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.
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.
@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)
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?
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?
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.
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.
@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
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…
@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.)
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…
