So, I guess I’m here to continue the tradition of post-conference architectural proposals, but I’m going to try to keep things relatively modest.
At the conference, there was a lot of talk and excitement about FHIR and microservices (and, of course, many other exciting things, but I’m focusing on FHIR). I’d like to propose a way forward to attempt to move from conceiving of FHIR as a module written against core to conceiving of it as a transitional step towards a microservice style architecture.
Importantly, I think, we should be thinking of microservices as a goal of an evolution process rather than a completely new kind of app. A great article, that’s similar to the lines I’m thinking along can be found here, and discusses a practical approach to breaking apart a monolithic application.
All that said, concretely what I’m proposing is that instead of putting all of our effort into developing a FHIR module, we look at building a FHIR service that’s responsible for translating our core data frame into FHIR resources.
What I’m thinking of looks something like this:
The main idea is to provide a basis for eventually enabling us to drop the OpenMRS platform and instead focus OpenMRS development on the parts necessary for making an EHR, while still giving implementers an out-of-the-box deployment solution.
I’m proposing this to solicit some feedback on the overall design. I’ve done some more thinking about how this might be implemented at a more technical level, which I’m happy to discuss, but I want to keep this initial post down to a sane size.