> ## Content Index > Fetch the complete content index at: https://agility-by-nexcurve.ghost.io/llms.txt > Use this file to discover other available public pages before exploring further. # Make the System Carry the Complexity - URL: https://agility-by-nexcurve.ghost.io/make-the-system-carry-the-complexity/ - Published: 2026-09-02T19:24:23.000Z - Updated: 2026-09-02T20:16:35.000Z - Description: The Difference Between Helping Patients Navigate Complexity and Absorbing It Inside the Network - Author: Michael A. Eaton - Tags: Clinical Integration, Physician Enterprise Leaders, #Series Performance, Engineered · 1 of 3 In recent months, I have been meeting with physician enterprise and network leaders about what comes next in the evolution of their business and operating models. A recurring theme has been the next step in clinical integration: moving from primarily measuring and managing performance to actively engineering how the network responds before avoidable problems occur. In this progression, clinical integration came first to create the performance foundation. It gave physician enterprises better visibility into care utilization, care model variation, physician performance, care gaps, and total cost. It also created stronger expectations for accountability. All of that is important. But much of that still happens after the fact. By the time a performance report tells us where utilization increased, where access broke down or where cost moved in the wrong direction, the patient has already moved through the system, scarce capacity has already been used and the opportunity to shape the outcome may have passed. Going forward, that will not be enough. High performance requires us to work earlier. It requires a network that can anticipate demand, understand what capacity is available and organize a response before delay, poor utilization or avoidable cost occurs. The leaders I speak with generally agree with that direction. The harder question they pose is what it actually means in operational terms. This is the first in a series of three articles focused on that question. The goal is to move from theory to practice by identifying operating changes that physician enterprise leaders can assign, measure and manage. The first starts with a simple idea: ## The System Should Do More of the Work Healthcare still asks too much of the consumer. We give patients provider directories, portals, phone numbers, referral instructions, benefit rules and scheduling options, then expect them to assemble the right path on their own. They have to decide whether and how quickly they should be seen. They have to determine whether primary care, urgent care, virtual care or the emergency department is the right place to start. They have to find out who accepts their insurance, which specialist is appropriate, where capacity exists and what to do when the first available appointment is weeks or months away. In many cases, we describe this as consumer choice. But choice and complexity are not the same thing. Giving patients more options does not necessarily make healthcare easier to use. In many cases, it simply transfers operating complexity from the system to the patient, a fact which confounds the people that we serve, adds avoidable cost and eats up scarce capacity. Other industries have moved in the opposite direction. Consumers do not need to understand the logistics network behind Amazon, the routing logic behind Google Maps or the payment infrastructure behind their banking app. They express an intent and the system does the complicated work required to fulfill it. Healthcare is obviously different. The stakes are higher, the decisions are more consequential and the operating environment is more complex. That is precisely why expecting the patient to manage that complexity is such a weak operating model. The patient should not need to understand how the system is organized in order to get the right care. The network should be able to interpret the need, recommend the appropriate pathway, identify usable capacity, make the connection and remain accountable until the issue is resolved. That is the difference between navigation and orchestration. - Navigation helps the patient work through complexity. - Orchestration absorbs more of that complexity inside the system. A navigator may give a patient a list of cardiologists and instructions about whom to call. A high-performing operating system should know which cardiologist is clinically appropriate, participates in the patient's coverage, meets network performance expectations and has usable capacity within the required timeframe. It should then help arrange the connection while preserving clinical judgment and patient preference. That requires the network itself to perform. ## High-Performing Networks, Not Just Practices A physician enterprise can contain excellent physicians and still perform poorly as a system. Patients can wait too long and referrals can disappear. Capacity can remain invisible and information can break across sites. Scarce appointments can still go to whoever happens to call first. High performance therefore cannot simply mean having high-performing *providers*. It means creating a network that can see demand, see capacity, connect the two intelligently and keep the patient's care connected. In practical terms, that requires four operating capabilities. **1\. Understand demand** Can we consistently identify the patient's clinical need, level of urgency and appropriate level of care at the point of entry? **2\. See capacity** Can we see usable capacity across the network, not simply published schedules or individual appointment books? **3\. Route deliberately** Can we direct patients based on clinical need, access, performance, continuity and cost rather than relying primarily on historical referral patterns or whoever happens to have an opening? **4\. Own resolution** Can we tell whether the intended care actually happened, and does the system intervene when it does not? This is where performance engineering becomes tangible. The network still measures utilization, but it also begins to shape it. Capacity stops being treated solely as a collection of independently managed appointment books and starts becoming a network resource that can be deployed against patient need. The system stops relying on the patient, family or referring physician to connect the pieces and starts taking greater responsibility for making those connections work. That gives leaders a straightforward operating test: > **Who is carrying the complexity?** If the patient, family or referring physician is still responsible for figuring out what happens next, the network has more work to do. The goal is not to eliminate complexity. Healthcare is too clinically and operationally complex for that. The goal is to absorb that complexity where the organization has the data, expertise and operating leverage to manage it. When that happens, the experience becomes simpler for the patient and the network becomes more deliberate in how it uses scarce capacity. That is performance engineering in practical terms: the patient should experience less complexity because the network is doing more of the work. --- **J. Michael Eaton** — SVP, Healthcare Strategy, Nexcurve *Agility by Nexcurve.* Articles, analysis, research and relationships for healthcare leaders building a professional legacy through transformation.