WO2022145312A1

WO2022145312A1 - 情報処理方法、情報処理装置及びプログラム

Info

Publication number: WO2022145312A1
Application number: PCT/JP2021/047597
Authority: WO
Inventors: 琢磨前田
Original assignee: ハッシュピーク株式会社
Priority date: 2020-12-28
Filing date: 2021-12-22
Publication date: 2022-07-07
Also published as: JPWO2022145312A1; US20240079104A1

Abstract

一つの側面に係る情報処理方法は、患者を特定する患者ＩＤ、患者の属性、及び医療に関する質問に対する前記患者による回答を取得し、医師を特定する医師ＩＤを取得し、取得した前記医師ＩＤに対応する医師端末装置（３）へ前記患者の患者ＩＤ、属性及び回答を送信し、前記患者の患者ＩＤ、属性及び回答が表示された前記医師端末装置（３）を通じて、前記患者に対する診療データの入力を受け付け、前記患者の属性、回答及び入力された診療データを含む医療データの送信要求を受け付け、前記医療データのハッシュ値をブロックチェーンシステム（２）に出力し、前記医療データの開示要求を介して受け付け、前記研究者の開示要求に対する前記患者の承認を得た場合に、前記医療データを前記研究者端末装置（５）に出力することを特徴とする。　

Description

情報処理方法、情報処理装置及びプログラム

　本発明は、情報処理方法、情報処理装置及びプログラムに関する。

　特許文献１には、患者情報、担当医療者情報、疾患・疾病における有害事象に関する質問と複数の回答とが組み合わされている複数の疾病診断用問合せ情報を用いて、異常を検出した場合に担当医療者へアラートを通知する疾病診断・治療・予防システムが開示されている。

特開２０２０－０６４４３５号公報

　しかしながら、特許文献１に係る発明は、医療研究者が患者の医療データを用いて医療を研究することができないという問題がある。

　一つの側面では、患者の医療データを適切に医療研究者に提供することが可能な情報処理方法等を提供することを目的とする。

　一つの側面に係る情報処理方法は、患者を特定する患者ＩＤ、患者の属性、及び医療に関する質問に対する前記患者による回答を取得し、医師を特定する医師ＩＤを前記患者の患者端末装置により読み取らせることにより前記医師ＩＤを取得し、取得した前記医師ＩＤに対応する医師端末装置へ前記患者の患者ＩＤ、属性及び回答を送信し、前記患者の患者ＩＤ、属性及び回答が表示された前記医師端末装置を通じて、前記医師による前記患者に対する診療データの入力を受け付け、前記患者の属性、回答及び入力された診療データを含む医療データの送信要求を受け付け、前記医療データのハッシュ値をブロックチェーンシステムに出力し、前記ブロックチェーンシステムに記録された前記医療データの開示要求を研究者の研究者端末装置を介して受け付け、前記研究者の開示要求に対する前記患者の承認を得た場合に、前記医療データを前記研究者端末装置に出力することを特徴とする。

　一つの側面では、患者の医療データを適切に医療研究者に提供することが可能となる。

医療データ管理システムの概要を示す説明図である。サーバの構成例を示すブロック図である。患者ＤＢ及び医師ＤＢのレコードレイアウトの一例を示す説明図である。質問ＤＢ及び医療データＤＢのレコードレイアウトの一例を示す説明図である。研究者ＤＢ及び取引履歴ＤＢのレコードレイアウトの一例を示す説明図である。管理ＤＢのレコードレイアウトの一例を示す説明図である。ブロックチェーンのノードの構成例を示すブロック図である。医師端末及び患者端末の構成例を示すブロック図である。研究者端末の構成例を示すブロック図である。電子署名付き医療データを作成する動作を説明する説明図である。医療データをブロックチェーンに記録する処理を説明する説明図である。医療データを研究者端末に出力する動作を説明する説明図である。質問に対する回答の入力画面の一例を示す説明図である。医療データの作成画面の一例を示す説明図である。患者端末側での医療データの表示画面の一例を示す説明図である。患者端末側での医療データの表示画面の一例を示す説明図である。患者端末側での医療データの表示画面の一例を示す説明図である。患者端末側での開示要求の応答画面の一例を示す説明図である。患者端末側での医療データの取引履歴画面の一例を示す説明図である。患者端末側での医療データの詳細画面の一例を示す説明図である。研究者端末側での医療データ管理画面の一例を示す説明図である。研究者端末側での取引履歴画面の一例を示す説明図である。医療データを作成する際の処理手順を示すフローチャートである。医療データを作成する際の処理手順を示すフローチャートである。患者の承認を得た医療データを研究者端末に出力する際の処理手順を示すフローチャートである。患者の承認を得た医療データを研究者端末に出力する際の処理手順を示すフローチャートである。医療データを共有する際の処理手順を示すフローチャートである。研究結果に関する情報を患者端末に出力する際の処理手順を示すフローチャートである。研究者端末側での複数回の医療データの表示画面の一例を示す説明図である。実施形態５における管理ＤＢのレコードレイアウトの一例を示す説明図である。承諾情報の受付画面の一例を示す説明図である。患者の再承認を得た医療データを研究者端末に出力する際の処理手順を示すフローチャートである。

　以下、本発明をその実施の形態を示す図面に基づいて詳述する。

　（実施形態１）
　実施形態１は、患者の医療データを研究者（医療研究者）に提供する形態に関する。図１は、医療データ管理システムの概要を示す説明図である。本実施形態のシステムは、情報処理装置１、ブロックチェーンシステム２、情報処理端末３、情報処理端末４及び情報処理端末５を含み、各装置はインターネット等のネットワークＮを介して情報の送受信を行う。

　情報処理装置１は、種々の情報に対する処理、記憶及び送受信を行う情報処理装置である。情報処理装置１は、例えばサーバ装置、パーソナルコンピュータまたは汎用のタブレットＰＣ（パソコン）等である。本実施形態において情報処理装置１はサーバ装置であるものとし、以下では簡潔のためサーバ１と読み替える。

　ブロックチェーンシステム２とは、分散型台帳技術又は分散型ネットワークである。ブロックチェーンシステム２は、コンセンサス処理を実行する複数のノード２１により構成される。ノード２１の各々は、当該コンセンサス処理の実行を通じて、ブロックチェーンデータのコピーを保持する。ブロックチェーンシステム２は、ブロックと呼ばれるデータの単位を一定時間ごとに生成し、鎖のように連結していくことによりデータを保管する。

　ブロックチェーンシステム２は、ピアツーピア（Peer to Peer）ネットワークと分散型タイムスタンプサーバの使用により自律的に管理される。鎖状に保存しているため、ブロック内のデータを一度記憶した場合、該データを遡及的に変更することが難しい。なお、ブロックチェーンシステム２は、パブリック型、プライベート型、コンソーシアム型のいずれであっても良い。データの単位はブロックではなく個々のトランザクションであっても良い。また、データの保存は鎖状以外にも有向非巡回グラフ等の保存形式であっても良い。以下では簡潔のため、ブロックチェーンシステム２をブロックチェーン２と読み替える。

　情報処理端末３は、患者の属性、医療に関する質問に対する患者による回答、及び医師による患者に対する診療データを含む医療データの作成、ならびに、医療データの電子署名等を行う端末装置である。情報処理端末３は、例えばスマートフォン、携帯電話、タブレット、パーソナルコンピュータ端末等の情報処理機器である。以下では簡潔のため、情報処理端末３を医師端末３と読み替える。

　情報処理端末４は、患者の属性及び質問に対する回答の取得、電子署名付き医療データの取得、並びに、医療データの開示要求に対する承認情報の入力受付等を行う端末装置である。情報処理端末４は、例えばスマートフォン、携帯電話、アップルウォッチ（Apple Watch:登録商標）等のウェアラブルデバイス、タブレット、パーソナルコンピュータ端末等の情報処理機器である。以下では簡潔のため、情報処理端末４を患者端末４と読み替える。

　情報処理端末５は、医療データの開示要求の受付及び送信、ならびに、開示要求に対して承認を得た医療データの受信等を行う端末装置である。情報処理端末５は、例えばスマートフォン、携帯電話、タブレット、パーソナルコンピュータ端末等の情報処理機器である。以下では簡潔のため、情報処理端末５を研究者端末５と読み替える。

　本実施形態に係るサーバ１は、患者を特定する患者ＩＤ、患者の属性、及び医療に関する質問に対する前記患者による回答を取得する。サーバ１は、医師を特定する医師ＩＤを患者端末４により読み取らせることにより医師ＩＤを取得する。サーバ１は、取得した医師ＩＤに対応する医師端末３へ患者の患者ＩＤ、属性及び回答を送信する。サーバ１は医師端末３を通じて、該医師による患者に対する診療データの入力を受け付ける。

　サーバ１は、患者の属性、回答及び入力された診療データを含む医療データの送信要求を医師端末３から受け付けた場合、医療データのハッシュ値を算出する。サーバ１は、算出した医療データのハッシュ値をブロックチェーン２に出力する。サーバ１は研究者端末５を介して、ブロックチェーン２に記録された医療データの開示要求を受け付けた場合、受け付けた開示要求を、該医療データを提供した患者の患者端末４に送信する。サーバ１は、開示要求に対する患者の承認を得た場合、該医療データを研究者端末５に送信する。

　図２は、サーバ１の構成例を示すブロック図である。サーバ１は、制御部１１、記憶部１２、通信部１３、入力部１４、表示部１５、読取部１６及び大容量記憶部１７を含む。各構成はバスＢで接続されている。

　制御部１１はＣＰＵ（Central Processing Unit）、ＭＰＵ（Micro-Processing Unit）、ＧＰＵ（Graphics Processing Unit）等の演算処理装置を含み、記憶部１２に記憶された制御プログラム１Ｐ（プログラム製品）を読み出して実行することにより、サーバ１に係る種々の情報処理、制御処理等を行う。また制御プログラム１Ｐには、例えばイーサリアムのGeth（Go-Ethereum）等のスマートコントラクトの生成・実行、仮想通貨の送金、アカウントの作成、マイニング等の処理を実行するプログラムが含まれる。

　また、制御部１１は、ハッシュ値算出部１１ａ及び電子署名作成部１１ｂを含む。ハッシュ値算出部１１ａは、暗号学的ハッシュ関数を用いて各種情報のハッシュ値を算出する処理を行う。電子署名作成部１１ｂは、偽造又は改ざんを防止するため、公開鍵暗号方式に基づくデジタル認証用の署名を生成する。なお、図２では制御部１１を単一のプロセッサであるものとして説明するが、マルチプロセッサであっても良い。

　記憶部１２はＲＡＭ（Random Access Memory）、ＲＯＭ（Read Only Memory）等のメモリ素子を含み、制御部１１が処理を実行するために必要な制御プログラム１Ｐ又はデータ等を記憶している。また、記憶部１２は、制御部１１が演算処理を実行するために必要なデータ等を一時的に記憶する。通信部１３は通信に関する処理を行うための通信モジュールであり、ネットワークＮを介して、ブロックチェーン２のノード２１、医師端末３、患者端末４または研究者端末５等との間で情報の送受信を行う。

　入力部１４は、マウス、キーボード、タッチパネルまたはボタン等の入力デバイスであり、受け付けた操作情報を制御部１１へ出力する。表示部１５は、液晶ディスプレイ又は有機ＥＬ（electroluminescence）ディスプレイ等であり、制御部１１の指示に従い各種情報を表示する。

　読取部１６は、ＣＤ（Compact Disc）－ＲＯＭ又はＤＶＤ（Digital Versatile Disc）－ＲＯＭを含む可搬型記憶媒体１ａを読み取る。制御部１１が読取部１６を介して、制御プログラム１Ｐを可搬型記憶媒体１ａより読み取り、大容量記憶部１７に記憶しても良い。また、ネットワークＮ等を介して他のコンピュータから制御部１１が制御プログラム１Ｐをダウンロードし、大容量記憶部１７に記憶しても良い。さらにまた、半導体メモリ１ｂから、制御部１１が制御プログラム１Ｐを読み込んでも良い。

　大容量記憶部１７は、例えばＨＤＤ（Hard disk drive:ハードディスク）、ＳＳＤ(Solid State Drive:ソリッドステートドライブ)等の記録媒体を備える。大容量記憶部１７は、患者ＤＢ（データベース：database）１７１、医師ＤＢ１７２、質問ＤＢ１７３、医療データＤＢ１７４、研究者ＤＢ１７５、取引履歴ＤＢ１７６及び管理ＤＢ１７７を含む。

　患者ＤＢ１７１は、患者の属性を記憶している。医師ＤＢ１７２は、医師の属性を記憶している。質問ＤＢ１７３は、医療に関する質問に対する患者による回答を記憶している。医療データＤＢ１７４は、患者の医療データを記憶している。研究者ＤＢ１７５は、研究者の属性を記憶している。取引履歴ＤＢ１７６は、医療データの取引履歴を記憶している。管理ＤＢ１７７は、医療データの管理情報を記憶している。

　なお、本実施形態において記憶部１２及び大容量記憶部１７は一体の記憶装置として構成されていても良い。また、大容量記憶部１７は複数の記憶装置により構成されていても良い。更にまた、大容量記憶部１７はサーバ１に接続された外部記憶装置であっても良い。

　なお、本実施形態では、サーバ１は一台の情報処理装置であるものとして説明するが、複数台により分散して処理させても良く、または仮想マシンにより構成されていても良い。

　図３は、患者ＤＢ１７１及び医師ＤＢ１７２のレコードレイアウトの一例を示す説明図である。　患者ＤＢ１７１は、患者ＤＩＤ（Decentralized Identifier）列、氏名列、生年月日列、郵便番号列、住所列、電話番号列、メールアドレス列及び登録日時列を含む。患者ＤＩＤ列は、各患者を識別するために、一意に特定される患者のＤＩＤを記憶している。ＤＩＤは、ユーザが自分の属性情報に関するコントロール権を確保した上で、各データ保有者が保有するユーザの属性情報のうち必要な情報を、ユーザの許可した範囲で連携し合う分散型アイデンティティ（非中央集権型ＩＤ）である。ＤＩＤは、ブロックチェーン２により構築された分散型システムを用いて、重複しない一意な識別子を実現することにより、不変性、または外部からの閲覧・改ざんに対する高い信頼性を維持することができる。なお、本実施形態では、患者ＩＤが患者ＤＩＤである例を説明したが、これに限るものではない。患者ＩＤは、患者を特定するための従来（既存）のＩＤ、顔または指紋による生体認証情報等であっても良い。

