ORCA(日レセ)不是电子病历 ── 从工程师视角梳理诊疗报酬结算系统(レセコン)与医疗系统的构成

你是否听过”电子病历的ORCA”这种说法？只要参与过面向医疗机构的系统项目，这个名字就一定会出现，但这种叫法其实包含着一个误解。ORCA(日医标准诊疗报酬结算软件)不是电子病历。

本文面向初次接触医疗IT项目的工程师，目标是回答以下疑问。

• ORCA是什么，在医疗机构的系统构成中处于什么位置
• 诊疗报酬结算系统所承担的”诊疗报酬明细书业务”，从系统的角度看究竟在做什么
• 它是用什么技术构建的，公开的源代码中都有什么内容
• WebORCA迁移会带来哪些变化，对接一方应把握哪些要点

本文的所有描述均基于公开的一手信息。关于源代码的描述，是实际下载官方公开的日レセ本体 5.2系源代码(2026年7月1日公开快照，VERSION文件标注为5.2.0) 并加以确认后得到的结果。

目录

1. 先说结论 ── ORCA是”诊疗报酬结算系统”
2. 诊疗报酬明细书业务是什么 ── 从系统视角的最短理解
3. 医疗机构的系统构成图 ── ORCA处于什么位置
4. ORCA项目的历史与许可协议
5. 技术栈 ── 实际统计COBOL 400万行代码的内容
6. 源代码目录的浏览方法 ── 哪里有什么
7. 对接的入口 ── 日レセAPI・PushAPI・CLAIM
8. WebORCA迁移带来了哪些变化
9. 总结 ── 工程师应把握的要点
10. 参考资料

1. 先说结论 ── ORCA是”诊疗报酬结算系统”

作为ORCA项目核心的”日医标准诊疗报酬结算软件”(简称日レセ)，是一款诊疗报酬结算系统(レセコン，Receipt Computer)。诊疗报酬结算系统是根据诊疗内容计算诊疗报酬，并制作提交给审查支付机构的诊疗报酬明细书(レセプト)的业务系统。

电子病历与诊疗报酬结算系统的角色划分十分明确。

“电子病历的ORCA”这一通称之所以出现，是因为许多电子病历产品都采用了”诊疗报酬结算系统部分与ORCA对接”这样的架构。作为工程师，如果一开始就把ORCA=请款系统的基干，电子病历=诊疗记录系统这一区分记在心里，后面的内容就都容易理解了。

2. 诊疗报酬明细书业务是什么 ── 从系统视角的最短理解

要理解诊疗报酬结算系统究竟是一套怎样的系统，了解医疗机构的收入流程是最快的途径。在日本的医保诊疗中，患者在窗口支付的原则上只是1〜3成，剩余部分由医疗机构按月向审查支付机构(社会保险诊疗报酬支付基金・国民健康保险团体联合会)请款。这份请款单据就是诊疗报酬明细书。

从系统的角度看，诊疗报酬结算系统是一套运转下述月度批处理周期的装置。

1. 日常: 在前台确认保险资格，录入诊疗行为(诊察・检查・投药・处置……)，按点数表自动计算出的窗口自付金额进行结算。
2. 月度: 将一个月内的诊疗行为按”患者×保险”的单位汇总，制作诊疗报酬明细书。提交前进行数据检查(病名与处方的整合性等)，作为电子诊疗报酬明细书(レセ電数据)提交。
3. 次月以后: 应对审查退回的”返戻”以及被扣分的”查定”，修正后重新请款。

这里重要的是，点数计算的规则会随着每两年一次的诊疗报酬修订而变化。如果软件无法跟上点数主数据・药价・核算规则的修订，医疗机构就无法正确请款。诊疗报酬结算系统这类软件的本质难点，既不在于UI，也不在于规模，而在于几十年如一日地持续跟进这种制度变化。后文将提到的ORCA源代码中刻下的修改履历，正是这一过程的记录。

3. 医疗机构的系统构成图 ── ORCA处于什么位置

把诊所的典型构成画成图，可以看到ORCA(日レセ)处于接近院内系统枢纽的位置。

flowchart LR
    subgraph clinic["医疗机构内"]
        EMR["电子病历<br/>诊疗记录・医嘱"]
        RSV["前台・预约系统"]
        ONS["在线资格确认终端"]
        ORCA["ORCA/日レセ<br/>诊疗报酬结算系统 - 诊疗报酬请款"]
        EMR -->|"日レセAPI - HTTP"| ORCA
        RSV -->|"前台・预约对接"| ORCA
        ONS -->|"保险资格信息"| ORCA
    end
    ORCA -->|"诊疗报酬明细书 - 月度请款"| PAY["审查支付机构<br/>支付基金・国保联合会"]

