Incredible Health

The predictive matching engine is the mechanism of the marketplace, recognizing more than 70 specialties and 250 skills, with generative AI handling resume processing and recruiter outreach and two named agents extending it. Held back from A because the product is a two sided marketplace whose value also derives from the supply of vetted nurses; matching quality depends on liquidity as much as on the model.

No description of a human review step, confidence signal, threshold or override mechanism was located.

The question has a particular shape for a matching platform and it is worth stating precisely. The system does not make a hiring decision; an employer does. But it decides what an employer sees, and in a marketplace that ranks and shortlists, what is not surfaced is functionally excluded. A candidate who never appears in a recruiter's list has been screened out by the software without anyone deciding to screen them out.

So the oversight question is not whether a human makes the final call, which they plainly do. It is whether anyone can see or revisit the selection that preceded it. Establish whether a recruiter can view candidates the system ranked low, whether the ranking basis is shown, whether an employer can adjust or disable automated screening, and whether a candidate is told they were considered and not surfaced.

The vendor's own published guidance for employers describes the goal as ranked shortlists rather than raw applicant dumps, which is an honest statement of what the product does and is exactly the capability requiring oversight.

A second layer applies on the candidate side. Automated interview scheduling is described as operating without human coordination, so establish what happens when it misfires and who resolves it.

No model or model family is named, no accuracy or performance figure is published, no evaluation methodology is described, and no model card was located. The vendor describes custom matching algorithms and automated credential screening without characterising either.

For a hiring platform the disclosure that would matter is narrower than a general model card and more useful. What features does the matching model use, and are protected characteristics or close proxies among them. What is the model optimising for, since matching for employer fill rate and matching for candidate outcome are different objectives that diverge. How often is it retrained, and on what signal.

That last question is the one with teeth. A matching system that learns from which candidates employers hired is learning from employer behaviour, including whatever preferences that behaviour encoded. A system that learns from which placements lasted is learning something closer to fit. Neither is disclosed.

The credential screening component raises a separate and more tractable question. Establish whether licence and certification verification is performed against primary sources, and what the system does when a record cannot be matched, since a false mismatch on a licence is a serious harm to an individual nurse and is not a probabilistic matter.

Ask what the matching model uses, what it optimises for, and how verification failures are handled.

Nothing identifies any party in the chain: no model or model family, no hosting arrangement and no sub processor list was located in two passes, and no retention schedule, training use statement or de identification posture was found.

The holding is not patient information and the framing should reflect that: what accumulates is a durable professional profile for an individual nurse, covering licences and certifications with verification records, employment history, specialty and shift preferences, salary expectations, application history, interview activity and in platform messages with employers. That is a career record and its sensitivity is of a different kind.

An employment history showing short tenures, a record of applications that did not progress, or a stated salary expectation are all things a nurse would reasonably not want visible to a future employer, and all of them are held by a company whose paying customers are employers. The two sided structure is the reason to ask rather than assume: the subject of the data is not the paying customer, so nothing in the commercial relationship represents her interest.

Establish what an employer can see beyond what the nurse chose to share, whether application or interview history with one employer is visible to another, how long a profile is retained after she stops using the service and whether it can be deleted rather than deactivated, and whether her activity trains matching models with an option to decline.

Operational claims are specific and falsifiable rather than vague: permanent roles filled in under 20 days against multi month industry norms, a 20 percent lift in interview request acceptance attributed to generative outreach, and 15 percent higher retention among nurses hired through the platform. Scale is corroborated in independent coverage at 1.5 million healthcare workers and 1,500 employers. Held back from A because the figures are vendor measured without published methodology or an independent comparison cohort, and retention in particular is difficult to attribute cleanly.

No retention schedule, training use statement or de identification posture was located.

The holding is not patient information, and the framing should reflect that. What the platform accumulates is a durable professional profile for an individual nurse: licences and certifications with verification records, employment history, specialty and shift preferences, salary expectations, application history, interview activity and in platform messages with employers.

