電子處方箋改變了電腦醫療報酬系統的什麼──從原始碼解讀ORCA的電子處方箋對應

2023年1月開始運作的電子處方箋，經常被稱為繼線上資格確認之後醫療DX的第二波。那麼，對電腦醫療報酬系統（レセコン）而言，因應電子處方箋具體上要做什麼呢──光說「把處方箋這張報表電子化」是無法據此進行設計的。

第1回探討了電腦醫療報酬系統的角色，第2回探討了日レセAPI，第3回探討了線上資格確認，第4回探討了診療報酬單審查邏輯。這次的第5回，將從電腦醫療報酬系統的角度剖析電子處方箋。

• 電子處方箋會為處方流程帶來什麼改變（制度面的最短理解）
• ORCA（日レセ）因應方式的整體樣貌 ── 本體與對應程式之間的責任分界
• 管理處方箋ID・兌換碼・重複處方（Refill）的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年起就背負著QR碼
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/>(健保卡數位化 或 兌換碼)"]
    PT --> PH["藥局"]
    EPS -->|"取得處方箋資料"| PH
    PH -->|"登錄調劑結果"| EPS2["(送往管理服務)<br/>成為重複用藥等檢查的基礎"]

• 醫療機構將處方箋資料登錄到電子處方箋管理服務（與線上資格確認相同，由支付基金・國保中央會營運）。
• 患者不必再隨身攜帶紙本，改用健保卡數位化於藥局掛號，或是告知兌換碼（及被保險人資訊等）。
• 藥局則主動向管理服務取得處方箋資料，並登錄調劑結果。

從電腦醫療報酬系統的角度來看，本質有兩點。第一，處方箋不再是院內自我完結的一張報表，而變成登錄到外部服務的結構化資料。第二，由於處方・調劑的實際紀錄集中到管理服務端，跨醫療機構・藥局的重複用藥等檢查才得以實現。第4回曾寫過「與其他機構資料的比對，原理上院內做不到」，而電子處方箋可以定位為一套國家級基礎架構，讓處方領域（不是在審查階段，而是在處方的當下）跨越了這道牆。

2. 制度的最短理解 ── 電子處方箋管理服務與兌換碼

以下只整理制度面的重點。

• 從何時開始：2023年1月開始運作。這是以線上資格確認的網路與基礎架構為前提的機制，對應機構正逐步擴大中。
• 處方箋的確定方式：每一張發行出去的電子處方箋都會被賦予一個處方箋ID。患者以健保卡數位化在藥局掛號時，可在讀卡機上選擇要調劑的電子處方箋來確定（有多張時會有選擇步驟）；不使用健保卡數位化時，則需將兌換碼與被保險人資訊等告知藥局來確定（單靠兌換碼無法確定）。
• 重複用藥等檢查：由於處方・調劑資訊會累積到管理服務中，醫師・藥師可以在處方的當下參考與近期處方・調劑資料比對後的檢查結果。
• 重複處方箋（Refill處方箋）：2022年度診療報酬修訂中引進，可在一定期間內重複使用的處方箋。電子處方箋與重複處方的重複使用管理也相當契合，如後文所述，ORCA的資料表中同樣內建了重複處方相關欄位。

識別碼如何在醫院與藥局之間往返

若依照從發行到調劑的時間順序，追蹤處方箋ID・兌換碼・被保險人資訊這3個識別碼分別經過誰的手，就能最清楚地看出電子處方箋的結構。

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 以健保卡數位化掛號
        PT->>PH: 出示健保卡數位化<br/>在讀卡機上選擇要調劑的處方箋
        PH->>EPS: 以被保險人資訊查詢
    else 以兌換碼掛號
        PT->>PH: 告知兌換碼+被保險人證等資訊
        PH->>EPS: 以被保險人號碼等+兌換碼查詢
    end
    EPS-->>PH: 回傳處方箋資料(內部以處方箋ID管理)
    PH->>EPS: 登錄調劑結果

從這張圖應該讀出兩件事。