要点有以下3个。

• 很多架构中患者基本信息与保险信息的主数据由ORCA一侧持有，电子病历通过API进行查询・更新。患者编号的编号权归属哪一方，是对接设计中首先要面对的论点。
• 诊疗行为(做了什么)由电子病历发送给ORCA，由ORCA进行点数计算并接入会计・请款流程。电子病历用”医嘱的语言”描述诊疗，ORCA则用”点数的语言”描述诊疗，因此两者之间的转换(诊疗行为代码的映射)是对接工作实务上的难点所在。
• 月度诊疗报酬明细书的提交是ORCA的工作。也就是说，医疗机构的营收要经由ORCA才能请款。对接失误不会表现为诊疗记录的缺失，而会表现为请款金额的错误——这种紧张感正是这一领域的特点。

4. ORCA项目的历史与许可协议

ORCA是日本医师会(日医)的项目。2001年11月发布的”日医IT化宣言”提出了将日本医师会开发的软件以开源形式公开的方针，而作为其核心开发出来的正是日レセ。2002年起在医疗现场开始使用，此后持续开发了20多年。

从工程师的视角来看，值得特别一提的是，这套业务系统的源代码已经持续公开20多年。

• 许可协议是随源代码一同附带的日医开源使用许可协议(JMA OpenSource License version 1.0)。这不是GPL，而是日医独自的协议，非独占且免费地许可对程序的使用(包括复制・改编・发布・公众传播)，并要求发布修改版时附加相同条件，具有类似Copyleft的结构。准据法为日本法。
• 过去曾公开CVS版本库，但随着商用版开始提供，CVS变为非公开，现在采用每月1日公开上月1日时点源代码tar包的方式。公开对象为本体・地区公费・公开单据这3个组件，5.0系・5.1系・5.2系并行公开。
• 开发・提供体制也颇具特色。阅读源代码的修改履历可以看到，早期排列的是NACL(开发受托方)工程师的名字，从2022年前后开始，逐渐变为以ORCAMO(日本医师会ORCA管理机构)名义提交。周边服务(支持、软件包、手册等)由ORCA管理机构以商用版形式提供，导入・维护则由全国的认定支持服务商承担——这是一种分工模式。

也就是说，ORCA是一款”开源，但不是GitHub式社区开发”的软件。源代码可以阅读，也可以fork，但主流开发始终由单一主体以类似厂商的方式推进——考虑到医疗这一不容许出错、且必须持续跟进制度变化的领域，我认为这是一个合理的落脚点。

5. 技术栈 ── 实际统计COBOL 400万行代码的内容

从这一章开始，专有名词会一下子增多，因此先在这里放一份术语表。后续章节也请把这张表放在手边对照阅读。

公开的5.2系源代码的INSTALL.ja中，列出了MONTSUQI(panda)、OpenCOBOL、PostgreSQL、MONPE等作为所需软件。将整体构成归纳如下。

光靠文字描述难以传达规模感，这里给出对5.2系快照(解压后约8,200个文件・237MB)实际统计的结果。

数据库的表名相当直白，读惯了之后，业务内容就能直接浮现出来。命名中”英语缩写”与”日语罗马字”混杂在一起，把日语部分还原为汉字后就能理解含义。主要的表列举如下。

也就是说，第1章中”患者・保险・病名・诊疗行为・点数”这一角色分工，原样体现在了表结构的实现之中。表定义书在官方网站上公开，如果对读法感到困惑，可以去那里确认正式名称。

架构的核心是MONTSUQI。日レセ内部是一种经典的集中处理型架构：Java客户端(monsiaj)从服务器接收画面定义并进行显示，输入内容由服务器一侧的COBOL程序处理，对PostgreSQL进行读写。哪个画面对应哪个COBOL程序，以声明的方式写在lddef/目录下的LD定义文件中。

flowchart LR
    CL["monsiaj<br/>Java客户端"] -->|"画面操作"| MW["MONTSUQI<br/>应用服务器"]
    API["对接系统<br/>电子病历等"] -->|"日レセAPI - HTTP"| MW
    MW -->|"按lddef/*.ld的定义分派"| AP["业务程序群<br/>COBOL 约1,750个"]
    AP --> DB[("PostgreSQL<br/>285张表")]

有意思的是，画面的调度与API的调度共存于同一份LD定义文件中。也就是说，日レセAPI并不是后来追加的独立服务器，而是在与对话画面相同的业务程序基盘之上，实现为追加了一个”用XML代替画面进行会话的入口”。这一设计的细节将在续篇中详述。

