Data Access Framework (DAF) All Community

Meeting August 14th, 2013

Meeting Etiquette• Remember: If you are not speaking keep your

phone on mute• Do not put your phone on hold – if you need to

take a call, hang up and dial in again when finished with your other call– Hold = Elevator Music = very frustrated speakers and

participants

• This meeting, like all of our meeting is being recorded– Another reason to keep your phone on mute when not

speaking

• Feel free to use the “Chat” feature for questions, comments or any items you would like the moderator or participants to know.

NOTE: This meeting is being recorded and will be posted on the Meeting Minutes Wiki page after

the meeting

From S&I Framework to Participants:Hi everyone: remember to keep your phone on mute

2

Agenda

Topic Time Allotted

General Announcements 5 minutes

Review of DAF Project Charter Comments and Dispositions 25 Minutes

Review of the Consensus Process (for Project Charter) 5 minutes

Introduction to Use Case Development 20 minutes

Next Steps/Questions 5 Minutes

3

General Announcements• We will begin the Consensus process of the

DAF Project Charter August 14th

– Consensus opens August 14th and will close at 8 pm ET August 22nd

• The Data Access Framework (DAF) All Hands Community meets every Wednesday from 12:00-1:00 PM EDT– To participate please see the “Weekly Meetings”

Section of the DAF Wiki Homepage:http://wiki.siframework.org/Data+Access+Framework+Homepage

Note: Please check the meeting schedule weekly to get the most up-to-date meeting information

4

Join the Initiative • We encourage all

members to “sign up” or join the initiative. By joining this ensures you stay up-to-date with the work being done, communications and any initiative activities.

• Simply complete the Join Form on the Join Wiki Page: http://wiki.siframework.org/Data+Access+Framework+Join+the+Initiative

5

S&I Framework Phases & Data Access Framework Activities

6

We are Here

Notional Project Timeline

Kick-off (7/16)Pre-Discovery,

Call for Participation

Jan 2014

Nov

Discovery

S&I Lifecycle(Discovery Pilot & Evaluation)

7

July 2013 Sept

Implementation

Define Use Case & Functional Requirements

Standards Gap Analysis Harmonized Specifications

Technology Evaluations

Technical Project Outline (11/14)

Use Case 1 Consented 10/29

UC

1:

Lo

cal

Dat

a A

cces

s:

Intr

a-O

rgan

izat

ion

al

Qu

ery

UC

2:

Targ

eted

D

ata

Acc

ess:

In

ter-

Org

aniz

atio

nal

Qu

ery

Discovery

Define Use Case & Functional Requirements

Implementation

Standards Gap Analysis

Use Case 2 Consented 11/29

Charter Review & Consensus

Today 8/14

7

Review of Project Charter

• Real time review of the Project Charter Comments– Discuss comments and proposed Dispositions– Make all updates based on comments– Update charter for Consensus

• TIMELINE FOR CHARTER REVIEW:– July 31st Call – Detailed Community Review (includes discussion and reading of

entire charter)– August 7th – Disposition of All Comments made during meeting on Project

Charter– August 8th – Project Charter goes for end-to-end review and comment– August 12th – end-to-end review closes– August 14th – All end-to-end comments deposed and shared with

community during 1st half of community call– August 14th – Consensus voting on Project Charter opens– August 22nd – Consensus voting ends– August 28th – Consensus reached and all votes and comments incorporated

into the FINAL PROJECT CHARTER 8

Terminology…• Data Access Mechanisms: Data Access mechanism refers to how the data is

accessed. This is commonly done via queries which conform to various query structures. Data Access mechanisms do not indicate the structure of the query results, however the DAF initiative will specify standards for query results. Examples of Data Access mechanisms include Document based access, Data Element based access, Quality Measure based access.

– Document Based Access: Document based access is used to access information about patients or populations based on the following:

• Type of the document such as (C-CDA, QRDA, LabReport etc)• Metadata such as time of creation, modification etc.• Practice type, Authors• Patient Id, Document Id, • Other ebRS/ebRIM based Queries as in ITI TF: 2a : 3.18.4.1.2.3.7

Note: In Document based access, the content within a document such as C-CDA, QRDA, LabReport etc. is not used to formulate the query, but other metadata about the document such as authors, timestamps etc. are used to retrieve the information.

Terminology…

• Data Element Based Access: Data element based access is used to access information about patients or populations using information that is part of the clinical records such as

– Patient Demographics– Lab Results– Medications, Immunizations, Problems etc.

• Quality Measure Based Access: Quality Measure based access is used to access patient or population level information using quality measures.

10

Note: In Data Element based access the queries will be structured to express criteria that will be used to filter information present within a HealthIT system and return appropriate query results.

Terminology continued

