Attendees:

Debbie Bucci

Adrian Gropper

Sarah Squire

Thompson Boyd

Cait Ryan

Nancy Lush

Dale Moberg

Scott Shorter

Eve Maler

Glen Marshall

Jim Kragh

Luis Mass

Edmund Jay

Tom Sullivan

Jin Wen

Kathleen Connor

Discussion

Scott: Added a few terms to the wiki page from the specifications and use case and provider directory workshop. I’ll get those into the glossary. If you go to the HEART wiki page, recent activity shows the glossary, and I’ll email this page to the group.

Debbie: There was a provider directory workshop, and there was discussion about using API rather that HPD, which is LDAP on top of SOAP. I’m wondering if those are relevant to HEART.

Scott: Anything that doesn’t need to be here we can remove.

Eve: I’ve converted the UMA use case into markdown. Most of the text is the same as before. I have been having conversations with various folks offline. We’ve been talking about particular aspects of what the FHIR API would look like if Alice wants to share with her husband in an interactive fashion. There are a lot choices about provisioning the knowledge to Bob in some fashion about what the resource is. That’s what we want to illuminate through this use case. What would be the URL? Would it be a query? Would it have Alice’s patient ID in it?

Debbie: Is there some notice that is part of the flow?

Eve: She’s not asked to share anything. It’s on her own initiative. I call it a share button. That’s peripheral, but the fact that it’s of her own initiative is core. Particulars of how it looks in an interface are peripheral.

Adrian: Is the share button on the resource server or the authorization server?

Eve: It could be either. ForgeRock has it built into the authorization server component, but you could build it in the resource server side.

Debbie: You could be redirecting back to the AS even if you’re logged into the RS.

Eve: When it comes to a notification, that is also a question. Does Bob get an email? Does his app pop up a notification? Presumably that’s all going to be peripheral. We don’t want to dictate how software writers appeal to the market. Do we want to say something about the FHIR URL format?

Debbie: Just thinking out loud: Alice gives Bob access, Bob needs to know Alice’s AS, right?

Eve: Bob’s client discovers Alice’s AS in the process of trying to access the resource. Once I start writing the flows in this use case, I could outline some of the UMA flows, but we could just reference back to the UMA spec. I think I will not go into a lot of detail on those.

Debbie: So we don’t think there’s a layer in front of that that’s doing deidentification for Alice?

Eve: The RS will have to be capable of exposing that scope in order for Alice to be able to choose it. The RS is slicing up the data. Alice is saying who she wants to get what. The AS is responsible for doing what Alice wants.

Adrian: Alice is describing her policies only to the AS, not the RS.

Eve: Right.

Debbie: So what’s an example of a resource set?

Eve: Resource set is a term of art for whatever the RS tells the AS is being protected. For example, the thing being protected might be a folder with many files in it. Only the RS knows that it’s a folder with many files in it. The AS just needs to know it’s a thing that is protected. It’s a “bundle” of things. It is equivalent to a protected resource.

Adrian: Let’s skip to the simplest situation. The choice of policies to set are made by Alice at the authorization server. Ahead of that, there’s a step where Alice has linked the resource server to the authorization server. That happened a day before? Or a second before? Is that an assumption we’re making?

Eve: We could treat it as peripheral, because either works. There might be business assumptions about that.

Adrian: Are we going to start out by picking one particular instance of a FHIR transaction and follow the user experience from end to end? Or are we generalizing?

Eve: We’re looking at all the places that need profilable design patterns. Where we can determine it to be peripheral, we should pick something and run. If we’re not sure, we should discuss it in the group.

Adrian: Wouldn’t it be easier if we started out with an index case first?

Eve: I’m trying to come up with something that is close to the average of an index case for different businesses.

Debbie: How do we define how the RS tells the AS what it can protect?

Eve: Given that FHIR already has a taxonomy of resources, that might be part of our work.

Adrian: Aside from the FHIR specific stuff, are we also profiling the format by which the FHIR resource is communicated to the authorization server? Is it XML? JSON? Eve: The authorization server doesn’t touch data.

Adrian: How do we canonicalize communication about resources?

Eve: The semantics around what to standardize will depend on the use cases.

Kathleen: Hopefully we’re keeping track of how these standards interact with consent directives.

Adrian: I don’t actually know what a consent directive is. It sounds to me like the default assumption for UMA is that the RS and the AS have constraints. We don’t assume in UMA that Alice has more or less control over the resource than the resource server.

Kathleen: The institution can limit what Alice can do with that information. They set up sharing policies.

Adrian: But that’s not UMA. The basis for the AS choosing is of no concern to the RS. FHIR should apply to all transfers regardless of whether an EHR is involved. Policy is never communicated over the wire.

Kathleen: How does policy get set if it never goes over the wire?

Adrian: Alice’s policies are only known to Alice and the AS.

Kathleen: We don’t disagree.

Eve: UMA is not the only wire in question when it comes to access management.

Debbie: If the AS needs to be aware of the resource sets and the policies, and the AS is also aware of third-party access management stuff, it’s not the AS that’s making the final decision. Right?

Eve: The AS executes Alice’s wishes. It’s not acting on behalf of the enterprise. It may or may not be the “end of the line” for access control.

Adrian: I think if we can simply deal with the profiling and with the index case in these terms, that’s what needs to be done.

Debbie: Eve, how can we help? What’ the next step?

Eve: Review prior to the next call would be great. I’ll send out the link to the list.