[Openid-specs-heart] Draft HEART Meeting Notes 2016-04-18

[Sarah Squire]

Also, here's a link to the use cases we discussed today:

https://bitbucket.org/openid/heart/wiki/Alice_Shares_with_Physicians_and_Others_UMA_FHIR

Thanks to Jim for the reminder!

Sarah Squire
Engage Identity
http://engageidentity.com

On Mon, Apr 18, 2016 at 1:59 PM, Sarah Squire <sarah at engageidentity.com>
wrote:

> Attending:
>
> Eve Maler
>
> Tom Sullivan
>
> William Kinsley
>
> Josh Mandel
>
> Adrian Gropper
>
> Dale Moberg
>
> Scott Shorter
>
> Cait Ryan
>
> Simon Gordon
>
> Justin Richer
>
> Sarah Squire
>
> Glen Marshall
>
> Edmund Jay
>
> Jin Wen
>
> Kathleen Connor
>
> Jim Kragh
>
> Julie Maas
>
> Upcoming events:
>
> IIW
>
> EIC
>
> Cloud Identity Summit
>
> SOUPS
>
> Datapolooza
>
> OSCON
>
> IEEE Security and Privacy
>
> Is there an interest in trying to find alternate dates? Why don’t we
> construct a Doodle poll of dates where we know we definitely have an
> overlap?
>
> Action Item: Sarah will construct a Doodle poll.
>
> Eve:
>
> UMA FHIR Use Case: We’ve made small changes, but the content of the
> characters and flows hasn’t changed.
>
> We have sharing scenarios to consider. These need some group input.
>
> Jin:
>
> One case is a patient visiting a healthcare organization and then
> transferring his or her medical history. This would be an EHR to EHR
> transfer.
>
> Eve:
>
> There’s also sharing the medication list with Alice’s husband.
>
> What should we call a healthcare information consuming application?
>
> Kathleen:
>
> Maybe we could just call it a health app. Just leave the portal as a PHR
> and then everything else is an app. There are apps that a healthcare
> consumer might want to use in concert with other apps that have nothing to
> do with health.
>
> William:
>
> Are we differentiating between HIPAA covered apps and non-HIPAA covered
> apps?
>
> Eve:
>
> We could. Non-PHR seems to be the more relevant distinction.
>
> Adrian:
>
> What are we trying to do here? Why do we need separate use cases for all
> of these subcategories?
>
> Eve:
>
> In this case, it’s the people motivated to share. In the first case, Alice
> doesn’t want to fill in a clip board. In the sharing with husband case,
> Alice’s husband needs to know so he can help with care.
>
> Glen:
>
> That is of interest in setting up the use case, but not after.
>
> Eve:
>
> We could do a whole series of use cases, but we’re starting to see this as
> modular. If we documented each of the flows, we could easily prioritize
> them. For me, sharing with husband is the highest priority.
>
> Adrian:
>
> Would you consider two motivations as part of this list? Alice gathers
> different portals into one, and the desire to be “in the loop” for anything
> involving healthcare at a particular provider, i.e. wanting transparency.
>
> Eve:
>
> We would only branch off if we had other characters or flows. There are
> many motivations that are not listed here. The motivations you are talking
> about are outside of an UMA flow. We could have a use case involving
> central management of two EHRs by adding another doctor. Do we have an
> authoritative data source?
>
> Adrian:
>
> They would both be authoritative for different data. If there is no
> trigger update mechanism, then the PHR doesn’t solve that problem.
>
> Bill:
>
> I think we need to figure out what the scope of the use case is. The
> purpose of the PHR was to provide a single point of truth. I think what
> you’re trying to say is there is no single point of truth. Is that true?
>
> Adrian:
>
> Every FHIR endpoint is authoritative for something, and what matters is
> what triggers updates of another system. How do we create a surveillance
> system so that a doctor can find out when their patients are seen
> elsewhere?
>
> Bill:
>
> Having a single point of truth simplifies the use cases. I think that
> creates a complex use case.
>
> Sarah:
>
> How is this different from our oauth delegation use case?
>
> Adrian:
>
> Being able to specify an authorization server to multiple resources. And
> we have lots of directory problems.
>
> Sarah:
>
> Directory problems are outside the scope of HEART, and it sounds like
> you’re talking about Alice to Alice delegation, which has already been
> solved with oauth.
>
> Bill:
>
> Aren’t we supposed to be protocol agnostic?
>
> Justin:
>
> We’re trying to increase security, and we are definitely going to use
> FHIR. HEART is a longer term utopian project, whereas Argonauts is a
> current-state project. We are more forward-looking.
>
> Bill:
>
> I’m just saying we shouldn’t be too concerned with Argonauts because
> they’re jumping and doing things now, and that’s not our goal.
>
> Justin:
>
> Agreed, we just want to make sure that HEART remains realistic and
> implementable and becomes a next-generation option for the healthcare space.
>
> Eve:
>
> I’m trying to figure out how to summarize where we are. Our first use case
> is exchange between EHR and PHR. Is that controversial?
>
> Adrian:
>
> I just said it was unnecessary.
>
> Eve:
>
> But whoever is authoritative should be the source of truth. In the case of
> medications, the patient is authoritative.
>
> Adrian:
>
> The distinction between EHR and PHR is arbitrary.
>
> Eve:
>
> You obviously feel strongly about PHR mucking up the works. I don’t
> understand why it can’t be authoritative.
>
> Adrian:
>
> It’s not wrong, but it doesn’t serve the purpose of filling in the
> clipboard. You want to be able to do that even if the patient doesn’t have
> a PHR.
>
> Kathleen:
>
> It’s not a problem to me that there are different endpoints.
>
> Justin:
> Reminder that there’s no call next week due to the OpenID Foundation
> meeting. There will be a HEART get-together there.
>
>
> Sarah Squire
> Engage Identity
> http://engageidentity.com
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-heart/attachments/20160418/6f00498c/attachment.html>