電子処方箋はレセコンの何を変えるのか ── ORCAの電子処方箋対応をソースコードから読む

2023年1月に運用が始まった電子処方箋は、オンライン資格確認に続く医療DXの第2弾としてよく語られます。では、レセコンにとって電子処方箋対応とは具体的に何をすることなのか──処方箋という帳票の電子化、と言うだけでは設計はできません。

第1回でレセコンの役割、第2回で日レセAPI、第3回でオンライン資格確認、第4回でレセプト点検を扱ってきました。第5回の今回は、電子処方箋をレセコン側から解剖します。

• 電子処方箋で処方の流れはどう変わるのか(制度の最短理解)
• ORCA(日レセ)の対応の全体像 ── 本体と対応プログラムの責任分界
• 処方箋ID・引換番号・リフィルを管理するtbl_shoho_kanriの設計
• 発行形態の希望がオンライン資格確認から届く、という制度間の接続

制度側の記述は厚生労働省・ORCA公式の公開資料に、ソースコードに関する記述は公式公開されている日レセ本体 5.2系ソース(2026年7月1日公開スナップショット) を実際に読んで確認した結果に基づきます。

目次

1. まず結論 ── 処方箋は「渡すもの」から「取りに行くもの」になる
2. 制度の最短理解 ── 電子処方箋管理サービスと引換番号
3. 前史 ── 処方箋は2001年からQRコードを背負っていた
4. ORCA対応の全体像 ── 本体と対応プログラムの責任分界
5. tbl_shoho_kanriを読む ── 1枚の処方箋が持つ電子的な属性
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/>(マイナ保険証 or 引換番号)"]
    PT --> PH["薬局"]
    EPS -->|"処方箋データ取得"| PH
    PH -->|"調剤結果登録"| EPS2["(管理サービスへ)<br/>重複投薬等チェックの基盤に"]

• 医療機関は処方箋データを電子処方箋管理サービス(オンライン資格確認と同じく支払基金・国保中央会が運営)へ登録する。
• 患者は紙を持ち歩く代わりに、マイナ保険証で薬局受付するか、引換番号(と被保険者証等の情報)を伝える。
• 薬局は管理サービスから処方箋データを取りに行き、調剤結果を登録する。

レセコン視点での本質は2つです。第一に、処方箋が院内で完結する帳票ではなく、外部サービスに登録される構造化データになったこと。第二に、処方・調剤の実績が管理サービスに集まることで、医療機関・薬局をまたいだ重複投薬等のチェックが可能になったことです。第4回で「他機関のデータとの突き合わせは院内では原理的にできない」と書きましたが、電子処方箋はその壁を処方領域で(審査のタイミングではなく処方のタイミングで)越えるための国のインフラだと位置づけられます。

2. 制度の最短理解 ── 電子処方箋管理サービスと引換番号

制度側の要点だけ整理します。

• いつから: 2023年1月に運用開始。オンライン資格確認のネットワークと基盤を前提とした仕組みで、対応施設は段階的に拡大しています。
• 処方箋の特定方法: 発行された電子処方箋には処方箋IDが振られます。患者がマイナ保険証で薬局受付する場合はカードリーダー上で対象の電子処方箋を選択して特定し(複数ある場合の選択ステップがあります)、マイナ保険証を使わない場合は引換番号と被保険者証等の情報を薬局へ伝えて特定します(引換番号単独では特定できません)。
• 重複投薬等チェック: 処方・調剤情報が管理サービスに蓄積されるため、処方の時点で直近の処方・調剤データと突き合わせたチェック結果を医師・薬剤師が参照できます。
• リフィル処方箋: 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: 調剤結果を登録

この図から読み取るべきことは2つあります。

第一に、病院から薬局へシステム連携データが直接渡ることはないこと。処方箋の正データは常に管理サービスを経由します。患者が運ぶのは「鍵」(マイナ保険証または引換番号)で、処方内容(控え)の紙を受け取って持ち歩く場合もありますが、控えはあくまで参考情報であり、薬局が調剤に使う正データは管理サービスから取得します。病院・薬局間のポイントツーポイント連携を作り込む必要がない代わりに、両者とも管理サービスとの連携品質がすべてになります。

第二に、3つの識別子は役割がはっきり分かれていることです。

