New Institutional Module: Is it time?

[sjpadgett (Jerry P)]

I have been developing Institutional module off and on for the last couple years where it became fragmented and disjointed. I have picked it back up as my only project and to build a module that makes sense and expandable.

While this roadmap may show item status are production ready, in real terms it means usability but decisions need to be made on how tightly I want to integrate submodule with OpenEMR.

I am putting this topic up to see what interest this module would raise and if there is community support. I hope to have a working product with in thirty days but I will need a site to beta test and eventually release to production mode.

The below is how I track and release updates to current interested parties. I will be updating progress here by replacing this summary.

This project is a big deal to me and I hope to get it right. I’m still in the process of deciding how I will release and will depend on community support whether I opensource or not. I’ve been asked numerous times over the years about Institutional support for OpenEMR where I could always internalize what a boom it would be to advancing the project, but in the end, nobody wanted to support the effort monetarily or development wise. I need all the help I can get, especially from any developers whom are knowledgeable with various institutional setting.

If a more detailed engineering implementation plan of module or app structure is wanted, PM me. A quick hint is that in its current development state it almost stands on its own.

OpenEMR Institutional Workflow Module

Product Capability Summary · v0.9.5 · February 2026

---

At a Glance

Submodules	PHP Classes	Clinical Pages	Release
23	100+	27+	v0.9.5

---

Executive Summary

The OpenEMR Institutional Workflow Module is a purpose-built clinical operations extension for OpenEMR, the world’s most widely deployed open-source electronic health record system. The module transforms OpenEMR into a fully featured institutional workflow platform capable of managing Emergency Department tracking, inpatient observation stays, behavioral health boarding, medication administration, real-time charge nurse alerting, discharge coordination, and HL7 v2 ADT interoperability — all within a single, manifest-driven, drop-in package.

The current release (v0.9.5) delivers a production-ready core across 23 submodules with a clean PSR-4 PHP architecture designed to integrate with OpenEMR’s evolving module management framework. All submodules are feature-flagged through a central manifest. v0.9.5 adds CMS pay-for-performance quality measure tracking (OP-1, OP-2, OP-5, SEP-1), CMS 2-midnight rule observation billing compliance, and a multi-facility health system dashboard — expanding the product from a single-facility workflow tool to a health system operations platform.

---

Problem & Market Opportunity

Community hospitals, critical access facilities, and behavioral health units running OpenEMR lack access to the real-time clinical operations tooling available in enterprise EHR systems — tools that reduce LWBS rates, shorten door-to-provider times, ensure regulatory compliance for observation status billing and EMTALA transfers, and automate transitions-of-care documentation at discharge.

Key gaps this module addresses:

1. No real-time ED tracking board in standard OpenEMR
2. No structured observation stay management with CMS-compliant 2-midnight rule enforcement
3. No behavioral health boarding workflow or EMTALA transfer checklist
4. No charge nurse alerting layer — overdue tasks, overdue medications, LWBS risk, sepsis risk, and deteriorating vitals go unnoticed
5. No digital medication administration record — paper MARs create compliance gaps and high-alert drug risks
6. No CMS pay-for-performance quality measure tracking — door-to-ECG, door-to-provider, and sepsis bundle compliance are invisible
7. No multi-facility view — health system administrators have no cross-facility census or alert visibility
8. No HL7 ADT outbound feed — downstream systems receive no admit/transfer/discharge events

---

Technical Architecture

The module is implemented as a PSR-4 compliant OpenEMR custom module, installable as a single directory drop-in. The architecture separates public-facing pages from business logic through a clean Controller / Service / Repository layering, with all submodules organized under a shared namespace hierarchy.

• Language: PHP 8.1+, zero external runtime dependencies
• Database: MySQL/MariaDB — 23 tables with safe IF NOT EXISTS migrations
• Frontend: Bootstrap 5 — responsive, no build step required
• Feature gating: JSON manifest — enable/disable any submodule per facility
• Security: CSRF validation on every POST, OpenEMR ACL integration, PRG pattern throughout
• Alerts polling: Pure Web Audio API tone + 60-second auto-refresh, no WebSocket required
• Interoperability: HL7 v2.5.1 ADT over MLLP (TCP) or HTTP — compatible with Mirth Connect, Rhapsody, Azure AHDS, AWS HealthLake

---

Feature Matrix

Clinical Operations