第一，醫院與藥局之間不存在系統整合資料的直接傳遞。處方箋的正本資料永遠經由管理服務流轉。患者攜帶的是「鑰匙」（健保卡數位化或兌換碼），雖然有時也會拿到處方內容的存根紙本隨身攜帶，但存根終究只是參考資訊，藥局實際用於調劑的正本資料是從管理服務取得的。這樣一來，醫院與藥局之間不需要建構點對點整合，取而代之的是雙方與管理服務之間整合品質的高低，將決定一切。

第二，3個識別碼的角色分工十分明確。

在ORCA端，留存這段往返痕跡的正是後文將要介紹的處方管理資料表。發行時從管理服務回傳的處方箋ID與兌換碼會原封不動地儲存（PRESCRIPTIONID・ACCESSCODE），用於存根報表的列印，以及取消・變更時的核對。

3. 前史 ── 處方箋自2001年起就背負著QR碼

「處方箋的資料化」這件事本身，其實並不是什麼新鮮話題。ORCA的原始碼中有一支名為cobol/common/ORCSQRCSV.CBL「處方箋　ＱＲ資料輸出」的程式，建立日期為2001年9月。在紙本處方箋上列印QR碼，由藥局端系統讀取後匯入調劑系統──這樣的運作方式，早在20多年前就已經存在。

也就是說，電子處方箋帶來的改變並非「資料化」本身，而是資料存放位置與取得途徑的標準化。QR碼是印在紙上的「僅此一張的資料」，而電子處方箋則登錄在全國統一的管理服務中，任何人（在權限範圍內）都能憑處方箋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卡認證・數位身分識別卡認證）。也就是說，電子處方箋中變動最劇烈的議題──「如何實現醫師的電子簽章」──既沒有留在日レセ本體中，也沒有留在電處模組中，而是被吸收進了專門的簽章模組層。這正是本體原始碼中不出現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章看到的兩種領取方式（健保卡數位化/兌換碼）所對應的金鑰，原封不動地作為紀錄的屬性列出（此外，現行運作中的兌換碼為6碼，16碼只是欄位的容量。把位數當作固定值寫死來實作恐怕並不安全）。
• 取消與變更各自都有對應的UNDO日期時間。 由於電子處方箋是已登錄至管理服務的資料，院內一旦取消處方，就必須同時取消登錄，甚至還可能出現「取消該取消」（即復原）的操作。紙本時代那種「撕掉重寫」的做法，如今變成了狀態轉移的管理。
• 重複處方（Refill）從一開始就是一個屬性。 重複處方次數與處方天數被納入了處方管理的基本欄位，以重複使用為前提的生命週期管理已編織進設計之中。

另外，使用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. 與線上資格確認的連結 ── 發行形態從資格確認送達

把電子處方箋放進院內流程來看，第一個分岔點就是「這位患者要以電子還是紙本方式領取處方箋」。這項資訊是從哪裡來的呢──答案是線上資格確認。

患者以健保卡數位化掛號時，可以在讀卡機上選擇處方箋的領取方式（電子/紙本）。這個選擇會與資格確認的結果一同送達電腦醫療報酬系統。第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第二電子憑證（無卡簽章）的驗證環境使用・測試用數位身分識別卡：透過電子郵件向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. 發行形態的資訊從掛號環節流入──但僅限於健保卡數位化掛號的情況。 電子/紙本的意願，只有在以健保卡數位化掛號時，才會包含在線上資格確認的結果中。對於使用資格確認書等、不使用健保卡數位化的患者，則需要由櫃檯或診間的工作人員・醫師另行確認意向，因此若只依賴SHO_SHOHO_KEITAI，就會殘留一條意向未經確認便直接抵達處方環節的路徑。請在設計中同時納入把掛號時的資訊貫穿至診療・處方的動線，以及在沒有讀卡機來源數值時的確認流程。
4. 要預設「紙本」本身也分為兩種。 在所有患者・所有藥局都完成電子化之前，紙本處方箋仍會繼續存在，但在已導入電子處方箋的機構中，存在即便是紙本處方箋，也會把處方・調劑資訊登錄至管理服務的運作方式（附兌換碼的紙本處方箋），這類處方箋同樣會成為重複用藥等檢查的對象。與其做「電子/紙本」的二分法，不如以「電子/已登錄至管理服務的紙本/沿用原有QR碼運作的紙本」這三選一為前提來設計分支，更貼近現實。
5. 建立追蹤制度擴充的機制。 從用法主檔對應到重複處方對應，電子處方箋周邊的原始碼每年都在更新。正如本系列反覆建議的那樣，對每月公開原始碼中record/・cobol/目錄進行diff監控，在這裡同樣能比官方公告更早察覺到變化。

