Hl7 advance cda may 2019 webinar

Advance CDA -
Clinical Document
Architecture
AbdulMalik Shakir
® Health Level Seven and HL7 are registered trademarks of Health Level Seven International, registered with the United States Patent and Trademark Office.
05/22/2019 – 05/23/2019

AbdulMalik Shakir
I am an experienced healthcare informatics
standards expert.
I specialize in the application of health information
technology standards for use in:
• health information exchange,
• clinical decision support, and
• semantic interoperability.
My primary area of interest is facilitating the
discovery and application of evidence based best
practices in health care.
® Health Level Seven and HL7 are registered trademarks of Health Level Seven International,
registered with the United States Patent and Trademark Office. 2

AbdulMalik Shakir
• President and Chief Informatics Scientist, Hi3 Solutions
• Active member of HL7 since September 1991
• Co-chair of the HL7 Modeling and Methodology Workgroup
• HL7 Milestones:
• Chaired the HL7 Education Workgroup from 1996 to 2010.
• Received the HL7 volunteer of the year award in 1997
• Served on the HL7 Board of Directors from 2000 to 2005
• Received the HL7 Fellowship award in 2012
• Grandfather of Malika Power Shakir since April 2019

Course Outline
® Health Level Seven and HL7 are registered trademarks of Health Level Seven
International, registered with the United States Patent and Trademark Office.
4
Clinical Data
Architecture
Specification
CDA Technical
Artifacts
Constrained
Information
Models and XML
Schema
CIM Terminology
and Datatype
Components
CDA Information
Model
Consolidated
CDA
Implementation
Guide
Continuity of Care
C-CDA Document

Deep Dive
Advanced
Perspectives
• UML Class Diagram
• XML Schema
• RMIM Design
• Clinical Terminologies
• V3 Templates

Learning Objectives
Upon completion of this
tutorial the participant shall:
1. Understand the components and
features of the CDA standard.
2. Be able to apply the CDA standard
conformance rules when evaluating
the validity of a CDA implementation.
3. Be able to create templates to
constrain the CDA standard for use in
support of a particular use case.
® Health Level Seven and HL7 are registered trademarks of Health Level Seven International, registered with the United States Patent and Trademark Office. 6
Bloom’s Taxonomy

CDA STANDARD SPECIFICATION
https://www.hl7.org/implement/standards/product_brief.cfm?product_id=7

HL7 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.
• The CDA is a constrained refinement of the HL7 v3 Reference Information Model (RIM) specific to the
purpose of clinical document exchange.
• The CDA standard is further constrained via the specification of implementation guides for specific
document types, clinical domains, and document exchange scenarios.
• The CDA is one of the initial set of standards, implementation specifications, and certification criteria
for Electronic Health Record technology specified in USA Meaningful Use legislation.
• The collection of implementation guides developed for CDA are widely adopted by EMR vendors;
secondary users of EMR data are aligning their information requirements with these guides in
anticipation of these data becoming more readily assessable.

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

CDA Technical Artifacts
HL7 Reference
Information Model
• The HL7 RIM is the definitive reference
source for class and attribute definitions.
• The CDA specification does not exhaustively
replicate RIM definitions, but instead refers
the reader to the RIM for complete
definitions.
• While CDA may further constrain RIM
definitions, at no time will CDA definitions
conflict with those in the RIM.
• CDA, Release Two is derived from HL7 RIM,
Version 2.07.
HL7 Vocabulary
Domains
• Vocabulary domains represent value sets
for coded CDA components.
• These domains can include HL7-defined
concepts or can be drawn from HL7-
recognized coding systems such as LOINC
or SNOMED.
• The HL7 Vocabulary chapter is the
definitive reference source for the
definitions of HL7-defined concepts.
• While CDA may further constrain these
definitions, at no time will CDA definitions
conflict with those in the Vocabulary
chapter.
HL7 V3
Data Types
• Data types define the structural format of
the data carried within a RIM attribute and
influence the set of allowable values an
attribute may assume.
• Every attribute in the RIM is associated with
one and only one data type.
• CDA, Release Two uses the HL7 V3 Data
Types, Release One abstract and XML-
specific specification.

CDA TECHNICAL ARTIFACTS

