Phone as Health Care Credential: Difference between revisions

From IDESG Wiki
Jump to navigation Jump to search
Line 12: Line 12:


==Context==
==Context==
* Only smart phones running iOS or Android operating systems in use by the patient or their guardian.
* Primary use case is smart phones running iOS or Android operating systems in use by the patient or their guardian.
*The wiki page [[Trustworthy Healthcare Ecosystem]] contains more context information for the patient's view of trusted identifiers in cyberspace.
*The wiki page [[Trustworthy Healthcare Ecosystem]] contains more context information for the patient's view of trusted identifiers in cyberspace.
*Some of the benefits of simple cell phone use can be included in a comprehensive plan for patient matching and authentication, but since 84% of patients in early 2020 have smart phones, that is the focus of this wiki page.
*Some of the benefits of simple cell phone use can be included in a comprehensive plan for patient matching and authentication, but since 84% of patients in early 2020 have smart phones, that is the focus of this wiki page.

Revision as of 20:15, 20 March 2021

Full Title

Using a Patient's Cell Phone as the holder of their (1) Health Care Credential and (2) personal healthcare Information store.

Goal

  1. The first goal as defined by MITRE in the PEW report (see next section) is to provide strong patient matching to prevent both life-threatening misidentification and medications fraud.
  2. The second goal is a common means to authenticate users that can be both secure and used as proof that a QHIN is non-discriminatory as defined in TEFCA

    5.1.2 No Discriminatory Limits on Exchange of EHI. A QHIN shall not unfairly or unreasonably limit exchange or interoperability with any other QHIN, Participant, Participant Member, or Individual User such as by means of burdensome testing requirements that are applied in a discriminatory manner or other means that limit the ability of a QHIN to send or receive EHI with another QHIN, Participant, Participant Member, or Individual User or slows down the rate at which such EHI is sent or received if such limitation or slower rate would have an anti-competitive effect.

Terminology

  • TEFCA = Trusted Exchange Framework and Common Agreement contains most of the other acronyms and is the source for US regulations on exchange of EHI.
  • QHIN = Qualified HIN is a network of organizations working together to share data. QHINs will connect directly to each other to ensure interoperability between the networks they represent.
  • EHI = Electronic Health Information aka Personal Health Information (PHI) which is nearly all Personally Identifiable Information (PII),
  • HIPAA = Health Insurance Portability and Accountability Act of 1996 which was designed to make information interchange ubiquitous also contains privacy requirements which are more restrictive than any general state mandated privacy requirements.

Context

  • Primary use case is smart phones running iOS or Android operating systems in use by the patient or their guardian.
  • The wiki page Trustworthy Healthcare Ecosystem contains more context information for the patient's view of trusted identifiers in cyberspace.
  • Some of the benefits of simple cell phone use can be included in a comprehensive plan for patient matching and authentication, but since 84% of patients in early 2020 have smart phones, that is the focus of this wiki page.
  • Smart Health Cards Framework is focused on COVID-19 certificates.
  • Pew research reports that Enhanced Patient Matching Is Critical to Achieving Full Promise of Digital Health Records, and to prevent harm through faulty health history information. The report is oriented towards healthcare provider issues. When they did ask patients what they wanted it was consistently shown that patients want all of the purported benefit of matching, but with no loss of privacy. They also found that Republican voters tended to favor less government involvement in the process.
  1. System oriented solution needs unique patient identifiers - but what they really mean is mandatory patient IDs for life.
  2. Patient oriented solutions, like Smart Phones and QR codes, fit in better with the goal to give patients access and control of their private information, personal as well as medical.
  3. Demographic matching, bio-metrics, disease history, whatever (maybe even the old standard, the social security number).
  4. Referential from other sites, like social services agencies or similar.
  • These are the conclusions from that RAND report on the use of patient's phones.

