Standards for Electronic Transactions and Code Sets

III. Analysis of, and Responses to, Public Comments on the Proposed Rule

In response to the publication in the Federal Register of the proposed rule on May 7, 1998, we received approximately 17,000 timely public comments. The comments came from a wide variety of correspondents including professional associations and societies, health care workers, law firms, third party health insurers, hospitals, and private individuals. We reviewed each commenter’s letter and grouped like or related comments. Some comments were identical, indicating that the commenters had submitted form letters. After associating like comments, we placed them in categories based on subject matter or based on the section(s) of the regulations affected and then reviewed the comments. All comments relating to general subjects, such as the format of the regulations were similarly reviewed.

This process identified areas of the proposed regulation that required review in terms of their effect on policy, consistency, or clarity of the rules.

We present comments and responses generally in the order in which the issues appeared in the May 1998 proposed rule.

General - Comment Period

Comment: We received several comments that stated the 60-day comment period was too short. It was stated that the period did not take into account the highly detailed, technical review of the thousands of pages in the implementation specifications that was required in order to comment in a meaningful way.

Response: We disagree. We understand the difficulty in reviewing a rule of this complexity. However, we met our notice requirements for the length of the comment period and made every effort to ensure that the proposed rule was readily accessible to the public (for example, the proposed rule was published in the Federal Register and available over the Internet). In addition, we received many comments requesting changes to the implementation specifications, which indicates that the majority of interested parties were able to review all implementation specifications in the 60-day period. If additional changes are necessary, revisions may be made to the standards on an annual basis.

A. Applicability

In subpart A §142.102 we listed the entities that would be subject to the provisions and we discussed under what circumstances they would apply.

Below we discuss the comments concerning applicability.

Comments and Responses on the Applicability of the Regulations

1. Electronically Transmitting Transactions

Proposal Summary: Our proposed rules apply to health plans and health care clearinghouses, as well as any health care provider when transmitting an electronic transaction defined in Subpart A of 45 CFR Part 142.

Comment: Several commenters requested clarification on the applicability provisions. For example, several commenters questioned whether a health plan would be required to accept or send a standard that it does not currently support electronically. Some commenters believe the language allows any entity to submit a standard transaction and expect it to be processed by the receiver even though they do not have a business relationship with each other.

Response: Under the terms of section 1172(a) of the Act, these regulations apply to health plans, health care clearinghouses, and health care providers who transmit any health information in electronic form in connection with a transaction referred to in section 1173(a) of the Act (in other words, “covered entities”). We interpret this provision to mean that by the applicable compliance dates of the regulation, all covered entities must comply with the standards adopted by this regulation. (Covered entities, of course, may comply before the applicable compliance dates.) We do not have the authority to apply these standards to any entity that is not a covered entity. However, we require covered entities to apply many of the provisions of the rule to the entities with whom they contract for administrative and other services related to the transactions, as it would be inconsistent with the underlying statutory purpose to permit covered entities to avoid the Act’s requirements by the simple act of contracting out certain otherwise covered functions.

With respect to health plans, a health plan is required to have the capacity to accept and/or send (either itself, or by hiring a health care clearinghouse to accept and/or send on its behalf) a standard transaction that it otherwise conducts but does not currently support electronically. For example, if a health plan pays claims electronically but historically performed enrollment and disenrollment functions in paper, the health plan must have the capacity to electronically perform enrollment and disenrollment as well as claims payment as standard transactions by the applicable compliance date of the regulation.

Also, in response to the public’s need for clarification of the applicability of the HIPAA administrative simplification provisions (45 CFR subtitle A, subchapter C) to covered entities, we revisited the applicability provision with respect to health care providers. In the proposed rule, we proposed that the administrative simplification provisions would apply to a health care provider when transmitting an electronic transaction (63 FR 25305). (We note that this language differed somewhat from the statute, which states that the HIPAA administrative simplification provisions apply to “a health care provider who transmits any health information in electronic form in connection with a transaction” referred to in subchapter C.)

We phrased the applicability section in the proposed rule as we did in an effort to convey the message that these regulations do not require a health care provider to transmit transactions electronically; thus, a health care provider remains free to use paper media. These regulations do require, however, that a health care provider who uses electronic media to transmit any health information in connection with a transaction referred to in 45 CFR subtitle A, subchapter C, must do so in compliance with the regulations. We do not believe that the proposed applicability language as it applied to health care providers adequately communicated this message. Thus, after reevaluating the proposed approach, we believe that the best approach is to have the applicability text mirror the statute and use §162.923 (Requirements for Covered Entities) as the vehicle to detail the specific requirements for covered health care providers.

In addition, we provide the following as examples of types of health care provider behavior that are permissible under the regulations. For instance, a health care provider may send an electronic health care claim or equivalent encounter information standard transaction for Patient A to health plan Z, and may send a paper claim for Patient B to health plan Z. A health care provider may also send an electronic health care claim or equivalent encounter information standard transaction to health plan S and then send paper claims to health plan T.

In regard to the second comment, while we interpret HIPAA to mean that a health plan cannot refuse to conduct a transaction because it is a standard transaction, we do not believe that use of standard transactions can create a relationship or liability that does not exist. For example, a health plan cannot refuse to accept a claim from a health care provider because the health care provider electronically submits the standard transaction. However, the health plan is not required to pay the claim merely because the health care provider submitted it in standard format, if other business reasons exist for denying the claim (for example, the service for which the claim is being submitted is not covered). This rule does not require a health care provider to send or accept an electronic transaction.

2. Various Technologies

Proposal Summary: Entities that offer on-line interactive transmission of the transactions described in section 1173(a)(2) of the Act, would have to comply with the standards (63 FR 25276). For example, the Hypertext Markup Language (HTML) interaction between a server and a browser by which the data elements of a transaction are solicited from a user would not have to use the standards, although the data content must be equal to that required for the standard. Once the data elements are assembled into a transaction by the server, the transmitted transaction would have to comply with the standards.

a. Comment: Several comments recommended that electronic transmissions should be classified as “computer to computer without human interaction” (i.e., batch and fast batch transmissions) and be subject to the national standards. They also recommended that transmissions involving browser to server (Internet, Extranet, HTML, Java, ActiveX, etc.), direct data entry terminals (dumb terminals), PC terminal emulators, point of service terminals (devices similar in function to credit card terminals), telephone voice response systems, “faxback” systems, and any real-time transactions where data elements are directly solicited from a human user, be classified as “person to computer” transmissions. Moreover, “person to computer” transmissions should be supplemental to the national standards, but the data content of these transmissions should comply with the HIPAA electronic standards as they apply to data content.

Several commenters questioned whether HIPAA requires a health plan to support “person to computer” methods. Several commenters suggested that we should only except HTML web sites from the transaction standards if the web browser is used in HTML passive mode without plug-ins or programmable extensions and that the response times must be the same or faster than that of the HIPAA electronic standards.

