Query+Health+Technical+Approach

include component="page" wikiName="siframework" page="Query Health Header"




 * This has been Consensus Approved by the community based on the Query Health Technical Approach Call for Consensus.**

This wiki page is to facilitate the discussion of the Query Health technical approach which will be used to guide the Query Health Technical WG activities to produce specifications, standards and build a robust Query Health Reference Implementation. Please provide feedback on this page through the discussion tab. toc

=1. Introduction= The Query Health Use Case describes the operational context, best practices, information interchange, system and dataset requirements for a generic and a “Expanded Analysis for Diabetic Care in Outpatient setting” user story. The Query Health Abstract Model defines technical concepts, terms and their definitions that facilitate the interactions outlined by the Query Health Use Case.

The goal of the technical approach document is to identify the following = = =2. Scope= The scope of this document is to identify and provide an overview of the Query Health specifications and standards and the components that will be used as a starting point to build the reference implementation.This document, when consensus approved sets the direction for the work group activities over the next few months.
 * Query Health specifications and standards that will promote interoperability among Query Health Network participants
 * Architecture Layers and Components that will lead to building a robust Query Health Reference Implementation that conforms to the Query Health specifications and standards while retaining the required flexibility to extend it for purposes beyond the prioritized pilot user stories.

This document does not describe each specification in complete detail, nor does it describe all the design and implementation details of the reference implementation. New artifacts will be created to describe and document these details as the work group activities progress.

The rest of the document provides an overview of the Query Health specifications, standards and reference implementation. = = =3. Query Health specifications and standards= The objective of Query Health specifications is to promote interoperability between Query Network participants facilitating query requests and returning results. The specifications are based on proven existing implementations of query networks along with standards that are being adopted for population based queries and results. In order to determine what aspects of the Query Networks should be standardized for interoperability the following viewpoints are considered:

**//Information Requestor viewpoint: //** From an Information Requestor’s viewpoint the ability to express queries and expect results in a standardized manner is a critical need. Standardizing the query and results formats allows the Information Requestor to be agnostic to the responding organization’s technologies which are executing the queries and creating the results. This calls for declarative standards such as XML as opposed to procedural standards such as SQL or JavaScript.

**//Responding Organizations viewpoint: //** From a Responding Organization’s viewpoint the ability to use technologies and implementations of choice is critical. The standardization of query and results formats will provide this independence to the organization. In addition the Responding Organization retains control over execution of the query and releasing of results which calls for appropriate level of metadata to be packaged in a standardized manner to facilitate the required decision making without relying on the details of the actual query and its formats.

**//Information Requestor and Responding Organization common viewpoints: //** For both Information Requestors and Responding Organizations to meaningfully execute the query and return results, a common understanding of the data that is being queried is essential. This is facilitated by standardizing the data element definitions across all the Query Network participants so that Information Requestors can use these definitions to compose queries and Responding Organizations use it to execute the queries and compute the required results.

Based on the above viewpoints the Query Health targeted areas for standardization are shown in the diagram below.



The Query Health specifications and standards based on the above targeted areas are further defined in the table below:



3.1 Query Envelope Specification
<span style="display: block; font-family: 'Arial','sans-serif'; font-size: 13.3333px; text-align: justify;">The Query Envelope specification describes the data and formats associated with packaging the queries and results. In addition to the packaging constructs, the required metadata for security and policy enforcement will be detailed in the specification.

**//<span style="font-family: 'Arial','sans-serif'; font-size: 13.3333px;">Note: The details of the actual specification will be captured in a different document through continuing work group activities. //**

3.2 Query Format Specification
<span style="display: block; font-family: 'Arial','sans-serif'; font-size: 13.3333px; text-align: justify;">The Query Format specification identifies the common minimum query format for expressing a large majority of queries across Query Health implementations. This specification will capture the following:
 * <span style="font-family: 'Arial','sans-serif'; font-size: 13.3333px;">Link to the base HQMF specifications
 * <span style="font-family: 'Arial','sans-serif'; font-size: 13.3333px;">Identify the list of changes required to the base specifications to create the Modified version of HQMF that is more conducive to query expressions and translations to implementation languages.
 * <span style="font-family: 'Arial','sans-serif'; font-size: 13.3333px;">Identify the list of constraints that need to be levied on HQMF
 * <span style="font-family: 'Arial','sans-serif'; font-size: 13.3333px;">Identify best practices to translate HQMF to implementation / procedural representation.
 * <span style="font-family: 'Arial','sans-serif'; font-size: 13.3333px;">Identify the types of queries that can be represented in HQMF with examples.
 * <span style="font-family: 'Arial','sans-serif'; font-size: 13.3333px;">Identify the types of queries that are difficult to represent with HQMF constructs.

