Stream: implementers
Topic: GraphDefinition, use of compartments
René Spronk (Jul 09 2019 at 06:00):
Why does GraphDefinition use 'compartments'? I don't see a reason for them, expressing custom constraints on a graph IMHO has nothing to do with the concept of compartments in FHIR. Why compartments?
Ewout Kramer (Jul 09 2019 at 09:00):
One of the usecases that came up was that we'd like GraphDefinition to be able to validate a tree of data, especially the linkage, since that's pretty hard to do otherwise. So the <link> element has some additional tools to specify checks about that link. One of those checks is: are the source and target resource part of the same compartment? One use of this is that you can declare that a whole set of related resources in the tree should be from the same patient.
René Spronk (Jul 09 2019 at 13:12):
You could do that, but a) is that a 80% use case [to want to ensure that sub-trees (sub-graphs, really) are the same], b) why only subtrees as defined by the FHIR spec? It's 'compartment definitions (and these are fixed by FHIR)' may not agree with how my implementation wishes to define sub-trees. To me we'd need a solution to the general problem, of which comparing "FHIR compartments" is just one example (or even an extension on) the general use case. Isn't the 80% thing we want to achieve something like "in the resulting graph I want all patients to be one and the same", "in the resulting graph I want these and these resources to reference one and the same condition", "these two resources should NOt be the same resource instance" ?
René Spronk (Jul 10 2019 at 05:54):
And how would FHIR-resource-compartments be useful if we use GraphDefinition to express the structure of a graph of logical-models (e.g. DCMs, business data models, Dutch ZIBs, HL7v2, CDA R2)?
We need a different way of expressing that one desires one part of the graph-tree to be the same (or not the same) as some other specified part of the graph-tree. If 'that part' is just 1 resource, than FHIRPath will suffice. If not, then one would either have to list the resources-to-be compared exhaustively (and use FHIRPath for each such resource), or perhaps use GraphDefinition recursively to define some sub-graph. @Grahame Grieve ? I'm still questioning the need for comparision of whole sub-graphs. What's the primary use case?
Grahame Grieve (Jul 10 2019 at 22:54):
so there's a very clear and important use case around coherency, that a lot of real system implementers have raised - that's a primary deficiency of FHIR that a condition can reference a patient that is different to the encounter it references. That SHOULD NOT BE ALLOWED.
Except, of course, where it is correct, which are truly corner cases, but still valid.
So it's an important use cases to be able to say things like that. People who have raised it with me have hammered the patient compartment issue, so GraphDefinition solves that particular problem very concisely. Is that in the 80% overall - I think it is for GraphDefinition. Does the way it's solved solve your other problems - no. Should it? I don't know. FHIRPath is a much less processible way of solving the problem, but it may be good as an extension??
Last updated: Apr 12 2022 at 19:14 UTC
