査定と返戻はどこで起きるのか ── レセプト点検のロジックをORCAのソースコードと公開資料から分解する

医療機関の窓口収入は一部にすぎず、収入の大半は月に一度のレセプト請求で決まります。だからこそ現場では「査定された」「返戻が来た」という言葉が重い意味を持つのですが、システムに関わるエンジニアにとって、査定・返戻がどこで・どんなロジックで発生するのかは意外なほど見えにくいテーマです。

シリーズ第1回でレセコンの役割を、第2回で日レセAPIを、第3回でオンライン資格確認を扱いました。今回はレセプト業務の本丸である点検・審査のロジックを、レセプトが通る「関所」を一列に並べる形で分解します。

• 返戻・査定・再審査という用語の正確な意味
• 医療機関内のチェック ── ORCAのデータチェック業務とチェックマスタの実装
• 提出前のレセ電データチェック
• 審査支払機関側のチェック ── コンピュータチェック・突合点検・縦覧点検
• レセコン側と審査側が、構造的には同じ「ルール表+エンジン」であること

制度側の記述は支払基金・医師会等の公開資料に、ORCAの実装に関する記述は公式公開されている日レセ本体 5.2系ソース(2026年7月1日公開スナップショット) を実際に読んで確認した結果に基づきます。

目次

1. まず結論 ── レセプトは「4つの関所」を通る
2. 用語の最短整理 ── 返戻・査定・増減点・再審査
3. 関所① ORCAのデータチェック業務をソースで読む
4. チェックマスタというルール表 ── tbl_chk系テーブルの設計
5. 入力時チェックとAPI ── 点検は月末だけではない
6. 関所② レセ電データチェック ── 請求データの点検
7. 関所③④ 審査支払機関のコンピュータチェックと突合・縦覧点検
8. 両側とも「ルール表+エンジン」である ── エンジニアの見取り図
9. 実務ポイント ── 点検精度を上げるためにシステム側でできること
10. まとめ
11. 参考資料

1. まず結論 ── レセプトは「4つの関所」を通る

1件のレセプトが医療機関の入力から支払いに至るまでに通る主なチェックポイントを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. 用語の最短整理 ── 返戻・査定・増減点・再審査

制度用語を最短で整理します。

重要なのは、返戻は「やり直し」、査定は「減額の確定」で、影響の重さが違うことです。そして突合点検・縦覧点検は、1枚のレセプト単票を見ているだけでは検出できないエラー(月をまたぐ回数制限、医科と調剤の食い違い)を検出します。ただし性質は異なり、他機関のレセプトとの突き合わせ(突合)は医療機関内では原理的にできない一方、自院の過去月との比較(縦覧に相当)は自院データの範囲で可能です。この線引きを理解した上で「内側で拾えるものは全部内側で拾う」のが点検業務の目標になります。

3. 関所① ORCAのデータチェック業務をソースで読む

