Following is the use case story that drove the development of the VA Secure Restful Profiles work, catalogued here:
The overall use case has been documented here:
These are the more specific use cases that drove the development of the pilot software. I haven’t mapped these to the ACE-style categories yet, and they don’t have the full UMA information as we didn’t develop that in our pilot. I’ve tried to note
Steve Emeritus, is a veteran
Dr. Pat Feelgood, a VA doctor and Steve’s PCP
Dr. Sam Pellegrino, a non-VA ER doctor who treats Steve for an injury
Patient domain, services that Steve runs, owns, contracts, or otherwise controls
VA domain, services directly in control and view of the VA
ER domain, services directly in control and view of the ER domain
IdP, an OpenID Connect Identity Provider (one per domain)
AS, an OAuth 2.0 Authorization Server (one per healthcare domain)
FHIR Client (one per domain)
FHIR Server (one per healthcare domain)
Part 1: Steve goes to the doctor
Steve has a strong and ongoing patient-provider relationship with his primary care physician, Dr. Feelgood at the VA, who has a medical record on Steve at the VA. Dr. Feelgood can access this medical record on the VA’s system via her identity with the VA IdP, using the VA authorization server to connect the VA’s FHIR client to the VA’s FHIR server. Steve wants to be able to access his record through the VA portal, so he signs in to the portal with his digital identity through his personal IdP in the presence of Dr. Feelgood, who binds this digital identity to Steve’s medical record. [[ Note: the specifics of the identity-binding ceremony were outside the scope of our pilot. ]]
Steve is now able to log into the VA Portal and the VA AS using his digital identity, and the VA backend systems (the AS and FHIR server) hold the policy that Steve’s external digital identity has access rights to Steve’s specific medical record.
[[ Note: Both Steve and Dr. Feelgood’s access is mediated through the VA AS using OAuth 2.0, even though this is inside of a single security domain. We designed the pilot such that internal access and external access are technologically identical, but controlled by different policies. In this particular case, the VA AS has been set to whitelist the VA FHIR client, so no users are prompted. ]]
Part 2: Steve accesses his data remotely
Steve now wants to access his medical records through a personal health application, hosted outside of the VA. He can log into this application using his IdP to create an account. He gets a URL representing his medical record (pointing to the VA FHIR server) from his doctor that he can plug into his health application. Steve’s health application sends him to the VA’s AS to get access to his record. [[ Note: we left dynamic registration and trust out of the pilot as well, and statically registered components ahead of time. ]] Steve logs into the VA AS with his personal IdP, and authorizes his personal FHIR Client to access his VA medical record on the VA FHIR server. Since the VA system knows Steve from Part 1, he’s allowed to do this.
Part 3: Steve gets hurt, gets a new record
Steve is on vacation and is involved in a minor accident. He shows up at a non-VA emergency room with minor injuries and is treated by Dr. Pellegrino. Dr. Pellegrino creates a new medical record for Steve at the ER. Steve logs in to the ER system with his personal IdP and binds to his ER record, just like in Step 1.
Part 4: Dr. Pellegrino requests access to Steve’s VA record
Dr. Pellegrino asks Steve for access to his medication information from his PCP. Steve then plugs in his VA health record URL to the ER’s FHIR client. The ER’s FHIR client sends Steve to the VA AS for authorization. Steve logs into the VA AS using his personal IdP and authorizes the ER FHIR client access to just the medication information in his VA record at the VA FHIR server.
The ER FHIR client gets an OAuth 2.0 access token and uses that to call the VA FHIR server and access the medication information in the record. The token isn’t able to get any other data from the server. [[ Note: This uses Steve’s direct OAuth delegation and not a policy granted access to Dr. Pellegrino. This is an obvious place where UMA could give another option. ]] The ER FHIR client is then able to take the information that it has pulled from the VA FHIR server and push it (as a cached remote copy) into the ER FHIR server for later comparison and access. This allows both Steve and Dr. Pellegrino to access this part of his VA record from the ER portal. Dr. Pellegrino uses the ER IdP to log in to everything. [[ Note: we did not develop the stored-cache part of the FHIR client/server in our pilot, but left a space where it “could” happen. ]]
Part 5: Steve accesses his data remotely, again
Steve gets a URL from Dr. Pellegrino for his record at the ER and enters this URL into his personal health app. Steve is redirected to the ER AS, where he logs in with his personal IdP. Steve authorizes his personal FHIR client to access the ER FHIR server for his record. He’s allowed to do this because Dr. Pellegrino bound Steve’s identity to the specific medical record in Part 3 and the ER AS recognizes him, just like the VA AS did in Part 2.
Part 6: Dr. Feelgood accesses Steve’s record through the ER portal
Steve comes home and points his PCP at his new record over at the ER. Dr. Feelgood logs into the ER portal with her VA IdP and accesses Steve’s ER medical record there. Steve has set up a policy on the ER AS that allows Dr. Feelgood direct remote access. [[ Note: in our demo pilot software this is smoke and mirrors, but in reality this is where UMA would come into play. Steve would effectively point at the VA’s IdP, probably by using the VA email address claim from the doctor and some means of determining which IdP is canonical for a given email domain. This is likely to involve webfinger and some kind of interfederation protocol. ]]
Part 7: Dr. Feelgood imports Steve’s ER record to the VA system
Dr. Feelgood grabs the URL for Steve’s record from the ER system and enters it into the VA FHIR Client (where she’s once again logged in using the VA IdP). She is then redirected to the ER AS and logs in using the VA IdP to authorize the VA FHIR Client to access the ER FHIR server. The VA FHIR Client can then copy and cache the ER record into the VA FHIR server for later use. This whole process shows three main aspects of our profiles: direct user delegation (OAuth within domains and across domains), VA as an IdP (using OIDC) and VA as an RP (using OIDC through a trusted binding ceremony).