HIPAA Administrative Simplification: Standards for Electronic Health Care Claims Attachments

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

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

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, ANSI-accredited SDO that provides standards for the exchange, management, and integration of data that support clinical patient care and the management, delivery, and evaluation of health care services. While other standards development or standard setting organizations create standards or protocols to meet the business needs of a particular healthcare domain such as pharmacy, medical devices, or insurance, HL7's domain is principally clinical data. Its specific emphasis is on the interoperability between healthcare information systems. In fact, “Level Seven” refers to the highest level of the International Standards Organization's communications model for Open Systems Interconnection—which is the application level of a system. The application level addresses the definition of the data to be exchanged, the timing of the interchange, and the communication of certain errors to the application. The seventh level supports such functions as security checks, participant identification, availability checks, exchange mechanism negotiations, and most significantly, data exchange structuring. HL7 is in a unique position to participate in standard setting for health information because its focus is on the interface requirements of the entire health care organization rather than on a particular domain.

HL7 membership is open to all individuals and organizations. Within HL7, similar to Work Group 9 under X12N, the Attachments Special Interest Group (ASIG) includes industry experts representing health care providers, health plans, and vendors, and is dedicated to developing the criteria and standards for electronic health care claims attachments. This group created the Additional Information Specifications (AIS) referenced in this proposed rule. The ASIG is responsible for those tasks associated with creating and maintaining the documents that specify the content, format and codes for submitting and responding to requests for each type of electronic health care claims attachment. These documents are known as AIS, which again, are each a set of instructions and associated code tables created and maintained by HL7 that describes, lists, or itemizes the additional information that is to be sent and how such information is to be conveyed in an electronic health care claims attachment.

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

1. ASC X12N and the HL7 Implementation Guides and HL7 Additional Information Specifications

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

The ASC X12 committee is the decision-making body responsible for

obtaining consensus from the entire organization, which is necessary before seeking ANSI approval of a standard in the field of health insurance. The ASC X12N Subcommittee develops standards and conducts maintenance activities. The draft documents are made available for public review and comment. After the comments are addressed, the revised document is presented to the entire ASC X12N subcommittee membership group for approval. This work is then reviewed and approved by the membership of ASC X12 as a whole. In sum, Implementation Guides developed by ASC X12N must be ratified by a majority of voting members of the ASC X12N subcommittee and the executive committee of X12 itself.

HL7: To establish its standards, HL7 conducts a three-step process. First, standards are developed and accepted or rejected by voting at the technical committee level. All HL7 members are eligible to vote on standards, without regard to whether they are members of the committee that wrote the standard. Non-members may also vote on a given ballot for a standard, for which privilege they pay an administrative fee. HL7's policy states that it shall assess an administrative fee for the processing, handling, and shipping of the ballot package. The administrative fee does not exceed the fee associated with an individual membership in HL7. Second, HL7 technical committees and special interest groups vote on “recommendations” and at least two-thirds of the total votes must be positive for approval. Third, if approved at the technical committee level, the recommended standards are submitted to the entire HL7 organization for approval. Finally, they are submitted to ANSI for certification.

2. Implementation Guides in HIPAA Regulations

Section 1172(d) of the Act directs the Secretary to establish specifications for implementing each of the standards adopted under this part.

For electronic transaction standards, the SDOs developed “Implementation Guides” for implementing the same standards for a number of different business purposes. For example, the general ASC X12 claim, the 837, has separate implementation guides that permit its use in automobile, liability, and health care claims. The approach taken in the final Transactions Rule was to adopt a specific “Implementation Guide” as both the “standard” and the “implementation specifications” for each health care transaction.

The regulations text of this proposed rule also adopts the referenced guides as both the standard and the implementation specifications for each electronic health care claim attachment transaction. Accordingly, this rule proposes the adoption of specific X12 Implementation Guides (for example, the ASC X12N 277 version 4050) as both the standard and the implementation specification for each transaction. To avoid confusion in the use of certain similar terms in this proposed rule, we use the term “Implementation Guide” only when referring to specific documents published by ASC X12N. Therefore, when we refer to the master HL7 Implementation Guide, we will state the full document name: “HL7 Additional Information Specification Implementation Guide,” or HL7 AIS IG. We do not otherwise refer to “implementation specifications” or distinguish between “standards” and “implementation specifications.”

