Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 2 Next »

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

(info) We should also add new privileges to manage these operations

(info) 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:

ColumnDatatypeRequiredFKJava Variable Name Class Type

FHIR Mapping

Comments
medication_statement_idintAuto
medicationStatementIdInteger

patient_id
Yespatient.patient_idpatientPatientsubject
statusint
concept.concept_idstatusConceptstatusWhat options do we plan to support for the upstream? Do we have these already defined in CIEL?
category_idint?concept.concept_idcategoryConceptcategory
  • Should this be required?
  • What options do we plan to support for the upstream?
drug_idint?drug.drug_iddrugDrugmedication
  • Should this be required?
  • Considering that data entry may rely on external sources, should we enable support for free text entry?
encounter_idint
encounter.encounter_idencounterEncounter

context



adherenceintNoconcept.concept_idadherenceConceptadherence.code

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

adherence_reasonintNoconcept.concept_idadherenceReasonConceptadherence.reasonShould this be captured as free text?
medication_start_datedatetime

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

medicationEndDateDateeffective[y]
date_asserteddatetime

dateAssertedDatedateAsserted

information_provider

intYesperson.person_idinformationProviderPersoninformationSource
medication_reason_idint
concept.concept_idmedicationReasonConceptreasonConsidering that data entry may rely on external sources, should we enable support for free text entry?
notevarchar(1024)

noteStringnote
dosedouble

doseDoubledosage.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_unitsint
concept.concept_iddoseUnitsConceptdosage.doseAndRate.dose.Quantity.unit and/or code
dosing_instructionstext

dosingInstructionsStringdosage.text
routeint
concept.concept_idrouteConceptdosage.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?









  • No labels