Ahealthcare staffing firm places travel nurses and allied health professionals into hospitals and facilities across the country. Over years of operation, it had built something genuinely valuable: a database of 85,000 clinician profiles, each one a real person with a real career history, stored in its Bullhorn ATS.
Most of that value was invisible to its own search tools.
Healthcare staffing moves fast. When a hospital calls with an urgent opening, the agency that responds first with the right candidate wins the placement. Speed matters — but so does accuracy. A wrong submission wastes the facility’s time, strains the relationship, and reflects poorly on the agency.
The firm ran its searches through Bullhorn’s native search and its built-in AI matching. Bullhorn is a capable platform — but its matching layer is fundamentally a keyword index with structured field filtering. When it comes to finding the right clinical candidate, that architecture has a ceiling no amount of configuration can raise.
It finds candidates with the right keywords. It does not find candidates with the right experience.
Here is what that gap looks like in practice. A recruiter needs to fill three open roles:
- 01Pediatric ICU nurse · Phoenix
“ICU-experienced RN, pediatric subspecialty, compact license, ACLS and BLS current, available in three weeks.”
- 02Traveling OR scrub tech · Nashville
“Orthopedic experience preferred, proficient in robotic-assisted procedures, first-call availability required.”
- 03Labor & delivery nurse · Seattle
“High-risk obstetrics experience, Epic EMR proficiency, minimum two years in a Level III NICU-adjacent unit.”
Each requirement has two distinct layers. The structured part — license type, certifications, state eligibility, specialty codes — Bullhorn handles adequately through relational filtering. But the clinical nuance — five years in a pediatric step-down unit, hands-on robotic-assisted orthopedic cases, comfort managing high-risk obstetric emergencies — lives in unstructured free-text fields that candidates wrote themselves, in their own words.
Bullhorn’s matching layer cannot interpret those fields semantically. It pattern-matches on token overlap. So a recruiter searching for a pediatric ICU nurse misses the candidate whose profile says “pediatric critical care” — different tokens, same clinical meaning, invisible to a keyword index.
Different words. Same clinician. Invisible to the search box.
The recruiter is left doing one of two things: spending hours manually reading through profiles to find the ones the system missed, or submitting keyword-matched candidates who looked right on paper but were not the right clinical fit. Neither is acceptable when a facility is waiting.
Coral Tree deployed Scout — its proprietary semantic search and entity-matching system — as an intelligence layer directly on top of the existing Bullhorn database. Bullhorn stayed in place as the system of record — profile management, compliance tracking, and candidate communications all ran exactly as before. What changed was the search experience itself: recruiters could now query the full database in plain English, the way they would describe a role to a colleague, rather than assembling combinations of keyword filters and structured fields across multiple Bullhorn screens.
Scout operates in three stages:
Hard constraints, enforced first.
Certain requirements are non-negotiable and are handled deterministically, before any semantic reasoning. A candidate without a compact nursing license cannot work across state lines; a candidate whose ACLS certification has lapsed cannot work in an ICU. These fields are filtered at the database layer — no semantic relevance score can override a hard credential disqualifier.
Retrieval by meaning.
Every free-text experience description across all 85,000 profiles is encoded into a numerical representation by an embedding model calibrated on clinical language rather than general-purpose text. At query time, the recruiter's natural language requirement is encoded into the same space, and the system retrieves profiles by semantic proximity — ranked by how closely their clinical meaning matches the query, not whether the words overlap.
An LLM relevance gate.
Dense retrieval at scale surfaces candidates who are semantically close but not always contextually right. A language model reads each retrieved profile against the specific role requirements and scores fit at a deeper level of reasoning — removing candidates who matched on embedding proximity but don’t hold up under a holistic clinical reading. This is the layer that eliminates the false positives pure vector search cannot catch.
The output is a ranked shortlist of candidates who are not just credentialed for the role but genuinely experienced for it — surfaced from a corpus that was always there, but never fully accessible.
The numbers tell part of the story.
A recruiter who used to spend most of a half-day on a single search — manually reading profiles, filtering out keyword matches with no real clinical relevance, cycling back through the ATS with rephrased queries — now gets a semantically ranked shortlist in the time it takes to make a cup of coffee.
The 40% improvement in submission-to-placement rate is not just an efficiency gain. It means the firm’s facility clients started receiving better candidates. Fewer rejections. Fewer follow-up calls asking why a submitted candidate didn’t meet the clinical requirements. The agency’s reputation with its hospital partners improved alongside its internal productivity.
The 85,000 profiles had always been in the database. What changed is that the firm could finally see all of them — not just the ones whose authors happened to use the exact tokens a recruiter typed into a search box.