Data Element Based Query for Clinical Health Information

Type	Standard / Implementation Specification	Standards Process Maturity	Implementation Maturity	Adoption Level	Federally required	Cost	Test Tool Availability
Standard	HL7® FHIR® RESTful API	Final	Production		Yes	Free	Yes
Implementation Specification	FHIR Bulk Data Access Implementation Guide	Final	Production	Feedback Requested	Yes	Free	Yes – Open
Implementation Specification	HL7 FHIR DaVinci Payer Data Exchange (PDex) Implementation Guide	Balloted Draft	Production		No	Free	No
Implementation Specification	HL7 FHIR DaVinci Clinical Data Exchange (CDex) Implementation Guide	Balloted Draft	Pilot		No	Free	No
Implementation Specification	HL7 FHIR DaVinci Payer Health Record Exchange (HRex) Implementation Guide	Balloted Draft	Pilot		No	Free	No
Implementation Specification	HL7 FHIR US Core Implementation Guide STU 4.0.0	Final	Production	Feedback Requested	No	Free	Yes
Implementation Specification	HL7 FHIR Bulk Data Access (Flat FHIR) (v2.0.0 STU 2)	Final	Production	Feedback Requested	No	Free	Yes
Implementation Specification	HL7 FHIR US Core Implementation Guide STU 5.0.1	Final	Production	Feedback Requested	No	Free	Yes
Emerging Implementation Specification	IHE Mobile Cross-Enterprise Document Data Element Extraction (mXDE) Profile	Balloted Draft	Pilot	Feedback Requested	No	Free	No
Emerging Implementation Specification	IHE Query for Existing Data for Mobile (QEDm)	Balloted Draft	Pilot	Feedback Requested	No	Free	No

Limitations, Dependencies, and Preconditions for Consideration	Applicable Security Patterns for Consideration
The reference to FHIR for this interoperability need is in relation to the transport services that are conformant to the “RESTful FHIR API” Note that the maturity level of FHIR resources may vary. The FHIR Maturity Model and each of the levels is described on the HL7 wiki. The combination of mXDE and QEDm provide for Provenance evidence between the FHIR Resources made available via QEDm and the documents from which that data was decomposed. In this way the client application using FHIR Resource data can ask for Provenance. For each Provenance record given there is a unique document that contained that information. Thus the client can know how many documents stated the medical information, and can navigate to those documents. See IHE whitepaper section consuming data as FHIR resources. The HL7 FHIR Bulk Data Access (Flat FHIR) (v2.0.0: STU 2) is a newer version of the standard that is available for health IT developers to voluntarily update and provide to their customers. It became available when it was added to the Approved Standards for 2022 through ONC’s Standards Version Advancement Process (SVAP). The HL7 FHIR US Core Implementation Guide STU 4.0.0 is a newer version of the standard that is available for health IT developers to voluntarily update and provide to their customers. It became available when it was added to the Approved Standards for 2022 through ONC’s Standards Version Advancement Process (SVAP). The HL7 FHIR US Core Implementation Guide STU 5.0.1 is a newer version of the standard that is available for health IT developers to voluntarily update and provide to their customers. It became available when it was added to the Approved Standards for 2022 through ONC’s Standards Version Advancement Process (SVAP).	System Authentication – The information and process necessary to authenticate the systems involved. User Details – Identifies the end user who is accessing the data. User Role – Identifies the role asserted by the individual initiating the transaction. Purpose of Use – Identifies the purpose for the transaction. Patient Consent Information – Identifies the patient consent information that may be required before data can be accessed. May be required to authorize any exchange of patient information. May be required to authorize access and use of patient information. May be required to be sent along with disclosed patient information to advise the receiver about policies to which end users must comply. Security Labeling – The health information is labeled with security metadata necessary for access control by the end user. Query Request ID – Query requesting application assigns a unique identifier for each query request in order to match the response to the original query.

Limitations, Dependencies, and Preconditions for Consideration

Applicable Security Patterns for Consideration

