FHIR service as a service

After two years of building and improving our FHIR server, we are now slowly entering the phase where we as a company start asking the question how an actual implementation of a FHIR server will look.

Will it just be a REST interface on top of a Hospital Information System, like EPIC or will it survive as a stand alone server where all other systems can safely store and retrieve data? (I must say resources of course). Will it be just a slave to other systems or does it serve a purpose on its own? Will people always want to implement all the endpoints we created? Is there eventually a need for a general purpose FHIR server like we made, or is it sufficient to create a server that only understands a specific (Profiled) situation?

These are not questions with A-or-B answer. It will be both or either depending on where and when. And many of these questions have been asked and answered by everyone building this standard.

But we had to premeditate some answers while making this server. And as a result one choice we made is accepting that our FHIR server is not an application. It can be. But it doesn’t have to be. And thus we are now transforming it into a module. A module that preferably is plug-and-play. Or as plug-and-play as possible.

Although the work is far from finished, our precious Spark FHIR Server application is now little more than a single REST controller. Everything that happens before (routing and deserialization) and after (validation, storage, retrieval, and indexing) is no longer. That’s now just a library.

It allows us to create more varieties: an open test server, a secure server, a specific implementation. A REST endpoint that is just an interface to another system.

And all that we are left with now is little dilemma’s like – is our test server called Spark? Or is it the actual module – or library – or what is this thing now? Oh yeah, and of course that huge pile of refactoring that still in the backlog.

1 thought

  1. I would love the see the FHIR spark server as a stand alone communication server in the health IT clinical network where all other systems can safely store and retrieve data. The FHIR server should be a prominent part in a medical IT network communicating live through a vendor neutral gateway with the network of connected medical devices and systems at the point of care. The FHIR server should be a reliable test and verification source when communicating through IHE ITI profiles, as already exercised with the PDQm, IUA and MHD ITI profiles. More IHE profiles of other domains should take up the proposed FHIR standard, e.g. the IHE domains PCD, RAD and LAB, DICOM systems should have a standardized FHIR interface to store DICOM data and resources in the FHIR server. The FHIR server should become an integral part of the IHE connectathons.proving the interoperability of connected systems and networks with medical devices at the point of care. Time for implementing FHIR as a service has come. :-). Thank you for all your effort and passion. Uwe @ MT2IT

Post a comment

Your email address will not be published. Required fields are marked *

Want to stay on top of Interoperability and Health IT? 

Subscribe to our newsletter for the latest news on FHIR.