data provenance tiger team june 16, 2014 johnathan coleman johnathan coleman - initiative...
TRANSCRIPT
Data Provenance Tiger Team
June 16, 2014
Johnathan Coleman - Initiative Coordinator
Lynette Elliott – Tiger Team Support
Bob Yencha – Subject Matter Expert
Ioana Singureanu – Modeling Facilitator
Kathleen Connor – Subject Matter Expert
Neelima Chennamaraja - Modeling Facilitator
2
Agenda
Topic Time Allotted
General Announcements 1 minuteHL7 Project Scope Statement Update, Timeline 1 minutes
Task Activity 50 minutesNext Steps/Wrap Up 5 minutes
3
Meeting Etiquette
• Please mute your phone when you are not speaking to prevent background noise.– All meetings are recorded.
• Please do not put your phone on hold. – Hang up and dial back in to prevent
hold music.• Use the “Chat” feature to ask questions
or share comments.– Send chats to “All Participants” so
they can be addressed publicly in the chat, or discussed in the meeting (as appropriate).
Click on the “chat” bubble at the top of the meeting window to
send a chat.
The Star and Swoosh, Putting the I in Health IT, the Putting the I in Health IT composite logo, HealthIT.gov, the HealthIT.gov composition logo, HealthITBuzz, and the HealthITBuzz composite logo are service marks or registered service marks of the U.S. Department of Health and Human Services.
Office of the National Coordinator for Health Information Technology
May- Jun ‘14 Jul- Aug ‘14 Sept- Oct ‘14 Nov- Dec ‘14M
ilest
ones
HL7 Ballot (Aug 8- Sept 8)
Dat
a Pr
oven
ance
HL7 Project Scope Statement (May 18)
Consensus/ End-to-end Review
HL7
HL7 Notification of Intent to Ballot (June 29)
HL7 Initial Content Deadline (Jul .13)
HL7 WG Meeting (Sept 14-19)
HL7 Final Content Due (Aug. 3)
Data Provenance Tiger Team HL7 September 2014 Ballot
HL7 Ballot Reconciliation (Sept. 8-Nov. 21)
Today
HL7 DSTU Publication Dec. ‘14
Tiger Team Timeline
Day Date Mon 28-Apr Kick off
Mon 5-May No meeting - HL7
Mon 12-May Set-up, begin analysis Model and example doc review, gather requirements & related materials for review
Mon 19-May Analysis Requirements review
Tue 27-May Analysis Address requirementsMon 2-Jun Analysis Address requirements
Mon 9-Jun Harmonization requests dueAnalysis
HL7 Harmonization Committee Schedule:Initial Proposal Deadline: Sunday, June 15, 2014, MidnightTechnical review: Tuesday or Wednesday June 17-18, 2014
Mon 16-Jun Analysis
Mon 23-Jun Analysis
Mon 30-Jun Analysis Final Harmonization Proposal Deadline: Sunday, July 6, 2014, MidnightHarmonization Mtg: Tuesday through Friday, July 15-18, 2014
Mon 7-Jul Analysis/review draft ballot
Mon 14-Jul Review draft ballotMon 21-Jul Review draft ballot
Mon 28-Jul Final ballot review and sign-off Next 3 days will be used to finalize pubs packageFri 1-Aug Ballot Submission
Agenda
Modeling:
• Clarify assumptions on use of header, section and entry data elements– Capture of provenance “known facts” in existing
CDA structures
– Begin to frame “best practice” guidance on what is available today
– Identify areas for future work and recommendations to full initiative
Framing Concepts for CDA IG
• Context conduction & inheritance within the document– How this will play out in new uses of parts of
document
The Star and Swoosh, Putting the I in Health IT, the Putting the I in Health IT composite logo, HealthIT.gov, the HealthIT.gov composition logo, HealthITBuzz, and the HealthITBuzz composite logo are service marks or registered service marks of the U.S. Department of Health and Human Services.
Office of the National Coordinator for Health Information Technology
8
Entry/Observation
Section
Header
author
informant
authenticator
provider
organization
device
provider
organization
device
providerRepresentedorganization
legalAuthenticator provider
Representedorganization
author
informant
provider
organization
device
provider
organization
device
author
informant
providerorganization
device
provider
organization
device
Todays topics
• Role of authenticator and legalAuthenticator– Header only - not on sections or entries– Where do these roles come into play with the
changes in the above– Relationship to custodian?– Relationship to author?
Todays topics
• Assignment in clinical organizations and workflow is clear– Inclusion of information from multiple sources is
included into a new clinical document that can be legally authenticated as “fit for use for clinical care”
• Guidance questions to be resolved– Who/what is legalAuthenticator in clinical vs. non-
clinical settings e.g. an HIE where document is assembled as result of query, no clinical review is performed
Todays topics
• Author - generally– Authors create new info (may be a device)
• Author at Header?– Assembler vs. “traditional” view of device
participation• Does NOT create new information, repackages existing
content• What is level of detail about assembler we want to
capture and communicate?• Use of assignedAuthor?
Todays topics
• Informant– Suppliers vs. custodians– Single provider vs. teams
13
Data Provenance Tiger TeamNext Steps
• Monitor wiki for updated draft based on todays work– Please use the comment capture form on the wiki
• Requests for community input– Submit any potential requirement not previously discussed
or included in draft IG for discussion on next meeting on the wiki Requirements page
– Identify any other candidate source IGs for review
• Next Meeting – Monday, June 16 @ 3:00PM ET
14
• Questions?
Data Provenance Tiger TeamBackground Slides
The following slides are included as references and for quick access when/if needed
16
CDA R2 Definitions
• 4.2.2.1 – authenticator– Represents a participant who has attested to the
accuracy of the document, but who does not have privileges to legally authenticate the document. An example would be a resident physician who sees a patient and dictates a note, then later signs it.
• 4.2.2.8 – legalAuthenticator– Represents a participant who has legally
authenticated the document.
17
CDA R2 Definitions
• 4.2.2.2 – author– Represents the humans and/or machines that
authored the document.• 4.2.2.3 – custodian– Represents the organization that is in charge of
maintaining the document. The custodian is the steward that is entrusted with the care of the document. Every CDA document has exactly one custodian.
18
CDA R2 Definitions
• 4.2.2.6 – informant– An informant (or source of information) is a
person that provides relevant information, such as the parent of a comatose patient who describes the patient's behavior prior to the onset of coma.
Reference Choices
Related Provenance
21
Document contains excerpts of other documents
Document Informant: State HIE
Section Informant: Organization
overrides
Entry Informant: Sub-organization
overrides
Sub-organization of…
Document Author Device: Aggregation SoftwareRepresented organization
Section Author Device: Software
Represented organization Entry Author:
Aggregation Software
Represented organization
• One document that contains content from multiple related documents
Document Record Target: Patient identifiers by organization
Entry Record:Org-specific patient id
Assigning organization
Related Documents: Summary 1, Summary 2
Document Id: Summary HIE
Document contains excerpt s from other documents• One document that contains excerpts from multiple related documents
Related Documents: Summary 1, Summary 2, Summary 3, Summary 4
Summary 1: Allergies
Summary 2: Results
Summary 3: Results
Summary 4: Results
Related Docum
ents
Org A
Org B
Org C
Org D
Additional provenance template …• …to indicate the source of each external entry
Related Documents: Summary 1, Summary 2, Summary 3, Summary 4
Summary 1: Allergies
Summary 2: Results
Summary 3: Results
Summary 4: Results
Related Docum
ents
Org A
Reference/externalDocument
Summary 1: Allergy
Summary 1: Allergy
Reference/externalDocument
Reference/externalDocument
Reference/externalObservation
Reference/externalObservation
Representing Assembly Software in DPROV CDA
Requirement
• Need to convey that Assembly Software generated a CDA document
• Two Approaches:– Author ASSEMBLER– Participant ASSEMBLER
Document Author and Participant
Author ASSEMBLER
Header [1…*] Assigned Author Role:• Each Assigned Author played by [0…1] Person or Device • Scoped by [0…1] Organization• If no Authoring Device or Person, Author Entity can be
null• If Device is Assigned Author, then may be:
– Played by [0…*] MaintenanceEntity – Scoped by [1…1] Person
• Section [0…*]• Entry [0…*]
Participant ASSEMBLER
• Header [1…*] and Entry [0…*] participants• ParticipationType = DEV• ParticipationFunction = ASSEMBLER• Organization responsible for ASSEMBLER’s
participation
[0…1] Person is only choice of Participant Assigned Entity at Header • Can leave Null[0…1] Device with additional software information supported at Entry for Participant ASSEMBLER
Author ASSEMBLER
PRO
Author ASSEMBLER can be conveyed at Header/Section/Entry• Header ASSEMBLER Entity
conveys additional information about Software and who maintains it
• May be useful for determining:– Type of Assembly Software
Algorithm used– How it’s maintained – Organization responsible for
deploying the ASSEMBLER
CON
Author ASSEMBLER connotes that the ASSEMBLER is creating new info• Authors create new info (may be
a device)ASSEMBLER vs. “traditional” view of device participation• Does NOT create new
information, repackages existing content
What level of detail about ASSEMBLER need to be captured and communicated?
Participant ASSEMBLER
PRO
Participant ASSEMBLER can be conveyed at Header and /Entry• Does not misrepresent the
ASSEMBLER as an Author• Header Participant
ASSEMBLER may include Organization responsible for deploying the ASSEMBLER
CON
Participant ASSEMBLER can not be conveyed at Section Level• Cannot convey additional
information about the ASSEMBLER software algorithm or who maintains it
What needs to be conveyed about ASSEMBLER?
• Does it make sense to convey the Assembly Software at the section or entry?
• If ASSEMBLER generated a CDA Document, then ASSEMBLER also generated all contained sections and entries, even if those assembled into the Document were generated separately by same/different Assembly Software
• How critical is ASSEMBLER at Section Level if available at Entry Level?