The document discusses HL7 and FHIR. It begins by explaining that HL7 is a standards development organization that provides a framework and standards for exchanging health information to support clinical practices and health services management. It then defines what "Level Seven" refers to in relation to the ISO communication model. The document also provides information on various HL7 product families, including FHIR, CDA, EHR functional model, SOA, and context management architecture. It concludes by summarizing HL7 Version 2 and Version 3 messaging standards.

1. HL7 & FHIR
2

2. What is HL7?
• Health Level Seven (HL7) is a Standards
Developing Organization accredited by the
American National Standards Institute (ANSI).
• The mission of HL7 is to provide a comprehensive
framework and related standards for the exchange,
integration, storage, and retrieval of health
information that support clinical practices and the
management, delivery and evaluation of health
services.
HL7

3. What is HL7?
“Level Seven” refers to the highest level of the International
Standards Organization’s communication model for Open
Systems Interconnection - the application level.
Communication
ISO OSI CommunicationArchitecture Model
Application
6 Presentation
5 Session
4 Transport
3 Network
2 Data Link
1 Physical
Function

4. HL7 Product Families
• Fast Healthcare Interoperability Resources Specification (FHIR)
FHIR is a next generation standards framework that combines the best features of HL7’s Version 2, Version 3 and CDA® product lines while leveraging the latest web standards and
applying a tight focus on implementation FHIR solutions are built from a set of modular components called “Resources”. These resources can be easily assembled into working
systems that solve real world clinical and administrative problems.
• Clinical Document Architecture
The HL7 Version 3 Clinical Document Architecture (CDA) is a document markup standard that specifies the structure and semantics of "clinical documents" for the purpose of
exchange between healthcare providers and patients. A CDA can contain any type of clinical content -- typical CDA documents would be a Discharge Summary, Imaging Report,
Admission & Physical, Pathology Report and more.
• Electronic Health Record System Functional Model
The HL7 International EHR System Functional Model (EHR-S FM) provides a standard description and common understanding of functions for healthcare
settings. HL7 has developed or is developing profiles for areas such as child health, emergency care, long term care, behavioral health and vital statistic
reporting.
• Service Oriented Architecture
The Services Oriented Architecture supports the HL7 mission to promote and create standards by identifying common architectural "services" and their behaviors. The SOA WG
produces Service Functional Models (SFMs), implementation guides, and educational materials. Additionally, the workgroup will explore the implications of emerging technologies
(such as Cloud computing and advanced distributed systems) for health-related environments.
• Context Management Architecture
Aimed at facilitating the integration of applications at the point of use, CCOW Context Management Specification is a standard for both internal applications programming and
runtime environment infrastructure. By synchronizing and coordinating applications to automatically follow the patient, user, and other contexts, CCOW serves as the basis for
ensuring secure and consistent access to patient information from heterogeneous sources.
• HL7 Version 3 Product Suite
Health Level Seven Version 3 (V3) is a suite of specifications based on HL7’s Reference Information Model (RIM). It includes standards for communications that document and
manage the care and treatment of patients in a wide variety of healthcare settings. Version 3 represents a new approach to clinical information exchange based on a model
driven methodology that produces messages and electronic documents expressed in XML syntax.
• HL7 Version 2 Product Suite
HL7’s Version 2.x (V2) messaging standard is the workhorse of electronic data exchange in the clinical domain and arguably the most widely implemented standard for
healthcare in the world. This messaging standard allows the exchange of clinical data between systems. It is designed to support a central patient care system as well as a more
distributed environment where data resides in departmental systems.

5. HL7 Why?
User Interface
Program
Module
Dataset
User
Interface
Program
Module
Dataset
Message
Creation
Message
Parsing
A to B
Transfor
mation
Message
Parsing
Message
Creation
B to A
Transfor
mation
Laboratory
Application
System
OrderEntry
Application
System
Laboratory
Application
System
tn
l
io
esuac
t
R
Labr
a
n
s
T

6. Health Level Seven - Why?
• The number of interfaces between N systems is given by theformula
I = (N2-N)/2.
• Linking 6 systems needs as many as 15 interfaces, (62 – 6) / 2 = 15
• The benefits of using the HL7 standard increase rapidly with the
number of systems involved. I = N

