Query Health Distributed Population Queries

Implementation Group Meeting

September 27, 2011

Participation Instructions for WebEx

Please Note: • This session will be recorded• Lines are open so please mute your line to avoid “Music on Hold”

1. Select the “Q&A” button in the WebEx toolbar.

2. Select “All Panelists” in the Q&A box.

3. Type your question and hit send.

4. We’ll call on you to state your comment / question

.

Agenda

• Summary of Last Meeting & Reminders• WG updates

• Clinical• Technical• Business

• Charter – 2nd Call for consensus• Discussion Forums

• Security / Privacy Tiger Team – Recap• Meaningful Use Working Group

• Open discussion / Next Steps

Query HealthScope and Approach

Practice drives standards1. Rough consensus2. Running code (open source)3. Pilot4. Specifications5. Standards

Query Health – Distributed

Population Queries

Standards & Service

Public / Private Partnership

Project

Community Driven,

Consensus-based

EHRs & Other Clinical Records

HIT Policy Committee:

Policy Guideposts

Query HealthWhere We are

Query HealthCalendar

Implementation GroupTuesdays 1:30pm-3:00pm EDT

Technical Work GroupWednesdays 11am-12pm EDT

Clinical Work Group Wednesdays 12pm-1pm EDT

Business Work GroupThursdays 11am-12pm EDT

First Face to Face MeetingOctober 18-19

Sign Up atQueryHealth.org

Download to your calendar at

QueryHealth.org

Query HealthWho’s participating (As of 9/27)

95+ Participating Organizations– Public Health Agencies– Health IT Vendors– Health Information Exchanges– Academic Partners– Health Systems– Patient Advocacy Organizations

Recap of Last Meeting

• Reviewed Query Health Scope, Approach, Timeline, and Organization

• Reviewed the objectives of each working group• Clinical – Use Cases, User Stories, Clinical Information Models• Technical – Architectural principles, technical standards /

specifications, design of pilot implementations• Business – best practices for privacy, data use, network partner

coordination• Discussed Policy Sandbox and presentation to HITPC

Action ItemsDescription Owner Status Due Date NotesReview changes to the charter and provide comments for consensus by 9/29/2011

Working Group Participants

Closed. 9/29/2011 Please provide updated votes and comments Call for Consensus page

Register and arrange for travel for the October Face to Face meeting

Working Group Participants

Open 9/29/2011  

Choose leaders for each of the Work Groups

Working Group Participants

Open 9/29/2011  To be discussed at each WG meeting week of 9/26

Clinical Working Group

Update from 9/21 Meeting

• Presented & Discussed Community User Story proposals– Expanded Analysis User Story (Presented by Kim Nolen & Lindsey Hoggle)– Updated Generic Population Measures User Story (Presented by Michael Buck)

• Recap: Proposed User Stories

Key Topics Covered/Discussed

User Story Name Leads & Contributors Expected Presentation Date

Link

Example User Story – Case Control, Statin Efficacy

Working Group Participants 9/21/2011 Example User Story – Case Control, Vaccine Efficacy

Example User Story – Case Control, Vaccine Efficacy

Working Group Participants 9/21/2011 Example User Story – Case Control, Statin Efficacy

Expanded Analysis User Story Kim Nolen (Lead), Lindsay Hoggle 9/21/2011 Expanded Analysis User Story

Generic Population Measures User Story

Michael Buck, Susan Campbell 9/14/2011 Reportable Disease Reporting User Story

Consumer Perspective User Story

Eva Powell 9/14/2011 Consumer Perspective User Story

All Hazards User Story Taha Kass-Hout 9/28/2011 TBD

Hypothesis Generation User Story

David McCallie 9/28/2011 TBD

Decisions• The Working Group members decided it would be best to have the Generic User Story be

included as part of the Use Case supplemented by 1-2 additional User Stories. 

Work Assignments/Next Steps• Develop, refine and provide comments using the wiki discussion tab for the following:

– Proposed User Stories• Example User Story – Case Control, Vaccine Efficacy• Example User Story – Case Control, Statin Efficacy• Generic Population Measures User Story

• Consumer Perspective User Story• Expanded Analysis User Story• All Hazards User Story• Hypothesis Generation User Story• Sentinel user story

• The Working Group will prioritize and select the remaining 1-2 User Stories during the 9/28 meeting based on;

– National Priorities– Leveraging existing research and public health network infrastructure

• Review and comment on draft Functional Requirements

Key Decisions & Next Steps

Query HealthTechnical WG Update

9/27/2011

Technical WG Update

• Two major discussion topics

• Abstract Model discussion - Sean Nolan

• Scan of Existing standards discussion – Srinivas Velamuri

Abstract Model Discussion

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.

AuthorizedRequestors

ParticipatingResponders

Query

Query Lifecycle

1. Requestor optionally uses a composer to create a query and submits it to their dedicated agent.

2. Agent submits the query over the Internet to each participating responder’s gateway and awaits responses.

3. At each participating responder, the standard gateway passes the request to a site-specific adapter.

4. The adapter calculates site results for their site and returns them to the gateway.

5. The gateway returns site results to the appropriate agent.

6. The 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.

Agent

Gateway Gateway

Adapter Adapter

Composer Aggregator

ClinicalData

ClinicalData

Authorized Requestor

1

2

34

5

6

7

Responder “1” Responder “N”…

Query Envelope

Query

• Requestor identifier• Query identifier (unique

within requestor space)• Freeform notes for

responders• Query type and version• (List of) Query Items

– Item name/tag (unique within request)

– Item request payload

Response• Responder identifier• Response identifier (unique

within responder space)• Requestor identifier• Query identifier• Freeform notes for

