Patient Choice

From IDESG Wiki
Jump to navigation Jump to search

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

2021-04-30 (HIPAA changes can introduce new threats)

Context

  • For more context see the wiki page Native Apps for US Healthcare which looks at the apps that control access to user secrets in hardware. This page considers web apps as well.
  • 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.
  • The Monday 2020-03-09 release of ONC’s Cures Act Final Rule which supports seamless and secure access, exchange, and use of electronic health information
  • And the Tuesday 2020-03-10 report in the New York Times New Data Rules Could Empower Patients but Undermine Their Privacy Which points out that forcing adoption without concern for patient privacy would harm patients rights.
  • 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 uniformly 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 website 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.
  • Without some other trust mark on the app, it is very difficult for the patient to determine if the app is covered by HIPAA. "If you see the term 'we are HIPAA-compliant', the basic rule of thumb is the program does not fall under HIPAA" from Pam Dixon, executive director of the World Privacy Forum as quoted by Thorin Klosowski in "Consider the Consequences of Trading Your Health Data. (2020-02-03) New York Times p. B7.
  • 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.
  • In the US on 2020-02-20 data sharing is not based on FHIR standards but an older document exchange protocol that has little control and operates with no transparency to the patient. This Reddit post shows Your doctors are sharing your private health information to the state and feds (and it's not a HIPPA violation!)
  • Also a threat is Some proposed HIPAA changes could inadvertently expose the data it’s supposed to protect.

    One of the changes involves allowing patients to receive their medical information via personal health applications — smartphone apps, for example — which are often developed and operated by third-party technology companies. But these companies are generally not governed by HIPAA, opening up patient health data to potential misuse. “The patient isn’t the only one getting the information in that situation, and so you wind up exposing information to tech platforms, app developers and others. That exposed information can then be shared with data brokers who create profiles on individuals, which can be used for potentially nefarious purposes. For example, it creates a gating opportunity where some people may get certain opportunities based on those profiles, and others are barred from those same opportunities. That’s according to Laura Hoffman, assistant director of federal affairs at the American Medical Association,

  • Part of the problem is that sometimes the health services themselves pass patient records to app developers. For example the article UK class action-style suit filed over DeepMind NHS health data scandal describes live patient information passed from the UK NHS to a small developer and Google Deep Mind for development purposes. (2021-09-30)

Solutions

The patient is not accustomed to having a choice in their health as the insurance market has dictated that for decades. There are two obstacles to overcome to provide real choice to any consumer.

  1. The patient must learn that they have a choice. Even though the 21st Century Cares Act gives them choice, it is not enforceable until October 2020 since extended to October 2021..
  2. The patient must have easy access to clear data to make a choice. In particular the effectiveness and out-of-pocket cost of any procedure or medicine. This will probably be decided in a hit-or-miss approach unless some real user research can be done.
  • 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.

Expected Types of Access Methods

For users with some computer literacy:

  1. Browser on a personal or public device
  2. User portable device with browser and local storage for continued connectivity.
  3. User agent running the cloud that can be accessed with any browser
  4. User agent in a native app on a user owned device using traditional sources of an identifier
  5. User agent in a native app on a portable user owned device with a self-issued identifier

Consent and Notification

  1. The current medical practice is for the user to be given a form at the physician’s office that give consent to keep records in a patient’s EHR is a health data repository (called a data controller in the GDPR) for the physician, the patient and other providers. This is typically extended to referrals where the patient is giving consent to send medical records that are relevant to the referral. No change is proposed here.
  2. Once the records are at the referred EHR, the Cares Act gives the patient the right to see and acquire PHI from that source as well. Clearly it is important for remote access by the user to exercise this right, but only under careful identity proofing with patient credentials which are protected to AAL2 in NIST 800-63-3B,
  3. Patient Consent that is provided on any such protected remote access must be recorded and acknowledged to the patient, preferable with a receipt that is similar in concept to the one that the patient receives in the office. (Also known as the Break-the-Glass scenario.)
  4. Users must be able to determine which information will be released to other locations which will be conditioned on the purpose of that access
  5. Users will always be notified of changes to access list, medicines and other issues related to their health and security breaches
  6. More information is included on the wiki page Patient Consent.

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 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.

Retrieved from "https://wiki.idesg.org/index.php?title=Patient_Choice&oldid=16181"