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

[Eve Maler]

Attending:

Debbie Bucci

Adrian Gropper

Brandon Smith

Dale Moberg

Eve Maler

Glen Marshall

Hope Morgan

Tom Sullivan

Bill Kinsley

Edmund Jay

Jin Wen

Jeremy Maxwell

Jim Kragh

Thompson Boyd

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

A CDRN would have some sort of pseudonymization, relative to the
researchers’ purposes. This is now noted in the use case.

Alice participates in all of the decision-making regarding her care. The
PHR picks up on the previous use case information. The PHR operator
supports many end users.

The care providers include healthcare professionals -- note, there are
multiple, vs. previous use cases. This is typical for a Stage 4 patient.

What is the reason for separating EHR and PHR in this use case? Some of the
information in the EHR may have data that is not readily meaningful to a
patient, but may be clinically significant for research purposes,
especially given that it will use clinical terminology. FHIR objects
contain data and vocabulary -- it’s both “terminology and transport”. It’s
currently oriented towards clinical decision-making.

A concern was raised about Alice granting the proxy access rights that are
equal to her own. This is different from something like a “durable power of
attorney”. The latter has real legal rights. Glen suggests that this is a
policy matter that is outside the purview of the use case. One way to think
of this is that the data/API access rights are “downstream” from the
(possibly legally based) relationship forged between people, whether that
relationship was on paper or machine readable or whatever. It’s for this
reason that the use case as written avoids the word “proxy”.

The EHR providers would create multiple EHRs. There may be aggregate data
across multiple EHRs. There’s a realm of practices and practitioners here
that is realistic per PCORnet.

The CDRN (clinical data research network) is where the data is aggregated.
There may be one or more CDRNs for the same data. A client application
might be a browser or a query engine of some sort. Clinical researchers
access the CDRN, and perhaps create higher-level aggregations if there are
multiple.

Might there be three separate data roles: clinical data, directive-type
stuff, and global stuff like search queries related to patient-generated
health data (PGHD)? Yes, but for the purposes of this use case, the actual
CDRN data is unimportant. This suggests that any CDRN data content is
[peripheral], because it’s all gated by research that’s gone through the
IRB-approved protocol.

There would be a template for the access token that the IRB would provide.
The CDRN would call the AS to determine what they’re authorized to get. The
authorization would consist of what data you could access and for what
patient, and possibly for how long. A researcher sitting in front of a CDRN
client would be granted access to an individual PHR/EHR system as
determined by the patient’s policies.

There’s an authorization domain described here that’s dominated by FHIR,
and another dominated by the research domain. In what sense is FHIR (the
HL7 standard) intended to serve research? This is the access control
portion of Phase 3 of the work, where Phases 1 and 2 include the FHIR
interface. In fact, for this use case, the use of the FHIR API is not core.
The API could be instead, or in addition, PMI
<http://www.nih.gov/news/health/sep2015/od-17.htm> (Precision Medicine
Initiative) for genetics. Let’s make the use of FHIR [peripheral], rather
than a technical precondition.

The use case should add “subject to IRB policy” to the description of being
about clinical research. (Done.)

For traceability, the OpenID Connect technology may be needed. If there’s a
patient on one side and a researcher on the other, does the OAuth/OpenID
Connect level of technology make sense vs. UMA? What impact does anonymity
have? And there may be multiple authorization servers: one at an enterprise
level and one at a personal level.

A vulnerability and risk assessment for access control would be very
interesting to see on this use case.

CQF = Clinical Quality Framework.

What’s the impact of the 21st Century Cures Act
<https://www.congress.gov/bill/114th-congress/house-bill/6/text>? It’s
incorporated into the mention of the IRB, around not needing authorization
over and over every time.

Should the preconditions include that the exposed APIs support the scopes
as defined by HEART itself? It’s a little recursive or something. Glen’s
point was that he’s assuming that the PHR and EHR only support OAuth.

We want to treat the “proxy” characteristic of the use case not as
peripheral but as core, because this will impact the UMA characteristics of
the profiling. We know that (in perpheral-land) this would indeed require a
durable power of attorney or a proxy.

Are we talking about computable consent
<http://www.hl7.org/implement/standards/product_brief.cfm?product_id=280>
here? Since UMA doesn’t provide a way of dereferencing data, Glen suspects
we may have to introduce a link between UMA and XACML -- but we’re not
talking about actually solving for it! Eve wonders how valuable the actual
solution of “portable policy” really is.

CDRNs are read-only with respect to the EHR.

The treatment protocols are out of band with respect to the use case.

There’s currently an email thread on issues related to this use case; let’s
keep that up. Then it’s hoped Eve will have enough fodder to refine the
graphical representation of the use case.

AI: Eve: Create a use case template with all of the boilerplate wording,
for use by future use case writers.


*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/20150921/ada54851/attachment-0001.html>