Stream: conformance
Topic: Capability Search Parameter
Ruth berge (Apr 16 2021 at 01:11):
My question is about the _id search parameter and any other search parameters that are related to all. the documentation says "Parameters for each resource
In addition to the _id parameter which exists for all resources, each FHIR resource type defines its own set of search parameters with their names, types, and meanings". My question is, do we need to add _id as a search parameter to every resource? Is that a best practice or normal behavior for a FHIR server?
Jose Costa Teixeira (Apr 16 2021 at 04:46):
Are you asking if the impact of the spec spec is that the _id parameter needs to be added? Or are you asking if the spec is correct in asking that?
Jose Costa Teixeira (Apr 16 2021 at 04:47):
my reading of the spec is that every server must implement the _id search parameter for all resources (the same way they must support the id element)
Lloyd McKenzie (Apr 16 2021 at 14:14):
The fact that it 'exists' doesn't mean a server must support it.
Ruth berge (Apr 16 2021 at 16:48):
My question isn't whether a server should implement the _id parameter. I tested it and it works. My question is whether, in the Capability Statement, for each and every resource type , do we need to add a statement like "searchParam": [
{
"name": "_id",
"type": "token",
"documentation": "The ID of the resource"
},
OR is it assumed that every resource will support that and it doesn't have to be called out in the Capability Statement. It isn't a question of whether it is supported, but whether the Capability Statement should list it. And really, it is understanding the crowd usage or best practice.
Lloyd McKenzie (Apr 16 2021 at 17:20):
You should explicitly be stating it. It can't be safely inferred. (Agree that it's a pain, so if you want to submit a change request for us to define an easier way to say "I support these search criteria for all supported resources", that wouldn't be a bad idea.)
Eric Haas (Apr 16 2021 at 22:18):
US Core did it here: http://build.fhir.org/ig/HL7/US-Core/CapabilityStatement-us-core-server.html#patient for example.
Rick Lisseveld (Apr 29 2021 at 15:55):
Lloyd McKenzie said:
The fact that it 'exists' doesn't mean a server must support it.
If the SearchParameter _id is not required then I believe the following statement in the spec is confusing
"Servers are not required to implement any of the standard search parameters (except for the _id parameter described above). "
https://www.hl7.org/fhir/search.html#parameters
Prior to reading the feedback from @Lloyd McKenzie , I had the same opinion as @Jose Costa Teixeira . What was the sentence meant to convey in this context if not that _id was the exception to the rule?
Lloyd McKenzie (Apr 29 2021 at 16:01):
To be honest, I'm really not sure. Can you submit a change request for us to clarify?
Rick Lisseveld (Apr 29 2021 at 17:35):
Thanks Lloyd. The change request has been created https://jira.hl7.org/browse/FHIR-32018
Grahame Grieve (Apr 29 2021 at 20:20):
When I wrote that it was certainly intended that _id must be supported; it's synonymous with a read but allows for _include. But technically, it must be supported if read is supported, I guess
Lloyd McKenzie (Apr 29 2021 at 20:36):
It's not totally clear to me why that's a "must". If a system doesn't choose to support any _includes, forcing them to support multiple search syntaxes doesn't seem reasonable. We allow you to say "I support 'read', but not 'search'", and this would essentially make that impossible.
Grahame Grieve (Apr 29 2021 at 20:47):
I'm just saying what we meant at the time
Last updated: Apr 12 2022 at 19:14 UTC
