If you build software for Medicare Advantage (MA) plans, "analytics" usually arrives as a vague requirement and leaves as a pile of nightly batch jobs and a BI dashboard nobody trusts. This post is about treating value-based care analytics as an engineering problem: data contracts, idempotent scoring, and auditability baked into the API surface.
The domain in one paragraph
Each member has diagnoses (ICD-10-CM codes) that map to Hierarchical Condition Categories (HCCs). HCCs, plus demographics, produce a Risk Adjustment Factor (RAF) under the CMS-HCC V28 model. RAF drives the plan's payment. So the analytics platform's job is to take coded encounters in, and emit defensible RAF and gap insights out — reproducibly.
1. Model the inputs as contracts, not files
The single biggest source of bad analytics is loose ingestion. Define a strict schema for encounters and enforce it at the edge:
