Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

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. 

...

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?
noteCLOB

noteStringnoteDo we need this for phase one?
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?









...