医院PACS影像存储扩容怎么做？从法定保存年限倒推容量与IOPS

医院的存储告急，通常不是在机房发现的，是在放射科发现的——医生点开一张三个月前的 CT，转圈。这时候信息科才去看容量，发现已经用到 85%。医院PACS影像存储扩容真正难的地方不在"买多大盘"，而在于：法定要存多少年、一年会长多少、在线调阅要什么性能、归档能不能用慢盘。这四件事算清楚了，买多少、怎么扩是水到渠成的。这篇写给医院信息科、设备科，以及要给医院做存储方案的集成商。

需要先说明：以下容量与性能数字都是测算方法加示例假设，不是任何一家医院的实测值。真实项目要按你自己的检查量和设备参数重算。

先看政策底线：病历到底要存多少年

容量测算的起点不是"现在剩多少盘"，而是"按规定必须留多久"。

按《医疗机构病历管理规定（2013年版）》，门诊病历保存不少于 15 年，住院病历保存不少于 30 年（原文见国家卫健委官网，链接在文末）。天津市卫健委 2026 年 2 月的公开报道里也重申过这条线：互联网诊疗场景下病历至少保存 15 年。

划重点：影像作为病历的一部分，同样受这条规定约束。 很多医院早期按"存 3 年就够了"做的容量规划，现在正在集体补课——这就是为什么近几年医院的"存储扩容"招标公告一直没停过。

从公开招标公告能看到这种常态化需求：四川大学华西天府医院的存储扩容采购、中国医学科学院肿瘤医院的存储扩容采购、遵义市播州区人民医院的 PACS 存储扩容竞争性磋商、广东省农垦中心医院的存储扩容招标、石门县人民医院的"数据迁移和存储扩容改造"——注意最后这个项目名，它把真正的难点写出来了：不只是加盘，还要迁移。

第一步算容量：不是算总检查量，是算"原始 + 备份 + 副本"

一个能用在预算里的容量公式，大概是这个形状：

目标容量 = 年新增数据量 × 保存年限 × (1 + 冗余系数) × (1 + 副本系数)复制

四个变量各自怎么定：

年新增数据量，按模态分别估更准。DICOM 文件的大小差异极大——一张 DR 平片和一次薄层 CT 能差两三个数量级，同一次检查的层数、是否增强、压缩方式都会影响。所以不要用"平均一张几 MB"拍脑袋，要么让 PACS 厂商从库里导真实统计，要么抽样十个典型检查实测。

举个带假设的算例（假设值，非实测）：某院日均检查 800 例，加权后单例平均产生 80MB 影像数据，一年 300 个工作日——

年新增 = 800 × 80MB × 300 ≈ 19.2 TB/年复制

保存年限：门诊线 15 年、住院线 30 年。实务上通常按更长的那条做规划，或至少保证在线可调阅的部分覆盖近期年限、归档覆盖全程。

冗余系数：RAID、快照、纠删码都会吃掉可用容量。具体倍数取决于阵列方案，这一点必须让存储方案方给出明确口径，不能含糊。

副本系数：这是最容易被漏掉的一块。为了容灾或离线保存，同一份数据往往要存两份甚至三份（本地 + 异地 + 离线归档）。

把上面四项代进去，19.2 TB/年 × 15 年，再乘冗余和副本——目标是几百 TB 量级，不是几十 TB。这就是为什么医院存储扩容项目的金额通常不小。

第二步定性能：PACS 存储和普通文件存储差在哪

容量算完只是及格，性能定错了照样被投诉。

PACS 的读写特征和普通文件服务器完全不同：

说白了：在线层看 IOPS 和时延，归档层看每 TB 多少钱。两者用同一套介质，一定有一头是浪费的。

判断在线层够不够，有一个比看参数表更实用的办法：问放射科医生的主观感受，同时抓存储的实际时延。 如果调阅一张近期影像要等两三秒，那不是网络问题就是在线层 IOPS 不够——先查存储，别急着换交换机。

服务器和存储怎么分工：别把两件事混在一个预算里

医院影像系统里，"服务器"和"存储"是两笔账，混在一起最容易出问题。

服务器负责的事：PACS 应用、数据库、DICOM 网关、AI 辅助诊断推理（如果有）。它们的瓶颈在 CPU、内存、如果是 AI 应用则在 GPU。

存储负责的事：影像文件的存取。瓶颈在 IOPS、时延、容量和可靠性。

一个常见的错配是：把影像文件也放在 PACS 服务器的本地盘上。 早期小体量能跑，一旦数据量上来，应用和文件抢同一块盘的 IO，两边都慢。合理的做法是影像文件放独立的存储层，服务器只跑应用。

