[Openid-specs-heart] HEART Meeting Notes 2015-02-23

[Debbie Bucci]

*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*


   - March 2 - Adrian Gropper will present Post MI Implant and Rehab use
   case  (in progress ..
   http://hg.openid.net/heart/wiki/Post-MI_Implant_and_Rehab)
   - March 9 - Focus on Delegation

*General *

   - *Public wiki :  *http://hg.openid.net/heart/wiki/Home
   - *Resources* (slides etc) : http://openid.net/wg/heart/resources/
   <http://hg.openid.net/heart/wiki/Home>


A couple of the member requested a meeting invite for the weekly meetings -
 Note there is an iCal link on the home page http://openid.net/heart/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-heart/attachments/20150225/7ba77574/attachment.html>