Post on 05-Dec-2014
description
1
HL7 Standards
Nawanan Theera-Ampornpunt, M.D., Ph.D.Department of Community Medicine
Faculty of Medicine Ramathibodi HospitalCertified HL7 CDA Specialist
Some slides reproduced & adapted with permission from Dr. Supachai Parchariyanon
October 11, 2014
2
»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
Some Slides Reproduced with Permission from Dr. Supachai Parchariyanon@supachaiMD
Slide reproduced/adapted from Dr. Supachai Parchariyanon
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 SpecialistFormer Deputy Chief, Informatics DivisionDeputy Executive Director for Informatics, Chakri Naruebodindra Medical InstituteFaculty of Medicine Ramathibodi Hospital
nawanan.the@mahidol.ac.thhttp://groups.google.com/group/ThaiHealthIT
Research interests:• EHRs & health IT applications in clinical settings• Health IT adoption• Health informatics education & workforce development
4
Thailand’s HL7Certified Specialists
Kevin Asavanant
HL7 V3 RIM (2009)
SupachaiParchariyanonHL7 CDA (2010)
NawananTheera-Ampornpunt
HL7 CDA (2012)
SireeratSrisiriratanakul
HL7 V3 RIM (2013)
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
Standards Are Everywhere
7
Standards: Why?
• The Large N ProblemN = 2, Interface = 1
# Interfaces = N(N-1)/2
N = 3, Interface = 3
N = 5, Interface = 10
N = 100, Interface = 4,950
8
Health Information Exchange (HIE)
Hospital A Hospital B
Clinic C
Government
Lab Patient at Home
9
Objectives• Interoperability• Inter-operable
systems
Ultimate Goals• Continuity of Care• Quality Safety Timeliness Effectiveness Equity Patient-Centeredness
Efficiency
Why Health Information Standards?
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
Levels of Interoperability
Functional
Semantic
Syntactic
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
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 equal to interoperability
Slide reproduced/adapted from Dr. Supachai Parchariyanon
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
Semantic
Syntactic
How Standards Support Interoperability
Technical Standards (TCP/IP, encryption,
security)
Exchange Standards (HL7 v.2, HL7 v.3 Messaging, HL7 CDA,
DICOM)
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
Functional Standards (HL7 EHRFunctional Specifications)
Some may be hybrid: e.g. HL7 v.3, HL7 CCD
Unique ID
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
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
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 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
What HL7 does?
Slide reproduced/adapted from Dr. Supachai Parchariyanon
22
HL7 Standards
• HL7 V2.x– Defines electronic messages supporting hospital
operations• HL7 V3• HL7 Clinical Document Architecture
(CDA) Releases 1 and 2• HL7 Arden Syntax
– Representation of medical knowledge• HL7 EHR & PHR Functional Specifications• Etc.
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
HL7 version2
• HL7 v2 is still the most commonly used HL7standard– 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
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
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
HL7 Basic Transaction Model
sendHL7 ADT A01 msg
receive HL7 ACK msg
ADT system
Lab system
Receive A01,send ACK
(external) admitevent
trigger event
network
Slide reproduced/adapted from Dr. Supachai Parchariyanon
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
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
Message Header Segment - MSH
MSH|^~|&|SMS|OR2|TMR|SICU|201010191535|password|ADT^A01|MSG1632|P|2.7<cr>
Sending Unit
Receiving Unit Date
TimeMessage
typeTrigger
ID
Sending Place Receiving
Place
Message Number
version
Delimiters
production
Slide reproduced/adapted from Dr. Supachai Parchariyanon
31
PID Segment – 1/3
PID|Z12345^5^M11||||PATIENT^JOSEPH^M^IV|
Patient ID
Check digit
Method
Last nameFirst name
Middle Initial
Suffix
Patient name
Null fieldsData field
Field delimiter
Slide reproduced/adapted from Dr. Supachai Parchariyanon
32
PID Segment – 2/3
MAIDEN|19610605|M||C|1492 OCEAN STREET^
Mother’s maiden name
Gender
Date of birth RaceStreet
address
Data component Component delimiter
Slide reproduced/adapted from Dr. Supachai Parchariyanon
33
PID Segment – 3/3
DURHAM^NC^27705|DUR|(919)684-6421<cr>
City
State
Zip Code
County
Telephone
Segment terminator
Slide reproduced/adapted from Dr. Supachai Parchariyanon
34
PV1 Segment
PV1|1|1|N2200^2200|||OR^02|0846^WELBY^MARCUS^G||SUR<cr>
Patient locationAttending
ServiceSequence
number
Patient class
Slide reproduced/adapted from Dr. Supachai Parchariyanon
35
OBR Segment
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>
Placer order number
Filler order number
Universal service ID
Text order Local set
Requested date-time of
service
Reason for study
Principal results interpreter
Slide reproduced/adapted from Dr. Supachai Parchariyanon
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
Slide reproduced/adapted from Dr. Supachai Parchariyanon
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).
37
Summary
Slide reproduced/adapted from Dr. Supachai Parchariyanon
38
Admit Discharge Transfer (ADT)
MSH Message Header Segment[
EVN Event type segmentPID Patient Identification segmentPV1 Patient Visit segment[PV2] Patient Visit – Additional Information[{OBX}] Observation/Result
]
Slide reproduced/adapted from Dr. Supachai Parchariyanon
39
RULES
Slide reproduced/adapted from Dr. Supachai Parchariyanon
40
ADT event typesADT^A13 Cancel discharge/end visitADT^A04 Register a patientADT^A08 Update patient informationADT^A01 Admit/visit notificationADT^A02 Transfer a patientADT^A03 Discharge/end visitADT^A28 Add person informationADT^A14 Pending admitADT^A05 Pre-admit a patientADT^A31 Update person informationADT^A07 Change an inpatient to an outpatientADT^A06 Change an outpatient to an inpatientADT^A11 Cancel admit/visit notificationADT^A10 Patient arriving – trackingADT^A09 Patient departing - trackingADT^A12 Cancel transferADT^A15 Pending transferADT^A16 Pending dischargeADT^A17 Swap patients
ADT^A18Merge patient information (for backward compatibility only)
ADT^A20 Bed status updateADT^A32 Cancel patient arriving - trackingADT^A33 Cancel patient departing - trackingADT^A27 Cancel pending admitADT^A25 Cancel pending dischargeADT^A26 Cancel pending transferADT^A23 Delete a patient recordADT^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^A35Merge patient information - account number only (for backward compatibility only)
ADT^A36 Merge patient information - patient ID and account number
ADT^A34Merge 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 numberADT^A46 Change patient ID (for backward compatibility only)ADT^A47 Change patient identifier listADT^A37 Unlink patient informationADT^A38 Cancel pre-admitADT^A41 Merge account - patient account numberADT^A40 Merge patient - patient identifier listADT^A39 Merge person - patient ID (for backward compatibility only)ADT^A42 Merge visit - visit numberADT^A44 Move account information - patient account numberADT^A43 Move patient information - patient identifier listADT^A45 Move visit information - visit numberADT^A51 Change alternate visit IDADT^A50 Change visit numberADT^A52 Cancel leave of absence for a patientADT^A53 Cancel patient returns from a leave of absenceADT^A55 Cancel change attending doctorADT^A54 Change attending doctorADT^A60 Update allergy informationADT^A62 Cancel change consulting doctorADT^A61 Change consulting doctor
Slide reproduced/adapted from Dr. Supachai Parchariyanon
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|||\LIS\REPORT\2011\08\25\20110825_25110524242.htm<cr>NTE|1||\.br\*อืน่ๆ\.br\Specimen 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
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
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
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
HL7 V3 Standards
• A family of standards based on V3information models and development methodology
• Components– HL7 V3 Reference Information Model (RIM)– HL7 V3 Messaging– HL7 Development Framework (HDF)
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
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
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
HL7 V3 Messaging
• V3 provides messaging standards for– Patient administration– Medical records– Orders– Laboratory– Claims & Reimbursement– Care provision– Clinical genomics– Public Health– Etc.
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
HL7 v3 Reference Information Model
• Referral• Transportation• Supply• Procedure• Consent• Observation• Medication• Administrative act• Financial act
• Organization• Place• Person• Living Subject• Material
• Patient• Member• Healthcare facility• Practitioner• Practitioner assignment• Specimen• Location
Entity0..*
1Role
1
0..*
1
0..*
ActRelationship
1..*
10..*
1Participation Act
• Author• Reviewer• Verifier• Subject• Target• Tracker
• Has component• Is supported by
Slide reproduced/adapted from Dr. Supachai Parchariyanon
52
HL7 v3 Components and Process: RIM UML Instance
Scenario
Classes are color coded: Green = Entity, Yellow = Role, Blue = Participation, Red/Pink = Act, Purple = Infrastructure, Lilac = message
controller.
John Doe Patient Subject
Entity Role Participation Act
Dr. SmithHealthCare
Provider Surgeon
John Doe Patient Subject
Has Pertinent InformationAct Relationship
(Clinical Trial Act)Protocol ECOG
1112
XYZ Hospital
HealthCareFacility Location
(Procedure Act)Prostectomy
Slide reproduced/adapted from Dr. Supachai Parchariyanon
53
Reference Information Model (RIM)
53
54Source: “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 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
The HL7 v3 Solution (Cont.)
• HL7v3 addresses the problems of HL7v2by:– 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
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
HL7 Development Framework
• Formal methodology for mapping any “local”, domain -specific system, such as a “laboratory system” in the v3Reference 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
Model-based Development
HL7 Framework HL7 Specification
RIMData typesData elementsVocabularyTemplatesClinical Statements
Core Structured
Content
V3 Messaging
CDA Specifications
GELLO
System Oriented Architecture
Slide reproduced/adapted from Dr. Supachai Parchariyanon
60
HL7 Model Repository
• Database holding the core of HL7semantic specifications– RIM– Storyboards– Vocabulary domains– Interaction models– Message designs– Message constraints
Slide reproduced/adapted from Dr. Supachai Parchariyanon
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
62Slide reproduced/adapted from Dr. Supachai Parchariyanon
63
Domain Document Elements
Slide reproduced/adapted from Dr. Supachai Parchariyanon
64
Example: HL7 v3
Slide reproduced/adapted from Dr. Supachai Parchariyanon
65Slide reproduced/adapted from Dr. Supachai Parchariyanon
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 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
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
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 v3messaging means
• Need stability, clarity, definition of v3 messaging
Slide reproduced/adapted from Dr. Supachai Parchariyanon
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
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• HL7 v3:
– “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
Assignment 1
1._______ messaging standard is easy to use and understand. It is based on an implicit information model.
1. HL7 v3.n2. DICOM v2.n3. XML v3.n4. HL7 v2.n
2.HL7 message are composed of reusable segments, each identified by a __ -letter mnemonic.
1. 22. 33. 44. 5
Slide reproduced/adapted from Dr. Supachai Parchariyanon
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. Acknowledgement2. Interface3. Trigger event4. message
4.___________ is the exclusive international standards body for imaging standards.
1. XML2. NCPDP3. DICOM4. IEEE
Slide reproduced/adapted from Dr. Supachai Parchariyanon
74
Assignment 1
5. ___________ creates standards for pharmacy services.1. X12N2. NCPDP3. DICOM4. IEEE
6. _________ is the standards developing organization that focuses primarily on device standards.
1. X12N2. NCPDP3. DICOM4. IEEE
Slide reproduced/adapted from Dr. Supachai Parchariyanon
75
Assignment 1
7. ______ has developed standards for the exchange of purchase-order data, invoice data and other commonly used business documents.
1. X12N2. NCPDP3. DICOM4. IEEE
8.________ based on an object information model, called the Reference Information Model, (RIM), Patient Records.
1. HL7 v32. DICOM v2.n3. XML v3.n4. HL7 v2.n
Slide reproduced/adapted from Dr. Supachai Parchariyanon
76
Assignment 1: Key
1._______ messaging standard is easy to use and understand. It is based on an implicit information model.
1. HL7 v3.n2. DICOM v2.n3. XML v3.n4. HL7 v2.n
2.HL7 message are composed of reusable segments, each identified by a __ -letter mnemonic.
1. 22. 33. 44. 5
Slide reproduced/adapted from Dr. Supachai Parchariyanon
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. Acknowledgement2. Interface3. Trigger event4. message
4.___________ is the exclusive international standards body for imaging standards.
1. XML2. NCPDP3. DICOM4. IEEE
Slide reproduced/adapted from Dr. Supachai Parchariyanon
78
Assignment 1: Key
5. ___________ creates standards for pharmacy services.1. X12N2. NCPDP3. DICOM4. IEEE
6. _________ is the standards developing organization that focuses primarily on device standards.
1. X12N2. NCPDP3. DICOM4. IEEE
Slide reproduced/adapted from Dr. Supachai Parchariyanon
79
Assignment 1: Key
7. ______ has developed standards for the exchange of purchase-order data, invoice data and other commonly used business documents.
1. X12N2. NCPDP3. DICOM4. IEEE
8.________ is based on an object information model, called the Reference Information Model, (RIM).
1. HL7 v32. DICOM v2.n3. XML v3.n4. HL7 v2.n
Slide reproduced/adapted from Dr. Supachai Parchariyanon
80
Assignment 2“READING AN ADT MESSAGE” For the Message:
MSH|^~\&|ADT_HGG||LAB_HGG||20090827120759||ADT^A01^ADT_A01|ADT_HGG00234509|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||H0100240|||||||||||||||||||||||||20090827120759<cr>IN1|1|CPS|HGG| HC Hospital General Gold, INC. |5555 WASHTEOLD AVENUE^SUITE2333^ ANN ARBOR^MI^48104^USA||555-555- 3002||||||||||||||||||||||||||||||||||||||||||444-22-2222 <cr>
Slide reproduced/adapted from Dr. Supachai Parchariyanon
81
Assignment 2ASSIGNMENT 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
Assignment 2: KeyASSIGNMENT 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^SUITE2333^ 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
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
HL7 Reference Information Model (RIM)
Nawanan Theera-Ampornpunt, M.D., Ph.D.Department of Community Medicine
Faculty of Medicine Ramathibodi HospitalCertified HL7 CDA Specialist
Some slides reproduced & adapted with permission from Dr. Supachai Parchariyanon
October 11, 2014
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
Reference Information Model
• The RIM is the cornerstone of HL7 v3messaging.
• 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
RIM - Domain Related Classes
Slide reproduced/adapted from Dr. Supachai Parchariyanon
88
RIM Backbone Classes
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.
Entity Role Participation Act
A connection between two roles expressing a dependency between those roles.
A directed association between a source act and a target act.
Role Link Act Relationship
0..n1
0..n 0..n
1
0..1
0..n
0..n 0..n0..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
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
– 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
RIM as an Abstract Model
Slide reproduced/adapted from Dr. Supachai Parchariyanon
91
HL7 v3 Components and Process: RIM UML Instance
Scenario
Classes are color coded: Green = Entity, Yellow = Role, Blue = Participation, Red/Pink = Act, Purple = Infrastructure, Lilac = message
controller.
John Doe Patient Subject
Entity Role Participation Act
Dr. SmithHealthCare
Provider Surgeon
John Doe Patient Subject
Has Pertinent InformationAct Relationship
(Clinical Trial Act)Protocol ECOG
1112
XYZ Hospital
HealthCareFacility Location
(Procedure Act)Prostectomy
Slide reproduced/adapted from Dr. Supachai Parchariyanon
92
RIM Entity Classes
Slide reproduced/adapted from Dr. Supachai Parchariyanon
93
RIM Entity Classes
classCode : CSdeterminerCode : CSid : SET<II>code : CEquantity : SET<PQ>name : BAG<EN>desc : EDstatusCode : SET<CS>existenceTime : IVL<TS>telecom : BAG<TEL>riskCode : CEhandlingCode : CE
Entity• 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
RIM Entity Classes: How to Read
classCode : CSdeterminerCode : CSid : SET<II>code : CEquantity : SET<PQ>name : BAG<EN>desc : EDstatusCode : SET<CS>existenceTime : IVL<TS>telecom : BAG<TEL>riskCode : CEhandlingCode : CE
Entity• 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
RIM Entity Classes : How to Read
classCode : CSdeterminerCode : CSid : SET<II>code : CEquantity : SET<PQ>name : BAG<EN>desc : EDstatusCode : SET<CS>existenceTime : IVL<TS>telecom : BAG<TEL>riskCode : CEhandlingCode : CE
Entity
Slide reproduced/adapted from Dr. Supachai Parchariyanon
96
RIM Entity Classes : How to Read
classCode : CSdeterminerCode : CSid : SET<II>code : CEquantity : SET<PQ>name : BAG<EN>desc : EDstatusCode : SET<CS>existenceTime : IVL<TS>telecom : BAG<TEL>riskCode : CEhandlingCode : CE
Entity
Slide reproduced/adapted from Dr. Supachai Parchariyanon
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, 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
classCode : CSid : SET<II>code : CEnegationInd : BLaddr : BAG<AD>telecom : BAG<TEL>statusCode : SET<CS>effectiveTime : IVL<TS>certificateText : EDquantity : RTOpositionNumber : LIST<INT>
Role
Slide reproduced/adapted from Dr. Supachai Parchariyanon
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 Role.
• Participation has the following sub-class:– ManagedParticipation
Participation
typeCode : CSfunctionCode : CDcontextControlCode : CSsequenceNumber : INTnegationInd : BLnoteText : EDtime : IVL<TS>modeCode : CEawarenessCode : CEsignatureCode : CEsignatureText : EDperformInd : BLsubstitutionConditionCode : CE
Slide reproduced/adapted from Dr. Supachai Parchariyanon
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 : CSmoodCode : CSid : SET<II>code : CDnegationInd : BLderivationExpr : STtext : EDtitle : STstatusCode : SET<CS>effectiveTime : GTSactivityTime : GTSavailabilityTime : TSpriorityCode : SET<CE>confidentialityCode : SET<CE>repeatNumber : IVL<INT>interruptibleInd : BLlevelCode : CEindependentInd : BLuncertaintyCode : CEreasonCode : SET<CE>languageCode : CE
Slide reproduced/adapted from Dr. Supachai Parchariyanon
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.
inboundRelationship
ActRelationship
typeCode : CSinversionInd : BLcontextControlCode : CScontextConductionInd : BLsequenceNumber : INTpriorityNumber : INTpauseQuantity : PQcheckpointCode : CSsplitCode : CSjoinCode : CSnegationInd : BLconjunctionCode : CSlocalVariableName : STseperatableInd : BL
Act
0..n
0..n
source
0..n
target1
outboundRelationship
Slide reproduced/adapted from Dr. Supachai Parchariyanon
103
HL7 v3 Process & Artifacts Overview
RIM DMIM RMIM
1..* 1..*
1..*HMDMT
1..*
Slide reproduced/adapted from Dr. Supachai Parchariyanon
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
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
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
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 PatientLivingSubjectEvent Activate message
Slide reproduced/adapted from Dr. Supachai Parchariyanon
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
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
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
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
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
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
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
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
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
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
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
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
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
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
Faculty of Medicine Ramathibodi HospitalCertified HL7 CDA Specialist
Some slides reproduced & adapted with permission from Dr. Supachai Parchariyanon
October 11, 2014
123
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)
Exchange Standards
124
Messages
• Human Unreadable• Machine Processable
Clinical Documents
• Human Readable• (Ideally) Machine
Processable
Exchange Standards
125
Hospital A Hospital B
Clinic C
Government
Lab Patient at Home
Message Exchange
Message
Message
Message
Message Message
126
Hospital A Hospital B
Clinic C
Government
Lab Patient at Home
Clinical Document ExchangeMessage containing
Referral Letter
Message containing Claims Request
Message containing Lab Report
Message containing Patient Visit Summary
Message containing Communicable Disease Report
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
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
Clinical Documents
Slide reproduced/adapted from Dr. Supachai Parchariyanon
130Slide reproduced/adapted from Dr. Supachai Parchariyanon
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
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
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
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 specificationsSource: HL7 CDA R2
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
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 V3messages (where CDA clinical documents can become contents of the messages)
Source: HL7 CDA R2
137
Scope of CDA
Lab Technician Physician
Lab Report
Create document
Process & Store
document
Transmit document
CDA
138
Scope of document content
• Clinical content of the documents is defined by the RIM and not by CDA. CDAonly standardizes the structure and semantics required to exchange documents.
Slide reproduced/adapted from Dr. Supachai Parchariyanon
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
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 HL7committees
• Technical barriers to use of CDA should be minimized
• Specifies representation of instances required for exchange
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
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 browsers & print drivers and a generic CDA style sheet written in a standard style sheet language
• Use open standards
Source: HL7 CDA R2
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
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
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
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– 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 charactersSource: http://en.wikipedia.org/wiki/MIME
149
Base64 Encoding
• TWFuIGlzIGRpc3Rpbmd1aXNoZWQsIG5vdCBvbmx5IGJ5IGhpcyByZWFzb24sIGJ1dCBieSB0aGlzIHNpbmd1bGFyIHBhc3Npb24gZnJvbSBvdGhlciBhbmltYWxzLCB3aGljaCBpcyBhIGx1c3Qgb2YgdGhlIG1pbmQsIHRoYXQgYnkgYSBwZXJzZXZlcmFuY2Ugb2YgZGVsaWdodCBpbiB0aGUgY29udGludWVkIGFuZCBpbmRlZmF0aWdhYmxlIGdlbmVyYXRpb24gb2Yga25vd2xlZGdlLCBleGNlZWRzIHRoZSBzaG9ydCB2ZWhlbWVuY2Ugb2YgYW55IGNhcm5hbCBwbGVhc3VyZS4=
• 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
• 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
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
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
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
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
Human Readable Part
Machine Processable Parts
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, 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 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 CDA Documents (2)
• When structured content is derived from narrative, there must be a mechanism to describe the process by which machine-processableportions 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 CDA Documents (3)
Source: HL7 CDA R2
<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>
Text to be rendered
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
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– image/gif– image/tiff– image/jpeg– image/png
Slide reproduced/adapted from Dr. Supachai Parchariyanon
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 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>
Nar
rativ
eC
ompu
tabl
e
REQUIRED
Slide reproduced/adapted from Dr. Supachai Parchariyanon
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"/>
Nar
rativ
eC
ompu
tabl
e
OPTIONAL
Slide reproduced/adapted from Dr. Supachai Parchariyanon
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 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
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 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
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
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
Source: HL7 CDA R2
181
Design Principles ofCDA 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
Design Principles ofCDA 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
Security, Confidentiality & Data Integrity
• Application systems sending and receiving CDAdocuments 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
CDA Conformance (1)
• CDA document originator application is responsible for ensuring that generated CDAdocuments 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 CDAdocuments defined by CDA (out-of-scope)
Source: HL7 CDA R2
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
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
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
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
Document Management Examples
Source: From “What is CDA R2? by Calvin E. Beebe at HL7 Educational Summit in July 2012
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
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
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
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
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
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
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
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 V3messages
Most likely early use cases for CDA Referrals Claims & Reimbursements Lab/imaging Reports Electronic Health Records Documents
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
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
Assignment: KeyAssignment: 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
Q/A
Slide reproduced/adapted from Dr. Supachai Parchariyanon