Subscribe to our newsletterSubscribe
Implementing a FHIR server can seem intimidating, especially if your current data architecture uses multiple data formats and incorporates legacy systems.
So Firely has come up with a solution that lets a FHIR server work hand-in-hand with your proprietary system. We call this a ‘sidecar’, and it means you can add a FHIR API to your infrastructure without a complicated and expensive integration project. Keep reading to find out all about the exciting possibilities our PubSub Messaging plug-in offers.
It’s a common dilemma. You want to implement FHIR but don’t have the time or resources to run a complete integration project. Day-to-day tasks are taking your full attention, and a total overhaul of your proprietary systems is out of the question.
The good news is – the pressure is off. It’s now possible to implement an off-the-shelf FHIR server right alongside your existing data architecture. Our PubSub Messaging plug-in is the key to using Firely Server as a loosely-coupled sidecar that takes minimal effort to implement, but still feels completely integrated.
A FHIR server in your network normally communicates with the outside world using its HL7 FHIR REST interface, so that apps and other servers can store and retrieve data from its database.
And of course, the FHIR REST interface is designed around requests (“find me the observations for a given patient ID”) and immediate responses (“here are the matching observations”). This is fine for giving an external app or another server exactly the right data when it asks for it, but less useful when the roles are reversed.
When proprietary data gets updated, your FHIR data needs to get updated as well. But by using the FHIR REST interface alone, you can end up continuously requesting resources that haven’t actually changed.
Our PubSub Messaging solves the problem by using an asynchronous subscription model to notify any number of your services of changes to the data in Firely Server – and vice versa.
Instead of continuous syncing, which would impact performance, changes are placed in a message queue to be picked up when the system is ready to process them. When a subscribed server is unavailable, messages are kept until it’s ready to deal with them.
Messaging and reports
You can think of Firely Server as holding a FHIR-based shadow copy of your proprietary data. When a doctor enters fresh or updated data in your system, the PubSub Messaging will make sure Firely Server gets notified and can act on the changes. Any third-party app connected to the FHIR API will be able to get the updated data that have just been entered by the clinician. The same principle also works the other way around. When Firely Server data updates or stores data through its FHIR interface, your own services get notified and can act on the changes, including running analytics. For example, an existing Power BI database can be fed ad hoc changes that support completely up-to-date reports.
Any significant changes to your proprietary data will also reach Firely Server, and anything that happens on the Firely Server REST interface travels in the opposite direction. The two systems become connected like a motorbike and a sidecar. This means that:
- Both systems can be maintained independently
- If one system goes down the other can step in
- Message implementation is smooth and simple
- You get all the power and compliancy of Firely Server, but your existing architecture stays intact
Implementation of the full FHIR REST interface (or Firely Facade) and its requirements is replaced by a simple messaging contract. Firely Server handles all the complexity and operations required by regulations and IGs, and Firely will update Firely Server to keep your interface compliant and reliable, with minimal changes needed to the system on your side.
More about Firely Server
This easy-to-use functionality is another good reason to put Firely on your shortlist when assessing FHIR Servers to buy.