The 4050 versions of the X12 Implementation Guides are compatible with the current X12 4010 guides adopted for HIPAA transactions—version 4010-1a so that the two transactions can be used together as necessary. In other words, a claims transaction (837 version 4010-1a) may be accompanied by a health care claims attachment response transaction (275 version 4050). Public comments on the draft versions of the X12 Implementation Guides for version 4050 of the X12N 277 and X12N 275 were solicited between December 5, 2003 and January 9, 2004. The current guides may be obtained from

http://www.wpc-edi.com

.

The other set of documents proposed for use with electronic health care claims attachments are called HL7 Additional Information Specifications (AIS). These were drafted by the HL7 ASIG work group and were balloted and approved by HL7 in September 2003. These AIS are used in concert with the X12 Implementation Guides and provide the instructions for the use of the proposed code set, to be described later in this preamble. The adoption of the HL7 documents would fulfill the legal mandate for the Secretary to establish the implementation specifications for the HIPAA standards proposed for adoption in accordance with 1172(d) of the Act.

The X12N Implementation Guides, HL7 AIS IG, HL7 AIS, and the LOINC® 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 non-clinical information such as the destination justification and ordering practitioner.

2. Attachment Information means the supplemental health information

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

document specification that enables the standardization of “clinical documents” for electronic exchanges of health information (see explanation of XML below). The CDA became the first ANSI-accredited XML-based standard in the health care industry.

There is increasing evidence that many health care organizations, including health plans, health care providers, and health care clearinghouses, plan on implementing more XML-based EDI tools. Thus, building electronic health care claims attachments using XML technology is in concert with the direction of the industry. In light of these developments, we believe that the timing for this proposed rule is reasonable because its publication and the years allowed for implementation should leave ample time for the industry to further develop its skills with XML and EDI exchange methodology.

The HL7 standard being proposed here would allow the same records and data to be “read” and used by either people or computers. In other words, regardless of how the data are sent within the proposed transaction, they can be processed either manually or through automation. Furthermore, as entities move toward computer-based methods for adjudication, the costs of copying, coding, transcribing, storing, and processing records should begin to decrease. Thus, this proposal has the potential for helping the industry attain desired efficiencies, expedite payments, reduce fraud and abuse, and improve the accuracy of medical information.

1. Overview of Extensible Markup Language (XML)

Extensible Markup Language, or XML, is a relatively new technology. It allows documents to be formatted and exchanged across the Internet or through EDI.

Hypertext Markup Language (HTML) is a widely used presentation language used to create documents for display on the Web. Using HTML markup with text, links, and graphics creates an HTML document that is attractive in appearance. HTML was created to describe how the content of a page should be displayed, but not the actual contents of the page. XML fills this gap because it provides an intelligence to electronic documents and preserves both the content (the actual information) and semantics for the document, and also formats it attractively, similar to HTML. In fact, XML and HTML are increasingly used together—XML stores and organizes the data, while HTML renders it inside the browser or application.

XML was originally published by the World Wide Web Consortium (

http://www.w3c.org

) and designed as a standard markup language to speed up and simplify data exchange and database connectivity and to enhance the creation of complex documents. XML effectively structures files into logical elements of information by the use and placement of tags which describe the kind of information being sent. Information organized using XML, and bounded by tags, is known as a document whether it is in a file, or whether it is being transmitted over the Internet or in any other technical environment. The process of arranging information between tags is called document markup.

Over the past few years, XML has been adopted by most major companies in information technology as the basis for attaining interoperability among their own products. One of the special features of the XML family is the standard language for describing the transformation or conversion of an XML document into another format. Extensible Stylesheet Language, or XSL, is the language that contains the presentation format instructions for the document, similar to HTML. It allows the display of information in different media, such as a computer screen or a paper copy, and it enables the user to view the document according to his or her preferences and abilities, just by changing the stylesheet. XSL Version 1.0 is important because it can convert an XML document into Extensible HTML, which can be understood by current Web browsers and many common applications. In fact, each HL7 AIS for the electronic claims attachment standards will include a fully functional XSL stylesheet for use by covered entities. If covered entities choose not to use the HL7 supplied stylesheet, they will be able to create their own without significant problems, assuming the expertise exists on staff or is available through a vendor.

