JP2020010267A - 分散型医療情報共有システム、医療情報提供サーバー及びプログラム - Google Patents

分散型医療情報共有システム、医療情報提供サーバー及びプログラム Download PDF

Info

Publication number
JP2020010267A
JP2020010267A JP2018131950A JP2018131950A JP2020010267A JP 2020010267 A JP2020010267 A JP 2020010267A JP 2018131950 A JP2018131950 A JP 2018131950A JP 2018131950 A JP2018131950 A JP 2018131950A JP 2020010267 A JP2020010267 A JP 2020010267A
Authority
JP
Japan
Prior art keywords
medical information
providing server
encryption
key
terminal
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
JP2018131950A
Other languages
English (en)
Inventor
直一 桑山
Naoichi Kuwayama
直一 桑山
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Konica Minolta Inc
Original Assignee
Konica Minolta Inc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Konica Minolta Inc filed Critical Konica Minolta Inc
Priority to JP2018131950A priority Critical patent/JP2020010267A/ja
Publication of JP2020010267A publication Critical patent/JP2020010267A/ja
Pending legal-status Critical Current

Links

Images

Abstract

【課題】安全性が高く、かつ利便性の高い方法により、医療データを複数のユーザー間で共有可能な分散型医療情報共有システム、医療情報提供サーバー及びプログラムを提供する。【解決手段】医療情報提供サーバーと、医療情報を提供する提供端末と、医療情報を閲覧する閲覧端末と、合意形成処理を行う分散型共有台帳を管理するブロックチェーンノードと、を備えた分散型医療情報共有システムにおいて、提供端末は、医療情報を、第１の秘密鍵を用いて暗号化する暗号化処理部を備え、医療情報提供サーバーは、第１の秘密鍵に対応する第１の公開鍵及び閲覧端末が復号可能なデータに再暗号化するための再暗号化鍵を、ブロックチェーンノードによってブロックに保存させる保存制御部と、暗号化された医療情報を、ブロックに保存された再暗号化鍵によって再暗号化して、前記閲覧端末に提供する再暗号化部と、を備える。【選択図】図１

Description

