Remote Patient Authorization and Submission of EHR Data for Research

IHE Advanced Patient Privacy Consent

The IHE Advanced Patient Privacy Consent (APPC) is a Trial-Implementation companion to the normative BPPC profile. The APPC profile is used when additions or deviations from a "Basic" consent policy are needed. The APPC mechanism provides for deeper coded consents beyond what BPPC supports. BPPC continues to be used to capture the ceremony and overall policy, where APPC provides the specific additions or deviations. see the IHE publication https://profiles.ihe.net/ITI/TF/Volume1/ch-43.html

IHE Basic Patient Privacy Consent

The IHE Basic Patient Privacy Consent (BPPC) provides a means for recording the ceremony of patient consenting to a policy. The BPPC profile is normative and widely used to record consent in cross-enterprise settings, such as HIE or research. The BPPC profile includes support for gross coded consent, enabling basic consents to be supported. The IHE normative specification -- https://profiles.ihe.net/ITI/TF/Volume1/ch-19.html 19 Basic Patient Privacy Consents (BPPC) The document sharing infrastructure provided by XD* allow for the publication and use of clinical documents associated with a patient. This profile allows for a Patient Privacy Policy Domain (e.g., an XDS Affinity Domain to have a number of Patient Privacy Policies that can be acknowledged (aka consent). This allows for more flexibility to support some patient concerns, while providing an important and useful dataset to the healthcare provider. Without BPPC, the XDS Profile requires that the administrators of an XDS Affinity Domain creates and agrees to a single document publication and use policy (see ITI TF-1: Appendix L ). Such a single XDS Affinity Domain Policy is enforced in a distributed way through the inherent access controls of the systems involved in the XDS Affinity Domain. This profile will use terms consistent with ISO 22600 - Privilege Management and Access Control (PMAC), but is not restricted to systems that implement PMAC. This profile uses the term “Patient” to refer to the human-subject of health-related data. In this context “Patient” is not to imply only those subjects under current treatment, this is sometimes referred to as “consumer”. This profile uses the term “Consent” to mean acknowledgement of a privacy policy, also known as an information access policy. In this context the privacy policy may include constraints and obligations. The systems involved in XDS are expected to support sufficient Access Controls to carry out the Policy of the XDS Affinity Domain. See the IHE white paper Enabling Document Sharing Health Information Exchange Using IHE Profiles published on the IHE web site. ...

Trusted Dynamic Client Registration

With regards to system authentication for this use case, UDAP Dynamic Client Registration provides an extension to RFC 7591 to better scale the use of FHIR client apps. This profile has seen interest from numerous industry stakeholders as an alternative to re-registering apps at every different datasource and as a way to enable sharing of information about apps among datasources. Trusted Dynamic Client Registration provides a path for verification of attributes for apps holding valid digital certificates and the communication of these attributes (e.g. privacy policy) to the end user, increasing confidence in valid FHIR clients within the ecosystem and facilitating the connection of research study apps to clinical FHIR servers without manual preregistration. UDAP is an open collaborative developing profiles to increase confidence in Open API ecosystems. This profile is in draft status and is in pilot stage. UDAP DCR has been tested at several HL7 FHIR connectathons and has received positive feedback from multiple stakeholders, including national health information networks, EHR vendors, and app developers.

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.

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.

 

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.

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.

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.