Why Every Provider Needs a Data Spine

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

Most ABA providers have more connectivity than they think - and less than what they need.

The gap isn't usually in moving records between systems.

It's in moving the information needed to make operational decisions.

Historically, providers expected the practice management platform to be both the system of record and the place where operational decisions occurred. As organizations have become more complex, those two functions have increasingly diverged.

The ABA technology stack has changed significantly over the last several years. Most providers today have meaningful connectivity across their operations.

• Their CRM pushes referrals into the practice management platform. Intake workflows trigger tasks automatically.
• Authorization tracking tools monitor expirations and submission deadlines.
• Clinical documentation systems pull session data from the platform for audits.
• Some providers have gone further — building API connections, automated reporting pipelines, or purpose-built tools that sit on top of their core systems.

That progress is real.

And it's worth saying directly, because the conversation about data in ABA sometimes implies providers are starting from scratch. Most aren't.

But here's what that connectivity usually doesn't solve.

• It doesn't tell the authorization team whether the clinical picture actually supports the hours being requested at renewal.
• It doesn't tell the recruiting leader which markets are becoming bottlenecks before the caseload demand is already there.
• It doesn't tell the matching coordinator which technician is the right fit for a specific child, family, and clinical situation - even when availability and credentials are visible across connected systems.

The integrations most providers have built are good at moving records.

They weren't designed to support decisions.

That distinction is what the concept of a data spine is actually about.

A useful way to think about a data spine is not as an integration architecture, but as a decision architecture. Its purpose is not simply to move records between systems.

Its purpose is to ensure that the information required for an operational decision can arrive where it is needed, when it is needed, without relying on someone to manually assemble it.

The Gap Between Records and Decisions

Most healthcare technology - and most of the integrations built around it - is organized around records.

• A CRM-to-platform integration moves the referral record.
• An intake automation moves the client record.
• An authorization tracking tool manages the authorization record - expiration dates, submission status, approval codes.

These are genuinely useful. They reduce manual entry, improve consistency, and eliminate the kind of administrative breakdown that used to cost providers hours every week.

But operational decisions are rarely organized around records.

A scheduler isn't asking:

"Show me this employee's availability."

She's asking:

"Which technician is the right fit for this client, this family, and this clinical situation — given everything I know about both of them?"

An authorization manager isn't asking:

"When does this authorization expire?"

He's asking:

"Is this authorization actually supportable at renewal — and are we in a position to defend it upon close clinical examination?"

Those questions require pulling information across systems, combining it with context that isn't captured in any single record, and applying judgment about what the combination means.

The record exists.

The integration may move it.

But the decision — the operational question the team is actually trying to answer — still requires someone to assemble the full picture.

Most providers have connectivity around their records.

What they often lack is connectivity around their decisions.

Where the Manual Layer Still Lives

The easiest way to find it is to look for the spreadsheet that survived the last platform migration - and the one before that.

It's the utilization report that someone exports weekly, reformats, and drops into a shared folder before the clinical meeting.

The matching log that a coordinator maintains because the scheduling system shows availability, but doesn't capture fit.

The recruiting dashboard that an operations leader built because the ATS tracks candidates, but not open caseload demand or credentialing gaps by market.

The exception tracker that a revenue cycle manager maintains because the claims platform surfaces denials, but not the pattern behind them.

These tools exist alongside integrations, not instead of them.

A provider can have a sophisticated authorization tracking tool and still be running their clinical renewal strategy on a manually updated spreadsheet.

Both can be true — and usually are.

That's the important nuance.

The question isn't whether a provider has integrations.

It's whether those integrations reach the operational decisions that determine how the organization actually functions - or whether they stop at the record layer and leave the decision layer to human assembly.

For most providers, even well-connected ones, the answer is the latter.

Prior Authorization: Where Two Layers Become Visible

Authorization management is a useful place to examine this carefully, because it's an area where the record layer and the decision layer have genuinely diverged - and where tools have gotten good at one without fully addressing the other.

The administrative layer around authorizations has improved substantially.

Tools purpose-built for this workflow now handle expiration tracking, submission management, payor follow-up, benefit verification, and eligibility checks with a level of automation and reliability that simply didn't exist a few years ago.

• Providers using these tools don't miss renewal deadlines the way they used to.
• Submission workflows are tighter.
• The administrative overhead that once consumed entire FTEs has been meaningfully reduced.

That's real progress on the process layer around authorization.

What it doesn't address is the decision layer.

A proactive authorization strategy requires something different from tracking and submitting.

• It requires visibility into whether the utilization trend over the last six weeks actually supports the hours being requested.
• Whether the cancellation pattern reflects a family pulling back or a staffing disruption.
• Whether the clinical documentation is prepared for scrutiny.
• Whether the assigned BCBA will be available through the renewal window.
• How this particular payor has behaved on similar clinical profiles.

None of that lives in the authorization record.

It lives across multiple systems and within the operational knowledge of the people doing the work.

The process connectivity is there.

The decision connectivity often isn't.

The Same Pattern Across the Operating Layer

Authorization is the clearest example, but the pattern appears throughout provider operations.

• In technician-client matching, availability is often visible. Fit is not.
• In recruiting, candidates are visible. Future staffing risk is not.
• In clinical documentation review, missing notes are visible. The operational causes behind those patterns often are not.
• In revenue cycle management, denials are visible. The organizational conditions producing those denials frequently are not.

In each case, the integrations help.

They reduce friction, improve consistency, and move records efficiently.

But the operational decision still requires someone to connect information that originates in multiple places.

This Isn't a Reporting Problem

When operational data comes up internally, the conversation usually becomes a conversation about reporting.

• Better dashboards.
• More metrics.
• Improved visibility.

Reporting matters.

But a data spine isn't a reporting initiative.

Reporting tells you what happened.

A data spine supports what happens next.

A dashboard that shows utilization by clinician provides visibility.

A mechanism that surfaces which clients are drifting toward underutilization - and routes that information to the people who can act before a renewal becomes problematic - creates operational leverage.

One informs.

The other moves the organization.

The data spine doesn't replace judgment.

It reduces the manual effort required to assemble the information judgment depends on.

The Real Goal Is Adaptability

It's tempting to frame the data spine as a technology problem.

It's actually an operational capability.

The providers gaining the most leverage aren't necessarily the ones with the most integrations or the most sophisticated platforms.

They're the ones that can consistently move information from where it originates to where it is needed, in a form that supports action.

When that capability exists,

• The benefits compound.
• Problems surface earlier.
• Institutional knowledge becomes less fragile.
• Workflows become easier to adjust.
• New tools become easier to evaluate and integrate.
• Most importantly, organizations become less dependent on any specific platform, process, or individual.

This is one reason so many organizations struggle to realize value from AI initiatives.

AI can help interpret information and accelerate decisions, but only after the underlying information can be accessed, connected, and moved to where the work happens.

When information can move freely, organizations gain something more valuable than better reporting.

They gain options.

And in a market that continues to evolve, options matter.

This is the second in a three-part series around this month's theme of "The Rise of the Operating Layer."

Next in the series: We'll explore how operating layers and data spines create the flexibility to scale while preserving freedom of choice around workflows, engagement models, treatment planning approaches, technology decisions, and future innovation.

P.S. Know someone shaping ABA operations, technology, or investment? Invite them to subscribe at missionviewpoint.com.