"Comprehensive adoption of security standards in health care, not piecemeal implementation, is advocated to provide security to data that is exchanged between health care entities.

"By definition, if a system or communications between two systems, were implemented with technology(s) meeting standards in a general system security framework (Identification and Authentication; Authorization and Access Control; Accountability; Integrity and Availability; Security of Communication; and Security Administration.) that system would be essentially secure.

* * * no single standards development organization (SDO) is addressing all aspects of health care information security and confidentiality, and specifically, no single SDO is developing standards that cover every category of the security framework." [Page 189]

Our proposed standard does not reference or advocate specific technology because security technology is changing quickly. We want to give providers/plans/clearinghouses flexibility to choose their own technical solutions. A standard that is dependent on a specific technology or technologies would not be flexible enough to use future advances.

The standard must be able to be implemented by all the affected entities, from the smallest provider to the largest clearinghouse. A single approach would be neither economically feasible nor effective in safeguarding health data. For example, in a small physician practice, a contingency plan for system emergencies might be only a few pages long, and cover issues such as where backup diskettes must be stored, and the location of a backup personal computer (PC). At a large health plan, the contingency plan might consist of multiple volumes and cover issues such as remote hot site operations and secure off-site storage of electronic media. The physician office solution would not protect the large plan’s data, and the plan’s solution would not be economically feasible (or necessary) for the physician office. Moreover, the statute specifically directed the Secretary to take into account the needs and capabilities of small and rural health care providers, as those terms are defined by the Secretary. The scalability of our approach addresses this direction. We are not proposing specific definitions of "small" and "rural" health care providers because the statute provides no exemptions or special benefits for these two groups. However, we solicit comments on the necessity to define these terms.

v General Approach

We would define the security standard as a set of requirements with implementation features that providers, plans, and clearinghouses must include in their operations to assure that electronic health information pertaining to an individual remains secure. The implementation features address specific aspects of the requirements. The standard does not reference or advocate specific technology. This would allow the security standard to be stable, yet flexible enough to take advantage of state-of-the-art technology. The standard does not address the extent to which a particular entity should implement the specific features. Instead, we would require that each affected entity assess its own security needs and risks and devise, implement, and maintain appropriate security to address its business requirements. How individual security requirements would be satisfied and which technology to use would be business decisions that each organization would have to make.

The recommendations contained in the National Research Council’s 1997 report For The Record: Protecting Electronic Health Information support our approach to the development of a security standard. This report presents findings and recommendations related to health data security, and is widely viewed as an authoritative and comprehensive source on the subject. The report concludes that appropriate security practices are highly dependent on individual circumstances, but goes on to suggest that:

The specific requirements and supporting implementation features detailed in the next section represent this general set of practices. Many health care entities have already implemented some or all of these practices. We believe they represent those practices that are necessary in order to conduct business electronically in the health care industry today and, therefore, are normal business costs.

Inherent in this approach is a balance between the need to secure health data against risk and the economic cost of doing so. Health care entities must consider both aspects in devising their security solutions.

The proposed standard requires that each health care entity engaged in electronic maintenance or transmission of health information assess potential risks and vulnerabilities to the individual health data in its possession in electronic form, and develop, implement, and maintain appropriate security measures. Most importantly, these measures must be documented and kept current.

The proposed security standard consists of the requirements that a health care entity must address in order to safeguard the integrity, confidentiality, and availability of its electronic data. It also describes the implementation features that must be present in order to satisfy each requirement. The proposed requirements and implementation features were developed by the implementation team based on knowledge of security procedures and existing standards and guidelines described above. This was an iterative process that involved extensive outreach with a number of health care industry and Department of Commerce security experts. We also drew upon Recommendations 1 and 3 in the National Research Council’s 1997 report, For The Record, that were recommended for immediate implementation.

"Recommendation 1: All organizations that handle patient-identifiable health care information—regardless of size—should adopt the set of technical and organizational policies, practices, and procedures described below to protect such information."

The proposed security standard addresses the following policies, practices, and procedures that were listed under Recommendation 1:

1. Individual authentication of users

2. Access controls

3. Audit trails

4. Physical security and disaster recovery

5. Protection of remote access points

6. Protection of external electronic communications

7. Software discipline, and

8. System assessment.

