July 3 rd , 2014

• 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.
• Please announce your name before speaking • 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.
2

Topic
General Announcements Tiger Team report out Use Case Discussion Next Steps/Questions
Time Allotted
5 minutes 5 minutes 45 minutes 5 minutes 3

Next meetings: • HL7 DProv Joint Working Session: Monday July 7 th 4:00pm ET , 2014 3:00 – New meeting information • All Hands: Thursday July 10 th , 2014 – 2:30-3:30 pm ET • http://wiki.siframework.org/Data+Provenance+Initiative • All meeting materials (including this presentation) can be found on the Past Meetings page: • http://wiki.siframework.org/Data+Provenance+Past+Meetings 4

(aka DProv Tiger Team Meeting)
5

Phase Pre-Discovery Discovery We are Here Implementation Pilot Evaluation
        
Planned Activities
 Development of Initiative Synopsis Development of Initiative Charter Definition of Goals & Initiative Outcomes Creation/Validation of Use Cases, User Stories & Functional Requirements Identification of interoperability gaps, barriers, obstacles and costs Review of Candidate Standards Creation of aligned specification  Documentation of relevant specifications and reference implementations  such as guides, design documents, etc.
Development of testing tools and reference implementation tools   Validation of aligned specifications, testing tools, and reference implementation tools Revision of documentation and tools Measurement of initiative success against goals and outcomes Identification of best practices and lessons learned from pilots for wider scale deployment Identification of hard and soft policy tools that could be considered for wider scale deployments 6

Bob Yencha – Subject Matter Expert Kathleen Connor – Subject Matter Expert Ioana Singureanu – Subject Matter Expert Neelima Chennamaraja – Subject Matter Expert Johnathan Coleman- Initiative Coordinator
7

A. Provider/Patient Authored document with & without externally sourced sections and entries compiled by ASSEMBLER B. Device authored document with & without externally sourced sections and entries compiled by ASSEMBLER C. HIE scoped document author [person & device not specified] with ASSEMBLER compiling the document – All contents are externally sourced composed by other authors and/or compiled by ASSEMBLERs

• Ensure that Scenario A covers any person including patients as an author – Noting requirements that arise from that distinction • Further discussion on using document participant to convey use of ASSEMBLER software • Discussed how document author inheritance propagates and implications of the ASSEMBLER participant • Conformance for overriding document authors and their scoping organizations at all levels

• HL7 CBCC agreed to co-sponsor the tiger team work now that NIB has cleared all approvals • Provides additional time on Tuesday HL7 CBCC WG call for discussion and intersection with other HL7 activities and projects • No change to Monday meeting time but will have new logistics (in process – watch the S&I TT wiki and the HL7 CBCC listserve) • CBCC WG meetings are every Tuesday, 1PM ET – http://www.hl7.org/concalls/Default.aspx

• Most current document is always avail: – http://gforge.hl7.org/gf/project/cbcc/frs/?action= FrsReleaseBrowse&frs_package_id=240 • Call for content contributors to the ballot document – Can be supplied as bullet points for each section in the ToC in draft IG – Please review the posted document and provide feedback and comments

Ahsin Azim– Use Case Lead Presha Patel – Use Case Lead
12

Week
1 2 3 4 5 6 7 8 9 10 11 12
Target Date (2014)
6/12 6/19 6/26 7/3 7/10 7/17 7/24 7/31 8/7 8/14 8/21 8/28
All Hands WG Meeting Tasks
Use Case Kick-Off & UC Process Overview Introduce: In/Out of Scope & Assumptions Review: In/Out of Scope & Assumptions Introduce: Context Diagram & User Stories Review: Context Diagram & User Stories Review: Finalize User Stories Introduce: Pre/Post Conditions Review: Pre/Post Conditions Introduce: Activity Diagram & Base Flow Review: Activity Diagram & Base Flow Introduce: Functional Requirements & Sequence Diagram Review: Functional Requirements & Sequence Diagram Introduce: Data Requirements Review: Finalize Data Requirements Introduce: Risks & Issues Review: Risks and Issues Begin End-to-End Review End-to-End Comments Review & disposition Finalize End-to-End Review Comments & Begin Consensus Consensus Vote*
Review & Comments from Community via Wiki page due following Tuesday by 8 P.M. Eastern
Review: In/Out of Scope & Assumptions Review: Context Diagram & User Stories Review: Continue Review of User Stories Review: Pre/Post Conditions Review: Activity Diagram & Base Flow Review: Functional Requirements & Sequence Diagram Review: Data Requirements Review: Risks & Issues End-to-End Review by community End-to-End Review ends Begin casting consensus vote Conclude consensus voting 13

Today we will be reviewing:
1. Scenarios 2 and 3 along with accompanying User Stories
Introduce:
1. Pre/Post Conditions (time permitting) Double click the icon to open up the Word Document with the sections for review 14

