刷My Number保險證會發生什麼事 ── 從ORCA原始碼解讀線上資格確認與收費電腦的串接

在診所掛號櫃檯把My Number保險證往讀卡機上一刷，幾秒鐘內本人身分驗證與保險資格確認就完成了。在這數秒的背後，究竟有哪些系統依照怎樣的順序在運作──尤其是，資格資訊究竟是如何送達最終負責請款的收費電腦，能說清楚的工程師恐怕意外地不多。

前前一篇介紹了ORCA(日醫標準レセプト軟體)就是收費電腦，前一篇則說明了如何從原始碼掌握日レセAPI的整體樣貌。這次作為應用篇，從收費電腦的角度解剖線上資格確認(通稱線上資確)。

• 從刷My Number保險證，到資格資訊登記進收費電腦為止的整體流程
• 連接資格確認端末與收費電腦的「檔案串接」，其內容為何
• ORCA一側的接口 ── 線上資確相關API 20支與tbl_onshi_*資料表群
• 刻在COBOL修改履歴中的、從2020年到2026年的制度因應年表

制度層面的記述基於厚生勞動省・ORCA官方公開的資料，原始碼方面的記述則基於實際閱讀官方公開的日レセ本體5.2系原始碼(2026年7月1日公開快照)後確認的結果。

本文的前提

目標讀者是掛號系統・電子病歷・預約系統等開發與收費電腦串接之系統的工程師。不需要能讀懂COBOL(引用之處會隨時加以說明)。也不預設醫療事務方面的實務經驗。

本文是系列第3篇，前兩篇中說明過的用語會直接沿用。為了讓本文也能獨立閱讀，這裡先整理一份最低限度的詞彙表。

目錄

1. 先講結論 ── 資格確認是「4個登場角色」的接力
2. 制度速覽 ── 什麼是線上資格確認
3. 端末與收費電腦之間 ── OQS檔案串接這個接點
4. ORCA一側的接口 ── 從原始碼數出線上資確相關API 20支
5. 資料的去向 ── tbl_onshi_* 13張資料表
6. 解讀tbl_onshi_kaku ── 一次資格確認會留下什麼
7. 修改履歴即是制度年表 ── 2020〜2026
8. 反映到患者登記 ── 結果不會「原樣」變成保險資訊
9. 串接系統開發者的實務要點
10. 總結
11. 參考資料

1. 先講結論 ── 資格確認是「4個登場角色」的接力

把從刷My Number保險證到資格資訊載入收費電腦為止的過程畫成一張圖，登場角色共有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. 具備人臉辨識功能的讀卡機讀取My Number卡，進行本人身分驗證(人臉辨識或密碼)。
2. 資格確認端末透過線上資格確認等系統的網路(電信業者的IP-VPN，或經由網際網路的IPsec+IKE連線)向線上資格確認等系統(由社會保險診療報酬支付基金・國民健康保險中央會營運)查詢，並以XML形式接收資格資訊。
3. 端末與收費電腦之間基本上以檔案串接完成。結果XML會被放入共用資料夾，由串接程式匯入收費電腦。就日レセ而言，擔負這項角色的官方程式即是onshi-tools。
4. 匯入後的結果會先暫存在ORCA內的線上資確專用資料表群(tbl_onshi_*)中，再由掛號・患者登記業務據此反映到患者資訊・保險資訊上。

重點在於，資格確認的結果並非直接寫入患者主檔，而是先暫存在專用資料表中。「查詢記錄」與「反映至患者主檔」相互分離的這種兩段式結構，正是解讀ORCA線上資確串接的關鍵(第6章・第8章)。

2. 制度速覽 ── 什麼是線上資格確認

在進入系統層面的討論之前，先用最短的篇幅整理一下制度層面。

