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

記事「査定と返戻はどこで起きるのか ── レセプト点検のロジックをORCAのソースコードと公開資料から分解する」の主張を、概念と関係(エッジ)に分解した知識グラフの全体です。各関係には根拠・確認日・確度が付いています。

レセプトは医療機関内のデータチェック業務(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件)

図と同じ関係を文章でも列挙します。表示している文と機械可読な意味データ(RDFa)は同じ要素に載っています。確度が「確立した関係」のものは直接の関係として、「条件付きの関係」のものは成立条件つきの言明(rdf:Statement)として表現しています。

• 日レセ(ORCA)はデータチェック業務(ORCA業務メニュー41)の実装を担います。ORCAはデータチェック業務(業務メニュー41)の実装を担う / 確度: 確立した関係 / 確認日: 2026-08-01 出典
• データチェック業務(ORCA業務メニュー41)はチェックマスタ(ORCA)を利用します。データチェックは、適応病名・禁忌・併用算定などの対応関係をチェックマスタというルール表から読み込んで検査する / 確度: 確立した関係 / 確認日: 2026-08-01 出典
• データチェック業務(ORCA業務メニュー41)は例外登録(tbl_chkreigai)を利用します。データチェックのエラー内容確認画面には例外登録の仕組みがあり、個々のエラーを当月または常時チェックしないよう抑止できる / 確度: 確立した関係 / 確認日: 2026-08-01 出典
• datacheckv3 APIはデータチェック業務(ORCA業務メニュー41)を自動化します。datacheckv3 APIは、画面操作なしでデータチェック業務を外部システムから起動・状態確認できるようにする / 確度: 確立した関係 / 確認日: 2026-08-01 出典
• 併用禁忌チェックAPI(contraindicationcheckv2)は査定を軽減します。処方入力の時点で併用禁忌を検知でき、月次のデータチェックより早い段階でエラーを直せるため、結果として査定・返戻のリスクを下げる / 確度: 条件付きの関係 / 確認日: 2026-08-01 出典
• データチェック業務(ORCA業務メニュー41)はレセ電データチェックより先に行うべきです。医療機関内では、診療内容の整合性を見るデータチェックを行ったうえで、提出直前のレセ電データチェックに進む / 確度: 確立した関係 / 確認日: 2026-08-01 出典
• レセ電データチェックはコンピュータチェック(審査支払機関)より先に行うべきです。医療機関が提出前に行うレセ電データチェックは、提出後に審査支払機関が行うコンピュータチェックより先に行われる / 確度: 確立した関係 / 確認日: 2026-08-01 出典
• コンピュータチェック(審査支払機関)は本部点検条件を利用します。コンピュータチェックは、告示・通知に基づく本部点検条件をルールとして走査する / 確度: 確立した関係 / 確認日: 2026-08-01 出典
• コンピュータチェック(審査支払機関)は審査側チェックマスタを利用します。コンピュータチェックは、医薬品添付文書に基づく審査側チェックマスタもルールとして走査する / 確度: 確立した関係 / 確認日: 2026-08-01 出典
• コンピュータチェック(審査支払機関)は査定の原因になることがあります。コンピュータチェックが付けた印をもとに職員が点検し、審査委員会の判断を経て査定に至ることがある / 確度: 条件付きの関係 / 確認日: 2026-08-01 出典
• 突合点検は査定の原因になることがあります。同一患者の医科・調剤レセプトの不一致が突合点検で見つかると査定につながることがある / 確度: 条件付きの関係 / 確認日: 2026-08-01 出典
• 縦覧点検は査定の原因になることがあります。算定回数制限の超過などが縦覧点検で見つかると査定につながることがある / 確度: 条件付きの関係 / 確認日: 2026-08-01 出典
• レセ電データチェックは返戻を軽減します。提出前に記録形式や必須記録の有無を検査することで、形式不備を理由にした返戻を防げる / 確度: 条件付きの関係 / 確認日: 2026-08-01 出典
• 査定は再審査請求の原因になることがあります。査定の結果に不服がある場合、医療機関は再審査請求という手続きを取ることができる / 確度: 確立した関係 / 確認日: 2026-08-01 出典
• データチェック業務(ORCA業務メニュー41)は査定を軽減します。レセコン側の内容点検で誤りを事前に見つけられれば、審査支払機関での査定を避けられる / 確度: 条件付きの関係 / 確認日: 2026-08-01 出典
• データチェック業務(ORCA業務メニュー41)は返戻を軽減します。レセコン側の内容点検で記載不備を事前に見つけられれば、審査支払機関からの返戻を避けられる / 確度: 条件付きの関係 / 確認日: 2026-08-01 出典
• データチェック業務(ORCA業務メニュー41)はルール表+エンジン構造の実装を担います。データチェック業務は、ルール(チェックマスタ)とエンジン(COBOLプログラム)を分離した構造で実装されている / 確度: 確立した関係 / 確認日: 2026-08-01 出典
• コンピュータチェック(審査支払機関)はルール表+エンジン構造の実装を担います。審査支払機関のコンピュータチェックも、本部点検条件・チェックマスタというルール表とシステムというエンジンを分離した同型の構造を持つ / 確度: 確立した関係 / 確認日: 2026-08-01 出典
• 審査支払機関はコンピュータチェック(審査支払機関)を利用します。審査支払機関はコンピュータチェックによってレセプトを機械的に走査する / 確度: 確立した関係 / 確認日: 2026-08-01 出典
• 審査支払機関は突合点検の実装を担います。審査支払機関は突合点検の実施を担う / 確度: 確立した関係 / 確認日: 2026-08-01 出典
• 審査支払機関は縦覧点検の実装を担います。審査支払機関は縦覧点検の実施を担う / 確度: 確立した関係 / 確認日: 2026-08-01 出典
• 保険者は審査支払機関を前提とします。保険者による支払いは、審査支払機関がレセプトを審査し取りまとめることを前提とする / 確度: 確立した関係 / 確認日: 2026-08-01 出典
• データチェック業務(ORCA業務メニュー41)はレセプト(診療報酬明細書)を前提とします。データチェック業務は、検査対象として作成中・作成済みのレセプトのデータを前提とする / 確度: 確立した関係 / 確認日: 2026-08-01 出典
• 審査支払機関はレセプト(診療報酬明細書)を前提とします。審査支払機関の審査は、医療機関から提出されたレセプトを前提とする / 確度: 確立した関係 / 確認日: 2026-08-01 出典