　氏名列は、患者の氏名を記憶している。生年月日列は、患者の生年月日を記憶している。郵便番号列は、患者の現住所に基づく郵便番号を記憶している。住所列は、患者の現住所を記憶している。電話番号列は、患者の電話番号を記憶している。メールアドレス列は、患者の電子メールアドレスを記憶している。登録日時列は、患者の属性を登録した日時情報を記憶している。

　医師ＤＢ１７２は、医師ＤＩＤ列、氏名列、医療機関名称列及び診療科名称列を含む。医師ＤＩＤ列は、各医師を識別するために、一意に特定される医師のＤＩＤを記憶している。なお、本実施形態では、医師ＩＤが医師ＤＩＤである例を説明したが、これに限るものではない。医師ＩＤは、医師を特定するための従来のＩＤ、顔または指紋による生体認証情報等であっても良い。氏名列は、医師の氏名を記憶している。医療機関名称列は、医師が勤務している医療機関の名称を記憶している。診療科名称列は、精神科、皮膚科または外科等の診療科の名称を記憶している。

　図４は、質問ＤＢ１７３及び医療データＤＢ１７４のレコードレイアウトの一例を示す説明図である。

　質問ＤＢ１７３は、患者ＤＩＤ列、質問種類列及び質問データ列を含む。患者ＤＩＤ列は、患者を特定する患者ＤＩＤを記憶している。質問種類列は、医療に関する質問の種類を記憶している。質問の種類は、例えばＰＤＱ（Parkinson's Disease Questionnaire）－３９、ＭＤＳ－ＵＰＤＲＳ（Movement Disorder Society-sponsored revision of the Unified Parkinson's Disease Rating Scale）またはＥＱ－５Ｄ（EuroQOL 5 Dimensions）等を含む。なお、上述した質問の種類は一例であり、これに限るものではない。質問データ列は、医療に関する質問、及び各質問に対する患者による回答を記憶している。

　医療データＤＢ１７４は、医療データＩＤ列、患者ＤＩＤ列、医療データ列、ハッシュ値列、医師ＤＩＤ列、署名日時列、ＢＣへ記録日時列及び状態列を含む。医療データＩＤ列は、各医療データを識別するために、一意に特定される医療データのＩＤを記憶している。患者ＤＩＤ列は、患者を特定する患者ＤＩＤを記憶している。

　医療データ列は、医療データＩＤに対応付けて患者の医療データを記憶している。医療データ列には、患者の属性、医療に関する質問に対する患者による回答、及び医師による患者に対する診療データを含む医療データが記憶されている。医療データは、例えばＪＳＯＮ（JavaScript(登録商標) Object Notation）形式のファイル、またはＸＭＬ（Extensible Markup Language）形式のファイル等である。ハッシュ値列は、医療データのハッシュ値を記憶している。

　医師ＤＩＤ列は、医師を特定する医師ＤＩＤを記憶している。署名日時列は、医療データを電子署名した日時情報を記憶している。ＢＣへ記録日時列は、ブロックチェーン２に医療データを記録した日時を記憶している。状態列は、医療データの状態を記憶している。医療データの状態は、例えば「下書き保存」、「サブミット済み」、「署名済み」または「ＢＣへ記録済み」等を含む。「下書き保存」状態は、患者の属性及び質問に対する患者による回答を下書き保存した状態である。「サブミット済み」状態は、患者の属性及び質問に対する患者による回答をサーバ１にサブミット（送信）済みであることを示す状態である。「署名済み」状態は、患者の属性、質問に対する回答及び医師による患者に対する診療データを含む医療データに署名済みであることを示す状態である。「ＢＣへ記録済み」状態は、医療データをブロックチェーン２に記録済みであることを示す状態である。

　図５は、研究者ＤＢ１７５及び取引履歴ＤＢ１７６のレコードレイアウトの一例を示す説明図である。研究者ＤＢ１７５は、研究者ＤＩＤ列、研究機関ＩＤ列、氏名列、生年月日列、郵便番号列、住所列、電話番号列、メールアドレス列及び登録日時列を含む。研究者ＤＩＤ列は、各研究者を識別するために、一意に特定される研究者のＤＩＤを記憶している。なお、本実施形態では、研究者ＩＤが研究者ＤＩＤである例を説明したが、これに限るものではない。研究者ＩＤは、研究者を特定するための従来のＩＤ、顔または指紋による生体認証情報等であっても良い。

　研究機関ＩＤ列は、研究者が所属する研究機関を特定するための研究機関ＩＤを記憶している。研究機関は、研究、試験または鑑定等を行うための組織（機関）、またはその施設である。氏名列は、研究者の氏名を記憶している。生年月日列は、研究者の生年月日を記憶している。郵便番号列は、研究者の現住所に基づく郵便番号を記憶している。住所列は、研究者の現住所を記憶している。電話番号列は、研究者の電話番号を記憶している。メールアドレス列は、研究者の電子メールアドレスを記憶している。登録日時列は、研究者の属性を登録した日時情報を記憶している。

　取引履歴ＤＢ１７６は、研究機関ＩＤ列、医療データＩＤ列、患者ＤＩＤ列、研究者ＤＩＤ列及び取引日時列を含む。研究機関ＩＤ列は、研究機関を特定する研究機関ＩＤを記憶している。医療データＩＤ列は、医療データを特定する医療データＩＤを記憶している。患者ＤＩＤ列は、患者を特定する患者ＤＩＤを記憶している。研究者ＤＩＤ列は、研究者を特定する研究者ＤＩＤを記憶している。取引日時列は、患者と研究者との間に医療データの取引日時を記憶している。

　図６は、管理ＤＢ１７７のレコードレイアウトの一例を示す説明図である。管理ＤＢ１７７は、管理ＩＤ列、医療データＩＤ列、患者ＤＩＤ列、研究者ＤＩＤ列、要求状況列、要求日時列、患者承認日時列、承認種別列、患者否認日時列及び患者撤回日時列を含む。管理ＩＤ列は、各管理データを識別するために、一意に特定される管理データのＩＤを記憶している。医療データＩＤ列は、医療データを特定する医療データＩＤを記憶している。患者ＤＩＤ列は、患者を特定する患者ＤＩＤを記憶している。研究者ＤＩＤ列は、研究者を特定する研究者ＤＩＤを記憶している。

　要求状況列は、医療データの開示要求に対する患者の応答状況を記憶している。要求状況列には、「データ未請求」、「承認待ち」、「承認済み」、「撤回済み」または「保留中」等が記憶される。要求日時列は、医療データの開示要求を受け付けた日時情報を記憶している。患者承認日時列は、患者が医療データの利用を承認した日時情報を記憶している。

　承認種別列は、医療データに対する承認種別を記憶している。承認種別は、医療データの開示要求に対する第１承認、及び、第１承認と、医療データの開示要求に対して第１承認を得た医療データを、他の研究者に共有することを求める共有要求に対する患者の第２承認とを含む承認を有する。以下では簡潔のため、第１承認を「開示のみ」と読み替え、第１承認と第２承認とを含む承認を「開示＆共有」と読み替える。患者否認日時列は、患者が医療データの利用を否認した日時情報を記憶している。患者撤回日時列は、承認済みの医療データに対し、患者が承認を撤回した日時情報を記憶している。

　なお、上述した各ＤＢの記憶形態は一例であり、データ間の関係が維持されていれば、他の記憶形態であっても良い。

　図７は、ブロックチェーン２のノード２１の構成例を示すブロック図である。ブロックチェーン２のノード２１は、制御部２１１、記憶部２１２、通信部２１３、受付部２１４、出力部２１５、ブロック生成部２１６、ブロック検証部２１７及びブロック共有部２１８を含む。各構成はバスＢで接続されている。

　制御部２１１は、他ノード２１（端末）の制御部と自律分散的に協調して、常に最新のブロックチェーン（台帳：ブロックチェーンデータのコピー）を記憶部２１２に保持する。記憶部２１２には、分散型のネットワークへブロードキャストされたトランザクションが含まれたブロックチェーン（台帳）、及びブロック内の情報の検証処理に必要となる情報等が記憶される。

　通信部２１３は、通信に関する処理を行うための通信モジュールである。受付部２１４は、外部ノードから、ブロックチェーン２が管理するブロックチェーンである分散型のネットワークに記録する情報を受け付ける。出力部２１５は、外部ノードからの要求に応じて、自身が保持するブロックチェーンの情報を出力する。

　ブロック生成部２１６は、受付部２１４が受け付けた情報を基に、ブロックチェーンに追加するブロックを生成する。ブロック生成部２１６は、前ブロックに基づく情報と受付部２１４が受け付けた情報とを含むブロックを生成する。また、ブロック生成部２１６は、自身が生成したブロックまたは後述するブロック共有部２１８を介して他のブロックチェーンのノード２１が生成したブロックに対して、所定のコンセンサス処理として、例えば、ノンスを探索する処理や署名を付与する処理を行った上で、自身が管理するブロックチェーン（台帳）にブロックを追加する。なお、ブロック生成部２１６が生成したブロックに対して、複数のノード２１が所定のコンセンサス処理を行って得られたものが、最終的にブロックチェーン２に追加されるブロックとなる。

　ブロック検証部２１７は、自身が保持するブロックチェーンにブロックを追加する際に、該ブロック内の情報の検証を行う。通常、追加対象とされるブロックは、自ノードを含むノード２１群において最も早く規則が満たされたブロックであるが、悪意のあるノード２１が含まれていた場合等を考慮して、実際に規則が満たされているか等を検証しても良い。

　ブロック共有部２１８は、ブロックチェーン２に属するノード２１間で情報交換を行う。ブロック共有部２１８は、より具体的には、受付部２１４が受け付けた情報、ブロック生成部２１６が生成したブロック、及び他のノード２１から受け付けたブロック等を、適宜他のノード２１に送信する。これにより、可能な限り全てのノード２１でこれらの情報および最新のブロックチェーン２を共有する。

　なお、図７の構成はあくまで一例であって、ブロックチェーンのノード２１は、改ざんが困難なブロックチェーン２を複数のノードが共有して管理するための所定のコンセンサス処理を実行可能であり、外部ノードからの要求に応じて分散型のネットワークへの情報追加、及び分散型のネットワークに記録された情報の参照が可能なノードであれば、具体的な構成は問わない。

　なお、サーバ１は、ブロックチェーン２のノード２１であっても良い。

　図８は、医師端末３及び患者端末４の構成例を示すブロック図である。　医師端末３は、制御部３１、記憶部３２、通信部３３、入力部３４及び表示部３５を含む。各構成はバスＢで接続されている。

　制御部３１はＣＰＵ、ＭＰＵ等の演算処理装置を含み、記憶部３２に記憶された制御プログラム３Ｐ（プログラム製品）を読み出して実行することにより、医師端末３に係る種々の情報処理、制御処理等を行う。また、制御部３１は、ハッシュ値算出部３１ａ及び電子署名作成部３１ｂを含む。ハッシュ値算出部３１ａは、暗号学的ハッシュ関数を用いて、ウォレットアドレス等を算出する処理を行う。また制御プログラム３Ｐには、例えばイーサリアムのGeth等のスマートコントラクトの生成・実行、仮想通貨の送金、アカウントの作成、マイニング等の処理を実行するプログラムが含まれる。電子署名作成部３１ｂは、偽造又は改ざんを防止するため、公開鍵暗号方式に基づくデジタル認証用の署名を生成する。

　なお、図８では制御部３１を単一のプロセッサであるものとして説明するが、マルチプロセッサであっても良い。記憶部３２はＲＡＭ、ＲＯＭ等のメモリ素子を含み、制御部３１が処理を実行するために必要な制御プログラム３Ｐ又はデータ等を記憶している。また、記憶部３２は、制御部３１が演算処理を実行するために必要なデータ等を一時的に記憶する。通信部３３は通信に関する処理を行うための通信モジュールであり、ネットワークＮを介して、サーバ１等と情報の送受信を行う。入力部３４は、キーボード、マウスまたは表示部３５と一体化したタッチパネルでも良い。表示部３５は、液晶ディスプレイ又は有機ＥＬディスプレイ等であり、制御部３１の指示に従い各種情報を表示する。

　患者端末４は、制御部４１、記憶部４２、通信部４３、入力部４４、表示部４５及び撮影部４６を含む。各構成はバスＢで接続されている。なお、患者端末４の制御部４１、記憶部４２、通信部４３、入力部４４及び表示部４５に関しては、医師端末３の制御部３１、記憶部３２、通信部３３、入力部３４及び表示部３５と同様であるため、説明を省略する。撮影部４６は、例えばＣＣＤ(Charge Coupled Device)カメラ、ＣＭＯＳ（Complementary Metal Oxide Semiconductor）カメラ等の撮影装置である。なお、撮影部４６は患者端末４の中に内蔵せず、外部で直接患者端末４と接続し、撮影可能な構成としても良い。

　図９は、研究者端末５の構成例を示すブロック図である。研究者端末５は、制御部５１、記憶部５２、通信部５３、入力部５４及び表示部５５を含む。各構成はバスＢで接続されている。なお、研究者端末５の制御部５１、記憶部５２、通信部５３、入力部５４及び表示部５５に関しては、医師端末３の制御部３１、記憶部３２、通信部３３、入力部３４及び表示部３５と同様であるため、説明を省略する。

　図１０は、電子署名付き医療データを作成する動作を説明する説明図である。先ず、患者の属性を予め登録する処理を説明する。患者の属性は、患者の氏名、性別、年齢、生年月日、郵便番号、住所、電話番号、メールアドレス、既往歴、投薬歴または血液型等を含む。なお、患者の属性には、生体が発する種々の生理学的・解剖学的情報である生体データ（例えば、血圧、心電、心音またはＸ線の吸収率）が含まれても良い。

　具体的には、患者端末４は、患者の属性の入力を受け付け、受け付けた患者の属性をサーバ１に送信する。サーバ１は、患者端末４から送信された患者の属性を受信して患者ＤＩＤを発行する。例えばサーバ１は、Ｅｔｈｅｒｅｕｍ（登録商標）のＥＲＣ７２５／７３５、またはＳｏｖｒｉｎ　Ｎｅｔｗｏｒｋ等のプラットフォームを利用することにより、患者を特定する患者ＤＩＤを発行する。

　サーバ１は、発行した患者ＤＩＤに対応付け、受信した患者の属性を患者ＤＢ１７１に記憶する。具体的には、サーバ１は患者ＤＩＤに対応付け、患者の氏名、生年月日、郵便番号、住所、電話番号、メールアドレス及び登録日時を一つのレコードとして患者ＤＢ１７１に記憶する。

