Embed Size (px)
Citation preview
Data Provenance Community Meeting
July 31st, 2014
2
Meeting Etiquette
Click on the “chat” bubble at the top of the meeting window to
send a chat.
• 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).
3
Agenda
Topic Time Allotted
General Announcements 2 minutesUse Case Discussion 40 minutesTiger Team Report Out 5 minutesDPROV Initiative Process Review 10 minutesNext Steps/Questions 3 minutes
4
Next meetings:• HL7 DProv Joint Working Session: Cancelled• All Hands: Thursday August 7th, 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
General Announcements
5
S&I Framework Phases outlined for Data Provenance
Phase Planned Activities Pre-Discovery Development of Initiative Synopsis
Development of Initiative Charter Definition of Goals & Initiative Outcomes
Discovery Creation/Validation of Use Cases, User Stories & Functional Requirements Identification of interoperability gaps, barriers, obstacles and costs Review of Candidate Standards
Implementation 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
Pilot Validation of aligned specifications, testing tools, and reference implementation tools
Revision of documentation and toolsEvaluation 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
We are Here
6
Data Provenance –Use Case (Discovery)Ahsin Azim– Use Case Lead
Presha Patel – Use Case Lead
Proposed Use Case & Functional Requirements Development Timeline
7
Week Target Date (2014) All Hands WG Meeting Tasks Review & Comments from Community via Wiki page
due following Tuesday by 8 P.M. Eastern
1 6/12 Use Case Kick-Off & UC Process OverviewIntroduce: In/Out of Scope & Assumptions Review: In/Out of Scope & Assumptions
2 6/19 Review: In/Out of Scope & AssumptionsIntroduce: Context Diagram & User Stories Review: Context Diagram & User Stories
3 6/26 Review: Context Diagram & User Stories Review: Continue Review of User Stories
4 7/3 Review: Finalize User StoriesIntroduce: Pre/Post Conditions Review: Pre/Post Conditions
5 7/10 Review: Finalize User StoriesIntroduce: Pre/Post Conditions Review: Pre/Post Conditions
6 7/17 Review: Pre/Post ConditionsIntroduce: Actors & Roles, and Activity Diagram/Base Flow Review: Actors & Roles and Activity Diagram/Base Flow
7 7/31Review: Actors & Roles, and Activity Diagram/Base FlowIntroduce: Functional Requirements & Sequence Diagram Data Requirements
Review: Functional Requirements & Sequence Diagram, and Data Requirements
8 8/7Review: Functional Requirements , Sequence Diagram and Data RequirementsIntroduce: Risks & Issues
Review: Risks & Issues
9 8/14 Review: Risks and IssuesBegin End-to-End Review End-to-End Review by community
10 8/21 End-to-End Comments Review & disposition End-to-End Review ends
11 8/28 Finalize End-to-End Review Comments & Begin Consensus Begin casting consensus vote
12 9/4 Consensus Vote* Conclude consensus voting
Sections for Review
8
Today we will be reviewing: 1. Pre/Post Conditions
Introduce: 2. Actors & Roles3. Activity Diagrams 4. Base Flows
Double click the icon to open up the Word Document with the sections for review
Sections for Review
Draft Use Case Information Interchange per scenario
9
End Point (EHR)
Data Source(EHR, Lab,
Other)
Assembler(EHR, HIE, other
systems)
Data Source(EHR, Lab,
Other)
Transmitter ONLY(HIE, other systems)
Scenario 1
Scenario 2
Scenario 3Data Source(EHR, Lab,
Other)
Data Source(EHR, Lab,
Other)
Pre-step – Creation of the data and associated provenance information
Based on the Context Diagram, we can break up our workflows into 3 different scenarios:
1. Data Source End Point2. Data Source Transmitter End Point3. 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) 10
Scenarios
Scenario 1: Data Source End Point
User Story 1: A patient arrives at the ophthalmologist’s 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.
11
User Stories – Scenario 1
Scenario 2: Data Source Transmitter End Point
User Story 1 (no alteration in exchange): While training for a marathon, a patient fractures his foot. The patient’s PCP conducts a foot exam and captures all of the data from that visit in his EHR. The PCP also calls in a referral for the patient to an orthopedic specialist for further treatment. After the PCP calls in the referral, the summary of care information is made available to the specialist, by passing through a transmitter, 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 a transmitter.
12
User Stories – Scenario 2
Scenario 3: Data Source Assembler End PointNote: 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 wants to obtain the patient’s summary record as part of the delivery of 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 in a standard lab format 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 a referral to the specialist. The referral document includes relevant data originating in the PCP's EHR along with provenance information from Lab A that is transformed into a representation that is compatible with the referral document.
13
User Stories – Scenario 3
14
Scenario 3: Data Source Assembler End Point
User Story 3: A PCP tethered PHR enables patient to download and transmit Summary of Care records that includes provenance information 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 App in a mobile device friendly format using different terminology for expressing vital sign measures. The patient authorizes the Fitness Trainer App to access the patient’s information and put into a format that is recognizable by the Fitness Trainer App client. The Fitness Trainer App user (could be patient, physical therapist, etc.) receives provenance information showing that the information received has been assembled by the patient and that it was authored by various other clinical staff.
Alternative to User Story 3: Prior to visiting her ophthalmologist, a patient uploads clinical information into her PHR from several providers that she receives care from. She also enters information into the PHR on her health. The patient then sends a summary of care report from her PHR to her ophthalmologist which includes the self-reported data along with clinical data from her other providers. The ophthalmologist receives the report with provenance information and an indication that it was assembled by the PHR.
User Stories – Scenario 3 (cont.)
15
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
Pre/Post Conditions
16
A look ahead: Data Provenance Next Week
• August 7th, 2014 – All Hands Community Meeting (2:30-3:30)– Review Actors & Roles, Activity Diagrams and Base Flows
Provide your comments on the bottom of this page http://wiki.siframework.org/Data+Provenance+Use+Cases
17
HL7 DProv Joint Working SessionBob Yencha – Subject Matter Expert
Kathleen Connor – Subject Matter Expert
Ioana Singureanu – Subject Matter Expert
Neelima Chennamaraja – Subject Matter Expert
Johnathan Coleman- Initiative Coordinator
Tiger Team Report
• Created entry-level templates to provide complete coverage at all levels of CDA to the extent allowable by the base specification
• Updates to front matter based on community feedback
• On track for on-time submission to HL7
S&I Data Provenance InitiativePresentation to the Data Provenance Community
July 31st, 2014
Johnathan ColemanInitiative Coordinator – Data ProvenanceONC/OCPO/OST (CTR)
20
Challenge• While there are several existing efforts to address data
provenance, no authoritative specification, standard, or model for provenance has been universally adopted to-date within the context of HIT.
• The variability in how HIEs, EHRs, and PHRs currently capture, retain, and display provenance is problematic for the interoperable exchange, integration, and interpretation of health data.
Background
21
Initiative Purpose and Goals• To establish a standardized way for capturing, retaining, and
exchanging the provenance of health information (including inbound, system generated, and outbound provenance).
• The initiative will:– Establish guidance for handling data provenance in content
standards, including the level to which provenance should be applied
– Establish the minimum set of provenance data elements and vocabulary
– Standardize the provenance capabilities to enable interoperability
Background
22
Initiative Activities:S&I Framework
Phase Planned Activities Pre-Discovery Development of Initiative Synopsis
Development of Initiative Charter Definition of Goals & Initiative Outcomes
Discovery Creation/Validation of Use Cases, User Stories & Functional Requirements Identification of interoperability gaps, barriers, obstacles and costs Review of Candidate Standards
Implementation 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
Pilot Validation of aligned specifications, testing tools, and reference implementation tools
Revision of documentation and toolsEvaluation 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
We are Here
23
End Point (EHR)
Data Source(EHR, Lab,
Other)
Data Source(EHR, Lab,
Other)
Transmitter ONLY(HIE, other systems)
Scenario 1
Scenario 2
Scenario 3
Data Source(EHR, Lab,
Other)
Data Source(EHR, Lab,
Other)
Pre-step : Creation of the data and associated provenance information
Assembler(EHR, HIE, other
systems)
Initiative Activities:Use Case Scenarios (DRAFT)
24
Initiative Activities
Data Provenance Tiger Team • Established as a subgroup of the S&I Initiative.• Tasked with working with SDOs to accelerate the S&I Framework
harmonization phase by:– Evaluating current provenance requirements in CDA and
various HL7 specifications.– Supporting development of a harmonized Implementation
Guide (IG) for Provenance in a CDA.• Meets weekly as part of a joint S&I/HL7 working meeting.• Reports on progress to HL7 Community Based Collaborative Care
(CBCC) WG meetings and the S&I Data Provenance Initiative meetings.
25
Data Provenance Tiger Team Accomplishments:
• Proposed the Data Provenance project in HL7 and received approval from:– US Realm Task Force– Community Based Collaborative Care (CBCC) (sponsoring WG)– Structured Documents Work Group (SDWG) (co-sponsor)– Domain Experts Steering Division (DESD)– Technical Steering Committee (TSC)
• Supporting development of HL7 Provenance Specification:– HL7 Implementation Guide for CDA® Release 2: Data Provenance, Release 1 – Targeted for September 2014 ballot as DSTU – Working with other HL7 workgroups on vocabulary harmonization
Initiative Activities
26
Conclusion
Expected Outcomes:• Technical specifications which enable provenance information
to be conveyed in a standardized way, from creation to exchange and integration across multiple health information systems.
• Ultimately these standards will improve the confidence in the integrity of health information, facilitating greater trust in healthcare data and its use in clinical care, interventions, analysis, decision making and clinical research, and others.
Community Participation:• S&I Data Provenance Initiative: Thursdays 2:30-3:30 pm ET
– http://wiki.siframework.org/Data+Provenance+Initiative
• HL7/S&I D-PROV Working Sessions: Mondays 3:00-4:00pm ET– https://www3.gotomeeting.com/register/868770014
27
Support Team and QuestionsPlease feel free to reach out to any member of the Data Provenance
Support Team:• Initiative Coordinator: Johnathan Coleman: [email protected] • OCPO Sponsor: Julie Chua: [email protected] • OST Sponsor: Mera Choi: [email protected]• Subject Matter Experts: Kathleen Conner: [email protected] and Bob
Yencha: [email protected] • Support Team:
– Project Management: Jamie Parker: [email protected] – Use Case Development: Presha Patel: [email protected]
and Ahsin Azim: [email protected] – Harmonization: Rita Torkzadeh: [email protected] – Standards Development Support: Amanda Nash:
[email protected] – Support: Lynette Elliott: [email protected] and Apurva Dharia:
