Rehire Eligibility Leaks: Stopping DNR Failures Across Branches

A nurse gets DNR'd from a hospital on Tuesday. Two weeks later, the same nurse walks onto the same floor — placed by a different branch of the same agency, through a different VMS portal, under a slightly different email. The charge nurse recognizes her. The account manager gets the call. The contract goes into review.

This is not a rare edge case. It is the default failure mode of staffing operations where rehire eligibility is treated as a data hygiene problem instead of an identity problem. Every branch, every VMS integration, and every client portal keeps its own version of the worker record, and none of them agree on who is blocked from where.

The Same Worker, Three Applications, Zero Flags

Here is the scenario every ops leader has lived through. A traveler finishes an assignment badly at Client A. The account manager at Branch 1 logs a DNR in a shared spreadsheet, notes it in the ATS, and emails the recruiter who placed her. Three weeks pass.

The same worker submits a fresh application through a VMS portal — one your firm subscribes to but doesn't own. She uses her personal email this time instead of the Gmail she applied with before. The VMS parses her resume, creates a candidate profile, and pings your Branch 2 recruiter about an open req at Client A's sister facility. Branch 2 has never heard of her. There is no flag. She is submitted and confirmed within 48 hours.

When she badges in, the client sees the same face they told you never to send back. In healthcare staffing, that failure isn't just embarrassing — it's a measured quality event. Joint Commission certified health care staffing firms are expected to send quality temporary staff who are skilled and reliable to healthcare facilities, and when performance falls short the customer may request that the individual not return for future assignments, known as a "Do Not Return" (DNR). Regardless of the underlying reason, DNR requests can negatively impact the business relationships and reputation of the firm.

The cost stack is ugly: client trust erosion, potential loss of the MSA, and — for Joint Commission-certified firms — a hit to a monthly reported quality metric that customers can and do request during renewals.

Why DNR and "Not Eligible for Rehire" Aren't the Same Record

Part of why this keeps happening is that operators lump three distinct concepts under one mental label. They are not the same, and they don't live in the same system.

Client-issued DNRs come from the customer. A charge nurse, a unit manager, or a facility administrator says: don't send this person back. A DNR is defined as any customer request for an individual not to come back to complete the current assignment or be assigned in the future to a specific unit/ward of the facility, any unit/ward of the facility, or the entire health system. The scope matters — unit, facility, or system — and most agencies collapse all three into a single flag.

Agency-issued Do Not Deploy lists are internal. The worker no-called-no-showed twice, failed a drug screen, or falsified credentials. The agency won't place them anywhere. This lives in HR notes or a recruiter Slack channel.

HR "not eligible for rehire" is the employment-record flag. It follows termination policy and lives in the HRIS. It might not be visible to recruiters at all, depending on how permissions are configured.

These three records answer three different questions — where can this person work, will we deploy this person anywhere, and can this person be re-employed by us — and they get stored in three different systems. VMS portals hold client-facing exclusion lists. The ATS holds candidate status flags. The HRIS holds employment history. Recruiter spreadsheets hold everything nobody else caught. When a new placement kicks off, the check runs against whichever system the recruiter happened to open. That is the root cause.

The Four Places Rehire Checks Fail

When we walk through post-mortems with staffing ops teams, the failures cluster into four buckets.

1. Branch silos

Branch 2 recruiters cannot see Branch 1's notes. Each office runs its own pipeline, its own recruiter Slack, its own DNR spreadsheet. When a worker migrates markets — or just applies to a nearby branch after a bad assignment — the receiving recruiter has no signal. They pull up a clean-looking profile and submit.

2. VMS portals that accept applications before your internal check runs

Many VMS platforms create the candidate record on their side first, then ping the agency for confirmation. If your DNR logic lives in a downstream ATS, the worker has already been surfaced to the client-facing hiring manager before your rules fire. Now you're pulling a candidate back, which looks worse than never submitting them.

3. Duplicate worker records created by resume-parsing tools

Every time a resume gets parsed under a slightly different email, phone number, or name spelling, most ATSes create a new profile. "Kate Johnson" applies in March. "Katherine Johnson-Reyes" applies in September using a new phone number after moving. The parser doesn't merge them. The DNR flag lives on the March record. The September record is clean.

4. Client-site rehires across a parent health system

A nurse gets DNR'd from one hospital inside a large IDN. The DNR is logged at the facility level. Six months later she's placed at a sister hospital in the same system — sometimes managed by the same regional VP. The client's expectation is system-scope exclusion. Your record was facility-scope. The scope mismatch is the failure.

Identity Resolution: One Worker Profile, Every Branch

Every fix here starts in the same place: deduplication. You cannot enforce a DNR on a worker record that is fragmented across three profiles. The fix isn't a smarter recruiter — it's a matching engine that collapses records before they multiply.

Email alone won't cut it. Workers change addresses when they move jobs. Phone numbers cycle. Names change with marriage, divorce, and preference. The matching stack that actually works looks like this:

Signal	Why it matters	Weight
SSN last 4 + DOB	Near-unique when both present, survives name changes	High
Credential number (RN license, EMT cert, CDL)	State-issued, stable across employers	High
Phone number	Common but cycles; strong when combined	Medium
Email address	First signal most systems check; weakest alone	Medium
Prior client history	Two "different" candidates with identical work history are the same person	Medium
Name + DOB fuzzy match	Catches spelling variants and hyphenation	Low-Medium

