Phone as Health Care Credential

From IDESG Wiki
Revision as of 21:36, 28 January 2020 by Tomjones (talk | contribs) (→‎Problems)
Jump to navigation Jump to search

Full Title

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

Goal

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

Context

  • The wiki page Trustworthy Healthcare Ecosystem contains more context information for the patient's view of trusted identifiers in cyberspace.
  • 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.

Problems

  1. The HIPAA covered entity has obligations to avoid disclosing patient health information (PHI) without explicit user consent.
  2. Patient data held on, or accessed by, a user of a smart phone is vulnerable to theft by many well-known attack vectors.
  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 PHI could result in the app and vendor together as a "covered HIPPA 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.

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.

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 or faction scan,
    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.

NIST NCCOE Engagement Model

This model is proposed as a methodology that can be used to advance the idea of a phone as credential into the NCCOE cyber-security framework. This will make a significant extension of the existing NCCOE May 2016 Healthcare Sector Cybersecurity Framework Implementation Guide.

  1. Define == OUTCOME: Define a scope of work with industry to solve a pressing cybersecurity challenge
  2. Assemble == OUTCOME: Assemble teams of industry organizations, government agencies, and academic institutions to address all aspects of the cybersecurity challenge
  3. Build == OUTCOME: Build a practical, usable, repeatable implementation to address the cybersecurity challenge
  4. Advocate == OUTCOME: Advocate adoption of the example implementation using the practice guide

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.

References

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