Skip to main content

Roll back an accidental practitioner termination

PUT 
/practitioners/terminate/rollback

Reverses a termination that should not have happened (CP-37299): removes the termination date, reason and informed-date from EVERY level they were set for this practitioner — core slice, tenant practitioner, group, group-network, location, location-network and location-network-specialty rows — and regenerates each row's stored status from its surviving effective date, so relationships read Active or Pending again instead of Inactive.

One atomic write. Every row clears together or none does; a failed call leaves the practitioner exactly as terminated as before.

Practitioner-wide, not level-scoped. There are no scope fields: pass tenantPractitionerId OR certifyPractitionerId (exactly one). A certifyPractitionerId clears every contributing slice this tenant owns; slices belonging to other tenants are never touched.

This is an undo, not a reinstatement. For a practitioner re-entering a network after a gap — which needs a second effective/termination range — this is the wrong endpoint.

Monitoring flags closed by the termination are reopened, then recalculated so any that are no longer valid (a licence renewed while the practitioner was terminated) are retired again rather than resurfacing. Only flags the termination itself closed are reopened -- flags a reviewer marked seen are left alone. This runs after the field clear commits and is fail-soft: inspect the flags block in the response, since a 200 means the dates were cleared, not necessarily that the flag side landed.

Not reverted: credentialing workflows cancelled by the termination stay cancelled; NPDB/CAQH enrolment is not restored. nextCredentialingDate is deliberately left untouched, since an undo is not a re-credentialing event.

Not idempotent. A second call for the same practitioner returns 400, because by then there is no termination left to roll back.

Failure is safe. The write is one all-or-nothing batch, so a 4xx or 5xx leaves the practitioner exactly as terminated as before and the call can be retried. A data-access-layer fault surfaces as 502, not 500.

Gated by practitioner.termination.rollback.enabled (default true); returns 404 as if the endpoint did not exist while disabled.

Request​

Responses​

Rolled back. clearedRecords is how many rows were written and rollbackTraceId correlates the structured events for this reversal. A 200 means the termination fields were cleared; the flags block reports separately whether the monitoring side landed, so callers that care must inspect reopenOk and recalculateOk rather than trusting the status code alone.