Commenters also recommended that we permit the use of a proprietary format for web-based transactions if the transactions are sent to an entity’s in-house system for processing, and the entity’s web browser is under the control of a back-end processor, as well as part of the same corporate entity, and does not serve other back-end processors. They recommended that the HIPAA standards be used if the transactions are sent externally (outside of that entity’s system) for processing, and the entity’s web browser is under a contract with a back-end processor that is not under the same corporate control, and that serves more than one back-end processor.

Response: We are pleased that commenters support the use of the national standards for electronic transactions since this outcome is required by section 1173 of the Act. For each designated transaction, these standards specify the format, the data elements required or permitted to structure the format, and the data content permitted for each of the data elements, including designated code sets where applicable.

Certain technologies present a special case for the use of standard transactions. We proposed that telephone voice response, “faxback”, and Hyper Text Markup Language (HTML) interactions would not be required to follow the standard. We have since reevaluated this position in light of the many comments on this position and on developments in the EDI industry which continue to expand the options in this area. We have decided that, instead of creating an exception for these transmissions, we will recognize that there are certain transmission modes in which use of the format portion of the standard is inappropriate. However, the transaction must conform to the data content portion of the standard. The “direct data entry” process, using dumb terminals or computer browser screens, where the data is directly keyed by a health care provider into a health plan’s computer, would not have to use the format portion of the standard, but the data content must conform. If the data is directly entered into a system that is outside of the health plan’s system, to be transmitted later to the health plan, the transaction must be sent using the full standard (format and content). We have included this clarification in §162.923 (Requirements for Covered Entities).

3. Atypical Services

Proposal Summary: Transactions for certain services that are not normally considered health care services, but which may be covered by some health plans, would not be subject to the standards (63 FR 25276). These services would include, but not be limited to: nonemergency transportation, physical alterations to living quarters for the purpose of accommodating disabilities, and case management. Other services may be added to this list at the discretion of the Secretary.

Comment: We received comments both for and against subjecting transactions for certain services to the transaction standards. Some commenters recommended that any service that could be billed to a health plan be required to comply with the standards in order to avoid the need to maintain alternate systems. However, other commenters argued that certain Medicaid services are not insured by any other program, thus, use of the standard is unnecessary.

Several commenters supported not subjecting these services to the standard, except for case management, arguing that a more precise definition of case management needs to be developed. Other commenters stated that case management is considered a health care service by many health plans and health care providers, and reported using standard codes.

We received suggestions for additional services that should not be subject to the standards. Suggestions included home and community based waiver services provided under the Medicaid program and abbreviated transactions between State agencies, for example, claims between a State health service and a State Medicaid agency.

Response: We agree with commenters that case management is a health care service since it is directly related to the health of an individual and is furnished by health care providers. Case management will, therefore, be subject to the standards.

We recognize that the health care claim and equivalent encounter information standard, with its supporting implementation specification, is capable of supporting claims for atypical services. However, requiring all services potentially paid for by health plans to be billed using the standards would lead to taxi drivers, auto mechanics and carpenters to be regulated as health care providers. Instead, we will use our definition of "health care" found at 160.103 to determine whether a particular service is a "health care" service or not. Services that are not health care services or supplies under this definition are not required to be claimed using the standard transactions. Thus, claims for non-emergency transportation or carpentry services for housing modifications, if submitted electronically, would not be required to be conducted as standard transactions. As noted above, the standards do support such claims and a health plan may choose to require its atypical service providers to use the standards for its own business purposes.

Those atypical services that meet the definition of health care, however, must be billed using the standard if they are submitted electronically. If there are no specific codes for billing a particular service (for example, there is not yet an approved code set for billing for alternative therapies), or if the standard transactions do not readily support a particular method of presenting an atypical service (for example, roster billing for providing immunizations for an entire school or nursing facility), the health care service providers are urged to work with the appropriate Designated Standard Maintenance Organizations (DSMOs) to develop modifications to the standard and implementation specifications. (See “I. New and Revised Standards” in this section of the preamble for a discussion of the DSMOs.)

We disagree with the proposal that home and community based waiver services should have a blanket exemption from the administrative simplification standards. First, Congress explicitly included the Medicaid programs as health plans that are subject to the administrative simplification standards. Second, these waiver programs commonly pay for a mix of health care and non-health care services. State Medicaid agencies with home and community based waivers are not exempt from these standards for transactions relating to health care services or supplies.

4. Conducting the Transactions

Proposal Summary: If a person conducts a transaction (as defined in §160.103) with a health plan as a standard transaction, the following apply:

1. The health plan may not refuse to conduct the transaction as a standard transaction.
2. The health plan may not delay the transaction or otherwise adversely affect, or attempt to adversely affect, the person or the transaction on the ground that the transaction is a standard transaction.

Comment: Some commenters questioned what was meant by “delay” of a standard transaction. They questioned what methods (i.e., batch, online, etc.) a health plan must provide to support receipt and submission of standard transactions. The proposed rule did not define the term “delay” nor specify the time frame within which a health plan is required to act when it receives a standard transaction.

Several commenters recommended the rule encompass all entities that might be conducting an electronic transaction with a health plan and that there be further clarification of what an unreasonable delay would be. It was also recommended that the regulation should apply to a health care provider, not a person that conducts an “electronic” transaction.

Response: Section 1175 of the Act prohibits a health plan from delaying a standard transaction, or otherwise adversely affecting, or attempting to adversely affect any person desiring to conduct a transaction referred to in § 1173 (a)(1) of the Social Security Act or the transaction on the ground that the transaction is a standard transaction. We interpret this provision to mean that there should be no degradation in the transmission of, receipt of, processing of, and response to a standard transaction solely because the transaction is a standard transaction. Thus, health plans must process standard transactions from any person, including, but not limited to, covered entities, in the same time frame in which they processed transactions prior to implementation of HIPAA. They also may not provide incentives that will discourage (i.e., adversely affect) the use of standard transactions.

In §162.923 we have included requirements for all covered entities and in §162.925 we have provided additional requirements for health plans.

5. Role of Health Care Clearinghouses

Proposal Summary: Health care clearinghouses would be able to accept nonstandard transactions for the sole purpose of translating them into standard transactions for sending customers and would be able to accept standard transactions and translate them into nonstandard formats for receiving customers (63 FR 25276).

Comment: Several commenters believe health care clearinghouses are excepted from accepting the standards. Other commenters believe that allowing health care providers to use a health care clearinghouse will negate administrative simplification. There was also concern that entities may designate themselves as a health care clearinghouse to avoid compliance.

Several commenters also requested that we clarify who is responsible for health care clearinghouse costs and state that contracts cannot require health care providers to use nonstandard formats.

Response: First, we clarify that a health care clearinghouse is a covered entity and must comply with these rules. Accordingly, all transactions covered by this part between health care clearinghouses must be conducted as standard transactions. However, the statute permits a covered entity to submit nonstandard communications to a health care clearinghouse for processing into standard transactions and transmission by the health care clearinghouse as well as receive standard transactions through the health care clearinghouse.

