View, Download, and Transmit Data from EHR

Type	Standard / Implementation Specification	Standards Process Maturity	Implementation Maturity	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 Fast Healthcare Interoperability Resources (FHIR) STU 2, Argonaut Data Query Implementation Guide	Balloted Draft	Production	No	Free	Yes Yes Yes
Emerging Implementation Specification	HL7 Fast Healthcare Interoperability Resources (FHIR) STU Release 3	Balloted Draft	Pilot	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. 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). Direct is not currently supported by a formal SDO but is actively maintained and updated by the Direct Community. Current Procedural Terminology (CPT) Consumer Friendly Descriptors (CFDs) may be used when data is being exchanged between patients and providers. The reference to FHIR for this interoperability need is in relation to the transport services that are conformant to the RESTful FHIR API. 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.
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).
Direct is not currently supported by a formal SDO but is actively maintained and updated by the Direct Community.
Current Procedural Terminology (CPT) Consumer Friendly Descriptors (CFDs) may be used when data is being exchanged between patients and providers.
The reference to FHIR for this interoperability need is in relation to the transport services that are conformant to the RESTful FHIR API.
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

Comment

Submitted by davidkibbe on 2017-11-15

Feedback on Adoption Level of Direct

As President and CEO of DirectTrust and speaking on behalf of our large membership and community interested in patient participation in Direct exchange with their Providers and others of their choice, my feedback would be that the adoption level is growing rapidly, as patients and consumers obtain Direct addresses for personal applications, such as PHRs, and also as third parties work with patients to obtain their permission to receive and use their health information via Direct exchange. Patients' HIPAA rights enable them to designate an electronic end point via Direct to which their health information in electronic format, for example the C-CDA formatted CCD, must be sent by the health care provider or their organization. Patient portals are becoming capable of asking patients to designate a Direct address for such transmission, which does not require any additional permissions or filling out of forms by the patient with the portal account. This methodology is attracting a wide stakeholder audience, as researchers, referral specialists, application providers, and many others recognize the ease and ubiquity of Direct exchange for secure and interoperable health information exchange initiated by patients and consumers. I would suggest at least 2 dots in the Adoption Level column of this ISA table. Thank you, David C. Kibbe

Submitted by juliemaas on 2017-11-20

Direct adoption level for VDT

Since transmit via Direct is required functionality under the 2014 Edition Certification criteria, then the adoption level should be at least that of 2014 Edition certified EHRs (4 or 5).

Julie Maas

CEO, EMR Direct

Submitted by agropper on 2017-11-20

Remove "trust" barriers to patient-directed interoperability

As Chief Technology Officer of Patient Privacy Rights Foundation, I urge the removal of trust barriers to patient-directed interoperability via Direct or FHIR API. This will enable information to flow without special effort and help patients assemble a longitudinal health record accessible to all of his / her real-world caregivers.

The work of the 2016 API Task Force should also be recognized for its contribution to patient-directed exchange. In particular, that Task Force elucidated the patient’s absolute right to designate a destination for transmission via a FHIR API without any blocking on the basis of “trust” by the API operator. Per the Task Force, the FHIR API operator can warn the patient directing exchange that a destination is “untrusted” but it cannot cannot block the patient from using it if they insist. Per the API Task Force, information blocking on the FHIR API would only be allowed for destinations that would endanger the institution’s security or other patients such as through a denial-of-service attack.

I strongly endorse the addition of Kantara Initiative User Managed Access (UMA) to the API standards for patient directed exchange. UMA should apply equally to both research and clinical APIs so I suggest we remove the “for Research” and make the title “Remote Patient Authorization and Submission of EHR Data”.

The healthcare application of the UMA standard has been profiled by the HEAlth Relationship Trust (HEART) workgroup http://openid.net/wg/heart/ and this work should be recognized in the ISA.

The 21st Century Cures Act provision for API access “without special effort” should be referenced and discussed in the ISA. One way to enable patients to provide access to the FHIR API “without special effort” is to allow the patient to specify their UMA Authorization Server via the institution’s Patient Portal. This would be equivalent to a patient using the portal to opt-in to a health information exchange (HIE) of their choice. Once the patient has done this, their choice should be honored for the next year or until the patient signs into the portal and revokes the HIE designation. There’s no need for the patient to sign-in to the portal for every data access by the designated HIE. There are major benefits of portal control of the HIE to the patient and to interoperability. The patient can point various service providers to the same HIE regardless of whether a particular provider “trusts” a particular HIE. An HIE can then serve a patient’s providers wherever or whoever they are including mental health services, long-term care, research, patient communities, or international facilities. For their part, the HIEs will have to compete on the basis of their privacy policies for the patient’s trust and will not need to worry that their access would be blocked by some FHIR API operators.

