• No results found

Health Insurance Portability & Accountability Act (HIPAA) TECHNICAL WHITE PAPER

N/A
N/A
Protected

Academic year: 2021

Share "Health Insurance Portability & Accountability Act (HIPAA) TECHNICAL WHITE PAPER"

Copied!
14
0
0

Loading.... (view fulltext now)

Full text

(1)

Health Insurance Portability & Accountability Act (HIPAA)

TECHNICAL WHITE PAPER

A U G U S T 2 0 0 1

(2)

1.0 INTRODUCTION

Like most other major enterprises, healthcare organizations are moving rapidly toward transmission of

information over the Internet to take advantage of the associated flexibility, speed, and inherent cost-savings. However, with the benefits of electronic information transfer come the regulations and liabilities associated with privacy and unauthorized access of data, most notably in the form of the Health Insurance Portability and Accountability Act of 1996 (HIPAA).

Far from being a clearly outlined set of standards and expectations, HIPAA and its related regulations represent an enormous web of confusing mandates, coming in the form of Proposed Rules, Rules, Final Rules, (final) Final Rules and ever-changing deadlines. Untangling this web proves to be an exhausting process. Curiously, the websites of the Department of Health and Human Service (HHS) and the Centers for Medicare and Medicaid Services (CMS), the government agencies charged with creating and enforcing HIPAA regulations, provide some of the least comprehensive information on the subject!

At its most fundamental level, as it concerns healthcare organizations, HIPAA applies to three major areas: privacy, administrative simplification, and security.

The Final Rule on privacy standards entered the Federal Register on December 28, 2000, requiring healthcare organizations of all sizes to comply by April 14, 2003 (large organizations) and Apr 14, 2004 (small

organizations). Recent proposed changes remove some of the onus from practices, especially in the area of patient consent, making the rules more enforceable and reasonable in terms of compliance.

The privacy rule describes patient privacy rights and creates a framework within which individual practices and physicians may create internal rules and policies. Technical requirements supporting privacy, such as

electronic transaction and code set standards, fall under the umbrella of security and administrative simplification.

As a major component of HIPAA, the administrative simplification requirement pertains to the handling and exchange of healthcare information through uniform transaction standards. Specifically, this applies to code sets and uniform identifiers, which are used to identify transactions and patients.

Two major developments in this area, HHS's proposed “Modifications to Transaction and Code Set Standards for Electronic Transactions” and designation of the Employer Identification Number (EIN) as a standard identifier, were entered into the Federal Register on May 31, 2002. The compliance deadline for the published Final Rule is October 16, 2002 (or October 16, 2003, for practices that file a compliance plan and request an extension), with the revised rule under the proposed Modifications carrying its own as yet to be announced deadline. With regard to security, HHS's proposed Standards for Security and Electronic Signatures (SES) aim to standardize how electronic patient data is accessed as well as transmitted between organizations. The Proposed Rule was released in August 1998 and should become finalized this year with an expected compliance deadline in late 2004. SES mandates requirements in five broad areas:

Administrative Requirements - covering certification, policies, controls and auditing

Physical Security Requirements - governing and auditing physical access to systems and media Technical Security Services - systems and software used to protect electronic data

Technical Security Mechanisms including network access controls, alarms, auditing and reporting Electronic Signature Standards - auditing and non-repudiation of electronic transactions

According to most authorities on the subject of electronic security standards, there has never been such a sweeping set of changes been enacted. HIPAA is acting as a catalyst for change, driving affected organizations to research and implement solutions in order to meet the enacted deadlines. An article in Health Management Data Magazine refers to the security and privacy provisions of HIPAA as the most challenging federa

(3)

According to most authorities on the subject of electronic security standards, there has never been such a sweeping set of changes been enacted. HIPAA is acting as a catalyst for change, driving affected organizations to research and implement solutions in order to meet the enacted deadlines. An article in Health Management Data Magazine refers to the security and privacy provisions of HIPAA as the most challenging federal

