Phone as Health Care Credential: Difference between revisions

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


[[File:Phone_as_HC_Cred.png]]
[[File: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.
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.


Revision as of 20:53, 27 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.
  • 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.

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

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.

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

References

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