UPES II Session2 V1

Healthcare Applications
& HL7-2
CDA and HL7 V3
2015 IBM Corporation

Learning Objectives
Understand the Clinical Document Architecture and its components
Describe the HL7 V3 Releases 1 & 2
Understand the CDA message specifications
Understand the Model driven standards and RIM
Describe HL7 CDA schemas
Understand the methodology to develop CDA specifications
HL7 V2.x to V3 Transformation example
2015 IBM Corporation 2 Innovation Centre for Education

Limitations of HL7 2.x
Implicit information model, not explicit
Events not tightly coupled to profiles
Need for controlled vocabularies
Limited to a single encoding syntax
No explicit support for object technologies
No explicit support for security functions
Optionality is ubiquitous and troublesome
Ad Hoc design methodology

Version 3 Goals
Provide a framework for coupling events,
data elements and messages
Improve clarity and precision of specification
Improve adaptability of standards to change
Begin to approach plug and play
Conceptual A single, common reference information model to be used

across HL7
foundation
Semantic Explicitly defined concept domains drawn from the best
terminologies
foundation
Abstract design That is technology-neutral
Able to be used with whatever is the technology de jour
methodology XML, UML, etc.
Maintain a Database of the semantic content

Ensures a single source and enable development of support
repository tooling

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

An HL7 Version 2.X Spec
Chapter-
Chapter-
Chapter-
Chapters Common Specific
Specific Chapters
Specific
Specs Specs
Specs 3, 4, 6, ...
2 and 8 Specs
Trigger
Segment Event
s and and
Fields Message
s

Contents of Existing HL7 V2.X
Trigger Actions or occurrences

events
Messages Information content
Segments Repeating structures
Data Data representation

elements

An HL7 Version 3.X Spec
HL7
Referenc
e Model Chapter
-
Commo Specific
n Specs Specs
*Future
Consideratio
n
Message Model Implementable

Information
Use Case Interaction Message
Implementable
Model 2-nd Order Specification
Model Model Message
Implementable
1 choice of Specification
Message
0-n Drug Specification
XML/ER7/
0-1 Nursing OLE/CORBA
EDIFACT*

Benefits of V3 to Providers
Deals with complexity of the HC environment:

Facilitates integration of
heterogeneous systems
u Increases choices of innovative
best-of-breed solutions
u Provides support for legacy systems
u Allows reliable verification of
vendors conformance claims
9
2015 IBM Corporation Innovation Centre for Education
Benefits of V3 to Vendors
Provides improved protocol for

interconnecting heterogeneous systems
Reduces installation effort
reduces site-specific negotiations
simplifies interface programming
Promotes vendor specialization by
allowing segmentation of product
lines into niche market spaces

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

Reference Information Model
The RIM is the cornerstone of HL7 v3 messaging.
The RIM is an UML Model class diagram.
The RIM:
Is the fundamental model from which all v3 messages are
derived
Is a generic, abstract model that expresses the information
content of all the areas of healthcare
Forms a shared view of the healthcare domain, and is used
across all HL7 messages independent of message structure

Normative R6 RIM Class Diagram

Entity and Act
A physical thing or an organization/group of
Entity physical things capable of participating in

Acts. This includes living subjects,
organizations, material, and places.
A discernible action of interest in the

healthcare domain. An instance of Act is a
Act
record of that action. Acts definitions (master
files), orders, plans, and performance records
(events)
are all represented by an
instance of Act.

RIM Core Classes
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
classCode : CS classCode : CS
determinerCode: CS 0..* 0..* moodCode: CS
code: CE code: CD
statusCode : CS statusCode : CS
id : II effectiveTime : GTS
id : II

RIM Core Classes
Entity Role Act

classCode : CS
determinerCode: CS 1 plays 0..* 0..* 0..*
moodCode: CS
code: CE
code: CE code: CD
effectiveTime : IVL<TS>
statusCode : CS
id : II
id : II

RIM Core Classes
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).
Entity Role Act

0..1 plays classCode : CS
determinerCode: CS 0..* moodCode: CS
code: CE 0..* 0..*
code: CE code: CD
effectiveTime : IVL<TS>
0..1 scopes statusCode : CS
id : II 0..*
effectiveTime : GTS
id : II
id : II

RIM Core Classes
Act Relationship
Act relationship an association between two Acts.

This includes Act to Act associations such as typeCode : CS
collector/component, predecessor/successor, and

cause/outcome. The semantics of the association is
captured by the Act Relationship attributes. 0..* 0..*
1 1
Entity Role Participation Act

classCode : CS 0..1 classCode : CS
plays classCode : CS
determinerCode: CS 1 1 moodCode: CS
0..* code: CE typeCode : CS
code: CE 0..* 0..* code: CD
effectiveTime : IVL<TS> time : IVL<TS>
0..1
scopes statusCode : CS statusCode : CS
0..* id : II
id : II

RIM Core Classes
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 Role Link Act Relationship
have a Role Link
with multiple other
Roles. A single Role typeCode : CS
Link is always effectiveTime : IVL<TS> typeCode : CS
between two distinct

instances of Role.
0..* 0..* 0..* 0..*
1 1 1 1

0..1 scopes statusCode : CS statusCode : CS
0..* id : II
id : II

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 of Act.
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 particular Act.
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 of Role.

