This is a story about a task nobody puts on a slide: checking a list of doctors before it goes into the system that pays them. It is dull, it is repetitive, and when it goes wrong the failure shows up weeks later as a pile of rejected claims and angry providers. Every registry record below is a real lookup against the live national provider registry, captured from an actual chat. No mocked screens, no toy data.
The setup
Priya runs provider-network operations at a regional health plan. When the contracting team signs a new group or a batch of clinicians, the roster lands on her desk as a spreadsheet: an NPI for each provider, a name, and a claimed specialty. Her job is to verify each row and then load it into the claims system so the plan can actually pay those providers.
The verification is not glamorous, but it is load-bearing. For every NPI she has to confirm three things:
- Is the NPI Active? A deactivated or non-existent NPI that slips into the claims system rejects every claim tied to it.
- Is it the right entity type? An individual clinician is a Type 1 NPI; a facility or group is Type 2. Load one where the other belongs and claims edit out.
- Does the registry taxonomy match the specialty the contracting sheet claims? If the roster says "ophthalmologist" and the registry says something else, the claim edits that key off specialty will reject the claim downstream.
For years this meant one browser tab on the national NPI registry, one row at a time: type the number, read the record, eyeball the specialty, copy the status into the load file. Twenty providers was a morning. And it was reliable exactly as long as she was not rushed, which, at roster-load time, she always is. The rejects that follow a bad load are expensive: reworked claims, provider abrasion, and a network-adequacy report that no longer matches reality.
So she changed the mechanical part. She wired the national provider registry directly into Claude as a tool, using the official Apify MCP server, and let the model do the lookups. Setup was one config block and a restart. Nothing about how she works changed: she still opens a chat and types in plain English.
The tool she connected:
The NPPES NPI Healthcare Provider Data Scraper returns the full registry record for any US provider: NPI status, entity type, legal name, credential, the full taxonomy (specialty) list with license numbers, and practice address. Exposed to Claude through one MCP endpoint, it turns a tab-and-type chore into a sentence.
The batch
Monday morning, a new roster: six providers to verify and load. A multi-specialty facility, a couple of dentists, a cardiologist, an oncologist, and an eye doctor. Instead of opening the registry six times, Priya pasted the list into Claude and asked it to check each NPI for status, type, and a taxonomy match against the specialty her sheet claimed.
A few seconds of tool calls, and the picture was clear. Five of the six came back clean:
- Mayo Clinic (NPI 1881018208): Active, Type 2 (Organization), Clinic/Center, Multi-Specialty, Rochester, MN. Matches "facility."
- Dr. Steven Aaker (1538202965): Active, Type 1, Dentist (DDS, license D8075), Prior Lake, MN. Matches "general dentist."
- Dr. John Aamodt (1790723302): Active, Type 1, Dentist, Orthodontics, Eagan, MN. Matches "orthodontist."
- Dr. Michael Aaron, MD (1790762623): Active, Type 1, Internal Medicine, Cardiovascular Disease, West Islip, NY. Matches "cardiologist."
- Dr. Laurent Gressot, MD (1215930367): Active, Type 1, Hematology & Oncology, Houston, TX. Matches "oncologist."
The sixth is the reason the check exists. Dr. Steven Sheiner (NPI 1417918293) came back Active (so a naive "is the NPI good?" check would have waved it through), but the registry listed him as an Optometrist, while Priya's sheet claimed ophthalmologist. Claude flagged it and offered to pull the detail.
This is the part that matters. A live, Active NPI is not the same as a correct roster row. The registry check catches the difference and says why, so the flag is auditable, not a hunch.
The catch
Priya asked Claude to open up row six: why the flag, and what exactly to tell contracting.
The detail made the problem concrete. The registry record for NPI 1417918293 shows the provider's credential is OD (Doctor of Optometry) and the primary taxonomy is 152W00000X, Optometrist, licensed OPC3172 in Florida. The roster claimed Ophthalmology (207W00000X). Those are two different professions: an optometrist (OD) and an ophthalmologist (MD) are not interchangeable, and they carry different billable service sets.
Loaded as an ophthalmologist, this row would have sailed past a basic eligibility check and then rejected the moment a claim came in with a procedure code restricted to that specialty, a taxonomy edit denial. The provider disputes the denial, and it lands right back on Priya's desk weeks later, harder to trace. Caught at load time, it is one line in an email to contracting: the registry shows this NPI belongs to an optometrist, not an ophthalmologist, so either the wrong NPI was pulled for the intended physician or the specialty column is wrong. Confirm which, fix it, then load.
Nobody had to remember the OD-versus-MD distinction, or hold the taxonomy codes in their head. The check was one sentence, backed by the live registry rather than anyone's memory of what Dr. Sheiner does.
The load ticket
The last step used to eat the most time: writing it all up so the load could proceed and an auditor could follow it later. Priya asked Claude to consolidate the morning's verification into a go/load table she could attach to the ticket.
Six providers, six decisions, each with the NPI status, entity type, and registry taxonomy it was based on. Five cleared to load, one on hold pending a specialty correction. The whole thing traces back to the official registry, so the load ticket carries its own evidence. If a claim on any of these providers is questioned six months from now, the reasoning is right there.
What actually changed
Priya still owns the judgment. She still decides what loads and what goes back to contracting. What moved to the machine was the mechanical part: the tab-switching, the copy-paste, the risk of skimming a taxonomy under deadline. That is the right division of labor:
- The lookup is automated. Claude pulls the live registry record the moment the conversation needs it, one NPI or fifty.
- The evidence is preserved. Every verdict cites a status, a type, and a taxonomy code, so the load ticket is audit-ready by default.
- The check is consistent. The same three tests run on row six as on row one, at 9am or at 6pm, whether or not it is a busy morning.
The mismatched provider was caught before a single claim rejected. On the old one-tab process, an Active NPI with the wrong specialty is exactly the kind of thing that gets waved through under time pressure, and surfaces later as a denial report.
Build the same agent
Everything in this story is reproducible today with a free Apify account and any MCP-capable client (Claude Desktop, Cursor, or your own agent):
- Get your Apify API token from the Apify Console under Settings → Integrations.
- Add the official Apify MCP server to your client and list the Actor in the
toolsparameter:
{
"mcpServers": {
"apify": {
"url": "https://mcp.apify.com?tools=scrapers_lat/nppes-npi-scraper",
"headers": { "Authorization": "Bearer YOUR_APIFY_TOKEN" }
}
}
}
- Restart the client and paste a roster in plain English. Ask it to confirm each NPI is Active, the right type, and a taxonomy match. It will pick the tool and do the lookups.
📌 Note: each tool call is a real Actor run billed to your Apify account (the NPPES Actor is pay-per-result, a fraction of a cent per lookup). For a nightly re-verification of an entire loaded network (catching providers who deactivate or change taxonomy after you loaded them), run the Actor on a schedule through the Apify API instead of one call per chat.
🏹 Extend it: the same pattern covers the rest of a provider-file check. Add SAM.gov exclusions to screen each provider against federal exclusion and debarment lists, or the OFAC sanctions list for a sanctions check, to the tools list, and your roster agent verifies more of the file without a line of new code.
The Actor used in this story: NPPES NPI Healthcare Provider Data Scraper.
Top comments (0)