information security requirements facing healthcare organization [Godert 'The Dawn of HIPAA' April 2000]. Existing players in the electronic security industry are positioning their current product lines as 'HIPAA solutions', bringing to bear large-scale deployments of complex technologies. Almost without exception these approaches are expensive, resource-intensive to install and maintain, difficult to use, and, in many cases unsuitable for mixed communication between organizations and individuals.

CureMD's HIPAA mission is two-fold. With regard to privacy, security and administrative simplification standards, CureMD is committed to keeping pace with HIPAA requirements as each Final Rule takes effect, appropriately assisting clients with maintaining adherence to their own HIPAA compliance plans.

Secondarily, CureMD offers sound alternatives that address security, privacy and uniform transactions within reasonable economies. Unlike many legacy products, CureMD's solution is almost completely transparent and requires very little end-user training. CureMD upholds comprehensive interoperability with its standards-based software that works with all leading platforms, servers, clients, and authentication approaches, thereby fully leveraging existing IT investments.

Complete policy control enables system administrators to enforce security policies and provide rigorous, end-to-end security based on the Federal Advanced Encryption Standard (AES).

2.0 OPPORTUNITY

According to the VHA and Deloitte & Touche Health Care 2000 study, approximately 33.5 million Americans received healthcare information online in 2000. With projected population growth, general availability of Internet access, increasing mobility, and a wider variety of healthcare options available to Americans, demand will only increase for electronic transfer of patient information.

Private data that likely to be delivered electronically include portable and universal health records; web or email-based test results; online appointment scheduling and reminders; and electronic dialogue with physicians and other healthcare providers.

Electronic information can be exchanged in many formats to a variety of recipient environments (email, browser, PDA, wireless phone, pager, text-to-voice). In a digital world, reproduction of information is easily reproduced and disseminated, and copies are essentially free and as authentic as the original. This presents a considerable challenge to organizations required to authenticate, authorize, encrypt and audit such

information exchanges in a consistent manner while still providing a useful and cost-effective solution. On the provider side, the increased exchange of information over secure networks offers a very real

opportunity for shortened revenue cycles, improved patient-doctor communication, and ultimately, improved quality of care. On the IT vendor side, the opportunities for developing and marketing new products and services are tremendous. Of course, this requires extra vigilance and education on the provider (consumer) side.

3.0 REGULATIONS

3.1 HIPAA and Related Acts

This section is not intended as a replacement for consulting the enacted and proposed legislation. Rather, it is intended to provide a broad overview of electronic security and privacy issues and pertinent regulations, with a

(4)

focus on requirements for security software and services. O 0 R n h t a o u l r e t e p A a 5 T l n o s 3.2 Privacy Standards

n December 28, 200 , HHS published in the Federal Register (65 Fed. eg. 82462-82829) the final rule establishing “Sta dards for Privacy Individually Identifiable Healt Information” (45 CFR Parts 160-164)

pursuant to he requirements of Sections 262 and 264 of the He lth Insurance Portability and Accountability Act f 1996 (HIPAA). According to HHS, “This rule incl des standards to protect the privacy of individua ly

identifiable health information” as well as “p ocedures for the exercise of those rights, and th authorized and required uses and disclosures of his information.”

Covered entities and those cov red via business associate agreements must be com liant with all provisions of the Privacy rule by pril 14, 2003, with an extension for ''small'' he lth plans (defined as having annual receipts of $ million or less) of an additional year, to April 14, 2004. Revisions were published in March 2002 and should be finalized by the end of the year.

he Privacy Standards themselves mandate no techno ogies, policies, procedures, products, or impleme tations - just requirements that must be met by c mpliant organizations. As the Standards went from draft form to final form, the scope of regulation significantly expanded:

The rule now covers information in any medium or format - paper, electronic, or oral All information disclosures now require patient consent

Retention of the requirement that covered entities have written contractual relationships with business associates that receive or create private health information from or on behalf of the covered entity (Business Associate)

Express prohibition of employers accessing patient data for employment-related purposes

3.3 Security Standards

