Stream: implementers
Topic: Compartment search specifications
Grahame Grieve (Jun 14 2018 at 01:04):
@Christiaan Knaap in regard to GF#15906 - you know, from the compartment definition, that patient is a Patient, so the fact that target.patient and target.subject may target more than patients is ok - they ust don't count. No?
Christiaan Knaap (Jun 14 2018 at 11:15):
No. Let's take the first link, target.patient:
The link is from Provenance -> target (Any resource) -> patient.
So this implies an extra search argument of /Provenance?target.patient=<the patient in the compartment>.
But most of the allowed resourcetypes for Provenace.target do not have a patient search parameter.
I might be able to infer which of the resourcetypes would be in scope for this (probably the other types listed in the CompartmentDefinition linked through a patient parameter), but that leads to 2 problems:
1. You may run into "Servers SHOULD reject a search where the logical id refers to more than one matching resource across different types." Chained Parameters. This happens to be ok on Vonk because we use GUIDs, but that is not always the case.
2. Different resourcetypes may have different searchparameters, incidentally with the same name:
- Observation.patient, where the searchparameter is clinical-patient;
- MedicationRequest.patient, where the searchparameter is medications-patient.
I'm not sure whether that is allowed. At least it is unclear.
For target.subject the same problems arise.
John Moehrke (Jun 14 2018 at 19:23):
Is it reasonable to expect that Provenance exists within the patient compartment? Seems the usecases for Provenance start with the other object (source or target), and desire to learn more (aka Provenance). Provenance must be useable when the other resource is not patient specific, or is patient specific but not directly (Binary). Thus should we not just remove Provenance from the patient compartment?
Lloyd McKenzie (Jun 14 2018 at 19:30):
Provenance can live in multiple compartments simultaneously. It doesn't mean you can't search it outside of any compartment. Lots of compartment-specific resources won't always live in all compartments they're associated with. For example, an Observation made about a Location won't be in the Patient compartment, but the resource type is still associatable with that compartment. All the compartment link does is allow you to search using that compartment if the necessary relationship exists.
John Moehrke (Jun 14 2018 at 19:34):
Lloyd, I recognize that. I am just wondering what the use-case is for having Provenance be in the compartments? If declaring that Provenance is not in any compartment simplifies things, then why not do that? I am also fine with Provenance being in compartments. Are we doing similar gymnastics for AuditEvent? I see really good reason for AuditEvent to be declared as not to be included in compartments given the sensitive nature of ALL the auditEvents relative to those useful to a common user (signal to noise problem, as well as privacy/security issues).
Lloyd McKenzie (Jun 14 2018 at 19:59):
Provenance is intended to be user-facing and needs to be subject to the same compartment-specific access controls as clinical resources.
Lloyd McKenzie (Jun 14 2018 at 20:00):
I think audit events are outside compartments because they're expected to be highly sensitive and highly restricted. Though that doesn't mean we couldn't put them in the compartments too I guess
Grahame Grieve (Jun 14 2018 at 20:31):
AuditEvent is in the patient compartment, as is Provenance. Mixing access control issues into the syntax consideration is weird, to me
Grahame Grieve (Jun 14 2018 at 20:34):
back to @Christiaan Knaap's point: I think #1 is an issue. Doesn't arise for me because I resolve the index late.
Grahame Grieve (Jun 14 2018 at 20:35):
I'll have to review the way this is generated into CompartmentDefinition
Lloyd McKenzie (Jul 16 2018 at 20:07):
FHIR-I wants this conversation to continue: @James Agnew @Chris Grenz
Chris Grenz (Jul 17 2018 at 14:04):
I've always thought there's some tension/inconsistencies in how compartments are described. The combination of
The following resources are never in this compartment:
on the compartment definition page (e.g. http://hl7.org/fhir/compartmentdefinition-patient.html) with the verbiage in the last paragraph here, especially
Servers will need to make arrangements to make these resources available to the clients that are limited to particular compartments.
means that the definition of the compartment is admittedly (and intentionally?) inadequate. I would expect the test of the breadth of a compartment to be the $everything call on that compartment: [base]/Patient/123/$everything should logically return all the contents of the compartment. And if it's part of $everything, it's "in" the compartment, no?
While the meaning of "in" might be semantics, the technical definition leaves "making arrangements" an area of inconsistency.
Chris Grenz (Jul 17 2018 at 14:08):
To this specific issue, I agree with @Christiaan Knaap that the spec wording is a problem. Personally, I'd relax the chained search wording and put the error mode under the control of the prefer header directive. A strict query would fail on this type of chaining, a lenient would simply ignore it when searching resources that don't have the parameter.
Grahame Grieve (Jul 17 2018 at 21:24):
server can decide to include things in $everything that are referenced from the compartment, but not part of it.
Grahame Grieve (Jul 17 2018 at 21:25):
we discussed saying that the server had to return absolutely everything in the patient compartment as part of $everything, but backed away from that. but in principle, it should be
Grahame Grieve (Jul 17 2018 at 21:26):
But I'm not sure how this makes them inconsistent
Grahame Grieve (Jul 17 2018 at 21:26):
this is orthogonal to the question though
Chris Grenz (Jul 18 2018 at 14:23):
I'm not sure it's orthogonal as it goes to what's "in" the compartment, the technical definition of that set, and ultimately, the use case of a compartment.
Last updated: Apr 12 2022 at 19:14 UTC
