[Openid-specs-heart] Draft HEART Meeting Notes 2015-10-13

[Justin Richer]

I would like to reiterate what I believe is an important point to the call: we are not necessarily going to hand off to another organization for final publication, and most likely will not do so. It’s the charter of this WG to publish documents within OIDF.

 — Justin

> On Oct 13, 2015, at 5:02 PM, Sarah Squire <sarah at engageidentity.com> wrote:
> 
> Action Items:
> 
> Debbie will make a sequence diagram for the registration use case. (created 10/13)
> Adrian will make a sequence diagram for the delegation use case. (created 10/13)
> 
> 
> Attendees:
> 
> Steve Greenberg
> Danny van Leeuwen
> Glen Marshall
> Tom Sullivan
> Sarah Squire
> Adrian Gropper
> Debbie Bucci
> Dale Moberg
> Eve Maler
> Justin Richer
> Edmund Jay
> Jim Kragh
> 
> We discussed the three existing use cases: registration, delegation, and data contribution.
> 
> Are there other use cases we should be considering? What are the possible design patterns when you have an individual sharing with an institution (or non-person entity requesting party). What happens when that institution shares that data by means of a chained delegation?
> 
> Is Alice sharing with Dr. Bob the person, Dr. Bob the role, or the institution of the hospital?
> 
> If we could show an example of running code implementing UMA and FHIR, that deliverable would be the simplest example of a healthcare API.
> 
> We should identify design patterns for UMA that could be implemented now.
> 
> Does anonymity fit into these deliverables anywhere? It could.
> 
> We are positioned to be able to influence FHIR if we can build something out relatively quickly. However, that possibility does not imply that we would hand off this group’s work to another organization.
> 
> We are not developing a standard. We are developing a profile of a standard.
> 
> HEART is primarily about user-mediated exchange, but we can’t ignore clinical data exchange. For example, if a patient works on the Eastside, but lives on the Westside. There are hospitals on each side of town. If the patient breaks his leg at work, he should be able to delegate access to his Westside hospital records to the Eastside hospital. The patient would be sharing the information they are authorized to see.
> 
> Should we have the portal transfer patient information? No, portals are user-facing. We are describing an API that is machine-facing.
> Should we disregard the first use case since the PHR isn’t involved in this use case? No, because the patient should still have the right to use the PHR as their source of truth. Is it a subset of the second and third use cases? Yes, it could be. 
> 
> Five sharing design patterns:
> Identity
> Role
> Organization
> Self (PHR)
> Aggregator (patient directory, disease registry, researcher)
> 
> How is the aggregator different from the organization? Aggregators are dealing with multiple hospitals across multiple security boundaries. Organizations are within one security boundary.
> 
> More and more hospitals are part of an aggregated or affiliated entity or enterprise. That makes them de facto aggregators. 
> 
> Would sequence diagrams of the three use cases move us closer toward implementation? Yes it would. Debbie will make a sequence diagram for the registration use case. Adrian will make a sequence diagram for the delegation use case.
> 
> We need to discuss what sort of profile UMA design patterns would fit within, since they’re not technically security, but they also aren’t exclusive to FHIR, so they aren’t appropriate for the semantic profile.
> 
> Sarah Squire
> Engage Identity
> http://engageidentity.com <http://engageidentity.com/>_______________________________________________
> 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/20151013/044c3ce6/attachment.html>