This proposed security standard was developed in the spirit of Recommendation 3. The security standard development process has been an open one with invitations to a number of organizations to participate in the security discussions. Although implementation team membership was limited to government employees, nongovernmental organizations; business organizations; individuals knowledgeable in security; and educational institutions have been encouraged to express their views.

As a result of the collaborative security regulation development process, the implementation team has chosen to divide the proposed security requirements, for purposes of presentation only, into the following four categories:

It should be noted that the only necessity is that the requirements would be met, not that they be presented in these four categories. Under this proposed rule, a business entity could choose to order the requirements in any manner that suits its business.

We then determined the requirements and implementation features that health plans, providers, and clearinghouses would implement. The implementation features describe the requirements in greater detail. Some requirements do not require this additional level of detail. Within the four categories, the requirements and implementation features are presented in alphabetical order to ensure that no one item is considered to be more important than another. The relative importance of the requirements and implementation features would depend on the characteristics of each organization.

The four categories of the matrix are described in greater detail in § 142.308 and are depicted in tabular form along with the electronic signature standard in a combined matrix located at Addendum 1. We have not included the matrix in the proposed regulation text. We invite your comments concerning the appropriateness and usefulness of including the matrix in the final regulation

text. We also solicit comments as to the level of detail expressed in requirement implementation features; i.e., do any represent a level of detail that goes beyond what is necessary or appropriate. We have also provided a glossary of terms to facilitate a common understanding of the matrix entries. The glossary can be found at Addendum 2. Finally, we have included currently existing standards and guidelines mapped to the proposed security standard. This mapping is not all inclusive and is located at Addendum 3.

Background

To improve the efficiency and effectiveness of the health care system, Congress enacted the Health Insurance Portability and Accountability Act (HIPAA) of 1996, which included a series of "administrative simplification" provisions that required the Department of Health and Human Services (HHS) to adopt national standards for electronic health care transactions. All covered entities must be in compliance with the electronic transactions and code sets standards by October 16, 2003.

The law is clear: October 16, 2003 is the deadline for covered entities to comply with HIPAA’s electronic transaction and code sets provisions. After that date, covered entities, including health plans, may not conduct noncompliant transactions. With the October deadline just ahead, HHS has received a number of inquiries expressing concern over the health care industry’s state of readiness. In response, the Department believes it is particularly important to outline its approach to enforcement of HIPAA’s electronic transactions and code sets provisions. The Department will continue to provide technical assistance and issue guidance on the transactions and code sets provisions and compliance therewith.

The Secretary has made the Centers for Medicare & Medicaid Services (CMS) responsible for enforcing the electronic transactions and code sets provisions of the law.

CMS will focus on obtaining voluntary compliance and use a complaint-driven approach for enforcement of HIPAA’s electronic transactions and code sets provisions. When CMS receives a complaint about a covered entity, it will notify the entity in writing that a complaint has been filed. Following notification from CMS, the entity will have the opportunity to 1) demonstrate compliance, 2) document its good faith efforts to comply with the standards, and/or 3) submit a corrective action plan.

Demonstrating Compliance - Covered entities will be given an opportunity to demonstrate to CMS that they submitted compliant transactions.

Good Faith Policy - CMS’s approach will utilize the flexibility granted in section 1176(b) of the Social Security Act to consider good faith efforts to comply when assessing individual complaints. Under section 1176(b), HHS may not impose a civil money penalty where the failure to comply is based on reasonable cause and is not due to willful neglect, and the failure to comply is cured with a 30-day period. HHS has the authority under the statute to extend the period within which a covered entity may cure the noncompliance "based on the nature and extent of the failure to comply."

CMS recognizes that transactions often require the participation of two covered entities and that noncompliance by one covered entity may put the second covered entity in a difficult position. Therefore, during the period immediately following the compliance date, CMS intends to look at both covered entities’ good faith efforts to come into compliance with the standards in determining, on a case-by-case basis, whether reasonable cause for the noncompliance exists and, if so, the extent to which the time for curing the noncompliance should be extended.

