Medical Administration Record

Yes, I do. I always ask before beginning a project to see if someone else has already done it and is willing to share.

I’d be interested in working on this with you!

Created a project on GitHub (Medical Administration Record · GitHub)

Will start formulating a plan. Let’s use this topic to hash out the early ideas

I would be honored to work with you on this project if it comes to bear fruit.

I am awaiting more information on how the system is to be developed. I am looking forward to capitalizing on the new construct that is underway.

1 Like

I have bookmarked the project site.

Medical Administration Record

Exploratory Roadmap

What is a Medical Administration Record?

A Medical Administration Record (aka “MAR”) provides a record for all medications for a patient at a given encounter (think a hospital visit). It is often considered the official medication documentation for a patient, and nurses use it as the “gold standard” when deciding if a patient is able to receive a medication. Medications include scheduled, as needed (PRN), discontinued, as well as one-off prescriptions.

Basic Data Points of a MAR

  • Patient ID (Name, DOB)
  • Medication name
  • Dosage
  • Route
  • Date and time
  • Site of administration
  • 2nd provider witness
  • 2nd provider signature
  • Adverse reaction
  • Pre-administration assessment
  • Follow up assessment

Integration Points

  • Administration section to enable/disable MAR and set simple settings as well as possibly complex rules
    • This includes a dedicated section to manage a virtual pharmacy (i.e. valid medications that can be ordered)
  • Encounter hook to provide link
  • Dedicated table-based view of medications
  • New form to add a medication to the MAR
  • New form to witness/sign/administer medication
  • Potential alert hooks that trigger overdue medications
  • Basic interaction checker (Alert for Allergies)

Potential Development Routes

  1. Create OpenEMR\MAR namespace
  2. Investigate routes to administration
  3. Evaluate usage of event-driven functions
  4. Sketch out full data entity
    • This is likely going to be split into OpenEMR\MAR and OpenEMR\Medication where a MAR object represents a collection of Medications (decoupling the MAR from medications)

Personal Opinion

I think the iniital steps of any project like this is to layout the entities involved. Before we can begin thinking about UI or event triggers or databases we must know what data we are actually engaging with. I suggest we do this by collarborating on a document mapping out what the objects are in plain-text before trying to abstract them into any type of codable language interfaces. I have experience on the front-end of inpatient MARs – I use them in my clinical work and have a strong understanding of what a nurse would see/use on an everyday basis (at least for in patient). Nurses (at least in the US) provide the BULK of care involving the actual administration of medications.

This is excellent! Thanks for sharing this information. I was only able to find limited information about how the MAR actually work from a workflow point of view. I do agree that we need a clear concept of what is to be accomplished before any code can be written. I am going to study what you have written. Meaning I will read over it a number of times to truly absorb the information so that I may ask intelligent questions.

This is also great that you have experience because we don’t have to wait on information from the party that had approached me about this feature build. Let’s keep it moving!

Encounter hook: this should not be needed because MAR is generally not connected to a patient visit in the hospital or nursing home facility. Meds are just passed with no respect to an appointment. So, my question is why create an encounter hook?

Are we going to discuss next the object model for this feature and are we going to use the Zend module framework?

Yes, we should discuss the object model first.

No need to use Zend at the moment, the object model will be just a regular PHP class.

We can hash out the Medication Object here: Medication Object · openemr/openemr Wiki · GitHub

and the MAR Object here: MAR Object · openemr/openemr Wiki · GitHub

Note, those links are on the github wiki, used basically just as a scratchpad that we both have access to :slight_smile:

I have been out in the field engineering retail systems. I am back now and
wish to catch up on this. I have read the entry for the Medication-Object.
I am understanding what I am reading. I am learning as we go because I have
never discussed with another how to design. Looking forward to getting this
going. What is our next move?

Didn’t want this to fall to the wayside. I am looking to you Robert to lead the way as I don’t really know what is all entailed in a MAR system.

Won’t let this fall away, just need to wrap up like 3 parallel pull requests I’ve got open. Luckily I think I closed 2 of them today so hopefully we can start putting together a real game plan here shortly. Will keep you updated

Late to this thread. One of the use case / integration is offices administering medications from inventory during a visit.

We have been using a LBF with plugin code for this routine activity.

@MatthewVita medical administration record is a mandatory data for cTAKES :wink:

Great idea. We’ll keep an eye out.




There are some things to consider in the model:

  • Drug-Drug Interactions - this would be meds in the MAR, Rx’d, and the patient’s med list

  • Allergies/intolerances - would need to connect to the food and medication allergy list

  • Listing next scheduled dose

  • Ensure that scheduled meds are separate from PRN meds

  • Signature for person administering all drugs. 2nd signature or witness only required for certain types of drugs

  • Calculate administration rates for IV, Central Line, Intra-arterial drugs

  • For routes of administration (ROA), will need a check to make sure the right route is selected. (This is a sophisticated feature.) For example, if the doctor ordered the medication to be given orally and the nurse has an IV medication. The system would alert the nurse they selected the wrong route.

  • ROAs - (some that I remember, but we can look up to make sure all are covered)

    • Oral (PO), Sublingual (SL), buccal, Inhaled, ET Tube
    • Nasal
    • PEG/G-tube, PEJ/J-tube,
    • Intradermal (ID), Transdermal, Intramuscular (IM), Intravenous (IV)
    • Central line - PICC, CL
    • Intra-arterial
    • Rectal (PR)
    • Intravaginal
    • Otic (ear)
    • Ophthalmic (eye)
  • When it comes to route and if it is IV make sure they person has an IV and the user can specify which IV the medication is being administered. There may be IV incompatibilities you need to be aware of and alert the user about (I don’t remember if we look these up or if the newer EHRs consider that. I haven’t worked in a hospital in awhile).

  • Assessments before and after administration, e.g.:
    *Tie pain assessments to pain meds.
    *Tie heart rate assessments to certain BP meds.
    *Tie BP assessments to BP meds.

    • Temperature after meds given for fevers or where body temperature is relevant

Labs for meds that require levels to be monitored for therapeutic or toxicity levels.

Robert, would there be separate modules for special administrations such Blood, FFP, High Risk meds (e.g. heparin), anti-epileptics, etc.

This may not be true for international hospitals but some have dispensing machines and the EHR MAR is tied to those dispensing machines to confirm meds dispensed match meds being administered. This would be a nice to have if a facility needed it.

That’s all I can think of right now. I hope it helps.


Wow, thanks @jboyd13! You definitely took it way further than our initial look.

A typical workflow involves scanning the medication into the EHR just before Administration. I believe this ties a particular vial of medication or pill to the patient. As for the dispensing mechanism, we’d need a way to emit data from OpenEMR to that server (likely FHIR or HL7)

There’s probably more to it than this, but what a great start.