For the pipeline layer underneath every clinical dashboard
Healthcare Data & Analytics
A hospital's data usually exists in more systems than anyone can name from memory, and most of them disagree quietly. This practice builds the interoperability and pipeline layer that reconciles those systems, governs population-health analytics, and de-identifies data for research without leaving the underlying patients exposed.
Reconciling hospital systems that were never built to agree
How an interoperability layer handles conflicting records instead of hiding the conflict.
90 secSample frame · video pending01Before choosing an interface pattern
HL7 v2 or FHIR is a real decision, not a preference.
Most hospitals run both, and defaulting to whichever an engineer prefers ignores what the source systems actually support. Four questions settle the pattern for a given integration.
What does the source system actually expose?
Legacy systems often only speak HL7 v2 messages. Forcing a FHIR-first approach onto a system that cannot emit it just adds a translation layer.
Does the consumer need a query API or a message feed?
FHIR suits systems that need to query a specific resource on demand. HL7 v2 suits systems built around a stream of discrete events.
How many systems need to agree on one record?
More source systems mean more reconciliation logic regardless of protocol, which is often the larger cost than the interface pattern itself.
What does your existing interface engine already support?
An interface engine already handling HL7 v2 traffic reliably does not need replacing just to standardise on a newer protocol.
| HL7 v2 interfaces | FHIR APIs | |
|---|---|---|
| Integration pattern | Message-based, event-driven | Resource-based, query-driven |
| Common source | Legacy hospital systems | Modern EHR and app platforms |
| Tooling maturity | Long-established interface engines | Growing, increasingly standard |
| Best fit | Existing legacy estates | New builds and modern consumers |
02Agreed before a pipeline is built
The ledger that keeps interoperability honest
Data engagements go wrong when ownership of a reconciled record is assumed rather than agreed. This ledger fixes what source systems you bring, what pipeline gets built, what you can query afterward, and what governance never leaves your control.
- Your side
You bring
- Every source system and the format it exports today
- Known gaps where two systems already disagree
- The clinical or operational question the unified data needs to answer
- Our side
We build
- HL7 and FHIR interfaces connecting the source systems
- A pipeline that reconciles conflicting records rather than hiding the conflict
- Monitoring for the interface breaking silently when a vendor updates
- Your side
You receive
- A working interoperability layer across the named systems
- Documented mapping showing where each field actually comes from
- Alerts when an interface stops receiving expected data
Never leaves you
- Ownership of every source system and its data
- The decision on which systems get connected next
- Governance over who can query the unified data
Where the line sitsInteroperability does not mean one system wins. Each source keeps its own record; the pipeline reconciles them without quietly deciding whose version is true.
03From source system to trusted query
Four stages, each closing on evidence
Pipelines that silently break usually skipped one of these stages. This system closes each one with something a data owner could actually verify.
Map every source and its format
Every source system, its export format and its known quirks are documented before an interface is built, so surprises surface early, not in production.
A map before a pipelineBuild the interoperability layer
HL7 and FHIR interfaces are built with reconciliation logic that is documented and reviewable, not buried inside an opaque transformation step.
Reconciliation logic that is visibleApply governance and de-identification
Where data leaves the operational system, a documented de-identification or access-control process is applied before it reaches an analyst or researcher.
De-identification where the use case demands itShip with monitoring on every interface
Interfaces are monitored for silent failure, so a vendor update that breaks a feed is caught by an alert rather than a missing report.
Monitoring for silent interface failure
04What actually moves the number
Four drivers, priced from the assessment
Healthcare data work is priced against the assessment, because these four factors change scope by multiples.
Number of source systems to reconcile
Two systems that mostly agree cost far less to connect than five systems with years of independent drift between them.
Legacy protocol support required
Supporting an ageing HL7 v2 estate alongside modern FHIR consumers costs more than standardising on one protocol from the start.
De-identification and research-governance depth
A dataset destined for external researchers needs deeper de-identification review than one staying inside the hospital's own analytics team.
Freshness the analytics actually needs
Near real-time population-health dashboards cost more to build and operate than a pipeline refreshed on a nightly batch.
05Evidence and proof
Pipelines a data owner could actually trace.
Healthcare data proof is a reconciled record with a traceable source and an interface that alerts before a report goes missing. Every record here waits for written client approval before production.
Explore case studiesFour disagreeing systems reconciled into one queryable population record.
Koru Health's clinical data sat across four systems that quietly disagreed on shared patients. An interoperability layer reconciled the records and made population-level queries possible for the first time.
- Source systems reconciled
- 4
- Silent interface failures caught
- Monitored continuously
A legacy industrial data estate rebuilt into a governed, queryable pipeline.
Nexa Foundry's plant data sat in ageing, disconnected systems similar in shape to a legacy hospital estate. The same reconciliation and monitoring pattern applies directly to fragmented clinical data.
- Legacy systems brought into the pipeline
- Multiple
- Manual reconciliation hours removed
- Measured post-launch
We finally trusted a population-level number because we could trace exactly where every record inside it came from.
Sample · pending client approval
06Read this first
When new pipeline work is the wrong answer
Building a bespoke interoperability layer for two systems that already export a shared format is over-engineering. The exits are marked plainly. When the work is justified, it runs on standard HL7 and FHIR tooling with governed cloud infrastructure.
The systems already export a compatible format
If two systems already agree on a shared export, a lighter integration serves better than a full interoperability build.
- Data practice
The reporting need is a one-off, not recurring
A single ad hoc report rarely justifies a governed pipeline. A spreadsheet extract may genuinely be the right tool once.
- Team extension
You need data engineers, not a delivery team
If your team already owns the data architecture and needs capacity, team extension fits better than a commissioned build.
| Shape | Best when | You direct | We carry |
|---|---|---|---|
| Scoped build | The source systems and question are known | Governance and access decisions | Pipeline design and delivery |
| Delivery pod | The analytics need will keep expanding | Product and clinical priorities each cycle | Engineering and monitoring |
| Team extension | Your leads own the data strategy | Architecture and governance standards | Named engineers and continuity |
07Straight answers
Asked before a data pipeline budget is approved.
01Do you work with HL7 v2, FHIR, or both?
Both, chosen against what your source systems actually support rather than a default. Most hospitals run a mix, and the interface pattern follows the system, not a preference.
02How is this different from the AI for Healthcare practice?
This practice builds the pipeline and interoperability layer underneath prediction. The AI practice builds the models that sit on top of data this layer has already made reliable.
03Can you connect systems from different vendors that were never designed to talk?
Yes, that is the common starting point. An interoperability layer reconciles conflicting records between vendors rather than requiring either system to change.
04How do you de-identify data for research use?
Through a documented method scoped to the specific research use, with residual re-identification risk assessed and written down. The process is repeatable for future extracts.
05Will population-health dashboards work with our existing reporting?
Dashboards are built around the outcomes your clinical leadership already tracks. They typically extend or replace existing reporting rather than sitting alongside it as a duplicate system.
06How long does an interoperability project take?
It depends on how many source systems need reconciling and how much they already disagree. Two compatible systems connect faster than five with years of independent drift.
07What does healthcare data engineering cost?
Cost is priced from the number of source systems, legacy protocol support and de-identification depth required. These three factors alone can change scope by several multiples.
08Do you monitor pipelines after launch or just build them?
Monitoring for silent interface failure is part of delivery, since a vendor update can break a feed without an obvious error. Alerts catch that before a report quietly goes missing.