从源代码把握日レセ API 的全貌 ── 通读 ORCA 公开源码（附全 137 个端点对照表）

在上一篇文章中，我们梳理了 ORCA（日医标准诊疗报酬结算软件）是一款诊疗报酬结算系统（レセコン），以及其源代码已经持续公开 20 多年这两点。

这次要实际阅读那份源代码。主题是从一手信息出发把握日レセ API 的全貌。不是从头开始逐条阅读官方 API 规格书，而是按照下面这个顺序进行：

1. 从源代码中数出服务器端实际存在的全部端点，
2. 把一个 API 从实现一直追踪到响应 XML 的形态，
3. 与官方文档对照、验证差异，
4. 用版本间 diff 实测 API 的变化。

文章末尾附有这次调查得到的全 137 个端点的对照表（URL・COBOL 程序・功能）。

本文的调查对象是官方公开的日レセ本体 5.2 系列源代码（2026 年 7 月 1 日公开快照），同时也使用5.1 系列（同日公开）作为对比对象。所有描述均基于这两个版本，正文中会给出复现所需的命令。

目标读者是接下来要设计・实现与日レセ API 对接功能的开发者。不需要会读 COBOL。把握全貌只需要用到文本的 grep 和 iconv，即便到了深入追查单个 API 的阶段，主要阅读的也是头部注释与修改履历。同样不预设医疗事务方面的实务知识。

目录

1. 先说结论
2. 前提 ── 源代码的获取与版本固定
3. API 调度机制 ── URL 由lddef决定
4. 发现：API 是”画面业务的 API 版” ── bind与bindapi
5. 完整追踪一个 API ── 解剖patientgetv2
6. 统计全部端点 ── 一条 grep 命令搞定的调查步骤
7. 与官方一览表对照 ── 一览表中没有的 API 示例
8. 从源代码推导未文档化 API 的规格 ── 以findv3为例
9. 用版本间 diff 实测 API 的变化 ── 5.1 系列 vs 5.2 系列
10. 如何与未文档化 API 相处 ── “文档化”并非保证
11. 深入追查时的实务笔记
12. 总结
13. 附录：全137个端点对照表（5.2系列・2026年7月版）
14. 参考资料

1. 先说结论

