ONC Annual Meeting: MU Training Day Query Health: Distributed Population Queries

1. ONC Annual Meeting: MU Training DayQuery Health: Distributed Population Queries Rich Elmore Coordinator Merideth Vida Clinical Alice Leiter Operations “Dragon” NageshwaraBashyam Technical November 18, 2011

2. Learning Objectives Upon completion of this training, you will be able to: • Explain distributed population queries • List ways in which distributed population queries can be used • Describe the 3 targeted standards for distributed population queries • Identify priority uses of distributed population queries in your community • Find Query Health on the web

3. Topics • Overview • Clinical • Operations • Technical • Exercise: Priorities for Pilot

4. Vision Enable a learning health system to understand population measures of health, performance, disease and quality, while respecting patient privacy, to improve patient and population health and reduce costs.

5. Context and Opportunity Context: The nation is reaching critical mass of deployed Electronic Health Records (EHRs) with greater standardization of information in support of health information exchange and quality measure reporting. The Opportunity: Improve community understanding of population health, performance and quality • Proactive population health management / care • Insights for local and regional quality improvement • Consistently applied performance measures and payment / incentive strategies • Most effective treatments • Visibility of utilization

6. The Challenge • High transaction and “plumbing” costs • Lack of query standards • Lack of understanding of best business practices • Variation in clinical concepts and codes, even within organizations • Centralizing tendency • Moves data further away from source – less actionable / maintainable • Increases PHI risk exposure

7. Improve community understanding of patient population health Clinical Information Question Aggregate Result Clinical Information Question Aggregate Result Questions about disease outbreaks, prevention activities, health research, quality measures, etc.

8. Expanded Analysis of Diabetes Aggregated Count Data Patient Data Note: All patient level data stays behind the firewall. Data Source Public Health Agency (Information Requestor) Query & Results Reviewer 1. EHR / Clinical Record (Patient Data) Translate patient data to CIM 3. Distribute Query to Data Sources 2. Clinical Information Model (CIM) 5. Sends Query Results to Information Requestor 4. Execute Query , format & return Results Responding Organization Firewall

9. Query HealthScope and Approach HIT Policy Committee: Policy Guideposts Practice drives standards Rough consensus Running code (open source) Pilot Specifications Standards

10. Inside Query Health

11. Summer Concert Series

12. Summer Concert Series: Challenges “The hardest part of distributed queries isn’t the technology, it’s the policy and governance” - - From several distributed query practitioners

13. Query NetworksVoluntary, No Central Planning Community of participants that voluntarily agree to interact with each other. There will be many networks; requestors and responders may participate in multiple networks. Query Authorized Requestors Participating Responders

14. Query HealthOrg & Timeline • Clinical • Current State Presentations • CIM, Query, Result • Alternatives, Convergence & Consensus • Pilots • Feedback to Standards & Pilot Support • Technology • Current State Presentations • Standards & Reference Implementation • Privacy, Security, Consent, Sustainability DUA, & Best Practices • Alternatives, Convergence & Consensus • Operations • Current State Presentations • Alternatives, Convergence & Consensus • Pilots

15. Community Participation Implementation Group Tuesdays 1:30pm-3pm ET Clinical Work Group Wednesdays 12pm-1pm ET Business Work Group Thursdays 11am-12pm ET Technical Work Group Thursdays 2-3pm ET Sign Up to Participate at QueryHealth.org Follow on Twitter hashtag: #QueryHealth Download to your calendar at QueryHealth.org

16. Goals Alignment with:S&I Framework S&I Framework Governance • Open Government Initiative • Engaging leaders from consumers, public health, research community, providers, health IT vendors, states / HIOs, payers and federal partners Meaningful Use and Standards • Standardized information models and terminologies, e.g., SNOMED, LOINC – vocabulary value sets associated with patient care and quality metrics • CIM model to support user stories, leveraging S&I initiatives and existing distributed query models • Transport approach will leverage / extend the NwHIN

17. Digital Infrastructure for a Learning Health System • Build a shared learning environment • Engage health and health care, population and patient • Leverage existing programs and policies • Embed services and research in a continuous learning loop • Anchor in an ultra‐large‐scale systems approach • Emphasize decentralization and specifications parsimony • Keep use barriers low and complexity incremental • Foster a socio‐technical perspective, focused on the population • Weave a strong and secure trust fabric among stakeholders • Provide continuous evaluation and improvement Reference IOM 2011. Digital Infrastructure for the learning healthcare system: Workshop series summary. National Academies Press.

18. Query HealthRecap

