<div dir="ltr"><div>So much juiciness in this thread... I am overwhelmed. :-) A couple of thoughts to follow up:</div><div><br></div><div><b>Caching:</b> I guess I'm something of a contrarian on the caching problem. In real life we see a continuum of app and human behavior around how sharing is done, based on:</div><div><ul><li><b>Data volatility over time</b> (stable home addresses make downloading/copying/caching more attractive than volatile calendars do -- for the latter we share URLs, sometimes secured or at least "secret")</li><li><b>"Stasis" of the data operations desired</b> (reading/printing operations makes downloading/copying/caching more attractive than complex API calls do -- for the latter we share endpoints, mostly often secured)<br></li><li><b>Sharing method affordances</b> (by-value methods like generating PDFs, when available, make downloading/copying/caching more attractive than a Share button that lets you create a policy for accessing the original (endpoint-based) source of truth in an access-controlled way)</li></ul><div>One of the original motivations of UMA was precisely to enable protection over a "feed" of data, meaning roughly that a URL from which a fresh version of data can be sourced should be able to be freely shared, without necessarily implying that anyone in possession of the URL automatically gets the data. UMA does not inherently rely on "magic links" or "secret URLs", and thus it helps to boost the affordances around by-reference sharing methods vs by-value methods.</div><div><br></div><div>There are still, of course, other challenges to solve. Genome data is an example of especially non-volatile data; being able to capture "purpose of use" restrictions enforceably is one goal of UMA's legal subgroup, partly to remove some friction around non-volatile data.</div><div><br></div><div>But we were talking about EHR copying and caching on the call. To me, this an example of fairly volatile data that also tends to have much more value when absorbed into a specialized client ecosystemthat knows about the specific API calls to use vs just getting, say, a "dead" PDF. (BTW, my latest UMA demo actually demonstrates how a medical pro can naively share the URL for a patient's IoT bath-scale weight data with a colleague, which doesn't automatically confer access privileges; rather, the resource owner gets a "pending request" that she can field. Happy to share that with y'all at some point.)</div></div><div><br></div><div>Finally, "time-to-live strategy" is a time-honored way to manage some kinds of cache abuse, and UMA has one or two more potential points for managing TTL than even OAuth. Here's a short <a href="https://docs.kantarainitiative.org/uma/draft-uma-core-v1_0_1.html#rfc.section.1.3.4">section</a> that discusses it.</div><div class="gmail_extra"><br></div><div class="gmail_extra"><b>"Relationship-based access control":</b> There was some thread discussion about a) roles being something that could indeed be practical and familiar, at least in the HL7 context, b) groups being a potentially viable approach because of their simplicity and familiarity, particularly with "email-like" identifiers in place, and c) the attractions of having Alice sharing with (what appears to be) a single other individual.</div><div class="gmail_extra"><br></div><div class="gmail_extra">In the interests of time, I didn't go into more detail about another experimental approach I've briefly mentioned on previous calls, but which I think may be helpful here: applying access controls -- that is, policies -- in some automated fashion based on the relationships established between people, and/or between people and things, and/or between things. This could potentially take a lot of confusion out of Alice's interactions and mistakes out of sharing patterns within organizations. In my company we've started referring to this as ReBAC, for relationship-based access control. (From where we're sitting, it starts getting essential real quick when you have to scale to All The Devices...) Thoughts?<br clear="all"><div><div class="gmail_signature"><div dir="ltr"><div><div dir="ltr">
<p><b>Eve Maler<br></b>ForgeRock Office of the CTO | VP Innovation & Emerging Technology<br>Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl<br>Join our <a href="http://forgerock.org/openuma/" target="_blank">ForgeRock.org OpenUMA</a> community!</p></div></div></div></div></div>
<br><div class="gmail_quote">On Tue, Oct 20, 2015 at 2:52 PM, Adrian Gropper <span dir="ltr"><<a href="mailto:agropper@healthurl.com" target="_blank">agropper@healthurl.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr">Our goal is interoperability. I suggest we base our design pattern priorities on (a) the recent GAO report and (b) the doctors in my state medical society. <br><br>(a) <br>Electronic Health Records: Nonfederal Efforts to Help Achieve Health Information Interoperability GAO-15-817: Published: Sep 16, 2015. Publicly Released: Sep 29, 2015.<a href="http://www.gao.gov/products/GAO-15-817" target="_blank"> http://www.gao.gov/products/GAO-15-817</a> that says:<br><div><div><div><br><blockquote style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex" class="gmail_quote">"Stakeholders and initiative representatives GAO interviewed described
five key challenges to achieving EHR interoperability, which are
consistent with challenges described in past GAO work. Specifically, the
challenges they described are (1) insufficiencies in health data
standards, (2) variation in state privacy rules, (3) accurately matching
patients' health records, (4) costs associated with interoperability,
and (5) the need for governance and trust among entities, such as
agreements to facilitate the sharing of information among all
participants in an initiative."<br></blockquote><div><br></div><div>(b)<br>Two MA medical society resolutions and our Task Force (which Dr. Sullivan chairs) have all concluded that physicians need to have control over information sharing for their patients without what ONC calls "blocking" by the institutions or EHR vendors that may be involved. Our Task Force has actually suggested to the AMA that physicians should have a way to get access to the patient-controlled EHR interface. This approach is sometimes referred to as patient-directed exchange. Note that patient-directed exchange does not mean that the patient gets to see her own data (as with a patient-mediated or PHR exchange). The FHIR resource goes directly from the NPE to the Requesting Party. In this way, and with appropriate FHIR cooperation, this helps solve difficult provenance, cache consistency, and patient matching issues. <br><br></div><div>Of the 5 GAO "challenges" (2), (3), and (5) would be completely eliminated by a patient-directed design pattern. (1), the data standards, is a combination of FHIR and HEART outcome. (4), costs, should be equivalent for any FHIR API design pattern, but even if costs were an issue, the patient-directed exchange allows for patient pay to remove that barrier.<br><br></div><div>Choosing to deliver a patient-directed design pattern as our HEART baseline does not preclude either FHIR or HEART from delivering other design patterns in the future but it will inform the work of FHIR and align our efforts with the GAO and physician comments.<br><br></div><div>Therefore, I propose this <a href="http://www.websequencediagrams.com/cgi-bin/cdraw?lz=dGl0bGUgQmFzZWxpbmUgSEVBUlQgU2VxdWVuY2UgRGlhZ3JhbQoKcGFydGljaXBhbnQgIkFsaWNlIHJlc291cmNlXG5vd25lciAoUk8pIiBhcyBSTwAhDk5QRQAiC3NlcnYAKQVTACcHUwBOD2dlbnQgYXV0aG9yaXphdGlvbgArCkEALgdBACYPQm9iIGNsaWVudFxuYXBwIChDAIEFBkMAFRJyZXF1ZXN0aW5nXG5wYXJ0eSAoUnFQAIEzB3FQCm5vdGUgb3ZlciBSTywgUlMsIEFTLCBDLAAYBU5QRSA9IE5vbi1QZXJzb24gRW50aXR5IC8gVGhpcyBpcyB0aGUgSW5kaXZpZHVhbC10by0ABAogRGVzaWduIFBhdHRlcm4KZW5kIG5vdGUKCgpSTy0-UlM6IFByZXNlbnRzIEluIABdBgpSUy0-Uk86IEdldHMgQ3JlZGVudGlhbAAqCVNpZ24gSW4gdG8gTlBFIFBvcnRhbAAtCURpc3BsYXkAFgVST0kgRm9ybQAxCnBlY2lmeSBBdXRoJ3ogUwCCXAoAgQgJVGV4dCBSAINkByBEZXNjcmlwdGlvbgCBLgVBAHIOAIM2BgB7BwCBNAVBUzogRkhJUgAtFkEAgVQHAEMiQ29uZmlybQCBJQUAhA8JIFBvbGljaWVzAEMGAB0KXG4AgSkJUmVnaXN0cgCEQwUAgQkJQ29uc2VudCBSZWNlaXB0CgCDYBUKIEVuZCBvZiBVTUEgUGhhc2UgMQCDKAsAhB0LAIQWDiBScVAgZGlzY292ZXIAhAsGAIYjCCB2aWEgbWVzc2FnZSBvciBkaXJlY3RvcnkgcXVlcnkAhAYLUnFQAIJYBgCECAlDbGFpbXNcbmUuZy4gYm9iQG1lZGljYWxzb2NpZXR5Lm9yZwCCSgZxUACEGRMARwgAgyEMUwBcCk1heSBuZWVkIHRvAIIrB2VyIEMAhkwFAIMgBUMAgiISQwCDeAZSAIZJBnMAgwwOAC0IR3JhbgALEQCCIBsAgmERMgCGGwogCkMAhh4GQWNjZXNzAIRJDgCEZAlBY2NvdW50aW5nIGZvciBEaXNjbG9zdXIAgxUdAINYETMAhxAMCg&s=mscgen" target="_blank">Baseline HEART Sequence Diagram</a> based on the <b>Individual to Individual</b> design pattern (also supported by Justin's comment above). <br><br></div><div>Here's the source code for anyone to improve or fork.<br></div><div><br><font size="1"><span style="font-family:monospace,monospace">title Baseline HEART Sequence Diagram<br><br>participant "Alice resource\nowner (RO)" as RO<br>participant "NPE resource\nserver (RS)" as RS<br>participant "Agent authorization\nserver (AS)" as AS<br>participant "Bob client\napp (C)" as C<br>participant "Bob requesting\nparty (RqP)" as RqP<br>note over RO, RS, AS, C, RqP<br>NPE = Non-Person Entity / This is the Individual-to-Individual Design Pattern<br>end note<br><br><br>RO->RS: Presents In Person<br>RS->RO: Gets Credential<br>RO->RS: Sign In to NPE Portal<br>RS->RO: Display NPE ROI Form<br>RO->RS: Specify Auth'z Server (AS)<br>RO->RS: Text Resource Description<br>RO->AS: Sign In to Agent Portal<br><br>RS->AS: FHIR Resource Description<br>AS->RO: Text Resource Description<br>RO->AS: Confirm Authorization Policies<br>AS->RS: Confirm\nResource Registration<br>RS->AS: Consent Receipt<br><br>note over RO, RS, AS<br> End of UMA Phase 1<br>end note<br><br>note over RS, AS, C, RqP<br> RqP discovers the resource via message or directory query<br>end note<br><br>RqP->AS: Presents Claims\ne.g. <a href="mailto:bob@medicalsociety.org" target="_blank">bob@medicalsociety.org</a><br>AS->RqP: Gets Credential<br>RqP->AS: Sign In to AS<br>RqP->AS: May need to Register Client<br>AS->C: Consent Receipt<br>C->AS: Requests Authorization<br>AS->C: Grants Authorization<br><br>note over RS, AS, C, RqP<br> End of UMA Phase 2<br>end note<br> <br>C->RS: Access FHIR Resource<br>RS->AS: Accounting for Disclosure<br><br>note over RS, AS, C, RqP<br> End of UMA Phase 3<br>end note</span></font><span class=""><font color="#888888"><br><br></font></span></div><span class=""><font color="#888888"><div>Adrian<br></div><div><br> <br></div></font></span></div></div></div></div><div class="gmail_extra"><div><div class="h5"><br><div class="gmail_quote">On Tue, Oct 20, 2015 at 11:30 AM, Glen Marshall [SRS] <span dir="ltr"><<a href="mailto:gfm@securityrs.com" target="_blank">gfm@securityrs.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000">
For the individual-to-role pattern, HL7 has a role based access
control standard. It includes and extensive vocabulary of
healthcare roles, and it is extensible. This can be used to share
access control role semantics across authorization services. <br>
<br>
The individual-to-NPE and individual-to-role patterns presents some
interesting challenges. One of them is that the mapping of access
permissions depends on the location and work assignments. For
example, health care staff may be assigned to different care
locations and have legitimate access only to the patients' data for
that location. Similarly, the role assigned to a person will vary.
I do not know how amenable these cases are to technical solutions.
Current practice is to assume compliance of the staff to
institutional policies.<br>
<br>
What identifying data needs to be shared among users to access
Alice's [current] authorizations? What is its provenance? <br>
<br>
<div>
<p><b>Glen F. Marshall</b><br>
Consultant<br>
Security Risk Solutions, Inc.<br>
698 Fishermans Bend<br>
Mount Pleasant, SC 29464<br>
Tel: <a href="tel:%28610%29%20644-2452" value="+16106442452" target="_blank">(610) 644-2452</a><br>
Mobile: <a href="tel:%28610%29%20613-3084" value="+16106133084" target="_blank">(610) 613-3084</a><br>
<a href="mailto:gfm@securityrs.com" target="_blank">gfm@securityrs.com</a><br>
<a href="http://www.SecurityRiskSolutions.com" target="_blank">www.SecurityRiskSolutions.com</a></p></div></div></blockquote></div></div></div></div>
<br></blockquote></div><br></div></div>