心血管医疗影像：从申报叙事恢复模块化产品规格

这项工作的公开价值，不在于复述答辩材料里的市场数字，而在于恢复一个医疗影像产品如何被拆成算法模块、临床计算流程和人工复核环节。

现存证据有明显层级：进度表记录了具体日期、接口和数据依赖；申报书描述预期能力；两版答辩材料陈述性能与市场主张。三者不能混用。本文只把进度表中的完成项视为实施事实，把申报与答辩内容视为设计目标或团队当时的自报。

临床能力不是一个模型，而是七条任务链

【文档事实】与临床人员讨论后，系统被拆成：

1. 左心室轮廓；
2. 左心室心功能；
3. 心肌壁厚；
4. 延迟强化；
5. 右心室轮廓与功能；
6. 心肌灌注随时间变化的衰减曲线；
7. 心肌应变及 T1 参数成像。

这些模块之间存在明确依赖，而不是并列菜单：

轮廓是多个派生指标的上游输入。只要分割在基底部、心尖部或边界模糊处出现系统偏差，容积、射血分数、壁厚和应变都会继承误差。因此，产品验收不能只看轮廓图“像不像”，还要验证派生测量对误差是否敏感。

进度表恢复出的真实时间线

这张表解释了为何“系统已经完成”并不准确。左心室轮廓、心功能链路和右心室接口存在原型级证据；壁厚、灌注、应变和延迟强化仍受数据或方法阻塞；T1 参数成像的流程状态又与原始数据探索并存，需要进一步拆分“界面流程”“计算实现”和“临床可用”。

【文档事实】产品计划还包含定位与形态确认、初版、第二版、机构内部署以及持续运营，时间安排使用约一周和约一个月的递进周期，并要求至少按月改进。这说明团队考虑过从演示到部署的节奏，但没有留下各版本的验收记录。

数据瓶颈在任务开始后才显性化

四例标注数据最能说明项目当时所处阶段。它足以验证文件能否读取、标注坐标是否对齐、接口能否返回轮廓，却不足以支撑疾病、人群、设备和机构之间的泛化结论。

更关键的是，不同模块需要不同的数据契约：

【分析推断】如果数据契约不在立项前冻结，“等待数据”会一直被当作外部依赖，算法团队无法判断缺的是病例数量、序列完整性、标注规范，还是临床计算公式。每个模块应在开发前设置数据就绪门：字段完整、去标识化、序列可读、标注通过双人复核、训练与验证病例按患者隔离。

申报指标与临床证据之间有多大距离

【文档事实】两版答辩材料都给出了性能、使用规模和未来市场目标，但没有同步提供队列构成、分母、训练与测试划分、参考标准、置信区间、不良案例或按设备分层结果。两版材料对未来目标规模的描述还相差一个数量级：一版使用约百家机构和数万病例的口径，另一版改成千家以上、千万级病例及份额目标。

这种变化说明目标数字仍处于申报叙事阶段，不能当作产品路线图基线。材料中的点估计也只能记为“团队自报”，不能改写为独立验证结果。

不同任务需要不同验收指标：

• 轮廓分割：重叠度、平均及高分位边界误差，并按心尖、基底分层；
• 心功能：容积、射血分数等派生值与参考测量的偏差和一致性；
• 参数拟合：逐像素拟合误差、失败率和设备协议分层；
• 病变识别：灵敏度、特异度、阳性预测值及适用人群；
• 临床工作流：医生修订比例、单例耗时、拒绝输出率和严重错误；
• 泛化：按机构、设备、协议和患者亚组报告，而不是只报总体均值。

没有这些上下文，一个“准确率”既不能说明分割质量，也不能说明临床可用性。

代码缺失意味着无法恢复哪些细节

【代码事实】Jira 中没有稳定对应的项目，GitLab 中也没有找到能与这些附件、模块名称和时间线相互印证的仓库。附件里一个不透明的工程文件无法形成可读代码证据。

因此，以下关键细节目前无法从历史材料验证：

• 原始影像如何导入、序列识别、去标识化和标准化；
• 模型的网络结构、损失函数、训练参数和权重版本；
• “六种算法”分别是什么，以及如何串联；
• 推理接口的请求、响应、超时、异常与版本协议；
• 医生修改轮廓后如何重算指标；
• 单元测试、回归测试、部署日志和审计机制。

申报材料还提出用知识图谱关联症状、疾病和多设备数据。【文档事实】这证明该能力进入过产品叙事；【证据缺口】没有实体类型、关系定义、消歧规则、查询接口或代码，不能确认知识图谱已经实现。

从残留材料恢复一份最小产品规格

以下是依据模块依赖和医疗工作流作出的【规格重建】，不是对历史实现的事实陈述。

核心实体可以设计为：

~~~text Case └─ Series └─ AnalysisTask └─ ModelRun(model_version, input_version, status) ├─ Measurement(value, unit, method) └─ Review(reviewer_role, correction, reason, time) ~~~

任务状态至少区分：

~~~text 待数据 → 数据校验 → 待分析 → 自动分析 → 待复核 → 已确认 / 已修订 / 拒绝输出 → 报告冻结 ~~~

关键机制包括：

• 推理结果必须绑定输入序列、模型版本和参数版本；
• 上游轮廓被修改后，所有派生测量自动失效并重新计算；
• 输入序列不完整、协议不支持或质量不足时拒绝给出确定结果；
• 医生能够看到原始影像、自动轮廓、修改记录和计算依据；
• 训练数据导出、模型调用、人工修改和报告冻结进入审计日志；
• 患者级数据严格隔离，公开材料不出现病例身份和合作机构信息。

这份规格解决的是“如何把原型变成可审查的辅助工具”，而不是假设缺失的历史代码曾经实现了这些能力。

下面是根据进度表依赖关系整理的等价伪代码，不是历史算法源码。它展示上游轮廓修订后，派生结果为何必须失效并重算：

def review_segmentation(task, corrected_mask, reviewer):
    assert task.status == "待复核"
    assert reviewer.can_review(task.module)

    previous = task.active_segmentation
    revision = save_revision(
        task_id=task.id,
        model_version=previous.model_version,
        input_version=task.series.version,
        corrected_mask=corrected_mask,
        reviewer_role=reviewer.role,
    )

    for measurement in task.derived_measurements:
        measurement.invalidate(reason="上游轮廓已修订")

    task.active_segmentation = revision
    task.derived_measurements = recompute(task.module, revision)
    task.status = "已修订"
    append_audit_event(task, previous, revision)
    return task

复盘：产品进度必须按证据类型拆开

• “界面完成”“算法可运行”“有少量标注”“通过内部测试”和“临床验证”是五个不同里程碑。
• 对上游数据和临床计算流程的依赖应进入计划主路径，而不是长期挂在备注栏。
• 多模块产品需要共享病例、版本、复核和审计能力，但每个算法必须保留独立适用范围。
• 申报指标应保存版本和依据；数量级变化必须重新评审资源、数据和合规假设。
• 医疗辅助系统的最终输出必须可见、可改、可拒绝、可追溯，医生保留最终判断。

证据账本

本文不保留人员、合作机构、设备厂商、患者、预算、内部地址或账号信息。所有产品化设计均明确标为规格重建，历史完成度只按可复核材料陈述。