• 日レセ API 的 URL 与服务器端程序的对应关系，以声明的方式写在源代码的lddef/*.ld（LD 定义文件）中。即使不读 COBOL，仅凭文本的 grep 就能列举出 API 的全貌。
• 在 5.2 系列快照中，27 个 LD 定义合计束有 137 个端点，均由bindapi统一管理。官网 API 规格一览页面上刊载的只有约 50 个，源代码一侧实际存在的端点数量是它的 2 倍以上。
• XML 请求・响应的结构声明在record/*.db中，XML 标签名直接沿用定义中的项目名。也就是说，即使是未文档化的 API，只要沿着lddef→cobol→record追溯，也能推导出规格。
• 与 5.1 系列进行版本间 diff 后可以看到，端点新增 9 个・删除 0 个。新增部分集中在在线资格确认（医保卡，日文称マイナ保険証）相关领域，由此可以实测出”API 会随制度对应而增加，而现有的 API（至少在这两个系列之间）并未消失”这一事实。
• 未文档化的 API 并不是”不能用的 API”。ORCA 是开源软件，可以把源代码本身当作一手规格来对待。问题的关键不在于有没有承诺，而在于”能否建立起自行检测变更的运维体系”，这一判断框架将在第 10 章中整理。

2. 前提 ── 源代码的获取与版本固定

源代码可以从官方技术信息页面以 tar 包（zip）的形式下载。由于每月 1 日都会更新为上月 1 日时点的快照，调查结果必须与版本一起记录是铁律。本文使用的是以下版本。

• 获取地址：https://ftp.orca.med.or.jp/pub/src/jma-receipt.r_5_2_branch.zip（用于对比的r_5_1_branch.zip也一并使用）
• 获取日期：2026-07-17（两者均为 2026 年 7 月 1 日时点的快照）
• 5.2 系列的VERSION文件：5.2.0

若要亲自动手操作，最简步骤如下。之后各章的命令，都以解压后的目录为起点执行。

# 确定工作目录，获取并解压5.2系列的快照
mkdir -p ~/orca-src && cd ~/orca-src
curl -O https://ftp.orca.med.or.jp/pub/src/jma-receipt.r_5_2_branch.zip
unzip -q jma-receipt.r_5_2_branch.zip

# 记录版本。以下这两项务必留在调查笔记中
sha256sum jma-receipt.r_5_2_branch.zip
cat jma-receipt.r_5_2_branch/VERSION      # → 5.2.0

# 之后的命令都在这个目录内执行
cd jma-receipt.r_5_2_branch
ls lddef/ | head

用于对比的 5.1 系列，只需把 URL 中的r_5_2_branch替换为r_5_1_branch，按同样的步骤解压备用，第 9 章的 diff 就可以直接执行。

解压后大约有 8,200 个文件、237MB，本文主要使用以下 3 个目录。

3. API 调度机制 ── URL 由lddef决定

在进入正题之前，先把本章开始要用到的术语整理一下。虽然全都是 ORCA 特有的说法，但要记住的只有 5 个。

日レセ API 的 URL 采用”模块名/端点名”这样的两段式结构，例如/api01rv2/patientgetv2。这一对应关系原样体现在lddef/目录下的 LD 定义文件中。

来看一下lddef/api01rv2.ld的开头部分。

name	api01rv2;

bindapi	"patientgetv2"	"OpenCOBOL"	"ORAPI012R1V2";
bindapi	"acceptlstv2"	"OpenCOBOL"	"ORAPI011R1V2";
bindapi	"appointlstv2"	"OpenCOBOL"	"ORAPI014R1V2";
...

读法很直接：LD 名对应 URL 的第 1 段，bindapi的第 1 个参数对应第 2 段，第 3 个参数则是负责处理的 COBOL 程序名。也就是说，发往/api01rv2/patientgetv2的请求，会被转交给名为ORAPI012R1V2的 COBOL 程序。

flowchart LR
    C["对接系统<br/>电子病历等"] -->|"GET /api01rv2/patientgetv2?id=患者编号"| M["日レセ服务器<br/>MONTSUQI"]
    M -->|"lddef/api01rv2.ld<br/>查阅bindapi定义"| P["ORAPI012R1V2.CBL<br/>患者基本信息获取"]
    P --> D[("PostgreSQL")]
    P -->|"XML响应"| C

除此之外，LD 定义中还声明了用于组装响应的一组 XML 记录（db "xml2" { ... }），以及一些值得留意的配置（如数组大小等）。LD 文件可以当作”该模块所涉及的画面・API・数据结构的目录”来阅读。

4. 发现：API 是”画面业务的 API 版” ── bind与bindapi

浏览 LD 定义时，会立刻注意到一件事：同一个文件中，bind（画面）与bindapi（API）是共存的。来看一下患者查询模块lddef/orca13.ld。

name	orca13;

bind	"Q01"		"OpenCOBOL"	"ORCGQ01";     ← 患者查询的对话画面
bind	"Q02"		"OpenCOBOL"	"ORCGQ02";
...
bindapi "findv3"    "OpenCOBOL"	"ORCGQAPI01";  ← 该功能的API版
bindapi "findinfv3" "OpenCOBOL"	"ORCGQAPI02";
bindapi "foundv3"   "OpenCOBOL"	"ORCGQAPI03";

Q01等是医疗事务人员操作的患者查询画面对应的程序，findv3等则是属于同一模块的 API。程序名也是如此对应的：画面为ORCGQ01，API 则在画面系名称中插入”API”字样成为ORCGQAPI01。

也就是说，日レセ API 并不是作为独立的 API 服务器设计出来的，而是在与对话画面相同的业务程序基础之上，按业务模块逐一追加了”用 XML 代替画面进行会话的入口”。理解了这个结构，下面两点就能自然地说通了。

• 为什么 URL 的第 1 段（orca13、orca42……）源自画面的业务编号，作为 API 来看，乍一看像是毫无意义的数字
• 为什么“画面上能做的业务，也许存在 API 版”这种探寻思路能够成立——寻找未文档化 API，实际上更接近于把这些”画面业务的 API 版”逐一列举出来

5. 完整追踪一个 API ── 解剖patientgetv2

在统计整体全貌之前，先把一个 API 从实现一直追到响应的形态。选用的题材是最基本的患者基本信息获取 /api01rv2/patientgetv2。

（1）调度：lddef/api01rv2.ld中的bindapi "patientgetv2" → ORAPI012R1V2。实体是cobol/api01rv2/ORAPI012R1V2.CBL（2,163 行）。COBOL 源码原则上放在与 LD 名相同的目录下，因此只要能读懂lddef，几乎可以机械式地定位到实现文件（也有例外，比如orca51的 API 群的实体位于cobol/orca52/。最可靠的方法是用程序名来find）。

（2）程序头部：开头写着”组件名称：患者基本信息获取（支持 version2）”，紧随其后的修改履历，从 2013 年的地区协作 ID 对应，到 2022 年的电子处方笺对应，再到 2024 年的”基于医保卡的资格有效性返回对应”，这一个 API 所经历过的制度改定，就这样排成了一份年表。比 API 规格书里的”更新履历”更加详细。

（3）在读取哪些数据：查看WORKING-STORAGE SECTION中的 COPY 语句（引入的公共定义），就能看出这个 API 触及了哪些数据。摘录如下：

COPY "CPPTINF.INC".          *> 患者基本信息(tbl_ptinf)
COPY "CPPTNUM.INC".          *> 患者编号
COPY "CPJYURRK.INC".         *> 就诊履历
COPY "CPPTCARE-HKNINF.INC".  *> 护理保险信息
COPY "CPPTMYNUMBER.INC".     *> 患者个人编号(My Number)
COPY "CPONSHI-KAKU.INC".     *> 在线资格确认结果
COPY "CPPATIENTXMLV2RES.INC" *> 响应编辑用

一个只用来返回单个患者信息的 API，竟引入了从护理保险、个人编号到在线资格确认在内近 30 个定义。这正是”患者基本信息”的含义随着制度不断膨胀的实物证据。

（4）响应的形态：响应 XML 的结构声明在record/xml_patientinfov2res.db中。

xml_patientinfov2res {
    patientinfores {
        Api_Result          varchar(2);
        Patient_Information {
            Patient_ID          varchar(20);
            WholeName            varchar(100);
            WholeName_inKana    varchar(100);
            BirthDate           varchar(10);
            Sex                 varchar(1);
            Home_Address_Information {
                Address_ZipCode varchar(07);
                ...

用过日レセ API 的人应该会觉得眼熟。API 响应中的 XML 标签名（Patient_ID、WholeName……），直接沿用了这份record定义中的项目名。 也就是说，官方 XML 规格书中所写的项目表的”原本”就在这里。由于连项目的大小（位数）都写明了，也可以作为对接方设计校验规则的一手信息来使用。

这（1）→（4）就是解剖一个日レセ API 的标准流程模板。用lddef确定程序，用头部注释掌握功能与历史，用 COPY 语句把握所涉及的数据，用record确定报文结构——即使不深入阅读 COBOL 本体的逻辑，到这一步为止，实务所需的信息已经基本齐备。

6. 统计全部端点 ── 一条 grep 命令搞定的调查步骤

弄清楚原理之后，统计全貌就只是机械作业了。

# 列举出全部"端点 → COBOL程序"对应关系
grep -H '^[[:space:]]*bindapi' lddef/*.ld

# 按模块统计件数
for f in lddef/*.ld; do
  n=$(grep -c '^[[:space:]]*bindapi' "$f"); [ "$n" -gt 0 ] && echo "$f: $n"
done

# 从COBOL头部机械提取每个端点的功能名
# (源码是EUC-JP编码，因此要经过iconv转换。程序的存放位置
#  存在与LD名不一致的例外，因此用find来确定)
for ld in lddef/*.ld; do
  mod=$(basename "$ld" .ld)
  grep '^[[:space:]]*bindapi' "$ld" | sed 's/"//g; s/;//' \
  | while read -r _ ep _ prog; do
      cbl=$(find cobol -name "$prog.CBL" | head -1)
      comp=$(iconv -f EUC-JP -t UTF-8 "$cbl" 2>/dev/null \
             | grep -m1 'コンポーネント名' \
             | sed 's/.*コンポーネント名[[:space:]]*[:：][[:space:]]*//')
      printf '%s\t%s\t%s\t%s\n' "$mod" "$ep" "$prog" "$comp"
    done
