电子处方笺改变了结算系统的哪些方面 ── 从源代码解读ORCA的电子处方笺支持

电子处方笺(電子処方箋)自2023年1月起正式运行,常被称为继在线资格确认之后医疗DX的第二弹。那么,对结算系统(レセコン)而言,支持电子处方笺具体意味着要做什么呢——仅仅说”把处方笺这张单据电子化”是无法据此进行设计的。

在第1回中探讨了结算系统的职责,在第2回中探讨了日レセAPI,在第3回中探讨了在线资格确认,在第4回中探讨了诊疗报酬结算单据审核。本次的第5回,将从结算系统一侧解剖电子处方笺。

• 电子处方笺会给处方流程带来怎样的变化(制度层面的最短理解)
• ORCA(日レセ)对应的整体架构 ── 主体程序与配套程序之间的职责边界
• 管理处方笺ID・兑换号・重复处方的tbl_shoho_kanri表设计
• 发行形式的意愿如何从在线资格确认传达过来 ── 制度之间的衔接

关于制度层面的表述,依据的是厚生劳动省・ORCA官方公开的资料;关于源代码的表述,则是基于对官方公开的日レセ主体程序 5.2系源代码(2026年7月1日公开快照) 实际阅读确认后的结果(源代码的获取途径已汇总在第8章的5)中)。

本文的阅读方法

预设读者是为医疗机构开发系统(电子病历・处方支援・接诊・部门系统等)的厂商工程师,以及院内负责这些系统对接的信息系统负责人。本文不预设诊疗报酬或医疗业务方面的背景知识,但预设读者具备关系型数据库与API对接方面的一般知识。

本文可独立阅读的范围: 电子处方笺制度的框架(第2章)、ORCA的职责边界(第4章)、处方管理表的设计(第5章)、CSV对接与票据(第6章)、面向厂商的验证环境(第8章),即使未读过本系列的其他文章也可以直接阅读。

前提环境: 本文中关于表定义・源代码的表述,均基于日レセ 5.2系(WebORCA本地部署版,2026年7月1日公开的源代码快照)。日レセ的数据库为PostgreSQL,WebORCA本地部署版的安装过程中使用数据库用户orca・UTF-8编码(PostgreSQL的版本随操作系统而定,在有官方安装步骤的Ubuntu 22.04 LTS上为14系)。本文中出现的以tbl_开头的名称,均为该PostgreSQL上的表。

先读能更快理解的几回: 本文中作为前提引用的文章共有以下4篇。不需要从头全部读完,在正文出现引用处再回头查阅即可。

称谓与缩略语对照: 先将官方资料与正文中容易出现叫法波动的术语固定下来。

目录

1. 先说结论 ── 处方笺从”递交的东西”变为”前去领取的东西”
2. 制度的最短理解 ── 电子处方笺管理服务与兑换号
3. 前史 ── 处方笺自2001年起就背负着二维码
4. ORCA对应的整体架构 ── 主体程序与配套程序的职责边界
5. 解读tbl_shoho_kanri ── 一张处方笺所拥有的电子属性
6. 数据的出口 ── 电子处方笺CSV与票据
7. 与在线资格的衔接 ── 发行形式从资格确认送达
8. 面向厂商 ── 如何准备验证环境
9. 系统对接开发方的实务要点
10. 总结
11. 参考资料

1. 先说结论 ── 处方笺从”递交的东西”变为”前去领取的东西”

纸质处方笺过去是由医疗机构打印、患者带往药店的”手递手数据传递”。而在电子处方笺下,这一流程发生了逆转。

flowchart LR
    subgraph clinic["医疗机构"]
        DR["医生开具处方"]
        RC["结算系统/电子病历<br/>ORCA在此管理处方数据"]
        SIGN["电子处方笺对应程序<br/>+ 另需电子签名模块<br/>负责电子签名与发送"]
        DR --> RC --> SIGN
    end
    SIGN -->|"登记处方笺数据"| EPS["电子处方笺管理服务<br/>支付基金・国保中央会"]
    EPS -->|"兑换号,面向患者"| PT["患者<br/>My Number医保卡或兑换号"]
    PT --> PH["药店"]
    EPS -->|"获取处方笺数据"| PH
    PH -->|"登记调剂结果"| EPS2["汇总至管理服务<br/>成为重复用药等核查的基础"]