• Granularity of Data being accessed: The information that is retrieved by the Data Access Framework will be called as Query Results. The granularity of query results can be Patient Level or Population Level. The Query Results will use existing standards as necessary to return the requested information.

– Patient Level Data: When the granularity of data access is “Patient Level Data”, the HealthIT systems responding to the queries are expected to return information for each patient(s) that meets the query criteria. For example,

• If the query is about a single patient, the query results will be specific to the identified patient.

• In the case where the query identifies generic criteria such as “age > 50 and HbA1c >7%”, the query results should contain discrete information for each patient who meets the specified criteria.

• Standards such as C-CDA, FHIR, QRDA Category I, HL7 v2.5.1 are used to encode individual patient level data.

– Population Level Data: When the granularity of data access is “Population Level Data”, the HealthIT systems responding to the queries are expected to return information for the population that meets the criteria. Population information could be

• Number of patients that meet a criteria.• Percentage of Patients that meet a criteria.• De-identified Patient List Report (Patient List Report is essentially a list of patients)• Standards such as QRDA Category III Report and conceptual QRDA Category II

Report are used to encode population level data.

Consensus on the Implementation Guide

• For those of you who are committed members, we ask you to vote on the Data Access Framework Charter:– Yes

• A Yes vote does not necessarily mean that the deliverable is the ideal one from the perspective of the Initiative Member, but that it is better to move forward than to block the deliverable

– Yes with comments• If a Consensus Process attracts significant comments (through Yes with comment

votes), it is expected that the comments be addressed in a future revision of the deliverable.

– Formal Objection- with comments indicating a path to address the objection in a way that meets the known concerns of other members of the Community of Interest. "Formal Objection" vote without such comments will be considered Abstain votes.

• A Formal Objection means that the objector cannot proceed with the project unless the objections are met. It is acceptable and expected to use a Formal Objection in a first consensus round to communicate a point of view or process issue that has not been addressed in the drafting of the initial deliverable.

• Should a Consensus Process attract even one "Formal Objection" vote with comments from an Initiative Member, the deliverable must be revised to address the "Formal Objection" vote (unless an exceptional process is declared).

– Abstain (decline to vote)

Note: Each Organization, no matter the number of Committed Members only receives 1 Vote. If there are multiple committed members from your organization please verify your collective vote with them

Verifying your Commitment Level• To verify you are a

committed member go to the Members section of the DAF wiki page: http://wiki.siframework.org/Data+Access+Framework+Charter+and+Members#members

• Search for your name• Verify your “Role”• If you want to be a committed

member and see that you are not please re-join or re sign up for the initiative indicating your new role http://wiki.siframework.org/Data+Access+Framework+Join+the+Initiative

13

Submitting your Vote

1. Review the Data Access Framework

Charter (either using the attached word

document or reading the Wiki – both

contain the same information)

http://wiki.siframework.org/Data+Access+Framework+Charter+and+Members

2. Complete the Voting Form:– NOTE: You must be a Committed

Member to Vote• Yes• Yes with comments.• Formal Objection• Abstain (decline to vote)

3. Submit your Vote

4. A Message is displayed verifying your vote was recorded

14

2

3

4

Project Charter Section

To participate in the Consensus for Data Access Framework please do the following:1

Data Access Framework (DAF)Use Case Kickoff

August 14, 2013

15

Today’s Agenda:

16

Discussion Topic Estimated Time

Use Case Development Objectives & Process Overview

5 Minutes

Use Case Terminology, Sections Review and Approach

5 Minutes

Proposed Use Case & Functional Requirements Development Timeline

2 Minutes

Local Data Access Scenario & Context Diagram 3 Minutes

Review and Discussion• In and Out of Scope Items• Assumptions

14 Minutes

Next Steps 1 Minute

Develop Content

Validate Content

1. Use case value statement, initiative/scope 2. Develop scenarios/user stories3. Define actors and roles4. Identify assumptions, pre-conditions and post conditions5. Develop use case diagrams6. Develop functional requirements (information interchange and system requirements) 7. Develop dataset requirements 8. Consensus

Use Case Development Process

1. Use case value

statement, initiative/use

case scope

2. Develop Scenarios/

User stories

3. Define Actors and

Roles

4. Identify Assumptions,

Pre-Conditions and Post

Conditions

5. Develop Use Case Diagrams

6. Develop Functional

Requirements

7. Develop Dataset

Requirements8. Consensus

17

Definitions:Use Case, Scenarios, and User Stories

18

Use Case

User Story 1

(Supplement to Scenario)

Scenario 1 Scenario 2The Scenario is a comprehensive description of the actors, interactions, activities, and requirements associated with the information exchange.

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

The Use Case is the foundation for identifying and specifying the standards required to support the data exchange, reference implementations and tools to ensure consistent and reliable adoption of the data exchange standards

User Story 2

(Supplement to Scenario)

