⏱ 预计阅读：8 分钟
图注：OHIF 官方文档首页，展示项目的 Viewer 定位。
上期看 Medplum 时，我们讨论的是 FHIR（医疗数据交换标准）如何成为医疗应用底座。这一期换到影像场景：很多团队以为影像产品的难点是“把片子显示出来”，但真正进入医院后，问题往往变成另一件事。
为什么会研究 OHIF Viewer？
OHIF Viewer 是 Open Health Imaging Foundation（开放健康影像基金会）维护的医学影像查看器项目，GitHub（代码托管平台）仓库是 OHIF/Viewers。本次核验时，它有 4,277 个 Star（收藏数）和 4,306 个 Fork（分叉数），latest release（最新发布版本）是 2026 年 8 月 3 日的 v3.12.11，许可证是 MIT（麻省理工许可证）。
它最吸引我的地方，不是“浏览器里能打开 CT（计算机断层扫描）或 MRI（磁共振成像）”。这件事已经不是最稀缺的能力。
OHIF Viewer 真正值得研究的点，是它把医学影像查看这件事拆成了可替换的 extension、mode 和 data source。这对做影像 AI（人工智能）产品的人很关键：你最后要接入的不是一张图，而是一套科室工作流。
为什么是现在？因为影像 AI 团队正在从“模型输出一个结果”走向“结果要嵌进阅片、标注、复核和报告”。如果 viewer 这一层没有可扩展边界，后面的模型、质控和临床反馈都会被前端页面拖住。
图注：OHIF/Viewers 仓库页，本次核验 Star、Fork、许可证和更新时间。
OHIF Viewer 是什么？
OHIF Viewer 的 README（项目说明文件）把自己定义为 zero-footprint medical image viewer（零安装医学影像查看器）：用户不需要在本地装一个传统桌面软件，就可以通过浏览器查看医学影像。
它默认支持 DICOMweb（基于 Web 的 DICOM 影像访问协议）。DICOM（医学影像传输与存储标准）是医院影像系统里最核心的标准之一，DICOMweb 则让影像归档、浏览器 viewer 和上层应用可以通过 Web 接口协作。
它的关键能力可以拆成三类看。
第一类是显示能力。OHIF Viewer 支持 2D（二维）、3D（三维）、MPR（多平面重建）、MIP（最大密度投影）、WSI（全切片病理图像）和动态体积等查看方式。
第二类是临床工具。它支持测量、分割、窗宽窗位、DICOM Structured Report（DICOM 结构化报告）和 PDF（便携式文档格式）渲染等能力。
第三类是工程扩展。README 明确说，几乎所有核心能力都建立在 extension system（扩展系统）上。这意味着团队不一定要 Fork 整个项目，才能把自己的工具、面板、视图或流程接进去。
OHIF Viewer 的核心是怎么工作的？
可以把 OHIF Viewer 想成一个浏览器里的影像工作台。
输入端，项目要处理来自 PACS（医学影像归档与通信系统）、云端影像档案或研究数据集的 DICOM/DICOMweb 数据。中间层，它要把不同来源的数据适配成 viewer 可以理解的对象。显示层再决定用 2D、3D、MPR、WSI 或视频等方式呈现。
真正复杂的地方在工具层和工作流层。放射科可能更在意阅片、测量和报告；肿瘤场景可能更在意病灶追踪；科研平台可能更在意标注、导出和自动化验证。
如果这些差异都写死在一个前端页面里，项目迟早会变成难维护的大杂烩。OHIF 的解法是把这些差异拆成 extension（扩展模块）、mode（使用模式）和 data source（数据源）三个工程边界。
图注：白板图拆解 OHIF 从数据接入到测试反馈的完整链路。
这里的黑盒拆解不是为了“架构好看”，而是为了让每个环节都能被替换、测试和追责。数据从哪里来，界面如何摆，工具怎么组合，测量结果如何输出，质量怎么验证，都有相对清楚的位置。
深度解析：扩展机制为什么是关键？
第 4 章不讲“工程底座”这个大词，直接讲 OHIF Viewer 最有辨识度的机制：extension/mode/data-source 三件套。
Extension（扩展模块）负责把工具、面板、视口、命令接入 viewer。比如一个团队想加入新的测量工具，或者给某类影像加一个专用面板，理论上应该优先通过 extension 做，而不是复制整个项目另开一套。
Mode（使用模式）负责组织一类工作流。放射、肿瘤、显微、动态体积不是同一个阅读路径。一个好的 viewer 不应该假设所有科室都用同一种布局、同一组按钮、同一种输出。
Data Source（数据源）负责接入不同影像来源。DICOMweb、DICOM JSON（DICOM 的 JSON 表达形式）和云端影像服务背后，权限、性能、缓存和错误处理都不一样。把它们隔离成数据源接口，才能减少上层页面对底层存储的耦合。
OHIF 的工程启发是：医疗软件里的“复杂”，常常不是模型复杂，而是流程差异复杂。你可以把一个模型封装成 API（应用程序接口），但你很难用一个固定页面覆盖所有科室、所有报告习惯和所有数据来源。
这类设计还有一个现实价值：当医院要求改一个工具位置、换一个影像源、增加一种专科路径时，团队可以先判断应该动 extension、mode 还是 data source，而不是在同一个页面里层层加判断。
图注：白板图展示 Extension、Mode 和 Data Source 三类接口关系。
这也是为什么 OHIF README 会强调可配置、可扩展和不必私有维护一个大 Fork。少 Fork 不是偷懒，而是降低长期维护成本；多配置也不是堆参数，而是承认医院工作流天然不一致。
项目最新更新了什么？
本次核验到的最新 release 是 v3.12.11，发布时间是 2026 年 8 月 3 日。与此同时，仓库在同一天还有 3.14.0-beta.8 相关版本更新提交。
这个信号说明两件事。
第一，OHIF 不是一个停在 README 里的老项目，而是仍在维护 release 和 beta（测试版本）节奏。对基础 viewer 这类项目来说，稳定发布比一次性功能演示更重要。
第二，README 里专门写到 Cornerstone3D（影像渲染工具链）集成测试：Playwright（浏览器自动化测试工具）可以跑端到端测试，验证 OHIF 和 Cornerstone3D 跨仓库变化。这个细节很工程化，因为影像 viewer 的风险经常出在“看起来能打开”，但切片、视口、工具状态或测量结果在真实路径里错了。
图注：OHIF v3.12.11 Release 页面，支持近期活跃度判断。
图注：官方 Extension 文档页面，支撑本文核心机制分析。
谁适合研究这个项目？
| 情况 | 建议 |
|---|---|
| 影像 AI 团队要做原型 viewer | 值得先研究 OHIF 的 mode 和 extension，而不是从零画页面 |
| 已有 PACS 或云端影像服务 | 先确认 DICOMweb、权限、缓存和性能边界 |
| 科研团队要做标注平台 | 可以借鉴工具/面板/输出分层，但要补数据治理 |
| 产品团队要接医院流程 | 不要只看 demo，要先画出目标科室的工作流 |
| 商业化团队评估采用 | MIT 许可证友好，但仍要确认依赖、数据合规和临床验证责任 |
| 临床团队想直接替代诊断 | 不适合。它是 viewer 底座，不是临床结论本身 |
主要风险也很清楚。
第一是版本依赖。影像 viewer 依赖渲染、工具状态、浏览器能力和后端数据源，升级不能只看 npm（Node 包管理生态）版本号。
第二是证据边界。OHIF 可以支撑影像查看和工作流组织，但不等于证明某个 AI 模型有临床效果。
第三是数据合规。接入真实患者影像时，权限、审计、脱敏和院内部署责任不能交给前端框架自动解决。
图注：白板图整理适用人群、前置能力、风险和采用建议。
所以，研究 OHIF 的正确姿势，不是问它能不能替代医院系统，而是问它能把你自己的影像工作流拆清楚到什么程度。
写在最后
本期一句话：OHIF Viewer 最值得学习的，不是网页里能看医学影像，而是它把影像工作流拆成了可配置、可扩展、可验证的工程接口。
如果你正在做影像 AI 产品，一个很具体的问题是：你的系统现在最难改的部分，到底是模型、数据源、页面布局、临床工具，还是每个科室都不一样的工作流？
这也是 OHIF Viewer 给我的最大提醒：医疗 AI 进入真实场景后，工程边界比单点功能更早决定产品上限。