[Openid-specs-heart] How do you define a resource set?

[John Moehrke]

Debbie,

You can continue to hope that the way FHIR divides up Resources is useful
for Privacy enforcement, but it is simply not true. I have expressed this
multiple times. The way that a patient would like to sub-divide their
medical records does not fall nicely along the dividing lines of the types
of Resources. They want to divide along the lines of sensitive health
topics, most want to had-pick the item-by-item.  The FHIR Resource model is
based on the data-model, meaning all things that are Medications are
described in that resource. All things Orderable are described in an Order.
etc. These are organized for structure, not sensitivity.   Yet some
medications would be very sensitive, some orders would be very sensitive,
some observations, some lab results, etc... This is reality.

That does not mean that there is no hope. Just that you can't look to the
FHIR Resource structure.

YES, a Profile mechanism will be useable to create scopes. There likely
will be many profiles for various different regions of the globe. They will
define scopes. These profiles will not be like DAF or USLab or QiCore; but
will be a layer added to these. This layer will be agnostic to the
underlying data profiling layer.

When will this work be done? Likely after far more experience with the
data-model and the data-profiling. But I expect that early success will use
the sensitivity tagging mechanism (security-tags) that I have built into
FHIR. Likely different sub-sets of vocabulary, as the vocabulary you find
in the core specification consists of any security-tag vocabulary item.
That is to say that no one has tried to create practical subsets, as that
is a very political, personal, regional, and many other soft forces..

Hence why I recommend HEART simply adopt either the SMART scopes or the
_confidentiality codes. The _confidentiality codes are in my view closer to
a useable set, and are not specific to FHIR. But the SMART scopes are being
used in demonstration systems and are not out-right-wrong. The important
part is that the scopes we include need to be recognized as a starter-set,
that the actual scopes we will find in production are likely to be totally
different.

You can continue to ignore me... but progress would be far faster if we
focus on what HEART can affect while being transparent about things we
can't control, like the actual subset of scopes... at least right now.

John

John Moehrke
Principal Engineering Architect: Standards - Interoperability, Privacy, and
Security
CyberPrivacy – Enabling authorized communications while respecting Privacy
M +1 920-564-2067
JohnMoehrke at gmail.com
https://www.linkedin.com/in/johnmoehrke
https://healthcaresecprivacy.blogspot.com
"Quis custodiet ipsos custodes?" ("Who watches the watchers?")

On Sat, Jul 2, 2016 at 7:37 AM, Debbie Bucci <debbucci at gmail.com> wrote:

> Think I'm on the verge of understanding....
>
> A well defined implementation profile in FHIR  , such as HL7 defined DAF,
> USLab and QiCore (now absorbed by DAF?), may be equivalent and defined as a
> supported Resource Set in an UMA AS.
>
> That resource set would include a number of scopes including:  permission,
> resource and access types as defined in the profile.
>
> Given we are focused on FHIR API - Would the UMA profile suggest a subset
> of resource types and permissions for a specific use cases example using
> and existing FHIR profile/resource set?
>
> I can see where an implementation of an UMA service may support both
> policy administration and policy information points - using xacml
> terminology or be seen and support consent/sharing preferences perhaps the
> same policies would support both (?)
>
>
>
> _______________________________________________
> 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/20160702/d461c309/attachment.html>