产品设计文档 · PRODUCT DESIGN · 最终版

AI-native PACS 产品设计

从设计哲学、核心对象、工作流到功能架构——完整的产品定义与设计方法

v2.0 Final · 2026-11-01 · 本文整合设计哲学与方法论，统一使用审核后术语，是对外交付与内部迭代的权威依据

01定义：什么是 AI-native PACS

一句话定义

一个围绕「临床问题」组织工作的影像诊断系统：AI 先行起草每一步产出,人审核签发；语义沿全流程保真且可溯源；每一次交付都有确认闭环。它处理的是证据，不是文件。

它不是 RIS + PACS + AI。RIS 与 PACS 的分裂是"检查对象"模型的产物——RIS 管单子、PACS 管图片。核心对象换成"临床问题"后，这个分裂不再存在：申请、协议、影像、报告、沟通都是同一个问题对象的不同阶段。对外沿用 AI-native PACS 作为名称。

它与 PACS + AI 的本质区别

PACS + AI：旁路辅助

人操作为主，AI 在旁路上给建议。阅片医生可以选择看或不看 AI 标注；报告医生可以参考或不参考 AI 预读。AI 关掉，系统照常运转。

  • 核心对象是"检查"（一次扫描）
  • 协议来自通用模板库
  • 报告从空白文本框开始
  • 质控在签发后抽检
  • AI 结果放在单独窗口，不进主流程

传统工作流示意

申请（人填） → 排程（人排） → 扫描（人操作） → 归档（自动） → 阅片（人读，AI 旁观） → 报告（人写，可能参考 AI） → 签发（人签） → 发送

AI-native：主路起草

AI 在关键路径上先行起草，人审核签发。协议草案、标注、报告条目、质控意见都由 AI 生成，医生审核后确认。AI 服务不可用时，系统进入显式标记的降级模式。

  • 核心对象是"临床问题"（为什么做）
  • 协议按问题 + 约束推导
  • 报告从 AI 草稿开始审核
  • 质控在签发前逐份完成
  • AI 结果是下一步输入，不是附件

AI-native 工作流示意

申请（AI 预审） → 协议（AI 草案 → 人确认） → 采集（AI 质检 → 人补扫） → 标注（AI 标注） → 报告（AI 起草 → 人审核） → 质控（AI 核查 → 人处理） → 签发（人签） → 交付（AI 解释 → 人确认）

02设计约束：问题驱动 · 语义保真 · 闭环可证

不是功能列表，而是所有功能必须满足的三条约束。任何设计决策违反其一，即不属于本产品。

约束一

问题驱动

每个工作步骤都知道"这次检查为什么做"。协议、质检标准、报告结构、危急值判断，都从临床问题推导，不从通用模板出发。问题驱动不等于只看问题：意外发现有独立通道，技师与临床医生的人工发现也走此通道。

约束二

语义保真

信息沿链条不丢失（内容完整）、不失真（换形式不换含义）、不失源（每条信息标注来自系统 AI / 持证算法 / 规则 / 人工，含版本与时间）。只转换呈现方式，不做降维。测量可比时给变化，不可比时输出不可比的原因而非强行给出增长率。

约束三

闭环可证

系统永远知道自己发出的信息是否被接收。每个需要他人行动的输出都有确认机制，确认状态是系统状态的一部分。系统也知道自己处于哪种运行模式（正常 / 降级）。降级不是妥协，而是理念的一部分——临床主线独立可运行。

四个判别问题

任一答"否"即非 AI-native。

Q1系统是否知道"为什么做"？协议、QC、报告结构是否按临床问题定制，而非把诊断当备注字段。
Q2每条结论能否追溯到证据与来源？点条目跳标注，测量值知道出自哪一层、哪个算法、哪个版本。
Q3系统是否知道信息被谁接收？危急值、协议草案、患者说明都有确认状态。
Q4AI 是否在关键路径上？默认路径是"AI 起草→人签发"；AI 不可用时进入显式标记的降级模式，而非静默退回"正常"。PACS+AI 的 AI 在旁路上，关掉无感；AI-native 的 AI 在主路上，关掉有明确的模式切换与留痕。

