[Openid-specs-heart] Proposal for reworked use case AND use case template

Mon Aug 3 15:21:34 UTC 2015

Aaron,

My definition of "patient-centric" is what we use in The Society for
Participatory Medicine: "Nothing about me without me."

This is not as hypothetical as it sounds. A number of us in HEART worked on
the "Privacy on FHIR" pilot for last HIMSS. We demoed a patient-centered
system that included private EHR, gov EHR, 42CFR Part 2 sensitive data,
PHR, phone apps, and wearable IoT devices all sharing data using FHIR.
http://wiki.siframework.org/file/view/HIMSS15_Privacy%20on%20FHIR%20FINAL.PDF/555755441/HIMSS15_Privacy%20on%20FHIR%20FINAL.PDF
The use of a single UMA Authorization Server for Alice across all of these
FHIR resources is the embodiment of "Nothing about me without me."

The patient-centered or patient-directed approach to FHIR solves, or at
least avoids, the very difficult patient ID problem. It buys us time while
cybersecurity initiatives like NSTIC/IDESG figure out how to implement
practical trust frameworks for identity and related verified attributes.
Human ID is not a healthcare-specific issue, because we don't license human
patients. While others work on Human ID, we can use the patient-directed
approach to match patients across institutions.

The patient-directed approach also avoids the difficult problem of
delegation to a family caregiver or custodian. Instead of every FHIR
resource having to implement a delegation method and policy, that
responsibility shifts to the patient's AS and becomes mostly transparent to
the resource server.

The patient-directed approach provides increased cybesecurity because the
AS is consulted for every new interface access. This means that breaches
can be discovered in minutes instead of months. This also fulfills the
much-delayed Accounting for Disclosures requirement in HIPAA.

The patient-directed approach avoids most of the provenance issues because
information flows directly from one institution to another without the
opportunity for delay or corruption by intermediary PHRs or HIEs.

The patient-directed approach solves the "multiple portals" problem. Once
registration is complete, the patient or custodian need not interact with
the patient portal at the Resource Server again. In some cases, it's
possible that the resource server can avoid running a patient portal
altogether by allowing a staff member to complete enrollment of the
patient's AS as part of registration.

The Russian Dolls metaphor doesn't work for me. What I see is a simple
bifurcation at the root of FHIR design: either you enable a
patient-specified Authorization Server as a third-party in server-client
FHIR exchange or you don't. If you start down the UMA branch, then all of
the benefits above accrue downstream. If you don't start down the UMA
branch, then complexity explodes as we try to invent accessory actors,
federations and governance mechanisms.

Adrian

On Mon, Aug 3, 2015 at 10:00 AM, Aaron Seib <aaron.seib at nate-trust.org>
wrote:

