[Federal Register Volume 65, Number 160 (Thursday, August 17, 2000)]
[Rules and Regulations]
[Pages 50312-50372]
From the Federal Register Online via the Government Publishing Office [www.gpo.gov]
[FR Doc No: 00-20820]



[[Page 50311]]

-----------------------------------------------------------------------

Part III





Department of Health and Human Services





-----------------------------------------------------------------------



Office of the Secretary



Health Care Financing Administration



-----------------------------------------------------------------------



45 CFR Parts 160 and 162



Health Insurance Reform: Standards for El

[[Page 50312]]

ectronic Transactions; Announcement of Designated Standard Maintenance 
Organizations; Final Rule and Notice

  Federal Register / Vol. 65, No. 160 / Thursday, August 17, 2000 / 
Rules and Regulations  
-----------------------------------------------------------------------

DEPARTMENT OF HEALTH AND HUMAN SERVICES

Office of the Secretary

45 CFR Parts 160 and 162

[HCFA-0149-F]
RIN 0938-AI58


Health Insurance Reform: Standards for Electronic Transactions

AGENCY: Office of the Secretary, HHS.

ACTION: Final rule.

-----------------------------------------------------------------------

SUMMARY: This rule adopts standards for eight electronic transactions 
and for code sets to be used in those transactions. It also contains 
requirements concerning the use of these standards by health plans, 
health care clearinghouses, and certain health care providers.
    The use of these standard transactions and code sets will improve 
the Medicare and Medicaid programs and other Federal health programs 
and private health programs, and the effectiveness and efficiency of 
the health care industry in general, by simplifying the administration 
of the system and enabling the efficient electronic transmission of 
certain health information. It implements some of the requirements of 
the Administrative Simplification subtitle of the Health Insurance 
Portability and Accountability Act of 1996.

DATES: The effective date of this rule is October 16, 2000. The 
incorporation by reference of certain publications listed in this rule 
is approved by the Director of the Federal Register as of October 16, 
2000.

FOR FURTHER INFORMATION CONTACT: Pat Brooks, (410) 786-5318, for 
medical diagnosis, procedure, and clinical code sets.
    Joy Glass, (410) 786-6125, for the following transactions: health 
claims or equivalent encounter information; health care payment and 
remittance advice; coordination of benefits; and health claim status.
    Marilyn Abramovitz, (410) 786-5939, for the following transactions: 
enrollment and disenrollment in a health plan; eligibility for a health 
plan; health plan premium payments; and referral certification and 
authorization.

SUPPLEMENTARY INFORMATION:

Availability of Copies

    To order copies of the Federal Register containing this document, 
send your request to: New Orders, Superintendent of Documents, P.O. Box 
371954, Pittsburgh, PA 15250-7954. Specify the date of the issue 
requested and enclose a check or money order payable to the 
Superintendent of Documents, or enclose your Visa or Master Card number 
and expiration date. Credit card orders can also be placed by calling 
the order desk at (202) 512-1800 or by faxing to (202) 512-2250. The 
cost for each copy is $8. As an alternative, you can view and photocopy 
the Federal Register document at most libraries designated as Federal 
Depository Libraries and at many other public and academic libraries 
throughout the country that receive the Federal Register. You may also 
obtain a copy from the following web sites: http://www.access.gpo.gov/
su--docs/aces/aces140.html; http://aspe.hhs.gov/admnsimp/.

I. Background

A. Electronic Data Interchange

    Electronic data interchange (EDI) is the electronic transfer of 
information, such as electronic media health claims, in a standard 
format between trading partners. EDI allows entities within the health 
care system to exchange medical, billing, and other information and to 
process transactions in a manner which is fast and cost effective. With 
EDI there is a substantial reduction in handling and processing time 
compared to paper, and the risk of lost paper documents is eliminated. 
EDI can eliminate the inefficiencies of handling paper documents, which 
will significantly reduce administrative burden, lower operating costs, 
and improve overall data quality.
    The health care industry recognizes the benefits of EDI and many 
entities in that industry have developed proprietary EDI formats. 
Currently, there are about 400 formats for electronic health claims 
being used in the United States. The lack of standardization makes it 
difficult and expensive to develop and maintain software. Moreover, the 
lack of standardization minimizes the ability of health care providers 
and health plans to achieve efficiency and savings.

B. Statutory Background

    The Congress included provisions to address the need for standards 
for electronic transactions and other administrative simplification 
issues in the Health Insurance Portability and Accountability Act of 
1996 (HIPAA), Public Law 104-191, which was enacted on August 21, 1996. 
Through subtitle F of title II of that law, the Congress added to title 
XI of the Social Security Act a new part C, entitled ``Administrative 
Simplification.'' (Public Law 104-191 affects several titles in the 
United States Code. Hereafter, we refer to the Social Security Act as 
the Act; we refer to the other laws cited in this document by their 
names.) The purpose of this part is to improve the Medicare program 
under title XVIII of the Social Security Act and the Medicaid program 
under title XIX of the Act, and the efficiency and effectiveness of the 
health care system, by encouraging the development of a health 
information system through the establishment of standards and 
requirements to enable the electronic exchange of certain health 
information.
    Part C of title XI consists of sections 1171 through 1179 of the 
Act. These sections define various terms and impose several 
requirements on HHS, health plans, health care clearinghouses, and 
certain health care providers.
    The first section, section 1171 of the Act, establishes definitions 
for purposes of part C of title XI for the following terms: code set, 
health care clearinghouse, health care provider, health information, 
health plan, indiyvidually identifiable health information, standard, 
and standard setting organization (SSO).
    Section 1172 of the Act makes any standard adopted under part C 
applicable to (1) all health plans, (2) all health care clearinghouses, 
and (3) any health care provider who transmits any health information 
in electronic form in connection with transactions referred to in 
section 1173(a)(1) of the Act.
    This section also contains requirements concerning standard 
setting.
     The Secretary may adopt a standard developed, adopted, or 
modified by a standard setting organization (that is, an organization 
accredited by the American National Standards Institute (ANSI)) that 
has consulted with the National Uniform Billing Committee (NUBC), the 
National Uniform Claim Committee (NUCC), the Workgroup for Electronic 
Data Interchange (WEDI), and the American Dental Association (ADA).
     The Secretary may also adopt a standard other than one 
established by a standard setting organization, if the different 
standard will reduce costs for health care providers and health plans, 
the different standard is promulgated through negotiated rulemaking 
procedures, and the Secretary consults with each of the above-named 
groups.
     If no standard has been adopted by any standard setting 
organization, the Secretary is to rely on the recommendations of the 
National Committee on Vital and Health Statistics (NCVHS) and consult 
with the above-named groups before adopting a standard.

[[Page 50313]]

     In complying with the requirements of part C of title XI, 
the Secretary must rely on the recommendations of the NCVHS, consult 
with appropriate State and Federal agencies and private organizations, 
and publish the recommendations of the NCVHS regarding the adoption of 
a standard under this part in the Federal Register.
    Paragraph (a) of section 1173 of the Act requires that the 
Secretary adopt standards for financial and administrative 
transactions, and data elements for those transactions, to enable 
health information to be exchanged electronically. Standards are 
required for the following transactions: health care claims or 
equivalent encounter information, health claims attachments, health 
plan enrollments and disenrollments, health plan eligibility, health 
care payment and remittance advice, health plan premium payments, first 
report of injury, health care claim status, and referral certification 
and authorization. Section 1173(a)(1)(B) authorizes the Secretary to 
adopt standards for any other financial and administrative transactions 
as she determines appropriate.
    Paragraph (b) of section 1173 of the Act requires the Secretary to 
adopt standards for unique health identifiers for each individual, 
employer, health plan, and health care provider. It also requires that 
the adopted standards specify for what purposes unique health 
identifiers may be used.
    Paragraphs (c) through (f) of section 1173 of the Act require the 
Secretary to adopt standards for code sets for each data element for 
each health care transaction listed above, security standards to 
protect health care information, standards for electronic signatures 
(established together with the Secretary of Commerce), and standards 
for the transmission of data elements needed for the coordination of 
benefits and sequential processing of claims. Compliance with 
electronic signature standards will be deemed to satisfy both State and 
Federal statutory requirements for written signatures with respect to 
the transactions listed in paragraph (a) of section 1173 of the Act.
    In section 1174 of the Act, the Secretary is required to adopt 
standards for all of the above transactions, except claims attachments, 
within 18 months after enactment. The standards for claims attachments 
must be adopted within 30 months after enactment. Modifications to any 
established standard may be made after the first year, but not more 
frequently than once every 12 months. The Secretary may, however, 
modify an initial standard at any time during the first year of 
adoption, if she determines that the modification is necessary to 
permit compliance with the standard. The Secretary must also ensure 
that procedures exist for the routine maintenance, testing, 
enhancement, and expansion of code sets and that there are crosswalks 
from prior versions. Any modification to a code set must be implemented 
in a manner that minimizes the disruption and the cost of compliance.
    Section 1175 of the Act prohibits health plans from refusing to 
conduct a transaction as a standard transaction. It also prohibits 
health plans from delaying the processing of, or adversely affecting or 
attempting to adversely affect, a person submitting a standard 
transaction or the transaction itself on the grounds that the 
transaction is in standard format. It establishes a timetable for 
compliance: each person to whom a standard or implementation 
specification applies is required to comply with the standard no later 
than 24 months (or 36 months for small health plans) following its 
adoption. With respect to modifications to standards or implementation 
specifications made after initial adoption, compliance must be 
accomplished by a date designated by the Secretary. This date may not 
be earlier than 180 days after the modification is adopted by the 
Secretary.
    Section 1176 of the Act establishes civil monetary penalties for 
violation of the provisions in part C of title XI of the Act, subject 
to several limitations. Penalties may not be more than $100 per person 
per violation of a provision, and not more than $25,000 per person per 
violation of an identical requirement or prohibition for a calendar 
year. With certain exceptions, the procedural provisions in section 
1128A of the Act, ``Civil Monetary Penalties,'' are applicable to 
imposition of these penalties.
    Section 1177 of the Act established penalties for any person that 
knowingly misuses a unique health identifier, or obtains or discloses 
individually identifiable health information in violation of this part. 
The penalties include: (1) A fine of not more than $50,000 and/or 
imprisonment of not more than 1 year; (2) if the offense is ``under 
false pretenses,'' a fine of not more than $100,000 and/or imprisonment 
of not more than 5 years; and (3) if the offense is with intent to 
sell, transfer, or use individually identifiable health information for 
commercial advantage, personal gain, or malicious harm, a fine of not 
more than $250,000 and/or imprisonment of not more than 10 years. We 
note that these penalties do not affect any other penalties that may be 
imposed by other federal programs.
    Under section 1178 of the Act, the provisions of part C of title XI 
of the Act, as well as any standards or implementation specifications 
adopted under them, generally supersede contrary provisions of State 
law. However, the Secretary may make exceptions to this general rule if 
she determines that the provision of State law is necessary to prevent 
fraud and abuse, ensure appropriate State regulation of insurance and 
health plans, or for State reporting on health care delivery or costs, 
among other things. In addition, contrary State laws relating to the 
privacy of individually identifiable health information are not 
preempted if more stringent than the related federal requirements. 
Finally, contrary State laws relating to certain activities with 
respect to public health and regulation of health plans are not 
preempted by the standards adopted under Part C or section 264 of 
Public Law 104-191.
    Finally, section 1179 of the Act makes the above provisions 
inapplicable to financial institutions or anyone acting on behalf of a 
financial institution when ``authorizing, processing, clearing, 
settling, billing, transferring, reconciling, or collecting payments 
for a financial institution.''

II. General Overview of the Provisions of the Proposed Rule

    On May 7, 1998, we proposed standards for eight transactions (we 
did not propose a standard for either health claims attachments or 
first report of injury) and for code sets to be used in the 
transactions (63 FR 25272). In addition, we proposed requirements 
concerning the implementation of these standards. This proposed rule 
set forth requirements that health plans, health care clearinghouses, 
and certain health care providers would have to meet concerning the use 
of these standards.
    We proposed to add a new part 142 to title 45 of the Code of 
Federal Regulations to include requirements for health plans, certain 
health care providers, and health care clearinghouses to implement 
HIPAA administrative simplification provisions. This material has been 
restructured to accommodate HIPAA privacy and security provisions, and 
is now contained in parts 160 and 162 of title 45. Subpart A of part 
160 contains the general provisions for all parts. Subpart I of part 
162 contains the general provisions for the standards proposed in the 
Standards for Electronic

[[Page 50314]]

Transactions proposed rule. Subparts J through R contain the provisions 
specific to each of the standards proposed in the Standards for 
Electronic Transactions proposed rule.

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

    In response to the publication in the Federal Register of the 
proposed rule on May 7, 1998, we received approximately 17,000 timely 
public comments. The comments came from a wide variety of 
correspondents including professional associations and societies, 
health care workers, law firms, third party health insurers, hospitals, 
and private individuals. We reviewed each commenter's letter and 
grouped like or related comments. Some comments were identical, 
indicating that the commenters had submitted form letters. After 
associating like comments, we placed them in categories based on 
subject matter or based on the section(s) of the regulations affected 
and then reviewed the comments. All comments relating to general 
subjects, such as the format of the regulations were similarly 
reviewed.
    This process identified areas of the proposed regulation that 
required review in terms of their effect on policy, consistency, or 
clarity of the rules.
    We present comments and responses generally in the order in which 
the issues appeared in the May 1998 proposed rule.

General--Comment Period

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

A. Applicability

    In subpart A Sec. 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 Sec. 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

[[Page 50315]]

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 
Sec. 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

[[Page 50316]]

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 
Sec. 160.103) with a health plan as a standard transaction, the 
following apply:
    (1) The health plan may not refuse to conduct the transaction as a 
standard transaction.
    (2) The health plan may not delay the transaction or otherwise 
adversely affect, or attempt to adversely affect, the person or the 
transaction on the ground that the transaction is a standard 
transaction.
    Comment: Some commenters questioned what was meant by ``delay'' of 
a standard transaction. They questioned what methods (i.e., batch, 
online, etc.) a health plan must provide to support receipt and 
submission of standard transactions. The proposed rule did not define 
the term ``delay'' nor specify the time frame within which a health 
plan is required to act when it receives a standard transaction.
    Several commenters recommended the rule encompass all entities that 
might be conducting an electronic transaction with a health plan and 
that there be further clarification of what an unreasonable delay would 
be. It was also recommended that the regulation should apply to a 
health care provider, not a person that conducts an ``electronic'' 
transaction.
    Response: Section 1175 of the Act prohibits a health plan from 
delaying a standard transaction, or otherwise adversely affecting, or 
attempting to adversely affect any person desiring to conduct a 
transaction referred to in Sec. 1173 (a)(1) of the Social Security Act 
or the transaction on the ground that the transaction is a standard 
transaction. We interpret this provision to mean that there should be 
no degradation in the transmission of, receipt of, processing of, and 
response to a standard transaction solely because the transaction is a 
standard transaction. Thus, health plans must process standard 
transactions from any person, including, but not limited to, covered 
entities, in the same time frame in which they processed transactions 
prior to implementation of HIPAA. They also may not provide incentives 
that will discourage (i.e., adversely affect) the use of standard 
transactions.
    In Sec. 162.923 we have included requirements for all covered 
entities and in Sec. 162.925 we have provided additional requirements 
for health plans.
5. Role of Health Care Clearinghouses
    Proposal Summary: Health care clearinghouses would be able to 
accept nonstandard transactions for the sole purpose of translating 
them into standard transactions for sending customers and would be able 
to accept standard transactions and translate them into nonstandard 
formats for receiving customers (63 FR 25276).
    Comment: Several commenters believe health care clearinghouses are 
excepted from accepting the standards. Other commenters believe that 
allowing health care providers to use a health care clearinghouse will 
negate administrative simplification. There was also concern that 
entities may designate themselves as a health care clearinghouse to 
avoid compliance.
    Several commenters also requested that we clarify who is 
responsible for health care clearinghouse costs and state that 
contracts cannot require health care providers to use nonstandard 
formats.
    Response: First, we clarify that a health care clearinghouse is a 
covered entity and must comply with these rules. Accordingly, all 
transactions covered by this part between health care clearinghouses 
must be conducted as standard transactions. However, the statute 
permits a covered entity to submit nonstandard communications to a 
health care clearinghouse for processing into standard transactions and 
transmission by the health care clearinghouse as well as receive 
standard transactions through the health care clearinghouse.
    If a covered entity (for example, a health care provider) uses a 
health care clearinghouse to submit and receive nonstandard/standard 
transactions, the health care clearinghouse is the covered entity's 
business associate. If a health plan operates as a health care 
clearinghouse, or requires the use of a health care clearinghouse, a 
health care provider may submit standard transactions to that health 
plan through the health care clearinghouse. However, the health care 
provider must not be adversely affected, financially or otherwise, by 
doing so. (For example, the costs of submitting a standard transaction 
to a health plan's health care clearinghouse must not be in excess of 
the costs of submitting a standard transaction directly to the health 
plan.)
    In Sec. 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

[[Page 50317]]

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 Sec. 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 
Sec. 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 Sec. 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

[[Page 50318]]

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 Sec. 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 Sec. 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 Sec. 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.

[[Page 50319]]

B. Definitions

Comments and Responses Concerning the Definitions

    Several definitions in this rule have also been proposed in other 
HIPAA proposed rules. They may be revised as these other rules are 
published in final.
1. Code set
    Comment: One commenter stated that the definition of code set 
should be expanded to include factors such as functional status, in 
order to clarify that a code set is not limited to ``medical'' terms.
    Response: We have defined ``code set'' very broadly to encompass 
any set of codes used to encode data elements. Many code sets (such as 
revenue codes) are nonmedical in nature and are designated within the 
transaction standards. We are separately designating standards for 
medical data code sets used in the transaction.
2. Health Care Clearinghouse
    Comment: Several commenters requested that the definition of a 
health care clearinghouse be reworded. Of particular concern was the 
reference to other entities, such as billing services, repricing 
companies, etc. Commenters stated the definition would preclude these 
other entities from using a health care clearinghouse for format 
translation and data conversion. Several commenters stated health care 
clearinghouses play roles other than data and format conversion as 
described in the proposed rule.
    Response: If an entity does not perform the functions of format 
translation and data conversion, it is not considered a health care 
clearinghouse under our definition. Billing services, for example, are 
often extensions of a health care provider's office, primarily 
performing data entry of health care claims and reconciling the 
payments received from a health plan. Health care providers may use 
health care clearinghouses for format translation and other services a 
health care clearinghouse provides. We agree the definition should be 
reworded and have revised the definition in Sec. 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

[[Page 50320]]

arbitrarily exclude certain health plans. It was also stated that 
exclusion will cause undue hardship on health care providers of those 
specialities that most frequently deal with these health plans, such as 
orthopedic specialists. It was questioned whether the Bureau of Prisons 
or state correctional facilities are included in this definition, since 
they provide or pay for the cost of medical care.
    Another commenter stated that if State Workers' Compensation 
