<div dir="ltr"><div><div><div><div><div><div>Thanks, John - I missed that.<br><br></div>Maybe this opens an opportunity:<br><br></div>(1) and (3) The RS uses FHIR Consent to encode the UMA Resource Registration (before the Client shows up). <br><br></div>(2) If the UMA AS is HEART-aware, it grants a scope coded with FHIR Consent. <br><br></div>(4) If the UMA AS is not HEART-aware the FHIR Resource Server may not support date and page ranges until the UMA spec deals with this.<br><br></div>In other words, HEART profiles specify that the RS MAY use FHIR Consent to manage the assignment of any UMA AS as Substitute Decision Maker. If the RS supports FHIR Consent, then it MAY register a "FHIR Consent" scope along with other plain scopes. The UMA AS does not know or care about this. <br><br>Later, when the Client shows up to the AS and asks for scopes: a HEART-aware AS issues a token encoded as per FHIR Consent. If the UMA AS is not HEART-aware, the Client can only get a subset of the plain scopes.<br><br></div><div>This should make everyone happy. The UMA AS can encode the patient's policies into a FHIR Consent standard without actually sharing the policies themselves but a generic UMA AS can still provide interoperability to the limit of the UMA standard. The RS should be happy because it's can receive complex authorizations in a standard format while also being interoperable on the basis of whatever scopes UMA supports. Patients that want fine-grained authorizations will have an incentive to select a FHIR-aware AS but it's their choice. UMA has an incentive to deal with date and page ranges when it's ready. <br></div><div><br></div>Adrian<br><div><div><br><br><div><br><br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Aug 10, 2016 at 10:57 PM, John Moehrke <span dir="ltr"><<a href="mailto:johnmoehrke@gmail.com" target="_blank">johnmoehrke@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><p dir="ltr">Adrian</p>
<p dir="ltr">2. Consent.period</p><span class="HOEnZb"><font color="#888888">
<p dir="ltr">John</p></font></span><div class="HOEnZb"><div class="h5">
<div class="gmail_extra"><br><div class="gmail_quote">On Aug 10, 2016 5:00 PM, "Adrian Gropper" <<a href="mailto:agropper@healthurl.com" target="_blank">agropper@healthurl.com</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Thank you John for pointing us to a specific document so that we can figure out how the UMA AS and UMA scopes might interact with the HL7 work. Looking at the spec I can ask a few specific (sic) questions which I have numbered below:<br><div><div><br>(1) To Ken's question, the NYP ROI Authorization Form is at <a href="https://dl.dropboxusercontent.com/u/8909568/NYP%20authorization.pdf" target="_blank">https://dl.dropboxusercontent.<wbr>com/u/8909568/NYP%20authorizat<wbr>ion.pdf</a> Is it fair to say that the FHIR Consent resource <a href="http://hl7-fhir.github.io/consent.html" target="_blank">http://hl7-fhir.github.io/cons<wbr>ent.html</a> is designed to capture the content of the executed NYP ROI Form in a legally accountable way, regardless of how actual sharing will be enforced?<br><br></div><div>(2) I don't see any particular way to express date ranges in the Consent spec. Maybe this is to be handled through extensions. If the purpose of standardizing the Consent resource is interoperability, then it seems to me that a lot of profiling will need to be done and it's not clear who will do that profiling. I believe HL7 FHIR has an 80% rule. Does the Consent spec require profiling to reach the 80% level? (Being able to encode the NYP ROI Form would meet the 80% threshold for me.) If profiling is needed to reach 80%, who will do that profiling?<br><br></div><div>(3) The Privacy Consent Directive <a href="http://hl7-fhir.github.io/consent.html#6.4.1.1" target="_blank">http://hl7-fhir.github.io/cons<wbr>ent.html#6.4.1.1</a> introduces the term Substitute Decision Maker which is not mentioned anywhere else in the document. Could the UMA AS be the Substitute Decision Maker this section is referencing? If so, then point us to a spec for Substitute Decision Maker and we will make progress on the relationship between FHIR and HEART.<br><br></div><div>I agree with John that (c) Both is the preferred solution. (b) has nothing to do with UMA and HEART. (a) is unrealistic, impractical, and undesirable because it assumes a massive bureaucracy that protects all the institutions and all of the patients in all circumstances. This kind of bureaucracy has been elusive (see the UK NHS care.data news for an example of trying to do this in a single national system) and review the history of NHIN for the US equivalent. Option (c) is already supported by the UMA spec because it allows the UMA resource server to impose whatever jurisdictional and business rules it chooses regardless of what the UMA AS authorization token and associated scopes may say. <br><br></div><div>John is clear on the user experience aspects of the discussion. Whether an UMA AS chooses to implement FHIR Consent in order to improve the user experience may not be relevant to the HEART scope discussion. Authorization Servers can compete on their user experience without harming interoperability for FHIR endpoints labeled HEART. The interoperability rule (be liberal in what you accept and strict in what you send out) applies.<br><br></div><div>(4) The sine-qua-non for interoperability is that any Client labeled HEART and any Server labeled HEART must work together under any UMA standard AS. Some UMA AS will be FHIR-aware and others will not. Does anyone interpret the HEART charter as implying that the AS is somehow healthcare specific?<br><br></div><div>As for John's suggestion that we get UMA in the FHIRe door first before we deal with improvements, let's revisit the date or page range issue as part of the relationship between UMA and FHIR as orthogonal standards that we are all in favor of after we make some progress on questions (1) to (4).<br><br></div><div>Adrian<br></div><div><br></div><div><br></div><div><br><br></div><div><br><br></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Aug 10, 2016 at 4:35 PM, John Moehrke <span dir="ltr"><<a href="mailto:johnmoehrke@gmail.com" target="_blank">johnmoehrke@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">Adrian,<div><br></div><div>A Consent Directive is one of the formal terms used for results of a Privacy Consent act/ceremony. Lots of terms for the same thing. There is nothing new being spoken about here. Note these are defined on the FHIR Consent Resource page  </div><div>  <a href="http://hl7-fhir.github.io/consent.html" target="_blank">http://hl7-fhir.github.io/cons<wbr>ent.html</a></div><div><br></div><div>In FHIR ballot about to start (STU3) the concept is managed by the FHIR Consent Resource, rather than a profile on contract. This was done to simplify and focus. ANYONE who is an HL7 member, make sure you signup for the ballot NOW. Outsiders can also participate.</div><div>  <a href="http://www.hl7.org/ctl.cfm?action=ballots.home&ballot_cycle_id=541" target="_blank">www.hl7.org/ctl.cfm?action=b<wbr>allots.home&ballot_cycle_id=54<wbr>1</a> </div><div><br></div><div>The FHIR Consent Resource is only a mechanism for capturing the consent meaning. It is not a mechanism for decision making or enforcement. It is also not a mechanism for interacting with the patient (UI).  The FHIR Consent resource is just a resource. It is not a service. It is not an operational environment. It is not an application. Something else would be the method of intervention upon requests for data about a subject, deciding if it is authorized, and enforcing it.<br></div><div><br></div><div>Where UMA is a method of making decisions and enforcement. UMA leaves the capturing of the rules that it enforces as an implementation detail of the AS. Nore does UMA define a static format for the rules.</div><div><br></div><div>Thus one could:</div><div>a) Use UMA alone, leaving up to UI of the UMA AS to capture the rules, persist the consent experience, etc... This means that UMA AS is used to protect all accesses to protected data about the subject. </div><div>b) Use FHIR Consent to capture the results of the consent ceremony; and all data holding servers would look to the FHIR Consent rules when they themselves decide if a request for data is authorized. </div><div>c) Use FHIR Consent to capture the results of the consent ceremony; and use UMA to make data request authorization decisions.</div><div><br></div><div>So, you could use one, or the other, or both. There is no need for us to constrain one or the other. But we should be aware of all. Clearly the best combination from a standards perspective is (c); but it is also the most complex UMA AS. </div><div><br></div><div>Neither of these is dependent on Scopes. Scopes are an optimization factor. The better aligned Scopes are to the consent rules, the fewer UMA authorization decisions need to be made. If Scopes align well, then one decision authorizing a broader scope value can be re-used in many different transactions by an application against a resource sever. If the scopes don't align well, then authorization decisions need to be on a request by request basis. This is just an optimization. It does not inhibit the rules that the UMA can enforce. I believe I am right, so if I am wrong I hope someone from OAuth/UMA community can illuminate my mistake.</div><div><br></div><div>This is why I recommend we just pick some scopes for now. Similar to what SMART did, they just picked something that was easy to pick.  The real magic that we are enabling is to have UMA involved, and thus getting "User" "Managed" "Access" (Aka Patient Centric Authorizations). Once we get UMA in this position, the UMA AS can be improved. </div><div><br></div><div>John</div></div><div class="gmail_extra"><span><font color="#888888"><br clear="all"><div><div 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 <a href="tel:%2B1%20920-564-2067" value="+19205642067" target="_blank">+1 920-564-2067</a><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/jo<wbr>hnmoehrke</a><br><a href="https://healthcaresecprivacy.blogspot.com" target="_blank">https://healthcaresecprivacy.b<wbr>logspot.com</a><br>"Quis custodiet ipsos custodes?" ("Who watches the watchers?")</div></div></div>
<br></font></span><div class="gmail_quote"><div><div>On Wed, Aug 10, 2016 at 1:57 PM, Adrian Gropper <span dir="ltr"><<a href="mailto:agropper@healthurl.com" target="_blank">agropper@healthurl.com</a>></span> wrote:<br></div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div><div dir="ltr"><div><div><div><div><div>What is a consent directive?<br><br></div>What is the relationship of whatever it is to FHIR or any other standard data model?<br><br></div>How does a consent directive interact with OAuth, UMA or OpenID Connect?<br><br></div>Do you have an example of how a consent directive maps into, replaces, or changes the NYP ROI authorization form?<br><br></div>Thanks,<br><br></div>Adrian<br><div><div><div><div><div><br><br></div></div></div></div></div></div><div><div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Aug 10, 2016 at 2:49 PM, Salyards, Kenneth (SAMHSA/OPPI) <span dir="ltr"><<a href="mailto:Kenneth.Salyards@samhsa.hhs.gov" target="_blank">Kenneth.Salyards@samhsa.hhs.g<wbr>ov</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">





