ORCAの電子処方箋対応の知識マップ(知識グラフ)
電子処方箋は、紙の処方箋を患者が薬局へ持参する仕組みから、処方箋データを電子処方箋管理サービスへ登録し処方箋IDと引換番号で取得する仕組みへと処方箋の流れを変える。ORCA(日レセ)は処方箋ID・引換番号・リフィル回数・取消/変更を管理する処方管理テーブルtbl_shoho_kanriと電子処方箋CSV出力を担い、電子署名やHPKI認証、管理サービスとの通信は電処モジュール・拡張電処ヘルパーと別途必要な電子署名モジュールに切り出されている。処方箋の電子/紙の発行形態はマイナ保険証によるオンライン資格確認の結果として受付時に届き、処方・調剤情報が管理サービスに集約されることで医療機関・薬局をまたいだ重複投薬等チェックが可能になる。
電子処方箋
紙の処方箋を患者が薬局へ持参する代わりに、処方箋データを電子処方箋管理サービスに登録し、薬局がオンラインで取得する2023年1月運用開始の制度。
電子処方箋制度
電子処方箋管理サービス
支払基金・国保中央会が運営する、電子処方箋データの登録先・取得元となる管理サービス。
管理サービス
処方箋ID
電子処方箋管理サービスが発行する36桁のシステム内部の識別子。処方箋レコードの主キーで、患者は扱わない。
引換番号
患者がマイナ保険証を使わずに薬局で電子処方箋を受け取るときに管理サービスが発行する、現行運用で6桁の人間可読の番号。単独では無効。
被保険者情報
保険者がオンライン資格確認の基盤で確認する情報で、医療機関側の登録にも薬局側の照会にも共通キーとして使われる。
ORCA(日医標準レセプトソフト/日レセ)
日本医師会が提供する「日医標準レセプトソフト」の略称。ソースコードが公開されているレセプトコンピューター。
日レセ
日医標準レセプトソフト
処方管理テーブル(tbl_shoho_kanri)
処方箋ID・引換番号・リフィル回数・処方日数・取消/変更日時とそのUNDO日時を、医療機関番号+uuid+連番の複合キーで処方箋単位に管理するORCAのテーブル。
record/*.db(データ構造定義)
リクエスト・レスポンスやレコードのデータ構造を宣言するORCAソース中の定義ファイル群。XMLのタグ名はここの項目名がそのまま使われる。
record定義
リフィル処方箋
2022年度診療報酬改定で導入された、一定期間内に繰り返し使える処方箋の仕組み。
リフィル
電子処方箋CSVデータ出力
処方管理テーブルの内容を電子処方箋対応プログラムへ渡すためのCSVを出力する、日レセ本体のCOBOLプログラム。2022年10月新規作成。
COBOL
DATA DIVISIONによるレコード定義とPROCEDURE DIVISIONによる処理手順を柱とする、業務システムで使われてきたプログラミング言語。
COBOL言語
電子処方箋モジュール(電処モジュール)
電子処方箋の発行処理を担う、ORCA公式の電子処方箋対応プログラムの1つ。Windows 11(x64)専用。
電処モジュール
電子署名モジュール
電子処方箋の導入に別途必要な、検証済みのベンダー提供品。HPKIカードによるローカル署名とリモート署名(FIDO認証・HPKIカード認証・マイナンバーカード認証)を担う。
拡張電処ヘルパー
電子処方箋の発行まわりの補助機能を担う、ORCA公式の対応プログラム。Windows 11(x64)専用。
拡張電処補助モジュール
HPKI(保健医療福祉分野の公開鍵基盤)
医師などの国家資格を証明できる電子証明書の基盤。電子処方箋の電子署名に使う。
重複投薬等チェック
処方・調剤情報が電子処方箋管理サービスに蓄積されることで可能になる、医療機関・薬局をまたいだ重複投薬等の確認。
オンライン資格確認(オン資)
マイナ保険証などをキーに患者の保険資格をオンラインで即時確認する制度とシステムで、社会保険診療報酬支払基金・国民健康保険中央会が運営する。
オン資
オンライン資格確認等システム
処方箋発行形態の選択
患者がカードリーダー上で選択する、処方箋を電子で受け取るか紙で受け取るかの希望。オン資の資格確認結果テーブルの項目として2022年7月に追加された。
マイナ保険証
マイナンバーカードを健康保険証として利用する仕組みで、カードリーダーでの受付時に電子処方箋の受け取り方を選択できる。
マイナンバーカードの健康保険証利用
処方箋QRコード出力
紙の処方箋にQRコードを印字し薬局側システムが読み取る、2001年9月作成の日レセの機能。電子処方箋以前から存在する処方データ化の前史。
電子カルテ
院内でレセコンと併存することが多い、診療記録・オーダーを扱うシステム。電子処方箋では発行主体をORCA側・電子カルテ側のどちらに置くかで連携パターンが分かれる。
日レセAPI
ORCAが外部システム向けに提供するAPI群。5.2系ソース(2026年7月スナップショット)ではlddefのbindapi宣言を数えると137エンドポイントが実在する。
日レセAPI全体像
電子処方箋では、医療機関が処方箋データを電子処方箋管理サービスへ登録することが前提になる
管理サービスは発行した処方箋に処方箋ID(36桁)を振り、薬局の取得も調剤結果の登録もこのIDに紐づける
マイナ保険証を使わない受付のために、管理サービスは引換番号を発番する
引換番号は単独では無効で、被保険者情報とセットで初めて処方箋を照会できる
日レセ本体は、処方箋ID・引換番号・リフィル回数・取消/変更履歴を管理する処方管理テーブルtbl_shoho_kanriを持つ
tbl_shoho_kanriのテーブル定義はrecord/tbl_shoho_kanri.dbに宣言されている
tbl_shoho_kanriはPRESCRIPTIONID項目として、管理サービスから返ってきた処方箋IDを保持する
tbl_shoho_kanriはACCESSCODE項目として引換番号を保持する
tbl_shoho_kanriはREFILL_NUM・REFILL_ZAIKAISUの項目でリフィル回数と処方日数を保持する
日レセ本体は処方内容を電子処方箋対応プログラムへ渡すためのCSV出力の仕組みを持つ
電子処方箋CSVデータ出力プログラム(ORCSEPRECSV.CBL)はCOBOLで実装されている
電子処方箋CSV出力は処方管理テーブルtbl_shoho_kanriのデータを元にCSVを組み立てる
電処モジュールは日レセ本体が出力した電子処方箋CSVを取り込んで登録要求を組み立てる
公式ページは、電子処方箋を導入するためには電処モジュールとは別に電子署名モジュールが必要と明記している
電子処方箋の発行処理は電処モジュールと拡張電処ヘルパーが連携して担う
電子署名モジュールはHPKIカードによるローカル署名と、FIDO認証・HPKIカード認証・マイナンバーカード認証によるリモート署名を担う
処方・調剤情報が管理サービスに蓄積されることで、医療機関・薬局をまたいだ重複投薬等チェックが可能になる
オン資の資格確認結果テーブルには処方箋発行形態の項目(SHO_SHOHO_KEITAIとXML定義のPrescriptionIssueSelect)があり、2022年7月に追加された
受付で決まった発行形態は、tbl_shoho_kanri.SHOHO_KEITAIとして処方箋1枚ごとに確定する
処方箋発行形態(電子/紙)の選択がオン資の結果に含まれるのは、患者がマイナ保険証で受付した場合に限られる
電子処方箋は、2001年から存在した処方箋QRコード出力の運用を土台に、データの置き場所と取得経路を全国共通の管理サービスへ標準化したものである
電子カルテを発行主体にしない構成では、電子カルテのオーダーが日レセAPIを介してORCAへ連携され、tbl_shoho_kanriで処方が管理される
電子カルテのオーダー(診療行為・中途データ登録)は日レセAPIを介してORCAへ連携される