**//<span style="font-family: 'Arial','sans-serif'; font-size: 13.3333px;">Note: The details of the actual specification will be captured in a different document through continuing work group activities. //**

3.3 Results Format Specification
<span style="display: block; font-family: 'Arial','sans-serif'; font-size: 13.3333px; text-align: justify;">The Results Format specification identifies the common minimum results format for expressing a large majority of results across Query Health implementations. This specification will capture the following:
 * <span style="font-family: 'Arial','sans-serif'; font-size: 13.3333px;">Link to the base QRDA specifications
 * <span style="font-family: 'Arial','sans-serif'; font-size: 13.3333px;">Identify the list of changes required to the base specifications
 * <span style="font-family: 'Arial','sans-serif'; font-size: 13.3333px;">Identify the list of constraints that need to be levied on QRDA Category III Report
 * <span style="font-family: 'Arial','sans-serif'; font-size: 13.3333px;">Identify sample result sets that can be represented using QRDA Category III Report with examples.
 * <span style="font-family: 'Arial','sans-serif'; font-size: 13.3333px;">Identify the limitations of QRDA Category III Report with examples.

**//<span style="font-family: 'Arial','sans-serif'; font-size: 13.3333px;">Note: The details of the actual specification will be captured in a different document through continuing work group activities. //**

3.4 Data Element Specification
The Data Element specification will capture the required details about data elements that are required to express queries and compute results in a consistent, interoperable manner across organizations. The Data Element specification will capture these elements in an implementation independent manner. The Data Element specification will capture the following:
 * Query Health Data Element Definitions that will be available for queries.
 * Vocabularies/Code Systems to be used along with the Data Element definitions
 * Value Sets to be used along with the Data Element definitions.
 * Concept to Code Mapping best practices and Concept to Code Maps for widely used concepts in Query Health Initiative.

<span style="font-family: 'Calibri','sans-serif'; font-size: 14.6667px;">The data element definitions activity at a minimum will capture the information shown in the table below. The elements shown in the table are just an example and is not a comprehensive list.
 * **Element Group** || **Attributes** || **Definition** || **Portable Data Types** || **Examples** || **Relationship to other Element Groups** || **Cardinality** ||
 * Patient ||  ||   ||   ||   ||   ||   ||
 * || Birth Date ||  ||   ||   ||   ||   ||
 * || Gender ||  ||   ||   ||   ||   ||
 * Medications ||  ||   ||   ||   ||   ||   ||
 * Encounter ||  ||   ||   ||   ||   ||   ||
 * Problem ||  ||   ||   ||   ||   ||   ||
 * Allergies ||  ||   ||   ||   ||   ||   ||

The Vocabularies/Code Systems that will be used to represent the various codes for each of the data elements. This activity at a minimum will capture the information shown in the table below. <span style="font-family: 'Calibri','sans-serif'; font-size: 14.6667px;">The elements shown in the table are just an example and is not a comprehensive list.
 * **Element Group** || **Attributes** || **Recommended CodeSystem** ||
 * Patient ||  ||   ||
 * || Birth Date ||  ||
 * || Gender ||  ||
 * Medications ||  ||   ||
 * Encounter ||  ||   ||
 * Problem ||  ||   ||
 * Allergies ||  ||   ||

The Value Sets to be used for Query Health will identify the exact values or will refer to existing Value Sets from other standards to describe the data elements and their attributes. This is shown in the table below which is just an example and is not a comprehensive list.
 * **Element Group** || **Attributes** || **Value Set adopted from SDO when applicable** || **Constraints on Value Set adopted from SDO when applicable** || **Actual Value Set values when it is not adopted from an existing standard** ||
 * Patient ||  ||   ||   ||   ||
 * || Birth Date ||  ||   ||   ||
 * || Gender ||  ||   ||   ||
 * Medications ||  ||   ||   ||   ||
 * Encounter ||  ||   ||   ||   ||
 * Problem ||  ||   ||   ||   ||
 * Allergies ||  ||   ||   ||   ||

