风险调整软件：从代码挖掘到合规证明的五大核心能力
1. 风险调整软件：从“代码挖掘机”到“合规证明者”的范式转移
如果你在医疗支付或健康计划领域工作，最近几年听到“风险调整”这个词时，后背可能已经开始冒冷汗了。这不再是一个简单的财务优化游戏，而是一个充满监管雷区的合规战场。过去，风险调整软件的核心卖点是“帮你找到更多被遗漏的诊断代码（HCC），从而提高风险调整因子分数，从CMS那里拿到更多报销款”。逻辑简单粗暴：代码越多，分数越高，收入越多。许多供应商的演示会自豪地展示其AI如何从海量病历中“挖掘”出额外的慢性病诊断，仿佛这是一台永不疲倦的印钞机。
但2026年的现实是，这台“印钞机”很可能正在为你打印罚单。美国司法部在三月从Aetna那里收缴了1.177亿美元，原因是其提交了缺乏临床支持的诊断代码且未能将其删除。Kaiser Permanente就类似指控达成了约10亿美元的和解。同月发布的OIG审计报告显示，三家医疗保险优势组织的错误率高达81%至91%。监管机构已经不再警告，而是直接开罚单。这意味着，评估风险调整软件的核心问题，已经从“哪个工具能找到最多的代码？”彻底转变为“哪个工具能帮我证明我提交的每一个代码都是站得住脚的？”。这场变革的本质，是行业从“收入驱动”向“合规驱动”的深刻范式转移。
2. 风险调整软件的核心工作流与当前困境
2.1 风险调整的基本逻辑与工作流
要理解这场变革，首先得清楚风险调整软件到底在做什么。在医疗保险优势等基于价值的医疗计划中，CMS根据参保成员的健康状况（即“风险”）向保险公司支付费用。成员病情越重、慢性病越多，计划获得的预期支付就越高。Hierarchical Condition Categories（HCC）编码系统就是用来量化这种风险的。软件的核心工作流通常包括四个步骤：数据摄入（整合电子健康记录、理赔数据、实验室报告）、AI识别（运用自然语言处理等技术从非结构化文本中提取潜在的HCC代码）、验证（将AI识别的代码与病历中的临床证据进行比对）、人工审核与提交（由专业编码员进行最终确认）。
一个高效的软件确实能比纯人工流程更快、更准确地完成这些步骤。但“高效”在今天有了新的定义：它不仅要快，其产出物还必须能经受住审计的考验。传统软件聚焦于流程的前半段——尽可能多地“添加”代码，却普遍忽视了后半段——严谨地“验证”并“删除”那些缺乏支持的代码。
2.2 单向编码模式埋下的合规陷阱
多年来，许多健康计划将风险调整视为纯粹的营收部门，聘请供应商进行病历回顾，唯一的目标就是寻找被遗漏的诊断以增加RAF分数。这种“只增不减”的单向模式在监管宽松时期确实带来了可观的财务回报。然而，Aetna的案例成为了一个转折点。司法部指出，Aetna在2015支付年度的病历审查项目中，既发现了可添加的代码，也发现了缺乏支持的代码，但其操作只选择了添加，而故意忽略了删除。政府认为，这种选择性利用审查结果的行为，构成了故意夸大支付的证据。
这揭示了一个致命的逻辑缺陷：如果你的软件或流程设计上只寻找“漏网之鱼”（漏报），而系统性地无视“无中生有”（多报），那么你本质上构建了一个存在偏见的系统。在审计员看来，这不再是无心之失，而是系统性风险的证据。OIG那几份触目惊心的审计报告（错误率81%-91%）进一步证实，将“病史”错误编码为“现病史”等问题极为普遍，而这些错误代码很多正是通过不严谨的回顾性审查被引入并保留在系统里的。
3. 2026年合规环境下，风险调整软件必须具备的五大核心能力
基于当前严峻的执法环境和我们与多家大型健康计划、ACO合作处理数百万份患者记录的经验，我认为一款真正有用而非“ shelfware”（买来闲置的软件）的风险调整平台，必须拥有以下五项核心能力。
3.1 双向编码：增与删的平衡艺术
这是当前评估中最重要、却最难在市场上找到的能力。双向编码意味着软件必须同时具备两个功能：识别应添加的代码（理赔中遗漏的合法诊断）和识别应删除的代码（缺乏临床证据支持的诊断）。任何一个合规优先的项目都需要这两个方向同时工作。
Aetna和解案中，1.177亿罚款中的1.062亿都可追溯至那个单向工作的病历审查项目。监管信号已无比清晰：补充数据提交理应双向进行。因此，在评估供应商时，你必须直接询问：“你们的平台是否能识别多报的代码？”如果对方的回答含糊其辞、强调“我们的重点是帮您增收”，这就是一个巨大的危险信号。真正的合规软件，其默认工作模式就应该是双向的。在我们的平台上，神经符号AI会在同一个审查周期内，同步识别潜在添加、潜在删除以及确认正确的代码，这不是一个可选的哲学功能，而是应对监管现实的直接技术响应。
3.2 可解释的AI与证据链
“由AI驱动”如今已是门槛级宣传，每个供应商都在这么说。关键问题是：这个AI能展示它的工作过程吗？当一个诊断代码被标记出来时，软件必须能够将该建议追溯到病历中具体的临床证据上。这意味着，每个代码都需要与符合MEAT标准（管理、评估、评估/计划和治疗）的文档片段相关联，这是CMS验证HCC诊断的核心依据。
如果AI不能解释它为何建议某个代码，那么这个代码在审计面前就是不堪一击的。我们采用的神经符号AI架构，结合了神经网络（擅长从文本中提取模式）和符号推理（基于知识图谱和临床规则进行逻辑判断）。这种架构为每一个代码建议都生成了一个透明的决策轨迹：证据在病历的哪一页、哪一段，它是如何映射到特定诊断的，以及它为何满足或未能满足MEAT标准。与纯粹的黑盒NLP或生成式AI相比，神经符号系统因为受到知识图谱和临床规则的约束，更不易产生“幻觉”或错误关联。审计员或内部合规团队无需事后反向工程去猜测AI的思考过程，证据链一目了然。
注意：在供应商演示中，不要只看它推荐了什么代码，一定要坚持查看“证据视图”。如果对方无法现场展示代码与具体病历内容（如“患者主诉呼吸困难，查体闻及湿罗音，胸片显示肺水肿”）的精确链接，那么其AI的可解释性就值得怀疑。
3.3 为RADV审计而生，而非事后补救
CMS已于2026年2月启动了2020支付年度的风险调整数据验证审计，并且审计节奏已加快至每季度一次。审计样本量可变（35至200参保人年），CMS自身也在大幅扩充其认证编码员队伍，并利用AI辅助审计。这意味着，审计变得更频繁、规模更大、速度也更快。
因此，软件是否原生为RADV审计准备而设计至关重要。它应该是一个审计指挥中心，提供集中化的审计管理、实时进度跟踪、生成符合CMS要求的报告，并能从一个界面管理并发的多个审计项目。关键在于，审计防御能力不应是事后添加的功能，而应内建于日常的编码流程中。在我们的平台上，通过回顾性工作流审查的每一份病历，都已携带了MEAT验证的证据链。当审计通知到来时，审计模块不是从头开始整理资料，而是直接调取和呈现已在编码过程中验证过的文档，极大提升了响应速度和证据质量。
3.4 前瞻性与回顾性覆盖相结合
回顾性审查（在诊疗发生后回顾病历）是必要的，但已不再足够。CMS明确表示更青睐“诊疗驱动”的文档，即诊断应在患者实际就诊时由主治医生确认，而非通过事后数月的病历挖掘才发现。最安全的诊断，就是在诊疗点由临床医生记录下来的诊断。
因此，优秀的软件需要提供前瞻性风险调整支持。这并非告诉医生该如何编码，而是在医生工作流中（通常在EHR内），基于患者过去两年的数据，智能提示需要重新捕获的慢性病状况、标记诊疗间隙，为临床决策提供支持。这确保了在医患面对面时，所有相关的临床信息都能被及时考虑和记录。
一个完整的平台应该将前瞻性与回顾性解决方案整合在一起。前瞻性方案在最安全的时点（诊疗发生时）捕获诊断；回顾性方案则清理遗漏的内容，并移除不应存在的代码。两者结合，才能覆盖风险调整的全生命周期，实现真正的闭环管理。
3.5 安全性与部署灵活性
风险调整软件处理的是海量受保护的健康信息。安全认证不是可选项，而是必选项。最低要求应包括HITRUST认证和SOC 2 Type II合规报告，但并非所有供应商都同时具备这两者。此外，部署模式也至关重要：平台能否运行在你自己的云环境中？还是要求你将PHI发送到供应商控制的基础设施？
对于大型企业客户而言，能够将软件部署在自有或指定的云环境（如Azure、AWS、GCP），是与现有IT治理和安全策略保持一致的关键。这减少了数据跨境、第三方管控带来的潜在风险。在评估时，务必要求供应商提供清晰的安全白皮书和部署架构图，并由你的信息安全团队进行评审。
4. 供应商评估中的关键危险信号
在眼花缭乱的供应商演示中，如何拨开迷雾，识别潜在风险？以下是几个需要警惕的“红色警报”：
1. 基于小样本的准确率宣称：很多供应商会展示在一个200份病历的试点项目中达到98%的准确率。这个数字在生产规模下毫无意义。你必须要求查看在不进行人工干预的情况下，处理2000份甚至更多病历后的性能数据。如果供应商无法提供，那么其“AI”很可能只是一个披着软件外衣的人力质检流程。
2. 仅支持“添加”的回顾性项目：这是最危险的信号。如果供应商的解决方案只识别待添加的代码，从不标记待删除的代码，那么你正在构建的，正是司法部刚刚惩罚Aetna的那种风险模型。直接问出那个关键问题：“你们的平台如何识别和处理多报的代码？”如果答案有任何犹豫或回避，请果断离开。
3. 不透明的“黑盒”AI：如果供应商无法解释其AI背后的技术架构，这就是一个问题。“我们使用AI”这句话什么也没说明。你需要追问：使用的是NLP、机器学习、生成式AI还是其他技术？系统如何解释其代码建议？能否提供一个样本证据链？如果演示只展示推荐结果而不展示推理过程，那就假设它根本不存在推理过程。
4. 将RADV准备作为咨询附加服务：有些平台将RADV审计准备视为事后的咨询或专业服务，而非平台的内生能力。考虑到季度性的审计节奏，RADV就绪性必须是平台的原生功能，能够与日常编码和数据管理流程无缝集成，而不是在审计通知下达后才临时拼凑的方案。
5. 行业未来方向与合规性建设
监管的风向标已经非常明确。OIG在2026年2月更新的《医疗保险优势行业合规计划指南》中，将病历审查、上门健康风险评估和EHR提示等做法列为需要密切监督的对象，并明确指出未能删除不受支持的代码属于合规失败。同时，该指南还特别强调，MAO必须审查其编码过程中使用的AI和软件工具。
另一方面，MedPAC的报告指出，医疗保险在MA参保人上的支出比传统按服务付费模式高出14%，其中约220亿美元的差距是由编码强度驱动的。两党共同提出的《No UPCODE Act》法案甚至提议将病历审查和健康风险评估得出的诊断完全排除在风险调整之外。
所有这些信号都指向同一个结论：风险调整正从一个营收职能转变为一个合规职能。为最大化代码捕获而构建的软件将成为负债；为证明临床准确性和文档完整性而构建的软件将成为必需品。未来的赢家不是那些能找到最多代码的工具，而是那些能最好地证明每个已提交代码合理性的工具。
6. 构建面向未来的风险调整操作实践
基于上述分析，对于正在使用或计划采购风险调整软件的健康计划和供应商组织，我建议从以下几个层面调整实践，以构建一个可持续的、合规的风险调整项目：
第一，重塑内部文化与考核指标。必须将风险调整团队的目标从单一的“RAF分数提升”转变为“精准编码与合规率”。考核指标应同时包含“漏报率”和“多报率”，并定期进行内部审计，模拟RADV检查，以评估代码提交的证据坚实度。管理层需要传达清晰的信息：合规性优先于短期财务收益。
第二，实施技术采购的“双向验证”测试。在供应商选型的概念验证阶段，不要只提供“干净”的病历。应该准备一个包含已知多报、漏报和正确编码的测试病历集。要求供应商平台运行后，不仅看它发现了多少遗漏的代码，更要严格评估它：1）是否正确识别并建议删除那些缺乏支持的代码；2）是否为每一个建议（无论是增是删）提供了清晰、可追溯至具体文本的MEAT证据链。这是检验其AI是否真正“理解”临床文档而非简单模式匹配的关键。
第三，整合前瞻性干预到临床工作流。与IT部门和临床领导合作，探索将风险调整的前瞻性提示无缝嵌入到医生的EHR工作流中。重点在于设计非侵入性的、以患者安全和服务质量为导向的提示，例如：“系统提示：患者有2型糖尿病史，但过去12个月内未记录HbA1c结果，本次就诊是否考虑评估？” 这能将代码捕获点前置到最可靠的诊疗时刻，从源头上提升数据质量。
第四，建立持续的审计就绪状态。不要将审计准备视为一个临时项目。利用软件的审计管理模块，常态化地维护一个“活”的审计包。这意味着，日常的每一次代码添加或删除决策，其背后的证据和支持文档都已被结构化地保存和索引。当审计真正来临时，你的团队可以在几天内（而非几周内）完成证据提交，展现出卓越的治理水平。
第五，投资于编码员与临床医生的持续教育。再好的工具也需要人来驾驭。定期对编码员进行培训，重点不仅是HCC编码规则，更是对MEAT标准的深刻理解，以及如何利用AI提供的证据链进行批判性判断。同时，对临床医生进行教育，解释准确、及时的诊断记录不仅关乎患者护理，也关乎整个医疗系统的财务完整性与合规性，争取他们的理解与配合。
最终，选择风险调整软件，就是选择你未来五年的合规姿态。它不再是一个简单的IT采购决策，而是一个战略性的风险管理决策。在2026年及以后，唯一可持续的策略，就是从“寻找更多代码”转向“证明每一个代码”。这不仅是应对监管的盾牌，更是构建一个更公平、更高效、基于价值的医疗体系的基石。