主要概念の定義

レセプト(診療報酬明細書)

患者ごと・月ごとの診療内容と請求額をまとめた明細書で、医療機関が保険分の代金を請求するために作成する。

査定

審査の結果として点数が増減(実務上はほぼ減点)され、請求金額が減ることである。

返戻

記載不備や資格エラーなどを理由に、レセプトが審査支払機関から医療機関へ差し戻されることで、修正して翌月以降に再請求できる。

日レセ(ORCA)

日本医師会が提供する、ソースコードが公開されているレセコンである。

データチェック業務(ORCA業務メニュー41)

医薬品と診療行為の対応関係や保険・実日数の整合など、診療内容の整合性をレセコン側で検査するORCAの業務である。

datacheckv3 API

外部システムからORCAのデータチェック業務を起動できるAPIで、確認項目・対象患者を指定した実行と状態確認を非同期で行う。

併用禁忌チェックAPI(contraindicationcheckv2)

患者と薬剤を渡すと併用禁忌の該当情報を返す、処方入力時点で使えるORCAのAPIである。

レセ電データチェック

提出直前に、電子レセプト(レセ電)ファイルの記録形式や必須記録の有無など請求データとしての正しさを検査するチェックである。

コンピュータチェック(審査支払機関)

審査支払機関が、告示・通知や医薬品添付文書に基づくルールでレセプトを機械的に走査し、疑いのある項目に印を付ける仕組みである。

突合点検

同一患者・同一月の医科(歯科)レセプトと調剤レセプトを電子的に付き合わせる点検である。

縦覧点検

同一患者の当月レセプトを過去複数月分と比較する点検で、算定回数制限の超過などを検出する。

審査支払機関

医療機関から提出されたレセプトを審査し、保険者に代わって医療機関へ支払う機関で、被用者保険は社会保険診療報酬支払基金、国保・後期高齢者は国民健康保険団体連合会が担う。

保険者

健康保険組合・協会けんぽ・市町村など、公的医療保険を運営し最終的な支払いの原資を持つ主体である。

機械可読データ

• JSON-LD / Turtle ── この記事の知識グラフ全体
• 概念一覧 / 語彙(述語)の定義

このページはサイトの知識グラフ(_data/knowledge/)から自動生成されています。誤りの指摘はお問い合わせからお願いします。