<div dir="ltr"><div>Scope Design Proposal #1 aims to support <a href="https://dl.dropboxusercontent.com/u/8909568/NYP%20authorization.pdf">a typical ROI authorization</a>.<br><br></div>The structure of SDP1 is: patient/<a href="http://hl7.org/fhir/search.html#date">date</a>/<a href="http://hl7-fhir.github.io/v3/ConfidentialityClassification/vs.html">confidentialityclass</a>/<a href="http://hl7.org/fhir/resourcelist.html">resource</a>/edit<br><div><br>The logic is as follows:<br></div><div><ul><li>/patient because this applies to only one patient at a time. The patient ID is local to the resource server.</li><li>/<a href="http://hl7.org/fhir/search.html#date">date</a> is defined by FHIR and can be a range. Putting it at the highest level in the hierarchy (if a scope hierarchy is useful) allows for efficiency in clients requesting updates and reduces the cost to the resource server</li><li>/<a href="http://hl7-fhir.github.io/v3/ConfidentialityClassification/vs.html">confidentialityclass</a> filters for resources at or below the specified value. Resources that do not have a confidentiality class are considered N - Normal. It is up to the resource server to provide jurisdictictionally appropriate policies and user interfaces for setting confidentiality class other than N on particular resources.</li><li>/<a href="http://hl7.org/fhir/resourcelist.html">resource</a> is any resource listed in the particular version of the FHIR specification</li><li>/edit is "read", "write", "any" operation by the client on the resource</li></ul><p>A client might request a scope for immunizations for patient 23 as:</p><pre>[ "date=le2016-8-8","conclass=N", "resource=Immunization", "edit=read" ]<br><span style="font-family:arial,helvetica,sans-serif"><br>on a resource registered as:</span> [base]/Patient/23/<font face="arial,helvetica,sans-serif"> with a reference to HEART scopes SDP1 <br>that would tell both the AS and anyone else that dereferenced HEART/SDP1 that the RS would<br>process specific scope strings for date, confidentialityclass, resource, and edit as described above.<br><br>The AS would be free to present SDP1 to the RO any way that it chose.<br><br>A resource server like NYP that wanted to offer registration for sensitive data like Mental Health Treatment<br>would register another resource: </font><font face="arial,helvetica,sans-serif">[base]/Patient/23/MentalHealthTx with whatever scopes it offered. <br>These additional resources would not be specified by HEART.<br><br></font><font face="arial,helvetica,sans-serif"><font face="arial,helvetica,sans-serif">Any particular RS could choose to support Confidentiality Class, additional resources, neither, or both. <br></font><font face="arial,helvetica,sans-serif"><br></font>It would be up to the AS to combine HEART SDP1 resources and additional resources and scopes offered by the RS into whatever policy setting experience it wanted.<br></font></pre>With this scheme, an AS might offer Alice a policy setting for Observation = R - Restricted even on a resource server that did not support confidentiality class. This would cause all client requests for Observations to fail because the RS would be forced to treat unlabeled resources as N and the authorization tokens for observations were R. The RS could:<br>(a) ignore this problem and treat it as an AS bug, <br>(b) implement confidentiality classification, or <br>(c) offer additional resources and scopes so that the AS could tell Alice that Observations did not include those related to mental health in the hope that Alice would set Observation = N and deal with mental health as a separate part of her policy.<br><br></div><div>I believe that, to a first approximation, SDP1 would capture the functionality of most sharing use-cases without forcing the RS to do anything more than it is jurisdictionally already required to do. <br></div><div><pre><font face="arial,helvetica,sans-serif">Adrian</font></pre></div><div><span style="font-family:arial,helvetica,sans-serif"><br></span><br clear="all"><div><div><br>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><br><div dir="ltr">Adrian Gropper MD<span style="font-size:11pt"></span><br><br><span style="font-family:"Arial",sans-serif;color:rgb(31,73,125)">PROTECT YOUR FUTURE - RESTORE Health Privacy!</span><span style="font-family:"Arial",sans-serif;color:rgb(31,73,125)"><br>HELP us fight for the right to control personal health data.</span><span style="font-family:"Arial",sans-serif;color:rgb(31,73,125)"></span><span style="font-family:"Arial",sans-serif;color:rgb(31,73,125)"><br>DONATE:
<a href="http://patientprivacyrights.org/donate-2/" target="_blank"><span style="color:rgb(5,99,193)">http://patientprivacyrights.org/donate-2/</span></a></span><span style="color:rgb(31,73,125)"></span>
</div></div></div></div></div></div></div></div>
</div></div></div></div>