1. XML for HL7 v.2 Messages: A Bridge to Clinical Documents
PHIN Conference
Atlanta, August 2007
Nancy McQuillen, M.S., Data Architect
California Department of Public Health
HDF and resulting HL7 Implementation Guide
An alternate name for our presentation today might be “Toward a fully specified HL7 implementation guide for exchanging Public Health case reports”, as most of the analysis steps and resulting artifacts are those that would be produced if you applied the HL7 Development Framework (HDF) methodology.
Presenter
Nancy McQuillen will be the speaker today, but Jason Siegel of Atlas Dev. Corp. is the co-author, and has collaborated on every aspect of this material, and is especially expert in mapping to the HL7 RIM (this comment via Nancy.)
9/26/ PHIN 2006

2. Syntax (XML) as a Bridge to Enlightenment?
-- Well, maybe not; but public health workers read documents more easily than HL7 messages.
via XML ->
Dimensions are relative to the “Public Health system”.
The “IN” and “ACROSS” dimensions are most “document-like”.
E.g. “IN” – morbidity reports authenticated by clinicians.
E.g. “ACROSS” – investigation reports (case history reports) authenticated by a local case worker.
The “UP” case notifications are most like the CDC and HL7 case notification reports.
But there are still differences between the federal requirements and the in-State requirements. Hopefully some day they will converge (and we can utilize the same implementation guides.)
PHIN 2007
9/26/ PHIN 2006

3. What’s wrong with these statements?
Interface developers:
”We are planning to use either HL7 (version 2) or XML”.
Standards watchers:
”HL7 is introducing XML-based messaging starting with their latest release - version 3”.
Dimensions are relative to the “Public Health system”.
The “IN” and “ACROSS” dimensions are most “document-like”.
E.g. “IN” – morbidity reports authenticated by clinicians.
E.g. “ACROSS” – investigation reports (case history reports) authenticated by a local case worker.
The “UP” case notifications are most like the CDC and HL7 case notification reports.
But there are still differences between the federal requirements and the in-State requirements. Hopefully some day they will converge (and we can utilize the same implementation guides.)
PHIN 2007
9/26/ PHIN 2006

4. Presentation Goals
Raise Awareness – of HL7’s XML syntax option for version 2 messages, as a potential bridge to forms, documents, and XML-aware technologies (web-based data exchange).
Describe “Use Cases” – for XML in relation to forms and documents.
Show some steps (and tools) – for defining HL7 XML messages, and presenting them as forms or clinical documents.
We’re going to quickly summarize topics 1, 2, and 3 – i.e. our data exchange needs, progressing from general interactions to detailed element lists – focusing on the methodology vs. the details, in the interest of time.
We would then like to focus a bit on how we mapped the requirements to CDA, and the advantages of CDA. Time remaining, we would also like to hit some of the important points regarding contrasts between CDA, v.2, and v3, particularly in light of CDC’s recent decision to recommend 2.5 instead of 3.0 for PHIN case messaging in the near term.
Note that topics 1, 2, and 3 are identical regardless of which HL7 version is used for implementation.
PHIN 2007
9/26/ PHIN 2006