That is a career record, and its sensitivity is of a different kind. An employment history showing short tenures, a record of applications that did not progress, or a stated salary expectation are all things a nurse would reasonably not want visible to a future employer, and all are held by a company whose paying customers are employers.

So the questions are about visibility and duration rather than clinical confidentiality. What can an employer see beyond what the nurse chose to share. Is application or interview history with one employer visible to another. How long is a profile retained after a nurse stops using the service, and can it be deleted rather than deactivated. Is candidate activity used to train matching models, and can a nurse decline that.

The two sided structure is the reason to ask: the subject of the data is not the paying customer.

This axis does not apply and its absence is expected rather than a gap. The platform serves nurses seeking employment and hospitals hiring them. Its subjects are clinicians, not patients, and no protected health information is created or received on a covered entity's behalf, so no business associate relationship arises from the core product.

What governs instead is a different body of law that a buyer should assess on its own terms.

Employment records law applies to what the platform holds about candidates. Where background screening or verification is performed by or through a third party for employment purposes, federal consumer reporting law imposes its own obligations, including candidate authorisation, adverse action notice and a right to dispute inaccurate information. State licence verification carries its own rules, and licence status is public information in most states while the verification record built around it may not be.

One conditional is worth checking rather than assuming. If the platform ever handles occupational health information, immunisation status or fitness to work documentation as part of onboarding, that content is health information and the analysis changes.

Ask which framework the vendor operates under for verification, whether consumer reporting obligations are engaged, and whether any health related onboarding document ever passes through the platform.

No attestation, certification or trust centre was located.

The expectation is set by the customer base rather than by the sensitivity of clinical data, since none is held. The platform sells to hospitals and health systems, and those organisations run vendor security reviews as a matter of course before granting any supplier a role in hiring. Assessments of this vendor almost certainly exist in customers' hands. None is published, which leaves a prospective employer starting from nothing and a nurse with no way to assess the company holding their professional record.

What an examination would need to cover is defined by the two sided structure. On the employer side, recruiter accounts reach candidate profiles at scale, so provisioning, scoping and revocation are the controls that matter, particularly when a recruiter changes employer within the same market. On the candidate side, the platform holds licence numbers, certifications and employment history for a large population of nurses, which is an identity rich dataset attractive independently of any clinical value.

The verification function adds a third. Where the platform validates credentials, the integrity of that record is what employers rely on, so tamper resistance and audit logging on verification records deserve their own question.

Ask which report is held or scheduled, its scope, and how recruiter access is scoped and revoked.

No clearance, device authorisation or pathway statement exists, and none should. This is a hiring marketplace. It does not touch patient care, so no device framework applies and this axis should not be read as an absence.

What governs instead is a body of law that is moving faster than device regulation and applies squarely to this product, because the platform screens candidates and produces ranked matches for employers. That makes it an automated employment decision tool in the terms several jurisdictions now use.

Three strands matter. Federal employment discrimination law reaches selection procedures regardless of whether a human or an algorithm applies them, and the enforcement agency has issued guidance confirming that algorithmic tools are assessed against the same standards. New York City requires an annual independent bias audit for automated employment decision tools used for positions in the city, with published summary results and advance notice to candidates. And a growing set of state statutes govern consequential automated decisions, with employment named among them.

A platform serving hospitals nationwide will have candidates and positions inside those jurisdictions. So the compliance question is not whether it applies but which obligations have been met and where.

Ask whether a bias audit has been performed and published, what candidate notice is given, and how the vendor allocates responsibility between itself and the employer.

No fairness statement, bias audit, subgroup performance disclosure or responsible AI documentation was located.

That matters more here than for most records in this index, because for this product category a bias audit is not a best practice a vendor may choose to adopt. In at least one major jurisdiction it is a legal requirement for automated employment decision tools, it must be conducted independently, and a summary of results must be published. The obligation exists precisely so a candidate can see it.