• 是做什麼的機制：以My Number卡(My Number保險證)或保險證的記號號碼為金鑰，線上即時確認患者保險資格的機制。由於跨保險人的資格異動(換工作・搬家等)會在查詢當下即被反映，從請款業務的角度來看，其最大意義在於能減少因資格錯誤導致的診療報酬明細書遭退件。
• 從何時開始：2021年10月正式啟動運作，2023年4月起原則上要求保險醫療機構・藥局導入該系統。2024年12月健康保險證停止新發行，轉為以My Number保險證為主的體制。
• 除資格外還會傳來什麼：只要患者在讀卡機上表示同意，醫療機構一方便可查閱藥劑資訊・特定健檢資訊・診療資訊。此外，醫療扶助(生活保護)的資格確認，以及地方政府醫療費用補助資訊的串接(PMH: Public Medical Hub)，涵蓋範圍也在不斷擴大。

雖名為「資格確認」，但實質上正逐漸成為以資格為入口、連診療資訊也一併流通的醫療資訊串接主幹線——這大概就是目前所處的位置。這種「涵蓋範圍的擴大」在收費電腦的程式碼中是如何體現的，將在第7章以年表的形式呈現。

3. 端末與收費電腦之間 ── OQS檔案串接這個接點

醫療機構內部的接點，也就是資格確認端末與收費電腦(或電子病歷)之間，究竟是如何連接的呢？

在國家(厚生勞動省)公開的系統廠商用資料中，作為既有系統與線上資格確認等系統的串接方式，除了透過串接應用程式進行的檔案串接之外，還列出了Web應用程式串接・人臉辨識串接・WebAPI串接等方式。作為核心的檔案串接，籠統地說就是「把指定名稱的XML檔案放進指定的資料夾，就會回傳作為答案的XML檔案」——一種古典但確實可靠的機制。

日レセ也採用這種方式。ORCA官方的「日レセ線上資格確認」頁面中，列出了與資格確認端末之間收發的檔案命名規則：

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

這些檔案透過共用資料夾進行收發。負責這項檔案收發以及匯入日レセ的，是官方提供的onshi-tools，分別提供Ubuntu版與Windows版(同時還公開了監控匯入服務的工具，以及環境檢查工具)。

開頭的OQS，是與線上資格確認等系統往來的檔案統一附帶的前綴(該縮寫的完整展開，公開資料中並未明示)。檔案名稱的結構為：前綴OQS + 表示請求種類的部分(如siquc01) + req(要求)或res(結果) + 醫療機構一方附加的識別碼。依同一套體系，藥劑資訊的請求檔案會帶有YZK前綴，特定健檢資訊則是TKK(第4章)。

「OQS」這個詞彙，也會出現在ORCA的公開原始碼中。舉例來說，為串接程式組裝並回傳查詢請求資料的API(第4章將看到的onlinequa1)的回應定義record/xml_onlinequares1.db中，就排列著InsurerNumber(保險者編號)、InsuredCardSymbol(被保險人證記號)、QualificationConfirmationDate(資格確認日)、LimitApplicationCertificateRelatedConsFlg(限度額適用認定證相關同意標記)等項目。同一份定義檔案中，還以註解形式寫著居家診療等的查閱同意撤銷請求檔案名稱為OQSsihvd01req_xxxxxxxxxxxx.xml(附有2024-11的批註)，OQS命名就這樣原樣出現在原始碼上。也就是說，線上資格確認等系統一側的XML項目名稱，原樣貫穿到了收費電腦的API之中。對開發串接系統的一方而言，能用同一套詞彙去比對國家的規格書與ORCA的原始碼，是一種令人感激的設計。

4. ORCA一側的接口 ── 從原始碼數出線上資確相關API 20支