10. 總結

• 電子處方箋是把處方箋從「由患者隨身攜帶的紙張」，轉變為「登錄至管理服務、透過處方箋ID/兌換碼取得的結構化資料」的機制。透過彙整處方・調劑資訊，跨醫療機構・藥局的重複用藥等檢查得以實現。
• ORCA的因應方式採取的是日レセ本體（資料管理・CSV輸出・報表）+對應程式群（電子處方箋模組・擴充電處輔助工具等）+需另行準備的電子簽章模組（經過驗證的廠商提供產品）這套架構。本體原始碼中不出現電子簽章字樣，正是這條責任分界的證據。
• 本體端的核心是tbl_shoho_kanri，以處方箋為單位管理處方箋ID・兌換碼・重複處方次數/天數・取消/變更及其UNDO日期時間。原始碼中留存著與處方箋QR碼輸出（2001年～）並存的痕跡，映照出從「資料化」走向「存放位置標準化」這一變化的本質。
• 電子/紙本的發行形態，在健保卡數位化掛號時，會作為線上資格確認的結果在掛號時送達（線上資格確認端的接口，在原始碼上是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 等 ── 本文中關於實作的敘述均基於這份快照

相關文章

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

相關主題

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

與本主題相關的服務

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

常見問題

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

電子處方箋與紙本處方箋有什麼不同？

與患者攜帶紙本處方箋前往藥局不同，電子處方箋是將處方箋資料登錄到電子處方箋管理服務（由支付基金・國保中央會營運），再由藥局線上取得。患者可以用健保卡數位化掛號，在讀卡機上選擇要調劑的處方箋，或是把兌換碼與被保險人資訊告知藥局來確定處方箋（處方箋ID是系統內部使用的識別碼，並非患者需要處理的號碼）。由於處方・調劑資訊都集中到管理服務端，因此能夠進行跨醫療機構・藥局的重複用藥等檢查，這是最大的變化。

ORCA（日レセ）是如何因應電子處方箋的？

角色分成兩部分。日醫標準診療報酬軟體本體擁有管理處方箋ID・兌換碼・重複處方（Refill）次數・取消/變更歷程的資料表（tbl_shoho_kanri），以及將處方內容輸出為CSV的機制、支援電子處方箋的處方箋格式報表。另一方面，電子簽章（透過HPKI卡進行的本地簽章或遠端簽章）以及與電子處方箋管理服務的通訊，則是電子處方箋模組・擴充電處輔助工具等對應程式群，以及需另行準備的電子簽章模組（有經過驗證的廠商提供產品）的工作。從公開的日レセ本體原始碼中找不到電子簽章相關處理這一點，也能看出這條責任分界線。

兌換碼是什麼？

這是患者在不使用健保卡數位化、於藥局領取電子處方箋時所使用的號碼。藥局會依據這個號碼與被保險人資訊來確定處方箋，並從管理服務取得。現行運作中的兌換碼為6位數，在ORCA（日レセ）的原始碼中，是以處方管理資料表的ACCESSCODE（最大16位的欄位）保存，並與處方箋ID成對管理。

線上資格確認與電子處方箋是什麼關係？

兩者的入口是相連的。患者以健保卡數位化掛號時，可以在讀卡機上選擇希望以電子還是紙本方式領取處方箋，這項資訊（處方箋發行形態）會與線上資格確認的結果一併傳送到電腦醫療報酬系統。在ORCA的原始碼中，資格確認結果資料表裡的處方箋發行形態欄位，也是在2022年7月新增的，由此可知線上資格確認與電子處方箋是建立在同一套基礎架構之上、層層堆疊而成的。

作者檔案

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

Go Komura

小村軟體有限公司 代表

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