Module	Capability	Status
ED Tracking Board	Real-time episode board with arrival stamping, location assignment, status workflow (Waiting → Roomed → Provider → Results → Ready Dispo → Obs → Closed), BH safety quick-set, obs start with protocol picker, and disposition close.	Production
Episode Intake	Patient search (name, DOB, phone, PID) with new episode creation, arrival mode, ESI entry, and chief complaint capture.	Production
Triage / Vitals	Multi-set vitals capture (BP, HR, RR, SpO₂, Temp, GCS, Pain, Weight) with automatic ESI suggestion, history table, trend indicators, and abnormal value highlighting.	Production
Disposition	Per-episode disposition form capturing code, destination, decision/depart datetimes, admit flag, notes. Timestamps feed throughput metrics. Triggers automatic E-Referral draft on save.	Production
Tasks	Protocol-driven task scheduling (every-N-minutes or at-minute patterns), open task list with one-click completion, overdue highlighting.	Production
Staff Assignments	Nurse and provider assignment per episode. Quick-assign dropdown on ED Board. Assignments management page with JSON endpoint for inline editing.	Production
Episode Timeline	Chronological event stream per episode across 7 data sources: episode events, status history, location changes, vitals sets, tasks, MAR administrations, and e-referral events.	Production

Medication Administration

Module	Capability	Status
MAR	Digital medication administration record. Order placement with high-alert drug detection (23 categories). Auto-scheduling from standard frequency codes (QD through Q12H). PRN orders. Inline outcome recording (GIVEN / HELD / REFUSED / MISSED). Facility-wide overdue panel.	Production
Allergy Checking	Queries OpenEMR lists table before administration. Bidirectional substring match surfaces allergy warning banner on MAR page. Advisory — not a hard block; clinical judgment prevails.	Production
MAR Alerts	Overdue medication slots surface as MAR_OVERDUE alerts. High-alert drugs and doses >30 min overdue escalate to CRITICAL. 15-minute configurable grace period.	Production

Clinical Decision Support

Module	Capability	Status
Sepsis / qSOFA Scoring	Auto-computed qSOFA score from latest vitals every alert cycle. Criteria: GCS < 15 (altered mentation), RR ≥ 22, SBP ≤ 100. Score ≥ 2 = SEPSIS_RISK alert; score 3 = CRITICAL; score 2 = WARNING. Detail shows triggering criteria.	Production
Vitals Deterioration	Per-episode alerts on SpO₂, systolic BP, HR, GCS, and temperature threshold breaches. Stale vitals alerts (>2h ED, >4h OBS). No-vitals-on-arrival alert.	Production
Vitals Scheduling	Auto-schedules VITALS_CHECK tasks on protocol application. Q2H for ED episodes, Q4H for OBS. Protocol-aware deduplication prevents double-scheduling.	Production

Discharge & Transitions of Care

Module	Capability	Status
E-Referral	Discharge referral auto-drafted from disposition. Priority auto-escalated for high-acuity transfers. Clinical summary pre-populated from vitals and chief complaint. Facility Directory fuzzy-matched. Full send/response workflow. Print / Fax Sheet. Supports Meaningful Use transitions-of-care attestation.	Production
Shift Handoff	Printable shift change report: room, ESI, chief complaint, status, last vitals, qSOFA score, next task due, pending MAR count, assigned nurse and provider. Print stylesheet optimised for 8.5pt landscape output.	Production

Observation Stay Management

Module	Capability	Status
Obs Protocol Engine	JSON-defined protocol templates (target hours, runway hours, milestone tasks). Built-in: General Observation and Chest Pain. Protocol editor UI for custom protocols.	Production
Obs Episodes Board	Facility-wide active obs plan list with next task type and due time for charge nurse oversight.	Production
Runway Alerts	Warning when obs window approaches the runway threshold. CRITICAL alert on overrun.	Production
OBS Billing Flags	CMS 2-Midnight Rule compliance. Classifies each OBS episode: Normal / Approaching 1st Midnight / Approaching 2nd Midnight / Convert to Inpatient (≥48h) / Overrun (≥72h). Timeline progress bar with midnight markers. CRITICAL billing alerts on charge nurse dashboard.	Production

Analytics & Reporting

