01
Patients & families
Find care, meet specialists and book a visit without playing phone-tag with a front desk.
Case studies
Product Story — Built in-house by Electro AI Lab
ElectroHMS: Engineering a Hospital Information Management System as a Connected Hospital OS
A hospital runs on dozens of small handoffs — a patient booked, a bed assigned, a prescription filled, an invoice cleared. ElectroHMS is Electro AI Lab’s in-house hospital information management system, built to keep those handoffs connected instead of scattered across disconnected tools.
27
Modules
6
Functional layers
12+
Staff roles
3
Audiences, one system
Product snapshot
Built in-house as a Hospital OS
This page isn’t a customer case study. There’s no client hospital behind it, no deployment to report on, no results to quote. What follows is the story of a product Electro AI Lab designed and built itself — the thinking behind it, the way its parts fit together, and what that says about how we approach complex software.
- What it is
- A hospital information management system covering clinical, operational, financial and administrative workflows.
- Built by
- Electro AI Lab, as an in-house product.
- Core audiences
- Patients & families, clinical and hospital staff, hospital leadership.
- Scope
- 27 operational modules across six functional layers, with role-based access spanning 12+ distinct staff roles.
The problem
The Problem With How Hospitals Run Software
01Most hospitals don’t run on one system. They run on several — a booking tool here, a billing package there, a spreadsheet for bed occupancy, a separate login for the pharmacy. Each piece does its job reasonably well in isolation. The trouble starts at the seams.
02A patient books an appointment through one channel and shows up to a front desk that has no record of it. A doctor orders a lab test that never quite makes it into the discharge summary. A pharmacy runs low on a critical drug because nobody was watching the stock count in real time. None of this is any one department’s fault — it’s what happens when a hospital’s information lives in pieces instead of a system.
03Hospital administrators feel this most acutely. Ask a hospital owner how many beds are occupied right now, what today’s collections look like, or which drugs need reordering, and the honest answer is often “let me check three different places.” That’s not a staffing problem. It’s a software architecture problem.
04ElectroHMS started from that observation.
The vision
The Vision: A Hospital Operating System
We didn’t set out to build another appointment booking tool, and we didn’t set out to build another billing package. We set out to build something closer to an operating system for a hospital — a single connected layer that every department, every role and every location runs on.
Inside the product, this is exactly how ElectroHMS describes itself: Hospital OS.
That line — pulled directly from ElectroHMS’s own staff sign-in screen — is a fair summary of the whole design philosophy. Access, identity and context aren’t an afterthought bolted onto a booking calendar. They’re the foundation everything else is built on.
The idea is simple to state and hard to build: a receptionist, a pharmacist, a lab technician, and a hospital owner should all be looking at the same underlying data — just through the lens their job actually needs.
“Secure access with full RBAC. Authentication, authorization, multi-hospital / multi-branch context and role-based permissions for every hospital team member.”
Who it serves
Built for Three Audiences, One System
ElectroHMS is deliberately split into three entry points, because a hospital isn’t one audience — it’s three, with almost nothing in common except the data they share.
02
Clinical and hospital teams
Run wards, pharmacy, lab work and billing from one connected workspace instead of switching between disconnected tools.
03
Hospital leadership
See occupancy, collections and service load through live operational reporting — not a weekly spreadsheet someone had to assemble by hand.
Three very different jobs. One underlying system holding the data together.
Connected workflows
How ElectroHMS Connects a Hospital
This is the part most hospital software gets wrong. It’s easy to build a module for appointments, a separate module for billing and a separate module for pharmacy. It’s much harder to make sure a single patient’s journey flows cleanly through all three and that a change in one place is reflected everywhere else that depends on it. ElectroHMS is organized around four workflows that run through the same core, rather than existing as isolated tools.
Workflow 01
The Clinical Journey
Patient registration is the starting point for everything downstream. An outpatient consult might end there. An inpatient case moves further — into a ward, potentially into the operating theatre, always back into a shared patient record that every subsequent department can see. Emergency intake follows the same underlying logic, just under time pressure: triage, escalate to IPD or OT if needed, keep the record intact throughout.
- 01Patients
- 02Appointments (OPD or Emergency intake)
- 03Consultation
- 04Laboratory / Blood Bank
- 05Pharmacy
- 06IPD admission (Wards & Beds)
- 07OT, if surgery is required
- 08Records
The point isn’t that each of these exists. It’s that they’re built to hand off to each other automatically, instead of requiring someone to manually re-enter the same patient’s details in four different screens.
Workflow 02
The Financial Journey
Every clinical encounter eventually becomes a bill. ElectroHMS treats that as a direct, traceable line rather than a separate reconciliation exercise.
- 01Clinical encounter (OPD / IPD / OT / Emergency)
- 02Billing
- 03Insurance (where applicable)
- 04Finance / Collections
Pharmacy and lab charges flow into the same billing record, rather than arriving as a separate invoice the front desk has to reconcile by hand. Insurance sits between billing and finance as a claims step. Finance rolls the whole picture up — which is what powers the collections and pending-invoice figures that show up on the leadership dashboard.
Workflow 03
The Administrative Journey
Staff access follows its own workflow, separate from patient care but just as structured.
- 01Staff
- 02HRMS
- 03Users
- 04Roles & RBAC
- 05Sessions
Every staff member has an employment record, a system account, a defined role, and a controlled session. That’s what turns “role-based access” from a marketing phrase into something enforceable — a nurse’s account is scoped to what a nurse needs, a cashier’s account is scoped to what a cashier needs, and neither can casually wander into the other’s territory.
Workflow 04
The Organizational Structure
Hospitals aren’t always single buildings. ElectroHMS is built around a structure that assumes they might not be.
- 01Hospitals
- 02Branches
- 03Departments
- 04Wards & Beds
A hospital group can operate multiple branches under one system, each with its own departments, staff, and bed inventory — all reporting up through the same platform rather than requiring a separate install per location. This is a deliberately different starting assumption than software built for a single clinic and later stretched to cover a chain.
Inside the platform
Inside the Platform
ElectroHMS’s internal dashboard organizes into 27 modules. Rather than list them all, it’s more useful to see how they group into six functional layers:
Layer 01
Front-of-house & patient flow
Patients, OPD, IPD, Emergency, OT, Appointments, Doctors
Layer 02
Clinical support
Laboratory, Blood Bank, Wards & Beds, Records
Layer 03
Pharmacy & supply
Pharmacy, Inventory
Layer 04
Revenue cycle
Billing, Finance, Insurance
Layer 05
People operations
Staff, HRMS
Layer 06
Governance & administration
Users, Roles & RBAC, Sessions, Settings, Hospitals, Branches, Departments, CRM, Reports, Dashboard
Six layers, one shared core — none of these modules were designed to work alone.
Product in action
Product in Action
The dashboard is where all four workflows meet. It’s the first screen a hospital administrator sees, and it’s designed to answer the questions that usually take a phone call to three different departments.
A live snapshot shows patients registered, today’s appointments, beds occupied against total capacity and collections against pending invoices — in one view. Below that, a recent-appointments feed ties patients to doctors, dates, and status in real time, and a pharmacy alerts panel flags stock nearing its reorder point before it becomes a shortage.
None of this is a static report generated overnight. It’s the same data the clinical and financial workflows are updating throughout the day, surfaced in a form a hospital owner can actually use without digging.
Gallery
Product gallery
Interface and system visuals from ElectroHMS — product UI, operational layers, and platform concepts. Demo data shown where applicable.
Access & governance
Access, Roles & Governance
Hospitals have a wider range of job functions than most software categories account for and each one needs a different slice of the system.
ElectroHMS ships with defined roles for Super Admin, Hospital Owner, Branch Admin, Medical Director, Doctor, Receptionist, Nurse, Pharmacist, Lab Technician, Cashier, HR, and Patient — twelve in total, with the underlying permission system built to support more granular splits within a hospital’s own structure.
This matters more than it might sound. A receptionist shouldn’t be able to override a billing record. A pharmacist shouldn’t be editing clinical notes. A branch admin at one location shouldn’t have visibility into a different branch’s staff records by default. Getting this wrong doesn’t just create a messy interface — it creates real accountability gaps in a setting where accountability isn’t optional.
Access control in ElectroHMS isn’t a settings page you configure after the fact. It’s a structural layer — Users, Roles & RBAC and Sessions — that every other module is built on top of.
Defined roles across the hospital
Super Admin
Hospital Owner
Branch Admin
Medical Director
Doctor
Receptionist
Nurse
Pharmacist
Lab Technician
Cashier
HR
Patient
Design decisions
Design Decisions
01
Multi-branch as a first-class concept, not an add-on
Many hospital systems are built for a single facility and patched later to support chains. ElectroHMS starts from the opposite assumption — Hospitals and Branches are core entities from the first schema decision, not a workaround added when a second location shows up.
Digital Transformation Consulting02
Role granularity over role simplicity
It would have been simpler to ship three or four broad roles — “staff,” “admin,” “patient.” Twelve-plus specific roles is more work to design and maintain, but it reflects how hospitals actually organize their people, and it’s the only way role-based access means anything in practice.
03
One dashboard, not a report someone assembles
Operational visibility for hospital leadership could have been a monthly export. Instead, the dashboard reads from the same live data the clinical and financial modules write to — a choice that shapes how every module underneath it has to be built, not just how the top screen looks.
Custom AI & ML SolutionsWhy it stands apart
What Makes This Different
Genuine breadth
Clinical, pharmacy, billing, insurance, HR and administration in one platform — not a booking tool with a billing plugin bolted on.
Multi-branch by design
Built to support hospital groups from the ground up, not retrofitted for scale after the fact.
Real access governance
Twelve-plus roles with structural RBAC, session control, and permission scoping — not a single “admin” toggle.
Live operational visibility
A dashboard that reflects the hospital’s actual state right now, not a report from last week.
CRM included
An uncommon addition for hospital software, reflecting an ambition that extends past pure clinical and billing operations into patient relationships.
Terminology
Terminology, Clarified
Hospital software terminology gets used loosely, even in vendor marketing. A few definitions worth being precise about:
- Hospital Information System (HIS)
- Typically refers to software that spans both clinical and administrative data — patient records, orders, and operational workflows together.
- Hospital Management System (HMS)
- Often used for the more operational half of that — registration, scheduling, billing, bed management — sometimes without deep clinical documentation.
- Hospital Information Management System (HIMS) / Hospital Management Information System (HMIS)
- Largely used interchangeably with HIS and HMS across the industry, without a strict, universally agreed distinction.
- Hospital ERP
- Extends further into back-office operations — finance, HR, procurement, asset management — borrowing structure from ERP software built for other industries.
ElectroHMS doesn’t fit neatly into just one of these categories. It combines HMS-style operational modules (registration, scheduling, billing, bed management) with HIS-style clinical connectivity (lab, blood bank, records) and ERP-adjacent administrative layers (HRMS, finance, multi-branch governance) — which is closer to what the “Hospital OS” framing is trying to describe in the first place.
What's next
Where ElectroHMS Is Headed
ElectroHMS is an active in-house product, not a finished one. It continues to serve as Electro AI Lab’s reference platform for how we think about complex, multi-role, multi-location healthcare software and it continues to evolve as that thinking does.
We’re not publishing a roadmap here, because we’d rather that stay honest than promotional. What we can say is that the same questions that shaped it so far — how access should be scoped, how workflows should connect, how a hospital group’s structure should be represented — are still the ones driving what gets built next.
Build Something Like This With Us
ElectroHMS reflects how Electro AI Lab approaches software for complex, regulated, multi-stakeholder environments — not just hospitals, but any organization where different roles need different views of the same underlying system. If you’re evaluating hospital software, or need something built with this level of operational depth, talk to the team that built it.
Talk to our expertsFAQ
Frequently asked questions
The terms are often used interchangeably. In general, HIS leans toward combining clinical and administrative data, while HMS is used more often for the operational side — scheduling, registration, billing and bed management. ElectroHMS is designed to span both.
Yes. Hospitals and Branches are core structural entities in ElectroHMS, with Departments and Wards & Beds scoped underneath them — built to support hospital groups operating across multiple locations under one system.
ElectroHMS defines specific roles — including Super Admin, Hospital Owner, Branch Admin, Medical Director, Doctor, Receptionist, Nurse, Pharmacist, Lab Technician, Cashier, HR and Patient — each scoped to the data and actions relevant to that role, governed through dedicated Users, Roles & RBAC and Sessions modules.
ElectroHMS is currently an in-house Electro AI Lab product. For hospitals or healthcare organizations interested in similar software, the best next step is to talk directly with our team.
ElectroHMS spans 27 modules across six functional layers: front-of-house and patient flow (Patients, OPD, IPD, Emergency, OT, Appointments, Doctors), clinical support (Laboratory, Blood Bank, Wards & Beds, Records), pharmacy and supply (Pharmacy, Inventory), revenue cycle (Billing, Finance, Insurance), people operations (Staff, HRMS), and governance and administration (Users, Roles & RBAC, Sessions, Settings, Hospitals, Branches, Departments, CRM, Reports, Dashboard).
Related work
Related healthcare work
Client engagements — distinct from this in-house product story.
Client portfolio
HealthTrack Patient Portal
Client work — HIPAA-compliant healthcare platform with telemedicine and appointment scheduling. Distinct from this in-house ElectroHMS product story.
Client portfolioMedConnect Telemedicine
Client work — virtual healthcare platform connecting patients with doctors via video consultation. Distinct from this in-house ElectroHMS product story.