- 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