ORCA側でこの往復の痕跡が残るのが、後述する処方管理テーブルです。発行時に管理サービスから返ってきた処方箋IDと引換番号がそのまま格納され(PRESCRIPTIONID・ACCESSCODE)、控え帳票への印字や取消・変更時の突合に使われます。

3. 前史 ── 処方箋は2001年からQRコードを背負っていた

「処方箋のデータ化」自体は、実は新しい話ではありません。ORCAのソースにはcobol/common/ORCSQRCSV.CBL「処方箋　ＱＲデータ出力」というプログラムがあり、作成日付は2001年9月。紙の処方箋にQRコードを印字し、薬局側システムが読み取って調剤システムへ取り込む──という運用は、20年以上前から存在していました。

つまり電子処方箋がもたらした変化は「データ化」ではなく、データの置き場所と取得経路の標準化です。QRコードは紙に印字された「その1枚だけのデータ」でしたが、電子処方箋は全国共通の管理サービスに登録され、処方箋IDで誰でも(権限の範囲で)取得できる。この違いが、重複投薬チェックのような横断的な機能を可能にしました。ソースの中に新旧2つの仕組みが同居しているのは、移行期のレセコンらしい風景です。

4. ORCA対応の全体像 ── 本体と対応プログラムの責任分界

ORCAの電子処方箋対応は、公式ページ(「日医標準レセプトソフト電子処方箋」)によると日レセ本体+電子処方箋対応プログラム(電子処方箋API)という構成です。5.2系の公開ソースを読むと、この分界線が実装からも確認できます。

面白いのは最後の行です。電子処方箋の技術的なハイライトである電子署名まわりが、日レセ本体の400万行には一切登場しない。本体は「処方データの正であり続けること」に徹し、署名・通信という変化の速い領域は別プログラムに切り出す──第3回で見たオン資連携(本体はAPIとテーブル、ファイル授受はonshi-tools)と同じ分界パターンです。国のインフラ側の仕様変更を、本体のリリースサイクルから切り離す設計だと解釈できます。

では、切り出された側には何がいるのか。公式ページに載っている対応プログラム群の顔ぶれはこうです。

対応OSはコンポーネントごとに異なり、電子処方箋モジュールと拡張電処ヘルパーはWindows 11(x64)専用、処方入力画面はWindows・Mac・Ubuntu(Ubuntu対応はWebORCAオンプレ版のみ)です。院内端末の計画では、発行まわりのモジュールがWindows前提であることに注意してください。そして署名の分担が重要で、公式ページには「電子処方箋を導入するためには、別途電子署名モジュールが必要」と明記されています。検証済みの電子署名モジュール(アイ・オー・データ機器、三菱電機ITソリューションズ提供)が、HPKIカードによるローカル署名とリモート署名(FIDO認証・HPKIカード認証・マイナンバーカード認証)を担います。つまり、電子処方箋で最も動きの激しい「医師の電子署名をどう成立させるか」という論点は、日レセ本体からも電処モジュールからも切り出され、専用の署名モジュール層に吸収されている──本体ソースにHPKIが登場しない理由の、これが答え合わせです。

電子カルテがいる場合、発行の主体はどちらか

ここまでの図は医療機関内を1本の流れに畳んでいましたが、実際の院内には電子カルテとレセコンが併存する構成が多くあります。その場合、処方が薬局(管理サービス)に届くまでの通り道は、大きく2パターンに分かれます。

図にすると、2つのパターンの違いは「署名・登録の箱がどちら側にあるか」に集約されます。

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側のどちらに置くか、そしてその決定に合わせて処方箋ID・引換番号が請求データと突合できるようにtbl_shoho_kanri相当の管理をどちらが持つか、という点です。

5. tbl_shoho_kanriを読む ── 1枚の処方箋が持つ電子的な属性

日レセ本体側の中心は処方管理テーブル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);  -- 処方箋ＩＤ
    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章で見た2通りの受け取り方(マイナ保険証/引換番号)に対応するキーが、レコードの属性としてそのまま載っています(なお現行運用の引換番号は6桁で、16桁はカラムの容量です。桁数を固定値として実装しないほうが安全でしょう)。
• 取消と変更に、それぞれUNDOの日時がある。 電子処方箋は管理サービスに登録済みのデータなので、院内で処方を取り消せば登録も取り消す必要があり、さらにその取消を取り消す(復元する)操作まで起こりえます。紙の時代には「破って書き直す」だった運用が、状態遷移の管理に変わったわけです。
• リフィルが最初から属性である。 リフィル回数と処方日数が処方管理の基本項目に入っており、繰り返し利用を前提としたライフサイクル管理が設計に織り込まれています。

