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.
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:
The health plan may not refuse to conduct the transaction as a standard transaction.
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.
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.
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.
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.
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.
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 CPT-4 (including codes and modifiers) is a required code set are enumerated in the implementation specifications for the transaction standards that require its use.
(2) Dental Services
The standard code set for these services is The Code on Dental Procedures and Nomenclature, printed as “The Code” and published as CDT, maintained and distributed by the ADA for a charge. The specific data elements for which the Dental Code is a required code set are enumerated in the implementation specifications for the transaction standards that require its use.
(3) Inpatient Hospital Services
The standard code set for these services is the International Classification of Diseases, 9th edition, Clinical Modification (ICD-9-CM), Volume 3 procedures, maintained and distributed by the U.S. Department of Health and Human Services. The specific data elements for which ICD- 9-CM, Volume 3 procedures, is a required code set are enumerated in the implementation specifications for the transaction standards that require its use.
(c) Other Health-Related Services
The standard code set for other health-related services is the Health Care Financing Administration Common Procedure Coding System (Level II of HCPCS) maintained and distributed by the U.S. Department of Health and Human Services.
The proposed standard code set for these entities is the National Drug Codes maintained and distributed by the U.S. Department of Health and Human Services, in collaboration with drug manufacturers. The specific data elements for which the NDC is a required code set are enumerated in the implementation specifications for the transaction standards that require its use.
(e) Other Substances, Equipment, Supplies, or Other Items Used in Health Care Services
The proposed standard code set for these entities is the Health Care Financing Administration Common Procedure Coding System (Level II of HCPCS) as maintained and distributed by the U.S. Department of Health and Human Services.
a. Comment: The great majority of commenters supported the selection of the code sets proposed on the basis that these code sets were already in wide use among hospitals, physician offices, other ambulatory facilities, pharmacies, and similar health care locations. Commenters mentioned that replacement systems could have different formats and number of digits. This could complicate the initial conversion. They also pointed out that replacement systems for the ICD-9-CM are still under development and testing. Many commenters stated that it would be premature to make a decision on replacements for the ICD-9-CM prior to their completion and testing.
Response: We agree that the continued use of the proposed coding systems will be the least disruptive for many entities required to implement HIPAA standards. The fact that replacement systems are still under development and testing further supports this decision.
b. Comment: Two commenters stated that the proposal did not reflect current uses of some code sets. One commenter stated that in addition to being used for inpatient procedural coding, the ICD-9-CM procedure codes are also required by many health plans for the reporting of facility-based outpatient procedures. The second commenter pointed out that in addition to being used by physicians and other health care professionals, the combination of HCPCS level I and CPT-4 is required for reporting ancillary services such as radiology and laboratory services and by some health plans for reporting facility-based procedures. Further, Medicare currently requires HCPCS level II codes for reporting services in skilled nursing facilities.
Response: Health plans must conform to the requirements for code set use set out in this final rule. Therefore, if a health plan currently requires health care providers to use CPT-4 to report inpatient facility-based procedures, they both would be required to convert to ICD-9.
We agree that the proposal did not reflect all current uses of some code sets. For example, we agree that CPT-4 is commonly used to code laboratory tests, yet laboratory tests are not necessarily considered to be physician services. Moreover, the proposed rule implied that laboratory tests are a type of other health care service which are encoded using HCPCS. We believe that the architecture of both coding sets, HCPCS and CPT-4, is such that they are both frequently used for coding physician and other health care services. Both of these medical data code sets are standard medical data code sets and may be used in standard transactions (see §162.1002(e)). Therefore, a health plan using CPT-4 to report outpatient facility-based procedures would not be required to change that practice.
In addition, the proposed rule did not itemize the types of services included in other health care services. These other health care services include the ancillary services, radiology and laboratory which are mentioned in the comment, as well as other medical diagnostic procedures, physical and occupational therapy, hearing and vision services, and transportation services including ambulance. Similarly, other substances, equipment, supplies, or other items used in health care services includes medical supplies, orthotic and prosthetic devices, and durable medical equipment.
In the final rule, we clarify the description of physician and other health care services and we recognize that two code sets (CPT-4 and HCPCS) are used to specify these services. In the proposed rule, we used the term “health-related services” to help describe these services. We believe that use of the term “health-related services” might suggest that these services are not health care. In an effort to prevent this confusion, and because the codes in this category are used to enumerate services meeting the definition of health care, we are using what we believe is the more appropriate term (“health care services”) to describe these services. We note that the substance of the category remains the same. The final rule has been revised to indicate that the combination of HCPCS and CPT-4 will be used for physician services and other health care services. The use of ICD-9-CM procedure codes is restricted to the reporting of inpatient procedures by hospitals.
In § 162.1002 we clarify the use of medical code sets. The standard code sets are the following:
(a) ICD-9-CM, Volumes 1 and 2 (including The Official ICD-9-CM Guidelines for Coding and Reporting), is the required code set for diseases, injuries, impairments, other health problems and their manifestations, and causes of injury, disease, impairment, or other health problems.
(b) ICD-9-CM Volume 3 Procedures (including The Official ICD-9-CM Guidelines for Coding and Reporting) is the required code set for the following procedures or other actions taken for diseases, injuries, and impairments on hospital inpatients reported by hospitals: prevention, diagnosis, treatment, and management.
(c) NDC is the required code set for drugs and biologics.
(d) Code on Dental Procedures and Nomenclature is the code set for dental services.
(e) The combination of HCPCS and CPT-4 is the required code set for physician services and other health care services.
(f) HCPCS is the required code set for other substances, equipment, supplies, and other items used in health care services.
c. Comment: Although there was wide support for the code sets that were proposed, a number of commenters pointed out that additional code sets were needed to cover some health services recorded in administrative health transactions. One commenter mentioned that the code sets proposed as standards lacked coverage of alternative health care procedures and recommended that the Alternative Link coding system also be designated as a standard code set. Commenters also indicated that none of the proposed standard code sets covered home infusion procedures; they recommended that the Home Infusion EDI Coalition Coding System (HIEC) be selected as a HIPAA standard. HIEC is currently used by some non-governmental health plans. One commenter recommended that dental diagnostic codes (SNODENT) developed by the ADA be used as a national standard. This commenter stated that the ICD-9-CM codes were inadequate for dentistry.
Response: No single code set in use today meets all of the business requirements related to the full range of health care services and conditions. Adopting multiple standards is a way to address code set inadequacies, but can also introduce complexities due to code set overlaps. We acknowledge that the coding systems proposed as initial standards may not address all business needs, especially in the areas of alternative health care procedures, home infusion procedures, and dental diagnoses. Specific shortcomings should be brought to the attention of the code set maintainers. The adoption of additional standards may be an appropriate way to fill gaps in coding coverage in these areas. Additional code sets must be analyzed by the DSMOs that will make recommendations to the National Committee on Vital and Health Statistics. In order to request changes, we recommend working through the processes described in §§162.910 and 162.940. In the interim, segments exist in the standard transactions which allow for manual processing of services for which codes have not been adopted.
d. Comment: While agreeing in general with the code sets proposed as standards, some commenters indicated that they lacked sufficient specificity to code data elements in several areas: functional status and other data elements necessary for studying persons with mental illness; behavioral health; chronic conditions and functional assessments covered by long term care insurance; and mental health services.
Response: We agree the code sets proposed as HIPAA standards may not cover functional status, mental and behavioral health, chronic conditions, and mental health services to the extent required by the legitimate business needs of some health care providers and health plans. We are unaware of any viable alternative code sets which cover these areas more completely. Maintainers of code sets seeking to be named as standards must pursue recognition through the processes set out at §§162.910 and 162.940.
e. Comment: One commenter, who supported the proposed code sets for their intended purposes, felt that they lacked the detail necessary to document a complete clinical encounter. The commenter stated that a comprehensive health information system requires the use of a controlled reference terminology to document care, retrieve data to perform studies, and assess patient outcomes. The commenter stated that as the implementation of HIPAA progresses towards the adoption of standards for a complete computer based patient record, the current coding systems will be inadequate. The commenter stated that the system developed by Systematized Nomenclature of Human and Veterinary Medicine International (SNOMED) could be used as a future standard.
Response: We agree that more detailed clinical terminologies are likely to be needed in complete computer-based patient records. SNOMED is one of the clinical terminologies being examined by the Work Group on Computer-Based Patient Records of the National Committee on Vital and Health Statistics’ Subcommittee on Standards and Security. The Work Group is responsible for studying the issues related to the adoption of uniform data standards for patient medical record information and the electronic exchange of such information.
f. Comment: One commenter expressed problems with the use of the ICD-9-CM and the ICD-10-CM for the collection of both reimbursement and research related data. It was stated that the data collected in claims’ transactions clog up the reimbursement data system with a large amount of extraneous material. The commenter also felt that the data were of dubious quality. The commenter estimated that as much as 50% of the information gathered within the transactions’ systems was for research purposes only. The commenter felt it was unfair to force the private sector to subsidize research costs through subterfuge. The commenter suggested that the issue be resolved by limiting the initial scope of the ICD-10-CM to collecting only information used or needed for reimbursement.
Response: The adopted coding systems support the collection of a wide variety of data that can be used for many purposes. However, we disagree with the commenter that standard health care claims or equivalent encounter information transactions collect data primarily for research purposes. The content of the health care claims or equivalent encounter information transaction was developed on a consensus basis by health care providers, health plans, and other industry representatives as necessary for the conduct of administrative transactions.
d. Coordination among Code Sets
Comment: Several commenters recommend that a very tight process be put in place to control overlap of HCPCS Level II “D” codes (The Code on Dental Procedures and Nomenclature, printed as “The Code” and published as CDT) and the CPT-4 codes. It was questioned whether there will be a review process in place for dental codes. Since there is some duplication of dental codes and the CPT-4 codes presently, a review process is needed to avoid duplication. One commenter stated that to attain and maintain coding consistency and avoid duplicate codes, the American Dental Association should be a member of a federal HCPCS committee.
Response: We agree that a mutual exchange of information is necessary to attain and maintain coding consistency. Panel member(s) from HCPCS Level II “D” Codes (The Code on Dental Procedures and Nomenclature), CPT-4, and Alpha-Numeric HCPCS will participate or act as consultants on the other coding panels in order to attain and maintain coding consistency and avoid duplicate codes.
e. Proposed changes to Dental Codes
Proposal: In HCPCS, the first digit “0" in the American Dental Association’s The Code on Dental Procedures and Nomenclature is replaced by a ``D'' to eliminate confusion and overlap with certain CPT-4 codes. The ADA has agreed to make this change an official part of the dental codes they distribute and to replace their first digit “0" with a “D.” Consequently, dental codes will no longer be issued within HCPCS as of the year 2000. The ADA will be the sole source of the authoritative version of “The Code.”
Comment: There were several specific comments about the proposal to change the initial digit in the ADA’s version of The Code on Dental Procedures and Nomenclature from “0” to “D.” Comments in favor of the change agreed that it would avoid potential overlap and confusion. One commenter indicated that this was particularly true for those claims that would continue to be submitted manually since the ASC X12N 837 and 835 transactions contain a code qualifier that clearly indicates which procedure code is being used. One commenter stated that as the ADA replaces the leading “0” with the letter “D,” some of the resulting codes will coincide with existing HCPCS Level II “D” codes, but will have totally different meanings. This could create great confusion at adjudication time. Dealing with a coding system that contains an alphabetic character would also cause problems for many systems. One commenter believed that it is the responsibility of both the ADA and the Department to specify clear and unambiguous rules that will affect this transition between coding systems, so the resulting confusion is minimized. The commenter suggested the following options: (1) replace the codes nationwide on a certain date; (2) choose a letter other than “D” for “The Code,” so there is no overlap; or (3) retain the leading zero in “The Code” and assure that there continues to be no conflict or overlap with the CPT-4 anesthesia codes, as currently they do not overlap.
There were no comments about the proposal that “The Code” be removed from HCPCS and that the ADA become the sole source of the definitive version of these codes.
Response: The ADA will change the leading “0” to a “D” as proposed. Many organizations are already using the “D” Codes, which contains the leading “D,” without difficulty, and we expect others to make this transition without difficulty. Although we did not receive comments that specifically addressed the removal of the dental codes from the HCPCS, general comments about the desirability of more consolidated access to all HIPAA code sets have led us to revise our position on the inclusion of “The Code” in the HCPCS. Thus, the dental codes will be available from two sources: the ADA, and through a licensing agreement between HCFA and the ADA.
f. Other Dental Code Issues
a. Comment: One commenter (a major health plan) emphasized the critical importance of federal oversight and monitoring of dental coding maintenance and revision to ensure that dental data sets do not incorporate fragmented or unbundled procedures that are integral parts of a single dental service. For example, in “The Code-1," the procedure code 04910, periodontal prophylaxis/periodontal recall, included the examination as part of this single dental service; in “The Code-2," the examination is unbundled and is listed as a separate procedure. The import of this unbundling is the potential for increasing cost of care, without otherwise increasing the services provided. At the very least, to control the impact that unbundling might potentially have on the cost of care, it was recommended that once a particular standard code is established, it may not be deleted and any changes or modifications to the code or descriptor be included as a new code.
Response: The American Dental Association (ADA) will be responsible for maintaining an appropriate open process for updating “The Code.” Interested public and private sector organizations and groups will have the opportunity for substantive input, as they will for all HIPAA standards. The Department will continue to review the process of code modification to ensure that the code sets continue to meet the business needs of the industry.
b. Comment: One commenter questioned whether the addition of a specific procedure to the dental codes adopted as a HIPAA standard meant that a health plan had to cover the procedure or whether it meant the health plan only had to be able to receive and process the standard code for the procedure.
Response: The establishment of a code in any of the code sets adopted as HIPAA standards does not require that a health plan cover the coded procedure. However, health plans must be able to receive and process all codes in HIPAA standard code sets. In other words, transactions containing standard codes may be returned with a message that the procedure is not covered by the health plan to whom they have been submitted. Transactions may not be rejected because the health plan’s system does not recognize valid standard codes.
g. Future Consideration of ICD-10 Code Sets
Proposal Summary: Although the exact timing and precise nature of changes in the code sets designated as standards for medical data are not yet known, it is inevitable that there will be changes to coding and classification standards after the year 2000. For example, the ICD-10-CM for diagnosis may replace the ICD-9-CM as the standard for diagnosis data. When any of the standard code sets proposed in this rule are replaced by wholly new or substantially revised systems, the new standards may have different code lengths and formats.
a. Comment: Several commenters felt that the ICD-10-CM should be considered as a future national standard after the year 2000. The commenters stated that the proposed initial standard, ICD-9-CM, should be selected since it was currently in use. They pointed out that the ICD-10-CM was still under development. Several commenters suggested that the system be tested and evaluated as a future national standard when the final draft is completed. One commenter was supportive of the system and suggested that factors such as code length be considered as part of the testing and evaluation of the ICD-10-CM system. Several commenters felt that the current draft of the ICD-10-CM showed significant improvements over the ICD-9- CM. Another commenter stated that the system would allow for more accurate reporting by health care providers. One commenter stated that the use of the ICD-10-CM will require considerable training.
Response: We agree with the commenters that the ICD-10-CM has great potential as a replacement for the ICD-9-CM. We also agree that a final evaluation of the system should await the completion of the final draft and testing.
b. Comment: Several commenters stated the ICD-10-PCS (which is under development for use in the United States as a replacement for the procedure coding section of ICD-9-CM) should be considered as a future national standard. Most commenters recommended that the decision to use or not use the ICD-10-PCS should await final development and testing. The majority of commenters stated that future systems, such as the ICD-10-PCS, should not be implemented until after the year 2000. However, several commenters supported the future migration to the ICD-10-PCS because it was felt to offer significant improvements over the ICD- 9-CM. One commenter stated that the ICD-10-PCS development project has made valuable contributions to many issues relating to coding and terminology. Another commenter expressed concern about the level of detail in the ICD-10-PCS and recommended that further studies and trials should be performed in order to establish the relative costs and benefits of the system. This commenter was particularly concerned about the pathology section and felt it needed more work. Others praised the increased level of detail in the system and felt the added clinical information would be useful.
Response: We believe the ICD-10-PCS has great promise as a future replacement of the ICD-9-CM, volume 3. However, we also believe the system needs additional testing and revision prior to making a decision about its use as a national standard. The system is dramatically different from the ICD-9-CM containing more digits, greater detail, and a more organized approach. With any new system, many factors must be weighed prior to making a recommendation about national use. Changing a coding system will have a great impact on national data and would be evaluated carefully by the Designated Standard Maintenance Organizations and the NCVHS, with opportunity for public input.
h. Universal Product Number (UPN)
Proposal: The Universal Product Number (UPN) identifies medical equipment and supplies. It was not recommended as an initial standard for the following reasons: the existence of two different sets of UPN codes; incomplete coverage - approximately 30 percent of the health care products do not have a UPN assigned to them; and lack of experience with UPNs for reimbursement. However, the proposal asked for comments regarding UPNs and when it might be appropriate to designate one or more UPN systems as HIPAA standards.
a. Comment: Several commenters stated that the HCPCS level II codes that we recommended to identify medical equipment and supplies are currently not specific enough for accurate claims processing, proper financial controls, or proper tracking of utilization. Health care providers use many different kinds of supplies and equipment not found in the HCPCS level II codes. It was argued that establishing UPNs as a national coding system for identifying health care supplies and equipment will provide the following advantages over the HCPCS level II codes:
- The UPN system would allow for more accurate billing and better fraud and abuse detection than the use of a non-specific coding system such as the HCPCS level II.
- UPNs would improve administrative efficiency and effectiveness.
- The product specificity that UPNs provide in identifying the actual specifications of manufacturer’s products and packaging sizes is essential to managing health industry transactions and determining accurate payment amounts.
- The UPN mechanism is already in place and has been proven in use.
Several commenters agreed that we should not include the UPNs in the initial list of standards. A cautious approach and considerable further study is necessary to determine if the objectives of administrative simplification and reduced costs within the health care system will be achieved by using the UPNs as a national coding system for health care products.
Response: We agree that additional information regarding the utility of the UPNs for claims processing needs to be obtained before a decision is made to require their use. Specifically, more information is needed concerning the costs and benefits that can be expected from using the UPNs and the extent to which their use would promote administrative simplification. Also, information is needed regarding the standards that would have to be established to ensure that the UPNs could be used effectively by third party payers. Another issue that needs to be studied is the amount and type of information that an insurer would have to obtain from manufacturers in order to adequately identify the products represented by approximately three to five million UPNs. Only detailed information concerning the products that are represented by the UPNs, provided in a consistent manner, will allow comparisons to determine if products from different manufacturers are functionally equivalent.
b. Comment: Several commenters expressed concern that the health care industry may continue to use two different types of UPN systems rather than a single system. They asserted that this is the best time to choose between the two coding councils, the Health Care Uniform Code Council (UCC) and the Health Industry Business Communications Council (HIBCC), because there has not been a substantial investment in either system.
Response: We believe that neither UPN system should be selected at this time, based on the reasons outlined above. We look to the industry to resolve the issue of whether the two systems should continue.
Before requiring the use of UPNs, we need to obtain more information regarding the costs and benefits of implementing the UPN, the adaptability of the UPN system for making coverage and payment determinations, and for combating fraud and abuse. We will be monitoring demonstrations being conducted by California Medicaid to determine the cost and feasibility of using UPNs in the health care industry. The entity proposing such a demonstration must request an exception from the standards following the procedures in § 162.940.
a. Comment: Commenters generally agreed with our recommendation to eliminate Level II HCPCS codes for drugs by the year 2000 and to use NDC for all drugs. However, some commenters disagreed with applying this requirement to non-pharmacy claims and recommended that the NDC be used only for retail pharmacy claims until sufficient benefits and overhead costs of exclusively implementing the NDC codes can be further researched. It was mentioned that the NDC numbers notate a vial size and physician injections often results in a single vial being used for multiple patients. They alleged that current Level II HCPCS codes allow for this identification. Several commenters also recommended that those durable medical equipment (DME) that do not have Level II HCPCS codes should use NDC codes.
It was noted that Medicaid agencies must reimburse health care providers for supplying the drug products of any company in the Federal Rebate Program as long as the drug reimbursement rates are within the Federal Upper Payment Limit. Because many companies produce the same drug, there are often many NDCs that correspond to the same drug with the same Level II HCPCS code. It was stated that Medicaid uses the Level II HCPCS codes to indicate which of these many products is reimbursable for health care provider submitted drug transactions.
One commenter suggested moving the NDC codes to the HCPCS codes. The commenter stated using two different coding systems (NDC and HCPCS) is counter to the overall goal of administrative simplification.
Response: We continue to believe that use of NDC to identify drugs is the most appropriate and efficient coding system available. While commenters gave various reasons in support of their objection to requiring use of NDC for non-pharmacy claims, most of these reasons were based upon a misunderstanding of the proposal. For example, contrary to one comment, the Medicaid drug rebate program requires the NDC, not the generalized Level II HCPCS code for the rebate program.
In response to the commenter who stated that the NDC does not always allow identification of partial vials (that is, when a single vial is used among multiple patients), we note that although this may be true with certain NDC codes, the transaction standards allow the reporting of dosage units for the NDC. In addition, although certain commenters requested a crossover period during which both nonstandard and standard codes may be used for processing, we believe that it is more reasonable to require all of the systems’ changes that we can at one time, rather than addressing the changes in a piecemeal fashion. The two years after the effective date allowed before compliance is required will allow for a smooth transition period. Both non- standard electronic formats and the new standard transactions may be used during this transition period.
With respect to DME claims, HCPCS Level II is the proposed standard for DME. DME do not receive NDC as NDC are national drug codes. We are not moving the NDC codes to the HCPCS since each are separate coding systems for different purposes. Commenters generally supported this recommendation.
b. Comment: One commenter recommended to either revise the existing NDC or create a new coding system so the codes are distinctive in their format. The commenter stated that the coding system should serve the inventory and distribution industries as well as assist with the billing and inventory management of outpatient and hospital settings. Moreover, the commenter wanted the system to have the capacity to last 50 to 100 years or longer.
One commenter stated the NDC system was designed for health care providers who manufacture drug products or pay for drug therapy. The commenter said the design is completely inappropriate for the needs of most health care providers who prescribe drug therapies, dispense drug products, or administer medications to patients. The NDC identifies drug products at a level of detail (the package) that is much too granular to be of any practical use for most health care providers. The commenter recommended to select either MediSource Lexicon or the HL7 Vocabulary Special Interest Group Drug Model and Listing as the standard code set for drugs.
Response: In general, the Act requires the Secretary to adopt existing code sets developed by private or public entities, unless code sets for the data elements have not been developed by such entities. When new code sets are developed or existing ones revised, they need to be evaluated. Demonstrations need to be performed in order to determine the cost and feasibility of such codes sets in the health care industry. MediSource and HL7 are not currently used within the transaction system for administrative and reimbursement purposes for retail pharmacy claims. The majority of commenters supported the adoption of the NDC coding system for pharmacy claims and did not support one commenter’s opinion regarding difficulties perceived. The NDC was originally developed as a 10-digit identifier made up of three subcodes: the manufacturer code, the product code, and the package size code. Each subcode is variable in length. Some subcodes are reported with leading zeroes and some truncate the leading zero. This leads to variable sizes, such as: 5-4-1, 5-3-2, and 4-4-2. Originally, the subcodes were separated by hyphens. However, when used in computer systems, it is customary to display each subcode using its largest valid size, yielding an 11-digit number: 5-4-2. We are adopting the 11-digit NDC in order that the format is distinctive and will be in place until the Secretary decides to adopt a new code system. Since it will be in a standard format, inventory systems, as well as other systems, should realize benefits. As the nation moves beyond the adoption of initial standards, there may be a need to evaluate other coding systems that have the potential of being adopted as a standard in the future.
c. Comment: Several commenters said the FDA needs to improve its oversight of NDC before adoption. It was stated that the FDA shifted responsibilities for the maintenance of the system to manufacturers and drug packagers who assigned their own codes. As a result, the FDA does not possess a current, accurate, or complete NDC list. It was stated that the 11-digit NDC code identifies drugs, and these codes are assigned on a continuous basis throughout the year as new drug products are issued.
Response: The Food and Drug Administration's Center for Drug Evaluation and Research provides daily updates to the New and Generic Prescription Drug Approval List. They provide weekly updates to the FDA Drug Approval List. This list includes additions and deletions to prescription and over the counter (OTC) drug products. This list must be used in conjunction with the most current publication of the Approved Drug Products with Therapeutic Equivalence Evaluations (a.k.a. Orange Book) which is updated on a monthly basis. The NDC Directory is updated on a quarterly basis. These lists are available via the Internet at: http://www.fda.gov/cder.
j. Training Requirements
Comment: A medical association stated that there will be a significant increase in the workload required in order to adequately comply with the standardized transaction code sets. There is a tremendous need for training for health care providers as well as information systems modifications. For example, the code sets for anesthesia, dental, and procedure codes will require a large amount of time and effort for State Medicaid Management Information Systems (MMIS) to comply with using the standardized code sets.
Response: We agree that educational activities must occur. Health plans should inform their health care providers of the impending changes as soon as possible and arrange for appropriate educational opportunities in 2000. It is also anticipated that health care clearinghouses and other commercial entities will offer training.
k. Local Codes
Proposal Summary: The Health Care Financing Administration Procedural Coding System (HCPCS) contains three levels. Level I (CPT-4), is developed and maintained by the AMA and captures physician services. Level II of HCPCS contains codes for products, supplies, and services not included in CPT-4. Level III, local codes, include codes established by insurers and agencies to fulfill local claim processing needs. One of the intentions of this rule is to eliminate local codes.
Comment: We received comments from a diverse group of organizations, ranging from data management corporations, health insurance organizations, State agencies, etc. A little less than half of the commenters did not favor the elimination of local codes. There was a general concern expressed by both public and private insurers that very specific and unique codes are necessary for processing and paying claims efficiently. Many commenters, particularly ones from State Medicaid agencies and from other insurance health plans, commented on the need for local codes to describe a wide variety of health care services. For example, several commenters described specific needs for local codes for physician services, such as digital rectal exam, that are not delineated in CPT-4 or HCPCS. Other commenters opposed the elimination of local codes because they argued that it would be difficult to get a national code approved in a timely fashion to process claims for new technologies that come onto the market and are coverable. The main concern of these commenters was that the needs of some health plans’ programs are so specific that a more general code would not meet their needs. Furthermore, eliminating both local codes and the process to standardize codes would take away some of a State’s authority to administer its programs. There was great concern that if the translation of local codes to national codes is not done expeditiously it would create a high number of “not otherwise classified codes,” which in turn create processing delays. There was a great deal of concern expressed by health plans that eliminating local codes would disrupt data reporting, claims payment, and data systems design for a considerable amount of time and would be very expensive.
Many commenters said that the proposed process was not well defined in the proposed rule. They felt that given the timetable specified in the proposed rule there would not be enough time to develop and implement an effective standardization process.
Commenters made a number of recommendations regarding the standardization process. Included among them were the following: conduct monthly meetings of the HCPCS panel; have each State establish its own HCPCS committee with health plan and health care provider representatives deciding which local codes to eliminate and which to submit to the national panel for standardization; open the HCPCS panel meetings to the public and include participation of stakeholders such as state beneficiary representatives and data maintenance organizations; add the AMA, ADA and BC/BS Association as voting members; and establish both state and regional level committees to make decisions on standardization of codes.
The main concern was that the proposed elimination of local codes would create an enormous backlog of codes for the HCPCS panel to review and this would result in the delay of the implementation of national codes. There was a general recommendation that any process that is established to standardize local codes should also have a mechanism in place to assign national codes for use within a very short time frame.
Several commenters stated they were unclear about whether all local codes could be translated into equivalent national codes within the next two years. They considered the timetable presented as difficult to achieve, and suggested that all codes developed and approved by HCFA should have a standard publication timetable. They said that any process for standardizing local codes must have the ability to assign codes within a very short time frame to assure that claims can be processed timely. Some commenters proposed that local codes should be eliminated when the ICD-10 codes sets and transactions are implemented. Others suggested delaying the elimination of local codes to allow for an orderly transition.
Response: We understand commenters’ concern about eliminating local codes and moving to a national process for reviewing and approving codes that are needed by public and private insurers. We remain committed in our effort to work with the industry to facilitate the standardization process. We will be monitoring the process of code revision to ensure that the code sets continue to meet the needs of the industry. Moreover, although the standardization of local codes will be challenging, we believe it is an achievable undertaking as health plans and health care providers have two years to eliminate local codes and transition to national codes (small health plans have three years before they are required by statute to be compliant with the HIPAA standards).
We would like to clarify that covered entities may not use local codes in standard transactions after compliance with this regulation is required. Nor may a covered entity require the use of local codes in standard transactions after compliance with this regulation is required.
We believe that the prohibition on the use of local codes in standard transactions will likely require health insurers to review their local codes and eliminate those codes that duplicate elements in the national codes. During this review process, we expect that covered entities will find that there are instances when they use a particular local code in fewer than 50 claims submissions per year. In those instances when a covered entity discovers that it uses a local code in fewer than 50 claims submissions per year, the covered entity should not make a modification request to the maintainer of the relevant medical code set for a unique national code for the item or service. Rather than having the maintainer of the relevant code set issue a unique national code for a service or item for which there are fewer than 50 claim submissions per year, a covered entity should use the national Not Otherwise Specified (NOS) code (use of the NOS code is voluntary before the compliance date of this regulation, but use of the NOS code becomes mandatory after the compliance date of the regulation). We believe that not only will NOS codes continue to serve as the national code for claim submissions for an item or service that are submitted fewer than 50 times per year, they will continue to serve as the national code for new services or items that have not yet been assigned a unique national code by the maintainer of the relevant medical code set.
Also, we anticipate that insurers will need to work with other similarly situated health plans to review local codes used for professional services, procedures, health care products and supplies which are not described by the current code sets. Finally, in situations where, after careful review, no national code currently exists to replace a local code, health plans may request the establishment of a national code. Health plans should bear in mind the criteria for the establishment of a national code. Specifically, national codes are only designed to identify an item or service; additional codes are not established to carry health plan specific information such as units or health care provider identification for products or procedures which have been given a national code. Such information must be used elsewhere and cannot be imbedded in the national codes.
Health plans should submit individual code requests for the establishment of national codes, along with supporting documentation, to the appropriate standard code set maintenance group. For example, in order to provide a better understanding of the HCPCS process, a Web site has been set up to provide public access to the list of items submitted for the HCPCS National Panel for review. An e-mail link is available for questions and comments related to the HCPCS process. The Internet site is http://www.hcfa.gov/medicare/hcpcs.htm.
For information on changes and updates to the procedure part of ICD-9-CM (Volume 3) see the following Internet site: http://www.hcfa.gov/medicare/icd9cm.htm.
For information on changes and updates to the diagnosis part of ICD-9-CM (Volumes 1 & 2) see the following Internet site: http://www.cdc.gov/nchswww/about/otheract/icd9/maint/maint.htm.
The Internet site for requesting a change or an addition to the code(s) in the Code on Dental Procedures and Nomenclature is: http://www.ada.org/P&S/benefits/cdtguide.html.
To request a change or an addition to the code(s) in the Current Procedural Terminology, Fourth Edition (CPT-4) you can write:
American Medical Association
Department of Coding and Nomenclature
515 North State Street
Chicago, Illinois, 60610.
The Internet site for the American Medical Association is http://www.ama-assn.org.
For the list of codes found in the National Drug Codes, see the following Internet site: http://www.fda.gov/cder/ndc/index.htm.
For information about submitting a request to modify the National Drug Codes, see the following Internet site: http://www.fda.gov/cder.
In addition, some commenters have stated that they use codes within their operating systems that are internally generated. These internal operating codes are used solely within the organization for administrative purposes. We understand that these codes are sometimes called local codes. Furthermore, commenters are concerned that this regulation will require the elimination of those internal operating codes. We clarify that this regulation will not require the elimination of the use of these internal operating codes when not part of a transaction for which a standard has been adopted under this part.
2. Transaction Standards
We received numerous comments on the specific transaction standards and implementation specifications which we proposed to adopt. Some of these concerned the choice of the particular standard itself, a matter clearly within the Secretary’s purview. Many of the other comments, however, concerned specific issues raised by the electronic formats, data conditions, and/or data content of the proposed standards and/or implementation specifications themselves. As these are all standards that are developed and maintained by external organizations (SSOs), the concerns raised by this latter group of comments could not be directly addressed by the Secretary.
Thus, we initially analyzed the public comments received to determine which comments fell into this latter group. The comments directed at the implementation specification for the X12N standards were turned over to the ASC X12N Subcommittee for review and action by the appropriate work group(s). They classified the comments into two categories: business needs, and technical or editorial errors. A listing of issues reviewed by X12N and the X12N response to those issues can be viewed on the Internet at http://www.wpc-edi.com/hipaa/nprm_issues. Those workgroups in turn reviewed the various comments and concluded that the existing standard and/or implementation specification: (1) needed to be changed and made the appropriate changes, (2) already addressed the concerns raised, so that no change was needed, (3) were correct, so that no change was needed, or (4) needed to be changed, but that the changes needed could not be made in the time available.
Thus, the discussion of the particular X12N standards in the preamble below generally reflects this approach. The first four paragraphs of the discussion of the agency’s response to each standard follows the following general format:
Of those comments we referred to ASC X12N, the work groups determined that [#] comments identified areas where the implementation specification could be improved, and the appropriate changes were made. [#] comments identified business needs that ASC X12N judged could already be met within the current standard implementation specification. Detailed information on how the current implementation specifications can be used to meet these business needs has been provided by ASC X12N at the Internet site in §162.920. [#] comments alleged technical or editorial errors in the standard implementation specification. A technical review of these issues was conducted by work groups within ASC X12N. The work groups determined that [#] comments identified areas where the implementation specifications were in fact correct and that no changes were needed. Changes to the implementation specification were not required. There were another [#] comments which identified business needs that ASC X12N judged could not be met directly within the current standard implementation specification. The implementation specifications could not be changed prior to the issuance of the final regulation because the X12 standards development process for modifying standards could not be completed in time. However, a review of the issues by the ASC X12N work groups has identified a means of meeting the business needs within the existing implementation specification as an interim measure. Organizations and individuals who submitted such comments are encouraged to work with the DSMOs to submit a request to modify the national standard.
We set out below the number of comments that fell into each category with respect to each of the standards. The particular groupings above appear, where applicable, as paragraphs (i), (ii), (iii), and (iv), respectively, of the responses to the comments on each X12N standard.
a. Transaction Standard for Health Care Claims or Equivalent Encounter Information
We proposed in subpart K that:
- For pharmacy claims, the NCPDP Telecommunications Standard Format Version 3.2 and equivalent Standard Claims Billing Tape Format batch implementation, version 2.0, would be the standard.
- For dental claims, the ASC X12N 837 - Health Care Claim: Dental, Version 4010, Washington Publishing Company, 004010X097, would be the standard.
- For professional claims, the ASC X12N 837 - Health Care Claim: Professional, Version 4010, Washington Publishing Company, 004010X098, would be the standard.
- For institutional claims, the ASC X12N 837 - Health Care Claim: Institutional, Version 4010, Washington Publishing Company, 004010X096, would be the standard.
- Comments and Responses on the Transaction Standard for Health Care Claims and Equivalent Encounter Information: Pharmacy
i. Comment: One commenter suggested that the final rule contain the correct version of the NCPDP Batch Standard Version. The correct version is 1.0, not version 2.0 as originally proposed.
Response: We agree to make the recommended change. The correct name of the standard may be found in §162.1102.
ii. Comment: Several commenters recommended that we reword this section to state “version 3.2 or higher.” This change would allow any approved version of the standard to be used. Currently, there are health plans and health care providers who have implemented a higher version of the standard.
Response: This final rule adopts NCPDP Telecommunications Standard Format, Version 5.1 in place of version 3.2. We do not believe that the term “or higher” is appropriate in that it will allow for variations in the standard used for pharmacy transactions. This is the most recently approved version of the NCPDP standard. This version contains revisions that address comments made to the proposed rule. There are numerous other benefits and advantages to naming Version 5.1. Some of these benefits and advantages are the following:
- Expanded dollar fields.
- HIPAA supported fields including Employer ID, Plan ID, and Prescriber (Provider) ID.
- New clinical fields including expanded Diagnosis Code, Patient Height, and Patient Body Surface Area.
- Service transactions for expanded professional pharmacy service support.
- Expanded coordination of benefits (COB) support.
- Support of intermediary processing.
- Coupon fields.
- Expanded response messaging including preferred product support and approved message codes.
- Flexibility with qualifiers that allows for addition of qualifier type codes instead of adding new fields.
- Pricing uniformity.
- Controlled Substance reporting support including Alternate ID and Scheduled Rx ID.
- Consistency within the NCPDP telecommunication standard.
- Correction of issues from previous versions.
- Variable length transactions that allow for trading partners to transmit only the data required for doing business (i.e. A v5.1 claim can be very small when necessary. Refer to the v5.1 implementation specifications for examples).
- Supports partial fill indicators.
- Additional code values for Drug Utilization Review (DUR).
iii. Comment: One commenter recommended that the word “retail” be removed when mentioning the NCPDP standard since the NCPDP Telecommunications Standard Format Version 3.2 and equivalent NCPDP Batch Standards Version 1.0 may be used to bill professional pharmacy services as well as retail pharmacy services.
Response: We are adopting the NCPDP standard for retail pharmacy only. We are adopting the ASC X12N 837 for professional pharmacy claims. Professional pharmacy claims use both the National Drug Code (NDC) and HCPCS j-codes to identify the pharmacy procedure or service. The NCPDP standard is designed to accommodate the NDC only and does not allow for billing of professional pharmacy claims using HCPCS. The NCPDP standard would require major modifications in order to accommodate the HCPCS codes.
Comments and Responses on the Transaction Standard for Health Care Claims or Equivalent Encounter Information: Dental
The majority of commenters expressed support of the selected standard.
i. Of those comments we referred to ASC X12N, the work groups determined that 246 comments identified areas where the implementation specification could be improved, and the appropriate changes were made.
ii. One individual comment identified a business need that ASC X12N judged could already be met within the current standard implementation specification. Detailed information on how the current implementation specifications can be used to meet these business needs has been provided by ASC X12N at the Internet site in §162.920.
iii. Thirty-one individual comments alleged technical or editorial errors in the standard implementation specification. A technical review of these issues was conducted by work groups within ASC X12N. The work groups determined that the 31 comments identified areas where the implementation specifications were in fact correct and that no changes were needed. Changes to the implementation specification were not required.
iv. There were another 4 individual comments which identified business needs that ASC X12N judged could not be met directly within the current standard implementation specification. The implementation specifications could not be changed prior to the issuance of the final regulation because the X12 standards development process for modifying standards could not be completed in time. However, a review of the issues by the ASC X12N work groups has identified a means of meeting the business needs within the existing implementation specification as an interim measure. Organizations and individuals who submitted such comments are encouraged to work with the DSMOs to submit a request to modify the national standard.
Comments and Responses on the Transaction Standard for Health Care Claims or Equivalent Encounter Information: Professional
i. Of those comments we referred to ASC X12N, the work groups determined that 356 comments identified areas where the implementation specification could be improved, and the appropriate changes were made.
ii. Thirty-five comments identified business needs that ASC X12N judged could already be met within the current standard implementation specification. Detailed information on how the current implementation specifications can be used to meet these business needs has been provided by ASC X12N at the Internet site in §162.920.
iii. 267 comments alleged technical or editorial errors in the standard implementation specification. A technical review of these issues was conducted by work groups within ASC X12N. The work groups determined that the 276 comments identified areas where the implementation specifications were in fact correct and that no changes were needed. Changes to the implementation specification were not required.
iv. There were another 9 comments which identified business needs that ASC X12N judged could not be met directly within the current standard implementation specification. The implementation specifications could not be changed prior to the issuance of the final regulation because the X12 standards development process for modifying standards could not be completed in time. However, a review of the issues by the ASC X12N work groups has identified a means of meeting the business needs within the existing implementation specification as an interim measure. Organizations and individuals who submitted such comments are encouraged to work with the DSMOs to submit a request to modify the national standard.
v. Comment: The majority of commenters expressed support for the selected standard. However, there was concern that the X12N 837 neither meets Medicaid’s needs nor supports behavioral health services. One commenter stated that representatives of the alcoholism and substance abuse treatment fields were not adequately represented in the development of the standards.
Response: The X12N standards are developed and maintained in an open atmosphere. We strongly encourage all industry stakeholders to assist in this process to ensure that their business needs are met. If Medicaid Agencies or other entities believe their business needs will not be met through the selected standard, we encourage them to submit any new data requests to the DSMOs. We will be monitoring the DSMOs’ process for the revision of standards to ensure that they are revised appropriately.
vi. Comment: Several commenters stated that the adoption of the claim standard without the attachment standard will create processing problems. They stated there is a potential that certain claims that require an attachment will need to be adjudicated manually.
Response: The health care claims or equivalent encounter information standard currently contains many justification requirements for certain services, including oxygen, chiropractic, ambulance, and durable medical equipment services. Therefore, these claims will not have to be adjudicated manually. Once the attachment standard is adopted, we expect that the justification requirements for the services listed above will be met by the attachment standards and, therefore, will be removed from the health care claims or equivalent encounter information standard. All other attachments that are not in this transaction or are not met by the attachment standard will need to be adjudicated manually.
Comments and Responses on the Transaction Standard for Health Care Claims or Equivalent Encounter Information: Institutional
i. Of those comments we referred to ASC X12N, the work groups determined that 169 comments identified areas where the implementation specification could be improved, and the appropriate changes were made.
ii. Three comments identified business needs that ASC X12N judged could already be met within the current standard implementation specification. Detailed information on how the current implementation specifications can be used to meet these business needs has been provided by ASC X12N at the Internet site in §162.920.
iii. 54 comments alleged technical or editorial errors in the standard implementation specification. A technical review of these issues was conducted by work groups within ASC X12N. The work groups determined that the 54 comments identified areas where the implementation specifications were in fact correct and that no changes were needed. Changes to the implementation specification were not required.
iv. There were another 6 comments which identified business needs that ASC X12N judged could not be met directly within the current standard implementation specification. The implementation specifications could not be changed prior to the issuance of the final regulation because the X12 standards development process for modifying standards could not be completed in time. However, a review of the issues by the ASC X12N work groups has identified a means of meeting the business needs within the existing implementation specification as an interim measure. Organizations and individuals who submitted such comments are encouraged to work with the DSMOs to submit a request to modify the national standard.
v. Comment: The majority of commenters expressed support of the selected standard.
Several commenters stated that they wanted the UB92 to be selected as the institutional claim standard since it is widely used. Several commenters disagreed that the X12N 837 met all of the guiding principles. The guiding principles are:
(1) Improve the efficiency and effectiveness of the health care system by leading to cost reductions for, or improvements in benefits from, electronic health care transactions.
(2) Meet the needs of the health data standards user community, particularly health care providers, health plans, and health care clearinghouses.
(3) Be consistent and uniform with the other standards required under this part--their data element names, definitions, and codes and the privacy and security requirements--and with other private and public sector health data standards, to the extent possible.
(4) Have low additional development and implementation costs relative to the benefits of using the standard.
(5) Be supported by an ANSI-accredited standard setting organization or other private or public organization that will ensure continuity and efficient updating of the standard over time.
(6) Have timely development, testing, implementation, and updating procedures to achieve administrative simplification benefits faster.
(7) Be technologically independent of the computer platforms and transmission protocols used in electronic health transactions, except when they are explicitly part of the standard.
(8) Be precise and unambiguous, but as simple as possible.
(9) Keep data collection and paperwork burdens on users as low as is feasible.
(10) Incorporate flexibility to adapt more easily to changes in the health care infrastructure (such as new services, organizations, and provider types) and information technology.
The principles in question were 1, 4, 6, 8, 9 and 10.
There was also concern that the X12N 837 does not meet the needs of many State Medicaid agencies. Different agencies require codes and data elements that are not in the transaction standard.
Response: While the UB92 is supported by many institutions, it is not used in a standard manner. To undergo a national UB92 standardization effort is not practical since the X12N 837 meets institutional needs and the majority of commenters support the selection of all X12N transactions.
We believe the X12N 837 meets all of the guiding principles in question. Implementation of the X12N 837 using the specifications defined in the implementation specification for version 4010 will lead to administrative simplification and cost savings for both health plans and health care providers. One nationally accepted standard will exist, rather than a variety of national and local formats (#1). We believe that the long-term savings that will accrue from the adoption of the standard will offset the short-term implementation costs (#4) (see section VI. Final Impact Analysis). The DSMOs have a process for the development and maintenance of transactions and implementation specifications that include many quality and technical assurance checkpoints prior to the approval of X12 standards and X12N industry implementation specifications (#6). Uniform implementation of the standards is critical. The implementation specifications provide for standard as well as unambiguous data content requirements for all users of each transaction (#8). Exchange of the X12N 837 standard transaction does not require increased data collection or paperwork burden (#9). The X12N 837 standard and syntax allow for the easy addition of new business functions. For example, instead of listing all CPT codes, the implementation specification refers to the code source. The standard uses qualifiers to aggregate general data content into unambiguous business transactions (#10). If an external code set is updated, the standard transaction would not have to be updated since the codes are external to the implementation specification. Qualifiers allow for the precise definition of generic fields, such as dates.
As part of the proposed rule comment process, commenters were encouraged to review the implementation specifications. Many commenters submitted requests for data needs or changes to the implementation specifications and, thus, we believe there has been ample time to review and submit these requests. If Medicaid agencies or other entities did not identify all of their business needs, they will need to submit new data requests to the DSMOs.
We note that health plans and covered health care providers that do business with Medicaid agencies will be required to use the standards within the 24 month implementation period (36 months for small health plans). We believe it would be inconsistent with the statutory intent to require these entities to support non-standard requirements solely for individual State Medicaid agencies, especially where those health plans and health care providers operate in more than one State. HCFA and the DSMOs stand ready to assist the State agencies with their transitions to the standards.
b. Transaction Standard for Health Care Payment and Remittance Advice
In subpart L, redesignated as subpart P, we proposed ASC X12N 835 - Health Care Claim Payment/Advice, Version 4010, Washington Publishing Company, 004010X091 as the standard for health care payment and remittance advice.
Comments and Responses on the Transaction Standard for Health Care Payment and Remittance Advice
The majority of commenters expressed support of the selected standard.
i. Of those comments we referred to ASC X12N, the work groups determined that 209 comments identified areas where the implementation specification could be improved, and the appropriate changes were made.
ii. Seven comments identified business needs that ASC X12N judged could already be met within the current standard implementation specification. Detailed information on how the current implementation specifications can be used to meet these business needs has been provided by ASC X12N at the Internet site in §162.920.
iii. Fifteen comments alleged technical or editorial errors in the standard implementation specification. A technical review of these issues was conducted by work groups within ASC X12N. The work groups determined that the 15 comments identified areas where the implementation specifications were in fact correct and that no changes were needed. Changes to the implementation specification were not required.
iv. Comment: A number of commenters asked that they be allowed to continue to use proprietary codes, narrative information, and their current alternate uses of selected ASC X12N 835 segments.
Response: We disagree. Permitting the combined use of nonstandard data content would not comply with the intent of the statute. The ASC X12N 835 format is intended to be fully machine readable, so that there can be totally automated posting of transactions to patient and health care provider accounts wherever used, regardless of the health plan.
We encourage health care providers and health plans who have a business need for additional information in the ASC X12N 835 format to provide background to the DSMOs on the need so the ASC X12N 835 implementation specification can be modified for a future version, or so that the DSMOs can advise commenters how their business needs can be met within the current implementation specification. ASC X12N made a number of changes in the 4010 implementation specification as a result of such comments on the proposed rule. In most cases, however, commenters who indicated that current code sets were inadequate did not submit any specific suggestions or requests with respect to the changes they needed. The DSMOs cannot consider an implementation specification modification to meet a need if the need has not been defined. We strongly encourage health plans and health care providers to participate in this process so that their needs are met.
v. Comment: Some commenters questioned why the ASC X12N 835 did not explain the basis for the payment issued.
Response: The ASC X12N 835 is not intended to explain how the amount of payment for a service is determined. A health care payment and remittance advice, as embodied in the ASC X12N 835 format, primarily exists to notify the health care provider of the amount being paid for a set of bills and, if that payment does not equal the amount billed, to briefly explain every adjustment applied to those bills by the health plan. A health care payment and remittance advice is not a vehicle for instructing health care providers on coverage policy, except to briefly refer to that policy when it is the reason for denial or reduction of a billed service. Information on policy type and coverage rules is more appropriately included on a health plan’s membership card and the coverage information shared with the subscriber and/or a health care provider at enrollment or in subsequent newsletters.
vi. Comment: A number of health plans requested that the ASC X12N 835 format be rearranged to more closely parallel the internal flat file they use for their claims systems in order to minimize the programming changes they would need to make in order to comply with version 4010 of the ASC X12N 835. They argued that they did not consider it administratively simpler if they had to make extensive programming changes.
Response: We considered these comments. In some cases, the implementation specification was changed, but for the most part, such requests could not be accommodated. HIPAA requires that United States health plans and certain health care providers, or their clearinghouses, use national health care transaction standards. Health care providers and health plans have flexibility in how they will implement the standards. They may choose to utilize a health care clearinghouse to process their transactions. By definition, a health care clearinghouse is used to translate non-standard format into a standard format, or vice-versa. When a health plan or health care provider uses a health care clearinghouse for those functions, they may be able to minimize programming changes. There are also a wide variety of software vendors from whom they may choose to purchase translation software.
vii. Comment: Some commenters asked for more generic codes in the ASC X12N 835 version 4010 implementation specification so that a health plan can simply report a service as denied or reduced, without the need to furnish more explanation on the reason for the denial or reduction.
Response: Health care providers need to have adequate details on the ASC X12N 835 transaction that they receive in order to enable them to not only post accounts, but to decide whether an appeal should be filed, or further action taken in response to the health plan’s decision on a claim. A failure to supply adequate reasons for denial or reduction would undermine the effectiveness of an ASC X12N 835 transaction.
viii. Comment: A few commenters asked for a code to indicate that a health plan was knowingly issuing an ASC X12N 835 transaction that did not balance. It was reasoned that not all health plans might be able to issue an ASC X12N 835 transaction that balances when the transaction becomes effective as a national health care standard.
Response: This request can not be accommodated. As explained in the implementation specification, an ASC X12N 835 transaction must balance at the line, claim and provider levels. To be in balance, the amount billed, less the amount of any adjustments, must equal the amount paid. An out of balance ASC X12N 835 would not be in compliance with the version 4010 implementation specification. Health plans are responsible for making all changes as needed to issue complete and compliant ASC X12N 835 version 4010 transactions. An out of balance ASC X12N 835 is of little to no value to a health care provider, raises more questions that it settles, and consumes the resources of health care providers and health plans who must explain why it does not balance.
ix. Comment: A health care clearinghouse asked if it would share any liability for non- compliance if it forwarded out of balance remittance data from a health plan to a health care provider.
Response: Liability issues will be discussed in a later enforcement regulation.
x. Comment: One commenter asked that all new codes or changes to codes considered for inclusion in an ASC X12N 835 implementation specification be circulated to all health plans for review and comment prior to inclusion.
Response: This is not practical at this time. There is not yet a central registry of health plans and, even if there were, the cost of such distribution and analysis of responses would be a significant financial burden on the code set maintainers. Such a process would also greatly extend the clearance time for such changes, preventing maintainers from meeting immediate business needs. Affected health plans can comment on code additions and changes included in or referred to in a later implementation specification through the maintenance and modification process set out at §162.910. Affected health plans are also encouraged to increase their involvement with the organizations responsible for code set maintenance. Health plans are encouraged to submit any new data requests to the DSMOs.
xi. Comment: A few State Medicaid agencies requested that they be permitted to use the ASC X12N 835 format, rather than the ASC X12N 820, to pay premiums to managed care companies under contract to provide care to Medicaid beneficiaries.
Response: Although the ASC X12N 835 can accommodate claims and capitation payments to health care providers, including managed care companies, the payments described in these comments are considered health plan premium payments, rather than payment for direct patient care. As discussed below under “Comments and Responses on the Transaction Standard for Health Plan Premium Payments,” all health plan premium payments must be transmitted with the ASC X12N 820 standard for consistency. Also, the ASC X12N 820 Payroll Deducted and Other Group Premium Payment for Insurance Products implementation specification includes some data elements not contained in the ASC X12N 835, because it was designed specifically for premium payment, rather than claim payment.
xii. Comment: A number of commenters questioned whether they would be prohibited from use of the automated clearinghouse (ACH) transaction for electronic funds transfer (EFT) of health care payments once the ASC X12N 835 is effective as a HIPAA transaction standard.
Response: The ACH is an acceptable mode of EFT under both the ASC X12N 835 and 820 transactions. The implementation specifications for the ASC X12N 835 and 820 transactions contain two parts, a mechanism for the transfer of dollars and one for the transfer of information about the payment, and allow these two parts to be transmitted separately. Consistent with the implementation specifications, actual payment may be sent in a number of different, equally acceptable ways, including check and several varieties of electronic funds transfer. When the transfer of funds is part of paying a health care premium or a health care claim, the ACH transaction may continue to be used as a valid part of an ASC X12N 835 or 820 transaction where the other part of the transaction is sent to the health plan or health care provider, directly or indirectly (through a clearinghouse or financial institution). Although these standard transactions allow transmission of one or both parts through a financial institution, they do not require both parts to be sent to the financial institution and the financial institution is not required by this regulation to accept or forward such transactions.
Health plans may continue to use the ACH transaction alone to authorize the transfer of funds (electronic funds transfer) when such transfer is not part of paying a health care premium or a health care claim for an individual, because such a transaction would not be a transaction covered under this part. The Department of the Treasury has confirmed that this standard does not conflict with their requirements for disbursements.
xiii. Comment: One commenter criticized the ASC X12N 835 format as inadequate to explain benefit payments to subscribers. The commenter was under the impression that ASC X12N 835 transactions would be issued electronically to patients as well as health care providers or their clearinghouses.
Response: We clarify that the ASC X12N 835 will be sent from a health plan to health care providers and/or health care clearinghouses. We are not regulating the explanations of benefits (EOBs) that health plans send to their subscribers. We believe subscribers will still receive an adequate explanation of benefits.
xiv. Comment: A health plan asked if it would be prohibited from sending paper EOBs to a health care provider who was sent an ASC X12N 835 transaction for the same claims. The health plan currently issues electronic remittance advice but includes appeal information only on the corresponding paper remittance advice. The health plan was concerned about how it could distribute appeal information for denied or reduced claims.
Response: A health plan can choose to continue to send paper remittance advice notices to health care providers that are issued ASC X12N 835 transactions. However, all information in the paper notice that could have been expressed in the X12N 835 must be included in the X12N 835 transaction. If a health plan has a need to send data that is not on the X12N 835, it needs to work with the DSMOs to submit a request to modify the standard. It is anticipated, however, that with expanded acceptance of electronic transactions by health care providers, and increases in automated coordination of benefits among health plans, there may be less of a need for paper remittance advice notices. At some point, health plans may be able to reduce or eliminate most paper remittance notices to health care providers capable of receiving of the electronic notices.
Also, the ASC X12N 835 transaction may be used to notify a health care provider of appeal rights by using the “remark codes” segment. Please see the remark code menu item at www.wpc-edi.com for a listing of currently approved remark codes and instructions on how to request additional remark codes to meet your business needs.
xv. Comment: One commenter was confused as to whether the NCPDP standard for real time remittance information could continue to be used once version 4010 of the ASC X12N 835 became the national Health Care Payment and Remittance Advice standard.
Response: Yes, the NCPDP Telecommunications Standard Format may continue to be used for real time pharmacy transactions because it is designed to apply to such transactions. The ASC X12N 835 is the standard transaction for dental, professional, and institutional health care payment and remittance advice. The NCPDP standard was not originally proposed due to an oversight on our part regarding the functionality of the standard. The NCPDP standard is used for both claim and health care payment and remittance advice and is being adopted as the standard transaction for retail pharmacy.
xvi. Comment: A few commenters asked for guidance as to when version 4010 of the ASC X12N 835 might sunset in favor of a later version or a replacement format. They also asked whether version 4010 and a replacement version/format could be operated concurrently for 90 days or more to allow for an orderly conversion of health plans and health care providers between versions/formats.
Response: These issues will be addressed when the Secretary announces any successor version/format to version 4010 of the ASC X12N 835. Under HIPAA, however, as a general rule, new versions or formats cannot be required more than once every 12 months and health care providers must be allowed a minimum of 180 days advance notice to enable them to comply with the change. We do anticipate a need for a crossover period of at least 90 days to convert between versions/formats during which both the old and new versions/formats will need to be supported.
xvii. Comment: It was suggested that the ASC X12N 997 format be expanded or new format developed and recognized as a HIPAA standard to allow health care providers or health care clearinghouses to notify a health plan of some problem with the format or content of an ASC X12N 835 transaction.
Response: This issue has been referred to X12N. There is no implementation specification for a transaction of this type at present, but such a transaction can be considered for addition to the published HIPAA standards if and when it is developed, and the implementation specification is written.
xviii. Comment: One commenter was concerned that patient privacy could be violated if a full ASC X12N 835 transaction is sent to a health care provider’s bank. The commenter asked what will be done to secure that data.
Response: A separate enforcement rule will address the penalties for violating the HIPAA rules. Separate privacy and security regulations are being prepared that will address privacy and security restrictions for health information.
xix. Comment: Several commenters recommended that we include the NCPDP telecommunications Standard 3.2 for the submission of remittance advice for the pharmacy service sector. Another commenter said that they use the NCPDP telecommunications Standard 3.2 for the claim and remittance transactions. Several commenters said the NCPDP meets their business needs and there is no business need to move to the ASC X12N 835 transaction for remittance advice inquiries.
Response: We agree with the commenter that remittance information is integral to the NCPDP Telecommunications Standard named in the proposed rule for retail pharmacy claims. As discussed previously, we are naming the NCPDP Telecommunications Standard 5.1 and NCPDP Batch Standard as the standard for health care payment and remittance advice within the retail pharmacy sector. We have added this requirement to §162.1602.
c. Transaction Standard for Coordination of Benefits
In subpart M, redesignated in this rule as subpart R, we proposed as the standards for coordination of benefits the following:
- For pharmacy claims, the NCPDP Telecommunications Standard Format Version 3.2 and equivalent Standard Claims Billing Tape Format batch implementation, version 2.0.
- For dental claims, the ASC X12N 837 - Health Care Claim: Dental, Version 4010, Washington Publishing Company, 004010X097.
- For professional claims, the ASC X12N 837 - Health Care Claim: Professional, Version 4010, Washington Publishing Company, 004010X098.
- For institutional claims, the ASC X12N 837 - Health Care Claim: Institutional, Version 4010, Washington Publishing Company, 004010X096.
Comments and Responses on the Transaction Standard for Coordination of Benefits: Pharmacy
Comment: One commenter suggested that the final rule contain the correct version of the NCPDP Batch Standard Version. The correct version is 1.0, not version 2.0 as originally proposed.
Response: We agree to make the recommended change for the batch standard. The proposed version 2.0 was incorrect. The correct name of the standard may be found in §162.1802. We are also changing the version to the NCPDP Telecommunications Standard Format Version for COB. The version is 5.1 as previously discussed.
Comments and Responses on the Transaction Standard for Coordination of Benefits: Dental, Professional, Institutional
i. Comment: One commenter recommended that claim/encounter data items should be distinguished from those data items that are part of the COB transaction process.
Response: One implementation specification is used for claims and coordination of benefits. The implementation specification clearly distinguishes between coordination of benefits data and claim data. For example, each coordination of benefits data element contains notes specifying when a particular data element is used.
ii. Comment: The majority of commenters supported the selection of the ASC X12N 837 for the coordination of benefits exchange standard. Some commenters believe that the decision to conduct COB in a certain manner is a business decision and not within the scope of HIPAA. Others would like all health plans to be required to participate in COB exchange using the plan to plan model in which the health care provider supplies the primary insurer with information needed for the primary insurer to then submit the claim directly to the secondary insurer. Several commenters stated that the plan to plan model would be quite costly and should be closely evaluated before being adopted at a national level.
Concern was expressed that if the standard COB transaction were sent to a health plan that does not conduct COB transactions, the health plan would reject the standard COB transaction because it contained COB information.
Response: Coordination of Benefits can be accomplished in two ways, either between health plans and other payers (for example, an auto insurance company), or from a health care provider to a health plan or other payer. The choice of model is up to the health plan.
Under this rule health plans are only required to accept COB transactions from other entities, including those that are not covered entities, with which they have trading partner agreements to conduct COB. Once such an agreement is in place, a health plan may not refuse to accept and process a COB transaction on the basis that it is a standard transaction. For example, a health plan receives a standard ASC X12N 837 transaction from a health care provider with which it has a COB trading partner agreement. If the health plan is not the primary payer, it must accept and process the COB information to adjudicate the claim. If the health plan has decided to conduct COB transactions with another payer, it must accept and store the COB information to use in a COB transaction with the other payer. If the health plan is the primary payer and does not have a trading partner agreement with the secondary payer, then it may simply dispose of the COB information and leave the COB activity up to the health care provider.
If a health plan electronically conducts COB with another health plan it must do so using the standard transaction. A health care provider that chooses to conduct COB electronically with a health plan must do so using the standard transaction. A COB transmission between a health care provider and a payer that is not a health plan would not be subject to the requirements of this rule; nor would the transmission of a COB transaction from a health plan to another payer that is not another health plan.
d. Transaction Standard for Health Care Claim Status
In subpart N, we proposed the ASC X12N 276/277 Health Care Claim Status Request and Response, Version 4010, Washington Publishing Company, 004010X093 as the standard for health care claim status.
Comments and Responses on the Transaction Standard for Health Care Claim Status
The majority of commenters expressed support for the selected standard.
i. Of those comments we referred to ASC X12N, the work groups determined that all 94 comments identified areas where the implementation specification could be improved, and the appropriate changes were made.
ii. Comment: We received several comments questioning whether the ASC X12N 277 “Unsolicited Claims Status Request” transaction will be included as a HIPAA standard transaction.
Response: The HIPAA transaction requirements do not include the ASC X12N 277 “Unsolicited Claims Status Request.” We expect to consider this transaction for adoption in a future regulation.
iii. Comment: Several commenters questioned whether a health care provider is mandated to use the ASC X12N 276 Health Care Claim Status Request transaction.
Response: A health care provider must use the ASC X12N 276 Health Care Claim Status Request transaction when transmitting the transaction electronically to a health plan. The health care provider has the option to submit nonstandard transactions to a health care clearinghouse for processing into the standard transaction and may of course choose to submit transactions in paper form.
iv. Comment: Several commenters questioned whether a health plan will be required to respond to an ASC X12N 276 request from a health care provider who did not have a business arrangement with the health plan.
Response: A health plan may not refuse to process a transaction simply because it is a standard transaction. Whether a health plan may refuse to process a transaction on other grounds may depend upon the particular business agreements the health plan has with the sender. Health plans may have contracts that require them to process out of service area transactions. Use of a standard transaction does not create a relationship or liability that does not otherwise exist. A health plan would not be required by these rules to respond to such a request from a health care provider with whom it does not have a business arrangement.
v. Comment: We received several comments relating to whether a State or health plan will be required to support the ASC X12N 276/277 transactions if they are currently using another application to provide this information.
Response: All health plans, including state Medicaid plans, must have the capability to accept, process, and send the ASC X12N 276/277 transactions.
e. Transaction Standard for Enrollment and Disenrollment in a Health Plan
In subpart O, we proposed the ASC X12N 834 - Benefit Enrollment and Maintenance, Version 4010, Washington Publishing Company, (004010X095) as the standard for enrollment and disenrollment in a health plan.
Comments and Responses on the Transaction Standard for Enrollment and Disenrollment in a Health Plan
The majority of commenters expressed support for the selected standard.
i. Of those comments we referred to ASC X12N, the work groups determined that 124 comments identified areas where the implementation specification could be improved, and the appropriate changes were made.
ii. Ten comments identified business needs that ASC X12N judged could already be met within the current standard implementation specification. Detailed information on how the current implementation specifications can be used to meet these business needs has been provided by ASC X12N at the Internet site in §162.920.
iii. Twenty comments alleged technical or editorial errors in the standard implementation specification. A technical review of these issues was conducted by work groups within ASC X12N. The work groups determined that the 20 comments identified areas where the implementation specifications were in fact correct and that no changes were needed. Changes to the implementation specification were not required.
iv. There was one comment which identified a business need that ASC X12N judged could not be met directly within the current standard implementation specification. The implementation specifications could not be changed prior to the issuance of the final regulation because the X12 standards development process for modifying standards could not be completed in time. However, a review of the issue by the ASC X12N work groups has identified a means of meeting the business need within the existing implementation specification as an interim measure. Organizations and individuals who submitted such comments are encouraged to work with the DSMOs to submit a request to modify the national standard.
v. Comment: Several commenters said that health plans must be free to accept enrollment data in non-standard formats if that option is chosen by a sponsor. In the proposed rule we stated, we would require health plans to use only the standard specified in §142.1502 (63 FR 25293). Commenters suggested that we not include the word “only” in the final rule under health plan requirements. One commenter suggested the addition of the following language to the rule: “However, health plans may require trading partners to use the standard transaction to conduct business.”
Response: We recognize that entities that are not covered under HIPAA, such as sponsors of health plans, including employee welfare benefit plans, are not required to use the HIPAA standards to perform EDI with health plans. The proposed rule stated that health plans are required to use only the standard specified in §142.1502 for electronic enrollment and disenrollment in a health plan transactions. Sponsors, one of the primary trading partners with whom the health plans exchange enrollment and disenrollment in a health plan transactions, were proposed to be excluded from the requirements. Our reference to the requirements for health plans to accept “only” the standard specified was intended to preclude health plans from using data in formats other than the standard transaction when exchanging transactions with entities named in the law. It was not intended to impose requirements on sponsors. Thus, sponsors remain free to send enrollment data in nonstandard format if they choose, and health plans are free to accept the data.
We expect that sponsors may voluntarily accommodate a health plan’s request to use the ASC X12N 834 by directly submitting the transaction in standard format or by using a health care clearinghouse to translate non-standard data into the standard transaction.
vi. Comment: Several commenters said that the ASC X12N 834 should not be used to collect demographic data for public health and health data research. A number of other commenters said that the ASC X12N 834 should be used for this purpose. These commenters also recognized that the demographic data collected by the ASC X12N 834, such as address, could change frequently. Commenters noted that the data collected in the ASC X12N 834 is needed by the enrolling entity so that it can perform certain functions, such as determining the eligibility of a person for enrollment into their offered health plan.
Response: The ASC X12N 834 is used to enroll and disenroll subscribers in a particular health plan, and demographic data are included in the data content. The decision to include demographic data as required data content was made through the ASC X12N 834 work group following the usual standards development process. We support the inclusion of such data in the implementation standard. The collection of demographic data is a means of monitoring progress towards eliminating disparities in health care for populations that historically have experienced discrimination and differential treatment based on factors such as race and national origin. We recognize the ASC X12N 834 Benefit Enrollment and Maintenance transaction set as the most favorable vehicle for collecting these data due to the mostly static nature of demographic information. While the public health and health research community does not currently have access to the enrollment data, we support a secondary use of the ASC X12N 834 for public health and health research. We see this as a mechanism for opening the lines of communication between the health data research community and the holders of the data.
Current Departmental policy supports increasing the use of demographic data for researching disparities in health care among demographic groups. However, the research community generally does not have access to the data collected by sponsors on the ASC X12N 834. While the research community is not opposed to collecting demographic data on the ASC X12N 834, they have requested that this data also be collected on the ASC X12N 837. This request would make no change to the ASC X12N 834 implementation specification. Most of the demographic data in the ASC X12N 837 implementation specification is marked as not used. As stated above, most of the demographic data in the ASC X12N 834 is currently not available to the research community. The business needs of the research community must be presented to the X12N 837 work group for consideration in a future version of the implementation specification.
We recognize that the enrollment and disenrollment in a health plan transaction was designed for use mainly by sponsors, but sponsors are not required by HIPAA to use the standard. Additionally, the conditions for use of the demographic data are stringent, as follows: "This data should only be transmitted when such transmission is required under the insurance contract between the sponsor and payer and allowed by federal and state regulations." Therefore, we would not expect to see a widespread increase in the collection of demographic data when these standards are implemented for the first time. Nor would we expect that this arrangement would provide public health and researchers with increased access to demographic information because of the difficulty creating dependable linkages between enrollment and encounter data.
If demographic data were collected routinely, facilities would more easily demonstrate compliance with Title VII of the Civil Rights Act of 1964, the nondiscrimination provisions of health and social services block grant programs, and other program statutes and regulations which prohibit discrimination on the basis of race or national origin.
Therefore, the Department intends to work with the industry to support efforts to revise future versions of the Health Care Claims or Equivalent Encounter Information (ASC X12N 837) implementation specification to allow collection of demographic data. We also support conditions for collection of these data that are less stringent than specified in the enrollment and disenrollment in a health plan transaction implementation specification. Many claim transactions cannot be linked to their respective enrollment data. Allowing transmission of racial and ethnic data in both the enrollment and disenrollment in a health plan and the claim transaction sets will increase the probability that this important information is available for utilization review, quality of care initiatives, disparity and nondiscrimination monitoring, and research. The Secretary believes it is critical to collect these data for the following reasons, all of which are high priorities for the Department:
- the need to measure racial and ethnic disparities in type, volume and appropriateness of care received.
- the need to focus efforts in areas/populations/health plans where there is evidence of disparities based on race and national origin.
- the need to monitor progress towards eliminating disparities in health and health care.
- the need to monitor and enforce statutes and regulations that prohibit discrimination on the basis of race and national origin.
We strongly recommend that the health care industry, including the public health and research community, work with the appropriate content committees and standard setting organizations to come to consensus on an approach that will enhance the collection of demographic data as well as be acceptable to the entire health care community. Departmental representatives to these committees and organizations will participate actively in this process, including articulation of the essential business needs. A solution that has met the test of the consensus process may be adopted as a national standard under HIPAA. The solution should promote uniformity, comparability, and the increased availability of demographic data for entities that depend upon this data to monitor progress towards eliminating disparities in health care. As we work with the data content committees and standard setting organizations to reach consensus on an approach that will enhance the collection of demographic data, the Department plans to explore approaches, including demonstration projects, for promoting and facilitating the voluntary collection of high quality demographic data in the health care environment.
vii. Comment: We received several comments regarding the role and responsibility of State agencies’ use of the ASC X12N 834. One commenter stated we need to make it clear that if a State Health Agency does not participate in the enrollment function, it is not required to use the standard.
Response: Health plans, including State health agencies, are not required to conduct a standard transaction based solely on the fact that it is a standard transaction.
viii. Comment: Other commenters also asked what we recommend as a process and structure for the submission of monthly capitation claims from a managed care health plan to a State Medicaid agency.
Response: We interpret “process and structure” to mean implementation specification and standard transaction. Monthly capitation claims from a managed care organization (MCO) to a State Medicaid Agency do not fall within the rules we have established for transactions between health plans. The transaction does not meet the definition of a health care claim or equivalent encounter information transaction. It does not need to be conducted as a standard transaction.
ix. Comment: Another commenter said that an interface between a State and the State’s processing associate, specifically for data entry, should not be required to be in standard format.
Response: We agree. In this scenario, data entry does not fall within any of the definitions for standard transactions. Consequently, the communication for data entry purposes does not need to be in standard format.
x. Comment: Several commenters said that a State Medicaid program is excepted from using the ASC X12N 834 when contracting with a managed care health plan because it is functioning as a sponsor.
Response: A State Medicaid program is acting as a sponsor and is excepted from the HIPAA standard requirements only when purchasing coverage for its employees. The State Medicaid program is not acting as a sponsor when enrolling Medicaid recipients in contracted managed care health plans, and thus is not excepted from the law.
xi. Comment: Several commenters said that the ASC X12N 834 should not apply to the State “buy-in” process.
Response: The transmission between a State Medicaid Agency and HCFA for the purpose of buy-in is outside of the scope of this requirement. State buy-in, the process by which State Medicaid programs pay only the Medicare premium for certain categories of dually eligible individuals, is essentially a Medicaid subsidy, required under Federal law, of Medicare insurance. This transaction is neither an enrollment and disenrollment in a health plan nor a health plan premium payment transaction. It is a unique transaction created solely for the purpose of the buy-in program. States use a unique flat-file and coding structure for transmitting to HCFA a list of Medicaid beneficiaries who are already enrolled in Medicare whose income level entitles them to participate in the buy-in program for that month. HCFA then creates an internal billing file with accretions and deletions for each state. A paper billing notice, reflecting the total amount of premiums owed by the state for that month, is mailed to the state. The Medicaid agency sends premium payment to HCFA via Federal Wire to Treasury. No electronic health plan premium payment transaction occurs between HCFA and the Medicaid agency.
f. Transaction Standard for Eligibility for a Health Plan
In subpart P, redesignated in this rule as subpart L, we proposed the ASC X12N 270 - Health Care Eligibility/Benefit Inquiry and ASC X12N 271 - Health Care Eligibility/Benefit Response, Version 4010, Washington Publishing Company, (004010X092) as the standard for eligibility for a health plan.
Comments and Responses on the Transaction Standard for Eligibility for a Health Plan
The majority of commenters expressed support for the selected standard.
i. Of those comments we referred to ASC X12N, the work groups determined that 224 comments identified areas where the implementation specification could be improved, and the appropriate changes were made.
ii. Eleven comments identified business needs that ASC X12N judged could already be met within the current standard implementation specification. Detailed information on how the current implementation specifications can be used to meet these business needs has been provided by ASC X12N at the Internet site in §162.920.
iii. Seven comments alleged technical or editorial errors in the standard implementation specification. A technical review of these issues was conducted by work groups within ASC X12N. The work groups determined that the 7 comments identified areas where the implementation specifications were in fact correct and that no changes were needed. Changes to the implementation specification were not required.
iv. There were another 10 comments which identified business needs that ASC X12N judged could not be met directly within the current standard implementation specification. The implementation specifications could not be changed prior to the issuance of the final regulation because the X12 standards development process for modifying standards could not be completed in time. However, a review of the issues by the ASC X12N work groups has identified a means of meeting the business needs within the existing implementation specification as an interim measure. Organizations and individuals who submitted such comments are encouraged to work with the DSMOs to submit a request to modify the national standard.
v. Comment: We received one individual comment requesting changes to a set of codes which were not maintained by X12 or by a Federal agency, but were maintained by an external code source maintaining body.
Response: All code sources external to the X12 standard are listed in section C of the implementation specifications. All of these code sources have a mechanism for modifying their codes. The contact listed in the X12 code source list can provide detailed information regarding the process for updating their codes. The X12N subcommittee can also assist entities in determining how to contact an external code source maintenance body in order to request changes to the codes. Code sets not listed in the external code set appendices in the implementation specifications fall within X12N jurisdiction and are maintained through that organization’s data maintenance procedures, in conjunction with the DSMOs.
vi. Comment: Several commenters recommended that we include the NCPDP telecommunications Standard 3.2 for the pharmacy service sector eligibility inquiries. One commenter said that this is the only automated eligibility inquiry allowed for use by pharmacy providers. A commenter said that it uses the transaction (the NCPDP telecommunications Standard 3.2) for the pharmacy service sector for both claim and eligibility transactions. Finally, additional commenters suggested that there is no business need that should force health care providers to move to the ASC X12N 270/271 transaction for the pharmacy service sector for eligibility inquiries. It was stated that thousands of eligibility transactions are performed each month by pharmacies and health plans using the NCPDP telecommunications Standard 3.2. Furthermore, there is no benefit in moving to the ASC X12N 270/271 for pharmacy eligibility inquiries since the NCPDP telecommunications Standard 3.2 is already fully supported.
Response: We agree with the commenter that eligibility and enrollment are integral to the NCPDP Telecommunications Standard named in the proposed rule for retail pharmacy claims. We name the NCPDP Telecommunications Standard 5.1 and the NCPDP Batch Standard as the standard for patient eligibility and coverage information within the retail pharmacy sector since the eligibility information is part of the NCPDP standard. We have added this requirement to §162.1202.
vii. Comments: Several commenters suggested that the ASC X12N 270/271 Eligibility Roster implementation specification for eligibility for a health plan should be adopted as a HIPAA standard. One commenter suggested that the description of the roster implementation is incorrect in that it states that the roster is a separate part of the 270/271. The commenter went on to explain that the roster is essentially the same transaction as that being recommended for response to an X12N 270 inquiry, but the implementation specification has different values in some of the segments so that the X12N 271 response can be sent without an associated inquiry, and so that the hierarchy of benefits can be more fully described. It was also suggested that the example of a health plan sending the X12N 270/271 roster to alert a hospital about forthcoming admissions was not representative of the functionality of the roster. The commenter also stated that there are health care providers who currently use the X12N 270/271 electronic roster implementation, and it was misleading to use the term “not recommended” in connection with the roster implementation specification. Additionally, the commenter stated that it is incorrect to say that the roster implementation specification is not millennium compliant and that the standards development process for the implementation specification is not completed.
Response: We agree that a more precise description of the roster functionality would be to refer to it as another implementation rather than another part of the standard. Although the current version of this implementation specification is millennium compliant and complete, this was not true at the time the proposed rule was written. Thus, we did not recommend the use of the ASC X12N 270/271 to provide requests for eligibility. Another implementation of the ASC X12N 271 is designed to handle requests for eligibility “rosters,” which are essentially lists of entities -- subscribers and dependents, health care providers, employer groups, health plans -- and their relationships to each other. For example, this transaction might be used by a health plan to submit a roster of patients to a health care provider in order to designate a primary care physician.
The eligibility inquiry and response is the only implementation proposed under HIPAA for eligibility for a health plan. The implementation of the HIPAA standards will be a great undertaking and at this time we are limiting the transactions to those identified in the proposed rule. In addition, entities who move eligibility information in a roster format may do so using any available format, including the ASC X12N 270/271 roster implementation. After the implementation specification for the roster function is complete and approved by an accredited standard setting organization, we recommend that a request for adopting the new standard be submitted to the DSMOs. See §162.910 for the process to request new standards.
viii. Comment: Several commenters recommended that the Interactive Health Care Eligibility/Benefit Inquiry (IHCEBI) transaction set and its companion, the Interactive Health Care Eligibility/Benefit Response (IHCEBR) transaction set, should also be adopted.
Response: The IHCEBI/IHCEBR is based on UNEDIFACT syntax, not ASC X12N syntax. At the time of the development of the proposed rule, the syntax used was a version subsequently modified by UNEDIFACT, resulting in the need to reformat the messages into the modified syntax before they could be adopted by the UNEDIFACT body. Therefore, there was no uniform implementation specification developed for these standards. After consideration, we decided that, where possible, the transactions to be named in the proposed rule should have a uniform syntax structure. This was possible for all transactions; ASC X12N transactions were chosen because they met the criteria of having implementation specifications and having the same basic syntax structure. The NCPDP standards also met the criteria, and each transaction is designed using the same syntax structure. If, in the future, a millennium compliant interactive eligibility for a health plan transaction standard is approved by an ANSI accredited standards setting organization and an implementation specification exists, we shall consider it for adoption as a HIPAA standard.
ix. Comment: We received one comment that suggested we clarify that the eligibility response sent by a health plan is not the equivalent of a prior authorization of services, and does not guarantee coverage of a rendered service.
Response: We believe that the purpose and scope of the ASC X12N 270/271 is clearly defined in the ASC X12N 270/271 Health Care Eligibility Benefit Inquiry and Response implementation specification. An eligibility response sent by a health plan is not the equivalent of a prior authorization of services and does not guarantee coverage of a rendered service. Furthermore, the function of prior authorization of services is explicitly defined in the ASC X12N 278, Health Care Services Review - Request for Review and Response implementation specification, which is the recommended standard for this transaction.
x. Comment: One commenter suggested that we clarify the requirements to clearly state that while health plans must implement the ASC X12N 270/271 Eligibility Request/Response, they are not required to respond to all requests sent in the ASC X12N 270.
Response: We do not agree. A health plan may not reject a standard transaction because it contains information the health plan does not want. This principle applies to the data elements of all transactions in this rule. Health plans must accept a complete ASC X12N 270 and must respond with all applicable responses that are included in the ASC X12N 271. If health plans can arbitrarily respond or not respond to a standard transaction, then the cost saving effect of using the standards will be blunted by a requirement to negotiate aspects of every transaction with every trading partner.
xi. Comment: One commenter said that the ASC X12N 270 transaction requires an ASC X12N 271 response to every record, a one-to-one correspondence. The commenter recommended that the one-to-one response be negotiable between the parties that have a contract to exchange information.
Response: A one-to-one correspondence to every record is not required. The ASC X12N 270/271 transaction sets were built so that trading partners could use them in real time or batch mode. We agree that negotiation must occur between trading partners (including clearinghouses/switches) regarding the processing limits (i.e., file size, transmission speeds).
g. Transaction Standard for Health Plan Premium Payments
In subpart Q, we proposed the ASC X12N 820 - Payment Order/Remittance Advice, Version 4010, Washington Publishing Company, (004010X061) as the standard for health plan premium payments.
Comments and Responses on the Transaction Standard for Health Plan Premium Payments
The majority of commenters expressed support for the selected standard.
i. Of those comments we referred to ASC X12N, the work groups determined that 53 comments identified areas where the implementation specification could be improved, and the appropriate changes were made.
ii. One comment identified a business need that ASC X12N judged could already be met within the current standard implementation specification. Detailed information on how the current implementation specifications can be used to meet these business needs has been provided by ASC X12N at the Internet site in §162.920.
iii. Six comments alleged technical or editorial errors in the standard implementation specification. A technical review of these issues was conducted by work groups within ASC X12N. The work groups determined that the 6 comments identified areas where the implementation specifications were in fact correct and that no changes were needed. Changes to the implementation specification were not required.
iv. Comment: Several commenters said that health plans must be free to accept premium payment data in non-standard formats if that option is chosen by a sponsor. In the preamble to the proposed rule, we stated that health plans must “accept only the standard specified in §142.1704.” (63 FR 25295). Commenters suggested that we not include the word “only” in the final rule under the health plan requirements. One commenter suggested that we add language in the rule to state: “However, health plans may require trading partners to use the standard transaction to conduct business.”
Response: We recognize that entities such as sponsors perform EDI with health plans. The proposed rule stated that health plans are required to use only the standard specified in §142.1702 for electronic health plan premium payments. Sponsors, one of the primary trading partners with whom the health plans exchange health plan premium payment transactions, were proposed to be excluded. Our reference to the requirements for health plans to accept “only” the standard specified was intended to preclude health plans from using data in formats other than standard when conducting transactions that are standard transactions. It was not intended to impose requirements on sponsors. Thus, sponsors remain free to send health plan premium payments in nonstandard format if they choose, and health plans are free to accept the data.
We expect that sponsors may voluntarily accommodate a health plan’s request to use the ASC X12N 820 by directly submitting the transaction in standard format, or by using a health care clearinghouse to translate non-standard data into the standard format.
v. Comment: One commenter said that Version 3040 is the most widely accepted version of the ASC X12N 820 in the financial community and, therefore, recommended its adoption. The commenter reasoned that by setting the minimum version at 3040, The Secretary would greatly increase the likelihood of successful implementation since it is currently in use for transmitting premium payments.
Response: We did not recommend version 3040 because it was not millennium ready.
vi. Comment: Several commenters, including the Department of the Treasury, said that the ASC X12N 820 should not be named as a payment order format for use by Treasury- disbursed Federal agencies since they use Federal implementation conventions and Treasury payment formats that may not be compatible with this standard. All Federal payment formats disbursed by these agencies must go through a commercial financial institution prior to delivery of the payment to the recipient. It was stated a distinction needs to be made in regard to the function of the X12N 820. It is used as a “payment order” and a “remittance advice” delivery.
Response: The ASC X12N 820 is an appropriate format for use by all covered entities and is designed to provide the information needed to process a payment of health insurance premiums from an employer or other sponsor of health insurance to a health plan. If a Federal agency is a covered entity and conducts a transaction adopted under this part with another covered entity electronically, the transaction must be conducted as a standard transaction. If the other entity is not a covered entity, of course, the standard transaction need not be used unless the Federal agency is a health plan and the other entity requests the standard transaction.
This standard is quite flexible with respect to transfers of funds. The implementation specification for the ASC X12N 820 contains two parts, a mechanism for the transfer of dollars and one for the transfer of information about the payment. It allows these two parts to be transmitted separately. Consistent with the implementation guide, actual payment may be sent in a number of different, equally acceptable ways, including check and several varieties of electronic funds transfer, as long as the detailed information describing the payment is transmitted to the health plan using the ASC X12N 820 directly or indirectly (through a health care clearinghouse or financial institution). When the transfer of funds is part of paying a health care premium the ACH transaction may continue to be used as a valid part of an ASC X12N 820 transaction where the other part of the transaction is sent to the health plan. Although these standard transactions allow transmission of one or both parts through a financial institution, they do not require both parts to be sent to the financial institution, and the financial institution is not required by this regulation to accept or forward such transactions. The Department of the Treasury has confirmed that this standard does not conflict with their requirements for disbursements.
vii. Comment: One commenter asked whether a sponsor must use the 4010 version of the ASC X12N 820.
Response: Section 1172 of the Act identifies the entities required to comply with the HIPAA standards. Sponsors are not included in this provision. If sponsors choose to use the ASC X12N 820, we strongly encourage that they use the version of the standard named in this rule.
h. Transaction Standard for Referral Certification and Authorization
In subpart R, redesignated as subpart M, we proposed the ASC X12N 278 - Health Care Services Review--Request for Review and Response, Version 4010, Washington Publishing Company, (004010X094) as the standard for referral certifications and authorizations.
Comments and Responses on the Transaction Standard for Referral Certification and Authorization
The majority of commenters expressed support for the selected standard.
i. Of those comments we referred to ASC X12N, the work groups determined that 146 comments identified areas where the implementation specification could be improved, and the appropriate changes were made.
ii. Thirteen comments identified business needs that ASC X12N judged could already be met within the current standard implementation specification. Detailed information on how the current implementation specifications can be used to meet these business needs has been provided by ASC X12N at the Internet site in §162.920.
iii. Three comments alleged technical or editorial errors in the standard implementation specification. A technical review of these issues was conducted by work groups within ASC X12N. The work groups determined that the 3 comments identified areas where the implementation specifications were in fact correct and that no changes were needed. Changes to the implementation specification were not required.
iv. There were another 76 comments which identified business needs that ASC X12N judged could not be met directly within the current standard implementation specification. The implementation specifications could not be changed prior to the issuance of the final regulation because the X12 standards development process for modifying standards could not be completed in time. However, a review of the issues by the ASC X12N work groups has identified a means of meeting the business needs within the existing implementation specification as an interim measure. Organizations and individuals who submitted such comments are encouraged to work with the DSMOs to submit a request to modify the national standard.
v. Comment: Several commenters requested that we need to make clear that if a state health agency does not authorize referrals it is not required to use the standard.
Response: If a state health agency does not conduct referral certification and authorization, then the health plan is not required to support this transaction based solely on the fact that the transaction is one named as a HIPAA transaction. However, we note that most commercially available software packages are designed to support a suite of transactions. We anticipate that vendors will offer suites for all HIPAA transactions, which may encourage health plans to support this specific transaction.
vi. Comment: Several commenters recommended that we include the Inquiry and Response and Notification implementations of the ASC X12N 278.
Response: The Request for Review and Response is the only implementation proposed under HIPAA for referral certification and authorization. We are not accommodating this request, because at the time of the development of the proposed rule, the standards development process for the ASC X12N Inquiry and Response and Notification implementation specifications was incomplete and not supported by an accredited standard setting organization. The implementation of the HIPAA standards will be a great undertaking and at this time we are limiting the transactions to those identified in the proposed rule. Entities who use Inquiry and Response and Notification implementations may do so using any available format, including the ASC X12N 278 implementations until such time as we may adopt a standard for Inquiry and Response and Notification through regulation. After the implementation specification for these functions is complete and approved by an accredited standard setting organization, we encourage a request to test a proposed revision to the standard be submitted to the Secretary (see §162.940).
G. Compliance Testing
Proposal Summary: We identified three levels of testing that are typically performed in connection with the adoption and implementation of the proposed standards and their required code sets:
- Level 1--developmental testing, the testing done by the standards setting organization during the development process
- Level 2--validation testing, the testing of sample transactions to see whether they are written correctly.
- Level 3--production testing, the testing of a transaction from a sender through the receiver’s system.
- Pilot production--Because of the billions of dollars that change hands each year as a result of health care claims processing, we stated that we believe the industry should sponsor pilot production projects to test transaction standards that are not in full production prior to the effective date for adoption of the initial HIPAA standard formats.
We also stated that it would be useful to all participants if pilot production projects and the results of pilot projects were posted on a web site for all transactions. For the health care claims or equivalent encounter information transactions, we believe that posting pilot production projects and the results of pilot projects on a web site must be mandatory.
Comments and Responses on Compliance Testing
Comment: The majority of commenters recommended that the posting of pilot production results should be voluntary, not mandatory.
Several commenters suggested that all HIPAA standards projects be posted and that the government should provide funding or at least publicly advertise the results of all compliance testing projects. It was suggested that the Electronic Healthcare Network Accreditation Commission (EHNAC) could host a bulletin board or web site in which tests results could be published.
Several commenters asked whether entities providing validation testing will need to be certified. They stated that validation testing is only useful if certification is obtained. Several commenters recommended that the Secretary endorse the Standard Transaction Format Compliance System (STFCS) process established by EHNAC for validation testing, suggesting that EHNAC certification lends credibility and reliability to the process. However, other commenters wanted certification for compliance to be voluntary.
Several commenters recommended that WEDI, X12, or some other group further develop the various types of testing situations which might occur as well as tentative protocols for handling such tests.
Several commenters wanted the testing processes thoroughly defined prior to the implementation of the standards. For example, commenters wanted costs defined, and testing time frames, scheduling, and turn around times established. Others wanted to gain experience using the transactions first and allow testing to be done on a good faith effort basis.
The majority of commenters recommended that all of the transactions should be tested and any necessary modifications made prior to the publication of the final rule and as early as possible.
Response: We agree that posting of results for any HIPAA standard should be voluntary. As long as the transactions are successfully implemented in production, posting of the results is more of a marketing, advertising, and sales issue than a technical concern.
Since the HIPAA provisions do not require the Secretary to certify compliance with HIPAA standards, the Secretary is not conducting certification reviews or recognizing private organizations that have decided to conduct such reviews. Therefore, any certification of commercial entities performing validation testing will remain in the private domain and be voluntary. While receivers of transactions are likely to test whether a vendor that claims to be HIPAA compliant is, in fact, producing compliant transactions, this is a matter of business practice, and such tests are not being mandated in this rule.
The HIPAA provisions require the Secretary to adopt standards developed by standards setting organizations (SSOs) whenever possible. With this approach, the standards developed by a consensus of the health care industry will be implemented by the health care industry at large. Consistent with this approach, the Secretary is relying on those in the health care arena to come forward and test the designated standards. All of the standards have completed levels 1 and 2 of testing. Some of the standards have completed all three levels of testing and are in full production (for example, the NCPDP standard and many of the data code sets). We urge the health care industry to work in concert with the DSMOs. Health plans and vendors currently define their own test plans and conduct their own tests. We urge health plans to develop pilot test plans using the implementation specifications specified by the Secretary.
Certain types of testing are commonly conducted by organizations that transmit transactions electronically. These include site, unit, integration, connectivity, end to end, and parallel testing. ASC X12N has agreed to solicit private individuals, organizations, vendors and other interested parties to facilitate these types of testing and document their results and conditions on the X12N web site. Many government agencies will test and post results as well. X12N intends to continue to review and refine its testing process to make sure it continues to meet the requirements of the health care industry.
Proposal Summary: Under the statute, failure to comply with standards may result in monetary penalties. The Secretary is required by statute to impose penalties of not more than $100 per violation on any person 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 a single standard for a calendar year.
We did not propose any enforcement procedures, but we will do so in a future Federal Register document.
We did, however, solicit input on appropriate mechanisms to permit independent assessment of compliance.
Comments and Responses on Enforcement
1. Comment: We received many comments regarding the timing of enforcement. Several commenters stated an enforcement and mediating body is needed immediately. The majority of commenters called for the delay of enforcement. Commenters also requested that HCFA permit initial compliance testing of these standard transactions to be based on good faith. It was also recommended that actual testing for compliance occur later. Several commenters said that we should not assess penalties in the first year. A few commenters requested that we establish a body to which a health care provider may go for help. Others requested advance notice of enforcement procedures.
A few commenters requested that we define the terms “person” and “violation,” as well as provide examples of violations and provide descriptions of how penalties will apply. Several commenters requested that fines apply only to health plans and health care clearinghouses, and not to health care providers.
One commenter suggested that the Electronic Healthcare Network Accreditation Commission (EHNAC) be endorsed as a process for establishing compliance in using the standards.
Response: The proposed rule, like the other three notices of proposed rulemakings (NPRMs) published in 1998 to implement the administrative simplification requirements of HIPAA, did not contain provisions for compliance and enforcement. We are, therefore, not adopting any compliance or enforcement provisions in this final rule. As we indicated in the proposed rule, we will be developing a separate compliance and enforcement rule to establish compliance and enforcement procedures for these and other administrative simplification requirements. We plan to publish an NPRM requesting public comments next year, and to subsequently issue a final compliance and enforcement regulation that will become effective prior to the first compliance dates of these rules. We anticipate addressing the specific issues of compliance, timing, appeals, and technical assistance in the projected compliance and enforcement rulemaking. We also plan to address the practicability of using some type of self- certification or certification by external parties to demonstrate compliance with some or all of the requirements.
We encourage covered entities, trading partners and business associates to address issues relating to compliance and resolution of disputes concerning use of these standards in their trading partner agreements. The following resources are available to assist with questions of interpretation and application of specific transactions standards and implementation guides:
For assistance in resolving a particular X12N issue, submit the issue to the X12N Insurance list serve. To subscribe to the X12N Insurance list serve, go to http://www.x12.org.
For additional information regarding the interpretation of the NCPDP standards, go to http://www.ncpdp.org.
The Department will develop a plan for providing technical assistance to covered entities and others affected by the rule. We plan to announce the availability of technical assistance through the Federal Register, various web sites including the Department’s Administrative Simplification web site and the web sites identified above, and through other means.
2. Comment: Several commenters suggested we address educational activities. It was stated that the changes required by the administrative simplification provisions of HIPAA cannot be implemented without a concerted and sustained educational effort.
Response: We agree that HIPAA educational activities are critical to the successful implementation of the standards. Industry organizations, such as X12N have begun to provide education about standard transactions. While not required by this rule, we encourage health care clearinghouses and vendors to educate their customers as well. The Health Care Financing Administration (HCFA) has scheduled a series of regional training sessions for Medicare and Medicaid. They have contracted with instructors who are nationally recognized experts in EDI standards. Medicare and Medicaid have also published health care provider education articles. Copies of these articles may be obtained from local HCFA contractors.
I. New and Revised Standards
We proposed a procedure for entities to follow if they want a new standard. We also proposed a procedure that we would follow if a standard needs to be revised.
Comments and Responses on the Procedures for New and Revised Standards
1. New Standards for Existing Transactions
Proposal Summary: To encourage innovation and promote development of new standards, we proposed to develop a process that would allow an organization to request a replacement of any adopted standard or standards.
An organization could request the replacement of an adopted standard by requesting a waiver from the Secretary of HHS to test a new standard. The organization, at a minimum, would have to demonstrate that the new standard clearly offers an improvement over the adopted standard. If the organization presented sufficient documentation that supported testing a new standard, we wanted to be able to grant the organization a temporary waiver to test the new standard while remaining in compliance with the law. We did not intend to establish a process that would allow organizations to request waivers as a mechanism to avoid using an adopted standard.
Comment: Most commenters supported the proposed process for testing proposed revisions to standards. Several commenters preferred the word “exemption” instead of the word “waiver,” since it makes it clearer that standards should generally not be waived. It was also suggested that the cost benefit analysis should apply to the report developed after the pilot study and not to the application phase of the temporary exemption. Another suggestion was to have organizations wishing to test a new standard submit written concurrences from trading partners who will participate in testing the new standard. Those organizations must also assure they will continue to support existing standards during the testing process.
Response: We agree that standards should generally not be “waived.” We agree with the substance of commenters concern and therefore, we have added language in § 162.940 to include the suggested changes and are using the term “exception” to indicate that the standard generally applies, but that a specific group of entities are not required to follow all or a portion of one standard to permit testing of proposed revisions. While industry practice uses 1 year for testing, we have decided to grant an exception for a period not to exceed 3 years. We decided to adopt a 3 year time frame because we believe this period gives us flexibility in determining the extent to which testing may be required. We emphasize that a new standard is a standard that is not one of the transactions defined in this rule, including code sets. A revised standard is specific to the version of the Secretary’s standard and the implementation specifications.
2. Revised Standards/Proposals for Additional Standards
Proposal Summary: We recognized the very significant contributions that the traditional data content committees (DCCs) (the NUCC, the NUBC, the ADA, and the National Council for Prescription Drug Programs (NCPDP)) have made to the content of health care transactions over the years and, in particular, the work they contributed to the content of the proposed standards in the proposed rule. We proposed that these organizations be designated to play an important role in the maintenance of data content for standard health care transactions. We proposed that these organizations, assigned responsibility for maintenance of data content for standard health care transactions, would work with X12N data maintenance committees to ensure that implementation documentation is updated in a consistent and timely fashion.
We intended that the private sector, with public sector involvement, would continue to have responsibility for defining the data content of the administrative transactions. Both Federal agencies and private organizations would continue to be responsible for maintaining medical data code sets.
a. Code Sets
Comment: Several health care systems, State agencies, and insurance companies submitted comments agreeing that all coding systems adopted as HIPAA standards should have an open updating process, e.g., the responsible panel or committee of experts should be representative of a broad cross-section of the relevant stake-holders; all panel or committee members should have voting privileges, any interested party should be eligible to submit proposals for additions and changes, and the meetings should be announced in advance and should be open to the public. They made specific criticisms of the current processes used for updating HCPCS (for example, no representation from the commercial companies that actually pay claims), CPT, and “The Code” (dental).
Commenters made several favorable comments about the current process for obtaining public input and making decisions regarding changes to ICD-9-CM.
Response: We agree that the current process for making decisions regarding updates to the ICD9-CM provides a useful model, and we consider it to be probably the most workable approach for code sets. This process encourages broad input but gives final decision-making authority to the organizations responsible for developing the code sets. A purely democratic approach, under which all changes are put to a vote by the members of a particular standards committee and any organization eligible to become a voting member, is likely to have significant drawbacks for routine code set maintenance, e.g., delays in updates, inability to make changes that are essential for a minority of players, and changes in the code set that undermine its logical structure. We received clarification from the developers of the “The Code” (dental) and the CPT-4 about their update processes that will be in place at the time these standards are implemented. We are confident that it will be a workable open updating process.
In response to the comments regarding the process for updating HCPCS, we have reviewed our current policies and procedures governing the submission of requests from the public for revisions/changes to the HCPCS. We have ensured that existing procedures are easy to use and are adequately communicated to the public. The current process for updating the HCPCS includes the following features:
- Identification of a central contact for information/assistance regarding the process for submitting requests to modify the coding system.
- Advance notice of meeting agendas.
- Identification of proposals submitted for coding consideration.
- Opportunity for public comment on the proposals.
- Subsequent posting of coding changes for public information.
b. Transaction Standards
Comment: While most commenters supported the proposal that the NUCC, NUBC, and the ADA be designated as the data content committees (DCCs), several commenters opposed this proposal. Commenters opposing designation of these bodies recommended that X12 be named as the sole content body, pointing out that X12 is sufficiently open to include views from the NUCC, NUBC, ADA and others. Some commenters believe that the NUBC and NUCC do not adequately support nor understand the health care providers they represent, and their expertise is grounded in paper rather than electronic transactions. Some commenters opposed selection of the ADA as it was perceived to include inadequate non-health care provider representation for data content issues. Others opposed the selection of the NUCC because it was perceived as non- representative of the full range of health care professionals.
Other commenters stated there should not be a separate DCC for each X12N transaction because a change in one transaction may impact another. Another commenter stated X12 should be allowed to have a permanent voting member on each DCC that is selected, and that X12 should retain responsibility for the maintenance of the data dictionary for the selected transactions. Some commenters recommended that the NUCC, NUBC, and ADA continue to interact with X12N, and did not see a need for government oversight of the process. They felt that the current process works well and should not be tampered with.
Several commenters recommended that these multiple content bodies should have consistent protocols and should implement them uniformly. They recommended that the committees have meetings open to the public with cross-industry representation, including input from the public sector. Commenters also suggested that the committees operate under an equitable consensus process, and that they sign a memo of understanding (MOU) with the Secretary to ensure due process, close cooperation with standard setting organizations, and balanced voting. They asked that the data maintenance and change process for the standards be clearly described in the final rule. A request was also made for the establishment of an oversight group responsible for arbitrating conflicting decisions reached by different data content committees; handling appeals on data content committee decisions; coordinating data requests involving more than one data content committee; and centrally coordinating with X12.
Some commenters recommended that while NUCC, NUBC and ADA have a DCC role, this role should focus primarily on claims information. These committees were not perceived as having experience with enrollment, eligibility, premium payment, remittance, claim status, and referral issues. It was recommended that X12N or another industry forum serve as the data content committee for these other standards.
A few commenters asked that, as an SSO, the NCPDP’s role in the DCC process be addressed in the final rule. A number of comments were also submitted concerning appointment of a DCC for the attachments transaction standard under HIPAA.
Response: Only the NUCC, NUBC, ADA, NCPDP and X12N expressed an interest in having a role as a DCC for the X12N standards selected for the HIPAA transactions in this rule. To address the issues raised by these comments, representatives of the Secretary have contacted many officers and members of the NUCC, NUBC, ADA, NCPDP, X12N, WEDI and other organizations. Discussions centered on the following issues: preferences; operational models; control and coordination issues; time frames for incorporation for a request for a data change in implementation specifications; membership composition; internal processing rules and voting requirements; willingness to serve; expectations; public participation; and other details.
In §162.910, we state that the Secretary may designate an organization(s) to maintain the standards, propose modifications to existing standards, and propose new standards to the National Committee on Vital Health Statistics (NCVHS). These organizations, which can include DCCs (for example, the NUCC) and SSOs (for example, X12N), also receive and process requests for the creation of a new standard, or the modification of an existing standard. In the proposed rule, we referred to these organizations strictly as DCCs and SSOs. In this final rule, we call the organizations that are designated under §162.910 Designated Standard Maintenance Organizations (DSMOs). The DSMOs are a subset of DCCs and SSOs, and we have published a notice announcing these organizations elsewhere in this Federal Register.
We recognize that not every medical specialty or health plan may consider itself to have sufficient voting representation or weight within the DSMOs. Therefore, the DSMOs will operate a process which allows open public access for requesting changes to the standards, consideration of the request by each organization, coordination and final agreement among the DSMOs on the request, an appeals process for a requester of a proposed modification if the final decision is not satisfactory. The DSMO’s process will also allow for an expedited process to address content needs of the industry, and address new Federal legislation within the implementation date requirements of the law. Recommendations will be presented by the DSMOs to the NCVHS, where appropriate. Change requests can be submitted via a designated web site that will be made available to the public.
The DSMOs will also improve coordination among themselves, publicize open meetings, and, in some cases, expand voting membership. The DSMOs understand that their appointments as DSMOs will be reconsidered if they fail to perform, coordinate, and respond to the public as described in §162.910.
J. Proposed Impact Analysis
Proposal Summary: On the same day that we proposed the standards that are the subject of this final rule, we also published a rule to propose the national provider identifier (NPI)(63 FR 25320). In that rule, we set forth an impact analysis that covered the collective impact of most of the administrative simplification standards (including standards for security and the unique identifiers, but not including the costs of privacy standards, which will be detailed in the privacy final rule) since estimating the impact of them individually would be misleading. We did provide an impact analysis that was specific to each standard, but the impact analysis assessed only the relative impact of implementing a given standard.
Conclusion of impact analysis of proposed rules
We estimated that the impact of the proposed rules would result in net savings to health plans and health care providers of $1.5 billion during the first five years; use of the standards would continue to save the industry money.
Comments and Responses on the Proposed Impact Analysis--General
1. Cost/Benefit Analysis
a. Comment: Several commenters questioned the validity of the projected cost of implementing electronic data interchange standards (EDI) because it was based largely on data compiled in 1992 by WEDI. The WEDI report projected implementation costs ranging between $5.3 billion and $17.3 billion with annual savings projected to be between $8.9 billion and $20.5 billion. It was stated the WEDI report projected the costs as being much higher. One reason the projected cost was inflated by WEDI is because the HIPAA compliance process will be spread out over a longer period of time than is provided for in the statute. The HIPAA standards will require additional data elements, will replace local coding schemes with national ones, and will affect many business process associated with health plans and health care providers. Therefore, the modifications to existing systems will be extensive and time consuming, with a high degree of uncertainty regarding the projected benefits. The estimates in this section need to be recalculated taking into account more current figures and trends.
Response: The cost estimates used in the proposal cost analysis were based largely on data compiled in 1992 but updated to reflect 1998 costs. The report developed by WEDI projects implementation costs ranging from between $5.3 billion and $17.3 billion with annual savings projected to be between $8.9 billion and $20.5 billion. The Department has obtained more current data and information on costs and market trends, and these data are used in the final cost analysis. It is an accurate statement that the HIPAA standards would create new data elements and would remove local coding schemes in favor of national ones. However, some of the factors that would cause health care providers or health plans to incur a substantial financial burden have been spread out over a longer period of time than was suggested by the commenters. The removal of local coding schemes, for example, will not occur immediately, but will occur over a two year time period following the publication of this final rule. A longer time frame will spread out the implementation costs and therefore will not pose as great a burden as previously expected. With regard to Medicaid specifically, some of the unusual service type codes (i.e. taxi services) will also not have to be removed.
b. Comment: One commenter stated that although the methodology used in the WEDI report served as a basis for determining the cost/benefit analysis explored within the proposed rule, the concept of cost-benefit analysis is vague and resembles something of a “black art.” Because of the large number of variables and the complexity of the assumptions with which health care providers and health plans will have to deal in implementing of HIPAA, it is hard to determine the actual advantages or disadvantages for the HIPAA standards as a group.
Response: It is difficult to assess the cost and benefits of the HIPAA standards with absolute certainty. While there are no standard methods for doing these analyses, an effort was made not to overstate the benefits or understate the costs of implementation. The WEDI report is the most extensive industry analysis of the effects of EDI standards available.
c. Comment: Several commenters stated that the sweeping changes that HIPAA mandates make it difficult to do a precise cost-benefit analysis. One commenter noted that additional actuarial studies should be done, with the cooperation of health plans and health care providers. The commenter also stated that pilot programs should be initiated in different geographic regions in order to identify the feasibility of the scope and time frames for HIPAA implementation. Another commenter stated that they believed that the costs associated with the NPI and subsequent system changes required of covered entities may run into the six-figure range, which is not mentioned in the proposed rule.
Response: It is difficult to assess the cost and benefits of the HIPAA standards with complete accuracy. This is particularly true considering that these changes have no historical precedent. While initiating pilot programs in each region and conducting further actuary studies may provide detailed analysis, it is neither feasible nor practical. The time frame for implementation, as mandated by the statute, precludes this. The analysis given was derived from aggregate figures that provided the most realistic impact in terms of costs and savings. NPI costs are currently being evaluated by the Department of Health and Human Services and will be published in the final rule regarding the NPI.
d. Comment: Several commenters expressed concern with the cost-benefit analysis in regard to Medicaid. One commenter stated that dismantling 80% of the Medicaid systems that process EDI in order to accommodate the HIPAA standards will result in a loss. Furthermore, it was noted that the use of a dual health care provider assignment number will continue to be used in their Medicaid Management Information System (MMIS) which would mitigate any cost savings benefit.
Response: The rationale behind the Impact Analysis was to evaluate the cost and savings for the health care system as a whole. While the cost to a specific health plan or health care provider may outweigh the benefits to that entity, our analysis showed overall savings to the health care system. There is a greater possibility for savings in the future due to use of a common identifiers, the increased simplicity of processing transactions, and the overall coordination of benefits. We do not anticipate an immediate need to overhaul an entire system, but we do expect some implementation costs which have been factored into the analysis. Translation software may be purchased at reasonable cost thus avoiding major reprogramming. (Since the translators will not affect the issues raised, they should have no impact.) Health plans and health care providers may also use a health care clearinghouse to perform the translation. We believe entities that use health care clearinghouses will see costs reduced or at least stabilized.
We do acknowledge that the $1 million cost estimate for redesigning a State Medicaid system to accommodate these standards may have been too low. Further analysis indicated that costs to individual State Medicaid programs may be in the $10 million range. While the cost in each State may differ somewhat, the Federal government will pay approximately 75 - 90 percent of these costs, leaving the costs to each State near the $1-2.5 million range. We believe that long-term benefits to States will outweigh the costs.
e. Comment: Several commenters stated that many of the numbers associated with our analysis were based upon calculations using aggregate data instead of evaluating the standards individually. It was stated that a separate assessment of each standard would yield more realistic results because the staged release of the proposed rules led to the impression that the HIPAA standards will be implemented in a staggered fashion. Assessing the cost of implementing each standard independently would not yield inflated costs, but would yield numbers that would approximate what the actual costs will be. A number of commenters suggested different approaches to make the rules more effective and beneficial, as well as make the implementation more orderly. One such approach was that the implementation of all of the standards be postponed until all of the proposed rules are published (e.g., a single harmonized implementation date based on the date of the last published rule), perhaps with the exception of those standards that have been deferred such as the First Report of Injury and the Patient Identifier. Another would be to break down the implementation into phases. The first phase would be full implementation of the standards within 2 years of the publication dates of the final rule for identifiers for health care providers, employers, and health plans. Phase 2 would be the full implementation of all the transactions including attachments and the security rule within 2 years of the publication of the last of these final rules. Phase 3 would be the implementation of the individual identifier within 2 years after the publication of the identifier final rule. The last recommended approach is the simultaneous publication of the final rules for the health care provider, health plan and employer identifiers; the transaction sets, including the First Report of Injury and the attachments; and the security regulations. This method would ensure that health care providers and vendors will have the changes necessary for both internal application systems and external communications.
Response: While the original plan was to implement all of the standards at the same time, the realities of the regulatory process and the impact of millennium activities will cause a variety of effective dates. This rule is the first to be published, with other rules for standards following shortly. It is difficult to assess the cost-benefit of each standard individually because there are costs and benefits associated with the interaction of many of the standards. It is more realistic to assess cost-benefits of standardizing EDI in general, using aggregate data to give a more complete picture, than attempting to measure the impact of each standard. Many of the numbers associated with this analysis are based upon calculations using aggregate data.
2. Implementation Costs
a. Comment: One commenter noted that a translator does not address the problems health care providers will have in relating their health care provider type to State billing systems or in billing local codes.
Response: The local code issue has been addressed in this rule. The health care provider type issue will be addressed in the final rule for the National Provider Identifier. Translators will allow health care providers to accommodate most of the business process changes required by this rule.
b. Comment: Several commenters stated that we greatly underestimated the implementation costs. They claimed that the costs associated with translator devices were not included, and upgrades to EDI systems could continue annually and could involve multiple standards which would not be classified as short-term costs. Furthermore, it was stated that all methods of complying with the HIPAA requirements will have costs associated with them that will not be limited to the first three years of implementation. There will be ongoing costs for training and support that will surpass the estimates given by the impact analysis. In addition, third-party administrators opting for in-house programming have already spent large sums of money to prepare for administrative simplification before compliance is mandated. Some commenters fear that health care clearinghouses will potentially charge high yearly fees and high transaction fees due to an increase in demand. They believe high fees will not be eliminated after the three year time frame has ended and the costs could be passed on to health care providers, health plans and purchasers. Finally, while the proposed rule proposed the elimination of data entry clerks and mailing costs, it did not account for software engineers that will be needed to redesign or reprogram a system. The personnel costs associated with these individuals could be 4-6 times as high as a data entry clerk.
Response: These comments raise several important issues. The first one deals specifically with the cost of a translator. The cost of translators, in fact, were included in estimating upgrade costs. In addition, some of these EDI standards would have occurred without the passage of HIPAA due to the demands of the health care industry. Many of the other costs mentioned, such as costs for training and support, would have also occurred whether or not standards were mandated, so we do not believe them relevant to the impact of this rule. The financial data given in the Impact Analysis was based on the most reasonable estimates available and took into account the implementation costs, including software engineering, that will be incurred during the first three years. This justifies the categorization of expenditures associated with the HIPAA standards as one-time or short-term. All of the costs associated with a system upgrade have been included in the implementation time-frame noted in the Proposed Rule. Finally, redesigning or reprogramming work that will be done in accordance with this regulation has been included in the implementation costs. While it is an aggregate amount, it provides the most realistic estimate based on available data. Health care clearinghouse charges can be expected to decrease due to market forces.
c. Comment: One commenter noted that the statement that increased EDI claims submission has the potential to improve cash flow because those who use EDI get their payments faster runs counter to HCFA’s decision to instruct its contractors to increase the waiting period before they issue checks to a health care provider. It was stated that HCFA’s decision may cause cash flow problems for physicians and mute the benefits of increased efficiency that are supposed to be generated by electronic claims submission. It was also stated that HCFA needs to refrain from taking actions that run counter to realizing the benefits envisioned by Congress and specified in the statute.
Response: Health care providers will share in many benefits of administrative simplification. HCFA is fully supportive of administrative simplification and will examine this issue carefully to ensure that there is no conflict. We have not instructed our contractors to change the waiting period for payment of Medicare claims, be they paper or electronic.
d. Comment: One commenter stated that before the industry begins to use any of the transactions in production, the National Provider System (NPS) should be fully loaded and tested. It was recommended that all health care providers be enumerated and NPS data should be ready for use on all transaction sets required under HIPAA within the first six months of the implementation period.
Response: The proposed rule acknowledged that there is a strong likelihood that implementation problems will result in rejected transactions, manual exception processing, payment delays, and requests for additional information. Therefore, the transaction formats allow for the use of current/legacy identifiers until the NPS is fully implemented. As recommended by a number of commenters, we have concluded that it would be best to implement the transactions and make sure they are implemented correctly before we begin requiring the identifiers be to used in the transactions.
e. Comment: Several commenters representing Medicaid have raised the notion that costs, both initial and long-term, will be far more expensive than originally anticipated. For example, one commenter stated that they currently use intelligent health care provider numbers with extensive hard coding and editing. Changing their MMIS would require changing the basic logic of 11 subsystems and 3 million lines of code. Another commenter estimated they will spend $6.5 million to implement the HIPAA standards despite the fact that 78% of their claims are already submitted electronically.
Response: The Impact Analysis generalized that standardization can be expected to lead to cost-effectiveness and avoidance of burden (see also the response to the comment in J. 1. d. in this section of the preamble). A number of States have provided cost estimates which indicate that the $1 million figure given may be too low. We do not disagree with this assertion, but believe that the costs will be spread out over a longer period of time than expected, and will not be as severe as anticipated. The costs to States to implement the HIPAA standards were carefully considered, but were not the only factor considered in developing the individual standards. A number of guiding principles (see B. Guiding Principles for Standard Selection in section IV. of this preamble) were followed and the overall adequacy and acceptance of these standards is dependent upon the standards meeting these guiding principles.
f. Comment: Several commenters expressed concern that the implementation time frame falls within the time period required to make millennium and Medicare Balanced Budget Act (BBA) changes. It was stated that the industry was given little flexibility in determining the most cost-effective way to implement the HIPAA standards.
Response: The Impact Analysis states that health care providers have considerable flexibility in determining how and when to accomplish changes in their systems to accommodate the HIPAA standards. Due to the longer than expected time to publish this final rule, the implementation time frame will fall beyond millennium changes and most BBA changes. Therefore, it is still possible to evaluate the most cost-effective approach.
g. Comment: One commenter stated that the impact analysis did not specifically mention who would provide the translator software that would be integrated into an existing system. If small physician practices are using older “legacy” type systems, they may not be able to create an interface with a translator that would accept the standard data. A complete system overhaul would be extremely costly to these specific health care provider groups.
Response: The Impact Analysis did not specifically mention who would provide the translator software that would be integrated into an existing system because we expect such software to be readily available on the open market. However, it did include estimates from the WEDI reports which were updated to reflect the current costs for small practices to convert their systems in order to use the standard formats. These estimates indicate an overall cost savings for physician practices. The most efficient way for small physician practices to circumvent high implementation costs may be to use a health care clearinghouse. If health care providers cannot create an interface with a translator, they have the option to use a health care clearinghouse. This would avoid the need to overhaul older type systems in order to accommodate the HIPAA standards. Furthermore, the costs for vendors and health care clearinghouses should be reduced due to the use of national EDI standards as well as the NPI. The overall homogeneity of these EDI formats should significantly reduce the high costs associated with the processing of different electronic claims formats. In turn, this would allow vendors and health care clearinghouses to provide services at lower costs, which should enable savings to be passed on to health care providers. In this regard, we also anticipate that market competition should tend to keep costs down.
h. Comment: One commenter believed that as part of a 1999 Presidential proposal, Medicare will charge one dollar for each paper Medicare claim that a physician submits. The commenter stated that this unfairly undermines a physician’s ability to continue to submit paper claims.
Response: Medicare has not instituted a user fee for paper claims.
3. Benefits of Increased EDI for Health Care Transactions
Comment: One commenter stated that the impact analysis should factor in the cost of dismantling existing electronic interchange systems. It was also stated that health care providers may move from electronic to paper submission if they feel that the costs and burdens associated with the new standards are too great.
Response: There is no need to dismantle entire systems. Rather, provisions need to be made to accommodate the new standards. We believe that the benefits health care providers are currently realizing through EDI will continue and will increase with the adoption of these standards. Unlike current practices which compel health care providers to use multiple formats when sending and receiving, health care providers will only need to use one format for each HIPAA standard when they send and receive. If health care providers are unwilling to upgrade their EDI system, they have the option of using a health care clearinghouse, or reverting to paper claim submission.
4. The Role of Standards in Increasing the Efficiency of EDI
Comment: One commenter stated that there are many factors affecting a health care provider’s decision as to when to convert to EDI. Thus, the idea that a health care provider may decide to delay conversion to EDI until it is “cost-effective” is made moot by other forces affecting a health care provider’s decision making process.
Response: Health care providers must use the standards if they wish to do business electronically. While other factors will impact their decision to do business electronically, we believe that the HIPAA standards will produce cost savings and efficiencies in EDI which should help convince health care providers of the benefits of EDI.
All known factors that may influence a health care provider’s decision were taken into account when the proposed rule was written and published. However, other factors may arise that were not accounted for. It is impossible to account for every possible scenario for every health care provider. The Impact Analysis took into account factors based on the data available at the time. These factors, which represent a wide spectrum of possibilities, were included in the cost-effectiveness figures and the overall decision making process.
5. Cost/Benefit Tables
a. Comment: Several commenters representing Medicaid had a number of comments regarding these tables. First, with respect to Table 1 (63 FR 25344) (see VI. Final Impact Analysis, I. Cost/Benefit Tables of this preamble for the updated table) they stated it was difficult to assess where Medicaid was represented or whether any other Federal program was included. Second, regarding that same table, it was stated that the method of allocating savings was imprecise and illogical when consideration is given to existing EDI systems that will have to be changed. For high end-users, the costs to convert will consume most of the savings. Third, because so much of Medicaid is automated already, the estimated savings that will offset 50% of the upgrade cost will be less. The cost assumptions are also not inclusive of the numerous operational activities associated with the possible role of the enumerator. One Medicaid Agency specifically mentioned that they pay their fiscal associate $.2672 to process any type of claim. They stated that the savings estimates based on $1 per claim for health plans and physicians and $.75 per claim for hospitals and other health care providers does not relate to their experience.
Response: Medicare and Medicaid program costs and savings were not included in the table on cost and savings to health plans because the Impact Analysis was done for private sector health plans only, as required. Cost estimates were made using the WEDI report and may not be specific to Medicaid or other State Agencies. They are also not specific to any unique experience. The savings mentioned in the analysis are based on overall utilization.
b. Comment: Several commenters stated that the pharmacist enumeration costs were underestimated. Table 2 (63 FR 25344) (see VI. Final Impact Analysis, I. Cost Benefit/Tables of this preamble for the updated table) lists 70,100 pharmacies; however, no data was included regarding the number of pharmacists. There are about 200,000 pharmacists. It was stated that the enumeration costs should be adjusted accordingly.
Response: We did not enumerate pharmacists, because the pharmacy is the entity that does most of the billing and, therefore, is the appropriate unit for analysis.
c. Comment: One commenter raised several questions regarding Table 4a (63 FR 25346), which shows relative savings and volume of other transactions (note, Table 4a corresponds to Table 5 in VI. Final Impact Analysis, I. Cost/Benefit Tables of this preamble): (1) was the ASC X12N 997 transaction included in the “Claim” transaction in Table 4a; (2) was the ASC X12N 277 included in the “Claims Inquiry” transaction; (3) does the “Remittance Advice” include payment data and Electronic Funds Transfer (EFT) payment; (4) has allowance been made for any charges by banks for passing on the payment data; (5) is the ASC X12N 275 included in one of the transactions listed; and (6) how was the “Average Cost for Non-EDI Health Plans” calculated?
Response: (1) The ASC X12N 997 is not a HIPAA transaction standard and was not included. (2) The ASC X12N 277 does represent a HIPAA transaction standard and was included in the analysis. (3) The “Remittance Advice” includes payment data and EFT payment. (4) The cost of the banks processing data was not included in the impact analysis because the EFT process will remain the same under the standards. Banks are not required to use the HIPAA standards; however, most, if not all, are expected to continue to use the Automated Clearinghouse (ACH) standard which they are now using for EFT (and which would be compliant with these standards). (5) The ASC X12N 275 was not included in the transactions listed. (6) The cost to non-EDI health plans was computed as follows: total entities x (1-EDI %) x average upgrade cost x 0.5.
d. Comment: One commenter stated that more information is needed on the methodology used to calculate the costs/benefits in order for each hospital to model the cost/benefits.
Response: The methodology for calculating the costs/benefits for health care providers was derived from the WEDI report and was mentioned at the beginning of the Impact Analysis. The WEDI report also documents how that methodology was applied.
6. Quantitative Impacts of Administrative Simplification
a. Comment: In regard to Medicaid, commenters noted that with the mandatory nature of EDI rules, the obligation to coordinate “who pays when” was not included (i.e., Medicaid is the payer of last resort). It was stated that standardization of data and transactions alone will not help unless health plans pass on those rules. Administrative simplification could facilitate coordination of benefits by having a standardized set of data that is known to all parties, along with standardized name and address information that tells where to route transactions.
Response: We agree that standardization will facilitate coordination of benefits by having in place a standardized set of data. This is one of the goals of administrative simplification. The HIPAA standards do require health plans to use the standard COB transaction for exchanging COB with other health plans.
b. Comment: Some comments stated that the administrative burden for health plans may increase as more data validation occurs in a post-adjudication environment. It was stated that the example of staff translation of codes due to standardized codes was misleading, since individuals must still perform coding actions in order to enter patient data into the hospital information system or other patient data systems.
Response: The implementation of the HIPAA standards will actually reduce the overall need for data validation as it will reduce the need for clerical entry. Although there may still be individual manipulation or translation of codes, it will be less labor intensive; this result will be due to the replacement of multiple EDI formats with one set of nationally accepted standards.
c. Comment: One commenter stated that the cost to maintain a proprietary health care provider file may remain basically the same or may increase as there may be an increased need to validate data between the proprietary file and the National Provider System database (NPS); this result would more than offset any savings that may have been realized through the elimination of other health care provider numbers.
Response: When the NPI is implemented, there will be a one time cost to entities to align their proprietary health care provider files to NPS data and add the NPI to their files. Once the NPI has been added, though, we would expect ongoing costs for several functions (COB, health care provider monitoring, communications with health care providers, etc.) to be reduced because of the uniform numbering system and the elimination of health care provider enumeration activities by individual health plans.
7. Regulatory Flexibility Analysis
a. Comment: One commenter recommended that the statement “cost savings will be passed on to customers of health care clearinghouses and billing agencies” should be reworded to state that cost savings “should” be passed on rather than imply that they will. It is possible that these savings won’t be passed on because health care clearinghouses may be in a position to profit from the increased demand for their services. The possibility also exists that costs will decrease, and as a result prices will drop to reflect these savings.
Response: We believe that market forces will drive down costs, and as a result savings will be passed on to customers of health care clearinghouses and billing agencies.
b. Comment: One commenter stated that there is no guarantee that small health care providers will embrace EDI. There should be information about educational campaigns and how that educational outreach will occur.
Response: The Impact Analysis acknowledges that not everyone will move to the HIPAA standards and use EDI. However, since the catalyst behind this statute was the health care industry, we expect that health plans and others will recognize the benefits they can enjoy through administrative simplification, and will educate health care providers so that benefits will be realized.
8. Unfunded Mandates
a. Comment: Several commenters stated that it is possible that a portion of the costs which managed care organizations will incur due to HIPAA will be passed onto the Medicaid program in the form of increased capitation payments. It was stated that while the Secretary puts forth a Cost Budget Office (CBO) analysis indicating that States “have the option to compensate by reducing other expenditures,” they have first-hand knowledge of the challenges associated with “reducing” expenditures associated with entitlement programs. Furthermore, enrollment of Medicaid recipients into managed care programs does not eliminate the need for fee-for-service claims processing under the new standards. One commenter noted that $2 million is a conservative estimate of the cost to a State to modify its MMIS to comply with the HIPAA mandates. The improvements offered are geared towards EDI between commercial health plans and their health care providers. Benefits of increased EDI and health care provider enumeration accrue to all EDI participants at the expense of the Medicaid program.
Response: We do not agree that the benefits of EDI for the health care community would increase at the expense of the Medicaid program. We acknowledge that the implementation costs for each State may be underestimated. However, the benefits of administrative simplification should accrue to every health care entity, whether public or private. The costs to the Medicaid program will be spread out over a longer period of time than expected, which will mitigate any large financial impact. Additional provisions were also included for specialized delivery services. The Department will match 75 - 90% of the costs associated with the MMIS and the new software that will be integrated for the HIPAA standards. The long-term savings will offset implementation costs. We recognize that fee-for-service claims processing will continue.
b. Comment: Several commenters stated that it may be an inaccurate conclusion that the unfunded mandates of HIPAA will not result in significant costs to State governments. In fact, it may cost States between $2 and $10 million to restructure for HIPAA compliance. Furthermore, the start-up costs will be high in order to align current health care provider files with the NPS so that matches can be made. Start-up costs will probably exceed $1 million per health plan. There are also additional indirect costs which are not mentioned. Indirect costs may arise from having to reorganize business functions and possibly having to pay the implementation costs of health care providers, health care clearinghouses and health plans.
Response: We agree that the calculated costs may be underestimated and the Impact Analysis does state that it is difficult to assess cost/benefits of such a sweeping change. Many of the costs mentioned in the comment are short-term costs. The long-terms savings that will accrue from administrative simplification will offset the short-term expenditures. Each health care provider will have to determine how to treat these initial costs until the savings begin to accrue.
c. Comment: One commenter stated that many areas of the payment processes are still done manually. Changes/upgrades to bulletin board type systems that receive electronic billing data from health care providers will also impact the costs of this unfunded mandate.
Response: The costs associated with these bulletin board type systems have been included in the estimated cost of system upgrades mentioned in the Impact Analysis.