Wiki Spaces


Get Help from Others

Q&A: Ask OpenMRS
Discussion: OpenMRS Talk
Real-Time: IRC Chat | Slack


Page tree
Skip to end of metadata
Go to start of metadata

We will need to add a new "medication_dispense" table (and companion domain object MedicationDispense) modeled after the  MedicationDispense FHIR resource:

The domain object should extend BaseOpenmrsData and provide the standard audit visits of that class.  

Beyond that, the table/domain object should contain the fields below.  (Note the "Phase 1" column, which denotes if this field should be added in the initial implementation.  Fields with a "no" here are fields that will be delegated to a later phase. I have grouped those fields to the bottom of the table)

"Related Order/Drug Order Property" is a reference to the related fields on a DrugOrder domain object.  (ie, theoretically, if you created a MedicationDispense from DrugOrder without any modifications, the values in these fields could be copied from the Drug Order to the MedicationDispense)

When we create the new domain object, we should make sure that for each property we add a comment noting which FHIR field it maps to (perhaps even with a link) so that we remember the reasoning behind each field.

Column NameColumn DatatypeRequiredForeign KeyJava Variable NameJava Variable Class


FHIR Field

Related Order/Drug Order PropertyPhase One?Notes


drug_idintNo drug.drug_iddrugDrugmedication.reference(Medication)DrugOrder.drugYesMay need to clarify how this actually gets transformed in FHIR
patient_idintYes patient.patient_idpatientPatientsubjectPatientYes
location_idintNo location.location_idlocationLocationlocationN/AYeswhere the dispensed event occurred
encounter_idintNoencounter.encounter_idencounterEncountercontextN/AYesencounter when the dispensing event occurred
provider_idintNoprovider.provider_idproviderProviderperformer.actorN/A​_YesNote that FHIR provides support for 0..x "performers" and each performer may have a "performer.function" where "function" is a codeable concept and reflects a role like "packager"or "checker";  we will start with support for just a single 0..1 "provider"
drug_order_idintNodrug_order.drug_order_iddrugOrderDrugOrderauthorizingPrescriptionOrder.orderIdYesthe drug order that led to this dispensing event; note that authorizing prescription maps to a "MedicationRequest" FHIR resource

preparation | in-progress | cancelled | on-hold | completed | entered-in-error | stopped | declined | unknown  



For  allowed coded answers, see:  

Note that these include things like "Stock Out"  which we will likely be building some business logic around them.  

typeintNo concept.concept_idtypeConcepttype.codeableConceptN/AYes 

For potential example concepts, see:

Note that these include things like "Refill" and "Partial Fill" which we will likely be building some business logic around them.


Not required by FHIR

quantity_unitsintNoconcept.concept_idquantityUnitsConceptquantity.unit and/or quanity.codeDrugOrder.quantityUnitsYes

See: FM2-64 - Getting issue details... STATUS

doseDoubledosageInstructions.doseAndRate.dose.doseQuantity DrugOrder.doseYes
dose_unitsintNoconcept.concept_iddoseUnitsintDosageInstructions.doseAndRate.dose.Quantity.unit and/or codeDrugOrder.doseUnitsYes

See: FM2-64 - Getting issue details... STATUS

routeintNoconcept.concept_idrouteintDosageInstructions.route DrugOrder.routeYes





(warning) Note that we will continue to map this as a single "frequency" concept, although it doesn't map well to FHIR, to make consistent with DrugOrder in OpenMRS

asNeededBooleanDosageInstructions.AsNeeded.asNeededBoolean DrugOrder.asNeededYes
dosingInstructionsStringDosageInstructions.patientInstructions  DrugOrder.dosingInstructions​_Yes

From FHIR: "When product was packaged and reviewed"

I used "datePrepared" instead of "whenPrepared" because it seemed more in-line with OpenMRS conventions.  Happy to debate.


From FHIR: "When product was given out"

 I used "dateHandedOver" instead of "whenHandedOver" because it seemed more in-line with OpenMRS conventions.  Happy to debate.

notevarchar(1024) (question)No

FHIR supports 0..n but we will only support 0..1 for starters? It also supports the author and the time via the "annotation" type. 

(question) Should this be a clob, see comment from Ian below



wasSubstitutedBooleansubstitution.wasSubstitutedN/AYesTrue/false whether a substitution was made during this dispense event

For valid FHIR concepts, see:

We also could punt on building this in Phase 1, and make the distinction between enum and concept when we have an actual use case.

Let Andrew Kanter  know if we need these as concepts.


For valid FHIR concepts, see:

We also could punt on building this in Phase 1, and make the distinction between enum and concept when we have an actual use case.

Let Andrew Kanter  know if we need these as concepts.


From FHIR: The amount of medication expressed as a timing amount.

It might be best to drop support for this an only support quantity, at least at a first pass (technically quantity can have a units of days)


ie, Inpatient, Outpatient, Discharge, Community

For valid FHIR concepts, see:

Let Andrew Kanter  know if we need these as concepts.

destination_id intNolocation.location_iddestinationLocationdestinationN/ANo 

From FHIR: "Where the medication was sent".

Do we want this for "phase 1"?

receiver_id intNoperson.person_idreceiverPersonreceiverN/ANo 

From FHIR: "Who collected the medication"

Do we want this for "phase 1"?

FHIR supports  a receiver of a "Practioner" or "Patient", so "Person" is the only current way in OpenMRS to support this 

(0...n in FHIR, but we currently only support 0..1) 

NoExternal identifier

NoEvent that dispense is a part of (maps to a FHIR Procedure)



  • No labels

1 Comment

  1. Thanks Mark for this great work. Addressing some questions:

    1. My current feeling is that it's preferable to avoid ENUMs except in very limited cases and rely on standardised concept maps instead where we need business logic that picks out particular concepts. There are a few reasons for this:
      1. Enums are not easily localisable, concepts are
      2. Extending enums requires updating the module and if the value set (list of possible values) can change. This is actually a bigger concern for core.
    2. As a general requirement, I'd avoid data elements we don't have a real need for. FHIR models are especially verbose with the idea that most consumers are using a limited (profiled) subset of the data elements... that also why most data elements in FHIR core are marked as optional, i.e., they are there if you need them, but won't be if you don't need them.
    3. I'm actually surprised that FHIR doesn't have a rule requiring either quantity or daysSupply be provided. I definitely don't see a real reason for capturing both and quantity for a raw number is probably the much more straight-forward.
    4. Note might be best stored as a CLOB since it's doubtful we're searching for it.