なお識別にuuidを使う作りは、第3回のオン資関連テーブル(tbl_onshi_kaku)と共通のイディオムです。ただし主キーはuuid単独ではなく医療機関番号+uuid+連番(RENNUM)の複合キーで、同じuuidに複数行がぶら下がる設計です。連携システム側でこのテーブル相当のデータを扱うときは、uuidだけを行キーとみなすと複数行が潰れるので注意してください。

6. データの出口 ── 電子処方箋CSVと帳票

第5章のテーブルと第7章のオン資接続まで含めて、ORCA内部をデータがどう通るのかを先に1枚にしておきます。

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月) ── 運用開始から2年半を過ぎても、年に数回のペースで改修が続く

この履歴が示すとおり、電子処方箋のCSV連携は「一度作って終わり」ではなく現在進行形で変わり続けています。帳票側では、処方箋様式の帳票プログラム(ORCHC02系・ORCHCM19系)に電子処方箋対応の版が並びます。電子処方箋になっても帳票が消えないのは、患者に渡す控え(引換番号の通知を含む)や、紙運用との併存が続くためです。「電子化=帳票廃止」ではなく、帳票は残しつつ正データの置き場所が変わるというのが移行期の実態で、ソースのファイル構成がそれを正直に映しています。

7. オン資との接続 ── 発行形態は資格確認から届く

電子処方箋を院内フローとして見ると、最初の分岐は「この患者は電子と紙のどちらで処方箋を受け取るか」です。この情報はどこから来るのか──答えはオンライン資格確認です。

患者がマイナ保険証で受付するとき、カードリーダー上で処方箋の受け取り方(電子/紙)を選択できます。その選択は資格確認の結果と一緒にレセコンへ届きます。第3回で読んだオン資の資格確認結果テーブルtbl_onshi_kakuには処方箋発行形態の項目(SHO_SHOHO_KEITAI)があり、定義コメントによれば2022年7月の追加。オン資のXML定義にもPrescriptionIssueSelect(処方箋発行形態)という項目が存在します。電子処方箋の運用開始(2023年1月)の半年前に、まずオン資側の受け口が拡張されていた──制度が積み上がる順番まで、ソースの日付から読み取れるわけです。

そして受付で決まった発行形態は、処方の場面でtbl_shoho_kanri.SHOHO_KEITAIとして処方箋1枚ごとに確定します。オン資(受付)→処方(診療)→管理サービス(発行)という制度間のデータの受け渡しが、テーブル設計のレベルでつながっている。オンライン資格確認を「資格を入口に情報が流れる幹線」と呼んだ第3回の見立てが、電子処方箋でも裏づけられます。

8. ベンダー向け ── 検証環境をどう用意するか

電子処方箋の連携開発で最初につまずくのは、コードではなく「仕様書とテスト環境の入手経路が分散している」ことです。公式情報を入口ごとに整理します。

1) 仕様書の入手 ── 「医療機関等ONS」

システムベンダ向けの一次仕様は、支払基金が提供するベンダ向け情報サイト「医療機関等ONS」に集約されています(オンライン資格確認等システム外部インターフェイス仕様書や電子処方箋管理サービス記録条件仕様もここ)。医療機関が使う総合ポータルとは別サイトで、ベンダとしての利用登録が前提です。あわせて、厚労省の「電子処方箋(システムベンダ向け)」ページにシステムベンダ向け技術解説書(執筆時点で2.04版)や薬局システム向けの連携資料が公開されています。なお、JAHISの「電子処方箋実装ガイド」(Ver.1.2、2021年)は現行の電子処方箋管理サービスより前の検討資料であり、現行仕様の一次資料はあくまでONSの仕様書・技術解説書側です。検索で先にヒットしがちなので注意してください。

2) テスト用の証明書・カードの入手

電子処方箋の発行には医師・歯科医師の電子署名(HPKI)が必須なので、テストにも証明書が要ります。入手窓口は用途で分かれます。

