Query Health Pilots Sub-Work Group December 8, 2011

1. Query HealthPilots Sub-Work GroupDecember 8, 2011

2. Agenda • Introductions • Logistics • Orientation • Pilots Sub-Work Group context • The Pilot Project Profile • EHR/HIE vendor collaboration • Priorities, strategy, and organization discussion

3. Context, Vision, 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. 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. Opportunity: Improve community understanding of population health, performance and quality through • 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

4. The Challenge The Query Health Initiative seeks to overcome barriers to the widespread adoption and use of distributed query technology for population health surveillance, quality measures, and clinical research. Some barriers are: • 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 its source, making it less actionable and maintainable. • Increases PHI exposure risk.

5. Value Statements • Improve quality monitoring, public health surveillance and clinical researchby using distributed queries for quality measures, disease outbreaks, comparative effectiveness analysis, efficacy of drug treatments and monitoring health trends. • Distributed queries provide access to data, for analysis purposes, while maintaining patient privacy and security by keeping protected health information safely behind healthcare organization firewalls. This will reduce the complexity of managing patient consent and authorizations, audit logs and access lists requirements. • The value of the Query Health Initiative will be to lower the barrier using consensus-based standards and specifications to support queries for population based/aggregated data from certified EHRs and other community records. • The initiative will provide a standardized Clinical Information Model (CIM) to support implementable, high-value user stories, based on available, shareable and standardized information from EHRs and other patient care systems. • The initiative will also provide extensible ‘Query’ and ‘Return Results’ standards and services, enabling interoperability between and among information requestors and data sources. • Specification of these standards (CIM, Query/Results) will assist the development and implementation of software and pilots, and will facilitate analysis of results. • Use of these standards and services (CIM, Query/Results) can result in increased speed and reduced transaction costs for healthcare providers to analyze and apply information regarding prevention activities, healthcare research, and disease outbreaks. • The above benefits can be combined to reduce the overall cost of healthcare and to improve the health of all citizens.

6. Pilot Project Participants A pilot may involve the following participants from the healthcare ecosystem: • Health Care Provider (Hospital or Clinic) • EHR/HIE/PHR Vendors • HISP or System Integrator • Health Information Exchange • PHR provider • Provider or Patient or Caregiver

7. Timeframe

8. Pilots Sub-Work Group Created to support and administer the Pilot Projects Program. The program encompasses pilot projects to be undertaken by participants in the Standards & Interoperability Framework and the Query Health Initiative. This group will: • Help to organize Query Health Pilot Projects. • Provide a forum wherein Pilot Project participants can discuss ideas, resolve issues, and collaborate on common work. • Provide facilities whereby the other Query Health Work Groups and the ONC support staff can support the participants in their Pilot Projects. The Pilots SWG has Wiki pages rooted at http://wiki.siframework.org/Query+Health+Pilots+%28Sub-Work+group%29.

9. Query Health Work Groups Clinical Current State Presentations CIM, Query, Result Pilots Feedback to Standards & Pilot Support Alternatives, Convergence & Consensus Technology Current State Presentations Standards & Reference Implementation Alternatives, Convergence & Consensus Privacy, Security, Consent, Sustainability DUA, & Best Practices Operations Current State Presentations Alternatives, Convergence & Consensus Pilots

10. Implementation Work Group The overarching workgroup that coordinates and integrates the work of the Clinical, Technical, and Operations Work Groups. Responsible for setting scope, approach, roles, and products, and for interfacing with other initiatives. Ensures that the initiative’s operations align with: 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

11. Scope and Approach(Implementation WG) HIT Policy Committee: Policy Guideposts Practice drives standards Rough consensus Running code (open source) Pilot Specifications Standards

12. Clinical Work Group • Responsible for developing the Use Case and Functional Requirements, and for building the Clinical Information Model (CIM) and clinical concept mapping approach. • Focused 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. • Concentrating first on the clinical record (EHRs and HIEs rather than claims and/or administrative systems). • Developed two user stories: • Generic User Story for general distributed queries, to lay a requirements-driven foundation • Expanded Analysis User Story specific to an outpatient setting, focused on making Type-II Diabetes information available for distributed query

13. Generic User Story(Clinical WG) 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

14. Operations Work Group “The hardest part of distributed queries isn’t the technology, it’s the policy and governance” - - From several distributed query practitioners Responsible for operational aspects including privacy, security, sustainability, extensibility and data use agreements. • Take guidance from Health IT Policy Committee (HITPC) and Privacy & Security Tiger Team. • Create a reusable, high-level policy sandbox that sets a level policy playing field and establishes reusable policy requirements. • Create sample data use agreements driven by core elements agreed by industry, for reuse with potential distributed query partners. • Define operational assumptions and requirements for each user story. • Establish operational best practice recommendations & templates for reuse in pilots. • Sustainability • Organization, management, & coordination • Consistency of clinical concepts • Data extensibility • Cross-organization queries • Multiple networks

15. Technical Work Group • Responsible for marshalling architecture, standards, software tools, code development, and other resources to implement the output of the Operations and Clinical Work Groups in the real world. • Recommend standards based on proven distributed query implementations • Promotes interoperability in the distributed query space • Recommend changes to standards as warranted • 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

16. Conceptual Architecture(Technical WG)

