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.