Medicare and medicaid: Health Insurance Portability and Accountability Act; implementation— Electronic health care claims attachments; standards,

[Federal Register: September 23, 2005 (Volume 70, Number 184)]

[Proposed Rules]

[Page 55989-56025]

From the Federal Register Online via GPO Access [wais.access.gpo.gov]

[DOCID:fr23se05-28]

[[Page 55989]]

Part III

Department of Health and Human Services

Office of the Secretary

45 CFR Part 162

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

[[Page 55990]]

DEPARTMENT OF HEALTH AND HUMAN SERVICES

Office of the Secretary

45 CFR Part 162

[CMS-0050-P]

RIN 0938-AK62

HIPAA Administrative Simplification: Standards for Electronic Health Care Claims Attachments

AGENCY: Office of the Secretary, HHS.

ACTION: Proposed rule.

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

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

ADDRESSES: In commenting, please refer to file code CMS-0050-P. Because of staff and resource limitations, we cannot accept comments by facsimile (FAX) transmission.

You may submit comments in one of four ways (no duplicates, please):

1. Electronically. You may submit electronic comments on specific issues in this regulation to http://www.cms.hhs.gov/regulations/ecomments. Attachments should be in Microsoft Word, WordPerfect, or

   Excel; however, we prefer Microsoft Word.

2. By mail. You may mail written comments (one original and two copies) to the following address ONLY:

   Centers for Medicare & Medicaid Services, Department of Health and Human Services, Attention: CMS-0050-P, P.O. Box 8014, Baltimore, MD 21244-8014.

   Please allow sufficient time for mailed comments to be received before the close of the comment period.

3. By express or overnight mail. You may send written comments (one original and two copies) to the following address ONLY: Centers for Medicare & Medicaid Services, Department of Health and Human Services, Attention: CMS-0050-P, Mail Stop C4-26-05, Baltimore, MD 21244-1850.

4. By hand or courier. If you prefer, you may deliver (by hand or courier) your written comments (one original and two copies) before the close of the comment period to one of the addresses above or below. If you intend to deliver your comments to the Baltimore address, please call (410) 786-7195 in advance to schedule your arrival with one of our staff members.

   Hubert H. Humphrey Building, Room 445-G 200 Independence Avenue, SW., Washington, DC 20201; or 7500 Security Boulevard, Baltimore, MD 21244-1850.

   (Because access to the interior of the HHH Building is not readily available to persons without Federal Government identification, commenters are encouraged to leave their comments in the CMS drop slots located in the main lobby of the building. A stamp-in clock is available for persons wishing to retain a proof of filing by stamping in and retaining an extra copy of the comments being filed.)

   Comments mailed to the addresses indicated as appropriate for hand or courier delivery may be delayed and received after the comment period.

   For information on viewing public comments, see the beginning of the SUPPLEMENTARY INFORMATION section.

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

   SUPPLEMENTARY INFORMATION: Submitting Comments: We welcome comments from the public on all issues set forth in this proposed rule to assist us in fully considering issues and developing policies. You can assist us by referencing the file code [CMS-0050-P] and the specific ``issue identifier'' that precedes the section on which you choose to comment.

   Inspection of Public Comments: All comments received before the close of the comment period are available for viewing by the public, including any personally identifiable or confidential business information that is included in a comment. CMS posts all comments received before the close of the comment period on its public Web site as soon as possible after they have been received. Comments received timely will be available for public inspection as they are received, generally beginning approximately 3 weeks after publication of a document, at the headquarters of the Centers for Medicare & Medicaid Services, 7500 Security Boulevard, Baltimore, Maryland 21244-1850, Monday through Friday of each week from 8:30 a.m. to 4 p.m. To schedule an appointment to view public comments, phone 1-800-743-3951.

   Table of Contents

   1. Background

   1. Summary

   2. Legislation

   3. Standards Setting Organizations

1. Accredited Standards Committee X12 (ASC X12)

2. Health Level Seven (HL7)

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

   1. Definitions

1. Ambulance Services

2. Attachment Information

3. Clinical Reports

4. Emergency Department

5. Laboratory Results

6. Logical Observation Identifiers Names and Codes (LOINC[supreg]))

7. Medications

8. Rehabilitation Services

   2. Effective Dates

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

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

   5. Electronic Health Care Claims Attachment Content and Structure

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

1. Transactions

   1. Health Care Claims Attachment Request Transaction

   2. Health Care Claims Attachment Response Transaction

2. Code Sets

3. Implementation Specifications for Sending and Receiving Additional Health Care Information within a Transaction

   7. Proposed Standards

1. Code Set

2. Electronic Health Care Claims Attachment Request Transaction

   [[Page 55991]]

3. Electronic Health Care Claims Attachment Response Transaction

4. Examples of How Electronic Health Care Claims Attachments Could Be Implemented

   1. Use of the Proposed Transactions Specifications, and Codes for Electronic Health Care Claims Attachments

   2. White Paper from HL7

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

   1. Clinical Reports

   2. Laboratory Results

   3. Medications

2. Additional Information Specification (AIS) Uses: Attachment Types for Specific Services

   1. Rehabilitation Services

   2. Ambulance Service

   3. Emergency Department

3. Maximum Data Set

   1. Specific Documents and Sources III. Modifications to Standards and New Electronic Attachments

   1. Modifications to Standards

   2. Additional Information Specifications for New Electronic Attachments

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

   1. Overall Impact

1. Affected Entities (Covered Entities)

2. Effects of Various Options

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

   1. Costs of Implementation

   2. Benefits of Implementation

5. Conclusions

   3. Guiding Principles for Standard Selection

1. Overview

2. General Regulations Text

   1. Background

   1. Summary

      This proposed rule recommends the adoption of a set of standards that will facilitate the electronic exchange of clinical and administrative data to further improve the claims adjudication process when additional documentation (also known as health care claim attachments) is required. This rule proposes two X12N transaction standards to be used--one to request the information and one to respond to that request with the answers or additional information. This rule also proposes the use of Health Level 7 (HL7) specifications for the content and format of communicating the actual clinical information. And finally, this rule proposes the adoption of the Logical Observation Identifiers Names and Codes, or LOINC[supreg] for specific identification of the additional information being requested, and the coded answers which respond to the requests. The combination of the X12N and HL7 standards for purposes of these transactions is proposed because the X12N standards are standards for exchanging administrative information, and the HL7 standards are standards for exchanging clinical information; the marriage of these standards for the electronic health care claims attachment transactions uses the capabilities and advantages of each type of standard. The LOINC[supreg] code set already has the most robust set of codes for laboratory results and clinical reports, and now includes the codes for the attachment ``questions'' or requests proposed in this rule.

      Electronic data interchange (EDI) is the electronic transfer of information (such as electronic health care claims and supplemental information) in a standard format. EDI allows entities within the health care system to exchange medical, billing, and other information to process transactions in a more expedient and cost effective manner. Use of EDI reduces handling and processing time and eliminates the risk of lost paper documents. EDI can therefore reduce administrative burdens, lower operating costs, and improve overall data quality.

      The health care industry already recognizes the benefits of EDI, and there has been a steady increase in its use over the past decade. In fact, for many years, health plans have been encouraging their health care providers to move toward electronic transmissions of claims and inquiries, both directly and through third parties such as health care clearinghouses, but the transition has been inconsistent across the board. It is assumed that the absence of standardization has made it difficult to encourage widespread increases in EDI and to develop software that could be employed by multiple users. The Health Insurance Portability and Accountability Act (HIPAA) of 1996 (Pub. L. 104-191, enacted on August 21, 1996) Transaction Rule standards, with entity type specific compliance dates in October of either 2002 or 2003, addressed that lack of standardization in the health care industry. Just as experience and process improvements have grown with EDI, experience with the standard transactions and automation will result in additional efficiencies and savings for both health care providers and health plans.

      The expectation, when standard national EDI formats and data content for health care transactions were adopted, was that the administrative burdens on health plans, health care providers, and their billing services would decrease. A standard EDI format allows data interchange using a common interchange structure, thus eliminating the need for users to program their data processing systems to accommodate multiple formats. Standardization of the interchange structure also involves specification of which data elements are to be exchanged; uniform definitions of those specific data elements in each type of electronic transaction; and identification of the specific codes or values that are valid for each data element.

   2. Legislation

      Through subtitle F of title II of HIPAA, the Congress added to title XI of the Social Security Act (``the Act'') a new subpart C, entitled ``Administrative Simplification.'' HIPAA affects several titles in the United States Code. Throughout this proposed rule, we refer to the Social Security Act as ``the Act,'' and we refer to the other laws cited in this document by their names. One purpose of subtitle F was to improve the efficiency and effectiveness of the health care system in general by encouraging the development of a more automated health information system through the establishment of standards and requirements to facilitate the electronic transmission of certain health information. The Congress included provisions to address the need for supplemental health care claim information in the form of electronic attachments to claims.

      Part C of title XI consists of sections 1171 through 1179 of the Act. These sections define various terms and impose requirements on the Department of Health and Human Services (HHS), health plans, health care clearinghouses, and certain health care providers, concerning the conduct of electronic transactions, among other things.

      HIPAA was discussed in greater detail in Standards for Electronic Transactions (65 FR 50312), published on August 17, 2000 (Transactions Rule), and the Standards for Privacy of Individually Identifiable Health Information (65 FR 82462), published on December 28, 2000 (Privacy Rule). Rather than repeating the discussion here, the reader is referred to those documents for further information. Specific information is provided in those

      [[Page 55992]]

      documents on the content of each section of HIPAA (for example, they explain that section 1173 of the Act requires the Secretary to adopt standards for transactions and data elements to be included in covered transactions; section 1174 of the Act describes the timetable for establishing standards and for compliance with those standards; sections 1176 and 1177 of the Act establish penalties for violations of the established standards; and so forth).

      Two provisions of the Act are particularly relevant to the electronic health care claims attachment standards being presented here:

      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.

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

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

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

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

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

   [[Page 55993]]

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

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

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

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

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

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

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

   The X12N Implementation Guides, HL7 AIS IG, HL7 AIS, and the LOINC[supreg] code set proposed for adoption in this proposed rule, are all copyrighted by their respective organizations, and each document includes a copyright statement. The copyright protection ensures the integrity of the materials and provides appropriate attribution to the developers. The materials are all available at no charge. Later in this preamble and in the regulations themselves, we provide the mailing addresses and Internet sites for the documents so that readers can obtain them in a convenient manner that will allow for their review, along with this proposed rule.

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

   1. Definitions

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

   Section 1171 of the Act defines several terms. The definitions set out in section 1171 of the Act and regulations at 45 CFR part 160 and subpart A of part 162 would also apply to the electronic health care claims attachment standards. There are also several new terms and definitions proposed that are related to the standards proposed in this rule, (see proposed Sec. 162.103 and Sec. 162.1900). The new terms, their definitions and examples or explanations thereof are as follow:

1. Ambulance Services means health care services provided by land, water, or air transport, and the procedures and supplies used during the trip by the transport personnel, to assess, treat or monitor the individual until arrival at the hospital, emergency department, home or other destination. Ambulance documentation may also include non- clinical information such as the destination justification and ordering practitioner.

2. Attachment Information means the supplemental health information

   [[Page 55994]]

   needed to support a specific health care claim. The health care claim attachment information is conveyed using both an X12 transaction and HL7 specification.

3. Clinical Reports means reports, studies, or notes, including tests, procedures, and other clinical results, used to analyze and/or document an individual's medical condition. These include discharge summaries, operative notes, history, physicals, and diagnostic procedures (radiology reports, electrocardiogram (for example, EKG), cardiac echoes, gastrointestinal tests, pathology, etc.) Clinical reports do not include psychotherapy notes.

4. Emergency department means a health care facility or department of a hospital that provides acute medical and surgical care and services on an ambulatory basis to individuals who require immediate care primarily in critical or life-threatening situations.

5. Laboratory Results means the clinical information resulting from tests conducted by entities furnishing biological, microbiological, serological, chemical, immunohematological, hematological, biophysical, cytological, pathology, or other examinations of materials from the human body. Laboratory results are used for the diagnosis, prevention, or treatment of any disease or impairment of, or assessment of, the health of the individual. Laboratory results are generated from the services provided in a laboratory or other facility that conducts those tests and examinations.

6. LOINC stands for Logical Observation Identifiers Names and Codes (LOINC[supreg]). It is a code set that provides a standard set of universal names and codes for identifying individual laboratory and clinical results as well as other clinical information. LOINC[supreg] codes are developed and maintained by the LOINC[supreg] committee and copyrighted 1995-2004, by Regenstrief Institute, Inc., and the Logical Observation Identifiers Names and Codes (LOINC[supreg]) Committee.

7. Medications means those drugs and biologics that the individual is already taking, that are ordered for the individual during the course of treatment, or that are ordered for an individual after treatment has been furnished. Medications include drugs and biologics that are ordered by a licensed practitioner, or that are being taken by the individual, independent of a health care provider's orders (for example, over-the-counter drugs). In the AIS documents, these are referred to as ``current medications,'' ``medications administered,'' and ``discharge medications.'' Current medications are those the individual is taking before an encounter that generates a new claim; medications administered are those given to the individual by a health care provider during the encounter; and discharge medications are those that the health care provider orders for the individual to take and use after release or discharge from the encounter, including the medications the individual may already have at home or those he or she may need to obtain following treatment.

