Back to Blog
build-vs-buyhealthcare-dataactuarial-analyticsengineeringdata-infrastructurehealthcare-technology

A CTO's Guide to Build vs. Buy in Actuarial Analytics

TB

Thomas Bedington, Cofounder & CTO

July 30, 2025 • 6 min read

As a CTO in healthcare – in any industry really – you frequently face the question: "Can we just build this ourselves?" Quickly followed by: "Even if we can, should we build this ourselves?"

Your team is smart. You've built complex systems before. And frankly, spending large sums on a vendor when you could hire a few engineers raises questions.

But here's what we've learned after watching dozens of healthcare organizations go down this path: 80% isn't good enough in healthcare data, and getting from 80% to 95%+ will consume far more of your engineering roadmap than the business will tolerate.

The Seductive 80%

Healthcare data integration follows a predictable pattern. Within a few sprints you start to show results:

  • Claims data flowing in ✓
  • Basic aggregations working ✓
  • Cost per member calculations ✓
  • Leadership impressed ✓

After another month of work you're building some analytics on top of this data.

But a half year later you're still wrestling with edge cases. A new dataset observes different adjudication patterns the platform doesn't handle. A provider's system exports procedure codes differently after a software update. Medicare Advantage enrollment terminations don't match the spec. There's a new coverage code. Lab costs are inflated by 100x because of a decimal place issue that only affects one payer for a random three month period…

A year later you're still encountering new edge cases. You face a trade-off: engineer across all potential edge-cases or wait until they arrive and disrupt the business?

The problem isn't capability — it's that healthcare data is uniquely, systematically messy.

Why Healthcare Data Is Different

Compared to e-commerce transactions or user behavior data, healthcare claims represent the intersection of:

  • 50+ state regulatory environments
  • Hundreds of payer-specific adjudication rules
  • Thousands of provider billing systems
  • Decades of legacy code and manual processes

Each payer handles the "same" data differently:

  • One payer's DRG codes come through clean, another only sends them for 50% of its facility claims
  • Enrollment termination dates might be the last day of coverage, the first day you're not covered, or have to be inferred based on other context clues or fallback logic
  • Lab results could be $247.83 or $24,783.00 depending on how the source system handles decimals, and this might even vary within the same file if it's sourced from multiple systems

Your team will build solutions for each case as they discover them. But discovery is the killer—you only find these issues when they break your analysis, often months later during reconciliation, and sometimes with catastrophic, customer-facing financial or clinical consequences.

The Long Tail Problem

Here's what the build vs. buy math really looks like:

  • Months 1-6: 2-3 engineers, basic data pipeline working
  • Months 7-12: Same team, now handling payer-specific quirks
  • Months 13-18: Added a data engineer, still chasing edge cases
  • Year 2+: Full-time data reliability engineer, because "just this once" became "every month"

Meanwhile, your actual product roadmap suffers. The features that differentiate your business—the ones that drive revenue and member outcomes—get pushed because the data foundation still isn't solid.

The Actuarial-Grade Problem

Even if you nail data integration, you're still nowhere near having "actuarial-grade" data. That requires:

  • Risk adjustment methodologies that match CMS specifications
  • IBNR modeling that passes audit
  • Episode grouping logic that aligns with industry standards
  • Benchmarking data that's credible to actuaries and CFOs

This isn't just engineering—it's specialized healthcare domain knowledge that takes years to develop. Your team might build something that works, but will it pass muster with your Chief Actuary, medical management, or auditors?

The Opportunity Cost

The real question isn't "Can we build this?" It's "Should we?"

Every hour your engineers spend on data wrangling is an hour not spent on:

  • The predictive models that identify high-risk members
  • The provider engagement tools that drive better outcomes
  • The member experience features that reduce churn
  • The financial reporting that gives you competitive advantage

The most successful companies in every industry build on top of proven, reliable infrastructure, and the next generation of healthcare leaders are choosing to focus on their IP, and lean on partners for healthcare data infrastructure.

When Building Makes Sense

There are cases where building in-house is the right call:

  • You have unique data sources that no vendor handles
  • Data integration is your core business (you're building a healthcare data company)
  • You have regulatory requirements that prevent external data processing
  • You're at massive scale where vendor costs exceed internal costs

But for most healthcare organizations, data integration is necessary but not differentiating. You need it to be excellent, but you don't need to be the one building it.

The Build vs. Buy Framework

Ask yourself these questions:

1. Is 80% accuracy sufficient for your use case? If you're doing population health analytics, risk adjustment, or financial reporting, the answer is probably no. Small errors compound quickly in healthcare.

2. How fast do you need to be production-ready? Vendors can get you live in weeks. Building will take 6-18 months minimum, and that's if everything goes smoothly.

3. What's your true total cost of ownership? Don't just count engineering salaries. Include opportunity cost, ongoing maintenance, and the business impact of delayed features.

4. Do you have both healthcare data and actuarial expertise in-house? This isn't just about engineering talent—do you have people who understand Medicare Advantage risk adjustment? Claims adjudication workflows? Incurred-but-not-reported payment dynamics? Building these into software systems requires a unique blend of actuarial, med-econ and engineering expertise.

Making the Right Choice

CTOs need to be ruthless about what they build vs. buy. They buy infrastructure that needs to be excellent but not differentiated, and they build features that create competitive advantage.

In healthcare, that usually means:

  • Buy: Data integration, normalization, and foundational analytics
  • Build: Member engagement, provider tools, and business-specific workflows

Your engineering team didn't join a healthcare company to debug claims data formats. They joined to improve patient outcomes, reduce costs, and build the future of healthcare.

Let them do that. Buy the infrastructure. Build your business.