<div link="blue" vlink="purple" lang="EN-US">
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">Fine grained authorization should be dealt with using a patients’ consent directive. FHIR DSTU2 supports consent directive as part of the contract resource.
 In DSTU3, as I understand the consent directive will not be part of contract. This can work seamlessly within the UMA resource server construct. Ken<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></p>
<div>
<div style="border:none;border-top:solid #b5c4df 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif"">From:</span></b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif""> Openid-specs-heart [mailto:<a href="mailto:openid-specs-heart-bounces@lists.openid.net" target="_blank">openid-specs-heart-bou<wbr>nces@lists.openid.net</a>]
<b>On Behalf Of </b>Vivek Biswas<br>
<b>Sent:</b> Wednesday, August 10, 2016 1:50 PM<br>
<b>To:</b> Adrian Gropper; <a href="mailto:openid-specs-heart@lists.openid.net" target="_blank">openid-specs-heart@lists.openi<wbr>d.net</a><br>
<b>Cc:</b> Josh Mandel; Grahame Grieve</span></p><div><div><br>
<b>Subject:</b> Re: [Openid-specs-heart] HEART Scope Design Proposal #1<u></u><u></u></div></div><p></p>
</div>
</div><div><div>
<p class="MsoNormal"><u></u> <u></u></p>
<div>
<div>
<p class="MsoNormal" style="background:white"><span style="font-family:"Verdana","sans-serif";color:black">Hi Adrian,<u></u><u></u></span></p>
</div>
<div>
<p class="MsoNormal" style="background:white"><span style="font-family:"Verdana","sans-serif";color:black"><u></u> <u></u></span></p>
</div>
<div>
<p class="MsoNormal" style="background:white"><span style="font-family:"Verdana","sans-serif";color:black">The scopes are meant to do coarse-grained authorization and not fine grained authorization.<u></u><u></u></span></p>
</div>
<div>
<p class="MsoNormal" style="background:white"><span style="font-family:"Verdana","sans-serif";color:black"><u></u> <u></u></span></p>
</div>
<div>
<p class="MsoNormal" style="background:white"><span style="font-family:"Verdana","sans-serif";color:black">And hence, this one of the reason why scopes are static string.<u></u><u></u></span></p>
</div>
<div>
<p class="MsoNormal" style="background:white"><span style="font-family:"Verdana","sans-serif";color:black"><u></u> <u></u></span></p>
</div>
<div>
<p class="MsoNormal" style="background:white"><span style="font-family:"Verdana","sans-serif";color:black">If one want to perform fine grained authorization, then its based on lot of contextual information like you mention, date-range, geo-location, etc....<u></u><u></u></span></p>
</div>
<div>
<p class="MsoNormal" style="background:white"><span style="font-family:"Verdana","sans-serif";color:black"><u></u> <u></u></span></p>
</div>
<div>
<p class="MsoNormal" style="background:white"><span style="font-family:"Verdana","sans-serif";color:black">The contextual information can reside in the Request Payload, in database, within the access token (if JWT) etc. All these contextual information associated
 with the request can be trusted only if the access token is valid. <u></u><u></u></span></p>
