Odoo → MediRec implementation and migration plan

Disable Odoo logins at the freeze, rather than only announcing it

A revoked login is a guarantee; a memo is a hope. Costs nothing, and belongs in the runbook at step 3.

Make the importer refuse to clobber newer local edits

Before overwriting a row, compare its MediRec updated_at against the timestamp of its last import. If the local copy is newer, skip it and list it in the run summary.

Conflict detection without a conflict UI — roughly 3–4 h on top of the Importer base class. It converts the failure mode from "silent data loss" into "a line in the import report", and since the whole strategy depends on running the sync repeatedly, it is worth having whatever the policy says.

Corrected 2026-08-02. An earlier draft scoped this as "build the catalog importer, sourced from Odoo, 10–14 h". That work already shipped under MED-93 (Doctor Visit v1.1, READY FOR REVIEW). Two idempotent importers and both source catalogs are in the repo, and the dev database already holds 82,477 rows — 12,687 Spanish, 74,719 English.

W1a · Wire into the seed path — 2–3 h. DatabaseSeeder doesn't call either importer, so migrate:fresh --seed leaves icd_codes empty. Fresh environments and CI get no catalog, which makes diagnosis-picker tests vacuous rather than failing. Add a seeder that runs both commands, and mention them in CLAUDE.md — right now the only documentation is in ingest/*/README.md.

W1b · Reconcile against Odoo — 3–5 h. The one with real risk. Ours is the Mexican SSA/DGE catalog (12,687 terminal codes); Odoo's medical.pathology holds 12,423. Historical consultations reference Odoo's codes, so any code in Odoo but not in ours yields a migrated diagnosis pointing at nothing. Similar counts are not evidence of matching sets. Diff them, then decide per gap: add, map, or accept a null with a recorded reason. Must happen before the consultation import.

W1c · Search performance — 1–2 h, only if needed. 82k rows with LIKE %term% across two description columns will be slow on SQLite. Measure before optimising.

No longer true of this workstream: it is not a useful proving ground for the OdooSource pipeline, because these importers read local files and never touch Odoo. Phase 0 gets its first real exercise at the physicians import instead.

Rescoped 2026-08-02 against MED-111. This workstream was written from my own read of ir.attachment (3,167 rows) and assumed we'd pull the files onto the local private disk. Both assumptions were wrong: Erik has already extracted the documents — ~5,100 files, ~14 GB — and the target is Laravel Cloud, decided 2026-07-21. My 3,167 was a floor, not a total; the read-only account may have been subject to record rules, so reconcile against Erik's export rather than my query.

Scope confirmed by Q5: scanned medical visit forms, lab results, X-rays and other documents. All of them carry over, with no exclusion by type, and they must be available inside MediRec — Odoo is being decommissioned (Q4), so there is no read-only fallback.

MED-111 adds requirements this workstream didn't have: encrypted transfer, access limited to project participants, documented storage location and readership, a verification method against Odoo's counts, and confirmation that Erik's local copy is deleted or encrypted once the authoritative copy is on Laravel Cloud. The ticket is explicit that this is real patient data and needs a human at every step.

Polymorphic attachments table with disk, path, original filename, MIME type, size, checksum, uploader, odoo_id, and soft deletes.

Storage is already correct by default — the local disk roots at storage_path('app/private'), so files are not web-reachable. Serve through a controller that authorizes per record; never a public URL or storage:link.

Add attachment_audit_logs following the existing four-table pattern. Viewing a PHI document is an access event and should be recorded, not just uploads and deletes.

MIME allowlist must cover PDF and the scan formats (JPEG, PNG, TIFF). The size cap has to accommodate radiographs, the largest files in the set — don't inherit a default 2 MB limit and discover it during the import. Malware scanning is out of scope; flag it as a deployment concern rather than pretending it's handled.

Q5a answered — the X-rays are ordinary images, not DICOM. No imaging viewer is needed and the estimate stands: browser-native rendering covers the whole attachment set, so this remains a file feature rather than becoming a medical imaging one. The MIME allowlist above is sufficient as written.

The largest build — five tables: lab_test_units (106), lab_test_types (44), lab_test_parameters, lab_results (1,585) and lab_result_lines (1,492).

Result lines carry numeric and text values (Odoo has both), unit, lower and upper limits, an is_out_of_range flag computed on save, remark and sequence. Out-of-range values must be visually unmistakable — that is the clinical point of storing limits at all.

Add canManageLabResults() / canViewLabResults() to UserRole; laboratory_technician already exists with nothing behind it. New patient-detail tab, plus recent results surfaced on consultation forms.

PDF export deferred to W3b (8–12 h) — needs a new dependency.

notifiable_conditions seeded with the 91 MINSAL entries, plus a pivot to consultations and a multi-select on all five forms.

Split deliberately. Capture is unambiguous and can ship now; the return format and cadence depend on Q3. Build the data model first so we capture from day one and can generate any format retroactively.

Currently a placeholder page. Do not scope this from the gap analysis — scope it from watching someone use Odoo for twenty minutes.

Interim safe bets, all of which exist as Odoo pivot views today: consultations by type and period, consultations by provider, patient demographics, lab volume and turnaround.

New consultation_types lookup with name ES/EN, mapped AppointmentType, active flag and odoo_id.

Keep AppointmentType as-is. It correctly drives scheduling and provider eligibility. Add consultation_type_id for the finer clinical catalog — two concepts, two columns. Collapsing them would break eligibleProviderRoles().

A hand-curated mapping file resolves the 71 dirty Odoo values onto a clean set. Needs clinic sign-off, not a developer guess.

patient_pregnancies plus prenatal control visits linked to consultations. Scope from the real CONTROL PRENATAL records rather than Odoo's obstetric models, which are all empty and therefore tell us nothing about actual practice.

Broken on both sides: ~149 consultations, two orphaned report templates, and the medical.ultrasound model no longer exists. Needs a conversation before it needs a schema.

Split this. Add a category column and preserve the Odoo a/b/c/d value on import immediately — losing it would be irreversible. Reconciling it against calculateConsultationFeeCode() waits for Q2.

The column must land before the first patient import. Everything else about this gap can wait.

Add to consultations, matching the existing insurance_status on exam reports.

Not scheduled. G12 and G13 are effectively unused in Odoo; G11 needs a relevance check first.

MED-52…59 cover invoice generation, payment tracking and financial reporting. This document says billing is out of scope because Odoo holds zero invoices, zero payments and zero sales orders. Both can't be right — either the backlog is aspirational post-migration scope, or the clinic bills somewhere neither system can see.

Worth asking before it gets planned as parity work. It is nine tickets of potentially dead scope.

MED-35…42 include a medication database, prescription PDF export and medication history. This document rates prescriptions as an area where MediRec is ahead of Odoo — true of the data model, but measured against Odoo's HTML blob, not against MED-34's intended scope. Not a contradiction so much as two different yardsticks, but "MediRec ahead" shouldn't be read as "nothing to do here".