2. Overview of Clinical Document Architecture

The HL7 Clinical Document Architecture (CDA)—Release 1.0 was approved by HL7 in November 2000. It is a document markup standard encoded in XML that specifies the structure (format) and semantics (content) of “clinical documents” for the purpose of information exchange. These XML-coded documents have the same characteristics and information as hard copy clinical documents, and therefore can be processed by both people and machines. The clinical documents encoded in XML include a hierarchical set of document specifications (the architecture) and are rendered in human readable form using XSL. This makes them usable in either electronic or printed format. The XSL essentially translates the XML into a format that looks like a “regular” plain text document.

We are aware that HL7 continues to improve its standards, including the CDA. In fact, CDA Release 2.0 was first balloted in August 2003 and re-balloted in 2004. While Release 2.0 may be approved between the time of this proposed rule and the final rule, this proposed regulatory text does not suggest its adoption at this time. However, if Release 2.0 is approved by HL7 between the time of this proposed rule and the final rule, we may propose its adoption for future AIS, based on the impact of CDA Release 2.0 on the existing AIS. As part of CDA Release 2.0, HL7 is developing an XSL stylesheet that would permit interoperability between Release 1.0 and Release 2.0. However, as this too is incomplete, it is premature to consider its use or viability at this time. We invite comment on the pros and cons of each CDA release, the issues related to the use of a stylesheet to permit use of either CDA release, and the costs and timing associated with implementing one release version over the other.

3. How XML Is Applied Within the Clinical Document Architecture

As with any XML-based standard, the CDA defines tag names and how they nest to structure information. Some of the important tag names are shown in the table below. The indentation in the left column of the table shows the manner in which certain elements nest within other elements.

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 content-specific electronic attachment types as they are developed and approved.

Based on industry feedback following implementation of the Transactions Rule, it became clear that pilot programs and early testing of new standards and processes were vital to the standards adoption process. In July 2004, HHS awarded funds for a Medicare pilot program to test the X12 request and response transactions, the LOINC® 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

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. Auto-adjudication is the use of computers, programmed with business rules and logic, to process a claim, making decisions as to whether to pay, how much to pay, and to whom to make the payment. It is a long-term goal for most health plans to be able to support auto-adjudication for as many claims as possible.

Even with this variant, HL7 will supply “stylesheets” that will put any data into an HTML or screen readable format. This means that health plans

that do not intend to auto-adjudicate in the short term, may continue to use low-cost technology to print or display the electronic attachment information, regardless of which option or variant the health care provider uses.

The human and computer variants do not differ in actual content. Both types of variants (human and computer) for each electronic attachment type have required and optional content elements, which are listed in the specification for that attachment. Both types of variants will satisfy the standard, as they will differ only with regard to whether or not structured and coded data are required. That is, in the computer variant, coded data are required, whereas in the human variants, coded data are not required. While both variant types will carry a LOINC® 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 computer-based medical record systems.

From the health plan perspective, the requirements for use of the two standards can be met with a low impact implementation for claims adjudication, based on a person looking at the content of the electronic attachment in a text/readable format, regardless of how it is submitted. While the proposed process supports auto-adjudication, it does not require it for compliance.

D. Electronic Health Care Claims Attachment Business Use

A health care claims attachment conveys supplemental information pertaining to the services provided to a specific individual to support evaluation of a claim before it is paid. An attachment might contain biometric data; medical history; clinical data (reports, studies, notes); hospital discharge notes; laboratory results; medication information; rehabilitation plans; optical prescriptions; certifications made by the individual and/or the health care provider regarding sterilization, hysterectomy, or other services, as required by Federal or State rules; or other clarifying information for a particular service.

