[Openid-specs-heart] Draft HEART meeting notes 2015-07-13

Fri Jul 17 01:34:40 UTC 2015

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.

in the SMART on FHIR Authorization Guide:

   -

   Use Case 1: Patient uses a provider-approved web application to access
   health data
   -

   Use Case 2: Patient uses provider-approved mobile app to access health
   data
   -

   Use Case 3: Clinician uses provider-approved web application to access
   health data
   -

   Use Case 4: Clinician uses provider-approved mobile app to access health
   data

These use-cases are irrelevant to HEART because they do not support
symmetrical interface between two Resource Servers in separate security
domains.

The relevant Argonaut use-case:

   -

   Use Case 5 (future: Provider using EHR A access patient record held in
   EHR B

is explicitly out of scope for Argonaut and a requirement for HEART.

in  the SMART on FHIR Registering a SMART App with an EHR:

“...the app must be registered with that EHR's authorization service.”

The HEART charter <http://openid.net/wg/heart/charter/> section 5) requires:

   -

   Support independent authorization services and identity providers, to be
   chosen by people who may build, run, or outsource these services.

The HEART charter section 5 also includes the following:

   -

   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.

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.

The HEART charter section 5 also includes the following:

   -

   Generative (able to be combined and extended to support a variety of use
   cases in other application domains and emerging application functionality).

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.

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.

Thanks,

Adrian

On Thu, Jul 16, 2015 at 6:49 PM, Debbie Bucci <debbucci at gmail.com> wrote:

> 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!
>
> 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.
>
> 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.
>
>  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.
>
> 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.
>
> 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.
>
>
> Deb
>
>
>
>
> On Thu, Jul 16, 2015 at 11:31 AM, Josh Mandel <
> Joshua.Mandel at childrens.harvard.edu> wrote:
>
>> 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:
>> http://fhir-docs.smarthealthit.org/argonaut-dev/authorization/
>>
>> Beyond a set of editorial changes, the most relevant updates are:
>>
>> 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).
>>
>> 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).
>>
>> 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.
>>
>>
>>
> _______________________________________________
> Openid-specs-heart mailing list
> Openid-specs-heart at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-heart
>
>

-- 
Adrian Gropper MD
Ensure Health Information Privacy. Support Patient Privacy Rights.
*http://patientprivacyrights.org/donate-2/*
<http://patientprivacyrights.org/donate-2/>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-heart/attachments/20150716/c58a8795/attachment.html>