A multi-state MSO with 14 clinics decided to roll out AI denial prevention. The pilot at Location 1 worked beautifully: denials dropped 38% in 90 days, the clinical staff loved it, the billing team called it the best thing that had happened to RCM in years. Confident in the result, leadership greenlit rollout across the remaining 13 locations. Eighteen months later, the picture was unrecognizable. Only four other locations had successfully deployed. Two had explicitly rejected the AI after pilot attempts. The rest were in various states of half-implementation. Each location had introduced local customizations during deployment, so what started as one AI system was now six different variants nobody centrally understood. Denial rates network-wide had barely moved. The CIO spent half her time mediating between locations and the central AI team. The board was asking pointed questions about whether the strategy was working.
This is the most common failure mode for multi-location healthcare AI. The technology works at a single location. The strategy of replicating that single-location success across the network doesn’t work. The reason has nothing to do with AI capability and everything to do with architecture: when each location is treated as its own AI project, you end up with N projects instead of one program. The cost scales linearly with locations. The complexity scales geometrically. The risk concentrates at the worst possible places.
The architecture that scales is hub-and-spoke: centralized intelligence and governance, distributed execution and local context. The hub holds the models, the data foundation, the policies, and the institutional learning. The spokes — each location — execute, contribute local data, and apply local clinical context. This article unpacks what to centralize, what to leave at the spokes, and the specific patterns that distinguish multi-location AI programs that scale from those that fragment.
The Three Things That Must Be Centralized
Three components of a multi-location AI program have to live in the hub, not at the spokes. Trying to distribute them is what creates the fragmentation that breaks scale.
The first is the models themselves. One denial prevention model, one documentation completeness model, one coding accuracy model — trained on pooled data from every location in your network, deployed centrally, accessed by every location through a common interface. Centralization gives you three things you cannot get from per-location models. You get statistical power: a model trained on the combined data of 14 clinics learns patterns that no single clinic’s data would reveal, particularly for rare cases. You get consistency: every location gets the same clinical reasoning, the same coding suggestions, the same denial predictions, which means your network’s clinical-financial behavior becomes uniform rather than location-dependent. And you get manageable governance: one model to validate, one model to monitor, one model to update, one model to audit. Compare that to the alternative of governing 14 separate models, each diverging from the others, each requiring its own validation and monitoring overhead.
The second is the data foundation. A unified data layer that pulls clinical, operational, and financial data from every location into a common analytical environment. This sounds obvious and turns out to be the single largest practical barrier to multi-location AI. Locations were acquired at different times, run different EHRs or different versions of the same EHR, use different code sets, define data fields differently, and have varying data quality. A unified data layer doesn’t mean forcing every location onto the same source systems. It means building an integration layer above the source systems that produces consistent, queryable, AI-ready data regardless of what’s underneath. This is technically harder than building the AI models themselves, but it’s the foundation that makes everything else possible. Skip it and you’ll spend the next three years rebuilding the same AI features for each new location.
The third is governance. One AI steering committee. One set of policies. One ethics review board. One risk classification framework. One incident response protocol. Locations can have local representation on the central committee, but the committee itself is unified. This is the one most often violated under the well-meaning logic that ‘each location is different and should have local autonomy.’ The problem is that local autonomy in governance creates exactly the kind of risk concentration that turns one AI incident at one location into a network-wide reputational crisis. You centralize governance not to override local judgment but to ensure that every location is operating to the same standard and that learning from one location’s near-miss informs every other location’s practice.
The Three Things That Must Stay Local
The hub-and-spoke model isn’t a top-down command structure. Three things have to live at the spokes, not at the hub, and over-centralizing them is the second common failure mode.
Workflow execution is local. Your central AI hub doesn’t run your clinic’s day. The AI sends alerts, recommendations, and predictions; the people on the ground integrate them into how they actually work. Location 1’s documentation completeness AI might fire alerts into the EHR; Location 4’s might run alongside the EHR in a separate interface because that’s what fits their physician workflow. The recommendations are the same; the delivery mechanism varies. Force a single workflow across every location and you’ll get nominal compliance and zero adoption.
Clinical context is local. Patient populations differ across locations. Payer mix differs. Specialty mix differs. Local clinical leadership has knowledge about why their location operates the way it does. The central AI model produces a coding recommendation; the local coder applies professional judgment about whether that recommendation fits the patient population and clinical context. This is not a workaround for AI deficiency; it’s how AI is supposed to be used. Pretending the central model knows enough to override local clinical judgment is what creates the cases that show up in your incident reports.
Adoption ownership is local. Your central team can build the most elegant AI in healthcare, but adoption happens one staff member at a time at the front line. Each location needs an internal champion — not someone titled ‘AI ambassador’ on a slide, but a real clinical or operational leader at that site who owns the rollout and is accountable for outcomes. Without this, AI gets deployed and never actually used. With it, AI gets adapted to local needs, real feedback flows back to the hub, and the program becomes part of how the location operates rather than something the central team is imposing.
The Patterns That Make Hub-and-Spoke Work
Beyond the centralization-versus-localization split, three specific operating patterns separate successful multi-location AI programs from the rest. Federated governance is the first. Central policy with local representation: every location has a seat on the AI steering committee, every location’s AI champions meet monthly with the central team, every incident anywhere in the network gets reviewed by everyone within 30 days. This sounds like extra meeting overhead. It is. It also prevents the political dynamics that otherwise erupt when locations feel that ‘corporate AI’ is being done to them rather than with them.
Staged rollout with template replication is the second. You don’t pilot at Location 1 and then deploy at all 13 others simultaneously. You pilot at Location 1, refine, deploy at Locations 2 and 3 in parallel (these are the early-adopter sites with stronger leadership and easier integration), refine again, then deploy at Locations 4 through 8 in your second wave, and so on. By the time you reach Locations 12 through 14, your deployment template is mature, your common pitfalls are documented, and rollout takes weeks instead of months. The template is the asset that compounds; the AI itself is the same everywhere.
Continuous learning is the third. Every location’s outcomes feed back into the central data layer. The model retrains regularly on the combined data, picking up patterns that only emerge at scale. Successful adoption practices at one location get documented and propagated to others. Failed approaches get analyzed and avoided in subsequent deployments. The network gets smarter as a whole, not just at the locations that happen to have strong local teams. After 18-24 months of operation, a hub-and-spoke AI program is materially more effective than it was at launch, while a federation of per-location AI projects is exactly as effective as the average of its parts.
What Doesn't Work: The Four Anti-Patterns
If hub-and-spoke is the pattern that works, four anti-patterns predictably fail. The first is per-location AI projects, where each location runs its own AI initiative with its own vendor, its own models, and its own data infrastructure. This produces a portfolio of incompatible point solutions that can’t share learning, can’t be governed uniformly, and concentrate risk at each individual location. By year three you have a network-wide AI estate that’s impossible to maintain and impossible to improve.
The second is centralized everything, where the hub tries to run not just the AI but the workflows the AI participates in. Standardized AI alerts arriving in standardized workflow tools, with central teams making routing decisions that should be made locally. This produces high nominal compliance and very low actual adoption. Local staff find ways to work around the AI because the AI keeps making decisions that don’t fit their context. Within a year the metrics look fine and the impact has evaporated.
The third is data silos, where each location keeps its own data and shares aggregates or extracts with the hub periodically. This is the most seductive anti-pattern because it appears to respect local data autonomy and avoid the integration work. In practice it means the central model can never learn from real data, monitoring can never detect cross-location patterns, and any incident requires a multi-week data archaeology project. Data silos are the single most expensive shortcut in multi-location AI architecture.
The fourth is top-down deployment mandates, where central leadership decides AI will be used at every location starting on a specific date, without local champions or adoption planning. This produces theatrical compliance — the system gets installed, dashboards show it being used, frontline staff continue working the way they always did. Six months later the metrics look identical to baseline because the AI is being clicked through rather than actually informing decisions. Mandates produce compliance; adoption requires engagement.
The Metrics That Prove It's Working
A working hub-and-spoke AI program produces five characteristic outcomes within the first 18-24 months of operation. New location rollouts complete in 30-60 days rather than 6-9 months, because the deployment template is mature. Cost per AI use case drops 60-70% as you amortize central infrastructure across more locations. Model accuracy improves measurably for rare cases — the cases your largest single location wouldn’t see enough of to train reliably — because pooled data reveals what isolated data hides. Governance overhead per AI feature drops because you’re governing one centrally managed asset rather than N location-specific ones. And frontline adoption rates run 2-3x higher than top-down deployments because local champions and federated governance create the conditions for staff to actually engage with the AI. If your multi-location AI program isn’t showing these patterns 12-18 months in, the issue isn’t the AI; it’s the architecture. The good news is that re-architecting from per-location to hub-and-spoke can be done incrementally — you don’t have to start over, but you do have to commit to the structural change.
About BTCNXT
BTCNXT builds hub-and-spoke AI operating models for MSOs and multi-location healthcare networks. From unified data foundations to federated governance to staged rollout templates, we help operations leaders deploy AI that scales with the network rather than fragmenting with it.
