1. Data Access Framework (DAF) All Community Meeting August 14th, 2013

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

3. Agenda TopicTime Allotted General Announcements5 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 Development20 minutes Next Steps/Questions5 Minutes 3

4. General Announcements We will begin the Consensus process of the DAF Project Charter August 14 th – Consensus opens August 14 th and will close at 8 pm ET August 22 nd 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+Ho mepage http://wiki.siframework.org/Data+Access+Framework+Ho mepage Note: Please check the meeting schedule weekly to get the most up-to-date meeting information 4

5. 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+Fra mework+Join+the+Initi ative http://wiki.siframework. org/Data+Access+Fra mework+Join+the+Initi ative 5

6. S&I Framework Phases & Data Access Framework Activities 6 We are Here

7. Notional Project Timeline Kick-off (7/16) Pre-Discovery, Call for Participation Jan 2014 Nov Discovery S&I Lifecycle (Discovery  Pilot & Evaluation) 7 July 2013Sept 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: Local Data Access : Intra- Organizational Query UC 2: Targeted Data Access : Inter- Organizational Query Discovery Define Use Case & Functional Requirements Implementation Standards Gap Analysis Use Case 2 Consented 11/29 Charter Review & Consensus Today 8/14 7

8. 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 31 st Call – Detailed Community Review (includes discussion and reading of entire charter) –August 7 th – Disposition of All Comments made during meeting on Project Charter –August 8 th – Project Charter goes for end-to-end review and comment –August 12 th – end-to-end review closes –August 14 th – All end-to-end comments deposed and shared with community during 1 st half of community call –August 14 th – Consensus voting on Project Charter opens –August 22 nd – Consensus voting ends –August 28 th – Consensus reached and all votes and comments incorporated into the FINAL PROJECT CHARTER 8

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

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

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

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

13. 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/D ata+Access+Framework+Cha rter+and+Members#members http://wiki.siframework.org/D ata+Access+Framework+Cha rter+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/D ata+Access+Framework+Join +the+Initiative http://wiki.siframework.org/D ata+Access+Framework+Join +the+Initiative 13

14. 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+Me mbers 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 2 3 3 4 4 Project Charter Section To participate in the Consensus for Data Access Framework please do the following : 1 1

15. Data Access Framework (DAF) Use Case Kickoff August 14, 2013 15

16. Today’s Agenda : 16 Discussion TopicEstimated 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 Diagram3 Minutes Review and Discussion In and Out of Scope Items Assumptions 14 Minutes Next Steps1 Minute

17. Develop Content Validate Content 1.Use case value statement, initiative/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 (information interchange and system requirements) 7.Develop dataset requirements 8.Consensus 1.Use case value statement, initiative/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 (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 Requirements 8. Consensus 17

18. Definitions: Use Case, Scenarios, and User Stories 18 Use Case User Story 1 (Supplement to Scenario) Scenario 1 Scenario 2 The 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)

19. Review of Key Use Case Sections Use 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 ActorSystemRole Information RequestorHealth IT SystemRequests access to patient data Receives patient data

20. Review of Key Use Case Sections Activity 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

21. Review of Key Use Case Sections Sequence 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

22. Review of Key Use Case Sections Functional 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

23. Week Target Date All Hands WG Meeting Tasks Review & Comments due Monday COB 18/14 Use Case Kick-Off & UC Process Overview Introduce: In/Out of Scope, Assumptions Review: In/Out of Scope, Context Diagram, Assumptions 28/21 User Stories, Pre/Post Conditions Finalize: In/Out of Scope Context Diagram, Assumptions Draft: User Stories Review: Actors & Roles, Pre/Post Conditions 38/28User Stories, Actors & Roles Review: User Stories Finalize: Actors/Roles, Pre/Post Conditions Review: User Stories 49/4Base Flow, Activity DiagramFinalize: User StoriesReview: Base Flow, Activity Diagram 59/11Functional Requirements Finalize: Base Flow, Activity Diagram Review: Functional Requirements 69/18 Functional Requirements, Sequence Diagram Review: Functional Requirements, Sequence Diagram 79/25Data Requirements Finalize: Functional Requirements, Sequence Diagram Review: Data Requirements 810/2Data RequirementsFinalize: Data RequirementsReview: Data Requirements 910/9Full Review & Finalize Data RequirementsEnd-to-End Review (10/9-10/16) 1010/16End-to-End Review (10/9-10/16) End-to-End Review comments due 10/15 1110/23Consensus Review (10/17-10/22)Cast consensus vote FINAL CONSENSUS (10/23) Proposed Use Case & Functional Requirements Development Timeline 23

