Phone as Health Care Credential: Difference between revisions

From IDESG Wiki
Jump to navigation Jump to search
Line 1: Line 1:
==Full Title==
==Full Title==
Using a Patient's Cell Phone as their Health Care Credential
Using a Patient's Cell Phone as their Health Care Credential and personal healthcare Information store.


==Context==
==Context==

Revision as of 17:40, 1 August 2019

Full Title

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

Context

  • The wiki page Trustworthy Healthcare Ecosystem contains more context information.
  • 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.

The is the conclusions from that 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.

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.

Solution

  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 Identity Proofing already performed at many HIPAA covered healthcare providers 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. 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 entity that handle PHI.
  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.

Phone as HC Cred.png

References