8. Rehabilitation services means those therapy services provided for the primary purpose of assisting in an individual's rehabilitation program of evaluation and services. These services are: Cardiac rehabilitation, medical social services, occupational therapy, physical therapy, respiratory therapy, skilled nursing, speech therapy, psychiatric rehabilitation, and alcohol and substance abuse rehabilitation.

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

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

      For the remainder of this document, we will use the terms electronic claims attachments or electronic attachments to mean the same thing as electronic health care claims attachments. Similarly, the term Additional Information Specification may be referred to as an attachment specification or an AIS, and these terms are used interchangeably throughout the text. Since the term ``Implementation Guide'' is used by both HL7 and X12, we therefore use the full title for each document when they are referenced, such as the ``HL7 Additional Information Specification Implementation Guide.''

      This rule proposes to establish standards for electronic health care claims attachments. The proposed rule is specific to electronic health care claims attachments rather than paper attachments (hard copy medical records), since the purpose of the HIPAA administrative simplification provisions is to facilitate the development of a national electronic health information system. Standard electronic health care claims attachments will allow for the electronic exchange of additional clinical and administrative information to augment the HIPAA standard claim transaction.

      The goal of having a more automated, standardized approach to the exchange of information in the health care industry is longstanding. In 1994, the Workgroup for Electronic Data Interchange (WEDI) conducted a survey of the U.S. health care industry and documented its findings in a paper entitled: WEDI Attachments Workgroup Report, Initial Findings. Among other issues, this study examined the state of the health care industry as it related to the use of, and need for, electronic health care claims attachments standards. The survey identified hundreds of different paper-based attachments formats being used with health care claims. The attachments and their formats ranged from simple to complex and varied according to the type of information being requested, the services involved, and who was asking for the information. The WEDI report concluded with a set of recommendations, including the development of an electronic standard for exchanging this type of information between health care providers and health plans. Key among the recommendations were that: (a) Standardized data elements should be created for electronic claims attachments; (b) collaboration between affected entities should be encouraged; (c) standard ways to link data across transaction sets should be developed; and (d) a transaction set (pair of transactions) should be selected to send and respond to requests for additional information (similar to the health care claims status request and response transactions--the X12N 276/277 pair).

      CMS's work in the mid-1990s with WEDI, ASC X12, and HL7 resulted in the recommendation to use an HL7 version 2.4 message embedded within version 3040 of the ASC X12N 275 ``Additional Information to Support a Health Care Claim or Encounter Transaction,'' in other words, a response to a request for information. The embedded HL7 message would have contained structured and codified attachment data using the LOINC[supreg] coding system. For a variety of reasons, a proposed rule was never released with this recommendation. Since that time, HL7 moved ahead with development of its Clinical Document Architecture (CDA), which was a significant enhancement over the HL7 version 2.4 messaging. The CDA Release 1.0, August 2003, is an XML-based

      [[Page 55995]]

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

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

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

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

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

      XML was originally published by the World Wide Web Consortium (http://www.w3c.org) and designed as a standard markup language to

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

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

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

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

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

      [[Page 55996]]

      Demonstration of How XML Is Used Within a CDA Document

      Tag name

      Purpose

      .................. Outermost tag, contains an entire CDA document. . Contains information about the document arranged in subsections. .......... Contains a code that identifies the document type (for example, a discharge summary or cardiac rehabilitation plan). .................... Contains the name and identification number of the patient (individual). ....................... Contains the body of the report expressed in natural language with optional structured information. .................... A subdivision of the body containing a logical unit of information (for example, the discharge medications). .................... A subdivision of sections and other elements that describes the contents that will follow. ................ A subdivision of a caption that identifies the contents that follow using a LOINC[supreg] code.

      Source: HL7 white paper August 26, 2003. Specific to Release 1.0 of the CDA.

      An important feature of the CDA is that it allows the entire body of the XML document to be replaced by an actual image. The image might be a scanned copy of a page or pages from the medical record. The header is still present to support computer management of the document, but the clinical content can be conveyed entirely by an image or text document. This option is important to those health care providers that do not have a computer-based patient record system and cannot yet create electronic claims attachments in a structured format, but wish to reap some benefits from standardization and a certain level of automation. 4. Transactions for Transmitting Electronic Attachments

      As we describe in a later section entitled ``Candidates Considered,'' the standard setting organizations attempted to evaluate existing transactions for their potential to be used to send and receive attachment information electronically. Two transactions were ultimately selected because they only required modifications in a later version. In other words, while the existing X12N version 4010 standards did not satisfy the data content needs of the electronic health care claims attachments, revisions in version 4050 were made to accommodate these needs in time for this proposed rule. Thus, version 4050 of the X12N 277 ``request'' and version 4050 of the X12N 275 ``response'' are proposed to carry the attachment related questions and the related answers or responses. The X12N 277 version 4050 transaction transmits information about the particular claim in question and the question codes. The X12N 275 version 4050 transaction returns the claim identification (ID) information, and, in the Binary Data (BIN) segment, literally transports the responses to each question, with the response codes, narrative text, or actual imaged documents. The X12N transactions are flexible enough to accommodate the two format variants described in the next section, meaning the transaction can be used for either manual processing or computer automated processing. 5. Electronic Claims Attachment Types

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

      While it might be considered ideal by some to have electronic attachments for all health care claims business needs, it would be virtually impossible to identify and create standard specifications with appropriate codes for the full array of different attachment types required today. Furthermore, given changes in industry business practices, and new adjudication rules over the past decade, it is more important to determine, from health care providers and health plans, which claims most commonly require additional information for adjudication today, and what types of electronic attachments might be required in the next 5 to 10 years. It is equally important for covered entities to gain experience with a manageable number of electronic attachment types at the outset, so that technical and business issues can be identified to improve the process with each new electronic attachment specification that is developed.

      While the attachment information needed to support the full range of health care claims may be diverse, the same general transaction structure and administrative information can be applied to all electronic claims attachments to allow for some level of consistency. This proposal to encourage some form of electronic transmission, even of a scanned document in the early stages of implementation, at least represents a methodical approach towards moving the industry from paper to electronic communication for health care claims attachments. The advantage of the more general X12N transaction standards that can serve as the vehicles to carry any type of electronic attachment information, is that they can be coupled with the specific attachment ``documents''--coded or scanned--and remain available to handle new content-specific electronic attachment types as they are developed and approved.

      Based on industry feedback following implementation of the Transactions Rule, it became clear that pilot programs and early testing of new standards and processes were vital to the standards adoption process. In July 2004, HHS awarded funds for a Medicare pilot program to test the X12 request and response transactions, the LOINC[supreg] codes and at least two of the attachment types, using the HL7 Additional Information Specifications. The pilot is expected to demonstrate the capability of sending the X12 request transaction from a health plan to a health care provider, and then for the health care provider to send the X12 response, complete with the HL7 CDA in the BIN segment, back to the health plan. The health care provider will send both variants of each attachment type--a human variant (scanned document) and a computer variant (a coded response). These variants are described later in this preamble. We believe this pilot program will provide valuable insight as to the implementation challenges of electronic attachments, and perhaps even as to when health care providers and health plans could begin to move towards more structured, coded communication and adjudication. The SDOs are involved in the pilot as subject matter experts, so that as technical or operational challenges are identified with the standards, a core group of professionals with expertise can address them, and take corrective action on the X12 Implementation Guides, HL7 AIS or

      [[Page 55997]]

      LOINC[supreg] code set before the final rule is issued.

      In this proposed rule, we propose six specific electronic attachment types, each with data content requirements related to treatment or services provided. These six attachments are: (1) Ambulance services, (2) emergency department, (3) rehabilitation services, (4) clinical reports, (5) laboratory results, and (6) medications. These six specific attachments were originally selected for development because there was industry consensus on their relevance to a significant percentage of covered entities and to those claims that typically require additional documentation. They also contain the types of information commonly found in attachments, for example, narrative text (such as nurses' notes), simple data points (such as the results of a single laboratory test), and more complex information (such as rehabilitation progress over time). In 2003, the HL7 ASIG work group began working on other electronic claim attachment specifications that were identified by the industry as being significant, including home health, periodontal care, and durable medical equipment (DME).

      Comments are invited as to whether the six proposed attachment types are still the most frequently requested by health plans, and if there are others that are equally or more pressing for the industry.

      In the future, any new electronic attachment types, or changes to the six attachments standards proposed here, would require the Department to follow the usual rulemaking process. If changes are requested of the six proposed attachments standards, as a result of public comments during the period between the proposed and final rule, it is highly likely that HL7 would be able to make and ballot such changes in time for their adoption in the final rule. New electronic attachment standards approved by the SDO but not adopted by the Department may be used on a voluntary basis between trading partners, but there is no regulatory authority over their use.

      The effect of adopting a limited number of attachments standards at first is to permit covered entities time to gain experience with new standards and to evaluate the technical and business impacts of such transactions. In the meantime, while the electronic attachment specifications for DME, periodontal care, and home health are still under development, covered entities are strongly encouraged to actively participate in the development, review and modification process, and to advance their own proposals for these and other electronic attachments.

      Any new electronic attachment specifications, such as the ones referenced above, will be developed in accordance with the framework of the HL7 CDA Release 1.0. If CDA Release 2.0 is approved, the HL7 ASIG will determine if the next set of AISs will use CDA Release 2.0, or continue to be built on Release 1.0. HL7 will advise HHS as to the industry impact if the later version of CDA is adopted, particularly since covered entities need to be able to use both versions without requiring additional system changes. Industry representatives interested in participating in the development process should work in collaboration with HL7.

      In fact, as these and other new electronic attachments are developed, we strongly encourage the health care provider and health plan segments of the industry to review them and then provide substantial input on the ``questions'' or LOINC[supreg] codes, and on the cardinality (priority values) of the data elements--in other words, which elements should be required and which should be situational or optional for each electronic attachment type. Health care providers and health plans will recall their implementation experiences with the Transactions Rule and have an appreciation of the extreme importance of evaluating and understanding both the technical and business requirements of the standards and guides, and of submitting their issues and recommendations to the SDOs, DSMOs, and the regulators. We also solicit industry input on the impact to servers and other data storage systems for processing and storing electronic files of clinical information, both coded and text or image based. 6. Format Options (Human vs. Computer Variants) for Electronic Claims Attachments

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

      The Department and the standard setting organizations are sensitive to the fact that many health care providers, particularly smaller practices that are not yet fully automated, may be looking for means to convert from paper to electronic records in a cost effective, staged manner. To encourage such a transition, the standard setting organizations have proposed an approach to electronic health care claims attachments that could provide the benefits of electronic transmission of the information for both the health care provider and the health plan but that would not require a large upfront investment in electronic medical records systems, or the immediate merging of financial/administrative and clinical systems. Under this proposal, the electronic health care claims attachments may be sent in one of three formats, shown in the table below. Two of the formats are in the category of Human Decision Variant, and the third format is a Computer Decision Variant. There is a lengthy discussion of these variants along with examples later in this preamble, based on a white paper written by members of HL7's Attachments Special Interest Group.

      Human Decision Variants: (1) Many health care providers may choose to send scanned or imaged documents in the X12 transaction, and health plans will use manual procedures to process them; a health plan employee will physically look at the contents of the attachment to adjudicate the claim. Simply put, the health care provider would send a virtual document inside the X12 transaction and the health plan would view it on the computer screen, or a printed hard copy. This process is one of the human decision-making variants because it allows for the transmission of scanned page images. After the image has been rendered (printed or viewed as a document), the information should be clear enough and contain sufficient data for a person--the health plan's employee--to make a decision about the claim. (2) The second type of human decision variant is even simpler: The health care provider responds to the electronic request using narrative text, such as a typed response to the question, again embedding this response into the BIN segment of the X12 transaction. The health plan employee reads the answer off the screen, or prints a hard copy for review.

      Computer Decision Variant: The computer decision variant contains additional information that is structured so that it can be electronically extracted for use in computer-based adjudication systems, using automated processing rules. The codes will literally be read and interpreted by the computer. Auto-adjudication is the use of computers, programmed with business rules and logic, to process a claim, making decisions as to whether to pay, how much to pay, and to whom to make the payment. It is a long-term goal for most health plans to be able to support auto-adjudication for as many claims as possible.

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

      [[Page 55998]]

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

      The human and computer variants do not differ in actual content. Both types of variants (human and computer) for each electronic attachment type have required and optional content elements, which are listed in the specification for that attachment. Both types of variants will satisfy the standard, as they will differ only with regard to whether or not structured and coded data are required. That is, in the computer variant, coded data are required, whereas in the human variants, coded data are not required. While both variant types will carry a LOINC[supreg] code or codes, they will be accompanied by the natural text translation (narrative text) in the same transaction, so the request will be understandable in either the human or the computer variant.

      Table 1.--Human vs. Computer Variants for Electronic Attachments

      Information Information sent as Variant

      representation

      * * *

      Human Decision.............. Scanned image....... Scanned image of pages from the medical record. Repeats LOINC[supreg] code from the request. Human Decision.............. Natural language Natural language text.

      text with captions that match the specified questions. Repeats LOINC[supreg] code from the request. Computer Decision........... Natural language Natural language text and structured text, captions information.

      identified by LOINC[supreg] codes and supplemented by coded information.

      Source: Gartner Research 2003.

7. Combined Use of Two Different Standards Through Standard Development Organization (SDO) Collaboration

   [If you choose to comment on issues in this section, please include the caption ``COMBINED USE OF DIFFERENT STANDARDS'' at the beginning of your comments.]

   As discussed in the previous section, claims attachment transactions contain both administrative and clinical information. Thus, attachment data could come from a health care provider's clinical record system, whether paper or electronic, as well as from its practice management or billing system. Historically, these two distinct areas (clinical vs. administrative) have been the domain of two different SDOs: HL7 focuses on clinical data standards, while X12 concentrates on administrative data and transactions. In 1997, a joint effort between HL7 and X12 produced several options that would facilitate the communication of both clinical and administrative data, as well as smooth the transition from paper to a standardized electronic process for health care claims attachment information.

   ASC X12N, through its Patient Information Standards Work Group (WG9), developed transactions and the accompanying X12 implementation guides to fulfill the administrative needs of an electronic attachment request and the response to that request. HL7, through its ASIG, developed the message structure and the additional information specifications employing LOINC[supreg] codes that were relevant to the major types of clinical data needed in claims attachments. The ASIG included HL7 representatives, members of X12's WG9, and several vendors and health care providers with HL7 experience. The purpose of proposing the combined use of both ASC X12N and HL7 standards is to address both the administrative and clinical aspects of the attachment transactions from a format and content perspective. However, because these two standards have not been used together before, we solicit industry feedback regarding this strategy.

   One of the benefits of standardizing health care claims attachments is that it allows health care providers to anticipate requirements from health plans regarding additional documentation for claims adjudication. This should present opportunities for providers to develop procedures and systems to collect the data specified in the X12 Implementation Guides and HL7 Additional Information Specifications. Health care providers would also be given considerable latitude on how to submit the information--with either narrative text, scanned documents or with fully coded data, permitting the use of some form of electronic attachments for health care providers that do not have computer-based medical record systems.

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

   4. Electronic Health Care Claims Attachment Business Use

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

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

      [[Page 55999]]

      to use the standard transaction format and structure for requesting and submitting these types of attachments, those transactions are not considered electronic claims attachments as defined in this proposed rule. 1. Electronic Health Care Claims Attachment vs. Health Care Claims Data

      Electronic health care claims attachments must not be used to convey information that is already required on every claim. Information needed for every claim is ``claims data'' that must be conveyed in the appropriate standard claim transaction. The purpose of a claims attachment is to convey supplemental information that is directly related to one or more of the services billed on the claim submitted by the health care provider when further explanation of those services is required before payment can be made by the health plan. There are even some current business practices that include 100 percent pre-payment medical review. This is when a health plan requires a specific health care provider to include certain supplemental information with all claims for a certain type of service.

      Over the past few years, health plan rules and policies regarding the additional data necessary to adjudicate a claim have evolved, and in fact, many health plans have begun to limit or reduce their requests for claims attachments. Therefore, it is critical that members of the health plan industry and the health care provider community actively engage themselves in the final development of this proposed rule so that the proposed attachments are indeed those which will yield significant benefits to health care providers and health plans alike. 2. Solicited vs. Unsolicited Electronic Health Care Claims Attachments

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

      In general, health care providers will submit their electronic health care claims attachment information to the health plan for certain claim types, upon request, after the health plan has received and reviewed the claim. This follows the course of claims adjudication today. Health plans may also request, in advance, that additional documentation (the attachment) accompany a certain type of claim for a specific health care provider, procedure, or service. The ASIG refers to this scenario, of sending attachment information with the initial claim, as an unsolicited attachment because a request was not made after the fact, using the standard request transaction. We are proposing that health care providers may submit an unsolicited electronic attachment with a claim only when a health plan has given them specific advance instructions pertaining to that type of claim or service.

      We are proposing such a restriction around ``unsolicited'' electronic attachments, because we believe that there are legal, business, and technical implications for health care providers, health plans, and their business associates for handling and processing unsolicited attachments without prior direction. If health care providers were permitted to submit unsolicited electronic attachments with any claim without prior arrangement with the health plan, there would be a number of issues, including compliance with the Privacy Rule's minimum necessary standards, and identifying the new business and technical procedures health plans would need to develop to review, evaluate, store, return, or destroy the unsolicited documents. Similarly, health care providers would need systems and processes to track submissions and returns.

      We also propose that for each specific claim, health plans may solicit only one electronic attachment request transaction which would have to include all of their required or desired ``questions'' and/or documentation needs relevant to that specific claim. Health care providers would be required to respond completely to the request, using one response transaction. The intent of these proposed requirements is to avoid inefficient, redundant processes. A health plan would not be able to extend adjudication through a lengthy process of multiple individual attachment requests for the same claim: submitting one LOINC[supreg] request code at a time, receiving the health care provider's response, and then submitting another transaction with another LOINC[supreg] code for additional information related to the same claim. Nor would a health care provider be able to send bits and pieces of the requested information at different times or dates. We propose this because it seems contrary to the goals of administrative simplification for covered entities to engage in a continuous loop of query and response in order to have a claim processed.

      We solicit feedback from the industry on this issue. 3. Coordination of Benefits

      There is considerable variation in how health care providers and health plans handle Coordination of Benefits (COB) and the communication of related claims information. However, with respect to electronic attachment requests and responses in a COB scenario, we assume that the primary health plan will request only the attachments it needs to adjudicate its portion of the claim. The secondary health plan would request its own attachments in a separate (X12N 277) transaction sent directly to the health care provider. In health plan- to-health plan (also known as payer-to-payer) COB transactions, the primary health plan may not know the secondary health plan's business rules, and therefore would not be expected or required to request an attachment on behalf of the secondary health plan. 4. Impact of Privacy Rule

      Before implementation of the Privacy Rule in 2003, health care providers often sent the individual's entire medical record to the health plan for the purpose of justifying a claim. Health plans and health care providers indicated that this practice reduced instances for which follow-up requests for more information were needed, since all possible information was supplied at once. That practice was often wasteful and time consuming, and it is now generally inconsistent with the ``minimum necessary'' standards contained in the HIPAA Privacy Rule at 45 CFR 164.502(b) and 45 CFR 164.514(d). These standards require covered entities to make reasonable efforts to limit requests for, or disclosures of, protected health information to the minimum necessary to accomplish the intended purpose of the request or disclosure. In situations where the minimum necessary standard applies, such as when a covered health care provider discloses protected health information to a health plan for payment, the standards prohibit disclosure of the entire medical record unless the entire medical record is specifically justified as the amount that is reasonably necessary to accomplish the purpose of the disclosure (45 CFR 164.514(d)(5).

      The Privacy Rule exempts from the minimum necessary standard any use or disclosure that is required for compliance with the Transactions Rule (45 CFR 164.502(b)(2)); thus, the minimum necessary standard does not apply to any required or situationally required data elements in a standard transaction. For example, if an identifier code were required on all electronic attachment request transactions to create a connection between the electronic attachment request

      [[Page 56000]]

      transaction and the associated health care claim, then health plans would not need to apply the minimum necessary standard to that data element to determine whether they could request that information. However, the minimum necessary standard would apply to data elements for which health plans or health care providers may exercise discretion as to whether the information should be provided or requested in the transaction. For example, health plans must apply the minimum necessary standard when selecting the attachment information to be requested in a particular electronic attachment request transaction.

      A health care provider may rely, if such reliance is reasonable under the circumstances, on a health plan's request for information, or specific instructions for unsolicited attachments, as the minimum necessary for the intended disclosure. Such reliance is not required, however, and the covered health care provider always retains the discretion to make its own minimum necessary determination.

      For health care providers who choose to submit attachment information in the form of scanned documents, efforts will need to be made to ensure that those documents do not contain more than the minimum necessary information.

      We solicit comments on the extent to which the use of the proposed electronic attachment standards will facilitate the application of the ``minimum necessary'' standard by covered entities when conducting electronic health care claims attachment transactions. 5. Impact of the Security Rule

      All covered entities need to comply with the Security Rule no later than April 20, 2005, except for small health plans, which must comply no later than April 20, 2006. The Security Rule applies to all covered entities, and, therefore, will apply to the transmission of electronic health care claims attachments. There are four overarching security requirements with which covered entities must comply: (1) Ensure the confidentiality, integrity, and availability of all Electronic Protected Health Information (EPHI) that the covered entity creates, receives, maintains, or transmits; (2) protect against any reasonably anticipated threats or hazards to the security or integrity of EPHI; (3) protect against any reasonably anticipated uses or disclosures of EPHI that are not permitted under the Privacy Rule; and (4) ensure compliance with the security regulations by members of the workforce. The types of security measures required by the Security Rule fall generally into three categories: administrative, physical, and technical safeguards. The Security Rule also has standards for documentation and organization requirements. Since the requirements are intended to be scalable, each covered entity must take into account its size, complexity, capabilities, technical infrastructure, and hardware and software security capabilities; the cost of security measures; and the probability and criticality of potential risks to EPHI.

      The systems used to transmit electronic claims attachments will likely be the same systems used for other electronic transactions. Therefore, any efforts to comply with the Security Rule should be effectively incorporated into electronic attachment processing.

      Most covered entities (with the possible exception of small health plans) will be in compliance with the Security Rule by the time of this proposed rule; and all health plans will have fully implemented their security programs by the time the final rule is published for electronic health care claims attachments. 6. Connection to Signatures (Hard Copy and Electronic)

      This regulation does not propose requirements for Electronic Signatures (e-signatures) because a consensus standard does not presently exist that we could propose to adopt, nor does any Federal standard currently govern the use of electronic signatures for private sector health care services. Federal agencies that are also covered entities have to comply with the Office of Management and Budget (OMB) guidance on e-signatures in the context of the Government Paperwork Elimination Act (OMB notice 5/2000, 65 FR 25508) and the Federal Information Security Management Act (Title III of the E-Government Act of 2002). And, while the OMB has responsibility for coordinating and implementing the adoption and use of electronic signature technologies for Federal agencies, this effort is not related to HIPAA transactions per se, and we do not have authority to require the private sector to comply with rules that are only applicable to Federal agencies. At the time of this proposed rule, other agencies and Federal initiatives involved in the evaluation and development of standards for electronic signatures include the Department of Defense (DOD), the National Institute for Standards and Technology (NIST), and the Federal Consolidated Health Informatics Initiative (CHI).

      We are aware that virtually all health plans, including the Medicare and Medicaid programs, require signatures certifying certain types of services, such as sterilization, certain rehabilitation plans, and authorization for certain types of equipment. For example, health plans may request a paper copy of the signature page of a rehabilitation plan, or they may accept the response code indicating that the signature is on file. The CDA Release 1.0 requires the acquisition of the signature to be documented via the component, so there is an accommodation for signature within the standard, but not a requirement for an electronic signature specific to HIPAA.

      We solicit input from the industry on how signatures should be handled when an attachment is requested and submitted electronically. 7. Connection to Consolidated Health Informatics Initiative

      Several agencies within the Federal government that deal with the delivery of health services, including the Departments of Health and Human Services, Veterans Affairs, and Defense, have adopted a portfolio of health information interoperability standards that will enable all agencies in the Federal health enterprise to ``speak the same language'' based on common, enterprise-wide business and technology architecture. This program is known as he Consolidated Health Informatics (CHI) initiative. In 2003, CHI targeted 24 ``domains'' for data and messaging, from laboratory results to vocabulary for nursing, to medications. The CHI initiative looked to the private sector to identify particular electronic health clinical data standards for adoption, researched these standards, and is now beginning to build the plan to implement them within Federal agencies as program requirements dictate. On May 6, 2004, the Secretaries adopted standards for 20 domains and subdomains; among others, these included: HL7 messaging standards for clinical data, NCPDP standards for ordering from retail pharmacies, IEEE1073 to allow health care providers to monitor medical devices, DICOM to enable images of diagnostic information to be retrieved and transferred between devices and workstations, LOINC[supreg] for the exchange of clinical laboratory results, SNOMED CT[supreg] for certain interventions, diagnosis and nursing terminology, and a variety of terminologies for medications. We include a reference to CHI here to clarify that while the Federal government is reviewing and adopting standards for its intra-agency communications, these are

      [[Page 56001]]

      not inconsistent with the private sector, with whom significant transactions are exchanged, and that furthermore, the work and outcome of CHI related activities do not conflict with HIPAA. Indeed, CHI has adopted HIPAA standards as the standards for the exchange of administrative information. The complete list of adopted standards and other details about CHI may be found at http://www.egov.gov or http://www .whitehouse.gov/omb/egov/gtob/health--informatics.htm. 8. Health Care Provider vs. Health Plan Perspective

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

      Health care providers and health plans regard claims attachments quite differently. Health care providers would prefer to keep attachments to a minimum and regard requests for additional claims- related information as unnecessarily lengthening the payment cycle. Health plans consider the use of attachments as a necessary tool to ensure appropriate payment decisions, maintain quality assurance, and minimize fraud and abuse. What a health care provider may regard as an unnecessary and/or onerous request for information may be viewed by the requesting health plan as critical to ensure that payment is being made according to the provisions of the patient's policy and benefits, for which the health plan pays. This rule does not propose to set out requirements for the appropriateness of requests for additional information. However, the proposed attachment standards are designed to reduce miscommunication and multiple requests for information by providing specificity to both the request for information and the response, and by establishing specific limits to the content of the attachment.

      Health Care Provider vs. Health Plan Implementation: In accordance with 1175(a) of the Act and 45 CFR part 162, Sec. 162.923 and Sec. 162.925, health plans may not reject any electronic transaction simply because it is being conducted as a standard transaction. This applies to the proposed transactions for electronic health care claims attachment requests and responses. So, for example, a health care provider may direct a health plan to send any request for additional documentation to it or its business associate in standard form, for those attachment types for which a standard has been adopted here, and the health plan must do so. The health care provider may also request that the health plan accept the attachment information in the standard response transaction.

      However, as we have stated in the past, we do not believe that the use of a standard transaction can create a business relationship or liability that does not otherwise exist. 9. Health Care Clearinghouse Perspective

      Health care clearinghouses are covered entities under HIPAA, and must be able to accept and transmit a standard transaction when asked by a health care provider or health plan for whom they serve as a business associate for those functions. Since both health care providers and health plans have dependencies on the health care clearinghouses, it is imperative that the health care clearinghouse industry participates actively in the rulemaking process, standards review, and implementation assessment as well. It would be helpful if health care clearinghouses were among the first of all entity types to come into compliance with these standards so that testing between trading partners--health care providers and health plans--could be executed in a timely fashion.

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

      [[Page 56002]]

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

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

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

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

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

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

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

      Under HIPAA, the Secretary may adopt code sets developed by either private or public entities, including proprietary code sets. The Act also allows the Secretary to adopt standards other than those established by an SDO if the different standards will reduce costs for health care providers and health plans, and other applicable statutory requirements are met. Both of the code set candidates evaluated for inclusion were proprietary code sets that had established mechanisms for maintenance related updates, were available without payment of licensing or use fees, and were already in use by the medical community.

      Washington Publishing Company is the exclusive publisher and copyright

      [[Page 56003]]

      holder of the X12N health care claim status reason codes. The Regenstrief Institute, Inc. and the LOINC[supreg] Committee are the copyright holders of the LOINC[supreg] code set and database.

      LOINC[supreg] provides sets of universal names and identification codes for identifying laboratory and clinical test results as well as other units of information that are meaningful in electronic claims attachments. The LOINC[supreg] code for a name is unique and permanent and has no intrinsic structure except that the last character in the code is a check digit and must always be transmitted with a hyphen before the check digit (for example, ``10154-3''). The LOINC[supreg] codes offer a comprehensive array of coded topics designed to support detailed supplementary information.

      The Remark and Reason Code Committee of X12N maintains the health care claim status reason codes that are currently used in version 4010 of the X12N 277 Claims Status response transaction. This transaction provides information about the general status of a claim in response to a request made for such status, using version 4010 of the X12N 276 transaction.

      Ultimately, the standards organization determined that the health care claims status codes were significantly less definitive and efficient than the LOINC[supreg] codes for communicating detailed or specific clinical information to supplement a claim, and made a recommendation to the Secretary to adopt LOINC[supreg] for the electronic health care claims attachment transactions.

      The recommendation was supported through a 1996 ``Proof of Concept'' study sponsored by CMS, using an early version of the X12N 277-Health Care Claim Request for Additional Information, coupled with the health care claim status reason codes. Eight provider/vendor partners and five plans that were also Medicare contractors participated in the effort to evaluate the suitability of the X12N 277 and the health care claims status codes for electronic attachment use (Executive Report Medicare Proof of Concept Study: Standard Electronic Requests for Additional Medical Review Information). This study identified a number of barriers related to the use of health care claim status reason codes for the purpose of the electronic attachments transactions. Specifically, the health care providers did not view the codes as sufficiently ``concise'' in providing the request. They predicted that this lack of precision would increase time spent ``pulling and copying medical records'' and submitting responses such as ``sent the whole record,'' which would increase costs to the health care provider and the health plan. There were also concerns about the level of specificity, clarity, and redundancy of the codes. In fact, a cross walk of the claims status codes to the existing standard codes could not be accomplished, and the study showed that, in many cases, several claim status reason codes were required at one time in order to convey an appropriate level of clarity to the request. At the time of the study, there were 406 local (Medicare) codes being used, and 50 percent of them could not be mapped to the health care claim status reason codes.

      The example in Table 2, Comparison of LOINC[supreg] Codes and Health Care Claim Status Reason Codes for Requesting Additional Information, illustrates the brevity and efficiency associated with using LOINC[supreg] codes when compared to health care claim status reason codes. In this example, the health plan is requesting information pertaining to treatment, progress notes, and attainment of rehabilitation goals for a rehabilitation service.

      Table 2.--Comparison of LOINC[supreg] Codes and Health Care Claim Status Reason Codes for Requesting Additional Information

      LOINC[supreg] code

      Health care claim Health care claim status LOINC[supreg] code

      definition

      status reason code reason code definition

      R4: 18658-5:LOI................... R4 = Requests for

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

      additional information/ and documentation 18658-5

      documentation; 310 = = Psychiatric

      Progress notes for the 6 Rehabilitation treatment

      months prior to plan, progress notes, and

      statement date; 3F = attainment of goals LOI =

      Rehabilitation facility. Specifies this is a LOINC[supreg] code.

      .......................... R4:436:3F............ R4 = Requests for additional information/ documentation; 436 = Short term goals; 3F = Rehabilitation facility.

      .......................... R4:437:3F............ R4 = Requests for additional information/ documentation; 437 = Long term goals; 3F = Rehabilitation facility.

      The LOINC[supreg] code 18658-5 asks the exact question the plan wants answered with a single code. In contrast, the health care claim status reason codes cannot exactly replicate what the plan wants answered; the closest match requires three separate requests. In this example, the use of the existing set of reason codes would result in the health care provider sending data that the health plan did not request and does not need because the code for progress notes includes an instruction to send 6 months of information. 3. Implementation Specifications for Sending and Receiving Additional Health Care Information Within a Transaction

      As described earlier, the HISB reviewed available transaction options and recommended that new versions of the X12N 277/275 standards be created and adopted for the transmission of electronic health care claims attachment information. In particular, the X12N 275 response transaction had the advantage of being capable of transmitting other standards within the transaction and the ability to transmit large amounts of information within the BIN segment of the transaction. Most of the supplemental information requested by health plans is clinical information, usually detailed with specific quantitative measurement, lab results, and specific medical reports. Clinical information of this nature could already be accommodated in HL7 transactions.

      Thus, the BIN segment of the ASC X12N 275 (response) transaction would be able to hold all of the attachment information requested by the health

      [[Page 56004]]

      plan. In 1997, the NUBC, the NUCC, and the NCVHS were consulted on the data format to be used in the BIN segment. Originally, the NUCC recommended that a choice between unstructured ASCII text alone and structured HL7 be given. However, much discussion occurred during the NCVHS meeting itself, and after considering the comments received, and discussion with health insurance EDI professionals, the NCVHS and WG9 determined that the best options for content structure were the following:

1. HL7 structure--this option would require the structure and content of the Additional Information Specification (AIS) to be based entirely on HL7 defined information for each message. HL7 would define the data content and structure for each AIS based on existing HL7 conventions;

2. HL7 plus ASCII text structured--this option would allow, in addition to the HL7 structure, additional specifically formatted text information (defined lengths, etc.). This would limit the amount and type of additional information that could be submitted; or

3. HL7 plus ASCII text unstructured--this option would allow, in addition to the HL7 information, any additional text information.

   The NCVHS Subcommittee on Standards and Security held hearings on this specific issue on June 15, 1998 in Washington DC. Representatives from ASC X12N, HL7, NUBC, NUCC, HHS, providers, a translator firm, and a health care clearinghouse spoke to the advantages and disadvantages of each of the options. After discussion, the NCVHS Subcommittee voted to recommend to the full committee Option 1, which would require HL7 messages within the BIN segment of the ASC X12N 275 version 4020-- Additional Information to Support a Health Care Claim or Encounter implementation guide. This approach would accommodate a broad spectrum of possible information since the HL7 standard permits unstructured ASCII text within the body of an HL7 structure. The HL7 standard supports the additional information specifications that represent the specific supplementary information being submitted in the form of an attachment. Thus, the AIS, formatted in accordance with the overarching HL7 Implementation Guide, represents the data to be transmitted in the BIN segment of the X12N 275 transaction.

   The LOINC[supreg] codes offer a comprehensive array of coded topics that readily support detailed supplementary information that can be transmitted by HL7 messages within the BIN segment, and these codes provide sets of universal names and identifying codes for conveying laboratory and clinical test results as well as other units of information that are important in health care claims attachments. The LOINC[supreg] process for reviewing and updating the database of codes and values also offers sufficient opportunities for growth and expansion. Therefore, LOINC[supreg] was determined to be the best match along with the recommended X12 transaction standards and HL7 specifications.

   7. Proposed Standards

      We are proposing certain industry consensus standards that, when used together, provide the functionality necessary for the electronic health care claims attachment. No other industry standards are in use today for this purpose. The proposed standards are fully compatible with the other ASC X12 and HL7 standards and can be translated to and from various systems using software programs (commonly referred to as ``translators'' and ``interface engines'') that are increasingly used by industries using ASC X12 transactions and HL7 messages.

      This rule proposes the following for adoption as national standards for electronic health care claims attachments: 1. Code Set

      The industry organizations that developed the electronic claims attachment standards proposed the adoption of LOINC[supreg] as the code set for representing the specific elements of attachment information. In 1998, NCVHS held several days of hearings on electronic health care claims attachments, including presentations on the status of a pilot for the request transaction, the types of attachments being requested by health plans, and the use of the LOINC[supreg] code set for describing and/or itemizing the information being requested, and the information being submitted in response to that request. Based on the testimony, NCVHS recommended that the LOINC[supreg] code set be adopted to support electronic health care claims attachments. We support the recommendation, and have included the adoption of LOINC[supreg] codes as a part of this proposed rule. HL7 has created companion LOINC[supreg] modifiers that would add further specificity to the LOINC[supreg] code itself. These modifiers refine the requests in terms of time frame; for example, on, before, or during a particular encounter, or in terms of item modifiers, such as abnormal, worst, first, last, etc. We therefore also propose to adopt the LOINC[supreg] modifiers as national standards for the electronic health care claims attachments.

      As we have described earlier, the HL7 specification uses LOINC[supreg] codes for each proposed electronic claims attachment, and these AIS specify the required content and LOINC[supreg] codes for each electronic attachment. It is, therefore, imperative for all segments of the industry to comment on the proposed attachment content, the attachment criteria and the procedures, so that the standards can be validated, and any appropriate revisions to those standards made and approved in time for the final rule.

      The LOINC[supreg] code set, similar to ICD-9, CPT-4, HCPCS, CDT and other proprietary code sets, may be updated with new codes as needed to reflect new technology, services, and procedures. Similar to other code sets, maintenance updates of the LOINC[supreg] code set are permissible and do not require regulatory action, though the formal procedures of the code set maintainer must be followed for requesting, adding and communicating new codes to each code set. The addition of new codes to the LOINC[supreg] code set is considered a routine code set maintenance activity and does not require rulemaking because, in part, additions (and deletions) do not change the format or field size of the codes. Such maintenance simply allows the addition or deletion of codes to accommodate clinical advances and industry needs. Modification, on the other hand, involves actual format changes to some or all of the codes, or the code set in its entirety, such as converting a numeric code set to an alphanumeric code set. Such a change would likely require significant business and system changes and programming. Therefore, use of a modified code set would require rulemaking to allow the industry time to evaluate the impact and provide feedback to the Department, the code set maintainers, and other relevant parties with authority.

      To date, we have no information to indicate that LOINC[supreg] is being evaluated for any kind of modification and therefore we are comfortable recommending its adoption for use with electronic health care claims attachments. The most common updates to LOINC[supreg] will likely be in the categories of laboratory results, clinical reports, and medications, as new diagnostic studies, clinical reports, expansion of lab technology, new tests and new drug regimens are adopted by the industry. The proposed HL7 attachment specifications for laboratory

      [[Page 56005]]

      results, clinical reports and medications allow for the use of new LOINC[supreg] codes in the response, once these become available in the LOINC[supreg] code set and are needed for communication between HIPAA trading partners.

      With respect to the attachment data that can be requested, also known as the ``questions'' or attachment components, the AISs for ambulance, emergency department, medications, and rehabilitation contain a finite list of LOINC[supreg] codes that may be used. New questions, and therefore potential new LOINC[supreg] codes for the current AIS that are proposed as a result of the public comment before publication of the final rule would need to go through the HL7 ballot process; if approved in time, the new questions, in the form of LOINC[supreg] codes, could be incorporated in the AIS adopted in the final rule. Any LOINC[supreg] question code additions or changes to the specifications made after publication of the final rule would require rulemaking, as do changes to other standards. New LOINC[supreg] codes may be requested through Regenstrief, by following the procedures outlined in the LOINC[supreg] manual, Appendix D. Submissions may be made via e-mail or regular mail, and the RELMA tool offers use of an ACCESS database to ensure the completeness of the request. Commenters are encouraged to become familiar with the RELMA tool, the LOINC[supreg] database and the LOINC[supreg] manual.

      We specifically do not name a code set for medications or drugs for this proposed rule. NDC was repealed as the code set for non-retail pharmacy drugs and biologics under the Transactions Rule, and no other single code set for drugs has been adopted for non-retail pharmacy transactions. The HL7 AIS for medications allows requests for current medications, medications administered during treatment, and discharge medications. The AIS is written such that it functions with any narrative text, codes or coding system that are agreed to between trading partners; it does not require any single code set to be used. The AIS has a section devoted to special considerations for the drug codes and reporting requirements that will work in both human and computer decision variants. Industry representatives should read this AIS in order to provide feedback to HHS and the SDOs regarding this approach to medication documentation. 2. Electronic Health Care Claims Attachment Request Transaction

      We are proposing to adopt the ASC X12N 004050X150 (ASC X12N 277-- Health Care Claim Request for Additional Information) transaction to convey the request for the electronic claim attachment. It would identify the claim and related data needed. This transaction would serve as an ``electronic envelope,'' conveying the LOINC[supreg] code or codes appropriate to that electronic attachment request. Only LOINC[supreg] codes specified in the HL7 AIS booklets and LOINC[supreg] code tables for the particular electronic attachment can be requested. Medications, laboratory results, and clinical reports may use any of the relevant codes in the LOINC[supreg] code set. The responding transaction (the X12N 275) would echo the requester's LOINC[supreg] request codes, and provide the data associated with those LOINC[supreg] codes, in either the human or computer decision variants.

      In part 162, we would specify the ASC X12N Implementation Guide 004050X150 (ASC X12N 277--Health Care Claim Request for Additional Information) as the standard for requesting electronic health care claims attachment information. Note that LOINC[supreg] codes being used to request specific information must be those specified in the appropriate AIS as follows:

      1. CDAR1AIS0001R021 Additional Information Specification 0001: Ambulance Service Attachment. The instructions and LOINC[supreg] code tables for requesting ambulance supplemental information are contained in this guide.

      2. CDAR1AIS0002R021 Additional Information Specification 0002: Emergency Department Attachment. The instructions and LOINC[supreg] codes for requesting emergency department supplemental information are contained in this guide.

      3. CDAR1AIS0003R021 Additional Information Specifications 0003: Rehabilitation Services Attachment. The instructions and LOINC[supreg] code tables for requesting rehabilitation services supplemental information are contained in this guide.

      4. CDAR1AIS0004R021 Additional Information Specifications 0004: Clinical Reports Attachment. The instructions and LOINC[supreg] code tables for requesting clinical reports supplemental information are contained in this guide.

      5. CDAR1AIS0005R021 Additional Information Specifications 0005: Laboratory Results Attachment. The instructions and partial list of LOINC[supreg] codes for requesting laboratory results supplemental information are contained in this guide.

      6. CDAR1AIS0006R021 Additional Information Specifications 0006: Medications Attachment. The instructions and LOINC[supreg] codes for requesting medication supplemental information are contained in this guide. 3. Electronic Health Care Claims Attachment Response Transaction

         We are proposing to adopt the ASC X12N 004050X151 (ASC X12N 275-- Additional Information to Support a Health Care Claim or Encounter) as the response transaction to convey the claim identification and related data, such as individual name, provider name, date and type of service, that are needed to match the information to the original claim. The claim identification and related data are conveyed in the BIN segment of the transaction that serves as an ``electronic envelope.'' This envelope also conveys the HL7 message that carries the supplementary electronic health care claims attachment data in the form of an AIS.

         Information conveyed by the HL7 message would be the specific AIS provided in response to the LOINC[supreg] code or codes contained in the request, or as an unsolicited (but pre-arranged) electronic attachment submission. Each electronic attachment type is identified by a unique LOINC[supreg] code that indicates its name and appears in the header of the message for identification purposes; for example, psychiatric rehabilitation has its own unique LOINC[supreg] code of 18594-2. Other LOINC[supreg] codes used in the body of the message will specify the specific information related to that service that is desired (for example, the psychiatric rehabilitation plan). The individual booklets for each HL7 AIS contain the instructions and LOINC[supreg] code tables that define all of the data content that may be used in that particular electronic attachment.

         The LOINC[supreg] code set provides a set of subject modifier codes that are categorical; that is, an identifier code can apply to a group of related reports. For example, Clinical reports can be identified by the type of equipment used (for example, CAT scan report); the body part examined (report of x-ray of left wrist), the subdivision of the laboratory performing the analysis (microbiology), or a challenge to the system (cardiac stress test). Different combinations of these facts can produce information relevant to a clinical reports AIS. Therefore, it is important that the request transaction, based upon the ASC X12N 277 version 004050x150 being submitted, use the LOINC[supreg] Report Subject Identifier Code(s) that most clearly represents the attachment information needed. The LOINC[supreg] Report Subject Modifier Codes can be found in the LOINC[supreg] Committee publication.

         [[Page 56006]]

         In part 162, we would specify the ASC X12N Implementation Guide 004050X151 (ASC X12N 275--Additional Information to Support a Health Care Claim or Encounter and the HL7 CDAR1AIS0000RO21 HL7--Additional Information Specification Implementation Guide, and HL7--Clinical Document Architecture Framework Release 1.0) as the standards for conveying electronic health care claim attachments, and we would specify the following six specifications as the standards for the electronic health care claims attachments:

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

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

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

      4. CDAR1AIS0004R021, Additional Information Specification 0004: Clinical Reports Attachment, Release 2.1, based on HL7 CDA Release 1.0. The Clinical Reports AIS allows for the electronic transmission of a wide variety of clinical reports, such as electrocardiograms and radiology reports. Examples of data elements included in this AIS are specimen source, reason for study, and observation values. The instructions and LOINC[reg] codes for transmitting clinical reports by an AIS cover a wide variety of functional topics. These include, but are not limited to, discharge summaries, operative notes, history and physicals, clinic visits, other assessments, and all types of diagnostic procedures including laboratory studies.

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

      6. CDAR1AIS0006R021, Additional Information Specification 0006: Medications Attachment. Release 2.1, based on HL7 CDA Release 1.0. The Medications AIS allows health care providers to report on the medication an individual is currently taking, or was given during a course of treatment, or was provided upon discharge. Data elements include individual identifiers, medications provided, and units of the medication.

         New AIS addressing durable medical equipment, home health, and periodontal charting are currently being developed by HL7. We solicit comments regarding which other attachments most impact the health care industry with respect to the exchange of clinical and administrative information, specifically for the purpose of claims adjudication. 4. Examples of How Electronic Health Care Claims Attachments Could Be Implemented a. Use of the Proposed Transactions, Specifications, and Codes for Electronic Health Care Claims Attachments

         An X12N 277 request for claims attachments may be used to electronically request one or more attachment types, and the X12N 275 response can be used to transport one or more electronic attachment types. The X12 Implementation Guides describe how the LOINC[supreg] codes and LOINC[supreg] modifiers are to be used, and how the segments within the BIN segment of the response transaction are used to carry the actual attachment information. Individual LOINC[supreg] codes and LOINC[supreg] modifiers are defined for each component of the electronic attachment, specific to each discipline. The modifiers permit the request to be limited by date, time, number of repetitions, and other factors. Each AIS includes tables of the LOINC[supreg] codes needed to request the attachment data specific to each claim type. However, a request for Emergency Department information may include a request for data on laboratory results or diagnostic studies either as part of a full Emergency Department attachment or as a Laboratory Results attachment or a Clinical Reports attachment. In other words, it is possible that an electronic attachment request for one claim may require multiple attachment types. The Emergency Department attachment specification defines all of the LOINC[supreg] codes necessary to electronically request attachment data specific to treatment in an emergency department. In fact, there are three codes that represent an explicit request for the complete set of data components relevant to emergency department events, inclusive of laboratory results and diagnostic studies. Alternatively, the health plan may request only one piece of information for a specific attachment type. For example, it may request only the associated lab results for the ER visit. When only lab results or diagnostic studies are requested for an emergency department encounter, the results and studies are to be reported as defined in the Laboratory AIS, but the information is to be sent in the response to the specific request related to the services provided in the emergency department; the claim ID will be used to match up the data.

         As another example, using the Rehabilitation AIS, the LOINC[supreg] codes for rehabilitation services include some codes that can be used to request or send information about medications the individual reported taking as part of the rehabilitation treatment plan. The specifications for sending medications are described in section two of the AIS for Medications. The sender will use the instructions in the Medications AIS for sending medication information related to the rehabilitation plan claim and the required additional documentation/ attachment.

         Again, it is critical for the industry to evaluate the HL7 AISs, the X12 Implementation Guides and the LOINC[supreg]

         [[Page 56007]]

         code set to fully evaluate and understand their use and the implications on technical systems and business operations. b. White Paper from HL7

         A white paper entitled ``HIPAA and Claims Attachments: Preparing for Regulation'' was written and published in August 2003 by the ASIG at HL7. This white paper, reproduced in part in this preamble with specific written permission from HL7, provides sample scenarios depicting how health care providers and health plans could comply with the proposed standards for electronic attachment transactions. The entire white paper is also available at no charge on the HL7 Web site, http://www.HL7.org.

         The document is included here to highlight some of the possible approaches to implementation, and to depict how electronic health care claims attachments requests and responses could work between health plans and health care providers. The scenarios may be useful to covered entities in determining which path may be the most appropriate for a particular setting or entity type. These scenarios are not the only options for implementation and compliance; rather, they were crafted by HL7 in an effort to help the industry understand how electronic health care claims attachments could be implemented. The descriptions and pros and cons for each scenario were taken in their entirety from the white paper, and therefore the term ``payer'' instead of ``health plan'' is used throughout this section. These two terms have the same meaning for purposes of this discussion. Any comments on the white paper may be submitted to the ASIG, through the HL7 Web site.

         The text for the HL7 white paper begins here:

         Providers and payers have the latitude to choose a path that suits their own balance of low/high impact vs. low/high business benefit. In general, the scenarios are listed from low impact/low business benefit to high impact/high business benefit. Both payers and providers also have the latitude to analyze their own business needs and prioritize the accommodation for each individual attachment. For example, if either payers or providers review their current volume of activity and determine that one or two attachments encompass a disproportionate percentage of all their attachment volume, they would prioritize the accommodation of those one or two attachments as structured data to facilitate auto-adjudication.

         All following scenarios represent the processing that takes place either after a payer has requested additional documentation from the provider or when the provider has elected to submit additional information in the same transmission as the initial claim. The payer and provider scenarios are not dependent upon each other. Each payer and provider can choose a path most suitable to the situation independent of the means used by the others with whom the payer and provider exchange standardized electronic transactions.

         Provider Compliance:

         Provider Scenario 1: A provider keeps patient data in paper records. The provider's billing application is adapted to accept scanned images. Once the appropriate attachments documents are scanned from the paper medical record, the billing application associates that scanned image with a claim and includes the scanned image as an attachment in submission to the payer as needed.

         [GRAPHIC] [TIFF OMITTED] TP23SE05.051

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

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

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

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

         [[Page 56008]]

         [GRAPHIC] [TIFF OMITTED] TP23SE05.052

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

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

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

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

         [GRAPHIC] [TIFF OMITTED] TP23SE05.053

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

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

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

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

         [[Page 56009]]

         [GRAPHIC] [TIFF OMITTED] TP23SE05.054

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

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

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

         Payer Options

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

         [GRAPHIC] [TIFF OMITTED] TP23SE05.055

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

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

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

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

         [[Page 56010]]

         [GRAPHIC] [TIFF OMITTED] TP23SE05.056

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

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

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

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

         [[Page 56011]]

         [GRAPHIC] [TIFF OMITTED] TP23SE05.057

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

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

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

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

         [GRAPHIC] [TIFF OMITTED] TP23SE05.058

         [[Page 56012]]

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

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

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

         The text for the HL7 white paper ends here.

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

      Health plans would be required to be prepared to receive and send only the standards specified in Sec. 162.1915 and Sec. 162.1925 for the identified transactions. No other electronic transaction format or content would be permitted for the identified transactions. We intend for covered entities to use the standard transactions and the approved attachment specifications as they apply to the six named attachment types.

      The use of the standard electronic health care claims attachments would not preclude the health plan from using other processes or procedures to verify the information reported in the attachment documentation.

      Under the proposed rule, health plans may continue to use manual processes (such as paper forms, letters, faxes, etc.) to request additional documentation from a health care provider, even for the attachment types listed in this proposal. However, whenever such a request is made electronically, it must be made using the standard. Furthermore, if the health care provider asks that the transaction be sent using the standard, the health plan must comply.

      As stated earlier, it is possible that multiple AIS apply to a particular electronic claim attachment request. The clinical reports, medications, and laboratory results AIS could be used to request additional information about any service in a particular claim. However, the ambulance, emergency department, and rehabilitation services AIS can only be used to request information about the specific type of services to which they refer. When the ASIG developed the first set of attachment types, three were for specific types of services-- ambulance, emergency department, and rehabilitation. Since those services often necessitated tests and reports, the supporting attachment specifications--laboratory results, clinical reports and medications--were created. These latter specifications also represented claim types that were subjected to additional documentation requests in their own right, so the six together were a practical fit. Thus, for example, if a health plan needs additional information about an ambulance service, and needs information about the medications an individual is taking in order to adjudicate the ambulance claim, both the ambulance and medication AIS would be used and sent within the same X12N transaction. Covered Health Care Providers

      We would require covered health care providers to be prepared to receive and send the standards specified in Sec. 162.1915 and Sec. 162.1925 for the specific electronic health care claims attachment transactions, if they choose to receive and send requests and responses electronically for any of the six proposed attachments. No other electronic formats would be permitted for these specific business purposes. For information required for other business purposes, the standards proposed here would not limit the type and format of electronic or paper transaction could be used. Health care providers generally have the option of using paper as their regular mode of communication. Any information requested after the claims adjudication process, such as for post-adjudication medical review or quality assurance review, would not be subject to the standards proposed here. In either case, covered health care providers would continue to have the option of using electronic or manual means of conducting business, including responding to a request for attachment information electronically or on paper. However, if they choose to respond electronically to an attachment request for which a standard has been adopted, that standard would have to be used.

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

      Health care clearinghouses would be required to be prepared to receive and send only the standards specified in Sec. 162.1915 and Sec. 162.1925 for the specific electronic health care claims attachment transactions, or to translate proprietary information from their clients into standard format for re-transmission. Health care clearinghouses must already comply with the requirements set out in Sec. 162.930, adopted by the Transactions Rule. 1. Additional Information Specification (AIS) Uses: Attachment Types That May Be Used for Any Service

      The proposed rule would require that attachment requests, responses, and the AIS be used in the following situations, when the transaction is being conducted electronically:

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

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

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

      1. 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).

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

      3. Emergency Department

         Used when the health plan is requesting, or the health care provider is supplying, information needed to support the adjudication of a claim that includes emergency department services.

         [[Page 56013]]

3. Maximum Data Set

   Each AIS is considered to include the maximum data set for each of the named electronic attachment types. We propose to prohibit health plans from asking for additional data beyond those that are specified in the AIS for that service. Four of the attachment specifications (ambulance services, emergency department, medications, and rehabilitation services) have a finite set of LOINC[supreg] codes that can be used to ask the questions (request the information) for those services. The specifications for Laboratory Results and Clinical Reports do not contain pre-defined lists of codes because clinical developments in those two areas necessitate the ability to use and request information about new tests and reports. Any of the laboratory and clinical reports codes in the LOINC[supreg] database could be used for these requests and responses.

   The proposed AIS documents were drafted several years ago when business practices related to health care claims attachments were likely different than they are today. Therefore, the electronic health care claims attachment data elements, questions, and the cardinality of these elements must be validated for each specification. It is imperative that each AIS be thoroughly reviewed by covered entities to ensure that the proposed data set meets current and projected future business needs. Thus, we ask that during the comment period, health plans and health care providers engage fully in the process of evaluating this maximum data set and the required, situational, and optional elements, and provide us with comments on these issues.

   1. Specific Documents and Sources

      All code sources that are developed outside of the X12 standard setting process, such as ZIP codes, which are maintained by the United States Postal Service, are referred to as external code sets. These code sets are maintained independent of any HIPAA specific requirements, and no rulemaking is required when changes are made to them. The external code sets are listed in section C of the appropriate ASC X12N implementation guide. All of the code sources listed in the ASC X12N Implementation Guides have mechanisms for modifying their codes. The contact posted on the code source list can provide detailed information regarding the process and timing for updating its codes. If the format of a code set that has been adopted as a HIPAA code set (HCPCS, CPT, ICD-9 etc.) is changed, for example, from alpha to alpha numeric, then the change constitutes a ``modification of the code set.'' Use of a modified code set can only be required through further rulemaking to expressly adopt those modified code sets in place of the existing standard.

      The implementation specifications, as expressed in implementation guides for the various ASC X12N transactions and HL7 messages as well as the additional information specifications and the LOINC[supreg] Modifier Codes, may all be obtained at no charge from the Washington Publishing Company site at the following Internet address: http://www.wpc-edi.com/ .

      Users without access to the Internet may purchase the X12N implementation guides from the Washington Publishing Company directly: Washington Publishing Company, PMB 161, 5284 Randolph Road, Rockville, MD, 20852; telephone 301-949-9740; FAX: 301-949-9742.

      HL7 maintains the XML-based Clinical Document Architecture Release 1.0 and the AISs, and information can be obtained at no charge at the HL7 Web site: http://www.HL7.org. Users without access to the Internet

      may obtain HL7 documents directly from the HL7 organization, c/o Health Level Seven, Inc., 3300 Washtenaw Avenue, Suite 227, Ann Arbor, MI 48104, or 734-677-7777.

      The LOINC[supreg] database and the publication LOINC[supreg] Modifier Codes can be obtained at no charge from the Regenstrief Institute site at the following Internet address: http://www.regenstrief.org/loinc/loinc.htm. Users without access to the

      Internet may obtain the LOINC[supreg] database and the LOINC[supreg] modifier codes from the Regenstrief Institute, c/o LOINC[supreg], 1050 West Wishard Blvd., Indianapolis, IN 46202, telephone 317-630-7433.

      The full set of the Data Elements for Emergency Department Systems, Release 1.0 (DEEDS) is published by the National Centers for Injury Prevention and Control, Centers for Disease Control and Prevention. The Internet address is http://www.cdc.gov/ncipc/pub-res/deedspage.htm.

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

      1. Modifications to Standards

         In Sec. 162.910, parameters are outlined for requesting and making modifications to the standards. The statute provides that the Secretary of HHS may not modify any standard, including the electronic attachment standards, more frequently than once a year and must permit at least 180 days for implementation of an adopted modification to a standard by all affected entities before compliance with the modified standard may be required. The Secretary may, however, adopt a modification at any time during the first year after the standard or implementation specification is initially adopted, if the Secretary determines that the modification is necessary to permit compliance with the standard.

         The addition or deletion of codes in a code set for the purpose of enhancing the electronic attachment's communication capabilities is considered maintenance, because such actions do not constitute format or field length changes to the codes or the code set itself. HIPAA expressly permits the routine maintenance, testing, enhancements, and expansion of a code set. We have stated throughout the preamble, that if the codes or code set were changed structurally--for example, changing from a numeric format to an alphanumeric format, this would be considered an actual modification of the code set that would require system changes. Use of such a modified code set could not be required, and would not be permitted, without a regulatory change.

         [[Page 56014]]

         There are mechanisms in place for LOINC[supreg] to add new codes on a regular basis to reflect developments in the industry, just as occurs with ICD-9, CPT-4, and HCPCS, among others. New codes may be used in an electronic health care claims attachment without a change to the rule, if use of a new code is specifically permitted by the AIS, and the use complies with the associated ASC X12N Implementation Guides and HL7 AISs. For example, new LOINC[supreg] codes for new types of laboratory results and clinical reports will be added to LOINC[supreg] based on medical developments. Use of such new codes is permitted by the AIS for laboratory results, clinical reports and medications in both the request and the response transactions.

         Requests for new LOINC[supreg] codes are to be addressed to the Regenstrief Institute for Health Care, c/o LOINC[supreg] Committee, 1050 West Wishard Blvd, Indianapolis, IN 46202, or electronically, in accordance with the instructions in Appendix D of the LOINC[supreg] users guide, to the Regenstrief Web site at http://www.regenstrief.org.

         and will be evaluated through the existing process.

         Once a HIPAA standard is adopted in a final rule, requests for changes to that standard must be submitted through the DSMO process, as set forth in Sec. 162.910(c). After approval, the DSMOs will forward proposed new implementation specifications to the NCVHS and to the Secretary. The NCVHS serves as a consultative body that, under the provisions of the Public Health Service Act, provides advice concerning specified health care matters to the Secretary. Following consultation with appropriate agencies and organizations, including the NCVHS, the Secretary may adopt the modified versions as HIPAA standards through the notice and comment rulemaking process.

         Information pertaining to the designation of DSMOs and their responsibilities can be found in the Transactions Rule and the notice announcing the DSMOs, which were published on August 17, 2000 (65 FR 50365, 50373).

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

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

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

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

   6. 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.]

      1. Overall Impact

         We have examined the impacts of this rule as required by Executive Order 12866 (September 1993, Regulatory Planning and Review), as amended by Executive Order 13258, and the Regulatory Flexibility Act (RFA) (Pub. L. 96-354), section 1102(b) of the Social Security Act, the Unfunded Mandates Reform Act of 1995 (Pub. L. 104-4), and Executive Order 13132.

         The impact analysis in the Transactions Rule assessed the expected costs and benefits associated with the Administrative Simplification regulations (related to employing electronic systems for designated health care related purposes) covering a time span of 10 years. That analysis however did not include electronic health care claims attachments. Nonetheless, this section can be read in conjunction with the Transactions Rule analysis, since the statistics for electronic claims can be considered related to electronic claims attachments.

         Executive Order 12866 directs agencies to assess all costs and benefits of available regulatory alternatives and, if regulation is necessary, to select regulatory approaches that maximize net benefits (including potential economic, environmental, public health and safety effects, distributive impacts, and equity). A regulatory impact analysis (RIA) must be prepared for major rules with economically significant effects ($100 million or more in any 1 year). We consider this proposed rule to be a major rule, as it will have an impact of over $100 million on the economy. This impact analysis shows a potential net savings of between $414 million and $1.1 billion over a 5-year period. We attempt to provide information for the impact analysis, focusing on savings projections, since cost data on the HIPAA transactions are not yet available from the industry. We solicit such data during the comment period for this proposed rule. Also, as referenced earlier, HHS provided funding for a pilot to test the proposed standards, and we anticipate that any cost/benefit information that comes of that study

         [[Page 56015]]

         will be provided before the final rule is published.

         The RFA requires agencies to analyze options for regulatory relief of small businesses. For purposes of the RFA, small entities include small businesses, nonprofit organizations, and small government jurisdictions. Many hospitals and most health care providers and suppliers are small entities, either by nonprofit status or by having revenues of $6 to $29 million or less in any 1 year. For purposes of the RFA, nonprofit organizations are considered small entities; however, individuals and States are not included in the definition of a small entity. For details, see the Small Business Administration's current regulation that set forth size standards for health care industries at (65 FR 69432).

         Effective October 1, 2000, the SBA no longer used the Standard Industrial Classification (SIC) System to categorize businesses and establish size standards, and began using industries defined by the new North American Industry Classifications System (NAICS). The NAICS made several important changes to the Health Care industries listed in the SIC System. It revised terminology, established a separate category (Health Care and Social Assistance) under which many health care providers are located, and increased the number of Health Care industries to 30 NAICS industries from 19 Health Services SIC industries.

         On November 17, 2000, the SBA published a final rule, which was effective on December 18, 2000, in which the SBA adopted new size standards, ranging from $5 million to $25 million, for 19 Health Care industries. It retained the existing $5 million size standard for the remaining 11 Health Care industries. The revisions were made to more appropriately define the size of businesses in these industries that SBA believes should be eligible for Federal small business assistance programs.

         On August 13, 2002, the SBA published a final rule that became effective on October 1, 2002. The final rule amended the existing SBA size standards by incorporating OMB's 2002 modifications to the NAICS into its table of small business size standards.

         On September 6, 2002, the SBA published a subsequent final rule (effective October 1, 2002) that corrected the August 13, 2002 final rule and contained a new table of size standards to clearly identify these organizations by dollar value and by number of employees. Some of the revisions in size standards affected some of the entities that are considered covered entities under this proposed rule. For example, the SBA revisions increased the annual revenues for physician offices to $8.5 million (other practitioners' offices' revenues remained at $6 million) and increased the small business size standard for hospitals to $29 million in annual revenues.

         The regulatory flexibility analysis for this proposed rule is linked to the aggregate flexibility analysis for all of the Administrative Simplification standards that appeared in the Transactions Rule (65 FR 50312), published on August 17, 2000, which predated the SBA changes noted above. In addition, all HIPAA regulations published to date have used the SBA size standards that existed at the time of the publication of the Transactions Rule. For this analysis, we use the current SBA small business size standards. Even though the SBA has raised the small business size standards, the revised size standards have no effect on the cost and benefit analysis for this proposal. The revised standards simply increase the number of health care providers that are classified as small businesses.

         One source of information about the health data information industry is Faulkner & Gray's Health Data Directory (CY 2000 edition). Using this resource, health care clearinghouses, billing companies, and software vendors may also be considered small entities. However, for the same reasons cited elsewhere, we do not have any cost data to determine if this rule would have a significant impact on small entities.

         In addition, section 1102(b) of the Act requires us to prepare a regulatory impact analysis if a rule may have a significant impact on the operations of a substantial number of small rural hospitals. This analysis must conform to the provisions of section 603 of the RFA. For purposes of section 1102(b) of the Act, we define a small rural hospital as a hospital that is located outside of a Core-Based Metropolitan Statistical Area and has fewer than 100 beds. Because these attachment standards are not mandatory for all health care providers, but rather only for those health care providers who conduct a transaction electronically for which the Secretary has adopted a standard, small rural hospitals can continue to operate as they do today, and we do not anticipate a significant financial and business impact on these covered entities. For a more detailed discussion of small rural hospitals, please refer to the Transactions Rule, 65 FR 50312.

         Section 202 of the Unfunded Mandates Reform Act of 1995 (UMRA) (2 U.S.C. 1501 et seq.) also requires that agencies assess anticipated costs and benefits before issuing any rule that may result in expenditures in any one year by State, local, or tribal governments, in the aggregate, or by the private sector, of $110 million. This proposed rule has been reviewed in accordance with the Unfunded Mandates Reform Act of 1995 and Executive Order 12875.

         In the Transaction Rule's impact analysis, State Medicaid agencies estimated that they could spend $10 million each to implement the entire set of HIPAA transactions. Since electronic claims attachments are only one component of the entire transaction set, and we believe that some of the programming completed for the current transactions will be useable for processing electronic health care claims attachments, we do not believe that the States, in aggregate, will exceed the $110 million UMRA expenditure threshold for these new attachment transactions.

         State Medicaid agencies, which are statutory health plans under HIPAA, currently require and use a variety of attachments to adjudicate claims. In order to validate the fiscal and operational impact of this rule, current data on the number and types of claims attachments for each State would be necessary, particularly whether the attachment types we name affect any significant percentage or number of Medicaid claims. We are aware of an industry wide survey that was conducted in the winter of 2005, which may provide some insight into this information for States, if the Medicaid agencies and Medicaid providers participated in the survey. In addition, during the comment period, we hope that State Medicaid agencies will provide such information.

         HHS estimated that the private sector would require expenditures in excess of $110 million to implement all of the transaction standards. Since electronic health care claims attachments are only one of the eight transactions, and since there are only six attachment types at this time, our assumption is that expenditures to meet just the electronic health care claims attachment requirements will not exceed the UMRA threshold for the private sector. Even if our assumption is incorrect, and the costs of implementing the electronic health care claims attachments standards exceed the UMRA threshold, we believe that anticipated benefits of the proposed rule justify the added costs.

         The anticipated benefits and costs of these proposed standards, and other issues raised in section 202 of the UMRA, are addressed later in this

         [[Page 56016]]

         section. In addition, under section 205 of the UMRA (2 U.S.C. 1535), having considered at least three alternatives for the transaction standard (X12 275 version 4010, IEEE, DICOM) and two options for the code sets (claims status and LOINC[supreg]), as outlined in the preamble to this rule and in the following analysis, HHS has concluded that this proposed rule is the most cost-effective alternative for implementing HHS's statutory objective of administrative simplification.

         Executive Order 13132 establishes certain requirements that an agency must meet when it promulgates a proposed rule (and subsequent final rule) that would, if finalized, impose substantial direct requirement costs on State and local governments, preempt State law, or otherwise have Federalism implications. Executive Order 13132 of August 4, 1999, Federalism, published in the Federal Register on August 10, 1999 (64 FR 43255), requires the opportunity for meaningful and timely input by State and local officials in the development of rules that have Federalism implications. The Department consulted with appropriate State and Federal agencies, including tribal authorities and Native American groups, as well as private organizations. These private organizations included WEDI and the DSMO coordinating committee.

         The Department has examined the effects of provisions in the proposed rule as well as the opportunities for input by the States to the proposed rule. The Federalism implications of the proposed rule are consistent with the provisions of the Administrative Simplification subtitle of HIPAA by which the Department was required by the Congress to promulgate standards for the interchange of certain health care information via electronic means, which standards, by statute, preempt contrary State law.

         The States were invited to participate in the electronic claims attachment standard development process from its beginning in 1994. During the early stages, a concept paper that set forth the transactions, code sets, and key issues being considered for the proposed rule was provided to the States for review and comment. Those comments have been considered in preparation of this proposed rule. The National Medicaid EDI HIPAA work group (NMEH) has a claims attachment subcommittee, which will be active in ensuring that each State is given the opportunity to provide input during the public comment period. The Department concludes that the policy in this proposed rule has been assessed in accordance with the principles, criteria, and requirements in Executive Order 13132; that this proposed rule is not inconsistent with that Order; that this proposed rule would not impose significant additional costs and burdens on the States; and that this proposed rule would not affect the ability of the States to discharge traditional State governmental functions. 1. Affected Entities (Covered Entities)

         All health plans, health care clearinghouses, and covered health care providers that transmit any health information in electronic form in connection with a claims attachment which use other electronic format(s), and all health care providers that decide to change from a paper format to an electronic process for claims attachments, would have to begin to use the ASC X12N 277--Health Care Claim Request For Additional Information and ASC X12N 275--Additional Information to Support a Health Care Claim or Encounter and the accompanying HL7 specifications for requesting and submitting electronic health care claims attachments. Currently, there are no standardized electronic claim attachment formats in consistent use across the industry. Since health care providers have the option of continuing to submit paper attachment information, there would be little potential for disruption of claims processes and timely payments during a particular health plan's transition to the ASC X12N 277, ASC X12N 275, HL7 standards and LOINC[supreg] code set use. Implementation will simplify processing for attachments and reduce administrative expenses for covered health care providers. Health plans will be able to automate the processing of attachment information, thus reducing their labor costs and improving the accuracy of attachment responses from covered health care providers. The costs of implementing the X12 and HL7 standards with the LOINC[supreg] code set are generally one-time costs related to conversion. The systems upgrade costs for small covered health care providers, health plans, and health care clearinghouses will vary depending upon the capabilities of hardware and software systems in use at the time these changes are being made. Administrative costs may increase depending on the data entry and data conversion options selected in order to comply with the standard. 2. Effects of Various Options

         After ruling out certain versions of transactions based on limitations identified by early adopters of X12 transactions, we assessed the potential of the later versions of ASC X12N 277--Health Care Claim Request For Additional Information transaction; the ASC X12N 275--Additional Information to Support a Health Care Claim or Encounter transaction; the HL7 CDA message standard; and the six HL7 AIS. These standards were measured against the key principles listed in this proposed rule: achieve the maximum benefit for the least cost; avoid incompatibility; be consistent with the other HIPAA standards; and be technologically independent of computer protocols used in HIPAA transactions. Specifically, the goal of improving the effectiveness and efficiencies of the health care system through electronic means is supported by these standards. We found that these transactions and specifications met all the principles, because once systems and operations are upgraded to send and receive the data in the new format and with predictable content, many other business processes will be improved.

      2. Cost and Benefit Analysis

         [If you choose to comment on issues in this section, please include the caption ``COSTS AND BENEFITS'' at the beginning of your comments.] 1. General Assumptions, Limitations, and Scope

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

         Most health plans, health care clearinghouses, and covered health care

         [[Page 56017]]

         providers were required to comply with the Transaction Rule standards in 2002, or 2003, depending on the entity type and the applicability of the Administrative Simplification Compliance Act (ASCA), which permitted certain covered entities to apply for an extension of the compliance date. Widespread implementation of the HIPAA Transaction Rule was further delayed when covered entities invoked contingency plans under an enforcement discretion strategy guidance document that had been issued by CMS. One of the results of these implementation delays is that industry-wide cost data could not be compiled for HHS to use in assessing the actual financial impact (that is, cost or savings projections) of implementing any of the original transactions.

         The lack of data available today regarding any industry wide HIPAA transaction costs or savings; on the current use of claims attachments; the costs of manual processes; or the impact of conducting any transactions electronically, imposes a significant limitation to any quantitative analysis. Therefore, in order to prepare this proposed rule, HHS used older available studies and anecdotal observations from the industry and SDOs. Since the analysis in the Transaction Rule specifically excluded costs and benefits for electronic health care claims attachments, it further highlighted the data limitations we were faced with for this analysis.

         HHS used the 1993 WEDI report coupled with conservative assumptions from the Transaction Rule to predict costs and savings at a high level. We solicit information from the industry regarding implementation costs for the current HIPAA transactions, in addition to: the frequency of claims attachments; the types of attachments currently being requested (by service and/or procedure); the workload associated with requesting attachment information and providing the response; the costs that may be incurred implementing new software, practice management systems, and other tools; as well as any other relevant cost data that could supplement this analysis. We also hope to receive information from WEDI, following their efforts to engage the industry in discussing Return on Investment (ROI) from HIPAA--an initiative expected to begin in the fall of 2005.

         The impact analysis in the August 2000 Transactions Rule assessed the expected costs and benefits associated with the Administrative Simplification regulations covering a time span of 10 years, beginning in 2002. That analysis did not include electronic attachments to health care claims because no standard was forthcoming at that time. However, electronic attachments are viewed as a minor incremental cost compared to the total cost assessed in the August 2000 Transactions Rule, because covered entities have readied their systems for the other X12 transactions and will have ample experience with X12 by the time the final rule for electronic health care claims attachments is effective. The analysis here can be an adjunct to that which was provided in the Transactions Rule, since the volume of attachments is directly related to the volume of health care claims.

         As we note earlier, data and information about claims attachments was gleaned primarily from the 1993 WEDI report entitled: ``The 1993 WEDI Report and Recommendations.'' Some other general data on claim volumes was gathered from a CY2000 publication from Health Data Management and anecdotally, from informal discussions with industry representatives of health plans and vendors. There were no surveys or proprietary data available from the BlueCross BlueShield Association (BCBSA), the American Medical Association (AMA), the American Hospital Association (AHA), America's Health Insurance Plans (AHIP), The Association for Electronic Health Care Transactions (AFEHCT), X12, HL7 or any other professional organization or SDO.

         The 1993 study by WEDI suggested that 25 percent of all health care claims required support by an attachment or additional documentation. Though these data on attachments are over 10 years old, they are currently the only set of broad-based information available from the industry. We acknowledge that this 1993 statistic does not take into account changes that have occurred following implementation of the HIPAA Transaction and Privacy Rules, nor more recent health plan business rule changes for how claims are adjudicated and what attachments are now being requested. Nonetheless, these are the most comprehensive data available. If current attachment statistics exist, we hope the industry and/or its representatives will provide those data during the comment period.

         We also assume in this impact analysis that electronic health care claims attachments would not be implemented at all, and certainly not with uniform standards, in the absence of this rule. This assumption is based on direct industry comment, and current industry practice to date--very few attachments are being sent electronically today; and vendors, health plans and health care providers say that they will not move forward on this until the HIPAA standards are adopted. The early evidence from the current pilot bears this out, as the hospital providers have said that they will not undertake full scale implementation until the regulation is published.

         The following assumptions are based upon anecdotal comments by industry professionals, as well as the Department's general knowledge of present circumstances in the health care industry. Beyond our anecdotal information, and subsequent assumptions, the only available data we have for hospitals and physicians, indicates that their services represent over 50 percent of the claims submitted annually. Furthermore, their services are likely to be those most affected by the six electronic attachments proposed in this rule. One subject matter expert from a national health plan indicated that 50 percent of all claims attachments are likely to be represented by the six attachment types named here. We request comments and any data that will supplement these and all other assumptions in this section:

         Few health care claims attachments are requested or submitted using an electronic format of any kind.

         Preparation and processing of electronic claims attachments (requests and responses) will entail workload effort that is similar in complexity and duration as that associated with the preparation and processing of an electronic claim, for both health care providers and health plans.

         The volume of unsolicited attachments accompanying original health care claims today is relatively small.

         Health care providers will not all be equally impacted by the electronic claims attachment standards. Some health care provider types (for example, ambulance companies, providers of rehabilitation services, and hospitals or other facilities that operate emergency departments) are more likely to elect to conduct attachment transactions electronically because of the frequency of the requests. Other health care providers may decide to implement the transactions later, opting to continue providing requested information via paper-to- paper fax or paper copies in the short term.

         The cost and benefit analysis is separated into various sub- sections below. In addition, there is a section that discusses the financial impact of implementation covering a 5-year time span, from 2007 to 2011. We use a five

         [[Page 56018]]

         year time span to match the remainder of the 10-year period that was used in the Transaction Rule; that analysis calculated costs and benefits through 2011. 2. Cost and Benefit Analysis for Health Plans

         1. Health plans may incur the following implementation costs:

            Learning about and training staff on the new claims attachment standards, the X12 implementation guides, HL7 AIS booklets, and LOINC codes[supreg].

            Programming systems to accommodate the new transaction types, messaging standards, and codes.

            Installing LOINC[supreg] codes.

            Mapping the LOINC[supreg] codes to the current attachment request reason codes.

            Acquiring translator capability to process HL7 messages.

            Telecommunication expansion.

            Server expansion to retain electronic records.

            Other potential software upgrades for browsing, translating, and validating, as well as internal controlling or messaging/routing functions.

            Health care clearinghouse fees.

            Acquiring XML expertise.

            Changing business practices and retraining staff to accommodate electronic attachments versus paper attachments and records.

            These items should not represent unusual expenditures, as some of the same kinds of tasks will have been accomplished through HIPAA Transaction compliance activities. We also understand that several firms that provide translators already have HL7 capabilities in their HIPAA-capable translators.

         2. Health plan savings could accrue from:

            Using standardized attachment requests.

            Receiving consistent response information.

            Eliminating paper documents and the manual efforts to request, receive, process, and handle the documents.

            Reducing postage costs.

            The ability to electronically adjudicate health care claims supported by an electronically submitted attachment.

            We solicit industry input as to the anticipated implementation costs for technical, business and operational changes that may be required, as well as anticipated savings. 3. Cost and Benefit Analysis for Covered Health Care Providers

         1. Covered health care providers may incur the following implementation costs:

            Learning about and training staff on the new electronic claims attachment standards, the X12 implementation guides, HL7 AIS and LOINC[supreg] codes.

            Programming systems to accommodate the new transaction types, messaging standards, and codes.

            Mapping the LOINC[supreg] codes to current proprietary codes.

            Installing LOINC[supreg] codes.

            Software and/or vendor fees.

            Practice management system vendor fees and charges.

            Health care clearinghouse fees.

            Changing business practices and re-training staff to enter different data, perform different functions, conduct different procedures.

            Purchasing or expanding server space.

            Acquiring XML expertise.

            Purchasing or enhancing translator software.

            Telecommunication expansion.

            Utility conversion programs.

            Again, many of these items should not represent unusual expenditures for covered health care providers and/or their business associates, as some of the same kinds of tasks will have been accomplished through HIPAA transactions compliance activities to date. Small practices that have practice management or software maintenance agreements are likely to be provided with appropriate software upgrades at modest costs, in view of the market competition for that business sector. Covered health care providers with their own EDI software may incur some added costs to obtain HL7 capabilities for their translators. The costs for covered health care providers to implement this proposal for electronic attachments to health care claims are not considered to be significant and many implementation costs for transactions were estimated to be one-time expenditures rather than recurring ones.

         2. Savings could accrue from the following:

            Use of standardized, predictable attachments, and formats rather than numerous proprietary forms associated with individual health plan requirements.

            Reduction of paper documents and manual efforts to receive, process, and respond to requests.

            Reduction in postage and mailing costs.

            Reduction in labor costs.

            Minimization of ambiguities, which frequently result in multiple communication exchanges before the desired information is correctly identified and provided.

            Application of automation by covered health care providers with electronic record systems to support the rapid retrieval of information, and respond to requests.

            More accurate tracking and receipt of attachment information, resulting in fewer lost documents.

            Receipt of payment more quickly.

            We solicit industry input as to the anticipated implementation costs for technical, business and operational changes that may be required, as well as on anticipated savings.

            We do not make any assumptions about the fiscal impact to clearinghouses, because there was no baseline data in the 1993 WEDI report, and no current data on their costs for implementing the HIPAA transactions over the past several years. Nonetheless, we believe that costs would be similar to those incurred by both health plans and health care providers, because of the programming, mapping, translating and storage functions for which they may be responsible. We anticipate that AFEHCT, HIMSS and AHIMA, to name a few associations, will compile data on costs and potential savings for their constituents in order to avoid concerns over proprietary and competitive data. Such deidentified data may be useful for comments on this proposal. A vendor forum held in August 2005 may encourage analysis within the industry itself. 4. Cost and Benefit Estimates

         1. Costs of Implementation: The transaction standards proposed in this rule are in the same family of X12 standards as the other HIPAA- mandated transactions. Therefore, any new activities necessary to implement the electronic health care claims attachment transactions should be consistent with what has already been done, and may be largely in place. The HL7 message standard is used in many clinical settings already, and laboratories and some other health care organizations use the LOINC[supreg] codes.

            While the Department had estimated costs in the impact analysis for the other transactions adopted under the Transaction Rule, we believe that covered entities now have data regarding the actual costs for this implementation, and are themselves in the best position to provide current data regarding the implementation costs of this proposal.

            The 1993 WEDI report did not provide data specific to claims attachments, and no reports since that time have attempted to quantify volumes or costs. The report was extremely limited in data for health plans on this subject.

            [[Page 56019]]

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

            The tables below illustrate the estimated costs for health plans and health care providers to implement electronic health care claims attachments.

            Table 3.--Five Year Costs From Transactions Rule [In billions]

            Costs

            2007

            2008

            2009

            2010 2011

            Providers......................... $1.2............................ $1.2........................... $1.1........................... ....... ....... Health plans...................... 1.2............................. 1.2............................ 1.1............................ ....... ....... 10% of costs...................... 120 million..................... 120 million.................... 110 million.................... ....... .......

            We used Table 4 from the Transactions Rule to demonstrate an estimate of implementation costs for electronic health care claims attachments for both health plans and providers. Using the recent informal industry estimate that implementation of the electronic health care claims attachments standards would cost 10 percent of what covered entities spent on overall HIPAA implementation yields an estimate of $120 million in each of the first 2 years for both sectors. The first 3 years are deemed to have the implementation costs, while future expenses are related to operations, and not reflected in implementation estimates. b. Benefits of Implementation

            In order to estimate the benefits of electronic claims attachments, we applied the methodology described below. According to Gartner, Inc., a management research and consulting firm, 5.1 billion health care claims were submitted in the year 2000. Furthermore, of the 5.1 billion health claims submitted, Gartner believes that 486 million claims were from hospitals and 1.9 billion claims were from physicians. This translates to approximately 10 percent and 38 percent of all health claims being submitted by hospitals and physicians respectively.

            To predict a trend for total annual physician and hospital claims beyond the year 2000 figures provided by the consulting firm, we used the CMS growth rates of Medicare Parts A & B claims from 2001 through 2005 (listed in the CMS Justification of Estimates for Appropriations Committees Fiscal Year 2005 Report (DHHS)) and applied those as the associated growth rates for our physician and hospital health claims model for 2001 through 2005. Furthermore, for the years 2006 through 2011, we assumed the continued 2005 Parts A and B average growth rate of 4 percent for physician and hospital claims. Table 4 below, Total Health Care Claims (in millions), presents a low-high sensitivity range for the number of physician and hospital claims for years 2007 through 2011. Our model uses 2007 as the first year; since this is the anticipated year covered entities will need to be compliant with the regulation.

            As stated earlier, this proposed rule uses a 5-year period for its analysis, in order to synchronize its potential implementation schedule with the date line established in the original Transactions Rule. Since the initial compliance date for the Transactions Rule was 2002, the end date for that analysis was 2011. In this proposed rule, we begin our estimates in 2007, and end in 2011.

            The Table below (Table 4) reflects the estimated number of claims for years 2007 through 2011. As part of a sensitivity analysis, the high numbers reflect a 30 percent increase in the claims count for the same years.

            Table 4.--Total Health Care Claims--Physicians and Hospitals

            2007

            2008

            2009

            2010

            2011

            Low High Low High Low High Low High Low High

            Physician Claims................ 2,832 3,682 2,946 3,829 3,064 3,983 3,186 4,142 3,314 4,308 Hospital Claims................. 708 921 736 957 766 996 797 1,035 828 1,077

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

            [[Page 56020]]

            Table 5.--Total Health Care Claims Attachments--Physicians and Hospitals [In millions]

            2007

            2008

            2009

            2010

            2011

            Low High Low High Low High Low High Low High

            Attachments volume: 50 percent 354 460 368 458 383 498 398 518 414 538 of the estimated 25 percent of all Physician Claims........... Attachments volume: 50 percent

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

            Table 5 shows the number of electronic health care claims attachments that could potentially be required for health care claims (in millions), in spite of the increase in electronic data exchange through the other HIPAA transactions. The data are shown from a low range to a high range to demonstrate that the volumes are large in either case.

            According to the 1993 WEDI Report, operational savings per transaction through the use of electronically submitted claims varies between $1.01 to $1.96 for physicians and $0.64 to $1.07 for hospitals, net of transaction costs (assumed to be up to $0.50 per claim). WEDI believed that conversion from a paper-based process to an electronic transaction process would include savings on labor costs as a result of standardized information and procedures, and a decrease in non- personnel expenses such as postage, telephone, and forms. Other savings may accrue to covered health care providers because they will experience a reduction in the days between claims submission and claims payment. Since there was no other quantitative information from the industry outlining the costs and benefits of the transition to EDI, we constructed our estimates by using the WEDI operational savings figures above in our assumptions and calculations. We note here that the WEDI report did not estimate a per transaction cost for electronic attachments or medical records exchange between a health care provider and a health plan. WEDI provided an estimate of a net savings potential of $1.5 billion in labor from copying and shipment of medical records between health care providers, though not for the purpose of claims attachments.

            For physicians, we assumed the WEDI operational savings of $1.01 within our low category and $1.96 within our high category for each of the 5-year calculations. For hospitals, we assumed the WEDI operational savings of $0.64 within our low category and $1.07 within our high category for each of the 5-year calculations. We do not provide any savings assumptions for health plans, as no relevant data were available through any reports shared with us. We hope that the health plan industry will submit such data to HHS during the comment period. We also note here that operational savings calculations include costs and savings (costs less savings equal operational savings with this methodology). In this proposed rule, we attempt to reflect cost and savings estimates based on available research as well as current informal and anecdotal input from industry subject matter experts.

            Table 6.--Operational Savings From Electronic Health Care Claims Attachments--Physicians and Hospitals [In millions]

            2007

            2008

            2009

            2010

            2011

            Low High Low High Low High Low High Low High

            Physicians...................... 358 902 372 938 387 976 402 1,015 418 1,055 Hospitals....................... 57 123 59 98 61 133 64 138 66 144

            Operational Savings......... 415 1,025 431 1,036 448 1,109 466 1,153 485 1,199

            Table 6, Operational Savings from Electronic Health Care Claims Attachments (in $ millions), shows the total operational savings that could be achieved. The calculations for number of claims attachments are made using the figures in Table 5 and the WEDI savings assumptions for physicians and hospitals.

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

            [[Page 56021]]

            Table 7.--Operational Savings From Electronic Health Care Claims Attachments Based on Specific Rates of Conversion [In millions]

            percent

            percent

            percent

            percent

            percent conversion) conversion) conversion) conversion) conversion)

            Low High Low High Low High Low High Low High

            Total Operational Savings for

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

            Table 7 represents operational savings from electronic health care claims attachments using the estimated conversion factors. We took the operational savings figures shown in Table 6 and applied the conversion rates for each of the 5 years.

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

            Table 8.--Five-Year (2007 Through 2011) Operational Savings ($ Millions)--Discounted (3 Percent and 7 Percent) and Annualized Projections [In millions]

            Total savings

            Total savings Annualized savings Annualized savings (discounted at 3 (discounted at 7 (discounted at 3 (discounted at 7 percent)

            percent)

            percent)

            percent)

            Low

            High Low

            High Low

            High Low

            High

            Total Operational Savings Achieved Using Conversion Factor for

            1,023 2,532

            915 2,264

            205

            506

            183

            453 Paper to Electronic Attachments................................

            As final explanation of our use of the older formal data, and current informal estimates, in preparing this proposed rule we conducted extensive research to obtain up-to-date information. Data regarding paper versus electronic claims were not available beyond the year 2000, perhaps in preparation for HIPAA and the assumption that data would be available post implementation. We used a variety of other resources, including Medicare claims data, external research organizations such as Gartner, and contractors to estimate the number of electronic health care claims attachments, conversion rates, operational savings for each conversion factor, and total operation savings. The newly established Office of the National Coordinator for Health Information Technology (ONCHIT) also did not have current data that have provided any further insight for the impact analysis. Studies pertaining to the adoption of electronic medical record systems (EMR or EHR) and the integration of those with financial and administrative systems may be able to provide some useful information for the final rule in a few years time, but there is none available today related to electronic health care claims attachments.

            OMB requires that all agencies provide estimates using net present values. OMB recommends the use of 3 percent and 7 percent discount rates based on current cost of capital. The discounted totals in Table 8 are based on these rates, and begin in 2007. 5. Conclusions

            As shown in Table 3, Costs Associated with Electronic Health Care Claims Attachments, the estimated costs are $120 million dollars for the first 2 years, and slightly less in the third year. With regard to operational savings, the range is from $414 million to $1.1 billion over five years. In calendar year 2007, maximum operational savings, for both physicians and hospitals, is estimated to range between $414 million to $1 billion.

            When we use the term ``conversion rate,'' we use it to mean the transition from a paper-based system to an EDI based process. As table 7 shows, using the assumed first year conversion rate of 5 percent yields an estimated total operational savings range of $21 million to $51 million. For 2008, the estimated operational savings, for both physicians and hospitals, ranges between $431 million and $1 billion. Using the assumed second year conversion rate of 20 percent could yield an estimated total operational savings range of $86 million to $213 million. For 2009, the estimated operational savings, for both physicians and hospitals, ranges between $448 million and $1.1 billion. Using the assumed third year conversion rate of 50 percent yields an estimated total operational savings range of $224 million to $554 million. In 2010, the estimated operational savings, for both physicians and hospitals, ranges between $466 million and $1.1 billion. Using the assumed fourth year conversion rate of 75 percent yields an estimated operational savings range of $349 million to $865 million. In 2011, the estimated total maximum operational savings, for both physicians and hospitals, ranges between $485 million and $1 billion. Using the assumed fifth year conversion rate of 90 percent yields an estimated total operational savings range of $436 million to $1 billion.

            The 5-year (2007 through 2011) total operational savings presented in Table 8

            [[Page 56022]]

            shows a total operational savings range, for physicians and hospitals, of $1 billion to $2.5 billion, using the 3 percent discounted rate. While using the 7 percent discounted rate translates to a total operational savings range of $915 million to $2.2 billion. In addition, this table shows an annualized operational savings range, for physicians and hospitals, between $205 million and $506 million using the 3 percent discounted rate, and between $183 million and $453 million using the 7 percent discounted rate.

            In accordance with the provisions of Executive Order 12866, this proposed rule has been reviewed by the Office of Management and Budget.

      3. Guiding Principles for Standard Selection

