A Role played by a physician in relationship to another physician.0..* 0..1 0..plays0..* scopes® Health Level Seven and HL7 are registered trademarks of Health Level Seven International, registered with the United States Patent and Trademark Office. 17RIM Core Classes0..10..0..10..playsscopesEntityclassCode : CSdeterminerCode: CScode: CEstatusCode : CSid : IIRoleclassCode : CScode: CEeffectiveTime : IVL<TS>statusCode : CSid : IIActclassCode : CSmoodCode

Introduction to 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/20/2019 – 05/21/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
Brief History of
HL7 v3 and CDA
Clinical Data
Architecture
Specification
CDA Template
Profiles
CDA
Implementation
Guides
Consolidated
CDA
Implementation
Guide
Continuity of Care
C-CDA Document
Type
CDA Product
Family and
Projects

BRIEF HISTORY OF HL7 V3 AND CDA
® Health Level Seven and HL7 are registered trademarks of Health Level Seven International, registered with the United States Patent and Trademark Office. 5

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.

HL7 CDA Matriarch and Pioneers
January 1997: my first HL7 working group meeting
It was a dark and cold New England January in 1997 when I came down
to my first HL7 working group meeting in Tampa Bay, Florida.
I was invited to talk about Standard Generalized Markup Language –
SGML – an object of veneration of a small cult that would give the world
both HTML and XML, the engines of the World Wide Web and what
came to be called ecommerce. To put this in context, the Web was just
over 3 years old and XML was still a suckling infant.
It had been announced the previous month, in Boston, simultaneously
with a talk on “SGML in Healthcare” by me and clinical co-conspirators,
John Spinosa, Dan Essin, and Tom Lincoln. We finished before the XML
folks and caught the final few minutes of what we knew meant a
dramatic change in electronic information publishing and processing.

HL7 v3 Model Driven Specification Design
• HL7 Version 3 introduced a common Reference Information Model
(RIM), a data type model, a set of vocabularies, and a formal model
driven specification design methodology.
• The term “v3" is typically used to refer to “v3 messaging". However,
v3 also introduced the use of "documents" as an alternative to
messages for use in sharing healthcare information.
• The HL7 RIM and data types used as a basis for v3 have been
adopted as ISO standards. ISO 21731:2014 and ISO 21090:2011
respectively.

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

Use Case Modeling
Interaction Modeling
Message Design
Information Modeling
RIM
Restrict
R-MIM
Serialize
HMD
Restrict
Message
Type
Example
Storyboard
Storyboard
Example
D-MIM
Derive
Application
Role
Sender Receiver
Trigger
Event
Triggers
Content
Interaction
References
V3 Message
Development
Framework

RIM History
• Development of the HL7 Reference Information Model began in April 1996.
• The first draft of the RIM was created by consolidating data models developed by HL7
Technical Committees, contributed by HL7 Member Organizations, and published by national
and international standards organizations and government bodies.
• The first release of the RIM (v0.80) was adopted by the HL7 Technical Steering Committee at
the January 1997 working group meeting.
• The next two working group meetings focused on gaining familiarity with the draft RIM and
implementing a process for obtaining and reconciling proposed enhancements to the model.
• The RIM maintenance process became known as "RIM harmonization.” The first RIM
harmonization meeting was held July 1997 in Indianapolis, Indiana.

RIM Development Process
B
X F
E
C A D
G
1
0..*
0..* 1 0..* 1
0..* 0..1 0..*1
Model I Model II Model III
A
C
B
0..*
0..*
0..* 1 X
C
B
0..*
0..*
0..* 1
D
A B0..* 0..*
0..*
1

Contributing Data Models
• HL7 Technical Committees
– Admission/Discharge/Transfer
– Finance
– Medical Records
– Orders/Results
– Patient Care
• Standards Development Organizations
– CEN TC251
– DICOM
• HL7 Member Organizations
– Eli Lilly and Company
– HBO and Company
– Health Data Sciences
– IBM Worldwide
– Kaiser Permanente
– Mayo Foundation
– Hewlett Packard
• National Health Programs
– United Kingdom
– Australia
Abdul-Malik Shakir
Manager, Information Administration
Kaiser Foundation Health Plan, Inc.
One Kaiser Plaza, Oakland, CA 94612
v: (510) 271-6856 f: (510) 271-6859
Email: 74353.1431@Compuserve.com
April 1996

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
Act
classCode : CS
moodCode: CS
code: CD
statusCode : CS
effectiveTime : GTS
id : II
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.
0..* 0..*

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

0..1
0..*
0..1
0..*
plays
scopes
Entity
classCode : CS
determinerCode: CS
code: CE
statusCode : CS
id : II
Role
classCode : CS
code: CE
statusCode : CS
id : II
Act
classCode : CS
moodCode: CS
code: CD
statusCode : CS
effectiveTime : GTS
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).
0..* 0..*

Entity
classCode : CS
determinerCode: CS
code: CE
statusCode : CS
id : II
Role
classCode : CS
code: CE
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..*
RIM Core Classes
• 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.
0..1
0..*
plays
scopes

Entity
classCode : CS
determinerCode: CS
code: CE
statusCode : CS
id : II
Role
classCode : CS
code: CE
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..*
Act Relationship
typeCode : CS
1 1
0..* 0..*
RIM Core Classes
• 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.
0..1
0..*
plays
scopes

