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 |
|
| drug_id | int | ? | drug.drug_id | drug | Drug | medication |
|
| 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 | varchar(1024) | note | String | note | |||
| 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..
| ||
| 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 |
| ||||||
| relatedClinicalInformation |
| ||||||
| renderedDosageInstruction | This captures a full rep of the dosing info as markup. Do we need this for phase 1? | ||||||