Attendees:

Debbie Bucci

Dale Moberg

Tom Sullivan

Glen Marshall

Sarah Squire

William Kinsley

Scott Shorter

Josh Mandel

Justin Richer

Kathleen Connor

Adrian Gropper

Thompson Boyd

Edmund Jay

Eve Maler

Nancy Lush

Debbie: Can we come up with a common understanding about consent?

Adrian: Consent is Phase I of UMA.

Josh: There are many communities using it in different ways. We’re not going to square that circle. We just need to decide on a consistent definition for ourselves.

Sarah: Debbie, can you explain the context of your question?

Debbie: When we’re talking about delegation and third-party access, OCR (Office of Civil Rights) calls that authorization. We’re talking about authorization, not consent.

Kathleen: Let’s avoid coming up with a policy-bound definitions. Consent directive is a term of art for many communities.

Justin: We just need to carefully define what our terms are and how we use them. They won’t line up with all use cases everywhere. We should be careful not to confuse our terms with common terms in the healthcare or security communities.

Glen: For the purposes of this use case, consent only occurs during signing on the dotted line of a form. It’s not a technical thing. It occurs in the process of the IRB, which owns the form of consent. The signature creates some sort of record within the EHR, probably a FHIR consent record.

Adrian: Do we have a working definition of the difference between phase one and phase two?

Kathleen: We don’t have that yet, and we need to spend time working on it. We can use whatever words we want as long as they aren’t policy-laden.

Justin: Let’s not get caught up in defining single-word term, let’s just work with unambiguous phrases.

Debbie: As we start talking about UMA, there’s a whole list of other terminology that has been included, and I don’t see consent in here. We might need a glossary.

Kathleen: The baseline is no consent, then there’s implied consent, then there’s opt-in, then there’s opt-out with exclusions.

Adrian: I think that what you’re describing has nothing to do with HEART. The point of HEART is to allow the patient to specify policies outside the medical institution. The policies of the AS are not transparent to the resource server. The AS is a place where the resource owner keeps a set of policies and they’re secret and only tested when Bob’s client shows up.

Debbie: I thought what HEART was supposed to do was work on profiles, and so we need to specify and define scopes. Opt-in may be a scope to consider. There may be values in a resource set to consider.

Glen: Let’s go back to the use case.

Debbie: I assume some of the flows are asynchronous, like request for access?

Glen: Some of them are asynchronous, but I made them synchronous for the purpose of discussion

Bill: How are policies communicated between ASs?

Glen: That's open for discussion. Assuming there's an internal language for discussing policies. Not specifying what they are.

Adrian: RS has the scopes, AS defines the policies. AS translates the scopes that are available to it into tokens that relate those scopes.

Eve: One slight correction, RSs are authoritative for the resources and scopes, ROs are authoritative for mapping those to subjects, AS's are authoritative for executing on those to associate authorization data with tokens.

Debbie: This is clinical data for PCORI? [yes] Then there are existing policies that can be leveraged.

Glen: Policies are determined by the IRB. There's a definition but it isn't complete.

Justin: Historically, things like XACML can't really cross domains. Interop falls apart. Cross domain syntax and policy language is very challenging.

Glen: There’s a “crazyquilt” of policies between states.

Debbie: The OCR says a bunch of stuff about authorization. Is there something in one of our profiles that we want to detail so that it would be consistent?

Adrian: Let’s just not use the word consent in our profiles. Let’s use authorization.

Glen: The permission that the IRB would need to conduct research would need to be defined. What I intend to do as my next step is to take the discussion and do an edit of the use case, especially the swim lanes and remove any terminology we’ve tripped over.

Debbie: We’re not meeting next week. Josh made a comment about a glossary. I was heading down that path anyway, just so we’re all speaking a common language.

Justin: We’re meeting at HIMSS at 5pm on Tuesday at Carnevino. It will be informal. Ask Sarah if you need more information. I’m working on creating a “HEART mode” authorization server and I’d like to talk about it during our call in two weeks.

Adrian: Does this mean we’re going to be testing against FHIR APIs?

Justin: No. We’re not talking about compliance, we’re talking about a mode that will disable things that are not in line with HEART.