RIM Backbone Classes
Role Link Act Relationship
typeCode : CS
effectiveTime : IVL<TS> typeCode : CS
0..* 0..* 0..* 0..*
1 1 1 1

classCode : CS 0..1
classCode : CS
plays classCode : CS
0..1 scopes statusCode : CS statusCode : CS
0..* id : II
id : II


0..1 statusCode : CS statusCode : CS
id : II scopes effectiveTime : GTS
0..* id : II
id : II


1 plays classCode : CS
1 statusCode : CS statusCode : CS
id : II scopes effectiveTime : GTS
0..* id : II
id : II
Observation
Supply
Patient Encounter
Procedure
Living Subject Licensed Entity Device Task
Place Patient Substance Administration

Managed Participation
Organization Access Financial Transaction
Material Employee Invoice Element
Financial Contract
Account
Working List
Control Act
HL7 RIM Class Diagram

0..1 classCode : CC
classCode : CC plays
0..* classCode : CS 1 typeCode : CS 1 moodCode : CS
determinerCode : CS
effectiveTime : IVL<TS> 0..* time : IVL<TS> 0..* statusCode : CS
statusCode : CS
0..1 code: CE statusCode : CS code: CD
scopes
code: CE 0..*
effectiveTime : GTS

RIM Core Attribute Value Sets
Living Subject Observation

Performer
Person Procedure Act
Entity Author
Participation
Organization Supply
Witness Class Code
Class Code Type Code Substance
Material Subject
Place Admin
Destination
... Financial
Entity Role ... Participation Act
0..1 ...
plays classCode : CC
classCode : CC 0..* 1 1
classCode : CS typeCode : CS moodCode : CS
determinerCode : CS 0..* 0..*
effectiveTime : IVL<TS> time : IVL<TS> statusCode : CS
statusCode : CS 0..1
scopes code: CE statusCode : CS code: CD
code: CE
0..* effectiveTime : GTS
Patient
Definition
Provider
Entity Kind Role Intent
Act
Employee
Instance Order
Determiner Class Code Specimen Mood Code
Quantified Event
Code Group Certified
Criterion
Practitioner Innovation Centre for Education
...
Example Component and Process

Coded Structural Attributes
RIM coded attributes with a data type of Coded Simple (CS) are referred to
as structural
A CS data type is assigned to an attribute when the only allowable code
values for the attribute are determined by HL7
There are 18 such attributes in the RIM. Each of them is bound to a
vocabulary value set defined by HL7.
These attributes are referred to as structural because their presence in the
model eliminates the need to include other structural model components such
as classes, generalizations, and associations.
Vocabulary value sets bound to coded structural attributes are
normative.

Coded Structural Attributes
Act.classCode Entity.classCode
Act.moodCode Entity.determinerCode
Act.statusCode Entity.statusCode
ActRelationship.checkpointCode ManagedParticipation.statusCode
ActRelationship.conjunctionCode Participation.contextControlCode
ActRelationship.joinCode Participation.typeCode
ActRelationship.splitCode Role.classCode
ActRelationship.Type Role.statusCode
ActRelationship.contextControlCode RoleLink.typeCode

Act.classCode
3.1.1.1 Act.classCode :: CS (1..1) Mandatory

Vocabulary domain: ActClass (CNE)
Attribute description:
A code specifying the major type of Act that this Act-instance represents.
Constraints:
The classCode domain is a tightly controlled vocabulary, not an external or user-
defined vocabulary.
Every Act-instance must have a classCode. If the act class is not further specified, the
most general Act.classCode (ACT) is used.
The Act.classCode must be a generalization of the specific Act concept (e.g., as
expressed in Act.code), in other words, the Act concepts conveyed in an Act must be
specializations of the Act.classCode. Especially, the classCode is not a "modifier" or
the Act.code that can alter the meaning of a class code. (See Act.code for contrast.)

Act.moodCode
3.1.1.2 Act.moodCode :: CS (1..1) Mandatory

Vocabulary domain: ActMood (CNE)
A code distinguishing whether an Act is conceived of as a factual statement or in some other
manner as a command, possibility, goal, etc.
Constraints:
An Act-instance must have one and only one moodCode value. The moodCode of a single Act-
instance never changes. Mood is not state. To describe the progression of a business activity from
defined to planned to executed, etc. one must instantiate different Act-instances in the different
moods and link them using ActRelationship of general type "sequel". (See
ActRelationship.typeCode.)
Discussion:
The Act.moodCode includes the following notions: (1) event, i.e., factual description of an actions
that occurred; (2) definition of possible actions and action plans (the master file layer); (3) intent,
i.e., an action plan instantiated for a patient as a care plan or order; (4) goal, i.e., an desired
outcome attached to patient problems and plans; and (5) criterion, i.e., a predicate used to
evaluate a logical expression

Act.code
3.1.1.4 Act.code :: CD (0..1)

Vocabulary domain: ActCode (CWE)
A code specifying the particular kind of Act that the Act-instance represents within its
class.
Constraints:
The kind of Act (e.g. physical examination, serum potassium, inpatient encounter,
charge financial transaction, etc.) is specified with a code from one of several,
typically external, coding systems. The coding system will depend on the class of
Act, such as LOINC for observations, etc. Conceptually, the Act.code must be a
specialization of the Act.classCode. This is why the structure of ActClass domain
should be reflected in the superstructure of the ActCode domain and then individual
codes or externally referenced vocabularies subordinated under these domains that
reflect the ActClass structure.