• 医疗机构将处方笺数据登记至电子处方笺管理服务(電子処方箋管理サービス)(与在线资格确认相同,由支付基金・国保中央会运营)。
• 患者不必再随身携带纸质处方笺,而是用My Number医保卡(マイナ保険証)在药店受理,或是告知兑换号(引換番号)(及被保险人证等信息)。
• 药店则主动前往管理服务获取处方笺数据,并登记调剂结果。

从结算系统的视角来看,本质有两点。第一,处方笺不再是院内自我完结的一张票据,而变成了登记到外部服务的结构化数据。第二,由于处方・调剂的实际记录汇总到了管理服务,跨医疗机构・药店的重复用药等核查成为可能。在第4回中曾写道”与其他机构数据的比对,原理上院内无法做到”,而电子处方笺可以定位为一套国家基础设施,让处方领域(不是在审核环节,而是在处方的当下)跨越了这道壁垒。

2. 制度的最短理解 ── 电子处方笺管理服务与兑换号

下面只整理制度层面的要点。

• 始于何时:2023年1月正式运行。这是以在线资格确认的网络与基础设施为前提的机制,支持机构正在逐步扩大。
• 处方笺的确定方式:每一张发行的电子处方笺都会被赋予一个处方笺ID。患者以My Number医保卡在药店受理时,可在读卡器上选择目标电子处方笺来确定(存在多张时会有选择步骤);不使用My Number医保卡时,则需将兑换号与被保险人证等信息告知药店来确定(仅凭兑换号无法确定)。
• 重复用药等核查:由于处方・调剂信息会积累到管理服务中,医师・药剂师可以在处方的时间点参考与近期处方・调剂数据比对后的核查结果。
• 重复处方笺:在2022年度诊疗报酬修订中引入,可在一定期间内重复使用的处方笺。电子处方笺与重复处方的重复利用管理也颇为契合,如后文所述,ORCA的表中同样内置了重复处方相关字段。

标识符如何在医院与药店之间往返

若按照从发行到调剂的时间顺序,追踪处方笺ID・兑换号・被保险人信息这三个标识符各自经过谁的手,就能最清楚地看出电子处方笺的结构。

sequenceDiagram
    participant MED as 医疗机构<br/>(ORCA+电处/签名模块)
    participant EPS as 电子处方笺<br/>管理服务
    participant PT as 患者
    participant PH as 药店
    Note over MED: 处方确定・电子签名
    MED->>EPS: 登记处方笺数据(含被保险人信息)
    EPS-->>MED: 发放处方笺ID+兑换号
    Note over MED: 记录到tbl_shoho_kanri<br/>在存根票据上打印兑换号
    MED-->>PT: 交付存根(兑换号)
    alt 以My Number医保卡受理
        PT->>PH: 出示My Number医保卡<br/>在读卡器上选择目标处方笺
        PH->>EPS: 以被保险人信息查询
    else 以兑换号受理
        PT->>PH: 告知兑换号+被保险人证等信息
        PH->>EPS: 以被保险人编号等+兑换号查询
    end
    EPS-->>PH: 返回处方笺数据(内部以处方笺ID管理)
    PH->>EPS: 登记调剂结果

从这张图中应当读取到两点。

第一,医院与药店之间不存在系统对接数据的直接传递。处方笺的正本数据始终经由管理服务流转。患者所携带的是”钥匙”——My Number医保卡或兑换号,虽然有时也会拿到处方内容的存根纸张随身携带,但存根终究只是参考信息,药店实际用于调剂的正本数据是从管理服务获取的。这样一来,医院与药店之间就不必构建点对点对接,取而代之的是双方与管理服务之间对接质量的高低将决定一切。

第二,三个标识符的角色分工十分明确。

在ORCA一侧,留存这一往返痕迹的正是后文将要介绍的处方管理表。发行时从管理服务返回的处方笺ID与兑换号会被原样存储(PRESCRIPTIONID・ACCESSCODE),用于存根票据的打印,以及取消・变更时的核对。

