Standards and Harmonization
Data Provenance
S&I Framework
December 4th, 2014
1
Agenda
Topic
Time Allotted
Announcements
5 minutes
HL7 Implementation Guide for CDA® Release 2: Digital
Signatures and Delegation of Rights, Release 1 presentation by
Bob Dieterle
15 minutes
CDA R2, CCDA, CDA IG, HL7 V2 presentation by Bob Yencha
30 minutes
Comments and Questions
10 minutes
DPROV Harmonization Timeline
Nov.
Dec.
Today
Jan.
10/23 – 1/8
Create IG Template
IG Development
Feb.
March
April
May
DPROV Harm Launch
Standards SME presentations
1/8-2/5
Solution
Planning
Standards
Evaluation
Oct.
Standards Analysis & Assessment
1/29 – 3/5
Solution Planning
12/15 - 1/5
Introduction
1/22 - 2/5
Implementation Approach
3/5 – 4/5
Suggested Enhancements
4/5 – 4/12
End-to-End Review
4/12 – 5/5
3
Data Provenance Standards Presentations Schedule
Standard to Present
ISO 21089 Health Informatics: Trusted End-to-End Information Flows
11/20/2014
SOAP
THANKSGIVING HOLIDAY
1. C-CDA
2. CDA R2
3. HL7 Implementation Guide for CDA® Release 2: Data
Provenance, Release 1 – US Realm
12/4/2014 4. HL7 V2
Date
SME Name
Gary Dickinson
Glen Marshall
Confirmed
Y
Y
Bob Yencha +
Kathleen Connor
Y
HL7 Implementation Guide for CDA® Release 2: Digital Signatures and Delegation of
Rights, Release 1
Bob Dieterle
Y
1. HL7 EHR Interoperability Model DSTU (2007)
2. HL7 Implementation Guide for CDA Release 2: Reference Profile for EHR
Interoperability DSTU (2008)
12/11/2014 3. HL7 EHR Lifecycle Model DSTU (2008)
Gary Dickinson
4. ISO/HL7 10781 EHR System Functional Model, Release 2 (2014)
5. HL7 Record Lifecycle Events on FHIR (project underway 2014 for FHIR DSTU Release 2)
Y
HL7 Implementation Guide for CDA®, Release 2: Consent Directives, Release 1
12/18/2014 HL7 EHR Records Management and Evidentiary Support (RM-ES) Functional Model,
Release 1
As a grouping of Implementation Guides:
Serafina Versaggi
Reed Gelzer
Diana Warner
Y
Y
1. HL7 Health Care Privacy and Security Classification System, Release 1
2. HL7 Version 3 Standard: Privacy, Access and Security Services (PASS)
1/8/2015
3. HL7 Version 3 Standard: Privacy, Access and Security Services; Security Labeling
Service, Release 1 (SLS)
Kathleen Connor
*Associated vocabulary
HL7 Implementation Guide: Data Segmentation for Privacy (DS4P), Release 1
Y
Updated Candidate Standards
#
1 a)
2 a)
2 b)
3 a)
3 b)
Transaction
Content and Structure
Terminology and Code
Values - DP
*C-CDA
*HL7 V.2/ V.3
*CDA R2
Vocabulary &
Start Point sends clinical data *W3C PROV: PROV-AQ, PROVTerminology Standards
with provenance information CONSTRAINTS, PROV-XML
to End Point
*Personal Health Record System
Functional Model
*HL7 EHR Records Management and
Evidentiary Support (RM-ES) Functional
Start Point sends clinical data Model, Release 1
to transmitter with
*ISO/HL7 EHR System Functional Model
provenance information
Release 2
*HL7 EHR Lifecycle Model (2008)
*HL7 Record Lifecycle Event Metadata
using FHIR (project underway 2014)
Transmitter send clinical data *HL7 V.2.x
to end point with provenance *ISO 21089 Health Informatics: Trusted
information
End-to-End Information Flows
*HL7 FHIR DSTU Release 1.1 Provenance
Resource
*HL7 Implementation Guide for CDA®
Start Point sends clinical data Release 2: Data Provenance, Release 1 –
to assembler/composer with US Realm
provenance information
*HL7 Implementation Guide for CDA®,
Release 2: Consent Directives, Release 1
*HL7 EHR Interoperability Model DSTU
(2007)
Assembler/composer compiles *HL7 Implementation Guide for CDA
clinical data which is sent to Release 2: Reference Profile for EHR
end point with provenance
Interoperability DSTU (2008)
information
Transport
Security
*Representation
State Transfer
(RESTful)
*Cross Enterprise
Document-Sharing
XDS
*SOAP
*HL7 Implementation Guide: Data
Segmentation for Privacy (DS4P),
Release 1
* HL7 Health Care Privacy and Security
Classification System, Release 1 (HCS)
*HL7 Version 3 Standard: Privacy,
Access and Security Services (PASS)
*HL7 Version 3 Standard: Privacy,
Access and Security Services; Security
Labeling Service, Release 1 (SLS)
*HL7 Implementation Guide for CDA®
Release 2: Digital Signatures and
Delegation of Rights, Release 1
HL7 CDA and V2
Bob Yencha
RTY LLC
December 4, 2014
Basics
 Clinical Document Architecture
 ANSI/HL7 CDA R1.0-2000
 ANSI/HL7 CDA R2.0-2005, Re-affirmed 2010
 Created & maintained by HL7 Structured