• HPKIテストカード(署名用・認証用): 窓口は職種で分かれます。医師用は日医電子認証センター(JMACA)の「ベンダーのみなさまへ」ページから申込書を郵送して入手。歯科医師用・薬剤師用はそれぞれの認証局(MEDIS、日本薬剤師会認証局)の案内に従います。
• HPKIセカンド電子証明書(カードレス署名)の検証環境利用・テスト用マイナンバーカード: MEDIS(医療情報システム開発センター)の専用窓口へメールで申請。
• 注意点として、本番用のHPKIカードは平時でも申請から発行まで2〜3か月かかります。さらに執筆時点のJMACAの案内では、ICカード不足により物理カード(医師資格証)の発行が一時停止され、HPKIセカンド電子証明書(カードレス)を先行発行する運用が案内されています。カード前提の計画を立てる前に、最新の発行状況とカードレス署名での代替可否から確認するのが安全です。

3) 接続検証とリリース前チェック

管理サービスとの接続検証はONS経由の案内に沿って進めることになりますが、開発者として先に読んでおきたいのが、厚労省が公開している「電子処方箋対応版ソフトのリリースに関するセルフチェックリスト(テスト完了確認)」(執筆時点で4.2版)です。ベンダはこのチェックリストのテスト完了を確認してリリースする建付けになっており、裏を返せば「何をテストすべきか」の公式リストが最初から存在するということです。テスト計画はここから逆算するのが早道です。また、署名処理を自前実装しない選択肢として電子処方箋署名共通モジュールがあり、導入支援サービス提供事業者の一覧も厚労省ページに掲載されています。

4) ORCA側の検証環境

日レセ+対応プログラム構成で検証するなら、WebORCAオンプレ版を検証用サーバに立て、公式の電処モジュール&拡張電処ヘルパー インストールマニュアルに沿ってセットアップします。第6章で見たとおり電子処方箋は用法マスタと連動するため、マスタ更新まで済ませておかないと出力データの検証になりません。さらに、標準用法コードには使用期限があります。執筆時点の公式ページでは、2026年8月1日から一部の標準用法コードが電子処方箋で使用不可となり、期限切れコードのマッピングが残っていると日レセはダミーコードを出力する旨が案内されています。マスタを最新化するだけでなく、自システムが使っている用法コードの再マッピング確認まで検証項目に含めてください(今テストが通っても、期限日を境にダミーコード出力へ変わりえます)。第3回で紹介したオン資の検証用パターンファイルと同じく、自前でテストデータを創作する前に公式の検証手段を確認するのが鉄則です。

9. 連携システムを作る側の実務ポイント

電子カルテ・処方支援・受付システムなどから電子処方箋まわりに関わるときの要点です。

1. 責任分界を最初に引く。 処方データの管理は日レセ本体、署名・管理サービス通信は電子処方箋対応プログラム、という分界がORCAの標準構成です。自作の連携システムがどちら側と会話すべきかを、機能ごとに切り分けてから設計してください。署名まわりを自前実装する判断は、HPKIカードの運用まで背負うことを意味します。
2. 処方箋IDと引換番号をエンティティとして扱う。 「処方箋=印刷物」のデータモデルのままだと、取消/変更/UNDO、リフィルといった状態管理が後付けになります。tbl_shoho_kanriの項目構成は、電子処方箋時代の処方エンティティ設計の参考書として優秀です(ただし持っているのはリフィルの回数・日数であり、使用済み回数・残回数の状態は載っていません。残回数は調剤側のライフサイクルに属するデータとして、別途扱う前提で設計してください)。
3. 発行形態は受付起点で流れてくる──ただしマイナ受付に限る。 電子/紙の希望がオン資の資格確認結果に含まれるのは、マイナ保険証で受付した場合です。資格確認書などマイナ保険証を使わない患者では、窓口や診察室でスタッフ・医師が意向を確認する運用になるため、SHO_SHOHO_KEITAIだけを頼りにすると意向未確認のまま処方に到達する経路が残ります。受付時点の情報を診療・処方まで引き回す動線と、カードリーダー由来の値がない場合の確認フローを、両方設計に含めてください。
4. 「紙」の中にも2種類あることを前提にする。 全患者・全薬局が電子に揃うまでは紙の処方箋が残りますが、電子処方箋を導入済みの施設では、紙の処方箋でも処方・調剤情報を管理サービスに登録する運用(引換番号付きの紙処方箋)があり、重複投薬等チェックの対象になります。「電子/紙」の二分ではなく、「電子/管理サービス登録ありの紙/従来のQRコード運用の紙」という三択を前提にした分岐設計が現実的です。
5. 制度の拡張を追う仕組みを持つ。 用法マスタ対応、リフィル対応と、電子処方箋まわりのソースは毎年更新されています。シリーズで繰り返し勧めているとおり、月次公開ソースのrecord/・cobol/のdiff監視が、ここでも公式アナウンスより早い変更検知になります。