Programs are allowed to operate with different rules (as they do now) 
health care providers will be required to maintain multiple systems to 
accommodate the many variations. Consequently, administrative 
simplification will not achieve the desired cost savings.
    Response: We recognize that non-HIPAA entities such as workers' 
compensation programs and property casualty insurance accept electronic 
transactions from health care providers, however, the Congress did not 
include these programs in the definition of a health plan under section 
1171 of the Act.
    The statutory definition of a health plan does not specifically 
include workers' compensation programs, property and casualty programs, 
or disability insurance programs, and, consequently, we are not 
requiring them to comply with the standards. However, to the extent 
that these programs perform health care claims processing activities 
using an electronic standard, it would benefit these programs and their 
health care providers to use the standard we adopt.
    We believe that prisons do not fall within this definition of 
health plan, as prisons are not ``individual or group plans'' 
established for the purpose of paying the cost of health care.
    c. Comment: We received two requests to clarify that limited scope 
dental and vision health plans are not subject to the rule. It was 
stated that the proposed rule did not specifically indicate that the 
standards are applicable to these health plans. The limited scope 
dental health plans provide for annual maximum benefits generally in 
the $1000-$2000 range and annual benefit payments under limited scope 
vision health plans rarely exceed a few hundred dollars. The commenters 
noted that consumers can afford presently to pay for the cost of the 
annual benefit payments, but if health plans must implement these 
standards, they will most likely pass on the costs associated with this 
burden to their enrollees, causing many consumers to drop their 
coverage.
    Response: We believe limited scope dental health plans and limited 
scope vision health plans meet the definition of health plan and, thus, 
they are subject to the requirements of this rule. The Congress did not 
give the Secretary the discretion to treat these health plans 
differently than other health plans. If a health plan believes it would 
be cost prohibitive to implement the standards, it has the option of 
using a health care clearinghouse to transmit and receive the standard 
transactions.
5. Small Health Plan
    Comment: One commenter requested we clarify how the figure for the 
number of participants for a small health plan was determined. For 
instance, is an individual insured in a health plan for one month 
considered a participant for that year? Would twelve different people 
insured for one month each in a single year be considered a 
participant? Another commenter questioned why small health plans are 
being given an extra 12 months to implement the standards.
    Response: In the proposed rule, we stated that a small health plan 
means a group health plan or individual health plan with fewer than 50 
participants. It has come to our attention that the Small Business 
Administration (SBA) promulgates size standards that indicates the 
maximum number of employees or annual receipts allowed for a concern 
(13 CFR 121.105) and its affiliates to be considered ``small.'' The 
size standards themselves are expressed either in number of employees 
or annual receipts (13 CFR 121.201). The size standards for compliance 
with programs of other agencies are those for SBA programs which are 
most comparable to the programs of such other agencies, unless 
otherwise agreed by the agency and the SBA (13 CFR 121.902). With 
respect to the insurance industry, the SBA has specified that annual 
receipts of $5 million is the maximum allowed for a concern and its 
affiliates to be considered small (13 CFR 121.201). Consequently, the 
definition of small health plan has been amended to be consistent with 
SBA requirements. As such, we need not address the definition of 
participants for purposes of small health plans.
    Small health plans must implement the standards no later than 36 
months after adoption under section 1175 of the Act.
6. Standard
    Comment: One commenter stated the proposed rule dramatically 
changed the definition of standard. The commenter stated the new 
definition implies that any and all standards promulgated by an ANSI 
SSO or HHS automatically become a standard, whereas under the Act, only 
the Secretary can specify, establish, or adopt standards. The commenter 
recommended the definition under the Act stay the same.
    Response: We agree that only the Secretary may adopt a standard 
under the Act. Because the statutory definition of the term 
``standard'' is ambiguous, we are adopting a broader definition to 
accommodate the varying functions of the specific standards proposed in 
the other HIPAA regulations. We have revised the definition in 
Sec. 160.103 to clarify this, and have also added a definition for 
standard transaction in Sec. 162.103 for further clarification.
7. Transaction
    Comment: Several commenters recommended we amend the transaction 
definition to clarify each transaction.
    Response: We have provided clarification in the definitions of each 
transaction in subparts K through R.

Additional Definitions

    Comment: We received comments requesting that we define the terms 
``sponsor,'' ``third party administrator,'' ``trading partner 
agreement,'' and ``health claims attachments.''
    Response: We have included a definition for trading partner 
agreement in Sec. 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

