SharedCredentialingWorkflow

The NSCP Shared Credentialing Groups listing and rollup repair (internal).

📄️The Shared Credentialing Groups listing for one Anchor Group

One row per Shared Credentialing Group, with the group's derived status, coverage, cycle and due date read from the group row. Ordered by due date, earliest first and empty dates last, by default. Closed groups — those with no open member workflow — are excluded unless includeClosedGroups is set; no filter admits one implicitly. The search and filter parameters are accepted and ignored until CP-39680 implements them.

📄️Enqueue an assignment for each eligible group in the selection

Answers 202 once the tasks are enqueued, NOT once the work is done: a 500-row selection cannot be held open for a synchronous answer. One task per group, so a group that keeps failing retries and dead-letters alone instead of dragging the rest of the selection through every redelivery. Outcomes are read back from the listing and the audit log.

📄️Enqueue a withdrawal for each eligible group in the selection

Same dispatch shape as bulk-assign: 202 once enqueued, one task per group. No analyst is involved, so shore is never resolved and R15's routing question does not arise — the selection is checked for scope, authority and open members only.

📄️One shared credentialing run

The run's own row: its derived shared status, the coverage rollups, the cycle and the credentialing due date. Every value is derived and persisted by the Core story; this read exposes the row and computes nothing.

📄️Assign or unassign one shared credentialing group

Called by a Cloud Task, one group per task. A null or absent assignedTo unassigns. onshoreAssignedTo is required when the group holds onshore-only members: R15 forbids an offshore analyst taking them, so one group can legitimately need two people. Every non-terminal member is written, each resolved to the analyst its own scope demands; an all-terminal group is a no-op with membersWritten 0.

📄️Recompute the display group keys on one shared run's member workflows

Recomputes credentialingDisplayGroupKey on every row of every catalog section of each member workflow, and writes only the sections where a stored key is missing or different. Idempotent: a second run reports UNCHANGED and writes nothing. Completed members are skipped, and a member that fails is reported without stopping the others. Use dryRun to see what would move first.

📄️Write one identity field to the named member tenants

The analyst chooses the targets, so the status lock does not apply and no confirmation is asked for: no tenant gains data it did not already hold.

📄️Set one identity field on every member the lock allows

The server chooses the targets, so it applies the status lock and requires the tenant-share confirmation. Members the lock protected come back named.

📄️The shared credentialing page's head

Every participating tenant, the identity agreement across them, their user-defined fields and the practitioner's earlier runs — from one read of the member documents.

📄️Set one member's File Type (Clean or Non-Clean) or hide its findings, under its own tenant

Writes a File Type change on one member workflow of this shared credentialing run, under the tenant named in the body, while the member is at PSV Complete. The shared page spans tenants and the tenant-scoped `PATCH /credentialing-workflows/{workflowId}/practitioner-file-type` can only answer for the caller's selected one, so the member's real tenant travels in the body. `hiddenFindingRuleKeys` is the full set of findings to hide from the PSV packet; without `fileType` the save is hide-only: it writes no analyst File Type, so the verdict stays the platform's, and needs no reason. A Non-Clean change always needs a reason; a Clean change needs one while a finding stays unhidden; either needs one when the member's verdict could not be evaluated or there is none. The caller must hold the File Type permission in the body tenant, and the member's tenant must have PSV transparency switched on. Repeating the newest analyst change with the same hides is a 204 that writes nothing.

📄️Retry one member's file-type verdict, under its own tenant

Evaluates the clean / non-clean rules again for one member workflow of this shared credentialing run whose verdict could not be evaluated, under the tenant named in the body, and stores the result. Synchronous: bounded by the rule-engine timeout plus a read and a write. The member must be at PSV Complete with a verdict that is not frozen. A verdict that is already derived answers DERIVED without calling the rules engine. The caller must hold the File Type permission in the body tenant. Re-read the members for the value.

📄️Set one member's Lines of Business to Cred, under its own tenant

Writes `lineOfBusiness` on one member workflow of this shared credentialing run, under the tenant named in the body. The write itself is the service behind `PATCH /credentialing-workflows/{workflowId}/line-of-business`, so the conflict retry and the change log behave as they do from the tenant's own page. Unlike that route, this one refuses a member outside the States to Cred editable statuses (PSV Complete and later, Withdrawn or Cancelled). **One member per call — this scope field has no bulk overwrite.** An empty array unsets the field.

📄️Get a signed URL for one member's latest PSV packet

Returns a short-lived signed URL for the latest PSV packet of one member workflow of this shared run, under the tenant named in the body. `disposition` DOWNLOAD saves the packet, INLINE renders it in the browser. The caller must hold credentialing workflow read in that tenant (checked first, so membership does not leak), and the workflow and tenant must be a member of this run. A withdrawn member with a packet still gets a URL. Writes nothing.

