FHIR Chat · Extend the definition of SearchParameters? · conformance

Stream: conformance

Topic: Extend the definition of SearchParameters?


view this post on Zulip Simone Heckmann (Jul 08 2019 at 08:25):

Situation: We have a german extension for Patient.gender, to differentiate between two different kinds of "other", adding the codes "undetermined" and "divers", somewhat like this:

<gender value="other">
    <extension url="http://fhir.de/StructureDefinition/gender-amtlich-de"/>
        <valueCode value="divers"/>
    </extension>
</gender>

If we want to be able to search for Patients of gender "divers", do we need to add a new SearchParameter, or is there a way to "extend the reach" of the existing genderParameter (by adding another FHIRPath expression) to also include the values from the extension, to allow queries like /Patient?gender=divers? Can an IG extend the definition of SearchParameters?

view this post on Zulip Brian Postlethwaite (Jul 08 2019 at 08:45):

Th IG would need to have another search parameter, or filter to other server side, and divers on client side.

view this post on Zulip Simone Heckmann (Jul 08 2019 at 08:46):

I thought so. But it felt worth asking :)

view this post on Zulip Eric Haas (Jul 08 2019 at 15:10):

Hold on, what if SP.derivedFrom = gender SP and then you value SP.expression. What does that mean? Is that expression in addition to the gender SP or instead of the gender1 SP ?

view this post on Zulip Simone Heckmann (Jul 09 2019 at 08:28):

I would think that an SP that is derivedFrom a core SP sort of "overwrites" the original SP definition.
So in my case, the derived SP would have to specify both the path to Patient.gender as well as Patient.gender.extension

The spec says

If a derivedFrom is provided, then the details in the search parameter must be consistent with the definition from which it is defined. i.e. the parameter should have the same meaning, and (usually) the functionality should be a proper subset of the underlying search parameter.

So technically what I was proposing doesn't fit the bill for "proper subset". But then again, this sounds like a very soft SHOULD... :smiling_devil:

view this post on Zulip Brian Postlethwaite (Jul 09 2019 at 23:07):

Subset, not superset.


Last updated: Apr 12 2022 at 19:14 UTC