本発明は、分散型医療情報共有システム、医療情報提供サーバー及びプログラムに関する。
近年、医療技術の多様化に伴い、特定機能を持つ病院や診療所等の複数の医療施設が医療情報を共有し、連携して患者の検査や治療を行う医療連携が普及しつつある。例えば、連携先の医療施設からしか参照できない医療情報をクラウドにアップロードし、必要な時に医療情報をダウンロードするシステムが利用されている。
このように医療情報をクラウドに保存するサービスにおいては、情報発生源は医療施設のユーザーであり、閲覧権限の制御及び閲覧権限者も医療施設のユーザーとなる。医療情報は個人情報でもあるため、より安全に医療情報の受け渡しが可能なクラウドサービスが求められている。しかし、医療情報を共有するコミュニティーの規模が大きくなるにつれて、中央集権型サーバーによるデータ共有形式であると、管理コストの増大及び障害に対するリスクが増大する問題があるため、分散されたサーバー間でデータを共有する分散方式が必要となる。
上記した問題に関連して、特許文献１には、再暗号化技術を用いたデータ共有方法が開示されている。具体的には、データの再暗号化に使用する暗号鍵の一部を中継サーバーによって生成し、中継サーバーは閲覧権限者の暗号鍵によって参照できるように復号鍵を再生成し、閲覧権限者からの情報要求時にデータを参照して送信する。
また、特許文献２には、再暗号化技術を用いたデータ共有方法において、複数のユーザー間で共有するデータを保持する再暗号化装置を備え、データの送信者は閲覧権限者ごとに再暗号化に使用する公開暗号鍵を入手し、自身の秘密鍵と閲覧権限者の暗号鍵とを使用して、閲覧権限者ごとに暗号化データを作成する方法が用いられている。
このような再暗号化技術を用いたデータ共有方法では、閲覧者以外の者にデータが漏洩するリスクを低減できるため、比較的安全性が高いといえる。
特開２０１５−５６８２０号公報 特開２０１６−１３９８９４号公報
しかしながら、再暗号化技術においては、クラウドサービスの管理者と不正なユーザーの結託により、再暗号化鍵を偽造されるリスクを排除できない。即ち、何らかの理由で鍵が漏洩してしまった場合、閲覧権限者以外の者に向けた再暗号化鍵を生成することが可能となるため、不正なユーザーによって医療情報が閲覧されてしまう虞がある。
また、特許文献２のようにデータの送信者が閲覧権限者毎にデータを暗号化させるものとすると、閲覧権限者が追加される度に送信者の秘密鍵を使用した暗号化及び再暗号化が必要となるため、鍵の管理が煩雑化する。
本発明は上記課題に鑑みてなされたものであって、安全性が高く、かつ利便性の高い方法により、医療データを複数のユーザー間で共有可能な分散型医療情報共有システム、医療情報提供サーバー及びプログラムを提供することを目的とする。
上記課題を解決するため、請求項１に記載の分散型医療情報共有システムは、
医療情報を記憶する医療情報提供サーバーと、前記医療情報提供サーバーに医療情報を提供する提供端末と、前記医療情報提供サーバーに記憶された医療情報を閲覧する閲覧端末と、合意形成処理を行う分散型共有台帳を管理するブロックチェーンノードと、を備えた分散型医療情報共有システムにおいて、
前記提供端末は、
医療情報を、第１の秘密鍵を用いて暗号化する暗号化処理部を備え、
前記医療情報提供サーバーは、
前記第１の秘密鍵に対応する第１の公開鍵及び前記閲覧端末が復号可能なデータに再暗号化するための再暗号化鍵を、前記ブロックチェーンノードによってブロックに保存させる保存制御部と、
暗号化された医療情報を、ブロックに保存された前記再暗号化鍵によって再暗号化して、前記閲覧端末に提供する再暗号化部と、を備える
ことを特徴とする。
請求項２に記載の発明は、請求項１に記載の分散型医療情報共有システムにおいて、
前記提供端末は、
前記第１の公開鍵及び前記第１の秘密鍵を生成する第１の暗号鍵生成部を備える
ことを特徴とする。
請求項３に記載の発明は、請求項１又は２に記載の分散型医療情報共有システムにおいて、
前記提供端末は、
暗号化された医療情報を、閲覧端末が復号可能なデータに再暗号化するための再暗号化鍵を生成する再暗号化鍵生成部と、を備える
ことを特徴とする。
請求項４に記載の発明は、請求項３に記載の分散型医療情報共有システムにおいて、
前記再暗号化鍵生成部は、公開先の閲覧端末が変更される場合において、暗号化された医療情報を、新たに閲覧権限を取得した閲覧端末が復号可能なデータに再暗号化するための新規の再暗号化鍵を生成し、
前記再暗号化部は、暗号化された医療情報を、前記新規の再暗号化鍵によって再暗号化して、前記新たに閲覧権限を取得した閲覧端末に提供する
ことを特徴とする。
請求項５に記載の発明は、請求項１から４のいずれか一項に記載の分散型医療情報共有システムにおいて、
前記医療情報提供サーバーは、
前記提供端末により暗号化された医療情報を記憶する記憶部を備える
ことを特徴とする。
請求項６に記載の発明は、請求項１から５のいずれか一項に記載の分散型医療情報共有システムにおいて、
前記閲覧端末は、
第２の公開鍵及び第２の秘密鍵を生成する第２の暗号鍵生成部と、
再暗号化された医療情報を、前記第２の公開鍵を用いて復号する復号処理部と、を備える
ことを特徴とする。
請求項７に記載の医療情報提供サーバーは、
医療情報を記憶する医療情報提供サーバーと、医療情報を、第１の秘密鍵を用いて暗号化する暗号化処理部を備え、前記医療情報提供サーバーに医療情報を提供する提供端末と、前記医療情報提供サーバーに記憶された医療情報を閲覧する閲覧端末と、合意形成処理を行う分散型共有台帳を管理するブロックチェーンノードと、を備えた分散型医療情報共有システムにおける医療情報提供サーバーであって、
前記医療情報提供サーバーは、
前記第１の秘密鍵に対応する第１の公開鍵及び前記閲覧端末が復号可能なデータに再暗号化するための再暗号化鍵を、前記ブロックチェーンノードによってブロックに保存させる保存制御部と、
暗号化された医療情報を、ブロックに保存された前記再暗号化鍵によって再暗号化して、前記閲覧端末に提供する再暗号化部と、を備える
ことを特徴とする。
請求項８に記載の発明は、請求項７に記載の医療情報提供サーバーにおいて、
前記提供端末により暗号化された医療情報を記憶する記憶部を備える
ことを特徴とする。
請求項９に記載のプログラムは、
医療情報を記憶する医療情報提供サーバーと、医療情報を、第１の秘密鍵を用いて暗号化する暗号化処理部を備え、前記医療情報提供サーバーに医療情報を提供する提供端末と、前記医療情報提供サーバーに記憶された医療情報を閲覧する閲覧端末と、合意形成処理を行う分散型共有台帳を管理するブロックチェーンノードと、を備えた分散型医療情報共有システムにおいて、
前記医療情報提供サーバーのコンピューターを、
前記第１の秘密鍵に対応する第１の公開鍵及び前記閲覧端末が復号可能なデータに再暗号化するための再暗号化鍵を、前記ブロックチェーンノードによってブロックに保存させる保存制御部、
暗号化された医療情報を、ブロックに保存された前記再暗号化鍵によって再暗号化して、前記閲覧端末に提供する再暗号化部、として機能させる
ことを特徴とする。
本発明によれば、安全性が高く、かつ利便性の高い方法により、医療データを複数のユーザー間で共有可能な分散型医療情報共有システム、医療情報提供サーバー及びプログラムを提供することができる。
医療情報共有システムのシステム構成の一例を示す図である。 利用者端末のハードウェア構成の一例を示す図である。 情報提供サーバーのハードウェア構成の一例を示す図である。 ブロックチェーンノードのハードウェア構成の一例を示す図である。 医療情報共有システムの各装置の機能的構成の一例を示す図である。 医療情報共有システムの各装置の機能的構成の一例を示す図である。 ブロックチェーンの構成図である。 ブロックチェーン登録シーケンスにおける各装置の動作を示すシーケンス図である。 情報提供サーバー登録時における各装置の動作を示すシーケンス図である。 利用者アカウント登録時における各装置の動作を示すシーケンス図である。 ブロックチェーン登録依頼電文の構成を示す図である。 医療情報登録時における各装置の動作を示すシーケンス図である。 アクセス権限登録時における各装置の動作を示すシーケンス図である。 アクセス権限登録依頼電文の構成を示す図である。 情報開示要求時における各装置の動作を示すシーケンス図である。 情報開示要求登録依頼電文の構成を示す図である。 医療情報開示要求の検索時における各装置の動作を示すシーケンス図である。 医療情報参照時における各装置の動作を示すシーケンス図である。 アクセス権限変更時における各装置の動作を示すシーケンス図である。 アクセス権限削除時における各装置の動作を示すシーケンス図である。 再暗号化依頼電文の構成を示す図である。
以下、図面を参照して本発明に係る医療情報共有システムの実施の形態について説明する。なお、本発明は、図示例に限定されるものではない。
＜医療情報共有システム１００の構成＞
図１に、本実施形態における医療情報共有システム１００（分散型医療情報共有システム）のシステム構成を示す。
図１に示すように、医療情報共有システム１００は、連携先医療施設１に設置された利用者端末１０と、クラウドＣ上で動作する複数の情報提供サーバー２０及びｎ台のブロックチェーンノード３０（１）〜３０（ｎ）と、を備えて構成される。利用者端末１０、情報提供サーバー２０及びブロックチェーンノード３０は、インターネット等の通信ネットワークを介してデータ通信可能に接続されている。
なお、本実施形態においては、連携先医療施設１Ａに設置された利用者端末１０Ａは情報提供サーバー２０Ａに、連携先医療施設１Ｂに設置された利用者端末１０Ｂは情報提供サーバー２０Ｂに、それぞれアクセスすることを想定しており、各連携先医療施設１内の利用者端末１０の数は、特に限定されない。また、情報提供サーバー２０の数は、特に限定されない。
利用者端末１０は、医療施設におけるユーザーが、情報提供サーバー２０に対して医療情報を提供、あるいは情報提供サーバーから医療情報を取得して閲覧を行うために用いるコンピューターである。なお、本実施形態においては、利用者端末１０Ａは提供端末、利用者端末１０Ｂは閲覧端末として機能する。
利用者端末１０は、ＬＡＮ（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）とは、分散システム上で統制なしに作成できる識別子として設計されたＩＤであり、将来にわたって重複しないことを前提に用いることができる。
図１０は、各装置の動作を示すシーケンス図である。以下では、利用者アカウントＡを登録する場合を説明する。
まず、利用者端末１０Ａは、利用者を認証する情報が入力されると、ユーザー識別ＵＵＩＤを生成する（ステップＳ３０１）。続いて、利用者端末１０Ａは、ユーザー識別ＵＵＩＤに紐づく公開鍵ＫＡｐ及び秘密鍵ＫＡｐ −１を生成する（ステップＳ３０２）。
続いて、利用者端末１０Ａは、任意の文字列を生成し、秘密鍵ＫＡｐ −１で暗号化したものを、公開鍵確認情報とする（ステップＳ３０３）。なお、任意の文字列は利用者端末１０Ａしか知りえない情報である。
次いで、利用者端末１０Ａは、情報提供サーバー２０Ａに対してブロックチェーン登録依頼要求を行う（ステップＳ３０４）。
図１１は、ステップＳ３０４で送信されるブロックチェーン登録依頼電文の構造を示した図である。図１１に示すように、ブロックチェーン登録依頼電文５１０は、利用者アカウントＡのユーザー識別ＵＵＩＤ５１１と、登録依頼電文の種別（ここでは、ユーザー識別登録）を表す種別情報５１２と、公開鍵（ここでは、公開鍵ＫＡｐ）を表す公開鍵情報５１３と、上記した公開鍵確認情報５１４と、を備えて構成される。
したがって、ここでは、登録データ４２０としてユーザー識別ＵＵＩＤ５１１、公開鍵情報５１３、公開鍵確認情報５１４を送信する。
情報提供サーバー２０はブロックチェーン登録依頼要求を受け付けると、電文構成が正しい場合には、ブロックの追加を要求し、ブロックチェーンノード３０との間で図８に示すブロックチェーン登録シーケンスを実行する（ステップＳ３０５）。
ブロックが登録されると、情報提供サーバー２０Ａは、利用者端末１０Ａに対してブロックチェーン登録依頼応答を行う（ステップＳ３０６）。
利用者端末１０Ａは、ユーザー識別ＵＵＩＤを用いて情報提供サーバー２０Ａからブロックチェーンを取得し、ブロックチェーンに登録された公開鍵確認情報を自身の秘密鍵ＫＡｐ −１で復号して、正常に登録されたか否かを判断する。
以上の処理を、利用者アカウントＢについても同様に実行する。
なお、情報提供サーバー２０Ａが不正なプログラムで制御されている場合には、ブロックの登録が偽装されている可能性があるが、その他の信頼できる複数の情報提供サーバー２０に対して問い合わせを行い、正しく登録されていることを確認するものとしてもよい。
（３）利用者端末からの医療情報の送信
利用者アカウントＡによってログインされた利用者端末１０Ａから、医療情報を入力する。このとき、閲覧権限者が決まっている必要はない。医療情報のデータをＭとし、利用者端末１０Ａ内で、鍵の付け替え可能な再暗号化技術Ｅｎｃによって暗号化される。この時の暗号化に使用する鍵は、一時的に生成した付け替え用の鍵ＫＡｔと、利用者端末１０Ａ内で生成した再暗号化用の公開鍵ＫＡｐとの合成鍵ＫＡｔ・ＫＡｐである。また、暗号化されたデータは、Ｅｎｃ（ＫＡｔ・ＫＡｐ，Ｍ）で表され、情報提供サーバー２０Ａに送信される。なお、この時点で当該暗号化データを復元できるのは、逆元の鍵ＫＡｔ −１と秘密鍵ＫＡｐ −１とを有する利用者端末１０Ａのみである。
図１２は、各装置の動作を示すシーケンス図である。
医療情報Ｍが入力されると（ステップＳ４０１）、当該医療情報Ｍに紐づく医療情報識別ＵＵＩＤを生成するとともに（ステップＳ４０２）、鍵付け替え用の鍵ＫＡｔとその逆元の鍵ＫＡｔ −１をその都度新たに生成する（ステップＳ４０３）。
次いで、利用者端末１０は、鍵付け替え用の鍵ＫＡｔと公開鍵ＫＡｐとを合成して再暗号化鍵ＫＡｔ・ＫＡｐとし（ステップＳ４０４）、医療情報Ｍを再暗号化鍵ＫＡｔ・ＫＡｐで暗号化して、暗号化医療情報Ｅｎｃ（ＫＡｔ・ＫＡｐ，Ｍ）を生成する（ステップＳ４０５）。
続いて、利用者端末１０Ａは、情報提供サーバー２０に対して医療情報登録依頼要求を行う（ステップＳ４０６）。ここでは、登録データ４２０として、医療情報識別ＵＵＩＤ及び暗号化医療情報Ｅｎｃ（ＫＡｔ・ＫＡｐ，Ｍ）が送信される。
情報提供サーバー２０Ａは、暗号化医療情報を受け取ると、医療情報識別ＵＵＩＤと暗号化医療情報Ｅｎｃ（ＫＡｔ・ＫＡｐ，Ｍ）を紐づけた状態で保存し、利用者端末１０Ａに医療情報を登録した旨を応答する（ステップＳ４０７）。
これ以降は、情報提供サーバー２０Ａ及び利用者端末１０Ａは、医療情報識別ＵＵＩＤを管理し、情報提供サーバー２０Ａは、利用者端末１０Ａから医療情報識別ＵＵＩＤによる問い合わせがあった場合に、医療情報識別ＵＵＩＤに紐づく医療情報を応答する。
なお、情報提供サーバー２０は、自分自身が管理していない医療情報識別ＵＵＩＤに関する要求電文を受信した場合、他の情報提供サーバー２０に転送するとともに、転送済みの電文を再度受け取った場合には転送しないものとする。
なお、送信した医療情報を閲覧者によってアクセス可能範囲を分ける場合には、その範囲毎に、鍵付け替え用の鍵ＫＡｔとは異なる一時的な付け替え用の鍵ＫＡｕ及びその逆元の鍵ＫＡｕ −１を生成し、当該範囲に対して合成された暗号鍵ＫＡｕ・ＫＡｔ・ＫＡｐを使用して暗号化し、Ｅｎｃ（ＫＡｕ・ＫＡｔ・ＫＡｐ，Ｍ’）を生成して送信する。
（４）医療情報へのアクセス権限の登録
（４−１）利用者アカウントＡによる利用者アカウントＢへのアクセス権限付与
利用者アカウントＡは、送信した医療情報を利用者端末１０Ｂの利用者アカウントＢに閲覧権限を付与する場合に、利用者アカウントＢのアクセス権限をブロックチェーンに登録する。なお、利用者アカウントＡと利用者アカウントＢは、事前に互いのユーザー識別ＵＵＩＤを、医療情報共有システムとは無関係に知っていることを前提とする。また、情報提供サーバー２０には、ユーザー識別ＵＵＩＤが残される可能性があるが、それがどのアカウントと紐づいているかを情報提供サーバー２０が知る必要はない。
図１３は、各装置の動作を示すシーケンス図である。
利用者端末１０Ａは、アクセス権限を与えるユーザー識別ＵＵＩＤを選択する（ステップＳ５０１）。ここでは、利用者アカウントＢにアクセス権限を与えるため、利用者アカウントＢに紐づくユーザー識別ＵＵＩＤを選択する。
次いで、利用者端末１０Ａは、情報提供サーバー２０Ａに対して、ブロックチェーン情報取得要求を行う（ステップＳ５０２）。このとき、利用者端末１０Ａは、利用者アカウントＢのユーザー識別ＵＵＩＤを送信する。
ブロックチェーン情報取得要求を受け付けると、情報提供サーバー２０Ａは、ユーザー識別ＵＵＩＤの公開鍵ＫＢｐが情報提供サーバー２０Ａのキャッシュに存在しない場合、ブロックチェーンノード３０から取得するために、ブロックチェーンノード３０に対してブロックチェーン情報取得要求を行う（ステップＳ５０３）。ｎ台のブロックチェーンノード３０は、それぞれユーザー識別ＵＵＩＤの公開鍵ＫＢｐを取得し、情報提供サーバー２０Ａに応答する（ステップＳ５０４）。
情報提供サーバー２０Ａは、公開鍵ＫＢｐの情報として３ｆ＋１台のブロックチェーンノード３０から同値が応答された時、当該値が正しいと判断し（ステップＳ５０５）、利用者端末１０Ａに対してユーザー識別ＵＵＩＤの公開鍵ＫＢｐを送信し、ブロックチェーン情報取得応答を行う（ステップＳ５０６）。
利用者端末１０Ａは、ユーザー識別ＵＵＩＤに紐づく秘密鍵ＫＡｐ −１と、医療情報識別ＵＵＩＤに紐づく秘密鍵ＫＡｔ −１と、アクセス権限を与えるユーザー識別ＵＵＩＤに紐づく公開鍵ＫＢｐとから、再暗号化鍵ＫＢｐ・ＫＡｐ −１・ＫＡｔ −１を生成する（ステップＳ５０７）。
続いて、利用者端末１０Ａは、情報提供サーバー２０Ａに対してアクセス権限登録依頼電文を送信して、ブロックチェーン登録依頼要求を行う（ステップＳ５０８）。
図１４は、アクセス権限登録依頼電文５２０の構成の一例である。アクセス権限登録依頼電文５２０は、医療情報識別ＵＵＩＤ５２１と、種別情報５２２と、アクセス権限リスト５２３と、アクセス権限付与先情報５２４と、復号後のハッシュ値５２５と、等を有する。
医療情報識別ＵＵＩＤ５２１は、利用者アカウントＡが利用者アカウントＢに参照を期待する医療情報に紐づいている。
種別情報５２２は、当該ブロックチェーン登録依頼の種別を表し、ここではアクセス権限登録である。
アクセス権限リスト５２３は、医療情報識別ＵＵＩＤ以外での検索可能な項目（ここでは、検索１及び検索２の各項目）が存在する場合には、項目を表す検索１用のハッシュ値と、検索２用のハッシュ値と、等がそれぞれ分けて登録される。なお、当該データを保存する情報提供サーバー２０のＩＰアドレスが、保存先ＩＰアドレスとして保存される。なお、アクセス権限リスト５２３は、情報提供サーバー２０が参照することが可能である。
アクセス権限付与先情報５２４（＃１）には、相手先ユーザー識別ＵＵＩＤとして利用者アカウントＢのユーザー識別ＵＵＩＤと、再暗号化鍵ＫＢｐ・ＫＡｐ −１・ＫＡｔ −１と、が登録される。なお、アクセス権限付与先情報５２４は、一つのブロックに複数同時に登録することができる。したがって、複数の利用者アカウントにアクセス権限を付与する場合には、それぞれ異なるアクセス権限付与先情報５２４（＃２、＃３、・・・）に分けて登録される。
復号後のハッシュ値５２５は、暗号化医療情報Ｅｎｃ（ＫＡｔ・ＫＡｐ，Ｍ）を復号したデータをハッシュ関数により演算して得られたハッシュ値であり、後述するように、利用者アカウントＢによる再暗号化された医療情報の復号時に、当該医療情報が正しいものであるかを確認する際に用いられる。
したがって、ここでは、登録データ４２０として医療情報識別ＵＵＩＤ５２１、アクセス権限付与先情報５２４（相手先ユーザー識別ＵＵＩＤ及び再暗号化鍵）が送信される。
なお、医療情報識別ＵＵＩＤ５２１及び種別情報５２２は、誰にでも検索可能であるが、その他の項目については、自身の再暗号化鍵以外は入手しても活用することができない。
情報提供サーバー２０Ａがブロックチェーン登録依頼要求を受け付けると、情報提供サーバー２０Ａ及びブロックチェーンノード３０は、図８に示すブロックチェーン登録シーケンスを行う（ステップＳ５０９）。ブロックチェーン登録シーケンスが完了すると、情報提供サーバー２０Ａは利用者端末１０Ａに対してブロックチェーン登録依頼応答を行い（ステップＳ５１０）、制御を終了する。
以上説明した方法により、情報提供サーバー２０又はブロックチェーンノード３０が不正侵入されて、再暗号化鍵が入手されても、ユーザー識別ＵＵＩＤに紐づく秘密鍵ＫＢｐ −１は利用者端末１０Ｂのみが保有するため、情報提供サーバー２０及びブロックチェーンノード３０は再暗号化された医療情報を復号することができない。
仮に秘密鍵ＫＢｐ −１を有する利用者端末１０Ｂが不正に操作された場合、または情報提供者である利用者端末１０Ａが誤って利用者端末１０Ｂにアクセス権限を付与してしまったとしても、ＫＡｐ −１・ＫＡｔ −１は流出するが、ＫＡｐ −１自体は流出しない。したがって、利用者端末１０Ａから利用者端末１０Ｂに共有された暗号化医療情報Ｅｎｃ（ＫＡｔ・ＫＡｐ，Ｍ）は流出するが、その他の情報は流出しない。
なお、アクセス権限を追加する場合には、後述するように図１８のシーケンスにしたがって処理を行い、アクセス権限の一部を削除する場合には、図１９のシーケンスにしたがって処理を行う。
（４−２）利用者アカウントＢによるアクセス権限付与の要求
一方で、利用者アカウントＢが、利用者アカウントＡに、ある特定の検索項目に合致する医療情報の入手を希望した場合には、利用者アカウントＢは、特定の検索項目に合致する医療情報識別ＵＵＩＤの一覧を作成し、それぞれの医療情報識別ＵＵＩＤに紐づくアクセス権限のブロックチェーン登録依頼電文を、情報提供サーバー２０Ｂに送信する。
図１５は、各装置の動作を示すシーケンス図である。
利用者端末１０Ｂは、検索項目のハッシュ値を求める（ステップＳ６０１）。続いて、情報提供サーバー２０Ｂに対して、情報検索依頼要求を行う（ステップＳ６０２）。このとき、利用者アカウントＢのユーザー識別ＵＵＩＤと、ステップＳ６０１で求めた検索項目のハッシュ値とを送信することで、ハッシュ値による情報検索を要求する。
情報提供サーバー２０Ｂは、ハッシュ値によって自身のキャッシュを検索する（ステップＳ６０３）。情報提供サーバー２０Ｂは、検索が完了すると、利用者端末１０Ｂに対して情報検索応答を行う（ステップＳ６０４）。
利用者端末１０Ｂは、情報提供サーバー２０Ｂに対して情報開示要求登録依頼電文を送信して、医療情報開示要求を行う（ステップＳ６０５）。
図１６は、情報開示要求登録依頼電文５３０の構成の一例である。情報開示要求登録依頼電文５３０は、医療情報識別ＵＵＩＤ５３１と、種別情報５３２と、アクセス権限リスト５３３と、情報提供ユーザー識別ＵＵＩＤ５３４と、情報開示ユーザー識別ＵＵＩＤ５３５と、等を有する。
医療情報識別ＵＵＩＤ５３１は、利用者アカウントＢが閲覧を希望する医療情報に紐づいている。
種別情報５３２は、ここでは情報開示要求である。
アクセス権限リスト５３３は、情報開示を要求する検索項目（ここでは、検索１及び検索２の各項目）をリストとした情報である。
情報提供ユーザー識別ＵＵＩＤ５３４は、情報提供者である利用者アカウントＡのユーザー識別ＵＵＩＤを表す。
情報開示ユーザー識別ＵＵＩＤ５３５は、情報の提供を依頼する利用者アカウントＢのユーザー識別ＵＵＩＤを表す。
したがって、ここでは、登録データ４２０として、医療情報識別ＵＵＩＤ５３１、情報提供ユーザー識別ＵＵＩＤ５３４、情報開示ユーザー識別ＵＵＩＤ５３５が送信される。
情報提供サーバー２０Ｂが医療情報開示要求を受け付けると、情報提供サーバー２０及びブロックチェーンノード３０は、図８に示すブロックチェーン登録シーケンスを行う（ステップＳ６０６）。ブロックチェーン登録シーケンスが完了すると、情報提供サーバー２０Ｂは利用者端末１０Ｂに対して医療情報開示要求応答を行い（ステップＳ６０７）、制御を終了する。
一方で、利用者端末１０Ａは、定期的に情報提供ユーザー識別ＵＵＩＤとして自身を利用する利用者アカウントＡが登録されたブロックチェーンのブロックを検索する。当該ブロックの存在を確認した場合、情報開示要求を行ったユーザー識別ＵＵＩＤを確認し、問題がないと判別できる場合には、アクセス権限登録のブロックチェーン登録依頼電文を情報提供サーバー２０Ａに送信する。
図１７は、各装置の動作を示すシーケンス図である。
利用者端末１０Ａは、自らを利用する利用者アカウントのユーザー識別ＵＵＩＤに紐づく医療情報開示要求を、任意の契機で検索する（ステップＳ７０１）。利用者端末１０Ａは、検索を行うタイミングであると判断した場合に、情報提供サーバー２０Ａに対して、医療情報開示要求検索を要求する（ステップＳ７０２）。このとき、利用者アカウントＡのユーザー識別ＵＵＩＤを情報提供サーバー２０Ａに送信する。
情報提供サーバー２０Ａは、ユーザー識別ＵＵＩＤを糸口に、情報開示要求検索を実行する（ステップＳ７０３）。情報提供サーバー２０Ａは、ブロックチェーンノード３０に対して、ブロックチェーン情報取得要求を行う（ステップＳ７０４）。このとき、情報提供サーバー２０は、利用者アカウントＡのユーザー識別ＵＵＩＤをブロックチェーンノード３０に送信する。
各ブロックチェーンノード３０は、ブロックチェーン情報取得要求を受け付けると、医療情報開示要求検索を実行し、検索結果として医療情報識別ＵＵＩＤ及び相手先ユーザー識別ＵＵＩＤの情報を、情報提供サーバー２０Ａに応答する（ステップＳ７０５）。即ち、ｎ台のブロックチェーンノード３０からの応答がなされる。
情報提供サーバー２０Ａは、３ｆ＋１台以上のブロックチェーンノード３０から同値が応答された時、当該値は正しいと判断し（ステップＳ７０６）、利用者端末１０Ａに対して医療情報識別ＵＵＩＤ及び情報開示要求を行った相手先ユーザー識別ＵＵＩＤ（ここでは、利用者アカウントＢのユーザー識別ＵＵＩＤ）の情報を送信し、医療情報検索応答を行い（ステップＳ７０７）、制御を終了する。
以上の処理によって情報開示要求が検出された場合、相手先ユーザー識別ＵＵＩＤが既知で、指定された医療情報識別ＵＵＩＤの情報開示に問題がないと判断した場合、図１３のアクセス権限付与時のブロックチェーン登録シーケンスが実行される。
（５）再暗号化した医療情報の送信
利用者アカウントＢが利用者端末１０Ｂにログインすると、利用者端末１０Ｂが利用者アカウントＢのユーザー識別ＵＵＩＤに紐づくアクセス権限登録のブロックが存在するか否かを、自身が通信を行う情報提供サーバー２０Ｂに問い合わせ、情報提供サーバー２０Ｂから医療情報を取得し、利用者アカウントＢによって閲覧可能とする。
図１８は、各装置の動作を示すシーケンス図である。
利用者端末１０Ｂは、検索項目のハッシュ値を求める（ステップＳ８０１）。次いで、利用者端末１０Ｂは、情報提供サーバー２０Ｂに対してアクセス権限検索要求を行い、利用者アカウントＢのアクセス権限登録のブロックの存在を問い合わせる（ステップＳ８０２）。このとき、利用者端末１０Ｂは、利用者アカウントＢのユーザー識別ＵＵＩＤ及び検索項目のハッシュ値を送信する。
情報提供サーバー２０Ｂは、ハッシュ値による自身のキャッシュの検索を実行し、自身のキャッシュに存在する場合には検索結果を利用者端末１０Ｂに応答する（ステップＳ８０３）。
情報提供サーバー２０Ｂは、自身のキャッシュに存在しない場合には、ブロックチェーンノード３０に対してブロックチェーン情報取得要求を行う（ステップＳ８０４）。このとき、情報提供サーバー２０Ｂは、ブロックチェーンノード３０に医療情報識別ＵＵＩＤを送信する。
各ブロックチェーンノード３０は、ブロックを検索してブロックチェーン情報取得応答を行う（ステップＳ８０５）。即ち、ｎ台のブロックチェーンノード３０からの応答がなされる。このとき、ブロックチェーンノード３０は、医療情報識別ＵＵＩＤ及び保存ＩＰ先アドレスを情報提供サーバー２０Ｂに送信する。
続いて、情報提供サーバー２０Ｂは、利用者端末１０Ｂに対して、医療情報識別ＵＵＩＤ及び保存先ＩＰアドレスを送信してアクセス権限検索応答を行う（ステップＳ８０６）。
利用者端末１０Ｂは、保存先ＩＰアドレスに紐づく情報提供サーバー２０Ａに対して、医療情報識別ＵＵＩＤ及び情報提供ユーザー識別ＵＵＩＤを送信することで、医療情報参照要求を行う（ステップＳ８０７）。
情報提供サーバー２０Ａは、自身のキャッシュに再暗号化鍵が存在しない場合、ブロックチェーンノード３０に対して医療情報識別ＵＵＩＤを送信することで、ブロックチェーン情報取得要求を行う（ステップＳ８０８）。
ｎ台のブロックチェーンノード３０は、それぞれ情報提供サーバー２０Ａに対して再暗号化鍵を送信することで、ブロックチェーン情報取得応答を行う（ステップＳ８０９）。なおブロックには、上記したように暗号化医療情報Ｅｎｃ（ＫＡｔ・ＫＡｐ，Ｍ）に対応する再暗号化鍵ＫＢｐ・ＫＡｐ −１・ＫＡｔ −１が保存されている。
情報提供サーバー２０Ａは、３ｆ＋１台以上のブロックチェーンノード３０から同値が応答された時、当該値は正しいと判断する（ステップＳ８１０）。
続いて、情報提供サーバー２０Ａは、再暗号化鍵ＫＢｐ・ＫＡｐ −１・ＫＡｔ −１によって暗号化医療情報Ｅｎｃ（ＫＡｔ・ＫＡｐ，Ｍ）を再暗号化する（ステップＳ８１１）
次いで、情報提供サーバー２０Ａは、再暗号化した医療情報を、利用者端末１０Ｂに送信することで、医療情報参照要求応答を行う（ステップＳ８１２）
ここで、再暗号化鍵ＫＢｐ・ＫＡｐ −１・ＫＡｔ −１による暗号化医療情報Ｅｎｃ（ＫＡｔ・ＫＡｐ，Ｍ）の再暗号化においては、以下の式（５）が成立し、鍵の付け替えに成功する。
Ｅｎｃ（ＫＢｐ・ＫＡｐ −１・ＫＡｔ −１，（Ｅｎｃ（ＫＡｔ・ＫＡｐ，Ｍ））
＝Ｅｎｃ（ＫＢｐ・ＫＡｐ −１・ＫＡｔ −１・ＫＡｔ・ＫＡｐ，Ｍ）
＝Ｅｎｃ（ＫＢｐ・ＫＡｐ −１・ＫＡｐ，Ｍ）
＝Ｅｎｃ（ＫＢｐ，Ｍ） ・・・（５）
利用者端末１０Ｂに再暗号化医療情報Ｅｎｃ（ＫＢｐ，Ｍ）が送信されると、利用者端末１０Ｂは、利用者端末１０Ｂのみが保有する秘密鍵ＫＢｐ −１によって復号して医療情報Ｍを取得して（ステップＳ８１３）、制御を終了する。
ここで、秘密鍵ＫＢｐ −１による再暗号化医療情報Ｅｎｃ（ＫＢｐ，Ｍ）の復号においては、以下の式（６）が成立する。
Ｅｎｃ（ＫＢｐ −１，Ｅｎｃ（ＫＢｐ，Ｍ））
＝Ｅｎｃ（ＫＢｐ −１・ＫＢｐ，Ｍ）
＝Ｍ ・・・（６）
なお、もし暗号化医療情報がＥｎｃ（ＫＡｔ・ＫＡｐ，Ｍ）でなければ、利用者端末１０Ｂはダウンロードに成功しても、元の医療情報に秘密鍵ＫＢｐ −１を用いて復元することができない。これは、アクセス権限登録において登録した復号後のハッシュ値５２５と、実際に復号したデータのハッシュ値との比較を行うことで確認可能である。
（６）アクセス権限登録の追加または削除
（６−１）アクセス権限登録の追加
利用者アカウントＡが、新たに利用者アカウントＣにアクセス権限を付与する場合は、以下のようにしてアクセス権限登録を行う。
図１９は、各装置の動作を示すシーケンス図である。
利用者端末１０Ａは、新たにアクセス権限を与える利用者アカウントＣに紐づくユーザー識別ＵＵＩＤを事前に知っていることを前提とし、選択する（ステップＳ９０１）。
ステップＳ９０２及びステップＳ９０３の処理は、図１３におけるステップＳ５０２及びステップＳ５０３の処理と同様であるため、説明を省略する。
ステップＳ９０４では、ｎ台のブロックチェーンノード３０は、それぞれユーザー識別ＵＵＩＤの公開鍵ＫＣｐを取得し、情報提供サーバー２０Ａに応答する。
ステップＳ９０５及びステップＳ９０６の処理は、図１３におけるステップＳ５０５及びステップＳ５０６の処理と同様であるため、説明を省略する。
ステップＳ９０７では、利用者端末１０Ａは、自身の秘密鍵ＫＡｐ −１と、医療情報識別ＵＵＩＤに紐づく逆元の鍵ＫＡｔ −１と、アクセス権限を与えるユーザー識別ＵＵＩＤに紐づく公開鍵ＫＣｐとから、再暗号化鍵ＫＣｐ・ＫＡｐ −１・ＫＡｔ −１を生成する。
ステップＳ９０８〜ステップＳ９１０の処理は、図１３におけるステップＳ５０８〜ステップＳ５１０の処理と同様であるため、説明を省略する。
したがって、利用者アカウントＣが利用する利用者端末１０においては、再暗号化鍵ＫＣｐ・ＫＡｐ −１・ＫＡｔ −１によって再暗号化された医療情報Ｅｎｃ（ＫＣｐ，Ｍ）を、秘密鍵ＫＣｐ −１によって復号化して医療情報Ｍを取得することが可能となる。
（６−２）アクセス権限登録の削除
利用者アカウントＡが、特定の医療情報についてのアクセス権限を付与した利用者アカウントを削除する場合には、以下のようにしてアクセス権限登録の削除を行う。
図２０は、各装置の動作を示すシーケンス図である。
利用者端末１０Ａは、アクセス権限の削除に係る医療情報識別ＵＵＩＤを選択する（ステップＳ１００１）。
続いて、利用者端末１０Ａは、鍵付け替え用の鍵ＫＡｔ及びその逆元の鍵ＫＡｔ −１とは異なる、一度しか使用しない鍵付け替え用の鍵ＫＡｔ２及びその逆元の鍵ＫＡｔ２ −１を生成する（ステップＳ１００２）。さらに、利用者端末１０Ａは、鍵付け替え用の鍵ＫＡｔ２と鍵ＫＡｔの逆元の鍵ＫＡｔ −１とから、再暗号化鍵ＫＡｔ２・ＫＡｔ −１を生成する（ステップＳ１００３）。
続いて、利用者端末１０Ａは、再暗号化依頼要求電文を情報提供サーバー２０Ａに送信することにより、再暗号化依頼要求を行う（ステップＳ１００４）。
図２１は、再暗号化依頼要求電文５４０の構成の一例である。再暗号化依頼要求電文５４０は、医療情報識別ＵＵＩＤ５４１と、種別情報５４２と、再暗号化鍵５４３と、再暗号化前のハッシュ値５４４と、再暗号化後のハッシュ値と、等を有する。
医療情報識別ＵＵＩＤ５２１は、アクセス権限の削除に係る医療情報に紐づいている。
種別情報５２２は、ここでは再暗号化である。
再暗号化鍵５４３は、ここではＫＡｔ２・ＫＡｔ −１である。
再暗号化前のハッシュ値５４４は、暗号化医療情報Ｅｎｃ（ＫＡｔ・ＫＡｐ，Ｍ）を再暗号化鍵ＫＡｔ２・ＫＡｔ −１で再暗号化する前のデータをハッシュ関数により演算して得られたハッシュ値である。
再暗号化後のハッシュ値５４５は、暗号化医療情報Ｅｎｃ（ＫＡｔ・ＫＡｐ，Ｍ）を再暗号化鍵ＫＡｔ２・ＫＡｔ −１で再暗号化した後のデータをハッシュ関数により演算して得られたハッシュ値である。
再暗号化依頼要求を受け付けると、情報提供サーバー２０Ａは、医療情報識別ＵＵＩＤに紐づく暗号化医療情報Ｅｎｃ（ＫＡｔ・ＫＡｐ，Ｍ）を、再暗号化鍵ＫＡｔ２・ＫＡｔ −１で再暗号化する（ステップＳ１００５）。即ち、以下の式（７）が成立する。
Ｅｎｃ（ＫＡｔ２・ＫＡｔ −１，（Ｅｎｃ（ＫＡｔ・ＫＡｐ，Ｍ））
＝Ｅｎｃ（ＫＡｔ２・ＫＡｔ −１・ＫＡｔ・ＫＡｐ，Ｍ）
＝Ｅｎｃ（ＫＡｔ２・ＫＡｐ，Ｍ） ・・・（７）
これにより、ＫＡｔ２ −１及びＫＡｐ −１を保有する利用者端末１０Ａ以外の全ての利用者端末で、一時的に再暗号化された医療情報を復号できなくなる。
情報提供サーバー２０Ａは、再暗号化依頼応答を利用者端末１０Ａに送信すると（ステップＳ１００６）、制御を終了する。
なお、利用者アカウントＡが、新たに他の利用者アカウントにアクセス権限を付与する場合、新たなアクセス権限のブロックチェーン登録依頼電文を情報提供サーバー２０Ａに送信する。これにより、医療情報Ｍを閲覧可能な利用者アカウントに紐づくアクセス権限登録のブロックは複数存在することとなるが、新しいアクセス権限登録を正しいものとすることで、制御することが可能である。
以上説明したように、本実施形態に係る医療情報共有システム１００においては、利用者端末１０Ａは、秘密鍵を用いて医療情報を暗号化し、情報提供サーバー２０Ａは、秘密鍵に対応する公開鍵及び再暗号化鍵をブロックチェーンノードに保存させるとともに、暗号化された医療情報を、再暗号化鍵によって再暗号化して、利用者端末１０Ｂに提供する。
したがって、情報提供サーバー２０は暗号化されたデータのみを管理することになるため、情報提供サーバー２０の増加などの際の医療情報の管理も簡便である。また、ブロックチェーン技術によって鍵の偽装および漏洩を防ぎ、閲覧権限者が管理する復号鍵でのみ復元できるようにすることで、医療情報が不正なユーザーによって閲覧されないようリスクを低減させ、安全性を向上させることができる。
また、本実施形態に係る医療情報共有システム１００においては、利用者端末１０自身が暗号化鍵及び再暗号化鍵を生成するため、効率的であるとともに、意図しない鍵で医療情報が暗号化あるいは再暗号化されるおそれがない。
また、本実施形態に係る医療情報共有システム１００においては、アクセス権限を付与する利用者端末１０が追加または変更される場合において、暗号化された医療情報を、新たに閲覧権限を取得した利用者端末１０が復号可能なデータに再暗号化するための新規の再暗号化鍵を生成し、当該新規の再暗号化鍵によって再暗号化して新たに閲覧権限を取得した利用者端末１０に提供することを特徴とする。
したがって、閲覧権限を付与する利用者端末１０において再暗号化・再送する必要がなく、また、再暗号化の際に復号して元のデータを公開先以外に参照されるリスクがないため、安全に公開先を変更することができる。また、暗号化鍵及び再暗号化鍵は常に利用者端末１０で生成・合成され、ブロックチェーンに保存されるため、意図しない鍵で更新されず、効率的かつ安全性が高い。
［他の実施形態］
以上、本発明に係る実施形態に基づいて具体的に説明したが、医療情報共有システム１００を構成する各装置の細部構成及び各装置の細部動作に関しても、本発明の趣旨を逸脱することのない範囲で適宜変更可能である。
また、上記の説明では、本発明に係るプログラムのコンピューター読み取り可能な媒体としてＨＤＤや半導体の不揮発性メモリー等を使用した例を開示したが、この例に限定されない。その他のコンピューター読み取り可能な媒体として、ＣＤ−ＲＯＭ等の可搬型記録媒体を適用することが可能である。また、本発明に係るプログラムのデータを、通信回線を介して提供する媒体として、キャリアウエーブ（搬送波）も適用される。
１００ 医療情報共有システム
１０Ａ 利用者端末（提供端末）
１０１ 公開鍵・秘密鍵生成部（第１の暗号鍵生成部）
１０５ 再暗号化鍵生成部
１０７ 送信データ暗号化部（暗号化処理部）
１１５ 公開鍵・秘密鍵生成部（第２の暗号鍵生成部）
１１８ 受信データ復号部（復号処理部）
１０Ｂ 利用者端末（閲覧端末）
２０ 情報提供サーバー（医療情報提供サーバー）
２０４ ブロックチェーン生成部（保存制御部）
２１８ データ再暗号化部（再暗号化部）
３０ ブロックチェーンノード

