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
Query Lifecycle 1a Query Builder UX Authorized Requestor 1b • 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 agent. • Agent submits the query over the Internet to each participating responder’s gatewayand awaits responses. Gateways may provide a number of services: additional authorization, manual review, etc. • The standard gateway passes accepted requests to a site-specific adapter. • The adapter calculates site results for their site and returns them to the gateway. • The gateway returns site results to the appropriate agent. • The 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. 8 7 2 Aggregator Orchestrator Agent 3 6 Gateway Gateway 5 4 Adapter Adapter Clinical Data Clinical Data Responder “1” Responder “N” …
Query Envelope Query 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 • Requestor identifier • Query identifier (unique within requestor space) • Metadata to support policy decisions (auth, privacy, etc.) • Optional recurrence information to support repeated queries • Freeform notes for responders • Query type and version • (List of) Query Items • Item name/tag (unique within request) • Item request 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.