10. まとめ

• 電子処方箋は、処方箋を「患者が持ち運ぶ紙」から「管理サービスに登録され、処方箋ID/引換番号で取得される構造化データ」に変える仕組み。処方・調剤情報の集約により、医療機関・薬局をまたぐ重複投薬等チェックが可能になった。
• ORCAの対応は日レセ本体(データ管理・CSV出力・帳票)+対応プログラム群(電子処方箋モジュール・拡張電処ヘルパー等)+別途必要な電子署名モジュール(検証済みのベンダー提供品)という構成。本体ソースに電子署名が登場しないことが、この責任分界の証拠になっている。
• 本体側の中心はtbl_shoho_kanriで、処方箋ID・引換番号・リフィル回数/日数・取消/変更とそのUNDO日時を処方箋単位で管理する。処方箋QRコード出力(2001年〜)との同居がソースに残り、「データ化」から「置き場所の標準化」へという変化の本質を映している。
• 電子/紙の発行形態は、マイナ受付ではオンライン資格確認の結果として受付時に届く(オン資側の受け口はソース上2022年7月に先行追加)。資格確認書等の患者では窓口・診察室での意向確認が別途必要。オン資→電子処方箋という制度の積み上がりが、テーブルとXML定義のレベルで接続されている。

シリーズ次回は、ORCAのデータベーススキーマ全体を読む「DB編」または月次ソースdiff監視の実運用を予定しています。

11. 参考資料

• 電子処方箋 - 厚生労働省
• 日医標準レセプトソフト電子処方箋 - ORCA Project(電子処方箋対応プログラム・対象帳票)
• 日医標準レセプトソフトの電子処方箋対応について - ORCA Project
• 電子処方箋(システムベンダ向け) - 厚生労働省(技術解説書・記録条件仕様・リリース前セルフチェックリスト)
• ベンダーのみなさまへ(HPKIテストカード) - 日本医師会電子認証センター
• 処方せん印刷API - ORCA Project
• 日レセ本体 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(日レセ)は電子処方箋にどう対応していますか？

役割が2つに分かれています。日レセ本体は、処方箋ID・引換番号・リフィル回数・取消/変更履歴を管理するテーブル(tbl_shoho_kanri)と、処方内容をCSVとして出力する仕組み、電子処方箋対応の処方箋様式帳票を持ちます。一方、電子署名(HPKIカードによるローカル署名やリモート署名)や電子処方箋管理サービスとの通信は、電子処方箋モジュール・拡張電処ヘルパーなどの対応プログラム群と、別途必要な電子署名モジュール(検証済みのベンダー提供品がある)の仕事です。公開されている日レセ本体ソースに電子署名処理が見当たらないことからも、この責任分界が読み取れます。

引換番号とは何ですか？

患者がマイナ保険証を使わずに薬局で電子処方箋を受け取るときに使う番号です。薬局はこの番号と被保険者証情報から処方箋を特定して管理サービスから取得します。現行運用の引換番号は6桁の番号で、ORCA(日レセ)のソースでは処方管理テーブルにACCESSCODE(最大16桁の領域)として保存され、処方箋IDとセットで管理されています。

オンライン資格確認と電子処方箋はどう関係しますか？

入口がつながっています。患者がマイナ保険証で受付するとき、カードリーダー上で処方箋を電子で受け取るか紙で受け取るかの希望を選択でき、その情報(処方箋発行形態)がオンライン資格確認の結果と一緒にレセコンへ流れてきます。ORCAのソースでも、資格確認結果テーブルに処方箋発行形態の項目が2022年7月に追加されており、オン資と電子処方箋が同じ基盤の上に積み上がっていることが分かります。

著者プロフィール

記事の著者プロフィールページです。

小村 豪

合同会社小村ソフト 代表

Windows ソフト開発、技術相談、不具合調査を中心に、既存資産が残る案件や原因が見えにくい障害調査に強みがあります。