Build vs Buy: Healthcare Information Systems

Healthcare IT leaders recognize that the build-vs-buy decision is rarely all-or-nothing. Instead, most large health systems adopt a hybrid approach: they purchase vendor platforms for core functions and reserve custom development for truly unique needs. As one industry analysis notes, "few healthcare organizations have the resources to develop [systems] entirely without external expertise," so a modular strategy is necessary. In practice, even an innovator like Penn Medicine found that roughly 90% of its technology stack was vendor-supplied, underscoring that off-the-shelf solutions handle the majority of needs. The key is intentional strategy – each major system (EHR, billing, analytics, etc.) should have a documented build-vs-buy decision based on its own criteria, rather than defaulting to one model.

Custom development offers complete control over workflows and data, but at a high price. Building in-house means funding not only initial engineering but ongoing maintenance, security updates, and regulatory compliance. Healthcare analysts warn that compliance and security costs are often "the most consistently underestimated" budget items in healthtech projects. In one ROI illustration, a 500-bed hospital's five-year cost for a purchased EHR was $26M vs $19M for a custom build – highlighting that integration and long-term support can dominate total cost of ownership. In short, focusing on upfront license or development cost alone is misleading; leaders must project the full multi-year TCO and associated risks for each option.

Strategic Decision Factors

When evaluating build vs buy, executives should consider factors beyond price:

• Market maturity: Core administrative and billing functions have mature commercial solutions. If multiple established vendors exist (e.g. Epic, Cerner, Athenahealth for EHR/RCM), buying is usually more cost-effective.
• Internal capability: Custom development requires a large, specialized IT team (software engineers, informatics experts, UI/UX designers, DevOps, and compliance officers) for design and ongoing support. If those resources are limited or already overloaded, buying vendor software is safer.
• Strategic differentiation: Only build when the feature is central to your competitive or clinical edge (for example, proprietary care pathways or unique payer-provider integrations). In one case, an academic center built a bespoke transplant workflow tool that delivered a 150% ROI in year one, because commercial products couldn't capture their complex protocol.
• Regulatory and security requirements: Solutions involving intensive compliance (HIPAA, FDA-regulated functions, etc.) often favor proven vendors who already address those burdens. Developing a compliant system in-house can double the work – one analysis shows proactive HIPAA architecture alone can add on the order of $60K–$180K to a project – so reuse of certified software may reduce risk and effort.

Total Cost and Hidden Risks

Even off-the-shelf systems carry hidden costs, but custom builds tend to amplify them. Key risks include:

• Integration expenses: New software must interface with existing EHRs, lab systems, devices, etc. Interface development (HL7, FHIR, custom APIs) is expensive – for example, one hospital spent $2.4M connecting a $600K patient app to its systems. These costs often exceed initial estimates.
• Ongoing maintenance: Vendors include security patches and updates as part of licensing, but custom code shifts that burden to your team or contracts. Annual budgets must cover penetration testing, risk assessments, and patching. As noted, compliance/security costs are frequently under-budgeted.
• Lock-in and upgrade risk: Buying ties you to a vendor's roadmap, while building ties you to your legacy code. Both can incur major switching costs. For example, one health system delayed replacing an underperforming EHR for eight years because the projected $18M migration cost outweighed short-term benefits.

Governance and Hybrid Architecture

In most cases, executives conclude that a hybrid architecture is optimal: use established commercial platforms for standard functions and interconnect them with custom modules only where needed. Milliman MedInsight advisors capture this by noting that "no single system—whether developed internally or acquired—can fulfill all data management needs indefinitely". In practice, health systems often implement a flexible integration layer (e.g. FHIR or an API gateway) that lets in-house tools sit alongside purchased systems. Crucially, a formal governance process should underpin each decision: steering committees or IT councils should document the rationale, ROI assumptions, and risk profile for each build-vs-buy choice. This transparency ensures that future leaders understand why a certain path was taken and can update decisions as strategy and technology evolve.