病历屏幕上的每一个空白字段，背后都有一连串需要先确定的事项：问题究竟指什么，哪些答案有效，某个数值该用什么单位，临床人员应当看到哪种语言，以及这项结果能否继续与另一间病房、另一个国家采集的数据相比较。精致的界面可以把这些决定藏起来，却无法让它们消失。

OpenMRS 的特别之处，在于它把这项语义工作放在接近系统核心的位置。人们通常称它为开源电子病历系统，但若只把它理解成“医院应用”，便低估了它的范围。这个项目持久的根基，是一套临床数据语法、模块化后端、可组装的参考应用，以及一个由实施者组成、把这些组件适配到本地医疗工作的社区。OpenMRS 因而拥有少见的灵活性，本地技术与临床治理也从一开始就成为产品的一部分；等到后期采购附加服务时，这项责任早已存在。[2][3]

封面照片拍摄于 2004 年，画面是肯尼亚埃尔多雷特的 Moi 大学教学与转诊医院。OpenMRS 源于这处医院的工作，也源于 Partners In Health 在其他地区运行的系统。与软件截图相比，这座狭长的医院建筑更能说明项目的缘起：项目所服务的机构各有患者、工作流程、语言、报告责任和基础设施，任何一家供应商的默认界面都容纳不了这些差异。[1]

共同项目始于已经无法继续扩展的系统

2004 年 2 月，肯尼亚西部 AMPATH 的患者数据量已经超出当时用于监测医疗工作的 Microsoft Access 工具所能处理的范围。Burke Mamlin 与 Paul Biondich 开始在埃尔多雷特设计新的病历数据模型。与此同时，Partners In Health 已有一套基于 Web 的病历系统，服务于秘鲁的结核病照护和海地的 HIV 照护，但这套自行开发的软件即将扩展到另外几个国家，维护压力随之而来。两支团队于 2004 年 9 月在 MedInfo 会议上相遇，并商定共同开发一个平台；此后的合作采用了开源模式。PIH 的临床工作流程经验，由此与 AMPATH 的数据录入及报告需求汇合。[1]

这段起源至今仍界定着项目的范围。OpenMRS 的出发点，是多家机构面对共同的基础难题，同时又无法假定彼此采用相同的表单、术语、基础设施或医疗项目。如今，社区维护核心平台、参考应用、共享模块、开发框架和基础设施；实施伙伴则在这套基础上，部署适合具体国家、卫生系统或医疗机构的版本。[2]

其中有一条实用的分界线：共享机制与本地规则。患者身份、诊疗接触、观察记录、API、模块加载和扩展契约都可以共享。接诊时哪些问题必须回答，结核病项目如何命名某个治疗状态，哪些实验室代码具有权威性，谁可以编辑表单，以及卫生主管部门的报告必须呈现什么，则属于本地规则。一次 OpenMRS 部署能否顺利运转，取决于团队是否清楚每项决定应当落在分界线的哪一侧。

概念字典才是真正的中心

OpenMRS 每次实施的核心，都是概念字典。一个概念可以表示临床问题、编码答案、检查、诊断、所见、药物、诊疗操作、带单位的数值，或其他数据元素。字典记录名称、数据类型、类别、同义词、语言区域偏好，以及它与参考术语体系的映射。表单、医嘱、摘要和报告随后共同引用这些概念，免得每次都为一个字段另行发明一套含义。[3]

到了诊疗接触中，这套模型便有了具体形态。OpenMRS 将诊疗接触（encounter）定义为患者与医疗服务提供者之间的一次特定互动，其中包含类型、时间、地点和服务提供者。观察记录（observation）则记下这次互动中测得或确认的内容，例如血压、症状、影像学所见，或对临床问题的回答。一次就诊可以包含多次诊疗接触，一次诊疗接触也可以包含多项观察记录。[3]

这样的区分既保留适应能力，也继续约束数据的含义。诊所可以直接添加本地医疗所需的概念，省去等待供应商在数据库里增加一列的环节；它还可以为该概念指定某种语言或地区下的首选名称，并在有适用标准代码时建立映射。此后，同一项观察记录可以出现在诊疗现场的表单、患者摘要和报告中，始终保留为同一项数据，避免分裂成三个互不相干的字段。

