Stream: implementers
Topic: Aggregating multiple services behind a FHIR interface
Bart Dutkowski (Oct 12 2021 at 23:00):
Hi, I'm looking to sanity check our proposed solution to a problem I would image is quite common in this space. We are looking at creating a single FHIR interface that will aggregate multiple distributed non-FHIR databases. The databases are hosted in different locations and have different schemas. So we are proposing to use an agent, co-located with each database to fulfill the read and write requests. The FHIR requests will be accepted at the interface and forwarded along to each respective agent using an event bus and the agents will be partitioned by an organization identifier that will have to be used on the request. The agents will be responsible for translating the fhir request to their respective database schemas. My first question is, is this a common enough problem that there is some best practice guidance available? Secondly, that would be a good format to serialize the FHIR requests to, or is there any downside to leaving them as raw http requests?
Grahame Grieve (Oct 12 2021 at 23:24):
there's previous discussion here. I don't think we've published anything, but your issues are all around identity management and mixed security models, nothing to do with format
Daniel Venton (Oct 13 2021 at 12:10):
My company has the same scenario. For the most part I don't think FHIR is in a position to say anything about how you handle internal data gathering. FHIR defines the interface on your outer edge. How the API works and how the data is formatted/coded. All the gyrations that you have to go through to get the data to the edge is outside of FHIR scope.
Personally I think the sooner you can get the data into FHIR format the better you'll be long term. i.e. the owner of the data translates the internal schema format into FHIR compliant resources. Otherwise when you are 2-3 levels removed you start asking questions like, "I think this value is supposed to be category, but I don't know what 'A' is supposed to represent."
John Silva (Oct 13 2021 at 12:28):
@Bart Dutkowski - Firely's FHIR server has the ability to add plug-ins that could perform this type of facade to aggregate data from multiple 'back-ends' and present the results as FHIR. https://fire.ly/products/firely-server/
Mike Lohmeier (Oct 13 2021 at 13:29):
AWS FHIR Works has a Persistence interface that you can implement to build custom data solutions like this one as well. We looked at doing this but ended up coming to the same conclusion that @Daniel Venton came to in that it's actually just easier to hard migrate the system of record to a FHIR data store. The ability to support FHIR bundles across multiple data stores means you need distributed transactions and with AWS FHIR Works search is done through OpenSearch so you'd have to sync to indexes in OpenSearch or implement your own search interface.
https://github.com/awslabs/fhir-works-on-aws-interface/blob/mainline/src/persistence.ts
Bart Dutkowski (Oct 22 2021 at 03:24):
Hi everyone, thanks for all your input. @Daniel Venton, I agree that it would be best that the source system move to FHIR but unfortunately this is unlikely to happen this decade so we are stuck aggregating and translating the data ourselves. I also totally agree that the interface at the edge of our system would be FHIR, I was just wondering if there were any practical advantages to keeping the internals of the system as FHIR too. One advantage I thought of was that FHIR will likely have better tooling and documentation than any intermediary data format we have, so it would be easier to use FHIR within our system. Our search requirements are quite specific, so we will always be searching withing a single patient context meaning that our indexing requirements are quite limited.
Daniel Venton (Oct 22 2021 at 12:05):
I don't know as it's a practical advantage or not, but it's my belief that every layer of translation is another layer of errors. This 1st layer only transposes 1 attribute, the next layer only transposes 1 attribute...by the time you get to the end it's junk. At least with a common interface between layers you aren't trying to match definitions between data formats it's a->a->a->a all the way through. Yes somebody has to say fhir.a->sql table X col Y but it's pretty simple if you know that then you probably know the reverse.
Last updated: Apr 12 2022 at 19:14 UTC