ActRelationship.typeCode
3.1.2.1 ActRelationship.typeCode :: CS (1..1) Mandatory

Vocabulary domain: ActRelationshipType (CNE)
A code specifying the meaning and purpose of every ActRelationship instance. Each of its values
implies specific constraints to what kinds of Act objects can be related and in which way.
Discussion:
The types of act relationships fall under one of 5 categories:
1.) (De)-composition, with composite (source) and component (target).
2.) Sequel which includes follow-up, fulfillment, instantiation, replacement, transformation, etc.
that all have in common that source and target are Acts of essentially the same kind but with
variances in mood and other attributes, and where the target exists before the source and the
source refers to the target that it links back to.
3.) Pre-condition, trigger, reason, contraindication, with the conditioned Act at the source and the
condition or reason at the target.
4.) Post-condition, outcome, goal and risk, with the Act at the source having the outcome or goal
at the target.
5.) A host of functional relationships including support, cause, derivation, etc. generalized under
the notion of "pertinence".

Participation.typeCode
3.1.3.1 Participation.typeCode :: CS (1..1) Mandatory

Vocabulary domain: ParticipationType (CNE)
A code specifying the kind of Participation or involvement the Entity playing
the Role associated with the Participation has with regard to the associated
Act.
Constraints:
The Participant.typeCode contains only categories that have crisp semantic
relevance in the scope of HL7. It is a coded attribute without exceptions and
no alternative coding systems allowed.

Entity.classCode
3.2.1.1 Entity.classCode :: CS (1..1) Mandatory

Vocabulary domain: EntityClass (CNE)
An HL7 defined value representing the class or category that the Entity instance
represents.
Examples:
Person, Animal, Chemical Substance, Group, Organization
Rationale:
Due to the extremely large number of potential values for a code set representing all
physical things in the universe, the class code indicates both the subtype branch of
the Entity hierarchy used as well as a high level classifier to represent the instance of
Entity. This can be used to constrain the eligible value domains for the Entity.code
attribute.

Entity.determinerCode
3.2.1.2 Entity.determinerCode :: CS (1..1) Mandatory

Vocabulary domain: EntityDeterminer (CNE)
An HL7 defined value representing whether the Entity represents a kind-of or a
specific instance.
Examples:
1 human being (an instance), 3 syringes (quantified kind) or the population of
Indianapolis (kind of group)
Rationale:
An Entity may at times represent information concerning a specific instance (the
most common), a quantifiable group with common characteristics or a general type of
Entity. This code distinguishes these different representations.

Entity.code
3.2.1.4 Entity.code :: CE (0..1)

Vocabulary domain: EntityCode (CWE)
A value representing the specific kind of Entity the instance represents.
Examples:
A medical building, a Doberman Pinscher, a blood collection tube, a tissue biopsy.
Rationale:
For each Entity, the value for this attribute is drawn from one of several coding
systems depending on the Entity.classCode, such as living subjects (animal and
plant taxonomies), chemical substance (e.g., IUPAC code), organizations,
insurance company, government agency, hospital, park, lake, syringe, etc. It is
possible that Entity.code may be so fine grained that it represents a single
instance. An example is the CDC vaccine manufacturer code, modeled as a
concept vocabulary, when in fact each concept refers to a single instance.

Role.classCode
3.3.1.1 Role.classCode :: CS (1..1) Mandatory

Vocabulary domain: RoleClass (CNE)
A code specifying the major category of a Role as defined by HL7 vocabulary.

Role.code
3.3.1.3 Role.code :: CE (0..1)

Vocabulary domain: RoleCode (CWE)
A code further specifying the kind of Role.
Discussion:
The Role.code must conceptually be a proper specialization of Role.classCode.
Role.code does not modify Role.classCode. Rather, each is a complete concept or a
Role-like relationship between two Entities, but Role.code may be more specific than
Role.classCode.
The Role.code may not be coded if only an un-coded name for the type of role is
commonly used.

RoleLink.typeCode
3.3.2.1 RoleLink.typeCode :: CS (1..1) Mandatory

Vocabulary domain: RoleLinkType (CNE)
A code specifying the kind of connection represented by this RoleLink, e.g., has-part,
has-authority.

HL7 v3 Process & Artifacts Overview

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

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
Patient Living Subject Event
Activate

Hierarchical Message Definition (HMD)
An HMD is a serialized version of the RMIM in a specific order.

This is the HMD for the Patient LivingSubject Event Activate

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
Patient LivingSubject Event
Activate message

HL7 V3 Artifact Codes
Artifact Code
Application Role AR
D-MIM (Domain Information Model) DM
HMD (Hierarchical Message
HD
Descriptor)
Interaction IN
Message Type MT
R-MIM (Refined Message
RM
Information Model)
Storyboard ST
Storyboard Narrative SN
Trigger Event TE

Example Artifact Identifier

CMET HL7 Definition
A CMET can be envisioned as a message type
Common fragment that is reusable by other message types.

Any message type, including other CMETs, can
reference a CMET.
Message As an example, several committees may require the
use of a common concept, that of a person in the role
of a patient. A CMET can be defined to express this
Element concept as a message type that clones a role played
by a person, with all appropriate attributes.
Type A CMET is derived from a single D-MIM, defined by