If a covered entity (for example, a health care provider) uses a health care clearinghouse to submit and receive nonstandard/standard transactions, the health care clearinghouse is the covered entity’s business associate. If a health plan operates as a health care clearinghouse, or requires the use of a health care clearinghouse, a health care provider may submit standard transactions to that health plan through the health care clearinghouse. However, the health care provider must not be adversely affected, financially or otherwise, by doing so. (For example, the costs of submitting a standard transaction to a health plan’s health care clearinghouse must not be in excess of the costs of submitting a standard transaction directly to the health plan.)

In §162.915, we clarify what a trading partner agreement that a covered entity enters into may not do. Section 162.923 specifies that a covered entity conducting a transaction covered under this rule with another covered entity (or within the same covered entity) using electronic media must conduct the transaction as standard transaction, with an exception for direct data entry. Section 162.925 makes it clear that a health plan may not offer an incentive for a health care provider to conduct a transaction covered by this part under the direct data entry exception.

6. Exception for Transmissions within Corporate Entities

Proposal Summary: Transmissions within a corporate entity would not be required to comply with the standards (63 FR 25276).

Comment: We received many comments regarding excepting transmissions within corporate boundaries and the examples we provided. The comments can be summarized by three questions: (1) What constitutes a “corporate entity” and “internal” communications; (2) can the “internal umbrella” cover the transactions among “corporate” entities; and (3) why should Government agencies be excepted from meeting the standards?

Some commenters attempted to determine the circumstances under which compliance with the standards can be avoided. Generally, these commenters indicated a desire for a very broad definition of “corporate entity.” Some commenters reflected a desire to severely restrict the boundaries or eliminate them altogether. Other commenters asked if particular kinds of data or transactions are required in particular situations.

Response: We proposed to create an exception for transactions within a corporate entity to minimize burden. However, after considering public comment, and further analyzing the implications of the proposed exception, we have decided not to create an exception for standard transactions within a “corporate entity.” First, we have not been able to define “corporate entity” so that the exception would not defeat the rule. The rapid pace of mergers, acquisitions, and dissolutions in the corporate health care world would make such an exception extremely difficult to implement. Equally important, the proposed exception would not have promoted the use of the standard transactions at the health care provider and health plan level. Each health care provider that is owned by or under contract to one or more health plans could be required to use the “in-house” or “non-standard” transactions favored by each health plan, thus negating the benefits of the use of the standards. Finally, our decision to not adopt a corporate entity exception does not impose an additional burden on health plans, because health plans already are required to have the capacity to accept standard transactions from any person. Thus, the fundamental policy is that covered entities must use a standard transaction when transmitting a transaction covered by this part with another covered entity (or within the same covered entity) electronically, regardless of whether the transmission is inside or outside the entity.

We have decided to clarify the description of each transaction to help covered entities determine when the standards must be used. A transaction is now defined in §160.103 as the exchange of data for one of the enumerated specific purposes. In subparts K through R of part 162, we describe each transaction in specific, functional terms. For example, one type of health care claims or equivalent encounter information transaction is the exchange of information between a health care provider and a health plan about services provided to a patient to obtain payment; one type of eligibility for a health plan transaction is the exchange of information between a health provider and a health plan to determine whether a patient is eligible for services under that health plan. Data submissions or exchanges for purposes other than those designated in this regulation are not transactions and therefore do not require use of the standards.

Transactions may be used by both covered entities and other entities. For example, the enrollment and disenrollment in a health plan transaction is most commonly sent by employers or unions, which are not covered entities, to health plans, which are covered entities. The employer may choose to send the transaction electronically in either standard or non-standard format. The health plan, however, must conduct the transaction as a standard transaction when conducting the transaction electronically with another covered entity, with another part of itself, or when requested to do so by any other entity. Moreover, if an employer or other non-covered entity desires to send a transaction as a standard transaction, the health plan may not delay or adversely affect either the sender or the transaction. It is expected that this provision will encourage non- covered entities that conduct the designated transactions with more than one health plan to conduct these transactions as standard transactions.

In general, if a covered entity conducts, using electronic media, a transaction adopted under this part with another covered entity (or within the same covered entity), it must conduct the transaction as a standard transaction. If any entity (covered or not covered) requests a health plan to conduct a transaction as a standard transaction, the health plan must comply. We have provided examples below to assist in determining when a transaction must be conducted as a standard transaction.

Example 1: Corporation K operates a health plan that is a covered entity under these rules. Corporation K owns a hospital which provides care to patients with coverage under Corporation K’s health plan and also provides care to patients with coverage under other health plans. Corporate rules require the hospital to send encounter information electronically to Corporation K identifying the patients covered by the corporate plan and served by the hospital.

A) Must the transmission of encounter data comply with the standards? Both the health plan and the hospital are covered entities. The hospital is a covered entity because it is conducting covered transactions electronically in compliance with its corporate rules. The electronic submission of encounter data satisfies the definition of the health care claims or equivalent encounter information transaction designated as a standard transaction (see §162.1101(b)). Therefore, the submission of this encounter data therefore must be a standard transaction.

B) Must the payments and remittance advices sent from Corporation K’s health plan to the hospital be conducted as standard transactions? Corporation K’s health plan is covered by the definition of “health plan,” the hospital is a covered entity, and the transmission of health care payments and remittance advices is within the scope of the designated transactions (see §162.1601). The health care payments and remittance advices must be sent as standard transactions.

Example 2: A large multi-state employer provides health benefits on a self-insured basis, thereby establishing a health plan. The health plan contracts with insurance companies in seven states to function as third party administrators to process its employees’ health claims in each of those states. The employer’s health plan contracts with a data service company to hold the health eligibility information on all its employees. Each of the insurance companies sends eligibility inquiries to the data service company to verify the eligibility of specific employees upon receipt of claims for services provided to those employees or their dependents.

A) Are these eligibility inquiries activities that must be conducted as standard transactions? In this case, each insurance company is not a covered entity in its own right because it is functioning as a third party administrator, which is not a covered entity. However, as a third party administrator (TPA), it is the business associate of a covered entity (the health plan) performing a function for that entity; therefore, assuming that the covered entity is in compliance, the TPA would be required to follow the same rules that are applicable to the covered entity if the covered entity performed the functions itself. The definition for the eligibility for a health plan transaction is an inquiry from a health care provider to a health plan, or from one health plan to another health plan, to determine the eligibility, coverage, or benefits associated with a health plan for a subscriber. In this case, the inquiry is from one business associate of that health plan to another business associate of that same health plan. Therefore, the inquiry does not meet the definition of an eligibility for a health plan transaction, and is not required to be conducted as a standard transaction.

B) Is an electronic eligibility inquiry from a health care provider to the data service company, to determine whether an employee-patient may receive a particular service, required to be a standard transaction? The health care provider is a covered entity, because it conducts covered electronic transactions. The data service company is the business associate of the employer health plan performing a plan function. Therefore, the activity meets the definition of the eligibility for a health plan transaction, and both the inquiry and the response must be standard transactions.

