AI Native RIS/PACS系统总体方案

AI Native RIS/PACS 是以患者影像诊疗任务为中心，将放射信息系统（RIS）、影像归档与通信系统（PACS）、结构化临床信息、知识规则和受控AI能力统一设计的新一代影像业务系统。它负责一次检查从申请、预约、执行、图像采集、阅片、报告、审核、重要结果沟通到后续随访的全过程，并持续记录人员、数据、证据和版本之间的关系。

这里的“原生”是一种产品与工程设计方式，不是本方案宣称的官方认证等级，也不意味着所有病例必须使用同一个模型。AI可以是影像检测与测量模型、语言模型、语音模型、预测模型，或与规则引擎协同的任务服务。

系统完成的核心转变：从“围绕一次检查存文件、流转状态”，转向“围绕临床任务组织图像、观察、证据、文书和后续行动”。人仍承担授权范围内的临床判断，系统承担可靠处理、准备和记录职责。

系统职责分界

基础建设范围建议以CT、MR、DR的检查业务为主，支持约定范围的其他DICOM模态接入。乳腺专用显示、超声波形分析、核医学定量、介入及放疗等采用独立能力包；每个包明确存储、显示、测量和临床用途，不能以“支持DICOM”笼统替代专科能力验收。

以上是业务顺序，不是要求所有技术处理严格串行。影像接收可以与采集并行；历史预取可提前完成；AI可在输入满足要求时启动；医生可在AI未完成时阅片。危急结果沟通依据院内制度及时启动，不等待报告全部流程走完。

异常也是正式流程

患者无法确认、申请变更、设备中止、部分图像到达、补扫、报告退回、检查取消、结果迟到和通知无人接收，都必须有状态、负责人、允许动作、截止时间和恢复路径。系统不允许用一个笼统的“失败”或人工线下处理将异常从数据中消失。

对每次医生点击附加强制理由会增加负担。普通编辑自动记录差异，只有关键驳回、重大风险覆盖、身份修正和异常放行等需要结构化理由；质量分析应以病例和任务为单位，而非鼓励机械点击。

标准依据：DICOM工作列表用于设备获取计划任务；存储承诺与单纯接收图像具有不同语义。具体设备能力需要逐台联测。[2][3]

制度依据：国家卫生健康委医疗质量安全核心制度涉及查对、危急值、病历与信息安全。系统提供可配置工具和可追溯记录；临床时限、人员职责和升级路径应与本机构正式制度一致。[14]

本系统以“任务”而不是“聊天轮次”组织AI。每个任务必须说明：为哪位患者、哪次检查解决什么问题；读取哪些数据版本；允许使用哪些工具；输出什么对象；由谁确认；失败如何退出。一个模型可以承担多个任务，一个任务也可以调用多个模型，但患者状态、签发权限和流程终点由业务服务控制。

任务上下文由六部分组成

自动化级别：按动作配置，不按模型名称配置

不要求通过“多智能体互相讨论”完成每项工作。一个受约束的工具调用能解决的问题，不额外增加代理。复杂任务需要多步协作时，共享结构化任务结果与版本，不依赖复制整段聊天记录。

场景一：门诊颅脑MR，从申请到签发

临床提出检查目的后，系统读取获准使用的背景，生成项目匹配及缺项提示。医生确认申请；预约根据设备与准备条件分配时间；到检完成身份和安全核验；技师确认协议并记录实际序列。影像接入后自动预取历史、核查完整性，符合条件的算法运行，否则明确显示不适用。诊断医师完成原图阅读，录入或确认观察；系统据此组织报告并检查术语、结构和矛盾。审核与签发按资质执行，报告与观察版本一起冻结，正式结果回到临床。

场景二：肺部病灶纵向追踪

