Workgroups



This Week's Agenda




Who's Tweeting about QH?




How to Get Involved

  • Keep me Informed
    • To be notified about significant events and announcements from the project, follow this site
  • How can I contribute?
  • Add my organization as an official member

Edit SidebarRight

Edit PageTabs

QHhome.pngQH_Launch_Blue.pngQHsignup.pngQHimplementationgroup.pngOperations_WG.pngQHclinical.png

QHtechnical_HL.pngWiki_Button_Query_Health_Pilots_Blue.pngWiki_Button_Blue_Reference_Implementation.pngWiki_Button_Query_Health_Standards.pngQHinthenews.pngQHreference.jpg


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.























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
  • 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.

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.

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.

StandardsContext.jpg

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

Standards_1.jpg



3.1 Query Envelope Specification

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.

Note: The details of the actual specification will be captured in a different document through continuing work group activities.

3.2 Query Format Specification

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:
  • Link to the base HQMF specifications
  • 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.
  • Identify the list of constraints that need to be levied on HQMF
  • Identify best practices to translate HQMF to implementation / procedural representation.
  • Identify the types of queries that can be represented in HQMF with examples.
  • Identify the types of queries that are difficult to represent with HQMF constructs.

Note: The details of the actual specification will be captured in a different document through continuing work group activities.

3.3 Results Format Specification

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:
  • Link to the base QRDA specifications
  • Identify the list of changes required to the base specifications
  • Identify the list of constraints that need to be levied on QRDA Category III Report
  • Identify sample result sets that can be represented using QRDA Category III Report with examples.
  • Identify the limitations of QRDA Category III Report with examples.

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.

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.
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.

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

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:

Abstract_Model_and_Specificatioons.jpg


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

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.

A top level overview of the components leveraged from proven implementations is as shown in the diagram below:


RI_Components_Overview_1.jpg


The Reference Implementation components are organized into 3 architecture layers:
    • UX Layer:
      • 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.
    • Policy Enablement Layer
      • 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.
      • 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
      • 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:

The Reference Implementation has the following flexibility built into it:
  • Allowing Native Formats to co-exist along with standards:
    • 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.
    • Allowing extensions to the data model:
      • 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.

5. Summary

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.
In summary there are four targeted areas for standardization
  1. Query Envelope to package queries, results of different formats along with the metadata required for security and policy enforcement.
  2. Query Format to express queries in a declarative format
  3. Results Format to express results in a declarative format
  4. 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.

The Reference Implementation will be built using
  • PopMedNet
  • i2B2
  • hQuery and
  • standards translation work accomplished by the community.
Ongoing work group activities will be organized into parallel work streams based on the above technical approach once this gets consensus approved.

6. References

  1. I2B2 - https://www.i2b2.org/
  2. hQuery – http://github.com/hquery
  3. PopMedNet - http://www.popmednet.org/
  4. Standards Translation Work from Keith Boone: http://motorcycleguy.blogspot.com/
    1. http://motorcycleguy.blogspot.com/2011/10/siframework-face-to-face-update-on.html
    2. http://motorcycleguy.blogspot.com/2011/10/declarative-vs-procedural-and.html
    3. http://motorcycleguy.blogspot.com/2011/11/value-sets-and-queryhealth.html
    4. http://motorcycleguy.blogspot.com/2011/11/putting-together-pieces-for-queryhealth.html
    5. http://motorcycleguy.blogspot.com/2011/11/when-xml-sucks.html
    6. http://motorcycleguy.blogspot.com/2011/11/hl7-hqmf-proof-of-concept-with-hquery.html
    7. http://motorcycleguy.blogspot.com/2011/11/implementing-queryhealth-on-collection.html
    8. http://motorcycleguy.blogspot.com/2011/11/models-for-query-health.html
    9. http://motorcycleguy.blogspot.com/2011/11/sql-implementation-for-queryhealth.html
    10. http://motorcycleguy.blogspot.com/2011/11/implementing-min-max-first-and-most.html
    11. http://motorcycleguy.blogspot.com/2011/11/summary-computations-and-hqmf.html
    12. http://motorcycleguy.blogspot.com/2011/11/classifying-results-in-hqmf.html
    13. http://motorcycleguy.blogspot.com/2011/11/greening-hqmf.html
    14. http://motorcycleguy.blogspot.com/2011/11/loading-i2b2-from-cda-documents.html
    15. http://motorcycleguy.blogspot.com/2011/12/visualizing-criteria-hqmf-document.html
    16. http://motorcycleguy.blogspot.com/2011/12/some-principals-for-creating-hqmf.html

  5. HQMF – http://www.hl7.org/dstucomments/
  6. QRDA - http://www.hl7.org/dstucomments/