<div dir="ltr">Dear HEART,<br><br>Apologies that I couldn't make today's call!<br><br>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 :-)<br><br>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.<br><br>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.<br><br>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).<br><br>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.<br><br>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).<br><br>I hope this clears up my perspective,<div><br></div><div>  -Josh</div></div>