“COBOL+专用中间件+PostgreSQL”这样的构成，从现代Web开发的感觉来看显得相去甚远。然而，一份COBOL程序的头部以注释的形式刻着自2002年以来的修改履历，从中可以读出，同一套代码库已经持续跟进制度改定20多年，直至电子处方笺(2022年)、个人编号保险证的资格确认(2024年)这类近期的制度应对。这样的构成，也是长期以”经过千锤百炼、持续稳定运行”为目标优化的结果。

6. 源代码目录的浏览方法 ── 哪里有什么

作为实际阅读源代码时的地图，这里整理一下顶层的主要目录。

有一点实务上的注意事项。源代码的字符编码是EUC-JP(许可文档为ISO-2022-JP)。用现代编辑器直接打开会出现乱码，因此需要通过iconv -f EUC-JP -t UTF-8转换后再阅读。这可以说是一种时间胶囊，原样保存着2002年当时Linux环境的标准。

7. 对接的入口 ── 日レセAPI・PushAPI・CLAIM

外部系统的工程师接触ORCA时的入口，实质上有以下3个。

1. 日レセAPI ── 当前的推荐方案。对接系统通过HTTP发送请求，进行患者信息获取・挂号・诊疗行为登记等操作。读取类基本为GET或POST+XML，更新类基本为POST+XML。官方网站上公开了API规格。
2. PushAPI ── 将日レセ一侧发生的事件(单据打印指示等)通知给对接系统的机制。不是轮询而是事件驱动，可以构建画面联动。
3. CLAIM ── 长期以来作为医疗信息交换的标准规约被使用，但已于2026年3月终止支持。源代码中依然残留着CLAIM相关的处理，但既有的CLAIM对接已经以迁移到API为前提。

也就是说，今后如果要设计ORCA对接，日レセAPI是唯一选择。而且正如前面提到的，由于API是实现在与对话画面相同的COBOL业务程序基盘之上的，当”不清楚API的行为”时，可以一路深入到源代码去确认。从源代码把握API全貌(包括官方一览表中没有列出的端点)的具体步骤，将在续篇文章中讲解。

8. WebORCA迁移带来了哪些变化

当前的ORCA正处于向”WebORCA”迁移的过渡期。提供形态大致分为两种。

• WebORCA云版 ── 以ORCA管理机构提供的云服务形式使用日レセ的形态。医疗机构无需再进行服务器管理。申请需经由认定支持服务商，官方说明中预计从申请到服务开始大约需要3周左右。医疗机构一方院内不设置服务器，通过浏览器使用，伴随诊疗报酬改定而进行的程序更新也统一在云端完成。费用按每家医疗机构的月费制收取。
• WebORCA本地部署版 ── 安装在院内服务器(Ubuntu)上使用的形态。现行的提供环境是Ubuntu 22.04(jammy)上的日レセ Ver5.2.0。

关于迁移的时间轴，有两点需要把握。

其一是，官方已经准备好了迁移路径。ORCA Project公开了《日レセ运用环境迁移手引》，其中明确规定了迁移对象：从运行在Ubuntu 16.04 / 18.04 / 20.04之上的传统型(MONTSUQI版)日レセ 5.1.0 / 5.2.0，迁移到WebORCA本地部署版(Ubuntu 22.04 + 5.2.0)的步骤。反方向，也就是迁移到更低版本的OS或更低版本的日レセ，是无法实现的。

另一点是，“所有医疗机构应在何时之前迁移到WebORCA”这样一个统一的期限，并没有被公布。在实务上真正起作用的期限，是按OS与日レセ软件包的组合分别设定的支持终止日，这以《日レセ软件包及OS支持时间表》的形式公布，临近终止的版本会被单独公告。对于开发对接系统的一方而言，与其关注”迁移到WebORCA是什么时候”，不如确认对方医疗机构所使用的Ubuntu与日レセ版本，以及其支持终止日，这才是把握时间轴的实务方法。

重要的是，两者内部其实是同一个日レセ。运行的软件并不会因为提供形态不同而变成别的东西，API的种类与行为基本通用。对接工程师应把握的差异，并不在于实现，而集中在连接方面。

• API的请求路径中，云版会加上/api前缀，连接信息・认证设置也因提供形态而异——这些属于入口层面的差异。API本身的规格是通用的。
• 在云版中，院内的对接系统需要通过互联网调用API，因此网络路径以及故障时的降级行为设计，比本地部署构成需要考虑的事项更多。
• 每月公开的源代码中，原样包含了面向WebORCA的定义(例如record/目录下的.db.weborca文件)。这证明同一套源代码树支撑着两种形态，从源代码中获得的知识对云版同样适用。此外，.weborca版中存在响应数组上限等经过调整的定义，确认细节时也要留意是否存在面向WebORCA的定义。

