# Presentation: 910805

## XML Technology in HL7’s Patient Medical Record Information Exchanges*National Committee on Vital and Health StatisticsMarch 29, 1999

**XML Technology in HL7’s Patient Medical Record Information Exchanges*****National Committee on Vital and Health Statistics****March 29, 1999**

**Robert H. Dolin, MD**
**Kaiser Permanente**

***Disclaimer: Opinions are those of the author. XML activities have not yet been subjected to HL7’s formal ballot process.**

**Notes:**
Robert H. Dolin, MD
Robert.H.Dolin@kp.org

Primary affiliation: 
Kaiser Permanente - Department of Internal Medicine, National Clinical Information Systems

Secondary affiliation:
Assistant Clinical Professor of Medicine, UCLA

Primary responsibilities: 
Provide patient care
National medical terminology project
National clinical intranet 
HL7 and KP XML activities
National Electronic Health Record

## Outline

**Introduction to XML**
**XML Healthcare Applications**
- Medical Publishing
- Messaging
- Clinical Documents
**Conclusions**

## SGML
User-defined tags.
A set of user-defined tags apply to a class of documents.
HTML
A fixed set of tags.
Uses the rules of SGML to define its set of tags.
The set of HTML tags are used in all HTML documents on the World Wide Web.
XML
User-defined tags that apply to a class of documents.
A formal (simpler) subset of SGML.

**SGML**
- User-defined tags.
- A set of user-defined tags apply to a class of documents.
**HTML**
- A fixed set of tags.
- Uses the rules of SGML to define its set of tags.
- The set of HTML tags are used in all HTML documents on the World Wide Web.
**XML**
- User-defined tags that apply to a class of documents.
- A formal (simpler) subset of SGML.

- XML embeds <BOLD> **tags **</BOLD> in documents.
- These tags tell a computer how to process a document.

**Notes:**
SGML is an international standard document markup language and specifies the rules by which users can create a set of tags to embed within documents. A “user” might range from an individual to a national standards organization. A class of documents whose tags are drawn from a particular tag set can be created.

The best known use of SGML is HTML (HyperText Markup Language), which uses the rules of SGML to define a specific set of tags that can be embedded within documents, enabling them to be viewed and linked to one another over the world wide web. The set of HTML tags are used in all HTML documents on the World Wide Web.

XML is a proper subset of SGML (meaning that all XML documents are valid SGML documents) that excludes some of the more obscure or less-used features. The appearance of XML-aware web browsers greatly extends the types of documents that can be delivered over the Internet. 

## HTML is SGML (although not XML)

- <h2>Patient Information</h2>
- <ul>
-      <li><b>Name:</b>Henry Levin, the 7th</li>
-      <li><b>MRN:</b>123456789</li>
-      <li><b>DOB:</b>May 13, 1900</li>
- </ul>
- <h2>Clinical Data</h2>
- <p>History of smoking for 40 years.
- <h2>Procedure</h2>
- <p>Chest X-ray
- <h2>Findings</h2>
- <p>Comparison is made with a chest-x-ray ...
- <h2>Impressions</h2>
- <p>RLL nodule, suggestive of malignancy. Compared with a prior CXR from 6 months ago, nodule size has increased.
- <h2>Recommendations</h2>
- <p>I notified the ordering physician of this finding by phone.

**Radiology Report - Chest X-Ray**
**Patient Information**
-  **Name:** Henry Levin, the 7th
** ****MRN:** 123456789
** ****DOB:** May 13, 1900
**Clinical Data**
- History of smoking for 40 years.
**Procedure**
- Chest X-Ray
**Findings**
- Comparison is made with a chest x-ray ...
**Impressions**
- RLL nodule, suggestive of malignancy. Compared with a prior CXR from 6 months ago, nodule size has increased.
**Recommendations**
- I notified the ordering physician of this finding by phone.

**HTML is SGML (although not XML)**

**Notes:**
This figure shows an HTML-encoded radiology report along with a display of how that report might look when viewed with a typical web-browser. The tags tell the web-browser how to display the information sandwiched between a corresponding pair of opening and closing tags. So for instance, the text occurring between the opening tag ‘<b>’ and the closing tag ‘</b>’ is displayed in bold. 

The HTML specification declares the set of tags allowed in HTML documents. The SGML standard gives the rules by which HTML can make such a declaration. 

(The previous slide stated that XML is a formal subset of SGML. Therefore, there are certain features of SGML that are not a part of the XML specification - some of which are used in the HTML specification. Therefore, some HTML documents are not proper XML documents.)

## XML - Define your own tags

- <RadiologyReport>
- <PatientInfo>
-      <Name>Henry Levin, the 7th</Name>
-      <MRN>123456789</MRN>
-      <DOB>May 13, 1900</DOB>
- </PatientInfo>
- <ClinicalData>History of smoking for 40 years. </ClinicalData>
- <Procedure>Chest X-ray</Procedure>
- <Findings>Comparison is made with a chest-x-ray ...
- </Findings>
- <Impressions>RLL nodule, suggestive of malignancy.
-      Compared with a prior CXR from 6 months ago, nodule
-      size has increased.
- </Impressions>
- <Recommendations>I notified the ordering physician of
-      this finding by phone.
- </Recommendations>
- </RadiologyReport>

