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

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)) 

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 

Federal Register / Vol. 70, No. 184 / Friday, September 23, 2005 / Proposed Rules 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 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 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 

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

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: 

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

• 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, ANSIaccredited 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 

Federal Register / Vol. 70, No. 184 / Friday, September 23, 2005 / Proposed Rules 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 twothirds 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.wpcedi.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

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 §162.103 and 

§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 nonclinical information such as the 

destination justification and ordering 

practitioner. 

2. Attachment Information means the 

supplemental health information 

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

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). 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 codes are 

developed and maintained by the 

LOINC committee and copyrighted 

1995–2004, by Regenstrief Institute, 

Inc., and the Logical Observation 

Identifiers Names and Codes (LOINC) 

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

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 

Federal Register / Vol. 70, No. 184 / Friday, September 23, 2005 / Proposed Rules 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 ANSIaccredited 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. 

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

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 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 contentspecific 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

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 

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

LOINC 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 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. Autoadjudication 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 autoadjudication 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 

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

that do not intend to auto-adjudicate in 

the short term, may continue to use lowcost 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 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

Variant Information representation Information sent as * * * 

Human Decision ................................................. Scanned image ................................................ Scanned image of pages from the medical 

record. Repeats LOINC code from the request. 

Human Decision ................................................. Natural language text ....................................... Natural language text with captions that 

match the specified questions. Repeats 

LOINC code from the request. 

Computer Decision ............................................. Natural language text and structured information.Natural language text, captions identified by 

LOINC 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 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 computerbased 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 

Federal Register / Vol. 70, No. 184 / Friday, September 23, 2005 / Proposed Rules 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 request code at 

a time, receiving the health care 

provider’s response, and then 

submitting another transaction with 

another LOINC 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 

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

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 for 

the exchange of clinical laboratory 

results, SNOMED CT 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 

Federal Register / Vol. 70, No. 184 / Friday, September 23, 2005 / Proposed Rules 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, 

§162.923 and §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: 

• The administrative information 

contained in the request and response; 

• The attachment information (also 

referred to as the additional information 

specification) contained in the response; 

• A code set for specifically 

describing the attachment information; 

• A code set modifier for adding 

specificity to the request; and 

• 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 

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

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 patientbased 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

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 

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

holder of the X12N health care claim 

status reason codes. The Regenstrief 

Institute, Inc. and the LOINC

Committee are the copyright holders of 

the LOINC code set and database. 

LOINC 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 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 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

codes for communicating detailed or 

specific clinical information to 

supplement a claim, and made a 

recommendation to the Secretary to 

adopt LOINC 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 Codes and Health Care 

Claim Status Reason Codes for 

Requesting Additional Information, 

illustrates the brevity and efficiency 

associated with using LOINC 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 CODES AND HEALTH CARE CLAIM STATUS REASON CODES FOR REQUESTING

ADDITIONAL INFORMATION

LOINC code LOINC code definition Health care claim status reason 

code 

Health care claim status reason code 

definition 

R4: 18658–5:LOI ....... R4 = Requests for additional information 

and documentation 18658–5 = Psychiatric Rehabilitation treatment plan, 

progress notes, and attainment of 

goals LOI = Specifies this is a LOINC

code.

R4:310:3F ................................... R4 = Requests for additional information/ 

documentation; 310 = Progress notes 

for the 6 months prior to statement 

date; 3F = Rehabilitation facility. 

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

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

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 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 process for reviewing and 

updating the database of codes and 

values also offers sufficient 

opportunities for growth and expansion. 

Therefore, LOINC 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 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 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

code set be adopted to support 

electronic health care claims 

attachments. We support the 

recommendation, and have included the 

adoption of LOINC codes as a part of 

this proposed rule. HL7 has created 

companion LOINC modifiers that 

would add further specificity to the 

LOINC 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 modifiers as 

national standards for the electronic 

health care claims attachments. 

As we have described earlier, the HL7 

specification uses LOINC codes for 

each proposed electronic claims 

attachment, and these AIS specify the 

required content and LOINC 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 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 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 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 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 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 

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

results, clinical reports and medications 

