Patient Choice

Full Title

The options that a patient should have in accessing and sharing their Protected Health Information (PHI) with trusted medical providers.

Source

The Federated Identifiers for Resilient Ecosystems Work Group of the Kantara Initiative.

Last updated

2020-01-26

Context

• The major context for this page is an environment where user's private data is treated like a commodity to be bought and sold. These two postings in the Sunday New York Times on 2020-01-26 demonstrate conclusively that a Trustworthy Healthcare Ecosystem requires more attention to the handling of healthcare data that is common at this time:
  • The report on The Secretive Company That Might End Privacy as we Know it received more reader attention than any reports on the Impeachment trial of the President or even the tribulations of the Duke and Duchess of Sussex.
  • An entire section of the paper "One Nation, Tracked" describing "The Smartphone Data Collection Industry" showed conclusively that we cannot trust the phone apps that brought us to this point.
• This pattern is a sub-set of the User Choice Pattern which covers the general user choice issues. It contains the general context and should be read in conjunction with this page.
• This document assumes that the *Trusted Exchange Framework and Common Agreement (TEFCA) Draft 2 (2019-04-19) will apply. From that it assumes that some means must be found for level 2 authentication of patients that will not be faced with the same rejection as was evidenced in earlier attempts at TLS client authentication.
• Patient choice is acclaimed by existing health care solutions, often as a means for the providers to avoid the responsibility for making good, but tough, clinical and security decisions which might possibly result in bad outcomes and liability to large tort actions. If the blame can be placed on the patient, the care provider might avoid lawsuits.
• For a long time, actual patient choice has been ignored. Now that more enterprises have found that patients will not use products that they don't like or don't trust, every enterprise is claiming that their applications preserve patient choice. The reality does not quite live up to their claims.
• To understand what applications will satisfy patients, we cannot rely on enterprises that peddle solutions, we need to give the patients information about their choices and only then ask the patients what is really important to them.

The term "enterprise" is used on this page to include all purveyors of health care solutions from governments and non-profits to profit making companies.

Problems

• Patients have all expressed a desire to control what and where they share their Protected Health Information (PHI).
• Patients also ask to have control of the applications that run on their smartphones particularly with respect to the way that they handle user private information and the way that they intrude on the attention of the user.
• If the patient chooses an application for their smartphone that downloads PHI, then that application has complete control over where that data goes.
• If the healthcare community decides to allow any smartphone application that the patient chooses to install on the smartphone, then the patient is at risk to loose control of their PHI.
• If the patient chooses to upload their PHI to just any web site without knowledge of that sites' controls, then the patient is at risk to loose control of their PHI.
• The patient must be given the tools to assure that their PHI remains under their control. The healthcare community will loose the patient's trust if they don't enforce that.
• The biggest problem for the covered HIPAA entity is what level of assurance of patient intent do they require to:

1. Release data to the user, especially in machine readable form.
2. Accept data input from the user to be added to the patient's permanent EHR.
3. Accept medical directives from the patient, especially POLST directives.

• As a recipient of HIPAA covered data, any patient-centric health care app MUST take responsibility for protecting the data.
• Electronic Health Record sites must assure that any patient app accepts this responsibility before sending them PHI.
• All computer application software that is running on internet connected computers is subject to a daily barrage of attacks trying to exploit vulnerabilities in that software or the gullibility of the people operating those computers. The Healthcare IT News reported that: "8 out of 10 mobile health apps open to HIPAA violations, hacking, data theft. Though the majority of executives surveyed by Arxan said they believe their apps are secure."
• A recent evaluation of the security of health apps on smartphones revealed the following: "We identified 116 eligible mobile phone apps. Of those, 4% (5/116) received a transparency score of acceptable, 28% (32/116) questionable, and 68% (79/116) unacceptable. Only a minority of the apps (49%) had a privacy policy." Clearly leaving security up to app developers without verification is not working today.

Solutions

• The computer industry has learned that security cannot be a choice and has taken the responsibility to assure that their software does not expose the user to exploits that are launched regularly from any site that has access to the internet.
• If the patient is to have a choice about the release of their protected health information (PHI), they must be able to rely on the software that is installed on the healthcare providers computers as well as any software that they use on their own computers.
• To enable real patient choice, the healthcare community must create a trust registry of web sites and applications that are to be trusted with patient healthcare information (covered HIPAA entities). In other words, enabling patient choice on access to their data, the patient must be limited to the use of secure sites and applications that can be trusted to maintain the security of that information.
• The healthcare community must prevent any sites or apps that are not in the US Healthcare Assurance Registry from downloading patient data.
• The healthcare community should prevent any user app from uploading data is not from a trusted site or app into the patient's EHR.
• To be sure that patient concerns are met, a Trustworthy Healthcare Ecosystem must exist to be able to strongly identify these actors:

1. The Patient must be able to prove that they are the owner (or Guardian of the owner) of the PHI.
2. The Patient app must be trusted to faithfully present the patient authentication and protect PHI that the patient downloads.
3. The source of the data must be trusted to show the provenance of the data. That is to show that the data is legitimate and accurate.
4. If the patient chooses to share PHI, they must be able to assure that the recipient of the data will treat the data with the full protections of HIPAA.

• The question about PHI that is released to non-HIPAA covered entities has not yet been addressed. But is it clear that the patient needs to understand the implications and risks of such a release before it happens.

Other functionality that a device app could supply

1. The app could be used by a medical record source to determine which categories of medical records the patient wants to share with other HIPAA covered entities.
2. The app could respond to requests by an EHR for current information, with with the data is held by the user, or by forwarding the request to the source EHR.
3. The patient or legal system can enable guardians to use the app for access or update of patient data.

References

Other Material

The following use cases contain details about the location where a user agent maintains Patient Choice (ie on the user's phone or in the cloud) among other issues in a Trustworthy Healthcare Ecosystem.

• The Remote Attestation Use Case wiki page describes a user with a Smartphone going through a series of actions that will provide subsequent statements from that user on that phone with a higher level of assurance.
• The User Agent in the Cloud wiki page describes a user with a modern browser on a internet connected computing device establishing an agent on a trustworthy website to allow access to information on their behalf.

These patient choices and their attendant liability are addressed in Design Principles/Goals for a Healthcare Identity Environment Architecture above, a current copy will be maintained on the Kantara website.