Provider identity is out of sync between Odoo and OpenMRS at KAHS

Headline

How provider information actually flows

Two independent paths write and read provider identity, and they disagree. The write path runs once, at record creation. The read path runs on every printed report.

Write path — Odoo pushes to OpenMRS on create only

There is no write() override, so editing a practitioner in Odoo never reaches OpenMRS. Failures in create() are caught and logged, then swallowed — the record saves anyway with a null uuid.

Read path — the bridge asks Odoo to name each provider

The whole read path hinges on one line in bahmni_pos/controllers/clinical.py:1166:

Practitioner.search([("provider_uuid", "in", provider_uuids)])

No active_test=False — so archived practitioners silently vanish from reports they signed. No uniqueness guarantee — so one provider uuid can return several different doctors.

Finding 1 — Seven Odoo rows point at the wrong human

OpenMRS system_id embeds the Odoo record that created the account (clinical-provider-<odoo_id>-<hash>), which gives an independent provenance trail. Comparing it against the current Odoo row exposes two distinct failure modes.

Mode A — recycled rows (ids 7, 14, 19, 39, 52)

The row was created and synced for person A, then later renamed to person B in Odoo. Because there is no write() sync, OpenMRS kept person A. Two humans now share one row, and the system_id still names the original.

Mode B — cloned identity (ids 149, 161, 162)

uuid, provider_uuid, lab_uid and last_sync_date are declared readonly but not copy=False (bahmni_pos/models/hospital/practitioner.py:81-99). Duplicating a practitioner in the Odoo UI clones the foreign keys, so three Odoo rows — and three SENAITE lab contacts — now resolve to one OpenMRS provider. The two rows have been flip-flopping the account's name since June.

Live evidence. One provider uuid, two different doctors with two different NMC numbers:

$ curl -s -X POST http://localhost:8069/api/providers/ \
    -d '{"providers":["afc895e4-7454-4f13-8feb-775426bc240d"]}'

[{"name":"Dipendra Gharti Mahar","profession":"medical_records_technician",
  "license":"B-14759 Med GM","title":"HA"},
 {"name":"Bhagawati Rawal",     "profession":"healthcare_administrator",
  "license":"B-6322",          "title":"HA"}]

This provider signs live encounters, so any report rendering that visit lists both people as signatories.

Finding 2 — the bridge cannot name 16 of the 119 providers in active use

The 16 break into three groups:

Finding 3 — data quality on the Odoo side

The licence duplicates are not cosmetic: who_insurance/models/claim/claim.py:3145 puts license_number straight onto the insurance claim as the practitioner's NMC number.

Remediation plan

Acceptance test

The same read-only audit used to produce this report doubles as the verification suite:

Target for provider resolution is 117, not 119 — superman and LABSYSTEM are deliberately excluded rather than resolved.

Incidental — ehrplus-odoodb is not actually unhealthy

Odoo connects via HOST=odoodb-dog → pgdog (ehrplus-odoodb-dog) → ehrplus-odoodb, whose Postgres listens on 5433. pgdog is healthy and passing traffic. The container's healthcheck is pg_isready -h localhost -U odoo with no -p 5433, so it probes the wrong port and reports unhealthy forever. Cosmetic, but it is what lights up the fleet health check across the sites running pgdog.