Another patient benefit would be a more uniform user experience across different service providers. Patients already need to get credentials to the provider’s patient portal for View, Download, and Transmit. Adding the ability to designate their HIE to the VDT patient portal would avoid introducing a new set of credentials and a new user experience. This would promote health information exchange and help to create longitudinal health records.

Patient identity matching is also enabled by allowing the patient to designate their HIE via the patient portal. That HIE designation would be verified by the HIE the same familiar way a service provider verifies an email address today. This voluntary association between the patient identity and the patient’s HIE preserves the privacy of the patient and allows matching across a full range of services including mental health because the patient’s consent is conveniently factored in.

Submitted by kwboone on 2017-11-20

How about just simple e-mail…

How about just simple e-mail? SMPT, POP3, et cetera. I'm NOT a covered entity, and would like this to remain simple.

Submitted by mattreid on 2017-11-20

AMA comments on the 2018 ISA

On behalf of American Medical Association (AMA) I appreciate the ability to comment on the 2018 Interoperability Standards Advisory (ISA).

Comment:

The AMA requests the Current Procedural Terminology (CPT) Consumer Friendly Descriptors (CFDs) be added to the standards listed for View, Download, and Transmit Data from EHR. The CFD code set was developed in 2010 in response to industry demand for a patient-focused version of CPT that is comprehensive and useful. The CFDs take the complex terminology of medical procedures and services within CPT and translates it into a language that patients and caregivers can better understand and use. An example is CPT code “Arthrodesis, great toe; metatarsophalangeal joint,” which translates to the CFD “Fusion of great toe.” The CFDs have been included in the Centers for Medicare & Medicaid Services’ (CMS) guidance to Medicare Administrative Contractors (MACs) for adding new CPT codes. One specific example is CMS Transmittal 3670 on the addition of CPT codes to report physical and occupational therapy evaluations.

Submitted by K Grasso on 2017-11-20

Remove process burdens on…

Remove process burdens on patients under HIPAA that may limit patient access to their health information based upon patient choice of levels of privacy.

Patients should have instantaneous population of care into their medical record

Patients should have a “key” to be able to share ‘read-only’ access to an entire record for another provider and include a time out option.

Allow patients to view the complete patient record, including pricing, tests, films, lab results, and health care provider notes. Enable patients to comment on their review of such services. Provide affiliated charges and pricing. Price and cost transparency should occur before patients get care and should be presented electronically. As patients access the EHR, they should access the range of pricing from the institution.

The health care provider should be able to view their patient’s aggregated/comprehensive patient electronic health record. Health care providers should have the ability to email notes and orders to each other to communicate regarding patient care.

Technology can support automatic data transfer to patients and better security protection. This will allow patients to be sure their health care providers have the information they need to provide high quality treatment while allowing patients and caregivers to manage their acute and chronic conditions at home.

Submitted by optimal_patient_care on 2017-11-20

Much like the financial community, patients should be able to download their medical data. If any provider or the patient himself wants to view the integrated lab tests and look at a five or ten year horizon, he/she should be able to readily download the data and compare and contrast changes. They should stored in machine-readable form to allow for data analytics by care providers, caregivers, patients, and for research (where the patient has chosen to opt in).

HHS should seek to remove blockage and process burdens on patients under HIPAA that may limit patient access to their health information based upon patient choice of levels of privacy. See our comments above regarding instantaneous population to the digital record and eliminating signing a form for access and waiting 30 days.

Patients should be able to view their complete patient record, including pricing, tests, films, lab results, and health care provider notes. The EHR should provide affiliated charges and pricing. Price and cost transparency, outside of emergency situations, should be provided upfront to the patient prior to rendering services. As patients access the EHR, they should access the range of pricing from the institution compared to other comparable price ranges for a similar procedure elsewhere.

Health care providers should be able to view their patient’s aggregated/comprehensive patient electronic health record. Health care providers should have a two-way ability to communicate via email, phone, and text with each other regarding patient care.

We support the OpenNotes movement for physician notes to be provided attached to the patient EHR and two-way communication to be allowed for patient engagement.