Common Business Library (CBL)   Table of contents   Indexes   XML and e-Commerce
 

HL7-XML Progress Report
 Tom   Lincoln
  Representative of the SGML/XML SIG of HL7 and the "Kona Editorial Group" within it
 
Email: lincoln@rand.org
 
Biographical notice:
 Alschuler, Liora 
 Boyer, Sandy 
 Spinosa, John 
 
 John   Spinosa
  Representative of the SGML/XML SIG of HL7 and the "Kona Editorial Group" within it
 
Email: john@spinosa.com
 Sandy   Boyer
  Representative of the SGML/XML SIG of HL7 and the "Kona Editorial Group" within it
 
Email: slboyer@ibm.net
 Liora   Alschuler
  Representative of the SGML/XML SIG of HL7 and the "Kona Editorial Group" within it
 
Email: liora@the-word-electric.com
 

Introduction
 
At SGML '96 in Boston we presented "Medicine for SGML," proposing the utility of using SGML for managing electronic medical records. An interoperability proof of concept using XML in health care was recently completed at the February HIMSS  (Health Information Management System Society) meeting in Atlanta, Georgia, which attracted 17,500 attendees.
 
The project was conceived and carried out by HL7 (www.hl7.org), which is the dominant health care standards organization for healthcare message communication from machine to machine in the United States, with an active presence in Europe, Australia, and most recently in Japan. One of the key features of the proof of concept was the use of XML for both health care messages as well as clinical record documents. Much of the work was carried out under the aegis of the SGML/XML SIG  (special interest group) , which had been formally started in 1997. Recently, HL7 designated a member of the SIG to be the representative to W3C, which has opened a new avenue for the communication of our objectives.
 

The HIMSS Demonstration
 
The HL7 XML demo represents the culmination of three years of effort by the HL7 SGML/XML SIG and the various other SIG s and technical committees of HL7. It is the latest development in bringing together two standardization efforts, the HL7 healthcare communication protocol and a markup strategy for medical information using XML. Each builds upon years of real-world implementation experience. The HL7 organization is creating two related standards of markup using XML - one for machine to machine messaging and one for clinical record documents. In this demonstration, ten volunteer vendors, each with their own stand-alone healthcare products, shared information using a common management interface. This interface used the XML DTD of the draft Level One PRA  (Patient Record Architecture) and the prototype Version 3 messaging conventions from HL7's RIM  (Reference Information Model) , a comprehensive object-oriented compilation of the events and transactions that are involved in clinical healthcare message exchange.
 
The HIMSS demo is the broadest test to date of these prototypes and the first instance of message/document interaction based on the HL7 specifications.
 

XML and HL7's Reference Information Model
 
The purpose of the RIM is to play a central role in assuring that the work of HL7 will be consistent when applied to different functional areas, technologies, and modalities. It has been constructed over the past two years through the collaboration of a group of HL7 committees representing centers of expertise in such matters as patient administration and finances, clinical orders and observations, patient care, medical records information management, public health and governmental requirements. Their knowledge has been combined through the HL7 " RIM Harmonization" process and other methodologies developed by HL7 specifically to meet the needs of writing information-intensive standards. HL7 has invested a substantial portion of its annual budget in providing software and staff to support this process. XML has begun to contribute an important and previously missing bi-directional validation component to this process by a mapping of portions of the RIM into Patient Record Architecture (PRA) DTDs as well as by testing use of the evolving MDF  (message development framework) to develop DTDs.
 

Other Advantages of XML to HL7
 
This same validation process provides precise logic for vendor conformance and testing. HL7 gains other advantages. XML parsers remove the need for building specialized HL7 parsers from scratch, and implementers can add validation constraints as required. Because of industry enthusiasm for XML, HL7 anticipates growth of a broader pool of XML-trained individuals, minimizing recruiting difficulties for vendors and providers. The related specifications and tools, such as style sheets and XML-aware office suites will simplify the open interaction and development of applications derived from the HL7 message flow.
 

The Patient Record Architecture (PRA)
 
The Patient Record Architecture or PRA is an outgrowth of "Operation Jumpstart" in the summer of 1997 and the resultant "Kona Proposal" and the "XML-Mixer" which was its first test. It uses some of the features of HyTime in establishing a general architectural framework for the exchange of clinical documents. XML DTDs written for specific applications and domains (e.g., medical specialties) can be mapped to the PRA . Senders can transform documents with their locally defined tags into documents carrying the industry-standard HL7 PRA markup. While it might seem simpler to write common DTDs that everyone can use, in the real world applications and providers need to express their own clinical practice and business rules in their own DTDs. The PRA is a mechanism for automating exchange without impinging on the expressivity or flexibility of such local implementations.
 
The benefit for exchange lies in the power of the XML PRA to express relationships between the local DTDs used for document creation and the HL7 RIM using the architectural exchange DTDs.
 