</div>
<div>
<p class="MsoNormal" style="background:white"><span style="font-family:"Verdana","sans-serif";color:black"><u></u> <u></u></span></p>
</div>
<div>
<p class="MsoNormal" style="background:white"><span style="font-family:"Verdana","sans-serif";color:black">There can be a policy associated with context which can help us to decide if the request should be authorized or not.<u></u><u></u></span></p>
</div>
<div>
<p class="MsoNormal" style="background:white"><span style="font-family:"Verdana","sans-serif";color:black"><u></u> <u></u></span></p>
</div>
<div>
<p class="MsoNormal" style="background:white"><span style="font-family:"Verdana","sans-serif";color:black">So, scopes can help you do first level of coarse grain authorization which will yield you an access token. Once an access token is valid, grab the contextual
 information from the payload, header, access token etc. Find a policy associated with the contextual object and than perform fine level authorization based on the policy.<u></u><u></u></span></p>
</div>
<div>
<p class="MsoNormal" style="background:white"><span style="font-family:"Verdana","sans-serif";color:black"><u></u> <u></u></span></p>
</div>
<div>
<p class="MsoNormal" style="background:white"><span style="font-family:"Verdana","sans-serif";color:black"><u></u> <u></u></span></p>
</div>
<div>
<p class="MsoNormal" style="background:white"><span style="font-family:"Verdana","sans-serif";color:black">Regards<u></u><u></u></span></p>
</div>
<div>
<p class="MsoNormal" style="background:white"><span style="font-family:"Verdana","sans-serif";color:black">Vivek Biswas, CISSP<u></u><u></u></span></p>
</div>
<div>
<p class="MsoNormal" style="background:white"><span style="font-family:"Verdana","sans-serif";color:black">Consulting Member @Oracle<u></u><u></u></span></p>
</div>
<div>
<p class="MsoNormal" style="background:white"><span style="font-family:"Verdana","sans-serif";color:black"><u></u> <u></u></span></p>
</div>
<div>
<p class="MsoNormal" style="background:white"><span style="font-family:"Verdana","sans-serif";color:black"><u></u> <u></u></span></p>
</div>
<div>
<p class="MsoNormal" style="background:white"><span style="font-family:"Verdana","sans-serif";color:black"><u></u> <u></u></span></p>
</div>
<div>
<div>
<div>
<div>
<div class="MsoNormal" style="text-align:center;background:white" align="center">
<span style="font-size:10.0pt;font-family:"Arial","sans-serif";color:black">
<hr width="100%" size="1" align="center">
</span></div>
<p class="MsoNormal" style="background:white"><b><span style="font-size:10.0pt;font-family:"Arial","sans-serif";color:black">From:</span></b><span style="font-size:10.0pt;font-family:"Arial","sans-serif";color:black"> Adrian Gropper <<a href="mailto:agropper@healthurl.com" target="_blank">agropper@healthurl.com</a>><br>
<b>To:</b> "<a href="mailto:openid-specs-heart@lists.openid.net" target="_blank">openid-specs-heart@lists.open<wbr>id.net</a>" <<a href="mailto:openid-specs-heart@lists.openid.net" target="_blank">openid-specs-heart@lists.open<wbr>id.net</a>>
<br>
<b>Cc:</b> Justin Richer <<a href="mailto:jricher@mit.edu" target="_blank">jricher@mit.edu</a>>; Vivek Biswas <<a href="mailto:vivek_biswas@yahoo.com" target="_blank">vivek_biswas@yahoo.com</a>>; Josh Mandel <<a href="mailto:jmandel@gmail.com" target="_blank">jmandel@gmail.com</a>>; Grahame Grieve <<a href="mailto:grahame@healthintersections.com.au" target="_blank">grahame@healthintersections.c<wbr>om.au</a>><br>
<b>Sent:</b> Tuesday, August 9, 2016 12:57 PM<br>
<b>Subject:</b> Re: [Openid-specs-heart] HEART Scope Design Proposal #1</span><span style="font-family:"Helvetica","sans-serif";color:black"><u></u><u></u></span></p>
</div>
<div>
<p class="MsoNormal" style="background:white"><span style="font-family:"Helvetica","sans-serif";color:black"><u></u> <u></u></span></p>
<div>
<div>
<div>
<p class="MsoNormal" style="background:white"><span style="font-family:"Helvetica","sans-serif";color:black">There are many reasons why we need to find a way:<u></u><u></u></span></p>
<ol start="1" type="1">
<li class="MsoNormal" style="color:black;background:white">
<span style="font-family:"Helvetica","sans-serif"">I have never seen a release of information form that did not have a date range. Has anyone? If we say HEART can't do that we're calling into question the legitimacy of HEART.<u></u><u></u></span></li><li class="MsoNormal" style="color:black;background:white">
<span style="font-family:"Helvetica","sans-serif"">We have a lot of experience with 75-page CCDAs with the current standards. Many patients have huge health records and it is resource-intensive to get 74-pages of information you already had in order to find
 the change from the last encounter. The cost is not just on the sender but on the recipient as well. This is probably the top complaint of the current interop methods in my medical society.<u></u><u></u></span></li><li class="MsoNormal" style="color:black;background:white">