7. Abstract Message Specification
Guarant
or
Insurance
Insurance Additional
Info. Insurance Add'l
Info - Cert.
[ ] optional
Segment
ID
MSH
EVN
PID
[PD1]
[ { NK1
} ]
PV1
[ PV2 ]
…
[ { GT1
} ] [
{ IN1
[ IN2 ]
[ IN3 ]
}
]
…
Segment
Name Message
Header Event
Type
Patient Identification
Additional
Demographics
Next of Kin /Associated
Parties Patient Visit
Patient Visit - Additional
Info
. { } may repeat

8. MSH - Message Header Segment
SEQ LEN C.LEN DT OPT RP/# TBL# ITEM # ELEMENT NAME
1 1..1 ST R 00001 Field Separator
Segment Definition Table
2 4..5 ST
3 HD
SEQ - position within segment
LEN - length of field n
C.LEN – conformance length
DT - data type for field OPT - optionality
for field RP/# - repeatability
TBL# - table number for codes
ITEM# - HL7 element number m
ELEMENT NAME - name
4 HD
5 HD
6 HD
7 DTM e
8 40= ST
9 MSG
10 1..199 = ST
11 PT
12 VID
13 NM
14 180= ST
15 2..2 ID ent Type
16 2..2 ID dgment Type
17 3..3 ID
18 5..15 ID O Y 0211 00692 Character Set

9. PID - Patient Identification Segment
Optionality Meaning
R required
O optional
C(a/b) conditional
B backward compatibility
W Withdrawn

10. HL7 v3 Messaging
• HL7 Version 3 (V3) introduced a common Reference Information Model (RIM),
data type model, a set of vocabulary and a formal standards development
methodology.
• In addition, it introduced the use of "documents" as an alternative architecture
for sharing healthcare information. However, the term "V3" is typically used to
refer to "V3 messaging".
• The HL7 RIM and data types used as a basis for V3 have also been adopted
as ISO standards. ISO 21731:2014 and ISO 21090:2011 respectively.

11. HL7 V3 Message Design Information Models
• RIM: Reference Information Model
• D-MIM: Domain Message Information Model
• R-MIM: Refined Message Information Model
• HMD: Hierarchical Message Definition
82 of
208
R-MIM
Serialize
HMD
D-MIM
Restrict
RIM
Derive

12. HL7 V3 Message Development Framework
Use Case Modeling
Interaction
Modeling
Message Design
Information
Modeling
RIM
R-MIM
Serialize
HMD
Restrict
Message
Type
Example
Storyboard
Storyboard
Example
D-MIM
Restrict
Derive
Application
Role
Sen der Rece iver
Trigger
Event
Triggers
Content
Interaction
References

13. Entity and Act
• Entity
a physical thing or an
organization/group of
physical things capable of
participating in Acts. This
includes living subjects,
organizations, material,
and places.
• Act
a discernible action of
interest in the healthcare
domain. An instance of Act
is a record of that action.
Acts definitions (master
files), orders, plans, and
performance records
(events)
are all represented by an
instance of Act.
Entity Act

14. RIM Core Classes
Entity Act
classCode : CS classCode : CS
determinerCode: CS 0..* 0..* moodCode: CS
code: CE code: CD
statusCode : CS statusCode : CS
id : II effectiveTime :
GTS
id : II
• Entity - a physical thing or an organization/group of physical things capable of
participating in Acts. This includes living subjects, organizations, material, and
places.
• Act – a discernible action of interest in the healthcare domain. An instance of Act
is a record of that action. Acts definitions (master files), orders, plans, and
performance records (events) are all represented by an instance of Act.

15. RIM Core Classes
Entity Role Act
classCode : CS
determinerCode: CS 1 plays 0..* classCode : CS
code: CE
effectiveTime : IVL<TS>
statusCode : CS
id : II
0..* 0..*
classCode : CS
moodCode: CS
code: CE code: CD
statusCode : CS statusCode : CS
id : II effectiveTime : GTS
id : II