　次に、医療に関する質問に対する患者による回答を予め登録する処理を説明する。医療に関する質問は、例えばパーキンソン病において、パーキンソン病者を対象とした疾患特異的ＱＯＬ（Quality of Life）質問票であるＰＤＱ－３９が利用されても良い。具体的には、患者端末４は、患者による質問の種類（例えば、ＰＤＱ－３９、ＭＤＳ－ＵＰＤＲＳまたはＥＱ－５Ｄ）の選択を受け付ける。患者端末４は、受け付けた質問の種類に応じて、該当する質問を記憶部または外部装置から取得して画面に表示する。

　患者端末４は、画面に表示されている質問に対する患者による回答を受け付け、受け付けた回答を患者ＤＩＤに対応付けてサーバ１に送信する。サーバ１は、患者端末４から送信された患者ＤＩＤ及び質問に対する回答を受信し、受信した患者ＤＩＤ及び回答を質問ＤＢ１７３に記憶する。具体的には、サーバ１は、受信した患者ＤＩＤに対応付け、質問の種類、質問及び該質問に対する回答を含む質問データを一つのレコードとして質問ＤＢ１７３に記憶する。

　なお、患者の属性及び質問に対する回答のほか、血圧、心拍数、呼吸数または体温など計測を可能にするウェアラブルデバイス、またはバイタルセンサを搭載した端末などにより計測されたバイタルデータ（生体データ）がサーバ１に登録されても良い。例えば、端末２はウェアラブルデバイスを介して、血圧、心拍数、呼吸数または体温などを含むバイタルデータを取得する。端末２は、取得したバイタルデータを、患者の属性及び質問に対する回答と共にサーバ１に登録する。

　続いて、電子署名付き医療データを作成する処理を説明する。医療データは、患者の属性、質問に対する回答及び医師による該患者に対する診療データを含む。

　医師の医師端末３は、コードを生成するライブラリを利用し、医師を識別する医師ＤＩＤを記述したコードを生成する。コードは、一次元コード又は二次元コードを含む。一次元コードは、例えば縞模様状の線の太さによって数値または文字を表すバーコード（Barcode）であっても良い。二次元コードは、例えば横方向にしか情報を持たない一次元コードに対し、水平方向と垂直方向に情報を持つ表示方式のＱＲコード（登録商標）であっても良い。以下では、二次元コードの例を説明する。医師ＤＩＤは、例えばＥｔｈｅｒｅｕｍのＥＲＣ７２５／７３５、またはＳｏｖｒｉｎ　Ｎｅｔｗｏｒｋ等のプラットフォームを利用して発行されても良い。

　医師端末３は、生成した二次元コードを画面に表示する。患者が医師の診断を受けた場合、患者端末４は、医師端末３上で表示されている二次元コードを読み取る。患者端末４は、二次元コードの解析ライブラリを利用し、読み取った二次元コードから医師ＤＩＤを取得する。なお、本実施形態では、二次元コードを用いる例を挙げたが、これに限るものではない。例えば、ＩＣタグ(Integrated Circuit Tag)、ＲＦタグ(Radio Frequency Tag)、またはＲＦＩＤ(Radio Frequency Identifier)チップ（マイクロチップ）等に記憶された医師ＤＩＤをＲＦリーダで読み取る形態であっても良く、または、バーコードに記憶された医師ＤＩＤを読み取る形態であっても良い。更にまた、医師ＤＩＤが手動入力で受け付けられても良い。

　患者端末４は、取得した医師ＤＩＤと患者ＤＩＤとをサーバ１に送信する。サーバ１は、患者端末４から送信された医師ＤＩＤ及び患者ＤＩＤを受信する。サーバ１は、受信した患者ＤＩＤに基づいて患者の属性及び質問に対する回答を取得する。具体的には、サーバ１は、患者ＤＩＤに基づいて患者ＤＢ１７１から患者の属性を取得する。サーバ１は、患者ＤＩＤに基づいて質問ＤＢ１７３から質問に対する回答を取得する。

　サーバ１は、患者ＤＩＤと、取得した患者の属性及び質問に対する回答とを、受信した医師ＤＩＤに対応する医師端末３に送信する。医師端末３は、サーバ１から送信された患者ＤＩＤ、患者の属性及び質問に対する回答を受信する。医師端末３は、医師による患者に対する診療データの入力を受け付ける。例えばパーキンソン病などの疾患の重症度分類、処方情報（薬剤の成分名、剤型または用量等）、血圧または脈拍等が診療データに含まれる。

　医師端末３は、患者の属性、質問に対する回答及び診療データを含む医療データに対する電子署名の指示を受け付けた場合、該医療データに対して電子署名処理（暗号化）を行う。電子署名処理とは、与えられたデータに対し秘密鍵を用いた電子署名を行う機能である。通常は与えられたデータを暗号学的ハッシュ関数で変換したハッシュ値を暗号化する。暗号学的ハッシュ関数は、デジタル文書の改ざんを検出する一方向の暗号処理方法であり、出力値は常に１６進数表記として６４桁と固定されている。ハッシュ関数は何を用いても良く、例えば、ＳＨＡ（Secure Hash Algorithm）－１またはＳＨＡ－２５６を用いることができる。なお、電子署名の対象となるデータのサイズが小さい場合には、ハッシュ値ではなく、データそのものを暗号化したものを電子署名として用いても良い。

　なお、本実施形態では、医師により医療データに対して電子署名を行ったが、これに限るものではない。例えば、臨床検査技師、理学療法士または介護士等の医療関連の有資格者により医療データに対して電子署名を行っても良い。

　医師端末３は、患者ＤＩＤ及び医師ＤＩＤに対応付け、電子署名付き医療データをサーバ１に送信する。サーバ１は、医師端末３から送信された患者ＤＩＤ、医師ＤＩＤ及び電子署名付き医療データを受信する。サーバ１は、公開鍵を用いて電子署名付き医療データを復号する。サーバ１は、医療データを特定する医療データＩＤを作成する。例えばサーバ１は、Ｅｔｈｅｒｅｕｍの一つのスマートコントラクト規格であるＥＲＣ７２１を利用し、「価値」を証明することができる非代替性トークン（ＮＦＴ）を医療データＩＤとして作成しても良い。ＥＲＣ７２１規格を用いれば、ブロックチェーン２上の全ての医療データＩＤを開示しているが、改ざんすることはできないため、所有者または帰属情報等を付けることが可能となる。

　サーバ１は、作成した医療データＩＤに対応付け、患者ＤＩＤ、復号した医療データ、医師ＤＩＤ、電子署名日時及び「署名済み」となった状態を一つのレコードとして医療データＤＢ１７４に記憶する。サーバ１は、医療データを患者端末４に送信する。患者端末４は、サーバ１から送信された医療データを受信して画面に表示する。患者端末４は、患者から該医療データをブロックチェーン２に出力（記録）する指示を受け付けた場合、ブロックチェーン２への出力指示をサーバ１に送信する。出力指示には、患者ＤＩＤ及び医療データＩＤが含まれる。サーバ１は、患者端末４から送信されたブロックチェーン２への出力指示を受信し、受信した出力指示に応じて該医療データのハッシュ値をブロックチェーン２に出力する。

　具体的には、サーバ１は、暗号学的ハッシュ関数を用いて医療データのハッシュ値を算出する。例えばサーバ１は、ＳＨＡ２－２５６アルゴリズムを用いたハッシュ関数を採用し、医療データのハッシュ値を算出する。なお、ハッシュ関数に限らず、他の暗号化方式であっても良い。サーバ１は、患者ＤＩＤ、医師ＤＩＤ及び医療データＩＤに対応付け、算出した医療データのハッシュ値をブロックチェーン２のいずれかのノード２１に送信する。ブロックチェーン２のノード２１は、サーバ１から送信された患者ＤＩＤ、医師ＤＩＤ、医療データＩＤ及び医療データのハッシュ値を受信して記録する。サーバ１は、医療データＩＤに対応付け、医療データのハッシュ値、ブロックチェーン２への記録日時、及び「ＢＣへ記録済み」となった状態を医療データＤＢ１７４に記憶する。

　図１１は、医療データをブロックチェーン２に記録する処理を説明する説明図である。ブロックチェーン２の一つのノード２１は、サーバ１から送信された取引データ（トランザクション）を受信する。図示のように、患者ＤＩＤ、医師ＤＩＤ、医療データＩＤ及び医療データのハッシュ値が取引データに含まれる。ノード２１は、受信した取引データに含まれている患者ＤＩＤ、医師ＤＩＤ、医療データＩＤ及び医療データのハッシュ値と、自身が管理しているブロックチェーンの情報とを基に作成した前ブロック管理情報とを少なくとも含むブロックを生成する。

　そして、ブロックチェーン２の各々のノード２１は、所定のコンセンサスアルゴリズムに従った処理を実行する。例えばビットコイン（登録商標）に係るブロックチェーン技術を本システムに応用した場合、ノード２１、ノード２１、ノード２１…は、ＰｏＷ（Proof of Work）と呼ばれる演算処理を実行し、ブロックチェーン２を更新するノード２１を決定する。ＰｏＷは、新たに生成するブロックの一つ前のブロックに予め格納されたハッシュ値から、ある正解値を探索する（マイニング）演算処理である。

　ノード２１は、新たにブロックを生成する場合、当該ブロックの一つ前のブロックに格納されたハッシュ値及び取引データをハッシュ化したハッシュ値を生成し、最新のブロックに格納する。例えば図１１に示すように、ブロック３を生成する場合、ノード２１は、ブロック２に格納されているハッシュ値と、複数の取引データとをハッシュ化してハッシュ値を生成し、ブロック３に格納する。例えばビットコインの例では、ノード２１は演算処理の難易度を上げる目的で、取引データのほかにナンス値をヘッダに挿入してハッシュ値を生成する。ナンス値は、ハッシュ値のヘッダにゼロが所定数連続するような値であり、ナンス値に係るゼロの数を適切な数に設計することで、演算処理の処理負荷が調整される。

　各ノード２１は、最新のブロックを生成する場合、前のブロックに含まれる当該ハッシュ値から正解値（ビットコインの例ではナンス値）を探索するという探索問題を解く。例えば図１１に示すように、ブロック３を新たに生成する場合、各ノード２１は、ブロック２のブロックに格納されているハッシュ値から正解値を探索する。１回の演算処理で正解値を探し当てる確率は低く、例えばビットコイン等の仮想通貨に係るブロックチェーン技術を応用した場合、平均して１０分程度の時間を要する。各ノード２１は一斉に探索問題の演算処理を実行し、正解値を探索する。そして、最も早く正解値を探し当てたノード２１に、最新のブロックを生成する権限が与えられる。不正者がブロックチェーンのデータを書き換えようとする場合、善意の検証者（ノード２１）全ての演算処理速度を上回る速度でブロックを生成する必要があり、実際に不正な書き換えを行うことは極めて難しくなっている。

　探索に成功した場合、ノード２１は、検証した取引データ（患者ＤＩＤ、医師ＤＩＤ、医療データＩＤ及び医療データのハッシュ値）を格納した最新のブロックを生成し、当該ブロックに係るデータを他のノード２１、２１、２１…に通知する。この場合、上述の如くノード２１は、一つ前のブロックに格納されているハッシュ値及び取引データからハッシュ値を生成し、当該ハッシュ値を新たなブロックに格納した上で各ノード２１に通知する。

　例えば図１１に示すように、ノード２１は、ブロック２に格納されているハッシュ値及び取引データをハッシュ化したハッシュ値を生成し、新たなブロック３に格納して他のノード２１、２１、２１…に通知する。新たなブロックに格納されたハッシュ値は、一つ前のブロックのハッシュ値を含むことから、ブロックチェーンを構成する各ブロックは時系列的に関連付けられている。他のノード２１、２１、２１…は、通知されたブロックのデータの正当性を確認した後、取引データを記憶部２１２に記憶する。これにより、各ノード２１、２１、２１…の記憶部２１２には、同一のブロックチェーンに係るデータが複製されて記憶される。

　なお、探索に成功したノード２１の管理者（マイナー）には、探索に成功した報酬が与えられる。すなわち、探索に成功したノード２１の管理者に、当該ブロックに格納されている各取引の手数料が支払われる。これにより、管理者にはノード２１という計算資源を投入するインセンティブが与えられる。

　なお、上記ではブロックチェーンの更新権限を決定する手法としてＰｏＷを用いたが、本実施の形態はこれに限定されるものではなく、例えばＰＯＩ（Proof of Importance）、ＰＯＳ（Proof of Stake）等を用いても良い。また、上記ではビットコイン技術を応用したシステムについて説明したが、本実施の形態はこれに限定されるものではない。例えばビットコイン以外に、イーサリアム、ハイパーレジャー・ファブリック（Hyperledger Fabric）等に係るブロックチェーン技術を応用しても良い。

　続いて、ブロックチェーン２に記録された医療データを用いて医療を研究する研究者からの医療データの開示要求に応じて、該医療データを研究者端末５に出力する処理を説明する。

　図１２は、医療データを研究者端末５に出力する動作を説明する説明図である。なお、研究者の属性が予め登録される。研究者の属性は、研究者の氏名、生年月日、郵便番号、住所、電話番号、メールアドレス、プロフィールまたは研究目的等を含む。なお、研究者の登録処理に関しては、患者の登録処理と同様であるため、説明を省略する。

　研究者端末５は、研究者による医療データの開示要求を受け付けた場合、受け付けた開示要求を、研究者ＤＩＤ及び医療データＩＤに対応付けてサーバ１に送信する。サーバ１は、研究者端末５から送信された研究者ＤＩＤ、医療データＩＤ及び開示要求を、該医療データを提供した患者の患者端末４に送信する。なお、開示要求と共に研究者のメッセージまたはプロフィールが患者端末４に送信されても良い。この場合、患者端末４は、研究者のメッセージまたはプロフィールを開示要求と共に画面に表示する。

　患者端末４は、サーバ１から送信された開示要求に応じて、医療データの開示要求に対する承認情報を受け付けた場合、受け付けた承認情報をサーバ１に送信する。サーバ１は、患者端末４から送信された承認情報に応じて、研究者から患者へ所定のトークンを支払うトランザクションを作成する。トランザクションとは、ブロックチェーン２における取引記録であり、ブロックチェーン２の参加者間での各種の情報及び価値の移転を記憶している。作成されたトランザクションは、研究者のウォレットアドレス、患者のウォレットアドレス、支払ったトークン数量及び取引日時を含む。

