Data Provenance –Use Case (Discovery) Ahsin Azim– Use Case Lead Presha Patel – Use Case Lead

1. Data Provenance –Use Case (Discovery) Ahsin Azim– Use Case Lead Presha Patel – Use Case Lead

2. Proposed Use Case & Functional Requirements Development Timeline

3. Sections for Review Today we will be reviewing: In/Out Scope Assumptions Introduce: Context Diagram Scenarios and User Stories Pre-Post Conditions (time permitting) Double click the icon to open up the Word Document with the sections for review

4. In Scope Out of Scope • Patient identity matching*** • Third party mechanisms for checking patient consent and the relative merits of existing policies or regulations (such as privacy policies or jurisdictional considerations)*** • Policy-based decisions (such as records management based policies on record retention) • Non-clinical data (such as environmental data) • Mechanisms to verify the validity of the original source data  In Scope Items • To identify and define guidance on use of standards to facilitate provenance capabilities by specifying the following: *** • Standards for the provenance (e.g. origin, source, custodian(s), FHIR resources, CDA, etc.) • Supportive standards (e.g. integrity, non-repudiation, and privacy &security with respect to provenance ) • Vocabulary standard metadata tags for data provenance • Variance in granularity to which data provenance can be collected, the way it is encoded, and how that provenance is communicated to consuming systems • Define system requirements that allow applications to generate, persist and retrieve provenance data and maintain associations with the target record • Ensure sufficient granularity to support chain of custody **Leveraged from Charter

5. Assumptions • Clinical information that already exists within the EHR system (without the use of the CDA artifact) is found at the level appropriate for the implementation • The original sources (intent) are valid • Representation of the party providing information follows standards practices and is of high quality/integrity    

6. Draft Use Case Context Diagram End Point (EHR) Data Originator (EHR, Lab, Other) Scenario 1 Transmitter ONLY (HIE, other systems) Data Originator (EHR, Lab, Other) Scenario 2 Data Originator (EHR, Lab, Other) Assembler (EHR, HIE, other systems) Scenario 3

7. Scenarios Based on the Context Diagram, we can break up our workflows into four different scenarios: • Data Originator  End Point • Data Originator  Transmitter  End Point • Data Originator  Assembler End Point Draft Definitions: • Data Originator – 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

8. User Stories – Scenario 1 Scenario 1: Data Originator  End Point User Story 1: A patient is referred to an ophthalmologist by his primary care provider (PCP) for an eye exam. After the patient arrives at his office, the ophthalmologist conducts an eye exam and records all of the data 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.

9. User Stories – Scenario 2 Scenario 2: Data Originator  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.

10. User Stories – Scenario 3 Scenario 3: Data Originator  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.

11. User Stories –Scenario 3 (Cont.) Scenario 3: Data Originator  Assembler  End Point Use 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.

12. Pre-Post Conditions (time permitting) • 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 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

13. A look ahead: Data Provenance Next Week • June 23rd , 2014 – Tiger Team (3-4 pm ET) • June 26th , 2014 – All Hands Community Meeting (2:30-3:30) • Review draft Context Diagram, User Stories, Pre-Post conditions Provide your comments on the bottom of this page http://wiki.siframework.org/Data+Provenance+Use+Cases

14. 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: Presha Patel: presha.patel@accenture.comand 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