Stream: implementers
Topic: custom CompartmentDefinitions and authorization
Jens Villadsen (Mar 13 2019 at 11:46):
How come the CompartmentDefinition.code is not extensible? If compartmentDefinitions are meant to be of use in some authorization use cases, and eg. the part that grants access to a certain set of resources goes through eg. a CareTeam, it's sort hard to do currently.
Lloyd McKenzie (Mar 13 2019 at 14:51):
At the moment, because compartment definitions drive code so much, we've said that only HL7 can define and change them. That doesn't mean we couldn't revisit that decision though.
Jens Villadsen (Mar 13 2019 at 19:56):
That would still be the case if the set is extensible.
Christiaan Knaap (Apr 11 2019 at 09:14):
I think a GraphDefinition is more capable of expressing authorization rules than a CompartmentDefinition. Anyone else's thoughts on that?
John Moehrke (Apr 11 2019 at 12:17):
Realistically: Security and Privacy will leverage anything they can when it comes to rules writing and rules enforcing. This is why there is no singular binding of a security model to FHIR.
John Moehrke (Apr 11 2019 at 12:21):
Compartment in terms of REST is related to Compartment in terms of Security; but they are not the same thing. As I said above, security is happy to leverage the REST (CompartmentDefinition) compartment mechanism. However Security-labels include the concept of compartment as a tag. Local domains will identify compartments, and put that tag on all the data that is to be considered within that compartment. This concept of compartment as a tag is the Security domain concept of Compartment. This concept of compartment is what you will see in a government system, like military. These security compartment tags are completely dynamic, and universally supported in the FHIR specification.
John Moehrke (Apr 11 2019 at 12:23):
On GraphDefinition, I would agree this is also a good tool for Privacy and Security. I would love to see someone propose this as a model for writing the rules of a Privacy-Consent. The nice part of this is that the graph definition is managed independent of the data, and thus is more flexible to changes in policy. @Christiaan Knaap do you have an example?
Christiaan Knaap (Apr 11 2019 at 12:24):
No, I haven't - I have not left the theoretical phase yet.
Christiaan Knaap (Apr 11 2019 at 12:25):
I was interested in community thoughts on this because it would mean that custom CompartmentDefinitions (that @Jens Villadsen requested) are not that neccessary.
John Moehrke (Apr 11 2019 at 12:27):
Compartments in the REST domain are far less dynamic, much more like FHIR has today.
Lloyd McKenzie (Apr 11 2019 at 14:20):
When I was talking about Compartment from a security perspective, I was referring to the RESTful compartments. I.e. a practitioner might have access to data in one patient's Compartment, but not another. Or a Practiioner might always have access to data that's in their Compartment. This use of Compartment is more common than using it as a query mechanism
Grahame Grieve (Apr 12 2019 at 20:52):
also, this use is implicit not explicit
Grahame Grieve (Apr 12 2019 at 20:52):
Compartments are very challenging when they are based on indirect references. I don't see how we'd make a CareTeam compartment work
Jens Villadsen (Apr 23 2019 at 12:24):
Right - having thought about it, Careteams is probably not a good fit. As I see it, compartments more or less works as a set of restrictions for an entity (machine or person) that in some unspecified way can act as a user to the system. In that perspective, a Careteam is not part of that definition as it more or less consists of a group of entities
nicola (RIO/SS) (Apr 23 2019 at 20:57):
Here how we do custom compartments - https://docs.aidbox.app/tutorials/compartments
Last updated: Apr 12 2022 at 19:14 UTC
