マイナ保険証をかざすと何が起きるのか ── オンライン資格確認とレセコンの連携をORCAのソースコードから読む

診療所の受付でマイナ保険証をカードリーダーにかざすと、数秒で本人確認と保険資格の確認が終わります。あの数秒の裏で、どんなシステムがどんな順番で動いているのか──特に、最終的に請求を担うレセコンに資格情報がどうやって届くのかを説明できるエンジニアは、意外と少ないのではないでしょうか。

前々回はORCA(日医標準レセプトソフト)がレセコンであること、前回は日レセAPIの全体像をソースコードから把握する方法を書きました。今回はその応用編として、オンライン資格確認(通称オン資)をレセコン側から解剖します。

• マイナ保険証をかざしてから、資格情報がレセコンに登録されるまでの全体フロー
• 資格確認端末とレセコンをつなぐ「ファイル連携」の中身
• ORCA側の受け口 ── オン資関連API 20本とtbl_onshi_*テーブル群
• COBOLの修正履歴に刻まれた、2020年から2026年までの制度対応の年表

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

目次

1. まず結論 ── 資格確認は「4つの登場人物」のリレーである
2. 制度の最短理解 ── オンライン資格確認とは何か
3. 端末とレセコンの間 ── OQSファイル連携という接点
4. ORCA側の受け口 ── オン資関連API 20本をソースから数える
5. データの行き先 ── tbl_onshi_* 13テーブル
6. tbl_onshi_kakuを読む ── 1回の資格確認が何を残すか
7. 修正履歴は制度の年表である ── 2020〜2026
8. 患者登録への反映 ── 結果は「そのまま」保険情報にならない
9. 連携システムを作る側の実務ポイント
10. まとめ
11. 参考資料

1. まず結論 ── 資格確認は「4つの登場人物」のリレーである

マイナ保険証をかざしてから資格情報がレセコンに載るまでを1枚にすると、登場人物は4つです。

flowchart LR
    subgraph clinic["医療機関内"]
        CR["顔認証付き<br/>カードリーダー"]
        TERM["資格確認端末"]
        REN["連携プログラム<br/>(日レセではonshi-tools)"]
        ORCA["ORCA/日レセ<br/>tbl_onshi_* に蓄積"]
        UKE["受付・患者登録業務"]
        CR --> TERM
        TERM <-->|"共有フォルダ<br/>OQS〜.xml"| REN
        REN -->|"オン資関連API<br/>(登録系)"| ORCA
        ORCA --> UKE
    end
    TERM <-->|"IP-VPN /<br/>IPsec+IKE"| OQS["オンライン資格確認等システム<br/>(支払基金・国保中央会)"]

1. 顔認証付きカードリーダーがマイナンバーカードを読み、本人確認(顔認証または暗証番号)を行う。
2. 資格確認端末が、オンライン資格確認等システムのネットワーク(回線事業者のIP-VPN、またはインターネット経由のIPsec+IKE接続)を通じてオンライン資格確認等システム(社会保険診療報酬支払基金・国民健康保険中央会が運営)へ照会し、資格情報をXMLで受け取る。
3. 端末とレセコンの間はファイル連携が基本。結果XMLは共有フォルダに置かれ、連携プログラムがレセコンへ取り込む。日レセの場合、この役割を担う公式プログラムがonshi-toolsです。
4. 取り込まれた結果はORCA内のオン資専用テーブル群(tbl_onshi_*)に一旦蓄積され、受付・患者登録業務がそこから患者情報・保険情報へ反映する。

ポイントは、資格確認の結果が患者マスタに直接書き込まれるのではなく、専用テーブルにいったん溜まることです。「照会の記録」と「患者マスタへの反映」が分離されているこの二段構えが、ORCAのオン資連携を読み解く鍵になります(第6章・第8章)。

2. 制度の最短理解 ── オンライン資格確認とは何か

システムの話に入る前に、制度側を最短で整理します。