allow for the use of new LOINC codes 

in the response, once these become 

available in the LOINC 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 codes that may be used. New 

questions, and therefore potential new 

LOINC 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

codes, could be incorporated in the AIS 

adopted in the final rule. Any LOINC

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 codes 

may be requested through Regenstrief, 

by following the procedures outlined in 

the LOINC 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 database and the LOINC

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 code or codes appropriate to 

that electronic attachment request. Only 

LOINC codes specified in the HL7 AIS 

booklets and LOINC 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

code set. The responding transaction 

(the X12N 275) would echo the 

requester’s LOINC request codes, and 

provide the data associated with those 

LOINC 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 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 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 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 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 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

codes for requesting laboratory results 

supplemental information are contained 

in this guide. 

f. CDAR1AIS0006R021 Additional 

Information Specifications 0006: 

Medications Attachment. The 

instructions and LOINC 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

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 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 code of 

18594–2. Other LOINC 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

code tables that define all of the data 

content that may be used in that 

particular electronic attachment. 

The LOINC 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 Report 

Subject Identifier Code(s) that most 

clearly represents the attachment 

information needed. The LOINC

Report Subject Modifier Codes can be 

found in the LOINC Committee 

publication. 

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

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 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 codes and LOINC

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 codes and LOINC

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 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

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 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

Federal Register / Vol. 70, No. 184 / Friday, September 23, 2005 / Proposed Rules 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. 

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. 


EP23SE05.051</GPH>
56008 Federal Register / Vol. 70, No. 184 / Friday, September 23, 2005 / Proposed Rules 

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. 

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. 


EP23SE05.052</GPH> EP23se05.053</GPH>
Federal Register / Vol. 70, No. 184 / Friday, September 23, 2005 / Proposed Rules 56009 

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. 

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 autoadjudicated. Exceptional claims may be 

manually adjudicated and attachments 

viewed using a Web browser. 


EP23SE05.054</GPH> EP23SE05.055</GPH>
56010 Federal Register / Vol. 70, No. 184 / Friday, September 23, 2005 / Proposed Rules 

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 autoadjudicated. Exceptional claims may be 

manually adjudicated and attachments 

viewed using a Web browser. 


EP23se05.056</GPH>
Federal Register / Vol. 70, No. 184 / Friday, September 23, 2005 / Proposed Rules 56011 

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. 


EP23se05.057</GPH> EP23se05.058</GPH>
56012 Federal Register / Vol. 70, No. 184 / Friday, September 23, 2005 / Proposed Rules 

Advantages—This scenario is the best case 

and has the best potential to maximize autoadjudication 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 § 162.1915 and 

§ 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 

§ 162.1915 and § 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 postadjudication 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 

§162.1915 and §162.1925 for the 

specific electronic health care claims 

attachment transactions, or to translate 

proprietary information from their 

clients into standard format for retransmission. Health care 

clearinghouses must already comply 

with the requirements set out in 

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

Federal Register / Vol. 70, No. 184 / Friday, September 23, 2005 / Proposed Rules 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 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

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 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 database and the 

publication LOINC 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 database and the 

LOINC modifier codes from the 

Regenstrief Institute, c/o LOINC, 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 §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. 

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

There are mechanisms in place for 

LOINC 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

codes for new types of laboratory results 

and clinical reports will be added to 

LOINC 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 codes are to 

be addressed to the Regenstrief Institute 

for Health Care, c/o LOINC Committee, 

1050 West Wishard Blvd, Indianapolis, 

IN 46202, or electronically, in 

accordance with the instructions in 

Appendix D of the LOINC 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 

§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 onetime burden has already been approved 

and accounted for in ‘‘HIPAA Standards 

for Coding Electronic Transactions’’

(OMB #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 

Federal Register / Vol. 70, No. 184 / Friday, September 23, 2005 / Proposed Rules 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 

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

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), as outlined in the 

preamble to this rule and in the 

following analysis, HHS has concluded 

that this proposed rule is the most costeffective 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 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 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

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 

Federal Register / Vol. 70, No. 184 / Friday, September 23, 2005 / Proposed Rules 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: 

