Hi all,
I have started the work in adding this functionality to core, and have a draft PR available for review which implements the initial design document.
In the process of developing this out, I’ve run into a few questions which I wanted to bring back here for discussion and greater visibility:
Question 1: How to handle the provider or provider(s)
The initial design called for a single “provider” attribute on the MedicationDispense object. This was to reduce the complexity of implementing the FHIR model, which rather calls for a set of 1-N “performers”, where a “performer” refers to a “function” and “actor”.
Now, the current FHIR specification defines the available functions as these:
| Code |
Display |
Definition |
| dataenterer |
Data Enterer |
Recorded the details of the request |
| packager |
Packager |
Prepared the medication. |
| checker |
Checker |
Performed initial quality assurance on the prepared medication |
| finalchecker |
Final Checker |
Performed the final quality assurance on the prepared medication against the request. Typically, this is a pharmacist function. |
At the same time, our MedicationDispense design also calls for the following related fields: dateCreated, createdBy, whenPrepared and whenHandedOver.
A possible alternative proposal would be to add the various “performers” and functions like this (this may not be totally accurate):
-
dateCreated, createdBy (User) - This would correspond to “dataenterer” above
- Change “whenPrepared” to datePrepared and add preparedBy (Provider) - This would correspond to “packager” above
-
dateChecked, checkedBy - This would correspond to “checker” above
- Change “whenHandedOver” to dateDispensed and add dispensedBy (Provider) - Not sure if this would correspond to “finalchecker” or if this is different?
Another alternative would be to create a separate table/entity for tracking the various performers on the MedicationDispense, which would support an arbitrarily flexible workflow and set of functions, which would be mapped to Concepts.
Question 2: How to handle note(s) / annotations
The initial design called for a single “note” attribute on the MedicationDispense object, which is just a String. This was to reduce the complexity of implementing the FHIR model, which rather calls for a set of 1-N “annotations”, where an “annotation” contains “author”, “datetime”, and “note text”.
However, it feels to me like the more flexible and detailed model is one we would want to support. Thoughts on adding 0-N association between MedicationDispense and MedicationDispenseNote, which would be an OpenmrsData object with “provider”, “noteDatetime”, and “contents” (or similar named fields)? Alternative ideas?
Note, this is potentially something we could punt to phase 2, leaving “note” out of the data model entirely and adding it in at a later stage.
Question 3: Should the service method void and recreate on edit
Do we want to set up the MedicationDispenseService to ensure that - if a MedicationDispense object is saved with edits - that it first voids the existing object, then creates a new clone with the edits, in order to save this audit history? Do we want to retain a “previousVersion” between the two if so? This seems like the right thing to do, though it is not done consistently across the OpenMRS API (patient, person, person_name, person_attribute, encounter, patient_program, patient_state, relationship, etc. do not have this auditing in place).
Question 4: Should we add any indexes to the data model
Does the medication_dispense table need any indexes added to it to ensure it performs well.
Question 5: Do we need to re-think the dosing fields
The DrugOrder API in OpenMRS supports a flexible dosing model. There are standard relational fields for SimpleDosingInstructions such as dose/doseUnits/frequency/route, but there is also support for FreeTextDosingInstructions and any other custom DosingInstructions that an implementation wants to support. In FHIR, the dosing instructions are represented by a “Dosage”, which is modeled similarly but has some differences. Should our model for adding dosing-related fields to MedicationDispense be modified in any way to ensure that it can support the necessary use cases and mapping to FHIR?
There is a lot above, and probably too much for one talk post. Interested in feedback from @burke , @ibacher , @mogoodrich , @Mekom , and anyone else who is interested in this feature moving forward.
Thanks,
Mike
