A made-to-order Odoo radiology information system: imaging ordering from the EMR encounter, DICOM modality worklist for the scanners, radiologist reporting with signed final reports, and an embedded web DICOM/PACS viewer — all tied to the patient record. ECOSIRE builds, installs, and supports it after a scoping call. Built to order by ECOSIRE for Odoo 17, 18, 19 — indicative price from $599.00 USD; request a quote for a scoped proposal.

A made-to-order Odoo radiology information system: imaging ordering from the EMR encounter, DICOM modality worklist for the scanners, radiologist reporting with signed final reports, and an embedded web DICOM/PACS viewer — all tied to the patient record. ECOSIRE builds, installs, and supports it after a scoping call.
No payment now. This sends a quote request to our team — we'll follow up by email with pricing and next steps.
Imaging centers and hospital radiology departments live between two systems that never talk to each other: the clinical record where the study is ordered, and the modality/PACS world where images are actually acquired and read. In plain Odoo, an "X-ray" or "MRI" is just a product.product line on an invoice — there is no concept of a study status pipeline, no way to push an order to a CT scanner, no radiologist worklist, and certainly no way to view the images. Native Odoo (base, product, account) runs out of road the moment a technologist asks "what's on my worklist today" or a radiologist asks "show me the priors for this patient's chest." A typical off-the-shelf apps.odoo.com module usually stops at cataloguing imaging services and printing a report template; it does not speak the DICOM protocols that connect Odoo to real hardware, and it leaves the viewer out entirely.
Imaging study catalog modeled by modality (X-ray, CT, MRI, USG) as dedicated records with per-study pricing linked to `product.product` for billing
Imaging order raised directly from an EMR encounter, carrying clinical indication, requested procedure, laterality/body part, and priority (routine/urgent/stat)
Study status state machine (`ordered → scheduled → acquired → reported → signed`) enforced by `@api.depends` computes and Odoo automated actions
DICOM Modality Worklist (MWL) export so scanners pull accession number, demographics, and scheduled procedure instead of manual entry
Embedded open web DICOM viewer (OHIF-style) as an OWL component opening the study's `DICOMweb`/PACS URL in-record
Automatic prior-study comparison list for the same patient and body part, surfaced beside the current study for context reading
This build fills that gap end to end. On top of your existing clinical-core-his-emr and Odoo's mail/web layers, we model an imaging study catalog by modality (X-ray, CT, MRI, USG) with per-study pricing, then let a clinician raise an imaging order directly from an EMR encounter carrying the clinical indication and priority (routine/urgent/stat). Each order becomes a study record whose status advances through ordered → scheduled → acquired → reported → signed via a state machine on a models.Model with @api.depends computes and Odoo automated actions gating each transition. The key interoperability piece is a DICOM Modality Worklist (MWL) export: scheduled studies are published so modality equipment pulls the day's order list — accession number, patient demographics, requested procedure, and scheduled station — instead of technologists re-keying it. The viewer is delivered as clean-room glue: an embedded OWL component that opens an open web DICOM viewer against the study's DICOMweb / PACS URL, with a prior-study comparison list assembled for the same patient and body part so the radiologist reads in context.
Radiologists report against per-modality structured templates (findings and impression) rendered in Odoo views, then sign off with an electronic signature that locks the final report; the locked report is produced as a QWeb PDF and cannot be silently edited afterward. Technologists keep an acquisition log capturing the views performed, contrast used, and dose notes. On sign-off, the report and the key images are pushed back into the patient's EMR timeline via the shared mail.thread/chatter backbone, and a billing hook posts the imaging charge to the patient's invoice through account. Access is governed by ir.model.access.csv plus record rules so an ordering clinician, a technologist, a reporting radiologist, and billing each see only what their role should — with multi-company record rules available when you run more than one site. Everything is exposed over Odoo's XML-RPC/JSON-RPC API so an external PACS broker or reporting workstation can read study state and post results programmatically.
Because this is built to order, nothing ships as an instant download. After a short scoping call we confirm the exact modalities, your PACS/DICOMweb endpoint, report templates, and billing rules, then build your version against your Odoo 17.0, 18.0, or 19.0 database (Community or Enterprise — we flag any Enterprise-only dependency up front). Typical delivery is 2–4 weeks from confirmed scope, on staging first, with UAT before go-live. Pricing starts from $599 (indicative, single-company base scope); multi-company/multi-site coverage, deeper PACS/DICOMweb and HL7 integration, additional modality report templates, localization depth, and historical study data migration volume increase the quoted scope. You receive a fixed quote after the scoping call — the from-price is a starting point, not a firm figure.
Runs a hospital imaging department and needs ordered studies, technologist worklists, and radiologist reporting to live inside the same Odoo record as the patient — without buying and integrating a separate heavyweight RIS/PACS. Cares most about the study pipeline, signed reports, and role-based access.
Operates a standalone diagnostic/imaging center and wants ordering, viewer access, reporting, and billing in one system. Needs the modality worklist so scanners pull orders automatically and charges to post cleanly to patient invoices, keeping overhead low.
Reads studies and signs reports. Needs an embedded viewer opening the study's images, a prior-study comparison list, per-modality structured templates, and an electronic sign-off that produces a locked final PDF they can stand behind.
Owns the PACS, DICOMweb endpoint, and Odoo instance. Needs clean MWL export, a documented XML-RPC/JSON-RPC surface, a clear security model, and clean-room viewer glue rather than a black-box integration they can't maintain.
Buy the license on ecosire.com and download the Clinical Imaging — Radiology (RIS) with DICOM/PACS Viewer module ZIP from your account dashboard.
Extract the ZIP into your Odoo custom addons folder on the server (or upload via Apps > Install from file on Odoo.sh / runbot).
Activate Developer Mode, open Apps, click Update Apps List, search for Clinical Imaging — Radiology (RIS) with DICOM/PACS Viewer, and press Install.
Open the new menu, paste your ECOSIRE license key, connect any external credentials (Shopify, Amazon, Stripe, etc.), and save.
Run the built-in connection test, sync your first 10 records, and schedule the recurring cron. Contact support if anything fails.
| Criterion | ECOSIRE | Custom Build | Competitor | Odoo Native |
|---|---|---|---|---|
| Study status pipeline | Full `ordered → scheduled → acquired → reported → signed` state machine with automated-action gates | Whatever you build; correctness and edge cases are on you | Often a basic status field, rarely an enforced pipeline | |
| DICOM Modality Worklist (MWL) | MWL export so scanners pull the order list — no re-keying at the console | Rarely attempted; requires DICOM protocol knowledge | Usually absent — most stop at the report template | |
| Embedded DICOM/PACS viewer | Open web viewer embedded as an OWL component against your DICOMweb URL | Possible but significant clean-room integration effort | Typically no in-record viewer at all | |
| Radiologist reporting | Per-modality structured templates (findings/impression) with signed, locked PDF | Buildable, but template governance and locking are non-trivial | Generic report template, often no enforced sign-off lock | |
| Prior-study comparison | Auto-assembled prior list by patient + body part beside the current study | Extra build; matching logic must be designed | Generally not provided | |
| EMR + billing integration | Report/key images to the patient timeline; charges posted to `account` invoice | You wire it up and maintain it | Billing sometimes present; EMR timeline push usually not | |
| Support & ownership | Built, installed, supported; full git repo + docs + training handed over | Depends entirely on your in-house team's availability | Vendor support varies; you adapt to their roadmap | |
| Delivery model | Build-to-order, 2–4 weeks from confirmed scope, staging + UAT first | Open-ended timeline driven by your backlog | Instant download, but generic and integration still on you |
It connects to yours. The module provides the RIS layer inside Odoo — ordering, worklist, reporting, sign-off, billing — plus a DICOM Modality Worklist (MWL) export for your scanners and an embedded open web viewer that opens against your existing PACS/DICOMweb URL. We do not sell or bundle PACS storage; we build the clean-room glue that ties Odoo to the image store you run. If you don't yet have a DICOMweb-capable archive, we can advise on open options during scoping.
This is a build-to-order module, not an instant download. Typical delivery is 2–4 weeks from confirmed scope. The clock starts once we've agreed the modalities, your PACS/DICOMweb endpoint, report templates, and billing rules on the scoping call — not from the day you enquire. We build on a staging database first and run UAT with you before any production go-live.
Pricing starts from $599 as an indicative single-company base-scope figure. It is a starting point, not a fixed price. Drivers such as multi-company/multi-site coverage, deeper PACS/DICOMweb or HL7 integration, extra modality report templates, localization, and historical study-data migration change the number. After a 15–45 minute scoping call we send a fixed written quote for your exact requirements.
We build for Odoo 17.0, 18.0, and 19.0 on both Community and Enterprise. The core builds on `base`, `mail`, `product`, `account`, `web`, and your `clinical-core-his-emr`. If your requested scope pulls in any Enterprise-only dependency, we tell you before you commit so there are no surprises at install time.
Every build includes a post-go-live support window for defect fixes and configuration adjustments, and you receive the full git repository so nothing is locked to us. Because your version is custom-built, it is not auto-updated from a marketplace; when you move to a newer Odoo release or need new modalities, templates, or integrations, we scope and quote that as a follow-on engagement. Ongoing support/maintenance retainers are available.
Yes. For each study the module assembles a prior-study comparison list for the same patient and body part and surfaces it beside the current study, so the radiologist reads in context and can open priors in the embedded viewer. The comparison logic (matching on body part, modality, and date window) is confirmed during scoping.
No — that's by design. Sign-off applies an electronic signature and locks the final report; the locked report is rendered as a QWeb PDF and cannot be silently edited afterward. Any correction follows a controlled addendum/amendment path rather than an in-place edit, preserving the medico-legal audit trail via Odoo's logging and chatter.
A made-to-order Odoo radiology information system: imaging ordering from the EMR encounter, DICOM modality worklist for the scanners, radiologist reporting with signed final reports, and an embedded web DICOM/PACS viewer — all tied to the patient record. ECOSIRE builds, installs, and supports it after a scoping call.