Presentation on theme: "Query Health Pilots Sub-Work Group December 8, 2011."— Presentation transcript:
Query Health Pilots Sub-Work Group December 8, 2011
Agenda Introductions Logistics Orientation Pilots Sub-Work Group context The Pilot Project Profile EHR/HIE vendor collaboration Priorities, strategy, and organization discussion
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
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.
Value Statements Improve quality monitoring, public health surveillance and clinical research by 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.
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
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. http://wiki.siframework.org/Query+Health+Pilots+%28Sub-Work+group%29
Query Health Work Groups 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 Query Health Implementation Group Clinical Work Group Clinical Concept Mapping Sub Work Group Technical Work group Operations Work Group Pilot Sub Work Group
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 initiatives 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
Scope and Approach (Implementation WG) Practice drives standards 1.Rough consensus 2.Running code (open source) 3.Pilot 4.Specifications 5.Standards HIT Policy Committee : Policy Guideposts
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
Generic User Story (Clinical WG) 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
Operations Work Group 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 The hardest part of distributed queries isnt the technology, its the policy and governance - - From several distributed query practitioners The hardest part of distributed queries isnt the technology, its the policy and governance - - From several distributed query practitioners
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
Pilot Architecture Pattern I using an intermediary Information Requestor Query Builder Data Source - Provider - 1 Responder Agent Data Source Vendor specific Mapper Intermediary – HIE/HISP/RHIO Inbound Requestor Agent Orchestrator Aggregator Outbound Data Source - Provider - N Responder Agent Data Source Vendor specific Mapper 1..N CIM Policy Sandbox, Data Level Agreements, Access Consent
Pilot Architecture Pattern II without an intermediary Information Requestor Query Builder Data Source - Provider - 1 Responder Agent Data Source Vendor specific Mapper Information Requestor Inbound Requestor Agent Orchestrator Aggregator Outbound Data Source - Provider - N Responder Agent Data Source Vendor specific Mapper Policy Sandbox, Data Level Agreements, Access Consent 1..N CIM
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 Download to your calendar at QueryHealth.org
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 Initiatives 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
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.
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.
Vendor Collaboration The system architecture developed by the Technical WG calls for a query datastore that conforms to the CIM as realized by the Technical WGs 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. EHR/HIE datastore query datastore ETL process EHR Schema Mapping Query Health CIM Responder Agent
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?
More In-Depth Information The following slides go into more detail about specific products of the Query Health Work Groups.
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 http://wiki.siframework.org/TOC+Clinical+Information+Model
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.
Query Lifecycle (Technical WG) 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 organizations 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 1Responder N … Orchestrator 2 7 Note: All communication between Requestors and Responders are asynchronous.
Your consent to our cookies if you continue to use this website.