Documents Work Group (SDWG)
 An XML specification for document exchange
 HL7 Reference Information Model (RIM)
 Vocabulary (HL7, SNOMED, LOINC, ICD, local,…)
 Transport agnostic
CDA Characteristics
 (§2.1) “A clinical document ... has the following
characteristics :
 Persistence
 Stewardship
 Potential for authentication
 Context
 Wholeness
 Human readability”
 (§4.2.1) “A clinical document is a documentation
of clinical observations and services…”
 A snapshot in time, immutable set of facts
Core Concepts of CDA
 Provides a framework for defining models (templates)
for:
 Documents
 Sections
 Entries
 Documents provide a context
 Referral, Surgical Note, Continuity of Care …
 Sections and entries are re-used across document
types
 Vital Signs Section: Blood Pressure, Weight, et al
 Medications Section: active and inactive medications
RIM Concepts
 Every happening (event) is an Act
 Procedure, observation, substance administration, etc.
 Participation defines involvement in an Act
 Author, performer, subject, location, etc.
 The participants have Roles
 Patient, agent, responsible party.
 Roles are played and scoped by Entities
 Persons, organizations, material, places, devices, etc
 Acts are related through ActRelationship
CDA and Provenance
 CDA documents have characteristics that support
traceability and verification
 Provenance meta-data is “built-in” to CDA but not
specifically enforced or uniformly applied for today’s
requirements
 Solution is to provide constraining templates that
orchestrate the available components to present a
consistent capture of core data provenance facts
(who/what/when/where/how/why) at all levels:
 Documents
 Sections
 Entries
Implementation Guides
 Consolidated CDA, R2
 A catalog of document, section and entry level templates
 Has namespace extensions to support evolving
requirements, e.g., digital signatures
 The architecture allows for additional external constraints
to be applied without conflict, e.g., the HL7 DPROV for
CDA IG
 Defines additional constraints to orchestrate the capture of