• 何をする仕組みか: マイナンバーカード(マイナ保険証)または保険証の記号番号をキーに、患者の保険資格をオンラインで即時確認する仕組み。保険者をまたいだ資格の異動(転職・転居など)が照会時点で反映されるため、資格過誤によるレセプト返戻を減らせるというのが請求業務側から見た最大の意義です。
• いつから: 2021年10月に本格運用が始まり、2023年4月から保険医療機関・薬局にシステム導入が原則義務化されました。2024年12月には健康保険証の新規発行が終了し、マイナ保険証を基本とする体制に移行しています。
• 資格以外に何が来るか: 患者がカードリーダーで同意すると、薬剤情報・特定健診情報・診療情報を医療機関側から閲覧できます。さらに医療扶助(生活保護)の資格確認や、自治体の医療費助成情報の連携(PMH: Public Medical Hub)へと対象が広がっています。

「資格確認」という名前ですが、実態は資格を入口に診療情報まで流れる医療情報連携の幹線になりつつある、と捉えるのが現在地です。この「対象の広がり」がレセコンのコードにどう現れているかは、第7章で年表として見ます。

3. 端末とレセコンの間 ── OQSファイル連携という接点

医療機関内の接点、つまり資格確認端末とレセコン(や電子カルテ)の間はどうつながっているのでしょうか。

国が公開しているシステムベンダ向け資料では、既存システムとオンライン資格確認等システムの連携方式として、連携アプリケーションによるファイル連携のほか、Webアプリケーション連携・顔認証連携・WebAPI連携といった方式が示されています。中心となるファイル連携は、おおまかに言えば「決められた名前のXMLファイルを決められたフォルダに置くと、答えのXMLファイルが返ってくる」という、古典的だが確実な仕組みです。

日レセもこの方式です。ORCA公式の「日レセオンライン資格確認」ページには、資格確認端末との間で授受されるファイルとして

• 要求: OQSsiquc01req_Oxxxxxxxxxxxx.xml
• 結果: OQSsiquc01res_Oxxxxxxxxxxxx.xml

という命名が示されており、共有フォルダを介してこれらを受け渡します。このファイル授受と日レセへの取り込みを担うのが公式提供のonshi-toolsで、Ubuntu版とWindows版が提供されています(取り込みサービスを監視するツールや、環境チェックツールも併せて公開されています)。

この「OQS」の語彙は、ORCAの公開ソースにも顔を出します。たとえば連携プログラム向けに照会依頼データを組み立てて返すAPI(第4章で見るonlinequa1)のレスポンス定義record/xml_onlinequares1.dbには、InsurerNumber(保険者番号)、InsuredCardSymbol(被保険者証記号)、QualificationConfirmationDate(資格確認日)、LimitApplicationCertificateRelatedConsFlg(限度額適用認定証関連の同意フラグ)といった項目が並びます。オンライン資格確認等システム側のXML項目名が、そのままレセコンのAPIまで貫通しているわけです。連携システムを作る側にとっては、国の仕様書とORCAのソースを同じ語彙で突き合わせられるという意味で、ありがたい設計です。

4. ORCA側の受け口 ── オン資関連API 20本をソースから数える

