Stream: conformance
Topic: Search Parameter Combination Extension
Grahame Grieve (Dec 01 2021 at 06:29):
Opinions are solicited on this issue raised against the validator: https://github.com/hapifhir/org.hl7.fhir.core/issues/665
@Vassil Peytchev
John Moehrke (Dec 01 2021 at 12:09):
given how fluid search parameter 'configuration' is, it would be hard to know that a given parameter is not defined by someone. This seems unfortunate. I guess it might be possible in an IG, through the dependsOn to force that the search parameter has been defined somewhere in the IG scope. It does seem like at best a warning, which would enable an IG author to ignoreWarnings...
Vassil Peytchev (Dec 01 2021 at 14:08):
The specific issue is about the combined search parameters within the REST supported resource structure within a capability statement (CapabilityStatement.rest.resource). My suggestion is to validate that the combined search parameters found within CapabilityStatement.rest.resource.extension are also present as individual search parameters (as MAY, if support for the individual search parameter is not part of the IG) in CapabilityStatement.rest.resoource.searchParam. That way at least the type of each component in the combined parameters has to be declared. This is within the "power" of the IG author to make sure it is present.
Whether CapabilityStatement.rest.resoource.searchParam.definition is present, that is currently optional, but it is nice to have too.
Vassil Peytchev (Dec 08 2021 at 18:16):
There is a visual representation of how things can potentially look if the combined search parameters are also present as individual search parameters in the capability statement: https://hl7.org/fhir/uv/ipa/2022Jan/CapabilityStatement-ipa-server.html
The information about the parameter type can only come from the individual search parameter declaration, and if it is not present, the only thing that can be rendered is unknown.
Last updated: Apr 12 2022 at 19:14 UTC
