Federation — PHCWR → NHWR (mCSD ITI-91)
Viewing as
Live mCSD federation channel
PHCWR → NHWR via IHE ITI-91. Each row below is a real push to a second FHIR R5 server. Idempotent by design, audit-receipts retained for 7 days. Synthetic and superseded records are not federated — they're demo data or have been replaced by an authoritative real entry. Skip audit log at
/skipped (90-day TTL).Registry federation receipts
NPHCDA PHCWR owns posting. FMOH NHWR owns identity. They federate.
Every regulated-cadre worker registered in PHCWR is pushed up to NHWR via the IHE mCSD ITI-91 transaction — the IHE standard for healthcare registry federation. PUT-by-id keeps it idempotent: re-runs are safe.
Total receipts
—
Loading
Success rate
—
—
NHWR target
phcwr-nhwr
https://phcwr-nhwr.fly.dev/fhir
Last sync
—
Awaiting first push
Live demo theatre. Click to trigger a fresh batch push from PHCWR to NHWR. New receipts appear in the table below.
Recent federation receipts
Loading live receipts…
IHE mCSD (Mobile Care Services Discovery) is the international profile for federating healthcare registries. ITI-91 — Request Care Services Updates — is the transaction Source registries (PHCWR) use to push incremental updates of their resources to a Target registry (NHWR). We stamp meta.profile on every resource so Target registries can validate conformance, and retain PHCW-UID as a secondary identifier so NHWR can match back. See the ITI-91 spec.
What you just saw
A Cloudflare Worker (phcwr-federation) running our mCSD ITI-91 push. It pulls regulated-cadre Practitioners from PHCWR's HAPI FHIR R5 server, projects them into NHWR's identity-only scope (name + qualification + licensing council), and PUTs them to our mock NHWR — a second HAPI R5 instance running on Fly in
jnb for the same data residency posture. Each push writes a tamper-evident receipt to KV with a 7-day TTL. The presenter line: “PHCWR is not competing with NHWR. They federate. Click any receipt and you can prove it.”