Unified Care Platform for 3M+ Patients
Our team built one patient record across a national hospital network of more than 3 million patients, with telehealth and analytics running on that same record.
Overview
Hospital networks that grow by acquisition often end up with a different set of systems in every hospital. Registration, labs, radiology, and billing each keep their own copy of a patient’s details. Without a shared identifier, no single system can say which records belong to the same person.
One of our clients, a national hospital network with more than 3 million patients, was in exactly this position. Registration, the labs, radiology, billing, and a telehealth product each held part of a patient’s history, and none of them agreed on who that patient was. Clinicians closed the gap themselves, with four systems open at once or a phone call to the hospital that had seen the patient last.
Let’s see how our team built the layer that brings those systems together into one record per patient, while leaving the hospitals’ existing EHRs where they were.
Challenges
The network had grown by acquisition, and its systems had arrived with it. Nobody had chosen this architecture. Here’s the list of problems the network faced:
- Different EHRs in every hospital: each hospital still ran the EHR it had before it joined, with different vendors, different versions, and different meanings for a routine field like admission date.
- No shared patient identifier: the same patient was held as separate records in registration, the lab, and radiology. There was no way to tell a genuine duplicate from two people who share a name and a birth date.
- A separate telehealth product: telehealth had been added in a hurry, with its own login and its own record, so a video consultation left no trace in the patient’s chart.
- Yesterday’s analytics: analytics ran off overnight extracts, so every dashboard in the network described yesterday.
- Scattered access logs: HIPAA access logs were kept per system, so answering who opened this patient’s record meant collating six logs and hoping none had been missed.
So, the network brought in our team to give every patient one dependable record.
Our Strategy
The obvious proposal was to replace all the EHRs with a single system, and we argued against it. A rip-and-replace across a national network is a multi-year risk for clinicians, and it fixes patient identity last, when identity is what everything else depends on.
We did the reverse. Every source system stayed where it was, and we built one layer above them that resolves identity, assembles a single record, and writes back only where a clinician expects it to. This kept the risk small. If our layer went down, each hospital would still run on the systems it used the day before. It also meant the first useful release arrived in months instead of years.
The layer was built AI-native. The team used Claude Code in the daily build loop for the repetitive, spec-driven code, while senior engineers handled anything that needed judgment.
Our Solution
Here’s how we built the platform and rolled it out.
-
01
Patient Identity First
We built the master patient index before anything else. It uses deterministic matching on the fields that are reliable and probabilistic scoring on the ones that are not. Ambiguous matches go to the network’s clinical data team for a human decision, rather than letting a confidence score quietly merge two people’s charts. Before the index touched a live record, we replayed it against historical data and had the network’s own data stewards grade the results.
-
02
The Integration Layer
The layer connects to each system using HL7v2 where the system supports it, FHIR where the vendor offers it, and a custom adapter where neither is available. The adapters were scaffolded with Claude Code from each vendor’s interface specification, then reviewed field by field by a senior engineer before merge. The first release was read-only, so it could show a clinician everything and change nothing, which is what got it through clinical governance. Kafka sits between the adapters and the record store, so a slow source system delays only its own data.
-
03
One Record, with Telehealth Inside It
The consolidated view is assembled for each patient when it is read, and every field shows the system it came from. Clinicians do not trust a record that will not say where a value originated. Telehealth moved from a separate product into the record, so a consultation now writes to the chart like any other encounter. We also added AI-assisted triage as decision support at intake. It ranks and suggests, a clinician decides, and both the suggestion and the decision are logged.
-
04
Analytics, Then the Rest of the Network
Analytics now runs on the same record the clinicians read, which retired the overnight extract. One queryable access log covers the whole estate, so the HIPAA question became a query instead of a collation exercise. We rolled the platform out hospital by hospital, with each site’s previous systems running alongside until its data stewards signed off.
Business Outcomes
- Created one record per patient across the network’s hospitals, with the source of every field visible on the record itself.
- Brought telehealth consultations into the patient’s chart, instead of a separate system beside it.
- Replaced six access logs with one queryable log across the estate, so who opened this record is now one question asked in one place.
- Moved dashboards onto the current record instead of an overnight extract, so the network no longer works from yesterday’s numbers.
- Shortened the time to ship new clinical capability by 60%. Most of that gain came from building against one integration layer instead of a new set of point-to-point interfaces for each hospital. That is why it held after our engagement ended.
- Delivered AI-native development with a paper trail, as every change Claude Code made traces back to the senior engineer who approved it.
- Kept 99.9% uptime through the rollout, with the source systems still running underneath as a fallback that was never needed.
Tech Stack
Conclusion
By resolving patient identity first and leaving the existing systems in place, our team gave the hospital network one dependable record for each of its more than 3 million patients. Clinicians no longer need to phone another hospital to find out what has already been done for a patient, and new clinical features are now built once, against one layer.
If your organization runs on systems that do not share a patient or customer identity, our team can help you bring them together without replacing what already works.