Stream: implementers
Topic: Use CapabilityStatement for searching on referenced resouces
Jaime Olivares (Jun 26 2018 at 23:18):
We are writing a platform that supports any kind of FHIR resources and treat them in a generic way. We can show lists of any kind of resource. For those lists, we want to create a 'Filter' option.
By processing the CapabilityStatement (/metadata), we can get a list of 'searchParam's as well a list of 'searchInclude's. Some search parameters can be used for showing as fields in the Filter Fields, when they are of type token
, string
or date
. Then those param names and values can be added to the search URL.
The difficulty comes when we want to go beyond the resource scope, let say the 'performer' entry in ProcedureRequest's searchParam, matching the 'ProcedureRequest.performer' as present in the searchInclude list. There is no information in the CapabilityStatement about the type of that reference (Practitioner | Organization | Patient | Device | RelatedPerson | HealthcareService, according to the FHIR spec), so we cannot offer a list of fields for those nested fields.
Moreover, it is not suggested that 'performer' is associated to 'ProcedureRequest.performer', in order to automatically include it in the URL when that filter is selected. We just infer that from the specification website.
It seems there is missing a 'referenceType' attribute for each search parameter with type 'reference' as a single string or an array of strings, as well as an 'include' attribute for mentioning the associated searchInclude, like:
{ "type": "ProcedureRequest", "searchParam": [ { "name": "performer", "definition": "http://hl7.org/etc…", "type": "reference", "documentation": "Requested performer", /* Suggested attributes */ "referenceType": [ "Practitioner", "Organization", "Patient", "Device", "RelatedPerson", "HealthcareService" ], "include": "ProcedureRequest:performer" } ] }
Is that something we can suggest to be added to the standard?
Our intent is to make CapabilityStatement more digestible by applications rather than the human eye.
@Grahame Grieve @Christiaan Knaap
Grahame Grieve (Jun 27 2018 at 04:13):
we used to have this, but stripped it out. The search parameter now only contains name, definition, type, and a reference to a full set of information in a search parameter resource
Grahame Grieve (Jun 27 2018 at 04:13):
where everything you can think of can be found
Jaime Olivares (Jun 27 2018 at 14:15):
and a reference to a full set of information in a search parameter resource where everything you can think of can be found
Are you talking about the URL in "definition" ?
If that's the case. That URL usually points to a verbose html document, which an application cannot parse.
Alexander Zautke (Jun 27 2018 at 17:44):
Based on this URL, you can look up all search parameters in the search-parameters.json / .xml which is provided in the FHIR Definitions .zip. See https://www.hl7.org/fhir/downloads.html
Jaime Olivares (Jun 28 2018 at 13:25):
Thanks @Alexander Zautke, although not automatable with such degree of dispersion, we can compile our own SearchParams.json file.
Brian Postlethwaite (Jul 04 2018 at 06:43):
You could ask the server for the search parameter by the URL in the definition. As might be a custom one, not one from the standard.
Last updated: Apr 12 2022 at 19:14 UTC