requestors• (List of) Response Items

– Item name/tag– Item status– Item response payload

Query Payload

Query Health supports multiple “query types” traveling over the same transport and envelope

Types are identified by a name and version– E.g., “MU Stage 1 EP/1.0”

Each type implies– Query syntax– Clinical information model– Response format

Existing Standards Discussion

Update from Discussions

• Standards Examined

• QRDA• QRDA Category I – Single Patient Quality Report • QRDA Category II – Multi-Patient Quality Report• QRDA Category III – Aggregate or Summary Level

Quality Report

• HQMF or eMeasures – Health Quality Measures represented in Electronic Format

• To determine if either of these two standards can be used to represent Queries and/or Results Payload

Summary of QRDA and HQMF

• Summary from the WG Discussion:

• Query Health will have to support different types of queries including dynamic queries and a variety of result formats

• Given the generic use cases and purposes that Query Health standards and protocols will be used for, the WG thinks that QRDA and HQMF are too constrained as they currently exist.

Technical WG – Next Steps

• Will be working towards WG approval of the Abstract model and bring it to the Implementation Group

• Sign up for developing and refining the various artifacts at the following links and present at the next WG meeting:

• Abstract Model Discussion Link - http://wiki.siframework.org/Query+Health+Abstract+Model+and+Terminology

• Patterns Summary Discussion Link -

http://wiki.siframework.org/Summer+Concert+Series+Patterns+and+Summary

• Existing Standards Discussion Link - http://wiki.siframework.org/Query+Health+-+Existing+Standards+and+Models+Landscape

QRDA Category I Sample

QRDA Category II Sample

QRDA Category III Sample

HQMF Sample

HQMF Sample Cont’d

Business Working Group

Update from 9/22 Meeting

• Points of Discussion– Use key secondary uses for domain specific requirements –

these have been added to Matrix– Examine privacy and security framework developed for caBIG in

work with the University of Michigan– Clarification of plans for pilot(s) and use of Policy Sandbox

• ONC supported pilots will use the Policy Sandbox• Different applications of Query Health tools will conform to the

necessary data use agreements and privacy and security regulations as applied to the specific query domain and type

Key Topics Covered/Discussed

Business Working Group Key Decisions and Next Steps

• Decisions• The WG agreed to focus on developing Business Requirements for the

General Use Case using the Business Matrix

• Work assignments/Next Steps– Enter business requirements for General Query Health Use

Case – Schedule time for self-organized calls to develop business

requirements next week

Project Charter

• Key assumptions:– Initiative will leverage existing distributed query technology (e.g. those

identified from the summer concert series) and NwHIN technology as appropriate

– Existing S&I ToC data model as the CIM starting point (with extensions if needed for the selected user story)

• Key demonstrations – 1 or 2 user stories to pilot and test – The broader set of user stories is intended to ensure that the

architecture framework is robust and extensible• Pilot sites will be selected based on

– national priorities – Existing research and health information management infrastructure

Scope Clarification & Discussion

Project Charter FeedbackEndorsement (Yes or No)

If No, what can be changed to make it Yes?

YesNo I share the Microsoft and Epic concerns. Clarification of the role of "network partners" should be easy, as I don't think they are a required part

of the model. Deciding on the PHI question may not be so easy. As stated in a comment earlier, I do not think QH should by design exclude the ability to

return PHI as part of a query response. Clearly QH must operate within the law, and within the contracts that will exist between query placers and query responders.

Perhaps the charter should specify a range of response restrictions that will be supported, based on the contracted use cases? I believe that i2b2 has this capability, supporting aggregate counts for some users, "limited data sets" for other users, and PHI-containing responses for users who have obtained a waiver from an appropriate IRB.

No Confusing Terminology - "As a result, information requestors will be able to create and securely distribute queries to network data partners who subscribe to the published queries." **Publish/Subscribe** is a well-defined messaging pattern, which doesn't seem to be part of the Query Health intent. Maybe "who support the defined queries" is a better wording.

Use of CDR - While EHR systems in this context can be assumed to be defined by HITECH and MU, the same is not true for Clinical Data Repository. Using this term may lead to the understanding that providers need to purchase a specific CDR product in order to be able to provide responses to the queries. Suggest using "Query Health Responder" or "Query Health Data Responder" as the generic term to be used in addition to EHR systems.

No We agree with comments that PHI should be allowed, and to the extent possible, the Project Charter should call for the technical means and policies to assure that PHI is not compromised.

YesNo Agree with both comments from Epic

"network data provider" in the scope section implies an intermediary that may or may not turn out to be relevant ... better as a simpler description such as "information requestors will be able to create and securely distribute queries to network data partners who subscribe to the published queries. Network data partners will examine queries and pass them on to data sources. Data sources, such as a provider organizations, will execute the query against a standard clinical information model, and securely return the results of the query to a data network partner, and then subsequently to the requester." Note there are other uses of the "network data provider" term that should also be addressed.

In the Key Assumptions section, we continue to struggle with the limitations being placed on the movement of PHI and the "initial pilot" ... we will likely have multiple pilots, and some of them may be between partners that are comfortable sharing PHI. I don't understand why we feel a need to put this into the charter --- I can only see it hurting our ability to deliver the best possible model.

Yes with Comments The wording around whether or not limited PHI such as for public health purposes is to be piloted and permitted is not clear or consistent in the current draft. It needs to be edited for clarity as it looks like we wish to permit it.

Yes

Open Discussion

• Identify Working Group leadership• Call for consensus on Charter (third time’s the charm!) – Sept 29• Face-to-Face Meeting October 18, 19

– Register– Arrange Travel

Next Steps