User Story 1

(Supplement to Scenario)

User Story 2

(Supplement to Scenario)

Review of Key Use Case SectionsUse Case Diagram, Actors & Roles

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

– These diagrams characterize 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

Actors & Roles• 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. Thus, as a person or organization, the actor can (and should) be a stakeholder.

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

19

Actor System Role

Information Requestor Health IT System Requests access to patient dataReceives patient data

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

– An action state represents the fulfillment of associated responsibilities in response to the communication received from the previous step

– Most transitions are triggered by completion of activities in the source 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

20

Review of Key Use Case SectionsSequence Diagram

• 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

21

Review of Key Use Case SectionsFunctional Requirements & Dataset 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

– 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

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

22

Week TargetDate All Hands WG Meeting Tasks Review & Comments

due Monday COB

1 8/14 Use Case Kick-Off & UC Process OverviewIntroduce: In/Out of Scope, Assumptions

Review: In/Out of Scope, Context Diagram, Assumptions

2 8/21 User Stories, Pre/Post Conditions

Finalize: In/Out of Scope Context Diagram, Assumptions

Draft: User StoriesReview: Actors & Roles, Pre/Post Conditions

3 8/28 User Stories, Actors & Roles Review: User StoriesFinalize: Actors/Roles, Pre/Post Conditions Review: User Stories

4 9/4 Base Flow, Activity Diagram Finalize: User Stories Review: Base Flow, Activity Diagram

5 9/11 Functional Requirements Finalize: Base Flow, Activity Diagram Review: Functional Requirements

6 9/18 Functional Requirements,Sequence Diagram

Review: Functional Requirements, Sequence Diagram

Review: Functional Requirements, Sequence Diagram

7 9/25 Data Requirements Finalize: Functional Requirements, Sequence Diagram Review: Data Requirements

8 10/2 Data Requirements Finalize: Data Requirements Review: Data Requirements

9 10/9 Full Review & Finalize Data Requirements End-to-End Review (10/9-10/16)

10 10/16 End-to-End Review (10/9-10/16) End-to-End Review comments due 10/15

11 10/23 Consensus Review (10/17-10/22) Cast consensus vote

FINAL CONSENSUS (10/23)

Proposed Use Case & Functional Requirements Development Timeline

23

Data AccessFramework

Local Access viaIntra-Organization Query

Targeted Access viaInter-Organization Query

Multiple Data Source Access via Distributed Query (Query Health) –

Completed Initiative

Standards based approach to enable access at all levels: Local, Targeted, and Distributed

• Create and disseminate queries internal to organization

• Query Structure Layer • APIs

• Receive standardized responses• Query Results Layer

• Create and disseminate queries to external organization

• Query Structure Layer • Transport Layer• Authentication/Authorization Layer

• Receive standardized responses from external orgs• Query Results Layer

• Create and disseminate queries to multiple orgsGoverned by a network

• Receive aggregated or de-identified responses

• Focus on Information Model for the network and leverage standards from earlier phases.

DataSource

DataSource

DataSource

Query Request

Query Response

X Hospital System X Hospital System

Y Hospital System

24

DAF Scope – Current focus: Local Data Access

Organization Entity A

Sends: Data Query

Receives: Patient(s) Data or Document

Information Requester

Health IT System

Scenario Example: Information Requester sends a data query to his/her the Health IT system requesting data about one or more patient(s). The data requested can be document based access, which means obtaining/returning information based on the document type, date of creation etc. The data requested can also be based on a specific criteria (i.e. data element) for example patient demographics or clinical condition. The Internal Information System returns the requested patient data or document to the Information Requester.

Note: Detailed user stories describing real world examples will be presented in future meetings

DAF - Local Data Access Workstream via Intra-Organizational Query

25

Use Case 1 - Local Data Accessvia Intra-Organizational Query

In Scope Items

1. Defining requirements for providers, healthcare professionals etc. to internally be able to access already documented patient data from previous encounters, admissions, or visits.

2. Document Based Access: Accessing data for one or more patients based on the document metadata such as document type, date/time of creation, author, etc.

3. Data Element Based Access: Accessing data for one or more patients based on a specific data element values such as patient demographics, clinical conditions, etc.

4. Quality Measure Based Access: Accessing data for one or more patients data using quality measures.

5. Define requirements for standardized API’s that allow applications to access data in a consistent manner across EHRs

26

Out of Scope Items

1. Defining policy and procedure considerations that allow data access queries to be executed within an organization.

2. Defining retrieval of information stored in databases or other applications not directly linked to the organization’s Health IT system.

3. Accessing data from systems outside of the organization (legal entity).

4. Patient generated queries and access are out of scope (addressed within BlueButton Initiative).

5. Displaying, consumption, and processing of results by the receiving system is out of scope.