the producing committee.
Its content is a direct subset of the class clones and
(CMET): attributes defined in that D-MIM, and does not include

content from other D-MIMs (It does not span D-
MIMs).

HL7 Version 3.0 Data Types
HL7 data types define the structure and constrain the allowable values
of attributes in the RIM.
The HL7 v3 abstract data type specification declares the set of data
types, identifies components of complex types, and defines
relationships between data types.
The HL7 data type implementation technology specification defines
constraints and operations for data types and describes how data
types are to be represented in XML.
Data types are reusable atomic building blocks used to create all HL7
V3 information structures.
Each RIM attribute is assigned one data type; each data type is
assigned to zero, one, or more RIM attribute.

HL7 Version 3.0 Data Types (R1)
AD: Postal Address MO: Monetary Amount

ANY: DataValue ON: Organization Name
BAG: Bag PN: Person Name
BL: Boolean PPD: Parametric Probability Distribution
CD: Concept Descriptor PQ: Physical Quantity
CE: Coded With Equivalents REAL: Real Number
CS: Coded Simple Value RTO: Ratio
ED: Encapsulated Data SC: Character String with Code
EN: Entity Name SET: Set
GTS: General Timing Specification ST: Character String
HIST: History TEL: Telecommunication Address
II: Instance Identifier TN: Trivial Name
INT: Integer Number TS: Point in Time
IVL: Interval UVP: Uncertain Value - Probabilistic
LIST: Sequence
Datatype Class Diagram

HL7 Data Type Packages
AnyDataType
+ DataValue : ANY
QuantityDataTypes
+ BinaryDat a : BIN
+ Boolean : BL
+ IntegerNumber : INT
ConceptDescriptorDataTypes IdentifierDataTypes + MonetaryAmount : MO
+ CodedSimpleValue : CS + ISOObjectIdentifier : OID + PhysicalQuantity : PQ
+ CodedValue : CV + InstanceIdentifier : II + Quantity : QTY
+ CodedWithEquivalents : CE + Ratio : RTO
+ Conc eptDescriptor : CD + RealNumber : REAL
+ ConceptRole : CR
EntityNameDataTypes
Address DataTypes ParameterizedDataTypes TimingExpressionDat atypes
+ EntityName : EN
+ AddressPart : ADXP + Bag : BAG + GeneralTimingSpecification : GTS
+ EntityNamePart : ENXP
+ PostalAndResidentialAddress : AD + Interval : IVL + GeneralTimingSpecificationTerm
+ OrganizationName : ON
+ TelecommunicationAddress : TEL + Sequence : LIST + PointInTime : TS
+ PersonNameType : PN
+ UniversalResourceLocator : URL + Set : SET
+ TrivialName : TN
CharacterStringDatatypes
+ CharacterString : ST
+ EncapsulatedData : ED
+ StringWithCode : SC

Basic Datatype Descriptions
Name Symbol Description
Boolean BL The Boolean type stands for the values of two-valued logic. A Boolean value can be either
true or false.
Encapsulated Data ED Data that is primarily intended for human interpretation or for further machine processing
outside the scope of this specification. This includes unformatted or formatted written
language, multimedia data, or structured information in as defined by a different standard
(e.g., XML-signatures.) Instead of the data itself, an ED may contain only a reference (see
TEL.) Note that the ST data type is a specialization of the ED data type when the ED
media type is text/plain.
Character String ST Text data, primarily intended for machine processing (e.g., sorting, querying, indexing,
etc.) Used for names, symbols, and formal expressions.) Note that the ST data type is a
specialization of the ED data type when the ED media type is text/plain.
Coded Simple Value CS Coded data, consists of a code and display name. 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.
Coded Value CV Coded data, consists of a code, display name, code system, and original text. Used when
a single code value must be sent.
Coded With Equivalents CE Coded data, consists of a coded value (CV) and, optionally, coded value(s) from other
coding systems that identify the same concept. Used when alternative codes may exist.
Concept Descriptor CD Coded data, is like a CE with the extension of modifiers. Modifiers for codes have an
optional role name and a value. Modifiers allow one to express, e.g., "FOOT, LEFT" as a
postcoordinated term built from the primary code "FOOT" and the modifier "LEFT".


Instance Identifier II An identifier to uniquely identify an individual instance. Examples are medical record
number, order number, service catalog item number, etc. Based on the ISO Object
Identifier (OID)
Telecommunication Address TEL A telephone number or e-mail address specified as a URL. In addition, this type
contains a time specification when that address is to be used, plus a code describing
the kind of situations and requirements that would suggest that address to be used
(e.g., work, home, pager, answering machine, etc.)
Postal Address AD For example, a mailing address. Typically includes street or post office Box, city,
postal code, country, etc.
Entity Name EN A name of a person, organization, place, or thing. Can be a simple character string or
may consist of several name parts that can be classified as given name, family name,
nickname, suffix, etc.
Person Name PN A name of a person. Person names usually consist of several name parts that can be
classified as given, family, nickname etc. PN is a restriction of EN.
Organization Name ON A name of an organization. ON name parts are typically not distinguished, but may
distinguish the suffix for the legal standing of an organization (e.g. "Inc.", "Co.", "B.V.",
"GmbH", etc.) from the name itself. ON is a restriction of EN.
Trivial Name TN A restriction of EN that is equivalent with a plain character string (ST). Typically used
for the names of things, where name parts are not distinguished.
Integer Number INT Positive and negative whole numbers typically the results of counting and
enumerating. The standard imposes no bounds on the size of integer numbers.