📄️Whether one member can move on in PSV, and its open blockers

Evaluates the member's PSV rules once under the tenant named in the body and answers READY or BLOCKED with the failed rules. A rule already acknowledged by an earlier move in the current PSV stretch reads covered and does not block. The caller must hold credentialing workflow read in that tenant (checked first, so membership does not leak), and the workflow and tenant must be a member of this shared workflow. Answers 404 while PSV transparency is switched off. Writes nothing.

📄️Evaluate one member's PSV rules under its own tenant

Runs the same PSV rule evaluation the tenant's own psv-validation read runs, for one member workflow of this shared workflow, under the tenant named in the body. The caller must hold credentialing workflow read in that tenant, and the workflow and tenant must be a member of this shared workflow. Writes nothing.

📄️Set one member's Specialties to Cred, under its own tenant

Sets the specialties one member workflow of this shared credentialing run credentials, under the tenant named in the body. The body carries the member's desired list; the server adds what is new and removes what is gone through the shared Specialties section's own writes, for that tenant only. A removed specialty another tenant also holds is narrowed off this tenant; one only this tenant holds is deleted. The section writes need credentialing-workflow:details:create (to add) and details:delete (to remove) on every member tenant. Refuses a member outside the States to Cred editable statuses (PSV Complete and later, Withdrawn or Cancelled). A specialty is matched by taxonomy code, else by name; primarySpecialty, subspecialty and type only apply to a newly added specialty, and a specialty the member already holds is left as it is. Writes run removals first, one at a time, so a refusal part-way leaves the earlier writes in place and a retry recomputes the difference. **One member per call.** An empty array removes them all.

📄️Set one member's States to Cred, under its own tenant

Writes `statesToCredential` on one member workflow of this shared credentialing run, under the tenant named in the body. The shared page spans tenants and the tenant-scoped `PATCH /credentialing-workflows/{workflowId}/states-to-credential` can only answer for the caller's selected one, so the member's real tenant travels in the body. The write itself is that same endpoint's service, so the editable-status gate, the conflict retry, the change log and the Anchor Date recalculation all behave exactly as they do from the tenant's own page. **One member per call — these scope fields have no bulk overwrite (R12).** An empty array unsets the field.

📄️Status history of every member, under its own tenant

Returns the status history of every member workflow of this shared credentialing run, each member checked under its own tenant. The shared page spans tenants, so the tenant-scoped `/credentialing-workflows/{id}/timeline-events` cannot answer them in one call. Each member is `EVALUATED`, with its status changes oldest first, or `FORBIDDEN` (the caller may not read credentialing workflows in that tenant), with no events. Members come in membership order; a run with no members returns an empty list. Writes nothing.

📄️Timeline status-options for each member, under its own tenant

Returns the timeline event status-options available to the caller for each named member of this shared credentialing run, evaluated under that member's own tenant. The shared page spans tenants, so the tenant-scoped `/credentialing-workflows/{id}/timeline-events/status-options` cannot answer them in one call. Each member is `EVALUATED`, `FORBIDDEN` (the caller may not read credentialing workflows in that tenant), `NOT_MEMBER`, or `UNAVAILABLE` (its options could not be resolved right now) — one unreadable or failing member never fails the call. Duplicate pairs are evaluated once. Writes nothing.

📄️Start CAQH and/or NPDB pulls for chosen member tenants

Each pull runs under its own tenant and is reported on its own: one tenant's refusal never becomes the request's failure.

📄️One data-integration source's state across the member tenants

CAQH or NPDB, one source per call. The page reads them independently so a slow or failing read of one never holds the other.

📄️Verify every record on every unlocked member workflow

Each unlocked member's unverified records, shared or its own, in the verifiable sections of the shared page are stamped. Records already verified keep their verifier. Locked members are skipped and named. Not atomic: the result names every member verified, skipped or failed, and the caller retries the failed ones.

📄️Verify one shared record on every member workflow holding it

The record is found in every member workflow by its section and credentialingDisplayGroupKey, computed from each member's rows, and every copy is stamped by the caller, already verified ones included, as the tenant verify does. Locked members are skipped and named. Not atomic: the result names every member verified, skipped or failed, and the caller retries the failed ones.

📄️Re-derive one shared credentialing group's rollups

Reads the group's member workflows, re-derives every rollup, and writes the result if anything moved. Idempotent: a second run reports UNCHANGED and writes nothing. Use dryRun to see the delta first — this is the only gate in front of a write that can close a group to new tenant joins permanently, and a dry run reports that outcome as closedToNewJoins.

📄️Withdraw one shared credentialing group's members

Called by a Cloud Task, one group per task. Moves every member that the transition matrix permits to WITHDRAWN_CANCELLED and leaves the rest alone; nothing is written to the group row, whose status is re-derived from the members that moved.