Stream: implementers
Topic: Multi-system return values
Adam Flinton (Jun 15 2021 at 08:09):
I am looking at trying to get a single get request/query return from multiple systems. We have the system to make the same call to many many systems & this question is about aggregating the responses into a single document.
i.e. imagine you had a GP system, an Acute system & a Community care system.
So you want to say "Give me all of Bob's allergies" where the different systems might have differing result (some the same, some different) e.g. GP says penicillin, acute says pen & latex & community care says pen & dust mites.
Is there an obvious/standard structure into which I can place a top level of these systems , under which is the return for the specific query? e.g. /systems/GP/Allergies, /systems/Acute/Allergies, /systems/CommunityCare/Allergies etc. We are looking to target V4 & looking at the docs I can't quite see an obvious candidate.
Ah the joy of cleaning up after years of disconnected working & record taking......
Grahame Grieve (Jun 15 2021 at 08:31):
a top level of these systems
I don't know what this means
Adam Flinton (Jun 15 2021 at 09:11):
Imagine I am wanting to return an allergies list from each clinical system where a clinical system = "GP System" & handles GP'es making GP records vs Hospital System, and hospital records etc.,etc.
Our "Fhir Facade" can ask each of our clinical systems the same question & then would look to aggregate the individual (e.g. allergies) FHIR responses into a single document where each response is represented as a child of the system which returned it.
So you would see something like:
<DocRoot>
<ClincialSystems>
<ClincialSystem name="GP">
Individual FHIR Query response structure e.g. list of allergies
</ClincialSystem>
<ClincialSystem name="Acute">
Individual FHIR Query response structure e.g. list of allergies
</ClincialSystem>
<ClincialSystem name="CommunityCare">
Individual FHIR Query response structure e.g. list of allergies
</ClincialSystem>
</ClincialSystems>
</DocRoot>
The rationale is that we need to know where (which clinical system) each query return came from and will allow clinicians to note where there are differences between the responses from other systems e.g. the GP may not be aware of the Community Care dust mite allergy or the Acute Latex Allergy & thus may want to take appropriate actions to rectify differences.
Adam Flinton (Jun 15 2021 at 09:39):
Ah just found : "Grahame Grieve - One FHIR Facade for Multiple Servers | DevDays November 2020 Virtual" on youtube . Hopefully the answer is in there.
Adam Flinton (Jun 15 2021 at 10:10):
Some other points.
(1) Interesting vid as it has raised the problems we have ID'ed so that's a useful second opinion.
(2) At this stage we are looking to have an ephemeral facade i.e. the end systems own their data & we are simply an aggregation service so we ask the end servers every time.
(3) We keep data effectively for ever (long after a patient has died)
(4) We need to split by clinical System because we feel de-duplicating is dangerous so we would rather show duplicate data than erroneously remove duplicates
(5) Given the age of our records and the variety of different systems we will have different codesystems/taxonomies and I have too many scars from taxonomic mismatching to wish to do some sort of taxonomic normalisation (e.g. everything to snomed).
(6) We are instituting a common JWT with common RBAC etc codes wrt human fertility, sexual & mental health etc & the end servers are responsible for what they pass back on that basis. No records found due to those reasons is acceptable.
(7) Part of the reason for splitting by clinical system is to allow for if a system has not responded, this can be made clear to the client.
(8) The Facade has no capabilities of its own and as such each server has a capability statement which our facade queries periodically to build up a aggregated capability statement which allows us to route queries to servers with that declared capability.
Michele Mottini (Jun 15 2021 at 12:50):
A FHIR server can return only a flat list of resources in response to a search request, so it has to return either (1) all the allergies as they are recorded in the different systems or (2) some kind of consolidated list if the facade is able to de-duplicate or combine data coming from different systems. In case (1) you can use Provenance to represent where the data came from
Yunwei Wang (Jun 15 2021 at 13:42):
If they come from different systems, then they should have different base url
Grahame Grieve (Jun 15 2021 at 21:31):
The rationale is that we need to know where (which clinical system) each query return came from and will allow clinicians to note where there are differences between the responses from other systems e.g. the GP may not be aware of the Community Care dust mite allergy or the Acute Latex Allergy & thus may want to take appropriate actions to rectify differences.
I understand that, and agree about the challenges with matching: an unresolvable problem without significant clinical efforts that are unlikely to pay off at the moment. You effectively have three choices:
#1 use Resource.meta.source to indicate the source system, and require source systems to expose the source when displaying the results of a search
#2 think of this as a document, prepared by a server, with a Composition resource doing your structuring as you show, Define a document format profile, and use the standard operation to generate a patient document on request
#3 define your own custom operation
My recommendation would be #2. I think you're not thinking about a 'facade' in the sense that's a FHIR API that's a facade on multiple APIs; you want a server that does more than that.
Adam Flinton (Jun 16 2021 at 13:37):
thanks
Adam Flinton (Jun 16 2021 at 14:35):
& yes it does / will do more than that. This is the stage 1 foot in the door exploration of the possible/ the best way.
Last updated: Apr 12 2022 at 19:14 UTC