The PRA is based on a set of design principles that include keeping the barrier to entry low, while providing a migration path toward ever more sophisticated electronic medical records, both for implementers and for the standard itself. There are three levels to the architecture with increasing levels of granularity of markup (called Coded Header, Coded Context, and Coded Content), plus a common header for all levels that uniquely identifies and classifies the document, attestation details, event, patient, and practitioner. The basic level of the architecture (Level One), shown at HIMSS , supports display and simple processing. Level One PRA documents have a standard framework for including coded vocabulary terms and controlled terminology and can carry the semantic of the local markup as an optional feature. One benefit of the multi-level architecture is that implementation and standards development groups can inform and assist each other in a cooperative, iterative process toward documentation that is increasingly fine grained.
 

Present and Future Work
 
The HL7 SGML/XML SIG is extending the PRA framework and working with the other SIG s and technical committees to refine both the HL7 V3 message derivation methodology and the RIM to meet the needs of applications as divergent as decision support and practice management. The HIMSS interoperability demo shows how even simple applications provide tremendous utility, because basic patient, practitioner, event and document information is synchronized and made compatible between the PRA and the HL7 V3 messages.
 
Timing has been important. The SGML/XML SIG became part of HL7 in January 1997, one month after the announcement of XML. Eliot Kimber took part in Operation Jumpstart. Tim Bray of Textuality and later Jon Bosak of SUN attended HL7 meetings and provided their special insights, expertise and enthusiasm to move the convergent process forward. The draft HL7 Level One PRA DTD and V3 messaging specification are close to completion and ready for trial implementation. Several vendors have started to work with them and the HIMSS demo includes several "firsts".
 

The Demo Scenarios
 
The demo uses the following scenarios to showcase HL7 XML in messages, documents, and message/document interactions:
 
  1.  Enhanced Clinical Care Scenario
     A patient is registered in one system, seen by a physician as recorded in an Electronic Medical Record system, has lab work done by an external lab, and the combined information is available in the EMR, a data repository, and a medical Intranet. The technologies involved include a mixture of legacy technologies, client server, and Web-based applications, and both document- and relational-technology databases. Indeed, some of the systems are operating on the present HL7 version 2.3, demonstrating the evolution that will be necessary to introduce the benefits of version 3 to the marketplace.
  2.  Repository scenario
     A sophisticated medical records system and a transcription-to-XML system send PRA -compliant documents to an HL7 clinical data repository and to an XML document repository. Each repository can respond to queries for documents from both sources - the CDR by indexing the V3 message envelope that carried the document and the document repository by parsing the document itself. Data fields in theV3 envelope message are automatically generated from the contents of the PRA documents. While the documents are created with vastly different technologies, common processing methods apply to all, regardless of source. Both types of repository also store and index V3 XML messages including patient registrations, lab orders and results, etc. so they can build a complete picture of patient care.
  3.  Lab scenario
     A PRA History & Physical document triggers a V3 lab order message by including the appropriate LOINC code (a laboratory standards indexing system) under "Labs" in the Plan section of the document. The HL7 interface engine translates the V3 message to V2.3 for the lab system working under the present standard. Then, going the other way, it translates the lab results from V2.3 to V3. The V3 XML results message is used to "autopopulate" the results section of a Progress Note.
 

The Evaluation
 
Wes Rishel was HL7's coordinator for this demonstration. He is Vice-Chair of the Technical Steering Committee, and a member of the HL7 board of directors. He finds the most impressive facet of the demo to be that it is a coordinated approach that applies to different information needs, functional areas, and types of technology, which is exactly the desired objective of HL7. "Without the resources provided by HL7, the healthcare industry would have approaches to standards that are compartmentalized.
 
Providers and vendors operating in such an environment would have difficulty meeting their numerous competing requirements."
 

The Players and the Playing Field
 
There were ten vendors. Seven applications used prototype HL7 documents.
 
Eight applications used prototype V3 XML messages. One application used HL7 version 2.3. Six applications involved some message/document interactivity.
 
There were three document types: the PRA Level One architecture, a History & Physical and a Progress Note. There were twelve message types including registrations, lab orders and results, query/response, and one document envelope.
 
Care Data (clinical data repository and patient administration): generated V3 Patient Demographics; and responded to queries for data from the repository about Patient Demographics, Lab Results, and Documents.
 
CareFlow|Net (transcription): generated a V3 Progress Note as a transcription.
 
Epic Systems (EMR and patient administration): generated V3 Patient Demographics.
 
Health Network Ventures (Medical Intranet): generated queries by Patient Name or Patient ID for Lab Results and Documents.
 
Medical Logic (EMR)
 
Oceania (EMR): generated a V3 History and Physical in response to structured input.
 
Orchard Software Corporation (lab): generated a Lab result message in HL7 V2.3 format in response to a lab order.
 
Sequoia Software (document repository)
 
Software Technologies Corporation (interface engine): V2.3 messages translated into the standard V3 message architecture for Patient Demographics, ADT, lab orders, lab results, etc., and V3 lab orders translated into V2.3 for Orchard Software.
 
Texcel (document management): converted a Progress Note from a lab result message; created a SOAP Note from previous Oceania H&P, a lab result, and user input; created a lab request if present on an Oceania H&P.
 
Wizdom Systems: although not present in Atlanta, Wizdom Systems hosted and completed our testing.
 
Acknowledgments
 
Thanks go to many participating parties in HL7 and in the SGML/XML SIG .
Common Business Library (CBL)   Table of contents   Indexes   XML and e-Commerce