View, Download, and Transmit Data from EHR

Type	Standard / Implementation Specification	Standards Process Maturity	Implementation Maturity	Adoption Level	Federally required	Cost	Test Tool Availability
Implementation Specification	Direct (Applicability Statement for Secure Health Transport v1.2)	Final	Production		Yes	Free	Yes
Standard	Current Procedural Terminology (CPT) Consumer Friendly Descriptors (CFDs)	Final	Production		Yes	$
Standard	HL7® FHIR® RESTful API	Final	Production		Yes	Free	Yes
Implementation Specification	UDAP Implementation Guide for Registration and Authorization of Consumer Facing Health Apps	In Development	Production	Feedback Requested	No	Free	Yes
Implementation Specification	IHE Mobile Access to Health Documents (MHD) Profile	Balloted Draft	Feedback requested	Feedback Requested	No	Free	Yes
Implementation Specification	IHE Query for Existing Data for mobile (QEDm) Profile	Balloted Draft	Feedback requested	Feedback Requested	No	Free	Yes

Limitations, Dependencies, and Preconditions for Consideration	Applicable Security Patterns for Consideration
To learn more about Patient Portals and their usage, see the Patient Engagement Playbook. For a consumer-facing resource on this interoperability need, see ONC's Guide to Getting & Using Your Health Records. See FHIR, Direct, Patient Portal, API, and Open API projects in the Interoperability Proving Ground. “Direct” standard is based upon the underlying standard: Simple Mail Transfer Protocol (SMTP) RFC 5321 and for security uses Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Message Specification, RFC 5751. For Direct, interoperability may be dependent on the establishment of “trust” between two parties and may vary based on the trust community(ies) to which parties belong. The leading trust communities to enable communication amongst the most users include DirectTrust (for provider messaging and consumer-mediated exchange) and NATE (for consumer-mediated exchange). As of March 2019, DirectTrust received accreditation as an ANSI SDO. A new division of the organization, DirectTrust Standards has convened a consensus body to update and maintain the Direct Standard (TM) going forward and to seek ANSI approval for the Standard. Current Procedural Terminology (CPT) Consumer Friendly Descriptors (CFDs) may be used when data is being exchanged between patients and providers. The SMART on FHIR Project is working in this area, and may have additional implementation guidance, as well as a list of applications supporting this interoperability need. When using the SMART on FHIR model, the authentication model uses OAuth2. Except for “Secure Communication”, the security patterns listed do not apply. The IHE Mobile Access to Health Documents (MHD) profile provides a simple API for document discovery and download. This API may be used in many settings including by Patient managed applications. See -- https://profiles.ihe.net/ITI/HIE-Whitepaper/index.html The IHE Query for Existing Data for mobile (QEDm) profile provides for a simple query for a subset of clinical FHIR Resources. This subset is consistent with USCDI.	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 Secure Communication – create a secure channel for client-to-server and server-to-server communication. Secure Message Router – securely route and enforce policy on inbound and outbound messages without interruption of delivery

Limitations, Dependencies, and Preconditions for Consideration

Applicable Security Patterns for Consideration

To learn more about Patient Portals and their usage, see the Patient Engagement Playbook.
For a consumer-facing resource on this interoperability need, see ONC's Guide to Getting & Using Your Health Records.
See FHIR, Direct, Patient Portal, API, and Open API projects in the Interoperability Proving Ground.
“Direct” standard is based upon the underlying standard: Simple Mail Transfer Protocol (SMTP) RFC 5321 and for security uses Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Message Specification, RFC 5751.
For Direct, interoperability may be dependent on the establishment of “trust” between two parties and may vary based on the trust community(ies) to which parties belong. The leading trust communities to enable communication amongst the most users include DirectTrust (for provider messaging and consumer-mediated exchange) and NATE (for consumer-mediated exchange).
As of March 2019, DirectTrust received accreditation as an ANSI SDO. A new division of the organization, DirectTrust Standards has convened a consensus body to update and maintain the Direct Standard (TM) going forward and to seek ANSI approval for the Standard.
Current Procedural Terminology (CPT) Consumer Friendly Descriptors (CFDs) may be used when data is being exchanged between patients and providers.
The SMART on FHIR Project is working in this area, and may have additional implementation guidance, as well as a list of applications supporting this interoperability need.
When using the SMART on FHIR model, the authentication model uses OAuth2. Except for “Secure Communication”, the security patterns listed do not apply.
The IHE Mobile Access to Health Documents (MHD) profile provides a simple API for document discovery and download. This API may be used in many settings including by Patient managed applications. See -- https://profiles.ihe.net/ITI/HIE-Whitepaper/index.html
The IHE Query for Existing Data for mobile (QEDm) profile provides for a simple query for a subset of clinical FHIR Resources. This subset is consistent with USCDI.

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
Secure Communication – create a secure channel for client-to-server and server-to-server communication.
Secure Message Router – securely route and enforce policy on inbound and outbound messages without interruption of delivery

Comment

Submitted by John Moehrke on 2021-09-08

IHE - Mobile Access to Health Documents

The IHE Mobile Access to Health Documents (MHD) provides a simple API for document discovery and download. This API may be used in many settings including by Patient managed applications. See -- https://profiles.ihe.net/ITI/HIE-Whitepaper/index.html

Submitted by John Moehrke on 2021-09-08

IHE - Query for Existing Data for mobile

The IHE Query for Existing Data for mobile (QEDm) implementation guide is in Trial-Implementation status. This implementation guide provides for a simple query for a subset of clinical FHIR Resources. This subset is consistent with USCDI. IHE publication -- https://www.ihe.net/uploadedFiles/Documents/PCC/IHE_PCC_Suppl_QEDm.pdf The Query for Existing Data for Mobile Profile (QEDm) supports dynamic queries for clinical data elements, including observations, allergy and intolerances, problems, diagnostic results, medications, immunizations, procedures, encounters and provenance by making the information widely available to other systems within and across enterprises to support provision of better clinical care. It defines a transaction used to query a list of specific data elements, persisted as FHIR resources

About the ISA

ISA Content

ISA Sections

Appendices

Specialty Care and Settings

ISA Publications

Recent ISA Updates

21st Century Cures

View, Download, and Transmit Data from EHR

Comment

IHE - Mobile Access to Health Documents

IHE - Query for Existing Data for mobile