How Operating Layers Create Strategic Advantage & Adaptability

Part Three of MissionViewpoint's series: The Rise of the Operating Layer

The competitive advantages in autism services have traditionally been easy to recognize. Organizations competed through geography. Through recruiting. Through clinical quality. Through payor relationships. Through operational execution. Through scale.

Those advantages aren't disappearing. But another one is emerging alongside them.

The ability to adapt.

Not because providers suddenly need more technology — because the pace of operational change keeps accelerating. AI capabilities are improving quarter over quarter. Practice management platforms continue evolving. Payors change requirements. New software categories appear almost every year.

The organizations that thrive over the next decade won't necessarily be the ones with the best technology. They'll be the ones that can keep improving how they operate without rebuilding the business every few years.

In the first article in this series, I argued that every provider already has an operating layer — that operational decisions increasingly happen outside the practice management platform, because that's where organizations assemble the information needed to run the business.

In the second, I argued that those decisions require a data spine — not to move records between systems, but to move the information needed to make decisions.

The obvious next question: what does that actually look like in practice — and why does it become a strategic advantage rather than just an operational improvement?

Thinking Beyond the Traditional Technology Stack

Most providers think about their technology stack as a collection of applications. Practice management. CRM. HR. Scheduling. Documentation. Recruiting. Each system owns part of the business.

But operational decisions rarely happen inside just one of those systems.

A technician-client match may require information from scheduling, HR, the practice management platform, mapping software, and clinical documentation.

An authorization renewal may require information from utilization, documentation, scheduling, and payor history.

The systems already contain most of the information. The challenge is assembling it around the decision.

One way to think about this is as a modern operational stack:

Notice what changes. People — and increasingly AI — don't begin inside individual systems. They begin inside a decision. The data spine assembles the information needed. The decision engine evaluates it. The decision workspace presents the recommendations — before judgment even begins.

What Each Layer Is Made Of

Before going further, it's worth defining each layer in concrete terms.

Systems of record are the actual vendor applications: practice management, CRM, HRIS, ATS, scheduling, documentation, authorization, RCM. They document the business. That job doesn't change, and nothing here replaces them.

The data spine is a provider-owned operational data repository: a database, warehouse, lakehouse, or structured data model that receives selected data from those systems on a schedule the provider controls. It isn't intended to become another system of record. It contains the operational data needed to support decisions, organized around decisions rather than around the applications they came from.

The decision engine is provider-controlled logic applied to the data spine — the software that evaluates operational conditions and produces recommendations. It does not have to be exotic.

• It may be Python code that scores technician-client matches.
• It may be SQL that flags authorizations with low utilization before renewal.
• It may be stored procedures that update a risk queue every morning.
• It may be a low-code workflow that routes cancellation exceptions.
• It may eventually include AI prompts that summarize the reasoning behind a recommendation.

None of these technologies is the engine by itself; together, they form it.

What matters is not the implementation. What matters is that the provider owns the logic that determines how operational decisions are prioritized. The decision engine isn't a product you buy. It's the logic you own.

The decision workspace is the place people work — where the engine's output becomes usable. It may look like a simple internal web page, a filtered Power BI table, a Salesforce screen, a Power Apps form, a queue in a workflow tool, or a daily alert.

The workspace is intentionally simple. Its job isn't to expose more data. Its job is to expose fewer, better decisions.

The user no longer starts by searching across systems. They start with a short list of decisions that need attention, ranked or explained by the organization's own logic.

In authorization management, one line in that list might read:

J.M. — renewal due Aug 14 — At risk — utilization 71% over six weeks, trending down — next step: review schedule with family before submission.

People — and increasingly AI agents — sit on top. Their judgment hasn't been replaced. It just starts at the decision instead of at the data gathering.

Same systems. Same data. Same people. What the stack changes is everything between the record and the judgment.

Decisions Become the Organizing Principle

Consider technician-client matching.

Historically, a coordinator might open the scheduling system, review technician availability, check insurance eligibility inside the practice management platform, look up addresses in Google Maps, review family notes in their CRM, call a supervisor, update a spreadsheet — and repeat the entire process when the first technician isn't available.

Most of that work isn't deciding. It's gathering.

An operating layer changes the sequence.

• The data spine assembles the relevant information.
• The decision engine applies the organization's matching philosophy. Perhaps continuity of care receives the highest priority. Perhaps minimizing drive time matters more. Perhaps language compatibility outweighs both.

