data provenance community meeting june 19 th, 2014
TRANSCRIPT
Data Provenance Community Meeting
June 19th , 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.• 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 5 minutesTiger Team report out 5 minutesUse Case Discussion 45 minutesNext Steps/Questions 5 minutes
4
Next meetings:• Tiger Team: Monday June 23rd , 2014 3:00-4:00pm ET• All Hands: Thursday June 26th, 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 Tiger TeamBob 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 Out Items
• CBCC WG submitted 4 DPROV Project Initial Harmonization Proposals
• TT consensus on Assembly Software participation in CDA• Next TT modeling tasks for DPROV CDA IG Ballot• Call for ballot business guidance contributors
DPROV HL7 Harmonization Proposals
• HL7 CBCC WG submitted 4 initial Harmonization Proposals agreed to by ONC DPROV Initiative
• Posted on ONC DPROV TT page – CBCC ActRelationshipActProvenance value set– CBCC DPROV ParticipationFunction Codes– CBCC ProvenanceDocumentRelationship value set– CBCC ProvenanceEvent Value Set
• Next Steps:– Make any corrections specified by HL7 Vocabulary WG review– Consider DPROV and HL7 CBCC WG feedback on initial proposals– Submit approved final proposals by 07/06/2014– Prepare for Harmonization Conference Call Jul 15, 2014 to July 18, 2014
See HL7 Harmonization Meeting information page for more information
Tiger Team Modeling Activities
Tiger Team Modeling Question:How to convey that Assembly Software generated a CDA document• Two Approaches:– Author ASSEMBLER - (aka NY HIE approach) documented in
CDA Source of Information Guidance)– Participant ASSEMBLER – Proposed by TT Modeling Team
• TT reached consensus to approve Participant ASSEMBLER modeling approach– TT members provided additional rationale for why this is
correct path for the DPROV CDA IG
10
Assembled CDA DocumentsNY HIE Approach
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, auto-generated, from multiple organization and sub-organizations
Document Record Target: Patient identifiers by organization
Entry Record:Org-specific patient id
Assigning organization Secondary
identifier may be redundant
Primary identifier may be accompanied by secondary identifiers
11
Proposed Approach CDA Documents
Document Author/assignedAuthor/representedOrganization: State HIE
Entry Informant: Sub-organization
overrides
Sub-organization of…
Document Author/assignedAuthor/assignedPerson: nullflavor=NARepresented organization
Represented organization Entry Participation:
ASSEMBLER
• One document, auto-generated, from multiple organization and sub-organizations
Document Record Target: Patient identifiers by organization
Entry Record:Org-specific patient id
Assigning organization Secondary
identifier may be redundant
Document Participation/associatedEntity: ASSEMBLER
Document Participation/associatedEntity/scopingOrganization: State HIE
Scopting organization
Tiger Team Modeling Next Steps
DPROV Modeling Next Steps:• ProvenanceEvent(s)• Determining appropriate participations of Actor in or
contributions to CDA Entries (most granular portion of CDA, e.g., a Record Entry
• Specifying permissible relationships among Entries• Relating an Entry to its ProvenanceEvent(s)• Relating an Entry and associated ProvenanceEvents to
External Artifacts
13
Data Provenance –Use Case (Discovery)Ahsin Azim– Use Case Lead
Presha Patel – Use Case Lead
Proposed Use Case & Functional Requirements Development Timeline
14
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: Pre/Post ConditionsIntroduce: Activity Diagram & Base Flow Review: Activity Diagram & Base Flow
6 7/17 Review: Activity Diagram & Base Flow Introduce: Functional Requirements & Sequence Diagram Review: Functional Requirements & Sequence Diagram
7 7/24 Review: Functional Requirements & Sequence Diagram Introduce: Data Requirements Review: Data Requirements
8 7/31 Review: Finalize Data RequirementsIntroduce: Risks & Issues Review: Risks & Issues
9 8/7 Review: Risks and IssuesBegin End-to-End Review End-to-End Review by community
10 8/14 End-to-End Comments Review & disposition End-to-End Review ends
11 8/21 Finalize End-to-End Review Comments & Begin Consensus Begin casting consensus vote
12 8/28 Consensus Vote* Conclude consensus voting
Sections for Review
15
Today we will be reviewing: 1. In/Out Scope 2. Assumptions
Introduce: 3. Context Diagram4. Scenarios and User Stories5. Pre-Post Conditions (time
permitting)
Double click the icon to open up the Word Document with the sections for review
Microsoft Word Document
In Scope
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 16
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
**Leveraged from Charter
17
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
Draft Use Case Context Diagram
18
End Point (EHR)
Data Originator(EHR, Lab,
Other)
Data Originator(EHR, Lab,
Other)
Assembler(EHR, HIE, other
systems)
Data Originator(EHR, Lab,
Other)
Transmitter ONLY(HIE, other systems)
Scenario 1
Scenario 2
Scenario 3
Based on the Context Diagram, we can break up our workflows into four different scenarios:
1. Data Originator End Point2. Data Originator Transmitter End Point3. 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
19
Scenarios
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.
20
User Stories – Scenario 1
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.
21
User Stories – Scenario 2
Scenario 3: Data Originator 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 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.
22
User Stories – Scenario 3
23
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.
User Stories –Scenario 3 (Cont.)
24
Pre-Post Conditions (time permitting)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
25
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
26
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 Dahria: