Difference between revisions of "Health Care Identity Management"

From MgmtWiki
Jump to: navigation, search
(→‎Full Title)
m (→‎References)
(32 intermediate revisions by the same user not shown)
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==
−
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
+
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:
−
===Problems===
 
 
# How do we identify unique users across systems using person-centric mobile technologies?
 
# 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?
 
# 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?
 
# 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?
 
# What does a consumer-directed, electronic federated consent approach look like?
 +
See the wiki page [[Health Care Digital Identity]] for a description of the [[Identifier]]s used in health care to address these areas.
  
 
==Solutions==
 
==Solutions==
−
The following are specific cases of [[Identity Management]] that might be applied to Health Care use cases. For specific data flows see the following page in this wiki - [[Health Care Identity Management]].
+
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.
−
===1 Identification of individuals with mobile devices===
 
−
Developments for user-centric authentication is becoming common both with smart phones and with late-binding tokens that are already appearing in user's hands. Two methods will be addressed in the immediate future: (1) smart phones with native apps and (2) hand held devices that can be kept in the person's possession and used for authentication. Each device will come with their own personal user Identifier. That way the user can change authentication devices as technologies advance. The binding of the user's device Identifier with the user's medical and state-supplied Identifiers will be a separate process that gives technologies the space to innovate while maintaining user access to all of their medical (and other) records.
 
  
−
We have prototype native applications running now on Android and Windows devices and will be adding Apple iOS apps in the near future. These apps give the user immediate control of their own Identifiers and Medical Records access codes. The apps authenticate the person holding the phone by one of several proof-of-possession actions and then accept a request for access from the provider. They can also display some of the information access methods on a locked phone in the hands of a first responder. The information is coded into the user device ID and from there to a records locator (solution #3).
+
===Health Care APIs accessible to the Patient===
 +
* [https://f.hubspotusercontent20.net/hubfs/5796578/0_RESOURCES-Ungated/Apervita-Interoperability-Solutions_20200819.pdf Apervita Interoperability Solutions] focus on EHR or PCP views exposed to patient.
  
−
===2 Secure Authentication with Open Standards===
+
===Table of information flows used in [[Identity Management]] and [[Identity Proofing]]. ===
−
Open standards exist today for self-issued identifiers and new standards are evolving rapidly for new technologies like W3C Web Authentication and Block-chain technologies. These can and will be deployed for the bulk of the population with IAL 2 (NIST 800-63-3) as an aspirational goal. But the absolute requirement is that all patients that present themselves for emergency treatment will be treated with whatever level of assurance is possible and high assurance will be layered onto the medical records as it becomes available.
 
  
−
Mutual authentication will be required so that the patient will know who is asking for the information and for what purpose (solution #4). This will give the user confidence that the health care network is operating for their benefit and that all providers and all services are fully compliant with HIPPA and other appropriate regulations. The patient will also know how to access any medical record that is being created with their personal information and to maintain an access method to that record.
+
{| class="wikitable"
 +
|-
 +
| # || 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
 +
|-
 +
| 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
 +
|-
 +
| 13 ||  ||  ||  ||
 +
|-
 +
| 14 ||  ||  ||  ||
 +
|-
 +
| 15 ||  ||  ||  ||
 +
|-
 +
| 16 ||  ||  ||  ||
 +
|-
 +
| 17 ||  ||  ||  ||
 +
|-
 +
| 18 ||  ||  ||  ||
 +
|-
 +
| 19 ||  ||  ||  ||
 +
|-
 +
| 20 ||  ||  ||  ||
 +
|-
 +
| 21 ||  ||  ||  ||
 +
|-
 +
| 22 ||  ||  ||  ||
 +
|-
 +
| 23 ||  ||  ||  ||
 +
|-
 +
| 24 ||  ||  ||  ||
 +
|-
 +
| 25 ||  ||  ||  ||
 +
|-
 +
| 26 ||  ||  ||  ||
 +
|-
 +
| 27 ||  ||  ||  ||
 +
|-
 +
| 28 ||  ||  ||  ||
 +
|-
 +
| 29 ||  ||  ||  ||
  
−
===3 Cross-facility matching of individuals===
+
|}
−
Each facility that creates a user record will need to have their own identifier(s) for that record(s). Rather than try to enforce a single use Identifier on all providers, it is expected that a better success ratio would result from complete acceptance of a multiplicity of records and some clearing house that was specifically designed to allow the user to get access and transfer capability for all records no matter where they resided. This will also allow the user more granular control (if they wish) to determine which records will be shared with which providers. The solution to this problem is the same as the solution to problem #1, the medical records matching service. Since this service is first of all, a service supporting the patient's rights to control access to their own information (solution #4), the choice of the records matching service will be made by the patient. Each service will have the capability to collect any information that the user wished to accumulate and release it only as the user directs. The service will be accessible at any time by the user (and by FirstNet) but providers will only have access as they acquire access tokens from the user. First responders can use the access codes or phone numbers on cell phones to access the records. Any such access will be reported to the patient.
 
  
−
===4 Electronic Federated Consent===
+
===Details of use of exchanges===
−
This is a fruitful time for solving user consent with a user experience that will match with their experience on other sites.
+
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.
  
−
FirstNet access should have an override of user consent for any recorded needed in emergency situations. Most particularly it is important for user directives (DNR, etc) and emergency contacts to be immediately available to first responders.
+
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]].
 +
# 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====
 +
TK
  
 
==References==
 
==References==
−
*[https://www.healthit.gov/sites/default/files/draft-trusted-exchange-framework.pdf ONC for Health IT Draft Trust Exchange Framework]
+
* [https://cloud.google.com/healthcare/docs/concepts/consent Google Healthcare API - Consent and privacy overview]
−
*[https://www.carinalliance.com/our-work/consumer-id-authentication/ carin Consumer ID & Authentication] is largely based on NIST 800-63-3 IAL 2
+
* [https://wiki.idesg.org/wiki/index.php/Trustworthy_Healthcare_Ecosystem The Trustworthy Healthcare Ecosystem] has a great data flow diagram.
−
*[https://kantarainitiative.org/groups/ciswg/ The Kantara Consent & Information Sharing Work Group] has published a [https://kantarainitiative.org/file-downloads/consent-receipt-specification-v1-1-0 Consent Receipt Standard].
+
* [https://www.healthit.gov/sites/default/files/draft-trusted-exchange-framework.pdf ONC for Health IT Draft Trust Exchange Framework]
−
*[http://pubdocs.worldbank.org/en/595741519657604541/DigitalIdentification-HealthcareReportFinal.pdf Identification for Development (ID4D)] The World Bank. The Role of Digital Identification for Healthcare:The Emerging Use Cases
+
* [https://www.carinalliance.com/our-work/consumer-id-authentication/ carin Consumer ID & Authentication] is largely based on NIST 800-63-3 IAL 2
−
*[https://www.gsma.com/identity/digital-identity-demonstrates-crucial-role-transforming-healthcare Digital Identity Demonstrates its Crucial Role in Transforming Healthcare] from the GSMA - the mobile telcos and friends.
+
* Note that some of the information on this site is proprietary or subject to various patents.
−
* The Kantara Identity Incubator supports development of solutions including the [https://kantarainitiative.org/trustoperations/kantara-identity-privacy-incubator/mobile-authentication-for-first-responders/ Mobile Authentication for First Responders]
 
  
 
[[Category:Identity]]
 
[[Category:Identity]]
 
[[Category:Use Case]]
 
[[Category:Use Case]]
 
[[Category:Health]]
 
[[Category:Health]]

Revision as of 18:11, 14 March 2021

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
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
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=10103"