Data Provenance Tiger Team June 16, 2014 Johnathan Coleman Johnathan Coleman - Initiative Coordinator Lynette ElliottLynette Elliott – Tiger Team Support Bob Yencha Bob Yencha – Subject Matter Expert Ioana Singureanu Ioana Singureanu – Modeling Facilitator Kathleen Connor Kathleen Connor – Subject Matter Expert Neelima ChennamarajaNeelima Chennamaraja - Modeling Facilitator

Agenda 2 Topic Time Allotted General Announcements1 minute HL7 Project Scope Statement Update, Timeline 1 minutes Task Activity50 minutes Next Steps/Wrap Up5 minutes

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). 3 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 ‘14Jul- Aug ‘14Sept- Oct ‘14Nov- Dec ‘14 Milestones HL7 Ballot (Aug 8- Sept 8) Data Provenance 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 DayDate Mon28-AprKick off Mon5-MayNo meeting - HL7 Mon12-May Set-up, begin analysis Model and example doc review, gather requirements & related materials for review Mon19-May Analysis Requirements review Tue27-May Analysis Address requirements Mon2-Jun Analysis Address requirements Mon9-JunHarmonization requests due Analysis HL7 Harmonization Committee Schedule: Initial Proposal Deadline: Sunday, June 15, 2014, Midnight Technical review: Tuesday or Wednesday June 17-18, 2014 Mon16-Jun Analysis Mon23-Jun Analysis Mon30-Jun Analysis Final Harmonization Proposal Deadline: Sunday, July 6, 2014, Midnight Harmonization Mtg: Tuesday through Friday, July 15-18, 2014 Mon7-JulAnalysis/review draft ballot Mon14-JulReview draft ballot Mon21-JulReview draft ballot Mon28-JulFinal ballot review and sign-offNext 3 days will be used to finalize pubs package Fri1-AugBallot 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 provider Represented organization legal Authenticator provider Represented organization author informant provider organization device provider organization device author informant provider organization 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

Data Provenance Tiger Team Next 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 3:00PM ET 13

Questions? 14

Data Provenance Tiger Team Background Slides The following slides are included as references and for quick access when/if needed

CDA R2 Definitions – 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 – legalAuthenticator – Represents a participant who has legally authenticated the document. 16

CDA R2 Definitions – author – Represents the humans and/or machines that authored the document – 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. 17

CDA R2 Definitions – 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. 18

Reference Choices

Related Provenance

Document contains excerpts of other documents 21 Document Informant: State HIE Section Informant: Organization overrides Entry Informant: Sub-organization overrides Sub-organization of… Document Author Device: Aggregation Software Represented 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 Documents 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 Documents Org A Reference/ externalDocument Summary 1: Allergy Reference/ externalDocument 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?