To assess that concept, Pew contracted and collaborated with the RAND Corp. to evaluate different approaches to involving patients in matching. RAND conducted a literature review, interviewed experts, and convened an advisory panel to identify different options for a patient-empowered matching strategy and criteria used to analyze each approach. The research identified several options, which ranged in the degree to which the patient would be involved. Some approaches included minimal patient involvement—patients could, for example, permit their pictures to be taken—while others included a more hands-on role for the individuals, including having each patient aggregating all his or her health data in one location or obtaining a voluntary unique patient identifier. The research identified several criteria to evaluate each solution, including the degree to which it would improve match rates, the likelihood of patient adoption and use, and the feasibility of implementation. In a report released in August 2018, (reference below) RAND recommended a patient-empowered approach for matching involving two main components: validating patient information and a smartphone application, which would then be used together once developed.

  • This document addresses the last point, the use of a smart phone application to achieve the high assurance authentication (IAL2, AAL2) required by the healthcare community. Specific recommendations from RAND include those that will advance the selected three-stage solution through development and pilot testing by:
  1. Developing technical specifications for verified data fields, developing best practices that allow health care providers to verify mobile phone numbers, and iteratively pilot testing and refining the specifications and best practices to maximize feasibility and usability
  2. Developing application programming interfaces and best practices for establishing bidirectional communication between a smartphone app and health care provider registration systems at the point of care, and iteratively pilot testing and refining them
  3. Developing advanced app functionalities to further improve record matching and increase the value of apps to patients and providers.
  • As reported in the Trustworthy Healthcare Ecosystem this Kantara committee proposes to build a sandbox for testing these concepts.
  • Many companies, and now the DHS TIC 3.0 Interim Telework Guidance provide for users to bring their own device (BYOD) to work environments. In all cases the enterprise will have from some security, possibly even remote wipe capability, for the phone. In other words, the enterprise does not trust the user to keep their own device secure.

Problems

  1. The HIPAA covered entity has obligations to avoid disclosing patient health information (PHI) without explicit user consent. No consensus exists on what form that consent might take.
  2. Patient data held on, or accessed by, a user of a smart phone is vulnerable to theft by many well-known attack vectors. In the New York TImes of 2019-09-03 Natasha Singer reports large health organization and even the software providers, like Epic, have "concerns that people who authorized consumer apps to retrieve their medical records could open themselves up to serious data abuses."
  3. The ONC has supported guidelines that require a moderately high level of assurance (provided by NIST IAL2 and AAL2) that is proven to work in today's smart phone, but only when that phone is configured by security-conscious enterprise admins.
  4. The smart phone today will have some sort of trusted execution environment that can hold patient credentials and PHI in a secure fashion, but the history of enabling that protection for the general population is littered with failed efforts.
  5. The ordinary smart phone user is not knowledgeable about assuring that they only communicate with trusted web sites that will protect their data from disclosure.
  6. The ordinary smart phone user is not knowledgeable about assuring that any application that they install on their phone will protect their data from disclosure.
  7. 25% of Healthcare Providers Faced Mobile Device Breach in 2018 A new Verizon report found healthcare organizations were also more likely to be notified of a breach by a customer or vendor than other sectors.

Liabilities

  • Medical devices are controlled by the FDA. If a smartphone with an app is deemed to be a medical device then the app vendor will need to be aware of the consequences.
  • Even if a smartphone app is not a medical device, downloading Protected Healcare Information (PHI) could result in the app and vendor together being viewed as a "covered HIPAA entity" in the US.
  • If all of those liabilities are avoided it is likely that the app will need to register as sufficient to provide Authentication Assurance Level 2 (AAL2) for the sign in features. This step is likely to require "duty of care" for such actions.
  • But judicial review will win in the end, and that process has hardly begun.
  • In any case liability insurance is RECOMMENDED for app vendors.
  • If an attacker learns either your subject identifier or medical record locator, they can claim ownership. In a well-designed system such a fraudulent claim will fail.

Solution

The following are new services that need to be spec'd and built to support a testing sandbox for compliant smart phone solutions for patients of Health Care providers. The sandbox would also need (1) a test version of a doctor's office with EHR, (2) a second covered entity with a completely separate EHR that will receive data from the patient and (3) a trusted third party that can authentication users and handle user-generated content, like emergency contact data.

  1. The establishment of some sort of trust registry that allows smart phone apps to verify the trustworthiness of every site that has access to PHI at no cost to the patient is mandatory if the patient is to safely manage their own PHI.
  2. The solution proposed is to leverage the Distributed Identity Proofing that is already performed at many HIPAA covered healthcare providers to achieve IAL2 assurance.
  3. The to allow a Credential Service Provider (CSP) to certify the installation of a high assurance credential on the patient's smart phone using a native application that can also be validated by the CSP as a part of the credential that provides AAL2 assurance.
  4. From that point forward any HIPAA covered entity can use the authentication provided by the patient's smart phone if they choose to do so.
  5. For current status on approved apps for US Health care see the wiki page on Native Apps for US Healthcare.

