Hl7 Standards (September 15, 2016)

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

September 15, 2016

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

»[email protected]

»http://www.facebook.com/supachaiMD

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 Specialist

Former Deputy Chief, Informatics Division

Deputy Executive Director for Informatics,

Chakri Naruebodindra Medical Institute


[email protected]

http://groups.google.com/group/ThaiHealthIT

Research interests:• EHRs & health IT applications in clinical settings

• Health IT adoption

• Health informatics education & workforce development

4

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)

• Clinical Document Architecture (CDA)


5

Standards Are Everywhere

6

Standards: Why?

• The Large N Problem

N = 2, Interface = 1

# Interfaces = N(N-1)/2



N = 100, Interface = 4,950

7

Health Information Exchange (HIE)

Hospital A Hospital B

Clinic C

Government

Lab Patient at Home

8

Objectives

• Interoperability

• Inter-operable

systems

Ultimate Goals

• Continuity of Care

• Quality

Safety

Timeliness

Effectiveness

Equity

Patient-Centeredness

Efficiency

Why Health Information Standards?

9

Levels of Interoperability

Functional

Semantic

Syntactic

10

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

11

Functional

Semantic

Syntactic

How Standards Support Interoperability

Technical Standards

(TCP/IP, encryption,

security)

Exchange Standards (HL7 V2,

HL7 V3 Messaging, HL7 CDA,

DICOM)

Vocabularies, Terminologies,

Coding Systems (ICD-10, ICD-9,

CPT, SNOMED CT, LOINC)

Information Models (HL7 V3 RIM,

ASTM CCR, HL7 CCD)

Standard Data Sets

Functional Standards (HL7 EHR

Functional Specifications)

Some may be hybrid: e.g. HL7 V3, HL7 CCD

Unique ID

12

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.


13

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.


14

OSI Model


15

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)


16

What HL7 does?


17

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.

18

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″


19

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

20

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


21

Part of Sample HL7 V2 Message

(Lab Result)

OBX|1|NM|10839-9^TROPONIN-I^LN||5|ng/ml|0-1.3|H||H|F|19980309…

22

HL7 Basic Transaction Model

send

HL7 ADT

A01 msg

receive HL7

ACK msg

ADT system

Lab system

Receive A01,

send ACK

(external) admit

event

trigger event

network


23

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)


24

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>


25

Message Header Segment - MSH

MSH|^~|&|SMS|OR2|TMR|SICU|201010191535|password|ADT^A01|MSG1632|P|2.7<cr>

Sending

UnitReceiving

Unit Date

TimeMessage

typeTrigger

ID

Sending

Place Receiving

Place

Message

Number

version

Delimiters

production


26

PID Segment – 1/3

PID|Z12345^5^M11||||PATIENT^JOSEPH^M^IV|

Patient ID

Check digit

Method

Last name

First name

Middle

Initial

Suffix

Patient name

Null fields

Data field

Field delimiter


27

PID Segment – 2/3

MAIDEN|19610605|M||C|1492 OCEAN STREET^

Mother’s

maiden name

Gender

Date of birth Race

Street

address

Data component Component

delimiter


28

PID Segment – 3/3

DURHAM^NC^27705|DUR|(919)684-6421<cr>

City

State

Zip Code

County

Telephone

Segment terminator


29

PV1 Segment

PV1|1|1|N2200^2200|||OR^02|0846^WELBY^MARCUS^G||SUR<cr>

Patient locationAttending

ServiceSequence

number

Patient

class


30

Summary


31

Rules


32

Problems with HL7 v2

• 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


33

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


34

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


35

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)

36

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

37

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

38

HL7 V3 Messaging

• V3 provides messaging standards for

– Patient administration

– Medical records

– Orders

– Laboratory

– Claims & Reimbursement

– Care provision

– Clinical genomics

– Public Health

– Etc.

39

Sample HL7 V3 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

40

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..*

Act

Relationship

1..*

10..*

1Participation Act

• Author

• Reviewer

• Verifier

• Subject

• Target

• Tracker

• Has component

• Is supported by


41

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

ProviderSurgeon

John Doe Patient Subject

Has Pertinent

InformationAct Relationship

(Clinical Trial Act)

Protocol ECOG

1112

XYZ

HospitalHealthCare

FacilityLocation

(Procedure Act)

