OpenEMR Institutional Module Beta continued

sjpadgett · March 30, 2026, 6:37am

Hi Everyone,
Continued from New Institutional Module: Is it time? - #42 by sjpadgett
I decided to start a new topic to split up the ongoing Institutional Module topic: New Institutional Module: Is it time? because that topic has become a book requiring 20 minutes to read. Since I’ve developed a new submodule for Home-Based Care (HBC) I thought this is a good time to break out.
For my last add on to module I’m designing an Occupational Health module to include all the OSCHA requirements. Feel free to opine all demo my beta version of HBC.

OpenEMR Institutional Module — Home-Based Care Submodule Beta

We’re releasing the Home-Based Care (HBC) submodule of the OpenEMR Institutional Module into public beta on our demo server. This is the most field-mobile track in the module, purpose-built for skilled nursing, therapy, and house-call programs operating outside a facility wall.

What it covers

The submodule manages the full HBC episode lifecycle from referral through discharge across ten pages:

Visit Board — the daily operations hub with four panels: a service snapshot showing KPIs, a triage-ordered referral queue for new and pending cases, an action queue for open follow-up tasks, and a date-navigable schedule of today’s visits. Coordinators can advance visit status (Scheduled → En Route → Arrived → Complete) with a single tap and capture clinician GPS on arrival — all via JSON endpoints without a page reload.

Referral Intake — accepts new HBC referrals with live patient search, international service address, caregiver contact, urgency triage (Routine / Urgent / Emergent), clinician assignment, primary diagnosis with ICD-10, and payer/authorization notes. Duplicate episode detection prevents double-admits. Creates an OpenEMR encounter automatically to anchor care plan entries.

Patient Profile — the hub page for a single episode, showing the service address and caregiver card, next scheduled visit, recent visit history, vitals snapshot, care plan progress, and open tasks.

Schedule Visit — books a new visit with visit type (Skilled Nursing, Physical Therapy, Occupational Therapy, Speech Therapy, Medical Social Work, Home Health Aide, Physician/House Call, or Other), scheduled time, arrival window, route sequence, travel notes, and clinician — with next-visit recommendations pulled from the previous visit’s follow-up plan.

Visit Workspace — a phone/tablet-optimised field encounter page with server-side draft autosave, localStorage fallback, silent GPS capture, patient signature canvas, medication reconciliation status, wound summary, procedure summary, home safety assessment, and care coordination notes. Supports structured completion as Complete, Refused, or Missed.

Vitals, Fall Risk, Incident Reports, Shift Handoff, Discharge — shared clinical forms adapted for the home setting, using the same repositories as the AL track where appropriate.

Offline support — a service worker caches the core HBC pages for offline use. Visit drafts and finalization queue to IndexedDB and sync automatically when connectivity is restored.

Visit status model: Scheduled → En Route → Arrived → Complete (with Missed, Refused, and Canceled as terminal alternatives).

How it fits the broader module — HBC is one of six installed-purpose profiles (alongside ED+OBS+BH, Inpatient, Assisted Living, AL+Inpatient, and Full). A facility or individual clinician can run HBC alongside other tracks on the same OpenEMR instance; the context bar and per-user profile system keep each user’s view focused on their workflow.

The demo server is available at [see below]. Feedback welcome in this thread. This is beta — clinical workflows are complete end-to-end but we’re still collecting field feedback on the mobile visit workspace and offline sync behavior before a stable release.

Demo site: Demo Institutional OpenEMR
(Below usernames log you into the Institutional Facility Profile for username. admin default context is FULL meaning all shared and submodules are available. Nice for testing.)
Username: admin, DemoTester, DemoTesterOne, HomeHealth, Institutional and AssistedLiving.
Password for all usernames: !OpenDemo1

I hope this is received well and thanks for the support.

censon · March 31, 2026, 9:06am

On fire!

Love the home-based care sub module and looking forward to your occupational health sub-module. A work of genius.