**Radiology Report - Chest X-Ray**
**Patient Information**
-  **Name:** Henry Levin, the 7th
** ****MRN:** 123456789
** ****DOB:** May 13, 1900
**Clinical Data**
- History of smoking for 40 years.
**Procedure**
- Chest X-Ray
**Findings**
- Comparison is made with a chest x-ray ...
**Impressions**
- RLL nodule, suggestive of malignancy. Compared with a prior CXR from 6 months ago, nodule size has increased.
**Recommendations**
- I notified the ordering physician of this finding by phone.

**Notes:**
A different set of tags can be declared for use in a particular class of documents. The document class must then conform to this different set of tags.

This figure shows the radiology report of the previous figure encoded according to a different set of tags. In this case, the tags do not specify the format or display characteristics of the intervening text. Rather, the tags in this alternative representation are intended to specify the semantic content or context of the encoded text. 

These are user-defined tags. The tag names are meaningful to the user that created them.

## XML - Define your own tags

**XML - Define your own tags**

- <RadiologyReport>
- <PatientInfo>
-      <Name>Henry Levin, the 7th</Name>
-      <MRN>123456789</MRN>
-      <DOB>May 13, 1900</DOB>
- </PatientInfo>
- <ClinicalData>History of smoking for 40 years. </ClinicalData>
- <Procedure>Chest X-ray</Procedure>
- <Findings>Comparison is made with a chest-x-ray ...
- </Findings>
- <Impressions>RLL nodule, suggestive of malignancy.
-      Compared with a prior CXR from 6 months ago, nodule
-      size has increased.
- </Impressions>
- <Recommendations>I notified the ordering physician of
-      this finding by phone.
- </Recommendations>
- </RadiologyReport>

