The Future of OpenMRS on FHIR

Development
,
1

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:

OpenMRS%20FHIR%20Architecture

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.

5 Likes
2

Do you mean creating a number of different microservices and using FHIR to interoperate between them?

Do you mind explaining what you mean by this?

3

@jdick @burke @isaacholeman

@ibacher - to clarify - this is a proposal on an intermediate step to be able to run OpenMRS (UX/biz logic) one day entirely onto of an out of box FHIR server like hapi?

1 Like
4

@gschmidt Yes, that’s the idea.

1 Like
5

@dkayiwa a number of different micro services might be a long term goal. For right now, the proposal is simply to have the FHIR resources running in parallel with the OpenMRS platform.

On the second point, I probably should’ve been a bit more quiet. As I understand it @burke’s long-term strategy is to try to simplify OpenMRS so that we can store the data in a standardised representation (which FHIR might serve as) and refocus the purpose of OpenMRS as providing the layers necessary for that data to be used in an EMR.

A slightly shorter term version of this is to extract the domain model from core so that both the platform and the FHIR service can use the same domain representation.

6

I thought you wanted to mean FHIR resources running on the OpenMRS platform. Possibly a difference of opinion in regards to what the OpenMRS platform is. :smile:

I find FHIR cool for data exchange (and that is what it was designed for), but too denormalised to be an efficient storage access format, for our use case, which requires enforcing referential integrity, and other things. Though i would not be against evaluating a hybrid approach of storing some FHIR resources natively and others differently, according to the different requirements. :slight_smile:

7

@dkayiwa When I say “OpenMRS platform” I mostly mean OpenMRS core. And I’m not necessarily advocating using FHIR as the data store per se. Only using FHIR as an opportunity to explore something more like a microservices architecture.

8

I discussed this with @ibacher at the conference and I’m definitely a fan of pursuing this approach with the FHIR service being it’s own entity instead of an OpenMRS module, with the caveat of that if it starts to become a blocker to getting new/better FHIR support out in a timely manner we may want to reconsider.

As you move forward, I’m interested in hearing more about the details and how the reverse proxy and the stand-alone elastic search work.

Take care, Mark

9

I do not yet see our FHIR implementation stable enough to move out of a module. We are still iterating over it at such a rate that the practical advantages of it being in a module greatly outweigh the alternative.

10

@dkayiwa I don’t really understand that last argument. Why should our FHIR implementation be “stable enough” to happen somewhere else rather than in the current module?

11

Possibly i did not use the appropriate wording. :smile:

What i mean is that it is still under active development which needs a vehicle that provides more flexible releases like that of modules.

12

Also, for a litte context: I’m not too familiar with the FHIR module (or FHIR itself) but at OMRS19 there was talk of the need to create a new FHIR module because the existing one was lacking/outdated. It’s within that context that these discussions are taking place: if we are going to rewrite the FHIR module, does it make sense to take a microservice approach when doing so? I think this is this worth exploring, because I think having a FHIR service that could interact with the OpenMRS data model without the overhead of the full OpenMRS Core could be very advantageous. That being said, if this leads to a significantly more complex FHIR “module” that takes longer to develop/deploy/iterate/release we should consider just sticking with a “regular” module for now.

I think @ibacher is beginning to explore the possibilities of what this would take, and I’m excited to see this moving forward.

As to the need to rewrite the FHIR module in the first place, I can’t weigh in intelligently on that as I don’t have much experience with, but there seemed to be some consensus around that at the conference. Perhaps someone with more knowledge of the discussions can add more detail?

Take care, Mark

13

