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

Status of this Specification

This specification is now Consensus Approved.

IPR Statement


By contributing to this specification, all contributors warrant that all applicable patient or other intellectual policy rights have been disclosed and that any of which contributors are aware of will be disclosed in accordance with the S&I Framework IPR Policy.

Abstract

The Query Envelope specification documents a standard set of requirements and data elements required to facilitate secure exchange of queries and results without constraining business workflows or technical implementation platforms. Additionally, the specification is developed to be agnostic towards query formats, result formats and the repositories that house the data.
An implementation of the Query Envelope specification is necessary within a Query Network to facilitate secure information exchange between Information Requestors and Responding Organizations according to their business workflows and enable the HIT Policy Committee and Tiger Team Recommendations for ONC sponsored Query Health Pilots.

1. Introduction


1.1 Purpose

The goal for the Query Envelope specification is to develop a standard set of requirements and data elements to facilitate the secure exchange of queries and results without constraining business workflows or technical implementation platforms. The requirements and data elements are developed to be agnostic towards query formats, result formats and the repositories that house the data.
An implementation of the Query Envelope specification is necessary within a Query Network to facilitate secure information exchange between Information Requestors and Responding Organizations according to their business workflows and enable the HIT Policy Committee and Tiger Team Recommendations for ONC sponsored Query Health Pilots.The Query Envelope specification does not constrain the technologies or the technical platforms that may be used to implement the requirements and the data structures.


1.2 Requirements Key Words

The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL”, in this document are to be interpreted as described in RFC 2119.
An implementation is not compliant if it fails to satisfy one or more of the MUST or REQUIRED level requirements for the Query Envelope. An implementation that implements all the MUST or REQUIRED level and all the SHOULD level requirements for the Query Envelope is said to be “unconditionally compliant”; one that satisfies all the MUST or REQUIRED level requirements but not all the SHOULD level requirements for the Query Envelope is said to be “conditionally compliant”.


1.3 Query Envelope Context

The Query Envelope is used to transfer queries and results and the figure below provides an overview of the Query Envelope organization. As shown in the figure below the Query Envelope encompasses the Query Request or Query Result information which includes the appropriate metadata along with the payload.
The Query Envelope specification describes the Query Request and Query Result Metadata elements and is agnostic to the details of the Query and Result payload.

1.4 Terminology References

The terms Query Network, Information Requestor, Responding Organization etc used in this specification are defined by the Query Health Abstract Model.
The data types integer, string, dateTime and other data types used in this specification are defined by W3C XML Schema Data Types Second Edition.


Query_Envelope_v2.jpg


The next couple of sections detail the requirements for the Query Envelope along with the Query Request and Query Result Metadata elements.


1.5 Generic Query Envelope Requirements

The Query Envelope MUST contain either Query Request Information or Query Result Information.
The Query Envelope MAY contain multiple Query Request Information entities as part of a single Query Envelope.
The Query Envelope MAY contain multiple Query Result Information entities as part of a single Query Envelope.

1.6 Query Request Metadata Information

A Query Envelope conveying Query Request is described by the Query Request Metadata elements. These elements along with their requirements are described in the next few sub-sections.

1.6.1 Query Identification

The query identification information is used to associate queries with results within a Query Network.
  • Each Query Request MUST contain a Query Id which is a unique identifier within the Query Network.
    • Data Type: string.
    • Constraints: The Query Id format MUST conform to RFC2392 Message Id ("mid:") scheme.

  • Each Query Request SHOULD contain a name associated with the query.
    • Data Type: string
    • Constraints: Length Minimum: 1 character. Length Maximum: 100 characters.

1.6.2 Information Requestor Identification

The Information Requestor information can be used by organizations for the general purpose of communications, alert and event notifications.
  • Each Query Request MUST contain the following attributes related to the Information Requestor.
      • Email Address of the Information Requestor
        • DataType: string
        • Constraints:Email address MUST conform to the format described by addr-spec requirements of RFC 5322.

  • Each Query Request SHOULD contain have the following attributes related to the Information Requestor.
    • Requestor’s Name
      • This can be associated with a person or a electronic system.
      • DataType: string
      • Constraints: Length Minimum: 1 Character: Length Maximum: 100 characters.

    • Organization Name
      • The name of the Requestor’s organization.
      • DataType: string
      • Constraints:Length Minimum: 1 Character: Length Maximum: 100 characters.


1.6.3 Query Purpose and Priority

The Query purpose and priority are used by reviewers and responders to understand the details of the query in terms of it’s purpose and priority.

  • Each Query Request MUST contain a "PurposeOfUse" code to indicate the purpose of the query
    • DateType: string
    • Constraints: The "PurposeOfUse" code MUST contain values from the value set {TREAT, HPAYMT, HOPERAT, HRESCH, HMARKT, PATRQT, PUBHLTH} which are derived from HL7 value set 2.16.840.1.113883.1.11.20449

  • Each Query Request SHOULD contain a “Description” to describe the purpose of the query.
    • DataType: string
    • Constraints:Length Minimum: 1 Character: Length Maximum: 500 characters.

  • Each Query Request MAY contain a “Priority” to describe the priority of the query.
    • DataType: integer
    • Constraints: Priority must contain values in the value set {1, 2, 3, 4, 5}. A value of 1 indicates highest priority and 5 indicates lowest priority for a data source to execute the query.