ここからソースを読みます。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がジョブ(シェル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にはサンプルデータとして「ポンタール」(解熱鎮痛剤)と「胃潰瘍」、チェックマスタ区分「1 薬剤と病名」が置かれています。画面定義のサンプルにまで、次章で見る「薬剤と病名の対応チェック」という代表的なユースケースが刻まれているわけです。

4. チェックマスタというルール表 ── tbl_chk系テーブルの設計

データチェックの「何が正しいか」の知識のうち、医薬品・診療行為の対応関係にかかわる部分は、COBOLにハードコードされているのではなく、チェックマスタと呼ばれるテーブル群にデータとして入っています。一方、保険・記号番号・実日数の整合といった制度の基本構造にかかわるチェックは、バッチ群(ORCDTCHK*)のコードに直接実装されており、修正履歴にも「枝番データチェック対応」「労働保険番号データチェック対応」のようなコード側の追補が並びます。チェックマスタを整備すればすべてのルールが変わる、という理解は誤りで、ルール表が受け持つのは適応病名・禁忌・併用算定などの領域です。その前提で、テーブル一覧(lddef/orcadb.inc)から関連テーブルを抜き出すと:

ルールの構造はrecord/tbl_chk.dbとCOPY句cobol/copy/CPCHK.INC(項目に日本語コメント付き)で確認できます。本質だけ抜くと1行のルールはこういう形です。

チェック区分(CHKKBN) + 診療コード(SRYCD) + 有効期間(YUKOSTYMD〜YUKOEDYMD)
  → 対応するコードの集合(CDKBN + CD)、入外区分、処理区分

つまり「診療コードXには、期間Y内において、コード集合Zのどれかが対応していなければならない(あるいは共存してはならない)」という宣言的なルールです。どんな種類のルールがあるかは、チェックマスタの帳票出力画面(screen/X91.glade)に列挙されています。

• 薬剤と病名 / 病名と薬剤(適応病名の対応)
• 診療行為と病名 / 病名と診療行為
• 薬剤と併用禁忌
• 投与禁忌薬剤と病名
• 診療行為の併用算定(同日内・同月内・同会計内)
• 診療行為どうしの算定漏れ
• 算定回数チェック

「薬剤と病名」と「病名と薬剤」が対になっているのが面白いところで、前者は「この薬を出すならこの病名が必要」(適応病名の欠落検出)、後者は「この病名があるならこの薬・検査があるはず」(算定漏れの検出)を担います。ただし実装上は1つの表の逆引きではありません。帳票プログラム(cobol/orca103/ORCHXLST.CBL)を読むと、前者はtbl_chksnd、後者はtbl_chk005と別テーブル・別キーで管理されており、片方向を登録すれば逆方向も効くわけではない点に注意が必要です。有効期間を持つのは、2年ごとの診療報酬改定や薬価収載・削除にルール側が追従するためで、第1回で見た「制度追従こそレセコンの本質」がルール表の設計にも貫かれています。

なお、すべてのルールが上の1形状に収まるわけではありません。tbl_chksnd・tbl_chk005には病名の文字列(BYOMEI)や疑い病名の扱いを持つ形状、tbl_chktrdには同日・同月の区分(DAYMONTHKBN)を持つ形状があり、チェックの種類に応じてルールテーブル自体が別形状に正規化されています。「ルール表」と言っても単一のスキーマではない、という点は実装を読むときの注意点です。

5. 入力時チェックとAPI ── 点検は月末だけではない

データチェックは月次のバッチ点検ですが、チェックはそれだけではありません。ソースからは、より上流──日々の入力時点──で動く仕組みも確認できます。

• 併用禁忌チェックAPI: /api01rv2/contraindicationcheckv2(担当プログラムORAPI021R4V2「併用禁忌薬剤情報返却」、ヘッダの作成日付は2016年)。患者と薬剤を渡すと併用禁忌の該当情報を返すAPIで、電子カルテが処方入力の時点で日レセに問い合わせる、という連携が作れます。
• データチェックAPI: 前章のdatacheckv3。月次バッチを画面操作なしで起動できるため、「毎晩、当月分を自動チェックして翌朝エラーリストを出す」といった運用が組めます。

ここには設計上の普遍的な教訓があります。エラーは発生源に近いほど安く直せる。月末のデータチェックで見つかったエラーは1か月分まとめて修正することになりますが、処方入力の時点で併用禁忌に気づければ数秒で対処できます(なお、この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年から本格化したこの2つは、レセプト単票の検査ではなくレセプト間の関係の検査です。ここで境界線を正確に引いておきましょう。突合点検(同一患者の医科レセプトと調剤レセプトの突き合わせ)は、調剤薬局という他機関のレセプトが相手なので、医療機関内の点検では原理的に代替できません。一方、縦覧点検(同一患者の当月と過去月の比較)に相当することは、自院の請求履歴の範囲なら院内でも可能です。回数制限のある算定の管理や、院外処方に対応する病名の管理を自院データの範囲で厳密にやっておくことが、突合・縦覧での指摘を減らす現実的な対策になります。

8. 両側とも「ルール表+エンジン」である ── エンジニアの見取り図

ここまでを1枚に畳むと、レセプト点検の世界は次のように見えます。

構造は同型で、違いはルールの網羅性と検査範囲にあります。ここからエンジニアに引き出せる結論は3つです。

1. ルールはデータ、エンジンはプログラムという分離が、制度改定に20年以上追従するための必須条件だった。ルールがコードに埋まっていたら、改定のたびに全面改修になる。
2. チェックマスタ連動型の領域(適応病名・禁忌など)では、医療機関側の点検精度はエンジンの賢さよりもルール表の充実度で決まる(保険・実日数などコード実装側のチェックは、プログラム自体の守備範囲がそのまま検出力になる)。ORCAのチェックマスタには提供分(tbl_chk_master)とユーザー登録分(tbl_chk_user)の2系統があり、自院でルールを足せる設計になっている。市販のレセプト点検ソフトの価値も、突き詰めれば独自ルール表の充実度にある。
3. 審査側ルールの一部が公開された今、「審査側の公開ルールを自院の点検にどう取り込むか」が新しい実務テーマになっている。公開CSVという機械可読な形式で提供されていることの意味は、エンジニアなら見逃せないはずです。

9. 実務ポイント ── 点検精度を上げるためにシステム側でできること

医療機関のシステム担当や連携ベンダーの立場で、押さえておきたい点をまとめます。

1. チェックの多段構造を運用に写像する。 入力時(併用禁忌API等)→月次(データチェック)→提出前(レセ電チェック)の3段は役割が違います。「月末に1回データチェックを回すだけ」の運用なら、上流の2段を活かす余地があります。
2. データチェックはAPIで自動化できる。 datacheckv3で確認項目・対象患者を指定した定期実行が組めます。夜間バッチ+朝のエラーリストという形にすれば、月末の点検負荷を日々に分散できます。
3. 例外登録を「ルールのチューニング」として扱う。 誤検知を放置するとエラーリストが読まれなくなります。例外(tbl_chkreigai)と自院ルール(tbl_chk_user)を計画的にメンテナンスし、エラーリストの信号対雑音比を保つことが点検業務の生命線です。
4. 返戻・査定の結果を分析ループに戻す。 増減点連絡書の事由を集計し、頻出パターンをチェックマスタの自院ルールや入力時の運用に反映する──これが「ルール表を育てる」ことであり、審査側との認識ギャップを縮める唯一の方法です。
5. 審査側の公開資料を定期的に見る。 支払基金のコンピュータチェック公開は更新され続けています。突合・縦覧点検の解説も含め、審査側が「何を見るか」を公式に説明している時代に、それを読まない手はありません。

10. まとめ

• レセプトは①レセコンの内容チェック→②レセ電データチェック→③審査側のコンピュータチェック(+突合・縦覧点検)→④職員・審査委員会という多段の関所を通る。返戻は差し戻し、査定は減点で、他機関のレセプトと突き合わせる突合点検は医療機関内では代替できない(自院の過去月との比較は院内でも可能)。
• ORCAのデータチェックはorca41業務として実装され、適応病名・禁忌・併用算定などのルールはチェックマスタにデータとして持つ(保険・実日数などの基本整合はコード側)。確認項目を選んで実行し、例外登録で誤検知を抑止し、datacheckv3 APIで外部からも駆動できる──公開ソースでここまで確認できる。
• 審査側も本部点検条件+チェックマスタというルール表をCSV公開しており、医療機関側と審査側は同型の「ルール表+エンジン」構造を持つ。違いはルールの網羅性と検査範囲(全機関・全月を見られるのは審査側だけ)。
• 点検精度を決めるのはエンジンではなくルール表の充実度と運用。例外登録・自院ルール・査定結果の分析ループ・審査側公開ルールの取り込みが実務の要点になる。

シリーズ次回以降は、ORCAのデータベーススキーマを直接読む「DB編」や、月次ソース公開を自動で追うdiff監視の実運用などを予定しています。

11. 参考資料

• コンピュータチェックに関する公開 - 社会保険診療報酬支払基金(本部点検条件・チェックマスタのCSV公開)
• 突合点検・縦覧点検 - 社会保険診療報酬支払基金
• レセプトの点検、審査、返戻、査定、再審査請求など - 東京都医師会「開業医のための保険診療の要点」
• 日医標準レセプトソフト外来版マニュアル(データチェック関連) - 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ファイルで公開しており、段階的に対象を広げています。また突合点検・縦覧点検の仕組みも公式サイトで解説されています。ただし、摘要欄の確認や医学的判断を要する事例など、公開対象外のチェックもあります。

著者プロフィール

記事の著者プロフィールページです。

小村 豪

合同会社小村ソフト 代表

Windows ソフト開発、技術相談、不具合調査を中心に、既存資産が残る案件や原因が見えにくい障害調査に強みがあります。