Cheers, Simon

sjpadgett · March 31, 2026, 6:18pm

Thanks for looking over and your kind comment @censon

I’ve decided before moving forward with Occupational I should address billing scaffolding and make some integration decisions. Best bet IMO is a hybrid shared billing submodule with facility-profile billing mode by each facility’s installed purpose to drive the billing behavior. The current facility-profile model is already in place for this.

Billing mode by installed purpose
ED / OBS / IP / BH
Default to:

institutional charge staging
UB04/837I oriented workflow
OpenEMR Billing Manager handoff

Assisted Living
Default to:

private-pay / recurring service ledger
statement/invoice workflow
optional claim export only for selected covered services

Home-Based Care
Default to:

professional / visit-based charge capture first
optional claim handoff
do not force institutional billing by default

This gives one billing submodule without just one reimbursement model.

Since OpenEMR already supports HCFA 1500, UB04, 837I and 837P much of the heavy lifting is done plus a bonus that I will be able to contribute some fixes and upgrades to existing OpenEMR Billing.

Furthermore, I need to sort out vitals and make a decision if I want to originate vitals from OpenEMR or notify vitals from current vital collections in module, This has been on my mind since the start of module development. I’d appreciate opinions on this work flow.

htuck · March 31, 2026, 7:14pm

Due to my limited time to play with this I’m primarily focusing on the UI mechanics of the MAR workflows. Hopefully they will come to a resting state to be tested?

One thing I’m noticing is the lists of individual meds in facility view are visually awkward to use. They each seem to have their own time, even if they’re listed in the same frequency, BiD, TiD or whatever. It’d make sense to me to group the meds by patient, in the time slot (med pass) they belong to. Of course ya gotta establish what the times of the med passes are– Qd = 0600, BiD = 0600-1600, TiD = 0600, 12N, 1800, etc then round the times of the due meds into the nearest time slot they’re ordered for.

Mebbe for the next point version.

Keep it up!

HT

sjpadgett · March 31, 2026, 8:39pm

Unsure I understand @htuck. I can agree the scheduling is very busy but the individual scheduled med can be handled from the same place such as co-sign, waste, witness etc.
I assume you are talking about this screen.

Medication Reconciliation is where OpenEMR prescribed drugs are imported to patient for MAR.
The module will automatically interrupt openemr drug signatures/dosage due to hl-7 is not fully supported. So you can review med fix dosages etc then activate into patient for MAR scheduling.

Still I need to work on UX and may need to add some new support pages.

sjpadgett · April 1, 2026, 9:41pm

Extended Vitals & Remote Observation Support — Module Update

For those following the institutional care module, we’ve just shipped a significant update to how vitals and extended patient observations are handled.

The short version: the module now cleanly separates episodic clinical vitals (the kind OpenEMR was designed for) from continuous and device-sourced observations — the kind you need when managing chronic care cohorts, RPM programs, or institutional patients with connected wearables.

What’s new:

A shared vitals architecture across all care tracks (ED, IP, AL, HBC) with track-appropriate alert thresholds — acute inpatient norms are tighter than residential or home-based norms, and the system knows the difference
A new oei_observation store purpose-built for high-frequency device data, partitioned by quarter to handle volume gracefully without bloating the core OpenEMR tables
24 pre-seeded observation types with LOINC codes — glucose, HRV, SpO₂, INR, sleep, stress, HbA1c, and more — all configurable per facility
A FHIR R4 ingest endpoint so existing device bridges (wearables, CGM, home BP cuffs) can POST data directly without OpenEMR framework dependencies
Flagged readings surface as real-time indicators on the AL, IP, and HBC boards — no need to open a chart to see which patients need attention
A full observation history and trend page per patient, accessible from any profile, with Chart.js trend charts that colour-code readings outside alert bounds