Claims (9)

  1. 医療情報を記憶する医療情報提供サーバーと、前記医療情報提供サーバーに医療情報を提供する提供端末と、前記医療情報提供サーバーに記憶された医療情報を閲覧する閲覧端末と、合意形成処理を行う分散型共有台帳を管理するブロックチェーンノードと、を備えた分散型医療情報共有システムにおいて、
    前記提供端末は、
    医療情報を、第１の秘密鍵を用いて暗号化する暗号化処理部を備え、
    前記医療情報提供サーバーは、
    前記第１の秘密鍵に対応する第１の公開鍵及び前記閲覧端末が復号可能なデータに再暗号化するための再暗号化鍵を、前記ブロックチェーンノードによってブロックに保存させる保存制御部と、
    暗号化された医療情報を、ブロックに保存された前記再暗号化鍵によって再暗号化して、前記閲覧端末に提供する再暗号化部と、を備える
    ことを特徴とする分散型医療情報共有システム。
  2. 前記提供端末は、
    前記第１の公開鍵及び前記第１の秘密鍵を生成する第１の暗号鍵生成部を備える
    ことを特徴とする請求項１に記載の分散型医療情報共有システム。
  3. 前記提供端末は、
    暗号化された医療情報を、閲覧端末が復号可能なデータに再暗号化するための再暗号化鍵を生成する再暗号化鍵生成部と、を備える
    ことを特徴とする請求項１又は２に記載の分散型医療情報共有システム。
  4. 前記再暗号化鍵生成部は、公開先の閲覧端末が変更される場合において、暗号化された医療情報を、新たに閲覧権限を取得した閲覧端末が復号可能なデータに再暗号化するための新規の再暗号化鍵を生成し、
    前記再暗号化部は、暗号化された医療情報を、前記新規の再暗号化鍵によって再暗号化して、前記新たに閲覧権限を取得した閲覧端末に提供する
    ことを特徴とする請求項３に記載の分散型医療情報共有システム。
  5. 前記医療情報提供サーバーは、
    前記提供端末により暗号化された医療情報を記憶する記憶部を備える
    ことを特徴とする請求項１から４のいずれか一項に記載の分散型医療情報共有システム。
  6. 前記閲覧端末は、
    第２の公開鍵及び第２の秘密鍵を生成する第２の暗号鍵生成部と、
    再暗号化された医療情報を、前記第２の公開鍵を用いて復号する復号処理部と、を備える
    ことを特徴とする請求項１から５のいずれか一項に記載の分散型医療情報共有システム。
  7. 医療情報を記憶する医療情報提供サーバーと、医療情報を、第１の秘密鍵を用いて暗号化する暗号化処理部を備え、前記医療情報提供サーバーに医療情報を提供する提供端末と、前記医療情報提供サーバーに記憶された医療情報を閲覧する閲覧端末と、合意形成処理を行う分散型共有台帳を管理するブロックチェーンノードと、を備えた分散型医療情報共有システムにおける医療情報提供サーバーであって、
    前記医療情報提供サーバーは、
    前記第１の秘密鍵に対応する第１の公開鍵及び前記閲覧端末が復号可能なデータに再暗号化するための再暗号化鍵を、前記ブロックチェーンノードによってブロックに保存させる保存制御部と、
    暗号化された医療情報を、ブロックに保存された前記再暗号化鍵によって再暗号化して、前記閲覧端末に提供する再暗号化部と、を備える
    ことを特徴とする医療情報提供サーバー。
  8. 前記提供端末により暗号化された医療情報を記憶する記憶部を備える
    ことを特徴とする請求項７に記載の医療情報提供サーバー。
  9. 医療情報を記憶する医療情報提供サーバーと、医療情報を、第１の秘密鍵を用いて暗号化する暗号化処理部を備え、前記医療情報提供サーバーに医療情報を提供する提供端末と、前記医療情報提供サーバーに記憶された医療情報を閲覧する閲覧端末と、合意形成処理を行う分散型共有台帳を管理するブロックチェーンノードと、を備えた分散型医療情報共有システムにおいて、
    前記医療情報提供サーバーのコンピューターを、
    前記第１の秘密鍵に対応する第１の公開鍵及び前記閲覧端末が復号可能なデータに再暗号化するための再暗号化鍵を、前記ブロックチェーンノードによってブロックに保存させる保存制御部、
    暗号化された医療情報を、ブロックに保存された前記再暗号化鍵によって再暗号化して、前記閲覧端末に提供する再暗号化部、として機能させる
    ためのプログラム。
