[Federal Register Volume 63, Number 88 (Thursday, May 7, 1998)]
[Proposed Rules]
[Pages 25272-25320]
From the Federal Register Online via the Government Publishing Office [www.gpo.gov]
[FR Doc No: 98-11691]



[[Page 25271]]

_______________________________________________________________________

Part II





Department of Health and Human Services





_______________________________________________________________________



Health Care Financing Administration



_______________________________________________________________________



45 CFR Part 142



Health Insurance Reform: Standards for Electronic Transactions; 
National Standard Health Care Provider Identifier; Proposed Rules

Federal Register / Vol. 63, No. 88 / Thursday, May 7, 1998 / Proposed 
Rules

[[Page 25272]]



DEPARTMENT OF HEALTH AND HUMAN SERVICES

Office of the Secretary

45 CFR Part 142

[HCFA-0149-P]
RIN 0938-AI58


Health Insurance Reform: Standards for Electronic Transactions

AGENCY: Health Care Financing Administration (HCFA), HHS.

ACTION: Proposed rule.

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

SUMMARY: This rule proposes standards for eight electronic transactions 
and for code sets to be used in those transactions. It also proposes 
requirements concerning the use of these standards by health plans, 
health care clearinghouses, and health care providers.
    The use of these standard transactions and code sets would 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 would implement some of the requirements 
of Administrative Simplification subtitle of the Health Insurance 
Portability and Accountability Act of 1996.

DATES: Comments will be considered if we receive them at the 
appropriate address, as provided below, no later than 5 p.m. on July 6, 
1998.

ADDRESSES: Mail written comments (1 original and 3 copies) to the 
following address:

Health Care Financing Administration, U.S. Department of Health and 
Human Services, Attention: HCFA-0149-P, P.O. Box 31850, Baltimore, MD 
21207-8850.

    If you prefer, you may deliver your written comments (1 original 
and 3 copies) to one of the following addresses:

Room 309-G, Hubert H. Humphrey Building, 200 Independence Avenue, SW., 
Washington, DC 20201,
    or
Room C5-09-26, 7500 Security Boulevard, Baltimore, MD 21244-1850.

    Comments may also be submitted electronically to the following e-
mail address: <a href="/cdn-cgi/l/email-protection#fb8f899a95889a988fbb94889a888b9ed59f939388d59c948d"><span class="__cf_email__" data-cfemail="92e6e0f3fce1f3f1e6d2fde1f3e1e2f7bcf6fafae1bcf5fde4">[email protected]</span></a>. E-mail comments should include 
the full name and address of the sender and must be submitted to the 
referenced address to be considered. All comments should be 
incorporated in the e-mail message because we may not be able to access 
attachments. Electronically submitted comments will be available for 
public inspection at the Independence Avenue address below.
    Because of staffing and resource limitations, we cannot accept 
comments by facsimile (FAX) transmission. In commenting, please refer 
to file code HCFA-0149-P and the specific section of this proposed 
rule. Comments received timely will be available for public inspection 
as they are received, generally beginning approximately 3 weeks after 
publication of a document, in Room 309-G of the Department's offices at 
200 Independence Avenue, SW., Washington, DC, on Monday through Friday 
of each week from 8:30 a.m. to 5 p.m. (phone: (202) 690-7890). 
Electronic and legible written comments will also be posted, along with 
this proposed rule, at the following web site: <a href="http://aspe.os.dhhs.gov/
admnsimp">http://aspe.os.dhhs.gov/
admnsimp</a>.
    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.
    This Federal Register document is also available from the Federal 
Register online database through GPO Access, a service of the U.S. 
Government Printing Office. Free public access is available on a Wide 
Area Information Server (WAIS) through the Internet and via 
asynchronous dial-in. Internet users can access the database by using 
the World Wide Web; the Superintendent of Documents home page address 
is
http://www.access.gpo.gov/su__docs/, by using local WAIS client 
software, or by telnet to swais.access.gpo.gov, then login as guest (no 
password required). Dial-in users should use communications software 
and modem to call 202-512-1661; type swais, then login as guest (no 
password required).

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 care 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:

I. Background

[Please label written or e-mailed comments about this section with 
the subject: Background]

    Electronic data interchange (EDI) is the electronic transfer of 
information, such as electronic media health care claims, in a standard 
format between trading partners. EDI allows entities within the health 
care system to exchange medical, billing, and other information and 
process transactions in a manner which is fast and cost effective. With 
EDI there is a substantial reduction in handling and process time, and 
the risk of lost paper documents is eliminated. EDI can eliminate the 
inefficiencies of handling paper documents, which will significantly 
reduce the 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 care 
claims being used in the United States. The lack of standardization 
makes it difficult to develop software, and the efficiencies and 
savings for health care providers and health plans that could be 
realized if formats were standardized are diminished.
    Adopting national standard EDI formats for health care transactions 
would greatly decrease the burden on health care providers and their 
billing services, as would standardized data content. Standard EDI 
format allows data interchange using a common interchange structure, 
thus eliminating the need for users to reprogram their data processing 
systems for multiple formats. Standardization of the data content 
within the interchange structure involves: (1) Uniform definitions of 
the data elements that will be exchanged in each type of electronic 
transaction, and

[[Page 25273]]

(2) for some data elements, identification of the specific codes or 
values that are valid for each data element. The code sets needed for 
EDI in the health care industry include large coding and classification 
systems for medical diagnoses, procedures, and drugs, as well as 
smaller sets of codes for such items as types of facility, types of 
currency, types of units, and specified State within the United States. 
Standardized data content is essential to accurate and efficient EDI 
between the many producers and users of administrative health data 
transactions.

A. Legislation

    The Congress included provisions to address the need 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 and 
Medicaid programs in particular and the efficiency and effectiveness of 
the health care system in general by encouraging the development of a 
health information system through the establishment of standards and 
requirements to facilitate the electronic transmission 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 concerning the electronic transmission of 
health information.
    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, individually identifiable health information, standard, 
and standard setting organization.
    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 providers that transmit 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.
    <bullet> 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).
    <bullet> 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.
    <bullet> 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.
    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, Federal, and private agencies or organizations, and 
publish the recommendations of the NCVHS 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 claims, health 
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 claim status, and referral certification and 
authorization. In addition, the Secretary is required to adopt 
standards for any other financial and administrative transactions that 
are determined to be appropriate by the Secretary.
    Paragraph (b) of section 1173 of the Act requires the Secretary to 
adopt standards for unique health identifiers for all individuals, 
employers, health plans, and health care providers and requires further 
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 establish standards for code sets for each data element 
for each health care transaction listed above, security standards for 
health care information systems, 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 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 24 months after enactment. The standards for claims attachments 
must be adopted within 30 months after enactment. Generally, after a 
standard is established it cannot be changed during the first year 
except for changes that are necessary to permit compliance with the 
standard. Modifications to any of these standards may be made after the 
first year, but not more frequently than once every 12 months. 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.
    Section 1175 of the Act prohibits health plans from refusing to 
process or delaying the processing of a transaction that is presented 
in standard format. The Act's requirements are not limited to health 
plans, however; instead, each person to whom a standard or 
implementation specification applies is required to comply with the 
standard within 24 months (or 36 months for small health plans) of its 
adoption. A plan or person may, of course, comply voluntarily before 
the effective date. A person may comply by using a health care 
clearinghouse to transmit or receive the standard transactions. 
Compliance with modifications to standards or implementation 
specifications must be accomplished by a date designated by the 
Secretary. This date may not be earlier than 180 days after the notice 
of change.
    Section 1176 of the Act establishes a civil monetary penalty 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 and not more than $25,000 per person per violation of a 
single standard for a calendar year. The procedural provisions in 
section 1128A of the Act, ``Civil Monetary Penalties,'' are applicable.

[[Page 25274]]

    Section 1177 of the Act establishes penalties for a knowing misuse 
of unique health identifiers and individually identifiable health 
information: (1) A fine of not more than $50,000 and/or imprisonment of 
not more than 1 year; (2) if misuse is ``under false pretenses,'' a 
fine of not more than $100,000 and/or imprisonment of not more than 5 
years; and (3) if misuse 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.
    Under section 1178 of the Act, the provisions of part C of title XI 
of the Act, as well as any standards established under them, supersede 
any State law that is contrary to them. However, the Secretary may, for 
statutorily specified reasons, waive this provision.
    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''.
    (Concerning this last provision, the conference report, in its 
discussion on section 1178, states:

    ``The conferees do not intend to exclude the activities of 
financial institutions or their contractors from compliance with the 
standards adopted under this part if such activities would be 
subject to this part. However, conferees intend that this part does 
not apply to use or disclosure of information when an individual 
utilizes a payment system to make a payment for, or related to, 
health plan premiums or health care. For example, the exchange of 
information between participants in a credit card system in 
connection with processing a credit card payment for health care 
would not be covered by this part. Similarly sending a checking 
account statement to an account holder who uses a credit or debit 
card to pay for health care services, would not be covered by this 
part. However, this part does apply if a company clears health care 
claims, the health care claims activities remain subject to the 
requirements of this part.'')

(H.R. Rep. No. 736, 104th Cong., 2nd Sess. 268-269 (1996))

B. Process for Developing National Standards

    The Secretary has formulated a 5-part strategy for developing and 
implementing the standards mandated under part C of title XI of the 
Act:
    1. To ensure necessary interagency coordination and required 
interaction with other Federal departments and the private sector, 
establish interdepartmental implementation teams to identify and assess 
potential standards for adoption. The subject matter of the teams 
includes claims/encounters, identifiers, enrollment/eligibility, 
systems security, and medical coding/classification. Another team 
addresses cross-cutting issues and coordinates the subject matter 
teams. The teams consult with external groups such as the NCVHS'' 
Workgroup on Data Standards, WEDI, ANSI's Healthcare Informatics 
Standards Board (HISB), the NUCC, the NUBC, and the ADA. The teams are 
charged with developing regulations and other necessary documents and 
making recommendations for the various standards to the HHS'' Data 
Council through its Committee on Health Data Standards. (The HHS Data 
Council is the focal point for consideration of data policy issues. It 
reports directly to the Secretary and advises the Secretary on data 
standards and privacy issues.)
    2. Develop recommendations for standards to be adopted.
    3. Publish proposed rules in the Federal Register describing the 
standards. Each proposed rule provides the public with a 60-day comment 
period.
    4. Analyze public comments and publish the final rules in the 
Federal Register.
    5. Distribute standards and coordinate preparation and distribution 
of implementation guides.
    This strategy affords many opportunities for involvement of 
interested and affected parties in standards development and adoption 
by enabling them to:
    <bullet> Participate with standards setting organizations.
    <bullet> Provide written input to the NCVHS.
    <bullet> Provide written input to the Secretary of the HHS.
    <bullet> Provide testimony at NCVHS' public meetings.
    <bullet> Comment on the proposed rules for each of the proposed 
standards.
    <bullet> Invite HHS staff to meetings with public and private 
sector organizations or meet directly with senior HHS staff involved in 
the implementation process.
    The implementation teams charged with reviewing standards for 
designation as required national standards under the statute have 
defined, with significant input from the health care industry, a set of 
principles for guiding choices for the standards to be adopted by the 
Secretary. These principles are based on direct specifications in HIPAA 
and the purpose of the law, principles that support the regulatory 
philosophy set forth in Executive Order 12866 and the Paperwork 
Reduction Act of 1995. To be designated as an HIPAA standard, each 
standard should:
    1. Improve the efficiency and effectiveness of the health care 
system by leading to cost reductions for or improvements in benefits 
from electronic health care transactions.
    2. Meet the needs of the health data standards user community, 
particularly health care providers, health plans, and health care 
clearinghouses.
    3. Be consistent and uniform with the other HIPAA standards--their 
data element definitions and codes and their privacy and security 
requirements--and, secondarily, with other private and public sector 
health data standards.
    4. Have low additional development and implementation costs 
relative to the benefits of using the standard.
    5. Be supported by an ANSI-accredited standards developing 
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.
    A master data dictionary providing for common data definitions 
across the standards selected for implementation under HIPAA will be 
developed and maintained. We intend for the data element definitions to 
be precise, unambiguous, and consistently applied. The transaction-
specific reports and general reports from the master data dictionary 
will be readily available to the public. At a minimum, the information 
presented will include data element names, definitions, and appropriate 
references to the transactions where they are used.

C. ANSI-Accredited Standards Committee Standard Setting Process

    ANSI chartered the X12 Accredited Standards Committee (ASC) a 
number of years ago to design national electronic

[[Page 25275]]

standards for a wide range of business applications. A separate ASC 
X12N Subcommittee was in turn chartered to develop electronic standards 
specific to the insurance industry, including health care insurance. 
Volunteer members of the ASC X12N Subcommittee, including health care 
providers, health plans, bankers, and vendors involved in software 
development/billing/transmission of health care data and other business 
aspects of health care administrative activities, worked to develop 
standards for electronic health care transactions. ANSI accredits 
standards setting organizations to ensure that the procedures used meet 
certain due process requirements and that the process is voluntary, 
open, and based on obtaining consensus. Both Accredited Standards 
Committee (ASC) X12 and the National Council for Prescription Drug 
Programs (NCPDP) are ANSI-accredited standards developers.
    Each of the two standards setting organizations has written 
procedures for the establishment of, and revisions to, established 
standards. All of the X12 Subcommittee N: Insurance (to which we refer 
hereafter as X12N) standard implementations mentioned in this 
regulation are ASC X12 standards and are published under the 
designation ``Draft Standard for Trial Use (DSTU)''. These standards 
are fully accepted and published national standards for use in 
electronic data exchanges. The DSTU designation is used to distinguish 
ASC X12 standards from those standards that have been forwarded to the 
American National Standards Institute for acceptance as American 
National Standards. ASC X12 creates a family of standards that are 
related and therefore only forwards standards to ANSI every five years. 
Although the official designation of X12 standards includes the word 
``Draft'', these standards are final, published national standards.
    The ASC X12 development process involves negotiation and consensus 
building, resulting in approval and publication of DSTU and American 
National Standards. The ASC X12 committee maintains current standards, 
proposes new standards and embraces new ideas.
    The ASC X12N Subcommittee is the decision-making body responsible 
for obtaining consensus, which is necessary for approval of American 
National Standards in the field of insurance. The ASC X12N Subcommittee 
has the responsibility for specific standards development and standards 
maintenance activities, but its work must be ratified by the membership 
of ASC X12 as a whole.
    Members of the ASC X12 committee are eligible to vote on ASC X12N 
issues. ASC X12N votes technical issues by letter ballot. 
Administrative issues may be voted by letter ballot or at general 
sessions during ASC X12N meetings.
    The NCPDP Telecommunication Standard 3.2 specifies the rules 
regarding the creation of a new version and release. The NCPDP 
standards development process involves additions of new data elements 
or additional values to existing data elements. Updated documentation 
of existing or new data elements and a new version is created with 
changes to: (1) The definition of an existing data element, (2) 
deletions of values of an existing data element, (3) deletions of 
existing data elements, (4) major structural changes to the formats, 
(5) changes in the size of data elements, or (6) changes in the formats 
of data elements.
    These rules were confirmed by the Board of Trustees in June, 1995 
and ensure that the health plan explicitly knows which Data Dictionary 
to apply to the transaction when processing the claim. Likewise, the 
pharmacy needs to know what are the acceptable fields in the response 
returned from the health plan.
    In addition, the Telecommunication Standard Format Version/Release 
changes anytime there is an approved change to the Professional 
Pharmacy Services (PPS) standard, Drug Utilization Review (DUR) 
standard, Billing Unit standard or to the data elements for the claim 
itself.
    All NCPDP implementation guides must be reviewed and approved by 
the Maintenance and Control Work Group prior to release to the 
membership. All proposed standards will have an implementation guide 
developed and approved prior to the proposed standard being balloted. 
Once balloted, the originating committee may work with individual 
disapproval votes to accommodate their concerns and convert their votes 
to approval. If the changes made to accommodate disapproval votes are 
considered substantial, then the item under consideration must be 
balloted again.
    After the originating group has reviewed all comments received 
during the letter ballot period, the Co-Chairs of the originating group 
make a written request to the Board of Trustees for the ballot results 
collected from the Standardization Co-chairs and the Board of 
Directors. The Board of Trustees retains final authority over the 
certification of these ballot results.
    Two types of code sets are required for data elements in ASC X12N 
and NCPDP health transaction standards: (1) Large coding and 
classification systems for medical data elements (for example, 
diagnoses, procedures, and drugs), and (2) smaller sets of codes for 
data elements such as type of facility, type of units, and specified 
State within address fields. Federal agencies (NCHS, HCFA, FDA) and 
some private organizations (the AMA and the ADA) have developed and 
maintained standards for large medical data code sets. In the past, 
these code sets have been mandated for use in some Federal and State 
programs, such as Medicare and Medicaid, and the ASC X12N and NCPDP 
standards setting organizations have adopted these code sets for use in 
their standards. For the smaller sets of codes needed for various 
transaction data elements they have designated other de facto 
standards, such as the 2-character state abbreviations used by the U.S. 
Postal Service, or developed code sets specifically for their 
transaction standards.
    This proposed rule would establish the standards for code sets to 
be used in seven of the transactions specified in section 1173(a)(2) of 
the Act, and for a transaction for coordination of benefits. We 
anticipate publishing several regulations documents altogether to 
promulgate the various standards required under the HIPAA. The other 
proposed regulations cover security standards, the seventh and ninth 
transactions specified in the Act (first report of injury and claims 
attachments), and the four identifiers.

II. Provisions of the Proposed Regulations

[Please label written comments or e-mailed comments about this 
section with the subject: Provisions]

    In this proposed rule, we propose standards for eight transactions 
and for code sets to be used in the transactions. We also propose 
requirements concerning the implementation of these standards. This 
proposed rule would 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 propose to add a new part to title 45 of the Code of Federal 
Regulations for health plans, health care providers, and health care 
clearinghouses in general. The new part would be part 142 of title 45 
and would be titled ``Administrative Requirements.'' Subparts J through 
R would contain the provisions specifically concerning the standards 
proposed in this rule.

[[Page 25276]]

A. Applicability

    Section 262 of HIPAA applies to all health plans, all health care 
clearinghouses, and any health care providers that transmit any health 
information in electronic form in connection with transactions referred 
to in section 1173(a)(1) of the Act. Our proposed rules (at 45 CFR 
142.102) would apply to the health plans and health care clearinghouses 
as well, but we would clarify the statutory language in our regulations 
for health care providers: we would have the regulations apply to any 
health care provider only when electronically transmitting any of the 
transactions to which section 1173(a)(1) of the Act refers.
    Electronic transmissions would include transmissions using all 
media, even when the transmission is physically moved from one location 
to another using magnetic tape, disk, or CD media. Transmissions over 
the Internet (wide-open), Extranet (using Internet technology to link a 
business with information only accessible to collaborating parties), 
leased lines, dial-up lines, and private networks are all included. 
Telephone voice response and ``faxback'' systems would not be included.
    Our regulations would apply to health care clearinghouses when 
transmitting transactions to, and receiving transactions from, any 
health care provider or health plan that transmits and receives 
standard transactions (as defined under ``transaction'') and at all 
times when transmitting to or receiving transactions from another 
health care clearinghouse.
    Entities that offer on-line interactive transmission must comply 
with the standards. 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.
    The law would apply to each health care provider when transmitting 
or receiving any of the specified electronic transactions. 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 proposed in this rule. 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.
    We invite comments on this list and ask for identification of other 
types of services that may fall into this category. We will publish a 
complete list of these services and a process to request an exemption 
in the final rule.
    The law applies to health plans for all transactions.
    Section 142.104 would contain the following provisions (from 
section 1175 of the Act):
    If a person conducts a transaction (as defined in Sec. 142.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.
    (3) The information transmitted and received in connection with the 
transaction must be in the form of standard data elements of health 
information.
    As a further requirement, we would provide that a health plan that 
conducts transactions through an agent assure that the agent meets all 
the requirements of part 142 that apply to the health plan.
    Section 142.105 would state that a person or other entity may meet 
the requirements of Sec. 142.104 by either--
    (1) Transmitting and receiving standard data elements, or
    (2) Submitting nonstandard data elements to a health care 
clearinghouse for processing into standard data elements and 
transmission by the health care clearinghouse and receiving standard 
data elements through the health care clearinghouse.
    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. We would state in Sec. 142.105 that the transmission of 
nonstandard transactions, under contract, between a health plan or a 
health care provider and a health care clearinghouse would not violate 
the law.
    Transmissions within a corporate entity would not be required to 
comply with the standards. A hospital that is wholly owned by a managed 
care company would not have to use the standards to pass encounter 
information back to the home office, but it would have to use the 
standard claims transaction to submit a claim to another health plan. 
Another example might be transactions within Federal agencies and their 
contractors and between State agencies within the same State. For 
example, Medicare enters into contracts with insurance companies and 
common working file sites that process Medicare claims using government 
furnished software. There is constant communication, on a private 
network, between HCFA Central Office and the Medicare carriers, 
intermediaries and common working file sites. This communication may 
continue in nonstandard mode. However, these contractors must comply 
with the standards when exchanging any of the transactions covered by 
HIPAA with an entity outside these ``corporate'' boundaries.
    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 are not required to use any of the standard 
transactions), we stress that a standard may be used voluntarily in any 
situation in which it is not required.

B. Definitions

    Section 1171 of the Act defines several terms and our proposed 
rules would, for the most part, simply restate the law. The terms that 
we are defining in this proposed rule follow:
    1. ASC X12 stands for the Accredited Standards Committee chartered 
by the American National Standards Institute to design national 
electronic standards for a wide range of business applications.
    2. ASC X12N stands for the ASC X12 subcommittee chartered to 
develop electronic standards specific to the insurance industry.
    3. Code set.
    We would define ``code set'' as section 1171(1) of the Act does: 
``code set'' means any set of codes used for encoding data elements, 
such as tables of terms, medical concepts, medical diagnosis codes, or 
medical procedure codes.
    4. Health care clearinghouse.
    We would define ``health care clearinghouse'' as section 1171(2) of 
the Act does, but we are adding a further, clarifying sentence. The 
statute defines a ``health care clearinghouse'' as a public or private 
entity that processes or facilitates the processing of nonstandard data 
elements of health information into standard data elements. We would

[[Page 25277]]

further explain that such an entity is one that currently receives 
health care transactions from health care providers and other entities, 
translates the data from a given format into one acceptable to the 
intended recipient, and forwards the processed transaction to 
appropriate health plans and other health care clearinghouses, as 
necessary, for further action.
    There are currently a number of private clearinghouses that perform 
these functions for health care providers. For purposes of this rule, 
we would consider billing services, repricing companies, community 
health management information systems or community health information 
systems, value-added networks, and switches performing these functions 
to be health care clearinghouses.
    5. Health care provider.
    As defined by section 1171(3) of the Act, a ``health care 
provider'' is a provider of services as defined in section 1861(u) of 
the Act, a provider of medical or other health services as defined in 
section 1861(s) of the Act, and any other person who furnishes health 
care services or supplies. Our regulations would define ``health care 
provider'' as the statute does and clarify that the definition of a 
health care provider is limited to those entities that furnish, or bill 
and are paid for, health care services in the normal course of 
business.
    For a more detailed discussion of the definition of health care 
provider, we refer the reader to our proposed rule, HCFA-0045-P, 
Standard Health Care Provider Identifier, published elsewhere in this 
Federal Register.
    6. Health information.
    ``Health information,'' as defined in section 1171 of the Act, 
means any information, whether oral or recorded in any form or medium, 
that--
    <bullet> 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
    <bullet> 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.
    We propose the same definition for our regulations.
    7. Health plan.
    We propose that a ``health plan'' be defined essentially as section 
1171 of the Act defines it. Section 1171 of the Act cross refers to 
definitions in section 2791 of the Public Health Service Act (as added 
by Public Law 104-191, 42 U.S.C. 300gg-91); we would incorporate those 
definitions as currently stated into our proposed definitions for the 
convenience of the public. We note that many of these terms are defined 
in other statutes, such as the Employee Retirement Income Security Act 
of 1974 (ERISA), Public Law 93-406, 29 U.S.C. 1002(7) and the Public 
Health Service Act. Our definitions are based on the roles of plans in 
conducting administrative transactions, and any differences should not 
be construed to affect other statutes.
    For purposes of implementing the provisions of administrative 
simplification, a ``health plan'' would be an individual or group 
health plan that provides, or pays the cost of, medical care. This 
definition includes, but is not limited to, the 13 types of plans 
listed in the statute. On the other hand, plans such as property and 
casualty insurance plans and workers compensation plans, which may pay 
health care costs in the course of administering nonhealth care 
benefits, are not considered to be health plans in the proposed 
definition of health plan. Of course, these plans may voluntarily adopt 
these standards for their own business needs. At some future time, the 
Congress may choose to expressly include some or all of these plans in 
the list of health plans that must comply with the standards.
    Health plans often carry out their business functions through 
agents, such as plan administrators (including third party 
administrators), entities that are under ``administrative services 
only'' (ASO) contracts, claims processors, and fiscal agents. These 
agents may or may not be health plans in their own right; for example, 
a health plan may act as another health plan's agent as another line of 
business. As stated earlier, a health plan that conducts HIPAA 
transactions through an agent is required to assure that the agent 
meets all HIPAA requirements that apply to the plan itself.
    ``Health plan'' includes the following, singly or in combination:
    a. ``Group health plan'' (as currently defined by section 2791(a) 
of the Public Health Service Act). A group health plan is a plan that 
has 50 or more participants (as the term ``participant'' is currently 
defined by section 3(7) of ERISA) or is administered by an entity other 
than the employer that established and maintains the plan. This 
definition includes both insured and self-insured plans. We define 
``participant'' separately below.
    Section 2791(a)(1) of the Public Health Service Act defines ``group 
health plan'' as an employee welfare benefit plan (as currently defined 
in section 3(1) of ERISA) to the extent that the plan provides medical 
care, including items and services paid for as medical care, to 
employees or their dependents directly or through insurance, or 
otherwise.
    It should be noted that group health plans that have fewer than 50 
participants and that are administered by the employer would be 
excluded from this definition and would not be subject to the 
administrative simplification provisions of HIPAA.
    b. ``Health insurance issuer'' (as currently defined by section 
2791(b) of the Public Health Service Act).
    Section 2791(b)(2) of the Public Health Service Act currently 
defines a ``health insurance issuer'' as an insurance company, 
insurance service, or insurance organization that is licensed to engage 
in the business of insurance in a State and is subject to State law 
that regulates insurance.
    c. ``Health maintenance organization'' (as currently defined by 
section 2791(b) of the Public Health Service Act).
    Section 2791(b) of the Public Health Service Act currently defines 
a ``health maintenance organization'' as a Federally qualified health 
maintenance organization, an organization recognized as such under 
State law, or a similar organization regulated for solvency under State 
law in the same manner and to the same extent as such a health 
maintenance organization. These organizations may include preferred 
provider organizations, provider sponsored organizations, independent 
practice associations, competitive medical plans, exclusive provider 
organizations, and foundations for medical care.
    d. Part A or Part B of the Medicare program (title XVIII of the 
Act).
    e. The Medicaid program (title XIX of the Act).
    f. A ``Medicare supplemental policy'' as defined under section 
1882(g)(1) of the Act.
    Section 1882(g)(1) of the Act defines a ``Medicare supplemental 
policy'' as a health insurance policy that a private entity offers a 
Medicare beneficiary to provide payment for expenses incurred for 
services and items that are not reimbursed by Medicare because of 
deductible, coinsurance, or other limitations under Medicare. The 
statutory definition of a Medicare supplemental policy excludes a 
number of plans that are generally considered to be Medicare 
supplemental plans, such as health plans for employees and former 
employees and for members and former members of trade associations and 
unions. A number of these health plans may be included under the

[[Page 25278]]

definitions of ``group health plan'' or ``health insurance issuer'', as 
defined in a. and b. above.
    g. A ``long-term care policy,'' including a nursing home fixed-
indemnity policy. A ``long-term care policy'' is considered to be a 
health plan regardless of how comprehensive it is. We recognize the 
long-term care insurance segment of the industry is largely unautomated 
and we welcome comments regarding the impact of HIPAA on the long-term 
care segment.
    h. 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. This 
includes plans and other arrangements that are referred to as multiple 
employer welfare arrangements (``MEWAs'') as defined in section 3(40) 
of ERISA.
    i. The health care program for active military personnel under 
title 10 of the United States Code.
    j. The veterans health care program under chapter 17 of title 38 of 
the United States Code.
    This health plan primarily furnishes medical care through hospitals 
and clinics administered by the Department of Veterans Affairs for 
veterans with a service-connected disability that is compensable. 
Veterans with non-service-connected disabilities (and no other health 
benefit plan) may receive health care under this health plan to the 
extent resources and facilities are available.
    k. The Civilian Health and Medical Program of the Uniformed 
Services (CHAMPUS), as defined in 10 U.S.C. 1072(4).
    CHAMPUS primarily covers services furnished by civilian medical 
providers to dependents of active duty members of the uniformed 
services and retirees and their dependents under age 65.
    l. The Indian Health Service program under the Indian Health Care 
Improvement Act (25 U.S.C. 1601 et seq.).
    This program furnishes services, generally through its own health 
care providers, primarily to persons who are eligible to receive 
services because they are of American Indian or Alaskan Native descent.
    m. The Federal Employees Health Benefits Program under 5 U.S.C. 
chapter 89.
    This program consists of health insurance plans offered to active 
and retired Federal employees and their dependents. Depending on the 
health plan, the services may be furnished on a fee-for-service basis 
or through a health maintenance organization.

    Note: Although section 1171(5)(M) of the Act refers to the 
``Federal Employees Health Benefit Plan,'' this and any other rules 
adopting administrative simplification standards will use the 
correct name, the Federal Employees Health Benefits Program. One 
health plan does not cover all Federal employees; there are over 350 
health plans that provide health benefits coverage to Federal 
employees, retirees, and their eligible family members. Therefore, 
we will use the correct name, the Federal Employees Health Benefits 
Program, to make clear that the administrative simplification 
standards apply to all health plans that participate in the Program.

    n. Any other individual or group health plan, or combination 
thereof, that provides or pays for the cost of medical care.
    We would include a fourteenth category of health plan in addition 
to those specifically named in HIPAA, as there are health plans that do 
not readily fit into the other categories but whose major purpose is 
providing health benefits. The Secretary would determine which of these 
plans are health plans for purposes of title II of HIPAA. This category 
would include the Medicare Plus Choice plans that will become available 
as a result of section 1855 of the Act as amended by section 4001 of 
the Balanced Budget Act of 1997 (Pub. L. 105-33) to the extent that 
these health plans do not fall under any other category.
    8. Medical care.
    ``Medical care,'' which is used in the definition of health plan, 
would be defined as current section 2791 of the Public Health Service 
Act defines it: the diagnosis, cure, mitigation, treatment, or 
prevention of disease, or amounts paid for the purpose of affecting any 
body structure or function of the body; amounts paid for transportation 
primarily for and essential to these items; and amounts paid for 
insurance covering the items and the transportation specified in this 
definition.
    9. Participant.
    We would define the term ``participant'' as section 3(7) of ERISA 
currently defines it: a ``participant'' is any employee or former 
employee of an employer, or any member or former member of an employee 
organization, who is or may become eligible to receive a benefit of any 
type from an employee benefit plan that covers employees of such an 
employer or members of such organizations, or whose beneficiaries may 
be eligible to receive any such benefits. An ``employee'' would include 
an individual who is treated as an employee under section 401(c)(1) of 
the Internal Revenue Code of 1986 (26 U.S.C. 401(c)(1)).
    10. Small health plan.
    We would define a ``small health plan'' as a group health plan with 
fewer than 50 participants.
    The HIPAA does not define a ``small health plan'' but instead 
leaves the definition to be determined by the Secretary. The Conference 
Report suggests that the appropriate definition of a ``small health 
plan'' is found in current section 2791(a) of the Public Health Service 
Act, which is a group health plan with fewer than 50 participants. We 
would also define small individual health plans as those with fewer 
than 50 participants.
    11. Standard.
    Section 1171 of the Act defines ``standard,'' when used with 
reference to a data element of health information or a transaction 
referred to in section 1173(a)(1) of the Act, as any such data element 
or transaction that meets each of the standards and implementation 
specifications adopted or established by the Secretary with respect to 
the data element or transaction under sections 1172 through 1174 of the 
Act.
    Under our definition, a standard would be a set of rules for a set 
