Statement of
Krista Robinson
Electronic Data Systems (EDS)

Introduction

Good morning. I am Krista Robinson representing Electronic Data Systems (EDS). I would like to thank the Subcommittee for the opportunity to testify on health care claims attachments.

EDS is a professional services firm that provides consulting, information, and technical expertise to over 9,000 clients worldwide. We shape how information is created, distributed, shared, enjoyed, and applied for the benefit of enterprises and individuals alike. In the health care industry, EDS serves over 250 clients including 71 insurance carriers, 18 state Medicaid programs, Medicare Part B carriers for the entire country, clearinghouses, as well as many HMOs, Federal health care programs, employers and pharmaceutical organizations. EDS processes over 2.4 billion transactions per year and processes claims for one every in four Americans (123 million lives), eighty percent of which are electronic. The EDS health care industry serves and participates in several professional industry organizations such as: X12, AHFECT, WEDI, NCPDP, and HL7. In addition, EDS has formed a HIPAA virtual team to assess the impacts of the legislation not only in our own corporation, but for our customers as well.

Though I am here today to represent EDS as a corporation and the HIPAA virtual team, my background revolves around Medicare Part B claims processing. Because I would like to assist the Subcommittee to the fullest extent, I have with me Barry Blanchard, who co-chaired the development of the X12 837 health care claim transaction, to help answer any additional questions that the Subcommittee may have on this important topic.

Electronic claims attachments is a complex, dynamic matter, and there are several issues that should be addressed, as we have indicated in the testimony to follow. Based upon our knowledge and experience in health care, we are planning to address the following items concerning health care claims attachments: the definition of a claim versus an attachment, appropriate information for a claim, appropriate information for claims attachments, the positive and negative impacts on existing systems with the inclusion of X12 and HL7 in one standard, the integration of information that systems currently have with health care data, and the problems of implementing standards for health care claims attachments.

Claims versus Attachments

1. In order to differentiate information that is appropriate in a claim versus information that is appropriate for claims attachments, it is important to understand the differences between the two transactions. In the industry, there is much debate over what constitutes a claim versus what constitutes an attachment. Many feel that the electronic claim currently contains information that is considered an attachment. Others believe that the electronic claim should contain more information in order to adjudicate a claim, without having to request additional information.
2. In its’ simplest definition, a claim is a request for reimbursement of a health care product or service provided to an individual by a provider. It contains administrative information, along with pertinent medical record information that is needed to validate the claim. A claim can be submitted through a paper form or by an electronic format. In today’s environment, a claim attachment contains supplemental information required by a payer to adjudicate a claim. Most often this information is additional patient information concerning their medical record, documented on primarily non-electronic media.
3. In the future, the information that should be included in a claim is data that can be codified and does not require human intervention for interpretation. The attachment should include supplemental information related to the processing of a patient’s claim, that is not necessary for most types of claims, but may be requested by payers for further clarification of a submitted claim.

Attachment Standards

As mentioned yesterday by Steve Barr, there is a Proof of Concept team that HCFA is guiding to define a transaction format and content for providers to return requested Medicare Medical Record information to payers. The request for the information would come in an X12 transaction, the 277 - Request for Additional Information - from the payer to the provider. The proof of concept would require the response to come from another X12 transaction, the 275 - Additional Patient Information, and possibly an HL7 message embedded within a segment in the X12 transaction.

Though combining the two Standards Development Organizations (SDO) is an excellent idea for a concerted effort, significant impacts to existing systems are involved. Because this is new to the EDI software industry, an initial negative impact is the ability to recognize and interpret different syntax in the same data stream. Currently most systems do not use X12 or HL7 for electronically processing claims or claims attachments. Of those that do, HL7 is typically used for processing clinical information between medical delivery systems, or X12 is used for processing medical billing and encounter systems, which are financial in nature. Most systems are designed for one or the other.