<span style="font-family:"Helvetica","sans-serif"">I don't think the HEART charter set a particular limit on how much of FHIR we would manage. It's not in our charter to treat effective provider-to-provider exchange as out-of-scope. Once we say that HEART will
 not support the full patient-level feature set of FHIR, where do we draw the line?<u></u><u></u></span></li><li class="MsoNormal" style="color:black;background:white">
<span style="font-family:"Helvetica","sans-serif"">UMA is not OAuth. The goals of the two standards are very different. UMA and HEART are patient-centered. If we restrict HEART to a small fraction of the longitudinal health records or patient-centered health
 rerecords transactions (because most of the traffic stays in the batch or institution-to-institution domain) then where do we host the discussion on a future for patient-centered records?<u></u><u></u></span></li><li class="MsoNormal" style="color:black;background:white">
<span style="font-family:"Helvetica","sans-serif"">There is no logical reason for HEART to not support date ranges once FHIR has that capability. In some jurisdictions, this would be seen as reducing patient's right of access and subject to legal challenge.
<u></u><u></u></span></li></ol>
<div>
<p class="MsoNormal" style="background:white"><span style="font-family:"Helvetica","sans-serif";color:black">I've added Josh and Grahame to this thread. Let's try and find the solution to this problem even if it involves changing UMA, FHIR or both.<u></u><u></u></span></p>
</div>
<div>
<p class="MsoNormal" style="background:white"><span style="font-family:"Helvetica","sans-serif";color:black">Adrian<u></u><u></u></span></p>
</div>
<div>
<p class="MsoNormal" style="background:white"><span style="font-family:"Helvetica","sans-serif";color:black"><u></u> <u></u></span></p>
<div>
<div>
<p class="MsoNormal" style="background:white"><span style="font-family:"Helvetica","sans-serif";color:black">On Tue, Aug 9, 2016 at 12:31 PM, Vivek Biswas <<a href="mailto:vivek_biswas@yahoo.com" target="_blank">vivek_biswas@yahoo.com</a>> wrote:<u></u><u></u></span></p>
<div>
<div>
<p class="MsoNormal" style="background:white"><span style="font-family:"Helvetica","sans-serif";color:black">I agree with Justin, that scopes are static string vs scope string be parameterized. Most of the OAuth server support static string. <u></u><u></u></span></p>
</div>
<div>
<p class="MsoNormal" style="background:white"><span style="font-family:"Helvetica","sans-serif";color:black"><u></u> <u></u></span></p>
</div>
<div>
<p class="MsoNormal" style="background:white"><span style="font-family:"Helvetica","sans-serif";color:black">It will get challenging to implement a profile which requires dynamic string which in turn will hamper the adoption of HEART.<u></u><u></u></span></p>
</div>
<div>
<p class="MsoNormal" style="background:white"><span style="font-family:"Helvetica","sans-serif";color:black"><u></u> <u></u></span></p>
</div>
<div>
<p class="MsoNormal" style="background:white"><span style="font-family:"Helvetica","sans-serif";color:black">We are trying to add contextual information into the scope which are not what scopes are intended for.<u></u><u></u></span></p>
</div>
<div>
<p class="MsoNormal" style="background:white"><span style="font-family:"Helvetica","sans-serif";color:black"><br>
Regards<u></u><u></u></span></p>
<div>
<p class="MsoNormal" style="background:white"><span style="font-family:"Helvetica","sans-serif";color:black">Vivek Biswas, CISSP<u></u><u></u></span></p>
</div>
<div>
<p class="MsoNormal" style="background:white"><span style="font-family:"Helvetica","sans-serif";color:black">Consulting member @Oracle <u></u><u></u></span></p>
</div>
</div>
<div>
<div>
<div>
<p class="MsoNormal" style="margin-bottom:12.0pt;background:white"><span style="font-family:"Helvetica","sans-serif";color:black"><br>
On Aug 9, 2016, at 9:17 AM, Justin Richer <<a href="mailto:jricher@mit.edu" target="_blank">jricher@mit.edu</a>> wrote:<u></u><u></u></span></p>
</div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<p class="MsoNormal" style="background:white"><span style="font-family:"Helvetica","sans-serif";color:black">A problem I can see with this is that the “date” field in particular moves this from something that’s expressible as a table of known strings (like
 in the appendix of the current spec) to something that’s dynamically parameterized with a potentially infinite set of values. This is a problem in practice as many OAuth implementations treat all scopes as static strings, and will do things like limit set
 set of scopes a client is allowed to ask for based on a set of registered strings. That’s not possible with a field like “date” anymore, since the value is filled in at runtime. We tried to have parameterized scopes in BB+ (and even implemented it) but it
 was generally thought to be too complicated, and required special tooling at the authorizations server.<u></u><u></u></span></p>
