FHIR and FHIR2 clash on older Platform versions (2.0-2.3.x)

I have heard a rumor that the FHIR2 module has been conflicting with something. Talking with @alaboso & @eudson we think we have pinpointed it:

  • Platform versions 2.0.0-2.3.x came with the old FHIR module (v1) pre-bundled.
  • FHIR2 wasn’t bundled until Platform 2.4 (Source: Looking through our platform release notes)
  • @alaboso found that adding the new FHIR2 OMOD while using one of these older platform versions conflicted with the bundled v1 FHIR module

This conflict is not too surprising. My questions are:

  1. Won’t we likely see many implementers run into this issue as they try to work with OpenMRS 3 on a Platform versioned 2.0-2.3? I’m wondering if we can prevent that.
  2. Should we provide a patch for Platform 2.1.x, 2.2.x, and 2.3.x?
  3. If so, what’s the actual lift to do that? (1 hr? A week?)

cc @dkayiwa @ibacher @burke @mksrom @mayanja

This is very much a known issue, though it’s probably only been noted on several non-obvious Talk posts.

Short version: hopefully not. I.e., I would hope most implementations were taking advantage of the SDK and the distro.properties file to manage their versions rather than manually building on top of the platform release. This is the model that we use for the RefApp.

More concerning, though, is ensuring things are running with the right version of the FHIR2 module. The FHIR2 module development cycle is a bit faster than the platform development cycle, so, e.g., the Platform 2.4.0 release bundles FHIR2 1.0.0, but O3 realistically probably requires at least FHIR2 1.2.2, i.e., the version running on openmrs-spa.org.

This is a bit of a difficult question. I don’t like releasing patch versions of the platform that have a breaking change. E.g., if we did a full release of, say, platform 2.3.6 with FHIR2, that would break things for anyone using 2.3.x and relying on the FHIR module, because the FHIR2 module is not backwards-compatible with the FHIR module (this is why it’s a separate module). The other alternative is to come up with some kind of tagged release thing so we have, e.g., platform-2.3.6 and platform-2.3.6-fhir2. That’s possible, but is a fair bit of work to setup and maintain (i.e., the CI pipelines need to be modified to handle that). Ultimately, this is why we only ever shipped FHIR2 by default with 2.4.

I outlined two options above. The “simple” thing (e.g., 2.3.6 with breaking changes) is quite low-effort other than verifying that the platform releases “took” and everything ended up where it was supposed to. If things break (those release builds can be finicky), it could take a couple of days to do that many releases, but realistically, its probably a few hours.

The more complex thing involves re-writing the CI plans and that’s probably a couple of hours of work on top of the same level of effort as above.

1 Like

I thought the FHIR2 module was designed as a replacement for the original FHIR module and we weren’t expecting to support both running at the same time.

Perhaps we need to have people running older versions of the platform with the original FHIR module remove that module and install the FHIR2 module.