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.