By Anke Merkx, Product Manager, M-TIBA

Most health insurance technology projects begin the same way: with a list of requirements. A new workflow. A new dashboard. A new module to tick a box on paper. It feels rigorous, but it quietly assumes the hardest part — understanding the problem — is already done.

We start somewhere else. Before we build anything, we ask insurers a different question: can you walk us through your work? Not what you think you need, but the actual flow — every step, every hand-off, every point where someone has to stop and decide something.

That conversation surfaces what a requirements list never does: where the process slows down, where people are doing manual work the system should handle, where errors are introduced, and where decisions get stuck waiting for information. Only then do we look at what to build. Understanding the work comes before designing the solution.

Why we build the whole flow, not just the parts

This principle shows up in what we've deliberately chosen to build ourselves. Product setup and quotation is a good example. Many platforms lean on an external tool for it. We built it inside the platform, because pricing a health product well depends on what actually happens downstream — utilisation, claims behaviour, cost drivers.

When product and quotation live inside the end-to-end flow, the data from the whole journey feeds back into how products are priced and configured. That's one connected feedback loop rather than a series of disconnected systems that have to be reconciled after the fact. The platform is split into modules and domains so each part of the insurance journey gets the right features, but the teams behind them work as one system — so the right data moves cleanly from one step to the next.

The assumption we disagree with

There's a belief running through a lot of health insurance tech decisions: that more data is always better. We don't think that's true.

Data is valuable, but only in proportion to whether you can use it. A large volume of data that can't be connected to a decision doesn't improve outcomes — it adds noise and cost. What matters is timing and context: when the data arrives, and whether the person or the system making a decision can actually act on it at that moment.

This reframes what "using data" even means. It isn't a report someone reads later. It's a signal that changes what happens to a specific claim, a specific member, a specific provider, while there's still time to act.

What we've seen from building this way

Designing around workflows and decisions rather than requirements has produced consistent operational shifts across the insurers we work with. The time from treatment to claim vetting fell to under a minute for automated claims. Insurers on this foundation have seen loss ratios improve by roughly 10 percentage points — driven not by stricter rules, but by the ability to see cost drivers and leakage in real time.*

None of that comes from a single clever feature. It comes from the order of operations: understanding the flow first, then building around the decisions inside it.

The question worth asking

If you're evaluating a tech partner, the most useful thing you can do is look inside your own flow first. Where are the moments that actually matter — claims adjudication, payment reconciliation, cost control? What decision has to be made at each one, and what data would support it? Then ask a simple question of any partner:

Can you put the right data in front of that decision, at the moment it's made?

If the answer is unclear, you're likely looking at a system that processes data rather than one that supports decisions. The difference between the two is where a health book is sustainably run and profitable.

See what a decision-ready platform looks like. Explore how M-TIBA is built for insurers, brokers, and TPAs.

[See the platform → Here ]

‍