Health Care Identity Management
- 1 Full Title
- 2 Context
- 3 Solutions
- 3.1 Health Care APIs accessible to the Patient
- 3.2 Table of information flows used in Identity Management and Identity Proofing.
- 3.3 Details of use of exchanges
- 4 References
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.
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:
- How do we identify unique users across systems using person-centric mobile technologies?
- How do we securely authenticate individuals across systems using modern, open standards?
- Once a patient is identified at one organization, how do we cross-facility match a patient to their records?
- What does a consumer-directed, electronic federated consent approach look like?
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
- Apervita Interoperability Solutions focus on EHR or PCP views exposed to patient.
Table of information flows used in Identity Management and Identity Proofing.
|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|
|8A||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|
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
- The establishment of trust in the credential put on the user's devices.
- The establishment of trust in the web sites that the user visits.
The Patient in an emergency Visit
- Google Healthcare API - Consent and privacy overview
- the Trustworthy Healthcare Ecosystem as a great data flow diagram.
- ONC for Health IT Draft Trust Exchange Framework
- carin Consumer ID & Authentication is largely based on NIST 800-63-3 IAL 2
- Note that some of the information on this site is proprietary or subject to various patents.