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

[Sarah Squire]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-heart/attachments/20151013/0e7869a4/attachment.html>