3. 前史 ── 处方笺自2001年起就背负着二维码

「处方笺的数据化」这件事本身,其实并不是什么新话题。ORCA的源代码中有一个名为cobol/common/ORCSQRCSV.CBL「处方笺 QR数据输出」的程序,创建日期为2001年9月。在纸质处方笺上打印二维码,由药店一侧的系统读取后导入调剂系统——这样的运作方式,早在20多年前就已经存在。

也就是说,电子处方笺带来的变化并非「数据化」本身,而是数据存放位置与获取途径的标准化。二维码是印在纸上的「仅此一张的数据」,而电子处方笺则登记在全国统一的管理服务中,任何人(在权限范围内)都可以凭处方笺ID获取。正是这一差异,使得重复用药核查这类跨机构功能成为可能。源代码中新旧两套机制并存,正是转型期结算系统的真实写照。

4. ORCA对应的整体架构 ── 主体程序与配套程序的职责边界

根据官方页面(「日医标准诊疗报酬结算软件 电子处方笺」)的说明,ORCA对电子处方笺的支持采取的是日レセ主体程序+电子处方笺对应程序(电子处方笺API)这一架构。阅读5.2系的公开源代码后可以发现,这条职责分界线在实现层面同样能得到印证。

有意思的是最后一行。作为电子处方笺技术亮点的电子签名相关内容,在日レセ主体程序的400万行代码中完全没有出现。主体程序专注于”始终作为处方数据的正本”这一职责,而把签名・通信这类变化迅速的领域切分给了独立程序——这与第3回中看到的在线资格对接(主体程序负责API与表,文件收发交给onshi-tools)是同一种分界模式。可以将其解读为一种把国家基础设施一侧的规格变更,从主体程序的发布周期中剥离出来的设计。

那么,被切分出去的一侧究竟包含哪些内容?官方页面所列出的配套程序群阵容如下。

各组件所支持的操作系统各不相同,电子处方笺模块与扩展电处助手仅支持Windows 11(x64),处方录入界面则支持Windows・Mac・Ubuntu(其中Ubuntu仅WebORCA本地部署版支持)。在规划院内终端时,请注意发行相关的模块是以Windows为前提的。而签名职责的划分尤为重要,官方页面明确写道:「要引入电子处方笺,须另行准备电子签名模块」。经过验证的电子签名模块(由I-O DATA机器、三菱电机IT Solutions提供),承担基于HPKI卡(HPKI=保健医疗福祉领域公钥基础设施,一种存有可证明医师等国家资格的电子证书的IC卡)的本地签名,以及远程签名(FIDO认证・HPKI卡认证・My Number卡认证)。也就是说,电子处方笺中变动最为剧烈的议题——「如何实现医师的电子签名」——既没有留在日レセ主体程序中,也没有留在电处模块中,而是被吸收进了专门的签名模块层。这正是主体程序源代码中不出现HPKI字样的答案所在。

若院内同时存在电子病历,发行的主体是哪一方

此前的图示都把医疗机构内部简化成了一条流程,但实际院内很多情况下是电子病历与结算系统并存的架构。在这种情况下,处方送达药店(管理服务)之前所经过的路径,大致可分为两种模式。

画成图后可以看到,两种模式的差异归结为一点:「签名・登记这个环节位于哪一侧」。

flowchart TB
    subgraph A["模式A - 以ORCA为发行主体"]
        direction LR
        EMRA["电子病历<br/>下达医嘱"] -->|"日レセAPI"| ORCAA["ORCA<br/>tbl_shoho_kanri"]
        ORCAA --> MODA["电处模块<br/>+ 电子签名模块"]
        MODA -->|"登记"| EPSA["电子处方笺<br/>管理服务"]
    end
    subgraph B["模式B - 以电子病历为发行主体"]
        direction LR
        EMRB["电子病历<br/>自身电处对应+签名"] -->|"登记"| EPSB["电子处方笺<br/>管理服务"]
        EMRB -->|"为请求而同步处方"| ORCAB["ORCA<br/>生成结算单据"]
    end

