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

[Eve Maler]

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!

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...

*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...

*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...

*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...

*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...

*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.


*Eve Maler*ForgeRock Office of the CTO | VP Innovation & Emerging Technology
Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-heart/attachments/20161219/9cd3319c/attachment.html>