• Few health care claims attachments 

are requested or submitted using an 

electronic format of any kind. 

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

• The volume of unsolicited 

attachments accompanying original 

health care claims today is relatively 

small. 

• 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 

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

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: 

• Learning about and training staff on 

the new claims attachment standards, 

the X12 implementation guides, HL7 

AIS booklets, and LOINC codes. 

• Programming systems to 

accommodate the new transaction types, 

messaging standards, and codes. 

• Installing LOINC codes. 

• Mapping the LOINC codes to the 

current attachment request reason 

codes. 

• Acquiring translator capability to 

process HL7 messages. 

• Telecommunication expansion. 

• Server expansion to retain 

electronic records. 

• Other potential software upgrades 

for browsing, translating, and validating, 

as well as internal controlling or 

messaging/routing functions. 

• Health care clearinghouse fees. 

• Acquiring XML expertise. 

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

• Using standardized attachment 

requests. 

• Receiving consistent response 

information. 

• Eliminating paper documents and 

the manual efforts to request, receive, 

process, and handle the documents. 

• Reducing postage costs. 

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

• Learning about and training staff on 

the new electronic claims attachment 

standards, the X12 implementation 

guides, HL7 AIS and LOINC codes. 

• Programming systems to 

accommodate the new transaction types, 

messaging standards, and codes. 

• Mapping the LOINC codes to 

current proprietary codes. 

• Installing LOINC codes. 

• Software and/or vendor fees. 

• Practice management system 

vendor fees and charges. 

• Health care clearinghouse fees. 

• Changing business practices and retraining staff to enter different data, 

perform different functions, conduct 

different procedures. 

• Purchasing or expanding server 

space. 

• Acquiring XML expertise. 

• Purchasing or enhancing translator 

software. 

• Telecommunication expansion. 

• 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 onetime expenditures rather than recurring 

ones. 

b. Savings could accrue from the 

following: 

• Use of standardized, predictable 

attachments, and formats rather than 

numerous proprietary forms associated 

with individual health plan 

requirements. 

• Reduction of paper documents and 

manual efforts to receive, process, and 

respond to requests. 

• Reduction in postage and mailing 

costs. 

• Reduction in labor costs. 

• Minimization of ambiguities, which 

frequently result in multiple 

communication exchanges before the 

desired information is correctly 

identified and provided. 

• Application of automation by 

covered health care providers with 

electronic record systems to support the 

rapid retrieval of information, and 

respond to requests. 

• More accurate tracking and receipt 

of attachment information, resulting in 

fewer lost documents. 

• 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 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. 

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

In light of existing limitations, we 

repeat our solicitation for 

implementation cost information from 

affected entities. We are providing highlevel 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 lowhigh 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. 

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

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 of the estimated 25 percent of all Physician Claims ............................................. 354 460 368 458 383 498 398 518 414 538 

Attachments volume: 50 percent of the estimated 25 percent of all Hospital Claims ................................................ 89 115 92 119 96 124 100 129 104 135 

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

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

TABLE 7.—OPERATIONAL SAVINGS FROM ELECTRONIC HEALTH CARE CLAIMS ATTACHMENTS BASED ON SPECIFIC RATES

OF CONVERSION

[In millions] 

2007 

(@ 5 percent 

conversion) 

2008 

(@ 20 percent 

conversion) 

2009 

(@ 50 percent 

conversion) 

2010 

(@ 75 percent 

conversion) 

2011 

(@ 90 percent conversion) 

Low High Low High Low High Low High Low High 

Total Operational Savings for each conversion factor ........ 21 51 86 213 224 554 349 865 436 1,079 

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 

(discounted at 3 percent) 

Total savings 

(discounted at 7 percent) 

Annualized savings 

(discounted at 3 percent) 

Annualized savings 

(discounted at 7 percent) 

Low High Low High Low High Low High 

Total Operational Savings Achieved Using 

Conversion Factor for Paper to Electronic 

Attachments .................................................. 1,023 2,532 915 2,264 205 506 183 453 

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 

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

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: 

• Improve the efficiency and 

effectiveness of the health care system 

