Stream: implementers
Topic: CompartmentDefinition
Angus Millar (May 02 2018 at 02:02):
I feel there is a syntax error in the CompartmentDefinition example resource and the Compartment Patient page here: http://build.fhir.org/compartmentdefinition-patient.html . In both there is a search parameter referances which allows the AuditEvent resources to be in the Patient compartment, same issue exsits for the Provenance resource in Patient Compartment as well. Focusing on the AuditEvent case the search parameters given are agent.patient or entity.patient. These are chain syntax using the '.' yet I'm not confident that this was the intent. I question weather the intent was to have a parameter such as agent:Patient or entity:Patient where we are explicitly saying only references that are to a Patient resource in the Compartment. At present agent.patient or entity.patient is saying any resource this reference points to where that resource has a search parameter called 'patient' . So to summarise I am questioning should this agent.patient or entity.patient actually be agent:Patient or entity:Patient? And I do realise that Compartment search parameters can be chain parameters, I'm asking is the use of a chaining parameter correct in these cases.
Angus Millar (May 02 2018 at 02:39):
Actualy I'm now begining to think the way it currently is in the spec is intended. This section from the chaining docuemntation is key, and also something I have never liked. "Advanced Search Note: Where a chained parameter searches a resource reference that may have more than one type of resource as its target, the parameter chain may end up referring to search parameters with the same name on more than one kind of resource at once. Servers SHOULD reject a search where the logical id refers to more than one matching resource across different types. For example, the client has to specify the type explicitly using the syntax in the second example above." I've never liked this as it seamed like a vague form of matching. To that point in my server I forced that when the referance points to n resources the client MUST specify the type. Yet this has now come unstuck for me when it comes to Compartments. My problem to work on!
Angus Millar (May 02 2018 at 09:25):
I'm now back where I started and think this is this incorrect or at least not workable. If we have a Patient Compartment and it is deemed that AuditEvent resources are in that Patient Compartment based on any of the following search parameters :
Patient Compartment AuditEvent search parameters:
- patient : acts on ResourceTypes: (Patient)
- agent.patient : acts on ResourceTypes: (Practitioner, Organization, Device, Patient, RelatedPerson)
- entity.patient: acts on ResourceTypes: (Any)
Given this, I would say that it is highly likely that a Patient would have AuditEvents for more than a single one of the allowed Resource Types. For instance, 'AuditEvent.entity.patient' is a reference to a resource involved in the audited event where that resource has a 'patient' search parameter, and it can reference any resource type. That is 28 resource in total with the patient parameter.
If I am trying to get all AuditEvent resource for a given Patient compartment then it would only take two AuditEvent resources across all instances of the 28 types to have a reference to the same patient compartment resource id, and if so, the search is to be rejected based on the Advanced Search Note for Chaining, as quoted in the comment above.
So as an example, if I have an AuditEvent resource pointing to a DiagnosticReport resource as its entity, and also another AuditEvent resource pointing to an Observation resource as its entity, and both have the same patient, then the search is to be rejected based on the rule. I would have thought this happens 80% of the time if not more.
I would have thought the resolution to this is that all 28 'entity' search parameters should be explicitly stated in the compartments search parameters. like this:
entity:DiagnosticReport.patient
entity:Observation.patient
entity:Encounter.patient
entity:Procedure.patient
...etc for all 28 possible, in fact, the same need to occur for any chained parameter in a CompartmentDefinition where that parameter has more than a single possible ResourceType.
Grahame Grieve (May 05 2018 at 04:44):
well, it was intended to be chain search. It's trying to say something simple; an audit event falls into a patient compartment if it's an audit on a resource about the patient
Last updated: Apr 12 2022 at 19:14 UTC