模式A的痕迹在源代码中留存得很清楚。第5章将会看到的处方管理表中,发行来源区分(HAKKOKBN)存在「API中途数据发送」这一取值(在COPY句CPSHOHO-KANRI.INC的注释中可以确认),从电子病历经由API送入的处方,与在ORCA画面上录入的处方会由同一张表管理。第2回中看到的「API即画面业务的API版本」这一设计理念,在电子处方笺的发行路径上同样得到了体现。

无论哪种模式,都不存在向药店「发送」的处理。药店一侧是由药店的结算系统・调剂系统从管理服务获取处方笺数据(关于药店系统内部的对接,厚生劳动省公开了结算系统与电子药历之间的对接数据资料)。医疗机构一侧的厂商在设计时首先需要确定的是,将发行・签名・取消的起点设在病历一侧还是ORCA一侧,并据此决定由哪一方持有相当于tbl_shoho_kanri的管理功能,以便处方笺ID・兑换号能够与请求数据进行核对。

5. 解读tbl_shoho_kanri ── 一张处方笺所拥有的电子属性

日レセ主体程序一侧的核心是处方管理表tbl_shoho_kanri。以下从其定义(record/tbl_shoho_kanri.db)与COPY句的日文注释中摘取主要字段。

tbl_shoho_kanri {
    TBL_UUID          varchar(36);  -- 识别uuid
    RENNUM            number(1);    -- 序号(主键为 HOSPNUM+TBL_UUID+RENNUM)
    SRYYMD / PTID / SRYKA / HKNCOMBI  -- 诊疗日期・患者・诊疗科・保险组合
    SHOHO_KEITAI      varchar(1);   -- 处方笺发行区分(电子/纸质)
    PRESCRIPTIONID    varchar(36);  -- 处方笺ID
    ACCESSCODE        varchar(16);  -- 兑换号
    REFILL_NUM        number(1);    -- 重复处方次数
    REFILL_ZAIKAISU   number(3);    -- 重复处方天数
    CANCEL_TIME / CANCEL_UNDO_TIME  -- 处方笺取消日期时间与取消UNDO日期时间
    CHANGE_TIME / CHANGE_UNDO_TIME  -- 变更日期时间与变更UNDO日期时间
};

光是这张表,就能透视出电子处方笺的实务全貌。

• 同时持有处方笺ID(36位空间)与兑换号(16位空间)这一对字段。 第2章中看到的两种领取方式(My Number医保卡/兑换号)所对应的密钥,原封不动地作为记录的属性列出(此外,现行运用中的兑换号为6位,16位只是列的容量。将位数写死为固定值来实现恐怕并不安全)。
• 取消与变更各自都有对应的UNDO日期时间。 由于电子处方笺是已登记到管理服务的数据,院内一旦取消处方,就必须同时取消登记,甚至还可能出现「取消该取消」(即恢复)的操作。纸质时代那种”撕掉重写”的做法,如今变成了状态迁移的管理。
• 重复处方从一开始就是一个属性。 重复处方次数与处方天数被纳入了处方管理的基本字段,以重复使用为前提的生命周期管理已被编织进设计之中。

另外,使用uuid进行标识的做法,与第3回中在线资格相关表(tbl_onshi_kaku)所用的是同一套惯用手法。不过主键并非uuid单独构成,而是医疗机构编号+uuid+序号(RENNUM)的复合键,设计上允许同一个uuid挂靠多行数据。在对接系统一侧处理与该表相当的数据时,请注意如果只把uuid当作行键,会导致多行数据被合并掉。

6. 数据的出口 ── 电子处方笺CSV与票据

在此先用一张图,把第5章的表与第7章的在线资格对接都纳入进来,展示数据在ORCA内部的流转方式。

flowchart LR
    ONS["在线资格确认<br/>接诊时"] -.->|"发行形式意愿<br/>SHO_SHOHO_KEITAI"| TBL
    NYURYOKU["处方录入<br/>画面/日レセAPI"] --> TBL["tbl_shoho_kanri<br/>处方笺ID・兑换号・<br/>重复处方・取消/变更"]
    TBL -->|"CSV输出<br/>ORCSEPRECSV"| MOD["电处模块<br/>组装并发送登记请求"]
    SIGNM["电子签名模块<br/>电子签名"] -.->|"签名"| MOD
    MOD -->|"登记"| EPS["电子处方笺<br/>管理服务"]
    EPS -.-> RET["处方笺ID・兑换号<br/>记录至tbl_shoho_kanri・<br/>打印到存根票据ORCHC02系"]