Entity
classCode : CS
determinerCode: CS
code: CE
statusCode : CS
id : II
Role
classCode : CS
code: CE
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
Act Relationship
typeCode : CS
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.
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.

Normative R6 RIM
Version 2.44 11/22/2013

RIM From Draft to Normative
• Apr 96 – Dec 96: Initial development
• Jan 97 – Jan 00: Pre-USAM Harmonization
• Jan 00 – Jul 03: Post-USAM and Pre-Normative
• Normative Releases:
– V1.25 Release 1.0: 2003
 V2.07 Release 1.0: 2005
– V2.14 Release 1.0: 2007
– V2.29 Release 2.0: 2009
– V2.33 Release 3.0: 2010
– V2.36 Release 4.0: 2011
– V2.40 Release 5.0: 2012
– V2.44 Release 6.0: 2013
– V2.47 Release 7.0: 2016

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

Domain Information Model
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)
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

Refined Message Information Model
(COCT_RM420000UV)
classCode*: = "OBS"
moodCode*: = "EVN"
typeCode*: = "OUTC"
outcome
AssessmentException
classCode*: = "OBS"
moodCode*: = "EVN"
AbnormalityGrade
classCode*: = "OBS"
moodCode*: = "EVN"
AssessmentOutcome
typeCode*: = "APND"
appendageOf
classCode*: = "OBS"
moodCode*: = "EVN"

Hierarchical Message Definition

HL7 XML Schema Generator
HL7 Vocabulary
Specification
HL7 Data Type
Specification
HL7 XML
Schema
Generator
Hierarchical Message
Definition
XML Schema
Specification

HL7 V3 Modeling Tools
Rational
Rose
Reference
Model
Repository
RoseTree
R-MIM
Designer
Schema
Generator
RIM RIM
R-MIM
R-MIM
HMD HMD
XSD
R-MIM
RIM

HL7 XML Schema Generator
HL7 Vocabulary
Specification
HL7 Data Type
Specification
HL7 XML
Schema
Generator
XML Schema
Specification
(COCT_RM420000UV)
classCode*: = "OBS"
moodCode*: = "EVN"
typeCode*: = "OUTC"
outcome
AssessmentException
classCode*: = "OBS"
moodCode*: = "EVN"
AbnormalityGrade
classCode*: = "OBS"
moodCode*: = "EVN"
AssessmentOutcome
typeCode*: = "APND"
appendageOf
classCode*: = "OBS"
moodCode*: = "EVN"
Refine Message
Information Model
Hierarchical Message
Definition

Sample HL7 v3 Message Instance

CDA STANDARD SPECIFICATION

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.

A Brief History and Evolution of CDA
• 1997 – Work begins on the Patient Record Architecture
• 1998 – Patient Record Architecture draft
• 1999 – CDA Release 1.0 Approved by HL7 Membership
• 2000 – CDA Release 1.0 adopted as an American National
Standard
• 2000 – HL7 XML SIG becomes Structured Documents Technical
Committee
• 2005 – Clinical Document Architecture Release 2 Adopted
• 2006 – Care Record Summary Implementation Guide
• 2007 – Continuity of Care Document Implementation Guide
• 2008 – Recognition of HL7 CDA by the Secretary of HHS
• 2008 – Submission of CDA to ISO TC-215
• 2009 – ISO TC-215 Approves CDA as an ISO Standard
• 2010 – CDA reaffirmed by HL7 and ANSI as an American National
Standard
• 2011 – Consolidated CDA Implementation Guide
• 2012 - HL7 Releases New Tool for Reviewing CDA Templates
• 2013 - HL7 Announces a CCD to Blue Button Transform Tool
• 2014 – Consolidated CDA R2 DSTU published
• 2014 – Initiated CDA R2.1 project
• 2014 – Initiated C-CDA on FHIR project
• 2019 – Initiated Consolidated CDA STU 2019 Update project
• 2019 – CDA on FHIR project scope statement prepared

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

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

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

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

CDA RMIM Subset UML Class Diagram

Document Header Example

Structured Body Example

Section Entry Example

CDA TEMPLATE PROFILES

Sample CDA Templated Constraints
Age Observation: templateId 2.16.840.1.113883.10.20.22.4.31 (open)
• SHALL contain exactly one [1..1] @classCode="OBS" Observation (CodeSystem: HL7ActClass 2.16.840.1.113883.5.6 STATIC)
(CONF:7613).
• SHALL contain exactly one [1..1] @moodCode="EVN" Event (CodeSystem: ActMood 2.16.840.1.113883.5.1001 STATIC)
(CONF:7614).
• SHALL contain exactly one [1..1] templateId (CONF:7899) such that it
– SHALL contain exactly one [1..1] @root="2.16.840.1.113883.10.20.22.4.31" (CONF:10487).
• SHALL contain exactly one [1..1] code (CONF:7615).
– This code SHALL contain exactly one [1..1] @code="445518008" Age At Onset (CodeSystem: SNOMED-CT
2.16.840.1.113883.6.96 STATIC) (CONF:16776).
• SHALL contain exactly one [1..1] statusCode (CONF:15965).
– This statusCode SHALL contain exactly one [1..1] @code="completed" Completed (CodeSystem: ActStatus
2.16.840.1.113883.5.14 STATIC) (CONF:15966).
• SHALL contain exactly one [1..1] value with @xsi:type="PQ" (CONF:7617).
– This value SHALL contain exactly one [1..1] @unit, which SHALL be selected from ValueSet AgePQ_UCUM
2.16.840.1.113883.11.20.9.21 DYNAMIC (CONF:7618).