与此相伴的失效方式同样重要。两个团队若为同一项测量创建细微有别的概念，把同一个概念用于两种含义，省略单位，或没有明确记录映射关系，数据库在技术上仍然有效，分析价值却会逐渐衰减。因此，概念字典需要明确的负责人：临床人员负责界定含义，医疗信息学人员负责建模，还要有一套审核流程，防止每张新表单演变成私有词汇表。OpenMRS 给出了语法和编辑工具；共识仍需团队在实施过程中建立，安装本身无法代劳。

O3 改变前端的组装方式，底层病历保持不变

当前的 O3 前端清楚展现了平台与应用之间的区别。OpenMRS 自己的文档写得很明确：O3 是模块化前端框架，沿用现有后端平台版本。只要平台和所需后端模块达到 O3 的最低版本要求，它就可以在现有 OpenMRS 数据库上运行，并与 O2 UI 使用相同的 REST 和 FHIR API。[4]

O3 部署中面向浏览器的部分由多个独立模块包组装而成。spa-assemble-config.json 负责选择前端模块及其版本。组装过程会生成 importmap.json，告诉应用外壳每个模块包的位置；同时还会生成 routes.registry.json，描述这些模块提供的页面、扩展、模态窗口、工作区和功能开关。应用外壳注册这些元数据，在路由或扩展实际需要时才加载模块代码。模块在 src/routes.json 中声明路由元数据，在 src/config-schema.ts 中声明配置属性；具名扩展槽允许一个模块向另一个模块内部加入界面元素。[5]

这套工作方式给实施团队三种实用手段。配置可以直接改变系统已经支持的行为，上游代码分支保持原样。发行版可以选择纳入哪些持续维护的模块及版本。真正属于本地的工作流程，则可以放入单独模块，经由已声明的路由和扩展槽接入系统。定制内容越贴近这些契约，社区项目负责的部分与本地团队必须维护的部分就越容易辨认。

团队仍然可以为核心代码或社区模块制作私有补丁，但运行方式会随之改变。此后，团队必须负责变基、回归测试、安全修复，以及私有补丁与发行版其他部分之间的兼容性。配置本身同样要纳入版本管理：导入映射指定代码，路由注册表指定功能，后端模块则暴露这些功能所需的 API。三者若更新不同步，登录页面仍会正常加载，而患者病历中的某个扩展却会等到临床人员进入时才报错。

REST 传递数据；FHIR 不会抹去本地语义

OpenMRS 的 REST API 在带版本号的 /openmrs/ws/rest/v1 路径下暴露资源，并以 JSON 经 HTTPS 传输。它是通往 OpenMRS 数据模型的一套务实应用接口。[6] O3 经由 REST 及面向 FHIR 的服务访问数据，避开对数据库表的直接读写，让前端模块始终停留在临床记录的应用层。[4]

FHIR 还开辟了一条面向标准的数据交换通道。OpenMRS FHIR 模块负责在 OpenMRS 对象和 FHIR 资源之间转换，已发表的实施研究记录了实验室互操作、药品发放流程、分析，以及全球卫生系统间数据交换等用途。[7] 它的价值，正建立在内部模型与外部模型存在差异这一事实上。

在这处衔接点上，概念字典依然重要。本地定义的观察记录装进 FHIR 资源之后，通用解释仍有若干前提。它的概念需要有据可查的映射，单位需要一致，接收系统也要理解当前使用的 FHIR Profile 或实施约定。FHIR 可以标准化传输封装和许多资源结构；双方能否在其中表达同一含义，则由术语治理决定。把该模块当作自动语义转换器，只会把歧义转移到网络上。

部署单位是一支社会—技术团队

OpenMRS 可以适应很不相同的规模，灵活性却不等同于省力的安装。2021 年一项实施研究指出，它为医疗运营、报告、互操作性、数据可用性和研究带来了益处，同时也发现多项反复出现的困难：熟练技术人员的配备、临床人员的接受程度、培训、供电与网络连接、本地功能缺口、文档，以及向上游贡献改动。[8] 更早的一项研究覆盖七个国家的十处站点，也得出了相近结论：充分的基础设施很重要，人员配置、规划、培训、工作流程整合和修改系统的能力同样影响深远。[9]

