Stream: implementers
Topic: Compartment search behaviour
Jonny Rylands (Feb 26 2020 at 10:05):
GET [base]/Patient/333/Condition GET [base]/Condition?patient=333
Where patient 333 is not found on the FHIR server, the two requests above will return an empty bundle, as per https://www.hl7.org/fhir/compartmentdefinition.html#use.
I have two questions regarding this:
1.The first request's behaviour (the compartment based search) seems unintuitive since requesting a root of the compartment based search URL would return a 404 if patient 333 was not found.
I.e. "intuitively" i would expect these two requests to behave in the same way if patient 333 was not found:
GET [base]/Patient/333 GET [base]/Patient/333/Condition
Is there something I'm missing as to why the compartment based search returns an empty bundle when the patient is not found?
- The specification goes on to say:
Some systems will include an operation outcome warning that there is no matching patient.
Does this mean an OperationOutcome resource return within the (empty) Bundle response?
Jens Villadsen (Feb 26 2020 at 12:20):
You cannot expect the same service is hosting both Patient and Condition
Jens Villadsen (Feb 26 2020 at 12:21):
If Condition and Patient is hosted on two different FHIR servers, you cannot traverse both resources on both servers
Jens Villadsen (Feb 26 2020 at 12:22):
you can however assume that (given some assumptions regarding referential integrity) that the server hosting Condition is able to find Conditions which have a reference to Patient
Lloyd McKenzie (Feb 26 2020 at 16:27):
Under the covers, the first URL is treated just like the second. It's still a search, even though the URL isn't structured like one.
Jens Villadsen (Feb 26 2020 at 18:03):
@Lloyd McKenzie is that required by the spec?
Jens Villadsen (Feb 26 2020 at 18:04):
Because im pretty sure that wont hold in a sharded microservice setup
Lloyd McKenzie (Feb 26 2020 at 18:07):
The spec is pretty clear: The outcome of a compartment search is the same as the equivalent normal search. For example, both these searches return the same outcome if there is no patient 333:
GET [base]/Patient/333/Condition
GET [base]/Condition?patient=333
Jens Villadsen (Feb 27 2020 at 08:58):
While it may be 'semantically equivalent', it is not 'syntactically equivalent' - a server only hosting the Patient resource would probably fail on GET [base]/Patient/333/Condition if it doesn't host the Condition resource - whereas a server hosting the Condition resource with stored references to patient resources would probably support GET [base]/Condition?patient=333
Jens Villadsen (Feb 27 2020 at 10:14):
@James Agnew @Lloyd McKenzie FYI - in that case the HAPI implementation does not comply with compartments search.
while
http://hapi.fhir.org/baseDstu3/Patient/2684442/Appointmentdoes not work,
http://hapi.fhir.org/baseDstu3/Appointment?patient=Patient/2684442 does work
James Agnew (Feb 27 2020 at 10:39):
Yup, that first syntax isn't currently supported in HAPI, although it is valid FHIR.
Jonny Rylands (Feb 27 2020 at 21:06):
OK thanks all for your responses.
Jens Villadsen (Feb 27 2020 at 21:58):
Lloyd McKenzie said:
The spec is pretty clear:
The outcome of a compartment search is the same as the equivalent normal search. For example, both these searches return the same outcome if there is no patient 333: GET [base]/Patient/333/Condition GET [base]/Condition?patient=333
What constitutes a normal search? Is that defined anywhere? If not, I would avoid such term as normal
Lloyd McKenzie (Feb 27 2020 at 23:06):
I just meant one not using the compartment syntax
Jens Villadsen (Feb 28 2020 at 10:07):
Still - the term normalis ambiguous and context dependent.
Dag Roppe (Oct 30 2020 at 14:41):
Question on compartment searches. Can I search across all resources in a defined compartment with search parameters valid for all resources?
Like GET [base]/Patient/[id]?parameter(s) Is this Valid? I didn't see anything in the spec that would make it invalid.
So a search like this might be useful: Get [base]/Patient/[id]?_lastUpdated=ge2020-10-30
To get all patient related resources updated recently.
Lloyd McKenzie (Oct 30 2020 at 15:33):
We haven't defined that that's allowed, though we haven't prohibited it either. If it's functionality you'd like be explicitly supported, you could submit a change request
Last updated: Apr 12 2022 at 19:14 UTC
