# Proposal: Medication Dispense OpenMRS module **URL:** \ **Category:** Development\ **Tags:** drug-dispense, drugs, ohri, o3\ **Created:** [March 4, 2022, 4:10pm UTC](https://talk.openmrs.org/t/proposal-medication-dispense-openmrs-module/36021 "2022-03-04T16:10:41Z")\ **Posts on this page:** 20\ **Page:** 1
**Author:** ![mogoodrich](https://talk.openmrs.org/user_avatar/talk.openmrs.org/mogoodrich/32/3324_2.png) [@mogoodrich](https://talk.openmrs.org/u/mogoodrich)\ **Post date:** [March 4, 2022, 4:10pm UTC](https://talk.openmrs.org/t/proposal-medication-dispense-openmrs-module/36021/1 "2022-03-04T16:10:41Z")
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: [https://wiki.openmrs.org/display/projects/Medication+Dispense+Module](https://wiki.openmrs.org/display/projects/Medication+Dispense+Module) 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: > [@Plans for integrated prescribing/dispensing workflow](https://talk.openmrs.org/t/plans-for-integrated-prescribing-dispensing-workflow/34345): > > Hi, At PIH, one of our EMR priorities has become integrating prescribing and dispensing functionality as our users have expressed a need for a paperless workflow there. We are currently doing requirements and use case collection. Our high level needs are tools for: pharmacy staff to view all medications prescribed pharmacy staff to be able to indicate what/how much of medications are dispensed (at point of dispensing) clinicians to be able to view what was prescribed/dispensed in a convenie… fyi @bistenes@cioan@mseaton @ibacher@mksd Take care, Mark ---
**Author:** ![mksd](https://talk.openmrs.org/user_avatar/talk.openmrs.org/mksd/32/11729_2.png) [@mksd](https://talk.openmrs.org/u/mksd)\ **Post date:** [March 4, 2022, 8:23pm UTC](https://talk.openmrs.org/t/proposal-medication-dispense-openmrs-module/36021/2 "2022-03-04T20:23:06Z")
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. ---
**Author:** ![ibacher](https://talk.openmrs.org/user_avatar/talk.openmrs.org/ibacher/32/19751_2.png) [@ibacher](https://talk.openmrs.org/u/ibacher)\ **Post date:** [March 4, 2022, 9:18pm UTC](https://talk.openmrs.org/t/proposal-medication-dispense-openmrs-module/36021/3 "2022-03-04T21:18:13Z")
> [@mksd](#): > > 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. ---
**Author:** ![mksd](https://talk.openmrs.org/user_avatar/talk.openmrs.org/mksd/32/11729_2.png) [@mksd](https://talk.openmrs.org/u/mksd)\ **Post date:** [March 5, 2022, 12:43am UTC](https://talk.openmrs.org/t/proposal-medication-dispense-openmrs-module/36021/4 "2022-03-05T00:43:33Z")
@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. ---
**Author:** ![mogoodrich](https://talk.openmrs.org/user_avatar/talk.openmrs.org/mogoodrich/32/3324_2.png) [@mogoodrich](https://talk.openmrs.org/u/mogoodrich)\ **Post date:** [March 5, 2022, 6:09pm UTC](https://talk.openmrs.org/t/proposal-medication-dispense-openmrs-module/36021/5 "2022-03-05T18:09:22Z")
@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 ---
**Author:** ![mksd](https://talk.openmrs.org/user_avatar/talk.openmrs.org/mksd/32/11729_2.png) [@mksd](https://talk.openmrs.org/u/mksd)\ **Post date:** [March 5, 2022, 7:01pm UTC](https://talk.openmrs.org/t/proposal-medication-dispense-openmrs-module/36021/6 "2022-03-05T19:01:36Z")
> [@mogoodrich](#): > > Enough consensus on the model to move forward 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. ---
**Author:** ![akanter](https://talk.openmrs.org/user_avatar/talk.openmrs.org/akanter/32/331_2.png) [@akanter](https://talk.openmrs.org/u/akanter)\ **Post date:** [March 6, 2022, 6:13pm UTC](https://talk.openmrs.org/t/proposal-medication-dispense-openmrs-module/36021/7 "2022-03-06T18:13:04Z")
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. ---
**Author:** ![mogoodrich](https://talk.openmrs.org/user_avatar/talk.openmrs.org/mogoodrich/32/3324_2.png) [@mogoodrich](https://talk.openmrs.org/u/mogoodrich)\ **Post date:** [March 7, 2022, 2:22pm UTC](https://talk.openmrs.org/t/proposal-medication-dispense-openmrs-module/36021/8 "2022-03-07T14:22:33Z")
> [@mksd](#): > > My take would be to solely provide the FHIR API for all things touching to medication dispensing. 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? ---
**Author:** ![mksd](https://talk.openmrs.org/user_avatar/talk.openmrs.org/mksd/32/11729_2.png) [@mksd](https://talk.openmrs.org/u/mksd)\ **Post date:** [March 7, 2022, 2:25pm UTC](https://talk.openmrs.org/t/proposal-medication-dispense-openmrs-module/36021/9 "2022-03-07T14:25:46Z")
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. ---
**Author:** ![mogoodrich](https://talk.openmrs.org/user_avatar/talk.openmrs.org/mogoodrich/32/3324_2.png) [@mogoodrich](https://talk.openmrs.org/u/mogoodrich)\ **Post date:** [March 7, 2022, 2:25pm UTC](https://talk.openmrs.org/t/proposal-medication-dispense-openmrs-module/36021/10 "2022-03-07T14:25:56Z")
> [@akanter](#): > > Reviewing the value sets for this module I find a lot of concepts that would have limited use in OpenMRS settings. 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? ---
**Author:** ![mogoodrich](https://talk.openmrs.org/user_avatar/talk.openmrs.org/mogoodrich/32/3324_2.png) [@mogoodrich](https://talk.openmrs.org/u/mogoodrich)\ **Post date:** [March 7, 2022, 2:27pm UTC](https://talk.openmrs.org/t/proposal-medication-dispense-openmrs-module/36021/11 "2022-03-07T14:27:13Z")
> [@mksd](#): > > Core would provide the Java API (incl. the DAO layer) and the only web/REST API would be that provided by the FHIR2 module. Right, make sense. Though I’ll be noncommital on supporting that until I under what FHIR2 provides in greater detail… ---
**Author:** ![morrisng](https://talk.openmrs.org/user_avatar/talk.openmrs.org/morrisng/32/12190_2.png) [@morrisng](https://talk.openmrs.org/u/morrisng)\ **Post date:** [March 9, 2022, 3:13pm UTC](https://talk.openmrs.org/t/proposal-medication-dispense-openmrs-module/36021/12 "2022-03-09T15:13:32Z")
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](https://github.com/nmrs-nigeria/nmrs_commodity_app) ---
**Author:** ![jesplana](https://talk.openmrs.org/letter_avatar/jesplana/32/5_5575768a8748004e209b776fc1b2916d.png) [@jesplana](https://talk.openmrs.org/u/jesplana)\ **Post date:** [March 9, 2022, 3:25pm UTC](https://talk.openmrs.org/t/proposal-medication-dispense-openmrs-module/36021/13 "2022-03-09T15:25:45Z")
Hi @morrisng , do you have any screenshots or documentations available that you can share? Thank you, John ---
**Author:** ![morrisng](https://talk.openmrs.org/user_avatar/talk.openmrs.org/morrisng/32/12190_2.png) [@morrisng](https://talk.openmrs.org/u/morrisng)\ **Post date:** [March 10, 2022, 10:33am UTC](https://talk.openmrs.org/t/proposal-medication-dispense-openmrs-module/36021/14 "2022-03-10T10:33:49Z")
[Comodity Managemnt Module Training Manual.pdf](https://talk.openmrs.org/uploads/short-url/e42jE53pEs7mkkuntgSDuOOZbS7.pdf) (1.5 MB) ---
**Author:** ![mogoodrich](https://talk.openmrs.org/user_avatar/talk.openmrs.org/mogoodrich/32/3324_2.png) [@mogoodrich](https://talk.openmrs.org/u/mogoodrich)\ **Post date:** [March 18, 2022, 4:00pm UTC](https://talk.openmrs.org/t/proposal-medication-dispense-openmrs-module/36021/15 "2022-03-18T16:00:35Z")
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. [https://issues.openmrs.org/browse/TRUNK-6071](https://issues.openmrs.org/browse/TRUNK-6071) [https://issues.openmrs.org/browse/TRUNK-6072](https://issues.openmrs.org/browse/TRUNK-6072) [https://issues.openmrs.org/browse/FM2-462](https://issues.openmrs.org/browse/FM2-462) 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 ---
**Author:** ![mogoodrich](https://talk.openmrs.org/user_avatar/talk.openmrs.org/mogoodrich/32/3324_2.png) [@mogoodrich](https://talk.openmrs.org/u/mogoodrich)\ **Post date:** [March 18, 2022, 4:21pm UTC](https://talk.openmrs.org/t/proposal-medication-dispense-openmrs-module/36021/16 "2022-03-18T16:21:23Z")
@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: [https://build.fhir.org/valueset-medicationdispense-status.html](https://build.fhir.org/valueset-medicationdispense-status.html) 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 etc… … 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 ---
**Author:** ![mksd](https://talk.openmrs.org/user_avatar/talk.openmrs.org/mksd/32/11729_2.png) [@mksd](https://talk.openmrs.org/u/mksd)\ **Post date:** [March 18, 2022, 4:40pm UTC](https://talk.openmrs.org/t/proposal-medication-dispense-openmrs-module/36021/17 "2022-03-18T16:40:29Z")
Thank you so much @mogoodrich 👍 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.) ---
**Author:** ![wyclif](https://talk.openmrs.org/user_avatar/talk.openmrs.org/wyclif/32/19607_2.png) [@wyclif](https://talk.openmrs.org/u/wyclif)\ **Post date:** [March 18, 2022, 5:08pm UTC](https://talk.openmrs.org/t/proposal-medication-dispense-openmrs-module/36021/18 "2022-03-18T17:08:59Z")
@mksd makes sense, thanks for sharing guys. ---
**Author:** ![akanter](https://talk.openmrs.org/user_avatar/talk.openmrs.org/akanter/32/331_2.png) [@akanter](https://talk.openmrs.org/u/akanter)\ **Post date:** [March 19, 2022, 2:00am UTC](https://talk.openmrs.org/t/proposal-medication-dispense-openmrs-module/36021/19 "2022-03-19T02:00:08Z")
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). ---
**Author:** ![mogoodrich](https://talk.openmrs.org/user_avatar/talk.openmrs.org/mogoodrich/32/3324_2.png) [@mogoodrich](https://talk.openmrs.org/u/mogoodrich)\ **Post date:** [March 21, 2022, 4:43pm UTC](https://talk.openmrs.org/t/proposal-medication-dispense-openmrs-module/36021/20 "2022-03-21T16:43:38Z")
> [@akanter](#): > > 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. 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 [Next page](https://talk.openmrs.org/t/proposal-medication-dispense-openmrs-module/36021.md?page=2)