处方数据传递给配套程序的出口,正是ORCSEPRECSV.CBL(电子处方笺 CSV数据输出)。其文件头的修改历史,原原本本地记录了制度对应的过程。

• 2022年10月 新建 ── 先于2023年1月的正式运行而实现
• 2023年6月 用法主数据反映对应 ── 电子处方笺中用法(服用方法)也需要编码化处理,因此必须与用法主数据保持一致
• 2024年 重复处方次数对应(1月)・交付编号备注记载对应(3月)・原研药患者意愿对应(8月)・汉字姓名40字节化(12月) ── 长期收载药品的选定疗养(患者意愿的记录)等制度层面的动向,直接体现为字段的增加
• 2025年 虚拟代码警告对应(1月)・使用期限年月日对应(4月)・负担者编号/受给者编号位数对应(7月) ── 即便正式运行已过去两年半,每年仍以数次的节奏持续进行改造

正如这段历史所示,电子处方笺的CSV对接并非「做完一次就结束」,而是正在进行时,持续发生变化。在票据方面,处方笺样式的票据程序(ORCHC02系・ORCHCM19系)也并列出现了支持电子处方笺的版本。之所以即便实现了电子处方笺,票据也不会消失,是因为交给患者的存根(包含兑换号的通知)以及与纸质运作的并存仍在继续。「电子化=废除票据」的说法并不成立,票据得以保留,而正本数据的存放位置发生了改变,这才是转型期的真实情况,源代码的文件结构如实反映了这一点。

7. 与在线资格的衔接 ── 发行形式从资格确认送达

把电子处方笺放在院内流程中来看,第一个分支点就是「这位患者要以电子还是纸质方式领取处方笺」。这项信息从何而来?——答案是在线资格确认。

患者以My Number医保卡受理时,可以在读卡器上选择处方笺的领取方式(电子/纸质)。这一选择会与资格确认的结果一同送达结算系统。第3回中读到的在线资格的资格确认结果表tbl_onshi_kaku中,存在处方笺发行形式字段(SHO_SHOHO_KEITAI),根据定义注释,该字段是2022年7月新增的。在线资格的XML定义中也存在PrescriptionIssueSelect(处方笺发行形式)这一字段。早在电子处方笺正式运行(2023年1月)的半年之前,在线资格一侧的接口就已先行扩展——就连制度层层叠加的先后顺序,也能从源代码的日期中读取出来。

而在接诊环节确定下来的发行形式,到了处方环节,会以tbl_shoho_kanri.SHOHO_KEITAI的形式针对每一张处方笺予以确定。在线资格(接诊)→处方(诊疗)→管理服务(发行)这样跨制度的数据传递,在表设计的层面上是彼此衔接的。第3回中把在线资格确认称为「以资格为入口、信息在其中流动的主干线」这一判断,在电子处方笺上同样得到了印证。

8. 面向厂商 ── 如何准备验证环境

在电子处方笺的对接开发中,最先让人碰壁的往往不是代码本身,而是「规格书与测试环境的获取途径十分分散」这一点。下面按入口分类整理官方信息。

1) 规格书的获取 ── 「医疗机构等ONS」

面向系统厂商的一手规格,集中收录在支付基金提供的厂商专用信息网站「医疗机构等ONS」中(在线资格确认等系统外部接口规格书,以及电子处方笺管理服务记录条件规格也都在这里)。该网站与医疗机构使用的综合门户是不同的网站,以厂商身份完成使用登记是前提条件。此外,厚生劳动省的「电子处方笺(面向系统厂商)」页面上也公开了面向系统厂商的技术说明书(截稿时为2.04版)以及面向药店系统的对接资料。另外需要留意,JAHIS(一般社团法人保健医疗福祉信息系统工业会——由医疗信息系统厂商组成的行业团体,负责制定各类标准规格与实施指南)的「电子处方笺实施指南」(Ver.1.2,2021年)是早于现行电子处方笺管理服务的探讨性资料,现行规格的一手资料终究是ONS的规格书・技术说明书。这份指南在搜索中往往容易先被检索到,请多加注意。

