The Homegrown Trap
Some health plans built their own risk adjustment technology. Internal development teams created chart review workflows, coding interfaces, and basic NLP tools tailored to the organization’s specific processes. These homegrown systems worked when the requirements were straightforward: ingest charts, help coders find codes, track production.
The requirements are no longer straightforward. CMS-HCC V28 changed the coding model entirely, requiring updated mappings, new coefficient tables, and recalibrated prioritization logic. Annual RADV audits with 35 to 200 enrollee samples require evidence preservation, cross-encounter indexing, concurrent audit tracking, and CDAT-compliant output formatting. OIG guidance demands two-way coding with documented MEAT validation. AI governance requires explainable reasoning for every coding recommendation.
Homegrown systems weren’t designed for any of this. Retrofitting them requires the same internal development team to become experts in V28 coefficient modeling, RADV submission specifications, MEAT validation frameworks, AI explainability standards, and compliance documentation requirements. The engineering effort to maintain parity with purpose-built commercial platforms consumes development resources that could serve the plan’s core business functions.
Where Homegrown Systems Fall Behind
The gap is widest in three areas. First, AI sophistication. Commercial platforms invest millions in NLP and clinical reasoning AI that maps documentation to MEAT criteria, evaluates evidence in both directions, and produces explainable recommendations. Replicating this capability internally requires AI/ML engineering talent that most health plans don’t employ and can’t recruit competitively against technology companies.
Second, regulatory currency. When CMS publishes new RADV specifications, updates V28 mappings, or changes audit submission requirements, commercial vendors update their platforms across all clients simultaneously. Homegrown systems require the internal team to interpret the regulatory change, design the update, build it, test it, and deploy it, a cycle that can take months while the platform operates on outdated logic.
Third, audit infrastructure. Purpose-built platforms include evidence preservation, concurrent audit tracking, defensibility scoring, and CDAT formatting as core capabilities. Homegrown systems typically handle coding but not the full audit lifecycle, which means the plan bolts on manual processes (spreadsheets, shared drives, email chains) for the functions the homegrown system doesn’t cover. That fragmentation is exactly what slows audit response and weakens evidence quality.
The Total Cost Comparison
Plans that built their own systems often cite cost control as the rationale. But the total cost includes internal engineering salaries, regulatory update cycles, security certification maintenance, infrastructure hosting, and the opportunity cost of engineering talent diverted from core business applications. When settlement risk is added to the calculation (homegrown systems that can’t demonstrate explainable AI or produce audit-ready evidence trails create enforcement exposure that commercial platforms are designed to mitigate), the total cost of homegrown often exceeds commercial alternatives.
The Decision Framework
Plans still running homegrown systems should evaluate whether their internal platform can deliver V28-current coding logic, explainable AI with documented evidence trails, two-way coding capability, MEAT validation at scale, concurrent RADV audit management, and CDAT-compliant output. Any risk adjustment solution that can’t deliver all of these is creating compliance gaps that commercial platforms have closed. The build vs. buy decision in 2026 isn’t about preference. It’s about whether the plan’s technology can meet the regulatory standard the enforcement environment now applies.
