医疗数据资产盘点：不要只数系统，要追数据流

资产盘点不是把系统列全，而是要追清数据从哪里产生、流向哪里、谁在使用、哪里失控。系统告诉你数据在哪里，流向告诉你风险在哪里。

关键词：数据资产、数据流向、边缘数据、动态台账

很多医院做数据资产盘点，第一版表格通常长这样：

HIS 系统、EMR 系统、LIS 系统、PACS 系统、医保结算系统、互联网医院平台、随访系统、科研平台、数据中台。

系统名称列得很全，责任部门也写了，重要程度也标了。看起来像是完成了盘点。

但真正到了数据安全管理时，问题很快就冒出来：

某个科室导出的 Excel 算不算数据资产？测试库里的脱敏数据谁负责？厂商排障拿走的日志里有没有患者信息？科研平台里的队列数据能不能继续复用？互联网医院接口同步到合作平台的数据是否还在医院可控范围内？

这些问题，单靠“系统清单”回答不了。医疗数据资产盘点不能只数系统，而要追数据流。系统告诉你数据在哪里，流向告诉你风险在哪里。

上一篇我们讲到，医院数据安全第一步不是买工具，而是先把责任、边界和流程说清楚。到了第二步，最容易被低估的动作就是资产盘点。

很多医院以为资产盘点就是“把系统列出来”。但从数据安全角度看，系统只是数据的一个落点，真正决定风险大小的，是数据从哪里产生、经过哪些系统、被谁调用、有没有导出、有没有给第三方、有没有被复制到测试库、报表库和科研环境里。

如果只数系统，医院看到的是一张静态地图；如果追数据流，医院看到的才是风险运行的路线。

这篇就围绕一个问题展开：医院做数据资产盘点，到底应该盘什么，怎么盘，盘完之后怎么真正服务后面的分类分级、权限治理、脱敏审计和应急处置。

一、系统资产和数据资产不是一回事

医院的信息系统通常比较清楚，因为它们有建设项目、有供应商、有运维责任人，也经常出现在等保、资产管理和运维台账里。

但数据资产比系统资产更细，也更流动。

同一个 HIS 系统里，可能同时包含患者身份信息、挂号记录、诊疗记录、费用记录、操作日志、统计报表。它们的敏感程度、使用场景、管理要求并不一样。

反过来，同一类数据也可能分布在多个系统里。比如患者身份信息，可能出现在挂号系统、电子病历、检验系统、影像系统、医保系统、互联网医院、随访系统、短信平台和数据中台。

如果只按系统盘点，最后得到的是“系统重要性”；如果按数据盘点，才能进一步判断“这类数据谁能用、怎么用、能不能导出、是否要脱敏、访问是否要审计”。

医院盘点时，至少要把四类资产分开看：

类型	关注重点	例子
系统资产	数据存放在哪些业务系统中	HIS、EMR、LIS、PACS、医保系统
数据资产	具体有哪些数据类别和数据集	病历、检验、影像、医保、随访、科研队列
接口资产	数据通过哪些接口流动	院内集成平台、互联网医院接口、区域平台接口
派生资产	数据被导出、复制、加工后的形态	Excel、报表库、测试库、备份库、科研数据集

很多风险不发生在核心系统里，而发生在派生资产里。

这也是医院资产盘点最容易“看起来很完整、实际上不够用”的地方。系统清单通常能回答“医院有哪些业务系统”，但回答不了三个关键问题：

关键问题	只看系统清单的问题	数据资产盘点要补上的内容
数据到底是什么	只知道系统名称，不知道具体数据类别	数据集、字段范围、敏感程度、数据规模
数据怎么被使用	只知道系统归属，不知道使用场景	诊疗、管理、科研、上报、共享、AI 训练等场景
数据离开系统后去了哪里	看不到导出、复制、接口、备份和第三方接触	流向、载体、接收方、保存期限、控制措施

所以，医院做资产盘点时，不能把“系统台账”直接当成“数据资产台账”。系统台账是基础，但它只是入口。真正的数据安全管理，需要把每个系统里的关键数据拆出来，再沿着业务流、接口流、文件流和使用流继续往下追。

