Across production projects including mySugr/Roche (1M+ users, 52 countries) and 9amHealth, healthcare system integration breaks in predictable ways. Teams build the technically interesting layer first and discover months later that insurance billing or pharmacy connectivity was the actual revenue gate. Compliance requirements treated as late-stage tasks become re-architecture problems. AI pipelines create PHI exposure nobody modeled. These patterns are avoidable when integration is treated as a design constraint from the start.
In 2021, 9amHealth came to us with no codebase, a distributed team across Poland, Austria, and the US, and a hard deadline. Before a single line of code was written for the clinical platform, we spent time understanding their business model. That conversation determined the order in which we built everything that followed.
Healthcare system integration doesn’t fail in production because teams can’t implement FHIR. It fails because teams implement FHIR before they’ve figured out which integration is actually blocking revenue. Here’s what five projects taught us.
The first integration a platform needs is usually the one nobody planned for
The assumption going into 9amHealth was that the clinical data layer would be the technical centerpiece: FHIR resources, patient records, clinician input. Those were the interesting problems.
The integration that needed to work before anything else was the e-prescription flow and pharmacy connectivity. Then insurer connections. The platform’s ability to generate revenue depended on those integrations being production-ready before the clinical layer mattered to anyone.
This sequence shows up across projects. Teams architect the interoperability layer, then discover that a pharmacy API with incomplete documentation or an insurer integration on a proprietary protocol sits between them and their first paying user. When we scope integration work now, the first question is: what does the business model require to process a transaction? Those integrations come first.
Moving a production database without taking the system offline
The mySugr migration shows what healthcare system integration looks like under pressure.
mySugr had 1 million active users across 52 countries on a MySQL database. AWS Aurora 3 forced a migration to PostgreSQL. There was no downtime window. Taking the system offline would have affected patients managing diabetes across more than 50 countries.
The migration took 9 months from concept to production. We ran change data capture (CDC) to keep both databases synchronized during the transition, ran old and new systems in parallel for 2 months before switching traffic, and brought maintenance costs down 50% after the cutover. Zero downtime throughout.
The lesson generalizes beyond databases. Live healthcare systems have no clean state. Any integration that assumes a pause long enough to do the work cleanly is assuming conditions that don’t exist in production. Budget for CDC. Budget for parallel operation. Budget for the fact that users generate new records throughout the entire process.
Compliance requirements missed in the architecture show up as integration problems in certification
When we joined the Selfapy project, their only mobile developer had left weeks before a BSI security certification deadline. Selfapy is a cognitive behavioral therapy app for patients with depression and anxiety disorders.
The immediate problem was the timeline. The underlying problem was that BSI compliance hadn’t been designed into the data architecture from the start. Access control, audit trails, and encryption decisions that should have shaped the data model were sitting outside it. We delivered 3 versions on schedule and cleared 120+ BSI requirements, but retrofitting those constraints cost more than building them in would have.
The Mentalyc project made the same point from a different angle. Mentalyc automates therapy session notes using AI. They had developers and no QA framework. Building the full framework from scratch – Playwright, Cucumber BDD, Docker, GitHub Actions — cut test time from several hours to 24 minutes. More relevant to integration: the testing revealed gaps in the data pipeline the team hadn’t seen while shipping features.
When AI processes therapy session content, every system in the pipeline touches PHI: the prompt, the inference log, the observability stack, any caching layer that retains the request. HIPAA doesn’t distinguish between intentional and accidental exposure. If those systems aren’t modeled as compliance constraints from the beginning, an audit is the only other moment they surface.
What „legacy system” actually means on the ground
Every project has a legacy system somewhere in the stack. Across the five we’re describing, the pattern is consistent: the system works, the API is partially documented, the vendor responds in 3 business days, and there’s at least one field in the response payload that nobody mentioned during scoping but drives a core workflow.
Teams that know this going in budget a discovery sprint before committing to integration timelines. Teams that treat „integrate with the existing API” as a fixed-scope task run the same calendar time, just without the buffer.
In healthcare, undocumented behavior in a legacy system usually means undocumented behavior around patient data. Finding it late is a timeline problem and a compliance problem simultaneously.
What the first 6 months actually cost
A first integration against a new system, one partner, one set of requirements, one compliance scope, takes 3 to 6 months from sandbox access to production. Multi-system coverage runs 12 to 24 months depending on how many integrations are required and whether vendor programme timelines are involved.
The cost drivers that consistently get underestimated: parallel operation during migrations, compliance documentation, and per-site variability. Two insurers or two hospital systems on the same platform expose different configurations, different edge cases, different data quirks. That variability doesn’t appear in the estimate for the first site.
What we’d do differently on every project
Scope integration as a design constraint before the architecture is decided. Identify which integration gates revenue and build that one first. Model compliance as a data flow constraint, not a certification checklist. Assume every live system has undocumented behavior and allocate time to find it before committing to a timeline.
Every project that deferred integration to phase two encountered it as a phase-one problem anyway, with less time to solve it. An architecture built around a known constraint is faster to ship than one rebuilt around a constraint discovered in production.
If you’re building a digital health product and want to work through where your integration risks actually sit, we’re available for that conversation.