1. Overview

   The implementation teams charged with designating standards under the statute have defined, with significant input from the health care industry, a set of common criteria for evaluating potential standards. These criteria were based on direct specifications in the HIPAA, the purpose of the law, those principles that support the regulatory philosophy set forth in Executive Order 12866 of September 30, 1993, and the PRA of 1995. In order to be designated as a standard, a proposed standard should do the following:

   Improve the efficiency and effectiveness of the health care system by leading to cost reductions for, or improvements in, benefits from electronic HIPAA health care transactions. This principle supports the regulatory goals of cost-effectiveness and avoidance of burden.

   Meet the needs of the health data standards user community, particularly covered health care providers, health plans, and health care clearinghouses. This principle supports the regulatory goal of cost-effectiveness.

   Be consistent and uniform with the other HIPAA standards (that is, their data element definitions and codes and their privacy and security requirements) and, secondarily, with other private and public sector health data standards. This principle supports the regulatory goals of consistency and avoidance of incompatibility, and it establishes a performance objective for the standard.

   Have low additional development and implementation costs relative to the benefits of using the standard. This principle supports the regulatory goals of cost-effectiveness and avoidance of burden.

   Be supported by an ANSI-Accredited Standards Developing Organization or other private or public organization that would ensure continuity and efficient updating of the standard over time. This principle supports the regulatory goal of predictability.

   Have timely development, testing, implementation, and updating procedures to achieve administrative simplification benefits faster. This principle establishes a performance objective for the standard.

   Be technologically independent of the computer platforms and transmission protocols used in HIPAA health transactions, except when they are explicitly part of the standard. This principle establishes a performance objective for the standard and supports the regulatory goal of flexibility.

   Be precise and unambiguous but as simple as possible. This principle supports the regulatory goals of predictability and simplicity.

   Keep data collection and paperwork burdens on users as low as is feasible. This principle supports the regulatory goals of cost- effectiveness and avoidance of duplication and burden.

   Incorporate flexibility to adapt more easily to changes in the health care infrastructure (such as new services, organizations, and provider types) and information technology. This principle supports the regulatory goals of flexibility and encouragement of innovation.

   We believe that the standards being proposed in this regulation meet the requirements of these guidelines. 2. General

   Converting to any standard would result in one-time conversion costs for covered health care providers, health care clearinghouses, and health plans. Some covered health care providers and health plans would incur those costs directly and others may incur them in the form of a fee from health care clearinghouses or, for covered health care providers, other agents such as practice management and software system vendors. We do not include estimated costs to health care clearinghouses in our analysis, since these costs are incurred on behalf of covered health care providers and health plans, and are ultimately borne by them. Including health care clearinghouse costs in this analysis would therefore count those costs twice.

   We also do not include estimated costs for health plans in this analysis, because no relevant data were available. The lack of data overall is discussed in the section called ``limitations.''

   The standards named in this proposed rule compare favorably with typical ASC X12 and HL7 standards and code sets in terms of simplicity, ease of use and cost. Covered entities have a variety of ways in which they can choose to send and/or receive an ASC X12 transaction or HL7 message, including internal reprogramming of their own systems, contracting with vendors and purchasing off-the-shelf translator, or interface engine programs.

   The selection of the LOINC[supreg] code set for conveying meaningful information between trading partners represents another opportunity to control user costs, since this code set is available for use without payment of licensing fees.

   List of Subjects in 45 CFR Part 162

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

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

   PART 162--ADMINISTRATIVE REQUIREMENTS

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

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

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

   Sec. 162.103 Definitions.

   For purposes of this part, the following definitions apply: * * * * *

   LOINC[supreg] stands for Logical Observation Identifiers Names and Codes. * * * * *