HL7 Reference Information Model

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

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..*
1
0..*
Role Link
typeCode : CS
effectiveTime : IVL<TS>
Act Relationship
typeCode : CS
RIM Core Classes
0..1
0..*
plays
scopes
1 1
0..* 0..*
1 1
0..* 0..*

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.

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
RIM
Restrict
R-MIM
Serialize
HMD
D-MIM
Derive
PatientIncident
classCode*: <= ENC
moodCode*: <= EVN
id: [1..*] (RegistNum)
code: CV CNE [0..1] <= ExternallyDefinedActCodes (PatientType)
statusCode: LIST<CS> CNE <= ActStatus (IDPHStatus)
activityTime: TS (EDDate)
Injury
classCode*: <= ACT
moodCode*: <= EVN
activityTime: TS (InjuryDate)
0..1 pertinentInjury
typeCode*: <= PERT
pertinentInformation1
TraumaRegistryExport
(IDPH_RM00001)
Data content of HL7
messages used to export
data from the IDPH Trauma
Registry.
PatientPerson
classCode*: <= PSN
determinerCode*: <= INSTANCE
name: PN [0..1] (*Name)
existenceTime: (Age)
administrativeGenderCode: CV CWE <= AdministrativeGender
(GenderID)
birthTime: (DateOfBirth)
addr: AD [0..1] (AddressHome)
raceCode: CV CWE [0..1] <= Race (RaceID)
ethnicGroupCode: CV CWE [0..1] <= Ethnicity (EthnicID)
1..1 patientPatientPerson
1..1 providerTraumaParticipant
Patient
classCode*: <= PAT
id: II [0..1] (MedicaRecordNum)
TraumaParticipant
classCode*: <= ORG
id: [1..1] (HospitNum)
code: CV CWE [0..1] <= EntityCode
name: ON [0..1] (HospitName)
statusCode: CS CNE [0..1] <= EntityStatus (ActiveFacili)
addr: AD [0..1] (HospitCity)
1..1 patient
typeCode*: <= SBJ
subject
InjuryLocation
classCode*: <= PLC
code: CV CWE [0..1] <= EntityCode (InjuryPlaceID)
addr: AD [0..1] (AddressScene)
0..1 playingInjuryLocation
Role
classCode*: <= ROL
1..1 participant
typeCode*: <= LOC
location
InjuryRelatedObservation
classCode*: <= OBS
moodCode*: <= EVN
code: <= ExternallyDefinedActCodes
priorityCode: CV CWE [0..1] <= ActPriority
value: [0..1]
0..* pertinentInjuryRelatedObservation
typeCode*: <= PERT
sequenceNumber: INT [0..1] (InjurySequen)
pertinentInformation
Procedure
classCode*: <= PROC
moodCode*: <= EVN
code: CV CWE <= ActCode (ICDCodeID)
activityTime: TS (ProcedDate)
0..* pertinentProcedure
typeCode*: <= PERT
0..1 medicalStaff
typeCode*: <= PRF
performer
MedicalStaff
classCode*: <= PROV
id: II [0..1] (MedicalStaffID)
0..1 procedureLocation
typeCode*: <= LOC
location
ProcedureLocation
classCode*: <= SDLOC
code: <= RoleCode (ProcedLocateID)
PatientIncidentRelatedObservation
classCode*: <= OBS
moodCode*: <= EVN
code: <= ActCode
reasonCode: CV CWE [0..1] <= ActReason
value: ANY [0..1]
0..* pertinentPatientIncidentRelatedObservation
typeCode*: <= PERT
PatientTransfer
classCode*: <= TRNS
moodCode*: <= EVN
activityTime: IVL<TS> (DischaDate to ArriveDate)
reasonCode: CV CWE [0..1] <= TransferActReason (REASONTRANSFID)
1..1 arrivalPatientTransfer
typeCode*: <= ARR
arrivedBy
0..* aRole
typeCode*: <= ORG
origin
0..1 playingTraumaParticipant
aRole
classCode*: <= ROL
TransferRelatedObservation
classCode*: <= OBS
moodCode*: <= EVN
code: CV CWE <= ExternallyDefinedActCodes
value: PQ [0..1]
methodCode: CV CWE [0..1] <= ObservationMethod
1..* pertinentTransferRelatedObservation
typeCode*: <= PERT
1..1 transferVehicle
typeCode*: <= VIA
via
1..1 owningVehicleProvider
TransferVehicle
classCode*: <= OWN
id: II [0..1] (VehiclNum)
code: <= RoleCode (VehiclLevelID)
VehicleProvider
classCode*: <= ORG
id: II [0..1] (VehiclProvide)
code: <= EntityCode (MaxVehiclLevelID)
name: ON [0..1] (VehiclProvidName)
HospitalVisit
classCode*: <= ENC
moodCode*: <= EVN
code: CV CWE <= ActCode (AdmitServicID)
activityTime: TS (DischaDate)
dischargeDispositionCode: CV CWE [0..1]
<= EncounterDischargeDisposition
1..1 pertinentHospitalVisit
typeCode*: <= PERT
HospitalVisitRelatedObservation
classCode*: <= OBS
moodCode*: <= EVN
value: [0..1]
0..* pertinentHospitalVisitRelatedObservation
typeCode*: <= PERT
1..1 admittingProvider
typeCode*: <= ADM
admitter
0..1 healthCareMedicalStaffPerson
AdmittingProvider
classCode*: <= PROV
id: II [0..1] (ADMITMEDICASTAFFID)
code: CV CWE <= RoleCode (StaffTypeID)
0..* hospitalVisitPhysician
typeCode*: <= RESP
time: TS
responsibleParty
HospitalVisitPhysician
classCode*: <= PROV
id: II [0..1]
MedicalStaffPerson
classCode*: <= PSN
name: PN [0..1] (MedicaStaffName)
0..1 licensedEntity
typeCode*: <= DST
destination
0..1 subjectChoice
LicensedEntity
classCode*: <= LIC
id: II [0..1]
Choice
Facility
classCode*: <= ORG
id:
code*: CS CNE <= EntityCode "FAC"
name:
Hospital
classCode*: <= ORG
id:
code*: CS CNE <= EntityCode "HOSP"
name:
EmergencyDepartmentEncounter
classCode*: <= ENC
moodCode*: <= EVN
activityTime: IVL<TS>
dischargeDispositionCode: CV CWE <= EncounterDischargeDisposition
0..1 pertinentEmergencyDepartmentEncounter
typeCode*: <= PERT
EmergencyDepartmentRelatedObservation
classCode*: <= OBS
moodCode*: <= EVN
text:
activityTime: TS
reasonCode: <= ActReason
value: [0..1]
targetSiteCode: CV CWE [0..1] <= HumanActSite
0..* pertinentEmergencyDepartmentRelatedObservation
typeCode*: <= PERT
0..* emergencyDepartmentPhysician
typeCode*: <= PRF
performer
0..1 healthCareMedicalStaffPerson EmergencyDepartmentPhysician
classCode*: <= PROV
id: II [0..1]
code: CE CWE [0..1] <= RoleCode (StaffTypeID)
PreHospitalEncounter
classCode*: <= ENC
moodCode*: <= EVN
id: II [0..1] (crashNum)
0..1 priorPreHospitalEncounter
typeCode*: <= PREV
predecessor
PreHosptialRelatedObservation
classCode*: <= OBS
moodCode*: <= EVN
value: ANY [0..1]
0..* pertinentPreHosptialRelatedObservation
typeCode*: <= PERT
1..1 preHospitalVehicle
typeCode*: <= ParticipationType
participant
PreHospitalVehicle
classCode*: <= OWN
0..* emergencyDepartmentPhysicianAct
typeCode*: <= COMP
component
EmergencyDepartmentPhysicianAct
classCode*: <= ACT
moodCode*: <= EVN
code: CS CNE [0..1] <= ExternallyDefinedActCodes
activityTime*: TS [0..1]
component
0..* patientIncidentRelatedObservation
typeCode*: <= COMP
VehicleProvider
MedicalStaffPerson
TraumaParticipant
A_AbnormalityAssessment
(COCT_RM420000UV)
Description: assessment of clinical findings, including lab test results,
for indications of the presence and severity of abnormal conditions
AbnormalityAssessment
classCode*: = "OBS"
moodCode*: = "EVN"
code*: CD CWE [1..1] <= V:ObservationType ("ADVERSE_REACTION")
statusCode*: CS CNE [1..1] <= V:ActStatusAbortedCancelledCompleted
activityTime*: TS.DATETIME [1..1]
value: CD CWE [0..1] <= V:AbnormalityAssessmentValue
methodCode: SET<CE> CWE [0..*] <= V:AbnormalityAssessmentMethod
1..* assessmentOutcome *
typeCode*: = "OUTC"
contextConductionInd*: BL [1..1] ="true"
outcome
AssessmentException
classCode*: = "OBS"
moodCode*: = "EVN"
code*: CD CWE [1..1] <= V:ObservationType ("ASSERTION")
value*: SC CWE [1..1] <= V:AssessmentExceptionValue
AbnormalityGrade
classCode*: = "OBS"
moodCode*: = "EVN"
code*: CD CWE [1..1] <= V:ObservationType ("SEV")
uncertaintyCode: CE CNE [0..1] <= V:ActUncertainty
value*: CD CWE [1..1] <= V:AbnormalityGradeValue
AssessmentOutcome
0..* assessmentOutcomeAnnotation
typeCode*: = "APND"
appendageOf
AssessmentOutcomeAnnotation
classCode*: = "OBS"
moodCode*: = "EVN"
value*: SC CWE [1..1] <= V:AssessmentOutcomeAnnotationValue

HL7 CDA R-MIM
• HL7 specifications derived from the HL7 RIM use a process known as "cloning" to refine domain specific models from
the base HL7 RIM.
• When a refined model makes use of a specialization of an HL7 RIM class, the new class in the refined model is known
as a clone of the HL7 RIM class.
• These specializations may further constrain the base class, for example, by specifying more restrictive attribute
cardinality or by further constraints on the allowed vocabulary values.
• Multiple clones of a particular HL7 RIM class may appear in a refined model, each representing a different
specialization.
• The CDA R-MIM is a graphical representation of the CDA specification. It is presented using diagramming conventions
and notations that were developed by HL7 to represent the specific semantic constructs contained in the critical, "back-
bone" classes of the RIM.
• Although it could be represented in UML notation, as the RIM is, the HL7 notation provides more details about the
specific constraints and class clones being represented.
• The HL7 diagramming convention abbreviates some relationship conventions, enabling diagrams to be smaller and
more concise and to convey more information visually.

