Your IT team knows the data pipeline is broken. The question is whether to pull someone off BAU work to fix it or bring in outside expertise. Here is how to think about that decision.
Karan Bhosale
Founder, Kinesiis
Every hospital IT leader we talk to has already identified the problem. EHR data is siloed. Reporting is manual. Finance and clinical operations are working from different numbers. The pipeline is broken and everyone knows it. The question that stalls most projects is not whether to fix it, but who should do the work. Should you hire or redeploy someone internally, or bring in a specialist team? Both paths have real trade-offs, and the right answer depends on your team's current capacity, the timeline, and what you want to own at the end.
Key takeaways
The strongest argument for building in-house is that your team understands your systems, your data, and your organisation's workflow better than any outside team ever will. They know which HL7 feeds are reliable, which departments produce clean data, and which workarounds have been in place for years.
An in-house build also means your team develops deep expertise in the infrastructure they will be maintaining. There is no handover risk. There is no knowledge gap when the consultants leave. The people who built it are the people who run it.
The case is strongest when you have engineers with data infrastructure experience available and when the timeline is flexible enough to accommodate the learning curve on EHR-specific integration patterns.
Hospital IT teams typically have two to five engineers supporting existing infrastructure, application maintenance, security compliance, and user support. Pulling an engineer off that work to build a data pipeline means something else stops getting done.
The timeline risk is more significant than most teams estimate upfront. EHR integration has edge cases that only appear in production: FHIR API rate limits that behave differently under real load, PHI handling in error paths, schema drift when the EHR vendor pushes an update, OAuth token expiry during long-running backfills. Each of these adds weeks if you are encountering them for the first time.
We have seen in-house projects scoped at three months take nine months to reach production because the team underestimated the gap between a working prototype and a production pipeline. The prototype works in week three. The production hardening takes the remaining six months.
A specialist team that has built healthcare data pipelines before will ship faster, not because they are better engineers, but because they have already encountered the failure modes your team will discover one by one.
They know that Epic's FHIR pagination tokens change format between sandbox and production. They know that HL7v2 feeds from LabTech systems need schema drift detection. They know that BigQuery column-level security is the cleanest way to implement PHI access controls. These are not insights that come from reading documentation. They come from having solved the same category of problem multiple times.
The timeline difference is substantial. A well-scoped EHR data integration project with a specialist team typically takes 10 to 16 weeks. The same scope in-house, with a team encountering these patterns for the first time, typically takes 6 to 12 months.
The legitimate concern with hiring outside expertise is dependency. If the specialist team builds the system and then leaves, and your team cannot operate or extend it, you have traded one problem for another.
This is a real risk with many consulting models, particularly those designed around managed services or ongoing retainers. If the consultancy's business model depends on you continuing to pay them, the incentive to build for handover is weak.
The test is simple: at the end of the engagement, does your team own the code, the infrastructure, and the operational knowledge? Or are you calling the consultancy every time something needs to change? A build-and-handover model with documented runbooks, Terraform-managed infrastructure, and a post-launch support window eliminates this risk.
For teams with two to five engineers who cannot afford to pause BAU work for six months, the most practical approach is hybrid: a specialist team builds the data infrastructure foundation, then hands it over to the in-house team to operate and extend.
The specialist team handles the high-risk, high-expertise phases: EHR API integration, pipeline architecture, HIPAA compliance controls, and production hardening. Your team participates throughout, building context and operational knowledge. At handover, your team has a working system, runbooks, and 90 days of support to build confidence.
After the support period, your team extends the system as needs evolve: adding new data sources, building new reporting views, adjusting alert thresholds. They own it fully. The specialist accelerated the foundation. Your team takes it from there.
In summary
The in-house vs specialist decision is ultimately about where your team's time creates the most value. If your engineers have data infrastructure experience and the timeline is flexible, building in-house develops deep institutional knowledge. If the timeline is driven by an upcoming audit, a leadership mandate, or an operational bottleneck that is costing the organisation measurable money every week, a specialist team gets you to production faster. The build-and-handover model gives you the speed of outside expertise without the dependency. At the end, your team runs it.
Talk to us. We will scope an engagement before any work begins.