XML, HL7 Messaging
and the Clinical Document Architecture
Contents
• Introduction to XML
• Introduction to Heath Level 7 (HL7)
• HL7 messaging, current and future
• HL7 Clinical Document Architecture (CDA)
Generalized Markup Languages
• Markup identifies structural elements of a
document rather than specific formatting features
• Markup is expressed as standard text sequences
(markup "tags")
• Formatting instructions are applied separately to
the specified document elements
• Markup tags can be human-readable
Markup Expresses Metadata
• Documents naturally have content and metadata
• Metadata may help specify:
>
>
>
>
Meaning of data (e.g., standard coding)
Arrangement of data (display)
Correct use of the data (business rules)
Context and relationships between data elements
• Example of display markup:
Documents contain <emph>metadata</emph> and "primary" data
Embedded "tag"
Tag content
Heritage of Generalized Markup Languages
Internal work
at IBM
TeX, nroff, troff
SGML
Frameworks
1984
Many specialpurpose markup
languages
Tag formats
DTD format
Processing rules
XML
1998
HTML
~1990
XHTML
Implementations
Many specialpurpose markup
languages
Extensable Markup Language (XML)
• HTML originally specified structural components of documents
> HTML has evolved to become a presentation syntax
• SGML is complex and requires complex processing software
• XML is a simplified version of SGML designed for electronic
document archiving and exchange
> Allows creation of special-purpose markup languages
> Can represent a variety of data structures and semi-structured data as well
as metadata
> Arbitrary tag nesting, recursion and granularity
> Human-readable and machine readable
> Expected to be useful for creation of special purpose data-interchange
standards as well as document structuring
XML Document Detail
Opening tag
Element name Attribute
<procedure cpt="1234">
<pat_phys pnum="abcd">
<firstName>Elmer</firstName>
<lastName>Fudd</lastName>
Content
<degree>M.D.</degree>
</pat_phys>
<proc_name>Upper endoscopy of gizzard</proc_name>
<proc_date>09/09/1999</proc_date>
<location name="ER"/>
</procedure>
Singleton tag
Closing tag
HL7
Health Level 7
Organized to create standards for the exchange, management
and integration of data that supports clinical patient care and the
management, delivery and evaluation of healthcare services
• Founded by healthcare providers in 1987
• Version 1.0 late in 1987
• Version 2.0 late in 1988
• Versions 2.1, 2.2 and 2.3 published in 1990, 1994 and 1997;
ANSI standards
• Pragmatic approach
• Work on Version 3 (XML-based) is ongoing
"Level Seven"
A protocol for the exchange of health care information
ISO-OSI Layered Protocol Model
Function
Communication
7
6
5
4
3
2
1
Application
Presentation
Session
Transport
Network
Data Link
Physical
HL7 Transactional Model
trigger event
(external) admit
event
send
HL7 A01 msg
receive HL7
ACK msg
ADT system
Lab system
Receive A01,
send ACK
network
Current Message-Router-Based Interfaces
CORPORATE SYSTEMS
PURCHASE ORDERS
ORDER STATUS
PURCHASE ORDERS
ORDER STATUS
MPAC ADT
EMTEK CLINICAL
EKG REPORTS
COPATH REPORTS
IDXRAD RESULTS
SUNQUEST RESULTS
CLINICAL DATA
MPAC ADT
ADT
SUNQUEST RESULTS
ADT
IDXRAD RESULTS
COPATH REPORTS
EXTERNAL HOSPITALS
SHADYSIDE ORBIT/OR SYSTEM
SHADYSIDE MUSE CARDIOLOGY
DEROYAL OR SUMMARY/NOTES
AMBULATORY RESULTS
SUMMIT RESULTS
SHADYSIDE SMS RADIOLOGY
SHADYSIDE MRC TRANSCRIPTION
SHADYSIDE TDS/PATIENT CARE
WPIC CLINICAL NOTES
MARQUETTE EKG
DOLBEY TRANSCRIPTION
CLINIPAC ORDERS
SHADYSIDE TDS ADT
SHADYSIDE SMS RADIOLOGY
MEDITEK LAB STATUS/RESULTS
SHADYSIDE TDS PHARMACY ORDERS
PHARMAKON RESULTS
QUEST STATUS/ RESULTS
COPATH STATUS/ RESULTS
MPAC RSP
MPAC ADT
RESULTS
MPAC ADT
COPATH DEMOG
IMAGE LOCATION
INQUIERIES
IDXRAD RESULT STATUS
ADT
ORDERS
MPAC ADT
SUNQUEST RESULT STATUS
ADT/OE
MPAC ADT
O.R. SUMMARY
PHYS. REPORTS
REPORTS
O.R. SUMMARY
MPAC ADT
ABACUS ADT
OMS RESULTS
MPAC ADT
CHP SMS ADT
IDXRAD REPORTS
PULMONARY RESULTS
MPAC ADT
MPAC ADT
CPAC ORDERS
ORBIT OR SYSTEM
MUSE CARDIOLOGY
PHARMACY ORDERS
BED CENSUS
RADIOLOGY/ SMS
LAB/ MEDITECH
TRANSCRIPTION/ MEDWRITER
ADT / SMS
MPAC ADT
ABACUS ADT
ADT
MPAC ADT
CLINICAL NOTES
QUEST RESULTS
SUNQUEST ORDERS
IN DEVELOPMENT
FILES FTP'D
PRODUCTION
SUNQUEST STATUS/ RESULTS
IDXRAD STATUS/ RESULTS
EPIC MPI#
MPAC ADT
EPIC RSP
MPAC INQ
EPIC INQ
DEMOG
MPAC ADT
IMAGE LOCATION
PATHOLOGY REPORTS
MPI #
SHADYSIDE TDS ADT
MPAC ADT
HDX INQ
HDX RESPONSE
MAGEE ADT
SUNQUEST RESULTS
ORDERS
DATA REPOSITORY
MPAC ADT
CIS RESULTS
ORDERS REPORTS
STAR ORDERS
STAR RESULT STATUS
CHP SMS ADT
CPAC ADT/OE
STATUS
RESULTS
STAR INQUIERIES
STAR ORDERS
STAR ADT/ OE
STAR RESULT STATUS
EPIC ORDERS
ORDERS TO QUEST
QUEST RESULTS
CHP SMS ADT
CPAC ADT/OE
CPAC RES / INQ
MPAC ADT
RESULTS
RESPONSE INS. ELIGIBILITY
INSURANCE ELIGIBILITY
ADT
CIS ORDERS
CBORD ORDERS
IDXRAD RESULTS
IDXRAD ADT/OE
SUNQUEST ADT/OE
SUNQUEST RESULTS/INQ
AS OF 10/9/98
LDG
NORTHERN
HEALTH
CHILDRENS
HOSPITAL
SMS
STAR
BRADDOCK,
MCKEESPORT,
ST. MARGARET
HORIZON
MAGEE
SMS
VA
HOSPITAL
PATHOLOGY
LAN VISION
IMAGING
DEROYAL
OR
AMBULATORY
RING MED
PAGING
INTELLUS
MEDICAL
RECORDS
SHADYSIDE
TDS
QUEST
REFERENCE
LABORATORY
MCDODGE
MARQUETTE
EKG
EMTEK
CRITICAL
CARE
DEC
EDI
APACHE
CRITICAL
CARE
CLEM
SUMMIT
CARDIOLOGY
DOLBEY
TRANSCRIPTION
CBORD
DIETARY
ABACUS
CERNER
CLINICAL INFORMATION SYSTEM
HDX INSURANCE
VERIFICATION
COPATH
PATHOLOGY
EPIC
PHYSICIAN
PRACTICE PLAN
MARS
PHARMAKON
PHARMACY
IDXRAD
RADIOLOGY
SUNQUEST
LAB
MEDIPAC
CLINIPAC
UPMC MESSAGE ROUTER
HL7 Abstract Messages
• Identifies data fields
• Describes error conditions
• DOES NOT describe the byte string contained in
the message.
Admit Message
segments, fields, components & subcomponents
MSH|^~\&|ADT1|MCM|LABADT|MCM|198808181126|SECURITY|ADT^A01|MSG00001|P|2.3|<cr>
EVN|A01|198808181123||<cr>
PID|||PATID1234^5^M11||JONES^WILLIAM^A^III||19610615|M||C|1200 N ELM
STREET^^GREENSBORO^NC^27401-1020|GL|(919)379-1212|(919)271-3434||S||
PATID12345001^2^M10|123456789|987654^NC|<cr>
NK1|JONES^BARBARA^K|WIFE||||||NK^NEXT OF KIN<cr>
PV1|1|I|2000^2012^01||||004777^LEBAUER^SIDNEY^J.|||SUR||||ADM|A0|<cr>
Variability in HL7 Interfaces
• Site 1:
OBX|1|CE|ABO^ABO GROUP||O^Type O|
• Site 2:
OBX|1|CE|BLDTYP^ABO GROUP||TYPEO^Type O|
• Site 3:
OBX|1|CE|ABOTYPE^ABO GROUP||OPOS^Type O|
"when you've seen one HL7 interface you've seen one HL7 interface"
HL7 v2.x is not Plug and Play
• Cost of installing an HL7 interface: 2-4 weeks of
analyst time
• Issues
> Different implicit information models
> Misunderstanding of specifications
> No vocabulary to describe conformance except by
detailed specs
> Significant local demands on vendors
Goals for Version 3
• Substantially reduce interface development time
> Clarify spec for messages
> Create a specified information model
• Method for conformance specification
• Support modern communications infrastructures
• Reference Information Model (RIM)
> Coherent shared information model
> Includes all content of HL7 messages
> Provides consistency to messages across usage settings
Reference Information Model (RIM)
Stakeholder_identifier
id : ST
identifier_type_cd : ID
participates_in
Active_participation
participation_type_cd : ID 0..*
0..*
is_assigned_to
is_assigned
1
0..1
Stakeholder participates_in
addr : XAD
1
phon : XTN
collects
Organization
organization_name_type_cd : CNE
organization_nm : ST
1 standard_industry_class_cd
0..*
takes_on_role_of
0..*
has_as_participant
0..*
is_collected_by
Person
birth_dttm : DTM
gender_cd : CNE
marital_status_cd : CNE
primary_name_representation_cd : CNE
is_a_subdivision_of
0..1
primary_name_type_cd : CNE
has_as_a_subdivision
primary_prsnm : PN
race_cd : CNE
0..*
participates_in
Service_intent_or_order
0..*
filler_order_id : IID
has_as_participant filler_txt : TX
is_entered_at
order_id
0..1 order_placed_dttm : DTM
order_quantitytiming_qt : TQ
placer_order_id : IID
placer_txt : TX
is_an_instance_of
has_as_target
report_results_to_phone : XTN
0..*
intent_or_order_cd : ID
0..1
Collected_specimen_sample
body_site_cd : CE
collection_end_dttm : DTM
collection_start_dttm : DTM
collection_volume_amt : CQ
handling_cd : ID
id : IID
method_of_collection_desc : TX
specimen_additive_txt : ST
specimen_danger_cd : ID
specimen_source_cd : CE
0..*
is_sourced_from
0..1
is_fulfilled_by
Observation_intent_or_order
patient_hazard_code
reason_for_study_cd
relevant_clinical_information_txt
reporting_priority_cd
specimen_action_cd
0..1
has_as_active_participant
is_target_of
is_source_for
0..1
is_target_of
1
takes_on_role_of
includes 0..1
Patient
0..*
1
1..*
0..1
fulfills
0..*
delivers
Service_event
has_as_target service_desc : ST
0..*
Tar get_par ticipation
is_instantiated_as
0..1 ambulatory_status_cd
service_event_desc
0..*
birth_order_number
has_as_targetparticipation_type_cd : CE
specimen_received_dttm : DTM is_delivered_during
Healthcare_service_provider
is_a_role_ofliving_arrangement_cd 0..1
1
1
is_target_of
name : CE
specialty_cd : CNE
Master_service
living_dependency_cd
0..*
0..*
is_target_of
multiple_birth_ind
method_cd : CE
has_as_target
is_performed_at
newborn_baby_ind
method_desc : TX
has_a_primary_providerorgan_donor_ind
service_desc : TX
Assessm ent
preferred_pharmacy_id
target_anatomic_site_cd : CE
0..*
universal_service_id : CE
is_the_primary_provider_for
is_a_role_of
is_a_role_of
0..*
0..1
0..1
0..1
has_as_primary_facility
Individual_healthcare_practitioner
Healthcare_provider_organization
Clinical_observation
desc : TX
abnormal_result_ind : ID
practitioner_type_cd : CNE
1..*
last_observed_normal_values_dttm : DTM
nature_of_abnormal_testing_cd : CE
is_primary_facility_for
clinically_relevant_begin_dttm : DTM
0..1
clinically_relevant_end_dttm : DTM
provides_patient_services_at
is_target_for
0..*
..* Master_patient_service_location 0..1
provides_services_on_behalf_of0
observation_value_txt : NM
addr : XAD
probability_number : NM
0..1
email_address
:
XTN
references_range_text : ST
0..*
id : ID
value_units_code : CE
is_location_for
is_included_in
nm : ST
phon : XTN
is_entry_location_for
1
takes_on_role_of
has_as_target
0..*
0..1
Advantages of XML for Message Formatting
• The syntax handles recursion and nesting
> Variably nested structures to arbitrary depth
> More flexible than segments, fields, components &
subcomponents
> Objects (including contained objects) can be represented
> Relational structures can be represented
•
•
•
•
Simple syntax, easy to debug (human readable)
Software tools (parsers, etc.) are generally available
Language- and platform-independent
Compatibility with other industries
HL7 2.3 Message Format
HL7 v3 Message Format
HL7 Clinical Document Architecture (CDA)
A multilevel representation of medical documents that can be
passed as messages and which make up the medical record.
• Level 1: XML-coded header
> Contents may be flat or tagged text
• Level 2: Coded document sections
> Generic architectural DTD with multiple derived DTDs
• Level 3: Coded content
> Text tagging based on RIM
> Generic architectural DTD with multiple derived DTDs
• Initial focus is documents used directly in clinical care
Definition of a Document
• Persistence
> Defined by local and regulatory requirements
• Stewardship
> Maintained by an organization or person
• Authentication
> A collection of information that is to be legally authenticated
• Wholeness
> Legal authentication applies to the document as a whole and not to
parts of the document out of context. The document also
establishes a context for use of the contained information.
• Human readability
Advantages of XML for Document Management
• Adaptable to unstructured and semi-structured data
• Tagging does not destroy the document or its text
flow
> The text of the document can be recovered by ignoring
the tags
• Tagged document are human readable
• If tagging is well-documented and/or tags are
logically named, XML documents will remain
readable over the long term
CDA Level 1 Markup
Header & "wrapper"
Clinical Document
as text
CDA Level 2 Markup
Header & "wrapper"
Clinical Document
with structural markup
(main sections)
CDA Level 3 Markup
Header & "wrapper"
Clinical Document
with detailed markup
including local extensions
Why Not Standardize DTDs?
•
•
•
•
•
DTDs support local processes
Single documents may use multiple DTDs
Achieving consensus on details is lengthy
DTDs evolve with local needs
Strategy:
> Create generic architectural DTDs
> Allow local extension
> Local extensions can be ignored when necessary
Key Header Elements
•
•
•
•
•
•
•
ID, set ID, version, addendum vs. replacement
Fulfills order
Document type (LOINC)
Origination time
Confidentiality level
Patient encounter
Service actors (care providers; individuals and
organizations)
> Authenticator, legal authenticator, originator, intended recipient,
originating organization, provider, transcriptionist
• Service target (living or inanimate)
> If patient, one and only one
Structural Markup
• HTML-like (captions/headings, paragraphs, lists,
tables)
• Recursive relationships
• Content tag: generic identifier and target for text
sequences
• Coded entry: standard vocabulary entry, can be
targeted to a text span defined by content tags
• Generic design yields limited ability to specify
structure of particular document types (schemas?)
• Complex style sheets for particular documents?
Summary
• XML is a flexible framework for creating tag vocabularies that
add metadata to textual documents
• HL7 is a core standard in healthcare systems communications
that has strengths and also specific weaknesses
• A new version of the HL7 messaging standard attempts to
address those weaknesses through definition of a reference
information model and XML message formatting
• HL7 has also defined a generic XML standard for clinical
documents that is intended to improve the structure,
accessibility and longevity of the electronic medical record.
Descargar

No Slide Title