Remote Patient Authorization and Submission of EHR Data for Research

Type	Standard / Implementation Specification	Standards Process Maturity	Implementation Maturity	Adoption Level	Federally required	Cost	Test Tool Availability
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)
See Sync for Science and Sync for Genes for more details about the research project use case that pertains to this interoperability need. The Kantara Initiative's UMA (User Managed Access) Work Group project's use case is designed to develop specifications that allow individual control of authorized data sharing and service access to promote interoperability in support of this interoperability need. The reference to FHIR for this interoperability need is in relation to the transport services that are conformant to the RESTful FHIR API. See FHIR, API, and Open API projects in the Interoperability Proving Ground. Current Procedural Terminology (CPT) Consumer Friendly Descriptors (CFDs) may be used when data is being exchanged between patients and providers. When using the SMART on FHIR model, the authentication model is OAuth2. The other security patterns listed do not apply. See Section VI: Questions and Requests for Stakeholder Feedback for a question related to this interoperability need.	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 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 Purpose of Use – Identifies the purpose for the transaction Security Labeling – the health information is labeled with security metadata necessary for access control by the end user

Limitations, Dependencies, and Preconditions for Consideration

Applicable Value Set(s) and Starter Set(s)

See Sync for Science and Sync for Genes for more details about the research project use case that pertains to this interoperability need.
The Kantara Initiative's UMA (User Managed Access) Work Group project's use case is designed to develop specifications that allow individual control of authorized data sharing and service access to promote interoperability in support of this interoperability need.
The reference to FHIR for this interoperability need is in relation to the transport services that are conformant to the RESTful FHIR API.
See FHIR, API, and Open API projects in the Interoperability Proving Ground.
Current Procedural Terminology (CPT) Consumer Friendly Descriptors (CFDs) may be used when data is being exchanged between patients and providers.
When using the SMART on FHIR model, the authentication model is OAuth2. The other security patterns listed do not apply.
See Section VI: Questions and Requests for Stakeholder Feedback for a question related to this interoperability need.

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
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
Purpose of Use – Identifies the purpose for the transaction
Security Labeling – the health information is labeled with security metadata necessary for access control by the end user

Comment

Submitted by agropper on 2017-11-20

Add Kantara UMA as a patient-designated HIE Standard

As Chief Technology Officer of Patient Privacy Rights Foundation, 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 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.

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 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 Remote Patient Authorization and Submission of EHR Data for Research. 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

Patients should own their…

Patients should own their health information and be able to easily create a longitudinal health record that they can use or share with health care providers, caregivers, researchers and others. The patient should have an upfront choice to opt in or opt out. They should be able to opt out of their data being shared for research without their knowledge, even if it is supposedly “anonymized”.

Patients should be informed of the transactional brokerage of their health data and the extent at which it is forwarded to pharmaceutical companies, PBM’s, advertising firms, or organizations that re-broker the selling of patient data, anonymized or not (from insurance companies, hospitals, and providers).

Patients can make choices about with whom and when to share their information.

Submitted by K Grasso on 2017-11-20

Patients should own their…

Patients can make choices about with whom and when to share their information.

Submitted by optimal_patient_care on 2017-11-20

Remote Patient Authorization and Submission of EHR Data for Rese

Patients should own their health information and be able to easily create a longitudinal health record that they can use or share with health care providers, caregivers, researchers and others.

Patient information should not automatically be used for research or brokered even if it is “anonymized.” Patients should have the choice to opt in to any broad or specific medical research, and the institution should not be able to broker the patient’s data without the patient having full transparency and the choice to opt in to having their information brokered and shared. Patients should be remunerated for the per-patient access to such information if the researcher and the institution are being compensated for delivery of such information.

The patient should be fully informed of wherever the institution sends the patient data, even if they claim it is anonymized. The patient should also be informed of the transactional brokerage of their health data and the extent to which it is forwarded to pharmaceutical companies and their subsidiaries or contracted firms, anonymized or not.

If the institution is being paid for those data, the patient should have full transparency into payments the provider or researcher received for his or her medical record. Remunerations should be made to the patient for the use of such data.