[Federal Register Volume 70, Number 184 (Friday, September 23, 2005)]
[Proposed Rules]
[Pages 55990-56025]
From the Federal Register Online via the Government Publishing Office [www.gpo.gov]
[FR Doc No: 05-18927]



[[Page 55989]]

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

Part III





Department of Health and Human Services





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



Office of the Secretary



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



45 CFR Part 162



HIPAA Administrative Simplification: Standards for Electronic Health 
Care Claims Attachments; Proposed Rule

Federal Register / Vol. 70, No. 184 / Friday, September 23, 2005 / 
Proposed Rules

[[Page 55990]]


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

DEPARTMENT OF HEALTH AND HUMAN SERVICES

Office of the Secretary

45 CFR Part 162

[CMS-0050-P]
RIN 0938-AK62


HIPAA Administrative Simplification: Standards for Electronic 
Health Care Claims Attachments

AGENCY: Office of the Secretary, HHS.

ACTION: Proposed rule.

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

SUMMARY: This rule proposes standards for electronically requesting and 
supplying particular types of additional health care information in the 
form of an electronic attachment to support submitted health care 
claims data. It would implement some of the requirements of the 
Administrative Simplification subtitle of the Health Insurance 
Portability and Accountability Act of 1996.

DATES: To be assured consideration, comments must be received at one of 
the addresses provided below, no later than 5 p.m. on November 22, 
2005.

ADDRESSES: In commenting, please refer to file code CMS-0050-P. Because 
of staff and resource limitations, we cannot accept comments by 
facsimile (FAX) transmission.
    You may submit comments in one of four ways (no duplicates, 
please):
    1. Electronically. You may submit electronic comments on specific 
issues in this regulation to http://www.cms.hhs.gov/regulations/ecomments. Attachments should be in Microsoft Word, WordPerfect, or 
Excel; however, we prefer Microsoft Word.
    2. By mail. You may mail written comments (one original and two 
copies) to the following address ONLY:
    Centers for Medicare & Medicaid Services, Department of Health and 
Human Services, Attention: CMS-0050-P, P.O. Box 8014, Baltimore, MD 
21244-8014.
    Please allow sufficient time for mailed comments to be received 
before the close of the comment period.
    3. By express or overnight mail. You may send written comments (one 
original and two copies) to the following address ONLY: Centers for 
Medicare & Medicaid Services, Department of Health and Human Services, 
Attention: CMS-0050-P, Mail Stop C4-26-05, Baltimore, MD 21244-1850.
    4. By hand or courier. If you prefer, you may deliver (by hand or 
courier) your written comments (one original and two copies) before the 
close of the comment period to one of the addresses above or below. If 
you intend to deliver your comments to the Baltimore address, please 
call (410) 786-7195 in advance to schedule your arrival with one of our 
staff members.
    Hubert H. Humphrey Building, Room 445-G 200 Independence Avenue, 
SW., Washington, DC 20201; or 7500 Security Boulevard, Baltimore, MD 
21244-1850.
    (Because access to the interior of the HHH Building is not readily 
available to persons without Federal Government identification, 
commenters are encouraged to leave their comments in the CMS drop slots 
located in the main lobby of the building. A stamp-in clock is 
available for persons wishing to retain a proof of filing by stamping 
in and retaining an extra copy of the comments being filed.)
    Comments mailed to the addresses indicated as appropriate for hand 
or courier delivery may be delayed and received after the comment 
period.
    For information on viewing public comments, see the beginning of 
the SUPPLEMENTARY INFORMATION section.

FOR FURTHER INFORMATION CONTACT: Lorraine Tunis Doo, (410) 786-6597.

SUPPLEMENTARY INFORMATION: Submitting Comments: We welcome comments 
from the public on all issues set forth in this proposed rule to assist 
us in fully considering issues and developing policies. You can assist 
us by referencing the file code [CMS-0050-P] and the specific ``issue 
identifier'' that precedes the section on which you choose to comment.
    Inspection of Public Comments: All comments received before the 
close of the comment period are available for viewing by the public, 
including any personally identifiable or confidential business 
information that is included in a comment. CMS posts all comments 
received before the close of the comment period on its public Web site 
as soon as possible after they have been received. Comments received 
timely will be available for public inspection as they are received, 
generally beginning approximately 3 weeks after publication of a 
document, at the headquarters of the Centers for Medicare & Medicaid 
Services, 7500 Security Boulevard, Baltimore, Maryland 21244-1850, 
Monday through Friday of each week from 8:30 a.m. to 4 p.m. To schedule 
an appointment to view public comments, phone 1-800-743-3951.

Table of Contents

I. Background
    A. Summary
    B. Legislation
    C. Standards Setting Organizations
    1. Accredited Standards Committee X12 (ASC X12)
    2. Health Level Seven (HL7)
    D. Industry Standards, Implementation Guides and Additional 
Information Specifications
    1. ASC X12N and the HL7 Implementation Guides and HL7 Additional 
Information Specifications
    2. Implementation Guides in HIPAA Regulations
II. Provisions of the Proposed Regulations
    A. Definitions
    1. Ambulance Services
    2. Attachment Information
    3. Clinical Reports
    4. Emergency Department
    5. Laboratory Results
    6. Logical Observation Identifiers Names and Codes 
(LOINC[supreg]))
    7. Medications
    8. Rehabilitation Services
    B. Effective Dates
    C. Overview of Key Information for Electronic Health Care Claims 
Attachments
    1. Overview of Extensible Markup Language (XML)
    2. Overview of Clinical Document Architecture
    3. How XML Is Applied Within the Clinical Document Architecture
    4. Transactions for Transmitting Electronic Attachments
    5. Electronic Claims Attachment Types
    6. Format Options (Human vs. Computer Variants) for Electronic 
Claims Attachments
    7. Combined Use of Two Different Standards Through Standard 
Development Organization (SDO) Collaboration
    D. Electronic Health Care Claims Attachment Business Use
    1. Electronic Health Care Claims Attachment vs. Health Care 
Claims Data
    2. Solicited vs. Unsolicited Electronic Health Care Claims 
Attachments
    3. Coordination of Benefits
    4. Impact of Privacy Rule
    5. Impact of the Security Rule
    6. Connection to Signatures (Hard Copy and Electronic)
    7. Connection to Consolidated Health Informatics Initiative
    8. Health Care Provider vs. Health Plan Perspective
    9. Health Care Clearinghouse Perspective
    E. Electronic Health Care Claims Attachment Content and 
Structure
    F. Alternatives Considered: Candidate Standards for Transaction 
Types and Code Sets
    1. Transactions
    a. Health Care Claims Attachment Request Transaction
    b. Health Care Claims Attachment Response Transaction
    2. Code Sets
    3. Implementation Specifications for Sending and Receiving 
Additional Health Care Information within a Transaction
    G. Proposed Standards
    1. Code Set
    2. Electronic Health Care Claims Attachment Request Transaction

[[Page 55991]]

    3. Electronic Health Care Claims Attachment Response Transaction
    4. Examples of How Electronic Health Care Claims Attachments 
Could Be Implemented
    a. Use of the Proposed Transactions Specifications, and Codes 
for Electronic Health Care Claims Attachments
    b. White Paper from HL7
    H. Requirements (Health Plans, Covered Health Care Providers and 
Health Care Clearinghouses)
    1. Additional Information Specification (AIS) Uses: Attachment 
Types That May Be Used for Any Service
    a. Clinical Reports
    b. Laboratory Results
    c. Medications
    2. Additional Information Specification (AIS) Uses: Attachment 
Types for Specific Services
    a. Rehabilitation Services
    b. Ambulance Service
    c. Emergency Department
    3. Maximum Data Set
    I. Specific Documents and Sources
III. Modifications to Standards and New Electronic Attachments
    A. Modifications to Standards
    B. Additional Information Specifications for New Electronic 
Attachments
    C. Use of Proposed and New Electronic Attachment Types Before 
Formal Approval and Adoption
IV. Collection of Information Requirements
V. Response to Comments
VI. Regulatory Impact Analysis
    A. Overall Impact
    1. Affected Entities (Covered Entities)
    2. Effects of Various Options
    B. Cost and Benefit Analysis
    1. General Assumptions, Limitations, and Scope
    2. Cost and Benefit Analysis for Health Plans
    3. Cost and Benefit Analysis for Health Care Providers
    4. Cost and Benefit Estimates
    a. Costs of Implementation
    b. Benefits of Implementation
    5. Conclusions
    C. Guiding Principles for Standard Selection
    1. Overview
    2. General
Regulations Text

I. Background

A. Summary

    This proposed rule recommends the adoption of a set of standards 
that will facilitate the electronic exchange of clinical and 
administrative data to further improve the claims adjudication process 
when additional documentation (also known as health care claim 
attachments) is required. This rule proposes two X12N transaction 
standards to be used--one to request the information and one to respond 
to that request with the answers or additional information. This rule 
also proposes the use of Health Level 7 (HL7) specifications for the 
content and format of communicating the actual clinical information. 
And finally, this rule proposes the adoption of the Logical Observation 
Identifiers Names and Codes, or LOINC[supreg] for specific 
identification of the additional information being requested, and the 
coded answers which respond to the requests. The combination of the 
X12N and HL7 standards for purposes of these transactions is proposed 
because the X12N standards are standards for exchanging administrative 
information, and the HL7 standards are standards for exchanging 
clinical information; the marriage of these standards for the 
electronic health care claims attachment transactions uses the 
capabilities and advantages of each type of standard. The LOINC[supreg] 
code set already has the most robust set of codes for laboratory 
results and clinical reports, and now includes the codes for the 
attachment ``questions'' or requests proposed in this rule.
    Electronic data interchange (EDI) is the electronic transfer of 
information (such as electronic health care claims and supplemental 
information) in a standard format. EDI allows entities within the 
health care system to exchange medical, billing, and other information 
to process transactions in a more expedient and cost effective manner. 
Use of EDI reduces handling and processing time and eliminates the risk 
of lost paper documents. EDI can therefore reduce administrative 
burdens, lower operating costs, and improve overall data quality.
    The health care industry already recognizes the benefits of EDI, 
and there has been a steady increase in its use over the past decade. 
In fact, for many years, health plans have been encouraging their 
health care providers to move toward electronic transmissions of claims 
and inquiries, both directly and through third parties such as health 
care clearinghouses, but the transition has been inconsistent across 
the board. It is assumed that the absence of standardization has made 
it difficult to encourage widespread increases in EDI and to develop 
software that could be employed by multiple users. The Health Insurance 
Portability and Accountability Act (HIPAA) of 1996 (Pub. L. 104-191, 
enacted on August 21, 1996) Transaction Rule standards, with entity 
type specific compliance dates in October of either 2002 or 2003, 
addressed that lack of standardization in the health care industry. 
Just as experience and process improvements have grown with EDI, 
experience with the standard transactions and automation will result in 
additional efficiencies and savings for both health care providers and 
health plans.
    The expectation, when standard national EDI formats and data 
content for health care transactions were adopted, was that the 
administrative burdens on health plans, health care providers, and 
their billing services would decrease. A standard EDI format allows 
data interchange using a common interchange structure, thus eliminating 
the need for users to program their data processing systems to 
accommodate multiple formats. Standardization of the interchange 
structure also involves specification of which data elements are to be 
exchanged; uniform definitions of those specific data elements in each 
type of electronic transaction; and identification of the specific 
codes or values that are valid for each data element.

B. Legislation

    Through subtitle F of title II of HIPAA, the Congress added to 
title XI of the Social Security Act (``the Act'') a new subpart C, 
entitled ``Administrative Simplification.'' HIPAA affects several 
titles in the United States Code. Throughout this proposed rule, we 
refer to the Social Security Act as ``the Act,'' and we refer to the 
other laws cited in this document by their names. One purpose of 
subtitle F was to improve the efficiency and effectiveness of the 
health care system in general by encouraging the development of a more 
automated health information system through the establishment of 
standards and requirements to facilitate the electronic transmission of 
certain health information. The Congress included provisions to address 
the need for supplemental health care claim information in the form of 
electronic attachments to claims.
    Part C of title XI consists of sections 1171 through 1179 of the 
Act. These sections define various terms and impose requirements on the 
Department of Health and Human Services (HHS), health plans, health 
care clearinghouses, and certain health care providers, concerning the 
conduct of electronic transactions, among other things.
    HIPAA was discussed in greater detail in Standards for Electronic 
Transactions (65 FR 50312), published on August 17, 2000 (Transactions 
Rule), and the Standards for Privacy of Individually Identifiable 
Health Information (65 FR 82462), published on December 28, 2000 
(Privacy Rule). Rather than repeating the discussion here, the reader 
is referred to those documents for further information. Specific 
information is provided in those

[[Page 55992]]

documents on the content of each section of HIPAA (for example, they 
explain that section 1173 of the Act requires the Secretary to adopt 
standards for transactions and data elements to be included in covered 
transactions; section 1174 of the Act describes the timetable for 
establishing standards and for compliance with those standards; 
sections 1176 and 1177 of the Act establish penalties for violations of 
the established standards; and so forth).
    Two provisions of the Act are particularly relevant to the 
electronic health care claims attachment standards being presented 
here:
    <bullet> Section 1172 of the Act contains requirements concerning 
standard setting. It states that the Secretary must adopt a standard 
developed, adopted, or modified by a standard setting organization 
(that is, a standard setting organization accredited by the American 
National Standards Institute (ANSI) that develops standards for 
transactions or data elements) after consulting with the National 
Uniform Billing Committee (NUBC), the National Uniform Claim Committee 
(NUCC), Workgroup for Electronic Data Interchange (WEDI), and the 
American Dental Association (ADA), assuming there is a suitable 
standard.
    <bullet> Section 1173(a)(2)(B) identifies a health claim attachment 
[sic] as one transaction for which electronic standards are to be 
adopted.

C. Standards Setting Organizations

    ANSI accredits organizations to develop standards under the 
condition that procedures used to develop and approve the standards 
meet certain due process requirements and that the process is 
voluntary, open, and based on obtaining consensus. These accredited 
organizations are referred to by ANSI as Accredited Standards 
Developer(s) (ASD) or Standards Development Organization(s)(SDO). The 
standards for the transactions proposed in this rule come from two such 
accredited organizations, Accredited Standards Committee X12 (ASC X12) 
and Health Level Seven (HL7).
1. Accredited Standards Committee X12
    The Accredited Standards Committee X12 (ASC X12) is the SDO 
accredited by ANSI to design national electronic standards for a wide 
range of administrative and business applications across many 
industries. ASC X12 membership is open to all individuals and 
organizations. A subcommittee of ASC X12, ASC X12N, develops electronic 
standards specific to the insurance industry, including health care 
insurance. Volunteer members of the ASC X12N subcommittee, including 
health care providers, health plans, bankers, and vendors involved in 
software development and billing/transmission of health care data, as 
well as organizations involved in other business aspects of health care 
administrative activities, worked together to develop standards for 
electronic health care transactions. These standards included 
transactions for common administrative activities: claims, remittance 
advice, claims status, enrollment, eligibility, and authorizations and 
referrals. Within ASC X12N, Workgroup 9: Patient Information (WG9) 
undertook the tasks associated with evaluating appropriate standards 
for electronic health care claims attachments. The WG9 workgroup is 
comprised of representatives from private and government insurers, 
software vendors, health care clearinghouses, State and Federal 
agencies, health insurance standards organizations, and provider 
associations.
2. Health Level Seven
    HL7 is a not-for-profit, ANSI-accredited SDO that provides 
standards for the exchange, management, and integration of data that 
support clinical patient care and the management, delivery, and 
evaluation of health care services. While other standards development 
or standard setting organizations create standards or protocols to meet 
the business needs of a particular healthcare domain such as pharmacy, 
medical devices, or insurance, HL7's domain is principally clinical 
data. Its specific emphasis is on the interoperability between 
healthcare information systems. In fact, ``Level Seven'' refers to the 
highest level of the International Standards Organization's 
communications model for Open Systems Interconnection--which is the 
application level of a system. The application level addresses the 
definition of the data to be exchanged, the timing of the interchange, 
and the communication of certain errors to the application. The seventh 
level supports such functions as security checks, participant 
identification, availability checks, exchange mechanism negotiations, 
and most significantly, data exchange structuring. HL7 is in a unique 
position to participate in standard setting for health information 
because its focus is on the interface requirements of the entire health 
care organization rather than on a particular domain.
    HL7 membership is open to all individuals and organizations. Within 
HL7, similar to Work Group 9 under X12N, the Attachments Special 
Interest Group (ASIG) includes industry experts representing health 
care providers, health plans, and vendors, and is dedicated to 
developing the criteria and standards for electronic health care claims 
attachments. This group created the Additional Information 
Specifications (AIS) referenced in this proposed rule. The ASIG is 
responsible for those tasks associated with creating and maintaining 
the documents that specify the content, format and codes for submitting 
and responding to requests for each type of electronic health care 
claims attachment. These documents are known as AIS, which again, are 
each a set of instructions and associated code tables created and 
maintained by HL7 that describes, lists, or itemizes the additional 
information that is to be sent and how such information is to be 
conveyed in an electronic health care claims attachment.

D. Industry Standards, Implementation Guides, and Additional 
Information Specifications

1. ASC X12N and the HL7 Implementation Guides and HL7 Additional 
Information Specifications
    ASC X12N: The ASC X12 Subcommittee N: Insurance (ASC X12N) 
publishes documented specifications for standard data interchange 
structures (message transmission formats) that apply to various 
business needs. For example, the X12N 820 transaction standard for 
premium payment can be used to submit payment for automobile insurance 
or casualty insurance, as well as for health insurance. The X12N 820 
was adopted as one of the standards under HIPAA for premium payments 
from an employer or group health plan to the insurer or health plan. In 
order to make these general standards functional for industry-specific 
uses, it became critical to develop implementation specifications. 
These specifications, referred to by the industry as ``implementation 
guides,'' are based upon ASC X12 standards and contain the detailed 
instructions developed by ASC X12N for using a specific transaction to 
meet a specific business need. Each ASC X12N implementation guide has a 
unique version identification number (for example, 004010, 004050, or 
005010) where the highest version number represents the most recent 
version. Implementation Guides are written collaboratively by X12N 
workgroups, and are voted upon as described below.
    The ASC X12 committee is the decision-making body responsible for

[[Page 55993]]

obtaining consensus from the entire organization, which is necessary 
before seeking ANSI approval of a standard in the field of health 
insurance. The ASC X12N Subcommittee develops standards and conducts 
maintenance activities. The draft documents are made available for 
public review and comment. After the comments are addressed, the 
revised document is presented to the entire ASC X12N subcommittee 
membership group for approval. This work is then reviewed and approved 
by the membership of ASC X12 as a whole. In sum, Implementation Guides 
developed by ASC X12N must be ratified by a majority of voting members 
of the ASC X12N subcommittee and the executive committee of X12 itself.
    HL7: To establish its standards, HL7 conducts a three-step process. 
First, standards are developed and accepted or rejected by voting at 
the technical committee level. All HL7 members are eligible to vote on 
standards, without regard to whether they are members of the committee 
that wrote the standard. Non-members may also vote on a given ballot 
for a standard, for which privilege they pay an administrative fee. 
HL7's policy states that it shall assess an administrative fee for the 
processing, handling, and shipping of the ballot package. The 
administrative fee does not exceed the fee associated with an 
individual membership in HL7. Second, HL7 technical committees and 
special interest groups vote on ``recommendations'' and at least two-
thirds of the total votes must be positive for approval. Third, if 
approved at the technical committee level, the recommended standards 
are submitted to the entire HL7 organization for approval. Finally, 
they are submitted to ANSI for certification.
2. Implementation Guides in HIPAA Regulations
    Section 1172(d) of the Act directs the Secretary to establish 
specifications for implementing each of the standards adopted under 
this part.
    For electronic transaction standards, the SDOs developed 
``Implementation Guides'' for implementing the same standards for a 
number of different business purposes. For example, the general ASC X12 
claim, the 837, has separate implementation guides that permit its use 
in automobile, liability, and health care claims. The approach taken in 
the final Transactions Rule was to adopt a specific ``Implementation 
Guide'' as both the ``standard'' and the ``implementation 
specifications'' for each health care transaction.
    The regulations text of this proposed rule also adopts the 
referenced guides as both the standard and the implementation 
specifications for each electronic health care claim attachment 
transaction. Accordingly, this rule proposes the adoption of specific 
X12 Implementation Guides (for example, the ASC X12N 277 version 4050) 
as both the standard and the implementation specification for each 
transaction. To avoid confusion in the use of certain similar terms in 
this proposed rule, we use the term ``Implementation Guide'' only when 
referring to specific documents published by ASC X12N. Therefore, when 
we refer to the master HL7 Implementation Guide, we will state the full 
document name: ``HL7 Additional Information Specification 
Implementation Guide,'' or HL7 AIS IG. We do not otherwise refer to 
``implementation specifications'' or distinguish between ``standards'' 
and ``implementation specifications.''
    The 4050 versions of the X12 Implementation Guides are compatible 
with the current X12 4010 guides adopted for HIPAA transactions--
version 4010-1a so that the two transactions can be used together as 
necessary. In other words, a claims transaction (837 version 4010-1a) 
may be accompanied by a health care claims attachment response 
transaction (275 version 4050). Public comments on the draft versions 
of the X12 Implementation Guides for version 4050 of the X12N 277 and 
X12N 275 were solicited between December 5, 2003 and January 9, 2004. 
The current guides may be obtained from http://www.wpc-edi.com.
    The other set of documents proposed for use with electronic health 
care claims attachments are called HL7 Additional Information 
Specifications (AIS). These were drafted by the HL7 ASIG work group and 
were balloted and approved by HL7 in September 2003. These AIS are used 
in concert with the X12 Implementation Guides and provide the 
instructions for the use of the proposed code set, to be described 
later in this preamble. The adoption of the HL7 documents would fulfill 
the legal mandate for the Secretary to establish the implementation 
specifications for the HIPAA standards proposed for adoption in 
accordance with 1172(d) of the Act.
    The X12N Implementation Guides, HL7 AIS IG, HL7 AIS, and the 
LOINC[supreg] code set proposed for adoption in this proposed rule, are 
all copyrighted by their respective organizations, and each document 
includes a copyright statement. The copyright protection ensures the 
integrity of the materials and provides appropriate attribution to the 
developers. The materials are all available at no charge. Later in this 
preamble and in the regulations themselves, we provide the mailing 
addresses and Internet sites for the documents so that readers can 
obtain them in a convenient manner that will allow for their review, 
along with this proposed rule.

II. Provisions of the Proposed Regulations

    This proposed rule describes requirements that health plans, 
covered health care providers, and health care clearinghouses would 
have to meet to comply with the statutory requirement to use a standard 
for electronic health care claims attachment transactions, and to 
facilitate the transmission of certain types of detailed clinical 
information to support an electronic health care claim.
    In the final Transactions Rule, new parts 160 and 162 were added to 