Those aren't software features. They're organizational choices.

Instead of twenty technicians, the coordinator receives three recommended matches with the reasoning behind each one. Human judgment hasn't been replaced. It simply begins much sooner.

The same pattern appears across nearly every operational workflow — authorization planning, scheduling, utilization management, quality review, revenue cycle exceptions. The information already exists. The operating layer reorganizes it around the decision instead of around the application where it originated.

This Is Also Where AI Fits

Much of the conversation around AI assumes that simply adding AI to existing systems will create meaningful operational improvement. Sometimes it will. Often it won't.

AI has the same problem people do: it needs context.

A large language model doesn't know how your organization balances continuity of care against technician utilization. It doesn't know which authorization renewals deserve the earliest attention. It doesn't know how your clinical leadership prioritizes competing operational goals.

Those aren't facts. They're organizational logic.

AI already knows a great deal about the world. It knows almost nothing about how your organization chooses to operate. That's the missing context.

Once that logic becomes explicit inside an operating layer, AI becomes dramatically more useful.

• It can assemble information before someone begins working.
• It can identify operational exceptions.
• It can explain why one staffing option is stronger than another.
• It can summarize documentation requiring review.
• It can monitor hundreds of authorization renewals while surfacing only the handful that truly deserve attention.

The AI didn't suddenly become smarter. The organization did.

Optionality Becomes Strategic

This is where adaptability enters the picture — and where the operating layer stops being an efficiency story and becomes a strategy story. When the decision engine is something the organization controls, nearly every kind of change gets cheaper. Consider what that preserves:

Freedom around workflows. Suppose leadership decides to redesign technician matching — new priorities, new constraints, a different balance between continuity and drive time. The systems of record don't change. The data spine barely changes. What changes is the decision engine, in one place, applied consistently everywhere the next morning.

Freedom around engagement models. Suppose the organization shifts its delivery mix — more home-based services, a hybrid model, a new parent engagement platform. The operating layer incorporates another source of information and another set of constraints. The decision workspaces coordinators already rely on remain familiar, even as the model underneath them evolves.

Freedom around treatment planning approaches. Suppose clinical leadership adopts a new assessment framework, or changes how it weighs clinical trajectory in authorization planning. Those priorities are encoded once, in the decision engine — not retrained coordinator by coordinator, or rediscovered after the next round of turnover.

Freedom around technology decisions. Suppose a better authorization platform enters the market. The decision workspace remains largely the same; only one system beneath it changes. Because the organization's logic doesn't live inside any vendor's product, switching costs shrink — and evaluating new tools becomes an ordinary decision instead of a multi-year commitment.

Freedom around future innovation. Suppose AI becomes capable of handling first-pass scheduling recommendations. The same decision engine that guides people now guides agents. The organization doesn't start over. It extends.

This isn't theoretical. In last week's Operator Spotlight, Behavioral Framework described exactly this pattern: a modular internal layer that started with matching and expanded into utilization and cancellation processing — while Lumary remained the system of record throughout.

Each improvement builds on the same operational foundation. Technology evolves. The organization continues operating according to its own philosophy.

The Strategic Advantage Isn't the Platform

Healthcare technology will continue changing. Better platforms will emerge. Better AI will emerge. Better operational tools will emerge.

The organizations that succeed won't necessarily predict those changes. They'll simply be prepared for them.

That may be the central idea behind this entire series. Every provider already has an operating layer. Increasingly, every provider needs a data spine. But neither is the destination. They are organizational capabilities.

Systems of record capture operations. The data spine organizes operational information. The decision engine evaluates it using provider-owned logic. Decision workspaces present recommendations to people and AI. Better decisions follow — because the information arrives in the right place, at the right time, organized around the work that actually needs to be done.

The strategic advantage isn't having the best platform.

It's preserving the freedom to continuously improve how the organization operates while technology continues to evolve.

That freedom is what allows a provider to scale without calcifying — and, ultimately, it's what more, and better, access to autism care looks like.

This is the third and final article in MissionViewpoint's series on "The Rise of the Operating Layer."

Read Part One: Every Provider Already Has an Operating Layer, and Part Two: Why Every Provider Needs a Data Spine.

P.S. Know someone shaping ABA operations, technology, or investment? Invite them to subscribe to the ABA Mission Newsletter.