Attachments may be requested or submitted when the supplemental medical information is directly related to the determination of benefits under the subscriber's contract, or when directly related to providing medical justification for health care services provided to the individual when that medical justification can affect the adjudication of payment for services billed by the provider of health care services. Although additional clinical or administrative information may be required following adjudication of claims, such as for post-adjudication review to support quality control, fraud and abuse, or other post-adjudication reviews and reporting requirements, we do not consider these post-adjudication requests for claims-related data to be part of the claims payment process. Therefore, post-adjudication processes are not covered by this proposal. While covered entities may voluntarily choose

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

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

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

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

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

[If you choose to comment on issues in this section, please include the caption “ALTERNATIVES CONSIDERED: CANDIDATE STANDARDS” at the beginning of your comments.]

1. Transactions

History: In the early years of the HIPAA standards adoption process, the ANSI Health Informatics Standards Board (HISB) prepared inventories of transaction standards and code sets for HHS so that staff could evaluate the available options. Several standards were selected as potentially viable for electronic health care claims attachments, but no final decision was made at that time, and the proposal was held for additional work. In a 2001 white paper, HISB again documented the potential transaction standards that could be used for electronic health care claims attachments. The list included the ANSI X12N 275 version 4010 (Additional Information in Support of the Health Care Claim or Encounter) as the vehicle to send the electronic attachment information to the health plan. However, that transaction and a number of other ones considered, were not suitable on their own for a general electronic health care claims attachment standard, as they (the transaction standards) were overly service specific. For example, the Institute of Electrical and Electronic Engineers (IEEE) had a standard (IEEE 1073) for communication among bedside devices. Digital Imaging and Communication in Medicine (DICOM) created a standard for the format and transfer of biomedical images and image-related information. The American Society for Testing and Materials (ASTM) had created a framework vocabulary for the patient-based record content. While each of these standards had its place in the industry, none was appropriate as a transaction standard capable of handling a host of different types of electronic health care claims attachments.

a. Health Care Claims Attachment Request Transaction

The HISB did not suggest any candidate transactions for use as a request for additional health care claim information. A review of SDO transaction inventories and a review of relevant literature by the WG9 identified only one transaction that could be modified for use as an electronic claims attachment request transaction: the X12N 277 version 4010 Claim Status Response transaction could satisfy this business need if the implementation specifications were modified. The X12N 277 transaction adopted under HIPAA for claims status inquiries was originally created by ASC X12N to provide the capability to electronically transmit information about the (payment) status of a health care claim (the 277 serves as a response transaction to the 276 inquiry). In order to accommodate the more extensive business requirements of an electronic health care claim attachment request, a new version of the implementation specification of the X12N 277-Health Care Claim Status Notification would have been required. Thus, X12 and HL7 determined that it was more expedient and practical to create a new transaction standard designed for the specific purpose of requesting an attachment rather than trying to modify one designed as a response transaction.

b. Health Care Claims Attachment Response Transaction

The HISB assessment originally suggested one standard as a candidate for the response to a request for health care claims attachment information. The X12N 275-Patient Information transaction had the closest match in capability and business potential for conveying health care claims attachment information, though it had not been adopted as a HIPAA standard for any other purpose. The X12N 275 transaction was designed to provide individual information to be shared among trading partners. When coupled with HL7 message structures, the X12N 275 appeared to represent the best electronic solution for this purpose because of its two key advantages over other ASC X12N transactions: (1) The capability to transmit other standard messages within the transaction; and (2) the ability to transmit large amounts of information within the BIN segment of the transaction, which can contain up to 64 megabytes of data. However, after extensive evaluation, WG9 determined that the existing version of the X12N 275 transaction would have to be modified, with significant structural changes to accommodate the business needs for standardized electronic health care claim attachments. WG9 also determined that most of the supplemental information requested by health plans was clinical information, usually detailed with specific quantitative measurements, laboratory results, and specific medical reports. Clinical information of this nature was already accommodated by HL7 messages, but not by anything in the X12 repertoire. The X12N 275 transaction, when coupled with HL7 message structures, appeared to represent the best electronic solution for this purpose. In 1997, ASC X12N representatives agreed to incorporate the use of HL7 standard messages in the BIN segment of the ASC X12N 275. Over the past two years, ASC X12N developed a new implementation guide for this use, complemented by the HL7 specifications.

2. Code Sets