Clinical Document Architecture
Refined Message Information Model
Clinical Document
Participating Entities
Clinical Document
Header
Clinical Document
Body
Document Section
Entries

• Constrained Information Model (CIM)
HL7 V3 Contrained Information Models
• RIM: Reference Information Model
• D-MIM: Domain Message Information Model
• R-MIM: Refined Message Information Model
• HMD: Hierarchical Message Definition
RIM
Restrict
R-MIM
Serialize
HMD
D-MIM
Derive
PatientIncident
classCode*: <= ENC
moodCode*: <= EVN
id: [1..*] (RegistNum)
code: CV CNE [0..1] <= ExternallyDefinedActCodes (PatientType)
statusCode: LIST<CS> CNE <= ActStatus (IDPHStatus)
activityTime: TS (EDDate)
Injury
classCode*: <= ACT
moodCode*: <= EVN
activityTime: TS (InjuryDate)
0..1 pertinentInjury
typeCode*: <= PERT
TraumaRegistryExport
(IDPH_RM00001)
Data content of HL7
messages used to export
data from the IDPH Trauma
Registry.
PatientPerson
classCode*: <= PSN
name: PN [0..1] (*Name)
existenceTime: (Age)
administrativeGenderCode: CV CWE <= AdministrativeGender
(GenderID)
birthTime: (DateOfBirth)
addr: AD [0..1] (AddressHome)
raceCode: CV CWE [0..1] <= Race (RaceID)
ethnicGroupCode: CV CWE [0..1] <= Ethnicity (EthnicID)
1..1 patientPatientPerson
1..1 providerTraumaParticipant
Patient
classCode*: <= PAT
id: II [0..1] (MedicaRecordNum)
TraumaParticipant
classCode*: <= ORG
id: [1..1] (HospitNum)
code: CV CWE [0..1] <= EntityCode
name: ON [0..1] (HospitName)
statusCode: CS CNE [0..1] <= EntityStatus (ActiveFacili)
addr: AD [0..1] (HospitCity)
1..1 patient
typeCode*: <= SBJ
subject
InjuryLocation
classCode*: <= PLC
code: CV CWE [0..1] <= EntityCode (InjuryPlaceID)
addr: AD [0..1] (AddressScene)
0..1 playingInjuryLocation
Role
classCode*: <= ROL
1..1 participant
typeCode*: <= LOC
location
InjuryRelatedObservation
classCode*: <= OBS
moodCode*: <= EVN
priorityCode: CV CWE [0..1] <= ActPriority
value: [0..1]
0..* pertinentInjuryRelatedObservation
typeCode*: <= PERT
sequenceNumber: INT [0..1] (InjurySequen)
Procedure
classCode*: <= PROC
moodCode*: <= EVN
code: CV CWE <= ActCode (ICDCodeID)
activityTime: TS (ProcedDate)
0..* pertinentProcedure
typeCode*: <= PERT
0..1 medicalStaff
typeCode*: <= PRF
performer
MedicalStaff
classCode*: <= PROV
id: II [0..1] (MedicalStaffID)
0..1 procedureLocation
typeCode*: <= LOC
location
ProcedureLocation
classCode*: <= SDLOC
code: <= RoleCode (ProcedLocateID)
PatientIncidentRelatedObservation
classCode*: <= OBS
moodCode*: <= EVN
code: <= ActCode
reasonCode: CV CWE [0..1] <= ActReason
value: ANY [0..1]
0..* pertinentPatientIncidentRelatedObservation
typeCode*: <= PERT
PatientTransfer
classCode*: <= TRNS
moodCode*: <= EVN
activityTime: IVL<TS> (DischaDate to ArriveDate)
reasonCode: CV CWE [0..1] <= TransferActReason (REASONTRANSFID)
1..1 arrivalPatientTransfer
typeCode*: <= ARR
arrivedBy
0..* aRole
typeCode*: <= ORG
origin
0..1 playingTraumaParticipant
aRole
classCode*: <= ROL
TransferRelatedObservation
classCode*: <= OBS
moodCode*: <= EVN
value: PQ [0..1]
1..* pertinentTransferRelatedObservation
typeCode*: <= PERT
1..1 transferVehicle
typeCode*: <= VIA
via
TransferVehicle
classCode*: <= OWN
VehicleProvider
classCode*: <= ORG
id: II [0..1] (VehiclProvide)
code: <= EntityCode (MaxVehiclLevelID)
name: ON [0..1] (VehiclProvidName)
HospitalVisit
classCode*: <= ENC
moodCode*: <= EVN
code: CV CWE <= ActCode (AdmitServicID)
activityTime: TS (DischaDate)
dischargeDispositionCode: CV CWE [0..1]
<= EncounterDischargeDisposition
1..1 pertinentHospitalVisit
typeCode*: <= PERT
HospitalVisitRelatedObservation
classCode*: <= OBS
moodCode*: <= EVN
value: [0..1]
0..* pertinentHospitalVisitRelatedObservation
typeCode*: <= PERT
1..1 admittingProvider
typeCode*: <= ADM
admitter
AdmittingProvider
classCode*: <= PROV
id: II [0..1] (ADMITMEDICASTAFFID)
0..* hospitalVisitPhysician
typeCode*: <= RESP
time: TS
responsibleParty
HospitalVisitPhysician
classCode*: <= PROV
id: II [0..1]
MedicalStaffPerson
classCode*: <= PSN
name: PN [0..1] (MedicaStaffName)
0..1 licensedEntity
typeCode*: <= DST
destination
0..1 subjectChoice
LicensedEntity
classCode*: <= LIC
id: II [0..1]
Choice
Facility
classCode*: <= ORG
id:
code*: CS CNE <= EntityCode "FAC"
name:
Hospital
classCode*: <= ORG
id:
code*: CS CNE <= EntityCode "HOSP"
name:
EmergencyDepartmentEncounter
classCode*: <= ENC
moodCode*: <= EVN
dischargeDispositionCode: CV CWE <= EncounterDischargeDisposition
0..1 pertinentEmergencyDepartmentEncounter
typeCode*: <= PERT
EmergencyDepartmentRelatedObservation
classCode*: <= OBS
moodCode*: <= EVN
text:
activityTime: TS
reasonCode: <= ActReason
value: [0..1]
targetSiteCode: CV CWE [0..1] <= HumanActSite
0..* pertinentEmergencyDepartmentRelatedObservation
typeCode*: <= PERT
0..* emergencyDepartmentPhysician
typeCode*: <= PRF
performer
0..1 healthCareMedicalStaffPerson EmergencyDepartmentPhysician
classCode*: <= PROV
id: II [0..1]
code: CE CWE [0..1] <= RoleCode (StaffTypeID)
PreHospitalEncounter
classCode*: <= ENC
moodCode*: <= EVN
id: II [0..1] (crashNum)
0..1 priorPreHospitalEncounter
typeCode*: <= PREV
predecessor
PreHosptialRelatedObservation
classCode*: <= OBS
moodCode*: <= EVN
value: ANY [0..1]
0..* pertinentPreHosptialRelatedObservation
typeCode*: <= PERT
1..1 preHospitalVehicle
typeCode*: <= ParticipationType
participant
PreHospitalVehicle
classCode*: <= OWN
0..* emergencyDepartmentPhysicianAct
typeCode*: <= COMP
component
EmergencyDepartmentPhysicianAct
classCode*: <= ACT
moodCode*: <= EVN
code: CS CNE [0..1] <= ExternallyDefinedActCodes
activityTime*: TS [0..1]
component
0..* patientIncidentRelatedObservation
typeCode*: <= COMP
VehicleProvider
MedicalStaffPerson
TraumaParticipant
A_AbnormalityAssessment
(COCT_RM420000UV)
Description: assessment of clinical findings, including lab test results,
for indications of the presence and severity of abnormal conditions
AbnormalityAssessment
classCode*: = "OBS"
moodCode*: = "EVN"
code*: CD CWE [1..1] <= V:ObservationType ("ADVERSE_REACTION")
statusCode*: CS CNE [1..1] <= V:ActStatusAbortedCancelledCompleted
activityTime*: TS.DATETIME [1..1]
value: CD CWE [0..1] <= V:AbnormalityAssessmentValue
methodCode: SET<CE> CWE [0..*] <= V:AbnormalityAssessmentMethod
1..* assessmentOutcome *
typeCode*: = "OUTC"
outcome
AssessmentException
classCode*: = "OBS"
moodCode*: = "EVN"
value*: SC CWE [1..1] <= V:AssessmentExceptionValue
AbnormalityGrade
classCode*: = "OBS"
moodCode*: = "EVN"
code*: CD CWE [1..1] <= V:ObservationType ("SEV")
uncertaintyCode: CE CNE [0..1] <= V:ActUncertainty
value*: CD CWE [1..1] <= V:AbnormalityGradeValue
AssessmentOutcome
0..* assessmentOutcomeAnnotation
typeCode*: = "APND"
appendageOf
AssessmentOutcomeAnnotation
classCode*: = "OBS"
moodCode*: = "EVN"
value*: SC CWE [1..1] <= V:AssessmentOutcomeAnnotationValue