　ウォレットアドレスは、取引ごとに作成された仮想通貨用の口座番号であり、文字列又はＱＲコードとして表示する。ウォレットアドレスは、ブロックチェーン２で利用されている公開鍵暗号を基にして、数学的に導出されたアドレスである。また、送信元と送信先のウォレットアドレスは、ブロックチェーン２のノード２１に記録され、ブロックチェーン２のシステムが維持し続ける限り改ざんされない。ウォレットアドレスは計算で生成されるため、オンライン又はオフラインでも作成することが可能となる。

　サーバ１は、ブロックチェーン２のいずれかのノード２１に、作成したトランザクションを送信する。ブロックチェーン２のノード２１は、トランザクションを受信してトークンの支払処理を実行する。なお、本実施形態では、研究者が医療データを提供した患者にトークンを支払ったが、これに限るものではない。例えば、研究者が医療データに電子署名した医師のみに所定のトークンを支払っても良い。または、研究者が医療データを提供した患者と、該医療データに電子署名した医師との両方に所定のトークンを支払っても良い。更にまた、研究者の開示要求にもかかわらず、医師が医療データに電子署名した場合、例えばスポンサーまたはシステム運営者が該医師に所定のトークンを支払っても良い。

　なお、本実施形態では、トークンの一種である仮想通貨（暗号資産）の例を説明したが、これに限るものではない。例えば、電子マネー、クーポンまたはポイント等の他の種類のトークンにも同様に適用することができる。

　ノード２１は、トークンの支払処理を実行した後に、医療データＩＤに基づいて該医療データのハッシュ値を取得する。ノード２１は、取得した医療データのハッシュ値をサーバ１に送信する。サーバ１は、ノード２１から送信された医療データのハッシュ値を受信する。サーバ１は、医療データＩＤに基づいて該医療データのハッシュ値を医療データＤＢ１７４から取得する。サーバ１は、ノード２１から送信された医療データのハッシュ値と、医療データＤＢ１７４に記憶された医療データのハッシュ値とを照合する。サーバ１は、両者が一致していると判定した場合、該医療データのハッシュ値に対応する医療データを医療データＤＢ１７４から取得する。サーバ１は、取得した医療データを研究者端末５に送信する。研究者端末５は、サーバ１から送信された医療データを受信して画面に表示する。

　なお、上述したトークンの支払処理に限らず、スマートコントラクトを利用しても良い。スマートコントラクトは、事前に執行条件及び契約内容の定義がプログラム化されてトランザクションに組み込まれ、執行条件及び契約内容に合致した取引が発生した場合、自動的に契約が履行される仕組みである。サーバ１は、医療データの取引処理を行うための必要な執行条件、患者及び研究者のウォレットアドレス等が記述されたスマートコントラクトのコードを生成する。サーバ１は、生成したスマートコントラクトのコードを含むトランザクションをブロックチェーン２のいずれかのノード２１に送信する。ブロックチェーン２のノード２１は、受信したスマートコントラクトを含むトランザクションを記録する。

　スマートコントラクトのコードの内容は、例えば研究者の開示要求に対する患者の承認を得た場合、研究者のウォレットアドレス宛から患者のウォレットアドレス宛に所定のトークンを支払う契約をコードで定義している。トランザクションは、スマートコントラクトのコード、患者及び研究者の電子署名を含む。ブロックチェーン２のノード２１は、研究者の開示要求に対する患者の承認を得た執行条件に合致した場合、契約内容上で決められた所定のトークンを研究者のウォレットアドレス宛から患者のウォレットアドレス宛に支払う。

　なお、本実施形態では、研究者が患者にトークンを支払う例を説明したが、これに限らず、例えばスポンサーまたはシステム運営者が患者に所定のトークンを支払っても良い。

　図１３は、質問に対する回答の入力画面の一例を示す説明図である。該画面は、回答入力欄１１ａ、保存ボタン１１ｂ及びサブミットボタン１１ｃを含む。回答入力欄１１ａは、医療に関する質問に対する患者による回答の入力を受け付ける入力欄である。保存ボタン１１ｂは、質問に対する回答を下書き保存するボタンです。サブミットボタン１１ｃは、質問に対する回答をサーバ１に送信（サブミット）するボタンである。

　なお、図１３では、質問の種類がＰＤＱ－３９である例を説明するが、他の質問の種類にも同様に適用される。患者端末４は、ＰＤＱ－３９をサーバ１の記憶部１２または外部装置から取得する。患者端末４は、取得したＰＤＱ－３９を回答入力欄１１ａに表示する。患者端末４は、回答入力欄１１ａの入力操作を受け付けた場合、質問に対する患者による回答を受け付ける。患者端末４は、保存ボタン１１ｂのタッチ（クリック）操作を受け付けた場合、回答入力欄１１ａにより入力された回答を下書き保存する。患者端末４は、サブミットボタン１１ｃのタッチ操作を受け付けた場合、回答入力欄１１ａにより入力された回答と患者の属性とを患者ＤＩＤに対応付けてサーバ１に送信する。

　図１４は、医療データの作成画面の一例を示す説明図である。該画面は、ＱＲコード生成ボタン１２ａ、患者からデータ取得ボタン１２ｂ、ＱＲコード表示欄１２ｃ、患者属性表示欄１２ｄ、閲覧ボタン１２ｅ、診療データ受付欄１２ｆ、署名送信ボタン１２ｇ及び結果表示欄１２ｈを含む。

　ＱＲコード生成ボタン１２ａは、医師ＤＩＤを記述したＱＲコードを生成するボタンである。患者からデータ取得ボタン１２ｂは、患者から患者の属性及び質問に対する回答を取得するボタンである。ＱＲコード表示欄１２ｃは、ＱＲコードを表示する表示欄である。患者属性表示欄１２ｄは、患者の属性を表示する表示欄である。

　閲覧ボタン１２ｅは、質問に対する回答を表示するボタンである。なお、閲覧ボタン１２ｅの数が、質問の種類に基づいて設けられても良い。図示のように、「ＰＤＱ－３９」、「ＭＤＳ－ＵＰＤＲＳ」及び「ＥＱ－５Ｄ」それぞれの閲覧ボタン１２ｅが設けられる。医師端末３は、質問に対する回答をサーバ１から取得したと判定した場合、該当する閲覧ボタン１２ｅのタイトルを「閲覧」に設定し、閲覧ボタン１２ｅを操作可能なアクティブ（活性）状態に設定する。また、医師端末３は、質問に対する回答をサーバ１から取得していないと判定した場合、該当する閲覧ボタン１２ｅのタイトルを「データなし」に設定し、閲覧ボタン１２ｅを操作不可能な非アクティブ（非活性）状態に設定する。

　診療データ受付欄１２ｆは、医師が患者を診断した診療データの入力を受け付ける受付欄である。署名送信ボタン１２ｇは、患者の属性、質問に対する回答及び診療データを含む医療データを電子署名して送信するボタンである。結果表示欄１２ｈは、医療データに対する電子署名及び送信処理の結果を表示する表示欄である。

　医師端末３は、ＱＲコード生成ボタン１２ａのクリック（タッチ）操作を受け付けた場合、二次元コードを生成するライブラリを利用し、医師ＤＩＤを記述したＱＲコードを生成する。医師端末３は、生成したＱＲコードをＱＲコード表示欄１２ｃに表示する。患者端末４は、医師端末３上で表示されているＱＲコードを読み取ることにより医師ＤＩＤを取得する。

　患者端末４は、取得した医師ＤＩＤと患者ＤＩＤとをサーバ１に送信する。サーバ１は、患者端末４から送信された医師ＤＩＤ及び患者ＤＩＤを受信し、受信した患者ＤＩＤに基づいて患者の属性及び質問に対する回答を患者ＤＢ１７１及び質問ＤＢ１７３から取得する。サーバ１は、取得した患者の属性及び質問に対する回答を、受信した医師ＤＩＤに対応する医師端末３に送信する。

　また、患者からデータ取得ボタン１２ｂにより患者の属性及び質問に対する回答を取得することができる。具体的には、医師端末３は、患者からデータ取得ボタン１２ｂのクリック操作を受け付けた場合、患者ＤＩＤの入力を受け付けるためのサブ画面を生成する。医師端末３は、生成したサブ画面に患者ＤＩＤの入力を受け付け、受け付けた患者ＤＩＤをサーバ１に送信する。その後に、上述した処理と同様に、患者の属性及び質問に対する回答がサーバ１から取得される。

　医師端末３は、サーバ１から送信された患者の属性及び質問に対する回答を受信する。医師端末３は、受信した患者の属性を患者属性表示欄１２ｄに表示する。医師端末３は、閲覧ボタン１２ｅのクリック操作を受け付けた場合、該当する質問に対する回答をサブ画面に表示する。例えば、医師端末３は、「ＰＤＱ－３９」に対応する閲覧ボタン１２ｅのクリック操作を受け付けた場合、質問に対する回答を表示するためのサブ画面を生成する。医師端末３は、受信した質問に対する回答から「ＰＤＱ－３９」に対する回答を取得し、取得した「ＰＤＱ－３９」に対する回答をサブ画面に表示する。

　医師端末３は、診療データ受付欄１２ｆの入力操作を受け付ける。診療データは、診断データ、治療データ及び検査データを含む。診断データは、病状情報及び疾患情報（例えば、医師により決定された疾患名）等の診断に関するデータである。治療データは、患者の疾患に対する治療方針、治療法、手術情報または薬剤情報等の治療に関するデータである。検査データは、疾患の有無またはその程度を調べるために、患者が受けた各種の検査（例えば、血液検査）に関するデータである。

　図示のように、医師端末３は、重症度分類を含む診断データ、処方情報（薬剤の成分名、剤型または用量等）を含む治療データ、並びに、医療診断画像、嗅覚検査、血圧及び脈拍を含む検査データの入力を診療データ受付欄１２ｆにより受け付ける。医療診断画像は、例えばMRI(Magnetic Resonance Image)、DAT(Dopamine transporter) Scan、Cardiac MIBG(123I-metaiodobenzylguanidine) ScintigraphyまたはBrain Perfusion SPECT(Single Photon Emission Computed Tomography)等の検査により得られた画像である。なお、図１４では、パーキンソン病の検査項目の例を説明したが、これに限らず、他の種類の疾患の検査項目にも同様に適用される。

　医師端末３は、署名送信ボタン１２ｇのクリック操作を受け付けた場合、患者の属性、質問に対する回答及び診療データを含む医療データを電子署名し、電子署名付き医療データを患者ＤＩＤ及び医師ＤＩＤに対応付けてサーバ１に送信する。医師端末３は、医療データに対する電子署名及び送信処理の結果を結果表示欄１２ｈに表示する。図示のように、「署名＆送信に成功しました」が結果表示欄１２ｈに表示される。

　図１５は、患者端末４側での医療データの表示画面の一例を示す説明図である。なお、図１５は電子署名未取得の医療データの例示である。該画面は、医療データＩＤ表示欄１３ａ、状態アイコン１３ｂ、日時表示欄１３ｃ、医師表示ボタン１３ｄ、開示要求表示欄１３ｅ、開示請求ボタン１３ｆ及び取引履歴表示ボタン１３ｇを含む。

　医療データＩＤ表示欄１３ａは、医療データＩＤを表示する表示欄である。状態アイコン１３ｂは、医療データの状態を示すアイコンである。日時表示欄１３ｃは、医療データの各状態の更新日時を表示する表示欄である。医師表示ボタン１３ｄは、医療データを電子署名した医師の属性を表示する表示欄である。開示要求表示欄１３ｅは、開示要求に関する情報を表示する表示欄である。開示請求ボタン１３ｆは、後述の開示要求の応答画面（図１８）に遷移するためのボタンである。取引履歴表示ボタン１３ｇは、後述の取引履歴画面（図１９）に遷移するためのボタンである。

　患者端末４は患者ＤＩＤに基づいて、医療データに関する情報をサーバ１の管理ＤＢ１７７から取得する。医療データに関する情報は、医療データＩＤ、医療データの状態（下書き保存、サブミット済み、署名済み及びＢＣへ記録済み）、及び各状態の更新日時を含む。患者端末４は、医療データＩＤごとに医療データに関する情報を画面に表示する。

　具体的には、患者端末４は、医療データＩＤを医療データＩＤ表示欄１３ａに表示する。患者端末４は、医療データの状態に応じて該当するアイコンを状態アイコン１３ｂに表示する。図示のように、患者端末４は、医療データの状態が「サブミット済み」であると判定した場合、「サブミット済み」状態を示すアイコンを状態アイコン１３ｂに表示し、医師表示ボタン１３ｄを操作不可能な非アクティブ状態に設定する。

　患者端末４は、各状態の更新日時を日時表示欄１３ｃに表示する。図示のように、「下書き保存」の日時、「サブミット済み」の日時、「署名済み」の日時及び「ＢＣへ記録済み」の日時が日時表示欄１３ｃに表示される。なお、医師からの電子署名を未取得の状態であるため、「署名済み」の日時の代わりに、「医師に署名を依頼してください」となる提示情報が日時表示欄１３ｃに表示される。また、該医療データがブロックチェーン２に記録されていないため、「ＢＣへ記録済み」の日時の代わりに、「－」が日時表示欄１３ｃに表示される。

　患者端末４は、医療データの状態に応じて開示請求ボタン１３ｆ及び取引履歴表示ボタン１３ｇのアクティブ状態を設定する。具体的には、患者端末４は、医療データの状態が「下書き保存」、「サブミット済み」または「署名済み」であると判定した場合、開示請求ボタン１３ｆ及び取引履歴表示ボタン１３ｇを操作不可能な非アクティブ状態に設定する。患者端末４は、医療データの状態が「ＢＣへ記録済み」であると判定した場合、開示請求ボタン１３ｆ及び取引履歴表示ボタン１３ｇを操作可能なアクティブ状態に設定する。

　図１６は、患者端末４側での医療データの表示画面の一例を示す説明図である。なお、図１６は電子署名取得済みの医療データの例示である。なお、図１５と重複する内容については同一の符号を付して説明を省略する。

　患者端末４は患者ＤＩＤに基づいて、医療データに関する情報をサーバ１の管理ＤＢ１７７から取得する。医療データに関する情報は、医療データＩＤ、医療データの状態、各状態の更新日時、医療データを電子署名した医師の医師ＤＩＤ及び属性を含む。

　患者端末４は、医療データの状態が「署名済み」であると判定した場合、「署名済み」状態を示すアイコンを状態アイコン１３ｂに表示し、医師による署名済みの日時を日時表示欄１３ｃに表示する。患者端末４は、医師表示ボタン１３ｄを操作可能なアクティブ状態に設定する。患者端末４は、医師表示ボタン１３ｄのタッチ操作を受け付けた場合、医療データＩＤをサーバ１に送信する。サーバ１は、患者端末４から送信された医療データＩＤに基づいて該医療データを署名した医師の医師ＤＩＤを医療データＤＢ１７４から取得する。

