An Amazing Future for OpenMRS - Move Away from Java Backend?

I’ve got a lot of them, especially here, but certainly the move towards representing as much of the OpenMRS data model as we can via FHIR is a goal of the FHIR squad that we are actively working towards and when we get to a point where the data that we need to power OpenMRS can be gathered from a FHIR API, it might make sense to just move (some of) the backing data to a FHIR store.

It’s important to realise, though, that there are limitations to FHIR. It’s not intended as a general purpose data model for EHRs. Some key things will never be possible to completely migrate to FHIR. For instance, representing users and their privileges has routinely be ruled out-of-scope for FHIR. Other things are less mature in FHIR than we might like. For example, there is work being done on representing things like OpenMRS forms (what FHIR calls Questionnaires)—and some of this work is very impressive (there are a number of condition-specific tools that have been built using this, including things like a tool for recommendations around alcohol use and tools for screening for COVID-19), but the standards around this haven’t quite reached the point where they can serve as a general-purpose form tool. Similarly, FHIR itself is a moving target with each new release bringing about at least some major changes. In fact, the most recent release (R4—released a few months after the initial question) is the first release to feature “normative” content, which just means that certain resources have been widely used and are unlikely to change, at least in major ways. But even then, the “normative content” covers only a small part of the FHIR specification, and there are certainly major changes under way for the next releases (R5, the next major version, is currently targetted at Q2 2022; however, there is a quite large update currently called R4B that is expected to be finalised in Q2 2021).

Finally, the reality of it is that while FHIR has seen some great adoption and a wide array of use-cases, it’s still under-used for use-cases that might be expected. For example, the OpenMRS FHIR Squad and I-TECH have worked on what might be the first FHIR-based integration between an EHR and a LIS. Certainly, we had a hard time finding other examples out there. The reality is that current EHR platforms in high-income countries are still relying on pre-existing technologies and while I know both the NHS in the UK and ONC in the USA are pushing FHIR-based solutions, we’re still a bit away from that becoming ubiquitous (and, in the US context in particular, the push towards FHIR is actually a push towards enabling patients to have electronic access to their medical records stored in EHRs).

If I’ve sounded a bit down on FHIR, I’m not really. I think there’s actually exciting opportunities for the global health informatics community to get involved with FHIR and push it in directions to meet the needs and challenges faced with providing health care outside of rich countries. Moreover, I think that FHIR provides a great building-block to enable richer data sharing among electronic health care systems. But it’s certainly not a simple drop-in solution.

9 Likes