HL7 V3 CONSTRAINED INFORMATION
MODEL

Components of an HL7 Constrained Information Model
• The HL7 v3 methodology specifies the information content of transport datasets (messages or
documents) as constrained information models (CIM).
• Each CIM is comprised of clone classes derived from HL7 RIM classes.
• Clone classes are associated with attributes and relationships also derived from corresponding
RIM model elements.
• A CIM may include a choice structure derived from a root RIM class and its specializations.
• Relationships in the CIM are composed of two traversal paths, each derived from association
ends in RIM class relationships.
• Controlling attributes in clone classes are used to identify the specific specialization of the RIM
class used to derive the CIM clone class.

HL7 Constrained Information Model
«clone»
Class
localName: char
fixedName: char
businessName: char
comment: Annotation
isEntryPointIndicator: boolean
isStubIndicator: boolean
«RIM»
Class
name: char
description: Annotation
«clone»
Attribute
businessName: char
datatype: DataType
cardinality: Cardinality
conformance: Conformance
comment: Annotation
initialValue: char
initialValueRole: ValueRole
maximumLength: int
«RIM»
Attribute
name: char
datatype: DataType
mandatoryInclusionIndicator: boolean
«RIM»
Relationship
name: char
relationshipType: RelationshipType
«clone»
Relationship
ConstrainedInformationModel
name: char
modelType: ModelType
ControllingAttribute
constraints
{datatype = CS}
{cardinality = (1..1)}
{conformance = Mandatory}
{codingStrength = CNE}
{terminologyReference = CodeSystem}
«RIM»
AssociationEnd
roleName: char
multiplicity: Cardinality
navigabilityIndicator: boolean
«clone»
TraversalPath
name: char
enabledIndicator: boolean
requiredIndicator: boolean
mandatoryIndicator: boolean
multiplicity: Cardinality
«enumeration»
Cardinality
0..1
0..n
0..*
1
1..1
1..n
1..*
n..m
n..*
«enumeration»
RelationshipType
Generalization
Association
Composition
Aggregation
«clone»
Choice
name: char
nameExtension: char
«enumeration»
Conformance
Optional
Required
Mandatory
«enumeration»
ValueRole
Fixed
Default
«enumeration»
ModelType
DMIM = Domain Message ...
RMIM = Refined Message...
CMET = Common Message ...
HMD = Hierarchical Me...
0..*
associates source
1
«restrict»
1..*
0..*
associates target
1
0..*
associates target
1
0..*
associates source
1
0..*
isDerivedFrom
1
0..*
{ordered}
1..*
{ordered}
0..*
isDerivedFrom
1
0..*
isDerivedFrom
1
0..*
isDerivedFrom
root1
1..*
0..1
0..*
isDerivedFrom
1
2
2

CDA RMIM Patient Class
• The CDA RMIM Patient class is a clone derived from the RIM Person class.
• The RIM Person class is one of the specializations of the RIM Entity class.
• The CDA RMIM Patient class is connected to the Clinical Document class by
way of the recordTarget, patientRole, playingEntity traversal path.
Traversal Path

Derived Attributes of
the CDA RMIM
Patient Class
• Entity
 classCode <= PSN
 determinerCode <= INSTANCE
– id
– name
• LivingSubject
– administrativeGenderCode
– birthtime
• Person
– maritalStatusCode
– religiousAffiliationCode
– raceCode
– ethnicGroupCode

CDA Hierarchical Message Definition
International, registered with the United States Patent and Trademark Office. 25
RMIM Class Attribute Constraints
• Name (same as in the RIM, an optional business name may be provided in notes)
• Source RIM class (for reference only. Provide context for attribute semantics)
• Cardinality (same as or more constrained than in the RIM)
• Mandatory Inclusion Indicator (must be present and contain a non-null value in all instances)
• Conformance (Required, Optional, Conditional)
• Required must be present in all instances, may be null unless also mandatory
• Optional may be omitted from instances
• Conditional is required or optional depending on predicate stated in notes
• Datatype (same as or more constrained than in the RIM)
• Terminology Binding (same as or more constrained than in the RIM)
• Terminology Binding Strength (same as or more constrained than in the RIM)
• Notes (default values, business names, conditional usage predicates, design notes, and business rules)
TraversalPath

HL7 V3 XML SCHEMA GENERATOR

HL7 XML Schema Generator
HL7 XML
Schema
Generator
XML Schema
Specification
Hierarchical Message
Definition

