I've watched health tech organisations build the same way for a decade: start with a feature, bolt on another feature, integrate a third, and then wonder why the whole thing feels fragile. The ones that succeed take a different approach. They build the foundation first and let features grow from it.
What You Need to Know
- Health data platforms built feature-first accumulate technical debt that eventually blocks clinical adoption and regulatory compliance
- A foundation-first approach, data architecture, interoperability standards, governance frameworks, makes every subsequent feature cheaper and faster to build
- The health sector's unique constraints (privacy, clinical safety, regulatory compliance) make foundational architecture more important than in other industries
- Organisations that invest 3-6 months in foundation work before feature development report faster delivery timelines over 24 months
The Feature Trap
Every health tech platform I've been involved with, including Edison, started with pressure to ship features. Investors want visible progress. Clinicians want specific capabilities. Sales teams want demo-ready functionality. The pull toward "build the next feature" is relentless.
And it works, for a while. You can build impressive functionality on a thin foundation. Genomic variant classification? Done. Patient dashboard? Done. Lab integration? Done.
Then you hit the wall.
The wall looks different in every organisation, but the cause is always the same. You need two features to share data, and they can't because they were built as isolated modules. You need to comply with a new privacy regulation, and there's no centralised consent management because it was never part of the foundation. You need to integrate with a hospital system, and your data model doesn't map to HL7 FHIR because you built a custom schema to move fast.
68%
of health IT projects that fail cite integration and interoperability issues as a primary factor
Source: HIMSS Analytics, 2023
The feature trap is seductive because the short-term ROI is visible. The long-term cost is invisible until it isn't.
What a Health Data Foundation Looks Like
A foundation isn't a product. It's the architecture that products are built on. In health data, that means four things.
A data model that speaks the language of health. Not a custom schema designed to solve today's problem. A model built on health data standards, FHIR, SNOMED, LOINC, that can accommodate tomorrow's requirements without a rewrite. This feels slower at the start. It's dramatically faster over 24 months.
Interoperability as a first-class concern. Health data doesn't live in one place. It lives in GP systems, lab systems, hospital systems, pharmacy systems, and increasingly in patient-held devices. A platform that can't exchange data with these systems in standard formats isn't a platform. It's a silo.
Consent and privacy architecture. Health data has the strictest privacy requirements of any sector. Consent management, data sovereignty, audit trails, these can't be retrofitted. They need to be in the foundation. I've seen organisations spend more time retrofitting privacy controls than it would have taken to build them properly from the start.
Clinical safety frameworks. If your platform influences clinical decisions, it needs safety guardrails from day one. Version control for clinical content. Audit trails for every classification. Clear boundaries between AI-assisted and AI-determined outputs. These aren't features. They're foundations.
The pattern is the same across every sector we work in. Organisations that build foundations first feel slower for the first three months and faster for the next three years. In health, where the stakes include patient safety, the foundation isn't optional.
Isaac Rolfe
Managing Director
The Edison Lesson
When we built Edison, we made both mistakes. We built some capabilities foundation-first and others feature-first, because the pressure to demonstrate value was real.
The foundation-first components, our genomic data model, our consent architecture, became the stable core that everything else plugged into. When we needed to add new genomic panels or integrate with new lab systems, the foundation handled it.
The feature-first components were the ones that caused pain. Every new requirement meant reworking connections between modules that should have been designed to work together from the start. The time we "saved" by skipping foundation work was spent three times over in integration and rework.
The AI Multiplier
This is especially relevant now that AI is part of the health tech stack. AI models are hungry for clean, well-structured data. An AI layer built on a strong data foundation can do remarkable things: predict patient risk, optimise treatment pathways, identify patterns across populations.
An AI layer built on fragmented, inconsistently structured data produces unreliable outputs that clinicians, rightly, refuse to trust.
73%
of data scientists report spending most of their time on data preparation and cleaning rather than building models
Source: Anaconda State of Data Science Report, 2022
I've seen health organisations invest heavily in AI capabilities while their underlying data architecture is held together with spreadsheets and manual processes. The AI doesn't fix the foundation problem. It amplifies it. Bad data in, confidently wrong outputs out.
A Practical Approach
If you're building or rebuilding a health data platform, here's the sequence that works.
Months 1-3: Foundation. Data model (FHIR-aligned), consent architecture, interoperability layer, clinical safety framework. No user-facing features. This is the hardest phase politically because there's nothing to demo.
Months 3-6: First clinical feature on the foundation. Pick the highest-value clinical workflow and build it properly on the foundation. This validates the architecture and gives you something to show.
Months 6+: Accelerate. With the foundation in place, new features build faster because they share data, consent, and safety infrastructure. Each new capability is additive rather than independent.
The organisations that get the first phase right, even when the board is asking "where's the product?", are the ones that build health tech that lasts. The ones that skip it build health tech that ships fast and stalls faster.
- How long does it take to build a health data foundation?
- Typically 3-6 months for core architecture: data model, interoperability layer, consent management, and clinical safety framework. The investment pays back within 12 months through faster feature delivery and fewer integration problems.
- Can you build a foundation incrementally alongside features?
- Partially, but the core data model and consent architecture need to be in place before you build features on top of them. Retrofitting these is significantly more expensive than building them first. Other foundation elements, like expanded interoperability, can evolve alongside feature development.
- What's the biggest risk of skipping foundation work?
- In health tech specifically, the biggest risk is a compliance or safety failure that forces a rebuild. We've seen organisations spend 18 months rebuilding platforms that took 12 months to build originally, because the foundation couldn't support regulatory requirements that should have been anticipated.