審定與退件究竟發生在哪裡 ── 從ORCA原始碼與公開資料拆解診療報酬明細書點檢的邏輯

醫療機構的窗口收入只是一小部分，收入的大半是由每月一次的診療報酬明細書申報所決定。正因如此，現場才會覺得「被審定了」「退件回來了」這些話有著沉重的分量，但對於參與系統開發的工程師來說，審定・退件究竟在哪裡、以什麼樣的邏輯發生，卻是意外地看不清楚的主題。

系列第1篇談了收費電腦的角色，第2篇談了日レセ API，第3篇談了線上資格確認。這次要拆解診療報酬明細書業務的核心──點檢・審查的邏輯，以把診療報酬明細書所通過的「關卡」依序排列的方式進行。

• 退件・審定・再審查這些用語的正確意義
• 醫療機構內部的檢查 ── ORCA的資料檢核業務與檢核主檔的實作
• 提交前的レセ電資料檢核
• 審查支付機構端的檢查 ── 電腦檢核・比對點檢・縱覽點檢
• 收費電腦端與審查端，在結構上同樣都是「規則表+引擎」

有關制度面的敘述，依據支付基金・醫師會等公開資料；有關ORCA實作的敘述，則依據實際閱讀官方公開的日レセ本體 5.2系列原始碼(2026年7月1日公開快照) 後確認的結果。

用語的最小集合 ── 只要知道這些就能讀懂

醫療業界的縮寫詞會接連出現，因此先把最小限度的用語固定下來。從這裡開始，請依照這個意義往下讀。

把彼此的關係濃縮成一張圖，診療報酬明細書與金錢的流向如下。

flowchart LR
    PT["患者"] -->|"就診・部分負擔金"| MED["醫療機構<br/>(用收費電腦製作診療報酬明細書)"]
    MED -->|"診療報酬明細書(申報)"| SSK["審查支付機構<br/>(支付基金・國保連)"]
    SSK -->|"審查完成的申報"| HKN["保險人"]
    HKN -->|"支付"| SSK
    SSK -->|"支付"| MED
    SSK -.->|"退件・審定的通知"| MED

本文所要處理的，是中間這段「診療報酬明細書從醫療機構通過審查支付機構的這段過程中，會在哪裡被檢查什麼」。

預設讀者是參與醫療機構相關系統(收費電腦串接、電子病歷、部門系統)的工程師，以及院內的資訊系統負責人。不預設具備醫療事務的實務經驗。也不預設已讀過本系列，但如果讀過以下幾回，會更容易理解背景。

目次

1. 先講結論 ── 診療報酬明細書要通過「4道關卡」
2. 用語最短整理 ── 退件・審定・增減點・再審查
3. 關卡① 用原始碼閱讀ORCA的資料檢核業務
4. 作為規則表的檢核主檔(チェックマスタ) ── tbl_chk系列資料表的設計
5. 輸入時檢查與API ── 點檢不是只在月底進行
6. 關卡② レセ電資料檢核 ── 申報資料的點檢
7. 關卡③④ 審查支付機構的電腦檢核與比對・縱覽點檢
8. 兩側都是「規則表+引擎」 ── 給工程師的整體圖
9. 實務要點 ── 為了提升點檢精度，系統端能做的事
10. 總結
11. 參考資料

1. 先講結論 ── 診療報酬明細書要通過「4道關卡」

把1份診療報酬明細書從醫療機構輸入到支付為止，所經過的主要檢查點彙整成一張圖，就是這樣。