5. Traditional ER7 Syntax vs. XML Syntax
HL7 is primarily a semantic standard (defining data content of messages). The semantics can be cast into multiple syntaxes.
In addition to traditional encoding rules (ER7) for HL7 v.2.x, HL7 also publishes a syntax guide (an “Implementable Technology Specification (ITS)”) for the XML representation of HL7 v.2.3.1, v.2.4, v.2.5 messages (and beyond).
HL7 Standard
(Syntax specification #2)
(Syntax specification #1)
We’re going to quickly summarize topics 1, 2, and 3 – i.e. our data exchange needs, progressing from general interactions to detailed element lists – focusing on the methodology vs. the details, in the interest of time.
We would then like to focus a bit on how we mapped the requirements to CDA, and the advantages of CDA. Time remaining, we would also like to hit some of the important points regarding contrasts between CDA, v.2, and v3, particularly in light of CDC’s recent decision to recommend 2.5 instead of 3.0 for PHIN case messaging in the near term.
Note that topics 1, 2, and 3 are identical regardless of which HL7 version is used for implementation.
Also called:
Bar syntax
Pipe-and-hat^
EDI-style
Traditional
ER7
XML
PHIN 2007
9/26/ PHIN 2006

6. ER7 Syntax vs. XML Syntax ER7: XML: (COMPACT!) (REALLY LONG!)
The HL7 XML schema structure follows the simple structure of the HL7 v.2 standard:
<Message>
<Segments>
<Fields>
<Components>
We’re going to quickly summarize topics 1, 2, and 3 – i.e. our data exchange needs, progressing from general interactions to detailed element lists – focusing on the methodology vs. the details, in the interest of time.
We would then like to focus a bit on how we mapped the requirements to CDA, and the advantages of CDA. Time remaining, we would also like to hit some of the important points regarding contrasts between CDA, v.2, and v3, particularly in light of CDC’s recent decision to recommend 2.5 instead of 3.0 for PHIN case messaging in the near term.
Note that topics 1, 2, and 3 are identical regardless of which HL7 version is used for implementation.
This translation
example provided by:
PHIN 2007
9/26/ PHIN 2006

7. A Closer Look at One HL7 XML Segment
PID Segment Snippet:
<Segment> (PID)
<Field> (PID.5)
<Datatype> (XPN)
<Component>
(Surname)
(Given name)
We’re going to quickly summarize topics 1, 2, and 3 – i.e. our data exchange needs, progressing from general interactions to detailed element lists – focusing on the methodology vs. the details, in the interest of time.
We would then like to focus a bit on how we mapped the requirements to CDA, and the advantages of CDA. Time remaining, we would also like to hit some of the important points regarding contrasts between CDA, v.2, and v3, particularly in light of CDC’s recent decision to recommend 2.5 instead of 3.0 for PHIN case messaging in the near term.
Note that topics 1, 2, and 3 are identical regardless of which HL7 version is used for implementation.
Complex HL7 datatypes such as Extended Person Name (XPN) have component parts (e.g. XPN.1 and XPN.2) expressed as subordinate XML elements.
PHIN 2007
9/26/ PHIN 2006

8. “Use Cases” for HL7 v.2 XML
Useful as an adjunct (not a replacement) for traditional ER7 syntax, if you need to:
Convert messages - to other versions of HL7 (or to custom XML formats) using standard XML-aware tools, such as integration brokers and graphical mapping tools.
Present and/or “persist” message data – on forms and documents, using XML- aware standards (e.g. XForms) and technologies (e.g. Adobe’s XML architecture for .pdf fillable forms).
We’re going to quickly summarize topics 1, 2, and 3 – i.e. our data exchange needs, progressing from general interactions to detailed element lists – focusing on the methodology vs. the details, in the interest of time.
We would then like to focus a bit on how we mapped the requirements to CDA, and the advantages of CDA. Time remaining, we would also like to hit some of the important points regarding contrasts between CDA, v.2, and v3, particularly in light of CDC’s recent decision to recommend 2.5 instead of 3.0 for PHIN case messaging in the near term.
Note that topics 1, 2, and 3 are identical regardless of which HL7 version is used for implementation.
PHIN 2007
9/26/ PHIN 2006

9. Confidential Morbidity Report (CMR) - XML-Based Adobe
Confidential Morbidity Report (CMR) - XML-Based Adobe .pdf Fillable Form Example
We’re going to quickly summarize topics 1, 2, and 3 – i.e. our data exchange needs, progressing from general interactions to detailed element lists – focusing on the methodology vs. the details, in the interest of time.
We would then like to focus a bit on how we mapped the requirements to CDA, and the advantages of CDA. Time remaining, we would also like to hit some of the important points regarding contrasts between CDA, v.2, and v3, particularly in light of CDC’s recent decision to recommend 2.5 instead of 3.0 for PHIN case messaging in the near term.
Note that topics 1, 2, and 3 are identical regardless of which HL7 version is used for implementation.
PHIN 2007
9/26/ PHIN 2006

10. Dream scenario, or someday soon?
Example Data Flow: Clinical <-> Public Health Using Both Syntaxes (and Multiple HL7 Versions)
Dream scenario, or someday soon?
Rendered, Faxed
CMRs
2007?
CMR Form
Flat CMR
Integration
Broker
(Adobe Prof. 8)
HL7 XML CMR
2.4 ER7 CMR
2008?
2.5 ER7 CMR
CDA CMRs,
Case Extracts
EHR Case
Extracts
(CDA)
EHR Case
Data Requests
(CDA)
We’re going to quickly summarize topics 1, 2, and 3 – i.e. our data exchange needs, progressing from general interactions to detailed element lists – focusing on the methodology vs. the details, in the interest of time.
We would then like to focus a bit on how we mapped the requirements to CDA, and the advantages of CDA. Time remaining, we would also like to hit some of the important points regarding contrasts between CDA, v.2, and v3, particularly in light of CDC’s recent decision to recommend 2.5 instead of 3.0 for PHIN case messaging in the near term.
Note that topics 1, 2, and 3 are identical regardless of which HL7 version is used for implementation.
2009?
Electronic Health
Records Systems
Public Health Jurisdictions
PHIN 2007
9/26/ PHIN 2006

11. Steps to (Truly) Interoperable Messages
Tools Used
(examples):
XML (the general standard: an open slate)
XML Tag Language (Semantics)
Constrain!
Text/XML editors
HL7 XML (specific schema applied)
XML Structure (Elements/Attributes)
XMLSpy
Constrain!
Profiled HL7 XML Message
HL7 Segments, Fields, Repeats
HL7 MWB
Constrain!
PHIN Compliant Profiled:
Vocabulary and OIDs
Datatype (parts)
Rules and constraints
XSLT
Constrain!
We’re going to quickly summarize topics 1, 2, and 3 – i.e. our data exchange needs, progressing from general interactions to detailed element lists – focusing on the methodology vs. the details, in the interest of time.
We would then like to focus a bit on how we mapped the requirements to CDA, and the advantages of CDA. Time remaining, we would also like to hit some of the important points regarding contrasts between CDA, v.2, and v3, particularly in light of CDC’s recent decision to recommend 2.5 instead of 3.0 for PHIN case messaging in the near term.
Note that topics 1, 2, and 3 are identical regardless of which HL7 version is used for implementation.
Schematron
Sample Messages
Message Validators
Validate!
SUCCESS!
PHIN 2007
9/26/ PHIN 2006

12. Steps to Implement an HL7 v.2.5 XML Message Behind an Adobe .pdf Form
Step/Task
Tool Used
Discover (reverse engineer) PHIN 2.5 ORU_RO1 message structure
HL7 Messaging Workbench (MWB)
A) Adapt (profile) the message as a CMR; and B) generate XML schema
Bind the XML schema to data fields of a fillable CMR .pdf form
Adobe LiveCycle Designer
(Adobe Acrobat 8 Professional)
Create an XSLT transformation to add PHIN codes, OIDs, final details
Altova MapForce
Attach the auto-generated XSLT transform to outbound .pdf CMR form
Validate the resulting PHIN-adapted CMR against profiled HL7 ORU_RO1
Altova XMLSpy
We’re going to quickly summarize topics 1, 2, and 3 – i.e. our data exchange needs, progressing from general interactions to detailed element lists – focusing on the methodology vs. the details, in the interest of time.
We would then like to focus a bit on how we mapped the requirements to CDA, and the advantages of CDA. Time remaining, we would also like to hit some of the important points regarding contrasts between CDA, v.2, and v3, particularly in light of CDC’s recent decision to recommend 2.5 instead of 3.0 for PHIN case messaging in the near term.
Note that topics 1, 2, and 3 are identical regardless of which HL7 version is used for implementation.
PHIN 2007
9/26/ PHIN 2006

13. Step 1: Messaging Workbench - Parse structure of sample (CDC case notification) message
We’re going to quickly summarize topics 1, 2, and 3 – i.e. our data exchange needs, progressing from general interactions to detailed element lists – focusing on the methodology vs. the details, in the interest of time.
We would then like to focus a bit on how we mapped the requirements to CDA, and the advantages of CDA. Time remaining, we would also like to hit some of the important points regarding contrasts between CDA, v.2, and v3, particularly in light of CDC’s recent decision to recommend 2.5 instead of 3.0 for PHIN case messaging in the near term.
Note that topics 1, 2, and 3 are identical regardless of which HL7 version is used for implementation.
PHIN 2007
9/26/ PHIN 2006

14. Step 2a: Messaging Workbench - Profile the CMR (Select segments, fields, etc.)
We’re going to quickly summarize topics 1, 2, and 3 – i.e. our data exchange needs, progressing from general interactions to detailed element lists – focusing on the methodology vs. the details, in the interest of time.
We would then like to focus a bit on how we mapped the requirements to CDA, and the advantages of CDA. Time remaining, we would also like to hit some of the important points regarding contrasts between CDA, v.2, and v3, particularly in light of CDC’s recent decision to recommend 2.5 instead of 3.0 for PHIN case messaging in the near term.
Note that topics 1, 2, and 3 are identical regardless of which HL7 version is used for implementation.
PHIN 2007
9/26/ PHIN 2006

15. Step 2b: Messaging Workbench - (XML schema generated for the profiled CMR)
Hint:
Schema is multi-page and organized from “bottom up” –
progressing from general (whole ORU_R01) to specifics (segments and datatypes).
We’re going to quickly summarize topics 1, 2, and 3 – i.e. our data exchange needs, progressing from general interactions to detailed element lists – focusing on the methodology vs. the details, in the interest of time.
We would then like to focus a bit on how we mapped the requirements to CDA, and the advantages of CDA. Time remaining, we would also like to hit some of the important points regarding contrasts between CDA, v.2, and v3, particularly in light of CDC’s recent decision to recommend 2.5 instead of 3.0 for PHIN case messaging in the near term.
Note that topics 1, 2, and 3 are identical regardless of which HL7 version is used for implementation.
PHIN 2007
9/26/ PHIN 2006

16. Step 3: Adobe LiveCycle Designer – Bind the XML schema to data fields of fillable form
We’re going to quickly summarize topics 1, 2, and 3 – i.e. our data exchange needs, progressing from general interactions to detailed element lists – focusing on the methodology vs. the details, in the interest of time.
We would then like to focus a bit on how we mapped the requirements to CDA, and the advantages of CDA. Time remaining, we would also like to hit some of the important points regarding contrasts between CDA, v.2, and v3, particularly in light of CDC’s recent decision to recommend 2.5 instead of 3.0 for PHIN case messaging in the near term.
Note that topics 1, 2, and 3 are identical regardless of which HL7 version is used for implementation.
e.g. Patient First Name (on form) is bound to PID.XPN.2 (in the attached XML schema).
PHIN 2007
9/26/ PHIN 2006

17. Step 4: Altova Mapforce Add PHIN Codes, OIDs, Rules, via XSLT
We’re going to quickly summarize topics 1, 2, and 3 – i.e. our data exchange needs, progressing from general interactions to detailed element lists – focusing on the methodology vs. the details, in the interest of time.
We would then like to focus a bit on how we mapped the requirements to CDA, and the advantages of CDA. Time remaining, we would also like to hit some of the important points regarding contrasts between CDA, v.2, and v3, particularly in light of CDC’s recent decision to recommend 2.5 instead of 3.0 for PHIN case messaging in the near term.
Note that topics 1, 2, and 3 are identical regardless of which HL7 version is used for implementation.
PHIN 2007
9/26/ PHIN 2006

18. Step 5: Adobe LiveCycle Designer: Attach the XSLT to “Transform Outgoing Data”
Insert snapshot:
We’re going to quickly summarize topics 1, 2, and 3 – i.e. our data exchange needs, progressing from general interactions to detailed element lists – focusing on the methodology vs. the details, in the interest of time.
We would then like to focus a bit on how we mapped the requirements to CDA, and the advantages of CDA. Time remaining, we would also like to hit some of the important points regarding contrasts between CDA, v.2, and v3, particularly in light of CDC’s recent decision to recommend 2.5 instead of 3.0 for PHIN case messaging in the near term.
Note that topics 1, 2, and 3 are identical regardless of which HL7 version is used for implementation.
PHIN 2007
9/26/ PHIN 2006

19. Step 6: XMLSpy (or Other Validators) View XML generated via Form Entry (+ XSLT)
We’re going to quickly summarize topics 1, 2, and 3 – i.e. our data exchange needs, progressing from general interactions to detailed element lists – focusing on the methodology vs. the details, in the interest of time.
We would then like to focus a bit on how we mapped the requirements to CDA, and the advantages of CDA. Time remaining, we would also like to hit some of the important points regarding contrasts between CDA, v.2, and v3, particularly in light of CDC’s recent decision to recommend 2.5 instead of 3.0 for PHIN case messaging in the near term.
Note that topics 1, 2, and 3 are identical regardless of which HL7 version is used for implementation.
PHIN 2007
9/26/ PHIN 2006

20. Binding to an HL7 CDA Document
An HL7 Clinical Document is an XML document!
Representing a human-readable document
A CDA message is composed of two parts:
A header and a body
Designed for communication between two systems
A valid variant of HL7 v3 -
based on the HL7 Reference Information Model (RIM); CDA is an HL7 v3 standard
PHIN 2007
9/26/ PHIN 2006

21. Structure of a CDA Document (an XML Instance)
<ClinicalDocument >
<title>Confidential Morbidity Report</title>
<effectiveTime value=" "/>
<author> </author>
<recordTarget>
<patient> </patient>
</recordTarget>
<component>
<structuredBody>
<section>
<code code=" " ….. codeSystemName="SNOMED CT"/>
<title>Established diagnosis</title>
…..
<entry>
<observation classCode="COND" moodCode="EVN"> .....
<value ... code=" " ... displayName="Botulism"> ... </value>
</observation>
</entry>
</section>
</component>
</structuredBody>
</ClinicalDocument>
Header
Body
Clinical
Statement(s)
The red areas indicate two important Acts (the big long red boxes) within the ClinicalDocument RMIM:
The “ClinicalDocument” in the CDA header, and
The “ClinicalStatement” (choice box of potential “entries”) in the CDA body
PHIN 2007
9/26/ PHIN 2006

22. Example: Mapping HL7 2.5 Segments to an HL7 CDA Message Schema
We’re going to quickly summarize topics 1, 2, and 3 – i.e. our data exchange needs, progressing from general interactions to detailed element lists – focusing on the methodology vs. the details, in the interest of time.
We would then like to focus a bit on how we mapped the requirements to CDA, and the advantages of CDA. Time remaining, we would also like to hit some of the important points regarding contrasts between CDA, v.2, and v3, particularly in light of CDC’s recent decision to recommend 2.5 instead of 3.0 for PHIN case messaging in the near term.
Note that topics 1, 2, and 3 are identical regardless of which HL7 version is used for implementation.
PHIN 2007
9/26/ PHIN 2006

23. Conclusions, Hypotheses
HL7 XML Syntax for v.2 Messages is Useful
- to facilitate message conversions (e.g. v2 to HL7 v3 Clinical Document Architecture (CDA)), and to facilitate integration with other XML-aware forms and document architectures (e.g. XForms and Adobe .pdf forms).
Tools for manipulating XML and HL7 XML schemas are emerging
- and can be used to help bridge messages with documents, enabling public health professionals to visualize message content, and to participate in PHIN-compliant form development and vocabulary review. =
We’re going to quickly summarize topics 1, 2, and 3 – i.e. our data exchange needs, progressing from general interactions to detailed element lists – focusing on the methodology vs. the details, in the interest of time.
We would then like to focus a bit on how we mapped the requirements to CDA, and the advantages of CDA. Time remaining, we would also like to hit some of the important points regarding contrasts between CDA, v.2, and v3, particularly in light of CDC’s recent decision to recommend 2.5 instead of 3.0 for PHIN case messaging in the near term.
Note that topics 1, 2, and 3 are identical regardless of which HL7 version is used for implementation.
PHIN 2007
PHIN 2008 and Beyond
PHIN 2007
9/26/ PHIN 2006

24. Acknowledgements
The author would like to thank the following persons and organizations who have contributed their time and thought leadership to the XML, Adobe, HL7, and PHIN technical content of this presentation.
Dr. Mark Starr, NEDSS Principal Investigator, California Department of Public Health
Linda Sandoval, NEDSS Surveillance Systems Coordinator, California Department of Public Health
Dr. Cecil Lynch, OntoReason LLC and UC Davis Informatics
Kai Heitmann, Paul Biron, and the entire (former) XML Special Interest Group (SIG) of HL7
Bob Dolin, M.D. and Liora Alschuler, Co-chairs of HL7 Structured Documents Technical Committee
CDC NCPHI PHIN technical support team and DISS XForms team
PHIN 2007
9/26/ PHIN 2006