(57)【要約】【課題】安全性が高く、かつ利便性の高い方法により、医療データを複数のユーザー間で共有可能な分散型医療情報共有システム、医療情報提供サーバー及びプログラムを提供する。【解決手段】医療情報提供サーバーと、医療情報を提供する提供端末と、医療情報を閲覧する閲覧端末と、合意形成処理を行う分散型共有台帳を管理するブロックチェーンノードと、を備えた分散型医療情報共有システムにおいて、提供端末は、医療情報を、第１の秘密鍵を用いて暗号化する暗号化処理部を備え、医療情報提供サーバーは、第１の秘密鍵に対応する第１の公開鍵及び閲覧端末が復号可能なデータに再暗号化するための再暗号化鍵を、ブロックチェーンノードによってブロックに保存させる保存制御部と、暗号化された医療情報を、ブロックに保存された再暗号化鍵によって再暗号化して、前記閲覧端末に提供する再暗号化部と、を備える。【選択図】図１
2020010267.tif 000002
【特許請求の範囲】
【請求項１】
医療情報を記憶する医療情報提供サーバーと、前記医療情報提供サーバーに医療情報を提供する提供端末と、前記医療情報提供サーバーに記憶された医療情報を閲覧する閲覧端末と、合意形成処理を行う分散型共有台帳を管理するブロックチェーンノードと、を備えた分散型医療情報共有システムにおいて、
前記提供端末は、
医療情報を、第１の秘密鍵を用いて暗号化する暗号化処理部を備え、
前記医療情報提供サーバーは、
前記第１の秘密鍵に対応する第１の公開鍵及び前記閲覧端末が復号可能なデータに再暗号化するための再暗号化鍵を、前記ブロックチェーンノードによってブロックに保存させる保存制御部と、
暗号化された医療情報を、ブロックに保存された前記再暗号化鍵によって再暗号化して、前記閲覧端末に提供する再暗号化部と、を備える
ことを特徴とする分散型医療情報共有システム。
【請求項２】
前記提供端末は、
前記第１の公開鍵及び前記第１の秘密鍵を生成する第１の暗号鍵生成部を備える
ことを特徴とする請求項１に記載の分散型医療情報共有システム。
【請求項３】
前記提供端末は、
暗号化された医療情報を、閲覧端末が復号可能なデータに再暗号化するための再暗号化鍵を生成する再暗号化鍵生成部と、を備える
ことを特徴とする請求項１又は２に記載の分散型医療情報共有システム。
【請求項４】
前記再暗号化鍵生成部は、公開先の閲覧端末が変更される場合において、暗号化された医療情報を、新たに閲覧権限を取得した閲覧端末が復号可能なデータに再暗号化するための新規の再暗号化鍵を生成し、
前記再暗号化部は、暗号化された医療情報を、前記新規の再暗号化鍵によって再暗号化して、前記新たに閲覧権限を取得した閲覧端末に提供する
ことを特徴とする請求項３に記載の分散型医療情報共有システム。
【請求項５】
前記医療情報提供サーバーは、
前記提供端末により暗号化された医療情報を記憶する記憶部を備える
ことを特徴とする請求項１から４のいずれか一項に記載の分散型医療情報共有システム。
【請求項６】
前記閲覧端末は、
第２の公開鍵及び第２の秘密鍵を生成する第２の暗号鍵生成部と、
再暗号化された医療情報を、前記第２の公開鍵を用いて復号する復号処理部と、を備える
ことを特徴とする請求項１から５のいずれか一項に記載の分散型医療情報共有システム。
【請求項７】
医療情報を記憶する医療情報提供サーバーと、医療情報を、第１の秘密鍵を用いて暗号化する暗号化処理部を備え、前記医療情報提供サーバーに医療情報を提供する提供端末と、前記医療情報提供サーバーに記憶された医療情報を閲覧する閲覧端末と、合意形成処理を行う分散型共有台帳を管理するブロックチェーンノードと、を備えた分散型医療情報共有システムにおける医療情報提供サーバーであって、
前記医療情報提供サーバーは、
前記第１の秘密鍵に対応する第１の公開鍵及び前記閲覧端末が復号可能なデータに再暗号化するための再暗号化鍵を、前記ブロックチェーンノードによってブロックに保存させる保存制御部と、
暗号化された医療情報を、ブロックに保存された前記再暗号化鍵によって再暗号化して、前記閲覧端末に提供する再暗号化部と、を備える
ことを特徴とする医療情報提供サーバー。
【請求項８】
前記提供端末により暗号化された医療情報を記憶する記憶部を備える
ことを特徴とする請求項７に記載の医療情報提供サーバー。
【請求項９】
医療情報を記憶する医療情報提供サーバーと、医療情報を、第１の秘密鍵を用いて暗号化する暗号化処理部を備え、前記医療情報提供サーバーに医療情報を提供する提供端末と、前記医療情報提供サーバーに記憶された医療情報を閲覧する閲覧端末と、合意形成処理を行う分散型共有台帳を管理するブロックチェーンノードと、を備えた分散型医療情報共有システムにおいて、
前記医療情報提供サーバーのコンピューターを、
前記第１の秘密鍵に対応する第１の公開鍵及び前記閲覧端末が復号可能なデータに再暗号化するための再暗号化鍵を、前記ブロックチェーンノードによってブロックに保存させる保存制御部、
暗号化された医療情報を、ブロックに保存された前記再暗号化鍵によって再暗号化して、前記閲覧端末に提供する再暗号化部、として機能させる
ためのプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、分散型医療情報共有システム、医療情報提供サーバー及びプログラムに関する。
【背景技術】
【０００２】
近年、医療技術の多様化に伴い、特定機能を持つ病院や診療所等の複数の医療施設が医療情報を共有し、連携して患者の検査や治療を行う医療連携が普及しつつある。例えば、連携先の医療施設からしか参照できない医療情報をクラウドにアップロードし、必要な時に医療情報をダウンロードするシステムが利用されている。
【０００３】
このように医療情報をクラウドに保存するサービスにおいては、情報発生源は医療施設のユーザーであり、閲覧権限の制御及び閲覧権限者も医療施設のユーザーとなる。医療情報は個人情報でもあるため、より安全に医療情報の受け渡しが可能なクラウドサービスが求められている。しかし、医療情報を共有するコミュニティーの規模が大きくなるにつれて、中央集権型サーバーによるデータ共有形式であると、管理コストの増大及び障害に対するリスクが増大する問題があるため、分散されたサーバー間でデータを共有する分散方式が必要となる。
【０００４】
上記した問題に関連して、特許文献１には、再暗号化技術を用いたデータ共有方法が開示されている。具体的には、データの再暗号化に使用する暗号鍵の一部を中継サーバーによって生成し、中継サーバーは閲覧権限者の暗号鍵によって参照できるように復号鍵を再生成し、閲覧権限者からの情報要求時にデータを参照して送信する。
また、特許文献２には、再暗号化技術を用いたデータ共有方法において、複数のユーザー間で共有するデータを保持する再暗号化装置を備え、データの送信者は閲覧権限者ごとに再暗号化に使用する公開暗号鍵を入手し、自身の秘密鍵と閲覧権限者の暗号鍵とを使用して、閲覧権限者ごとに暗号化データを作成する方法が用いられている。
このような再暗号化技術を用いたデータ共有方法では、閲覧者以外の者にデータが漏洩するリスクを低減できるため、比較的安全性が高いといえる。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】特開２０１５−５６８２０号公報
【特許文献２】特開２０１６−１３９８９４号公報
【発明の概要】
【発明が解決しようとする課題】
【０００６】
しかしながら、再暗号化技術においては、クラウドサービスの管理者と不正なユーザーの結託により、再暗号化鍵を偽造されるリスクを排除できない。即ち、何らかの理由で鍵が漏洩してしまった場合、閲覧権限者以外の者に向けた再暗号化鍵を生成することが可能となるため、不正なユーザーによって医療情報が閲覧されてしまう虞がある。
また、特許文献２のようにデータの送信者が閲覧権限者毎にデータを暗号化させるものとすると、閲覧権限者が追加される度に送信者の秘密鍵を使用した暗号化及び再暗号化が必要となるため、鍵の管理が煩雑化する。
【０００７】
本発明は上記課題に鑑みてなされたものであって、安全性が高く、かつ利便性の高い方法により、医療データを複数のユーザー間で共有可能な分散型医療情報共有システム、医療情報提供サーバー及びプログラムを提供することを目的とする。
【課題を解決するための手段】
【０００８】
上記課題を解決するため、請求項１に記載の分散型医療情報共有システムは、
医療情報を記憶する医療情報提供サーバーと、前記医療情報提供サーバーに医療情報を提供する提供端末と、前記医療情報提供サーバーに記憶された医療情報を閲覧する閲覧端末と、合意形成処理を行う分散型共有台帳を管理するブロックチェーンノードと、を備えた分散型医療情報共有システムにおいて、
前記提供端末は、
医療情報を、第１の秘密鍵を用いて暗号化する暗号化処理部を備え、
前記医療情報提供サーバーは、
前記第１の秘密鍵に対応する第１の公開鍵及び前記閲覧端末が復号可能なデータに再暗号化するための再暗号化鍵を、前記ブロックチェーンノードによってブロックに保存させる保存制御部と、
暗号化された医療情報を、ブロックに保存された前記再暗号化鍵によって再暗号化して、前記閲覧端末に提供する再暗号化部と、を備える
ことを特徴とする。
【０００９】
請求項２に記載の発明は、請求項１に記載の分散型医療情報共有システムにおいて、
前記提供端末は、
前記第１の公開鍵及び前記第１の秘密鍵を生成する第１の暗号鍵生成部を備える
ことを特徴とする。
【００１０】
請求項３に記載の発明は、請求項１又は２に記載の分散型医療情報共有システムにおいて、
前記提供端末は、
暗号化された医療情報を、閲覧端末が復号可能なデータに再暗号化するための再暗号化鍵を生成する再暗号化鍵生成部と、を備える
ことを特徴とする。
【００１１】
請求項４に記載の発明は、請求項３に記載の分散型医療情報共有システムにおいて、
前記再暗号化鍵生成部は、公開先の閲覧端末が変更される場合において、暗号化された医療情報を、新たに閲覧権限を取得した閲覧端末が復号可能なデータに再暗号化するための新規の再暗号化鍵を生成し、
前記再暗号化部は、暗号化された医療情報を、前記新規の再暗号化鍵によって再暗号化して、前記新たに閲覧権限を取得した閲覧端末に提供する
ことを特徴とする。
【００１２】
請求項５に記載の発明は、請求項１から４のいずれか一項に記載の分散型医療情報共有システムにおいて、
前記医療情報提供サーバーは、
前記提供端末により暗号化された医療情報を記憶する記憶部を備える
ことを特徴とする。
【００１３】
請求項６に記載の発明は、請求項１から５のいずれか一項に記載の分散型医療情報共有システムにおいて、
前記閲覧端末は、
第２の公開鍵及び第２の秘密鍵を生成する第２の暗号鍵生成部と、
再暗号化された医療情報を、前記第２の公開鍵を用いて復号する復号処理部と、を備える
ことを特徴とする。
【００１４】
請求項７に記載の医療情報提供サーバーは、
医療情報を記憶する医療情報提供サーバーと、医療情報を、第１の秘密鍵を用いて暗号化する暗号化処理部を備え、前記医療情報提供サーバーに医療情報を提供する提供端末と、前記医療情報提供サーバーに記憶された医療情報を閲覧する閲覧端末と、合意形成処理を行う分散型共有台帳を管理するブロックチェーンノードと、を備えた分散型医療情報共有システムにおける医療情報提供サーバーであって、
前記医療情報提供サーバーは、
前記第１の秘密鍵に対応する第１の公開鍵及び前記閲覧端末が復号可能なデータに再暗号化するための再暗号化鍵を、前記ブロックチェーンノードによってブロックに保存させる保存制御部と、
暗号化された医療情報を、ブロックに保存された前記再暗号化鍵によって再暗号化して、前記閲覧端末に提供する再暗号化部と、を備える
ことを特徴とする。
【００１５】
請求項８に記載の発明は、請求項７に記載の医療情報提供サーバーにおいて、
前記提供端末により暗号化された医療情報を記憶する記憶部を備える
ことを特徴とする。
【００１６】
請求項９に記載のプログラムは、
医療情報を記憶する医療情報提供サーバーと、医療情報を、第１の秘密鍵を用いて暗号化する暗号化処理部を備え、前記医療情報提供サーバーに医療情報を提供する提供端末と、前記医療情報提供サーバーに記憶された医療情報を閲覧する閲覧端末と、合意形成処理を行う分散型共有台帳を管理するブロックチェーンノードと、を備えた分散型医療情報共有システムにおいて、
前記医療情報提供サーバーのコンピューターを、
前記第１の秘密鍵に対応する第１の公開鍵及び前記閲覧端末が復号可能なデータに再暗号化するための再暗号化鍵を、前記ブロックチェーンノードによってブロックに保存させる保存制御部、
暗号化された医療情報を、ブロックに保存された前記再暗号化鍵によって再暗号化して、前記閲覧端末に提供する再暗号化部、として機能させる
ことを特徴とする。
【発明の効果】
【００１７】
本発明によれば、安全性が高く、かつ利便性の高い方法により、医療データを複数のユーザー間で共有可能な分散型医療情報共有システム、医療情報提供サーバー及びプログラムを提供することができる。
【図面の簡単な説明】
【００１８】
【図１】医療情報共有システムのシステム構成の一例を示す図である。
【図２】利用者端末のハードウェア構成の一例を示す図である。
【図３】情報提供サーバーのハードウェア構成の一例を示す図である。
【図４】ブロックチェーンノードのハードウェア構成の一例を示す図である。
【図５】医療情報共有システムの各装置の機能的構成の一例を示す図である。
【図６】医療情報共有システムの各装置の機能的構成の一例を示す図である。
【図７】ブロックチェーンの構成図である。
【図８】ブロックチェーン登録シーケンスにおける各装置の動作を示すシーケンス図である。
【図９】情報提供サーバー登録時における各装置の動作を示すシーケンス図である。
【図１０】利用者アカウント登録時における各装置の動作を示すシーケンス図である。
【図１１】ブロックチェーン登録依頼電文の構成を示す図である。
【図１２】医療情報登録時における各装置の動作を示すシーケンス図である。
【図１３】アクセス権限登録時における各装置の動作を示すシーケンス図である。
【図１４】アクセス権限登録依頼電文の構成を示す図である。
【図１５】情報開示要求時における各装置の動作を示すシーケンス図である。
【図１６】情報開示要求登録依頼電文の構成を示す図である。
【図１７】医療情報開示要求の検索時における各装置の動作を示すシーケンス図である。
【図１８】医療情報参照時における各装置の動作を示すシーケンス図である。
【図１９】アクセス権限変更時における各装置の動作を示すシーケンス図である。
【図２０】アクセス権限削除時における各装置の動作を示すシーケンス図である。
【図２１】再暗号化依頼電文の構成を示す図である。
【発明を実施するための形態】
【００１９】
以下、図面を参照して本発明に係る医療情報共有システムの実施の形態について説明する。なお、本発明は、図示例に限定されるものではない。
【００２０】
＜医療情報共有システム１００の構成＞
図１に、本実施形態における医療情報共有システム１００（分散型医療情報共有システム）のシステム構成を示す。
図１に示すように、医療情報共有システム１００は、連携先医療施設１に設置された利用者端末１０と、クラウドＣ上で動作する複数の情報提供サーバー２０及びｎ台のブロックチェーンノード３０（１）〜３０（ｎ）と、を備えて構成される。利用者端末１０、情報提供サーバー２０及びブロックチェーンノード３０は、インターネット等の通信ネットワークを介してデータ通信可能に接続されている。
なお、本実施形態においては、連携先医療施設１Ａに設置された利用者端末１０Ａは情報提供サーバー２０Ａに、連携先医療施設１Ｂに設置された利用者端末１０Ｂは情報提供サーバー２０Ｂに、それぞれアクセスすることを想定しており、各連携先医療施設１内の利用者端末１０の数は、特に限定されない。また、情報提供サーバー２０の数は、特に限定されない。
【００２１】
利用者端末１０は、医療施設におけるユーザーが、情報提供サーバー２０に対して医療情報を提供、あるいは情報提供サーバーから医療情報を取得して閲覧を行うために用いるコンピューターである。なお、本実施形態においては、利用者端末１０Ａは提供端末、利用者端末１０Ｂは閲覧端末として機能する。
【００２２】
利用者端末１０は、ＬＡＮ（Local Area Network）等の施設内ネットワークにより、医療施設内に設置されたＰＡＣＳ（Picture Archiving and Communication System）とデータ通信可能に接続されており、ＰＡＣＳから医療情報を取り込む。ＰＡＣＳは、医療施設内のモダリティーにより生成された医用画像の画像データ等の医療情報を患者情報や検査情報と対応付けて記憶する施設内サーバーである。モダリティーとして、例えば、ＣＲ（Computed Radiography）、ＦＰＤ（Flat Panel Detector）、ＣＴ（Computed Tomography）、ＭＲＩ（Magnetic Resonance Imaging）等が用いられる。
【００２３】
図２に、利用者端末１０のハードウェア構成を示す。
図２に示すように、利用者端末１０は、制御部１１、ＲＡＭ１２、通信部１３、操作部１４、表示部１５、記憶部１６等を備えて構成され、各部はバス１７等により接続されている。
【００２４】
制御部１１は、ＣＰＵ等により構成され、利用者端末１０の各部の処理動作を統括的に制御する。制御部１１は、記憶部１６に記憶されている各種プログラムを読み出してＲＡＭ１２に展開し、当該プログラムとの協働により各種処理を実行する。
【００２５】
ＲＡＭ１２は、制御部１１により実行制御される各種処理において、記憶部１６から読み出された各種プログラム、入力若しくは出力データ及びパラメーター等を一時的に記憶するワークエリアを形成する。
【００２６】
通信部１３は、ネットワークインターフェース等により構成され、通信ネットワークを介して接続された情報提供サーバー２０や、施設内ネットワークを介して接続された外部機器との間でデータの送受信を行う。
【００２７】
操作部１４は、カーソルキー、数字入力キー及び各種機能キー等を備えたキーボードと、マウス等のポインティングデバイスを備えて構成され、キーボードに対するキー操作やマウス操作により入力された操作信号を制御部１１に出力する。例えば、操作部１４は、利用者端末１０を操作するユーザーが情報提供サーバー２０にアップロードする医療情報を指定する際や、情報提供サーバー２０からダウンロードする医療情報を指定する際に用いられる。
【００２８】
表示部１５は、ＬＣＤ（Liquid Crystal Display）等のモニターを備えて構成されており、制御部１１から入力される表示信号の指示に従って、各種画面を表示する。
【００２９】
記憶部１６は、ＨＤＤや半導体の不揮発性メモリー等により構成される。記憶部１６は、制御部１１により実行される各種プログラムを記憶しているほか、各種プログラムを実行するために必要なパラメーターやデータを記憶している。
【００３０】
情報提供サーバー２０は、連携先医療施設１において生成された医療情報を蓄積するとともに、管理する。なお、情報提供サーバー２０は医療情報提供サーバーとして機能する。
【００３１】
図３に、情報提供サーバー２０のハードウェア構成を示す。
図３に示すように、情報提供サーバー２０は、制御部２１、ＲＡＭ（Random Access Memory）２２、通信部２３、記憶部２４等を備えて構成されており、各部はバス２５により接続されている。
【００３２】
制御部２１は、ＣＰＵ（Central Processing Unit）等により構成され、情報提供サーバー２０の各部の処理動作を統括的に制御する。制御部２１は、記憶部２４に記憶されている各種プログラムを読み出してＲＡＭ２２に展開し、当該プログラムとの協働により各種処理を実行する。
【００３３】
ＲＡＭ２２は、制御部２１により実行制御される各種処理において、記憶部２４から読み出された各種プログラム、入力若しくは出力データ及びパラメーター等を一時的に記憶するワークエリアを形成する。
【００３４】
通信部２３は、ネットワークインターフェース等により構成され、通信ネットワークを介して接続された利用者端末１０及びブロックチェーンノード３０との間でデータの送受信を行う
【００３５】
記憶部２４は、ＨＤＤ（Hard Disk Drive）や半導体の不揮発性メモリー等により構成される。記憶部２４は、制御部２１により実行される各種プログラムを記憶しているほか、各種プログラムを実行するために必要なパラメーターやデータを記憶している。
【００３６】
ブロックチェーンノード３０は、ブロックチェーン技術が導入されたコンピューターであり、ブロックチェーンを管理する。各ブロックチェーンノード３０は、分散型ネットワークにより相互に接続されている。なお、医療情報共有システム１００においては、ｎ台（ｎ≧３）のブロックチェーンノード３０を有する。
図４に、ブロックチェーンノード３０のハードウェア構成を示す。
図４に示すように、ブロックチェーンノード３０は、制御部３１、ＲＡＭ（Random Access Memory）３２、通信部３３、記憶部３４等を備えて構成されており、各部はバス３５により接続されている。
【００３７】
制御部３１は、ＣＰＵ（Central Processing Unit）等により構成され、ブロックチェーンノード３０の各部の処理動作を統括的に制御する。制御部３１は、記憶部３４に記憶されている各種プログラムを読み出してＲＡＭ３２に展開し、当該プログラムとの協働により各種処理を実行する。
【００３８】
ＲＡＭ３２は、制御部３１により実行制御される各種処理において、記憶部３４から読み出された各種プログラム、入力若しくは出力データ及びパラメーター等を一時的に記憶するワークエリアを形成する。
【００３９】
通信部３３は、ネットワークインターフェース等により構成され、通信ネットワークを介して接続された他のブロックチェーンノード３０及び情報提供サーバー２０との間でデータの送受信を行う
【００４０】
記憶部３４は、ＨＤＤ（Hard Disk Drive）や半導体の不揮発性メモリー等により構成される。記憶部３４は、制御部３１により実行される各種プログラムを記憶しているほか、各種プログラムを実行するために必要なパラメーターやデータを記憶している。
【００４１】
続いて、医療情報共有システム１００の機能的構成を説明する。
図５は、利用者端末１０が情報提供サーバー２０に医療情報を提供する際における各装置の機能的構成を示す図であり、この場合、利用者端末１０Ａ、情報提供サーバー２０Ａ及びｎ台のブロックチェーンノード３０が必要となる。
【００４２】
利用者端末１０の制御部１１は、公開鍵及び秘密鍵を生成する公開鍵・秘密鍵生成部１０１、ユーザー識別ＵＵＩＤ及び医療情報識別ＵＵＩＤを生成するＵＵＩＤ生成部１０２、再暗号化鍵を生成する再暗号化鍵生成部１０５、情報提供サーバーに送信する各種データを暗号化する送信データ暗号化部１０７、利用者アカウントの認証を行うユーザー認証部１１１として機能する。
また、通信部１３は、情報提供サーバー２０に依頼電文を送信する依頼電文送信部１１０として機能する。
また、操作部１４は、各種送信データを入力する送信データ入力部１０３、アクセス権限の付与に必要な情報を入力するアクセス権限入力部１０９として機能する。
また、記憶部１６は、当該利用者端末１０が提供する医療情報を参照する利用者アカウントのユーザー識別ＵＵＩＤを記憶する参照先ユーザーＵＵＩＤ管理部１０４、送信する医療情報毎の秘密鍵を記憶する送信データ毎秘密鍵管理部１０６、当該利用者端末１０を利用する利用者アカウント毎の秘密鍵を記憶する利用者毎秘密鍵管理部１０８として機能する。
【００４３】
情報提供サーバー２０Ａの制御部２１は、自身が記憶するブロックチェーンを検索するブロックチェーン検索部２０３、ブロックチェーンを生成するブロックチェーン生成部２０４として機能する。
また、通信部２３は、利用者端末１０から依頼電文を受信する依頼電文受信部２０２、ブロックチェーンノード３０からブロックチェーンを受信するブロックチェーン受信部２０７、ブロックチェーンノード３０にブロックチェーン承認結果を送信するブロックチェーン承認結果送信部２０８として機能する。
また、記憶部２４は、利用者端末１０から受信した依頼電文を記憶する依頼電文保存部２０１、暗号化された医療情報を記憶する暗号化データ記憶部２０５、ブロックチェーンを記憶するブロックチェーン保存部２０６、ブロックチェーン承認結果を記憶するブロックチェーン承認結果記憶部２０９として機能する。
【００４４】
ブロックチェーンノード３０の制御部３１は、情報提供サーバー２０を管理する情報提供サーバー管理部３０１、自身が記憶するブロックチェーンを検索するブロックチェーン検索部３０２、ブロックチェーンを管理するブロックチェーン管理部３０３として機能する。
また、通信部３３は、情報提供サーバー２０との間でブロックチェーンの送受信を行うブロックチェーン通信部３０４、情報提供サーバー２０にブロックチェーンの検証結果を送信するブロックチェーン検証結果送信部３０６として機能する。
また、記憶部３４は、ブロックチェーンを記憶するブロックチェーン保存部３０５、ブロックチェーンの承認結果を記憶するブロックチェーン承認結果記憶部３０７として機能する。
【００４５】
なお、公開鍵・秘密鍵生成部１０１は第１の暗号鍵生成部、送信データ暗号化部１０７は暗号化処理部、ブロックチェーン生成部２０４は保存制御部として機能する。
【００４６】
図６は、利用者端末１０が情報提供サーバー２０から医療情報を取得する際における各装置の機能的構成を示す図であり、この場合、利用者端末１０Ｂ、情報提供サーバー２０Ｂ、情報提供サーバー２０Ａ、及びｎ台のブロックチェーンノード３０が必要となる。
【００４７】
利用者端末１０の制御部１１は、ユーザー認証部１１２、公開鍵・秘密鍵生成部１１５、情報提供サーバー２０Ａから受信した再暗号化された医療情報を復号する受信データ復号部１１８として機能する。
また、通信部１３は、依頼電文送信部１１３、情報提供サーバー２０Ａから医療情報を受信するデータ受信部１１９として機能する。
また、操作部１４は、情報提供サーバー２０Ａから取得する医療情報を選択するデータ選択部１１４として機能する。
また、表示部１５は、情報提供サーバー２０Ａから受信した医療情報を表示する受信データ表示部１１７として機能する。
また、記憶部１６は、利用者毎秘密鍵管理部１１６として機能する。
【００４８】
情報提供サーバー２０Ｂの制御部２１は、ブロックチェーン検索部２１２として機能する。
また、通信部２３は、依頼電文受信部２１１、依頼電文を情報提供サーバー２０Ａに転送する依頼電文転送部２１３、ブロックチェーン受信部２１４として機能する。
また、記憶部２４は、依頼電文保存部２１０、ブロックチェーン保存部２１５として機能する。
【００４９】
情報提供サーバー２０Ａの制御部２１は、再暗号化鍵を用いて暗号化された医療情報を再暗号化するデータ再暗号化部２１８として機能する。
また、通信部２３は、依頼電文受信部２１６、利用者端末１０に医療情報を送信するデータ送信部２１９として機能する。
また、記憶部２４は、暗号化データ記憶部２１７として機能する。
【００５０】
ブロックチェーンノード３０の制御部３１は、情報提供サーバー管理部３０８、ブロックチェーン検索部３０９、ブロックチェーン管理部３１０として機能する。
また、通信部３３は、ブロックチェーン通信部３１１として機能する。
また、記憶部３４は、ブロックチェーン保存部３１２として機能する。
【００５１】
なお、公開鍵・秘密鍵生成部１１５は第２の暗号鍵生成部、受信データ復号部１１８は復号処理部、データ再暗号化部２１８は再暗号化部として機能する。
【００５２】
＜医療情報の共有＞
次に、本実施形態に係る医療情報共有システム１００における、医療情報の共有方法について説明する。
【００５３】
医療情報をクラウドＣ上に保存する場合、医療情報は公開鍵暗号記述によりデータを暗号化したうえで送信され、複数の閲覧権限者で共有される。このとき、（１）一つの復号鍵を複数の閲覧権限者で共有する方式、（２）閲覧権限者毎の復号鍵で復号できるように暗号化して配信する方式、（３）再暗号化鍵で鍵の付け替えを可能とし、ダウンロード時に鍵の付け替えを行う方式、が想定される。
【００５４】
（１）の方式では、暗号化のための鍵は一つであるため管理が容易である一方、一つしかない復号鍵が漏洩した場合、医療情報の漏洩を阻止できないという問題がある。
（２）の方式では、各閲覧権限者が復号鍵を共有しないため、セキュリティ上は好ましい一方で、情報提供者が閲覧権限者すべての暗号化鍵を使用して暗号化しなければならないうえ、閲覧権限者の増減に合わせて再度暗号化して送信する必要に迫られ、情報提供者にとって管理が煩雑化するという問題がある。
【００５５】
（３）の方式について、再暗号化技術は、暗号化されたデータを復号することなく別のユーザーの鍵に付け替え可能な暗号方式である。即ち、暗号化した医療情報を特定の利用者のみが復号可能となるように再暗号化することにより、情報提供者自身が、当該利用者のみに閲覧権限を与えることと同等の効果がある。
一方で、不正なクラウドＣの管理者とユーザーが結託して、再暗号化鍵と秘密鍵から本来存在しないはずの再暗号化鍵が偽造されてしまうおそれがある。即ち、再暗号化技術によれば利便性と一定以上の安全性を確保可能である一方で、なりすましのリスクを排除することができない。
【００５６】
そこで、本発明においては、再暗号化技術を用いて、医療情報を利便性高く管理する一方で、アクセス権限や再暗号化鍵などの重要な情報を、ブロックチェーン技術によりブロックチェーンで管理することで、不正な利用者に医療情報を閲覧されるリスクを排除することを特徴とする。
【００５７】
［再暗号化技術］
一般的な再暗号化技術について説明する。
暗号鍵ＫでデータＭを暗号化する暗号演算をＥｎｃ（Ｋ，Ｍ）と表記し、鍵同士の合成演算を（・）と表記すると、ここでの再暗号化技術においては以下の性質を持つことを前提とする。
１．暗号化を行わない鍵０が一つだけ存在し、Ｋ・０＝０・Ｋ＝Ｋとなる。即ち、以下の式（１）が成立する。
Ｅｎｃ（０，Ｍ）＝Ｍ    ・・・（１）
２．鍵Ｋで暗号化したデータを復元する逆元の鍵Ｋ−１が一つだけ存在し、以下の式（２）が成立する。
Ｋ−１・Ｋ＝０    ・・・（２）
３．０ではない鍵Ｋ１と鍵Ｋ２を用いて、以下の式（３）が成立する。
Ｅｎｃ（Ｋ１，Ｅｎｃ（Ｋ２，Ｍ））＝Ｅｎｃ（Ｋ１，・Ｋ２，Ｍ）    ・・・（３）
【００５８】
なお、０ではない鍵Ｋ１と鍵Ｋ２に関して、セキュリティ上、Ｋ１，・Ｋ２≠Ｋ２・Ｋ１であることが望ましい。ただし、Ｋ１，・Ｋ２＝Ｋ２・Ｋ１であってもよい。
【００５９】
また、鍵０以外の合成鍵で、それがどの鍵から合成されたのかを明らかにすることが可能な、現実的な計算方法は存在しないことを前提とする。即ち、任意の合成鍵が別の合成鍵と同じ値となり、このような異なる鍵の組み合わせを求めることが現実的に不可能であることが前提である。
【００６０】
これらの性質を持つ暗号演算と合成演算とにより、鍵の付け替えを行う場合、元の鍵の逆元の鍵Ｋ−１と、付け替える予定の鍵Ｊとの合成鍵がある場合、以下の式（４）により鍵の付け替えが可能となる。
Ｅｎｃ（Ｊ・Ｋ−１，Ｅｎｃ（Ｋ，Ｍ））
＝Ｅｎｃ（Ｊ・Ｋ−１・Ｋ，Ｍ）
＝Ｅｎｃ（Ｊ，Ｍ）    ・・・（４）
即ち、鍵Ｋで暗号化されたデータＭを、再暗号化鍵Ｊ・Ｋ−１を用いて、復号することなく鍵Ｊに付け替えることが可能である。
【００６１】
［ブロックチェーン技術］
ブロックチェーンとは、分散型台帳技術とも呼ばれ、ビザンチン障害（Byzantine Faults）を含む不特定多数のノードを用いて、時間の経過とともにその時点の合意が覆る確率が０へ収束するプロトコル、又はその実装のことを指す。
図７は、ブロックチェーンに登録されるブロックの構造を示す図である。ブロックＢＬは、それぞれブロックヘッダー４１０と登録データ４２０とを備える。
【００６２】
ブロックヘッダー４１０は、ブロック識別子４１１、開始時間４１２、ノード識別記号４１３、前ブロックのハッシュ値４１４、及び署名データ４１５を備えて構成される。
ブロック識別子４１１とは、複数のブロックの間に順序関係を明らかにするものであって、次のブロック識別子が何であるかを判別する可能なものが用いられる。ここでは、自然数（１，２，３，・・・）を使用するものとし、例えばブロック４００Ａが有するブロック識別子４１１が「５」である場合、次に生成されるブロック４００Ｂのブロック識別子４１１は「６」である。
【００６３】
開始時間４１２は、ブロックの生成を開始した時点からの経過時間を表す。
ノード識別記号４１３は、ブロックを承認したブロックチェーンノード３０を識別する記号である。ここでは、ブロックチェーンノード３０のＩＰアドレスを使用するものとする。
【００６４】
前ブロックのハッシュ値４１４は、一つ前のブロックを要約した値である。ただし、先頭のブロック（Genesis Block）４００は、前ブロックのハッシュ値４１４を持たず、運用開始前に登録された値を前ブロックのハッシュ値として保有している。
署名データ４１５は、当該ブロック４００が正規のブロックであることを確認可能にするバイナリーデータである。ここでは、登録データ４２０と前ブロックのハッシュ値４１４を、ブロックを承認したブロックチェーンノード３０の秘密鍵で暗号化したデータとする。したがって、承認したブロックチェーンノード３０を特定できれば、署名データ４１５を公開鍵で復号し、実際のハッシュ値と比較することで正当性を確認することができる。
登録データ４２０は、後述する各シーケンスにおいてブロック４００に登録されるデータである。
【００６５】
続いて、合意形成アルゴリズムについて説明する。合意形成アルゴリズムは、現在のブロックチェーンの末尾にどのブロックを接続するかを、ブロックチェーンノード間で決定するアルゴリズムである。本実施形態においては、ＰＢＦＴ（Practical Byzantine Fault Tolerance）を使用する。
【００６６】
ＰＢＦＴは、ビザンチン障害の発生に係らず正常に合意形成可能なアルゴリズムである。ビザンチン障害とは、故障や不正によりその系で異常な出力を行うブロックチェーンノード３０が存在する場合に、全体として正しい合意形成が行われなくなる障害を指し、ＰＢＦＴでは以下のようにすることで、このような問題に影響されることなく合意形成を行うことを可能とする。
【００６７】
ＰＢＦＴにおいては、ブロックの追加提案をできるブロックチェーンノード３０（ここでは提案ノードと表記）を任意の方法で一台決定する。また、ブロックの承認をするブロックチェーンノード３０（ここでは承認ノードと表記）のうち、ブロックの追加をする権限を有するブロックチェーンノード３０（ここではリーダーノードと表記）を任意の方法で一台決定する。
ここで、承認ノードの可用性を判断する故障許容ノード数ｆを設定した場合に、３ｆ＋１台以上の承認ノードからブロックの承認を受けた場合に、新規ブロックがブロックチェーンに追加されることとなり、換言すると提案ノードがトランザクションをコミットできることとなる。
【００６８】
本実施形態においては、情報提供サーバー２０が提案ノードとして機能し、ブロックチェーンノード３０のうちの一台がリーダーノード、その他のブロックチェーンノード３０が承認ノードとして機能する。
【００６９】
図８は、新規ブロックをブロックチェーンに追加するブロックチェーン登録シーケンスにおける、各装置の動作を示すフローチャートである。
まず、情報提供サーバー２０は提案ノードとして、ブロックチェーン追加権限要求を行う（ステップＳ１０１）。このとき、当該情報提供サーバー２０のＩＰアドレスを、リーダーノードとしてのブロックチェーンノード３０（１）に送信する。
【００７０】
ブロックチェーンノード３０（１）は、情報提供サーバー２０からの依頼でなければ無視するが、情報提供サーバー２０からの依頼であることを確認すると、承認ノードとしてのブロックチェーンノード３０（２）に対して、ブロックチェーン追加権限要求を行う（ステップＳ１０２）。一方で、ブロックチェーンノード３０（１）は自身のキャッシュの中で、追加可能なブロック識別子４１１を情報提供サーバー２０に応答する（ステップＳ１０３）。
【００７１】
ブロックチェーンノード３０（２）は、情報提供サーバー２０からの依頼でなければ無視するが、情報提供サーバー２０からの依頼であることを確認すると、自身のキャッシュの中で追加可能なブロック識別子４１１を情報提供サーバー２０に応答する（ステップＳ１０４）。
一方で、ブロックチェーンノード３０（２）は、ブロックチェーンノード３０（３）に対してブロックチェーン追加権限要求を行う（ステップＳ１０２）。
全てのブロックチェーンノード３０がブロック識別子４１１を情報提供サーバー２０に応答するまで以上の処理を繰り返す。即ち、ステップＳ１０４の処理をｎ−１回、ステップＳ１０５の処理をｎ−２回繰り返す。
【００７２】
情報提供サーバー２０は、ブロックチェーンノード３０（１）に対して、ブロックチェーン登録依頼要求を行う（ステップＳ１０６）。ブロックチェーン登録依頼要求は、ｎ台のブロックチェーンノード３０から応答されたブロック識別子４１１のうち、３ｆ＋１以上のブロックチェーンノード３０から共通して応答されたブロック識別子４１１を選択し、登録データ４２０及び前ブロックのハッシュ値４１４を含むブロックチェーン登録依頼電文の内容で登録要求する。
【００７３】
ブロックチェーンノード３０（１）は、処理済みの登録要求は無視する一方、未処理の登録要求であることを確認すると、ブロックチェーンノード３０（２）に対してブロックチェーン登録依頼要求を行う（ステップＳ１０７）。
一方で、ブロックチェーンノード３０（１）は、前ブロックのハッシュ値４１４が正しいこと、及びブロック識別子４１１と情報提供サーバー２０のＩＰアドレスが正しいことを検証し、情報提供サーバー２０にブロック検証結果を応答する（ステップＳ１０８）。なお、署名データ４１５は、登録データ４２０のハッシュ値をブロックチェーンノード３０（１）の秘密鍵で署名して生成する。
【００７４】
ブロックチェーンノード３０（２）〜（ｎ）は、各々がブロック検証結果を情報提供サーバー２０に応答するとともに（ステップＳ１０９）、他のブロックチェーンノード３０にブロックチェーン登録依頼要求を行う（ステップＳ１１０）。したがって、ステップＳ１０９及びステップＳ１１０の処理は、それぞれｎ−１回あるいはｎ−２回繰り返される。
【００７５】
情報提供サーバー２０は、応答された結果のうち、３ｆ＋１以上のブロックチェーンノード３０が成功応答した場合に、応答された署名データ４１５を含めたブロックを正式に登録し、ブロックチェーン承認通知をブロックチェーンノード３０（１）に送信する（ステップＳ１１１）。ブロックチェーン承認通知には、ブロック識別子４１１、登録データ４２０及び署名データ４１５が含まれる。
なお、情報提供サーバー２０は、失敗と判断した場合、ブロックチェーン追加権限要求からやり直す。
【００７６】
ブロックチェーンノード３０（１）は、処理済みの承認通知は無視する一方、未処理の承認通知であることを確認すると、ブロックチェーンノード３０（２）に対してブロックチェーン承認通知を行う（ステップＳ１１２）。
一方で、ブロックチェーンノード３０（１）は、署名データ４１５を確認し、不正な署名であればブロックチェーンに追加しないが、正しく署名されていることを確認すると、ブロックチェーンに追加し、情報提供サーバー２０にブロック承認完了通知を送信する（ステップＳ１１４）。
【００７７】
ブロックチェーンノード３０（２）〜（ｎ）は、各々が署名データ４１５を確認し（ステップＳ１１５）、ブロック承認完了通知を情報提供サーバー２０に送信するとともに（ステップＳ１１６）、他のブロックチェーンノード３０にブロックチェーン承認通知を送信する（ステップＳ１１７）。したがって、ステップＳ１１５及びステップＳ１１６の処理は、それぞれｎ−１回繰り返され、ステップＳ１１７の処理は、ｎ−２回繰り返される。
以上のようにして、ブロックチェーン登録シーケンスを完了する。
【００７８】
［医療情報共有システムの動作］
以下、本実施形態に係る医療情報共有システム１００の動作について説明する。医療情報共有システム１００が、医療情報の共有を開始し、完了するまでの基本シーケンスは以下である。なお、以下では連携先医療施設１Ａにおいて医療情報をクラウドＣに保存し、連携先医療施設１Ｂにおいて当該医療情報を閲覧するものとする。
（１）情報提供サーバー２０Ａ，２０Ｂを登録する。
（２）利用者アカウントＡ，Ｂのユーザー識別情報と公開鍵をブロックチェーンに登録する。
（３）利用者端末１０Ａから医療情報を入力し、当該医療情報のデータを暗号化したうえで情報提供サーバー２０Ａに送信する。
（４）利用者端末１０Ａから送信した医療情報のアクセス権限をブロックチェーンに登録する。
（５）利用者アカウントＢに紐づくアクセス権限登録のブロックが存在する場合、再暗号化した医療情報を利用者端末１０Ｂに送信する。
（６）利用者アカウントＡに紐づくアクセス権限登録を追加又は削除する。
【００７９】
（１）情報提供サーバーの登録
情報提供サーバー２０を、新規のブロックを追加提案可能な提案ノードとして運用開始する場合、当該情報提供サーバー２０を識別する情報及びネットワーク情報を、ブロックチェーンノード３０のサーバー群に個別の設定として登録する。この設定方法については特に限定されない。ブロックチェーンノード３０のサーバー群は、登録された情報提供サーバー２０だけを、提案ノードとして認識する。
【００８０】
図９は、各装置の動作を示すシーケンス図である。
まず、情報提供サーバー２０が、リーダーノードであるブロックチェーンノード３０（１）に対して情報提供サーバー登録要求を行う（ステップＳ２０１）。このとき、情報提供サーバー２０は、ＩＰアドレスやノード名などの識別情報を送信する。
続いて、ブロックチェーンノード３０（１）は、当該自身が管理しているブロックチェーンのブロックを返信する（ステップＳ２０２）。なお、情報提供サーバー２０が接続許可を設定済みでなければ、ブロックチェーンノード３０（１）はステップＳ２０１の要求を無視する。
【００８１】
情報提供サーバー２０は、ブロックチェーンノード３０（１）からブロックチェーンのブロックを取得すると、キャッシュに保存し（ステップＳ２０３）、ブロックのハッシュ値と次のブロックで保持しているハッシュ値が同一か否かを確認する（ステップＳ２０４）。
【００８２】
一方で、ブロックチェーンノード３０（１）は、他の承認ノードであるブロックチェーンノード３０（２）〜３０（ｎ）に対して、情報提供サーバー２０の識別情報を通知して共有する（ステップＳ２０５）。
通知を受け取ると、ブロックチェーンノード３０（２）〜（ｎ）は、各々が管理しているブロックチェーンのブロックを、情報提供サーバー２０に返信する（ステップＳ２０６、２０７）。また、ブロックチェーンノード３０（２）〜（ｎ）は、情報提供サーバー２０の識別情報を他のブロックチェーンノードに通知して共有し（ステップＳ２０８）、受け取ったブロックチェーンノード３０は、既に受け取った内容と同じである場合には、無視する。
【００８３】
情報提供サーバー２０は、ブロックチェーンノード３０（２）〜（ｎ）からブロックチェーンのブロックを取得すると、キャッシュに保存されたブロックと同一であるか否かを判断する（ステップＳ２０８）。情報提供サーバー２０は、ブロックチェーンノード３０から応答された結果のうち、３ｆ＋１台以上のブロックチェーンノード３０からのブロックが同じであれば、正しいブロックであると判断し、キャッシュに保存する（ステップＳ２０９）。
以上の処理を情報提供サーバー２０Ａ及び２０Ｂについて実行することで、情報提供サーバー２０Ａ及び２０Ｂが新規のブロックを追加提案可能な提案ノードとして機能することが可能となる。
【００８４】
（２）利用者アカウントの登録
連携先医療施設１Ａの利用者端末１０Ａを用いて医療情報を提供する利用者アカウントＡと、連携先医療施設１Ｂの利用者端末１０Ｂを用いて医療情報を閲覧する利用者アカウントＢと、をそれぞれ登録する必要がある。したがって、利用者端末１０Ａは、利用者を認証する情報が入力されると、当該情報に基づくユーザー識別ＵＵＩＤと、当該ユーザー識別ＵＵＩＤに紐づく公開暗号鍵のペア（公開鍵ＫＡｐ及び秘密鍵ＫＡｐ−１）を生成し、ユーザー識別ＵＵＩＤと公開鍵ＫＡｐがブロックチェーンに登録されることで、利用者アカウントＡの登録が完了する。
ここで、ＵＵＩＤ（Universal Unique Identifier）とは、分散システム上で統制なしに作成できる識別子として設計されたＩＤであり、将来にわたって重複しないことを前提に用いることができる。
【００８５】
図１０は、各装置の動作を示すシーケンス図である。以下では、利用者アカウントＡを登録する場合を説明する。
まず、利用者端末１０Ａは、利用者を認証する情報が入力されると、ユーザー識別ＵＵＩＤを生成する（ステップＳ３０１）。続いて、利用者端末１０Ａは、ユーザー識別ＵＵＩＤに紐づく公開鍵ＫＡｐ及び秘密鍵ＫＡｐ−１を生成する（ステップＳ３０２）。
続いて、利用者端末１０Ａは、任意の文字列を生成し、秘密鍵ＫＡｐ−１で暗号化したものを、公開鍵確認情報とする（ステップＳ３０３）。なお、任意の文字列は利用者端末１０Ａしか知りえない情報である。
【００８６】
次いで、利用者端末１０Ａは、情報提供サーバー２０Ａに対してブロックチェーン登録依頼要求を行う（ステップＳ３０４）。
図１１は、ステップＳ３０４で送信されるブロックチェーン登録依頼電文の構造を示した図である。図１１に示すように、ブロックチェーン登録依頼電文５１０は、利用者アカウントＡのユーザー識別ＵＵＩＤ５１１と、登録依頼電文の種別（ここでは、ユーザー識別登録）を表す種別情報５１２と、公開鍵（ここでは、公開鍵ＫＡｐ）を表す公開鍵情報５１３と、上記した公開鍵確認情報５１４と、を備えて構成される。
したがって、ここでは、登録データ４２０としてユーザー識別ＵＵＩＤ５１１、公開鍵情報５１３、公開鍵確認情報５１４を送信する。
【００８７】
情報提供サーバー２０はブロックチェーン登録依頼要求を受け付けると、電文構成が正しい場合には、ブロックの追加を要求し、ブロックチェーンノード３０との間で図８に示すブロックチェーン登録シーケンスを実行する（ステップＳ３０５）。
【００８８】
ブロックが登録されると、情報提供サーバー２０Ａは、利用者端末１０Ａに対してブロックチェーン登録依頼応答を行う（ステップＳ３０６）。
利用者端末１０Ａは、ユーザー識別ＵＵＩＤを用いて情報提供サーバー２０Ａからブロックチェーンを取得し、ブロックチェーンに登録された公開鍵確認情報を自身の秘密鍵ＫＡｐ−１で復号して、正常に登録されたか否かを判断する。
以上の処理を、利用者アカウントＢについても同様に実行する。
【００８９】
なお、情報提供サーバー２０Ａが不正なプログラムで制御されている場合には、ブロックの登録が偽装されている可能性があるが、その他の信頼できる複数の情報提供サーバー２０に対して問い合わせを行い、正しく登録されていることを確認するものとしてもよい。
【００９０】
（３）利用者端末からの医療情報の送信
利用者アカウントＡによってログインされた利用者端末１０Ａから、医療情報を入力する。このとき、閲覧権限者が決まっている必要はない。医療情報のデータをＭとし、利用者端末１０Ａ内で、鍵の付け替え可能な再暗号化技術Ｅｎｃによって暗号化される。この時の暗号化に使用する鍵は、一時的に生成した付け替え用の鍵ＫＡｔと、利用者端末１０Ａ内で生成した再暗号化用の公開鍵ＫＡｐとの合成鍵ＫＡｔ・ＫＡｐである。また、暗号化されたデータは、Ｅｎｃ（ＫＡｔ・ＫＡｐ，Ｍ）で表され、情報提供サーバー２０Ａに送信される。なお、この時点で当該暗号化データを復元できるのは、逆元の鍵ＫＡｔ−１と秘密鍵ＫＡｐ−１とを有する利用者端末１０Ａのみである。
【００９１】
図１２は、各装置の動作を示すシーケンス図である。
医療情報Ｍが入力されると（ステップＳ４０１）、当該医療情報Ｍに紐づく医療情報識別ＵＵＩＤを生成するとともに（ステップＳ４０２）、鍵付け替え用の鍵ＫＡｔとその逆元の鍵ＫＡｔ−１をその都度新たに生成する（ステップＳ４０３）。
次いで、利用者端末１０は、鍵付け替え用の鍵ＫＡｔと公開鍵ＫＡｐとを合成して再暗号化鍵ＫＡｔ・ＫＡｐとし（ステップＳ４０４）、医療情報Ｍを再暗号化鍵ＫＡｔ・ＫＡｐで暗号化して、暗号化医療情報Ｅｎｃ（ＫＡｔ・ＫＡｐ，Ｍ）を生成する（ステップＳ４０５）。
【００９２】
続いて、利用者端末１０Ａは、情報提供サーバー２０に対して医療情報登録依頼要求を行う（ステップＳ４０６）。ここでは、登録データ４２０として、医療情報識別ＵＵＩＤ及び暗号化医療情報Ｅｎｃ（ＫＡｔ・ＫＡｐ，Ｍ）が送信される。
【００９３】
情報提供サーバー２０Ａは、暗号化医療情報を受け取ると、医療情報識別ＵＵＩＤと暗号化医療情報Ｅｎｃ（ＫＡｔ・ＫＡｐ，Ｍ）を紐づけた状態で保存し、利用者端末１０Ａに医療情報を登録した旨を応答する（ステップＳ４０７）。
これ以降は、情報提供サーバー２０Ａ及び利用者端末１０Ａは、医療情報識別ＵＵＩＤを管理し、情報提供サーバー２０Ａは、利用者端末１０Ａから医療情報識別ＵＵＩＤによる問い合わせがあった場合に、医療情報識別ＵＵＩＤに紐づく医療情報を応答する。
【００９４】
なお、情報提供サーバー２０は、自分自身が管理していない医療情報識別ＵＵＩＤに関する要求電文を受信した場合、他の情報提供サーバー２０に転送するとともに、転送済みの電文を再度受け取った場合には転送しないものとする。
【００９５】
なお、送信した医療情報を閲覧者によってアクセス可能範囲を分ける場合には、その範囲毎に、鍵付け替え用の鍵ＫＡｔとは異なる一時的な付け替え用の鍵ＫＡｕ及びその逆元の鍵ＫＡｕ−１を生成し、当該範囲に対して合成された暗号鍵ＫＡｕ・ＫＡｔ・ＫＡｐを使用して暗号化し、Ｅｎｃ（ＫＡｕ・ＫＡｔ・ＫＡｐ，Ｍ’）を生成して送信する。
【００９６】
（４）医療情報へのアクセス権限の登録
（４−１）利用者アカウントＡによる利用者アカウントＢへのアクセス権限付与
利用者アカウントＡは、送信した医療情報を利用者端末１０Ｂの利用者アカウントＢに閲覧権限を付与する場合に、利用者アカウントＢのアクセス権限をブロックチェーンに登録する。なお、利用者アカウントＡと利用者アカウントＢは、事前に互いのユーザー識別ＵＵＩＤを、医療情報共有システムとは無関係に知っていることを前提とする。また、情報提供サーバー２０には、ユーザー識別ＵＵＩＤが残される可能性があるが、それがどのアカウントと紐づいているかを情報提供サーバー２０が知る必要はない。
【００９７】
図１３は、各装置の動作を示すシーケンス図である。
利用者端末１０Ａは、アクセス権限を与えるユーザー識別ＵＵＩＤを選択する（ステップＳ５０１）。ここでは、利用者アカウントＢにアクセス権限を与えるため、利用者アカウントＢに紐づくユーザー識別ＵＵＩＤを選択する。
次いで、利用者端末１０Ａは、情報提供サーバー２０Ａに対して、ブロックチェーン情報取得要求を行う（ステップＳ５０２）。このとき、利用者端末１０Ａは、利用者アカウントＢのユーザー識別ＵＵＩＤを送信する。
【００９８】
ブロックチェーン情報取得要求を受け付けると、情報提供サーバー２０Ａは、ユーザー識別ＵＵＩＤの公開鍵ＫＢｐが情報提供サーバー２０Ａのキャッシュに存在しない場合、ブロックチェーンノード３０から取得するために、ブロックチェーンノード３０に対してブロックチェーン情報取得要求を行う（ステップＳ５０３）。ｎ台のブロックチェーンノード３０は、それぞれユーザー識別ＵＵＩＤの公開鍵ＫＢｐを取得し、情報提供サーバー２０Ａに応答する（ステップＳ５０４）。
【００９９】
情報提供サーバー２０Ａは、公開鍵ＫＢｐの情報として３ｆ＋１台のブロックチェーンノード３０から同値が応答された時、当該値が正しいと判断し（ステップＳ５０５）、利用者端末１０Ａに対してユーザー識別ＵＵＩＤの公開鍵ＫＢｐを送信し、ブロックチェーン情報取得応答を行う（ステップＳ５０６）。
【０１００】
利用者端末１０Ａは、ユーザー識別ＵＵＩＤに紐づく秘密鍵ＫＡｐ−１と、医療情報識別ＵＵＩＤに紐づく秘密鍵ＫＡｔ−１と、アクセス権限を与えるユーザー識別ＵＵＩＤに紐づく公開鍵ＫＢｐとから、再暗号化鍵ＫＢｐ・ＫＡｐ−１・ＫＡｔ−１を生成する（ステップＳ５０７）。
【０１０１】
続いて、利用者端末１０Ａは、情報提供サーバー２０Ａに対してアクセス権限登録依頼電文を送信して、ブロックチェーン登録依頼要求を行う（ステップＳ５０８）。
図１４は、アクセス権限登録依頼電文５２０の構成の一例である。アクセス権限登録依頼電文５２０は、医療情報識別ＵＵＩＤ５２１と、種別情報５２２と、アクセス権限リスト５２３と、アクセス権限付与先情報５２４と、復号後のハッシュ値５２５と、等を有する。
【０１０２】
医療情報識別ＵＵＩＤ５２１は、利用者アカウントＡが利用者アカウントＢに参照を期待する医療情報に紐づいている。
【０１０３】
種別情報５２２は、当該ブロックチェーン登録依頼の種別を表し、ここではアクセス権限登録である。
【０１０４】
アクセス権限リスト５２３は、医療情報識別ＵＵＩＤ以外での検索可能な項目（ここでは、検索１及び検索２の各項目）が存在する場合には、項目を表す検索１用のハッシュ値と、検索２用のハッシュ値と、等がそれぞれ分けて登録される。なお、当該データを保存する情報提供サーバー２０のＩＰアドレスが、保存先ＩＰアドレスとして保存される。なお、アクセス権限リスト５２３は、情報提供サーバー２０が参照することが可能である。
【０１０５】
アクセス権限付与先情報５２４（＃１）には、相手先ユーザー識別ＵＵＩＤとして利用者アカウントＢのユーザー識別ＵＵＩＤと、再暗号化鍵ＫＢｐ・ＫＡｐ−１・ＫＡｔ−１と、が登録される。なお、アクセス権限付与先情報５２４は、一つのブロックに複数同時に登録することができる。したがって、複数の利用者アカウントにアクセス権限を付与する場合には、それぞれ異なるアクセス権限付与先情報５２４（＃２、＃３、・・・）に分けて登録される。
【０１０６】
復号後のハッシュ値５２５は、暗号化医療情報Ｅｎｃ（ＫＡｔ・ＫＡｐ，Ｍ）を復号したデータをハッシュ関数により演算して得られたハッシュ値であり、後述するように、利用者アカウントＢによる再暗号化された医療情報の復号時に、当該医療情報が正しいものであるかを確認する際に用いられる。
【０１０７】
したがって、ここでは、登録データ４２０として医療情報識別ＵＵＩＤ５２１、アクセス権限付与先情報５２４（相手先ユーザー識別ＵＵＩＤ及び再暗号化鍵）が送信される。
なお、医療情報識別ＵＵＩＤ５２１及び種別情報５２２は、誰にでも検索可能であるが、その他の項目については、自身の再暗号化鍵以外は入手しても活用することができない。
【０１０８】
情報提供サーバー２０Ａがブロックチェーン登録依頼要求を受け付けると、情報提供サーバー２０Ａ及びブロックチェーンノード３０は、図８に示すブロックチェーン登録シーケンスを行う（ステップＳ５０９）。ブロックチェーン登録シーケンスが完了すると、情報提供サーバー２０Ａは利用者端末１０Ａに対してブロックチェーン登録依頼応答を行い（ステップＳ５１０）、制御を終了する。
【０１０９】
以上説明した方法により、情報提供サーバー２０又はブロックチェーンノード３０が不正侵入されて、再暗号化鍵が入手されても、ユーザー識別ＵＵＩＤに紐づく秘密鍵ＫＢｐ−１は利用者端末１０Ｂのみが保有するため、情報提供サーバー２０及びブロックチェーンノード３０は再暗号化された医療情報を復号することができない。
仮に秘密鍵ＫＢｐ−１を有する利用者端末１０Ｂが不正に操作された場合、または情報提供者である利用者端末１０Ａが誤って利用者端末１０Ｂにアクセス権限を付与してしまったとしても、ＫＡｐ−１・ＫＡｔ−１は流出するが、ＫＡｐ−１自体は流出しない。したがって、利用者端末１０Ａから利用者端末１０Ｂに共有された暗号化医療情報Ｅｎｃ（ＫＡｔ・ＫＡｐ，Ｍ）は流出するが、その他の情報は流出しない。
【０１１０】
なお、アクセス権限を追加する場合には、後述するように図１８のシーケンスにしたがって処理を行い、アクセス権限の一部を削除する場合には、図１９のシーケンスにしたがって処理を行う。
【０１１１】
（４−２）利用者アカウントＢによるアクセス権限付与の要求
一方で、利用者アカウントＢが、利用者アカウントＡに、ある特定の検索項目に合致する医療情報の入手を希望した場合には、利用者アカウントＢは、特定の検索項目に合致する医療情報識別ＵＵＩＤの一覧を作成し、それぞれの医療情報識別ＵＵＩＤに紐づくアクセス権限のブロックチェーン登録依頼電文を、情報提供サーバー２０Ｂに送信する。
【０１１２】
図１５は、各装置の動作を示すシーケンス図である。
利用者端末１０Ｂは、検索項目のハッシュ値を求める（ステップＳ６０１）。続いて、情報提供サーバー２０Ｂに対して、情報検索依頼要求を行う（ステップＳ６０２）。このとき、利用者アカウントＢのユーザー識別ＵＵＩＤと、ステップＳ６０１で求めた検索項目のハッシュ値とを送信することで、ハッシュ値による情報検索を要求する。
【０１１３】
情報提供サーバー２０Ｂは、ハッシュ値によって自身のキャッシュを検索する（ステップＳ６０３）。情報提供サーバー２０Ｂは、検索が完了すると、利用者端末１０Ｂに対して情報検索応答を行う（ステップＳ６０４）。
【０１１４】
利用者端末１０Ｂは、情報提供サーバー２０Ｂに対して情報開示要求登録依頼電文を送信して、医療情報開示要求を行う（ステップＳ６０５）。
図１６は、情報開示要求登録依頼電文５３０の構成の一例である。情報開示要求登録依頼電文５３０は、医療情報識別ＵＵＩＤ５３１と、種別情報５３２と、アクセス権限リスト５３３と、情報提供ユーザー識別ＵＵＩＤ５３４と、情報開示ユーザー識別ＵＵＩＤ５３５と、等を有する。
【０１１５】
医療情報識別ＵＵＩＤ５３１は、利用者アカウントＢが閲覧を希望する医療情報に紐づいている。
種別情報５３２は、ここでは情報開示要求である。
アクセス権限リスト５３３は、情報開示を要求する検索項目（ここでは、検索１及び検索２の各項目）をリストとした情報である。
情報提供ユーザー識別ＵＵＩＤ５３４は、情報提供者である利用者アカウントＡのユーザー識別ＵＵＩＤを表す。
情報開示ユーザー識別ＵＵＩＤ５３５は、情報の提供を依頼する利用者アカウントＢのユーザー識別ＵＵＩＤを表す。
したがって、ここでは、登録データ４２０として、医療情報識別ＵＵＩＤ５３１、情報提供ユーザー識別ＵＵＩＤ５３４、情報開示ユーザー識別ＵＵＩＤ５３５が送信される。
【０１１６】
情報提供サーバー２０Ｂが医療情報開示要求を受け付けると、情報提供サーバー２０及びブロックチェーンノード３０は、図８に示すブロックチェーン登録シーケンスを行う（ステップＳ６０６）。ブロックチェーン登録シーケンスが完了すると、情報提供サーバー２０Ｂは利用者端末１０Ｂに対して医療情報開示要求応答を行い（ステップＳ６０７）、制御を終了する。
【０１１７】
一方で、利用者端末１０Ａは、定期的に情報提供ユーザー識別ＵＵＩＤとして自身を利用する利用者アカウントＡが登録されたブロックチェーンのブロックを検索する。当該ブロックの存在を確認した場合、情報開示要求を行ったユーザー識別ＵＵＩＤを確認し、問題がないと判別できる場合には、アクセス権限登録のブロックチェーン登録依頼電文を情報提供サーバー２０Ａに送信する。
【０１１８】
図１７は、各装置の動作を示すシーケンス図である。
利用者端末１０Ａは、自らを利用する利用者アカウントのユーザー識別ＵＵＩＤに紐づく医療情報開示要求を、任意の契機で検索する（ステップＳ７０１）。利用者端末１０Ａは、検索を行うタイミングであると判断した場合に、情報提供サーバー２０Ａに対して、医療情報開示要求検索を要求する（ステップＳ７０２）。このとき、利用者アカウントＡのユーザー識別ＵＵＩＤを情報提供サーバー２０Ａに送信する。
【０１１９】
情報提供サーバー２０Ａは、ユーザー識別ＵＵＩＤを糸口に、情報開示要求検索を実行する（ステップＳ７０３）。情報提供サーバー２０Ａは、ブロックチェーンノード３０に対して、ブロックチェーン情報取得要求を行う（ステップＳ７０４）。このとき、情報提供サーバー２０は、利用者アカウントＡのユーザー識別ＵＵＩＤをブロックチェーンノード３０に送信する。
【０１２０】
各ブロックチェーンノード３０は、ブロックチェーン情報取得要求を受け付けると、医療情報開示要求検索を実行し、検索結果として医療情報識別ＵＵＩＤ及び相手先ユーザー識別ＵＵＩＤの情報を、情報提供サーバー２０Ａに応答する（ステップＳ７０５）。即ち、ｎ台のブロックチェーンノード３０からの応答がなされる。
【０１２１】
情報提供サーバー２０Ａは、３ｆ＋１台以上のブロックチェーンノード３０から同値が応答された時、当該値は正しいと判断し（ステップＳ７０６）、利用者端末１０Ａに対して医療情報識別ＵＵＩＤ及び情報開示要求を行った相手先ユーザー識別ＵＵＩＤ（ここでは、利用者アカウントＢのユーザー識別ＵＵＩＤ）の情報を送信し、医療情報検索応答を行い（ステップＳ７０７）、制御を終了する。
【０１２２】
以上の処理によって情報開示要求が検出された場合、相手先ユーザー識別ＵＵＩＤが既知で、指定された医療情報識別ＵＵＩＤの情報開示に問題がないと判断した場合、図１３のアクセス権限付与時のブロックチェーン登録シーケンスが実行される。
【０１２３】
（５）再暗号化した医療情報の送信
利用者アカウントＢが利用者端末１０Ｂにログインすると、利用者端末１０Ｂが利用者アカウントＢのユーザー識別ＵＵＩＤに紐づくアクセス権限登録のブロックが存在するか否かを、自身が通信を行う情報提供サーバー２０Ｂに問い合わせ、情報提供サーバー２０Ｂから医療情報を取得し、利用者アカウントＢによって閲覧可能とする。
【０１２４】
図１８は、各装置の動作を示すシーケンス図である。
利用者端末１０Ｂは、検索項目のハッシュ値を求める（ステップＳ８０１）。次いで、利用者端末１０Ｂは、情報提供サーバー２０Ｂに対してアクセス権限検索要求を行い、利用者アカウントＢのアクセス権限登録のブロックの存在を問い合わせる（ステップＳ８０２）。このとき、利用者端末１０Ｂは、利用者アカウントＢのユーザー識別ＵＵＩＤ及び検索項目のハッシュ値を送信する。
【０１２５】
情報提供サーバー２０Ｂは、ハッシュ値による自身のキャッシュの検索を実行し、自身のキャッシュに存在する場合には検索結果を利用者端末１０Ｂに応答する（ステップＳ８０３）。
情報提供サーバー２０Ｂは、自身のキャッシュに存在しない場合には、ブロックチェーンノード３０に対してブロックチェーン情報取得要求を行う（ステップＳ８０４）。このとき、情報提供サーバー２０Ｂは、ブロックチェーンノード３０に医療情報識別ＵＵＩＤを送信する。
【０１２６】
各ブロックチェーンノード３０は、ブロックを検索してブロックチェーン情報取得応答を行う（ステップＳ８０５）。即ち、ｎ台のブロックチェーンノード３０からの応答がなされる。このとき、ブロックチェーンノード３０は、医療情報識別ＵＵＩＤ及び保存ＩＰ先アドレスを情報提供サーバー２０Ｂに送信する。
【０１２７】
続いて、情報提供サーバー２０Ｂは、利用者端末１０Ｂに対して、医療情報識別ＵＵＩＤ及び保存先ＩＰアドレスを送信してアクセス権限検索応答を行う（ステップＳ８０６）。
【０１２８】
利用者端末１０Ｂは、保存先ＩＰアドレスに紐づく情報提供サーバー２０Ａに対して、医療情報識別ＵＵＩＤ及び情報提供ユーザー識別ＵＵＩＤを送信することで、医療情報参照要求を行う（ステップＳ８０７）。
【０１２９】
情報提供サーバー２０Ａは、自身のキャッシュに再暗号化鍵が存在しない場合、ブロックチェーンノード３０に対して医療情報識別ＵＵＩＤを送信することで、ブロックチェーン情報取得要求を行う（ステップＳ８０８）。
【０１３０】
ｎ台のブロックチェーンノード３０は、それぞれ情報提供サーバー２０Ａに対して再暗号化鍵を送信することで、ブロックチェーン情報取得応答を行う（ステップＳ８０９）。なおブロックには、上記したように暗号化医療情報Ｅｎｃ（ＫＡｔ・ＫＡｐ，Ｍ）に対応する再暗号化鍵ＫＢｐ・ＫＡｐ−１・ＫＡｔ−１が保存されている。
【０１３１】
情報提供サーバー２０Ａは、３ｆ＋１台以上のブロックチェーンノード３０から同値が応答された時、当該値は正しいと判断する（ステップＳ８１０）。
続いて、情報提供サーバー２０Ａは、再暗号化鍵ＫＢｐ・ＫＡｐ−１・ＫＡｔ−１によって暗号化医療情報Ｅｎｃ（ＫＡｔ・ＫＡｐ，Ｍ）を再暗号化する（ステップＳ８１１）
【０１３２】
次いで、情報提供サーバー２０Ａは、再暗号化した医療情報を、利用者端末１０Ｂに送信することで、医療情報参照要求応答を行う（ステップＳ８１２）
ここで、再暗号化鍵ＫＢｐ・ＫＡｐ−１・ＫＡｔ−１による暗号化医療情報Ｅｎｃ（ＫＡｔ・ＫＡｐ，Ｍ）の再暗号化においては、以下の式（５）が成立し、鍵の付け替えに成功する。
Ｅｎｃ（ＫＢｐ・ＫＡｐ−１・ＫＡｔ−１，（Ｅｎｃ（ＫＡｔ・ＫＡｐ，Ｍ））
＝Ｅｎｃ（ＫＢｐ・ＫＡｐ−１・ＫＡｔ−１・ＫＡｔ・ＫＡｐ，Ｍ）
＝Ｅｎｃ（ＫＢｐ・ＫＡｐ−１・ＫＡｐ，Ｍ）
＝Ｅｎｃ（ＫＢｐ，Ｍ）    ・・・（５）
【０１３３】
利用者端末１０Ｂに再暗号化医療情報Ｅｎｃ（ＫＢｐ，Ｍ）が送信されると、利用者端末１０Ｂは、利用者端末１０Ｂのみが保有する秘密鍵ＫＢｐ−１によって復号して医療情報Ｍを取得して（ステップＳ８１３）、制御を終了する。
ここで、秘密鍵ＫＢｐ−１による再暗号化医療情報Ｅｎｃ（ＫＢｐ，Ｍ）の復号においては、以下の式（６）が成立する。
Ｅｎｃ（ＫＢｐ−１，Ｅｎｃ（ＫＢｐ，Ｍ））
＝Ｅｎｃ（ＫＢｐ−１・ＫＢｐ，Ｍ）
＝Ｍ    ・・・（６）
【０１３４】
なお、もし暗号化医療情報がＥｎｃ（ＫＡｔ・ＫＡｐ，Ｍ）でなければ、利用者端末１０Ｂはダウンロードに成功しても、元の医療情報に秘密鍵ＫＢｐ−１を用いて復元することができない。これは、アクセス権限登録において登録した復号後のハッシュ値５２５と、実際に復号したデータのハッシュ値との比較を行うことで確認可能である。
【０１３５】
（６）アクセス権限登録の追加または削除
（６−１）アクセス権限登録の追加
利用者アカウントＡが、新たに利用者アカウントＣにアクセス権限を付与する場合は、以下のようにしてアクセス権限登録を行う。
【０１３６】
図１９は、各装置の動作を示すシーケンス図である。
利用者端末１０Ａは、新たにアクセス権限を与える利用者アカウントＣに紐づくユーザー識別ＵＵＩＤを事前に知っていることを前提とし、選択する（ステップＳ９０１）。
【０１３７】
ステップＳ９０２及びステップＳ９０３の処理は、図１３におけるステップＳ５０２及びステップＳ５０３の処理と同様であるため、説明を省略する。
ステップＳ９０４では、ｎ台のブロックチェーンノード３０は、それぞれユーザー識別ＵＵＩＤの公開鍵ＫＣｐを取得し、情報提供サーバー２０Ａに応答する。
ステップＳ９０５及びステップＳ９０６の処理は、図１３におけるステップＳ５０５及びステップＳ５０６の処理と同様であるため、説明を省略する。
【０１３８】
ステップＳ９０７では、利用者端末１０Ａは、自身の秘密鍵ＫＡｐ−１と、医療情報識別ＵＵＩＤに紐づく逆元の鍵ＫＡｔ−１と、アクセス権限を与えるユーザー識別ＵＵＩＤに紐づく公開鍵ＫＣｐとから、再暗号化鍵ＫＣｐ・ＫＡｐ−１・ＫＡｔ−１を生成する。
ステップＳ９０８〜ステップＳ９１０の処理は、図１３におけるステップＳ５０８〜ステップＳ５１０の処理と同様であるため、説明を省略する。
したがって、利用者アカウントＣが利用する利用者端末１０においては、再暗号化鍵ＫＣｐ・ＫＡｐ−１・ＫＡｔ−１によって再暗号化された医療情報Ｅｎｃ（ＫＣｐ，Ｍ）を、秘密鍵ＫＣｐ−１によって復号化して医療情報Ｍを取得することが可能となる。
【０１３９】
（６−２）アクセス権限登録の削除
利用者アカウントＡが、特定の医療情報についてのアクセス権限を付与した利用者アカウントを削除する場合には、以下のようにしてアクセス権限登録の削除を行う。
【０１４０】
図２０は、各装置の動作を示すシーケンス図である。
利用者端末１０Ａは、アクセス権限の削除に係る医療情報識別ＵＵＩＤを選択する（ステップＳ１００１）。
続いて、利用者端末１０Ａは、鍵付け替え用の鍵ＫＡｔ及びその逆元の鍵ＫＡｔ−１とは異なる、一度しか使用しない鍵付け替え用の鍵ＫＡｔ２及びその逆元の鍵ＫＡｔ２−１を生成する（ステップＳ１００２）。さらに、利用者端末１０Ａは、鍵付け替え用の鍵ＫＡｔ２と鍵ＫＡｔの逆元の鍵ＫＡｔ−１とから、再暗号化鍵ＫＡｔ２・ＫＡｔ−１を生成する（ステップＳ１００３）。
【０１４１】
続いて、利用者端末１０Ａは、再暗号化依頼要求電文を情報提供サーバー２０Ａに送信することにより、再暗号化依頼要求を行う（ステップＳ１００４）。
図２１は、再暗号化依頼要求電文５４０の構成の一例である。再暗号化依頼要求電文５４０は、医療情報識別ＵＵＩＤ５４１と、種別情報５４２と、再暗号化鍵５４３と、再暗号化前のハッシュ値５４４と、再暗号化後のハッシュ値と、等を有する。
【０１４２】
医療情報識別ＵＵＩＤ５２１は、アクセス権限の削除に係る医療情報に紐づいている。
種別情報５２２は、ここでは再暗号化である。
再暗号化鍵５４３は、ここではＫＡｔ２・ＫＡｔ−１である。
再暗号化前のハッシュ値５４４は、暗号化医療情報Ｅｎｃ（ＫＡｔ・ＫＡｐ，Ｍ）を再暗号化鍵ＫＡｔ２・ＫＡｔ−１で再暗号化する前のデータをハッシュ関数により演算して得られたハッシュ値である。
再暗号化後のハッシュ値５４５は、暗号化医療情報Ｅｎｃ（ＫＡｔ・ＫＡｐ，Ｍ）を再暗号化鍵ＫＡｔ２・ＫＡｔ−１で再暗号化した後のデータをハッシュ関数により演算して得られたハッシュ値である。
【０１４３】
再暗号化依頼要求を受け付けると、情報提供サーバー２０Ａは、医療情報識別ＵＵＩＤに紐づく暗号化医療情報Ｅｎｃ（ＫＡｔ・ＫＡｐ，Ｍ）を、再暗号化鍵ＫＡｔ２・ＫＡｔ−１で再暗号化する（ステップＳ１００５）。即ち、以下の式（７）が成立する。
Ｅｎｃ（ＫＡｔ２・ＫＡｔ−１，（Ｅｎｃ（ＫＡｔ・ＫＡｐ，Ｍ））
＝Ｅｎｃ（ＫＡｔ２・ＫＡｔ−１・ＫＡｔ・ＫＡｐ，Ｍ）
＝Ｅｎｃ（ＫＡｔ２・ＫＡｐ，Ｍ）    ・・・（７）
【０１４４】
これにより、ＫＡｔ２−１及びＫＡｐ−１を保有する利用者端末１０Ａ以外の全ての利用者端末で、一時的に再暗号化された医療情報を復号できなくなる。
情報提供サーバー２０Ａは、再暗号化依頼応答を利用者端末１０Ａに送信すると（ステップＳ１００６）、制御を終了する。
【０１４５】
なお、利用者アカウントＡが、新たに他の利用者アカウントにアクセス権限を付与する場合、新たなアクセス権限のブロックチェーン登録依頼電文を情報提供サーバー２０Ａに送信する。これにより、医療情報Ｍを閲覧可能な利用者アカウントに紐づくアクセス権限登録のブロックは複数存在することとなるが、新しいアクセス権限登録を正しいものとすることで、制御することが可能である。
【０１４６】
以上説明したように、本実施形態に係る医療情報共有システム１００においては、利用者端末１０Ａは、秘密鍵を用いて医療情報を暗号化し、情報提供サーバー２０Ａは、秘密鍵に対応する公開鍵及び再暗号化鍵をブロックチェーンノードに保存させるとともに、暗号化された医療情報を、再暗号化鍵によって再暗号化して、利用者端末１０Ｂに提供する。
したがって、情報提供サーバー２０は暗号化されたデータのみを管理することになるため、情報提供サーバー２０の増加などの際の医療情報の管理も簡便である。また、ブロックチェーン技術によって鍵の偽装および漏洩を防ぎ、閲覧権限者が管理する復号鍵でのみ復元できるようにすることで、医療情報が不正なユーザーによって閲覧されないようリスクを低減させ、安全性を向上させることができる。
【０１４７】
また、本実施形態に係る医療情報共有システム１００においては、利用者端末１０自身が暗号化鍵及び再暗号化鍵を生成するため、効率的であるとともに、意図しない鍵で医療情報が暗号化あるいは再暗号化されるおそれがない。
【０１４８】
また、本実施形態に係る医療情報共有システム１００においては、アクセス権限を付与する利用者端末１０が追加または変更される場合において、暗号化された医療情報を、新たに閲覧権限を取得した利用者端末１０が復号可能なデータに再暗号化するための新規の再暗号化鍵を生成し、当該新規の再暗号化鍵によって再暗号化して新たに閲覧権限を取得した利用者端末１０に提供することを特徴とする。
したがって、閲覧権限を付与する利用者端末１０において再暗号化・再送する必要がなく、また、再暗号化の際に復号して元のデータを公開先以外に参照されるリスクがないため、安全に公開先を変更することができる。また、暗号化鍵及び再暗号化鍵は常に利用者端末１０で生成・合成され、ブロックチェーンに保存されるため、意図しない鍵で更新されず、効率的かつ安全性が高い。
【０１４９】
［他の実施形態］
以上、本発明に係る実施形態に基づいて具体的に説明したが、医療情報共有システム１００を構成する各装置の細部構成及び各装置の細部動作に関しても、本発明の趣旨を逸脱することのない範囲で適宜変更可能である。
【０１５０】
また、上記の説明では、本発明に係るプログラムのコンピューター読み取り可能な媒体としてＨＤＤや半導体の不揮発性メモリー等を使用した例を開示したが、この例に限定されない。その他のコンピューター読み取り可能な媒体として、ＣＤ−ＲＯＭ等の可搬型記録媒体を適用することが可能である。また、本発明に係るプログラムのデータを、通信回線を介して提供する媒体として、キャリアウエーブ（搬送波）も適用される。
【符号の説明】
【０１５１】
１００  医療情報共有システム
１０Ａ  利用者端末（提供端末）
１０１  公開鍵・秘密鍵生成部（第１の暗号鍵生成部）
１０５  再暗号化鍵生成部
１０７  送信データ暗号化部（暗号化処理部）
１１５  公開鍵・秘密鍵生成部（第２の暗号鍵生成部）
１１８  受信データ復号部（復号処理部）
１０Ｂ  利用者端末（閲覧端末）
２０  情報提供サーバー（医療情報提供サーバー）
２０４  ブロックチェーン生成部（保存制御部）
２１８  データ再暗号化部（再暗号化部）
３０  ブロックチェーンノード
【図１】
2020010267.tif 000003
【図２】
2020010267.tif 000004
【図３】
2020010267.tif 000005
【図４】
2020010267.tif 000006
【図５】
2020010267.tif 000007
【図６】
2020010267.tif 000008
【図７】
2020010267.tif 000009
【図８】
2020010267.tif 000010
【図９】
2020010267.tif 000011
【図１０】
2020010267.tif 000012
【図１１】
2020010267.tif 000013
【図１２】
2020010267.tif 000014
【図１３】
2020010267.tif 000015
【図１４】
2020010267.tif 000016
【図１５】
2020010267.tif 000017
【図１６】
2020010267.tif 000018
【図１７】
2020010267.tif 000019
【図１８】
2020010267.tif 000020
【図１９】
2020010267.tif 000021
【図２０】
2020010267.tif 000022
【図２１】
2020010267.tif 000023