CMS will not impose penalties on covered entities that deploy contingencies (in order to ensure the smooth flow of payments) if they have made reasonable and diligent efforts to become compliant and, in the case of health plans, to facilitate the compliance of their trading partners. Specifically, as long as a health plan can demonstrate to CMS its active outreach/testing efforts, it can continue processing payments to providers. In determining whether a good faith effort has been made, CMS will place a strong emphasis on sustained actions and demonstrable progress.

Indications of good faith might include, for example, such factors as:

While there are many examples of complaints that CMS may receive, the following is one example that illustrates how CMS expects the process to work.

Example: A complaint is filed against an otherwise-compliant health plan that accepts and processes both compliant and non-compliant transactions while working to help its providers achieve compliance.

In this situation, CMS would 1) notify the plan of the complaint, 2) based on the plan’s response to the notification, evaluate the plan’s efforts to help its noncompliant providers come into compliance, and 3) if it determined that the plan had demonstrated good faith and reasonable cause for its non-compliance, not impose a penalty for the period of time CMS determines is appropriate, based on the nature and extent of the failure to comply.

For example, CMS would examine whether the health plan undertook a course of outreach actions to its trading partners on awareness and testing, with particular focus on the actions that occurred prior to October 16th. Similarly, health care providers should be able to demonstrate that they took actions to become compliant prior to October 16th. If CMS determines that reasonable and diligent efforts have been made, the cure period for noncompliance would be extended at the discretion of the government. Furthermore, CMS will continue to monitor the covered entity to ensure that their sustained efforts bring progress towards compliance. If continued progress is not made, CMS will step up their enforcement efforts towards that covered entity.

Organizations that have exercised good faith efforts to correct problems and implement the changes required to comply with HIPAA should be prepared to document them in the event of a complaint being filed. This flexibility will permit health plans to mitigate unintended adverse effects on covered entities’ cash flow and business operations during the transition to the standards, as well as on the availability and quality of patient care.

Corrective Action Plan (CAP) – After October 16, 2003, in addition to possible fines and penalties imposed, CMS will expect non-compliant covered entities to submit plans to achieve compliance in a manner and time acceptable to the Secretary. More detailed information on CAPs will be forthcoming.

In the few remaining months before the October 16th deadline, HHS encourages health plans and providers to intensify their efforts toward achieving transaction and code set compliance. In addition, HHS encourages health plans to assess the readiness of their provider communities to determine the need to implement contingency plans to maintain the flow of payments while continuing to work toward compliance. Although transaction and code set compliance is a huge undertaking, the result will be greatly enhanced electronic communication throughout the health care community. Successful implementation will require the attention and cooperation of all health plans and clearinghouses, and of all providers that conduct electronic transactions. There is considerable industry support for transaction and code sets, and we all look forward to realizing the many advantages of its successful implementation.

v HIPAA Administrative Simplification Compliance Act (ASCA)

The delay will give covered entities more time to build, test, and successfully implement the new Final Electronic Transactions and Code Sets required by HIPAA.

No, the compliance date for the privacy standards is still April, 2003 or, for small health plans, April 2004.

No, the compliance date for small plans does not change.

No. Covered entities must submit a compliance extension plan to the Department of Health and Human Services (HHS) before October 16, 2002 to get an extension.

The requirement to submit a compliance extension plan provides assurance that covered entities have plans in place that will allow them to be compliant by the new deadline of October 16, 2003.

The law does not require approval or disapproval of plans. Submission of an extension plan is sufficient to secure the one-year extension.

The form will be available by March 31, 2002.

We will publish the form in the Federal Register and will also make it available on several websites. The compliance extension form we are developing is a model. While we strongly recommend its use, covered entities may submit plans using other formats.

We are still working on the form, but we intend to make it as simple and easy to complete as possible. The ASCA requires the plans to contain summary information regarding compliance activities, including: 1) budget, schedule, work plan and implementation strategy for achieving compliance; 2) planned use of contractors or vendors; 3) assessment of compliance problems; and 4) a timeframe for testing to begin no later than April 16, 2003.

No. The compliance extension form will ask only for summary information from your detailed plan. You do not need to send other information.

Yes, we will encourage electronic filing of compliance extension plans, although we will also accept plans submitted on paper.

Covered entities must submit their compliance extension plans by October15, 2002.

Please do not submit requests at this time. Instructions will be issued that will explain how to submit compliance extension plans.