Example 3: A pharmacy (a health care provider) contracts with a pharmacy benefits manager (PBM) to forward its claims electronically to health plan Z. Under the contract, the PBM also receives health care payment and remittance advice from health plan Z and forwards them to the pharmacy.

A) Must the submission of claims be standard transactions? The pharmacy is a covered entity electronically submitting, to covered entity health plan Z, health care claims or equivalent encounter information, which are designated transactions (see §162.1101), through a business associate, the PBM. The claims must be submitted as standard transactions.

B) Must the explanation of benefits and remittance advice information be sent as a standard transaction? Health plan Z and the health care provider are covered entities conducting one of the designated transactions (see §162.1601). This transaction, therefore, must be conducted as a standard transaction.

Example 4: A State Medicaid plan enters into a contract with a managed care organization (MCO) to provide services to Medicaid recipients. That organization in turn contracts with different health care providers to render the services.

A) When a health care provider submits a claim or encounter information electronically to the MCO, is this activity required to be a standard transaction? The entity submitting the information is a health care provider, covered by this rule, and the MCO meets our definition of health plan. The activity is a health care claims or equivalent encounter information transaction designated in this regulation. The transaction must be a standard transaction.

B) The managed care organization then submits a bill to the State Medicaid agency for payment for all the care given to all the persons covered by that MCO for that month under a capitation agreement. Is this a standard transaction? The MCO is a health plan under the definition of “health plan” in §160.103. The State Medicaid agency is also a covered entity as a health plan. The activity, however, does not meet the definition of a health care claims or equivalent encounter information transaction. It does not need to be a standard transaction.

However, note that the health plan premium payment transaction from the State Medicaid agency to the health plan would have to be conducted as a standard transaction because the State Medicaid agency is a covered entity sending the transaction to another covered entity (the health plan), and the transaction meets the definition of health plan premium payment.

7. Applicability to Paper Transactions and Other Entities

Proposal Summary: Although there are situations in which the use of the standards is not required (for example, health care providers may continue to submit paper claims and employers and other noncovered entities are not required to use any of the standard transactions), we stressed that a standard may be used voluntarily in any situation in which it is not required (63 FR 25276).

a. Comment: The majority of commenters suggested that the transaction standards and their codes sets, in some manner, apply to paper transactions. They suggested that the required data elements in the standard transactions also be required for paper transactions and that any required identifiers also be required for use on paper transactions.

The commenters stated that there could be two consequences if the same data were not required on paper and electronic transactions. First, health plans would have to maintain two systems: one for the processing of electronic claims; and one for the processing of paper claims. The same argument was also applied to identifiers - it was argued that health plans would need to maintain two sets of identifiers: one for paper claims; and one for electronic claims. Second, many health care providers would revert to paper claims if the data requirements were less restrictive than those for electronic claims.

Response: These are powerful arguments from a cost benefit standpoint. While the HIPAA statute provides the Secretary with the authority to declare these standards applicable to all transactions, including those on paper, we chose at this point to focus on standards for electronic transactions. Most of the paper forms currently in use today cannot accommodate all of the data content included in the standard transactions. This does not prevent health plans from requiring the same data, including identifiers for paper transactions as is required by the HIPAA regulations with respect to electronic transactions.

b. Comment: Several commenters recommended that employers/sponsors who perform EDI should be required to use the standards because they play a critical role in the overall administration of health care. These entities are the major users of the enrollment and disenrollment in a health plan transactions, and are often major payers of health premiums.

Response: The administrative simplification provisions of HIPAA do not require noncovered entities to use the standards, but noncovered entities are encouraged to do so in order to achieve the benefits available from such use. For example, employers and sponsors play a key role in the administrative functions of health care, e.g. the enrollment and disenrollment of individuals in health plans. But because the legislation does not specifically require employers /sponsors to use the transaction standards, we are not extending the requirement to them in the regulation. Health plans are, however, free to negotiate trading partner agreements with employers and sponsors that require the use of standard transactions.

8. Exceptions for State law (Section 1178)

Proposal Summary: The proposed rule did not propose preemption requirements in the regulation text and did not directly request comments on the preemption issue. However, it did set forth a summary of the preemption provision of the Act, section 1178, and, therefore, raised the issue for public comment (63 FR 25274). In response, we received a number of comments regarding the preemption issue, and requesting guidance on how preemption questions will be resolved.

Comment: Many commenters recommended the exception for State law process be delineated or clarified in the final rule. Many commenters stated that exceptions in general should not be granted, saying that this is contrary to the idea of national standards. Other commenters stated exceptions should be discouraged.

Response: The statute clearly states that the Secretary may grant exceptions in certain circumstances. The proposed rule regarding Standards for Privacy for Individually Identifiable Health Information, published in the Federal Register on November 3, 1999 (64 FR 59967), specifically raised the preemption issue. Comments received in response to that proposed rule are being analyzed. We will issue conforming amendments to Part 160 Subpart B when the preemption issues have been resolved in the context of the Standards for Privacy for Individually Identifiable Health Information final rule.

B. Definitions

Comments and Responses Concerning the Definitions

Several definitions in this rule have also been proposed in other HIPAA proposed rules. They may be revised as these other rules are published in final.

1. Code set

Comment: One commenter stated that the definition of code set should be expanded to include factors such as functional status, in order to clarify that a code set is not limited to “medical” terms.

Response: We have defined “code set” very broadly to encompass any set of codes used to encode data elements. Many code sets (such as revenue codes) are nonmedical in nature and are designated within the transaction standards. We are separately designating standards for medical data code sets used in the transaction.

2. Health Care Clearinghouse

Comment: Several commenters requested that the definition of a health care clearinghouse be reworded. Of particular concern was the reference to other entities, such as billing services, repricing companies, etc. Commenters stated the definition would preclude these other entities from using a health care clearinghouse for format translation and data conversion. Several commenters stated health care clearinghouses play roles other than data and format conversion as described in the proposed rule.

Response: If an entity does not perform the functions of format translation and data conversion, it is not considered a health care clearinghouse under our definition. Billing services, for example, are often extensions of a health care provider’s office, primarily performing data entry of health care claims and reconciling the payments received from a health plan. Health care providers may use health care clearinghouses for format translation and other services a health care clearinghouse provides. We agree the definition should be reworded and have revised the definition in §160.103.

3. Health care provider.

Comment: We received several comments requesting clarification on the distinction between billing health care providers and a billing service, as well as clarification on the difference between housekeeping staff and home health aides. Several commenters recommended removal of the word “bills” in the definition. They want the definition to be based on the direct provision of health care and not financial arrangements.