This directly addresses the storage and scope limitations of OpenEMR’s native vitals for use cases like RPM, assisted living, and home-based care — which was the gap we set out to close.

Still on the roadmap: per-facility threshold management UI and AI-assisted triage integration using the trend data.

Happy to answer questions or discuss the architecture. I’ve decided to stay out of or rely on openemr vitals I may look into integrating extended observation to openemr observations.

censon · April 1, 2026, 9:58pm

Superb! Cannot wait for this to be available.

Cheers, Simon

luissantosHCIT · April 6, 2026, 5:46pm

Hi everyone! I am new to the project from a contributions standpoint. I do have extensive experience in backend, devops, cybersecurity, and protocols in healthcare. My area of expertise is in Open Source projects in medicine. Hopefully, that gives some credence in my statements. I also help institutions upgrade and modernize their systems.

After reading the prior thread and this thread, there are a few pieces of feedback I would like to share:

Starting with the quoted statement above, what does the author mean here? As a bit of background, I am currently in the process of completing an HL7 V2 to FHIR bridge toolset in Rust (* RUMTK) which was a project I began a couple of years ago in my off hour to enable hospitals to upgrade from the old protocol to FHIR. I also worked with FHIR extensively when I was helping the NIH (once upon a time). It sounds like work duplication is taking effect here. I believe another user expressed a similar concern about a different submodules and already existing OpenEMR codebase. The interface is the contract boundary between the application internals and the outside world. FHIR is extremely portable compared to V2. There should not be any dependencies between it and the world. Meaning, once an outside entity (gadget, my own interfaces, other hospital systems) authenticates, it can just POST to the appropriate standard FHIR REST endpoint. I believe, OpenEMR already has a FHIR endpoint. What is wrong with it that made the author build another? As a result, I really do not understand what the author is trying to communicate with this statement. We have to be careful here since interface work can make or break workflows necessitating integration with downstream systems. Your reputation kinda goes down the drain if an interface is too unreliable to work with.
On the surface, the UI work appears very impressive. No surprise here, because I think the author mentioned usage of Machine Learning assistance. ML tools are statistical machines and most of their training data is web dev code bases. That combined with the OpenEMR codebase as part of the context should provide consistent results here. Also, a colleague who “vibe codes” showed me some impressive UI prototypes he made. Again, pretty cool.
What is the unit, integration, and E2E test coverage here? Albeit impressive, the work here appears to move too fast. I saw a comment from the author about skipping FHIR under the assumption that hospitals only use HL7 V2. Although that provided speed in development, it is the wrong assumption. People like me are working to upgrade hospital to FHIR. In engineering, it is important to test, test, and then do some testing. Encoding these test in a programmatic structure creates a reproducible checklist. This is specially key in medicine. Something I love about OpenEMR is that it provides an opportunity to slowly, but surely build robust systems and avoid the spaghetti code prevalent in pure commercial solutions. I have been there as a software engineer and it is not pretty to maintain a system other use when the internal code quality suffers. As a result, my recommendation is to slowdown and ensure each detail in the module is properly tested and properly testable. By the way, the tests should probably be human coded to avoid LLM based ML systems from outright falsifying the true state of the module. Furthermore, I saw another major project (* OHIF/Viewer) usage of a ML system to build an internal diagram of component logic, so something like it might be useful in tracking implicit dependencies and potential failure areas that may have developed over time.
Besides the author, does anyone else understand the internals of this project/idea? If this is something for which the author aspires to propose and merge into the main OpenEMR project, I recommend a thorough review of the internals by other third parties and to break down current work into small, self contained features to integrate over time. If this process is performed properly, this could take a few years and trigger a few other requests for code consolidation and code quality improvements elsewhere in OpenEMR. For example, I have changes in OHIF which are far smaller in scope and which has taken almost a year to ratify and that’s how I know I can trust their codebase. Once changes are in, you can be confident they are robust. It is important to have multiple people knowledgeable of the actual codebase specifics to build the capacity to support it in the future.