Decimal number REAL Fractional numbers. Typically used whenever quantities are measured, estimated, or
computed from other real numbers. The typical representation is decimal, where the
number of significant decimal digits is known as the precision.
Physical Quantity PQ A dimensioned quantity expressing the result of measurement. It consists of a real
number value and a physical unit. Physical quantities are often constrained to a certain
dimension by specifying a unit representing the dimension (e.g. m, kg, s, kcal/d, etc.)
However, physical quantities should not be constrained to any particular unit (e.g.,
should not be constrained to centimeter instead of meter or inch.)
Monetary Amount MO The amount of money in some currency. Consists of a value and a currency
denomination (e.g., U.S.$, Pound sterling, Euro, Indian Rupee.)
Ratio RTO A quantity explicitly including both a numerator and a denominator (e.g. 1:128.) Only in
the rare cases when the numerator and denominator must stand separate should the
Ratio data type should be used. Normally, the REAL, PQ, or MO data types are more
appropriate.
Point in Time TS A time stamp.

General Timing Specification GTS One or more time intervals used to specify the timing of events. Every event spans one
time interval (occurrence interval). A repeating event is timed through a sequence of
such occurrence intervals. Such timings are often specified not directly as a sequence of
intervals but as a rule, e.g., "every other day (Mon - Fri) between 08:00 and 17:00 for 10
minutes."

ED: Encapsulated Data
Name Type Status Definition

BIN BIN mandatory The binary data.
type CS mandatory Identifies the encoding of the data and a method to interpret the data.
charset CS optional Where applicable, specifies the character set and character encoding
used. The charset may be implied or fixed by the ITS.
language CS optional Where applicable, specifies the language of text data.
compression CS optional Indicates whether the raw byte data is compressed, and what
compression algorithm was used.
reference TEL optional A telecommunication address that resolves to the binary data.
integrityCheck BIN optional A short binary value representing a cryptographically strong checksum
over the binary data.
integrityCheckAlgorithm CS optional Specifies the algorithm used to compute the integrityCheck value.
thumbnail ED optional An abbreviated rendition of the full data.

ST: Character String

data BIN mandatory The binary data of the character string.
charset CS optional Specifies the character set and character encoding used.
language CS optional Specifies the language of text data.

