Stream: implementers
Topic: SearchParameter expectation
Yunwei Wang (Oct 19 2021 at 14:30):
Yesterday, we had a very deep discussion on FHIR-I call about multipleAnd/multipleOr in SearchParameter. I am wondering how SearchParameter is used in real world by server and client implementers. For example, US Core defines Patient's name search as image.png.
The name search parameter has multipleAnd: True, Conformance Expectation = MAY). So it is up to the server implementer to decide if a server instance supports multipleAnd search and the server implementer has to declare his own SearchParameter for patient's name search to make that clear.
Should this searchParameter derivedFrom USCore's patient name search parameter? (I think so)
Can this searchParameter have multipleAnd: False? (I think so too)
I think the problem is that SearchParameter has multiple purpose, just like CapabilityStatement. When used in IG, it is a requirement for server implementation to meet. When used by a server instance, it is a capability the instance support.
I think we should distinguish these two use cases.
@Grahame Grieve @Lloyd McKenzie @Josh Mandel
Eric Haas (Oct 19 2021 at 18:38):
It is important to note that the SP in US Core are for documenting Server expected capabilities as Yunwei pointed out.
Should this searchParameter derivedFrom USCore's patient name search parameter? (I think so)
They are not intended to be a base SP upon which to be derived. I would recommend using the base SP instead.
Yunwei Wang (Oct 19 2021 at 19:35):
That is confusing. A US Core compliant server has a SP not derived from corresponding US Core SP.
Eric Haas (Oct 20 2021 at 01:35):
A US Core compliant server having a SP with the same code as a base SP is implicitly using the base SP not a derived SP. They can document its capabilities the same way as the IG using the base SP and not US Core.
Yunwei Wang (Oct 20 2021 at 13:29):
Eric Haas said:
server having a SP with the same code as a base SP is implicitly using the base SP not a derived SP.
Is this written somewhere?
I thought it was the other way.
Eric Haas (Oct 20 2021 at 15:08):
That was the result of several chats and from @Lee Surprenant who was all over this. :-) bottom line you can't make up your own SP and call the same thing - hows a client to know what its searching for if my patient searches for patient and yours redefined patient searches for status. But you are correct, the spec only states this obliquely here:
Also, there is a single page that lists all the search parameters. Note that search parameter names are case sensitive, though this specification never defines different parameters with names that differ only in case. Clients SHOULD use correct case, and servers SHALL not define additional parameters with different meanings with names that only differ in case.
And I cannot find any trackers...
Lloyd McKenzie (Oct 20 2021 at 18:25):
You absolutely can make up your own SP and call it the same thing. The obligation is actually on the client to look at the CapabilityStatement and determine what a given search string corresponds to. I do agree that it's bad practice to name things the same as an official HL7 search parameter that mean something different, but given that HL7 can define new things in future versions and everyone else can make up search parameters named whatever they like, you can't trust that the meaning of a search string is the same on every server - you must always check the CapabilityStatement and the SearchParameter definitions.
Eric Haas (Oct 20 2021 at 19:54):
Although I personally think those search parameters should be reserved and only mod, comps, mult ands , mult ors changeable, that little nugget should be in the patient safety checklist
Lloyd McKenzie (Oct 20 2021 at 20:37):
Feel free to submit a change request re: the safety list.
The problem with "reserving names" is that core can introduce new names at any time. So can HL7 International-published IGs. So a name that was "free" to use a year ago might conflict with an HL7-defined name today.
Yunwei Wang (Oct 20 2021 at 20:54):
How about the original question I asked, should we add a .kind (like CapabilityStatement) to indicate this SP is a "requirement" or a "instance"?
Lloyd McKenzie (Oct 20 2021 at 22:05):
I don't understand that. A SearchParameter is always a 'definition' - it's a kind of thing that can be searched upon. Servers can point to an SP defined in an IG directly.
Eric Haas (Oct 21 2021 at 00:43):
uh-uh ... US Core express expected support of mods, comps, ors and ands. They are not implementable out of the box and have to be transformed to instances. I think Yunwei's idea has merit.
Lloyd McKenzie (Oct 21 2021 at 01:35):
The default is that everything is there - if you support everything, you can use the ones out-of-the-box from the FHIR spec.
Eric Haas (Oct 21 2021 at 03:26):
The default is that everything is there
Lloyd McKenzie said:
The default is that everything is there - if you support everything, you can use the ones out-of-the-box from the FHIR spec.
Where is that asserted in the FHIR Spec? to me that mean all mods, comps, ands and ors and types are supported.
Daniel Venton (Oct 21 2021 at 12:56):
Lloyd McKenzie said:
You absolutely can make up your own SP and call it the same thing. The obligation is actually on the client to look at the CapabilityStatement and determine what a given search string corresponds to. I do agree that it's bad practice to name things the same as an official HL7 search parameter that mean something different, but given that HL7 can define new things in future versions and everyone else can make up search parameters named whatever they like, you can't trust that the meaning of a search string is the same on every server - you must always check the CapabilityStatement and the SearchParameter definitions.
Tips on preventing any future HL7 defined search parameter from stepping on your current custom search parameter. Don't name your search parameter the same as any attribute on any current resource. Name it with your vendor name. Instead of searching for "thething" "epic_thething" it's unlikely that HL7 will ever use a high profile vendor name in a core name.
Lloyd McKenzie (Oct 21 2021 at 13:13):
You can do that. However, the resolution mechanism is still "don't trust the name, look at the declared URL in the CapabilityStatement".
Last updated: Apr 12 2022 at 19:14 UTC