History: There was virtually no depth in the pool of available code sets for consideration to request or send information—at least not one individual code set with everything that might be needed for electronic health care claims attachments. Thus, the original candidate for the code set to be used with attachments was the X12N version of health care claims status reason codes, tied to the X12N 837 claims transaction and the claims status inquiry and response (X12N 276/277). As this option was being evaluated, HISB also reviewed another code set that could potentially serve to identify the additional information needed to process the claim—this was the LOINC® 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

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

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

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.

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®

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.

EP23SE05.051

Advantages—This scenario requires minimal changes to the billing application. Based on feedback from the healthcare industry, this accommodation was specifically included in the specification as an interim step for providers who plan to eventually adopt one of the other scenarios that result in sending attachments as structured data, but needed an expedient alternative as an interim step.

Disadvantages—This scenario does not provide the payer with the structured data necessary to auto-adjudicate the claim, thus negating much of the advantage of electronic attachments. This scenario requires a staff member to scan the documents that contain the attachments data. Since the required attachments data may exist on forms that also include other, unnecessary data, the staff member may, for privacy reasons, also have to take whatever steps are necessary to ensure the privacy of Protected Health Information under HIPAA.

Likely changes from status quo—The provider's billing vendor would have to accommodate the new X12N 277 and 275 transaction sets and would have to enable the attachment of a scanned image to the 275 transaction set. The provider would have to assign the new task of scanning in attachments data to staff members.

Provider Scenario 2: The provider installs a conversion utility in the billing or practice management software to translate attachments data from its current format into a fully formatted attachment with structured data. The provider is then able to key the attachment data into the conversion utility. The utility creates the attachment and delivers it to the billing application. The billing application then associates the formatted attachment with a claim and includes it in submission to the payer as needed.

EP23SE05.052

Advantages—This scenario provides the payer with the structured data necessary to auto-adjudicate the claim. It also requires minimal changes to the billing application. This scenario also provides a “bridge” between the EMR scenario described in Scenario 4 and the strictly text/image model in Scenario 1. Although this scenario introduces an additional workflow step, it also allows for the elimination of other workflow steps such as copying paper files and dealing with the U.S. mail process.

Disadvantages—This scenario requires the addition of a new conversion utility application into the provider's information systems environment. Attachments data are manually typed into the conversion utility, which is an additional workflow step. Since this scenario requires an additional workflow step, the provider does not have an automated solution for submitting unsolicited attachments with the initial claim. Furthermore, there is an increased opportunity for human error, due to the requirement for manual keying of information.

Likely changes from status quo—The provider would have to select, purchase, install, and support the new conversion utility. The provider's billing vendor would have to accommodate the new request for attachment and the response (with attachment) and join the attachment from the conversion utility with the claim.

Provider Scenario 3: The provider's billing application is adapted to allow attachments information to be keyed directly into the billing application. The billing application then formats the attachment information as structured data and includes it in submission to the payer as needed.

EP23se05.053

Advantages—This scenario provides the payer with the structured data necessary to auto-adjudicate the claim. Only the billing application needs to be upgraded. This scenario also provides a “bridge” between the EMR scenario described in Scenario 4 and the strictly text/image model in Scenario 1. Although this scenario introduces an additional workflow step, it also allows for the elimination of other workflow steps such as copying paper files and dealing with the U.S. mail process.

Disadvantages—This scenario requires the attachments data to be manually typed into the billing application, which is an additional workflow step. Since this scenario requires an additional workflow step, the provider does not have an automated solution for submitting unsolicited attachments with the initial claim. Furthermore, there is an increased opportunity for human error, due to the requirement for manual keying of information.

Likely changes from status quo—The provider's billing vendor would have to enable the provider's billing application to accept attachment data that have been keyed manually, and would have to accommodate the new request for an attachment and sending the response with the attachment data, as well as the creation of the structured data attachment itself. The provider would have to reassign staff to the new task of keying in attachment data, versus their previous task of copying and mailing records manually.

Provider Scenario 4: The provider's Electronic Medical Record (EMR) or clinical information system provides a fully formatted attachment with the appropriate attachment information to the billing application. The billing application then associates the formatted attachment and includes it in submission to the payer as needed.

