Stream: implementers
Topic: CapabilityStatement.rest.searchParams for common params
Cooper Thompson (Feb 10 2021 at 15:46):
Can/should CapabilityStatement.rest.searchParam be used to document search params that are common across all resources listed in CapabilityStatement.rest.resources? For example, _id, _count, _revInclude, _include. Or should those be duplicated in every single resource listed in CapabilityStatement.rest.resource?
On the one hand, it is slightly more convenient for client parsers to have everything for single resource in one spot (rest.resource.searchParams). On the other hand, CapabilityStatements can get very large, and duplicating identical params across all resources just adds to the bloat.
Lloyd McKenzie (Feb 10 2021 at 15:46):
@Grahame Grieve
René Spronk (Feb 10 2021 at 15:48):
if a parameter is really supported in the very same way, inclusive of modifiers, comparators, etc., accross all resource types, then that's what CapabilityStatement.rest.searchParams is for. Whether that's a SHALL, now that's another question.
Eric Haas (Feb 10 2021 at 16:47):
I do it for each resource for expectations in IGs. But I can see it being done system wide for instances
Cooper Thompson (Feb 10 2021 at 16:49):
@Eric Haas Did US Core have a section somewhere I missed that has expectations for them to be in each resource?
Cooper Thompson (Feb 10 2021 at 16:55):
I see that the US Core Server CapabilityStatement says what params are required for each resource, but it doesn't say which level in CapabilityStatement those should be documented.
Yunwei Wang (Feb 10 2021 at 17:13):
The definition for system level search parameter is "Search parameters that are supported for searching all resources". How to interpret this?
- the search parameter that search all resources. eg:
GET [base]?[parameters]{&_format=[mime-type]} - the search parameter defined for all resources. The second column in this table https://www.hl7.org/fhir/search.html#Summary
- the search parameter commonly supported by all resources on this server (as @Cooper Thompson mentioned)
Eric Haas (Feb 10 2021 at 18:24):
the capabilitystatement list expectation both by system and resource type. For each resource type there is an expectation listed and for example Patient lists _id: http://hl7.org/fhir/us/core/CapabilityStatement-us-core-server.html#patient
Eric Haas (Feb 10 2021 at 18:24):
As an implementer this expectation would be met by making the support for _id systemwide
Eric Haas (Feb 10 2021 at 18:31):
US Core does not make system-wide search expectations but a resource type search parameter would be subsumed by that. I think that is self-evident, but if you think it should be explicit or specific guidance on how to take a CapabilityStatement of type = requirements (e.g.from an IG ) and convert it to a type instance. Like I mention briefly here: https://argonautproject.github.io/patient-lists/CapabilityStatement-server.html Then feel free to log a tracker.
Grahame Grieve (Feb 10 2021 at 20:16):
hmm, I see that we have a lack of clarity in the documentation here @Cooper Thompson and @René Spronk
rest.resource.searchParams is for search parameters that are supported when the client searches with a type specified. e.g.
GET [base]/?_type=Patient,Practitioner&...
Grahame Grieve (Feb 10 2021 at 20:16):
it's not for search parameters that are supported on all the kinds of resources supported.
Yunwei Wang (Feb 10 2021 at 20:34):
@Grahame Grieve when you say
rest.resource.searchParams is for search parameters that are supported when the client searches with a type specified.
do you mean
rest.searchParams is for search parameters that are supported when the client searches with a type specified.
Grahame Grieve (Feb 10 2021 at 20:38):
duh. I meant, without
Cooper Thompson (Feb 10 2021 at 21:03):
So it sounds like:
- I should submit a tracker to add clarification that using rest.searchParams is not appropriate for parameters that apply to all resources
- The Inferno Program Edition tests are correct as they are, where they are ignoring rest.searchParams and only checking rest.resource.searchParams for US Core compliance, so I'll close Issue#230
- Epic will need to update our CapabilityStatement to move our params that are common across all resources into rest.resource.searchParams
Cooper Thompson (Feb 10 2021 at 21:09):
FHIR#31051 - Clarify the use of CapabilityStatement.rest.searchParams
Eric Haas (Feb 11 2021 at 00:52):
I am still confused. What grahame is saying is that there is currently no way to define that _id applies to all resources?
But the others that @Cooper Thompson listed (_count, _revInclude, _include) are appropriate for CapabilityStatement.rest.searchParam?
I don't see why _id is excluded?
Last updated: Apr 12 2022 at 19:14 UTC
