Medication Statement Data Model

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
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: Do we want to support all dosage fields? Do we want to mark some fields as required? 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?