系统载入当前和既往影像，检查患者关联、日期、采集方法与可比较性。模型提出可能属于同一病灶的配对以及测量，医生逐项核对后建立长期观察标识。报告中的变化说明引用本次与既往测量及方法。是否需要跟进、采取何种方式，由授权临床人员结合适用证据确认；平台将已确认计划形成任务，追踪联系、执行和结局。

例如，演示病例中的“8.2 mm”只是一项带方法、图像位置和确认状态的测量。系统不能仅凭这一数字直接生成个体化复查间隔或恶性结论。若两次测量不可比，输出“不可直接比较”以及原因，而不是强行给出增长率。

场景三：急诊影像的风险提示与沟通

急诊医嘱从进入系统起即保留临床优先级。图像达到特定算法的输入要求后可启动分析；在获准的用途和本地验证策略下，将可疑高风险信号送到影像医生的复核队列。医生核实后启动相应级别的重要结果沟通，系统记录接收者和后续处置。AI失败或未检出不使急诊降级，临床与技师发现的危险信息也有独立人工入口。

场景四：跨院调阅与检查互认辅助

接诊医师先核验患者关联与外院资料来源，系统展示原检查项目、执行时间、图像完整性和正式报告。规则服务将原项目映射为可比较语义，并提示其是否能够回答当前临床问题。当前医生决定采用既往结果、补充检查或重新检查，并记录原因。平台保留来源医院和签发版本，不将外院文字转换为本院已经核实的观察。

场景五：签发后到达的新AI结果或补传影像

已签发报告保持不变。新图像生成新的输入清单；系统识别旧结果已不能完整代表当前输入。AI晚到结果进入“签发后新信息”任务，由相关医生评估是否需要补充或更正报告。若发生更正，产生新签发版本，并更新分发、患者说明和随访关系，同时保留历史与通知证据。

建议采用“稳定临床核心＋异步智能任务＋共享证据与治理”的架构。逻辑上分层，物理上不强制把每一功能模块拆成微服务。规模较小时可用模块化业务服务承载RIS、报告和任务管理；影像接入、归档、渲染、推理与大规模检索按性能和故障边界独立部署。

所有临床、AI和统计数据围绕患者、就诊及检查形成关联，但不同对象不强制一对一。医嘱可以拆分执行，一个影像检查可以对应多项申请，正式报告也可以覆盖多个执行项目。必须保留这些映射及发生时间，不能只用一个检查号拼接全部数据。

三个状态机必须分开

这些是内部领域状态，不直接冒充FHIR或DICOM枚举值。对外交换时按选定版本的资源状态映射，并保留必要扩展。FHIR提供观察、报告和来源等表达能力；具体事实库、状态流转和字段约束仍需要本系统的实施指南。[8][9][11]

互操作验收同时检查协议、语义、身份、状态和错误恢复。FHIR不是影像像素仓库：ImagingStudy表达影像检查及对象相关信息，实际DICOM实例仍需要通过相应影像服务获取。[7]

DICOMweb、SR、SEG、FHIR与IHE各承担不同层面的职责，不能互相替代。协议与资源事实依据见资料[1]—[13]；本表的系统分配及字段要求是本方案的实施设计。[1][4][5][6][10]

标准结果回写的最小验证链

生成一个候选测量 → 写入适用的标准对象 → 由独立接收端解析 → 核对患者、原图、单位、位置、来源与评估状态 → 在原图上复现对应位置 → 按条件检索 → 导出并重新导入。仅证明能生成文件、能打开PDF或能导出Excel，不构成这条链路的验收。

知识服务同时维护“为什么这样处理”与“系统怎样执行”。证据文本、适用条件、逻辑表达式、动作和例外必须分开管理，避免将一段自然语言直接作为不可解释的阻断规则。国家卫生健康委的CDSS管理规范解读明确其临床辅助工具定位；本方案据此将临床知识治理与授权操作单独设为产品能力。[17]

示例：申请侧别与已确认观察侧别不一致