by leading to cost reductions for, or 

improvements in, benefits from 

electronic HIPAA health care 

transactions. This principle supports the 

regulatory goals of cost-effectiveness 

and avoidance of burden. 

• Meet the needs of the health data 

standards user community, particularly 

covered health care providers, health 

plans, and health care clearinghouses. 

This principle supports the regulatory 

goal of cost-effectiveness. 

• Be consistent and uniform with the 

other HIPAA standards (that is, their 

data element definitions and codes and 

their privacy and security requirements) 

and, secondarily, with other private and 

public sector health data standards. This 

principle supports the regulatory goals 

of consistency and avoidance of 

incompatibility, and it establishes a 

performance objective for the standard. 

• Have low additional development 

and implementation costs relative to the 

benefits of using the standard. This 

principle supports the regulatory goals 

of cost-effectiveness and avoidance of 

burden. 

• Be supported by an ANSIAccredited Standards Developing 

Organization or other private or public 

organization that would ensure 

continuity and efficient updating of the 

standard over time. This principle 

supports the regulatory goal of 

predictability. 

• Have timely development, testing, 

implementation, and updating 

procedures to achieve administrative 

simplification benefits faster. This 

principle establishes a performance 

objective for the standard. 

• Be technologically independent of 

the computer platforms and 

transmission protocols used in HIPAA 

health transactions, except when they 

are explicitly part of the standard. This 

principle establishes a performance 

objective for the standard and supports 

the regulatory goal of flexibility. 

• Be precise and unambiguous but as 

simple as possible. This principle 

supports the regulatory goals of 

predictability and simplicity. 

• Keep data collection and paperwork 

burdens on users as low as is feasible. 

This principle supports the regulatory 

goals of cost-effectiveness and 

avoidance of duplication and burden. 

• Incorporate flexibility to adapt more 

easily to changes in the health care 

infrastructure (such as new services, 

organizations, and provider types) and 

information technology. This principle 

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 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 §162.103, the introductory text 

to the section is republished, and a 

definition for ‘‘LOINC’’ is added in 

alphabetical order to read as follows: 

§ 162.103 Definitions. 

For purposes of this part, the 

following definitions apply: 

* * * * * 

LOINC stands for Logical 

Observation Identifiers Names and 

Codes. 

* * * * * 

3. In §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: 

§ 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 

Federal Register / Vol. 70, No. 184 / Friday, September 23, 2005 / Proposed Rules 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 

§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 

§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.wpcedi.com/. 

(2) The HL7 Additional Information 

Specifications for each of the six 

attachments listed in §162.1915 and 

§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 §162.1915(b)(1) 

and §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 §162.1915(b)(2) and 

§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 §162.1915(b)(3) and 

§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 §162.1915(b)(4) and 

§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 §162.1915(b)(5) 

and §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 §162.1915(b)(6) 

and §162.1925(c)(6). 

(3) The LOINC 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 §162.1002, paragraph (c) is 

added to read as follows: 

§ 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

(LOINC), as maintained and 

distributed by the Regenstrief Institute 

and the LOINC Committee. The 

LOINC 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 database from the 

Regenstrief Institute, c/o LOINC, 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 

§ 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 nonclinical 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 

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

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. 

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

§ 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 §162.1905 , the 

plan must conduct the transaction in 

accordance with the appropriate 

provisions of §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 codes and LOINC

modifiers identifying the attachment 

information being requested. 

§ 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 §162.920). 

(b) The following HL7 AIS documents 

to convey the LOINC 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 §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 §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 §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 §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 §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 §162.920). 

§ 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 §162.1905, the health 

care provider must conduct the 

transaction in accordance with the 

appropriate provisions of §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 codes as the 

response, other than to repeat the 

LOINC 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. 

§ 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 §162.920). 

(b) The HL7 Additional Information 

Specification Implementation Guide 

Release 2.1 (incorporated by reference 

in §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 codes that 

identify the attachment type and 

Federal Register / Vol. 70, No. 184 / Friday, September 23, 2005 / Proposed Rules 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 §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 §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 §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 §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 §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 §162.920). 

§ 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