Segment of the CDA affected by the Age
Observation template

Templated Conformance Constraints
Age Observation: templateId 2.16.840.1.113883.10.20.22.4.31 (open)
• SHALL contain exactly one [1..1] @classCode="OBS" Observation
(CodeSystem: HL7ActClass 2.16.840.1.113883.5.6 STATIC) (CONF:7613).
• SHALL contain exactly one [1..1] @moodCode="EVN" Event (CodeSystem:
ActMood 2.16.840.1.113883.5.1001 STATIC) (CONF:7614).
• SHALL contain exactly one [1..1] templateId (CONF:7899) such that it
– SHALL contain exactly one [1..1]
@root="2.16.840.1.113883.10.20.22.4.31" (CONF:10487).
• SHALL contain exactly one [1..1] code (CONF:7615).
– This code SHALL contain exactly one [1..1] @code="445518008"
Age At Onset (CodeSystem: SNOMED-CT
2.16.840.1.113883.6.96 STATIC) (CONF:16776).
• SHALL contain exactly one [1..1] statusCode (CONF:15965).
– This statusCode SHALL contain exactly one [1..1]
@code="completed" Completed (CodeSystem: ActStatus
2.16.840.1.113883.5.14 STATIC) (CONF:15966).
• SHALL contain exactly one [1..1] value with @xsi:type="PQ" (CONF:7617).
– This value SHALL contain exactly one [1..1] @unit, which SHALL
be selected from ValueSet AgePQ_UCUM
2.16.840.1.113883.11.20.9.21 DYNAMIC (CONF:7618).

Usage
• The conformance verb keyword at the start of a constraint (
SHALL , SHOULD , MAY, etc.) indicates usage
conformance.
– SHALL is an indication that the constraint is to be enforced without
exception;
– SHOULD is an indication that the constraint is optional but highly
recommended; and
– MAY is an indication that the constraint is optional and that adherence to
the constraint is at the discretion of the document creator.

Cardinality
• The cardinality indicator (0..1, 0..*, 1..1, 1..*, etc.) specifies the allowable occurrences within an
instance.
• Thus, " MAY contain 0..1" and " SHOULD contain 0..1" both allow for a document to omit the
particular component, but the latter is a stronger recommendation that the component be
included, if it is known.
• The following cardinality indicators may be interpreted as follows:
– 0..1 as contains zero or one
– 1..1 as contains exactly one
– 2..2 as contains exactly two
– 1..* as contains one or more
– 0..* as contains zero or more
• Each constraint is uniquely identified (e.g., "CONF:605") by an identifier placed at or near the
end of the constraint.

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

Terminology Binding
Specification Data Element
Terminology Binding
- identifier: ST
- type: CD
- codeSystem.identifier: ST [0..1]
- codeValue: ST [0..1]
- name: ST
- valueSet.identifier: ST [0..1]
- /codeSystemTerm.identifier: ST [0..1]
- /valueSetMemberIdentifier: ST [0..1]
Code System
- identifier: ST
- name: ST
- OID: Uid
Code System Term
- codeValue: ST
- codeSystem.identifier: ST
- /identifier: ST
- name: ST
Value Set Member
- codeValue: ST
- codeSystem.identifier: ST
- preferredName: ST [0..1]
- /identifier: ST
- valueSet.identifier: ST
- /codeSystemTerm.identifier: ST
Value Set
- identifier: ST
- name: ST
- OID: Uid0..* 0..*1
0..*
0..1
0..*
0..1
0..*
0..1
0..*
0..*
0..1

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

Course
Outline
Brief History of HL7 v3 and CDA
Clinical Data Architecture Specification
CDA Template Profiles
CDA Implementation Guides
Consolidated CDA Implementation Guide
Continuity of Care C-CDA Document Type
CDA Product Family and Projects

CDA IMPLEMENTATION GUIDES

Partial list of Implementation Guides (by country)
• USA
– CCD (Continuity of Care Document) Rel.1
– CRS (Care Record Summary)
– SPL – Structured Product Label
– HAI (Healthcare associated infections)
– HITSP
– C32 –Summary Documents Using HL7 Continuity of Care Document (CCD)
– C37 – Lab Report
– C48 –Encounter Document Using IHE Medical Summary (XDS-MS) Component
– Consultation Notes
– History and Physical
– Operative Notes
– Imaging Integration, Basic Imaging Reports
• Canada
– e-MS (electronic Medical Summary)
• Germany
– VHitG-Arztbrief v1.50 (discharge summary)
– Addendum Laboratory
– Addendum Medication
– Addendum notifiable diseases (in progress)
• South Korea
– CDA conference 2004
• Austria
– ELGA (currently in progress)
• Switzerland
– CDA-CH v1.1
• France
– French CRS CDA Body implementation Guide (in French)
• Finland
– seamless Care and CDA
– Finnish (CDA) implementation guides: CDA R2, V3, Medical Records, V2, CDA R (in Finnish)
• Japan
– Japanese Clinical Summary document (in Japanese)

