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.