Prostectomy


42

Reference Information Model (RIM)


43Source: “What is CDA R2? by Calvin E. Beebe

at HL7 Educational Summit in July 2012

44

The HL7 V3 Solution

• Approaching “Plug and Play” - less of a

“framework for negotiation”

• Utilizes RIM for data model

• Utilizes XML as transport method

• HL7 V3 is not the next release of HL7 V2 -It is a paradigm shift


45

The HL7 V3 Solution (Cont.)

• HL7 V3 addresses the problems of HL7 V2

by:– Reducing HL7 V2 optionality

– Including testable conformance rules

• HL7 V3 is based on a formal development

methodology:– Follows an Object Oriented (OO) approach

– Uses Universal Modeling Language (UML) principles

• Most importantly, HL7 V3 supports

semantic interoperabilitySlide reproduced/adapted from Dr. Supachai Parchariyanon

46

Interoperability in HL7 V3

• The Four Pillars of Semantic

Interoperability in HL7 V3– 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


47

HL7 Model Repository

• Database holding the core of HL7semantic specifications

– RIM

– Storyboards

– Vocabulary domains

– Interaction models

– Message designs

– Message constraints


48Slide reproduced/adapted from Dr. Supachai Parchariyanon

49

Navigating the V3 Ballot Publication


50

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..


51

Domain Publication Structure

Each Realm contains a collection of

Domains. Domains are further divided into

Topics

• Domain• Topic


52

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


53

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 protocolhttp://wiki.hl7.org/index.php?title=FHIR

54

HL7 Clinical Document

Architecture (CDA)

Nawanan Theera-Ampornpunt, M.D., Ph.D.

Department of Community Medicine


Certified HL7 CDA Specialist

Some slides reproduced & adapted with permission from

Dr. Supachai Parchariyanon

55

Message Exchange

• Goal: Specify format

for exchange of data

• Internal vs. external

messages

• Examples HL7 V2

HL7 V3 Messaging

DICOM

NCPDP

Document Exchange

• Goal: Specify format

for exchange of

“documents”

• Examples HL7 V3 Clinical Document

Architecture (CDA)

ASTM Continuity of Care

Record (CCR)

HL7 Continuity of Care

Document (CCD)

Exchange Standards

56

Messages

• Human Unreadable

• Machine Processable

Clinical Documents

• Human Readable

• (Ideally) Machine

Processable

Exchange Standards

57


Clinic C

Government

Lab Patient at Home

Message Exchange

Message

Message

Message

MessageMessage

58


Clinic C

Government

Lab Patient at Home

Clinical Document Exchange

Message containing

Referral Letter

Message containing

Claims Request

Message containing

Lab Report

Message containing

Patient Visit Summary

Message containing

Communicable

Disease Report

59

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!!

60

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


61

Clinical Document


62

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

63


• 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

64


• A CDA document is a defined & complete

information object that can include

Text

Images

Sounds

Other multimedia content

Source: HL7 CDA R2

65

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

66

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

67

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

68

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

69

Scope of CDA

Lab Technician Physician

Lab Report

Create

document

Process &

Store

document

Transmit

document

CDA

70

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.


71

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

72

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

73

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


74

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


75

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


76

CDA As Payload

Source: From “What is CDA R2? by Calvin E. Beebe


77

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

http://en.wikipedia.org/wiki/MIME

78

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

http://en.wikipedia.org/wiki/Base64

79

Components of CDA Document

• Header

– Metadata requires for document discovery,

management, retrieval

• Body

– Section

– Entry (machine processable part)

– Narrative Block (human readable part)

Source: HL7 CDA R2

80

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.


81

Major Components of a CDA


82

CDA Model



83

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

84

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>

Na

rra

tive

Co

mp

uta

ble

REQUIRED


85

Body - Structured Body (Machine Processable)

<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"/>

Narr

ative

Com

puta

ble

OPTIONAL


86

Rendering CDA Documents (1)



87




88


• 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

89

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)

90

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)

91

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

92

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)

93

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)

94

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

95

HL7: 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


96

Additional Information

• Health Level Seven http://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

• FHIR: http://www.hl7.org/implement/standards/fhir/


97

Q/A


Hl7 Standards (September 15, 2016)

Healthcare

Transcript of Hl7 Standards (September 15, 2016)