Matching logic needs to run at three moments: application intake, before submission to a client, and on any bulk import from a VMS or job board feed. It also needs merge rules that don't destroy history. When two profiles collapse, the audit trail should show every field that changed, who confirmed the merge, and every prior DNR, credential, and placement carried forward from the source records.

This is where a unified worker database beats a stack of branch-level ATSes. Deduplication has to happen once, at the platform level, not repeatedly in each recruiter's inbox. Teambridge's Applicant Tracking System and staffing agency platform are built around a single canonical worker record that every branch, every recruiter, and every client-facing surface reads from.

Merge audit requirements

When two records collapse, three things must be true:

1. Every DNR from both records is preserved on the merged profile.
2. The reason code, source, and date of each DNR carries over.
3. The merge itself is logged — who did it, when, and against what matching signal.

Otherwise you have created a new failure mode: the accidental merge that erases a DNR.

Wiring DNR Rules Into the Placement Workflow

Deduplication is table stakes. The next step is enforcement — actually blocking the placement at the moment it matters, not after the shift is filled. This is where most agencies leak.

Hard blocks vs. soft warnings

Not every flag should stop a placement. A system-scope DNR from a client should be a hard block: the recruiter cannot submit, full stop. A 90-day cooldown after a no-call-no-show might be a soft warning: the recruiter sees it, acknowledges it, and can proceed with a supervisor override. A credential-adjacent flag (expired license) is a different rule entirely.

Scope-aware enforcement

DNRs have three natural scopes, and your rules should support all of them:

• Unit-level: worker cannot return to the ICU at Memorial North, but can work med-surg
• Facility-level: worker cannot return to Memorial North, but can work Memorial South
• System-level: worker cannot work anywhere in the Memorial Health System

A DNR is defined as any customer request for an individual not to come back to complete the current assignment or be assigned in the future to a specific unit/ward of the facility, any unit/ward of the facility, or the entire health system. If your data model doesn't capture that scope, you will over-block (losing revenue on placements you could have made) or under-block (losing contracts).

Time-boxed DNRs and cooldowns

Not every DNR is permanent. A 90-day cooldown, a probationary period, or a "do not deploy until retraining" flag should expire on its own. Manual cleanup of expired flags is where recruiters lose trust in the system and start ignoring it.

Reason codes tied to policy

Recruiters need to see why a worker is flagged. "Blocked" with no reason gets ignored or worked around. "Blocked — client-issued DNR, unit-scope, patient safety incident, 2024-11-14" gets respected.

VMS and API sync

External portals have to respect the same rules. That means webhook-based updates: when a DNR is added, updated, or expires on the worker profile, the change propagates outward to every connected VMS, client portal, and downstream system. Batch nightly syncs are too slow. By morning, the placement is confirmed.

The Audit Trail Clients and Auditors Actually Ask For

When a client calls and asks "how did this person get back on our floor," the answer needs to be a specific record, not a story. And when a Joint Commission surveyor arrives at a certified firm, they expect a defensible measurement process behind the DNR-linked placement rate.

Here is the minimum audit trail your worker profile needs to produce:

• DNR issue date — when the flag was added
• Source — which client contact, from which facility, requested it
• Reason category — mapped to your policy taxonomy (clinical, behavioral, attendance, credentials, other)
• Scope — unit, facility, or system
• Duration — permanent or time-boxed with expiration
• Override history — every time the flag was suppressed, by whom, and why
• Blocked placement attempts — every subsequent submission the system prevented

That last one is the one most agencies miss. When a client asks how you're managing DNRs, the strongest answer isn't "we haven't placed her since November" — it's "we blocked seven placement attempts to your facility and three to your sister system in that window." That is a control operating as designed.

For Joint Commission-certified firms, this maps directly to how HCSS-5 is measured. If two nurses had DNRs in January (Nurse A had 5 DNRs and Nurse B only 1 DNR), and John reports 30 as the denominator and 28 as the numerator for the month of January, CMIP calculates the measure rate as 93% for that month. The measure counts placements, not people — which means a single worker generating repeated DNRs from repeated placements has an outsized effect on your reported rate. Blocking re-placement is the direct lever on the metric. See the Joint Commission HCSS-5 specification for the full data element definitions.

What to Build, What to Buy, What to Retire

If you're auditing your own rehire eligibility stack this quarter, here's the short version.

Retire:

• Branch-level DNR spreadsheets
• Shared inboxes where account managers forward client DNR emails
• "Ask the recruiter who placed her last time" as an institutional practice
• Separate DNR fields in your ATS, HRIS, and VMS portal that don't sync

Consolidate:

• One canonical worker record per person, across every branch
• DNR, rehire-eligibility, and credential fields on that single record
• Reason codes, scope, and duration structured — not free text
• Webhook or API sync out to every VMS you subscribe to

Build or buy:

• A matching engine that dedupes on multiple signals, not just email
• Placement-time enforcement, not post-placement reporting
• An audit view your account managers can share directly with clients
• Time-boxed DNRs that expire without manual cleanup

This is the operator surface Teambridge is built for. The Teambridge platform unifies the worker record across branches, and Admin Tools give ops leads the exception-handling and audit views clients and surveyors actually ask for. For healthcare staffing firms specifically, DNR scope, credential expiry, and rehire eligibility live on the same worker profile every recruiter and every VMS integration reads from.

The worker who was DNR'd on Tuesday shouldn't be badging in two weeks later under a different email. Fixing that isn't about training recruiters harder. It's about giving them one profile per worker, one set of rules, and a system that blocks the submission before it reaches the client.