flowchart LR
    subgraph clinic["醫療機構內"]
        NYU["日常輸入<br/>(輸入時檢查)"]
        DC["① 資料檢核業務<br/>(ORCA: orca41)"]
        REC["② レセ電資料檢核<br/>(申報資料的點檢)"]
        NYU --> DC --> REC
    end
    subgraph SHINSA["審查支付機構(支付基金・國保連)"]
        CC["③ 電腦檢核<br/>+ 比對點檢・縱覽點檢"]
        JIN["④ 職員點檢<br/>+ 審查委員會"]
        CC --> JIN
    end
    REC -->|"線上申報"| CC
    JIN -->|"審查完成的申報"| HOKEN["保險人"]
    HOKEN -.-> PAY["支付<br/>(經審查支付機構轉交醫療機構)"]
    JIN -.-> RET["退件(退回)・審定(減點)<br/>(通知醫療機構 → 修正・重新申報)"]

• 關卡①(內容點檢)：收費電腦負責檢查「病名與用藥是否吻合」「有無算定遺漏」等診療內容的整合性。在ORCA中，這由資料檢核業務負責。
• 關卡②(申報資料點檢)：把要提交的電子診療報酬明細書(レセ電檔案)當作申報資料來檢查(從記錄格式到留言記載要件都涵蓋)。在ORCA中，這是レセ電資料檢核。
• 關卡③(機械審查)：審查支付機構的電腦檢核，會依告示・通知與醫藥品仿單為依據的規則，機械式地掃描診療報酬明細書，並在有疑慮的項目上做記號。比對同一患者醫科・調劑診療報酬明細書的比對點檢、與過去月份診療報酬明細書比較的縱覽點檢，也都包含在這一關。
• 關卡④(人工審查)：職員以機械做的記號為線索進行點檢，最終由審查委員會判斷。判斷結果會以退件或審定的形式通知醫療機構。

身為工程師該掌握的本質是，關卡①與關卡③是從兩側進行「同一種檢查」。醫療機構這一側想的是「希望在提交前，先找出審查時可能被抓到的申報」；審查那一側想的是「希望找出不符合規則的申報」。這種對稱性，會如同後面所見，以實作結構的相似性(雙方都是規則表+引擎)呈現出來。

2. 用語最短整理 ── 退件・審定・增減點・再審查

以下用最短篇幅整理制度用語。

重要的是，退件是「重來一次」，審定則是「減額已確定」，兩者影響的輕重不同。而比對點檢・縱覽點檢，能檢測出只看單張診療報酬明細書無法察覺的錯誤(跨月的次數限制、醫科與調劑之間的不一致)。不過兩者性質不同：與其他機構的診療報酬明細書進行比對(比對點檢)，原理上醫療機構內部無法做到；另一方面，與自家醫院過去月份的比較(相當於縱覽點檢)，在自家資料的範圍內是可以做到的。理解這條界線之後，「凡是內部能抓到的都在內部抓到」就成為點檢業務的目標。

3. 關卡① 用原始碼閱讀ORCA的資料檢核業務

原始碼的取得方式，以及本文的閱讀方式

接下來要開始閱讀原始碼。因為任何人都能在自己手邊做同樣的事，所以先把路徑寫在前面。

• 取得方式：ORCA Project的技術資訊頁面公開了原始碼。每月1日，會以tar包(zip)的形式公開上個月1日時點的原始碼，5.2系列的本體是https://ftp.orca.med.or.jp/pub/src/jma-receipt.r_5_2_branch.zip(無法顯示目錄清單，請從技術資訊頁面的連結取得)。
• 本章以後會開啟的檔案：業務結構是lddef/orca41.ld，畫面是screen/D0x.glade，檢查處理是cobol/orca41/與cobol/orcabt/，規則表的定義則是record/tbl_chk*.db與cobol/copy/CPCHK.INC。
• 追蹤方式：用日文搜尋容易受文字編碼影響，因此先以英數字識別碼為線索最為可靠。

# 資料檢核業務的結構(畫面・批次・API的清單)
less lddef/orca41.ld

# 檢查邏輯本體的批次程式群
ls cobol/orcabt/ORCDTCHK*.CBL

# 規則表的定義，以及附有日文註解的項目定義
less record/tbl_chk.db
less cobol/copy/CPCHK.INC

先掌握檔案種類的稱呼方式。即使不熟悉COBOL或GTK，只要弄懂這3種就能讀懂。