17. Pilot Architecture Pattern Iusing an intermediary Data Source Responder Agent Intermediary – HIE/HISP/RHIO Information Requestor Vendor specific Mapper Query Builder CIM Inbound Orchestrator Requestor Agent 1..N Outbound Aggregator CIM Data Source - Provider - N Data Source Responder Agent Data Source - Provider - 1 CIM Vendor specific Mapper Policy Sandbox, Data Level Agreements, Access Consent

18. Pilot Architecture Pattern IIwithout an intermediary Data Source Responder Agent Information Requestor Information Requestor Vendor specific Mapper Query Builder CIM Inbound Orchestrator Requestor Agent 1..N Outbound Aggregator CIM Data Source - Provider - N Data Source Responder Agent Data Source - Provider - 1 CIM Vendor specific Mapper Policy Sandbox, Data Level Agreements, Access Consent

19. 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 Concept Mapping sub Work Group Tuesday 3-4pm ET Pilot Work Group Thursdays 3.30-4.30pm ET Sign Up to Participate at QueryHealth.org Follow on Twitter hashtag: #QueryHealth Download to your calendar at QueryHealth.org

20. Pilot Project Profile • The profile is intended to collect both high-level and detailed information about pilot projects. • Study the profile in order to learn about the considerations and decisions necessary to undertake a pilot project. • Submit a completed copy of the profile to the Query Health Initiative’s Pilots Sub-Work Group. • Over the course of project development, add details and supporting documents as necessary to keep the Initiative apprised of its progress. • The profile is a “living document”. It does not have to be completed in its entirety before the pilot project is approved or begun. It is intended to serve as a guide to and record of the decisions and activities associated with the pilot project over its entire lifetime. • The Pilot Project Profile template is available on the Pilots SWG Wiki page, or at http://wiki.siframework.org/file/view/Query%20Health%20Pilot%20Project%20Profile.doc

21. Six Profile Sections • The Pilot Story section is for recording the overall objectives, strategy, and organization of the pilot project in the form of a high-level descriptive narrative. • The General Information section collects identifying and strategic information about the pilot project. • The Participating Organization(s) section collects detailed information about each partner in the project, and their roles and capabilities. • The Technical Approach section collects detailed information about the technical implementation of the pilot project: architecture, design, components, data flow, intersystem communications, and so forth. • The Essential Planning section addresses the major components of the pilot project plan, including the project timeline, phases and milestones, resources available, and resources yet to be acquired. • The Project Tracking section provides checklists of activities that are appropriate at various stages of the pilot project.

22. Vendor Collaboration • The ONC is asking EHR and HIE software vendors to organize and collaborate in support of the Pilot Projects and of the Query Health Initiative. • The vendors in the collaboration group should include at least the vendors that serve the pilot project participants. • Pilot project participants can then adopt the modified software from their vendors.

23. Vendor Collaboration EHR/HIEdatastore ETL process querydatastore Responder Agent EHR Schema Mapping Query Health CIM • The system architecture developed by the Technical WG calls for a query datastore that conforms to the CIM as realized by the Technical WG’s schema. This work is being done in the Concept Mapping SWG. • The vendors are being asked to map the Query Health CIM schema to their own internal datastore, and to develop the means whereby the query datastore is kept in sync with it.

24. General Discussion • General discussion topics • What does this group need to get started? • Are there any questions or issues that need to be addressed? • What are our priorities and next steps?

25. More In-Depth Information The following slides go into more detail about specific products of the Query Health Work Groups.

26. Clinical Information Model (Clinical WG) • What is it and why do we need it? • 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? • We leveraging best practices and industry-leading information models to extend current S&I Framework CIM efforts. • The 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 • Started from Transitions of Care CIM: http://wiki.siframework.org/TOC+Clinical+Information+Model

27. Privacy and Security(Operations WG) • Federal privacy and security rules set forth a set of requirements necessary to protect individually identifiable health information from unauthorized use and disclosure, all of which must be met by Query Health Participants. This User Story acknowledges the variations in privacy and security policies and requirements for reporting across local, state, tribal and territorial boundaries, as well as voluntary versus mandatory requirements. • At a minimum, participants must: • Comply with the laws governing the privacy and security of health information, including but not limited to HIPAA, HITECH and state and local rules. • Comply with the full complement of applicable Fair Information Practices. • Develop policies and procedures consistent with those developed by ONC and, where appropriate, with the Health IT Policy Committee, Privacy and Security Tiger Team and Health IT Standards Committee recommendations. • Apply Policy Sandbox requirements, including: • Pilot will use aggregated numeric counts the least-identifiable data form. • Whether or not to run a particular query, and to release any results, will be under the control of the disclosing entity/data holder. • Data being exchanged by a disclosing entity/data holder will be either mock or test data, aggregate de-identified data sets or aggregated limited data sets (each with data use agreements), or a public health permitted use under state or federal law (which may be identifiable information where permitted by law). • For other than regulated/permitted use purposes, cells with less than 5 observations in a cell shall be blurred by methods that reduce the accuracy of the information provided.

28. Query Lifecycle(Technical WG) 1a Query Builder UX Authorized Requestor 1b 7 6 2 Aggregator Orchestrator Requestor Agent 3 5 Responder Agent Responder Agent 4 Source Data Source Data Responder “1” Responder “N” … 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. Note: All communication between Requestors and Responders are asynchronous.

29. Technical Foundation(Technical WG)