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?
- 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.