　サーバ１は、取得した医師ＤＩＤに基づいて医師の属性を医師ＤＢ１７２から取得する。医師の属性は、医師の氏名、及び医師が所属する医療機関の名称を含む。サーバ１は、取得した医師ＤＩＤ及び医師の属性を患者端末４に送信する。患者端末４は、サーバ１から送信された医師ＤＩＤ及び医師の属性を受信し、受信した医師ＤＩＤ及び医師の属性を日時表示欄１３ｃ（「署名済み」の日時と「ＢＣへ記録済み」の日時との間の領域）に表示し、医師表示ボタン１３ｄのタイトルを「医師非表示」に変更する。

　図１７は、患者端末４側での医療データの表示画面の一例を示す説明図である。なお、図１７はブロックチェーン２への記録済みの医療データの例示である。なお、図１５及び図１６と重複する内容については同一の符号を付して説明を省略する。

　患者端末４は患者ＤＩＤに基づいて、医療データに関する情報及び開示要求に関する情報をサーバ１から取得する。医療データに関する情報は、医療データＩＤ、医療データの状態、各状態の更新日時、医療データを電子署名した医師の医師ＤＩＤ及び属性を含む。開示要求に関する情報は、医療データに対する開示要求の数量、承認待ちの数量、「開示のみ」で承認済みの数量、及び「開示＆共有」で承認済みの数量を含む。

　具体的には、患者端末４は、患者ＤＩＤをサーバ１に送信する。サーバ１は、患者端末４から送信された患者ＤＩＤを受信する。サーバ１は、受信した患者ＤＩＤに基づいて医療データに関する情報を管理ＤＢ１７７から取得する。サーバ１は、患者ＤＩＤ及び医療データＩＤに基づいて、医療データの開示要求に関する情報を管理ＤＢ１７７から取得する。

　サーバ１は、取得した医療データに関する情報及び開示要求に関する情報を患者端末４に送信する。患者端末４は、サーバ１から送信された医療データに関する情報及び開示要求に関する情報を受信して画面に表示する。なお、医療データに関する情報の表示処理に関しては、図１６と同様であるため、説明を省略する。患者端末４は、受信した開示要求に関する情報を開示要求表示欄１３ｅに表示する。図示のように、医療データに対する開示要求の数量、承認待ちの数量、「開示のみ」で承認済みの数量、及び「開示＆共有」で承認済みの数量が開示要求表示欄１３ｅに表示される。

　患者端末４は、医療データの状態が「ＢＣへ記録済み」であると判定した場合、「ＢＣへ記録済み」状態を示すアイコンを状態アイコン１３ｂに表示し、「ＢＣへ記録済み」の日時を日時表示欄１３ｃに表示し、開示請求ボタン１３ｆ及び取引履歴表示ボタン１３ｇを操作可能なアクティブ状態に設定する。患者端末４は、開示請求ボタン１３ｆのタッチ操作を受け付けた場合、後述の開示要求の応答画面（図１８）に遷移する。患者端末４は、取引履歴表示ボタン１３ｇのタッチ操作を受け付けた場合、後述の医療データの取引履歴画面（図１９）に遷移する。

　図１８は、患者端末４側での開示要求の応答画面の一例を示す説明図である。なお、図１５～図１７と重複する内容については同一の符号を付して説明を省略する。該画面は、開示要求表示欄１４ａ、承認ボタン１４ｂ、否認ボタン１４ｃ、撤回ボタン１４ｄ及び承認種別設定ダイアログ１４ｅを含む。

　開示要求表示欄１４ａは、医療データの開示要求に関する情報を表示する表示欄である。承認ボタン１４ｂは、医療データの開示要求に応じて承認処理を行うためのボタンである。否認ボタン１４ｃは、医療データの開示要求に応じて否認処理を行うためのボタンである。撤回ボタン１４ｄは、承認済みの医療データに対して承認の撤回処理を行うためのボタンである。承認種別設定ダイアログ１４ｅは、医療データに対する承認種別の設定を受け付けるダイアログ（子画面）である。

　患者端末４は、医療データＩＤに基づいて該医療データの開示要求に関する情報をサーバ１から取得する。患者端末４は、取得した開示要求に関する情報を開示要求表示欄１４ａに表示する。図示のように、研究者ＤＩＤ、申請日時及び要求状況（例えば、承認待ち）が開示要求表示欄１４ａに表示される。なお、開示要求に関する情報は、上記の項目に限らず、例えば研究者の氏名及びメールアドレス等を含んでも良い。

　患者端末４は、承認ボタン１４ｂのタッチ操作を受け付けた場合、承認種別設定ダイアログ１４ｅを生成して画面に表示する。承認種別設定ダイアログ１４ｅは、承認種別設定ラジオボタン１４ｆ及びダイアログ内承認ボタン１４ｇを含む。承認種別設定ラジオボタン１４ｆは、医療データに対する承認種別（「開示のみ」または「開示＆共有」）を受け付けるラジオボタンである。ダイアログ内承認ボタン１４ｇは、承認種別に応じて医療データの承認処理を行うためのボタンである。

　患者端末４は、承認種別設定ラジオボタン１４ｆのタッチ操作を受け付けた場合、承認種別の設定を受け付ける。患者端末４は、ダイアログ内承認ボタン１４ｇのタッチ操作を受け付けた場合、承認種別設定ラジオボタン１４ｆにより設定された承認種別を医療データＩＤに対応付けてサーバ１に送信する。

　患者端末４は、否認ボタン１４ｃのタッチ操作を受け付けた場合、医療データＩＤに対応付け、該医療データの利用を否認したことを示す否認情報をサーバ１に送信する。患者端末４は、撤回ボタン１４ｄのタッチ操作を受け付けた場合、医療データＩＤに対応付け、該承認済みの医療データを承認撤回したことを示す承認撤回情報をサーバ１に送信する。

　図１９は、患者端末４側での医療データの取引履歴画面の一例を示す説明図である。なお、図１５～図１７と重複する内容については同一の符号を付して説明を省略する。該画面は、取引履歴表示欄１５ａを含む。取引履歴表示欄１５ａは、医療データの取引履歴を表示する表示欄である。

　患者端末４は、患者ＤＩＤ及び医療データＩＤをサーバ１に送信する。サーバ１は、患者端末４から送信されたＤＩＤ及び医療データＩＤを受信する。サーバ１は、受信した患者ＤＩＤ及び医療データＩＤに基づいて、医療データの取引履歴を取引履歴ＤＢ１７６から取得する。サーバ１は、取得した取引履歴を患者端末４に送信する。患者端末４は、サーバ１から送信された取引履歴を受信して取引履歴表示欄１５ａに表示する。図示のように、研究者ＤＩＤ、患者ＤＩＤ、取引履歴日時及び医療データのハッシュ値を含む取引履歴が取引履歴表示欄１５ａに表示される。

　図２０は、患者端末４側での医療データの詳細画面の一例を示す説明図である。なお、図１５～図１７と重複する内容については同一の符号を付して説明を省略する。該画面は、医療データ表示欄１６ａを含む。医療データ表示欄１６ａは、医療データの詳細情報を表示する表示欄である。

　患者端末４は、患者ＤＩＤ及び医療データＩＤをサーバ１に送信する。サーバ１は、患者端末４から送信されたＤＩＤ及び医療データＩＤを受信する。サーバ１は、受信した患者ＤＩＤ及び医療データＩＤに基づいて、患者の属性、医療に関する質問に対する患者による回答（例えば、ＰＤＱ－３９に対する回答）、及び医師による患者に対する診療データ（例えば、血圧、処方情報または脈拍）を含む医療データを医療データＤＢ１７４から取得する。サーバ１は、取得した医療データを患者端末４に送信する。患者端末４は、サーバ１から送信された医療データを受信して医療データ表示欄１６ａに表示する。

　図２１は、研究者端末５側での医療データ管理画面の一例を示す説明図である。該画面は、研究者表示欄１７ａ、管理情報表示欄１７ｂ、アクションボタン１７ｃ及び患者ＤＩＤリンク１７ｄを含む。研究者表示欄１７ａは、研究者の氏名を表示する表示欄である。管理情報表示欄１７ｂは、医療データの管理情報を表示する表示欄である。

　アクションボタン１７ｃは、医療データに対するアクションを受け付けるボタンである。アクションは、「データ請求」及び「閲覧」を含む。「データ請求」アクションは、医療データを提供した患者に該医療データの開示要求を送信するアクションである。「閲覧」アクションは、医療データを閲覧（表示）するアクションである。なお、本実施形態では、アクションが「データ請求」及び「閲覧」を含む例を説明したが、これに限るものではない。例えば、アクションには「再承認」または「再請求」が含まれても良い。「再承認」アクションは、研究者の開示要求に応じて一旦開示が拒否された医療データに対し、再び承認の要求を送信するアクションである。「再請求」アクションは、医療データに対して開示可能な期間（例えば、一年）が設けられた場合、開示可能な期間を過ぎた後に、医療データを提供した患者に該医療データの開示要求を再送信するアクションである。患者ＤＩＤリンク１７ｄは、後述の医療データの表示画面（図２９）に遷移するためのボタンである。

　研究者端末５は、研究者ＤＩＤをサーバ１に送信する。サーバ１は、研究者端末５から送信された研究者ＤＩＤを受信し、受信した研究者ＤＩＤに基づいて研究者の氏名及び研究機関ＩＤを研究者ＤＢ１７５から取得する。サーバ１は研究者ＤＩＤに基づいて、患者ＤＩＤ、開示要求に関する情報及び医師による医療データの署名日時を管理ＤＢ１７７から取得する。サーバ１は、取得した研究者の氏名、研究機関ＩＤ、患者ＤＩＤ、開示要求に関する情報及び医師による医療データの署名日時を研究者端末５に送信する。

　研究者端末５は、サーバ１から送信された研究者の氏名、研究機関ＩＤ、患者ＤＩＤ、開示要求に関する情報及び医療データの署名日時を受信する。研究者端末５は、受信した研究者の氏名を研究者表示欄１７ａに表示し、研究機関ＩＤ、患者ＤＩＤ、開示要求に関する情報及び医療データの署名日時を管理情報表示欄１７ｂに表示する。開示要求に関する情報は、データ種類、開示要求状況、開示要求日時、承認日時、否認日時及び承認撤回日時を含む。開示要求状況は、データ未請求、承認済（閲覧＆共有）、承認済（閲覧のみ）、撤回済及び保留中を含む。

　図示のように、研究機関ＩＤ、患者ＤＩＤ（データ所有者）、データ種類、開示要求（リクエスト）状況、開示要求状況に応じて生成されたアクションボタン１７ｃ、医師署名日時、研究者の開示要求（リクエスト）日時、患者の承認日時、患者の否認日時及び患者の承認撤回日時が管理情報表示欄１７ｂに表示される。

　研究者端末５は、開示要求状況に応じて、アクションボタン１７ｃのタイトル及びアクティブ状態を設定する。具体的には、研究者端末５は、開示要求状況が「データ未請求」であると判定した場合、アクションボタン１７ｃのタイトルを「データ請求」に設定し、アクションボタン１７ｃを操作可能なアクティブ状態に設定する。研究者端末５は、開示要求状況が「撤回済」または「保留中」であると判定した場合、アクションボタン１７ｃのタイトルを「データ請求」に設定し、アクションボタン１７ｃを操作不可能な非アクティブ状態に設定する。研究者端末５は、開示要求状況が「承認済（閲覧＆共有）」または「承認済（閲覧のみ）」であると判定した場合、アクションボタン１７ｃのタイトルを「閲覧」に設定し、アクションボタン１７ｃを操作可能なアクティブ状態に設定する。

　研究者端末５は、タイトルが「データ請求」であるアクションボタン１７ｃのタッチ操作を受け付けた場合、研究者ＤＩＤ及び医療データＩＤをサーバ１に送信する。サーバ１は、研究者端末５から送信された研究者ＤＩＤ及び医療データＩＤを受信し、受信した研究者ＤＩＤ及び医療データＩＤに基づいて該医療データの開示要求を作成する。サーバ１は、作成した開示要求を患者端末４に送信する。

　研究者端末５は、タイトルが「閲覧」であるアクションボタン１７ｃのタッチ操作を受け付けた場合、医療データＩＤに基づいて医療データをサーバ１の医療データＤＢ１７４から取得する。研究者端末５は、取得した医療データを画面に表示する。患者が一度研究者に医療データの開示を承認した場合、該医療データを継続して閲覧することができる。または、医療データに対して開示可能な期間が設けられても良い。例えば、所定期間（例えば、一年）内に、研究者が該医療データを繰り返して閲覧することができる。

　研究者端末５は、患者ＤＩＤリンク１７ｄのクリック操作を受け付けた場合、開示要求状況を判定する。研究者端末５は、開示要求の状況が「承認済（閲覧＆共有）」または「承認済（閲覧のみ）」であると判定した場合、該患者ＤＩＤに対応する患者が所有している医療データの表示画面（図２９）に遷移する。

　図２２は、研究者端末５側での取引履歴画面の一例を示す説明図である。該画面は、取引履歴表示欄１８ａを含む。取引履歴表示欄１８ａは、取引履歴を表示する表示欄である。研究者端末５は、研究者ＤＩＤをサーバ１に送信する。サーバ１は、研究者端末５から送信された研究者ＤＩＤを受信し、受信した研究者ＤＩＤに基づいて該研究者の医療データの取引履歴を取引履歴ＤＢ１７６から取得する。サーバ１は、取得した取引履歴を研究者端末５に送信する。

　研究者端末５は、サーバ１から送信された取引履歴を受信して取引履歴表示欄１８ａに表示する。図示のように、研究者が所属する研究機関の研究機関ＩＤ、医療データＩＤ、取引日時、患者ＤＩＤ、研究者ＤＩＤ及び医療データのハッシュ値を含む医療データの取引履歴が取引履歴表示欄１８ａに表示される。なお、単一の取引履歴の表示を例示したがこれに限定せず、複数の取引履歴を列挙しても良い。

　なお、上述した医療データの取引履歴が医師端末３または患者端末４に送信され、取引履歴画面が医師端末３側または患者端末４側で表示されても良い。