这是数据一致性规则，不是“模型判定哪一侧正确”。当申请与已确认观察均为明确单侧，且对应同一目标部位时才比较；双侧、多发、跨部位或信息不足进入相应分支。发现冲突后要求有权限人员核对医嘱、影像定位和文书，修正或说明合理例外。

{
  "rule_id": "QC.LATERALITY.CONSISTENCY",
  "version": "1.0.0",
  "kind": "deterministic_consistency",
  "applicability": {
    "phase": "pre_sign",
    "same_target_anatomy": true,
    "explicit_unilateral_values_required": true
  },
  "required_inputs": [
    "order.laterality",
    "confirmed_observation.laterality",
    "order.anatomy",
    "confirmed_observation.anatomy"
  ],
  "evaluation": {
    "missing_or_ambiguous": "UNKNOWN",
    "excluded_scope": "NOT_APPLICABLE",
    "matching_values": "PASS",
    "conflicting_values": "FAIL"
  },
  "action": {
    "FAIL": "authorized_clinical_review_required",
    "UNKNOWN": "request_clarification",
    "execution_error": "technical_alert_not_pass"
  },
  "override": {
    "allowed": true,
    "role": "authorized_signer",
    "reason_required": true
  },
  "provenance": {
    "source": "hospital_approved_policy_required",
    "approval_record": "must_be_resolved_before_production"
  }
}

检索增强生成的实际控制

检索顺序建议为：权限过滤 → 项目、模态、人群、场景和有效期过滤 → 关键词与语义联合检索 → 重排 → 证据条款核对。模型只能使用核实通过的片段形成草稿，并输出引用。搜索相关不等于医学适用，语义相似也不等于同一检查方法。

模板组织优先按“检查项目＋临床场景＋必要观察集合”配置，而非为每一种自由文本创建一个模板。图谱主要表达检查—部位—征象—分级—证据—建议之间的受控关联；初期可用关系表实现，确认多跳检索确有价值后再引入图数据库。

参考技术组合

以下是便于研发落地的参考组合，不是指定厂商，也不是已验证可直接临床部署的软件包。应先核查许可、现有系统兼容性、终端性能和运维能力，再冻结组件及版本。

开发顺序：先可运行的业务骨架，再扩智能能力

报告生成管线

进入报告任务时，读取特定版本的申请、影像清单、已确认观察、医生文本与模板。先确定必需段落和缺项，再产生文字草稿；独立校验器检查结构、引用、数值、单位、否定和侧别。验证未通过时可以在限定次数内修复格式，但不能通过添加未经证实的事实“修复”临床缺项。最终内容进入可编辑草稿，由医生按工作流程确认。

图像模型管线

适用性判定 → 检查输入清单及图像可解码性 → 按已验证配置预处理 → 推理 → 后处理 → 空间坐标回映 → 输出结构与单位校验 → 保存源结果和候选观察。输入尺寸改变、重采样、裁剪及坐标变换须记录。检测结果为空仍需要有效完成状态和模型覆盖说明。

有限智能体循环（示意伪代码）

context = load_authorized_snapshot(task.patient_id, task.input_version)
if not eligible(task, context):
    finish_as_not_applicable_or_missing_input()
else:
    for step in range(task.max_steps):
        enforce_deadline_and_budget(task)
        proposed_call = plan_next_allowed_tool(context)
        result = call_tool_after_policy_check(proposed_call)
        store_provenance(result)
        checked = validate_schema_evidence_and_business_rules(result)
        if checked.ready_for_review:
            save_candidate(checked, input_version=task.input_version)
            create_review_task_if_required()
            break
    else:
        finish_as_incomplete_and_route_to_human()
# 报告签发、医嘱变更和对外临床发布不由此循环直接执行。

不要在未限定适用范围之前决定模型大小和型号。选型以目标任务的本地测试为依据，分别检查影像算法、人机团队、结构化抽取、规则检索、中文报告与复杂异常，不以通用榜单或更大参数量替代验证。