Each covered entity should communicate directly with its own trading partners to determine which ones have submitted plans. This information could be included in establishing schedules for the testing activities that are to begin by April 16, 2003, culminating in a migration to the new standards that meets the needs of all trading partners.

No. A covered entity will be considered compliant if it can send and receive compliant transactions, and therefore would not need to submit an extension plan.

This is a business decision between the plan and its provider network. Neither HIPAA nor ASCA preclude plans from requiring that their providers use standard transactions in advance of the compliance deadline, but HIPAA non-compliance penalties would not apply to a provider that has submitted a plan until 2003.

Under the Freedom of Information Act (FOIA), information held by the federal government is available to the public on request, unless it falls within one of several exemptions. The model form will be designed to avoid collection of any information that would be subject to exemption, such as confidential personal or proprietary information. If such information is submitted, both the FOIA and the ASCA require that it be redacted before the files are released either to the NCVHS or to the public.

Medicare will continue to implement the HIPAA transaction standards on a sequenced basis, and that schedule will not change significantly. We expect to be ready to test the claim and several other transactions by Spring 2002, but implementation of several transactions (such as the referral/authorization transaction) will be in early FY 2003. Once a provider has successfully tested a transaction with us, it will be able to use the standard in our production environment.

Each Medicaid State Agency has its own project plan for achieving HIPAA compliance, and will decide whether to submit a compliance extension plan. If you are a trading partner, you will receive notice of testing directly from the Medicaid State Agency(s) with whom you do business.

No. Only covered entities – plans, clearinghouses and providers – must file. In fact, vendors will need to maintain their current delivery schedules for compliant software in order for covered entities to make use of the additional implementation time.

ASCA requires that compliance plans include a testing phase that would begin no later than April 16, 2003. We recommend that all covered entities begin to test as soon as they are ready in order to allow adequate time to address and correct problems. CMS will soon send out an instruction with dates by which Medicare contractors must begin testing with providers.

HHS will be publishing proposed regulations to address this new exclusion authority.

ASCA prohibits HHS from paying Medicare claims that are not submitted electronically after October 16, 2003, unless the Secretary grants a waiver from this requirement. It further provides that the Secretary must grant such a waiver if there is no method available for the submission of claims in electronic form or if the entity submitting the claim is a small provider of services or supplies. Beneficiaries will also be able to continue to file paper claims if they need to file a claim on their own behalf. The Secretary may grant such a waiver in other circumstances. We will publish proposed regulations to implement this new authority.

Congress and the health care industry have agreed that standards for the electronic exchange of administrative and financial health care transactions are needed to improve the efficiency and effectiveness of the health care system. The Health Insurance Portability and Accountability Act of 1996 (HIPAA) required the Secretary of Health and Human Services to adopt such standards.

National standards for electronic health care transactions will encourage electronic commerce in the health care industry and ultimately simplify the processes involved. This will result in savings from the reduction in administrative burdens on health care providers and health plans. Today, health care providers and health plans that conduct business electronically must use many different formats for electronic transactions. For example, about 400 different formats exist today for health care claims. With a national standard for electronic claims and other transactions, health care providers will be able to submit the same transaction to any health plan in the United States and the health plan must accept it. Health plans will be able to send standard electronic transactions such as remittance advices and referral authorizations to health care providers. These national standards will make electronic data interchange a viable and preferable alternative to paper processing for providers and health plans alike.

As required by HIPAA, the Secretary of Health and Human Services is adopting standards for the following administrative and financial health care transactions:

Standards for the first report of injury and claims attachments (also required by HIPAA) will be adopted at a later date.

All private sector health plans (including managed care organizations and ERISA plans, but exlcuding certain small self administered health plans) and government health plans (including Medicare, State Medicaid programs, the Military Health System for active duty and civilian personnel, the Veterans Health Administration, and Indian Health Service programs), all health care clearinghouses, and all health care providers that choose to submit or receive these transactions electronically are required to use these standards. These "covered entities" must use the standards when conducting any of the defined transactions covered under the HIPAA.

A health care clearinghouse may accept nonstandard transactions for the sole purpose of translating them into standard transactions for sending customers and may accept standard transactions and translate them into nonstandard transactions for receiving customers.

If the plan performs that business function (whether electronically, on paper, via phone, etc.), it must be able to support the electronic standard for that transaction. It may do this directly or through a clearinghouse.

