Stream: implementers
Topic: FHIR facade optimization
Georg Fette (Nov 25 2020 at 08:37):
At our institution we would like to establish a FHIR facade for the whole institution that directly sits on top of the databases of the various primary systems. When I have a constrained query on Observation (e.g. GET [base]/Observation?code=94500-6&_summary=count) I have to query all subsystems that potentially generate Observations and filter the results for those Observations that have the constrained code. When I know beforehand that this code only appears in a specific subsystem, only this system would have to be queried. Is it possible to build a facade that does this pre-selection of queried subsystems with the tools that the FHIR specification offers ?
René Spronk (Nov 25 2020 at 08:45):
FHIR itself doesn't offer any Facade tools, most existing third-party facade tools offer one to develop plug-ins. The decision where to route a query to could easily be such a plugin or some other extension to a Facade toolkit implementation.
Georg Fette (Nov 25 2020 at 08:50):
I am not interested in tools, but in a formalism defined in FHIR itself. It would be useful if there were a way to define, that a certain subsystem only produces resources confirming to specific profiles or that certain constrained codes only belong to specific valuesets. The definition of query routing would then be easier with such a formalism, because the quer could be analysed based on the constrains defined with such "capability statements" of the subsystems.
Grahame Grieve (Nov 25 2020 at 08:58):
there's no formalism other than the URL, and most systems with this set up do one of 2 things:
- a prefix in the resource id that identifies the underlying source system
- a big lookup table on the facade to do the directing.
The first is operationally easier but requires some discipline in approach
Last updated: Apr 12 2022 at 19:14 UTC