24. Data Access Framework Local Access via Intra-Organization Query Targeted Access via Inter-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 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 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 orgs Governed by a network Receive aggregated or de-identified responses Focus on Information Model for the network and leverage standards from earlier phases. Create and disseminate queries to multiple orgs Governed by a network Receive aggregated or de-identified responses Focus on Information Model for the network and leverage standards from earlier phases. Data Source Data Source Data Source Query Request Query Response X Hospital System Y Hospital System 24 DAF Scope – Current focus: Local Data Access

25. 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 Access via Intra-Organizational Query

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

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

28. Assumptions 28

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

30. Next Steps Vote (Consensus) on the Project Charter – http://wiki.siframework.org/Data+Access+Framework+Charter+and+ Members 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 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

31. Initiative Support Leads For questions, please feel free to contact your support leads: – Initiative Coordinator: John Feikema john.feikema@siframework.orgjohn.feikema@siframework.org – ONC Sponsors: Mera Choi mera.choi@hhs.govmera.choi@hhs.gov – Support Team: Project Management: – Jamie Parker jamie.parker@esacinc.comjamie.parker@esacinc.com Technical Support: – Dragon (Nagesh) Bashyam nagesh.bashyam@drajer.comnagesh.bashyam@drajer.com Use Case Development: – Presha Patel presha.patel@accenture.compresha.patel@accenture.com Vocabulary and Terminology Subject Matter Expert: – Mark Roche mrochemd@gmail.commrochemd@gmail.com Project Support – Gayathri Jayawardena gayathri.jayawardena@esacinc.comgayathri.jayawardena@esacinc.com 31

32. Questions 32

33. Data Access Framework (DAF) Resources DAF Wiki Homepage – http://wiki.siframework.org/Data+Access+Framework+Homepage http://wiki.siframework.org/Data+Access+Framework+Homepage Become a Community Member – http://wiki.siframework.org/Data+Access+Framework+Join+the+Initia tive http://wiki.siframework.org/Data+Access+Framework+Join+the+Initia tive DAF Charter – http://wiki.siframework.org/Data+Access+Framework+Charter+and+M embers http://wiki.siframework.org/Data+Access+Framework+Charter+and+M embers Standards and Interoperability(S&I) Framework – http://wiki.siframework.org/Introduction+and+Overview http://wiki.siframework.org/Introduction+and+Overview S & I Calendar of Events – http://wiki.siframework.org/Calendar http://wiki.siframework.org/Calendar 33

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

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

36. Appendix B: Additional Use Case Reference Material 36

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

38. Some Previous and Ongoing S&I Use Cases (not a complete list) 38 Use Case Name (including links)Status Data Access FrameworkIn Progress Transitions of CareComplete Lab Results InterfaceComplete Provider Directory - Certificate DiscoveryComplete Provider Directory - Electronic Service Information DiscoveryComplete Query HealthComplete Data Segmentation for PrivacyComplete esMD - PPA Provider Registration (UC 1)Complete esMD - Secure sending and Structure of eMDR (UC 2)Complete esMD - Author of Record Level 1Complete Lab Orders InterfaceComplete Lab Orders Interface - eDOSComplete Health eDecisions CDS Artifact Sharing UC 1Complete Health eDecisions CDS Guidance Service UC 2Complete Structured Data CaptureComplete Longitudinal Coordination of CareComplete Public Health ReportingComplete Automate Blue Button InitiativeComplete Prescription Drug Monitoring ProgramComplete esMD – Author of Record Level 2Complete