Essential XML ITS Transformation Rules
• All XML elements and attributes are to be represented in the namespace defined by "urn:hl7-org:v3".
• The XML representation for the members of a class will be a sequence of child elements, one for each
attribute followed by one for each outbound association.
• Where the HL7 static model allows for an association to a choice of classes, the representation of the
XML shall be the same as would be the case if there had been no choice, and only the class
corresponding to the information items in the HL7 instances were included in the specification.
• All HL7 RIM structural attributes are represented as XML attributes. All other HL7 RIM attributes are
represented as XML elements.
• The type of the HL7 attribute will be one of the types defined in the ISO datatypes. That specification
includes a definition of the XML serialization to be used.
• When included in an instance local extensions MUST be in a namespace other than the HL7v3
namespace.

CDA
XML Schema
• Each CDA RMIM Class is included
as a complex type in the schema
• Each class complex type contains:
– a sequence of elements
o Infrastructure
o Non-structural attributes
o Outbound relationships
– controlling structural attributes
• The schema includes a reference
to the HL7 v3 core datatype and
vocabulary schema specifications

HL7 XML Schema Generator
HL7 XML
Schema
Generator
HL7 Data Type
Specification
HL7 Vocabulary
Specification
XML Schema
Specification

Core Schema
 The core schema specifications include infrastructure root, datatype base,
datatype, and vocabulary.
 The core schema specifications include no domain content. They are present
only to facilitate interpretation of datatypes and validation of structural
vocabulary.
Our
Schema
Infrastructure
Root.XSD
Datatype.XSD
Datatype-
base.XSD
Voc.XSD
Include Include
Include Include Include
Include
Core Schema

HL7 Version 3.0 Reference Models
Reference Information Model
Data Type
Specification
Vocabulary
Specification

HL7 VERSION 3.0
DATA TYPE SPECIFICATION
The HL7 v3 Abstract Datatype Specification defines the
structural format of the data carried in an attribute and
influences the set of allowable values an attribute may assume.

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

Datatype Class Diagram
T
Sequence : LIST
T
Set : SET
T
Bag : BAG
Quantity : QTY
IntegerNumber : INT
RealNumber : REAL
PhysicalQuantity : PQ
MonetaryAmount : MO
Ratio : RTO
PointInTime : TS
Boolean : BL
CharacterString : ST
ConceptDescriptor : CD
CodedValue : CV
InstanceIdentifier : II
TelecommunicationAddress : TEL
T
Interval : IVL
DataValue : ANY
BinaryData : BIN
List_of_Boolean : LIST<BL>
<<extends>>
EncapsulatedData : ED
<<extends>>
ConceptRole : CR
CodedSimpleValue : CS
<<restricts>>
CodedWithEquivalents : CE
ISO_object_identifier : OID
List_ADXP : LIST<ADXP>
PostalAndResidentialAddress : AD
<<extends>>
AddressPart : ADXP
PersonNameType : PN
List_ENXP : LIST<ENXP>
EntityNamePart : ENXP
T
PeriodicIntervalOfTime : PIVL
T
EventRelatedPeriodicIntervalOfTime : EIVL
GeneralTimingSpecification : GTS
Set_of_TS : SET<TS>
<<extends>>
T : T
T
Annotated : ANT
T
History_item : HXIT
T
History : HIST
Set_of_HXIT : SET<HXIT<T>>
T
UncertainValueNarrative : UVN
<<extends>>
T
UncertainValueProbabilistic : UVP
T
NonParametricProbabilityDistribution : NPPD
Set_UVP : SET<UVP<T>>
T
ParametricProbabilityDistribution : PPD
UniversalResourceLocator : URL
<<extends>>
OrganizationName : ON
<<extends>>
<<extends>><<extends>>
<<extends>>
<<extends>>
<<extends>>
<<extends>>
<<extends>>
<<extends>>
<<extends>>
<<extends>>
<<restricts>>
<<restricts>>
<<restricts>>
<<extends>>
<<extends>>
<<extends>>
<<extends>>
<<extends>>
<<extends>>
<<restricts>>
<<extends>>
<<extends>>
<<extends>>
<<extends>> <<extends>>
<<extends>>

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

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 post-coordinated 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
Name Type Status
code ST mandatory
displayName ST optional
Name Type Status
code ST mandatory
codeSystem OID mandatory
codeSystemName ST optional
codeSystemVersion ST optional
originalText ST optional
Name Type Status
code ST mandatory
codeSystem OID mandatory
codeSystemName ST optional
codeSystemVersion ST optional
originalText ST optional
translation SET<CV> optional
CS: Coded Simple
CV: Coded Value
CE: Coded With Equivalents

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.
assigningAuthorityNa
me
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.
use SET<CS> optional
A code advising a system or user which telecommunication address in a set of
like addresses to select for a given telecommunication need.
validTime GTS optional
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 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
use SET<CS> optional
A code advising a system or user which address in a set of like addresses to select
for a given purpose
validTime GTS optional
Identifies the periods of time during which the address can be used. Typically used
to refer to different addresses for different times of the year or to refer to historical
addresses.
ST ST mandatory The address part data
type CS optional
Indicates whether an address part is the street, city, country, postal code, post
box, etc.
ADXP: Postal Address Part

EN: Entity Name
Name Type Status Default Constraint Definition
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
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
Entity Name Specializations:
TN: Trivial Name
PN: Person Name
ON: Organization Name

RTO: Ratio
numerator QTY mandatory The numerator of the ratio.
denominator QTY mandatory
The denominator of the ratio
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
value REAL mandatory NULL
The magnitude of the monetary amount in terms of
the currency unit.
currency CS mandatory NULL ISO 4217 The currency unit

Additional Datatypes and Aggregates
• BL: Boolean
• INT: Integer
• Real: Real
– Precision :: Int
• TS: Point in Time
– Offset :: PQ
– Calendar :: CS
– Precision :: INT
– Timezone :: PQ
• SET
• LIST
• BAG
• IVL
– Low
– Center
– Width
– High

HL7 VERSION 3.0
VOCABULARY SPECIFICATION
The HL7 Vocabulary Specification defines the set of
all concepts that can be taken as valid values in an
instance of a coded attribute or message element.

HL7 V3 Vocabulary Specification
• The HL7 V3 Vocabulary Specification defines vocabulary domains used in RIM coded
Attributes and coded data type properties.
• A vocabulary domain is an abstract collection of interrelated concepts. It describes the purpose
or intent of a coded attribute.
• A value set is a collection of coded concepts drawn from one or more code systems. A
vocabulary domain may be associated with many value sets (e.g. for use in different countries).
• A context expression provides a means of designating which value set for a given domain are
applicable for a given usage context.
• A coded concept has a concept code assigned by the coding system and a concept
designation which names the referenced concept.
• A coded concept may be a parent concept for a collection of additional concepts within the
same code system.

HL7 V3 Vocabulary Specification Metamodel
ParentConcept
VocabularyDomain
name : String
description : String
CodedConcept
conceptCode : String
conceptDesignation : String
0..*0..*
ValueSet
name : String
definingExpression : String
0..*
0..*
0..*
0..*
0..*
0..*
0..*
0..*
includes
CodeSystem
identifier : OID
name : String
0..*0..*
0..*
0..1
0..*
0..1
based on
ValueSetContext
contextExpression : String

Code System vs Value Set
• Days of Week Code System
– Su: Sunday
– Mo: Monday
– Tu: Tuesday
– We: Wednesday
– Th: Thursday
– Fr: Friday
– Sa: Saturday
• Workday Value Set
– Mo, Tu, We, Th, Fr
• Weekend Value Set
– Fr, Sa, Su
• Humpday Value Set
– We
• Sabbath Value Set
– Su or Sa or Fr (depending upon realm)

