刷个人编号保险证（マイナ保険証）会发生什么 ── 从ORCA源代码解读在线资格确认与诊疗报酬结算系统（レセコン）的联动

在诊所前台把个人编号保险证（マイナ保険証）在读卡器上一刷，几秒钟内本人验证与保险资格确认就完成了。在这数秒背后，究竟有哪些系统按怎样的顺序在运作──尤其是，资格信息究竟是如何送达最终负责请款的诊疗报酬结算系统（レセコン）的，能说清楚的工程师恐怕并不多。

上上一篇介绍了ORCA（日本医师会标准诊疗报酬软件）就是一款诊疗报酬结算系统，上一篇则讲解了如何从源码把握日レセAPI的全貌。这次作为应用篇，从诊疗报酬结算系统一侧解剖在线资格确认（通称オン資）。

• 从刷个人编号保险证，到资格信息登记进诊疗报酬结算系统为止的整体流程
• 连接资格确认终端与诊疗报酬结算系统的“文件联动”究竟是什么
• ORCA一侧的接口 ── 在线资格确认相关API 20个与tbl_onshi_*表群
• 刻在COBOL修改记录中的、从2020年到2026年的制度应对年表

制度层面的描述基于厚生劳动省・ORCA官方公开资料，源码方面的描述则基于对官方公开的日レセ本体5.2系源码（2026年7月1日公开快照）的实际阅读确认结果。

本文的前提

目标读者是前台接诊系统・电子病历・预约系统等与诊疗报酬结算系统联动的系统开发者。不需要能读懂COBOL（引用之处会随时加以说明）。也不预设医疗事务方面的实务经验。

本文是系列的第3篇，前两篇中说明过的术语会直接沿用。为了让本文也能独立阅读，这里先整理一份最低限度的词汇表。

目录

1. 先说结论 ── 资格确认是“四位角色”的接力
2. 制度速览 ── 什么是在线资格确认
3. 终端与诊疗报酬结算系统之间 ── OQS文件联动这一接点
4. ORCA一侧的接口 ── 从源码数出在线资格确认相关API 20个
5. 数据的去向 ── tbl_onshi_* 13张表
6. 解读tbl_onshi_kaku ── 一次资格确认会留下什么
7. 修改记录即是制度年表 ── 2020～2026
8. 反映到患者登记 ── 结果不会“原样”变成保险信息
9. 联动系统开发者的实务要点
10. 总结
11. 参考资料

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. 制度速览 ── 什么是在线资格确认

在进入系统层面的讨论之前，先用最短的篇幅梳理一下制度层面。

• 是做什么的机制：以个人编号卡（マイナ保険証）或保险证的记号・号码为key，在线即时确认患者保险资格的机制。由于跨保险者的资格变动（跳槽・搬家等）会在查询当下即被反映，从请款业务的角度看，其最大意义在于能减少因资格错误导致的诊疗报酬明细单被退回。
• 从何时开始：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，是与在线资格确认等系统往来的文件统一附带的前缀（该缩写的完整展开在公开资料中并未明示）。文件名的结构为：前缀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。它们被放在读取类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）”，记录的是“以什么为条件进行了查询”（由于个人编号卡卡面上并未印有保险者编号或记号・号码，因此这并非“卡面的复印件”）。
• 返回的资格信息(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. 总结

• 个人编号保险证的接诊，是按读卡器→资格确认终端→（文件联动）→联动程序→诊疗报酬结算系统这一接力顺序处理的。终端与诊疗报酬结算系统之间基本靠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个。构成上分为：把资格确认结果以及药剂・特定健康体检・诊疗信息登记进日レセ的登记类、由联动程序组装并返回投向资格确认终端的查询请求数据的请求组装类，以及电子病历等系统获取已积累数据的获取类。最初的3个诞生于2020年11月，此后每逢制度扩展，API数量便随之增加。

在构建在线资格确认相关的联动系统时，需要注意什么？

首先要把握一个前提：资格确认终端与诊疗报酬结算系统之间基本通过XML文件的收发（联动应用程序方式）来完成。在此基础上，还需注意ORCA联动是以uuid串联相关记录的设计、登记类API与获取类API在角色上的差异，以及药剂・特定健康体检・诊疗信息的查阅涉及患者的同意状态。另外，由于制度应对会让API与表几乎每年都在扩展，建议把对每月公开源码进行diff监控纳入日常运维。

作者简介

本文作者的个人简介页面。

Go Komura

小村软件有限公司 代表

以 Windows 软件开发、技术咨询与故障排查为中心，擅长难以复现的故障调查，以及既有资产仍在运行的项目。