部署模式

物理部署建议

最小生产结构分为接入区、临床业务区、影像数据区、AI计算区、管理与审计区、对外服务区。临床数据库与GPU推理不共用同一故障点；AI网络拥塞和显存耗尽不能拖垮图像接收。数据高可用采用适合规模的冗余方式，备份隔离保存并定期恢复。研究与训练在独立环境运行，生产数据进入其中须经过用途与权限控制。

容量测算示例：只演示计算方法，不指定保留年限

假设首年平均每日1,000次检查，每次归档影像平均300 MB，每年增长15%，用于容量估算的窗口为3年；派生数据增加20%，主存储采用2份副本，规划使用率上限80%。以下按十进制GB/TB计算，未包含独立备份、研究副本、日志和训练集。这个3年窗口不是病历或影像保存期限建议。

实际采购前，按CT、MR、DR及其他模态分别抽样，测量大检查、薄层、动态序列、压缩比例和历史回迁量。GPU型号与数量还取决于模型显存、上下文、批处理、并发、多模型共驻及P95/P99时延，应以代表性负载压测确定。

建议服务目标：需经基线测量与合同确认

分级降级与恢复

系统上线前按具体功能、预期用途和使用方式进行合规确认，而不是用“仅供参考”标签替代责任与验证。正式诊疗、科研验证、教学展示、患者说明采用不同的权限与发布路径。平台集成第三方产品时，还须确认原产品的获准用途、输入和输出没有被集成方式实质改变。

法律与管理依据：个人信息保护法将医疗健康信息列入敏感个人信息，处理应满足相应条件；国家卫生健康委2025年电子病历信息使用管理通知强调分级访问、最小可用、服务商授权和全流程可追溯。本方案将这些要求落实为用途、字段、岗位及审计的技术控制，不替代具体法律适用审查。[16][18]

医院数据、患者权益、厂商软件和背景技术不是同一种权利。合同应分别明确医院对临床记录的控制与获取、标准格式迁出、配置与自建知识的使用权、厂商背景知识产权、第三方术语许可、服务终止后的返还与删除；不笼统宣称“全部数据和算法所有权均归一方”。

验证对象包括基础RIS/PACS、数据链路、单个模型、知识规则、岗位体验和人机团队。IMDRF的GMLP原则强调适用人群、独立测试、合适参照、临床环境下的人机表现以及部署后的监测。本方案据此安排分层验证，而不只看模型离线分数。[21]

上线门槛与发布流程

影子运行能够检查接口、输出、时延和初步一致性，但不能证明医生实际使用后的收益。涉及临床诊断、分诊或高后果建议的功能，还需匹配风险与监管要求的临床评价和院内准入。未满足条件的模块保留在研究环境，不通过修改界面标签混入正式工作。

参照标准与抽样

按患者及必要的机构、时间边界切分训练与测试，防止同一患者的相近检查泄漏。抽样既包含分歧大、低置信和边缘输入，也包含具有代表性的普通病例，尤其关注人和AI都没有提示但实际有问题的病例。病理、随访、专家仲裁和单医生确认的证据强度不同，分别标注，不简单视作同等真值。

AIRA支持记录和交换AI结果评估，但其范围不包含保证评估结论正确的过程。因此接受、修改、拒绝等操作记录可用于运营反馈，却不能未经复核直接当作训练标签或总体准确性证明。[13]

反馈如何真正进入改进

反馈整理 → 去除身份或关联错误 → 按问题分类 → 临床复核与参照分级 → 区分规则、模板、模型、数据和交互原因 → 形成变更 → 回放已冻结的测试集 → 更新独立验证 → 获准后发布。线上观察到的好坏不直接驱动自动调权重。重大安全信号可以按预先批准的策略立即停用受影响功能，恢复需再次确认。

