My name is Ed Hammond. Thank you for the opportunity to appear before this subcommittee as a representative of an ANSI approved Standards Developer Organization, Health Level Seven (HL7). I am the immediate past chair of HL7, having completed my second tour as Chair of HL7; I am a co-chair of the Special Interest Group on Vocabulary; and I am chair of the Government Relations Committee.
Health Level Seven is in its eleventh year of developing data interchange standards. The current version, Version 2.3, was approved as an American National Standard by the American National Standards Institute (ANSI) in 1997. The current membership of HL7 includes approximately 500 organizational members, balanced between vendor and provider organizations, and includes additionally consultants, payers, government organizations, and general interest categories. HL7 has over 1800 members. HL7 now has six International Affiliates and anticipates authorizing three more International Affiliates in 1998.
Approximately 90% of the venders in the clinical information systems market offer the HL7 interface. Most, if not all, of the gateway engines or data interface engines in the healthcare area support the HL7 standard. In 1996, Hewlett Packard Corporation conducted a survey at HIMSS relating to standards and specifically, which standards are most important to your organization. Sixty-five percent of the respondents indicated HL7 as that choice. The next closest standards developer organization was 21% (DICOM).
The activities within HL7 have grown immensely during the past two years. HL7 is now addressing issues that must be resolved to have true interoperability in the exchange of clinical, administrative and financial data within an institution, within an enterprise, within a geographical integrated delivery system, or within a national system.
New areas of activity include:
The Special Interest Group (SIG) on Standardized General Markup Language (SGML) (which includes Extensible Markup Language (XML) and Hypertext Markup Language (HTML)) – markup languages that permit definition of the document form and content and is important for the exchange of data, particularly on the Internet.
1. The SIG on Security, Privacy, and Confidentiality that addresses transmission of data on the Internet, Intranet, Extranet and other communication media. Activities include encoding of messages during transmission; encoding of message content; digital signatures; and authentication.
The SIG on Vocabulary is working to define vocabulary in terms of content and use in HL7 messages and takes advantage of existing controlled vocabulary sets including LOINC, SNOMED, ICD 9 and 10, Reed Classification Codes, CMT and others. This vocabulary will be mapped into UMLS and will be defined specifically for use in HL7 messages. A subset of this group will meet in early March to develop a proposed model for naming prescription drugs and related data. Four drug knowledge based groups have contributed their drug models and, at this meeting, these models will be harmonized along with input from NCPDP and models from the European Union’s CEN TC251.
The SIG for Claims Attachment has already been presented. This SIG represents the effective coalition of two SDOs working together to create standard for claims attachments. Leadership in this committee is shared between HL7 and X12N members. In my opinion, this combined effort will produce a standard that will be a much better product than if either group had produced the standard independently.
Other activities include the SIG for Decision Support that now includes the Arden Syntax Medical Logic Modules Standard; SIG for Conformance; SIG for Certification; and at the last meeting, a SIG for accountability, performance and quality.
2. HL7 has created a Reference Information Model that defines the healthcare data objects that will be used in HL7 messages.
HL7 has active projects with NCPDP, ASTM, X12N, IEEE and ACR/NEMA DICOM. IEEE now meets with HL7.
Duke Medical Center has almost 100 different HL7 interfaces for the exchange of clinical and administrative data. These interchanges take place within the hospital, between the hospital and hospital service departments and outpatient clinics, and among a network of Duke University Affiliated Physicians (small groups of community providers). The types of data exchanged include structured data (i.e., coded elements with values), text strings, text blobs such as image interpretations, progress notes, discharge summaries and operative notes. The standard supports the interchange of demographic data, laboratory orders and results, pharmacy orders and dispensing, allergies, procedures, diagnoses, and encounter data.
An envelope container for images using the DICOM standard is being defined for HL7 messages. HL7 supports the transmission of automated waveforms such as EKGs or EEGs. I have used HL7 to exchange all components with the electronic medical record (EMR) and, in fact, the entire electronic medical record. These elements are what make up the bulk of the claims attachment.
The task of this subcommittee is not an easy one, and that difficulty must be acknowledged and faced. Taking the easy way out and providing quick solutions would deny the opportunity for doing something truly significant in administrative simplification and cost constrains for both payers and providers. From yesterdays testimonies and discussion, it is clear that many different perceptions of what is needed and why do we do what we now do exists not only between payers and providers but within each group. We are burdened with legacy requests of additional data without understanding why that data is requested. Providers send everything in hopes that the answers are contained within; payers are overwhelmed and do not look at all submitted data. We seem to be defining solutions to problems that have not been clearly defined. We use the process of claims attachment to control other hidden but maybe important events. If money flow is a problem, then it should be acknowledged and dealt with. Detecting fraud should be independent from the process of determining appropriateness of health care and reimbursement justification. We must not use ambiguity in defining claims attachment as a method of control. Payers are afraid that if they clearly define what is required to justify reimbursement, providers will take advantage; providers think they are abused in what is required to document the claim.
We need to understand where we want to be in 5-10 years and make recommendations that will get us there. Paper forms are static; electronic data exchange is dynamic and can be tailored to what data is required for which actions. Static HTML has quickly given way to Dynamic HTML. One form does not fit all. The same is true for claims. We need to define a claims attachment process that does accommodate a vision for the future. Any short term process will dictate what is do be for at least the next 10 years. We must define clearly and unambiguously what we want and include the justification and reasoning. That process will require change, but that process will provide additional incentive to move toward the electronic medical record for all providers, large or small.
The comment was made the HL7 is not being used by small providers. The truth is that little computerization exists in most small provider group settings. The HL7 standard does define what is necessary to support these groups. Commercial systems for use in those settings support HL7. Technology is quickly providing affordable and manageable systems. Much data, including transcriptions and laboratory data, is already economically available to all providers. Increasing the benefits by reducing the cost of claims processing will speed up the use of computers and the adoption of the EMR in these settings.
We now support multiple databases financial, clinical care, and research as well as databases for different groups public health, health care facilities, CDC, JCAHO, NCQA, state systems, and others. We cannot afford the efforts of data capture and recording and for insuring the integrity of that data multiple times. I echo yesterdays remark Do it right, do it completely, and do it once.
Finally, I offer one comment on security, privacy and confidentiality. We need to recognize that in many instances, the humans do not need to know the identity of the patient whose claim they are processing. Only the computer needs to know how to link the claim to a specific individual, a specific payer, and a specific benefit plan.
HL7 is delighted to be part of the Proof of Concept project. I believe that the framework of what is proposed is workable and provides adequate flexibility to accommodate the development and maintenance of the detailed definitions of claim attachments. Elimination of the manual efforts required on both sides of the reimbursement process can be minimized by this approach. Furthermore, the approach is visionary and will accommodate future requirements.
That NCVHS issue a clearly stated directive that this proposal is how claims attachment will be done (combined HL7 and X12N standards). This directive should be issued as soon as possible in enable vendors to begin to move toward a solution. It is likely that interface software will be developed to mate legacy clinical information systems with reimbursement software.
That NCVHS identify a framework and body which will have the responsibility for defining what is required to validate the claim and what is required for justification for reimbursement. This process requires the identification of the experts and getting them involved and committed. All groups must be willing to change and to compromise.
Educate all groups to understand that this process is evolutionary.
1. What is your definition of a claim versus a claim attachment?
A claim is part of a financial transaction in which the claimant is stating the amount to be paid for a particular service. The Claim attachment is supporting clinical information that may be necessary to justify the services that are the subject of the claim. Our concepts of what is a claim and what is a claim attachment are highly biased by the present, mainly paper system. A dynamic, electronic submission of claims could eliminate a separate document known as a claims attachment. Ideally the action of this committee would reduce the number of times additional data is requested after the submission of the claim.
How should we differentiate information that is appropriate for the claim versus information that is appropriate for claims attachments?
The claim information should be limited to the business transaction and should include only that information for which the primary EDI transaction has provided explicit data representations. The Claim attachment should be limited to clinical information about the patient to whom the service was rendered, including the dates of service and orders that produced the clinical data.
What aspects of these processes would be aided by standardization and electronic exchange of information?
We could provide consistent data to all payers; significantly reduce the effort needed to assemble otherwise idiosyncratic requests and be able to take further advantage of automation in which we have already invested for clinical use.
What is the relationship between claims attachments and the medical record?
The claims attachment should be a specific extract (logically speaking) from the medical record. The extract should be designed to respond to a particular question or documentation requirement. It should not be designed nor intended as a place where the payer can extrapolate conjectures about perceived practice patterns. The data necessary to do practice pattern research needs to be both broader and better integrated than one can get from monitoring claims attachment data that are intended to document or support a particular procedure or service provided to a particular patient in the context of a particular clinical episode or pathology.
Would standardization and simplification of the questions asked by the payer make the claim adjudication process easier?
It would allow consistent responses to all our payers, and would allow us to provide data whose integrity and context we both understand and trust. Passing the data through the interpretive services of even a very good business office affects both the integrity of the data and our trust that it reliably represents the clinical findings.
Do you have any suggestions that would assist us in the task of standardizing the requests for additional information from payers?
The old 90-10 rule. Lets find that ten per-cent of the attachments that, in truth, respond to 90% of the needs. Also, expect that providers ability to submit electronically will evolve over time. Do not penalize those providers who can file clinical attachments electronically simply because some (perhaps large) fraction of the provider community cannot. They will, over time, catch up to the benefit of all.
Would the automation of health care claim attachment information and standardization of the payers' requests for information reduce operating costs for your facility?
Yes. It would allow us to reduce the clerical effort needed to respond to these requests and would permit more timely submission of reliable claims.
26. Can you clearly differentiate clinical information, "claims information, and attachment information?
These terms relate primarily to the use of the data. Claims information is what is extracted from the clinical record (which contains financial, demographic, process data as well as clinical data) for the purpose of reimbursement. Attachment information is submission of clinical data and reasoning of provider which supports the claim.
27. Are there health care claim attachments that do not contain clinical information?
Yes. However, I argue that all such information, if it exists, should be part of the patients EMR.
28. Currently, the NUCC and the NUBC have the responsibility for approving the content of information contained in the standard health care claim. Do you think such an organization should also have responsibility for approving the content of claims attachments? Can you suggest which organization(s) should have this responsibility?
I think these are likely candidates to participate in the process. I personally support the creation of a National Uniform Data Commission to have such responsibility.
29. If there was a governing body over data content of the standard attachment data, there would have to be a protocol in place to add, delete, modify, etc. existing data content of the attachment. What are your suggestions/concerns regarding this process?
The terminology here should be information content, not data content. If the standards makers are not allowed to specify the data content needed to fulfill the information content requirements, there will be no standardization.
30. What impact will the incorporation of HL7 messaging in the standardization of attachments have?
The vast majority of our clinical information is already handled in HL7. Thus it would vastly simplify the process of providing this information and would obviate the need to do translations into another form. Such translations inevitably result in errors and loss of semantic consistency.
33. What positive/negative impacts on existing systems would the inclusion of X12 and HL7 messaging in one standard have?
Most health care systems vendors already support both.
34. How common are systems that integrate information across departments so that electronic requests for clinical information can be fulfilled electronically, regardless of the data source?
Only a few such systems exist today and these systems are found in the larger academic medical centers. However, the spread of such systems into the wider community is happening rapidly. Almost 50% of the hospitals in the US are using HL7, for example.
35. What problems do you foresee in implementation of standards for health care claims attachments?
Reaching agreement on a reasonable set of attachments to automate, and not just throwing in everything that any payer may, on a whim, desire.