Welcome back to our quick series on matching clinicians to jobs. If you missed it, check out Part 1: Intent, where we explored how Nomad captures explicit and revealed preferences to understand which jobs a clinician actually wants.
Intent answers the first half of a good match: will this clinician be interested in the role? But interest isn't enough. A clinician can be dying to take a job they have no chance of winning.
Qualification answers the second half: should this clinician be presented to the client? Will they win an offer if presented for this job? Same clinician, entirely different question.
The Qualification Problem
Get qualification wrong and the failure is more expensive than an intent miss.
Pitch a job the clinician isn't interested in, and they ignore you. Submit a clinician who isn't actually qualified, and you burn something much harder to earn back: the client's trust. Every unqualified submission is a withdrawal from your credibility with the account.
So how do you know a clinician is actually qualified? It sounds like it should be simple: read the job order, check the boxes. It isn't.
Having operated as a staffing firm for years, we learned this the hard way. The facility has requirements the job order doesn't mention. The health system layers on its own. The channel partner or VMS adds another set. Sometimes the job order is simply missing critical information. Sometimes it's in direct conflict with what the client will actually accept. The requisition in your hands is one input, not the whole truth.
Why AI Isn't Enough
Lately a wave of tools has come to market claiming to solve this with AI. The pitch is familiar: feed an LLM the unstructured job description and the candidate's resume, convert both into embeddings (numerical representations of each), and score how similar they are. More similar, higher match.
It falls short on two counts:
- It trusts the job order. The approach assumes the job order contains every requirement a clinician must meet to be presented. It doesn't. As we've seen, the real requirement set is assembled from the whole stack, and the gates that matter most are often the ones nobody bothered to write into the job order.
- It's fuzzy. LLMs are non-deterministic by nature: ask twice, get two answers. A similarity score tells you whether a clinician feels like a fit. But "feels like a fit" has no business deciding who gets presented to a client or cleared to work the floor. You need to know, with certainty, that a clinician clears every requirement of the stage, the same answer every time.
How Nomad Solves Qualification
Nomad built a requirements engine for this, one that does the deterministic work similarity can't.
We still use LLMs, but for the job they're actually good at: reading the messy, unstructured job order and pulling out the requirements buried inside it. Then we layer in everything the job order leaves out, the part most tools skip. The rules defined by the facility. The rules defined by the health system. The rules from the channel partner or VMS. A half dozen other layers. We resolve all of it into a single, authoritative picture.
The result is a definitive view of what must be true for a clinician to progress: a set of requirements that reflects what the client will enforce, including the parts nobody bothered to write into the job order.
Think of every requirement as a gate the clinician has to walk through: license, specialty, years of experience, certifications, EMR familiarity, and dozens more.
The job order hands you a few of these gates. But the real set is assembled from a stack. Picture the client as a multi-layered cake: channel partner at the top, then health system, then facility, then the specific job order at the bottom. Each layer can add a gate the layer above didn't mention, or override one it did. A health system might require a certification the facility never listed; a facility might waive something the job order demanded. Nomad walks the whole stack top to bottom, merges it, resolves the conflicts, and compiles one authoritative set of gates for that exact job.
Here's the hard part: scale. Everything above (walking the stack, merging the layers, resolving the conflicts) is the work to qualify one clinician against one job. Multiply it out:
- Hundreds of thousands of clinicians in the database
- Ten thousand open jobs in the marketplace, each revised multiple times over its lifecycle
- A dozen-plus requirements per job
That's an m × n × o problem: clinicians times jobs times requirements. Do the math: 100,000 × 10,000 × 12 is more than ten billion individual pass/fail checks. And that's the easy version, the one where nothing ever changes.
It always changes. A job's requirements get revised, a clinician earns a new certification, a health system updates a policy, and every one of those changes ripples across the grid. You can't run this as an overnight batch and file it away. It's a living evaluation that re-resolves the instant any input moves and stays correct across the entire database every time a job is published or updated.
Qualifying Down Funnel
The qualification problem is present across the entire hiring funnel.
The requirements to create an application aren't the same as the ones to submit that clinician to a client — and neither matches what it takes to clear compliance.
Because Nomad models requirements at each stage of the funnel, not just at the top, the overall yield increases. Fewer clinicians fall out of the funnel. A clinician may not qualify to be submitted for a particular job, so the system suggests jobs they do qualify for. A clinician may be at risk of a pushed start in compliance, so the system flags that file. The system is constantly evaluating clinicians to maximize yield through the funnel.
Bringing It Together
Intent told you whether the clinician wants the job, and the graph answered from behavior, without a phone call. Qualification tells you whether they can win it, and the requirements engine answers from the client's real rules, without a rockstar recruiter reading between the lines.
Put the two together and you have the whole match: a clinician who is both interested and qualified, surfaced automatically, at a scale no team could reach by hand. That's how the right clinician and the right job come together, and it's what Nomad OS was built to do.