Run the hospital, not the paperwork.
Ospeli is one operations system for hospitals and clinics: beds, engineering faults, A&E flow, process maps and the playbooks to redesign a department. It captures what happens as it happens, then helps your team fix the flow and prove what changed.
Map processes. Optimise flow. Improve care.
Large public hospitals run on walking, phoning and paper.
Beds, broken equipment, A&E queues and handoffs are tracked on paper, whiteboards and phone calls, so nobody can see the whole hospital or prove what an improvement changed. Ospeli builds that record first.
TodayFree beds are found by walking the wards, with long gaps overnight.
With OspeliThe ward reports a bed's state the moment it changes.
TodayA&E waits are felt but not measured, step by step.
With OspeliArrival, triage, decision and bed are timestamped, so the slowest step is visible.
TodayHandoffs wait in trays and on boards until someone notices.
With OspeliEvery handoff is a task with an owner role and an alert.
TodayFaults are reported by phone and lost; simple fixes wait for a technician.
With OspeliScan a QR code to report, track the work order, and follow a step guide for simple fixes.
One system for the whole operation.
Start with the module that hurts most. Each one shares the same hospital model, the same definitions and the same audit trail.
Bed board
Bed states, the waiting list, allocation with reasons for declines, and today's flow.
Open the demoEngineering and maintenance
QR fault reports with photos, work-order queues, repeat-fault lists and step guides for simple fixes.
A&E and patient flow
Arrival to bed on one timeline, pressure levels and action cards when the department is under strain.
Process mapping
Walk a process, tap each step, and get a current-state map with times and roles drawn for you.
Playbooks
Flow reports, bottleneck finder, department redesign, structure review and business case packs.
Guides for administrators
Checklists and decision trees for routine operations, with a learning mode for new staff.
Capture once. Every answer builds on it.
The model is not the hard part. The data, the hospital's structure and the routines that use them are.
Capture
Staff record what happens with one tap on a shared tablet or phone: a bed freed, a fault reported, a patient triaged. It works offline and syncs later. Timestamps are a by-product, not extra work.
Model
Departments, wards, beds, assets, roles and metric definitions are configured once per hospital, without code. Every report uses the same definitions every day.
Playbooks
Ready-made routines turn the day's events into the outputs operations teams already produce: flow reports, redesign options, structure reviews.
Decide
Ospeli suggests; a named person decides. Every suggestion is logged with its inputs and the human action taken.
The work your operations team does every week, built in.
Each playbook has a fixed input, a fixed analysis and a ready-to-use output. No starting from a blank chat.
Daily flow report
Bottleneck finder
Department redesign
Process map
Structure review
Business case pack
A chat assistant starts every conversation empty.
Most of the effort in using general AI for hospital operations goes into explaining the hospital. Ospeli already knows it.
General AI chat
- Knows only what someone pastes in
- Needs the wards, roles and definitions explained each time
- Gives a different answer to the same question on different days
- Sends whatever you paste to an outside service
Ospeli
- Holds today's data, captured on the ward as work happens
- Knows your hospital: wards, beds, roles and metric definitions
- Runs the same playbook the same way, so results compare week to week
- Runs on your own server; no patient data leaves the hospital
Designed for unreliable networks, shared tablets and tight budgets.
Offline-first
A ward keeps working through a network outage and syncs cleanly afterwards.
Runs on your premises
One small local server per hospital. Cloud hosting is optional, in-country where the law requires.
Beside your EHR
Sits alongside the existing record system and never replaces it. Exchanges data using HL7 FHIR R4 and HL7 v2.
Export anything
Any date range exports to CSV and FHIR without a vendor. Your data stays yours.
Commodity hardware
Mid-range Android tablets, a mini PC and a UPS. No specialist kit to import.
Open core
The core is open source, so a ministry IT team can install and inspect it.
Safe to buy, safe to run.
Ospeli is built to the rules a public hospital board and its data protection officer will ask about first.
People decide, Ospeli suggests
No allocation, report or clinical draft is issued without a named person's action.
Patient data stays in the hospital
Nothing identifiable leaves the site unless the hospital approves that specific flow in writing.
Measures flows, never people
Ospeli measures beds, queues and handoffs by role. It never times or ranks a named individual.
Full audit trail
Every read and write of patient data is logged in a tamper-evident record.
Synthetic data until you approve
Demonstrations and testing use a fictional hospital. Real data is used only after formal written approval.
An off switch for every AI feature
Each assistive feature can be turned off per hospital and per ward.
Start with one to three wards and the bed desk.
A pilot runs alongside your existing paper process. Paper is retired on a ward only if its staff choose to.
- Weeks 1–2
Measure today's baselines on paper. Agree ward and bed names. Check clocks. Install tablets.
- Weeks 3–6
One ward and the allocation desk go live, alongside paper.
- Weeks 7–12
Two more wards join. Results are measured against the week-one baseline.
Talk to us about a pilot
Tell us your hospital, the wards you have in mind and who leads operations and nursing.
hello@ospeli.com Ospeli is in early development. Pilots are arranged through each hospital's own procurement route.