從原始碼掌握日レセ 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個。新增部分集中在線上資格確認(My Number保險證)相關領域，由此可以實測出「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".     *> 患者個人番号
COPY "CPONSHI-KAKU.INC".     *> オンライン資格確認結果
COPY "CPPATIENTXMLV2RES.INC" *> レスポンス編集用

一支只用來回傳單一患者資訊的 API，竟引入了從介護保險、My Number 到線上資格確認在內近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筆，取出冒號之後的部分(功能名稱)

執行之後，會以 Tab 分隔，排列出「模組 / 端點 / 程式 / 功能名稱」這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個。可以清楚看到，制度因應(圍繞 My Number 保險證的相關制度)以 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 軟體開發、技術諮詢與故障調查為中心，在難以重現的故障調查與既有資產仍在運作的專案上具有優勢。