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計畫的核心「日醫標準診療報酬結算軟體」(簡稱日レセ),是一套收費電腦(レセプトコンピュータ)。收費電腦是根據診療內容計算診療報酬,並製作提交給審查支付機構的診療報酬明細書的業務系統。

電子病歷與收費電腦的角色分工十分清楚。

「電子病歷的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式社群開發」的軟體。原始碼可以閱讀、也可以分叉,但主流開發是由單一主體以類似廠商的方式推進──考量到醫療這個不容許出錯、且必須追隨制度變化的領域,我認為這是一個合理的折衷方案。

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年起的修改履歴,一路延續到電子處方箋(2022年)與My Number保險證資格確認(2024年)等近期的制度應對,由此可以看出同一套程式碼庫已持續追隨制度修訂超過20年。這種架構本身,也是被優化成「歷經千錘百鍊而持續運作」的結果。

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」遷移的過渡期。提供形態大致分為2種。

• WebORCA雲端版 ── 以ORCA管理機構提供的雲端服務形式使用日レセ的形態。醫療機構得以擺脫伺服器管理的負擔。申請需經由認定支援業者辦理,官方公告預估從申請到服務開始約需3週左右。醫療機構端不需要在院內放置伺服器,透過瀏覽器即可使用,伴隨診療報酬修訂而來的程式更新也會統一在雲端端進行。費用為每間醫療機構的月費制。
• WebORCA地端版 ── 安裝於院內伺服器(Ubuntu)使用的形態。目前的提供環境為Ubuntu 22.04(jammy)上的日レセ Ver5.2.0。

關於遷移的時間軸,有2點應該掌握。

其一是,遷移的路徑已由官方備妥。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 軟體開發、技術諮詢與故障調查為中心，在難以重現的故障調查與既有資產仍在運作的專案上具有優勢。