Think in systems, not tasks

The next-task trap

Ask most teams how the day went and you will hear a count. Faxes worked, calls answered, authorizations submitted, claims sent. The inbox, the queue and the to-do list all reward the same thing: finishing the next item.

It feels like progress, and at the level of the task it is. But a patient does not experience tasks. A patient experiences one journey: a referral, a booking, an exam, a report, a bill. If that journey stalls between two well-run tasks, nobody’s count shows it.

The systems scientist Donella Meadows described a system as elements, the connections between them and a purpose. We notice the elements. The connections and the purpose decide how the system behaves. In an imaging center, those are the tasks, the hand-offs and the goal: a patient scanned, the report back, the exam paid.

W. Edwards Deming put a number on it. In Out of the Crisis he estimated that 94% of troubles and opportunities for improvement belong to the system, and only 6% to special causes such as one person or one machine. Later, in The New Economics, he said it more plainly: "No amount of care or skill in workmanship can overcome fundamental faults of the system."

That is the trap. When work is measured one task at a time, everyone can be busy, every task can be done well, and the order still does not move.

After Donella Meadows, Thinking in Systems (2008), and W. Edwards Deming, Out of the Crisis.

The tasks sit above the waterline, where they are easy to count. The hand-offs and the goal sit below it, and they decide what the patient gets.

Engineering a task is not engineering a system

Engineers learn this distinction the hard way. An engineering task has a specification, an owner and a definition of done. An engineering system has a purpose, and most of its behavior lives in the interfaces between tasks, where no single owner is looking.

The clearest example is NASA’s Mars Climate Orbiter, lost on September 23, 1999. The investigation board found the root cause in one ground software file. It reported thruster data in English units, pound-force seconds, when the interface specification called for metric newton-seconds. The navigation team assumed metric, as the specification said. Each team did its task. The interface between them sent a spacecraft too close to Mars.

The board also faulted the lack of end-to-end verification. Nobody had checked the system as a system.

I came to imaging from semiconductors, where the same lesson is built into the arithmetic. A wafer goes through more than a thousand process steps, and yield multiplies across them. You cannot run a fab by celebrating good steps. You run it by watching the whole line.

Illustrative arithmetic: share intact = (rate per step) to the power of the number of steps.

Good steps do not add up. They multiply, and the line only pays for what survives every one of them.

Why you can’t go back

Systems thinking is a one-way door. Once you have seen how the work actually moves, a list of tasks stops looking like a plan. It starts looking like a map with the roads left out.

Three things change for good.

• You look for the constraint, not the busiest desk. Eliyahu Goldratt’s The Goal made the point with a factory: an hour lost at the bottleneck is an hour lost for the whole system, and an hour saved anywhere else is a mirage. Speeding up a task that is not the constraint changes nothing the customer feels.

• You stop asking who dropped it. You ask why the system let it drop. That is Deming’s 94% in practice, and it is kinder to the people doing the work.

• You measure the journey, not the step. Tasks closed per person tells you about effort. Time from referral to report, and from exam to payment, tells you about the system.

Why does this matter more now than it did ten years ago? Because the work between the steps used to need a person. Only a person could read the fax, make the call or work the payer portal, so the journey was split into pods of people, each holding one piece. That constraint is gone. Agents can hold the call, read the fax and work the portal. The question is no longer which tasks to speed up. It is which system should do the work.

Imaging centers: one journey, run as pods

Walk through a freestanding imaging center and you will see the org chart in the work: intake, booking, authorization, the exam and the read, then billing. Each pod has its own queue, and often its own information system.

Every pod can be excellent and the center can still lose. Every order has three chances to be lost: before it arrives, before it is scanned, and before it is paid. None of those losses is one person’s mistake.

One imaging order, five pods, three leaks.

That is why the simplest question is so hard to answer. How many referrals did you lose last month? Most imaging centers can’t say, because the answer is split across three systems.

The people in those pods are not the problem. They are what holds the journey together today, by phone, by fax and by memory. Prior authorization shows the cost. In the AMA’s 2025 prior authorization survey of 1,000 physicians, released in May 2026, practices reported 40 authorizations per physician per week and 13 hours of physician and staff time spent on them. Two in five physicians employ staff who do nothing else, and 95% say prior authorization delays necessary care. A whole role now exists to carry one task across a line in the org chart.

The outside world is starting to move as a system. Since January 1, 2026, the payers covered by CMS’s Interoperability and Prior Authorization rule must decide expedited requests within 72 hours and standard requests within seven calendar days, and a FHIR prior authorization interface follows from January 2027. The payer’s clock is getting shorter. Inside the center, the clock is still set by how long an order waits between pods.

We learned this before we wrote any software. Alpha Nodus started after someone very close to our founder could not get a scan for six weeks. When we put sensors in imaging centers, the machines were in use 60 to 65 percent of the time while patients waited. The constraint was not the scanner. It was the operation around it. So we spent a year doing every job on the front desk before we wrote a line of code, and the pods looked very different from the inside: each one working hard, none of them able to see the whole order.

One order, one system: the Agentic Operations System (AOS) for imaging

Information systems record the work. An AOS does the work.

That sentence is systems thinking applied to imaging software. A CRM is a system of relationships. A RIS is a system of orders. An RCM is a system of claims. An AOS is a system of work. The first three each see their own third of the journey; an AOS sees the order whole.

Three information systems compared with one system of work.

The job it does is the same journey the pods share today: get the order, complete the exam, get paid. What changes is who carries the order between steps. Agents work the order. Your people work the exceptions. Where the work is routine, Gravity just does it. Where it takes intelligence, reading the fax, making the call, working the portal, Gravity’s agents do it, and your people either review the work or handle the exceptions.

A system needs a system-level measure, not a count of tasks closed. Ours is simple. An AOS is measured by how many tasks finish without your staff touching them. It is the fab engineer’s question asked of an imaging center. Not how good each step is, but how much of the line runs straight through.

How does that fit with what a center has today? It can run on top of the systems you already run. More than 460 imaging centers across the US run 5.7 million imaging orders a year through Gravity, from the referral to the payment.

And what happens to the team? Gravity takes over the tasks, not the people. The routine work completes on its own, so your team can give patients the attention the paperwork used to take.

That is what thinking in systems buys you. Not a faster next task, but an order that finishes.