2) 测试用证书・卡的获取

电子处方笺的发行必须要有医师・牙科医师的电子签名(HPKI),因此测试同样需要证书。获取窗口按用途分开。

• HPKI测试卡(用于签名・认证):窗口按职业种类划分。医师用通过日本医师会电子认证中心(JMACA——由日本医师会运营的HPKI认证机构,负责发放医师资格证=HPKI卡)的「致厂商各位」页面邮寄申请表来获取。牙科医师用・药剂师用则分别按各自认证机构(MEDIS=一般财团法人医疗信息系统开发中心、日本药剂师会认证机构)的指引办理。
• HPKI第二电子证书(无卡签名)的验证环境使用・测试用My Number卡:通过邮件向MEDIS的专用窗口申请。
• 需要注意的是,正式环境用的HPKI卡即便在平时,从申请到发放也需要2至3个月。而且截稿时JMACA的通知显示,由于IC卡短缺,物理卡(医师资格证)的发放已暂停,官方引导采用先行发放HPKI第二电子证书(无卡)的运作方式。在制定以实体卡为前提的计划之前,先确认最新的发放情况以及能否以无卡签名替代,会更为稳妥。

3) 对接验证与发布前检查

与管理服务之间的对接验证,需要按照ONS一方的指引来进行,但作为开发者更值得先读的,是厚生劳动省公开的「电子处方笺对应版软件发布相关自查清单(测试完成确认)」(截稿时为4.2版)。这份清单的设计初衷,是要求厂商确认清单上的测试均已完成后再发布,反过来说,这也意味着「应该测试什么」的官方清单从一开始就已经存在。以此为起点反推测试计划,是最快捷的方式。此外,作为不自行实现签名处理的一种选择,还存在电子处方笺签名通用模块,厚生劳动省页面上也刊载了提供导入支援服务的事业者一览表。

4) ORCA一侧的验证环境

如果要以「日レセ+配套程序」的架构进行验证,可以在验证用服务器上搭建WebORCA本地部署版,并按照官方的电处模块&扩展电处助手安装手册进行安装设置。正如第6章所述,电子处方笺与用法主数据是联动的,如果不先完成主数据更新,就无法真正验证输出数据。此外,标准用法代码是有使用期限的。截稿时的官方页面显示,自2026年8月1日起,部分标准用法代码将无法在电子处方笺中使用,如果过期代码的映射仍然残留,日レセ会输出虚拟代码。因此不能只更新主数据,还应把自身系统所使用的用法代码的重新映射确认也纳入验证项目(即便现在测试能通过,一旦跨过期限日,也可能变为输出虚拟代码)。与第3回中介绍的在线资格验证用样本文件同样,在自行编造测试数据之前先确认官方的验证手段才是铁律。

5) 自行阅读源代码

本文中关于实现的表述,全部是通过实际查阅公开源代码确认得来的。同样的事情任何人都可以做到。具体路径如下。

• 获取:源代码通过ORCA Project的技术信息页面公开。每月1日,会公开上月1日时点的源代码,以tar包(zip)形式发布,5.2系主体程序为https://ftp.orca.med.or.jp/pub/src/jma-receipt.r_5_2_branch.zip(由于无法直接列出目录,请通过技术信息页面的链接获取)。地方公费(jma-receipt-kk)与票据(jma-receipt-forms)则是单独的归档文件。
• 该看哪里:表定义在record/目录下(例如record/tbl_shoho_kanri.db),字段的日文注释在COBOL的COPY句中(cobol/copy/CPSHOHO-KANRI.INC),处理主体则在cobol/common/目录下(例如ORCSEPRECSV.CBL)。若想把握表的整体面貌,同一技术信息页面上的「日医标准诊疗报酬结算软件数据库表定义书」可作为索引使用。
• 阅读推进方式:用日文注释检索会受源代码文字编码的影响,因此先用英数字标识符追踪最为可靠。