举个简单例子：PACS 系统本身当然是重要系统，但盘点不能停在“PACS 系统，责任部门：影像科/信息科”。还要继续问：影像图像和影像报告是不是同一类数据？影像报告里是否包含诊断信息？是否会同步到 EMR？是否会进入区域影像平台？是否会给远程会诊平台？是否会被科研项目批量调取？厂商排障时能否接触影像原片？这些问题，才是数据安全真正要处理的颗粒度。

二、医院数据流向要从业务链条上找

医疗数据不是静态放在数据库里的。它跟着患者就诊流程、医院管理流程和科研流程不断流动。

一个患者从挂号开始，数据可能经过挂号、分诊、医生工作站、电子病历、检查申请、检验检查、影像报告、药房、收费、医保结算、随访、互联网医院复诊等多个环节。

每个环节都会产生新的数据，也会调用前面环节的数据。

做数据流向盘点时，建议不要一开始就钻数据库字段，而是先沿着业务链条问问题：

• 数据从哪个业务动作产生？

• 写入哪个系统？

• 被哪些系统调用？

• 是否通过接口同步出去？

• 是否会被导出成报表或文件？

• 是否会进入数据中台、科研平台、上报平台？

• 是否有第三方参与处理？

可以用一个四层模型来梳理：

层次	要看什么	盘点产出
业务层	哪个诊疗、管理、科研动作产生数据	场景清单
系统层	数据进入哪些系统和平台	系统清单
流转层	数据通过哪些接口、文件、任务流动	流向图
使用层	谁查看、导出、分析、共享、训练	用数场景清单

这个模型比单纯列系统更麻烦，但它更接近真实风险。

实际落地时，可以先不追求“一次画完整个医院的数据地图”。更可行的做法，是从高风险、高频流动的数据开始，先把几条主链路追清楚。

比如可以先选三条线：

数据链路	为什么优先盘	重点关注
患者诊疗主链路	覆盖 HIS、EMR、LIS、PACS、药房、收费等核心系统	数据产生、系统调用、诊疗连续性、日志追踪
科研用数链路	批量数据多，复用和导出风险高	伦理审批、字段最小化、脱敏、保存期限、项目结束处置
第三方接触链路	外部人员和外部环境带来额外不确定性	远程接入、账号权限、日志留痕、数据带出、退出机制

这三条线跑通以后，医院会很快发现：很多风险不是某个系统“有没有漏洞”，而是数据在跨系统、跨部门、跨机构流转时，责任和控制没有跟上。

追数据流时，建议每条链路至少形成一张“流向草图”。草图不一定复杂，但要能看出四件事：数据从哪里来，经过哪里，谁在使用，哪里可能离开医院可控范围。

流向节点	要问的问题	常见风险
数据产生点	谁录入、谁校验、是否涉及敏感个人信息	源头字段过度收集、质量责任不清
系统存储点	存在哪个库、谁有管理权限、是否有备份	权限过大、备份裸奔、历史库无人管
接口交换点	通过哪个接口、传哪些字段、频率多高	接口字段过宽、调用方不清、日志不足
文件导出点	谁导出、导出什么、保存多久、是否外发	Excel 扩散、审批缺失、无法追回
外部接触点	哪个厂商或平台接触、依据是什么	委托处理不清、远程操作不可追溯

三、最容易漏掉的是“边缘数据”

医院的数据安全盲区，往往不在最核心的生产库，而在那些平时没人太注意的边缘位置。

比如测试环境。系统升级、接口联调、厂商排障时，生产数据可能被复制到测试库。如果没有脱敏、没有访问控制、没有清理机制，测试库就会变成一个低防护的数据仓库。

比如报表和 Excel。业务科室为了统计、质控、科研，可能导出大量包含患者信息的表格。表格离开系统以后，原来的权限控制、日志审计和访问边界基本都会变弱。

比如日志和截图。厂商排查问题时经常需要日志、数据库片段、页面截图，而这些材料里可能包含姓名、证件号、诊断、费用、手机号等信息。

比如备份和历史系统。医院更换系统后，旧系统可能不再频繁使用，但历史数据仍然存在。备份数据也常常保存了完整敏感信息，一旦权限控制不足，风险不比生产库小。盘点数据资产时，不要只看“正在运行的系统”，还要看数据被复制、导出、备份、测试、共享之后去了哪里。