All health plans, all health care clearinghouses, and any health care provider that chooses to transmit any of the transactions in electronic form must comply within 24 months after the effective date of the final rule (small health plans have 36 months). The effective date of the rule is 2 months after publication. Therefore, compliance with the final rule is required by October 2002 (October 2003 for small health plans). Entities can begin using these standards earlier than the compliance date.

HIPAA required the Secretary to adopt standards, when possible, that have been developed by private sector standards development organizations (SDOs) accredited by the American National Standards Institute (ANSI). These are not government agencies. All of the transactions adopted by this rule are from such organizations. All are from the Accredited Standards Committee (ASC) X12N except the standards for retail pharmacy transactions, which are from the National Council for Prescription Drug Programs (NCPDP).

ANSI ASC X12N standards, Version 4010, were chosen for all of the transactions except retail pharmacy transactions. The choice for the retail pharmacy transactions was the standard maintained by the NCPDP because it is already in widespread use. The NCPDP Telecommunications Standard Format Version 5.1 and equivalent NCPDP Batch Standard Version 1.0 have been adopted in this rule (health plans will be required to support one of these two NCPDP formats).

Internet transactions are being treated the same as other electronic transactions. However, we recognize that there are certain transmission modes in which the format portion of the standard is inappropriate. In these cases, the transaction must conform to the data content portion of the standard. In particular, a "direct data entry" process, where the data are directly keyed by a health care provider into a health plan’s computer using dumb terminals or computer browser screens, would not have to use the format portion of the standard, but the data content must conform. If the data are directly entered into a system that is outside the health plan’s system, to be transmitted later to the health plan, the transaction must be sent using the format and content of the standard.

The decision on when a standard must be used does not depend on whether the transaction is being sent inside or outside corporate boundaries. Instead, a simple two part test, in question form, can be used to determine whether the standards are required.

For purposes of question 1, a business associate acting on behalf of a covered entity can only perform those particular functions that the covered entity itself could perform in the transaction. The regulation requires health plans to accept standard transactions from any person.

For purposes of question 2, the definitions of the transactions themselves, as stipulated in Subpart K through Subpart R of the regulation, must be used to determine if the function is a transaction for which the Secretary has adopted a standard.

Section 1178 of the Social Security Act provides that standards for the transactions will supercede any State law that is contrary to them, but allows for an exception process. This process is currently under development and will be issued in the final rule for Privacy Standards.

In addition to the exceptions for conflicting State laws, an exception may be allowed for the testing of proposed modifications to the standards. An entity wishing to test a different standard may apply for an exception to test the new standard. Instructions for applications are published in the final rule. In this way, we hope to encourage the development of new technologies.

Section 1171(5)(E) of the Social Security Act, as enacted by HIPAA, identifies the State Medicaid programs as health plans, which therefore must be capable of receiving, processing, and sending standard transactions electronically. There is no requirement that internal information systems maintain data in accordance with the standards. However, Medicaid programs will need the capacity to process standard claim, encounter, enrollment, eligibility, remittance advice, and other transactions. In addition, as health plans, the State Medicaid programs will be required to comply with other HIPAA standards two years after adoption of the standards.

The standards should benefit Medicaid programs in multiple areas. Here are a few examples:

The law gives the Secretary the authority to impose monetary penalties for failure to comply with a standard. The Secretary is required by statute to impose penalties of not more than $100 per violation on any person or entity who fails to comply with a standard except that the total amount imposed on any one person in each calendar year may not exceed $25,000 for violations of one requirement. Enforcement procedures will be published in a future regulation.

First, the Department developed a set of guiding principles to serve as the basis for evaluating alternative standards for each transaction. These guiding principles, designed to be consistent with the intent of HIPAA, are published in the regulation. Second, an inventory of standards was developed by the ANSI Health Informatics Standards Board, a private sector organization. Third, teams composed of representatives from several government agencies evaluated the available standards against the guiding principles to determine which standards best met the principles. Extensive outreach and consultation, including public meetings, with all facets of the health care industry continued throughout this process.

