Medical Administration Record

OpenEMR Development Inpatient Development
#1

Has anyone developed eMAR’s feature?

OpenEMR for Assisted Living Facility & Medication Administration
#2

Do you mean “Medication Administration Record”?

1 Like
#3

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

#4

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

#5

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

#6

Robert,
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
#7

I have bookmarked the project site.

#8

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.

Project - Support MAR
Project - Support MAR
#9

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!

#10

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?

#11

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

#12

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:

#13

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?

#14

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.

#15

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

#16

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.

#17

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

#18

Great idea. We’ll keep an eye out.

-m

#19

@jboyd13

#20

Thanks.