核定与退回究竟发生在哪里 ── 用ORCA源代码与公开资料拆解诊疗报酬明细单核查的逻辑

医疗机构窗口收入只占一小部分，收入的大半由每月一次的诊疗报酬明细单申报决定。正因如此，”被核定了”“收到退回了”这类说法在现场才格外沉重。但对参与系统开发的工程师而言，核定・退回究竟发生在哪里、遵循怎样的逻辑，却是一个出人意料地难以看清的主题。

系列第1篇讲解了诊疗报酬结算系统的作用，第2篇讲解了日レセAPI，第3篇讲解了在线资格确认。这次将聚焦诊疗报酬明细单业务的核心──核查・审查的逻辑，把诊疗报酬明细单所经过的一道道”关卡”依次排开进行拆解。

• 退回・核定・再审查这些用语的准确含义
• 医疗机构内部的核查 ── ORCA的数据检查业务与核查主数据的实现
• 提交前的结算电子数据核查
• 审查支付机构一侧的核查 ── 计算机检查・比对核查・纵览核查
• 诊疗报酬结算系统一侧与审查一侧，在结构上同为”规则表+引擎”这一点

制度层面的记述基于支付基金・医师会等公开资料；关于ORCA实现的记述，则基于对官方公开的日レセ本体5.2系源代码（2026年7月1日公开快照）的实际阅读确认结果。

术语最小集合 ── 只要掌握这些就能读懂

医疗行业的缩略语会不断出现，因此先把最低限度的术语固定下来。从这里开始，请按照以下含义继续阅读。

关系汇总成一张图，诊疗报酬明细单与金钱的流动如下所示。

flowchart LR
    PT["患者"] -->|"就诊・部分自付费用"| MED["医疗机构<br/>诊疗报酬结算系统制作诊疗报酬明细单"]
    MED -->|"诊疗报酬明细单-申报"| SSK["审查支付机构<br/>支付基金・国保联"]
    SSK -->|"已审查的申报"| HKN["保险人"]
    HKN -->|"支付"| SSK
    SSK -->|"支付"| MED
    SSK -.->|"退回・核定通知"| MED

本文要探讨的，正是图中中间部分的“诊疗报酬明细单从医疗机构送往审查支付机构的过程中，究竟在哪里、检查了什么”这一问题。

目标读者是参与医疗机构相关系统开发的工程师（诊疗报酬结算系统对接、电子病历、部门系统），以及院内的信息系统负责人。不预设医疗事务方面的实务经验。也不预设已读过本系列前几篇，不过若读过以下各篇，理解背景会更容易。

目录

1. 先说结论 ── 诊疗报酬明细单要经过”4道关卡”
2. 术语最简整理 ── 退回・核定・增减点・再审查
3. 关卡① 通过源代码解读ORCA的数据检查业务
4. 核查主数据这一规则表 ── tbl_chk系表的设计
5. 录入时核查与API ── 核查并非只在月末进行
6. 关卡② 结算电子数据核查 ── 申报数据的核查
7. 关卡③④ 审查支付机构的计算机检查与比对・纵览核查
8. 双方都是”规则表+引擎”结构 ── 工程师视角的全景图
9. 实务要点 ── 从系统侧提升核查精度能做的事
10. 总结
11. 参考资料

1. 先说结论 ── 诊疗报酬明细单要经过”4道关卡”

把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. 术语最简整理 ── 退回・核定・增减点・再审查

用最简练的方式整理一下制度层面的用语。

重要的是，退回意味着”重新来过”，核定意味着”减额已成定局”，二者在影响程度上并不相同。而比对核查・纵览核查所检测的，是仅凭一份诊疗报酬明细单单据无法发现的错误（跨月的次数限制、医科与调剂之间的不一致）。不过二者性质有所不同：与其他机构的诊疗报酬明细单进行比对（比对），在医疗机构内部原理上是无法替代完成的；而与自身医院过去月份的比较（相当于纵览），在自身医院数据的范围内是可以做到的。理解这条界线之后，”能在内部拦下的全部在内部拦下”就成为核查业务的目标。

3. 关卡① 通过源代码解读ORCA的数据检查业务

源代码的获取与本文的阅读方式

接下来要开始阅读源代码。这件事任何人都能在自己手边重现，因此先把路径写在前面。

• 获取方式: ORCA Project的技术信息页面公开了源代码。每月1日会以tar包（zip）形式公开上月1日时点的源代码，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以作业（shell 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中放置的示例数据是”Pontal”（解热镇痛药）与”胃溃疡”，核查主数据区分为”1 药剂与病名”。也就是说，连画面定义的示例数据中，都刻着下一章将会看到的”药剂与病名对应核查”这一代表性用例。

4. 核查主数据这一规则表 ── tbl_chk系表的设计

数据检查所拥有的”何为正确”这一知识，存放位置分为两处。

