1. OpenID Foundation Avatar OpenID Foundation
  2. WGs
  3. HEART

Wiki

Clone wiki

HEART / 2015-02-23

View History

Attendee Stats

  • 16 in attendance 9 are members - ( Attendee roster link avail next week)
  • Listserv up to 87 members (wow!)

Virtual Patient Registration Use Case ## - ( http://hg.openid.net/heart/wiki/Virtual_Patient_Registration )

  • Catherine Schulten presented the Virtual Patient Registration use case, based on Virtual Clipboard from the WEDI effort. The idea is that the patient can bring their eligibility data (the 270 X12 eligibility request) to the equation. The use case being displayed takes a different twist; it meets the needs of the patient stakeholder, the provider stakeholder, and also the payer stakeholder.
  • The individual is a “patient” to the provider, and a “subscriber” to the payer. The individual may be a child, or an elderly person who may give someone else their proxy for parts of the flow. The data used in registration is part of a familiar form. The “top of the form” has familiar identification and location fields. Then you get into insurance information. And then medical history/clinical information. This use case focuses most on the “top of the form” (financial and administrative data), not on the clinical information.
  • The registration event sparks a lot of downstream processes. People ask you for all this data in order to support further population of healthcare claims, clinical application processes, filling out of names on the tops of charts, and so on. It touches lots and lots of systems. So it’s important to get it right at the beginning.
  • The actors include a healthcare provider, a healthcare payer, and a patient. You fill out the form to the best of your recollection. Someone transcribes written text into a computer system. Other transactions get spawned off of this. There’s an e-registration service that would let the patient create a profile and allow systems to accept the e-registration process. The patient and the provider would need to be “known to the service” somehow, kind of like a consumer and a merchant both being “known to VISA” to pay by credit card.
  • The patient is in charge of their own data, and can update it — such as their phone number — when necessary. The data should be in the well-known standard format so that it can be consumed in a standard fashion.
  • The authorization problems summary includes a starter set, such as emergency scenarios. The patient might want to get very “discrete” (fine-grained) about handing out data. Regulations are part of this landscape, including HIPAA and other privacy/PII regs.
  • This is going to be piloted this year by WEDI, so it’s not that futuristic. The use case identifies benefits as well as challenges. The drivers for individuals are convenience, managing our own data, and helping people in our care. Providers also have strong drivers. Payers talk about how they have to generate insurance ID cards, which has a cost.
  • Eve suggests capturing the drivers/benefits as well as the challenges. Catherine is involved in a startup, and has a good sense of the business drivers; she will share those.
  • The service is not a giant Rolodex in the sky that the payer or hospital queries to get the individual’s information; the individual chooses to grant access to the information. The individual might be onboarding to the provider’s system for the first time, but this scenario could also suffice for a person returning and updating information. “Registration” here includes not just provisioning a new account, but also updating data in an existing record. Identity proofing and authentication are not part of the process — thinking of someone who shows up at a hospital, they’ll create a record if necessary no matter who you are!
  • There’s the concept of “known to the practice”. This is a way to automate becoming “known to the practice”. Attaching an existing record to a verifiable identity supplied by an identity provider is not part of this use case. However, we note that there’s a lot of medical identity theft, where a person poses as another person and seeks care as that other person. “Record overlays” cause pernicious problems around clinical risk.

VA Secure RESTful Use Case ## - ( http://hg.openid.net/heart/wiki/VA_Secure_RESTful_Use_case )

  • Justin picked up on his use case.
  • There was an IdP in each domain, there was OpenID Connect used as a login method to an OAuth server in each case, there was a FHIR web client in each case, and they were OAuth clients with tightly coupled OAuth authorization servers. (Some of this was “demo-genic” to make things work smoothly.) Dynamic client registration wasn’t used all over the place initially. Steve’s doctor, to view Steve’s record at the ER, would require some sort of claims-based access a la UMA. So the question is: What is the method? This wasn’t profiled yet. The identity binding ceremony gets into legal requirements more than technology, and wasn’t profiled; it’s unexciting on a technical level.
  • They made up simple FHIR scopes, and didn’t write up a formal profile for that yet. They did publish their source, however. They hope that work will feed into this group’s work.
  • The intention of what we want to profile is to layer specs, so that our UMA profile can layer on top of the OAuth profile. If anyone needs just the OAuth functionality, then they can just use the underlying spec etc.
  • Profiling and Stacks
  • What does the “decision tree” look like for what technologies anyone would use in securing/protecting/access controlling (etc.) a health data API? Specifically, when would one use OAuth, OpenID Connect, UMA, which kinds of client applications, etc.? Eve suspects it’s truly a “layer cake”.

AI: Eve: Propose a decision tree for choosing the high-level "Venn" technologies (and thus their corresponding HEART profiles) - approximately 2 weeks

AI: Justin: Send excerpted contributed-profile information on choosing specific kinds of client applications to the list. [DONE - http://hg.openid.net/heart/wiki/VA_OAuth_references ] ###

Upcoming Meetings

General ##

Updated