では、ORCA側の受け口を数えます。前回と同じ方法で、5.2系ソースのLD定義(lddef/*.ld)からbindapi宣言を拾うと、オン資関連のエンドポイントは3つのLDファイルに分かれて計20本あります。機能名はいずれも、担当COBOLプログラムのヘッダに書かれた「コンポーネント名」をそのまま転記したものです。

(新規作成年月は各プログラムヘッダの作成日付欄から。onlinequa1の括弧書きは実装内容からの補足です)

この一覧は、役割で3グループに分かれます。

1. 登録系(端末側→日レセ): onlinequa2(顔認証)・onlinequa3(保険証)をはじめ、薬剤・特定健診・診療情報・OCR画像・医療扶助・医療費助成の各「登録、更新処理」。資格確認端末側から届いた結果を日レセに流し込む受け口です。
2. 依頼組み立て系(連携プログラム→日レセ): onlinequa1は名前から「結果の照会API」に見えますが、実装を読むと違います。uuid(必須)でtbl_onshi_kakuの最新レコードを読み、そこから資格確認端末へ投げる照会依頼(OQS要求)の中身──資格確認に使う保険者番号・記号番号・同意フラグ、薬剤情報・特定健診情報の要求ファイル名(YZKsiquc01req_～.xml、TKKsiquc01req_～.xml。「～」は患者番号の末尾をXで埋めて20桁に固定した文字列)──を組み立てて返します。PushAPIの照会指示を受けた連携プログラムが「何を端末に聞けばよいか」を取りに来るためのAPIであり、蓄積結果を検索して返すAPIではありません。
3. 取得系(電子カルテ等→日レセ): /api01rv2/配下の3本は、蓄積された薬剤・特定健診・診療情報を連携システムが取得するためのAPIです。読み取り系APIが集まるapi01rv2に置かれている点も、前回見た日レセAPIの配置ルールどおりです。

さらにソースにはrecord/push_onlinequa.dbという定義もあり、オン資まわりのPushAPIイベント(Bulk_Qualification・patient_qualification)が用意されていることが分かります。発行箇所を読むと、照会業務の画面、受付・患者登録から呼ばれる資格確認サブ(ORCSONSHI001.CBL)、予約患者一括照会の画面(ORCGY06.CBL)、バッチ(ORCBONSHIPUSH.CBL)がそれぞれ照会指示のイベントを発行しています。つまりこのイベントは、日レセ側から連携プログラムへ「資格確認をしに行け」と指示を飛ばすためのチャネルが中心です。ただし中身は発行元ごとに違います。クラスにはRreq(照会依頼)のほか確認要否フラグの値(Yes)がそのまま入るケースがあり、uuidの意味も、個別イベントではtbl_onshi_kakuのレコードuuid、予約患者一括照会ではジョブ管理のuuid、バッチの一括指示ではuuidなし、と一定しません。受信側はイベント名・クラス・uuidの意味に応じて、onlinequa1(個別の依頼組み立て)・onlinequaapp1(予約患者一括)・onlinerefall1(照会番号一括登録)を呼び分ける必要があります。record/xml_onlinequareq1.dbの冒頭コメントには、Push通知を受けた受信プログラム(onshi_receiver)がonlinequa1で要求データを取得する流れが記されており、個別イベントに限ればPush(照会指示)→onlinequa1(依頼の組み立て)→端末への要求ファイル→onlinequa2/onlinequa3(結果の登録)という一巡が読み取れます。逆に、顔認証・保険証の結果登録API(onlinequa2/onlinequa3)はこのイベントを発行しません。「結果が登録された瞬間の通知」をPushAPIに期待して受付画面を作ると、通知が来ないまま待ち続けることになるので注意してください(第9章)。

5. データの行き先 ── tbl_onshi_* 13テーブル

登録系APIが受け取ったデータはどこへ行くのか。DBテーブルの一覧(lddef/orcadb.inc)からonshiを含むテーブルを抜くと13本あります。名前を見るだけで、オン資で流れてくる情報の種類がそのまま写像されていることが分かります。

第1章で述べた二段構えが、ここではっきり見えます。オン資由来のデータは患者マスタ(tbl_ptinf)や保険テーブルに直接書かれるのではなく、まずtbl_onshi_*という「オン資の言葉のままのテーブル」に着地します。国の制度側の語彙(資格・薬剤・特定健診・診療情報…)とレセコン内部の語彙(患者・保険・公費…)の間に緩衝地帯を設けた設計であり、制度側の拡張(テーブルが13本まで増えたこと自体がその証拠です)を、レセコン本体のスキーマを壊さずに受け止めてきたことが読み取れます。

6. tbl_onshi_kakuを読む ── 1回の資格確認が何を残すか

中心テーブルtbl_onshi_kaku(定義はrecord/tbl_onshi_kaku.db)を読むと、1回の資格確認が何を記録するかが具体的に分かります。主要な項目群を抜粋します。

• UUIDの束: TBL_UUID(このレコード自身)のほか、AITE_UUID・OYA_UUID・KOUHI_UUID(公費)・FUJYO_UUID(医療扶助)・PMH_UUID(医療費助成)と、関連レコードを指すuuidが並びます。資格確認・公費確認・扶助確認・助成情報が別レコードとして登録され、uuidの連鎖でひとつの受付イベントに束ねられる構造です。第4章の依頼組み立てAPI(onlinequa1)がuuid指定を必須にしているのはこのためです。
• 照会に使った検索条件(SHO_*): 照会時に指定した保険者番号・記号・番号・枝番・生年月日など。定義の由来はリクエスト側の「資格確認照会用情報(QualificationConfirmSearchInfo)」で、「何を条件に問い合わせたか」の記録です(マイナンバーカードの券面に保険者番号や記号番号は載っていないので、「券面の写し」ではありません)。
• 返ってきた資格情報(RES_*): 保険者番号・記号・番号・枝番・本人家族区分・被保険者氏名など。「オン資システムが何と答えたか」の記録です。照会条件(SHO)と結果(RES)を別項目で持つので、手元で把握していた記号番号と最新の資格とのズレ(転職・転居などによる資格変更)をレコード上で追えます。
• 結果と状態: 処理結果(RESULT_*)、エラーコード/メッセージ(ERR_*)、資格の有効性(SIKAKU_YUKO)、被保険者証区分(CARD_CLASS──定義の由来はInsuredCardClassificationで、返ってきた資格レコードの区分。物理カードの種類ではありません)、確認日時、患者番号(PTID)への紐付け、複数該当フラグ(FUKUSU_GAITO)など。
• 同意まわり: 同意フラグは1個ではなく、情報種別ごとに分かれて並びます。薬剤(YAKUZAI_DOUIFLG)・特定健診(KENSHIN_DOUIFLG)・診療情報(SHINRYO_DOUIFLG)のほか、限度額適用認定証(GENDO_DOUIFLG)・特定疾病療養受療証(SIKKAN_DOUIFLG)、さらに手術・傷病名・感染症・アレルギー・検査・処方といった単位まで細分化されています。第2章で触れた「同意に基づく情報閲覧」が、何への同意かを種別ごとに区別する形でテーブル項目として実装されているわけです。

定義ファイルのコメントには項目追加の時期も残っており、保険証OCRファイル名の項目には2022年7月、PMH_UUIDには2025年11月の注記があります。テーブル定義そのものが、次章で見る制度対応史の一部になっています。

7. 修正履歴は制度の年表である ── 2020〜2026

前々回で「COBOLヘッダの修正履歴は制度改定の年表になっている」と書きました。オン資関連のプログラム群は、その最も鮮やかな実例です。第4章の表の作成日付と修正履歴を制度側の動きと並べます。

前々回は「レセコンの本質的な難しさは制度追従を何十年も続けること」と書きましたが、オン資はその現在進行形です。2020年の新設から2026年まで、ほぼ毎年APIかテーブルが増えている──この事実は、オン資連携を「一度作って終わり」のインテグレーションと見なしてはいけない、という実務上の警告でもあります(第9章)。

なお、公開ソースを毎月diffしていれば、この種の拡張は公式アナウンスの前後にlddefとrecordの差分として検出できます。前回提案した月次スナップショットのdiff監視が、オン資領域では特に効くわけです。

8. 患者登録への反映 ── 結果は「そのまま」保険情報にならない

tbl_onshi_kakuに溜まった結果は、最後にどう患者マスタへ反映されるのでしょうか。

資格確認結果テーブルを参照するプログラムを数えると、最も多いのは患者登録業務(cobol/orca12/)の16本で、受付業務(orca11)や照会業務からも参照されています。患者登録の中心プログラムORCGP02.CBLの節コメントを拾うだけでも、処理の流れが見えます。

* オンライン資格確認UID検索処理
* オンライン資格確認データ 患者新規処理
* オンライン資格確認情報 基本情報処理
* オンライン資格確認情報 住所更新処理
* オンライン資格確認情報 保険情報処理
* オンライン資格確認情報 限度額など公費追加処理
* オンライン資格確認情報 公費開始日チェック処理

つまり日レセは、資格確認結果を機械的に上書きするのではなく、患者登録業務の文脈で「新規患者の作成」「氏名・住所の更新」「保険情報の突合・更新」「限度額認定や公費の追加」「開始日の妥当性チェック」といった個別の判断に分解して反映しています。オン資の結果は判断材料であって、最終的な患者・保険マスタの正はあくまで患者登録業務が握る──第1章の二段構えは、この責任分界のための設計だと解釈できます。

電子カルテや受付システムを作る側にとっての含意は明確です。資格確認結果を自システム側で患者マスタに直接反映するような近道を作ると、この突合ロジックを素通りすることになります。反映はORCAの業務(またはそれに準ずるAPI)を通すのが筋です。

9. 連携システムを作る側の実務ポイント

受付システム・電子カルテ・予約システムなどからオン資まわりに関わるときの要点をまとめます。

1. 接点は2か所ある。 資格確認端末との接点(OQSファイル連携)と、レセコンとの接点(日レセAPI)は別物です。日レセ構成ではファイル連携と取り込みをonshi-toolsが担うので、連携システムが自分でOQSファイルを扱う必要があるのか、それとも日レセに取り込まれた後のデータ(薬剤・特定健診・診療情報は取得系API、患者・保険への反映結果は通常の患者情報系API)で足りるのかを最初に切り分けてください。多くのケースでは後者で足ります。
2. uuidの連鎖を設計に織り込む。 資格確認・公費確認・医療扶助・医療費助成は別レコードとしてuuidで連鎖します(第6章)。「1回の受付」を復元するキー設計を、最初にソースのrecord/定義で確認しておくと後で効きます。
3. PushAPIイベントの「意味」をソースで確認してから使う。 push_onlinequaイベントは存在しますが、発行箇所を読む限り主用途は照会依頼(Rreq)の指示であり、結果登録API(onlinequa2/onlinequa3)は発行しません。onlinequa1も結果を返すAPIではなく依頼の組み立てAPIです(第4章)。受付画面の「資格確認済み」表示のような連動を作るなら、結果到着の通知が日レセから来る前提にはできません。結果の到着を最初に知るのは結果を登録する側(連携プログラム)なので、連動が必要なら取り込み経路と同じ場所(登録処理の完了時点)で自システムへ通知を出すか、日レセの受付・患者登録業務での反映を前提に画面を設計してください。
4. 同意の状態を種別ごとに尊重する。 薬剤・特定健診・診療情報は患者の同意に基づいて流れてくる情報であり、tbl_onshi_kakuにはYAKUZAI_DOUIFLG・KENSHIN_DOUIFLG・SHINRYO_DOUIFLGなど情報種別ごとの同意フラグが用意されています。取得系APIを叩けば返ってくるからといって、該当種別の同意状態を確認せずに使う設計にしないことが必要です。
5. 「毎年増える」前提で保守を設計する。 第7章のとおり、オン資関連はAPI・テーブルとも毎年のように拡張されています。月次公開ソースのlddef/recordのdiff監視を運用に組み込み、制度対応のリリースノートとして読む習慣をつけることをおすすめします。
6. 検証は公式の道具立てから。 ORCA公式は連携プログラムのほか、検証用のパターンファイルや環境チェックツール、医療扶助・訪問診療・オンライン診療向けの一括取得ツールも公開しています。自前でテストデータを創作する前に、公式の検証手段を確認してください。

10. まとめ

• マイナ保険証の受付は、カードリーダー→資格確認端末→(ファイル連携)→連携プログラム→レセコンというリレーで処理される。端末とレセコンの間はOQS命名のXMLファイル授受が基本で、日レセでは公式のonshi-toolsがその橋渡しを担う。
• ORCA側の受け口はオン資関連API 20本(登録系・依頼組み立て系・取得系)。資格確認結果は患者マスタに直接書かれず、tbl_onshi_* 13テーブルにいったん蓄積され、患者登録業務が突合・更新の判断を握る二段構えになっている。
• tbl_onshi_kakuは、照会に使った検索条件(SHO_*)と返ってきた資格情報(RES_*)を別々に持ち、照会条件と最新資格のズレをレコード上で追える。関連レコードはuuidの連鎖で束ねられる。
• オン資関連のCOBOL修正履歴は、2020年の新設から顔認証・OCR・診療情報・医療扶助・PMH・オンライン診療まで、制度拡張の年表そのもの。オン資連携は「作って終わり」ではなく、毎年の拡張に追従する保守を前提に設計すべき領域である。
• 例によって、これらはすべて公開ソースから一次情報として確認できる。国の仕様書の語彙(OQSのXML項目名)がレセコンのAPIまで貫通しているため、制度資料とソースを同じ言葉で突き合わせられる。

シリーズ次回は、レセプトの点検・査定のロジックを予定しています。医療機関内のデータチェック(ORCAのorca41業務)と審査支払機関側のコンピュータチェックがそれぞれ何を見ているのかを、同じくソースと公開資料から分解します。

11. 参考資料

• オンライン資格確認について(医療機関・施術所等、システムベンダ向け) - 厚生労働省
• 医療機関等向け総合ポータルサイト(連携アプリケーション等の技術資料)
• 日レセオンライン資格確認 - 日医標準レセプトソフト - ORCA Project(onshi-tools・OQSファイル連携・検証用資料)
• オンライン資格確認一括取得ツール - 日医標準レセプトソフト - ORCA Project
• 日医標準レセプトソフトのオンライン資格確認への対応について - 日本医師会ORCA管理機構
• 日レセ本体 5.2系ソースコード(2026年7月公開スナップショット) lddef/orca14.ld / lddef/orca71.ld / lddef/api01rv2.ld / cobol/orca14/ORAPION*.CBL / cobol/orca71/ORAPION*.CBL / record/tbl_onshi_*.db / record/xml_onlinequares1.db / record/push_onlinequa.db / cobol/orca12/ORCGP02.CBL ほか ── 本文中のAPI一覧・テーブル項目・修正履歴の記述はすべてこのスナップショットに基づく

関連する記事

同じタグを共有する最新の記事です。さらに近い話題で知識を深められます。

関連トピック

このテーマと近いトピックページです。記事を起点に、関連するサービスや他の記事へ進めます。

このテーマがつながるサービス

この記事は次のサービスページにつながります。近い入口からご覧ください。

よくある質問

この記事のテーマについて、相談時によくある質問をまとめています。

マイナ保険証で受付すると、保険資格の情報はどうやってレセコンに入りますか？

顔認証付きカードリーダーで本人確認が済むと、資格確認端末が支払基金・国保中央会のオンライン資格確認等システムへ照会し、資格情報をXMLファイルとして受け取ります。レセコンとの間は共有フォルダを介したファイル連携が基本で、ORCA(日レセ)の場合は公式提供の連携プログラム(onshi-tools)が結果ファイルを取り込みます。取り込まれた結果は日レセ内のオン資関連テーブル(tbl_onshi_kakuなど)に蓄積され、受付・患者登録業務から患者情報・保険情報へ反映されます。

オンライン資格確認で流れてくるのは保険資格の情報だけですか？

資格情報だけではありません。患者の同意に基づいて、薬剤情報・特定健診情報・診療情報も医療機関側から閲覧できます。ORCAのソースにも、資格確認結果とは別に薬剤情報・特定健診情報・診療情報(医科・歯科)それぞれの登録APIと専用テーブルが用意されています。さらに医療扶助(生活保護)の資格確認や、医療費助成情報(PMH)の連携など、対象は年々広がっています。

ORCA(日レセ)のオンライン資格確認関連APIはいくつありますか？

公開されている5.2系ソース(2026年7月スナップショット)のLD定義を数えると、オンライン資格確認関連のエンドポイントは20本あります。内訳は、資格確認結果や薬剤・特定健診・診療情報を日レセへ登録する登録系、連携プログラムが資格確認端末へ投げる照会依頼データを組み立てて返す依頼系、電子カルテなどが蓄積データを取得する取得系です。2020年11月に最初の3本が作られ、以後、制度の拡張のたびにAPIが増設されてきました。

オンライン資格確認まわりの連携システムを作るとき、何に注意すべきですか？

まず、資格確認端末とレセコンの間はXMLファイルの授受(連携アプリケーション方式)が基本という前提を押さえることです。その上で、ORCA連携ではuuidで関連レコードをたどる設計になっていること、登録系APIと取得系APIの役割の違い、薬剤・特定健診・診療情報の閲覧には患者の同意状態が関わることに注意が必要です。また制度対応でAPIやテーブルが毎年のように拡張されるため、月次で公開されるソースのdiff監視を運用に組み込むことをおすすめします。

著者プロフィール

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

小村 豪

合同会社小村ソフト 代表

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