EP23SE05.054

Advantages—This scenario provides the payer with the structured data necessary to auto-adjudicate the claim.

Disadvantages—This scenario requires capabilities for data exchange to be present in the provider's billing and one or more EMR/clinical applications.

Likely changes from status quo—The provider's billing application would have to accept attachments as XML documents and transmit them to payers. Various provider systems would have to produce structured attachments in CDA format and route them to the billing system. Examples of potential source systems include the electronic medical record, laboratory, radiology (for reports), rehabilitation, and general transcription. Where the source system already produces HL7 version 2 messages, the provider may use an integration broker to convert the HL7 message into a CDA document. In a few cases, the provider may choose to use desktop productivity applications to accept input.

Payer Options

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

EP23SE05.055

Advantages—This option represents the least organizational change for the payer. There may be savings opportunities based on the reduction in mailed requests and the manual tracking systems used to associate hard copy requests, records, and the related claims. It is possible that this option would reduce time delays associated with the manual requests and responses, and minimize the number of “lost records.”

Disadvantages—None of the benefits of auto-adjudication are realized.

Changes to the Status Quo—Elements of the payer's application suite are modified to associate the CDA (XML) based attachment for human viewing via a browser.

Payer Scenario 2: If the payer already uses a conversion utility to translate X12N transaction sets, and that conversion utility is capable of also translating CDA based attachments, the claim may be auto-adjudicated. Exceptional claims may be manually adjudicated and attachments viewed using a Web browser.

EP23se05.056

Advantages—A conversion utility may be more flexible and may more readily accommodate the new tasks for parsing XML based attachments than the payer's main system. This option provides the potential to maximize auto-adjudication and minimize administrative costs.

Disadvantages—Additional responsibility is placed on the conversion utility. This may or may not be a disadvantage.

Changes to the Status Quo—Existing conversion utilities have to be either reconfigured or modified to parse CDA (XML based) attachments.

Payer Scenario 3: If the payer already uses a conversion utility to translate X12N transaction sets, and that conversion utility is not capable of also translating CDA based attachments, a second conversion utility may be used and the claim may be auto-adjudicated. Exceptional claims may be manually adjudicated and attachments viewed using a Web browser.

EP23se05.057

Advantages—Existing components continue to function with little or no modification. Auto-adjudication may still be used to its potential.

Disadvantages—This adds one or more utilities to split the attachment from its X12N transaction set, parse the attachment, and maintain the association between the attachment and its X12N transaction set. This may add significant complexity to the flow of electronic transaction sets.

Changes to the Status Quo—One or more utilities are added to the payer's application suite to split the attachment from its X12N transaction set, parse the attachment, and maintain the association between the attachment and its X12N transaction set.

Payer Scenario 4: If the payer is capable of parsing both X12N 275 transaction sets and CDA based attachments, the claim may be auto-adjudicated. Only exceptional claims are manually adjudicated. When necessary, attachments are viewed using a Web browser.

EP23se05.058

Advantages—This scenario is the best case and has the best potential to maximize auto-adjudication and minimize administrative costs.

Disadvantages—This may involve the most significant changes to the primary information systems used for processing claims.

Changes to the Status Quo—Most large primary management information systems are legacy based mainframe systems. These systems would need to integrate with XML aware browsers to view XSL “rendered” attachment data.

The text for the HL7 white paper ends here.

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

Health plans would be required to be prepared to receive and send only the standards specified in § 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 post-adjudication medical review or quality assurance review, would not be subject to the standards proposed here. In either case, covered health care providers would continue to have the option of using electronic or manual means of conducting business, including responding to a request for attachment information electronically or on paper. However, if they choose to respond electronically to an attachment request for which a standard has been adopted, that standard would have to be used.

Any electronic attachments covered by the rule and that accompany a new claim would have to be submitted based on an advanced instruction from the receiving health plan. These “unsolicited” electronic attachments should not be sent without prior agreement or understanding between trading partners.

Health Care Clearinghouses

Health care clearinghouses would be required to be prepared to receive and send only the standards specified in §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 re-transmission. 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.

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.

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 one-time 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

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.

This text is long and has been trimmed here. Open the source document for the complete record.