Standards for Electronic Healthcare
Claims Attachments

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

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

1. Transactions

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

a. Health Care Claims Attachment Request Transaction

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

b. Health Care Claims Attachment Response Transaction

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

2. Code Sets

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

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

Washington Publishing Company is the exclusive publisher and copyright holder of the X12N health care claim status reason codes. The Regenstrief Institute, Inc. and the LOINC Committee are the copyright holders of the LOINC code set and database.

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

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

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

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

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

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

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

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

Thus, the BIN segment of the ASC X12N 275 (response) transaction would be able to hold all of the attachment information requested by the health plan. In 1997, the NUBC, the NUCC, and the NCVHS were consulted on the data format to be used in the BIN segment. Originally, the NUCC recommended that a choice between unstructured ASCII text alone and structured HL7 be given. However, much discussion occurred during the NCVHS meeting itself, and after considering the comments received, and discussion with health insurance EDI professionals, the NCVHS and WG9 determined that the best options for content structure were the following:

1. HL7 structure—this option would require the structure and content of the Additional Information Specification (AIS) to be based entirely on HL7 defined information for each message. HL7 would define the data content and structure for each AIS based on existing HL7 conventions;
2. HL7 plus ASCII text structured—this option would allow, in addition to the HL7 structure, additional specifically formatted text information (defined lengths, etc.). This would limit the amount and type of additional information that could be submitted; or
3. HL7 plus ASCII text unstructured—this option would allow, in addition to the HL7 information, any additional text information.

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

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

[Top of Page] [Previous] [Next: Proposed Standards]