1

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

Presha Patel – Use Case Lead

ONC Standards and Interoperability (S&I) Framework LifecycleOur Missions» Promote a sustainable ecosystem that drives increasing interoperability and standards

adoption» Create a collaborative, coordinated, incremental standards process that is led by the industry

in solving real world problems» Leverage “government as a platform” – provide tools, coordination, and harmonization that

will support interested parties as they develop solutions to interoperability and standards adoption.

Tools and Services

Use Case Development

and Functional Requirements

Standards DevelopmentSupport

Certificationand Testing

Harmonization ofCore Concepts

Implementation Specifications

Pilot Demonstration Projects

Reference Implementation

Architecture Refinement and Management 2

3

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

Use Case Development Objectives

• Engage Stakeholders as Committed Members, Invite Experts, or Interested Parties in the creation of a Use Case This is you all!

• Identify Scenarios and User Stories that address real-world problems

• Keep it simple

• Focus on the business and functional requirements: Focus on “what” the requirements should be rather than “how”

• Create a finalized Use Case that demonstrates value and supports the proposed goals and success criteria for the Initiative

• Publish a finalized Use Case that contains necessary content, supported by artifacts, to enable Harmonization and subsequent S&I Framework efforts to occur

4

•1.0 Preface and Introduction

•2.0 Initiative Overview– 2.1 Initiative Challenge Statement**

•3.0 Use Case Scope– 3.1 Background**– 3.2 In Scope– 3.2 Out of Scope– 3.3 Communities of Interest

(Stakeholders)**

•4.0 Value Statement**

•5.0 Use Case Assumptions

•6.0 Pre-Conditions

•7.0 Post Conditions

•8.0 Actors and Roles

•9.0 Use Case Diagram

Use Case OutlineTailored for each Initiative

•10.0 Scenario: Workflow– 10.1 User Story 1, 2, x, …– 10.2 Activity Diagram

o 10.2.1 Base Flowo 10.2.2 Alternate Flow (if needed)

– 10.3 Functional Requirementso 10.3.1 Information Interchange

Requirementso 10.3.2 System Requirements

– 10.4 Sequence Diagram

•11.0 Dataset Requirements

•12.0 Risks, Issues and Obstacles

•Appendices

– Related Use Cases– Previous Work Efforts– References

** Leverage content from Charter5

Assumptions• Outlines what needs to be in place to meet or realize the requirements of the Use Case • These points are more functional in nature and state the broad overarching concepts

related to the Initiative• The Use Case assumptions will serve as a starting point for subsequent harmonization

activities

Pre Conditions• Describes the state of the system, from a technical perspective, that must be true before

an operation, process, activity or task can be executed• It lists what needs to be in place before executing the information exchange as described

by the Functional Requirements and Dataset requirements

Post Conditions• Describes the state of the system, from a technical perspective, that will result after the

execution of the operation, process activity or task

Review of Key Use Case SectionsAssumptions, Pre-conditions and Post-conditions

6

Review of Key Use Case SectionsUse Case Diagrams

• Conceptually represents the Business Actors interacting with the Use Case and the User Stories

• Provides a pictorial representation of the environment where the exchange takes place

• Characterizes the types of interactions that an actor has with a specific system

• Shows the association and interaction between the business actors and the Use Case

• It provides an overview of the actors (users or external systems) and the interactions between them

Example: Transitions of Care

7

Review of Key Use Case SectionsDefining the Actors

• This section of the Use Case outlines the business actors that are participants in the information exchange requirements for each scenario. A business actor is a person or organization that directly participates in a scenario.

• The business actor must use a system to perform the functions and to participate in the information interchange. The system or system actor has roles (send, receive, publish, subscribe or in some cases display) and actions which involve exchanging content. Please see the table below for an example of these designations.

Actor System Role

PCP EHR System Sender

Specialist EHR System Receiver

Patient PHR System Receiver

Example

8

Review of Key Use Case SectionsScenarios• The scenario is a comprehensive description of the actors, interactions, activities,

and requirements associated with the information exchange

• Scenarios pertain to supporting the health information exchange and describing key flows, and they are supplemented by User Stories

• Example: Specialist requests a patient’s Clinical Care Summary from Primary Care Provider (PCP)

Scenario 1

User Story 1 User Story 2

Scenario 2

User Story 1 User Story 2

9

