[Openid-specs-heart] Draft HEART Meeting Notes 2015-09-28

Eve Maler eve.maler at forgerock.com
Mon Sep 28 20:59:33 UTC 2015


Attending:

Debbie Bucci

Abbie Barbir

Adrian Gropper

Catherine Schulten

Corey Spears

Dale Moberg

Edmund Jay

Eve Maler

Glen Marshall

Jeremy Maxwell

Robert Horn

Thompson Boyd

Tom Sullivan

John Moehrke

Glen’s Use Case
<https://docs.google.com/document/d/1BajiGx_68nrKvSUL1raItMwPkSFCZ_m-aSKUsdb9hzY/edit?usp=sharing>:
Alice Consents to Clinical Research [UMA]

Since the CDRN doesn’t know who the patient is, there has to be some sort
of engine that permits reidentifying the patient. This can be considered a
minor nit. The permission to reidentify the patient could be stored in the
AS.

Saying “pseudonymized” is important, as there’s an ISO standard for this,
and it admits reidentification. For proper privacy protection, the data
that is sent to the CDRN by the PHR would be associated with the case
number before the CDRN sees it. The CDRN has to use the pseudonym, which
would be the case number -- or at least, this is how Glen would implement
it.

It seems suspicious to be able to reidentify without explicit permission.
If the RO is explicit about a constrained purpose of use, then they’d have
to come back to her to ask about reidentification later.

Research under the PCORI initiative differs from clinical trials, so
experience with how clinical trials have a clinical trial manager who might
know patients vs. the researchers who don’t know patients may not be
relevant in the PCORI case. It would be a good idea to clarify up front
that this use case is PCORI-specific. We don’t know whether it’s pre-trial
or post-trial; however, we know PCORI is really different from clinical
trials (and it appears each paradigm could learn from the other in various
ways). Glen will edit accordingly.

Glen will ensure that the cardinalities of the technical entities are
clear. In the case of OAuth, assume that each “source of truth” of data (an
RS) is accompanied by its own AS, so that the cardinality is that there’s a
pair of AS/RS entities for each EHR.

Eve will provide the latest “entity roles” boilerplate (see the template
link below).

We walked through the technical flows. In the UMA case, the patient is
capable of rescinding or modifying the permissions. Keeping the patients in
control is very much in the spirit of HEART.

Pseudonymization is something that, at a minimum, the API being protected
has to enable through a choice of a scope. If it’s not enabled in this way,
a patient can’t choose to consent to it vs. being identified in the clear.
Eve calls this “scope-grained access”. This may have implications for our
profiling work as it relates to the FHIR API, at least, both when it comes
to OAuth scopes and when it comes to UMA scopes. To date, FHIR scopes
hadn’t been subjected to patient-centric use cases such as the ones we’re
considering.

In passing, Eve mentions ForgeRock’s early experimentation with leveraging
“relationships” between people and data, and between pieces of data, to
drive various automated workflows for authorization.

Of course, even if a patient were to choose consent to a scope that offers
some more privacy-enabled mode of access to data, there are still risks of
correlation, reidentification, etc. Jeremy notes that the formal definition
of deidentification doesn’t even mean that the chance of reidentification
isn’t zero -- it’s just low.

FHIR does recognize the realities and messiness of patient identifiers. It
is a data model and not a server model; however, it admits
compartmentalization as a mechanism of data management. It’s
authentication- and authorization-agnostic.

AI: Glen, Debbie, Eve: Work on a set of diagrams for the use case.

Next meeting: Try to go through the alpha OAuth FHIR profile doc.

Heart Use Case template

Eve has created a template
<https://docs.google.com/document/d/1Y3aUsxKOW6-HY-TQxRLO5MgBkJMpjsH_ihWv00z1l8I/edit?usp=sharing>
for use in creating new use cases. Comments are welcome. Any new use case,
or any editing of the boilerplate in a use case, should use this template.


*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!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-heart/attachments/20150928/01f3d3e3/attachment.html>


More information about the Openid-specs-heart mailing list