The Concept to Code Maps will capture the following at a minimum:
 * Concept Name
 * Concept Definition
 * Code System Name (One or more)
 * Codes that are mapped to the above concept based on the Code System.

**//<span style="font-family: 'Arial','sans-serif'; font-size: 13.3333px;">Note: The details of the actual specification will be captured in a different document through continuing work group activities. //**

3.5 Abstract Model and Specifications Linkage
<span style="display: block; font-family: 'Arial','sans-serif'; font-size: 13.3333px; text-align: justify;">This section links the Query Health Abstract Model and it's interactions to the Query Health specifications. This mapping is shown in the figure below:



<span style="display: block; font-family: 'Arial','sans-serif'; font-size: 13.3333px; text-align: justify;">The next section discusses the Reference Implementation approach and components that have been identified as starting points for implementation of the above specifications. = = =4. Reference Implementation Approach= <span style="display: block; font-family: 'Arial','sans-serif'; font-size: 13.3333px; text-align: justify;">The Query Health Reference Implementation approach will leverage proven components from existing distributed query implementations comprising of i2B2, hQuery and PopMedNet along with standards translation components necessary to implement the identified specifications and promote interoperability. The components identified in the Reference Implementation approach are starting points for building a robust Reference Implementation. The components described and shown below are __not__ specifications and standards themselves but an implementation of the specifications and standards. This allows the community to build the Query Health Reference Implementation on proven robust components rather than start from a blank slate. In addition the Query Health specifications and standards are intended to be implemented by organizations independent of the Reference Implementation shown below.

<span style="display: block; font-family: 'Arial','sans-serif'; font-size: 13.3333px; text-align: justify;">A top level overview of the components leveraged from proven implementations is as shown in the diagram below:

<span style="display: block; font-family: 'Arial','sans-serif'; font-size: 13.3333px; text-align: justify;">

<span style="display: block; font-family: 'Arial','sans-serif'; font-size: 13.3333px; text-align: justify;">The Reference Implementation components are organized into 3 architecture layers:
 * <span style="font-family: 'Arial','sans-serif'; font-size: 13.3333px;">UX Layer:
 * <span style="font-family: 'Arial','sans-serif'; font-size: 13.3333px;">This layer primarily deals with composing queries and viewing results and consists of all the components above the Policy Enablement components in the above diagram.
 * <span style="font-family: 'Arial','sans-serif'; font-size: 13.3333px;">Policy Enablement Layer
 * <span style="font-family: 'Arial','sans-serif'; font-size: 13.3333px;">This layer deals with enforcing all the security requirements of the use case along with the requirements of the policy sandbox. The policy enablement components exist in both the requesting and the responding organizations and aid in enforcing the various security requirements and the policy sandbox requirements. Some of the functions performed by these components include identity verification, authorization of queries, results reviews; secure transport of queries and results.
 * <span style="font-family: 'Arial','sans-serif'; font-size: 13.3333px;">In addition to the policy enablement components, the layer also includes query orchestration component to facilitate periodic queries and aggregation capabilities to aggregate results.
 * Query Execution Layer
 * <span style="font-family: 'Arial','sans-serif'; font-size: 13.3333px;">This layer deals with running the queries against a data model and returning the results. The data model is an implementation of the Data Element Specification outlined above and may be implemented using different technologies. The Data Source integration approach is still under analysis and will require further elaboration as we move forward.