The mechanism worth naming is specific to matching. A system that ranks candidates against employer preferences learns from historical hiring outcomes, and nursing has documented demographic patterns in specialty distribution, shift allocation and progression. A model trained on who was hired before will reproduce those patterns without anything in it being designed to. The same applies to proxies: years at one employer, gaps in employment history, or which schools appear in a profile all correlate with characteristics the law protects.

None of that requires intent, and none of it is visible to a nurse who simply receives fewer matches.

Ask whether an independent bias audit exists, what it examined, what it found, and whether results are published as the relevant statute contemplates.

Two passes located no model family, no accuracy or performance figure, no evaluation methodology and no warranty, indemnity or remediation commitment, with matching algorithms and credential screening described without either being characterised. Two questions matter more than a general model card and neither is answered.

The first is what the model optimises for, because matching for employer fill rate and matching for candidate outcome are different objectives that diverge, and a nurse and a hospital would want different systems. The second has more teeth: what signal the model retrains on. A matching system that learns from which candidates employers hired is learning from employer behaviour, including whatever preferences that behaviour encoded, and will reproduce them while appearing to learn merit.

A system that learns from which placements lasted is learning something closer to fit. Neither is disclosed, and the choice between them determines whether the model launders past hiring patterns or improves on them. The credential screening component raises a separate and more tractable point.

Establish whether licence and certification verification runs against primary sources and what happens when a record cannot be matched, because a false mismatch on a licence is a serious harm to an individual nurse and is not a probabilistic matter to her. Ask what the model uses, what it optimises for, what it retrains on, and how verification failures are handled.

This axis maps imperfectly and the scoping should be stated rather than the row read as a failure. A nurse hiring marketplace does not connect to clinical record systems, holds no patient data, and has no reason to interoperate with an electronic health record. Its absence from that ecosystem is correct rather than deficient.

The equivalent question for this product is integration with the systems a hospital actually runs for hiring: applicant tracking systems, human resources information systems, and credentialing platforms. The vendor's own published guidance for employers names applicant tracking integration among the criteria a health system should evaluate, describing it as avoiding a rip and replace, so the company recognises it as a buying consideration.

What is not established is what the product itself offers. No applicant tracking system is named, no integration mechanism or standard is described, and no statement distinguishes a data feed from a fuller bidirectional connection. Separately the vendor markets automated interview scheduling requiring no technology integration, which is a genuine adoption advantage and also means that part of the workflow sits outside the systems a hospital already governs.

Ask which applicant tracking and human resources systems are supported, by what mechanism, whether the connection is bidirectional, and what data flows in each direction.

No hosting model, region, tenancy or residency statement was located. Delivery is a multi tenant cloud service reached through web and mobile applications on both major platforms.

As with other consumer facing marketplaces in this lane, the deployment model itself is not genuinely in question. Residency, retention location and subprocessor disclosure are, and they are unanswered.

Two features give the question weight. The platform holds licence numbers, certifications and employment histories for a large national population of nurses, which is identity rich data whose location a buyer and a candidate both have reason to know. And the vendor describes automated interview scheduling operating without technology integration on the employer side, which implies calendar and communication integrations reaching into employer systems or individual recruiters' accounts. Those are subprocessor relationships and access grants, and neither is disclosed.

Tenancy deserves a question for the same commercial reason it does elsewhere in this lane. The customer base is hospitals competing for the same nurses in the same regional labour markets, so separation between employer tenants is a competitive matter as well as a security one. A recruiter at one system should not be able to infer another's pipeline.

Ask for the hosting region, the tenancy model, the subprocessor list, and what access the scheduling function requires.

The model is disclosed even though amounts are not: employers pay and the platform is free to nurses, with third party coverage describing per hire or subscription structures. A buyer can understand how they would be charged without a sales call, which is more than most vendors in this index offer, but not what they would pay.

Narrow and clearly stated: permanent placement of nurses and allied healthcare workers at hospitals and health systems, explicitly not travel or contract staffing. That exclusion is a meaningful scope statement, since contract labor is the adjacent market and the company declines it.