Query Health Technical Working Group

1. Query HealthTechnical 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

4. Rough Agenda: Wednesday * 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. Query Authorized Requestors Participating Responders

7. Query Lifecycle 1a Query Builder UX Authorized Requestor 1b 7 • Requestor optionally uses a query builder user interface to create a query and submits it to their dedicated orchestrator. • The orchestrator determines at what time and frequency the query should run (one time, monthly, etc.) and submits the query when appropriate to its requestoragent. • 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. • The responder agent calculates site resultsusing the appropriate data sources. • The responder agent returns site results to the appropriate requestor agent. • The requestor agent returns site results to the aggregator that combines site results into combined results • The aggregator makes interim and final results available to the requestor. 6 2 Aggregator Orchestrator Requestor Agent 3 5 Responder Agent Responder Agent 4 Source Data Source Data Responder “1” Responder “N” … Note: All communication between Requestors and Responders are asynchronous.

8. Query Envelope Query Response Responder identifier Response identifier (unique within responder space) Requestor identifier Query identifier Freeform notes for requestors Results Usage policy information Response Payload • 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

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., hQueryJavascript 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!