3. In Sec. 162.920, the following changes are made:

   1. The section heading is revised.

   2. The introductory text is revised.

   3. New paragraph (a)(10) is added.

   4. New paragraph (a)(11) is added.

   5. New paragraph (c) is added.

   The changes read as follows:

   Sec. 162.920 Availability of implementation specifications and guides.

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

   [[Page 56023]]

   Register approves the implementation specifications and guides described in this section for incorporation by reference in subparts I through S of this part in accordance with 5 U.S.C. 552(a) and 1 CFR part 51. The implementation specifications and guides described in this paragraph are also available for inspection by the public at the Centers for Medicare & Medicaid Services, 7500 Security Boulevard, Baltimore, Maryland 21244 or at the National Archives and Records Administration (NARA). For information on the availability of this material at NARA, call 202-741-6030, or go to: http://www.archives.gov/federal_register/code_of_federal_regulations/ibr_locations.html.

   Copy requests must be accompanied by the name of the standard, number, if applicable, and version number. Implementation specifications and guides are available for the following transactions:

   (a) ASC X12N specifications. * * *

   (10) The ASC X12N 277--Health Care Claim Request for Additional Information, Version 4050 (004050X150), May 2004, Washington Publishing Company as referenced in Sec. 162.1915.

   (11) The ASC X12N 275--Additional Information to Support a Health Care Claim or Encounter, Version 4050 (004050X151), May 2004, Washington Publishing Company as referenced in Sec. 162.1925. * * * * *

   (c) HL7 specifications. (1) The HL7 CDAR1AIS0000R021 Additional Information Specification Implementation Guide, Release 2.1 (based on HL7 CDA Release 1.0), May 2004, Health Level Seven, Inc. The AIS Implementation Guide for the HL7 standard may be obtained from Health Level Seven, Inc., 3300 Washtenaw Avenue, Suite 227, Ann Arbor, MI 48104-4250, or via the Internet at http://www.hl7.org; or from the

   Washington Publishing Company, PMB 161, 5284 Randolph Road, Rockville, MD 20852, or via the Internet at http://www.wpc-edi.com/.

   (2) The HL7 Additional Information Specifications for each of the six attachments listed in Sec. 162.1915 and Sec. 162.1925 may be obtained from Health Level Seven, Inc., 3300 Washtenaw Avenue, Suite 227, Ann Arbor, MI 48104-4250, or via the Internet at http://www.hl7.org ; or from Washington Publishing Company, PMB 161, 5284

   Randolph Road, Rockville, MD 20852, or via the Internet at http://www.wpc-edi.com/. The six HL7 AIS documents are:

   (i) Ambulance services information: The CDAR1AIS0001R021 Additional Information Specification 0001, Ambulance Service Attachment, Release 2.1, based on HL7 CDA Release 1.0, May 2004, as referenced in Sec. 162.1915(b)(1) and Sec. 162.1925(c)(1).

   (ii) Emergency department information: The CDAR1AIS0002R021 Additional Information Specification 0002: Emergency Department Attachment, Release 2.1, based on HL7 CDA Release 1.0, May 2004, as referenced in Sec. 162.1915(b)(2) and Sec. 162.1925(c)(2).

   (iii) Rehabilitation services information: The CDAR1AIS0003R021. Additional Information Specification 0003: Rehabilitation Services Attachment, Release 2.1, based on HL7 CDA Release 1.0, May 2004, as referenced in Sec. 162.1915(b)(3) and Sec. 162.1925(c)(3).

   (iv) Clinical reports information: The CDAR1AIS0004R021 Additional Information Specification 0004: Clinical Reports Attachment, Release 2.1, based on HL7 CDA Release 1.0, May 2004, as referenced in Sec. 162.1915(b)(4) and Sec. 162.1925(c)(4).

   (v) Laboratory results information: The CDAR1AIS0005R021 Additional Information Specification 0005: Laboratory Results Attachment, Release 2.1, based on HL7 CDA Release 1.0, May 2004, as referenced in Sec. 162.1915(b)(5) and Sec. 162.1925(c)(5).

   (vi) Medications information: The CDAR1AIS0006R021 Additional Information Specification 0006: Medications Attachment, Release 2.1, based on HL7 CDA Release 1.0, May 2004, as referenced in Sec. 162.1915(b)(6) and Sec. 162.1925(c)(6).

   (3) The LOINC[supreg] Modifier Codes booklet ``for use with ASC X12N 277 Implementation Guides when requesting Additional Information,'' is available from Washington Publishing Company, PMB 161, 5284 Randolph Road, Rockville, MD 20852, or via the Internet at http://www.wpc-edi.com/.