information regarding Entities that are Participants in an Act,
the Roles they are playing, and they’re relationship to the
other Participants
Optimizing CDA inherent provenance leveraging HL7 ControlAct
Provenance Metadata Patterns
DPROV STANDARDS HARMONIZATION
HL7 DPROV CDA IG
DPROV CDA IG as Provenance Enabling Overlay
• Like HL7 DS4P CDA IG, DPROV CDA IG offers a
set of Provenance Enabling Overlays that can
be flexibly applied to meet use case
requirements to any CDA IG
• Any set of DPROV CDA IG
Document/Section/Entry templates may be
used as applicable
• Provenance Metadata maximizes CDA
provenance support
Use of Multiple DPROV Template Overlays
• A DPROV conformant IG permits the use of
any of the DPROV Document templates where
there are multiple Authors, i.e., where a
Provider is an Author of a Document that
includes Assembler generated content.
• Any DPROV conformant document may
include one or more Assembler generated
entries where the Assembler is the sole
author or is a co-author of the entry.
DPROV Provenance Metadata
Supports representation of provenance for:
• Any Clinical Statement Entry Type in one of 3 ways:
– An Entry referencing another predecessor Entry in the Document
• Observation A is an except of internal Observation B
– An Entry referencing a predecessor Entry external to the Document
• Observation B replaces an external Observation C
• Association of an Entry at:
– State N with predecessor at State N-1 Legally authenticated
Observation A
– State N-1 with predecessor at State N-2 Authenticated Observation A
– State N-2 with predecessor at State N-3 Newly created Observation A
How to Use Provenance Metadata Template
• There is both a Provenance Metadata Entry
Relationship and a Provenance Metadata template.
The entryRelationship may be on any Clinical
Statement in any Section, and is intended to link
predecessor versions of the Entry via state transitions
following the same pattern used in v2 and v3 via
ControlActEvents.
• ProvenanceMetadata Entry captures the CurrentState
of a target Entry as a transition from a referenced
internal or external Entry where the transition is not
one supported by current entryRelationship or
externalReference ActRelationshipType codes.
How to Use Provenance Metadata Template (cont.)
• E.g., if an Observation is an Excerpt from another Observation in the document,
then provenance is conveyed by XCRPT type code from
x_ActRelationshipEntryRelationship. If an Observation replaces an externally
referenced Observation, then provenance is conveyed by RPLC type code from
x_ActRelationshipExternalReference.
• However, if the transition from an internal or external referenced Observation is
to the state that cannot be conveyed with the current CDA R2
x_ActRelationshipExternalReference and x_ActRelationshipEntryRelationship
codes, then ProvenanceMetadata is used.
• For example, if a successor Observation is referenced by ProvenanceMetadata
with a ProvenanceEventCurrentState code “legally authenticated” and the
ProvenanceMetadata references an internal or external Observation, which is
the predecessor of that Observation, then the ProvenanceMetadata indicates a
state transition from a previous state, e.g., “authenticated.” The authenticated
predecessor Observation may also have a component ProvenanceMetadata
Entry, which would capture its state transition from a previous state, e.g., from a
“new” Observation. This pattern supports conveyance of an Entry’s (in this case,
Observation) Lifecycle.
Provenance Metadata LifeCycle Building Blocks
externalActChoice
ExternalAct
classCode*: <= ACT
moodCode*: <= EVN
id: SET<II> [0..*]
code: CD CWE [0..1] <= ActCode
text: ED [0..1]
entryRelationship
typeCode*: <= x_ActRelationshipEntryRelationship
inversionInd: BL [0..1]
contextConductionInd*: BL [1..1] "true"
sequenceNumber: INT [0..1]
negationInd: BL [0..1]
seperatableInd: BL [0..1]
ExternalObservation
c
l
i
n
i
c
a
l
S
t
a
t
e
m
e
n
t
Observation
0..* clinicalStatement
classCode*: <= OBS
moodCode*: <= x_ActMoodDocumentObservation
id: SET<II> [0..*]
code*: CD CWE [1..1] <= ObservationType
negationInd: BL [0..1]
derivationExpr: ST [0..1]
text: ED [0..1]
statusCode: CS CNE [0..1] <= ActStatus
effectiveTime: IVL<TS> [0..1]
priorityCode: CE CWE [0..1] <= ActPriority
repeatNumber: IVL<INT> [0..1]
languageCode: CS CNE [0..1] <= HumanLanguage
value: ANY [0..1]
interpretationCode: SET<CE> CNE [0..*]
methodCode: SET<CE> CWE [0..*]
targetSiteCode: SET<CD> CWE [0..*]
componentOf
0..1 clinicalStatement X
Provenance Metadata
classCode*: <= Act
moodCode*: <= EVN
id: SET<II> [0..*]
code*: CD CWE [1..1]
<=ProvenanceEventCurrentState = legally
authenticated
performer
0..* assignedEntity
typeCode*: <= x_ServiceEventPerformer
functionCode: CE CWE [0..1] <= ParticipationFunction
time: IVL<TS> [0..1]
AssignedEntity
0..1 representedOrganization
0..1 assignedPerson
ExternalProcedure
reference
0..* externalActChoice
typeCode*: <= x_ActRelationshipExternalReference
seperatableInd: BL [0..1]
0 ..* clinicalStatement
typeCode*: <= COMP
0..1 encompassingEncounter
classCode*: <= OBS
moodCode*: <= EVN
id: SET<II> [0..*]
code: CD CWE [0..1] <= ActCode
text: ED [0..1]
classCode*: <= PROC
moodCode*: <= EVN
id: SET<II> [0..*]
code: CD CWE [0..1] <= ActCode
text: ED [0..1]
ExternalDocument
classCode*: <= DOC
moodCode*: <= EVN
id: SET<II> [0..*]
code: CD CWE [0..1] <= DocumentType
text: ED [0..1]
setId: II [0..1]
versionNumber: INT [0..1]
reference
Observation n-1
classCode*: <= Act
moodCode*: <= EVN
code*: CD CWE [1..1]
typeCode*: < = COMP
contextConductionInd
*: BL[1..1] "true"
sequenceNumber: INT[0..1]
seperatableInd: BL[0..1]
componentOf
typeCode*: <= COMP
0..1 encompassingEncounter
Provenance Metadata
classCode*: <= Act
moodCode*: <= EVN
id: SET<II> [0..*]
code*: CD CWE [1..1]
<=ProvenanceEventCurrentState =
authenticated
Observation n-2
classCode*: <= Act
moodCode*: <= EVN
code*: CD CWE [1..1]
0 ..* clinicalStatement
reference
typeCode*: < = COMP
contextConductionInd
*: BL[1..1] "true"
sequenceNumber: INT[0..1]
seperatableInd: BL[0..1]
componentOf
typeCode*: <= COMP
0..1 encompassingEncounter
Provenance Metadata
classCode*: <= Act
moodCode*: <= EVN
id: SET<II> [0..*]
code*: CD CWE [1..1]
<=ProvenanceEventCurrentState = new
0 ..* clinicalStatement
reference
Observation n-3
classCode*: <= Act
moodCode*: <= EVN
code*: CD CWE [1..1]
typeCode*: < = COMP
contextConductionInd
*: BL[1..1] "true"
sequenceNumber: INT[0..1]
seperatableInd: BL[0..1]
HL7 V2.x Messages
 Some parallels to documents but with very different