CDA Implementation Guides
(available for download from the HL7 website)
1. Clinical Oncology Treatment Plan and Summary, DSTU Release 1
2. Personal Healthcare Monitoring Report
3. Patient Generated Document Header Template, Release 1
4. Plan-to-Plan Personal Health Record (PHR) Data Transfer, Release 1
5. Public Health Case Reports (US Realm)
6. Quality Reporting Document Architecture –
Category I (QRDA) DSTU Release 2 (US Realm)
7. Level 1 and 2 - Care Record Summary (US realm)
8. Level 3: Emergency Medical Services; Patient
Care Report, Release 1 – US Realm
9. CDA Framework for Questionnaire Assessments, DSTU Release 2
10. Digital Signatures and Delegation of Rights,
Release 1
11. Exchange of Clinical Trial Subject Data; Patient Narratives, Release 1 - US
Realm
12. Genetic Testing Reports, Release 1
13. Healthcare Associated Infection (HAI) Reports
14. HIV/AIDS Services Report, Release 1 - US Realm
15. IHE Health Story Consolidation, Release 1.1 - US Realm
16. Long-Term Post-Acute Care Summary, DSTU Release 1 (US Realm)
17. Patient Assessments, Release 1
18. Quality Reporting Document Architecture - Category III (QRDA III), DSTU
Release 1
19. Questionnaire Form Definition Document, Release 1
20. Questionnaire Response Document, Release 1
21. Reference Profile for EHR Interoperability, Release 1
22. Trauma Registry Data Submission, Release 1
23. Consent Directives, Release 1
24. Procedure Note, Release 1
25. greenCDA Modules for CCD®, Release 1
26. Imaging Integration; Basic Imaging Reports in CDA and DICOM, Release 1
27. Specification and Use of Reusable Information Constraint Templates, Release 1
28. Neonatal Care Reports (NCR), R1
29. Continuity of Care Document (CCD®) Release 1
30. Consolidated CDA Templates for Clinical Notes DSTU 2.1 – US Realm

Domain Analysis
Model
HL7 Standard
Specifications
Conformance
Profiles
Implementations
Business
Requirements
Engineering
Requirements
Local
Requirements
From Requirements
to Implementation
Use Case
Base
Standard
Implementable
Specification

From Data Dict. to CDA Guide

Implementation Guide Development

DAM: a UML representation of dictionary elements
PreHospitalEcounter
- arrivalDateTime :TS [0..1]
- departureDateTime :TS [0..1]
- dispatchDateTime :TS [0..1]
+ preHospitalTransportationMethodCode :TransportationMethod [0..*]
PreHospitalNervousSystemObservation
+ glasgowComaEyeResponseValue :INT
+ glasgowComaMotorResponseValue :INT
+ glasgowComaScoreValue :INT
+ glasgowComaVerbalResponseCode :INT
PreHospitalCirculatorySystemObservation
+ heartRateAmount :PQ
+ systolicBloodPressureAmount :PQ
PreHospitalRespiratorySystemObservation
+ arterialOxygenSaturationAmount :PQ
+ respiratoryRateAmount :PQ
2.0 Submission::
RegistrySubmissionTransaction
0..1 0..1
0..1
0..1

Organization of DAM Classes
2.0 Submission
+ RegistrySubmissionTransaction
1.0 Patients
+ Patient
3.0 Injury Events
+ InjuryEvent
+ InjurySeverityObservation
4.0 PreHospital Encounters
+ PreHospitalCirculatorySystemObservation
+ PreHospitalEcounter
+ PreHospitalNervousSystemObservation
+ PreHospitalRespiratorySystemObservation
5.0 Hospital Care Episodes
+ HospitalCareEpisode
+ HospitalCirculatorySystemObservation
+ HospitalNervousSystemObservation
+ HospitalPhysiologicalObservation
+ HospitalRespiratorySystemObservation
+ 5.1 Emergency Hospital Encounters
+ 5.2 InpatientHospitalEncounters

Dictionary to DAM
Element ID NTDB Dictionary Element DAM Package DAM Class DAM Attribute
D_01 D_01: PATIENT’S HOME ZIP CODE 2.0 Patients Patient postalAddress
D_02 D_02: PATIENT’S HOME COUNTRY 2.0 Patients Patient postalAddress
D_03 D_03: PATIENT’S HOME STATE 2.0 Patients Patient postalAddress
D_04 D_04: PATIENT’S HOME COUNTY 2.0 Patients Patient postalAddress
D_05 D_05: PATIENT’S HOME CITY 2.0 Patients Patient postalAddress
D_06 D_06: ALTERNATE HOME RESIDENCE 2.0 Patients Patient residenceStatusCode
D_07 D_07: DATE OF BIRTH 2.0 Patients Patient birthDate
D_08 D_08: AGE 2.0 Patients Patient eventRelatedAgeQuantity
D_09 D_09: AGE UNITS 2.0 Patients Patient eventRelatedAgeQuantity
D_10 D_10: RACE 2.0 Patients Patient raceCode
D_11 D_11: ETHNICITY 2.0 Patients Patient ethnicCode
D_12 D_12: SEX 2.0 Patients Patient genderCode
DG_01 DG_01: CO-MORBID CONDITIONS 5.0 Hospital Care Episodes HospitalCareEpisode coMorbidConditionCode
DG_02 DG_02: ICD-9 INJURY DIAGNOSES 5.0 Hospital Care Episodes HospitalCareEpisode injuryDiagnosisCode
DG_03 DG_03: ICD-10 INJURY DIAGNOSES 5.0 Hospital Care Episodes HospitalCareEpisode injuryDiagnosisCode
ED_01 ED_01: ED/HOSPITAL ARRIVAL DATE 5.0 Hospital Care Episodes HospitalCareEpisode arrivalDateTime
ED_02 ED_02: ED/HOSPITAL ARRIVAL TIME 5.0 Hospital Care Episodes HospitalCareEpisode arrivalDateTime
ED_03 ED_03: INITIAL ED/HOSPITAL SYSTOLIC BLOOD PRESSURE 5.0 Hospital Care Episodes HospitalCirculatorySystemObservation systolicBloodPressureAmount
ED_043 ED_043: INITIAL ED/HOSPITAL PULSE RATE 5.0 Hospital Care Episodes HospitalCirculatorySystemObservation heartRateAmount
ED_05 ED_05: INITIAL ED/HOSPITAL TEMPERATURE 5.0 Hospital Care Episodes HospitalPhysiologicalObservation temperatureAmount
ED_06 ED_06: INITIAL ED/HOSPITAL RESPIRATORY RATE 5.0 Hospital Care Episodes HospitalRespiratorySystemObservation respiratoryRateAmount
ED_07 ED_07: INITIAL ED/HOSPITAL RESPIRATORY ASSISTANCE 5.0 Hospital Care Episodes HospitalRespiratorySystemObservation respiratoryAssistanceIndicator
ED_08 ED_08: INITIAL ED/HOSPITAL OXYGEN SATURATION 5.0 Hospital Care Episodes HospitalRespiratorySystemObservation arterialOxygenSaturationAmount
ED_09 ED_09: INITIAL ED/HOSPITAL SUPPLEMENTAL OXYGEN 5.0 Hospital Care Episodes HospitalRespiratorySystemObservation supplementalOxygenIndicator

CIM: a CDA influenced UML representation of
dictionary elements
Domain Analysis
Model
2
CDA RMIM
Constrained
Information Model
ArterialOxygenSaturationObservation
+ code :CD = ObservationType
- value :PQ
::RespiratorySystemObservation
+ classCode :CS = "OBS"
+ moodCode :CS = "EVN"
RespiratoryRateObservation
+ code :CD = ObservationType
- value :PQ
::RespiratorySystemObservation
RespiratorySystemObservation
PreHospitalEncounterDetail::
RespiratorySystemEntryRelationship
+ typeCode :CS = x_ActRelationsh...
+ contextConductionInd :BL = "true"
0..*
1

Organization of CIM Classes
InjuryEventSection
+ InjuryEventSection
+ StructuredBodyInjuryEventComponent
+ InjuryEventDetailEntry
(from TraumaRegistrySubmissionDocument)
TraumaRegistrySubmissionDocument
+ HealthcareFacility
+ RegistryParticipant
+ StructuredBodyComponent
+ StucturedBody
+ Submitter
+ TraumaRegistrySubmissionDocument
+ Patient
+ PreHospital Encounter Section
+ Hospital Care Episode Section
+ EntryPoint
Patient
+ RecordTarget
+ Patient
+ PatientRole
+ PatientDetailSection
PreHospital Encounter Section
+ PreHospitalEncounterSection
+ StructoredBodyPreHospitalEncounterComponent
+ PreHospitalEncounterDetail
Hospital Care Episode Section
+ HospitalCareEpisodeSection
+ StructuredBodyHospitalCareEpisodeComponent
+ HospitalCareEpisodeActivityDetail

DAM to CIM
DAM Class DAM Attribute CIM Class CIM Attribute
Patient birthDate Patient birthTime
Patient ethnicCode Patient ethnicGroupCode
Patient eventRelatedAgeQuantity PatientAgeObservation value
Patient genderCode Patient administrativeGenderCode
Patient industryCode PatientIndustryObservation value
Patient occupationCode PatientOccupationObservation value
Patient postalAddress PatientRole addr
Patient raceCode Patient raceCode
Patient residenceStatusCode PatientResidenceStatusObservation value
InjuryEvent abbreviatedInjuryCode AbreviatedInjuryObservation value
InjuryEvent airbagDeploymentCode AirbagDeploymentObservation value
InjuryEvent bodyInjuryRegionCode BodyInjuryObservation value
InjuryEvent injurySeverityScoreValue SeverityScoreObservation value
InjuryEvent locationTypeCode LocationTypeObservation value
InjuryEvent occurenceDateTime InjuryEventAct effectiveTime
InjuryEvent postalAddress PostalAddressObservation value
InjuryEvent primaryInjuryCauseCode PrimaryInjuryCauseObservation value
InjuryEvent safetyEquipmentUsedCode SafetyEquipmentUsedObservation value
InjuryEvent supplementalInjuryCauseCode SupplementalInjuryCauseObservation value
InjuryEvent workRelatedEventInd WorkRelatedObservation value
PreHospitalCirculatorySystemObservation heartRateAmount HeartRateObservation value
PreHospitalCirculatorySystemObservation systolicBloodPressureAmount SystolicBloodPressureObservation value
PreHospitalEncounter arrivalDateTime PreHospitalEncounter effectiveTime
PreHospitalEncounter departureDateTime PreHospitalEncounter effectiveTime