The proposal from the Proof of Concept team is to have a binary segment in the ANSI 275 transaction that will be able to handle any type of information, whether it is ASCII text, a word processing document, an x-ray, an ultrasound, or an HL7 message. A qualifying segment would be required prior to this binary segment in order to let the system know what type of data is inside the binary segment. Both the qualifying segment and the binary segment would loop, so that there would be a one-to-one match between the two. In other words, you could not have both a word processing document and an HL7 message following one qualifier. The transaction would have a qualifier for the word processing document, then the document, followed by another qualifier and the HL7 message.

In today’s environment, payers, health plans and claims processing systems do not have common integration of information across departments. It is more common in the institutional provider community to have a system integrated with HL7, than it is on the professional or dental provider community. Typically, these providers do not have an electronic mechanism in place to process clinical information. The latter has typically focused their efforts in the development of claims payment systems and put little automation in the business processes surrounding the development of the claims, the review of the claims or the resolution of the claims.

The EDI industry is currently working on the technical feasibility of reading, processing and interpreting different types of formats. Translators can process both HL7 and X12, but the payer’s current systems may not be able to interpret the data. In addition, the various entities involved with these transactions will need to evaluate other business issues such as cost of implementing such systems, and related business processes and work flows.

In addition to technical impacts, there are data dictionary issues that would need to be resolved. Each standard, X12 and HL7, uses different data dictionaries which would need to be referenced in the same data stream. The Proof of Concept team has done an excellent job codifying the information used in attachments for the limited number of attachments that they are using for this project. This team has identified attachments, giving them a reference number, as well as the data elements within each attachment, assigning codes for each data element. They are currently trying to cross-reference these codes with LOINC codes (Logical Observation Identifiers, Names and Codes) along with HL7 to come up with a universe of codes for each element in their test attachments.

The issue then becomes who is responsible for this code list; where can providers needing to send an attachment, payers needing to receive an attachment, and systems needing to integrate codes into the system to alleviate human intervention, find this list; and who can update it? We believe that if X12 and HL7 are combined, then there should only be one code set, with a cross-walk of the code lists in a single source of information. The industry should decide how this is done, and who should maintain this list. This would provide the least impact for users to identify the necessary information.

If the technical and business process data stream issues can be resolved, then electronically submitting attachments becomes a positive impact. Until these issues are resolved, we believe that one of two situations will occur:

1) providers will continue to submit paper attachments

OR

2) providers will “catch on” to what payers request for additional information in order to process a claim, and will submit as much information as possible with the claim every time in order to adjudicate their claims as quickly as possible. This will make it more difficult for the payer and/or system to process the original claim.

Implementation of Standards for Attachments

In addition to the impacts noted above, we believe that the following challenges could occur:

• different type of workstations may be required, coupled with data storage that will be needed in order to retrieve information
• cost benefit analysis will be required by all entities involved, related to business flows, processes and system upgrades
• there will be individual privacy and confidentiality issues of electronically transmitting additional patient information
• changes will be required in Federal and State laws and mandates

Conclusion

This is a complex challenge. It will take flexibility and compromises to implement such a task by all entities involved. The standards for attachments should be an industry led consensus with government participation. The EDI industry is still in the process of developing software capable of interpreting multiple types of formats. We would encourage the Proof of Concept team to include a viability and feasibility study, along with a cost savings and benefit analysis on their work with the X12 standards and HL7 messages. Until this is done, it may be premature to make any decisions on how and when electronic attachments are implemented. If standards are developed that limit the use of attachments, it could infringe on a payer’s ability to continue with their current business decisions. It may also require payers to upgrade their current EDI software. In conclusion, the industry along with the government, should define a standard, allow a framework to be established that will allow payers and providers to move forward with the electronic attachment, and allow an economic model to define when to move forward with the implementation.

Thank you for the opportunity to provide the Subcommittee with this testimony. I will open this up for any questions that you may have at this time.