Now, don’t take my comments harshly, I am passionate about medicine (went to school for that), software engineering (done it my whole life and I aspire to one day build a Linux kernel module [for fun]), and engineering (I watch airplane crash investigations [for fun]). I am trying to share some wisdom and ensure that this idea being developed can be depended on years to come. Otherwise, I think the UI ideas here are things that I suspected were areas OpenEMR needed work on so I think this is a great discussion starter. LLMs enable us to generate prototypes quickly and that is excellent (specially if it makes people interested in solving problems). Just keep in mind that going from prototype to production is a different question and demands we put our engineering hats on.

P.S. > If OpenEMR is looking to improve on the interface side of things, that is a niche I would love to work with the author here and with the community at large!

sjpadgett · April 8, 2026, 2:04am

Hello Everyone following,
I’ve put in a great deal of effort on the Home-Based Care submodule and along with Assisted Living care submodule is getting close to a release product. Needs considerable testing which I’m hoping some of you are willing to help out with.

Since I’ll be implementing a FHIR Observation endpoint(currently a Rest endpoint) for collecting external device observations, I’m also looking into implementing most, if not all, backend DB transactions via FHIR API. This means I’ll need to contribute write capable FHIR endpoints(Care Plan, Care Teams, Clinical Notes, Encounter, Medication to start) to the community project. I feel API’s are the go to for all future module implementations and at some point may be required. Most certainly direct DB access would and should be strictly limited.
Visit my Demo at

Log in with username HomeHealth for an already setup context.

Home-Based Care Module — Now Available (v0.40.0)

oe-module-institutional now includes a complete Home-Based Care (HBC) submodule for managing home health, house-call, and community nursing workflows inside OpenEMR.

If your organization delivers care in patients’ homes — skilled nursing visits, physical therapy, home health aide services, physician house calls — this module manages the entire lifecycle from referral through discharge, with mobile-first field documentation and offline support.

What It Does

Referral → Visit → Documentation → Discharge — a complete end-to-end workflow built for home care operations.

Referral & Intake — Accept referrals from hospitals, PCPs, family, or agencies. Capture service address, caregiver contacts, diagnosis, payer authorization, and certification period. The system prevents duplicate active episodes and creates proper OpenEMR encounters automatically.

Visit Board — The daily cockpit for field clinicians and supervisors. Shows today’s schedule sorted by route sequence, a priority action queue that surfaces patients needing urgent attention (overdue follow-ups, medication issues, cert period expiring, supervisory visits due), and a referral queue for new patients awaiting triage.

Scheduling — Single visit or batch/recurring scheduling. Need 3 skilled nursing visits per week for 4 weeks? Select the days, set the number of weeks, and the system creates all 12 visits in one submission. Assign clinicians with day-load visibility, set arrival windows, route sequences, and travel notes. Edit or reassign any scheduled visit without canceling.

Mobile Visit Workspace — Designed for phones and tablets in the field. 13 structured documentation sections: clinical narrative, outcome summary, medication reconciliation, wound care, procedures, home safety assessment, care coordination, follow-up planning, inline vitals capture, and patient signature. Autosaves every 30 seconds with localStorage backup.

Offline Support — Full offline capability via service worker and IndexedDB. If you lose connectivity during a home visit, drafts and even finalizations queue locally and sync automatically when you’re back online.

Inline Vitals — Record BP, HR, SpO₂, respiratory rate, temperature, weight, and pain score directly in the visit workspace. Written to the clinical vitals table on finalize — no separate vitals page needed during a visit.

Certification Period Compliance — Track payer-authorized service windows with start/end dates and authorized visits per week. The profile shows a compliance progress bar, and expiry alerts surface at 14 days (yellow) and 7 days (red). Expired certs push patients to the top of the action queue.