16. RIM Core Classes
Entity
0..
1
play
s
Role
0..* 0..*
Act
classCode : CS
determinerCod
e: CS code:
CE
statusCode :
CS
id : II
classCode : CS
code: CE
effectiveTime :
IVL<TS>
statusCode : CS
id : II
classCode : CS
moodCode: CS
code: CD
statusCode :
CS
effectiveTime :
GTS id : II
0..
1
scop
es
0..
*
0..*
• Role – a classification/specialization of an Entity defined by the
relationship of the playing Entity to a scoping Entity. An example of Role is
“Employee”. An employee is a classification attributed to a person which
has an employment relationship with an organization(Employer).

17. RIM Core Classes
Entity Role
1
Participation
1
Act
classCode : CS
determinerCod
e: CS code:
CE
statusCode :
CS
id : II
0..
1
play
s
classCode : CS
code: CE
effectiveTime :
IVL<TS>
statusCode : CS
id : II
typeCode :
CS time :
IVL<TS>
statusCode
: CS
classCode : CS
moodCode: CS
code: CD
statusCode :
CS
effectiveTime :
GTS id : II
0..
1
scop
es
0..
*
0..* 0..*
0..*
• Participation – an association between a Role and an Act representing the
function assumed by the Role within the context of the Act. A single Role
may participate in multiple Acts and a single Act may have multiple
participating Roles. A single Participation is always an association between a
particular Role and a particular Act.

18. RIM Core Classes
Entity
classCode : CS
determinerCode: CS
code: CE
statusCode : CS
id : II
Role
classCode : CS
code: CE
effectiveTime : IVL<TS>
statusCode : CS
id : II
Participation
typeCode : CS
time : IVL<TS>
statusCode : CS
Act
classCode : CS
moodCode: CS
code: CD
statusCode : CS
effectiveTime : GTS
id : II
0..*
1
0..*
1
0..*
Act Relationship
typeCode : CS
0..*
1 1
0..1 plays
0..* 0..*
• Act relationship – an association between two Acts. This includes Act to Act associations such as
collector/component, predecessor/successor, and cause/outcome. The semantics of the associationis
captured by the Act Relationshipattributes.
0..1 scopes

19. RIM Core Classes
Entity
classCode : CS
determinerCode: CS
code: CE
statusCode : CS
id : II
Role
classCode : CS
code: CE
effectiveTime : IVL<TS>
statusCode : CS
id : II
Participation
typeCode : CS
time : IVL<TS>
statusCode : CS
Act
classCode : CS
moodCode: CS
code: CD
statusCode : CS
effectiveTime : GTS
id : II
0..*
1
0..*
1
0..*
Role Link
typeCode : CS
effectiveTime : IVL<TS>
Act Relationship
typeCode : CS
0..*
0..1 plays
Role Link – An association
between two Roles. It is
used to capture relationships
that exists between Entities
other than the scoping
relationships.
0..1 scopes
1 1
0..* 0..*
1 1
0..* 0..*

20. Definition of RIM Core Classes
• Act – a discernible action of interest in the healthcare domain. An instance of Act is a record of that
action. Acts definitions (master files), orders, plans, and performance records (events) are all
represented by an instance ofAct.
• Act relationship – an association between two Acts. This includes Act to Act associations such as
collector/component, predecessor/successor, and cause/outcome. The semantics of the association is
captured by the Act Relationship attributes.
• Entity - a physical thing or an organization/group of physical things capable of participating in
Acts. This includes living subjects, organizations, material, and places.
• Participation – an association between a Role and an Act representing the function assumed by
the Role within the context of the Act. A single Role may participate in multiple Acts and a single Act
may have multiple participating Roles. A single Participation is always an association between a
particular Role and a particularAct.
• Role – a classification/specialization of an Entity defined by the relationship of the playing Entity
to a scoping Entity. An example of Role is “Employee”. An employee is a classification attributed to a
person which has an employment relationship with an organization (Employer).
• Role Link – An association between two Roles. It is used to capture relationships that exists between
Entities
other than the scoping relationships. A single Role may have a Role Link
with multiple other Roles. A single Role Link is always between two distinct instances ofRole.

21. Sample HL7 v3 Message Schema

22. Sample HL7 v3 Message

23. Clinical Document Architecture (CDA)
The HL7 Clinical Document Architecture
(CDA) is a document markup standard that
specifies the structure and semantics of
"clinical documents" for the purpose of
exchange.

24. Clinical Document
• A clinical document is a documentation of clinical observations and services, with
the following characteristics:
 Persistence – A clinical document continues to exist in an unaltered state, for a
