Healthcare providers on Odoo quickly hit a wall when patients need self-service access to their own records. Odoo's stock website portal (portal.mixin, the /my controllers) was designed around sales orders, invoices, and project tasks — not encounters, clinical documents, lab results, or consent forms. Front-desk staff end up emailing PDFs manually, results get lost in inboxes, and there is no audited, permissioned surface where a patient can log in and see only their own information. The moment you try to expose anything clinical through the native portal you also inherit a data-segregation problem: without carefully written record rules, one patient's portal query can reach another patient's data.

We build a dedicated Patient Portal Management module that extends the Odoo portal into a proper patient-facing surface. On the backend we add clinical models (models.Model) for patient records, encounters, and shareable documents, each linked to res.partner, with computed fields (@api.depends) for status, next appointment, and result-ready flags. The security layer is the heart of the build: granular ir.model.access.csv plus record rules that scope every model to user_partner_id = env.user.partner_id (and its commercial hierarchy where a guardian or caregiver relationship applies), so a logged-in patient can only ever read their own rows — enforced at the ORM level, not just hidden in the UI. Portal pages are delivered as QWeb templates and portal.mixin controllers so they inherit Odoo's breadcrumb, pager, and access-token patterns; document downloads run through controlled ir.attachment routes with signed access checks rather than public URLs. We wire automated actions to notify a patient when a new document or result is published, and expose read-only endpoints over the JSON-RPC/XML-RPC API when you need to sync with an EMR or a booking front end.

Because this is made-to-order, nothing ships as a generic download — we build your version against your Odoo edition and your data model. We confirm which document types patients may see, whether you run Community or Enterprise (Enterprise unlocks tighter approval flows, studio-adjacent extensions, and some sign/document features we can lean on; Community gets a fully equivalent hand-built path), and how patient identity maps to res.partner in your existing database. Delivery is typically one working week from a confirmed scope: we develop on a staging branch, run UAT with your team against real-shaped test data, then deploy to production with a rollback plan and hand over the git repository.

Delivery is a defined path, not an open-ended engagement. After a short scoping call we send a fixed written quote and a milestone plan; you approve the scope, we build on staging, you sign off through UAT, and we cut over to production with a rollback plan and a post-go-live support window. Pricing starts from $999 (indicative, single-company base scope); multi-company hospital groups, EMR/lab-system integrations, additional document workflows, or deeper localization increase the quoted scope. You receive a firm number before any build work begins.