[[Page 50321]]

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'' (Sec. 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 (Pub. L. 105-33) and meets the statutory 
criteria for a health plan.
    We are adding a definition of ``state'' to Sec. 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 
Sec. 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 Sec. 142.106 (now Sec. 160.104), we proposed 
that if the

[[Page 50322]]

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

[[Page 50323]]

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 
(Sec. 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 
Sec. 142.1002 (now Sec. 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 Sec. 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 Sec. 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 Sec. 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

[[Page 50324]]

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.
    6. 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.
    (d) Drugs. The proposed standard code set for these entities is the 
National Drug Codes maintained and distributed by the U.S. Department 
of Health and

[[Page 50325]]

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 Sec. 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 Sec. 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

[[Page 50326]]

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 Secs. 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 Secs. 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''

[[Page 50327]]

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

[[Page 50328]]

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 Sec. 162.940.
    i. NDC. 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

[[Page 50329]]

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

[[Page 50330]]

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

[[Page 50331]]

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 
Sec. 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 Sec. 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

[[Page 50332]]

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 Sec. 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 Sec. 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 Sec. 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

[[Page 50333]]

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 Sec. 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

[[Page 50334]]

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 
than 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 Sec. 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,

[[Page 50335]]

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 
Sec. 162.1602.
    c. Transaction Standard for Coordination of Benefits. In subpart M, 
redesignated in this rule as subpart R,

[[Page 50336]]

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 Sec. 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.

[[Page 50337]]

    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 Sec. 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 Sec. 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 Sec. 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

[[Page 50338]]

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

[[Page 50339]]

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 Sec. 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 Sec. 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 Sec. 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

[[Page 50340]]

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 Sec. 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 
Sec. 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 Sec. 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

[[Page 50341]]

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 Sec. 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 Sec. 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

[[Page 50342]]

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.

H. Enforcement

    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

[[Page 50343]]

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 Sec. 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

[[Page 50344]]

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 Sec. 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 Sec. 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

[[Page 50345]]

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 Sec. 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.
    a. 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

[[Page 50346]]

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

[[Page 50347]]

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

[[Page 50348]]

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.

[[Page 50349]]

    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-term 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.

IV. Summary of Changes to the Regulations

    Listed below is a summary of changes made to 45 CFR.
     Added Part 160 and moved proposed Secs. 142.101, 142.103, 
and 142.106 to Part 160.
     Added definitions for the following terms in Sec. 160.103: 
``business associate,'' ``compliance date,'' ``covered entity,'' 
``implementation specification,'' ``modify,'' ``standard setting 
organization,'' ``state,'' ``trading partner agreement,'' and 
``workforce.''
     Added definitions for the following terms in Sec. 162.103: 
``code set maintaining organization,'' ``data condition,'' ``data 
content,'' ``data element,'' ``data set,'' ``descriptor,'' ``designated 
standard maintenance organization,'' ``direct data entry,'' 
``electronic media,'' ``format,'' ``maintenance,'' ``maximum defined 
data set,'' ``segment,'' ``standard transaction.''
     Deleted definitions for ``ASC X12,'' ASC X12N,'' ``medical 
care,'' and ``participant.''
     Added Sec. 160.104 to describe the effective date and 
compliance date of a modification to an established standard.
     Included the word ``retail'' when referring to the NCPDP 
standard.
     Included language in Sec. 162.923 (formerly 142.102) to 
include the requirements for the use of direct data entry and to 
clarify requirements for covered entities.
     Added Sec. 162.910 to address the process for maintenance 
of the standards.
     Added section Sec. 162.915 to include the requirements of 
trading partner agreements.
     Removed the words ``at no cost'' in Sec. 162.920(a) when 
referring to the acquisition of implementation specifications.
     Revised language in Sec. 162.925 (formerly Sec. 142.104) 
to state that a health plan may not delay the transaction or attempt to 
adversely affect the entity or the transaction on the

[[Page 50350]]

basis that the transaction is a standard transaction. Added COB and 
code set requirements.
     Included language in Sec. 162.930 to clarify compliance of 
health care clearinghouses.
     Added Sec. 162.940 to include the process for requesting 
an exception to test proposed modifications to standards.
     Revised language in Sec. 162.1000 to include the 
requirement for the use of applicable medical code sets and, in 
Sec. 162.1002, we listed the name of all the standard medical code 
sets.
     Added Sec. 162.1011 to address compliance dates for 
maintenance changes to code sets.
     Corrected language in Sec. 162.1102 to reflect the correct 
version of the NCPDP Batch Standard, Version 1 Release 0.
     Added language in Sec. 162.1602 to include the NCPDP 
standard for health care payment and remittance advice within the 
retail pharmacy sector.
     Added language in Sec. 162.1202 to include the NCPDP 
standard for patient eligibility and coverage information within the 
retail pharmacy sector.
     Included the description of each transaction in subparts K 
through R, Secs. 162.1101, 162.1201, 162.1301, 162.1401, 162.1501, 
162.1601, 162.1701, and 162.1801.

V. Collection of Information Requirements

    Under the Paperwork Reduction Act of 1995 (PRA), agencies are 
required to provide a 30-day notice in the Federal Register and solicit 
public comment on a collection of information requirement submitted to 
the Office of Management and Budget (OMB) for review and approval. In 
order to fairly evaluate whether an information collection should be 
approved by OMB, section 3506(c)(2)(A) of the PRA requires that we 
solicit comment on the following issues:
     Whether the information collection is necessary and useful 
to carry out the proper functions of the agency.
     The accuracy of the agency's estimate of the information 
collection burden.
     The quality, utility, and clarity of the information to be 
collected.
     Recommendations to minimize the information collection 
burden on the affected public, including automated collection 
techniques.
    We are soliciting public comment on each of these issues for the 
following sections of this document that contain information collection 
requirements:
    In summary, each of the sections identified below require health 
care plans, and/or health care providers to use the standards 
referenced in this regulation for all electronically transmitted 
standard transactions that require it on and after the effective date 
given to it.

Subpart I--General Provisions for Transactions

Section 162.923 Requirements for covered entities

Section 162.925 Additional requirements for health plans

    Discussion: As referenced in the proposed rule, the emerging and 
increasing use of health care EDI standards and transactions has raised 
the issue of the applicability of the PRA. As such, we solicited 
comment on whether a regulation that adopts an EDI standard used to 
exchange certain information constitutes an information collection is 
subject to the PRA. Public comments were presented which suggested that 
the use of an EDI standard is not an information collection and under 
the PRA. The Office of Management and Budget, however, has determined 
that this regulatory requirement (which mandates that the private 
sector disclose information and do so in a particular format) 
constitutes an agency sponsored third-party disclosure as defined under 
the Paperwork Reduction Act of 1995 (PRA).
    HIPAA mandates the Secretary to adopt standards that have been 
developed, adopted, or modified by a standard setting organization, 
unless there is no such standard, or unless a different standard would 
substantially reduce administrative costs. OMB has concluded that the 
scope of its review under the PRA would be limited to the review and 
approval of this regulatory requirement, that is, the Secretary's 
decision to adopt or reject an established industry standard, based on 
the HIPAA criterion of whether a different standard would substantially 
reduce administrative costs. For example, if OMB concluded under the 
PRA that a different standard would substantially reduce administrative 
costs as compared to an established industry standard, the Secretary 
would be required to reconsider its decision under the HIPAA standards. 
The Secretary would be required to make a new determination of whether 
it is appropriate to adopt an established industry standard or whether 
it should enter into negotiated rulemaking to develop an alternative 
standard (section 1172(c)(2)(A)).
    The burden associated with these requirements, which is subject to 
the PRA, is the initial one-time burden on the entities identified 
above to modify their current computer system requirements. However, 
the burden associated with the routine or ongoing use of these 
requirements is exempt from the PRA as defined in 5 CFR 1320.3(b)(2).
    Based on the assumption that the burden associated with HIPAA, 
Title II systems modifications may overlap and the HIPAA standards 
would replace the use of multiple standards, resulting in a reduction 
of burden, commenters should take into consideration when drafting 
comments that: (1) One or more of these standards may not be used; (2) 
some of the these standards may already be in use by several of the 
estimated entities; (3) systems modifications may be performed in an 
aggregate manner during the course of routine business and/or; (4) 
systems modifications may be made by contractors such as practice 
management vendors, in a single effort for a multitude of affected 
entities.
    As required by section 3504(h) of the Paperwork Reduction Act of 
1995, we have submitted a copy of this document to the Office of 
Management and Budget (OMB) for its review of these information 
collection requirements.
    If you comment on these information collection and recordkeeping 
requirements, please e-mail comments to [email protected] (Attn:HCFA-
0149) or mail copies directly to the following:

Health Care Financing Administration, Office of Information Services, 
Information Technology Investment Management Group, Division of HCFA 
Enterprise Standards, Room C2-26-17, 7500 Security Boulevard, 
Baltimore, MD 21244-1850, Attn: HCFA-0149
       And
Office of Information and Regulatory Affairs, Office of Management and 
Budget, Room 10235, New Executive Office Building, Washington, DC 
20503, Attn: Allison Herron Eydt, HCFA Desk Officer

VI. Final Impact Analysis

A. Executive Summary

    Title II of the Health Insurance Portability and Accountability Act 
(HIPAA) provides a statutory framework for the establishment of a 
comprehensive set of standards for the electronic transmission of 
health information. Pursuant to this Title, the Department of Health 
and Human Services published proposed regulations concerning electronic 
transactions and code sets (May, 1998), national standard health care 
provider identifier (May, 1998), national standard employer

[[Page 50351]]

identifier (June, 1998), security and electronic signature standards 
(August, 1998), and standards for privacy of individually identifiable 
health information (November, 1999).
    Currently, there are numerous electronic codes available in the 
market. Without government action, a common standard might eventually 
emerge as the result of technological or market dominance. However, the 
uneven distribution of costs and benefits may have hindered the 
development of a voluntary industry-wide standard. Congress concluded 
that the current market is deadlocked and that the health care industry 
would benefit in the long run if government action were taken now to 
establish an industry standard. This approach, however, does entail 
some risks. For example, whenever the government chooses a standard, 
even one that is the best available at any point in time, the 
incentives to develop a better standard may be diminished because there 
is virtually no market competition and government-led standards often 
take longer to develop than those developed as the result of market 
pressures. The approach taken in this regulation is designed to 
encourage and capitalize on market forces to update standards as needs 
and technology change and have the government respond as quickly and 
efficiently as possible to them.
    As discussed in the proposals, the regulations will provide a 
consistent and efficient set of rules for the handling and protection 
of health information. The framework established by these 
administrative simplification regulations is sufficiently flexible to 
adapt to a health system that is becoming increasingly complex through 
mergers, contractual relationships, and technical and telecommunication 
changes. Moreover, the promulgation of a final privacy standard will 
enhance public confidence that highly personal and sensitive 
information is being properly protected, and therefore, it will enhance 
the public acceptance of increased use of electronic systems. 
Collectively, the standards that will be promulgated under Title II can 
be expected to accelerate the growth of electronic transactions and 
information exchange in health care.
    The final Impact Analysis provides estimates based on more current 
information and more refined assumptions than the original NPRM 
analysis. Since the original estimates were made, some of the voluntary 
development and investment in technology that was anticipated at the 
time of the proposal was diverted or delayed because of Y2K concerns; 
the investment is still expected but the timing of it has been delayed. 
The analysis utilizes more current data and reflects refinements in 
underlying assumptions based on the public comments and other 
information that has been collected on market changes. In addition, 
this analysis extended the time period for measuring costs and savings 
from five years to ten years. Given that the HIPAA provisions require 
initial expenses but subsequently produce a steady stream of savings, a 
ten year analysis more accurately measures the impact of the 
regulations.
    This final rule has been classified as a major rule subject to 
Congressional review. The effective date is October 16, 2000. If, 
however, at the conclusion of the Congressional review process the 
effective date has been changed, we will publish a document in the 
Federal Register to establish the actual effective date or to issue a 
notice of termination of the final rule action.
    Therefore, the following analysis includes the expected costs and 
benefits of the administration simplification regulations related to 
electronic systems for ten years. Although only the electronic 
transactions standards are being promulgated in this regulation, the 
Department expects affected parties to make systems compliance 
investments collectively because the regulations are so integrated. 
Moreover, the data available to us are also based on the collective 
requirements of the regulations; it is not feasible to identify the 
incremental technological and computer costs for each regulation based 
on currently available data. The Department acknowledges that the 
aggregate impact analysis does not provide the information necessary to 
assess the choice of specific standards.
    The costs of implementing the standards specified in the statute 
are primarily one-time or short-term costs related to conversion. These 
costs include system conversion/upgrade costs, start-up costs of 
automation, training costs, and costs associated with implementation 
problems. These costs will be incurred during the first three years of 
implementation. Although there may be some ongoing maintenance costs 
associated with these changes, vendors are likely to include these 
costs as part of the purchase price. Plans and providers may choose to 
upgrade their systems beyond the initial upgrade required by the rule 
as technology improves over time. Since the rule only requires an 
initial systems upgrade, the costs of future upgrades are not included 
in the cost estimate of the rule. The benefits of EDI include reduction 
in manual data entry, elimination of postal service delays, elimination 
of the costs associated with the use of paper forms, and the enhanced 
ability of participants in the market to interact with each other.
    In this analysis, the Department has used conservative assumptions 
and it has taken into account the effects of the trend in recent years 
toward electronic health care transactions. Based on this analysis, the 
Department has determined that the benefits attributable to the 
implementation of administrative simplification regulations will accrue 
almost immediately but will not exceed costs incurred by health care 
providers and health plans until after the second year of 
implementation. After the second year, however, the benefits will 
continue to accrue for an extended period of time. The total net 
savings for the period 2002-2011 will be $29.9 billion (a net savings 
of $13.1 billion for health plans, and a net savings of $16.7 billion 
for health care providers). The single year net savings for the year 
2011 will be $5.6 billion ($2.5 billion for health plans and $3.1 
billion for health care providers). The discounted present value of 
these savings is $19.1 billion over the ten years. These estimates do 
not include the sizeable secondary benefits that are likely to occur 
through expanded e-commerce resulting from standardized systems.
    In accordance with the provisions of Executive Order 12866, this 
rule was reviewed by the Office of Management and Budget.

B. Guiding Principles for Standard Selection

    The implementation teams charged with designating standards under 
the statute have defined, with significant input from the health care 
industry, a set of common criteria for evaluating potential standards. 
These criteria are based on direct specifications in the HIPAA, the 
purpose of the law, and principles that support the regulatory 
philosophy set forth in Executive Order 12866 of September 30, 1993, 
and the Paperwork Reduction Act of 1995. In order to be designated as a 
standard, a proposed standard should:
     Improve the efficiency and effectiveness of the health 
care system by leading to cost reductions for or improvements in 
benefits from electronic HIPAA health care transactions. This principle 
supports the regulatory goals of cost-effectiveness and avoidance of 
burden.
     Meet the needs of the health data standards user 
community, particularly health care providers, health plans, and health 
care clearinghouses. This

[[Page 50352]]

principle supports the regulatory goal of cost-effectiveness.
     Be consistent and uniform with the other HIPAA standards 
(that is, their data element definitions and codes and their privacy 
and security requirements) and with other private and public sector 
health data standards to the extent possible. This principle supports 
the regulatory goals of consistency and avoidance of incompatibility, 
and it establishes a performance objective for the standard.
     Have low additional development and implementation costs 
relative to the benefits of using the standard. This principle supports 
the regulatory goals of cost-effectiveness and avoidance of burden.
     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. This 
principle supports the regulatory goal of predictability.
     Have timely development, testing, implementation, and 
updating procedures to achieve administrative simplification benefits 
faster. This principle establishes a performance objective for the 
standard.
     Be technologically independent of the computer platforms 
and transmission protocols used in HIPAA health transactions, except 
when they are explicitly part of the standard. This principle 
establishes a performance objective for the standard and supports the 
regulatory goal of flexibility.
     Be precise and unambiguous but as simple as possible. This 
principle supports the regulatory goals of predictability and 
simplicity.
     Keep data collection and paperwork burdens on users as low 
as is feasible. This principle supports the regulatory goals of cost-
effectiveness and avoidance of duplication and burden.
     Incorporate flexibility to adapt more easily to changes in 
the health care infrastructure (such as new services, organizations, 
and health care provider types) and information technology. This 
principle supports the regulatory goals of flexibility and 
encouragement of innovation.

C. Introduction

    The Department assessed several strategies for determining the 
impact of the various standards that the Secretary will designate under 
the statute. The costs and savings of each individual standard could be 
analyzed independently, or the Department could analyze the costs and 
savings of all the standards in the aggregate. The decision was made to 
base the analysis on the aggregate impact of all the standards. Given 
that all the standards are likely to be made final within a reasonable 
period of one another, it is likely that organizations will seek to 
make changes to comply with all the regulations at the same time, at 
least for those components of the regulations that require computer and 
technology changes. This will be the most efficient investment for most 
affected organizations, and the estimates the Department has obtained 
from industry sources are based on this assumption.
    The statute gives health care providers and health plans 24 months 
(36 months for small health plans) to implement each standard after the 
effective date of the final rule. This provides the industry 
flexibility in determining the most cost-effective means of 
implementing the standards. Dictated by their own business needs, 
health plans and health care providers may decide to implement more 
than one standard at a time or to combine implementation of a standard 
with other system changes. As a result, overall estimates will be more 
accurate than individual estimates.
    Assessing the benefits of implementing each standard independently 
could also be inaccurate. While each individual standard is beneficial, 
the standards as a whole have a synergistic effect on savings. For 
example, the combination of the standard health plan identifier and the 
standard claim format will improve the coordination of benefits process 
to a much greater extent than use of either standard individually.
    It is difficult to assess the costs and benefits of such a sweeping 
change because no-one has historical experience with this unique area. 
Moreover, the standardization of electronic transactions will spur 
secondary innovations, particularly in e-commerce, that may be 
described generally but are too new to assess quantitatively. 
Consequently, the analysis of these secondary benefits will be 
qualitative.

D. Overall Cost/Benefit Analysis

    To assess the impact of the HIPAA administrative simplification 
provisions, it is important to understand current industry practices. A 
1993 study by Lewin-VHI estimated that administrative costs comprised 
17 percent of total health expenditures. Paperwork inefficiencies are a 
component of those costs, as are the inefficiencies caused by the more 
than 400 different data transmission formats currently in use. Industry 
groups such as ANSI ASC X12N have developed standards for EDI 
transactions which are used by some health plans and health care 
providers. However, migration to these recognized standards has been 
hampered by the inability to develop a concerted approach. For example, 
even ``standard'' formats such as the Uniform Bill (UB-92), the 
standard Medicare hospital claim form (which is used by most hospitals, 
skilled nursing facilities, and home health agencies for inpatient and 
outpatient claims) are customized by health plans and health care 
providers.
    Several reports have made estimates of the costs and/or benefits of 
implementing EDI standards. In assessing the impact of the HIPAA 
administrative simplification provisions, the Congressional Budget 
Office reported that:

    ``The direct cost of the mandates in Title II of the bill would 
be negligible. Health plans (and those health care providers who 
choose to submit claims electronically) would be required to modify 
their computer software to incorporate new standards as they are 
adopted or modified...Uniform standards would generate offsetting 
savings for health plans and health care providers by simplifying 
the claims process and coordination of benefits.'' (Page 4 of the 
Estimate of Costs of Private Sector Mandates in the Congressional 
Budget Office report)

    The most extensive industry analysis of the effects of EDI 
standards was developed by WEDI in 1993, which built upon a similar 
1992 report. The WEDI report used an extensive amount of information 
and analysis to develop its estimates, including data from a number of 
EDI pilot projects. The report included a number of electronic 
transactions that are not covered by HIPAA, such as materials 
management. The WEDI report projected implementation costs ranging 
between $5.3 billion and $17.3 billion (3, p. 9-4) and annual savings 
for the transactions covered by HIPAA ranging from $8.9 billion and 
$20.5 billion (3, pp. 9-5 and 9-6). Lewin estimated that the data 
standards proposed in the Healthcare Simplification and Uniformity Act 
of 1993 would save from 2.0 to 3.9 percent in administrative costs 
annually ($2.6 to $5.2 billion based on 1991 costs) (1, p.12). A 1995 
study commissioned by the New Jersey Legislature estimated yearly 
savings of $760 million related to EDI claims processing, reducing 
claims rejection, performing eligibility checks, decreasing accounts 
receivable, and other potential EDI applications in New Jersey alone 
(4, p.316).
    We have drawn on the 1993 WEDI report for many of our estimates 
because it is the most comprehensive available.

[[Page 50353]]

However, our conclusions differ, especially in the area of savings, for 
a number of reasons. The WEDI report was intended to assess the savings 
in an EDI environment that is much broader than is covered by HIPAA. 
Furthermore, EDI continued to grow through the 1990's (see Faulkner & 
Gray, 2000), and it is reasonable to assume that EDI would continue to 
grow for the foreseeable future even without HIPAA. The Department's 
objective in this analysis is to assess the effect of the legislation 
and these regulations on the health care sector; only a portion of the 
benefits of EDI identified by WEDI would be attributable to HIPAA.

E. Implementation Costs

    The costs of implementing the standards specified in the statute 
are primarily one-time or short-term costs related to conversion. They 
can be characterized as follows:
    1. System Conversion/Upgrade--Health care providers and health 
plans will incur costs to convert existing software to utilize the 
standards. Health plans and large health care providers generally have 
their own information systems, which they maintain with in-house or 
contract support. Small health care providers are more likely to use 
off-the-shelf software developed and maintained by a vendor. Examples 
of software changes include the ability to generate and accept 
transactions using the standard (for example, claims, remittance 
advices) and converting or cross walking medical code sets to chosen 
standards. However, health care providers have considerable flexibility 
in determining how and when to accomplish these changes. One 
alternative to a complete system redesign would be to purchase a 
translator that reformats existing system outputs into standard 
transaction formats. A health plan or health care provider could also 
decide to implement two or more related standards at once or to 
implement one or more standards during a software upgrade. Each health 
care provider's and health plan's situation will differ, and each will 
select a cost-effective implementation scheme. Many health care 
providers use billing associates or health care clearinghouses to 
facilitate EDI. (Although we discuss billing associates and health care 
clearinghouses as separate entities in this impact analysis, billing 
associates are considered to be the same as health care clearinghouses 
for purposes of administrative simplification if they meet the 
definition of a health care clearinghouse). Those entities would also 
have to reprogram to accommodate standards.
    2. Start-up Cost of Automation--The statute does not require health 
care providers to conduct transactions electronically. To benefit from 
EDI, health care providers who choose to conduct electronic 
transactions but do not currently have electronic capabilities would 
have to purchase and install computer hardware and software as well as 
train their staffs to use the technology. However, this conversion is 
likely to be less costly once standards are in place because there will 
be more vendors providing support services. Furthermore, providers 
without electronic capabilities are more likely to conclude that the 
benefits of conducting transactions electronically justify a capital 
investment in EDI technology.
    3. Training--Health care provider and health plan personnel will 
require training on the use of the various standard identifiers, 
formats, and code sets. For the most part, training will be directed 
toward administrative personnel, though clinical staff will also need 
training on the new code sets. With standardization, however, vendors 
are more likely to offer assistance in training as a means of 
increasing sales, thereby reducing the per unit cost of training.
    4. Implementation Problems--The implementation of any industry-wide 
standards will inevitably create additional complexity in regard to how 
health plans and health care providers conduct business. Health plans 
and health care providers will need to work on re-establishing 
communication with their trading partners, and process transactions 
using the new formats, identifiers, and code sets. This is likely to 
result in a temporary increase in rejected transactions, manual 
exception processing, payment delays, and requests for additional 
information.
    While the majority of costs are one-time costs related to 
implementation, there are also on-going costs associated with 
administrative simplification, such as subscribing to or purchasing 
documentation and implementation specifications related to code sets 
and standard formats and obtaining current health plan and health care 
provider identifier directories or data files. Because covered entities 
are already incurring most of these costs, the costs under HIPAA will 
be marginal. These small ongoing costs are included in the estimate of 
the system conversion and upgrade costs.
    In addition, EDI could affect cash flow throughout the health 
insurance industry. Electronic claims reach the health plan faster and 
can be processed faster. This has the potential to improve health care 
providers' cash flow situations while decreasing health plans' earnings 
on cash reserves. However, improved cash flow is generally considered a 
benefit, particularly for small businesses.

F. Benefits of Increased Use of EDI for Health Care Transactions

    Some of the benefits attributable to increased EDI can be readily 
quantified, while others are more intangible. For example, it is easy 
to compute the savings in postage from EDI claims, but attributing a 
dollar value to processing efficiencies is difficult.
    The benefits of EDI to the industry in general are well documented 
in the literature. One of the most significant benefits of EDI is the 
reduction in manual data entry. The paper processing of business 
transactions requires manual data entry when the data are received and 
entered into a system. For example, the data on a paper health care 
transaction from a health care provider to a health plan have to be 
manually entered into the health plan's business system. If the patient 
has more than one health plan, the second health plan would also have 
to manually enter the data into its system if it cannot receive the 
information electronically. Repeated keying of information transmitted 
via paper results in increased labor as well as significant 
opportunities for keying errors. EDI permits direct data transmission 
between computer systems which, in turn, reduces the need to rekey 
data.
    Another problem with paper-based transactions is that these 
documents are primarily mailed. Normal delivery times of mailings can 
vary anywhere from one to several days for normal first class mail. 
Shipping paper documents more quickly can be expensive. While bulk 
mailings can reduce some costs, paper mailings remain costly. Using 
postal services can also lead to some uncertainty as to whether the 
transaction was received, unless more expensive certified mail options 
are pursued. A benefit of EDI is that the capability exists for the 
sender of the transaction to receive an electronic acknowledgment once 
the data is opened by the recipient. Also, because EDI involves direct 
computer to computer data transmission, the associated delays with 
postal services are eliminated. With EDI, communication service 
providers such as value added networks function as electronic post 
offices and provide 24-hour service. Value added networks

[[Page 50354]]

deliver data instantaneously to the receiver's electronic mailbox.
    In addition to mailing time delays, there are other significant 
costs in using paper forms. These include the costs of maintaining an 
inventory of forms, typing data onto forms, addressing envelopes, and 
the cost of postage. The use of paper also requires significant staff 
resources to receive and store the paper during normal processing. The 
paper must be organized to permit easy retrieval if necessary.

G. The Role of Standards in Increasing the Efficiency of EDI

    There was a steady increase in the use of EDI in the health care 
market through the late 1990's, and there is likely to be some 
continued growth, even without national standards. However, the upward 
trend in EDI health care transactions will be enhanced by having 
national standards in place. Because national standards are not in 
place today, there continues to be a proliferation of proprietary 
formats in the health care industry. Proprietary formats are those that 
are unique to an individual business. Due to proprietary formats, 
business partners that wish to exchange information via EDI must agree 
on which formats to use. Since most health care providers do business 
with a number of health plans, they must produce EDI transactions in 
many different formats. For small health care providers facing the 
requirement of maintaining multiple formats, this is a significant 
disincentive to converting to EDI.
    National standards will allow for common formats and translations 
of electronic information that will be understandable to both the 
sender and receiver. Multiple electronic formats increase associated 
labor costs because more personnel time and more skills are required to 
link or translate different systems. These costs are reflected in 
increased office overhead, a reliance on paper and third party vendors, 
and communication delays. National standards eliminate the need to 
determine what format a trading partner is using. Standards also reduce 
software development and maintenance costs that are required for 
operating or converting multiple proprietary formats. Health care 
transaction standards will improve the efficiency of the EDI market and 
will help further persuade reluctant industry partners to choose EDI 
over traditional mail services.
    The statute directs the Secretary to establish standards and sets 
out the timetable for doing so. The Secretary must designate a standard 
for each of the specified transactions and medical code sets. Health 
plans and health care providers generally conduct EDI with multiple 
partners and the choice of a transaction format is a bilateral decision 
between the sender and receiver. Many health care providers and health 
plans need to support many different transaction formats in order to 
meet the needs of all of their trading partners. Single standards will 
maximize net benefits and minimize ongoing confusion.
    Health care providers and health plans have a great deal of 
flexibility in how and when they will implement standards. The statute 
specifies dates by which health plans will have to use adopted 
standards, however, health plans can determine if, when, and in which 
order they will implement standards before the date of mandatory 
compliance. Health care providers have the flexibility to determine 
when it is cost-effective for them to convert to EDI. Health plans and 
health care providers have a wide range of vendors and technologies 
from which to choose in implementing standards and can choose to 
utilize a health care clearinghouse to transmit (produce and receive) 
standard transactions.

H. Updated Cost and Benefit Assumptions

    As mentioned above, we have made changes to the original impact 
analysis published in the NPRM. In response to the public comments 
regarding the NPRM impact analysis, the Department did a thorough 
review of the original assumptions and data sources. In the review 
process, it became clear that the original data sources required 
updating and that there were some inconsistencies in the original 
assumptions. What follows is an explanation of each change and the 
rationale behind the new methodology.
    Ten Year Time-Frame: This Impact Analysis changes the original 
NPRM's time-frame from five years to ten years. The need for this 
change results from the nature of the HIPAA regulations: there will be 
significant one-time initial investments followed by many years of 
savings. Because a five year impact analysis will show the full cost of 
the regulations but truncate the savings significantly, a ten year 
time-frame allows for a fuller presentation of the benefits 
administrative simplification offers the health care industry. As an 
illustration of the difference between a five year and a ten year time 
frame, the initial NPRM Impact Analysis estimated $1.5 billion in net 
savings to the industry, but a ten year analysis using identical 
assumptions as the original NPRM would estimate $24.2 billion in net 
savings. The Department believes it is more appropriate to use a time 
frame that more accurately estimates the long term impact of the 
regulations.
    New Data: Given the length of time between the publication of the 
NPRM and the final rule, it was necessary to update data for the number 
of plans and providers, the number of claims, and the current 
proportion of claims that are electronic in the health care industry. 
Updated data on the number of different types of plans and providers 
were obtained from a variety of sources, including the 1997 Economic 
Census, the 1999 Statistical Abstract of the United States, the 
American Medical Association and other industry groups, the Department 
of Labor, and the Department of Health and Human Services. In the NPRM, 
the 1993 WEDI report was used to determine the total number of claims 
in the health care industry for 1993, which was trended forward using 
data from the 1996 edition of Faulkner and Gray's Health Data Directory 
to estimate the number of claims annually over the 1998 to 2002 time 
frame. For the final impact analysis, we used 1999 data (the most 
recent available) from the 2000 edition of Faulkner and Gray's Health 
Data Directory to determine the total number of claims in the industry, 
the number of claims by provider type, and the percent of claims that 
are billed electronically by provider type.
    The baseline rate of growth in the number of claims and the rate of 
growth in the proportion of electronic claims were revised using 
historical trend data from the 2000 Faulkner and Gray report. In the 
final impact analysis, the average annual rate of growth over the 1995 
to 1999 period is used to determine the annual increase in the number 
of claims and in the proportion of claims that are electronic, for all 
claims in the industry and by provider type.
    New Electronic Claims Growth Assumptions: This Impact Analysis 
makes a refinement to the original assumptions for determining the rate 
of increase in electronic claims due to HIPAA. The model assumes that 
electronic claims submissions will increase in the first three years 
after the implementation at a rapid pace as many health care providers 
and health plans make the switch to electronic formats but then the 
rate will decrease over time. The model also assumes some providers 
will not make the transition to EDI during the ten year period. 
Specifically, we assumed that the proportion of manual claims will 
decrease by twenty percent annually from 2002 to 2005 and then will 
decrease by ten percent annually from

[[Page 50355]]

2006 to 2011. By contrast, the original NPRM model assumed the rate of 
increase in electronic claims would grow by two additional percentage 
points above the baseline rate each year.
    Savings per Claim: This impact analysis uses more consistent 
assumptions for the savings per claim. In the original NPRM, the 
savings per claim for payers and each provider type was based on the 
ranges developed by WEDI. However, the NPRM did not consistently pick 
from a given point in the WEDI ranges, but rather various points were 
chosen for different groups based on limited anecdotal information. 
Upon further analysis, the Department no longer believes there is a 
justifiable basis to pick from different parts of the WEDI ranges, 
given the lack of additional evidence to support more precise 
assumptions. Therefore, the final impact analysis assumes the savings 
per claim will be at the mid-point of the WEDI ranges for payers and 
all providers.
    Inflation Adjustment: The final Impact Analysis corrects an 
inconsistency found in the NPRM regarding an inflation adjustment to 
the annual savings per claim assumptions. Specifically, the NPRM 
increased the savings per claim by 3% annually to account for 
inflation. This adjustment was an inconsistency because no other 
figures in the NPRM impact analysis were adjusted for inflation. 
Therefore, for the final impact analysis, all dollar estimates, 
including the savings per claim, are in current 2000 dollars.
    First Year Savings: Another change made to the impact analysis was 
to include savings in the first year of mandatory compliance with the 
rule. The NPRM assumed that there would be no savings in the first year 
of mandatory compliance, yet we believe that this assumption was in 
error because most entities must comply no later than two years after 
the effective date of the final rule (three years for small health 
plans), and therefore some savings will begin two years after 
publication of the rule. In fact, it could be argued that some entities 
will come into compliance prior to the two year deadline and begin to 
produce savings, but in order to produce a conservative estimate, this 
analysis only assumes that savings begin in the first year of mandatory 
compliance.
    Impact of Changes: The cumulative effect of the changes made to the 
impact analysis increases the net savings from administrative 
simplification. Although the NPRM only showed five year costs and 
savings, the underlying analysis included ten year estimates as well. 
Compared to the original impact analysis, the final impact analysis 
increases the estimated gross costs of the rule from $5.8 billion to 
$7.0 billion over ten years. The original impact analysis produced 
gross savings of $30 billion and net savings of $24.2 billion over ten 
years while the new impact analysis produces gross savings of $36.9 
billion and net savings of $29.9 billion over ten years. Although the 
new impact analysis now shows an additional $5.7 billion in savings 
over ten years, the Department believes the revised assumptions 
underlying these estimates are based on better, more up-to-date data, 
are more consistent, and are more reasonable. The discounted present 
value of the savings is $19.1 billion over ten years. Furthermore, the 
updated impact analysis still produces a conservative estimate of the 
impact of administrative simplification. For example, the new impact 
analysis assumes that over the ten-year post-implementation period, 
only 11.2% of the growth in electronic claims will be attributable to 
HIPAA. Given the widely recognized benefits standardization offers the 
health care industry, assuming that only 11.2% of all health claims 
will be affected by HIPAA represents a reasonably conservative estimate 
of the impact .

I. Cost/Benefit Tables

    The tables below illustrate the essential costs and savings for 
health plans and health care providers to implement the standards and 
the savings that will occur over time as a result of the HIPAA 
administrative simplification provisions. All estimates are stated in 
2000 dollars. The costs are based on estimates of a moderately complex 
set of software upgrades, which were provided by the industry. The 
range of costs and savings that health plans and health care providers 
will incur is quite large and is based on such factors as the size and 
complexity of the existing systems, ability to implement using existing 
low-cost translator software, and reliance on health care 
clearinghouses to create standard transactions. The cost of a 
moderately complex upgrade represents a reasonable mid-point in this 
range. In addition, we assume that health plans and health care 
providers that operate EDI systems will incur implementation costs 
related to manual operations to make those processes compatible with 
the EDI systems. For example, manual processes may be converted to 
produce paper remittance advices that contain the same data elements as 
the EDI standard transaction. These costs are estimated to equal 50 
percent of the software upgrade cost. Health care providers that do not 
have existing EDI systems will also incur some costs due to HIPAA, even 
if they choose not to implement EDI for all of the HIPAA transactions. 
For example, a health care provider may have to change accounting 
practices in order to process the revised paper remittance advice 
discussed above. We have assumed the average cost for non-EDI health 
care providers and health plans to be half that of already-automated 
health care providers and health plans.
    Savings due to standardization come from three sources. First, 
there are savings due to increased use of electronic claims submissions 
throughout the health care industry. Second, there will be savings 
based on simplification of the manual claims that remain in the system. 
Finally, there will be savings due to increased electronic non-claims 
transactions, such as eligibility verifications and coordination of 
benefits. It is important to view these estimates as an attempt to 
furnish a realistic context rather than as precise budgetary 
predictions. The estimates also do not include any benefits 
attributable to the qualitative aspects of administrative 
simplification, nor is there any inclusion of secondary benefits. 
Industry people have argued that standardization will accelerate many 
forms of new e-commerce. These innovations may generate significant 
savings to the health care system or improvements in the quality of 
health but they have not been included here.
    More detailed information regarding data sources and assumptions is 
provided in the explanations for the specific tables.
    Table 1 below shows estimated costs and savings for health plans. 
The number of plans listed in the chart is derived from the 1993 WEDI 
report, trade publications, and data from the Department of Labor. The 
cost per health plan for software upgrades is based on the WEDI report, 
which estimated a range of costs required to implement a fully capable 
EDI environment, and more current estimates provided by the industry. 
The high-end estimates ranged from two to ten times higher than the 
low-end estimates. Lower end estimates were used in most cases because, 
as explained above, HIPAA does not require changes as extensive as 
envisioned by WEDI. The estimated percentages of health plans that 
accept electronic billing are based on reports in the 2000 edition of 
Faulkner & Gray's Health Data Directory (5). The total cost for each 
type of health plan is the sum of the cost for EDI and non-EDI health 
plans. Cost for EDI health plans is computed as follows:


[[Page 50356]]


(Total Entities  x  EDI %  x  Average Upgrade Cost  x  1.5)

    Note: As described above, EDI health plans would incur costs 
both to upgrade software and to make manual operations compatible 
with EDI systems. The cost of changing manual processes is estimated 
to be half the cost of system changes.

    Cost for non-EDI health plans is computed as follows:

Total entities  x  (1-EDI %)  x  Average Upgrade Cost  x  0.5

    Note: As described above, cost to non-EDI health plans is 
assumed to be half the cost of systems changes for EDI plans.

    The data available permit us to make reasonable estimates of the 
costs that will be borne by different types of health plans (Table 1). 
Unfortunately, though we can estimate the overall savings, we cannot 
reliably estimate their distributional effects. Hence, only the 
aggregate savings estimates are presented.

                             Table 1.--Health Plan Implementation Costs and Savings
                                                   [2002-2011]
----------------------------------------------------------------------------------------------------------------
                                                  Number of                              Total cost    Savings
              Type of health plan                   health      Average       % EDI         (in          (in
                                                    plans         cost                   millions)    millions)
----------------------------------------------------------------------------------------------------------------
Large commercials..............................          250   $1,000,000           90         $350
Small commercials..............................          400      500,000           50          200
Blue Cross/Blue Shield.........................           48    1,000,000          100           98
Third-party administrators.....................          750      500,000           50          375
HMO/PPO........................................        1,630      250,000        60-85          487
Self-administered..............................       50,000       50,000           25        1,875
Other employer health plans....................    2,550,000          100           00          127
    Total (Undiscounted).......................  ...........  ...........  ...........       $3,512      $16,600
    Total (Discounted).........................  ...........  ...........  ...........       $3,300      $11,600
----------------------------------------------------------------------------------------------------------------


    Note: The estimates in Table 1 show cost savings in 2000 dollars 
(estimates in the proposed rule were in 1998 dollars). The Office of 
Management and Budget now requires all agencies to provide estimates 
using a net present value calculation. Furthermore, OMB recommends 
the use of a 7 percent discount rate based on the current cost of 
capital. The discounted totals in the table are based on this rate 
beginning in 2003.

    Table 2 illustrates the costs and savings attributable to various 
types of health care providers.
    The number of entities (practices or establishments, not individual 
health care providers) is based on the 1997 Economic Census, the 1999 
Statistical Abstract of the United States, the American Medical 
Association's Physician Characteristics and Distribution in the U.S. 
(2000-2001 edition), and Department of Health and Human Services data 
trended to 2002. Estimated percentages of EDI billing are based on the 
2000 edition of Faulkner & Gray's Health Data Directory or are 
Departmental estimates.
    The cost of software upgrades for personal computers (PCS) in 
provider practices or establishments is based on reports of the cost of 
software upgrades to translate and communicate standardized claims 
forms. The low end of the range of costs is used for smaller practices 
or establishments and the high end of the range of costs for larger 
practices/establishments with PCS. The cost per upgrade estimate for 
hospitals and other facilities is a Departmental estimate derived from 
estimates by WEDI and estimates of the cost of new software packages in 
the literature. The estimates fall within the range of the WEDI 
estimates, but that range is quite large. For example, WEDI estimates 
that the cost for a large hospital upgrade will be from $50,000 to 
$500,000.
    The $20.2 billion in savings in Table 4 represents savings to 
health care providers for the first ten years of implementation. The 
discounted present value of these savings is $19.1 billion over ten 
years. They are included to provide a sense of how the HIPAA 
administrative simplification provisions will affect various entities.

                         Table 2.--Health Care Provider Implementation Costs and Savings
                                                   [2002-2011]
----------------------------------------------------------------------------------------------------------------
                                                  Number of
                                                 health care    Average                  Total cost    Savings
          Type of health care provider            providers       cost        % EDI         (in          (in
                                                 (2002 est.)                             millions)    millions)
----------------------------------------------------------------------------------------------------------------
Federal Hospitals..............................          266     $250,000           88          $92
Non-Federal Hospitals 100 beds.................        2,639      100,000           88          364
Non-Federal Hospitals 100+ beds................        2,780      250,000           88          960
Nursing facility 100 beds......................        9,606       10,000           90          134
Nursing facility 100+ beds.....................        8,833       20,000           90          247
Home health agency.............................        8,900       10,000           90          184
Hospice........................................        2,027       10,000           90           28
Residential Mental Health/Retardation/Substance       22,339       10,000           10          134
 Abuse Facilities..............................
Outpatient care centers........................       24,034       10,000           75          300
Pharmacy.......................................       43,900        4,000           96          256
Medical labs...................................        9,500        4,000           85           51
Dental labs....................................        7,900        1,500           50           12
DME............................................      112,200        1,500           50          168
Physicians solo and groups less than 3.........      193,000        1,500           50          290
Physicians groups 3+ with computers............       20,000        4,000           90          112
Physicians groups 3+ no automation.............        1,000            0           00            0
Osteopaths.....................................       13,600        1,500           10           12

[[Page 50357]]

 
Dentists.......................................      120,000        1,500           30          144
Podiatrists....................................        9,100        1,500           05            8
Chiropractors..................................       32,000        1,500           05           26
Optometrists...................................       18,800        1,500           05           16
Other professionals............................       33,400        1,500           05           28
    Total (Undiscounted).......................  ...........  ...........  ...........       $3,566      $20,200
    Total (Discounted).........................  ...........  ...........  ...........       $3,300      $14,100
----------------------------------------------------------------------------------------------------------------


    Note: The estimates in Table 2 show cost savings in 2000 dollars 
(estimates in the proposed rule were in 1998 dollars). The Office of 
Management and Budget now requires all agencies to provide estimates 
using a net present value calculation. Furthermore, OMB recommends 
the use of a 7 percent discount rate based on the current cost of 
capital. The discounted totals in the table are based on this rate 
beginning in 2003.

    Table 3 shows the estimates we used to determine the portion of EDI 
claims increase attributable to the HIPAA administrative simplification 
provisions. The proportion of claims that would be processed 
electronically even without HIPAA is assumed to grow at the same rate 
from 2002 through 2011 as it did from 1995-1999. The proportion of 
``other'' health care provider claims is high because it includes 
pharmacies that generate large volumes of claims and have a high rate 
of electronic billing.
    The increase in EDI claims attributable to HIPAA is highly 
uncertain and is critical to the savings estimate. These estimates are 
based on an analysis of the current EDI environment. Most of the growth 
rate in electronic billing is attributable to Medicare and Medicaid; 
smaller private insurers and third party administrators (who are not 
large commercial insurers) have lower rates of electronic billing and 
may benefit significantly from standardization.

                   Table 3.--Percent Growth in EDI Claims Attributable to HIPAA As Provisions
                                                  [Cumulative]
----------------------------------------------------------------------------------------------------------------
  Type of health care provider     2002    2003    2004    2005    2006    2007    2008    2009    2010    2011
----------------------------------------------------------------------------------------------------------------
Physician:
    Percent before HIPAA........      53      55      58      61      63      65      67      69      71      73
    Percent after HIPAA.........      63      72      80      83      86      88      90      91      93      94
    Difference..................      10      17      21      22      23      23      22      22      22      21
Hospital:
    Percent before HIPAA........      87      88      89      89      90      91      91      92      92      93
    Percent after HIPAA.........      90      93      95      95      96      97      97      98      98      98
    Difference..................       3       5       6       6       6       6       6       6       6       6
Other:
    Percent before HIPAA........      83      84      86      87      88      89      90      91      92      93
    Percent after HIPAA.........      87      91      93      95      96      96      97      98      98      99
    Difference..................       4       6       7       7       7       7       7       6       6       6
----------------------------------------------------------------------------------------------------------------

    Table 4 shows the annual costs, savings, and net savings over a ten 
year implementation period which are gained by using the HIPAA 
standards. Virtually all of the costs attributable to HIPAA will be 
incurred within the first three years of implementation, since the 
statute requires health plans other than small health plans to 
implement the standards within 24 months and small health plans to 
implement the standards within 36 months of the effective date of the 
final rule. As each health plan implements a standard, health care 
providers that conduct electronic transactions with that health plan 
will also implement the standard. No net savings would accrue in the 
first year because not enough health plans and health care providers 
will have implemented the standards. Savings will increase as more 
health plans and health care providers implement the standards, thus 
exceeding costs in the fourth year. At that point, the majority of 
health plans and health care providers will have implemented the 
standards and, as a result, costs will decrease and benefits will 
increase.
    The savings per claim processed electronically instead of manually 
is based on the mid-point of the range estimated by WEDI.: $1 per claim 
for health plans, $1.49 for physicians, $0.86 for hospitals and $0.83 
for others. These estimates are based on surveys of health care 
providers and health plans. Total savings are computed by multiplying 
the per claim savings by the number of EDI claims attributed to HIPAA. 
The total number of EDI claims is used in computing the savings to 
health plans, while the savings for specific health care provider 
groups is computed using only the number of EDI claims generated by 
that group (for example, savings to physicians is computed using only 
physician EDI claims).
    WEDI also estimated savings resulting from other HIPAA 
transactions, such as eligibility verifications, coordination of 
benefits, and claims inquiries (among others). The average savings per 
transaction was slightly higher than the savings from electronic 
billing, but the number of transactions was much smaller than the 
number of claims transactions. The estimates for transactions other 
than claims were derived by approximating a number of

[[Page 50358]]

transactions and estimating the anticipated savings associated with 
each transaction relative to those assumed for the savings for 
electronic billing (see table 5). In general, the approximations are 
close to those used by WEDI. For these non-billing transactions, the 
Department assumed that the simplification promoted by HIPAA will 
facilitate a significant conversion from manual to electronic formats. 
While today it is estimated that about 44% of these non-billing 
transactions are electronic, by the end of the ten year period it is 
estimated that 92% will become electronic.
    Savings can also be expected from simplifications in manual claims. 
The basic assumption is that the savings are ten percent of savings per 
claim that are projected for conversion from manual to electronic 
billing. However, it is also assumed that the standards will only 
gradually allow health care providers and health plans to abandon old 
manual forms and identifiers by 10% annually; this staged transition is 
inevitable because many of the relationships that have been established 
with other entities will require a period of overlap during 
transitioning with entities with which they do business.

                                                             Table 4.--Ten Year Net Savings
                                                                      [$ Billions]
--------------------------------------------------------------------------------------------------------------------------------------------------------
                                                                                                                                 Total          Total
             Costs and savings               2002    2003    2004    2005    2006    2007    2008    2009    2010    2011   (Undiscounted)  (Discounted)
--------------------------------------------------------------------------------------------------------------------------------------------------------
Costs:....................................
    H.C. Provider.........................     1.2     1.2     1.1     0.0     0.0     0.0     0.0     0.0     0.0     0.0           3.5            3.3
    Health Plan...........................     1.2     1.2     1.1     0.0     0.0     0.0     0.0     0.0     0.0     0.0           3.5            3.3
                                           -------------------------------------------------------------------------------------------------------------
      Total...............................     2.4     2.4     2.2     0.0     0.0     0.0     0.0     0.0     0.0     0.0           7.0            6.8
                                           =============================================================================================================
Savings from Claims Processing:
    H.C. Provider.........................     0.4     0.7     1.0     1.1     1.1     1.2     1.2     1.3     1.3     1.3          10.7            7.7
    Health Plan...........................     0.4     0.6     0.8     0.9     1.0     1.0     1.1     1.1     1.1     1.1           9.1            6.5
                                           -------------------------------------------------------------------------------------------------------------
      Total...............................     0.8     1.4     1.8     2.0     2.0     2.2     2.3     2.4     2.4     2.5          19.8           14.2
                                           =============================================================================================================
Savings from Other Transactions:
    H.C. Provider.........................     0.1     0.3     0.5     0.7     0.9     1.0     1.2     1.4     1.5     1.7           9.3            6.2
    Health Plan...........................     0.1     0.2     0.4     0.6     0.7     0.8     0.9     1.1     1.2     1.4           7.3            4.9
                                           -------------------------------------------------------------------------------------------------------------
      Total...............................     0.1     0.5     0.8     1.3     1.6     1.9     2.1     2.4     2.7     3.1          16.6           11.1
                                           =============================================================================================================
Savings from Manual Transactions:
    H.C. Provider.........................     0.0     0.0     0.0     0.0     0.0     0.0     0.0     0.0     0.0     0.0           0.3            0.2
    Health Plan...........................     0.0     0.0     0.0     0.0     0.0     0.1     0.0     0.0     0.0     0.0           0.2            0.1
                                           -------------------------------------------------------------------------------------------------------------
      Total...............................     0.0     0.0     0.0     0.0     0.1     0.1     0.1     0.1     0.1     0.1           0.5            0.3
                                           =============================================================================================================
Total Savings:
    H.C. Provider.........................     0.5     1.0     1.5     1.8     2.1     2.3     2.5     2.7     2.9     3.1          20.2           14.1
    Health Plan...........................     0.4     0.8     1.2     1.5     1.7     1.9     2.0     2.2     2.4     2.5          16.6           11.6
                                           -------------------------------------------------------------------------------------------------------------
      Total...............................     0.9     1.9     2.7     3.3     3.8     4.1     4.5     4.9     5.2     5.6          36.9           25.6
                                           =============================================================================================================
Net:
    H.C. Provider.........................    -0.7    -0.3     0.4     1.8     2.1     2.3     2.5     2.7     2.9     3.1          16.7           10.8
    Health Plan...........................    -0.8    -0.4     0.1     1.5     1.7     1.9     2.0     2.2     2.4     2.5          13.1            8.3
                                           -------------------------------------------------------------------------------------------------------------
      Total...............................    -1.5    -0.5     0.5     3.3     3.8     4.1     4.5     4.9     5.2     5.6          29.9           19.07 
--------------------------------------------------------------------------------------------------------------------------------------------------------
Note: Figures do not total due to rounding.
Note: The estimates in Table 4 show cost savings in 2000 dollars (estimates in the proposed rule were in 1998 dollars). The Office of Management and
  Budget now requires all agencies to provide estimates using a net present value calculation. Furthermore, OMB recommends the use of a 7 percent
  discount rate based on the current cost of capital. The discounted totals in the table are based on this rate beginning in 2003.

    The ratios in Table 5 were derived from the WEDI Report, which 
estimated the volume and savings of the listed non-billing 
transactions. By comparing the relationship between billing volume and 
savings to non-billing volume and savings, it is possible to estimate 
total savings due to other transactions. These ratios were used because 
the billing data has been updated by the Faulkner and Gray Health Data 
Directory, but WEDI has not updated the estimates for non-billing 
transactions. Therefore, this model implicitly assumes that the ratio 
of billing transactions to non-billing transactions has remained 
constant since 1993.

       Table 5.--Relative Savings and Volume of Other Transactions
------------------------------------------------------------------------
                   Transaction                      Savings     Volume
------------------------------------------------------------------------
Claim............................................        1.0        1.0
Claims inquiry...................................        4.0        0.5
Remittance advice................................        1.5        0.10
Coordination of benefits.........................        0.5        0.10
Eligibility inquiry..............................        0.5        0.05
Enrollment/disenrollment.........................        0.5        0.01
Referral.........................................        0.1        0.10
------------------------------------------------------------------------

J. Qualitative Impacts of Administrative Simplification

    Administration simplification produces more than hard-dollar 
savings. There are also qualitative benefits that are less tangible, 
but nevertheless important. These changes become possible when data can 
be more easily integrated across entities. WEDI suggests in its 1993 
report that the implementation of an EDI infrastructure will cause a 
``ripple-effect'' on the whole health care delivery system; this chain 
reaction will occur because there will be a reduction in duplicate 
medical procedures and processes as a patient is handled by a continuum 
of health care providers during an episode of care. WEDI also suggests 
that there will be a reduction in the exposure to health care fraud as 
security controls on electronic

[[Page 50359]]

transactions will prevent unauthorized access to financial data.
    Standards may also reduce administrative burden and improve job 
satisfaction. For example, fewer administrative staff will be required 
to translate procedural codes, since a common set of codes will be 
used. All codes used in these transactions will be standardized, 
eliminating different values for data elements (for example, place of 
service).
    Administrative simplification will promote the accuracy, 
reliability and usefulness of the information shared. For example, 
today there are any number of transaction formats in use. There are 
over 400 variations of electronic formats for claims transactions 
alone. As noted earlier, these variations make it difficult for parties 
to exchange information electronically. At a minimum, it requires data 
to be translated from the sender's own format to the different formats 
specified by each intended receiver. Translation usually requires 
additional equipment and labor.
    Administrative simplification greatly enhances the sharing of data 
both within entities and across entities. It facilitates the 
coordination of benefits information by having in place a standardized 
set of data that is known to all parties, along with standardized name 
and address information that tells where to route transactions. Today, 
health care providers are reluctant to file claims with multiple health 
plans on behalf of the patient because information about a patient's 
eligibility in a health plan is difficult to verify. Most claims filed 
by patients today are submitted in hard copy. We anticipate that more 
health care providers will file claims and coordinate benefits on the 
patient's behalf once standard transactions are adopted and this 
information is made available electronically.

K. Regulatory Flexibility Analysis

    The Regulatory Flexibility Act (RFA) of 1980, Public Law 96-354, 
requires the Department to prepare a regulatory flexibility analysis if 
the Secretary certifies that a proposed regulation will have a 
significant economic impact on a substantial number of small entities. 
In the health care sector, a small entity is one with less than $5 
million in annual revenues. For the purposes of this analysis (pursuant 
to the RFA), nonprofit organizations are considered small entities; 
however, individuals and States are not included in the definition of a 
small entity. We have attempted to estimate the number of small 
entities and provide a general discussion of the effects of the 
statute.
    For the purpose of this analysis, all 31 nonprofit Blue Cross-Blue 
Shield Health Plans are considered small entities. 28% of HMOs are 
considered small entities because of their nonprofit status. Doctors of 
osteopathy, dentistry, podiatry, as well as chiropractors, and solo and 
group physicians' offices with fewer than three physicians, are 
considered small entities. Forty percent of group practices with 3 or 
more physicians and 100 percent of optometrist practices are considered 
small entities. Seventy-two percent of all pharmacies, 88% of medical 
laboratories, 100% of dental laboratories and 90% of durable medical 
equipment suppliers are assumed to be small entities as well.
    We found the best source for information about the health data 
information industry is Faulkner & Gray's Health Data Directory. This 
publication is the most comprehensive data dictionary of its kind that 
we could find. The information in this directory is gathered by 
Faulkner & Gray editors and researchers who called all of the more than 
3,000 organizations that are listed in the book in order to elicit 
information about their operations. It is important to note that some 
businesses are listed as more than one type of business entity; this is 
because in reporting the information, companies could list themselves 
as many as three different types of entities. For example, some 
businesses listed themselves as both practice management vendors and 
claims software vendors because their practice management software was 
``EDI enabled.''
    All the statistics referencing Faulkner & Gray's come from the 2000 
edition of its Health Data Directory. It lists 78 claims 
clearinghouses, which are entities under contract that take electronic 
and paper health care claims data from health care providers and 
billing companies that prepare bills on a health care provider's 
behalf. The claims clearinghouse acts as a conduit for health plans; it 
batches claims and routes transactions to the appropriate health plan 
in a form that expedites payment.
    Of the 78 claims clearinghouses listed in this publication, eight 
processed more that 20 million electronic transactions per month. 
Another 15 handled 2 million or more transactions per month and another 
4 handled over a million electronic transactions per month. The 
remaining 39 entities listed in the data dictionary processed less than 
a million electronic transactions per month. Almost all of these 
entities have annual revenues of under $5 million and would therefore 
be considered small entities.
    Another entity that is involved in the electronic transmission of 
health care transactions is materials management/supply ordering 
software companies (value added networks). They are involved in the 
electronic transmission of data over telecommunication lines. Faulkner 
& Gray list 21 materials management/supply ordering software vendors 
that handle health care transactions. We believe that almost all of 
these companies meet the definition of a small business. \1\
---------------------------------------------------------------------------

    \1\ The SBA size standard for computer software related 
industries (SIC 7371-7379) is $18.0 million or less. Between 81% and 
99% of the companies in these categories qualify.
---------------------------------------------------------------------------

    A billing company is another entity involved in the electronic 
routing of health care transactions. It works primarily with physicians 
in office and hospital-based settings. Billing companies, in effect, 
take over the office administrative functions for a physician; they 
take information such as copies of medical notes and records and 
prepare claim forms that are then forwarded to an insurer for payment. 
Billing companies may also handle the receipt of payments, including 
posting payment to the patient's record on behalf of the health care 
provider. They can be located within or outside of the physician's 
practice setting.
    In the proposed rule we stated that The International Billing 
Association, a trade association representing billing companies, 
estimated that there were 4,500 billing companies in business in the 
United States. The International Billing Association's estimates are 
based on the number of names and addresses of actual billing companies 
on its mailing list. Since we were unable to find more recent 
information about these entities, we are assuming that the number of 
billing companies has not changed significantly and that all of the 
4,500 billing companies continue to have revenues under $5 million 
annually.
    Software system vendors provide computer software applications 
support to health care clearinghouses, billing companies, and health 
care providers. In particular, they work with health care providers' 
practice management and health information systems. These businesses 
provide integrated software applications for such services as accounts 
receivable management, electronic claims submission (patient billing), 
record keeping, patient charting, practice analysis and patient 
scheduling. Some software vendors are

[[Page 50360]]

also involved in providing applications for translating paper and 
nonstandard computer documents into standardized formats that are 
acceptable to health plans.
    Faulkner & Gray list 78 physician practice management vendors and 
suppliers, 76 hospital information systems vendors and suppliers, 140 
software vendors and suppliers for claims-related transactions, and 20 
translation vendors (now known as Interface Engines/ Integration 
Tools). We were unable to determine the number of these entities with 
revenues over $5 million, but we assume most of these businesses would 
be considered small entities.
    As discussed earlier in this analysis, the cost of implementing the 
standards specified in the statute are primarily one-time or short-term 
costs related to conversion. They were characterized as follows: 
software conversion; cost of automation; training; implementation 
problems; and cost of documentation and implementation specifications. 
Rather than repeat that information here, we refer you to the beginning 
of this impact analysis.
1. Health care Providers and Health Plans
    As a result of standard data format and content, health care 
providers and health plans that wish to do business electronically will 
be able to do so knowing that capital outlays they make are likely to 
be worthwhile, with some certainty on the return of their investment. 
This is because covered entities that exchange electronic health care 
transactions will be required to receive and send transactions in the 
same standard formats. We believe this will be an incentive for small 
physicians' offices to convert from paper to EDI. In a 1996 Office of 
the Inspector General study entitled ``Encouraging Physicians to Use 
Paperless Claims,'' the Office of the Inspector General and HCFA agreed 
that over $36 million in annual Medicare claims processing savings 
could be achieved if all health care providers submitting 50 or more 
Medicare claims per month submitted them electronically. Establishment 
of EDI standards will make it financially beneficial for many small 
health care providers to convert to electronic claim submissions 
because all health plans will accept the same formats.
    Additionally, health care providers that currently use health care 
clearinghouses and billing agencies will see costs stabilize and will 
potentially enjoy some cost reduction. This will result from the 
increased efficiency that health care clearinghouses and billing 
companies will realize from being able to more easily link with health 
care industry business partners.
2. Third Party Vendors
    Third party vendors include third party processors/health care 
clearinghouses (including value added networks), billing companies, and 
software system vendors. While the market for third party vendors will 
change as a result of standardization, these changes will be positive 
for the industry and its customers over the long term. However, the 
short term/one time costs discussed above will apply to the third party 
vendor community.
    a. Health Care Clearinghouses and Billing Companies. As noted 
above, health care clearinghouses are entities that take health care 
transactions, convert them into standardized formats, and forward them 
to the insurer. Billing companies take on the administrative functions 
of a physician's office. The market for health care clearinghouse and 
billing company services will definitely be affected by the HIPAA 
administrative simplification provisions; however, there appears to be 
some debate on how the market for these services will be affected.
    It is likely that competition among health care clearinghouses and 
billing companies will increase over time as standards reduce some of 
the technical limitations that currently inhibit health care providers 
from conducting their own EDI. For example, by eliminating the 
requirement to maintain several different claims standards for 
different trading partners, health care providers will be able to more 
easily link themselves directly to health plans. This could negatively 
affect the market for health care clearinghouses and system vendors 
that do translation services; however, standards should increase the 
efficiency in which health care clearinghouses operate by allowing them 
to more easily link to multiple health plans. The increased efficiency 
in operations resulting from standards could, in effect, lower their 
overhead costs as well as attract new health care clearinghouse 
customers to offset any loss in market share that they might 
experience.
    Another potential area of change is that brought about through 
standardized code sets. Standard code sets will lower costs and break 
down logistical barriers that discouraged some health care providers 
from doing their own coding and billing. As a result, some health care 
providers may choose an in-house transaction system rather than using a 
billing company as a means of exercising more control over information. 
Conversely, health care clearinghouses may acquire some short-term 
increase in business from those health care providers that are 
automated but do not use the selected standards. These health care 
providers will hire health care clearinghouses to take data from the 
nonstandard formats they are using and convert them into the 
appropriate standards. Generally, health care clearinghouses can also 
be expected to identify opportunities in which they could add value to 
transaction processing and to find new business opportunities, such as 
in training health care providers on the new transaction sets. 
Standards will increase the efficiency of health care clearinghouses, 
which could in turn drive costs for these services down. Health care 
clearinghouses may be able to operate more efficiently or at a lower 
cost based on their ability to gain market share. Some small billing 
companies may be consumed by health care clearinghouses that may begin 
offering billing services to augment their health care clearinghouse 
activities. However, most health care providers that use billing 
companies will probably continue to do so because of the comprehensive 
and personalized services these companies offer.
    Value added networks transmit data over telecommunication lines. We 
anticipate that the demand for value added network services will 
increase as additional health care providers and health plans move to 
electronic data exchange. Standards will eliminate the need for data to 
be reformatted, which will allow health care providers to purchase 
value added network services individually rather than as a component of 
the full range of health care clearinghouse services.
    b. Software Vendors. As noted above, software vendors provide 
computer software applications support to health care clearinghouses 
and health care providers. In particular, they work with health care 
providers' practice management and health information systems. These 
entities will be affected positively, at least in the short term. The 
implementation of administrative simplification will enhance their 
business opportunities as they become involved in developing 
computerized software solutions that allow health care providers and 
other entities that exchange health care data to integrate the new 
transaction set into their existing systems.
L. Unfunded mandates
    We have identified the private sector costs associated with the

[[Page 50361]]

implementation of these standards. Although these costs are unfunded, 
we expect that they will be offset by subsequent savings as detailed in 
this impact analysis.
    Most costs to health care providers and health plans will occur in 
the first 3 years following the adoption of the HIPAA standards, with 
savings to health care providers and health plans exceeding costs in 
the fourth year. The total net savings for the period 2001-2011 will be 
$29.8 billion (a net savings of $13.1 billion for health plans, and a 
net savings of $16.7 billion for health care providers). The single 
year net savings for the year 2011 will be $5.6 billion ($2.5 billion 
for health plans and $3.1 billion for health care providers). The 
discounted present value of these savings is $19.1 billion over ten 
years. These estimates do not include the secondary benefits that will 
be realized through expanded e-commerce resulting from standardized 
systems.
    The costs to State and local governments and tribal organizations 
are also unfunded, but we do not have sufficient information for 
programs other than Medicaid to provide estimates of the impact of 
these standards on those entities. As discussed previously, several 
State Medicaid agencies have estimated that it may cost as much as $10 
million per state to implement all the HIPAA standards. However, the 
Congressional Budget Office analysis stated that ``States are already 
in the forefront in administering the Medicaid program electronically; 
the only costs--which should not be significant--would involve bringing 
the software and computer systems for the Medicaid programs into 
compliance with the new standards.'' The report went on to point out 
that Medicaid State agencies have the option to compensate for costs by 
reducing other expenditures. State and local government agencies are 
likely to incur less in the way of costs since most of them will have 
fewer enrollees than Medicaid agencies. Moreover, the Federal 
government pays a portion of the cost of converting State Medicaid 
Management Information Systems (MMIS) as Federal Financial 
Participation--75 percent for system maintenance changes and 90 percent 
for new software (if approved). Many States are in the process of 
changing systems as they convert many of the current functions in the 
move to enroll Medicaid beneficiaries in managed care. The net effect 
is that some States may have to pay $1 million to comply; however, 
numerous States may have already incurred some of these costs, though 
the Department does not have a complete record of State changes.

M. Code Sets--Specific Impact of Adoption of Code Sets for Medical Data

Affected Entities
    Standard codes and classifications are required in some segments of 
administrative and financial transactions. Covered entities that create 
and process administrative transactions must implement the standard 
codes according to the implementation specifications adopted for each 
coding system and each transaction. Those that receive standard 
electronic administrative transactions must be able to receive and 
process all standard codes irrespective of local policies regarding 
reimbursement for certain conditions or procedures, coverage policies, 
or need for certain types of information that are part of a standard 
transaction.
    The adoption of standard code sets and coding guidelines for 
medical data supports the regulatory goals of cost-effectiveness and 
the avoidance of duplication and burden. The code sets that are being 
proposed as initial HIPAA standards are already in use by most health 
plans, health care clearinghouses, and health care providers.
    Health care providers currently use the recommended code set for 
reporting diagnoses and one or more of the recommended procedure coding 
systems for reporting procedures/services. Since health plans can 
differ with respect to the codes they accept, many health care 
providers use different coding guidelines for dealing with different 
health plans, sometimes for the same patient. (Anecdotal information 
leads us to believe that use of other codes is widespread, but we 
cannot quantify the number.) Some of these differences reflect 
variations in covered services that will continue to exist irrespective 
of data standardization. Others reflect differences in a health plan's 
ability to accept as valid a claim that may include more information 
than is needed or used by that health plan. The requirement to use 
standard coding guidelines will eliminate this latter category of 
differences and should simplify claims submission for health care 
providers that deal with multiple health plans.
    Currently, there are health plans that do not adhere to official 
coding guidelines and have developed their own plan-specific guidelines 
for use with the standard code sets, which do not permit the use of all 
valid codes. Again, we cannot quantify how many health plans do this, 
but we are aware of some instances when this occurs. When the HIPAA 
code set standards become effective, these health plans will have to 
receive and process all standard codes, without regard to local 
policies regarding reimbursement for certain conditions or procedures, 
coverage policies, or need for certain types of information that are 
part of a standard transaction.
    We believe that there is significant variation in the reporting of 
anesthesia services, with some health plans using the anesthesia 
section of CPT and others requiring the anesthesiologist or nurse 
anesthetist to report the code for the surgical procedure itself. When 
the HIPAA code sets become effective, health plans following the latter 
convention will have to begin accepting codes from the anesthesia 
section.
    We note that by adopting standards for code sets we are requiring 
that all parties accept these codes within their electronic 
transactions. We are not requiring payment for all of these services. 
Those health plans that do not adhere to official coding guidelines 
must therefore undertake a one-time effort to modify their systems to 
accept all valid codes in the standard code sets or engage a health 
care clearinghouse to preprocess the standard claims data for them. 
Health plans should be able to make modifications to meet the deadlines 
specified in the legislation, but some temporary disruption of claims 
processing could result.
    There may be some temporary disruption of claims processing as 
health plans and health care clearinghouses modify their systems to 
accept all valid codes in the standard code sets.

N. Transaction Standards

1. Specific Impact of Adoption of the National Council of Prescription 
Drug Programs (NCPDP) Telecommunication Claim
    a. Affected Entities. Health care providers that submit retail 
pharmacy claims, and health care plans that process retail pharmacy 
claims, currently use the NCPDP format. The NCPDP claim and equivalent 
encounter is used either in on-line interactive or batch mode. Since 
all pharmacy health care providers and health plans use the NCPDP claim 
format, there are no specific impacts to health care providers.
    b. Effects of Various Options. The NCPDP format met all of the 10 
guiding principles used to designate a standard as a HIPAA standard, 
and there are no other known options for a standard retail pharmacy 
claim transaction.

[[Page 50362]]

2. Specific Impact of Adoption of the ASC X12N 837 for Submission of 
Institutional Health Care Claims, Professional Health Care Claims, 
Dental Claims, and Coordination of Benefits
    a. Affected Entities. All health care providers and health plans 
that conduct EDI directly and use other electronic format(s), and all 
health care providers that decide to change from a paper format to an 
electronic one, would have to begin to use the ASC X12N 837 for 
submitting electronic health care claims (hospital, physician/supplier 
and dental). (Currently, about 3 percent of Medicare health care 
providers use this standard for claims; it is used less for non-
Medicare claims.)
    Some of the possible effects of adopting the ASC X12N 837 include 
the possibility of an initial disruption in claim processing and 
payment during a health plan's transition to the standard format and 
the possibility that health care providers could react adversely to 
implementation costs and thus revert to hard copy claims.
    Despite the initial problems health care providers may encounter 
with administrative simplification, health care providers will, in the 
long run, enjoy the advantages associated with not having to keep track 
of and use different electronic formats for different insurers. This 
will simplify health care provider billing systems and processes as 
well as reduce administrative expenses.
    Health plans will, as long as they meet the deadlines specified in 
the statute, be able to schedule their implementation of the ASC X12N 
837 in a manner that best fits their needs, thus allaying some costs 
through coordination of conversion to other standards. Although the 
costs of implementing the ASC X12N 837 are generally one-time costs 
related to conversion, the cost of systems upgrades for some smaller 
health care providers, health plans, and health care clearinghouses may 
be prohibitive. Health care providers and health plans have the option 
of using a health care clearinghouse to satisfy the HIPAA standard 
requirements.
    Coordination of benefits. Once the ASC X12N 837 has been 
implemented, health plans that perform coordination of benefits will be 
able to eliminate the support of multiple proprietary electronic claim 
formats, thus simplifying claims receipt and processing as well as 
reducing administrative costs. Coordination of benefits activities will 
also be greatly simplified because all health plans will use the same 
standard format. There is no doubt that standardization in coordination 
of benefits will greatly enhance and improve efficiency in the overall 
claims process and the coordination of benefits.
    From a non-systems perspective (meaning policy and program issues), 
there should not be an adverse effect on the coordination of benefits 
process. The COB transaction will continue to consist of the incoming 
electronic claim and the data elements provided on a remittance advice. 
Standardization of the information needed for coordination of benefits 
will clearly increase efficiency in the electronic processes utilized 
by the health care providers, health care clearinghouses, and health 
plans.
    b. Effects of Various Options. We assessed the various options for 
a standard claim transaction against the principles, listed at the 
beginning of this impact analysis above, with the overall goal of 
achieving the maximum benefit for the least cost. We found that the ASC 
X12N 837 for institutional claims, professional claims, dental claims, 
and coordination of benefits met all of the 10 guiding principles that 
were used to designate a standard as a HIPAA standard, but no other 
candidate standard transaction met all the principles.
    Since the majority of dental claims are submitted on paper and 
those submitted electronically are being transmitted using a variety of 
proprietary formats, the only viable choice for the standard is the ASC 
X12N 837. The American Dental Association (ADA) also recommended the 
ASC X12N 837 for the dental claim standard.
    The ASC X12N 837 was selected as the standard for the professional 
(physician/supplier) claim because it met the principles above. The 
only other candidate standard, the National Standard Format, was 
developed primarily by HCFA for Medicare claims. While it is widely 
used, it is not always used in a standard manner. Thus, we declined to 
adopt the National Standard Format. Many variations of the National 
Standard Format are in use. Moreover, the NUCC, the AMA, and WEDI 
recommended the ASC X12N 837 for the professional claim standard.
    The ASC X12N 837 was selected as the standard for the institutional 
(hospital, nursing facilities and similar inpatient institutions) claim 
because it met the principles above. The only other candidate standard 
was the UB-92 Format developed by HCFA for Medicare claims. While the 
UB-92 is widely used, it is not always used in a standard manner. 
Consequently, we did not elect to adopt the UB-92.
    The selection of the ASC X12N 837 does not impose a greater burden 
on the industry than the nonselected options because the nonselected 
formats are not used in a standard manner by the industry and they do 
not incorporate the flexibility necessary to adapt easily to change. 
The ASC X12N 837 presents significant advantages in terms of 
universality and flexibility.
3. Specific Impact of Adoption of the ASC X12N 835 for Receipt of 
Health Care Remittance
    a. Affected Entities. Health care providers that conduct EDI with 
health plans and that do not wish to change their internal systems will 
have to convert the ASC X12N 835 transactions received from health 
plans into a format compatible with their internal systems either by 
using a translator or a health care clearinghouse. Health plans that 
want to transmit remittance advice directly to health care providers 
and that do not use the ASC X12N 835 will also incur costs to convert 
to the standard. Many health care providers and health plans do not use 
this standard at this time. We do not have information to quantify the 
standard's use outside the Medicare program. However, according to 
Medicare statistics, in 1996, 15.9 percent of part B health care 
providers and 99.4 percent of part A health care providers were able to 
receive this standard. All Medicare contractors must be able to send 
the standard.
    Some of the possible effects of adopting the ASC X12N 835 include 
the potential for an initial delay in payment or the issuance of 
electronic remittance during a plan's transition to the standard format 
and the possibility that health care providers could react adversely to 
implementation costs and thus, revert to hard copy remittance notices 
in lieu of an electronic transmission.
    Despite the initial problems health care providers may encounter 
with administrative simplification, health care providers will, in the 
long run, enjoy the advantage associated with not having to keep track 
of or accept different electronic payment/remittance advice formats 
issued by different health plans. This will simplify automatic posting 
of all electronic payment/remittance advice data, thus reducing 
administrative expenses. This will also reduce or eliminate the 
practice of posting payment/remittance advice data manually from hard 
copy notices, again reducing administrative expenses. Most manual 
posting occurs currently in response to the problem of

[[Page 50363]]

multiple formats; using standard transactions will eliminate this 
burden.
    Additionally, once the ASC X12N 835 has been implemented, health 
plans' coordination of benefits activities, which will use the ASC X12N 
837 format supplemented with limited data from the ASC X12N 835, will 
be greatly simplified because all health plans will use the same 
standard format.
    As long as they meet the deadlines specified in the statute, health 
plans will be able to schedule their implementation of the ASC X12N 835 
in a manner that best fits their needs, thus allaying some costs 
through coordination of conversion to other standards.
    The selection of the ASC X12N 835 does not impose a greater burden 
on the industry than the nonselected options because the nonselected 
formats are not used in a standard manner by the industry and they do 
not incorporate the flexibility necessary to adapt easily to change. 
The ASC X12N 835 presents significant advantages in terms of 
universality and flexibility.
    b. Effects of Various Options. We assessed the various options for 
a standard payment/remittance advice transaction against the principles 
listed above which aim at achieving the maximum benefit for the least 
cost. We found that the ASC X12N 835 met all the principles, but no 
other candidate standard transaction met all the principles, or even 
those principles supporting the regulatory goal of cost-effectiveness.
    The ASC X12N 835 was selected as it met the principles above. The 
only other candidate standard, the ASC X12N 820, was not selected 
because, although it was developed for payment transactions, it was not 
developed for health care claims payment purposes. The ASC X12N 
subcommittee itself recognized this in its decision to develop the ASC 
X12N 835.
4. Specific Impact of Adoption of the ASC X12N 276/277 for Health Care 
Claim Status/Response
    a. Affected Entities. Most health care providers that are currently 
using an electronic format for claim status inquiries (of which there 
are currently very few) and that wish to request claim status 
electronically using the ASC X12N 276/277 will incur conversion costs. 
We cannot quantify the number of health care providers that will have 
to convert to the standard, but we do know that no Medicare contractors 
use the standard; thus, we assume that few health care providers are 
able to use it at this time.
    After implementation, health care providers will be able to request 
and receive the status of claims in one standard format from all health 
care plans. This will eliminate their need to maintain redundant 
software and will make electronic claim status requests and receipt of 
responses feasible for small health care providers, eliminating their 
need to manually send and review claim status requests and responses.
    Health plans that do not currently directly accept electronic claim 
status requests and do not directly send electronic claims status 
responses will have to modify their systems to accept the ASC X12N 276 
and to send the ASC X12N 277. No disruptions in claims processing or 
payment should occur.
    After implementation, health plans will be able to submit claim 
status responses in one standard format to all health care providers. 
Administrative costs incurred by supporting multiple formats and 
manually responding to claim status requests will be greatly reduced.
    b. Effects of Various Options. There are no known options for a 
standard claims status and response transaction.
5. Specific Impact of Adoption of the ASC X12N 834 for Enrollment and 
Disenrollment in a Health Plan
    a. Affected entities. The ASC X12N 834 may be used by an employer 
or other sponsor to electronically enroll or disenroll its subscribers 
into or out of a health plan. Currently, most small and medium size 
employers and other sponsors conduct their subscriber enrollments using 
paper forms. We cannot quantify how many of these sponsors use paper 
forms, but anecdotal information indicates that most use paper. We 
understand that large employers and other sponsors are more likely to 
electronically conduct subscriber enrollment transactions because this 
method makes it easier to respond to the many changes that occur in a 
large workforce; for example, hirings, firings, retirements, marriages, 
births, and deaths. Large employers currently use proprietary 
electronic data interchange formats, which differ among health plans, 
in order to conduct subscriber enrollment. Nonetheless, it is our 
understanding, based on anecdotal information, that health plans still 
use paper to conduct most of their enrollment transactions.
    We expect that the impact of the ASC X12N 834 transaction standard 
will differ, at least in the beginning, according to the current use of 
electronic transactions. As stated earlier, at the present time, most 
small and medium size employers and other sponsors do not use 
electronic transactions and will therefore experience little immediate 
impact from the adoption of the ASC X12N 834 transaction. The ASC X12N 
834 will offer large employers, currently conducting enrollment 
transactions electronically, the opportunity to shift to a single 
standard format. A single standard will be most attractive to those 
large employers that offer their subscribers choices among multiple 
health plans. Thus, the early benefits of the ASC X12N 834 will accrue 
to large employers and other sponsors that will be able to eliminate 
duplicative hardware and software, and human resources required to 
support multiple proprietary electronic data interchange formats. In 
the long run, we expect that the standards will lower the costs of 
conducting enrollment transactions, thus making it possible for small 
and medium size companies to achieve significant additional savings by 
converting from paper to electronic transactions.
    Overall, employers and other sponsors, and the health plans with 
which they deal, stand to benefit from the adoption of the ASC X12N 834 
and electronic data interchange. The ASC X12N 834 and electronic data 
interchange will facilitate the performance of enrollment and 
disenrollment functions. Further, the ASC X12N 834 supports detailed 
enrollment information on the subscriber's dependents, which is often 
lacking in current practice. Ultimately, reductions in administrative 
overhead may be passed along in lower premiums to subscribers and their 
dependents.
    b. Effects of Various Options. The only other option, the NCPDP 
Member Enrollment Standard, does not meet the selection criteria and 
would not be implemented in the larger health industry setting.
6. Specific Impact of Adoption of the ASC X12N 270/271 for Eligibility 
for a Health Plan
    a. Affected Entities. The ASC X12N 270/271 transaction may be used 
by a health care provider to electronically request and receive 
eligibility information from a health care plan prior to providing or 
billing for a health care service. Many health care providers routinely 
verify health insurance coverage and benefit limitations both prior to 
providing treatment and/or before preparing claims for submission to 
the insured patient and his or her health plan. Currently, health care 
providers secure most of these eligibility determinations through 
telephone calls, proprietary point of sale terminals, or

[[Page 50364]]

using proprietary electronic formats that differ from health plan to 
health plan. Since many health care providers participate in multiple 
health plans, these health care providers must maintain duplicative 
software and hardware, as well as human resources to obtain eligibility 
information. This process is inefficient, often burdensome, and takes 
valuable time that could otherwise be devoted to patient care.
    The lack of a health care industry standard may have imposed a cost 
barrier to the widespread use of electronic data interchange. The ASC 
X12N 270/271 is used widely, but not exclusively, by health care plans 
and health care providers; this may be due, in part, to the lack of an 
industry-wide implementation specification for these transactions in 
health care. We expect that adoption of the ASC X12N 270/271 and its 
implementation specification will lower the cost of using electronic 
eligibility verifications. Use of the ASC X12N 270/271 and its 
implementation specification will benefit health care providers because 
they will be able to move to a single standard format. Consequently, 
electronic data interchange will be feasible for the first time for 
small health plans and health care providers that rely currently on the 
telephone, paper forms, or proprietary point of sale terminals and 
software.
    b. Effect of Various Options. There were two other options, the ASC 
X12N IHCEBI, and its companion, IHCEBR, and the NCPDP 
Telecommunications Standard Format. None of these meet the selection 
criteria and thus they would not be implementable.
7. Specific Impact of Adoption of the ASC X12N 820 for Payroll Deducted 
and Other Group Premium Payment for Insurance Product
    a. Affected Entities. An employer or sponsor can respond to a bill 
from a health plan by using the ASC X12N 820 to electronically transmit 
a remittance notice to accompany a payment for health insurance 
premiums. Payment may be in the form of a paper check or an electronic 
funds transfer transaction. The ASC X12N 820 can be sent with 
electronic funds transfer instructions that are routed directly to the 
Federal Reserve System's automated health care clearinghouses or with 
payments generated directly by the employer's or other sponsor's bank. 
The ASC X12N 820 transaction is widely used by many industries 
(manufacturing, for instance) and government agencies (Department of 
Defense) in addition to the insurance industry in general. However, the 
ASC X12N 820 is not widely used in the health insurance industry and is 
not widely used by employers and other sponsors to make premium 
payments to their health insurers. This may be due, in part, to the 
lack of an implementation specification specifically for health 
insurance.
    Currently, most payment transactions are conducted on paper, and 
those that are conducted electronically use proprietary electronic data 
interchange standards that differ across health plans. We cannot 
quantify how many of these transactions are conducted on paper, but 
anecdotal information suggests that most are. We believe that the lack 
of a health care industry standard may have imposed a cost barrier to 
the use of electronic data interchange; larger employers and other 
sponsors that often transact business with multiple health plans need 
to retain duplicative hardware and software, and human resources to 
support multiple proprietary electronic premium payment standards. We 
expect that the adoption of national standards will lower the cost of 
using electronic premium payments. This will benefit large employers 
that can move to a single standard format; national standards will make 
electronic transmissions of premium payments feasible for the first 
time for smaller employers and other sponsors whose payment 
transactions have been performed almost exclusively in paper.
    At some point, an organization's size and complexity will require 
it to consider switching its business transactions from paper to 
electronic formats, due to the savings and efficiencies conversion 
would produce. The ASC X12N 820 would facilitate premium payment by 
eliminating redundant proprietary formats that are certain to arise 
when there are no widely accepted common standards. By eliminating the 
software, hardware, and human resources associated with redundancy, a 
business may reach the point where it becomes cost beneficial to 
convert from paper to electronic transactions. Also, those sponsors and 
health care plans that already support more than one proprietary format 
will incur some additional expense in the conversion to the standard, 
but they would enjoy longer term savings that result from eliminating 
the redundancies.
    b. Effects of Various Options. There are no known options for 
premium payment transactions.
8. Specific Impact of Adoption of ASC X12N 278 for Referral 
Certification and Authorization
    a. Affected Entities. The ASC X12N 278 may be used by a health care 
provider to electronically request and receive approval from a health 
plan prior to providing a health care service. Prior approvals have 
become standard operating procedure for most hospitals, physicians and 
other health care providers due to the rapid growth of managed care. 
Health care providers secure most of their prior approvals through 
telephone calls, paper forms or proprietary electronic formats that 
differ from health plan to health plan. Since many health care 
providers participate in multiple managed care health plans, they must 
devote redundant software, hardware, and human resources to obtaining 
prior authorization; this process is often untimely and inefficient.
    The lack of a health care industry standard may have imposed a cost 
barrier to the widespread use of electronic data interchange. The ASC 
X12N 278 is not widely used by health plans and health care providers, 
which may be due, in part, to the lack of an industry-wide 
implementation specification for it. The adoption of the ASC X12N 278 
and its implementation specification will lower the cost of using 
electronic prior authorizations. This will benefit health care 
providers that can move to a single standard format; the standard 
transaction will also make electronic data interchange feasible for the 
first time for smaller health plans and health care providers that 
perform these transactions almost exclusively using the telephone or 
paper.
    At some point, an organization's size and complexity will require 
it to consider switching its business transactions from paper to 
electronic form, due to the savings and efficiencies conversion would 
produce. The ASC X12N 278 will facilitate that by eliminating 
duplicative proprietary formats that are certain to arise when there 
are no widely accepted standards. By eliminating the software, 
hardware, and human resources associated with redundancy, a business 
may reach the point where it becomes cost beneficial to convert from 
paper to electronic transactions. Health plans and health care 
providers that already support more than one proprietary format will 
incur some additional expense in converting to the standard, but will 
enjoy longer term savings that result from eliminating the 
redundancies.
    b. Effects of Various Options. There are no known options for 
referral and certification authorization transactions.

VII. Federalism

    Executive Order 13132 of August 4, 1999, Federalism, published in 
the Federal Register on August 10, 1999 (64

[[Page 50365]]

FR 43255) requires us to ensure meaningful and timely input by State 
and local officials in the development of rules that have Federalism 
implications. Although the proposed rule (63 FR 25272) was published 
before the enactment of this Executive Order, the Department consulted 
with State and local officials as part of an outreach program early in 
the process of developing the proposed regulation. The Department 
received comments on the proposed rule from State agencies and from 
entities who conduct transactions with State agencies. Many of the 
comments referred to the costs incurred by State and local governments 
which will result from implementation of the HIPAA standards. We assume 
that government entities will have these costs offset by future 
savings, consistent with our projections for the private sector. A 
Congressional Budget Office analysis made the following points: States 
are already in the forefront of administering the Medicaid program 
electronically, Medicaid State agencies can compensate (for these 
costs) by reducing other expenditures, and the Federal government pays 
a portion of the cost of converting State Medicaid Management 
Information Systems.
    Other comments regarding States expressed the need for 
clarification as to when State agencies were subject to the standards. 
Responses to comments from States and State organizations regarding the 
standard transactions set forth in this rule are found in this 
preamble.
    In complying with the requirements of part C of title XI, the 
Secretary established interdepartmental implementation teams who 
consulted with appropriate State and Federal agencies and private 
organizations. These external groups consisted of the NCVHS 
Subcommittee on Standards and Security, the Workgroup for Electronic 
Data Interchange (WEDI), the National Uniform Claim Committee (NUCC), 
the National Uniform Billing Committee (NUBC) and the American Dental 
Association (ADA). The teams also received comments on the proposed 
regulation from a variety of organizations, including State Medicaid 
agencies and other Federal agencies.

VIII. Interaction with Privacy

    The Secretary has developed this rule in conjunction with the 
development of standards to protect the privacy of individually 
identifiable health information, including information that will be 
transmitted pursuant to these transaction standards. Compliance with 
the privacy standards will be required at approximately the same time 
as the compliance dates of this rule. If the privacy standards are 
substantially delayed, or if Congress fails to adopt comprehensive and 
effective privacy standards that supercede the standards we are 
developing, we would seriously consider suspending the application of 
the transaction standards or taking action to withdraw this rule.

List of Subjects

45 CFR Part 160

    Electronic transactions, Health, Health care, Health facilities, 
Health insurance, Health records, Medicaid, Medical research, Medicare, 
Reporting and recordkeeping requirements.

45 CFR Part 162

    Administrative practice and procedure, Electronic transactions, 
Health facilities, Health insurance, Hospitals, Incorporation by 
reference, Medicare, Medicaid, Reporting and recordkeeping 
requirements.
    For the reasons set forth in the preamble, 45 CFR subtitle A, 
subchapter C, is added to read as follows:

SUBCHAPTER C--ADMINISTRATIVE DATA STANDARDS AND RELATED REQUIREMENTS

PART 160--GENERAL ADMINISTRATIVE REQUIREMENTS

Subpart A--General Provisions
Sec.
160.101   Statutory basis and purpose.
160.102   Applicability.
160.103   Definitions.
160.104   Modifications.
Subpart B--[Reserved]

    Authority: Secs. 1171 through 1179 of the Social Security Act 
(42 U.S.C. 1320d-1320d-8), as added by sec. 262 of Pub. L. 104-191, 
110 Stat. 2021-2031, and sec. 264 of Pub. L. 104-191, 110 Stat. 
2033-2034 (42 U.S.C. 1320d-2 (note)).

Subpart A--General Provisions


Sec. 160.101  Statutory basis and purpose.

    The requirements of this subchapter implement sections 1171 through 
1179 of the Social Security Act (the Act), as added by section 262 of 
Public Law 104-191, and section 264 of Public Law 104-191.


Sec. 160.102  Applicability.

    Except as otherwise provided, the standards, requirements, and 
implementation specifications adopted under this subchapter apply to 
the following entities:
    (a) A health plan.
    (b) A health care clearinghouse.
    (c) A health care provider who transmits any health information in 
electronic form in connection with a transaction covered by this 
subchapter.


Sec. 160.103  Definitions.

    Except as otherwise provided, the following definitions apply to 
this subchapter:
    Act means the Social Security Act.
    ANSI stands for the American National Standards Institute.
    Business associate means a person who performs a function or 
activity regulated by this subchapter on behalf of a covered entity, as 
defined in this section. A business associate may be a covered entity. 
Business associate excludes a person who is part of the covered 
entity's workforce as defined in this section.
    Compliance date means the date by which a covered entity must 
comply with a standard, implementation specification, or modification 
adopted under this subchapter.
    Covered entity means one of the following:
    (1) A health plan.
    (2) A health care clearinghouse.
    (3) A health care provider who transmits any health information in 
electronic form in connection with a transaction covered by this 
subchapter.
    Group health plan (also see definition of health plan in this 
section) means an employee welfare benefit plan (as defined in section 
3(1) of the Employee Retirement Income Security Act of 1974 (ERISA)(29 
U.S.C. 1002(1)), including insured and self-insured plans, to the 
extent that the plan provides medical care, as defined in section 
2791(a)(2) of the Public Health Service (PHS) Act, 42 U.S.C. 300gg-
91(a)(2), including items and services paid for as medical care, to 
employees or their dependents directly or through insurance, 
reimbursement, or otherwise, that--
    (1) Has 50 or more participants (as defined in section 3(7) of 
ERISA, 29 U.S.C. 1002(7)); or
    (2) Is administered by an entity other than the employer that 
established and maintains the plan.
    HCFA stands for Health Care Financing Administration within the 
Department of Health and Human Services.
    HHS stands for the Department of Health and Human Services.
    Health care means care, services, or supplies furnished to an 
individual and related to the health of the individual. Health care 
includes the following:
    (1) Preventive, diagnostic, therapeutic, rehabilitative, 
maintenance, or palliative care; counseling; service; or procedure with 
respect to the physical or mental condition, or functional status, of 
an individual or affecting the structure or function of the body.

[[Page 50366]]

    (2) Sale or dispensing of a drug, device, equipment, or other item 
in accordance with a prescription.
    (3) Procurement or banking of blood, sperm, organs, or any other 
tissue for administration to individuals.
    Health care clearinghouse means a public or private entity that 
does either of the following (Entities, including but not limited to, 
billing services, repricing companies, community health management 
information systems or community health information systems, and 
``value-added'' networks and switches are health care clearinghouses 
for purposes of this subchapter if they perform these functions.):
    (1) Processes or facilitates the processing of information received 
from another entity in a nonstandard format or containing nonstandard 
data content into standard data elements or a standard transaction.
    (2) Receives a standard transaction from another entity and 
processes or facilitates the processing of information into nonstandard 
format or nonstandard data content for a receiving entity.
    Health care provider means a provider of services as defined in 
section 1861(u) of the Act, 42 U.S.C. 1395x(u), a provider of medical 
or other health services as defined in section 1861(s) of the Act, 42 
U.S.C. 1395x(s), and any other person or organization who furnishes, 
bills, or is paid for health care in the normal course of business.
    Health information means any information, whether oral or recorded 
in any form or medium, that --
    (1) Is created or received by a health care provider, health plan, 
public health authority, employer, life insurer, school or university, 
or health care clearinghouse; and
    (2) Relates to the past, present, or future physical or mental 
health or condition of an individual; the provision of health care to 
an individual; or the past, present, or future payment for the 
provision of health care to an individual.
    Health insurance issuer (as defined in section 2791(b) of the PHS 
Act, 42 U.S.C. 300gg-91(b)(2), and used in the definition of health 
plan in this section) means an insurance company, insurance service, or 
insurance organization (including an HMO) that is licensed to engage in 
the business of insurance in a State and is subject to State law that 
regulates insurance. Such term does not include a group health plan.
    Health maintenance organization (HMO) (as defined in section 2791 
of the PHS Act, 42 U.S.C. 300gg-91(b)(3), and used in the definition of 
health plan in this section) means a Federally qualified HMO, an 
organization recognized as an HMO under State law, or a similar 
organization regulated for solvency under State law in the same manner 
and to the same extent as such an HMO.
    Health plan means an individual or group plan that provides, or 
pays the cost of, medical care (as defined in section 2791(a)(2) of the 
PHS Act, 42 U.S.C. 300gg-91(a)(2)). Health plan includes, when applied 
to government funded programs, the components of the government agency 
administering the program. Health plan includes the following, singly 
or in combination:
    (1) A group health plan, as defined in this section.
    (2) A health insurance issuer, as defined in this section.
    (3) An HMO, as defined in this section.
    (4) Part A or Part B of the Medicare program under title XVIII of 
the Act.
    (5) The Medicaid program under title XIX of the Act, 42 U.S.C. 1396 
et seq.
    (6) An issuer of a Medicare supplemental policy (as defined in 
section 1882(g)(1) of the Act, 42 U.S.C. 1395ss(g)(1)).
    (7) An issuer of a long-term care policy, excluding a nursing home 
fixed-indemnity policy.
    (8) An employee welfare benefit plan or any other arrangement that 
is established or maintained for the purpose of offering or providing 
health benefits to the employees of two or more employers.
    (9) The health care program for active military personnel under 
title 10 of the United States Code.
    (10) The veterans health care program under 38 U.S.C. chapter 17.
    (11) The Civilian Health and Medical Program of the Uniformed 
Services (CHAMPUS), as defined in 10 U.S.C. 1072(4).
    (12) The Indian Health Service program under the Indian Health Care 
Improvement Act (25 U.S.C. 1601 et seq.).
    (13) The Federal Employees Health Benefit Program under 5 U.S.C. 
8902 et seq.
    (14) An approved State child health plan under title XXI of the 
Act, providing benefits that meet the requirements of section 2103 of 
the Act, 42 U.S.C. 1397 et seq.
    (15) The Medicare + Choice program under part C of title XVIII of 
the Act, 42 U.S.C. 1395w-21 through 1395w-28.
    (16) Any other individual or group plan, or combination of 
individual or group plans, that provides or pays for the cost of 
medical care (as defined in section 2791(a)(2) of the PHS Act, 42 
U.S.C. 300gg-91(a)(2)).
    Implementation specification means the specific instructions for 
implementing a standard.
    Modify or modification refers to a change adopted by the Secretary, 
through regulation, to a standard or an implementation specification.
    Secretary means the Secretary of Health and Human Services or any 
other officer or employee of the Department of Health and Human 
Services to whom the authority involved has been delegated.
    Small health plan means a health plan with annual receipts of $5 
million or less.
    Standard means a prescribed set of rules, conditions, or 
requirements describing the following information for products, 
systems, services or practices:
    (1) Classification of components.
    (2) Specification of materials, performance, or operations.
    (3) Delineation of procedures.
    Standard setting organization (SSO) means an organization 
accredited by the American National Standards Institute that develops 
and maintains standards for information transactions or data elements, 
or any other standard that is necessary for, or will facilitate the 
implementation of, this part.
    State refers to one of the following:
    (1) For health plans established or regulated by Federal law, State 
has the meaning set forth in the applicable section of the United 
States Code for each health plan.
    (2) For all other purposes, State means the United States, the 
District of Columbia, the Commonwealth of Puerto Rico, the Virgin 
Islands, and Guam.
    Trading partner agreement means an agreement related to the 
exchange of information in electronic transactions, whether the 
agreement is distinct or part of a larger agreement, between each party 
to the agreement. (For example, a trading partner agreement may 
specify, among other things, the duties and responsibilities of each 
party to the agreement in conducting a standard transaction.)
    Transaction means the exchange of information between two parties 
to carry out financial or administrative activities related to health 
care. It includes the following types of information exchanges:
    (1) Health care claims or equivalent encounter information.
    (2) Health care payment and remittance advice.
    (3) Coordination of benefits.
    (4) Health care claim status.
    (5) Enrollment and disenrollment in a health plan.
    (6) Eligibility for a health plan.
    (7) Health plan premium payments.

[[Page 50367]]

    (8) Referral certification and authorization.
    (9) First report of injury.
    (10) Health claims attachments.
    (11) Other transactions that the Secretary may prescribe by 
regulation.
    Workforce means employees, volunteers, trainees, and other persons 
under the direct control of a covered entity, whether or not they are 
paid by the covered entity.


Sec. 160.104  Modifications.

    (a) Except as provided in paragraph (b) of this section, the 
Secretary may adopt a modification to a standard or implementation 
specification adopted under this subchapter no more frequently than 
once every 12 months.
    (b) The Secretary may adopt a modification at any time during the 
first year after the standard or implementation specification is 
initially adopted, if the Secretary determines that the modification is 
necessary to permit compliance with the standard.
    (c) The Secretary establishes the compliance date for any standard 
or implementation specification modified under this section.
    (1) The compliance date for a modification is no earlier than 180 
days after the effective date of the final rule in which the Secretary 
adopts the modification.
    (2) The Secretary may consider the extent of the modification and 
the time needed to comply with the modification in determining the 
compliance date for the modification.
    (3) The Secretary may extend the compliance date for small health 
plans, as the Secretary determines is appropriate.

Subpart B--[Reserved]

PART 162--ADMINISTRATIVE REQUIREMENTS

Subpart A--General Provisions
Sec.
162.100   Applicability.
162.103   Definitions.
Subparts B-H--[Reserved]
Subpart I--General Provisions for Transactions
162.900  Compliance dates of the initial implementation of the code 
sets and transaction standards.
162.910   Maintenance of standards and adoption of modifications and 
new standards.
162.915   Trading partner agreements.
162.920   Availability of implementation specifications.
162.923   Requirements for covered entities.
162.925   Additional requirements for health plans.
162.930   Additional rules for health care clearinghouses.
162.940   Exceptions from standards to permit testing of proposed 
modifications.
Subpart J--Code Sets
162.1000   General requirements.
162.1002   Medical data code sets.
162.1011   Valid code sets.
Subpart K--Health Care Claims or Equivalent Encounter Information
162.1101   Health care claims or equivalent encounter information 
transaction.
162.1102   Standards for health care claims or equivalent encounter 
information.
Subpart L--Eligibility for a Health Plan
162.1201   Eligibility for a health plan transaction.
162.1202   Standards for eligibility for a health plan.
Subpart M--Referral Certification and Authorization
162.1301   Referral certification and authorization transaction.
162.1302   Standard for referral certification and authorization.
Subpart N--Health Care Claim Status
162.1401   Health care claim status transaction.
162.1402   Standard for health care claim status.
Subpart O--Enrollment and Disenrollment in a Health Plan
162.1501   Enrollment and disenrollment in a health plan 
transaction.
162.1502   Standard for enrollment and disenrollment in a health 
plan.
Subpart P--Health Care Payment and Remittance Advice
162.1601   Health care payment and remittance advice transaction.
162.1602   Standards for health care payment and remittance advice.
Subpart Q--Health Plan Premium Payments
162.1701   Health plan premium payments transaction.
162.1702   Standard for health plan premium payments.
Subpart R--Coordination of Benefits
162.1801   Coordination of benefits transaction.
162.1802   Standards for coordination of benefits.

    Authority: Secs. 1171 through 1179 of the Social Security Act 
(42 U.S.C. 1320d--1320d-8), as added by sec. 262 of Pub. L. 104-191, 
110 Stat. 2021-2031, and sec. 264 of Pub. L. 104-191, 110 Stat. 
2033-2034 (42 U.S.C. 1320d-2 (note)).

Subpart A--General Provisions


Sec. 162.100  Applicability.

    Covered entities (as defined in Sec. 160.103 of this subchapter) 
must comply with the applicable requirements of this part.


Sec. 162.103  Definitions.

    For purposes of this part, the following definitions apply:
    Code set means any set of codes used to encode data elements, such 
as tables of terms, medical concepts, medical diagnostic codes, or 
medical procedure codes. A code set includes the codes and the 
descriptors of the codes.
    Code set maintaining organization means an organization that 
creates and maintains the code sets adopted by the Secretary for use in 
the transactions for which standards are adopted in this part.
    Data condition means the rule that describes the circumstances 
under which a covered entity must use a particular data element or 
segment.
    Data content means all the data elements and code sets inherent to 
a transaction, and not related to the format of the transaction. Data 
elements that are related to the format are not data content.
    Data element means the smallest named unit of information in a 
transaction.
    Data set means a semantically meaningful unit of information 
exchanged between two parties to a transaction.
    Descriptor means the text defining a code.
    Designated standard maintenance organization (DSMO) means an 
organization designated by the Secretary under Sec. 162.910(a).
    Direct data entry means the direct entry of data (for example, 
using dumb terminals or web browsers) that is immediately transmitted 
into a health plan's computer.
    Electronic media means the mode of electronic transmission. It 
includes the Internet (wide-open), Extranet (using Internet technology 
to link a business with information only accessible to collaborating 
parties), leased lines, dial-up lines, private networks, and those 
transmissions that are physically moved from one location to another 
using magnetic tape, disk, or compact disk media.
    Format refers to those data elements that provide or control the 
enveloping or hierarchical structure, or assist in identifying data 
content of, a transaction.
    HCPCS stands for the Health [Care Financing Administration] Common 
Procedure Coding System.
    Maintain or maintenance refers to activities necessary to support 
the use of a standard adopted by the Secretary, including technical 
corrections to an implementation specification, and enhancements or 
expansion of a code set. This term excludes the activities related to 
the adoption of a new standard or implementation specification, or 
modification to an

[[Page 50368]]

adopted standard or implementation specification.
    Maximum defined data set means all of the required data elements 
for a particular standard based on a specific implementation 
specification.
    Segment means a group of related data elements in a transaction.
    Standard transaction means a transaction that complies with the 
applicable standard adopted under this part.

Subparts B--H [Reserved]

Subpart I--General Provisions for Transactions


Sec. 162.900--Compliance  dates of the initial implementation of the 
code sets and transaction standards.

    (a) Health care providers. A covered health care provider must 
comply with the applicable requirements of subparts I through N of this 
part no later than October 16, 2002.
    (b) Health plans. A health plan must comply with the applicable 
requirements of subparts I through R of this part no later than one of 
the following dates:
    (1) Health plans other than small health plans-- October 16, 2002.
    (2) Small health plans-- October 16, 2003.
    (c) Health care clearinghouses. A health care clearinghouse must 
comply with the applicable requirements of subparts I through R of this 
part no later than October 16, 2002.


Sec. 162.910  Maintenance of standards and adoption of modifications 
and new standards.

    (a) Designation of DSMOs. (1) The Secretary may designate as a DSMO 
an organization that agrees to conduct, to the satisfaction of the 
Secretary, the following functions:
    (i) Maintain standards adopted under this subchapter.
    (ii) Receive and process requests for adopting a new standard or 
modifying an adopted standard.
    (2) The Secretary designates a DSMO by notice in the Federal 
Register.
    (b) Maintenance of standards. Maintenance of a standard by the 
appropriate DSMO constitutes maintenance of the standard for purposes 
of this part, if done in accordance with the processes the Secretary 
may require.
    (c) Process for modification of existing standards and adoption of 
new standards. The Secretary considers a recommendation for a proposed 
modification to an existing standard, or a proposed new standard, only 
if the recommendation is developed through a process that provides for 
the following:
    (1) Open public access.
    (2) Coordination with other DSMOs.
    (3) An appeals process for each of the following, if dissatisfied 
with the decision on the request:
    (i) The requestor of the proposed modification.
    (ii) A DSMO that participated in the review and analysis of the 
request for the proposed modification, or the proposed new standard.
    (4) Expedited process to address content needs identified within 
the industry, if appropriate.
    (5) Submission of the recommendation to the National Committee on 
Vital and Health Statistics (NCVHS).


Sec. 162.915  Trading partner agreements.

    A covered entity must not enter into a trading partner agreement 
that would do any of the following:
    (a) Change the definition, data condition, or use of a data element 
or segment in a standard.
    (b) Add any data elements or segments to the maximum defined data 
set.
    (c) Use any code or data elements that are either marked ``not 
used'' in the standard's implementation specification or are not in the 
standard's implementation specification(s).
    (d) Change the meaning or intent of the standard's implementation 
specification(s).


Sec. 162.920  Availability of implementation specifications.

    (a) Access to implementation specifications. A person or 
organization may request copies (or access for inspection) of the 
implementation specifications for a standard described in subparts K 
through R of this part by identifying the standard by name, number, and 
version. The implementation specifications are available as follows:
    (1) ASC X12N specifications. The implementation specifications for 
ASC X12N standards may be obtained from the Washington Publishing 
Company, PMB 161, 5284 Randolph Road, Rockville, MD, 20852-2116; 
telephone 301-949-9740; and FAX: 301-949-9742. They are also available 
through the Washington Publishing Company on the Internet at http://www.wpc-edi.com. The implementation specifications are as follows:
    (i) The ASC X12N 837--Health Care Claim: Dental, Version 4010, May 
2000, Washington Publishing Company, 004010X097, as referenced in 
Secs. 162.1102 and 162.1802.
    (ii) The ASC X12N 837--Health Care Claim: Professional, Volumes 1 
and 2, Version 4010, May 2000, Washington Publishing Company, 
004010X098, as referenced in Secs. 162.1102 and 162.1802.
    (iii) The ASC X12N 837--Health Care Claim: Institutional, Volumes 1 
and 2, Version 4010, May 2000, Washington Publishing Company, 
004010X096, as referenced in Secs. 162.1102 and 162.1802.
    (iv) The ASC X12N 270/271--Health Care Eligibility Benefit Inquiry 
and Response, Version 4010, May 2000, Washington Publishing Company, 
004010X092, as referenced in Sec. 162.1202.
    (v) The ASC X12N 278--Health Care Services Review--Request for 
Review and Response, Version 4010, May 2000, Washington Publishing 
Company, 004010X094, as referenced in Sec. 162.1302.
    (vi) The ASC X12N 276/277 Health Care Claim Status Request and 
Response, Version 4010, May 2000, Washington Publishing Company, 
004010X093, as referenced in Sec. 162.1402.
    (vii) The ASC X12N 834--Benefit Enrollment and Maintenance, Version 
4010, May 2000, Washington Publishing Company, 004010X095, as 
referenced in Sec. 162.1502.
    (viii) The ASC X12N 835--Health Care Claim Payment/Advice, Version 
4010, May 2000, Washington Publishing Company, 004010X091, as 
referenced in Sec. 162.1602.
    (ix) The ASC X12N 820--Payroll Deducted and Other Group Premium 
Payment for Insurance Products, Version 4010, May 2000, Washington 
Publishing Company, 004010X061, as referenced in Sec. 162.1702.
    (2) Retail pharmacy specifications. The implementation 
specifications for all retail pharmacy standards may be obtained from 
the National Council for Prescription Drug Programs (NCPDP), 4201 North 
24th Street, Suite 365, Phoenix, AZ, 85016; telephone 602-957-9105; and 
FAX 602-955-0749. It may also be obtained through the Internet at 
http://www.ncpdp.org. The implementation specifications are as follows:
    (i) The Telecommunication Standard Implementation Guide, Version 5 
Release 1, September 1999, National Council for Prescription Drug 
Programs, as referenced in Secs. 162.1102, 162.1202, 162.1602, and 
162.1802.
    (ii) The Batch Standard Batch Implementation Guide, Version 1 
Release 0, February 1, 1996, National Council for Prescription Drug 
Programs, as referenced in Secs. 162.1102, 162.1202, 162.1602, and 
162.1802.

[[Page 50369]]

    (b) Incorporations by reference. The Director of the Office of the 
Federal Register approves the implementation specifications described 
in paragraph (a) of this section for incorporation by reference in 
subparts K through R of this part in accordance with 5 U.S.C. 552(a) 
and 1 CFR part 51. A copy of the implementation specifications may be 
inspected at the Office of the Federal Register, 800 North Capitol 
Street, NW, Suite 700, Washington, DC.


Sec. 162.923  Requirements for covered entities.

    (a) General rule. Except as otherwise provided in this part, if a 
covered entity conducts with another covered entity (or within the same 
covered entity), using electronic media, a transaction for which the 
Secretary has adopted a standard under this part, the covered entity 
must conduct the transaction as a standard transaction.
    (b) Exception for direct data entry transactions. A health care 
provider electing to use direct data entry offered by a health plan to 
conduct a transaction for which a standard has been adopted under this 
part must use the applicable data content and data condition 
requirements of the standard when conducting the transaction. The 
health care provider is not required to use the format requirements of 
the standard.
    (c) Use of a business associate. A covered entity may use a 
business associate, including a health care clearinghouse, to conduct a 
transaction covered by this part. If a covered entity chooses to use a 
business associate to conduct all or part of a transaction on behalf of 
the covered entity, the covered entity must require the business 
associate to do the following:
    (1) Comply with all applicable requirements of this part.
    (2) Require any agent or subcontractor to comply with all 
applicable requirements of this part.


Sec. 162.925  Additional requirements for health plans.

    (a) General rules. (1) If an entity requests a health plan to 
conduct a transaction as a standard transaction, the health plan must 
do so.
    (2) A health plan may not delay or reject a transaction, or attempt 
to adversely affect the other entity or the transaction, because the 
transaction is a standard transaction.
    (3) A health plan may not reject a standard transaction on the 
basis that it contains data elements not needed or used by the health 
plan (for example, coordination of benefits information).
    (4) A health plan may not offer an incentive for a health care 
provider to conduct a transaction covered by this part as a transaction 
described under the exception provided for in Sec. 162.923(b).
    (5) A health plan that operates as a health care clearinghouse, or 
requires an entity to use a health care clearinghouse to receive, 
process, or transmit a standard transaction may not charge fees or 
costs in excess of the fees or costs for normal telecommunications that 
the entity incurs when it directly transmits, or receives, a standard 
transaction to, or from, a health plan.
    (b) Coordination of benefits. If a health plan receives a standard 
transaction and coordinates benefits with another health plan (or 
another payer), it must store the coordination of benefits data it 
needs to forward the standard transaction to the other health plan (or 
other payer).
    (c) Code sets. A health plan must meet each of the following 
requirements:
    (1) Accept and promptly process any standard transaction that 
contains codes that are valid, as provided in subpart J of this part.
    (2) Keep code sets for the current billing period and appeals 
periods still open to processing under the terms of the health plan's 
coverage.


Sec. 162.930  Additional rules for health care clearinghouses.

    When acting as a business associate for another covered entity, a 
health care clearinghouse may perform the following functions:
    (a) Receive a standard transaction on behalf of the covered entity 
and translate it into a nonstandard transaction (for example, 
nonstandard format and/or nonstandard data content) for transmission to 
the covered entity.
    (b) Receive a nonstandard transaction (for example, nonstandard 
format and/or nonstandard data content) from the covered entity and 
translate it into a standard transaction for transmission on behalf of 
the covered entity.


Sec. 162.940  Exceptions from standards to permit testing of proposed 
modifications.

    (a) Requests for an exception. An organization may request an 
exception from the use of a standard from the Secretary to test a 
proposed modification to that standard. For each proposed modification, 
the organization must meet the following requirements:
    (1) Comparison to a current standard. Provide a detailed 
explanation, no more than 10 pages in length, of how the proposed 
modification would be a significant improvement to the current standard 
in terms of the following principles:
    (i) 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.
    (ii) Meet the needs of the health data standards user community, 
particularly health care providers, health plans, and health care 
clearinghouses.
    (iii) Be uniform and consistent with the other standards adopted 
under this part and, as appropriate, with other private and public 
sector health data standards.
    (iv) Have low additional development and implementation costs 
relative to the benefits of using the standard.
    (v) Be supported by an ANSI-accredited SSO or other private or 
public organization that would maintain the standard over time.
    (vi) Have timely development, testing, implementation, and updating 
procedures to achieve administrative simplification benefits faster.
    (vii) Be technologically independent of the computer platforms and 
transmission protocols used in electronic health transactions, unless 
they are explicitly part of the standard.
    (viii) Be precise, unambiguous, and as simple as possible.
    (ix) Result in minimum data collection and paperwork burdens on 
users.
    (x) Incorporate flexibility to adapt more easily to changes in the 
health care infrastructure (such as new services, organizations, and 
provider types) and information technology.
    (2) Specifications for the proposed modification. Provide 
specifications for the proposed modification, including any additional 
system requirements.
    (3) Testing of the proposed modification. Provide an explanation, 
no more than 5 pages in length, of how the organization intends to test 
the standard, including the number and types of health plans and health 
care providers expected to be involved in the test, geographical areas, 
and beginning and ending dates of the test.
    (4) Trading partner concurrences. Provide written concurrences from 
trading partners who would agree to participate in the test.
    (b) Basis for granting an exception. The Secretary may grant an 
initial exception, for a period not to exceed 3 years, based on, but 
not limited to, the following criteria:
    (1) An assessment of whether the proposed modification demonstrates 
a significant improvement to the current standard.
    (2) The extent and length of time of the exception.
    (3) Consultations with DSMOs.
    (c) Secretary's decision on exception. The Secretary makes a 
decision and

[[Page 50370]]

notifies the organization requesting the exception whether the request 
is granted or denied.
    (1) Exception granted. If the Secretary grants an exception, the 
notification includes the following information:
    (i) The length of time for which the exception applies.
    (ii) The trading partners and geographical areas the Secretary 
approves for testing.
    (iii) Any other conditions for approving the exception.
    (2) Exception denied. If the Secretary does not grant an exception, 
the notification explains the reasons the Secretary considers the 
proposed modification would not be a significant improvement to the 
current standard and any other rationale for the denial.
    (d) Organization's report on test results. Within 90 days after the 
test is completed, an organization that receives an exception must 
submit a report on the results of the test, including a cost-benefit 
analysis, to a location specified by the Secretary by notice in the 
Federal Register.
    (e) Extension allowed. If the report submitted in accordance with 
paragraph (d) of this section recommends a modification to the 
standard, the Secretary, on request, may grant an extension to the 
period granted for the exception.

Subpart J--Code Sets


Sec. 162.1000  General requirements.

    When conducting a transaction covered by this part, a covered 
entity must meet the following requirements:
    (a) Medical data code sets. Use the applicable medical data code 
sets described in Sec. 162.1002 as specified in the implementation 
specification adopted under this part that are valid at the time the 
health care is furnished.
    (b) Nonmedical data code sets. Use the nonmedical data code sets as 
described in the implementation specifications adopted under this part 
that are valid at the time the transaction is initiated.


Sec. 162.1002  Medical data code sets.

    The Secretary adopts the following code set maintaining 
organization's code sets as the standard medical data code sets:
    (a) International Classification of Diseases, 9th Edition, Clinical 
Modification, (ICD-9-CM), Volumes 1 and 2 (including The Official ICD-
9-CM Guidelines for Coding and Reporting), as maintained and 
distributed by HHS, for the following conditions:
    (1) Diseases.
    (2) Injuries.
    (3) Impairments.
    (4) Other health problems and their manifestations.
    (5) Causes of injury, disease, impairment, or other health 
problems.
    (b) International Classification of Diseases, 9th Edition, Clinical 
Modification, Volume 3 Procedures (including The Official ICD-9-CM 
Guidelines for Coding and Reporting), as maintained and distributed by 
HHS, for the following procedures or other actions taken for diseases, 
injuries, and impairments on hospital inpatients reported by hospitals:
    (1) Prevention.
    (2) Diagnosis.
    (3) Treatment.
    (4) Management.
    (c) National Drug Codes (NDC), as maintained and distributed by 
HHS, in collaboration with drug manufacturers, for the following:
    (1) Drugs
    (2) Biologics.
    (d) Code on Dental Procedures and Nomenclature, as maintained and 
distributed by the American Dental Association, for dental services.
    (e) The combination of Health Care Financing Administration Common 
Procedure Coding System (HCPCS), as maintained and distributed by HHS, 
and Current Procedural Terminology, Fourth Edition (CPT-4), as 
maintained and distributed by the American Medical Association, for 
physician services and other health care services. These services 
include, but are not limited to, the following:
    (1) Physician services.
    (2) Physical and occupational therapy services.
    (3) Radiologic procedures.
    (4) Clinical laboratory tests.
    (5) Other medical diagnostic procedures.
    (6) Hearing and vision services.
    (7) Transportation services including ambulance.
    (f) The Health Care Financing Administration Common Procedure 
Coding System (HCPCS), as maintained and distributed by HHS, for all 
other substances, equipment, supplies, or other items used in health 
care services. These items include, but are not limited to, the 
following:
    (1) Medical supplies.
    (2) Orthotic and prosthetic devices.
    (3) Durable medical equipment.


Sec. 162.1011  Valid code sets.

    Each code set is valid within the dates specified by the 
organization responsible for maintaining that code set.

Subpart K--Health Care Claims or Equivalent Encounter Information


Sec. 162.1101  Health care claims or equivalent encounter information 
transaction.

    The health care claims or equivalent encounter information 
transaction is the transmission of either of the following:
    (a) A request to obtain payment, and the necessary accompanying 
information from a health care provider to a health plan, for health 
care.
    (b) If there is no direct claim, because the reimbursement contract 
is based on a mechanism other than charges or reimbursement rates for 
specific services, the transaction is the transmission of encounter 
information for the purpose of reporting health care.


Sec. 162.1102  Standards for health care claims or equivalent encounter 
information.

    The Secretary adopts the following standards for the health care 
claims or equivalent encounter information transaction:
    (a) Retail pharmacy drug claims. The National Council for 
Prescription Drug Programs (NCPDP) Telecommunication Standard 
Implementation Guide, Version 5 Release 1, September 1999, and 
equivalent NCPDP Batch Standard Batch Implementation Guide, Version 1 
Release 0, February 1, 1996. The implementation specifications are 
available at the addresses specified in Sec. 162.920(a)(2).
    (b) Dental Health Care Claims. The ASC X12N 837--Health Care Claim: 
Dental, Version 4010, May 2000, Washington Publishing Company, 
004010X097. The implementation specification is available at the 
addresses specified in Sec. 162.920(a)(1).
    (c) Professional Health Care Claims. The ASC X12N 837--Health Care 
Claim: Professional, Volumes 1 and 2, Version 4010, May 2000, 
Washington Publishing Company, 004010X098. The implementation 
specification is available at the addresses specified in 
Sec. 162.920(a)(1).
    (d) Institutional Health Care Claims. The ASC X12N 837--Health Care 
Claim: Institutional, Volumes 1 and 2, Version 4010, May 2000, 
Washington Publishing Company, 004010X096. The implementation 
specification is available at the addresses specified in 
Sec. 162.920(a)(1).

Subpart L--Eligibility for a Health Plan


Sec. 162.1201  Eligibility for a health plan transaction.

    The eligibility for a health plan transaction is the transmission 
of either of the following:

[[Page 50371]]

    (a) An inquiry from a health care provider to a health plan, or 
from one health plan to another health plan, to obtain any of the 
following information about a benefit plan for an enrollee:
    (1) Eligibility to receive health care under the health plan.
    (2) Coverage of health care under the health plan.
    (3) Benefits associated with the benefit plan.
    (b) A response from a health plan to a health care provider's (or 
another health plan's) inquiry described in paragraph (a) of this 
section.


Sec. 162.1202  Standards for eligibility for a health plan.

    The Secretary adopts the following standards for the eligibility 
for a health plan transaction:
    (a) Retail pharmacy drugs. The NCPDP Telecommunication Standard 
Implementation Guide, Version 5 Release 1, September 1999, and 
equivalent NCPDP Batch Standard Batch Implementation Guide, Version 1 
Release 0, February 1, 1996. The implementation specifications are 
available at the addresses specified in Sec. 162.920(a)(2).
    (b) Dental, professional, and institutional. The ASC X12N 270/271-
Health Care Eligibility Benefit Inquiry and Response, Version 4010, May 
2000, Washington Publishing Company, 004010X092. The implementation 
specification is available at the addresses specified in 
Sec. 162.920(a)(1).

Subpart M--Referral Certification and Authorization


Sec. 162.1301  Referral certification and authorization transaction.

    The referral certification and authorization transaction is any of 
the following transmissions:
    (a) A request for the review of health care to obtain an 
authorization for the health care.
    (b) A request to obtain authorization for referring an individual 
to another health care provider.
    (c) A response to a request described in paragraph (a) or paragraph 
(b) of this section.


Sec. 162.1302  Standard for referral certification and authorization.

    The Secretary adopts the ASC X12N 278--Health Care Services 
Review--Request for Review and Response, Version 4010, May 2000, 
Washington Publishing Company, 004010X094 as the standard for the 
referral certification and authorization transaction. The 
implementation specification is available at the addresses specified in 
Sec. 162.920(a)(1).

Subpart N--Health Care Claim Status


Sec. 162.1401  Health care claim status transaction.

    A health care claim status transaction is the transmission of 
either of the following:
    (a) An inquiry to determine the status of a health care claim.
    (b) A response about the status of a health care claim.


Sec. 162.1402  Standard for health care claim status.

    The Secretary adopts the ASC X12N 276/277 Health Care Claim Status 
Request and Response, Version 4010, May 2000, Washington Publishing 
Company, 004010X093 as the standard for the health care claim status 
transaction. The implementation specification is available at the 
addresses specified in Sec. 162.920(a)(1).

Subpart O--Enrollment and Disenrollment in a Health Plan


Sec. 162.1501  Enrollment and disenrollment in a health plan 
transaction.

    The enrollment and disenrollment in a health plan transaction is 
the transmission of subscriber enrollment information to a health plan 
to establish or terminate insurance coverage.


Sec. 162.1502  Standard for enrollment and disenrollment in a health 
plan.

    The Secretary adopts the ASC X12N 834--Benefit Enrollment and 
Maintenance, Version 4010, May 2000, Washington Publishing Company, 
004010X095 as the standard for the enrollment and disenrollment in a 
health plan transaction. The implementation specification is available 
at the addresses specified in Sec. 162.920(a)(1).

Subpart P--Health Care Payment and Remittance Advice


Sec. 162.1601  Health care payment and remittance advice transaction.

    The health care payment and remittance advice transaction is the 
transmission of either of the following for health care:
    (a) The transmission of any of the following from a health plan to 
a health care provider's financial institution:
    (1) Payment.
    (2) Information about the transfer of funds.
    (3) Payment processing information.
    (b) The transmission of either of the following from a health plan 
to a health care provider:
    (1) Explanation of benefits.
    (2) Remittance advice.


Sec. 162.1602  Standards for health care payment and remittance advice.

    The Secretary adopts the following standards for the health care 
payment and remittance advice transaction:
    (a) Retail pharmacy drug claims and remittance advice. The NCPDP 
Telecommunication Standard Implementation Guide, Version 5 Release 1, 
September 1999, and equivalent NCPDP Batch Standard Batch 
Implementation Guide, Version 1 Release 0, February 1, 1996. The 
implementation specifications are available at the addresses specified 
in Sec. 162.920(a)(2).
    (b) Dental, professional, and institutional health care claims and 
remittance advice. The ASC X12N 835--Health Care Claim Payment/Advice, 
Version 4010, May 2000, Washington Publishing Company, 004010X091. The 
implementation specification is available at the addresses specified in 
Sec. 162.920(a)(1).

Subpart Q--Health Plan Premium Payments


Sec. 162.1701  Health plan premium payments transaction.

    The health plan premium payment transaction is the transmission of 
any of the following from the entity that is arranging for the 
provision of health care or is providing health care coverage payments 
for an individual to a health plan:
    (a) Payment.
    (b) Information about the transfer of funds.
    (c) Detailed remittance information about individuals for whom 
premiums are being paid.
    (d) Payment processing information to transmit health care premium 
payments including any of the following:
    (1) Payroll deductions.
    (2) Other group premium payments.
    (3) Associated group premium payment information.


Sec. 162.1702  Standard for health plan premium payments.

    The Secretary adopts the ASC X12N 820--Payroll Deducted and Other 
Group Premium Payment for Insurance Products, Version 4010, May 2000, 
Washington Publishing Company, 004010X061 as the standard for the 
health plan premium payments transaction. The implementation 
specification is available at the addresses specified in 
Sec. 162.920(a)(1).

Subpart R--Coordination of Benefits


Sec. 162.1801  Coordination of benefits transaction.

    The coordination of benefits transaction is the transmission from 
any

[[Page 50372]]

entity to a health plan for the purpose of determining the relative 
payment responsibilities of the health plan, of either of the following 
for health care:
    (a) Claims.
    (b) Payment information.


Sec. 162.1802  Standards for coordination of benefits.

    The Secretary adopts the following standards for the coordination 
of benefits information transaction:
    (a) Retail pharmacy drug claims. The NCPDP Telecommunication 
Standard Implementation Guide, Version 5 Release 1, September 1999, and 
equivalent NCPDP Batch Standard Batch Implementation Guide, Version 1 
Release 0, February 1, 1996. The implementation specifications are 
available at the addresses specified in Sec. 162.920(a)(2).
    (b) Dental claims. The ASC X12N 837--Health Care Claim: Dental, 
Version 4010, May 2000, Washington Publishing Company, 004010X097. The 
implementation specification is available at the addresses specified in 
Sec. 162.920(a)(1).
    (c) Professional health care claims. The ASC X12N 837--Health Care 
Claim: Professional, Volumes 1 and 2, Version 4010, May 2000, 
Washington Publishing Company, 004010X098. The implementation 
specification is available at the addresses specified in 
Sec. 162.920(a)(1).
    (d) Institutional health care claims. The ASC X12N 837--Health Care 
Claim: Institutional, Volumes 1 and 2, Version 4010, May 2000, 
Washington Publishing Company, 004010X096. The implementation 
specification is available at the addresses specified in 
Sec. 162.920(a)(1).

    Authority: Secs. 1171 through 1179 of the Social Security Act 
(42 U.S.C. 1320d-1320d-8), as added by sec. 262 of Public Law 104-
191, 110 Stat. 2021-2031, and sec. 264 of Pub. L. 104-191, 110 Stat. 
2033-2034 (42 U.S.C. 1320d-2 (note)).


(Catalog of Federal Domestic Assistance Program No. 93.774, 
Medicare--Supplementary Medical Insurance Program)

    Dated: July 24, 2000.
Donna Shalala,
Secretary.
[FR Doc. 00-20820 Filed 8-11-00; 3:41 pm]
BILLING CODE 4120-01-U