Hospitals running Odoo hit a wall the moment a patient is admitted rather than sold to. Odoo's native sale.order → account.move flow assumes a transaction that begins and ends, but an inpatient stay is an open-ended event: a bed is occupied for days, nurses chart vitals every few hours, doctors add orders, consumables and room charges accrue continuously, and only at discharge does all of that collapse into a single itemized bill. Core Odoo has no concept of a ward, a bed, an admission, or a length-of-stay charge, so teams end up tracking occupancy in spreadsheets and re-keying charges into invoices by hand — slow, error-prone, and impossible to audit.

We build a dedicated Inpatient Management module that models the stay as a first-class object. A new ecosire.inpatient.admission model (with models.Model, proper fields, and @api.depends computes for length-of-stay and running charges) links the patient (res.partner), the attending practitioner, the assigned bed, and every clinical and financial event during the stay. Facilities, wards, and beds are their own models with real-time occupancy state, so the admissions desk sees which beds are free before allocating one — with an ORM constraint that prevents double-booking an occupied bed. Nursing vitals (temperature, BP, pulse, SpO2, respiration) are captured on a one2many observation model with timestamps and the recording user, rendered in list and OWL-friendly form views for fast bedside entry. Bed-day charges, procedures, and consumed items post to the admission and, at discharge, generate a draft account.move through Odoo's standard accounting engine — so the discharge bill is native, taxable, and reconcilable rather than bolted on.

Everything ships as a clean installable module: a __manifest__.py declaring dependencies (base, mail for chatter/activities, account for billing), models under models/, views and menus in XML, QWeb PDF reports for the admission summary and the discharge invoice, and ir.model.access.csv plus record rules so ward staff, billing, and administrators each see only what their role permits. State transitions (admitted → in-treatment → discharge-pending → discharged → billed) are enforced in code, and automated actions can flag long-stay patients or trigger discharge-billing checklists. Because it uses Odoo's own ORM and accounting, the data is reachable over the standard XML-RPC / JSON-RPC API for lab systems, insurance portals, or reporting tools, and it runs on Odoo Community — no Enterprise dependency — while remaining compatible with Enterprise if you run it.

Delivery is build-to-order. It starts with a short scoping call to confirm your ward and bed structure, charge model, billing rules, and target Odoo version (17.0, 18.0, or 19.0). We then build against a staging copy of your database, walk you through UAT, and deploy only once you sign off — typically one working week from confirmed scope. You receive the full source, documentation, a training session, and a post-go-live support window. Pricing starts from $999 (indicative, single-company base scope); multi-hospital or multi-company rollout, insurance/TPA claim integration, deeper localization of the discharge invoice, and migration of existing admission history increase the quoted scope. You get a fixed quote after the scoping call — never a surprise.