　図２３及び図２４は、医療データを作成する際の処理手順を示すフローチャートである。医師端末３の制御部３１は、二次元コードを生成するライブラリを利用し、医師ＤＩＤを記述した二次元コード（例えば、ＱＲコード）を生成する（ステップＳ３１１）。制御部３１は、生成した二次元コードを表示部３５により表示する（ステップＳ３１２）。患者端末４の制御部４１は、医師端末３上で表示されている二次元コードを撮影部４６により読み取る（ステップＳ４１１）。

　制御部４１は、二次元コードの解析ライブラリを利用し、読み取った二次元コードから医師ＤＩＤを取得する（ステップＳ４１２）。制御部４１は通信部４３を介して、患者の属性及び医療に関する質問に対する患者による回答をサーバ１から取得する（ステップＳ４１３）。具体的には、制御部４１は患者ＤＩＤに基づいて、患者の属性をサーバ１の大容量記憶部１７の患者ＤＢ１７１から取得し、質問に対する回答をサーバ１の大容量記憶部１７の質問ＤＢ１７３から取得する。なお、制御部４１は、患者による質問に対する回答の入力を入力部４４により受け付けても良い。

　制御部４１は通信部４３を介して、取得した患者の属性及び質問に対する回答を、患者ＤＩＤ及び医師ＤＩＤに対応付けてサーバ１に送信する（ステップＳ４１４）。サーバ１の制御部１１は通信部１３を介して、患者端末４から送信された患者ＤＩＤ、医師ＤＩＤ、患者の属性及び回答を受信し（ステップＳ１１１）、受信した患者ＤＩＤ、医師ＤＩＤ、患者の属性及び回答を医師端末３に送信する（ステップＳ１１２）。医師端末３の制御部３１は、サーバ１から送信された患者ＤＩＤ、医師ＤＩＤ、患者の属性及び回答を通信部３３により受信する（ステップＳ３１３）。制御部３１は、受信した患者の属性及び回答を表示部３５により表示する（ステップＳ３１４）。

　制御部３１は、医師による患者に対する診療データの入力を入力部３４により受け付ける（ステップＳ３１５）。制御部３１は、患者の属性、質問に対する回答及び診療データを含む医療データに対する電子署名の指示を入力部３４により受け付け（ステップＳ３１６）、制御部３１の電子署名作成部３１ｂは、医師の秘密鍵を用いて、該医療データに対して電子署名処理を行う（ステップＳ３１７）。制御部３１は、患者ＤＩＤ及び医師ＤＩＤに対応付けて電子署名付き医療データを通信部３３によりサーバ１に送信する（ステップＳ３１８）。

　サーバ１の制御部１１は、医師端末３から送信された患者ＤＩＤ、医師ＤＩＤ及び署名付き医療データを通信部１３により受信する（ステップＳ１１３）。制御部１１は公開鍵を用いて、受信した電子署名付き医療データを復号する（ステップＳ１１４）。制御部１１は、例えばＥｔｈｅｒｅｕｍの一つのスマートコントラクト規格であるＥＲＣ７２１を利用し、医療データを特定する医療データＩＤを作成する（ステップＳ１１５）。制御部１１は、作成した医療データＩＤに対応付け、患者ＤＩＤ、医療データ、医師ＤＩＤ、電子署名日時及び「署名済み」となった医療データの状態を一つのレコードとして医療データＤＢ１７４に記憶する（ステップＳ１１６）。

　制御部１１は、医療データを通信部１３により患者端末４に送信する（ステップＳ１１７）。患者端末４の制御部４１は、サーバ１から送信された医療データを通信部４３により受信し（ステップＳ４１５）、受信した医療データを表示部４５により表示する（ステップＳ４１６）。制御部４１は、患者から該医療データをブロックチェーン２に記録する指示を入力部４４により受け付けた場合（ステップＳ４１７）、ブロックチェーン２への記録指示を通信部４３によりサーバ１に送信する（ステップＳ４１８）。

　サーバ１の制御部１１は、患者端末４から送信されたブロックチェーン２への記録指示を通信部１３により受信する（ステップＳ１１８）。制御部１１のハッシュ値算出部１１ａは、暗号学的ハッシュ関数を用いて医療データのハッシュ値を算出する（ステップＳ１１９）。制御部１１は、算出した医療データのハッシュ値を医療データＩＤに対応付けて医療データＤＢ１７４に記憶する（ステップＳ１２０）。制御部１１は、算出した医療データのハッシュ値を患者ＤＩＤ及び医師ＤＩＤに対応付けてトランザクションを作成する（ステップＳ１２１）。作成されたトランザクションは、患者ＤＩＤ、医師ＤＩＤ及び医療データのハッシュ値を含む。

　制御部１１は、トランザクションデータを分散して管理するブロックチェーン２のいずれかのノード２１に、作成したトランザクションを通信部１３により送信する（ステップＳ１２２）。ブロックチェーン２のノード２１の制御部２１１は、サーバ１から送信されたトランザクションを通信部２１３により受信する（ステップＳ２１１）。ノード２１の制御部２１１は、受信したトランザクションに基づいて、医療データのハッシュ値を患者ＤＩＤ及び医師ＤＩＤに関連付けて記録する（ステップＳ２１２）。

　具体的には、トランザクションを受信したノード２１の制御部２１１は、ブロック生成部２１６を介して、受信したトランザクションに含まれた患者ＤＩＤ、医師ＤＩＤ及び医療データのハッシュ値と、自身が管理しているブロックチェーン（台帳）の情報とを基に作成した前ブロック管理情報とを少なくとも含むブロックを生成する。そして、ブロックチェーン２のノード２１各々の制御部２１１は、所定のコンセンサス処理をブロック生成部２１６により実行する。ブロックチェーンは、ブロックとよばれる所定のデータ構造を有するデータ群を時系列に並べたものであり、取引内容を記した台帳としての役割を有する。各ブロックは、取引内容等の当該ブロックに記録したいデータの他に、一つ以上前のブロック（以下、前ブロックという）の情報と、改ざんの有無を検知するための情報（ノンスまたは署名等）とを含む。ノンスは、あるデータ領域に対して、その領域内のデータを一方向性関数により処理したときに得られる値が予め決められた規則を満たすように設定される、当該データ領域内の値である。

　ブロックチェーン２には、２台以上のノードが参加する所定のコンセンサスアルゴリズムに従った処理を経て新たなブロックが追加される。例えば、コンセンサスアルゴリズムの一つであるＰｏＷでは、前ブロックの情報とノンスとを含む各ブロック（データ群）に対して、「ブロックのＨａｓｈ値が閾値以下であること」といった規則が予め決められており、ブロックを追加する際に、そのような規則を満たすようなノンスを複数のノードが同時並列的に探索する処理がブロック検証部２１７により行われる。なお、ＰｏＷ以外にもＢＦＴ（Byzantine fault tolerance）等のコンセンサスアルゴリズムがある。ブロックチェーン２のノード２１各々の制御部２１１は、所定のコンセンサス処理を実行した後に、ブロック共有部２１８を介して、ブロック生成部２１６が生成したブロックを記憶部２１２に記憶（追加）する。

　なお、本実施形態では、ブロックチェーン２への記録処理をサーバ１側で実行したが、これに限らず、患者端末４側で実行しても良い。

　図２５及び図２６は、患者の承認を得た医療データを研究者端末５に出力する際の処理手順を示すフローチャートである。研究者端末５の制御部５１は、ブロックチェーン２に記録された医療データの開示要求を入力部５４により受け付ける（ステップＳ５３１）。制御部５１は通信部５３を介して、研究者ＤＩＤ及び医療データＩＤに対応付け、受け付けた開示要求をサーバ１に送信する（ステップＳ５３２）。サーバ１の制御部１１は、研究者端末５から送信された研究者ＤＩＤ、医療データＩＤ及び開示要求を通信部１３により受信する（ステップＳ１３１）。制御部１１は、受信した研究者ＩＤ、医療データＩＤ及び開示要求を、該医療データを提供した患者の患者端末４に送信する（ステップＳ１３２）。

　患者端末４の制御部４１は、サーバ１から送信された研究者ＩＤ、医療データＩＤ及び開示要求を通信部４３により受信する（ステップＳ４３１）。制御部４１は、受信した開示要求に応じて、医療データに対する承認情報を受け付け（ステップＳ４３２）、受け付けた承認情報を通信部４３によりサーバ１に送信する（ステップＳ４３３）。承認情報は、医療データが開示可能であるか否かを示す情報、及び医療データに対する承認種別（「開示のみ」、または「開示＆共有」）を含む。

　サーバ１の制御部１１は、患者端末４から送信された承認情報を通信部１３により受信する（ステップＳ１３３）。制御部１１は、受信した承認情報に基づいて、開示要求の対象となる医療データが開示可能であるか否かを判定する（ステップＳ１３４）。制御部１１は、該医療データが開示不可能であると判定した場合（ステップＳ１３４でＮＯ）、開示不可の旨を含む通知を通信部１３により研究者端末５に送信する（ステップＳ１３５）。研究者端末５の制御部５１は、サーバ１から送信された開示不可通知を通信部５３により受信し（ステップＳ５３３）、受信した開示不可通知を表示部５５により表示する（ステップＳ５３４）。

　制御部１１は、該医療データが開示可能であると判定した場合（ステップＳ１３４でＹＥＳ）、研究者から患者へ所定のトークンを支払うトランザクションを作成する（ステップＳ１３６）。トランザクションは、研究者のウォレットアドレス、患者のウォレットアドレス、支払ったトークン数量及び取引日時を含む。制御部１１は、ブロックチェーン２のいずれかのノード２１に、作成したトランザクションを通信部１３により送信する（ステップＳ１３７）。

　ブロックチェーン２のノード２１は、サーバ１から送信されたトランザクションを通信部２１３により受信し（ステップＳ２３１）、受信したトランザクションを実行する（ステップＳ２３２）。ノード２１の制御部２１１は、医療データＩＤに基づいて該医療データのハッシュ値を取得する（ステップＳＳ２３３）。ノード２１の制御部２１１は、取得した医療データのハッシュ値を通信部２１３によりサーバ１に送信する（ステップＳ２３４）。

　サーバ１の制御部１１は、ブロックチェーン２から送信された医療データのハッシュ値を通信部１３により受信する（ステップＳ１３８）。制御部１１は、医療データＩＤに基づいて該医療データのハッシュ値を大容量記憶部１７の医療データＤＢ１７４から取得する（ステップＳ１３９）。制御部１１は、取得した医療データのハッシュ値と、ノード２１から送信された医療データのハッシュ値とを照合し、両者が一致しているか否かを判定する（ステップＳ１４０）。

　制御部１１は、両者が一致していないと判定した場合（ステップＳ１４０でＮＯ）、不正な医療データである旨を含むエラーメッセージを通信部１３により研究者端末５に送信する（ステップＳ１４１）。研究者端末５の制御部５１は、サーバ１から送信されたエラーメッセージを通信部５３により受信し（ステップＳ５３５）、受信したエラーメッセージを表示部５５により表示する（ステップＳ５３６）。

　制御部１１は、両者が一致していると判定した場合（ステップＳ１４０でＹＥＳ）、該医療データのハッシュ値に対応する医療データを大容量記憶部１７の医療データＤＢ１７４から取得する（ステップＳ１４２）。制御部１１は、取得した医療データを通信部１３により研究者端末５に送信する（ステップＳ１４３）。研究者端末５の制御部５１は、サーバ１から送信された医療データを通信部５３により受信し（ステップＳ５３７）、受信した医療データを表示部５５により表示し（ステップＳ５３８）、処理を終了する。

　本実施形態によると、医師による電子署名付き医療データを作成することが可能となる。

　本実施形態によると、研究者が、医療データを提供した患者に所定のトークンを支払うことにより、医療データの提供を積極的に進めることが可能となる。

　本実施形態によると、研究者がブロックチェーン２に記録された医療データを用いて医療を研究することにより、新しい治療法の研究、健康寿命の延伸、医療サービスの質の向上または医療費または介護費の抑制等に貢献することが可能となる。

　（実施形態２）
　実施形態２は、研究者により医療データを共有する形態に関する。なお、実施形態１と重複する内容については説明を省略する。

　研究者は、患者により設定された医療データの承認種別に基づき、医療データを利用する。医療データの承認種別が「開示のみ」である場合、開示要求を行った研究者に該医療データを開示することができるが、他の研究者に共有することができない。医療データの承認種別が「開示＆共有」である場合、開示要求を行った研究者に該医療データを開示することができ、かつ、他の研究者に共有することができる。

　図２７は、医療データを共有する際の処理手順を示すフローチャートである。なお、図２７のフローチャートでは説明の便宜上、共有元の研究者端末５を符号５ａで表し、共有先の研究者端末５を符号５ｂで表す。

　研究者端末５ａの制御部５１は、医療データＩＤを通信部５３によりサーバ１に送信する（ステップＳ５５１）。サーバ１の制御部１１は、研究者端末５ａから送信された医療データＩＤを通信部１３により受信する（ステップＳ１５１）。制御部１１は、受信した医療データＩＤに基づいて、該医療データの承認種別を大容量記憶部１７の医療データＤＢ１７４から取得する（ステップＳ１５２）。制御部１１は、取得した承認種別を通信部１３により研究者端末５ａに送信する（ステップＳ１５３）。

　研究者端末５ａの制御部５１は、サーバ１から送信された承認種別を通信部５３により受信する（ステップＳ５５２）。制御部５１は、受信した承認種別が「開示＆共有」であるか否かを判定する（ステップＳ５５３）。制御部５１は、承認種別が「開示＆共有」でないと判定した場合（ステップＳ５５３でＮＯ）、処理を終了する。制御部５１は、承認種別が「開示＆共有」であると判定した場合（ステップＳ５５３でＹＥＳ）、共有先の研究者ＤＩＤの入力を入力部５４により受け付ける（ステップＳ５５４）。

　制御部５１は、医療データＩＤ、及び受け付けた共有先の研究者ＤＩＤを通信部５３によりサーバ１に送信する（ステップＳ５５５）。サーバ１の制御部１１は、研究者端末５ａから送信された医療データＩＤ及び共有先の研究者ＤＩＤを通信部１３により受信する（ステップＳ１５４）。制御部１１は、受信した医療データＩＤに基づいて医療データを大容量記憶部１７の医療データＤＢ１７４から取得する（ステップＳ１５５）。制御部１１は、取得した医療データを通信部１３により研究者端末５ｂに送信する（ステップＳ１５６）。研究者端末５ｂの制御部５１は、サーバ１から送信された医療データを通信部５３により受信し（ステップＳ５５６）、受信した医療データを表示部５５により表示し（ステップＳ５５７）、処理を終了する。

　なお、上述した共有処理に限るものではない。例えば、承認種別が「開示＆共有」である医療データを研究者に開示した場合、該研究者が所属する研究機関内の他の研究者に、該医療データを自動的に共有しても良い。