業務結構

ORCA的資料檢核是業務選單41號，在原始碼上對應cobol/orca41/目錄與lddef/orca41.ld。只要看LD定義，就能直接看出結構。

• 畫面系：以D01「診療報酬明細書檢查指示」為起點，分別分支到D02「個別指示」・D03「確認項目設定登錄」・D04「錯誤內容確認」，D05「例外設定清單」則由D04呼叫(分支邏輯在ORCGD01.CBL・ORCGD04.CBL的轉場處理中，畫面名稱可在各screen/D0x.glade的標題中確認)。
• 引擎系：檢查邏輯的本體不在畫面那一側，而是位於批次程式群cobol/orcabt/ORCDTCHK000〜011.CBL。從畫面這一側，是由ORCGDSUB02.CBL以工作(shell ID ORCBSD1)的形式啟動這個批次，對話畫面與檢查處理彼此分離。
• API系：以bindapi "datacheckv3"的形式，繫結了一支能從外部啟動資料檢核的API(ORCGDAPI01)。

API的請求定義(record/xml_data_checkv3req.db)，用最精簡的方式告訴我們這個業務的輸入規格。

data_checkv3req {
    Request_Number             varchar(02);   -- 00=取得資訊 / 01=執行檢查 / 02=狀態確認
    Karte_Uid                  varchar(36);   -- 呼叫端識別(執行時為必填。空白則出錯)
    Orca_Uid                   varchar(36);   -- 工作識別(狀態確認時為必填。於執行時的回應中取得)
    Perform_Month              varchar(07);   -- 對象診療年月
    Start_Day / End_Day        varchar(02);   -- 日期範圍
    InOut                      varchar(01);   -- 門診・住院區分
    Check_Insurance_Information { Id; }[6];   -- 對象保險(最多6筆)
    Check_Item_Information    { Id; }[22];    -- 確認項目ID(最多22筆)
    Patient_Information { Patient_ID; }[100]; -- 對象患者(最多100筆)
};

(Request_Number各值的意義，可從ORCGDAPI01.CBL的常數定義與分支中確認；Karte_Uid・Orca_Uid的必填檢查，則可從ORCGDAPI01S01.CBL・ORCGDAPI01S02.CBL中確認。這是一種非同步設計：執行(01)以工作的形式運行，並附上執行回應中取得的Orca_Uid，透過狀態確認(02)追蹤進度。)

值得注意的是，Check_Item_Information是一個22個元素的陣列。資料檢核並非單一的檢查，而是一組稱為「確認項目」的檢查集合，其設計是在執行時選擇要跑哪幾項。錯誤內容確認畫面(D04.glade)也有例外登錄的機制，可以把個別錯誤抑制為「不檢查(當月)」「不檢查(常時)」(例外會儲存在資料表tbl_chkreigai中)。這是一種能透過營運方式消除誤判的、實用的規則引擎形態。

順帶一提，D04.glade裡放了「Pontal」(解熱鎮痛劑)與「胃潰瘍」作為範例資料，以及檢核主檔區分「1 藥劑與病名」。就連畫面定義的範例中，也刻著下一章要看到的「藥劑與病名對應檢查」這個代表性的使用情境。

4. 作為規則表的檢核主檔(チェックマスタ) ── tbl_chk系列資料表的設計

資料檢核所擁有的「什麼才是正確」的知識，存放的地方分成兩處。

• 規則表(檢核主檔)所持有的內容：適應病名・禁忌・併用算定等，醫藥品與診療行為之間的對應關係。這些並非硬編碼在COBOL裡，而是以資料的形式存放在一群資料表中。
• 程式碼所持有的內容：保險・記號號碼・實際診療日數整合性等，涉及制度基本結構的檢查。這些直接實作在批次程式群(ORCDTCHK*)中，修改歷史裡也並列著「支號資料檢核因應」「勞動保險編號資料檢核因應」之類程式端的追加補強。

