Healthcare & Life Sciences
Provider Directory Intelligence API
Your provider directory is wrong in ways you cannot currently measure. Patients find out by calling a number that does not answer.
- Health plans
- Care navigation platforms
- Referral management software
- Patient access and scheduling vendors
What your customers would see
example interfaceMockupIllustrative mockup of the interface we would build. Figures shown are examples, not results from a live deployment.
The problem this solves
Directory accuracy is a chronic and well-documented failure. Audits repeatedly find a large share of listed entries containing at least one material error: a clinician who left the practice two years ago, an address that is a billing office rather than a clinic, a specialty copied from a credentialing form that bears no relation to what the clinician actually does, a phone number routing to a disconnected line. The consequences land on patients, who make calls that go nowhere, and on plans, who carry regulatory exposure for network adequacy claims built on this data.
The underlying reason is structural. Directory records are assembled from attestations that providers have little incentive to update, credentialing files that lag reality, and claims data that shows where care was actually delivered but is not designed as a directory source. These disagree constantly, and most systems resolve the disagreement by picking whichever source was loaded last.
What helps is not another source. It is reconciliation across the sources you already have, with a confidence attached to each field and a record of which source said what and when. A directory that admits a phone number is unverified is substantially more useful than one that states it confidently and is wrong.
Who buys this
Health plans, Care navigation platforms, Referral management software, Patient access and scheduling vendors
What the API returns
What comes back
- Reconciled provider records with per-field confidence and source attribution
- Specialties as practised, inferred from claims patterns alongside the attested specialty
- Practice locations distinguished from administrative and billing addresses
- Accepting-new-patients status with the date and method of last verification
- Accepted coverage and network participation, with conflicting sources shown rather than merged away
- Duplicate and identity-resolution output across the identifier schemes in your sources
- A record-level accuracy score plus the specific fields most likely to be stale
- Change events: departures, new locations, specialty shifts and practice closures
Endpoints
| Method | Path | Returns |
|---|---|---|
| GET | /v1/providers/{id} | Reconciled record with confidence and provenance |
| POST | /v1/providers/search | Search by specialty, location, coverage and availability |
| POST | /v1/providers/reconcile | Reconcile a batch of your directory records |
| GET | /v1/providers/{id}/accuracy | Field-level accuracy assessment and staleness |
| GET | /v1/changes | Detected directory change events |
| POST | /v1/verification/results | Feed back verification outcomes from your own outreach |
Request and response
illustrativeRequest
{
"query": {
"specialty": "endocrinology",
"near": { "postcode": "02139", "radius_km": 25 },
"accepting_new_patients": true,
"coverage_id": "plan_ppo_gold"
},
"min_record_accuracy": 0.7,
"limit": 20
}Response
{
"results_total": 14,
"providers": [
{
"provider_id": "prv_210884",
"name": "Dr M. Okonkwo",
"record_accuracy": 0.86,
"specialties": {
"attested": ["Internal Medicine", "Endocrinology"],
"practised": ["Endocrinology"],
"basis": "claims pattern, last 24 months",
"confidence": 0.91
},
"locations": [
{ "type": "clinic", "address": "[example address]", "confidence": 0.94,
"last_seen_in_claims": "2026-09-28" },
{ "type": "billing_only", "address": "[example address]", "confidence": 0.71,
"note": "No encounters originate from this address" }
],
"accepting_new_patients": { "value": true, "verified_on": "2026-08-14",
"method": "provider_attestation", "confidence": 0.62 },
"coverage": [
{ "coverage_id": "plan_ppo_gold", "participating": true, "sources_agree": true }
],
"stale_fields": ["phone", "accepting_new_patients"]
}
]
}Where the data comes from
| Your own directory and credentialing files | The starting record set, including attestation dates, which is what staleness is measured against |
| Your claims data | Where care was actually delivered and by whom — the strongest available evidence that a location and specialty are real and current |
| Public registries and licensing boards | Licence status, registered specialties and disciplinary status, published openly in most jurisdictions |
| Facility and organisation registries | Entity relationships, so a clinician is linked to the right practice rather than a parent corporation |
| Permitted public web sources | Practice websites and listings, subject to terms of use — some explicitly forbid automated collection and we design around those rather than ignoring them |
| Your outreach verification results | Call and attestation outcomes from your own directory validation campaigns, which calibrate every confidence score in the system |
The intelligence layer
The difference between a demo and a service is mostly in this section. These are the parts that keep the answer trustworthy once real traffic is hitting it.
- Identity resolution across identifier schemes with explicit handling of common-name collisions, which are the main source of bad merges
- Per-field reconciliation rather than per-record source precedence — claims are authoritative for location, licensing boards for credentials, attestation for accepting-new-patients
- Practised specialty inferred from claims distribution and reported alongside the attested specialty, never silently replacing it
- Billing-address detection from the absence of originating encounters at an address
- Confidence modelled from source agreement, recency and verification history, calibrated against your own outreach outcomes
- Conflicts preserved and surfaced; the schema shows disagreement rather than resolving it to a single value that looks certain
- Change detection on claims gaps and licensing updates, which typically precede a directory update by months
- Accuracy measurement on a sampled basis against verification outcomes, reported as a standing metric per source
What it changes for the business
Measurable directory accuracy
A record-level score and field-level staleness turn an unmeasured liability into something with a number against it.
Verification effort targeted
Outreach campaigns go to the records most likely to be wrong rather than cycling through the whole directory.
Referrals that connect
Distinguishing clinic from billing addresses and practised from attested specialty removes two of the most common dead ends.
Evidence for adequacy reporting
Provenance and verification dates per field give network adequacy claims something auditable underneath them.
How it fits into your product
How it embeds
- REST search and lookup for live patient-facing directory and referral flows
- Batch reconciliation for periodic sweeps across the whole directory
- Change-event webhooks into your credentialing and directory maintenance workflows
- Confidence thresholds configurable per use, so a patient-facing search can be stricter than an internal view
- Deployment inside your environment where claims data cannot leave it
- Verification feedback endpoint so your own outreach continuously improves the scoring
Included in every build
- Authentication, scoped API keys and per-customer rate limiting
- Input validation with predictable, documented error responses
- Versioned endpoints so your integration never breaks without notice
- Request and response logging for audit and dispute resolution
- Latency, error-rate and usage monitoring with alerting
- OpenAPI specification, sandbox environment and client examples
- Backups, failover design and a documented recovery procedure
- An agreed support arrangement once the service is live
How we would build it
about 12 weeksDiscovery and data review
Weeks 1–2
We agree the exact question the API answers, review the sources you already hold, check what has to be licensed, and write down the response contract your developers will code against.
Architecture and prototype
Weeks 3–4
You get a written architecture plus a working endpoint on real data — narrow, but genuinely callable — so integration can be tested against something concrete rather than a document.
Production build
Weeks 5–10
Pipelines, models, storage, authentication, rate limiting, logging, tests and documentation. Security and observability are part of this phase, not a later one.
Integration and handover
Weeks 11–12
We support your engineers through their integration, run load tests at your expected volume, and agree how the service is monitored and supported once it is live.
Commercial models
There is no fixed price list, because the cost is driven by data complexity, integration count, model requirements, request volume and the support level you need. Scope is agreed in writing before development starts.
Fixed-scope prototype
A defined slice of the service, built and priced as one piece of work. The usual first step when the business case needs proving internally.
Fixed-price build
An agreed scope against a written architecture, delivered for an agreed price. Best when the requirements are already clear.
Build then retainer
We build the service, then operate and improve it under a monthly agreement covering monitoring, updates and model maintenance.
White-label product
The service runs under your brand, your domain and your pricing, with MLPivot invisible to your customers.
Questions buyers ask
Can you guarantee directory accuracy?
No. Nobody can, and a vendor claiming to should be treated with suspicion. Providers move without telling anyone, and some facts are only knowable by asking. What this does is measure likely accuracy per field, expose conflicts instead of hiding them, and point verification effort where it will find the most errors. That is a meaningful improvement over a directory that is confidently wrong, and it is not a guarantee.
Where does the specialty inference come from, and is it reliable?
From the distribution of procedure and diagnosis codes in claims over a rolling window. It is reliable for clinicians with reasonable volume and a clear practice pattern, and weak for low-volume, newly qualified or genuinely generalist clinicians — where it returns low confidence rather than a label. It is always returned alongside the attested specialty, not instead of it.
Does this use patient data?
It reads claims, which are patient-related, and that is a governance matter rather than a detail. The directory outputs are provider-level and contain no patient information. In practice the reconciliation runs inside your environment under your existing permitted uses, and only provider records are produced. We would not design a version that moves claims outside your boundary.
Can you collect this from practice websites at scale?
Partly, and only where terms of use permit it. Some sites allow automated collection, some forbid it outright, and being able to read a page does not mean you may redistribute what is on it inside a commercial directory. We establish the position per source during discovery and treat web data as a supporting signal rather than a foundation.
How often does the accepting-new-patients field go stale?
Fast — it is the least stable field in any directory, because it changes with a clinician's list size rather than with any recorded event. We return it with the verification date and method attached, and the confidence decays with age, so a six-month-old attestation presents as what it is.
Related blueprints
Healthcare Billing Validation API
Pre-submission checks on coding consistency, missing documentation and billing anomalies, returned as review items for a human biller.
Appointment No-Show Prediction API
Cancellation and no-show probabilities per appointment, built to add capacity through reminders and overbooking rather than to ration care.
Medical Document Extraction API
Structured fields pulled from clinical notes, lab reports and referral letters, returned with per-field confidence for review.
Want this built for your platform?
Tell us what your product does today and what you want another system to be able to ask it. We will come back with an approach, a scope and a price.