1.6.4 Query Type

The Query type information is useful to the organizations to select data sources, enforce policies regarding query execution and returning of results.

Each Query Request MUST contain the following attributes:
  • Query Format
    • DataType: string
    • Constraints:Length Minimum: 1 Character: Length Maximum: 30 characters
      • For Interoperable queries, Query Format MUST contain the value "application/HQMF+xml".
      • Note: Once the above string gets registered with IANA following RFC4288 which is in progress, then this particular data element will be changed to become a Media Type per RFC4288.

  • Level of PHI Disclosure
    • DataType: string
    • Constraints:Level of PHI Disclosure MUST contain values from the value set {Aggregated, Limited, De-identified, PHI}

1.6.5 Query Timing

The query timing information can be used to track and audit when queries were executed and request queries to be executed on an older snapshot of data.

Each Query Request MUST contain the following:
  • Query submission timestamp.
    • DataType: dateTime

Each Query Request MAY contain the following
  • Data Snapshot timestamp for Query Execution.
    • Date Type: dateTime
    • The purpose of this attribute it to comply with operational audit/follow-up requirements where a query might have to be re-run using the data that was present at the time the query was executed originally.
      • When this attribute is present with a valid time, the organization that owns the data source has to ensure that the data available for query represents the data that was available as indicated by the timestamp.
      • Some of the implementation options that organizations may pursue to meet this requirement are:
        • Roll back the database to the closest available backup and then re-run the query as required. Although this may not be technically a mirror of what was present, this is a close approximation.
        • Maintain a history of all database changes and exclude changes after the snapshot timestamp from the query. This could create performance issues and increase storage capacity.

1.7 Query Payload

The query payload contains the query that needs to be executed on a data source.

Each Query Request MUST contain a query payload.
  • The type of the payload is designated using the media type "application/octet-stream" which allows implementations to choose binary, text or other formats to package the payload.

1.8 Query Result Metadata Information

A Query Envelope conveying Query Result is described by the following data elements and requirements.

1.8.1 Result Identification

The result identification information is used to associate queries with results across the network.
  • Each Result Response MUST contain a reference to the Query Request Metadata Information for which the results are being sent.
    • The query request reference contained is the entire Query Request Metadata as shown in the diagram above to facilitate effective request response correlation.

  • Each Result Response MUST contain a Response Id which is unique within the Responding Organization.
    • Data Type: string.
    • Constraints: The Response Id format MUST conform to RFC2392 Message Id ("mid:") scheme.

1.8.2 Data Source Identification

The Data Source information can be used by organizations for the general purpose of communications, alert and event notifications.
  • Each Result Response MUST contain the following attributes related to the Data Source.
    • Data Source Id which is unique within an Organization’s Facility.
      • DataType: string
      • Constraints:Length Minimum: 1 Character: Length Maximum: 100 characters.
    • Data Source Name
      • DataType: string
      • Constraints:Length Minimum: 1 Character: Length Maximum: 100 characters.
    • Facility Id which is unique within an Organization.
      • DataType: string
      • Constraints:Length Minimum: 1 Character: Length Maximum: 100 characters.
    • Facility Name
      • DataType: string
      • Constraints:Length Minimum: 1 Character: Length Maximum: 100 characters.
    • Organization Id
      • DataType: string
      • Constraints:Length Minimum: 1 Character: Length Maximum: 100 characters.
    • Organization Name which is unique within the Query Network.
      • DataType: string
      • Constraints:Length Minimum: 1 Character: Length Maximum: 100 characters.

1.8.3 Result Status

The result status information is used by reviewers, responders and requestors to understand the details of the results, its status and usability.
  • Each Result Response MUST contain the following attributes
    • Status value
      • DataType: string
      • Constraints:Status MUST contain values from the value set {Approved, NotApproved, Rejected, Pending Approval, InProgress, Complete, Deferred}
    • Status Change Timestamp
      • This indicates the time when the status change occurred.
      • DataType: dateTime
    • Email Address of the Contact
      • DataType: string
      • Constraints:Email address MUST conform to the format described by addr-spec requirements of RFC 5322.

  • Each Result Response SHOULD contain the following attributes
    • Notes
      • DataType: string
    • Error Message
      • DataType: string

1.8.4 Result Type

The Result type information is useful to the organizations to interpret results and enforce policies on the returned results.

