Hospitals and surgical centers running Odoo hit a wall when the operating room becomes the coordination bottleneck. A surgical case is not a sales order or a calendar event: it needs a booked theatre and time block that cannot double-book, a named surgeon plus anaesthetist and scrub/circulating nurses whose availability and role qualification must be checked, a procedure with an expected duration, required instrument sets and implants, and a sign-off trail proving the sign-in / time-out / sign-out safety steps were actually completed before the first incision. Odoo core gives you calendar.event, hr.employee, project.task and stock — useful primitives, but none of them model theatre capacity, enforce a checklist gate, or hold the clinical fields (ASA grade, procedure side/laterality, anaesthesia type) that a real OR schedule depends on. Teams end up managing surgery in spreadsheets and whiteboards alongside Odoo, and the two never reconcile.

ECOSIRE builds a dedicated Surgery Management application for your Odoo database. At its core is a surgery.case model (models.Model) linking the patient (res.partner), the primary surgeon and full care team (hr.employee), the operating room (a surgery.theatre resource with working-hours and turnaround-time), the procedure catalogue, and a state machine (draft → scheduled → checklist_ready → in_progress → recovery → completed, with cancelled). Scheduling conflicts are prevented server-side: an overlap constraint (@api.constrains plus an SQL exclusion where appropriate) blocks two cases claiming the same theatre or the same surgeon in the same window, and @api.depends computes expected end time from procedure duration and turnaround buffer. Safety checklists are their own models — a configurable surgery.checklist.template with surgery.checklist.line items grouped by phase — and a case cannot advance to in_progress until every mandatory sign-in and time-out line is confirmed, giving you a hard, auditable gate rather than a reminder people ignore.

The team-assignment side enforces the rules that matter clinically: role-qualification checks so only staff flagged for a role can be assigned to it, availability checks against the theatre schedule and time-off, and a clean many-to-many of team members per case with their role. On top of the data model we build the operational surface: a theatre-day Gantt/calendar view (OWL-based drag-to-reschedule where your edition supports it), kanban by state, a QWeb operating-schedule report and per-case surgical record / checklist PDF for printing or the chart, and automated actions (ir.cron / base automation) for pre-op reminders and unconfirmed-checklist escalations. Access is locked down with ir.model.access.csv plus record rules so surgeons, OR coordinators, and read-only auditors each see the appropriate scope, and every schedule and integration point is reachable over Odoo's XML-RPC/JSON-RPC API for your imaging, LIS, or bed-management systems. We target Odoo 17.0, 18.0, and 19.0 and are explicit about Community vs Enterprise: the full data model, checklists, security, reports and calendar views run on Community, while the native drag-and-drop Gantt planning widget is an Enterprise convenience — on Community we deliver an equivalent calendar/OWL scheduling view so no capability is lost, only the exact widget differs.

Because this is build-to-order, nothing is downloaded and switched on instantly. After you request a quotation we run a short scoping call, confirm the exact scope in writing, then build, test on a staging copy of your database, and hand over — typical delivery is one working week from confirmed scope depending on complexity and integrations. Pricing starts from $999 (indicative, single-company base scope); multi-hospital / multi-company theatre pools, deeper localization, and integrations with external clinical systems (EMR, LIS, imaging, billing) increase the quoted scope. You receive a fixed quote after the scoping call, never a surprise bill.