[Federal Register: August 17, 2000 (Volume 65, Number 160)]
[Rules and Regulations]
[Page 50311-50372]
From the Federal Register Online via GPO Access [wais.access.gpo.gov]
[DOCID:fr17au00-26]
[[Page 50311]]
-----------------------------------------------------------------------
Part III
Department of Health and Human Services
-----------------------------------------------------------------------
Office of the Secretary
Health Care Financing Administration
-----------------------------------------------------------------------
45 CFR Parts 160 and 162
Health Insurance Reform: Standards for Electronic Transactions;
Announcement of Designated Standard Maintenance
Organizations; Final Rule and Notice
-----------------------------------------------------------------------
DEPARTMENT OF HEALTH AND HUMAN SERVICES
Office of the Secretary
45 CFR Parts 160 and 162
[HCFA-0149-F]
RIN 0938-AI58
Health Insurance Reform: Standards for Electronic Transactions
AGENCY: Office of the Secretary, HHS.
ACTION: Final rule.
-----------------------------------------------------------------------
SUMMARY: This rule adopts standards for eight electronic transactions
and for code sets to be used in those transactions. It also contains
requirements concerning the use of these standards by health plans,
health care clearinghouses, and certain health care providers.
The use of these standard transactions and code sets will improve
the Medicare and Medicaid programs and other Federal health programs
and private health programs, and the effectiveness and efficiency of
the health care industry in general, by simplifying the administration
of the system and enabling the efficient electronic transmission of
certain health information. It implements some of the requirements of
the Administrative Simplification subtitle of the Health Insurance
Portability and Accountability Act of 1996.
DATES: The effective date of this rule is October 16, 2000. The
incorporation by reference of certain publications listed in this rule
is approved by the Director of the Federal Register as of October 16,
2000.
FOR FURTHER INFORMATION CONTACT: Pat Brooks, (410) 786-5318, for
medical diagnosis, procedure, and clinical code sets.
Joy Glass, (410) 786-6125, for the following transactions: health
claims or equivalent encounter information; health care payment and
remittance advice; coordination of benefits; and health claim status.
Marilyn Abramovitz, (410) 786-5939, for the following transactions:
enrollment and disenrollment in a health plan; eligibility for a health
plan; health plan premium payments; and referral certification and
authorization.
SUPPLEMENTARY INFORMATION:
Availability of Copies
To order copies of the Federal Register containing this document,
send your request to: New Orders, Superintendent of Documents, P.O. Box
371954, Pittsburgh, PA 15250-7954. Specify the date of the issue
requested and enclose a check or money order payable to the
Superintendent of Documents, or enclose your Visa or Master Card number
and expiration date. Credit card orders can also be placed by calling
the order desk at (202) 512-1800 or by faxing to (202) 512-2250. The
cost for each copy is $8. As an alternative, you can view and photocopy
the Federal Register document at most libraries designated as Federal
Depository Libraries and at many other public and academic libraries
throughout the country that receive the Federal Register. You may also
obtain a copy from the following web sites: http://www.access.gpo.gov/
su--docs/aces/aces140.html; http://aspe.hhs.gov/admnsimp/.
I. Background
A. Electronic Data Interchange
Electronic data interchange (EDI) is the electronic transfer of
information, such as electronic media health claims, in a standard
format between trading partners. EDI allows entities within the health
care system to exchange medical, billing, and other information and to
process transactions in a manner which is fast and cost effective. With
EDI there is a substantial reduction in handling and processing time
compared to paper, and the risk of lost paper documents is eliminated.
EDI can eliminate the inefficiencies of handling paper documents, which
will significantly reduce administrative burden, lower operating costs,
and improve overall data quality.
The health care industry recognizes the benefits of EDI and many
entities in that industry have developed proprietary EDI formats.
Currently, there are about 400 formats for electronic health claims
being used in the United States. The lack of standardization makes it
difficult and expensive to develop and maintain software. Moreover, the
lack of standardization minimizes the ability of health care providers
and health plans to achieve efficiency and savings.
B. Statutory Background
The Congress included provisions to address the need for standards
for electronic transactions and other administrative simplification
issues in the Health Insurance Portability and Accountability Act of
1996 (HIPAA), Public Law 104-191, which was enacted on August 21, 1996.
Through subtitle F of title II of that law, the Congress added to title
XI of the Social Security Act a new part C, entitled ``Administrative
Simplification.'' (Public Law 104-191 affects several titles in the
United States Code. Hereafter, we refer to the Social Security Act as
the Act; we refer to the other laws cited in this document by their
names.) The purpose of this part is to improve the Medicare program
under title XVIII of the Social Security Act and the Medicaid program
under title XIX of the Act, and the efficiency and effectiveness of the
health care system, by encouraging the development of a health
information system through the establishment of standards and
requirements to enable the electronic exchange of certain health
information.
Part C of title XI consists of sections 1171 through 1179 of the
Act. These sections define various terms and impose several
requirements on HHS, health plans, health care clearinghouses, and
certain health care providers.
The first section, section 1171 of the Act, establishes definitions
for purposes of part C of title XI for the following terms: code set,
health care clearinghouse, health care provider, health information,
health plan, indiyvidually identifiable health information, standard,
and standard setting organization (SSO).
Section 1172 of the Act makes any standard adopted under part C
applicable to (1) all health plans, (2) all health care clearinghouses,
and (3) any health care provider who transmits any health information
in electronic form in connection with transactions referred to in
section 1173(a)(1) of the Act.
This section also contains requirements concerning standard
setting.
<bullet> The Secretary may adopt a standard developed, adopted, or
modified by a standard setting organization (that is, an organization
accredited by the American National Standards Institute (ANSI)) that
has consulted with the National Uniform Billing Committee (NUBC), the
National Uniform Claim Committee (NUCC), the Workgroup for Electronic
Data Interchange (WEDI), and the American Dental Association (ADA).
<bullet> The Secretary may also adopt a standard other than one
established by a standard setting organization, if the different
standard will reduce costs for health care providers and health plans,
the different standard is promulgated through negotiated rulemaking
procedures, and the Secretary consults with each of the above-named
groups.
<bullet> If no standard has been adopted by any standard setting
organization, the Secretary is to rely on the recommendations of the
National Committee on Vital and Health Statistics (NCVHS) and consult
with the above-named groups before adopting a standard.
[[Page 50313]]
<bullet> In complying with the requirements of part C of title XI,
the Secretary must rely on the recommendations of the NCVHS, consult
with appropriate State and Federal agencies and private organizations,
and publish the recommendations of the NCVHS regarding the adoption of
a standard under this part in the Federal Register.
Paragraph (a) of section 1173 of the Act requires that the
Secretary adopt standards for financial and administrative
transactions, and data elements for those transactions, to enable
health information to be exchanged electronically. Standards are
required for the following transactions: health care claims or
equivalent encounter information, health claims attachments, health
plan enrollments and disenrollments, health plan eligibility, health
care payment and remittance advice, health plan premium payments, first
report of injury, health care claim status, and referral certification
and authorization. Section 1173(a)(1)(B) authorizes the Secretary to
adopt standards for any other financial and administrative transactions
as she determines appropriate.
Paragraph (b) of section 1173 of the Act requires the Secretary to
adopt standards for unique health identifiers for each individual,
employer, health plan, and health care provider. It also requires that
the adopted standards specify for what purposes unique health
identifiers may be used.
Paragraphs (c) through (f) of section 1173 of the Act require the
Secretary to adopt standards for code sets for each data element for
each health care transaction listed above, security standards to
protect health care information, standards for electronic signatures
(established together with the Secretary of Commerce), and standards
for the transmission of data elements needed for the coordination of
benefits and sequential processing of claims. Compliance with
electronic signature standards will be deemed to satisfy both State and
Federal statutory requirements for written signatures with respect to
the transactions listed in paragraph (a) of section 1173 of the Act.
In section 1174 of the Act, the Secretary is required to adopt
standards for all of the above transactions, except claims attachments,
within 18 months after enactment. The standards for claims attachments
must be adopted within 30 months after enactment. Modifications to any
established standard may be made after the first year, but not more
frequently than once every 12 months. The Secretary may, however,
modify an initial standard at any time during the first year of
adoption, if she determines that the modification is necessary to
permit compliance with the standard. The Secretary must also ensure
that procedures exist for the routine maintenance, testing,
enhancement, and expansion of code sets and that there are crosswalks
from prior versions. Any modification to a code set must be implemented
in a manner that minimizes the disruption and the cost of compliance.
Section 1175 of the Act prohibits health plans from refusing to
conduct a transaction as a standard transaction. It also prohibits
health plans from delaying the processing of, or adversely affecting or
attempting to adversely affect, a person submitting a standard
transaction or the transaction itself on the grounds that the
transaction is in standard format. It establishes a timetable for
compliance: each person to whom a standard or implementation
specification applies is required to comply with the standard no later
than 24 months (or 36 months for small health plans) following its
adoption. With respect to modifications to standards or implementation
specifications made after initial adoption, compliance must be
accomplished by a date designated by the Secretary. This date may not
be earlier than 180 days after the modification is adopted by the
Secretary.
Section 1176 of the Act establishes civil monetary penalties for
violation of the provisions in part C of title XI of the Act, subject
to several limitations. Penalties may not be more than $100 per person
per violation of a provision, and not more than $25,000 per person per
violation of an identical requirement or prohibition for a calendar
year. With certain exceptions, the procedural provisions in section
1128A of the Act, ``Civil Monetary Penalties,'' are applicable to
imposition of these penalties.
Section 1177 of the Act established penalties for any person that
knowingly misuses a unique health identifier, or obtains or discloses
individually identifiable health information in violation of this part.
The penalties include: (1) A fine of not more than $50,000 and/or
imprisonment of not more than 1 year; (2) if the offense is ``under
false pretenses,'' a fine of not more than $100,000 and/or imprisonment
of not more than 5 years; and (3) if the offense is with intent to
sell, transfer, or use individually identifiable health information for
commercial advantage, personal gain, or malicious harm, a fine of not
more than $250,000 and/or imprisonment of not more than 10 years. We
note that these penalties do not affect any other penalties that may be
imposed by other federal programs.
Under section 1178 of the Act, the provisions of part C of title XI
of the Act, as well as any standards or implementation specifications
adopted under them, generally supersede contrary provisions of State
law. However, the Secretary may make exceptions to this general rule if
she determines that the provision of State law is necessary to prevent
fraud and abuse, ensure appropriate State regulation of insurance and
health plans, or for State reporting on health care delivery or costs,
among other things. In addition, contrary State laws relating to the
privacy of individually identifiable health information are not
preempted if more stringent than the related federal requirements.
Finally, contrary State laws relating to certain activities with
respect to public health and regulation of health plans are not
preempted by the standards adopted under Part C or section 264 of
Public Law 104-191.
Finally, section 1179 of the Act makes the above provisions
inapplicable to financial institutions or anyone acting on behalf of a
financial institution when ``authorizing, processing, clearing,
settling, billing, transferring, reconciling, or collecting payments
for a financial institution.''
II. General Overview of the Provisions of the Proposed Rule
On May 7, 1998, we proposed standards for eight transactions (we
did not propose a standard for either health claims attachments or
first report of injury) and for code sets to be used in the
transactions (63 FR 25272). In addition, we proposed requirements
concerning the implementation of these standards. This proposed rule
set forth requirements that health plans, health care clearinghouses,
and certain health care providers would have to meet concerning the use
of these standards.
We proposed to add a new part 142 to title 45 of the Code of
Federal Regulations to include requirements for health plans, certain
health care providers, and health care clearinghouses to implement
HIPAA administrative simplification provisions. This material has been
restructured to accommodate HIPAA privacy and security provisions, and
is now contained in parts 160 and 162 of title 45. Subpart A of part
160 contains the general provisions for all parts. Subpart I of part
162 contains the general provisions for the standards proposed in the
Standards for Electronic
[[Page 50314]]
Transactions proposed rule. Subparts J through R contain the provisions
specific to each of the standards proposed in the Standards for
Electronic Transactions proposed rule.
III. Analysis of, and Responses to, Public Comments on the Proposed
Rule
In response to the publication in the Federal Register of the
proposed rule on May 7, 1998, we received approximately 17,000 timely
public comments. The comments came from a wide variety of
correspondents including professional associations and societies,
health care workers, law firms, third party health insurers, hospitals,
and private individuals. We reviewed each commenter's letter and
grouped like or related comments. Some comments were identical,
indicating that the commenters had submitted form letters. After
associating like comments, we placed them in categories based on
subject matter or based on the section(s) of the regulations affected
and then reviewed the comments. All comments relating to general
subjects, such as the format of the regulations were similarly
reviewed.
This process identified areas of the proposed regulation that
required review in terms of their effect on policy, consistency, or
clarity of the rules.
We present comments and responses generally in the order in which
the issues appeared in the May 1998 proposed rule.
General--Comment Period
Comment: We received several comments that stated the 60-day
comment period was too short. It was stated that the period did not
take into account the highly detailed, technical review of the
thousands of pages in the implementation specifications that was
required in order to comment in a meaningful way.
Response: We disagree. We understand the difficulty in reviewing a
rule of this complexity. However, we met our notice requirements for
the length of the comment period and made every effort to ensure that
the proposed rule was readily accessible to the public (for example,
the proposed rule was published in the Federal Register and available
over the Internet). In addition, we received many comments requesting
changes to the implementation specifications, which indicates that the
majority of interested parties were able to review all implementation
specifications in the 60-day period. If additional changes are
necessary, revisions may be made to the standards on an annual basis.
A. Applicability
In subpart A Sec. 142.102 we listed the entities that would be
subject to the provisions and we discussed under what circumstances
they would apply.
Below we discuss the comments concerning applicability.
Comments and Responses on the Applicability of the Regulations
1. Electronically Transmitting Transactions
Proposal Summary: Our proposed rules apply to health plans and
health care clearinghouses, as well as any health care provider when
transmitting an electronic transaction defined in Subpart A of 45 CFR
Part 142.
Comment: Several commenters requested clarification on the
applicability provisions. For example, several commenters questioned
whether a health plan would be required to accept or send a standard
that it does not currently support electronically. Some commenters
believe the language allows any entity to submit a standard transaction
and expect it to be processed by the receiver even though they do not
have a business relationship with each other.
Response: Under the terms of section 1172(a) of the Act, these
regulations apply to health plans, health care clearinghouses, and
health care providers who transmit any health information in electronic
form in connection with a transaction referred to in section 1173(a) of
the Act (in other words, ``covered entities''). We interpret this
provision to mean that by the applicable compliance dates of the
regulation, all covered entities must comply with the standards adopted
by this regulation. (Covered entities, of course, may comply before the
applicable compliance dates.) We do not have the authority to apply
these standards to any entity that is not a covered entity. However, we
require covered entities to apply many of the provisions of the rule to
the entities with whom they contract for administrative and other
services related to the transactions, as it would be inconsistent with
the underlying statutory purpose to permit covered entities to avoid
the Act's requirements by the simple act of contracting out certain
otherwise covered functions.
With respect to health plans, a health plan is required to have the
capacity to accept and/or send (either itself, or by hiring a health
care clearinghouse to accept and/or send on its behalf) a standard
transaction that it otherwise conducts but does not currently support
electronically. For example, if a health plan pays claims
electronically but historically performed enrollment and disenrollment
functions in paper, the health plan must have the capacity to
electronically perform enrollment and disenrollment as well as claims
payment as standard transactions by the applicable compliance date of
the regulation.
Also, in response to the public's need for clarification of the
applicability of the HIPAA administrative simplification provisions (45
CFR subtitle A, subchapter C) to covered entities, we revisited the
applicability provision with respect to health care providers. In the
proposed rule, we proposed that the administrative simplification
provisions would apply to a health care provider when transmitting an
electronic transaction (63 FR 25305). (We note that this language
differed somewhat from the statute, which states that the HIPAA
administrative simplification provisions apply to ``a health care
provider who transmits any health information in electronic form in
connection with a transaction'' referred to in subchapter C.)
We phrased the applicability section in the proposed rule as we did
in an effort to convey the message that these regulations do not
require a health care provider to transmit transactions electronically;
thus, a health care provider remains free to use paper media. These
regulations do require, however, that a health care provider who uses
electronic media to transmit any health information in connection with
a transaction referred to in 45 CFR subtitle A, subchapter C, must do
so in compliance with the regulations. We do not believe that the
proposed applicability language as it applied to health care providers
adequately communicated this message. Thus, after reevaluating the
proposed approach, we believe that the best approach is to have the
applicability text mirror the statute and use Sec. 162.923
(Requirements for Covered Entities) as the vehicle to detail the
specific requirements for covered health care providers.
In addition, we provide the following as examples of types of
health care provider behavior that are permissible under the
regulations. For instance, a health care provider may send an
electronic health care claim or equivalent encounter information
standard transaction for Patient A to health plan Z, and may send a
paper claim for Patient B to health plan Z. A health care provider may
also send an electronic health care claim or equivalent encounter
information standard transaction to health plan S
[[Page 50315]]
and then send paper claims to health plan T.
In regard to the second comment, while we interpret HIPAA to mean
that a health plan cannot refuse to conduct a transaction because it is
a standard transaction, we do not believe that use of standard
transactions can create a relationship or liability that does not
exist. For example, a health plan cannot refuse to accept a claim from
a health care provider because the health care provider electronically
submits the standard transaction. However, the health plan is not
required to pay the claim merely because the health care provider
submitted it in standard format, if other business reasons exist for
denying the claim (for example, the service for which the claim is
being submitted is not covered). This rule does not require a health
care provider to send or accept an electronic transaction.
2. Various Technologies
Proposal Summary: Entities that offer on-line interactive
transmission of the transactions described in section 1173(a)(2) of the
Act, would have to comply with the standards (63 FR 25276). For
example, the Hypertext Markup Language (HTML) interaction between a
server and a browser by which the data elements of a transaction are
solicited from a user would not have to use the standards, although the
data content must be equal to that required for the standard. Once the
data elements are assembled into a transaction by the server, the
transmitted transaction would have to comply with the standards.
a. Comment: Several comments recommended that electronic
transmissions should be classified as ``computer to computer without
human interaction'' (i.e., batch and fast batch transmissions) and be
subject to the national standards. They also recommended that
transmissions involving browser to server (Internet, Extranet, HTML,
Java, ActiveX, etc.), direct data entry terminals (dumb terminals), PC
terminal emulators, point of service terminals (devices similar in
function to credit card terminals), telephone voice response systems,
``faxback'' systems, and any real-time transactions where data elements
are directly solicited from a human user, be classified as ``person to
computer'' transmissions. Moreover, ``person to computer''
transmissions should be supplemental to the national standards, but the
data content of these transmissions should comply with the HIPAA
electronic standards as they apply to data content.
Several commenters questioned whether HIPAA requires a health plan
to support ``person to computer'' methods. Several commenters suggested
that we should only except HTML web sites from the transaction
standards if the web browser is used in HTML passive mode without plug-
ins or programmable extensions and that the response times must be the
same or faster than that of the HIPAA electronic standards.
Commenters also recommended that we permit the use of a proprietary
format for web-based transactions if the transactions are sent to an
entity's in-house system for processing, and the entity's web browser
is under the control of a back-end processor, as well as part of the
same corporate entity, and does not serve other back-end processors.
They recommended that the HIPAA standards be used if the transactions
are sent externally (outside of that entity's system) for processing,
and the entity's web browser is under a contract with a back-end
processor that is not under the same corporate control, and that serves
more than one back-end processor.
Response: We are pleased that commenters support the use of the
national standards for electronic transactions since this outcome is
required by section 1173 of the Act. For each designated transaction,
these standards specify the format, the data elements required or
permitted to structure the format, and the data content permitted for
each of the data elements, including designated code sets where
applicable.
Certain technologies present a special case for the use of standard
transactions. We proposed that telephone voice response, ``faxback'',
and Hyper Text Markup Language (HTML) interactions would not be
required to follow the standard. We have since reevaluated this
position in light of the many comments on this position and on
developments in the EDI industry which continue to expand the options
in this area. We have decided that, instead of creating an exception
for these transmissions, we will recognize that there are certain
transmission modes in which use of the format portion of the standard
is inappropriate. However, the transaction must conform to the data
content portion of the standard. The ``direct data entry'' process,
using dumb terminals or computer browser screens, where the data is
directly keyed by a health care provider into a health plan's computer,
would not have to use the format portion of the standard, but the data
content must conform. If the data is directly entered into a system
that is outside of the health plan's system, to be transmitted later to
the health plan, the transaction must be sent using the full standard
(format and content). We have included this clarification in
Sec. 162.923 (Requirements for Covered Entities).
3. Atypical Services
Proposal Summary: Transactions for certain services that are not
normally considered health care services, but which may be covered by
some health plans, would not be subject to the standards (63 FR 25276).
These services would include, but not be limited to: nonemergency
transportation, physical alterations to living quarters for the purpose
of accommodating disabilities, and case management. Other services may
be added to this list at the discretion of the Secretary.
Comment: We received comments both for and against subjecting
transactions for certain services to the transaction standards. Some
commenters recommended that any service that could be billed to a
health plan be required to comply with the standards in order to avoid
the need to maintain alternate systems. However, other commenters
argued that certain Medicaid services are not insured by any other
program, thus, use of the standard is unnecessary.
Several commenters supported not subjecting these services to the
standard, except for case management, arguing that a more precise
definition of case management needs to be developed. Other commenters
stated that case management is considered a health care service by many
health plans and health care providers, and reported using standard
codes.
We received suggestions for additional services that should not be
subject to the standards. Suggestions included home and community based
waiver services provided under the Medicaid program and abbreviated
transactions between State agencies, for example, claims between a
State health service and a State Medicaid agency.
Response: We agree with commenters that case management is a health
care service since it is directly related to the health of an
individual and is furnished by health care providers. Case management
will, therefore, be subject to the standards.
We recognize that the health care claim and equivalent encounter
information standard, with its supporting implementation specification,
is capable of supporting claims for atypical services. However,
requiring all services potentially paid for by health plans to be
billed using the
[[Page 50316]]
standards would lead to taxi drivers, auto mechanics and carpenters to
be regulated as health care providers. Instead, we will use our
definition of ``health care'' found at 160.103 to determine whether a
particular service is a ``health care'' service or not. Services that
are not health care services or supplies under this definition are not
required to be claimed using the standard transactions. Thus, claims
for non-emergency transportation or carpentry services for housing
modifications, if submitted electronically, would not be required to be
conducted as standard transactions. As noted above, the standards do
support such claims and a health plan may choose to require its
atypical service providers to use the standards for its own business
purposes.
Those atypical services that meet the definition of health care,
however, must be billed using the standard if they are submitted
electronically. If there are no specific codes for billing a particular
service (for example, there is not yet an approved code set for billing
for alternative therapies), or if the standard transactions do not
readily support a particular method of presenting an atypical service
(for example, roster billing for providing immunizations for an entire
school or nursing facility), the health care service providers are
urged to work with the appropriate Designated Standard Maintenance
Organizations (DSMOs) to develop modifications to the standard and
implementation specifications. (See ``I. New and Revised Standards'' in
this section of the preamble for a discussion of the DSMOs.)
We disagree with the proposal that home and community based waiver
services should have a blanket exemption from the administrative
simplification standards. First, Congress explicitly included the
Medicaid programs as health plans that are subject to the
administrative simplification standards. Second, these waiver programs
commonly pay for a mix of health care and non-health care services.
State Medicaid agencies with home and community based waivers are not
exempt from these standards for transactions relating to health care
services or supplies.
4. Conducting the Transactions
Proposal Summary: If a person conducts a transaction (as defined in
Sec. 160.103) with a health plan as a standard transaction, the
following apply:
(1) The health plan may not refuse to conduct the transaction as a
standard transaction.
(2) The health plan may not delay the transaction or otherwise
adversely affect, or attempt to adversely affect, the person or the
transaction on the ground that the transaction is a standard
transaction.
Comment: Some commenters questioned what was meant by ``delay'' of
a standard transaction. They questioned what methods (i.e., batch,
online, etc.) a health plan must provide to support receipt and
submission of standard transactions. The proposed rule did not define
the term ``delay'' nor specify the time frame within which a health
plan is required to act when it receives a standard transaction.
Several commenters recommended the rule encompass all entities that
might be conducting an electronic transaction with a health plan and
that there be further clarification of what an unreasonable delay would
be. It was also recommended that the regulation should apply to a
health care provider, not a person that conducts an ``electronic''
transaction.
Response: Section 1175 of the Act prohibits a health plan from
delaying a standard transaction, or otherwise adversely affecting, or
attempting to adversely affect any person desiring to conduct a
transaction referred to in Sec. 1173 (a)(1) of the Social Security Act
or the transaction on the ground that the transaction is a standard
transaction. We interpret this provision to mean that there should be
no degradation in the transmission of, receipt of, processing of, and
response to a standard transaction solely because the transaction is a
standard transaction. Thus, health plans must process standard
transactions from any person, including, but not limited to, covered
entities, in the same time frame in which they processed transactions
prior to implementation of HIPAA. They also may not provide incentives
that will discourage (i.e., adversely affect) the use of standard
transactions.
In Sec. 162.923 we have included requirements for all covered
entities and in Sec. 162.925 we have provided additional requirements
for health plans.
5. Role of Health Care Clearinghouses
Proposal Summary: Health care clearinghouses would be able to
accept nonstandard transactions for the sole purpose of translating
them into standard transactions for sending customers and would be able
to accept standard transactions and translate them into nonstandard
formats for receiving customers (63 FR 25276).
Comment: Several commenters believe health care clearinghouses are
excepted from accepting the standards. Other commenters believe that
allowing health care providers to use a health care clearinghouse will
negate administrative simplification. There was also concern that
entities may designate themselves as a health care clearinghouse to
avoid compliance.
Several commenters also requested that we clarify who is
responsible for health care clearinghouse costs and state that
contracts cannot require health care providers to use nonstandard
formats.
Response: First, we clarify that a health care clearinghouse is a
covered entity and must comply with these rules. Accordingly, all
transactions covered by this part between health care clearinghouses
must be conducted as standard transactions. However, the statute
permits a covered entity to submit nonstandard communications to a
health care clearinghouse for processing into standard transactions and
transmission by the health care clearinghouse as well as receive
standard transactions through the health care clearinghouse.
If a covered entity (for example, a health care provider) uses a
health care clearinghouse to submit and receive nonstandard/standard
transactions, the health care clearinghouse is the covered entity's
business associate. If a health plan operates as a health care
clearinghouse, or requires the use of a health care clearinghouse, a
health care provider may submit standard transactions to that health
plan through the health care clearinghouse. However, the health care
provider must not be adversely affected, financially or otherwise, by
doing so. (For example, the costs of submitting a standard transaction
to a health plan's health care clearinghouse must not be in excess of
the costs of submitting a standard transaction directly to the health
plan.)
In Sec. 162.915, we clarify what a trading partner agreement that a
covered entity enters into may not do. Section 162.923 specifies that a
covered entity conducting a transaction covered under this rule with
another covered entity (or within the same covered entity) using
electronic media must conduct the transaction as standard transaction,
with an exception for direct data entry. Section 162.925 makes it clear
that a health plan may not offer an incentive for a health care
provider to conduct a transaction covered by this part under the direct
data entry exception.
6. Exception for Transmissions within Corporate Entities
Proposal Summary: Transmissions within a corporate entity would not
be
[[Page 50317]]
required to comply with the standards (63 FR 25276).
Comment: We received many comments regarding excepting
transmissions within corporate boundaries and the examples we provided.
The comments can be summarized by three questions: (1) What constitutes
a ``corporate entity'' and ``internal'' communications; (2) can the
``internal umbrella'' cover the transactions among ``corporate''
entities; and (3) why should Government agencies be excepted from
meeting the standards?
Some commenters attempted to determine the circumstances under
which compliance with the standards can be avoided. Generally, these
commenters indicated a desire for a very broad definition of
``corporate entity.'' Some commenters reflected a desire to severely
restrict the boundaries or eliminate them altogether. Other commenters
asked if particular kinds of data or transactions are required in
particular situations.
Response: We proposed to create an exception for transactions
within a corporate entity to minimize burden. However, after
considering public comment, and further analyzing the implications of
the proposed exception, we have decided not to create an exception for
standard transactions within a ``corporate entity.'' First, we have not
been able to define ``corporate entity'' so that the exception would
not defeat the rule. The rapid pace of mergers, acquisitions, and
dissolutions in the corporate health care world would make such an
exception extremely difficult to implement. Equally important, the
proposed exception would not have promoted the use of the standard
transactions at the health care provider and health plan level. Each
health care provider that is owned by or under contract to one or more
health plans could be required to use the ``in-house'' or ``non-
standard'' transactions favored by each health plan, thus negating the
benefits of the use of the standards. Finally, our decision to not
adopt a corporate entity exception does not impose an additional burden
on health plans, because health plans already are required to have the
capacity to accept standard transactions from any person. Thus, the
fundamental policy is that covered entities must use a standard
transaction when transmitting a transaction covered by this part with
another covered entity (or within the same covered entity)
electronically, regardless of whether the transmission is inside or
outside the entity.
We have decided to clarify the description of each transaction to
help covered entities determine when the standards must be used. A
transaction is now defined in Sec. 160.103 as the exchange of data for
one of the enumerated specific purposes. In subparts K through R of
part 162, we describe each transaction in specific, functional terms.
For example, one type of health care claims or equivalent encounter
information transaction is the exchange of information between a health
care provider and a health plan about services provided to a patient to
obtain payment; one type of eligibility for a health plan transaction
is the exchange of information between a health provider and a health
plan to determine whether a patient is eligible for services under that
health plan. Data submissions or exchanges for purposes other than
those designated in this regulation are not transactions and therefore
do not require use of the standards.
Transactions may be used by both covered entities and other
entities. For example, the enrollment and disenrollment in a health
plan transaction is most commonly sent by employers or unions, which
are not covered entities, to health plans, which are covered entities.
The employer may choose to send the transaction electronically in
either standard or non-standard format. The health plan, however, must
conduct the transaction as a standard transaction when conducting the
transaction electronically with another covered entity, with another
part of itself, or when requested to do so by any other entity.
Moreover, if an employer or other non-covered entity desires to send a
transaction as a standard transaction, the health plan may not delay or
adversely affect either the sender or the transaction. It is expected
that this provision will encourage non-covered entities that conduct
the designated transactions with more than one health plan to conduct
these transactions as standard transactions.
In general, if a covered entity conducts, using electronic media, a
transaction adopted under this part with another covered entity (or
within the same covered entity), it must conduct the transaction as a
standard transaction. If any entity (covered or not covered) requests a
health plan to conduct a transaction as a standard transaction, the
health plan must comply. We have provided examples below to assist in
determining when a transaction must be conducted as a standard
transaction.
Example 1: Corporation K operates a health plan that is a
covered entity under these rules. Corporation K owns a hospital
which provides care to patients with coverage under Corporation K's
health plan and also provides care to patients with coverage under
other health plans. Corporate rules require the hospital to send
encounter information electronically to Corporation K identifying
the patients covered by the corporate plan and served by the
hospital.
(A) Must the transmission of encounter data comply with the
standards? Both the health plan and the hospital are covered
entities. The hospital is a covered entity because it is conducting
covered transactions electronically in compliance with its corporate
rules. The electronic submission of encounter data satisfies the
definition of the health care claims or equivalent encounter
information transaction designated as a standard transaction (see
Sec. 162.1101(b)). Therefore, the submission of this encounter data
therefore must be a standard transaction.
(B) Must the payments and remittance advices sent from
Corporation K's health plan to the hospital be conducted as standard
transactions? Corporation K's health plan is covered by the
definition of ``health plan,'' the hospital is a covered entity, and
the transmission of health care payments and remittance advices is
within the scope of the designated transactions (see Sec. 162.1601).
The health care payments and remittance advices must be sent as
standard transactions.
Example 2: A large multi-state employer provides health
benefits on a self-insured basis, thereby establishing a health
plan. The health plan contracts with insurance companies in seven
states to function as third party administrators to process its
employees' health claims in each of those states. The employer's
health plan contracts with a data service company to hold the health
eligibility information on all its employees. Each of the insurance
companies sends eligibility inquiries to the data service company to
verify the eligibility of specific employees upon receipt of claims
for services provided to those employees or their dependents.
(A) Are these eligibility inquiries activities that must be
conducted as standard transactions? In this case, each insurance
company is not a covered entity in its own right because it is
functioning as a third party administrator, which is not a covered
entity. However, as a third party administrator (TPA), it is the
business associate of a covered entity (the health plan) performing
a function for that entity; therefore, assuming that the covered
entity is in compliance, the TPA would be required to follow the
same rules that are applicable to the covered entity if the covered
entity performed the functions itself. The definition for the
eligibility for a health plan transaction is an inquiry from a
health care provider to a health plan, or from one health plan to
another health plan, to determine the eligibility, coverage, or
benefits associated with a health plan for a subscriber. In this
case, the inquiry is from one business associate of that health plan
to another business associate of that same health plan. Therefore,
the inquiry does not meet the definition of an eligibility for a
[[Page 50318]]
health plan transaction, and is not required to be conducted as a
standard transaction.
(B) Is an electronic eligibility inquiry from a health care
provider to the data service company, to determine whether an
employee-patient may receive a particular service, required to be a
standard transaction? The health care provider is a covered entity,
because it conducts covered electronic transactions. The data
service company is the business associate of the employer health
plan performing a plan function. Therefore, the activity meets the
definition of the eligibility for a health plan transaction, and
both the inquiry and the response must be standard transactions.
Example 3: A pharmacy (a health care provider) contracts with a
pharmacy benefits manager (PBM) to forward its claims electronically
to health plan Z. Under the contract, the PBM also receives health
care payment and remittance advice from health plan Z and forwards
them to the pharmacy.
(A) Must the submission of claims be standard transactions? The
pharmacy is a covered entity electronically submitting, to covered
entity health plan Z, health care claims or equivalent encounter
information, which are designated transactions (see Sec. 162.1101),
through a business associate, the PBM. The claims must be submitted
as standard transactions.
(B) Must the explanation of benefits and remittance advice
information be sent as a standard transaction? Health plan Z and the
health care provider are covered entities conducting one of the
designated transactions (see Sec. 162.1601). This transaction,
therefore, must be conducted as a standard transaction.
Example 4: A State Medicaid plan enters into a contract with a
managed care organization (MCO) to provide services to Medicaid
recipients. That organization in turn contracts with different
health care providers to render the services.
(A) When a health care provider submits a claim or encounter
information electronically to the MCO, is this activity required to
be a standard transaction? The entity submitting the information is
a health care provider, covered by this rule, and the MCO meets our
definition of health plan. The activity is a health care claims or
equivalent encounter information transaction designated in this
regulation. The transaction must be a standard transaction.
(B) The managed care organization then submits a bill to the
State Medicaid agency for payment for all the care given to all the
persons covered by that MCO for that month under a capitation
agreement. Is this a standard transaction? The MCO is a health plan
under the definition of ``health plan'' in Sec. 160.103. The State
Medicaid agency is also a covered entity as a health plan. The
activity, however, does not meet the definition of a health care
claims or equivalent encounter information transaction. It does not
need to be a standard transaction.
However, note that the health plan premium payment transaction
from the State Medicaid agency to the health plan would have to be
conducted as a standard transaction because the State Medicaid
agency is a covered entity sending the transaction to another
covered entity (the health plan), and the transaction meets the
definition of health plan premium payment.
7. Applicability to Paper Transactions and Other Entities
Proposal Summary: Although there are situations in which the use of
the standards is not required (for example, health care providers may
continue to submit paper claims and employers and other noncovered
entities are not required to use any of the standard transactions), we
stressed that a standard may be used voluntarily in any situation in
which it is not required (63 FR 25276).
a. Comment: The majority of commenters suggested that the
transaction standards and their codes sets, in some manner, apply to
paper transactions. They suggested that the required data elements in
the standard transactions also be required for paper transactions and
that any required identifiers also be required for use on paper
transactions.
The commenters stated that there could be two consequences if the
same data were not required on paper and electronic transactions.
First, health plans would have to maintain two systems: one for the
processing of electronic claims; and one for the processing of paper
claims. The same argument was also applied to identifiers--it was
argued that health plans would need to maintain two sets of
identifiers: one for paper claims; and one for electronic claims.
Second, many health care providers would revert to paper claims if the
data requirements were less restrictive than those for electronic
claims.
Response: These are powerful arguments from a cost benefit
standpoint. While the HIPAA statute provides the Secretary with the
authority to declare these standards applicable to all transactions,
including those on paper, we chose at this point to focus on standards
for electronic transactions. Most of the paper forms currently in use
today cannot accommodate all of the data content included in the
standard transactions. This does not prevent health plans from
requiring the same data, including identifiers for paper transactions
as is required by the HIPAA regulations with respect to electronic
transactions.
b. Comment: Several commenters recommended that employers/sponsors
who perform EDI should be required to use the standards because they
play a critical role in the overall administration of health care.
These entities are the major users of the enrollment and disenrollment
in a health plan transactions, and are often major payers of health
premiums.
Response: The administrative simplification provisions of HIPAA do
not require noncovered entities to use the standards, but noncovered
entities are encouraged to do so in order to achieve the benefits
available from such use. For example, employers and sponsors play a key
role in the administrative functions of health care, e.g. the
enrollment and disenrollment of individuals in health plans. But
because the legislation does not specifically require employers /
sponsors to use the transaction standards, we are not extending the
requirement to them in the regulation. Health plans are, however, free
to negotiate trading partner agreements with employers and sponsors
that require the use of standard transactions.
8. Exceptions for State Law (Section 1178)
Proposal Summary: The proposed rule did not propose preemption
requirements in the regulation text and did not directly request
comments on the preemption issue. However, it did set forth a summary
of the preemption provision of the Act, section 1178, and, therefore,
raised the issue for public comment (63 FR 25274). In response, we
received a number of comments regarding the preemption issue, and
requesting guidance on how preemption questions will be resolved.
Comment: Many commenters recommended the exception for State law
process be delineated or clarified in the final rule. Many commenters
stated that exceptions in general should not be granted, saying that
this is contrary to the idea of national standards. Other commenters
stated exceptions should be discouraged.
Response: The statute clearly states that the Secretary may grant
exceptions in certain circumstances. The proposed rule regarding
Standards for Privacy for Individually Identifiable Health Information,
published in the Federal Register on November 3, 1999 (64 FR 59967),
specifically raised the preemption issue. Comments received in response
to that proposed rule are being analyzed. We will issue conforming
amendments to Part 160 Subpart B when the preemption issues have been
resolved in the context of the Standards for Privacy for Individually
Identifiable Health Information final rule.
[[Page 50319]]
B. Definitions
Comments and Responses Concerning the Definitions
Several definitions in this rule have also been proposed in other
HIPAA proposed rules. They may be revised as these other rules are
published in final.
1. Code set
Comment: One commenter stated that the definition of code set
should be expanded to include factors such as functional status, in
order to clarify that a code set is not limited to ``medical'' terms.
Response: We have defined ``code set'' very broadly to encompass
any set of codes used to encode data elements. Many code sets (such as
revenue codes) are nonmedical in nature and are designated within the
transaction standards. We are separately designating standards for
medical data code sets used in the transaction.
2. Health Care Clearinghouse
Comment: Several commenters requested that the definition of a
health care clearinghouse be reworded. Of particular concern was the
reference to other entities, such as billing services, repricing
companies, etc. Commenters stated the definition would preclude these
other entities from using a health care clearinghouse for format
translation and data conversion. Several commenters stated health care
clearinghouses play roles other than data and format conversion as
described in the proposed rule.
Response: If an entity does not perform the functions of format
translation and data conversion, it is not considered a health care
clearinghouse under our definition. Billing services, for example, are
often extensions of a health care provider's office, primarily
performing data entry of health care claims and reconciling the
payments received from a health plan. Health care providers may use
health care clearinghouses for format translation and other services a
health care clearinghouse provides. We agree the definition should be
reworded and have revised the definition in Sec. 160.103.
3. Health care provider
Comment: We received several comments requesting clarification on
the distinction between billing health care providers and a billing
service, as well as clarification on the difference between
housekeeping staff and home health aides. Several commenters
recommended removal of the word ``bills'' in the definition. They want
the definition to be based on the direct provision of health care and
not financial arrangements.
Response: The proposed rule regarding Standard Health Care Provider
Identifiers, published in the Federal Register on May 7, 1998 (63 FR
25320) also included the definition of health care provider. Comments
received in response to that proposed rule regarding the definition of
a health care provider included the comments above, as well as
additional comments, and are being analyzed. We believe it is
appropriate to address all comments regarding the definition of a
health care provider in the final rule for Standard Health Care
Provider Identifiers.
4. Health plan
We interpret section 1171(5)(G) of the Act to mean that issuers of
long-term care policies are considered health plans for purposes of
administrative simplification. We also believe that this provision of
the statute gives the Secretary the discretionary authority to include
or exclude nursing home fixed-indemnity policies from the definition of
a health plan. We specifically requested comments on the impact of
HIPAA on the long-term care segment of the health care industry.
a. Comment: The majority who commented on long-term care policies
recommended we exclude these policies from the definition of a health
plan. Several commenters stated the standard transaction implementation
specifications do not meet long term care administrative requirements.
The commenters noted that there are fundamental differences between the
nature and type of transactions and information required by health
plans that pay for long-term care services and those that pay for
hospital or physician care. The commenters pointed out that not all
long-term care insurance policies pay directly for specific long-term
care services. They also stated that the code sets included in the
proposed regulation do not adequately meet the needs of long-term care
insurance because most documents sent to these companies are narrative
``activities of daily living'' (ADLs) evaluations, adult ``day care''
invoices and physician notes.
Moreover, including long-term care only policies within the
definition of a health plan would be contrary to the purposes of
section 1171 of the Act. It was also stated that for the most part, the
long-term care industry is not automated and the costs of developing
systems to implement these requirements will be dramatic with little,
if any, return. It would increase consumer premiums. Most long-term
care claim submissions and payment transactions are between the insured
(or a family member) and their insurance companies, without health care
providers submitting claims.
One commenter that supported including long-term care policies in
the definition of a health plan stated that there have been great
strides in the automation of health information in the long-term care
industry and it should not be excepted from the standards. Another
commenter stated the proposed standards offer the opportunity for all
segments of the health care industry to adopt automation and to benefit
from such adoption. The standards provide long-term care health care
providers with a single method that can be exchanged with all health
plans. The commenter stated it would be an unfortunate precedent to
except segments of the health care industry from these rules.
Response: The arguments both for and against inclusion of long-term
care policies have merit. Since some long term care health care
providers bill Medicaid using the UB92, it appears that standard
transactions and code sets could be used by long-term care health care
providers to bill health plans. In addition, we agree that movement by
the industry to these electronic standards would create long term
benefits including decreased administrative costs.
We interpret the statute as authorizing the Secretary to exclude
nursing home fixed-indemnity policies, not all long-term care policies,
from the definition of ``health plan,'' if she determines that these
policies do not provide ``sufficiently comprehensive coverage of a
benefit'' to be treated as a health plan (see section 1171 of the Act).
We interpret the term ``comprehensive'' to refer to the breadth or
scope of coverage of a policy. ``Comprehensive'' policies would be
those that cover a range of possible service options. Since nursing
home fixed indemnity policies are, by their own terms, limited to
payments made solely for nursing facility care, we have determined that
they should not be included as health plans for the purposes of this
regulation. The Secretary has, therefore, determined that only nursing
home fixed-indemnity policies should be excluded from the definition of
``health plan.'' Issuers of all other long-term care policies are
considered to be health plans under this rule.
b. Comment: Several commenters recommended that property and
casualty insurance health plans and workers' compensation health plans
be included in the definition of a health plan. It was stated that we
should not
[[Page 50320]]
arbitrarily exclude certain health plans. It was also stated that
exclusion will cause undue hardship on health care providers of those
specialities that most frequently deal with these health plans, such as
orthopedic specialists. It was questioned whether the Bureau of Prisons
or state correctional facilities are included in this definition, since
they provide or pay for the cost of medical care.
Another commenter stated that if State Workers' Compensation
Programs are allowed to operate with different rules (as they do now)
health care providers will be required to maintain multiple systems to
accommodate the many variations. Consequently, administrative
simplification will not achieve the desired cost savings.
Response: We recognize that non-HIPAA entities such as workers'
compensation programs and property casualty insurance accept electronic
transactions from health care providers, however, the Congress did not
include these programs in the definition of a health plan under section
1171 of the Act.
The statutory definition of a health plan does not specifically
include workers' compensation programs, property and casualty programs,
or disability insurance programs, and, consequently, we are not
requiring them to comply with the standards. However, to the extent
that these programs perform health care claims processing activities
using an electronic standard, it would benefit these programs and their
health care providers to use the standard we adopt.
We believe that prisons do not fall within this definition of
health plan, as prisons are not ``individual or group plans''
established for the purpose of paying the cost of health care.
c. Comment: We received two requests to clarify that limited scope
dental and vision health plans are not subject to the rule. It was
stated that the proposed rule did not specifically indicate that the
standards are applicable to these health plans. The limited scope
dental health plans provide for annual maximum benefits generally in
the $1000-$2000 range and annual benefit payments under limited scope
vision health plans rarely exceed a few hundred dollars. The commenters
noted that consumers can afford presently to pay for the cost of the
annual benefit payments, but if health plans must implement these
standards, they will most likely pass on the costs associated with this
burden to their enrollees, causing many consumers to drop their
coverage.
Response: We believe limited scope dental health plans and limited
scope vision health plans meet the definition of health plan and, thus,
they are subject to the requirements of this rule. The Congress did not
give the Secretary the discretion to treat these health plans
differently than other health plans. If a health plan believes it would
be cost prohibitive to implement the standards, it has the option of
using a health care clearinghouse to transmit and receive the standard
transactions.
5. Small Health Plan
Comment: One commenter requested we clarify how the figure for the
number of participants for a small health plan was determined. For
instance, is an individual insured in a health plan for one month
considered a participant for that year? Would twelve different people
insured for one month each in a single year be considered a
participant? Another commenter questioned why small health plans are
being given an extra 12 months to implement the standards.
Response: In the proposed rule, we stated that a small health plan
means a group health plan or individual health plan with fewer than 50
participants. It has come to our attention that the Small Business
Administration (SBA) promulgates size standards that indicates the
maximum number of employees or annual receipts allowed for a concern
(13 CFR 121.105) and its affiliates to be considered ``small.'' The
size standards themselves are expressed either in number of employees
or annual receipts (13 CFR 121.201). The size standards for compliance
with programs of other agencies are those for SBA programs which are
most comparable to the programs of such other agencies, unless
otherwise agreed by the agency and the SBA (13 CFR 121.902). With
respect to the insurance industry, the SBA has specified that annual
receipts of $5 million is the maximum allowed for a concern and its
affiliates to be considered small (13 CFR 121.201). Consequently, the
definition of small health plan has been amended to be consistent with
SBA requirements. As such, we need not address the definition of
participants for purposes of small health plans.
Small health plans must implement the standards no later than 36
months after adoption under section 1175 of the Act.
6. Standard
Comment: One commenter stated the proposed rule dramatically
changed the definition of standard. The commenter stated the new
definition implies that any and all standards promulgated by an ANSI
SSO or HHS automatically become a standard, whereas under the Act, only
the Secretary can specify, establish, or adopt standards. The commenter
recommended the definition under the Act stay the same.
Response: We agree that only the Secretary may adopt a standard
under the Act. Because the statutory definition of the term
``standard'' is ambiguous, we are adopting a broader definition to
accommodate the varying functions of the specific standards proposed in
the other HIPAA regulations. We have revised the definition in
Sec. 160.103 to clarify this, and have also added a definition for
standard transaction in Sec. 162.103 for further clarification.
7. Transaction
Comment: Several commenters recommended we amend the transaction
definition to clarify each transaction.
Response: We have provided clarification in the definitions of each
transaction in subparts K through R.
Additional Definitions
Comment: We received comments requesting that we define the terms
``sponsor,'' ``third party administrator,'' ``trading partner
agreement,'' and ``health claims attachments.''
Response: We have included a definition for trading partner
agreement in Sec. 160.103. In this final rule, we are defining only
terms used in the regulations text, therefore, we are not providing
definitions for ``sponsor'' or ``third party administrator.'' In the
future, we intend to publish a proposed rule that defines health claims
attachment.
We have added definitions to parts 160 and 162 that were not part
of the proposed rule. In order to clarify the applicability and scope
of this rule, we have added definitions for ``covered entity,''
``trading partner agreement,'' and ``workforce'' to part 160, and
definitions for ``direct data entry'' and ``electronic media'' to part
162.
We have added a definition for ``business associate'' to part 160
in order to distinguish those functions a covered entity chooses other
entities to perform on its behalf (making the other entity a business
associate of the covered entity) from the functions of other types of
agents. These other types may have differing meanings in different
situations (for example, insurance agent).
To aid in the articulation of the process by which standards are
adopted and changed, we have added definitions for ``compliance date,''
``implementation specification,'' ``modify'' and ``standard
[[Page 50321]]
setting organization'' to part 160, and definitions for ``code set
maintaining organization,'' ``designated standard maintenance
organization (DSMO),'' and ``maintenance'' to part 162.
We added a definition for ``standard transaction'' to part 162 to
complement the definitions of ``standard'' and ``transaction,'' which
were proposed and, in the case of standard, revised as discussed
earlier in this preamble. And, in order to enumerate as many facets of
a standard transaction as possible, we have added definitions for
``data condition,'' ``data content,'' ``data element,'' ``data set,''
``descriptor,'' ``format,'' ``maximum defined data set,'' and
``segment'' to part 162. These definitions should help to make clear
the components of a standard transaction.
We also made several clarifications with respect to the definition
of ``health plan'' (Sec. 160.103). For purposes of defining the various
health plans that are considered health plans for purposes of the
regulation, we added the word ``issuer'' to Medicare supplemental
policy, and long-term care policy. We included the word ``issuer'' when
referring to long-term care policies, because policies themselves are
not entities subject to the statute. Rather, it is the issuers of long-
term care policies that are subject to the statute. We also added the
SCHIP program, because it is a health plan under section 4901 of the
Balanced Budget Act of 1997 (Pub. L. 105-33) and meets the statutory
criteria for a health plan.
We are adding a definition of ``state'' to Sec. 160.103 to clarify
its meaning with regard to the Federal programs included in the
definition of ``health plan,'' which contain this term.
Several terms were in the proposed rule but are not included in the
final rule. We have reconsidered the inclusion of the definition of
``medical care.'' It has come to our attention that the term ``medical
care'' is easily confused with the term ``health care.'' Since the term
medical care is used in the regulation only in the context of the
definition of health plan and its inclusion in the regulation text may
cause confusion, we have decided to remove the definition of ``medical
care'' from the final regulation. We note, however, that ``medical
care'' is a statutorily defined term and its use is critical in making
a determination as to whether a health plan is considered a ``health
plan'' for purposes of Administrative Simplification. Thus, we do
include the statutory cite for ``medical care'' in the definitions of
``group health plan'' and ``health plan.''
Similarly, we removed the definition of ``participant'' because it
appears only in the context of the definitions of the various types of
health plans. As in the case of ``medical care,'' we embed the
statutory cite for the definition of ``participant'' in the definition
of ``group health plan.''
Also, the definitions for ``ASC X12,'' ``ASC X12N'' were removed
because we decided their presence in the regulation did not add to the
functionality of the text. We did not receive any comments on the
definitions that were removed.
C. Effective Dates and Compliance Dates
1. Effective Dates and Compliance Dates for Specified Standards
The effective date for this final rule is the date that it amends
the Code of Federal Regulations (CFR). The current CFR consists of the
rules published in the latest CFR volume and any effective amendments
published in the Federal Register since the revision of the latest CFR
volume. Since the impact is expected to be in excess of $100 million
per year, Congress will have 60 days after the date of publication in
the Federal Register to revise the rule before it becomes effective.
Standards are adopted and implementation specifications are established
as of the effective date of this rule.
The compliance dates of this final rule are the dates that covered
entities must be in compliance with the rule. The compliance date of
this final rule for most covered entities is no later than 24 months
after the effective date of this final rule. The compliance date of
this final rule for small health plans, however, is no later than 36
months after the effective date of this final rule.
In our proposed rule, we stated that we would include the specific
compliance dates in the subpart for each standard (63 FR 25279). The
compliance dates in this final rule have been consolidated in
Sec. 162.900.
Comments and Responses on Effective Dates and Compliance Dates for
Specific Standards
Comment: The majority of commenters cited that Y2K initiatives will
clash with implementing the HIPAA standards. It was recommended that
the implementation date should be delayed until after the year 2000.
Several commenters stated that a 2-year implementation time frame
may be inadequate to coordinate new system designs with other health
plans and to modify existing systems and contracts. There was concern
that the industry cannot convert to the new standards within 2 years.
Several commenters recommended that all health plans have the same
time frame with which to comply with the standards of this rule. They
noted that a health care provider has no knowledge of whether a health
plan is a small or large health plan. It would be very inefficient for
a health care provider to maintain two systems for an additional year.
The majority of those who commented on the publication of the final
rule recommended that the rules be published in a staggered fashion,
specifically the identifiers first, then the transactions. Some also
wanted the attachment and security regulations published at the same
time the transaction regulation is published. Some commenters also
wanted the effective dates for each standard transaction to be
staggered. Several commenters recommended publishing an interim final
rule allowing for additional comments.
Several commenters generally supported the WEDI recommendation that
health care providers not be required by health plans to use any of the
standards during the first year after adoption of the standards, and
that willing trading partners could implement any or all of the
standards by mutual agreement at any time during the 2 year
implementation phase (3 years for small health plans). WEDI also
recommended that health care providers be given at least 6 months'
notice by a health plan before requiring health care providers to
implement the standards.
Response: Section 1175 of the Act dictates that the standards are
to be implemented no later than 24 months after adoption (36 months for
small health plans).
In the interest of a smooth transition, we encourage health plans
not to require health care providers to use the standards specified in
subparts K through R during the first year after the effective date of
the transactions final rule, although willing trading partners could do
so by mutual agreement during that time. We also encourage health plans
to give health care providers at least 6 months notice before requiring
health care providers to implement a standard transaction. For example,
if the effective date of the rule is 8/1/2000 and trading partners have
agreed not to implement during the first year, the first implementation
date could be 8/1/2001 and health care providers should be notified by
2/1/2001.
2. Effective Dates and Compliance Dates of Modifications
Proposal Summary: In Sec. 142.106 (now Sec. 160.104), we proposed
that if the
[[Page 50322]]
Secretary adopts a modification to an implementation specification or a
standard, the implementation date of the modification (the date by
which covered entities must comply with the modification) would be no
earlier than the 180th day following the adoption of the modification
(the effective date of the final rule in the Federal Register which
adopts the modification). The Secretary would determine the actual
date, taking into account the time needed to comply due to the nature
and extent of the modification. The Secretary would be able to extend
the time for compliance for small health plans.
Comments and Responses on Effective Dates and Compliance Dates of
Modifications
Comment: Some commenters believed 180 days may not always be enough
time to implement a revised standard.
Response: The statute states that the Secretary must permit no
``fewer'' than 180 days for implementation after adopting a revised
standard (i.e., a modification). Depending on the nature of the
revision, the minimum time frame of 180 days could be longer. This time
frame does not apply to the maintenance of medical code sets and
external code sets. The compliance date will be specified by the code
set maintaining organization responsible for maintenance changes to
that code set.
We will clarify the terms modification and maintenance. In the
transactions context, when a change is substantial enough to justify
publication of a new version of an implementation specification, this
change will be considered to be a modification. Such a change must be
adopted by the Secretary through regulation. Maintenance is the
activities necessary to support the use of a standard, including
technical corrections to an implementation specification, and
enhancements, additions, or deletions to a data code set. These changes
could be non-substantive or error correction. Public comment and
notification is required as part of the normal, ANSI-accredited
standards development process, but regulatory action would not be
required for maintenance as we have defined it. For example, this final
rule adopts the ASC X12N 278--Health Care Services Review--Request for
Review and Response, Version 4010, May 2000 as the standard for the
referral certification and authorization transaction. Error corrections
or addendums to Version 4010, May 2000, would constitute maintenance to
this standard and there would be no regulatory action. Changes
requiring a new version, or an updated edition of Version 4010 (for
example, moving from Version 4010, May 2000 to Version 4010, October
2001) would constitute a modification to this standard and would be
adopted through regulatory action.
D. Data Content
Proposal Summary: We proposed standard data content for each
adopted standard. Information that would facilitate data content
standardization, while also facilitating identical implementations,
would consist of implementation specifications, data conditions, data
dictionaries, and the standard code sets for medical data that are part
of this rule. Data conditions are rules that define the situations when
a particular data element or segment can or must be used.
It is important to note that all data elements would be governed by
the principle of a maximum defined data set. No one would be able to
exceed the maximum defined data set in this rule. This principle
applies to the data elements of all transactions.
Comments and Responses on Data Content
Comment: The majority of commenters supported the concept of a
maximum defined data set; however, there was some confusion on what we
were proposing.
Several commenters believed we were requiring health care providers
to always send the transaction with the maximum data possible. They
stated that health care providers and health plans will pay excessively
for unused data that is transmitted. Concern was also expressed that
health plans would have to store coordination of benefits (COB)
information if it is submitted, even though they do not perform COB.
Several commenters suggested that health plans be allowed to reject a
transaction because it contains information they do not want.
One commenter recommended that the maximum defined data set be the
full set of data available in the implementation specifications, not
the addendum in the proposed rule.
A few commenters wanted to expand the concept of a maximum defined
data set to include code sets, modifiers, narrative descriptions,
guidelines and instructions applicable to codes sets, as well as an
additional category for ``usage'' in the implementation specifications,
``not required unless specified by a contractual agreement.'' Several
commenters wanted trading partners to be able to agree on which non-
required data will be used between them.
One commenter suggested a ``minimum'' data set principle be
applied. If a submitter sends a minimum data set, the receiver cannot
reject it as incomplete. Again, the commenter believed we were implying
that a submitter must send the maximum every time, in order to assure
acceptance of the transaction.
Response: We wish to clarify the maximum defined data set concept.
A maximum defined data set contains all of the required and situational
data elements possible in a standard transaction. For each standard
transaction there are situational data elements that are both relevant
to the particular transaction and necessary to process it; there are
also situational data elements that an entity may include in a
transaction, but does not need to include, in order for the transaction
to be processed. A required data element is always required in a
transaction. A situational data element is dependent on the written
condition in the implementation specification that describes under
which circumstances it is to be provided. The maximum defined data set
is based on the implementation guides and not the addendum in the
proposed rule. The maximum defined data set also includes the
applicable medical and nonmedical code sets for that transaction. Some
code sets, e.g., HCPCS and CPT-4, include special codes referred to as
``modifiers.'' Modifiers are included in the concept of maximum defined
data set. The maximum defined data set does not include operational
guidelines or instructions for every code set.
We note that if an entity follows the implementation specification
and the conditions in the implementation specification for each
transaction, the entity will only be supplying the minimum amount of
data elements necessary to process a transaction (required data
elements and relevant situational data elements); the entity will not
be supplying possible but unnecessary situational data elements.
In addition, we note that the intent behind the maximum defined
data set was to set a ceiling on the nature and number of data elements
inherent to each standard transaction and to ensure that health plans
did not reject a transaction because it contained information they did
not want. For example, if an implementation specification defines a
health care claim or equivalent encounter information transaction as
having at most 50 specific data elements, a health plan could not
require a health care provider to submit a health care claim or
encounter transaction containing more than the 50
[[Page 50323]]
specific data elements as stipulated in the implementation guide. (A
health plan may, however, request additional information through
attachments.)
While operational guidelines or instructions are not included in
the concept of a maximum defined data set, we agree that
standardization of these code set guidelines is highly desirable and
beneficial. We reviewed the available guidelines to determine which
should be adopted as implementation specifications and have found that
there are also many current practical barriers to achieving such
standardization. For example, we recognize that the operational
guidelines for some code sets required for use in the designated
transactions are more complete than others. Also, objective,
operational definitions for most codes are not available and the level
of detail varies widely from code to code. In addition, the processes
for developing guidelines and instructions are typically not open and
include limited participation compared to the code development
processes. However, where such guidelines exist and are universally
accepted, we name them as part of the standard. Therefore, we adopt the
Official ICD-9-CM Guidelines for Coding and Reporting as maintained and
distributed by the Department of Health and Human Services
(Sec. 162.1002). Additionally, we received many public comments in
support of this action. We do not name guidelines for other code sets.
With respect to COB, if a health plan electronically performs COB
exchange with another health plan or other payer, then it must store
the COB data necessary to forward the transaction to that health plan
or other payer.
In addition, we disagree with commenters that we should add a new
``usage'' statement, ``not required unless specified by a contractual
agreement,'' in the implementation guide. We believe that the usage
statement would have the same effect as allowing trading partners to
negotiate which conditional data elements will be used in a standard
transaction. Each health plan could then include different data
requirements in their contracts with their health care providers.
Health care providers would then be required to use a variety of
guidelines to submit transactions to different health plans. This would
defeat the purpose of standardization.
E. Availability of Implementation Specifications
Proposal Summary: We provided the addresses and telephone numbers
for a person to obtain the implementation specifications for the
proposed standards.
Comments and Responses on Implementation Specifications and Their
Availability
1. Comment: One commenter suggested that the X12N (the ASC X12
subcommittee chartered to develop electronic standards specific to the
insurance industry) implementation specifications under HIPAA must be
flexible to permit businesses to customize their EDI process. It was
stated the implementation specifications do not allow flexibility
between trading partners.
Response: We disagree. Allowing flexibility would result in non-
standard implementation of the transactions. The X12N implementation
specifications under HIPAA, adopted in this final rule, are all version
4010. If businesses customize implementations of 4010, the health care
industry would have hundreds of different implementations of the same
transaction.
2. Comment: One commenter recommended we include the following
language: ``In addition, a set of NCPDP standards contains all of the
approved standards and implementation specifications. For an additional
fee, the data dictionaries are available.''
Response: We are aware that data dictionaries are available and
that there is a charge separate from the membership fee for them. We do
not believe this needs to be included in the final rule, since this
information is available through the NCPDP web site.
F. Proposed Requirements Stated in Each Subpart
In each subpart setting forth a standard or standards, we stated
which entities had to use the standard(s), the effective dates for
implementation, and that we are incorporating implementation
specifications (where applicable) by reference.
Comments and Responses on Provisions Appearing in Each Subpart
1. Code Set Standards
Proposal Summary: We proposed in subpart J the following: In
Sec. 142.1002 (now Sec. 162.1000), we stated that health plans, health
care clearinghouses, and certain health care providers would have to
use the diagnosis and procedure code sets as prescribed by the
Secretary for electronic transactions. The proposed standard medical
code sets of these diagnosis and procedure code sets were identified in
the preamble, and the implementation specifications for the transaction
standards in part 142 (now part 162), Subparts K through R, specified
which of the standard medical data code sets should be used in
individual data elements within those transaction standards.
In Sec. 142.1004, we specified that the code sets in the
implementation specification for each transaction standard in part 142,
subparts K through R, would be the standard for the coded nonmedical
data elements present in that transaction standard.
In Sec. 142.1010, the requirements sections of part 142, subparts K
through R, specified that those who transmit electronic transactions
covered by the transaction standards must use the appropriate
transaction standard, including the code sets that are required by that
standard. These sections would further specify that those who receive
electronic transactions covered by the transaction standards must be
able to receive and process all standard codes.
We proposed code sets for various types of services and diagnoses.
Comments and Responses on Proposed Standards for Code Sets and
Requirements for Their Use
Proposed Code Sets
a. Version Control. Comment: The majority of commenters stated that
we should have a clearer requirement for version control, that is, we
should require an electronic transaction to use the version of each
applicable code set that is valid at the time the transaction is
initiated. A common schedule should be established (for example,
calendar year) for conversion to new versions of all standard code
sets. A few commenters indicated that there should be an overlap period
in which both last year's and this year's codes are accepted to
accommodate resubmission or subsequent transfer of claims initiated in
the prior year.
Many commenters said that HHS should maintain a consolidated list
of the current accepted versions of standard code sets and make this
list available to the public, e.g., on the Web. Several commenters
indicated that all of the code sets themselves should be available from
a single HHS website.
Response: We have included in Sec. 162.1000 a clearer statement
that the version of the medical data code sets specified in the
implementation specifications must be the version that is valid at the
time the health care is furnished. Since transactions may have to be
resubmitted long after the time health care was provided, health plans
must be able to process earlier versions of code sets. The version of
the nonmedical data code sets specified in
[[Page 50324]]
the implementation specifications must be the version that is valid at
the time the transaction is initiated.
At this time we are not establishing a common schedule for
implementing new versions of all HIPAA medical data code sets, since
some of the code sets are updated annually (for example, ICD-9-CM, CPT)
and some are updated more frequently. The organizations that maintain
medical data code sets will continue to specify their update schedule.
Different Federal laws mandate the implementation of annual updates to
ICD-9-CM on October 1 and annual updates to the CPT on January 1 of the
following year for their use in the Medicare program. Changing either
of these dates would require legislative action and would also
represent a major change in current practice for many elements of the
health care industry.
We agree that a common web site is a viable solution, but it is
unclear what the Federal role would be in the development of one. We
expect to work with the medical data code set maintainers to explore
this option.
6. Proprietary coding systems. Two of the code sets proposed as
HIPAA standards, CPT and The Code on Dental Procedures and Nomenclature
(referred to as ``The Code'' and published as CDT), are proprietary
products.
Comment: Many commenters stated that the Secretary should not
recommend proprietary systems as national standards. They believed that
the proposed rule lacked a definitive method to guarantee public access
to the proposed standards at low cost, and recommended that the
government should develop or maintain the national standards or acquire
the rights to the standards of choice. Without ownership and control,
the government places itself and the remainder of the health industry
at noteworthy risk. One commenter indicated that implementation of the
standards should be delayed until proprietary code sets have been moved
into the public domain. One commenter said it was illegal for the
Secretary to establish the CPT as a national standard. Another argued
that the ``The Code'' should not be named a national standard.
Response: Under HIPAA, the Secretary has the authority to select
existing code sets developed by either private or public entities and
is not precluded from selecting proprietary code sets. The Secretary is
required to ensure that all standard code sets are updated as needed
and that there are efficient, low cost mechanisms for distribution
(including electronic distribution) of the code sets and their updates.
Free distribution of standard code sets is not required by the statute.
The comments we received regarding code sets were overwhelmingly in
favor of the selection of currently used code sets as the initial
standards. Some of the code sets that are currently used in
administrative transactions are proprietary code sets. We have obtained
some clarification from the developers of these code sets about the
pricing structure and mechanisms for publishing the pricing structure
that will be in place when the initial standards are implemented. The
existence of efficient, low-cost distribution mechanisms will affect
future decisions regarding changes or additions to the code sets
designated as standards.
A health care provider who submits X12N transactions can download
the implementation specifications free of charge from the Washington
Publishing Company website. However, two of the medical codes sets, CPT
and the Dental Code require a fee. Royalties for electronic use of the
CPT are based on a $10.00 per user standard. Royalties for electronic
use of the Dental Code in practice management systems are based on
$10.00 per user site. These royalty fees are normally included in the
purchase and maintenance costs of the electronic systems that such
providers use. The other medical codes sets, HCPCS and ICD-9 CM, may be
downloaded free of charge.
For paper manuals, to which most providers that use these code sets
already subscribe, the CPT manual is $49.95 and the Dental Code manual
is $39.95. In fact, the need for such paper manuals may decrease as
more electronic systems are implemented.
A health care provider who submits retail pharmacy transactions who
wants a copy of the NCPDP standards can pay an annual fee of $550 for
membership in the NCPDP organization, which includes copies of the
implementation specifications for the retail pharmacy standard and the
data dictionary as well as technical assistance in implementation. As a
non-member, the implementations specifications and data dictionary may
be purchased separately for $250 each.
Although nothing in this final rule, including the Secretary's
designation of standards, implementation specifications, or code sets
is intended to divest any copyright holders of their copyrights in any
work referenced in this final rule, future decisions regarding changes
or additions to the code sets designated as standards may be affected
by the existence of efficient, low-cost distribution mechanisms.
c. Code Sets Proposed. The following code sets were proposed as
initial standards:
(a) Diseases, injuries, impairments, other health related problems,
their manifestations, and causes of injury, disease, impairment, or
other health-related problems.
The standard code set for these conditions is the International
Classification of Diseases, 9th edition, Clinical Modification, (ICD-9-
CM), Volumes 1 and 2, as maintained and distributed by the U.S.
Department of Health and Human Services. The specific data elements for
which the ICD-9-CM is the required code set are enumerated in the
implementation specifications for the transaction standards that
require its use.
(b) Procedures or other actions taken to prevent, diagnose, treat,
or manage diseases, injuries and impairments.
(1) Physician Services. The standard code set for these services is
the Current Procedural Terminology (CPT-4) maintained and distributed
by the AMA. The specific data elements for which the CPT-4 (including
codes and modifiers) is a required code set are enumerated in the
implementation specifications for the transaction standards that
require its use.
(2) Dental Services. The standard code set for these services is
The Code on Dental Procedures and Nomenclature, printed as ``The Code''
and published as CDT, maintained and distributed by the ADA for a
charge. The specific data elements for which the Dental Code is a
required code set are enumerated in the implementation specifications
for the transaction standards that require its use.
(3) Inpatient Hospital Services. The standard code set for these
services is the International Classification of Diseases, 9th edition,
Clinical Modification (ICD-9-CM), Volume 3 procedures, maintained and
distributed by the U.S. Department of Health and Human Services. The
specific data elements for which ICD-9-CM, Volume 3 procedures, is a
required code set are enumerated in the implementation specifications
for the transaction standards that require its use.
(c) Other Health-Related Services. The standard code set for other
health-related services is the Health Care Financing Administration
Common Procedure Coding System (Level II of HCPCS) maintained and
distributed by the U.S. Department of Health and Human Services.
(d) Drugs. The proposed standard code set for these entities is the
National Drug Codes maintained and distributed by the U.S. Department
of Health and
[[Page 50325]]
Human Services, in collaboration with drug manufacturers. The specific
data elements for which the NDC is a required code set are enumerated
in the implementation specifications for the transaction standards that
require its use.
(e) Other Substances, Equipment, Supplies, or Other Items Used in
Health Care Services. The proposed standard code set for these entities
is the Health Care Financing Administration Common Procedure Coding
System (Level II of HCPCS) as maintained and distributed by the U.S.
Department of Health and Human Services.
a. Comment: The great majority of commenters supported the
selection of the code sets proposed on the basis that these code sets
were already in wide use among hospitals, physician offices, other
ambulatory facilities, pharmacies, and similar health care locations.
Commenters mentioned that replacement systems could have different
formats and number of digits. This could complicate the initial
conversion. They also pointed out that replacement systems for the ICD-
9-CM are still under development and testing. Many commenters stated
that it would be premature to make a decision on replacements for the
ICD-9-CM prior to their completion and testing.
Response: We agree that the continued use of the proposed coding
systems will be the least disruptive for many entities required to
implement HIPAA standards. The fact that replacement systems are still
under development and testing further supports this decision.
b. Comment: Two commenters stated that the proposal did not reflect
current uses of some code sets. One commenter stated that in addition
to being used for inpatient procedural coding, the ICD-9-CM procedure
codes are also required by many health plans for the reporting of
facility-based outpatient procedures. The second commenter pointed out
that in addition to being used by physicians and other health care
professionals, the combination of HCPCS level I and CPT-4 is required
for reporting ancillary services such as radiology and laboratory
services and by some health plans for reporting facility-based
procedures. Further, Medicare currently requires HCPCS level II codes
for reporting services in skilled nursing facilities.
Response: Health plans must conform to the requirements for code
set use set out in this final rule. Therefore, if a health plan
currently requires health care providers to use CPT-4 to report
inpatient facility-based procedures, they both would be required to
convert to ICD-9.
We agree that the proposal did not reflect all current uses of some
code sets. For example, we agree that CPT-4 is commonly used to code
laboratory tests, yet laboratory tests are not necessarily considered
to be physician services. Moreover, the proposed rule implied that
laboratory tests are a type of other health care service which are
encoded using HCPCS. We believe that the architecture of both coding
sets, HCPCS and CPT-4, is such that they are both frequently used for
coding physician and other health care services. Both of these medical
data code sets are standard medical data code sets and may be used in
standard transactions (see Sec. 162.1002(e)). Therefore, a health plan
using CPT-4 to report outpatient facility-based procedures would not be
required to change that practice.
In addition, the proposed rule did not itemize the types of
services included in other health care services. These other health
care services include the ancillary services, radiology and laboratory
which are mentioned in the comment, as well as other medical diagnostic
procedures, physical and occupational therapy, hearing and vision
services, and transportation services including ambulance. Similarly,
other substances, equipment, supplies, or other items used in health
care services includes medical supplies, orthotic and prosthetic
devices, and durable medical equipment.
In the final rule, we clarify the description of physician and
other health care services and we recognize that two code sets (CPT-4
and HCPCS) are used to specify these services. In the proposed rule, we
used the term ``health-related services'' to help describe these
services. We believe that use of the term ``health-related services''
might suggest that these services are not health care. In an effort to
prevent this confusion, and because the codes in this category are used
to enumerate services meeting the definition of health care, we are
using what we believe is the more appropriate term (``health care
services'') to describe these services. We note that the substance of
the category remains the same. The final rule has been revised to
indicate that the combination of HCPCS and CPT-4 will be used for
physician services and other health care services. The use of ICD-9-CM
procedure codes is restricted to the reporting of inpatient procedures
by hospitals.
In Sec. 162.1002 we clarify the use of medical code sets. The
standard code sets are the following:
(a) ICD-9-CM, Volumes 1 and 2 (including The Official ICD-9-CM
Guidelines for Coding and Reporting), is the required code set for
diseases, injuries, impairments, other health problems and their
manifestations, and causes of injury, disease, impairment, or other
health problems.
(b) ICD-9-CM Volume 3 Procedures (including The Official ICD-9-CM
Guidelines for Coding and Reporting) is the required code set for the
following procedures or other actions taken for diseases, injuries, and
impairments on hospital inpatients reported by hospitals: prevention,
diagnosis, treatment, and management.
(c) NDC is the required code set for drugs and biologics.
(d) Code on Dental Procedures and Nomenclature is the code set for
dental services.
(e) The combination of HCPCS and CPT-4 is the required code set for
physician services and other health care services.
(f) HCPCS is the required code set for other substances, equipment,
supplies, and other items used in health care services.
c. Comment: Although there was wide support for the code sets that
were proposed, a number of commenters pointed out that additional code
sets were needed to cover some health services recorded in
administrative health transactions. One commenter mentioned that the
code sets proposed as standards lacked coverage of alternative health
care procedures and recommended that the Alternative Link coding system
also be designated as a standard code set. Commenters also indicated
that none of the proposed standard code sets covered home infusion
procedures; they recommended that the Home Infusion EDI Coalition
Coding System (HIEC) be selected as a HIPAA standard. HIEC is currently
used by some non-governmental health plans. One commenter recommended
that dental diagnostic codes (SNODENT) developed by the ADA be used as
a national standard. This commenter stated that the ICD-9-CM codes were
inadequate for dentistry.
Response: No single code set in use today meets all of the business
requirements related to the full range of health care services and
conditions. Adopting multiple standards is a way to address code set
inadequacies, but can also introduce complexities due to code set
overlaps. We acknowledge that the coding systems proposed as initial
standards may not address all business needs, especially in the areas
of alternative health care procedures, home infusion procedures, and
dental
[[Page 50326]]
diagnoses. Specific shortcomings should be brought to the attention of
the code set maintainers. The adoption of additional standards may be
an appropriate way to fill gaps in coding coverage in these areas.
Additional code sets must be analyzed by the DSMOs that will make
recommendations to the National Committee on Vital and Health
Statistics. In order to request changes, we recommend working through
the processes described in Secs. 162.910 and 162.940. In the interim,
segments exist in the standard transactions which allow for manual
processing of services for which codes have not been adopted.
d. Comment: While agreeing in general with the code sets proposed
as standards, some commenters indicated that they lacked sufficient
specificity to code data elements in several areas: functional status
and other data elements necessary for studying persons with mental
illness; behavioral health; chronic conditions and functional
assessments covered by long term care insurance; and mental health
services.
Response: We agree the code sets proposed as HIPAA standards may
not cover functional status, mental and behavioral health, chronic
conditions, and mental health services to the extent required by the
legitimate business needs of some health care providers and health
plans. We are unaware of any viable alternative code sets which cover
these areas more completely. Maintainers of code sets seeking to be
named as standards must pursue recognition through the processes set
out at Secs. 162.910 and 162.940.
e. Comment: One commenter, who supported the proposed code sets for
their intended purposes, felt that they lacked the detail necessary to
document a complete clinical encounter. The commenter stated that a
comprehensive health information system requires the use of a
controlled reference terminology to document care, retrieve data to
perform studies, and assess patient outcomes. The commenter stated that
as the implementation of HIPAA progresses towards the adoption of
standards for a complete computer based patient record, the current
coding systems will be inadequate. The commenter stated that the system
developed by Systematized Nomenclature of Human and Veterinary Medicine
International (SNOMED) could be used as a future standard.
Response: We agree that more detailed clinical terminologies are
likely to be needed in complete computer-based patient records. SNOMED
is one of the clinical terminologies being examined by the Work Group
on Computer-Based Patient Records of the National Committee on Vital
and Health Statistics' Subcommittee on Standards and Security. The Work
Group is responsible for studying the issues related to the adoption of
uniform data standards for patient medical record information and the
electronic exchange of such information.
f. Comment: One commenter expressed problems with the use of the
ICD-9-CM and the ICD-10-CM for the collection of both reimbursement and
research related data. It was stated that the data collected in claims'
transactions clog up the reimbursement data system with a large amount
of extraneous material. The commenter also felt that the data were of
dubious quality. The commenter estimated that as much as 50% of the
information gathered within the transactions' systems was for research
purposes only. The commenter felt it was unfair to force the private
sector to subsidize research costs through subterfuge. The commenter
suggested that the issue be resolved by limiting the initial scope of
the ICD-10-CM to collecting only information used or needed for
reimbursement.
Response: The adopted coding systems support the collection of a
wide variety of data that can be used for many purposes. However, we
disagree with the commenter that standard health care claims or
equivalent encounter information transactions collect data primarily
for research purposes. The content of the health care claims or
equivalent encounter information transaction was developed on a
consensus basis by health care providers, health plans, and other
industry representatives as necessary for the conduct of administrative
transactions.
d. Coordination among Code Sets. Comment: Several commenters
recommend that a very tight process be put in place to control overlap
of HCPCS Level II ``D'' codes (The Code on Dental Procedures and
Nomenclature, printed as ``The Code'' and published as CDT) and the
CPT-4 codes. It was questioned whether there will be a review process
in place for dental codes. Since there is some duplication of dental
codes and the CPT-4 codes presently, a review process is needed to
avoid duplication. One commenter stated that to attain and maintain
coding consistency and avoid duplicate codes, the American Dental
Association should be a member of a federal HCPCS committee.
Response: We agree that a mutual exchange of information is
necessary to attain and maintain coding consistency. Panel member(s)
from HCPCS Level II ``D'' Codes (The Code on Dental Procedures and
Nomenclature), CPT-4, and Alpha-Numeric HCPCS will participate or act
as consultants on the other coding panels in order to attain and
maintain coding consistency and avoid duplicate codes.
e. Proposed changes to Dental Codes. Proposal: In HCPCS, the first
digit ``0'' in the American Dental Association's The Code on Dental
Procedures and Nomenclature is replaced by a ``D'' to eliminate
confusion and overlap with certain CPT-4 codes. The ADA has agreed to
make this change an official part of the dental codes they distribute
and to replace their first digit ``0'' with a ``D.'' Consequently,
dental codes will no longer be issued within HCPCS as of the year 2000.
The ADA will be the sole source of the authoritative version of ``The
Code.''
Comment: There were several specific comments about the proposal to
change the initial digit in the ADA's version of The Code on Dental
Procedures and Nomenclature from ``0'' to ``D.'' Comments in favor of
the change agreed that it would avoid potential overlap and confusion.
One commenter indicated that this was particularly true for those
claims that would continue to be submitted manually since the ASC X12N
837 and 835 transactions contain a code qualifier that clearly
indicates which procedure code is being used. One commenter stated that
as the ADA replaces the leading ``0'' with the letter ``D,'' some of
the resulting codes will coincide with existing HCPCS Level II ``D''
codes, but will have totally different meanings. This could create
great confusion at adjudication time. Dealing with a coding system that
contains an alphabetic character would also cause problems for many
systems. One commenter believed that it is the responsibility of both
the ADA and the Department to specify clear and unambiguous rules that
will affect this transition between coding systems, so the resulting
confusion is minimized. The commenter suggested the following options:
(1) Replace the codes nationwide on a certain date; (2) choose a letter
other than ``D'' for ``The Code,'' so there is no overlap; or (3)
retain the leading zero in ``The Code'' and assure that there continues
to be no conflict or overlap with the CPT-4 anesthesia codes, as
currently they do not overlap.
There were no comments about the proposal that ``The Code'' be
removed from HCPCS and that the ADA become the sole source of the
definitive version of these codes.
Response: The ADA will change the leading ``0'' to a ``D'' as
proposed. Many organizations are already using the ``D''
[[Page 50327]]
Codes, which contains the leading ``D,'' without difficulty, and we
expect others to make this transition without difficulty. Although we
did not receive comments that specifically addressed the removal of the
dental codes from the HCPCS, general comments about the desirability of
more consolidated access to all HIPAA code sets have led us to revise
our position on the inclusion of ``The Code'' in the HCPCS. Thus, the
dental codes will be available from two sources: the ADA, and through a
licensing agreement between HCFA and the ADA.
f. Other Dental Code Issues. a. Comment: One commenter (a major
health plan) emphasized the critical importance of federal oversight
and monitoring of dental coding maintenance and revision to ensure that
dental data sets do not incorporate fragmented or unbundled procedures
that are integral parts of a single dental service. For example, in
``The Code-1,'' the procedure code 04910, periodontal prophylaxis/
periodontal recall, included the examination as part of this single
dental service; in ``The Code-2,'' the examination is unbundled and is
listed as a separate procedure. The import of this unbundling is the
potential for increasing cost of care, without otherwise increasing the
services provided. At the very least, to control the impact that
unbundling might potentially have on the cost of care, it was
recommended that once a particular standard code is established, it may
not be deleted and any changes or modifications to the code or
descriptor be included as a new code.
Response: The American Dental Association (ADA) will be responsible
for maintaining an appropriate open process for updating ``The Code.''
Interested public and private sector organizations and groups will have
the opportunity for substantive input, as they will for all HIPAA
standards. The Department will continue to review the process of code
modification to ensure that the code sets continue to meet the business
needs of the industry.
b. Comment: One commenter questioned whether the addition of a
specific procedure to the dental codes adopted as a HIPAA standard
meant that a health plan had to cover the procedure or whether it meant
the health plan only had to be able to receive and process the standard
code for the procedure.
Response: The establishment of a code in any of the code sets
adopted as HIPAA standards does not require that a health plan cover
the coded procedure. However, health plans must be able to receive and
process all codes in HIPAA standard code sets. In other words,
transactions containing standard codes may be returned with a message
that the procedure is not covered by the health plan to whom they have
been submitted. Transactions may not be rejected because the health
plan's system does not recognize valid standard codes.
g. Future Consideration of ICD-10 Code Sets. Proposal Summary:
Although the exact timing and precise nature of changes in the code
sets designated as standards for medical data are not yet known, it is
inevitable that there will be changes to coding and classification
standards after the year 2000. For example, the ICD-10-CM for diagnosis
may replace the ICD-9-CM as the standard for diagnosis data. When any
of the standard code sets proposed in this rule are replaced by wholly
new or substantially revised systems, the new standards may have
different code lengths and formats.
a. Comment: Several commenters felt that the ICD-10-CM should be
considered as a future national standard after the year 2000. The
commenters stated that the proposed initial standard, ICD-9-CM, should
be selected since it was currently in use. They pointed out that the
ICD-10-CM was still under development. Several commenters suggested
that the system be tested and evaluated as a future national standard
when the final draft is completed. One commenter was supportive of the
system and suggested that factors such as code length be considered as
part of the testing and evaluation of the ICD-10-CM system. Several
commenters felt that the current draft of the ICD-10-CM showed
significant improvements over the ICD-9-CM. Another commenter stated
that the system would allow for more accurate reporting by health care
providers. One commenter stated that the use of the ICD-10-CM will
require considerable training.
Response: We agree with the commenters that the ICD-10-CM has great
potential as a replacement for the ICD-9-CM. We also agree that a final
evaluation of the system should await the completion of the final draft
and testing.
b. Comment: Several commenters stated the ICD-10-PCS (which is
under development for use in the United States as a replacement for the
procedure coding section of ICD-9-CM) should be considered as a future
national standard. Most commenters recommended that the decision to use
or not use the ICD-10-PCS should await final development and testing.
The majority of commenters stated that future systems, such as the ICD-
10-PCS, should not be implemented until after the year 2000. However,
several commenters supported the future migration to the ICD-10-PCS
because it was felt to offer significant improvements over the ICD-9-
CM. One commenter stated that the ICD-10-PCS development project has
made valuable contributions to many issues relating to coding and
terminology. Another commenter expressed concern about the level of
detail in the ICD-10-PCS and recommended that further studies and
trials should be performed in order to establish the relative costs and
benefits of the system. This commenter was particularly concerned about
the pathology section and felt it needed more work. Others praised the
increased level of detail in the system and felt the added clinical
information would be useful.
Response: We believe the ICD-10-PCS has great promise as a future
replacement of the ICD-9-CM, volume 3. However, we also believe the
system needs additional testing and revision prior to making a decision
about its use as a national standard. The system is dramatically
different from the ICD-9-CM containing more digits, greater detail, and
a more organized approach. With any new system, many factors must be
weighed prior to making a recommendation about national use. Changing a
coding system will have a great impact on national data and would be
evaluated carefully by the Designated Standard Maintenance
Organizations and the NCVHS, with opportunity for public input.
h. Universal Product Number (UPN). Proposal: The Universal Product
Number (UPN) identifies medical equipment and supplies. It was not
recommended as an initial standard for the following reasons: the
existence of two different sets of UPN codes; incomplete coverage--
approximately 30 percent of the health care products do not have a UPN
assigned to them; and lack of experience with UPNs for reimbursement.
However, the proposal asked for comments regarding UPNs and when it
might be appropriate to designate one or more UPN systems as HIPAA
standards.
a. Comment: Several commenters stated that the HCPCS level II codes
that we recommended to identify medical equipment and supplies are
currently not specific enough for accurate claims processing, proper
financial controls, or proper tracking of utilization. Health care
providers use many different kinds of supplies and equipment not found
in the HCPCS level II codes. It was argued that establishing UPNs as a
national coding system for identifying health
[[Page 50328]]
care supplies and equipment will provide the following advantages over
the HCPCS level II codes:
<bullet> The UPN system would allow for more accurate billing and
better fraud and abuse detection than the use of a non-specific coding
system such as the HCPCS level II.
<bullet> UPNs would improve administrative efficiency and
effectiveness.
<bullet> The product specificity that UPNs provide in identifying
the actual specifications of manufacturer's products and packaging
sizes is essential to managing health industry transactions and
determining accurate payment amounts.
<bullet> The UPN mechanism is already in place and has been proven
in use.
Several commenters agreed that we should not include the UPNs in
the initial list of standards. A cautious approach and considerable
further study is necessary to determine if the objectives of
administrative simplification and reduced costs within the health care
system will be achieved by using the UPNs as a national coding system
for health care products.
Response: We agree that additional information regarding the
utility of the UPNs for claims processing needs to be obtained before a
decision is made to require their use. Specifically, more information
is needed concerning the costs and benefits that can be expected from
using the UPNs and the extent to which their use would promote
administrative simplification. Also, information is needed regarding
the standards that would have to be established to ensure that the UPNs
could be used effectively by third party payers. Another issue that
needs to be studied is the amount and type of information that an
insurer would have to obtain from manufacturers in order to adequately
identify the products represented by approximately three to five
million UPNs. Only detailed information concerning the products that
are represented by the UPNs, provided in a consistent manner, will
allow comparisons to determine if products from different manufacturers
are functionally equivalent.
b. Comment: Several commenters expressed concern that the health
care industry may continue to use two different types of UPN systems
rather than a single system. They asserted that this is the best time
to choose between the two coding councils, the Health Care Uniform Code
Council (UCC) and the Health Industry Business Communications Council
(HIBCC), because there has not been a substantial investment in either
system.
Response: We believe that neither UPN system should be selected at
this time, based on the reasons outlined above. We look to the industry
to resolve the issue of whether the two systems should continue.
Before requiring the use of UPNs, we need to obtain more
information regarding the costs and benefits of implementing the UPN,
the adaptability of the UPN system for making coverage and payment
determinations, and for combating fraud and abuse. We will be
monitoring demonstrations being conducted by California Medicaid to
determine the cost and feasibility of using UPNs in the health care
industry. The entity proposing such a demonstration must request an
exception from the standards following the procedures in Sec. 162.940.
i. NDC. a. Comment: Commenters generally agreed with our
recommendation to eliminate Level II HCPCS codes for drugs by the year
2000 and to use NDC for all drugs. However, some commenters disagreed
with applying this requirement to non-pharmacy claims and recommended
that the NDC be used only for retail pharmacy claims until sufficient
benefits and overhead costs of exclusively implementing the NDC codes
can be further researched. It was mentioned that the NDC numbers notate
a vial size and physician injections often results in a single vial
being used for multiple patients. They alleged that current Level II
HCPCS codes allow for this identification. Several commenters also
recommended that those durable medical equipment (DME) that do not have
Level II HCPCS codes should use NDC codes.
It was noted that Medicaid agencies must reimburse health care
providers for supplying the drug products of any company in the Federal
Rebate Program as long as the drug reimbursement rates are within the
Federal Upper Payment Limit. Because many companies produce the same
drug, there are often many NDCs that correspond to the same drug with
the same Level II HCPCS code. It was stated that Medicaid uses the
Level II HCPCS codes to indicate which of these many products is
reimbursable for health care provider submitted drug transactions.
One commenter suggested moving the NDC codes to the HCPCS codes.
The commenter stated using two different coding systems (NDC and HCPCS)
is counter to the overall goal of administrative simplification.
Response: We continue to believe that use of NDC to identify drugs
is the most appropriate and efficient coding system available. While
commenters gave various reasons in support of their objection to
requiring use of NDC for non-pharmacy claims, most of these reasons
were based upon a misunderstanding of the proposal. For example,
contrary to one comment, the Medicaid drug rebate program requires the
NDC, not the generalized Level II HCPCS code for the rebate program.
In response to the commenter who stated that the NDC does not
always allow identification of partial vials (that is, when a single
vial is used among multiple patients), we note that although this may
be true with certain NDC codes, the transaction standards allow the
reporting of dosage units for the NDC. In addition, although certain
commenters requested a crossover period during which both nonstandard
and standard codes may be used for processing, we believe that it is
more reasonable to require all of the systems' changes that we can at
one time, rather than addressing the changes in a piecemeal fashion.
The two years after the effective date allowed before compliance is
required will allow for a smooth transition period. Both non-standard
electronic formats and the new standard transactions may be used during
this transition period.
With respect to DME claims, HCPCS Level II is the proposed standard
for DME. DME do not receive NDC as NDC are national drug codes. We are
not moving the NDC codes to the HCPCS since each are separate coding
systems for different purposes. Commenters generally supported this
recommendation.
b. Comment: One commenter recommended to either revise the existing
NDC or create a new coding system so the codes are distinctive in their
format. The commenter stated that the coding system should serve the
inventory and distribution industries as well as assist with the
billing and inventory management of outpatient and hospital settings.
Moreover, the commenter wanted the system to have the capacity to last
50 to 100 years or longer.
One commenter stated the NDC system was designed for health care
providers who manufacture drug products or pay for drug therapy. The
commenter said the design is completely inappropriate for the needs of
most health care providers who prescribe drug therapies, dispense drug
products, or administer medications to patients. The NDC identifies
drug products at a level of detail (the package) that is much too
granular to be of any practical use for most health care providers. The
commenter recommended to select either
[[Page 50329]]
MediSource Lexicon or the HL7 Vocabulary Special Interest Group Drug
Model and Listing as the standard code set for drugs.
Response: In general, the Act requires the Secretary to adopt
existing code sets developed by private or public entities, unless code
sets for the data elements have not been developed by such entities.
When new code sets are developed or existing ones revised, they need to
be evaluated. Demonstrations need to be performed in order to determine
the cost and feasibility of such codes sets in the health care
industry. MediSource and HL7 are not currently used within the
transaction system for administrative and reimbursement purposes for
retail pharmacy claims. The majority of commenters supported the
adoption of the NDC coding system for pharmacy claims and did not
support one commenter's opinion regarding difficulties perceived. The
NDC was originally developed as a 10-digit identifier made up of three
subcodes: the manufacturer code, the product code, and the package size
code. Each subcode is variable in length. Some subcodes are reported
with leading zeroes and some truncate the leading zero. This leads to
variab