(57)【要約】【課題】実運用が可能な電子処方せんを実現する。【解決手段】処方せんデータを患者と関連付けて記憶するブロックチェーンデータベースが、所定の患者が操作する第１端末から、前記所定の患者を担当する医師の前記ブロックチェーンデータベース内の前記所定の患者のレコードへの一時的なアクセス権限を付与する第１のトランザクションを受信し、前記アクセス権限を付与された前記医師が操作する第２端末から出力された第２のトランザクションに含まれる前記処方せんデータを、前記所定の患者と関連付けて記憶すること、を含むことを特徴とする電子処方せん管理方法。【選択図】図１
2019185642.tif 000002
【特許請求の範囲】
【請求項１】
処方せんデータを患者と関連付けて記憶するブロックチェーンデータベースが、
所定の患者が操作する第１端末から、前記所定の患者を担当する医師の前記ブロックチェーンデータベース内の前記所定の患者のレコードへの一時的なアクセス権限を付与する第１のトランザクションを受信し、
前記アクセス権限を付与された前記医師が操作する第２端末から出力された第２のトランザクションに含まれる前記処方せんデータを、前記所定の患者と関連付けて記憶すること、
を含むことを特徴とする電子処方せん管理方法。
【請求項２】
前記第１端末から、前記所定の患者を担当する薬剤師の前記ブロックチェーンデータベース内の前記所定の患者のレコードへの一時的なアクセス権限を付与する第３のトランザクションを受信し、
前記アクセス権限を付与された前記薬剤師が操作する第３端末による前記所定の患者に関する前記処方せんデータの参照を許可し、
前記第３端末から出力された第４のトランザクションに含まれる調剤データを前記所定の患者と関連付けて記憶すること、
を更に含むことを特徴とする請求項１に記載の電子処方せん管理方法。
【請求項３】
処方せんデータを患者と関連付けて記憶するブロックチェーンデータベースと、
患者操作に応じて、所定の患者を担当する医師の前記ブロックチェーンデータベース内の前記所定の患者のレコードへの一時的なアクセス権限を許容する第１のトランザクションを出力する第１端末と、
前記医師の操作に応じて、前記処方せんデータを含む第２のトランザクションを出力する第２端末と、を含み、
前記ブロックチェーンデータベースは、前記アクセス権限を付与された前記医師に対応する前記第２端末から出力された前記第２のトランザクションに含まれる前記処方せんデータを前記所定の患者と関連付けて記憶すること、
を特徴とする電子処方せん管理システム。
【請求項４】
前記第１端末は、前記患者操作に応じて、前記所定の患者を担当する薬剤師の前記ブロックチェーンデータベース内の前記所定の患者のレコードへの一時的なアクセス権限を許容する第３のトランザクションを出力し、
前記電子処方せん管理システムは、薬剤師の操作に応じて、前記処方せんデータの参照要求、又は調剤データを含む第４のトランザクションを出力する第３端末を更に含み、
前記ブロックチェーンデータベースは、前記アクセス権限を付与された薬剤師に対応する前記第３端末による前記所定の患者に関する前記処方せんデータの参照を許可するとともに、前記第３端末から出力された第４のトランザクションに含まれる前記調剤データを前記所定の患者と関連付けて記憶すること、
を特徴とする請求項３に記載の電子処方せん管理システム。
【請求項５】
処方せんデータを患者と関連付けて記憶するブロックチェーンデータベースにアクセス可能であり、所定の患者が操作する端末に対して、
医師による診察の際には前記医師に前記ブロックチェーンデータベース内の前記所定の患者のレコードへのアクセス権限を付与するトランザクションを、及び、前記所定の患者を担当する薬剤師による調剤の際には前記薬剤師に前記レコードへの前記アクセス権限を付与するトランザクションを、それぞれ前記ブロックチェーンデータベースに出力するステップと、
前記診察及び前記調剤がそれぞれ終了すると、付与した前記アクセス権限を剥奪するトランザクションを前記ブロックチェーンデータベースに出力するステップと、
を実行させるプログラム。
【請求項６】
処方せんデータを患者と関連付けて記憶するブロックチェーンデータベースと通信可能な医師端末に対して、
医師操作に応じて所定の患者に関する処方せんデータを取得するステップと、
前記ブロックチェーンデータベース内の前記所定の患者のレコードへの一時的なアクセス権限が付与された状態で、前記所定の患者に関する前記処方せんデータを含むトランザクションを前記ブロックチェーンデータベースに出力するステップと、
を実行させるプログラム。
【請求項７】
処方せんデータを患者と関連付けて記憶するブロックチェーンデータベースと通信可能な薬剤師端末に対して、
前記ブロックチェーンデータベース内の前記所定の患者のレコードへの一時的なアクセス権限が付与された状態で、
所定の患者に関する前記処方せんデータの参照を前記ブロックチェーンデータベースに要求するステップと、
薬剤師の操作に応じて前記所定の患者に関する調剤データを取得するステップと、
前記所定の患者に関する前記調剤データを含むトランザクションを前記ブロックチェーンデータベースに出力するステップと、
を実行させるプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、処方せんの電磁的記録による作成、交付及び保存を実施するための電子処方せん管理方法、電子処方せん管理システム、及びプログラムに関する。
【背景技術】
【０００２】
厚生労働省の平成２８年３月３１日付通知により、制度上は電子処方せんの実施が可能となった。これを受けて、一般社団法人  保険医療福祉情報システム工業会（ＪＡＨＩＳ）は、電子処方せんの実装上の仕様を取りまとめた（例えば、非特許文献１参照）。
【０００３】
この実装ガイドは、ＡＳＰサーバの活用を前提とし、患者、医療機関及び薬局とＡＳＰサーバとの間のトランザクションを記述している。
【先行技術文献】
【非特許文献】
【０００４】
【非特許文献１】一般社団法人  保険医療福祉情報システム工業会「ＪＡＨＩＳ  電子処方せん実装ガイド  Ｖｅｒ．１．０」２０１７年５月
【発明の概要】
【発明が解決しようとする課題】
【０００５】
しかしながら、この実装ガイドが自ら認めているとおり、この実装ガイドだけでは対応の難しい課題が存在し、この実装ガイドに基づいて電子処方せんを実装しても実運用に供するのは困難である。このように、電子処方せんの実現には種々の課題が残っている。
【０００６】
そこで、本発明は、ＡＳＰサーバを用いずとも、実運用が可能な電子処方せんを実現することができる電子処方せん管理方法、電子処方せん管理システム、及びプログラムを提供することを目的とする。
【課題を解決するための手段】
【０００７】
上述した課題を解決すべく、本発明の第１の態様は、処方せんデータを患者と関連付けて記憶するブロックチェーンデータベースが、所定の患者が操作する第１端末から、前記所定の患者を担当する医師の前記ブロックチェーンデータベース内の前記所定の患者のレコードへの一時的なアクセス権限を付与する第１のトランザクションを受信し、前記アクセス権限を付与された前記医師が操作する第２端末から出力された第２のトランザクションに含まれる前記処方せんデータを、前記所定の患者と関連付けて記憶すること、を含むことを特徴とする電子処方せん管理方法を提供する。
ここで、処方せんデータは処方の内容を示すデータであり、典型的には処方せんＣＤＡデータであるが、例えば、医師が作成した処方データ自体でもよいし、処方せんＣＤＡデータをＰＤＦファイルに出力したものでもよいものとする。
【０００８】
上記のような構成を有する本発明の電子処方せん管理方法は、前記第１端末から、前記所定の患者を担当する薬剤師の前記ブロックチェーンデータベース内の前記所定の患者のレコードへの一時的なアクセス権限を付与する第３のトランザクションを受信し、前記アクセス権限を付与された前記薬剤師が操作する第３端末による前記所定の患者に関する前記処方せんデータの参照を許可し、前記第３端末から出力された第４のトランザクションに含まれる調剤データを前記所定の患者と関連付けて記憶すること、を更に含んでいてもよい。
ここで、調剤データは、調剤結果を示すデータであり、典型的には調剤ＣＤＡデータであるが、例えば、薬剤師が作成した調剤結果自体でもよいし、調剤ＣＤＡデータをＰＤＦファイルに出力したものでもよいものとする。
【０００９】
また、本発明の第２の態様は、処方せんデータを患者と関連付けて記憶するブロックチェーンデータベースと、患者操作に応じて、所定の患者を担当する医師の前記ブロックチェーンデータベース内の前記所定の患者のレコードへの一時的なアクセス権限を許容する第１のトランザクションを出力する第１端末と、前記医師の操作に応じて、前記処方せんデータを含む第２のトランザクションを出力する第２端末と、を含み、前記ブロックチェーンデータベースは、前記アクセス権限を付与された前記医師に対応する前記第２端末から出力された前記第２のトランザクションに含まれる前記処方せんデータを前記所定の患者と関連付けて記憶すること、を特徴とする電子処方せん管理システムを提供する。
【００１０】
上記のような構成を有する本発明の電子処方せん管理システムは、前記第１端末は、前記患者操作に応じて、前記所定の患者を担当する薬剤師の前記ブロックチェーンデータベース内の前記所定の患者のレコードへの一時的なアクセス権限を許容する第３のトランザクションを出力し、前記電子処方せん管理システムは、薬剤師の操作に応じて、前記処方せんデータの参照要求、又は調剤データを含む第４のトランザクションを出力する第３端末を更に含み、前記ブロックチェーンデータベースは、前記アクセス権限を付与された薬剤師に対応する前記第３端末による前記所定の患者に関する前記処方せんデータの参照を許可するとともに、前記第３端末から出力された第４のトランザクションに含まれる前記調剤データを前記所定の患者と関連付けて記憶してもよい。
【００１１】
本発明の第３の態様は、処方せんデータを患者と関連付けて記憶するブロックチェーンデータベースにアクセス可能であり、所定の患者が操作する端末に対して、医師による診察の際には前記医師に前記ブロックチェーンデータベース内の前記所定の患者のレコードへのアクセス権限を付与するトランザクションを、及び、前記所定の患者を担当する薬剤師による調剤の際には前記薬剤師に前記レコードへの前記アクセス権限を付与するトランザクションを、それぞれ前記ブロックチェーンデータベースに出力するステップと、前記診察及び前記調剤がそれぞれ終了すると、付与した前記アクセス権限を剥奪するトランザクションを前記ブロックチェーンデータベースに出力するステップと、を実行させるプログラムを提供する。
【００１２】
本発明の第４の態様は、処方せんデータを患者と関連付けて記憶するブロックチェーンデータベースと通信可能な医師端末に対して、医師操作に応じて所定の患者に関する処方せんデータを取得するステップと、前記ブロックチェーンデータベース内の前記所定の患者のレコードへの一時的なアクセス権限が付与された状態で、前記所定の患者に関する前記処方せんデータを含むトランザクションを前記ブロックチェーンデータベースに出力するステップと、を実行させるプログラムを提供する。
【００１３】
本発明の第５の態様は、処方せんデータを患者と関連付けて記憶するブロックチェーンデータベースと通信可能な薬剤師端末に対して、前記ブロックチェーンデータベース内の前記所定の患者のレコードへの一時的なアクセス権限が付与された状態で、所定の患者に関する前記処方せんデータの参照を前記ブロックチェーンデータベースに要求するステップと、薬剤師の操作に応じて前記所定の患者に関する調剤データを取得するステップと、前記所定の患者に関する前記調剤データを含むトランザクションを前記ブロックチェーンデータベースに出力するステップと、を実行させるプログラムを提供する。
【発明の効果】
【００１４】
本発明によれば、ＡＳＰサーバを用いずとも、実運用が可能な電子処方せんを実現することができる。
【図面の簡単な説明】
【００１５】
【図１】本発明の代表的な実施形態に係る電子処方せん管理システム１の全体構成図である。
【図２】図１の患者端末、病院情報システム、医師端末、薬局システム及び薬剤師端末としてのコンピュータ、並びにブロックチェーンを構成するコンピュータのハードウェア構成の一例を示すブロック図である。
【図３】患者端末１０のソフトウェア構成の一例を示すブロック図である。
【図４】病院情報システム２０のソフトウェア構成の一例を示すブロック図である。
【図５】医師端末３０のソフトウェア構成の一例を示すブロック図である。
【図６】薬局システム４０のソフトウェア構成の一例を示すブロック図である。
【図７】薬剤師端末５０のソフトウェア構成の一例を示すブロック図である。
【図８】ブロックチェーンにおけるトランザクションの概念図である。
【図９】ブロックチェーンの説明図である。
【図１０】トランザクション構造の一例を示す図である。
【図１１】ステートデータベース（ＤＢ）のデータテーブルの一例を示す図である。
【図１２】診療時におけるステートＤＢの状態遷移の一例を示す図である。
【図１３】調剤時におけるステートＤＢの状態遷移の一例を示す図である。
【図１４】診察時の処理フローを示すフローチャートである。
【図１５】調剤時の処理フローを示すフローチャートである。
【発明を実施するための形態】
【００１６】
以下、本発明の代表的な実施形態を、図面を参照しつつ詳細に説明する。ただし、本発明はこれら図面に限定されるものではない。また、図面は、本発明を概念的に説明するためのものであるから、理解容易のために、必要に応じて寸法、比又は数を誇張又は簡略化して表している場合もある。
【００１７】
［電子処方せん管理システムの全体構成］
図１を参照して、本実施形態に係る電子処方せん管理システム１の全体構成例を説明する。
電子処方せん管理システム１は、処方せんの電磁的記録による作成、交付及び保存を実施するためのコンピュータシステムである。電子処方せん管理システム１では、患者側からの一時的なアクセス権限の付与により、医師側から処方せんデータをブロックチェーン内に保存するとともに、薬剤師側から当該処方せんデータを参照して調剤データをブロックチェーン内に保存することができる。
【００１８】
かかる電子処方せん管理システム１は、患者端末１０（第１端末）、病院情報システム２０、医師端末３０（第２端末）、薬局システム４０、薬剤師端末５０（第３端末）及びブロックチェーン６０を含んで構成されている。患者端末１０、病院情報システム２０、医師端末３０、薬局システム４０及び薬剤師端末５０は、それぞれブロックチェーン６０と有線又は無線で通信可能に接続されている。これらの各構成要素はいずれも、１台又は複数台のコンピュータであり、例えばデスクトップ型、ラップトップ型、タブレット型、携帯型など、任意のタイプのコンピュータでよい。
【００１９】
図２は、患者端末、病院情報システム、医師端末、薬局システム、薬剤師端末、及び、ブロックチェーンを構成するコンピュータの、ハードウェア構成の一例を示すブロック図である。これらコンピュータのそれぞれは、ＣＰＵ１０１、メモリ１０２、記憶装置１０３、通信装置１０４、入力装置１０５及び出力装置１０６を含んで構成されている。
【００２０】
ＣＰＵ１０１は、各種プログラム及びデータをメモリ１０２に読み出して実行することで、追って述べるように患者端末、病院情報システム、医師端末、薬局システム、薬剤師端末及びブロックチェーン（ノード）としての各種機能を実現する。記憶装置１０３は、各種のデータやプログラムを記憶する、例えばハードディスクドライブやソリッドステートドライブ、フラッシュメモリなどである。
【００２１】
通信装置１０４は、有線及び無線の通信ネットワークに接続するためのインタフェースであり、例えばイーサネット（登録商標）に接続するためのアダプタ、公衆電話回線網に接続するためのモデム、無線通信を行うための無線通信機、シリアル通信のためのＵＳＢ（Universal Serial Bus）コネクタやＲＳ２３２Ｃコネクタなどである。
【００２２】
入力装置１０５は、データを入力する、例えばキーボード、マウス、タッチパネル、ボタン、マイクロフォンなどである。出力装置１０６は、データを出力する、例えばディスプレイ、プリンタ、スピーカなどである。
【００２３】
［患者端末］
図３を参照して、患者端末１０のソフトウェア構成例を説明する。
患者端末１０は、患者、その親権者及び後見人（以下、これらのうちの一部又は全部を単に「患者」ということがある。）が使用する端末であり、第１端末の一例である。患者端末１０は、チェックイン部１１、保存領域確認部１２、暗号鍵生成部１３、暗号鍵記憶部１４及びアクセス権限付与部１５を含む。ただし、患者端末１０の持つ機能の一部を他の構成要素に委譲させてもよいものとする。例えば、保存領域確認部１２に相当する機能をブロックチェーン６０の代替ノードに持たせてもよい。
【００２４】
チェックイン部１１は、患者の操作に応じて、病院情報システム２０及び薬局システム４０にチェックインし及びチェックアウトする。病院情報システム２０へのチェックインにより、電子処方せんの発行が可能となる。電子処方せんの発行に先立ち、医師による診療（遠隔診療でもよい）が実施されてもよい。また、薬局システム４０へのチェックインにより、例えば、薬剤師による電子処方せんの参照及び調剤が可能となる。
【００２５】
保存領域確認部１２は、該当する患者の処方せん保存領域がブロックチェーン６０内に存在するかどうかをチェックし、該当する処方せん保存領域が存在しない場合に、必要な処方せん保存領域をブロックチェーン６０内に生成させる。
【００２６】
具体的には、保存領域のチェックは、例えば、患者を特定する情報（以下、「患者ＩＤ」という。）がステートＤＢ（図１１参照）に記憶されているかどうかを、ブロックチェーン６０内のノードコンピュータ（以下、単に「ノード」という。）に検索させることによって行う。また、保存領域の生成は、例えば、患者ＩＤを含むトランザクションをノードにブロードキャストすることによって行う。このようなトランザクションがブロックに纏められ、そのブロックがブロックチェーン６０内で承認されることで、該当する患者ＩＤが電子処方せん管理システム１内で利用可能となる。
【００２７】
暗号鍵生成部１３は、処方せん暗号鍵を生成し、暗号鍵記憶部１４に保存する。処方せん暗号鍵は、例えばトランザクションの生成のために利用されるものであり、患者に固有の公開鍵及び秘密鍵を含む。
【００２８】
アクセス権限付与部１５は、患者以外の関係者（例えば医師、薬剤師）に対して、ブロックチェーン６０内の当該患者の処方せん保存領域へのアクセス権限を付与し及び剥奪する。例えば、アクセス権限付与部１５は、チェックイン部１１の状態（医師による診察のために病院情報システム２０にチェックインしているか、薬剤師による調剤のために薬局システム４０にチェックインしているか）に応じて、医師及び薬剤師のいずれかに権限を付与するトランザクションを出力する。これらのトランザクションは、それぞれ第１及び第３のトランザクションに対応する。本実施形態では、アクセス権限の付与のためのトランザクションに、後述する医師ＩＤ又は薬剤師ＩＤを含めることとしている。
アクセス権限付与部１５はまた、付与したアクセス権限を剥奪する。本実施形態では、アクセス権限の剥奪は会計処理後に行われるが、処方せんデータ（処方せんＣＤＡデータ）又は調剤データ（調剤ＣＤＡデータ）の送信後、遅滞なく行われればよい。
【００２９】
［病院情報システム］
図４を参照して、病院情報システム２０のソフトウェア構成例を説明する。
病院情報システム２０は、医療機関の情報管理を担うシステムであり、例えば遠隔診療システム、電子カルテシステム、オーダエントリシステム及び医事会計システムを含んでいてもよい。かかる病院情報システム２０は、受付部２１、患者情報記憶部２２、診療録記憶部２３、処方せんＣＤＡ生成部２４及び会計処理部２５を含む。
【００３０】
受付部２１は、患者端末１０からのチェックイン及び医師端末３０からの受付入力を受け付ける。受付部２１の処理が完了すると、医師による診療（遠隔診療でもよい）及び処方せん発行が可能となる。本実施形態では、前提として、例えば患者ＩＤ、氏名、住所などの患者情報が予め患者情報記憶部２２に記憶されていることを想定しているが、受付部２１は、チェックインの都度、患者情報の入力を要求してもよい。
【００３１】
診療録記憶部２３は、医師端末３０からの入力に基づき、患者ごとに診療録（カルテ）データを記憶している。ここでは、診療録として、医師が患者の診療内容・経過などを記載する文書を想定しているが、広く診療に関する諸記録を含むものとしてもよい。
【００３２】
処方せんＣＤＡ生成部２４は、医師端末３０からの処方せんデータに基づいて処方せんＣＤＡデータを生成し出力する。ここで、処方せんデータは、患者の氏名、医師の氏名、医療機関の名称・住所、交付年月日、処方内容を含むものとし、更に保険に関する情報や後発医薬品への変更の可否などの付帯情報を含んでいてもよい。また、処方せんＣＤＡ(Clinical Document Architecture)データは、処方せんデータを所定のデータ構造で記述したものである。ここでいう所定のデータ構造としては、例えば、ＨＬ７(Health Level Seven)協会が策定したＨＬ７  ＣＤＡやＨＬ７  ＣＤＡ  Ｒ２といった標準規約に従うことを想定しているが、本発明はこれに限られるものではない。
【００３３】
会計処理部２５は、患者端末１０及び医師端末３０からの指示に基づき、例えば診療報酬の計算や請求などの会計処理を行う。
【００３４】
［医師端末］
図５を参照して、医師端末３０のソフトウェア構成例を説明する。
医師端末３０は、医師及び歯科医師（以下、単に「医師」と言う。）が利用する端末であり、第２端末の一例である。医師端末３０は、受付部３１、診療録作成部３２、処方せん発行部３３、処方せんＣＤＡ記憶部３４及び処方せんＣＤＡ送信部３５を含む。
【００３５】
受付部３１は、病院情報システム２０に対して受付処理を行う。受付処理は、例えば、患者を氏名やＩＤなどにより特定して行われる。
【００３６】
診療録作成部３２は、医師の入力に基づいて診療録データを作成し、病院情報システム２０に出力する。
処方せん発行部３３は、医師の入力に基づいて処方せんデータを生成し、病院情報システム２０に出力する。
【００３７】
処方せんＣＤＡ記憶部３４は、病院情報システム２０から受信した処方せんＣＤＡデータを記憶する。
【００３８】
処方せんＣＤＡ送信部３５は、処方せんＣＤＡデータに担当医師（処方医）の電子署名を付与し、これをブロックチェーン６０内に保存させる。ただし、患者から処方医にブロックチェーン６０へのアクセス権限が与えられていることが前提となる。
【００３９】
具体的には、処方せんＣＤＡ送信部３５は、患者ＩＤ及び処方せんＣＤＡデータを含むトランザクション（第３のトランザクション）を生成し、これをブロックチェーン６０内のノードにブロードキャストする。当該トランザクションを含むブロックがブロックチェーン６０内で承認されると、当該処方せんＣＤＡデータはブロックチェーン６０内に保存されることになる。
【００４０】
［薬局システム］
図６を参照して、薬局システム４０のソフトウェア構成例を説明する。
薬局システム４０は、薬局の情報管理を担うシステムであり、例えば調剤システム及び調剤レセコン（レセプトコンピュータ）を含んでいてもよい。薬局システム４０は、受付部４１、患者情報記憶部４２、処方せん記憶部４３、調剤ＣＤＡ生成部４４及び会計処理部４５を含む。
【００４１】
受付部４１は、患者端末１０からのチェックイン及び薬剤師端末５０からの受付入力を受け付ける。受付部４１の処理が完了すると、薬剤師によるブロックチェーン６０内の処方せんデータの取得、調剤及び調剤データの作成が可能となる。本実施形態では、前提として、例えば患者ＩＤ、氏名、住所などの患者情報が予め患者情報記憶部４２に記憶されていることを想定しているが、受付部４１は、チェックインの都度、患者情報の入力を要求してもよい。
【００４２】
処方せん記憶部４３は、薬剤師端末５０において取得した処方せんＣＤＡデータを記憶する。
【００４３】
調剤ＣＤＡ生成部４４は、薬剤師端末５０からの調剤データに基づいて調剤ＣＤＡデータを生成し、薬剤師端末５０に出力する。ここで、調剤データは、患者情報、調剤行為実施日付、調剤行為実施者、対応する処方せんの情報、及び調剤実施情報を含む。調剤実施情報は、薬局の名称・住所、薬剤及び払い出した薬剤の量を含む。また、調剤ＣＤＡ(Clinical Document Architecture)データは、調剤データを所定のデータ構造で記述したものである。ここでいう所定の構造としては、例えば、上述した標準規約に従うことを想定しているが、本発明はこれに限られるものではない。
【００４４】
会計処理部４５は、患者端末１０及び薬剤師端末５０からの指示に基づき、調剤費用の計算及び請求などの会計処理を行う。
【００４５】
［薬剤師端末］
図７を参照して、薬剤師端末５０のソフトウェア構成例を説明する。
薬剤師端末５０は、薬剤師が利用する端末であり、第３端末の一例である。薬剤師端末５０は、受付部５１、処方せん参照部５２、調剤情報発行部５３、調剤ＣＤＡ記憶部５４及び調剤ＣＤＡ送信部５５を含む。
【００４６】
受付部５１は、薬局システム４０に対して受付処理を行う。受付処理は、例えば、患者を氏名やＩＤなどにより特定して行われる。
【００４７】
処方せん参照部５２は、ブロックチェーン６０内の処方せんＣＤＡデータを参照する。具体的には、処方せん参照部５２は患者ＩＤをキーとしてノードのステートＤＢを検索させ、調剤済みでない処方せんＣＤＡデータを取得する。ただし、患者から薬剤師にブロックチェーン６０へのアクセス権限が与えられていることが前提となる。
【００４８】
調剤情報発行部５３は、薬剤師の入力に基づいて調剤データを生成し、薬局システム４０に出力する。
調剤ＣＤＡ記憶部５４は、薬局システム４０から受信した調剤ＣＤＡデータを記憶する。
【００４９】
調剤ＣＤＡ送信部５５は、調剤ＣＤＡデータをブロックチェーン６０内に保存させる。具体的には、調剤ＣＤＡ送信部５５は、患者ＩＤ及び調剤ＣＤＡデータを含むトランザクション（第４のトランザクション）を生成し、これをブロックチェーン６０内のノードにブロードキャストする。当該トランザクションを含むブロックがブロックチェーン６０内で承認されると、当該調剤ＣＤＡデータはブロックチェーン６０内に保存されることになる。
【００５０】
［ブロックチェーン］
図８−図１３を参照してブロックチェーン６０を説明する。
ブロックチェーン６０は、複数のノードから構成される非中央集権型（Ｐ２Ｐ）のネットワークシステムにおいて、各ノードが保持する台帳の役割を果たすデータストアないしデータベースに相当する。本実施形態では、イーサリアム型のブロックチェーンを想定しているが、本発明はこれに限られるものではない。
【００５１】
図８及び図９を参照して、ブロックチェーン及びトランザクションについて概説する。一般に、ブロックチェーンでは、取引履歴が、取引を含むブロックの連鎖として表現される。
【００５２】
図８に示すように、それぞれの取引（トランザクション）では、前のトランザクションのハッシュ値や、新たなトランザクションのユーザの公開鍵を含み、元のトランザクションのユーザの暗号鍵によってデジタル署名されている。全てのトランザクションに関する情報は、Ｐ２Ｐネットワーク全体で共有される。このようにトランザクションを表現することで、元のトランザクションのユーザの許可なく、本人以外が勝手に書き換えたり削除したりすることはできず、また、第三者は、取引経過を客観的に確認できる。
【００５３】
図９に示すように、ブロックチェーンを構成する各ブロックは、多数のトランザクションと、ナンスと呼ばれる特別な値と、直前のブロックのハッシュと、を有している。そして、ブロックに含まれたトランザクションのみを「正しい取引」と認め、ネットワーク全体で「唯一のブロックの鎖」を持つようにすることで、一貫した取引履歴をネットワーク全体で共有することができる。
【００５４】
次いで、図１０を参照して、本実施形態におけるトランザクションの構造を説明する。
各トランザクションは、送り主のアドレス、送り主の署名、及びデータの各フィールドを含んでいる。送り主のアドレスは、ブロックチェーン６０における患者、医師又は薬剤師のアドレスであり、例えば、これらの者の保有する公開鍵にハッシュ関数を適用して算出した値を示すものである。また、送り主の署名は、送り主を示す署名値（暗号化されたダイジェスト値）である。
【００５５】
各トランザクションの「データ」フィールドは、患者ＩＤ、医師・薬剤師ＩＤ、アクセス権限、ＣＤＡデータを含むことができる。データは更に、ＧＡＳに関する情報を含んでいてもよいが、ＧＡＳは例えば電子処方せん管理システム１の管理者又はブロックチェーン６０のプラットフォーム提供者によって支払われるものとしてもよい。
【００５６】
ここで、患者ＩＤは、患者を特定する情報である。本実施形態では、患者ＩＤとして、その患者に対するブロックチェーン６０でのアドレスを想定しているが、例えば個人番号のように住民毎に付与される固有の番号でもよい。同様に、医師・薬剤師ＩＤは、特定の医師又は薬剤師を特定する情報であり、本実施形態では、その医師又は薬剤師に対するブロックチェーン６０でのアドレスを想定している。
【００５７】
アクセス権限は、患者ごとに、その患者が、ブロックチェーン６０内の自己のレコードへのアクセスを一時的に許可する特定の医師又は薬剤師を示す情報であり、例えば医師ＩＤ又は薬剤師ＩＤで示される。なお、アクセス権限の項目に記述がないことは、第三者にその患者のレコードへのアクセス権限がないことを意味する。
ＣＤＡデータは、処方せんＣＤＡデータ又は調剤ＣＤＡデータを指す。
【００５８】
そして、本実施形態におけるブロックチェーン６０は、上述したトランザクションを含む一連のブロックを保存するとともに、患者毎のレコードを管理するためのステートデータベース（ＤＢ）を保持している。
【００５９】
図１１を参照してステートＤＢを説明すると、このデータベースは、患者毎の処方せんデータ（処方せんＣＤＡデータ）及び調剤データ（調剤ＣＤＡデータ）を管理するものである。本実施形態では、ステートＤＢは、患者ＩＤを、処方せんＣＤＡデータ又は調剤ＣＤＡデータ、アクセス権限及びステータスと関連付けて記憶している。ここで、ステータスは、処方待ち、処方済み、調剤済みといった、処方及び調剤の進捗状況を示す。
【００６０】
処方せんの発行及び調剤が行われると、所定の手続きを経てステートＤＢが更新される。したがって、ステートＤＢを参照することで、当該患者に対する処方及び調剤の履歴を知ることができる。なお、図１１における「処方せん（調剤）データ１」「処方せん（調剤）データ２」等は、処方せんＣＤＡデータ（調剤ＣＤＡデータ）に含まれる日付、病院（薬局）、医師（薬剤師）などの情報に基づいて識別されるものとする。
【００６１】
次いで、図１２及び図１３を参照して、ステートＤＢの状態遷移について説明する。ここでは、特定の患者（患者ＩＤ：０００１）に対する最新のレコードに着目することとし、ステートＤＢ内の他のレコードを省略している。また、患者端末１０は、所定の患者を担当する医師及び薬剤師のＩＤを記憶しており、担当医師の医師端末３０及び担当薬剤師の薬剤師端末５０はその患者のＩＤを記憶していることを前提とする。
【００６２】
まず、図１２を参照して、診療時のステートＤＢの状態遷移について述べる。
所定の患者が患者端末１０を介して病院情報システム２０にチェックインすると、ステートＤＢにこの患者ＩＤに対する新たなレコードが作成され、ステータス「処方待ち」、アクセス権限「なし」及びＣＤＡデータ「なし」が記録される。
【００６３】
次いで、所定の患者が、患者端末１０を介して、その患者の担当医師に一時的にアクセス権限を付与すると、ステートＤＢにおける該当するレコードのアクセス権限欄にその医師のＩＤが追加される。これにより、担当医師の操作する医師端末３０がブロックチェーン６０にアクセスすることが許可される一方、担当医師以外の第三者は引き続きブロックチェーン６０へのアクセスを拒絶される。ここで、アクセス権限の付与は、例えば、患者端末１０が、患者ＩＤ及び医師ＩＤを含むトランザクションをブロードキャストすることにより行われる。
【００６４】
医師による診断及び処方せんの作成後、医師端末３０は、ブロックチェーン６０にアクセスし、所定の患者のレコードに処方せんＣＤＡデータを保存する。その際、このレコードのステータスは「処方済み」に書き換えられる。ここで、処方せんＣＤＡデータの保存は、例えば、医師端末３０が、患者ＩＤ、医師ＩＤ及び処方せんＣＤＡデータを含むトランザクションをブロードキャストすることにより行われる。なお、かかるレコードの更新がブロックチェーン６０内で反映されるのは、このトランザクションを含むブロックがブロックチェーン６０内で承認された際である。
【００６５】
そして、会計処理が終了すると、患者端末１０は医師へのアクセス権限を剥奪する。アクセス権限の剥奪は、例えば、患者端末１０が、患者ＩＤ及びアクセス権限「なし」を含むトランザクションをブロードキャストすることにより行われる。
【００６６】
このように患者側から担当医師に自己のレコードへの一時的なアクセス権限を付与することで、全体として秘密状態を確保しながら、医師側からブロックチェーン６０にその患者の処方せんデータを記録することが可能となる。
【００６７】
次いで、図１３を参照して、調剤時のステートＤＢの状態遷移について述べる。ここでは、当該患者に対して新たな（未調剤の）処方せんデータがブロックチェーン６０に記録されていることを前提として説明を行う。
【００６８】
所定の患者が、患者端末１０を介して薬局システム４０にチェックインし、その患者の担当薬剤師に一時的なアクセス権限を付与すると、ステートＤＢにおける該当するレコードのアクセス権限欄にその薬剤師のＩＤが追加される。これにより、薬剤師端末５０がブロックチェーン６０にアクセスすることが許可される一方、担当薬剤師以外の第三者はブロックチェーン６０へのアクセスを拒絶される。ここで、アクセス権限の付与は、例えば、患者端末１０が、患者ＩＤ及び薬剤師ＩＤを含むトランザクションをブロードキャストすることにより行われる。
【００６９】
薬剤師端末５０は、ブロックチェーン６０にアクセスし、該当する患者のレコード中の処方せんＣＤＡデータを参照（取得）する。該当する患者のレコード中に複数の処方せんＣＤＡデータが保存されている場合には、薬剤師端末５０は少なくとも、未調剤の処方せんＣＤＡデータ、つまりステータス「処方済み」に対応する処方せんＣＤＡデータを参照すればよい。
【００７０】
調剤が行われて新たな調剤ＣＤＡデータが生成されると、薬剤師端末５０はブロックチェーン６０にアクセスし、新たな調剤ＣＤＡデータを追加保存する。その際、この処方せんＣＤＡデータ及び新たな調剤ＣＤＡデータに対するステータスは「調剤済み」に書き換えられる。ここで、調剤ＣＤＡデータの保存は、例えば、薬剤師端末５０が、患者ＩＤ、薬剤師ＩＤ及び調剤ＣＤＡデータを含むトランザクションをブロードキャストすることにより行われる。
【００７１】
そして、会計処理が終了すると、患者端末１０は薬剤師へのアクセス権限を剥奪する。アクセス権限の剥奪は、例えば、患者端末１０が、患者ＩＤ及びアクセス権限「なし」を含むトランザクションをブロードキャストすることにより行われる。
【００７２】
このように患者側から薬剤師に一時的なアクセス権限を付与することで、全体として秘密状態を確保しながら、薬剤師側からブロックチェーン６０に処方せんデータの参照及び調剤データの記録を行うことが可能となる。
【００７３】
［電子処方せんの管理手順］
図１４及び図１５を参照して、電子処方せんの管理手順を説明する。
【００７４】
図１４を参照して、電子処方せんの発行手順を説明する。この手順は、診察の受付（ＳＴＥＰ１）、診察の実施（ＳＴＥＰ２）及び診察の終了（ＳＴＥＰ３）に分けられる。
【００７５】
ＳＴＥＰ１では、まず、診察予約に従い、患者端末１０及び医師端末３０が病院情報システム２０にアクセスし、病院情報システム２０において受付及び患者登録の処理が行われる。そして、患者端末１０は、処方せん用の暗号鍵を保持しているかどうかを確認し、非保持の場合には暗号鍵を生成する。
【００７６】
次いで、患者端末１０は、ブロックチェーン６０内に当該患者に対する処方せん保存領域が存在するかどうかを確認する。処方せん保存領域の確認は、例えば、患者端末１０からノードに、該当する患者ＩＤの検索させることで行われる。他方、該当する処方せん保存領域がない場合には、患者端末１０は、ブロックチェーン６０に当該患者に対する処方せん保存領域を生成するよう指示する。処方せん保存領域の生成指示は、例えば、患者端末１０が、患者ＩＤを含むトランザクションをブロードキャストすることで行われる。
【００７７】
そして、患者端末１０は、担当医師にブロックチェーン６０内の自己のレコードへのアクセス権限を一時的に付与する。かかる担当医師へのアクセス権限の付与がブロックチェーン６０内で承認されると、担当医師がブロックチェーン６０内のその患者のレコードにアクセス可能な状態となる。
これによりＳＴＥＰ１の処理が終了し、ＳＴＥＰ２の処理に移る。
【００７８】
ＳＴＥＰ２では、医師による診察及び診療録作成の後、医師端末３０は、診療録データを病院情報システム２０に保存させ、次いで病院情報システム２０に処方せんＣＤＡデータの生成を指示する。この生成の指示は、処方内容に関する情報を含んでいる。
【００７９】
病院情報システム２０は、この生成の指示に従い、所定の規約に基づいて処方せんＣＤＡデータを生成し、医師端末３０に出力する。もちろん、病院情報システム２０は、処方せんＣＤＡデータを自らの記憶装置に記憶してもよい。
【００８０】
医師端末３０は、受け取った処方せんＣＤＡデータを自らの記憶装置に記憶するとともにブロックチェーン６０に保存し、ＳＴＥＰ２は終了する。処方せんＣＤＡデータのブロックチェーン６０への保存は、例えば、医師端末３０が、患者ＩＤ及び処方せんＣＤＡデータを含むトランザクションをブロードキャストすることで行われる。なお、アクセス権限のない医師が、その端末からトランザクションをブロードキャストしても、このトランザクションはブロックに組み込まれることなく破棄されることになる。
【００８１】
次いで、ＳＴＥＰ３では、病院情報システム２０は、患者端末１０及び医師端末３０からの指示に基づき、診療報酬の会計処理を行う。併せて、患者端末１０は、担当医師に付与していたアクセス権限を剥奪し、ＳＴＥＰ３が終了する。
【００８２】
このように、適時に担当医師に所定の患者のレコードへの一時的なアクセス権限を付与することで、機密保持を図りながら、医師による処方せんデータのブロックチェーン６０への追加を可能にしている。なお、対面診療の場面でも遠隔診療の場面でも、例えば患者が診察中又は診察後に患者端末１０を操作することで、電子処方せんの発行が可能である。
【００８３】
次に、図１５を参照して調剤手順を説明する。この手順は、調剤の受付（ＳＴＥＰ１）、調剤の実施（ＳＴＥＰ２）及び調剤の終了（ＳＴＥＰ３）に分けられる。
【００８４】
ＳＴＥＰ１では、まず、患者端末１０及び薬剤師端末５０が薬局システム４０にアクセスし、薬局システム４０において受付及び患者登録の処理が行われる。
【００８５】
そして、患者端末１０は、処方せん用の暗号鍵を保持しているかどうかを確認し、保持の場合には、担当薬剤師に対してブロックチェーン６０内の自己のレコードへのアクセス権限を付与する。一方、処方せん用の暗号鍵を非保持の場合、電子処方せんは発行されていないため、患者端末１０は処理を終了し、例えば紙の処方せんを持って薬局に行くように表示する。
【００８６】
このようにして担当薬剤師への一時的なアクセス権限の付与がブロックチェーン６０内で承認されると、担当薬剤師がブロックチェーン６０内のその患者のレコードにアクセス可能な状態となる。
【００８７】
薬剤師端末５０は、ブロックチェーン６０にアクセスし、該当する患者に関する処方せんＣＤＡデータを参照（取得）し、ＳＴＥＰ１が終了する。ここで、薬剤師端末５０は、調剤可能な処方せんＣＤＡデータのみを参照してもよいし、調剤済みの処方せんデータ及び調剤データを含む一覧を参照してもよい。調剤可能な処方せんＣＤＡデータがない場合、つまり、対応する調剤ＣＤＡデータが記録されている処方せんＣＤＡデータや、有効期間の過ぎている処方せんＣＤＡデータだけが記録されている場合には、薬剤師端末５０は、その旨の通知をブロックチェーン６０から受領してもよい。ここでも、アクセス権限を有しない薬剤師によるブロックチェーン６０へのアクセスが許可されないことは言うまでもない。
【００８８】
ＳＴＥＰ２では、薬剤師による調剤及び調剤情報作成の後、薬剤師端末５０は、薬局システム４０に対して調剤情報の処理の開始及び調剤ＣＤＡデータの生成を指示する。この生成の指示は、調剤内容を示す情報を含んでいる。
【００８９】
薬局システム４０は、この生成の指示に従い調剤ＣＤＡデータを生成し、薬剤師端末５０に出力する。もちろん、薬局システム４０は、調剤ＣＤＡデータを自らの記憶装置に記憶してもよい。
【００９０】
薬剤師端末５０は、受け取った調剤ＣＤＡデータを自らの記憶装置に記憶するとともにブロックチェーン６０に保存し、ＳＴＥＰ２は終了する。なお、薬剤師が、アクセス権限のない状態でトランザクションを出力しても、このトランザクションはブロックに組み込まれることなく破棄される。
【００９１】
ＳＴＥＰ３では、薬局システム４０は、患者端末１０及び薬剤師端末５０からの指示に基づき、調剤費用の会計処理を行う。併せて、患者端末１０は、担当薬剤師に付与していたアクセス権限を剥奪し、ＳＴＥＰ３が終了する。
【００９２】
このように、適時に担当薬剤師に所定の患者のレコードへの一時的なアクセス権限を付与することで、機密保持を図りながら、薬剤師による処方せんデータの参照及び調剤データのブロックチェーン６０への追加を可能にしている。
【００９３】
以上のとおり、本実施形態では、実運用が可能な電子処方せん管理システムを提供することができる。しかも、ＡＳＰサーバを利用した電子処方せん管理システムにおいて必要とされている、処方せんＩＤの発行処理や電子処方せん引換証の交付処理、電子処方せん無効化処理などの、複雑な処理が不要となり、簡易なシステム構成を採用することができる。
【００９４】
また、Ｐ２Ｐネットワークシステムで患者の処方せん情報を管理していることから、ＡＳＰサーバによる管理と比べて、障害に対する耐性がある。
【００９５】
なお、電子処方せん管理システム１では、処方せん暗号鍵を生成及び保持できない環境下の患者には電子処方せんの処理はさせず、従来通りの紙ベースでの処理を行わせることとする。つまり、このシステムは、紙の処方せんの運用と併用することが可能である。
【００９６】
以上、本発明の代表的な実施形態について説明したが、本発明はこれらに限定されるものではなく、種々の設計変更が可能であり、それらも本発明に含まれる。
【００９７】
本実施形態では、医師端末３０が、処方せんＣＤＡデータを含むトランザクションを出力するものとしたが、医師端末３０は、例えば、処方せんデータ自体や処方せんＣＤＡデータをＰＤＦファイルに出力したものを、トランザクションに含めて出力してもよい。同様に、薬剤師端末５０は、例えば、調剤データ自体や調剤ＣＤＡデータをＰＤＦファイルに出力したものを、トランザクションに含めて出力してもよい。
【００９８】
本実施形態では、医師端末３０が処方せんデータ（処方せんＣＤＡデータ）をブロックチェーン６０に出力することとしたが、医師端末３０は、病院情報システム２０又はデータ送信用のサブシステムを介して、処方せんデータを出力してもよい。同様に、薬剤師端末５０は、薬局システム４０又はデータ送信用のサブシステムを介して、処方せんデータ（処方せんＣＤＡデータ）を取得し、調剤データ（調剤ＣＤＡデータ）を出力してもよい。
【００９９】
また、患者端末１０、病院情報システム２０、医師端末３０、薬局システム４０及び薬剤師端末５０はそれぞれ、これらのユーザに代替して署名を行うＡＰＩ(Application Programming Interface)サーバを介してブロックチェーン６０と接続してもよい。
【０１００】
本実施形態では、医師又は薬剤師へのアクセス権限の剥奪は患者端末１０からのトランザクションの送信により行っていたが、例えば、所定の時間（例えば３０分、１時間など）だけ有効なアクセス権限を付与することでアクセス権限の剥奪行為を省略してもよい。
【０１０１】
ブロックチェーン６０は、薬剤師端末５０からの調剤データ（調剤ＣＤＡデータ）をデータベースに記憶したときに、その調剤データを、患者の同意の下で担当医師の医師端末３０又は病院情報システム２０に送信してもよい。
【符号の説明】
【０１０２】
１・・・電子処方せん管理システム、
１０・・・患者端末、
２０・・・病院情報システム、
３０・・・医師端末、
４０・・・薬局システム、
５０・・・薬剤師端末、
６０・・・ブロックチェーン。
【図１】
2019185642.tif 000003
【図２】
2019185642.tif 000004
【図３】
2019185642.tif 000005
【図４】
2019185642.tif 000006
【図５】
2019185642.tif 000007
【図６】
2019185642.tif 000008
【図７】
2019185642.tif 000009
【図８】
2019185642.tif 000010
【図９】
2019185642.tif 000011
【図１０】
2019185642.tif 000012
【図１１】
2019185642.tif 000013
【図１２】
2019185642.tif 000014
【図１３】
2019185642.tif 000015
【図１４】
2019185642.tif 000016
【図１５】
2019185642.tif 000017