/
Medication Statement Data Model

Medication Statement Data Model

Owned by Samuel Male
Last updated: Feb 29, 2024 by Grace Potma
3 min read

But first, please see the use cases: https://wiki.openmrs.org/x/VwBIFQ 

As a result of discussions in this talk thread, we have to introduce a new domain for medication statements as an effort towards comprehensive support of medication lists in OpenMRS. This means introducing a "medication_statement" table along with its MedicationStatement object plus a lightweight service layer. 

API layer

A new MedicationStatementService  will be added to handle basic CRUD operations:

  • getMedicationStatement (by internal ID)

  • getMedicationStatementByUuid

  • getMedicationsStatementsByPatient

  • getMedicationStatementsByDrugOrder (assuming we shall link orders)

  • saveMedicationStatement

  • purgeMedicationStatement

  • voidMedicationStatement

  • unvoidMedicationStatement

We should also add new privileges to manage these operations

A medication statement is mutable



RESTful API

This will be implemented based on the FHIR2 module and will be bundled within the module (custom module) for the initial iterations. It will later be migrated to the standard fhir module after the core migration.

Database Modelling

The MedicationStatement  domain object should be a standard POJO that extends BaseFormRecordableOpenmrsData. The "medication_statement" table should contain the columns below:


Column

Datatype

Required

FK

Java Variable Name 

Class Type

FHIR Mapping

Comments

Column

Datatype

Required

FK

Java Variable Name 

Class Type

FHIR Mapping

Comments

medication_statement_id

int

Auto



medicationStatementId

Integer





patient_id



Yes

patient.patient_id

patient

Patient

subject



status

int



concept.concept_id

status

Concept

status

What options do we plan to support for the upstream? Do we have these already defined in CIEL?

category_id

int

?

concept.concept_id

category

Concept

category

  • Should this be required?

  • What options do we plan to support for the upstream?

drug_id

int

?

drug.drug_id

drug

Drug

medication

  • Should this be required?

  • Considering that data entry may rely on external sources, should we enable support for free text entry?

encounter_id

int



encounter.encounter_id

encounter

Encounter

context





adherence

int

No

concept.concept_id

adherence

Concept

adherence.code

What options do we plan to support for the upstream? Do we have these already defined in CIEL?

adherence_reason

int

No

concept.concept_id

adherenceReason

Concept

adherence.reason

Should this be captured as free text?

medication_start_date

datetime





medicationStartDate

Date

effective[x]

These fields are meant to capture the date/time or interval when the medication is/was/will be taken. 

medication_end_date

datetime





medicationEndDate

Date

effective[y]

date_asserted

datetime





dateAsserted

Date

dateAsserted



information_provider

int

Yes

person.person_id

informationProvider

Person

informationSource



medication_reason_id

int



concept.concept_id

medicationReason

Concept

reason

Considering that data entry may rely on external sources, should we enable support for free text entry?

note

CLOB





note

String

note

Do we need this for phase one?

dose

double





dose

Double

dosage.doseAndRate.dose.doseQuantity

These are dosage fields and currently, the defined fields don't exhaust all the dosage fields as per the FHIR spec, I've left out: asNeeded, asNeededFor etc.. 

Questions: 

  1. Do we want to support all dosage fields?

  2. Do we want to mark some fields as required?

  3. Do we want to support free text entry for most of the coded fields? This could be necessary because data entry can be based on external sources 

dose_units

int



concept.concept_id

doseUnits

Concept

dosage.doseAndRate.dose.Quantity.unit and/or code

dosing_instructions

text





dosingInstructions

String

dosage.text

route

int



concept.concept_id

route

Concept

dosage.route













partOf















derivedFrom

  • Assuming this statement was derived from a dispensing event, do we want to associate the dispense here?

  • How does this property differ from partOf?













relatedClinicalInformation

  • Do we want to link adhoc data points eg. an observation, a related dispense, or request event? 













renderedDosageInstruction

This captures a full rep of the dosing info as markup. Do we need this for phase 1?



















Related content