[Openid-specs-heart] Draft HEART Meeting Notes 2016-02-06

[Sarah Squire]

Attending:

Eve Maler

Adrian Gropper

Celestin Bitjonck

Debbie Bucci

Edmund Jay

Glen Marshall

Jin Wen

Julie Maas

Justin Richer

Kenneth Salyards

Nancy Lush

Sarah Squire

Thomas Sullivan

Eve:

We’d like to focus on the IoT section because we got very specific on
claims profiling, which we were driving toward.
https://docs.google.com/a/forgerock.com/document/d/1PNra0i3aH4uwLsLw9IgfTYAbDV-eFiA96OHeQ9Dvtso/edit?usp=sharing

A legal line gets crossed when health data is shared with health
professionals. It becomes covered by legal frameworks. We have bridge
consumer and clinical scenarios.

Thomas:

Not all IoT devices have patient control of data sharing. Some devices
phone home or automatically inform certain medical professionals about the
data coming from the device.

Eve:

I’d like to discuss another use case. In this one, Alice’s doctor wants to
share her information with another professional. Or, alternatively, she
would like to use her data to get a second opinion. Also, if Alice were to
revoke access to a home healthcare worker, how would that inform the way we
design scopes in an API. If we talk about FHIR today, we’re just talking
about read and write. But if we’re talking about a camera, we’re talking
about move and zoom and pan and take photo, etc. You quickly get out of the
realm of what FHIR gives you by default.

Nancy:

We may want to limit who has access to a function, so would claims come
into play?

Eve:

There’s what you can do on the resource, and then there’s who can do it.
The first thing we’re talking about is data vs. function. That’s a very
coarse-grained distinction.

Nancy:

I know FHIR has a concept of device.

Glen:

http://wiki.hl7.org/index.php?title=Health_Care_Devices

Eve:

We can expect the control of the functions to be held close to the vest.
It’s probably not useful for us to standardize them.

Glen:

ISO/IEEE 11073 standardizes some healthcare interfaces

Eve:

Alice may want to share device access for leaderboard type of things. Or
she might want to allow friends to actually use the device. Now we get into
how and why she wants to share.

Adrian:

Have we found any place that’s different from IoT than the rest of
healthcare?

Eve:

I don’t know yet, but I suspect that it will teach us about needs for
extensions to our profile, extensions to FHIR, and APIs that are not FHIR.
It helped me really understand APIs that are “FHIR++”. The tricky ways in
which laws influence what devices do to Alice’s control are something we
should understand.

Justin:

There will be classes of devices where the manufacturers think they still
have full control.

Eve:

Another difference is that in some IoT cases, there are challenges with
disconnection from a network. That’s a technical challenge. I think there’s
an overarching thing that we need to profile. In the case of Alice sharing
with someone, on the basis of an OpenID Connect claim, is OpenID connect a
universal enough mechanism to use when Alice just wants to share with
someone? Do we want to profile that? Because if we do, it would look
completely different in UMA 1 vs UMA 2?

Justin:
We’re not going to be meeting for the next couple of weeks, so I’ll take
Eve’s document and do a first revision of it in spec language.


Sarah Squire
Engage Identity
http://engageidentity.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-heart/attachments/20170206/29412785/attachment.html>