Patient Choice

Full Title

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

Context

• 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 now 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 smart phones 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 smart phone that downloads PHI, then that application has complete control over where that data goes.
• If the healthcare community decides to allow any smart phone application that the patient chooses to install on the smart phone, 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.

• 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 smart phones 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 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 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 Smart Phone going though 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 web site to allow access to information on their behalf.