Response: The proposed rule regarding Standard Health Care Provider Identifiers, published in the Federal Register on May 7, 1998 (63 FR 25320) also included the definition of health care provider. Comments received in response to that proposed rule regarding the definition of a health care provider included the comments above, as well as additional comments, and are being analyzed. We believe it is appropriate to address all comments regarding the definition of a health care provider in the final rule for Standard Health Care Provider Identifiers.

4. Health plan

We interpret section 1171(5)(G) of the Act to mean that issuers of long-term care policies are considered health plans for purposes of administrative simplification. We also believe that this provision of the statute gives the Secretary the discretionary authority to include or exclude nursing home fixed-indemnity policies from the definition of a health plan. We specifically requested comments on the impact of HIPAA on the long-term care segment of the health care industry.

a. Comment: The majority who commented on long-term care policies recommended we exclude these policies from the definition of a health plan. Several commenters stated the standard transaction implementation specifications do not meet long term care administrative requirements. The commenters noted that there are fundamental differences between the nature and type of transactions and information required by health plans that pay for long-term care services and those that pay for hospital or physician care. The commenters pointed out that not all long-term care insurance policies pay directly for specific long-term care services. They also stated that the code sets included in the proposed regulation do not adequately meet the needs of long-term care insurance because most documents sent to these companies are narrative “activities of daily living” (ADLs) evaluations, adult “day care” invoices and physician notes.

Moreover, including long-term care only policies within the definition of a health plan would be contrary to the purposes of section 1171 of the Act. It was also stated that for the most part, the long-term care industry is not automated and the costs of developing systems to implement these requirements will be dramatic with little, if any, return. It would increase consumer premiums. Most long-term care claim submissions and payment transactions are between the insured (or a family member) and their insurance companies, without health care providers submitting claims.

One commenter that supported including long-term care policies in the definition of a health plan stated that there have been great strides in the automation of health information in the long-term care industry and it should not be excepted from the standards. Another commenter stated the proposed standards offer the opportunity for all segments of the health care industry to adopt automation and to benefit from such adoption. The standards provide long-term care health care providers with a single method that can be exchanged with all health plans. The commenter stated it would be an unfortunate precedent to except segments of the health care industry from these rules.

Response: The arguments both for and against inclusion of long-term care policies have merit. Since some long term care health care providers bill Medicaid using the UB92, it appears that standard transactions and code sets could be used by long-term care health care providers to bill health plans. In addition, we agree that movement by the industry to these electronic standards would create long term benefits including decreased administrative costs.

We interpret the statute as authorizing the Secretary to exclude nursing home fixed-indemnity policies, not all long-term care policies, from the definition of “health plan,” if she determines that these policies do not provide “sufficiently comprehensive coverage of a benefit” to be treated as a health plan (see section 1171 of the Act). We interpret the term “comprehensive” to refer to the breadth or scope of coverage of a policy. “Comprehensive” policies would be those that cover a range of possible service options. Since nursing home fixed indemnity policies are, by their own terms, limited to payments made solely for nursing facility care, we have determined that they should not be included as health plans for the purposes of this regulation. The Secretary has, therefore, determined that only nursing home fixed-indemnity policies should be excluded from the definition of “health plan.” Issuers of all other long-term care policies are considered to be health plans under this rule.

b. Comment: Several commenters recommended that property and casualty insurance health plans and workers’ compensation health plans be included in the definition of a health plan. It was stated that we should not arbitrarily exclude certain health plans. It was also stated that exclusion will cause undue hardship on health care providers of those specialities that most frequently deal with these health plans, such as orthopedic specialists. It was questioned whether the Bureau of Prisons or state correctional facilities are included in this definition, since they provide or pay for the cost of medical care.

Another commenter stated that if State Workers’ Compensation Programs are allowed to operate with different rules (as they do now) health care providers will be required to maintain multiple systems to accommodate the many variations. Consequently, administrative simplification will not achieve the desired cost savings.

Response: We recognize that non-HIPAA entities such as workers’ compensation programs and property casualty insurance accept electronic transactions from health care providers, however, the Congress did not include these programs in the definition of a health plan under section 1171 of the Act.

The statutory definition of a health plan does not specifically include workers’ compensation programs, property and casualty programs, or disability insurance programs, and, consequently, we are not requiring them to comply with the standards. However, to the extent that these programs perform health care claims processing activities using an electronic standard, it would benefit these programs and their health care providers to use the standard we adopt.

We believe that prisons do not fall within this definition of health plan, as prisons are not “individual or group plans” established for the purpose of paying the cost of health care.

c. Comment: We received two requests to clarify that limited scope dental and vision health plans are not subject to the rule. It was stated that the proposed rule did not specifically indicate that the standards are applicable to these health plans. The limited scope dental health plans provide for annual maximum benefits generally in the $1000-$2000 range and annual benefit payments under limited scope vision health plans rarely exceed a few hundred dollars. The commenters noted that consumers can afford presently to pay for the cost of the annual benefit payments, but if health plans must implement these standards, they will most likely pass on the costs associated with this burden to their enrollees, causing many consumers to drop their coverage.

Response: We believe limited scope dental health plans and limited scope vision health plans meet the definition of health plan and, thus, they are subject to the requirements of this rule. The Congress did not give the Secretary the discretion to treat these health plans differently than other health plans. If a health plan believes it would be cost prohibitive to implement the standards, it has the option of using a health care clearinghouse to transmit and receive the standard transactions.

5. Small Health Plan

Comment: One commenter requested we clarify how the figure for the number of participants for a small health plan was determined. For instance, is an individual insured in a health plan for one month considered a participant for that year? Would twelve different people insured for one month each in a single year be considered a participant? Another commenter questioned why small health plans are being given an extra 12 months to implement the standards.

Response: In the proposed rule, we stated that a small health plan means a group health plan or individual health plan with fewer than 50 participants. It has come to our attention that the Small Business Administration (SBA) promulgates size standards that indicates the maximum number of employees or annual receipts allowed for a concern (13 CFR 121.105) and its affiliates to be considered “small.” The size standards themselves are expressed either in number of employees or annual receipts (13 CFR 121.201). The size standards for compliance with programs of other agencies are those for SBA programs which are most comparable to the programs of such other agencies, unless otherwise agreed by the agency and the SBA (13 CFR 121.902). With respect to the insurance industry, the SBA has specified that annual receipts of $5 million is the maximum allowed for a concern and its affiliates to be considered small (13 CFR 121.201). Consequently, the definition of small health plan has been amended to be consistent with SBA requirements. As such, we need not address the definition of participants for purposes of small health plans.

Small health plans must implement the standards no later than 36 months after adoption under section 1175 of the Act.

6. Standard

Comment: One commenter stated the proposed rule dramatically changed the definition of standard. The commenter stated the new definition implies that any and all standards promulgated by an ANSI SSO or HHS automatically become a standard, whereas under the Act, only the Secretary can specify, establish, or adopt standards. The commenter recommended the definition under the Act stay the same.

