Stream: IG creation
Topic: Adding a combination of search parameters
Vassil Peytchev (Nov 17 2021 at 22:06):
I am trying to add patient and patient+clinical-status as search parameters to AllergyIntolerance, using the Search Parameter Combination extension, and I have some questions questions:
- Is it OK to have only patient and patient+clinical-status listed, but not clinical-status by itself?
- In the FHIR core R4 package, there doesn't seem to the an AllergyIntolerance-patient search parameter defined. Is that a problem? Answer: No, the shared search parameter is
clinical-patient - I am populating the IG's CapabilityStatement with the search parameters information. Is there another place to add that information?
- If I am not profiling the search parameters in any way, do I need to add them as resources to the IG?
Eric Haas (Nov 17 2021 at 22:30):
Is it OK to have only patient and patient+clinical-status listed, but not clinical-status by itself?
I list em all, but I don't know if can omit them individually?
I am populating the IG's CapabilityStatement with the search parameters information. Is there another place to add that information?
We use Quick Starts documentation in US Core - it is up to the author how they want to inform the reader
- If I am not profiling the search parameters in any way, do I need to add them as resources to the IG?
no - we modify them in US Core specify type and conformance expectations for the optional elements like multiple ors , but you can just reference the core sps
Vassil Peytchev (Nov 17 2021 at 22:37):
I list em all, but I don't know if can omit them individually?
My question is even at a higher level - can I omit saying anything about support for clinical-status by itself, but talk about patient+clinical-status?
Eric Haas (Nov 17 2021 at 23:39):
try it and see if it passes validation.
Vassil Peytchev (Nov 18 2021 at 00:02):
It does... I'll do another check to see how far it can be pushed.
Eric Haas (Nov 18 2021 at 00:05):
well I think you can, because in out narrative we only display the SHALL SHOULD for combo searches and omit the MAY for the individual- even though they are in the CApstatement as MAY ( I may remove them at some point). There is nothing prohibiting a client from trying a SP but the server can reject it too.
Vassil Peytchev (Nov 18 2021 at 00:09):
The question is whether clinical-status on its own can be omitted from the capability statement (since it's present in core anyway)...
Grahame Grieve (Nov 18 2021 at 00:31):
do I need to add them as resources to the IG?
Grahame Grieve (Nov 18 2021 at 00:31):
no
Eric Haas (Nov 18 2021 at 02:36):
Vassil Peytchev said:
The question is whether clinical-status on its own can be omitted from the capability statement (since it's present in core anyway)...
There is a lot stuff in the core, but because it is in the core does not mean that it will be implemented. The IG cap statement can provide that expectation. You could just say use em all + these swell combos, but when we asked we got a limited set that would be supported broadly and thus stuck with those.
Vassil Peytchev (Nov 18 2021 at 16:00):
My findings so far are that there is no validation done to check that the components of a combination are search parameters on their own - see issue #665 on GitHub. It will be probably much easier to do that validation, if the individual components are present as SearchParameter in the capability statement for the IG, even if they are of the "MAY" type.
Eric Haas (Nov 18 2021 at 16:05):
Yes and we got feedback that having only some SP as MAY in capabilitystatement but omitting others we did not need was suggesting that those omitted are excluded, which is wrong but something to consider ( how the audience misinterprets things)
Last updated: Apr 12 2022 at 19:14 UTC