Review of Key Use Case SectionsUser Story• User Stories describe the real world application as an example or instantiation of

the Scenario

• User Stories summarize the interaction between the actors of the Use Case, and specify what information is exchanged from a contextual perspective

• These interactions are further described in subsequent sections. Historically, user stories have been utilized to provide clinical context

• Example Scenario (from previous slide): Specialist requests a patient’s Clinical Care Summary from Primary Care Provider (PCP)

• Example User Story: A Specialist receives a referral and requires more information to treat the patient properly at the point of care. Using an EHR System, the Specialist sends a request to the PCP for the patient’s Clinical Care Summary. The PCP successfully receives the requests, understands the requests, and sends the patient’s Clinical Care Summary back to the Specialist via the EHR System. The Specialist successfully receives the patient information, understands it, and makes an informed decision that can provide better quality of care to the patient. 10

Review of Key Use Case SectionsActivity Diagram

• An Activity Diagram is a special form of a state transition diagram in which all or most of the states are activity states or action states

• The Activity Diagram illustrates the Use Case flows graphically, and represents the flow of events and information between the actors– It also displays the main events/actions

that are required for the data exchange and the role of each system in supporting the change

11

Review of Key Use Case SectionsFunctional Requirements• Functional Requirements identify the capabilities a system in a role must have in

order to enable interoperable exchange of the healthcare data of interest– They provide a detailed breakdown of the requirements in terms of the

intended functional behaviors of the application

• The Functional Requirements include:– Information Interchange Requirements– System Requirements

• The Information Interchange Requirements define the system’s name and role. They also specify the actions associated with the actual transport of content from the sending system to the receiving system

• System Requirements include the requirements internal to the system necessary to participate successfully in the transaction. System requirements may also detail a required workflow that is essential to the Use Case

12

• A Sequence Diagram is primarily used to show the interactions between objects in the sequential order that they occur– This representation can make it

easy to communicate how the exchange works by displaying how the different components interact

– The primary use of the diagram is in the transition from requirements expressed as use cases to the next and more formal level of refinement

• Note: Horizontal lines are used to identify the specific activity between the systems

Review of Key Use Case SectionsSequence Diagram

13

Dataset Requirements• Include the data elements and data element sets that will be available within the

message or document. Each data element included is necessary for some aspect of the Use Case; however, the requirements do not specify exactly how they may be used together. All data element sets may contain multiple data elements unless otherwise stated.

• The identification of data elements forms the foundation for harmonization activities. The data elements identified in the Use Case set constraints on the contents of documents and messages.

Issues Risks and Obstacles• Lists the concerns that might interfere with meeting the requirements of the Use

Case• Note: This list takes into consideration risks outlined in the Charter

Review of Key Use Case SectionsDataset Requirements & Issues, Risks & Obstacles

14

S&I Community Enabling Toolkit (CET)Use Case Overview

15

Proposed Use Case & Functional Requirements Development Timeline

16

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

In/Out Scope Items

17

In Scope

1. To identify and define guidance on use of standards to facilitate provenance capabilities by specifying the following: ***

1. Standards for the provenance (e.g. origin, source, custodian(s), FHIR resources, CDA, etc.)

2. Supportive standards (e.g. integrity, non-repudiation)3. Vocabulary standard metadata tags for data

provenance4. Variance in granularity to which data provenance can

be collected, the way it is encoded, and how that provenance is communicated to consuming systems

2. Define system requirements that allow applications to generate, persist and retrieve provenance data and maintain associations with the target record

3. Ensure sufficient granularity to support chain of custody

Out of Scope

1. Patient identity matching***2. Third party mechanisms for checking patient consent and the

relative merits of existing policies or regulations (such as privacy policies or jurisdictional considerations)***

3. Policy-based decisions (such as records management based policies on record retention)

4. Non-clinical data (such as environmental data)

*** Leveraged from Charter

Assumptions

18

1. 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

Draft Use Case Context Diagram

19

End Point (EHR)

True Source(EHR)

True Source(Lab)

Aggregator(EHR, HIE, other

systems)

True Source(Other)

20

A look ahead: Data Provenance Next Week

• June 16th , 2014 – Tiger Team (3-4 pm ET)• June 19th , 2014 – All Hands Community Meeting (2:30-

3:30)– Review In/Out Scope and Assumptions

21

Support Team and QuestionsPlease 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.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