IG: Dictionary elements represented as templated
CDA constraints
3
CDA RMIM
Constrained
Information Model
NTDB
Implementation Guide
EMS

Organization of IG Templates

Organization of IG Templates
StucturedBody
+ classCode :CS = "DOCBODY"
StructuredBodyComponent
+ typeCode :CS = "COMP"
+ contextConductionInd :BL = "true"
TraumaRegistrySubmissionDocument
+ classCode :CS = "DOCCLIN"
+ id :II
+ code :CE = DocumentType
- effectiveTime :TS
PatientDetailSection::PatientDetailSection
Patient::PatientRole RegistryParticipant
+ classCode :CS = "ASSIGNED"
Submitter
+ typeCode :CS = "INF"
+ contextControlCode :CS = "OP"
HealthcareFacility
+ classCode :CS = "ORG"
+ determinerCode :CS = "INSTANCE"
- id :II
EntryPoint
Patient
+ RecordTarget
+ Patient
+ PatientRole
PatientDetailSection
+ StucturedBodyPatientDetailComponent
+ PatientDemographicObservation
+ PatientEmploymentObservation
(from Patient)
InjuryEventSection::InjuryEventSection PreHospital Encounter Section::
PreHospitalEncounterSection
Hospital Care Episode Section::
HospitalCareEpisodeSection
InjuryEventSection
+ StructuredBodyInjuryEventComponent
+ InjuryEventDetailEntry
PreHospital Encounter Section
+ PreHospitalEncounterSection
+ StructoredBodyPreHospitalEncounterComponent
+ PreHospitalEncounterDetail
Hospital Care Episode Section
+ HospitalCareEpisodeSection
+ StructuredBodyHospitalCareEpisodeComponent
+ HospitalCareEpisodeActivityDetail
Name: TraumaRegistrySubmissionDocument
Author: Salimah Shakir
Version: 1.0
Created: 2/7/2013 9:30:31 PM
Updated: 6/14/2013 12:01:15 AM
Act
Entity
Role
Participation
ActRelationship
Foriegn Class
Legend
1..11
1..1
1
1..1
1
1..1
1
1..1
1
1..1
1
0..1
1
1..1
1
HEADER
BODY
ENTRIES® Health Level Seven and HL7 are registered trademarks of Health Level Seven International, registered with the United States Patent and Trademark Office. 82

Dict to DAM to CIM to IG
NTDB Dictionary Element CDA Template CDA ITEM CDA Clone CDA Attribute CDA CONF
D_01: PATIENT’S HOME ZIP CODE 3.1 Trauma Registry Submission Document 8.c.111 patientRole addr 27773
D_02: PATIENT’S HOME COUNTRY 3.1 Trauma Registry Submission Document 8.c.111 patientRole addr 27773
D_03: PATIENT’S HOME STATE 3.1 Trauma Registry Submission Document 8.c.111 patientRole addr 27773
D_04: PATIENT’S HOME COUNTY 3.1 Trauma Registry Submission Document 8.c.111 patientRole addr 27773
D_05: PATIENT’S HOME CITY 3.1 Trauma Registry Submission Document 8.c.111 patientRole addr 27773
D_06: ALTERNATE HOME RESIDENCE 5.3 Patient Demographic Observations Organizer 42.c.iv observation value 30000
D_07: DATE OF BIRTH 3.1 Trauma Registry Submission Document 8.c.iv.4 patient birthTime 27776
D_08: AGE 5.3 Patient Demographic Observations Organizer 43.c.iv observation value 30008
D_09: AGE UNITS 5.3 Patient Demographic Observations Organizer 43.c.iv.1 observation value@unit 30455
D_10: RACE 5.3 Patient Demographic Observations Organizer 44.c.iv observation value 30508
D_11: ETHNICITY 3.1 Trauma Registry Submission Document 8.c.iv.5 patient ethnicGroupCode 27778
D_12: SEX 3.1 Trauma Registry Submission Document 8.c.iv.3 patient administrativeGenderCode 27775
DG_01: CO-MORBID CONDITIONS 6.5 Hospital Care Episode Observation Organizer 84.c.iv observation value 30385
DG_02: ICD-9 INJURY DIAGNOSES 6.5 Hospital Care Episode Observation Organizer 85.c.iv observation value 30397
DG_03: ICD-10 INJURY DIAGNOSES 6.5 Hospital Care Episode Observation Organizer 85.c.iv observation value 30397
ED_01: ED/HOSPITAL ARRIVAL DATE 5.1 Hospital Care Episode Encounter 31 encounter effectiveTime 30341
ED_02: ED/HOSPITAL ARRIVAL TIME 5.1 Hospital Care Episode Encounter 31 encounter effectiveTime 30341
ED_03: INITIAL ED/HOSPITAL SYSTOLIC BLOOD PRESSURE 6.1 Circulatory System Observation Entry 63.c.iv observation value 29639
ED_043: INITIAL ED/HOSPITAL PULSE RATE 6.1 Circulatory System Observation Entry 62.c.iv observation value 29633
ED_05: INITIAL ED/HOSPITAL TEMPERATURE 6.7 Hospital Care Physiological Observation 100.c.iv observation value 30431
ED_06: INITIAL ED/HOSPITAL RESPIRATORY RATE 6.16 Respiratory System Observation Entry 145.c.iv observation value 30092
ED_07: INITIAL ED/HOSPITAL RESPIRATORY ASSISTANCE 6.15 Respiratory System Observation 140.c.iv observation value 30437
ED_08: INITIAL ED/HOSPITAL OXYGEN SATURATION 6.16 Respiratory System Observation Entry 144.c.iv observation value 30085
ED_09: INITIAL ED/HOSPITAL SUPPLEMENTAL OXYGEN 6.15 Respiratory System Observation 141.c.iv observation value 30441