Response: We agree that only the Secretary may adopt a standard under the Act. Because the statutory definition of the term “standard” is ambiguous, we are adopting a broader definition to accommodate the varying functions of the specific standards proposed in the other HIPAA regulations. We have revised the definition in §160.103 to clarify this, and have also added a definition for standard transaction in §162.103 for further clarification.

7. Transaction

Comment: Several commenters recommended we amend the transaction definition to clarify each transaction.

Response: We have provided clarification in the definitions of each transaction in subparts K through R.

Additional Definitions

Comment: We received comments requesting that we define the terms “sponsor,” “third party administrator,” “trading partner agreement,” and “health claims attachments.”

Response: We have included a definition for trading partner agreement in §160.103. In this final rule, we are defining only terms used in the regulations text, therefore, we are not providing definitions for “sponsor” or “third party administrator.” In the future, we intend to publish a proposed rule that defines health claims attachment.

We have added definitions to parts 160 and 162 that were not part of the proposed rule. In order to clarify the applicability and scope of this rule, we have added definitions for “covered entity,” “trading partner agreement,” and “workforce” to part 160, and definitions for “direct data entry” and “electronic media” to part 162.

We have added a definition for “business associate” to part 160 in order to distinguish those functions a covered entity chooses other entities to perform on its behalf (making the other entity a business associate of the covered entity) from the functions of other types of agents. These other types may have differing meanings in different situations (for example, insurance agent).

To aid in the articulation of the process by which standards are adopted and changed, we have added definitions for “compliance date,” “implementation specification,” “modify” and “standard setting organization” to part 160, and definitions for “code set maintaining organization,” “designated standard maintenance organization (DSMO),” and “maintenance” to part 162.

We added a definition for “standard transaction” to part 162 to complement the definitions of “standard” and “transaction,” which were proposed and, in the case of standard, revised as discussed earlier in this preamble. And, in order to enumerate as many facets of a standard transaction as possible, we have added definitions for “data condition,” “data content,” “data element,” “data set,” “descriptor,” “format,” “maximum defined data set,” and “segment” to part 162. These definitions should help to make clear the components of a standard transaction.

We also made several clarifications with respect to the definition of “health plan” (§160.103). For purposes of defining the various health plans that are considered health plans for purposes of the regulation, we added the word “issuer” to Medicare supplemental policy, and long-term care policy. We included the word "issuer" when referring to long-term care policies, because policies themselves are not entities subject to the statute. Rather, it is the issuers of long-term care policies that are subject to the statute. We also added the SCHIP program, because it is a health plan under section 4901 of the Balanced Budget Act of 1997 (Public Law 105-33) and meets the statutory criteria for a health plan.

We are adding a definition of “state” to §160.103 to clarify its meaning with regard to the Federal programs included in the definition of “health plan,” which contain this term.

Several terms were in the proposed rule but are not included in the final rule. We have reconsidered the inclusion of the definition of “medical care.” It has come to our attention that the term “medical care” is easily confused with the term “health care.” Since the term medical care is used in the regulation only in the context of the definition of health plan and its inclusion in the regulation text may cause confusion, we have decided to remove the definition of “medical care” from the final regulation. We note, however, that “medical care” is a statutorily defined term and its use is critical in making a determination as to whether a health plan is considered a “health plan” for purposes of Administrative Simplification. Thus, we do include the statutory cite for “medical care” in the definitions of “group health plan” and “health plan.”

Similarly, we removed the definition of “participant” because it appears only in the context of the definitions of the various types of health plans. As in the case of “medical care,” we embed the statutory cite for the definition of “participant” in the definition of “group health plan.”

Also, the definitions for “ASC X12,” “ASC X12N” were removed because we decided their presence in the regulation did not add to the functionality of the text. We did not receive any comments on the definitions that were removed.

C. Effective Dates and Compliance Dates

1. Effective Dates and Compliance Dates for Specified Standards

The effective date for this final rule is the date that it amends the Code of Federal Regulations (CFR). The current CFR consists of the rules published in the latest CFR volume and any effective amendments published in the Federal Register since the revision of the latest CFR volume. Since the impact is expected to be in excess of $100 million per year, Congress will have 60 days after the date of publication in the Federal Register to revise the rule before it becomes effective. Standards are adopted and implementation specifications are established as of the effective date of this rule.

The compliance dates of this final rule are the dates that covered entities must be in compliance with the rule. The compliance date of this final rule for most covered entities is no later than 24 months after the effective date of this final rule. The compliance date of this final rule for small health plans, however, is no later than 36 months after the effective date of this final rule.

In our proposed rule, we stated that we would include the specific compliance dates in the subpart for each standard (63 FR 25279). The compliance dates in this final rule have been consolidated in §162.900.

Comments and Responses on Effective Dates and Compliance Dates for Specific Standards

Comment: The majority of commenters cited that Y2K initiatives will clash with implementing the HIPAA standards. It was recommended that the implementation date should be delayed until after the year 2000.

Several commenters stated that a 2-year implementation time frame may be inadequate to coordinate new system designs with other health plans and to modify existing systems and contracts. There was concern that the industry cannot convert to the new standards within 2 years.

Several commenters recommended that all health plans have the same time frame with which to comply with the standards of this rule. They noted that a health care provider has no knowledge of whether a health plan is a small or large health plan. It would be very inefficient for a health care provider to maintain two systems for an additional year.

The majority of those who commented on the publication of the final rule recommended that the rules be published in a staggered fashion, specifically the identifiers first, then the transactions. Some also wanted the attachment and security regulations published at the same time the transaction regulation is published. Some commenters also wanted the effective dates for each standard transaction to be staggered. Several commenters recommended publishing an interim final rule allowing for additional comments.

Several commenters generally supported the WEDI recommendation that health care providers not be required by health plans to use any of the standards during the first year after adoption of the standards, and that willing trading partners could implement any or all of the standards by mutual agreement at any time during the 2 year implementation phase (3 years for small health plans). WEDI also recommended that health care providers be given at least 6 months’ notice by a health plan before requiring health care providers to implement the standards.

Response: Section 1175 of the Act dictates that the standards are to be implemented no later than 24 months after adoption (36 months for small health plans).

In the interest of a smooth transition, we encourage health plans not to require health care providers to use the standards specified in subparts K through R during the first year after the effective date of the transactions final rule, although willing trading partners could do so by mutual agreement during that time. We also encourage health plans to give health care providers at least 6 months notice before requiring health care providers to implement a standard transaction. For example, if the effective date of the rule is 8/1/2000 and trading partners have agreed not to implement during the first year, the first implementation date could be 8/1/2001 and health care providers should be notified by 2/1/2001.

2. Effective Dates and Compliance Dates of Modifications

Proposal Summary: In §142.106 (now §160.104), we proposed that if the Secretary adopts a modification to an implementation specification or a standard, the implementation date of the modification (the date by which covered entities must comply with the modification) would be no earlier than the 180th day following the adoption of the modification (the effective date of the final rule in the Federal Register which adopts the modification). The Secretary would determine the actual date, taking into account the time needed to comply due to the nature and extent of the modification. The Secretary would be able to extend the time for compliance for small health plans.