JP2018131950A 2018-07-12 2018-07-12 分散型医療情報共有システム、医療情報提供サーバー及びプログラム Pending JP2020010267A (ja)

Priority Applications (1)

Application Number Priority Date Filing Date Title
JP2018131950A JP2020010267A (ja) 2018-07-12 2018-07-12 分散型医療情報共有システム、医療情報提供サーバー及びプログラム

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2018131950A JP2020010267A (ja) 2018-07-12 2018-07-12 分散型医療情報共有システム、医療情報提供サーバー及びプログラム

Publications (1)

Publication Number Publication Date
JP2020010267A true JP2020010267A (ja) 2020-01-16

Family

ID=69152359

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2018131950A Pending JP2020010267A (ja) 2018-07-12 2018-07-12 分散型医療情報共有システム、医療情報提供サーバー及びプログラム

Country Status (1)

Country Link
JP (1) JP2020010267A (ja)

Cited By (15)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN111261250A (zh) * 2020-01-19 2020-06-09 江苏恒宝智能系统技术有限公司 一种基于区块链技术的医疗数据共享方法、装置、电子设备及存储介质
CN111415718A (zh) * 2020-02-29 2020-07-14 重庆邮电大学 一种基于区块链和条件代理重加密的电子处方共享方法
CN111641641A (zh) * 2020-05-29 2020-09-08 兰州理工大学 基于可搜索代理重加密的区块链数据共享方法
CN112039892A (zh) * 2020-08-31 2020-12-04 中国信息通信研究院 一种数据共享方法以及相关装置
CN112261015A (zh) * 2020-10-12 2021-01-22 北京沃东天骏信息技术有限公司 基于区块链的信息共享方法、平台、系统以及电子设备
CN113239255A (zh) * 2021-05-13 2021-08-10 杭州趣链科技有限公司 异构数据资源的共享方法、装置、计算机设备及介质
WO2021172589A1 (ja) * 2020-02-28 2021-09-02 株式会社シーズ 情報処理システム、及びプログラム
JP2021131865A (ja) * 2020-02-19 2021-09-09 バイドゥ オンライン ネットワーク テクノロジー （ベイジン） カンパニー リミテッド ブロックチェーンによるデータ処理方法、装置、デバイス、媒体、及びプログラム
JP2021136694A (ja) * 2020-02-26 2021-09-13 バイドゥ オンライン ネットワーク テクノロジー （ベイジン） カンパニー リミテッド ブロックチェーンネットワークに基づくデータ共有方法、装置、機器及び媒体
JP7011019B1 (ja) 2020-10-30 2022-02-14 サークレイス株式会社 ユーザ情報管理システム、ユーザ情報管理方法及びコンピュータプログラム
CN114070617A (zh) * 2021-11-16 2022-02-18 上海柯林布瑞信息技术有限公司 基于区块链的医疗数据共享方法和装置
WO2022102418A1 (ja) * 2020-11-10 2022-05-19 ソニーグループ株式会社 情報処理装置、情報処理方法及び情報処理プログラム
KR20220124674A (ko) * 2020-04-29 2022-09-14 주식회사 디케이아이테크놀로지 블록체인과 피케이아이기술을 이용한 개인의료기록 공유방법
CN115150397A (zh) * 2022-07-07 2022-10-04 中国电信股份有限公司 资源共享方法及装置、存储介质及电子设备
JP7357174B1 (ja) * 2022-09-28 2023-10-05 株式会社Ｉｄホールディングス 閲覧手続管理システム、閲覧手続管理方法

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2013101280A (ja) * 2011-11-09 2013-05-23 Alps Electric Co Ltd 光学装置及び光受信モジュール
JP2016012897A (ja) * 2014-06-30 2016-01-21 Kddi株式会社 暗号化データ管理システム、プロキシサーバ、ユーザ端末、暗号化データ管理方法およびコンピュータプログラム
JP6340107B1 (ja) * 2017-04-10 2018-06-06 アイビーシー株式会社 電子証明システム
JP2018107625A (ja) * 2016-12-26 2018-07-05 日本電信電話株式会社 データ配信システム、データ生成装置、仲介装置、データ配信方法、及びプログラム

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2013101280A (ja) * 2011-11-09 2013-05-23 Alps Electric Co Ltd 光学装置及び光受信モジュール
JP2016012897A (ja) * 2014-06-30 2016-01-21 Kddi株式会社 暗号化データ管理システム、プロキシサーバ、ユーザ端末、暗号化データ管理方法およびコンピュータプログラム
JP2018107625A (ja) * 2016-12-26 2018-07-05 日本電信電話株式会社 データ配信システム、データ生成装置、仲介装置、データ配信方法、及びプログラム
JP6340107B1 (ja) * 2017-04-10 2018-06-06 アイビーシー株式会社 電子証明システム

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
王立華 他: "ＰＲＩＮＣＥＳＳ：プロキシ暗号化技術を活用したセキュアなストレージシステム", ２０１４年 暗号と情報セキュリティシンポジウム, JPN6022005155, 21 January 2014 (2014-01-21), pages 1 - 6, ISSN: 0004866634 *