Trauma Registry Data Submission IG

Introduction and Specification Overview

Scope

Templates

Document Template

Section Templates

Entry Templates

Vocabulary Tables

CDA
Template
Authoring
Tools

Model Driven Health Tools (MDHT)
an open source framework that enables community authoring

Model Driven Health Tools
• MDHT defines healthcare-specific UML
profiles to specify the interoperability
standards and delivers model editing
tools that are optimized for clinical
informatics users, including a
customized interface for the UML profile
extensions.
• There are three primary categories of
users for MDHT tools:
o authors of healthcare industry
interoperability standards,
o certification or testing authorities
who validate that an Electronic Health
Record (EHR) system produces XML
or JSON files that comply with the
standard, and
o software developers that implement
adapters or applications that produce
and consume healthcare data.

• An open-source tool suite
that supports the creation
and maintenance of HL7
templates, value sets,
scenarios and data sets.
• The tool features cloud-
based federated Building
Block Repositories (BBR) for
Templates and Value Sets.
• It supports comprehensive
collaboration of team
members within and between
governance groups.
ART-DECOR®

What is ART-DECOR?
• DECOR (Data Elements, Codes, OIDs and Rules) is a methodology to record the information model used by health professionals.
• DECOR uses this model to generate various artifacts: documentation, XML- and test-tooling, etc.
• With DECOR it is possible to improve the recorded information model by generating and resolving issues per item.
• DECOR registers (amongst others) datasets, datatypes, valuesets, codes, identifications, and business rules.
• The underlying data-format is XML. Generation of HTML-documentation and XML-materials is possible through transformations
with stylesheets.
• DECOR consists of two parts:
– DECOR methodology: a framework to model artifacts (including documentation)
– DECOR software: XML-schemas, XML-schematrons, XML-stylesheets.
• ART (Advanced Requirement Tooling) is the DECOR user interface to create and adapt DECOR files, and to generate artifacts
from DECOR files.
• ART is based on the eXist-db XML database, XQuery and Orbeon XForms.

CONSOLIDATED CDA
IMPLEMENTATION GUIDE

Consolidated CDA

Collaborative Work Product
• This guide was produced and developed through the joint efforts of Health Level Seven (HL7),
Integrating the Healthcare Environment (IHE), the Health Story Project, and the Office of the
National Coordinator (ONC) within the US Department of Health and Human Services (HHS).
• The project was carried out within the ONC’s Standards and Interoperability (S&I) Framework
as the Clinical Document Architecture (CDA) Consolidation Project with a number of goals, one
of which is providing a set of harmonized CDA templates for the US Realm.

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

CCD Contained Templates

Consultation Notes
• The Consultation Note is generated by a request from a clinician for an
opinion or advice from another clinician.
• Consultations may involve face-to-face time with the patient or may fall
under the auspices of tele-medicine visits.
• Consultations may occur while the patient is inpatient or ambulatory.
• The Consultation note should also be used to summarize an
Emergency Room or Urgent Care encounter.
• A consultation note includes the reason for the referral, history of
present illness, physical examination, and decision-making
components (Assessment and Plan).

Consultation Notes Contained Templates

Discharge Summary
• The Discharge Summary is a document which synopsizes a patient's admission to a hospital, LTPAC provider,
or other admission.
• It provides information for the continuation of care following discharge.
• The Joint Commission requires the following information to be included in the Discharge Summary:
• The reason for hospitalization the admission
• The procedures performed, as applicable
• The care, treatment, and services provided
• The patient’s condition and disposition at discharge
• Information provided to the patient and family
• Provisions for follow-up care

Discharge Summary Contained Templates

14 Document Level Templates

52 Section Level Templates

88 Entry Level Templates

C-CDA Sections and Entry Templates
Clinical Document Lego Blocks

Required and Optional Sections by Document
Type

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

Medications

Problems

Procedures

Results

Social History

Vital Signs

Sections of the CCD
Required Sections Optional Sections

CDA PRODUCT FAMILY AND
PROJECTS

Clinical Document Architecture
Management Group
The Clinical Document Architecture
Management Group (CDA-MG) provides
day-to-day oversight of the processes
related to Clinical Document Architecture
(CDA) products throughout their lifecycle.
This includes ensuring CDA product
quality, monitoring scope and consistency
with Standards Governance Board (SGB)
principles and aiding in the resolution of
CDA related intra and inter-work group
issues.

Primary activities of the CDA-MG
• All planning aspects of product line/family changes
• Assessing and approving product line-specific project proposals for submission to the TSC
• Assessing and approving publishing requests for submission to the TSC
• Creating Product recommendations which may include:
• CDA IG recommendations
• Ensure that quality assurance criteria are in place and applied
• Escalation of unresolved issues to the TSC .
• Define priorities within the priority management criteria which the Governance Board has created
• Support activities such as education and connectathons
• Implementation guidance for the appropriate use of products
• Propose to SGB, as needed, precepts for the product family and adhere to those established by the SGB
• Ensure work done on the CDA Base Standard is consistent with the constructs of V3 modeling and methodology