of codes, data elements, transactions, or identifiers promulgated 
either by an organization accredited by ANSI or the HHS for the 
electronic transmission of health information.
    12. Transaction.
    ``Transaction'' would mean the exchange of information between two 
parties to carry out financial and administrative activities related to 
health care. A transaction would be (a) any of the transactions listed 
in section 1173(a)(2) of the Act and (b) any determined appropriate by 
the Secretary in accordance with section 1173(a)(1)(B) of the Act. We 
present them below in the order in which we propose standards for them 
in the regulations text.
    A ``transaction'' would mean any of the following:
    a. Health claims or equivalent encounter information.
    This transaction may be used to submit health care claim billing 
information, encounter information, or both, from health care providers 
to health plans, either directly or via intermediary billers and claims 
clearinghouses.
    b. Health care payment and remittance advice.
    This transaction may be used by a health plan to make a payment to 
a financial institution for a health care provider (sending payment 
only), to send an explanation of benefits or a remittance advice 
directly to a health care provider (sending data only), or to

[[Page 25279]]

make payment and send an explanation of benefits remittance advice to a 
health care provider via a financial institution (sending both payment 
and data).
    c. Coordination of benefits.
    This transaction can be used to transmit health care claims and 
billing payment information between health plans with different payment 
responsibilities where coordination of benefits is required or between 
health plans and regulatory agencies to monitor the rendering, billing, 
and/or payment of health care services within a specific health care/
insurance industry segment.
    In addition to the nine electronic transactions specified in 
section 1173(a)(2) of the Act, section 1173(f) directs the Secretary to 
adopt standards for transferring standard data elements among health 
plans for coordination of benefits and sequential processing of claims. 
This particular provision does not state that there should be standards 
for electronic transfer of standard data elements among health plans. 
However, we believe that the Congress, when writing this provision, 
intended for these standards to apply to the electronic form for 
coordination of benefits and sequential processing of claims. The 
Congress expressed its intent on these matters generally in section 
1173(a)(1)(B), where the Secretary is directed to adopt ``other 
financial and administrative transactions * * * consistent with the 
goals of improving the operation of the health care system and reducing 
administrative costs.''
    d. Health claim status.
    This transaction may be used by health care providers and 
recipients of health care products or services (or their authorized 
agents) to request the status of a health care claim or encounter from 
a health plan.
    e. Enrollment and disenrollment in a health plan.
    This transaction may be used to establish communication between the 
sponsor of a health benefit and the health plan. It provides enrollment 
data, such as subscriber and dependents, employer information, and 
health care provider information. The sponsor is the backer of the 
coverage, benefit or product. A sponsor can be an employer, union, 
government agency, association, or insurance company. The health plan 
refers to an entity that pays claims, administers the insurance product 
or benefit, or both.
    f. Eligibility for a health plan.
    This transaction may be used to inquire about the eligibility, 
coverage, or benefits associated with a benefit plan, employer, plan 
sponsor, subscriber, or a dependent under the subscriber's policy. It 
also can be used to communicate information about or changes to 
eligibility, coverage, or benefits from information sources (such as 
insurers, sponsors, and health plans) to information receivers (such as 
physicians, hospitals, third party administrators, and government 
agencies).
    g. Health plan premium payments.
    This transaction may be used by, for example, employers, employees, 
unions, and associations to make and keep track of payments of health 
plan premiums to their health insurers.
    h. Referral certification and authorization.
    This transaction may be used to transmit health care service 
referral information between health care providers, health care 
providers furnishing services, and health plans. It can also be used to 
obtain authorization for certain health care services from a health 
plan.
    i. First report of injury.
    This transaction may be used to report information pertaining to an 
injury, illness, or incident to entities interested in the information 
for statistical, legal, claims, and risk management processing 
requirements. Although we are proposing a definition for this 
transaction, we are not proposing a standard for it in this Federal 
Register document. (See section E.9 for a more in-depth discussion.) We 
will publish a separate proposed rule for it.
    j. Health claims attachments.
    This transaction may be used to transmit health care service 
information, such as subscriber, patient, demographic, diagnosis, or 
treatment data for the purpose of a request for review, certification, 
notification, or reporting the outcome of a health care services 
review. Although we are proposing a definition for this transaction, we 
are not proposing a standard for it in this Federal Register document 
because the legislation gave the Secretary an additional year to 
designate this standard. We will publish a separate proposed rule for 
it.
    k. Other transactions as the Secretary may prescribe by regulation.
    Under section 1173(a)(1)(B) of the Act, the Secretary shall adopt 
standards, and data elements for those standards, for other financial 
and administrative transactions deemed appropriate by the Secretary. 
These transactions would be consistent with the goals of improving the 
operation of the health care system and reducing administrative costs.

C. Effective Dates--General

    Health plans would be required by Part 142 to comply with our 
requirements as follows:
    1. Each health plan that is not a small health plan would have to 
comply with the requirements of Part 142 no later than 24 months after 
the effective date of the final rule.
    2. Each small health plan would have to comply with the 
requirements of Part 142 no later than 36 months after the effective 
date of the final rule.
    Health care providers and health care clearinghouses would be 
required to begin using the standard by 24 months after the effective 
date of the final rule.
    (The effective date of the final rule will be 60 days after the 
final rule is published in the Federal Register.)
    Provisions of trading partner agreements that stipulate data 
content, format definitions or conditions that conflict with the 
adopted standard would be invalid beginning 36 months from the 
effective date of the final rule for small health plans, and 24 months 
from the effective date of the final rule for all other health plans.
    If HHS adopts a modification to an implementation specification or 
a standard, the implementation date of the modification would be no 
earlier than the 180th day following the adoption of the modification. 
HHS would determine the actual date, taking into account the time 
needed to comply due to the nature and extent of the modification. HHS 
would be able to extend the time for compliance for small health plans. 
This provision would be at Sec. 142.106.
    The law does not address scheduling of implementation of the 
standards; it gives only a date by which all concerned must comply. As 
a result, any of the health plans, health care clearinghouses, and 
health care providers may implement a given standard earlier than the 
date specified in the subpart created for that standard. We realize 
that this may create some problems temporarily, as early implementers 
would have to be able to continue using old standards until the new 
ones must, by law, be in place.
    At the WEDI Healthcare Leadership Summit held on August 15, 1997, 
it was recommended that health care providers not be required to use 
any of the standards during the first year after the adoption of the 
standard. However, willing trading partners could implement any or all 
of the standards by mutual agreement at any time during the 2-year 
implementation phase (3-year implementation phase for small health 
plans). In addition, it was recommended

[[Page 25280]]

that a health plan give its health care providers at least 6 months 
notice before requiring them to use a given standard.
    We welcome comments specifically on early implementation as to the 
extent to which it would cause problems and how any problems might be 
alleviated.

D. Data Content

[Please label any written comments or e-mailed comments about this 
section with the subject: Data Content]

    We propose standard data content for each adopted standard. There 
are two aspects of data content standardization: (1) Standardization of 
data elements, including their formats and definition, and (2) 
standardization of the code sets or values that can appear in selected 
data elements. A telephone number is an example of a data element that 
has a standard definition and format, but does not have an enumerated 
set of valid codes or values. A patient's diagnosis is an example of a 
data element that has a standard definition, a standard format, and a 
set of valid codes. Information that would facilitate data content 
standardization, while also facilitating identical implementations, 
would consist of implementation guides, data conditions, and data 
dictionaries, as noted in the addenda to this proposed rule, 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 record/segment can be used. For example, ``the name of the 
tribe'' applies only to Indian Health Service claims. The defining rule 
for that data element would be ``must be entered if claim is Indian 
Health Service''.
1. Data Element and Record/Segment Content
    Once we publish the final rule in the Federal Register and it is 
effective, there will be no additional data element or record/segment 
content modifications in any of the transactions for at least one year.
    In our evaluation and recommendation for each proposed standard 
transaction, we have tried to meet as many business needs as possible 
while retaining our commitment to the guiding principles. We encourage 
comments on how the standards may be improved.
    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 data sets defined in the final rule, until that rule is 
amended one or more years from the effective date of the final rule. 
This means that if a transaction has all of the data possible--based on 
the appropriate implementation guide, data content and data conditions 
specifications, and data dictionary--then a health plan would have to 
accept the transaction and process it. This does not mean, however, 
that the health plan would have to store or use information that it 
does not need in order to process a claim or encounter, except for 
audit trail purposes or for coordination of benefits if applicable. It 
does mean that the health plan would not be able to require additional 
information, and it does mean that the health plan would not be able to 
reject a transaction because it contains information the health plan 
does not want. This principle applies to the data elements of all 
transactions proposed for adoption in this proposed rule.
2. Code Sets
[Please label any written comments or e-mailed comments about this 
section with the subject: Code Sets]
a. Background
    The administrative simplification provisions of HIPAA require the 
Secretary of HHS to adopt standards for code sets for administrative 
and financial transactions. Two types of code sets are required for 
data elements in the transaction standards to be established under 
HIPAA: (1) Large code sets for medical data, including coding systems 
for:
    <bullet> Diseases, injuries, impairments, other health related 
problems, and their manifestations;
    <bullet> Causes of injury, disease, impairment, or other health-
related problems;
    <bullet> Actions taken to prevent, diagnose, treat, or manage 
diseases, injuries, and impairments and any substances, equipment, 
supplies, or other items used to perform these actions; and (2) smaller 
sets of codes for other data elements such as race/ethnicity, type of 
facility, and type of unit.
    A separate HIPAA implementation team co-chaired by representatives 
from HCFA, the Centers for Disease Control/National Center for Health 
Statistics, and the National Institutes of Health/National Library of 
Medicine, and including members from other interested HHS agencies and 
Federal Departments, was established to recommend the code sets that 
should become HIPAA standards for medical data. HHS efforts to identify 
candidate medical data code sets were coordinated with the NCVHS 
Subcommittee on Health Data Needs, Standards, and Security. The smaller 
sets of codes for other data elements in transactions standards are 
part of the transaction standards themselves and are specified in their 
implementation guides.
    The following medical data code sets are already in use in 
administrative and financial transactions:
    ICD-9-CM: The International Classification of Diseases, Ninth 
Revision, Clinical Modification, classifies both diagnoses (Volumes 1 
and 2) and procedures (Volume 3). All hospitals and ambulatory care 
settings use it to capture diagnoses for administrative transactions. 
The procedure system is used for all in-patient procedure coding for 
administrative transactions. The ICD-9-CM was adopted for use in 
January 1979.
    The ICD-9-CM Coordination and Maintenance Committee is a Federal 
interdepartmental committee charged with maintaining and updating the 
ICD-9-CM. Requests for modification are handled through the ICD-9-CM 
Coordination and Maintenance Committee; no official changes are made 
without being brought before this committee. Suggestions for 
modifications come from both the public and private sectors and 
interested parties are asked to submit recommendations for modification 
prior to a scheduled meeting.
    Modifications are not considered without the expert advice of 
clinicians, epidemiologists, and nosologists (both public and private 
sectors). The meetings are open to the public and are announced in the 
Federal Register; all interested members of the public are invited to 
attend and submit written comments. Meetings are held twice each year.
    Approved modifications become effective October 1 of the following 
year. Changes to ICD-9-CM are published on the NCHS and HCFA websites, 
as well as by the American Hospital Association (AHA) and other private 
sector vendors.
    CPT: Physicians' Current Procedural Terminology is used by 
physicians and other health care professionals to code their services 
for administrative transactions. CPT is level one of the Health Care 
Financing Administration Procedure Coding System (HCPCS).
    CPT codes are updated annually by the AMA. The CPT Panel is 
comprised of 15 physicians, 10 nominated by the AMA and one each 
nominated by Blue Cross/Blue Shield of America (BCBSA), HIAA, HCFA, and 
AHA. Meetings are not open to the public.
    Alpha-numeric HCPCS: Alpha-numeric Health Care Financing 
Administration Procedure Coding System (HCPCS) contains codes for 
medical equipment and supplies;

[[Page 25281]]

prosthetics and orthotics; injectable drugs; transportation services; 
and other services not found in CPT. Alpha-numeric codes are level 2 of 
HCPCS. Its use is generally limited to ambulatory settings. The Omnibus 
Budget Reconciliation Act of 1986 requires the use of HCPCS in the 
Medicare program for services in hospital outpatient departments.
    Level II of HCPCS is updated annually and is maintained jointly by 
the BCBSA, the Health Insurance Association of America and HCFA.
    HCFA's regional offices assure coordination of local code 
assignments among the payers in a State; local codes must be approved 
by HCFA's central office to assure they do not duplicate national codes 
in CPT or Level II of HCPCS.
    Decisions regarding additions, deletions and revisions to Level II 
of HCPCS are made by the Alpha-Numeric Editorial Panel. This Panel, 
which meets three times a year, is comprised of representatives of the 
BCBSA, HIAA, and HCFA; the meetings are not open to the public. There 
are formal mechanisms to coordinate this Panel's activities with CPT 
and the American Dental Association's (ADA) procedure coding system.
    The revised HCPCS is available free of charge as a public use file.
    CDT: Current Dental Terminology is used in reporting dental 
services. CDT codes are also included in alpha-numeric HCPCS with a 
first character of D.
    Codes are revised on a five-year cycle by the ADA through its 
Council on Dental Benefits Program. Meetings are not open to the 
public.
    NDC: National Drug Codes are used in reporting prescription drugs 
in pharmacy transactions and some claims by health care professionals. 
The codes are assigned when the drugs are approved or repackaged and 
may be found on the packaging of drugs.
i. Candidates for the Standards
    The principal sources of input to the recommendations for medical 
data code sets were:
    (a) The ANSI HISB Standards Inventory.
    The inventoried code sets are:
    ICD-9-CM, which consists of both diagnoses and procedure sections. 
The diagnosis system is widely used in the health care industry. All 
hospitals and ambulatory care settings use it to capture diagnoses. The 
procedure system is used for all in patient procedure coding.
    ICD-10-CM for diagnosis, which is under development as a 
replacement to the diagnosis section of ICD-9-CM and not yet in use in 
this country. ICD-10 was developed by the World Health Organization and 
has been implemented in approximately 37 countries to report mortality 
data. These are data that are taken and coded from death certificates. 
However, since our country's need for morbidity data cannot be 
satisfied by ICD-10, the United States is preparing a clinical 
modification of ICD-10 (ICD-10-CM). The public has been given an 
opportunity to review and comment on the current draft of ICD-10-CM. 
The final draft should be available in the summer of 1998.
    <bullet> ICD-10-PCS for procedures, which is under development for 
use in the U.S. only as a replacement to the procedure section of ICD-
9-CM.
    <bullet> CPT, which is used by all physicians and many other 
practitioners to code their services. It is also used by hospital 
outpatient departments to code certain ambulatory services.
    <bullet> SNOMED (Systematized Nomenclature of Medicine), which is 
being used by the developers of computer-based patient record systems. 
It is not used in administrative transactions.
    <bullet> CDT, which is used by all practicing dentists to code 
their services for administrative transactions.
    <bullet> NIC (Nursing Interventions Classification), which is not 
used in administrative transactions in this country.
    <bullet> LOINC (Logical Observation Identifier Names and Codes), 
which is being used in a pilot-test by the Centers for Disease Control 
to report tests as evidence of a communicable disease. It is also being 
tested in electronic transactions involving detailed clinical 
laboratory tests and results. It is not used in administrative 
transactions.
    <bullet> HHCC (Home Health Care Classification system), which is 
not being used as a reporting system in this country.
    (b) A more extensive inventory of existing coding and 
classification systems prepared by the coding and classification 
implementation team itself and evaluated against the general HIPAA 
standards evaluation criteria (as found in section I.B., Process for 
developing standards for this proposed rule).
    This larger inventory (which will be placed on the home page of the 
National Center for Health Statistics at: <a href="http://www.cdc.gov/nchswww/
nchshome.htm">http://www.cdc.gov/nchswww/
nchshome.htm</a>) does not include any additional viable candidates for the 
initial standards for administrative code sets to be established under 
this proposed rule. It does contain some additional systems that may be 
applicable to elements of the claims attachments standard (to be issued 
on a later timetable) and to eventual HIPAA recommendations to the 
Congress regarding full electronic medical records.
    (c) The oral and written testimony submitted at an NCVHS public 
hearing to discuss medical/clinical coding and classification issues in 
connection with the requirements of HIPAA on April 15-16, 1997. The 
following entities presented testimony at the hearing: AMA, AHA, 
American Health Information Management Association, American College of 
Obstetricians and Gynecologists, American Academy of Pediatrics, 
American Nurses Association, National Association for Home Care, ADA, 
Family Practice Primary Care Work Group, National Association of 
Children's Hospitals and Related Institutions, Food and Drug 
Administration, College of American Pathologists, the Omaha System, 
developers of new nomenclature systems, research groups, publishers, 
consultants in coding, managed care organizations, software vendors, 
and informatics specialists.
    (d) The NCVHS' recommendations to the Secretary, HHS regarding 
codes and classifications.
    (e) Comments received in response to presentations at professional 
meetings and at the July 9, 1997, public meeting held by HHS on 
progress on selecting the initial HIPAA standards.
    For the hearing on April 15-16, 1997, the NCVHS invited interested 
organizations representing both the users and developers of medical/
clinical classification systems to present written and/or oral 
testimony responding to the following questions.

``--What medical/clinical codes and classifications do you use in 
administrative transactions now? What do you perceive as the main 
strengths and weaknesses of current methods for coding and 
classification of encounter and/or enrollment data?
``--What medical/clinical codes and classifications do you recommend 
as initial standards for administrative transactions, given the time 
frames in the HIPAA? What specific suggestions would you like to see 
implemented regarding coding and classification?
``--Prior to the passage of HIPAA, the National Center for Health 
Statistics initiated development of a clinical modification of the 
International Classification of Diseases-10 (ICD-10-CM), and HCFA 
undertook development of a new procedure coding system for inpatient 
procedures (called ICD-10-PCS), with a plan to implement them 
simultaneously in the year 2000. On the pre-HIPAA schedule, they 
will be released to the field for

[[Page 25282]]

evaluation and testing by 1998. If some version of ICD is to be used 
for administrative transactions, do you think it should be ICD-9-CM 
or ICD-10-CM and ICD-10-PCS, assuming that field evaluations are 
generally positive?
``--Recognizing that the goal of P.L. 104-191 is administrative 
simplification, how, from your perspective, would you deal with the 
current coding environment to improve simplification, reduce 
administrative burden, but also obtain medically meaningful 
information?
``--How should the ongoing maintenance of medical/clinical code sets 
and the responsibility, intellectual input and funding for 
maintenance be addressed for the classification systems included in 
the standards? What are the arguments for having these systems in 
the public domain versus in the private sector, with or without 
copyright?
``--What would be the resource implications of changing from the 
coding and classification systems that you currently are using in 
administrative transactions to other systems? How do you weigh the 
costs and benefits of making such changes?
``--A Coding and Classification Implementation Team has been 
established within the Department of Health and Human Services to 
address the requirements of P.L. 104-191; the Team's charge is 
enclosed. Does your organization have any concerns about the process 
being undertaken by the Department to carry out the requirements of 
the law in regard to coding and classification issues? If so, what 
are those concerns and what suggestions do you have for 
improvements?''

    In general, those testifying at the April 15-16 hearing recommended 
that systems currently in use be designated as standards for the year 
2000, since potential replacements were not yet fully tested and could 
not be implemented throughout the health care system by 2000. Testimony 
supported moving to ICD-10-CM for medical diagnoses after the year 2000 
(different timetables were mentioned). Testimony provided by 
representatives from the American Psychiatric Association described the 
ongoing efforts to make the Diagnostic and Statistical Manual of Mental 
and Behavioral Disorders (DSM) completely compatible with ICD. The 
American Psychiatric Association has crosswalked the appropriate ICD-9-
CM codes to what appear in the DSM for its diagnostic categories and is 
doing the same for ICD-10-CM for diagnosis. The mapping between DSM and 
ICD-10-CM for diagnosis is more precise than is possible for ICD-9-CM 
so the APA favors moving to ICD-10-CM for diagnosis as soon as 
possible.
    Many of those testifying emphasized the need to change to a less 
fragmented, overlapping, and duplicative approach to procedure coding, 
but sometime after the year 2000. Different potential approaches to 
achieving a more integrated procedure coding system were mentioned. 
Many identified current variations in the implementation of coding 
systems and the use of local HCPCS codes as problems that should be 
addressed.
    In general, those testifying approved the implementation team's 
charge, which includes an initial focus on the administrative standards 
for the year 2000 and longer term attention to recommendations for the 
more clinically-detailed vocabulary needed for full electronic medical 
records. Some of the developers of vocabularies and classifications who 
presented testimony emphasized the potential usefulness of their 
systems for full computer-based patient records, rather than for the 
administrative transactions that are the focus of the initial HIPAA 
standards.
    Comments on codes and classifications sets made at the June 3-4, 
1997, Health Data Needs, Standards and Security Subcommittee hearings 
in San Francisco, California echoed those heard at the April hearing.
    On June 25, 1997, the NCVHS submitted the following recommendations 
to the Secretary of HHS regarding standards for codes and 
classifications for administrative transactions:
    The Committee recommends that diagnosis and procedure coding 
continue to use the current code sets because replacements will not 
be ready for implementation by the year 2000. ICD-9-CM diagnosis 
codes, ICD-9-CM Volume 3 procedure codes, and HCPCS (including 
Current Procedural Terminology (CPT) and Current Dental Terminology 
(CDT)) procedure codes should be adopted as the standards to be 
implemented by the year 2000. Annual updates to ICD-9-CM and HCPCS 
should continue to follow the schedule currently used. In addition, 
we recommend that you advise industry to build and modify their 
information systems to accommodate a change to ICD-10-CM diagnosis 
coding in the year 2001 and a major change to a unified approach to 
coding procedures (yet to be defined) by the year 2002 or 2003. We 
recommend that you identify and implement an approach for procedure 
coding that addresses deficiencies in the current systems, including 
issues of specificity and aggregation, unnecessary redundancy, and 
incomplete coverage of health care providers and settings.

    At the July 9, 1997, public meeting on progress on selecting the 
HIPAA standards, the implementation team presented an overview of its 
planned recommendations for coding and classification standards for the 
year 2000. The team's recommendations were similar to those of the 
NCVHS but included the use of NDC codes for pharmacy transactions that 
the NCVHS did not address. The implementation team did not recommend a 
specific timetable for changes in the standards after the year 2000. 
The team believed that its recommendations for changes after the year 
2000 should await the results of field testing of ICD-10-CM for 
diagnosis and ICD-10-PCS for procedures (which should be available in 
March 1998) and further consideration of options for moving toward a 
more integrated approach to procedure coding.
    One of the coding systems that the implementation team considered 
to be promising for future implementation was the Universal Product 
Numbers (UPNs) system. The UPN system is a product numbering technology 
that uses human readable and bar code formats to identify products. A 
bar code and human readable number, which is unique to a particular 
product, is printed on the label or box as part of the production line 
process. There are currently two separate and different UPN coding 
systems that are generally accepted and recognized for health care 
products. One is numeric, a fixed 14 digit number, and the other an 
alpha-numeric format, a variable length number 8 to 20 digits. The 
numeric format is the system of the Health Care Uniform Code Council 
(UCC) and the alpha-numeric format is used by the Health Industry 
Business Communications Council (HIBCC). The first series of digits are 
assigned by one of these two private companies and identify the 
manufacturer or a repackager. The remaining digits are assigned by the 
manufacturer or repackager and are assigned according to the user's own 
standards and specifications. A manufacturer or repackager can apply to 
either one of these companies to use its system. The application fees, 
which are collected by either UCC or HIBCC, vary based on the 
manufacturer's or repackager's sales volume.
    The Department of Defense has started to use UPNs for its prime 
vendor program. Currently, there are purchasers and providers of 
medical equipment that are using the UPN system for inventory purposes, 
but, at this time, there are no insurers that pay for health care 
products using the UPN system. California Medicaid, however, has plans 
to begin using UPNs as part of its system.
    At this time, approximately 30 percent of the health care products 
do not have a UPN assigned to them. For this reason, in addition to the 
fact that no insurer currently uses UPNs for reimbursement, UPNs were 
not included in the initial list of standards.

[[Page 25283]]

However, it is a coding system that bears close examination during the 
next few years as a possible replacement for alpha-numeric HCPCS codes 
for health care products. Some consideration is being given to 
conducting a demonstration study in the Medicare program on the use of 
UPNs for reimbursement.
    Comments on the use of the UPNs as a national coding system are 
being sought. In particular, comments on issues such as timing of 
implementation, any complications presented by the existence of 
multiple bodies issuing UPN codes, the acceptability of varying lengths 
and formats, and the frequent changes in manufacture and packaging size 
would be helpful.
ii. Changes to HCPCS for Implementation in the Year 2000
    In proposing the use of the existing coding systems as the 
standards for the year 2000, many participants at public meetings 
voiced concern about overlaps in several of the coding systems, 
problems with HCPCS local codes, differences in implementation of NDC 
codes in different systems, and differences between the CDT codes in 
HCPCS and those issued by the ADA. It was repeatedly suggested that 
these issues be resolved and overlaps be eliminated for standards 
adopted in the year 2000. After careful consideration of all public 
input and of the options for modifying HCPCS in the relatively near 
term, the implementation team is recommending that changes be 
implemented in HCPCS in the year 2000 to reduce its overlap with other 
coding systems.
    HCPCS contains three levels. Level 1, CPT, is developed and 
maintained by the AMA and captures physician services. Level 2, alpha-
numeric HCPCS, contains codes for products, supplies, and services not 
included in CPT. Level 3, local codes, includes all the codes developed 
by insurers and agencies to fulfill local needs.
    We are proposing the adoption of HCPCS levels 1 and 2 for 
implementation in the year 2000. In addition, we are proposing to 
modify HCPCS level 3 for the year 2000 to eliminate overlaps and 
duplications.
    Most third-party public and private health insurers (such as 
Medicare contractors, Medicaid program and fiscal agents, and private 
commercial health insurers) use HCPCS as a basis for paying claims for 
medical services provided on a fee-for-service basis and for monitoring 
the quality and utilization of care. In addition, integrated health 
systems, such as managed care organizations, also use HCPCS as a basis 
for monitoring utilization and quality of care and for negotiating 
prospective fees and capitated payments. Research organizations use the 
HCPCS data collected by health insurers to monitor and evaluate these 
programs and regional/national patterns of care.
    As previously stated, HCPCS alpha-numeric codes capture products, 
supplies, and services not included in CPT. The ``D'' codes in the 
HCPCS system are dental codes created by the ADA and published as CDT. 
However, in HCPCS, the first digit ``0'' in CDT is replaced by a ``D'' 
to eliminate confusion and overlap with certain CPT codes. The ADA has 
agreed to replace their first digit ``0'' with a ``D'' so that CDT can 
become the national standard. There would no longer be dental codes 
within HCPCS. Consequently, CDT 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 CDT.
    The ``J'' codes within alpha-numeric HCPCS are for drugs. A 
separate coding system, the NDC developed by the Food and Drug 
Administration, is also used to report drug claims in the ANSI X12N 
837--Health Care Claim: Professional and in pharmacy transactions. The 
NDC system, which has 11-digit codes, is more precise and more current 
than the HCPCS ``J'' codes. NDC identifies drugs prescribed down to the 
manufacturer, product name and package size. NDC codes are assigned on 
a continuous basis throughout the year as new drug products are issued; 
``J'' codes are assigned on an annual basis. Many providers are 
currently forced to maintain both ``J'' and NDC codes to provide data 
to different insurers. The majority of the local codes currently 
created were developed because of the lack of a ``J'' code for a new 
drug. Local codes are level 3 of the HCPCS and are assigned by local 
insurers or agencies where there is no national code. By eliminating 
``J'' codes from alpha-numeric HCPCS codes and utilizing only NDC codes 
for drugs, greater national uniformity can be achieved, the workload of 
providers who previously had to utilize two drug coding systems will be 
reduced, and the need for local codes will diminish substantially.
    HHS is, therefore, proposing that NDC codes become the national 
standard in the year 2000 for all types of transactions requiring drug 
codes and that ``J'' codes be deleted from alpha-numeric HCPCS. This 
would require those handling electronic administrative transactions to 
process 11-digit NDC codes in the year 2000.
    Level 3 of HCPCS is intended to meet local needs and is established 
on a local basis by health insurers. There is no national registry for 
these local codes. We propose that, beginning in the year 2000, local 
codes be eliminated and that a national process be established for 
reviewing and approving codes that are needed by any public or private 
health insurer.
    The first step in this process would be to ask public and private 
health insurers to review the local codes they use and to immediately 
eliminate those that duplicate a national HCPCS code or NDC code 
already in existence. (See the previous section for a discussion of NDC 
codes.) They would also be asked to eliminate those local codes for 
which there are few claims submissions (for example, fewer than 50 per 
year) and that could reasonably and effectively be reviewed by the 
health insurer. Health insurers would also be asked to eliminate those 
local codes which were established for administrative purposes, to 
facilitate claims payment, rather than to identify and describe medical 
services, supplies and procedures. (A code for ``administration of 
immunization at public health clinic'' is an example of a code that 
includes administrative information in addition to information about 
the clinical content of the service.) This purging would result in the 
elimination of the vast majority of local codes now in use. Any 
remaining local codes would then have to be submitted by the health 
insurer to HCFA for review and approval as temporary codes. The HCPCS 
panel currently meets every two to three months to approve requests for 
temporary codes. This process will be re-examined to determine if more 
frequent meetings are required.
    The process would be modeled after the one that is currently used 
to review and approve code requests from Medicare and its contractors. 
Codes that are approved by HCFA would be established as national 
temporary codes that would be posted electronically and would be 
available for use by all health insurers. National temporary codes 
would be reviewed on an annual basis to make sure they are not 
duplicative of CPT codes or alpha-numeric codes that are newly 
established.
    This new centralized process for establishing national temporary 
codes would run parallel to the process for establishing national CPT 
codes, alpha-numeric HCPCS codes, and NDC codes. It is expected that 
most of the codes submitted for approval by HCFA in this process would 
be for new medical technologies and services not yet approved for codes 
by CPT or the alpha-

[[Page 25284]]

numeric process or for other medical services/procedures covered by 
health insurers which have no associated CPT or alpha-numeric codes.
    These recommendations are based on the following:
    As stated earlier, many participants at public meetings voiced 
concerns about overlaps in codes that are used and the proliferation of 
local codes. Local codes that are duplicative of national codes create 
extra work and confusion for providers who must submit different codes 
to different health insurers. Local codes also make it more difficult 
for researchers and programs such as Medicaid and Medicare to evaluate 
and monitor patterns of care and the utilization and quality of care on 
a regional or national basis.
    The use of local codes established for administrative purposes, to 
facilitate claims payment rather than to identify medical services, 
supplies and procedures, is contrary to the intent of the medical 
coding system, which is intended to describe medical services used to 
prevent, diagnose, treat or manage diseases, injuries, and impairments. 
Administrative functions necessary to process and facilitate claims by 
health insurers can be achieved by using ``administrative'' codes 
placed in fields other than those used for medical diagnosis and 
procedure codes or by attaching a modifier to a medical code. Because 
the need for new temporary codes is not unique to an individual health 
insurer, the new codes that are created as a result of this centralized 
process would be useful not just to the health insurer who submitted 
the original request for a code but also to many other health insurers 
across the country. By eliminating duplicative and otherwise 
unnecessary local codes and adding national temporary codes through the 
centralized process discussed above, we believe we are being consistent 
with the intent of HIPAA to simplify the administration of the claims 
review, payment and monitoring process.
    We welcome comments and suggestions on this proposal for 
eliminating unnecessary local codes and establishing a centralized, 
national process for establishing national temporary codes. We seek 
input specifically on the problems and barriers to creating this type 
of process. We are also specifically looking for examples of the kinds 
of local codes that are now being used that would have to be replaced 
with national codes or for alternatives to the above-described process.
iii. Recommended Standards and Implementation Guides
    The proposed standard code sets for different types of medical data 
are outlined below:
    (a) Diseases, injuries, impairments, other health related problems, 
their manifestations, and causes of injury, disease, impairment, or 
other health-related problems.
    The proposed 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 National Center for Health Statistics, Centers for 
Disease Control and Prevention, U.S. Department of Health and Human 
Services. The specific data elements for which ICD-9-CM is the required 
code set are enumerated in the implementation guides for the 
transactions standards that require its use.
    An area of weakness of the ICD-9-CM is that it is not always 
