Difference between revisions of "Health Care Identity Management"

From MgmtWiki
Jump to: navigation, search
(→‎Solutions)
(→‎Full Title)
Line 1: Line 1:
 
==Full Title==
 
==Full Title==
−
[[Health Care Identity Management]] can be performed in multiple ways and use cases should be provided for each. This document shows the [[PHI|Personal Health Information]] flows focusing on those that are involved in Patient Identification.
+
[[Health Care Identity Management]] can be performed in multiple ways and use cases should be provided for each. This document shows the [[PHI|Personal Health Information]] (PHI) flows focusing on those that are involved in Patient Identification.
  
 
==Context==
 
==Context==

Revision as of 13:35, 5 November 2020

Full Title

Health Care Identity Management can be performed in multiple ways and use cases should be provided for each. This document shows the Personal Health Information (PHI) flows focusing on those that are involved in Patient Identification.

Context

On March 4, CMS and ONC published two proposed rules in the Federal Register which requires the use of application programming interfaces (APIs) built with Fast Healthcare Interoperability Resources (FHIR) to share both clinical and claims data with consumers, third-party applications, and others within the health care ecosystem. In order to do so, there is a need to solve for at least four specific areas:

  1. How do we identify unique users across systems using person-centric mobile technologies?
  2. How do we securely authenticate individuals across systems using modern, open standards?
  3. Once a patient is identified at one organization, how do we cross-facility match a patient to their records?
  4. What does a consumer-directed, electronic federated consent approach look like?

See the wiki page Health Care Digital Identity for a description of the Identifiers used in health care to address these areas.

Solutions

The following are specific data flows (exchanges of messages) used in Health Care Identity Management for Patients and authorized users of PHI. These should create a complete taxonomy of such flows.

Health Care APIs accessible to the Patient

Table of information flows used in Identity Management and Identity Proofing.

# From To Media Notes
1 Patient PCP Physical Walks in the door
2 ID Documents PCP Physical Patient hands them to the receptionist
3 Health History PCP Open Today the patient files out a form - tomorrow their smart phone
4 PCP EHR AuthZ code Patient Open Either Paper (QR code) or Phone (device) Present
5 Trusted device SW device Digital Download SW to patient device (phone or computer)
6 QR code PCP on line Digital Allows patient to establish a IAL2 authentication
7 EHR Data device Digital copy of patient data (perhaps part of a referral)
8 Patient's Credential device digital digital reference to patient's IAL2 identity proofing
8 Patient's Credential Mobile Driver's License digital one version of a patient's IAL2 identity proofing
9 Patient's Credential specialist digital this allows specialist to create a IAL2 proofing
10 Patient's EHR specialist digital patient data, perhaps part of a referral document
11 TTP Entity Statement patient device digital information to allow patient to trust the TPP
12 Patient's Credential TTP digital this allows TTP to create a remote IAL2 proofing
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29

Details of use of exchanges

These are all use cases that are described else where. This is just a listing of the information exchanges organized by location.

The Patient Visit to their PCP

The source of nearly all first visit information is the patient visiting their Primary Care Physician (PCP). The first 3 exchanges are just the physical appearance of the patient, typically with their (1) driver's license, (2) insurance card and (3) other Payment Method as Identity Proof. At the first, and periodic other, visit, the patient asked to enter or update their medical histories. A similar even occurs at dentist and other specialist sites. The result is a care plan and now something new, an authorization code to access the PCP's EHR.

This authorization code (perhaps a QR bar code) is used to carry the proofing event that the patient had on-site to their online experience. It allows the PCP EHR to have IAL2 assurance as to the identity of the patient.

The Patient Visit to the PCP EHR site online

The patient identity proofing that occurred at the PCP needs to be carried to the various online sites that the patient would like to visit to get PHI or other information. There are multiple ways that can be used to perform that, the one described here is the acquisition of a QR code at the PCP office that can be used to authorize their access to their EHR. In the chase the patient is given a QR code on a separate piece of paper. This code can only be used once, but still is printed on a separate piece of paper that tells the patient how to use the code and how to protect it from disclosure before they use it. When the patient visits the PCP EHR web site, they are asked to show the code to the camera on their device to authorize them to that EHR.

Once they have authorized access, they are then asked to create a credential to install on the device to allow them to access that EHR in the future from that device. While the code is designed for one time use, it will be valid for a limited time after first use should the patient desire to use the code on multiple devices or to retry from a failed attempt. It is assumed that the QR code is never transmitted in the clear, except from the camera to the device.

The Patient Visit to a Specialist

There are two part to visiting a specialist, the on-site visit where Identity Proofing can be independently performed, and the online visit where an authorization code will be used to transition the Identity Proofing from the on-site to the online environment. In either the on-site or the online use case the Patient Credential can be used to bootstrap an IAL 2 level of assurance.

The path used to move the PHI from the PCP to the specialist is not detailed here because it can be over a back channel with not patient involvement. The front-channel using the patient's smart phone will be dealt with here at a later date.

The Patient Interactions with Trusted Third parties

In the Trusted Third Party case there is no on-site Identity Proofing, so that will rely solely on the Patient Credential.

  1. The establishment of trust in the credential put on the user's devices.
  2. The establishment of trust in the web sites that the user visits.

The Patient in an emergency Visit

TK

References

Retrieved from "http://tcwiki.azurewebsites.net/index.php?title=Health_Care_Identity_Management&oldid=8433"