Healthcare Patient Choice with Distributed Identity Assurance
Healthcare Patient Choice with Distributed Identity Assurance
Session 9E
Convener: Tom Jones
Notes-taker(s):
Tags for the session - technology discussed/ideas considered:
Discussion notes, key understandings, outstanding questions, observations, and, if appropriate to this discussion: action items, next steps:
Presentation is on this page http://tomjones.us/Home/Solutions
The methods for providing users with strong assurance eg X.509 have not had acceptable UX NSTIC → IDEF
The discussion is about enabling great Level 2 experience (when user makes an assertion they need validation; identity assurance needs proof of identity proofing; authentication assurance needs proof of protection of user secrets; cover nearly 1:1 claims about the user; 3rd party claims can extend to comparisons of different co-pay choices; any of these can be bound to other user contexts at other HIPAA entities)
At registration the new patient needs (driver’s license; health insurance card; payment card; health history) The information received can be validated by some existing technique and methods Patient Registration with Distributed Attributes - standard Precondition :
In this use case the patient has a smartphone; has the capability to load an app (which controls the identity and release of information). It is optionally possible to consider that the phone holds the healthcare information for the patient
PCP gives the user the location or, URL so that the app can be loaded on the phone - could be a QR code
User loads app on their phone → establishes an identifier on their own (self issued identifier) → user binds the identifier to medical records at the PCP/Hospital → phone binds the identifier to claims of authentication assurance
The app is a “certified app” and the phone is capable of securing the user’s secrets.
User can use these claims in a new context with any other HIPAA covered entity. User agent could download user data in FHIR format. User agent could verify the trustworthiness of any provider. User could upload user FHIR data to any certified web site. The goal is that the FHIR data never leaves the context of HIPAA
If the device is “shared” - given to another user with the screen unlocked; the new user (not the one who created the profile) is likely to have access to the app and detail. Unless the app requires secondary authentication for data/functionality within the application container Guardianship role capability can be added to the flow which is driven by the app. Minimal user data needed
