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

Josh Mandel Joshua.Mandel at childrens.harvard.edu
Tue Mar 8 22:08:07 UTC 2016


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

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

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,

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-heart/attachments/20160308/28f1d254/attachment.html>

More information about the Openid-specs-heart mailing list