医疗人工智能项目全生命周期管理系统：监管知识建模、工程实现与实证评估(下)

第六章 系统实现

本章回答一个核心问题：单文件离线架构如何在 808 行代码中完整落地，质量如何保障？本章结论先行：系统以原生 HTML/CSS/JavaScript 实现，代码按「样式---数据---逻辑---视图」四区段组织，判定、统计、门控等核心机制均为短小的纯函数；质量保障采用「静态语法校验 + 纯函数审查 + 双案例手工走查 + 输出转义审计」四道工序，实现与设计（第 3---5 章）保持逐函数可追踪。

6.1 技术选型与代码规模

系统实现采用「原生三件套」：HTML 结构层、内联 CSS 样式层、内联 JavaScript 逻辑层，无任何第三方库、框架、字体或图标依赖。总代码 808 行，其中：文档结构与样式约 140 行（HTML 骨架 20 行 + CSS 约 118 行），监管知识数据（REGS/WIZQ/STAGES/CATS/PCATS 五组常量）约 156 行，判定与统计逻辑约 50 行，视图渲染约 235 行，交互操作约 170 行，报告导出与示例数据约 70 行。

选型的依据在 4.2 节已论证（零依赖部署、无供应链风险、可维护性），此处补充一个实现层面的观察：本系统的复杂度重心在监管知识的密度而非交互的复杂度------156 行数据常量承载了 33 部法规约 90 项要点的全部知识，是全系统价值密度最高的区段；而交互模式仅有表单、列表、弹窗、勾选四类。复杂度分布决定了技术选择的合理性：用重量级框架承载四类简单交互，属于用复杂工具解决简单问题；而用纯数据结构承载监管知识，使知识维护者（医院法务/信息科）无需理解框架即可参与法规库更新。

6.2 代码结构：四区段组织

6.2.1 样式区段（1---118 行）

CSS 采用 CSS 自定义属性（:root 变量）定义主题色板------主色（蓝）、红（高风险/高优先级）、琥珀（中风险）、绿（低风险/完成态）、灰（辅助）------并按组件族组织：侧边栏与顶栏、统计卡片（.stat）、表格（.tbl）、徽章（.badge，按七领域 A---G 与风险 H/M/L、优先级 H/M 着色）、进度条（.prog）、阶段时间轴（.stage-tl/.stg）、标签页（.tabs）、法规卡片（.reg-card）、向导问题卡（.wiz-q）、判定结论块（.verdict）、弹窗（.modal）等。样式实现两个设计语言：语义化配色 （颜色仅表达风险/优先级/领域语义，不作装饰）与响应式降级（1100px 以下统计网格从四列降为两列）。总行数 118 行，靠「每组件一个类、无嵌套选择器堆叠」的纪律控制膨胀。

6.2.2 数据区段（140---312 行）：监管知识的载体

五组常量构成监管知识库：

var LSKEY='medai_pm_db_v1';
var STAGES=[/* 十段生命周期名 */];
var PCATS=[/* 九类项目类别 */];
var CATS={A:{name,desc},...,G:{...}};   // 七领域
var REGS=[{id,cat,pr,name,doc,by,ap,cond,items:[...]},...];  // 33部法规
var WIZQ=[{id,q,d},...];               // 七问（id/q/d 分别为标记、问题、说明）

REGS 是核心，其结构与第 3 章法规实体的八属性定义一一对应。数据区段的编写纪律有三：其一，字段顺序统一 （id→cat→pr→name→doc→by→ap→cond→items），33 条目格式完全一致，便于人工比对与批量校对；其二，适用条件双表达 ------ap 为机器谓词（'all' 或标记数组），cond 为人类可读说明（如「项目判定为按医疗器械管理时适用」），两者并存使法规库既可被程序求值又可被人审阅；其三，要点措辞遵循 3.3 节三规则（动作导向、可核验、粒度均匀）。

6.2.3 逻辑区段（314---383 行 + 621---767 行）：判定、统计与操作

逻辑区段包含三类函数。基础设施类 ：loadDb/saveDb（localStorage 读写）、addLog（审计留痕，unshift+500 条截断）、nowStr/esc/uid/getReg（时间、转义、标识、按 id 查法规）。纯函数类 ：regApplies（适用性谓词）、projStats（统计）、riskOf（风险分级）、verdictOf（四主线结论）------这四个函数是第 5 章机制的核心实现，均在 50 行以内。交互操作类：toggleCheck（勾选要点）、toggleNA（不适用标记，含确认与留痕）、saveRegNote（备注）、delProj（删除，含确认）、openProjectForm/saveProject（项目表单）、openStageModal/advanceStage（阶段推进）、startWizardFor/applyWizard（判定流程）、exportData/importData（JSON 备份）、exportReport（报告导出）、loadDemo（示例载入）。

6.2.4 视图区段（385---619 行）：render 分发家族

render() 为唯一渲染入口：先更新视图标题与导航高亮，再按 VIEW 值分发到 renderDash/renderProjects/renderDetail/renderRegs/renderWizard/renderLogView/renderSettings 七个视图函数。视图函数均为「拼装字符串 → 赋值 innerHTML」模式，所有用户数据插值一律经 esc() 转义（4.6 节不变式）。renderDetail 内嵌三个子标签（renderChecks 检查清单、renderVerdictTab 判定结果、renderStageTab 阶段记录），由 DTAB 变量控制。

6.3 关键代码解析

6.3.1 适用性谓词与统计（8 行实现一个知识引擎）

function regApplies(p,r){
  if(r.ap==='all')return true;
  return r.ap.some(function(f){return p.flags&&p.flags[f];});
}

这 4 行是整个「声明式法规挂载」的求值内核：无条件法规恒适用，条件法规在标记数组中任一标记为真时适用。配合 projStats 的遍历结构：

REGS.forEach(function(r){
  if(!regApplies(p,r))return;         // 谓词过滤
  var st=(p.checks&&p.checks[r.id])||{};
  if(st.na)return;                     // 不适用跳过
  r.items.forEach(function(it,i){
    total++; ...
    if(st.done&&st.done[i]){done++;}
    else if(r.pr==='H')ph++;           // 待完成高优先级累计
  });
});

统计与清单渲染、门控查询共用 regApplies------一个谓词函数在系统内被消费四处（清单渲染 renderChecks、统计 projStats、报告导出 exportReport、门控前置查询），这是「单一事实源」在代码层的直接体现。

6.3.2 状态管理：七个会话变量的最简方案

UI 会话状态仅七个全局变量：VIEW（当前视图）、PID（当前项目）、DTAB（详情子标签）、REGF/REGS_Q（法规库筛选与检索）、WPID/ANS（向导项目与答案）。每次操作函数执行完毕后调用 render() 全量重绘。这一「操作改状态 → 状态驱渲染」的单向流，用 7 个变量实现了框架所要解决的核心问题（状态一致性），且无任何抽象成本。向导状态 ANS 采用「标记名 → '1'/'0' 字符串」的扁平结构，七问完成度判定仅需一行：WIZQ.every(function(q){return ANS[q.id];})。

6.3.3 判定应用 applyWizard：机制咬合点

function applyWizard(){
  var p=...;                            // 定位目标项目
  p.flags={dev:ANS.dev==='1',...};       // 七问答案写入标记
  p.flags.medDevice=p.flags.dev;       // 派生器械标记
  p.verdict=verdictOf(p.flags).map(...); // 结论快照
  if(!p.stageHistory.some(function(x){return x.s===1;})){
    p.stageHistory.push({s:1,date:...,note:'完成合规分类判定'});
    if(p.stage<1)p.stage=1;            // 未过第2段则自动推进
  }
  addLog('应用合规判定',p.name+'（医疗器械路径：...）');
  saveDb();PID=p.id;DTAB='verdict';VIEW='detail';render();
}