precise or unambiguous. However, there are no viable alternatives for 
the year 2000. Many problems cannot be resolved within the current 
structure, but are being addressed in the development of ICD-10-CM for 
diagnosis, which is expected to be ready for implementation some time 
after the year 2000.
    The official coding guidelines for this proposed standard code set 
are in the public domain and available at no cost on the NCHS website 
at: http://www.cdc.gov/nchswww/about/otheract/icd9/icd9hp2.htm. Users 
without access to the Internet may purchase the official version of 
ICD-9-CM on CD-ROM from the Government Printing Office (GPO) at 1-202-
512-1800 or fax 1-202-512-2250. The CD-ROM contains the ICD-9-CM 
classification and the coding guidelines. The guidelines are also 
included in code books and coding manuals published by not-for-profit 
(for example, the American Hospital Association and the American Health 
Information Management Association) and other private sector vendors.
    (b) Procedures or other actions taken to prevent, diagnose, treat, 
or manage diseases, injuries and impairments.
(1) Physician Services
    The proposed standard code set for these entities is the Current 
Procedural Terminology (CPT) (level 1 of HCPCS) as maintained and 
distributed by the AMA. The specific data elements for which CPT 
(including codes and modifiers) is a required code set are enumerated 
in the implementation guides for the transaction standards that require 
its use.
    Narrative coding guidelines are presented at the beginning of each 
of the six sections of print edition of CPT and, in addition, special 
instructions for specific codes or groups of codes appear throughout 
CPT. CPT is available from the AMA at a charge as well as from several 
not-for-profit and other private sector vendors.
    An area of weakness of the CPT is that it is not always precise or 
unambiguous. However, there are no viable alternatives for the year 
2000.
(2) Dental Services
    The proposed standard code set for these services is the Current 
Dental Terminology (CDT) as maintained and distributed by the ADA for a 
charge. The specific data elements for which CDT is a required code set 
are enumerated in the implementation guides for the transaction 
standards that require its use.
    The official implementation guidelines for this standard appear in 
CDT as descriptors that explain the appropriate use of the codes. 
Copies of the ADA Current Procedural Terminology Second Edition (CDT-2) 
may be obtained by calling 1-800-947-4746. The ADA is in the process of 
developing CDT-3 for introduction in the year 2000.
(3) Inpatient Hospital Services
    The proposed standard code set for these services is the 
International Classification of Diseases, 9th edition, Clinical 
Modification, Volume 3, as maintained and distributed by the Health 
Care Financing Administration, U.S. Department of Health and Human 
Services. The specific data elements for which ICD-9-CM, Volume 3, is a 
required code set are enumerated in the implementation guides for the 
transactions standards that require its use.
    As stated earlier, an area of weakness of the ICD-9-CM is that it 
is not always precise or unambiguous. However, there are no viable 
alternatives for the year 2000 that are more precise or less ambiguous. 
Many problems cannot be resolved within the current structure but are 
being addressed in the development of ICD-10-PCS for procedures, which 
is expected to be ready for implementation some time after the year 
2000.
    The official coding guidelines for this standard are in the public 
domain and available at no cost on the NCHS website at <a href="http://
www.cdc.gov/nchswww/about/otheract/icd9/icd9hp2.htm">http://
www.cdc.gov/nchswww/about/otheract/icd9/icd9hp2.htm</a>. Users without 
access to

[[Page 25285]]

the Internet may purchase the official version of ICD-9-CM on CD-ROM 
from the Government Printing Office at 1-202-512-1800 or fax 1-202-512-
2250. The CD-ROM contains the ICD-9-CM classification and the coding 
guidelines. The guidelines are also included in code books and coding 
manuals published by not-for-profit (for example, the American Hospital 
Association and the American Health Information Management Association) 
and private sector vendors.
(c) Other Health-Related Services
    The proposed standard code set for other health-related services is 
the Health Care Financing Administration Procedure Coding System 
(alpha-numeric HCPCS) as maintained and distributed by the Health Care 
Financing Administration, U.S. Department of Health and Human Services. 
We are proposing to make significant modifications to alpha-numeric 
HCPCS for the year 2000. These modifications are described in Section 
II.D.2.a.ii of this proposed rule.
    The specific data elements for which alpha-numeric HCPCS (including 
codes and modifiers) is a required code set are enumerated in the 
implementation guides for the transaction standards that require its 
use.
    Alpha-numeric HCPCS codes meet all but one of the guiding 
principles for choosing standards. An area of weakness is that it is 
not always precise or unambiguous. However, there are no viable 
alternatives for the year 2000 that are more precise or less ambiguous. 
Some of the areas of ambiguity in HCPCS (the ``J'' codes for drugs, 
local codes, variant CDT codes) have been addressed in the changes 
recommended for the year 2000.
    The 1998 alpha-numeric HCPCS file (excluding the D procedure codes 
copyrighted by the ADA) is available from the HCFA website at <a href="http://
www.hcfa.gov/stats/pufiles.htm">http://
www.hcfa.gov/stats/pufiles.htm</a>. Users can also access this page by 
taking the Stats and Data link to the Browse/Download available PUFs 
link. The 1998 alpha-numeric HCPCS file is on the HCFA Public Use Files 
page under the Utilities/Miscellaneous heading.
    The HCPCS is in an executable format, which includes 1998 alpha-
numeric HCPCS in both Excel<SUP>/</SUP> and text, the 1998 Alpha-
Numeric Index in both Portable Document Format<SUP>/</SUP> (PDF) and 
text, the 1998 Table of Drugs in both PDF and text, the 1998 HCPCS 
record layout in WordPerfect<SUP>/</SUP> and text, and a read me file 
in WordPerfect<SUP>/</SUP> and text.
(d) Drugs
    The proposed standard code set for these entities is the National 
Drug Codes as maintained and distributed by the Food and Drug 
Administration, U.S. Department of Health and Human Services, in 
collaboration with drug manufacturers. The specific data elements for 
which NDC is a required code set are enumerated in the implementation 
guides for the transaction standards that require its use.
    NDC codes as established by the Food and Drug Administration are 
made available on the individual drug package inserts and product 
labeling. The Food and Drug Administration, Center for Drug Evaluation 
and Research, Office of Management, Division of Database Management, 
prepares an annual update, with periodic cumulative supplements of the 
Approved Drug Products with Therapeutic Equivalence Evaluations for 
prescription drug products, over the counter drug products and 
discontinued drug products. The supplements are available on diskette, 
on a quarterly basis, from the National Technical Information Service 
at 703-487-6430. The files are also available on the Internet's World 
Wide Web on the CDER Home Page at http://www.fda.gov/cder. The NDC 
codes are also published in such drug publications as the Physicians' 
Desk Reference under the individual drug product listings and ``How 
supplied.''
(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 Procedure Coding System (alpha-numeric 
HCPCS) as maintained and distributed by the Health Care Financing 
Administration, U.S. Department of Health and Human Services. We are 
proposing to make significant modifications to alpha-numeric HPCPS for 
the year 2000. These modifications are described in Section II.D.2.a.ii 
of this proposed rule. The specific data elements for which alpha-
numeric HCPCS is a required code set are enumerated in the 
implementation guides for the transactions standards that require its 
use.
    The recommended code sets adhere to the principles for guiding 
choices for the standards to be adopted under HIPAA as follows:
    <bullet> 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.
    Improvements in efficiency and effectiveness over the current 
status quo will result from: (a) The requirement for all those 
exchanging electronic transactions to use a single official 
implementation guide for each recommended code set; and (b) the 
proposed changes to HCPCS, which will eliminate overlap between NDC and 
HCPCS, eliminate one of the two current versions of CDT codes, and 
eliminate the use of local HCPCS codes that are known only to 
institutions that developed them.
    <bullet> Meet the needs of the health data standards user 
community, particularly health care providers, health plans, and health 
care clearinghouses.
    The recommended code sets meet some of the needs of the community. 
To meet all of the community's needs (e.g., elimination of overlap in 
procedure coding systems and better coverage of nursing and allied 
health services) will require changes to the code sets recommended or 
their replacement by newer systems, once these have been fully tested 
and revised. Essentially all segments of the health care community 
testified that there was no practical alternative to the recommended 
code sets for the year 2000, although they recommended changes after 
that time.
    <bullet> Be consistent and uniform with the other HIPAA standards--
their data element definitions and codes and their privacy and security 
requirements--and, secondarily, with other private and public sector 
health data standards.
    All of the recommended code sets are required for selected data 
elements in more than one of the recommended transaction standards.
    <bullet> Have low additional development and implementation costs 
relative to the benefits of using the standard.
    The recommended code sets are currently used by many segments of 
the health care community.
    <bullet> Be supported by an ANSI-accredited standards developing 
organization or other private or public organization that will ensure 
continuity and efficient updating of the standard over time.
    All of the recommended code sets are supported by U.S. government 
agencies or private sector organizations that have demonstrated a 
commitment to maintaining them over time.
    <bullet> Have timely development, testing, implementation, and 
updating procedures to achieve administrative simplification benefits 
faster.
    All of the recommended code sets have existing procedures for 
updating at

[[Page 25286]]

least annually. NDC updates continually throughout the year.
    <bullet> Be technologically independent of the computer platforms 
and transmission protocols used in electronic health transactions, 
except when they are explicitly part of the standard.
    All of the recommended code sets are technologically independent of 
computer platforms and transmission protocols.
    <bullet> Be precise and unambiguous, but as simple as possible.
    There are some problems with lack of precision and ambiguity in all 
the recommended code sets, but there are no viable alternatives for the 
year 2000. In the case of ICD-9-CM, many problems cannot be resolved 
within the current structure but are being addressed in the development 
of ICD-10-CM for diagnosis and ICD-10-PCS for procedures, which are 
expected to be ready for implementation some time after 2000. Some of 
the sources of ambiguity in HCPCS (the ``J'' codes for drugs, local 
codes, variant CDT codes) have been addressed in the changes 
recommended for the year 2000. The movement to a single framework for 
procedure coding, sometime after the year 2000, will address other 
known problems with the procedure codes.
    <bullet> Keep data collection and paperwork burdens on users as low 
as is feasible.
    Because the recommended code sets are currently used throughout the 
health care community, they should not add substantially to data 
collection or paperwork burdens.
    <bullet> Incorporate flexibility to adapt more easily to changes in 
the health care infrastructure (such as new services, organizations, 
and provider types) and information technology.
    Some of the recommended code sets lack a desirable level of 
flexibility; e.g., they use hierarchical codes and may therefore ``run 
out of room'' for additional codes required by advances in medicine and 
health care. Since they appear to be the only feasible alternatives for 
the year 2000, steps should be taken to improve their flexibility--or 
replace them with more flexible options--sometime after the year 2000.
iv. Probable Changes to Coding and Classification Standards After 2000
    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. As indicated in testimony at the NCVHS 
hearings previously discussed, changes will be required to address 
current coding system deficiencies that adversely affect the efficiency 
and quality of administrative data creation and to meet international 
treaty obligations. For example, ICD-10-CM for diagnosis is highly 
likely to replace ICD-9-CM as the standard for diagnosis data, possibly 
in 2001. 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. The current 
draft of ICD-10-CM for diagnoses contains 6 digit codes; the longest 
ICD-9-CM codes have 5 digits. In addition to accommodating the initial 
code sets standards for the year 2000, those that produce and process 
electronic administrative health transactions should build the system 
flexibility that will allow them to implement different code formats 
beyond the year 2000.
    As also clearly expressed in the hearings and other input to HHS, 
any major change in administrative coding systems involves significant 
initial costs and dislocations, as well as some level of discontinuity 
in data collected before and after the change. These factors must be 
weighed against expected improvements in the efficiency of data 
creation and in the accuracy and utility of the data collected. In the 
future, more flexible health data systems may assist in reducing the 
costs of implementing changes in administrative coding and 
classification standards, especially if administrative codes can be 
generated automatically from more granular clinical data.
b. Requirements
    In Sec. 142.1002, we would state that health plans, health care 
clearinghouses, and health care providers must use in electronic 
transactions the diagnosis and procedure code sets as prescribed by 
HHS. The names of these diagnosis and procedure code sets are published 
in a notice in the Federal Register. The implementation guides for the 
transaction standards in part 142, Subparts K through R would specify 
which of the standard medical data code sets should be used in 
individual data elements within those transaction standards.
    In Sec. 142.1004, we would specify that the code sets in the 
implementation guide for each transaction standard in part 142, 
subparts K through R, are 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, would specify 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, 
without regard to local policies regarding reimbursement for certain 
conditions or procedures, coverage policies, or need for certain types 
of information that are not part of a standard transaction.

E. Transaction Standards

    The HISB prepared an inventory of candidate standards to be 
considered by HHS in the standards adoption process. HHS wrote letters 
to the NUBC, the NUCC, the ADA, and WEDI in order to consult with them 
as required by the Act. HHS also consulted with them informally and 
received their support on all the transactions at various meetings and 
at the public meeting we held on July 9, 1997, in Bethesda, Maryland. 
The NCVHS held public hearings during which any person could present 
his or her views. There also were opportunities for those who could not 
attend the public hearings to provide written advice, and many did take 
advantage of that opportunity. In addition, HHS welcomed informal 
advice from any industry member, and that advice was taken into 
consideration during the decision making process.
    Recommendations for enrollment and disenrollment in a health plan, 
eligibility for a health plan, health care payment and remittance 
advice, health plan premium payments, first report of injury, health 
claim status, and referral certification and authorization were 
overwhelmingly in favor of ASC X12N implementations. Also, the 
recommendation for the National Council of Prescription Drug Programs 
(NCPDP) version 3.2 telecommunication standard format was not 
controversial and was nearly unopposed.
    The recommendations for the professional and institutional claims 
were quite controversial, with some factions supporting the de facto 
flat file standards that have been in use for many years and others 
supporting X12N standards.

[[Page 25287]]

    (A flat file is a file that has fixed-length records and fixed-
length fields.) Some associations proposed dual standards with the flat 
file claim standards (National Standard Format for professional claims 
and electronic UB-92 for institutional claims) to sunset on a specified 
date, at which time the parallel ASC X12N claim implementations would 
become the sole standards to be used.
    The HHS claims implementation team recommended, and we are 
proposing for adoption, the following standards as implemented through 
the appropriate implementation guides, data content and data conditions 
specifications, and data dictionary:
    <bullet> Health care claim and equivalent encounter:
    + Retail drug: NCPDP Telecommunication Claim version 3.2 or 
equivalent NCPDP Batch Standard Version 1.0.
    + Dental claim: ASC X12N 837--Health Care Claim: Dental.
    + Professional claim: ASC X12N 837--Health Care Claim: 
Professional.
    + Institutional claim: ASC X12N 837--Health Care Claim: 
Institutional.
    <bullet> Health care payment and remittance advice: ASC X12N 835--
Health Care Payment/Advice.
    <bullet> Coordination of benefits:
    + Retail drug: NCPDP Telecommunication Standard Format version 3.2 
or equivalent NCPDP Batch Standard Version 1.0.
    + Dental claim: ASC X12N 837--Health Care Claim: Dental.
    + Professional claim: ASC X12N 837--Health Care Claim: 
Professional.
    + Institutional claim: ASC X12N 837--Health Care Claim: 
Institutional.
    <bullet> Health claim status: ASC X12N 276/277--Health Care Claim 
Status Request and Response.
    <bullet> Enrollment and disenrollment in a health plan: ASC X12 
834--Benefit Enrollment and Maintenance.
    <bullet> Eligibility for a health plan: ASC X12N 270/271--Health 
Care Eligibility Benefit Inquiry and Response.
    <bullet> Health plan premium payments: ASC X12 820--Payment Order/
Remittance Advice.
    <bullet> Referral certification and authorization: ASC X12N 278--
Health Care Services Review--Request for Review and Response.
    We chose version 4010 of X12 for each ASC X12N transaction. Later 
in this proposed rule is a list of candidates for most transactions. 
The ASC X12N transactions listed as candidate standards in this section 
were originally specified as version 3070 because at the time of HISB 
inventory version 3070 was the most current DSTU version. However, we 
are proposing that version 4010 would be proposed in lieu of version 
3070 for the following reasons:
    <bullet> Version 4010 is millennium ready.
    <bullet> Version 4010 allows for up-to-date changes to be 
incorporated into the standards.
    We will propose a claims attachment standard in a separate document 
as the statute gives the Secretary an additional year to designate this 
standard. The attachment standards are likely to be drafted so that 
health care providers using Health Level 7 (HL7) for their in-house 
clinical systems would be able to send HL7 clinical data to health 
plans. Anyone wishing to use the HL7 may want to consider a translator 
that supports the administrative transactions proposed in this proposed 
rule and the HL7.
    We will also propose a standard for first report of injury 
transactions in a later rule for reasons explained in depth under 
section II.E.9.
1. Standard: Health Claims or Equivalent Encounter Information (Subpart 
K)
[Please label any written comments or e-mailed comments about this 
section with the subject: Health Claims]
a. Background
    By the mid-1970s, several health care industry associations had 
formed committees to attempt to standardize paper health care claim or 
equivalent encounter forms. By the mid-1980s, those committees were 
standardizing electronic formats with equivalent data. By the early 
1990s, some of these committees were working with the ASC X12N 
Subcommittee. Nevertheless, many health plans continued to require 
local formats, revising the formats to suit their own purposes rather 
than following procedures in order to revise the standards. As a 
result, it is not unusual for health care providers to support many 
electronic health care claim formats, either directly or by using 
clearinghouse services, in order to do business with the many health 
plans covering their patients.
    The committees that pursued organizational goals (such as a more 
cost-efficient environment for the provision of health care, more time 
and resources for patient care, and fewer resources for administration) 
were usually sponsored by health care provider associations such as the 
National Council of Prescription Drug Programs, the AMA, the American 
Hospital Association, and the ADA. Each association contributed to the 
development of the four corresponding accredited claims standards 
proposed for adoption, with content based on de facto standards derived 
over time.
i. Candidates for the Standard
    The HISB developed an inventory of health care information 
standards for HHS to consider for adoption. The candidate standards for 
health claims or equivalent encounter information were:
    <bullet> Retail drug: NCPDP Telecommunications Standard Format 
Version 3.2.
    <bullet> Dental claim: ASC X12N 837--health care claim: dental, 
version 3070 implementation.
    <bullet> Professional claim: ASC X12N 837--health care claim: 
Professional, version 3070 implementation and HCFA National Standard 
Format (NSF), version 002.00.
    + Institutional claim: ASC X12N 837--health care claim: 
institutional, version 3070 implementation and HCFA Uniform Bill (UB-
92) version 4.1
ii. Recommended Standards
    The four standards for claims or equivalent encounter information 
we are proposing in this proposed rule are:
    <bullet> Retail drug: NCPDP Telecommunications Standard Format 
Version 3.2 and equivalent NCPDP Batch Standard Version 1.0.
    The NCPDP was formed in 1977 as the result of a Senate Ad Hoc 
Committee to study standardization within the pharmacy industry. The 
NCPDP was specifically named in HIPAA as a standards setting 
organization accredited by ANSI. The first NCPDP Telecommunications 
Standard was developed in 1988 and allowed pharmacists to process 
claims in an interactive environment. The NCPDP developed the 
Telecommunications Standard Format for electronic communication of 
claims between pharmacy providers, insurance carriers, third-party 
administrators, and other responsible parties. The standard addresses 
the data format and content, the transmission protocol, and other 
appropriate telecommunications requirements. The NCPDP received input 
from all aspects of the prescription drug industry and designed the 
standard to be easy to implement and flexible enough to respond to the 
changing needs of the industry. The NCPDP also provides changes and 
additions to the standard to support unique requirements included in 
government mandates.
    The NCPDP telecommunications standard for claim and equivalent 
encounter data is on-line interactive. There is also a batch 
implementation of this standard, the NCPDP Batch Standard Version 1.0. 
The

[[Page 25288]]

telecommunications standard data set includes eligibility/enrollment, 
claim, and remittance advice information. When the transaction is 
complete, the sending pharmacy knows whether the customer is covered by 
the health plan, the health plan knows all of the details of the claim, 
the pharmacy knows whether the claim will be paid, and how much it will 
be paid, and any pertinent details regarding the amount of payment or 
the reason for denial of payment. This standard met all 10 of the 
criteria used to assess standards.
    Since retail drug claims are a specialized class and the NCPDP 
structure contains claims, enrollment/eligibility and remittance advice 
data, we did not recommend the ASC X12N 837 for the retail drug 
standard.
    <bullet> Dental claim: ASC X12N 837--Health Care Claim: Dental.
    The ADA recommended adoption of the ASC X12N 837, version 3070. 
This standard met all of the criteria used to assess standards.
    Professional claim: ASC X12N 837--Health Care Claim: Professional.
    HHS consulted with external groups in accordance with the 
legislation. These groups included the NCVHS, WEDI, the NUCC, the NUBC, 
the ADA, and many others.
    In a letter, dated March 12, 1997, the NUCC stated,

    The NUCC recommends to the Secretary of HHS that the ANSI ASC 
X12 837 transaction be adopted as a standard for electronically 
transmitting professional claims or equivalent encounters, including 
coordination of benefits information, as per the Administrative 
Simplification provision of the HIPAA.
    The NUCC recommends that a migration plan be adopted to allow 
current trading partners who use the National Standard format (NSF) 
to convert to a standard NSF, which will be implemented by the 
Secretary per the HIPAA, by February 2000 and to convert to the 
standard ANSI ASC X12 837 by February 2003.

    The AMA also supported the NUCC recommendation. However, the NCVHS 
and WEDI recommended adoption of the ASC X12N 837 transaction. The 
claims implementation team decided that, since the NUCC was clear that 
it wanted the ASC X12N 837 transaction in the end, it would be better 
to invest in migrating to that, rather than support two standards and 
take more time for the transition.
    Our recommendation takes into account the advice we received from 
organizations that we consulted directly and indirectly and from those 
who testified before the NCVHS subcommittee on Health Data Needs, 
Standards, and Security. These organizations included entities 
representing all parts of the health care industry--health care 
providers, health plans, and vendors/clearinghouses--to which the 
standard will apply.
    The ASC X12N 837 standard met all 10 criteria used to assess 