03翻转：自动化级别的重新配置

AI-native 的逻辑：AI 先行起草，人审核签发。协议草案由 AI 生成，技师审核后确认执行；报告条目由 AI 按标注和病史生成，医生审核中可以对着图像语音修改；质控由 AI 逐份完成，医生看到的已经是标出问题的报告。人不是在做工作，而是在审核 AI 已经完成的草案。

精确表达是：把每个动作的默认自动化级别从 A0（人工操作）提到 A1（自动准备）/ A2（确认后执行）；A3（预批准自动化）限于随访提醒、队列分配等事务；A4（自主临床决策）不在本产品范围。签发永远由人完成。

级别含义本产品中的典型动作谁负责
A0人工操作降级模式下的全部步骤；AI 不适用时的原图阅片人
A1自动准备整单预审意见、协议草案、历史预取与对齐、病灶标注、报告条目草稿、语义质控标记、风险预读、患者版解释草稿AI 生成，不对外发布
A2确认后执行缺项补开、协议执行、补扫、报告提交、签发、危急值推送、患者说明发出有权限的人确认
A3预批准自动化随访到期提醒、审核队列分配、接口失败重试、已确认计划的分发规则内自动，留痕
A4自主临床决策自动签发、自主改变治疗方案 —— 不纳入本产品—
降级模式是约束三的体现。AI 服务不可用时，系统进入显式标记的 A0 模式：界面提示、报告留痕、事后可统计。临床主线独立可运行；AI 增强线是默认开启的主路径，而非可选插件。

04核心对象：临床问题（Clinical Question）

系统的聚合根。从申请提交时创建，到交付确认后归档；所有环节的输入输出都挂在它上面。它不是数据库表，而是有状态、有生命周期的领域对象。

问题陈述
临床诊断 + 检查目的的语义表达。例："排除主动脉夹层"。驱动一切下游决策。
患者约束
肾功能、过敏史、体重、既往手术、用药——影响协议与判断的临床因素，按目的最小化装配，带版本
证据需求
回答此问题需要的影像证据：范围、时相、层厚——由问题陈述 + 患者约束推导
证据采集
实际协议（含与标准的差异及理由、技师确认）、序列级 QC 结果（持证算法 + 问题支撑性复核）、补扫记录
诊断推理
标注（来源、版本、置信度）↔ 检查所见条目 ↔ 测量值，三者双向关联；诊断意见逐条附依据
意外发现
不回答当前问题但有临床意义的发现。可触发独立报告条目、派生新问题线、或危急值流程。技师与临床医生的人工发现也走此通道。
答案（版本化）
结论 + 处置建议 + 随访计划 + 患者版解释。签发后不可变；新信息产生新签发版本，旧版本保留
交付状态
推送、临床回读、患者查阅的时间点与确认状态。系统知道答案是否被接收
问题线
同一患者、同一临床问题的连续对象串联。随访是线的延续；测量可比性在线内校验，不可比时输出原因而非强行给出增长率

生命周期（9 个主状态 + 2 个分支）

Created→Validated→Acquiring→Evidence-Ready→Diagnosing→Draft-Ready→Review-Pending→Signed→Delivered
分支：QC-Flagged（语义质控退回，回到 Diagnosing） Amended（签发后修正，产生新版本后回到 Delivered） Cancelled（任一阶段终止）
为什么要有"意外发现"？问题驱动有隧道视野风险——医生申请胸部 CT 排查肺结节，影像发现主动脉根部钙化，这不回答"肺结节有没有"，但有临床意义。意外发现通道让它不被丢弃：可以触发独立报告条目（在当前报告里）、派生新问题线（开新检查申请）、或启动危急值流程。技师与临床医生的人工发现也走此通道，而非只有 AI 可以报意外。

05工作流：10 个节点 + 1 个分支

每个节点是一次状态转换的执行者。AI 列为 A1 产出，人列为 A2 确认；闭环列标明系统如何得知结果。

