A patient-facing website and portal front-end for Odoo where patients self-register, book appointments against real doctor availability, view validated results, pay invoices, and message their care team. Built to order by ECOSIRE on top of Odoo's website, portal, payment, and mail framework. Built to order by ECOSIRE for Odoo 17, 18, 19 — indicative price from $299.00 USD; request a quote for a scoped proposal.

A patient-facing website and portal front-end for Odoo where patients self-register, book appointments against real doctor availability, view validated results, pay invoices, and message their care team. Built to order by ECOSIRE on top of Odoo's website, portal, payment, and mail framework.
Keine Zahlung jetzt. Dies sendet eine Angebotsanfrage an unser Team – wir melden uns per E-Mail mit Preisen und nächsten Schritten.
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.
Patient self-registration that provisions a portal `res.users` and links it to the correct patient record by MRN, with an identity-verification gate before any clinical data is exposed
Online appointment booking driven by live practitioner availability — computed slot fields (`@api.depends` over doctor schedules, existing bookings, and slot duration) so only genuinely open times are reservable
Booked slots write back as real clinical appointments in the `clinical-core-his-emr` layer, keeping the front desk calendar and portal in one source of truth
Result-release model that shows lab and radiology reports only after a clinician sets them to a validated state — patients download the QWeb PDF, never a draft
Portal dashboard surfacing prescriptions, visit history, and active care plans pulled read-only from the clinical record
View and pay outstanding invoices online through Odoo's `payment` provider framework, reconciling straight to `account.move`
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 2–4 weeks from confirmed scope. You receive the installable source for your version, documentation, training, and a post-go-live support window. Pricing starts from $299 (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.
Wants to cut front-desk phone volume for bookings, result copies, and balance enquiries by moving patients to self-service, without adding a separate portal vendor or a second login for staff to manage.
Needs a modern, branded, multilingual patient-facing experience that reflects well on the institution, works in RTL for regional audiences, and integrates seamlessly with the website they already run on Odoo.
Cares about faster invoice settlement and fewer unpaid balances — wants patients to see and pay outstanding invoices online through the same providers the practice already uses, reconciling cleanly to accounting.
Owns the Odoo instance and needs a portal that respects record rules and access CSVs, doesn't leak cross-patient data, upgrades cleanly across 17/18/19, and hands over as source they can maintain.
Kaufen Sie die Lizenz auf ecosire.com und laden Sie die ZIP-Datei des Clinical Patient Portal-Moduls von Ihrem Konto-Dashboard herunter.
Extrahieren Sie die ZIP-Datei in Ihren Odoo-Ordner für benutzerdefinierte Add-ons auf dem Server (oder laden Sie sie über „Apps“ > „Aus Datei installieren“ auf Odoo.sh/Runbot hoch).
Aktivieren Sie den Entwicklermodus, öffnen Sie „Apps“, klicken Sie auf „Apps-Liste aktualisieren“, suchen Sie nach „Clinical Patient Portal“ und klicken Sie auf „Installieren“.
Öffnen Sie das neue Menü, fügen Sie Ihren ECOSIRE-Lizenzschlüssel ein, verbinden Sie alle externen Anmeldeinformationen (Shopify, Amazon, Stripe usw.) und speichern Sie.
Führen Sie den integrierten Verbindungstest aus, synchronisieren Sie Ihre ersten 10 Datensätze und planen Sie den wiederkehrenden Cron. Wenden Sie sich an den Support, wenn etwas fehlschlägt.
| Kriterium | ECOSIRE | Benutzerdefinierter Build | Konkurrent | Odoo Native |
|---|---|---|---|---|
| Fit to your MRN & clinical workflow | Built to your exact MRN model, availability logic, and result-release states | Achievable but you own all design decisions and rework | Generic schema you must adapt to your clinic | |
| Appointment booking against real availability | Live computed slots from practitioner calendars, writes back as clinical appointments | Must be designed and built from scratch | Varies; often a simplified or fixed-slot booker | |
| Validated result release | Reports shown only after clinician validation; QWeb PDF download | You define and implement the release gate | May expose documents without a clinical validation state | |
| Cross-patient data security | Record rules + access CSV scoping every user to their MRN, tested | Depends entirely on your implementation discipline | Depends on vendor's rule design; you must verify | |
| Online invoice payment | Wired to your Odoo payment providers, reconciles to account.move | Build and test the payment flow yourself | Sometimes included, provider set may be limited | |
| Multilingual & RTL | Full 11-language + RTL inheriting storefront i18n | Translate and RTL-test everything yourself | Often English-first with partial translations | |
| Version support & handover | Built for 17/18/19, source + git repo + docs handed over | You maintain it, no external handover | Binary/OPL or AGPL app on vendor's release cadence | |
| Total effort to production | Scoped, built, UAT'd, and supported by us in 2–4 weeks | Longer; full spec, build, and QA on your team | Fast to install but slow to fit; adaptation cost hidden |
This is a build-to-order module, not an instant download. After a scoping call to confirm your MRN model, practitioner calendars, result-validation states, and payment providers, typical delivery is 2–4 weeks from confirmed scope. We build on staging, run UAT with you, then go live. Complex multi-company or heavy data-migration scopes extend that, and we tell you the realistic timeline in the quote.
No. ECOSIRE builds, installs, and supports it specifically for your clinic and your Odoo version. Unlike a typical off-the-shelf module, it's fitted to your actual MRN linkage, doctor availability logic, and result-release workflow rather than a generic schema you'd have to adapt yourself.
Pricing starts from $299 as an indicative, single-company base-scope figure. It's not a firm fixed price — after a short scoping call we give you a fixed written quote. Drivers that increase scope include multi-company or multi-branch setups, deeper localization, additional payment or identity integrations, and migrating historical patient or portal data.
Every build includes a post-go-live support window for defect fixes and configuration adjustments. Because you receive the full source and git repo, you can maintain it yourself or engage us for ongoing support and version upgrades. We build against 17.0/18.0/19.0, and moving to a newer Odoo release is a scoped upgrade engagement.
Security is enforced with Odoo's native `ir.model.access.csv` and record rules, so every portal user is scoped strictly to their own MRN-linked records at the ORM level. A crafted URL or guessed record id returns nothing rather than another patient's data. Result release is additionally gated so only clinician-validated reports are ever visible.
It builds on `website`, `portal`, `payment`, `mail`, and `account`, which exist in both editions, so it can run on Community. Where a capability depends on an Enterprise-only feature in your stack, we confirm your edition during scoping and design around it rather than assuming Enterprise widgets are present.
Yes. All the portal's models and appointment logic are reachable over Odoo's XML-RPC/JSON-RPC API, so an external booking site, kiosk, or mobile front-end can create bookings and read results through the same validated, permission-checked layer the portal uses.
A patient-facing website and portal front-end for Odoo where patients self-register, book appointments against real doctor availability, view validated results, pay invoices, and message their care team. Built to order by ECOSIRE on top of Odoo's website, portal, payment, and mail framework.