goals leading to fundamental differences in what is
available, how it is structured and how it is intended to
be used.
 Message types supply context akin to a doctype:
 A lab order (OML) and a lab result (ORU)
 Patient registration and demographics (ADT)
 Unlike documents, not intended to persist
 Consume and incorporate/act on content.
Similar but…
 CDA defines Documents
 V2 defines Messages
 Documents have sections
 Messages have
 Sections have entries that
are based on clinical
statement patterns
segments
 Segments have fields
(concepts) with structure
and content further
defined by a data type
V2 and Data Provenance
 Given the difference in purpose, some of what is explicit in
documents is not carried in messages, .e.g., who created a
segment of a message.
 Authorship is not a concept available for every segment
 Some “source” concepts supported in specific segments,
e.g. “Responsible Observer”:
 Definition: When required, this field contains the identifier of the
individual directly responsible for the observation (i.e., the
person who either performed or verified it). In a nursing service,
the observer is usually the professional who performed the
observation (e.g., took the blood pressure). In a laboratory, the
observer is the technician who performed or verified the
analysis.
Support Team and Questions
Please feel free to reach out to any member of the Data
Provenance Support Team:
•
•
•
•
Initiative Coordinator: Johnathan Coleman: jc@securityrs.com
OCPO Sponsor: Julie Chua: julie.chua@hhs.gov
OST Sponsor: Mera Choi: mera.choi@hhs.gov
Subject Matter Experts: Kathleen Conner: klc@securityrs.com and Bob
Yencha: bobyencha@maine.rr.com
• Support Team:
– Project Management: Jamie Parker: jamie.parker@esacinc.com
– Use Case Development: Atanu Sen: atanu.sen@accenture.com
– Harmonization and Standards Development Support:
» Alex Lowitt: alexander.s.lowitt@accenturefederal.com
» Atanu Sen: atanu.sen@accenture.com
» Perri Smith: perri.smith@accenturefederal.com
– Support: Lynette Elliott: lynette.elliott@esacinc.com and Apurva Dharia:
apurva.dharia@esacinc.com