[Openid-specs-heart] Draft HEART Meeting Notes 2016-10-03

Sarah Squire sarah at engageidentity.com
Mon Oct 3 20:55:59 UTC 2016


*Action Item for all group members:*

Review the revised spec documents (only the ones dated Oct 3 or later):

http://openid.bitbucket.org/HEART/


File specific edits here:

https://bitbucket.org/openid/heart/issues?status=new&status=open


Any broader discussion should to go this list.


Attending:

Debbie Bucci

Adrian Gropper

Cait Ryan

Edmund Jay

Eve Maler

Glen Marshall

Jim Kragh

Justin Richer

Ken Salyards

Kourtney Richeson

Luis Maas

Nancy Lush

Sarah Squire

Scott Shorter

Walter Kirk

Debbie:

Thanks to Danny for contributing a layman’s language version of HEART.

Glen:

We’ve been talking about relating HEART with FHIR and in order to pull that
off, we have to get in bed with HL7. We need to get a project established
with the security work group. We’ve talked about doing it, but we haven’t
taken the necessary steps to do it.

Debbie:

We had Andy from the MITRE team do some open source work around HEART that
got brought up with HL7. I don’t understand why we need more.

Glen:

We’ve talked about introducing UMA into the SMART profiles, and that would
take a working group, not just a ballot comment.

Debbie:

So if we move forward with patient-mediated exchange for certain use cases,
I still don’t see us influencing FHIR.

Glen:

We could work on FHIR consent. John and Kathleen could help us with that.
We have some crossover now, but we don’t have a project.  The first thing
we would need is a business case or business plan.

Debbie:

So how do we get the UMA semantic profile going? I get that we need to
simplify the use case. But I don’t think we have consensus on how to do
that.

Adrian:

I think we should focus on ordering a medication as the simplest possible
use case.

Sarah:

So if we were building a piece of software, I would agree that we would
need to focus on a feature set in order to build a minimum viable product,
but since we’re making a specification that allows for many different types
of software, that focus doesn’t really help. I would like to hear from Eve
and Justin about what they need to write the rest of the semantic profile
in terms of features and flows.

Eve:

Agree that we need to focus more on flows. We have several defined in the
use case, and I think they cover the breadth of what we would want to
enable.

Adrian:

We have a couple of flows that we’re profiling in HIE of One that would
help with this.

Eve:

That would be helpful, but we also need to focus on the types of data that
are being transferred. For example, switching providers or getting a second
opinion would be a different set of data than a de novo use case.

Adrian:

When I’m addressing the flow issue, I want to know how a FHIR EHR gets
connected to the authorization server for a resource event.

Debbie:

I’ve been trying to understand the different specs, and I keep spinning my
wheels around the authorization service. Couldn’t an OIDC IdP also be an
authorization service?

Justin:

Yes, but it is only allowing access to identity information. It is not
general purpose. And an UMA authorization server does not have to provide
the identity information profiled in OIDC. We want people to be able to
build a HEART-compliant OIDC server that is not a general purpose UMA or
OAuth server.

Debbie:

So where do we go from here:

Eve:

So we’ve talked about two phases - the phase of introduction, and then the
phase of resource set boundaries and scopes.

Debbie:

Are we providing “exemplar” resource sets?

Justin:

We would be defining a set of things including a resource set type. We are
very interested in what they are doing if they want to support FHIR, but
proprietary APIs are out of scope for us.

Eve:

My guess is it would have UMA scopes, UMA resource set boudaries, what Bob
is allowed to ask for. Protecting a FHIR API is fairly easy with OAuth. But
UMA puts that all on stage.

Justin:

The specifications have been reorganized to be friendly to people who are
building different parts of the ecosystem. I would like everyone in the
working group to look through these to make sure that I didn’t miss
anything. I feel like there are still holes, but I can’t place where they
are. I think there are bits that should be expanded.

Eve:

Can I ask who in the working group would actually be building these things?

Adrian:

I am building them.

Luis:

We are also building them and are interested in reviewing the drafts.

Nancy:

We’re also building.

Ken:

We’re also building.

Justin:

MITREid has HEART compliance as well.

Debbie:

We should get the text started on the profile. How do we get started?

Justin:

It would be great if Eve could reiterate on the list what she thinks would
be in the profile.

Debbie:

I think that would be really helpful

Eve:

I wrote something in January, but I will revise it given the conversations
that we’ve had and resend it to the list.

Justin:

I’d also like to point out section 1.3 in each portion, which focuses on
interoperability.

Ken:

I think there’s going to be multiple ways that we have to do resource sets.

Justin:
Please add those ways to the list.

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


More information about the Openid-specs-heart mailing list