Module	Capability	Status
Alerts Dashboard	Dark-mode charge nurse dashboard polling every 60s. Ten alert types: LWBS risk, overdue tasks, MAR overdue, BH boarding dwell, obs runway, vitals deterioration, stale vitals, no-vitals-on-arrival, sepsis risk (qSOFA), and OBS billing flags. Per-alert snooze. Web Audio API alert tone on new criticals.	Production
Throughput	Daily KPI dashboard: door-to-room, door-to-provider, door-to-decision, door-to-depart averages. BH-specific door-to-accepted and door-to-transport.	Production
Provider Scorecard	Per-provider performance: volume, D2R, D2P, D2D, D2Depart, LWBS rate, obs rate, obs LOS, ESI distribution. Delta vs. facility average, color-coded vs. targets, daily volume sparkline.	Production
CMS Quality Measures	Four CMS pay-for-performance measures: Door-to-Room (OP-1, ≤30m), Door-to-Provider (OP-2, ≤60m), Door-to-ECG (OP-5, ≤10m), Sepsis Antibiotic Bundle ≤3h (SEP-1). SVG gauge cards with EXCELLENT/GOOD/FAIR/POOR tier badges. Episode drill-down with met/missed breakdown. No new tables required.	Production
Multi-Facility Dashboard	Health system view across all registered facilities. Per-facility: census, OBS count, bed occupancy bar, LWBS count, BH boarding count, MAR overdue count, sepsis risk count, avg D2R today. System-wide KPI strip. 60-second auto-refresh.	Production
Exports	CSV export of throughput and transfer data for offline analysis and regulatory reporting.	Production

HL7 v2 ADT Interoperability

Module	Capability	Status
ADT Message Builder	HL7 v2.5.1 ADT messages from episode data. Segments: MSH, EVN, PID, PV1, PV2. Events: A01 Admit, A02 Transfer, A03 Discharge, A04 Register, A08 Update.	Production
MLLP Transport	TCP socket with 0x0B / 0x1C 0x0D framing. Parses ACK AA/AE/AR. Compatible with Mirth Connect, Rhapsody, Ensemble.	Production
HTTP Transport	HTTP/S POST with Content-Type: application/hl7-v2. Optional Bearer token for Azure AHDS and AWS HealthLake.	Production
Outbound Log	Every send persisted with full message, ACK, status, and error detail. Auto-fires A04/A02/A01/A03/A08. Fire-and-forget never blocks clinical workflow.	Production

Administration

Module	Capability	Status
Bed Board	Location management with episode-to-location assignment, occupancy view, and move history.	Production
Locations	Location CRUD with type (ED Room, OBS Bed, BH Room) and status management.	Production
Facility Directory	Receiving facility database for BH boarding, transfer, and E-Referral. Auto-matched by E-Referral to populate destination fax and phone.	Production
Episode Documents	File attachment to episodes with type classification. Soft-delete, served delivery, upload validation.	Production
Settings	Per-facility thresholds: LWBS, boarding hours, obs runway, MAR grace, ESI max, D2R/D2P targets, HL7 transport mode, MLLP host/port, HTTP URL, processing ID.	Production

---

Full Episode Workflow

A complete, unbroken patient journey from door to discharge with every step documented, timed, and optionally transmitted downstream:

#	Stage	Actions
1	Arrival	Episode Intake → search patient → create ED episode (WAITING, HL7 A04)
2	Room	ED Board → Set Room → location assigned (ROOMED, HL7 A02)
3	Triage	Triage → vitals recorded → ESI suggested → qSOFA computed → alerts fire if abnormal
4	Clinical Work	Tasks → protocol tasks scheduled. MAR → medications ordered, administered, allergy-checked, high-alert drugs flagged. Vitals auto-scheduled by protocol
5	Obs Stay	ED Board → Start Obs → protocol applied (HL7 A01). OBS Billing page monitors 2-midnight compliance
6	Disposition	Disposition → code + destination + times saved → E-Referral draft auto-generated
7	Referral	E-Referral → clinician reviews → Mark as Sent → Print / Fax Sheet
8	Handoff	Shift Handoff → printable snapshot with vitals, qSOFA, and pending orders
9	Discharge	ED Board → Close → episode CLOSED, removed from board (HL7 A03)
10	Reporting	Throughput, Provider Scorecard, and CMS Quality Measures all updated automatically

---

Development Roadmap

Recently Shipped

Release	Capability	Date
v0.9.5	CMS Quality Measures Dashboard — four pay-for-performance measures (OP-1, OP-2, OP-5, SEP-1) with SVG gauge cards and episode drill-down	Feb 2026
v0.9.5	OBS Billing Flags — CMS 2-midnight rule monitoring with timeline progress bar and charge nurse billing alerts	Feb 2026
v0.9.5	Multi-Facility Dashboard — health system view with per-facility census, alerts, bed occupancy, and 60s auto-refresh	Feb 2026
v0.9.4	Sepsis / qSOFA Scoring — automatic score from latest vitals; CRITICAL/WARNING alert with criteria detail	Feb 2026
v0.9.4	Shift Handoff Report — printable shift snapshot with qSOFA, pending MAR, and assignment summary	Feb 2026
v0.9.4	MAR Allergy Checking — patient allergy query before every administration; advisory warning banner	Feb 2026
v0.9.3	Episode Timeline — chronological event stream across 7 data sources per episode	Feb 2026
v0.9.3	Vitals Auto-Scheduling — VITALS_CHECK tasks by protocol (Q2H ED, Q4H OBS)	Feb 2026
v0.9.3	Staff Assignments — nurse/provider per episode with quick-assign on ED Board	Feb 2026
v0.9.2	Discharge E-Referral — auto-drafted from disposition with directory-matched destination	Feb 2026
v0.9.1	MAR — digital medication administration with high-alert detection, auto-scheduling, PRN support	Feb 2026