In addition to these Privacy Standards are the proposed Security and Electronic Signature Standards (SES). These are primarily concerned with guarding against inappropriate access and dissemination of protected data, rather than with privacy rights. When referring to 'HIPAA compliance' from an information security technology viewpoint, it is usually SES that provides the detailed requirements that specific security implementations must meet.

On August 12, 1998, the HHS published in the Federal Register (6.3 Fed. Reg. No. 5) the proposed rule for "Security and Electronic Signature Standards" (45 CFR Part 142) pursuant to the requirements of Section 262 of the Health Insurance Portability and Accountability Act of 1996 (HIPAA).

The Security and Electronic Signature Standards mandate the following:

Individually identifiable healthcare information must be protected to ensure privacy and confidentiality when electronically stored, maintained or transmitted"

They are "applicable to all electronic healthcare information whether internally communicated or externally communicated”

There must be documented policies and procedures for the routine and non-routine receipt, manipulation, storage, dissemination, transmission and/or disposal of health information

Note: individual states are free to enact more stringent requirements HIPAA and the associated regulations define only a national minimum.

The primary goal of the privacy and security legislation is to protect individually identifiable healthcare information (“protected data") in any electronic form from inadvertent or purposeful exposure to anyone not pre-approved for such exposure. Protection is expected to be provided through a combination of administrative policies, physical and electronic security, and regular audits. Compliance can be enforced via fines or, for willful or egregious failure to comply, via a prison term for the responsible individuals, as detailed below.

(5)

3.4 Impacted Organizations

There are two types of organizations impacted by HIPAA and associated standards. The first are organizations directly named in the legislation, called covered entities, and include health plans, healthcare providers, and healthcare information clearinghouses. The second are organizations indirectly named under the legislation. These are organizations that have a business relationship with covered entities and become subject to the laws as a consequence of business associate agreements executed with those entities. Any company or individual providing outsourced services to a covered entity that may involve the electronic transmission of individual data should expect to have to execute a business associate agreement, and to comply with HIPAA provisions. This second group includes law firms, insurance companies, test labs, and potentially employers. Each impacted organization will be responsible for:

Consistent, documented data handling policies and procedures, including regular updates, compliance auditing and training

Enforcement of equivalent regulations, policies, and procedures onto partner organizations handling protected data through written contracts (“Business associate contracts”)

Limiting physical and network access to protected data to approved individuals, and auditing all such accesses and any exceptions

Maintenance of data integrity, access and modification authorization and auditing, including events Non-compliance detection and correction alarms, auditing, procedures and systems

Creation and maintenance of a repository of retrievable, exact copies of data (patients can inspect and copy their protected health information as well as request a six-year audit of any disclosures made for reasons other than treatment, payment and healthcare operations)

Overall auditing and certification of compliance

While the affected 'data' referred to above is defined as 'individually identifiable healthcare information' in most cases it will be impractical to implement one security infrastructure for affected data and another for data that is not affected by HIPAA. In addition to the cost associated with deploying and maintain two information systems, is the potential liability cost associated with passing protected data across a non-compliant system. Therefore it is most likely that all electronic data passing inside and between healthcare organizations and their partners will move on HIPAA-compliant systems.

3.5 Liability

In the event of failure to comply with the requirements, the legislation provides for fines and/or jail terms: Civil penalties of $100 per violation, up to $25,000 per person per year for each standard

Criminal penalties for knowingly and improperly disclosing or obtaining protected health information of up to $50,000 and one year in prison, or up to $100,000 and five years for obtaining such data under "false pretenses", or tip to $250,000 and ten years for obtaining or disclosing with the intent to sell, transfer or use it for personal gain, commercial advantage or malicious harm

These penalties are separate from any levied by direct slut from an individual whose data is compromised contrary to these regulations.

3.6 Other Relevant Issues

In the European Union, a British individual privacy standard, BS7799, has been adopted as a provisional international standard, ISO 17799. ISO 17799 severely restricts how organizations can use data gathered from individuals in the EU, and requires consent for that use. Companies in any industry that do business in the EU will find themselves subject to IS0 17799 in the near future and should begin researching the standard and approaches to meeting its provisions.

4.0 SECURITY REQUIREMENTS

The Security and Electronic Signature Standards are composed of five top-level categories, with each category containing several subsections. The five primary categories are:

(6)

Administrative Requirements Physical Security Requirements Technical Security Services Technical Security Mechanisms Electronic Signature Standards

The following section walks through each security category and requirement in detail, and describes the implication each category presents to an organization attempting to comply with HIPAA and associated regulations. Extra attention is paid to specific items where CureMD-provided solutions could be leveraged to fulfill those requirements. The details of this section are referenced from the annotated 'Notice of Proposed Rule Making for the Security and Electronic Signature Standards', available from the Department of Health and Human Services.

4.1 Administrative Requirements

All twelve of the high-level 'Administrative Requirements' are designed to ensure that a compliant entity has a coherent security program in place from an organizational standpoint. Such a program must include

appropriate information security policies and procedures, management awareness and oversight, and organizational buy-in to compliance with policy and technical controls.

4.1.1 Certification

Each organization would be required to perform an evaluation to certify that the appropriate security has been implemented. This evaluation could be performed internally or by an external accrediting agency, and many such accrediting organizations are already offering 'HIPAA certification'.

4.1.2 Business Associate Contracts

If data is processed through or by a third party for a covered entity, the parties are required to enter into a business associate contract. This is a contract in which the third party agrees to protect the transmitted data to the same requirements as the covered entity. Chains of trust may extend even further, for example, if the third party itself contracts out data handling to another party, the new party must be bound by another contractual link in the business associate contract.

The primary consequence of the business associate requirements is that organizations not directly covered under the regulations will have to behave as if they were, in order to continue to engage in business with a covered entity. As chains of trust expand with the movement of protected data, there are expected to be more organizations involved with HIPAA due to chains of trust than due to direct compliance requirements. In particular, organizations, which provide connectivity IS/IT outsourcing services will need to confront the business associate issues of HIPAA directly to continue to do business with the healthcare industry.

CureMD itself is prepared to enter into business associate contracts as required by its customers. At the same time, CureMD's unique platform architecture - providing integrated security services while handling protected data - will limit effort and liability for our customers.

4.1.3 Contingency Plan

It is required that a contingency plan be in place for responding to system emergencies. The organization would be responsible for performing periodic backups, have available critical facilities for continuing operations the event of an emergency, and have disaster recovery procedures in place. Such a plan must include the following elements:

System, software, and data criticality and failure analysis A data backup plan

A disaster recovery plan

An emergency mode operation plan

(7)

CureMD has such plans and safeguards in place for responding to contingencies on our own data center operations, with customer availability of services enforceable through regular or customizable Service Level Agreements (SLA's). CureMD can also assist customers in architecting their own systems for fail-over and recovery, based on our experience in operating a secure, high-availability mission critical application platform. 4.1.4 Mechanism for Processing Records

There must be a formal, documented, data processing policy for processing records that covers routine and non-routine protected data receipt, manipulation, storage, dissemination, transmission, and disposal.

CureMD is available to assist organizations with implementing specific data policies. Regardless of how CureMD customers arrive at their internal policies, CureMD incorporates data handling protocols designed to meet the requirement of such policies. Further, CureMD's data-level manipulation solutions and user interface based controls allow an organization to enforce written data handling procedures directly and automatically. 4.1.5 Information Access Control

It is required that formal, documented policies and procedures for granting different level of access to protected data be implemented and updated. This requirement focuses on the procedural aspects of access control; actual access control mechanism requirements are covered under various headings in later

requirements.

To satisfy this specific requirement, the following policies and procedures must be provided: Access authorization

Access establishment Access modification

CureMD's embedded user-defined access control and authorization mechanism permits an organization to directly implement policies and procedures defined under this requirement.

4.1.6 Internal Audit

Regular in-house audits are required to allow identification of potential security violations. Policies and procedures covering the scope, frequency, and process of such audits are required. Auditing typically involves periodic and event-based review of records of system activity.

As CureMD secures data at the content level, our customers' auditing capabilities extend outside the

organization and include capabilities such as receipt confirmation. All CureMD products and services provide extensive and detailed reporting mechanisms to assist internal auditing, including customized reports to better meet organization-specific needs for such audits. Iinternal system, data and application audit programs are also available for all CureMD customers.

4.1.7 Personnel Security

All personnel with access to protected data must be authorized to do so after receiving appropriate clearances. This is important to prevent unnecessary or inadvertent access to secure information. To meet this

requirement, all of the following conditions must be met:

Supervision of personnel performing technical systems and maintenance activities by authorized, knowledgeable persons

Maintain access authorization records

Insure that operating and required maintenance personnel have proper access Employ personnel clearance procedures

Employ personnel security policy/procedures

Ensure that system users, including technical maintenance personnel, are trained in system security By separating the handling of protected data from the security infrastructure, CureMD solutions minimize the

(8)

possible exposure of information to operational and maintenance personnel. 4.1.8 Security Configuration Management

Organizations are required to implement measures, practices, and procedures for the security of information systems. These must be coordinated and integrated with other system configuration management practices in order to create and manage system integrity. This integration process is important to ensure that routine changes do not contribute to, or create, security weaknesses, and that any new issues can be traced back to changes in configuration, if appropriate. Specifically, this result in requirements for:

Documentation

Installation and maintenance review and testing for security Inventory procedures

Security testing Virus Checking

CureMD takes on the responsibility of maintaining correct configuration information and updating security audits-based “oil changes” in that configuration. The CureMD platform integrates with industry proven virus scanning solutions to provide a coherent approach to both virus and data security. CureMD can also manage the regular updating of virus scanning solutions required to meet new threats.

4.1.9 Security Incident Procedures

Formal, documented instructions for reporting security breaches are required, including the following: Report procedures

Response procedures

CureMD operates a 24x7 operational response team to react to potential service availability and security issues with an accompanying escalation procedure. CureMD's response team and procedures should be incorporated into the Security Incident procedures employed by our customers.

4.1.10 Security Management Process

Security management involves creating, administering, and overseeing policies to ensure the prevention, detection, containment, and correction of security breaches. A formal security management process must be in place to address the full range of security issues, and must include the following mandatory implementation features:

Risk analysis Risk management A sanction policy A security policy

As with incident procedures, any umbrella security management process implemented by a CureMD customer can leverage our 24x7 security response team, as well as our expertise in handling security breaches and related issues.

4.1.11 Termination Procedures

Formal termination procedures are required to prevent the possibility of unauthorized access to secure data by those who are no longer authorized to access that data. Termination procedures would include the following mandatory implementation features:

Changing combination locks and shared passwords Removal from access lists

Removal of user account(s)

Return of all keys, tokens, or cards that allow access

(9)

Use defined access management also provides the basis for single sign-on, allowing organizations to have a single point at which access decisions are made and from which authorizations need to be altered.

4.1.12 Training

Security training is required for all staff regarding the vulnerabilities of the health information in an entity's possession and the procedures that must be followed to ensure that information's protection. The specific implementation features that are required are:

Awareness training for all personnel, including management Periodic security awareness reminders

User education concerning virus protection

User education in importance of monitoring login success/failure, and how to report discrepancies User education in password management

CureMD strongly recommends that security implementations are automatically enforced wherever possible. Experience indicates that employees are most likely to circumvent security when it hampers their ability to perform their job. CureMD was founded to provide secured solutions that are easy to use, to make sure that employees can work to enforce security rather than attempting to work around it.

4.2 Physical Security Requirements

The 'Physical Security Requirements' are designed to put in place physical safeguards and their associated operational policies and procedures to protect against inappropriate access to protected data.

4.2.1 Assigned Security Responsibility

Security responsibility must be documented and assigned to a specific individual or organization. This

responsibility includes the management and supervision of security measures to protect data, and the conduct of personnel in relation to the protection of data.

Many organizations will establish the office of Chief Security Officer (CSO) and/or Chief Privacy Officer (CPO) to fulfill this requirement. Typically, such a position reports to an executive-level officer such as the CIO or CEO and will be a key decision maker in selecting technical solutions compliant with HIPAA and related regulations.

4.2.2 Media Controls

Media controls govern receipt and removal of hardware and/or software into or out of a facility. It is

considered essential to control the media itself, as well as the health data therein. Media controls are required to cover at a minimum: Controlled access Accountability Backup Storage Disposal

CureMD's platform is media and data agnostic and can be used to secure data on systems and removable media. In doing so, organizations can leverage the data file authentication, access control, audit trail, and key shredding features of supplied third party tools to work in conjunction with policies governing the physical media on which the data is stored.

P a d

h e

4.2.3 Physical Access Controls

hysical ccess controls limit access to properly authorize individuals. Under the general umbrella of the p ysical access controls requirement are sub-requir ments detailing responsibility for:

Disaster recovery

Emergency mode operation

(10)

4.2.4 Policy on Workstation Use 4 4 r 4 c 4 4 4

A policy or guideline on proper workstation use is required. This policy should cover the proper administrative and security functions to be performed and the manner and timing with which they should be performed. CureMD's platform is configured to automatically log out a user after a predefined period of time elapses since the last event.

.2.5 Secure Workstation Location

Organizations must put in place sufficient physical safeguards to prevent or minimize the possibility of unauthorized physical access to information.

This can include the equivalent of a 'clean-desk' policy for monitors, moving terminals from direct view from public areas, and removing workstations from traffic areas.

.2.6 Security Awa eness Training

It is considered insufficient to simply implement policies, procedures, and safeguards. Organizations must also train their employees, agents, and contractors in what their security responsibilities entail, and how to comply with established policies and procedures.

.3 Technical Se urity Services

Technical Security Services are also referred to as System Security Services. These requirements most directly address the software and hardware security implementations.

.3.1 Access Control

Access control restricts access to privileged entities, such as healthcare employees with a business need, to see such information. Iris required that provisions be made for emergency access, and that at least one of three access types be provided from among: context-based access, role-based access and user-based access. Encryption of access control exchanges is optional.

CureMD's session-less authentication platform provides all three-access types, allows emergency access, and provides encrypted and signed access exchanges.

.3.2 Audit Control

Audit control mechanisms to record and examine system activity are required. In particular, suspect data access should be determined and detailed.

CureMD's platform provides comprehensive audit trails of authentication, authorization, and data access events, all of which are immediately available for inspection by the customer.

.3.3 Authorization Control

There is a requirement for a mechanism to obtain consent for the use and disclosure of health information. These controls would be necessary to ensure that health information is used only by properly authorized individuals. Either of the following implementation features may be used:

Facility security plan

Procedures for verifying valid physical access authorizations Maintenance records

Personnel access procedures on a need-to-know basis Visitor sign-in and escorts

Testing and revision

Role-based access User-based access

(11)

CureMD's authentication features provide user-based access, emergency access, and auditable, encrypted and signed access exchanges.

E h h u n C v m d l E t c l 4.3.4 Data Authentication

ach organization is required to ensure t at data in its possession has not been altered or destroyed in an unauthorized manner. Examples of ow data corroboration may be assured include the se of a check sum, double keying, a message authe tication code, or digital signature.

ureMD pro ides built-in data authentication and validation echanisms to control data integrity by default an can optionally provide digital signatures, as we l.

4.3.5 Entity Authentication

ach organization is required to authenticate entities, which means that an entity is who it claims to be. Authentica ion is important to prevent the improper identifi ation of an entity accessing secure data. The fol owing implementation features must be used:

Automatic log off

Unique user identification

In addition, at least one of the following implementation features (authentication mechanisms) must be used: A biometric identification system

A password system

A personal identification number (PIN) Telephone callback

A token system using a physical device for user identification

All CureMD products include automated log-off functionality with an adjustable time period. CureMD's platform provides unique user identification and a single sign on associated with a secured password system and can support a wide variety of authentication mechanisms. Initial focus is on support for prevalent mechanisms (x.509 certificate based, password based) and common protocols (Windows directory, LDAP, Radius). Additional non-standard authentication mechanisms can be supported on a case-by-case basis.

4.4 TECHNICAL SECURITY MECHANISMS

In this section, the requirements and implementation features for technical security mechanisms are

presented. In some sense, therefore, this section details the requirements on the security systems put in place to meet the general requirements. Each mechanism chosen would need to be documented, the documentation periodically reviewed, updated, and made available to those individuals responsible for implementing the mechanisms.

Each organization will be required to protect communications containing protected data transmitted

electronically over open networks so that they cannot be intercepted and interpreted by parties other than the intended recipient. They must further protect their information systems from intruders. When using open networks, some form of encryption must be employed. The utilization of less open systems/networks is considered to provide sufficient access controls to allow encryption to be an optional feature.

The following implementation features must be in place: Integrity controls

Message authentication

One of the following implementation features must be in place: Access Controls

(12)

As discussed, CureMD's solutions provide all of the required and suggested implementation features. In addition, if using a network for communications, the following implementation features would be in place:

Alarm Audit trail

Entity authentication Event reporting

4.5 ELECTRONIC SIGNATURE STANDARDS

An electronic signature is designed to provide non-repudiation of transactions. They can be used one-or two-way, depending on the need for either party to prevent transaction repudiation. With the Federal Digital Signature Act of 2000, digital signature (one type of electronic signature) can technically begin to carry the same legal weight as a physical signature. However, for this to be enforceable, the signature must meet certain requirements, including authentication of the signer's identity at the time of signature, a signature process, binding of the signature to the document, and non-alterability after the signature has been affixed to the document.

Various technologies may fulfill one or more of the requirements for a valid electronic signature.

Authentication systems can he combined with cryptographic techniques to form an electronic signature. If electronic signatures are to be used, certain implementation features must be included, specifically:

Message integrity Non-repudiation User authentication

Currently there are no accepted and technically mature techniques for non-repudiation in the absence of trusted third parties beyond digital signature-based techniques. Therefore, if electronic signatures are employed they should utilize digital signature technology.

A digital signature is created by applying a mathematical function (a hash) to the contents of a message. This process yields a unique string, referred to as a message digest. The digest is encrypted using the originator's private key and the result is appended to the electronic document. The recipient of the transmitted document decrypts the message digest with the originator's public key, applies the same message hash function to the document, then compares the resulting digest with the transmitted version. If they are identical, then the recipient is assured that the message is unaltered and the identity of the signer is proven. Since only the signatory authority can hold the Private Key used to digitally sign the document, the critical feature of non-repudiation is enforced. Other electronic signature implementation features that may be used include:

Ability to add attributes

Continuity of signature capability Countersignatures capability Independent verifiability Interoperability

Multiple signatures Transportability

Timestamps may also be added at different points in this process for auditing purposes. Whenever a HIPAA specified transaction requires the use of an electronic signature, the digital signature approach must be used. However, no current or proposed standard transactions require the use of electronic signatures.

CureMD can optionally provide enterprise-level digital signing capability, and can interoperate with individual digital signatures. CureMD's approach to digital signatures is fully compliant with the security industry's best practice, as well as with the approach recommended in this standard.

(13)

5.0 CONCLUSIONS

HIPAA presents a major challenge to all healthcare organizations, and the potential cost of utilizing traditional security approaches can be staggering. CureMD offers a lower-cost approach that is more quickly deployed and easy-to-use while meeting the same stringent security requirements of the above detailed regulations.

The future is clear - more information will be transmitted electronically, and multiple regulations will be applied to enforce the security of that data. With HIPAA deadlines approaching, it is critical that organizations identify security partners who understand both the regulations and the fundamental security needs of your business. CureMD offers compelling solutions and a unique model making it an ideal partner.

6.0 REFERENCES

Standards for Privacy of Individually Identifiable Health Information - A brief summery of the final rule' American Medical Information Association (AMIA).

‘Frequently Asked Questions About Electronic Transaction Standards Adopted Under HIPAA' Department of Health and Human Services.

‘Frequently Asked Questions About Security and Electronic Signature Standards' - Department of Health and Human Services.

‘Notice of Proposed Rule Making for the Security and Electronic Signature Standards' Department of Health and Human Services.

Godert, Joseph “The dawn of HIPPA“ Health Data Management April 2001 [1]

[2] [3] [4] [5]

Table 1: SECURITY REQUIREMENTS AND POSSIBLE IMPLEMENTATIONS

I. Administrative Requirements Implementation

a. Certification by internal process or external accrediting agency.

b. Chain of Trust Agreement Written agreements in place with all third parties handling data

c. Contingency Plan covering criticality analysis, data backup, disaster recovery, emergency operation and resting and revision.

d. Mechanism for Processing Records Policy for routine and exceptional processing

e. Information Access Control Policy for access authorization, establishment, and modification. f. Internal Audit Regular auditing procedures and process.

g. Personnel Security assures supervision of maintenance personnel by knowledgeable and authorized person,

record of access authorizations, assure proper authorizations for operations (and as necessary, maintenance) personnel, personnel clearance procedure, personnel security policy/procedure, system risers and maintainers trained in security.

h. Security Configuration Management Must cover documentation, hardware/software installation and maintenance, inventory,

procedures, security testing, virus checking.

i. Security Incident Procedures Must cover reporting and response process and procedures.

j. Security Management Process Must cover risk analysis, risk management, sanction policy, security policy. k. Termination Procedures Must mandate change locks and passwords, remove from access lists, remove user

accounts, turn in physical access materials.

l. Training Awareness training for all personnel, periodic security reminders, virus protection education, education in monitoring access attempts and reporting access discrepancies, education in password management

II. Physical Security Requirements

(14)

b. Media Controls Access control, Tracking Mechanism, Backup, Storage, Disposal

c. Physical Access Controls Disaster recovery, emergency operation, equipment movement controls, facility security plan, physical access authorization validation procedure, maintenance records, need-to know policy, visitor sign-in and escort policy testing and revision

d. Policy on Workstation Use Standard security functions anti process

e. Policy on Workstation Use Removal from unsecured areas physically and visually. f. Security Awareness Training and refreshing of security awareness

III. Technical Security Services

a. Access Control Must procedure for emergency access, one of- role/user/context access, optional encryption

b. Audit Control Mechanisms to record system activity and identify suspect access c. Authorization Control Role or User based access

d. Data Authentication Data integrity confirmation by checksum, double keying, MAC or digital signature e. Entity Authentication Must automatic log off, unique user id; one of biometric, password, PIN, telephone, callback, token.

IV. Technical Security Mechanisms

Required: Integrity Controls, Message Authentication One of: Access Control Encryption

Required if using a network: Alarm, Audit Trail, Entity Authentication, Event Reporting V. Electronic Signature Standards

(Not required for any proposed standard transactions, must be digital signatures if required) Required: Message Integrity, Non-repudiation, Entity Authentication

Optional: Attributes, Continuity, Countersigning, Independent verification, Interoperability, Multiple Signature, Transportability

55 Broad Street, New York, NY 10004 Phone: 212.509.6200 Fax: 212.509.6206

References

Related documents

The traverse speed, water pressure and abrasive flow- rate are found to have a profound effect on the total depth of cut and kerf taper angle, while the first two variables also have

Whist the NEC IP telephony solution provides adequate basic voice functionality, it restricts the University’s options in terms of providing Unified Communications and Collaboration

The data highlight that there are some differences in the fluctuation of occupancy rates and average daily rate (ADR) (the two major performance measures of the vitality

If you are new to St John, you will be emailed your log in details for the St John learning portal (Moodle).. • The link to the online training portal is

We used area under receiver-operating characteristic curves (AUCs) to quantify our ability to predict therapeutic resistance in individual patients, where AUC=1.0

The skewed normal distribution — when considered as consisting of both singular and nonsingular csn variables — is therefore not closed under arbitrary linear transformations,

All portable devices to be used for business purposes must be approved and registered with your departmental IT group or your local HIPAA Security Coordinator.. It is

*In order to comply with regulation for Health Insurance Portability and Accountability Act (HIPAA) governing the confidentiality of patient information, a fully completed,