# 处方管理表的定义,以及带有字段名+日文注释的COPY句
less record/tbl_shoho_kanri.db
less cobol/copy/CPSHOHO-KANRI.INC

# 找出所有涉及处方笺ID的程序
grep -rl "PRESCRIPTIONID" cobol/ | head

# COBOL程序开头的注释中含有修改历史(即制度对应的记录)
head -60 cobol/common/ORCSEPRECSV.CBL

• 追踪变更:保存每月发布的归档文件,与上一个月的版本做diff -r比对,就能比官方公告更早察觉到变化(见第9章的5)。

9. 系统对接开发方的实务要点

以下是从电子病历・处方支援・接诊系统等一侧参与电子处方笺相关开发时的要点。

1. 首先划定职责边界。 处方数据的管理由日レセ主体程序负责、签名与管理服务通信由电子处方笺对应程序负责,这是ORCA的标准架构。请先按功能逐一区分,自建的对接系统究竟应该与哪一侧对话,再进行设计。若判断要自行实现签名相关功能,就意味着连HPKI卡的运营也要一并承担下来。
2. 把处方笺ID与兑换号当作实体来处理。 如果仍然停留在「处方笺=打印件」的数据模型上,取消/变更/UNDO、重复处方这类状态管理就会变成事后补加的东西。tbl_shoho_kanri的字段构成,可以作为电子处方笺时代处方实体设计的优秀参考(不过它持有的只是重复处方的次数・天数,并不包含已使用次数・剩余次数这类状态。请以剩余次数属于调剂一侧生命周期数据、需要另行处理为前提来设计)。
3. 发行形式的信息从接诊环节流入,但仅限于以My Number医保卡受理的情形。 电子/纸质的意愿只有在以My Number医保卡受理时,才会包含在在线资格的资格确认结果中。对于使用资格确认书等、不使用My Number医保卡的患者,则需要由窗口或诊室的工作人员・医师另行确认意向,因此如果只依赖SHO_SHOHO_KEITAI,就会残留一条意向未经确认便直接到达处方环节的路径。请在设计中同时纳入将接诊时的信息贯穿至诊疗・处方的动线,以及在没有读卡器来源数值时的确认流程。
4. 要预设「纸质」本身也分为两种。 在所有患者・所有药店都完成电子化之前,纸质处方笺仍会继续存在,但在已引入电子处方笺的机构中,存在即便是纸质处方笺,也将处方・调剂信息登记至管理服务的运作方式(带兑换号的纸质处方笺),这类处方笺同样会成为重复用药等核查的对象。与其做「电子/纸质」的二元划分,不如以「电子/已登记至管理服务的纸质/沿用原有二维码运作的纸质」这三选一为前提来设计分支,更贴近现实。
5. 建立追踪制度扩展的机制。 从用法主数据对应到重复处方对应,电子处方笺周边的源代码每年都在更新。正如本系列反复建议的那样,对每月公开源代码中record/・cobol/目录进行diff监控,在这里同样能比官方公告更早察觉到变化。

10. 总结

• 电子处方笺是把处方笺从”由患者随身携带的纸张”,转变为“登记至管理服务、通过处方笺ID/兑换号获取的结构化数据”的机制。通过汇总处方・调剂信息,跨医疗机构・药店的重复用药等核查得以实现。
• ORCA的对应采取的是日レセ主体程序(数据管理・CSV输出・票据)+配套程序群(电子处方笺模块・扩展电处助手等)+需另行准备的电子签名模块(经过验证的厂商提供产品)这一架构。主体程序源代码中不出现电子签名字样,正是这一职责边界的证据。
• 主体程序一侧的核心是tbl_shoho_kanri,以处方笺为单位管理处方笺ID・兑换号・重复处方次数/天数・取消/变更及其UNDO日期时间。源代码中留存着与处方笺二维码输出(2001年~)并存的痕迹,映射出从「数据化」走向「存放位置标准化」这一变化的本质。
• 电子/纸质的发行形式,在以My Number医保卡受理时,会作为在线资格确认的结果在接诊时送达(在线资格一侧的接口,在源代码上是2022年7月先行新增的)。使用资格确认书等的患者,则需要在窗口・诊室另行确认意向。在线资格→电子处方笺这一制度层层叠加的过程,在表与XML定义的层面上是彼此衔接的。