#节点AI 先行（A1）人签发（A2）闭环
1申请与预审解析临床诊断，装配患者约束，生成证据需求，整单预审（缺项、配套、禁忌）申请医生确认补开预审意见回推，确认后才下发
2排程按证据需求与设备状态推荐时段登记员确认，处理例外变更推送患者与岗位
3协议按问题 + 约束生成草案，标注与标准协议的差异及理由；越界由规则拦截技师确认执行草案 + 确认记录入对象
4采集与质检序列级 QC：图像质量（持证算法）+ 问题支撑性（系统复核）技师离机前补扫QC 与补扫记录入对象
5历史对齐问题线内历史影像对齐到同一层面，测量串成变化记录，病史摘要可点回原文医生核对对齐可比性校验结果入对象
6标注与报告病灶标注（持证算法）→ 所见条目 → 诊断意见附依据；意外发现独立成条医生审核、语音修改、确认测量条目↔标注双向关联
7语义质控所见 vs 结论、本次 vs 历史、报告 vs 临床诊断，三项契合度逐份核查医生处理标记后提交不通过不进审核队列
8审核签发风险预读，高风险置顶，附质控记录与关键层面审核医生签发签发版本冻结
9危急值语义分析命中 → 推送报告 + 影像 + 标注到临床桌面报告医生确认发出；临床医生回读确认时间点留痕，超时升级
9b签发后修正补传影像、晚到 AI 结果、临床质疑 → 生成"签发后新信息"任务医生评估后签发新版本级联更新分发、患者说明、随访
10患者交付图文报告、患者版解释、处置与随访草稿；患者提问按报告内容作答医生确认解释与建议患者查阅状态入对象

06功能架构：四层

业务层
10 个业务模块，一一对应工作节点
申请与预审排程调度协议管理与生成采集与质检影像归档与检索历史对齐与问题线阅片与报告质控与审核危急值与沟通患者交付与随访
能力层
6 个横向能力，业务模块通过统一接口调用
临床语义引擎持证算法接入平台规则引擎任务编排评测与治理审计追溯

临床语义引擎：解析申请、推导证据需求、语义质控（所见vs结论、本次vs历史、报告vs临床诊断）、风险预读。持证算法接入平台：调用、结果、版本、留痕。规则引擎：配套、安全边界、危急值、自动化级别配置。任务编排：触发→上下文→执行→验证→确认→评估；预算与退出。评测与治理：本地验证、运行监控、反馈回流、受控改进。审计追溯：谁、何时、依据什么、改了什么。

数据层
临床问题对象库为中心
临床问题对象库（关系型 + 文档型）影像存储（DICOM Archive）知识库（协议、规则、模板、术语）签发版本库（不可变）
接入层
互操作
HIS / EMR（HL7 FHIR）设备（DICOM Worklist / MPPS / Store）区域平台与外院调阅患者端（小程序 / App）
任务编排是 AI-native 区别于"调用几个算法"的技术核心。每个 AI 任务必须声明：为哪个问题对象、读取哪些数据版本、允许哪些工具、输出什么对象、由谁确认、预算用尽如何退出。任务记忆限于本病例，不跨患者。工作流管状态与责任，规则引擎管明确条件，AI 管文字、图像、模糊匹配与候选推理——三者分工，AI 不是唯一的状态库、身份系统或签发控制器。

07设计过程：从哲学到功能的 8 步推导

设计不是"想功能"，而是从约束推导到架构的过程。任何跳步都会让产品在中途偏离 AI-native 的定义。

1
陈述约束

先写三条设计约束（问题驱动、语义保真、闭环可证），用判别问题验证。任何功能违反其一，砍掉。

2
识别核心对象

什么是系统的聚合根？不是"检查"，而是"临床问题"。列出它的 9 个组成部分（问题陈述、患者约束、证据需求、证据采集、诊断推理、意外发现、答案、交付状态、问题线），画出 9 态生命周期。

3
定义自动化级别

不是"AI 做什么"，而是"每个动作配置在 A0–A4 哪一级"。列出 A1（自动准备）、A2（确认后执行）、A3（预批准自动化）的典型动作，明确 A4 不纳入，降级模式回 A0。

4
推导工作流

按对象的生命周期推导 10+1 个节点。每个节点标明：AI 先行什么（A1）、人确认什么（A2）、如何闭环。不能跳过节点 7（语义质控），否则违反约束二。