time period defined by local and regulatory requirements.
 Stewardship – A clinical document is maintained by an organization entrusted
with its care (custodian).
 Potential for authentication - A clinical document is an assemblage of
information that can be legally authenticated.
 Context - A clinical document establishesthe default context for its contents.
 Wholeness - Authentication of a clinical document applies to the whole and
does not apply to portions of the document without the full context of the
document.
 Human readability – A clinical document is human readable.
• A CDA document is a defined and complete information object that can include
text, images, sounds, and other multimedia content.

25. Clinical Document Architecture
Clinical Document
Header
(Part 1)
• The clinical document clone is theentry
point of the CDA RMIM.
• Relevant attributes of the clinical
document clone are:
• ID - Represents the uniqueinstance
identifier of a clinicaldocument
• Code - The code specifyingthe
particular kind of document
• Title - The title of the documentas
specified by the documentauthor
• Effective Time -Signifies the
document creation time, whenthe
document first came intobeing

26. Clinical Document Architecture
Clinical Document
Header
(Part 2)
• Additional clones appearing inthe
Clinical Document Headerinclude:
• Parent Document - the source of a
document revision, addenda, or
transformation.
• Service Event - the main Act being
documented (e.g., a colonoscopy or
an appendectomy).
• Order – the orders that are fulfilledby
this document.
• Consent - the consentsassociated
with this document.
• Encompassing Encounter - the
setting of the clinical encounterduring
which the documented act(s) or
ServiceEvent occurred.

27. Clinical Document Architecture
• Additional clones appearing inthe
Clinical Document Headerinclude:
• Parent Document - the source of a
document revision, addenda, or
transformation.
• Service Event - the main Act being
documented (e.g., a colonoscopy or
an appendectomy).
• Order – the orders that are fulfilledby
this document.
• Consent - the consentsassociated
with this document.
• Encompassing Encounter - the
setting of the clinical encounterduring
which the documented act(s) or
ServiceEvent occurred.
Clinical Document
Participating
Entities
•
• This section includes clones of entities and roles
related as participants of the clinical document.
Key participations include:
•
•
•
•
•
• Record Target - the medical record that the
clinical document belongs to.
Author - the humans and/or machines that
authored the document.
Custodian - the organization that is in charge of
maintaining the document.
Information Recipient - an entity to whom a
copy of a document is directed, at the time of
document authorship.
• Lesser participation types include:
Authenticator, Legal Authenticator, Data
Enterer, and Informant.
Participant - other participants not explicitly
mentioned by other cloned, that were somehow
involved in the documented acts.

28. Clinical Document Architecture
Clinical Document
Body
• The CDA body can be either an
unstructured blob, or can be
comprised of structuredmarkup.
• Every CDA document has exactly
one body, associated with the
Clinical Document class through
the component relationship.
• The Non-XML Body class
represents a document body that
is in some format other thanXML.
• The Structured Body class
represents a CDA documentbody
that is comprised of one or more
document sections.

29. Clinical Document Architecture
Document
Section
Entries
• Entries are the structured computer-
processable components of a clinical
document section.
• The current set of CDA entries have been
developed in response to identified
requirements and scenarios that are in
CDA's scope.
• The model for CDA entries is derived
from the shared HL7 ClinicalStatement
model.
• The Clinical Statement model, which
provides a consistent representationof
clinical observations and acts across
various V3 specifications.

30. CDA RMIM Subset UML Class Diagram
• Entries are the structured computer-
processable components of a clinical
document section.
• The current set of CDA entries have been
developed in response to identified
requirements and scenarios that are in
CDA's scope.
• The model for CDA entries is derived
from the shared HL7 ClinicalStatement
model.
• The Clinical Statement model, which
provides a consistent representationof
clinical observations and acts across
various V3 specifications.
• The key classes of the clinical statement model
include:
•
•
•
•
•

