Questionnaire response - search criteria questionnaire missing?

[ellgre]

We are using questionnaire and questionnaireResponse and are linking them based on the field questionnaire on the questionnaireResponce document. We would like to use questionnaire as search parameter as defined in FHIR in order to find all responses linked to a given questionnaire, but cannot find it as a search parameter in the capability statement.

Do you have any plans to add questionnaire as search parameter for questionnaireResponse?

[brendankowitz]

Hi @ellgre. Yes, this is related to #1566, though its not currently prioritized

[ellgre]

We have the following use case:

• We have a questionnaire that we use for terms of service which our users must respond to with questionnaireresponse in order to use our services.
• The questionnarieresponse is linked to the questionnaire through a versioned reference.
• The terms of service are revised regularly by creating a new version of the questionnaire.
• In order to make sure that all users have agreed to the new terms of service we need to find all questionnaireresponses linked to the old version and inform them.

We hoped to achieve this by using the search parameter for questionnaire.
Is there any other way we can achieve this without having a search parameter for questionnaire?

I just noticed that the link to questionnaire is a canonical and not a reference as we thought. Do you know why reference is not used in this case? Normally other FHIR resources are linked to by using references.

[giacomodeliberali]

Hi @brendankowitz , any update on this? We are facing the same issue

[CaitlinV39]

@giacomodeliberali We still don't have an ETA for when we would support this in the FHIR server. Is your scenario the same around questionnaire response?

[giacomodeliberali]

Yes same scenario

[holpit]

Hi,
some news about this topic?

[CaitlinV39]

@holpit this isn't prioritized on our backlog now.

[holpit]

Please rethink this priority.
There is no way for just a simple use case as searching for QuestionnaireResponses to a Questionnaire by reference. I think it is the minimum acceptable.
Thank you

[almostchristian]

I've implemented this in my own fork of the fhir server by adding a CanonicalToReferenceSearchValueConverter which would have a similar code to UriToReferenceSearchValueConverter. Not sure if it's correct for all cases, but we are able to search QuestionnaireResponses by the questionnaire search parameter with no issue. It also had the effect of shrinking the unsupported search parameters list to 4 (for R4)

Basically looks like this:

public class CanonicalToReferenceSearchValueConverter : FhirTypedElementToSearchValueConverter<ReferenceSearchValue>
{
}

[Maciejszuchta]

Any news on that?

[CaitlinV39]

@Maciejszuchta this is still on our backlog but no update on the ETA for support.

[CaitlinV39]

AB#76717

[holpit]

Hi,
I must come back on this issue because I 've seen the in the last version is not yet implemented. One year is elapsed.

How do you guess to find a QuestionnaireResponse without the possibilty to search by this reference?
The simplest use case is not supported:

1. Create a Questionnaire - OK
2. Fill the responses - OK
3. Find your QuestionnaireResponse to Questionnaire - FAIL !

[KMCGit]

Is there any update as to an ETA on support for the "questionnaire" Search Parameter for /QuestionnaireResponse?

[brendankowitz]

The closest workaround until this is done would be to use a custom search parameter with a different name and typed as Uri, e.g.

PUT https://{{hostname}}/SearchParameter/QuestionnaireResponse-questionnaireUri
content-type: application/json

{
    "resourceType": "SearchParameter",
    "id": "QuestionnaireResponse-questionnaireUri",
    "extension": [
        {
            "url": "http://hl7.org/fhir/StructureDefinition/structuredefinition-standards-status",
            "valueCode": "trial-use"
        }
    ],
    "url": "http://hl7.org/fhir/SearchParameter/QuestionnaireResponse-questionnaireUri",
    "version": "4.0.1",
    "name": "questionnaireUri",
    "status": "draft",
    "experimental": false,
    "date": "2019-11-01T09:29:23+11:00",
    "publisher": "Health Level Seven International (FHIR Infrastructure)",
    "description": "Questionnaire linked to a QuestionnaireResponse",
    "code": "questionnaireUri",
    "base": [
        "QuestionnaireResponse"
    ],
    "type": "uri",
    "expression": "QuestionnaireResponse.questionnaire",
    "xpathUsage": "normal"
}

This will allow you to search:
/QuestionnaireResponse?questionnaireUri=abc

[KMCGit]

Thanks for the work-around. I was able to get that operational and was extremely helpful. I wanted to ask if there was any possible way to remove the search parameter occupying the "questionnaire" key on /QuestionnaireResponse, so that "questionnaire" could be used as the key with the above work-around?

(I have tried to DELETE the parameter with ID QuestionnaireResponse-questionnaire and key "questionnaire", I have also tried to send PUT request to adjust it, but to no avail currently)

Thanks for your time and greatly appreciate your guidance so far. Have a great day.

[Monzingo89]

I think its been a while and this bug is rather important for SDA, linking questionnaire to questionnaire response shouldn't require a workaround, can we prioritize this higher? Its in the spec but not implemented.

[LordTony]

It's been about 4 years since this ticket was opened. This is a pretty big deal. Without being able to link QuestionnaireResponses to the Questionnaire they came from both Questionnaires AND QuestionnaireResponses are near useless. At least post the steps to let us hack it all in ourselves like @brendankowitz has shown us part of. The problem with his solution is that the Azrue FHIR Server/Service doesn't respect the version number of the questionnaire when searching with that SearchParameter. Also _include and _revinclude don't work with it so I'm having to make several calls when really a basic include/revinclude on a canonical should be all it takes. Please at least post the workaround steps here to get the database working with includes/revincludes and searches that all take the versionId of the Questionnaire into account.