1. Rich ElmoreCoordinator Merideth Vida Clinical Alice Leiter Operations “Dragon” Nageshwara Bashyam Technical ONC Annual Meeting: MU Training Day Query Health: Distributed Population Queries 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 1

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

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 Questions about disease outbreaks, prevention activities, health research, quality measures, etc.

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

9. Query Health Scope and Approach Practice drives standards 1.Rough consensus 2.Running code (open source) 3.Pilot 4.Specifications 5.Standards HIT Policy Committee: Policy Guideposts

10. Inside Query Health

11. Summer Concert Series

12. Summer Concert Series: Challenges Distributed Population Queries Best Practices for Data Use / Sharing Sustainability Organization, Management and Coordination Auditability Privacy, Security and Consent Consistency of Clinical Concepts Data Extensibility Queries Across Organizations Multiple Networks “The hardest part of distributed queries isn’t the technology, it’s the policy and governance” - - From several distributed query practitioners “The hardest part of distributed queries isn’t the technology, it’s the policy and governance” - - From several distributed query practitioners

13. Query Networks Voluntary, 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. Authorized Requestors Participating Responders Query

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

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 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 Health Recap

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 18

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 19

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

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

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

24. Clinical Working Group Expanded Analysis Example Result Set 23 Example Result Set Query Result for Provider X (where X is each reporting provider): GenderAge RangeZip CodeSetting Encounter Type RaceEthnicity Insurance Coverage For specified time frame: (MM-DD-YYYY - MM-DD-YYYY) TotalMaleFemale<1818 - 64≥65100211003110041InpatientOutpatientED….. Numerator Counts Risk Score 0-1 2-3 4-5 6-7 HbA1c > 9.0%1055 Blood Pressure ≥ 140/90 mm Hg532 LDL ≥ 130 mg/dl Microalbumin > 30 microgram/mg Creatine BMI ≥ 25 kg/m^2 Smoking Status Foot Examination Eye Examination Medication - Statin Medication - Asprin Medication - Ace Inhibitor/ARB Denominator Counts Diagnosis of Diabetes1006040 Type I Type II And all Risks Scores And Hb A1c Result604030 And BP Reading803545 And LDL Result And Microalbumin And BMI And Medications

25. Clinical Working Group Formation 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 24

26. Clinical Working Group Benefits 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. 25 Abstract Model Clinical Information Model Clinical Concept Mapping Technical Foundation Query Health Use Case Foundation

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 http://wiki.siframework.org/TOC+Clinical+Information+Model 26

28. Clinical Working Group Clinical Information Model – 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 27 – 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 – ??? – 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

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

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 29

31. Why an Operations working group? 30 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 Group Challenges Distributed Population Queries Best Practices for Data Use / Sharing Sustainability Organization, Management and Coordination Auditability Privacy, Security and Consent Consistency of Clinical Concepts Data Extensibility Queries Across Organizations Multiple Networks “The hardest part of distributed queries isn’t the technology, it’s the policy and governance” - - From several distributed query practitioners “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). 32

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.) 33

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 34

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

37. Technical Working Group Focus Areas 36 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. Authorized Requestors Participating Responders Query

39. Technical Working Group Abstract Model - Query Lifecycle 1.Requestor optionally uses a query builder user interface to create a query and submits it to their dedicated orchestrator. 2.The orchestrator determines at what time and frequency the query should run (one time, monthly, etc.) and submits the query when appropriate to its requestor agent. 3.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. 4.The responder agent calculates site results using the appropriate data sources. 5.The responder agent returns site results to the appropriate requestor agent. 6.The requestor agent returns site results to the aggregator that combines site results into combined results 7.The aggregator makes interim and final results available to the requestor. Requestor Agent Responder Agent Responder Agent Query Builder UX Aggregator Source Data Authorized Requestor 1a 1b 4 5 6 3 Responder “1”Responder “N” … Orchestrator 2 7 Note: All communication between Requestors and Responders are asynchronous.

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

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 40

42. Exercise: Community Priorities for Query Health Pilots 41

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: 1.Review the scenario as a team and work together to develop a response to the questions listed 2.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 43