边缘数据之所以危险，是因为它往往处在“业务觉得只是临时用一下，技术觉得不是核心系统，管理觉得已经离开正式流程”的灰色地带。

比如一个用于接口联调的测试库，最初可能只是为了让厂商排查问题方便；一个科室常用的统计 Excel，最初可能只是为了月度质控；一个历史系统备份，最初可能只是为了防止迁移后查不到旧数据。但时间一长，这些数据可能没有固定责任人、没有访问复核、没有脱敏要求、没有删除期限，最后就变成医院数据安全的暗面。

可以用下面这张表做一次边缘数据自查：

边缘位置	典型表现	需要补的控制
测试环境	复制生产库用于升级、联调、排障	数据脱敏、访问期限、环境隔离、到期清理
报表和 Excel	科室导出后本地保存、微信/邮件传递	导出审批、字段最小化、水印、保存期限
日志和截图	排障材料包含患者姓名、诊断、费用等	日志脱敏、截图规范、厂商接收登记
备份和历史库	系统下线后数据仍长期保留	访问授权、加密保存、恢复演练、销毁策略
科研数据集	课题结束后继续留存或复用	项目边界、二次使用审批、去标识化、归档删除

这张表的意义不在于一次性查完所有角落，而是提醒医院：凡是数据离开原系统、离开原场景、离开原权限控制，就要重新评估风险。

四、给医院一张可落地的台账字段表

医院可以先不用追求一次性做成很复杂的平台，先用一张结构化台账把核心问题问清楚。

字段	说明
数据类别	患者身份、诊疗、检验、影像、医保、科研、运营等
数据集名称	具体到病历首页、检验结果、影像报告、随访记录等
所属系统	数据当前主要存放系统
产生部门	数据由哪个业务环节产生
责任部门	谁负责判断数据使用合理性
使用场景	诊疗、管理、科研、上报、共享、AI 训练等
数据规模	单条、批量、全院、区域级
敏感程度	是否包含敏感个人信息或高风险医疗信息
流向	是否进入接口平台、数据中台、科研平台、第三方
导出方式	是否允许导出，导出是否审批和留痕
第三方接触	哪些厂商或外部单位可能接触
控制措施	权限、脱敏、加密、审计、备份、销毁要求

这张表不是为了好看，而是为了支撑后面的分类分级、审批、脱敏、审计和应急。

如果台账里没有“使用场景”和“流向”，后面很难做数据安全管理；如果没有“责任部门”，审批就没有业务判断依据；如果没有“控制措施”，分类分级就无法落地。

更具体一点，台账字段至少要服务四件后续工作。

第一，服务分类分级。没有数据类别、敏感程度、影响范围和业务重要性，分类分级只能停留在经验判断。医院很容易把所有医疗数据都写成“重要”，结果保护动作反而没有差异。

第二，服务权限治理。没有责任部门、使用场景、岗位角色和导出方式，权限治理就只能按系统角色粗放配置，很难做到“诊疗可看、科研可用但受控、第三方可运维但不接触明文数据”。

第三，服务审计追溯。没有流向、接口、导出和第三方接触信息，日志平台即使采集了大量记录，也很难判断哪些访问值得重点关注，哪些行为需要复核。

第四，服务应急处置。发生数据泄露或误用时，如果台账能说明数据范围、流向、接触方和控制措施，医院就能更快判断影响范围、定位责任链条、组织通报和整改。

可以把数据资产台账理解成一张“后续建设索引表”：

台账字段	后续能支撑什么
数据类别、敏感程度	分类分级、脱敏策略、访问强度
产生部门、责任部门	审批归口、业务判断、整改责任
使用场景、字段范围	最小必要、科研审批、共享评估
流向、接口、导出方式	接口监测、导出管控、数据流向图
第三方接触、控制措施	委托处理管理、远程运维审计、合同和退出要求

做到这一步，资产盘点才不只是“做了一张表”，而是给后面的安全建设打了一层地基。

五、合规要求落到资产盘点，就是“每年梳理、全面覆盖、动态更新”

