Inpatient: The Plan

(Robert Down, BSN, RN) #1

It’s clear that OpenEMR shines in the outpatient world. But we’ve had inpatient functionality on our radar for about a year and I think it is time we really begin to consider what this looks like.

Bed Management

In the outpatient world, a room is the smallest unit for a location. But in the in patient world we need to expand that.

A bed can have 1 room. 1 room can have n beds. A room can be located in 1 unit/ward. A unit/ward can have 1 parent unit/ward. Every unit/ward must have either a parent unit/ward or a facility.

This means a patient is located at Facility—>Ward—>Room—>Bed.

A bed should be identified by a UUID and should have human-readable name (name). It should have a foreign key of room_id. It should have an active Boolean and a foreign key for status. (Example: Clean, Dirty, Occupied, etc)

A room should have a UUID and a name. It should have a foreign key of unit_id. It should have the same active and status options.

A unit should have a UUID and a name. It should have an optional parent_id or facility_id. Active and status fields here too (status may be “At Capacity”)

Every Facility can have n units. Every unit can have 1 parent unit.

This gives us “Acme Hospital”, “Medical-Surgical Unit”, “Room 2531, Bed 1”

Ok, so now we can put a patient in a bed with proper unit support.

Some other things to consider.


Currently the scope of an “order” in OpenEMR is primarily a Procedure - this can include lab work, radiology, etc. However, an “order” for in patients can be far more than just a procedure and we’ll have to expand what an order looks like.

Here’s a typical set of orders you may see for inpatient:

Diet Order: NPO, Nothing By Mouth

Consult: Cardiology, Wound Care, Case Management

Activities of Daily Living: Bed Rest


Medications: Aspirin 81mg PO now

Diagnostic Tests: CXR 1-view, MRI of brain with contrast

Discharge: Planned DC based on results

This is just what I can think of off the top of my head. How I think we should approach this:

We create a base Order object. This contains all the basic parts of an order, things that every order has. This includes a UUID, the provider signing off, a category of the order (CPOE, Phone read back, Verbal readback, etc), who actually entered the order (a nurse can take a phone/readback order, enter it into the system, and the provider signs off later), current status of the order (Ordered, InProcess, Future, Canceled, etc).

We create a set of “top level orders” (Lab, Meds, Diagnostics, Consults, Diet, etc). These top level orders extend the base class and offer the specifics of each order type. For instance, a Diet order requires a a significantly different set of data than an order for a medication.

Orders will be a prime area where I think we will be heavily utilizing Event dispatching.

Also, something to consider is all of this needs to be built around a point in time architecture. That means we never UPDATE a database record and we never DELETE a record. If there’s a change, we basically SELECT the record in question, make our changes, update the time_updated and updated_by fields and INSERT it into the table as a new row. This allows us to see every change that was made to an order, it creates a perfect audit trail. We may be doing something similar currently, I just need to check out SQL calls.


The next key component of inpatient functionality is the Medical Administration Record. This is a complex matrix of medications, parameters, and times for every patient. The MAR should reflect every medication I’ve administered, will administer, was canceled, etc. It will looks kinda like a spreadsheet. Rows of medications, columns of time.

There’s a group of Pharmacy informaticists from VCU that are interested in helping create this component. This will be a huge undertaking because of the complexity surrounding medication administration. Pain meds need assessment data tied to it, flu shots need lot numbers entered, barcode scanning ensures the 5 rights of medication admin (right patient, right meds, right dose, right route, right time). This is going to be one of the heaviest parts of the inpatient functionality, but I’m stoked to have the connections at VCU to help guide us.

Continual Assessment Data

Next major piece of the puzzle - assessment data and form integration. I do assessments every 4 hours on patients, covering all the body systems. This means a LOT of data to manage.

I see an Assessment class being created which is extended to meet whatever assessment data needs to be entered. Example could include a CariologyAssessment class. This class can define all the fields being assessed along with possible input data. Example:

Heart Sounds: S1 and S2, S3, Pacemaker

Skin Temp: Warm, Cool, Clamy

Pulses (there’s a lot of pulses, each one could have its own field: +4, +3, +2 etc

Another example would be the NIH Stroke Scale.

The AssessmentOptions would likely be a subclass of a List.

So you have lists of assessment options which are used in an Assessment Item, which belongs to an Assessment Group which can be organized however best fits the use-case.

The Assessment section will look a whole lot like a giant Matrix, rows of Assessment items, columns of date-time specific assessment findings.

Expanded User Management

I need to investigate, but our idea of a User may need to be abstracted a bit. Right now it’s physician oriented, but they’ll be lots of other licensed personnel working on charts - MD, PA, APRN, RN, LPN, CNA, EMT, etc.


Another thing to consider is Discharge, but I haven’t put much thought into that yet.

There’s likely more to come, but this lays out the major areas we need to consider. A lot of smaller needs can be built out with LBV Forms. But Bed Management, Orders, MAR, and Assessments will need a lot of new code.

I want us to be very deliberate about how we go about creating this new functionality. We need to build it in a way that is still manageable in 5-10 years. We need proper planning.

(Robert Down, BSN, RN) #2

Sorry for the novel, this turned into a brain dump of everything I’ve been pondering for inpatient use for a while

(Elijah Wisdom) #3

This is a good plan. We had started this plan last year in the chat part of the group , you could go see it for more info.
Also this is overdue.

(Jboyd13) #4

That’s a great brain dump. The good thing about this is if you make the modules so the can be used in other facilities such as Nursing Homes, Prisons, Rehabilitation Centers, etc. That would be fantastic.


(Robert Down, BSN, RN) #5

Given the modular plan, it will be (relatively) easy to just flip on the modules you need. Need the MAR but not bed management? Just flip a switch on the Admin screen and disable that particular module.

I think this has a lot of potential for non-acute inpatient use, like @jboyd13 said.

(Daniel Sandoval) #6

@robert.down there are some slightly outdated designs for this here: Units Support

Lemme know if you’d like me to dive back in and update these now that you’ve written this spec.

(sergio samoilovich) #7

Please contact me if you want to try my new Inpatient module for OpenEMR. Several of the needs described before are covered…

(Elijah Wisdom) #8

Well done Sergio. kindly email me at so i could try it out and give my observations.

(sergio samoilovich) #9

I just saw your image that describes wards, rooms, beds. It seems that you are making good progress in this area. Your approach takes care of every important issue in an inpatient module. This part needs to be elastic to adapt to different institutions, each with specific divisions between areas, wards, floors, divisions, rooms and more.

My work was done at the request of a single customer and I had to improvise. Patient selection is done outside the standard system. At this point I am selling my module as it is, but I will later follow the guidelines to merge it with the general OpenEMR project.

I welcome your suggestions or ideas about this subject.