Interoperability Is Not the Answer. It Is the Admission That You Built the Wrong System.

A new coalition just announced itself to the senior living industry with a compelling story: seven technology companies, unified under one network, solving the interoperability crisis that has plagued operators for decades. The data is real. The problem is real. The outcomes cited — 172 additional days of resident length of stay, 95% reduction in intake time, six hours saved per staff member per week — are genuinely impressive.

I want to be clear about something before I say what I am about to say: I respect the operators and technologists involved. The problem they are trying to solve is the right problem. The interoperability crisis in senior living is not a theoretical concern — it is bleeding operators dry in administrative burden, compliance risk, and lost clinical revenue.

But the solution they are proposing is not a solution. It is a more elegant version of the same problem.

Interoperability, at its core, is the technology industry’s way of saying: we built separate systems that don’t talk to each other, and we are now building a layer to make them talk.

That layer — whether it is an API partnership, a data network, or a coalition of technology providers — is middleware. It is duct tape between systems that were never designed to share a data model. And the history of middleware in healthcare is not encouraging.

The hospital industry spent fifteen years and tens of billions of dollars building HL7 interfaces, then FHIR standards, then HIEs, then integrated networks. The result? Epic. Not because Epic “won” the interoperability wars. Because Epic made the question irrelevant by putting everything in one system from the start.

Interoperability is what you need when you have already made the architectural mistake of building separately. It is not a destination. It is a consolation prize.

Let’s examine the outcomes cited for the OpenLoop Network carefully.

Here is the question that the OpenLoop Network announcement does not answer: What happens when the data flows conflict?

When your EHR says a resident had a change in condition at 2 PM and your engagement platform says she attended an activity at 2:30 PM and your building management system says her door wasn’t opened between 1 PM and 4 PM — which system is right? Which timestamp wins? Who owns the reconciliation?

In an interoperability network, the answer is: someone, somewhere, has to figure it out. A care coordinator. A charge nurse. An administrator pulling reports from three different dashboards and manually identifying the discrepancy. The six hours per week your staff is saving under OpenLoop Network may simply be shifting to a different kind of reconciliation burden that hasn’t been measured yet.

In a unified system, this question does not exist. There is one record. One timestamp. One source of truth. The data cannot conflict because it was never separated.

Brandon Tabbert of New Perspective makes a compelling case for the financial impact of interoperability: “20 days twice a year per resident of clinical revenue that did not exist last year.” That is real money. He is right to identify it.

But consider what that statement actually means. If a change in condition is being identified 20 days later than it should be — and that delay is costing operators clinical revenue twice per year, per resident — the cause is not a lack of interoperability. The cause is that the clinical signal and the care response lived in separate systems, and by the time the data traveled through the integration layer, the window had narrowed.

A unified system does not have an integration layer. The clinical signal and the care response are in the same data model. The change in condition is visible the moment it is documented. The revenue opportunity is captured in real time, not 20 days later.

The OpenLoop Network will close the gap partially. A unified architecture closes it entirely.

The coalition model has a structural problem that is easy to miss in the announcement language: it is a voluntary partnership between competitors.

Every technology provider in the OpenLoop Network has its own product roadmap, its own pricing decisions, its own engineering priorities, and its own commercial interests. The “network” is held together by shared commitment to interoperability standards — which sounds strong until one partner raises its API pricing, another deprioritizes a critical integration in favor of a new feature, a third gets acquired, and a fourth exits the market.

Operators who build their workflows around an interoperability network are not building on a foundation. They are building on a series of handshakes. And in senior living, where clinical continuity and regulatory compliance are non-negotiable, handshakes are not enough.

The vendor risk in a seven-partner ecosystem is seven times the vendor risk of a single platform. That is not a theoretical concern. That is arithmetic.

If you are an operator reading the OpenLoop Network announcement and feeling encouraged, I want to ask you a direct question: Is the goal to connect your current systems better, or to stop needing eight systems?

Because those are different goals with different answers.

If the goal is to connect your current systems better, the OpenLoop Network may help. You will save some hours. You will reduce some friction. You will see some of the data that was previously invisible. And you will continue to manage seven vendor relationships, seven contract renewals, seven integration dependencies, and seven points of failure.

If the goal is to stop needing eight systems — to have one platform that handles clinical operations, financial management, workforce intelligence, resident engagement, compliance, capital reporting, and vendor management in a single data model — then interoperability is not the answer you are looking for. It is the industry’s way of managing the debt from decisions that were made before you got there.

The senior living industry has accepted a false benchmark for too long: we celebrate closing the gap created by fragmentation, rather than asking whether the gap should exist at all.

172 additional days of length of stay because residents feel more engaged and care is better coordinated. That is extraordinary. Now ask: what would the number be if care, engagement, clinical documentation, and operational data had never been separated in the first place? What if the engagement platform, the EHR, the workforce scheduler, and the financial system all ran on the same data model from day one? Not connected — unified.

We do not have that number yet, because no operator has been on a truly unified platform long enough to measure it. That is the data we are going after.

The interoperability movement is well-intentioned and it is better than nothing. If you are running a portfolio today on eight disconnected systems, a well-designed integration network will improve your situation meaningfully.

But interoperability is a bridge. Bridges are useful when you cannot move the destination. The destination here — a single, unified operating system for senior living — is not fixed. It exists. It is live. It is not a roadmap item or a pilot program.

The industry does not need to agree on data standards. It needs to agree that a single resident record, connected to every clinical, financial, operational, and capital workflow in one system, is what the next era of senior living requires.

Interoperability solves yesterday’s architecture. We built for tomorrow’s.

John Hauber is the Founder & CEO of HavenCo, LLC and SeniorCRE, the unified operating system for senior living and care. SeniorCRE connects clinical operations, financial management, workforce intelligence, and institutional capital workflows in a single platform purpose-built for multi-location operators. Learn more at seniorcre.com.

© 2026 SeniorCRE, LLC. All rights reserved.