三甲医院医疗AI代码库管理系统研究（上）

三甲医院医疗人工智能程序代码库管理系统研究报告

[第一章摘要](#第一章摘要)
[第二章概念界定与研究范围](#第二章概念界定与研究范围)
[第三章建设背景与驱动因素](#第三章建设背景与驱动因素)
[第四章现状调研与核心痛点](#第四章现状调研与核心痛点)
[第五章政策监管与合规要求](#第五章政策监管与合规要求)
[第六章需求分析](#第六章需求分析)
[第七章系统总体架构设计](#第七章系统总体架构设计)
[第八章核心功能模块详细设计](#第八章核心功能模块详细设计)
[第九章关键技术选型与信创适配](#第九章关键技术选型与信创适配)
[第十章安全治理体系设计](#第十章安全治理体系设计)
[第十一章国内外典型案例分析](#第十一章国内外典型案例分析)
[第十二章挑战、风险与应对策略](#第十二章挑战、风险与应对策略)
[第十三章建设路径与实施建议](#第十三章建设路径与实施建议)
[第十四章发展趋势展望](#第十四章发展趋势展望)
[第十五章结论](#第十五章结论)
[附录一术语表](#附录一术语表)
[附录二制度建设清单建议](#附录二制度建设清单建议)
[附录三主要参考来源](#附录三主要参考来源)

第一章摘要

1.1 研究缘起

2025 年以来，以 DeepSeek、Qwen 等为代表的开源大模型在中国医疗行业出现规模化落地浪潮。据公开报道，全国已有上千家医院宣布完成 DeepSeek 开源模型的本地化部署，应用场景覆盖医学科研、辅助诊断、病历质控、智能导诊、医院运营管理等诊疗与管理全流程。头部三甲医院更是从「部署通用大模型」走向「自研专科大模型」：上海交通大学医学院附属瑞金医院联合华为发布病理大模型 RuiPath，将单张病理切片诊断时间从约 40 分钟缩短至秒级；四川大学华西医院发布「华西黉医」医学大模型，并打造 HAIP（Hospital AI Platform）医院 AI 操作系统；复旦大学附属中山医院联合上海科学智能研究院发布国内首个心血管领域 AI 大模型「观心」（CardioMind），并提出建设「AI 原生医院」；北京儿童医院联合百川智能推出 AI 儿科医生。国家卫生健康委《卫生健康行业人工智能应用场景参考指引》（2024 年 11 月）明确了 4 大类 84 项应用场景，截至 2025 年 3 月全国已征集应用案例 950 项，实现 84 项场景全覆盖。

AI 应用数量、迭代频率、参与主体（信息科、临床科室、科研团队、外部厂商、高校团队）同时激增，使医院信息部门的治理对象发生了根本变化：过去管理的是 HIS、EMR、LIS、PACS 等少数成熟商业软件；现在要管理的是一个持续生长、多方共建、快速迭代的 AI 程序资产体系------包括 AI 应用源代码、模型权重文件、训练与推理框架、语料数据集、标注数据、提示词模板、智能体编排定义等新型资产。传统的 U 盘拷贝、共享目录、Excel 登记、厂商代管等代码管理方式，在版本追溯、协同开发、安全审计、注册合规四个维度上全面失效。

「医疗人工智能程序代码库管理系统」正是在这一背景下应运而生的基础设施级命题。本报告围绕三甲医院如何规划、建设和运营这样一套系统展开系统研究。

1.2 核心结论

第一，系统定位。 该系统是医院 AI 能力的「资产底座」与「合规引擎」，本质是 Git 代码托管、CI/CD 流水线、制品库、模型注册中心（Model Registry）、数据/语料版本管理、SBOM 与开源治理、安全审计的一体化平台。它向上支撑医院 AI 中台/开发平台，向下对接信创算力环境，向外对接监管检查与注册申报。其设计的最高纲领是回答一个问题：任何一次临床输出，都能回溯到具体版本的模型、数据与代码。

第二，监管是硬约束而非可选项。 国家药监局《医疗器械软件注册审查指导原则（2022 年修订版）》将配置管理、可追溯性分析贯穿软件全生命周期，要求源代码追溯分析追溯至软件单元、全部源代码均需测试、软件版本命名规则须与质量管理体系一致；《人工智能医疗器械注册审查指导原则》区分算法驱动型更新与数据驱动型更新并据此判定重大/轻微软件更新，要求训练集、调优集、测试集两两无交集，明确持续学习/自适应学习不得用于临床。国家卫生健康委等五部门《关于促进和规范「人工智能+医疗卫生」应用发展的实施意见》（国卫办规划发〔2025〕30 号）要求医疗卫生领域大模型规范备案、建立大模型应用评测验证与穿透式监管、建立临床数据授权运营管理制度、制订数据安全管理和个人信息保护负面清单。这些要求最终都需要一套代码库管理系统作为技术载体来落地。

第三，信创是现实路径且已被验证。 《中国数字医学》2026 年刊载的《基于信创环境的医院软件代码管理平台构建》提供了完整蓝本：以 GitLab 社区版为核心，基础设施层采用海光芯片服务器、中科方德操作系统、达梦数据库（DM8）、腾讯 Tendis 中间件，依托容器云实现应用与底层软硬件解耦。平台实际部署后，代码版本冲突率降低 68%，协同开发效率提升 55%，核心业务系统代码合规率达 100%，新成员环境配置时间从 4 小时缩短至 1 小时。全栈国产化建设医疗代码管理平台在技术上是可行的、在成效上是显著的。

第四，供应链安全已从行业倡议变为监管动作。 以四川省卫生健康委员会《关于开展 2026 年全省医疗机构软件供应链安全评估工作的通知》为代表，监管部门要求医疗机构摸清第三方/开源组件底数、合规生成标准化 SBOM（国标强制交付项）、依托 SCA 技术排查高危漏洞与许可证风险、输出符合监管检查标准的评估报告。SBOM/SCA 能力必须从「外购服务」内化为代码库管理系统的内建功能。

第五，建设路径建议。 按「统一托管 → 工程规范 → 资产注册 → 治理运营」四阶段演进：第一阶段将存量代码与 AI 程序全部纳入信创 Git 平台统一托管；第二阶段建立 CI/CD 与安全扫描门禁、制品库与 SBOM 能力；第三阶段建设模型注册中心与数据/语料版本管理，形成全院 AI 资产台账；第四阶段以 AI 治理委员会为核心实现常态化治理运营，并向医联体输出。治理组织建设与合规要求内建（Policy as Code）是成败关键。

1.3 报告结构

第二章界定管理对象与研究范围；第三章分析建设背景与驱动因素；第四章梳理现状与痛点；第五章系统梳理五条监管线索；第六章给出功能性与非功能性需求分析；第七章提出「一个底座、五大平面」总体架构；第八章对九大核心模块进行详细设计；第九章对比技术选型并给出信创适配方案；第十章设计安全治理体系；第十一章剖析国内外典型案例；第十二章分析挑战与风险；第十三章给出四阶段实施路线、预算估算与 KPI 体系；第十四章展望发展趋势；第十五章总结结论。附录提供术语表、制度清单建议与参考来源。

第二章概念界定与研究范围

2.1 定义

本报告所称「医疗人工智能程序代码库管理系统」（以下简称「代码库管理系统」或「本系统」），是指部署于医院内部数据中心或医疗专有云、对医疗 AI 相关数字资产进行统一存储、版本控制、协同开发、安全审计与合规治理的平台系统。它既是一种技术基础设施（代码托管 + 工程流水线 + 资产注册），也是一套治理机制的载体（权限、审批、审计、合规证据链）。

需要强调三个边界：

它不是通用研发管理工具的简单落地。 通用 DevOps 平台管理的是「代码 → 构建 → 部署」的线性流程；医疗 AI 代码库管理系统管理的是「数据 + 代码 + 算力 → 模型 → 临床输出 → 反馈数据」的循环流程，资产种类更多、血缘关系更复杂、合规要求更高。
它不是医院 AI 中台的全部，而是其底座。 AI 中台/开发平台（如重医附一院 AI 开发服务平台、华西 HAIP）面向用户提供标注、训练、推理、低代码编排等能力；代码库管理系统在底层承接源码、模型、语料、制品的沉淀与治理。二者可以一体化采购，但治理功能不可缺位。
它不等同于数据治理平台。 数据治理（主索引、数据质量、数据安全）是医院信息化另一条主线；本系统只管理与 AI 程序资产直接相关的数据版本与血缘（训练集、语料、标注），并与数据治理平台对接而非替代。

2.2 管理对象：五类资产

资产类别	具体内容	管理要点	失效风险示例
源代码	自研 AI 应用、智能体、接口服务、数据处理与标注脚本、低代码编排产物	分支策略、代码评审、版本标签、提交追溯	厂商交付后源码散落个人电脑，升级无人可维护
模型资产	基础大模型（DeepSeek、Qwen 等）、微调模型、专病小模型（病理、影像、心电）、Embedding/Rerank 模型、传统机器学习模型	模型注册、版本血缘、评测报告、上下架审批、退役管理	「final_v3_改.pt」式流传，线上跑的是哪个版本无人知晓
数据与语料	训练集/调优集/测试集、标注数据、知识库语料、RAG 索引、Prompt 评测集	脱敏、分级（如 S0--S3）、版本化、血缘追踪、集间隔离校验	训练数据混入测试集导致「假性性能」，注册申报被发补
依赖与制品	开源组件、容器镜像、推理框架（vLLM 等）、训练框架（PyTorch 等）、驱动与算子库	SBOM、SCA 漏洞扫描、许可证合规、制品签名	高危 CVE 组件上线，供应链安全检查不合格
配置与提示词	Prompt 模板、智能体编排流程定义、环境配置、密钥与证书	版本管理、变更审计、密钥托管	Prompt 被随意修改导致临床输出漂移且无法回溯

2.3 与传统医院代码管理的根本区别

传统代码库只回答「代码在哪、谁改了什么」；医疗 AI 代码库管理系统还必须回答三组问题：

可追溯性问题：哪个版本的模型 + 哪份数据 + 哪段代码 + 哪组参数产生了这次临床输出？这是 NMPA 可追溯性分析要求在 AI 场景的具体化。
可复现性问题：半年后监管核查或不良事件调查时，能否在隔离环境中完整复现当时的训练与推理过程？这要求代码、数据、环境（镜像）三位一体版本化。
可治理性问题：全院有多少 AI 模型、各是什么版本、跑在哪些系统、用了哪些开源组件、经过什么审批、是否仍在使用？这要求统一资产台账与生命周期状态机。

2.4 研究范围与方法

本报告研究范围覆盖：管理对象与需求分析、政策合规要求、系统架构与模块设计、技术选型与信创适配、安全治理体系、典型案例、风险与实施路径。不覆盖：具体 AI 算法研究、临床有效性评价、医院数据治理总体设计（仅讨论接口关系）。研究方法为公开资料研究法：法规政策文本分析、行业文献综述、公开采购文件分析、典型案例归纳与国际经验对标。

第三章建设背景与驱动因素

3.1 医疗 AI 应用的爆发式增长

从单点工具到平台化建设。 2020---2023 年，医院 AI 应用以单病种影像辅诊、单科室 CDSS 等单点采购为主，AI 程序数量少、迭代慢，管理方式尚可依赖厂商代管。2024---2026 年，三个变化同时发生：

大模型本地化部署浪潮。 DeepSeek 等高质量开源模型的出现，使医院第一次拥有了可私有化部署、可自主微调的通用智能底座。公开报道显示已有上千家医院完成本地化部署，各地移动运营商、华为、科大讯飞、蚂蚁等纷纷推出医疗大模型一体机，单台价格从数十万元到数百万元不等。
头部医院自研深水区。 瑞金 RuiPath 基于上百万病理切片训练，覆盖中国每年全癌种发病人数 90% 的常见癌种；华西黉医融合 PB 级原始影像数据和 250 余万条病历数据；中山「观心」输入数十万份心内科电子病历与医生诊疗逻辑；仁济医院联合蚂蚁构建国内首个泌尿外科临床专科推理数据集。自研意味着源代码、数据、模型全部成为医院自有资产，管理责任随之内生化。
场景全面铺开。 国家卫健委 84 项应用场景指引覆盖医疗服务管理、基层公卫服务、健康产业发展、医学教学科研四大方面；五部门 30 号文进一步明确到 2027 年「形成一批临床专病专科垂直大模型和智能体应用」、到 2030 年「二级以上医院普遍开展医学影像智能辅助诊断、临床诊疗智能辅助决策」。AI 程序从个位数增长到几十上百个，是三甲医院的确定性趋势。

管理复杂度的非线性上升。 AI 程序的管理复杂度远高于传统软件：模型随数据持续迭代（数据飞轮），同一应用可能存在多个并行版本（多科室微调），参与方多元（院内多科室 + 多厂商 + 高校），运行环境异构（CUDA/NPU、x86/ARM）。瑞金医院病理科即融合了商汤科技、衡道医学等多家公司的 AI 软件。没有统一代码库管理系统，复杂度将以失控方式增长。

3.2 政策与评级体系的多重驱动

顶层战略牵引。 国务院《关于深入实施「人工智能+」行动的意见》（国发〔2025〕11 号）将「人工智能+」上升为国家行动；五部门《关于促进和规范「人工智能+医疗卫生」应用发展的实施意见》（国卫办规划发〔2025〕30 号）是行业落地的纲领性文件，其中三处与代码库管理系统直接相关：一是「推动医学人工智能开源软件建设，持续提升共建共享水平」；二是「推动医疗卫生领域大模型规范备案，优化人工智能应用审核程序」；三是「建立大模型应用评测验证，从医疗质量安全、个人隐私和数据安全等方面开展穿透式监管，加强动态监测和预警」。备案、评测、穿透式监管的共同前提是医院自己先「说得清、查得到」其 AI 资产。

注册监管倒逼。 NMPA 数字医疗指导原则体系（详见第五章）对软件版本控制、配置管理、可追溯性分析提出了可核查的具体要求。对计划将自研 AI 申报医疗器械注册证（二类/三类）的医院及其合作企业而言，代码库管理系统产生的版本记录、测试记录、追溯关系表就是注册申报资料的直接来源。

数据合规趋严。 《数据安全法》《个人信息保护法》《人类遗传资源管理条例》、GB/T 39725《健康医疗数据安全指南》、TC260《网络安全标准实践指南------人工智能应用安全指引·卫生健康》（2026 年发布）共同构成数据与 AI 应用安全框架，要求训练数据来源合法、处理最小必要、脱敏到位、伦理审查完备、出境受控。

信创转型要求。 医院信息系统国产化替代稳步推进，代码管理平台本身作为承载全院核心软件资产的系统，须率先完成信创适配（国产芯片、操作系统、数据库、中间件），《中国数字医学》2026 年文献已给出验证路径。

供应链安全监管。 省级卫健委开始组织医疗机构软件供应链安全评估，要求 SAST/SCA 检测、SBOM 交付、开源许可证核查、停服组件排查，并与等级保护、关基台账核查联动（详见第五章第五节）。

3.3 医院自身治理诉求

头部三甲医院的 AI 建设模式正在从「单点采购」转向「平台化自主可控」，标志性事件是重庆医科大学附属第一医院 2026 年公开推介的「AI 开发服务平台项目」。该项目目标明确为「构建一个自主可控、开放协同、安全高效的医院级人工智能研发与开发平台」，要求建成集标注管理、推理调度、脱敏处理、知识语料构建、模型训练、低代码开发、测试部署发布于一体的 AI 基础平台，并提出两项与代码库直接相关的技术要求：「具备源码级模块、功能嵌入能力」和「支持用户自由拖拽、组合智能体节点及 skill 工具，形成可追溯的医疗 AI 决策链条」。此外还提出「通过技术授权等形式，将成熟的 AI 智能体或小模型进行商业化转化」------资产商业化转化的前提同样是资产权属清晰、版本可查、质量可证。

换言之，医院已经从实践中意识到：没有统一的代码库与资产管理系统，平台化 AI 建设无从谈起；没有资产治理，AI 资产就无法沉淀、复用与转化。

第四章现状调研与核心痛点

4.1 医院代码与 AI 资产管理现状素描

综合行业文献、公开报道与采购文件，当前三甲医院在代码与 AI 资产管理上大体呈现三种形态：

形态一：厂商代管为主（多数中小型医院与部分三甲）。 HIS/EMR 等核心系统由厂商持有源码，医院仅有使用权；AI 应用按项目采购，源码、模型由厂商维护。医院内部几乎无代码管理概念，更无 AI 资产台账。风险是资产完全受制于厂商，一旦厂商经营异常或合作终止，系统演进与安全维护立即陷入困境。
形态二：分散自管（多数三甲医院现状）。 信息科有少量自研系统，使用开源 GitLab 或 SVN 简单管理，但覆盖不全；临床科研团队各自使用 GitHub/Gitee 公有云账号甚至个人电脑存码；AI 模型以文件形式在 GPU 服务器之间拷贝流传；厂商交付的源码入不入库全凭项目要求。管理呈现「有工具、无体系」特征。
形态三：平台化治理（少数头部医院）。 以华西 HAIP、中山「AI 原生医院」、重医附一院 AI 开发服务平台为代表，开始建设统一的 AI 研发与资产底座，并将算力、数据、模型、智能体纳入平台化管理。该形态仍处于早期，且多数平台的「治理」能力（版本血缘、合规证据、供应链安全）弱于「研发」能力。

4.2 核心痛点：「四缺失、一错位」

痛点一：版本控制缺失。 代码分散在厂商交付包、个人电脑、共享目录；模型以「final_v3_改.pt」方式命名流传；Prompt 在业务系统后台被直接修改。直接后果是版本冲突频发、问题无法回溯、同一科室不同人员使用的「同一个模型」实际不是同一个文件。更严重的后果在合规侧：NMPA 要求软件版本命名规则与质量管理体系一致、版本变更可追溯，散乱状态根本无法满足。

痛点二：协同机制缺失。 信息科、临床科研团队、外部厂商、高校合作团队多方开发没有统一入口，没有代码评审与合并流程，没有统一的依赖与环境标准。后果是重复建设（多个科室各自采购/自研相似功能）、质量参差（无评审的代码直接上临床）、知识产权归属不清（多方共建成果权属模糊，影响后续转化）。

痛点三：安全审计缺失。 无统一权限体系与操作留痕；源代码随外包项目外流且无从核查；数据库口令、API 密钥硬编码在脚本中并随代码外传；离职/离场人员权限未及时回收。医院核心系统的源代码本身就是高价值攻击目标（可从中分析系统漏洞、窃取数据接口），《中国数字医学》文献将「代码存储安全隐患突出，存在泄露、篡改与未授权访问风险」列为传统模式三大痛点之一。

痛点四：资产台账缺失。 全院有多少 AI 模型、各是什么版本、部署在哪些系统、训练用了什么数据、依赖哪些开源组件、是否经过伦理审查与备案------没有一个部门能完整回答。这在穿透式监管、供应链安全检查、不良事件调查三种场景下都是致命的。模型漂移、性能退化、超范围使用也因无台账而无人负责、无人发现。

痛点五（错位）：重硬件轻体系的投入错位。 行业报道直言，不少医院采购的大模型一体机「用不起来，放在一边积灰」------因为「AI 病历那些重信息化开发，并不是买一个一体机就能解决问题的」。把 AI 建设等同于「买算力 + 部署模型」，忽视了工程体系（代码、流水线、数据准备）与治理体系（权限、审批、评估）才是价值产出的主体，是当前最普遍、代价最高的认知错位。

4.3 量化佐证

《中国数字医学》（2026, 21(5):114-120）对某医院基于信创环境的软件代码管理平台建设前后的实证对比，是目前国内该领域最完整的量化证据：平台建设针对的正是「版本控制缺失、协同开发效率低、代码存储安全隐患」三大痛点；平台上线后，代码版本冲突率降低 68%，协同开发效率提升 55%，核心业务系统代码合规率达 100%，新成员环境配置时间从 4 小时缩短至 1 小时，安全防护体系成功阻断源代码泄露和篡改风险。这一组数据为「代码库管理系统值得建、建得成」提供了直接证据。

第五章政策监管与合规要求

合规是医疗 AI 代码库管理系统区别于通用研发平台的最大特征。本章将与系统直接相关的监管要求梳理为五条线索，并逐条映射到系统能力。

5.1 线索一：NMPA 医疗器械软件监管（产品注册维度）

（1）《医疗器械软件注册审查指导原则（2022 年修订版）》------数字医疗指导原则体系的基础。核心要求包括：

基于风险的全生命周期管理。 软件安全性级别分轻微、中等、严重三级，级别越高生存周期质控要求越严格；风险管理、配置管理 、缺陷管理、可追溯性分析贯穿全程。配置管理与可追溯性分析正是代码库管理系统的核心职能。
可追溯性分析扩围。 由高风险软件扩至全部医疗器械软件；考虑到行业实际，源代码追溯分析活动追溯至软件单元（列明名称）即可。这意味着代码库必须支持「需求---代码单元---测试---风险」的关联记录。
全部源代码均需测试。 可采用多种测试方法实现------单元测试、集成测试、系统测试，白盒、黑盒、灰盒结合。CI/CD 流水线中的自动化测试记录是直接证据。
版本命名规则的严肃性。 注册申报资料所述软件版本命名规则需与质量管理体系保持一致；软件更新的版本变更需符合命名规则，不符合需采取纠正预防措施（CAPA）并记录。代码库的标签/分支策略即是命名规则的技术实现。
软件发布可重复性。 《医疗器械生产质量管理规范独立软件现场检查指导原则》要求软件发布形成文件，确定产品文件创建、归档备份、版本识别与标记、交付形式评估与验证等活动要求。制品库与镜像库的能力正对应于此。

（2）《人工智能医疗器械注册审查指导原则》（2022 年第 8 号）------AI 产品专属要求。对系统设计影响最大的四点：

算法更新分类管理。 算法驱动型更新（算法、结构、流程、编程框架、输入输出类型改变，或弃用原训练数据重新训练）通常属重大软件更新，应申请变更注册；数据驱动型更新（仅训练数据量增加）以算法性能评估结果是否发生显著性改变判定。代码库管理系统的模型注册中心必须完整记录每次更新的类型、原因、评估结果，形成判定证据链。
数据集隔离红线。 基础数据库、训练集、调优集和测试集必须严格分离（两两无交集），否则构成过拟合发补风险；审查员重点核查测评数据库的封闭性和样本分布。系统的数据版本管理模块应提供集间隔离自动校验能力，从流程上杜绝数据泄露导致的「假性性能」。
持续学习禁令。 持续学习/自适应学习不得用于临床，仅可用于算法训练或医学研究。系统须从技术上保证线上推理模型与训练环境的隔离，模型上线即「冻结」，任何变更走更新审批流程。
黑盒算法与泛化能力。 黑盒算法须开展算法性能影响因素分析、明确使用限制并在说明书提示；泛化能力须基于多中心、多层级机构数据验证，并提供压力测试、对抗测试报告。这些报告应作为模型版本档案的组成部分纳入模型注册中心。

（3）《医疗器械网络安全注册审查指导原则（2022 年修订版）》。网络安全能力由 19 项升级为 22 项，新增网络安全事件应急响应、漏洞评估、远程维护与升级、医疗数据出境、遗留设备等要求；网络安全研究资料按软件安全性级别区别要求。对应系统能力：漏洞情报联动、补丁版本管理、远程升级通道的审批与审计。

5.2 线索二：卫健委行业管理（机构应用维度）

（1）《卫生健康行业人工智能应用场景参考指引》（2024 年 11 月）。 明确 4 大类 84 项应用场景，是医院规划 AI 应用清单的框架；医院 AI 资产台账可对照 84 项场景分类组织。

（2）《关于促进和规范「人工智能+医疗卫生」应用发展的实施意见》（国卫办规划发〔2025〕30 号，2025 年 10 月）。 与本系统直接相关的规范要求：

大模型规范备案：推动医疗卫生领域大模型规范备案，优化人工智能应用审核程序；配合中央网信办开展医用生成式人工智能服务上线备案。备案所需的模型信息、评测材料可从模型注册中心直接产出。
穿透式监管：建立大模型应用评测验证，从医疗质量安全、个人隐私和数据安全等方面开展穿透式监管，加强动态监测和预警。「穿透」的对象正是模型---数据---代码的链条，没有代码库管理系统就无法自证。
临床数据授权运营管理制度：明确谁有权授权、谁能被授权、授权做什么、如何安全运营。系统的数据资产权限与审批流须与之对齐。
数据安全管理和个人信息保护负面清单：未经授权处理重要医疗健康数据、违规跨境传输、未获单独同意处理敏感个人信息、未完全匿名化情况下公开共享医疗信息等均为红线。系统应将负面清单转化为平台门禁（如未脱敏数据无法进入训练区）。
医学人工智能开源软件建设：政策明确「推动医学人工智能开源软件建设，持续提升共建共享水平」，为医院参与开源生态、同时做好开源治理提供了依据。

（3）《人工智能辅助治疗技术临床应用管理规范》（2022 修订）。 明确医疗机构、医务人员应用基本要求和数据管理要求，是临床应用侧的管理基线。

5.3 线索三：数据安全与个人信息保护

《个人信息保护法》：医疗健康信息属敏感个人信息，处理须取得单独同意、遵循最小必要、开展个人信息保护影响评估。训练数据的授权链条（知情同意或伦理豁免）应作为数据集档案的一部分纳入版本管理。
《数据安全法》：数据分类分级保护；重要数据处理者须定期开展风险评估。医疗数据普遍落入重要数据范畴。
《人类遗传资源管理条例》：涉及人类遗传资源（基因、组织样本及其信息）的采集、保藏、对外提供和开放使用须审批/备案。AI 训练涉及人遗数据时，代码库中的数据集血缘记录须能证明其合规来源，跨境协作场景尤甚。
GB/T 39725《健康医疗数据安全指南》：健康医疗数据全生命周期安全管理的技术基线。
TC260《网络安全标准实践指南------人工智能应用安全指引·卫生健康》（2026）：提出医生主导与 AI 辅助、患者知情与伦理合规、应用流程安全、场景化安全指引及卫生健康领域 AI 应用风险分级，并引用 GB/T 45654《生成式人工智能服务安全基本要求》、GB/T 45674《生成式人工智能数据标注安全规范》、GB 45438《人工智能生成合成内容标识方法》等配套标准。标注安全、生成内容标识均是系统落地要点。

5.4 线索四：等级保护与关键信息基础设施

三甲医院核心系统普遍按网络安全等级保护三级建设。代码库管理系统承载全院核心软件资产，自身应按等保三级建设与测评：身份鉴别（双因素）、访问控制（最小权限）、安全审计（日志留存六个月以上且防篡改）、数据完整性与保密性（加密存储与传输）、备份恢复。同时，供应链安全评估结果须满足省级督导、等级保护、关基台账核查要求。

5.5 线索五：软件供应链安全

以四川省卫健委《关于开展 2026 年全省医疗机构软件供应链安全评估工作的通知》为标志，供应链安全进入监管执行期。其对医疗机构的要求（引自医院采购公告）包括：

使用 SAST/二进制/应用包等多种方式对资产（软件业务系统）进行分析检测；
摸清医院业务系统第三方/开源组件底数，合规生成标准化 SBOM 软件物料清单（国标强制交付项）；
依托 SCA 开展多维度检测：排查开源组件高危 CVE/CNNVD/CNVD 漏洞；识别已停服、废弃不再维护的风险组件；核查开源许可证知识产权合规风险；输出风险分级整改清单；
统一输出符合省卫健委监管检查标准的 SCA 评估报告，满足省级督导、等级保护、关基台账核查要求。

对系统设计的含义：SBOM 自动生成（每次构建）、SCA 常态化扫描（代码入库时 + 定期 + 情报驱动）、许可证策略门禁、停服组件识别、监管格式报告一键导出，都应内建于代码库管理系统，而非依赖每年一次的外购评估服务。

5.6 合规要求到系统能力的映射总表

监管要求	出处	系统能力映射
配置管理、版本命名规则	NMPA 软件指导原则 2022	Git 分支/标签策略、发布管理、命名规则门禁
可追溯性分析（至软件单元）	NMPA 软件指导原则 2022	需求---代码---测试---风险关联追溯、追溯报告生成
全部源代码均需测试	NMPA 软件指导原则 2022	CI 自动化测试、测试报告归档
算法更新分类（重大/轻微）	NMPA AI 指导原则 2022	模型注册中心更新类型记录与审批流
训练/调优/测试集两两无交集	NMPA AI 指导原则 2022	数据集隔离自动校验
持续学习不得用于临床	NMPA AI 指导原则 2022	训练/推理环境隔离、模型上线冻结
大模型备案、穿透式监管	五部门 30 号文 2025	模型资产台账、备案材料导出、全链路血缘
数据安全负面清单	五部门 30 号文 2025	平台门禁（未脱敏数据不入训练区等）
等保三级	网络安全等级保护制度	2FA、RBAC、审计日志、加密、备份
SBOM 强制交付、SCA 评估	省卫健委供应链评估	构建期 SBOM 生成与签名、常态化 SCA、监管格式报告

第六章需求分析

6.1 用户角色与诉求

角色	核心诉求
信息科/大数据中心工程师	统一入口管理全院代码与 AI 资产；自动化流水线减轻运维负担；环境标准化
临床科研人员	低门槛获取算力、数据与模型工具；实验可记录、可复现；成果可沉淀
临床科室（使用方）	稳定可用的 AI 服务；问题可反馈、可追溯；知晓所用 AI 的版本与限制
厂商/外部合作团队	受控的开发接入；清晰的交付与验收边界；知识产权约定可执行
医务处/质控部门	AI 临床应用清单与风险评估；不良事件可回溯
伦理委员会	数据使用与模型试验的伦理审查记录可查
审计与监管对接人	一键产出等保、供应链检查、注册申报所需材料
院领导	AI 资产全貌、投入产出、风险态势可视化

6.2 功能性需求（摘要）

代码托管：Git 仓库、分支保护、合并请求、代码评审、Web IDE、大文件支持（Git LFS）。
流水线：构建、测试、扫描、打包、部署可视化编排；多环境（开发/测试/准生产/生产）分级发布；审批卡点。
制品与镜像管理：制品库、容器镜像库、依赖代理缓存（npm/Maven/PyPI/APT 等）、制品签名与校验。
模型注册：模型版本、血缘（代码 commit + 数据版本 + 参数 + 评测）、阶段流转（开发→验证→准生产→生产→退役）、审批签核、模型卡片。
数据与语料版本管理：Git-like 数据集版本化、血缘追踪、集间隔离校验、脱敏流水线、分级分类。
智能体与 Prompt 资产管理：Prompt 模板版本化与灰度发布；智能体编排定义纳入 Git（Agent as Code）；决策链条可追溯。
安全与合规：统一认证、RBAC、审计日志、秘密扫描、SAST/SCA、SBOM、许可证门禁、合规证据导出。
算力与运行对接：训练/推理任务提交、算力调度对接（昼推夜训）、模型服务发布与运行监控。
门户与可视化：资产台账门户、版本血缘图谱、治理驾驶舱。

6.3 非功能性需求

安全性：等保三级；数据不出院；日志留存 ≥6 个月；传输与存储加密。
可靠性：核心服务高可用；RPO ≤ 1 小时、RTO ≤ 4 小时（建议值）；每日备份、异地容灾可选。
性能：支撑全院 200+ 并发开发用户、单仓库 GB 级大文件、镜像库 PB 级扩展（建议值，按院规模调整）。
可维护性：容器化部署、版本可升级、与国产化软硬件解耦。
兼容性：x86/ARM 双架构；CUDA/NPU 双栈；兼容主流开源框架与国产自研框架。
可扩展性：从单院区到多院区、医联体「中心---边缘」架构平滑扩展。