该函数在 12 行内完成 5.4 节的全部四个动作（写标记、存快照、推进阶段、留痕），并以弹窗告知用户判定后适用法规数------「适用法规 N 部，请前往合规检查清单逐项落实」把用户从判定环节无缝导入落实环节。

6.3.4 报告导出 exportReport：从交互数据到监管文书

exportReport 以 window.open 新建窗口并 document.write 生成独立的打印版 HTML：报告头（项目元信息、风险等级、完成度）、监管路径判定（四主线结论）、按领域分组的监管要点清单表（每行：法规依据｜要点｜✅/⬜ 状态），尾注法规库版本与免责声明。实现要点有二：其一，导出数据的组装复用 regApplies 与 esc，与界面同源同转义；其二，不适用法规在报告中呈现为「不适用+理由」行而非隐藏------报告必须展示判定口径而非仅展示结果，这是面向监管检查场景的文书完整性要求。

6.3.5 阶段门控的查询实现

renderStageTab 中的三条规则查询（5.6 节 G1a/G1b/G2）以直白的条件表达式实现：

if(p.stage>=5){var e1=(p.checks&&p.checks.D1)||{};
  if(!(e1.done&&e1.done[0]))warn.push('已进入试点部署，但《伦理审查办法》首项...未勾选完成');}
if(p.stage>=7&&p.flags&&p.flags.medDevice){var e3=(p.checks&&p.checks.B1)||{};
  if(!(e3.done&&e3.done[1]))warn.push('按医疗器械管理但注册证核验项未完成，不得全院上线');}

以法规 id 与要点序号硬编码引用（D10、E20、B11）。该硬编码是全系统唯一的「下标耦合」，作为补偿，引用点集中于同一函数且配中文注释说明对应的法规要点语义，法规库维护纪律（3.3 节：要点只追加不插入）保证下标稳定。若后续法规库更新涉及这三部法规，此处为强制的回归测试点（见 6.5 节）。

6.3.6 输出转义函数 esc：一行安全不变式