- <!ELEMENT RadiologyReport
-         (PatientInfo, ClinicalData,
-          Procedure, Findings, Impressions,
-          Recommendations)>
- <!ELEMENT PatientInfo
-         (Name, MRN, DOB)>
- <!ELEMENT Name                      (#PCDATA)>
- <!ELEMENT MRN                      (#PCDATA)>
- <!ELEMENT DOB                       (#PCDATA)>
- <!ELEMENT ClinicalData           (#PCDATA)>
- <!ELEMENT Procedure               (#PCDATA)>
- <!ELEMENT Findings                 (#PCDATA)>
- <!ELEMENT Impressions            (#PCDATA)>
- <!ELEMENT Recommendations  (#PCDATA)>

**Notes:**
The set of tags, as well as the legal arrangement of those tags within a document, are defined using the rules specified in the XML Standard, and are expressed in a separate document called a Document Type Definition (DTD). 

The DTD specifying the tags and allowable tag arrangement for the XML-encoded radiology report of the previous figure is shown here. (There are slight differences between SGML DTDs and XML DTDs.)

The tag or ‘element’ named ‘RadiologyReport’ is specified as containing a single occurrence of elements ‘PatientInfo’, ‘ClinicalData’, ‘Procedure’, ‘Findings’, ‘Impressions’, and ‘Recommendations’. The element named ‘PatientInfo’ is further specified as containing a single occurrence of elements ‘Name’, ‘MRN’, and ‘DOB’. The elements ‘Name’, ‘MRN’, DOB’, ‘ClinicalData’, ‘Procedure’, ‘Findings’, ‘Impressions’, and ‘Recommendations’ will contain text data and no other tags.

The bottom right figure shows a hierarchical representation of the radiology report, illustrating that tags within XML (and SGML) documents properly nest. So, for instance, the “Name” tag can only occur between the opening and closing “PatientInfo” tag.

## XML - Computer-processable documents

**XML - Computer-processable documents**

**XML**
**Processor**

***XML reduces a document (or message) to a word in a known context-free grammar through a process of markup.***

**Notes:**
An XML processor converts an XML document into a computer-processable object. Tags within an XML document properly nest resulting in a hierarchical document structure. 

Tags are not allowed just anywhere within a document. A DTD represents a formal grammar that states exactly where tags can occur and which tags nest under which other tags. In many ways this turns an XML document into a chunk of computer code which can be validated before it is compiled. Formally stated, XML reduces a document (or message) to a word in a known context-free grammar through a process of markup.

Thus, a computer can validate that an XML document conforms to the declarations stated in the corresponding DTD. If you send someone a document and they have the DTD, they can validate the document against that DTD. Also, when authoring a document, you can check to make sure it conforms to the DTD.

## History of XML in HL7

**History of XML in HL7**

**1986 SGML**
- ISO 8879:1986
**1996 SGML Initiative**
- The original vision and charter for the deployment of SGML in healthcare was developed by John Mattison and John Spinosa.
**1996 HL7 SGML/XML Special Interest Group**
- HL7 Presidents Ed Hammond and Woody Beeler strongly support inclusion of SGML/XML activities within HL7.
- Co-chairs: John Mattison, Rachael Sokolowski, Paul Biron, Liora Alschuler.
- Objectives:
- Coordinate the development of a comprehensive document architecture for healthcare;
- Educate the healthcare community in the capabilities and utility of SGML/XML;
- Investigate the use of SGML/XML as a messaging syntax
**1998 XML**
- Approved Feb ‘98 by W3C

**Notes:**
SGML was approved as an ISO standard in 1986.

An initiative for the deployment of SGML in healthcare was developed in 1996 by John Mattison and John Spinosa. HL7 Presidents Ed Hammond and Woody Beeler strongly supported the inclusion of SGML/XML activities within HL7, and the SGML Initiative became a Special Interest Group of HL7.

XML was approved by the W3C in 1998, at which point the HL7 SGML Special Interest Group was renamed the HL7 SGML/XML Special Interest Group.

## Outline

**Introduction to XML**
**XML Healthcare Applications**
- Medical Publishing
- Messaging
- Clinical Documents
**Conclusions**

**Notes:**
References
Dolin RH, Alschuler L, Biron PV, Fuller LM, Kim AH, Minkler WT, Onaga D, Mattison JE. Clinical Practice Guidelines onto the Internet: A Structured, Scalable Approach. MD Computing 1999: (in press).

## Medical Publishing

**Medical Publishing**

**What?**
- Textbooks
- Journal Articles
- Clinical Guidelines
- Pharmacy, Lab Manuals
**Why?**
- Rapid wide-spread deployment
- Consistency in content and presentation
- Enhanced search performance
- Application-independent persistent format

**Notes:**
SGML has a long history of use in the publishing domain, including SGML-based publishing standards used by the DOD, SEC, and Library of Congress. XML will carry on and expand the tradition. Some of the reasons for SGML/XML’s popularity in publishing include:

Rapid Wide-spread Deployment: All XML-encoded documents can be converted into HTML for viewing over the web. (Newer web browsers combine an XML document with an XML “style sheet”, enabling XML documents to be rendered directly on web browsers without a conversion to HTML.)

Consistency in Content and Presentation: A computer can validate that a document conforms to a particular DTD. All documents that conform to a particular DTD will use the same set of tags and the same rules for tag arrangement. A single style sheet applied to one DTDcan transform the entire class of documents into web-based documents with the same look-and-feel.

Enhanced Search Performance: Context for searching is provided by the XML tags. A computer can extract text delimited by particular tags. (For instance, find all guidelines where “aspirin” occurs in the Recommendations section, rather then where “aspirin” occurs anywhere in the document.)

Application-independent Persistent Format: XML is application-independent. Therefore the same XML-encoded data can be manipulated with many different applications and application versions.

## in HTML

**in HTML**

**in XML**

**in Template**

**Transform**

**Transform**

**<cpg>**
**<head>**
**     ****<specialty>**Family Practice/Internal Medicine**</specialty>**
**     ****<number>**cpgdemo**</number>**
**     ****<document.title>**FAKE DEMO GUIDELINE**</document.title>**
**     ****<effective.date>**9-94; updated 9-96, no changes made**</effective.date>**
**     ****<review.date>**9-98**</review.date>**
**     ****<scope>**KPSC**</scope>**
**     ****<format>**kpscal_cpg_v1.0**</format>**
**     ****<provider.education>**Not available**</provider.education>**
**     ****<member.education>**MH-0110e; MH-0110s**</member.education>**
**     ****<methodology>**Global Subjective Judgment**</methodology>**
**     ****<contact.person>**Dr. Foobar, MD**</contact.person>**
**</head>**
**<body>**
**<background>**
**     **<para>Here is background material on this guideline... </para>
**</background>**
**<recommendations>**
**     ****<subsection>**Detection and Screening**</subsection>**
-      <list>
-           <item>Recommendations may reference the <link target="#table1”>
-                table</link>below...</item>
-           <item>Recommendations can refer to their sources (see <link
-                target="#ref1”>[1]</link>)...
-                <list><item>A recommendation might reference an image: See <link
-                target="PVR.gif”>Pressure-Volume Relationships</link></item>
-                </list></item>
-           <item>Other recommendations...</item>
-      </list>
-      <link name="table1"></link>
-      <table>
-           <title>Classification of High Blood Pressure in Adults <footnote
-           text="This classification scheme is for demo purposes only."></title>
-           <tbody><row><entry><b>Systolic (mm Hg)</b></entry>
-           <entry><b>Diastolic (mm Hg)</b></entry><entry><b>
-           Classification</b></entry></row><row><entry> &lt; 0
-           </entry><entry> &lt; 0 </entry><entry>Too Low </entry> </row>
-           <row><entry> &gt; 300</entry><entry> &gt; 150</entry><entry>Too
-           High</entry></row></tbody>
-      </table>
**</recommendations>**
**<references>**
-      <ref><link name="ref1"></link>Eddy DM. Assessing health practices and
-           designing practice policies: The explicit approach. Philadelphia, PA:
-           American College of Physicians; 1992. </ref>
-      <ref><link name="ref2" target =
-           "http://www.mcis.duke.edu/standards/HL7/committees/sgml/”> HL7
-           SGML/XML Special Interest Group web site</link></ref>
**</references>**
**</body>**
**</cpg>**

**Notes:**
This slide illustrates how we’ve used XML to publish our internal Clinical Practice Guidelines. 
Designing the CPG DTD: Document analysis, discussion with guideline experts, and review of existing standards lead to the creation of a Clinical Practice Guideline DTD. 

Building an authoring template : We take advantage of the user-friendly functionality provided by commercial word-processing programs in order to make it as easy as possible to create new documents or to convert existing documents into the proper format. The authoring template is designed in accordance with the CPG DTD.

Transformation from template into XML : Documents generated from the template are automatically converted into documents that are XML-encoded per the CPG DTD. These then represent the application-independent persistent form of the documents.

Transformation into HTML: XML-encoded documents are automatically converted into HTML documents for display over the web. During the transformation, hypertext links to referenced documents are created; a hypertext outline of each document displaying all sections, subsections, tables, and figures is produced; and a table of contents, a list of all exhibits (tables and figures), and indexes are generated for the entire document collection.

## Outline

**Introduction to XML**
**XML Healthcare Applications**
- Medical Publishing
- Messaging
- Clinical Documents
**Conclusions**

## Messaging

**Messaging**

**Lab Vocabulary**

**Lab Information**
**Model**

**Standard**
**Vocabulary**

**Standard**
**Information**
**Model**

**Standard**
**Vocabulary**

**Standard**
**Information**
**Model**

**Bob’s Vocabulary**

**Bob’s Information**
**Model**

**Standard**
**Vocabulary**

**Standard**
**Information**
**Model**

**Tom’s Vocabulary**

**Tom’s Information**
**Model**

**Standard**
**Transfer Syntax**

**Data Exchange:** The unambiguous standards-based transfer of data between applications.

**Transfer Syntax:** The explicit expression of the sender's semantics in a format that can be understood by the receiver.

**Notes:**
Data exchange for healthcare means the unambiguous standards-based transfer of data between applications. Messaging requires a shared information model and a shared vocabulary. The information model and the vocabulary work together to capture the semantics or meaning of what the sender wants to say. HL7 Version 3 introduces a Reference Information Model. Fields in all HL7 V3 messages  map to this central shared information model, ensuring greater consistency between messages. 

The transfer syntax (a.k.a implementable syntax) is the explicit expression of the sender's semantics in a format that can be understood by the receiver. In HL7, XML represents a transfer syntax.

## History of XML for HL7 messages

**History of XML for HL7 messages**

**1993 CEN Report**
- “Investigation of Syntaxes for Existing Interchange Formats to be used in Healthcare” (ASN.1,ASTM E1238, EDIFACT, EUCLIDES, ODA).
- Based on example scenarios, general message requirements are determined. Each syntax is examined to see which of the general requirements can be fulfilled.
- Metrics include:	Supported Information Structures			Supported Data Types			Encoding			Evolution and Backwards Compatibility			Conformance			Support and Availability
**1997 SGML as a Messaging Syntax**
- Robert Dolin, et al extend the CEN report, using their scenarios and evaluation criteria, to include SGML.
- SGML compares favorably with other syntaxes studied by CEN.
- No syntax explicitly represents all functional requirements.
**1999 HIMSS Demonstration**
- Wes Rishel coordinates a 10-vendor HL7-XML interoperability demo.
- All vendors rated the demo a success.

**Notes:**
In January, 1993, the European Committee for Standardization (CEN) issued a report, "Investigation of Syntaxes for Existing Interchange Formats to be used in Healthcare". Their objective was to "investigate syntaxes for existing interchange formats (IFs) to be used in healthcare and to define a strategy for selecting IFs". The 23 identified formats were prioritized, and those five formats with a priority one (ASN.1, ASTM E1238, EDIFACT, EUCLIDES, and ODA) were evaluated in detail.

The methods used by CEN in the formation of healthcare messages include: (1) Scope out the problem domain; (2) Determine parties and communication roles; (3) Scenario development; (4) Determine services associated with each communication role; (5) Develop a Domain Information Model (DIM) with specification of attributes and operations; (6) Formulate General Message Descriptions (GMDs). The GMDs are independent of, and set the functional requirements for the interchange format. The ability of the various syntaxes to support the functional requirements of the GMDs are then evaluated. Interchange formats are evaluated along six axes: (1) Support of Information Structures; (2) Support of Datatypes, including numbers, text strings, images, and sounds; (3) Encoding, i.e., the transformation to and from a transfer syntax; (4) Evolution and Backwards Compatibility; (5) Conformance and Certification; (6) Support and Availability. Each of these six axes are further broken down into Evaluation Criteria.

Members of the HL7 SGML/XML SIG sought to study the use of SGML as a message interchange format, following the methods, scenarios, and reporting format of CEN, enabling a direct comparison of SGML with ASN.1, ASTM E1238, EDIFACT, EUCLIDES, and ODA. Findings were that SGML compares favorably with other syntaxes studied by CEN. No syntax was able to explicitly represent all functional requirements.

## Messaging - HL7 V2.3 message

**Messaging - HL7 V2.3 message**

- <ORU.R01>
- <MSH>
-   <MSH.1>|</MSH.1>
-   <MSH.2>^~\&amp;</MSH.2>
-   <MSH.9><MSH.9.CM.1>ORU</MSH.9.CM.1>
-          <MSH.9.CM.2>R01</MSH.9.CM.2></MSH.9>
- </MSH>
- <OBR>
-   <OBR.2><EI.1>123456789</EI.1></OBR.2>
-   <OBR.4><CE.1>P3-72990</CE.1>
-          <CE.2>Growth hormone measurement</CE.2>
-          <CE.3>SNM3</CE.3></OBR.4>
- </OBR>
- <OBX>
-   <OBX.2>ST</OBX.2>
-   <OBX.3><CE.1>2963-7</CE.1>
-          <CE.2>SOMATOTROPIN:MCNC:PT:SER:QN</CE.2>
-          <CE.3>LN</CE.3></OBX.3>
-   <OBX.5>3.5</OBX.5>
-   <OBX.6><CE.1>ng/mL</CE.1></OBX.6>
-   <OBX.7>0-5</OBX.7>
- </OBX>
- </ORU.R01>

- MSH|^~\&|||||||ORU^R01<cr>
- OBR||123456789||
-    |P3-72990^Growth hormone measurement^SNM3<cr>
- OBX||ST|2963-7^SOMATOTROPIN:MCNC:PT:SER:QN^LN|
-    |3.5|ng/mL|0-5<cr>

**Notes:**
This illustration shows a standard-encoded and XML-encoded HL7 V2.3 ORU results  message.

The most common response to this figure is the apparent increase in message length with XML.

There are many ways to map HL7 into XML syntax. Various metrics can be employed to help determine the optimal XML representation. Some metrics are fairly straightforward to quantify (e.g. message length), while others are more qualitative (e.g. ease of implementation and maintenance, the value to making a message more human-readable).  There is a risk that the easily quantifiable measurements will assume significance out of proportion to the other metrics. All relevant metrics must be factored together in the determination of the optimal XML representation. The optimal XML message representation will be a balance of functional, technical, and practical requirements.

## HL7-XML Messaging: Findings

**HL7-XML Messaging: Findings**

- XML can serve as an implementable syntax for HL7 V2.3 and V3 messages.
- XML messages will be longer then today’s HL7 messages.
- The ability to express an HL7 rule in an XML DTD confers the ability to validate that rule with an XML processor.
- Not all HL7 requirements can be validated by an XML processor. Validation of these HL7 business rules will rely on further message processing by another application.
- Mapping HL7 into XML uncovered areas of ambiguity with the HL7 Standard.
- The optimal message representation is a balance of functional, technical, and practical requirements.

**HL7 conformance**

**HL7 rules that can be validated by an XML processor**

**Notes:**
XML was further tested as a messaging syntax for HL7 Version 3 messages at the HIMSS ‘99 Conference. All vendors rated the demo a success. Additional findings of the participating vendors include:

How easy it was for somebody to come up to speed, particularly for those who implemented their own parsers? Those who downloaded parsers had little trouble. Those who wrote their own spent significantly longer debugging that part of their interfaces.

For V3-XML messages, did size matter? No one had an issue with size. As a demo, there was not the volume of traffic where a size increase would have been noticeable. Within HL7 V2.3, there may be a 2:1 increase in size going from the usual encoding to an XML-based encoding. Because V3 adds additional message features not present in V2.3, the migration from 2.3 to 3 coupled with the introduction of XML syntax may result in a 10:1 or more size increase. This seems to be an issue and will be reevaluated by HL7.

## HL7-XML Messaging: Status

**HL7-XML Messaging: Status**

**Version 2.3**
- XML-ification being prepared as an Informative Document.
- XML style will be similar to that being proposed for Version 3.
**Version 3**
- XML will be used as a transfer syntax.

**Notes:**
An XML-based syntax for HL7 V2.3 messages is being developed as an Informative Document. (An HL7 Informative Document does not affect the Standard, but is balloted.) While HL7 V2.3 does have a default syntax, the HL7 Standard is syntax independent. The purpose of the Informative Document is to describe the HL7 V2.3 XML representation in detail. The XML style being developed for V2.3 is similar to that being proposed for V3.

Based on experience to date, HL7 plans on using XML as a transfer syntax for HL7 V3 messages.

## Outline

**Introduction to XML**
**XML Healthcare Applications**
- Medical Publishing
- Messaging
- Clinical Documents
**Conclusions**

**Notes:**
References - HL7 / XML / Documents
Dolin RH, Alschuler L, Behlen F, Biron PV, Boyer S, Essin D, Harding L, Lincoln T, Mattison JE, Rishel W, Sokolowski R, Spinosa J, Williams JP. HL7 Document Patient Record Architecture: An XML Document Architecture Based on a Shared Information Model. JAMIA Fall Symposium Supplement 1999: (submitted).

.HL7 Document Patient Record Architecture. Draft, Sept, 1998. (www.mcis.duke.edu:80/standards/HL7/committees/sgml/WhitePapers/Prap/)

## Clinical Documents

**Clinical Documents**

**Medical**
**Publishing**

**Clinical Documents**

**Messaging**

**Notes:**
If you consider all the benefits of XML for medical publishing along with the functional requirements required for unambiguous messaging, you are also describing some of the potential benefits of using XML for clinical documents within HL7.

In particular, XML is used in medical publishing to achieve rapid wide-spread deployment, consistency in content and presentation, enhanced search performance, and application-independence. Unambiguous messaging requires that data exchange be based on shared information and vocabulary models. All of these are objectives for clinical documents.

## HL7 Document Patient Record Architecture

**HL7 Document Patient Record Architecture**

**Healthcare is document-centric**
- Considerable clinical content is contained in narrative notes, which are created on systems of widely varying characteristics.
- It is difficult to store and/or exchange documents with retention of computer-processable semantics over both time and distance.
- Capturing some of the semantics of clinical narratives for computer processing is better then capturing none; capturing more of the semantics is better then capturing less; and if you know something and don’t record it, you’ve lost it.
- The HL7 Document Patient Record Architecture proposes a common data architecture that can accommodate a diverse set of records and requirements.

**Notes:**
The need for a patient record architecture stems from the desire to unlock the considerable clinical content currently stored in free text clinical notes, and to enable pooling of content from documents created on systems of widely varying characteristics. Given the variability in clinical notes, including structure, underlying information models, degree of semantic encoding, use of standard healthcare terminologies, platform- and vendor-specific features, it is currently difficult to store and/or exchange documents with retention of computer-processable semantics over both time and distance. The HL7 Document Patient Record Architecture proposes that what is needed is a common data architecture that can accommodate a diverse set of records and requirements. The PRA strives to be such an architecture.

## HL7 Document Patient Record Architecture

**XML provides a SYNTAX for HL7 SEMANTICS**
- XML tags have no predefined semantic meaning.
- Interoperability requires a shared semantics.
- Document processing is determined by an application that understands the meaning of the tags.
- HL7 PRA XML tags derive their meaning from the HL7 Reference Information Model (as do all HL7 V3 messages)
- HL7 PRA Documents provide for a standardized way of referencing external vocabularies.

**HL7 Document Patient Record Architecture**

**Notes:**
As with messages, unambiguous exchange of documents  requires a shared information model and a shared vocabulary. The DTDs that together form the PRA will be harmonized with the evolving HL7 Reference Information Model (RIM). The objective for the RIM is to serve as the central schema from which all HL7 messages are derived. Fields in all HL7 messages will map to the RIM. Likewise, components in PRA DTDs will map to the RIM. 

A shared information model is central to PRA. HL7 messages will also be based on the RIM, enabling the interplay of PRA documents and HL7 messages. Such interplay may include deriving an order message from the Plan section of a document, importing a lab report into the Results section of a document, and the ability to send documents as messages and communicate with systems designed for message storage, indexing, and retrieval.

## What’s in a <name>?

- <PatientInfo>
-      <**Name**>Henry Levin, the 7th</Name>
-      <**MRN**>123456789</MRN>
-      <**DOB**>May 13, 1900</DOB>
- </PatientInfo>
- <ClinicalData>History of smoking for 40 years. </ClinicalData>
- <**Procedure**>Chest X-ray</Procedure>
- <Findings>Comparison is made with a chest-x-ray ...
- </Findings>
- <**Assessment**>RLL nodule, suggestive of malignancy.
-      Compared with a prior CXR from 6 months ago, nodule
-      size has increased.
- </Assessment>
- <Recommendations>I notified the ordering physician of
-      this finding by phone.
- </Recommendations>
- </RadiologyReport>

**What’s in a <name>?**

- <radiology.report>
- <header>
-      <**name**>Henry Levin, the 7th</name>
-      <**dob**>19000513</dob>
-      <**patient.id**>123456789</patient.id>
- </header>
- <body>
-      <**section title = “Procedure”**>
-           <healthcare.code identifier="P5-20100"
-             name.of.coding.system="SNM3">
-             Chest X-Ray</healthcare.code>
-      </section>
-      <**section title = “Impressions”**>
-           <user.text>RLL nodule, suggestive of
-             malignancy.</user.text>
-      </section>
- ...
- </body>
- </radiology.report>

**Notes:**
This figure further illustrates the difference between syntax and semantics. The two documents contain the same clinical information, but the tag names are different. If everyone uses XML to represent documents but there is no central model upon which these tag names can be interpreted, then many of the benefits of XML will not be realized.

The PRA provides a mechanism for mapping a local DTD into a PRA DTD.

## HL7 PRA is harmonized with the RIM

**HL7 PRA is harmonized with the RIM**

- HL7
- Reference
- Information
- Model

- <!ELEMENT RadiologyReport (PatientInfo, ...)>
- <!ELEMENT PatientInfo (Name, MRN, DOB, SEX)>
**<!ELEMENT DOB %Time_stamp;>**
**<!ATTLIST DOB**
**    ****HL7.datatype CDATA #FIXED "TS"**
**    ****RIM.attribute CDATA #FIXED "Person.birth_dttm">**
**<!ELEMENT SEX EMPTY>**
**<!ATTLIST SEX**
**    ****HL7.datatype CDATA #FIXED "ID”**
**    ****RIM.attribute CDATA #FIXED "Person.gender_cd"**
**    ****domain CDATA #FIXED "HL70001"**
**    ****value %sex.table; #REQUIRED >**
- ...

- <RadiologyReport>
- <PatientInfo>
-      <Name>Henry Levin, the 7th</Name>
**     ****<DOB>19000513</DOB>**
**     ****<SEX value=“Male”/>**
- </PatientInfo>
- <Impressions>
-      RLL <healthcare.code identifier=“M-03010”
-      coding.system=“SNM3”> nodule
-      </healthcare.code>, suggestive of malignancy... </Impressions>
- </RadiologyReport>

**Notes:**
One of the foundational principles of PRA is that it be harmonized with the RIM. The requirements for the semantic content of PRA are derived from numerous sources. The harmonization process is an iterative cycle of feeding identified requirements into the RIM, ensuring that the RIM reflects these requirements, and mapping PRA components to the RIM. In the illustration above, the fixed XML attribute "RIM.attribute" expresses the mapping from an XML element to a corresponding RIM attribute. The fixed XML attribute "HL7.datatype" expresses the HL7 data type of the XML element. (HL7 data types are defined as entities within the DTD and referenced by other XML elements.)

## HL7 PRA references standard terminologies

**HL7 PRA references standard terminologies**

- SNOMED
- Terminology
- Model

- <!ELEMENT RadiologyReport (PatientInfo, ...)>
- <!ELEMENT PatientInfo (Name, MRN, DOB, SEX)>
- <!ELEMENT DOB %Time_stamp;>
- <!ATTLIST DOB
-     HL7.datatype CDATA #FIXED "TS"
-     RIM.attribute CDATA #FIXED "Person.birth_dttm">
- <!ELEMENT SEX EMPTY>
- <!ATTLIST SEX
-     HL7.datatype CDATA #FIXED "ID”
-     RIM.attribute CDATA #FIXED "Person.gender_cd"
-     domain CDATA #FIXED "HL70001"
-     value %sex.table; #REQUIRED >
- ...

- <RadiologyReport>
- <PatientInfo>
-      <Name>Henry Levin, the 7th</Name>
-      <DOB>19000513</DOB>
-      <SEX value=“Male”/>
- </PatientInfo>
- <Impressions>
-      RLL **<healthcare.code identifier=“M-03010”**
**     ****coding.system=“SNM3”> **nodule
-      **</healthcare.code>, **suggestive of malignancy... </Impressions>
- </RadiologyReport>

**Notes:**
Every PRA Document can contain coded entries from standard healthcare terminologies. These are expressed with the XML element "healthcare.code" which is patterned after the HL7 coded element data type.

## HL7 Document Patient Record “Architecture”

**HL7 Document Patient Record “Architecture”**

**Generic PRA LevelOne DTD**
**Generic PRA LevelTwo DTD**
- DTD LevelTwo Endocrinology
- DTD LevelTwo Endocrinology Diabetes
- 	DTD LevelThree Endocrinology Diabetes
- DTD LevelThree Endocrinology
- 	DTD LevelThree Endocrinology Diabetes
- DTD LevelTwo FamilyMedicine
- DTD LevelTwo FamilyMedicine Diabetes
- DTD LevelTwo Diabetes
- DTD LevelTwo Endocrinology Diabetes
- 	DTD LevelThree Endocrinology Diabetes
- DTD LevelTwo FamilyMedicine Diabetes
- DTD LevelThree Diabetes
- 	DTD LevelThree Endocrinology Diabetes
**Generic PRA LevelThree DTD**
- DTD LevelThree Endocrinology
- 	DTD LevelThree Endocrinology Diabetes
- DTD LevelThree Diabetes
- 	DTD LevelThree Endocrinology Diabetes

**Notes:**
The PRA is envisioned as a hierarchically organized set of document schemas (or DTDs) that, in aggregate, define the semantics and structural constraints necessary for the exchange of clinical documents. The proposal defines a multi-level document architecture where each level is derived from a more basic level, with level one being the most basic. Higher levels enable the computer-processable expression of richer shared semantics. We anticipate domain-specific specializations branching out from each level (such as an Endocrinology DTD branching out from the generic PRA level two DTD).
The PRA levels can be thought of as levels of  conformance. Regulatory agencies can require a particular PRA level for reporting. Institutions with different abilities to generate and process XML-encoded documents, can claim conformance with a particular PRA level. This should enable more institutions to utilize PRA while maximizing the amount of computer-processable and shared semantics embedded in an exchanged document.

Level one (a.k.a. "Coded Header") specifies encoding of the clinical document header, which contains information that uniquely identifies and classifies the document; attestation, event, patient, and practitioner details; and common structural elements for a document body. Level two (a.k.a. "Coded Context") structures the document body into coded sections. The vision for level two is that it will provide the semantics to encode the context under which clinical events occur. Level three (a.k.a. "Coded Content") is envisioned to encode a document sufficient to meet the processing needs of a fully electronic health record. 

Every level can contain coded entries from standard healthcare terminologies. These are expressed with the XML element "healthcare.code" which is patterned after the HL7 coded element data type.

## Mapping a local DTD into PRA

- <PatientInfo>
**     ****<Name>Henry Levin, the 7th</Name>**
**     ****<MRN>123456789</MRN>**
**     ****<DOB>May 13, 1900</DOB>**
**     ****<SEX>M</SEX>**
- </PatientInfo>
- <Procedure>
-      Chest X-ray
- </Procedure>
- <Impressions>
**     ****RLL <healthcare.code **
**     ****identifier=“M-03010”**
**     ****coding.system=“SNM3”> **
**     ****nodule </healthcare.code>, **
**     ****suggestive of malignancy... **
- </Impressions>
- </RadiologyReport>

**Mapping a local DTD into PRA**

- <radiology.report>
- <header>
**     ****<name>Henry Levin, the 7th</name>**
**     ****<dob>19000513</dob>**
**     ****<sex value=“Male”/>**
**     ****<patient.id>123456789</patient.id>**
- </header>
- <body>
-      <section title=”Procedure">
-           Chest X-ray
-      </section>
-      <section title=”Assessment">
-           **<user.text>RLL nodule, suggestive of **
**            ****malignancy.</user.text>**
**          ****<concept ID=“1” code=“M03010”**
**            ****text=“nodule” source=“SNM3”/>**
**          ****<concept ID=“2” code=“M80001”**
**            ****text=“malignancy” source=“SNM3”/>**
**          ****<relationship ID1=“1” ID2=”2”**
**            ****code=“GC022” text=“suggests” **
**            ****source=“SNM3”/>**
-      </section>
- </body>
- </radiology.report>

**Notes:**
A distinction can be made between an exchange DTD and an authoring DTD. The PRA proposes an architecture for the exchange of clinical documents. An HL7 PRA document may be originally authored data (meaning that an institution adopts a PRA DTD as their internal DTD), or may be a transformation from original data (meaning that an institution may have their own internal DTD, and map into the PRA for purposes of exchange). In the latter case, the exchanged document is not necessarily the same as the originally attested document (although a copy of the original document can be embedded within a generated PRA document).

Given this distinction, and because many institutions have or are actively developing their own internal document representations, there is a need to map or transform from an institution's authoring DTD into a PRA exchange DTD. While the discussion here focuses on mapping from one DTD to another, the issues are similar to those that arise in the more general sense of mapping from one information model to another. Some of these mapping issues are illustrated by the two documents shown above and include differences in element sequence, required elements, data type formats, granularity, and enumerated value lists. 

Perhaps the most challenging mapping problem occurs when the source’s information model of the real world differs from the information model underlying PRA. It may be that mapping to higher levels of PRA will depend on the extent to which the sender's information model can map to the RIM, or on the extent by which the author DTD can map to a PRA DTD, thus ultimately to the RIM. 

## The PRA Editorial Group

**The PRA Editorial Group**

- Liora Alschuler, Chair
- Dean Bidgood
- Paul V. Biron
- Fred Behlen
- Sandy Boyer
- Michal Coleman
- Don Connelly
- Robert H. Dolin

- Joachim W. Dudeck
- Dan Essin
- Lloyd Harding
- Tom Lincoln
- John E. Mattison
- Angelo Rossi Mori
- Rachael Sokolowski
- John Spinosa
- Jason P. Williams

**Notes:**
The PRA Editorial Group is the team that put together the proposed HL7 Document Patient Record Architecture.

## Outline

**Introduction to XML**
**XML Healthcare Applications**
- Medical Publishing
- Messaging
- Clinical Documents
**Conclusions**

## Conclusions

- XML is a sound technology, valuable for exchange of messages and documents.
- XML is an application-independent format valuable for the persistent storage of documents.
- XML documents are easily web-deployed.
- Rapid industry growth of XML tools will facilitate HL7 implementations.
- Rapid growth of interest in XML helps attract attention to the need for shared semantics.
- XML can provide a standardized syntax for the expression of shared semantics.
- XML validation represents an HL7 conformance metric.

**XML Technology in HL7’s Patient Medical Record Information Exchanges**

## What role should the government play?

- Medical content is complex, and no organization has yet produced a complete or widely accepted model. Timelines for national PMRI-Exchange standards should balance the need for implementation with the need for deepening our shared understanding of clinical information. This balance should ensure that quality standards can continue to evolve, and not be hampered by early rollout of awkward standards. The architectural approach put forth in the HL7 PRA proposal is one way of achieving this balance.
- There are limitations to mapping between different information models. If Standards Development Organizations (SDOs) independently create DTDs, information exchange will be limited by the extent to which those DTDs conform to a shared model. If all groups creating DTDs were encouraged to derive them from PRA, then many barriers to effective information exchange would be minimized. This holds for groups within HL7, SDOs, professional and regulatory groups, providers and vendors.
- Grants for SDOs (e.g. HL7, NIHI) and grants for large scale validation of clinical data models will accelerate standards development.

**XML Technology in HL7’s Patient Medical Record Information Exchanges**