本系列下一回,计划解读ORCA数据库整体架构的「数据库篇」,或是月次源代码diff监控的实际运作。

11. 参考资料

• 电子处方笺 - 厚生劳动省
• 日医标准诊疗报酬结算软件 电子处方笺 - ORCA Project(电子处方笺对应程序・对象票据)
• 关于日医标准诊疗报酬结算软件的电子处方笺对应 - ORCA Project
• 电子处方笺,面向系统厂商 - 厚生劳动省(技术说明书・记录条件规格・发布前自查清单)
• 致厂商各位,HPKI测试卡 - 日本医师会电子认证中心
• 处方笺打印API - ORCA Project
• 技术信息 - ORCA Project(源代码的月度公开・数据库表定义书)
• 双机运用的设置,日レセ5.2以降 - ORCA Project(WebORCA本地部署版的数据库为PostgreSQL)
• HPKI 保健医疗福祉领域公钥基础设施 电子认证局介绍 - MEDIS
• 日レセ主体程序 5.2系源代码(2026年7月公开快照) record/tbl_shoho_kanri.db / cobol/copy/CPSHOHO-KANRI.INC / cobol/common/ORCSEPRECSV.CBL / cobol/common/ORCSQRCSV.CBL / record/tbl_onshi_kaku.db 等 ── 本文中关于实现的表述均基于这一快照

相关文章

共享相同标签的最新文章。可以围绕相近的主题进一步加深理解。

相关主题

与本文相近的主题页面。以本文为起点，可以进一步了解相关服务和其他文章。

与本主题相关的服务

本文与以下服务页面相关联，欢迎从最接近的入口查看。

常见问题

汇总了咨询这一主题时常见的问题。

电子处方笺与纸质处方笺有什么区别？

与患者携带纸质处方笺前往药店不同,电子处方笺是将处方笺数据登记至电子处方笺管理服务(由支付基金・国保中央会运营),再由药店在线获取。患者可以用My Number医保卡受理,在读卡器上选择目标处方笺,或是把兑换号与被保险人证等信息告知药店以确定处方笺(处方笺ID是系统内部使用的标识符,并非患者需要处理的号码)。由于处方・调剂信息汇总到了管理服务一侧,能够进行跨医疗机构・药店的重复用药等核查,是最大的变化。

ORCA(日レセ)是如何支持电子处方笺的？

职责分成了两部分。日レセ主体程序拥有管理处方笺ID・兑换号・重复处方次数・取消/变更历史的表(tbl_shoho_kanri)、将处方内容输出为CSV的机制,以及支持电子处方笺的处方笺样式票据。另一方面,电子签名(通过HPKI卡进行的本地签名或远程签名)以及与电子处方笺管理服务的通信,则是电子处方笺模块・扩展电处助手等配套程序群,以及需另行准备的电子签名模块(存在经过验证的厂商提供产品)的职责。从公开的日レセ主体程序源代码中找不到电子签名处理这一点,也能读出这条职责边界。

兑换号是什么？

这是患者在不使用My Number医保卡、于药店领取电子处方笺时所使用的号码。药店会根据这个号码与被保险人证信息来确定处方笺,并从管理服务中获取。现行运用中的兑换号为6位数字,在ORCA(日レセ)的源代码中,作为处方管理表的ACCESSCODE(最大16位的空间)保存,并与处方笺ID配对管理。

在线资格确认与电子处方笺是什么关系？

两者的入口是相连的。患者以My Number医保卡受理时,可以在读卡器上选择希望以电子还是纸质方式领取处方笺,这项信息(处方笺发行形式)会与在线资格确认的结果一并传送到结算系统。在ORCA的源代码中,资格确认结果表里的处方笺发行形式字段也是在2022年7月新增的,由此可知在线资格与电子处方笺是建立在同一基础设施之上、层层叠加而成的。

作者简介

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

Go Komura

小村软件有限公司 代表

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