Multi-site clinical automation does not fail because facilities are different. It fails because the architecture makes one of two bets — that the facilities are basically the same, or that they are irreducibly different — and both bets are wrong. Copy a single-facility design across every site and it shatters on the first EMR that exports its data differently. Let every site run its own logic and the same payer scenario produces different answers depending on which building the patient walked into, with nobody able to say which answer was right.
The workflow looks identical on paper. The data paths, EMR behavior, staffing patterns, and local exceptions are not. What has to be built is an architecture that centralizes what must stay consistent and lets facilities differ exactly where they legitimately should — and the seam between those two is the whole design problem.
ML LABS built that architecture for HeartSciences, delivered under the ongoing engineering retainer that also produced the clinical billing automation it sits beside. It is the second of two systems the retainer shipped, and it is the one that decides whether the first can survive contact with more than one facility.
Fragmentation Is The Default
Multi-site health systems account for nearly 70% of US community hospitals according to hospital data (AHA, 2024), and almost none of them run one EMR everywhere. Mergers bring legacy systems. Different care settings need different specialized tools. Even an organization standardized on a single vendor runs different versions across sites — and data on hospital EHR adoption (HealthIT.gov, 2024) confirms that near-universal adoption has produced near-universal fragmentation rather than convergence.
The consequence is that clinical data exists in incompatible formats, patient records may not link across sites, reporting requires manual aggregation, and no operational metric can be compared without normalization first. A scoping review of EHR interoperability (Health Informatics Journal, 2025) finds semantic interoperability — the preservation of clinical meaning across systems — to be the dominant unresolved problem, and notes that even where syntactic exchange works, meaning degrades in transit. That is the failure that actually hurts: a diagnosis code that meant one thing at the originating site arrives at the hub as a string no rule can act on, and the workflow stalls in a queue that belongs to nobody.
The signals of it are visible early, if anyone is watching for them. Reconciliation queues that grow faster than they drain. Rule-engine fallbacks firing on a rising fraction of records. The same metric producing different numbers depending on which site's extract drives the report. Patient-matching review queues filling with the same demographic ambiguities. None of these is a minor data-quality issue — each one says the adapter layer is leaking complexity upward into the shared services, and once that starts, every new facility makes it worse.
The Centralized-Federated Pattern
The answer is neither pole. It is a hybrid with three layers, and the discipline is in the boundaries between them.
graph TD
A["Facility A<br/>EHR System 1"] -->|"Adapter"| H["Central Hub<br/>Rules + Identity"]
B["Facility B<br/>EHR System 2"] -->|"Adapter"| H
C["Facility C<br/>EHR System 3"] -->|"Adapter"| H
H --> R["Rule Engines<br/>(centralized)"]
H --> M["Master Patient Index"]
H --> CFG["Per-Org Config"]
R --> D["Reporting &<br/>Analytics"]
CFG --> W["Site-Specific<br/>Worklists"]
style A fill:#1a1a2e,stroke:#0f3460,color:#fff
style B fill:#1a1a2e,stroke:#0f3460,color:#fff
style C fill:#1a1a2e,stroke:#0f3460,color:#fff
style H fill:#1a1a2e,stroke:#16c79a,color:#fff
style R fill:#1a1a2e,stroke:#ffd700,color:#fff
style M fill:#1a1a2e,stroke:#ffd700,color:#fff
style CFG fill:#1a1a2e,stroke:#ffd700,color:#fff
style W fill:#1a1a2e,stroke:#0f3460,color:#fff
style D fill:#1a1a2e,stroke:#e94560,color:#fff- Per-facility adapters that normalize data from each local system
- Central rule and identity services carrying the shared logic and the per-organization configuration
- Local workflow surfaces that preserve the facility variation that is real
Adapters Absorb Local Mess
Each facility gets an adapter that converts its local data into one shared intermediate shape, which puts the messy variation exactly where it belongs: at the edge, contained, one file per site. Adding a facility becomes an adapter problem rather than a platform rewrite. The data arrives through genuinely different channels — web upload, file-based ingestion, API feed — and all of them converge into a single processing flow, which is the same ingress discipline that made the ECG platform's three clinic-to-cloud paths indistinguishable downstream.
Three properties keep an adapter layer from rotting:
- Stateless and idempotent. The same input produces the same output, every run.
- Schema-validated output. Deviations are caught at the boundary, not three stages later in a rule engine that cannot explain itself.
- Incremental extraction. New and changed records only — a full re-extract is a bug that has learned to look like a feature.
Coding systems are where the normalization gets hard. Healthcare runs on overlapping terminologies, and different EMRs use different versions and local extensions of them, so the pipeline has to map facility-specific codes to an enterprise-standard vocabulary before any rule sees them. The UMLS (NLM, 2024) supplies the mapping resources, and research on data interoperability (MDPI, 2025) identifies terminology inconsistency as the primary challenge across multi-site systems — which matches the data-readiness threshold from the billing build next door: when more than 15–20% of extracted records carry missing critical fields, or the same clinical event is coded differently across sites, the adapter is not the problem and normalization comes before automation.
Patient identity is the other edge case that is not an edge case. The same patient appears in several systems with slightly different names and identifiers, and the platform has to link the records without guessing. The pattern that holds is probabilistic matching that scores candidates across multiple demographic fields and routes uncertain matches to human review rather than resolving them silently — a study on patient record linkage (JMIR, 2023) reports ML-optimized matching reaching 100% specificity for definite linkages, which is the property that matters: be certain when you are certain, and escalate when you are not.
Centralize What Must Not Diverge
Some logic becomes dangerous the moment each facility interprets it for itself: eligibility rules, billing validation, reporting definitions, master identity resolution. Those live in the hub, once. When CMS changes a rule, it changes in one place.
A rule that lives in three facilities is three rules. The only open question is when you find out — during an audit, or during a deployment you chose.
Consider what that is worth. A federated design meets a mid-quarter eligibility change with every facility's local team interpreting it, scheduling its own build, and rolling out on its own calendar — and by quarter's end the same payer scenario produces three different outcomes depending on which site processed it, with no clean way to audit which interpretation was correct. In the centralized-federated pattern the rule lives once in the hub, ships behind a feature flag, runs in shadow mode against last week's claims at every site, and surfaces the diff before any facility touches a live patient under the new logic. Configuration decides which sites are eligible to flip the flag and when. That converts a compliance scramble into a routine deployment, and it is the return that justifies the adapter investment in the first place.
Two guardrails make the hub safe. Per-organization configuration controls which capabilities are active, which EHR behaviors apply, and which routing rules run — read at runtime, never branched in code — and the configuration surface compounds multiplicatively, so the interactions between settings are where the bugs live and where the tests have to concentrate. Cross-organization data safety is absolute: data from one organization must never surface in another's views, queries, or exports, and every query and background job is scoped to the requesting organization at the data layer rather than the application layer, because an application-layer check is one forgotten WHERE clause away from a breach.
And not everything should be centralized. Clinical documentation practices, local lab and pharmacy integrations, and state-specific regulatory requirements legitimately vary. Over-centralize and the platform becomes brittle; over-federate and the organization never escapes site-by-site reinvention. Worklists carry that variation honestly — a clinician sees their site, a regional manager sees their region, an administrator sees the enterprise — and the "Unassigned" state, where a patient has arrived but has not been routed anywhere, is a real operational category rather than a bug, and it appears whenever a new device or location joins before anyone has decided where its work belongs.
Where Facilities Resist Standardization
This pattern assumes facilities can produce data stable enough to normalize. Where a site cannot conform to baseline data standards at all — the recently acquired one with entrenched local processes is the hardest version — the adapter model does not bend, it breaks, and forcing it produces an exception queue that swallows the benefit whole.
The move there is not a mandate. Start with the sites that want it, prove the improvement where it is measurable (revenue captured from better eligibility detection is the argument that travels furthest inside a health system), and let the results do the negotiating. A facility that watches a peer site's reconciliation queue empty is a facility that stops explaining why its process is special.
First Steps
- Normalize before you standardize. Get data from a small cluster of facilities into one shape first. Workflow standardization on top of unnormalized data is a rewrite waiting to happen.
- Pick one cross-site workflow and make it the proof. Billing is the natural first — data-intensive, rule-driven, tied to revenue, and measurable enough that the second facility is an argument rather than a request.
- Draw the shared/local line explicitly. Write down which behaviors are enterprise-wide and which are per-site, then make the second list a configuration surface rather than a code branch.
Grow By Adapter, Not By Rebuild
The architecture that scales is the one where the second facility is cheaper than the first and the tenth is cheaper than the second — per-facility adapters absorbing local variation at the edge, centralized rule and identity services holding what must not diverge, and per-organization configuration carrying the difference between them. Every adapter written adds to a library rather than to a maintenance burden, and that is the only test that matters: if facility five costs what facility two cost, the seam is in the wrong place.
Several workflows moving at once across several sites, each one needing the same data paths, the same evaluation, and the same operational plumbing, is not a sequence of projects — it is a program, and buying it as projects is how organizations pay for the same integration three times. An enterprise AI program is the shape that matches it: several workflows built on one architecture, with per-workflow targets written into the contract and 90 days of embedded Operate included, so the platform stays owned through the stretch when the facilities are still telling you what they actually do. Get the seam right and multi-site stops being a multiplier on cost. It becomes a multiplier on leverage.
References
- American Hospital Association. Fast Facts on U.S. Hospitals. AHA, 2024.
- Office of the National Coordinator for Health IT. Non-Federal Acute Care Hospital EHR Adoption. HealthIT.gov, 2024.
- El-Yafouri, R., & Klieb, L. A scoping review of electronic health records interoperability levels, expectations, approaches, and problems. Health Informatics Journal, 2025.
- National Library of Medicine. Unified Medical Language System (UMLS). NLM, 2024.
- Saberi, M. A., et al. From Data Silos to Health Records Without Borders. MDPI Information, 2025.
- Nelson, W., et al. Optimizing Patient Record Linkage Using Machine Learning. JMIR Formative Research, 2023.