The reference to FHIR for this interoperability need is in relation to the transport services that are conformant to the “RESTful FHIR API”
Note that the maturity level of FHIR resources may vary. The FHIR Maturity Model and each of the levels is described on the HL7 wiki.
The combination of mXDE and QEDm provide for Provenance evidence between the FHIR Resources made available via QEDm and the documents from which that data was decomposed. In this way the client application using FHIR Resource data can ask for Provenance. For each Provenance record given there is a unique document that contained that information. Thus the client can know how many documents stated the medical information, and can navigate to those documents. See IHE whitepaper section consuming data as FHIR resources.
The HL7 FHIR Bulk Data Access (Flat FHIR) (v2.0.0: STU 2) is a newer version of the standard that is available for health IT developers to voluntarily update and provide to their customers. It became available when it was added to the Approved Standards for 2022 through ONC’s Standards Version Advancement Process (SVAP).
The HL7 FHIR US Core Implementation Guide STU 4.0.0 is a newer version of the standard that is available for health IT developers to voluntarily update and provide to their customers. It became available when it was added to the Approved Standards for 2022 through ONC’s Standards Version Advancement Process (SVAP).
The HL7 FHIR US Core Implementation Guide STU 5.0.1 is a newer version of the standard that is available for health IT developers to voluntarily update and provide to their customers. It became available when it was added to the Approved Standards for 2022 through ONC’s Standards Version Advancement Process (SVAP).

System Authentication – The information and process necessary to authenticate the systems involved.
User Details – Identifies the end user who is accessing the data.
User Role – Identifies the role asserted by the individual initiating the transaction.
Purpose of Use – Identifies the purpose for the transaction.
Patient Consent Information – Identifies the patient consent information that may be required before data can be accessed.
- May be required to authorize any exchange of patient information.
- May be required to authorize access and use of patient information.
- May be required to be sent along with disclosed patient information to advise the receiver about policies to which end users must comply.
Security Labeling – The health information is labeled with security metadata necessary for access control by the end user.
Query Request ID – Query requesting application assigns a unique identifier for each query request in order to match the response to the original query.

Comment

Submitted by mbkurilo@immre… on 2023-10-06

AIRA Comments on Bulk FHIR

AIRA appreciates this thorough review of standards related to bulk FHIR; we are currently partnering with the Helios FHIR Accelerator project to explore use of bulk FHIR query for immunizations, so this is helpful as we work toward implementation.

Submitted by John Moehrke on 2021-09-08

mXDE + QEDm = Provenance

The combination of mXDE and QEDm provide for Provenance evidence between the FHIR Resources made available via QEDm and the documents from which that data was decomposed. In this way the client application using FHIR Resource data can ask for Provenance. For each Provenance record given there is a unique document that contained that information. Thus the client can know how many documents stated the medical information, and can navigate to those documents.

see IHE whitepaper section https://profiles.ihe.net/ITI/HIE-Whitepaper/index.html#4-consuming-data-as-fhir-resources

Submitted by juliemaas on 2019-09-23

UDAP for Client App Registration, Authentication & Authorization

Since FHIR transactions require the use of a FHIR client, client application registration and management is an integral component of query using FHIR. With regards to system authentication for this use case, UDAP Dynamic Client Registration provides an extension to RFC 7591 to better scale the registration and use of FHIR client apps. This profile has seen interest from numerous industry stakeholders as an alternative to manually re-registering apps at every different datasource and as a way to enable sharing of information about apps among datasources. Trusted Dynamic Client Registration provides a path for verification of attributes for apps holding valid digital certificates and the communication of these attributes (e.g. privacy policy) to the end user, increasing confidence in valid FHIR clients within the ecosystem and facilitating the connection of apps to clinical FHIR servers without manual pre-registration. This can be used together with UDAP JWT-based Client Authentication to support reusable client identity for authentication and authorization, to help scale the use of client credentials or authorization code flow, and UDAP JWT-based Client Authorization Grants can be used to transmit Purpose of Use and Consent Information.

UDAP is an open collaborative developing profiles to increase scalability, confidence, security, and trust in Open API ecosystems, and allows the re-use of identity proofing and credentialing processes already in place in existing national health information networks. These profiles are in draft status and are in pilot stage. UDAP DCR and Authentication/Authorization have been tested successfully at several HL7 FHIR connectathons and have received positive feedback from multiple stakeholders, including national health information networks, EHR vendors, patient privacy rights advocates, and app developers. These profiles are also compatible with SMART App Launch and UMA.

We recommend that this be listed as a separate interoperability need sub-section of Query or possibly as a new top-level entry in Section III (e.g. Client Application Management), as it potentially overlaps with many of the other existing sub-sections where FHIR is used, including Query, Consumer Access, and Push.

Julie Maas, CEO, EMR Direct

Submitted by juliemaas on 2022-09-30

UDAP for Client App Registration, Authentication & Authorization

This work has now been jointly published by UDAP.org and HL7. The Security for Scalable Registration, Authentication, and Authorization (UDAP Security - http://hl7.org/fhir/us/udap-security/) Business-to-Business workflow is therefore recommended for use in this type of exchange; it is an Emerging Implementation Specification for securely scaling FHIR transactions by validating trusted ecosystem endpoints.