　本実施形態によると、医療データを他の研究者に共有することにより、医療データの活用に役立つことが可能となる。

　（実施形態３）
　実施形態３は、医療データを用いて研究した研究結果に関する情報を患者端末４に出力する形態に関する。なお、実施形態１～２と重複する内容については説明を省略する。研究結果は、例えば大量の患者の医療データに基づく学術論文、レポート、研究計画書、または治療に関する病気・症状・治療方法の動画等を含む。

　図２８は、研究結果に関する情報を患者端末４に出力する際の処理手順を示すフローチャートである。研究者端末５の制御部５１は、医療データを用いて研究した研究結果に関する情報を取得する（ステップＳ５７１）。具体的には、制御部５１は、研究結果に関する情報を入力部５４により受け付けても良く、または通信部５３により外部装置から取得しても良い。例えば研究結果が論文である場合、研究結果に関する情報は、論文のタイトル、著者・編者、書誌番号、発表日時または内容等を含む。

　制御部５１は通信部５３を介して、研究者ＤＩＤと取得した研究結果に関する情報とを、該研究結果に関連付けられた医療データＩＤに対応付けてサーバ１に送信する（ステップＳ５７２）。サーバ１の制御部１１は、研究者端末５から送信された研究者ＤＩＤ、研究結果に関する情報及び医療データＩＤを通信部１３により受信する（ステップＳ１７１）。制御部１１は、受信した医療データＩＤに基づき、該医療データを提供した患者を特定する（ステップＳ１７２）。具体的には、制御部１１は、研究者ＤＩＤ及び医療データＩＤに基づき、患者ＤＩＤを大容量記憶部１７の取引履歴ＤＢ１７６から取得して患者を特定する。

　制御部１１は、特定した患者の患者端末４に研究結果に関する情報を通信部１３により送信する（ステップＳ１７３）。患者端末４の制御部４１は、サーバ１から送信された研究結果に関する情報を通信部４３により受信し（ステップＳ４７１）、受信した研究結果に関する情報を表示部４５により表示し（ステップＳ４７２）、処理を終了する。

　本実施形態によると、医療データを用いて研究した研究結果を、該医療データを提供した患者に共有（送信）することにより、患者から医療データの提供を積極的に進めることが可能となる。

　（実施形態４）
　実施形態４は、複数回の医療データを統合的に出力する形態に関する。なお、実施形態１～３と重複する内容については説明を省略する。本実施形態では、患者の属性、複数回の質問に対する患者による回答、及び、医師による初回診断時の診療データと、２回目以降の診断時の診療データとを統合した診療データを含む医療データを研究者端末５に出力する処理を説明する。

　図２９は、研究者端末５側での複数回の医療データの表示画面の一例を示す説明図である。なお、図２９では、パーキンソン病の検査項目の例を説明したが、これに限らず、他の種類の疾患の検査項目にも同様に適用される。

　該画面は、患者ＤＩＤ表示欄１９ａ、閲覧ボタン１９ｂ、重症度分類表示欄１９ｃ、診断画像表示オブジェクト１９ｄ、嗅覚検査表示欄１９ｅ、処方情報表示欄１９ｆ、血圧表示欄１９ｇ、脈拍表示欄１９ｈ及びダウンロードボタン１９ｉを含む。患者ＤＩＤ表示欄１９ａは、患者ＤＩＤを表示する表示欄である。閲覧ボタン１９ｂは、質問に対する回答を表示するボタンである。なお、閲覧ボタン１９ｂに関しては、図１４の閲覧ボタン１２ｅと同様であるため、説明を省略する。

　重症度分類表示欄１９ｃは、複数回の重症度分類情報を表示する表示欄である。パーキンソン病において、重症度がI度（症状は片方の手足のみ）、II度（症状は両方の手足に）、III度（姿勢反射障害が加わってくる）、IV度（日常生活に部分的な介助が必要）及びV度（車いすでの生活または寝たきりとなる）に分類される。重症度分類情報は、重症度分類及び重症度の診断日時を含む。図示のように、「I：2012/06/08」、「II：2017/10/31」及び「III:2020/03/04」となった重症度分類情報が重症度分類表示欄１９ｃに表示される。診断画像表示オブジェクト１９ｄは、複数回の診断画像を表示するためのボタンである。なお、診断画像表示オブジェクト１９ｄの数が、診断画像の種類に基づいて設けられても良い。図示のように、「MRI」、「DAT Scan」、「Cardiac MIBG Scintigraphy」及び「Brain Perfusion SPECT」それぞれの診断画像表示オブジェクト１９ｄが設けられる。

　嗅覚検査表示欄１９ｅは、複数回の嗅覚検査の結果を表示する表示欄である。処方情報表示欄１９ｆは、複数回の処方情報を表示する表示欄である。血圧表示欄１９ｇは、複数回の血圧検査結果を表示する表示欄である。脈拍表示欄１９ｈは、複数回の脈拍の検査結果を表示する表示欄である。ダウンロードボタン１９ｉは、医療データをダウンロードするボタンである。

　研究者端末５は、患者ＤＩＤ及び研究者ＤＩＤをサーバ１に送信する。サーバ１は、研究者端末５から送信された患者ＤＩＤ及び研究者ＤＩＤを受信し、受信した患者ＤＩＤ及び研究者ＤＩＤに基づいて該患者の複数回の医療データを取得する。具体的には、サーバ１は、患者ＤＩＤに基づいて、質問種類ごとにすべての質問に対する回答を質問ＤＢ１７３から取得する。サーバ１は、患者ＤＩＤ及び研究者ＤＩＤに基づいて、取引対象となった医療データの医療データＩＤを取引履歴ＤＢ１７６から抽出する。サーバ１は、抽出した医療データＩＤに基づいて、該当するすべての医療データを医療データＤＢ１７４から取得する。

　サーバ１は、取得した複数回の医療データを研究者端末５に送信する。研究者端末５は、サーバ１から送信された複数回の医療データ対して統合する。研究者端末５は、統合した複数回の医療データを画面に表示する。具体的には、研究者端末５は、診断日時の新しい順に複数回の重症度分類を医療データから抽出し、抽出した複数回の重症度分類を重症度分類表示欄１９ｃに表示する。

　研究者端末５は、診断日時の古い順に複数回の嗅覚検査結果を医療データから抽出し、抽出した複数回の嗅覚検査結果に基づいて嗅覚検査の評点を示すグラフを生成する。研究者端末５は、生成したグラフを嗅覚検査表示欄１９ｅに表示する。図示のように、患者におけるにおいスティック（OSIT-J：Odor Stick Identification Test for Japanese)を用いた嗅覚検査の評点を示すグラフが嗅覚検査表示欄１９ｅに表示される。横軸は１回目、２回目、…と検査回数を示し、縦軸は嗅覚検査の評点を示す。なお、横軸は嗅覚検査の日付であっても良い。なお、複数の嗅覚検査法が利用された場合、研究者端末５はそれぞれの検査法に対応するグラフを生成して嗅覚検査表示欄１９ｅに並びに表示しても良い。

　研究者端末５は、診断日時の新しい順に複数回の処方情報を医療データから抽出し、抽出した複数回の処方情報を処方情報表示欄１９ｆに表示する。研究者端末５は、診断日時の古い順に複数回の血圧（高血圧及び低血圧）検査結果を医療データから抽出し、抽出した複数回の血圧検査結果に基づいて血圧の値を示すグラフを生成する。研究者端末５は、生成したグラフを血圧表示欄１９ｇに表示する。図示のように、横軸は１回目、２回目、…と検査回数を示し、縦軸は血圧の値を示す。なお、横軸は血圧検査の日付であっても良い。

　研究者端末５は、診断日時の古い順に複数回の脈拍検査結果を医療データから抽出し、抽出した複数回の脈拍検査結果に基づいて脈拍数を示すグラフを生成する。研究者端末５は、生成したグラフを脈拍表示欄１９ｈに表示する。図示のように、横軸は１回目、２回目、…と検査回数を示し、縦軸は脈拍数を示す。なお、横軸は脈拍検査の日付であっても良い。

　研究者端末５は、閲覧ボタン１９ｂのクリック（タッチ）操作を受け付けた場合、該当する質問に対する複数回の回答をサブ画面に表示する。例えば研究者端末５は、「ＰＤＱ－３９」に対応する閲覧ボタン１９ｂのクリック操作を受け付けた場合、質問に対する回答を表示するためのサブ画面を生成する。研究者端末５は、受信した医療データから「ＰＤＱ－３９」に対する複数回の回答を抽出し、抽出した複数回の回答をサブ画面に表示する。

　研究者端末５は、診断画像表示オブジェクト１９ｄのクリック操作を受け付けた場合、該当する複数回の診断画像をサブ画面に表示する。例えば研究者端末５は、「DAT Scan」に対応する診断画像表示オブジェクト１９ｄのクリック操作を受け付けた場合、診断画像を表示するためのサブ画面を生成する。研究者端末５は、受信した医療データから「DAT Scan」に対する複数回の診断画像を抽出し、抽出した複数回の診断画像をサブ画面に表示する。なお、診断画像と、診断画像を撮影した日時との両方がサブ画面に表示されても良い。

　研究者端末５は、ダウンロードボタン１９ｉのクリック操作を受け付けた場合、複数回の医療データに基づいて統合された医療データをＥｘｃｅｌ（登録商標）ファイルまたはＰＤＦ（Portable Document Format）ファイル等に書き込む。研究者端末５は、医療データを書き込んだファイルを、指定されたフォルダにダウンロードする。

　なお、図２９では、複数回の医療データの表示例を説明したが、これに限らず、１回の医療データにも同様に適用される。

　本実施形態によると、複数回の医療データを統合的に出力することにより、長期的な経過観察及び治療効果の判定等に利用することができるため、医療研究に役立つことが可能となる。

　（実施形態５）
　実施形態５は、所定期間以降の第２期間における患者の医療データを再開示する形態に関する。なお、実施形態１～４と重複する内容については説明を省略する。

　図３０は、実施形態５における管理ＤＢ１７７のレコードレイアウトの一例を示す説明図である。なお、図６と重複する内容については同一の符号を付して説明を省略する。管理ＤＢ１７７には、承諾情報列及び再開示期間列が含まれる。

　承諾情報列は、患者の医療データの再開示に関する承諾情報（例えば、再開示可能または再開示不可）を記憶している。再開示期間列は、医療データの再開示期間を記憶している。再開示期間は、所定期間以降の第２期間である。例えば、所定期間が起算日から２年であり、第２期間が２年以降の２０年であっても良い。起算日は、例えば医療データをブロックチェーン２のノード２１に最初に登録した登録日であっても良く、または当該医療データの開示要求に対する患者の最初の承認を得た承認日であっても良い。なお、第２期間が予め再開示期間列に記憶されても良く、またはユーザによる設定が受け付けられても良い。

　患者端末４は、所定期間以降の第２期間における医療データの再開示に関する承諾情報を受け付けた場合、受け付けた承諾情報をサーバ１に送信する。医療データに対し承諾情報が得られた場合、第２期間における当該医療データを再開示することができる。サーバ１は、患者端末４から送信された承諾情報を医療データＩＤに対応つけて管理ＤＢ１７７に記憶する。

　第２期間において、研究者端末５は、研究者による医療データの再開示要求を受け付けた場合、受け付けた再開示要求を、研究者ＤＩＤ及び医療データＩＤに対応付けてサーバ１に送信する。サーバ１は、研究者端末５から送信された研究者ＤＩＤ、医療データＩＤ及び再開示要求を受信する。サーバ１は、受信した再開示要求に応じて、当該医療データを再開示可能であるか否かを判定する。

　具体的には、サーバ１は医療データＩＤに基づき、当該医療データに対応する承諾情報及び第２期間（再開示期間）を管理ＤＢ１７７から取得する。サーバ１は、取得した承諾情報及び第２期間に基づいて、当該医療データを再開示可能であるか否かを判定する。例えば、第２期間において、承諾情報が「再開示可能」である場合、制御部１１は当該医療データを再開示可能と判定する。または、第２期間において、承諾情報が「再開示不可」である場合、制御部１１は当該医療データを再開示不可と判定する。

　サーバ１は、当該医療データを再開示可能と判定した場合、サーバ１から送信された再開示要求、研究者ＤＩＤ及び医療データＩＤを、該医療データを提供した患者の患者端末４に送信する。患者端末４は、サーバ１から送信された再開示要求、研究者ＤＩＤ及び医療データＩＤを画面に表示する。なお、再開示要求と共に、過去の開示要求の履歴（研究者ＤＩＤ、開示要求日時または承認日時等）、研究者のメッセージまたはプロフィールが患者端末４に送信されても良い。この場合、患者端末４は、過去の開示要求の履歴、研究者のメッセージまたはプロフィールを開示要求と共に画面に表示する。

　患者端末４は、当該医療データの再開示要求に対する患者の再承認情報を受け付けた場合、受け付けた再承認情報をサーバ１に送信する。再承認情報は、医療データが再開示可能であるか否かを示す情報、及び医療データに対する承認種別（「開示のみ」、または「開示＆共有」）を含む。サーバ１は、患者端末４から送信された再承認情報を受信する。サーバ１は、受信した再承認情報に応じて、医療データが再開示可能であるか否かを判定する。

　サーバ１は、当該医療データが再開示可能であると判定した場合、ブロックチェーン２のノード２１を経由して、研究者から患者へ所定のトークンを支払う。なお、支払処理に関しては、実施形態１と同様であるため、説明を省略する。なお、患者により当該医療データを無料で提供する等のサービスを有する場合には、トークンの支払処理を省略しても良い。

　ブロックチェーン２のノード２１は、トークンの支払処理を実行した後に、医療データＩＤに基づいて当該医療データのハッシュ値を取得する。ノード２１は、取得した医療データのハッシュ値をサーバ１に送信する。サーバ１は、ノード２１から送信された医療データのハッシュ値を受信する。サーバ１は、受信した医療データのハッシュ値と、医療データＤＢ１７４に記憶された医療データのハッシュ値とを照合する。

　サーバ１は、両者が一致していると判定した場合、当該医療データのハッシュ値に対応する医療データを医療データＤＢ１７４から取得する。サーバ１は、取得した医療データを研究者端末５に送信する。研究者端末５は、サーバ１から送信された医療データを受信して画面に表示する。

　図３１は、承諾情報の受付画面の一例を示す説明図である。なお、図１８と重複する内容については同一の符号を付して説明を省略する。