医疗数据资产盘点不是为了做项目材料，而是有明确合规要求。

《医疗卫生机构网络安全管理办法》要求医疗卫生机构对数据资产进行全面梳理，并结合数据重要程度和遭到破坏后的危害程度，建立本单位数据分类分级标准。这里的关键词不是“有一张表”，而是全面梳理、本单位标准、持续管理。

《数据安全法》要求建立数据分类分级保护制度。医院如果不知道自己有哪些数据、数据在哪里流动、哪些数据被批量导出或共享，就很难谈分类分级保护。

《个人信息保护法》也要求个人信息处理活动目的明确、范围最小、采取必要安全措施。要做到“最小必要”，前提是医院知道某个场景到底用了哪些字段、多少数据、流向哪里。

因此，资产盘点至少要回应这些合规问题：

合规要求	盘点时要补的内容
数据分类分级	不只列系统，还要列数据类别、数据集、重要程度和敏感程度
全生命周期管理	记录数据产生、存储、使用、传输、共享、备份、销毁环节
最小必要原则	标明每个场景实际需要的字段和数据范围
委托处理管理	记录哪些第三方可能接触数据、接触方式和责任边界
日志和追溯	记录数据访问、导出、接口调用、运维操作的留痕要求
风险评估	对批量数据、敏感数据、对外共享、AI 训练等场景单独标记

换句话说，医院的数据资产台账不能只是“资产清单”，还要能支撑合规审计。

这里还要注意一个现实问题：合规检查和事件复盘关注的通常不是“你有没有台账”，而是“台账能不能解释现场”。

如果台账写着某类数据只用于院内诊疗，但实际已经被导出到科研平台，说明台账没有动态更新；如果台账写着第三方不能接触真实数据，但排障日志里出现了患者姓名和诊断，说明委托处理和运维控制没有落地；如果台账写着数据需要审计，但实际只有系统登录日志，没有数据访问和导出日志，说明“可追溯”还停在表面。

因此，资产盘点不能做成一次性专项。比较稳的做法，是把它嵌入医院日常变更流程：

触发场景	台账要同步更新什么
新系统上线	新增数据类别、责任部门、接口、权限和日志要求
新接口开通	新增数据流向、调用方、字段范围、频率和留痕方式
新科研项目启动	新增数据集、审批依据、脱敏方式、保存期限
第三方入场或变更	新增接触系统、账号权限、远程方式、退出要求
系统下线或迁移	更新历史数据保留、备份、查询和销毁策略

这样做的好处是，台账会跟着业务变化一起动，而不是项目验收时漂亮、半年之后失真。

六、盘点结果要能回答四个追问

一轮资产盘点做完，不建议只看“填了多少行”。更应该看它能不能回答四个追问。

第一，能不能说清“高风险数据在哪里”。

医院至少要知道病历、检验、影像、医保、基因、随访、科研队列等高敏感数据分布在哪些系统、哪些平台、哪些导出文件和哪些第三方环境里。如果只能说“在 HIS、EMR、PACS 里”，颗粒度还不够。

第二，能不能说清“数据为什么被使用”。

同样是诊疗数据，用于门诊看诊、质控分析、科研建库、医保上报、AI 训练，管理要求完全不同。盘点结果如果没有场景，就无法支撑最小必要和目的限定。

第三，能不能说清“数据离开系统后如何控制”。

很多医院的正式系统有权限、有日志、有账号管理，但数据一旦导出成文件、进入测试库、进入厂商排障包，控制强度就明显下降。资产盘点必须把这些离开系统后的状态纳入视野。

第四，能不能说清“出了问题找谁”。

每一类关键数据、每一个高风险流向、每一个第三方接触点，都应该有责任部门和联系人。没有责任归口，后续告警、审批、整改和应急都会卡住。

盘点质量	典型表现	后续影响
低质量盘点	只有系统名称和责任人	只能用于资产目录，难以支撑数据安全
中等质量盘点	有数据类别和敏感程度	可以初步分类分级，但场景和流向不足
较高质量盘点	有场景、流向、第三方、控制措施	能支撑权限、脱敏、审计和风险评估
可运营盘点	能动态更新，并与审批、变更、审计联动	可以进入持续治理和安全运营