As required by HIPAA, the Secretary also consulted with the National Uniform Claim Committee (NUCC), the National Uniform Billing Committee (NUBC), the American Dental Association (ADA), and the Workgroup for Electronic Data Interchange (WEDI). The Secretary also considered advice from the National Committee on Vital and Health Statistics (NCVHS) and representatives of the health care industry who testified before the NCVHS Subcommittee on Health Data Needs, Standards, and Security.

Data dictionaries are available for an additional fee.

The implementation guides for the ASC X12N standards may be obtained from the Washington Publishing Company, 806 W. Diamond Ave., Suite 400, Gaithersburg, MD, 20878; telephone: 301-949-9740; FAX: 301-949-9742. These guides are also available at no cost through the Washington Publishing Company on the Internet at http://www.wpc-edi.com/hipaa/.

The implementation guide for retail pharmacy standards is available from the National Council for Prescription Drug Programs, 4201 North 24th Street, Suite 365, Phoenix, AZ, 85016; telephone: 602-957-9105; FAX: 602-955-0749. It is also available from the NCPDP’s website at http://www.ncpdp.org.

The Secretary has designated six organizations that have agreed to serve as Designated Standards Maintenance Organizations (DSMOs). The DSMOs are:

These organizations will work together to accept and evaluate requests for changes to the standards and suggest changes to the standards for the Secretary’s consideration. Further information about the change request process can be found on the Internet at: http://www.hipaa-dsmo.org .

The Secretary may modify a standard or its implementation guide specification one year after the standard or implementation specification has been adopted, but not more frequently than once every 12 months. If the Secretary modifies a standard or implementation specification, the implementation date of the modified standard or implementation specification may be no earlier than 180 days following the adoption of the modification. The Department of Health and Human Services (HHS) will determine the actual date, taking into account the time needed to comply given the nature and extent of the modification. HHS may extend the time for compliance for small health plans. Standards modifications will be published as regulations in the Federal Register.

No, there is no such requirement. However, more physicians may want to use computers for submitting and receiving transactions (such as health care claims and remittances/payments) electronically, once the standard way of doing things goes into effect.

The Administrative Simplification provisions of the HIPAA law were passed with the support of the health care industry. The industry believed standards would lower the cost and administrative burdens of health care, but they needed Government’s help to get to one uniform way of doing things. In the past, individual providers (physicians and others) have had to submit transactions in whatever form each health plan required. Health plans could not agree on a standard without giving their competitors a market advantage, at least in the short-run. The law, which requires standards to be followed for electronic transmission of health care transactions, levels the playing field. It does not require providers to submit transactions electronically. It does require that all transactions submitted electronically comply with the standards.

Providers, even those without computers, may want to adopt these standard electronic transactions, so they can benefit directly from the reductions in cost and burden. This is possible because the law allows providers (and health plans too, for that matter) to contract with clearinghouses to conduct the standard electronic transactions for them.

The transaction standards will apply only to electronic data interchange (EDI)– when data are transmitted electronically between health care providers and health plans as part of a standard transaction. Data may be stored in any format as long as it can be translated into the standard transaction when required. Security standards, on the other hand, will apply to all health care information.

To comply with the transaction standards, health care providers and health plans may exchange the standard transactions directly, or they may contract with a clearinghouse to perform this function. Clearinghouses may receive non-standard transactions from a provider, but they must convert these into standard transactions for submission to the health plan. Similarly, if a health plan contracts with a clearinghouse, the health plan may submit non-standard transactions to the clearinghouse, but the clearinghouse must convert these into standard transactions for submission to the provider.

Currently, some insurers accept the de facto standard claim (e.g., UB-92) but also require additional records (e.g., a proprietary cover sheet) for each claim submitted. Others have special requirements for data entered into the claim which make it non-standard.

Under the law, health plans are required to accept the standard claim submitted electronically. They may not require providers to make changes or additions to the standard claim. They must go through the private sector standards setting process to get their requirements added to the standard in order to effect desired changes. Health plans may not refuse the standard transaction or delay payment of a proper standard transaction.

An additional standard will be adopted for electronic health claims attachments, which health plans will be required also to accept. Until that standard is adopted (by February, 2001), health plans may continue to require health claim attachments to be submitted on paper. No other additions to standard claims will be acceptable.

Additional information may be provided within certain limits.

Electronic transactions must go through two levels of scrutiny: