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/06 PHIN 2006

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/06 PHIN 2006

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/06 PHIN 2006

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/06 PHIN 2006

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/06 PHIN 2006

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/06 PHIN 2006

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/06 PHIN 2006

“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/06 PHIN 2006

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/06 PHIN 2006

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/06 PHIN 2006

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/06 PHIN 2006

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/06 PHIN 2006

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/06 PHIN 2006

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/06 PHIN 2006

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/06 PHIN 2006

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/06 PHIN 2006

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/06 PHIN 2006

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/06 PHIN 2006

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/06 PHIN 2006

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/06 PHIN 2006

Structure of a CDA Document (an XML Instance) <ClinicalDocument > <title>Confidential Morbidity Report</title> <effectiveTime value="20050407"/> <author> ..... </author> <recordTarget> <patient> ..... </patient> </recordTarget> <component> <structuredBody> <section> <code code="14657009" ….. codeSystemName="SNOMED CT"/> <title>Established diagnosis</title> ….. <entry> <observation classCode="COND" moodCode="EVN"> ..... <value ... code="398565003" ... 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/06 PHIN 2006

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/06 PHIN 2006

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/06 PHIN 2006

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/06 PHIN 2006