Standards for Electronic Healthcare
Claims Attachments

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

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

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

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

CMS’s work in the mid-1990s with WEDI, ASC X12, and HL7 resulted in the recommendation to use an HL7 version 2.4 message embedded within version 3040 of the ASC X12N 275 ‘‘Additional Information to Support a Health Care Claim or Encounter Transaction,’’ in other words, a response to a request for information. The embedded HL7 message would have contained structured and codified attachment data using the LOINC coding system. For a variety of reasons, a proposed rule was never released with this recommendation. Since that time, HL7 moved ahead with development of its Clinical Document Architecture (CDA), which was a significant enhancement over the HL7 version 2.4 messaging. The CDA Release 1.0, August 2003, is an XML-based document specification that enables the standardization of ‘‘clinical documents’’ for electronic exchanges of health information (see explanation of XML below). The CDA became the first ANSIaccredited XML-based standard in the health care industry.

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

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

1. Overview of Extensible Markup Language (XML)

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

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

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

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

2. Overview of Clinical Document Architecture

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

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

3. How XML Is Applied Within the Clinical Document Architecture

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

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

4. Transactions for Transmitting Electronic Attachments

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

5. Electronic Claims Attachment Types

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

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

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

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

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

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

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

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

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

6. Format Options (Human vs. Computer Variants) for Electronic Claims Attachments

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

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

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

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

Even with this variant, HL7 will supply ‘‘stylesheets’’ that will put any data into an HTML or screen readable format. This means that health plans that do not intend to auto-adjudicate in the short term, may continue to use lowcost technology to print or display the electronic attachment information, regardless of which option or variant the health care provider uses. The human and computer variants do not differ in actual content. Both types of variants (human and computer) for each electronic attachment type have required and optional content elements, which are listed in the specification for that attachment. Both types of variants will satisfy the standard, as they will differ only with regard to whether or not structured and coded data are required. That is, in the computer variant, coded data are required, whereas in the human variants, coded data are not required. While both variant types will carry a LOINC code or codes, they will be accompanied by the natural text translation (narrative text) in the same transaction, so the request will be understandable in either the human or the computer variant.

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

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

As discussed in the previous section, claims attachment transactions contain both administrative and clinical information. Thus, attachment data could come from a health care provider’s clinical record system, whether paper or electronic, as well as from its practice management or billing system. Historically, these two distinct areas (clinical vs. administrative) have been the domain of two different SDOs: HL7 focuses on clinical data standards, while X12 concentrates on administrative data and transactions. In 1997, a joint effort between HL7 and X12 produced several options that would facilitate the communication of both clinical and administrative data, as well as smooth the transition from paper to a standardized electronic process for health care claims attachment information. ASC X12N, through its Patient Information Standards Work Group (WG9), developed transactions and the accompanying X12 implementation guides to fulfill the administrative needs of an electronic attachment request and the response to that request. HL7, through its ASIG, developed the message structure and the additional information specifications employing LOINC codes that were relevant to the major types of clinical data needed in claims attachments. The ASIG included HL7 representatives, members of X12's WG9, and several vendors and health care providers with HL7 experience. The purpose of proposing the combined use of both ASC X12N and HL7 standards is to address both the administrative and clinical aspects of the attachment transactions from a format and content perspective. However, because these two standards have not been used together before, we solicit industry feedback regarding this strategy.

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

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

[Top of Page] [Previous] [Next: Business Use]