> Adrian,
>
>
>
> Hi – I agree with your assessment regarding the sufficiency of oAuth for
> the use case as documented.  It is a good way and block and tackle the
> problem space to get to consensus of what separate components are capable
> of doing and resolving them from the basic to the complex.
>
>
>
> Does everyone agree with that starting point?
>
>
>
>
>
> For discussion purposes lets assume we have consensus on that.  For the
> use case where the consumer has PGHD that the Provider wants oAuth is
> sufficient.
>
>
>
> This sentence from your email:
>
>
>
> If the problem is to begin HEART with a patient-centricity as the problem,
> then this particular use-case distorts the discussion by presuming Alice
> wants a PHR and diminishes the patient-centered benefits of UMA as a health
> information exchange technology.
>
>
>
> I want to parse that better so I understand – can you help edify me about
> what is meant by “patient-centricity as the problem”?
>
>
>
> I don’t have the same feelings about the fact that part of the work HEART
> is doing is inventorying what the different use cases are and their
> sufficiency.  In fact I think this step may prove informative to the end
> point that we are all pursuing.
>
>
>
> One use case that is important that doesn’t follow the “Consumer has PGHD
> that the Provider Wants” that readily comes to mind is the pattern of
> Provider A having PHI about Patient X that Provider B (whom has a
> patient-provider relationship with Patient X) should have if and only iff
> (IFF) it is aligned with the privacy preferences of Patient X for Provider
> B to have said data.
>
>
>
> To close the loop – is that a statement of a patient-centricity use case?
> Does what we are learning with the first use case inform what needs to be
> done to satisfy the second use case?
>
>
>
> From a laypersons perspective I see a Russian Dolls exposition of the use
> cases one building on another until we solve the problems established by
> this work groups charter.
>
>
>
> Thank you for letting me share.
>
>
> Aaron
>
>
>
> Aaron Seib, CEO
>
> @CaptBlueButton
>
>  (o) 301-540-2311
>
> (m) 301-326-6843
>
> <http://nate-trust.org>
>
>
>
> *From:* Openid-specs-heart [mailto:
> openid-specs-heart-bounces at lists.openid.net] *On Behalf Of *Adrian Gropper
> *Sent:* Sunday, August 02, 2015 2:30 PM
> *To:* Id Coach
> *Cc:* openid-specs-heart at lists.openid.net
> *Subject:* Re: [Openid-specs-heart] Proposal for reworked use case AND
> use case template
>
>
>
> Thank you Eve!! I hope we can reach consensus on something like the format
> you present.
>
>
> Narratives are much easier to understand when they begin with a clear
> statement of the problem. Shouldn't use cases be asked to clearly state the
> problem they are trying to solve right up front?
>
> This particular use-case seems to be trying to solve some or all of three
> problems: federated sign-in, eliminating the registration clipboard hassle,
> and updating a PHR with encounter results. All of these can be solved by
> OAuth alone.
>
> If the problem is to begin HEART with a patient-centricity as the problem,
> then this particular use-case distorts the discussion by presuming Alice
> wants a PHR and diminishes the patient-centered benefits of UMA as a health
> information exchange technology.
>
> I've tried to clarify these fundamental issues in my comments on the
> document and hope we can resolve this before we move on to semantic
> profiling and scopes.
>
>
>
> Adrian
>
>
>
> On Sat, Aug 1, 2015 at 3:32 PM, Id Coach <coach at digitalidcoach.com> wrote:
>
> Thanks Eve,
>
> This is wonderful. I questioned/commented on things only a newbie is
> likely to ask/care about.
>
> It's also a useful template for other use cases. To your point about
> explaining oAuth and other template terms, you're using a new language and
> a new ecosystem to many, so I encourage those template terms to be
> explained over and over again as needed and as appropriate.
>
> It will be helpful to me to illustrate or diagram this process. I'll take
> a crack at that in the next few days (I hope).
>
>   judi
>
>
>
> On 8/1/15 11:20 AM, Eve Maler wrote:
>
> Completing my action item, you'll find our (well-worn :-) use case
> document here
> <https://docs.google.com/document/d/1IvbdWerdvMuA1dQ-KQvVKqIBrAas7FoenNVUtgpqYrw/edit?usp=sharing>.
> Following is my proposal. If we like what I've done here, I recommend that
> we:
>
>    - Edit the doc title to match the use case title I've supplied (just
>    below the horizontal line).
>
>
>    - Resolve all the comments above my title (fear not, they're all
>    accounted for in the comments I've inserted) and delete all the text above
>    that point (I've retained all our existing text above the line, just in
>    case).
>
>
>    - Resolve all the comments I've inserted -- as quickly as possible! We
>    don't have to take up call time to do the minor ones, if people take the
>    initiative to review them offline and supply their feedback as responses to
>    this note. Note that, in this new template, I have avoided the use of the
>    comment mechanism for anything that should be a permanent part of the
>    document.
>
>
>    - Ask people to write their other use cases in GDoc using this style.
>
>
>    - Obviously, if you have suggestions on how to improve the template,
>    weigh in! If you want to make invasive suggestions, contact me and we can
>    do a collaborative editing session together.
>
> I'm extremely glad I finally did this exercise, because it caused me to
> understand more of what we need to consider profiling and more of the
> "health SME" point of view. And, to be honest (perhaps forestalling a
> comment from Justin ;-), I don't feel that it was wasteful to go to this
> degree of mapping to the technologies because it flushed out some
> mismatches that really didn't make sense to me all this time. I now feel we
> can go straight to the heart (ahem) of the profiling matter with as many
> future use cases as we want, and in fact, we can begin profiling and write
> more use cases in parallel.
>
>
>
> Thanks to you all for letting me "get my OCD on".
>
>
> *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 list
>
> Openid-specs-heart at lists.openid.net
>
> http://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
>
> RESTORE Health Privacy!
> HELP us fight for the right to control personal health data.
> DONATE: http://patientprivacyrights.org/donate-2/
>

-- 

Adrian Gropper MD

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/20150803/cf2900b1/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image003.jpg
Type: image/jpeg
Size: 3147 bytes
Desc: not available
URL: <http://lists.openid.net/pipermail/openid-specs-heart/attachments/20150803/cf2900b1/attachment-0001.jpg>