Whether it's verifying a patient's coverage, submitting insurance forms, or sending information to the HMO in which you participate, delivering effective healthcare today involves sending, receiving, or exchanging information with other computers, offices, and state and federal agencies. To address the resulting drawbacks and headaches, many of them the result of a plethora of computer systems and applications that use different languages and have different requirements, the health care industry has created various standards to simplify the exchange of information among computer systems and information trading partners. The end result should be to give health care providers the information they need without burdening them with the problems inherent to information processing.
H ealth Level Seven (HL7) is both the name of the standards developing organization I represent and the collection of protocols we have developed and published. The group was founded in March 1987 as a committee comprised of healthcare providers, software vendors and consultants. Its goal is to simplify the implementation of interfaces between health care computer applications for different, often competing, vendors, thereby eliminating -- or at least greatly reducing -- the need for custom interface programming and program maintenance.
Most providers participate in delivery systems that use a group of installed computer applications for both inpatient and outpatient services such as hospital admissions, discharges, and transfers; billing and accounts receivable; laboratory; radiology, and home health care. HL7 protocols allow various systems to exchange these key sets of clinical data. The means by which this is accomplished is reflected in the organization's name.Encoding Rules and Scope
"Level Seven" refers to the application level, the highest level of the Open System Interconnection (OSI) model of the International Organization for Standardization (ISO). The OSI model is a networking architecture for moving data from one software application to another application located on another computer. This model divides the process of moving that data into seven steps or layers. From lowest to highest, the layers are: physical, link, network, transport, session, presentation, and application. The lowest two layers, physical and link, are handled by hardware. The upper five layers are handled by software. The issues that are addressed or that occur at the seventh level include the data to be exchanged, the timing of the exchanges, and the communication of certain application-specific errors between applications. HL7 is a framework÷an accepted set of protocols÷that defines these three elements.
HL7 addresses the first issue, the data to be exchanged, by compiling the data into messages, the format of which is defined by HL7's encoding rules. An HL7 message can be either the response to a query or an unsolicited update. A query might be as simple as one system requesting the lab system to send all lab results for patient #12567. Unsolicited updates typically contain data about the completion of an action concerning a given patient and are sent without one system querying the other. You can query or re-query for anything that has been sent. Both queries and unsolicited update messages may be either display or record-oriented.
A display message is used when information (typically update data) does not need to be captured by the receiving system but merely displayed or printed, and is thus formatted for display purposes. A record-oriented message is one with a format that explicitly denotes field content and thus can be captured by the receiving system. Both are ASCII clear-text messages that can be read.
An HL7 record-oriented message is typically comprised of numerous data fields (such as patient name, address, or age) that have a specific definition, are assigned a specific data type÷string, date, or numeric, for example÷and length, and are enclosed within field separators. The fields are combined into logical groupings called segments÷such as patient identification, allergy, or next of kin÷that may be optional and/or repeating for a particular message and that display in a particular order within the message.
The timing of the message exchange is governed in HL7 by trigger events, of which there is a definitive list. Messages are sent when the trigger event occurs or they are batched and sent at one time. The HL7 standard assumes that an event in the real world of health care creates the need for data to be exchanged by two or more systems. For example, most hospitals use an ADT (admit/discharge/transfer) system and a patient billing system. A billing record is typically created for each patient admitted to the hospital. When the patient is admitted (this is trigger event A01÷admit/visit notification), general information about the patient is typically collected and entered into the ADT system. An HL7 admit/visit notification message (unsolicited update) can be sent from the ADT system to the patient billing system. Using the patient data (e.g., name, address, birth date, next of kin, diagnosis, insurance data, etc.) collected by the ADT application and transmitted via the admit/visit notification message, the patient billing system can then create a billing record for the patient just admitted.
Finally, the HL7 standard also follows the OSI model protocols governing communication of error messages between two systems. When information is exchanged between two systems, the receiving system validates the message, then returns a response message to the sending system indicating that the information either was successfully received, did not contain all required segments/fields, or could not be interpreted by the receiving system. At other times, the receiving application commits the message to storage, obviating the need to send an acknowledgement message to the sending application. The acknowledgement paradigm that will be used is specified in the interface negotiation contract and reflected in the message header.
HL7's mission statement specifies the key sets of data to be exchanged: those "that support clinical patient care and the management, delivery and evaluation of health care services." When the HL7 standard was first published in 1988, its coverage was limited to the domains prevalent in most inpatient settings: ADT, orders, observations, and finance. Since then, HL7's scope has expanded to reflect the changing trends and needs in health care. Version 2.3, HL7's current release, provides messages for outpatient settings, mirroring the current prevalence of managed care and the need for flow of transactions across enterprises. It includes a Referral chapter, which provides messages for exchanging data among the systems of primary care providers, specialists, payors, labs, and other entities involved in patient referrals. A new Scheduling chapter introduces messages for transmitting event data related to scheduling appointments for services and/or resources, and a Patient Care chapter provides messages to support the communication of records that track a patient's health care problems, related goals, and pathways for meeting those goals. A new Medical Records chapter introduces messages that support that domain.
A number of organizations regularly collaborate with HL7 to develop projects and/or provide solutions to needs in the marketplace. For example, the Centers for Disease Control and Prevention (CDC) worked with HL7 on its version 2.3 release to develop messages for its immunization registry. These messages enable care providers and state and community databases to query, update, and exchange immunization records. The CDC also uses HL7 for Electronic Lab Reporting and its Cancer Registry. Published in 1997, the CDC's DEEDS (Data Elements for Emergency Depart Systems) Release 1.0, uses HL7 messaging segments to help standardize data elements used by emergency department systems. Once standardized, these data can be collected and aggregated for a variety of public health uses including surveillance, community risk assessment and research. HL7 is also currently collaborating with X12N (another standards organization) and the Health Care Financing Administration to conduct a Proof of Concept prototype to automate claims attachments in response to the Health Insurance Portability and Accountability Act of 1996 (HIPAA).Future Directions
HL7 is constantly working to keep abreast of the changing needs. Our foremost project is Version 3, the next major release of the standard. This new version will use an object-oriented methodology and Reference Information Model. Created using a formalized process, HL7's Version 3 abstract messages will be described in a syntax similar to ASN.1 (which is based on data objects÷people, places, things about which data are kept÷and their interactions with and hierarchical relationships to other objects), and HL7 Version 3 implementations will support the present character-based message models and the object broker model using OLE/ActiveX and CORBA, network communication frameworks÷akin to operating systems÷that enable objects to communicate. HL7 Version 3 implementations may also support XML (extensible markup language), a restricted form of SGML and a character-based (as opposed to object-based) syntax for encoding data. An advantage of object-oriented data models is that they provide a very clear understanding of the content of the messages being exchanged. One of the initial steps in HL7's object-oriented messaging endeavors was "Health Level Seven Messaging over Component Technology," a recommendation recently drafted and approved for publication by the HL7 Object Brokering Technologies special interest group. This recommendation enables portability of program code between two environments and provides a means to transport HL7 messages using CORBA and ActiveX.
HL7's efforts at meeting the industry's changing needs are being fostered in its special interest groups (SIGs). The HL7 Security SIG recently drafted a proposal for sending messaging transactions over the Internet. Its work will become increasingly important as legislators grapple with the privacy and confidentiality issues surrounding HIPAA legislation. The Codes and Vocabulary technical committee will also play an important part in HL7's future. Its goal is to provide an organization and repository for maintaining a coded vocabulary that, when used in conjunction with HL7 and related standards, will enable the exchange of clinical data and information so that sending and receiving systems have a shared, well-defined, and unambiguous knowledge of the meaning of the data transferred. The HL7 SGML/XML special interest group is working with HL7 to develop, coordinate, and maintain a framework for interoperable Document Type Definitions for use in health care and health care standards, including HL7. Accountability, Quality and Performance is a new HL7 special interest group and will seek to identify specific data interchange features, functions, and/or content that can be engaged as reliable measure for÷and to provide evidence of÷accountability, quality, and performance. Points of authority for this work may include the Joint Commission on Accreditation of Healthcare Organizations Hospital Accreditation Standards and the National Committee for Quality Assurance HEDIS 3.0 Standard. Our newest special interest group, Blood Bank, was formed to standardize EDI transactions within the blood banking community. This group will focus on both the patient-related and the product/donor -related needs by seeking to standardize the information transmitted in order messages for blood products, to identify a means by which pertinent laboratory data can be transmitted with orders for blood products, and to evaluate the use of HL7 as a standard for transmitting donor and blood product information between a blood center and other facilities such as a transfusion service, an off-site donor testing lab, or a hospital.
Another driving factor in HL7's future direction is the globalization of the marketplace and the resulting need to share information across national boundaries. HL7 is used in many countries and we have established official affiliates in Australia, Canada, Finland, Japan, Germany, The Netherlands, and New Zealand. We encourage the acceptance and use of the HL7 Standard world wide and will thus actively participate in the newly formed ISO Technical Committee 215 on Healthcare Informatics.
H L7's 1,700 plus members include health care providers, software vendors, government agencies, and special interest groups. Most major hospitals use the HL7 standard and approximately 90 percent of the largest vendors are HL7 members.
HL7's mission is to provide standards for the exchange, management and integration of data that support clinical patient care and the management, delivery, and evaluation of health care services. Any provider who needs to exchange this type of data with his or her health care organization's enterprise system should be interested in and actively participating in HL7. Like many other SDOs, HL7 is ANSI accredited and ballots its standard using a consensus method, assuring that each of its constituencies has an active voice in the development of its standard.
If you would like to participate in the development of Health Level Seven standards, or if you would like additional information about our organization, its next meeting, or its members, visit the HL7 Web site or call our offices at 734-677-7777.
Update October 2001: The Art of Playing Together
Hall of Fame baseball manager Casey Stengel once remarked that, "it's easy to get the good players. Getting' 'em to play together, that's the hard part." These 16 words embody the mission of Health Level Seven (HL7). HL7 has always attracted "best of breed" vendors, the top medical centers and government agencies, and its goal of interoperability is based on getting those constituents to "play together."
But the analogy goes deeper. HL7 has grown substantially since 1998 when I last wrote an article for Medical Computing Today. Much of our hard work and growth is attributable to a number of other good playersaffiliates, other standards groups and, most importantly, our group of volunteers (providers, vendors, payers, consultants, government groups and others with an interest in the development and advancement of clinical and administrative standards for healthcare). This article summarizes the activities of the new "good players" that have joined HL7 in the past several years and their contributions to our organization.XML
One of the most challenging new players to join HL7 in recent years is XML. Like the Web-based HTML, XML is an easy to use markup language, but it is expansible and better capable of expressing complex data. HL7 had used its own encoding since publishing its first standard but realized that XML was quickly gaining acceptance in the information technology industry and that its ability to make information accessible via the Internet offered powerful benefits. While XML and HL7 experts assumed the task of becoming proficient in the other's technology, rumors spread that XML would replace HL7. But the XML and HL7 experts, now proficient in the other's technology, understood that their synergy would provide a tremendous benefit to the industry. XML can be used to quickly and simply exchange information but offers little in terms of semantic interoperability of that information once it has been exchanged. HL7 provides the underlying semantics of the data and, when paired with XML, can take advantage of the power and benefits of the Internet.HL7's Clinical Document Architecture
The first XML-based standard for healthcare, the Clinical Document Architecture (CDA), was published by HL7 in October of 2000 and was approved by the American National Standards Institute (ANSI) in November of the same year. The CDA, previously known as Patient Record Architecture, provides an XML-based exchange model for clinical documents such as discharge summaries and progress notes. A CDA-enabled document is machine readable, the benefit being that its content can be parsed and processed electronically. CDA documents can also be read by humans and displayed by XML-aware Web browsers or wireless devices such as cell phones and Palm pilots, making information available to a physician or other human who may be miles away from a patient.
Other XML-based projects within HL7 include a protocol currently out for ballot for encoding V2.x messages using XML, participation in ebXML and endorsement of its Messaging Service Specification for the secure transfer, routing and packaging of messages, and HL7's newest standard, Version 3.Version 3
Version 3 was released for initial ballot in August of 2001 following years of work and several months of anticipation. It contains over 200 messages and represents the intellectual contributions of hundreds of volunteers, many of whom are from competing companies or organizations.
Version 3 was developed using HL7's new model-based methodology, a completely new approach on HL7's part to clinical information exchange. The cornerstone of this methodology is the HL7 Reference Information Model (RIM), a pictorial representation of the data that can be exchanged, organized by common themes or classes of data, and their relationships to other classes. The RIM also yokes coded fields with explicit and controlled vocabulary, thus increasing the semantic interoperability of data such as ethnic background and diagnoses whose values are typically drawn from various code sets. Like the CDA, all V3 messages are based on and drawn from the RIM and are encoded using XML. Consequently, these messages are internally consistent and precise and, with the benefit of controlled vocabularies, allow for the exchange of fine-grained clinical data without the need for bilateral negotiations.
Version 3 will also be a first in that it will allow testing of a vendor's conformance to the standard. While conformance testing will not be offered with the first published release of Version 3, it is expected in the subsequent release, providing a much needed service in the industry.CCOW
The Clinical Context Object Workgroup (CCOW) has joined the HL7 team in recent years. The CCOW standard allows for visual integration at the front end. Disparate applications that are running on the same desktop or digital device and which are CCOW-enabled can be automatically synchronized based on the clinician's selection of user, patient, encounter, observation request or digital signature. For example, whenever one of several clinicians sharing a workstation signs on to a CCOW-enabled application, all other such applications will recognize the username/password and automatically synchronize to that clinician. This insures privacy while eliminating the need to sign on to each CCOW-enabled application separately. The first three releases of the CCOW standard were approved by ANSI in 1999, 2000 and 2001 respectively. CCOW V1.4, which adds a number of backward-compatible enhancements to the standard, is currently being balloted. Information on the new changes being proposed for CCOW V1.4 is available at: http://www.hl7.org/memonly/ballots/ccow/v14announce.htmlArden Syntax
Another new player in the HL7 arena is The Arden Syntax for medical logic systems. Initially developed and maintained by ATSM, this standard came under the auspices of HL7 in 1998 and a second version of the standard was published by HL7 and received ANSI approval in 1999. A language for representing and sharing medical knowledge among personnel, The Arden Syntax was developed for organizations that require or develop systems that automatically assist physicians in decisions and alerts. Logic for such decisions or alerts is encoded into knowledge bases called Medical Logic Modules (MLM), each of which contains sufficient knowledge to make a single decision. While The Arden Syntax is the least known of HL7's standards, we anticipate an increase in its use based on the current interest in quality of care and in the reduction of medical mistakes.
While HL7 has embraced both CCOW and the Arden Syntax, the challenge now is to get these two standards "playing together" with the other HL7 standards so that our complete family of standards is based on and drawn from the RIM. This will be a priority for HL7 once Version 3 is published.HL7's Growing List of Affiliates
Whether you've used the standards, visited the HL7 web site, or attended an HL7 meetings, you've no doubt noticed that HL7 is much more cosmopolitan than it was just three years ago. Since 1998, 11 new affiliates have joined HL7: Argentina, China, India, Japan, Korea, Lithuania, Southern Africa, Switzerland, Taiwan, Turkey and the United Kingdom. These affiliates joined affiliates already established in Australia, Canada, Finland, Germany, The Netherlands and New Zealand. Each affiliate organization employs principles that mirror those of the parent HL7 US organization, including abiding by ANSI rules of consensus and openness. Affiliates participate in all technical committees and special interest groups, have a vote at the RIM Harmonization meetings (where changes to the HL7 RIM are discussed and voted on) and elect one representative to sit on the HL7 Board of Directors. The affiliates also have their own International Committee that meets during the regularly-scheduled HL7 Working Group meetings and, for two years in a row now, have convened their own annual meeting, last year in Germany and this year in the United Kingdom. Both of these annual affiliates meetings have attracted over 100 participants from around the globe.
The tag line of our V2.4 protocol, "The Global Healthcare Messaging Standard", attests to this recent dramatic increase in affiliates. The affiliates have contributed several valuable changes to our standards to accommodate ethnic and country-specific requirements such as various Japanese character sets, surname prefixes such as "van" or "de" in the Dutch and German languages respectively, and representation of address information that is expressed differently than in the States. Earlier this year the affiliates petitioned the HL7 Board of Directors to approve the creation of financial transactions to support a standard e-claims submission process. Not intended for use in the United States, these transactions will support representation of insurance companies, covered persons, policies, etc. in countries where X12 and EDIFACT are not used and have resulted in substantial contributions to HL7 RIM.
Two new special interest groups (SIGs) have been formed as a direct result of affiliate involvement. The Community-Based Health SIG was formed in 1999 with support from members in Australia, Finland, The Netherlands, Japan, Canada, Germany and the US to promote adequate information exchange between Community Based and Acute Care service domains. The Medication Information SIG was formed earlier this year to assure that HL7 messages and models concerning medication related information--including prescribing, dispensing, and administering medication--address all of the requirements of the many stakeholders and variations in different countries.
In October of this year, a proposal is expected for the formation of a new Electronic Health Record SIG. Representatives from Australia and the European affiliates are spearheading that initiative. Their proposed mission is to define a high-level architecture to support a variety of interoperability requirements for electronic health records. HL7 views the need for an Electronic Health Record as a major driver to its future direction. This will require HL7 to begin address data storage and retrieve, two areas that have traditionally been outside the scope of HL7.HL7 and CEN/TC251 Agree to Collaborate
Of significant importance, in May 2000, HL7 and CEN/TC 251, the European Committee for Standardization's Technical Committee for Health Informatics, signed an official Memorandum of Understanding (MOU). The intent of this MOU is to intensify collaborations between the two groups with an ultimate goal of the development of technically identical and interchangeable US and European standards. While a merger of the two groups is unlikely, each group will solicit and welcome comments from the other, and technical documents and solutions will be freely shared.HIPAA Involved in Charting HL7's Direction From our perspective, the Health Insurance Portability and Accountability Act of 1996 (HIPAA) will standardize the way medical information is exchanged, thereby increasing the efficiency of the healthcare delivery system. It will improve the accuracy of the information exchanged, because everyone is using the same standard to exchange information, including the same code sets for key pieces of information. It will also further collaboration between the standards development organizations (SDOs), although HL7 has worked with other organizations in the past (for example, HL7 and X12N have been working together for several years now on a transaction for claims attachments).
In recognition of the need for cooperation among the healthcare standards developing organizations as HIPAA transactions are legislated and implemented, in March 2000 an HL7 representative was invited to join the Workgroup for Electronic Interchange (WEDI) Board of Directors. Then, in May of 2000, HL7 was named by the Department of Health and Human Services as one of the six Designated Standards Maintenance Organization (DSMO) that will form the consortium responsible for managing and maintaining the electronic data interchange transaction standards adopted as national standards under HIPAA. Along with National Council for Prescription Drug Programs (NCPDP), The Insurance Subcommittee of the ANSI Accredited Standards Committee (X12N), National Uniform Claims Committee (NUCC), National Uniform Billing Committee (NUBC) and American Dental Association (ADA), HL7 reviews monthly submission of requests to enhance or change the current national standards and participates in responding to those requests when appropriate.
HL7 also provided testimony and submitted information in August of 2001 to the National Committee on Vital and Health Statistics on patient medical records, and we anticipate that HL7 will play a major role in those types of transaction.
Since January of 2001, HL7 has been working with American Society for Testing and Materials (ASTM) E31.20, The Internet Engineering Task Force: Electronic Data Interchange--Internet Integration (IETF EDIINT), NCPDP and X12N on a digital signatures project that supports HIPAA security requirements. Coordinated by the ANSI Healthcare Informatics Standards Board (HISB), these groups initially met at the May 2001 HL7 meeting in Minneapolis, where they drafted a purpose and scope statement.
The purpose of this project is to work jointly to "produce an electronic signature standard implementation in support of HIPAA security requirements." The scope and objectives of this project include identifying "the requirements for electronic signatures in health care based on ASTM standards E1762 and E2084. It will seek implementable solutions for integrating persistent confidentiality, authenticity, integrity, and non-repudiation into messages and documents. Public Key Infrastructure (PKI) considerations are excluded."
One of the first steps in providing such a standard implementation involved soliciting candidate use cases (real-life examples of how a particular technology or system will be used) from each of the SDOs involved in the project and getting input from HISB on them. As of the September 7, 2001 HISB meeting, uses cases had been submitted and reviewed for patient consent, attachments, dictation and education records by three of the SDOs, and the group had identified potential vendors to participate in the infrastructure of the project. Enrolling providers and payers in the project is next, followed by selecting a site for the servers that will house the project. The group meets again at the December HISB meeting. For more information about this project, see the following URL: www.hl7.org.special/committees/multiSDO/index.htm.
The HL7 Security and Accountability Special Interest Group is also working on an audit message, prompted by anticipated HIPAA requirements, and plans to collaborate with ASTM and Electronic Manufacturer Association (EMA)/Digital Imaging and Communications in Medicine (DICOM) once the initial informative ballot is approved by HL7 participants.Collaboration With other Key Groups
HL7 collaborates with many other groups to advance it goal of interoperability. The Clinical Data Interchange Standards Consortium (CDISC) is the newest group to join HL7, their interest being HL7's Clinical Trials special interest group. HL7 and DICOM have been collaborating for years via HL7's Imaging Integration SIG and a corresponding group within DICOM. We hope to formalize that relationship before the end of 2001 with the goal of facilitating the integration of imaging and information systems within healthcare enterprises. The National Committee for Clinical Laboratory Standards (NCCLS), a long-established group that develops clinical laboratory system specifications, and the Connectivity Industry Consortium (CIC) , which develops standards for physical connectivity and communications between portable laboratory testing equipment, joined HL7 in 1999 and 2000 respectively and consequently developed HL7-based messages for their domains that comprise and were published in the Laboratory Automation chapter of the HL7 V2.4 standard.Conclusion
Collaboration and negotiation between members and outside organizations have been major factors in HL7's growth and success in recent years. HL7 remains committed to its original goal of interoperability and continues to challenge its members to work to together to achieve the many levels of interoperability required to provide industry solutions. HL7 actively seeks and welcomes the input and work of other "good players." To contact HL7, send-mail to HQ@HL7.org.
In the late 1980s, several individuals from the medical informatics community took the ASTM E31 standard on message communication and formed a new organization to promote and implement this standard on the OSI application level seven for health care, thus forming what is now the most important standards organization for the 1990s. In 1987, it published HL7 version 1.0. Two years later, substantial improvements had led to version 2.0. In 1994, version 2.2 was published and HL7 became accredited as a standards development organization (SDO) by the American National Standards Institute.
HL7 has grown from its intrahospital communications roots to being a comprehensive messaging standard that includes many parts of healthcare communication, and is the de-facto communication standard in health care. The majority of vendors in the United States incorporate the HL7 standard in their software and many healthcare providers use it for clinical messages, including communication for administrative functions, financial support for clinical practice, scheduling, orders, and results.
The HL7 standard also partly addresses reporting results containing waveform data, immunization queries and reporting, clinical trials definitions and reporting, clinical master file support, clinical referrals, transcription processing, and other clinical messaging applications. In addition, HL7 now has working groups in decision support, XML, vocabulary issues, home health, image management, professional credentialling, and other areas. With more than 1,600 members, it is by far the largest standards organization in health care; all other ANSI-accredited standards organizations as well as other consortia and developers fade in comparison because of HL7's large membership, widely accepted use, and levels of activity. Internationally, despite a lack of support from healthcare standards organizations for the reasons given below, HL7 is being used by vendors and providers in many countries and has substantial user groups, notably in Germany, Finland, Japan, and Australia.
D espite the indisputable strength of HL7 as the most used clinical messaging standard, it is the most controversial standard. This can be traced to its four weaknesses -- ambiguity, messaging limitations for the future, lack of documentation issues, and implementation -- which are the focal point of discussions in the health informatics community.Ambiguity
I personally get many calls from hospitals and others who tell me that when they purchased a system they insisted that it should comply fully with the main healthcare standard (HL7) in order to achieve connectivity, perhaps even interoperability with further systems. When the next system was purchased, they insisted again on full compliance with HL7. At the installation they found out that systems that comply fully with HL7 do not interoperate unless a specific interface engine is put between the two. Indeed, HL7 is designed to allow customization up to 70%. The point is that standards are here to ensure interoperability. If your American plug does not fit into an English electrical outlet, one might say, "Oh, we need a standard for this." A standard should be tight and allow interoperability of two devices or systems without the need for customized interfaces. HL7 does not provide this.
This might have been the industry's notion of messaging and connectivity in the late 1980s, but at the end of the 1990s, a tight communication standard that allows a plug-and-play scenario is needed. The leadership of HL7 is addressing this in its work on Version 3.0, but is not clear if this can be achieved. A consortium, the Andover Working Group, under the leadership of Hewlett Packard, is trying through object technology to achieve a tighter communication match. It remains to be seen which one, if any, of these attempts will provide in a timely manner what the market needs.Messaging
The HL7 standard is based on its proprietary syntax and is competing with EDIFACT, a worldwide communication syntax used consistently in most countries. Although EDIFACT has many weaknesses of its own, it is politically the established worldwide EDI standard. Unfortunately, HL7 members put too much emphasis on the messaging syntax. As our society moves toward a global communication system consisting on user-friendly e-mail and Internet communication, messages will become less important. This will have a negative effect on HL7 in its traditional form.Lack of Documentation
Unfortunately, the leadership of HL7 has not seen in the past the need for sufficiently integrating the documentation features into the messaging system. Documentation issues include authentication (electronic signature), data integrity, availability, and auditability. Current work on a secure messaging wrapper is a much belated attempt to address some of the long-overdue communication requirements. It seems that some HL7 experts want to address these issues through SGML/XML avenues. This may be a partial solution to a much bigger problem.
The healthcare industry needs communication standards that allow the transition from paper-based medical records to electronic medical records. This can only be achieved with a communication standard that includes electronic signatures and data integrity features. It is not clear whether Version 3.0 will become the much needed communication standard that allows the exchange of electronic patient record information without paper backup.Implementation
The lack of tight implementation standards has led to a mixture of HL7 versions in the international arena. Will it be possible to follow the tighter implementation versions as used in Germany and other countries? Could a worldwide tight implementation standard be created?Current HL7 Developments
HL7 is putting much effort into Version 3.0. The standard organization's greatest strength, a vast membership, and very strong industry participation may also be its greatest impediment. Industry representatives may not want to move as quickly to the needed solutions as HL7's leaders wish. On the other hand, if an SDO's strength can be measured by the participation it attracts, then HL7 can respond to the demands in health care better than any other SDO.
The new ISO Technical Committee (TC) 215 for Health Informatics has decided to address messaging in one of its working groups. Standards for financial/business messaging, clinical messaging, medical device messaging and clinical image messaging will be created. It will be interesting to see if the HL7 standard in its entirety, or parts thereof, can emerge as one of the internationally agreed-upon communication standards.
HL7's leadership also recognizes that much of the future will be in object technologies. Will the HL7 effort be a message-based object technology approach or will it include a healthcare architecture for components and objects? If the latter is attempted, the question arises whether HL7 will have the expertise among its members and whether its membership will support such an approach.
As the demand for interoperable, international, and non-ambiguous communication standards in health care increases, these issues are a major challenge for the HL7 organization.
January 2, 1999
To The Editors:
[In the second article, Blessing or Impediment? The Importance of HL7 by C. Peter Waegemann,] (t)he description of the relationship of ASTM to the initial HL7 work is not quite correct. I was technical chair of HL7 at the time and remember the details quite well. The first work was started in Philadelphia, at the Hospital of the University of Pennsylvania, in the spring of 1987. None of the activists on the ASTM 1238 committee were part of the original group, and there was no focus on data models (OSI or otherwise). That happened much later, through the influence of IEEE Medix. The fact that Medix was founded at about the same time as HL7 was founded may have contributed to the misunderstanding. Version I of HL7, published in October of 1987, did not have any functional content from ASTM, nor was it very similar to it. Indeed, it covered registration and ADT (which ASTM did not). The syntax was similar to ASTM, but it was also similar to X12 - and other public and proprietary data syntaxes from three HL7 members (software vendors) who offered their intellectual property to the common effort.
The tight relationship between HL7 and the ASTM 1238-88, reporting syntax did not appear until HL7 version 2, and this resulted from a conscious effort by the ASTM and deliberate compromises between the HL7 and the ASTM committees to avoid the evolution of two quite distinct ways to transmit clinical data for the common good. Throughout this collaboration, HL7 transactions always had a much larger scope than ASTM 1238, which dealt only with the ordering and reporting of clinical observations. The ASTM committee considered the collaboration a very good thing, because HL7 had such a high participation of members from the health informatics industry compared to the more academic composition ASTM committee.
Further, the sharing went in both directions. Many fields, data types, features and segments were developed first in the HL7 committee and later adopted by ASTM. This sharing was formalized in an official agreement between the officers of HL7 and ASTM, and was helped by the fact that for nearly a decade the ASTM committee and the HL7 orders-results committee had the same chair and an overlapping membership of the volunteers who actually wrote the two standards. I applaud the history of cooperation between HL7 and ASTM - - it has been a very good thing for health informatics.Wes Rishel
Board member, Health Level 7
The above was forwarded to the author of the article, who responded:
January 25, 1999
My statement that "several individuals from the medical informatics community took the ASTM E-31 standard on message communication and formed a new organization" can be interpreted in many ways. I did not mean it to be controversial, but rather to indicate that the HL7 standard is based on ASTM E-31's standard 1238. Then, as today, many standards experts were active in various standards organizations. Wes Rishel's recollection is appreciated.Peter Waegemann
of other articles
Other MCToday articles on Standards: