Attendees:

Debbie Bucci

Glen Marshall

Scott Shorter

Sarah Squire

David Batchelor

Nancy Lush

Tom Sullivan

John Moehrke

Dale Moberg

Thompson Boyd

Jim Kragh

Edmund Jay

Kathleen Connor

Jin Wen

Julie Maas

Justin Richer

Discussion:

Debbie: Let’s say there are FHIR resource sets that talk about meds and things that you define. How do you define them if they’re not resource sets?

Nancy: Everything should be in a FHIR resource. All the clinical data should be covered. The difficulty is in defining the cases that come out of that.

John: The way that FHIR is choosing to divy up - this kind of stuff goes into this kind of resource. They do it based on the data model. That structure works great for organizing the data into a resource that holds that kind of data, but when it comes to privacy topics, they are cross-cutting and don’t align well. For instance, information about abortion or HIV status might cut across multiple resources.

Debbie: I’m trying to think simpler. Dr. Bob wants access to some data. Alice generates an RPT ticket saying that’s the data they can see. However, an RPT only implies consent, there’s nothing that explicitly expresses consent.

Sarah: We’re looking at using the id-event standard being developed in the IETF. That would be a SCIM-based standard. However, it’s not defined yet.

John: We’re working on getting FHIR consent onto the HL7 ballot this fall.

Glen: We also have to keep in mind that the consent resource in FHIR needs to be computable. It needs to be acted on by the security subsystem during operation. There could be other types of access control involved.

Kathleen: There’s a lot of history also around CDA consent. There’s another approach. What Graham did with the information that’s governed by the consent. It’s good for making resource sets computable. Alice’s consent is what allows the resource server to describe her permissions to the AS. If there was a FHIR consent that, for instance, limited disclosure to certain dates. The resource server could use the description to indicate that to the AS.

John: The location of the resources and the location of the consent object don’t have to be in the same place. It’s just an object. It could be in a resource server dedicated to consent objects.

Debbie: So you’re saying you would use an authorization server to identify the type of attributes?

Kathleen: We’re just saying that consent could live somewhere else.

Debbie: So there could be a resource set that is the virtual clipboard. You give the authorization for the resource set, and I might include the location of my consent and my advanced directives as part of that. Would that be included as part of the token?

Sarah: I think John’s idea of having consent as a resource that is also shared with Dr. Bob is a great idea.

Debbie: John, how did you envision us using confidentiality codes, and where is that placed?

John: Security tags are in the metadata of the resource. You can have rules that a patient can record that says “Any data relevant to HIV is blocked” then you use the tag to indicate whether data is hiv-related, allowing it to be blocked. There is some question as to how the tag gets there, but that’s more of an operational issue.

Kathleen: The security labeling service looks at consent and disclosure. The enforcement system needs to look at those confidentiality codes.

Debbie: Resources could have metadata associated with them.

Sarah: UMA resources have no concept of consent metadata at the AS. So, we would be looking at either changing or extending the UMA protocol. Whereas if we store consent as an UMA resource, we can work within the existing protocol.

John: I propose that we use these tags as scope values. So when someone wants an UMA resource, they may be issued a token that says ‘hiv-blocked’. The name of the resource is a metadata element.

Debbie: So if we defined a resource set, could that scope apply to all the resources in that set? Because you’re saying the same meta is all the attributes?

John: The existence of a specific value in the metadata is what defines that. There is a confidentiality code set that is a range of risk from low risk to high risk. There’s a different set for things like hiv or alcohol abuse.

Debbie: So we could add a confidentiality scope.

Sarah: We could. Scopes are actually “out of scope” for this project as a whole. Any AS and RP can agree to use whatever scopes they want. Dr. Bob, for legal reasons, will probably need more information about the consent than just a binary. He would need to know when it was collected, by whom, in what jurisdiction, etc. I think it makes more sense to store that as a protected resource and proactively push information about it to Dr. Bob if it changes.

John: I think it’s important to separate access management from Dr. Bob’s ability to look up consent records for legal purposes.

Debbie: So how would Alice use confidentiality codes?

Sarah: Alice would use confidentiality codes to structure her access management rules at the AS. But this is profiling scopes, which we’re not doing.

Debbie: Aren’t we making suggestions about how to use FHIR?

Nancy: I’m concerned about the physician only getting part of the information.

Kathleen: That’s always been the way it is. Patients withhold information, and doctors know that.

John: FHIR also has a return code indicating that information has been withheld due to policy.

Debbie: As part of the FHIR API UMA profile, could we require that all resources at least have a confidentiality code?

Justin: That would be an implementation decision. We can allow clients to request that type of access.

Kathleen: We could have a guide to tell them how to do it if they need to.

Debbie: I don’t understand why we wouldn’t require it, if the attribute is on all FHIR resources.

Justin: Because it’s not necessarily implemented on all resources.

Debbie: We could make it SHOULD.

Justin: The best approach is to always allow the client to request it, define what it means when the client requests it, but don’t require servers to strictly define their data in terms of this.

Kathleen: Why would a client ask for “send me something with a confidentiality code”?

Justin: Why wouldn’t a client ask for “I want information about hiv status”?

Debbie: Is “confidentiality code” not implemented everywhere?

Sarah: Yeah, but we’re not necessarily talking about institutional data. We could be talking about her fitbit information.

John: Things could be set to “normal” by default.

Debbie: It may not be consent, but it’s a step in the right direction.

Justin: Which is why it’s important to allow clients to request it, but not require it.

John: FHIR does not require it. Everything is optional.

Justin: The core charter of this working group is not to profile the FHIR protocol itself, but to profile security aspects around using FHIR.

Debbie: We’re talking about using it as a scope, because we don’t have any idea how to do consent.

Justin: We could certainly define it. That would allow the client to request specific access. It also allows Alice to write policies at the AS. But we shouldn’t require the RS to implement those specific controls universally. Be liberal in what you accept. Be strict in what you produce. The RS should be able to handle all FHIR metadata.

Debbie: So an AS could handle HEART profiles or other profiles, but that AS might be handling scopes for FHIR-specific APIs. The resource sets are defined by the resource server, right? So the resource server would use that as part of the resource set?