19. Why a Clinical Working Group? • The clinical working group is responsible for developing the Use Case, Functional Requirements and building the Clinical Information Model (CIM) and clinical concept mapping approach • The workgroup focuses on assessing the applicability of Query Health User Stories to available computable standardized data from certified EHRs and other standards-based health information sources, ultimately providing detailed, clinician-driven requirements of the pilot projects and reference implementation

20. Clinical Working Group Approach • In the first phase of Query Health, we are focusing on querying against the clinical record (EHRs and HIEs rather than claims and/or administrative systems) • We developed two user stories • Generic User Story – for general distributed queries, to lay a requirements-driven foundation • Expanded Analysis – specific to an outpatient setting, we focused on making diabetes information available for distributed query

21. Clinical Working GroupGeneric User Story in Action Data Source Information Requestor Distributes Query Results to Information Requestor Directly Sends Query to Data Source Directly Distributes Query Results to Intermediary OR Sends Query to Data Source Intermediary Distributes Query Results to Information Requestor Sends Query to Intermediary

22. Clinical Working GroupExpanded Analysis in Action Data Source (Provider/Provider Organization OR HIE) Information Requestor (Public Health Agencies, Quality Reporting Agency) Distributes Query Results to Information Requestor Directly Sends Query to Data Source Directly

23. Expanded Analysis of Diabetes Aggregated Count Data Patient Data Note: All patient level data stays behind the firewall. Data Source Public Health Agency (Information Requestor) Query & Results Reviewer 1. EHR / Clinical Record (Patient Data) Translate patient data to CIM 3. Distribute Query to Data Sources 2. Clinical Information Model (CIM) 5. Sends Query Results to Information Requestor 4. Execute Query , format & return Results Responding Organization Firewall

24. Clinical Working GroupExpanded Analysis Example Result Set Example Result Set

25. Clinical Working GroupFormation of Query Health requirements • User Stories are the foundation of the comprehensive Query Health Use Case & Functional Requirements • Query Health Use Case incorporates subject matter expertise, who were engaged to make sure the most frequently asked questions could be answered with the data elements included as part of the Functional Requirements • Ensured that core, critical data elements necessary for distributed queries were incorporated into functional requirements

26. Clinical Working GroupBenefits of Use Case Foundation • Use Case and Functional Requirements provide the framework for translating the vision of nationwide distributed healthcare queries into an implemented reality.

27. Clinical Working Group Clinical Information Model • Why / What? • The Clinical Information model (CIM) uses the functional requirements to establish clinically-focused information for queries • What questions would researchers and clinicians ask and how do we ensure that information is represented in a data model? • Leveraging best practices and industry-leading information models to extend current S&I Framework CIM efforts • Starting point: http://wiki.siframework.org/TOC+Clinical+Information+Model

28. Clinical Working Group Clinical Information Model • Admission Medications History • Hospital Discharge Medications • Medications Administered • Advance Directives • Pregnancy • Immunizations • Physical Examination • Vital Signs • Review of Systems • Hospital Course • Diagnostic Results • Assessment and Plan • Plan of Care • Family History • Social History • Encounters • Medical Equipment • Preoperative Diagnosis • Postoperative Diagnosis • Surgery Description • Surgical Operation Note Findings • Complications Section • Operative Note Surgical Procedure • Procedures • Diagnosis Code • Laboratory Results • Security Information • Care Setting • Facility Information • Entity Information • Functional Status • ??? • Personal Information • Demographic Information • Contact Information • Insurance Information • Healthcare Provider • Allergies • Other Adverse Reactions • Problem List • History of Past Illness • Chief Complaint • Reason for Transfer • History of Present Illness • List of Surgeries • Hospital Admission Diagnosis • Discharge Diagnosis • Medications

29. Clinical Working Group Clinical Concept Mapping Provider/Provider Organization (Role: Data Source) Information Requestor (Role: Query Source) • PSMA • Code 1 • Code 2 • LOINC • Code A • Code B UMLS (Value Set Repository) Clinical Concepts (unique per hospital, larger hospital system might share one) Map Clinical Concept Dictionary to Vocabulary Codes • SNOMED CT • Code XYZ • Code ABC • ICD 9 • Code 45 • Code 87 Query Request based on Clinical Concepts Data is Identified Clinical Concepts are Mapped from the Clinical Concept to Data in System Clinical Concepts Query is Received • ICD 10 • Code 124 • Code 89 Query Expression Query Results are Sent to Requestor Data is Formatted to Answer Query Data is mapped to Clinical Concepts Clinical Concepts Query Request is formatted

30. Clinical Working Group Benefits to Grantees • Use Case specifying the clinical and business needs for distributed queries through articulation of the scope into specific Actors, User Stories and requirements at the functional, system and dataset level • Foundational requirements to be reused for all distributed queries are directly aligned to data • Makes the process of building new queries and query types much easier and intuitive, and allows for reuse across different grantees • Reusable, best practice information model that can be immediately adopted by grantees interested in implementing distributed query capabilities • Clinical Concept Mapping approach will provide guidance to healthcare organizations who wish to participate in distributed query networks • Helps ensure that a clinical concept that is being queried is correctly coded and mapped to underlying health IT systems