done

第 3 段脚本比较长，这里把管道每一步在做什么拆解一下。

1. grep '^[[:space:]]*bindapi' "$ld" ── 从 LD 定义中只取出 API 声明的行
2. sed 's/"//g; s/;//' ── 去掉双引号和行末分号，变成以空格分隔的 4 个词（bindapi / 端点名 / OpenCOBOL / 程序名）
3. while read -r _ ep _ prog ── 丢弃第 1 个和第 3 个词，只接收端点名和程序名
4. find cobol -name "$prog.CBL" ── 查找程序的实体文件。由于存在 LD 名与目录名不一致的例外，所以不能把路径写死
5. iconv -f EUC-JP -t UTF-8 ── 由于 COBOL 源码是 EUC-JP 编码，为了能读到日语的头部注释而进行转换
6. grep -m1 'コンポーネント名' | sed … ── 只取头部中”コンポーネント名（组件名称）”这一行的第 1 条，提取出冒号之后的部分（功能名）

执行之后，会以制表符分隔，排列出”模块 / 端点 / 程序 / 功能名”这 4 列。前 6 行如下所示。

api01rv2	patientgetv2	ORAPI012R1V2	患者基本情報取得
api01rv2	acceptlstv2	ORAPI011R1V2	受付一覧
api01rv2	appointlstv2	ORAPI014R1V2	予約一覧  (xml2）
api01rv2	patientlst1v2	ORAPI012R2V2	患者番号一覧取得処理
api01rv2	patientlst2v2	ORAPI012R3V2	患者情報一覧取得
api01rv2	patientlst3v2	ORAPI012R4V2	患者情報一覧取得（氏名指定）

整体一共有 137 行。第 3 行”予約一覧 (xml2）”中出现的重复空格，以及全角和半角括号混用的情况，都是因为直接照搬了头部记载的原始内容。把这份输出整理之后，就是附录中的对照表，那里同样原样保留了（日语）原始写法（第 13 章）。

本版本的统计结果如下（全部 137 条的详细清单见附录）。

读取类（api01rv2）约占 4 成，与此相对，更新类则按业务模块（患者=orca12、挂号=orca11、诊疗行为=api21……）各自分开。第 4 章所说的”画面业务的 API 版”这一结构，也原样体现在这个分布上。

另外还值得关注的一点是，其中混杂着一些与其说是业务 API，不如说更接近基础功能 API的存在，比如session模块的session_start（登录认证）、orca00的print（打印）。无论把官方规格书的一览表看多少遍，都不会注意到这一层的存在。

各端点的详细信息参见附录的全 137 条对照表。先从上表的件数把目标模块的范围锁定，再按模块名在附录中查找，是最基本的查找方法。

7. 与官方一览表对照 ── 一览表中没有的 API 示例

接下来，把官网”日医标准诊疗报酬结算软件 API 规格”一览页面上刊载的 API（约 50 个），与从源码中提取出的 137 个进行对照。结果发现，一览页面上没有列出的端点，在源码一侧大量实际存在。下面按功能领域各举一例（功能均已通过 COBOL 头部的”组件名称”确认）。

也就是说，不仅是挂号、患者信息这类日常对接，就连按月进行的结算单业务（制作→核查→输出结算单电子数据→请款管理），也存在可供外部驱动的 API 群实现。这是只了解电子病历对接就无法看到的一层。

这里有两点需要特别注意。

1. 不要草率地断定”一览表中没有=未文档化”。 例如报表数据获取（formdatagetv2）这样的 API，就已经在 PushAPI 一侧的文档中被记载，一览页面并不保证覆盖全部 API。应当在确认了各自的文档页面乃至站内搜索之后，才能说”找不到相关文档”（上表就是经过这样确认后的结果，但即便如此，也无法完全证明”不存在已公开的文档”）。
2. 第三方实现同样可以作为对照材料。 像用 Ruby 调用日レセ API 的orca-api 库这样的开源软件，作为一份在实务中被使用过的端点目录，也很有参考价值。

8. 从源代码推导未文档化 API 的规格 ── 以findv3为例

即使弄清楚了”存在一览表中没有的 API”，如果不知道请求的格式，调查也无从下手。这时第 5 章的模板就派上用场了。下面就以findv3（患者查询）来试一下。

请求结构位于record/xml_findv3req.db中（节选）。

xml_findv3req {
  findv3req {
    Request_Number               varchar(2);
    Patient_Information {
      BirthDate    { First varchar(10); Last varchar(10); };
      Sex                        varchar(1);
      LastVisit_Date { First varchar(10); Last varchar(10); };
      Doctor_Code                varchar(05);
      Department_Code            varchar(2);
      Death_Class                varchar(1);
      Patient_ID   { First varchar(20); Last varchar(20); };
      TestPatient_Class          varchar(1);
      WholeName                  varchar(100)[5];
      ...

仅通过阅读这份定义就能看出，这是一个可以组合出生日期范围・性别・最终来院日范围・主治医・诊疗科・死亡区分・患者编号范围・姓名（可指定多个）等条件的、功能相当强大的患者检索 API。官方一览表中列出的患者检索类 API（patientlst1v2等）大多以患者编号范围或姓名等单一功能的检索为主，相比之下，这个能实现与画面端患者查询同等复合条件检索的 API，在功能层面明显是它们的上位替代。

响应结构同样位于record/xml_findv3res.db中，只要阅读对应的 COBOL（ORCGQAPI01.CBL），还能确认更细致的行为（如件数上限、排序方式等）。在源代码公开的 ORCA 中，”未文档化 API”其实就是”可以自己写出文档的 API”。

如此推导出来的规格，在生产环境中究竟可以信赖到什么程度──这是下一章的主题。

9. 用版本间 diff 实测 API 的变化 ── 5.1 系列 vs 5.2 系列

在讨论未文档化 API 的风险之前，先来实测一下”API 到底会变化到什么程度”。将同一天发布的 5.1 系列快照与bindapi定义进行 diff，结果如下：

新增的 9 个明细为：在线资格确认相关 6 个（onlinequa10・onlinequa11・onlinequaapp1〜3・onlineaidlstreq1），患者备注登记（patientmemomodv2），录入代码批量返回（inputcodelstv3），录入・诊疗代码信息获取（medicationgetv2），合计 9 个。可以清楚地看到，制度对应（围绕医保卡的相关制度）以 API 增设的形式体现了出来。

从这一观察中可以得出以下两点：

• 端点的”面”是稳定的（这两个系列之间删除数为零）。应当担心的不是端点消失，而是单个 API 的项目增加・行为变化（如第 5 章中所见的修改履历那样的变化）。
• 由于源代码每月都会公开，这类变更检测是可以自动化的。如果正在维护对接系统，只需对月度快照中的lddef与record进行 diff，就能构成一张预警网，提前掌握下个月版本升级会带来哪些变化。这是源代码公开才特有的、其他结算系统难以获得的维护手段。

10. 如何与未文档化 API 相处 ── “文档化”并非保证

首先要把前提厘清。日医开源使用许可协议在第 2 章第 5 条中，针对”能否无障碍运行”以及”是否存在瑕疵”等，将整个程序声明为不提供任何保证。这一点同样适用于已文档化的 API。关于兼容性，官方文档中也并没有明文规定承诺”不改变”已文档化的 API，实际上正如第 5 章所见，即便是已文档化 API 的代表patientgetv2，也在每次制度对应时不断被追加项目。

也就是说，”文档化/未文档化”之间的差异，并不在于是否有保证。归根结底，实质性的差异只有以下两点：

1. 变更是否容易以官方文档更新的形式体现出来（未文档化 API 的变更，除非阅读源代码，否则无从得知）
2. 是否容易被纳入与支持服务商沟通的议题

而 ORCA 的源代码是每月都会公开的。第 1 点的差异，可以通过对源代码进行 diff 监控来弥补。源代码才是一手规格，文档不过是它的摘译──这才是面对开源软件应有的正确态度。当文档与源代码出现分歧时，实际运行的是源代码那一方。

在此基础上，既然经手的是与金钱直接挂钩的结算单请款系统，那么无论是否已文档化，纳入生产流程的 API 都应当配套实施以下运维措施。

有一点运维上的注意事项。公开快照的内容是上月 1 日时点的状态，因此如果先把软件包更新应用到生产环境，那么能够读到对应源代码的时间点，就会落在应用之后。要让这项监控真正发挥预警作用，就必须把顺序颠倒过来──等到对应的源代码公开并完成验证之后，再进行版本升级。

反过来说，无法建立起这套运维体系的组织，即便只使用已文档化的 API，也谈不上安全。把不提供任何保证的开源软件用作业务核心系统，意味着的就是这么一回事。

11. 深入追查时的实务笔记

在用源代码深入追查单个 API 这一阶段，容易碰壁的一些细节点。

• 字符编码是 EUC-JP。 COBOL 源码及注释均为 EUC-JP 编码，因此要先通过iconv -f EUC-JP -t UTF-8转换之后再阅读。许可文档（doc/license.html）则是 ISO-2022-JP 编码。grep 如果不经过iconv转换，也无法用日语关键字命中。
• 记住程序名的命名规则会更快。 API 系的基本形式是ORAPI+业务编号+R（读取）/S（更新）+版本（V2/V3），画面系的 API 版则是ORCG〜API〜。COBOL 源码原则上位于cobol/<LD名>/目录下，但存在例外（orca51的 API 实体在cobol/orca52/），遇到不确定的情况就用程序名来find。
• 入口分为 GET 系与 POST+XML 系两种。 LD 定义的db "xml2"代码块中，没有请求用记录（〜req）的 API（例如patientgetv2）大致可判断为 GET 参数型，有的则是 POST+XML 型。最终确认要看 COBOL 一侧的输入处理。
• 数据项目的含义要通过record/与官方数据表定义书对照确认。 响应项目的”原本”在record/*.db中，数据库一侧的含义则在官方公开的数据表定义书中。两者并排对照，确度会更高。另外要注意，部分定义还并存有面向 WebORCA 的.db.weborca版本，其数组上限等会有所不同（例如xml_acceptlstv2res从 1,000 条变为 1,500 条）。在设计 WebORCA 对接时，需要确认该版本。
• 动作确认应在验证环境中进行。 利用官方的试用服务器，或社区提供的 Docker 环境，无需触碰实体结算系统机器，就能调用 API 进行确认。切忌在生产机上进行”试打”。

12. 总结

• 日レセ API 的全貌汇集在lddef/*.ld的bindapi定义中，仅用 grep 就能列举出 137 个端点（5.2 系列・2026 年 7 月版）。
• 日レセ API 的真面目是“画面业务的 API 版”。bind（画面）与bindapi（API）共存于同一份 LD 定义中，URL 的模块名源自画面的业务编号。
• 一个 API 可以按lddef（调度）→COBOL 头部（功能・历史）→COPY 语句（涉及的数据）→record/*.db（XML 结构的原本）这样的顺序解剖。XML 标签名就是record定义中的项目名本身。
• 官方一览表（约 50 个）与源代码（137 个）之间的差异中，包含了结算单制作・结算单电子数据制作・数据检查这类能够驱动月度业务的 API 群。不过不能草率地断定”一览表中没有=未文档化”，需要逐一验证。
• 与 5.1 系列的 diff 实测显示：新增 9 个（以在线资格确认相关为主）・删除 0 个。月度快照的 diff，可以作为对接维护的预警网来使用。
• 使用许可协议明确表示，包括已文档化 API 在内均不提供保证，”已文档化≠安全”。源代码才是一手规格。无论文档化与否，只要在生产环境中使用，就应当把版本固定・月度 diff 监控・回归确认・自有文档的完善配套实施。

不从规格书入手、而是从源代码入手，这次所用的顺序，并不局限于 ORCA，而是适用于所有”文档跟不上实现”的长寿命业务系统的通用调查方法。所幸 ORCA 的源代码是公开的，这使得这种方法既合法，又能每月保持最新状态地加以实践。

13. 附录：全137个端点对照表（5.2系列・2026年7月版）

这是从lddef/*.ld的bindapi定义中机械提取出的全部端点。功能名均直接转录自各 COBOL 程序头部的”组件名称”栏（用词不一致、全角括号、疑似笔误的拼写，均照原文保留。诸如「請求額シュミレーション」「medicatonmodv2」之类，并非本公司转录时的失误）。本表是对 2026 年 7 月 1 日时点 5.2 系列快照这一事实的记录，并不表示各端点的可用性或支持状况。

表格按模块（URL 第 1 段）顺序排列。要查找目标 API 时，按下面的顺序缩小范围会更快。在浏览器中用页内搜索（Ctrl+F）输入模块名，即可跳转到该模块所在段落的开头。

14. 参考资料

• 技术信息 - 日医标准诊疗报酬结算软件 - ORCA Project（源代码公开）
• 日医标准诊疗报酬结算软件API规格 - ORCA Project
• 日医标准诊疗报酬结算软件API - ORCA Project
• orca-api：日医标准诊疗报酬结算软件API的Ruby库(GitHub)
• 日レセ本体 5.2 系列・5.1 系列源代码（均为 2026 年 7 月公开快照） lddef/api01rv2.ld / lddef/orca13.ld / cobol/api01rv2/ORAPI012R1V2.CBL / record/xml_patientinfov2res.db / record/xml_findv3req.db 等 ── 正文中的实测数值・引用均基于此快照

相关文章

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

相关主题

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

与本主题相关的服务

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

常见问题

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

日レセ API 的端点一共有多少个？

官网的 API 规格一览页面上刊载了约 50 个，但如果统计公开源代码（5.2 系列・2026 年 7 月快照）中 LD 定义文件的内容，会发现由 bindapi 汇总起来的端点共有 137 个。差异之中也包含了像单据类那样在其他页面另行文档化的端点，因此不能简单地断定"未列入一览＝未文档化"，但通过统计源代码一侧，可以把 API 的全貌作为一手信息来把握。本文附有全 137 个端点的对照表。

可以在生产环境中使用官方文档里没有记载的 API 吗？

可以使用。因为 ORCA 的源代码是公开的，可以把实现本身当作一手规格来确认。使用许可协议本来就针对包括已文档化 API 在内的整个程序明确表示不提供保证，因此"只要文档化了就是安全的"这一前提本身才是错误的。与是否文档化相比，实质性的差异只有两点：一是"变更是否容易体现在官方文档中"，二是"是否容易在与支持服务商的沟通中被纳入议题"。前者可以通过对月度公开源代码进行 diff 监控来弥补，但后者（未文档化 API 很难成为支持对象这一点）依然存在。若要在生产环境中使用，请把版本固定、diff 监控、在验证环境中进行回归确认、完善自有文档、与支持服务商共享使用配置这几项配套实施。即便是使用已文档化的 API，原本也应该做到这些。

API 的请求・响应格式也能从源代码中得知吗？

可以得知。日レセ 的 XML 请求・响应结构，以声明式的方式写在 record/ 目录下的定义文件中（例如：record/xml_patientinfov2res.db），XML 标签名直接沿用了该定义中的项目名。即使是未文档化的 API，只要从 LD 定义中确定负责的程序，再阅读对应的 record 定义，就能推导出请求・响应的全部项目。

即使不会读 COBOL 也能进行调查吗？

可以调查。如果只是想把握端点的整体全貌，几乎不需要读懂 COBOL。LD 定义文件（lddef/*.ld）和数据结构定义（record/*.db）都是纯文本，URL、程序与 XML 结构之间的对应关系都以声明式方式写明。只有到深入追踪单个 API 内部行为的阶段，才真正需要阅读 COBOL，而仅凭程序头部的注释（日语）与修改履历，就已经能获得大量信息。

作者简介

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

Go Komura

小村软件有限公司 代表

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