Device Reliability

  • It is very important that once a user is signed up with a device HC Credential, that it continue to work as expected for as long as the user has the device.
  • To that end it is likely that any device and app that is offered as a host for HS Credentials wb part of the continuing application compatibility (App Compat) testing for at least 10 years into the future.
  • This wiki page assumes that the device will be either a cell phone or a smartphone running iOS or Android. with the local Trusted Execution Environment (TEE).
  • It is also assumed that the device will report that the user has a screen lock and the the credential private keys are protected by the hardware TEE.
  • While there is no report from the phone itself because of the trust that the app will report the phone's conditions, it should be noted that RFC 8250 does enable a Manufacturer Usage Description for IoT devices.
  • Recovery of access lost due to changes in the user's device must be addressed. See section 5.5 of the OpenID Self Issued Spec.

Data Generated or Delivered by the Phone

Phones can serve two puposes for gathering patient medical data that can be reported back to an EHR.

  1. Location data, inlcuding data on contacts with others. This can be very valuable for contract tracing and other epidemiological research. Phones that comment this data must be careful to release only to authorized services.
  2. Data sourced by other devices, like watches that collect a variety of data, inlacing blood oxygen levels. When this data is reported to an EHR the provenance of the data needs to be accurately capture and forwarded.

Consumer location data is valuable to medical and commercial web sites. It is conceivable that consumers could be compensated for the data, but it is certain the the data needs to protected from unauthorized exposure. - Reference: Cyrus Shahabi, Computing the Value of Location Data, CACM 63 No.9 p 84 (2020-09) and the following article on computing the value.

Device App Architecture

The following diagram shows the relationship between the existing HIPAA covered (medical) entities on the left, the patient and their mobile phone in the center and the two new elements to enable the solution:

  1. The Trust Registry with trustworthiness information on all covered entities and native apps that handle PHI. An API now in development by the OpenID Foundation is expected to serve as a paradigm for that effort.
  2. The Credential Service Provider (CSP) that acquires identity proofing information from a covered entity and uses that to create a secure patient credential on the patient phone. This effort will follow the guidelines in the NIST SP 800-63-3 for IAL2 and AAL2.
  3. Protecting the credential on the phone is required for AAL2 and is achieved by generating the private key in the Trusted Execution Environment of the phone with "no-export" enabled so that their is no way to clone the private key on any other device.
  4. Ensuring the reliability of the phone to FIPS 140-2 or Common Criteria requirements is presumed.
  5. Multi-factor authentication is provided by including the following factors, all of which are available on the 3 platforms of interest:
    1. Something you have is the private key protected from export as describe immediately above, with at least one of the following:
    2. Something you are is a fingerprint, face scan or similar,
    3. Something you know is a pin to access the credential on the phone.

Phone as HC Cred.png

Note that the only additional effort required by the provider is evidence that the patient has been proofed and accepted for care at the provider. That evidence of proofing and acceptance is used by a HIPAA covered Credential Service Provide to enable assurance of identity and protection for a health care credential on the user's smart phone. Other providers will be able to rely on this credential as valid in at least one covered health care provider. The Trust Registry can provide proof to the patient that any web site asking for their health care data is a HIPAA covered entity and also proof to that site that the credential has been proofed at one other HIPAA covered health care provider.

Note that the user/patient must have legal recourse against fraudulent use of their identifiable information. This is handled with the user experience components of recovery and redress which are described elsewhere.

The ongoing efforts at creating a specification will be posted on the web site at: https://kantarainitiative.org/confluence/display/WT/Draft+Recommendations

Other Healthcare Functions

While this page is primarily about identification of the patient during interaction with the healthcare community, there are many more types of interaction of the patient with their smart phone that are already being developed. As the phone becomes a source of patient health information (PHI), the protection of that information from disclosure and matching the information to the patient will need to be improved. Making the use of the Phone as Health Care Credential will ensure that those other healthcare functions can be performed with the needed level of security and privacy.

Derived Credential

The High Assurance ID Token that is created by the phone to get access other EHR data stores is a Derived Credential in the sense meant by the NCCOE/NIST Practice Guide where the EHR proofing provided by the source and be used to derived the credential that is used to access the destination.

Security Conditions on Android

The following setting are available starting in API version 23 (Android M) and must be verified as operational before a using a Phone as Health Care Credential. Apps running on earlier versions of Android must not be certified for use.

  • The Android Keystore provides the means to store private keys in hardware. This is required to be enabled.
  • Private keys can be marked for use only when the user has enabled and used authentication to access Android. This is required to be enabled on the phone and set for any private key used for this purpose.
  • Starting with Android 9 the user can create a backup of their private keying material on the phone to download to other devices if the phone is lost.

Security Conditions on iPhone

References

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