预计阅读：8 分钟
图注：Medplum 官方文档把项目定位为医疗开发者平台。
为什么会研究 Medplum？
前几期已经看过药物发现、医学影像、电子病历和患者侧研究工具。这一次我想换一个更贴近医疗 AI 落地底层的问题：如果一个团队要做真正能接进医院、患者、实验室和第三方系统的应用，难点到底是不是再写一个漂亮页面？
Medplum 值得拿出来讲，是因为它把答案放在了更底层的位置。
它不是一个单点功能，也不是一个单独的 EHR（电子健康记录系统）页面。它更像一套面向开发者的医疗应用底座：FHIR（医疗数据交换标准）资源模型、认证授权、临床数据仓库、API（应用程序接口）、SDK（软件开发工具包）、React（前端组件库）和 Bots（自动化任务）被放在同一个工程里。
这类项目最值得看的地方，不是它能不能快速做出一个界面，而是它有没有先把医疗数据对象、权限边界和流程触发点固定下来。
这也是为什么我没有继续选影像项目。影像已经很重要，但很多医疗 AI 产品最后卡住的地方，其实是“数据从哪里来、谁能看、怎么改、改完怎么触发下一步、出了问题怎么追溯”。
Medplum 是什么？
Medplum 官方 README（项目说明文件）把它定义为一个 developer platform（开发者平台），目标是让团队更灵活、更快地开发 healthcare apps（医疗健康应用）。
它的核心能力可以拆成 3 组。
第一组是数据底座。Medplum CDR（Clinical Data Repository，临床数据仓库）负责以标准化方式存放医疗数据。它不是把病历当普通表单塞进数据库，而是围绕 FHIR 资源组织对象，例如 Patient（患者）、Encounter（就诊）、Observation（检查或指标）、DiagnosticReport（诊断或检验报告）、ServiceRequest（服务申请）。
第二组是接口和开发工具。Medplum API 以 FHIR 为基础，SDK 和 React 组件帮助开发者更快做应用。仓库结构里能看到 server、core、fhirtypes、react、react-hooks、app、cli、hl7、agent 等包，这说明它不是只提供后端服务，而是把前端、类型定义、命令行、集成和自动化都纳入同一个 monorepo（单仓库工程）里。
第三组是身份和自动化。README 明确写到 Medplum Auth 支持 OAuth（开放授权协议）、OpenID（开放身份认证协议）和 SMART on FHIR（面向医疗应用的 FHIR 授权框架）。同时，Medplum Bots 可以在服务端运行应用逻辑。
换句话说，Medplum 关心的不是“页面上显示什么”，而是“一个医疗对象在系统里如何被创建、读取、授权、触发和审计”。
Medplum 的核心是怎么工作的？
理解 Medplum，可以先把它想成 6 层链路。
第一层是输入。患者、医生、设备、实验室、第三方系统都会产生数据。普通业务系统很容易把这些数据拆成互不兼容的表单；Medplum 的第一步，是把它们转成可识别的 FHIR 资源。
第二层是标准层。Patient、Encounter、Observation、DiagnosticReport、ServiceRequest 这些资源不是随便起名的字段，而是一套有结构、有引用关系的医疗对象模型。比如一次就诊可以关联患者、医护、检查结果和后续任务。
第三层是服务层。CDR 存储数据，REST API（表述性状态转移应用程序接口）、GraphQL（图查询接口）和 Search（检索能力）让应用可以读写这些资源。
第四层是身份权限。医疗系统里“能不能访问”比“能不能展示”更重要。OAuth2/OIDC（授权与身份认证协议组合）、SMART on FHIR 和 AccessPolicy（访问策略）决定了谁能在什么上下文里操作什么数据。
第五层是开发者工具。SDK、React 组件、CLI（命令行工具）和 Bots 让团队可以围绕同一套资源对象开发门户、工作台、自动化任务和系统集成。
第六层是输出。患者门户、临床工作台、实验室系统、保险或第三方连接，最后都不是孤立页面，而是围绕同一组资源和权限运行。
这条链路对医疗 AI 尤其关键：没有稳定的资源模型和权限边界，模型能力越强，接入真实流程时越容易变成不可追踪的临时脚本。
深度解析：FHIR 资源中枢为什么是关键？
很多人第一次看 FHIR，会把它理解成一种医疗数据格式。这种理解没有错，但不够。
在 Medplum 这样的工程里，FHIR 更像“医疗应用的对象边界”。Patient 不是一行用户信息，Encounter 不是一次页面访问，Observation 也不是一个孤立数值。它们之间有引用关系，有搜索语义，有权限语境，也有后续流程。
这会改变医疗应用开发的起点。
如果没有资源中枢，团队常见做法是：先做一个患者列表，再做一个报告页面，再补一个权限表，再写一个接口同步实验室结果。短期看速度很快，长期看每个功能都在制造自己的数据模型。
Medplum 的工程取向刚好相反：先把资源类型、引用关系和 API 语义放在底层，再让 App、SDK、Bots 和集成围绕它们工作。
这对 AI 应用也很现实。一个大模型总结检验报告，输入到底是 DiagnosticReport，还是 Observation，还是医生手工粘贴的一段文本？总结结果要写回哪里？谁能看？能不能触发复核任务？是否留下审计日志？
FHIR 的价值不是让数据“看起来标准”，而是让每一次读取、写入、授权和自动化触发都有明确对象。
所以 Medplum 最值得借鉴的不是某个具体页面，而是它把“数据对象、访问策略、开发体验、自动化逻辑”压在同一套工程语言里。这比单独做一个医疗 SaaS（软件即服务）功能更难，也更接近真实医疗应用的底层约束。
项目最新更新了什么？
图注：Medplum 最新 release 为 v5.1.26，发布于 2026-07-10。
本次核验时，Medplum 最新 release（发布版本）是 v5.1.26，发布时间是 2026-07-10。Release 记录里有 3 个变化值得注意。
第一，fix(server): honor target type in _include and _revinclude。这不是一个营销功能，但很说明项目性质。_include 和 _revinclude 是 FHIR 搜索里处理资源引用关系的重要机制。服务端如果不能正确尊重 target type（目标资源类型），资源联查就可能出现语义偏差。
第二，feat(provider): Include DiagnosticReports and ServiceRequests in labs。这说明 Medplum 近期仍在补临床业务对象，尤其是实验室相关流程里的报告和服务申请。
第三，最近可见 commit 是 2026-07-18 的 React 组件修复，涉及 ThreadInbox（消息线程收件箱）和 ListWithDetailPane（列表详情面板）。这类更新说明它仍在持续维护前端工作流组件，而不只是后端 FHIR 服务。
图注：发布前核验 Medplum 为 2,532 Star，Apache-2.0 许可。
这几个更新合在一起看，Medplum 的近期活跃点不是“又加了一个大功能”，而是在继续打磨 FHIR 查询语义、实验室资源覆盖和应用工作台体验。
谁适合研究这个项目？
| 情况 | 建议 |
|---|---|
| 想做 FHIR 原生患者门户、临床工作台或医疗数据应用 | 值得重点研究资源模型、权限和 SDK |
| 想把 AI 能力接入真实医疗流程 | 先看 DiagnosticReport、Observation、Task 和 Bot 如何串起来 |
| 团队缺少 FHIR 建模经验 | 先补标准理解，不要直接把旧表结构硬套进去 |
| 准备私有化或院内部署 | 提前评估运维、审计、备份、租户隔离和权限策略 |
| 只想找一个完整 HIS（医院信息系统）替代品 | 不适合直接当 HIS 使用，它更像开发平台和数据底座 |
| 涉及真实患者数据 | 必须另做数据脱敏、合规评估和人工验证 |
Medplum 的许可证是 Apache-2.0（Apache 许可证 2.0），对商业使用相对友好。但许可证友好不等于合规自动完成。医疗数据的访问控制、日志、数据驻留、患者授权和院内制度，仍然需要项目团队自己负责。
它降低的是医疗应用开发和系统集成门槛，不替代医院的数据治理和临床责任。
写在最后
本期一句话：Medplum 最值得看的不是页面，而是它把 FHIR 资源、权限边界、API 和自动化放进同一套开发底座。
如果说前几期的项目更多在回答“模型、影像、病历、患者数据分别怎么做”，Medplum 回答的是另一个更底层的问题：当医疗 AI 真的要进入业务系统时，它依附在哪一套数据对象和权限关系上？
这也是我认为它值得研究的原因。
医疗 AI 的落地难点，很多时候不是缺一个模型，而是缺一条能被审计、能被授权、能被持续维护的数据和流程链路。
你的项目里，今天的 AI 输出，能不能明确追溯到一个 FHIR 资源、一次授权判断和一条可审计的业务流程？