The Illusion of Digitisation

A couple of weeks ago, I had an interesting conversation with an EHR founder. Their product is live, with paying customers and active deployments.

But they admitted something uncomfortable: they don’t believe their database is usable for AI workflows. In their words, the data isn’t clean enough. The structure isn’t reliable enough. Building intelligence on top of it would mean months of painful cleanup (if it’s even possible).

Their proposed solution? Rewrite the system on an openEHR base so the underlying PostgreSQL structure becomes more AI-friendly (I’m still not sure how I feel about that approach).

But the conversation surfaced something much bigger than openEHR vs non-openEHR. It revealed a gap that most hospital owners don’t see coming.

The Intelligence Readiness Gap

Many EHRs are built to digitize paper. Very few are built to power intelligence. That difference matters. A system can generate bills, print prescriptions, store notes and track admissions, but still be structurally unfit for analytics. That system is not necessarily a strategic asset: it may simply be paper… in a computer. Documentation is not intelligence.

Why?

Because documentation and computability are not the same thing.

If diagnoses are mostly free text…
If lab results are stored as PDFs…
If data fields are inconsistently used…
If there’s no enforced coding structure…
If longitudinal queries are hard or impossible…

Then what you have is a documentation layer — not a data engine. And AI does not thrive on documentation. It thrives on structure.

Put another way: if your system cannot answer those questions without exporting spreadsheets and manually cleaning data for weeks, you don’t have operational intelligence. You have a record-keeping tool. And record-keeping tools do not grow topline.

This isn’t just an Africa problem

Anyone who follows healthcare AI founders globally has seen this pattern. Teams trying to build AI tools on top of existing EHRs often spend months just cleaning chaotic data before they can even begin model development.

That’s not because AI is immature or because the team lacks talent. It’s because the underlying systems were never built for computability in the first place.

The EHR did its original job: it digitized workflows. But it was never designed as an intelligence substrate.

Why Would an EHR Company Do This?

Three honest reasons.

Speed beats structure.

Early-stage companies optimize for survival. Go live fast. Close contracts. Adapt to client requests. Deep schema design slows you down.

Hospitals rarely demand structured data.

During procurement, hospital owners ask:

Can I bill from it?
Can I generate reports?
Is it affordable?
Will my staff adopt it?

They almost never ask:

Are diagnoses coded?
Can I run cohort-level queries?
Is this system intelligence-ready?

Vendors respond to buyer incentives.

Analytics wasn’t the original product.

Most African EHRs began as digitization tools, not operational intelligence systems. That origin story shapes architecture decisions in ways that are hard to reverse later.

Why This Should Worry Hospital Owners

Because the next phase of hospital competitiveness won’t be about “having software.” It will be about visibility. Visibility into:

Which hypertensive patients haven’t returned in 6 months
Which antenatal patients are at risk of dropping off
Which families haven’t re-engaged
Which service lines are quietly underperforming
Where revenue leakage is occurring

If your EHR cannot answer structured questions about your own patient base without heroic manual effort, you are not intelligence-ready. And that becomes a strategic liability, especially if you’re locked into a multi-year contract.

The Contracting Phase Blind Spot

Most small and mid-sized hospitals in Nigeria do not have a CIO. They do not have internal data architects, nor do they evaluate schema design during procurement. So how would they even know?

A few simple questions expose the difference immediately:

Are diagnoses stored as structured codes or free text?
Are lab results stored as discrete values or uploaded documents?
Can I query “all diabetic patients with no visit in 6 months” in real time?
Do you provide structured API access?
Can you demonstrate cohort-level analytics from a live deployment?

If a vendor cannot show cohort queries on live data, that’s a signal. Because intelligence cannot be bolted on easily later.

This Is Not About openEHR

Standards matter. Architecture matters. But this isn’t primarily about whether a system uses openEHR. You can build a chaotic implementation on openEHR. You can build a disciplined, intelligence-ready system without it.

The real question is simpler: Was this EHR designed as a documentation tool — or as a computable clinical data engine? That design philosophy determines whether AI becomes a layer you can activate… or a rebuild you must fund.

The Bigger Strategic Question

In the coming decade, hospitals won’t compete on who has the most features. They will compete on who can see patterns inside their own data.

Revenue visibility.
Recall systems.
Preventive enrollment.
Leakage detection.
Service line optimisation.

All of that requires structured, queryable, longitudinal data. If your system cannot support that, you don’t just have a tech limitation: you have a strategic ceiling.

And ceilings are expensive to break through later.