　承認種別設定ダイアログ１４ｅは、承諾チェックボックス１４ｈを含む。承諾チェックボックス１４ｈ■、所定期間（例えば、２年）以降の第２期間（例えば、２０年）において、患者の医療データの再開示に関する承諾情報を受け付けるチェックボックスである。患者端末４は、承諾チェックボックス１４ｈ■チェック操作を受け付けた場合、受け付けた承諾情報（例えば、再開示可能または再開示不可）■取得する。なお、第２期間をユーザ（例えば、患者）が設定できるようにしても良い。

　患者端末４は、ダイアログ内承認ボタン１４ｇのタッチ操作を受け付けた場合、承認種別設定ラジオボタン１４ｆにより設定された承認種別、及び承諾チェックボックス１４ｈにより取得された承諾情報を医療データＩＤに対応付けてサーバ１に送信する。サーバ１は、患者端末４から送信された承認種別及び承諾情報を医療データＩＤに対応付けて管理ＤＢ１７７に記憶する。

　図３２は、患者の再承認を得た医療データを研究者端末５に出力する際の処理手順を示すフローチャートである。なお、図２５及び図２６と重複する内容については同一の符号を付して説明を省略する。

　研究者端末５の制御部５１は、ブロックチェーン２のノード２１の記憶部２１２に記録された医療データの再開示要求を入力部５４により受け付ける（ステップＳ５８１）。制御部５１は通信部５３を介して、研究者ＤＩＤ及び医療データＩＤに対応付け、受け付けた再開示要求をサーバ１に送信する（ステップＳ５８２）。サーバ１の制御部１１は、研究者端末５から送信された研究者ＤＩＤ、医療データＩＤ及び再開示要求を通信部１３により受信する（ステップＳ１８１）。

　制御部１１は、受信した医療データＩＤに基づき、当該医療データに対応する承諾情報及び第２期間を大容量記憶部１７の管理ＤＢ１７７から取得する（ステップＳ１８２）。制御部１１は、取得した承諾情報及び第２期間に基づいて、当該医療データを再開示可能であるか否かを判定する（ステップＳ１８３）。

　制御部１１は、当該医療データを再開示不可と判定した場合（ステップＳ１８３でＮＯ）、再開示不可の旨を含む通知を通信部１３により研究者端末５に送信する（ステップＳ１８４）。研究者端末５の制御部５１は、サーバ１から送信された再開示不可通知を通信部５３により受信し（ステップＳ５８３）、受信した再開示不可通知を表示部５５により表示する（ステップＳ５８４）。

　制御部１１は、当該医療データを再開示可能と判定した場合（ステップＳ１８３でＹＥＳ）、制御部１１は、受信した研究者ＩＤ、医療データＩＤ及び再開示要求を、当該医療データを提供した患者の患者端末４に送信する（ステップＳ１８５）。患者端末４の制御部４１は、サーバ１から送信された研究者ＩＤ、医療データＩＤ及び再開示要求を通信部４３により受信する（ステップＳ４８１）。制御部４１は、受信した研究者ＩＤ、医療データＩＤ及び再開示要求を表示部４５により表示する（ステップＳ４８２）。

　制御部４１は、受信した再開示要求に応じて、医療データに対する患者の再承認情報を受け付けた場合（ステップＳ４８３）、受け付けた再承認情報を通信部４３によりサーバ１に送信する（ステップＳ４８４）。再承認情報は、医療データが再開示可能であるか否かを示す情報、及び医療データに対する承認種別を含む。サーバ１の制御部１１は、患者端末４から送信された再承認情報を通信部１３により受信する（ステップＳ１８６）。

　制御部１１は、受信した再承認情報に基づいて、当該医療データが再開示可能であるか否かを判定する（ステップＳ１８７）。制御部１１は、当該医療データが再開示不可能であると判定した場合（ステップＳ１８７でＮＯ）、ステップＳ１８４の処理に戻る。制御部１１は、当該医療データが再開示可能であると判定した場合（ステップＳ１８７でＹＥＳ）、ステップＳ１３６の処理を実行する。

　本実施形態によると、患者の医療データの再開示に関する承諾情報に基づき、所定期間以降の第２期間において、当該医療データを再開示することが可能となる。

　本実施形態によると、医療データの再開示により、医療データを活用して医療技術の進歩を促すことが可能となる。

　今回開示された実施の形態はすべての点で例示であって、制限的なものではないと考えられるべきである。本発明の範囲は、上記した意味ではなく、請求の範囲によって示され、請求の範囲と均等の意味及び範囲内でのすべての変更が含まれることが意図される。

　１　　　　情報処理装置（サーバ）
　１１　　　制御部
　１２　　　記憶部
　１３　　　通信部
　１４　　　入力部
　１５　　　表示部
　１６　　　読取部
　１７　　　大容量記憶部
　１７１　　患者ＤＢ
　１７２　　医師ＤＢ
　１７３　　質問ＤＢ
　１７４　　医療データＤＢ
　１７５　　研究者ＤＢ
　１７６　　取引履歴ＤＢ
　１７７　　管理ＤＢ
　１ａ　　　可搬型記憶媒体
　１ｂ　　　半導体メモリ
　１Ｐ　　　制御プログラム
　２　　　　ブロックチェーンシステム（ブロックチェーン）
　２１　　　ノード
　２１１　　制御部
　２１２　　記憶部
　２１３　　通信部
　２１４　　受付部
　２１５　　出力部
　２１６　　ブロック生成部
　２１７　　ブロック検証部
　２１８　　ブロック共有部
　３　　　　情報処理端末（医師端末）
　３１　　　制御部
　３１ａ　　ハッシュ値算出部
　３１ｂ　　電子署名作成部
　３２　　　記憶部
　３３　　　通信部
　３４　　　入力部
　３５　　　表示部
　３Ｐ　　　制御プログラム
　４　　　　情報処理端末（患者端末）
　４１　　　制御部
　４２　　　記憶部
　４３　　　通信部
　４４　　　入力部
　４５　　　表示部
　４６　　　撮影部
　５　　　　情報処理端末（研究者端末）
　５１　　　制御部
　５２　　　記憶部
　５３　　　通信部
　５４　　　入力部
　５５　　　表示部

Claims

　患者を特定する患者ＩＤ、患者の属性、及び医療に関する質問に対する前記患者による回答を取得し、
　医師を特定する医師ＩＤを前記患者の患者端末装置により読み取らせることにより前記医師ＩＤを取得し、
　取得した前記医師ＩＤに対応する医師端末装置へ前記患者の患者ＩＤ、属性及び回答を送信し、
　前記患者の患者ＩＤ、属性及び回答が表示された前記医師端末装置を通じて、前記医師による前記患者に対する診療データの入力を受け付け、
　前記患者の属性、回答及び入力された診療データを含む医療データの送信要求を受け付け、
　前記医療データのハッシュ値をブロックチェーンシステムに出力し、
　前記ブロックチェーンシステムに記録された前記医療データの開示要求を研究者の研究者端末装置を介して受け付け、
　前記研究者の開示要求に対する前記患者の承認を得た場合に、前記医療データを前記研究者端末装置に出力する
　情報処理方法。
　前記医師の秘密鍵を用いて電子署名を行った電子署名付き医療データを前記医師端末装置から取得し、
　取得した前記医療データを前記患者端末装置に出力する
　請求項１に記載の情報処理方法。
　前記医療データに対する前記ブロックチェーンシステムへの出力指示を前記患者端末装置から受け付けた場合に、前記医療データのハッシュ値を前記ブロックチェーンシステムに出力する
　請求項１又は２に記載の情報処理方法。
　前記医師ＩＤを記述した二次元コードを前記患者端末装置により読み取らせることにより前記医師ＩＤを取得する
　請求項１から３のいずれか一つに記載の情報処理方法。
　前記開示要求に対する前記患者の承認を得た場合に、前記研究者のウォレットアドレス宛から前記患者のウォレットアドレス宛へ、前記ブロックチェーンシステム経由で所定のトークンを支払う
　請求項１から４のいずれか一つに記載の情報処理方法。
　前記医療データの開示要求に対する承認、または、前記承認と、前記医療データの開示要求に対して承認を得た前記医療データを、他の研究者に共有することを求める共有要求に対する前記患者の第２承認とを含む承認情報を前記患者端末装置から受け付け、
　受け付けた前記承認情報を前記医療データに対応付けて記憶する
　請求項１から５のいずれか一つに記載の情報処理方法。
　所定期間以降の第２期間における前記医療データの再開示に関する承諾情報を前記患者端末装置から受け付け、
　前記第２期間において、前記承諾情報が得られた医療データの再開示要求を研究者の研究者端末装置を介して受け付けた場合、受け付けた再開示要求を前記患者端末装置に送信し、
　前記再開示要求に対する前記患者の再承認を得た場合に、前記医療データを前記研究者端末装置に出力する
　請求項１から６のいずれか一つに記載の情報処理方法。
　前記医療データを用いて研究した研究結果に関する情報を前記研究者端末装置から受け付け、
　受け付けた前記研究結果に関する情報を、前記医療データを提供した患者の患者端末装置に出力する
　請求項１から７のいずれか一つに記載の情報処理方法。
　前記医療データを特定する医療データＩＤ、前記医療データの取引日時、前記患者ＩＤ、前記研究者を特定する研究者ＩＤ及び前記医療データのハッシュ値を含む取引履歴を取得し、
　取得した前記取引履歴を、前記研究者端末装置、前記医師端末装置または前記患者端末装置に送信する
　請求項２から８のいずれか一つに記載の情報処理方法。
　前記患者ＩＤ、前記開示要求に関する情報及び前記医師による医療データの署名日時を取得し、
　取得した前記患者ＩＤ、前記開示要求に関する情報及び前記医療データの署名日時を前記研究者端末装置に送信する
　請求項２から９のいずれか一つに記載の情報処理方法。
　前記医療データに対する開示要求を前記研究者端末装置から受け付けた場合に、受け付けた前記開示要求を、前記医療データを提供した患者の患者端末装置に送信する
　請求項１から１０のいずれか一つに記載の情報処理方法。
　前記医療データＩＤ、前記開示要求に関する情報及び前記医師ＩＤを取得し、
　取得した前記医療データＩＤ、前記開示要求に関する情報及び前記医師ＩＤを前記患者端末装置に送信する
　請求項１から１１のいずれか一つに記載の情報処理方法。
　前記医療データを記憶したが前記医師からの電子署名を未取得の状態であるか、前記医師から前記医療データの電子署名を取得済みの状態であるか、または前記医療データを前記ブロックチェーンシステムに記録済みの状態であるかを示す前記医療データの状態を前記患者端末装置に送信し、
　前記医療データの状態を示すオブジェクトを前記患者端末装置に表示させる
　請求項２から１２のいずれか一つに記載の情報処理方法。
　患者を特定する患者ＩＤ、患者の属性、及び医療に関する質問に対する前記患者による回答を取得する第１取得部と、
　医師を特定する医師ＩＤを前記患者の患者端末装置により読み取らせることにより前記医師ＩＤを取得する第２取得部と、
　取得した前記医師ＩＤに対応する医師端末装置へ前記患者の患者ＩＤ、属性及び回答を送信する送信部と、
　前記患者の患者ＩＤ、属性及び回答が表示された前記医師端末装置を通じて、前記医師による前記患者に対する診療データの入力を受け付ける第１受付部と、
　前記患者の属性、回答及び入力された診療データを含む医療データの送信要求を受け付ける第２受付部と、
　前記医療データのハッシュ値をブロックチェーンシステムに出力する第１出力部と、
　前記ブロックチェーンシステムに記録された前記医療データの開示要求を研究者の研究者端末装置を介して受け付ける第３受付部と、
　前記研究者の開示要求に対する前記患者の承認を得た場合に、前記医療データを前記研究者端末装置に出力する第２出力部と
　を備える情報処理装置。
　患者を特定する患者ＩＤ、患者の属性、及び医療に関する質問に対する前記患者による回答を取得し、
　医師を特定する医師ＩＤを前記患者の患者端末装置により読み取らせることにより前記医師ＩＤを取得し、
　取得した前記医師ＩＤに対応する医師端末装置へ前記患者の患者ＩＤ、属性及び回答を送信し、
　前記患者の患者ＩＤ、属性及び回答が表示された前記医師端末装置を通じて、前記医師による前記患者に対する診療データの入力を受け付け、
　前記患者の属性、回答及び入力された診療データを含む医療データの送信要求を受け付け、
　前記医療データのハッシュ値をブロックチェーンシステムに出力し、
　前記ブロックチェーンシステムに記録された前記医療データの開示要求を研究者の研究者端末装置を介して受け付け、
　前記研究者の開示要求に対する前記患者の承認を得た場合に、前記医療データを前記研究者端末装置に出力する
　処理をコンピュータに実行させるプログラム。
　患者を特定する患者ＩＤを取得し、
　患者の属性、及び医療に関する質問に対する前記患者による回答を受け付け、
　医師を特定する医師ＩＤを取得し、
　取得した前記医師ＩＤに対応付けて、前記患者の患者ＩＤ、属性及び回答を送信し、
　前記患者の属性、回答及び前記医師による前記患者に対する診療データを含む医療データを受信し、
　ブロックチェーンシステムに記録された前記医療データの研究者による開示要求を受信した場合に、前記研究者の開示要求に対する前記患者の承認を得たか否かを示す情報を送信する
　処理をコンピュータに実行させるプログラム。
　前記医療データに対する前記ブロックチェーンシステムへの出力指示を受け付け、
　受け付けた前記ブロックチェーンシステムへの出力指示を送信する
　処理を実行させる請求項１６に記載のプログラム。
　前記医師ＩＤを記述した二次元コードを読み取り、
　読み取った前記二次元コードから前記医師ＩＤを取得する
　処理を実行させる請求項１６又は１７に記載のプログラム。
　前記医療データの開示要求に対する承認、または、前記承認と、前記医療データの開示要求に対して承認を得た前記医療データを、他の研究者に共有することを求める共有要求に対する前記患者の第２承認とを含む承認情報を受け付け、
　受け付けた前記承認情報を、前記医療データを特定する医療データＩＤに対応付けて送信する
　処理を実行させる請求項１６から１８のいずれか一つに記載のプログラム。
　前記医療データを記憶したが前記医師からの電子署名を未取得の状態であるか、前記医師から前記医療データの電子署名を取得済みの状態であるか、または前記医療データを前記ブロックチェーンシステムに記録済みの状態であるかを示す前記医療データの状態を受信し、
　受信した前記医療データの状態を示すオブジェクトを表示する
　処理を実行させる請求項１６から１９のいずれか一つに記載のプログラム。