換句話說，「只要整備好檢核主檔，所有規則就都能改變」的理解是錯誤的。規則表所負責的只有前者的領域，後者則唯有透過程式的改修才能改變。

在這個前提下，從資料表清單(lddef/orcadb.inc)中抽出相關資料表如下:

規則的結構可以在record/tbl_chk.db與COPY句cobol/copy/CPCHK.INC(項目附有日文註解)中確認。只抽出本質的話，一列規則會是這樣的形式。

檢查區分(CHKKBN) + 診療代碼(SRYCD) + 有效期間(YUKOSTYMD〜YUKOEDYMD)
  → 對應的代碼集合(CDKBN + CD)、門診/住院區分、處理區分

換句話說，這是一條「診療代碼X，在期間Y內，必須對應到代碼集合Z之中的某一個(或是不得共存)」的宣告式規則。有哪些種類的規則，列舉在檢核主檔的報表輸出畫面(screen/X91.glade)中。

• 藥劑與病名 / 病名與藥劑(適應病名的對應)
• 診療行為與病名 / 病名與診療行為
• 藥劑與併用禁忌
• 投藥禁忌藥劑與病名
• 診療行為的併用算定(同日內・同月內・同結帳內)
• 診療行為之間的算定遺漏
• 算定次數檢查

有趣的地方在於「藥劑與病名」和「病名與藥劑」是成對出現的。方向一旦相反，想要偵測的東西也會跟著改變。

不過在實作上，這並不是同一張表的反向查詢。閱讀報表程式(cobol/orca103/ORCHXLST.CBL)可以發現，如上表所示，它們是用不同的資料表・不同的鍵值來管理的，需要注意的是：只登錄單一方向，並不代表反方向也會自動生效。之所以擁有有效期間，是為了讓規則能跟上每兩年一次的診療報酬修訂，以及藥價收載・刪除，第1篇中所見的「緊跟制度變化正是收費電腦的本質」，也貫穿在規則表的設計之中。

另外，並非所有規則都能套進上面這一種形狀。tbl_chksnd・tbl_chk005具有存放病名字串(BYOMEI)與疑似病名處理方式的形狀，tbl_chktrd則具有存放同日・同月區分(DAYMONTHKBN)的形狀，規則資料表本身會依檢查種類的不同，被正規化成不同的形狀。雖然統稱為「規則表」，但並非單一的綱要(schema)──這是閱讀實作時要留意的一點。

5. 輸入時檢查與API ── 點檢不是只在月底進行

資料檢核雖然是月次的批次點檢，但檢查並不只有這一種。從原始碼中，也能確認到在更上游──也就是日常輸入的當下──運作的機制。

• 併用禁忌檢查API：/api01rv2/contraindicationcheckv2(負責程式ORAPI021R4V2「併用禁忌藥劑資訊返回」，標頭的建立日期為2016年)。這是一支傳入患者與藥劑，就會回傳併用禁忌相符資訊的API，可以做成電子病歷在處方輸入的當下向日レセ查詢的串接方式。
• 資料檢核API：也就是前一章提到的datacheckv3。因為能在不操作畫面的情況下啟動月次批次，所以可以架構出「每晚自動檢查當月份資料，隔天早上輸出錯誤清單」這樣的運作方式。

這裡有一個設計上放諸四海皆準的教訓：錯誤離發生源頭越近，修正的成本就越低。在月底的資料檢核中發現的錯誤，得整理成整整一個月份一起修正；但如果能在處方輸入的當下就發現併用禁忌，只需幾秒鐘就能處理完畢(補充說明：這支API所看的是併用禁忌。像是適應病名缺漏這類對應關係的檢查，屬於月次資料檢核那一側的守備範圍，並不會在輸入時就替你代勞)。ORCA的檢查機制之所以呈現「輸入時(API)→月次(資料檢核)→提交前(レセ電檢核)」的多段結構，正是這項原則的實作。

6. 關卡② レセ電資料檢核 ── 申報資料的點檢