9. 总结 ── 工程师应把握的要点

• ORCA(日レセ)不是电子病历，而是诊疗报酬结算系统。它握有患者・保险・病名・诊疗行为・点数等请款系数据的核心，医疗机构的营收要经由这里才能请款。
• 诊疗报酬结算系统的本质难点在于几十年如一日地跟进每两年一次的诊疗报酬改定。ORCA源代码中的修改履历，正是这一过程的实录。
• 这是一套自2001年日医IT化宣言以来持续至今的开源业务系统，源代码每月以tar包形式公开。许可协议不是GPL，而是日医开源使用许可协议。
• 内部构成是COBOL 1,754个・约406万行+MONTSUQI+PostgreSQL 285张表(5.2系实测)。画面与API均由同一份LD定义调度，是一种集中处理型架构。
• 外部对接目前以日レセAPI为入口。CLAIM已于2026年3月终止支持。WebORCA迁移正在进行中，但云版与本地部署版内部都是同一个日レセ，从公开源代码中获得的知识对两者都同样适用。

下一篇，将实际阅读这份公开源代码，讲解从源代码把握日レセAPI全貌(哪个URL由哪个COBOL程序处理、官方一览表中没有列出的端点是什么)的方法，并附上全137个端点的对照表。

10. 参考资料

• ORCA是什么 - ORCA Project
• 技术信息 - 日医标准诊疗报酬结算软件 - ORCA Project(源代码公开・API规格・表定义书)
• 日医标准诊疗报酬结算软件API - ORCA Project
• 日医标准诊疗报酬结算软件「ORCA」 - 日本医师会ORCA管理机构
• 关于日医标准诊疗报酬结算软件商用版 - 日本医师会ORCA管理机构
• WebORCA云版 - ORCA Project
• 日医标准诊疗报酬结算软件［WebORCA云版］- 日本医师会ORCA管理机构(申请渠道・提供形态・费用)
• 日レセ运用环境迁移手引 - ORCA Project(WebORCA本地部署版的迁移对象与步骤)
• 日医标准诊疗报酬结算软件 致使用中的用户 - ORCA Project(《日レセ软件包及OS支持时间表》的刊载出处)
• 日レセ本体5.2系源代码(2026年7月公开快照) INSTALL.ja / doc/license.html / lddef/orcadb.inc等 ── 正文中的实测数值均基于这一快照

相关文章

共享相同标签的最新文章。可以围绕相近的主题进一步加深理解。

相关主题

与本文相近的主题页面。以本文为起点，可以进一步了解相关服务和其他文章。

与本主题相关的服务

本文与以下服务页面相关联，欢迎从最接近的入口查看。

常见问题

汇总了咨询这一主题时常见的问题。

ORCA是电子病历吗？

不是。作为ORCA项目核心的日医标准诊疗报酬结算软件(日レセ)，是负责诊疗报酬请款(诊疗报酬明细书)的诊疗报酬结算系统。书写诊疗记录的电子病历是另一款软件，许多医疗机构会通过API让电子病历与ORCA对接使用。准确地说，"电子病历的ORCA"这种说法，是因为电子病历经常与之对接使用而产生的通称。

ORCA(日レセ)的源代码任何人都能阅读吗？

能够阅读。日医标准诊疗报酬结算软件本体的源代码，在日医开源使用许可协议(JMA OpenSource License)之下公开，每月1日都可以下载上月1日时点快照的tar包。曾经的CVS版本库随着商用版开始提供而变为非公开，但源代码公开本身仍在持续。

ORCA是用什么技术构建的？

服务器运行在Linux之上，业务逻辑的大部分用COBOL编写。数据库为PostgreSQL，业务程序的执行基盘使用名为MONTSUQI(panda)的开源中间件，客户端则使用Java制作的monsiaj等。统计5.2系的源代码，仅COBOL就有约1,750个文件・超过400万行，数据库则有超过280张表，是这样的规模。

电子病历与ORCA之间如何对接？

目前推荐使用日レセAPI。电子病历等对接系统通过HTTP发送请求，进行患者信息获取、诊疗行为登记等操作。也有由日レセ一侧通知事件的PushAPI。以前一直使用的基于CLAIM(医疗信息交换规约)的对接已于2026年3月终止支持，因此今后新建的对接应以API为前提进行设计。

作者简介

本文作者的个人简介页面。

Go Komura

小村软件有限公司 代表

以 Windows 软件开发、技术咨询与故障排查为中心，擅长难以复现的故障调查，以及既有资产仍在运行的项目。