Attending:

Debbie Bucci

Thompson Boyd

Scott Shorter

Celestin Bitjonck

Cait Ryan

Sarah Squire

Justin Richer

Dale Moberg

Tom Sullivan

Eve Maler

Adrian Gropper

Ken Salyards

Nancy Lush

Josh Mandel

Kathleen Connor

Luis Maas

Edmund Jay

Jim Kragh

Jin Wen

Discussion:

Debbie: We’re going to pick up where we left off on the use case. I added Data and Services resource sets. We might want to add consent

Kathleen: At some point, we should talk about tying resource sets to consent.

Eve: I was trying to steer the email discussion toward sharing scenario 1: Alice gives access to Dr. Bob before her first visit. It’s selective - some information, and exclusive - sharing with some parties but not others. This could guide our profiling efforts. Do we want to profile for specific use cases? We know there’s basic data structures that apply to this specific use case - what a doctor needs to know on a first visit.

Kathleen: You could use a sort of meaningful use transfer of care template.

Tom: I want to be sure when we say that Alice is giving Bob permission, that this actually goes to Dr. Bob’s office staff, because you will never get a physician to look at a record before a visit.

Kathleen: In the physical world, that’s generally the case. Clinics manage their own access control.

Adrian: We’re talking about a client that might be an institutional client, but Nancy or Bob are identified as Nancy or Bob at the authorization server, so this is a nonissue.

Eve: It’s only a non-issue if it’s not relevant to our profiling work. If we want all ASs to have certain things available, we need to include those things in the profile.

We can include purpose-of-use limitations in the profile.

Ken: I’d like to understand what is going to determine what information is getting shared when and how UW law is being vectored into this process of data sharing and authorization servers. I’m trying to figure out how FHIR resources are going to be able to be shared.

Kathleen: We’re going to need authorization server segmentation and consent.

Justin: The authorization server can’t segment the data because it doesn’t have the data.

Ken: Resources are descriptive of health information. I don’t understand why we need FHIR to help us share that information.

Justin: We’re conflating resources and resource servers.

Eve: HEART is working on adding new patient-centric functionality that doesn’t exist today. We’re looking at rolling up all the purpose-of-use vocabulary into chunks.

Ken: You can’t just register static resources. They will change.

Eve: We’re not assuming data is static. The act of sharing enables whoever it is to get access to whatever it is. If the data changed during that time, they get access to the changed data.

Adrian: HEART is trying to be patient-centered. Resources and dimensions may be dynamic. Is HEART going to profile the actual chunks? Or is HEART going to allow other institutions to define the chunks?

Justin: In my view, our job as a working group is to define a starting set of chunks, but more importantly, we can say how those chunks are defined and how we can allow other organizations to do that. For example, IANA protects protocol namespaces. That’s effectively the kind of thing we’re setting up when we’re building these profiles. We do need a starter set, but we also need to define the means by which things change going forward.

Eve: It’s really important to not have it be a free-for-all, especially since there have been lots of data structures that have been formally standardized. We can provide guideposts and meta-guideposts.

Debbie: UMA expresses policy, but does it compute policy?

Eve: UMA doesn’t deal with policy. It deals with the result of policy. It deals with the calculated result of WHO Alice wants to share with, WHAT she wants to share, and the SCOPES she wants the requesting party to get access to.

Debbie: So the resource is going to do the calculus.

Eve: The authorization server does do a calculus in terms of gathering claims and doing trust elevation of the requesting party.

Ken: The policy now gets rendered somewhere, and then at some point the authorization server has to evaluate that consent directive from the resource server, and then has to turn over that policy to an execution engine that says maybe I’m going to execute XACML to figure out what happens in this exchange.

Eve: It has to be done, but it can be done entirely proprietarily if you wish.

Debbie: Let’s say UMA creates a policy which may be a consent directive. The resource server is making those determinations? Eve: The result of applying policy is that the authorization server outputs an access token (RPT) which it gives to the UMA client. That’s not the flow that XACML has. It’s the flow that OAuth has.

Ken: That’s used for authentication, right?

Eve: It’s used for authorization.

Debbie: The entitlements delivered to the resource server could have sensitivity tagging about the resources it wants? Is that part of the entitlements?

Eve: My guess is you don’t want the tagging there, you want tags associated with the resources themselves.

Kathleen: You want them on both sides.

Ken: You want the tagging to be global because information associated with what you’re trying to protect may occur across multiple resources.

Debbie: Could tagging be part of the entitlements?

Kathleen: That’s called attribute-based access control. There are standard entitlements in FHIR and they can be on the provisioning of the request.

Eve: There’s an UMA spec called resource set registration that gives you an opportunity to “type” your resource. You can tell the AS that it’s of a “type” called “photo album” so the AS can do special stuff.

Justin: The “type” thing has always been completely undefined in UMA. It feels like it would be nice to have types of things, but it’s not being used anywhere.

Eve: It’s up to us. If we were to use the type field in registering resources, would it be foolish or sensible to populate permissions with further data given that we can derive the type from the registered resource. If HEART made a standard for “virtual clipboard” we would use it.

Adrian: I think what we’re saying is that other standards groups, whether they map resources or segmentation strategies, are going to talk to each other, and we have to stay above that fray.

Eve: We should be governing the namespace.

Adrian: Patient privacy rights or creative commons might want to create a registry or add to a registry. Aren’t we all saying that?

Eve: We need to figure out how Alice expresses who she wants to share with.

Justin: Consent directives are meant to be executable and proactive - a data structure that I look at and actively make an access management decisions. That’s what I want to make sure that we keep in mind.

Debbie: Right now we’re trying to focus on profiles that allow Alice to share information with Bob, and what she’s going to share. UMA may leverage other systems, but we need to be careful about what we’re profiling.

Justin: We also need to say if there is a segmentation engine, this is how it fits in.

Ken: The consent directive is the standing policy for what the patient wants to share. On the flip side, we have a XACML-based engine to do the segmentation or whatever. I’m happy that you guys understand what I’m bringing to the table.

Justin: The resource server actually processes the request. It may have a policy engine. It may do other things besides serve the data.