資料檢核所看的是「診療內容的整合性」，相對地，在提交前夕還有另一道稱為レセ電資料檢核的檢查在等著。它的對象是電子診療報酬明細書(レセ電)檔案，檢查的是記錄格式、有無必要記錄等等作為申報資料的正確性。

這項檢查的條件，在ORCA官方網站上以「レセ電データチェック チェック条件仕様(レセ電資料檢核 檢查條件規格)」的名義以PDF公開(醫保・勞災・術後照護共3種)。也就是說，ORCA不僅公開了內容檢查(檢核主檔可透過報表或CSV確認)，就連レセ電檢核的條件規格也以文件形式公開，讓人可以用第一手資料確認「究竟在檢查什麼」。

不過，把レセ電檢核當成「純粹形式上的檢查」並不準確。看原始碼就會發現，檢查診療報酬明細書留言記載要件的子程式(cobol/common/ORCSRECECOMCHK.CBL，2018年新增)，以及與線上診療費等相關的管理費・指導費算定歷程檢查(ORCSRECESRCHK.CBL)，都實作在レセ電處理這一側；而月次處理的Ruby腳本(在版本庫中是scripts/monthly/receden_check.rb.in，安裝時會部署為receden_check.rb的樣板)，甚至還做到與點數主檔・病名主檔的整合驗證(COBOL的世界裡竟然同居著Ruby，這也是這份原始碼有趣的地方)。大致上是「資料檢核＝診療內容、レセ電檢核＝申報資料」這樣的分工，但界線並不嚴謹，意義層面檢查的一部分是由レセ電檢核負責的──若在這裡想得太乾脆，就會誤判錯誤的出處。兩者都通過之後，才會成為「可以送審的診療報酬明細書」，這一點是實務上的要點。

7. 關卡③④ 審查支付機構的電腦檢核與比對・縱覽點檢

提交後的診療報酬明細書，會進入審查支付機構(受僱者保險是支付基金，國保・後期高齡者是國保連)的審查。這裡重要的是，審查那一側的檢查規則，也有一部分是公開的。

支付基金的「コンピュータチェックに関する公開(電腦檢核相關公開)」頁面中，提供了2種公開檔案(皆為CSV格式，正分階段擴大範圍)。

請留意這個名稱：支付基金這一側，同樣使用了「チェックマスタ(檢核主檔)」這個詞。把以告示・通知為依據的規則，和以仿單為依據的規則分開管理的結構，正好與ORCA把點數算定規則放在程式、把醫藥品適應症放在檢核主檔的結構，完美對應。

另一方面，也有不公開的檢查。公開頁面上明確寫著，需要確認摘要欄記載事項的事例、需要醫學判斷的事例、與醫藥品・診療行為適應症有關的事例等，會謹慎考慮是否公開。此外，支付基金也反覆說明其定位：電腦檢核只是在有疑慮的項目上做記號，並非機械式地審定，而是要經過職員的點檢與審查委員會的判斷。「電腦檢核＝自動審定」並不成立，這一點也是系統端的人應該正確理解的地方。

接著是第2章提到的比對點檢・縱覽點檢。這兩者從2012年起正式展開，檢查的不是單張診療報酬明細書，而是診療報酬明細書之間的關係。在此把界線劃分清楚。比對點檢(比對同一患者的醫科診療報酬明細書與調劑診療報酬明細書)，對手是調劑藥局這種其他機構的診療報酬明細書，因此原理上無法用醫療機構內部的點檢來取代。另一方面，相當於縱覽點檢(比較同一患者當月與過去月份)的內容，只要在自家醫院的申報歷程範圍內，院內也做得到。在自家資料的範圍內，嚴格管理有次數限制的算定，以及管理對應院外處方的病名，是減少比對・縱覽點檢中被指出問題的現實對策。

8. 兩側都是「規則表+引擎」 ── 給工程師的整體圖

把到目前為止的內容濃縮成一張表，診療報酬明細書點檢的世界看起來就是這樣。

