1. Query Health Technical Working Group F2F meeting 10/17/2011 Agenda

2. Our Mission for the F2F Get to know each other and forge the relationships we’ll need to get through the project successfully Agree on how to agree --- what are the key attributes of the right technical solution? Break the problem down into parallel sub-projects Self-select into groups to work on these projects Have fun and change the world!

3. Rough Agenda: Tuesday TUESDAY8:00amKeynotes 9:00amQH Overview (full QH Team) 10:00amDoug 11:00amTWG Kickoff NoonLunch Stuff 1:30pmToC Overview & Decision-Making Criteria 3:00pmBreak 3:15pmExisting Tech Overview (40 minute blocks) hQuery, Hub, NwHIN 4:45pmAdjourn

4. Rough Agenda: Wednesday WEDNESDAY8:00amExisting Tech Overview (40 minute blocks) I2b2, PopMedNet 10:00amBreak 10:15amExisting Tech Overview (40 minute blocks) OMOP, UPHN NoonLunch Stuff 1:30pmSelf-select into working groups 3:00pmBreak 3:15pmRecap and determine next steps 4:30pmReport out (full QH team) 5:30pmAdjourn * Note: Sean AWOL before noon and after 3:40pm

5. FIRST CONSENSUS! QUERY HEALTH ABSTRACT MODEL

6. 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. The network will enforce an initial, but not necessarily final, authorization boundary. Authorized Requestors Participating Responders Query

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

8. Query Envelope Query Requestor identifier Query identifier (unique within requestor space) Security and Privacy Context (auth, privacy, etc.) Optional recurrence information to support repeated queries Freeform notes for responders Query type and version Query Payload Response Responder identifier Response identifier (unique within responder space) Requestor identifier Query identifier Freeform notes for requestors Results Usage policy information Response Payload

9. 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 *Goal is to support two types in pilots; one very simple and one more complex to support the clinical workgroup user stories.

10. SESSIONS

11. Sub-project types: Should be plug&play Transport – Define the way queries and responses will move around Query Type: Measures – Define query and response payloads for measure-based queries (e.g., MU stage 1 by name). How will we standardize the universe of measures, input parameters, and output format? Query Type: Granular / ToC CIM – Define query and response payloads for queries that involve computation against a defined clinical model (e.g., hQuery Javascript or just SQL). Authentication & Policy Expression – This is a bit more vague … how to represent in the envelope the information required to authenticate queries and communicate inbound and outbound usage policies?

12. How to agree? Strawman criteria: Vendor-neutral Asynchronous Scalable (Computation) Scalable (Operation) Extensible Developer-friendly / approachable Minimal new technology (both conceptual and physical) Leverages existing work/standards (NwHIN, ToC CIM, etc.) Policy-friendly (e.g., manual review) Achievable with existing EHRs Has volunteer resources for a reference implementation!