title 45 of the Code of Federal Regulations (65 FR 50365). The 
provisions in this proposed rule would be placed in a new subpart S of 
part 162 which would contain provisions specific to the electronic 
health care claims attachment standards. The provisions of this new 
subpart can be implemented consistently with the provisions of the 
HIPAA Privacy Rule and Security Rule, which are codified mainly at 
subparts A, C, and E of part 164 of title 45 of the Code of Federal 
Regulations.

A. Definitions

    [If you choose to comment on issues in this section, please include 
the caption ``DEFINITIONS'' at the beginning of your comments.]
    Section 1171 of the Act defines several terms. The definitions set 
out in section 1171 of the Act and regulations at 45 CFR part 160 and 
subpart A of part 162 would also apply to the electronic health care 
claims attachment standards. There are also several new terms and 
definitions proposed that are related to the standards proposed in this 
rule, (see proposed Sec. 162.103 and Sec. 162.1900). The new terms, 
their definitions and examples or explanations thereof are as follow:
    1. Ambulance Services means health care services provided by land, 
water, or air transport, and the procedures and supplies used during 
the trip by the transport personnel, to assess, treat or monitor the 
individual until arrival at the hospital, emergency department, home or 
other destination. Ambulance documentation may also include non-
clinical information such as the destination justification and ordering 
practitioner.
    2. Attachment Information means the supplemental health information

[[Page 55994]]

needed to support a specific health care claim. The health care claim 
attachment information is conveyed using both an X12 transaction and 
HL7 specification.
    3. Clinical Reports means reports, studies, or notes, including 
tests, procedures, and other clinical results, used to analyze and/or 
document an individual's medical condition. These include discharge 
summaries, operative notes, history, physicals, and diagnostic 
procedures (radiology reports, electrocardiogram (for example, EKG), 
cardiac echoes, gastrointestinal tests, pathology, etc.) Clinical 
reports do not include psychotherapy notes.
    4. Emergency department means a health care facility or department 
of a hospital that provides acute medical and surgical care and 
services on an ambulatory basis to individuals who require immediate 
care primarily in critical or life-threatening situations.
    5. Laboratory Results means the clinical information resulting from 
tests conducted by entities furnishing biological, microbiological, 
serological, chemical, immunohematological, hematological, biophysical, 
cytological, pathology, or other examinations of materials from the 
human body. Laboratory results are used for the diagnosis, prevention, 
or treatment of any disease or impairment of, or assessment of, the 
health of the individual. Laboratory results are generated from the 
services provided in a laboratory or other facility that conducts those 
tests and examinations.
    6. LOINC stands for Logical Observation Identifiers Names and Codes 
(LOINC[supreg]). It is a code set that provides a standard set of 
universal names and codes for identifying individual laboratory and 
clinical results as well as other clinical information. LOINC[supreg] 
codes are developed and maintained by the LOINC[supreg] committee and 
copyrighted 1995-2004, by Regenstrief Institute, Inc., and the Logical 
Observation Identifiers Names and Codes (LOINC[supreg]) Committee.
    7. Medications means those drugs and biologics that the individual 
is already taking, that are ordered for the individual during the 
course of treatment, or that are ordered for an individual after 
treatment has been furnished. Medications include drugs and biologics 
that are ordered by a licensed practitioner, or that are being taken by 
the individual, independent of a health care provider's orders (for 
example, over-the-counter drugs). In the AIS documents, these are 
referred to as ``current medications,'' ``medications administered,'' 
and ``discharge medications.'' Current medications are those the 
individual is taking before an encounter that generates a new claim; 
medications administered are those given to the individual by a health 
care provider during the encounter; and discharge medications are those 
that the health care provider orders for the individual to take and use 
after release or discharge from the encounter, including the 
medications the individual may already have at home or those he or she 
may need to obtain following treatment.
    8. Rehabilitation services means those therapy services provided 
for the primary purpose of assisting in an individual's rehabilitation 
program of evaluation and services. These services are: Cardiac 
rehabilitation, medical social services, occupational therapy, physical 
therapy, respiratory therapy, skilled nursing, speech therapy, 
psychiatric rehabilitation, and alcohol and substance abuse 
rehabilitation.

B. Effective Dates

    [If you choose to comment on issues in this section, please include 
the caption ``EFFECTIVE DATES'' at the beginning of your comments.]
    Covered entities must comply with the standards for electronic 
health care claims attachments 24 months from the effective date of the 
final rule unless they are small health plans. Small health plans will 
have 36 months from the effective date of the final rule to come into 
compliance.

C. Overview of Key Information for Electronic Health Care Claims 
Attachments

    For the remainder of this document, we will use the terms 
electronic claims attachments or electronic attachments to mean the 
same thing as electronic health care claims attachments. Similarly, the 
term Additional Information Specification may be referred to as an 
attachment specification or an AIS, and these terms are used 
interchangeably throughout the text. Since the term ``Implementation 
Guide'' is used by both HL7 and X12, we therefore use the full title 
for each document when they are referenced, such as the ``HL7 
Additional Information Specification Implementation Guide.''
    This rule proposes to establish standards for electronic health 
care claims attachments. The proposed rule is specific to electronic 
health care claims attachments rather than paper attachments (hard copy 
medical records), since the purpose of the HIPAA administrative 
simplification provisions is to facilitate the development of a 
national electronic health information system. Standard electronic 
health care claims attachments will allow for the electronic exchange 
of additional clinical and administrative information to augment the 
HIPAA standard claim transaction.
    The goal of having a more automated, standardized approach to the 
exchange of information in the health care industry is longstanding. In 
1994, the Workgroup for Electronic Data Interchange (WEDI) conducted a 
survey of the U.S. health care industry and documented its findings in 
a paper entitled: WEDI Attachments Workgroup Report, Initial Findings. 
Among other issues, this study examined the state of the health care 
industry as it related to the use of, and need for, electronic health 
care claims attachments standards. The survey identified hundreds of 
different paper-based attachments formats being used with health care 
claims. The attachments and their formats ranged from simple to complex 
and varied according to the type of information being requested, the 
services involved, and who was asking for the information. The WEDI 
report concluded with a set of recommendations, including the 
development of an electronic standard for exchanging this type of 
information between health care providers and health plans. Key among 
the recommendations were that: (a) Standardized data elements should be 
created for electronic claims attachments; (b) collaboration between 
affected entities should be encouraged; (c) standard ways to link data 
across transaction sets should be developed; and (d) a transaction set 
(pair of transactions) should be selected to send and respond to 
requests for additional information (similar to the health care claims 
status request and response transactions--the X12N 276/277 pair).
    CMS's work in the mid-1990s with WEDI, ASC X12, and HL7 resulted in 
the recommendation to use an HL7 version 2.4 message embedded within 
version 3040 of the ASC X12N 275 ``Additional Information to Support a 
Health Care Claim or Encounter Transaction,'' in other words, a 
response to a request for information. The embedded HL7 message would 
have contained structured and codified attachment data using the 
LOINC[supreg] coding system. For a variety of reasons, a proposed rule 
was never released with this recommendation. Since that time, HL7 moved 
ahead with development of its Clinical Document Architecture (CDA), 
which was a significant enhancement over the HL7 version 2.4 messaging. 
The CDA Release 1.0, August 2003, is an XML-based

[[Page 55995]]

document specification that enables the standardization of ``clinical 
documents'' for electronic exchanges of health information (see 
explanation of XML below). The CDA became the first ANSI-accredited 
XML-based standard in the health care industry.
    There is increasing evidence that many health care organizations, 
including health plans, health care providers, and health care 
clearinghouses, plan on implementing more XML-based EDI tools. Thus, 
building electronic health care claims attachments using XML technology 
is in concert with the direction of the industry. In light of these 
developments, we believe that the timing for this proposed rule is 
reasonable because its publication and the years allowed for 
implementation should leave ample time for the industry to further 
develop its skills with XML and EDI exchange methodology.
    The HL7 standard being proposed here would allow the same records 
and data to be ``read'' and used by either people or computers. In 
other words, regardless of how the data are sent within the proposed 
transaction, they can be processed either manually or through 
automation. Furthermore, as entities move toward computer-based methods 
for adjudication, the costs of copying, coding, transcribing, storing, 
and processing records should begin to decrease. Thus, this proposal 
has the potential for helping the industry attain desired efficiencies, 
expedite payments, reduce fraud and abuse, and improve the accuracy of 
medical information.
1. Overview of Extensible Markup Language (XML)
    Extensible Markup Language, or XML, is a relatively new technology. 
It allows documents to be formatted and exchanged across the Internet 
or through EDI.
    Hypertext Markup Language (HTML) is a widely used presentation 
language used to create documents for display on the Web. Using HTML 
markup with text, links, and graphics creates an HTML document that is 
attractive in appearance. HTML was created to describe how the content 
of a page should be displayed, but not the actual contents of the page. 
XML fills this gap because it provides an intelligence to electronic 
documents and preserves both the content (the actual information) and 
semantics for the document, and also formats it attractively, similar 
to HTML. In fact, XML and HTML are increasingly used together--XML 
stores and organizes the data, while HTML renders it inside the browser 
or application.
    XML was originally published by the World Wide Web Consortium 