那麼，我們來數一數ORCA一側的接口。用前一篇同樣的方法，從5.2系原始碼的LD定義(lddef/*.ld)中提取bindapi宣告，會發現線上資確相關的端點分散在3個LD檔案中，合計20支。功能名稱皆是照抄自負責該功能的COBOL程式標頭中所寫的「元件名稱」。

(新增建立的年月取自各程式標頭的建立日期欄，統一以YYYY/MM表示。只有onlinequa4標注為「2021年」，是因為其標頭的建立日期以21/xx/xx這種隱去月日的形式寫成。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 ── 一次資格確認會留下什麼

閱讀核心資料表tbl_onshi_kaku(定義為record/tbl_onshi_kaku.db)後，就能具體了解一次資格確認會記錄哪些內容。定義檔案不過是把項目名稱與型別排列在一起的文字，形式如下(全文共668行，這裡只摘錄後文說明中會用到的部分)。

tbl_onshi_kaku {
	HOSPNUM				number(2,0);
	TBL_UUID     			varchar(36);
	AITE_UUID     			varchar(36);
	OYA_UUID     			varchar(36);
	KOUHI_UUID     			varchar(36);
	FUJYO_UUID     			varchar(36);
#---> PMH用UUID(2025-11)
	PMH_UUID     			varchar(36);
#---> 批次同意識別(2024/12)
	PROCESS_CLASS			varchar(01);
	（中略）
#---> 影像檔案名稱(2022/7)
	HKNOCR_FILENAME  		varchar(100);
	（中略）
	SHO_HKNJANUM			varchar(8);
	SHO_KIGO     			varchar(80);
	SHO_NUM     			varchar(80);
	SHO_EDABAN    			varchar(2);
	SHO_BIRTHDAY    		varchar(8);
	（中略）
	RES_HKNJANUM			varchar(8);
	RES_KIGO     			varchar(80);
	RES_NUM     			varchar(80);
	RES_EDABAN    			varchar(2);
	RES_HONKZKKBN	    		varchar(1);
	RES_HIHKNJANAME    		varchar(100);
	（中略）
	KENSHIN_DOUIFLG  	  	varchar(1);
	KENSHIN_TIME  		  	varchar(14);
	KENSHIN_KIGENYMD   	  	varchar(14);
	YAKUZAI_DOUIFLG   	  	varchar(1);
	YAKUZAI_TIME  		  	varchar(14);
	YAKUZAI_KIGEN  		  	varchar(14);
#---> 診療同意資訊(2022/7)
	SHINRYO_DOUIFLG   	  	varchar(1);

只要留意項目名稱的前綴(SHO_/RES_/〜_DOUIFLG)，以及以#--->開頭、標注新增時期的註解，就能大致讀出這張資料表的結構與歷史。以下摘錄主要的項目群加以說明。

• UUID群：除了TBL_UUID(該記錄本身)之外，還並列著AITE_UUID・OYA_UUID・KOUHI_UUID(公費)・FUJYO_UUID(醫療扶助)・PMH_UUID(醫療費用補助)等指向相關記錄的uuid。資格確認・公費確認・扶助確認・補助資訊各自作為獨立記錄登記，是一種透過uuid串連把它們捆綁進同一次掛號事件的結構。第4章的請求組裝API(onlinequa1)之所以將uuid設為必填，原因正在於此。
• 查詢所用的檢索條件(SHO_*)：查詢時指定的保險者編號・記號・號碼・枝號・出生日期等。此定義源自請求一側的「資格確認查詢用資訊(QualificationConfirmSearchInfo)」，記錄的是「以什麼為條件進行了查詢」(由於My Number卡卡面上並未印有保險者編號或記號・號碼，因此這並非「卡面的複本」)。
• 返回的資格資訊(RES_*)：保險者編號・記號・號碼・枝號・本人家屬區分・被保險人姓名等。記錄的是「線上資確系統給出了怎樣的答覆」。由於查詢條件(SHO)與結果(RES)分別放在不同項目中，因此可以在記錄上追溯手上掌握的記號號碼與最新資格之間的落差(因換工作・搬家等導致的資格變更)。
• 結果與狀態：處理結果(RESULT_*)、錯誤碼/訊息(ERR_*)、資格的有效性(SIKAKU_YUKO)、被保險人證區分(CARD_CLASS──其定義源自InsuredCardClassification，是返回的資格記錄的區分，並非實體卡片的種類)、確認日期時間、與患者編號(PTID)的關聯、多重命中標記(FUKUSU_GAITO)等。
• 同意相關：同意標記並非只有一個，而是按資訊種別分別排列。除藥劑(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. 接點有兩處。 與資格確認端末的接點(OQS檔案串接)和與收費電腦的接點(日レセAPI)是兩回事。在日レセ的架構中，檔案串接與匯入由onshi-tools負責，因此請先釐清：串接系統是否需要自行處理OQS檔案，還是說匯入日レセ之後的資料(藥劑・特定健檢・診療資訊用取得類API，反映到患者・保險後的結果用一般的患者資訊類API)就已經夠用。多數情況下後者已經足夠。
2. 把uuid的串連關係納入設計。 資格確認・公費確認・醫療扶助・醫療費用補助各自作為獨立記錄，透過uuid相互串連(第6章)。事先在原始碼的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. 總結

• My Number保險證的掛號，是依讀卡機→資格確認端末→(檔案串接)→串接程式→收費電腦這一接力順序處理的。端末與收費電腦之間基本上靠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清單・資料表項目・修改履歴的記述，皆基於這份快照

相關文章

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

相關主題

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

與本主題相關的服務

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

常見問題

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

用My Number保險證掛號時，保險資格的資訊是怎麼進到收費電腦裡的？

具備人臉辨識功能的讀卡機完成本人身分驗證後，資格確認端末會向支付基金・國保中央會的線上資格確認等系統查詢，並以XML檔案形式接收資格資訊。它與收費電腦之間基本上是透過共用資料夾進行檔案串接；就ORCA(日レセ)而言，由官方提供的串接程式(onshi-tools)負責匯入結果檔案。匯入後的結果會先累積在日レセ內部的線上資格確認相關資料表(如tbl_onshi_kaku)中，再經由掛號・患者登記業務反映到患者資訊・保險資訊上。

透過線上資格確認流通過來的，只有保險資格的資訊嗎？

不只是資格資訊。在患者同意的前提下，醫療機構一方還可以查閱藥劑資訊・特定健檢資訊・診療資訊。ORCA的原始碼中，除了資格確認結果之外，也分別為藥劑資訊・特定健檢資訊・診療資訊(醫科・牙科)準備了各自的登記API與專用資料表。此外，醫療扶助(生活保護)的資格確認，以及醫療費用補助資訊(PMH)的串接等，涵蓋範圍正逐年擴大。

ORCA(日レセ)與線上資格確認相關的API有多少支？

統計已公開的5.2系原始碼(2026年7月快照)中的LD定義，可以數出線上資格確認相關的端點共有20支。構成上分為：把資格確認結果以及藥劑・特定健檢・診療資訊登記進日レセ的登記類、由串接程式組裝並回傳投向資格確認端末之查詢請求資料的請求組裝類，以及電子病歷等系統取得已累積資料的取得類。最初的3支誕生於2020年11月，此後每逢制度擴充，API數量便隨之增加。

建構線上資格確認周邊的串接系統時，該注意什麼？

首先要掌握一個前提：資格確認端末與收費電腦之間基本上是透過XML檔案的收發(串接應用程式方式)來完成。在此基礎上，還須留意ORCA串接是以uuid串連相關記錄的設計、登記類API與取得類API在角色上的差異，以及藥劑・特定健檢・診療資訊的查閱涉及患者的同意狀態。另外，由於制度因應會讓API與資料表幾乎每年都在擴充，建議把對每月公開原始碼進行diff監控納入日常維運。

作者檔案

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

Go Komura

小村軟體有限公司 代表

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