So I’ve got a bit of a strategy here. I think the consensus among the people who have looked at the FHIR module is that it would be a good idea to replace it, at least for the minimal functionality that we require for, e.g., the UW requirements and the micro-frontend stuff. The limitations of the current FHIR module are:

  1. It’s substantially more complicated than it needs to be, and this means we are wasting developer time trying to figure out where to correctly plugin to the current module.
  2. The mappings in the current FHIR module are, in many cases, deeply questionable and semantically incorrect for the FHIR spec (even the version it is supposedly developed against). This means that there’s a great deal of manual review necessary to get the FHIR module up to snuff.
  3. We would like to be implementing FHIR R4, since this is the first version of the FHIR spec with normative content (that is, resource description that we can assume are stable). Currently the FHIR module implements DSTU3, for which many resources are similar.
  4. We need to have a better defined target for which versions of core the FHIR module will support. The current version is quasi-targeted 1.9 or greater, with the caveat that 1.9 is built on Java 6 and parts of the core module use features from Java 8.

I’m with @dkayiwa in this: the timeline for getting some fully-developed FHIR functionality does require we work on a module for now while in parallel trying to devise the framework which I’ve outlined in the first post. To that end, I’ve started up a new module with, I hope, a simpler architecture. That module can be found here: https://github.com/ibacher/openmrs-module-fhir2. Today, I think the FHIR squad will be discussing whether we continue with the current module or leverage the new module. I’ve designed the new module with some principles in mind that should make it possible to extract the core functionality (mapping between OpenMRS data types and FHIR resources) into the future architecture I’ve proposed in the first post.

(Also, if the FHIR squad determines that the FHIR2 module is the way forward for our effort there, I’d be looking to move it under the OpenMRS umbrella. I just put it somewhere I could do so easily for now).

1 Like
14

@ibacher - nice work! This is a great start to the module and I picked up some nice new tips about using annotations with Spring that I hadn’t used before - thanks for that. I think this is a great start and I appreciate you taking the initiative to get this new module rolling. I’d definitely advocate for moving it under the openmrs org.

Best, Mike

15

Appreciate your digging in here very much.

A couple of quick community governance questions as it relates to this module:

  1. We are talking about replacing a module that we currently bundle in our releases. What is the process for deciding as a community that we are going to replace it (with the good work you’ve seemingly started?)

  2. Grafting from OpenMRS object attributes to FHIR resources is some science, but is mostly “art” and left up to interpretation. Who will have accountability for signing off on this mapping activity and what background will we expect of him/her/them? :slight_smile:

Again, really appreciate you pushing on this.

16

Hi Paul,

Thanks for the great questions! I’m not sure I’m necessarily the person to answer them completely, but I’ll give them my best shot.

The new module was the outcome of discussions within the FHIR squad and a number of other stakeholders within the community at the recent conference. We, as the FHIR squad, are still evaluating whether or not this is the way we want to move forward. A key part of this decision-making, however, has been the complete inability to locate anyone in the community actually making use of the current FHIR module.

This is the part I feel unqualified to answer. It’s actually a broader question than just what this post was intended to discuss (an architectural sketch) and affects the FHIR squad whatever way forward we take. @ccwhite23 @janflowers @jdick Do any of you have any input on this?

17

Paul, to follow up on Ian’s comments

For #1, would defer to who’s ever managing releases. Based on our experience to date, I’d be a little shocked (and concerned) if anyone was actually using the current fhir module in production. Fhir2 will be using R4 so technically it’s a different api than the fhir1. I don’t think it would be incorrect to include both in a release such that a distro could have the option of using either api (despite my caveats mentioned above).

For #2, there isn’t a clear answer to this other than, “Burke, can you please tell us if this is right”. For now, that’s basically the process for establishing mappings. We’d love get a more robust process going. Would appreciate any further guidance on that.

18

Maybe as @ibacher (or others) pull together a proposed model for each resource, we could start a specific topic in the “FHIR” category on Talk for that resource so we can all weigh in as necessary?

(Tangentially, one thing that @ibacher mentioned on the call today that he didn’t mention here is that in his new module it should be easier for for implementations to override and/or provide special translations for resources if they are modelling something in a “nonstandard” way).

Ian, thanks again for taking all this on!

Take care, Mark