Skip to content

Medication Mapping OSCAR to E2E

Jeremy Ho edited this page Mar 6, 2013 · 12 revisions

E2E Mapping Medications Section

The E2E Medications section contains data pertaining to the specific patient's active and historical medications. It aims to have as much data granularity as is available from the exporting EMR, and contain prescription, dispensing and administering data if available.

General Assumptions

User Assumptions

  • The provider of OSCAR will only use the Rx3 prescription feature for recording prescriptions.
  • The provider will search for the drug they intend to prescribe to the patient and select the closest match when available.
  • The provider will mark drugs as longterm when the drug is a recurring prescription.

Data Assumptions

  • Any non-custom drug entered into OSCAR will have a DIN number associated with it.
  • Non-custom drug information will be centrally tied to the DIN number - the data associated with the drug itself should map to the DIN number.

Issues

Issue 1

  • E2E has concept of Medication Event with 0:n to Prescription Events (plus dispensing and administration events).
  • OSCAR currently only has prescription events.

Options

  • Map OSCAR Prescriptions 1:1 to E2E Medication Events (with additional details in the Prescription event mapped). This would result in a 1:1 mapping
  • Derive E2E Medication Events from DINs prescribed in OSCAR

Decision
Team meeting 01-Feb-2013

  • In the E2E export we derive Medication Events from active DIN numbers on OSCAR prescriptions. We then cluster those prescriptions in the E2E export as prescription events under a single Medication Event. This will result in a 1:n mapping a medication event to prescription events.
  • No DIN coded in OSCAR (i.e. custom med) entries will not be grouped but will show up as 1:1 medication event to prescribing event.
  • Consider raising this with OSCAR in case this could be helpful in a future redesign.

Issue 2

  • E2E contains a status flag of either active or completed in the Medication Event section. This field tells you whether the drug is still active for the patient or if its historical.
  • E2E Medication Events represent a single drug, whereas a Prescription Event represents the times when a provider has prescribed the drug to the patient.
  • OSCAR has a flag for "long term" medications, but may not necessarily enforce the same state over multiple prescriptions of the same drug.
  • Medication records in OSCAR are inserted into the drugs table sequentially over time. This preserves the order of prescriptions created over time. OSCAR only records prescription events.

Options

  • Move the status to each Prescription event and record it there
  • Check the latest prescription's status for the drug and base the field off of that

Decision
Team meeting 08-Feb-2013

  • We decided that the best course of action would be to check the most recent prescription for the drug. If it was flagged as longterm, it would be active irregardless of whether there is an active prescription at the time. If it wasn't flagged longterm, it would be flagged as active only if the prescription is still currently active.
  • We could take advantage of the ordering of prescriptions OSCAR has - by reversing the order and sorting by DIN, we would have the same drugs sequentially in the list, and the order reversal would guarantee that the first encounter of the drug would be the most recent prescription recorded.

Issue 3

  • E2E requires a field called e2e:formCode which represents the "strength" of the drug based on what the DIN code specifies.
  • Although defined in the specification document, it has problems passing through the XSD validator

Options

  • Omit the field from the export and leave it as a nullFlavor
  • Tweak the XSD to handle the field as close to the written specification as possible as interim solution

Decision

  • We modified the XSD validator for the E2E document in order to satisfy the Strength data requirement. For now, the field is a strength element containing the strength value as well as the unit of measurement
  • This will need to be revisited when an updated specification is released
  • Flagged with E2E specification holders.

Issue 4

  • E2E defines drug frequency as a numerator/denominator/unit field while OSCAR defines frequency based on codes such as QAM, Q1-2H, and BID.

Options

  • Omit the frequency field from export and leave it as a nullFlavor
  • Change the data field to store the frequency codes provided by OSCAR into E2E
  • Create a frequency numerator/denominator to code mapping for translation of intention

Decision

  • A mapping will be done for frequency to relate the two different field types and the translation table will be hardcoded into the export feature
  • Flag with E2E specification holders.

Issue 5

  • E2E defines its own code for describing drug form, whereas OSCAR draws based on Drugref/DPD's drug form terminology.
  • The canadian DPD and Drugref use the same terminology.

Options

  • Override E2E's definition and use DPD terminology in the drug form field.
  • Create a mapping between E2E form and DPD form codes

Decision

  • A mapping between the canadian DPD and E2E's terms will be done.
  • Not all mappings align. There is a possibility we must consider the route of entry to match more terms.
  • Flag with E2E specification holders.

Issue 5.1

  • Mapping DPD/Drugref Form to E2E is possible, but there exists some DPD terms that are unmappable to E2E vocabulary.

Options

  • For all unmappable terms, since Form is R 0..1, it means we can omit that field.
  • Do not omit the field, but fill it in with a form of null value code.
  • Omit the field, but add an xml comment mentioning the DPD code - maintain conformance but also note original data.

Decision

  • We decided to omit the field for unmappable terms, but leave an xml comment in the same location to let any human reader know the original form.
  • Flag with E2E specification holders.

Issue 6

  • E2E's RouteOfAdministration has a specified list of possible entry points, but is missing IM (intramuscular).
  • OSCAR allows the route to be freetext specified by the provider - may lead to unmappable terms and inconsistency.

Options

  • Override the route field with whatever OSCAR provides as workaround
  • Create a function to transform unexpected route entries or similar codes to E2E's vocab and omit terms that do not fit.

Decision

  • Pending

Mapping

Relevant OSCAR DB Tables: drugs

Medication Mapping Table

Current Iteration: 13

General Topics

Resources


Previous Iteration: 12

Previous Iteration: 11

Previous Iteration: 10

Previous Iteration: 9

Previous Iteration: 8

Previous Iteration: 7

Previous Iteration: 6

Previous Iteration: 5

Previous Iteration: 4

Previous Iteration: 3

Previous Iteration: 2

Previous Iteration: 1

Previous Iteration: 0

Clone this wiki locally