Comments and Responses on Effective Dates and Compliance Dates of Modifications

Comment: Some commenters believed 180 days may not always be enough time to implement a revised standard.

Response: The statute states that the Secretary must permit no “fewer” than 180 days for implementation after adopting a revised standard (i.e., a modification). Depending on the nature of the revision, the minimum time frame of 180 days could be longer. This time frame does not apply to the maintenance of medical code sets and external code sets. The compliance date will be specified by the code set maintaining organization responsible for maintenance changes to that code set.

We will clarify the terms modification and maintenance. In the transactions context, when a change is substantial enough to justify publication of a new version of an implementation specification, this change will be considered to be a modification. Such a change must be adopted by the Secretary through regulation. Maintenance is the activities necessary to support the use of a standard, including technical corrections to an implementation specification, and enhancements, additions, or deletions to a data code set. These changes could be non-substantive or error correction. Public comment and notification is required as part of the normal, ANSI- accredited standards development process, but regulatory action would not be required for maintenance as we have defined it. For example, this final rule adopts the ASC X12N 278 - Health Care Services Review--Request for Review and Response, Version 4010, May 2000 as the standard for the referral certification and authorization transaction. Error corrections or addendums to Version 4010, May 2000, would constitute maintenance to this standard and there would be no regulatory action. Changes requiring a new version, or an updated edition of Version 4010 (for example, moving from Version 4010, May 2000 to Version 4010, October 2001) would constitute a modification to this standard and would be adopted through regulatory action.

D. Data Content

Proposal Summary: We proposed standard data content for each adopted standard. Information that would facilitate data content standardization, while also facilitating identical implementations, would consist of implementation specifications, data conditions, data dictionaries, and the standard code sets for medical data that are part of this rule. Data conditions are rules that define the situations when a particular data element or segment can or must be used.

It is important to note that all data elements would be governed by the principle of a maximum defined data set. No one would be able to exceed the maximum defined data set in this rule. This principle applies to the data elements of all transactions.

Comments and Responses on Data Content

Comment: The majority of commenters supported the concept of a maximum defined data set; however, there was some confusion on what we were proposing.

Several commenters believed we were requiring health care providers to always send the transaction with the maximum data possible. They stated that health care providers and health plans will pay excessively for unused data that is transmitted. Concern was also expressed that health plans would have to store coordination of benefits (COB) information if it is submitted, even though they do not perform COB. Several commenters suggested that health plans be allowed to reject a transaction because it contains information they do not want.

One commenter recommended that the maximum defined data set be the full set of data available in the implementation specifications, not the addendum in the proposed rule.

A few commenters wanted to expand the concept of a maximum defined data set to include code sets, modifiers, narrative descriptions, guidelines and instructions applicable to codes sets, as well as an additional category for “usage” in the implementation specifications, “not required unless specified by a contractual agreement.” Several commenters wanted trading partners to be able to agree on which non-required data will be used between them.

One commenter suggested a “minimum” data set principle be applied. If a submitter sends a minimum data set, the receiver cannot reject it as incomplete. Again, the commenter believed we were implying that a submitter must send the maximum every time, in order to assure acceptance of the transaction.

Response: We wish to clarify the maximum defined data set concept. A maximum defined data set contains all of the required and situational data elements possible in a standard transaction. For each standard transaction there are situational data elements that are both relevant to the particular transaction and necessary to process it; there are also situational data elements that an entity may include in a transaction, but does not need to include, in order for the transaction to be processed. A required data element is always required in a transaction. A situational data element is dependent on the written condition in the implementation specification that describes under which circumstances it is to be provided. The maximum defined data set is based on the implementation guides and not the addendum in the proposed rule. The maximum defined data set also includes the applicable medical and nonmedical code sets for that transaction. Some code sets, e.g., HCPCS and CPT-4, include special codes referred to as “modifiers.” Modifiers are included in the concept of maximum defined data set. The maximum defined data set does not include operational guidelines or instructions for every code set.

We note that if an entity follows the implementation specification and the conditions in the implementation specification for each transaction, the entity will only be supplying the minimum amount of data elements necessary to process a transaction (required data elements and relevant situational data elements); the entity will not be supplying possible but unnecessary situational data elements.

In addition, we note that the intent behind the maximum defined data set was to set a ceiling on the nature and number of data elements inherent to each standard transaction and to ensure that health plans did not reject a transaction because it contained information they did not want. For example, if an implementation specification defines a health care claim or equivalent encounter information transaction as having at most 50 specific data elements, a health plan could not require a health care provider to submit a health care claim or encounter transaction containing more than the 50 specific data elements as stipulated in the implementation guide. (A health plan may, however, request additional information through attachments.)

While operational guidelines or instructions are not included in the concept of a maximum defined data set, we agree that standardization of these code set guidelines is highly desirable and beneficial. We reviewed the available guidelines to determine which should be adopted as implementation specifications and have found that there are also many current practical barriers to achieving such standardization. For example, we recognize that the operational guidelines for some code sets required for use in the designated transactions are more complete than others. Also, objective, operational definitions for most codes are not available and the level of detail varies widely from code to code. In addition, the processes for developing guidelines and instructions are typically not open and include limited participation compared to the code development processes. However, where such guidelines exist and are universally accepted, we name them as part of the standard. Therefore, we adopt the Official ICD-9-CM Guidelines for Coding and Reporting as maintained and distributed by the Department of Health and Human Services (§162.1002). Additionally, we received many public comments in support of this action. We do not name guidelines for other code sets.

With respect to COB, if a health plan electronically performs COB exchange with another health plan or other payer, then it must store the COB data necessary to forward the transaction to that health plan or other payer.

In addition, we disagree with commenters that we should add a new “usage” statement, “not required unless specified by a contractual agreement,” in the implementation guide. We believe that the usage statement would have the same effect as allowing trading partners to negotiate which conditional data elements will be used in a standard transaction. Each health plan could then include different data requirements in their contracts with their health care providers. Health care providers would then be required to use a variety of guidelines to submit transactions to different health plans. This would defeat the purpose of standardization.

E. Availability of Implementation Specifications

Proposal Summary: We provided the addresses and telephone numbers for a person to obtain the implementation specifications for the proposed standards.

Comments and Responses on Implementation Specifications and Their Availability

1. Comment: One commenter suggested that the X12N (the ASC X12 subcommittee chartered to develop electronic standards specific to the insurance industry) implementation specifications under HIPAA must be flexible to permit businesses to customize their EDI process. It was stated the implementation specifications do not allow flexibility between trading partners.

Response: We disagree. Allowing flexibility would result in non-standard implementation of the transactions. The X12N implementation specifications under HIPAA, adopted in this final rule, are all version 4010. If businesses customize implementations of 4010, the health care industry would have hundreds of different implementations of the same transaction.