Upcoming

Release	Capability	Date
v0.10	FHIR R4 Resource Mapping — Encounter, Location, Observation, Patient resources from the episode model	Q2 2026
v0.10	Diversion Status — facility-level diversion flag with automatic ADT A09 notification	Q2 2026
v0.10	Downtime Mode — offline-capable local storage fallback for network outages	Q3 2026
v1.0	FHIR Subscriptions — push Encounter status change notifications for FHIR-native downstream systems	Q3 2026
v1.0	Patient Portal Integration — estimated wait time and episode status display	Q4 2026
v1.0	MAR → Discharge Summary — medication list auto-populates E-Referral at discharge	Q4 2026

---

Why OpenEMR

1. 100+ million patients worldwide on OpenEMR deployments
2. 35,000+ facilities across 100+ countries — strong foothold in critical access and community hospitals
3. ONC-certified, HIPAA-ready, actively maintained with a large contributor community
4. No per-seat licensing — dramatically lower TCO vs. Epic, Cerner, or Meditech
5. Module marketplace emerging — first-mover advantage for institutional workflow tooling

---

This document reflects the v0.9.5 release dated February 2026.

Re: 02/23/2026 Updated project Summary, Roadmap and Full Episode Workflow.
Re: 02/25/2026 Uploaded a workflow summary of each submodule see here: New Institutional Module: Is it time? - #7 by sjpadgett

[sjpadgett (Jerry P)]

I think this points out well how important previous work for Fax/SMS/Email communications and the pending DORN module fits here.
We have Institutional billing already in place since at least v6.0.0.

[sjpadgett (Jerry P)]

Hi Everyone!
I wanted to share a few screenshots and announce I’ll be sharing a demo link soon.
I’d also request for those of you contacting or thinking to contact me via email to please also share questions and/or encouragements here so others in the community will glean answers to the same questions or concerns. However please, either way I’m always happy to see the emails.

I’ve been advancing MAR’s and finishing up

• Nurse / Provider Assignment Adding an assigned provider and assigned nurse to the episode (with a quick-assign dropdown on the board) feeds the Provider Scorecard more accurately, enables “my patients” filtered views, and is something every clinical audience immediately asks about.
• Sepsis / Early Warning Scoring The vitals engine already collects HR, RR, BP, Temp — the four SIRS criteria. A qSOFA score (altered mentation via GCS, RR ≥ 22, SBP ≤ 100) is three fields already captured. Auto-computing this on vitals save and surfacing a SEPSIS_RISK alert on the dashboard for a strong clinical story. It’s roughly the same pattern as VITALS_DETERIORATION alerts already in Alert Service. I’m finding from VA charge nurses I’ve spoken with how important alert service is.
• Shift Handoff Report A printable page (or PDF) of all active episodes at a given moment — current room, status, ESI, chief complaint, last vitals, next task due, MAR pending doses. Nurses print this at shift change. It’s a natural extension of the ED board table into a static printable format, and it’s one of the first things a CNO asks for from module.
• Allergy Check in MAR Before recording GIVEN, query OpenEMR’s lists table (where allergies are stored) against the drug name. Surface a warning — not a hard block — if there’s a match. This is the one MAR safety feature that would be expected in any clinical setting.

This is fun!

[sjpadgett (Jerry P)]

In a hurry to get to FHIR! Forgot to show work on reporting so a couple screenshots
I have started billing related integrations and am in the process of deciding if I want to pull my institutional billing, UB04 etc., the foundation sponsored several years ago into a module.

A structural part of the institutional module that I must address soon is Context Management covering various care settings. This module would represent a follow through of the Context Manager I introduced in OpenEMR version 7.0.4 which I meant to align OpenEMR’s user interface with real-world care settings thus in tern allowing Institutional workflows (or any module) to present the right setting for the right role at the right time without cluttering the experience for everyone else.

So much to do and this is why community support is so important. Workflow improvements can not become stagnant and must become much more progressive in the project. This takes cohesion and planning where the community becomes the backbone as what the project looks like five years from now. Preach Jerry!
Sorry I’m passionate concerning OpenEMR!

