Proposal: Medication Dispense OpenMRS module

After a long delay, I’ve gotten back into working on dispensing and would like to formally put out a proposal to create a new “Medication Dispense” module that would and data model and API functionality for dispensing based around the FHIR Medication Dispense object.

I’ve written up the details of my proposal here:

I’ve highlighted specific questions in the proposal with a ? icon.

@grace @burke can we get some time on an upcoming TAC to discuss?

For historical reference, see this previous thread:

fyi @bistenes @cioan @mseaton @ibacher @mksd

Take care, Mark


Thanks @mogoodrich. Is the need for a module stemming from the same reason as what happened with the Cohort module?

Namely that it can’t be done just in the FHIR2 module because we need to add tables, and we have decided that the FHIR2 module doesn’t do that.

The primary reason for that decision is I’d like to keep the FHIR2 module on par with the REST module. Other modules are free to define their own FHIR resources which the FHIR2 module should load but I don’t think FHIR2 should be adding new tables over and above what’s in the core data model.

@mogoodrich what about a Core 2.6 providing all that you have currently associated with this suggested dispensing module?

I think this was a harder model to follow with cohorts/patient lists, but it feels that here we should try to do it.

@mksd I’d totally be up for considering building this directly into Core (with the FHIR module and/or REST module providing the REST endpoints). The two main considerations on my end would be:

  • Enough consensus on the model to move forward (something we can discuss on a TAC)
  • Whether PIH is in a position to upgrade to 2.6 in the time span we need (something we at PIH can figure out internally… but my gut is this either won’t be a problem or we can figure out some sort of temporary workaround on our side until we are ready to upgrade)

Take care, Mark

My take would be to solely provide the FHIR API for all things touching to medication dispensing. This should limit the difficulties to agree on the underlying data model in OpenMRS, since it would mostly become internal mechanics.

Reviewing the value sets for this module I find a lot of concepts that would have limited use in OpenMRS settings. I’d love to have some input from existing implementers which concepts are actually required. Rwanda, Nigeria and those that have dispensing workflows now.

ie, you mean don’t add a REST API for it? I’m not familiar with the FHIR2 module, but assumedly Core would provide a small, mainly CRUD API that the FHIR2 module would use?

Core would provide the Java API (incl. the DAO layer) and the only web/REST API would be that provided by the FHIR2 module.

This would also be a great example of an exercise showing that we really go FHIR-first.

Agreed. I doubt we’d require any of these concepts to be present in an implementation, we’d rather just support configuring a set of valid values for a field, and recommend that when implementors set up that configuration they stick to concepts that can be mapped to valid FHIR concepts. @ibacher does that sound right to you?

Right, make sense. Though I’ll be noncommital on supporting that until I under what FHIR2 provides in greater detail…

Hi @mogoodrich and @ibacher at UMB we have worked on a similar use case while extending OpenHMIS, see here: GitHub - nmrs-nigeria/nmrs_commodity_app

1 Like

Hi @morrisng , do you have any screenshots or documentations available that you can share?

Thank you,


Comodity Managemnt Module Training Manual.pdf (1.5 MB)

I’ve created the first tickets about adding support for Medication Dispense to Core and to FHIR2. Further requirements for Core/FHIR2 will develop over time as we start to build out the Dispensing UI.

If anyone has any concerns, please let me know!

I also plan to work on ticketing what improvements need to be made to MedicationRequest mapping in FHIR2 in order to support the dispensing functionality.

Take care, Mark

1 Like

@akanter following up on concepts, although I certainly don’t think we will want/need concepts for all the concept fields in FHIR Medication Dispense module, the “status” field is a required field and it seems like we’d want CIEL concepts for it sooner rather than later:

This may warrant a separate discussion/thread, but: is there a strategy for adding FHIR2 code systems to CIEL (or is this already happening)? My quick analysis: seems like it would make sense to add a concept source for each code system, so, for instance, in this case we’d have the following mappings:

Source: FHIR Medication Dispense Status Codes Code: preparation

Source: FHIR Medication Dispense Status Codes Code: in-progress


… and then apply them to existing CIEL concepts or create new CIEL concepts as needed.

I would expect that the logic in Core would not require/expect any of the concepts to be present, it would just define a required field “status” of type “Concept”.

Then, in the FHIR2 module, when transforming this field, it would find for the “Medication Dispense Status Codes” code on the status concept and return that (but also be null-safe so that it would just map status to null if the “Medication Dispense Status Codes” source didn’t exist in the OpenMRS implementation).

The Dispensing UI we build will likely need to support business logic around these concepts, so we’d want to support either/or 1) installing these CIEL concepts when adding the Dispensing UI, or 2) making user implementors have at least applied all the relevant Status Code mappings to concepts currently in their system. This might tie into the OpenMRS Packaging dicussions that I probably haven’t been following as much as I should…

fyi @akanter @ibacher @mseaton @burke

Take care, Mark

1 Like

Thank you so much @mogoodrich :+1:

This is really great stuff .

@ruhanga @wyclif FYI since we will want to leverage the outcome of this work to propagate the dispensing information from our pharmacy system (Odoo then) back to OpenMRS (within Ozone.)

1 Like

@mksd makes sense, thanks for sharing guys.

1 Like

Mark, I think that in cases where the value sets have a source other than HL7, such as SNOMED, we’d include the SNOMED source. In this case, since these do not reference SNOMED (although many may overlap SNOMED) I can see adding as an HL7 source. However, this is not the best way to create value set relationships. I would prefer if we defined the value sets as sets and then built internal references since otherwise it will be hard to scale. @burke we have discussed how we’d start migrating our set structure to be more compliant with the FHIR model. Created a new set 167157 that contains these value set entries (new and old).

Thanks @akanter ! What do you mean by “internal references”?

Within OpenMRS Core, my plan now is that we will just store this as a concept, with no particular restriction based on set membership.

But in the FHIR2 module, when translating from a OpenMRS model to a FHIR model, or vice versa, I’d like the FHIR2 module to have an easy way to determine “this concept should map to Medication Dispense status code ‘preparation’”, and, ideally I’d think we’d be able to do this via simply looking at the concept and it’s mappings, and not having to refer to some other mapping table or global property, etc…

Thoughts @ibacher @mseaton @burke @mksd others?

Take care, Mark