<div dir="ltr"><p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-size:14.6667px;font-family:Arial;color:rgb(0,0,0);background-color:transparent;font-weight:normal;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline">I would suggest that we need to try and reach a consensus on one or more use cases to drive HEART before we dive into scopes and the details of profiles. Here are a few specific comparisons between the Argonaut use-cases as provided by Josh and the HEART WG Charter.</span><br></p><br><p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt" id="docs-internal-guid-f044e2d6-999e-d712-524b-3534e001bc09"><span style="font-size:14.6667px;font-family:Arial;color:rgb(0,0,0);background-color:transparent;font-weight:bold;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline">in the SMART on FHIR Authorization Guide:</span></p><ul style="margin-top:0pt;margin-bottom:0pt"><li dir="ltr" style="list-style-type:disc;font-size:13.3333px;font-family:Arial;color:rgb(0,0,0);background-color:transparent;font-weight:normal;font-style:italic;font-variant:normal;text-decoration:none;vertical-align:baseline"><p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-size:13.3333px;font-family:Arial;color:rgb(0,0,0);background-color:transparent;font-weight:normal;font-style:italic;font-variant:normal;text-decoration:none;vertical-align:baseline">Use Case 1: Patient uses a provider-approved web application to access health data</span></p></li><li dir="ltr" style="list-style-type:disc;font-size:13.3333px;font-family:Arial;color:rgb(0,0,0);background-color:transparent;font-weight:normal;font-style:italic;font-variant:normal;text-decoration:none;vertical-align:baseline"><p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-size:13.3333px;font-family:Arial;color:rgb(0,0,0);background-color:transparent;font-weight:normal;font-style:italic;font-variant:normal;text-decoration:none;vertical-align:baseline">Use Case 2: Patient uses provider-approved mobile app to access health data</span></p></li><li dir="ltr" style="list-style-type:disc;font-size:13.3333px;font-family:Arial;color:rgb(0,0,0);background-color:transparent;font-weight:normal;font-style:italic;font-variant:normal;text-decoration:none;vertical-align:baseline"><p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-size:13.3333px;font-family:Arial;color:rgb(0,0,0);background-color:transparent;font-weight:normal;font-style:italic;font-variant:normal;text-decoration:none;vertical-align:baseline">Use Case 3: Clinician uses provider-approved web application to access health data</span></p></li><li dir="ltr" style="list-style-type:disc;font-size:13.3333px;font-family:Arial;color:rgb(0,0,0);background-color:transparent;font-weight:normal;font-style:italic;font-variant:normal;text-decoration:none;vertical-align:baseline"><p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-size:13.3333px;font-family:Arial;color:rgb(0,0,0);background-color:transparent;font-weight:normal;font-style:italic;font-variant:normal;text-decoration:none;vertical-align:baseline">Use Case 4: Clinician uses provider-approved mobile app to access health data</span></p></li></ul><p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-size:14.6667px;font-family:Arial;color:rgb(0,0,0);background-color:transparent;font-weight:normal;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline">These use-cases are irrelevant to HEART because they do not support symmetrical interface between two Resource Servers in separate security domains. </span></p><br><p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-size:14.6667px;font-family:Arial;color:rgb(0,0,0);background-color:transparent;font-weight:normal;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline">The relevant Argonaut use-case: </span></p><ul style="margin-top:0pt;margin-bottom:0pt"><li dir="ltr" style="list-style-type:disc;font-size:13.3333px;font-family:Arial;color:rgb(0,0,0);background-color:transparent;font-weight:normal;font-style:italic;font-variant:normal;text-decoration:none;vertical-align:baseline"><p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-size:13.3333px;font-family:Arial;color:rgb(0,0,0);background-color:transparent;font-weight:normal;font-style:italic;font-variant:normal;text-decoration:none;vertical-align:baseline">Use Case 5 (future: Provider using EHR A access patient record held in EHR B</span></p></li></ul><p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-size:14.6667px;font-family:Arial;color:rgb(0,0,0);background-color:transparent;font-weight:normal;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline">is explicitly out of scope for Argonaut and a requirement for HEART.</span></p><br><p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-size:14.6667px;font-family:Arial;color:rgb(0,0,0);background-color:transparent;font-weight:bold;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline">in the SMART on FHIR Registering a SMART App with an EHR:</span></p><p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-size:13.3333px;font-family:Arial;color:rgb(0,0,0);background-color:transparent;font-weight:normal;font-style:italic;font-variant:normal;text-decoration:none;vertical-align:baseline">“...the app must be registered with that EHR's authorization service.”</span></p><p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-size:14.6667px;font-family:Arial;color:rgb(0,0,0);background-color:transparent;font-weight:normal;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline">The </span><a href="http://openid.net/wg/heart/charter/" style="text-decoration:none"><span style="font-size:14.6667px;font-family:Arial;color:rgb(17,85,204);background-color:transparent;font-weight:normal;font-style:normal;font-variant:normal;text-decoration:underline;vertical-align:baseline">HEART charter</span></a><span style="font-size:14.6667px;font-family:Arial;color:rgb(0,0,0);background-color:transparent;font-weight:normal;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline"> section 5) requires:</span></p><ul style="margin-top:0pt;margin-bottom:0pt"><li dir="ltr" style="list-style-type:disc;font-size:14.6667px;font-family:Arial;color:rgb(0,0,0);background-color:transparent;font-weight:normal;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline"><p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-size:14.6667px;font-family:Arial;color:rgb(0,0,0);background-color:transparent;font-weight:normal;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline">Support independent authorization services and identity providers, to be chosen by people who may build, run, or outsource these services.</span></p></li></ul><br><p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-size:14.6667px;font-family:Arial;color:rgb(0,0,0);background-color:transparent;font-weight:bold;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline">The HEART charter section 5 also includes the following:</span></p><ul style="margin-top:0pt;margin-bottom:0pt"><li dir="ltr" style="list-style-type:disc;font-size:14.6667px;font-family:Arial;color:rgb(0,0,0);background-color:transparent;font-weight:normal;font-style:italic;font-variant:normal;text-decoration:none;vertical-align:baseline"><p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-size:14.6667px;font-family:Arial;color:rgb(0,0,0);background-color:transparent;font-weight:normal;font-style:italic;font-variant:normal;text-decoration:none;vertical-align:baseline">Leverage lessons learned from the Blue Button+, RHEx and other initiatives and their profiles to the extent possible, and leverage FHIR as a key exemplar of a health data API, recognizing that additional features may be required.</span></p></li></ul><br><p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-size:14.6667px;font-family:Arial;color:rgb(0,0,0);background-color:transparent;font-weight:normal;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline">Experience with CONNECT, Blue Button Plus, and Direct has shown that any institutionally-driven interoperability approach will fragment into islands of trust dictated by the business interests of the implementing resource servers. As with mail, phones, fax, and email, only processes that allow individual people as accountable first-class citizens can create a universal address space for interoperability.</span></p><br><p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-size:14.6667px;font-family:Arial;color:rgb(0,0,0);background-color:transparent;font-weight:bold;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline">The HEART charter section 5 also includes the following:</span></p><ul style="margin-top:0pt;margin-bottom:0pt"><li dir="ltr" style="list-style-type:disc;font-size:14.6667px;font-family:Arial;color:rgb(0,0,0);background-color:transparent;font-weight:normal;font-style:italic;font-variant:normal;text-decoration:none;vertical-align:baseline"><p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-size:14.6667px;font-family:Arial;color:rgb(0,0,0);background-color:transparent;font-weight:normal;font-style:italic;font-variant:normal;text-decoration:none;vertical-align:baseline">Generative (able to be combined and extended to support a variety of use cases in other application domains and emerging application functionality).</span></p></li></ul><br><p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-size:14.6667px;font-family:Arial;color:rgb(0,0,0);background-color:transparent;font-weight:normal;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline">In order to accommodate and scale to include claims payment, implants, wearable devices, home monitors, cross-sectoral ID providers, and non-HL7 data models, the HEART profiles should not be driven by any single industry’s resource definitions. Argonaut, and the EHR community that controls FHIR is a relatively narrow slice of the human health management ecosystem.</span></p><p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><br><span style="font-size:14.6667px;font-family:Arial;color:rgb(0,0,0);background-color:transparent;font-weight:normal;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline"></span></p><p style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-size:14.6667px;font-family:Arial;color:rgb(0,0,0);background-color:transparent;font-weight:normal;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline">I would suggest that we need to try and reach a consensus on one or more use cases to drive HEART before we dive into scopes and the details of profiles.<br></span></p><p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><br><span style="font-size:14.6667px;font-family:Arial;color:rgb(0,0,0);background-color:transparent;font-weight:normal;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline"></span></p><p style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-size:14.6667px;font-family:Arial;color:rgb(0,0,0);background-color:transparent;font-weight:normal;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline">Thanks,</span></p><p style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><br><span style="font-size:14.6667px;font-family:Arial;color:rgb(0,0,0);background-color:transparent;font-weight:normal;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline"></span></p><p style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-size:14.6667px;font-family:Arial;color:rgb(0,0,0);background-color:transparent;font-weight:normal;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline">Adrian<br> </span></p><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jul 16, 2015 at 6:49 PM, Debbie Bucci <span dir="ltr"><<a href="mailto:debbucci@gmail.com" target="_blank">debbucci@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>Thanks so much for this Josh. Justin will be in Prague next week so I would like to postpone the broader scope/approach discussion until he returns and Eve is available as well. I have no answers - just questions and lots of them!</div><div><br></div><div>Instead I would like to use that time as an opportunity to pull the focus back to the PHR *as source of truth* and do as we originally intended - focus on the use case. </div><div><br></div><div>Gajun Sunthara has been building an open source FHIR based PHR from scratch as a way to understand the underlying standards and protocols. It's been amazing to see the concepts develop over time as he's socialized his efforts.</div><div><br></div><div> He has implemented OpenID Connect and has connected to a number FHIR resources and created a local store of his own. Additionally he has a running list of endpoints that seem to align with what I think a personal UMA authorization may look like (at least to a consumer). So many ways to extend those concepts.</div><div><br></div><div>The authorization service - or source of truth will need to be flexible and meet the consumers need across a number of different RS clients and APIs and standards. Gaj's UI makes me believe its possible to do.</div><div><br></div><div><div>if there is time after the demo, I'd like to use to focus on JUST the scopes that a PHR would need to communicate and enable read/write between PHR and PCP as both client and RS.</div><div><br></div><div><br></div><div>Deb</div></div><span class=""><div><br></div><div><br></div><div><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jul 16, 2015 at 11:31 AM, Josh Mandel <span dir="ltr"><<a href="mailto:Joshua.Mandel@childrens.harvard.edu" target="_blank">Joshua.Mandel@childrens.harvard.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;border-left-style:solid"><div dir="ltr"><p style="font-size:12.8px" dir="ltr">As promised: this is the version of the SMART on FHIR specification that includes the most recent changes in response to review from the Argonaut participants: <a href="http://fhir-docs.smarthealthit.org/argonaut-dev/authorization/" target="_blank">http://fhir-docs.smarthealthit.org/argonaut-dev/authorization/</a></p><p style="font-size:12.8px" dir="ltr">Beyond a set of editorial changes, the most relevant updates are:</p><p style="font-size:12.8px" dir="ltr">1. Addition of "aud" as a parameter on the authorization request. This is a security fix that mitigates against a malicious resource server (in the absence of a whitelisting protocol by which public client apps decide which resource servers to trust).</p><p style="font-size:12.8px" dir="ltr">2. Moved "launch:" out of the scopes list and into a separate parameter of the authorization request (this cleans up the semantics of our scopes list a bit, and sounds similar to what we were calling an "audience" on today's phone call).</p><p style="font-size:12.8px" dir="ltr">3. Added a scope called "online_access" (by analogy to the OIDC "offline_access" scope). This scope is used to request a refresh token that lasts until a user signs out of the EHR.</p></div><div class="gmail_extra"><br><div class="gmail_quote"><div><br></div></div></div></blockquote></div></div></span></div>
<br>_______________________________________________<br>
Openid-specs-heart mailing list<br>
<a href="mailto:Openid-specs-heart@lists.openid.net">Openid-specs-heart@lists.openid.net</a><br>
<a href="http://lists.openid.net/mailman/listinfo/openid-specs-heart" rel="noreferrer" target="_blank">http://lists.openid.net/mailman/listinfo/openid-specs-heart</a><br>
<br></blockquote></div><br><br clear="all"><br>-- <br><div class="gmail_signature"><div dir="ltr">Adrian Gropper MD<span style="font-size:11pt"></span><font size="1"><br><font size="2">Ensure Health Information Privacy. Support Patient Privacy Rights.<br></font></font><span style="font-size:11pt"><font size="1"></font></span><font size="2"><a href="http://patientprivacyrights.org/donate-2/" target="_blank"><font color="blue"><u>http://patientprivacyrights.org/donate-2/</u></font></a><font color="blue"><u> </u></font></font><span style="font-size:11pt"></span><span style="font-size:11pt"></span><span style="font-size:11pt"><font size="1"> <br></font><div></div></span><br></div></div>
</div>