按规模给三档参考（量级参考，非报价）：

扩容的三种做法，各自什么时候用

做法一：原地加盘。最省事，代价最小。适用条件：阵列还有空槽位、控制器性能有余量、容量缺口在 50% 以内。如果控制器已经跑在高负载，加盘只会让瓶颈更明显。

做法二：加一层新阵列，做分层。把新买的闪存放在线层，老阵列降级做归档。这是性价比通常最好的一种——不浪费已有投资，又解决了在线性能。 适用条件：现有阵列还能用、只是不够快或不够大。

做法三：整体替换 + 数据迁移。石门县人民医院那个"数据迁移和存储扩容改造"就是这一类。适用条件：老设备已过保、控制器成了硬瓶颈、或者要从 SAN 架构换到分布式/对象存储。

这里必须说一句实话：做法三的风险比其他两种高一个量级。 影像数据迁移不是拷文件——要保证迁移期间新旧系统都能调阅、要校验完整性、要有回滚方案。迁移窗口通常只能选在夜间或周末，而且必须先在测试环境跑通一遍。 预算里如果没给迁移留出人力和时间，项目大概率会延期。

验收怎么验：加一张"能不能调阅"的清单

存储扩容的验收，很多院只验了"容量对不对"，漏了"能不能用"。建议按这几项走：

第六项最容易被跳过，也最危险。 新系统上线后老数据打不开，是影像存储项目里最难收场的故障之一。

商红在这件事里的位置，以及不能做的部分

商红科技（深圳）有限公司持有软件著作权「医疗大数据分析挖掘系统」（可在天眼查版权页查到登记信息），公司对外也将医疗列为核心服务行业之一。除这条公开知识产权外，本文不引用任何具体医院项目——医疗客户信息敏感，没有授权就不写。

我们能做的是这一段：按你的真实检查量做容量测算、按调阅时延要求定在线/归档分层、给出整机与存储的配置方案、现场部署、验收配合，以及三年维保与 7×24 响应（售后专线 400-0755-816）。在深圳、惠州、广州都有办公室，珠三角项目可上门。

不能做、也不该由我们做的：PACS/RIS 软件本身、DICOM 协议适配开发、AI 辅助诊断算法。这些是医疗信息化厂商的活。我们补的是底层算力与存储这一段。

还有一类情况我们不合适：如果你只是要加几块硬盘、没有架构调整需求，找原厂或现有维保商处理会更划算——我们收的服务成本摆在那。

常见问题

法定保存年限到底怎么算？

《医疗机构病历管理规定（2013年版）》的口径是门诊病历不少于 15 年、住院病历不少于 30 年。影像作为病历组成部分同样适用。具体到某个项目，建议以本院医务科和上级卫健部门的解释为准，因为不同地区在实施细则上可能有差异。

能不能用公有云存影像？

技术上可行，但要先过合规关。患者影像属于敏感个人信息，是否允许出本院/出本地，要看医院的数据管理规定和当地卫健部门的要求。这不是技术选型问题，是合规问题——拿不准就先别上。

归档层用 HDD 会不会太慢？

归档层的定位就是"不常调阅"，用 HDD 是正常的。关键是分层策略要清楚：哪些数据在 SSD 上、多久之后下沉到归档、下沉后调阅要走什么流程。策略不清楚，就会出现"该快的没快、该省的没省"。

扩容要不要停机？

取决于阵列是否支持在线扩容和现有架构。做法一和做法二通常可以在线做；做法三（整体替换）几乎一定要停机窗口。招标前就要把停机窗口写进需求，否则实施时会和临床排班冲突。

旧阵列能不能继续用？

能，但要评估两件事：控制器性能是否已成瓶颈、是否还在质保期。过保设备做归档层可以接受，做在线层不建议——在线层最怕的就是故障时备件等不到。

最后

影像存储这件事，算对了容量和分层，剩下的就是买和装；算错了，就是反复扩容、反复被投诉。建议在做预算前先把三件事定下来：真实年新增量、要覆盖的保存年限、在线层的时延目标。 这三样有了，配置单基本就定了。

如果你正在做扩容立项，可以把这三个数发给我们，我们帮你把容量和分层算一遍，并告诉你哪些部分不需要换。这一步不收费。

全国统一服务热线：400-0755-816　把你的检查量与保存要求发给我们，获取存储配置建议

延伸阅读：

• 容灾备份解决方案

• 私有云解决方案

• 大数据 HPC 解决方案

• 售前服务：一份方案从需求到落地要经过什么