結構是同型的，差異在於規則的涵蓋範圍與檢查範圍。從這裡能為工程師導出3個結論。

1. 規則是資料、引擎是程式這樣的分離，是能持續跟上制度改定20年以上的必要條件。如果規則被埋在程式碼裡，每次改定都得全面改修。
2. 在與檢核主檔連動的領域(適應病名・禁忌等)，醫療機構端的點檢精度，與其說取決於引擎有多聰明，不如說取決於規則表的充實程度(至於保險・實際診療日數等程式碼實作端的檢查，程式本身的守備範圍就直接等於檢測力)。ORCA的檢核主檔分成官方提供的部分(tbl_chk_master)與使用者登錄的部分(tbl_chk_user)兩個系統，設計上讓自家醫院能自行增加規則。市售診療報酬明細書點檢軟體的價值，追根究柢也在於其獨家規則表的充實程度。
3. 如今審查端的部分規則已經公開，「該如何把審查端公開的規則納入自家醫院的點檢」，已成為新的實務課題。以公開CSV這種機器可讀格式提供的意義，身為工程師應該不會錯過。

9. 實務要點 ── 為了提升點檢精度，系統端能做的事

站在醫療機構系統負責人或串接廠商的立場，整理出應該掌握的重點。

1. 把檢查的多段結構映射到營運上。 輸入時(併用禁忌API等)→月次(資料檢核)→提交前(レセ電檢核)這3段各自扮演不同角色。如果目前的作法只是「月底跑一次資料檢核」，那還有活用上游2段的餘地。
2. 資料檢核可以用API自動化。 可以用datacheckv3指定確認項目・對象患者，架構出定期執行。做成夜間批次＋早上輸出錯誤清單的形式，就能把月底的點檢負荷分散到每一天。
3. 把例外登錄當成「規則的調校」來對待。 放任誤判不管，錯誤清單就會沒人讀。有計畫地維護例外(tbl_chkreigai)與自家醫院規則(tbl_chk_user)，維持錯誤清單的訊噪比，是點檢業務的命脈。
4. 把退件・審定的結果回饋到分析迴圈中。 彙整增減點聯絡書上的事由，把常見的模式反映到檢核主檔的自家醫院規則，或是輸入時的運作方式──這就是「培養規則表」，也是縮小與審查端認知落差的唯一方法。
5. 定期查看審查端的公開資料。 支付基金的電腦檢核公開持續在更新。在審查端連比對・縱覽點檢的解說都納入，公開說明「自己在看什麼」的這個時代，沒有理由不去讀它。

10. 總結

• 診療報酬明細書要通過①收費電腦的內容檢查→②レセ電資料檢核→③審查端的電腦檢核(+比對・縱覽點檢)→④職員・審查委員會這樣多段的關卡。退件是退回，審定是減點；與其他機構診療報酬明細書比對的比對點檢，醫療機構內部無法取代(與自家醫院過去月份的比較，院內也做得到)。
• ORCA的資料檢核以orca41業務的形式實作，適應病名・禁忌・併用算定等規則以資料形式存放在檢核主檔中(保險・實際診療日數等基本整合性則在程式碼那一側)。可以選擇確認項目來執行、用例外登錄抑制誤判、也能透過datacheckv3 API從外部驅動──從公開原始碼就能確認到這種程度。
• 審查端也把本部點檢條件+檢核主檔這樣的規則表以CSV公開，醫療機構端與審查端擁有同型的「規則表+引擎」結構。差異在於規則的涵蓋範圍與檢查範圍(只有審查端能看到全機構・全月份)。
• 決定點檢精度的不是引擎，而是規則表的充實程度與運作方式。例外登錄・自家醫院規則・審定結果的分析迴圈・納入審查端公開規則，是實務上的要點。

系列下一回以後，預計會處理直接閱讀ORCA資料庫綱要的「資料庫篇」，以及自動追蹤月次原始碼公開的diff監控實務運作等主題。

