[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: [email protected]. 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: http://aspe.os.dhhs.gov/
admnsimp.
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.
The Secretary may adopt a standard developed, adopted, or
modified by a standard setting organization (that is, an organization
accredited by the American National Standards Institute (ANSI)) that
has consulted with the National Uniform Billing Committee (NUBC), the
National Uniform Claim Committee (NUCC), the Workgroup for Electronic
Data Interchange (WEDI), and the American Dental Association (ADA).
The Secretary may also adopt a standard other than one
established by a standard setting organization, if the different
standard will reduce costs for health care providers and health plans,
the different standard is promulgated through negotiated rulemaking
procedures, and the Secretary consults with each of the above-named
groups.
If no standard has been adopted by any standard setting
organization, the Secretary is to rely on the recommendations of the
National Committee on Vital and Health Statistics (NCVHS) and consult
with the above-named groups.
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:
Participate with standards setting organizations.
Provide written input to the NCVHS.
Provide written input to the Secretary of the HHS.
Provide testimony at NCVHS' public meetings.
Comment on the proposed rules for each of the proposed
standards.
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--
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
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:
Diseases, injuries, impairments, other health related
problems, and their manifestations;
Causes of injury, disease, impairment, or other health-
related problems;
Actions taken to prevent, diagnose, treat, or manage
diseases, injuries, and impairments and any substances, equipment,
supplies, or other items used to perform these actions; 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.
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.
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.
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.
CDT, which is used by all practicing dentists to code
their services for administrative transactions.
NIC (Nursing Interventions Classification), which is not
used in administrative transactions in this country.
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.
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: http://www.cdc.gov/nchswww/
nchshome.htm) 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 http://
www.cdc.gov/nchswww/about/otheract/icd9/icd9hp2.htm. 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 http://
www.hcfa.gov/stats/pufiles.htm. 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/ and text, the 1998 Alpha-
Numeric Index in both Portable Document Format/ (PDF) and
text, the 1998 Table of Drugs in both PDF and text, the 1998 HCPCS
record layout in WordPerfect/ and text, and a read me file
in WordPerfect/ 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:
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.
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.
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.
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.
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.
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.
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.
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.
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.
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:
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.
Health care payment and remittance advice: ASC X12N 835--
Health Care Payment/Advice.
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.
Health claim status: ASC X12N 276/277--Health Care Claim
Status Request and Response.
Enrollment and disenrollment in a health plan: ASC X12
834--Benefit Enrollment and Maintenance.
Eligibility for a health plan: ASC X12N 270/271--Health
Care Eligibility Benefit Inquiry and Response.
Health plan premium payments: ASC X12 820--Payment Order/
Remittance Advice.
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:
Version 4010 is millennium ready.
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:
Retail drug: NCPDP Telecommunications Standard Format
Version 3.2.
Dental claim: ASC X12N 837--health care claim: dental,
version 3070 implementation.
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:
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.
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: 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.
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: http://www.wpc-edi.com/
hipaa/. 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:
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.
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.
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.
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.
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:
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.
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.
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.)
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:
The need for the information collection and its usefulness
in carrying out the proper functions of our agency.
The accuracy of our estimate of the information collection
burden.
The quality, utility, and clarity of the information to be
collected.
Recommendations to minimize the information collection
burden on the affected public, including automated collection
techniques.
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[email protected] (Attn:HCFA-0149) or mail
copies directly to the following:
Health Care Financing Administration, Office of Information Services,
Information Technology Investment Management Group, Division of HCFA
Enterprise Standards, Room C2-26-17, 7500 Security Boulevard,
Baltimore, MD 21244-1850. Attn: 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:
Improve the efficiency and effectiveness of the health
care system by leading to cost reductions for or improvements in
benefits from electronic HIPAA health care transactions. This principle
supports the regulatory goals of cost-effectiveness and avoidance of
burden.
Meet the needs of the health data standards user
community, particularly health care providers, health plans, and health
care clearinghouses. This principle supports the regulatory goal of
cost-effectiveness.
Be consistent and uniform with the other HIPAA standards
(that is, their data element definitions and codes and their privacy
and security requirements) and, 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.
Have low additional development and implementation costs
relative to the benefits of using the standard. This principle supports
the regulatory goals of cost-effectiveness and avoidance of burden.
Be supported by an ANSI-accredited 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.
Have timely development, testing, implementation, and
updating procedures to achieve administrative simplification benefits
faster. This principle establishes a performance objective for the
standard.
Be technologically independent of the computer platforms
and transmission protocols used in HIPAA health transactions, except
when they are explicitly part of the standard. This principle
establishes a performance objective for the standard and supports the
regulatory goal of flexibility.
Be precise and unambiguous but as simple as possible. This
principle supports the regulatory goals of predictability and
simplicity.
Keep data collection and paperwork burdens on users as low
as is feasible. This principle supports the regulatory goals of cost-
effectiveness and avoidance of duplication and burden.
Incorporate flexibility to adapt more easily to changes in
the health care infrastructure (such as new services, organizations,
and 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 http://www.wpc-edi.com/hipaa/
2. 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
http://www.wpc-edi.com/hipaa/
2. 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
http://www.wpc-edi.com/hipaa/
2. 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 http://www.wpc-edi.com/hipaa/
B. 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 http://www.wpc-edi.com/hipaa/
2. 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
http://www.wpc-edi.com/hipaa/
2. 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
http://www.wpc-edi.com/hipaa/
B. 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 http://
www.wpc-edi.com/hipaa/
B. 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