‍By Margaret Maringa, Senior Analytics Engineer M-TIBA

Across health insurance, insurers are investing heavily in automation to improve claims management, reduce fraud, and strengthen cost control. Yet one question receives far less attention:

Is the underlying data architecture capable of supporting better decisions?

Many legacy health insurance systems were built to process transactions, with far less emphasis on supporting decision-making. Claims, policies, benefits, diagnoses, providers, and payments are captured across separate systems, each designed for a specific operational function.

The challenge is that better decisions are only made from connected data, while many legacy systems store and process data in isolation.

A claim, on its own, says very little. Its value comes from its relationship to the member's policy, benefit design, diagnosis, provider history, product configuration, and payment journey. When those relationships cannot be established reliably, insurers lose the context required to make timely and informed decisions.

This is one reason many automation and AI initiatives struggle to deliver their expected impact. The underlying data was never structured around the decisions insurers need to make. It was structured around the transaction's insurers needed to process.

Before asking, "How do we automate more decisions?", insurers may need to ask a more fundamental question:

"Is our data structured around the decisions we need to make, or around the transactions we have always processed?"

‍

What it looks like when the data architecture is built for decisions

When data relationships are embedded at the point of capture, a claim is linked immediately to the active policy, the specific benefit being used, the provider contract, and the diagnosis behind the visit. These connections are part of the system's design, not something left to later reconciliation or data warehousing work.

This changes what automation can act on. An adjudication engine that already knows a claim belongs to a particular policy, under a defined benefit, with a contracted provider can apply rules with zero errors. It can automatically verify limits, flag mismatches, and approve or escalate complex cases for manual review. Where those links are missing, even basic rules depend on manual verification, and any model is forced to infer relationships that should have been explicit.

This is a different starting point from adding an AI model or a claims API on top of an existing system. No algorithm, however sophisticated, can infer relationships that were never captured at the point of capture. If the connection between a claim, its policy, and its provider contract doesn't exist in the data, no amount of intelligence layered on top can manufacture it after the fact. The fix has to happen in the architecture, not in the tooling placed on top of it.

What we have seen from building this way

At M-TIBA, working with health insurers across the region, we made relational data architecture a foundational choice. Every transaction connects back to the policy, product, and provider it belongs to from the moment of capture.

The operational shifts that followed were significant. Claims processing throughput per assessor increased by more than 500 percent*.  The time from treatment to claim vetting fell to under a minute for automated claims. Insurers using this data foundation saw loss ratios improve by approximately 10 percentage points, driven not by stricter rules but by the ability to see cost drivers and leakage in real time*. Fraud detection shifted from retrospective sampling to real-time anomaly recognition, because the relationships within the data were consistent enough to trust.

The implication

Automation relies on the quality of the data relationships it can access. When those relationships are built into the system from the start, faster and more accurate decisions follow. When they are missing, even the most sophisticated AI model or claims tool operates on incomplete context — and no amount of intelligence bolted on afterward can substitute for it. Automation is not a feature insurers buy on top of their existing systems; it's an outcome of the architecture underneath them. The question worth asking isn't which AI tool to add next, but whether the foundation beneath it can support the decision at all.

See what a decision-ready platform looks like

If your claims, policy, and provider data already lived in one connected system, what would you automate first? Explore how M-TIBA's platform is built for insurers, brokers, and TPAs.

[See the platform → Here ]

Foot note:

*aggregate data across M-TIBA insurer partners, 2024–2026

‍