I’ve loving what I’m doing but sure could use some developer help.

[htuck (htuck@mi-squared.com)]

Too kool for words, @sjpadgett ! This singlehandedly propels OpenEMR into the big, big leagues.
I would love to play with it though at this point in my life I could only do a couple hours testing a week.
But I would love to be able to get into your demo and play with it.

Am following this thread; hope to read more fun stuff soon!
Best- Harley

[sjpadgett (Jerry P)]

Hi Everyone watching. To follow up, today I get to inform progress on Context Management for care setting module will run in.
I kick myself for not implementing CM from the start because it completely had to touch most all of project but I muddled through and have it working.
There is still the on-going issue in core of any top level menu changes require a restart.

Now come on, how cool is this!

I’m still having fun however, this one not so much!

[sjpadgett (Jerry P)]

I’ve decided that I will defer adding FHIR because from my research most all hospital are still using HL7 middleware which really disappoints me because FHIR is superior.
Since I developed and released timed one-time tokens in use by portal document notifications directing patients to a portal card or document, I’ll be able to implement related person portal log in. This is ideal for such things as admit/history documents required by patient.
This is going to be my next and last submodule.

I find it understandable that I haven’t received any ideas or suggestion for module workflow needs since, of course, the community isn’t in this space. But I hope folks find this topic interesting and/or informative and follow along.

I attached a good summary document of what, how and why each submodule fits the various care contexts. It’s my best attempt yet at describing the module.

I plan to have my demo site up by Friday or Saturday and will announce here.
usage_submodules_summary.docx (27.1 KB)

[mkm1971 (Khalaf)]

That’s amazing. I do have a few recommendations: based on the ESI, we could use color-coding (e.g., red, yellow, green, etc.). Also, it would be great if the settings could be customizable to align with other triage standards as well — for example, the Manchester Triage System

[sjpadgett (Jerry P)]

Very helpful post, thanks @mkm1971
I’ll take under advisement and do some research.

[sjpadgett (Jerry P)]

On color coding: ESI acuity coloring is already live on the ED Board (ESI-1 black, ESI-2 red, ESI-3 orange, ESI-4 teal, ESI-5 gray), following the standard clinical convention.
On triage standard customization: this was great feedback, especially for international deployments. The Manchester Triage System is the dominant standard outside North America.
Therefore I’m deferring portal related person to bump this up in priority, like now!
Feel free to comment on other difference you can point out. I’m sure once the demo is up it’d be easier to determine.
Thanks again.

[mkm1971 (Khalaf)]

@sjpadgett just to be on safe side black means dead as a univirsal color becuase in my practice we use ESI and red means 1 2 amber 3 orange 4 teal or green 5 can be green.

[mkm1971 (Khalaf)]

what you can do is if we can set a function to be able to change the color based on practice. so that it is eaiser for users to change stuff.

[sjpadgett (Jerry P)]

Yep, what happens is it becomes part of the care context that persists for facility in this case. So part of the context is that MTS support is implemented and facility-configurable, with CTAS included for Canadian deployments as well.
I am going down the road that it be facility selectable and since module is multi-facility this makes sense, but I don’t know how this would be handled in real world. Tackling this feature does provide an opportunity for expanding context manager and defining the granularity level I support.
To start I’m using the standard colors and will circle back to color being selectable.

[sjpadgett (Jerry P)]

[sjpadgett (Jerry P)]

@mkm1971

we use ESI and red means 1 2 amber 3 orange 4 teal or green 5 can be green.

Are colors standard our whatever users like? We have picker in calendar set up in config. Is that worthwhile to allow user to pick color in setup’s acuity card?Here are the default colors:

[sjpadgett (Jerry P)]

While updating MAR I thought it be an easy feature to allow users to update and pick colors for the Acuity Badge Colors but lol, I should know better!

Here’s what I came up with. I don’t know how important this is but I can see how it would improve UX.

I have also put up a demo site that defaults to all submodules turned on with plenty demo data for full workflows. If anybody would like access, please PM or email me and I’ll get back to you asap with you site and login credentials.

[sjpadgett (Jerry P)]

Updated project summary word document. Very informative and helpful when using demo server.

usage_submodule_summary_v0.10.0.docx (25.6 KB)

[htuck (htuck@mi-squared.com)]

Hi Jerry-
Thx, and could you send me the demo login pls?

• HT

[censon (Simon Halliday)]

Very impressive. Would I be able to get access to demo server?

[sjpadgett (Jerry P)]

A quick notice. I’ll be updating Demo at 9pm EST. More nurse staffing.
Also, I PM’ed everyone that asked for demo access just so ya know.