AnchorOverride

Anchor Date Operations override writes and history (internal).

📄️A practitioner's anchor history, newest first

Backs the panel's Recent Changes list and supplies the Review callout's previous -> current values, which the panel cannot derive: it reads current state only, so 'what it was before' exists nowhere but these events. Ordered by commit time, newest first. The audit store is written asynchronously, so a change saved seconds ago may not appear yet; the endpoint returns what exists rather than waiting. Shared-workflow events (entityType SHARED_RECORD and SHARED_CREDENTIALING_WORKFLOW) are not returned, and totalCount excludes them.

📄️Remove a practitioner's override

Hands the record back to the platform (PRD 3i/4i): the manual date is cleared and every participation row goes back to NULL, which means 'follows eligibility'. The effective date becomes the platform's CURRENT calculated value, not the one that was in force when the override was made (PRD 5.14). This is the only transition back to AUTOMATIC.

📄️Apply a practitioner's override state

The body is the COMPLETE desired state, which is why this is a PUT: a partial body would have to say something about tenants it does not mention, and every available answer is wrong. An empty participatingTenantIds list is meaningful — zero participation is an override that voids the anchor, not the absence of one. The record is re-read inside the save and validated against what was read, never against the panel's copy; every violation is returned at once.

📄️Acknowledge a raised review, keeping the override as it is

Writes the review half and nothing else — both dates and participation are untouched. It deliberately does not go through the save path, which would re-derive the date from current scheduling dates and could silently move a stored value on what is meant to be an acknowledgement.