Middleware / Integration Engine Use in FHIR

Moving into the FHIR Implementation space, coming from many years of HL7 v2 implementation and development. Coming from a v2 background where it is common to manipulate messages in an integration engine, are similarly there recommended or industry standards to address gaps between FHIR Servers?

A few examples:

  1. If I have vendor FHIR client that needs to query another vendor’s FHIR server at my hospital organization but there is some data gap such as the vendor being queried doesn’t support a necessary resource, is it reasonable to create a FHIR separate FHIR server with limited scope to retrieve things like PatientID from the vendor’s FHIR server and then perform direct database queries to retrieve the required data not supported by the vendor and return it all to the requestor?

  2. I have a vendor that executes a FHIR query and expects a bundle return. However, the responding vendor doesn’t support bundles. Would it be reasonable to write a middleware layer to query each individual resource and compile them into a bundle and return them to the requestor?

My overall question is what is the role of middleware / integration engine layers in FHIR, and are there any good resources out there on how to properly get stated and build something that in line with industry standards or further reading on how to solve these types of problems in the correct manner?

Yes it’s common to find middleware for the same kind of purposes as classic health data exchange, though the reasons tend to have more to do with business and security decisions that technical wrangling about the details of the implementations

Excellent! Are these types of middleware typically done with standard integration engines that support FHIR or writing custom stand alone translators using libraries such as HAPI?

a mix -those two options, or roll your own js or ruby code or whatever; web integration work tends to be more dev orientated and there’s a huge set of open source tools to lean on

You’ll find engines most useful where integration needs span multiple workflows mixing and matching communication and/or messaging standards requiring normalization. One off focused FHIR interfaces don’t require engines. 90% or more of all current healthcare interfaces are still using HL7 2.x and it will be many years before the provider space moves away from it. If you are integrating with multiple partners having various messaging needs, engines are still the way to go.