按“先具备完整临床业务骨架，再扩展经过验证的AI场景，最后规模复制”的次序实施。参考周期为12个月，前提是接口和数据可获得、院内责任团队到位、选定组件可复用。采购、注册或临床评价所需时间独立排入计划，不能靠压缩试用期消化。

不同交付包清楚区分

前90天的工作包

前4周完成现状与接口验证、标准目录和目标状态机；第5—8周打通一条影像检查的完整人工业务链，建立数据版本和影像入口；第9—12周在非临床或获准测试环境接入首个AI任务，验证候选确认、失败退出和标准回写。90天目标是可验证的系统骨架和场景，不是宣称完成全部临床产品或所有注册流程。

切换与迁移

先进行历史数据盘点，区分全量影像迁移、索引统一与按需历史回迁。按院区、设备或亚专科安排切换窗口；每个窗口只保留一个明确的业务权威写入源，避免两套系统并行重复登记。切换前演练接收、报告、重要结果及回退；切换后逐日对账检查数、实例数、报告状态和费用事件。旧系统转为只读或退出须达到预先约定的数据与连续性标准。

验收由功能、互操作、性能、安全、临床使用、可运营和可退出七部分组成。以下为待执行的验收设计，不是已完成测试结果。所有指标必须明确适用范围、分母、时间起止、测试环境、样本量和排除原因。

30项端到端验收用例

国家卫生健康委已发布2024年版放射影像专业医疗质量控制指标。项目可将适用指标纳入运营与质控服务，但其具体定义、分母和统计周期应按正式附件配置；本方案不以自行设计的KPI冒充国家规定阈值。[15]

责任分工

任何AI或规则版本的上线、停用和恢复都由明确权限控制。研发和测试不能自行批准临床准入；平台运营人员不能修改医生已经签发的临床内容。需要紧急停用时按预授权预案执行，并补齐审核与复盘。

持续运营节奏

投入分成建设成本与持续运营成本

建设成本包括业务软件或组件集成、接口与迁移、存储及网络、诊断终端、AI算力、知识工程、验证与培训。持续成本包括归档增长、备份、模型或软件许可、算力消耗、知识维护、临床复核、运维与合规。开源组件可以减少部分基础开发，不等于企业级系统无许可义务、无集成成本或无临床验证成本。

年度总拥有成本 = 软件与设备年度摊销
               + 运维与支持 + 备份与存储增长
               + 推理资源与模型许可
               + 知识维护与临床验证 + 集成及合规费用

可核实效益 = 可转化的时间价值 + 可归因的流程成本减少
           + 可验证的资源利用改善

净效益 = 可核实效益 - 新增总成本
# 减少的阅片分钟不自动等于现金节省，也不应与新增检查收入重复计入。

团队至少覆盖产品与流程、RIS业务、DICOM与阅片、后端与数据、AI与评测、知识工程、测试、运维安全及临床代表。可以一人承担多个职责，但身份安全、临床规则、影像显示、数据迁移和上线验证不得成为无人负责的空白。医院需为专家复核和规则维护预留实际工作时间。

建议工程目录

ris-pacs-platform/
  apps/                   # 岗位工作台、诊断阅片、患者视图
  services/
    identity-catalog/     # 身份、检查项目与来源映射
    order-scheduling/     # 申请、预约与执行任务
    imaging-gateway/      # DICOM接入、完整性与对账
    observation-report/   # 观察、报告、审核与更正
    clinical-workflow/    # 重要结果、随访与责任任务
    knowledge-rules/      # 术语、规则、证据和模板
    ai-orchestration/     # 适用性、任务、版本及预算
    analytics-audit/      # 指标、查询、审计与运维
  adapters/               # 模态、HIS/EMR、模型与区域适配器
  contracts/              # API、事件Schema、FHIR Profile与示例
  scenario-packs/         # 经审核的场景包，不存生产患者数据
  validation/             # 去标识测试、合约、安全与临床验证脚本
  deployment/             # 环境、监控、备份和恢复配置
  docs/                   # 用途、风险、操作、运维、接口与验收资料

