FHIR Chat · CapabilityStatement > Custom Search Parameter

Stream: implementers

Topic: CapabilityStatement > Custom Search Parameter

Eduard de Rijcke (Nov 04 2019 at 13:22):

Hi,

I've a question about CapabilityStatement.rest.resource.searchInclude.

To my knowledge, normally you would include the resource path here. How does this work if you would want to use an include on a custom search parameter defined in an extension?

Would you use a FHIR path expression like this?

<resource>
           <type value="Procedure" />
           <interaction>
               <code value="search-type" />
           </interaction>
           <searchInclude value="Procedure. extension('http://example.com/extensionURL')" />

Michele Mottini (Nov 04 2019 at 13:30):

I do not think a resource path goes there - it is the actual value to use for the _include parameter - eg Procedue:custom-search-parameter - where that is the name of the search parameter corresponding to that extension

Ardon Toonstra (Nov 04 2019 at 15:36):

Thanks @Michele Mottini ,
That would have been my first guess as well. However, if I look at the CapabilityStatement examples in the FHIR spec I see that a path is used.

So for https://www.hl7.org/fhir/stu3/capabilitystatement-base.xml.html a path is used in .searchInclude while in .searchParameter.name the searchparameter name is used.

Michele Mottini (Nov 04 2019 at 15:42):

Seems wrong to me - and they are not even exactly the path :

       <searchInclude value="Account.subject"/>
      <searchInclude value="Account.patient"/>

Ardon Toonstra (Nov 04 2019 at 15:48):

I noticed that public test servers behave differently:

HAPI does something like this: <searchInclude value="Specimen:collector"/>
VONK does: <searchInclude value="Specimen.collector" />
For some reason, I can’t collect the CS of Grahame’s server.

Ardon Toonstra (Nov 04 2019 at 15:51):

Maybe its not the path but the resource type followed by the search parameter name. The CS resource is not really precise on what's expected here

Grahame Grieve (Nov 04 2019 at 19:23):

what you would put there is what the client is allowed to put in the _include statement when searching on that resource type

Eric Haas (Nov 04 2019 at 23:30):

see US Cores's CapStatement for an example of how this is done.

Eduard de Rijcke (Nov 05 2019 at 11:03):

Thank you. For now it's clear what to do at the CapabilityStatements with the US Core's CapStatement example.

At the CS of Grahame's server (R3 & R4) the is no examples of <searchInclude value="....."/>. We have only found _includes in the search parameter <searchParam> it self but I think this is not the same as a searchInclude, isn't it?

Michele Mottini (Nov 05 2019 at 13:33):

GF#25175

Paul Church (Nov 05 2019 at 15:06):

Where's the spec language that says it should be [resource]:[search params]? The [resource].[search params] format is the only one I've ever seen, so we implemented that.

Eduard de Rijcke (Nov 05 2019 at 15:17):

Parameter values for both _include and _revinclude have three parts, separated by a : character

Source: https://hl7.org/fhir/STU3/Search.html#include

Paul Church (Nov 05 2019 at 15:26):

I don't think it's self-evident that that implies what the capability statement should look like. It describes a parameter of the form a:b:c.

To be clear I agree that the proposed change is good, I just think it needs additional language in the definition of the capability statement to define the form of resource.searchInclude/searchRevInclude.

Eric Haas (Nov 05 2019 at 17:40):

I agree and recommend logging a tracker

Last updated: Apr 12 2022 at 19:14 UTC

Main menu

FHIR Chat · CapabilityStatement > Custom Search Parameter · implementers