• 规则表（核查主数据）所拥有的: 适应病名・禁忌・联合算定等，医药品与诊疗行为之间的对应关系。这些并非硬编码在COBOL中，而是作为数据保存在一组表里。
• 程序代码所拥有的: 保险・记号编号・实际就诊天数的整合性之类，涉及制度基本结构的核查。这些直接实现在批处理程序群(ORCDTCHK*)中，修改履历中也排列着诸如”支号数据检查对应”“劳动保险编号数据检查对应”这类代码侧的补充修改。

也就是说，“只要完善核查主数据就能改变所有规则”这种理解是错误的。规则表所负责的只是前者的范畴，后者只能通过程序的改修才能改变。

基于这一前提，从表清单(lddef/orcadb.inc)中挑出相关表如下:

规则的结构可以通过record/tbl_chk.db与COPY句cobol/copy/CPCHK.INC（项目附有日语注释）来确认。只抽取本质部分，一行规则的形态如下。

核查区分(CHKKBN) + 诊疗代码(SRYCD) + 有效期间(YUKOSTYMD〜YUKOEDYMD)
  → 对应的代码集合(CDKBN + CD)、门诊/住院区分、处理区分

也就是说，这是一条声明式的规则：”诊疗代码X，在期间Y内，必须对应代码集合Z中的某一个（或者不能与之共存）“。有哪些种类的规则，都列举在核查主数据的报表输出画面(screen/X91.glade)中。

• 药剂与病名 / 病名与药剂（适应病名的对应）
• 诊疗行为与病名 / 病名与诊疗行为
• 药剂与联合用药禁忌
• 用药禁忌药剂与病名
• 诊疗行为的联合算定（同日内・同月内・同一结算内）
• 诊疗行为之间的算定遗漏
• 算定次数核查

“药剂与病名”和”病名与药剂”成对出现，这一点很有意思。方向一旦反过来，想要检测的对象也随之改变。

不过在实现上，这并非同一张表的反向查询。阅读报表程序(cobol/orca103/ORCHXLST.CBL)可以发现，正如上表所示，二者是用不同的表・不同的键分别管理的，需要注意的是：登记了单一方向的规则，并不意味着反方向也会自动生效。之所以带有有效期间，是为了让规则一侧能够追随每两年一次的诊疗报酬改定，以及药价的新增收录・删除，第1篇中看到的”追随制度变化正是诊疗报酬结算系统的本质”这一点，在规则表的设计中同样贯彻始终。

另外，并非所有规则都能归入上述这一种形状。tbl_chksnd・tbl_chk005具有保存病名字符串(BYOMEI)以及疑似病名处理的形状，tbl_chktrd则具有保存同日・同月区分(DAYMONTHKBN)的形状，规则表本身会根据核查种类被规范化为不同的形状。虽然统称为”规则表”，却并非单一的模式（schema）──这一点是阅读实现时需要注意的地方。

5. 录入时核查与API ── 核查并非只在月末进行

数据检查是按月执行的批处理核查，但核查并不只有这一种。从源代码中还能确认到运行于更上游──日常录入时点──的机制。

• 联合用药禁忌核查API: /api01rv2/contraindicationcheckv2（负责程序为ORAPI021R4V2「联合用药禁忌药剂信息返回」，程序头部标注的创建日期为2016年）。这是一个传入患者与药剂后返回联合用药禁忌相关信息的API，可以实现”电子病历在处方录入时向日レセ发起查询”这样的联动。
• 数据检查API: 即前一章的datacheckv3。由于可以在不进行画面操作的情况下启动月度批处理，因此能够搭建出”每晚自动核查本月数据、次日早晨输出错误清单”这样的运维方式。

这里蕴含着一条设计上具有普遍性的教训：错误离发生源越近，修复成本就越低。在月末数据检查中发现的错误，需要把整整一个月份的内容一并修正；而如果能在处方录入的当下就发现联合用药禁忌，只需数秒就能处理完毕（需要说明的是，这个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. 关卡③④ 审查支付机构的计算机检查与比对・纵览核查

提交后的诊疗报酬明细单，将进入审查支付机构（职工保险归支付基金，国保・后期高龄者归国保联）的审查环节。这里重要的一点是，审查一侧的核查规则也有一部分是公开的。

在支付基金的”关于计算机检查的公开”页面上，提供了两类公开文件（均为CSV格式，正在逐步扩大范围）。

请注意名称。支付基金一侧同样使用了「核查主数据」这一说法。把基于告示・通知的规则与基于说明书的规则分开管理的结构，与ORCA把点数算定规则放在程序中、把药品适应症放在核查主数据中的结构，恰好一一对应。

另一方面，也存在不予公开的核查。公开页面中明确写道，对于需要确认摘要栏记载事项的案例、需要医学判断的案例、涉及药品・诊疗行为适应症的案例等，将慎重考虑是否公开。此外支付基金也反复说明，计算机检查只是对存疑项目做出标记，并非机械式地进行核定，而是要经过职员的核查与审查委员会的判断这一定位。”计算机检查≠自动核定”这一点，也是系统开发一方的人员应当准确理解的地方。