4. In Sec. 162.1002, paragraph (c) is added to read as follows:

   Sec. 162.1002 Medical data code sets.

   * * * * *

   (c) For the period beginning [24 months after the effective date of the final rule published in the Federal Register]: Logical Observation Identifiers Names and Codes[supreg] (LOINC[supreg]), as maintained and distributed by the Regenstrief Institute and the LOINC[supreg] Committee. The LOINC[supreg] database may be obtained from the Regenstrief Institute Web site at the following Internet address: http://www.regenstrief.org/loinc/loinc.htm. Users without access to the

   Internet may obtain the LOINC[supreg] database from the Regenstrief Institute, c/o LOINC[supreg], 1050 West Wishard Blvd., Indianapolis, IN 46202.

5. A new subpart S is added to part 162 to read as follows: Subpart S--Electronic Health Care Claims Attachments Sec. 162.1900 Definitions. 162.1905 Requirements for covered entities. 162.1910 Electronic health care claims attachment request transaction. 162.1915 Standards and implementation specifications for the electronic health care claims attachment request transaction. 162.1920 Electronic health care claims attachment response transaction. 162.1925 Standards and implementation specifications for the electronic health care claims attachment response transaction. 162.1930 Initial compliance dates for the electronic health care claims attachment response and electronic health care claims attachment request transaction standards.

   Subpart S--Electronic Health Care Claims Attachments

   Sec. 162.1900 Definitions.

   Ambulance services means health care services provided by land, water, or air transport and the procedures and supplies used during the trip by the transport personnel to assess, treat or monitor the individual until arrival at the hospital, emergency department, home or other destination. Ambulance documentation may also include non- clinical information such as the destination justification and ordering practitioner.

   Attachment information means the supplemental health information needed to support a specific health care claim.

   Clinical reports means reports, studies, or notes, including tests, procedures, and other clinical results, used to analyze and/or document an individual's medical condition.

   Emergency department means a health care facility or department of a hospital that provides acute medical and surgical care and services on an ambulatory basis to individuals who require immediate care primarily in critical or life-threatening situations.

   Laboratory results means the clinical information resulting from tests conducted by entities furnishing biological, microbiological, serological, chemical, immunohematological, hematological, biophysical, cytological, pathology, or other examinations of materials from the human body.

   Medications means those drugs and biologics that the individual is already

   [[Page 56024]]

   taking, that are ordered for the individual during the course of treatment, or that are ordered for an individual after treatment has been furnished.

   Rehabilitation services means those therapy services provided for the primary purpose of assisting in an individual's rehabilitation program of evaluation and services. These services are: Cardiac rehabilitation, medical social services, occupational therapy, physical therapy, respiratory therapy, skilled nursing, speech therapy, psychiatric rehabilitation, and alcohol and substance abuse rehabilitation.

   Sec. 162.1905 Requirements for covered entities.

   When using electronic media to conduct a health care claims attachment request transaction or a health care claims attachment response transaction, a covered entity must comply with the applicable standards of this subpart if:

   (a) Information not contained in a health care claim is needed for the adjudication of that health care claim; and

   (b) The health care claim is for one or more of the following types of services:

   (1) Ambulance services;

   (2) Emergency department services;

   (3) Rehabilitation services; or

   (c) The additional information requested is for one or more of the following types of information:

   (1) Clinical reports;

   (2) Laboratory results; or

   (3) Medications.

   Sec. 162.1910 Electronic health care claims attachment request transaction.

   (a) The health care claims attachment request transaction is the transmission, from a health plan to a health care provider, of a request for attachment information to support the adjudication of a specific health care claim. A health plan may make such a request--

   (1) Upon receipt of the health care claim;

   (2) In advance of submission of the health care claim; or

   (3) Through instructions for a specific type of health care claim which permit a health care provider to submit attachment information on an unsolicited basis each time such type of claim is submitted.

   (b) If a health plan conducts a health care claims attachment request transaction using electronic media and the attachment information requested is of a type described at Sec. 162.1905 , the plan must conduct the transaction in accordance with the appropriate provisions of Sec. 162.1915.

   (c) A health plan that conducts a health care claims attachment request transaction using electronic media, must submit complete requests and identify in the transaction, all of the attachment information needed to adjudicate the claim, which can be requested by means of the transaction.

   (d) The health care claims attachment request transaction sent using electronic media, is comprised of two component parts:

   (1) The general request structure that identifies the related claim; and

   (2) The LOINC[supreg] codes and LOINC[supreg] modifiers identifying the attachment information being requested.

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

   The Secretary adopts the following standards and implementation specifications for the electronic health care claims attachment request transaction:

   (a) The ASC X12N 277--Health Care Claim Request for Additional Information, Version 4050, May 2004, Washington Publishing Company, 004050X150 (incorporated by reference in Sec. 162.920).

   (b) The following HL7 AIS documents to convey the LOINC[supreg] codes that identify the attachment type and specific information being requested--

   (1) Ambulance services information: The CDAR1AIS0001R021 Additional Information Specification 0001, Ambulance Service Attachment, Release 2.1, based on HL7 CDA Release 1.0 (incorporated by reference in Sec. 162.920);

   (2) Emergency department information: The CDAR1AIS0002R021 Additional Information Specification 0002: Emergency Department Attachment, Release 2.1, based on HL7 CDA Release 1.0 (incorporated by reference in Sec. 162.920);

   (3) Rehabilitation services information: The CDAR1AIS0003R021. Additional Information Specification 0003: Rehabilitation Services Attachment, Release 2.1, based on HL7 CDA Release 1.0 (incorporated by reference in Sec. 162.920);

   (4) Clinical reports information: The CDAR1AIS0004R021 Additional Information Specification 0004: Clinical Reports Attachment, Release 2.1, based on HL7 CDA Release 1.0 (incorporated by reference in Sec. 162.920);

   (5) Laboratory results information: The CDAR1AIS0005R021 Additional Information Specification 0005: Laboratory Results Attachment, Release 2.1, based on HL7 CDA Release 1.0 (incorporated by reference in Sec. 162.920).

   (6) Medications information: The CDAR1AIS0006R021 Additional Information Specification 0006: Medications Attachment, Release 2.1, based on HL7 CDA Release 1.0 (incorporated by reference in Sec. 162.920).

   Sec. 162.1920 Electronic health care claims attachment response transaction.

   (a) The health care claims attachment response transaction is the transmission of attachment information, from a health care provider to a health plan, in response to a request from the health plan for the information.

   (b) If a health care provider conducts a health care claims attachment transaction using electronic media, and the attachment information is of the type described at Sec. 162.1905, the health care provider must conduct the transaction in accordance with the appropriate provisions of Sec. 162.1925.

   (c) A health care provider that conducts a health care claims attachment response transaction using electronic media must submit a complete response by providing, to the extent available, all of the requested attachment information or other appropriate response in the transaction.

   (d) A health care provider that sends scanned images and text documents in the attachment transaction, for the human decision variants, is not required to use the LOINC[supreg] codes as the response, other than to repeat the LOINC[supreg] codes used in the request. Response information may be free text, scanned documents, or an embedded document within the BIN segment of the response transaction.

   (e) A health care provider may submit an unsolicited response transaction only upon advance instructions by a health plan.

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

   The Secretary adopts the following standards and implementation specifications for the electronic health care claims attachment response trans action:

   (a) The ASC X12N 275--Additional Information to Support a Health Care Claim or Encounter, Version 4050, May 2004, Washington Publishing Company, 004050X151 (incorporated by reference in Sec. 162.920).

   (b) The HL7 Additional Information Specification Implementation Guide Release 2.1 (incorporated by reference in Sec. 162.920) for implementing the HL7 Additional Information Specifications to convey attachment information within the Binary Data segment of the ASC X12N 275 (004050x151).

   (c) The following HL7 AIS documents to convey the LOINC[supreg] codes that identify the attachment type and

   [[Page 56025]]

   specific attachment information being sent--

   (1) Ambulance Services information: The CDAR1AIS0001R021 Additional Information Specification 0001: Ambulance Service Attachment, Release 2.1, based on HL7 CDA Release 1.0 (incorporated by reference in Sec. 162.920);

   (2) Emergency Department information: The CDAR1AIS0002R021 Additional Information Specification 0002: Emergency Department Attachment, Release 2.1, based on HL7 CDA Release 1.0 (incorporated by reference in Sec. 162.920);

   (3) Rehabilitation services information: The CDAR1AIS0003R021 Additional Information Specification 0003: Rehabilitation Services Attachment, Release 2.1, based on HL7 CDA Release 1.0 (incorporated by reference in Sec. 162.920);

   (4) Clinical reports information: The CDAR1AIS0004R021 Additional Information Specification 0004: Clinical Reports Attachment, Release 2.1, based on HL7 CDA Release 1.0 (incorporated by reference in Sec. 162.920);

   (5) Laboratory results information: The CDAR1AIS0005R021 Additional Information Specification 0005: Laboratory Results Attachment, Release 2.1, based on HL7 CDA Release 1.0 (incorporated by reference in Sec. 162.920); and

   (6) Medications information: The CDAR1AIS0006R021 Additional Information Specification 0006: Medications Attachment, Release 2.1, based on HL7 CDA Release 1.0 (incorporated by reference in Sec. 162.920).

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

   (a) Health care providers. A covered health care provider must comply with the applicable requirements of this subpart S no later than

   [24 months after the effective date of the final rule published in the Federal Register] .

   (b) Health plans. A health plan must comply with the applicable requirements of this subpart S no later than one of the following dates:

   (1) Health plans other than small health plans--[24 months after the effective date of the final rule published in the Federal Register].

   (2) Small health plans--[36 months after the effective date of the final rule published in the Federal Register].

   (c) Health care clearinghouses. A health care clearinghouse must comply with the applicable requirements of this subpart S no later than

   [24 months after the effective date of the final rule published in the Federal Register] .

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

   Dated: May 27, 2005. Michael O. Leavitt, Secretary.

   [FR Doc. 05-18927 Filed 9-22-05; 8:45 am]

   BILLING CODE 4120-01-P