> ## Documentation Index
> Fetch the complete documentation index at: https://docs.perfectreferral.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Referral Scope Match
## What this module answers
When a provider refers a patient, the question is not whether a specialist *could*,
in principle, be a match for a referral. It is whether they are an appropriate match
in practice. This module reveals whether a specialist's billing data indicates they're
a good destination for a given kind of **routine** referral.
We work from what specialists bill, not from what their license or self-reported
specialty permits. A specialist's billing record is the most direct, large-scale
evidence of the work they actually perform, and it's what these predictions are
built on.
## How to read a label
For each specialty and each *routine* referral target to that specialty (such as
"colonoscopy" or "retina"), the module emits one of six labels.
| Label | Meaning |
| :-------------------- | :--------------------------------------------------------------------------------------------------------- |
| `very_likely_match` | The billing profile strongly indicates a match for this routine referral target. |
| `likely_match` | The billing profile indicates a match for this routine referral target. |
| `uncertain` | The provider is evaluable, but the evidence meets neither the match nor the no-match predictive threshold. |
| `unlikely_match` | The billing profile indicates this is not a match for this routine referral target. |
| `very_unlikely_match` | The billing profile strongly indicates this is not a match for this routine referral target. |
| `insufficient_data` | Not enough billing data to evaluate. |
The predictive value of a label for a target is calibrated against an even sampling
of held-out providers in the target's specialty. A `very_likely_*` label carries at
least a 95% predictive value, and a `likely_*`/`unlikely_*` label at least an 80%
predictive value.
Neither `uncertain` nor `insufficient_data` is a negative signal, and a consumer
can treat both as "not confident calls." They are not the same finding, though:
`uncertain` means we could see the provider clearly and the evidence was genuinely
mixed; `insufficient_data` means we could not see enough of the provider to judge
at all.
## Where the signal comes from
Every prediction this module produces is computed from public data:
* **Medicare Physician & Other Practitioners** data ([CMS](https://data.cms.gov/provider-summary-by-type-of-service/medicare-physician-other-practitioners/medicare-physician-other-practitioners-by-provider-and-service)),
for per-provider, per-procedure billing.
* **Medicaid T-MSIS** ([HHS](https://opendata.hhs.gov/datasets/medicaid-provider-spending/)),
as a second, separate payer channel.
* **NPPES**, the national provider registry, which defines each specialty cohort.
Some notes on the data:
* Medicare and Medicaid cover structurally different populations, so we keep them
side by side and never add a count from one to the other. An absent channel means
"no data here," not "this provider does not see those patients."
* We only label people, not group practices. Organization records are excluded
because a group's billing is an aggregate of many providers rather than a referable
person.
* Public billing data suppresses small counts, so a missing code may have been
performed and withheld for privacy rather than never performed. We never read a
missing code as a negative without first confirming the provider is observed
heavily enough for that absence to mean something.
* We do not consider the dollar amount of services. Payment amounts encode billing
and site-of-service mix, not clinical focus, so we stick to patient and service
counts in each provider's own mix of procedures.
## How we turn billing into predictions
**Tools.** We use frontier LLMs to handle the clinical ontology, reviewed by our
Chief Medical Officer: identifying referral targets, defining subspecialty workflows,
and characterizing provider billing profiles. However, LLMs do not calculate
magnitudes. Every weight, threshold, and prediction in the module is calculated via
deterministic analytics on claims data to maintain repeatability and explainability.
**Clinical context.** Our objective is to help match
routine referrals to the specialists who are genuinely the right fit. A patient who
needs diabetic retinopathy screening, for instance, should reach a general
ophthalmologist, not a retina surgeon. This guiding application affects the scope, training,
evaluation, and interpretation of this module:
1. **Target definitions.** We identify typical referral reasons per specialty; these
include focus areas, common procedures, and a catch-all "generalist" target for
every specialty.
2. **Provider matching.** Under the clinical context defined above, we leverage
frontier LLMs to reason about which providers are appropriate for each target
based on their billing fingerprints. These were sanity-checked by our Chief
Medical Officer.
3. **Training and calibration.** We use machine learning to identify billing
signatures that deterministically recapitulate the LLM-driven provider matching
step. This converts potentially inconsistent LLM judgements into robust and
explainable predictions. This step sometimes fails to produce a performant model.
Read more about limitations below.
## Why we sometimes only rule targets out
Not every referral target can be answered in both directions. For many routine
referral targets, billing data can confidently rule a provider out as a poor fit, but
cannot reliably rule them in. When that is the case, we make it clear (the
`rule_out_only` field in the endpoint response).
Whether a target can be ruled in at all is determined empirically, from the data, not
decided by hand.
To understand why, consider the ongoing management of heart failure. A focused
practice does leave billing traces, like the blood tests and imaging used to monitor
the condition. But none of these belong to heart failure alone: general cardiologists
order the same tests to work up other problems. Because the codes recur across all of
cardiology, a heavy share of them cannot separate the cardiologists who concentrate
on heart failure from those who touch it occasionally, so the evidence cannot rule in.
The reverse is firmer: a cardiologist who bills none of this workup can be confidently
set aside, because a genuine heart-failure practice does not leave that whole
footprint empty. The signal rules out, but it cannot rule in, and no additional
modeling recovers a positive trace that the claims never recorded.
## How we calibrate
We set the thresholds so that, on a uniform, representative sample drawn to represent
the target specialty population, a `likely_match` call matches the LLM reasoning at
least 80% of the time and a `very_likely_match` call at least 95% of the time. The
rule-out thresholds are set the same way against the same bar, so an `unlikely_match`
or `very_unlikely_match` call carries the matching guarantee on the exclusion side.
When a target model does not reach a minimum performance or positive/negative
predictive performance, it is omitted and recorded as omitted.
## Ongoing validation
Predicting scope of practice from billing data isn't new, but using it to judge
routine referral fit is. We're still learning where these predictions are strong and
where they're weak.
We treat validation as ongoing rather than a one-time gate: as our reference data
grows and as users surface corrections, we re-examine each target and revise or retire
it when the evidence no longer backs the call.
Two checks anchor this work. First, we perform clinical-consistency reviews to ask
whether a target's predictions cohere with independent clinical expectation: do the
specialists we rule in and rule out match how the specialty actually refers? We also
inspect the clinical validity of the weights assigned to billing codes during machine
learning. When possible, we interrogate the observed-versus-expected (O/E) enrichment
of providers' self-attested subspecialties against our predictions when there is a
strong match with a specific referral target.
## Other limitations
**Some referral targets are billing-invisible.** Inflammatory bowel disease, for
instance, is treated largely through prescriptions rather than billed infusions, so
most of the providers who manage it do not look distinctive in claims. We therefore
label the target as omitted and do not make predictions.
**Referral targets may change.** Though we'll do our best to keep the API stable,
methodological improvements may mean we change target definitions where appropriate.
**Not all specialties are present.** For this initial release, we focused on some of
the most common specialties that patients are referred to in an ambulatory setting.
Let us know if there's a specialty you're eager to see included in the next release.
**Billing data is incomplete and dated.** The billing data used in this module is
from 2024 and reflects care provided to Medicaid and traditional Medicare patients. A
provider may provide significantly different care to other populations, may have
changed their scope of practice, or may provide services not reflected in billing
data (for example, cash pay).
Want more recent data, or to augment predictions with your own dataset? Reach out to
learn more.
**Providers work in teams.** This module currently makes predictions about individual
providers. In reality, patients are referred to specialty clinics with many providers.
Future modules will connect this work to location and affiliation predictions.
Did you find an error or limitation? Please let us know by reaching out to
[corrections@threshold.health](mailto:corrections@threshold.health).
## What this module is not
This module reports a destination-fit signal. It is not a credentialing, licensure,
or privileging source, and it does not assert what a provider is qualified or
permitted to do. It reflects observed Medicare and Medicaid billing, so a provider who
practices primarily under commercial insurance, or who is newly in practice, may be
observed too thinly to judge. That is precisely what the `insufficient_data` label is
for. The referring clinician's judgment remains the decision. Our aim is to make that
decision better informed at the moment it is made, not to replace it.