<div>
<p class="MsoNormal" style="background:white"><span style="font-family:"Helvetica","sans-serif";color:black"><u></u> <u></u></span></p>
</div>
<div>
<p class="MsoNormal" style="background:white"><span style="font-family:"Helvetica","sans-serif";color:black">If at all possible, I’d like HEART scopes to not require such special processing and support at the AS.<u></u><u></u></span></p>
<div>
<p class="MsoNormal" style="background:white"><span style="font-family:"Helvetica","sans-serif";color:black"><u></u> <u></u></span></p>
</div>
<div>
<p class="MsoNormal" style="background:white"><span style="font-family:"Helvetica","sans-serif";color:black"> — Justin<u></u><u></u></span></p>
</div>
<div>
<p class="MsoNormal" style="background:white"><span style="font-family:"Helvetica","sans-serif";color:black"><u></u> <u></u></span></p>
<div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<p class="MsoNormal" style="background:white"><span style="font-family:"Helvetica","sans-serif";color:black">On Aug 8, 2016, at 9:08 PM, Adrian Gropper <<a href="mailto:agropper@healthurl.com" target="_blank">agropper@healthurl.com</a>> wrote:<u></u><u></u></span></p>
</div>
<p class="MsoNormal" style="background:white"><span style="font-family:"Helvetica","sans-serif";color:black"><u></u> <u></u></span></p>
<div>
<div>
<div>
<p class="MsoNormal" style="margin-bottom:12.0pt;background:white"><span style="font-family:"Helvetica","sans-serif";color:black">Scope Design Proposal #1 aims to support
<a href="https://dl.dropboxusercontent.com/u/8909568/NYP%20authorization.pdf" target="_blank">
a typical ROI authorization</a>.<u></u><u></u></span></p>
</div>
<p class="MsoNormal" style="background:white"><span style="font-family:"Helvetica","sans-serif";color:black">The structure of SDP1 is: patient/<a href="http://hl7.org/fhir/search.html#date" target="_blank">date</a>/<a href="http://hl7-fhir.github.io/v3/ConfidentialityClassification/vs.html" target="_blank">confidentialitycl
 ass</a>/<a href="http://hl7.org/fhir/resourcelist.html" target="_blank">resource</a>/edit<u></u><u></u></span></p>
