The three systems problem — why multi-site specialty surgical practices cannot answer the questions that matter
Every multi-site specialty surgical practice runs on at least three systems.
The first is the EMR — where scheduling, referrals, clinic encounters, charges, and patient demographics live. Common examples in specialty surgical are Integy, Nextech, ModMed, and Epic.
The second is the ASC platform — where surgical records, clinical timing, OR utilization data, and ASC billing live. HST Pathways is the dominant platform in this category. It is where the surgical record is created when a patient enters the ambulatory surgery center.
The third is the billing system — where claims, ERA payments, payer remittances, and accounts receivable live. This is where revenue cycle management happens.
Each of these systems is good at what it does. None of them communicate with the others. And the questions that matter most to leadership — why is our cancellation rate 28%, which locations are driving it, are our payers paying what our contracts say they owe — require data that spans all three.
The patient identity problem
The most fundamental issue is that each system assigns a different patient ID to the same person.
When a patient schedules a procedure at a pain management clinic, they get an Integy PersonNumber. When that same patient shows up at the ASC for the procedure, HST Pathways creates a new patient record with an HST PatientID. When the claim is filed, the billing system creates another record.
Three records. Three IDs. One patient.
This is not an oversight. It is how these systems were designed — to manage their specific function independently. The EMR does not need to know about the ASC record to manage the clinic encounter. The ASC platform does not need to know about the billing record to manage the surgical workflow.
But the COO asking "of the 400 cases we scheduled last month, how many were performed, how many cancelled, and which prior auth denials caused cancellations?" needs all three records connected for the same patient.
Without the connection, the question cannot be answered with any precision.
What becomes impossible without the connection
The questions that leadership asks — and that have material operational and financial consequences — almost all require cross-system data:
Scheduled-to-perform funnel. Scheduling data is in the EMR. Surgical records are in the ASC platform. Connecting them requires resolving the patient identity across both systems. Without that resolution, you cannot build a reliable denominator for the cancellation rate.
Prior authorization analysis. Auth timelines and approval status live in the billing system or payer portals. The surgical schedule lives in the EMR. Mapping which scheduled cases have confirmed authorizations — and which are at risk of 48-hour cancellations — requires connecting the schedule to the auth records.
Cancellation root cause. Reason codes are in the scheduling system. Payer information is in the billing system. Referral source is in the EMR. A complete cancellation decomposition requires all three — meaning all three systems need to be connected for the same case.
Payer contract reconciliation. Contracted rates are in PDF contracts with legal. Actual payments are in the billing system's ERA records. Comparing what payers owe against what they paid requires digitizing the contracts and connecting them to the ERA data.
OR utilization. Timing data — WheelsIn, WheelsOut, AnesStart, ProcStart, ProcEnd — lives in the ASC platform. Scheduled procedure time and surgeon information lives in the EMR. Calculating utilization variance requires both.
None of these analyses can be completed inside any single system. All of them require the cross-system layer that does not exist by default.
What most organizations do instead
Most multi-site surgical practices manage this by exporting data from each system and combining it manually in Excel.
The analyst (or practice administrator, or billing manager) pulls a scheduling report from the EMR, pulls a surgical record report from HST, and tries to match them up using patient name and date of birth — because those are the only fields that exist in both systems.
The matching is imprecise. Patients with common names get mismatched. Date of birth is sometimes entered differently across systems. The resulting combined file is a best approximation, not a reliable dataset.
This process also takes significant time — often several days each month. It depends entirely on the person who built it knowing how to do it. When they leave, the process stops.
And even when it works perfectly, it only answers the specific question it was built to answer. If leadership asks a follow-up — "show me this by referral source" or "break it down by payer" — the process has to be rebuilt.
The technical solution: patient identity resolution
The correct technical solution to the three systems problem is patient identity resolution — a matching layer that programmatically maps the same patient across all three systems using a combination of identifiers.
The match key varies by system combination. For Integy and HST Pathways — the most common pairing in pain management — the reliable match is DOB + LastName + FirstNameInitial. This combination produces a high-confidence match for the vast majority of patients across both systems.
Once the match is established, a bridge table is created: Integy PersonNumber ↔ HST PatientID. Every subsequent query that needs to connect scheduling data (Integy) to surgical data (HST) uses this bridge table to resolve patient identity before joining the records.
This bridge is the prerequisite for every cross-system deliverable. Without it, the scheduled-to-perform funnel, the cancellation decomposition, the prior auth mapping, and the referral source analysis are all impossible to build reliably.
Building the bridge vs. buying a platform
The natural question is whether an integrated platform solves this. Some EMR vendors offer ASC modules. Some ASC platforms offer billing integration. A few all-in-one healthcare data platforms promise to connect everything.
In practice, none of these fully solve the cross-system problem for multi-site specialty surgical organizations — for several reasons.
First, most practices have already made system investments and cannot migrate. An organization running Integy across 10 locations and HST at 6 ASCs cannot replace either system because a vendor promises integration.
Second, even "integrated" systems often maintain separate patient databases at the system level, producing the same identity fragmentation problem with a different vendor name.
Third, the analytical layer — the queries, the logic, the decomposition methodology — is not a platform feature. It is a diagnostic built on top of the data. Even if the systems are connected, someone still has to know which tables to query, which fields to use, and how to interpret what they find.
The patient identity bridge is not a product. It is a piece of infrastructure that has to be built correctly, verified against live data, and maintained as systems update their schemas.
The practical starting point
For any organization facing the three systems problem, the practical starting point is verification.
Before writing a single production query, the patient identity bridge should be tested: for a sample of 100 patients who have records in both the EMR and the ASC platform, how many can be matched with high confidence using DOB + LastName + FirstNameInitial? What is the false positive rate? What are the edge cases?
This verification step takes one to two weeks and prevents the larger problem of building analytics on a shaky identity layer. Every finding downstream of the bridge depends on the bridge being right.
Once verified, the bridge is the foundation for everything. The scheduled-to-perform funnel, the cancellation decomposition, the prior auth dashboard, the OR utilization analysis — all of them run on top of a patient identity layer that has been verified against live data from both systems.
That is the correct order of operations. Bridge first. Diagnostics second.