11. 參考資料

• 電腦檢核相關公開 - 社會保險診療報酬支付基金(本部點檢條件・檢核主檔的CSV公開)
• 比對點檢・縱覽點檢 - 社會保險診療報酬支付基金
• 診療報酬明細書的點檢、審查、退件、審定、再審查請求等 - 東京都醫師會「開業醫師的保險診療要點」
• 日醫標準レセプト軟體門診版手冊(資料檢核相關) - ORCA Project
• レセ電資料檢核 檢查條件規格 - ORCA Project
• 技術資訊 - ORCA Project(原始碼的月次公開・資料庫資料表定義書)
• 日レセ本體 5.2系列原始碼(2026年7月公開快照) lddef/orca41.ld / cobol/orca41/ORCGD*.CBL / cobol/copy/CPCHK.INC / record/tbl_chk*.db / record/xml_data_checkv3req.db / screen/D01.glade / screen/D04.glade / screen/X91.glade / lddef/api01rv2.ld(contraindicationcheckv2)等 ── 本文中關於實作的敘述，全部依據這份快照

相關文章

共用相同標籤的最新文章。能以相近的主題延伸理解。

相關主題

與本文相近的主題頁面。以本文為起點，可進一步連到相關服務與其他文章。

與本主題相關的服務

本文連結到以下服務頁面，歡迎從最接近的入口查看。

常見問題

整理諮詢這個主題時常見的問題。

審定與退件有什麼不同？

兩者都與審查支付機構(社會保險診療報酬支付基金・國民健康保險團體聯合會)的審查有關，但意義不同。退件是指診療報酬明細書被退回醫療機構，修正記載不完備或資格錯誤等問題後，可在下個月以後重新申報。審定則是審查結果導致點數增減(實務上幾乎都是減點)，申報金額也隨之減少。若對審定結果不服，則有再審查請求這項程序。

診療報酬明細書在提交之前會被檢查幾次？

大致上會通過多段檢查。在醫療機構內部，有收費電腦進行的內容檢查(ORCA的話就是資料檢核業務)，以及把電子診療報酬明細書檔案當作申報資料來檢查的レセ電資料檢核。提交後，會經過審查支付機構的電腦檢核(以告示・通知為依據的點檢條件，以及以醫藥品仿單為依據的檢核主檔)、比對同一患者醫科・調劑診療報酬明細書的比對點檢、與過去申報月份比較的縱覽點檢，最後由職員與審查委員會進行審查。

ORCA(日レセ)的診療報酬明細書檢查是如何實作的？

它是以資料檢核業務(業務選單41)的形式實作的，可以透過公開原始碼確認實作內容。醫藥品・診療行為之間對應關係的規則(藥劑與病名、診療行為與病名、藥劑與併用禁忌等)是以資料形式存放在稱為「チェックマスタ(檢核主檔)」的一群資料表中，再由COBOL程式解讀這些資料來檢查患者資料，是一種「規則表+引擎」的結構。保險、實際診療日數等整合性之類的基本檢查，則是直接實作在程式那一側。此外也備有錯誤例外登錄機制(這個錯誤不檢查)，以及讓外部系統啟動資料檢核的API(datacheckv3)。

審查支付機構的檢查規則有公開嗎？

有一部分是公開的。支付基金以「コンピュータチェックに関する公開(電腦檢核相關公開)」為名，將以告示・通知為依據的本部點檢條件，以及以醫藥品仿單為依據的檢核主檔以CSV檔案形式公開，並持續分階段擴大公開範圍。此外，比對點檢・縱覽點檢的機制也在官方網站上有說明。不過，像是需要確認摘要欄或需要醫學判斷的案例，也存在不公開的檢查項目。

作者檔案

本文作者的個人檔案頁面。

Go Komura

小村軟體有限公司 代表

以 Windows 軟體開發、技術諮詢與故障調查為中心，在難以重現的故障調查與既有資產仍在運作的專案上具有優勢。