Query Health Abstract Model Diagrams

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

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 Responder “1”Responder “N” … Orchestrator 2 7 Note: All communication between Requestors and Responders are asynchronous.

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

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.