Health Care Digital Identity

From MgmtWiki
Revision as of 14:14, 31 October 2020 by Tom (talk | contribs) (→‎Terminology)

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, but far more securely.
  2. In both technology and public health, the key to stopping viruses is testing, tracing and early detection. See more in the General Theory of Living Systems.

Terminology

  • Health Care Digital Identity is the sum total of all the electronic health Records (EHR) about a real world person.
  • Health Care Digital Identifier (aka record locator) is a string that is used to locate some fraction of these EHR.
  • Medical Records Identifier Locator Service is a mapping from one Identifier into the (hopefully) full Identity.

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 for healthcare include:

  1. HL7 and FHIR which is attempting to solve health information interchange internationally, but thinks high assurance identification is just too expensive.
  2. IETF OAuth 2.0 which has had enormous success and is now trying to move on to GNAP as a strong foundation for authorizing access to people's personal information.
  3. OpenID Connect which has been adopted by most of the large social media for user identification and is moving to enable identity assurance through personal attribute disclosure.
  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 without releasing personal attributes.
  7. Digital Identity Foundation where we are working to create a patient generated identifier.
  8. Kantara Federated Identifiers Work Group where we are working on a Mobile Authentication Assurance Statement to allow the Electronic Health Records to be safely released to a patient's smartphone.

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 Distributed Ledger Technology (aka Blockchain) 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) before the patient ever needs to identify themselves. 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 HIPAA 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. This effort will require the establishment of a code of conduct that is currently under development by the CARIN alliance and its imposition all players that handle PHI, including applications that are used by patients to access their health records.

  • That means providing Patient Choice that is meaningful and clear to the patients and their guardians.
  • That means that Patient Consent is obtained with an explanation of why that they can understand and not in the meaningless string of methods that are defined in the HL7/FHIR terms that are designed for physicians and not for patients.
  • Emergency Room or 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, POLST, etc) and emergency contacts to be immediately available to first responders.

5 Electronic Notification and Consent Receipts

Mark Lizar introduced Open Notification to Kantara and the result was the Consent Receipt Specification. That is only the start of an effort that will evolve to give the patient notification of any event that impacts their health or access to their healthcare records.

The best way to provide this to patients and guardians where and when they need it is via their smartphone. That means that their phone must also be trustworthy. We are working to make the Mobile Authentication Assurance Statement a meaningful way for the hospitals and health information networks determine that a request is from a well authenticated and identified patient rather than some hacker in Bulgaria.

6 Self Issued Identifiers

Both the Open ID Foundation and the Digital Identifier Foundation are engaged in created a self-issued identifier.

References

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