Stream: implementers
Topic: SearchParam names in CapabilityStatement
Lee Surprenant (Jun 01 2020 at 17:38):
We recently ran Touchstone against our server and found it was failing this check: searchParam.select(name).isDistinct()
Lee Surprenant (Jun 01 2020 at 17:38):
the root cause seems to be some duplicate names from SearchParameters we got from PDEX PlanNet
Lee Surprenant (Jun 01 2020 at 17:39):
the codes are unique but the names are not
Lee Surprenant (Jun 01 2020 at 17:39):
the 'name' vs 'code' thing has tripped us up in the past as DSTU2 wasnt' very clear on the difference
Lee Surprenant (Jun 01 2020 at 17:40):
are folks really putting SearchParameter.name into their CapabilityStatement.rest.resource.searchParam.name or is anyone using SearchParameter.code ?
Lee Surprenant (Jun 01 2020 at 17:41):
code seems a lot more useful since thats what you actually perform the search with
Paul Church (Jun 01 2020 at 17:42):
We also ran into this and I agree that the cap statement should list code...otherwise how would the client know how to call the search parameter?
Lee Surprenant (Jun 01 2020 at 17:42):
It could work if they dereferenced the Reference(SearchParameter) definition
Lee Surprenant (Jun 01 2020 at 17:43):
but that field is optional
Lee Surprenant (Jun 01 2020 at 17:43):
and currently we don't offer that for any built-in parameters
Lee Surprenant (Jun 01 2020 at 17:43):
so it would be nice if you could just go by the code
Lee Surprenant (Jun 01 2020 at 17:43):
will open a Jira for it
Lee Surprenant (Jun 01 2020 at 17:56):
Lloyd McKenzie (Jun 01 2020 at 17:56):
There's no expectation that 'name' or 'code' will necessarily be unique in all SearchParameter instances. CapabilityStatement.rest.resource.searchParam.name however must be unique. There is no requirement that resource.searchParam.name will always be the same as SearchParameter.code, though it's best practice for them to be the same when possible (and there's no issue with duplication of names).
Lee Surprenant (Jun 01 2020 at 17:57):
name vs code is already confusing; highly recommend adding language to indicate that this SHOULD match the corresponding code
Lee Surprenant (Jun 01 2020 at 17:58):
or at least that it might not match the SearchParameter.name
Lloyd McKenzie (Jun 01 2020 at 17:58):
Happy to have a change request to that effect - though it should also notice that distinct names will be necessary for disambiguation. It generally won't match SearchParameter.name - which is for code generation.
Lee Surprenant (Jun 01 2020 at 17:59):
i opened it as a clarification
Lee Surprenant (Jun 01 2020 at 17:59):
but feel free to change it to a change request
Lee Surprenant (Jun 01 2020 at 18:05):
question: in the case of disambiguating two definitions with the same code, will the "name" in CapabilityStatement.rest.resource.searchParam be the queryParameter name that clients can use in their queries?
Lee Surprenant (Jun 01 2020 at 18:05):
trying to udnerstand what "used in the interface" means...could be
A. the display name that is presented to end users; or
B. the query parameter name in the API (interface)
PKumar (Jun 01 2020 at 18:22):
Can we use HAPI FHIR to create FHIR based application?
Michele Mottini (Jun 01 2020 at 18:24):
@Pavan kumar seepana yes. There is a #hapi stream specifically for HAPI-related questions
Lee Surprenant (Jun 22 2020 at 16:35):
Lee Surprenant said:
question: in the case of disambiguating two definitions with the same code, will the "name" in
CapabilityStatement.rest.resource.searchParambe the queryParameter name that clients can use in their queries?
I'm still hoping for some confirmation on this one. I'm finding that IGs will frequently redefine search parameters that are already defined in the base spec (typically using the same expression or a similar one, with the same code, but with a different canonical url and id). I will open a separate topic for whether they should do that, but for this topic I just wanted to confirm whether the CapabilityStatement.rest.resource.searchParam.name is intended to be the string a client should use in their URL to search via this parameter (in cases where it may conflict with SearchParameter.code)
Grahame Grieve (Jun 23 2020 at 21:53):
yes
Lee Surprenant (Jun 23 2020 at 22:11):
thanks graham, I updated FHIR#27755 with this confirmation...I still think it could be a bit more clear in the spec, but I think I understand how this is supposed to work now: in cases where the SearchParameter.code has a conflict, an implementation may choose to expose that SearchParameter using a name which differs from the SeachParameter.code and, in such cases, a client should use the string from CapabilityStatement.rest.resource.searchParam.name in their queries
Last updated: Apr 12 2022 at 19:14 UTC