ActMood

EntityClass

EntityDeterminer

EntityCode

RoleCode

ActRelationshipType

Vocabulary TermsVocabulary BindingInformation Model
Vocabulary Binding
Class
Attribute
Vocabulary
Domain
Value Set Coded
Concept
Code
System
1
0..* 0..*
0..1
0..10..*
0..*
0..*
0..* 0..*
0..*
1
0..*
0..1

HL7 Version 3.0 Reference Models
ParentConcept
VocabularyDomain
name : String
CodedConcept
conceptCode : String
conceptDesignation : String
0..*0..*
ValueSet
name : String
definingExpression : String
0..*
0..*
0..*
0..*
0..*
0..*
0..*
0..*
includes
CodeSystem
identifier : OID
name : String
0..*0..*
0..*
0..1
0..*
0..1
based on
ValueSetContext
contextExpression : String
T
Sequence : LIST
T
Set : SET
T
Bag : BAG
Quantity : QTY
IntegerNumber : INT
RealNumber : REAL
PhysicalQuantity : PQ
MonetaryAmount : MO
Ratio : RTO
PointInTime : TS
Boolean : BL
CharacterString : ST
CodedValue : CV
InstanceIdentifier : II
TelecommunicationAddress : TEL
T
Interval : IVL
DataValue : ANY
BinaryData : BIN
List_of_Boolean : LIST<BL>
<<extends>>
EncapsulatedData : ED
<<extends>>
ConceptRole : CR
<<restricts>>
ISO_object_identifier : OID
List_ADXP : LIST<ADXP>
PostalAndResidentialAddress : AD
<<extends>>
AddressPart : ADXP
PersonNameType : PN
List_ENXP : LIST<ENXP>
EntityNamePart : ENXP
T
PeriodicIntervalOfTime : PIVL
T
EventRelatedPeriodicIntervalOfTime : EIVL
GeneralTimingSpecification : GTS
Set_of_TS : SET<TS>
<<extends>>
T : T
T
Annotated : ANT
T
History_item : HXIT
T
History : HIST
Set_of_HXIT : SET<HXIT<T>>
T
UncertainValueNarrative : UVN
<<extends>>
T
UncertainValueProbabilistic : UVP
T
NonParametricProbabilityDistribution : NPPD
Set_UVP : SET<UVP<T>>
T
ParametricProbabilityDistribution : PPD
UniversalResourceLocator : URL
<<extends>>
OrganizationName : ON
<<extends>>
<<extends>>
<<extends>>
<<extends>>
<<extends>>
<<extends>>
<<extends>>
<<extends>>
<<extends>>
<<restricts>>
<<restricts>>
<<restricts>>
<<extends>>
<<extends>>
<<extends>>
<<extends>>
<<extends>>
<<extends>>
<<restricts>>
<<extends>>
<<extends>>
<<extends>>
<<extends>> <<extends>>
<<extends>>

Course
Outline
Clinical Data Architecture Specification
Constrained Information Models and XML
Schema
CIM Terminology and Datatype Components
CDA Information Model
Consolidated CDA Implementation Guide
Continuity of Care C-CDA Document Type

CIM TERMINOLOGY AND DATATYPE
COMPONENTS

• Datatypes and terminology bindings are used to further describe CIM and RIM attributes.
• Attributes may be bound to a terminology reference (vocabulary domain, code system, code
system term, or value set).
• A code system is composed of one or more code system terms.
• Code system terms may be aggregated as members of one or more value set.
• Code system terms may be aggregated as specializations of one or more parent code system
term.
• Datatypes may be composed of one or more datatype attributes.
• Datatype attributes may be bound to a terminology reference.
• Datatypes may be aggregated as sub-kinds of a parent datatype.

HL7 CIM Terminology and Datatype
«clone»
Attribute
businessName: char
datatype: DataType
conformance: Conformance
comment: Annotation
initialValue: char
initialValueRole: ValueRole
maximumLength: int
«RIM»
Attribute
name: char
datatype: DataType
mandatoryInclusionIndicator: boolean
ControllingAttribute
constraints
{datatype = CS}
{cardinality = (1..1)}
{conformance = Mandatory}
{codingStrength = CNE}
{terminologyReference = CodeSystem}
«RIM»
TerminologyBinding
codingStrength: CodingStrength
«clone»
TerminologyBinding
TerminologyReference
{abstract}
name: char
VocabularyDomain
ValueSet
conceptIdentifier: char
CodeSystem
objectIdentifier: char
releaseIdentifier: char
isExternalIndicator: boolean
CodeSystemTerm
code: char [0..1]
designation: char
internalIdentifier: char
DataType
longName: char
shortName: char
DatatypeAttribute
name: char
datatype: DataType
ParentDatatype
«datatype»
TerminologyBinding
Annotation
{abstract}
«enumeration»
CodingStrength
CNE
CWE
ParentCodeSystemTerm
AnnotationSection
sectionRole: AnnotationSectionRole
sectionText: char
«enumeration»
AnnotationSectionRole
Description
Rationale
Design Comment
Issue
Implementation Note
History
Mapping
0..*
binds
1
0..1
binds
1
0..1
binds
1
0..*
isDerivedFrom
1
«restrict»
0..*
isDerivedFrom
1
0..*
binds
1
1..*
subkind
1..*
0..*
0..*
binds
1
0..1
binds
1
0..*
0..*
isBoundTo
1
member
1..*0..*
1..*
subkind
1..*
0..1

Core Schema
Our
Schema
Infrastructure
Root.XSD
Datatype.XSD
Datatype-
base.XSD
Voc.XSD
Include Include
Include Include Include
Include
Core Schema

InfrastructureRoot.xsd
Design-Level Static Information Models
77 of
77
December 2004

CS Datatype
+ code : CharacterString
+ displayName : CharacterString
DataValue : ANY
+ dataType : CodedSimpleValue
+ nullFlavor : CodedSimpleValue
(from AnyDataType)
ConceptRole : CR
+ name : CodedSimpleValue
+ value : ConceptDescriptor
+ inverted : Boolean
+ modifier : List<ConceptRole>
1..n
modifier
1..n
List
CodedValue : CV
+ codeSystem : ISOObjectIdentifier
+ codeSystemName : CharacterString
+ codeSystemVersion : CharacterString
+ originalText : CharacterString
+ translation : Set<CodedValue>
1..n
translation
1..n
Set

CDA Conformance
• A conformant CDA document is one that at a minimum validates against the CDA Schema, and
that restricts its use of coded vocabulary to values allowable within the specified vocabulary
domains.
• A document originator is an application role that creates a CDA document. The document
originator is responsible for ensuring that generated CDA documents are fully conformant.
• A document recipient is an application role that receives status updates and documents from a
document originator or document management system. The document recipient is responsible
for ensuring that received CDA documents are rendered properly.
• CDA is an exchange standard. There are no persistent storage requirements for CDA
documents defined in the standard.

CDA INFORMATION MODEL