31. Why an Operations working group? Operations working group is responsible for Query Health aspects including privacy, security, sustainability, extensibility and data use agreements. • Implement guidance from Health IT Policy Committee (HITPC) and Privacy & Security Tiger Team • Define operational assumptions (requirements) for each user story • Establish best practice recommendations & templates

32. Operations Working GroupChallenges “The hardest part of distributed queries isn’t the technology, it’s the policy and governance” - - From several distributed query practitioners

33. Operations Working Group Policy Sandbox • Control of data disclosures by data holder • Whether to run a query • Whether to release any results • Data being disclosed • Aggregated de-identified data sets or aggregated limited data sets, each with data use agreements (even in circumstances where they are not required by law), or • Public health permitted use under state or federal law providing the minimally necessary and permitted information (which may include identifiable information where permitted by law).

34. Operations Working Group Policy Sandbox (continued) • Data Use Agreement: • No re-identification • Clarity of purpose (permissible uses) • Small cells: • Cells with less than 5 observations in a cell shall be blurred by methods that reduce the accuracy of the information provided. • Exception for regulated / permitted use • (The CDC-CSTE Intergovernmental Data Release Guidelines Working Group has recommended limiting cell size to three counts presuming a sufficiently large population; this is also reflected in guidelines used by several states.)

35. Operations Working Group How does this work benefit you? • This work is of tremendous value to state HIE’s and other grantees looking to implement distributed queries: • Operational best practice considerations that can be reused by grantees • A reusable, high-level policy sandbox that sets a level policy playing field • Reusable policy requirements • Sample data use agreements that are driven by core elements agreed on by the industry, for reuse with potential distributed query partners

36. Why a Technical Working Group? The technical working group is establishing • 3 standards for distributed population queries (question, data, results) • Reference implementation technical foundation • Based on clinical and operations requirements.

37. Technical Working Group Focus Areas • Recommend standards based on proven distributed query implementations • Promotes interoperability in the distributed query space • Create Reference Implementation (RI) • Provide community a running code solution to pilot distributed query standards • Provide technical guidance, and assistance to conduct Pilots • Incorporate lessons learned back into the standards, RI

38. Technical Working Group Abstract Model - Query Network Community of participants that agree to interact with each other. There will be many networks; requestors and responders may participate in multiple networks. The network will enforce an initial, but not necessarily final, authorization boundary. Query Authorized Requestors Participating Responders

39. Technical Working Group Abstract Model - Query Lifecycle 1a Query Builder UX Authorized Requestor 1b 7 • Requestor optionally uses a query builder user interface to create a query and submits it to their dedicated orchestrator. • The orchestrator determines at what time and frequency the query should run (one time, monthly, etc.) and submits the query when appropriate to its requestoragent. • Requestor agent submits the query over the Internet to each participating organization’s responder agent and awaits responses. Responder agents may provide a number of services: additional authorization, manual review, etc. • The responder agent calculates site resultsusing the appropriate data sources. • The responder agent returns site results to the appropriate requestor agent. • The requestor agent returns site results to the aggregator that combines site results into combined results • The aggregator makes interim and final results available to the requestor. 6 2 Aggregator Orchestrator Requestor Agent 3 5 Responder Agent Responder Agent 4 Source Data Source Data Responder “1” Responder “N” … Note: All communication between Requestors and Responders are asynchronous.

40. Technical Working Group Technical Foundation (work in process)

41. Technical Working Group Benefits for Grantees • Leverage Query Health standards and reference implementation to connect new data sources to existing distributed query networks • Use Query Health reference implementation to establish new distributed query networks

42. Exercise: Community Priorities for Query Health Pilots

43. Exercise: Community Priorities for Query Health Pilots • Description: • Identify communities of interest that have a priority information need for a critical health, quality, or cost problem. • Describe potential Query Health pilots for your community: • The priority health question being addressed? • Who’s asking and answering the question? • What are the challenges today in getting this information? • Applicability of expanded analysis of diabetes in your community? • Mode of Participation: • Small groups by table • Time Allotted: • 20 minutes to complete; 3-5minutes for each table to report out • Directions: • Review the scenario as a team and work together to develop a response to the questions listed • Each table will then present their solution/recommendations to the class

44. Session Wrap Up/Summary In this session, we reviewed: • Distributed population queries • 3 targeted standards (query, CIM, results) • Priority uses in your community • Potential Pilots • QueryHealth.org Evaluation reminder