NEDSS Data Architecture Options

Download Report

Transcript NEDSS Data Architecture Options

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
Syntax (XML) as a Bridge to
Enlightenment?
--
Well, maybe not; but public health workers read
documents more easily than HL7 messages.
via XML ->
PHIN 2007
2
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”.
PHIN 2007
3
Presentation Goals
1) 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).
2) Describe “Use Cases” – for XML in relation
to forms and documents.
3) Show some steps (and tools) – for defining
HL7 XML messages, and presenting them as
forms or clinical documents.
PHIN 2007
4
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 #1)
Also called:
•Bar syntax
•Pipe-and-hat^
•EDI-style
•Traditional
PHIN 2007
ER7
(Syntax specification #2)
XML
5
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>
This translation
example provided by:
PHIN 2007
6
A Closer Look at One HL7 XML Segment
PID Segment Snippet:
• <Segment> (PID)
•
•
•
<Field> (PID.5)
<Datatype> (XPN)
<Component>
(Surname)
<Component>
(Given name)
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
7
“Use Cases” for HL7 v.2 XML
Useful as an adjunct (not a replacement) for
traditional ER7 syntax, if you need to:
1) 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.
2) Present and/or “persist” message data –
on forms and documents, using XMLaware standards (e.g. XForms) and
technologies (e.g. Adobe’s XML
architecture for .pdf fillable forms).
PHIN 2007
8
Confidential Morbidity Report (CMR) XML-Based Adobe .pdf Fillable Form Example
PHIN 2007
9
Example Data Flow: Clinical <-> Public Health
Using Both Syntaxes (and Multiple HL7 Versions)
Dream scenario, or someday soon?
Rendered, Faxed
CMRs
Flat CMR
Integration
Broker
2.4 ER7 CMR
2007?
CMR
Form
HL7 XML CMR
(Adobe Prof. 8)
2008?
2.5 ER7 CMR
EHR Case
Extracts
(CDA)
CDA CMRs,
Case Extracts
EHR Case
Data Requests
(CDA)
2009?
Electronic Health
Records Systems
PHIN 2007
Public Health
Jurisdictions
10
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)
Constrain!
XMLSpy
Profiled HL7 XML Message
• HL7 Segments, Fields, Repeats
Constrain!
HL7 MWB
PHIN Compliant Profiled:
Constrain!
• Vocabulary and OIDs
XSLT
• Datatype (parts)
• Rules and constraints
Schematron
Sample Messages
Validate!
PHIN 2007
SUCCESS!
Message
Validators
11
Steps to Implement an HL7 v.2.5 XML
Message Behind an Adobe .pdf Form
Step/Task
Tool Used
1.
Discover (reverse engineer) PHIN 2.5
ORU_RO1 message structure
HL7 Messaging Workbench
(MWB)
2.
A) Adapt (profile) the message as a
CMR; and B) generate XML schema
HL7 Messaging Workbench
(MWB)
3.
Bind the XML schema to data fields of
a fillable CMR .pdf form
Adobe LiveCycle Designer
(Adobe Acrobat 8 Professional)
4.
Create an XSLT transformation to add
PHIN codes, OIDs, final details
Altova MapForce
5.
Attach the auto-generated XSLT
transform to outbound .pdf CMR form
Adobe LiveCycle Designer
(Adobe Acrobat 8 Professional)
6.
Validate the resulting PHIN-adapted
CMR against profiled HL7 ORU_RO1
Altova XMLSpy
PHIN 2007
12
Step 1: Messaging Workbench Parse structure of sample (CDC case notification) message
PHIN 2007
13
Step 2a: Messaging Workbench Profile the CMR (Select segments, fields, etc.)
PHIN 2007
14
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).
PHIN 2007
15
Step 3: Adobe LiveCycle Designer –
Bind the XML schema to data fields of fillable form
e.g. Patient First Name (on form) is bound to
PID.XPN.2 (in the attached XML schema).
PHIN 2007
16
Step 4: Altova Mapforce
Add PHIN Codes, OIDs, Rules, via XSLT
PHIN 2007
17
Step 5: Adobe LiveCycle Designer:
Attach the XSLT to “Transform Outgoing Data”
Insert snapshot:
PHIN 2007
18
Step 6: XMLSpy (or Other Validators)
View XML generated via Form Entry (+ XSLT)
PHIN 2007
19
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
20
Structure of a CDA Document (an XML Instance)
<ClinicalDocument >
<title>Confidential Morbidity Report</title>
<effectiveTime value="20050407"/>
<author> ..... </author>
<recordTarget>
<patient> ..... </patient>
</recordTarget>
Header
<component>
<structuredBody>
<component>
<section>
<code code="14657009" ….. codeSystemName="SNOMED CT"/>
<title>Established diagnosis</title>
Clinical
…..
Statement(s)
<entry>
<observation classCode="COND" moodCode="EVN"> .....
<value ... code="398565003" ... displayName="Botulism"> ... </value>
</observation>
</entry>
</section>
</component>
</structuredBody>
</component>
Body
</ClinicalDocument>
PHIN 2007
21
Example: Mapping HL7 2.5 Segments to an
HL7 CDA Message Schema
PHIN 2007
22
Conclusions, Hypotheses
1) 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).
2) 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.
=
PHIN 2007
PHIN 2007
PHIN 2008 and Beyond
23
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
24