CD: Concept Descriptor
Name Description
code A string containing the value of the code (e.g., "F150")
displayName A string containing a short, human-readable description of the code. ("Ford F150 Full-size Pickup Truck")
codeSystem An Object Identifier (OID) that uniquely identifies the code system to which the code belongs (e.g.,
"106.75.314.67.89.24," where this uniquely identifies Ford Motor Company's set of model numbers).
codeSystemName A string containing a short, human-readable description of the code system (e.g., "Ford Car and Truck Models ").
codeSystemVersion A string qualifying the version of the code system (e.g., "Model Year 2001").
originalText This is the text, phrase, etc., that is the basis for the coding. (e.g., "The new truck purchased for hospital facility
maintenance was a Ford model F150 ...").
modifier Some code systems permit modifiers, additional codes that refine the meaning represented by the primary code.
HL7 Version 3 accommodates a list of modifiers. Continuing with our truck example, the list of modifiers "Body-
ECAB, Eng-V8, EM-CE" modify "F150" to designate that the truck has an extended cab, V8 engine, and California
Emissions package. "Body-," "Eng-," and "EM" designate the roles (body, engine, emissions) represented by the
codes "ECAB," "V8," and "CE."
translation Quite often in an interfaced environment, codes need to be translated into one or more other coding systems. In our
example, the California DMV may have their own code

Concept Descriptor Datatypes
CS: Coded Simple

Name Type Status
code ST mandatory
displayName ST optional
CV: Coded Value

Name Type Status
code ST mandatory
codeSystem OID mandatory

codeSystemName ST optional
codeSystemVersion ST optional
originalText ST optional
CE: Coded With Equivalents

Name Type Status
code ST mandatory
codeSystem OID mandatory
codeSystemName ST optional
codeSystemVersion ST optional
originalText ST optional
translation SET<CV> optional

II: Instance Identifier

extension ST optional The value of the identifier, unique within its assigning authority's namespace.
root OID mandatory A unique identifier that guarantees the global uniqueness of the instance identifier.
The root alone may be the entire instance identifier, an extension value is not
needed.
assigningAuthorityName ST optional A human readable name or mnemonic for the assigning authority. This name is
provided solely for the convenience of unaided humans interpreting an II value.
Note: no automated processing must depend on the assigning authority name to be
present in any form.
validTime IVL<TS> optional If applicable, specifies during what time the identifier is valid. By default, the
identifier is valid indefinitely. Any specific interval may be undefined on either side
indicating unknown effective or expiry time.
Note: identifiers for information objects in computer systems should not have
restricted valid times, but should be globally unique at all times. The identifier valid
time is provided mainly for real-world identifiers, whose maintenance policy may
include expiry (e.g., credit card numbers.)

Tel: Telecommunication Address

URL URL mandatory The essence of a telecommunication address is a Universal Resource Locator.
A code advising a system or user which telecommunication address in a set of like
use SET<CS> optional
addresses to select for a given telecommunication need.
Identifies the periods of time during which the telecommunication address can be
used. For a telephone number, this can indicate the time of day in which the party
validTime GTS optional
can be reached on that telephone. For a web address, it may specify a time range in
which the web content is promised to be available under the given address.

AD: Postal Address
LIST<ADXP> mandatory The address data
A code advising a system or user which address in a set of like addresses to

use SET<CS> optional
select for a given purpose
Identifies the periods of time during which the address can be used. Typically
validTime GTS optional used to refer to different addresses for different times of the year or to refer to
historical addresses.
ADXP: Postal Address Part

ST ST mandatory The address part data
Indicates whether an address part is the street, city, country, postal code, post
type CS optional
box, etc.

EN: Entity Name
Name Type Status Default Constraint Definition

LIST<ENXP> mandatory NULL The name data
use SET<CS> optional NULL NamePurpose A code advising a system or user
which name in a set of names to select
for a given purpose
validTime IVL<TS> optional NULL Identifies the interval of time during

which the name was used. Typically
used to record historical names.
ENXP: Entity Name Part

ST mandatory NULL The entity name part data
type CS optional NULL EntityNamePartType Indicates whether the name part is a
given name, family name, prefix,
suffix, etc.
qualifier SET<CS> optional NULL EntityNameQualifier A set of codes each of which specifies
a certain subcategory of the name part
in addition to the main name part type
Entity Name Specializations:

TN: Trivial Name
PN: Person Name
ON: Organization Name Innovation Centre for Education
RTO: Ratio

numerator QTY mandatory The numerator of the ratio.
The denominator of the ratio
denominator QTY mandatory The QTY data type is an abstract generalization that stands for INT, REAL, PQ,
and MO.

PQ: Physical Quantity

value REAL mandatory The magnitude of the quantity measured in terms of the unit
unit CS mandatory The unit of measure
original value REAL optional The magnitude of the quantity measured in terms of the original unit.
original unit CV optional The original unit of measure.

MO: Monetary Amount

The magnitude of the monetary amount in terms of
value REAL mandatory NULL
the currency unit.
currency CS mandatory NULL ISO 4217 The currency unit

Additional Datatypes and Aggregates
BL: Boolean SET

INT: Integer LIST
Real: Real BAG
Precision :: Int
TS: Point in Time
Offset :: PQ IVL
Low
Calendar :: CS
Center
Precision :: INT Width
Timezone :: PQ High
Messaging Artifacts
RMIM - VSD
Repository - MDB
Hierarchical Message Description - HMD
Schemas - XSD
Test Data Spread Sheet - XLS
Test Message XML
Datatype definition - datatypes.xsd
Vocabulary definition - voc.xsd

HL7 V3 Message Structure
A HL7 V3 Message wrapper

conformant Sender
xml Receiver
message
has the Responder
following ControlAct wrapper
components: Message Payload

The Message Wrapper
Receiver
Sender

Sample Message Payload 1
Payload

Software Packages
Following software packages are required

Published by HL7 (www.hl7.org)
RoseTree
RMIM Designer
Schema Generator
Open source software from the Apache Software Foundation (www.apache.org)
ANT
JUNIT and XMLUNIT
JAVA API for parsing MS Excel

Steps to Design New Message Type

Designing a Simple R-MIM
Microsoft Visio 2002

Tools HL7 R-MIM
designer
used: RIM Repository
V2.01.4

HL7 2.x and V3
In this example we discuss on V2.4 ORU^R01 for serum glucose and an equivalent V3
message instance

V3 Equivalent Message
Root Element
Payload Controlact Event
... <id root="2.16.840.1.113883.1122" extension="CNTRL-3456"/>  <creation_time value="2002-08-16T14:30:35.16-
06:00"/>  <version_id>3.0</version_id> <interaction_id root="2.16.840.1.113883" extension="POLB_IN004410"/>  Notification (POLB_IN004410) source=ORU^R01-->  <processingModeCode code="I"/> 
<acceptAckCode code="ER"/>   <applicationAckCode code="ER"/> 
<communicationFunctionRsp>  <type_cd code="RSP"/> <telecom use="WP" url="555-555-5555"/>
<servedBy> <nm xsi:type="dt:PN"> <dt:family>Hippocrates</dt:family> <dt:given>Harold</dt:given> <dt:given>H</dt:given> <dt:suffix
qualifier="AC">MD</dt:suffix> </nm> <telecom use="WP" url="555-555-5555"/> </servedBy> </executedByRespondToOrg> <executedBySendApp>
<type_cd code="SND"/> <telecom value="127.127.127.255"/> <servedBy>  <id extension="GHH LAB"
root="2.16.840.1.113883.1122"/> <nm use="L"> <given>An Entity Name</given> </nm> <telecom value="555-555-2005" use="H"/> <agencyFor>  <representedOrganization> <id nullFlavor="OTH"/> </representedOrganization> </agencyFor> <presence> <location> <id
root="2.16.840.1.113883.1122" extension="ELAB-3"/> <nm xsi:type="dt:TN">GHH Lab</nm> </location> </presence> </servedBy>
</executedBySendApp> <executedByRcvApp> <type_cd code="RCV"/> <telecom value="127.127.127.0"/> <servedBy>  <id root="2.16.840.1.113883.1122" extension="GHH OE"/> <nm use="L"> <given>An Entity Name</given> </nm> <telecom value="555-
555-2005" use="H"/> <agencyFor> <representedOrganization> <id root="2.16.840.1.113883.19.3.1001"/> <nm xsi:type="TN">GHH Outpatient
Clinic</nm> </representedOrganization> </agencyFor> <presence> <location> <id root="2.16.840.1.113883.1122" extension="BLDG4"/> <nm
xsi:type="TN">GHH Outpatient Clinic</nm> </location> </presence> </servedBy> </executedByRcvApp> <has_payload_ControlActEvent
xsi:type="MCAI_HD700200"> ... </has_payload_ControlActEvent> </Message>

The Control Act

Message Body

The Original Order

The Performing Provider
The Patient

CDA
Clinical Document Architecture

Clinical Documents
Historically, all clinical documents used in Healthcare industry are human readable and they
contain a mix of discrete data and free-flowing physicians narrative.
Discharge
Summary
Clinical
Diagnostic Summary
Reports
(DI, lab) Report,
Referrals
Clinical
Document
Public History &

health Physical
examination
report
Medication
Prescription
Rx
Not limited to above it can be any other document having valid signatures from different
players in healthcare provider industry

Sample Clinical Document
Header
Document Type
Sender
Receiver
Patient
Body
T Section(s)
E Admission Details
Primary/Secondary
X Diagnosis
T Observations
Medications
Follow-up
C Entries
O Admission Details
D Primary/Secondary
E Diagnosis
D Observations
Medications

Clinical Document Architecture
HL7 CDA
A document markup standard that specifies
structure & semantics of clinical documents
for the purpose of exchange
Focuses on document exchange, not

message exchange
A document is packaged in a message

during exchange
CDA is based on XML
In XML, structure & format are conveyed by

markup which is embedded into the
information

Characteristics of CDA
Persistence
Human Stewardshi
Readability p
CDA
Characteristics
Wholeness Authentication
Context

6 Characteristics of a CDA Document
A clinical document continues to exist in an unaltered state, for a time

Persistence period defined by local and regulatory requirements
Context A clinical document establishes the default context for its contents
Potential for A clinical document is an assemblage of information that is intended to

be legally authenticated
authentication
Authentication of a clinical document applies to the whole and does not
Wholeness apply to portions of the document without the full context of the
document.
Human readability A clinical document is human readable
A clinical document is maintained by an organization entrusted with its

Stewardship care.

Brief History of CDA
Level 1 Generic document structure (section,

paragraphs, list, tables)
domain-specific document types

Level 2 document ontology
constrainable for (domain-) compliant content
Level 3 fine-grained definitions / markup as defined

in the RIM

Design Principles of CDA
Must be compatible with XML & HL7 RIM
Must be compatible with representations of

clinical information arising from other HL7
committees
Technical barriers to use of CDA should be

minimized
Specifies representation of instances

required for exchange
Must be scalable to accommodate fine-

grained markup such as highly structured
text & coded data
CDA Documents must be human readable

with widely available XML aware browsers
and standard style sheet

CDA Information Model
Participations Clinical Related

Clinical Statements
Document Documents
Non-XML
or
Structured
Body
Observatio Linked
n Artifacts
Procedure
Medicatio
n
Record
Target Encounter
Custodian Nested Sections
with Narrative
Ext.
CDA Header CDA Body CDA Entries
Ref.

Body Structure
Sections and Human readable text

Key Aspects and scope of CDA
CDA documents are encoded in XML

CDA documents derive their machine
Key Aspects processable meaning from HL7 RIM
of CDA and use HL7 V3 Data Types
CDA specification is richly expressive
& flexible
Standardization of clinical documents

Scope of for exchange
CDA Data format of clinical documents
outside of exchange context
For example, the data format used to store clinical

documents are not bound by CDA specifications

Components of CDA Document
CDA = Header + Body

Header
Metadata requires for document discovery,
management, retrieval
Body
Section
Entry (machine processable)
Narrative Block (human readable)

Main Components of CDA
<ClinicalDocument>
Header
...
<StructuredBody>
<Section>
<text>...</text> Narrative Block
<Observation>
...
</Observation> S D
E
<Observation> E O
N
C B C
<reference> T
T O U
<ExternalObservation>External R
I D M
References I
... O Y E
E
</ExternalObservation> N N
S
S T
</reference>
</Observation>
</Section>
<Section>
<Section>...</Section>
</Section>
</StructuredBody>
</ClinicalDocument>

Section structure
<Section>
<code code="10153-2" codeSystem="LOINC">Anamnese</code>
<text>
<list>
<item><content>Asthma</content></item>
<item><content>High Bloodpressure</content></item>
<item><content ID="a3">Osteoarthritis, right knee</content></item>
</list>
</text>
<entry>
<contextConductionInd value="TRUE"/>
<Observation classCode="COND">
<code code="G-1001" codeSystem="SNOMED" displayName="prior diagnosis"/>
<value code="D1-201A8" codeSystem="SNOMED" displayName="Osteoarthritis">
<originalText><reference value="#a3"/></originalText>
</value>
<targetSiteCode code="T-15720" codeSystem="SNOMED" displayName="Knee">
<qualifier>
<name code="G-C220" codeSystem="SNOMED" displayName="Laterality"/>
<value code="G-A100" codeSystem="SNOMED" displayName="right"/>
</qualifier>
</targetSiteCode>
</Observation>
</entry>
</Section>

Rendering CDA Documents

Rendering CDA Documents (2)
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

CDA Levels are
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.

Release 1: defined Level One, Level Two only

Release 2: Levels One,Two, Three

CDA Header and Body
Main CDA elements : Header
Body

CDA Body
Body
Preferred non-XML
document types:
text/rtf
text/html
text/plain
application/pdf
image/g3fax
image/gif
image/tiff
image/jpeg
image/png
Body Narrative Text

Body Narrative Text (Table)
Result
Example

Body Narrative Text (List)
Example
Result

Body Structured Body (Human Readable)
<section>
<caption>
<captionCode V="114967" S=LOINC"/>
Narrative
Allergies and Adverse Reactions
</caption>
<list>
<item><content ID=A1>Penicillin Hives</content></item>
<item><content>Aspirin Wheezing</content></item> REQUIRED
<item>
<content>Codeine Itching and nausea</content>
</item>
</list>
<coded_entry>
Computable
<coded_entry.value ORIGTXT=A1 V="DF10074" S=SNOMED DN=Allergy to Penicillin/>
</coded_entry>
</section>

Body - Structured Body (Machine Processible)
<text>
Narrative
<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"
Computable
codeSystem="2.16.840.1.113883.6.96" displayName="Hives">
<originalText><reference value="#A1"/></originalText>
</value>
OPTIONAL
<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"/>

Entries
Structure Body Entries - observation

Machine Processible

Entries observation (Example)

Responsibilities of CDA document receiver
Assume default values where they are defined in this

specification, and where the instance does not contain a value
Parse and interpret the complete CDA header
Parse and interpret the CDA body sufficiently to be able to

render it
If the CDA Body is non-XML, it need not be rendered

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)
Inter-institutional
Exchange of parts of medical records (scanned or structured electronic health records)
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

Unlocking the power of Healthcare with standards
Unlocking the power of Healthcare with standards

Thank You

Quick Recap
HL7 Standard doesnt specify

Error free communication protocol
Programmatic means to transmit and receive HL7 messages
Doesnt specify any programmatic means to convert the characters, strings etc..,
HL7 domains refer to

An area of interest
Special interest groups
HD data type is typically used in PID to assign patient ID
ADT^A04 is used to register a patient
Name 6 core classes of HL7 RIM
HL7 RIM Doesnt define any logical, physical model or design standards
There are Control Act and Transmission Wrappers in HL7 V3
HL7 V3 artifact documents are uniquely identified by
Subsection, Domain, Artifact code, 6 digit number, Realm and Version number

UPES II Session2 V1

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

UPES II Session2 V1

Uploaded by

Copyright:

Available Formats

Healthcare Applications

CDA and HL7 V3

2015 IBM Corporation

2015 IBM Corporation 2 Innovation Centre for Education

Implicit information model, not explicit

Events not tightly coupled to profiles

Need for controlled vocabularies

Limited to a single encoding syntax

No explicit support for object technologies

No explicit support for security functions

Optionality is ubiquitous and troublesome

Ad Hoc design methodology

2015 IBM Corporation 3 Innovation Centre for Education

Conceptual A single, common reference information model to be used

Maintain a Database of the semantic content

2015 IBM Corporation 4 Innovation Centre for Education

v3 is approaching Plug and Play

v3 is a brand new start it is NOT backward compatible with v2

2015 IBM Corporation 5 Innovation Centre for Education

2015 IBM Corporation 6 Innovation Centre for Education

Trigger Actions or occurrences

Messages Information content

Segments Repeating structures

Data Data representation

2015 IBM Corporation 7 Innovation Centre for Education

Message Model Implementable

2015 IBM Corporation 8 Innovation Centre for Education

Deals with complexity of the HC environment:

Provides improved protocol for

2015 IBM Corporation 10 Innovation Centre for Education

Message sent from sending application to receiving application

Mostly triggered by an event Typical scenario portrayed in a

Message in XML with machine-processable elements conforming to

Data elements in message conform to RIM

Not designed for human readability

2015 IBM Corporation 11 Innovation Centre for Education

The RIM is the cornerstone of HL7 v3 messaging.

The RIM is an UML Model class diagram.

2015 IBM Corporation 12 Innovation Centre for Education

2015 IBM Corporation Innovation Centre for Education

A physical thing or an organization/group of

Entity physical things capable of participating in

A discernible action of interest in the

2015 IBM Corporation 14 Innovation Centre for Education

Entity - a physical thing or an organization/group of physical things

2015 IBM Corporation Innovation Centre for Education

Entity Role Act

2015 IBM Corporation Innovation Centre for Education

Role a classification/specialization of an Entity defined by the

Entity Role Act

2015 IBM Corporation Innovation Centre for Education

Act relationship an association between two Acts.

collector/component, predecessor/successor, and

Entity Role Participation Act

2015 IBM Corporation Innovation Centre for Education

Link is always effectiveTime : IVL<TS> typeCode : CS

between two distinct

Entity Role Participation Act

2015 IBM Corporation Innovation Centre for Education

2015 IBM Corporation Innovation Centre for Education

Role Link Act Relationship

0..* 0..* 0..* 0..*

Entity Role Participation Act