Clinical Document
Header
(Part 1)
• The clinical document clone is
the entry point of the CDA
RMIM.
• Relevant attributes of the
clinical document clone are:
 ID - Represents the unique instance
identifier of a clinical document
 Code - The code specifying the particular
kind of document
 Title - The title of the document as
specified by the document author
 Effective Time -Signifies the document
creation time, when the document first
came into being

Clinical Document Class
• Mandatory Attributes
– classCode
– moodCode
• Required Attributes
– id: II
– code: CE
– effectiveTime: TS
– confidentialtityCode: CE
• Terminology Bindings
– DOCCLIN
– EVN
– DocumentType (CWE)
– BasicConfidentialityKind (CWE)
– HumanLanguage (CNE)

Clinical Document Attribute Descriptions
• 4.2.1.1 ClinicalDocument.id
Represents the unique instance identifier of a clinical document
• 4.2.1.2 ClinicalDocument.code
The code specifying the particular kind of document (e.g. History and Physical, Discharge Summary, Progress Note). The value set is
drawn from LOINC, and has a CWE coding strength. Within the LOINC database, beginning with version 2.09, May 2003, document
type codes are those that have a value of "DOC" in the Scale component.
4.2.1.3 ClinicalDocument.title
Represents the title of the document. It's commonly the case that clinical documents do not have a title, and are collectively referred to
by the display name of ClinicalDocument.code (e.g. a "consultation" or "progress note"). Where these display names are rendered to
the clinician, or where the document has a unique title, the ClinicalDocument.title component should be used.
• 4.2.1.4 ClinicalDocument.effectiveTime
Signifies the document creation time, when the document first came into being. Where the CDA document is a transform from an
original document in some other format, the ClinicalDocument.effectiveTime is the time the original document is created. The time when
the transform occurred is not currently represented in CDA.
• 4.2.1.5 ClinicalDocument.ConfidentialityCode
Confidentiality is a required contextual component of CDA, where the value expressed in the header holds true for the entire document,
unless overridden by a nested value (as further described in CDA Context (§ 4.4 )).

BasicConfidentialityKind Value Set
• N (normal) (codeSystem 2.16.840.1.113883.5.25)
Normal confidentiality rules (according to good health care practice) apply.
That is, only authorized individuals with a legitimate medical or business
need may access this item.
• R (restricted) (codeSystem 2.16.840.1.113883.5.25)
Restricted access, e.g. only to providers having a current care relationship to
the patient.
• V (very restricted) (codeSystem 2.16.840.1.113883.5.25)
Very restricted access as declared by the Privacy Officer of the record holder.

® Health Level Seven and HL7 are registered trademarks of Health Level Seven International, registered with the United States Patent and
Trademark Office. 92
V3.Confidentiality Code System
Defining URL:
http://terminology.hl7.org/CodeSystem/
v3-Confidentiality
Version: 2018-08-12
Name: v3.Confidentiality
Title: v3 Code System Confidentiality
Definition:
A set of codes specifying the security
classification of acts and roles in
accordance with the definition for
concept domain "Confidentiality".
OID: 2.16.840.1.113883.5.25

Clinical Document
Header
(Part 2)
• Additional clones appearing in
the Clinical Document Header
include:
 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 fulfilled by this
document.
 Consent - the consents associated with this
document.
 Encompassing Encounter - the setting of
the clinical encounter during 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.

Record Target (aka Patient)

Author, Custodian, and Information Recipient

Clinical Document
Body
• The CDA body can be either an
unstructured blob, or can be
comprised of structured markup.
• 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 than XML.
• The Structured Body class
represents a CDA document body
that is comprised of one or more
document sections.

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
Clinical Statement model.
• The Clinical Statement model,
which provides a consistent
representation of clinical
observations and acts across
various V3 specifications.

Clinical Statement
Model
• The key classes of the clinical
statement model include:
 Observation - used for representing
coded and other observations.
 Substance Administration - used for
representing medication-related
events.
 Supply - used for representing the
provision of a material by one entity to
another.
 Procedure - used for representing an
Act whose immediate and primary
outcome is the alteration of the
physical condition of the subject.
 Encounter - used to represent related
encounters, such as follow-up visits or
referenced past encounters.
 Organizer - used to create arbitrary
groupings of other CDA entries that
share a common context

Clinical
Statement
® Health Level Seven and HL7 are registered trademarks of Health Level Seven International, registered with the United States Patent and Trademark
Office. 100

Clinical
Statement
Participants
® Health Level Seven and HL7 are registered trademarks of Health Level Seven International, registered with the United States Patent and Trademark
Office. 101

Document Header Example

Structured Body Example

Section Entry Example

CDA TEMPLATE PROFILES

Template Conformance Statement
SHALL contain exactly one [1..1] @classCode="OBS" Observation
(CodeSystem: HL7ActClass 2.16.840.1.113883.5.6 STATIC)
 Element: @classCode
 Usage: SHALL contain
 Cardinality: exactly one [1..1]
 Terminology Binding: ="OBS" Observation
(CodeSystem: HL7ActClass 2.16.840.1.113883.5.6 STATIC)

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

CONSOLIDATED CDA
IMPLEMENTATION GUIDE

C-CDA Sections and Entry Templates
Clinical Document Lego Blocks

US Realm Header Template
1. realmCode
2. typeId
3. templateId
4. id
5. code
6. title
7. effectiveDateTime
8. confidentialityCode
9. languageCode
10. setId
11. versionNumber

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

CONTINUITY OF CARE C-CDA
DOCUMENT TYPE

Continuity of Care Document (CCD)
• The Continuity of Care Document (CCD) represents a core data set of the most relevant
administrative, demographic, and clinical information facts about a patient's healthcare,
covering one or more healthcare encounters.
• It provides a means for one healthcare practitioner, system, or setting to aggregate all of the
pertinent data about a patient and forward it to another to support the continuity of care.
• The primary use case for the CCD is to provide a snapshot in time containing the germane
clinical, demographic, and administrative data for a specific patient.
• The key characteristic of a CCD is that the ServiceEvent is constrained to "PCPR". This means
it does not function to report new ServiceEvents associated with performing care. It reports on
care that has already been provided.
• The CCD provides a historical tally of the care over a range of time and is not a record of new
services in the process of being delivered.

