Adding searchable metadata to be able to group related resources

1

I am wondering which parts of our application logic can be modelled within FHIR and for which we need to fall back to non-FHIR API calls to make happen. Specifically, if I wanted to make it possible to say that questionnaires could have a “collection id” or some label, I am sure I could employ the extensions mechanism (and Profile? Too fresh to know) to add such a field, but would I then be able to search for such a generic field later on? Another example could be that I would like to find all questionnaires related to a given encounter, not just a specific patient.

I see that every Resource has a section called Search Parameters that lists which parameters are available for search, and I assume this is done to be able to effectively employ indices in searches. Not sure if this prevents adding additional fields in some local implementation, but adding custom fields might prevent interoperability or some other issue, I assume (?).

I was wondering if such queries are meant to be served by the _query parameter of the Advanced Search?

Typical queries I could think of from our business domain

  • Find all questionnaires for an encounter that are due to be filled out by a patient
  • Find all questionnaire of type X for encounter Y, where X is some business id, as each of these questionnaires might be structurally similar (derived from a template questionnaire), but with different pre-filled values

Other parameters might be stuff that is application specific and not known as FHIR resources, which makes me think some /non-fhir/specific-query might return just a list of FHIR entity ids.

2

You can define custom SearchParameter instances to search on elements (or element combinations) not supported in the core spec, including searching on extensions. So yes, that bit is possible.

Encounter is already a standard element on QuestionnaireResponse and a standard search parameter. (The Questionnaire itself is not specific to patient or encounter.)

The set of SearchParameters defined for a resource are those deemed ‘commonly supported’. For systems build to support FHIR from scratch, you’ll typically find support for all of them (though not always). For systems with a legacy repository, support for search parameters may vary. Implementation guides can define CapabilityStatements that set expectations about which resources and search parameters need to be supported (including, potentially, brand new search parameters not defined in the core spec)

_query is typically used for things that can’t easily be managed through simple search functions. E.g. “Find me all patients whose blood pressure has been at least 10% above average in the past year” is not the sort of thing you can easily do with just REST parameters, but which could be done with _query.

“Due to be filled out” is typically represented by a Task. So I’d say:
[base]/Task?status=requested,received,accepted,ready,in-progress,on-hold&code=http://hl7.org/fhir/uv/sdc/CodeSystem/temp|questionnaire
You could theoretically filter by Task.period as well

For the second, there’s a derivedFrom element that allows you to say one Questionnaire is derived from another, but it looks like there’s no standard SearchParameter to filter by that as yet. For R4, you’ll have to define your own. However, please submit a change request (using the ‘propose a change’) link at the bottom of the spec to ask for this to be added to R5. (There’s a 1-time free manually reviewed registration process, after which you can provide feedback at will.)

If you ever find yourself thinking “I need to do X and I can’t see a way to do it using the FHIR core spec or any relevant implementation guides”, the best thing to do is to ask a question on the http://chat.fhir.org Implementers stream. If there’s a standard way to do the thing you’re wanting to do, someone there should be able to tell you. And if not, they’ll also be able to recommend the best ‘non-standard’ way to do it (and maybe recommend proposing a change to introduce the feature into the standard).

1 Like