31. Specification Profiling
• Entries are the structured computer-
processable components of a clinical
document section.
• The current set of CDA entries have been
developed in response to identified
requirements and scenarios that are in
CDA's scope.
• The model for CDA entries is derived
from the shared HL7 ClinicalStatement
model.
• The Clinical Statement model, which
provides a consistent representationof
clinical observations and acts across
various V3 specifications.
• The key classes of the clinical statement model
include:
•
•
•
•
•
During specification profiling specification models and published specifications are further refined toproduce
a specification profile for use in a particular environment by a defined community of users. The primary
deliverable produced during specification profiling is a set of specification constraints and conformance
statements.
Specification
Profiling
Specification
Constraint and
Conformance
Statements
1. Identify community of user for the published specification
2. Further refine and constrain specification designmodels
3. Document exceptions, extensions, and annotations tospecifications
4. Prepare and publish specification profile
5. Prepare and publish conformance statements
Published
Specification

32. Terminology Binding
• Terminology bindings adhere to HL7 Vocabulary Working Group best practices,
and include both a conformance verb ( SHALL , SHOULD , MAY, etc.) and an
indication of DYNAMIC vs. STATIC binding.
• The use of SHALL requires that the component be valued with a member from
the cited terminology; however, in every case any HL7 "nullflavor" value such
as other (OTH) or unknown (UNK) may be used.
• STATIC binding means that the allowed values of the value set do not change
automatically as new values are added to a value set. That is, the binding is to a
single version of a value set.
• DYNAMIC binding means that the intent is to have the allowed values for a coded
item automatically change (expand or contract) as the value set is maintained over
time.

33. CDA Template Profiles
• A template is a collection of conformance statements
• A conformance statement is a collection of constraints
Usage
• Shall
• Should
• May
Terminology
• Code System
• Code System Term
• Value Set
Cardinality
• Min: O, 1, N
• Max: 1, N, *

34. C-CDA Document Types
1. Continuity of Care Document (CCD)
2. Consultation Notes
3. Discharge Summary
4. Diagnostic Imaging Reports (DIR)
5. History and Physical (H&P)
6. Operative Note
7. Progress Note
8. Procedure Note
9. Unstructured Documents

35. HL7 FHIR
HL7 Information
Exchange
Standards
Version 2
Messaging
Version 3
Messaging
Clinical
Document
Architecture
Fast Healthcare
Interoperability
Resources
Fast Health Interoperability Resources is
HL7’s most recent standards framework. It
combines the best features of HL7’s v2, v3,
and CDA product lines.
FHIR leverages web standards and applies
a tight focus on implementation concerns.

36. FHIR BASICS
• FHIR solutions are built from a set of modular components called
“Resources”.
• Resources can be assembled into data objects and services that
solve clinical and administrative problems faster, better, cheaper.
• Resources are:
– Small, discrete concepts that can be maintained independently
– Aligns with RESTful design philosophy
– Similar to the concept of:
• Segment in HL7 v2
• RIM class in HL7 v3
• RMIM clone in HL7 CDA
– Each resource has a unique id
– Resources are smallest units of transaction

37. FHIR BASICS Contd.
• Includes built-in extension mechanism
– Extensions are defined using name, value, link-point
– Elements used by 80% of implementers are part of the base
resource.
• All other elements are handled as extensions
• Extension is not a “dirty word” in FHIR
– Wire format remains stable, even as extensions occur

38. Resource anatomy
• Resources have 3 parts
Extensions
Narrative
Defined
Structured Data

39. FHIR Resource
Human Readable
Summary
StandardData
Content:
 MRN
 Name
 Gender
 Date of Birth
 Provider
Extension with reference
to its definition

40. FHIR Resource Catalog

41. FHIR Resource
FHIR resources are
described in several
different ways
• a hierarchical table that presents a
logical view of the content
• a UML diagram thatsummarizes
the content graphically
• a pseudo-XML syntax that
provides a visual sense of what
the end resource instances will
look like in XML
• a pseudo-JSON syntax that
provides a visual sense of what
the end resource instances will
look like in JSON
• a pseudo-Turtle syntax that
provides a visual sense of what
the end resource instances will
look like in Turtle