CCD v3 Section Templates
Continuity of
Care Document
34133-9
2.16.840.1.113883.10.20.22.2.21 Advance Directives Section (entries optional) (V3) "42348-3" Advance Directives O
2.16.840.1.113883.10.20.22.2.6.1 Allergies and Intolerances Section (entries required) (V3)"48765-2" Allergies, adverse reactions, alerts R
2.16.840.1.113883.10.20.22.2.22 Encounters Section (entries optional) (V3) "46240-8" Encounters O
2.16.840.1.113883.10.20.22.2.15 Family History Section (V3) "10157-6" Family History O
2.16.840.1.113883.10.20.22.2.14 Functional Status Section (V2) "47420-5" Functional Status O
2.16.840.1.113883.10.20.22.2.2.1 Immunizations Section (entries required) (V3) "11369-6" Immunizations O
2.16.840.1.113883.10.20.22.2.23 Medical Equipment Section (V2) "46264-8" Medical Equipment O
2.16.840.1.113883.10.20.22.2.1.1 Medications Section (entries required) (V2) "10160-0" History of medication use R
2.16.840.1.113883.10.20.22.2.56 Mental Status Section (V2) "10190-7" Mental Status O
2.16.840.1.113883.10.20.22.2.57 Nutrition Section "61144-2" Diet and nutrition O
2.16.840.1.113883.10.20.22.2.18 Payers Section (V3) "48768-6" Payers O
2.16.840.1.113883.10.20.22.2.10 Plan of Treatment Section (V2) "18776-5" Plan of Treatment O
2.16.840.1.113883.10.20.22.2.5.1 Problem Section (entries required) (V3) "11450-4" Problem List R
2.16.840.1.113883.10.20.22.2.7.1 Procedures Section (entries required) (V2) "47519-4" History of Procedures R
2.16.840.1.113883.10.20.22.2.3.1 Results Section (entries required) (V3) "30954-2" Relevant diagnostic tests and/or laboratory data R
2.16.840.1.113883.10.20.22.2.17 Social History Section (V3) "29762-2" Social History R
2.16.840.1.113883.10.20.22.2.4.1 Vital Signs Section (entries required) (V3) "8716-3" Vital Signs R
Template OID Template Title Section Code

Allergies

Allergies and
Intolerances
Section

Allergy Concern
Act Entry

Allergy
Intolerance
Observation

Medications

Medication
Activity Entry

Medication Activity
Entry Template
(required elements only)
• SHALL contain exactly one [1..1] @classCode="SBADM".
• SHALL contain exactly one [1..1] @moodCode=MoodCodeEvnInt.
• SHALL contain exactly one [1..1] templateId.
• @root=“2.16.840.1.113883.10.20.22.4.16”
• @extension=“2014-06-09”
• SHALL contain at least one [1..*] id.
• SHALL contain exactly one [1..1] statusCode=Medication Status.
• SHALL contain exactly one [1..1] effectiveTime.
• SHOULD contain zero or one [0..1] @value.
• SHOULD contain zero or one [0..1] low.
• MAY contain zero or one [0..1] high.
• SHALL contain either a low or a @value but not both.
• SHALL contain exactly one [1..1] doseQuantity.
• SHALL contain exactly one [1..1] consumable
(Medication Information).
«Substance Administration»
Medication Activity
- @classCode: CD ="SBADM"
- @moodCode: CD =MoodCodeEvnInt
- templateID.@root: ST=“2.16.840.1.113...
- templateID.@extension: ST=“2014-06-09”
- id: II
- statusCode: CD =MedicationStatus
- effectiveTime.@value: TS [0..1]
- effectiveTime.low: TS [0..1]
- effectiveTime.high: TS [0..1]
- doseQuantity: PQ
«Participation»
Consumable
- typeCode: CD ="CSM"
«Role»
Manufactured Product
- @classCode: CD ="MANU"
- id: II [0..*](SET)
«Manufactured Material»
Material
- @classCode: CD ="MMAT"
- @determinerCode: CD ="KIND"
- code: CD =MedicationClini...
- name: EN [0..1]
- lotNumberText: ST[0..1]
«Organization»
Manufacturer Organization
- @classCode: CD ="ORG"
- @determinerCode: CD ="Instance"
- id: II [1..*](SET)
- name: EN.ON
1..11..1
player
+manufacturedDrugOrOtherMaterial 1..1
scoper
+manufacturer 0..1

Problems

Procedures

Results

Social History

Vital Signs

Sections of the CCD
Required Sections Optional Sections

Course
Outline
Clinical Data Architecture Specification
Constrained Information Models and XML
Schema
CDA Information Model
Consolidated CDA Implementation Guide
Continuity of Care C-CDA Document Type
SANKOFA
Retrospective

Questions / Discussion / Feedback

BONUS TRACK - HL7 INFORMATION
EXCHANGE COMPONENTS

HL7 v2 Message ComponentsMessage
Segment Group
Segment Group
Segment
Segment Field
Data Element
Datatype Composite
Datatype
Datatype
Component
Code Table Code Table Item
Code System
Term
Code System
1..*1
1..*
1
1..*
1
0..*1
0..* 0..1
0..*
1
0..*
1
1..*1..*
1
1..*
1
0..*
10..*
0..1
1..*1

HMD
RMIM
RMIM Clone
RIM Class Attribute
Data Element
Datatype Composite
Datatype
Datatype
Component
Terminology
Binding
Value Set
Member
Code System
Term
Code System
HL7 RIM Value SetValue Domain
1..*
1
1..*
1
0..*1
0..* 0..1
0..*
1
0..*
1
1..*1..*
1
1..*
1
0..*
1
0..*
1
0..*
0..1
0..*
0..1
1..*1
HL7 v3 Message Components

Document Section
Section Entry
Entry Entry
Element
Data Element
Datatype Composite
Datatype
Datatype
Component
Terminology
Binding
Value Set
Member
Code System
Term
Code System
Value SetCDA RMIM CloneRIM Class
HL7 RIM
RMIM Clone
Attrbitute
Value Domain
0..*1
1..*
1
1..*
1
0..*
1
0..*1
0..* 0..1
0..*
1
0..*
1
1..*
1..*
1..*
1
1..*1
0..*
1
0..* 0..10..*1
0..*
1
0..*
0..1
1..*1
0..*
1
HL7 CDA Document Components

Exchange Payload Grouping
Structure
Grouping
Structure
Member
Resource Resource
Element
Data Element
Datatype Composite
Datatype
Datatype
Component
Terminology
Binding
Value Set
Member
Code System
Term
Code System
Value Set
1..*
1
1..*
1
0..*1
0..* 0..1
0..*
1
0..*
1
1..*1..*
1
1..*1
0..*
10..*
0..1
1..*1
HL7 FHIR Exchange Payload Components

HL7 Information Exchange Components
Exchange
Payload
Grouping
Structure
Grouping
Structure
Member
Payload Class Payload Class
Element
Data Element
Datatype Composite
Datatype
Datatype
Component
Terminology
Binding
Value Set
Member
Code System
Term
Code System
Value SetRMIM CloneRIM Class
HL7 RIM
RMIM Clone
Attrbitute
Value Domain
Payload
Datatype
Vocabulary
Reference Model
Legend
0..*1
1..*
1
1..*
1
0..*
0..1
0..*1
0..* 0..1
0..*
1
0..*
1
1..*
1..*
1..*
1
1..*1
0..*
1
0..* 0..10..*1
0..*
1
0..*
0..1
1..*1
0..*
0..1

Thank You! Please keep in touch.
AbdulMalik Shakir
President and Chief Informatics Scientist
Hi3 Solutions
your healthcare standards conformance partner
1407 Foothill Blvd., Suite 145
La Verne, CA 91750
AbdulMalik.Shakir@Hi3Solutions.com
Mobile: 626.644.4491
www.linkedin.com/in/ashakir/

Malika Power
Shakir
dob: 04/10/2019
13
8

Hl7 advance cda may 2019 webinar

More Related Content

What's hot

Similar to Hl7 advance cda may 2019 webinar

More from Abdul-Malik Shakir

Recently uploaded

Hl7 advance cda may 2019 webinar