Provider data management (PDM) has a customization problem. Not too little of it — too much. Health plans have spent years, and in some cases hundreds of millions of dollars, bending Salesforce, building homegrown systems, and layering vendor solutions on top of each other to get something that mostly works. By the time the project is done, the regulations have changed, the team has different requirements, and the system that was purpose-built for last year's problems is already obsolete.
At Blueprint 2026, CertifyOS CPO Simon Hayhurst and the product team gave the room its first live look at Provider Hub — the next generation of the CertifyOS PDM platform, purpose-built to break that cycle. Here's what makes it different.
Configuration, Not Customization, and the Difference is Everything
The demo team was direct about this from the first slide. Customization is a banned word at CertifyOS. Not because the platform can't adapt to your needs — it can, extensively — but because the word itself represents the wrong mental model.
Customization means bending a system to fit a use case it wasn't designed for. That's how you end up with a $200M Salesforce implementation that's taken three years to build, is already out of compliance with new regulations, and requires a dedicated team just to maintain. Configuration means choosing how a purpose-built system works for you:
- what fields you surface
- what survivorship rules govern conflicting data
- what workflows your teams see
- what your providers are asked to attest to
Every element of the Provider Hub dashboard is configurable. How you see your network on a map, which compliance tiles surface, how rosters are sliced and filtered, what fields appear in your provider portal. All of it is configuration, not code. No development cycles. No waiting rooms for IT.
When one health plan asks for a new capability, every plan benefits from it. That's the promise of a shared platform over a customized one; improvements compound across the whole network rather than sitting in one org's private fork of the codebase. And when regulations change — which they do, constantly — the platform adapts once, for everyone.
A Golden Record with Lineage — Because You Need to Know Why the Data Says What It Says
Every provider data system promises a source of truth. Provider Hub delivers something more useful: a source of truth you can interrogate.
The golden record at the center of Provider Hub shows not just the current operating value for any data field, but every source that contributed to it, the survivorship logic that determined which one won, and the full history of every change that's ever been made. When your delegate roster says a provider is in one location and CAQH says something different and your provider relations team has entered something else entirely, you don't just see the result — you see the reasoning.
"We talked a lot about AI yesterday and how none of it really matters if you don't have governance, if you don't have lineage, if you don't have history."
— CertifyOS Product Team, Blueprint 2026
Survivorship logic — which source wins when data conflicts — is fully configurable at the field level. For specialty, you might configure CAQH as the authoritative source over roster uploads. For language spoken, you might trust the provider's own portal attestation over any roster. For NPI, you validate against NPEZ. Every field, every source, every decision is visible and auditable.
This matters especially as AI becomes a bigger part of the workflow. An AI system is only as trustworthy as the data it runs on. Building that infrastructure — the lineage, the survivorship, the governance — is the prerequisite for everything else, not an afterthought.
A Data Model That Reflects How Provider Data Actually Works — Not How It Was Once Simplified
The complexity of provider data is not a bug. A physician can be a cardiologist at one group on Tuesdays, a general internist at a different location under a different group on Thursdays, accepting new patients at one place but not the other, admitting at a hospital where they don't have an office, and enrolled across three different plan networks under the same NPI. All of that is real, and all of it needs to be representable.
Provider Hub is built around four root tables: Practitioners, Locations, Networks, and Groups. Any attribute can be applied at any level or any combination of levels. A provider can have multiple specialties at multiple locations, each associated with different networks, each with different panel statuses and office hours. The data model reflects the real ontology — not a simplified version of it that creates problems downstream in directories, claims, and contracting.
What's visible in the platform — what a provider sees in their portal, what an admin sees in their dashboard — is a configurable view on top of that model. The underlying data is captured in full. How it's surfaced depends on the workflow.
"I haven't heard anything in any of these scenarios where we are not accepting or structuring the data in a way that can be presented to you in the way that you want to see it. It's a data problem. It's a structuring problem. And if you have those core root tables and you can combine them in a really scalable way, we should be able to match all these use cases."
— CertifyOS Product Team, Blueprint 2026
Roster Ingestion That Works with the Real World — Not the Template You Wished Delegates Would Use
Delegates don't use your template. They use their template, which is different from your other delegate's template, which is different again from the one you actually need. Provider Hub ingests any format, maps it to CertifyOS's schema automatically using AI-assisted field matching, validates it against configurable rule sets, and flags anomalies for review — all before a single row lands in your network.
The mapping isn't a one-time setup. When a delegate sends 'PCP Practitioner Role' and you need 'Practitioner Role,' the system recognizes the likely match and maps it — with the ability to override if it got it wrong. Specialty taxonomies are validated and corrected automatically. Addresses are standardized against the USPS API. Phone numbers are formatted consistently. NPI digits are validated against NPEZ.
What can be auto-corrected is. What needs human judgment gets flagged. And once a correction is made, survivorship logic remembers it; if a delegate keeps sending an incorrect phone number, the system flags the discrepancy and asks whether to trust the previously corrected value or the new incoming one.
Anomaly detection works at scale too. If a roster upload suddenly drops 30% of your providers, or if a single operator makes a bulk change that looks statistically unusual, Provider Hub flags it before it becomes a downstream problem in your directory or claims system.
A Provider Portal That Puts Providers in Control — And Makes Their Data Accurate as a Byproduct
The session's live demo showed something that rarely gets demonstrated in PDM conversations: the provider side. Logging in as a physician, the demo showed a portal where providers can see exactly what data the plan has on them — their specialties, licenses, DEA numbers, board certifications, group affiliations, location associations, panel statuses, and network enrollments — and interact with it directly.
Providers can attest No Surprises Act compliance, update panel status at a specific location, flag telehealth-only availability, and make corrections to any field they have permission to edit. Office administrators can make bulk changes on behalf of providers, with changes staged for provider review and attestation before they're committed. Every change is tracked, timestamped, and attributed.
The portal is modular by design. Plans using CAQH, Availity, or their own homegrown provider portal can plug those data sources into Provider Hub via API and get the same survivorship logic, lineage tracking, and golden record benefits. The portal is the recommended entry point — but it's not the only one.
And looking ahead, the vision articulated at Blueprint is shared PDM: a future where a provider updates their location in one plan's system and that change — with appropriate approval workflows — can propagate to every plan in the shared network. One update, not twenty.
Accuracy, Speed, and Efficiency — With a Roadmap Built Alongside the People Who Use It
Simon Hayhurst opened the session with three non-negotiable values: accuracy, speed, and efficiency. Not as marketing language, but as engineering constraints. Every decision about what to build and in what order runs through those three filters.
The roadmap process is unusual for a vendor. Twice a year — once virtually, once in person — CertifyOS brings health plan executives together to align on what's now, what's next, and what's later. Now is largely locked in: Provider Hub refinement, AI integration into production workflows, and shared credentialing infrastructure. Next is open for input. Later is where the room gets to shape the future.
The AI work already in production reflects this philosophy. CertifyOS is already running automated scraping across 400+ source sites, pulling license information and actions at scale and converting them into verified data points with no manual copying. That work — which used to be done by humans scrolling through PDFs — is increasingly handled by AI agents, with human review at the exception points rather than throughout the whole process.
"Even though these technologies may not be entirely perfect, they're already significantly better than humans — because humans definitely make mistakes, especially when you're doing the same thing over and over again."
— Simon Hayhurst, CPO, CertifyOS
The direction is clear: a platform where the data arrives more accurately, processes faster, costs less to operate, and gives health plans the infrastructure to build whatever comes next — shared credentialing, AI-powered directories, real-time verification — on top of a foundation they can actually trust.
Want to read more about Blueprint 2026? Find out what two of health care’s sharpest minds had to say about bridging the Ops-Tech Gap.