This document discusses HL7 standards and includes information about: - HL7 version 2 (HL7 v2), which is the most commonly used HL7 standard for defining electronic messages supporting hospital operations. - HL7 version 3, which adds semantic capability to messaging. - The Clinical Document Architecture (CDA), which defines the structure and semantics of clinical documents.

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
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
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
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
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
Standards Are Everywhere

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
Health Information Exchange (HIE)
Hospital A Hospital B
Clinic C
Government
Lab Patient at Home

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
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
Levels of Interoperability
Functional
Semantic
Syntactic

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
Things that can go wrong in
message exchange
Slide reproduced/adapted from Dr. Supachai Parchariyanon

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
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. 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
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
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
OSI Model
Slide reproduced/adapted from Dr. Supachai Parchariyanon

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
What HL7 does?
Slide reproduced/adapted from Dr. Supachai Parchariyanon

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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
Summary
Slide reproduced/adapted from Dr. Supachai Parchariyanon

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
RULES
Slide reproduced/adapted from Dr. Supachai Parchariyanon

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
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
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
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
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
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
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
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
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
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
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
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
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
Reference Information Model (RIM)
53

54. 54
Source: “What is CDA R2? by Calvin E. Beebe
at HL7 Educational Summit in July 2012

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
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
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
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
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
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
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. Slide reproduced/adapted from Dr. Supachai Parchariyanon 62

63. 63
Domain Document Elements
Slide reproduced/adapted from Dr. Supachai Parchariyanon

64. 64
Example: HL7 v3
Slide reproduced/adapted from Dr. Supachai Parchariyanon

65. Slide reproduced/adapted from Dr. Supachai Parchariyanon 65

66. 66
Navigating the V3 Ballot
Publication
Slide reproduced/adapted from Dr. Supachai Parchariyanon

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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
RIM - Domain Related
Classes
Slide reproduced/adapted from Dr. Supachai Parchariyanon

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
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
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
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
RIM Entity Classes
Slide reproduced/adapted from Dr. Supachai Parchariyanon

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
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
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
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
RIM Role Classes
Slide reproduced/adapted from Dr. Supachai Parchariyanon

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
RIM Participation and Act
Classes
Slide reproduced/adapted from Dr. Supachai Parchariyanon

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
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
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
HL7 v3 Process & Artifacts
Overview
RIM DMIM RMIM
1..* 1..*
MT HMD 1..*
1..*
Slide reproduced/adapted from Dr. Supachai Parchariyanon

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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
Q/A
Slide reproduced/adapted from Dr. Supachai Parchariyanon

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
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
Exchange Standards
Messages
• Human Unreadable
• Machine Processable
Clinical Documents
• Human Readable
• (Ideally) Machine
Processable

125. 125
Message Exchange
Message
Message
Hospital A Hospital B
Clinic C
Government
Lab Patient at Home
Message
Message Message

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
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
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
Clinical Documents
Slide reproduced/adapted from Dr. Supachai Parchariyanon

130. Slide reproduced/adapted from Dr. Supachai Parchariyanon 130

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
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
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
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
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
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
Scope of CDA
Lab Report
Lab Technician Physician
Create
document
Process &
Store
document
Transmit
document
CDA

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
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
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. 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. 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. 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
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
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
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
CDA As Payload
Source: From “What is CDA R2? by Calvin E. Beebe
at HL7 Educational Summit in July 2012

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
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. 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
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
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
Major Components of a
CDA
Slide reproduced/adapted from Dr. Supachai Parchariyanon

154. 154
CDA Model
Source: From “What is CDA R2? by Calvin E. Beebe
at HL7 Educational Summit in July 2012

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
Rendering CDA Documents (1)
Source: From “What is CDA R2? by Calvin E. Beebe
at HL7 Educational Summit in July 2012

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
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. 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. 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. 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
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
Release 1: defined Level
One, Level Two only
Slide reproduced/adapted from Dr. Supachai Parchariyanon

164. 164
Release 2: Levels One,
Two, Three
Slide reproduced/adapted from Dr. Supachai Parchariyanon

165. 165
Header
• Main CDA elements : Header
Slide reproduced/adapted from Dr. Supachai Parchariyanon

166. 166
Body
Slide reproduced/adapted from Dr. Supachai Parchariyanon

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
Body – Narrative Text
Slide reproduced/adapted from Dr. Supachai Parchariyanon

169. 169
Body – Narrative Text
(Table)
Example
Result
Slide reproduced/adapted from Dr. Supachai Parchariyanon

170. 170
Body – Narrative Text (List)
Example
Result
Slide reproduced/adapted from Dr. Supachai Parchariyanon

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
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
Entries
Structure Body
– Machine Processible
Slide reproduced/adapted from Dr. Supachai Parchariyanon

174. 174
Entries - observation
Slide reproduced/adapted from Dr. Supachai Parchariyanon

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
Entries - observation
(Example)
Slide reproduced/adapted from Dr. Supachai Parchariyanon

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
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
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. 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
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
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
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
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
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
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
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
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
Document Management Examples
Source: From “What is CDA R2? by Calvin E. Beebe
at HL7 Educational Summit in July 2012

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
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
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
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
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
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
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
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
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
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
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
Q/A
Slide reproduced/adapted from Dr. Supachai Parchariyanon