[Openid-specs-heart] Resources vs Resource sets
Eve Maler
eve.maler at forgerock.com
Tue Jul 26 16:59:03 UTC 2016
If we have Alice check off the FHIR resources she wants to share
individually and not share them as a prepackaged "first visit" bundle, then
a number of things get a bit easier for the services involved (though the
"HIV problem" doesn't get solved).
We can next set about defining UMA resource sets and their attendant scopes
for that list of FHIR resources. Note that the scopes *can* be unique per
resource set, but need not be.
I recommend that we plan for these to be profiled UMA resource set *types*.
Alice's instance of a medication list type would differ from Carol's, which
would differ from David's, and so on.
*Eve Maler*ForgeRock Office of the CTO | VP Innovation & Emerging Technology
Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl
*ForgeRock Summits and UnSummits* are coming to
<http://summits.forgerock.com/> *Sydney, London, and Paris!*
On Mon, Jul 25, 2016 at 7:19 PM, Nancy Lush <nlush at lgisoftware.com> wrote:
> Hello all,
>
>
>
> My sense is that we want to start with a simple example. Like, Alice can
> choose which resources she wants to share. Those can be from the list
> Debbie displayed today or the list I sent – or whatever the final list
> turns out to be. (The list can be changed later.) But that list is a list
> of ‘FHIR Resources’. Alice can choose to share either all, or she can
> specify which in the list she wishes to share. (I think this is consistent
> with Adrian’s most recent ‘b’ point.)
>
>
>
> While we can have resource sets, I don’t think we need to confuse the
> conversation with that yet.
>
>
>
> Also, we have talked about confidentiality codes and the desire to have
> Alice share her conditions, but exclude her HIV condition. I think as a
> group we would like to be able to do that, but because it is confusing it
> takes us off track. Just temporarily, let’s skip that detail.
>
>
>
> If we start with Alice’s ability to share the FHIR resources, we can work
> that through the more technical issues, and reach a point where we agree.
> We can then add additional detail on top of that.
>
>
>
> As a group we all come from different places, often each of those very
> different places are technical in nature. As a result, one term can have
> different meanings to each individual. I think we are close. The next
> step would be to define the flow for this, then bring it back to the team
> for review.
>
>
>
> -Nancy
>
>
>
>
>
>
>
>
>
> *Nancy Lush *
>
> nancy.lush at lgisoftware.com
>
> *Lush Group, Inc*
>
> Office: (401) 423-9111
>
> 28 Narragansett Ave
>
> PO Box 651
>
> www.lgisoftware.com
>
> Cell:(401) 965-9347
>
> Jamestown, RI 02835
>
>
>
> [image: LGI_logo_small]
>
>
>
>
>
> _______________________________________________
> Openid-specs-heart mailing list
> Openid-specs-heart at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-heart
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-heart/attachments/20160726/8e64b9e1/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.gif
Type: image/gif
Size: 3006 bytes
Desc: not available
URL: <http://lists.openid.net/pipermail/openid-specs-heart/attachments/20160726/8e64b9e1/attachment.gif>
More information about the Openid-specs-heart
mailing list