[Openid-specs-heart] Proposal for UMA+FHIR resource set registration profiling, with key issues

[Eve Maler]

In an ad hoc call today, Nancy, Justin, and I came up with proposed answers
to these questions and also to the question of guidance on when to register
resources. The GDoc (including its comments) shows the results. Brief
answers are also below.


*Eve Maler*ForgeRock Office of the CTO | VP Innovation & Emerging Technology
Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl

On Mon, Dec 19, 2016 at 2:17 PM, Eve Maler <eve.maler at forgerock.com> wrote:

> The GDoc I shared on today's call is here
> <https://docs.google.com/document/d/1JtESkMgZ5FxEM74Ae4OE8MHj0wjAqDY7FpA52XJQtZw/edit?usp=sharing>
> (read-only link; send me a request if you need deeper access).
>
> For those interested in an ad hoc session this week, I can meet at 1pm or
> 2pm ET on Wednesday, or 1pm ET on Thursday.
>
> Key *use case* issues: Please see the table in the doc!
>

See doc comment. For any FHIR resource type, supply that URI in the "type"
property. Still to be answered: Whether we want to impose any constraints
on targeted types, or profile how to use any types (e.g. Bundle, specifics
of Observation, etc.).


>
> Key *technical/spec* issues for discussion:
>
> *Set list of scopes vs. flexibility*
> Require all resource servers to include the same list of scopes, or allow
> them flexibility? Considerations: interoperability, patient empowerment, RS
> capabilities...
>

See doc wording. Flexibility allowed.


>
> *The * scope idea*
> Should the profile dictate the availability of an "all" scope that stands
> for all of the possible scopes? Considerations: Standardizing it vs.
> letting individual RS's offer it if they want to, semantics of choosing
> this scope while also choosing other scopes, growth of future UMA best
> practices...
>

See doc comment. * not added.


>
> *Legitimacy of RS scopes outside HEART choices*
> Okay to let RS's add other non-HEART scopes? If so, are there any
> constraints on what those scopes can be? Considerations: interoperability,
> patient empowerment...
>

See doc comment. Non-HEART scopes implicitly legitimate.


>
> *Mixed FHIR/non-FHIR servers*
> Is the current way of handling mixed servers a good one, where any one
> registered resource set that is tied to a FHIR resource type has to be
> served in a FHIR-conforming way? Do we need to be more specific about
> meaning "read" scope"? Should we way something about requiring HEART
> clients to "write" FHIR resource data in a conforming way as well?
> Considerations: interoperability...
>

See doc comment. Excessively explicit text removed; "correspondence"
between UMA resource sets and FHIR resource types sufficient.


>
> *New issue: Hybrid FHIR/non-FHIR resources*
> Is it possible to have such a thing as a hybrid or extended FHIR resource?
> If so, how would or could such a thing be handled? Considerations:
> interoperability...
>

Oops! We didn't actually talk about this explicitly. Discuss?


>
> *Cardinality of how many RS's can register a resource of the same FHIR
> type (or HEART bundle type) for the same patient, and what a client does
> with this situation*
> Need to say something about this? This depends on use cases/API calls. See
> the discussion in the doc.
>
> *New issue: Cardinality of how many resources of the same FHIR type (or
> HEART bundle type) the same RS can register for the same patient, and what
> a client does with this situation*
> Need to say something about this? This depends on use cases/API calls.
>

No action on both of these; they're exclusively the province of the
semantic API (FHIR), not this profile.


>
> *Eve Maler*ForgeRock Office of the CTO | VP Innovation & Emerging
> Technology
> Cell +1 425.345.6756 <(425)%20345-6756> | Skype: xmlgrrl | Twitter:
> @xmlgrrl
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-heart/attachments/20161221/42fa2aa6/attachment.html>