2. Comment: One commenter recommended we include the following language: “In addition, a set of NCPDP standards contains all of the approved standards and implementation specifications. For an additional fee, the data dictionaries are available.”

Response: We are aware that data dictionaries are available and that there is a charge separate from the membership fee for them. We do not believe this needs to be included in the final rule, since this information is available through the NCPDP web site.

F. Proposed Requirements Stated in Each Subpart

In each subpart setting forth a standard or standards, we stated which entities had to use the standard(s), the effective dates for implementation, and that we are incorporating implementation specifications (where applicable) by reference.

Comments and Responses on Provisions Appearing in Each Subpart

1. Code Set Standards

Proposal Summary: We proposed in subpart J the following: In § 142.1002 (now §162.1000), we stated that health plans, health care clearinghouses, and certain health care providers would have to use the diagnosis and procedure code sets as prescribed by the Secretary for electronic transactions. The proposed standard medical code sets of these diagnosis and procedure code sets were identified in the preamble, and the implementation specifications for the transaction standards in part 142 (now part 162), Subparts K through R, specified which of the standard medical data code sets should be used in individual data elements within those transaction standards.

In §142.1004, we specified that the code sets in the implementation specification for each transaction standard in part 142, subparts K through R, would be the standard for the coded nonmedical data elements present in that transaction standard.

In § 142.1010, the requirements sections of part 142, subparts K through R, specified that those who transmit electronic transactions covered by the transaction standards must use the appropriate transaction standard, including the code sets that are required by that standard. These sections would further specify that those who receive electronic transactions covered by the transaction standards must be able to receive and process all standard codes.

We proposed code sets for various types of services and diagnoses.

Comments and Responses on Proposed Standards for Code Sets and Requirements for Their Use

Proposed Code Sets

a. Version Control

Comment: The majority of commenters stated that we should have a clearer requirement for version control, that is, we should require an electronic transaction to use the version of each applicable code set that is valid at the time the transaction is initiated. A common schedule should be established (for example, calendar year) for conversion to new versions of all standard code sets. A few commenters indicated that there should be an overlap period in which both last year's and this year's codes are accepted to accommodate resubmission or subsequent transfer of claims initiated in the prior year.

Many commenters said that HHS should maintain a consolidated list of the current accepted versions of standard code sets and make this list available to the public, e.g., on the Web. Several commenters indicated that all of the code sets themselves should be available from a single HHS website.

Response: We have included in §162.1000 a clearer statement that the version of the medical data code sets specified in the implementation specifications must be the version that is valid at the time the health care is furnished. Since transactions may have to be resubmitted long after the time health care was provided, health plans must be able to process earlier versions of code sets. The version of the nonmedical data code sets specified in the implementation specifications must be the version that is valid at the time the transaction is initiated.

At this time we are not establishing a common schedule for implementing new versions of all HIPAA medical data code sets, since some of the code sets are updated annually (for example, ICD-9-CM, CPT) and some are updated more frequently. The organizations that maintain medical data code sets will continue to specify their update schedule. Different Federal laws mandate the implementation of annual updates to ICD-9-CM on October 1 and annual updates to the CPT on January 1 of the following year for their use in the Medicare program. Changing either of these dates would require legislative action and would also represent a major change in current practice for many elements of the health care industry.

We agree that a common web site is a viable solution, but it is unclear what the Federal role would be in the development of one. We expect to work with the medical data code set maintainers to explore this option.

b. Proprietary coding systems

Two of the code sets proposed as HIPAA standards, CPT and The Code on Dental Procedures and Nomenclature (referred to as “The Code” and published as CDT), are proprietary products.

Comment: Many commenters stated that the Secretary should not recommend proprietary systems as national standards. They believed that the proposed rule lacked a definitive method to guarantee public access to the proposed standards at low cost, and recommended that the government should develop or maintain the national standards or acquire the rights to the standards of choice. Without ownership and control, the government places itself and the remainder of the health industry at noteworthy risk. One commenter indicated that implementation of the standards should be delayed until proprietary code sets have been moved into the public domain. One commenter said it was illegal for the Secretary to establish the CPT as a national standard. Another argued that the “The Code” should not be named a national standard.

Response: Under HIPAA, the Secretary has the authority to select existing code sets developed by either private or public entities and is not precluded from selecting proprietary code sets. The Secretary is required to ensure that all standard code sets are updated as needed and that there are efficient, low cost mechanisms for distribution (including electronic distribution) of the code sets and their updates. Free distribution of standard code sets is not required by the statute.

The comments we received regarding code sets were overwhelmingly in favor of the selection of currently used code sets as the initial standards. Some of the code sets that are currently used in administrative transactions are proprietary code sets. We have obtained some clarification from the developers of these code sets about the pricing structure and mechanisms for publishing the pricing structure that will be in place when the initial standards are implemented. The existence of efficient, low-cost distribution mechanisms will affect future decisions regarding changes or additions to the code sets designated as standards.

A health care provider who submits X12N transactions can download the implementation specifications free of charge from the Washington Publishing Company website. However, two of the medical codes sets, CPT and the Dental Code require a fee. Royalties for electronic use of the CPT are based on a $10.00 per user standard. Royalties for electronic use of the Dental Code in practice management systems are based on $10.00 per user site. These royalty fees are normally included in the purchase and maintenance costs of the electronic systems that such providers use. The other medical codes sets, HCPCS and ICD-9 CM, may be downloaded free of charge.

For paper manuals, to which most providers that use these code sets already subscribe, the CPT manual is $49.95 and the Dental Code manual is $39.95. In fact, the need for such paper manuals may decrease as more electronic systems are implemented.

A health care provider who submits retail pharmacy transactions who wants a copy of the NCPDP standards can pay an annual fee of $550 for membership in the NCPDP organization, which includes copies of the implementation specifications for the retail pharmacy standard and the data dictionary as well as technical assistance in implementation. As a non-member, the implementations specifications and data dictionary may be purchased separately for $250 each.

Although nothing in this final rule, including the Secretary’s designation of standards, implementation specifications, or code sets is intended to divest any copyright holders of their copyrights in any work referenced in this final rule, future decisions regarding changes or additions to the code sets designated as standards may be affected by the existence of efficient, low-cost distribution mechanisms.

c. Code Sets Proposed

The following code sets were proposed as initial standards:

(a) Diseases, injuries, impairments, other health related problems, their manifestations, and causes of injury, disease, impairment, or other health-related problems.

The standard code set for these conditions is the International Classification of Diseases, 9th edition, Clinical Modification, (ICD-9-CM), Volumes 1 and 2, as maintained and distributed by the U.S. Department of Health and Human Services. The specific data elements for which the ICD-9-CM is the required code set are enumerated in the implementation specifications for the transaction standards that require its use.

(b) Procedures or other actions taken to prevent, diagnose, treat, or manage diseases, injuries and impairments.

(1) Physician Services

The standard code set for these services is the Current Procedural Terminology (CPT-4) maintained and distributed by the AMA. The specific data elements for which the