Every AI project in health is a data project wearing a costume. Most of them are being built on a data layer that was never designed to be believed.
Every AI project I've seen in health has been a data project wearing a costume. The costume is convincing. There's a vendor, a demo, a slide with a model on it, and a steering committee that has been told this is the year. Then someone asks the model a question that matters, and the answer depends on which of three teams' numbers it was trained on.
Here is the pattern. An institute or an agency asks for an AI strategy. You ask three questions. It turns out three teams pull the same data from the same system, apply their own rules, and get three answers. Nobody has decided which one is true, because nobody's job is to decide. AI on top of that doesn't fix it. It launders it. The three answers become one confident answer, and the confidence is the problem.
Raw data is not truth. Governed data products are.
A raw extract is a replica of a transactional system, complete with every quirk that system has accumulated over twenty years. It's what the clerk typed. It's not what happened. Truth is what you get after someone with the authority to do so has decided what an admission is, what an episode of care is, when a patient counts as discharged, and has written it down once, so that everyone downstream uses the same definition without having to ask.
The single most valuable thing an organisation can own is not its data lake. It's its agreed definitions, and the small set of governed data products built on them that everyone is allowed to believe. I've come to call that the truth layer. It sits between the source systems and everything that uses them, and it's the layer almost nobody funds, because it isn't a system and it isn't a model. It's a set of decisions.
Most organisations put governance in front of their data. There's a committee, you apply to it, and some months later you find out whether you can have what you asked for. That's governance as a gate, and it has two effects. It makes every request a negotiation from scratch. And it makes the people who hold the data the enemy of the people who need it, which is a strange thing to build into an organisation on purpose.
The alternative is governance inside the product. When a data product is built, decide then what's open by default (aggregated, de-identified, aged), what needs an approval (granular, recent), and what needs a specific authorisation (identified, linked). Write the tiers into the product. Then a request is approved once, against the product, and never renegotiated. This is also, not incidentally, the only way an AI use case becomes approvable at all. Nobody can sign off a model trained on data whose access rules were never written down.
Administrative health data is collected without consent. That's not a flaw to design around. It's the reason the stewards and custodians exist, and the reason they say no. Treat them as friction and you'll spend your career fighting them. Treat their tests as design inputs and the answer changes to yes, because you built the thing they were going to ask for before they asked.
Every few years someone proposes the central lake. All the data in one place, one team, one platform, and the problem goes away. It doesn't, for two reasons. The first is that the institutes and the health services will not hand over their data, and shouldn't have to; they're accountable for it under laws that don't stop applying because a platform got built. The second is that in Australia, privacy legislation differs by jurisdiction, so sharing identifiable data, or even the keys that link it, is a legal problem before it's a technical one.
The model that works is federation. Central control of the small set of systemwide products and the definitions behind them. Local autonomy for everything else: each institute keeps its raw data and builds its own products in its own workspace, on the condition that where its products overlap the shared ones, it uses the shared definitions. Autonomy for consistency is the trade, and it's a trade people will make, because it leaves them in charge of the thing they're accountable for.
Whenever a major source system is about to change, whether an electronic medical record, a trials platform or a registry migration, the organisation that already consumes governed data products barely notices. The definitions hold. The products get re-pointed. The reports keep working. The organisation still running on raw extracts rewrites every query it owns, and discovers in the process that nobody knew what half of them did.
So the order of work is not the intuitive one. Build the truth layer first, while the old system is still there to check it against. Then move the source. It feels slower. It's the only version that finishes.
A governance model is a document until someone wants to own it.
I've watched a good operating model die. Not because it was wrong; it had been reviewed, refined, endorsed in principle by everyone who read it. It died because the question it kept asking, who owns this, had no answer anyone wanted to give. Ownership of a data platform's governance is a person's name and a budget line. It is not a committee's. If nobody will put their name to it, the model is a document, however good, and the platform underneath it will be a technology project until it's a cautionary tale.
It's now the first question I ask, before I write a line. If there's no answer, I say so, and I suggest not building the platform yet. That's an unusual thing for someone who builds things to say. It's also the most useful sentence I have.
The organisations that will get real value from AI in the next three years are not the ones with the best pilots. They're the ones whose data layer someone is prepared to be believed on: defined once, governed inside the product, federated so the people accountable for it stay in control, and owned by a person with a name. Everything else is demos. Good demos, some of them. But demos.
Jahan · All insights · For research teams · For WA Government