Health Care Digital Identity

From MgmtWiki
Revision as of 16:19, 30 August 2020 by Tom (talk | contribs) (→‎Context)

Jump to: navigation, search

Full Title

A means for creating Identifiers and references to Electronic Health Records for people seeking health care in the US.

Goals

  1. The patient or guardian is as comfortable using her phone to manage health issues as it is to manage her emails, and far more secure.

Context

On May 1 2020, CMS and ONC published final 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?

There is no shortage of standards making organizations looking at identity. Some of the ones we have been tracking here include:

  1. HL7 and FHIR which is attempting to solve health information interchange internationally, but thinks high assurance identification is just too expensive.
  2. OAuth 2.0 which has had enormous success and is not trying to move on to GNAP is a strong foundation for authorizing access to people personal information.
  3. OpenID Connect with has been adopted by most of the large social media for user identification and is slowing moving to more identity assurance.
  4. Kantara UMA which has tried to place control of a user's personal information in their own hands and has tried to relate that to healthcare.
  5. OpenID HEART which tried to adapt UMA, OAuth and other standards to health care but has yet to address identity assurance.
  6. Kantara Health Identity Assurance Work Group has created principles and insights provided to ONC to help healthcare with identity assurance.
  7. Digital Identity Foundation where we are working to create a patient generated identifier.

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.

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 prototyped a Health Care Native Application 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).

We have demonstrations of Late Binding Tokens that are gaining ground in laptop computers and can be used with Smart Phones if they are not equipped with a Trusted Execution Environment (TEE).

2 Secure Authentication with Open Standards

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.

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

This is a fruitful time for solving user consent with a user experience that will match with their experience on other sites.


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.

References

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