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

Mon Apr 18 23:24:36 UTC 2016

Also, a point I raised on the call:

Keep in mind that many of the historically “proactive” use cases are likely proactive precisely because there’s no reasonable way for people to be reactive in a paper-based system. So instead of asking people in-situ when making decisions, we clear everything up front so that we don’t have to ask again. 

Yes, we can model that with technology. My question to the group is: should we? I think sometimes it makes sense, and others it does not. We need to carefully weigh that. 

And ultimately, the line of “proactive/reactive” is fuzzy at best. What do we call it when Alice gets notified of the enforcement of a proactive policy, which she can then quickly change on the fly? What if Alice makes a reactive decision and tells the system to remember it (TOFU)?

 — Justin

> On Apr 18, 2016, at 5:13 PM, Eve Maler <eve.maler at forgerock.com> wrote:
> 
> Thanks, Sarah! Piling on: Here is the snippet with the latest edited list of sharing scenarios to consider:
> 
> We suggest to modularize our work on this use case, such that we can add "Step" sections whenever we're satisfied with previously vetted sections. Can we prioritize sharing scenarios in the group?
> (Proactive flow?:) Alice setting up provisioning of basic data on first visits to Dr. Bob (and Dr. Erica for extra credit?): PHR A to EHR B and EHR E.
> Alice being able to monitor and control access by Dr. Bob: Alice interacting with SMH A.
> (Proactive flow?:) Alice sharing her medication list with her spouse: PHR A to app C.
> (Reactive flow?:) Agreeing to do data donation under certain conditions: EHR A to Aggregator
> (Proactive flow?:) Sharing mother’s medical concerns with daughter: PHR D to app A
> (Proactive flow:) Consent directives: Rules set ahead of time for EHR access by family members and others?
> (Reactive flow:) Alice approves access to physician requests for records?
> (lots of other flows possible...)
> Can people please weigh in on how they would prioritize these scenarios (and any other new ones, or edited versions of these) for building out the Steps? I don't think it would take all that long to write Steps for any (say) top-two flows if we narrow it down.
> 
> 
> Eve Maler
> ForgeRock Office of the CTO | VP Innovation & Emerging Technology
> Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl
> Check out the 2016 schedule <https://summits.forgerock.com/> for ForgeRock Summits and UnSummits!
> 
> 
> On Mon, Apr 18, 2016 at 2:04 PM, Sarah Squire <sarah at engageidentity.com <mailto:sarah at engageidentity.com>> wrote:
> 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 <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 <http://engageidentity.com/>
> On Mon, Apr 18, 2016 at 1:59 PM, Sarah Squire <sarah at engageidentity.com <mailto: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 <http://engageidentity.com/>
> 
> _______________________________________________
> Openid-specs-heart mailing list
> Openid-specs-heart at lists.openid.net <mailto:Openid-specs-heart at lists.openid.net>
> http://lists.openid.net/mailman/listinfo/openid-specs-heart <http://lists.openid.net/mailman/listinfo/openid-specs-heart>
> 
> 
> _______________________________________________
> Openid-specs-heart mailing list
> Openid-specs-heart at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-heart

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-heart/attachments/20160418/a8c1a956/attachment.html>