[Openid-specs-heart] "Individual-to-NPE" sharing episodes in UMA use cases, and "design pattern" solution options

Tue Oct 20 21:52:17 UTC 2015

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.

(a)
Electronic Health Records: Nonfederal Efforts to Help Achieve Health
Information Interoperability GAO-15-817: Published: Sep 16, 2015. Publicly
Released: Sep 29, 2015. http://www.gao.gov/products/GAO-15-817 that says:

"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."
>

(b)
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.

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.

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.

Therefore, I propose this Baseline HEART Sequence Diagram
<http://www.websequencediagrams.com/cgi-bin/cdraw?lz=dGl0bGUgQmFzZWxpbmUgSEVBUlQgU2VxdWVuY2UgRGlhZ3JhbQoKcGFydGljaXBhbnQgIkFsaWNlIHJlc291cmNlXG5vd25lciAoUk8pIiBhcyBSTwAhDk5QRQAiC3NlcnYAKQVTACcHUwBOD2dlbnQgYXV0aG9yaXphdGlvbgArCkEALgdBACYPQm9iIGNsaWVudFxuYXBwIChDAIEFBkMAFRJyZXF1ZXN0aW5nXG5wYXJ0eSAoUnFQAIEzB3FQCm5vdGUgb3ZlciBSTywgUlMsIEFTLCBDLAAYBU5QRSA9IE5vbi1QZXJzb24gRW50aXR5IC8gVGhpcyBpcyB0aGUgSW5kaXZpZHVhbC10by0ABAogRGVzaWduIFBhdHRlcm4KZW5kIG5vdGUKCgpSTy0-UlM6IFByZXNlbnRzIEluIABdBgpSUy0-Uk86IEdldHMgQ3JlZGVudGlhbAAqCVNpZ24gSW4gdG8gTlBFIFBvcnRhbAAtCURpc3BsYXkAFgVST0kgRm9ybQAxCnBlY2lmeSBBdXRoJ3ogUwCCXAoAgQgJVGV4dCBSAINkByBEZXNjcmlwdGlvbgCBLgVBAHIOAIM2BgB7BwCBNAVBUzogRkhJUgAtFkEAgVQHAEMiQ29uZmlybQCBJQUAhA8JIFBvbGljaWVzAEMGAB0KXG4AgSkJUmVnaXN0cgCEQwUAgQkJQ29uc2VudCBSZWNlaXB0CgCDYBUKIEVuZCBvZiBVTUEgUGhhc2UgMQCDKAsAhB0LAIQWDiBScVAgZGlzY292ZXIAhAsGAIYjCCB2aWEgbWVzc2FnZSBvciBkaXJlY3RvcnkgcXVlcnkAhAYLUnFQAIJYBgCECAlDbGFpbXNcbmUuZy4gYm9iQG1lZGljYWxzb2NpZXR5Lm9yZwCCSgZxUACEGRMARwgAgyEMUwBcCk1heSBuZWVkIHRvAIIrB2VyIEMAhkwFAIMgBUMAgiISQwCDeAZSAIZJBnMAgwwOAC0IR3JhbgALEQCCIBsAgmERMgCGGwogCkMAhh4GQWNjZXNzAIRJDgCEZAlBY2NvdW50aW5nIGZvciBEaXNjbG9zdXIAgxUdAINYETMAhxAMCg&s=mscgen>
based on the *Individual to Individual* design pattern (also supported by
Justin's comment above).

Here's the source code for anyone to improve or fork.

title Baseline HEART Sequence Diagram

participant "Alice resource\nowner (RO)" as RO
participant "NPE resource\nserver (RS)" as RS
participant "Agent authorization\nserver (AS)" as AS
participant "Bob client\napp (C)" as C
participant "Bob requesting\nparty (RqP)" as RqP
note over RO, RS, AS, C, RqP
NPE = Non-Person Entity / This is the Individual-to-Individual Design
Pattern
end note

RO->RS: Presents In Person
RS->RO: Gets Credential
RO->RS: Sign In to NPE Portal
RS->RO: Display NPE ROI Form
RO->RS: Specify Auth'z Server (AS)
RO->RS: Text Resource Description
RO->AS: Sign In to Agent Portal

RS->AS: FHIR Resource Description
AS->RO: Text Resource Description
RO->AS: Confirm Authorization Policies
AS->RS: Confirm\nResource Registration
RS->AS: Consent Receipt

note over RO, RS, AS
 End of UMA Phase 1
end note

note over RS, AS, C, RqP
 RqP discovers the resource via message or directory query
end note

RqP->AS: Presents Claims\ne.g. bob at medicalsociety.org
AS->RqP: Gets Credential
RqP->AS: Sign In to AS
RqP->AS: May need to Register Client
AS->C: Consent Receipt
C->AS: Requests Authorization
AS->C: Grants Authorization

note over RS, AS, C, RqP
 End of UMA Phase 2
end note

C->RS: Access FHIR Resource
RS->AS: Accounting for Disclosure

note over RS, AS, C, RqP
 End of UMA Phase 3
end note

Adrian

On Tue, Oct 20, 2015 at 11:30 AM, Glen Marshall [SRS] <gfm at securityrs.com>
wrote:

> 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.
>
> 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.
>
> What identifying data needs to be shared among users to access Alice's
> [current] authorizations?  What is its provenance?
>
>
> *Glen F. Marshall*
> Consultant
> Security Risk Solutions, Inc.
> 698 Fishermans Bend
> Mount Pleasant, SC 29464
> Tel: (610) 644-2452
> Mobile: (610) 613-3084
> gfm at securityrs.com
> www.SecurityRiskSolutions.com
> On 10/19/15 16:00, Eve Maler wrote:
>
> I promised to write this up, and hopefully I'll make it before the
> deadline of today's call.
>
> The subject line introduces what I hope will be useful consistent wording
> for discussing these sorts of topics. Some of our UMA use cases include
> episodes of party-to-party resource sharing that involve a resource owner
> who is an individual (say, a patient or consumer), and a requesting party
> that *is, or is the agent of,* a "non-person entity" or NPE, such as a
> hospital, government agency, or company.
>
> Staying entirely within the confines of the UMA protocol, a number of
> different "design patterns" could be chosen for deployment. Agreeing on
> which reasons to use which patterns, and locking down any areas of
> variability, could help make systems interoperate with each other. The UMA
> protocol, in fact, expects such variability and recommends profiling to
> improve interoperability. Thus, it seems a good idea for us to figure out
> how much such types of interop are in scope for us, and likely *do some
> profiling in these areas*.
>
> Here are four patterns I can think of:
>
>    1. *Individual-to-agent-of-NPE*: Alice the individual RO shares with
>    "the individual RqP who can prove they control the identifier 'Dr. Bob'"
>    (possible also constraining the client in use as well -- we'll leave that
>    part out for this analysis).
>    2. *Individual-to-NPE*: Alice the individual RO shares with "the NPE
>    RqP that can prove they control the identifier 'New York Presbyterian
>    Hospital'". Some process yet to be determined, possibly involving "chained
>    delegation", ensures that Dr. Bob and possibly others who work for NYP get
>    access thereafter.
>    3. *Individual-to-role*: Alice the individual RO shares with "any RqP
>    who can prove they have been assigned the role 'works for NYP'".
>    4. *Individual-to-individual*: Alice the individual RO shares with
>    "the individual RqP who can prove they control the identifier 'bob at gmail'"
>    (whom she knows is her doctor because he provisioned her with that gmail
>    handle). Bob might do "chained delegation" to share the resource with
>    himself as an employee of NYP.
>
> The reason interop questions arise is because the process of UMA trust
> elevation involves things like claims-gathering and possibly step-up
> authentication, and the policy-setting options presented to Alice (which
> are out of band of UMA, but nonetheless...) need to be driven by these
> requirements. The ability of the requesting sides to respond appropriately
> will be triggered off of expectations about what they'll be asked to cough
> up for trust elevation.
>
> Each pattern has pros and cons. Briefly:
>
>    - The one I'm least enamored of is #3; enterprise access control has
>    had so much trouble with RBAC, so can we expect adding UMA to help? :-)
>    - Chained delegation can be very powerful. In environments where
>    everybody uses the same UMA authorization server, a number of nice
>    value-add features can be supported, but they tend to break down (at least
>    with UMA V1.0.x) when you add the ability for every RO to choose their own
>    AS.
>    - I worry about sharing with individual doctors. It's very expedient,
>    so people will tend to do it as a path of least resistance (think Google
>    Apps!). And sometimes maybe it's the right answer, particularly if "chained
>    delegation" can allow Alice to track where her resource has been shared
>    further. But what if Dr. Bob leaves the hospital/practice/whatever? Is this
>    always the right answer?
>    - Sharing with an NPE sounds elegant -- it's what a recent POC of my
>    acquaintance did. But the "process yet to be determined" mentioned above
>    wasn't actually determined yet, so there's that. :-) And you have the
>    problem of a system administrator who has privileged identity credentials
>    to the NPE account -- as always -- having the key to a pretty valuable
>    kingdom. Maybe a cool mitigation of this risk is to go with sharing with
>    individuals and tracking sharing chains?
>
>
> *Eve Maler *ForgeRock Office of the CTO | VP Innovation & Emerging
> Technology
> Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl
> Join our ForgeRock.org OpenUMA <http://forgerock.org/openuma/> community!
>
>
> _______________________________________________
> Openid-specs-heart mailing listOpenid-specs-heart at lists.openid.nethttp://lists.openid.net/mailman/listinfo/openid-specs-heart
>
>
>
> _______________________________________________
> Openid-specs-heart mailing list
> Openid-specs-heart at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-heart
>
>

-- 

Adrian Gropper MD

PROTECT YOUR FUTURE - RESTORE Health Privacy!
HELP us fight for the right to control personal health data.
DONATE: http://patientprivacyrights.org/donate-2/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-heart/attachments/20151020/99f0bf91/attachment.html>