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)