Inpatient: The Plan

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.

Orders

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

Labs: CBC, BMP, PT/INR

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.

MAR

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.

Discharge

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.

4 Likes

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

3 Likes

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.

1 Like

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.

Joyce

2 Likes

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.

1 Like

@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.

1 Like

28 posts were split to a new topic: Inpatient module (proprietary)

We have a group working on Ordering/MAR usage. It is just a very large step because of the complexity, we are working on it though!

Excellent! I will be following its progress and look forward to see it in action.

Regards,

Felipe Ferreira

1 Like

It looks good to me.

I have just setup OpenEMR for a small clinic in Accra, Ghana.

So I am now getting my head round the Clinics workflows (Outpatient functionality), before I can even start to think about inpatient/bed management side of things.

I come to this with years of experience with Cerner/EPIC/Lorenzo/iPM and similar systems in Europe, so this is all exciting to me.

This has a great potential to help public and private healthcare facilities in Ghana and I really would like to create champion it as an initiative.

2 Likes

Is the plan continued? Is there any news?
Thank you. regards

1 Like

Are you still working on these modules?
regards