Structured Documents Workgroup
This group supports the HL7 mission
through development of structured
document standards for healthcare.
The Work Group will produce a
comprehensive architecture to facilitate
exchange and processing of electronic
healthcare documents.
The Work Group will support HL7 through
education in the development, evolution,
and use of structured document
specifications.
The specifications created by this
committee will follow the accepted HL7
development processes.

SDWG Sponsored CDA Projects
C-CDA Companion
Guide update
Clinical Data Exchange
(CDex)
Quality Criteria

C-CDA
Companion
Guide
update
• Description:
The Office of the National Coordinator (ONC) releases periodic proposed rules, and final
rules, which reference the use of Consolidated CDA (C-CDA). The Companion Guide to
Consolidated Clinical Document Architecture (C-CDA) provides supplemental guidance to the
Health Level Seven (HL7) CDA® R2 IG: C-CDA Templates for Clinical Notes STU. The prior
version of the companion guide is specific to a rule, the 2015 ONC Certification rule.
This project will update the guide to make it rule independent and will consider updates to
meet current and proposed regulations. New C-CDA templates to support USCDI will be
considered. Future regulations when published may also be considered appropriate for the
scope of this project.
Project Milestone Target Date
 Submit for STU Ballot (First Ballot Cycle) 2019 June/July Ballot (out of cycle)
 Complete STU Reconciliation 2019 August
 Request STU Publication 2019 August OR September
 Submit for 2nd STU Ballot 2020 May Ballot
 Complete STU Reconciliation 2020 July
 Request STU Publication 2020 August
 Project End Date 2025 - tentative, not firm.
® Health Level Seven and HL7 are registered trademarks of Health Level Seven International, registered with the United
States Patent and Trademark Office. 132

Clinical Data
Exchange
(CDex)
• Description:
The Clinical Data exchange (CDex) is part of the larger Da Vinci use case for Health Record exchange (HRex). The
scope of the CDex project is to defined combinations of exchange methods (push, pull, subscribe, CDS Hooks, …),
specific payloads (Documents, Bundles, and Individual Resources), search criteria, conformance, provenance, and
other relevant requirements to support specific exchanges of clinical information between provider and other providers
and/or payers.
The goal is to identify, document and constrain very specific patterns of exchange so that providers and payers can
reliably exchange information for patient care (including coordination of care), risk adjustment, quality reporting,
identifying that requested services are necessary and appropriate (e.g. should be covered by the payer) and other uses
that may be documented as part of this effort.
Clinical data payloads will include C-CDA, C-CDA on FHIR, compositions, bundles, specific resources, and bulk data
exchange. This list is intended to be illustrative and not prescriptive. This project will reference, where possible the
"standards" defined by the Health Record exchange (HRex) Framework Implementation Guide which in turn will utilize
prior work.
 Ballot for Comment (First Ballot Cycle) 2019 May Ballot
 Submit for STU Ballot (Second Ballot
Cycle)
2019 Sep Ballot
 Complete STU Reconciliation and Request
Publication
2020 Jan WGM
 Submit for STU 2 Ballot (Third Ballot Cycle) 2020 Sep Ballot
 Complete STU 2 Reconciliation and
Request Publication
2021 Jan WGM
 STU Period 2021 Jan -2022 Jan
 Submit for Normative Ballot 2022 May Ballot
 Complete Normative Reconciliation 2022 Sep WGM
 Submit Publication Request 2022 Oct
 Project End Date (all objectives have been
met)
2022 Dec

CDA
Implementation
Guide Quality
Criteria
Maintenance
• Description:
This project will identify the requirements and develop and ballot the initial set of 'key' FHIR profiles
necessary to support the Clinical Document use case as defined by CDA. Current C-CDA to FHIR
mapping work (not part of this project) will inform this project.
This project’s intent to provide a framework within which the Structured Documents Work Group will
develop and maintain a set of CDA Implementation Guide quality criteria. Sources for the criteria may
include the following:
• Existing CDA IG quality criteria developed by the Structured Documents Work Group
• Standards Governance Board (SGB) precepts
• Template quality criteria identified by the Templates work group
This project covers the development of the initial set of CDA IG quality criteria as well as the ongoing
maintenance of those criteria.
 Review existing CDA IG Quality Criteria and
create draft version for formal review
2019 Jan WGM
 Formal Review (Draft for Comment Ballot)
of Draft CDA IG Quality Criteria
2019 May Ballot
 Reconcile comments 2019 May WGM
 Approve initial version of CDA IG Quality
Criteria and make available to CDA IG
developers and CDA Management Group
2019 Sept WGM
 Repeat every 1-2 years as needed TBD
 Project End Date (all objectives have been
met)
Ongoing maintenance project

Retrospective
• HL7 v3 model driven specification design
• Clinical Document Architecture
– Header and Participants
– Structured and Unstructured Body
– Sections and Entries
• Template Conformance Profiles
• Implementation Guides
• CDA, C-CDA, and CCD
• CDA Product Family Strategies and Tactics
SANKOFA

Questions / Discussion / Feedback

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

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

More from Abdul-Malik Shakir

More from Abdul-Malik Shakir (11)

Recently uploaded

Recently uploaded (20)