Started the Assisted Living Care Domain to companion with Behavioral Health Domain.
Screenshot gives a decent overview for now. Let me know if I can answer any questions.
Mostly now Dashboard ran to help with context management.
Reading the ‘usage_submodule_summary_v0.10.0’ linked above.
I didn’t read every group/ submodule but it’s clear to me that fundamentally they’re well concieved and cover what’s important. Obviously the specifics will get adjusted when they meet reality.
Just a few things that occurred to me:
- there’s so many moving parts here, and so much overlap with the current OEMR’s features that it’ll be v important to establish a formal vocabulary for consistency and clarity. E.g., what is the ‘episode’ used here /vs/ the current OpenEMR term ‘encounter’. Not clear that/ if they’re the same thing. This is one of the failures of the existing OpenEMR documentation, that having different names for the same elements gets in the way of learning and using the application.
- As far as the features are concerned, they’re really on the mark but it appears that plenty of overlap will exist between the new features and the current OpenEMR features, so will have to distinguish their scopes clearly. Are these new features or reorg/ re-branding of existing functionalities? E.g., ‘02 Triage - drives labs’ etc, is this going to be an expansion of the existing ‘status’ feature as shown in the flowboard etc, or something new, leaving the ‘status’ dropdown as it is?
- group c - med management - this will conflict in many ways with commercial 3d party eRx solutions. Either by duplicating the features or requiring interaction with them. Going to have to map out the interactions v carefully!
Will run through the demo later in the week.
Best- Harley
Thanks @htuck
I need to check which demo I assigned to you because I have one that is fully seeded with all data required for every Care Domain.
I’m current restructuring file management to get on board with the domain care concept. Will be done later today.
I’ll PM you.
Hello folks,
I’ve been striving to get a BETA release together. I supplied workflow documents so you can run through how this module works. If you want to demo, send me an email or PM and I’ll give you access.
assisted-living_workflow_guide.docx (26.9 KB)
Maple Grove Assisted Living — Resident Workflow Guide (14 sections, green theme)
Follows all five demo reidents pulled directly from your seed data:
- Eleanor Hartwell — TIER 3 memory care, SNF transfer pending to Springfield Memory Care
- George Calloway — post-hip arthroplasty TIER 2, home discharge planned at day 60
- Ruth Okonkwo — COPD GOLD 2, TIER 1, inhaler adherence management
- Harold Steinberg — Parkinson’s H&Y 3, fall this morning, hospital eval pending
- Dorothy Vasquez — CHF + T2DM, weight gain alert, CHF decompensation eval
Covers every submodule: Resident Board flags logic, Intake (with the form_encounter guard), ADL MDS 3.0 scoring table, Morse Fall Scale history tables, MAR with the furosemide medication error incident, Care Plans (FHIR/CCDA note), Shift Handoff snapshot with red-highlighted severity rows, all five discharge pathways, and the full feature flag reference table.
obs_acute_workflow.docx (27.7 KB)
Springfield General Hospital — Acute Care & Observation Stay (14 sections, blue/teal theme)
Purpose-built for the ED_ACUTE and OBS_STAY domain contexts:
- ED vs OBS context comparison table (audience, features, HL7 events)
- ESI level 1-5 definitions with color-coded rows and module actions
- Automated alert sources: qSOFA sepsis screen, LWBS risk, overdue tasks, OBS billing flags
- Two-midnight rule threshold table (NORMAL → APPROACHING_1 → APPROACHING_2 → CONVERSION_DUE → OVERRUN) with a live sample billing view
- OBS protocol engine (GENERAL_OBS, CHEST_PAIN, custom) and task runway generation
- Acute MAR with heparin high-alert dual-verification note
- Full HL7 ADT event map (A04, A01, A08, A02, A03, A11)
- BH boarding extension (legal status, EMTALA, placement tracking)
- CMS quality measures (OP-18b, OP-20, troponin TAT, LWBS rate)
Update to v0.16.0
Finished some core integrations as part of this version:
- Facilities Multi-Facility support
- Users
- Patient data
- Care plans
- Care Teams
- Clinical Notes
- Interventions
I spent considerable time on workflow navigation of current care context. So if Assisted Living context then all page scopes pertaining to the context is available on the page. Point is that the user should never have to go to top level menus. Eventually I hope to extend to the task manager so when working a task related buttons to achieve the task are highlighted and task checklist gets updated as summary towards task completion.
Next immediate core interaction to be done is Prescription ↔ MARS which leads to if I’m going to develop an eRx submodule. TBD…
Since I now have the Domain Care concept structurally in place I can start mapping workflow variations for locales such as US, EU, Asia, Africa etc. This will require considerable research and expertise and if done right a domain needs can be easily expanded over time.
If anyone can point out any differences on how institutional is handled across international locations I’d greatly appreciate the input. A couple screen shots for Assisted Living relationship with core
Thanks to all of you giving me private encouragement.
2 Likes
Hi @sjpadgett
Looking good!
Myself, for now I’d leave for later an eRx submodule since what we have at the moment does work. I mean I don’t know anything about weno’s integration but Ensora has some data exchange habits w/ OpenEMR that seem tricky to me… though o’course I’m not a dev and don’t know the code of the interface.
- HT
Sorry @htuck I meant eMARS.
MAR is pretty much done.
Hot dang this is fun!
On the whole it looks encyclopedic. V complex but as soon as you get the screen logic works pretty good.
-
At this point I’m seeing little UI things like, when you select a time in the date/time picker there’s no positive action to make it so- just clicking outside the ctrl sets it. Which seems prone to serious error.
-
I take it the definition of ‘episode’ would be close to ‘stay’ or ‘admission’?
-
Have not been able to check the PRN admin function to see if it prevented doses timed too closely. When I tried to give a PRN med it did this:
-
At some point while operating the Inst. Mod the OpenEMR header disappears showing only the Inst. tab contents (no screenshots right now). I haven’t been able to find precisely how to get into, or out of, that display
-
which begs the question, how integrated is the Inst. module going to be with the ‘Clinic’ (as it were) OpenEMR ? Will providers be able to look in the pt’s OpenEMR record and see notes, procedures etc that they had as inpatient?
I’m having fun playing with this demo; at the moment practicing navigating between contexts and workflows. Would it be possible to get another test user so I can compare entries made by one as viewed or edited by the other?
Thanks again- HT
2 Likes
I was wondring if we can implement The MAR (Medication Administration Record along with barcode wristban scanning simialr to Cerner Bridge Medical.
2 Likes
Sorry, I’ve been out of it past couple days. Thanks for report and I have addressed MAR issues but I haven’t put up on demo yet. I have openemr care plan available in module and can create new care plan on either side but I’m thinking to restrict that care plans and clinical notes can only be managed in openemr.
If you generate a report or print it will open a new window or tab. You should be able to see and go back to openemr main tab. Still I don’t like and have been fixing as I come across i.e. new tab in openemr.
PRN is fixed plus some other MAR issue but I’m moving a little slow so give me til Monday and I’ll have demo updated.
1 Like
Hi @sjpadgett
I will play with the PRN and other things later, thx!
I see my demotester1 acct is an admin so I took the liberty of adding an extra user, ‘DemoUsr1’. Passwd in the usr profile.
Seems like a good design decision to make individual data and records like a care plan and a person’s clinical notes be controlled from their OpenEMR record. Will it be so that you can click on the pt name (or PID) in Inst. Mod and it brings up the OpenEMR pt record? What other capabilities do you think should be accessed through the pt record instead of the Inst Mod?
I’m thinking that anything needed in the Inst Mod that is seen in the Pt Portal should be accessed through their OpenEMR record’s portal controls. E.g., setting up D/C planning or gathering new docs.
More later!
- HT
Hi All,
Okay I’ve been trying to get all my submodules(30+) correctly following user role of care contexts and navigational workflow scopes for context correct in UI’s.
I’ve defined each care context as user roles for general institutional requirements except Assisted Living which will run on it’s own as an application with ability to add on other submodules if needed.
I have support to read and list care plans/clinical notes and have reasoned I should integrate MAR with openemr prescriptions. Vitals will be mirrored. Patient is integrated but I still need to add the niceties for things like patient name/age etc. and the various lookups common in openemr.
I could use some feedback on what would be best needed from openemr integration POV.
Inpatient Hospital Stay (INPATIENT_STAY) The acute inpatient setting covering the full admit → stay → discharge etc. for med/surg, telemetry, and general inpatient units. The admitting workflow uses intake, ADT Lite, bed management, and staff assignment to place the patient on the appropriate unit with the correct attending and nursing team. Active stay management surfaces the MAR, tasks, care plan, clinical notes, care team, episode documents, alerts, timeline, throughput, and handoff — the full longitudinal documentation toolset that distinguishes inpatient from an ED visit. The ED Tracking Board is included as the facility-wide census view since it shows all active episodes regardless of type, serving as the inpatient floor board until a dedicated whiteboard is built. The discharge arc uses disposition, e-referral, and transfer tracking to coordinate SNF, rehab, or home discharge. CMS quality measures and the provider scorecard are surfaced for attending physicians and case managers monitoring length-of-stay compliance and outcomes. Triage, BH Safety, BH Boarding, and all OBS protocol submodules are intentionally absent — those tools belong to their own contexts. Primary users are admitting nurses processing new arrivals, floor nurses managing the active stay and MAR, hospitalists documenting clinical notes and care plans, and case managers tracking LOS and arranging post-acute placement.
Emergency Department (ED_ACUTE) The acute emergency care setting for a hospital or freestanding emergency department, focused on real-time patient tracking from door to disposition. The ED Board drives the workflow — patients arrive, are triaged, assigned to a bed and provider, worked up, and dispositioned (admit, discharge, transfer) within a single high-acuity episode. The module surfaces intake, triage, MAR, tasks, BH safety screening, transfer tracking, and e-referral, along with the tracking board, alerts, timeline, and handoff tools. Primary users are the charge nurse managing the board, triage nurses processing new arrivals, and ED providers managing active patient workups.
Observation Stay (OBS_STAY) The hospital-based observation setting for patients who do not meet inpatient admission criteria but require monitoring beyond an ED visit — typically governed by two-midnight rule compliance and payer-specific protocols. This context adds the Observation-specific submodules (OBS Episodes, Protocols, Billing, OBS Start Picker) and CMS Quality reporting alongside the shared MAR, tasks, throughput, and disposition tools. The workflow centers on protocol assignment, level-of-care documentation, and timely discharge or inpatient conversion. Primary users are hospitalists managing observation orders, OBS-dedicated nurses, and case managers monitoring length-of-stay and billing status.
Behavioral Health (BH) The psychiatric and behavioral health setting for patients presenting in mental health crisis, requiring safety evaluation, boarding management, or coordinated placement. The context surfaces BH Safety screening, BH Boarding status tracking, and transfer/placement coordination alongside the standard intake, triage, MAR, and disposition tools. The emphasis is on safety documentation, bed search, and managing patients who may be boarding in the ED pending an inpatient psychiatric bed. Primary users are BH clinicians conducting evaluations, social workers managing placement and discharge planning, and boarding coordinators tracking psychiatric bed availability across the facility directory.
Operations & Admin (OPERATIONS) A supervisory and administrative lens for nursing directors, department administrators, and quality officers who need cross-facility visibility without the clinical workflow clutter. This context exposes the Command Center, throughput analytics, provider scorecard, multi-facility views, HL7 ADT configuration, admin exports, and system settings — the tools used to manage the module rather than treat patients. It intentionally omits most point-of-care clinical features, keeping the interface focused on operational oversight. Primary users are nursing directors monitoring department performance, administrators configuring the module, and quality officers running CMS quality and throughput reports.
Assisted Living (ASSISTED_LIVING) The long-term residential care setting for assisted living facilities, memory care units, or skilled nursing environments where residents have ongoing, census-based episodes rather than acute visit episodes. The workflow flows from the Resident Board through daily ADL charting, care plan management, vitals, fall risk reassessment, incident reporting, and the 5-day rolling MAR — all built around a longitudinal residency model rather than an acute encounter. Shared submodules like tasks, handoff, alerts, and e-referral are also surfaced for care coordination. Primary users are care aides documenting daily activities and medication administration, LPNs managing orders and care plans, the AL Director overseeing the census and compliance, and activity coordinators managing resident programming.
Full Access (FULL) Not a care setting — a bypass mode that disables all context filtering and surfaces every enabled manifest feature and menu group simultaneously. Intended for super-users, module developers, and system administrators who need unrestricted access during configuration, testing, or troubleshooting. Because it is a display lens rather than an access control boundary, it does not grant permissions beyond what a user’s OpenEMR ACL already allows; it simply removes the context-driven menu and feature filtering. This is the default context if no preference has been saved for a user/facility combination.
1 Like
@sjpadgett IMO, your default modules for each context do seem right but I am continually amazed how different facilities will perform the same workflows in their own idiosyncratic way. As long as the modules are easy to swap around to match whatever weird-o workflows some place wants to use, yer gud. IMO!
Slow moving is contagious- I hope to play with the PRN and other toys real soon here.
I don’t know a thing about how the eRx (‘NewCrop’) interface is coded but would this be a good time to take care of some of its idiosyncracies? Such as its data passing to/ from the OpenEMR Prescription module so it’ll display useful histories and current meds. There’s more; we can talk 
- Harley
First, I decided to clone the MAR submodule into a separate module and give to the community in that form once my submodule is finished.
For NewCrop the last time I looked at it, it appeared it’s integration was okay where NewCrop was handling medications and history however I don’t recall how much of this is saved to openemr.
Today I started the integration with openemr prescription. The ‘e’ part of MAR’s gets a little complicated but I’m working through it. From the MAR workflow perspective, OpenEMR mainly provides the pharmacy layer. The MAR module manages the facility medication workflow. A provider creates a medication order in MAR, OpenEMR’s Prescription/inventory capabilities can act as the pharmacy layer to verify and dispense the medication, and the MAR system then resumes control for administration.
The electronic “e” part of eMAR confused me but comes from the system automatically generating medication administration schedules and recording each administration event. Nursing staff see scheduled medication passes and document outcomes such as administered, held, refused, or missed.
Basically:
Medication Order (MAR)
→ Pharmacy Verify / Fill / Dispense (OpenEMR)
→ eMAR Schedule Generated (MAR)
→ Nurse Administration
→ Administration Record (eMAR)
In this model, OpenEMR provides the patient, medication, and pharmacy infrastructure, while the Institutional MAR module manages the eMAR scheduling and administration workflow. This keeps the existing outpatient prescribing system unchanged while enabling facility (idiosyncratic ) workflows such as assisted care, observation units, and small hospital medication administration.
Short of referencing existing prescriptions storage schema a notification hook from an event or an event for the MAR medication request to ease user work, submodule can stand on its own.
Working through the demo you can see much of all this is done except the med order needs further work(working now).
I really appreciate all of your input @htuck I’ll let you know when the ‘e’ part is ready.
1 Like
I’ve only tested from Resident Board full MAR but is same for other roles.
- Open MAR for an episode where the patient has active prescriptions in OpenEMR → med-rec panel appears above Place Order form
- Each prescription row shows drug, dose, route, frequency badge (BID/TID/PRN etc.), prescriber name
- PRN drugs show amber badge, scheduled drugs show grey
- Patient with no active prescriptions → grey info banner instead of table
- Check one or more pending rows → “Activate Selected” button enables
- “Select All Pending” checks all unactivated rows at once
- Submit → page reloads, activated drugs appear in MAR grid with 24h slots
- Re-open panel → activated rows show green “✓ On MAR” badge, checkbox is disabled (idempotent)
- Print MAR (
?print=1) → med-rec panel is hidden (no-print class) - AL episode → back button says “
Resident Board” - ED/OBS/BH episode → back button says “
ED Board”
I still need to check in on openemr prescription status but I am using openemr drug inventory to dispense.
I’m working STAT orders and Shift summary / administration report. Holding off on narcotics for more research.
Hi Everyone,
I’ve been hard at work on the eMAR/MAR submodule and am very close to start cloning in to a separate module for the community to have as an option.
The following is a summary and I still could use any feedback, thank you.
oe-module-institutional — MAR / eMAR Supported Functionality
Module version 0.16.0 · PHP 8.1+ / OpenEMR 7.0+ · Posted for community review · March 2026
The MAR submodule provides a full medication administration record workflow across
Emergency Department, Observation Stay, Behavioral Health, Inpatient, and Assisted
Living contexts. All write operations are routed through a single MarService
boundary — nothing writes directly to the MAR tables from controllers or views.
| Scheduled frequencies | 11 — Q1H · Q2H · Q4H · Q6H · Q8H · Q12H · QD · DAILY · BID · TID · QID |
| High-alert drug keywords | 26 — auto-detected at order time, stored on order row |
| Structured hold reasons | 10 — NPO · HR/BP/RR/SpO2 low · Lab pending · Level high · Refused · Physician hold · Not available · Other |
| MAR contexts | 5 — ED · OBS · BH · Inpatient · Assisted Living |
Order management
- Place scheduled medication order — drug name, dose, unit, route, frequency, instructions
- Place PRN (as-needed) order — separate section below scheduled grid, always requires Give PRN action
- STAT orders — creates an immediate slot at time of order then generates the normal rolling schedule; STAT flag stored on
oei_mar_order; disabled automatically when frequency is PRN - High-alert auto-detection — keyword match at order time, stored on order row, cannot be removed after placement. 26 keywords: insulin, heparin, warfarin, coumadin, morphine, hydromorphone, fentanyl, oxycodone, methadone, ketamine, vancomycin, gentamicin, digoxin, lithium, potassium chloride, KCl, hypertonic saline, 3% NaCl, concentrated, epinephrine, norepinephrine, dopamine, dobutamine, nitroprusside, nicardipine, amiodarone. Checkbox override available for trade names and compounds not auto-detected.
- Extend slot window — adds future administration slots (8h / 12h / 24h / 48h / 72h) from the last existing slot
- Discontinue order — voids all PENDING slots, sets order status to DISCONTINUED with timestamp and user ID
- Medication reconciliation — imports from OpenEMR
prescriptionstable withrx_idtracking; idempotent; already-imported rows shown as disabled with On MAR badge - Allergy checking — reads OpenEMR
liststable (type='allergy'), displays alert banner for any active order matching a documented allergen with severity badge
Administration recording
- Record administration on PENDING slot — outcome, given-at datetime, dose given, unit, route, site, lot number, note
- Outcomes: GIVEN · HELD · REFUSED · NOT_AVAILABLE · MISSED — each with distinct color badge in grid
- Structured hold reasons — 10 reason codes shown when outcome is HELD; stored on administration row
- Amend completed administration — warns nurse that original will be preserved; stamps amendment timestamp and user in note prefix
- Give PRN dose — creates a new administration record; captures dose, unit, route, site, lot, note, and given-at datetime
- Waste and witness documentation (new) — shown only on high-alert orders; witness selected from full staff list; waste amount and unit stored on administration row; displayed in history grid; witness name resolved by JOIN on
userstable - Two-nurse co-signature for high-alert administrations (new) — required on any GIVEN +
is_high_alertrow; second nurse selects their name from dropdown and clicks Co-Sign; DB guard:WHERE outcome='GIVEN' AND is_high_alert=1 AND co_sign_user_id IS NULL— idempotent, cannot overwrite existing co-signer; history grid shows co-signer name and timestamp, or red “Needed” badge when absent - Nurse PIN re-authentication before commit (new) — intercepts
record_admin,amend_admin, andgive_prnform submissions; modal challenges nurse to enter OpenEMR password, verified server-side viapassword_verify()againstusers_securetable; form only submits after successful verify; graceful fallback if Bootstrap CDN is slow; does not apply to co-sign
Administration history grid
- Columns: Scheduled · Given At · Outcome · Hold Reason · Dose · Site · Lot # · Nurse · Note · Witness · Waste · Co-Sign · Actions
- High-alert rows highlighted in amber; HA badge on scheduled time cell; Witness/Waste/Co-Sign columns hidden in print mode
- Nurse name resolved by JOIN on
users— never shows raw user ID - Patient name in episode header and print header via
oei_fmt_patient()— no raw PIDs shown to users
Facility-wide view
- Overdue / pending medications across all active episodes — lists episode, patient name, drug, scheduled time
- Overdue age badge (new) — red “Xh Ym late” computed from scheduled datetime; shows 0–59m as minutes only, 60+ as hours and minutes
- Patient names batch-fetched via
oei_patient_names()— single query, no per-row lookups - Shift summary report (
shift_summary.php) — 7a–7p day / 7p–7a night shift, auto-detects current shift, navigable by date; groups by episode then order; waste badge on high-alert rows; patient names resolved; printable
Assisted Living MAR
- 5-day rolling window calendar grid (
al_mar.php) — standing orders as rows, dates as columns, keyboard-navigable by offset - Record administration via modal (GIVEN · HELD · REFUSED · OMITTED) and amend completed records
- PRN medications in separate section below the scheduled grid
- Waste and witness documentation on high-alert orders in administration modal
- Two-nurse co-signature display in the 5-day grid and record modal
- All writes delegate to shared
MarServiceviaAlMarRepository— high-alert detection and scheduling rules apply equally in AL context - Context-aware back button — AL episodes return to Resident Board, all other contexts return to ED Board
Print and reporting
- Printable episode MAR (
?print=1) — PIN modal, action buttons, and Witness/Waste/Co-Sign columns suppressed for print; compact 8.5pt grid font - Shift summary report with day/night toggle, date picker, episode grouping, waste badges, and patient names
Architecture notes
- Write boundary —
MarServiceis the sole write path for all contexts. Controllers and views never write to MAR tables directly. - Dual namespace — Every service/repository exists in both
Shared\andSubmodule\namespaces, kept in sync.Sharedis canonical. - JSON endpoints —
verify_pinruns before$controller->handle().ob_end_clean()clears the bootstrap buffer before any JSON response header is sent. - Form routing — All POST forms carry explicit
action=attributes. Required for correct routing in OpenEMR’s iframe environment. - CSRF — All POST actions verify
csrf_token_formviaCsrfUtils::verifyCsrfToken(). Token collected once at page scope. - PRG pattern — All POST handlers redirect after processing. No double-submit risk on browser back/refresh.
Not yet implemented
- Drug-drug interaction checking — requires an external formulary or interaction data source;
AllergyService(allergen name matching) is the current safety layer - Standing order auto-renewal —
extendOrderSlots()exists and is callable; a scheduled/cron trigger is not yet built - BCMA barcode scanning — intentionally deferred; out of scope for current deployment target
- Write-back to OpenEMR
prescriptionstable — intentional design decision; MAR is a separate accountability boundary; Level 3 write-back is not planned
I think this topic is becoming too large to be practical so I may start a new topic to document the new eMAR stand alone module. Thoughts?
Hi @sjpadgett
looking at the demo (Sorry about that, Chief!)
user ‘demo’
Just glancing at the MAR Operation this AM, I realize a lot of these things are finishing touches.
QHS - is missing; seems important to have
QD - is this meant to be different from Daily?
Aspirin (for eg)- no cancel btn, stuck here can’t go back to the initial MAR display. D/c works, is that what’s intended to be used?
also- Field labels will be added, right?
the ‘Place Order’ panel to add a new order has default info (from the latest? rx) prefilled.
also- no cancel
the txt area labels are near impossible to see in some display themes/ styles
the frequency space would not offer other freqs, could only overwrite the val in the box.
also I couldn’t get it to actually add an order- clicking the blue ‘Place Order’ came back to the MAR screen but the ord was incomplete
what is LDA for a site? Consider a dropdown with the accepted abbreviations so the nurse doesn’t have to manually type the site each time.
High-alert auto-detection - possible to customize items, right?
Two-nurse co-signature for high-alert administrations - Again, may vary by house policy- don’t make it required on all Hi-Alert meds
I could be out of touch with MAR workflows in the past 20 years… but do they really require manual entry of the Lot# every time a med is given?
Nurse PIN re-authentication before commit - what does that make the med admin workflow?
I see how it replicates the authorization function of manually initialling the med’s administration but it’s a lot more work to enter the OEMR usrname than a quick init.
I imagine the browser’s habit of retaining the passwd would make this simpler- just click in the passwd txt area and if it’s working right that user’s passwd will be inserted. But if the nurse is using a different computer/ browser where their passwd is not saved on? We’re presuming dedicated computers for med admin? Just thinking in terms of how easy it’d be to make an error signing off a med, and what would be required of the facility’s IT folks and regular users to make it work right.
Any way- great work so far, you’re changing the world!
1 Like
Hi @htuck and All,
Yep I haven’t spent a lot of time on UX but am aware. Note that most panel slide ins are button toggles. Like Place Medication Order button toggles open/close. Saves on number of buttons.
I am working today to follow up on MAR UX but last couple days I wanted to get the Inpatient/Hospital Stay census board workflows working well enough that medication handling flows make better sense and easier to navigate.
I’m very happy so far with the Assisted Living and Hospital Stay contexts. Both are getting close to production as far as necessary requirements.
However now comes the hard work of completing openemr integration such as various useful lists for dropdowns. Need to make decisions on how to finish integrations of encounters, care plan, clinical note and procedures.
I create encounters on Admits/episodes(basically an encounter) but need to add type etc.
Care plans are shown in module but currently only allow create in openemr however module can create its own singular version.
Anyway, so much going on with contexts still not setting correct workflow to its role/context.
Next biggie for inpatient is importing hospital reports (HL7 ORU, CCD, or PDF) into the episode document structure.
So I bumped to v0.17.0 and added new Inpatient submenu in Full access context for testing. Here are a couple screenshots that I hope shows the discipline.
Oh! Theme is tricky. OpenEMR will be releasing BS 5 soon and would love to utilize, however while I support BS 5 I need to think about interfacing with prior openemr versions. For now best to test using modules light theme. Btw, I am thinking about moving to Tailwind CSS.
1 Like
Hello Folks,
For those who’ve been following this thread I’ve reached a genuinely meaningful milestone. Both the Inpatient and Assisted Living tracks are clinically navigable end-to-end, the eMAR is production-complete for floor nursing use, and a new Institutional Quality Dashboard ties everything together with live readiness scoring. Here’s a review and summary from my AI team of what the module can actually do today.
v0.17.0 Project Status
OpenEMR 7.3+ · PHP 8.1+ · Manifest-driven feature flags
Tracks: Emergency Department · Observation Stay · Behavioral Health · Assisted Living · Inpatient Hospital
Emergency Department & Observation Stay
The ED Board remains the module’s flagship view — a dense 15-column live census covering every active episode at a facility. Nurses and providers see room assignment, triage acuity (ESI 1–5 with color-coded badges), chief complaint, time-on-task metrics, protocol status, assigned staff, and a full action menu per row. Every column is the result of a real database query, not static scaffolding.
Triage captures a full vitals set with ESI auto-suggestion based on those vitals, supports re-triage sets numbered sequentially on the same episode, and feeds the alert engine directly.
Observation Stay has its own protocol engine supporting named clinical pathways — chest pain, COPD exacerbation, sepsis bundle, stroke, opioid overdose, pediatric fever, and a general OBS catch-all. Each protocol carries a target-hours clock and a runway warning threshold. The system tracks where each patient is in their protocol timeline and fires alerts when the runway is shrinking.
OBS Billing generates the CMS Two-Midnight Rule eligibility assessment for each observation episode, including medical necessity language, ready for the billing team to review before status conversion.
eMAR — Medication Administration Record
This is the most feature-dense component in the module and it is now production-complete for floor nursing workflows.
Ordering: Nurses can place scheduled, PRN, and STAT orders. STAT creates an immediate administration slot plus the rolling schedule simultaneously. Medication reconciliation imports active orders directly from OpenEMR’s native prescriptions table, with idempotent duplicate detection so running it twice is safe.
High-alert detection is automatic — a keyword list covering insulin, heparin, warfarin, opioids, vasopressors, concentrated electrolytes, and antiarrhythmics flags orders at the time they are placed. The flag is stored on the order, not recomputed at administration time.
Recording administration: Each scheduled slot shows a Record panel with outcome (Given, Held, Refused, Not Available, Missed), actual dose/unit/route if the nurse deviated from the order, injection site, lot number, and a nurse-supplied or back-documented timestamp. Amending a previously completed slot creates an auditable correction note.
Hold reasons are structured, not free-text: NPO, HR too low, BP too low, SpO2 too low, lab result pending, drug level too high, patient refused, physician order to hold, not available, and Other. The hold reason is stored separately from the administration note.
Waste and witness documentation appears automatically on high-alert administration rows — waste amount, waste unit, and a witness dropdown populated from active staff. This is not optional on high-alert drugs.
Two-nurse co-sign is fully implemented. High-alert administrations that have been recorded as Given show a co-sign status column. If a second nurse has co-signed, the column shows their name and timestamp in green. If not, it shows a red “Needed” badge. The co-sign action is a separate POST that enforces the GIVEN+high-alert guard before writing.
Nurse PIN re-authentication is wired. Before a high-alert administration can be committed, the nurse is required to re-enter their OpenEMR password via a modal PIN challenge. The verification hits the users_secure table directly and returns a JSON result without exposing credentials to the view layer.
Allergy checking runs against OpenEMR’s native allergy list (the lists table, type=‘allergy’) using bidirectional substring matching — drug name contains allergen, or allergen contains drug name. Warnings surface at the order placement step. It’s advisory, not a hard block, because clinical judgment prevails.
Shift summary gives charge nurses a day/night shift view grouped by episode, with waste badges and high-alert highlights for end-of-shift reconciliation.
What is not yet built in the MAR: drug-drug interaction checking, standing order auto-renewal, and BCMA barcode scanning (the last of these is explicitly out of scope for v1).
E-Referral
E-referral auto-drafts when a disposition is recorded. The service reads the disposition code, maps it to a referral type (Discharge, Transfer, or BH Placement), matches the destination name against the facility directory to pull fax number, phone, and address automatically, builds a reason-for-referral narrative, writes a clinical summary from episode and triage data, and populates the medications summary from the patient’s active MAR orders — all without the nurse having to type any of it.
The referral then moves through a Draft → Sent → Accepted/Declined lifecycle. Send methods supported are Manual, Fax, Direct, and Print. The facility referral dashboard shows all open referrals across active episodes with status and response tracking.
Inpatient Hospital
The Inpatient track reached full page coverage this cycle.
The Floor Board is the IP equivalent of the ED Board — a sticky-header sortable table with bed/unit, patient, age, service line, admission type, attending, actual LOS vs. expected LOS (green/amber/red badge), admitting diagnosis, next task due, and a full action row. Unit filter tabs let charge nurses narrow to their floor.
Admission uses the same live patient search widget as AL intake. The attending, service, admission type, bed, unit, and admitting diagnosis are all captured at admit time. Under the hood, admission follows OpenEMR’s three-step encounter creation process — generating a proper encounter number through the sequences table, inserting the form_encounter row, and registering it in the forms table — so the encounter appears natively in the OpenEMR chart timeline, CCDA, and FHIR exports.
The Patient Profile hub is what floor nurses open repeatedly throughout a shift. It aggregates the last six vitals readings as sparkline charts (BP, SpO₂, HR), today’s MAR administrations with outcome badges, care plan goals, open tasks, and care team members, all on one page. LOS vs. expected is prominently colored in the header.
Vitals monitoring uses tighter inpatient alert thresholds than AL: SpO₂ below 90%, systolic BP above 180 or below 80, heart rate above 120 or below 45. Trend sparklines are rendered directly in the browser from the stored readings.
Discharge planning is a two-stage Plan → Confirm workflow. Stage 1 records the disposition code (Home, SNF, Rehab, Hospice, Transfer, AMA, or Expired), destination, expected discharge date, and discharge summary narrative — the episode stays active. Stage 2 records the actual departure datetime, closes the episode, and fires an HL7 A03 event. At that point the e-referral auto-draft also triggers if a qualifying disposition was set.
Assisted Living
AL has the fullest workflow coverage of any track.
The Resident Board is a card layout with fall-risk color-coded left borders (red HIGH, orange MODERATE, green LOW), ADL overdue tinting, care level badges (Tier 1–3), and quick-action links to every sub-page from the card footer.
Intake uses the live patient search widget to find an existing OpenEMR patient and create an AL episode with room, unit, care level, fall risk tier, and admit reason.
The Resident Profile hub mirrors the IP profile — vitals snapshot, today’s MAR, ADL summary, care plan goals, open tasks, fall risk score, and navigation tabs to every sub-page.
ADL charting covers all seven standard domains (bathing, dressing, grooming, transfer, ambulation, eating, toileting) on a 0–4 independence scale per domain. Aggregate score is computed and cached on the AL overlay for fast board display. History table shows trend over time.
Morse Fall Scale assessments score all six items (fall history, secondary diagnosis, ambulatory aid, IV/heparin lock, gait, mental status), compute the 0–125 total, assign the risk tier, and maintain a timestamped history. The current score drives the board card color.
Incident reporting covers Fall, Fall with Injury, Elopement, Medication Error, and Other types, with severity levels, narrative, corrective action, and a mandatory-reporting flag with state notification tracking.
Activity logging records session type, name, time, location, and per-resident participation level (Full, Partial, Declined) with session-level notes. The board shows attendance counts.
AL MAR is a 5-day rolling nursing view purpose-built for the assisted living shift — same backend as the ED/IP MAR, different display optimized for medication-pass rounds.
Discharge mirrors the IP two-stage workflow with AL-specific disposition codes.
Institutional Quality Dashboard
New this cycle. The dashboard has four sections:
Operational timing measures (existing ED/OBS metrics now surfaced in the dashboard): door-to-room, door-to-provider, door-to-ECG, and sepsis 3-hour bundle compliance, each showing median, 75th percentile, and compliance rate with an animated SVG semicircle gauge.
Institutional readiness scorecard — six items each with a numerator, denominator, percentage, and status badge (Ready/Partial/Action): IP encounter linkage rate, AL encounter linkage rate, IP vitals capture rate, institutional MAR capture rate (IP+AL combined), AL fall-risk assessment rate, and IP discharge summary completion rate for closed episodes.
Hybrid extraction readiness is a composite meter showing the percentage of IP episodes that have both encounter linkage and vitals captured — the minimum floor for CMS hospital quality reporting extraction. The measure exists to give an honest answer to “can we generate a quality report from this data” before anyone tries.
Patient safety signals are live query-driven indicators: falls with injury from AL incident reports, opioid adverse events (naloxone administered following an opioid order), high-alert co-sign gaps, and IP discharge summary completion. Each shows a status of Good, Watch, or Action.
The dashboard is date-range filterable and pulls exclusively from live module tables.
Supporting Infrastructure
The Context Manager lets users switch clinical lens between ED Acute, Observation Stay, Inpatient, Behavioral Health, Assisted Living, Operations, and Full. The context drives which dashboard widgets and menu items appear.
Alerts fire on LWBS risk, sepsis indicators, BH boarding dwell time, OBS runway, and overdue MAR administrations. Alerts can be individually acknowledged with a configurable snooze window.
Shift Handoff is context-aware across ED, OBS, BH, AL, and IP — nurses get the right columns and episode links for their unit.
Transfer Tracking manages Transfer and BH Placement workflows with a checklist, accepting facility, and transport datetime.
Episode Timeline shows the full chronological event log for any episode — every status change, location move, task completion, and clinical event in order.
Throughput Analytics gives a single-day view of arrivals, dispositions, LOS distribution, and door-to-disposition times across episode types.
Operational Trends runs weekly or monthly series across the same timing metrics with a day-of-week heatmap for volume patterns.
Provider Scorecard ranks providers by volume, door-to-room, door-to-provider, door-to-disposition, LWBS rate, and OBS conversion rate over a configurable date range.
Multi-Facility Dashboard shows a system-wide census strip — one row per facility with live bed occupancy bar, census count, sepsis risk flags, pending MAR count, BH boarding count, and OBS count.
HL7 ADT fires A01 (admit/OBS start), A02 (location change), A03 (discharge), A04 (arrival/registration), and A08 (update) events into configurable MLLP or HTTP endpoints. A full outbound log with message body, ACK, status, and error is maintained.
Downtime mode runs a Service Worker that caches a facility snapshot to IndexedDB. If the network drops, nurses continue entering arrivals, vitals, and status notes into a browser-side write queue. On reconnect, the sync endpoint replays the queue in order.
What Remains
- Drug-drug interaction checking in the MAR
- Standing order auto-renewal
- eCQM catalog: lab result mapping to move the hybrid extraction readiness meter past Partial. I worked heavily on this in OpenEMR by adding the offering of all CMS measures included in selectable 2023-2025 besides those we certified for 2015 and 2025 attestations. 2026 measures can be available soon if they become a requirement moving forward.
- BCMA barcode scanning (explicitly deferred, out of scope for v1). I will get to this for sure.
Everything else is built, wired, and running on a live Docker/OpenEMR instance with a complete demo dataset of 5 demo AL residents, 5 demo IP inpatients, 13 ED/OBS patients, full MAR orders with administration history, care plans, tasks, triage vitals, incident reports, and ADT/HL7 log entries. I’ll post URL and credentials here by Monday 03/23 for all of you that want to take a look.
I truly appreciate all of you folks that are following my project. Based on all of my contributions to OpenEMR over the last ten years, I believe this to be the best.
Thanks and be well!
2 Likes