Each Result Response MUST contain the following attributes:
  • Result Format
    • DataType: string
    • Constraints:Length Minimum: 1 Character: Length Maximum: 30 characters
      • For Interoperable queries, Result Format MUST contain the value "application/QRDA+xml".
      • Note: Once the above string gets registered with IANA following RFC4288 which is in progress, then this particular field will be changed to become a Media Type per RFC4288.
  • Confidentiality Code
    • DateType: string
    • Constraints: Confidentiality Code MUST contain values from the value {L,M,N,R,U,V} which are derived from HL7 Confidentiality Code Value Set 2.16.840.1.113883.1.11.10228 and represent the values Low, Moderate, Normal, Restricted, Unrestricted and Very Restricted respectively.
  • Level of PHI Disclosure
    • DataType: string
    • Constraints: Level of PHI Disclosure MUST contain values from the value set {Aggregated, Limited, De-identified, PHI}

Each Result Response MAY contain the following attributes
  • Obligation Code
    • DataType: string
    • Constraints: Obligation Code MUST contain values from the HL7 Obligation Policy value set 2.16.840.1.113883.1.11.20445
  • Refrain Code
    • DataType: string
    • Constraints: Refrain Code MUST contain values from the HL7 Obligation Policy value set 2.16.840.1.113883.1.11.20446

  • Result Usage Notes Text
    • DataType: string


1.8.5 Result Timing

The result timing information can be used to track and audit when final results were returned

Each Result Response MUST contain the following:
  • Final Result Response timestamp.
    • DataType: dateTime

1.9 Result Payload

The result payload contains the exact result that needs to be returned to the information requestor..

Each Result Response MAY have a result payload.
  • The type of the payload is designated using the media type "application/octet-stream" which allows implementations to choose binary, text or other formats to package the payload.

1.10 Query Envelope Transport Requirements

Every Query Network is operated using a Data Use Agreement and is open only to the participants who are willing to participate in the Query Network. As a result, the Query Network establishes a Trust circle with the organizations participating. All the requirements below are levied on top of the Query Network business and data use agreements.

  • The Query Envelope Transport mechanism used between the Information Requestor and Responding Organization MUST protect the Confidentiality and Integrity of the data during transit.
    • Common mechanisms used to meet this requirement include
      • Two way TLS transport session between the Requesting Agent and the Responding Agent when exchanging information
      • Message Encryption between the Requesting Agent and the Responding Agent when exchanging information.

1.11 Query Envelope Authentication and Authorization Requirements

The query envelope authentication and authorization requirements specify how identities are validated between Information Requestors and Responding Organizations and further define the requirements which allow Data Sources to control authorization of individual queries and responses.
  • The Requesting Agent and Responding Agent MUST validate mutual identity before exchanging any queries or results.
    • X.509 is a common mechanism used to validate mutual identity.

  • The Data Source MUST be able to authorize queries by
    • Organization or Entity Level information
      • For example a Data Source might decide to approve queries from organization A but not from organization B.
    • Individuals belonging to an Organization
      • For example a Data Source might decide to allow User A to query the data but not User B where User's A and B are part of the same organization.

  • The Data Source MUST provide mechanisms to configure authorization of Query Requests to be either Automatic or Manual.
    • Automatic authorization allows queries to be received and executed by the data source without any manual intervention.
    • Manual authorization allows review of the queries before executing them and a review of the results before returning them back to the Information Requestor. The Manual review process can ensure that small cell results are not disclosed in-appropriately. The Reference Implementation might choose to provide additional features to automate the blurring of small cell results and still perform automatic authorization.


2 Appendix:

2.1 Implementation Guidance: (Query Envelope Schema and Structure)

This section is an example showing an XML structure of a query envelope which can be leveraged by organizations if required. This schema is not normative.

Query Envelope Schema Sample_v2.xsd

2.2 HL7 Value Sets Used:

The Query Envelope Schema Sample.xsd attached above has the values from the referenced HL7 value sets for the purposes of Query Health Initiative.

2.3 Query Envelope Security Risk Analysis

The Query Envelope Security Risk Analysis was conducted using the same process as currently used by HL7 and IHE.
The risks analysis spreadsheets identifies the current risks and mitigation strategies that organizations should consider when implementing Query Envelope Specifications and Standards based on their use cases.

2.3.1 Risk Analysis for Use Cases expecting Aggregated data as results:



2.3.2 Risk Analysis for Use Cases expecting Non-Aggregated data as results:



2.3.3 Consolidated Risk Analysis for all use cases:



2.4 References

  1. Message Id Scheme: http://www.ietf.org/rfc/rfc2392.txt
  2. MediaTypes and Registration:http://tools.ietf.org/html/rfc4288
  3. Email Addresses:http://tools.ietf.org/html/rfc5322
  4. X.509 certificates: http://www.ietf.org/rfc/rfc2459.txt
  5. Requirement Keyworkds: http://tools.ietf.org/html/rfc2119
  6. TLS Protocol:http://tools.ietf.org/html/rfc5246
  7. I2B2 - https://www.i2b2.org/
  8. hQuery – http://github.com/hquery
  9. PopMedNet - http://www.popmednet.org
  10. X.509: http://www.ietf.org/rfc/rfc2459.txt
  11. Security Analysis Background Material:http://healthcaresecprivacy.blogspot.com/2010/02/how-to-write-secure-interoperability.html