[Openid-specs-heart] Draft HEART Meeting Notes 2016-12-12

[Sarah Squire]

Attending:

Nancy Lush

Eve Maler

Adrian Gropper

Glen Marshall

Jim Kragh

Kenneth Salyards

Luis Maas

Sarah Squire

Scott Shorter

Thompson Boyd

Walter Kirk

Eve:

I’ve been conspiring with Nancy on how to make progress today. I’d like to
talk about profiles and message flow. I’d like to get consensus around
profiles. A profile is a standards specification where you limit the
options of the specification you’re building on top of. It’s normative, so
you’re describing what needs to happen.The purpose is to drive toward
interoperability. We should still with what we should profile generically
first. Where we see variability, let’s take those as discussion points and
let them drive later standards.

Glen:

I’m very much in favor of that kind of generalization. I think we need to
avoid special snowflakes.

Adrian:

I think HEART should be the interoperability standard for FHIR.

Eve:

We also had a conversation around resource types. This table was supposed
to be a starting point for patient-centric resource types of interest. Many
of those would be categorized as observation. Nancy and I talked a bit
about purpose. Is it meant to be informative? Or normative? I think of it
as imposing an obligation.

Glen:

Just so you know, FHIR consent group has been working on purpose this week.

Adrian:

Many of the groups I’ve been involved with are working on the rights of
patients to direct their data, and the right of institutions to warn
patients if the place they are directing their data isn’t within a given
trust framework.

Eve:

I’d like to talk about specific profiling opportunities, and how to
prioritize or parking lot them. I’ve made a diagram of how Dr. Erica could
present claims.

Adrian:

Heart is making the assumption that the client is dynamically registers.
All that matters is how Erica or Bob is authenticated to enable that.

Luis:

The OCR people and API taskforce people have been discussing what the
client credential process looks like when it’s automated. A resource server
can’t place any undue restrictions on an application that a patient chooses
to use.

Eve:

Right now we’re putting client registration in the parking lot. If someone
has something more to say on it, please send it to the list. Let’s move on
to doctor authentication.

Adrian:

There are four models here:

Erica has a login

Alice has whitelisted Erica’s idp

Alice has whitelisted Erica’s federated identity

Erica has a self-sovereign identity

Sarah:

That’s not true. Authentication is one claim that Erica can have, but she
could also have a valid medical license, or a verified email address.

Eve:

I think we’re sort of conflating AAT and claims gathering.  What about
notifications?

Nancy:

We’re talking about when Alice invites Dr. Erica, we don’t need to profile
that notification because there are already protocols for that.

Adrian:

There are three types of notifications

Notify Dr. Erica if the token is modified or ignored

Invitation to Erica

Sarah:

There’s also consent receipts and granting and revocation for consent to
use of data for research

Eve:

I’d also like to discuss FHIR resource types. It’s important to make the
mapping to UMA resource sets. So talking about how providers want to
retrieve information. That’s maybe homework for Nancy and me. We also want
to put registering resource sensitivity in the parking lot.

Glen:
Sensitivity and labels are under discussion at HL7.

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