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
Implementation Specification	HL7® FHIR® DSTU 2, Argonaut Data Query Implementation Guide	Balloted Draft	Production		No	Free	Yes Yes Yes
Standard	HL7® FHIR® R4	Final	Production	Feedback Requested	No	Free	Yes
Standard	Current Procedural Terminology (CPT) Consumer Friendly Descriptors (CFDs)	Final	Production		Yes	$
Implementation Specification	SMART on FHIR	Final	Feedback requested	Feedback Requested	No	Free	Yes

Limitations, Dependencies, and Preconditions for Consideration	Applicable Value Set(s) and Starter Set(s)
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.	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 Value Set(s) and Starter Set(s)

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.

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

View, Download, and Transmit Data from EHR

Comment