standards. The NSF met 5 of the criteria. The NSF does not improve the 
efficiency and effectiveness of the health care system (#1) because a 
standard implementation does not exist. The NSF meets the needs of many 
users, particularly Medicare, but not all of the needs of the user 
community (#2). It is not supported by an ANSI-accredited SDO (#5). 
There are no testing or implementation procedures in place (#6). Due to 
its fixed-length structure, it does not incorporate flexibility to 
adapt easily to change (#10).
    Institutional claim: ASC X12N 837--Health Care Claim--
Institutional.
    HHS consulted with the groups identified under our discussion of 
the standard for professional claims above in this section and also 
consulted with the NUBC on the selection of an institutional standard. 
In a letter dated March 11, 1997, the NUBC stated,

    The NUBC recommends the use of the EMC V.4 (UB-92) as the single 
electronic standards transaction for institutional health claims and 
encounters. We recommend the EMC V.4 for the following reasons:

--Nearly all institutional providers already use the EMC V.4 with a 
high level of success.
--The EMC V.4 has been in full production for over four years.
--There is no additional cost for providers to adopt the EMC V.4.
--It reduces the risks associated with the adoption of a new, 
complex and relatively untested transaction.
--It allows for a more successful transition to the 837.

    We agree with HCFA that coordination of benefits transactions 
(COB) do not require a fully separate transaction for the health 
care claim or encounter. The NUBC also believes that the EMC V.4 
should be used as the platform for transmitting COB data elements.
    At the present time, the NUBC cannot recommend the use of the 
837 as the electronic institutional claim standard.
    We recommend that larger scale testing of the 837 proceed. Once 
the transaction has proven that it can successfully handle the 
claim/encounter, the NUBC will consider endorsing the 837 as a 
successor standard.

    The American Hospital Association also supported NUBC's 
recommendation. The NCVHS and WEDI recommended adoption of the ASC X12N 
837 transaction.
    Due to the batch nature of the ASC X12N transactions, each 
transaction type and its corresponding data elements are separated by 
function. The adoption of the transactions for those functions (such as 
claims and remittance advice), with the exception of the NCPDP 
transaction, have all been recommended to be ASC X12N transactions. The 
ASC X12N 837 met all 10 criteria used to assess the standards. The UB-
92 met 5 of the criteria. The UB92 does not improve the efficiency and 
effectiveness of the health care system (#1) because a standard 
implementation does not exist. The UB92 is not supported by an ANSI-
accredited SDO (#5). There are no testing or implementation procedures 
in place (#6). The UB92 documentation is ambiguous in some instances 
and not always precise (#8). Due to its fixed-length structure, it does 
not incorporate flexibility to adopt easily to change (#10). The NUBC 
stated it would consider the 837, once successfully tested. For these 
reasons, we have concluded that the ASC X12N 837 should be adopted as 
the standard format implementation of the institutional claim.
    For the most part, a health care provider would use only one of 
these four health care claim implementations, although a large 
institution might use the institutional claim for inpatient and 
outpatient claims, the professional claim for staff physicians who see 
private patients within the institution, and the retail pharmacy claim, 
if applicable, which typically would be administered separately from 
the rest of the institution.
    Data elements for the various standards and other information may 
be found in Addendum 1.
b. Requirements
    In Sec. 142.1102, we would specify the exact standards we are 
adopting: the NCPDP Telecommunications Standard Format Version 3.2 and 
equivalent NCPDP Batch Standard Version 1.0; the ASC X12N 837--Health 
Care Claim: Dental, the ASC X12N 837--Health Care Claim: Professional, 
and the ASC X12N 837--Health Care Claim: Institutional. We would 
specify where to find the implementation guide and incorporate it by 
reference.
    i. Health plans.
    In Sec. 142.1104, Requirements: Health plans, we would require 
health plans to accept only the standards specified in Sec. 142.1102 
for electronic health claims or equivalent encounter information.
    ii. Health care clearinghouses.
    We would require in Sec. 142.1106 that each health care 
clearinghouse use the standard specified in Sec. 142.1102 for health 
claims or equivalent encounter information transactions.
    iii. Health care providers.

[[Page 25289]]

    In Sec. 142.1108, Requirements: Health care providers, we would 
require each health care provider that transmits health claims and 
encounter equivalent electronically to use the standard specified in 
Sec. 142.1102.
c. Implementation Guide and Source
    The source of implementation guides for the NCPDP telecommunication 
claim version 3.2 and equivalent NCPDP Batch Standard Version 1.0 is 
the National Council for Prescription Drug Programs, 4201 North 24th 
Street, Suite 365, Phoenix, AZ, 85016; telephone 602-957-9105; FAX 602-
955-0749. The web site address is: http://www.ncpdp.org.
    NCPDP standards are available to the public on a 3\1/2\'' diskette 
for a fee. A set is defined as containing the Telecommunications 
Standard, Standard Claims Billing Tape Format, Eligibility Verification 
and Response, and Enrollment. Membership in the NCPDP is not a 
requirement for obtaining the standards and associated implementation 
guides. The website contains information and instructions for obtaining 
these documents.
    The implementation guides for the ASC X12N standards are available 
at no cost from the Washington Publishing Company site at the following 
Internet address: http://www.wpc-edi.com/hipaa/.
    Users without access to the Internet may purchase implementation 
guides from Washington Publishing Company directly: Washington 
Publishing Company, 806 W. Diamond Ave., Suite 400, Gaithersburg, MD, 
20878; telephone 301-590-9337; FAX: 301-869-9460. The data definitions 
and description of data conditions may also be obtained from this 
website.
    The names of the implementation guides are:

ASC X12N 837--Health Care Claim: Professional (004010X098)
ASC X12N 837--Health Care Claim: Institutional (004010X096)
ASC X12N 837--Health Care Claim: Dental (004010X097)
2. Standard: Health Care Payment and Remittance Advice (Subpart L)
[Please label any written comments or e-mailed comments about this 
section with the subject: Payment]
a. Background
    The filing of claims for reimbursement (especially when a large 
number of patients have more than one insurer), control of those 
claims, association of payments, denials or rejections received with 
the patient records, posting of adjudication data to those records, 
reconciliation of payments sent to financial institutions, and storage 
and retrieval of patient accounts is a very labor intensive process 
when conducted manually. The process is further complicated by the 
diverse requirements and processes for activities such as billing, 
payment, and notification of the large number of health plans, which 
requires that health care provider staff stock multiple types of forms, 
be trained in the variety of requirements, be able to interpret the 
wide range of coding schemes used by each health plan, and maintain 
billing and payment manuals for each health plan.
    We believe that automation can greatly reduce the labor required 
for these processes, especially if every health plan becomes automated 
around a standard model so that health care providers are not required 
to deal with different requirements and software. Automation of the 
payment and remittance advice process can provide many benefits: health 
care providers can post claim decisions and payments to accounts 
without manual intervention, eliminating the need for re-keying data; 
payments can be automatically reconciled with patient accounts; and 
resources are freed to address patient care rather than paper and 
electronic administrative work.
    The ASC X12N Subcommittee established a workgroup in late 1991 to 
develop the ASC X12N 835--Health Care Claim Payment/Advice, since there 
was no existing standard capable of handling the large datasets 
necessary for health care.
i. Candidates for the Standards
    Prior to development of the ASC X12N 835, there were very few 
electronic formats available for the health care claim payment and 
remittance advice function. As researched by the HISB, existing 
standards that could be considered for national implementation under 
HIPAA for health care claim payment/remittance advice included:
    ASC X12N 835--Health Care Claim Payment/Advice, version 3070; ASC 
X12N 820 Payment Order/Remittance Advice; and the National Standard 
Format (NSF) for Remittance Version 2.0
ii. Recommended Standard
    The standard for remittance advice proposed in this proposed rule 
is the ASC X12N 835 Health Care Claim Payment/Advice.
    HHS chose this standard primarily because of advice received from 
industry members. Health care providers and health plans in the ASC 
X12N Subcommittee rejected the ASC X12N 820 due to its lack of health 
care specific information for this function. The X12N 820 is used for 
electronic payment of health insurance premiums by employers. Although 
the NSF is used by a large number of Medicare providers, we rejected it 
because it is not an ANSI-accredited standard and it lacks an 
independent, nongovernmental body for maintenance.
    The ASC X12N 835 may be used in conjunction with payment systems 
relying either on electronic funds transfer or the creation of paper 
checks. It may be sent through the banking system or it may be split 
with the electronic funds transfer portion directed to a bank, and the 
data portion sent either directly or through a health care 
clearinghouse to the individual for whom the funds are intended. If 
paper checks are used, the entire transaction is sent either directly 
or through a health care clearinghouse to the individual for whom the 
funds are intended. In all cases, however, the health care provider may 
use the electronic data in its own system, gaining efficiency by means 
of automatic posting of patient accounts. Uniformity is just as 
important as it is for health care claims, since there would be little 
gain in efficiency for the health care provider who must adapt to 
multiple formats and multiple data contents for remittance advice. This 
transaction is suitable for use only in batch mode.
    HHS, based on recommendations, has determined that the ASC X12N 
835--Health Care Claim Payment/Advice is the best candidate for 
adoption under HIPAA. A wide range of the health care community 
participated in its initial design, and the ASC X12N is ANSI-
accredited. Whereas the NSF met 5 of the criteria against which we 
evaluated the standards, the ASC X12N standards met all 10. The NSF 
does not improve the efficiency and effectiveness of the health care 
system (#1) because a standard implementation does not exist. The NSF 
was developed primarily for Medicare and, therefore, does not meet all 
of the needs of the user community (#2). It is not supported by an 
ANSI-accredited SDO (#5). There are no testing or implementation 
procedures in place (#6). Due to its fixed-length structure, it does 
not incorporate flexibility to adapt easily to change (#10).
    Data elements for the standard and other information may be found 
in Addendum 2.

[[Page 25290]]

b. Requirements
    In Sec. 142.1202, we would specify the ASC X12N 835 Health Care 
Claim Payment/Advice (004010X091) as the standard for payment and 
remittance advice transactions. We would also specify the source of the 
implementation guide and incorporate it by reference.
    i. Health plans.
    In Sec. 142.1204, Requirements: Health plans, we would require 
health plans to use only the standard specified in Sec. 142.1202 for 
electronically transmitting payment and remittance advice transactions.
    ii. Health care clearinghouses.
    We would require in Sec. 142.1206 that each health care 
clearinghouse use the standard specified in Sec. 142.1202 for payment 
and remittance advice transactions.
c. Implementation Guide and Source
    The implementation guide for the ASC X12N 835 (004010X091) is 
available at no cost from the Washington Publishing Company site at the 
following Internet address: http://www.wpc-edi.com/hipaa/.
    Users without access to the Internet may purchase implementation 
guides from Washington Publishing Company directly: Washington 
Publishing Company, 806 W. Diamond Ave., Suite 400, Gaithersburg, MD 
20878; telephone 301-590-9337; FAX: 301-869-9460. The data definitions 
and description of data conditions may also be obtained from this 
website.
3. Standard: Coordination of Benefits (Subpart M)
[Please label any written comments or e-mailed comments about this 
section with the subject: COB]
a. Background
    In an effort to provide better service to their customers, many 
health plans have made arrangements with each other to send claims 
electronically in the order of payment precedence, thus saving the 
customer the process of waiting for another health plan's notice. Each 
health plan in the chain wishes to see the original claim as well as 
the details of its adjudication by prior health plans that dealt with 
it. We believe that there should be a coordination of benefits standard 
to facilitate the interchange of this information between health plans.
    Adoption of a standard for electronic transmission of standard data 
elements among health plans for coordination of benefits and sequential 
processing of claims would serve these goals expressed by the Congress. 
Currently, the coordination of benefits for patients covered by 
multiple health plans is a burdensome chore. The COB transaction 
differs somewhat from the others because there are two models in 
existence for conducting it. The first model is provider-to-plan, where 
the provider submits the claim to the primary insurer, receives 
payment, and resubmits the claim (with the remittance advice from the 
primary insurer) to the secondary insurer. The second model is plan-to-
plan, where the provider supplies the primary insurer with information 
needed for the primary insurer to then submit the claim directly to the 
secondary insurer. The choice of model has been made between the 
providers and plans. Where the first model is used, the primary insurer 
essentially has no role in the COB transaction. Put another way, in the 
first model there is no separate COB transaction. Instead, the COB 
function is accomplished by a health care provider submitting a series 
of individual claims. This succession of transactions from health care 
provider to primary health plan to health care provider to secondary 
health plan, which often involves the production, reproduction, and 
mailing of paper forms and multiple claim formats, is time consuming 
and administratively costly. In some instances, it becomes even more 
burdensome when the provider shifts responsibility for these 
administrative tasks to the patient. Health plans have been unwilling 
to take on the full responsibility for coordinating benefits because of 
the many different forms and formats used for these transactions.
    Administrative simplification and electronic standards can simplify 
and smooth this onerous process. The four products of administrative 
simplification--(1) The uniform standards for electronic claims 
submissions; (2) an electronic transmission standard for coordination 
of benefits; (3) a uniform national standard for the data elements 
necessary for coordination of benefits among health plans; and (4) 
uniform health plan and provider identification numbers to efficiently 
route electronic transactions--would combine to remove the barriers 
that health plans currently face in carrying out transactions. These 
products would facilitate the process of the second model, direct 
health plan to health plan coordination of benefits. Once these 
standards are implemented, coordination of benefits could be completed 
without provider or patient intervention and at a lower cost to all 
parties than under current practice.
    Primary insurers are not required to participate in COB 
transactions as described in the second model. If, however, a plan does 
conduct COB through the second model, then it would be required to use 
the standard format. Primary insurers may determine whether they wish 
to participate in COB transactions (i.e., use the second model) based 
on their normal business practices. Where primary insurers do perform 
COB (using the second model) they must conduct the transaction 
electronically as standard transactions.
    The ASC X12N 837 Health Care Claim (refer to E.1. above) is 
designed to facilitate coordination of benefits. Each health plan 
responsible for the claim passes the claim on to the next health plan 
responsible for the claim. This transaction describes the original 
claim and how previous health plans adjudicated the claim. In October 
1994, the ASC X12N Subcommittee modified the ASC X12N 837 Health Care 
Claim to fully support coordination of benefits.
i. Candidates for the Standard
    a. Retail drug: NCPDP Telecommunications Standard Format version 
3.2.
    b. Dental claim: ASC X12N 837--Health Care Claim: Dental, version 
3070.
    c. Professional claim: ASC X12N 837--Health Care Claim: 
Professional, version 3070.
    d. Institutional claim: ASC X12N 837--Health Care Claim: 
Institutional, version 3070; and the Uniform Bill (UB-92) version 4.1.
ii. Recommended Standard
    The standards for the coordination of benefits exchange we are 
proposing are:
    a. Retail drug: NCPDP Telecommunications Standard Format version 
3.2 and the equivalent NCPDP Batch Standard Version 1.0.
    b. Dental claim: ASC X12N 837--Health Care Claim: Dental 
(004010X097).
    c. Professional claim: ASC X12N 837--Health Care Claim: 
Professional (004010X098).
    d. Institutional claim: ASC X12N 837--Health Care Claim: 
Institutional (004010X096).
    Since all recommended transactions for claims or equivalent 
encounters and the remittance advice are ASC X12N, with the exception 
of the NCPDP, it was determined that this transaction was the best 
candidate for national implementation, as it will increase the 
synergistic effect of the other ASC X12N standards.
    All health plans who perform COB, using the second model described 
above, would have to send and receive these standards for coordination 
of benefits. The data elements added to

[[Page 25291]]

explain the prior payments on the claim are shown in the implementation 
guide, data conditions, and data dictionary. This transaction 
accommodates coordination of benefits through the tertiary health plan. 
The NCPDP telecommunication claim version 3.2 is interactive. The three 
X12 standards are designed for use only in batch mode.
    HHS chose these standards primarily because of advice received from 
industry members.
    Data elements for the various standards and other information may 
be found in Addendum 3.
b. Requirements
    In Sec. 142.1302, we would specify the following as the standards 
for coordination of benefits: the NCPDP Telecommunications Standard 
Format Version 3.2 and equivalent NCPDP Batch Standard Version 1.0; the 
ASC X12N 837--Health Care Claim: Dental (004010X097); the ASC X12N 
837--Health Care Claim: Professional (004010X098); and the ASC X12N 
837--Health Care Claim--Institutional (004010X096). We would specify 
where to find the implementation guide and incorporate it by reference.
    i. Health plans.
    In Sec. 142.1304, Requirements: Health plans, we would require 
health plans who perform COB to use only the standards specified in 
Sec. 142.1302 for electronic coordination of benefits transactions.
    ii. Health care clearinghouses.
    We would require in Sec. 142.1306 that each health care 
clearinghouse use the standards specified in Sec. 142.1302 for 
coordination of benefits.
c. Implementation Guide and Source
    The source of implementation guides for the NCPDP telecommunication 
claim version 3.2 and equivalent Standard Claims Billing Tape Format is 
the National Council for Prescription Drug Programs, 4201 North 24th 
Street, Suite 365, Phoenix, AZ, 85016; Telephone 602-957-9105, FAX 602-
955-0749. The web site address is: http://www.ncpdp.org. NCPDP 
standards are available to the public on a 3\1/2\'' diskette. A set is 
defined as containing the Telecommunications Standard, Standard Claims 
Billing Tape Format, Eligibility Verification and Response, and 
Enrollment. Membership in the NCPDP is not a requirement for obtaining 
the standards and associated implementation guides. The website 
contains information and instructions for obtaining these formats.
    The implementation guides for the three ASC X12N health care claim 
standard implementations are available at no cost from the Washington 
Publishing Company site at the following Internet address: <a href="http://
www.wpc-edi.com/hipaa/">http://
www.wpc-edi.com/hipaa/</a>. The data definitions and description of data 
conditions may also be obtained from this website.
    Users without access to the Internet may purchase implementation 
guides from Washington Publishing Company directly. Washington 
Publishing Company, 806 W. Diamond Ave., Suite 400, Gaithersburg, MD, 
20878; Telephone 301-590-9337; FAX: 301-869-9460.
    The names of the implementation guides are:

ASC X12N 837--Health Care Claim: Professional (004010X098)
ASC X12N 837--Health Care Claim: Institutional (004010X096)
ASC X12N 837--Health Care Claim: Dental (004010X097)
4. Standard: Health Claim Status (Subpart N)
[Please label any written comments or e-mailed comments about this 
section with the subject: Status]
a. Background
    Health care providers need the ability to obtain up to date 
information on the status of claims submitted to health plans for 
payment, and the health plans need a mechanism to respond to these 
requests for information. The current processes are complicated by the 
diverse processes within health plan adjudication systems, which permit 
nonstandard information to be provided on the status of claims 
submitted. Most health care providers currently request claims status 
information manually. This requires health plans to provide information 
through various procedures that are costly and time consuming for all.
    With the paper model of claims processing, inquirers who want to 
know the status of a claim they have submitted to a health plan call 
the health plan. An operator looks up the status via computer terminal 
or some other means and explains the status to the caller. The health 
claim status tells the inquirer whether the claim has been received, 
whether it has been paid, or whether it is stopped in the system 
because of edit failures, suspense for medical review or some other 
reason.
    Many health plans have devised their own electronic claims status 
transactions since this is a function that is cheaper, easier, and 
faster to do electronically. This transaction eases administrative 
burden for both health plan and health care provider.
    The ASC X12N Subcommittee established a workgroup (Workgroup 5 
Claims Status) to develop a standard implementation with standard data 
content for all users of the ASC X12N 276/277 Health Care Claim Status 
Request and Response (004010X093).
    The ASC X12N 276 is used to transmit request(s) for status of 
specific health care claim(s). Authorized entities involved with 
processing the claim need to track the claim's current status through 
the adjudication process. The purpose of generating an ASC X12N 276 is 
to obtain the current status of the claim. Status information can be 
requested at various levels. The first level would be for the entire 
claim. A second level of inquiry would be at the service line level to 
obtain status of a specific service within the claim.
    The ASC X12N 277 Health Care Claim Status Response is used by the 
health plan to transmit the current status within the adjudication 
process. This can include status in various locations within the 
adjudication process, such as pre-adjudication (accepted/rejected claim 
status), claim pending development, suspended claim(s) information, and 
finalized claims status.
    Prior to the development of the ASC X12N 276/277 Health Care Claim 
Status Request and Response, there were very few proprietary or other 
electronic formats available for this type of claims status, and none 
were in widespread use. No existing standard was accepted for national 
use by the health care community. As researched by the HISB, only one 
standard could be considered for national implementation under HIPAA 
for health care claim status request and response: the ASC X12N 276/277 
Health Care Claim Status Request and Response, version 3070.
i. Candidates for the Standard
    The candidate standard for health care claim status is:
    ASC X12N 276/277 Health Care Claim Status Request and Response, 
version 3070.
ii. Standard Selected
    We propose to adopt ASC X12N 276/277 Health Care Claim Status 
Request and Response (004010X093), as the national standard for uniform 
use by health plans and health care providers for health care claims 
status.
    HHS chose this standard primarily because of advice received from 
industry members. It met all 10 of the criteria used for assessing 
standards.
    Data elements for the standard, and other information, may be found 
in Addendum 4.

[[Page 25292]]

b. Requirements
    In Sec. 142.1402, we would specify the following as the standard 
for health care claims status: ASC X12N 276/277 Health Care Claim 
Status Request and Response (004010X093). We would specify where to 
find the implementation guide and incorporate it by reference.
    i. Health plans.
    In Sec. 142.1404, Requirements: Health plans, we would require 
health plans to use only the standards specified in Sec. 142.1402 for 
electronic health care claims status transactions.
    ii. Health care clearinghouses.
    We would require in Sec. 142.1406 that each health care 
clearinghouse use the standards specified in Sec. 142.1402 for health 
care claims status.
    iii. Health care providers.
    In Sec. 142.1408, Requirements: Health care providers, we would 
require each health care provider that transmits health care claim 
status requests electronically to use standards specified in 
Sec. 142.1402 for those transactions.
c. Implementation Guide and Source
    The implementation guide for the standard is available at no cost 
from the Washington Publishing Company site at the following Internet 
address: http://www.wpc-edi.com/hipaa/. The data definitions and 
description of data conditions may also be obtained from this website.
    Users without access to the Internet may purchase implementation 
guides from Washington Publishing Company directly: Washington 
Publishing Company, 806 W. Diamond Ave., Suite 400, Gaithersburg, MD, 
20878; telephone 301-590-9337; FAX: 301-869-9460.
5. Standard: Enrollment and Disenrollment in a Health Plan (Subpart O)
[Please label any written comments or e-mailed comments about this 
section with the subject: Enrollment]
a. Background
    Currently, employers and other sponsors conduct transactions with 
health plans to enroll and disenroll subscribers and other individuals 
in a health insurance plan. The transactions are rarely done 
electronically.
    However, the ASC X12 834, Benefit Enrollment and Maintenance has 
been in widespread use within the insurance industry at large since 
February 1992 when ANSI approved it as a draft standard for trial use. 
Variants of this transaction standard have been widely used by 
employers to advise insurance companies of enrollment and maintenance 
information on their employees for insurance products other than 
health. It has rarely been used within the health care industry.
    i. Candidates for the Standard.
    According to the inventory conducted for HHS by the HISB, only two 
standards developed and maintained by a standards developing 
organization for the enrollment transaction exist. The first is the 
ANSI ASC X12 834. The second is the Member Enrollment Standard 
developed by the NCPDP.
    ii. Recommended Standard.
    The ANSI ASC X12 834--Benefit Enrollment and Maintenance is the 
standard proposed for electronic exchange of individual, subscriber, 
and dependent enrollment and maintenance information between sponsors 
and health plans, either directly or through a vendor, such as a health 
care clearinghouse. In some instances, this transaction may be used 
also to exchange enrollment and maintenance information between 
sponsors and health care providers or between health plans and health 
care providers.
    The NCPDP standard, which was developed to enhance the enrollment 
verification process for pharmaceutical claims, rather than for 
transmitting information between health plan and sponsor, is not being 
proposed for adoption in this rule. The NCPDP standard pertains to 
these specific uses and is therefore not suitable in its current form 
for the more general uses needed for the enrollment transaction.
    With the implementation of the ASC X12 834 for health care, 
sponsors would be able to transmit information on enrollment and 
maintenance using a single, electronic format; health plans would be 
required to accept only the standard transaction; neither sponsors nor 
health plans would have to continue to maintain and use multiple 
proprietary formats or resort to paper.
    Adoption of this standard would benefit sponsors, especially, by 
providing them the ability to convert to electronic transmission 
formats where paper is still being used today. Many of these sponsors 
already use X12 standards in their core business activities (for 
example, purchasing) unrelated to the provision of health care benefits 
to employees. The utility of this particular standard for health care 
transactions would be synergistic when considered in combination with 
the other standards in this proposed rule (for example, ASC X12 820) 
and other rules (PAYERID, national provider identifier) promulgated 
under HIPAA.
    In addition to being the only relevant standard for the enrollment 
and maintenance process designed for use by sponsors, the ANSI ASC X12 
834 met all of the 10 criteria deemed to be applicable in evaluating 
this potential standard.
    1. It will improve the efficiency of enrollment transactions by 
prescribing a single, standard format.
    2. It was designed to meet the needs of health care providers, 
health plans, and health care clearinghouses by virtue of its 
development within the ASC X12 consensus process, in which 
representatives of health care providers, health plans, and health care 
clearinghouses participate.
    3. It is consistent with the other X12 standards detailed in this 
proposed rule.
    4. Its development costs are relatively low, given the ASC X12 
development process; its implementation costs would be relatively low 
as it can be implemented along with a suite of X12 transaction sets, 
often with a single translator.
    5. It was developed and will be maintained by the ANSI-accredited 
standards setting organization ASC X12.
    6. It is ready for implementation, with the official implementation 
guide to which we refer in Addendum G to this proposed rule.
    7. It was designed to be technology neutral by ASC X12.
    8. Precise and unambiguous definitions for each data element in the 
transaction set are documented in the implementation guides.
    9. The transaction is designed to keep data collection requirements 
as low as is feasible.
    10. All X12 transactions, including the X12 834, are designed to 
make it easy to accommodate constantly changing business requirements 
through flexible data architecture and coding systems.
    iii. Uses of the ANSI ASC X12 834.
    Transaction data elements in the implementation guide for the ASC 
X12 834 are defined as either required or conditional, where the 
conditions are clearly stated. This transaction would be used to enroll 
and disenroll not only the subscriber, but also any covered dependents. 
In some instances, this would be an enhancement to enrollment 
information maintained by sponsors or health plans, compared with the 
common practice today of maintaining detailed records on the subscriber 
alone. In an increasingly value-conscious health care environment, 
detailed information on subscribers and covered dependents is necessary 
for the effective management of their health care utilization.
    Administrative and financial health care transactions such as the 
ASC X12 834 enrollment transaction may have

[[Page 25293]]

other, secondary uses that may be important to consider as well. For 
example, secondary uses of health care claims data are common and 
include analyses of health care utilization, quality, and cost. The ASC 
X12 834 enrollment transaction has been discussed (for example, by the 
NCVHS) as a means to collect demographic information on individuals for 
use by public health, State data organizations, and researchers. 
Typically, demographic data elements would be used in combination with 
information obtained from other health care transactions, such as 
health care claims and equivalent encounter transactions, and from 
other sources.
    Proponents of this approach and these uses have expressed their 
beliefs that the enrollment transaction includes patient demographic 
data elements and that this would provide more reliable data on patient 
demographics than are available currently from health care claims and 
encounter databases. Proponents also believe that the availability of 
demographic information is in jeopardy because the X12 837 health care 
claim transaction proposed elsewhere in this rule includes minimal 
patient demographic data elements. The use of this standard would be a 
change from current practice in many States where the health care claim 
is the vehicle for collecting such information. Some proponents also 
have indicated a desire to expand the number of demographic data 
elements contained in the ASC X12 834 enrollment transaction to serve 
these secondary uses.
    Opponents of this approach argue that the ASC X12 834 enrollment 
transaction is not a suitable vehicle for collecting demographic 
information for these secondary purposes. They also assert that such 
information would never be available on the uninsured and, since there 
is no obligation on the part of sponsors to adopt the electronic 
transactions, would be only intermittently available on the insured. 
They also state that, although some demographic elements are already 
contained in the ASC X12 834 enrollment transaction, no business need 
has been identified that would support the addition of other such data 
elements. Finally, the opponents argue that secondary uses, while 
legitimate, should not be allowed to subvert the primary purposes of 
these transactions nor the goal of administrative simplification.
    We welcome comments on the practical utility of the ASC X12 834 
enrollment transaction as a vehicle for collecting demographic 
information on individuals and its value as an adjunct to claims and 
encounter data in this regard.
    The data elements for this transaction, and other information, may 
be found in Addendum 5.
b. Requirement
    In Sec. 142.1502, we would specify the ASC X12 834 Benefit 
Enrollment and Maintenance (004010X095) as the standard for enrollment 
and disenrollment transactions. We would also specify the source of the 
implementation guide and incorporate it by reference.
    i. Health plans.
    In Sec. 142.1504, Requirements: Health plans, we would require 
health plans to use only the standard specified in Sec. 142.1502 for 
electronic enrollment and disenrollment transactions.
    ii. Health care clearinghouses.
    We would require in Sec. 142.1506 that each health care 
clearinghouse use the standard specified in Sec. 142.1502 for 
enrollment and disenrollment transactions.
     iii. Sponsors.
    There would be no requirement for sponsors to use the standard: 
they are not one of the entities subject to the requirements of HIPAA. 
However, to the extent a sponsor uses an electronic standard, it would 
benefit that sponsor to use the standard we adopt for the reasons 
discussed earlier. In addition, HIPAA contains no provisions that would 
prohibit a health plan requiring sponsors with which its conducts 
transactions electronically to use the adopted standard.
c. Implementation Guide and Source
    The implementation guide for the ASC X12N 834 (004010X095) is 
available at no cost from the Washington Publishing Company site on the 
World Wide Web at the following address: http://www.wpc-edi.com/hipaa/. 
The data definitions and description of data conditions may also be 
obtained from this website.
    Users without access to the Internet may purchase implementation 
guides from Washington Publishing Company directly. Washington 
Publishing Company, 806 W. Diamond Ave., Suite 400, Gaithersburg, MD, 
20878; telephone 301-590-9337; FAX: 301-869-9460.
6. Standard: Eligibility for a Health Plan (Subpart P)
[Please label any written comments or e-mailed comments about this 
section with the subject: Eligibility]
a. Background
    Often, health care providers may need to verify not only that a 
patient has health insurance coverage but also what specific benefits 
are included in that coverage. Having such information helps the health 
care provider to collect correct patient deductibles, co-insurance 
amounts, and co-payments and to provide an accurate bill for the 
patient and all pertinent health plans, including secondary payers.
    In addition, simple economics dictates that the out-of-pocket cost 
to the patient may affect treatment choices. The best case is when 
there are two equally effective treatment options and coverage is only 
available for one. More often, the question may be whether a particular 
treatment is covered or not. Here is an example: Jane Doe has cancer 
and a bone marrow transplant is the treatment of last resort. Since 
insurance coverage does not extend to ``experimental therapies,'' the 
question becomes: Does Jane's insurance cover a bone marrow transplant 
for her diagnosis? If she has leukemia, the treatment may be covered; 
if she has cervical cancer, it may not be. Whether Jane could afford to 
pay out-of-pocket for such a treatment could affect her treatment 
choice.
    The value of eligibility information is enhanced if it can be 
acquired quickly. Traditional methods of communication (that is, by 
phone or mail) are highly inefficient. Patients and health plans find 
it disturbing when the deductible and co-pays are not correctly 
applied.
    When insurance inquiries of this sort are transmitted 
electronically, health care providers can receive the information from 
the health plan almost immediately. However, in current practice, each 
health plan may require that the health care provider's request be in a 
preferred format, which often does not match the format required by any 
other health plan. This means that the health care provider must 
maintain the hardware and software capability to send multiple inquiry 
formats and receive multiple response formats. Because of this 
situation, adoption of electronic methods for inquiries has been 
inhibited, and reliance on paper forms or the telephone for such 
inquiries has continued.
i. Candidates for the Standard
    The HISB developed an inventory of health care information 
standards to be considered by the Secretary of HHS in the adoption of 
standards. The ANSI ASC X12N 270--Health Care Eligibility Benefit 
Inquiry and companion 271--Health Care Eligibility Benefit Response, 
the ASC X12N Interactive Health Care Eligibility/Benefit Inquiry 
(IHCEBI) and its companion the Interactive Health Care Eligibility/
Benefit Response

[[Page 25294]]

(IHCEBR), the NCPDP Telecommunications Standard Format, and the NCPDP 
Telecommunication Claim Standard for Pharmaceutical Professional 
Services are the standards available for the electronic exchange of 
patient eligibility and coverage information.
ii. Recommended Standard
    We propose to adopt the ANSI ASC X12N 270--Health Care Eligibility 
Benefit Inquiry and the companion ASC X12N 271--Health Care Eligibility 
Benefit Response as the standard for the eligibility for a health plan 
transaction.
    When evaluated against the criteria (discussed earlier) for 
choosing a national standard, the ASC X12 Transaction Sets 270/271 met 
the criteria more often than did the ASC X12 interactive or the NCPDP 
transactions. The ASC X12N 270/271 transaction set is supported by an 
accredited standards setting organization ASC X12 (criteria #5). By 
comparison with the alternatives, the ASC X12N 270/271 would have 
relatively low additional development and implementation costs and 
would be consistent with other standards in this proposed rule 
(criteria #4 and #3). The NCPDP standards, because they are specific to 
pharmacy transactions, were rejected because they would not meet the 
needs of the rest of the health care system (criteria #2), whereas the 
ASC X12N 270/271 would.
    The X12N subcommittee and its Workgroup 1, which is responsible for 
the eligibility transaction, recommended in June 1997 that the ASC X12N 
270/271 be adopted as the HIPAA standard (criteria #5).
    There are specific, technical reasons against adoption of the 
IHCEBI/IHCEBR at this time. The IHCEBI/IHCEBR is based on UNEDIFACT, 
not ASC X12N, syntax. Because of concurrent changes in UNEDIFACT design 
rules, the IHCEBI/IHCEBR is not a complete or consistent standard. It 
has not been classified by UNEDIFACT as ready to implement. In X12N, 
the current version of IHCEBI/IHCEBR is 3070, and we believe that 
current use is centered on a prior version (3051), which is not 
millennium compliant. The IHCEBI/IHCEBR transaction is not ready to be 
moved into version 4 (4010), as are the other transactions being 
recommended in this proposed rule. We also believe that current use is 
quite limited, and not consistent across users; in effect, current uses 
of this transaction have been implemented in proprietary format(s). For 
all these reasons, the ICHEBI/ICHEBR is neither technically ready nor 
stable and cannot be recommended as a standard at this time. Thus, the 
IHCEBI/IHCEBR would require higher additional development and 
implementation costs (criteria #4), and they would not be consistent or 
uniform with the other standards selected (criteria #3).
    If an interactive eligibility transaction standard were ratified by 
an accredited standards setting organization sometime in the future, 
then it could be considered for adoption as a HIPAA standard. However, 
at this time, we expect that any future standard for an interactive 
eligibility transaction is likely to differ substantially from the 
current IHCEBI/IHCEBR and the time to readiness could be substantial as 
well (criteria #6).
    The goal of administrative simplification, as expressed in the law, 
is to improve the efficiency and effectiveness of the health care 
system (criteria #1). Whereas it might seem that the interactive 
message would yield greater efficiencies in terms of time saved, 
similar efficiencies are available with the ASC X12N 270/271. In fact, 
the ASC X12N 270 can be used to submit a single eligibility inquiry 
electronically for a very quick turnaround 271 response. Response 
times, measured in seconds, would compare favorably to a true 
``interactive'' transaction and would be a substantial improvement over 
telephone inquiries or paper methods of eligibility determination.
    Transactions concerning eligibility for a health plan would be used 
only to verify the patient's eligibility and benefits; they would not 
provide a history of benefit use. The electronic exchange using these 
standards would occur usually between health care providers and health 
plans, but the standard would support electronic inquiry and response 
among other entities. In addition to uses by various health care 
providers (for example, hospitals, laboratories, and physicians), the 
ASC X12N 270/271 can be used by an insurance company, a health 
maintenance organization, a preferred provider organization, a health 
care purchaser, a professional review organization, a third-party 
administrator, vendors (for example, billing services), service bureaus 
(such as value-added networks), and government agencies (Medicare, 
Medicaid, and CHAMPUS).
    The eligibility transaction is designed to be used for simple 
status requests as well as more complex requests that may be related to 
specific clinical procedures. General requests might include queries 
for: all benefits and coverage conditions, eligibility status (whether 
the patient is active in the health plan), maximum benefits (policy 
limits), exclusions, in-plan/out-of-plan benefits, coordination of 
benefits information, deductibles, and copayments. Specific requests 
might include procedure coverage dates; procedure coverage maximum; 
amounts for deductible, co-insurance, co-payment, or patient 
responsibility; coverage limitations; and noncovered amounts.
    Another part 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 to designate a primary care 
physician or to alert a hospital about forthcoming admissions. We are 
not recommending this use of the ASC X12N 270/271 at this time because 
the roster implementation guide is not millennium compliant and the 
standards development process for the implementation guide is not 
completed. After the standards development process for the roster 
implementation guide is completed, it may be considered for adoption as 
a national standard.
    The data elements for this transaction, and other information, may 
be found in Addendum 6.
b. Requirements
    i. Health plans.
    In Sec. 142.1604, Requirements: Health plans, we would require 
health plans to use only the standard specified in Sec. 142.1602 for 
electronic eligibility transactions.
    ii. Health care clearinghouses.
    We would require in Sec. 142.1606 that each health care 
clearinghouse use the standard specified in Sec. 142.1602 for 
eligibility transactions.
    iii. Health care providers.
    In Sec. 142.1608, Requirements: Health care providers, we would 
require each health care provider that transmits any health plan 
eligibility transactions electronically to use the standard specified 
in Sec. 142.1602 for those transactions.
c. Implementation Guide and Source
    The implementation guide is available for the ASC X12N 270/271 
(004010X092) at no cost from the Washington Publishing Company site on 
the World Wide Web at the following address: <a href="http://www.wpc-edi.com/
hipaa/">http://www.wpc-edi.com/
hipaa/</a>. The data definitions and

[[Page 25295]]

description of data conditions may also be obtained from this website.
    Users without access to the Internet may purchase implementation 
guides from Washington Publishing Company directly. Washington 
Publishing Company, 806 W. Diamond Ave., Suite 400, Gaithersburg, MD, 
20878; telephone 301-590-9337; FAX: 301-869-9460.
7. Standard: Health Plan Premium Payment (Subpart Q)
[Please label any written comments or e-mailed comments about this 
section with the subject: Premium]
a. Background
    Electronic payment methods have become commonplace for consumers 
who pay their monthly mortgage, power, or telephone bills 
electronically. Yet, electronic payment of health insurance premiums by 
employers is not common at all.
    Adoption of a standard for electronic payment of health plan 
premiums would benefit employers and other sponsors, especially, by 
providing the opportunity to convert to a single electronic 
transmission format where paper forms and premium payment formats may 
vary from health plan to health plan. Many of these sponsors already 
use X12 standards in their core business activities (for example, 
purchasing) unrelated to the provision of health care benefits to 
employees. Federal and State governments when acting as employers and 
other government agencies that transmit premium payments to outside 
organizations (for example, State Medicaid agencies that pay premiums 
to outside organizations such as managed care organizations) would also 
benefit from these electronic transactions.
    i. Candidates for Standard.
    According to the inventory conducted for HHS by the HISB, only one 
standard developed and maintained by a standards developing 
organization for health plan premium payment transaction exists. It is 
the ASC X12 820--Payment Order/Remittance Advice.
    ii. Recommended Standard.
    The standard we are proposing to adopt for health plan premium 
payment transactions is the ASC X12 820--Payment Order/Remittance 
Advice. If we adopt the ASC X12 820, health plans would be able to 
transmit premium payments either as a summary payment or with 
individual payment detail, or as payment amount and adjustment amount, 
using a single, electronic format. Health plans would be required to 
accept the standard transaction as the electronic transmission; neither 
sponsors nor health plans would have to continue to maintain and use 
multiple proprietary premium payment formats or resort to paper.
    Although the premium order/remittance advice (ASC X12 820), used 
for health plan premium payments, can be paired with the ASC X12N 811--
Consolidated Service Invoice/Statement, which is used for health plan 
premium billing, our proposal and the focus of the statute is on a 
standard only for health plan premium payments.
    In addition to being the only relevant standard designed for use by 
sponsors, the ANSI ASC X12 820 met 9 of the 10 criteria deemed to be 
applicable in evaluating this potential standard. It would improve the 
efficiency of premium payment transactions by prescribing a single, 
standard format. It was designed to meet the needs of health care 
providers, health plans, and health care clearinghouses by virtue of 
its development within the ASC X12 consensus process, in which 
representatives of health care providers, health plans, and health care 
clearinghouses participate. It is consistent with the other ASC X12 
standards detailed in this proposed rule. Its development costs are 
relatively low, given the X12 development process; its implementation 
costs would be relatively low as it can be implemented along with a 
suite of X12 transaction sets, often with a single translator. It was 
developed and will be maintained by the ANSI-accredited standards 
setting organization X12. It is ready for implementation, with the 
official implementation guide to which we refer in Addendum 7 to this 
proposed rule. It was designed to be technology neutral by X12. Precise 
and unambiguous definitions for each data element in the transaction 
set are documented in the implementation guides.
    The ANSI ASC X12 820--Payment Order/Remittance Advice is currently 
used in applications other than health care. However, it is currently 
not in widespread use in the health insurance industry because most 
health plan premium payments are not done electronically. However, some 
large organizations are using the ASC X12 820 to meet other business 
requirements, such as automated purchasing. The ASC X12 820 is used in 
the health care industry for premium payment information exchanged 
between the sponsor and the health plan; it should not be confused with 
the ASC X12 834, which includes additional nonpremium payment 
information. The ASC X12 820 is not intended to be used to carry 
enrollment or other eligibility information.
    The data elements for this transaction, and other information, may 
be found in Addendum 7.
b. Requirements
    In Sec. 142.1702, we would specify the following as the standard 
for health plan premium payment: ASC X12 820--Payment Order/Remittance 
Advice (004010X061). We would specify where to find the implementation 
guide and incorporate it by reference.
    i. Health plans.
    In Sec. 142.1704, Requirements: Health plans, we would require 
health plans to accept only the standard specified in Sec. 142.1702 for 
electronic health plan premium payments.
    ii. Health care clearinghouses.
    We would require in Sec. 142.1706 that each health care 
clearinghouse use the standards specified in Sec. 142.1702 for health 
plan premium payment transactions.
    iii. Sponsors.
    There would be no requirement for sponsors to use the standard: 
they are not one of the entities subject to the requirements of HIPAA. 
However, to the extent a sponsor uses an electronic standard, it would 
benefit that sponsor to use the standard we adopt for the reasons 
discussed earlier. In addition, HIPAA contains no provisions that would 
prohibit a health plan requiring sponsors with which its conducts 
transactions electronically to use the adopted standard.
c. Implementation Guide and Source
    The implementation guide for this transaction is the ASC X12N 820--
Payroll Deducted and Other Group Premium Payment for Insurance Products 
(004010X061).
    The implementation guide is available at no cost from the 
Washington Publishing Company site on the World Wide Web at the 
following address: http://www.wpc-edi.com/hipaa/.
    Users without access to the Internet may purchase implementation 
guides from Washington Publishing Company directly. Washington 
Publishing Company, 806 W. Diamond Ave., Suite 400, Gaithersburg, MD, 
20878; telephone 301-590-9337; FAX: 301-869-9460.
8. Standard: Referral Certification and Authorization (Subpart R)
[Please label any written comments or e-mailed comments about this 
section with the subject: Referral]
a. Background
    Increasingly, the delivery of health care is focused on achieving 
greater

[[Page 25296]]

value from each health care dollar, and rigorous monitoring of health 
care utilization has become a common method adopted by health plans for 
achieving their value goals. Traditional methods of communication 
between health care providers and health plans or their designates, 
which rely on a combination of paper forms and telephone calls, are 
neither efficient nor cost effective and may impede the delivery of 
care. The burden and inefficiencies of these communications could be 
reduced by the adoption of standardized and electronic methods for 
making the requests and receiving responses.
    i. Candidates for Standard.
    According to the inventory of standards produced by the HISB for 
HHS, there is only one standard available for referral certification 
and authority. It is the ASC X12N 278, Health Care Services Review 
Information.
    ii. Recommended Standard.
    The ANSI ASC X12N 278--Health Care Services Review Information is 
the standard proposed for electronic exchange of requests and responses 
between health care providers and review organizations.
    These exchanges of information can be initiated by either the 
health care provider or the health plan. The health care provider 
requests from a designated review entity authorization or certification 
for a patient to receive a particular health care service. In turn, the 
review entity receives and responds to the health care provider's 
request. In addition to direct electronic inquiry and response, the ASC 
X12N 278 can be used in connection with point of service terminals.
    Many different types of organizations may act as a review entity in 
such an exchange. These include health plans, insurance companies, 
health maintenance organizations, preferred provider organizations, 
health care purchasers, managed care organizations providing coverage 
to Medicare and Medicaid beneficiaries, professional review 
organizations, other health care providers, and benefit management 
organizations, to name a few.
    These requests and responses may pertain to many different health 
care events, including reviews for: treatment authorization, specialty 
referrals, pre-admission certifications, certifications for health care 
services (such as home health and ambulance), extension of 
certifications, and certification appeals.
    As with all the other ASC X12 transactions being proposed in this 
rule, the ASC X12N 278 was developed with widespread input from health 
care industry representatives in a consensus process taking into 
account business needs. Further, the standard is fully compatible with 
the other ASC X12 standards and can be translated to and from native 
application systems using off-the-shelf software (commonly referred to 
as ``translators'') that is readily available and used by all 
industries utilizing ASC X12 standards.
    The data elements for this transaction, and other information, may 
be found in Addendum 8.
b. Requirements
    In Sec. 142.1802, we would specify the following as the standard 
for referral certifications and authorizations: ASC X12N 278--Request 
for Review and Response (004010X094). We would specify where to find 
the implementation guide and incorporate it by reference.
    i. Health plans.
    In Sec. 142.1804, Requirements: Health plans, we would require 
health plans to accept and transmit only the standard specified in 
Sec. 142.1802 for electronic referral certifications and 
authorizations.
    ii. Health care clearinghouses.
    We would require in Sec. 142.1806 that each health care 
clearinghouse use the standard specified in Sec. 142.1802 for referral 
certifications and authorizations.
    iii. Health care providers.
    In Sec. 142.1808, Requirements: Health care providers, we would 
require each health care provider that transmits referral 
certifications and authorizations electronically to use the standard 
specified in Sec. 142.1802 for the transactions.
c. Implementation Guide and Source
    The implementation guide for the ASC X12N 278 (004010X094) is 
available at no cost from the Washington Publishing Company site on the 
World Wide Web at the following address: http://www.wpc-edi.com/hipaa/.
    Users without access to the Internet may purchase implementation 
guides from Washington Publishing Company directly. Washington 
Publishing Company, 806 W. Diamond Ave., Suite 400, Gaithersburg, MD, 
20878; telephone 301-590-9337; FAX: 301-869-9460.
9. Standard: First Report of Injury
[Please label any written comments or e-mailed comments about this 
section with the subject: Injury]
Background
    ``First report of injury'' is not a general term or transaction in 
the health care insurance industry. Upon investigation, we found that 
the property and casualty insurance industry, among whose lines of 
business is workers compensation insurance, had developed a standard 
transaction entitled ``Report of Injury, Illness or Incident'' (ASC 
X12N 148). This transaction set was developed within ASC X12N to 
encompass more than 30 functions and exchanges that occur among the 
numerous parties to a workers compensation claim. The transaction can 
be used by an employer, first, to report an employee injury or illness 
to the State government agency that administers workers compensation 
and, second, to report to the employer's workers compensation insurance 
carrier so that a claim can be established to cover the employee's 
losses (income, health care, disability). When the employer is the 
Federal government, the transaction is used to report to the Department 
of Labor's Office of Workers Compensation Programs. In a few States, 
the transaction can also be used by health care providers to report an 
employee's work-related injury to employers and/or the employer's 
workers compensation insurance carrier. The transaction can be used by 
State agencies responsible for monitoring the disposition of a workers 
compensation claim. Other uses include summary reporting of employee 
injuries and illness to State workers compensation boards, commissions, 
or agencies; the Federal Bureau of Labor Statistics; the Federal 
Occupational Safety and Health Administration; and the Federal 
Environmental Protection Agency.
    The current, approved version of this transaction is 3070, which is 
not millennium compliant. There is no approved implementation guide for 
version 4010, which would be millennium compliant. The ASC X12N 
workgroup is developing a version 4010 or higher implementation guide 
and data dictionary. The workgroup hopes to secure ASC X12N approval 
for its revised standard and implementation guide in the spring of 
1998. Current workgroup planning is for a single implementation guide 
that covers all of the business uses to which we refer above.
    Recommendation:
    We do not recommend that the ASC X12N 148--Report of Injury, 
Illness or Incident be adopted at this time, for the following reasons:
    a. There is no millennium-compliant version of an implementation 
guide for this transaction.
    b. There is no complete data dictionary for this transaction.

[[Page 25297]]

    c. The implementation guide under development covers more business 
requirements and functions than the ``first report of injury'' 
specified in the statute.
    d. Consultation with the transaction's extensive user community is 
necessary to establish a consensus regarding the scope of the 
transaction set, and this is not possible in the time available to the 
Secretary for promulgating a final regulation.
    e. An alternative to the ASC X12N 148 has been brought to our 
attention and must be evaluated.
    The alternative EDI format is that developed and maintained by the 
International Association of Industrial Accident Boards and Commissions 
(IAIABC). The IAIABC EDI format was not identified in the ANSI HISB 
inventory of standards developed for HHS because the IAIABC is not an 
ANSI-accredited standards setting organization.
    Under the law, a standard adopted under the administrative 
simplification provisions of HIPAA is required to be ``a standard that 
has been developed, adopted, or modified by a standard setting 
organization'' (section 1172(c) of the Act) (if a standard exists). The 
Secretary may adopt a different standard if it would substantially 
reduce administrative costs to health care providers and health plans 
when compared to the alternatives (section 1172(c)(2)(A)).
    Accordingly, the IAIABC EDI format must be evaluated before a 
national standard for first report of injury transactions is adopted 
because it is reported to be widely used. The IAIABC will be requested 
to submit documentation so that its first report of injury format can 
be evaluated according to the ten criteria applied to all other 
standards.
    In assessing the utility of this alternative standard, we will 
follow the Guiding Principles for selecting a standard to evaluate the 
IAIABC EDI format against that developed and maintained by ANSI ASC 
X12N. The following questions about the IAIABC standard will be of 
particular importance:
    a. To what extent is this format widely accepted and used by 
organizations performing these transactions?
    b. Is this format millennium-compliant?
    c. Does this standard meet the requirements set forth in the 
Administrative Simplification provisions of HIPAA for improving the 
efficiency and effectiveness of the health care system?
    d. Is this a format developed, maintained, or modified by a 
standard setting organization as specified in Section 1171 (8) or does 
it meet the exceptions specified in Section 1172 (c)(2) of the Act?
    We do not recommend that the IAIABC format be adopted at this time. 
We have asked that the IAIABC provide documentation for their format.
    In view of these facts, HHS will take the following actions with 
regard to adopting a standard for ``first report of injury'':
    a. Continue to monitor the progress of the ASC X12N subcommittee 
toward development of a final, complete, millennium-compliant standard, 
implementation guide, and data dictionary for this transaction.
    b. Request that ASC X12N review the ASC X12N 148 to determine 
whether all of its broad functionality should be included in a standard 
to be adopted under HIPAA authority or whether the scope of the 
transaction should be limited by dividing the functions into separate 
implementation guides.
    c. Review and evaluate documentation from the IAIABC on its format 
so that it can be evaluated according to the ten criteria used to 
evaluate candidate standards and in relation to the ASC X12N 148 as 
described above.
    d. After the ASC X12N subcommittee has completed its standard 
setting role and approved a 4010 version or higher implementation guide 
and data definitions for the ASC X12N 148 and after analysis of the 
IAIABC alternative standard, issue a subsequent proposed rule 
promulgating a standard for ``first report of injury''.

III. Implementation of the Transaction Standards and Code Sets

A. Compliance Testing

    We have identified three levels of testing that must be addressed 
in connection with the adoption and implementation of the standards we 
are proposing and their required code sets:
    Level 1--Developmental Testing--This is the testing done by the 
standards setting organization during the development process. The 
conditions for, and results of, this testing are made public by the 
relevant standards bodies, and are available at the following Internet 
web site:

http://www.disa.org

    The information on the web site is provided at the discretion of 
the standards setting organization and could, among other things, refer 
to pilot, limited, or large-scale production if appropriate. 
Information regarding code set testing will also be posted to a 
website. This website will be advertised on the HCFA home page.
    Level 2--Validation Testing--This is testing of sample transactions 
to see whether they are being written correctly. We expect that private 
industry will provide commercial testing at this level. This level of 
testing would give the participants a sense of whether they are meeting 
technical specifications of structure and syntax for a transaction, but 
it may not necessarily test for valid data. This type of testing would 
inform individuals that the transaction probably meets the 
specifications. These edits would be less rigorous than those that 
might be applied by a health plan before payment (in the case of a 
claim) or by a health care provider prior to posting (in the case of a 
health care claim payment/advice). The test conditions and results from 
this level are generally shared only between the parties involved.
    Level 3--Production Testing--This tests a transaction from a sender 
through the receiver's system. The test information is exposed to all 
of the edits, lookups, and checks that the transaction would undergo in 
a production situation. The test conditions and results from this level 
are generally shared only between the parties involved.
    Pilot production--Billions of dollars change hands each year as a 
result of health care claims processing alone. For that reason, we 
believe the industry should sponsor pilot production projects to test 
transaction standards that are not currently in full production prior 
to the effective date for adoption. Pilot production tests are not 
necessary for the NCPDP retail pharmacy claim since it is already in 
widespread use. On the other hand, some of the ASC X12N implementations 
have not yet been placed in general production. We believe that pilot 
production results should be posted on a website and show information 
of general interest to potential users. The information given is at the 
discretion of the entities conducting the pilot and might contain 
information regarding the number of claims processed, the identity of 
the entities participating in the pilot, and the name, telephone number 
or e-mail address of an individual willing to answer questions from the 
public.
    It would be useful to all participants if pilot production projects 
and the results were posted to a web site for all transactions. For the 
claim and equivalent encounter transactions, we believe that posting 
pilot production projects and results to a web site must be mandatory.

[[Page 25298]]

B. Enforcement

    Failure to comply with standards may well 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 one 
requirement.
    We are not proposing any enforcement procedures at this time, but 
we will do so in a future Federal Regulations document, once the 
industry has some experience with using the standards.
    We are at this time, however, soliciting input on appropriate 
mechanisms to permit independent assessment of compliance. We are 
particularly interested in input from those engaging in health care EDI 
as well as from independent certification and auditing organizations 
addressing issues of documentary evidence of steps taken for 
compliance; need for/desirability of independent verification, 
validation, and testing of systems changes; and certifications required 
for off-the-shelf products used to meet the requirements of this 
regulation.

IV. New and Revised Standards

A. New Standards

    To encourage innovation and promote development, we intend to 
develop a process that would allow an organization to request a 
replacement to any adopted standard or standards.
    An organization could request a replacement to an adopted standard 
by requesting a waiver from the Secretary of HHS to test a new 
standard. The organization, at a minimum, must demonstrate that the new 
standard clearly offers an improvement over the adopted standard. If 
the organization presents sufficient documentation that supports 
testing of a new standard, we want to be able to grant the organization 
a temporary waiver to test it while remaining in compliance with the 
law. We do not intend to establish a process that would allow 
organizations to request waivers as a tool to avoid using any adopted 
standard.
    We would welcome comments on the following: (1) How we should 
establish this process, (2) the length of time a proposed standard 
should be tested before we decide whether to adopt it, and (3) other 
issues and recommendations we should consider in developing this 
process.
    Following is one possible process:
    <bullet> Any organization that wishes to replace an adopted 
standard must submit its waiver request to an HHS evaluation committee 
(not currently established or defined). The organization must do the 
following for each standard it wishes to replace:
    + Provide a detailed explanation, no more than 10 pages in length, 
of how the replacement would be a clear improvement over the current 
standard in terms of the principles listed in section I.D., Process for 
developing national standards, of this preamble.
    + Provide specifications and technical capabilities on the new 
standard, including any additional system requirements.
    + 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 care plans and health care providers expected to be 
involved in the test, geographical areas, and beginning and end dates 
of the test.
    <bullet> The committee's evaluation would, at a minimum, be based 
on the following:
    + A cost-benefit analysis.
    + An assessment of whether the proposed replacement demonstrates a 
clear improvement to an existing standard.
    + The extent and length of time of the waiver.
    <bullet> The evaluation committee would inform the organization 
requesting the waiver within 30 working days of the committee's 
decision on the waiver request. If the committee decides to grant a 
waiver, the notification may include the following:
    + Committee comments such as the following:

    --The length of time for which the waiver applies if it differs 
from the waiver request.
    --The sites the committee believes are appropriate for testing if 
they differ from the waiver request.
    --Any pertinent information regarding the conditions of an approved 
waiver.

    <bullet> Any organization that receives a waiver would be required 
to submit a report containing the results of the study, no later than 3 
months after the study is completed.
    <bullet> The committee would evaluate the report and determine 
whether the proposed new standard meets the 10 guiding principles and 
whether the advantages of a new standard would significantly outweigh 
the disadvantages of implementing it and make a recommendation to the 
Secretary.

B. Revised Standards

    We recognize the very significant contributions that the 
traditional content committees (the NUCC, the NUBC, the ADA, and the 
National Council for Prescription Drug Programs) have made to health 
care transaction content over the years and, in particular, the work 
they contributed to the content of the standards proposed in this 
proposed rule. Other Federal and private entities (the National Center 
for Health Statistics, the Health Care Financing Administration, the 
AMA, and the ADA) have developed and maintained the medical data code 
sets proposed as standards in this proposed rule. In a letter dated 
June 10, 1997, WEDI recommended that the NUBC, NUCC and ADA be 
recognized as the appropriate organizations to specify data content. We 
expect that these current committees would continue to play an 
important role in maintenance of data content for standard health care 
transactions. The organizations assigned responsibility for maintenance 
of data content for standard health care transactions will work with 
X12N data maintenance committees, ensuring that implementation 
documentation is updated in a consistent and timely fashion.
    We intend that the private sector, with public sector involvement, 
continue to have responsibility for defining the data element content 
of the administrative transactions. Both Federal agencies and private 
organizations will continue to be responsible for maintaining medical 
data code sets. The current data content committees are focused on 
transactions that involve health care providers and health plans. There 
may be some organizations that represent employers or other sponsors 
and health plans and are interested in assuming the burden of 
maintenance of the data content standards for the X12 820 and 834.
    We propose to designate content committees in the final rule and to 
specify the ongoing activities of these content committees pertaining 
to the data maintenance of all X12N standards identified in this rule, 
as well as attachments. All approved changes, not including medical 
code sets, would need to fit into the appropriate ASC X12N 
implementation guide(s) and receive ASC X12N approval, with the 
exception of the NCPDP standard. The NCPDP would continue to operate as 
currently for data content.
    It is important that data content revisions be made timely in this 
new standards environment. The Secretary of HHS may not revise any 
standard more

[[Page 25299]]

frequently than once a year and must permit no fewer than 180 days for 
implementation for all participants after adopting a revised standard. 
New values could be added to the code sets for certain data elements in 
transaction standards more frequently than once a year. For example, 
alpha-numeric HCPCS and NDC, two of the proposed standard code sets for 
medical data, now have mechanisms for ongoing addition to new codes as 
needed to reflect new health services and new drugs. Such ongoing 
update mechanisms would continue to be needed in the year 2000 and 
beyond.
    The private sector organizations charged with data element content 
maintenance would have to ensure that the revised standard contains the 
most recent data maintenance items that have been brought to them and 
that those new data requirements are adequately documented and 
communicated to the public. We believe that, at minimum, the data 
maintenance documentation needs to include the data name, data 
definition, the status of the data name (that is, required or 
conditional), written conditions regarding the circumstances under 
which the data would have to be supplied, a rationale for the new or 
revised data item, and its placement in an implementation guide. We 
believe that any data request approved by a body three or more months 
prior to the adoption of a new or revised standard would have to be 
included in that new standard implementation, assuming that no major 
format restructuring would have to be done. (A new data element, code, 
or segment would not constitute major restructuring.)
    We believe that any body with responsibility for maintaining a 
standard under this proposed rule must allow public access to their 
decision making processes. We plan to engage standards setting 
organizations and other organizations responsible for maintenance of 
data element content and standard code sets to establish a process that 
will enable timely standards development/updates with appropriate 
industry input. One approach may be as follows:
    <bullet> Each of the data maintenance bodies has biannual meetings 
with the public welcome to attend and participate without payment of 
fees.
    + These public meetings are announced to the broadest possible 
audience, at minimum by means of a website. The announcements of the 
meetings may also be available via widely read publications, such as 
the Commerce Business Daily or the Federal Register.
    + Annual public meeting schedules are posted on a website not later 
than 90 days after the effective date of the final rule, and annually 
on that date thereafter.
    + The data maintenance body establishes a central contact (name and 
post office and e-mail addresses) to which the public could submit 
correspondence (such as agenda items or data requests).
    + During these two open meetings, the public has the opportunity to 
voice concerns and suggest changes.
    + Each data maintenance body drafts procedures for the public to 
follow in regard to its meeting protocols.
    <bullet> Each data maintenance body drafts procedures for the 
public to submit requests for data or for revisions to the standard. 
These draft procedures are easy to use and are adequately communicated 
to the public.
    <bullet> Each designated data maintenance body is also responsible 
for communicating actions taken on requests to the requestor and the 
public, in addition to communicating any changes made to a standard. 
This may be done via mail, e-mail, publications, or newsletters but, at 
a minimum, are published on the website. (We believe the Internet is 
the most cost effective way of communicating this type of information.)
    <bullet> Each data maintenance body responds definitively to each 
request it receives no later than three months after the request is 
received.
    An alternative approach would be to require an organization which 
desired to be designated by the Secretary as the official data content 
maintenance body for a particular transaction to meet the ANSI criteria 
for due process found at http://www.ansi.org/proc__1.html. Not only 
would these criteria meet the intent of HIPAA to advocate an open, 
balanced, consensus process, but once an organization met these 
criteria, it would be able to apply for ANSI accreditation if it so 
desired.
    It is not our intention to increase any current burdens on data 
maintenance bodies. Our concern is that the public have a voice in the 
data maintenance process and that changes to a standard be timely and 
adequately communicated to the industry. We welcome any comments 
regarding the approach outlined above and recommendations for data 
maintenance committees for each X12N transaction standard identified in 
this rule.
    We also solicit comments on the appropriateness of ongoing Federal 
oversight/monitoring of maintenance processes and procedures.

V. Collection of Information Requirements

    Under the Paperwork Reduction Act of 1995 (PRA), we are required to 
provide 60-day notice in the Federal Register and solicit public 
comment before a collection of information requirement is 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 Paperwork Reduction Act 
of 1995 requires that we solicit comment on the following issues:
    <bullet> The need for the information collection and its usefulness 
in carrying out the proper functions of our agency.
    <bullet> The accuracy of our estimate of the information collection 
burden.
    <bullet> The quality, utility, and clarity of the information to be 
collected.
    <bullet> Recommendations to minimize the information collection 
burden on the affected public, including automated collection 
techniques.

Subpart K--Health Claims or Equivalent Encounter Information Standard

142.1104  Requirements: Health plans.
142.1108  Requirements: Health care providers.

Subpart L--Health Care Payment and Remittance Advice

142.1204  Requirements: Health plans.

Subpart M--Coordination of Benefits

142.1304  Requirements: Health plans.

Subpart N--Health Claims Status

142.1404  Requirements: Health plans.
142.1408  Requirements: Health care providers.

Subpart O--Enrollment and Disenrollment in a Health Plan

142.1504  Requirements: Health plans.

Subpart P--Eligibility for a Health Plan

142.1604  Requirements: Health plans.
142.1608  Requirements: Health care providers.

Subpart Q--Health Plan Premium Payments

142.1704  Requirements: Health plans.

Subpart R--Referral Certification and Authorization

142.1804  Requirements: Health plans.
142.1808  Requirements: Health care providers.

    Discussion: In summary, each of the sections identified above 
require health care plans, and/or health care providers to use any 
given standard proposed in this regulation for all electronically 
transmitted standard transactions that require it on and after the 
effective date given to it.
    The emerging and increasing use of health care EDI standards and

[[Page 25300]]

transactions raises the issue of the applicability of the PRA. The 
question arises whether a regulation that adopts an EDI standard used 
to exchange certain information constitutes an information collection 
subject to the PRA. However, for the purpose of soliciting useful 
public comment we provide the following burden estimates.
    In particular, the initial burden on the estimated 4 million health 
plans and 1.2 million health care providers to modify their current 
computer systems software would be 10 hours/$300 per entity, for a 
total burden of 52 million hours/$1.56 billion. While this burden 
estimate may appear low, on average, we believe it to be accurate. This 
is based on the assumption that these and the other burden calculations 
associated with the HIPAA administrative simplification systems 
modifications may overlap. This average also takes into consideration 
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) modifications may be performed in an aggregate manner 
during the course of routine business and/or; (4) modifications may be 
made by contractors such as practice management vendors, in a single 
effort for a multitude of affected entities.
    We solicit comment on whether the requirements to which we refer 
above constitute a one-time or an ongoing, usual and customary business 
practice as defined 5 CFR 1320.3(b)(2), the Paperwork Reduction 
regulations.
    We invite public comment on the issues discussed above. If you 
comment on these information collection and recordkeeping requirements, 
please e-mail comments to JB<a href="/cdn-cgi/l/email-protection#1762657c7226577f74717639707861"><span class="__cf_email__" data-cfemail="2b5e59404e1a6b43484d4a054c445d">[email protected]</span></a> (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: John Burke 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. Response to Comments

    Because of the large number of items of correspondence we normally 
receive on Federal Register documents published for comment, we are not 
able to acknowledge or respond to them individually. We will consider 
all comments we receive by the date and time specified in the DATES 
section of this preamble, and, if we proceed with a subsequent 
document, we will respond to comments in the preamble to that document.

VII. Impact Analysis

    As the effect of any one standard is affected by the implementation 
of other standards, it can be misleading to discuss the impact of one 
standard by itself. Therefore, we did an impact analysis on the total 
effect of all the standards in the proposed rule concerning the 
national provider identifier (HCFA-0045-P), which can be found 
elsewhere in this Federal Register.
    We intend to publish in each proposed rule an impact analysis that 
is specific to the standard or standards proposed in that rule, but the 
impact analysis will assess only the relative cost impact of 
implementing a given standard. Thus, the following discussion contains 
the impact analysis for each of the transactions proposed in this rule. 
As stated in the general impact analysis in HCFA-0045-P, we do not 
intend to associate costs and savings to specific standards.
    Although we cannot determine the specific economic impact of the 
standards being proposed in this rule (and individually each standard 
may not have a significant impact), the overall impact analysis makes 
clear that, collectively, all the standards will have a significant 
impact of over $100 million on the economy. Also, while each standard 
may not have a significant impact on a substantial number of small 
entities, the combined effects of all the proposed standards may have a 
significant effect on a substantial number of small entities. 
Therefore, the following impact analysis should be read in conjunction 
with the overall impact analysis.
    In accordance with the provisions of Executive Order 12866, this 
proposed rule was reviewed by the Office of Management and Budget.

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:
    <bullet> 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.
    <bullet> Meet the needs of the health data standards user 
community, particularly health care providers, health plans, and health 
care clearinghouses. This principle supports the regulatory goal of 
cost-effectiveness.
    <bullet> Be consistent and uniform with the other HIPAA standards 
(that is, their data element definitions and codes and their privacy 
and security requirements) and, secondarily, with other private and 
public sector health data standards. This principle supports the 
regulatory goals of consistency and avoidance of incompatibility, and 
it establishes a performance objective for the standard.
    <bullet>  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.
    <bullet> Be supported by an ANSI-accredited standards developing 
organization or other private or public organization that would ensure 
continuity and efficient updating of the standard over time. This 
principle supports the regulatory goal of predictability.
    <bullet> Have timely development, testing, implementation, and 
updating procedures to achieve administrative simplification benefits 
faster. This principle establishes a performance objective for the 
standard.
    <bullet> 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.
    <bullet> Be precise and unambiguous but as simple as possible. This 
principle supports the regulatory goals of predictability and 
simplicity.
    <bullet> 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.
    <bullet> Incorporate flexibility to adapt more easily to changes in 
the health care infrastructure (such as new services, organizations, 
and provider types) and information technology. This principle

[[Page 25301]]

supports the regulatory goals of flexibility and encouragement of 
innovation.

General

    The effect of implementing standards on health care clearinghouses 
is basically the same for all the standards. Currently, health care 
clearinghouses receive and transmit various transactions using a 
variety of formats. The implementation of standard transactions may 
reduce the variability in the data received from some groups, such as 
health care providers. The implementation of any standard will require 
some one-time changes to health care clearinghouse systems. Health care 
clearinghouses should be able to make modifications that meet the 
deadlines specified in the legislation, but some temporary disruption 
of processing could result. Once the transition is made, health care 
clearinghouses may have less ongoing system maintenance. Costs may vary 
according to the complexity of the standard, but costs may be recouped 
from customers.
    Health care clearinghouses would face impacts (both positive and 
negative) similar to those experienced by health plans (which we 
discuss in more detail in the discussions for specific transactions). 
However, implementation would likely be more complex, because health 
care clearinghouses deal with many health care providers and health 
plans and may have to accommodate additional nonstandard formats (in 
addition to those formats they currently support), as well as standards 
we adopt. (The additional nonstandard formats would be from those 
health care providers that choose to stop submitting directly to an 
insurer and submit through a health care clearinghouse.) This would 
also mean increased business for the health care clearinghouse.
    Converting to any standard will result in one-time conversion costs 
for health care providers, health care clearinghouses, and health plans 
as well. Some health care providers and health plans would incur those 
costs directly and others may incur them in the form of a fee from 
health care clearinghouses or, for health care providers, other agents.
    Each standard compares favorably with typical ASC X12 standards in 
terms of complexity and ease of use. No one in the ASC X12 subcommittee 
assumes that every entity that sends or receives an ASC X12 transaction 
has reprogrammed its information systems in order to do so. Every 
transaction is designed, and the technical review process assures, that 
it will be compatible with the commercial, off-the-shelf translator 
programs that are widely available in the United States. These 
translators significantly reduce the cost and complexity of achieving 
and maintaining compliance with all ASC X12 standards. Universal 
communication with all parties in the health care industry is thus 
assured.
    Specific technology limitations of existing systems could affect 
the complexity of conversion. Also, some existing health care provider 
systems may not have the resources to house a translator to convert 
from one format to another.
    Following is the portion of the impact analysis that relates 
specifically to the standards that are the subject of this regulation.

A. 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. Those that create and 
process administrative transactions must implement the standard codes 
according to the official implementation guides designated for each 
coding system and each transaction. Those that receive standard 
electronic administrative transactions must be able to receive and 
process all standard codes (and modifiers, in the cases of HCPCS and 
CPT), 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 all de facto standards 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 on 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 the HIPAA code set standards 
become effective, these health plans would have 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.
    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 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.

[[Page 25302]]

B. 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 the principles and there are no known 
options for a standard retail pharmacy claim transaction.
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 providers use this 
standard for claims; it is used less for non-Medicare claims.)
    There would be a potential for disruption of claims processes and 
timely payments during a particular health plan's transition to the ASC 
X12N 837. Some health care providers could react adversely to the 
increased cost and revert to submitting hard copy claims.
    After implementation, health care providers would no longer have to 
keep track of and use different electronic formats for different 
insurers. This would simplify provider billing systems and processes 
and reduce administrative expenses.
    Health plans would 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) as long 
as they meet the deadlines specified in the legislation. Although the 
costs of implementing the ASC X12N 837 are generally one-time costs 
related to conversion, the systems upgrades for some smaller health 
care providers, health plans, and health care clearinghouses may be 
cost prohibitive. Health care providers and health plans have the 
option of using a clearinghouse.
    The cost may also cause some smaller health plans that have trading 
partner agreements today to discontinue that partnership. That same 
audience of health care providers, health care clearinghouses, and 
health plans could conceivably be forced out of the partnerships of 
transmitting and accepting claims data. In these instances patients may 
be affected, in that, without trading partner agreements for electronic 
crossover of claims data for the processing of the supplemental 
benefit, the patient may be responsible for filing his or her own 
supplemental claims that are filed electronically today.
Coordination of Benefits
    Once the ASC X12N 837 has been implemented, health plans that 
perform coordination of benefits would be able to eliminate support of 
multiple proprietary electronic claim formats, thus simplifying claims 
receipt and processing as well as reducing administrative costs. 
Coordination of benefits activities would also be greatly simplified 
because all health plans would 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 nonsystems perspective, we do not foresee an impact to 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 in the coordination of benefits 
process will clearly increase efficiency in the electronic processes 
utilized by the health care providers, health care clearinghouses, and 
health plans as they work with standardized codes and processes.
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 the principles, 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 of a 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. Many variations of 
the National Standard Format are in use. 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) claim because it met the principles above. The only other 
candidate standard is the UB-92 Format. While it is widely used, it is 
not always used in a standard manner.
    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 flexibility in order 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 do not 
wish to change their internal systems would have to convert the ASC 
X12N 835 transactions received from health plans into a format 
compatible with their internal systems. Health plans that want to 
transmit remittance advice directly to health care providers and that 
do not use the ASC X12N 835 would also incur costs to convert. 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, 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.)
    There would be a potential for the delay in payment or the issuance 
of electronic remittance advice

[[Page 25303]]

transactions during a particular health plan's transition to the ASC 
X12N 835. Some health care providers could react adversely to the 
increased cost and revert to use of hard copy remittance advice notices 
in lieu of an electronic transmission.
    After implementation, health care providers would no longer have to 
keep track of or accept different electronic payment/remittance advice 
formats issued by different health care payers. This would simplify 
automatic posting of all electronic payment/remittance advice data, 
reducing administrative expenses. This would 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 multiple 
formats, which the standard would eliminate.
    Once the ASC X12N 835 has been implemented, health plans' 
coordination of benefits activities, which would use the ASC X12N 837 
format supplemented with limited data from the ASC X12N 835, would be 
greatly simplified because all health plans would use the same standard 
format.
    Health plans would 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), as long 
as they meet the deadlines specified in the legislation.
    The selection of the ASC X12N 835 does not impose a greater burden 
on the industry than the nonselected option because the nonselected 
formats are not used in a standard manner by the industry and they do 
not incorporate flexibility in order 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, with the 
overall goal of 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 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 (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 would have to convert to the proposed standard, but we 
do know that no Medicare contractors use it; thus, we assume that few 
health care providers are able to use it at this time.
    After implementation, health care providers would be able to 
request and receive the status of claims in one standard format, from 
all health care plans. This would eliminate their need to maintain 
redundant software and would make electronic claim status requests and 
receipt of responses feasible for small providers, eliminating their 
need to manually send and review claim status requests and responses.
    Health care plans that do not currently directly accept electronic 
claim status requests and do not directly send electronic claims status 
responses would 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 would occur.
    After implementation, health care plans would 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 would 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 conduct 
subscriber enrollment transactions electronically because of the many 
changes that occur in a large workforce; for example, hirings, firings, 
retirements, marriages, births, and deaths, to name a few. To do this, 
the large employers must use the proprietary electronic data 
interchange formats that differ among health plans. 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 
would differ, at least in the beginning, according to the current use 
of electronic transactions. As stated earlier, most small and medium 
size employers and other sponsors do not use electronic transactions 
currently and would therefore experience little immediate impact from 
adoption of the ASC X12N 834 transaction. The ASC X12N 834 would offer 
large employers that currently conduct 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, we 
expect that the early benefits of the ASC X12N 834 would accrue to 
large employers and other sponsors that would be able to eliminate 
redundant hardware, software, and human resources required to support 
multiple proprietary electronic data interchange formats. In the long 
run, we expect that the standards would lower the cost of conducting 
enrollment transactions and make it possible for small and medium size 
companies to convert from paper to electronic transactions and achieve 
significant additional savings.
    Overall, employers and other sponsors, and the health plans with 
which they deal, stand to benefit from adoption of the ASC X12N 834 and 
electronic data interchange. The ASC X12N 834 and electronic data 
interchange would 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.
    We invite commenters to provide us with data on the extent to which

[[Page 25304]]

employers and other sponsors conduct their health plan enrollments 
using paper proprietary formats rather than the ASC X12N 834 electronic 
data interchange standards.
b. Effects of Various Options
    The only other option, the NCPDP Member Enrollment Standard, does 
not meet the selection criteria and would not be implementable.
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 prior to providing treatment 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 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 redundant software, hardware, and human resources to obtain 
eligibility information. This process is inefficient, often burdensome, 
and takes valuable time that could otherwise be devoted to patient 
care.
    We believe that 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 guide for these 
transactions in health care. We expect that adoption of the ASC X12N 
270/271 and its implementation guide would lower the cost of using 
electronic eligibility verifications. This would benefit health care 
providers that can move to a single standard format and, for the first 
time, make electronic data interchange feasible 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
    The ASC X12N 820 may be used by an employer or sponsor to 
electronically transmit a remittance notice to accompany a payment for 
health insurance premiums in response to a bill from the health plan. 
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 
X12 820 transaction is very 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 guide 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 redundant hardware, software, and human resources to support 
multiple proprietary electronic premium payment standards. We expect 
that 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, and, for the first time, will make 
electronic transmissions of premium payments feasible for smaller 
employers and other sponsors whose payment transactions today are 
performed almost exclusively using paper.
    At some point, an organization's size and complexity will require 
it to consider switching its business transactions from paper to 
electronic. The ASC X12N 820 would facilitate that by eliminating 
redundant proprietary formats that are certain to crop up 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. Those other sponsors and health care 
plans that already support more than one proprietary format would incur 
some additional expense in the conversion to the standard, but they 
would enjoy longer term savings that result from eliminating the 
redundancies.
    We invite comments on the extent to which employers and other 
sponsors conduct their health plan premium payments using paper versus 
proprietary formats, compared to the ASC X12N 820 electronic data 
interchange standards.
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 request 
and receive approval from a health plan through an electronic 
transaction 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 plans, they must devote 
redundant software, hardware, and human resources to obtaining prior 
authorization. This process is often untimely and inefficient.
    We believe that 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 care plans 
and health care providers, which may be due, in part, to the lack of an 
industry-wide implementation guide for it. We expect that adoption of 
ASC X12N 278 and its

[[Page 25305]]

implementation guide would lower the cost of using electronic prior 
authorizations. This would benefit health care providers that can move 
to a single standard format and, for the first time, make electronic 
data interchange feasible 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. The ASC X12N 278 would facilitate that by eliminating 
redundant proprietary formats that are certain to crop up 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 care plans and health care 
providers that already support more than one proprietary format would 
incur some additional expense in the conversion to the standard but 
would 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.

List of Subjects in 45 CFR Part 142

    Administrative practice and procedure, Health facilities, Health 
insurance, Hospitals, Incorporation by reference, Medicare, Medicaid.

    Accordingly, 45 CFR subtitle A, subchapter B, would be amended by 
adding Part 142 to read as follows:

    Note to Reader: This proposed rule and another proposed rule 
found elsewhere in this Federal Register are two of several proposed 
rules that are being published to implement the administrative 
simplification provisions of the Health Insurance Portability and 
Accountability Act of 1996. We propose to establish a new 45 CFR 
Part 142. Proposed Subpart A--General Provisions is exactly the same 
in each rule unless we have added new sections or definitions to 
incorporate additional general information. The subparts that follow 
relate to the specific provisions announced separately in each 
proposed rule. When we publish the first final rule, each subsequent 
final rule will revise or add to the text that is set out in the 
first final rule.

PART 142--ADMINISTRATIVE REQUIREMENTS

Subpart A--General Provisions

Sec.
142.101  Statutory basis and purpose.
142.102  Applicability.
142.103  Definitions.
142.104  General requirements for health plans.
142.105  Compliance using a health care clearinghouse.
142.106  Effective dates of a modification to a standard or 
implementation specification.
142.110  Availability of implementation guides.

Subparts B-I--[Reserved]

Subpart J--Code Sets

142.1002  Medical data code sets.
142.1004  Code sets for nonmedical data elements.
142.1010  Effective dates of the initial implementation of code 
sets.

Subpart K--Health Claims or Equivalent Encounter Information

142.1102  Standards for health claims or equivalent encounter 
information.
142.1104  Requirements: Health plans.
142.1106  Requirements: Health care clearinghouses.
142.1108  Requirements: Health care providers.
142.1110  Effective dates of the initial implementation of the 
health claim or equivalent encounter information.

Subpart L--Health Claims and Remittance Advice

142.1202  Standard for health claims and remittance advice.
142.1204  Requirements: Health plans.
144.1206  Requirements: Health care clearinghouses.
142.1210  Effective dates of the initial implementation of the 
health claims and remittance advice.

Subpart M--Coordination of Benefits

142.1302  Standard for coordination of benefits.
142.1304  Requirements: Health plans.
144.1306  Requirements: Health care clearinghouses.
142.1308  Effective dates of the initial implementation of the 
standard for coordination of benefits.

Subpart N--Health Claim Status

142.1402  Standard for health claim status.
142.1404  Requirements: Health plans.
144.1406  Requirements: Health care clearinghouses.
142.1408  Requirements: Health care providers.
142.1410  Effective dates of the initial implementation of the 
standard for health claims status.

Subpart O--Enrollment and Disenrollment in a Health Plan

142.1502  Standard for enrollment and disenrollment in a health 
plan.
142.1504  Requirements: Health plans.
144.1506  Requirements: Health care clearinghouses.
142.1508  Effective dates of the initial implementation of the 
standard for enrollment and disenrollment in a health plan.

Subpart P--Eligibility for a Health Plan

142.1602  Standard for eligibility for a health plan.
142.1604  Requirements: Health plans.
144.1606  Requirements: Health care clearinghouses.
142.1608  Requirements: Health care providers.
142.1610  Effective dates of the initial implementation of the 
standard for eligibility for a health plan.

Subpart Q--Health Plan Premium Payments

142.1702  Standard for health plan premium payments.
142.1704  Requirements: Health plans.
144.1706  Requirements: Health care clearinghouses.
142.1708  Effective dates of the initial implementation of the 
standard for health plan premium payments.

Subpart R--Referral Certification and Authorization

142.1802  Referral certification and authorization.
142.1804  Requirements: Health plans.
144.1806  Requirements: Health care clearinghouses.
142.1808  Requirements: Health care providers.
142.1810  Effective dates of the initial implementation of the 
standard for referral certifications and authorizations.

    Authority: Sections 1173 and 1175 of the Social Security Act (42 
U.S.C. 1320d-2 and 1320d-4)

Subpart A--General Provisions


Sec. 142.101  Statutory basis and purpose.

    Sections 1171 through 1179 of the Social Security Act, as added by 
section 262 of the Health Insurance Portability and Accountability Act 
of 1996, require HHS to adopt national standards for the electronic 
exchange of health information in the health information system. The 
purpose of these sections is to promote administrative simplification.


Sec. 142.102  Applicability.

    (a) The standards adopted or designated under this part apply, in 
whole or in part, to the following:
    (1) A health plan.
    (2) A health care clearinghouse when doing the following:
    (i) Transmitting a standard transaction (as defined in 
Sec. 142.103) to a health care provider or health plan.
    (ii) Receiving a standard transaction from a health care provider 
or health plan.
    (iii) Transmitting and receiving the standard transactions when 
interacting with another health care clearinghouse.
    (3) A health care provider when transmitting an electronic 
transaction as defined in Sec. 142.103.
    (b) Means of compliance are stated in greater detail in 
Sec. 142.105.

[[Page 25306]]

Sec. 142.103  Definitions.

    For purposes of this part, the following definitions apply:
    ASC X12 stands for the Accredited Standards Committee chartered by 
the American National Standards Institute to design national electronic 
standards for a wide range of business applications.
    ASC X12N stands for the ASC X12 subcommittee chartered to develop 
electronic standards specific to the insurance industry.
    Code set means any set of codes used for encoding data elements, 
such as tables of terms, medical concepts, medical diagnostic codes, or 
medical procedure codes.
    Health care clearinghouse means a public or private entity that 
processes or facilitates the processing of nonstandard data elements of 
health information into standard data elements. The entity receives 
transactions from health care providers, health plans, other entities, 
or other clearinghouses, translates the data from a given format into 
one acceptable to the intended recipient, and forwards the processed 
transaction to the appropriate recipient. Billing services, repricing 
companies, community health management information systems, community 
health information systems, and ``value-added'' networks and switches 
are considered to be health care clearinghouses for purposes of this 
part.
    Health care provider means a provider of services as defined in 
section 1861(u) of the Social Security Act, a provider of medical or 
other health services as defined in section 1861(s) of the Social 
Security Act, and any other person who furnishes or bills and is paid 
for health care services or supplies 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 plan means an individual or group plan that provides, or 
pays the cost of, medical care. Health plan includes the following, 
singly or in combination:
    (1) Group health plan. A group health plan is an employee welfare 
benefit plan (as currently defined in section 3(l) of the Employee 
Retirement Income and Security Act of 1974 (29 U.S.C. 1002(l)), 
including insured and self-insured plans, to the extent that the plan 
provides medical care, including items and services paid for as medical 
care, to employees or their dependents directly or through insurance, 
or otherwise, and
    (i) Has 50 or more participants; or
    (ii) Is administered by an entity other than the employer that 
established and maintains the plan.
    (2) Health insurance issuer. A health insurance issuer is an 
insurance company, insurance service, or insurance organization that is 
licensed to engage in the business of insurance in a State and is 
subject to State law that regulates insurance.
    (3) Health maintenance organization. A health maintenance 
organization is a Federally qualified health maintenance organization, 
an organization recognized as a health maintenance organization under 
State law, or a similar organization regulated for solvency under State 
law in the same manner and to the same extent as such a health 
maintenance organization.
    (4) Part A or Part B of the Medicare program under title XVIII of 
the Social Security Act.
    (5) The Medicaid program under title XIX of the Social Security 
Act.
    (6) A Medicare supplemental policy (as defined in section 
1882(g)(1) of the Social Security Act).
    (7) A long-term care policy, including 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 Benefits Program under 5 U.S.C. 
chapter 89.
    (14) Any other individual or group health plan, or combination 
thereof, that provides or pays for the cost of medical care.
    Medical care means the diagnosis, cure, mitigation, treatment, or 
prevention of disease, or amounts paid for the purpose of affecting any 
body structure or function of the body; amounts paid for transportation 
primarily for and essential to these items; and amounts paid for 
insurance covering the items and the transportation specified in this 
definition.
    Participant means any employee or former employee of an employer, 
or any member or former member of an employee organization, who is or 
may become eligible to receive a benefit of any type from an employee 
benefit plan that covers employees of that employer or members of such 
an organization, or whose beneficiaries may be eligible to receive any 
of these benefits. ``Employee'' includes an individual who is treated 
as an employee under section 401(c)(1) of the Internal Revenue Code of 
1986 (26 U.S.C. 401(c)(1)).
    Small health plan means a group health plan or individual health 
plan with fewer than 50 participants.
    Standard means a set of rules for a set of codes, data elements, 
transactions, or identifiers promulgated either by an organization 
accredited by the American National Standards Institute or HHS for the 
electronic transmission of health information.
    Transaction means the exchange of information between two parties 
to carry out financial and administrative activities related to health 
care. It includes the following:
    (1) Transactions specified in section 1173(a)(2) of the Act, which 
are as follows:
    (i) Health claims or equivalent encounter information.
    (ii) Health care payment and remittance advice.
    (iii) Health claims status.
    (iv) Enrollment and disenrollment in a health plan.
    (v) Eligibility for a health plan.
    (vi) Health plan premium payments.
    (vii) First report of injury.
    (viii) Referral certification and authorization.
    (ix) Health claims attachments.
    (2) Other transactions as the Secretary may prescribe by 
regulation. Coordination of benefits is a transaction under this 
authority.


Sec. 142.104  General requirements for health plans.

    If a person conducts a transaction (as defined in Sec. 142.103) 
with a health plan as a standard transaction, the following apply:
    (a) The health plan may not refuse to conduct the transaction as 
standard transaction.
    (b) The health plan may not delay the transaction or otherwise 
adversely

[[Page 25307]]

affect, or attempt to adversely affect, the person or the transaction 
on the basis that the transaction is a standard transaction.
    (c) The health information transmitted and received in connection 
with the transaction must be in the form of standard data elements of 
health information.
    (d) A health plan that conducts transactions through an agent must 
assure that the agent meets all the requirements of this part that 
apply to the health plan.


Sec. 142.105  Compliance using a health care clearinghouse.

    (a) Any person or other entity subject to the requirements of this 
part may meet the requirements to accept and transmit standard 
transactions by either--
    (1) Transmitting and receiving standard data elements, or
    (2) Submitting nonstandard data elements to a health care 
clearinghouse for processing into standard data elements and 
transmission by the health care clearinghouse and receiving standard 
data elements through the health care clearinghouse.
    (b) The transmission, under contract, of nonstandard data elements 
between a health plan or a health care provider and its agent health 
care clearinghouse is not a violation of the requirements of this part.


Sec. 142.106  Effective dates of a modification to a standard or 
implementation specification.

    If HHS adopts a modification to a standard or implementation 
specification, the implementation date of the modified standard or 
implementation specification may be no earlier than 180 days following 
the adoption of the modification. HHS determines the actual date, 
taking into account the time needed to comply due to the nature and 
extent of the modification. HHS may extend the time for compliance for 
small health plans.


Sec. 142.110  Availability of implementation guides.

    The implementation guides specified in subparts K through R of this 
part are available as set forth in paragraphs (a) through (c) of this 
section. Entities requesting copies or access for inspection must 
specify the standard by name, number, and version.
    (a) The implementation guides for ASC X12 standards may be obtained 
from the Washington Publishing Company, 806 W. Diamond Ave., Suite 400, 
Gaithersburg, MD, 20878; telephone 301-590-9337; and FAX: 301-869-9460. 
They are also available, at no cost, through the Washington Publishing 
Company on the Internet at http://www.wpc-edi.com/hipaa/.
    (b) The implementation guide for pharmacy claims may be obtained 
from the National Council for Prescription Drug Programs, 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.
    (c) A copy of the guides may be inspected at the Office of the 
Federal Register, 800 North Capitol Street, NW., Suite 700, Washington, 
DC and at the Health Care Financing Administration.

Subparts B-I--[Reserved]

Subpart J--Code Sets


Sec. 142.1002  Medical data code sets.

    Health plans, health care clearinghouses, and health care providers 
must use on electronic transactions the diagnostic and procedure code 
sets as prescribed by HHS. These code sets are published in a notice in 
the Federal Register. The implementation guides for the transaction 
standards in part 142, Subparts K through R specify which of the 
standard medical data code sets are to be used in individual data 
elements within those transaction standards.


Sec. 142.1004  Code sets for nonmedical data elements.

    The code sets for nonmedical data that must be used in a 
transaction specified in subparts K through R of this part are the code 
sets described in the implementation guide for the transaction 
standard.


Sec. 142.1010  Effective dates of the initial implementation of code 
sets.

    (a) Health plans. (1) Each health plan that is not a small health 
plan must comply with the requirements of Secs. 142.104, 142.1002, and 
142.1004 by (24 months after the effective date of the final rule in 
the Federal Register).
    (2) Each small health plan must comply with the requirements of 
Secs. 142.104, 142.1002, and 142.1004 by [36 months after the effective 
date of the final rule in the Federal Register].
    (b) Health care clearinghouses and health care providers. Each 
health care clearinghouse and health care provider must begin to use 
the standards specified in Secs. 142.1002 and 142.1004 by (24 months 
after the effective date of the final rule in the Federal Register).

Subpart K--Health Claims or Equivalent Encounter Information


Sec. 142.1102  Standards for health claims or equivalent encounter 
information.

    The health claims or equivalent encounter information standards 
that must be used under this subpart are as follows:
    (a) For pharmacy claims, the NCPDP Telecommunications Standard 
Format Version 3.2 and equivalent Standard Claims Billing Tape Format 
batch implementation, version 2.0. The Director of the Federal Register 
approves this incorporation by reference in accordance with 5 U.S.C. 
552(a) and 1 CFR part 51. The guide is available at the addresses 
specified in Sec. 142.108(b) and (c) of this part.
    (b) The ASC X12N 837--Health Care Claim: Dental, Version 4010, 
Washington Publishing Company, 004010X097. The Director of the Federal 
Register approves this incorporation by reference in accordance with 5 
U.S.C. 552(a) and 1 CFR part 51. The guide is available at the 
addresses specified in Sec. 142.108(a) and (c) of this part.
    (c) The ASC X12N 837--Health Care Claim: Professional, Version 
4010, Washington Publishing Company, 004010X098. The Director of the 
Federal Register approves this incorporation by reference in accordance 
with 5 U.S.C. 552(a) and 1 CFR part 51. The guide is available at the 
addresses specified in Sec. 142.108(a) and (c) of this part.
    (d) The ASC X12N 837--Health Care Claim--Institutional, Version 
4010, Washington Publishing Company, 004010X096. The Director of the 
Federal Register approves this incorporation by reference in accordance 
with 5 U.S.C. 552(a) and 1 CFR part 51. The guide is available at the 
addresses specified in Sec. 142.108(a) and (c) of this part.


Sec. 142.1104  Requirements: Health plans.

    Each health plan must accept the standard specified in 
Sec. 142.1102 when conducting transactions concerning health claims and 
equivalent encounter information.


Sec. 142.1106  Requirements: Health care clearinghouses.

    Each health care clearinghouse must use the standard specified in 
Sec. 142.1102 when accepting or transmitting health claims or 
equivalent encounter information transactions.


Sec. 142.1108  Requirements: Health care providers.

    Any health care provider that transmits health claims or equivalent 
encounter information electronically must use the standard specified in 
Sec. 142.1102.

[[Page 25308]]

Sec. 142.1110  Effective dates of the initial implementation of the 
health claim or equivalent encounter information standard.

    (a) Health plans. (1) Each health plan that is not a small health 
plan must comply with the requirements of Secs. 142.104 and 142.1104 by 
(24 months after the effective date of the final rule in the Federal 
Register).
    (2) Each small health plan must comply with the requirements of 
Secs. 142.104 and 142.1104 by (36 months after the effective date of 
the final rule in the Federal Register).
    (b) Health care clearinghouses and health care providers. Each 
health care clearinghouse and health care provider must begin to use 
the standard specified in Sec. 142.1102 by (24 months after the 
effective date of the final rule in the Federal Register).

Subpart L--Health Claims and Remittance Advice


Sec. 142.1202  Standard for health claims and remittance advice.

    The standard for health claims and remittance advice that must be 
used under this subpart is the ASC X12N 835--Health Care Claim Payment/
Advice, Version 4010, Washington Publishing Company, 004010X091. The 
Director of the Federal Register approves this incorporation by 
reference in accordance with 5 U.S.C. 552(a) and 1 CFR part 51. The 
guide is available at the addresses specified in Sec. 142.108(a) and 
(c) of this part.


Sec. 142.1204  Requirements: Health plans.

    Each health plan must transmit the standard specified in 
Sec. 142.1202 when conducting health claims and remittance advice 
transactions.


Sec. 142.1206  Requirements: Health care clearinghouses.

    Each health care clearinghouse must use the standard specified in 
Sec. 142.1202 when accepting or transmitting health claims and 
remittance advice.


Sec. 142.1210  Effective dates of the initial implementation of the 
health claims and remittance advice.

    (a) Health plans. (1) Each health plan that is not a small health 
plan must comply with the requirements of Secs. 142.104 and 142.1204 by 
(24 months after the effective date of the final rule in the Federal 
Register).
    (2) Each small health plan must comply with the requirements of 
Secs. 142.104 and 142.1204 by (36 months after the effective date of 
the final rule in the Federal Register).
    (b) Health care clearinghouses. Each health care clearinghouse must 
begin to use the standard specified in Sec. 142.1204 by (24 months 
after the effective date of the final rule in the Federal Register).

Subpart M--Coordination of Benefits


Sec. 142.1302  Standard for coordination of benefits.

    The coordination of benefits information standards that must be 
used under this subpart are as follows:
    (a) For pharmacy claims, the NCPDP Telecommunications Standard 
Format Version 3.2 and equivalent Standard Claims Billing Tape Format 
batch implementation, version 2.0. The Director of the Federal Register 
approves this incorporation by reference in accordance with 5 U.S.C. 
552(a) and 1 CFR part 51. The guide is available at the addresses 
specified in Sec. 142.108(b) and (c) of this part.
    (b) For dental claims, the ASC X12N 837--Health Care Claim: Dental, 
Version 4010, Washington Publishing Company, 004010X097. The Director 
of the Federal Register approves this incorporation by reference in 
accordance with 5 U.S.C. 552(a) and 1 CFR part 51. The guide is 
available at the addresses specified in Sec. 142.108(a) and (c) of this 
part.
    (c) For professional claims, the ASC X12N 837--Health Care Claim: 
Professional, Version 4010, Washington Publishing Company, 004010X098. 
The Director of the Federal Register approves this incorporation by 
reference in accordance with 5 U.S.C. 552(a) and 1 CFR part 51. The 
guide is available at the addresses specified in Sec. 142.108(a) and 
(c) of this part.
    (d) For institutional claims, the ASC X12N 837--Health Care Claim--
Institutional, Version 4010, Washington Publishing Company, 004010X096. 
The Director of the Federal Register approves this incorporation by 
reference in accordance with 5 U.S.C. 552(a) and 1 CFR part 51. The 
guide is available at the addresses specified in Sec. 142.108(a) and 
(c) of this part.


Sec. 142.1304  Requirements: Health plans.

    Each health plan that performs coordination of benefits must accept 
and transmit the standard specified in Sec. 142.1302 when accepting or 
transmitting coordination of benefits transactions.


Sec. 142.1306  Requirements: Health care clearinghouses.

    Each health care clearinghouse must use the standard specified in 
Sec. 142.1302 when accepting or transmitting coordination of benefits 
transactions.


Sec. 142.1308  Effective dates of the initial implementation of the 
standard for coordination of benefits.

    (a) Health plans. (1) Each health plan that performs coordination 
of benefits and is not a small health plan must comply with the 
requirements of Secs. 142.104 and 142.1304 by (24 months after the 
effective date of the final rule in the Federal Register).
    (2) Each small health plan that performs coordination of benefits 
must comply with the requirements of Secs. 142.104 and 142.1304 by (36 
months after the effective date of the final rule in the Federal 
Register).
    (b) Health care clearinghouses. Each health care clearinghouse must 
begin to use the standard specified in Sec. 142.1302 by (24 months 
after the effective date of the final rule in the Federal Register).

Subpart N--Health Claim Status


Sec. 142.1402  Standard for health claim status.

    The standard for health claim status that must be used under this 
subpart is the ASC X12N 276/277 Health Care Claim Status Request and 
Response, Version 4010, Washington Publishing Company, 004010X093. The 
Director of the Federal Register approves this incorporation by 
reference in accordance with 5 U.S.C. 552(a) and 1 CFR part 51. The 
guide is available at the addresses specified in Sec. 142.108(a) and 
(c) of this part.


Sec. 142.1404  Requirements: Health plans.

    Each health plan must accept and transmit the standard specified in 
Sec. 142.1402 when accepting or transmitting health claim status in 
transactions with health care providers.


Sec. 142.1406  Requirements: Health care clearinghouses.

    Each health care clearinghouse must use the standard specified in 
Sec. 142.1402 when accepting or transmitting health claims status 
transactions.


Sec. 142.1408  Requirements: Health care providers.

    Any health care provider that transmits or accepts health claims 
status electronically must use the standard specified in Sec. 142.1402.


Sec. 142.1410  Effective dates of the initial implementation of the 
standard for health claims status.

    (a) Health plans. (1) Each health plan that is not a small health 
plan must comply with the requirements of Secs. 142.104 and 142.1404 by 
(24 months after the effective date of the final rule in the Federal 
Register).
    (2) Each small health plan must comply with the requirements of

[[Page 25309]]

Sec. Sec. 142.104 and 142.1404 by (36 months after the effective date 
of the final rule in the Federal Register).
    (b) Health care clearinghouses and health care providers. Each 
health care clearinghouse and health care provider must begin to use 
the standard specified in Sec. 142.1402 by (24 months after the 
effective date of the final rule in the Federal Register).

Subpart O--Enrollment and Disenrollment in a Health Plan


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

    The standard for enrollment and disenrollment in a health plan that 
must be used under this subpart is the ASC X12 834--Benefit Enrollment 
and Maintenance, [date], Version 4010, Washington Publishing Company, 
(004010X095). The Director of the Federal Register approves this 
incorporation by reference in accordance with 5 U.S.C. 552(a) and 1 CFR 
part 51. The guide is available at the addresses specified in 
Sec. 142.110(a) and (c).


Sec. 142.1504  Requirements: Health plans.

    Each health plan must accept the standard specified in 
Sec. 142.1502 when accepting transactions for enrollment and 
disenrollment in a health plan.


Sec. 142.1506  Requirements: Health care clearinghouses.

    Each health care clearinghouse must use the standard specified in 
Sec. 142.1502 when accepting or transmitting transactions for 
enrollment and disenrollment in a health plan.


Sec. 142.1508  Effective dates of the initial implementation of the 
standard for enrollment and disenrollment in a health plan.

    (a) Health plans. (1) Each health plan that is not a small health 
plan must comply with the requirements of Secs. 142.104 and 142.1504 by 
(24 months after the effective date of the final rule in the Federal 
Register).
    (2) Each small health plan must comply with the requirements of 
Secs. 142.104 and 142.1504 by (36 months after the effective date of 
the final rule in the Federal Register).
    (b) Health care clearinghouses. Each health care clearinghouse must 
begin to use the standard specified in Sec. 142.1502 by (24 months 
after the effective date of the final rule in the Federal Register).

Subpart P--Eligibility for a Health Plan


Sec. 142.1602  Standard for eligibility for a health plan.

    The standard for eligibility for a health plan transaction that 
must be used under this subpart is ASC X12N 270--Health Care 
Eligibility Benefit Inquiry and ASC X12N 271--Health Care Eligibility 
Benefit Response, [date], Version 4010, Washington Publishing Company, 
(004010X092). The Director of the Federal Register approves this 
incorporation by reference in accordance with 5 U.S.C. 552(a) and 1 CFR 
part 51. The guide is available at the addresses specified in 
Sec. 142.108(a) and (c) of this part.


Sec. 142.1604  Requirements: Health plans.

    Each health plan must accept and transmit the standard specified in 
Sec. 142.1602 when accepting or transmitting transactions for 
eligibility for a health plan.


Sec. 142.1606  Requirements: Health care clearinghouses.

    Each health care clearinghouse must use the standard specified in 
Sec. 142.1602 when accepting or transmitting transactions for 
eligibility for a health plan.


Sec. 142.1608  Requirements: Health care providers.

    Any health care provider that transmits or receives transactions 
for eligibility for a health plan electronically must use the standard 
specified in Sec. 142.1602.


Sec. 142.1610  Effective dates of the initial implementation of the 
standard for eligibility for a health plan.

    (a) Health plans. (1) Each health plan that is not a small health 
plan must comply with the requirements of Secs. 142.104 and 142.1604 by 
(24 months after the effective date of the final rule in the Federal 
Register).
    (2) Each small health plan must comply with the requirements of 
Secs. 142.104 and 142.1604 by (36 months after the effective date of 
the final rule in the Federal Register).
    (b) Health care clearinghouses and health care providers. Each 
health care clearinghouse and health care provider must begin to use 
the standard specified in Sec. 142.1602 by (24 months after the 
effective date of the final rule in the Federal Register).

Subpart Q--Health Plan Premium Payments


Sec. 142.1702  Standard for health plan premium payments.

    The standard for health plan premium payments that must be used 
under this subpart is the ASC X12 820--Payment Order/Remittance Advice, 
(date), Version 4010, Washington Publishing Company, (004010X061). The 
Director of the Federal Register approves this incorporation by 
reference in accordance with 5 U.S.C. 552(a) and 1 CFR part 51. The 
guide is available at the addresses specified in Sec. 142.108(a) and 
(c) of this part.


Sec. 142.1704  Requirements: Health plans.

    Each health plan must accept the standard specified in 
Sec. 142.1702 when accepting electronically transmitted health plan 
premium payments.


Sec. 142.1706  Requirements: Health care clearinghouses.

    Each health care clearinghouse must use the standard specified in 
Sec. 142.1702 when accepting or transmitting health plan premium 
payments.


Sec. 142.1708  Effective dates of the initial implementation of the 
standard for health plan premium payments.

    (a) Health plans. (1) Each health plan that is not a small health 
plan must comply with the requirements of Secs. 142.104 and 142.1704 by 
(24 months after the effective date of the final rule in the Federal 
Register).
    (2) Each small health plan must comply with the requirements of 
Secs. 142.104 and 142.1704 by (36 months after the effective date of 
the final rule in the Federal Register).
    (b) Health care clearinghouses. Each health care clearinghouse must 
begin to the use the standard specified in Sec. 142.1702 by (24 months 
after the effective date of the final rule in the Federal Register).

Subpart R--Referral Certification and Authorization


Sec. 142.1802  Referral certification and authorization.

    The standard for referral certification and authorization 
transactions that must be used under this subpart is the ASC X12N 278--
Request for Review and Response, (date), Version 4010, Washington 
Publishing Company, (004010X094). The Director of the Federal Register 
approves this incorporation by reference in accordance with 5 U.S.C. 
552(a) and 1 CFR part 51. The guide is available at the addresses 
specified in Sec. 142.108(a) and (c) of this part.


Sec. 142.1804  Requirements: Health plans.

    Each health plan must accept and transmit the standard specified in 
Sec. 142.1802 when accepting or transmitting referral certifications 
and authorizations.


Sec. 142.1806  Requirements: Health care clearinghouses.

    Each health care clearinghouse must use the standard specified in 
Sec. 142.1902

[[Page 25310]]

when accepting or transmitting referral certifications and 
authorizations.


Sec. 142.1808  Requirements: Health care providers.

    Any health care provider that transmits or accepts referral 
certifications and authorizations electronically must use the standard 
specified in Sec. 142.1902.


Sec. 142.1810  Effective dates of the initial implementation of the 
standard for referral certifications and authorizations.

    (a) Health plans. (1) Each health plan that is not a small health 
plan must comply with the requirements of Secs. 142.104 and 142.1804 by 
(24 months after the effective date of the final rule in the Federal 
Register).
    (2) Each small health plan must comply with the requirements of 
Secs. 142.104 and 142.1804 by (36 months after the effective date of 
the final rule in the Federal Register).
    (b) Health care clearinghouses and health care providers. Each 
health care clearinghouse and health care provider must begin to use 
the standard specified in Sec. 142.1802 by (24 months after the 
effective date of the final rule in the Federal Register).

    Dated: March 27, 1998.
Donna E. Shalala,
Secretary.
    Note: These Addenda will not appear in the Code of Federal 
Regulations.

Addendum 1--Health Claims or Equivalent Encounter Information

A. Retail Drug Claim or Equivalent Encounter

    The transactions selected for retail drug claims are accredited 
by the American National Standards Institute (ANSI). The 
transactions are: NCPDP Telecommunications Standard Format version 
3.2 and the equivalent NCPDP Batch Standard Version 1.0.

1. Implementation Guide and Source

    The source of the implementation guide for the NCPDP 
Telecommunication Standard Format Version 3.2 and the equivalent 
NCPDP Batch Standard Version 1.0 is the National Council for 
Prescription Drug Programs, 4201 North 24th Street, Suite 365, 
Phoenix, AZ, 85016, Telephone 602-957-9105, FAX 602-955-0749. The 
web site address is http://www.ncpdp.org

2. Data Elements

Accumulated Deductible Amount
Additional Message Information
Adjustment/reject Code--1
Adjustment/reject Code--2
Adjustment/reject Code--3
Alternate Product Code
Alternate Product Type
Amount Attributed to Sales Tax
Amount Billed
Amount of Co-pay/co-insurance
Amount Rejected
Amt. Applied to Periodic Deduct
Amt. Attrib. To Prod. Selection
Amt. Exceed. Periodic Benefit Max
Authorization Number
Basis of Cost Determination
Basis of Days Supply Determination
Basis of Reimb. Determination
Batch Number
Bin Number
Cardholder First Name
Cardholder Id Number
Cardholder Last Name
Carrier Address
Carrier Correction Notice Fields
Carrier Identification Number
Carrier Location City
Carrier Location State
Carrier Name
Carrier Telephone Number
Carrier Zip Code
Claim Count
Claim/reference Id Number
Clinic Id Number
Co-pay Amount
Comments-1
Comments-2
Compound Code
Contract Fee Paid
Customer Location
Date Filled
Date of Birth
Date of Injury
Date Prescription Written
Days Supply
Destination Name
Destination Processor Number
Diagnosis Code
Diskette Record Id
Dispense as Written (Daw)
Dispensing Fee Submitted
Dollar Count
Dollars Adjusted
Dollars Billed
Dollars Rejected
Drug Name
Drug Type
Dur Conflict Code
Dur Intervention Code
Dur Outcome Code
Dur Response Data
Eligibility Clarification Code
Employer City Address
Employer Contact Name
Employer Name
Employer Phone Number
Employer State Address
Employer Street Address
Employer Zip Code
Fee or Markup
Gross Amount Due
Group Number
Home Plan
Host Plan
Incentive Amount Submitted
Incentive Fee Paid
Ingredient Cost Billed
Ingredient Cost Paid
Ingredient Cost
Level of Service
Master Sequence Number
Message
Metric Decimal Quantity
Metric Quantity
Ndc Number
New/refill Code
Number of Refills Authorized
Other Coverage Code
Other Payor Amount
Patient City Address
Patient First Name
Patient Last Name
Patient Paid Amount
Patient Pay Amount
Patient Phone Number
Patient Social Security
Patient State Address
Patient Street Address
Patient Zip Code
Payment Processor Id
Person Code
Pharmacy Address
Pharmacy Count
Pharmacy Location City
Pharmacy Location State
Pharmacy Name
Pharmacy Number
Pharmacy Telephone Number
Pharmacy Zip Code
Plan Identification
Postage Amount Claimed
Postage Amount Paid
Prescriber Id
Prescriber Last Name
Prescription Denial Clarification
Prescription Number
Prescription Origin Code
Primary Prescriber
Prior Authorization/medical Certification Code And Number
Processor Address
Processor Control Number
Processor Location City
Processor Location State
Processor Name
Processor Number
Processor Telephone Number
Processor Zip Code
Record Identifier
Reject Code
Reject Count
Relationship Code
Remaining Benefit Amount
Remaining Deductible Amount
Response Data
Response Status
Resubmission Cycle Count
Run Date
Sales Tax Paid
Sales Tax
Sex Code
System Id
Terminal Id
Third Party Type
Total Amount Paid
Transaction Code
Unit Dose Indicator
Usual And Customary Charge
Version Release Number

B. Professional Health Claim or Equivalent Encounter

    The transaction selected for the professional (non-
institutional) health claim or equivalent encounter information is 
ASC X12N 837--Health Care Claim: Professional (004010X098)

1. Implementation Guide and Source

    The source of the implementation guide for the professional 
health care claim or equivalent encounter is: Washington Publishing 
Company, 806 W. Diamond Ave., Suite 400, Gaithersburg, MD, 20878, 
Telephone 301-590-9337, FAX: 301-869-

[[Page 25311]]

9460. The web site address is <a href="http://www.wpc-edi.com/hipaa/

2">http://www.wpc-edi.com/hipaa/

2</a>. Data Elements

Accident Date
Acute Manifestation Date
Additional Submitter or Receiver Name
Adjudication or Payment Date
Adjusted Repriced Claim Reference Number
Adjusted Repriced Line Item Reference Number
Adjustment Amount
Adjustment Quantity
Adjustment Reason Code
Agency Qualifier Code
Allowed Amount
Ambulatory Patient Group Number
Amino Acid Name
Amount Qualifier Code
Anesthesia or Oxygen Minute Count
Approved Ambulatory Patient Group Amount
Approved Ambulatory Patient Group Code
Approved Service Unit Count
Arterial Blood Gas Quantity
Arterial Blood Gas Test Date
Assigned Number
Assumed or Relinquished Care Date
Attachment Control Number
Attachment Description Text
Attachment Report Type Code
Attachment Transmission Code
Auto Accident State or Province Code
Benefits Assignment Certification Indicator
Billing Provider Additional Name
Billing Provider City Name
Billing Provider Contact Name
Billing Provider Credit Card Identifier
Billing Provider First Address Line
Billing Provider First Name
Billing Provider Identifier
Billing Provider Last or Organizational Name
Billing Provider Middle Name
Billing Provider Name Suffix
Billing Provider Postal Zone or ZIP Code
Billing Provider Second Address Line
Billing Provider State or Province Code
Bundled or Unbundled Line Number
Certification Form Number
Certification Period Projected Visit Count
Certified Registered Nurse Anesthetist Supervision Indicator
Claim Adjustment Group Code
Claim Encounter Identifier
Claim Filing Indicator Code
Claim Frequency Code
Claim Note Text
Claim Payment Remark Code
Claim Submission Reason Code
Clinical Laboratory Improvement Amendment Number
Code Category
Code List Qualifier Code
Coinsurance Amount
Communication Number Qualifier
Communication Number
Complication Indicator
Condition Codes
Condition Indicator
Contact Function Code
Contact Inquiry Reference
Continuous Passive Motion Date
Contract Amount
Contract Code
Contract Percentage
Contract Type Code
Contract Version Identifier
Country Code
Coverage Certification Period Count
Creation Date
Credit or Debit Card Holder Additional Name
Credit or Debit Card Holder First Name
Credit or Debit Card Holder Last or Organizational Name
Credit or Debit Card Holder Middle Name
Credit or Debit Card Holder Name Suffix
Credit or Debit Card Maximum Amount
Credit or Debit Card Number
Credit/Debit Flag Code
Currency Code
Current Illness or Injury Date
CHAMPUS Non-availability Indicator
Daily Amino Acid Gram Use Count
Daily Amino Acid Prescription Milliliter Use Count
Daily Dextrose Prescription Milliliter Use Count
Daily Prescribed Nutrient Calorie Count
Daily Prescribed Product Calorie Count
Date of Surgical Procedure
Date Time Period Format Qualifier
Date/Time Qualifier
Deductible Amount
Diagnosis Associated Amount
Diagnosis Code Pointer
Diagnosis Code
Disability Type Code
Disability-From Date
Disability-To Date
Discipline Type Code
Drug Formulary Number
Drug Unit Price
Emergency Indicator
Emergency Medical Technician (EMT) or Paramedic First Name
Emergency Medical Technician or Paramedic Middle Name
Emergency Medical Technician or Paramedic City Name
Emergency Medical Technician or Paramedic First Address Line
Emergency Medical Technician or Paramedic Last Name
Emergency Medical Technician or Paramedic Name Additional Text
Emergency Medical Technician or Paramedic Primary Identifier
Emergency Medical Technician or Paramedic Second Address Line
Emergency Medical Technician or Paramedic Secondary Identifier
Emergency Medical Technician or Paramedic State Code
Emergency Medical Technician or Paramedic ZIP Code
Employment Status Code
End Stage Renal Disease Payment Amount
Enteral or Parenteral Indicator
Entity Identifier Code
Entity Type Qualifier
Exception Code
Exchange Rate
Explanation of Benefits Indicator
EPSDT Indicator
Facility Type Code
Family Planning Indicator
Feeding Count
File Creation Time
First Visit Date
Fixed Format Information
Functional Status Code
Group or Policy Number
Hierarchical Child Code
Hierarchical ID Number
Hierarchical Level Code
Hierarchical Parent ID Number
Hierarchical Structure Code
Homebound Indicator
Hospice Employed Provider Indicator
HCPCS Payable Amount
Identification Code Qualifier
Immunization Status Code
Immunization Type Code
Independent Lab Charge Amount
Individual Relationship Code
Information Release Code
Information Release Date
Ingredient Cost Claimed Amount
Initial Treatment Date
Insurance Type Code
Insured Employer Additional Name
Insured Employer City Name
Insured Employer Contact Name
Insured Employer First Address Line
Insured Employer First Name
Insured Employer Identifier
Insured Employer Middle Name
Insured Employer Name Suffix
Insured Employer Name
Insured Employer Second Address Line
Insured Employer State Code
Insured Employer ZIP Code
Insured Group Name
Insured Group Number
Investigational Device Exemption Identifier
Laboratory or Facility City Name
Laboratory or Facility Contact Name
Laboratory or Facility First Address Line
Laboratory or Facility Name Additional Text
Laboratory or Facility Name
Laboratory or Facility Postal ZIP or Zonal Code
Laboratory or Facility Primary Identifier
Laboratory or Facility Second Address Line
Laboratory or Facility Secondary Identifier
Laboratory or Facility State or Province Code
Last Certification Date
Last Menstrual Period Date
Last Seen Date
Last Worked Date
Last X-Ray Date
Legal Representative Additional Name
Legal Representative City Name
Legal Representative First Address Line
Legal Representative First Name
Legal Representative Last or Organization Name
Legal Representative Middle Name
Legal Representative Second Address Line
Legal Representative State Code
Legal Representative Suffix Name
Legal Representative ZIP Code
Line Item Control Number
Line Note Text
Mammography Certification Number
Measurement Qualifier
Measurement Reference Identification Code
Medical Justification Text
Medical Record Number
Medicare Assignment Code
Medicare Coverage Indicator
Multiple Procedure Indicator
National Drug Code
National Drug Unit Count
Nature of Condition Code
Non-Payable Professional Component Billed Amount
Non-Visit Code
Note Reference Code

[[Page 25312]]

Nutrient Administration Method Code
Nutrient Administration Technique Code
Onset Date
Ordering Provider City Name
Ordering Provider Contact Name
Ordering Provider First Address Line
Ordering Provider First Name
Ordering Provider Identifier
Ordering Provider Last Name
Ordering Provider Middle Name
Ordering Provider Name Additional Text
Ordering Provider Name Suffix
Ordering Provider Second Address Line
Ordering Provider Secondary Identifier
Ordering Provider State Code
Ordering Provider ZIP Code
Original Line Item Reference Number
Originator Application Transaction Identifier
Other Employer Additional Name
Other Employer City Name
Other Employer First Address Line
Other Employer First Name
Other Employer Last or Organization Name
Other Employer Middle Name
Other Employer Second Address Line
Other Employer State Code
Other Employer ZIP Code
Other Insured Additional Identifier
Other Insured Additional Name
Other Insured Birth Date
Other Insured City Name
Other Insured First Address Line
Other Insured First Name
Other Insured Gender Code
Other Insured Identifier
Other Insured Last Name
Other Insured Middle Name
Other Insured Name Suffix
Other Insured Plan Name or Program Name
Other Insured Second Address Line
Other Insured State Code
Other Insured ZIP Code
Other Payer Additional Name Text
Other Payer City Name
Other Payer Covered Amount
Other Payer Discount Amount
Other Payer Federal Mandate Amount
Other Payer First Address Line
Other Payer Interest Amount
Other Payer Last or Organization Name
Other Payer Patient Paid Amount
Other Payer Patient Responsibility Amount
Other Payer Per Day Limit Amount
Other Payer Pre-Tax Claim Total Amount
Other Payer Primary Identifier
Other Payer Second Address Line
Other Payer Secondary Identifier
Other Payer State Code
Other Payer Tax Amount
Other Payer ZIP Code
Oxygen Saturation Quantity
Oxygen Saturation Test Date
Paid Service Unit Count
Paramedic Contact Name
Patient Account Number
Patient Additional Name
Patient Age
Patient Amount Paid
Patient Birth Date
Patient City Name
Patient Death Date
Patient Facility Additional Name Text
Patient Facility City Name
Patient Facility First Address Line
Patient Facility Name
Patient Facility Second Address Line
Patient Facility State Code
Patient Facility Zip Code
Patient First Address Line
Patient First Name
Patient Gender Code
Patient Height
Patient Last Name
Patient Marital Status Code
Patient Middle Name
Patient Name Suffix
Patient Primary Identifier
Patient Second Address Line
Patient Secondary Identifier
Patient Signature Source Code
Patient State Code
Patient ZIP Code
Pay-to Provider Additional Name
Pay-to Provider City Name
Pay-to Provider Contact Name
Pay-to Provider First Address Line
Pay-to Provider First Name
Pay-to Provider Identifier
Pay-to Provider Last or Organizational Name
Pay-to Provider Middle Name
Pay-to Provider Name Suffix
Pay-to Provider Second Address Line
Pay-to Provider State Code
Pay-to Provider ZIP Code
Payer Additional Identifier
Payer Additional Name
Payer City Name
Payer First Address Line
Payer Identifier
Payer Name
Payer Paid Amount
Payer Responsibility Sequence Number Code
Payer Second Address Line
Payer State Code
Payer ZIP Code
Period Count
Place of Service Code
Policy Compliance Code
Postage Claimed Amount
Prescription Amino Acid Concentration Percent
Prescription Date
Prescription Dextrose Concentration Percent
Prescription Lipid Concentration Percent
Prescription Lipid Milliliter Use Count
Prescription Number
Prescription Period Count
Pricing Methodology
Prior Authorization Number
Procedure Modifier
Product Name
Product/Service ID Qualifier
Product/Service Procedure Code
Prognosis Code
Property Casualty Claim Number
Provider or Supplier Signature Indicator
Provider Code
Provider Identifier
Provider Organization Code
Provider Signature Date
Provider Specialty Certification Code
Provider Specialty Code
Purchase Price Amount
Purchase Service Charge Amount
Purchase Service Provider Identifier
Purchase Service State Code
Purchased Service Provider City Name
Purchased Service Provider Contact Name
Purchased Service Provider First Address Line
Purchased Service Provider First Name
Purchased Service Provider Last or Organization Name
Purchased Service Provider Middle Name
Purchased Service Provider Name Additional Text
Purchased Service Provider Second Address Line
Purchased Service Provider Secondary Identifier
Purchased Service Provider State Code
Purchased Service Provider ZIP Code
Quantity Qualifier
Record Format Code
Reference Identification Qualifier
Referral Number
Referring Provider City Name
Referring Provider Contact Name
Referring Provider First Address Line
Referring Provider First Name
Referring Provider Identification Number
Referring Provider Last Name
Referring Provider Middle Name
Referring Provider Name Additional Text
Referring Provider Name Suffix
Referring Provider Second Address Line
Referring Provider Secondary Identifier
Referring Provider State Code
Referring Provider ZIP Code
Reimbursement Rate
Reject Reason Code
Related Hospitalization Admission Date
Related Hospitalization Discharge Date
Related Nursing Home Admission Date
Related-Causes Code
Rendering Provider City Name
Rendering Provider Contact Name
Rendering Provider First Address Line
Rendering Provider First Name
Rendering Provider Identifier
Rendering Provider Last Name
Rendering Provider Middle Name
Rendering Provider Name Additional Text
Rendering Provider Name Suffix
Rendering Provider Second Address Line
Rendering Provider Secondary Identifier
Rendering Provider State Code
Rendering Provider ZIP Code
Rental Equipment Billing Frequency Code
Rental Price Amount
Repriced Claim Reference Number
Repriced Line Item Reference Number
Repricing Organization Identifier
Repricing Per Diem or Flat Rate Amount
Resource Utilization Group Number
Resubmission Number
Retirement or Insurance Card Date
Review By Code Indicator
Sales Tax Amount
Sample Selection Modules
Saving Amount
School City Name
School Contact Name
School First Address Line
School Name Additional Text
School Name
School Primary Identifier
School Second Address Line
School State Code
School ZIP Code
Second Admission Date
Second Discharge Date
Service Date
Service From Date
Service Line Paid Amount
Service Type Code
Service Unit Count
Ship/Delivery or Calendar Pattern Code
Ship/Delivery Pattern Time Code

[[Page 25313]]

Shipped Date
Similar Illness or Symptom Date
Special Program Indicator
Statement Covers Period End Date
Statement Covers Period Start Date
Student Status Code
Submittal Date
Submitted Charge Amount
Submitter or Receiver Address Line
Submitter or Receiver City Name
Submitter or Receiver Contact Name
Submitter or Receiver First Name
Submitter or Receiver Identifier
Submitter or Receiver Last or Organization Name
Submitter or Receiver Middle Name
Submitter or Receiver State Code
Submitter or Receiver ZIP Code
Submitter Additional Name
Subscriber or Dependent Death Date
Subscriber Additional Identifier
Subscriber Birth Date
Subscriber Contact Name
Subscriber First Name
Subscriber Gender Code
Subscriber Identifier
Subscriber Last Name
Subscriber Marital Status Code
Subscriber Middle Name
Subscriber Name Suffix
Subscriber Postal ZIP Code
Subscriber Second Address Line
Subscriber State
Supervising Provider City Name
Supervising Provider Contact Name
Supervising Provider First Address Line
Supervising Provider First Name
Supervising Provider Identification Number
Supervising Provider Last Name
Supervising Provider Middle Name
Supervising Provider Name Additional Text
Supervising Provider Name Suffix
Supervising Provider Second Address Line
Supervising Provider Secondary Identifier
Supervising Provider State Code
Supervising Provider ZIP Code
Supporting Document Question Identifier
Supporting Document Response Code
Surgical Procedure Code
Terms Discount Percentage
Test Performed Date
Test Results
Time Period Qualifier
Total Claim Charge Amount
Total Purchased Service Amount
Total Visits Rendered Count
Transaction Segment Count
Transaction Set Control Number
Transaction Set Identifier Code
Transaction Set Purpose Code
Treatment or Therapy Date
Treatment Length
Unit or Basis for Measurement Code
Value Added Network Trace Number
Version Identification Code
Version Identifier
Weekly Prescription Lipid Use Count
Work Return Date
X-Ray Availability Indicator Code

C. Institutional Claim or Equivalent Encounter

    The transaction selected for the institutional health care claim 
or equivalent encounter information is ASC X12N 837--Health Care 
Claim: Institutional (004010X096).

1. Implementation Guide and Source

    The source of the implementation guide for the institutional 
health care claim or equivalent encounter is: Washington Publishing 
Company, 806 W. Diamond Ave., Suite 400, Gaithersburg, MD, 20878, 
Telephone 301-590-9337, FAX: 301-869-9460. The web site address is 
<a href="http://www.wpc-edi.com/hipaa/

2">http://www.wpc-edi.com/hipaa/

2</a>. Data Elements

Activities Permitted
Adjusted Repriced Claim Reference Number
Adjustment Amount
Adjustment Quantity
Adjustment Reason Code
Admission Date and Hour
Admission Source Code
Admission Type Code
Allowed Amount
Amount Qualifier Code
Approved Amount
Approved Diagnosis Related Group Code
Approved HCPCS Code
Approved Revenue Code
Approved Service Unit Count
Assigned Number
Attachment Control Number
Attachment Description Text
Attachment Report Type Code
Attachment Transmission Code
Attending Physician First Name
Attending Physician Last Name
Attending Physician Middle Name
Attending Physician Primary Identifier
Auto Accident State or Province Code
Benefits Assignment Certification Indicator
Billing Note Text
Billing Provider City Name
Billing Provider Contact Name
Billing Provider First Address Line
Billing Provider Identifier
Billing Provider Last or Organizational Name
Billing Provider Postal Zone or ZIP Code
Billing Provider Second Address Line
Billing Provider State or Province Code
Certification Condition Indicator
Certification Type Code
Claim Adjustment Group Code
Claim Days Count
Claim Disproportionate Share Amount
Claim DRG Amount
Claim DRG Outlier Amount
Claim Encounter Identifier
Claim ESRD Payment Amount
Claim Filing Indicator Code
Claim Frequency Code
Claim HCPCS payable amount
Claim Indirect Teaching Amount
Claim MSP Pass-through amount
Claim Note Text
Claim Original Reference Number
Claim Payment Remark Code
Claim PPS capital amount
Claim PPS capital outlier amount
Claim Total Denied Charge Amount
Code Associated Amount
Code Associated Date
Code Associated Quantity
Code Category
Code List Qualifier Code
Contact Function Code
Contract Amount
Contract Code
Contract Percentage
Contract Type Code
Contract Version Identifier
Cost Report Day Count
Country Code
Covered Days or Visits Count
Creation Date
Credit or Debit Card Authorization Number
Credit or Debit Card Holder First Name
Credit or Debit Card Holder Last or Organizational Name
Credit or Debit Card Holder Middle Name
Credit or Debit Card Maximum Amount
Credit or Debit Card Number
Currency Code
Date Time Period Format Qualifier
Date/Time Qualifier
Diagnosis Date
Discharge Hour
Discipline Type Code
Document Control Identifier
Employer Identification Number
Employment Status Code
Entity Identifier Code
Entity Type Qualifier
Estimated Amount Due
Estimated Claim Due Amount
Exception Code
Explanation of Benefits Indicator
Facility Code Qualifier
Facility Type Code
File Creation Time
Frequency Number
Functional Limitation Code
Group or Policy Number
Hierarchical Child Code
Hierarchical ID Number
Hierarchical Level Code
Hierarchical Parent ID Number
Hierarchical Structure Code
Home Health Certification Period
HCPCS Modifier Code
HCPCS/CPT-4 Code
Identification Code Qualifier
Implant Date
Implant Status Code
Implant Type Code
Individual Relationship Code
Industry Code
Information Release Code
Insurance Type Code
Insured Employer First Address Line
Insured Employer First Name
Insured Employer Identifier
Insured Group Name
Insured Group Number
Investigational Device Exemption Identifier
Last Admission Date
Last Visit Date
Leads Left In Patient Indicator
Legal Representative City Name
Legal Representative Contact Name
Legal Representative First Address Line
Legal Representative First Name
Legal Representative Last or Organization Name
Legal Representative Middle Name
Legal Representative Second Address Line
Legal Representative State Code
Legal Representative ZIP Code
Lifetime Psychiatric Days Count
Lifetime Reserve Days Count
Line Charge Amount
Line Item Denied Charge or Non-Covered Charge Amount
Manufacturer Identifier
Medicare Coverage Indicator
Medicare Paid at 100% Amount

[[Page 25314]]

Medicare Paid at 80% Amount
Mental Status Code
Model Number
Non-Covered Charge Amount
Non-Insured Employer City Name
Non-Insured Employer First Address Line
Non-Insured Employer First Name
Non-Insured Employer Identifier
Non-Insured Employer Last or Organization Name
Non-Insured Employer Middle Name
Non-Insured Employer Second Address Line
Non-Insured Employer State Code
Non-Insured Employer ZIP Code
Note Reference Code
Old Capital Amount
Operating Physician First Name
Operating Physician Last Name
Operating Physician Middle Name
Operating Physician Primary Identifier
Ordering Provider Identifier
Ordering Provider Last Name
Originator Application Transaction Identifier
Other Employer City Name
Other Employer First Address Line
Other Employer First Name
Other Employer Last or Organization Name
Other Employer Second Address Line
Other Employer Secondary Identifier
Other Employer State Code
Other Employer ZIP Code
Other Insured Additional Identifier
Other Insured Birth Date
Other Insured City Name
Other Insured First Address Line
Other Insured First Name
Other Insured Gender Code
Other Insured Identifier
Other Insured Last Name
Other Insured Middle Name
Other Insured Plan Name or Program Name
Other Insured Second Address Line
Other Insured State Code
Other Insured ZIP Code
Other Payer City Name
Other Payer First Address Line
Other Payer Last or Organization Name
Other Payer Patient Paid Amount
Other Payer Primary Identifier
Other Payer Second Address Line
Other Payer Secondary Identifier
Other Payer State Code
Other Payer ZIP Code
Other Physician First Name
Other Physician Identifier
Other Physician Last Name
Other Physician Middle Name
Paid From Part A Medicare Trust Fund Amount
Paid From Part B Medicare Trust Fund Amount
Patient Account Number
Patient Amount Paid
Patient Birth Date
Patient City Name
Patient Discharge Facility Type Code
Patient First Address Line
Patient First Name
Patient Gender Code
Patient Last Name
Patient Liability Amount
Patient Marital Status Code
Patient Middle Name
Patient Name Suffix
Patient Primary Identifier
Patient Second Address Line
Patient Secondary Identifier
Patient State Code
Patient Status Code
Patient ZIP Code
Payer Additional Identifier
Payer City Name
Payer First Address Line
Payer Identifier
Payer Name
Payer Paid Amount
Payer Responsibility Sequence Number Code
Payer Second Address Line
Payer State Code
Payer ZIP Code
Period Count
Physician Contact Date
Physician Order Date
Policy Compliance Code
Pricing Methodology
Prior Authorization Number
Procedure Modifier
Product/Service ID Qualifier
Product/Service Procedure Code
Professional Component Amount
Prognosis Code
PPS-Capital DSH DRG Amount
PPS-Capital Exception Amount
PPS-Capital FSP DRG Amount
PPS-Capital HSP DRG Amount
PPS-Capital IME amount
PPS-Operating Federal Specific DRG Amount
PPS-Operating Hospital Specific DRG Amount
Quantity Qualifier
Reference Identification Qualifier
Reimbursement Rate
Reject Reason Code
Related-Causes Code
Repriced Claim Reference Number
Repricing Organization Identifier
Repricing Per Diem or Flat Rate Amount
Returned to Manufacturer Indicator
Saving Amount
School City Name
School First Address Line
School Name
School Primary Identifier
School Second Address Line
School State Code
School ZIP Code
Serial Number
Service Date
Service From Date
Service Line Paid Amount
Service Line Rate
Service Line Revenue Code
Service Unit Count
Statement From or To Date
Submission or Resubmission Number
Submitted Charge Amount
Submitter or Receiver Contact Name
Submitter or Receiver Identifier
Submitter or Receiver Last or Organization Name
Subscriber Additional Identifier
Subscriber Birth Date
Subscriber First Address Line
Subscriber First Name
Subscriber Gender Code
Subscriber Last Name
Subscriber Marital Status Code
Subscriber Middle Name
Subscriber Second Address Line
Subscriber State
Surgery Date
Surgical Procedure Code
Terms Discount Percentage
Time Period Qualifier
Total Claim Charge Amount
Total Medicare Paid Amount
Total Visits Projected This Certification Count
Transaction Segment Count
Transaction Set Control Number
Transaction Set Identifier Code
Transaction Set Purpose Code
Unit or Basis for Measurement Code
Value Added Network Trace Number
Version Identification Code
Visits Prior to Recertification Date Count
Warranty Expiration Date 1861J1 Facility Indicator

D. Dental Claim or Equivalent Encounter

    The transaction selected for the dental health care claim or 
equivalent encounter is: ASC X12N 837--Health Care Claim: Dental 
(004010X097).

1. Implementation Guide and Source

    The source of the implementation guide for the dental health 
care claim or equivalent encounter is: Washington Publishing 
Company, 806 W. Diamond Ave., Suite 400, Gaithersburg, MD, 20878, 
Telephone 301-590-9337, FAX: 301-869-9460. The web site address is 
<a href="http://www.wpc-edi.com/hipaa/

2">http://www.wpc-edi.com/hipaa/

2</a>. Data Elements

Accident Date
Adjudication or Payment Date
Adjustment Amount
Adjustment Quantity
Adjustment Reason Code
Admission Date or Start of Care Date
Amount Qualifier Code
Anesthesia Unit Count
Appliance Placement Date
Assigned Number
Assistant Surgeon City Name
Assistant Surgeon First Address Line
Assistant Surgeon First Name
Assistant Surgeon Last Name
Assistant Surgeon Middle Name
Assistant Surgeon Primary Identification Number
Assistant Surgeon Second Address Line
Assistant Surgeon State Code
Assistant Surgeon Suffix Name
Assistant Surgeon ZIP Code
Attachment Control Number
Attachment Report Type Code
Attachment Transmission Code
Auto Accident State or Province Code
Benefits Assignment Certification Indicator
Billing Provider City Name
Billing Provider Credit Card Identifier
Billing Provider First Address Line
Billing Provider First Name
Billing Provider Identifier
Billing Provider Last or Organizational Name
Billing Provider Middle Name
Billing Provider Name Suffix
Billing Provider Postal Zone or ZIP Code
Billing Provider Second Address Line
Billing Provider State or Province Code
Claim Adjustment Group Code
Claim Encounter Identifier
Claim Filing Indicator Code
Claim
Submission Reason Code
Clinical Laboratory Improvement Amendment Number

[[Page 25315]]

Code List Qualifier Code
Contact Function Code
Coordination of Benefits Code
Country Code
Creation Date
Credit or Debit Card Authorization Number
Credit or Debit Card Holder First Name
Credit or Debit Card Holder Last or Organizational Name
Credit or Debit Card Holder Middle Name
Credit or Debit Card Holder Name Suffix
Credit or Debit Card Maximum Amount
Credit or Debit Card Number
Credit/Debit Flag Code
Currency Code
Date Time Period Format Qualifier
Date/Time Qualifier
Destination Payer Code
Diagnosis Code
Diagnosis Date
Diagnosis Type Code
Discharge Date/End Of Care Date
Entity Identifier Code
Entity Type Qualifier
Facility Code Qualifier
Facility Type Code
File Creation Time
Group or Policy Number
Hierarchical Child Code
Hierarchical ID Number
Hierarchical Level Code
Hierarchical Parent ID Number
Hierarchical Structure Code
Identification Code Qualifier
Individual Relationship Code
Information Release Code
Information Release Date
Initial Placement Date
Insured Employer First Address Line
Insured Employer First Name
Insured Employer Identifier
Insured Employer Middle Name
Insured Employer Name Suffix
Insured Group Name
Insured Group Number
Laboratory or Facility City Name
Laboratory or Facility First Address Line
Laboratory or Facility Name
Laboratory or Facility Postal ZIP or Zonal Code
Laboratory or Facility Primary Identifier
Laboratory or Facility Second Address Line
Laboratory or Facility State or Province Code
Legal Representative or Responsible Party Identifier
Legal Representative City Name
Legal Representative First Address Line
Legal Representative First Name
Legal Representative Last or Organization Name
Legal Representative Middle Name
Legal Representative Second Address Line
Legal Representative State Code
Legal Representative Suffix Name
Legal Representative ZIP Code
Line Charge Amount
Medicare Assignment Code
Oral Cavity Designation Code
Originator Application Transaction Identifier
Orthodontic Treatment Months Count
Orthodontic Treatment Months Remaining Count
Other Insured Birth Date
Other Insured City Name
Other Insured First Address Line
Other Insured First Name
Other Insured Gender Code
Other Insured Identifier
Other Insured Last Name
Other Insured Middle Name
Other Insured Name Suffix
Other Insured Second Address Line
Other Insured State Code
Other Insured ZIP Code
Other Payer Covered Amount
Other Payer Discount Amount
Other Payer Last or Organization Name
Other Payer Patient Paid Amount
Other Payer Patient Responsibility Amount
Other Payer Primary Identifier
Patient Account Number
Patient Amount Paid
Patient Birth Date
Patient City Name
Patient First Address Line
Patient First Name
Patient Gender Code
Patient Last Name
Patient Marital Status Code
Patient Middle Name
Patient Name Suffix
Patient Primary Identifier
Patient Second Address Line
Patient Signature Source Code
Patient State Code
Patient ZIP Code
Pay-to-Provider City Name
Pay-to-Provider First Address Line
Pay-to-Provider First Name
Pay-to-Provider Identifier
Pay-to-Provider Last or Organizational Name
Pay-to-Provider Middle Name
Pay-to-Provider Name Suffix
Pay-to-Provider Second Address Line
Pay-to-Provider State Code
Pay-to-Provider ZIP Code
Payer Additional Identifier
Payer City Name
Payer First Address Line
Payer Identifier
Payer Name
Payer Paid Amount
Payer Responsibility Sequence Number Code
Payer Second Address Line
Payer State Code
Payer ZIP Code
Periodontal Charting Measurement
Policy Name
Predetermination of Benefits Identifier
Predetermination of Benefits Indicator
Prior Authorization Number
Prior Placement Date
Procedure Count
Procedure Modifier
Product/Service ID Qualifier
Product/Service Procedure Code
Prothesis, Crown or Inlay Code
Provider or Supplier Signature Indicator
Provider Signature Date
Quantity Qualifier
Reference Identification Qualifier
Referring Provider City Name
Referring Provider First Address Line
Referring Provider First Name
Referring Provider Identification Number
Referring Provider Last Name
Referring Provider Middle Name
Referring Provider Name Suffix
Referring Provider Second Address Line
Referring Provider State Code
Referring Provider ZIP Code
Related-Causes Code
Rendering Provider City Name
Rendering Provider First Address Line
Rendering Provider First Name
Rendering Provider Identifier
Rendering Provider Last Name
Rendering Provider Middle Name
Rendering Provider Name Suffix
Rendering Provider Second Address Line
Rendering Provider State Code
Rendering Provider ZIP Code
Replacement Date
Retirement or Insurance Card Date
School City Name
School First Address Line
School Name
School Primary Identifier
School Second Address Line
School State Code
School ZIP Code
Service Date
Service Line Paid Amount
Student Status Code
Submitter or Receiver Address Line
Submitter or Receiver City Name
Submitter or Receiver Contact Name
Submitter or Receiver First Name
Submitter or Receiver Identifier
Submitter or Receiver Last or Organization Name
Submitter or Receiver Middle Name
Submitter or Receiver State Code
Submitter or Receiver ZIP Code
Subscriber Birth Date
Subscriber First Address Line
Subscriber First Name
Subscriber Gender Code
Subscriber Identifier
Subscriber Last Name
Subscriber Marital Status Code
Subscriber Middle Name
Subscriber Name Suffix
Subscriber Postal ZIP Code
Subscriber Second Address Line
Subscriber State
Title XIX Identification Number
Tooth Code
Tooth Number
Tooth Status Code
Tooth Surface
Total Claim Charge Amount
Transaction Segment Count
Transaction Set Control Number
Transaction Set Identifier Code
Transaction Set Purpose Code
Unit or Basis for Measurement Code

Addendum 2--Health Care Payment and Remittance Advice

    The transaction selected for the health care payment and 
remittance advice is ASC X12N 835--Health Care Claim Payment/Advice 
(004010X091).

A. Implementation Guide and Source

    The source of the implementation guide for the ASC X12N 835--
Health Care Claim Payment/Advice (004010X091) is: Washington 
Publishing Company, 806 W. Diamond Ave., Suite 400, Gaithersburg, 
MD, 20878, Telephone 301-590-9337, FAX: 301-869-9460. The website 
address is <a href="http://www.wpc-edi.com/hipaa/

B">http://www.wpc-edi.com/hipaa/

B</a>. Data Elements

Account Number Qualifier
Additional Payee Identifier

[[Page 25316]]

Adjustment Amount
Adjustment Quantity
Adjustment Reason Code
Amount Paid to Patient
Amount Qualifier Code
Assigned Number
Average DRG length of stay
Average DRG weight
Century
Check or EFT Trace Number
Check/EFT Issue Date
Claim Adjustment Group Code
Claim Contact Communications Number
Claim Contact Name
Claim Date
Claim Disproportionate Share Amount
Claim ESRD Payment Amount
Claim Filing Indicator Code
Claim Frequency Code
Claim HCPCS payable amount
Claim Indirect Teaching Amount
Claim MSP Pass-through amount
Claim Payment Remark Code
Claim PPS capital amount
Claim PPS capital outlier amount
Claim Status Code
Claim Supplemental Information Amount
Claim Supplemental Information Quantity
Code List Qualifier Code
Communication Number Extension
Communication Number Qualifier
Contact Function Code
Corrected Insured Identification Indicator
Corrected Patient or Insured First Name
Corrected Patient or Insured Last Name
Corrected Patient or Insured Middle Name
Corrected Patient or Insured Name Prefix
Corrected Patient or Insured Name Suffix
Corrected Priority Payer Identification Number
Corrected Priority Payer Name
Cost Report Day Count
Covered Days or Visits Count
Credit/Debit Flag Code
Crossover Carrier Identifier
Crossover Carrier Name
Currency Code
Date/Time Qualifier
Depository Financial Institution (DFI) Identifier
Depository Financial Institution (DFI) ID Number Qualifier
Description Text
Diagnosis Related Group (DRG) Weight
Diagnosis Related Group (DRG)
Discharge Fraction
Entity Identifier Code
Entity Type Qualifier
Exchange Rate
Facility Type Code
Fiscal Period Date
Identification Code Qualifier
Lifetime Psychiatric Days Count
Line Item Provider Payment Amount
Location Identification Code
Location Qualifier
National Uniform Billing Committee Revenue Code
Old Capital Amount
Original Service Unit Count
Originating Company Supplemental Code
Other Claim Related Identifier
Patient Control Number
Patient First Name
Patient Last Name
Patient Liability Amount
Patient Middle Name
Patient Name Prefix
Patient Name Suffix
Patient Status Code
Payee City Name
Payee First Line Address
Payee Identification Code
Payee Name
Payee Postal Zip Code
Payee Second Line Address
Payee State Code
Payer City Name
Payer Claim Control Number
Payer Contact Communication Number
Payer Contact Name
Payer First Address Line
Payer Identifier
Payer Name
Payer Process Date
Payer Second Address Line
Payer State Code
Payer ZIP Code
Payment Format Code
Payment Method Code
Procedure Modifier
Product/Service ID Qualifier
Product/Service Procedure Code Text
Product/Service Procedure Code
Production Date
Professional Component Amount
Provider Adjustment Amount
Provider Adjustment Identifier
Provider First Name
Provider Identifier
Provider Last or Organization Name
Provider Middle Name
Provider Name Prefix
Provider Name Suffix
PPS-Capital DSH DRG Amount
PPS-Capital Exception Amount
PPS-Capital FSP DRG Amount
PPS-Capital HSP DRG Amount
PPS-Capital IME amount
PPS-Operating Federal Specific DRG Amount
PPS-Operating Hospital Specific DRG Amount
Quantity Qualifier
Receiver or Provider Account Number
Receiver Identifier
Receiver/Provider Bank ID Number
Reference Identification Qualifier
Reimbursement Rate
Remark Code
Sender Account Number
Sender DFI Identifier
Service Date
Service Supplemental Amount
Service Supplemental Quantity Count
Submitted Charge Amount
Submitted Line Charges Paid
Subscriber First Name
Subscriber Identifier
Subscriber Last Name
Subscriber Middle Name
Subscriber Name Prefix
Subscriber Name Suffix
Total Actual Provider Payment Amount
Total Blood Deductible
Total Capital Amount
Total Claim Charge Amount
Total Claim Count
Total Coinsurance Amount
Total Contractual Adjustment Amount
Total Cost Outlier Amount
Total Cost Report Day Count
Total Covered Charge Amount
Total Covered Day Count
Total Day Outlier Amount
Total Deductible Amount
Total Denied Charge Amount
Total Discharge Count
Total Disp. Share Amount
Total DRG Amount
Total Federal-Specific Amount
Total Gramm-Rudman Reduction Amount
Total Hospital-Specific Amount
Total HCPCS Payable Amount
Total HCPCS Reported Charge Amount
Total Indirect Medical Education Amount
Total Interest Amount
Total MSP Pass-Through Amount
Total MSP Patient Liability Met Amount
Total MSP Payer Amount
Total Non-Covered Charge Amount
Total Non-Lab Charge Amount
Total Noncovered Charge Amount
Total Noncovered Day Count
Total Outlier Day Count
Total Patient Reimbursement Amount
Total Professional Component Amount
Total Provider Payment Amount
Total PIP Adjustment Amount
Total PIP Claim Count
Total PPS Capital FSP DRG Amount
Total PPS Capital HSP DRG Amount
Total PPS DSH DRG Amount
Trace Type Code
Transaction Handling Code
Transaction Segment Count
Transaction Set Control Number
Transaction Set Identifier Code
Units of Service Paid Count
Version Identifier

Addendum 3--Coordination of Benefits

A. Professional Claim Coordination of Benefits

    The transaction selected for the professional claim coordination 
of benefits is ASC X12N 837--Health Care Claim: Professional 
(004010X098).

1. Implementation Guide and Source

    The source of the implementation guide for the professional 
claim coordination of benefits transaction set is: Washington 
Publishing Company, 806 W. Diamond Ave., Suite 400, Gaithersburg, 
MD, 20878, Telephone 301-590-9337, FAX: 301-869-9460. The web site 
address is <a href="http://www.wpc-edi.com/hipaa/

2">http://www.wpc-edi.com/hipaa/

2</a>. Data Elements

    Data elements are found in addendum 1, B.2.

B. Institutional Claim Coordination of Benefits

    The transaction selected for the institutional claim 
coordination of benefits is ASC X12N 837--Health Care Claim: 
Institutional (004010X096).

1. Implementation Guide and Source

    The source of the implementation guide for the institutional 
claim coordination of benefits transaction set is: Washington 
Publishing Company, 806 W. Diamond Ave., Suite 400, Gaithersburg, 
MD, 20878, Telephone 301-590-9337, FAX: 301-869-9460. The web site 
address is http://www.wpc-edi.com/hipaa/

[[Page 25317]]

2. Data Elements

    Data elements are found in Addendum 1, C.2.

C. Dental Claim Coordination of Benefits

    The transaction selected for the dental claim coordination of 
benefits is ASC X12N 837--Health Care Claim: Dental (004010X097).

1. Implementation Guide and Source

    The source of implementation guide for the dental claim 
coordination of benefits transaction set is: Washington Publishing 
Company, 806 W. Diamond Ave., Suite 400, Gaithersburg, MD, 20878, 
Telephone 301-590-9337, FAX: 301-869-9460. The web site address is 
<a href="http://www.wpc-edi.com/hipaa/

2">http://www.wpc-edi.com/hipaa/

2</a>. Data Elements

    See Addendum 1, D.2.

D. Retail Drug Claim Coordination of Benefits

    The transactions selected for retail drug coordination of 
benefits is NCPDP Telecommunications Standard Format version 3.2 and 
the equivalent NCPDP Batch Standard Version 1.0.

1. Implementation Guide and Source

    The source of implementation guide for the retail drug claim 
coordination of benefits transaction set is: National Council for 
Prescription Drug Programs, 4201 North 24th Street, Suite 365, 
Phoenix, AZ, 85016, Telephone 602-957-9105, FAX 602-955-0749. The 
web site address is http://www.ncpdp.org

2. Data Elements

    See Addendum 1, A.2.

Addendum 4--Health Claim Status

    The transaction selected for the health claim status is ASC X12N 
276/277--Health Care Claim Status Request and Response (004010X093).

A. Implementation Guide and Source

    The source of the implementation guide for the health claim 
status transaction set is: Washington Publishing Company, 806 W. 
Diamond Ave., Suite 400, Gaithersburg, MD, 20878, Telephone 301-590-
9337, FAX: 301-869-9460. The website address is http://www.wpc-
edi.com/hipaa/

B. Data Elements

Adjudication or Payment Date
Amount Qualifier Code
Bill Type Identifier
Check or EFT Trace Number
Check/EFT Issue Date
Claim Payment Amount
Claim Service Period
Creation Date
Date Time Period Format Qualifier
Date/Time Qualifier
Entity Identifier Code
Entity Type Qualifier
Extra Narrative Data
Health Care Claim Status Category Code
Health Care Claim Status Code
Hierarchical Child Code
Hierarchical ID Number
Hierarchical Level Code
Hierarchical Parent ID Number
Hierarchical Structure Code
Identification Code Qualifier
Information Receiver Additional Address
Information Receiver Address
Information Receiver City
Information Receiver First Name
Information Receiver Identification Number
Information Receiver Last or Organization Name
Information Receiver Middle Name
Information Receiver Name Prefix
Information Receiver Name Suffix
Information Receiver Specific Location
Information Receiver State
Information Receiver ZIP Code
Line Charge Amount
Line Item Control Number
Line Item Service Date
Location Qualifier
Original Service Unit Count
Originator Application Transaction Identifier
Patient Control Number
Patient First Name
Patient Last Name
Patient Middle Name
Patient Name Prefix
Patient Name Suffix
Payer City Name
Payer Claim Control Number
Payer First Address Line
Payer Identifier
Payer Name
Payer Second Address Line
Payer State Code
Payer ZIP Code
Payment Method Code
Procedure Modifier
Product/Service ID Qualifier
Provider First Name
Provider Identifier
Provider Last or Organization Name
Provider Middle Name
Provider Name Prefix
Provider Name Suffix
Reference Identification Qualifier
Revenue Code
Service Identification Code
Service Line Date
Service Unit Count
Status Information Effective Date
Subscriber Birth Date
Subscriber City
Subscriber First Address Line
Subscriber First Name
Subscriber Gender Code
Subscriber Identifier
Subscriber Last Name
Subscriber Middle Name
Subscriber Name Prefix
Subscriber Name Suffix
Subscriber Postal ZIP Code
Subscriber Second Address Line
Subscriber State
Total Claim Charge Amount
Trace Type Code
Transaction Segment Count
Transaction Set Control Number
Transaction Set Identifier Code
Transaction Set Purpose Code
Transaction Type Code

[Direct Comments to Judy Ball, Enrollment and Eligibility IT]

Addendum 5--Benefit Enrollment and Maintenance

    The transaction selected for benefit enrollment and maintenance 
is ASC X12N 834--Benefit Enrollment and Maintenance Transaction Set 
(004010X095).

A. Implementation Guide and Source

    The source of the implementation guide for the benefit 
enrollment and maintenance transaction set is: Washington Publishing 
Company, 806 W. Diamond Ave., Suite 400, Gaithersburg, MD, 20878, 
Telephone 301-590-9337, FAX: 301-869-9460. The web site address is 
<a href="http://www.wpc-edi.com/hipaa/

B">http://www.wpc-edi.com/hipaa/

B</a>. Data Elements

Label--name of elements
Account Address Information
Account City Name
Account Communication Number
Account Contact Inquiry Reference Number
Account Contact Name
Account Country Code
Account Effective Date
Account Identification Code
Account Monetary Amount
Account Number Qualifier
Account Postal ZIP Code
Account State Code
Action Code
Additional Account Identifier
Additional Other Coverage Identifier
Adjustment Amount
Adjustment Reason Code Characteristic
Adjustment Reason Code
Amount Qualifier Code
Assigned Number
Benefit Account Number
Benefit Status Code
Birth Sequence Number
Card Count
Citizenship Status Code
Code List Qualifier Code
Communication Number Qualifier
Communication Number
Consolidated Omnibus Budget Reconciliation Act (COBRA) Qualifying 
Event Code
Contact Function Code
Contact Inquiry Reference
Coordination of Benefits Code
Coordination of Benefits Date
Country Code
Coverage Level Code
Creation Date
Credit/Debit Flag Code
Current Health Condition Code
Date Time Period Format Qualifier
Date/Time Qualifier
Dependent Employer Identification Code
Dependent Employer Name
Dependent Employment Date
Dependent School Date
Dependent School Identification Code
Dependent School Name
Description Text
Diagnosis Code
Disability Eligibility Date
Disability Maximum Entitlement Amount
Disability Type Code
Employment Status Code
Enrollment Control Total
Entity Identifier Code
Entity Relationship Code
Entity Type Qualifier
File Creation Time
First Diagnosed Date
Frequency Code
Gender Code
Group or Policy Number

[[Page 25318]]

Health Coverage Eligibility Date
Health-Related Code
Identification Card Type Code
Identification Code Qualifier
Individual Relationship Code
Industry Code
Insurance Eligibility Date
Insurance Group Number
Insurance Line Code
Insurer Contact Inquiry Reference
Insurer Contact Name
Insurer Contact Number
Insurer Entity Relationship Code
Insurer Identification Code
Insurer Name
Issuing State
Last Visit Reason Text
Late Reason Code
Location Qualifier
Maintenance Reason Code
Maintenance Type Code
Marital Status Code
Master Policy Number
Medicare Plan Code
Member Additional Address
Member City Name
Member Contact Name
Member Postal Code
Member State or Province Code
Monetary Amount
Occupation Code
Other Insurance Company Identification Code
Other Insurance Company Name
Payer Responsibility Sequence Number Code
Plan Coverage Description Text
Policy Name
Pre-disability Work Days Count
Premium Contribution Amount
Previous Transaction Identifier
Primary Insured Collateral Dependent Count
Primary Insured Sponsored Dependent Count
Product Option Code
Product/Service ID Qualifier
Provider Code
Provider Communications Number
Provider Contact Inquiry Reference
Provider Contact Name
Provider Eligibility Date
Provider First Name
Provider Identifier
Provider Last or Organization Name
Provider Middle Name
Provider Name Prefix
Provider Name Suffix
Quantity Count
Quantity Qualifier
Race or Ethnicity Code
Reference Identification Qualifier
Sponsor Additional Name
Sponsor City Name
Sponsor Contact Name
Sponsor Country Code
Sponsor Identifier
Sponsor Name
Sponsor State Code
Sponsor Street Address
Sponsor Zip Code
Student Status Code
Subscriber or Dependent Death Date
Subscriber Additional Identifier
Subscriber Birth Date
Subscriber City
Subscriber County Code
Subscriber Current Weight
Subscriber First Address Line
Subscriber First Name
Subscriber Height
Subscriber Identifier
Subscriber Last Name
Subscriber Middle Name
Subscriber Name Prefix
Subscriber Name Suffix
Subscriber Postal ZIP Code
Subscriber Previous Weight
Subscriber Second Address Line
Subscriber State
Time Zone Code
Transaction Segment Count
Transaction Set Control Number
Transaction Set Identifier Code
Transaction Set Purpose Code
TPA or Broker Account Address
TPA or Broker Account Amount
TPA or Broker Account City Name
TPA or Broker Account Contact Communication Number
TPA or Broker Account Contact Inquiry Reference
TPA or Broker Account Contact Name
TPA or Broker Account Number
TPA or Broker Account Postal Code
TPA or Broker Account State or Province Code
TPA or Broker Additional Account Reference Identification Number
TPA or Broker Additional Name
TPA or Broker Communication Number
TPA or Broker Contact Inquiry Reference Number
TPA or Broker Country Code
TPA or Broker Identification Code
TPA or Broker Name
TPA or Broker State Code
Underwriting Decision Code
Version Identification Code
Weight Change Text
Work Intensity Code
Yes/No Condition or Response Code

Addendum 6--Eligibility for a Health Plan

    The transaction selected for the eligibility for a health plan 
is ASC X12N 270/271--Health Care Eligibility Inquiry and Response 
(004010X092).

A. Implementation Guide and Source

    The source of the implementation guide for eligibility for a 
health plan transaction set is: Washington Publishing Company, 806 
W. Diamond Ave., Suite 400, Gaithersburg, MD, 20878, Telephone 301-
590-9337, FAX: 301-869-9460. The website address is http://www.wpc-
edi.com/hipaa/

B. Data Elements

Labels
Agency Qualifier Code
Amount Qualifier Code
Authorization Indicator Code
Benefit Coverage Level Code
Benefit Used or Available Amount
Birth Sequence Number
Communication Number Qualifier
Communication Number
Contact Function Code
Country Code
Coverage Level Code
Creation Date
Date Time Period Format Qualifier
Date/Time Qualifier
Dependent Additional Identification Text
Dependent Additional Identifier
Dependent Benefit Date
Dependent Birth Date
Dependent City Name
Dependent Communications Number
Dependent Contact Name
Dependent First Line Address
Dependent First Name
Dependent Gender Code
Dependent Identification Code
Dependent Last Name
Dependent Middle Name
Dependent Name Suffix
Dependent Postal Zip Code
Dependent Second Line Address
Dependent State Code
Dependent Trace Number
Description Text
Eligibility or Benefit Amount
Eligibility or Benefit Information
Eligibility or Benefit Percent
Entity Identifier Code
Entity Type Qualifier
File Creation Time
Follow-up Action Code
Free-Form Message Text
Handicap Indicator Code
Hierarchical Child Code
Hierarchical ID Number
Hierarchical Level Code
Hierarchical Parent ID Number
Hierarchical Structure Code
Identification Code Qualifier
Individual Relationship Code
Information Receiver Additional Address
Information Receiver Additional Identifier
Information Receiver Address
Information Receiver City
Information Receiver Contact Name
Information Receiver First Name
Information Receiver Identification Number
Information Receiver Last or Organization Name
Information Receiver Middle Name
Information Receiver Name Suffix
Information Receiver State
Information Receiver Trace Number
Information Receiver ZIP Code
Information Source Contact Name
Information Source Process Date
Insurance Eligibility Date
Insurance Type Code
Insured Indicator
Location Identification Code
Location Qualifier
Loop Identifier Code
Maintenance Reason Code
Maintenance Type Code
Network Services Code
Originating Company Identifier
Originating Company Secondary Identifier
Period Count
Plan Coverage Description Text
Plan Sponsor Name
Printer Carriage Control Code
Prior Authorization Number
Prior Authorization Text
Procedure Coding Method
Procedure Modifier
Product/Service ID Qualifier
Provider Address 1
Provider Address 2
Provider City
Provider Code
Provider Contact Name
Provider Contact Number
Provider First Name

[[Page 25319]]

Provider Identifier
Provider Last or Organization Name
Provider Middle Name
Provider Name Suffix
Provider Specialty Certification Code
Provider Specialty Code
Provider State
Provider Zip
Quantity Qualifier
Receiver Additional Identifier Description Text
Receiver Additional Identifier
Receiver Provider Additional Identifier Type Code
Receiver Provider Additional Identifier
Receiver Trace Number
Reference Identification Qualifier
Reject Reason Code
Relationship To Insured Code
Sample Selection Modulus
Service Type Code
Service Unit Count
Ship/Delivery or Calendar Pattern Code
Ship/Delivery Pattern Time Code
Source Additional Reference Identifier
Source City Name
Source Organization Name
Source Postal Zip Code
Source Primary Identification Number
Source State Code
Source Street Address
Spend Down Amount
Student Status Code
Subscriber Additional Identifier
Subscriber Additional Information Text
Subscriber Benefit Date
Subscriber Birth Date
Subscriber Card Issue Date
Subscriber City
Subscriber Contact Name
Subscriber Contact Phone Number
Subscriber First Address Line
Subscriber First Name
Subscriber Gender Code
Subscriber Identifier
Subscriber Last Name
Subscriber Middle Name
Subscriber Name Suffix
Subscriber Postal ZIP Code
Subscriber Second Address Line
Subscriber State
Time Period Qualifier
Trace Assigning Entity Additional Number
Trace Assigning Entity Number
Trace Number
Trace Type Code
Transaction Segment Count
Transaction Set Control Number
Transaction Set Identifier Code
Transaction Set Purpose Code
Transaction Type Code
Unit or Basis for Measurement Code
Valid Request Indicator Code
Value Added Network Trace Number

Addendum 7--Health Plan Premium Payment

    The transaction selected for the health plan premium payment is 
ASC X12N 820--Payment Order/Remittance Advice Transaction Set 
(004010X061).

A. Implementation Guide and Source

    The source of the implementation guide for the health plan 
premium payment transaction set is: Washington Publishing Company, 
806 W. Diamond Ave., Suite 400, Gaithersburg, MD, 20878, Telephone 
301-590-9337, FAX: 301-869-9460. The website address is <a href="http://
www.wpc-edi.com/hipaa/

B">http://
www.wpc-edi.com/hipaa/

B</a>. Data Elements

Account Number Qualifier
Adjustment Reason Code
Assigned Number
Billed Premium Amount
Contact Function Code
Contract or Invoice or Account Number
Country Code
Coverage Period Date
Credit/Debit Flag Code
Currency Code
Date Time Period Format Qualifier
Date/Time Qualifier
Depository Financial Institution (DFI) Identifier
Depository Financial Institution (DFI) ID Number Qualifier
Employee Identification Number
Entity Identifier Code
Exchange Rate
Funds Issued Date
Head Count
Identification Code Qualifier
Individual Identifier
Information Only Indicator Code
Information Receiver City
Information Receiver Last or Organization Name
Information Receiver State
Information Receiver ZIP Code
Insurance Policy or Plan Identifier
Line Item Control Number
Organization Premium Identification Code
Originating Company Identifier
Originating Company Supplemental Code
Payer Additional Name
Payer City Name
Payer Contact Name
Payer Identifier
Payer Name
Payer Process Date
Payer Second Address Line
Payer State Code
Payer ZIP Code
Payment Action Code
Payment Format Code
Payment Method Code
Payroll Processor Additional Name
Payroll Processor City Name
Payroll Processor Contact Name
Payroll Processor First Address Line
Payroll Processor Identifier
Payroll Processor Name
Payroll Processor Second Address Line
Payroll Processor State Code
Payroll Processor ZIP Code
Policy Level Individual Name
Premium Delivery Date
Premium Payment Amount
Premium Receiver First Address Line
Premium Receiver Reference Identifier
Premium Receiver Second Address Line
Receiver Account Number
Receiver Additional Name
Receiver Identifier
Reference Identification Qualifier
Sender Account Number
Trace Number
Trace Type Code
Transaction Handling Code
Transaction Segment Count
Transaction Set Control Number
Transaction Set Identifier Code
Unit or Basis for Measurement Code

Addendum 8--Referral Certification and Authority

    The transaction selected for the referral certification and 
authority is ASC X12N 278--Health Care Services Review Information 
(004010X094).

A. Implementation Guide and Source

    The source of the implementation guide for the referral 
certification and authority is: Washington Publishing Company, 806 
W. Diamond Ave., Suite 400, Gaithersburg, MD, 20878, Telephone 301-
590-9337, FAX: 301-869-9460. The website address is http://www.wpc-
edi.com/hipaa/

B. Data Elements

Action Code
Admission Source Code
Admission Type Code
Agency Qualifier Code
Ambulance Transport Code
Ambulance Transport Reason Code
Ambulance Trip Destination Address
Ambulance Trip Origin Address
Arterial Blood Gas Quantity
Certification Condition Indicator
Certification Expiration Date
Certification Number
Certification Type Code
Chiropractic Series Treatment Number
Citizenship Status Code
Code Category
Code List Qualifier Code
Communication Number Qualifier
Complication Indicator
Condition Codes
Contact Function Code
Country Code
Creation Date
Current Health Condition Code
Daily Oxygen Use Count
Date Time Period Format Qualifier
Date/Time Qualifier
Delay Reason Code
Dependent Additional Identification Text
Dependent Additional Identifier
Dependent Birth Date
Dependent Citizenship Country Code
Dependent First Name
Dependent Gender Code
Dependent Identification Code
Dependent Last Name
Dependent Marital Status Code
Dependent Middle Name
Dependent Name Prefix
Dependent Name Suffix
Dependent Trace Number
Diagnosis Code
Diagnosis Date
Diagnosis Type Code
Entity Identifier Code
Entity Type Qualifier
Equipment Reason Description
Facility Code Qualifier
Facility Type Code
File Creation Time
Follow-up Action Code
Free-Form Message Text
Full Destination Address
Full Origin Address
Hierarchical Child Code
Hierarchical ID Number

[[Page 25320]]

Hierarchical Level Code
Hierarchical Parent ID Number
Hierarchical Structure Code
Home Health Certification Period
Identification Code Qualifier
Information Release Code
Insured Indicator
Last Admission Date
Last Visit Date
Level of Service Code
Medicare Coverage Indicator
Monthly Treatment Count
Nature of Condition Code
Nursing Home Residential Status Code
Originator Application Transaction Identifier
Oxygen Delivery System Code
Oxygen Equipment Type Code
Oxygen Flow Rate
Oxygen Saturation Quantity
Oxygen Test Condition Code
Oxygen Test Findings Code
Oxygen Use Period Hour Count
Patient Condition Description Text
Patient Discharge Facility Type Code
Patient Status Code
Patient Weight
Period Count
Physician Contact Date
Physician Order Date
Portable Oxygen System Flow Rate
Previous Certification Identifier
Procedure Date
Procedure Monetary Amount
Procedure Quantity
Product/Service ID Qualifier
Product/Service Procedure Code Text
Product/Service Procedure Code
Prognosis Code
Proposed Admission Date
Proposed Discharge Date
Proposed Surgery Date
Provider Code
Provider Contact Name
Provider Identifier
Provider Service State Code
Provider Specialty Certification Code
Provider Specialty Code
Quantity Qualifier
Race or Ethnicity Code
Reference Identification Qualifier
Reject Reason Code
Related-Causes Code
Relationship To Insured Code
Request Category Code
Requester Address First Address Line
Requester Address Second Address Line
Requester City Name
Requester Contact Communication Number
Requester Contact Name
Requester Country Code
Requester First Name
Requester Identifier
Requester Last or Organization Name
Requester Middle Name
Requester Name Prefix
Requester Name Suffix
Requester Postal Code
Requester State or Province Code
Requester Supplemental Identifier
Respiratory Therapist Order Text
Round Trip Purpose Description Text
Sample Selection Modulus
Second Surgical Opinion Indicator
Service Authorization Date
Service From Date
Service Provider City Name
Service Provider Contact Communication Number
Service Provider Country Code
Service Provider First Address Line
Service Provider First Name
Service Provider Identifier
Service Provider Last or Organization Name
Service Provider Middle Name
Service Provider Name Prefix
Service Provider Name Suffix
Service Provider Postal Code
Service Provider Second Address Line
Service Provider State or Province Code
Service Provider Supplemental Identifier
Service Trace Number
Service Type Code
Service Unit Count
Ship/Delivery or Calendar Pattern Code
State Code
Stretcher Purpose Description Text
Subluxation Level Code
Subscriber Additional Identifier
Subscriber Additional Information Text
Subscriber Birth Date
Subscriber Citizenship Country Code
Subscriber First Name
Subscriber Gender Code
Subscriber Identifier
Subscriber Last Name
Subscriber Marital Status Code
Subscriber Middle Name
Subscriber Name Prefix
Subscriber Name Suffix
Subscriber Trace Number
Surgery Date
Surgical Procedure Code
Time Period Qualifier
Trace Type Code
Transaction Segment Count
Transaction Set Control Number
Transaction Set Identifier Code
Transaction Set Purpose Code
Transaction Type Code
Transport Distance
Treatment Count
Treatment Period Count
Treatment Series Number
Unit or Basis for Measurement Code
Utilization Management Organization (UMO) or Last Name
Utilization Management Organization (UMO) First Address Line
Utilization Management Organization (UMO) First Name
Utilization Management Organization (UMO) Middle Name
Utilization Management Organization (UMO) Name Prefix
Utilization Management Organization (UMO) Name Suffix
Utilization Management Organization (UMO) Second Address Line
Utilization Managment Organization (UMO) City Name
Utilization Managment Organization (UMO) Contact Communication 
Number
Utilization Managment Organization (UMO) Contact Name
Utilization Managment Organization (UMO) Country Code
Utilization Managment Organization (UMO) Identifier
Utilization Managment Organization (UMO) Postal Code
Utilization Managment Organization (UMO) State or Province Code
Valid Request Indicator Code
Version/Release/Industry Identifier
X-Ray Availability Indicator Code 1861J1 Facility Indicator

[FR Doc. 98-11691 Filed 5-1-98; 9:04 am]
BILLING CODE 4120-01-P


</pre><script data-cfasync="false" src="/cdn-cgi/scripts/5c5dd728/cloudflare-static/email-decode.min.js"></script></body>
</html>