<div>
<p class="MsoNormal" style="background:white"><span style="font-family:"Helvetica","sans-serif";color:black"><br>
The logic is as follows:<u></u><u></u></span></p>
</div>
<div>
<ul type="disc">
<li class="MsoNormal" style="color:black;background:white">
<span style="font-family:"Helvetica","sans-serif"">/patient because this applies to only one patient at a time. The patient ID is local to the resource server.<u></u><u></u></span></li><li class="MsoNormal" style="color:black;background:white">
<span style="font-family:"Helvetica","sans-serif"">/<a href="http://hl7.org/fhir/search.html#date" target="_blank">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<u></u><u></u></span></li><li class="MsoNormal" style="color:black;background:white">
<span style="font-family:"Helvetica","sans-serif"">/<a href="http://hl7-fhir.github.io/v3/ConfidentialityClassification/vs.html" target="_blank">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.<u></u><u></u></span></li><li class="MsoNormal" style="color:black;background:white">
<span style="font-family:"Helvetica","sans-serif"">/<a href="http://hl7.org/fhir/resourcelist.html" target="_blank">resource</a> is any resource listed in the particular version of the FHIR specification<u></u><u></u></span></li><li class="MsoNormal" style="color:black;background:white">
<span style="font-family:"Helvetica","sans-serif"">/edit is "read", "write", "any" operation by the client on the resource<u></u><u></u></span></li></ul>
<div>
<p class="MsoNormal" style="background:white"><span style="font-family:"Helvetica","sans-serif";color:black">A client might request a scope for immunizations for patient 23 as:<u></u><u></u></span></p>
</div>
<pre style="background:white"><span style="color:black">[ "date=le2016-8-8","conclass=N" , "resource=Immunization", "edit=read" ]<br></span><span style="font-family:"Arial","sans-serif";color:black"><br>on a resource registered as:</span><span style="color:black"> [base]/Patient/23/</span><span style="font-family:"Arial","sans-serif";color:black"> 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: [base]/Patient/23/ MentalHealthTx with whatever scopes it offered. <br>These additional resources would not be specified by HEART.<br><br>Any particular RS could choose to support Confidentiality Class, additional resources, neither, or both. <br><br>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.</span><span style="color:black"><u></u><u></u></span></pre>
<p class="MsoNormal" style="margin-bottom:12.0pt;background:white"><span style="font-family:"Helvetica","sans-serif";color:black">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.<u></u><u></u></span></p>
</div>
<div>
<p class="MsoNormal" style="background:white"><span style="font-family:"Helvetica","sans-serif";color:black">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. <u></u><u></u></span></p>
</div>
<div>
<pre style="background:white"><span style="font-family:"Arial","sans-serif";color:black">Adrian</span><span style="color:black"><u></u><u></u></span></pre>
</div>
<div>
<p class="MsoNormal" style="background:white"><span style="font-family:"Arial","sans-serif";color:black"><br>
</span><span style="font-family:"Helvetica","sans-serif";color:black"><br clear="all">
<u></u><u></u></span></p>
<div>
<div>
<p class="MsoNormal" style="background:white"><span style="font-family:"Helvetica","sans-serif";color:black"><br>
-- <u></u><u></u></span></p>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<p class="MsoNormal" style="background:white"><span style="font-family:"Helvetica","sans-serif";color:black"><u></u> <u></u></span></p>
<div>
<p class="MsoNormal" style="background:white"><span style="font-family:"Helvetica","sans-serif";color:black">Adrian Gropper MD<br>
<br>
PROTECT YOUR FUTURE - RESTORE Health Privacy!<br>
HELP us fight for the right to control personal health data.<br>
DONATE: <a href="http://patientprivacyrights.org/donate-2/" target="_blank"><span style="color:#0563c1">http://patientprivacyrights. org/donate-2/</span></a>
<u></u><u></u></span></p>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
<p class="MsoNormal" style="background:white"><span style="font-family:"Helvetica","sans-serif";color:black">______________________________ _________________<br>
Openid-specs-heart mailing list<br>
<a href="mailto:Openid-specs-heart@lists.openid.net" target="_blank">Openid-specs-heart@lists. openid.net</a><br>
<a href="http://lists.openid.net/mailman/listinfo/openid-specs-heart" target="_blank">http://lists.openid.net/ mailman/listinfo/openid-specs- heart</a><u></u><u></u></span></p>
</div>
</blockquote>
</div>
<p class="MsoNormal" style="background:white"><span style="font-family:"Helvetica","sans-serif";color:black"><u></u> <u></u></span></p>
</div>
</div>
</div>
</blockquote>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<p class="MsoNormal" style="background:white"><span style="font-family:"Helvetica","sans-serif";color:black">______________________________ _________________<br>
Openid-specs-heart mailing list<br>
<a href="mailto:Openid-specs-heart@lists.openid.net" target="_blank">Openid-specs-heart@lists. openid.net</a><br>
<a href="http://lists.openid.net/mailman/listinfo/openid-specs-heart" target="_blank">http://lists.openid.net/ mailman/listinfo/openid-specs- heart</a><u></u><u></u></span></p>
</div>
</blockquote>
</div>
</div>
</div>
</div>
</div>
<p class="MsoNormal" style="background:white"><span style="font-family:"Helvetica","sans-serif";color:black"><br>
<br clear="all">
<br>
-- <u></u><u></u></span></p>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<p class="MsoNormal" style="background:white"><span style="font-family:"Helvetica","sans-serif";color:black"><u></u> <u></u></span></p>
<div>
<p class="MsoNormal" style="background:white"><span style="font-family:"Helvetica","sans-serif";color:black">Adrian Gropper MD<br>
<br>
PROTECT YOUR FUTURE - RESTORE Health Privacy!<br>
HELP us fight for the right to control personal health data.<br>
DONATE: <a href="http://patientprivacyrights.org/donate-2/" target="_blank"><span style="color:#0563c1">http://patientprivacyrights.or<wbr>g/donate-2/</span></a>
<u></u><u></u></span></p>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
<p class="MsoNormal" style="margin-bottom:12.0pt;background:white"><span style="font-family:"Helvetica","sans-serif";color:black"><u></u> <u></u></span></p>
</div>
</div>
</div>
</div>
</div>
</div></div></div>
</div>

