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

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

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

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

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

用語の最小セット ── これだけ知っていれば読めます

医療業界の略語が続くので、先に最小限だけ固定します。ここから先は、この意味で読み進めてください。

関係を1枚にすると、レセプトと金銭は次のように流れます。

flowchart LR
    PT["患者"] -->|"受診・一部負担金"| MED["医療機関<br/>(レセコンでレセプト作成)"]
    MED -->|"レセプト(請求)"| SSK["審査支払機関<br/>(支払基金・国保連)"]
    SSK -->|"審査済みの請求"| HKN["保険者"]
    HKN -->|"支払"| SSK
    SSK -->|"支払"| MED
    SSK -.->|"返戻・査定の通知"| MED

この記事が扱うのは、真ん中の「レセプトが医療機関から審査支払機関を通っていく間に、どこで何がチェックされるか」です。

想定読者は、医療機関向けシステムに関わるエンジニア(レセコン連携、電子カルテ、部門システム)と、院内の情報システム担当者です。医療事務の実務経験は前提にしません。シリーズ既読も前提にしませんが、次の回を読んでいると背景が分かりやすくなります。

この記事の知識マップ

レセプトは医療機関内のデータチェック業務(ORCAではチェックマスタというルール表とCOBOLエンジンで実装)とレセ電データチェックを経て提出され、審査支払機関のコンピュータチェック・突合点検・縦覧点検を経て査定や返戻に至る。ORCAのチェックマスタと審査支払機関が公開する本部点検条件・チェックマスタは、いずれもルールをプログラムから切り離してデータとして持つ同型の構造を持ち、医療機関側の点検を厚くするほど審査側での査定・返戻のリスクを事前に減らせる。突合点検は他機関のレセプトとの照合が必要なため院内では代替できないが、縦覧点検に相当する自院の過去月比較は院内でも可能であり、例外登録やdatacheckv3 APIによる自動化が点検精度を上げる実務上の要点になる。

flowchart LR
    accTitle: レセプト点検と査定・返戻の知識マップ
    accDescr: 医療機関内のデータチェック業務とレセ電データチェック、審査支払機関のコンピュータチェック・突合点検・縦覧点検という多段のチェックが査定と返戻にどうつながるか、およびORCAと審査側がともにルール表とエンジンを分離した同型の構造を持つことを示す図
    receipt["レセプト(診療報酬明細書)"]
    assessment_reduction["査定"]
    return_rejection["返戻"]
    orca_receipt_system["日レセ(ORCA)"]
    orca_data_check["データチェック業務(ORCA業務メニュー41)"]
    check_master_table["チェックマスタ(ORCA)"]
    exception_registration["例外登録(tbl_chkreigai)"]
    datacheckv3_api["datacheckv3 API"]
    contraindication_check_api["併用禁忌チェックAPI(contraindicationcheckv2)"]
    receipt_electronic_data_check["レセ電データチェック"]
    computer_check["コンピュータチェック(審査支払機関)"]
    honbu_inspection_conditions["本部点検条件"]
    payer_check_master["審査側チェックマスタ"]
    cross_check_review["突合点検"]
    longitudinal_review["縦覧点検"]
    reexamination_request["再審査請求"]
    rule_engine_architecture["ルール表+エンジン構造"]
    claims_review_institution["審査支払機関"]
    insurer["保険者"]
    orca_receipt_system -->|"実装を担う"| orca_data_check
    orca_data_check -->|"利用する"| check_master_table
    orca_data_check -->|"利用する"| exception_registration
    datacheckv3_api -->|"自動化する"| orca_data_check
    contraindication_check_api -.->|"軽減する"| assessment_reduction
    orca_data_check -->|"より先に行うべき"| receipt_electronic_data_check
    receipt_electronic_data_check -->|"より先に行うべき"| computer_check
    computer_check -->|"利用する"| honbu_inspection_conditions
    computer_check -->|"利用する"| payer_check_master
    computer_check -.->|"原因になり得る"| assessment_reduction
    cross_check_review -.->|"原因になり得る"| assessment_reduction
    longitudinal_review -.->|"原因になり得る"| assessment_reduction
    receipt_electronic_data_check -.->|"軽減する"| return_rejection
    assessment_reduction -->|"原因になり得る"| reexamination_request
    orca_data_check -.->|"軽減する"| assessment_reduction
    orca_data_check -.->|"軽減する"| return_rejection
    orca_data_check -->|"実装を担う"| rule_engine_architecture
    computer_check -->|"実装を担う"| rule_engine_architecture
    claims_review_institution -->|"利用する"| computer_check
    claims_review_institution -->|"実装を担う"| cross_check_review
    claims_review_institution -->|"実装を担う"| longitudinal_review
    insurer -->|"前提とする"| claims_review_institution
    orca_data_check -->|"前提とする"| receipt
    claims_review_institution -->|"前提とする"| receipt

図の実線は常に成り立つ関係、破線は条件付きの関係です(成立条件は詳細ページの各関係の説明に記載)。関係すべての一覧(全24件、根拠・確度つき)と主要概念の定義は知識マップ詳細ページにまとめています。データ: JSON-LD / Turtle

目次

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 Projectの技術情報ページでソースが公開されています。毎月1日に、前月1日時点のソースがtarボール(zip)として公開される形で、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がジョブ(シェル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系テーブルの設計

データチェックが持つ「何が正しいか」の知識は、置き場所が2つに分かれています。

• ルール表(チェックマスタ)が持つもの: 適応病名・禁忌・併用算定など、医薬品と診療行為の対応関係。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)を読むと、上の表のとおり別テーブル・別キーで管理されており、片方向を登録すれば逆方向も効くわけではない点に注意が必要です。有効期間を持つのは、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
• 技術情報 - 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 ソフト開発、技術相談、不具合調査を中心に、既存資産が残る案件や原因が見えにくい障害調査に強みがあります。