Bowst Team
There’s a federal database that contains every licensed healthcare provider in the United States. Every physician, every physical therapist, every hospital, every clinic. 9.5 million records, maintained by the Centers for Medicare & Medicaid Services, freely available to anyone who wants it. It’s called the National Provider Identifier registry, and it’s one of the most useful datasets in healthcare that almost nobody uses well.
We recently built something on top of it. How we did it, and why AI made the difference, is worth sharing.
The problem Help Hope Live brought us
Help Hope Live is a nonprofit that does something rare: they hold and manage medical fundraising for people facing catastrophic illness or injury. When someone needs a kidney transplant or long-term rehabilitation they can’t afford, Help Hope Live creates a campaign, accepts donations on behalf of that person, and ensures the funds go toward legitimate medical care.
That last part matters. Before a campaign goes live, Help Hope Live needs confidence that the medical professionals and medical centers involved are real and appropriately licensed. A legitimate oncologist. A certified transplant center. Not a name and an address someone typed into a form.
Their old process was manual: staff looking up providers one by one in the public NPI search interface, copying information, cross-referencing. Slow, error-prone, and hard to scale. And because the stakes are real — donors trusting a cause, patients depending on the accuracy of that trust — “close enough” wasn’t a standard anyone was comfortable with.
The realization
When Help Hope Live brought us this problem, the first instinct might have been to build a better search form. A cleaner UI over the public NPI registry API. Something that made manual lookup faster.
We didn’t do that.
The data already existed and it was authoritative. The NPI registry is the source of truth and there’s no better data to build on. The question wasn’t how to make the lookup interface prettier. It was whether we could remove the friction between someone asking a question in plain English and getting a confident, sourced answer back.
That’s the problem AI is actually good at.
How we built it
We started by downloading the full NPPES dataset, the raw CMS data file, and importing it into a Postgres database. All 9.5 million records across four tables: core provider records, taxonomy and specialty codes, alternate names, and practice locations. A complete, queryable mirror of the federal registry.
Then we gave GPT-4o one job: read what a user types and figure out what to search for.
The backend is an Express server with a single meaningful endpoint. When a user sends a message, we send the full conversation history to GPT-4o along with a system prompt and one available tool: search_npi_registry. GPT-4o decides when to call it, extracts structured search parameters from the natural language query (name, state, city, specialty, NPI number) and our server runs a parameterized SQL query against the local database.
The results come back to GPT-4o, which formats them into a plain-language response. Name, NPI number, specialty, address, license status. Something a non-technical staff member can read and act on.
Two design decisions made this work well in practice.
The first was nickname handling. The NPI registry stores legal names: Robert, not Bob; Rebecca, not Becki; Margaret, not Peggy. Users don’t always know that. We built a nickname mapping layer that expands informal names into their legal equivalents at the query level, so a search for “Dr. Bob Smith” doesn’t come back empty just because the record says “Robert.”
The second was a fallback strategy baked into the system prompt. If a search returns zero results, GPT-4o doesn’t give up. It tries progressively broader queries: formal name, then last name only, then drop the city, then drop the state. Up to six rounds before it tells you it couldn’t find anyone. Most searches succeed within two or three.
The frontend is a simple React chat interface. You type something like “Dr. Lisa Chen, pediatric cardiologist in Chicago” and get back a verified NPI record within a few seconds. Try it here.
What this means
This project took weeks, not months. That matters.
Before tools like GPT-4o, turning a 9.5 million-record federal dataset into a natural language interface would have required significant investment: custom NLP, named entity recognition, elaborate query parsing logic, expensive to build and fragile to maintain. Most clients would have settled for a better form.
AI changed what’s in reach. Not because it does the work for you. The interesting work is still the design: what data to trust, what fallback logic to build, where the system should say “I couldn’t find that” instead of guessing. But it removes enough friction that a problem which used to require a long project can be a focused one.
That’s what I mean when I say we’re using AI to build better products. Not a chatbot for chatbot’s sake. A specific answer to a specific problem: a healthcare nonprofit that needed to verify providers faster and more reliably than a manual process allowed. The AI is the piece that converts an authoritative dataset into something a non-technical person can use in an ordinary conversation.
The broader pattern
The most valuable AI applications we’re building right now share a structure: there’s a source of truth that already exists (a database, an API, a knowledge base), a user who needs information from it, and a gap between the way that user naturally asks questions and the way the data is structured to answer them. AI bridges that gap.
If you’re sitting on a data problem that feels too messy, too manual, or too expensive to solve the traditional way, that’s often exactly where this approach is most useful.
We’re happy to talk through what we’ve learned. Reach out.