</blockquote></div><br><br clear="all"><br>-- <br><div 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:#1f497d">PROTECT YOUR FUTURE - RESTORE Health Privacy!</span><span style="font-family:"Arial",sans-serif;color:#1f497d"><br>HELP us fight for the right to control personal health data.</span><span style="font-family:"Arial",sans-serif;color:#1f497d"></span><span style="font-family:"Arial",sans-serif;color:#1f497d"><br>DONATE:
<a href="http://patientprivacyrights.org/donate-2/" target="_blank"><span style="color:#0563c1">http://patientprivacyrights.or<wbr>g/donate-2/</span></a></span><span style="color:#1f497d"></span>
</div></div></div></div></div></div></div></div>
</div>
</div></div><br></div></div><span>______________________________<wbr>_________________<br>
Openid-specs-heart mailing list<br>
<a href="mailto:Openid-specs-heart@lists.openid.net" target="_blank">Openid-specs-heart@lists.openi<wbr>d.net</a><br>
<a href="http://lists.openid.net/mailman/listinfo/openid-specs-heart" rel="noreferrer" target="_blank">http://lists.openid.net/mailma<wbr>n/listinfo/openid-specs-heart</a><br>
<br></span></blockquote></div><br></div>
</blockquote></div><br><br clear="all"><br>-- <br><div 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:#1f497d">PROTECT YOUR FUTURE - RESTORE Health Privacy!</span><span style="font-family:"Arial",sans-serif;color:#1f497d"><br>HELP us fight for the right to control personal health data.</span><span style="font-family:"Arial",sans-serif;color:#1f497d"></span><span style="font-family:"Arial",sans-serif;color:#1f497d"><br>DONATE:
<a href="http://patientprivacyrights.org/donate-2/" target="_blank"><span style="color:#0563c1">http://patientprivacyrights.or<wbr>g/donate-2/</span></a></span><span style="color:#1f497d"></span>
</div></div></div></div></div></div></div></div>
</div>
</blockquote></div></div>
</div></div></blockquote></div><br><br clear="all"><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:#1f497d">PROTECT YOUR FUTURE - RESTORE Health Privacy!</span><span style="font-family:"Arial",sans-serif;color:#1f497d"><br>HELP us fight for the right to control personal health data.</span><span style="font-family:"Arial",sans-serif;color:#1f497d"></span><span style="font-family:"Arial",sans-serif;color:#1f497d"><br>DONATE:
<a href="http://patientprivacyrights.org/donate-2/" target="_blank"><span style="color:#0563c1">http://patientprivacyrights.org/donate-2/</span></a></span><span style="color:#1f497d"></span>
</div></div></div></div></div></div></div></div>
</div></div></div></div></div>