目录表示逻辑边界，不要求每个目录各部署一套集群。受控场景包应包含：适用范围、输入清单、模型配置、规则模板、交互流程、异常策略、测试数据要求、评测结果和上线批准。这样复制的是完整临床工作能力，而不只是复制模型名称与提示词。

建议的应用API契约

以下JSON是本方案的内部领域对象示意，不是可直接提交的FHIR资源或完整DICOM对象。所有标识与测量均为演示数据，不包含真实患者；实际实现需增加认证、字段校验、版本兼容、可靠签名及必要标准映射。

候选观察对象

{
  "observation_id": "demo-observation-001",
  "patient_ref": "demo-patient-001",
  "study_uid": "2.25.123456789012345678901234567890123456",
  "input_manifest_version": "manifest-3",
  "status": "CANDIDATE",
  "concept": {
    "system": "local-demo",
    "code": "lung-nodule",
    "display": "肺结节候选"
  },
  "measurement": {
    "value": 8.2,
    "unit": "mm",
    "method": "demo_long_axis",
    "uncertainty": "not_established"
  },
  "evidence": [
    {
      "series_uid": "2.25.123456789012345678901234567890123457",
      "sop_instance_uid": "2.25.123456789012345678901234567890123458",
      "frame_number": 1,
      "geometry_ref": "demo-geometry-001"
    }
  ],
  "provenance": {
    "source_type": "AI",
    "model_id": "demo-model",
    "model_version": "demo-1",
    "preprocessing_version": "demo-1",
    "created_at": "2026-10-11T10:00:00+08:00"
  },
  "confidence": {
    "score": null,
    "meaning": "not_provided",
    "calibration_version": null
  },
  "assessment": {
    "status": "NOT_EVALUATED",
    "reviewer": null
  },
  "limitations": [
    "演示对象，不构成诊断",
    "未经医生确认",
    "不据此自动生成随访或治疗建议"
  ]
}

影像输入更新事件

{
  "event_id": "demo-event-002",
  "event_type": "imaging.manifest.updated",
  "schema_version": "1.0",
  "aggregate_id": "demo-study-001",
  "aggregate_version": 3,
  "occurred_at": "2026-10-11T10:05:00+08:00",
  "source": "imaging-gateway",
  "correlation_id": "demo-workflow-001",
  "payload": {
    "previous_manifest": "manifest-2",
    "current_manifest": "manifest-3",
    "reason": "late_series_arrival",
    "report_status": "SIGNED"
  },
  "required_behavior": [
    "mark_previous_input_jobs_as_potentially_stale",
    "create_authorized_review_task_if_needed",
    "do_not_overwrite_signed_report"
  ],
  "privacy_note": "消息仅传必要引用；消费方取数时再次鉴权"
}

重要工程约束

事件表示已经发生的事实，不等于执行命令。消息可能重复或乱序到达，消费方使用事件ID与聚合版本去重，并在业务提交时复核状态；需要外部通知时使用单独的幂等业务键。取消AI任务是取消未来工作，不删除已经存在的临床记录。回放日志可以重建索引和观察历史，但不能无审查重复执行给药、签发或消息发送。

术语速查

本方案为独立产品定义与建设设计。正文中的“应”“必须”“建议”描述本方案的设计约束或拟议验收条件；只有明确引用的标准与政策事实才来自相应资料。模块划分、流程、对象模型、参考架构、容量假设、SLO和实施周期由本方案提出，不是现成产品已经实现的证明。

资料核查日期：2026年10月11日。已选择官方标准、监管与卫生管理渠道及组件原作者文档。标准、政策、接口和许可在正式签约与上线时应重新核查，并固定适用版本；未逐条读取或确认的附件不用于推导具体临床阈值。