因此，即使试点范围明确，最小团队也要涵盖一名开发者以外的多种角色。团队需要一名临床工作流程负责人，需要有人对概念和报告语义负责，还需要一名运维人员管理服务器、备份、升级、隐私和访问权限，并配备能够培训和支持用户的人员。当配置和持续维护的现有模块表达不了所需工作流程时，开发者才成为必要角色。更大规模或多站点部署还需要发布协调：必须有人判断某个模块版本、后端依赖或元数据变更何时已经就绪，可以一同发布。

OpenMRS 实施指南建议从目标、基础设施、培训、变更管理和持续支持着手。指南提倡分阶段采用系统；对于规模较大的多站点实施，则建议先在单一站点试点，以降低风险。它也提醒实施者，要把部署视为持续工作：安全补丁、模块升级、网络、服务器、人员流动和不断变化的临床实践，在上线后仍会持续发生。[10]

这些建议勾勒出一条合理的采用界线。若一个机构需要拥有并调整自己的临床记录，能够长期维持跨专业实施团队，并且看重共享接口胜过开箱即用的一致性，OpenMRS 会与它相配。若一家医疗机构期待一次免费下载就能附带成品工作流程、术语、集成、监管控制、培训和已经解决的长期运维问题，它与 OpenMRS 的适配度则很低。

这个项目最有力量的开源理念，是让最难的决定各有明确归属。医院可以沿用共同开发的组件，整套系统由共享成果和本地工作共同完成。临床含义归入经过治理的字典；患者事件归入稳定的病历模型；界面功能归入带有已声明路由和扩展点的模块；数据交换在 REST 和 FHIR 契约下完成；本地规则则交给能够解释并维护它们的实施团队。

沿着这条线索看，OpenMRS 超出了一款逐屏与专有套件竞争的医院应用。它让临床语法保持共享，让本地差异清楚可见，也让适配成本在这些差异固化为另一套无法维护的系统之前显露出来。

来源

1. OpenMRS，《简史》——2004 年 AMPATH 与 Partners In Health 的项目起源、早期合作，以及 Moi 大学教学与转诊医院档案照片的出处。
2. OpenMRS，《关于我们》——当前社区、实施伙伴、共享平台与参考工具，以及 OpenMRS Inc. 之间的职责划分。
3. OpenMRS 文档，《概念字典基础》——概念、诊疗接触、观察记录、名称、数据类型、分类、映射和字典治理指南。
4. OpenMRS，《O3 简介》（更新于 2026 年 7 月 9 日）——O3 的范围、它与现有数据库及后端的关系、配置优先设计，以及 REST/FHIR 的职责范围。
5. OpenMRS，《O3 核心概念》——应用外壳、前端模块、导入映射、路由注册表、发行包组装、Module Federation 加载、扩展槽和配置模式。
6. OpenMRS，《REST API》——带版本号的资源路径、JSON 传输，以及访问 OpenMRS 数据模型的应用方式。
7. I. Bacher 等，《FHIRing up OpenMRS: Architecture, Implementation and Real-World Use-Cases in Global Health》，AMIA Joint Summits on Translational Science Proceedings，2024 年——FHIR 模块设计与实施案例。
8. Neha Verma 等，《OpenMRS as a global good: Impact, opportunities, challenges, and lessons learned from fifteen years of implementation》，International Journal of Medical Informatics 149，2021 年——来自多项实施工作的证据，涵盖覆盖范围、益处和限制。
9. Nareesa A. Mohammed-Rajput 等，《OpenMRS, A Global Medical Records System Collaborative: Factors Influencing Successful Implementation》，AMIA Annual Symposium Proceedings，2011 年——来自七个国家十处站点的证据，涵盖基础设施、人员配置、培训、规划和工作流程整合。
10. OpenMRS 指南，《迁移至 OpenMRS》——团队角色、分阶段采用、试点设计、持续维护、培训和变更管理的界线。