query health pilots sub-work group december 8, 2011
DESCRIPTION
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: - PowerPoint PPT PresentationTRANSCRIPT
Query HealthPilots 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
Timeframe
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.
Query Health Work Groups
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
Scope and Approach(Implementation WG)
Practice drives standards1.Rough consensus2.Running code (open source)3.Pilot4.Specifications5.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
IntermediaryIntermediary
Distributes Query Results to Information Requestor
Sends Query to Intermediary
Distrib
utes Query
Results
to In
termediar
y
Sends Q
uery to
Data
Source
Information Requestor
Information Requestor
Data SourceData SourceSends 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 isn’t the technology, it’s 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
Conceptual Architecture(Technical WG)
Pilot Architecture Pattern Iusing an intermediary
Information Requestor
Query Builder
Data Source - Provider - 1
Responder Agent
Data SourceData
Source
Vendor specific Mapper
Intermediary – HIE/HISP/RHIOIntermediary – HIE/HISP/RHIO
Inbound
Requestor AgentOrchestrator
Aggregator
OutboundData Source - Provider - N
Responder Agent Data
SourceData
Source
Vendor specific Mapper
1..N
CIM
CIM
CIM
Policy Sandbox, Data Level Agreements, Access ConsentPolicy Sandbox, Data Level Agreements, Access Consent
Pilot Architecture Pattern IIwithout an intermediary
Information Requestor
Query Builder
Data Source - Provider - 1
Responder Agent
Data SourceData
Source
Vendor specific Mapper
Information RequestorInformation Requestor
Inbound
Requestor AgentOrchestrator
Aggregator
OutboundData Source - Provider - N
Responder Agent Data
SourceData
Source
Vendor specific Mapper
Policy Sandbox, Data Level Agreements, Access ConsentPolicy Sandbox, Data Level Agreements, Access Consent
1..N
CIM
CIM
CIM
Community Participation
Implementation GroupTuesdays 1:30pm-3pm ET
Clinical Work Group Wednesdays 12pm-1pm ET
Business Work GroupThursdays 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 atQueryHealth.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 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
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 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.
EHR/HIEdatastoreEHR/HIE
datastorequery
datastorequery
datastoreETL
processETL
process
EHR Schema
EHR Schema MappingMapping
Query Health
CIM
Query Health
CIM
Responder Agent
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
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 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
QueryBuilder UX
Aggregator
Source Data Source Data
AuthorizedRequestor
1a
1b
4
5
6
3
Responder “1” Responder “N”…
Orchestrator2
7
Note: All communication between Requestors and Responders are asynchronous.
Technical Foundation(Technical WG)