(http://www.w3c.org) and designed as a standard markup language to 
speed up and simplify data exchange and database connectivity and to 
enhance the creation of complex documents. XML effectively structures 
files into logical elements of information by the use and placement of 
tags which describe the kind of information being sent. Information 
organized using XML, and bounded by tags, is known as a document 
whether it is in a file, or whether it is being transmitted over the 
Internet or in any other technical environment. The process of 
arranging information between tags is called document markup.
    Over the past few years, XML has been adopted by most major 
companies in information technology as the basis for attaining 
interoperability among their own products. One of the special features 
of the XML family is the standard language for describing the 
transformation or conversion of an XML document into another format. 
Extensible Stylesheet Language, or XSL, is the language that contains 
the presentation format instructions for the document, similar to HTML. 
It allows the display of information in different media, such as a 
computer screen or a paper copy, and it enables the user to view the 
document according to his or her preferences and abilities, just by 
changing the stylesheet. XSL Version 1.0 is important because it can 
convert an XML document into Extensible HTML, which can be understood 
by current Web browsers and many common applications. In fact, each HL7 
AIS for the electronic claims attachment standards will include a fully 
functional XSL stylesheet for use by covered entities. If covered 
entities choose not to use the HL7 supplied stylesheet, they will be 
able to create their own without significant problems, assuming the 
expertise exists on staff or is available through a vendor.
2. Overview of Clinical Document Architecture
    The HL7 Clinical Document Architecture (CDA)--Release 1.0 was 
approved by HL7 in November 2000. It is a document markup standard 
encoded in XML that specifies the structure (format) and semantics 
(content) of ``clinical documents'' for the purpose of information 
exchange. These XML-coded documents have the same characteristics and 
information as hard copy clinical documents, and therefore can be 
processed by both people and machines. The clinical documents encoded 
in XML include a hierarchical set of document specifications (the 
architecture) and are rendered in human readable form using XSL. This 
makes them usable in either electronic or printed format. The XSL 
essentially translates the XML into a format that looks like a 
``regular'' plain text document.
    We are aware that HL7 continues to improve its standards, including 
the CDA. In fact, CDA Release 2.0 was first balloted in August 2003 and 
re-balloted in 2004. While Release 2.0 may be approved between the time 
of this proposed rule and the final rule, this proposed regulatory text 
does not suggest its adoption at this time. However, if Release 2.0 is 
approved by HL7 between the time of this proposed rule and the final 
rule, we may propose its adoption for future AIS, based on the impact 
of CDA Release 2.0 on the existing AIS. As part of CDA Release 2.0, HL7 
is developing an XSL stylesheet that would permit interoperability 
between Release 1.0 and Release 2.0. However, as this too is 
incomplete, it is premature to consider its use or viability at this 
time. We invite comment on the pros and cons of each CDA release, the 
issues related to the use of a stylesheet to permit use of either CDA 
release, and the costs and timing associated with implementing one 
release version over the other.
3. How XML Is Applied Within the Clinical Document Architecture
    As with any XML-based standard, the CDA defines tag names and how 
they nest to structure information. Some of the important tag names are 
shown in the table below. The indentation in the left column of the 
table shows the manner in which certain elements nest within other 
elements.

[[Page 55996]]



         Demonstration of How XML Is Used Within a CDA Document
------------------------------------------------------------------------
           Tag name                             Purpose
------------------------------------------------------------------------
<level one>..................  Outermost tag, contains an entire CDA
                                document.
<clinical--document--header>.  Contains information about the document
                                arranged in subsections.
<Document--typ--ed>..........  Contains a code that identifies the
                                document type (for example, a discharge
                                summary or cardiac rehabilitation plan).
<Patient>....................  Contains the name and identification
                                number of the patient (individual).
<Body>.......................  Contains the body of the report expressed
                                in natural language with optional
                                structured information.
<Section>....................  A subdivision of the body containing a
                                logical unit of information (for
                                example, the discharge medications).
<Caption>....................  A subdivision of sections and other
                                elements that describes the contents
                                that will follow.
<caption--cd>................  A subdivision of a caption that
                                identifies the contents that follow
                                using a LOINC[supreg] code.
------------------------------------------------------------------------
Source: HL7 white paper August 26, 2003. Specific to Release 1.0 of the
  CDA.

    An important feature of the CDA is that it allows the entire body 
of the XML document to be replaced by an actual image. The image might 
be a scanned copy of a page or pages from the medical record. The 
header is still present to support computer management of the document, 
but the clinical content can be conveyed entirely by an image or text 
document. This option is important to those health care providers that 
do not have a computer-based patient record system and cannot yet 
create electronic claims attachments in a structured format, but wish 
to reap some benefits from standardization and a certain level of 
automation.
4. Transactions for Transmitting Electronic Attachments
    As we describe in a later section entitled ``Candidates 
Considered,'' the standard setting organizations attempted to evaluate 
existing transactions for their potential to be used to send and 
receive attachment information electronically. Two transactions were 
ultimately selected because they only required modifications in a later 
version. In other words, while the existing X12N version 4010 standards 
did not satisfy the data content needs of the electronic health care 
claims attachments, revisions in version 4050 were made to accommodate 
these needs in time for this proposed rule. Thus, version 4050 of the 
X12N 277 ``request'' and version 4050 of the X12N 275 ``response'' are 
proposed to carry the attachment related questions and the related 
answers or responses. The X12N 277 version 4050 transaction transmits 
information about the particular claim in question and the question 
codes. The X12N 275 version 4050 transaction returns the claim 
identification (ID) information, and, in the Binary Data (BIN) segment, 
literally transports the responses to each question, with the response 
codes, narrative text, or actual imaged documents. The X12N 
transactions are flexible enough to accommodate the two format variants 
described in the next section, meaning the transaction can be used for 
either manual processing or computer automated processing.
5. Electronic Claims Attachment Types
    [If you choose to comment on issues in this section, please include 
the caption ``ELECTRONIC CLAIMS ATTACHMENT TYPES'' at the beginning of 
your comments.]
    While it might be considered ideal by some to have electronic 
attachments for all health care claims business needs, it would be 
virtually impossible to identify and create standard specifications 
with appropriate codes for the full array of different attachment types 
required today. Furthermore, given changes in industry business 
practices, and new adjudication rules over the past decade, it is more 
important to determine, from health care providers and health plans, 
which claims most commonly require additional information for 
adjudication today, and what types of electronic attachments might be 
required in the next 5 to 10 years. It is equally important for covered 
entities to gain experience with a manageable number of electronic 
attachment types at the outset, so that technical and business issues 
can be identified to improve the process with each new electronic 
attachment specification that is developed.
    While the attachment information needed to support the full range 
of health care claims may be diverse, the same general transaction 
structure and administrative information can be applied to all 
electronic claims attachments to allow for some level of consistency. 
This proposal to encourage some form of electronic transmission, even 
of a scanned document in the early stages of implementation, at least 
represents a methodical approach towards moving the industry from paper 
to electronic communication for health care claims attachments. The 
advantage of the more general X12N transaction standards that can serve 
as the vehicles to carry any type of electronic attachment information, 
is that they can be coupled with the specific attachment 
``documents''--coded or scanned--and remain available to handle new 
content-specific electronic attachment types as they are developed and 
approved.
    Based on industry feedback following implementation of the 
Transactions Rule, it became clear that pilot programs and early 
testing of new standards and processes were vital to the standards 
adoption process. In July 2004, HHS awarded funds for a Medicare pilot 
program to test the X12 request and response transactions, the 
LOINC[supreg] codes and at least two of the attachment types, using the 
HL7 Additional Information Specifications. The pilot is expected to 
demonstrate the capability of sending the X12 request transaction from 
a health plan to a health care provider, and then for the health care 
provider to send the X12 response, complete with the HL7 CDA in the BIN 
segment, back to the health plan. The health care provider will send 
both variants of each attachment type--a human variant (scanned 
document) and a computer variant (a coded response). These variants are 
described later in this preamble. We believe this pilot program will 
provide valuable insight as to the implementation challenges of 
electronic attachments, and perhaps even as to when health care 
providers and health plans could begin to move towards more structured, 
coded communication and adjudication. The SDOs are involved in the 
pilot as subject matter experts, so that as technical or operational 
challenges are identified with the standards, a core group of 
professionals with expertise can address them, and take corrective 
action on the X12 Implementation Guides, HL7 AIS or

[[Page 55997]]

LOINC[supreg] code set before the final rule is issued.
    In this proposed rule, we propose six specific electronic 
attachment types, each with data content requirements related to 
treatment or services provided. These six attachments are: (1) 
Ambulance services, (2) emergency department, (3) rehabilitation 
services, (4) clinical reports, (5) laboratory results, and (6) 
medications. These six specific attachments were originally selected 
for development because there was industry consensus on their relevance 
to a significant percentage of covered entities and to those claims 
that typically require additional documentation. They also contain the 
types of information commonly found in attachments, for example, 
narrative text (such as nurses' notes), simple data points (such as the 
results of a single laboratory test), and more complex information 
(such as rehabilitation progress over time). In 2003, the HL7 ASIG work 
group began working on other electronic claim attachment specifications 
that were identified by the industry as being significant, including 
home health, periodontal care, and durable medical equipment (DME).
    Comments are invited as to whether the six proposed attachment 
types are still the most frequently requested by health plans, and if 
there are others that are equally or more pressing for the industry.
    In the future, any new electronic attachment types, or changes to 
the six attachments standards proposed here, would require the 
Department to follow the usual rulemaking process. If changes are 
requested of the six proposed attachments standards, as a result of 
public comments during the period between the proposed and final rule, 
it is highly likely that HL7 would be able to make and ballot such 
changes in time for their adoption in the final rule. New electronic 
attachment standards approved by the SDO but not adopted by the 
Department may be used on a voluntary basis between trading partners, 
but there is no regulatory authority over their use.
    The effect of adopting a limited number of attachments standards at 
first is to permit covered entities time to gain experience with new 
standards and to evaluate the technical and business impacts of such 
transactions. In the meantime, while the electronic attachment 
specifications for DME, periodontal care, and home health are still 
under development, covered entities are strongly encouraged to actively 
participate in the development, review and modification process, and to 
advance their own proposals for these and other electronic attachments.
    Any new electronic attachment specifications, such as the ones 
referenced above, will be developed in accordance with the framework of 
the HL7 CDA Release 1.0. If CDA Release 2.0 is approved, the HL7 ASIG 
will determine if the next set of AISs will use CDA Release 2.0, or 
continue to be built on Release 1.0. HL7 will advise HHS as to the 
industry impact if the later version of CDA is adopted, particularly 
since covered entities need to be able to use both versions without 
requiring additional system changes. Industry representatives 
interested in participating in the development process should work in 
collaboration with HL7.
    In fact, as these and other new electronic attachments are 
developed, we strongly encourage the health care provider and health 
plan segments of the industry to review them and then provide 
substantial input on the ``questions'' or LOINC[supreg] codes, and on 
the cardinality (priority values) of the data elements--in other words, 
which elements should be required and which should be situational or 
optional for each electronic attachment type. Health care providers and 
health plans will recall their implementation experiences with the 
Transactions Rule and have an appreciation of the extreme importance of 
evaluating and understanding both the technical and business 
requirements of the standards and guides, and of submitting their 
issues and recommendations to the SDOs, DSMOs, and the regulators. We 
also solicit industry input on the impact to servers and other data 
storage systems for processing and storing electronic files of clinical 
information, both coded and text or image based.
6. Format Options (Human vs. Computer Variants) for Electronic Claims 
Attachments
    [If you choose to comment on issues in this section, please include 
the caption ``FORMAT OPTIONS'' at the beginning of your comments.]
    The Department and the standard setting organizations are sensitive 
to the fact that many health care providers, particularly smaller 
practices that are not yet fully automated, may be looking for means to 
convert from paper to electronic records in a cost effective, staged 
manner. To encourage such a transition, the standard setting 
organizations have proposed an approach to electronic health care 
claims attachments that could provide the benefits of electronic 
transmission of the information for both the health care provider and 
the health plan but that would not require a large upfront investment 
in electronic medical records systems, or the immediate merging of 
financial/administrative and clinical systems. Under this proposal, the 
electronic health care claims attachments may be sent in one of three 
formats, shown in the table below. Two of the formats are in the 
category of Human Decision Variant, and the third format is a Computer 
Decision Variant. There is a lengthy discussion of these variants along 
with examples later in this preamble, based on a white paper written by 
members of HL7's Attachments Special Interest Group.
    Human Decision Variants: (1) Many health care providers may choose 
to send scanned or imaged documents in the X12 transaction, and health 
plans will use manual procedures to process them; a health plan 
employee will physically look at the contents of the attachment to 
adjudicate the claim. Simply put, the health care provider would send a 
virtual document inside the X12 transaction and the health plan would 
view it on the computer screen, or a printed hard copy. This process is 
one of the human decision-making variants because it allows for the 
transmission of scanned page images. After the image has been rendered 
(printed or viewed as a document), the information should be clear 
enough and contain sufficient data for a person--the health plan's 
employee--to make a decision about the claim. (2) The second type of 
human decision variant is even simpler: The health care provider 
responds to the electronic request using narrative text, such as a 
typed response to the question, again embedding this response into the 
BIN segment of the X12 transaction. The health plan employee reads the 
answer off the screen, or prints a hard copy for review.
    Computer Decision Variant: The computer decision variant contains 
additional information that is structured so that it can be 
electronically extracted for use in computer-based adjudication 
systems, using automated processing rules. The codes will literally be 
read and interpreted by the computer. Auto-adjudication is the use of 
computers, programmed with business rules and logic, to process a 
claim, making decisions as to whether to pay, how much to pay, and to 
whom to make the payment. It is a long-term goal for most health plans 
to be able to support auto-adjudication for as many claims as possible.
    Even with this variant, HL7 will supply ``stylesheets'' that will 
put any data into an HTML or screen readable format. This means that 
health plans

[[Page 55998]]

that do not intend to auto-adjudicate in the short term, may continue 
to use low-cost technology to print or display the electronic 
attachment information, regardless of which option or variant the 
health care provider uses.
    The human and computer variants do not differ in actual content. 
Both types of variants (human and computer) for each electronic 
attachment type have required and optional content elements, which are 
listed in the specification for that attachment. Both types of variants 
will satisfy the standard, as they will differ only with regard to 
whether or not structured and coded data are required. That is, in the 
computer variant, coded data are required, whereas in the human 
variants, coded data are not required. While both variant types will 
carry a LOINC[supreg] code or codes, they will be accompanied by the 
natural text translation (narrative text) in the same transaction, so 
the request will be understandable in either the human or the computer 
variant.

    Table 1.--Human vs. Computer Variants for Electronic Attachments
------------------------------------------------------------------------
                                   Information       Information sent as
           Variant               representation             * * *
------------------------------------------------------------------------
Human Decision..............  Scanned image.......  Scanned image of
                                                     pages from the
                                                     medical record.
                                                     Repeats
                                                     LOINC[supreg] code
                                                     from the request.
Human Decision..............  Natural language      Natural language
                               text.                 text with captions
                                                     that match the
                                                     specified
                                                     questions. Repeats
                                                     LOINC[supreg] code
                                                     from the request.
Computer Decision...........  Natural language      Natural language
                               text and structured   text, captions
                               information.          identified by
                                                     LOINC[supreg] codes
                                                     and supplemented by
                                                     coded information.
------------------------------------------------------------------------
Source: Gartner Research 2003.

7. Combined Use of Two Different Standards Through Standard Development 
Organization (SDO) Collaboration
    [If you choose to comment on issues in this section, please include 
the caption ``COMBINED USE OF DIFFERENT STANDARDS'' at the beginning of 
your comments.]
    As discussed in the previous section, claims attachment 
transactions contain both administrative and clinical information. 
Thus, attachment data could come from a health care provider's clinical 
record system, whether paper or electronic, as well as from its 
practice management or billing system. Historically, these two distinct 
areas (clinical vs. administrative) have been the domain of two 
different SDOs: HL7 focuses on clinical data standards, while X12 
concentrates on administrative data and transactions. In 1997, a joint 
effort between HL7 and X12 produced several options that would 
facilitate the communication of both clinical and administrative data, 
as well as smooth the transition from paper to a standardized 
electronic process for health care claims attachment information.
    ASC X12N, through its Patient Information Standards Work Group 
(WG9), developed transactions and the accompanying X12 implementation 
guides to fulfill the administrative needs of an electronic attachment 
request and the response to that request. HL7, through its ASIG, 
developed the message structure and the additional information 
specifications employing LOINC[supreg] codes that were relevant to the 
major types of clinical data needed in claims attachments. The ASIG 
included HL7 representatives, members of X12's WG9, and several vendors 
and health care providers with HL7 experience. The purpose of proposing 
the combined use of both ASC X12N and HL7 standards is to address both 
the administrative and clinical aspects of the attachment transactions 
from a format and content perspective. However, because these two 
standards have not been used together before, we solicit industry 
feedback regarding this strategy.
    One of the benefits of standardizing health care claims attachments 
is that it allows health care providers to anticipate requirements from 
health plans regarding additional documentation for claims 
adjudication. This should present opportunities for providers to 
develop procedures and systems to collect the data specified in the X12 
Implementation Guides and HL7 Additional Information Specifications. 
Health care providers would also be given considerable latitude on how 
to submit the information--with either narrative text, scanned 
documents or with fully coded data, permitting the use of some form of 
electronic attachments for health care providers that do not have 
computer-based medical record systems.
    From the health plan perspective, the requirements for use of the 
two standards can be met with a low impact implementation for claims 
adjudication, based on a person looking at the content of the 
electronic attachment in a text/readable format, regardless of how it 
is submitted. While the proposed process supports auto-adjudication, it 
does not require it for compliance.

D. Electronic Health Care Claims Attachment Business Use

    A health care claims attachment conveys supplemental information 
pertaining to the services provided to a specific individual to support 
evaluation of a claim before it is paid. An attachment might contain 
biometric data; medical history; clinical data (reports, studies, 
notes); hospital discharge notes; laboratory results; medication 
information; rehabilitation plans; optical prescriptions; 
certifications made by the individual and/or the health care provider 
regarding sterilization, hysterectomy, or other services, as required 
by Federal or State rules; or other clarifying information for a 
particular service.
    Attachments may be requested or submitted when the supplemental 
medical information is directly related to the determination of 
benefits under the subscriber's contract, or when directly related to 
providing medical justification for health care services provided to 
the individual when that medical justification can affect the 
adjudication of payment for services billed by the provider of health 
care services. Although additional clinical or administrative 
information may be required following adjudication of claims, such as 
for post-adjudication review to support quality control, fraud and 
abuse, or other post-adjudication reviews and reporting requirements, 
we do not consider these post-adjudication requests for claims-related 
data to be part of the claims payment process. Therefore, post-
adjudication processes are not covered by this proposal. While covered 
entities may voluntarily choose

[[Page 55999]]

to use the standard transaction format and structure for requesting and 
submitting these types of attachments, those transactions are not 
considered electronic claims attachments as defined in this proposed 
rule.
1. Electronic Health Care Claims Attachment vs. Health Care Claims Data
    Electronic health care claims attachments must not be used to 
convey information that is already required on every claim. Information 
needed for every claim is ``claims data'' that must be conveyed in the 
appropriate standard claim transaction. The purpose of a claims 
attachment is to convey supplemental information that is directly 
related to one or more of the services billed on the claim submitted by 
the health care provider when further explanation of those services is 
required before payment can be made by the health plan. There are even 
some current business practices that include 100 percent pre-payment 
medical review. This is when a health plan requires a specific health 
care provider to include certain supplemental information with all 
claims for a certain type of service.
    Over the past few years, health plan rules and policies regarding 
the additional data necessary to adjudicate a claim have evolved, and 
in fact, many health plans have begun to limit or reduce their requests 
for claims attachments. Therefore, it is critical that members of the 
health plan industry and the health care provider community actively 
engage themselves in the final development of this proposed rule so 
that the proposed attachments are indeed those which will yield 
significant benefits to health care providers and health plans alike.
2. Solicited vs. Unsolicited Electronic Health Care Claims Attachments
    [If you choose to comment on issues in this section, please include 
the caption ``SOLICITED vs. UNSOLICITED ATTACHMENTS'' at the beginning 
of your comments.]
    In general, health care providers will submit their electronic 
health care claims attachment information to the health plan for 
certain claim types, upon request, after the health plan has received 
and reviewed the claim. This follows the course of claims adjudication 
today. Health plans may also request, in advance, that additional 
documentation (the attachment) accompany a certain type of claim for a 
specific health care provider, procedure, or service. The ASIG refers 
to this scenario, of sending attachment information with the initial 
claim, as an unsolicited attachment because a request was not made 
after the fact, using the standard request transaction. We are 
proposing that health care providers may submit an unsolicited 
electronic attachment with a claim only when a health plan has given 
them specific advance instructions pertaining to that type of claim or 
service.
    We are proposing such a restriction around ``unsolicited'' 
electronic attachments, because we believe that there are legal, 
business, and technical implications for health care providers, health 
plans, and their business associates for handling and processing 
unsolicited attachments without prior direction. If health care 
providers were permitted to submit unsolicited electronic attachments 
with any claim without prior arrangement with the health plan, there 
would be a number of issues, including compliance with the Privacy 
Rule's minimum necessary standards, and identifying the new business 
and technical procedures health plans would need to develop to review, 
evaluate, store, return, or destroy the unsolicited documents. 
Similarly, health care providers would need systems and processes to 
track submissions and returns.
    We also propose that for each specific claim, health plans may 
solicit only one electronic attachment request transaction which would 
have to include all of their required or desired ``questions'' and/or 
documentation needs relevant to that specific claim. Health care 
providers would be required to respond completely to the request, using 
one response transaction. The intent of these proposed requirements is 
to avoid inefficient, redundant processes. A health plan would not be 
able to extend adjudication through a lengthy process of multiple 
individual attachment requests for the same claim: submitting one 
LOINC[supreg] request code at a time, receiving the health care 
provider's response, and then submitting another transaction with 
another LOINC[supreg] code for additional information related to the 
same claim. Nor would a health care provider be able to send bits and 
pieces of the requested information at different times or dates. We 
propose this because it seems contrary to the goals of administrative 
simplification for covered entities to engage in a continuous loop of 
query and response in order to have a claim processed.
    We solicit feedback from the industry on this issue.
3. Coordination of Benefits
    There is considerable variation in how health care providers and 
health plans handle Coordination of Benefits (COB) and the 
communication of related claims information. However, with respect to 
electronic attachment requests and responses in a COB scenario, we 
assume that the primary health plan will request only the attachments 
it needs to adjudicate its portion of the claim. The secondary health 
plan would request its own attachments in a separate (X12N 277) 
transaction sent directly to the health care provider. In health plan-
to-health plan (also known as payer-to-payer) COB transactions, the 
primary health plan may not know the secondary health plan's business 
rules, and therefore would not be expected or required to request an 
attachment on behalf of the secondary health plan.
4. Impact of Privacy Rule
    Before implementation of the Privacy Rule in 2003, health care 
providers often sent the individual's entire medical record to the 
health plan for the purpose of justifying a claim. Health plans and 
health care providers indicated that this practice reduced instances 
for which follow-up requests for more information were needed, since 
all possible information was supplied at once. That practice was often 
wasteful and time consuming, and it is now generally inconsistent with 
the ``minimum necessary'' standards contained in the HIPAA Privacy Rule 
at 45 CFR 164.502(b) and 45 CFR 164.514(d). These standards require 
covered entities to make reasonable efforts to limit requests for, or 
disclosures of, protected health information to the minimum necessary 
to accomplish the intended purpose of the request or disclosure. In 
situations where the minimum necessary standard applies, such as when a 
covered health care provider discloses protected health information to 
a health plan for payment, the standards prohibit disclosure of the 
entire medical record unless the entire medical record is specifically 
justified as the amount that is reasonably necessary to accomplish the 
purpose of the disclosure (45 CFR 164.514(d)(5).
    The Privacy Rule exempts from the minimum necessary standard any 
use or disclosure that is required for compliance with the Transactions 
Rule (45 CFR 164.502(b)(2)); thus, the minimum necessary standard does 
not apply to any required or situationally required data elements in a 
standard transaction. For example, if an identifier code were required 
on all electronic attachment request transactions to create a 
connection between the electronic attachment request

[[Page 56000]]

transaction and the associated health care claim, then health plans 
would not need to apply the minimum necessary standard to that data 
element to determine whether they could request that information. 
However, the minimum necessary standard would apply to data elements 
for which health plans or health care providers may exercise discretion 
as to whether the information should be provided or requested in the 
transaction. For example, health plans must apply the minimum necessary 
standard when selecting the attachment information to be requested in a 
particular electronic attachment request transaction.
    A health care provider may rely, if such reliance is reasonable 
under the circumstances, on a health plan's request for information, or 
specific instructions for unsolicited attachments, as the minimum 
necessary for the intended disclosure. Such reliance is not required, 
however, and the covered health care provider always retains the 
discretion to make its own minimum necessary determination.
    For health care providers who choose to submit attachment 
information in the form of scanned documents, efforts will need to be 
made to ensure that those documents do not contain more than the 
minimum necessary information.
    We solicit comments on the extent to which the use of the proposed 
electronic attachment standards will facilitate the application of the 
``minimum necessary'' standard by covered entities when conducting 
electronic health care claims attachment transactions.
5. Impact of the Security Rule
    All covered entities need to comply with the Security Rule no later 
than April 20, 2005, except for small health plans, which must comply 
no later than April 20, 2006. The Security Rule applies to all covered 
entities, and, therefore, will apply to the transmission of electronic 
health care claims attachments. There are four overarching security 
requirements with which covered entities must comply: (1) Ensure the 
confidentiality, integrity, and availability of all Electronic 
Protected Health Information (EPHI) that the covered entity creates, 
receives, maintains, or transmits; (2) protect against any reasonably 
anticipated threats or hazards to the security or integrity of EPHI; 
(3) protect against any reasonably anticipated uses or disclosures of 
EPHI that are not permitted under the Privacy Rule; and (4) ensure 
compliance with the security regulations by members of the workforce. 
The types of security measures required by the Security Rule fall 
generally into three categories: administrative, physical, and 
technical safeguards. The Security Rule also has standards for 
documentation and organization requirements. Since the requirements are 
intended to be scalable, each covered entity must take into account its 
size, complexity, capabilities, technical infrastructure, and hardware 
and software security capabilities; the cost of security measures; and 
the probability and criticality of potential risks to EPHI.
    The systems used to transmit electronic claims attachments will 
likely be the same systems used for other electronic transactions. 
Therefore, any efforts to comply with the Security Rule should be 
effectively incorporated into electronic attachment processing.
    Most covered entities (with the possible exception of small health 
plans) will be in compliance with the Security Rule by the time of this 
proposed rule; and all health plans will have fully implemented their 
security programs by the time the final rule is published for 
electronic health care claims attachments.
6. Connection to Signatures (Hard Copy and Electronic)
    This regulation does not propose requirements for Electronic 
Signatures (e-signatures) because a consensus standard does not 
presently exist that we could propose to adopt, nor does any Federal 
standard currently govern the use of electronic signatures for private 
sector health care services. Federal agencies that are also covered 
entities have to comply with the Office of Management and Budget (OMB) 
guidance on e-signatures in the context of the Government Paperwork 
Elimination Act (OMB notice 5/2000, 65 FR 25508) and the Federal 
Information Security Management Act (Title III of the E-Government Act 
of 2002). And, while the OMB has responsibility for coordinating and 
implementing the adoption and use of electronic signature technologies 
for Federal agencies, this effort is not related to HIPAA transactions 
per se, and we do not have authority to require the private sector to 
comply with rules that are only applicable to Federal agencies. At the 
time of this proposed rule, other agencies and Federal initiatives 
involved in the evaluation and development of standards for electronic 
signatures include the Department of Defense (DOD), the National 
Institute for Standards and Technology (NIST), and the Federal 
Consolidated Health Informatics Initiative (CHI).
    We are aware that virtually all health plans, including the 
Medicare and Medicaid programs, require signatures certifying certain 
types of services, such as sterilization, certain rehabilitation plans, 
and authorization for certain types of equipment. For example, health 
plans may request a paper copy of the signature page of a 
rehabilitation plan, or they may accept the response code indicating 
that the signature is on file. The CDA Release 1.0 requires the 
acquisition of the signature to be documented via the <signature--cd> 
component, so there is an accommodation for signature within the 
standard, but not a requirement for an electronic signature specific to 
HIPAA.
    We solicit input from the industry on how signatures should be 
handled when an attachment is requested and submitted electronically.
7. Connection to Consolidated Health Informatics Initiative
    Several agencies within the Federal government that deal with the 
delivery of health services, including the Departments of Health and 
Human Services, Veterans Affairs, and Defense, have adopted a portfolio 
of health information interoperability standards that will enable all 
agencies in the Federal health enterprise to ``speak the same 
language'' based on common, enterprise-wide business and technology 
architecture. This program is known as he Consolidated Health 
Informatics (CHI) initiative. In 2003, CHI targeted 24 ``domains'' for 
data and messaging, from laboratory results to vocabulary for nursing, 
to medications. The CHI initiative looked to the private sector to 
identify particular electronic health clinical data standards for 
adoption, researched these standards, and is now beginning to build the 
plan to implement them within Federal agencies as program requirements 
dictate. On May 6, 2004, the Secretaries adopted standards for 20 
domains and subdomains; among others, these included: HL7 messaging 
standards for clinical data, NCPDP standards for ordering from retail 
pharmacies, IEEE1073 to allow health care providers to monitor medical 
devices, DICOM to enable images of diagnostic information to be 
retrieved and transferred between devices and workstations, 
LOINC[supreg] for the exchange of clinical laboratory results, SNOMED 
CT[supreg] for certain interventions, diagnosis and nursing 
terminology, and a variety of terminologies for medications. We include 
a reference to CHI here to clarify that while the Federal government is 
reviewing and adopting standards for its intra-agency communications, 
these are

[[Page 56001]]

not inconsistent with the private sector, with whom significant 
transactions are exchanged, and that furthermore, the work and outcome 
of CHI related activities do not conflict with HIPAA. Indeed, CHI has 
adopted HIPAA standards as the standards for the exchange of 
administrative information. The complete list of adopted standards and 
other details about CHI may be found at http://www.egov.gov or http://www.whitehouse.gov/omb/egov/gtob/health_informatics.htm.
8. Health Care Provider vs. Health Plan Perspective
    [If you choose to comment on issues in this section, please include 
the caption ``PROVIDER VS PLAN PERSPECTIVE'' at the beginning of your 
comments.]
    Health care providers and health plans regard claims attachments 
quite differently. Health care providers would prefer to keep 
attachments to a minimum and regard requests for additional claims-
related information as unnecessarily lengthening the payment cycle. 
Health plans consider the use of attachments as a necessary tool to 
ensure appropriate payment decisions, maintain quality assurance, and 
minimize fraud and abuse. What a health care provider may regard as an 
unnecessary and/or onerous request for information may be viewed by the 
requesting health plan as critical to ensure that payment is being made 
according to the provisions of the patient's policy and benefits, for 
which the health plan pays. This rule does not propose to set out 
requirements for the appropriateness of requests for additional 
information. However, the proposed attachment standards are designed to 
reduce miscommunication and multiple requests for information by 
providing specificity to both the request for information and the 
response, and by establishing specific limits to the content of the 
attachment.
    Health Care Provider vs. Health Plan Implementation: In accordance 
with 1175(a) of the Act and 45 CFR part 162, Sec. 162.923 and 
Sec. 162.925, health plans may not reject any electronic transaction 
simply because it is being conducted as a standard transaction. This 
applies to the proposed transactions for electronic health care claims 
attachment requests and responses. So, for example, a health care 
provider may direct a health plan to send any request for additional 
documentation to it or its business associate in standard form, for 
those attachment types for which a standard has been adopted here, and 
the health plan must do so. The health care provider may also request 
that the health plan accept the attachment information in the standard 
response transaction.
    However, as we have stated in the past, we do not believe that the 
use of a standard transaction can create a business relationship or 
liability that does not otherwise exist.
9. Health Care Clearinghouse Perspective
    Health care clearinghouses are covered entities under HIPAA, and 
must be able to accept and transmit a standard transaction when asked 
by a health care provider or health plan for whom they serve as a 
business associate for those functions. Since both health care 
providers and health plans have dependencies on the health care 
clearinghouses, it is imperative that the health care clearinghouse 
industry participates actively in the rulemaking process, standards 
review, and implementation assessment as well. It would be helpful if 
health care clearinghouses were among the first of all entity types to 
come into compliance with these standards so that testing between 
trading partners--health care providers and health plans--could be 
executed in a timely fashion.

E. Electronic Health Care Claims Attachment Content and Structure

    [If you choose to comment on issues in this section, please include 
the caption ``ATTACHMENT CONTENT AND STRUCTURE'' at the beginning of 
your comments.]
    As noted, there are two separate transactions associated with the 
electronic claims attachment. One transaction is a health plan's 
request for health care claims attachment information, and the other is 
the health care provider's response, which includes submission of the 
attachment information.
    Each of these transactions contains administrative information that 
identifies the individual, date of service, and other information that 
permits the health care provider to identify the appropriate individual 
and claim, and enables the health plan to associate the electronic 
attachment material with the proper claim. In addition, the attachment 
request must have an unambiguous way to specify the clinical or other 
information needed, and the attachment response must have an 
unambiguous way to label the information being provided and to convey 
responses in a consistent, predictable manner.
    Example: ABC Ambulance Company submits a claim for transporting M. 
Smith on a certain date. The health plan cannot adjudicate the claim 
without knowing M. Smith's weight. The health plan sends a request for 
the individual's weight to ABC Ambulance Company and includes the 
individual's name, date of service, type of service, the control number 
it is using to identify the claim, and other information that will 
allow ABC to locate the individual's record. This information, when 
returned along with the response, will also enable the health plan to 
associate this new piece of data with the correct claim. The ABC 
Company sends the requested information back to the health plan, it is 
associated with M. Smith's claim, and the claim continues through the 
adjudication process.
    In this example, the health plan wants the individual's weight as 
reported by the individual (rather than an estimate made by the 
attendants) expressed in pounds, not kilograms. The request will 
contain a code that reflects this exact request, and the response will 
return the code with the individual's weight, expressed in pounds.
    Thus, the standards we are proposing for any of the named 
electronic attachments types will specify:
    <bullet> The administrative information contained in the request 
and response;
    <bullet> The attachment information (also referred to as the 
additional information specification) contained in the response;
    <bullet> A code set for specifically describing the attachment 
information;
    <bullet> A code set modifier for adding specificity to the request; 
and
    <bullet> The format that will contain all of this information.
    The size of the file in the response transaction will be impacted 
by the option the health care provider chooses for the submission--
either text and imaged documents or coded data. With imaged documents, 
the size of the file within a single response transaction could become 
large. The implementation guide for the X12 275 response transaction 
permits up to 64 megabytes of data in a single transaction. Industry 
comment on file size is also welcome.
    In sum, the proposed standards are those that have been under 
development for over eight (8) years by the HL7 ASIG. Meanwhile, the 
health care industry itself has undergone significant change. It is, 
therefore, critical that appropriate industry representation reviews 
and then weighs in on these standards: The attachment content, and 
format, and the transaction's function. As discussed throughout this 
preamble, we are soliciting comments from all affected covered entity 
types (covered health care providers, health plans, health care 
clearinghouses and Medicare

[[Page 56002]]

prescription drug discount card sponsors) and their business associates 
(practice management vendors, software vendors, document storage 
contractors and others) about these proposed standards. In this 
paragraph, we reference Medicare prescription drug discount card 
sponsors as a covered entity. These organizations are considered 
covered entities until 2006, when the new Medicare prescription drug 
program becomes effective. Based on the timing of the electronic health 
care claims attachments final rule, the requirements of that final rule 
may or may not be relevant to such organizations.

F. Alternatives Considered: Candidate Standards for Transaction Types 
and Code Sets

    [If you choose to comment on issues in this section, please include 
the caption ``ALTERNATIVES CONSIDERED: CANDIDATE STANDARDS'' at the 
beginning of your comments.]
1. Transactions
    History: In the early years of the HIPAA standards adoption 
process, the ANSI Health Informatics Standards Board (HISB) prepared 
inventories of transaction standards and code sets for HHS so that 
staff could evaluate the available options. Several standards were 
selected as potentially viable for electronic health care claims 
attachments, but no final decision was made at that time, and the 
proposal was held for additional work. In a 2001 white paper, HISB 
again documented the potential transaction standards that could be used 
for electronic health care claims attachments. The list included the 
ANSI X12N 275 version 4010 (Additional Information in Support of the 
Health Care Claim or Encounter) as the vehicle to send the electronic 
attachment information to the health plan. However, that transaction 
and a number of other ones considered, were not suitable on their own 
for a general electronic health care claims attachment standard, as 
they (the transaction standards) were overly service specific. For 
example, the Institute of Electrical and Electronic Engineers (IEEE) 
had a standard (IEEE 1073) for communication among bedside devices. 
Digital Imaging and Communication in Medicine (DICOM) created a 
standard for the format and transfer of biomedical images and image-
related information. The American Society for Testing and Materials 
(ASTM) had created a framework vocabulary for the patient-based record 
content. While each of these standards had its place in the industry, 
none was appropriate as a transaction standard capable of handling a 
host of different types of electronic health care claims attachments.
a. Health Care Claims Attachment Request Transaction
    The HISB did not suggest any candidate transactions for use as a 
request for additional health care claim information. A review of SDO 
transaction inventories and a review of relevant literature by the WG9 
identified only one transaction that could be modified for use as an 
electronic claims attachment request transaction: the X12N 277 version 
4010 Claim Status Response transaction could satisfy this business need 
if the implementation specifications were modified. The X12N 277 
transaction adopted under HIPAA for claims status inquiries was 
originally created by ASC X12N to provide the capability to 
electronically transmit information about the (payment) status of a 
health care claim (the 277 serves as a response transaction to the 276 
inquiry). In order to accommodate the more extensive business 
requirements of an electronic health care claim attachment request, a 
new version of the implementation specification of the X12N 277-Health 
Care Claim Status Notification would have been required. Thus, X12 and 
HL7 determined that it was more expedient and practical to create a new 
transaction standard designed for the specific purpose of requesting an 
attachment rather than trying to modify one designed as a response 
transaction.
b. Health Care Claims Attachment Response Transaction
    The HISB assessment originally suggested one standard as a 
candidate for the response to a request for health care claims 
attachment information. The X12N 275-Patient Information transaction 
had the closest match in capability and business potential for 
conveying health care claims attachment information, though it had not 
been adopted as a HIPAA standard for any other purpose. The X12N 275 
transaction was designed to provide individual information to be shared 
among trading partners. When coupled with HL7 message structures, the 
X12N 275 appeared to represent the best electronic solution for this 
purpose because of its two key advantages over other ASC X12N 
transactions: (1) The capability to transmit other standard messages 
within the transaction; and (2) the ability to transmit large amounts 
of information within the BIN segment of the transaction, which can 
contain up to 64 megabytes of data. However, after extensive 
evaluation, WG9 determined that the existing version of the X12N 275 
transaction would have to be modified, with significant structural 
changes to accommodate the business needs for standardized electronic 
health care claim attachments. WG9 also determined that most of the 
supplemental information requested by health plans was clinical 
information, usually detailed with specific quantitative measurements, 
laboratory results, and specific medical reports. Clinical information 
of this nature was already accommodated by HL7 messages, but not by 
anything in the X12 repertoire. The X12N 275 transaction, when coupled 
with HL7 message structures, appeared to represent the best electronic 
solution for this purpose. In 1997, ASC X12N representatives agreed to 
incorporate the use of HL7 standard messages in the BIN segment of the 
ASC X12N 275. Over the past two years, ASC X12N developed a new 
implementation guide for this use, complemented by the HL7 
specifications.
2. Code Sets
    History: There was virtually no depth in the pool of available code 
sets for consideration to request or send information--at least not one 
individual code set with everything that might be needed for electronic 
health care claims attachments. Thus, the original candidate for the 
code set to be used with attachments was the X12N version of health 
care claims status reason codes, tied to the X12N 837 claims 
transaction and the claims status inquiry and response (X12N 276/277). 
As this option was being evaluated, HISB also reviewed another code set 
that could potentially serve to identify the additional information 
needed to process the claim--this was the LOINC[supreg] code set.
    Under HIPAA, the Secretary may adopt code sets developed by either 
private or public entities, including proprietary code sets. The Act 
also allows the Secretary to adopt standards other than those 
established by an SDO if the different standards will reduce costs for 
health care providers and health plans, and other applicable statutory 
requirements are met. Both of the code set candidates evaluated for 
inclusion were proprietary code sets that had established mechanisms 
for maintenance related updates, were available without payment of 
licensing or use fees, and were already in use by the medical 
community.
    Washington Publishing Company is the exclusive publisher and 
copyright

[[Page 56003]]

holder of the X12N health care claim status reason codes. The 
Regenstrief Institute, Inc. and the LOINC[supreg] Committee are the 
copyright holders of the LOINC[supreg] code set and database.
    LOINC[supreg] provides sets of universal names and identification 
codes for identifying laboratory and clinical test results as well as 
other units of information that are meaningful in electronic claims 
attachments. The LOINC[supreg] code for a name is unique and permanent 
and has no intrinsic structure except that the last character in the 
code is a check digit and must always be transmitted with a hyphen 
before the check digit (for example, ``10154-3''). The LOINC[supreg] 
codes offer a comprehensive array of coded topics designed to support 
detailed supplementary information.
    The Remark and Reason Code Committee of X12N maintains the health 
care claim status reason codes that are currently used in version 4010 
of the X12N 277 Claims Status response transaction. This transaction 
provides information about the general status of a claim in response to 
a request made for such status, using version 4010 of the X12N 276 
transaction.
    Ultimately, the standards organization determined that the health 
care claims status codes were significantly less definitive and 
efficient than the LOINC[supreg] codes for communicating detailed or 
specific clinical information to supplement a claim, and made a 
recommendation to the Secretary to adopt LOINC[supreg] for the 
electronic health care claims attachment transactions.
    The recommendation was supported through a 1996 ``Proof of 
Concept'' study sponsored by CMS, using an early version of the X12N 
277-Health Care Claim Request for Additional Information, coupled with 
the health care claim status reason codes. Eight provider/vendor 
partners and five plans that were also Medicare contractors 
participated in the effort to evaluate the suitability of the X12N 277 
and the health care claims status codes for electronic attachment use 
(Executive Report Medicare Proof of Concept Study: Standard Electronic 
Requests for Additional Medical Review Information). This study 
identified a number of barriers related to the use of health care claim 
status reason codes for the purpose of the electronic attachments 
transactions. Specifically, the health care providers did not view the 
codes as sufficiently ``concise'' in providing the request. They 
predicted that this lack of precision would increase time spent 
``pulling and copying medical records'' and submitting responses such 
as ``sent the whole record,'' which would increase costs to the health 
care provider and the health plan. There were also concerns about the 
level of specificity, clarity, and redundancy of the codes. In fact, a 
cross walk of the claims status codes to the existing standard codes 
could not be accomplished, and the study showed that, in many cases, 
several claim status reason codes were required at one time in order to 
convey an appropriate level of clarity to the request. At the time of 
the study, there were 406 local (Medicare) codes being used, and 50 
percent of them could not be mapped to the health care claim status 
reason codes.
    The example in Table 2, Comparison of LOINC[supreg] Codes and 
Health Care Claim Status Reason Codes for Requesting Additional 
Information, illustrates the brevity and efficiency associated with 
using LOINC[supreg] codes when compared to health care claim status 
reason codes. In this example, the health plan is requesting 
information pertaining to treatment, progress notes, and attainment of 
rehabilitation goals for a rehabilitation service.

 Table 2.--Comparison of LOINC[supreg] Codes and Health Care Claim Status Reason Codes for Requesting Additional
                                                   Information
----------------------------------------------------------------------------------------------------------------
                                        LOINC[supreg] code        Health care claim     Health care claim status
        LOINC[supreg] code                  definition            status reason code     reason code definition
----------------------------------------------------------------------------------------------------------------
R4: 18658-5:LOI...................  R4 = Requests for           R4:310:3F............  R4 = Requests for
                                     additional information                             additional information/
                                     and documentation 18658-5                          documentation; 310 =
                                     = Psychiatric                                      Progress notes for the 6
                                     Rehabilitation treatment                           months prior to
                                     plan, progress notes, and                          statement date; 3F =
                                     attainment of goals LOI =                          Rehabilitation facility.
                                     Specifies this is a
                                     LOINC[supreg] code.
-----------------------------------
                                    ..........................  R4:436:3F............  R4 = Requests for
                                                                                        additional information/
                                                                                        documentation; 436 =
                                                                                        Short term goals; 3F =
                                                                                        Rehabilitation facility.
-----------------------------------
                                    ..........................  R4:437:3F............  R4 = Requests for
                                                                                        additional information/
                                                                                        documentation; 437 =
                                                                                        Long term goals; 3F =
                                                                                        Rehabilitation facility.
----------------------------------------------------------------------------------------------------------------

    The LOINC[supreg] code 18658-5 asks the exact question the plan 
wants answered with a single code. In contrast, the health care claim 
status reason codes cannot exactly replicate what the plan wants 
answered; the closest match requires three separate requests. In this 
example, the use of the existing set of reason codes would result in 
the health care provider sending data that the health plan did not 
request and does not need because the code for progress notes includes 
an instruction to send 6 months of information.
3. Implementation Specifications for Sending and Receiving Additional 
Health Care Information Within a Transaction
    As described earlier, the HISB reviewed available transaction 
options and recommended that new versions of the X12N 277/275 standards 
be created and adopted for the transmission of electronic health care 
claims attachment information. In particular, the X12N 275 response 
transaction had the advantage of being capable of transmitting other 
standards within the transaction and the ability to transmit large 
amounts of information within the BIN segment of the transaction. Most 
of the supplemental information requested by health plans is clinical 
information, usually detailed with specific quantitative measurement, 
lab results, and specific medical reports. Clinical information of this 
nature could already be accommodated in HL7 transactions.
    Thus, the BIN segment of the ASC X12N 275 (response) transaction 
would be able to hold all of the attachment information requested by 
the health

[[Page 56004]]

plan. In 1997, the NUBC, the NUCC, and the NCVHS were consulted on the 
data format to be used in the BIN segment. Originally, the NUCC 
recommended that a choice between unstructured ASCII text alone and 
structured HL7 be given. However, much discussion occurred during the 
NCVHS meeting itself, and after considering the comments received, and 
discussion with health insurance EDI professionals, the NCVHS and WG9 
determined that the best options for content structure were the 
following:
    1. HL7 structure--this option would require the structure and 
content of the Additional Information Specification (AIS) to be based 
entirely on HL7 defined information for each message. HL7 would define 
the data content and structure for each AIS based on existing HL7 
conventions;
    2. HL7 plus ASCII text structured--this option would allow, in 
addition to the HL7 structure, additional specifically formatted text 
information (defined lengths, etc.). This would limit the amount and 
type of additional information that could be submitted; or
    3. HL7 plus ASCII text unstructured--this option would allow, in 
addition to the HL7 information, any additional text information.
    The NCVHS Subcommittee on Standards and Security held hearings on 
this specific issue on June 15, 1998 in Washington DC. Representatives 
from ASC X12N, HL7, NUBC, NUCC, HHS, providers, a translator firm, and 
a health care clearinghouse spoke to the advantages and disadvantages 
of each of the options. After discussion, the NCVHS Subcommittee voted 
to recommend to the full committee Option 1, which would require HL7 
messages within the BIN segment of the ASC X12N 275 version 4020--
Additional Information to Support a Health Care Claim or Encounter 
implementation guide. This approach would accommodate a broad spectrum 
of possible information since the HL7 standard permits unstructured 
ASCII text within the body of an HL7 structure. The HL7 standard 
supports the additional information specifications that represent the 
specific supplementary information being submitted in the form of an 
attachment. Thus, the AIS, formatted in accordance with the overarching 
HL7 Implementation Guide, represents the data to be transmitted in the 
BIN segment of the X12N 275 transaction.
    The LOINC[supreg] codes offer a comprehensive array of coded topics 
that readily support detailed supplementary information that can be 
transmitted by HL7 messages within the BIN segment, and these codes 
provide sets of universal names and identifying codes for conveying 
laboratory and clinical test results as well as other units of 
information that are important in health care claims attachments. The 
LOINC[supreg] process for reviewing and updating the database of codes 
and values also offers sufficient opportunities for growth and 
expansion. Therefore, LOINC[supreg] was determined to be the best match 
along with the recommended X12 transaction standards and HL7 
specifications.

G. Proposed Standards

    We are proposing certain industry consensus standards that, when 
used together, provide the functionality necessary for the electronic 
health care claims attachment. No other industry standards are in use 
today for this purpose. The proposed standards are fully compatible 
with the other ASC X12 and HL7 standards and can be translated to and 
from various systems using software programs (commonly referred to as 
``translators'' and ``interface engines'') that are increasingly used 
by industries using ASC X12 transactions and HL7 messages.
    This rule proposes the following for adoption as national standards 
for electronic health care claims attachments:
1. Code Set
    The industry organizations that developed the electronic claims 
attachment standards proposed the adoption of LOINC[supreg] as the code 
set for representing the specific elements of attachment information. 
In 1998, NCVHS held several days of hearings on electronic health care 
claims attachments, including presentations on the status of a pilot 
for the request transaction, the types of attachments being requested 
by health plans, and the use of the LOINC[supreg] code set for 
describing and/or itemizing the information being requested, and the 
information being submitted in response to that request. Based on the 
testimony, NCVHS recommended that the LOINC[supreg] code set be adopted 
to support electronic health care claims attachments. We support the 
recommendation, and have included the adoption of LOINC[supreg] codes 
as a part of this proposed rule. HL7 has created companion 
LOINC[supreg] modifiers that would add further specificity to the 
LOINC[supreg] code itself. These modifiers refine the requests in terms 
of time frame; for example, on, before, or during a particular 
encounter, or in terms of item modifiers, such as abnormal, worst, 
first, last, etc. We therefore also propose to adopt the LOINC[supreg] 
modifiers as national standards for the electronic health care claims 
attachments.
    As we have described earlier, the HL7 specification uses 
LOINC[supreg] codes for each proposed electronic claims attachment, and 
these AIS specify the required content and LOINC[supreg] codes for each 
electronic attachment. It is, therefore, imperative for all segments of 
the industry to comment on the proposed attachment content, the 
attachment criteria and the procedures, so that the standards can be 
validated, and any appropriate revisions to those standards made and 
approved in time for the final rule.
    The LOINC[supreg] code set, similar to ICD-9, CPT-4, HCPCS, CDT and 
other proprietary code sets, may be updated with new codes as needed to 
reflect new technology, services, and procedures. Similar to other code 
sets, maintenance updates of the LOINC[supreg] code set are permissible 
and do not require regulatory action, though the formal procedures of 
the code set maintainer must be followed for requesting, adding and 
communicating new codes to each code set. The addition of new codes to 
the LOINC[supreg] code set is considered a routine code set maintenance 
activity and does not require rulemaking because, in part, additions 
(and deletions) do not change the format or field size of the codes. 
Such maintenance simply allows the addition or deletion of codes to 
accommodate clinical advances and industry needs. Modification, on the 
other hand, involves actual format changes to some or all of the codes, 
or the code set in its entirety, such as converting a numeric code set 
to an alphanumeric code set. Such a change would likely require 
significant business and system changes and programming. Therefore, use 
of a modified code set would require rulemaking to allow the industry 
time to evaluate the impact and provide feedback to the Department, the 
code set maintainers, and other relevant parties with authority.
    To date, we have no information to indicate that LOINC[supreg] is 
being evaluated for any kind of modification and therefore we are 
comfortable recommending its adoption for use with electronic health 
care claims attachments. The most common updates to LOINC[supreg] will 
likely be in the categories of laboratory results, clinical reports, 
and medications, as new diagnostic studies, clinical reports, expansion 
of lab technology, new tests and new drug regimens are adopted by the 
industry. The proposed HL7 attachment specifications for laboratory

[[Page 56005]]

results, clinical reports and medications allow for the use of new 
LOINC[supreg] codes in the response, once these become available in the 
LOINC[supreg] code set and are needed for communication between HIPAA 
trading partners.
    With respect to the attachment data that can be requested, also 
known as the ``questions'' or attachment components, the AISs for 
ambulance, emergency department, medications, and rehabilitation 
contain a finite list of LOINC[supreg] codes that may be used. New 
questions, and therefore potential new LOINC[supreg] codes for the 
current AIS that are proposed as a result of the public comment before 
publication of the final rule would need to go through the HL7 ballot 
process; if approved in time, the new questions, in the form of 
LOINC[supreg] codes, could be incorporated in the AIS adopted in the 
final rule. Any LOINC[supreg] question code additions or changes to the 
specifications made after publication of the final rule would require 
rulemaking, as do changes to other standards. New LOINC[supreg] codes 
may be requested through Regenstrief, by following the procedures 
outlined in the LOINC[supreg] manual, Appendix D. Submissions may be 
made via e-mail or regular mail, and the RELMA tool offers use of an 
ACCESS database to ensure the completeness of the request. Commenters 
are encouraged to become familiar with the RELMA tool, the 
LOINC[supreg] database and the LOINC[supreg] manual.
    We specifically do not name a code set for medications or drugs for 
this proposed rule. NDC was repealed as the code set for non-retail 
pharmacy drugs and biologics under the Transactions Rule, and no other 
single code set for drugs has been adopted for non-retail pharmacy 
transactions. The HL7 AIS for medications allows requests for current 
medications, medications administered during treatment, and discharge 
medications. The AIS is written such that it functions with any 
narrative text, codes or coding system that are agreed to between 
trading partners; it does not require any single code set to be used. 
The AIS has a section devoted to special considerations for the drug 
codes and reporting requirements that will work in both human and 
computer decision variants. Industry representatives should read this 
AIS in order to provide feedback to HHS and the SDOs regarding this 
approach to medication documentation.
2. Electronic Health Care Claims Attachment Request Transaction
    We are proposing to adopt the ASC X12N 004050X150 (ASC X12N 277--
Health Care Claim Request for Additional Information) transaction to 
convey the request for the electronic claim attachment. It would 
identify the claim and related data needed. This transaction would 
serve as an ``electronic envelope,'' conveying the LOINC[supreg] code 
or codes appropriate to that electronic attachment request. Only 
LOINC[supreg] codes specified in the HL7 AIS booklets and LOINC[supreg] 
code tables for the particular electronic attachment can be requested. 
Medications, laboratory results, and clinical reports may use any of 
the relevant codes in the LOINC[supreg] code set. The responding 
transaction (the X12N 275) would echo the requester's LOINC[supreg] 
request codes, and provide the data associated with those LOINC[supreg] 
codes, in either the human or computer decision variants.
    In part 162, we would specify the ASC X12N Implementation Guide 
004050X150 (ASC X12N 277--Health Care Claim Request for Additional 
Information) as the standard for requesting electronic health care 
claims attachment information. Note that LOINC[supreg] codes being used 
to request specific information must be those specified in the 
appropriate AIS as follows:
    a. CDAR1AIS0001R021 Additional Information Specification 0001: 
Ambulance Service Attachment. The instructions and LOINC[supreg] code 
tables for requesting ambulance supplemental information are contained 
in this guide.
    b. CDAR1AIS0002R021 Additional Information Specification 0002: 
Emergency Department Attachment. The instructions and LOINC[supreg] 
codes for requesting emergency department supplemental information are 
contained in this guide.
    c. CDAR1AIS0003R021 Additional Information Specifications 0003: 
Rehabilitation Services Attachment. The instructions and LOINC[supreg] 
code tables for requesting rehabilitation services supplemental 
information are contained in this guide.
    d. CDAR1AIS0004R021 Additional Information Specifications 0004: 
Clinical Reports Attachment. The instructions and LOINC[supreg] code 
tables for requesting clinical reports supplemental information are 
contained in this guide.
    e. CDAR1AIS0005R021 Additional Information Specifications 0005: 
Laboratory Results Attachment. The instructions and partial list of 
LOINC[supreg] codes for requesting laboratory results supplemental 
information are contained in this guide.
    f. CDAR1AIS0006R021 Additional Information Specifications 0006: 
Medications Attachment. The instructions and LOINC[supreg] codes for 
requesting medication supplemental information are contained in this 
guide.
3. Electronic Health Care Claims Attachment Response Transaction
    We are proposing to adopt the ASC X12N 004050X151 (ASC X12N 275--
Additional Information to Support a Health Care Claim or Encounter) as 
the response transaction to convey the claim identification and related 
data, such as individual name, provider name, date and type of service, 
that are needed to match the information to the original claim. The 
claim identification and related data are conveyed in the BIN segment 
of the transaction that serves as an ``electronic envelope.'' This 
envelope also conveys the HL7 message that carries the supplementary 
electronic health care claims attachment data in the form of an AIS.
    Information conveyed by the HL7 message would be the specific AIS 
provided in response to the LOINC[supreg] code or codes contained in 
the request, or as an unsolicited (but pre-arranged) electronic 
attachment submission. Each electronic attachment type is identified by 
a unique LOINC[supreg] code that indicates its name and appears in the 
header of the message for identification purposes; for example, 
psychiatric rehabilitation has its own unique LOINC[supreg] code of 
18594-2. Other LOINC[supreg] codes used in the body of the message will 
specify the specific information related to that service that is 
desired (for example, the psychiatric rehabilitation plan). The 
individual booklets for each HL7 AIS contain the instructions and 
LOINC[supreg] code tables that define all of the data content that may 
be used in that particular electronic attachment.
    The LOINC[supreg] code set provides a set of subject modifier codes 
that are categorical; that is, an identifier code can apply to a group 
of related reports. For example, Clinical reports can be identified by 
the type of equipment used (for example, CAT scan report); the body 
part examined (report of x-ray of left wrist), the subdivision of the 
laboratory performing the analysis (microbiology), or a challenge to 
the system (cardiac stress test). Different combinations of these facts 
can produce information relevant to a clinical reports AIS. Therefore, 
it is important that the request transaction, based upon the ASC X12N 
277 version 004050x150 being submitted, use the LOINC[supreg] Report 
Subject Identifier Code(s) that most clearly represents the attachment 
information needed. The LOINC[supreg] Report Subject Modifier Codes can 
be found in the LOINC[supreg] Committee publication.

[[Page 56006]]

    In part 162, we would specify the ASC X12N Implementation Guide 
004050X151 (ASC X12N 275--Additional Information to Support a Health 
Care Claim or Encounter and the HL7 CDAR1AIS0000RO21 HL7--Additional 
Information Specification Implementation Guide, and HL7--Clinical 
Document Architecture Framework Release 1.0) as the standards for 
conveying electronic health care claim attachments, and we would 
specify the following six specifications as the standards for the 
electronic health care claims attachments:
    a. CDAR1AIS0001RO21, Additional Information Specification 0001: 
Ambulance Service Attachment, Release 2.1, based on HL7 CDA Release 
1.0. The Ambulance AIS contains data elements used to describe 
ambulance services. These include body weight, transport distance, and 
the reason for the ambulance trip.
    b. CDAR1AIS0002RO21, Additional Information Specification 0002: 
Emergency Department Attachment, Release 2.1, based on HL7 CDA Release 
1.0. The Emergency Department AIS is used to provide supporting 
documentation when an emergency department visit is reported. Data 
elements include assessment results, medications provided, and the 
chief complaint reported. This AIS is derived in part from the document 
Data Elements for Emergency Department Systems, Release 1.0 (DEEDS), 
published by the National Center for Injury Prevention and Control, 
Centers for Disease Control and Prevention. The DEEDS document provides 
uniform specifications for data elements that may be used for EDI 
transactions. The emergency department AIS includes a subset of those 
data elements and adds additional elements on to meet the business 
needs associated with this attachment. Because this AIS only uses a 
portion of the DEEDS data element document, DEEDS would not be adopted 
as a code set for this HIPAA transaction.
    c. CDAR1AIS0003R021, Additional Information Specification 0003: 
Rehabilitation Services Attachment, Release 2.1, based on HL7 CDA 
Release 1.0. The Rehabilitation Services AIS provides information on 
rehabilitation care plans associated with nine disciplines: Alcohol/
Substance Abuse Rehabilitation, Cardiac Rehabilitation, Medical Social 
Services, Occupational Therapy, Physical Therapy, Psychiatric 
Rehabilitation, Respiratory Therapy, Speech Therapy, and Skilled 
Nursing. This AIS is not intended to accommodate requests for 
attachments related to Home Health claims. Data elements include 
information on plan progress, signatures, attending physicians, 
symptoms, and levels of individual participation.
    d. CDAR1AIS0004R021, Additional Information Specification 0004: 
Clinical Reports Attachment, Release 2.1, based on HL7 CDA Release 1.0. 
The Clinical Reports AIS allows for the electronic transmission of a 
wide variety of clinical reports, such as electrocardiograms and 
radiology reports. Examples of data elements included in this AIS are 
specimen source, reason for study, and observation values. The 
instructions and LOINC[reg] codes for transmitting clinical reports by 
an AIS cover a wide variety of functional topics. These include, but 
are not limited to, discharge summaries, operative notes, history and 
physicals, clinic visits, other assessments, and all types of 
diagnostic procedures including laboratory studies.
    e. CDAR1AIS0005R021, Additional Information Specification 0005: 
Laboratory Results Attachment, Release 2.1, based on HL7 CDA Release 
1.0. The Laboratory Results AIS gives health care providers the ability 
to report a wide variety of laboratory results. Data elements include 
individual identifiers, reasons for the study, actual laboratory 
results, and abnormality indicators.
    f. CDAR1AIS0006R021, Additional Information Specification 0006: 
Medications Attachment. Release 2.1, based on HL7 CDA Release 1.0. The 
Medications AIS allows health care providers to report on the 
medication an individual is currently taking, or was given during a 
course of treatment, or was provided upon discharge. Data elements 
include individual identifiers, medications provided, and units of the 
medication.
    New AIS addressing durable medical equipment, home health, and 
periodontal charting are currently being developed by HL7. We solicit 
comments regarding which other attachments most impact the health care 
industry with respect to the exchange of clinical and administrative 
information, specifically for the purpose of claims adjudication.
4. Examples of How Electronic Health Care Claims Attachments Could Be 
Implemented
a. Use of the Proposed Transactions, Specifications, and Codes for 
Electronic Health Care Claims Attachments
    An X12N 277 request for claims attachments may be used to 
electronically request one or more attachment types, and the X12N 275 
response can be used to transport one or more electronic attachment 
types. The X12 Implementation Guides describe how the LOINC[supreg] 
codes and LOINC[supreg] modifiers are to be used, and how the segments 
within the BIN segment of the response transaction are used to carry 
the actual attachment information. Individual LOINC[supreg] codes and 
LOINC[supreg] modifiers are defined for each component of the 
electronic attachment, specific to each discipline. The modifiers 
permit the request to be limited by date, time, number of repetitions, 
and other factors. Each AIS includes tables of the LOINC[supreg] codes 
needed to request the attachment data specific to each claim type. 
However, a request for Emergency Department information may include a 
request for data on laboratory results or diagnostic studies either as 
part of a full Emergency Department attachment or as a Laboratory 
Results attachment or a Clinical Reports attachment. In other words, it 
is possible that an electronic attachment request for one claim may 
require multiple attachment types. The Emergency Department attachment 
specification defines all of the LOINC[supreg] codes necessary to 
electronically request attachment data specific to treatment in an 
emergency department. In fact, there are three codes that represent an 
explicit request for the complete set of data components relevant to 
emergency department events, inclusive of laboratory results and 
diagnostic studies. Alternatively, the health plan may request only one 
piece of information for a specific attachment type. For example, it 
may request only the associated lab results for the ER visit. When only 
lab results or diagnostic studies are requested for an emergency 
department encounter, the results and studies are to be reported as 
defined in the Laboratory AIS, but the information is to be sent in the 
response to the specific request related to the services provided in 
the emergency department; the claim ID will be used to match up the 
data.
    As another example, using the Rehabilitation AIS, the LOINC[supreg] 
codes for rehabilitation services include some codes that can be used 
to request or send information about medications the individual 
reported taking as part of the rehabilitation treatment plan. The 
specifications for sending medications are described in section two of 
the AIS for Medications. The sender will use the instructions in the 
Medications AIS for sending medication information related to the 
rehabilitation plan claim and the required additional documentation/
attachment.
    Again, it is critical for the industry to evaluate the HL7 AISs, 
the X12 Implementation Guides and the LOINC[supreg]

[[Page 56007]]

code set to fully evaluate and understand their use and the 
implications on technical systems and business operations.
b. White Paper from HL7
    A white paper entitled ``HIPAA and Claims Attachments: Preparing 
for Regulation'' was written and published in August 2003 by the ASIG 
at HL7. This white paper, reproduced in part in this preamble with 
specific written permission from HL7, provides sample scenarios 
depicting how health care providers and health plans could comply with 
the proposed standards for electronic attachment transactions. The 
entire white paper is also available at no charge on the HL7 Web site, 
http://www.HL7.org.
    The document is included here to highlight some of the possible 
approaches to implementation, and to depict how electronic health care 
claims attachments requests and responses could work between health 
plans and health care providers. The scenarios may be useful to covered 
entities in determining which path may be the most appropriate for a 
particular setting or entity type. These scenarios are not the only 
options for implementation and compliance; rather, they were crafted by 
HL7 in an effort to help the industry understand how electronic health 
care claims attachments could be implemented. The descriptions and pros 
and cons for each scenario were taken in their entirety from the white 
paper, and therefore the term ``payer'' instead of ``health plan'' is 
used throughout this section. These two terms have the same meaning for 
purposes of this discussion. Any comments on the white paper may be 
submitted to the ASIG, through the HL7 Web site.
    The text for the HL7 white paper begins here:

    Providers and payers have the latitude to choose a path that 
suits their own balance of low/high impact vs. low/high business 
benefit. In general, the scenarios are listed from low impact/low 
business benefit to high impact/high business benefit. Both payers 
and providers also have the latitude to analyze their own business 
needs and prioritize the accommodation for each individual 
attachment. For example, if either payers or providers review their 
current volume of activity and determine that one or two attachments 
encompass a disproportionate percentage of all their attachment 
volume, they would prioritize the accommodation of those one or two 
attachments as structured data to facilitate auto-adjudication.
    All following scenarios represent the processing that takes 
place either after a payer has requested additional documentation 
from the provider or when the provider has elected to submit 
additional information in the same transmission as the initial 
claim. The payer and provider scenarios are not dependent upon each 
other. Each payer and provider can choose a path most suitable to 
the situation independent of the means used by the others with whom 
the payer and provider exchange standardized electronic 
transactions.
    Provider Compliance:
    Provider Scenario 1: A provider keeps patient data in paper 
records. The provider's billing application is adapted to accept 
scanned images. Once the appropriate attachments documents are 
scanned from the paper medical record, the billing application 
associates that scanned image with a claim and includes the scanned 
image as an attachment in submission to the payer as needed.
[GRAPHIC] [TIFF OMITTED] TP23SE05.051

    Advantages--This scenario requires minimal changes to the 
billing application. Based on feedback from the healthcare industry, 
this accommodation was specifically included in the specification as 
an interim step for providers who plan to eventually adopt one of 
the other scenarios that result in sending attachments as structured 
data, but needed an expedient alternative as an interim step.
    Disadvantages--This scenario does not provide the payer with the 
structured data necessary to auto-adjudicate the claim, thus 
negating much of the advantage of electronic attachments. This 
scenario requires a staff member to scan the documents that contain 
the attachments data. Since the required attachments data may exist 
on forms that also include other, unnecessary data, the staff member 
may, for privacy reasons, also have to take whatever steps are 
necessary to ensure the privacy of Protected Health Information 
under HIPAA.
    Likely changes from status quo--The provider's billing vendor 
would have to accommodate the new X12N 277 and 275 transaction sets 
and would have to enable the attachment of a scanned image to the 
275 transaction set. The provider would have to assign the new task 
of scanning in attachments data to staff members.
    Provider Scenario 2: The provider installs a conversion utility 
in the billing or practice management software to translate 
attachments data from its current format into a fully formatted 
attachment with structured data. The provider is then able to key 
the attachment data into the conversion utility. The utility creates 
the attachment and delivers it to the billing application. The 
billing application then associates the formatted attachment with a 
claim and includes it in submission to the payer as needed.

[[Page 56008]]

[GRAPHIC] [TIFF OMITTED] TP23SE05.052

    Advantages--This scenario provides the payer with the structured 
data necessary to auto-adjudicate the claim. It also requires 
minimal changes to the billing application. This scenario also 
provides a ``bridge'' between the EMR scenario described in Scenario 
4 and the strictly text/image model in Scenario 1. Although this 
scenario introduces an additional workflow step, it also allows for 
the elimination of other workflow steps such as copying paper files 
and dealing with the U.S. mail process.
    Disadvantages--This scenario requires the addition of a new 
conversion utility application into the provider's information 
systems environment. Attachments data are manually typed into the 
conversion utility, which is an additional workflow step. Since this 
scenario requires an additional workflow step, the provider does not 
have an automated solution for submitting unsolicited attachments 
with the initial claim. Furthermore, there is an increased 
opportunity for human error, due to the requirement for manual 
keying of information.
    Likely changes from status quo--The provider would have to 
select, purchase, install, and support the new conversion utility. 
The provider's billing vendor would have to accommodate the new 
request for attachment and the response (with attachment) and join 
the attachment from the conversion utility with the claim.
    Provider Scenario 3: The provider's billing application is 
adapted to allow attachments information to be keyed directly into 
the billing application. The billing application then formats the 
attachment information as structured data and includes it in 
submission to the payer as needed.
[GRAPHIC] [TIFF OMITTED] TP23SE05.053

    Advantages--This scenario provides the payer with the structured 
data necessary to auto-adjudicate the claim. Only the billing 
application needs to be upgraded. This scenario also provides a 
``bridge'' between the EMR scenario described in Scenario 4 and the 
strictly text/image model in Scenario 1. Although this scenario 
introduces an additional workflow step, it also allows for the 
elimination of other workflow steps such as copying paper files and 
dealing with the U.S. mail process.
    Disadvantages--This scenario requires the attachments data to be 
manually typed into the billing application, which is an additional 
workflow step. Since this scenario requires an additional workflow 
step, the provider does not have an automated solution for 
submitting unsolicited attachments with the initial claim. 
Furthermore, there is an increased opportunity for human error, due 
to the requirement for manual keying of information.
    Likely changes from status quo--The provider's billing vendor 
would have to enable the provider's billing application to accept 
attachment data that have been keyed manually, and would have to 
accommodate the new request for an attachment and sending the 
response with the attachment data, as well as the creation of the 
structured data attachment itself. The provider would have to 
reassign staff to the new task of keying in attachment data, versus 
their previous task of copying and mailing records manually.
    Provider Scenario 4: The provider's Electronic Medical Record 
(EMR) or clinical information system provides a fully formatted 
attachment with the appropriate attachment information to the 
billing application. The billing application then associates the 
formatted attachment and includes it in submission to the payer as 
needed.

[[Page 56009]]

[GRAPHIC] [TIFF OMITTED] TP23SE05.054

    Advantages--This scenario provides the payer with the structured 
data necessary to auto-adjudicate the claim.
    Disadvantages--This scenario requires capabilities for data 
exchange to be present in the provider's billing and one or more 
EMR/clinical applications.
    Likely changes from status quo--The provider's billing 
application would have to accept attachments as XML documents and 
transmit them to payers. Various provider systems would have to 
produce structured attachments in CDA format and route them to the 
billing system. Examples of potential source systems include the 
electronic medical record, laboratory, radiology (for reports), 
rehabilitation, and general transcription. Where the source system 
already produces HL7 version 2 messages, the provider may use an 
integration broker to convert the HL7 message into a CDA document. 
In a few cases, the provider may choose to use desktop productivity 
applications to accept input.

Payer Options

    Payer Scenario 1: If the attachment is sent as an image instead 
of structured data using CDA, manual adjudication may be done by 
viewing the image using a Web browser or image viewer.
[GRAPHIC] [TIFF OMITTED] TP23SE05.055

    Advantages--This option represents the least organizational 
change for the payer. There may be savings opportunities based on 
the reduction in mailed requests and the manual tracking systems 
used to associate hard copy requests, records, and the related 
claims. It is possible that this option would reduce time delays 
associated with the manual requests and responses, and minimize the 
number of ``lost records.''
    Disadvantages--None of the benefits of auto-adjudication are 
realized.
    Changes to the Status Quo--Elements of the payer's application 
suite are modified to associate the CDA (XML) based attachment for 
human viewing via a browser.
    Payer Scenario 2: If the payer already uses a conversion utility 
to translate X12N transaction sets, and that conversion utility is 
capable of also translating CDA based attachments, the claim may be 
auto-adjudicated. Exceptional claims may be manually adjudicated and 
attachments viewed using a Web browser.

[[Page 56010]]

[GRAPHIC] [TIFF OMITTED] TP23SE05.056

    Advantages--A conversion utility may be more flexible and may 
more readily accommodate the new tasks for parsing XML based 
attachments than the payer's main system. This option provides the 
potential to maximize auto-adjudication and minimize administrative 
costs.
    Disadvantages--Additional responsibility is placed on the 
conversion utility. This may or may not be a disadvantage.
    Changes to the Status Quo--Existing conversion utilities have to 
be either reconfigured or modified to parse CDA (XML based) 
attachments.
    Payer Scenario 3: If the payer already uses a conversion utility 
to translate X12N transaction sets, and that conversion utility is 
not capable of also translating CDA based attachments, a second 
conversion utility may be used and the claim may be auto-
adjudicated. Exceptional claims may be manually adjudicated and 
attachments viewed using a Web browser.

[[Page 56011]]

[GRAPHIC] [TIFF OMITTED] TP23SE05.057

    Advantages--Existing components continue to function with little 
or no modification. Auto-adjudication may still be used to its 
potential.
    Disadvantages--This adds one or more utilities to split the 
attachment from its X12N transaction set, parse the attachment, and 
maintain the association between the attachment and its X12N 
transaction set. This may add significant complexity to the flow of 
electronic transaction sets.
    Changes to the Status Quo--One or more utilities are added to 
the payer's application suite to split the attachment from its X12N 
transaction set, parse the attachment, and maintain the association 
between the attachment and its X12N transaction set.
    Payer Scenario 4: If the payer is capable of parsing both X12N 
275 transaction sets and CDA based attachments, the claim may be 
auto-adjudicated. Only exceptional claims are manually adjudicated. 
When necessary, attachments are viewed using a Web browser.
[GRAPHIC] [TIFF OMITTED] TP23SE05.058


[[Page 56012]]


    Advantages--This scenario is the best case and has the best 
potential to maximize auto-adjudication and minimize administrative 
costs.
    Disadvantages--This may involve the most significant changes to 
the primary information systems used for processing claims.
    Changes to the Status Quo--Most large primary management 
information systems are legacy based mainframe systems. These 
systems would need to integrate with XML aware browsers to view XSL 
``rendered'' attachment data.

    The text for the HL7 white paper ends here.

H. Requirements (Health Plans, Covered Health Care Providers and Health 
Care Clearinghouses)

    Health plans would be required to be prepared to receive and send 
only the standards specified in Sec.  162.1915 and Sec.  162.1925 for 
the identified transactions. No other electronic transaction format or 
content would be permitted for the identified transactions. We intend 
for covered entities to use the standard transactions and the approved 
attachment specifications as they apply to the six named attachment 
types.
    The use of the standard electronic health care claims attachments 
would not preclude the health plan from using other processes or 
procedures to verify the information reported in the attachment 
documentation.
    Under the proposed rule, health plans may continue to use manual 
processes (such as paper forms, letters, faxes, etc.) to request 
additional documentation from a health care provider, even for the 
attachment types listed in this proposal. However, whenever such a 
request is made electronically, it must be made using the standard. 
Furthermore, if the health care provider asks that the transaction be 
sent using the standard, the health plan must comply.
    As stated earlier, it is possible that multiple AIS apply to a 
particular electronic claim attachment request. The clinical reports, 
medications, and laboratory results AIS could be used to request 
additional information about any service in a particular claim. 
However, the ambulance, emergency department, and rehabilitation 
services AIS can only be used to request information about the specific 
type of services to which they refer. When the ASIG developed the first 
set of attachment types, three were for specific types of services--
ambulance, emergency department, and rehabilitation. Since those 
services often necessitated tests and reports, the supporting 
attachment specifications--laboratory results, clinical reports and 
medications--were created. These latter specifications also represented 
claim types that were subjected to additional documentation requests in 
their own right, so the six together were a practical fit. Thus, for 
example, if a health plan needs additional information about an 
ambulance service, and needs information about the medications an 
individual is taking in order to adjudicate the ambulance claim, both 
the ambulance and medication AIS would be used and sent within the same 
X12N transaction.
Covered Health Care Providers
    We would require covered health care providers to be prepared to 
receive and send the standards specified in Sec.  162.1915 and Sec.  
162.1925 for the specific electronic health care claims attachment 
transactions, if they choose to receive and send requests and responses 
electronically for any of the six proposed attachments. No other 
electronic formats would be permitted for these specific business 
purposes. For information required for other business purposes, the 
standards proposed here would not limit the type and format of 
electronic or paper transaction could be used. Health care providers 
generally have the option of using paper as their regular mode of 
communication. Any information requested after the claims adjudication 
process, such as for post-adjudication medical review or quality 
assurance review, would not be subject to the standards proposed here. 
In either case, covered health care providers would continue to have 
the option of using electronic or manual means of conducting business, 
including responding to a request for attachment information 
electronically or on paper. However, if they choose to respond 
electronically to an attachment request for which a standard has been 
adopted, that standard would have to be used.
    Any electronic attachments covered by the rule and that accompany a 
new claim would have to be submitted based on an advanced instruction 
from the receiving health plan. These ``unsolicited'' electronic 
attachments should not be sent without prior agreement or understanding 
between trading partners.
Health Care Clearinghouses
    Health care clearinghouses would be required to be prepared to 
receive and send only the standards specified in Sec. 162.1915 and 
Sec. 162.1925 for the specific electronic health care claims attachment 
transactions, or to translate proprietary information from their 
clients into standard format for re-transmission. Health care 
clearinghouses must already comply with the requirements set out in 
Sec. 162.930, adopted by the Transactions Rule.
1. Additional Information Specification (AIS) Uses: Attachment Types 
That May Be Used for Any Service
    The proposed rule would require that attachment requests, 
responses, and the AIS be used in the following situations, when the 
transaction is being conducted electronically:
    a. Clinical Reports
    Used when the health plan is requesting, or the health care 
provider is supplying, clinical report information needed to support 
the adjudication of a claim for any service. The request may cover a 
wide variety of questions that require information from clinical 
reports, such as surgical and diagnostic procedures and discharge 
summaries.
    b. Laboratory Results
    Used when the health plan is requesting, or the health care 
provider is supplying, information on laboratory results needed to 
support the adjudication of a claim for any service. The request may 
cover the entire set of laboratory tests, from allergy to toxicology.
    c. Medications
    Used when the health plan is requesting, or the health care 
provider is supplying, information on medication information needed to 
support the adjudication of a claim for any service. The request may 
cover medications administered during a service, medications sent home 
with the individual, or medications currently being taken by the 
individual.
2. Additional Information Specification (AIS) Uses: Attachment Types 
for Specific Services
    a. Rehabilitation Services
    Used when the health plan is requesting, or the health care 
provider is supplying, rehabilitation services information needed to 
support the adjudication of a claim that includes one or more of the 
nine disciplines designated for rehabilitation services (for example, 
occupational therapy, cardiac rehabilitation, or substance abuse 
therapy).
    b. Ambulance Services
    Used when the health plan is requesting, or the health care 
provider is supplying, information needed to support the adjudication 
of a claim that includes ambulance services.
    c. Emergency Department
    Used when the health plan is requesting, or the health care 
provider is supplying, information needed to support the adjudication 
of a claim that includes emergency department services.

[[Page 56013]]

3. Maximum Data Set
    Each AIS is considered to include the maximum data set for each of 
the named electronic attachment types. We propose to prohibit health 
plans from asking for additional data beyond those that are specified 
in the AIS for that service. Four of the attachment specifications 
(ambulance services, emergency department, medications, and 
rehabilitation services) have a finite set of LOINC[supreg] codes that 
can be used to ask the questions (request the information) for those 
services. The specifications for Laboratory Results and Clinical 
Reports do not contain pre-defined lists of codes because clinical 
developments in those two areas necessitate the ability to use and 
request information about new tests and reports. Any of the laboratory 
and clinical reports codes in the LOINC[supreg] database could be used 
for these requests and responses.
    The proposed AIS documents were drafted several years ago when 
business practices related to health care claims attachments were 
likely different than they are today. Therefore, the electronic health 
care claims attachment data elements, questions, and the cardinality of 
these elements must be validated for each specification. It is 
imperative that each AIS be thoroughly reviewed by covered entities to 
ensure that the proposed data set meets current and projected future 
business needs. Thus, we ask that during the comment period, health 
plans and health care providers engage fully in the process of 
evaluating this maximum data set and the required, situational, and 
optional elements, and provide us with comments on these issues.

I. Specific Documents and Sources

    All code sources that are developed outside of the X12 standard 
setting process, such as ZIP codes, which are maintained by the United 
States Postal Service, are referred to as external code sets. These 
code sets are maintained independent of any HIPAA specific 
requirements, and no rulemaking is required when changes are made to 
them. The external code sets are listed in section C of the appropriate 
ASC X12N implementation guide. All of the code sources listed in the 
ASC X12N Implementation Guides have mechanisms for modifying their 
codes. The contact posted on the code source list can provide detailed 
information regarding the process and timing for updating its codes. If 
the format of a code set that has been adopted as a HIPAA code set 
(HCPCS, CPT, ICD-9 etc.) is changed, for example, from alpha to alpha 
numeric, then the change constitutes a ``modification of the code 
set.'' Use of a modified code set can only be required through further 
rulemaking to expressly adopt those modified code sets in place of the 
existing standard.
    The implementation specifications, as expressed in implementation 
guides for the various ASC X12N transactions and HL7 messages as well 
as the additional information specifications and the LOINC[supreg] 
Modifier Codes, may all be obtained at no charge from the Washington 
Publishing Company site at the following Internet address: http://www.wpc-edi.com/.
    Users without access to the Internet may purchase the X12N 
implementation guides from the Washington Publishing Company directly: 
Washington Publishing Company, PMB 161, 5284 Randolph Road, Rockville, 
MD, 20852; telephone 301-949-9740; FAX: 301-949-9742.
    HL7 maintains the XML-based Clinical Document Architecture Release 
1.0 and the AISs, and information can be obtained at no charge at the 
HL7 Web site: http://www.HL7.org. Users without access to the Internet 
may obtain HL7 documents directly from the HL7 organization, c/o Health 
Level Seven, Inc., 3300 Washtenaw Avenue, Suite 227, Ann Arbor, MI 
48104, or 734-677-7777.
    The LOINC[supreg] database and the publication LOINC[supreg] 
Modifier Codes can be obtained at no charge from the Regenstrief 
Institute site at the following Internet address: http://www.regenstrief.org/loinc/loinc.htm. Users without access to the 
Internet may obtain the LOINC[supreg] database and the LOINC[supreg] 
modifier codes from the Regenstrief Institute, c/o LOINC[supreg], 1050 
West Wishard Blvd., Indianapolis, IN 46202, telephone 317-630-7433.
    The full set of the Data Elements for Emergency Department Systems, 
Release 1.0 (DEEDS) is published by the National Centers for Injury 
Prevention and Control, Centers for Disease Control and Prevention. The 
Internet address is http://www.cdc.gov/ncipc/pub-res/deedspage.htm.

III. Modifications to Standards and New Electronic Attachments

    [If you choose to comment on issues in this section, please include 
the caption ``MODIFICATIONS TO STANDARDS AND NEW ATTACHMENTS'' at the 
beginning of your comments.]
    To encourage innovation and promote development, we propose to 
adopt a process that will facilitate the development and future use of 
electronic health care claims attachments. In 1993, WEDI estimated that 
400 or more specific attachments were in use to support health care 
business needs. Comments from the industry are needed to validate and/
or update this figure, as it is over 10 years old, and represents many 
different types of attachments which are not all required solely for 
health care claims adjudication. For example, the original list of 
attachments included such documentation types as certification for 
sterilization and hysterectomy, dental services, eligibility, worker's 
compensation verification and the like. We do not believe that there 
are 400 different health care claims attachment types that would in 
fact be appropriate for electronic health care claims attachment 
requirements. The industry should identify the relevant attachment 
types and collaborate to assign priority to each one, so that new 
electronic attachment specifications that are appropriate to the 
business needs of the health care industry can be developed.

A. Modifications to Standards

    In Sec. 162.910, parameters are outlined for requesting and making 
modifications to the standards. The statute provides that the Secretary 
of HHS may not modify any standard, including the electronic attachment 
standards, more frequently than once a year and must permit at least 
180 days for implementation of an adopted modification to a standard by 
all affected entities before compliance with the modified standard may 
be required. The Secretary may, however, adopt a modification at any 
time during the first year after the standard or implementation 
specification is initially adopted, if the Secretary determines that 
the modification is necessary to permit compliance with the standard.
    The addition or deletion of codes in a code set for the purpose of 
enhancing the electronic attachment's communication capabilities is 
considered maintenance, because such actions do not constitute format 
or field length changes to the codes or the code set itself. HIPAA 
expressly permits the routine maintenance, testing, enhancements, and 
expansion of a code set. We have stated throughout the preamble, that 
if the codes or code set were changed structurally--for example, 
changing from a numeric format to an alphanumeric format, this would be 
considered an actual modification of the code set that would require 
system changes. Use of such a modified code set could not be required, 
and would not be permitted, without a regulatory change.

[[Page 56014]]

    There are mechanisms in place for LOINC[supreg] to add new codes on 
a regular basis to reflect developments in the industry, just as occurs 
with ICD-9, CPT-4, and HCPCS, among others. New codes may be used in an 
electronic health care claims attachment without a change to the rule, 
if use of a new code is specifically permitted by the AIS, and the use 
complies with the associated ASC X12N Implementation Guides and HL7 
AISs. For example, new LOINC[supreg] codes for new types of laboratory 
results and clinical reports will be added to LOINC[supreg] based on 
medical developments. Use of such new codes is permitted by the AIS for 
laboratory results, clinical reports and medications in both the 
request and the response transactions.
    Requests for new LOINC[supreg] codes are to be addressed to the 
Regenstrief Institute for Health Care, c/o LOINC[supreg] Committee, 
1050 West Wishard Blvd, Indianapolis, IN 46202, or electronically, in 
accordance with the instructions in Appendix D of the LOINC[supreg] 
users guide, to the Regenstrief Web site at http://www.regenstrief.org. 
and will be evaluated through the existing process.
    Once a HIPAA standard is adopted in a final rule, requests for 
changes to that standard must be submitted through the DSMO process, as 
set forth in Sec. 162.910(c). After approval, the DSMOs will forward 
proposed new implementation specifications to the NCVHS and to the 
Secretary. The NCVHS serves as a consultative body that, under the 
provisions of the Public Health Service Act, provides advice concerning 
specified health care matters to the Secretary. Following consultation 
with appropriate agencies and organizations, including the NCVHS, the 
Secretary may adopt the modified versions as HIPAA standards through 
the notice and comment rulemaking process.
    Information pertaining to the designation of DSMOs and their 
responsibilities can be found in the Transactions Rule and the notice 
announcing the DSMOs, which were published on August 17, 2000 (65 FR 
50365, 50373).

B. Additional Information Specifications for New Electronic Attachments

    We expect that the HL7 ASIG will continue to develop new standard 
AISs using the HL7 CDA Release 1.0 framework, and these will be 
approved under the established DSMO process. After development and 
approval by the DSMO, new AISs will be sent to the NCVHS and then to 
the Secretary for consideration. Upon receipt of new proposed 
additional information specifications, the Secretary may choose to 
incorporate them in a future proposed rule and subsequently may adopt 
them as HIPAA standards.

C. Use of Proposed and New Electronic Attachment Types Before Formal 
Approval and Adoption

    Due to the need to complete this rulemaking, together with the 
delayed compliance dates provided for by statute, the final rule will 
not be implemented for several years. There are no Federal prohibitions 
on the use of the proposed X12 standard transactions or HL7 AIS between 
now and the time compliance with the final standards is required. Even 
after the final rule is published, and compliance is required, if the 
Secretary has not named a standard for a particular type of electronic 
claims attachment, covered entities are still free to use that 
attachment type on a voluntary basis for any business purpose they deem 
appropriate.
    For example, if the DME attachment specification is finalized, 
balloted, and approved by HL7 after publication of the final rule, but 
DME is not one of the named attachment types, covered entities will be 
able to use that AIS and the X12N 277/275 implementation guides with no 
regulatory requirements. In other words, use of a new AIS that has not 
been formally adopted, as a standard by the Secretary, would be 
voluntary, based on trading partner agreements or other such contracts, 
unless and until regulations adopting that AIS are proposed and made 
final through the regulatory process.

IV. Collection of Information Requirements

    The burden associated with the requirements in this regulation are 
the time and effort of health plans, health care providers and/or 
health care clearinghouses to modify their systems for the capability 
of sending health care transactions electronically. This one-time 
burden has already been approved and accounted for in ``HIPAA Standards 
for Coding Electronic Transactions'' (OMB <greek-i>0938-0866) with a 
current expiration date of February 29, 2008. However, we will amend 
this currently approved collection to include electronic health claims 
attachments to the list of covered transactions.

V. Response to Comments

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

VI. Regulatory Impact Analysis

    [If you choose to comment on issues in this section, please include 
the caption ``IMPACT ANALYSIS'' at the beginning of your comments.]

A. Overall Impact

    We have examined the impacts of this rule as required by Executive 
Order 12866 (September 1993, Regulatory Planning and Review), as 
amended by Executive Order 13258, and the Regulatory Flexibility Act 
(RFA) (Pub. L. 96-354), section 1102(b) of the Social Security Act, the 
Unfunded Mandates Reform Act of 1995 (Pub. L. 104-4), and Executive 
Order 13132.
    The impact analysis in the Transactions Rule assessed the expected 
costs and benefits associated with the Administrative Simplification 
regulations (related to employing electronic systems for designated 
health care related purposes) covering a time span of 10 years. That 
analysis however did not include electronic health care claims 
attachments. Nonetheless, this section can be read in conjunction with 
the Transactions Rule analysis, since the statistics for electronic 
claims can be considered related to electronic claims attachments.
    Executive Order 12866 directs agencies to assess all costs and 
benefits of available regulatory alternatives and, if regulation is 
necessary, to select regulatory approaches that maximize net benefits 
(including potential economic, environmental, public health and safety 
effects, distributive impacts, and equity). A regulatory impact 
analysis (RIA) must be prepared for major rules with economically 
significant effects ($100 million or more in any 1 year). We consider 
this proposed rule to be a major rule, as it will have an impact of 
over $100 million on the economy. This impact analysis shows a 
potential net savings of between $414 million and $1.1 billion over a 
5-year period. We attempt to provide information for the impact 
analysis, focusing on savings projections, since cost data on the HIPAA 
transactions are not yet available from the industry. We solicit such 
data during the comment period for this proposed rule. Also, as 
referenced earlier, HHS provided funding for a pilot to test the 
proposed standards, and we anticipate that any cost/benefit information 
that comes of that study

[[Page 56015]]

will be provided before the final rule is published.
    The RFA requires agencies to analyze options for regulatory relief 
of small businesses. For purposes of the RFA, small entities include 
small businesses, nonprofit organizations, and small government 
jurisdictions. Many hospitals and most health care providers and 
suppliers are small entities, either by nonprofit status or by having 
revenues of $6 to $29 million or less in any 1 year. For purposes of 
the RFA, nonprofit organizations are considered small entities; 
however, individuals and States are not included in the definition of a 
small entity. For details, see the Small Business Administration's 
current regulation that set forth size standards for health care 
industries at (65 FR 69432).
    Effective October 1, 2000, the SBA no longer used the Standard 
Industrial Classification (SIC) System to categorize businesses and 
establish size standards, and began using industries defined by the new 
North American Industry Classifications System (NAICS). The NAICS made 
several important changes to the Health Care industries listed in the 
SIC System. It revised terminology, established a separate category 
(Health Care and Social Assistance) under which many health care 
providers are located, and increased the number of Health Care 
industries to 30 NAICS industries from 19 Health Services SIC 
industries.
    On November 17, 2000, the SBA published a final rule, which was 
effective on December 18, 2000, in which the SBA adopted new size 
standards, ranging from $5 million to $25 million, for 19 Health Care 
industries. It retained the existing $5 million size standard for the 
remaining 11 Health Care industries. The revisions were made to more 
appropriately define the size of businesses in these industries that 
SBA believes should be eligible for Federal small business assistance 
programs.
    On August 13, 2002, the SBA published a final rule that became 
effective on October 1, 2002. The final rule amended the existing SBA 
size standards by incorporating OMB's 2002 modifications to the NAICS 
into its table of small business size standards.
    On September 6, 2002, the SBA published a subsequent final rule 
(effective October 1, 2002) that corrected the August 13, 2002 final 
rule and contained a new table of size standards to clearly identify 
these organizations by dollar value and by number of employees. Some of 
the revisions in size standards affected some of the entities that are 
considered covered entities under this proposed rule. For example, the 
SBA revisions increased the annual revenues for physician offices to 
$8.5 million (other practitioners' offices' revenues remained at $6 
million) and increased the small business size standard for hospitals 
to $29 million in annual revenues.
    The regulatory flexibility analysis for this proposed rule is 
linked to the aggregate flexibility analysis for all of the 
Administrative Simplification standards that appeared in the 
Transactions Rule (65 FR 50312), published on August 17, 2000, which 
predated the SBA changes noted above. In addition, all HIPAA 
regulations published to date have used the SBA size standards that 
existed at the time of the publication of the Transactions Rule. For 
this analysis, we use the current SBA small business size standards. 
Even though the SBA has raised the small business size standards, the 
revised size standards have no effect on the cost and benefit analysis 
for this proposal. The revised standards simply increase the number of 
health care providers that are classified as small businesses.
    One source of information about the health data information 
industry is Faulkner & Gray's Health Data Directory (CY 2000 edition). 
Using this resource, health care clearinghouses, billing companies, and 
software vendors may also be considered small entities. However, for 
the same reasons cited elsewhere, we do not have any cost data to 
determine if this rule would have a significant impact on small 
entities.
    In addition, section 1102(b) of the Act requires us to prepare a 
regulatory impact analysis if a rule may have a significant impact on 
the operations of a substantial number of small rural hospitals. This 
analysis must conform to the provisions of section 603 of the RFA. For 
purposes of section 1102(b) of the Act, we define a small rural 
hospital as a hospital that is located outside of a Core-Based 
Metropolitan Statistical Area and has fewer than 100 beds. Because 
these attachment standards are not mandatory for all health care 
providers, but rather only for those health care providers who conduct 
a transaction electronically for which the Secretary has adopted a 
standard, small rural hospitals can continue to operate as they do 
today, and we do not anticipate a significant financial and business 
impact on these covered entities. For a more detailed discussion of 
small rural hospitals, please refer to the Transactions Rule, 65 FR 
50312.
    Section 202 of the Unfunded Mandates Reform Act of 1995 (UMRA) (2 
U.S.C. 1501 et seq.) also requires that agencies assess anticipated 
costs and benefits before issuing any rule that may result in 
expenditures in any one year by State, local, or tribal governments, in 
the aggregate, or by the private sector, of $110 million. This proposed 
rule has been reviewed in accordance with the Unfunded Mandates Reform 
Act of 1995 and Executive Order 12875.
    In the Transaction Rule's impact analysis, State Medicaid agencies 
estimated that they could spend $10 million each to implement the 
entire set of HIPAA transactions. Since electronic claims attachments 
are only one component of the entire transaction set, and we believe 
that some of the programming completed for the current transactions 
will be useable for processing electronic health care claims 
attachments, we do not believe that the States, in aggregate, will 
exceed the $110 million UMRA expenditure threshold for these new 
attachment transactions.
    State Medicaid agencies, which are statutory health plans under 
HIPAA, currently require and use a variety of attachments to adjudicate 
claims. In order to validate the fiscal and operational impact of this 
rule, current data on the number and types of claims attachments for 
each State would be necessary, particularly whether the attachment 
types we name affect any significant percentage or number of Medicaid 
claims. We are aware of an industry wide survey that was conducted in 
the winter of 2005, which may provide some insight into this 
information for States, if the Medicaid agencies and Medicaid providers 
participated in the survey. In addition, during the comment period, we 
hope that State Medicaid agencies will provide such information.
    HHS estimated that the private sector would require expenditures in 
excess of $110 million to implement all of the transaction standards. 
Since electronic health care claims attachments are only one of the 
eight transactions, and since there are only six attachment types at 
this time, our assumption is that expenditures to meet just the 
electronic health care claims attachment requirements will not exceed 
the UMRA threshold for the private sector. Even if our assumption is 
incorrect, and the costs of implementing the electronic health care 
claims attachments standards exceed the UMRA threshold, we believe that 
anticipated benefits of the proposed rule justify the added costs.
    The anticipated benefits and costs of these proposed standards, and 
other issues raised in section 202 of the UMRA, are addressed later in 
this

[[Page 56016]]

section. In addition, under section 205 of the UMRA (2 U.S.C. 1535), 
having considered at least three alternatives for the transaction 
standard (X12 275 version 4010, IEEE, DICOM) and two options for the 
code sets (claims status and LOINC[supreg]), as outlined in the 
preamble to this rule and in the following analysis, HHS has concluded 
that this proposed rule is the most cost-effective alternative for 
implementing HHS's statutory objective of administrative 
simplification.
    Executive Order 13132 establishes certain requirements that an 
agency must meet when it promulgates a proposed rule (and subsequent 
final rule) that would, if finalized, impose substantial direct 
requirement costs on State and local governments, preempt State law, or 
otherwise have Federalism implications. Executive Order 13132 of August 
4, 1999, Federalism, published in the Federal Register on August 10, 
1999 (64 FR 43255), requires the opportunity for meaningful and timely 
input by State and local officials in the development of rules that 
have Federalism implications. The Department consulted with appropriate 
State and Federal agencies, including tribal authorities and Native 
American groups, as well as private organizations. These private 
organizations included WEDI and the DSMO coordinating committee.
    The Department has examined the effects of provisions in the 
proposed rule as well as the opportunities for input by the States to 
the proposed rule. The Federalism implications of the proposed rule are 
consistent with the provisions of the Administrative Simplification 
subtitle of HIPAA by which the Department was required by the Congress 
to promulgate standards for the interchange of certain health care 
information via electronic means, which standards, by statute, preempt 
contrary State law.
    The States were invited to participate in the electronic claims 
attachment standard development process from its beginning in 1994. 
During the early stages, a concept paper that set forth the 
transactions, code sets, and key issues being considered for the 
proposed rule was provided to the States for review and comment. Those 
comments have been considered in preparation of this proposed rule. The 
National Medicaid EDI HIPAA work group (NMEH) has a claims attachment 
subcommittee, which will be active in ensuring that each State is given 
the opportunity to provide input during the public comment period. The 
Department concludes that the policy in this proposed rule has been 
assessed in accordance with the principles, criteria, and requirements 
in Executive Order 13132; that this proposed rule is not inconsistent 
with that Order; that this proposed rule would not impose significant 
additional costs and burdens on the States; and that this proposed rule 
would not affect the ability of the States to discharge traditional 
State governmental functions.
1. Affected Entities (Covered Entities)
    All health plans, health care clearinghouses, and covered health 
care providers that transmit any health information in electronic form 
in connection with a claims attachment which use other electronic 
format(s), and all health care providers that decide to change from a 
paper format to an electronic process for claims attachments, would 
have to begin to use the ASC X12N 277--Health Care Claim Request For 
Additional Information and ASC X12N 275--Additional Information to 
Support a Health Care Claim or Encounter and the accompanying HL7 
specifications for requesting and submitting electronic health care 
claims attachments. Currently, there are no standardized electronic 
claim attachment formats in consistent use across the industry. Since 
health care providers have the option of continuing to submit paper 
attachment information, there would be little potential for disruption 
of claims processes and timely payments during a particular health 
plan's transition to the ASC X12N 277, ASC X12N 275, HL7 standards and 
LOINC[supreg] code set use. Implementation will simplify processing for 
attachments and reduce administrative expenses for covered health care 
providers. Health plans will be able to automate the processing of 
attachment information, thus reducing their labor costs and improving 
the accuracy of attachment responses from covered health care 
providers. The costs of implementing the X12 and HL7 standards with the 
LOINC[supreg] code set are generally one-time costs related to 
conversion. The systems upgrade costs for small covered health care 
providers, health plans, and health care clearinghouses will vary 
depending upon the capabilities of hardware and software systems in use 
at the time these changes are being made. Administrative costs may 
increase depending on the data entry and data conversion options 
selected in order to comply with the standard.
2. Effects of Various Options
    After ruling out certain versions of transactions based on 
limitations identified by early adopters of X12 transactions, we 
assessed the potential of the later versions of ASC X12N 277--Health 
Care Claim Request For Additional Information transaction; the ASC X12N 
275--Additional Information to Support a Health Care Claim or Encounter 
transaction; the HL7 CDA message standard; and the six HL7 AIS. These 
standards were measured against the key principles listed in this 
proposed rule: achieve the maximum benefit for the least cost; avoid 
incompatibility; be consistent with the other HIPAA standards; and be 
technologically independent of computer protocols used in HIPAA 
transactions. Specifically, the goal of improving the effectiveness and 
efficiencies of the health care system through electronic means is 
supported by these standards. We found that these transactions and 
specifications met all the principles, because once systems and 
operations are upgraded to send and receive the data in the new format 
and with predictable content, many other business processes will be 
improved.

B. Cost and Benefit Analysis

    [If you choose to comment on issues in this section, please include 
the caption ``COSTS AND BENEFITS'' at the beginning of your comments.]
1. General Assumptions, Limitations, and Scope
    Attachments to health care claims will be requested electronically 
by using the ASC X12N 277--Health Care Claim Request For Additional 
Information transaction which includes LOINC[supreg] codes to identify 
the supplemental claim information being requested. Similarly, the 
attachment response will be conveyed electronically by the ASC X12N 
275--Additional Information to Support a Health Care Claim or Encounter 
transaction, serving as an envelope for the HL7 message and Additional 
Information Specification. While an attachment can be sent at the same 
time as the original claim is submitted, based on instructions from the 
health plan, it will usually be sent in response to a specific request 
after a claim has been submitted. Accordingly, this analysis considers 
the request, the response, the HL7 message standard, and the six 
additional information specifications as an ``attachment package'' that 
cannot be subdivided for purposes of any financial analysis since they 
cannot logically be implemented as separate stand-alone transactions.
Limitations
    Most health plans, health care clearinghouses, and covered health 
care

[[Page 56017]]

providers were required to comply with the Transaction Rule standards 
in 2002, or 2003, depending on the entity type and the applicability of 
the Administrative Simplification Compliance Act (ASCA), which 
permitted certain covered entities to apply for an extension of the 
compliance date. Widespread implementation of the HIPAA Transaction 
Rule was further delayed when covered entities invoked contingency 
plans under an enforcement discretion strategy guidance document that 
had been issued by CMS. One of the results of these implementation 
delays is that industry-wide cost data could not be compiled for HHS to 
use in assessing the actual financial impact (that is, cost or savings 
projections) of implementing any of the original transactions.
    The lack of data available today regarding any industry wide HIPAA 
transaction costs or savings; on the current use of claims attachments; 
the costs of manual processes; or the impact of conducting any 
transactions electronically, imposes a significant limitation to any 
quantitative analysis. Therefore, in order to prepare this proposed 
rule, HHS used older available studies and anecdotal observations from 
the industry and SDOs. Since the analysis in the Transaction Rule 
specifically excluded costs and benefits for electronic health care 
claims attachments, it further highlighted the data limitations we were 
faced with for this analysis.
    HHS used the 1993 WEDI report coupled with conservative assumptions 
from the Transaction Rule to predict costs and savings at a high level. 
We solicit information from the industry regarding implementation costs 
for the current HIPAA transactions, in addition to: the frequency of 
claims attachments; the types of attachments currently being requested 
(by service and/or procedure); the workload associated with requesting 
attachment information and providing the response; the costs that may 
be incurred implementing new software, practice management systems, and 
other tools; as well as any other relevant cost data that could 
supplement this analysis. We also hope to receive information from 
WEDI, following their efforts to engage the industry in discussing 
Return on Investment (ROI) from HIPAA--an initiative expected to begin 
in the fall of 2005.
    The impact analysis in the August 2000 Transactions Rule assessed 
the expected costs and benefits associated with the Administrative 
Simplification regulations covering a time span of 10 years, beginning 
in 2002. That analysis did not include electronic attachments to health 
care claims because no standard was forthcoming at that time. However, 
electronic attachments are viewed as a minor incremental cost compared 
to the total cost assessed in the August 2000 Transactions Rule, 
because covered entities have readied their systems for the other X12 
transactions and will have ample experience with X12 by the time the 
final rule for electronic health care claims attachments is effective. 
The analysis here can be an adjunct to that which was provided in the 
Transactions Rule, since the volume of attachments is directly related 
to the volume of health care claims.
    As we note earlier, data and information about claims attachments 
was gleaned primarily from the 1993 WEDI report entitled: ``The 1993 
WEDI Report and Recommendations.'' Some other general data on claim 
volumes was gathered from a CY2000 publication from Health Data 
Management and anecdotally, from informal discussions with industry 
representatives of health plans and vendors. There were no surveys or 
proprietary data available from the BlueCross BlueShield Association 
(BCBSA), the American Medical Association (AMA), the American Hospital 
Association (AHA), America's Health Insurance Plans (AHIP), The 
Association for Electronic Health Care Transactions (AFEHCT), X12, HL7 
or any other professional organization or SDO.
    The 1993 study by WEDI suggested that 25 percent of all health care 
claims required support by an attachment or additional documentation. 
Though these data on attachments are over 10 years old, they are 
currently the only set of broad-based information available from the 
industry. We acknowledge that this 1993 statistic does not take into 
account changes that have occurred following implementation of the 
HIPAA Transaction and Privacy Rules, nor more recent health plan 
business rule changes for how claims are adjudicated and what 
attachments are now being requested. Nonetheless, these are the most 
comprehensive data available. If current attachment statistics exist, 
we hope the industry and/or its representatives will provide those data 
during the comment period.
    We also assume in this impact analysis that electronic health care 
claims attachments would not be implemented at all, and certainly not 
with uniform standards, in the absence of this rule. This assumption is 
based on direct industry comment, and current industry practice to 
date--very few attachments are being sent electronically today; and 
vendors, health plans and health care providers say that they will not 
move forward on this until the HIPAA standards are adopted. The early 
evidence from the current pilot bears this out, as the hospital 
providers have said that they will not undertake full scale 
implementation until the regulation is published.
    The following assumptions are based upon anecdotal comments by 
industry professionals, as well as the Department's general knowledge 
of present circumstances in the health care industry. Beyond our 
anecdotal information, and subsequent assumptions, the only available 
data we have for hospitals and physicians, indicates that their 
services represent over 50 percent of the claims submitted annually. 
Furthermore, their services are likely to be those most affected by the 
six electronic attachments proposed in this rule. One subject matter 
expert from a national health plan indicated that 50 percent of all 
claims attachments are likely to be represented by the six attachment 
types named here. We request comments and any data that will supplement 
these and all other assumptions in this section:
    <bullet> Few health care claims attachments are requested or 
submitted using an electronic format of any kind.
    <bullet> Preparation and processing of electronic claims 
attachments (requests and responses) will entail workload effort that 
is similar in complexity and duration as that associated with the 
preparation and processing of an electronic claim, for both health care 
providers and health plans.
    <bullet> The volume of unsolicited attachments accompanying 
original health care claims today is relatively small.
    <bullet> Health care providers will not all be equally impacted by 
the electronic claims attachment standards. Some health care provider 
types (for example, ambulance companies, providers of rehabilitation 
services, and hospitals or other facilities that operate emergency 
departments) are more likely to elect to conduct attachment 
transactions electronically because of the frequency of the requests. 
Other health care providers may decide to implement the transactions 
later, opting to continue providing requested information via paper-to-
paper fax or paper copies in the short term.
    The cost and benefit analysis is separated into various sub-
sections below. In addition, there is a section that discusses the 
financial impact of implementation covering a 5-year time span, from 
2007 to 2011. We use a five

[[Page 56018]]

year time span to match the remainder of the 10-year period that was 
used in the Transaction Rule; that analysis calculated costs and 
benefits through 2011.
2. Cost and Benefit Analysis for Health Plans
    a. Health plans may incur the following implementation costs:
    <bullet> Learning about and training staff on the new claims 
attachment standards, the X12 implementation guides, HL7 AIS booklets, 
and LOINC codes[supreg].
    <bullet> Programming systems to accommodate the new transaction 
types, messaging standards, and codes.
    <bullet> Installing LOINC[supreg] codes.
    <bullet> Mapping the LOINC[supreg] codes to the current attachment 
request reason codes.
    <bullet> Acquiring translator capability to process HL7 messages.
    <bullet> Telecommunication expansion.
    <bullet> Server expansion to retain electronic records.
    <bullet> Other potential software upgrades for browsing, 
translating, and validating, as well as internal controlling or 
messaging/routing functions.
    <bullet> Health care clearinghouse fees.
    <bullet> Acquiring XML expertise.
    <bullet> Changing business practices and retraining staff to 
accommodate electronic attachments versus paper attachments and 
records.
    These items should not represent unusual expenditures, as some of 
the same kinds of tasks will have been accomplished through HIPAA 
Transaction compliance activities. We also understand that several 
firms that provide translators already have HL7 capabilities in their 
HIPAA-capable translators.
    b. Health plan savings could accrue from:
    <bullet> Using standardized attachment requests.
    <bullet> Receiving consistent response information.
    <bullet> Eliminating paper documents and the manual efforts to 
request, receive, process, and handle the documents.
    <bullet> Reducing postage costs.
    <bullet> The ability to electronically adjudicate health care 
claims supported by an electronically submitted attachment.
    We solicit industry input as to the anticipated implementation 
costs for technical, business and operational changes that may be 
required, as well as anticipated savings.
3. Cost and Benefit Analysis for Covered Health Care Providers
    a. Covered health care providers may incur the following 
implementation costs:
    <bullet> Learning about and training staff on the new electronic 
claims attachment standards, the X12 implementation guides, HL7 AIS and 
LOINC[supreg] codes.
    <bullet> Programming systems to accommodate the new transaction 
types, messaging standards, and codes.
    <bullet> Mapping the LOINC[supreg] codes to current proprietary 
codes.
    <bullet> Installing LOINC[supreg] codes.
    <bullet> Software and/or vendor fees.
    <bullet> Practice management system vendor fees and charges.
    <bullet> Health care clearinghouse fees.
    <bullet> Changing business practices and re-training staff to enter 
different data, perform different functions, conduct different 
procedures.
    <bullet> Purchasing or expanding server space.
    <bullet> Acquiring XML expertise.
    <bullet> Purchasing or enhancing translator software.
    <bullet> Telecommunication expansion.
    <bullet> Utility conversion programs.
    Again, many of these items should not represent unusual 
expenditures for covered health care providers and/or their business 
associates, as some of the same kinds of tasks will have been 
accomplished through HIPAA transactions compliance activities to date. 
Small practices that have practice management or software maintenance 
agreements are likely to be provided with appropriate software upgrades 
at modest costs, in view of the market competition for that business 
sector. Covered health care providers with their own EDI software may 
incur some added costs to obtain HL7 capabilities for their 
translators. The costs for covered health care providers to implement 
this proposal for electronic attachments to health care claims are not 
considered to be significant and many implementation costs for 
transactions were estimated to be one-time expenditures rather than 
recurring ones.
    b. Savings could accrue from the following:
    <bullet> Use of standardized, predictable attachments, and formats 
rather than numerous proprietary forms associated with individual 
health plan requirements.
    <bullet> Reduction of paper documents and manual efforts to 
receive, process, and respond to requests.
    <bullet> Reduction in postage and mailing costs.
    <bullet> Reduction in labor costs.
    <bullet> Minimization of ambiguities, which frequently result in 
multiple communication exchanges before the desired information is 
correctly identified and provided.
    <bullet> Application of automation by covered health care providers 
with electronic record systems to support the rapid retrieval of 
information, and respond to requests.
    <bullet> More accurate tracking and receipt of attachment 
information, resulting in fewer lost documents.
    <bullet> Receipt of payment more quickly.
    We solicit industry input as to the anticipated implementation 
costs for technical, business and operational changes that may be 
required, as well as on anticipated savings.
    We do not make any assumptions about the fiscal impact to 
clearinghouses, because there was no baseline data in the 1993 WEDI 
report, and no current data on their costs for implementing the HIPAA 
transactions over the past several years. Nonetheless, we believe that 
costs would be similar to those incurred by both health plans and 
health care providers, because of the programming, mapping, translating 
and storage functions for which they may be responsible. We anticipate 
that AFEHCT, HIMSS and AHIMA, to name a few associations, will compile 
data on costs and potential savings for their constituents in order to 
avoid concerns over proprietary and competitive data. Such deidentified 
data may be useful for comments on this proposal. A vendor forum held 
in August 2005 may encourage analysis within the industry itself.
4. Cost and Benefit Estimates
    a. Costs of Implementation: The transaction standards proposed in 
this rule are in the same family of X12 standards as the other HIPAA-
mandated transactions. Therefore, any new activities necessary to 
implement the electronic health care claims attachment transactions 
should be consistent with what has already been done, and may be 
largely in place. The HL7 message standard is used in many clinical 
settings already, and laboratories and some other health care 
organizations use the LOINC[supreg] codes.
    While the Department had estimated costs in the impact analysis for 
the other transactions adopted under the Transaction Rule, we believe 
that covered entities now have data regarding the actual costs for this 
implementation, and are themselves in the best position to provide 
current data regarding the implementation costs of this proposal.
    The 1993 WEDI report did not provide data specific to claims 
attachments, and no reports since that time have attempted to quantify 
volumes or costs. The report was extremely limited in data for health 
plans on this subject.

[[Page 56019]]

    In light of existing limitations, we repeat our solicitation for 
implementation cost information from affected entities. We are 
providing high-level cost and savings estimates in this proposed rule 
based on the 1993 data and the final Transactions Rule. Anecdotally, we 
have heard from industry representatives that implementing the 
standards for electronic health care claims attachments would likely 
cost 10 percent of what covered entities expended on their overall 
HIPAA implementation efforts. We use this figure for our cost estimates 
below. It is the only current figure available, following extensive 
research and discussion over the past 18 months. If the industry 
submits sufficiently robust data to allow for a reasonable analysis of 
costs and savings, updated estimates may be provided in the final rule 
on these standards.
    The tables below illustrate the estimated costs for health plans 
and health care providers to implement electronic health care claims 
attachments.

                                                    Table 3.--Five Year Costs From Transactions Rule
                                                                      [In billions]
--------------------------------------------------------------------------------------------------------------------------------------------------------
               Costs                              2007                              2008                             2009                 2010     2011
--------------------------------------------------------------------------------------------------------------------------------------------------------
Providers.........................  $1.2............................  $1.2...........................  $1.1...........................  .......  .......
Health plans......................  1.2.............................  1.2............................  1.1............................  .......  .......
10% of costs......................  120 million.....................  120 million....................  110 million....................  .......  .......
--------------------------------------------------------------------------------------------------------------------------------------------------------

    We used Table 4 from the Transactions Rule to demonstrate an 
estimate of implementation costs for electronic health care claims 
attachments for both health plans and providers. Using the recent 
informal industry estimate that implementation of the electronic health 
care claims attachments standards would cost 10 percent of what covered 
entities spent on overall HIPAA implementation yields an estimate of 
$120 million in each of the first 2 years for both sectors. The first 3 
years are deemed to have the implementation costs, while future 
expenses are related to operations, and not reflected in implementation 
estimates.
b. Benefits of Implementation
    In order to estimate the benefits of electronic claims attachments, 
we applied the methodology described below. According to Gartner, Inc., 
a management research and consulting firm, 5.1 billion health care 
claims were submitted in the year 2000. Furthermore, of the 5.1 billion 
health claims submitted, Gartner believes that 486 million claims were 
from hospitals and 1.9 billion claims were from physicians. This 
translates to approximately 10 percent and 38 percent of all health 
claims being submitted by hospitals and physicians respectively.
    To predict a trend for total annual physician and hospital claims 
beyond the year 2000 figures provided by the consulting firm, we used 
the CMS growth rates of Medicare Parts A & B claims from 2001 through 
2005 (listed in the CMS Justification of Estimates for Appropriations 
Committees Fiscal Year 2005 Report (DHHS)) and applied those as the 
associated growth rates for our physician and hospital health claims 
model for 2001 through 2005. Furthermore, for the years 2006 through 
2011, we assumed the continued 2005 Parts A and B average growth rate 
of 4 percent for physician and hospital claims. Table 4 below, Total 
Health Care Claims (in millions), presents a low-high sensitivity range 
for the number of physician and hospital claims for years 2007 through 
2011. Our model uses 2007 as the first year; since this is the 
anticipated year covered entities will need to be compliant with the 
regulation.
    As stated earlier, this proposed rule uses a 5-year period for its 
analysis, in order to synchronize its potential implementation schedule 
with the date line established in the original Transactions Rule. Since 
the initial compliance date for the Transactions Rule was 2002, the end 
date for that analysis was 2011. In this proposed rule, we begin our 
estimates in 2007, and end in 2011.
    The Table below (Table 4) reflects the estimated number of claims 
for years 2007 through 2011. As part of a sensitivity analysis, the 
high numbers reflect a 30 percent increase in the claims count for the 
same years.

                          Table 4.--Total Health Care Claims--Physicians and Hospitals
----------------------------------------------------------------------------------------------------------------
                                       2007            2008            2009            2010            2011
                                 -------------------------------------------------------------------------------
                                    Low    High     Low    High     Low    High     Low    High     Low    High
----------------------------------------------------------------------------------------------------------------
Physician Claims................   2,832   3,682   2,946   3,829   3,064   3,983   3,186   4,142   3,314   4,308
Hospital Claims.................     708     921     736     957     766     996     797   1,035     828   1,077
----------------------------------------------------------------------------------------------------------------

    The 1993 WEDI Report concluded that 25 percent of all health care 
claims require some sort of additional documentation, or attachment. 
Current anecdotal estimates are that 50 percent of all attachments are 
represented by those included in this proposed rule. As these are the 
only data available, we assumed 50 percent of the rate of 25 percent 
for attachments on our estimated physician and hospital health claims 
for each year from 2007 through 2011; or 12.5 percent of all claims. We 
know this results in a large number of potential claims attachments; 
and this number is undoubtedly higher than the number of claims that 
might actually require one of the six electronic attachment types 
proposed here. Nonetheless, we do not have any hard industry data on 
what percent of claims are submitted for the six service and procedure 
electronic claims attachment types proposed here, nor what volumes 
these represent of the total number of attachment types required by a 
significant number of health plans. Again, we solicit data from health 
care providers and health plans on this topic.

[[Page 56020]]



                    Table 5.--Total Health Care Claims Attachments--Physicians and Hospitals
                                                  [In millions]
----------------------------------------------------------------------------------------------------------------
                                       2007            2008            2009            2010            2011
                                 -------------------------------------------------------------------------------
                                    Low    High     Low    High     Low    High     Low    High     Low    High
----------------------------------------------------------------------------------------------------------------
Attachments volume: 50 percent       354     460     368     458     383     498     398     518     414     538
 of the estimated 25 percent of
 all Physician Claims...........
Attachments volume: 50 percent        89     115      92     119      96     124     100     129     104     135
 of the estimated 25 percent of
 all Hospital Claims............
----------------------------------------------------------------------------------------------------------------

    Table 5 shows the number of electronic health care claims 
attachments that could potentially be required for health care claims 
(in millions), in spite of the increase in electronic data exchange 
through the other HIPAA transactions. The data are shown from a low 
range to a high range to demonstrate that the volumes are large in 
either case.
    According to the 1993 WEDI Report, operational savings per 
transaction through the use of electronically submitted claims varies 
between $1.01 to $1.96 for physicians and $0.64 to $1.07 for hospitals, 
net of transaction costs (assumed to be up to $0.50 per claim). WEDI 
believed that conversion from a paper-based process to an electronic 
transaction process would include savings on labor costs as a result of 
standardized information and procedures, and a decrease in non-
personnel expenses such as postage, telephone, and forms. Other savings 
may accrue to covered health care providers because they will 
experience a reduction in the days between claims submission and claims 
payment. Since there was no other quantitative information from the 
industry outlining the costs and benefits of the transition to EDI, we 
constructed our estimates by using the WEDI operational savings figures 
above in our assumptions and calculations. We note here that the WEDI 
report did not estimate a per transaction cost for electronic 
attachments or medical records exchange between a health care provider 
and a health plan. WEDI provided an estimate of a net savings potential 
of $1.5 billion in labor from copying and shipment of medical records 
between health care providers, though not for the purpose of claims 
attachments.
    For physicians, we assumed the WEDI operational savings of $1.01 
within our low category and $1.96 within our high category for each of 
the 5-year calculations. For hospitals, we assumed the WEDI operational 
savings of $0.64 within our low category and $1.07 within our high 
category for each of the 5-year calculations. We do not provide any 
savings assumptions for health plans, as no relevant data were 
available through any reports shared with us. We hope that the health 
plan industry will submit such data to HHS during the comment period. 
We also note here that operational savings calculations include costs 
and savings (costs less savings equal operational savings with this 
methodology). In this proposed rule, we attempt to reflect cost and 
savings estimates based on available research as well as current 
informal and anecdotal input from industry subject matter experts.

     Table 6.--Operational Savings From Electronic Health Care Claims Attachments--Physicians and Hospitals
                                                  [In millions]
----------------------------------------------------------------------------------------------------------------
                                       2007            2008            2009            2010            2011
                                 -------------------------------------------------------------------------------
                                    Low    High     Low    High     Low    High     Low    High     Low    High
----------------------------------------------------------------------------------------------------------------
Physicians......................     358     902     372     938     387     976     402   1,015     418   1,055
Hospitals.......................      57     123      59      98      61     133      64     138      66     144
                                 ---------
    Operational Savings.........     415   1,025     431   1,036     448   1,109     466   1,153     485   1,199
----------------------------------------------------------------------------------------------------------------

    Table 6, Operational Savings from Electronic Health Care Claims 
Attachments (in $ millions), shows the total operational savings that 
could be achieved. The calculations for number of claims attachments 
are made using the figures in Table 5 and the WEDI savings assumptions 
for physicians and hospitals.
    Next, we assumed a fairly optimistic rate of adoption for the 
electronic health care claims attachment transactions, because, based 
on Medicare's experience, two years past the compliance date for the 
original set of transactions, 99 percent of the claims being submitted 
are in HIPAA compliant formats. We believe that most covered entities 
will choose to implement the human variant option first, which does not 
have significant technical complexities. Therefore, we use the 
following conversion factors, or ``adoption rates'' from paper to 
electronic attachments: 5 percent for 2007, 20 percent for 2008, 50 
percent for 2009, 75 percent for 2010, and 90 percent for 2011. For 
example, using the low end of attachment volumes found in Table 5, 5 
percent of the 354 million attachments (total low) for physician claims 
are expected to be converted from paper to electronic processing by the 
end of the year 2007. We used lower conversion rates for the first few 
years of implementation because not all paper attachments can 
automatically be moved to an electronic process; and only six 
attachment types have approved HL7 specifications at present. The 
conversion factors were based on the 1993 WEDI report, which as has 
been stated, remains the only available data source. However, as 
mentioned earlier, HIPAA compliance and adoption rates are promising, 
just 2 years after the compliance date.

[[Page 56021]]



     Table 7.--Operational Savings From Electronic Health Care Claims Attachments Based on Specific Rates of
                                                   Conversion
                                                  [In millions]
----------------------------------------------------------------------------------------------------------------
                                    2007  (@ 5      2008  (@ 20     2009  (@ 50     2010  (@ 75     2011  (@ 90
                                      percent         percent         percent         percent         percent
                                    conversion)     conversion)     conversion)     conversion)     conversion)
                                 -------------------------------------------------------------------------------
                                    Low    High     Low    High     Low    High     Low    High     Low    High
----------------------------------------------------------------------------------------------------------------
Total Operational Savings for         21      51      86     213     224     554     349     865     436   1,079
 each conversion factor.........
----------------------------------------------------------------------------------------------------------------

    Table 7 represents operational savings from electronic health care 
claims attachments using the estimated conversion factors. We took the 
operational savings figures shown in Table 6 and applied the conversion 
rates for each of the 5 years.
    In its A-4 circular, the Office of Management and Budget (OMB) 
requires all cost-benefit analyses to provide estimates of net benefits 
using both 3 percent and 7 percent discount rates (Office of Management 
and Budget, Circular A-4, September 17, 2003). Table 8, 5-Year (2007 
through 2011) Total Operational Savings (in $ millions), shows the 
potential savings that could be attained for physicians and hospitals 
when using the standard for electronic attachments. These figures take 
into account both undiscounted and discounted (3 percent and 7 percent) 
amounts, respectively, as well as annualized savings.

        Table 8.--Five-Year (2007 Through 2011) Operational Savings ($ Millions)--Discounted (3 Percent and 7 Percent) and Annualized Projections
                                                                      [In millions]
--------------------------------------------------------------------------------------------------------------------------------------------------------
                                                                      Total savings         Total savings      Annualized savings    Annualized savings
                                                                    (discounted at 3      (discounted at 7      (discounted at 3      (discounted at 7
                                                                        percent)              percent)              percent)              percent)
                                                                 ---------------------------------------------------------------------------------------
                                                                     Low        High       Low        High       Low        High       Low        High
--------------------------------------------------------------------------------------------------------------------------------------------------------
Total Operational Savings Achieved Using Conversion Factor for        1,023      2,532        915      2,264        205        506        183        453
 Paper to Electronic Attachments................................
--------------------------------------------------------------------------------------------------------------------------------------------------------

    As final explanation of our use of the older formal data, and 
current informal estimates, in preparing this proposed rule we 
conducted extensive research to obtain up-to-date information. Data 
regarding paper versus electronic claims were not available beyond the 
year 2000, perhaps in preparation for HIPAA and the assumption that 
data would be available post implementation. We used a variety of other 
resources, including Medicare claims data, external research 
organizations such as Gartner, and contractors to estimate the number 
of electronic health care claims attachments, conversion rates, 
operational savings for each conversion factor, and total operation 
savings. The newly established Office of the National Coordinator for 
Health Information Technology (ONCHIT) also did not have current data 
that have provided any further insight for the impact analysis. Studies 
pertaining to the adoption of electronic medical record systems (EMR or 
EHR) and the integration of those with financial and administrative 
systems may be able to provide some useful information for the final 
rule in a few years time, but there is none available today related to 
electronic health care claims attachments.
    OMB requires that all agencies provide estimates using net present 
values. OMB recommends the use of 3 percent and 7 percent discount 
rates based on current cost of capital. The discounted totals in Table 
8 are based on these rates, and begin in 2007.
5. Conclusions
    As shown in Table 3, Costs Associated with Electronic Health Care 
Claims Attachments, the estimated costs are $120 million dollars for 
the first 2 years, and slightly less in the third year. With regard to 
operational savings, the range is from $414 million to $1.1 billion 
over five years. In calendar year 2007, maximum operational savings, 
for both physicians and hospitals, is estimated to range between $414 
million to $1 billion.
    When we use the term ``conversion rate,'' we use it to mean the 
transition from a paper-based system to an EDI based process. As table 
7 shows, using the assumed first year conversion rate of 5 percent 
yields an estimated total operational savings range of $21 million to 
$51 million. For 2008, the estimated operational savings, for both 
physicians and hospitals, ranges between $431 million and $1 billion. 
Using the assumed second year conversion rate of 20 percent could yield 
an estimated total operational savings range of $86 million to $213 
million. For 2009, the estimated operational savings, for both 
physicians and hospitals, ranges between $448 million and $1.1 billion. 
Using the assumed third year conversion rate of 50 percent yields an 
estimated total operational savings range of $224 million to $554 
million. In 2010, the estimated operational savings, for both 
physicians and hospitals, ranges between $466 million and $1.1 billion. 
Using the assumed fourth year conversion rate of 75 percent yields an 
estimated operational savings range of $349 million to $865 million. In 
2011, the estimated total maximum operational savings, for both 
physicians and hospitals, ranges between $485 million and $1 billion. 
Using the assumed fifth year conversion rate of 90 percent yields an 
estimated total operational savings range of $436 million to $1 
billion.
    The 5-year (2007 through 2011) total operational savings presented 
in Table 8

[[Page 56022]]

shows a total operational savings range, for physicians and hospitals, 
of $1 billion to $2.5 billion, using the 3 percent discounted rate. 
While using the 7 percent discounted rate translates to a total 
operational savings range of $915 million to $2.2 billion. In addition, 
this table shows an annualized operational savings range, for 
physicians and hospitals, between $205 million and $506 million using 
the 3 percent discounted rate, and between $183 million and $453 
million using the 7 percent discounted rate.
    In accordance with the provisions of Executive Order 12866, this 
proposed rule has been reviewed by the Office of Management and Budget.

C. Guiding Principles for Standard Selection

1. Overview
    The implementation teams charged with designating standards under 
the statute have defined, with significant input from the health care 
industry, a set of common criteria for evaluating potential standards. 
These criteria were based on direct specifications in the HIPAA, the 
purpose of the law, those principles that support the regulatory 
philosophy set forth in Executive Order 12866 of September 30, 1993, 
and the PRA of 1995. In order to be designated as a standard, a 
proposed standard should do the following:
    <bullet> Improve the efficiency and effectiveness of the health 
care system by leading to cost reductions for, or improvements in, 
benefits from electronic HIPAA health care transactions. This principle 
supports the regulatory goals of cost-effectiveness and avoidance of 
burden.
    <bullet> Meet the needs of the health data standards user 
community, particularly covered health care providers, health plans, 
and health care clearinghouses. This principle supports the regulatory 
goal of cost-effectiveness.
    <bullet> Be consistent and uniform with the other HIPAA standards 
(that is, their data element definitions and codes and their privacy 
and security requirements) and, secondarily, with other private and 
public sector health data standards. This principle supports the 
regulatory goals of consistency and avoidance of incompatibility, and 
it establishes a performance objective for the standard.
    <bullet> Have low additional development and implementation costs 
relative to the benefits of using the standard. This principle supports 
the regulatory goals of cost-effectiveness and avoidance of burden.
    <bullet> Be supported by an ANSI-Accredited Standards Developing 
Organization or other private or public organization that would ensure 
continuity and efficient updating of the standard over time. This 
principle supports the regulatory goal of predictability.
    <bullet> Have timely development, testing, implementation, and 
updating procedures to achieve administrative simplification benefits 
faster. This principle establishes a performance objective for the 
standard.
    <bullet> Be technologically independent of the computer platforms 
and transmission protocols used in HIPAA health transactions, except 
when they are explicitly part of the standard. This principle 
establishes a performance objective for the standard and supports the 
regulatory goal of flexibility.
    <bullet> Be precise and unambiguous but as simple as possible. This 
principle supports the regulatory goals of predictability and 
simplicity.
    <bullet> Keep data collection and paperwork burdens on users as low 
as is feasible. This principle supports the regulatory goals of cost-
effectiveness and avoidance of duplication and burden.
    <bullet> Incorporate flexibility to adapt more easily to changes in 
the health care infrastructure (such as new services, organizations, 
and provider types) and information technology. This principle supports 
the regulatory goals of flexibility and encouragement of innovation.
    We believe that the standards being proposed in this regulation 
meet the requirements of these guidelines.
2. General
    Converting to any standard would result in one-time conversion 
costs for covered health care providers, health care clearinghouses, 
and health plans. Some covered health care providers and health plans 
would incur those costs directly and others may incur them in the form 
of a fee from health care clearinghouses or, for covered health care 
providers, other agents such as practice management and software system 
vendors. We do not include estimated costs to health care 
clearinghouses in our analysis, since these costs are incurred on 
behalf of covered health care providers and health plans, and are 
ultimately borne by them. Including health care clearinghouse costs in 
this analysis would therefore count those costs twice.
    We also do not include estimated costs for health plans in this 
analysis, because no relevant data were available. The lack of data 
overall is discussed in the section called ``limitations.''
    The standards named in this proposed rule compare favorably with 
typical ASC X12 and HL7 standards and code sets in terms of simplicity, 
ease of use and cost. Covered entities have a variety of ways in which 
they can choose to send and/or receive an ASC X12 transaction or HL7 
message, including internal reprogramming of their own systems, 
contracting with vendors and purchasing off-the-shelf translator, or 
interface engine programs.
    The selection of the LOINC[supreg] code set for conveying 
meaningful information between trading partners represents another 
opportunity to control user costs, since this code set is available for 
use without payment of licensing fees.

List of Subjects in 45 CFR Part 162

    Administrative practice and procedure, Electronic transactions, 
Health facilities, Health insurance, Hospitals, Incorporation by 
reference, Medicare, Medicaid, Reporting and recordkeeping 
requirements.

    For the reasons set forth in the preamble, the Department of Health 
and Human Services proposes to amend 45 CFR subtitle A, subchapter C, 
part 162 to read as follows:

PART 162--ADMINISTRATIVE REQUIREMENTS

    1. The authority citation for part 162 is revised to read as 
follows:

    Authority: 42 U.S.C. 1320d-1320d-8, as amended, and sec. 264 of 
Pub. L. 104-191, 110 Stat. 2033-2034 (42 U.S.C. 1320d-2 (note)).

    2. In Sec. 162.103, the introductory text to the section is 
republished, and a definition for ``LOINC[supreg]'' is added in 
alphabetical order to read as follows:


Sec.  162.103  Definitions.

    For purposes of this part, the following definitions apply:
* * * * *
    LOINC[supreg] stands for Logical Observation Identifiers Names and 
Codes.
* * * * *
    3. In Sec. 162.920, the following changes are made:
    A. The section heading is revised.
    B. The introductory text is revised.
    C. New paragraph (a)(10) is added.
    D. New paragraph (a)(11) is added.
    E. New paragraph (c) is added.
    The changes read as follows:


Sec.  162.920  Availability of implementation specifications and 
guides.

    A person or an organization may directly request copies of the 
implementation standards described in subparts I through S of this 
part, from the publishers listed in this section. The Director of the 
Office of the Federal

[[Page 56023]]

Register approves the implementation specifications and guides 
described in this section for incorporation by reference in subparts I 
through S of this part in accordance with 5 U.S.C. 552(a) and 1 CFR 
part 51. The implementation specifications and guides described in this 
paragraph are also available for inspection by the public at the 
Centers for Medicare & Medicaid Services, 7500 Security Boulevard, 
Baltimore, Maryland 21244 or at the National Archives and Records 
Administration (NARA). For information on the availability of this 
material at NARA, call 202-741-6030, or go to: http://www.archives.gov/federal_register/code_of_federal_regulations/ibr_locations.html. 
Copy requests must be accompanied by the name of the standard, number, 
if applicable, and version number. Implementation specifications and 
guides are available for the following transactions:
    (a) ASC X12N specifications. * * *
    (10) The ASC X12N 277--Health Care Claim Request for Additional 
Information, Version 4050 (004050X150), May 2004, Washington Publishing 
Company as referenced in Sec. 162.1915.
    (11) The ASC X12N 275--Additional Information to Support a Health 
Care Claim or Encounter, Version 4050 (004050X151), May 2004, 
Washington Publishing Company as referenced in Sec. 162.1925.
* * * * *
    (c) HL7 specifications. (1) The HL7 CDAR1AIS0000R021 Additional 
Information Specification Implementation Guide, Release 2.1 (based on 
HL7 CDA Release 1.0), May 2004, Health Level Seven, Inc. The AIS 
Implementation Guide for the HL7 standard may be obtained from Health 
Level Seven, Inc., 3300 Washtenaw Avenue, Suite 227, Ann Arbor, MI 
48104-4250, or via the Internet at http://www.hl7.org; or from the 
Washington Publishing Company, PMB 161, 5284 Randolph Road, Rockville, 
MD 20852, or via the Internet at http://www.wpc-edi.com/.
    (2) The HL7 Additional Information Specifications for each of the 
six attachments listed in Sec. 162.1915 and Sec. 162.1925 may be 
obtained from Health Level Seven, Inc., 3300 Washtenaw Avenue, Suite 
227, Ann Arbor, MI 48104-4250, or via the Internet at http://
www.hl7.org; or from Washington Publishing Company, PMB 161, 5284 
Randolph Road, Rockville, MD 20852, or via the Internet at  http://www.wpc-edi.com/. The six HL7 AIS documents are:
    (i) Ambulance services information: The CDAR1AIS0001R021 Additional 
Information Specification 0001, Ambulance Service Attachment, Release 
2.1, based on HL7 CDA Release 1.0, May 2004, as referenced in 
Sec. 162.1915(b)(1) and Sec. 162.1925(c)(1).
    (ii) Emergency department information: The CDAR1AIS0002R021 
Additional Information Specification 0002: Emergency Department 
Attachment, Release 2.1, based on HL7 CDA Release 1.0, May 2004, as 
referenced in Sec. 162.1915(b)(2) and Sec. 162.1925(c)(2).
    (iii) Rehabilitation services information: The CDAR1AIS0003R021. 
Additional Information Specification 0003: Rehabilitation Services 
Attachment, Release 2.1, based on HL7 CDA Release 1.0, May 2004, as 
referenced in Sec. 162.1915(b)(3) and Sec. 162.1925(c)(3).
    (iv) Clinical reports information: The CDAR1AIS0004R021 Additional 
Information Specification 0004: Clinical Reports Attachment, Release 
2.1, based on HL7 CDA Release 1.0, May 2004, as referenced in 
Sec. 162.1915(b)(4) and Sec. 162.1925(c)(4).
    (v) Laboratory results information: The CDAR1AIS0005R021 Additional 
Information Specification 0005: Laboratory Results Attachment, Release 
2.1, based on HL7 CDA Release 1.0, May 2004, as referenced in 
Sec. 162.1915(b)(5) and Sec. 162.1925(c)(5).
    (vi) Medications information: The CDAR1AIS0006R021 Additional 
Information Specification 0006: Medications Attachment, Release 2.1, 
based on HL7 CDA Release 1.0, May 2004, as referenced in 
Sec. 162.1915(b)(6) and Sec. 162.1925(c)(6).
    (3) The LOINC[supreg] Modifier Codes booklet ``for use with ASC 
X12N 277 Implementation Guides when requesting Additional 
Information,'' is available from Washington Publishing Company, PMB 
161, 5284 Randolph Road, Rockville, MD 20852, or via the Internet at 
http://www.wpc-edi.com/.
    4. In Sec. 162.1002, paragraph (c) is added to read as follows:


Sec.  162.1002  Medical data code sets.

* * * * *
    (c) For the period beginning [24 months after the effective date of 
the final rule published in the Federal Register]: Logical Observation 
Identifiers Names and Codes[supreg] (LOINC[supreg]), as maintained and 
distributed by the Regenstrief Institute and the LOINC[supreg] 
Committee. The LOINC[supreg] database may be obtained from the 
Regenstrief Institute Web site at the following Internet address: 
http://www.regenstrief.org/loinc/loinc.htm. Users without access to the 
Internet may obtain the LOINC[supreg] database from the Regenstrief 
Institute, c/o LOINC[supreg], 1050 West Wishard Blvd., Indianapolis, IN 
46202.
    5. A new subpart S is added to part 162 to read as follows:
Subpart S--Electronic Health Care Claims Attachments
Sec.
162.1900 Definitions.
162.1905 Requirements for covered entities.
162.1910 Electronic health care claims attachment request 
transaction.
162.1915 Standards and implementation specifications for the 
electronic health care claims attachment request transaction.
162.1920 Electronic health care claims attachment response 
transaction.
162.1925 Standards and implementation specifications for the 
electronic health care claims attachment response transaction.
162.1930 Initial compliance dates for the electronic health care 
claims attachment response and electronic health care claims 
attachment request transaction standards.

Subpart S--Electronic Health Care Claims Attachments


Sec.  162.1900  Definitions.

    Ambulance services means health care services provided by land, 
water, or air transport and the procedures and supplies used during the 
trip by the transport personnel to assess, treat or monitor the 
individual until arrival at the hospital, emergency department, home or 
other destination. Ambulance documentation may also include non-
clinical information such as the destination justification and ordering 
practitioner.
    Attachment information means the supplemental health information 
needed to support a specific health care claim.
    Clinical reports means reports, studies, or notes, including tests, 
procedures, and other clinical results, used to analyze and/or document 
an individual's medical condition.
    Emergency department means a health care facility or department of 
a hospital that provides acute medical and surgical care and services 
on an ambulatory basis to individuals who require immediate care 
primarily in critical or life-threatening situations.
    Laboratory results means the clinical information resulting from 
tests conducted by entities furnishing biological, microbiological, 
serological, chemical, immunohematological, hematological, biophysical, 
cytological, pathology, or other examinations of materials from the 
human body.
    Medications means those drugs and biologics that the individual is 
already

[[Page 56024]]

taking, that are ordered for the individual during the course of 
treatment, or that are ordered for an individual after treatment has 
been furnished.
    Rehabilitation services means those therapy services provided for 
the primary purpose of assisting in an individual's rehabilitation 
program of evaluation and services. These services are: Cardiac 
rehabilitation, medical social services, occupational therapy, physical 
therapy, respiratory therapy, skilled nursing, speech therapy, 
psychiatric rehabilitation, and alcohol and substance abuse 
rehabilitation.


Sec.  162.1905  Requirements for covered entities.

    When using electronic media to conduct a health care claims 
attachment request transaction or a health care claims attachment 
response transaction, a covered entity must comply with the applicable 
standards of this subpart if:
    (a) Information not contained in a health care claim is needed for 
the adjudication of that health care claim; and
    (b) The health care claim is for one or more of the following types 
of services:
    (1) Ambulance services;
    (2) Emergency department services;
    (3) Rehabilitation services; or
    (c) The additional information requested is for one or more of the 
following types of information:
    (1) Clinical reports;
    (2) Laboratory results; or
    (3) Medications.


Sec.  162.1910  Electronic health care claims attachment request 
transaction.

    (a) The health care claims attachment request transaction is the 
transmission, from a health plan to a health care provider, of a 
request for attachment information to support the adjudication of a 
specific health care claim. A health plan may make such a request--
    (1) Upon receipt of the health care claim;
    (2) In advance of submission of the health care claim; or
    (3) Through instructions for a specific type of health care claim 
which permit a health care provider to submit attachment information on 
an unsolicited basis each time such type of claim is submitted.
    (b) If a health plan conducts a health care claims attachment 
request transaction using electronic media and the attachment 
information requested is of a type described at Sec. 162.1905 , the 
plan must conduct the transaction in accordance with the appropriate 
provisions of Sec. 162.1915.
    (c) A health plan that conducts a health care claims attachment 
request transaction using electronic media, must submit complete 
requests and identify in the transaction, all of the attachment 
information needed to adjudicate the claim, which can be requested by 
means of the transaction.
    (d) The health care claims attachment request transaction sent 
using electronic media, is comprised of two component parts:
    (1) The general request structure that identifies the related 
claim; and
    (2) The LOINC[supreg] codes and LOINC[supreg] modifiers identifying 
the attachment information being requested.


Sec.  162.1915  Standards and implementation specifications for the 
electronic health care claims attachment request transaction.

    The Secretary adopts the following standards and implementation 
specifications for the electronic health care claims attachment request 
transaction:
    (a) The ASC X12N 277--Health Care Claim Request for Additional 
Information, Version 4050, May 2004, Washington Publishing Company, 
004050X150 (incorporated by reference in Sec. 162.920).
    (b) The following HL7 AIS documents to convey the LOINC[supreg] 
codes that identify the attachment type and specific information being 
requested--
    (1) Ambulance services information: The CDAR1AIS0001R021 Additional 
Information Specification 0001, Ambulance Service Attachment, Release 
2.1, based on HL7 CDA Release 1.0 (incorporated by reference in 
Sec. 162.920);
    (2) Emergency department information: The CDAR1AIS0002R021 
Additional Information Specification 0002: Emergency Department 
Attachment, Release 2.1, based on HL7 CDA Release 1.0 (incorporated by 
reference in Sec. 162.920);
    (3) Rehabilitation services information: The CDAR1AIS0003R021. 
Additional Information Specification 0003: Rehabilitation Services 
Attachment, Release 2.1, based on HL7 CDA Release 1.0 (incorporated by 
reference in Sec. 162.920);
    (4) Clinical reports information: The CDAR1AIS0004R021 Additional 
Information Specification 0004: Clinical Reports Attachment, Release 
2.1, based on HL7 CDA Release 1.0 (incorporated by reference in 
Sec. 162.920);
    (5) Laboratory results information: The CDAR1AIS0005R021 Additional 
Information Specification 0005: Laboratory Results Attachment, Release 
2.1, based on HL7 CDA Release 1.0 (incorporated by reference in 
Sec. 162.920).
    (6) Medications information: The CDAR1AIS0006R021 Additional 
Information Specification 0006: Medications Attachment, Release 2.1, 
based on HL7 CDA Release 1.0 (incorporated by reference in 
Sec. 162.920).


Sec.  162.1920  Electronic health care claims attachment response 
transaction.

    (a) The health care claims attachment response transaction is the 
transmission of attachment information, from a health care provider to 
a health plan, in response to a request from the health plan for the 
information.
    (b) If a health care provider conducts a health care claims 
attachment transaction using electronic media, and the attachment 
information is of the type described at Sec. 162.1905, the health care 
provider must conduct the transaction in accordance with the 
appropriate provisions of Sec. 162.1925.
    (c) A health care provider that conducts a health care claims 
attachment response transaction using electronic media must submit a 
complete response by providing, to the extent available, all of the 
requested attachment information or other appropriate response in the 
transaction.
    (d) A health care provider that sends scanned images and text 
documents in the attachment transaction, for the human decision 
variants, is not required to use the LOINC[supreg] codes as the 
response, other than to repeat the LOINC[supreg] codes used in the 
request. Response information may be free text, scanned documents, or 
an embedded document within the BIN segment of the response 
transaction.
    (e) A health care provider may submit an unsolicited response 
transaction only upon advance instructions by a health plan.


Sec.  162.1925  Standards and implementation specifications for the 
electronic health care claims attachment response transaction.

    The Secretary adopts the following standards and implementation 
specifications for the electronic health care claims attachment 
response trans action:
    (a) The ASC X12N 275--Additional Information to Support a Health 
Care Claim or Encounter, Version 4050, May 2004, Washington Publishing 
Company, 004050X151 (incorporated by reference in Sec. 162.920).
    (b) The HL7 Additional Information Specification Implementation 
Guide Release 2.1 (incorporated by reference in Sec. 162.920) for 
implementing the HL7 Additional Information Specifications to convey 
attachment information within the Binary Data segment of the ASC X12N 
275 (004050x151).
    (c) The following HL7 AIS documents to convey the LOINC[supreg] 
codes that identify the attachment type and

[[Page 56025]]

specific attachment information being sent--
    (1) Ambulance Services information: The CDAR1AIS0001R021 Additional 
Information Specification 0001: Ambulance Service Attachment, Release 
2.1, based on HL7 CDA Release 1.0 (incorporated by reference in 
Sec. 162.920);
    (2) Emergency Department information: The CDAR1AIS0002R021 
Additional Information Specification 0002: Emergency Department 
Attachment, Release 2.1, based on HL7 CDA Release 1.0 (incorporated by 
reference in Sec. 162.920);
    (3) Rehabilitation services information: The CDAR1AIS0003R021 
Additional Information Specification 0003: Rehabilitation Services 
Attachment, Release 2.1, based on HL7 CDA Release 1.0 (incorporated by 
reference in Sec. 162.920);
    (4) Clinical reports information: The CDAR1AIS0004R021 Additional 
Information Specification 0004: Clinical Reports Attachment, Release 
2.1, based on HL7 CDA Release 1.0 (incorporated by reference in 
Sec. 162.920);
    (5) Laboratory results information: The CDAR1AIS0005R021 Additional 
Information Specification 0005: Laboratory Results Attachment, Release 
2.1, based on HL7 CDA Release 1.0 (incorporated by reference in 
Sec. 162.920); and
    (6) Medications information: The CDAR1AIS0006R021 Additional 
Information Specification 0006: Medications Attachment, Release 2.1, 
based on HL7 CDA Release 1.0 (incorporated by reference in 
Sec. 162.920).


Sec.  162.1930  Initial compliance dates for the electronic health care 
claims attachment response and electronic health care claims attachment 
request transaction standards.

    (a) Health care providers. A covered health care provider must 
comply with the applicable requirements of this subpart S no later than 
[24 months after the effective date of the final rule published in the 
Federal Register].
    (b) Health plans. A health plan must comply with the applicable 
requirements of this subpart S no later than one of the following 
dates:
    (1) Health plans other than small health plans--[24 months after 
the effective date of the final rule published in the Federal 
Register].
    (2) Small health plans--[36 months after the effective date of the 
final rule published in the Federal Register].
    (c) Health care clearinghouses. A health care clearinghouse must 
comply with the applicable requirements of this subpart S no later than 
[24 months after the effective date of the final rule published in the 
Federal Register].

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

    Dated: May 27, 2005.
Michael O. Leavitt,
Secretary.
[FR Doc. 05-18927 Filed 9-22-05; 8:45 am]
BILLING CODE 4120-01-P