Cited By (25)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN111261250A (zh) * 2020-01-19 2020-06-09 江苏恒宝智能系统技术有限公司 一种基于区块链技术的医疗数据共享方法、装置、电子设备及存储介质
US11630821B2 (en) 2020-02-19 2023-04-18 Baidu Online Network Technology (Beijing) Co., Ltd. Blockchain-based data processing method and apparatus, device, and medium
JP2021131865A (ja) * 2020-02-19 2021-09-09 バイドゥ オンライン ネットワーク テクノロジー （ベイジン） カンパニー リミテッド ブロックチェーンによるデータ処理方法、装置、デバイス、媒体、及びプログラム
JP7066890B2 (ja) 2020-02-19 2022-05-13 バイドゥ オンライン ネットワーク テクノロジー（ペキン） カンパニー リミテッド ブロックチェーンによるデータ処理方法、装置、デバイス、媒体、及びプログラム
JP7096920B2 (ja) 2020-02-26 2022-07-06 バイドゥ オンライン ネットワーク テクノロジー（ペキン） カンパニー リミテッド ブロックチェーンネットワークに基づくデータ共有方法、装置、機器及び媒体
JP2021136694A (ja) * 2020-02-26 2021-09-13 バイドゥ オンライン ネットワーク テクノロジー （ベイジン） カンパニー リミテッド ブロックチェーンネットワークに基づくデータ共有方法、装置、機器及び媒体
WO2021172589A1 (ja) * 2020-02-28 2021-09-02 株式会社シーズ 情報処理システム、及びプログラム
CN111415718A (zh) * 2020-02-29 2020-07-14 重庆邮电大学 一种基于区块链和条件代理重加密的电子处方共享方法
CN111415718B (zh) * 2020-02-29 2024-02-09 沈培君 一种基于区块链和条件代理重加密的电子处方共享方法
KR20220124674A (ko) * 2020-04-29 2022-09-14 주식회사 디케이아이테크놀로지 블록체인과 피케이아이기술을 이용한 개인의료기록 공유방법
KR102605710B1 (ko) 2020-04-29 2023-11-24 주식회사 디케이아이테크놀로지 블록체인과 피케이아이기술을 이용한 개인의료기록 공유방법
CN111641641A (zh) * 2020-05-29 2020-09-08 兰州理工大学 基于可搜索代理重加密的区块链数据共享方法
CN111641641B (zh) * 2020-05-29 2021-07-30 兰州理工大学 基于可搜索代理重加密的区块链数据共享方法
CN112039892B (zh) * 2020-08-31 2022-11-29 中国信息通信研究院 一种数据共享方法以及相关装置
CN112039892A (zh) * 2020-08-31 2020-12-04 中国信息通信研究院 一种数据共享方法以及相关装置
CN112261015B (zh) * 2020-10-12 2023-05-12 北京沃东天骏信息技术有限公司 基于区块链的信息共享方法、平台、系统以及电子设备
CN112261015A (zh) * 2020-10-12 2021-01-22 北京沃东天骏信息技术有限公司 基于区块链的信息共享方法、平台、系统以及电子设备
JP7011019B1 (ja) 2020-10-30 2022-02-14 サークレイス株式会社 ユーザ情報管理システム、ユーザ情報管理方法及びコンピュータプログラム
JP2022073280A (ja) * 2020-10-30 2022-05-17 サークレイス株式会社 ユーザ情報管理システム、ユーザ情報管理方法及びコンピュータプログラム
WO2022091619A1 (ja) * 2020-10-30 2022-05-05 サークレイス株式会社 ユーザ情報管理システム、ユーザ情報管理方法及びコンピュータプログラム
WO2022102418A1 (ja) * 2020-11-10 2022-05-19 ソニーグループ株式会社 情報処理装置、情報処理方法及び情報処理プログラム
CN113239255A (zh) * 2021-05-13 2021-08-10 杭州趣链科技有限公司 异构数据资源的共享方法、装置、计算机设备及介质
CN114070617A (zh) * 2021-11-16 2022-02-18 上海柯林布瑞信息技术有限公司 基于区块链的医疗数据共享方法和装置
CN115150397A (zh) * 2022-07-07 2022-10-04 中国电信股份有限公司 资源共享方法及装置、存储介质及电子设备
JP7357174B1 (ja) * 2022-09-28 2023-10-05 株式会社Ｉｄホールディングス 閲覧手続管理システム、閲覧手続管理方法

