Stream: implementers
Topic: Advanced search note - chaining
Michael Calderero (May 20 2019 at 03:47):
At the bottom of http://hl7.org/fhir/R4/search.html#chaining, there's text that says:
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.
This same note was present in STU3 (i.e. https://www.hl7.org/fhir/STU3/search.html#chaining).
If I were to interpret this, would this mean that searches like AuditEvent?entity.patient=X (i.e. http://hl7.org/fhir/STU3/compartmentdefinition-patient.html) would always be rejected? I surmise that's why in R4, the Patient compartment had removed these types of searches from the list?
For the record, our FHIR server can handle AuditEvent?entity.patient=X but my other question is since the spec says "server SHOULD reject a search" does that mean we're not following the FHIR standard anymore? I tend to think that following the SHALL, MUST and SHOULD of the spec means we're FHIR-compliant and not following those would mean the opposite?
Michele Mottini (May 20 2019 at 11:38):
entity.patient=x is wrong - it should be entity:Patient=x or entity=Patient/x
Chaining works with search parameters of the target resource - so entity:Patient.name=Smith (and because entity has more that one type of resource as its target the :Patient part is needed)
Michael Calderero (May 20 2019 at 12:34):
So you're saying that the compartment definition of Patient for STU3 is wrong/non-executable if there's an AuditEvent resource?
Last updated: Apr 12 2022 at 19:14 UTC