Supervisory Visit Tracking — HHA patients require RN supervisory oversight every 14 days. Flag any visit as supervisory when scheduling, and the system tracks compliance across the handoff report and action queue.

Communication Log — Document all external contacts: calls to/from PCP, pharmacy, family, DME suppliers, payers, hospice, social services. Facility-wide view from the top menu, episode-specific view from the patient nav. Filter by contact role or follow-up status.

Clinician Handoff Report — One row per active patient with vitals, next visit, MAR status, fall risk, cert period, care plan goals, and clinical flags. Color-coded row highlighting for patients with multiple alerts. Print-optimized for paper handoffs.

Episode Edit — Update service address, caregiver info, clinician assignment, diagnosis, payer, cert period, and urgency at any point after intake. All changes are audit-logged.

Patient Profile — Central hub showing service snapshot, clinical attention scoring, next visit, latest vitals, open tasks, care plan progress, visit history with duration/mileage, observations, and links to all clinical workflows.

Shared Workflows — Full integration with the module’s existing shared infrastructure: Care Plan, Clinical Notes, Care Team, eReferral, Documents, Fall Risk Assessment, Incident Reporting, MAR, Tasks, and Observations.

Technical Details

OpenEMR 7.0+, PHP 8.1+
Bootstrap 5.3 served locally via Composer (CDN fallback available)
Dark/light theme support with normalized CSS variables across all pages
5 HBC migrations (0008–0012) — all idempotent, safe to re-run
Manifest-driven feature flags — enable/disable any feature per facility
Demo seed data included — 6 HBC episodes across 20 tables for evaluation
No external dependencies beyond what OpenEMR already provides
PSR-4 autoloading with controller/repository/service pattern throughout

Pages Included

Page	Purpose
Visit Board	Daily schedule, action queue, referral queue, KPIs
New Referral	Patient intake with address, caregiver, payer, cert period
Schedule Visit	Single or batch/recurring, clinician day load, route planning
Visit Workspace	Mobile field documentation with offline + signature
Patient Profile	Central hub — snapshot, attention, vitals, tasks, care plan
Edit Episode	Update address, clinician, caregiver, cert period, diagnosis
Communication Log	External contact tracking with follow-up flags
Handoff Report	Facility-wide clinician handoff with print view
Vitals	Dedicated vitals recording with history table
Fall Risk	Assessment and reassessment tracking
Incidents	Home safety, falls, med errors with mandatory report flags
Discharge	Episode closure with 7 disposition types

Getting Started

A Workflow Guide (Word document) is available for download that walks through every step from receiving a referral to closing an episode, including a printable visit-day checklist for field clinicians.

Download: HBC Workflow Guide
HBC-Workflow-Guide.docx (20.2 KB)

The guide covers all roles (intake coordinator, supervisor, field clinician, administrator) and includes the batch scheduling workflow, offline documentation procedures, and the clinician handoff process.

Feedback, bug reports, and contributions welcome. This has been built and tested on Docker with OpenEMR 8.0.2.

censon · April 8, 2026, 3:04am

Hi Jerry,

When I try to access home based care in the context manager, I received the attached error. Logged in as admin.

Cheers, Simon

sjpadgett · April 8, 2026, 3:10am

Are you logging in using HomeHealth username?
Sorry @censon I see you said admin. If you change context from an elevated context you may need to log out and in. I just went to sight as admin and saw it is setup for Home Based context on login.

censon · April 8, 2026, 3:14am

No, I used admin. Have used that previously sucessfully.

censon · April 8, 2026, 3:23am

Got it. Thanks for that.

sjpadgett · April 8, 2026, 3:42am

Note that the facility extended observation landing page is not available in the Home-Based context and it should be so a bug. Working on fixing now.
Obs alerts still show in patient profile.

sjpadgett · April 8, 2026, 3:55am

Okay added back Tracking menu that includes missing facility nurse alerts and extended observation pages. @censon log out and back in if still looking over.
Kind of important!