4.1 Reference Implementation Flexibility and Extension Points:
<span style="display: block; font-family: 'Arial','sans-serif'; font-size: 13.3333px; text-align: justify;">The Reference Implementation has the following flexibility built into it: = = =5. Summary= <span style="display: block; font-family: 'Arial','sans-serif'; font-size: 13.3333px; text-align: justify;">The above paragraphs identify the Query Health Technical Approach decisions and the starting point for the work group activities to build a robust set of specifications, standards and a reference implementation. <span style="display: block; font-family: 'Arial','sans-serif'; font-size: 13.3333px; text-align: justify;">In summary there are four targeted areas for standardization
 * <span style="font-family: 'Arial','sans-serif'; font-size: 13.3333px;">Allowing Native Formats to co-exist along with standards:
 * <span style="font-family: 'Arial','sans-serif'; font-size: 13.3333px;">As Query Health gets widely adopted there may be use cases which require queries and results which cannot be translated effectively into the Modified HQMF and QRDA Category III standards respectively. In these limited cases the native query and results formats of i2B2 and hQuery are available and can be used without requiring any changes. However the native formats of i2B2 and hQuery are not interoperable between each other.
 * <span style="font-family: 'Arial','sans-serif'; font-size: 13.3333px;">Allowing extensions to the data model:
 * <span style="font-family: 'Arial','sans-serif'; font-size: 13.3333px;">The Query Health Data Element specification will identify the initial set of data elements, vocabularies, value sets and concept to code maps that are needed to support the prioritized user stories. However as the Query Health Reference Implementation gets adopted widely it is envisioned that the data model will grow and new data elements will be added. Towards this end the STAR schema representation and JSON representation of the Data Element specification provide flexible ways of extending the implementation with minimum side effects.
 * 1) <span style="display: block; font-family: 'Arial','sans-serif'; font-size: 13.3333px; text-align: justify;">Query Envelope to package queries, results of different formats along with the metadata required for security and policy enforcement.
 * 2) <span style="display: block; font-family: 'Arial','sans-serif'; font-size: 13.3333px; text-align: justify;">Query Format to express queries in a declarative format
 * 3) <span style="display: block; font-family: 'Arial','sans-serif'; font-size: 13.3333px; text-align: justify;">Results Format to express results in a declarative format
 * 4) <span style="display: block; font-family: 'Arial','sans-serif'; font-size: 13.3333px; text-align: justify;">Common Data element definitions that facilitate queries across organizations


 * Note 1:** Patient Consent is not applicable to Query Health use cases. (Aggregated patient information or public health use cases). This has been confirmed with the ONC Privacy Office.

**Note 2:** Neither HQMF nor QRDA category III can be used “as is” for Query Health. We will investigate the feasibility of revising these specifications to make them suitable for distributed population query execution. Success of this investigation is a baseline requirement to use modified versions of HQMF and QRDA category III as the basis for queries and their results.

<span style="display: block; font-family: 'Arial','sans-serif'; font-size: 13.3333px; text-align: justify;">The Reference Implementation will be built using <span style="display: block; font-family: 'Arial','sans-serif'; font-size: 13.3333px; text-align: justify;">Ongoing work group activities will be organized into parallel work streams based on the above technical approach once this gets consensus approved. = = =6. References= >>
 * <span style="font-family: 'Arial','sans-serif'; font-size: 13.3333px;">PopMedNet
 * <span style="font-family: 'Arial','sans-serif'; font-size: 13.3333px;">i2B2
 * <span style="font-family: 'Arial','sans-serif'; font-size: 13.3333px;">hQuery and
 * <span style="font-family: 'Arial','sans-serif'; font-size: 13.3333px;">standards translation work accomplished by the community.
 * 1) <span style="font-family: 'Arial','sans-serif'; font-size: 13.3333px;">I2B2 - []
 * 2) <span style="font-family: 'Arial','sans-serif'; font-size: 13.3333px;">hQuery – []
 * 3) <span style="font-family: 'Arial','sans-serif'; font-size: 13.3333px;">PopMedNet - []
 * 4) <span style="font-family: 'Arial','sans-serif'; font-size: 13.3333px;">Standards Translation Work from Keith Boone: []
 * 5) []
 * 6) []
 * 7) []
 * 8) []
 * 9) []
 * 10) []
 * 11) <span style="font-family: 'Calibri','sans-serif'; font-size: 14.6667px;">[]
 * 12) []
 * 13) []
 * 14) []
 * 15) []
 * 16) []
 * 17) []
 * 18) []
 * 19) []
 * 20) []
 * 1) <span style="font-family: 'Arial','sans-serif'; font-size: 13.3333px;">HQMF – []
 * 2) <span style="font-family: 'Arial','sans-serif'; font-size: 13.3333px;">QRDA - []

include component="page" wikiName="siframework" page="space.template.inc_contentleft_end"