Building scalable healthcare integrations with FHIR and Serverless functions

Published in

Lifen.Engineering

4 min readOct 6, 2020

Lifen has built an AI-powered solution to streamline the exchange of medical documents between hospitals, private practitioners, and patients.

With more and more use cases handled inside french hospitals, we plugged our system inside a lot of EHR solutions, to receive data to our platform.

But with a constantly growing volume of data and new logics to handle every week, the need to protect our API from saturation arose.

We had to isolate the ability to receive high-volume, burst-y raw messages, from the process of transforming and mapping them to FHIR with an asynchronous queue system.

This is one of the goals of an integration engine or Enterprise Application Interface (EAI) i.e a middleware installed inside every health system which is used to integrate data between several applications.

Many proprietary and open projects provide EAI solutions. Yet as a startup, the buy versus build decision is not obvious :

we don’t have a clue about the number of integrations we’ll need
they’re often made with old languages & technologies
they can be hard to deploy & maintain
they may not be compatible with the french profiles & standards and are often hardly customizable (for example we have some NLP and AI processing, difficult to integrate inside standard EAI solutions).

So, when the time to integrate our first hospital system came, we decided to start with some homemade logic and plug this logic to a simple queue service architecture.

As we already had created a powerful platform based on a FHIR server for our initial product, we decided to build on homemade cloud-based EAI on top of FHIR. Our implementation consists of three main components:

Serverless functions to implement the business logic
The “Device” resource to represent an instance of external software.
An event messaging system to connect everything together with a scalable architecture.

Step by step, we added existing libraries to handle HL7 V2, MLLP protocols, and other dinosaur formats widely spread inside health systems. But with more than a hundred hospital systems connected today, the need for automation, monitoring, and structuration of our connectors became urging.

The magic of serverless functions (aka Lambdas)

Conventionally, serverless functions are single-purpose, programmatic functions that are hosted on managed infrastructure. With the lack of certified infrastructure in France, we built our own serverless framework on NodeJs language. Each time a FHIR resource is created or updated, an event is sent to trigger the execution of lambda functions. They may capture, transform, filter, or send messages to other applications.

Easy to build: the particularity of healthcare system integration is the number of functional differences between each system. With this kind of code, it’s easy to adapt one lambda for a custom transformation and deploy it in a couple of seconds.

Hospitals can send thousands and thousands of HL7 V2 messages. It’s almost impossible to handle them synchronously. We use our FHIR server as a buffering storage storing raw messages. Our event messaging system built around our server enables us to start the process when and only when the system is available.

It allows us to keep messages in correct order and ensure accurate delivery. In case our server is busy, a retry is automatically handled by our event messaging system.

One benefit of serverless functions is that they are made to scale. Each function is entirely autonomous and stateless. With a good alerting solution, it’s easy to detect when a lambda begins to struggle and deploy more instances.

With 30% growth each month, the number of messages received by day increases dramatically. Our system may scale without crushing our FHIR Server.

How to map objects with FHIR ?

We used the Device resource to represent a connector to a software within a hospital and its parameters. We configure the source and destination format, the protocol and network settings. We also define filters and treatments needed.

For example, we have a Device to integrate a document inside an EHR with HL7 MDM format through an SFTP channel :

We are sending (with a Communication) a DocumentReference with a Device as a recipient
A lambda function (represented by a circle) is triggered which is transforming the FHIR object to an HL7 MDM message.
Another lambda takes this HL7 message and writes the file in a SFTP file.

Workflow to send an HL7 message to an EHR

Example of a Device used to send HL7 messages to an EHR

We now have plenty of devices, another example is a type of Device dedicated to the capture of HL7 V2 ADT (Admit, transfer, discharge notification) :

Workflow to receive an HL7 message from an EHR

First, a lambda function is listening to the socket and creates a raw message in our server (Binary and MessageHeader).
Then, another lambda is triggered to extract information from this message, map it to FHIR and create resources in the server.
Once the processing is complete, the status of the MessageHeader is updated and an acknowledgment is sent to the data provider.

Today, we are still at the beginning of this adventure. Yet, we can already feel the power of this architecture and we’d love to hear from you if you want to share your experiments on this subject.

Thanks to our Connectors team for their daily investment ! (😍 an all-woman’s dev team at Lifen : Aurélie, Claire, Florence, Patrycja and Sonia )

Others related resources :

Building scalable healthcare integrations with FHIR and Serverless functions

The magic of serverless functions (aka Lambdas)

How to map objects with FHIR ?

Written by Julie Dumons