Section 142.308 would set forth the security standard. There is no recognized single standard that integrates all the components of security (administrative procedures, physical safeguards, technical security services, and technical mechanisms) that must be in place to preserve health information confidentiality and privacy as defined in the law. Therefore, we are designating a new, comprehensive standard, which defines the security requirements to be fulfilled.
In fact, there are numerous security guidelines and standards in existence today, focusing on the different techniques available for implementing the various aspects of security. We thoroughly researched the existing guidelines and standards, and consulted extensively with the organizations that developed them. A list of the organizations with which we consulted can be found in section G. below. As a result of these consultations and our research, we identified several high-level concepts on which the standard is based:
![]() | The standard must be comprehensive. |
Consultation with standards development organizations, such as ANSI-accredited organizations, as well as business interest organizations, revealed the need for a standard that addressed all aspects of security in a concerted fashion. The HISB noted in its report to the Secretary that:
"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]
![]() | The standard must be technology-neutral. |
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 scalable. |
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:
"It is therefore not possible to prescribe in detail specific practices for all organizations; rather, each organization must analyze its systems, vulnerabilities, risks, and resources to determine optimal security measures. Nevertheless, the committee believes that a set of practices can be articulated in a sufficiently general way that they can be adopted by all health care organizations in one form or another."
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.
v
Specific RequirementsThe 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:
![]() | Organizational Practices |
Security and confidentiality policies
Information security officers
Education and training programs, and
Sanctions
![]() | Technical Practices and Procedures |
Individual authentication of users
Access controls
Audit trails
Physical security and disaster recovery
Protection of remote access points
Protection of external electronic communications
Software discipline, and
System assessment.
"Recommendation 3: The federal government should work with industry to promote and encourage an informed public debate to determine an appropriate balance between the primary concerns of patients and the information needs of various users of health care information."
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:
![]() |
Administrative procedures to guard data integrity, confidentiality, and availability–these are documented, formal practices to manage the selection and execution of security measures to protect data and the conduct of personnel in relation to the protection of data. |
![]() |
Physical safeguards to guard data integrity, confidentiality, and availability–these relate to the protection of physical computer systems and related buildings and equipment from fire and other natural and environmental hazards, as well as from intrusion. Physical safeguards also cover the use of locks, keys, and administrative measures used to control access to computer systems and facilities. |
![]() |
Technical security services to guard data integrity, confidentiality, and availability–these include the processes that are put in place to protect and to control and monitor information access, and |
![]() |
Technical security mechanisms –these include the processes that are put in place to prevent unauthorized access to data that is transmitted over a communications network. |
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.
v Guidance on Compliance with HIPAA Transactions and Code Sets After the October 16, 2003 Implementation Deadline
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.
Enforcement Approach
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:
![]() |
Increased external testing with trading partners. |
![]() |
Lack of availability of, or refusal by, the trading partner(s) prior to October 16, 2003 to test the transaction(s) with the covered entity whose compliance is at issue. |
![]() |
In the case of a health plan, concerted efforts in advance of the October 16, 2003 and continued efforts afterwards to conduct outreach and make testing opportunities available to its provider community. |
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.
Working Towards Compliance
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)
What will be the impact of the one-year extension?
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.
Does the extension affect the compliance date for the HIPAA privacy standards?
No, the compliance date for the privacy standards is still April, 2003 or, for small health plans, April 2004.
Can small health plans get an extension to their current compliance date of October, 2003?
No, the compliance date for small plans does not change.
Do all covered entities automatically get an extension?
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.
Why didn’t Congress just give everyone 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.
Is HHS going to actually review and approve all these compliance extension plans? Will some be denied?
The law does not require approval or disapproval of plans. Submission of an extension plan is sufficient to secure the one-year extension.
When will the model compliance extension form be available?
The form will be available by March 31, 2002.
Where can I get a copy of the form? Do I have to use the form, or can I submit a compliance plan in another format?
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.
How extensive will the model compliance extension form be?
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.
My organization has a very detailed, voluminous compliance plan – are we supposed to submit the whole thing?
No. The compliance extension form will ask only for summary information from your detailed plan. You do not need to send other information.
Can I file the compliance extension form electronically?
Yes, we will encourage electronic filing of compliance extension plans, although we will also accept plans submitted on paper.
What will be the application deadline for a delay?
Covered entities must submit their compliance extension plans by October15, 2002.
Where should I send my completed compliance extension form?
Please do not submit requests at this time. Instructions will be issued that will explain how to submit compliance extension plans.
How will one covered entity know whether another covered entity with which it does business has submitted a plan?
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.
I believe I will be fully compliant by October, 2002. However, I know that some of my trading partners are requesting extensions and will continue to use nonstandard formats after that date. Do I need to submit a compliance extension plan so that I can continue to communicate with these partners using nonstandard transactions?
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.
Can a plan require its network providers to move to standard transactions before October 16, 2003?
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.
What will be done with the information I provide?
ASCA requires that a sample of the plans will be provided to the National Committee on Vital and Health Statistics (NCVHS), an advisory committee to the Secretary of Health and Human Services. The NCVHS will review the sample to identify common problems that are complicating compliance
activities, and will periodically publish recommendations for solving the problems.Will the information I provide be made public?
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.
How does the delay affect Medicare implementation activities?
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.
When will Medicaid Agencies begin testing compliant transactions with their trading partners?
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.
Do software vendors need to file for an extension?
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.
Should covered entities discontinue testing until 2003?
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.
ASCA allows the Secretary of HHS to exclude covered entities from the Medicare program if they do not submit a compliance extension plan or achieve compliance by October, 2002. Will every such covered entity be excluded?
HHS will be publishing proposed regulations to address this new exclusion authority.
Doesn’t the law also require Medicare claims to be submitted electronically after October, 2003?
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.
v Electronic Transaction Standards
Why have national standards for electronic health care transactions been adopted and why are they required?
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.
What health care transactions are required to use the standards under this regulation?
As required by HIPAA, the Secretary of Health and Human Services is adopting standards for the following administrative and financial health care transactions:
![]() |
Health claims and equivalent encounter information. |
![]() |
Enrollment and disenrollment in a health plan. |
![]() |
Eligibility for a health plan. |
![]() |
Health care payment and remittance advice. |
![]() |
Health plan premium payments. |
![]() |
Health claim status. |
![]() |
Referral certification and authorization. |
![]() |
Coordination of benefits. |
Standards for the first report of injury and claims attachments (also required by HIPAA) will be adopted at a later date.
Who is required to use the standards?
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 a health plan does not perform a transaction electronically, must it implement the standard?
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.
When will the standards become effective?
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.
Where did these standards come from? Did the Federal Government create them?
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).
What standards were chosen?
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).
Do these standards apply to transactions sent over the Internet?
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.
Do I have to use standard transactions when conducting business inside my corporate boundaries?
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.
![]() |
Question 1: Is the transaction initiated by a covered entity or its business associate? If no, the standard need not be used. |
![]() |
Question 2: Is the transaction one for which the Secretary had adopted a standard? If yes, the standard must be used. If no, the standard need not be used. |
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.
What is the effect on State law?
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.
Are any exceptions allowed?
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.
What does the law require of state Medicaid programs?
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:
![]() |
A national standard for encounter transactions will provide a much-needed method for collecting encounter data on Medicaid beneficiaries enrolled in managed care. Because of the standards, it will be possible to combine encounter data from managed care with similar claims data from fee-for-service, thus enhancing the ability to monitor utilization, costs, and quality of care in managed care and to compare managed care with fee-for-service. |
![]() |
The standard transactions will include methods for electronic exchange of enrollment information between the Medicaid program and private managed care plans enrolling Medicaid beneficiaries. This will reduce administrative costs of exchanging such information and enhance the reliability of such information. |
![]() |
The conversion to national standards provides an opportunity for Medicaid programs to shift to commercial software or clearinghouses and to stop the expensive maintenance of old, customized transaction systems. |
How will the standards be enforced?
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.
How were the standards chosen?
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.
Where can I obtain implementation guides for the standards?
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.
How can the standards be changed?
The Secretary has designated six organizations that have agreed to serve as Designated Standards Maintenance Organizations (DSMOs). The DSMOs are:
![]() |
Accredited Standards Committee X12 |
![]() |
The Dental Content Committee |
![]() |
Health Level Seven |
![]() |
National Council for Prescription Drug Programs |
![]() |
National Uniform Billing Committee |
![]() |
National Uniform Claim Committee |
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.
Does the law require physicians to buy computers?
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.
How will the standards affect data stored in my system?
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.
Can health plans require changes or additions to the standard claim?
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.
Should health plans publish companion documents that augment the information in the standard implementation guides for electronic transactions?
Additional information may be provided within certain limits.
Electronic transactions must go through two levels of scrutiny:
![]() |
Compliance with the HIPAA standard. The requirements for compliance must be completely described in the HIPAA implementation guides and may not be modified by the health plans or by the health care providers using the particular transaction. |
![]() |
Specific processing or adjudication by the particular system reading or writing the standard transaction. Specific processing systems will vary from health plan to health plan, and additional information regarding the processing or adjudication policies of a particular health plan may be helpful to providers. |
Such additional information may not be used to modify the standard and may not include:
![]() |
Instructions to modify the definition, condition, or use of a data element or segment in the HIPAA standard implementation guide. |
![]() |
Requests for data elements or segments that are not stipulated in the HIPAA standard implementation guide. |
![]() |
Requests for codes or data values that are not valid based on the HIPAA standard implementation guide. Such codes or values could be invalid because they are marked not used in the implementation guide or because they are simply not mentioned in the guide. |
![]() |
Change the meaning or intent of a HIPAA standard implementation guide. |
Could companion documents from health plans define cases where the health plan wants particular pieces of data used or not used?
The health plan must read and write HIPAA standard transactions exactly as they are described in the standard implementation guides. The only exception would be if the guide explicitly gives discretion regarding a data element to a health plan. For claims and most other transactions, the receiver must accept and process any transaction that meets the national standard. This is necessary because multiple health plans may be scheduled to receive a given transaction (e.g., a single claim may be processed by multiple health plans).
For example: Medicare currently instructs providers to bill for certain services only under certain circumstances. Once HIPAA standard transactions are implemented, Medicare will have to forego that policy and process all claims that meet HIPAA specifications. This does not mean that Medicare, or any other health plan, has to change payment policy. Today, Medicare would refuse to accept and process a bill for a face lift for cosmetic purposes only. Once the HIPAA standards are implemented, Medicare will be required to
accept and process the bill, but still will not pay for a face lift that is purely for cosmetic purposes.May health plans stipulate the codes or data values they are willing to accept and process in order to simplify implementation?
The simplest implementation is the one that is identical to all others. If the standard adopted stipulates that HCPCS codes will be used to describe procedures, then the health plan must abide by the instructions for the use of HCPCS codes. A health plan could refuse a code that was not applied in accordance with the HIPAA national standard coding instructions, but could not refuse a code properly applied for reasons of policy unrelated to the standard.
For example, if the standard stipulates that the most specific code available must be used, then a health plan would be right to refuse a code that does not meet that criterion. The health plan would need to work with the committee(s) governing the particular coding scheme to have codes adopted that meet its needs.
May health plans stipulate the number of loop iterations or the file sizes they are willing to accept?
Any loop iterations, file sizes, etc. stipulated in the standards must be honored by all players. If any health care electronic data interchange participant cannot live with the numbers stipulated in the HIPAA implementation guides, then the participant needs to work with the implementation guide author(s) to get numbers that all players can live with
For example, there are up to 99 service lines in a professional claim. The provider need not write 99 service lines, but the health plan must have the capability to accept that number when presented. If that is not the right number for all players, it should be changed. But the number identified in the implementation guide must be adhered to.
v Code Set Standards
What Is a Code Set?
Under HIPAA, a "code set" is any set of codes used for encoding data elements, such as tables of terms, medical concepts, medical diagnosis codes, or medical procedure codes. Medical data code sets used in the health care industry include coding systems for diseases, impairments, other health related problems, and their manifestations; causes of injury, disease, impairment, or other health-related problems; actions taken to prevent, diagnose, treat, or manage diseases, injuries, and impairments; and any substances, equipment, supplies, or other items used to perform these actions. Code sets for medical data are required for data elements in the administrative and financial health care transaction standards adopted under HIPAA for diagnoses, procedures, and drugs.
What Code Sets Have Been Adopted as HIPAA Standards?
The Secretary has adopted the following code sets as the standard medical data code sets:
International Classification of Diseases, 9th Edition, Clinical Modification, (ICD-9-CM), Volumes 1 and 2 (including The Official ICD-9-CM Guidelines for Coding and Reporting), as updated and distributed by HHS, for the following conditions:
![]() |
Diseases. |
![]() |
Injuries. |
![]() |
Impairments. |
![]() |
Other health related problems and their manifestations. |
![]() |
Causes of injury, disease, impairment, or other health-related problems. |
International Classification of Diseases, 9th Edition, Clinical Modification, (ICD-9-CM), Volume 3 Procedure
s (including The Official ICD-9-CM Guidelines for Coding and Reporting), as updated and distributed by HHS, for the following procedures or other actions taken for diseases, injuries, and impairments on hospital inpatients reported by hospitals:![]() |
Prevention. |
![]() |
Diagnosis. |
![]() |
Treatment. |
![]() |
Management. |
National Drug Codes (NDC), as updated and distributed by HHS, in collaboration with drug manufacturers, for the following: [Note that Secretary Thompson has indicated in a letter to the NCVHS that HHS will publish an NPRM in the near future proposing to retract the adoption of NDC for all transactions save those for retail pharmacies.]
![]() |
Drugs. |
![]() |
Biologics. |
Code on Dental Procedures and Nomenclature, as updated and distributed by the American Dental Association, for dental services.
The combination of Centers for Medicare & Medicaid Services (formerly known as Health Care Financing Administration) Common Procedure Coding System (HCPCS), as updated and distributed by HHS; and Current Procedural Terminology, Fourth Edition (CPT-4), as updated and distributed by the American Medical Association, for physician services and other health related services. These services include, but are not limited to, the following:
![]() |
Physician services. |
![]() |
Physical and occupational therapy services. |
![]() |
Radiological procedures. |
![]() |
Clinical laboratory tests. |
![]() |
Other medical diagnostic procedures. |
![]() |
Hearing and vision services. |
![]() |
Transportation services including ambulance. |
The Centers for Medicare & Medicaid Services (formerly known as Health Care Financing Administration) Common Procedure Coding System (HCPCS), as updated and distributed by CMS, HHS, for all other substances, equipment, supplies, or other items used in health care services. These items include, but are not limited to, the following:
![]() |
Medical supplies. |
![]() |
Orthotic and prosthetic devices. |
![]() |
Durable medical equipment. |
Can HCPCS Level 3 codes established on a local basis still be used?
No. All local codes will be eliminated. Users that need codes must apply to the appropriate organizations (e.g. CMS for HCPCS codes, the AMA for CPT-4 codes) for national codes.
Where can I get more information about the code sets?
ICD-9-CM: Official version is available on CD-ROM from the Government Printing Office (GPO) at 202-512-1800 or FAX: 202-512-2250. The CD-ROM contains the ICD-9-CM classification and coding guidelines. Versions of ICD-9-CM are also available from several private sector vendors.
CPT-4: Official version is available from the American Medical Association. Versions are also available from several private sector vendors.
HCPCS: Information about HCPCS is available from the CMS by searching their web site at http://cms.hhs.gov.
Code on Dental Procedures and Nomenclature:
Official version is available from the American Dental Association at 800-947-4746.NDC: Official versions of the files are available on the Internet at http://www.fda.gov/cder/ndc/index.htm. NDC codes are also published in the Physicians’ Desk Reference under the individual drug product listings and "How supplied." The supplements are available quarterly on diskette from the National Technical Information Service at 703-487-6430.