接下来是第2章提到的比对核查・纵览核查。这两项自2012年起全面推行的核查，检查的不是单份诊疗报酬明细单，而是诊疗报酬明细单之间的关系。这里有必要把边界划分清楚。比对核查（将同一患者的医科诊疗报酬明细单与调剂诊疗报酬明细单相互比对），对方是调剂药房这一其他机构的诊疗报酬明细单，因此原理上无法由医疗机构内部的核查来替代。而纵览核查（将同一患者的本月与过去月份进行比较）所对应的内容，只要在自身医院的申报履历范围内，在院内也是可以做到的。在自身医院数据的范围内，严格管理有次数限制的算定项目、以及与院外处方对应的病名，是减少比对・纵览核查中被指出问题的现实对策。

8. 双方都是”规则表+引擎”结构 ── 工程师视角的全景图

把到目前为止的内容浓缩成一张图，诊疗报酬明细单核查的世界看起来是这样的。

两者结构同型，差异在于规则的覆盖程度与检查范围。从中可以为工程师提炼出3条结论。

1. 规则是数据、引擎是程序这一分离结构，是能够追随制度改定20多年以上的必要条件。如果规则被埋在代码里，每次改定都会变成一次全面改修。
2. 在与核查主数据联动的领域（适应病名・禁忌等）中，医疗机构一侧的核查精度，与其说取决于引擎有多聪明，不如说取决于规则表的充实程度（保险・实际就诊天数等由代码实现的核查，其检测能力则直接取决于程序本身的覆盖范围）。ORCA的核查主数据分为官方提供部分(tbl_chk_master)与用户登记部分(tbl_chk_user)两个系统，设计上允许自身医院自行补充规则。市面上销售的诊疗报酬明细单核查软件的价值，归根结底也在于其独有规则表的充实程度。
3. 如今审查一侧的部分规则已经公开，“该如何把审查一侧公开的规则纳入自身医院的核查中”成为一个新的实务课题。以公开CSV这种机器可读的形式提供，其中蕴含的意义，工程师是不应错过的。

9. 实务要点 ── 从系统侧提升核查精度能做的事

从医疗机构的系统负责人或联动供应商的立场出发，整理一下应当把握的要点。

1. 把核查的多段结构映射到运维中。 录入时（联合用药禁忌API等）→月度（数据检查）→提交前（结算电子数据核查）这3段各自的角色不同。如果目前的运维只是”月末跑一次数据检查”，那么上游的两段还有可以利用的余地。
2. 数据检查可以通过API实现自动化。 用datacheckv3可以搭建指定确认项目・对象患者的定期执行。做成”夜间批处理+早晨错误清单”的形式，就能把月末的核查负担分散到日常。
3. 把例外登记当作”规则调优”来对待。 放任误检不管，错误清单就会不再被人查看。有计划地维护例外(tbl_chkreigai)与自身医院规则(tbl_chk_user)，保持错误清单的信噪比，是核查业务的生命线。
4. 把退回・核定的结果纳回分析闭环。 汇总增减点联络书中的事由，把高频出现的模式反映到核查主数据的自身医院规则或录入时的运维中──这就是”培养规则表”，也是缩小与审查一侧认知差距的唯一方法。
5. 定期查看审查一侧公开的资料。 支付基金的计算机检查公开内容一直在更新。在审查一侧已经正式说明”要看什么”的时代，包括比对・纵览核查的解说在内，没有不去阅读的道理。

10. 总结

• 诊疗报酬明细单要经过①诊疗报酬结算系统的内容核查→②结算电子数据核查→③审查一侧的计算机检查（+比对・纵览核查）→④职员・审查委员会这一多段关卡。退回是被退回医疗机构，核定是扣减点数；与其他机构诊疗报酬明细单进行比对的比对核查，在医疗机构内部无法替代（与自身医院过去月份的比较，则在院内也能做到）。
• ORCA的数据检查是作为orca41业务实现的，适应病名・禁忌・联合算定等规则以数据形式保存在核查主数据中（保险・实际就诊天数等基本整合性核查则在代码一侧）。可以选择确认项目后执行，通过例外登记抑制误检，还能通过datacheckv3 API从外部驱动──公开源代码能确认到这个程度。
• 审查一侧同样把本部核查条件+核查主数据这一规则表以CSV形式公开，医疗机构一侧与审查一侧拥有同型的”规则表+引擎”结构。差异在于规则的覆盖程度与检查范围（唯有审查一侧才能纵观所有机构・所有月份）。
• 决定核查精度的不是引擎，而是规则表的充实程度与运维方式。例外登记・自身医院规则・核定结果的分析闭环・审查一侧公开规则的纳入，都是实务上的要点。

本系列后续计划涉及直接阅读ORCA数据库模式（schema）的”数据库篇”，以及自动追踪月度源代码公开的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文件的形式公开，并在逐步扩大公开范围。比对核查・纵览核查的机制也在官方网站上有说明。不过，需要确认摘要栏记载内容或需要医学判断的案例等，也存在不属于公开对象的核查。

作者简介

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

Go Komura

小村软件有限公司 代表

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