42. FHIR Patient Resource
and IG Patient Resource Profiles
• a hierarchical table that presents a
logical view of the content
• a UML diagram thatsummarizes
the content graphically
• a pseudo-XML syntax that
provides a visual sense of what
the end resource instances will
look like in XML
• a pseudo-JSON syntax that
provides a visual sense of what
the end resource instances will
look like in JSON
• a pseudo-Turtle syntax that
provides a visual sense of what
the end resource instances will
look like in Turtle
FHIR Patient Resource BSeR Patient Resource Profile VRDR Patient Resource Profile
Patient Patient Patient
Patient.identifier 0..* Patient.identifier 1..* Patient.extension:race 0..*
Patient.active 0..1 Patient.name 1..* Patient.extension:ethnicity 0..1
Patient.name 0..* Patient.name.use 1..1 Patient.extension:birthsex 0..1
Patient.telecom 0..* Patient.name.family 1..1 Patient.identifier 1..*
Patient.gender 0..1 Patient.name.given 1..* Patient.name:legalName 1..1
Patient.birthDate 0..1 Patient.telecom 0..* Patient.name:legalName.use 1..1
Patient.deceased 0..1 Patient.telecom.system 1..1 Patient.name:legalName.family 0..1
Patient.address 0..* Patient.telecom.value 1..1 Patient.name:legalName.given 0..*
Patient.maritalStatus 0..1 Patient.telecom.use 1..1 Patient.name:aliasName 0..*
Patient.multipleBirth 0..1 Patient.gender 1..1 Patient.name:aliasName.use 1..1
Patient.photo 0..* Patient.birthDate 1..1 Patient.name:aliasName.family 0..1
Patient.contact 0..* Patient.address 0..1 Patient.name:aliasName.given 0..*
Patient.contact.relationship 0..* Patient.address.text 0..1 Patient.gender 1..1
Patient.contact.name 0..1 Patient.address.line 0..* Patient.birthDate 1..1
Patient.contact.telecom 0..* Patient.address.city 0..1 Patient.address:residential 1..1
Patient.contact.address 0..1 Patient.addres.state 0..1 Patient.address:residential.extension:cityLimit 1..1
Patient.contact.gender 0..1 Patient.address.postalCode 0..1 Patient.address:residential.type 1..1
Patient.contact.organization 0..1 Patient.address.country 0..1 Patient.address:residential.line 0..*
Patient.contact.period 0..1 Patient.communication 0..1 Patient.address:residential.city 0..1
Patient.communication 0..* Patient.communication.language 1..1 Patient.address:residential.state 0..1
Patient.communication.language 1..1 Patient.communication.preferred 0..1 Patient.address:residential.postalCode 0..1
Patient.communication.preferred 0..1 Patient.address:birthPlace 0..1
Patient.generalPractitioner 0..* Patient.address:birthPlace.type 1..1
Patient.managingOrganization 0..1 Patient.address:birthPlace.city 0..1
Patient.link 0..* Patient.address:birthPlace.state 0..1
Patient.link.o ther 1..1 Patient.address:birthPlace.country 0..1
Patient.link.ty pe 1..1 Patient.maritalStatus 0..1

43. Terminology Binding
• a hierarchical table that presents a
logical view of the content
• a UML diagram thatsummarizes
the content graphically
• a pseudo-XML syntax that
provides a visual sense of what
the end resource instances will
look like in XML
• a pseudo-JSON syntax that
provides a visual sense of what
the end resource instances will
look like in JSON
• a pseudo-Turtle syntax that
provides a visual sense of what
the end resource instances will
look like in Turtle
Specification Data Element
- identifier: ST
- type: CD
codeSystem.identifier: ST [0..1]
- codeValue: ST [0..1]
name: ST
- valueSet.identifier: ST [0..1]
- /codeSystemTerm.identifier: ST [0..1]
- /valueSetMemberIdentifier: ST [0..1]
Code System
- identifier: ST
- name:ST
- OID:Uid
Code System Term
- codeValue: ST
- codeSystem.identifier: ST
- /identifier: ST
- name: ST
Value Set Member
- codeValue: ST
- codeSystem.identifier: ST
- preferredName: ST [0..1]
- /identifier: ST
- valueSet.identifier: ST
- /codeSystemTerm.identifier: ST
Value Set
- identifier: ST
- name:ST
- OID:Uid
0..* 0..*
1
0..* -
0..1
0..*
0..1
0..*
0..1
Terminology Binding
0..*
0..* -
0..1

44. THANKS!
Dr Pankaj Gupta
Head – ACCESS Health Digital
digital.health@accessh.org
Twitter: @pankajguptadr, @accesshdigital
LinkedIn: drpankajgupta, accesshdigital