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

[Debbie Bucci]

The "refusal to bend" that you call out in the profiles seem to align with
some of the feedback we are getting from others.  Hopefully some
updates/clarifications will help potential Implementers understand it's not
an all or nothing deal.

I pushback a bit on ...experimentation .  There are use cases today (PMI?)
They  are concerned with tough issues such as consent and delegation now.

You have been following the UMA workgroup and are aware that the spec is
still evolving.

What I think we need is reference implementation (s), test tool and sme
volunteers to help vendors data holders providers and patient facing apps
that are willing to take the next step in ernest.  These specs are
implementer drafts.  Standards evolve.

Even the move from FHIR 1.0 to 2 was painful but there were lessons learned
from doing so.

Thank you so much for commenting.
On Mar 8, 2016 5:08 PM, "Josh Mandel" <Joshua.Mandel at childrens.harvard.edu>
wrote:

> Dear HEART,
>
> Apologies that I couldn't make today's call!
>
> Based on some comments from the draft minute (BTW thanks Sarah, these are
> consistently amazing!), let me see if I can articulate my positions
> coherently and consistently — because they are nuanced, but I don't enjoy
> creating the perception that I say different things in public vs. in
> private. I'm pretty sure I have consistently stuck to the 5-point message
> below, though it's not always what people want to hear :-)
>
> 1. HEART (especially with its focus on UMA) is tackling use cases that are
> incredibly important, and that perhaps no one else in the healthcare
> community is thinking deeply about: things like Alice to Bob sharing, and
> patient-controlled authorization servers, and the consolidation of decision
> points to a single server to mitigate the multiple portals problem.
>
> 2. Even though these cases are incredibly important, they are also
> incredibly complex. The technological solutions to address them in UMA are
> complicated enough that I'm not sure they can work in the real world. I
> think we need experiments, and usability studies, and lots of experience
> and implementation guidance. But this all goes into the realm of
> exploration, rather than immediate production adoption.
>
> 3. When it comes to the lower-level HEART profiles (OAuth, OIDC), the
> goals of the HEART workgroup are not just to build something that works
> today. The goals are actually to expand the state of the art and improve
> upon existing practice, and to push the ecosystem forward. So, for example,
> HEART makes liberal use of, and assumes that servers must implement,
> specifications like token introspection, and dynamic client registration,
> and public key authentication (and please forgive me if this listing isn't
> precisely correct). These are all good things, and I would like to live in
> a world where I can take them all for granted. But the fact is that HEART
> deliberately pushes beyond the installed base of today's healthcare
> ecosystem, and is disinclined to compromise for the sake of pragmatism. I
> describe this as an approach for the future (but I also caution that we
> need to accumulate and learn from real world experience en route to that
> future).
>
> 4. When it comes to the needs of today, the industry requires minimalistic
> specifications that are designed for implementation right now. In
> collaboration with a large group of EHR vendors for the 2015 certification
> timeline (that's what they call it even though certification will occur in
> 2016 and later), SMART and the Argonaut Project have a narrow, focused
> approach. We are specifically interested in standardizing the way that
> electronic health records talk to applications, but we are not trying to
> standardize the way that an EHR works internally. We are eager to identify
> pragmatic compromises that will lead to systems that are consistent enough,
> without getting stuck in the details where agreement is not essential for
> interoperability.
>
> 5. There are clearly some places where today's SMART/Argonaut
> specifications differ from HEART in arbitrary ways. And we should work to
> close those gaps ASAP. (We understand pretty well what those places are.)
> But if you compare #3 and #4, it seems inevitable that there will be some
> principled (rather than arbitrary) differences, and those are harder to
> reconcile (without waiting for the future to arrive).
>
> I hope this clears up my perspective,
>
>   -Josh
>
> _______________________________________________
> 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/20160309/5157079d/attachment.html>