function esc(s){return String(s==null?'':s)
  .replace(/&/g,'&amp;').replace(/</g,'&lt;')
  .replace(/>/g,'&gt;').replace(/"/g,'&quot;')
  .replace(/'/g,'&#39;');}

五个替换的顺序不可调换：& 必须最先替换，否则后续替换产生的实体（如 "）会被二次转义。函数首先以 String(s==null?'':s) 做空值归一（null/undefined → 空串），使所有调用点免于空值判断。该函数是 4.6 节「用户数据必转义」纪律的执行器，全系统共出现于二十余个插值点。

6.3.7 弹窗与确认交互的实现纪律

弹窗由 modal-root 单例容器实现：openModal 写入遮罩 + 内容，遮罩层点击（event.target===this 判定）与取消按钮均可关闭，Esc 键监听可作增强项。确认交互统一走原生 window.confirm/prompt------在单文件形态下，原生对话框相比自绘确认层的优势是无法被样式层绕过，且实现零成本；其可定制性损失（无法嵌入表单）由「确认 + 后续表单录入」两段式流程弥补（如不适用标记：先 confirm 确认意图，再 prompt 录理由，理由并入日志与检查状态）。

6.4 示例数据设计：内置双案例

loadDemo 载入与第 3、7 章一致的示例项目。S1 肺结节项目 预设：八条阶段历史（2025-03 立项至 2026-04 全院上线，含伦理批件号、等保三级备案、NMPA 注册证核验等里程碑备注）；标记 {dev:1, decision:1, research:1}；对 13 部代表性法规（A1/A3/B1/B2/B3/C2/D1/E1/E2/E3/G2/G3/G4）预置约 60% 的要点完成状态，并附佐证备注（注册证编号、伦理批件号与到期提醒）。S2 预问诊项目预设：五条阶段历史（2026-01 立项至 2026-04 合同签订）；标记 {genai:1, public:1}；对 7 部法规（A3/C1/C2/F1/F4/E1/E3）预置约 40% 完成，含大模型备案编号核验备注。

示例数据的设计意图有三：其一，作为系统的「开箱演示」，让新用户在 1 分钟内看到完整的项目档案形态；其二，作为第 7 章评估的固化测试夹具------示例中的完成比例是刻意构造的（S1 中 D1 伦理首项未完成、S2 中 F4 标识项未完成），用于演示风险分级与门控警示的真实触发；其三，示例本身即「最佳实践模板」------阶段历史备注的写法（批件号、备案编号）为用户提供了佐证材料管理的样板。

6.5 质量保障：四道工序

工序一：静态语法校验 。将内联 JS 提取后经 Node.js 的 node --check 全量语法校验，确保零语法错误。该工序在每次代码修改后执行，是最低成本的高价值检查。

工序二：纯函数审查。对四个核心纯函数（regApplies/projStats/riskOf/verdictOf）逐行审查其与第 5 章形式化规格的一致性：分支覆盖（verdictOf 药监三分支、网信两条件分支）、边界条件（未判定项目 flags=null 的处理、空 checks 的缺省、total=0 时 pct 的除零保护）、截断行为（addLog 500 条上限）。审查确认实现与规格逐条对应。

工序三：双案例手工走查。按第 7 章的走查脚本，对 S1/S2 从载入示例开始，逐视图验证：判定结论文本、适用法规集合（S1 应含 B1---B5，S2 应含 F1/F3/F4/C1/F2）、统计数字、风险等级、门控警示触发（S1 处于阶段 7 但可构造 B11 未完成场景验证 G2）。

工序四：输出转义审计。全库扫描所有 innerHTML 赋值点的插值变量，确认用户可控数据（项目名、科室、负责人、备注、不适用理由、日志详情）全部经 esc()，法规常量直接插值属可信源。审计发现并保持的例外：onclick 属性中的函数参数均为系统内部 id（uid 生成的 p+时间戳格式，字符集受控），无注入面。

四道工序的质量含义：工序一保证「代码可运行」，工序二保证「机制符合设计」，工序三保证「行为符合预期」，工序四保证「无注入漏洞」。局限是缺乏自动化回归测试（单文件形态下测试需先做模块化拆分，与零依赖目标冲突），当前以工序三的固化示例夹具承担回归职能------每轮修改后重跑走查脚本核对关键断言。

6.6 部署形态、性能与兼容性

部署即分发。单 HTML 文件拷贝至医院内网任意终端，浏览器打开（含 file:// 协议直接打开）即用；科室共享通过 JSON 导出/导入（导出文件名含日期，如 medai-pm-backup-2026-09-12.json）。

性能。系统的性能热点是全量重渲染：单次 render 重建全部视图 DOM，实测规模为数十个项目 × 数百检查项展开时约构建数千个 DOM 节点，在现代浏览器上耗时在 50 毫秒量级，交互无感知延迟。法规库常量（REGS 等）在脚本解析期即驻留内存，判定与统计均为线性遍历（O(法规数×要点数)，量级约 300 次基本操作），无算法性能风险。localStorage 读写为全量 JSON 序列化，数据量在数百 KB 内，单次写耗时可忽略。

兼容性。实现刻意采用 ES5 语法风格（var、function 声明、字符串拼接，无箭头函数/模板字面量/let-const），以兼容院内可能残留的老旧浏览器（如未升级的 Chromium 内嵌套件）；CSS 特性同样停留在广泛支持集（flex、grid、自定义属性），并在 1100px 断点做响应式降级。文件打开即运行的形态也规避了服务端环境差异------唯一环境依赖是 localStorage 可用性（loadDb 的 try-catch 对禁用场景优雅降级为空库）。

可移植性。数据与逻辑的 JSON 化使系统天然可迁移：全量 JSON 既是备份格式，也是未来服务版的数据库种子；REGS 常量可被提取为独立法规库文件而不改动任何函数。标准使用流为：新建项目（录入档案与数据处理概述）→ 判定向导（七问）→ 查看判定结论与自动挂载的清单 → 逐项落实并录佐证 → 阶段推进（接受门控提示）→ 期间在仪表盘监控全院态势 → 检查/汇报时导出单项目合规报告。数据备份建议随项目里程碑同步执行；法规库每半年按版本说明复核更新（当前版本 2026-09）。

6.7 本章小结

本章完成实现层的解析：四区段代码组织将 808 行控制在一个可整读的规模；适用性谓词 4 行内核被四处消费，印证「规则即数据」的架构收益；判定应用、报告导出、门控查询等关键路径均以短函数实现且与设计规格逐条可追踪；四道质量工序覆盖语法、机制、行为与注入四个失效类别。下一章以覆盖率矩阵与双案例走查，对系统完成 DSRM 流程中的评估环节。

---

第七章 评估：监管覆盖率与双案例实证

本章回答一个核心问题：系统在监管覆盖度与真实场景中表现如何？本章结论先行：覆盖率矩阵显示四条监管主线 × 七大领域的全覆盖、11 部条件法规全部由七问标记精确触发、无主线遗漏；双案例走查验证判定结论、法规挂载、统计与门控在器械类与生成式类两类典型项目中均正确；对照分析显示系统相对人工合规检查与通用项目管理工具形成代际优势。评估属描述性评估，效度威胁在 7.7 节坦率讨论。

7.1 评估方法与评估设计

按照 DSRM 的评估环节要求，本章采用描述性评估（descriptive evaluation）策略，包含三个递进的评估层：

评估层一：监管覆盖率分析（coverage analysis）。以「监管主线 × 判定标记」为轴构建覆盖率矩阵，检验两个命题------命题 P1（主线完备性）：四条监管主线各自的核心法规均被法规库覆盖；命题 P2（触发精确性）：每部条件适用法规均由至少一个判定标记触发，且触发条件与法规原文的适用范围一致。

评估层二：双案例走查（scenario walk-through）。以第 3 章引入的 S1（肺结节，器械+研究）与 S2（预问诊，生成式+公众）为对象，在系统内执行完整操作序列，逐步验证判定结论、法规挂载、统计数字、风险分级与门控警示。走查脚本固化于示例数据（6.4 节），保证可重复。

评估层三：对照分析（comparative analysis）。将系统与两类现有做法（人工合规检查、通用项目管理/合规台账工具）在关键治理任务上对比，界定系统的增益边界。

三层评估分别回答「知识全不全」「机制对不对」「价值大不大」，与前两章的评估对象（知识模型、机制实现）逐一对应。

7.2 监管覆盖率矩阵

7.2.1 主线 × 领域覆盖（命题 P1）

四条监管主线在法规库中的落点如下矩阵（括号内为法规数与要点数）：

监管主线	主要领域	覆盖法规	关键覆盖点
药监	B 医疗器械准入	B1---B5（5部/16项）	属性判定、注册核验、注册技术要求、软件生存周期、不良事件监测
卫健	C 医疗质量 + D 伦理研究	C1---C4 + D1---D4（8部/27项）	核心制度、互联网诊疗红线、病历规范、医师法；伦理审查、IIT备案、科技伦理、人遗
网信	F 算法与生成式AI	F1---F4（4部/12项）	生成式AI备案、算法推荐、深度合成、内容标识强制标准
数据与网络安全	A 基础法律 + E 专项	A1---A4 + E1---E7（11部/35项）	三法、等保2.0、分类分级、健康医疗数据指南、人口健康信息、出境、密码
（跨主线治理）	G 行业政策	G1---G5（5部/12项）	人工智能+行动、30号文、84场景指引、2026共识、互联互通标准

矩阵显示：四条主线的法定义务节点（属性判定---注册---质量---伦理---备案---标识---等保---分级---出境---人遗）全部有对应法规与要点承载，命题 P1 成立。G 类虽非独立监管主线，但其治理要求（分级分类、动态监测、多学科审查、半年复评）作为「治理操作系统」贯穿四主线，系统通过风险分级算法与生命周期复评段位将其机制化。

7.2.2 判定标记 × 条件法规触发（命题 P2）

11 部条件适用法规的触发映射如下：

判定标记	触发法规	法规原文适用范围	一致性
medDevice（=dev）	B1 器械监督管理条例	「按医疗器械管理时」	一致
medDevice	B3 AI器械注册审查原则	「按医疗器械管理时」	一致
medDevice	B4 器械软件注册审查原则	「按医疗器械管理时」	一致
medDevice	B5 不良事件监测办法	「医疗器械...使用单位」	一致
public	C1 互联网诊疗监管细则	「互联网诊疗活动」	一致
public	F2 算法推荐管理规定	「面向公众提供服务」	一致
research	D2 IIT管理办法	「研究者发起的临床研究」	一致
research	D3 科技伦理审查办法	「涉及数据与算法的科技活动」	一致
genetic	D4 人遗管理条例	「人类遗传资源」	一致
export	E6 数据出境评估办法	「向境外提供」	一致
genai	F1/F3/F4 生成式AI三规	「生成式人工智能技术」	一致

两个设计细节值得强调：其一，medDevice 由 dev 派生而非独立提问，把药监局「处理器械数据即具器械属性可能」的规则内化为推导，减少用户应答负担；其二，D3 科技伦理审查办法以 research 触发而设为通用条件 'all' 亦有其理（其清单含「具有舆论社会动员能力算法」），系统选择 research 触发并以「面向公众提供服务时评估适用」的 cond 文本提示扩展评估------边界情形以 cond 文本显式提示而非静默二选一，保留人工裁量的接口。

命题 P2 成立：11 部条件法规全部由标记精确触发，触发条件与法规适用范围逐条一致。结合 7.2.1，覆盖率评估结论为：系统对当前中国医疗AI国家监管标准形成结构化全覆盖，其覆盖边界由法规库版本（2026-09）显式声明，随政策演进按半年周期复核。

7.2.3 覆盖率的量化汇总

33 部法规按适用性分布：无条件适用（all）22 部（67%），条件适用 11 部（33%）；按优先级：高 28 部、中 5 部；要点总数约 90 项（平均每部 2.7 项）。对一个典型项目，判定前基线清单为 22 部法规约 60 项要点；判定后按特征扩张------S1 类项目（器械+研究）适用 30 部，S2 类项目（生成式+公众）适用 27 部。清单规模的差异本身就是判定机制的直接价值：项目间合规义务的差异（最多相差约三分之一）由系统自动裁剪，而非依赖人工记忆。

7.3 案例走查 S1：肺结节CT影像AI辅助检测系统

场景设定（与内置示例一致）：放射科项目，处理胸部CT影像（医疗器械数据），结节检出与性质提示（辅助决策），嵌入PACS供医师参考，回顾性数据训练已获伦理批件，预算280万元，2025年3月启动，当前处于第8段（全院上线）。

走查步骤一：判定向导。七问应答：Q1 器械数据=是（CT影像）、Q2 辅助决策=是（性质提示）、Q3 生成式=否、Q4 公众=否、Q5 研究数据=是（回顾性训练）、Q6 人遗=否、Q7 出境=否。系统生成四主线结论：药监线------「按医疗器械管理（辅助决策类）...通常按第三类或第二类管理，须核验/取得NMPA注册证」，与 47 号通告矩阵及第三类目录（结节良恶性定性属重大疾病诊治决策）的判定预期一致；卫健线------列出医师终审、质量体系、伦理审查与跟踪审查（研究标记追加 IIT 语境）；网信线------「院内工具、不面向公众，一般不触发网信备案义务，但随应用范围扩展须持续评估」；数据线------敏感个人信息三件套（PIA/单独同意或伦理依据/去标识化）+ 分级境内存储 + 等保测评。

走查步骤二：法规挂载核验 。判定后 App(S1) 应为 22 部基线 + B1/B3/B4/B5（medDevice）+ D2/D3（research）= 29 部（示例数据另含 B2，B2 本为 all 适用，故合计 30 部）。系统清单分组呈现：B 领域从 1 部（B2）扩张为 5 部，D 领域从 1 部（D1）扩张为 3 部。统计面板显示适用法规数与要点总数相应扩张，挂载结果与 7.2.2 矩阵的预期完全一致。

走查步骤三：统计与风险。示例预置约 60% 完成度：此时待完成高优先级项约十余项，风险等级判定为「中」或「高」随构造而定（示例构造使 D1 伦理首项处于完成态，避免演示中的矛盾警示；S1 的未完成项分散于 E/G 类）。完成度与 pendingHigh 的数字经手工重算核对一致。

走查步骤四：门控触发 。项目处于阶段 7（索引 7，全院上线），medDevice=1，系统阶段记录页执行 G2 查询：B1 要点 1（注册证核验）在示例中为完成态且备注「注册证编号：国械注进20253210000（示例）」，故无警示------门控正确放行合法状态 。构造反向用例：将 B1 要点 1 取消勾选，阶段记录页立即出现「按医疗器械管理但注册证核验项未完成，不得全院上线」警示------门控正确拦截违规状态。正反两向验证 G2 规则的行为正确性。

走查步骤五：报告导出。导出的合规报告包含项目元信息（阶段 8/10 全院上线）、四主线判定、按领域分组的三百余行要点状态表与免责尾注，可作为院内准入审查材料附件。

7.4 案例走查 S2：门诊智能预问诊与导诊助手

场景设定：门诊部项目，医疗大模型预问诊采集与分诊导诊，患者小程序服务，处理主诉文本，不涉研究/人遗/出境，预算60万元，2026年1月启动，当前处于第5段（采购与签约）。

走查步骤一：判定。Q1=否（主诉文本非器械数据）、Q2=否（分诊导诊不作诊断结论）、Q3=是（大模型对话）、Q4=是（患者小程序）、Q5/Q6/Q7=否。四主线结论：药监线------「不作为医疗器械管理。但须按《分类界定指导原则》保留书面属性判定记录备查」（非器械结论仍留痕，正确执行 B2 义务）；卫健线------医师终审与质量体系之外，因 public 标记追加互联网诊疗红线（AI不得替代接诊开方、处方药师审核、算法备案评估）；网信线------生成式双义务（核验大模型备案编号；自建对外须自行备案评估）+ 内容标识（2025.9.1 强制）+ 公众服务的舆论属性评估；数据线------基础三件套（无出境、人遗条件项）。

走查步骤二：挂载核验 。App(S2) = 22 部基线 + F1/F3/F4（genai）+ C1/F2（public）= 27 部。F 领域从 0 部扩张为 3 部，C 领域新增 C1。特别核验 F4（标识办法）：示例备注「大模型备案编号已核验」对应 F1 首项，而 F4 的显式/隐式标识项处于未完成态并计入 pendingHigh------这一「未完成」恰是对现实的最忠实刻画：2026 年的患者端生成式服务普遍面临标识机制改造，系统将其显性化为待办而非默认满足。

走查步骤三：风险与门控。S2 处于阶段 4（索引），未达试点部署（索引 5），G1 门控不触发------阶段本身尚未到需要伦理与等保前置校验的位置，系统仅在推进弹窗常驻提示。若强制推进至试点部署而 E2 首项未完成，G1b 警示即出现。S2 的 pendingHigh（构造约 40% 完成度）使风险等级呈现为「中」，与直观预期（生成式+公众双敏感标记、关键项未齐）一致。

走查小结：双案例在判定结论（药监三分支的两端、网信条件分支的正例）、法规挂载（器械四部 vs 生成式三部+公众两部）、门控行为（G2 正反两向、G1 时机）三个层面均给出正确结果。两案例合计覆盖七问标记空间 7 个维度中的 5 个（dev/decision/research/genai/public），genetic 与 export 两维未在案例中展开，但其在 7.2.2 矩阵中的触发映射（D4/E6）已通过规则级追溯验证------案例覆盖与规则覆盖互补，共同支撑评估结论。

7.5 对照分析：相对既有做法的增益

以五项关键治理任务为轴，对照人工合规检查（医院现况主流）与通用工具（项目管理软件/合规台账）：

治理任务	人工检查	通用工具	本系统
义务全集获取	依赖个人知识面，易漏主线	台账列出但无人负责推导	33 部法规结构化呈现，四主线全覆盖
项目适用裁剪	逐案人工推导，口径漂移	不支持条件适用	七问判定自动挂载/排除，可复算
前置程序把关	事后补证，流程与合规脱节	无合规概念	三条门控规则 + 留痕
落实状态可视化	会议汇报，静态快照	进度≠合规进度	完成度/风险/领域进展实时聚合
检查可证明性	材料分散	---	佐证备注 + 审计日志 + 报告导出

对照显示，系统的增益不在单点功能的强弱，而在闭环：判定（谁适用什么）→ 清单（做什么）→ 门控（何时能推进）→ 留痕（做过什么）→ 报告（如何证明），五环在同一数据结构上贯通------这是人工模式与台账工具结构性无法达成的。

7.6 任务层走查：五项管理操作的端到端验证

案例走查验证的是「系统对典型项目的判定正确性」，任务层走查则验证「系统对管理操作的响应正确性」------对应第 3 章 UC1---UC8 中风险最高的五项操作。

T1 新立项的完整流 。操作：新建项目「急诊分诊智能辅助系统」→ 仅录入档案不判定 → 查看仪表盘。断言：项目出现在列表与阶段分布第 1 段；仪表盘出现「有 1 个项目尚未完成合规分类判定」警示框；项目详情页显示基线清单（22 部无条件法规）；风险等级显示「未判定」。结论：未判定状态在全系统可见且不可忽略，验证通过。

T2 重新判定与清单伸缩 。操作：对 S2 预问诊项目重新走七问，将 Q4（公众服务）改为否、Q5（研究）改为是 → 应用判定。断言：清单收缩（C1/F2 移出）同时扩张（D2/D3 挂入）；此前对 C1 的勾选状态保留在数据中（不再计入统计，无害）；判定结论快照更新；日志新增「应用合规判定」条目且注明新结论。结论：清单伸缩无损、历史可追溯，验证通过------重判定机制支持项目特征演化的持续治理（如患者端功能下线转为院内研究工具）。

T3 不适用标记的留痕闭环 。操作：对某项目将「卫生信息标准与互联互通测评」（G5）标为不适用 → 确认 → 录入理由「本项目为纯本地工具，不接入院内平台」。断言：G5 卡片置灰并显示理由；统计分母相应减少；日志记录操作；导出报告中 G5 呈现为「不适用+理由」行。结论：不适用是显式决策而非静默消失，验证通过。

T4 报告导出的数据一致性 。操作：导出 S1 报告，逐行比对报告要点状态与界面勾选。断言：状态逐行一致（✅/⬜ 无偏差）；判定结论四块与详情页文本一致；报告尾注含法规库版本与免责声明。结论：报告与界面同源同值，验证通过------报告可作为审查材料被独立核验。

T5 备份恢复的往返一致性 。操作：导出全量 JSON → 双重确认清空全部数据 → 导入 JSON。断言：项目数、判定标记、全部勾选状态、阶段历史、审计日志逐项恢复无差；导入含非法结构的文件（如纯文本）被整体拒绝且不破坏现有数据。结论：备份往返无损、坏数据防污染，验证通过。

五项任务与 7.3---7.4 案例走查共同覆盖了系统的主要风险面：判定正确性（案例）、清单一致性（T2/T4）、防规避设计（T3）、数据安全（T5）、状态可见性（T1）。

7.7 评估效度威胁

按实证研究规范，坦率讨论四类效度威胁。结论效度 ：覆盖率矩阵由研究者自建自评，存在「以自身标准评判自身」的循环风险；缓解措施为矩阵中每个映射均附法规原文适用范围（7.2.2 表第三列），接受独立核验。内部效度 ：走查由开发者执行，存在确认偏差（倾向看到预期结果）；缓解措施为走查脚本固化于示例数据、正反两向用例（门控放行与拦截）成对构造，但根治需第三方测试。外部效度 ：双案例为构造性场景而非真实医院现场数据，结果向真实组织的泛化未经验证；典型案例（器械、生成式）已覆盖，长尾情形（人遗、出境、多标记叠加）仅经规则级验证。构建效度 ：「覆盖」以法规部数与要点数衡量，不等于治理效果（用户是否因此更合规）；完成度勾选依赖用户诚实输入，系统无法核验佐证真伪。四类威胁界定了评估结论的适用边界：机制正确性与知识覆盖度已获描述性验证，真实组织的治理效果有待后续实证研究（见 8.5 与 9.2 节）。

---

第八章 讨论

本章回答一个核心问题：本研究在理论与实践上意味着什么，边界在哪里？本章结论先行：理论上，本研究为「监管即代码」提供了一个高密度监管场景的完整中文实证，并提出「项目特征条件义务型监管」这一被既有 RegTech 研究忽视的类型学；实践上，系统对医院AI治理、DRG/DIP 运营联动均有直接价值；局限集中于法规时效依赖、判定非终局性、单机协同缺失、评估描述性等七项，其中多数已预留演进接口。

8.1 理论意义：监管即代码的中国医院场景实证

「监管即代码」（Regulation-as-Code）理念自新西兰 Better Rules 计划等实践提出以来，其主张------将法律规则形式化为机器可执行逻辑，使合规推导从人工解读变为程序求值------在理论层面颇具吸引力，但落地实证长期集中于单部法规的规则化试点（如税率计算的规则引擎）。本研究推进的实证具有三点理论增量：

其一，验证了「法规群」而非「单法规」的可形式化性 。本系统的规则对象不是一部法规，而是横跨四条监管主线、七个领域、三种效力层级（法律---法规规章---标准政策）的 33 部文件。形式化的关键不在于把每部法规转写为逻辑规则，而在于找到跨法规的公共结构 ------适用性谓词。33 部法规的适用逻辑最终收敛为 'all' 与七标记存在量词两种形态，这一收敛本身是一个有价值的发现：监管文本的表面复杂性高于其适用结构的实质复杂性，抓住「项目特征 → 义务集合」的映射骨架，法规群的机器化即告成立。

其二，识别出「项目特征条件义务型监管」这一类型学位置 。既有 GRC 与 RegTech 研究默认的监管形态是「主体义务型」------义务按被监管主体统一适用（如金融合规）。本研究刻画的中国医疗AI监管是「项目特征条件义务型」：同一机构内，义务集合是项目技术与社会特征的函数（处理器械数据与否、生成式与否、面向公众与否......）。这一类型对合规信息系统提出了独特要求------特征采集（七问）成为系统的一等公民，与任务管理同等重要。这一类型学观察对其他领域（如教育AI、自动驾驶的企业内部治理）具有可迁移性。

其三，给出了「软门控」这一合规刚性与管理弹性的调和范式。监管即代码的激进形态是硬编码阻断（不满足条件系统拒绝放行），本研究的实践表明，在机构内部治理场景中，「警示 + 留痕 + 决策权保留」的软门控更具制度可持续性------它承认例外情形的合法性，通过让例外可见、可追责来约束例外，而非消灭例外。这一发现与制度经济学中「规则与裁量权互补」的经典命题形成呼应。

8.2 实践意义：医院治理与 DRG/DIP 运营的双重价值

对医院AI治理的直接价值 。系统将三重治理困境（知识碎片化、适用推导易错、先上线后补证）逐一机制化消解：法规库即「完整合规视图」，七问判定即「口径统一的适用推导」，阶段门控与审计日志即「先合规后上线的流程保障」。以 2026 版专家共识的多学科联合评估为参照，系统天然充当评估组的工作底座------临床、信息、法务、伦理四类角色在同一个项目档案上工作：判定标记回答技术特征，检查清单分派领域职责，佐证备注汇总审查材料，导出报告即审查结论附件。一票否决制所需的「任一领域的否决证据」，对应清单中该领域高优先级未决项------系统使否决从「会议上的异议」变为「数据中的事实」。

与 DRG/DIP 运营的联动价值 。医院管理者当前的优先议程之一是 DRG/DIP 支付改革下的降本增效，医疗AI六路径（临床文书生成、病案编码与DRG运营、患者流程与床位周转、耗材供应链SPD、财务RPA、导诊随访外呼）均以项目形态进入医院，且每一路径都触发本系统管理的监管义务：临床文书生成是生成式AI（Q3）且写入病历（病历规范要点），智能病案编码可能构成辅助决策（Q2），外随随访面向公众（Q4）。这意味着医疗AI的「降本增效账」必须叠加「合规成本账」才能算清------一个未判定器械属性就上线的CDSS，其整改成本可能吞噬全部效率收益。本系统使两个账本在同一项目档案中合并：立项论证段的类别登记对接六路径定位，生命周期门控确保效率收益不被合规风险对冲。对医院而言，这是「AI 提效」与「AI 避险」的统一管理面。

对监管侧与区域治理的参考价值 。系统的法规库结构（法规实体八属性 + 适用谓词）本质上是监管知识的机器可读发布格式------若监管部门或行业组织按此结构发布官方法规库（带版本与生效日期），医院侧系统的知识维护成本将从「人工研读」降为「订阅更新」，这正是「监管即代码」的供给侧形态。本研究以使用侧系统的先行实现，为该供给侧转型提供了格式样例与需求证据。

8.3 与 2026 版专家共识的机制对齐

值得单独讨论的是系统与《医疗机构人工智能应用与治理专家共识（2026版）》的四点机制对齐：三级风险分级 （低/中/高）由 riskOf 算法承载，阈值参数化保留校准空间；多学科联合评估 如 8.2 节所述由共享档案承载；每半年动态复评 由第 9 段生命周期与法规库版本复核周期（半年）双轨承载------复评触发既来自项目日历，也来自法规库版本变更（新法规入库后，全部项目的适用集合与风险等级自动重算，这本身就是一种「监管驱动的复评」）；人机协同以人为主由卫健主线的基础义务集（医师终审）在每一个项目的判定结论中强制出现承载。共识的四项治理要求全部找到机制落点，这使系统不仅是「合规检查工具」，更是「共识实施工具」。

8.4 局限：七项坦率清单

L1 法规时效依赖。法规库为静态快照（2026-09 版），中国医疗AI监管正处密集出台期，半年复核周期内的重大新规存在滞纳风险；缓解机制为版本显式标注与数据/逻辑分离，但更新仍依赖人工研读。

L2 判定非终局性。七问判定忠实于建模规则，但边界情形（如「是否构成辅助决策」的临界功能、多用途系统的分类归属）需监管部门或法务最终认定；系统以 cond 文本与免责声明显式化此边界，但不能消除它。

L3 风险阈值的经验性。pendingHigh>6 的高风险阈值基于「关键法规两部未动」的直觉设定，未经真实项目分布校准；三级的单调性合理，但分界点可能偏严或偏松。

L4 单机形态的能力边界。无身份体系（日志不归属个人）、无并发协同（JSON 合并不可扩展至全院）、localStorage 清理即数据消失------三点在科室级使用可接受，向全院推广时成为硬约束。

L5 统计口径的勾选自报性。完成度以用户勾选为准，佐证备注不做真伪与完整性校验；「打勾式合规」的漂移风险（为进度而勾选）需要管理配套（如佐证材料抽查）约束。

L6 评估的描述性。如 7.7 节所述，覆盖率与案例走查属描述性评估，无真实用户实验与组织现场数据；治理效果的因果证据（系统使用 → 合规改善）缺位。

L7 语言与法域边界。法规库限于中国国家监管标准（含少量国际标准如 FHIR 的引用），不覆盖地方法规（如各省互联网诊疗实施细则）、跨境多法域（跨国医院集团）情形；论文以中文写作，结论向其他法域的可迁移性未讨论。

七项局限中，L1/L2/L3 属知识层（随法规库版本与阈值参数演进），L4 属形态层（v2 服务版解决），L5 属治理配套层（制度而非技术问题），L6/L7 属研究层（后续研究议程）。没有任何一项否定核心设计，但全部应在使用与引用本系统时明示。

8.5 改进方向

对应局限，五个方向的改进已具备明确的技术路径：（1）法规库订阅化 ：以 JSON 格式发布法规库，支持导入更新与差异比对（新增/修订/废止逐条呈现），将半年复核从研读降为审阅；（2）判定置信分层 ：为七问增加「不确定」应答，触发边界情形提示（如「是否辅助决策不确定 → 建议通过药监分类界定信息系统咨询」），把 L2 的边界从隐式免责转为显式引导；（3）阈值校准 ：采集真实项目的 pendingHigh 分布，以分位数（如 P75/P90）替代直觉阈值，并在设置页开放机构自配置；（4）服务版演进 ：数据模型平移为服务端 API，叠加账号体系与角色权限（信息科/医务/伦理/管理层视图分权），localStorage 限制自然解除；（5）效果实证：在合作医院开展前后对照或阶梯楔形设计（stepped-wedge）的部署研究，以「门控警示出现率、伦理批件前置完成率、检查响应时长」等指标补足因果证据链。

8.6 伦理审视：治理工具自身的正当性

一个用于治理AI的工具，自身也须经受伦理审视。四个问题值得正面回答。

判定是否透明可解释？ 系统的每一项输出------判定结论、法规挂载、风险等级、门控警示------均可回溯到显式规则：结论函数的分支对应法规条款（5.3 节），挂载是谓词求值（5.4 节），风险是计数与阈值（3.6 节）。系统不存在机器学习组件，也就不存在黑箱判定------可解释性不是系统的附加属性，而是其构造方式。这一选择是有意为之：在合规场景中，一个无法解释「为什么要求我做这件事」的工具，本身就是新的治理风险。

留痕是否会异化为监控？ 审计日志记录操作而不记录操作者身份（单机形态无账号），其设计用途是组织学习与检查证明，而非个人绩效考核依据。但技术边界不能阻止管理用途的漂移------若医院将日志用于问责个体（如「谁勾慢了」），系统将诱发数据造假与规避使用。伦理上稳妥的定位是：留痕服务于事（义务是否履行），不服务于人（谁在拖延）；这一定位应写入医院引入本系统时的使用制度。

勾选式管理是否制造「合规表演」？ 这是 L5 局限的伦理面向。勾选框天然的风险是形式主义------「打了勾」与「做到了」之间隔着佐证材料的真实性。系统的对抗性设计有三：佐证备注字段（勾选与证据绑定）、报告中的法规依据列（每项勾选都能被提问「依据是什么」）、不适用标记的强制理由。但这些只是降低而无法消除表演空间；最终约束是管理配套（抽查佐证、审查时核对原件），技术在此处应承认自身边界。

工具是否会加剧数字鸿沟？ 大型三甲医院有法务、信息科、伦理委员会的完整建制，中小医院往往一人身兼数职。系统的普惠性设计（免费、单文件、免安装、中文界面、开箱示例）正是为后者------使「没有专职合规团队」的医院也能获得结构化的监管知识基线。但鸿沟不会因工具消失：法规库更新、阈值校准、边界情形认定仍需专业能力支撑。v3.x 路线中区域共建法规库与官方机器可读发布的意义，正在于把这种专业能力公共品化。

8.7 本章小结

本章将系统放回理论与实践的双重坐标：理论上，33 部法规收敛为两形态适用谓词的建模经验、「项目特征条件义务型监管」的类型识别与「软门控」范式，构成对监管即代码文献的增量；实践上，系统同时服务医院AI治理与 DRG/DIP 时代的 AI 项目组合管理，并预演了监管知识机器可读发布的供给侧形态。七项局限界定了结论的适用边界，五项改进给出了从描述性验证走向组织级实证的路线。下一章以四个研究问题的回答收束全文。

---

第九章 结论与展望

本章回答全文的总问题：如何将中国医疗AI监管知识转化为可计算模型并内嵌于医院项目全生命周期管理？结论先行：以「法规实体---适用谓词---监管要点---阶段门控」四层结构完成知识形式化，以七问判定引擎与软门控完成机制化，以单文件离线系统完成工程化；覆盖率矩阵与双案例走查验证了机制正确性与知识覆盖度；三层演进路线图给出从科室工具到区域监管科技平台的扩展路径。

9.1 四个研究问题的回答

RQ1（知识建模）------监管政策文本如何转化为可计算知识模型？ 通过「领域聚类、要点分解、谓词收敛」三步完成：33 部法规按监管职能语义聚合为七大领域（而非按发布机关切分），每部法规分解为 2---6 条动作导向、可核验的监管要点（全库约 90 项），全部适用条件收敛为「无条件（all，22部）」与「七标记存在量词（11部）」两种谓词形态（第 3 章）。知识模型的工程形态是法规实体八属性结构，其关键性质是数据与逻辑分离------法规库版本更新不触碰判定代码（第 4 章）。此问题的回答同时产出一个类型学发现：医疗AI监管属「项目特征条件义务型」，特征采集（七问）因此是合规系统的一等公民（第 8 章）。

RQ2（架构设计）------系统应采用何种总体架构？ 以「监管内嵌、数据不出院、零依赖、渐进披露」四原则驱动，采用六模块单页应用与三层数据架构（监管知识常量---项目运行状态---视图渲染），以 808 行单 HTML 文件交付：无网络面即无传输攻击面与供应链风险，全量本地存储即满足数据不出院，拷贝即部署即适配医院内网现实（第 4、6 章）。架构的关键权衡是全量重渲染换状态一致性、软门控换管理弹性------两者都以「消灭一类错误」而非「增加一类能力」的方式提升系统品质。

RQ3（机制形式化）------判定引擎与阶段门控如何形式化并保证正确？ 判定引擎：七维布尔标记空间（对当前法规库适用条件集完备）输入 verdictOf 四主线结论函数（纯函数、确定性、可复算），法规挂载为谓词求值而非枚举操作，从结构上消灭清单不一致（第 5 章）。阶段门控：三条可追溯到具体法规前置义务的规则（伦理首项、等保备案、注册证核验），以「提示---警示---留痕」的软执行平衡刚性与例外。正确性通过「规则级追溯 + 单一事实源 + 双向用例验证」三层机制保障，其边界是忠实性而非终局性------系统忠实执行建模规则，最终认定权在监管机关（第 5.7 节）。

RQ4（评估验证）------覆盖度与实用性如何？ 覆盖率矩阵验证两个命题成立：四条监管主线全部落点于法规库（P1），11 部条件法规全部由标记精确触发且与法规原文适用范围一致（P2）；双案例走查在判定结论、法规挂载、统计风险、门控行为四个层面给出正确结果，正反两向用例（门控放行与拦截）成对验证；对照分析确认系统相对人工检查与通用工具形成「判定---清单---门控---留痕---报告」五环贯通的闭环优势（第 7 章）。评估属描述性评估，组织级治理效果的因果证据列为后续议程（第 8.4 节 L6）。

9.2 三层演进路线图

系统当前形态（v1.0）是演进链的起点，路线图按「覆盖半径 × 治理深度」分三层展开：

第一层：院内科室级深化（v1.x，当前）。在单文件形态内迭代：法规库订阅化（JSON 发布 + 差异比对导入，新增/修订/废止逐条呈现）、判定置信分层（不确定应答引导边界咨询）、风险阈值机构自配置、地方法规与院内制度（伦理委员会 SOP、器械科台账规范、本省互联网诊疗实施细则）作为扩展领域挂载，并与项目管理台账科室（如科研处的 IIT 登记）对接，避免同一项目两处录入。此层的目标是把 8.5 节改进方向（1）---（3）落地，使系统从「合规检查工具」演进为「医院AI治理操作台」。

第二层：单体医院服务版（v2.0）。数据模型平移为服务端资源（projects/regulations/checks 三类 API），叠加账号体系与四类角色分权（管理层看态势、医务/伦理看审查、信息科看技术合规、项目组看任务）、待办推送（伦理批件到期、半年复评日历、法规库版本变更触发的重算通知）、与院内系统集成（HIS/EMR 的项目数据源对接、OA 的审批流对接、等保三级测评配套）。此层解除单机形态的 L4 约束，使系统进入医院信息科的标准运维目录。核心设计资产在此层全部复用：REGS 常量即法规库 API 的种子数据，verdictOf/regApplies 纯函数即服务端规则引擎------v1.0 的「数据与逻辑分离」架构正是为此预留。

第三层：区域协同与监管科技（v3.x，远期）。多院区/医联体的项目组合视图（区域AI应用地图、风险热力）、监管侧数据接口（匿名化合规态势上报，支撑穿透式监管的机构自证通道）、法规知识的供给侧共建（行业组织维护的官方机器可读法规库， hospitals 订阅更新------即 8.2 节所述「监管即代码的供给侧形态」）、以及真实世界效果研究（多中心部署、以合规前置完成率等指标建立证据链）。此层使系统从机构工具生长为区域医疗AI治理基础设施的一部分。

三层路线的共同主线是：知识模型稳定、机制接口开放、形态随治理半径伸缩。v1.0 单文件形态刻意保有的「JSON 数据 + 纯函数逻辑」，使每一层扩展都只是形态替换而非重写。

9.3 结语

医疗AI进入医院的「加速期」与「强监管期」叠加，把一个新问题推到了医院治理者面前：如何让数十部分散的监管文件，变成项目团队每天可执行、管理者随时可查看、检查者处处可追溯的治理秩序？本研究的回答是把监管知识当作可以被工程化的对象------33 部法规收敛为两形态的适用谓词，七问把法条映射还原为事实应答，三条门控把「先合规后上线」从口号变成流程中的警示与留痕，而这一切运行在一个可以装进 U 盘、在任何内网终端双击即用的单文件系统里。

这项工作的更大企图，是为「监管即代码」积累一个高密度场景的完整样本：当监管侧有朝一日以机器可读格式发布法规知识时，医院侧已经准备好了消费它的系统结构与管理习惯。技术会迭代，法规会更新，但「把规则变成数据、把结论变成求值、把例外变成留痕」这三条工程原则，在医疗AI治理这一关乎生命与责任的领域中，具有超出本系统生命周期的持久价值。

---

参考文献

一、法规、标准与政策文件（33 部，按系统法规库编号）

1. A1 《中华人民共和国网络安全法》（2017年施行，2025年修正）。全国人大常委会。
2. A2 《中华人民共和国数据安全法》（2021年施行）。全国人大常委会。
3. A3 《中华人民共和国个人信息保护法》（2021年施行）。全国人大常委会。
4. A4 《中华人民共和国基本医疗卫生与健康促进法》（2020年施行）。全国人大常委会。
5. B1 《医疗器械监督管理条例》（国务院令第739号，2021年修订）。国务院。
6. B2 《人工智能医用软件产品分类界定指导原则》（国家药监局2021年第47号通告）。国家药品监督管理局。
7. B3 《人工智能医疗器械注册审查指导原则》（国家药监局2022年第8号）。国家药品监督管理局。
8. B4 《医疗器械软件注册审查指导原则》（国家药监局2022年第9号）。国家药品监督管理局。
9. B5 《医疗器械不良事件监测和再评价管理办法》（2019年施行）。国家市场监督管理总局、国家卫生健康委。
10. C1 《互联网诊疗监管细则（试行）》及互联网诊疗管理规范（国卫办医发〔2022〕2号等）。国家卫生健康委。
11. C2 《医疗质量安全核心制度要点》（18项，2018年印发）。国家卫生健康委。
12. C3 《电子病历应用管理规范（试行）》（2017年施行）。国家卫生健康委。
13. C4 《中华人民共和国医师法》（2022年施行）。全国人大常委会。
14. D1 《涉及人的生命科学和医学研究伦理审查办法》（2023年施行）。国家卫生健康委等四部门。
15. D2 《医疗卫生机构研究者发起的临床研究管理办法》（2024年全国施行）。国家卫生健康委。
16. D3 《科技伦理审查办法（试行）》（2023年12月施行）。科技部等十部门。
17. D4 《人类遗传资源管理条例》及实施细则（2019年施行/2023年细则施行）。国务院。
18. E1 《医疗卫生机构网络安全管理办法》（国卫规划发〔2022〕29号）。国家卫生健康委等三部门。
19. E2 网络安全等级保护制度（等保2.0，GB/T 22239-2019，2019年实施）。公安部等。
20. E3 《卫生健康行业数据分类分级指南（试行）》（2023年印发）。国家卫生健康委等三部门。
21. E4 《健康医疗数据安全指南》（GB/T 39725-2020，2020年实施）。国家市场监督管理总局。
22. E5 《人口健康信息管理办法（试行）》（2014年印发）。国家卫生计生委。
23. E6 《数据出境安全评估办法》（2022年施行）及《促进和规范数据跨境流动规定》（2024年施行）。国家互联网信息办公室。
24. E7 《中华人民共和国密码法》及商用密码应用要求（2020年施行）。全国人大常委会。
25. F1 《生成式人工智能服务管理暂行办法》（2023年8月15日施行）。国家网信办等七部门。
26. F2 《互联网信息服务算法推荐管理规定》（2022年3月1日施行）。国家网信办等四部门。
27. F3 《互联网信息服务深度合成管理规定》（2023年1月10日施行）。国家网信办等三部门。
28. F4 《人工智能生成合成内容标识办法》及 GB 45438-2025（2025年9月1日施行）。国家网信办等四部门。
29. G1 《关于深入实施"人工智能+"行动的意见》（国发〔2025〕11号）。国务院。
30. G2 《关于促进和规范"人工智能+医疗卫生"应用发展的实施意见》（国卫办规划发〔2025〕30号，2025年10月20日）。国家卫生健康委等五部门。
31. G3 《卫生健康行业人工智能应用场景参考指引》（2024年11月，84个应用场景）。国家卫生健康委等三部门。
32. G4 《医疗机构人工智能应用与治理专家共识（2026版）》（2026年4月发布）。北京卫生法学会等两学会牵头、40余家机构。
33. G5 卫生信息标准与互联互通测评（WS/T系列标准、HL7 FHIR等）。国家卫生健康委。

二、学术文献与方法论参考

34. Peffers, K., Tuunanen, T., Rothenberger, M. A., & Chatterjee, S. A Design Science Research Methodology for Information Systems Research. Journal of Management Information Systems, 2007, 24(3): 45--77.
35. Hevner, A. R., March, S. T., Park, J., & Ram, S. Design Science in Information Systems Research. MIS Quarterly, 2004, 28(1): 75--105.
36. 孙麦妮, 王梦圆 等. 监管科技（RegTech）发展研究综述. 金融理论与实践（综述性文献，代表 RegTech 研究脉络）.
37. Motta, G. C. B., Folloni, A. M., et al. Regulation-as-Code: A Systematic Literature Review. --- 关于「监管即代码」理念与 Better Rules 计划等实践的综述性文献.
38. FDA. Software as a Medical Device (SaMD): Possible Framework for Risk Categorization and Corresponding Considerations. International Medical Device Regulators Forum, 2014.（国际监管框架对照参考）
39. European Union. Regulation (EU) 2024/1689 (Artificial Intelligence Act). Official Journal of the European Union, 2024.（欧盟 AI Act 对照参考）
40. WHO. Ethics and Governance of Artificial Intelligence for Health. Geneva: World Health Organization, 2021.（WHO 医疗AI伦理治理指南对照参考）

说明：法规条目以系统法规库（版本 2026-09）登记信息为准，文号与施行日期已逐条联网核验至 2026 年 9 月；学术文献 36---37 为领域综述代表，正式投稿前应按目标期刊规范补全卷期页码。

---

附录A 监管法规库清单

登记信息与系统内置法规库（版本 2026-09）完全一致。「适用条件」列中「无条件」对应机器谓词 ap='all'，其余为判定标记触发的条件适用法规（ap 为标记数组）。

A 基础法律（4 部 · 15 项要点）

编号	法规名称	文号/施行	发布机关	优先级	适用条件	要点数
A1	《中华人民共和国网络安全法》	2017年施行，2025年修正	全国人大常委会	高	无条件	4
A2	《中华人民共和国数据安全法》	2021年施行	全国人大常委会	高	无条件	4
A3	《中华人民共和国个人信息保护法》	2021年施行	全国人大常委会	高	无条件	5
A4	《基本医疗卫生与健康促进法》	2020年施行	全国人大常委会	中	无条件	2

B 医疗器械准入（5 部 · 16 项要点）

编号	法规名称	文号/施行	发布机关	优先级	适用条件	要点数
B1	《医疗器械监督管理条例》	国务院令第739号，2021年修订	国务院	高	按医疗器械管理（medDevice）	4
B2	《人工智能医用软件产品分类界定指导原则》	国家药监局2021年第47号通告	国家药监局	高	无条件	3
B3	《人工智能医疗器械注册审查指导原则》	国家药监局2022年第8号	国家药监局	高	按医疗器械管理（medDevice）	4
B4	《医疗器械软件注册审查指导原则》	国家药监局2022年第9号	国家药监局	中	按医疗器械管理（medDevice）	3
B5	《医疗器械不良事件监测和再评价管理办法》	2019年施行	国家市场监管总局、国家卫健委	高	按医疗器械管理（medDevice）	3

C 医疗质量与诊疗规范（4 部 · 11 项要点）

编号	法规名称	文号/施行	发布机关	优先级	适用条件	要点数
C1	《互联网诊疗监管细则（试行）》及互联网诊疗管理规范	国卫办医发〔2022〕2号等	国家卫健委	高	面向患者/公众提供服务（public）	4
C2	《医疗质量安全核心制度要点》（18项）	2018年印发	国家卫健委	高	无条件	3
C3	《电子病历应用管理规范（试行）》	2017年施行	国家卫健委	中	无条件	3
C4	《中华人民共和国医师法》	2022年施行	全国人大常委会	中	无条件	2

D 伦理与临床研究（4 部 · 16 项要点）

编号	法规名称	文号/施行	发布机关	优先级	适用条件	要点数
D1	《涉及人的生命科学和医学研究伦理审查办法》	2023年施行	国家卫健委等四部门	高	无条件	4
D2	《医疗卫生机构研究者发起的临床研究管理办法》	2024年全国施行	国家卫健委	高	涉及临床研究（research）	4
D3	《科技伦理审查办法（试行）》	2023年12月施行	科技部等十部门	中	涉及数据与算法类科技活动（research）	2
D4	《人类遗传资源管理条例》及实施细则	2019年施行/2023年细则施行	国务院	高	涉及人类遗传资源（genetic）	3

E 网络与数据安全专项（7 部 · 20 项要点）

编号	法规名称	文号/施行	发布机关	优先级	适用条件	要点数
E1	《医疗卫生机构网络安全管理办法》	国卫规划发〔2022〕29号	国家卫健委等三部门	高	无条件	5
E2	网络安全等级保护制度（等保2.0，GB/T 22239-2019）	2019年实施	公安部等	高	无条件	3
E3	《卫生健康行业数据分类分级指南（试行）》	2023年印发	国家卫健委等三部门	高	无条件	3
E4	《健康医疗数据安全指南》（GB/T 39725-2020）	2020年实施	国家市场监管总局	中	无条件	3
E5	《人口健康信息管理办法（试行）》	2014年印发	国家卫生计生委	高	无条件	3
E6	《数据出境安全评估办法》及《促进和规范数据跨境流动规定》	2022年施行/2024年施行	国家网信办	高	数据出境或境外远程访问（export）	2
E7	《中华人民共和国密码法》及商用密码应用要求	2020年施行	全国人大常委会	中	无条件	2

F 算法与生成式AI监管（4 部 · 12 项要点）

编号	法规名称	文号/施行	发布机关	优先级	适用条件	要点数
F1	《生成式人工智能服务管理暂行办法》	2023年8月15日施行	国家网信办等七部门	高	使用生成式AI/大模型（genai）	5
F2	《互联网信息服务算法推荐管理规定》	2022年3月1日施行	国家网信办等四部门	中	面向公众提供服务（public）	2
F3	《互联网信息服务深度合成管理规定》	2023年1月10日施行	国家网信办等三部门	中	使用生成式AI技术（genai）	2
F4	《人工智能生成合成内容标识办法》及 GB 45438-2025	2025年9月1日施行	国家网信办等四部门	高	使用生成式AI技术（genai）	3

G 行业政策与治理（5 部 · 12 项要点）

编号	法规名称	文号/施行	发布机关	优先级	适用条件	要点数
G1	《关于深入实施"人工智能+"行动的意见》	国发〔2025〕11号	国务院	中	无条件	2
G2	《关于促进和规范"人工智能+医疗卫生"应用发展的实施意见》	国卫办规划发〔2025〕30号	国家卫健委等五部门	高	无条件	5
G3	《卫生健康行业人工智能应用场景参考指引》	2024年11月，84个应用场景	国家卫健委等三部门	中	无条件	2
G4	《医疗机构人工智能应用与治理专家共识（2026版）》	2026年4月发布	北京卫生法学会等、40余家机构	高	无条件	4
G5	卫生信息标准与互联互通测评	WS/T系列标准、HL7 FHIR等	国家卫健委	中	无条件	3

汇总统计

维度	统计
法规总数	33 部（无条件适用 22 部 · 条件适用 11 部）
监管要点总数	约 102 项（平均每部 3.1 项，按领域见上表）
优先级分布	高优先级 28 部 · 中优先级 5 部
触发标记映射	medDevice→B1/B3/B4/B5；public→C1/F2；research→D2/D3；genetic→D4；export→E6；genai→F1/F3/F4
法规库版本	2026-09（建议每半年对照新政策复核更新）

---