5
分层架构

业务层（10 模块）、能力层（6 能力）、数据层（4 库）、接入层（4 接口）。能力层是横向的，业务层通过统一接口调用。任务编排是能力层的核心，管 AI 任务的触发、上下文、预算、退出。

6
功能规格

逐个节点写交互流程、输入输出、异常处理。每个流程都要回答：AI 生成什么、人审核什么、如何闭环、降级时怎么办。用状态图 + 序列图表达，不要只写文字。

7
指标与验证

三条约束各一组北极星指标。问题驱动：申请缺项拦截率、离机前补扫比例、协议草案采纳率。语义保真：条目↔标注关联率、来源标注覆盖率。闭环可证:危急值确认时长、降级模式时长占比。写 20 个端到端用例，用真实病例跑状态机。

8
边界与迭代

明确不做什么（设备底层优化、算法研发、A4 决策、科研平台）。定义 MVP：节点 1·3·4·6·7·8，一个场景（急诊 CTA 或肺结节随访），3–6 个月，四个判别问题 + 20 个用例验收。每 2 周一个迭代，每个迭代用真实病例走一遍状态机。

警告：常见的跳步错误
直接列功能、先画界面、把工作流当成"用户点什么按钮"、让 AI 团队自己定义任务边界、没有降级模式、质控在签发后抽检、把"临床诊断"当备注字段、报告条目不关联标注、危急值没有确认状态、历史影像只做"参考"不做对比。这些都是因为跳过了前 4 步。

08验证：判别问题与北极星指标

四个判别问题

任一答"否"即非 AI-native。

Q1
系统是否知道"为什么做"？协议、QC、报告结构是否按临床问题定制，而非把诊断当备注字段。
Q2
每条结论能否追溯到证据与来源？点条目跳标注，测量值知道出自哪一层、哪个算法、哪个版本。
Q3
系统是否知道信息被谁接收？危急值、协议草案、患者说明都有确认状态。
Q4
AI 是否在关键路径上？默认路径是"AI 起草→人签发"；AI 不可用时进入显式标记的降级模式，而非静默退回"正常"。

北极星指标

问题驱动

  • 申请缺项在提交时拦截率（目标 >95%）
  • 离机前补扫占全部补扫的比例（vs 召回，目标 >80%）
  • 协议草案采纳率与修改原因分布

语义保真

  • 报告条目与标注关联率（目标 100%）
  • 临床医生回查原图次数（指标：降低）
  • 患者版解释经医生修改的比例
  • 来源标注覆盖率（目标 100%）

闭环可证

  • 危急值从命中到回读确认的时长分布与超时率
  • 签发后修正的级联更新完成率（目标 100%）
  • 降级模式时长占比与期间病例数

总体

  • 申请到签发全流程时长（按科室基线设定）

09边界与 MVP

不做什么

  • 设备排队调度的底层优化算法
  • 影像后处理专业工具（归持证算法与第三方）
  • AI 算法研发与注册（只接入持证算法）
  • 科研数据平台、区域会诊平台、医院集成总线
  • A4 自主临床决策

医疗 IT 的边界模糊，容易陷入"什么都做"。守住核心：临床问题对象 + AI 主路 + 闭环确认，其他能力通过接口对接。

MVP（3–6 个月）

范围：节点 1 · 3 · 4 · 6 · 7 · 8，一个完整闭环（申请→签发），一个场景先跑通（急诊 CTA 或肺结节随访二选一）。

验收：四个判别问题 + 20 个端到端用例（见原 review-plan §14）为准。

节奏：每 2 周一个迭代，每个迭代用真实病例走一遍状态机。不追求功能完整，追求闭环跑通。

MVP 不是"最小可卖"，而是"最小可验证约束"。如果 MVP 里协议还是通用模板、报告还是空白开始、质控还是签发后抽检，那它不是 AI-native 的 MVP。

10设计检查清单

每个功能规格、每个迭代、每次代码审查，都过一遍这张清单。

核心对象

问题驱动

语义保真

闭环可证

自动化级别

任务编排

架构