Front desks drown in phone calls for appointments, result copies, invoice balances, and referral paperwork — while patients expect the same self-service they get from every other modern service provider. Odoo ships a generic portal mixin that can expose sale orders and invoices to a logged-in contact, and a website layer for public pages, but out of the box neither knows anything about a Medical Record Number, a doctor's real slot availability, a validated radiology report, or the consent and intake workflows a clinical operation runs on. Bridging that gap with clicks alone is where native Odoo runs out of road: there is no standard model linking a res.partner portal user to a patient's clinical record, no booking engine that respects practitioner calendars and resource constraints, and no result-release gate that only shows reports a clinician has validated.

We build a Clinical Patient Portal as a dedicated Odoo module (its own __manifest__.py depending on website, portal, payment, mail, account, and your clinical-core-his-emr layer). Self-registration creates a portal res.users and securely links it to the correct patient record by MRN, with an identity-verification step so accounts can never see another patient's data. The booking front-end is an OWL/QWeb controller that reads live practitioner availability — computed fields (@api.depends) over each doctor's working schedule, existing appointments, and slot duration — so patients only ever see and reserve genuinely open times, which write straight back as clinical appointments. A result-release model exposes lab and radiology reports only once a clinician sets them to a validated state; patients view and download the underlying QWeb PDF, never a draft. The dashboard surfaces prescriptions, visit history, uploaded documents, and outstanding invoices, with online payment wired through Odoo's payment provider framework so a patient settles a balance in the same session.

Security is enforced the Odoo-native way, not bolted on: every model ships ir.model.access.csv entries plus record rules that scope a portal user strictly to their own MRN-linked records, so a crafted URL or guessed record id returns nothing. Care-team messaging rides Odoo's mail.thread, giving patients a threaded conversation that appears in the clinician's normal chatter with full audit history. Consent forms are presented for review and e-signature from the portal (pairing with your consent app), self-reported vitals and a pre-visit intake questionnaire flow into the record before the visit, and automated actions send appointment reminders and result-ready notifications by email. The entire portal inherits the storefront's 11-language and RTL conventions, and everything is built and tested against Odoo 17.0, 18.0, and 19.0, respecting Community-vs-Enterprise differences (e.g. we don't assume Enterprise-only widgets unless your edition provides them). Where you have an external booking site or kiosk, the same data is reachable over Odoo's XML-RPC/JSON-RPC API.

Because this is build-to-order, nothing ships until we've scoped it with you. After a short scoping call we confirm your MRN model, practitioner-calendar source, result-validation states, payment providers, and branding, then build, install on a staging environment, run UAT, and go live — typically one working week from confirmed scope. You receive the installable source for your version, documentation, training, and a post-go-live support window. Pricing starts from $999 (indicative, single-company base scope); multi-company or multi-branch deployments, deeper localization, extra payment/identity integrations, and migration of historical patient/portal data increase the quoted scope.