<div dir="ltr">Debbie,<div><br></div><div>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.</div><div><br></div><div>That does not mean that there is no hope. Just that you can't look to the FHIR Resource structure.</div><div><br></div><div>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.</div><div><br></div><div>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..</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>John</div></div><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr">John Moehrke<br>Principal Engineering Architect: Standards - Interoperability, Privacy, and Security<br>CyberPrivacy – Enabling authorized communications while respecting Privacy<br>M +1 920-564-2067<br><a href="mailto:JohnMoehrke@gmail.com" target="_blank">JohnMoehrke@gmail.com</a><br><a href="https://www.linkedin.com/in/johnmoehrke" target="_blank">https://www.linkedin.com/in/johnmoehrke</a><br><a href="https://healthcaresecprivacy.blogspot.com" target="_blank">https://healthcaresecprivacy.blogspot.com</a><br>"Quis custodiet ipsos custodes?" ("Who watches the watchers?")</div></div></div>
<br><div class="gmail_quote">On Sat, Jul 2, 2016 at 7:37 AM, Debbie Bucci <span dir="ltr"><<a href="mailto:debbucci@gmail.com" target="_blank">debbucci@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div><div><div>Think I'm on the verge of understanding....<br><br></div>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.<br><br></div>That resource set would include a number of scopes including:  permission, resource and access types as defined in the profile.<br><br></div>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?  <br><br></div><div>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 (?)<br></div><div><br><br></div></div>
<br>_______________________________________________<br>
Openid-specs-heart mailing list<br>
<a href="mailto:Openid-specs-heart@lists.openid.net">Openid-specs-heart@lists.openid.net</a><br>
<a href="http://lists.openid.net/mailman/listinfo/openid-specs-heart" rel="noreferrer" target="_blank">http://lists.openid.net/mailman/listinfo/openid-specs-heart</a><br>
<br></blockquote></div><br></div>