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

Adrian Gropper agropper at healthurl.com
Tue Mar 8 22:31:14 UTC 2016


Thanks, Josh for being so clear.

I, for one, am not an academic. What then, fellow HEART travelers, should
be our initial pilots?

Adrian

On Tuesday, March 8, 2016, 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
>


-- 

Adrian Gropper MD

PROTECT YOUR FUTURE - RESTORE Health Privacy!
HELP us fight for the right to control personal health data.
DONATE: http://patientprivacyrights.org/donate-2/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-heart/attachments/20160308/8b71aa11/attachment.html>


More information about the Openid-specs-heart mailing list