Similar Documents

Publication Publication Date Title
JP2020010267A (ja) 分散型医療情報共有システム、医療情報提供サーバー及びプログラム
JP6547079B1 (ja) 登録・認可方法、装置及びシステム
US9922207B2 (en) Storing user data in a service provider cloud without exposing user-specific secrets to the service provider
JP6082589B2 (ja) 暗号鍵管理プログラム、データ管理システム
JP6826290B2 (ja) 証明書配付システム、証明書配付方法、および証明書配付プログラム
CN104641592B (zh) 用于无证书认证加密(clae)的方法和系统
US10708047B2 (en) Computer-readable recording medium storing update program and update method, and computer-readable recording medium storing management program and management method
US11741241B2 (en) Private data processing
KR101982237B1 (ko) 클라우드 컴퓨팅 환경에서의 속성 기반 암호화를 이용한 데이터 공유 방법 및 시스템
RU2512139C2 (ru) Способ и устройство для генерации и аутентификации псевдонима
JP2010061103A (ja) 高速検索可能な暗号化のための方法、装置およびシステム
KR20090121628A (ko) Ｓｒｍ 장치간의 안전 정보 교환 시스템 및 방법
US20140156988A1 (en) Medical emergency-response data management mechanism on wide-area distributed medical information network
US20200035339A1 (en) Blockchain security system for secure record access across multiple computer systems
CN112118245A (zh) 密钥管理方法、系统和设备
JP6976405B2 (ja) アクセス管理システム、及びそのプログラム
JP2009212689A (ja) 共通鍵自動配布システム、クライアント、第三者認証機関側サーバ、及び共通鍵自動共有方法
JP5494171B2 (ja) ファイル管理システム、ストレージサーバ、クライアント、ファイル管理方法およびプログラム
JP5586397B2 (ja) セキュア・ネットワーク・ストレージ・システム、方法、クライアント装置、サーバ装置、及びプログラム
JP2003244123A (ja) 共通鍵管理システム、共通鍵管理サーバ、共通鍵管理方法、及び共通鍵管理プログラム
JPH11331145A (ja) 情報共有システム、情報保管装置およびそれらの情報処理方法、並びに記録媒体
KR20160128170A (ko) 비밀키 암호화 및 복원을 제공하는 단말, 서버 및 방법
WO2009153974A1 (ja) データ管理システム、データ管理方法、およびコンピュータプログラム
CN113766512A (zh) 一种医疗大数据信息安全处理方法及系统
JP2011130021A (ja) 証跡管理方法

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20210419

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20220126

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20220208

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20220406

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20220906

A601 Written request for extension of time

Free format text: JAPANESE INTERMEDIATE CODE: A601

Effective date: 20221104

A02 Decision of refusal

Free format text: JAPANESE INTERMEDIATE CODE: A02

Effective date: 20230307