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.

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.