6. Capabilities identified in the project charter as being out of scope (for e.g query execution policies, patient matching algorithms, new information models, discovery of query service end points).

27

Assumptions

1. An organization refers to a legal entity which can have any number of sub-entities within the organization.

2. The necessary access controls and authorization protocols (including patient consent and permissions), and audits for any of the systems or users described, are in place. Appropriate data segmentation and de-identification protocols are in place, as needed.

3. An organization’s Health IT system is comprised of any and all IT systems (i.e. varying EHR systems or other Health IT systems such as Pharmacy and Lab).

4. Defining methods of data access for a single query among various systems within the same organization will be determined by the organization

5. Information requester knows how to access data from their Health IT system.

6. All actors and systems shall ensure all transactions will be delivered in a timely manner

28

Next Steps• Review content & submit comments by Monday 08/19 COB

In & Out of Scope Assumptions Wiki link to be updated with materials after today’s call: http://

wiki.siframework.org/Use+Case+1+Local+Data+Access

• Attend our next session on Wednesday 08/21 at 12:00 PM EST to discuss... User Stories Defining Pre and Post Conditions

29

Next Steps

• Vote (Consensus) on the Project Charter– http://wiki.siframework.org/Data+Access+Framework+Charter

+and+Members

– Consensus is open to Committed Members will close at 8 pm ET August 22nd

• Review content & submit comments by Monday 08/19 COB– In & Out of Scope – Assumptions– Wiki link to be updated with materials after today’s call:

http://wiki.siframework.org/Use+Case+1+Local+Data+Access

• Attend our next session on Wednesday 08/21 at 12:00 PM EST to discuss...– User Stories– Defining Pre and Post Conditions

30

Initiative Support Leads

• For questions, please feel free to contact your support leads:

– Initiative Coordinator: John Feikema john.feikema@siframework.org– ONC Sponsors: Mera Choi mera.choi@hhs.gov– Support Team:

• Project Management: – Jamie Parker jamie.parker@esacinc.com

• Technical Support: – Dragon (Nagesh) Bashyam nagesh.bashyam@drajer.com

• Use Case Development: – Presha Patel presha.patel@accenture.com

• Vocabulary and Terminology Subject Matter Expert: – Mark Roche mrochemd@gmail.com

• Project Support– Gayathri Jayawardena gayathri.jayawardena@esacinc.com

31

Questions

32

Data Access Framework (DAF) Resources• DAF Wiki Homepage

– http://wiki.siframework.org/Data+Access+Framework+Homepage

• Become a Community Member– http://

wiki.siframework.org/Data+Access+Framework+Join+the+Initiative

• DAF Charter– http://

wiki.siframework.org/Data+Access+Framework+Charter+and+Members

• Standards and Interoperability(S&I) Framework– http://wiki.siframework.org/Introduction+and+Overview

• S & I Calendar of Events– http://wiki.siframework.org/Calendar

33

Appendix A: Access Level Table Diagram (updated 8-13-13)

34

Data Access Mechanism (Query) Formats

Document based access Data element based access

Data Access using quality measures

Granularity of Data being accessed(Query Results)

Patient Level Data Get me the latest C-CDA or lab report for a patient so that I can check if their HbA1c > 7%.

Retrieve lab reports for a patient for the past year where HbA1c > 7%.

Use Quality Measure such as NQF59 to retrieve patient data for diabetic patients with HbA1c > 7%.

Population Level Data

Retrieve population level information about patients who had a surgical procedure within the last 3 days to prepare for their care transition. Note: Surgical procedures are documented using Operative Notes.

Retrieve population level information about patients with age >=65 and HbA1c >7% stratified by ethnicity and preferred language to determine care planning needs for the population.

Use Quality Measure such as NQF59 to retrieve population level information about diabetic patients with HbA1c > 7%.

35

Appendix B: Additional Use Case Reference Material

36

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

37

Some Previous and Ongoing S&I Use Cases (not a complete list)

38

Use Case Name (including links) StatusData Access Framework In ProgressTransitions of Care CompleteLab Results Interface CompleteProvider Directory - Certificate Discovery CompleteProvider Directory - Electronic Service Information Discovery CompleteQuery Health CompleteData Segmentation for Privacy CompleteesMD - PPA Provider Registration (UC 1) CompleteesMD - Secure sending and Structure of eMDR (UC 2) CompleteesMD - Author of Record Level 1 CompleteLab Orders Interface CompleteLab Orders Interface - eDOS CompleteHealth eDecisions CDS Artifact Sharing UC 1 CompleteHealth eDecisions CDS Guidance Service UC 2 CompleteStructured Data Capture CompleteLongitudinal Coordination of Care CompletePublic Health Reporting CompleteAutomate Blue Button Initiative CompletePrescription Drug Monitoring Program CompleteesMD – Author of Record Level 2 Complete