Draft Use Case Information Interchange per scenario
Pre-step – Creation of the data and associated provenance information
Data Source (EHR, Lab, Other) Scenario 1 Data Source (EHR, Lab, Other) Scenario 2 Transmitter ONLY (HIE, other systems) End Point (EHR) Data Source (EHR, Lab, Other) Scenario 3 Data Source (EHR, Lab, Other) Assembler (EHR, HIE, other systems) 15

Based on the Context Diagram, we can break up our workflows into 3 different scenarios: 1. Data Source End Point 2. Data Source Transmitter  End Point 3. Data Source Assembler End Point Note – For each of the above, there is a pre-step associated with creation of the data and associated provenance information • • • • • Draft Definitions: Data Source – Health IT System where data is created (the true source) Transmitter – A system that serves as a pass through connecting two or more systems Assembler– A system that extracts, composes and transforms data from different patient records End Point – System that receives the data Note: In this context, when say data we are referring to an atomic data element (a piece of information) 16

Scenario 1: Data Source End Point User Story 1: A patient arrives at the ophthalmologists office for her annual eye exam. The ophthalmologist conducts an eye exam and captures all of the data from that visit in his EHR. The ophthalmologist electronically sends the information back to the patient’s PCP (where all data in the report sent was created by the ophthalmologist). User Story 2: A patient wishes to transmit the Summary of Care Document she downloaded from her PCP to her Specialist. Rather than downloading and sending it herself, she requests that the PCP transmits a copy of the document on her behalf to her Specialist. PCP is the only author of the Summary of Care Document and also the sender of the information to the Specialist. The Specialist understands from the document’s provenance that it is authentic, reliable, and trustworthy. Note: Provenance for the request made to the PCP is not in scope for this user story. 17

Scenario 2: Data Source  Transmitter  End Point User Story 1: While training for a marathon, a patient fractures his foot. The patient’s PCP refers the patient to an orthopedic specialist for treatment. After the PCP electronically sends the referral, the information is passed through an HIE, before being received by the orthopedic specialist’s system. The orthopedic specialist receives the summary of care with provenance information and an indication that the data passed through an HIE. 18

Scenario 3: Data Source  Assembler  End Point Note: A community of providers have established a data use agreement that allows
them to upload data to an HIE repository. When data is sent to the repository, the provenance information is also included.
User Story 1: A patient is rushed to the Emergency Department due to a car accident. The physician on hand wants to obtain the patient’s summary record before administering care. The physician queries the HIE repository and receives a summary record from the past six months. The data received includes the provenance information from the originating sources and also information that identifies the assembler and the actions they have taken. User Story 2: A patient with diabetes goes to Lab A to have his blood drawn. Lab A sends the lab results to the PCP’s EHR with provenance information attached. Upon reviewing the lab results, the PCP decides to refer the diabetic patient to a specialist for consultation. The PCP electronically sends the referral to the specialist with the lab results from Lab A along with relevant data originating in the PCP’s own EHR. 19

Scenario 3: Data Source  Assembler  End Point User Story 3: A PCP tethered PHR enables patient to download and transmit Summary of Care records to anyone she chooses. Patient downloads full Summary of Care Document, disaggregates the medications, problems, and vital signs in the document and then copies these into her PHR along with medications, problems and vital signs added previously. Patient then sends selected medications, vitals, and problems from PHR to her Fitness Trainer. The Fitness Trainer understands that the information received has been assembled by the patient and that it was authored by various other clinical staff. 20

• • •
Preconditions
Where it exists, the assembling software, is integrated into systems such as EHRs, PHRs, and HIEs – indicating the type of information for a receiver to use as provenance for calculating reliability, and the organization or person responsible for deploying it There exists an Access Control System that allow the assembler to perform necessary tasks for predecessor artifacts and newly assembled artifacts All systems generating or consuming any artifact are capable of persisting the security labels received and data segmentation based the security labels assigned by the artifact generator, which may be an assembler
Post Conditions
• Receiving system has incorporated provenance information into its system and association of the provenance information to the source data is persisted • Sending and receiving systems have recorded the transactions in their security audit records 21

• July 7 th , 2014 - HL7 DProv Joint Working Session(3:00-4:00pm) • July 10 th , 2014 – All Hands Community Meeting (2:30-3:30pm) – Review Pre/Post conditions Provide your comments on the bottom of this page http://wiki.siframework.org/Data+Provenance+Use+Cases 22

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
Yencha: bobyencha@maine.rr.com
and Bob • Support Team: – Project Management: Jamie Parker: jamie.parker@esacinc.com
– Use Case Development: Presha Patel: presha.patel@accenture.com
and Ahsin Azim: ahsin.azim@accenturefederal.com
– Harmonization: Rita Torkzadeh: rtorkzadeh@jbsinternational.com
– Standards Development Support: Amanda Nash: amanda.j.nash@accenturefederal.com
– Support: Lynette Elliott : lynette.elliott@esacinc.com
Dharia: apurva.dharia@esacinc.com
and Apurva 23