Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
1 
HL7 Standards 
Nawanan Theera-Ampornpunt, M.D., Ph.D. 
Department of Community Medicine 
Faculty of Medicine Ramathibod...
2 
Some Slides Reproduced with 
Permission from 
Dr. Supachai Parchariyanon 
@supachaiMD 
»Profile: 
Dr. Supachai Parchari...
3 
Nawanan Theera-Ampornpunt 
2003 M.D. (Ramathibodi) 
2009 M.S. in Health Informatics (U of MN) 
2011 Ph.D. in Health Inf...
4 
Thailand’s HL7 
Certified Specialists 
Kevin 
Asavanant 
HL7 V3 RIM (2009) 
Supachai 
Parchariyanon 
HL7 CDA (2010) 
Na...
5 
Outline 
• Introduction to Standards & Interoperability 
• What is Health Level Seven (HL7)? 
• What HL7 does? 
• HL7 v...
6 
Standards Are Everywhere
7 
Standards: Why? 
• The Large N Problem 
N = 2, Interface = 1 
# Interfaces = N(N-1)/2 
N = 3, Interface = 3 
N = 5, Int...
8 
Health Information Exchange (HIE) 
Hospital A Hospital B 
Clinic C 
Government 
Lab Patient at Home
9 
Why Health Information Standards? 
Objectives 
• Interoperability 
• Inter-operable 
systems 
Ultimate Goals 
• Continu...
10 
What is interoperability? 
It is the ability of two or more systems 
or components to exchange information, 
and to us...
11 
Levels of Interoperability 
Functional 
Semantic 
Syntactic
12 
Goal of interoperability 
• HL7’s key goal of interoperability has 
two aspects: 
– Syntactic interoperability has to ...
13 
Things that can go wrong in 
message exchange 
Slide reproduced/adapted from Dr. Supachai Parchariyanon
14 
Standards are not equal 
Interoperability 
Standards only create the opportunity 
for interoperability and are not equ...
15 
Various Kinds of Standards 
• Unique Identifiers 
• Standard Data Sets 
• Vocabularies & Terminologies 
• Exchange Sta...
Functional Standards (HL7 EHR 
Functional Specifications) 
Vocabularies, Terminologies, 
Coding Systems (ICD-10, ICD-9, 
C...
17 
What is HL7? 
• HL7 is an ANSI-accredited Standards 
Development Organization (SDO) 
operating in the healthcare arena...
18 
What is HL7? (Cont.) 
• HL7 is an acronym for Health Level Seven 
– Seven represents the highest, or “application” 
le...
19 
OSI Model 
Slide reproduced/adapted from Dr. Supachai Parchariyanon
20 
What HL7 does? 
• HL7 focuses on the clinical and administrative 
data domains. 
• It defines data exchange standards ...
21 
What HL7 does? 
Slide reproduced/adapted from Dr. Supachai Parchariyanon
22 
HL7 Standards 
• HL7V2.x 
– Defines electronic messages supporting hospital 
operations 
• HL7V3 
• HL7 Clinical Docum...
23 
The Industry Standard 
HL7 version 2 (HL7 v2) 
• Not “Plug and Play” - it provides 80 percent of the 
interface and a ...
24 
HL7 version2 
• HL7 v2 is still the most commonly used HL7 
standard 
– Over 90% of US hospitals have implemented some...
25 
HL7 v2 Message 
• Composed of reusable segments, each 
identified by a 3-letter mnemonic 
• All messages must start wi...
26 
Part of Sample HL7 v.2 Message 
(Lab Result) 
OBX|1|NM|10839-9^TROPONIN-I^LN||5|ng/ml| 
0-1.3|H||H|F|19980309… 
Slide ...
27 
HL7 Basic Transaction 
Model 
trigger event 
send 
HL7 ADT 
A01 msg 
receive HL7 
ACK msg 
ADT system 
Lab system 
Rec...
28 
Patient Admission Scenario, 
Inform Lab System 
• Trigger event is admission : A01 
• Message type is: ADT 
• Messages...
29 
HL7 v2 Message 
• Messages composed of 
– Segments composed of 
• Fields composed of 
– Components 
• Delimiters 
– Fi...
30 
Message Header Segment - MSH 
Sending 
Unit 
Receiving 
Unit Date 
Time 
Message 
type 
Trigger 
ID 
MSH|^~|&|SMS|OR2|...
31 
PID Segment – 1/3 
Check digit 
Patient ID 
Method 
Last name 
First name 
Middle 
Initial 
Suffix 
PID|Z12345^5^M11||...
32 
PID Segment – 2/3 
Mother’s 
maiden name 
Date of birth Race 
MAIDEN|19610605|M||C|1492 OCEAN STREET^ 
Gender 
Street ...
33 
PID Segment – 3/3 
City 
State 
Zip Code 
County 
Telephone 
DURHAM^NC^27705|DUR|(919)684-6421<cr> 
Segment terminator...
34 
PV1 Segment 
PV1|1|1|N2200^2200|||OR^02|0846^WELBY^MARCUS^G||SUR<cr> 
Patient location 
Attending 
Service 
Sequence 
...
35 
OBR Segment 
Placer order 
number 
Filler order 
number 
Universal 
service ID 
Text 
order Local set 
OBR|1|330769.00...
36 
Typical Result Message - 
ORU 
MSH|^~&|||||19981105131523||ORU^R01<cr> 
PID|||100928782^9^M11||Smith^John^J<cr> 
OBR||...
37 
Summary 
Slide reproduced/adapted from Dr. Supachai Parchariyanon
38 
Admit Discharge Transfer 
(ADT) 
MSH Message Header Segment 
[ 
EVN Event type segment 
PID Patient Identification seg...
39 
RULES 
Slide reproduced/adapted from Dr. Supachai Parchariyanon
40 
ADT event types 
ADT^A13 Cancel discharge/end visit 
ADT^A04 Register a patient 
ADT^A08 Update patient information 
A...
41 
Example message (ORU) 
MSH|^~&|HCLAB||HIS||20110826000629||ORU^R01|HCL0004461303|P|2.3||||||8859<cr> 
PID|1||4552213||...
42 
Problems with HL7v2 
• HL7 v2 cannot support all this! 
– Ad Hoc design methodology 
– Ambiguous – lacking definition ...
43 
What’s Different About v3? 
• Conceptual foundation 
– A single, common reference information model to be used across ...
44 
How is v3 different than v2? 
• v3 is approaching “Plug and Play” 
• v2 uses pipe and hat messaging, while v3 
uses th...
45 
HL7 V3 Standards 
• A family of standards based on V3 
information models and development 
methodology 
• Components 
...
46 
How HL7 V3 Works 
• Message sent from sending application to 
receiving application 
• Mostly triggered by an event 
•...
47 
v3 Messaging Standard 
• Based on an object information model, called the 
Reference Information Model, (RIM) 
– This ...
48 
Why Cross-Reference to 
the RIM? 
• Domain analysis models support 
communication within a domain 
• Communications be...
49 
HL7 V3 Messaging 
• V3 provides messaging standards for 
– Patient administration 
– Medical records 
– Orders 
– Labo...
50 
Sample HL7 v.3 Message 
(Patient Registration) 
<?xml version="1.0" encoding="UTF-8"?> 
<PRPA_IN101311UV02 xmlns="urn:...
51 
HL7 v3 Reference 
Information Model 
Act 
Relationship 
• Referral 
• Transportation 
• Supply 
• Procedure 
• Consent...
52 
HL7 v3 Components and Process: RIM UML Instance 
Scenario 
Entity Role Participation Act 
John Doe Patient Subject 
Dr...
53 
Reference Information Model (RIM) 
53
54 
Source: “What is CDA R2? by Calvin E. Beebe 
at HL7 Educational Summit in July 2012
55 
The HL7 v3 Solution 
• Approaching “Plug and Play” - less of a 
“framework for negotiation” 
• Utilizes RIM for data m...
56 
The HL7 v3 Solution (Cont.) 
• HL7v3 addresses the problems of HL7v2 
by: 
– Reducing HL7v2 optionality 
– Including t...
57 
Interoperability in HL7 v3 
• The Four Pillars of Semantic 
Interoperability in HL7v3 
– A common Reference Informatio...
58 
HL7 Development 
Framework 
• Formal methodology for mapping any “local”, domain - 
specific system, such as a “labora...
59 
Model-based Development 
HL7 Framework HL7 Specification 
RIM 
Data types 
Data elements 
Vocabulary 
Templates 
Clini...
60 
HL7 Model Repository 
• Database holding the core of HL7 
semantic specifications 
– RIM 
– Storyboards 
– Vocabulary ...
61 
HL7 Version 3.0 
• Use-case Model 
• Reference Information Model 
• Domain Information Model 
• Message Information Mo...
Slide reproduced/adapted from Dr. Supachai Parchariyanon 62
63 
Domain Document Elements 
Slide reproduced/adapted from Dr. Supachai Parchariyanon
64 
Example: HL7 v3 
Slide reproduced/adapted from Dr. Supachai Parchariyanon
Slide reproduced/adapted from Dr. Supachai Parchariyanon 65
66 
Navigating the V3 Ballot 
Publication 
Slide reproduced/adapted from Dr. Supachai Parchariyanon
67 
Navigating the V3 Ballot 
Publication 
• Domains: The Functional Content of the 
Publication 
– Universal Realm Domain...
68 
Domain Publication 
Structure 
Each Realm contains a collection of 
Domains. Domains are further divided into 
Topics ...
69 
V3 Messaging Concerns 
• Difficult to implement 
• No one understands v3 
• Overhead too much 
– 1% of message is payl...
70 
The Future of HL7 
• FHIR: Fast Healthcare Interoperability 
Resources 
– Pronounced “Fire” 
• FHIR defines a set of “...
71 
Additional Information 
• Health Level Seven 
– www.hl7.org 
• HL7 Reference Information Model 
– https://www.hl7.org/...
72 
Assignment 1 
1._______ messaging standard is easy to use and understand. It is 
based on an implicit information mode...
73 
Assignment 1 
3. In the HL7 transaction model a(n) _____ occurs and activates the 
sending of a specific message type ...
74 
Assignment 1 
5. ___________ creates standards for pharmacy services. 
1. X12N 
2. NCPDP 
3. DICOM 
4. IEEE 
6. ______...
75 
Assignment 1 
7. ______ has developed standards for the exchange of purchase-order 
data, invoice data and other commo...
76 
Assignment 1: Key 
1._______ messaging standard is easy to use and understand. It is 
based on an implicit information...
77 
Assignment 1: Key 
3. In the HL7 transaction model a(n) _____ occurs and activates the 
sending of a specific message ...
78 
Assignment 1: Key 
5. ___________ creates standards for pharmacy services. 
1. X12N 
2. NCPDP 
3. DICOM 
4. IEEE 
6. _...
79 
Assignment 1: Key 
7. ______ has developed standards for the exchange of purchase-order 
data, invoice data and other ...
80 
Assignment 2 
“READING AN ADT MESSAGE” 
For the Message: 
MSH|^~&|ADT_HGG||LAB_HGG||20090827120759||ADT^A01^ADT_A01|AD...
81 
Assignment 2 
ASSIGNMENT 2 - “READING AN ADT MESSAGE” 
For the Message: 
1: What type of message is it, and what is it...
82 
Assignment 2: Key 
ASSIGNMENT 2 - “READING AN ADT MESSAGE” 
For the Message: 
1: What type of message is it (ADT^A01^A...
83 
Assignment 2: Key 
4: Which clinicians are involved? Which roles are they playing? How old is 
the patient? 
AARON-ATT...
84 
HL7 Reference Information 
Model (RIM) 
Nawanan Theera-Ampornpunt, M.D., Ph.D. 
Department of Community Medicine 
Facu...
85 
Outline 
• Reference Information Model (RIM) 
– Overview 
– RIM Domains 
– Domain Related Classes 
– Backbone Classes ...
86 
Reference Information 
Model 
• The RIM is the cornerstone of HL7 v3 
messaging. 
• The RIM is an UML Model class diag...
87 
RIM - Domain Related 
Classes 
Slide reproduced/adapted from Dr. Supachai Parchariyanon
88 
RIM Backbone Classes 
Entity Role Participation Act 
A physical thing, 
group of physical 
things or an 
organization ...
89 
RIM as an Abstract Model 
• The RIM is comprised of six “back-bone” classes: 
– Act: which represents the actions that...
90 
RIM as an Abstract Model 
– Role: which establishes the roles that entities play as 
they participate in health care a...
91 
HL7 v3 Components and Process: RIM UML Instance 
Scenario 
Entity Role Participation Act 
John Doe Patient Subject 
Dr...
92 
RIM Entity Classes 
Slide reproduced/adapted from Dr. Supachai Parchariyanon
93 
RIM Entity Classes 
Entity 
classCode : CS 
determinerCode : CS 
id : SET<II> 
code : CE 
quantity : SET<PQ> 
name : B...
94 
RIM Entity Classes: 
How to Read 
Entity 
classCode : CS 
determinerCode : CS 
id : SET<II> 
code : CE 
quantity : SET...
95 
RIM Entity Classes : How to 
Read 
Entity 
classCode : CS 
determinerCode : CS 
id : SET<II> 
code : CE 
quantity : SE...
96 
RIM Entity Classes : How to 
Read 
Entity 
classCode : CS 
determinerCode : CS 
id : SET<II> 
code : CE 
quantity : SE...
97 
RIM Role Classes 
Slide reproduced/adapted from Dr. Supachai Parchariyanon
98 
RIM Role Classes 
• Roles: 
– A responsibility or part played by an entity (e.g. 
Person in a role of patient, employe...
99 
RIM Participation and Act 
Classes 
Slide reproduced/adapted from Dr. Supachai Parchariyanon
100 
RIM Participation Class 
• Participation: 
– An association between an Act and a 
Role with an Entity playing that Ro...
101 
RIM Act Class 
• Act: 
– A collection of classes including the Act 
class and its specializations. These relate to 
t...
102 
RIM ActRelationship Class 
• ActRelationship: 
– A directed association 
between a source Act and a 
target Act. A po...
103 
HL7 v3 Process & Artifacts 
Overview 
RIM DMIM RMIM 
1..* 1..* 
MT HMD 1..* 
1..* 
Slide reproduced/adapted from Dr. ...
104 
Domain Message 
Information Model (DMIM) 
• A DMIM is a refined subset 
of the RIM that includes a 
set of class clon...
105 
Refined Message 
Information Model (RMIM) 
• The RMIM is a subset of a 
DMIM that is used to express 
the information...
106 
Hierarchical Message 
Definition (HMD) 
• An HMD is a serialized version of the RMIM in a specific 
order. 
• This is...
107 
Message Type (MT) 
 A Message specification 
is a set of rules for 
constructing a message 
given a specific set of ...
108 
Data Types 
• Symbol: TS 
• Name: Point in Time 
• Description: A quantity specifying a point 
on the axis of natural...
109 
Data Types 
• Symbol: ANY 
• Name: DataValue 
• Description: Defines the basic properties of 
every data value. This ...
110 
Data Types 
• Symbol: BL 
• Name: Boolean 
• Description: The Boolean type stands for 
the values of two-valued logic...
111 
Data Types 
• Symbol: BN 
• Name: Boolean not NULL 
• Description: The Boolean type stands for 
the values of two-val...
112 
Data Types 
• Symbol: ST 
• Name: Character String 
• Description: The character string data type 
stands for text da...
113 
Data Types 
• Symbol: CS 
• Name: Coded Simple Value 
• Description: Coded data in its simplest 
form, where only the...
114 
Data Types 
• Symbol: CE 
• Name: Coded With Equivalents 
• Description: Coded data that consists of a 
coded value (...
115 
Data Types 
• Symbol: SC 
• Name: Character String with Code 
• Description: A Character String that 
optionally may ...
116 
Data Types 
• Symbol: II 
• Name: Instance Identifier 
• Description: An identifier that uniquely 
identifies a thing...
117 
Data Types 
• Symbol: SET 
• Name: Set 
• Description: A value that contains other 
distinct values in no particular ...
118 
Data Types 
• Symbol: BAG 
• Name: Bag 
• Description: An unordered collection of 
values, where each value can be co...
119 
Data Types 
• Symbol: IVL 
• Name: Interval 
• Description: A set of consecutive values of 
an ordered base data type...
120 
Data Types 
• Symbol: ED 
• Name: Encapsulated Data 
• Description: Allows the transmission of text 
of pointer to a ...
121 
Q/A 
Slide reproduced/adapted from Dr. Supachai Parchariyanon
122 
HL7 Clinical Document 
Architecture (CDA) 
Nawanan Theera-Ampornpunt, M.D., Ph.D. 
Department of Community Medicine 
...
123 
Exchange Standards 
Message Exchange 
• Goal: Specify format 
for exchange of data 
• Internal vs. external 
messages...
124 
Exchange Standards 
Messages 
• Human Unreadable 
• Machine Processable 
Clinical Documents 
• Human Readable 
• (Ide...
125 
Message Exchange 
Message 
Message 
Hospital A Hospital B 
Clinic C 
Government 
Lab Patient at Home 
Message 
Messag...
126 
Clinical Document Exchange 
Message containing 
Referral Letter 
Message containing 
Claims Request 
Message containi...
127 
What Is HL7 CDA? 
• “A document markup standard that 
specifies structure & semantics of “clinical 
documents” for th...
128 
What is CDA? 
• CDA is based on XML 
• XML is eXtensible Markup Language 
• In XML, structure & format are conveyed 
...
129 
Clinical Documents 
Slide reproduced/adapted from Dr. Supachai Parchariyanon
Slide reproduced/adapted from Dr. Supachai Parchariyanon 130
131 
A Clinical Document (1) 
• A documentation of clinical observations 
and services, with the following 
characteristic...
132 
A Clinical Document (2) 
• A documentation of clinical observations 
and services, with the following 
characteristic...
133 
A Clinical Document (3) 
• A CDA document is a defined & complete 
information object that can include 
 Text 
 Ima...
134 
Key Aspects of CDA 
• CDA documents are encoded in XML 
 When alternative implementations are feasible, 
new conform...
135 
Scope of CDA 
• Standardization of clinical documents for 
exchange 
• Data format of clinical documents outside 
of ...
136 
Scope of CDA 
• CDA doesn’t specify creation or 
management of documents and messages 
related to document management...
137 
Scope of CDA 
Lab Report 
Lab Technician Physician 
Create 
document 
Process & 
Store 
document 
Transmit 
document ...
138 
Scope of document content 
• Clinical content of the documents is 
defined by the RIM and not by CDA. CDA 
only stand...
139 
Goals of CDA (1) 
• Give priority to delivery of patient care 
• Allow cost effective implementation across 
as wide ...
140 
Goals of CDA (2) 
• Enable a wide range of post-exchange 
processing applications 
• Be compatible with a wide range ...
Design Principles of CDA (1) 
• Must be compatible with XML & HL7 RIM 
• Must be compatible with representations of 
clini...
Design Principles of CDA (2) 
• Should impose minimal constraints or 
requirements on document structure and content 
requ...
Design Principles of CDA (3) 
• Document specifications for document creation & 
processing, if intended for exchange, sho...
144 
CDA & HL7 Messages 
• Documents complement HL7 messaging 
specifications 
• Documents are defined and complete inform...
145 
CDA & Message Exchange 
• CDA can be payload (or content) in any kind of 
message 
– HL7 V2.x message 
– HL7 V3 messa...
146 
CDA & Message Exchange 
Clinical Document 
(Payload) 
HL7 V3 Message 
(Message) 
HL7 V2 Message 
(Message) 
Source: A...
147 
CDA As Payload 
Source: From “What is CDA R2? by Calvin E. Beebe 
at HL7 Educational Summit in July 2012
148 
MIME 
• Multipurpose Internet Mail Extensions 
• An Internet standard that extends the format of e-mail 
to support 
...
149 
Base64 Encoding 
• TWFuIGlzIGRpc3Rpbmd1aXNoZWQsIG5vdCBvbmx5IGJ 
5IGhpcyByZWFzb24sIGJ1dCBieSB0aGlzIHNpbmd1bG 
FyIHBhc3...
Components of CDA Document 
150 
• CDA = Header + Body 
• Header 
– Metadata requires for document discovery, management, ...
151 
XML Markup for CDA 
• XML tag is defined <tag> 
• Data is expressed as data element name 
• Data value is “value” 
• ...
152 
Major Components of a 
CDA 
• A CDA document is wrapped by the 
<ClinicalDocument> element, and contains 
a header an...
153 
Major Components of a 
CDA 
Slide reproduced/adapted from Dr. Supachai Parchariyanon
154 
CDA Model 
Source: From “What is CDA R2? by Calvin E. Beebe 
at HL7 Educational Summit in July 2012
Human Readable Part 
Machine Processable Parts 
155 
A Closer Look at a CDA Document 
<ClinicalDocument> ... CDA Header .....
156 
Rendering CDA Documents (1) 
Source: From “What is CDA R2? by Calvin E. Beebe 
at HL7 Educational Summit in July 2012
157 
Rendering CDA Documents (2) 
Source: From “What is CDA R2? by Calvin E. Beebe 
at HL7 Educational Summit in July 2012
158 
Rendering CDA Documents (3) 
• Different recipients may use different style sheets 
to render the same CDA document, ...
Human Readability & Rendering 
159 
CDA Documents (1) 
• Receiver of a CDA document can algorithmically 
display clinical ...
Human Readability & Rendering 
160 
CDA Documents (2) 
• When structured content is derived from 
narrative, there must be...
Human Readability & Rendering 
Text to be rendered 
161 
CDA Documents (3) 
<ClinicalDocument> ... CDA Header ... 
<struct...
162 
CDA Levels are 
distinguished by: 
• Granularity of machine-processible markup 
• Level One -- Body is human-readable...
163 
Release 1: defined Level 
One, Level Two only 
Slide reproduced/adapted from Dr. Supachai Parchariyanon
164 
Release 2: Levels One, 
Two, Three 
Slide reproduced/adapted from Dr. Supachai Parchariyanon
165 
Header 
• Main CDA elements : Header 
Slide reproduced/adapted from Dr. Supachai Parchariyanon
166 
Body 
Slide reproduced/adapted from Dr. Supachai Parchariyanon
167 
Body 
• Preferred non-XML document types: 
– text/rtf 
– text/html 
– text/plain 
– application/pdf 
– image/g3fax 
–...
168 
Body – Narrative Text 
Slide reproduced/adapted from Dr. Supachai Parchariyanon
169 
Body – Narrative Text 
(Table) 
Example 
Result 
Slide reproduced/adapted from Dr. Supachai Parchariyanon
170 
Body – Narrative Text (List) 
Example 
Result 
Slide reproduced/adapted from Dr. Supachai Parchariyanon
171 
Body –Structured Body 
(Human Readable) 
<section> 
<caption> 
<captionCode V="11496‐7" S=“LOINC"/> 
Allergies and Ad...
172 
Body - Structured Body 
(Machine Processible) 
<text> 
<list> 
<item><content ID="A1">Penicillin – Hives … 
</list> 
...
173 
Entries 
Structure Body 
– Machine Processible 
Slide reproduced/adapted from Dr. Supachai Parchariyanon
174 
Entries - observation 
Slide reproduced/adapted from Dr. Supachai Parchariyanon
175 
Entries - observation 
• Derived from the RIM Observation class, it is 
used to represent coded and other observation...
176 
Entries - observation 
(Example) 
Slide reproduced/adapted from Dr. Supachai Parchariyanon
177 
Document & Section Codes 
• The CDA specification permits the use of 
document codes and section codes. Thus, 
it is ...
178 
Rendering Tags 
<section> 
<text> 
<content emphasis="bold"> 
This is rendered bold, 
<content emphasis="italics"> 
t...
179 
Rendering Tags 
<section> 
<code code="10153-2" codeSystem="2.16.840.1.113883.6.1“ 
codeSystemName="LOINC"/> 
<title>...
XML Markup of CDA Documents 
• CDA instances are valid against CDA Schema 
• May be subject to additional validation 
• No...
181 
Design Principles of 
CDA Schema (1) 
• Design of CDA Schema follows more general 
requirements for CDA 
• Follow gen...
182 
Design Principles of 
CDA Schema (2) 
• Forward and backward compatibility 
• Tag names should be clear, human-unders...
183 
Security, Confidentiality & Data 
Integrity 
• Application systems sending and receiving CDA 
documents are responsib...
184 
CDA Conformance (1) 
• CDA document originator application is 
responsible for ensuring that generated CDA 
documents...
185 
CDA Conformance (2) 
Recipient Responsibilities 
• Assume default values where defined and the document 
instance doe...
186 
CDA Conformance (3) 
Originator Responsibilities 
• Properly construct CDA Narrative Blocks 
– Section label is conve...
187 
CDA & Document Management 
• CDA focuses on document exchange, not 
storage or processing 
• Clinical documents are u...
188 
CDA & Document Management 
• CDA supports appending and replacement of 
documents through use of Document ID, setID, ...
189 
Document Management Examples 
Source: From “What is CDA R2? by Calvin E. Beebe 
at HL7 Educational Summit in July 201...
190 
CDA Releases 
• CDA Release 1 (ANSI-approved in 2000) 
– First specification derived from HL7 RIM 
• CDA Release 2 (2...
191 
Changes Between CDA R1 & R2 
• In CDA R2, both header & body are fully RIM-derived 
• Much richer assortment of entri...
192 
Some Possible Use Cases of CDA 
 Intra-institutional 
 Exchange of parts of medical records (scanned or 
structured...
193 
Some Possible Use Cases of CDA 
 Inter-institutional 
 Referral letters 
 Claims requests or reimbursement documen...
194 
Achieving Interoperability 
 CDA is a general-purpose, broad standard 
 Use in each use case or context requires 
i...
195 
CDA Extensibility 
 Locally-defined markup possible when local 
semantics have no corresponding representation 
in C...
196 
CDA Summary 
 CDA is a markup standard for document 
exchange 
 Not message exchange 
 Not document storage or pro...
197 
CDA Summary 
 CDA is XML-based and RIM-based 
 CDA documents can be exchanged as 
encapsulated data (payload) in an...
198 
Take Home Message 
• HL7 is not panacea and so does other standards 
• People and processes matter most 
• Do not aim...
199 
Assignment 
 Assignment: Using the outline for a CDA, create a 
section for reporting a height and a weight measurem...
200 
Assignment: Key 
Assignment: Using the outline for a CDA, create a 
section for reporting a height and a weight 
meas...
201 
Q/A 
Slide reproduced/adapted from Dr. Supachai Parchariyanon
Upcoming SlideShare
Loading in …5
×

Hl7 Standards, Reference Information Model & Clinical Document Architecture

For Mahidol University Faculty of ICT's Undergraduate Health IT Track Teaching

  • Login to see the comments

Hl7 Standards, Reference Information Model & Clinical Document Architecture

  1. 1. 1 HL7 Standards Nawanan Theera-Ampornpunt, M.D., Ph.D. Department of Community Medicine Faculty of Medicine Ramathibodi Hospital Certified HL7 CDA Specialist Some slides reproduced & adapted with permission from Dr. Supachai Parchariyanon October 11, 2014
  2. 2. 2 Some Slides Reproduced with Permission from Dr. Supachai Parchariyanon @supachaiMD »Profile: Dr. Supachai Parchariyanon is a medical doctor who’s passionate about information technology and turn himself to be informatician and serial entrepreneurs. He’s also earned Business Management degree from Ramkamhaeng university and Biomedical Informatics degree from the US. He led the team to certify both HL7 Reference Information Model (RIM) and Clinical Document Architecture (CDA). His interest is now on standards and interoperability, clinical informatics and project management. »Keep in touch »supachaimd@gmail.com »http://www.facebook.com/supachaiMD Slide reproduced/adapted from Dr. Supachai Parchariyanon
  3. 3. 3 Nawanan Theera-Ampornpunt 2003 M.D. (Ramathibodi) 2009 M.S. in Health Informatics (U of MN) 2011 Ph.D. in Health Informatics (U of MN) 2012 Certified HL7 CDA Specialist Former Deputy Chief, Informatics Division Deputy Executive Director for Informatics, Chakri Naruebodindra Medical Institute Faculty of Medicine Ramathibodi Hospital nawanan.the@mahidol.ac.th http://groups.google.com/group/ThaiHealthIT Research interests: • EHRs & health IT applications in clinical settings • Health IT adoption • Health informatics education & workforce development
  4. 4. 4 Thailand’s HL7 Certified Specialists Kevin Asavanant HL7 V3 RIM (2009) Supachai Parchariyanon HL7 CDA (2010) Nawanan Theera-Ampornpunt HL7 CDA (2012) Sireerat Srisiriratanakul HL7 V3 RIM (2013)
  5. 5. 5 Outline • Introduction to Standards & Interoperability • What is Health Level Seven (HL7)? • What HL7 does? • HL7 version 2 • HL7 version 3 Messaging Standard • Reference Information Model (RIM) • Interoperability in HL7 version3 • V3 Normative Publication • Clinical Document Architecture (CDA)
  6. 6. 6 Standards Are Everywhere
  7. 7. 7 Standards: Why? • The Large N Problem N = 2, Interface = 1 # Interfaces = N(N-1)/2 N = 3, Interface = 3 N = 5, Interface = 10 N = 100, Interface = 4,950
  8. 8. 8 Health Information Exchange (HIE) Hospital A Hospital B Clinic C Government Lab Patient at Home
  9. 9. 9 Why Health Information Standards? Objectives • Interoperability • Inter-operable systems Ultimate Goals • Continuity of Care • Quality  Safety  Timeliness  Effectiveness  Equity  Patient-Centeredness  Efficiency
  10. 10. 10 What is interoperability? It is the ability of two or more systems or components to exchange information, and to use the information that has been exchanged predictably (IEEE Standard Computer Dictionary) Slide reproduced/adapted from Dr. Supachai Parchariyanon
  11. 11. 11 Levels of Interoperability Functional Semantic Syntactic
  12. 12. 12 Goal of interoperability • HL7’s key goal of interoperability has two aspects: – Syntactic interoperability has to do with structure – Semantic interoperability has to do with meaning Slide reproduced/adapted from Dr. Supachai Parchariyanon
  13. 13. 13 Things that can go wrong in message exchange Slide reproduced/adapted from Dr. Supachai Parchariyanon
  14. 14. 14 Standards are not equal Interoperability Standards only create the opportunity for interoperability and are not equal to interoperability Slide reproduced/adapted from Dr. Supachai Parchariyanon
  15. 15. 15 Various Kinds of Standards • Unique Identifiers • Standard Data Sets • Vocabularies & Terminologies • Exchange Standards – Message Exchange – Document Exchange • Functional Standards • Technical Standards: Data Communications, Encryption, Security
  16. 16. Functional Standards (HL7 EHR Functional Specifications) Vocabularies, Terminologies, Coding Systems (ICD-10, ICD-9, CPT, SNOMED CT, LOINC) Information Models (HL7 v.3 RIM, ASTM CCR, HL7 CCD) Standard Data Sets Unique ID Exchange Standards (HL7 v.2, HL7 v.3 Messaging, HL7 CDA, 16 How Standards Support Interoperability Functional Semantic Syntactic DICOM) Technical Standards (TCP/IP, encryption, security) Some may be hybrid: e.g. HL7 v.3, HL7 CCD
  17. 17. 17 What is HL7? • HL7 is an ANSI-accredited Standards Development Organization (SDO) operating in the healthcare arena. • It is a non-profit organization made up of volunteers – providers, customers, vendors, government, etc. Slide reproduced/adapted from Dr. Supachai Parchariyanon
  18. 18. 18 What is HL7? (Cont.) • HL7 is an acronym for Health Level Seven – Seven represents the highest, or “application” level of the International Standards Organization (ISO) communications model for Open Systems Interconnection (OSI) networks. Slide reproduced/adapted from Dr. Supachai Parchariyanon
  19. 19. 19 OSI Model Slide reproduced/adapted from Dr. Supachai Parchariyanon
  20. 20. 20 What HL7 does? • HL7 focuses on the clinical and administrative data domains. • It defines data exchange standards for these domains called messages or messaging specifications (aka HL7 messages) – Messages are developed by technical committees and special interest groups in the HL7 organization. • HL7 organization defines 2 versions of the messaging standard: – HL7 v2.x (syntactic only) – HL7 v3.0 (semantic capability added) Slide reproduced/adapted from Dr. Supachai Parchariyanon
  21. 21. 21 What HL7 does? Slide reproduced/adapted from Dr. Supachai Parchariyanon
  22. 22. 22 HL7 Standards • HL7V2.x – Defines electronic messages supporting hospital operations • HL7V3 • HL7 Clinical Document Architecture (CDA) Releases 1 and 2 • HL7 Arden Syntax – Representation of medical knowledge • HL7 EHR & PHR Functional Specifications • Etc.
  23. 23. 23 The Industry Standard HL7 version 2 (HL7 v2) • Not “Plug and Play” - it provides 80 percent of the interface and a framework to negotiate the remaining 20 percent on an interface-by-interface basis • Historically built in an ad hoc way because no other standard existed at the time • Generally provides compatibility between 2.X versions • Messaging-based standard built upon pipe and hat encoding • In the U.S., V2 is what most people think of when people say “HL7″ Slide reproduced/adapted from Dr. Supachai Parchariyanon
  24. 24. 24 HL7 version2 • HL7 v2 is still the most commonly used HL7 standard – Over 90% of US hospitals have implemented some version of 2.x HL7 messages • The HL7 v2 messaging standard is considered: – The workhorse of data exchange in healthcare – The most widely implemented standard for healthcare information in the world • HL7 v2.5 was approved as an ANSI standard in 2003 • HL7 is currently working on version 2.7 Slide reproduced/adapted from Dr. Supachai Parchariyanon
  25. 25. 25 HL7 v2 Message • Composed of reusable segments, each identified by a 3-letter mnemonic • All messages must start with header segment MSH which includes sender, receiver, date-time, message identifier, message type, and trigger event • Segments used in a message are determined by message type Slide reproduced/adapted from Dr. Supachai Parchariyanon
  26. 26. 26 Part of Sample HL7 v.2 Message (Lab Result) OBX|1|NM|10839-9^TROPONIN-I^LN||5|ng/ml| 0-1.3|H||H|F|19980309… Slide reproduced/adapted from Dr. Supachai Parchariyanon
  27. 27. 27 HL7 Basic Transaction Model trigger event send HL7 ADT A01 msg receive HL7 ACK msg ADT system Lab system Receive A01, send ACK (external) admit event network Slide reproduced/adapted from Dr. Supachai Parchariyanon
  28. 28. 28 Patient Admission Scenario, Inform Lab System • Trigger event is admission : A01 • Message type is: ADT • Messages composed of: – MSH (message header) – PID (patient identification) – PV1 (visit data) Slide reproduced/adapted from Dr. Supachai Parchariyanon
  29. 29. 29 HL7 v2 Message • Messages composed of – Segments composed of • Fields composed of – Components • Delimiters – Field separator: | – Component separator: ^ – Repetition separator: ~ – Escape character: – Subcomponent: & – Segment terminator: <cr> Slide reproduced/adapted from Dr. Supachai Parchariyanon
  30. 30. 30 Message Header Segment - MSH Sending Unit Receiving Unit Date Time Message type Trigger ID MSH|^~|&|SMS|OR2|TMR|SICU|201010191535|password|ADT^A01|MSG1632|P|2.7<cr> Sending Place Receiving Place Message Number version Delimiters production Slide reproduced/adapted from Dr. Supachai Parchariyanon
  31. 31. 31 PID Segment – 1/3 Check digit Patient ID Method Last name First name Middle Initial Suffix PID|Z12345^5^M11||||PATIENT^JOSEPH^M^IV| Patient name Null fields Data field Field delimiter Slide reproduced/adapted from Dr. Supachai Parchariyanon
  32. 32. 32 PID Segment – 2/3 Mother’s maiden name Date of birth Race MAIDEN|19610605|M||C|1492 OCEAN STREET^ Gender Street address Data component Component delimiter Slide reproduced/adapted from Dr. Supachai Parchariyanon
  33. 33. 33 PID Segment – 3/3 City State Zip Code County Telephone DURHAM^NC^27705|DUR|(919)684-6421<cr> Segment terminator Slide reproduced/adapted from Dr. Supachai Parchariyanon
  34. 34. 34 PV1 Segment PV1|1|1|N2200^2200|||OR^02|0846^WELBY^MARCUS^G||SUR<cr> Patient location Attending Service Sequence number Patient class Slide reproduced/adapted from Dr. Supachai Parchariyanon
  35. 35. 35 OBR Segment Placer order number Filler order number Universal service ID Text order Local set OBR|1|330769.0001.001^DMCRES|0000514215^RADIS1|77061^U/S PEVLIC^L ||201010211145|||||||||||||0491909||||U999|M||||||^FIBROIDS, R/O|207484^ CARROLL&BARBARA&A|||089657&BROWN&JOANNE<CR> Requested date-time of service Reason for study Principal results interpreter Slide reproduced/adapted from Dr. Supachai Parchariyanon
  36. 36. 36 Typical Result Message - ORU MSH|^~&|||||19981105131523||ORU^R01<cr> PID|||100928782^9^M11||Smith^John^J<cr> OBR||||Z0063-0^^LN<cr> OBX||XCN|Z0063-0^^LN||2093467^Smits^J^<cr> OBX||Z0092-0^^LN||203BE0004Y^^X12PTX<cr> Data field Data component segment Again, this slide shows a typical order result message. In this case, the segments include the header, the patient identifier, the order request, and two result segments. The OBX segment is examined in detail in the next slide. The last OBX shows the hierarchical nature of the segment. The test ID data field is broken into the triplet of code (with check-digit), text name, and vocabulary source (LOINC). Slide reproduced/adapted from Dr. Supachai Parchariyanon
  37. 37. 37 Summary Slide reproduced/adapted from Dr. Supachai Parchariyanon
  38. 38. 38 Admit Discharge Transfer (ADT) MSH Message Header Segment [ EVN Event type segment PID Patient Identification segment PV1 Patient Visit segment [PV2] Patient Visit – Additional Information [{OBX}] Observation/Result ] Slide reproduced/adapted from Dr. Supachai Parchariyanon
  39. 39. 39 RULES Slide reproduced/adapted from Dr. Supachai Parchariyanon
  40. 40. 40 ADT event types ADT^A13 Cancel discharge/end visit ADT^A04 Register a patient ADT^A08 Update patient information ADT^A01 Admit/visit notification ADT^A02 Transfer a patient ADT^A03 Discharge/end visit ADT^A28 Add person information ADT^A14 Pending admit ADT^A05 Pre-admit a patient ADT^A31 Update person information ADT^A07 Change an inpatient to an outpatient ADT^A06 Change an outpatient to an inpatient ADT^A11 Cancel admit/visit notification ADT^A10 Patient arriving – tracking ADT^A09 Patient departing - tracking ADT^A12 Cancel transfer ADT^A15 Pending transfer ADT^A16 Pending discharge ADT^A17 Swap patients ADT^A18 Merge patient information (for backward compatibility only) ADT^A20 Bed status update ADT^A32 Cancel patient arriving - tracking ADT^A33 Cancel patient departing - tracking ADT^A27 Cancel pending admit ADT^A25 Cancel pending discharge ADT^A26 Cancel pending transfer ADT^A23 Delete a patient record ADT^A29 Delete person information ADT^A21 Patient goes on a "leave of absence" ADT^A22 Patient returns from a "leave of absence" ADT^A24 Link patient information ADT^A35 Merge patient information - account number only (for backward compatibility only) ADT^A36 Merge patient information - patient ID and account number ADT^A34 Merge patient information - patient ID only (for backward compatibility only) ADT^A30 Merge person information (for backward compatibility only) ADT^A48 Change alternate patient ID (for backward compatibility only) ADT^A49 Change patient account number ADT^A46 Change patient ID (for backward compatibility only) ADT^A47 Change patient identifier list ADT^A37 Unlink patient information ADT^A38 Cancel pre-admit ADT^A41 Merge account - patient account number ADT^A40 Merge patient - patient identifier list ADT^A39 Merge person - patient ID (for backward compatibility only) ADT^A42 Merge visit - visit number ADT^A44 Move account information - patient account number ADT^A43 Move patient information - patient identifier list ADT^A45 Move visit information - visit number ADT^A51 Change alternate visit ID ADT^A50 Change visit number ADT^A52 Cancel leave of absence for a patient ADT^A53 Cancel patient returns from a leave of absence ADT^A55 Cancel change attending doctor ADT^A54 Change attending doctor ADT^A60 Update allergy information ADT^A62 Cancel change consulting doctor ADT^A61 Change consulting doctor Slide reproduced/adapted from Dr. Supachai Parchariyanon
  41. 41. 41 Example message (ORU) MSH|^~&|HCLAB||HIS||20110826000629||ORU^R01|HCL0004461303|P|2.3||||||8859<cr> PID|1||4552213||^นาย เสมอ ใจดี||196404090000|M<cr> OBR|1|15817060|110524242|250034^Prothrombin time|U|20110825214807|||||||| 20110825230321||008850^บดีภัทร วรฐิติอนันต์||OER101^ทั่วไป แผนกผูป้่วยฉุกเฉิน อาคารฉุกเฉิน ชัน้ 1||||20110826000629||||||OER101^ทั่วไป แผนกผูป้่วยฉุกเฉิน อาคารฉุกเฉิน ชัน้ 1|||LISREPORT2011082520110825_25110524242.htm<cr> NTE|1||.br*อื่นๆ.brSpecimen Clotted โทรแจง้ เวลา 23.52 น. คุณ วิชุดา รับสาย<cr> OBX|1|ST|250539^PT||*|sec|10.5 - 13.5|N|||C|||20110826000146|LAR0101^หน่วยโลหิต วิทยา|002108^อนุชา สรอ้ยสำโรง<cr> OBX|2|ST|250540^% Activity||*|%|70.0 - 120.0|N|||C|||20110826000146|LAR0101^หน่วย โลหิตวิทยา|002108^อนุชา สรอ้ยสำโรง<cr> OBX|3|ST|250541^INR||*||0.91 - 1.17|N|||C|||20110826000146|LAR0101^หน่วยโลหิต วิทยา|002108^อนุชา สรอ้ยสำโรง<cr> Slide reproduced/adapted from Dr. Supachai Parchariyanon
  42. 42. 42 Problems with HL7v2 • HL7 v2 cannot support all this! – Ad Hoc design methodology – Ambiguous – lacking definition – Complicated, esoteric encoding rules. – Artifacts left to retain backward compatibility – Too much optionality – Can’t specify conformance – No standard vocabulary Slide reproduced/adapted from Dr. Supachai Parchariyanon
  43. 43. 43 What’s Different About v3? • Conceptual foundation – A single, common reference information model to be used across HL7 • Semantic foundation – Explicitly defined concept domains drawn from the best terminologies • Abstract design methodology – That is technology-neutral – Able to be used with whatever is the technology de jour • XML, UML, etc. • Maintain a repository – Database of the semantic content – Ensures a single source and enable development of support tooling Slide reproduced/adapted from Dr. Supachai Parchariyanon
  44. 44. 44 How is v3 different than v2? • v3 is approaching “Plug and Play” • v2 uses pipe and hat messaging, while v3 uses the Reference Information Model(RIM) and XML for messaging • v3 is a brand new start – it is NOT backward compatible with v2 Slide reproduced/adapted from Dr. Supachai Parchariyanon
  45. 45. 45 HL7 V3 Standards • A family of standards based on V3 information models and development methodology • Components – HL7 V3 Reference Information Model (RIM) – HL7 V3 Messaging – HL7 Development Framework (HDF)
  46. 46. 46 How HL7 V3 Works • Message sent from sending application to receiving application • Mostly triggered by an event • Typical scenario portrayed in a storyboard • Message in XML with machine-processable elements conforming to messaging standard • Data elements in message conform to RIM • Not designed for human readability
  47. 47. 47 v3 Messaging Standard • Based on an object information model, called the Reference Information Model, (RIM) – This model is “abstract,” that is, it is defined without regard to how it is represented in a message “on the wire” or in a “service architecture” method or in a “clinical document” – In fact, each of these representations can contain the same “instance” of information • Consequently, can be extended incrementally when new clinical information domains need to be added, in a way that doesn’t require changing what has already been created Slide reproduced/adapted from Dr. Supachai Parchariyanon
  48. 48. 48 Why Cross-Reference to the RIM? • Domain analysis models support communication within a domain • Communications between domains requires an abstract, domain-independent model such as the HL7 RIM • Cross-reference tables build the mappings from the narrow world of the individual domain to the cross-domain interoperability supported by the HL7 RIM Slide reproduced/adapted from Dr. Supachai Parchariyanon
  49. 49. 49 HL7 V3 Messaging • V3 provides messaging standards for – Patient administration – Medical records – Orders – Laboratory – Claims & Reimbursement – Care provision – Clinical genomics – Public Health – Etc.
  50. 50. 50 Sample HL7 v.3 Message (Patient Registration) <?xml version="1.0" encoding="UTF-8"?> <PRPA_IN101311UV02 xmlns="urn:hl7-org:v3" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" ITSVersion="XML_1.0" xsi:schemaLocation="urn:hl7-org:v3 ../schemas/PRPA_IN101311UV02.xsd"> ... <name use="SYL" > <given>นวนรรน</given> <family>ธีระอมัพรพนัธุ์</family> </name> <name use="ABC"> <given>Nawanan</given> <family>Theera-Ampornpunt</family> </name> <administrativeGenderCode code="M"/> ... </PRPA_IN101311UV02> Message source adapted from Ramathibodi HL7 Project by Supachai Parchariyanon, Kavin Asavanant, Sireerat Srisiriratanakul & Chaiwiwat Tongtaweechaikit
  51. 51. 51 HL7 v3 Reference Information Model Act Relationship • Referral • Transportation • Supply • Procedure • Consent • Observation • Medication • Administrative act • Financial act • Organization • Place • Person • Living Subject • Material • Has component • Is supported by 0..* 1 • Patient • Member • Healthcare facility • Practitioner • Practitioner assignment • Specimen • Location Entity 0..* 1 Role 1 0..* 1 0..* 1..* 1 Participation Act • Author • Reviewer • Verifier • Subject • Target • Tracker Slide reproduced/adapted from Dr. Supachai Parchariyanon
  52. 52. 52 HL7 v3 Components and Process: RIM UML Instance Scenario Entity Role Participation Act John Doe Patient Subject Dr. Smith  Classes are color coded:  Green = Entity, Yellow = Role, Blue = Participation, Red/Pink = Act, Purple = Infrastructure, Lilac = message controller. HealthCare Provider Surgeon John Doe Patient Subject Has Pertinent Act Relationship Information (Clinical Trial Act) Protocol ECOG 1112 XYZ Hospital HealthCare Facility Location (Procedure Act) Prostectomy Slide reproduced/adapted from Dr. Supachai Parchariyanon
  53. 53. 53 Reference Information Model (RIM) 53
  54. 54. 54 Source: “What is CDA R2? by Calvin E. Beebe at HL7 Educational Summit in July 2012
  55. 55. 55 The HL7 v3 Solution • Approaching “Plug and Play” - less of a “framework for negotiation” • Utilizes RIM for data model • Utilizes XML as transport method • HL7v3 is not the next release of HL7v2 - It is a paradigm shift Slide reproduced/adapted from Dr. Supachai Parchariyanon
  56. 56. 56 The HL7 v3 Solution (Cont.) • HL7v3 addresses the problems of HL7v2 by: – Reducing HL7v2 optionality – Including testable conformance rules • HL7v3 is based on a formal development methodology: – Follows an Object Oriented (OO) approach – Uses Universal Modeling Language (UML) principles • Most importantly, HL7v3 supports semantic interoperability Slide reproduced/adapted from Dr. Supachai Parchariyanon
  57. 57. 57 Interoperability in HL7 v3 • The Four Pillars of Semantic Interoperability in HL7v3 – A common Reference Information Model (RIM) which spans the entire patient care, administrative and financial healthcare universe – A well-defined and tool-supported process for deriving data exchange specifications ("messages") from the RIM – A formal and robust Data Type Specification upon which to ground the RIM – A formal methodology for binding concept-based terminologies (vocabulary) to RIM attributes Slide reproduced/adapted from Dr. Supachai Parchariyanon
  58. 58. 58 HL7 Development Framework • Formal methodology for mapping any “local”, domain - specific system, such as a “laboratory system” in the v3 Reference model. • Basic concept is that any system can be mapped into a “neutral” and formal UML-based Domain Analysis Model (DAM) with the help of domain experts. • The DAM can then be mapped into the equivalent v3- RIM model. • Mapping is bi-directional and highlights any changes needed by either the local system or the RIM to create a semantically complete mapping. • RIM Harmonization process supports a standard way to add new domain requirements to the RIM in a way that doesn’t invalidate the previously created models – a feature of object-oriented paradigms. 58
  59. 59. 59 Model-based Development HL7 Framework HL7 Specification RIM Data types Data elements Vocabulary Templates Clinical Statements Core Structured Content V3 Messaging CDA Specifications GELLO System Oriented Architecture Slide reproduced/adapted from Dr. Supachai Parchariyanon
  60. 60. 60 HL7 Model Repository • Database holding the core of HL7 semantic specifications – RIM – Storyboards – Vocabulary domains – Interaction models – Message designs – Message constraints Slide reproduced/adapted from Dr. Supachai Parchariyanon
  61. 61. 61 HL7 Version 3.0 • Use-case Model • Reference Information Model • Domain Information Model • Message Information Model • Message Object Diagram • Hierarchical Message Description • Common Message Element Type Slide reproduced/adapted from Dr. Supachai Parchariyanon
  62. 62. Slide reproduced/adapted from Dr. Supachai Parchariyanon 62
  63. 63. 63 Domain Document Elements Slide reproduced/adapted from Dr. Supachai Parchariyanon
  64. 64. 64 Example: HL7 v3 Slide reproduced/adapted from Dr. Supachai Parchariyanon
  65. 65. Slide reproduced/adapted from Dr. Supachai Parchariyanon 65
  66. 66. 66 Navigating the V3 Ballot Publication Slide reproduced/adapted from Dr. Supachai Parchariyanon
  67. 67. 67 Navigating the V3 Ballot Publication • Domains: The Functional Content of the Publication – Universal Realm Domains • Administration Domains • Health and Clinical Practice Domains • Common Use Domains – US Realm domains • Medicaid Information Technology Architecture (MITA) – Other realm specific domains.. Slide reproduced/adapted from Dr. Supachai Parchariyanon
  68. 68. 68 Domain Publication Structure Each Realm contains a collection of Domains. Domains are further divided into Topics • Domain • Topic Slide reproduced/adapted from Dr. Supachai Parchariyanon
  69. 69. 69 V3 Messaging Concerns • Difficult to implement • No one understands v3 • Overhead too much – 1% of message is payload compared to v2 (delimiters) is about 90-95% • No one understands what implementation of v3 messaging means • Need stability, clarity, definition of v3 messaging Slide reproduced/adapted from Dr. Supachai Parchariyanon
  70. 70. 70 The Future of HL7 • FHIR: Fast Healthcare Interoperability Resources – Pronounced “Fire” • FHIR defines a set of “Resources” that represent granular clinical concepts, which can be managed in isolation, or aggregated into complex documents • Resources are based on simple XML or JSON structures, with an http-based RESTful protocol http://wiki.hl7.org/index.php?title=FHIR
  71. 71. 71 Additional Information • Health Level Seven – www.hl7.org • HL7 Reference Information Model – https://www.hl7.org/library/data-model/RIM/C30202/rim.htm • HL7 Vocabulary Domains – http://www.hl7.org/library/data-model/ RIM/C30123/vocabulary.htm • HL7 v3 Standard – http://www.hl7.org/v3ballot/html/welcome/environment/index.htm • HL7v3: – “Driving Interoperability & Transforming Healthcare Information Management” by Charles Mead, MD, MSc. – http://www.healthcare-informatics.com/webinars/05_20_04.htm Slide reproduced/adapted from Dr. Supachai Parchariyanon
  72. 72. 72 Assignment 1 1._______ messaging standard is easy to use and understand. It is based on an implicit information model. 1. HL7 v3.n 2. DICOM v2.n 3. XML v3.n 4. HL7 v2.n 2.HL7 message are composed of reusable segments, each identified by a __ -letter mnemonic. 1. 2 2. 3 3. 4 4. 5 Slide reproduced/adapted from Dr. Supachai Parchariyanon
  73. 73. 73 Assignment 1 3. In the HL7 transaction model a(n) _____ occurs and activates the sending of a specific message type to one or more receivers. 1. Acknowledgement 2. Interface 3. Trigger event 4. message 4.___________ is the exclusive international standards body for imaging standards. 1. XML 2. NCPDP 3. DICOM 4. IEEE Slide reproduced/adapted from Dr. Supachai Parchariyanon
  74. 74. 74 Assignment 1 5. ___________ creates standards for pharmacy services. 1. X12N 2. NCPDP 3. DICOM 4. IEEE 6. _________ is the standards developing organization that focuses primarily on device standards. 1. X12N 2. NCPDP 3. DICOM 4. IEEE Slide reproduced/adapted from Dr. Supachai Parchariyanon
  75. 75. 75 Assignment 1 7. ______ has developed standards for the exchange of purchase-order data, invoice data and other commonly used business documents. 1. X12N 2. NCPDP 3. DICOM 4. IEEE 8.________ based on an object information model, called the Reference Information Model, (RIM), Patient Records. 1. HL7 v3 2. DICOM v2.n 3. XML v3.n 4. HL7 v2.n Slide reproduced/adapted from Dr. Supachai Parchariyanon
  76. 76. 76 Assignment 1: Key 1._______ messaging standard is easy to use and understand. It is based on an implicit information model. 1. HL7 v3.n 2. DICOM v2.n 3. XML v3.n 4. HL7 v2.n 2.HL7 message are composed of reusable segments, each identified by a __ -letter mnemonic. 1. 2 2. 3 3. 4 4. 5 Slide reproduced/adapted from Dr. Supachai Parchariyanon
  77. 77. 77 Assignment 1: Key 3. In the HL7 transaction model a(n) _____ occurs and activates the sending of a specific message type to one or more receivers. 1. Acknowledgement 2. Interface 3. Trigger event 4. message 4.___________ is the exclusive international standards body for imaging standards. 1. XML 2. NCPDP 3. DICOM 4. IEEE Slide reproduced/adapted from Dr. Supachai Parchariyanon
  78. 78. 78 Assignment 1: Key 5. ___________ creates standards for pharmacy services. 1. X12N 2. NCPDP 3. DICOM 4. IEEE 6. _________ is the standards developing organization that focuses primarily on device standards. 1. X12N 2. NCPDP 3. DICOM 4. IEEE Slide reproduced/adapted from Dr. Supachai Parchariyanon
  79. 79. 79 Assignment 1: Key 7. ______ has developed standards for the exchange of purchase-order data, invoice data and other commonly used business documents. 1. X12N 2. NCPDP 3. DICOM 4. IEEE 8.________ is based on an object information model, called the Reference Information Model, (RIM). 1. HL7 v3 2. DICOM v2.n 3. XML v3.n 4. HL7 v2.n Slide reproduced/adapted from Dr. Supachai Parchariyanon
  80. 80. 80 Assignment 2 “READING AN ADT MESSAGE” For the Message: MSH|^~&|ADT_HGG||LAB_HGG||20090827120759||ADT^A01^ADT_A01|ADT_HG G00234509|P|2.6||||AL<cr> EVN||20090827120759<cr> PID|1||60719^^^HGG_ID^MR||EVERYWOMAN ^EVE||19780113100000|F|||2222 HOME STREET ^^ ANN ARBOR^MI^48104^USA <cr> NK1|1|KID^KEN|SPO|2222 HOME STREET^^ ANN ARBOR^MI^48104^USA |555-555- 2005 <cr> PV1|1|I|23^GHH ROOM 2341^2341|U|||1436^ ATTEND^AARON|1026^SENDER^SAM||MED||||9|A0||1026^ADMIT^ALAN||H010 0240|||||||||||||||||||||||||20090827120759<cr> IN1|1|CPS|HGG| HC Hospital General Gold, INC. |5555 WASHTEOLD AVENUE^SUITE 2333^ ANN ARBOR^MI^48104^USA||555-555- 3002||||||||||||||||||||||||||||||||||||||||||444-22-2222 <cr> Slide reproduced/adapted from Dr. Supachai Parchariyanon
  81. 81. 81 Assignment 2 ASSIGNMENT 2 - “READING AN ADT MESSAGE” For the Message: 1: What type of message is it, and what is it used for? Who sent the message and when? 2: Who is the patient’s insurance company? Where is the insurer located? 3: What is the patient ID? Which is the personal relationship that the next of kin/associated party has to the patient? What is her name? What is the phone number of her contact (next of kin)? 4: Which clinicians are involved? Which roles are they playing? How old is the patient? 5: What is the episode or visit number? What is the patient’s last name? 6: Should we answer this message? Which application is expected to receive it? Which is the subcomponent separator? 7: Who is the attending doctor? What is the patient location? Slide reproduced/adapted from Dr. Supachai Parchariyanon
  82. 82. 82 Assignment 2: Key ASSIGNMENT 2 - “READING AN ADT MESSAGE” For the Message: 1: What type of message is it (ADT^A01^ADT_A01,), and what is it used for?(Admit Visit Notification) Who sent the message and when? (ADT_HGG) at 20090827, 120759 2: Who is the patient’s insurance company? Where is the insurer located? CPS, 5555 WASHTEOLD AVENUE^SUITE 2333^ ANN ARBOR^MI^48104^USA 3: What is the patient ID? 60719 Which is the personal relationship that the next of kin/associated party has to the patient? SPO What is her name? KID^KEN What is the phone number of her contact (next of kin)? 555-555- 2005 Slide reproduced/adapted from Dr. Supachai Parchariyanon
  83. 83. 83 Assignment 2: Key 4: Which clinicians are involved? Which roles are they playing? How old is the patient? AARON-ATTENDING, ALAN-ADMIT, 31 5: What is the episode or visit number? 1436 (Segment 19) What is the patient’s last name? EVERYWOMAN 6: Should we answer this message? YES Which application is expected to receive it? LAB_HGG Which is the subcomponent separator? & 7: Who is the attending doctor? AARON-ATTENDING What is the patient location? GHH ROOM 2341 Slide reproduced/adapted from Dr. Supachai Parchariyanon
  84. 84. 84 HL7 Reference Information Model (RIM) Nawanan Theera-Ampornpunt, M.D., Ph.D. Department of Community Medicine Faculty of Medicine Ramathibodi Hospital Certified HL7 CDA Specialist Some slides reproduced & adapted with permission from Dr. Supachai Parchariyanon October 11, 2014
  85. 85. 85 Outline • Reference Information Model (RIM) – Overview – RIM Domains – Domain Related Classes – Backbone Classes – HL7 v3 Process & Artifacts Overview – Data Types Slide reproduced/adapted from Dr. Supachai Parchariyanon
  86. 86. 86 Reference Information Model • The RIM is the cornerstone of HL7 v3 messaging. • The RIM is an UML Model class diagram. • The RIM: – Is the fundamental model from which all v3 messages are derived – Is a generic, abstract model that expresses the information content of all the areas of healthcare – Forms a shared view of the healthcare domain, and is used across all HL7 messages independent of message structure Slide reproduced/adapted from Dr. Supachai Parchariyanon
  87. 87. 87 RIM - Domain Related Classes Slide reproduced/adapted from Dr. Supachai Parchariyanon
  88. 88. 88 RIM Backbone Classes Entity Role Participation Act A physical thing, group of physical things or an organization capable of participating in Acts, while in a role. A record of something that is being done, has been done, can be done, or is intended or requested to be done. A competency of the Entity playing the Role as identified, defined, guaranteed, or acknowledged by the Entity that Scopes the Role. An association between an Act and a Role with an Entity playing that Role. Each Entity (in a Role) involved in an Act in a certain way is linked to the act by one Participation-instance. 1 Role Link Act Relationship A connection between two roles expressing a dependency between those roles. A directed association between a source act and a target act. 0..n 1 0..n 0..n 0..1 0..n 0..n 0..n 0..n 0..n 0..1 Classes are color coded: – Green = Entity, Yellow = Role, Blue = Participation, Red/Pink = Act, Purple = Infrastructure, Lilac = message controller. Slide reproduced/adapted from Dr. Supachai Parchariyanon
  89. 89. 89 RIM as an Abstract Model • The RIM is comprised of six “back-bone” classes: – Act: which represents the actions that are executed and must be documented as health care is managed and provided – Participation: which expresses the context for an act in terms such as who performed it, for whom it was done, where it was done – Entity: which represents the physical things and beings that are of interest to, and take part in health care Slide reproduced/adapted from Dr. Supachai Parchariyanon
  90. 90. 90 RIM as an Abstract Model – Role: which establishes the roles that entities play as they participate in health care acts – ActRelationship: which represents the binding of one act to another, such as the relationship between an order for an observation and the observation event as it occurs – RoleLink: which represents relationships between individual roles Slide reproduced/adapted from Dr. Supachai Parchariyanon
  91. 91. 91 HL7 v3 Components and Process: RIM UML Instance Scenario Entity Role Participation Act John Doe Patient Subject Dr. Smith  Classes are color coded:  Green = Entity, Yellow = Role, Blue = Participation, Red/Pink = Act, Purple = Infrastructure, Lilac = message controller. HealthCare Provider Surgeon John Doe Patient Subject Has Pertinent Act Relationship Information (Clinical Trial Act) Protocol ECOG 1112 XYZ Hospital HealthCare Facility Location (Procedure Act) Prostectomy Slide reproduced/adapted from Dr. Supachai Parchariyanon
  92. 92. 92 RIM Entity Classes Slide reproduced/adapted from Dr. Supachai Parchariyanon
  93. 93. 93 RIM Entity Classes Entity classCode : CS determinerCode : CS id : SET<II> code : CE quantity : SET<PQ> name : BAG<EN> desc : ED statusCode : SET<CS> existenceTime : IVL<TS> telecom : BAG<TEL> riskCode : CE handlingCode : CE • Entity: – a person, animal, organization or thing – A collection of classes related to the Entity class, its specializations and related qualifying classes. The classes represent health care stakeholders and other things of interest to health care. • Entity has the following sub-classes: – Container – Device – LanguageCommunication – LivingSubject – ManufacturedMaterial – Material – NonPersonLivingSubject – Organization – Person – Place Slide reproduced/adapted from Dr. Supachai Parchariyanon
  94. 94. 94 RIM Entity Classes: How to Read Entity classCode : CS determinerCode : CS id : SET<II> code : CE quantity : SET<PQ> name : BAG<EN> desc : ED statusCode : SET<CS> existenceTime : IVL<TS> telecom : BAG<TEL> riskCode : CE handlingCode : CE • Entity: • Class name : Entity • Attributes : classCode, determinerCode, id, etc. • Data type : immediately follows the attribute name • Specializaton : LivingSubject and Place are specializations of Entity In other words, we would treat LivingSubject as an Entity with additional attributes. Slide reproduced/adapted from Dr. Supachai Parchariyanon
  95. 95. 95 RIM Entity Classes : How to Read Entity classCode : CS determinerCode : CS id : SET<II> code : CE quantity : SET<PQ> name : BAG<EN> desc : ED statusCode : SET<CS> existenceTime : IVL<TS> telecom : BAG<TEL> riskCode : CE handlingCode : CE Slide reproduced/adapted from Dr. Supachai Parchariyanon
  96. 96. 96 RIM Entity Classes : How to Read Entity classCode : CS determinerCode : CS id : SET<II> code : CE quantity : SET<PQ> name : BAG<EN> desc : ED statusCode : SET<CS> existenceTime : IVL<TS> telecom : BAG<TEL> riskCode : CE handlingCode : CE Slide reproduced/adapted from Dr. Supachai Parchariyanon
  97. 97. 97 RIM Role Classes Slide reproduced/adapted from Dr. Supachai Parchariyanon
  98. 98. 98 RIM Role Classes • Roles: – A responsibility or part played by an entity (e.g. Person in a role of patient, employee, etc.) – different faces of an Entity – A collection of classes related to the Role class and its specializations. These classes focus on the roles participants may play in health care.. • Role has the following sub‐classes: – Access – Employee – LicensedEntity – Patient – Health Care Provider – Member Role classCode : CS id : SET<II> code : CE negationInd : BL addr : BAG<AD> telecom : BAG<TEL> statusCode : SET<CS> effectiveTime : IVL<TS> certificateText : ED quantity : RTO positionNumber : LIST<INT> Slide reproduced/adapted from Dr. Supachai Parchariyanon
  99. 99. 99 RIM Participation and Act Classes Slide reproduced/adapted from Dr. Supachai Parchariyanon
  100. 100. 100 RIM Participation Class • Participation: – An association between an Act and a Role with an Entity playing that Role. • Participation has the following sub-class: – ManagedParticipation Participation typeCode : CS functionCode : CD contextControlCode : CS sequenceNumber : INT negationInd : BL noteText : ED time : IVL<TS> modeCode : CE awarenessCode : CE signatureCode : CE signatureText : ED performInd : BL substitutionConditionCode : CE Slide reproduced/adapted from Dr. Supachai Parchariyanon
  101. 101. 101 RIM Act Class • Act: – A collection of classes including the Act class and its specializations. These relate to the actions and events that constitute health care services. A record of something that is being done, has been done, can be done, or is intended or requested to be done. • Act has the following sub-classes: – Account – ControlAct – DeviceTask – DiagnosticImage – Diet – FinancialContract – FinancialTransaction – InvoiceElement Act classCode : CS moodCode : CS id : SET<II> code : CD negationInd : BL derivationExpr : ST text : ED title : ST statusCode : SET<CS> effectiveTime : GTS activityTime : GTS availabilityTime : TS priorityCode : SET<CE> confidentialityCode : SET<CE> repeatNumber : IVL<INT> interruptibleInd : BL levelCode : CE independentInd : BL uncertaintyCode : CE reasonCode : SET<CE> languageCode : CE Slide reproduced/adapted from Dr. Supachai Parchariyanon
  102. 102. 102 RIM ActRelationship Class • ActRelationship: – A directed association between a source Act and a target Act. A point from a later instance to a earlier instance OR point from collector instance to component instance. • ActRelationship has no sub-classes. ActRelationship typeCode : CS inversionInd : BL contextControlCode : CS contextConductionInd : BL sequenceNumber : INT priorityNumber : INT pauseQuantity : PQ checkpointCode : CS splitCode : CS joinCode : CS negationInd : BL conjunctionCode : CS localVariableName : ST seperatableInd : BL inboundRelationship Act 0..n 0..n source 0..n target 1 outboundRelationship Slide reproduced/adapted from Dr. Supachai Parchariyanon
  103. 103. 103 HL7 v3 Process & Artifacts Overview RIM DMIM RMIM 1..* 1..* MT HMD 1..* 1..* Slide reproduced/adapted from Dr. Supachai Parchariyanon
  104. 104. 104 Domain Message Information Model (DMIM) • A DMIM is a refined subset of the RIM that includes a set of class clones, attributes and relationships that can be used to create messages for a particular domain (a particular area of interest in healthcare). • This is the DMIM for the Patient Administration Domain Slide reproduced/adapted from Dr. Supachai Parchariyanon
  105. 105. 105 Refined Message Information Model (RMIM) • The RMIM is a subset of a DMIM that is used to express the information content for a message or set of messages with annotations and refinements that are message specific. • This is the RMIM for the PatientLivingSubject Event Activate Slide reproduced/adapted from Dr. Supachai Parchariyanon
  106. 106. 106 Hierarchical Message Definition (HMD) • An HMD is a serialized version of the RMIM in a specific order. • This is the HMD for the PatientLivingSubject Event Activate Slide reproduced/adapted from Dr. Supachai Parchariyanon
  107. 107. 107 Message Type (MT)  A Message specification is a set of rules for constructing a message given a specific set of instance data  This is the XML schema for the PatientLivingSubject Event Activate message Slide reproduced/adapted from Dr. Supachai Parchariyanon
  108. 108. 108 Data Types • Symbol: TS • Name: Point in Time • Description: A quantity specifying a point on the axis of natural time. A point in time is most often represented as a calendar expression. Slide reproduced/adapted from Dr. Supachai Parchariyanon
  109. 109. 109 Data Types • Symbol: ANY • Name: DataValue • Description: Defines the basic properties of every data value. This is an abstract type, meaning that no value can be just a data value without belonging to any concrete type. Every concrete type is a specialization of this general abstract DataValue type. Slide reproduced/adapted from Dr. Supachai Parchariyanon
  110. 110. 110 Data Types • Symbol: BL • Name: Boolean • Description: The Boolean type stands for the values of two-valued logic. A Boolean value can be either true or false, or, as any other value may be NULL. Slide reproduced/adapted from Dr. Supachai Parchariyanon
  111. 111. 111 Data Types • Symbol: BN • Name: Boolean not NULL • Description: The Boolean type stands for the values of two-valued logic. A Boolean value can be either true or false, but can not be NULL. Slide reproduced/adapted from Dr. Supachai Parchariyanon
  112. 112. 112 Data Types • Symbol: ST • Name: Character String • Description: The character string data type stands for text data, primarily intended for machine processing (e.g., sorting, querying, indexing, etc.) Used for names, symbols, and formal expressions. Slide reproduced/adapted from Dr. Supachai Parchariyanon
  113. 113. 113 Data Types • Symbol: CS • Name: Coded Simple Value • Description: Coded data in its simplest form, where only the code and display name is not predetermined. The code system and code system version is fixed by the context in which the CS value occurs. CS is used for coded attributes that have a single HL7-defined value set. Slide reproduced/adapted from Dr. Supachai Parchariyanon
  114. 114. 114 Data Types • Symbol: CE • Name: Coded With Equivalents • Description: Coded data that consists of a coded value (CV) and, optionally, coded value(s) from other coding systems that identify the same concept. Used when alternative codes ma exist. Slide reproduced/adapted from Dr. Supachai Parchariyanon
  115. 115. 115 Data Types • Symbol: SC • Name: Character String with Code • Description: A Character String that optionally may have a code attached. The text must always be present if a code is present. The code is often a local code. Slide reproduced/adapted from Dr. Supachai Parchariyanon
  116. 116. 116 Data Types • Symbol: II • Name: Instance Identifier • Description: An identifier that uniquely identifies a thing or object. Examples are object identifier for HL7 RIM objects, medical record number, order id, service catalog item id, Vehicle Identification Number (VIN), etc. Instance identifiers are defined based on ISO object identifiers. Slide reproduced/adapted from Dr. Supachai Parchariyanon
  117. 117. 117 Data Types • Symbol: SET • Name: Set • Description: A value that contains other distinct values in no particular order. Slide reproduced/adapted from Dr. Supachai Parchariyanon
  118. 118. 118 Data Types • Symbol: BAG • Name: Bag • Description: An unordered collection of values, where each value can be contained more than once in the bag, i.e., {a,a,b,c} Slide reproduced/adapted from Dr. Supachai Parchariyanon
  119. 119. 119 Data Types • Symbol: IVL • Name: Interval • Description: A set of consecutive values of an ordered base data type. Slide reproduced/adapted from Dr. Supachai Parchariyanon
  120. 120. 120 Data Types • Symbol: ED • Name: Encapsulated Data • Description: Allows the transmission of text of pointer to a text (for instance an URL) Slide reproduced/adapted from Dr. Supachai Parchariyanon
  121. 121. 121 Q/A Slide reproduced/adapted from Dr. Supachai Parchariyanon
  122. 122. 122 HL7 Clinical Document Architecture (CDA) Nawanan Theera-Ampornpunt, M.D., Ph.D. Department of Community Medicine Faculty of Medicine Ramathibodi Hospital Certified HL7 CDA Specialist Some slides reproduced & adapted with permission from Dr. Supachai Parchariyanon October 11, 2014
  123. 123. 123 Exchange Standards Message Exchange • Goal: Specify format for exchange of data • Internal vs. external messages • Examples  HL7 v.2  HL7 v.3 Messaging  DICOM  NCPDP Document Exchange • Goal: Specify format for exchange of “documents” • Examples  HL7 v.3 Clinical Document Architecture (CDA)  ASTM Continuity of Care Record (CCR)  HL7 Continuity of Care Document (CCD)
  124. 124. 124 Exchange Standards Messages • Human Unreadable • Machine Processable Clinical Documents • Human Readable • (Ideally) Machine Processable
  125. 125. 125 Message Exchange Message Message Hospital A Hospital B Clinic C Government Lab Patient at Home Message Message Message
  126. 126. 126 Clinical Document Exchange Message containing Referral Letter Message containing Claims Request Message containing Communicable Disease Report Hospital A Hospital B Clinic C Government Lab Patient at Home Message containing Lab Report Message containing Patient Visit Summary
  127. 127. 127 What Is HL7 CDA? • “A document markup standard that specifies structure & semantics of “clinical documents” for the purpose of exchange” [Source: HL7 CDA Release 2] • Focuses on document exchange, not message exchange • A document is packaged in a message during exchange • Note: CDA is not designed for document storage. Only for exchange!!
  128. 128. 128 What is CDA? • CDA is based on XML • XML is eXtensible Markup Language • In XML, structure & format are conveyed by markup which is embedded into the information Slide reproduced/adapted from Dr. Supachai Parchariyanon
  129. 129. 129 Clinical Documents Slide reproduced/adapted from Dr. Supachai Parchariyanon
  130. 130. Slide reproduced/adapted from Dr. Supachai Parchariyanon 130
  131. 131. 131 A Clinical Document (1) • A documentation of clinical observations and services, with the following characteristics:  Persistence - continues to exist in an unaltered state, for a time period defined by local and regulatory requirements  Stewardship - maintained by an organization entrusted with its care  Potential for authentication - an assemblage of information that is intended to be legally authenticated Source: HL7 CDA R2
  132. 132. 132 A Clinical Document (2) • A documentation of clinical observations and services, with the following characteristics:  Context - establishes the default context for its contents; can exist in non-messaging contexts  Wholeness - Authentication of a clinical document applies to the whole and does not apply to portions of the document without full context of the document  Human readability - human readable Source: HL7 CDA R2
  133. 133. 133 A Clinical Document (3) • A CDA document is a defined & complete information object that can include  Text  Images  Sounds  Other multimedia content Source: HL7 CDA R2
  134. 134. 134 Key Aspects of CDA • CDA documents are encoded in XML  When alternative implementations are feasible, new conformance requirements will be issued • CDA documents derive their machine processable meaning from HL7 RIM and use HL7 V3 Data Types • CDA specification is richly expressive & flexible  Templates can be used to constrain generic CDA specifications Source: HL7 CDA R2
  135. 135. 135 Scope of CDA • Standardization of clinical documents for exchange • Data format of clinical documents outside of exchange context (such as data format used to store clinical documents) is out-of-scope Source: HL7 CDA R2
  136. 136. 136 Scope of CDA • CDA doesn’t specify creation or management of documents and messages related to document management • Instead, HL7 V3 Structured Documents WG provides specifications on standards for document exchange within HL7 V3 messages (where CDA clinical documents can become contents of the messages) Source: HL7 CDA R2
  137. 137. 137 Scope of CDA Lab Report Lab Technician Physician Create document Process & Store document Transmit document CDA
  138. 138. 138 Scope of document content • Clinical content of the documents is defined by the RIM and not by CDA. CDA only standardizes the structure and semantics required to exchange documents. Slide reproduced/adapted from Dr. Supachai Parchariyanon
  139. 139. 139 Goals of CDA (1) • Give priority to delivery of patient care • Allow cost effective implementation across as wide a spectrum of systems as possible • Support exchange of human-readable documents between users, including those with different levels of technical sophistication • Promote longevity of all information encoded according to this architecture Source: HL7 CDA R2
  140. 140. 140 Goals of CDA (2) • Enable a wide range of post-exchange processing applications • Be compatible with a wide range of document creation applications • Promote exchange that is independent of the underlying transfer or storage mechanism • Prepare the design reasonably quickly • Enable policy-makers to control their own information requirements without extension to this specification Source: HL7 CDA R2
  141. 141. Design Principles of CDA (1) • Must be compatible with XML & HL7 RIM • Must be compatible with representations of clinical information arising from other HL7 committees • Technical barriers to use of CDA should be minimized • Specifies representation of instances required for exchange 141 Source: HL7 CDA R2
  142. 142. Design Principles of CDA (2) • Should impose minimal constraints or requirements on document structure and content required for exchange • Must be scalable to accommodate fine-grained markup such as highly structured text & coded data • Document specifications based on CDA (“Implementation Guides”) should accommodate constraints & requirements as supplied by appropriate professional, commercial & regulatory agencies 142 Source: HL7 CDA R2
  143. 143. Design Principles of CDA (3) • Document specifications for document creation & processing, if intended for exchange, should map to this exchange architecture • CDA documents must be human readable using widely-available & commonly-deployed XML-aware 143 browsers & print drivers and a generic CDA style sheet written in a standard style sheet language • Use open standards Source: HL7 CDA R2
  144. 144. 144 CDA & HL7 Messages • Documents complement HL7 messaging specifications • Documents are defined and complete information objects that can exist outside of a messaging context • A document can be a MIME-encoded payload within an HL7 message Source: “What is CDA R2? by Calvin E. Beebe at HL7 Educational Summit in July 2012
  145. 145. 145 CDA & Message Exchange • CDA can be payload (or content) in any kind of message – HL7 V2.x message – HL7 V3 message – EDI ANSI X12 message – IHE Cross-Enterprise Document Sharing (XDS) message • And it can be passed from one kind to another Source: “What is CDA R2? by Calvin E. Beebe at HL7 Educational Summit in July 2012
  146. 146. 146 CDA & Message Exchange Clinical Document (Payload) HL7 V3 Message (Message) HL7 V2 Message (Message) Source: Adapted from “What is CDA R2? by Calvin E. Beebe at HL7 Educational Summit in July 2012
  147. 147. 147 CDA As Payload Source: From “What is CDA R2? by Calvin E. Beebe at HL7 Educational Summit in July 2012
  148. 148. 148 MIME • Multipurpose Internet Mail Extensions • An Internet standard that extends the format of e-mail to support – Text in non-ASCII character sets – Non-text attachments – Message bodies with multiple parts – Etc. • Often used in e-mails & some HTTP data • Encoding: e.g. base64 (converting bits into 64 ASCII characters Source: http://en.wikipedia.org/wiki/MIME
  149. 149. 149 Base64 Encoding • TWFuIGlzIGRpc3Rpbmd1aXNoZWQsIG5vdCBvbmx5IGJ 5IGhpcyByZWFzb24sIGJ1dCBieSB0aGlzIHNpbmd1bG FyIHBhc3Npb24gZnJvbSBvdGhlciBhbmltYWxzLCB3a GljaCBpcyBhIGx1c3Qgb2YgdGhlIG1pbmQsIHRoYXQg YnkgYSBwZXJzZXZlcmFuY2Ugb2YgZGVsaWdodCBpbiB 0aGUgY29udGludWVkIGFuZCBpbmRlZmF0aWdhYmxlIG dlbmVyYXRpb24gb2Yga25vd2xlZGdlLCBleGNlZWRzI HRoZSBzaG9ydCB2ZWhlbWVuY2Ugb2YgYW55IGNhcm5h bCBwbGVhc3VyZS4= • Man is distinguished, not only by his reason, but by this singular passion from other animals, which is a lust of the mind, that by a perseverance of delight in the continued and indefatigable generation of knowledge, exceeds the short vehemence of any carnal pleasure. Source: http://en.wikipedia.org/wiki/Base64
  150. 150. Components of CDA Document 150 • CDA = Header + Body • Header – Metadata requires for document discovery, management, retrieval • Body – Section – Entry (machine processable) – Narrative Block (human readable) Source: HL7 CDA R2
  151. 151. 151 XML Markup for CDA • XML tag is defined <tag> • Data is expressed as data element name • Data value is “value” • Each entry has a start tag <tag> and a stop tag /<tag> – <code> code = “11488-4” </code> • Entries may be nested. Slide reproduced/adapted from Dr. Supachai Parchariyanon
  152. 152. 152 Major Components of a CDA • A CDA document is wrapped by the <ClinicalDocument> element, and contains a header and a body. • The header lies between the <ClinicalDocument> and the <StructuredBody> elements and identifies and classifies the document and provides information on authentication, the encounter, the patient, and the involved providers. Slide reproduced/adapted from Dr. Supachai Parchariyanon
  153. 153. 153 Major Components of a CDA Slide reproduced/adapted from Dr. Supachai Parchariyanon
  154. 154. 154 CDA Model Source: From “What is CDA R2? by Calvin E. Beebe at HL7 Educational Summit in July 2012
  155. 155. Human Readable Part Machine Processable Parts 155 A Closer Look at a CDA Document <ClinicalDocument> ... CDA Header ... <structuredBody> <section> <text>... Single Narrative Block ...</text> <observation>...</observation> <substanceAdministration> <supply>...</supply> </substanceAdministration> <observation> <externalObservation>... </externalObservation> </observation> </section> <section> <section>...</section> </section> </structuredBody> </ClinicalDocument> Source: HL7 CDA R2
  156. 156. 156 Rendering CDA Documents (1) Source: From “What is CDA R2? by Calvin E. Beebe at HL7 Educational Summit in July 2012
  157. 157. 157 Rendering CDA Documents (2) Source: From “What is CDA R2? by Calvin E. Beebe at HL7 Educational Summit in July 2012
  158. 158. 158 Rendering CDA Documents (3) • Different recipients may use different style sheets to render the same CDA document, and thus may display it differently (but the same content is presented) • This can help facilitate display of CDA documents with specific preferences or local requirements
  159. 159. Human Readability & Rendering 159 CDA Documents (1) • Receiver of a CDA document can algorithmically display clinical content of the note on a standard Web browser • Sender should not be required to transmit a special style sheet along with a CDA document • Must be possible to render all CDA documents with a single style sheet and general-market display tools • Human readability applies to authenticated content (but no need to render other machine processable parts) Source: HL7 CDA R2
  160. 160. Human Readability & Rendering 160 CDA Documents (2) • When structured content is derived from narrative, there must be a mechanism to describe the process by which machine-processable portions were derived from a block of narrative (e.g. by author, by human coder, by natural language processing algorithm, by specific software) • When narrative is derived from structured content, there must be a mechanism to identify the process by which narrative was generated from structured data Source: HL7 CDA R2
  161. 161. Human Readability & Rendering Text to be rendered 161 CDA Documents (3) <ClinicalDocument> ... CDA Header ... <structuredBody> <section> <text>... Single Narrative Block ...</text> <observation>...</observation> <substanceAdministration> <supply>...</supply> </substanceAdministration> <observation> <externalObservation>... </externalObservation> </observation> </section> <section> <section>...</section> </section> </structuredBody> </ClinicalDocument> Source: HL7 CDA R2
  162. 162. 162 CDA Levels are distinguished by: • Granularity of machine-processible markup • Level One -- Body is human-readable, no semantic codes. • Level Two -- Instances with machine-processible section-level semantics. • Level Three -- Instances that are machine-processible to the extent that can be modeled in the RIM. • All levels validate against the generic CDA schema. Additional validation can be provided by templates and constraints on the generic schema. Slide reproduced/adapted from Dr. Supachai Parchariyanon
  163. 163. 163 Release 1: defined Level One, Level Two only Slide reproduced/adapted from Dr. Supachai Parchariyanon
  164. 164. 164 Release 2: Levels One, Two, Three Slide reproduced/adapted from Dr. Supachai Parchariyanon
  165. 165. 165 Header • Main CDA elements : Header Slide reproduced/adapted from Dr. Supachai Parchariyanon
  166. 166. 166 Body Slide reproduced/adapted from Dr. Supachai Parchariyanon
  167. 167. 167 Body • Preferred non-XML document types: – text/rtf – text/html – text/plain – application/pdf – image/g3fax – image/gif – image/tiff – image/jpeg – image/png Slide reproduced/adapted from Dr. Supachai Parchariyanon
  168. 168. 168 Body – Narrative Text Slide reproduced/adapted from Dr. Supachai Parchariyanon
  169. 169. 169 Body – Narrative Text (Table) Example Result Slide reproduced/adapted from Dr. Supachai Parchariyanon
  170. 170. 170 Body – Narrative Text (List) Example Result Slide reproduced/adapted from Dr. Supachai Parchariyanon
  171. 171. 171 Body –Structured Body (Human Readable) <section> <caption> <captionCode V="11496‐7" S=“LOINC"/> Allergies and Adverse Reactions </caption> <list> <item><content ID=“A1”>Penicillin ‐ Hives</content></item> <item><content>Aspirin ‐ Wheezing</content></item> <item> <content>Codeine – Itching and nausea</content> </item> </list> <coded_entry> <coded_entry.value ORIGTXT=“A1” V="DF‐10074" S=“SNOMED“ DN=“Allergy to Penicillin”/> </coded_entry> </section> Computable Narrative REQUIRED Slide reproduced/adapted from Dr. Supachai Parchariyanon
  172. 172. 172 Body - Structured Body (Machine Processible) <text> <list> <item><content ID="A1">Penicillin – Hives … </list> </text> <entry> <observation classCode="OBS" moodCode="EVN"> <code code="84100007" codeSystem="2.16.840.1.113883.6.96“ codeSystemName="SNOMED CT" displayName="History taking"/> <value xsi:type="CD" code="247472004" codeSystem="2.16.840.1.113883.6.96" displayName="Hives"> <originalText><reference value="#A1"/></originalText> </value> <entryRelationship typeCode="MFST"> <observation classCode="OBS" moodCode="EVN"> <code code="84100007" codeSystem="2.16.840.1.113883.6.96" displayName="History taking"/> <value xsi:type="CD" code="91936005“ CodeSystem="2.16.84…" displayName=“PCN Allergy"/> Computable Narrative OPTIONAL Slide reproduced/adapted from Dr. Supachai Parchariyanon
  173. 173. 173 Entries Structure Body – Machine Processible Slide reproduced/adapted from Dr. Supachai Parchariyanon
  174. 174. 174 Entries - observation Slide reproduced/adapted from Dr. Supachai Parchariyanon
  175. 175. 175 Entries - observation • Derived from the RIM Observation class, it is used to represent coded and other observations Elements: • code: classification of observation • value: observation – can be any data type, need to set that using xsi:type • effectiveTime: observation date/time • moodCode: observation requested (RQO) or produced (EVN) Slide reproduced/adapted from Dr. Supachai Parchariyanon
  176. 176. 176 Entries - observation (Example) Slide reproduced/adapted from Dr. Supachai Parchariyanon
  177. 177. 177 Document & Section Codes • The CDA specification permits the use of document codes and section codes. Thus, it is possible to differentiate a "Consultation Note" from a "Discharge Summary" because the two will have distinct document codes in the document instance. Slide reproduced/adapted from Dr. Supachai Parchariyanon
  178. 178. 178 Rendering Tags <section> <text> <content emphasis="bold"> This is rendered bold, <content emphasis="italics"> this is rendered bold and italicized, </content> this is rendered bold. </content> </text> </section> Slide reproduced/adapted from Dr. Supachai Parchariyanon
  179. 179. 179 Rendering Tags <section> <code code="10153-2" codeSystem="2.16.840.1.113883.6.1“ codeSystemName="LOINC"/> <title>Past Medical History</title> <text> There is a history of <content ID="a1">Asthma</content> </text> <entry> <Observation> <code code="84100007 codeSystem="2.16.840.1.113883.6.96" codeSystemName="SNOMED CT" displayName="history taking (procedure)"/> <value xsi:type="CD" code="195967001" codeSystem="2.16.840.1.113883.6.96" codeSystemName="SNOMED CT" displayName="Asthma"> <originalText> <reference value="#a1"/> </originalText> </value> </Observation> </entry> </section> Slide reproduced/adapted from Dr. Supachai Parchariyanon
  180. 180. XML Markup of CDA Documents • CDA instances are valid against CDA Schema • May be subject to additional validation • No prohibition against multiple schema languages (W3C, DTD, RELAXNG, etc.) as long as conforming instances are compatible 180 Source: HL7 CDA R2
  181. 181. 181 Design Principles of CDA Schema (1) • Design of CDA Schema follows more general requirements for CDA • Follow general V3 XML ITS • CDA Schema is syntactic and not an adequate map between conforming instance and HL7 RIM (semantics) • Semantic interoperability of CDA instances requires CDA Schema, R-MIM & HD and corresponding RIM Source: HL7 CDA R2
  182. 182. 182 Design Principles of CDA Schema (2) • Forward and backward compatibility • Tag names should be clear, human-understandable and map directly to RIM • Vocabulary can be enumerated within CDA Schema or in an external, referenced source. – A vocabulary that is too large or is subject to change should be maintained externally and referenced in CDA Schema • CDA Schema should adhere to requirements of document analysis in derivation of content model Source: HL7 CDA R2
  183. 183. 183 Security, Confidentiality & Data Integrity • Application systems sending and receiving CDA documents are responsible for meeting all legal requirements for – Document authentication – Document confidentiality – Document retention • Encryption & source/recipient authentication may be necessary but is not part of CDA specs • Confidentiality status is available within CDA Source: HL7 CDA R2
  184. 184. 184 CDA Conformance (1) • CDA document originator application is responsible for ensuring that generated CDA documents are fully conformant to this specification • Document recipient is responsible for ensuring that received CDA documents are rendered in accordance to this specification • No persistent storage requirements for CDA documents defined by CDA (out-of-scope) Source: HL7 CDA R2
  185. 185. 185 CDA Conformance (2) Recipient Responsibilities • Assume default values where defined and the document instance doesn’t contain a value • Be able to parse & interpret complete CDA header (but may or may not render header at its discretion) • Parse & interpret CDA body sufficiently to be able to render it (title & narrative block) • Not required to parse & interpret complete set of CDA entries in body • Not required to validate CDA document against referenced templates Source: HL7 CDA R2
  186. 186. 186 CDA Conformance (3) Originator Responsibilities • Properly construct CDA Narrative Blocks – Section label is conveyed in Section.title component (except when unlabeled) – Narrative contents are placed in Section.text (even if also conveyed in machine-processable entries) – Contents of Section.text field must follow rules of Section Narrative Block • Not required to fully encode all narrative into CDA entries within CDA body Source: HL7 CDA R2
  187. 187. 187 CDA & Document Management • CDA focuses on document exchange, not storage or processing • Clinical documents are used for various reasons – Clinical care – Medico-legal reasons (as evidence) – Auditing – Etc. • Clinical documents may contain errors or need data updates (e.g. preliminary lab results vs. final results)
  188. 188. 188 CDA & Document Management • CDA supports appending and replacement of documents through use of Document ID, setID, versionNumber & parent document – Supports version control of documents – Both old (replaced) and new versions of documents can be stored in and retrieved from document management systems depending on situation – Addendum is possible through append – Addendum itself can also be replaced with same version control mechanism – Document management system (not CDA) is responsible for keeping track of most up-to-date documents
  189. 189. 189 Document Management Examples Source: From “What is CDA R2? by Calvin E. Beebe at HL7 Educational Summit in July 2012
  190. 190. 190 CDA Releases • CDA Release 1 (ANSI-approved in 2000) – First specification derived from HL7 RIM • CDA Release 2 (2005) - Current Release – Basic model essentially unchanged from R1 • Document has a header & a body • Body contains nested sections • Sections can be coded using standard vocabularies and can contain entries – Derived from HL7 RIM Version 2.07 Source: HL7 CDA R2
  191. 191. 191 Changes Between CDA R1 & R2 • In CDA R2, both header & body are fully RIM-derived • Much richer assortment of entries to use within CDA sections • R2 enables clinical content to be formally expressed to the extent that it is modeled in RIM • A number of other changes – Deprecated components (retained for backward compatibility) – Changes in some component structure or vocabularies Source: HL7 CDA R2
  192. 192. 192 Some Possible Use Cases of CDA  Intra-institutional  Exchange of parts of medical records (scanned or structured electronic health records)  Lab/Imaging requests & reports  Prescriptions/order forms  Admission notes  Progress notes  Operative notes  Discharge summaries  Payment receipts  Other forms/documents (clinical or administrative)
  193. 193. 193 Some Possible Use Cases of CDA  Inter-institutional  Referral letters  Claims requests or reimbursement documents  External lab/imaging reports  Visit summary documents  Insurance eligibility & coverage documents  Identification documents  Disease reporting  Other administrative reports
  194. 194. 194 Achieving Interoperability  CDA is a general-purpose, broad standard  Use in each use case or context requires implementation guides to constrain CDA  Examples  Operative Note (OP)  Consultation Notes (CON)  Care Record Summary (CRS)  Continuity of Care Document (CCD)  CDA for Public Health Case Reports (PHCRPT)  Quality Reporting Document Architecture (QRDA)
  195. 195. 195 CDA Extensibility  Locally-defined markup possible when local semantics have no corresponding representation in CDA specification  Additional XML elements & attributes that are not included in CDA Schema are permitted in local extensions
  196. 196. 196 CDA Summary  CDA is a markup standard for document exchange  Not message exchange  Not document storage or processing  CDA is a general-purpose standard  Use in specific context requires Implementation Guides (and possibly Extensions)
  197. 197. 197 CDA Summary  CDA is XML-based and RIM-based  CDA documents can be exchanged as encapsulated data (payload) in any message (HL7 V2, HL7 V3, etc.)  CDA is not dependent on using HL7 V3 messages  Most likely early use cases for CDA  Referrals  Claims & Reimbursements  Lab/imaging Reports  Electronic Health Records Documents
  198. 198. 198 Take Home Message • HL7 is not panacea and so does other standards • People and processes matter most • Do not aim to build HIS to comply with HL7 specification but do aim to let it be able to communicate to another systems via HL7 • Most specifications in standards and interoperability provide framework but not implementation guide, at times you need experts Slide reproduced/adapted from Dr. Supachai Parchariyanon
  199. 199. 199 Assignment  Assignment: Using the outline for a CDA, create a section for reporting a height and a weight measurement. Slide reproduced/adapted from Dr. Supachai Parchariyanon
  200. 200. 200 Assignment: Key Assignment: Using the outline for a CDA, create a section for reporting a height and a weight measurement. Solution: There are different ways of answering this question. The simplest answer is just to use text. <physical examination> <height> “68 inches” </height> <weight> “175 pounds” </weight> </physical examination> Other solutions: You could look up a LOINC code, separate value and units. Slide reproduced/adapted from Dr. Supachai Parchariyanon
  201. 201. 201 Q/A Slide reproduced/adapted from Dr. Supachai Parchariyanon

×