特開 2024-49373 閲覧手続管理システム、閲覧手続管理方法

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】公開特許公報(A)

(11)【公開番号】P2024049373

(43)【公開日】2024-04-09

(54)【発明の名称】閲覧手続管理システム、閲覧手続管理方法

(51)【国際特許分類】

   G16H 10/60 20180101AFI20240402BHJP

【ＦＩ】

G16H10/60

【審査請求】有

【請求項の数】2

【出願形態】ＯＬ

(21)【出願番号】P 2023161785

(22)【出願日】2023-09-25

(62)【分割の表示】P 2023032503の分割

【原出願日】2023-03-03

(31)【優先権主張番号】P 2022154939

(32)【優先日】2022-09-28

(33)【優先権主張国・地域又は機関】JP

(71)【出願人】

【識別番号】519355600

【氏名又は名称】株式会社ＩＤホールディングス

(74)【代理人】

【識別番号】100111970

【弁理士】

【氏名又は名称】三林 大介

(72)【発明者】

【氏名】牧野 剛明

【テーマコード（参考）】

5L099

【Ｆターム（参考）】

5L099AA23

(57)【要約】

【課題】複数の診察機関で作成された診察データの可用性を十分に確保する。
【解決手段】複数の診察ノード２の中の要求ノード２ａが作成ノード２ｂに対して、対象診察データの閲覧を求める要求メッセージを作成して作成ノードに送信する。作成ノードは、要求メッセージと共に受け取った対象患者の署名を認証して、要求ノードに対象診察データの閲覧権限を設定するように依頼する依頼メッセージを作成して認証ノード３に送信する。依頼メッセージには、対象患者および自己の署名をメッセージに含めるか、添付しておく。認証ノードは、依頼メッセージを受け取ると、要求ノードに対象診察データの閲覧権限を設定するブロックデータを生成し、複数の診察ノードに送信してブロックチェーン形式で記憶させる。
【選択図】図３

【特許請求の範囲】

【請求項1】

患者を診察することによって診察データを作成すると共に、複数のブロックデータをブロックチェーン形式で記憶する複数の診察ノードと、前記ブロックデータを生成して前記診察ノードに記憶させる認証ノードとが通信回線で接続されることによって形成され、複数の前記診察ノード間で前記診察データを閲覧する手続を管理する閲覧手続管理システムであって、
前記診察ノードは、
複数のブロックデータをブロックチェーン形式で記憶するブロックデータ記憶部と、
前記診察データを作成すると、前記診察ノードに接続されたデータベースに出力する診察データ出力部と
を備えており、
複数の前記診察ノードの中には、他の前記診察ノードで作成された前記診察データの閲覧を要求する要求ノードと、前記要求ノードから閲覧を要求された前記診察データである対象診察データを作成した作成ノードとが含まれており、
前記要求ノードは、前記作成ノードに対して前記対象診察データの閲覧を要求するメッセージであって、前記対象診察データの診察対象である対象患者の署名が付与された所定の署名用データを含むか、前記対象患者の署名が付与された前記署名用データが添付された前記メッセージである要求メッセージを作成すると、前記要求メッセージを前記作成ノードに送信する要求メッセージ送信部を有しており、
前記作成ノードは、
前記要求メッセージを受け取ると、前記要求メッセージと共に受け取った前記署名用データの前記対象患者の署名を認証する患者署名認証部と、
前記対象患者の署名の認証が成功した場合には、前記対象診察データを特定するための診察データ特定情報と、前記要求ノードを特定するための要求ノード特定情報とを取得する特定情報取得部と、
前記要求ノードが前記対象診察データを閲覧可能となる閲覧権限の設定を依頼するためのメッセージであって、前記診察データ特定情報と、前記要求ノード特定情報とを含むと共に、前記対象患者の署名付きの前記署名用データおよび前記作成ノードの署名付きの前記署名用データを更に含むか、前記対象患者の署名付きの前記署名用データおよび前記作成ノードの署名付きの前記署名用データが添付された前記メッセージである依頼メッセージを作成する依頼メッセージ作成部と、
前記依頼メッセージを前記認証ノードに送信する依頼メッセージ送信部と
を有しており、
前記認証ノードは、
前記依頼メッセージを受け取ると、前記対象患者の署名および前記作成ノードの署名を含み、前記要求ノードに対して前記対象診察データの閲覧権限を設定する前記ブロックデータを生成するブロックデータ生成部と、
生成した前記ブロックデータを複数の前記診察ノードに送信するブロックデータ送信部と
を備えることを特徴とする閲覧手続管理システム。

【請求項2】

患者を診察することによって診察データを作成すると共に複数のブロックデータをブロックチェーン形式で記憶する複数の診察ノードと、前記ブロックデータを生成して前記診察ノードに出力する認証ノードとが通信回線で接続されたネットワーク上で通信することにより、複数の前記診察ノード間で前記診察データを閲覧する手続を管理する閲覧手続管理方法であって、
複数の前記診察ノードの中で、他の前記診察ノードで作成された前記診察データの閲覧を要求する要求ノードが、前記要求ノードから閲覧を要求された前記診察データである対象診察データを作成した作成ノードに対して送信するメッセージであって、前記対象診察データの閲覧を要求すると共に、前記対象診察データの診察対象である対象患者の署名が付与された所定の署名用データを含むか、前記対象患者の署名が付与された前記署名用データが添付された前記メッセージである要求メッセージを作成して、前記作成ノードに送信する工程と、
前記作成ノードが、前記要求メッセージと共に受け取った前記署名用データの前記対象患者の署名を認証する工程と、
前記対象患者の署名の認証が成功した場合には、前記対象診察データを特定するための診察データ特定情報と、前記要求ノードを特定するための要求ノード特定情報とを、前記作成ノードが取得する工程と、
前記対象診察データを前記要求ノードが閲覧可能となる閲覧権限の設定を依頼するためのメッセージであって、前記診察データ特定情報と、前記要求ノード特定情報とを含むと共に、前記対象患者の署名付きの前記署名用データおよび前記作成ノードの署名付きの前記署名用データを更に含むか、前記対象患者の署名付きの前記署名用データおよび前記作成ノードの署名付きの前記署名用データが添付された前記メッセージである依頼メッセージを、前記作成ノードが作成して、前記認証ノードに送信する工程と、
前記認証ノードが前記依頼メッセージを受け取ると、前記認証ノードが、前記対象患者の署名と前記作成ノードの署名とを含み、前記要求ノードに対して前記対象診察データの閲覧権限を設定する前記ブロックデータを生成して、複数の前記診察ノードに送信する工程と
を備えることを特徴とする閲覧手続管理方法。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、患者を診察することによって診察データを作成し、通信回線で接続された複数の診察ノードが、互いの診察データを閲覧する手続を管理する技術に関する。

【背景技術】

【0002】

医師が患者を診察する際には、患者が他の医療機関で受診した時の診察記録（例えば検査画像や検査数値や医師の所見など）を参照する必要が生じることがある。このような場合、患者が以前に受信した医療機関に依頼して、診察記録を提供して貰うことになる。

【0003】

ところが、依頼を受けた医療機関にとっては、依頼に応じて診察記録を提供すれば良いという単純な話ではない。その理由は、次のようなものである。先ず、診察記録は単に検査結果（検査画像や検査数値など）を記載したものではなく、医師の長年の臨床経験や、医学的な知識や、それらを踏まえた医療方針などが反映されて生み出される創作物である。このため、診察記録には医師の著作権が混入している可能性がある。加えて、診察記録は患者にとっては極めて敏感な個人情報となり得るため、取扱いによっては患者のプライバシー権を侵害する虞がある。これらの事情から、依頼に応じてむやみに診察記録を提供すると、予期せぬ訴訟に巻き込まれる虞が生じるためである。実際に医療の現場では、複数の医療機関で診察記録を積極的に相互利用しようとしても、上述した事情が障害となっている旨が報告されている（非特許文献１）。

【0004】

これに対して、複数の医療機関で作成された診察記録を診察記録データベースに記憶すると共に、診察記録を参照するための記録識別情報をブロックチェーンデータベースに記憶し、更に、登録情報データベースに、患者を識別する患者識別情報に対応付けて記録識別情報を記憶しておくことで、保険会社などの第三者機関が患者の診察記録を長期に亘って参照できるようにした技術が提案されている（特許文献１）。

【0005】

あるいは、患者の処方箋データをブロックチェーンデータベースに記憶しておき、医者が処方箋を発行する場合や、薬剤師が処方箋を参照する場合は、患者が端末を操作することによって、医者または薬剤師に対してブロックチェーンデータベース上での処方箋データへのアクセス権限を付与し、処方箋の会計処理が終わったら、医者または薬剤師のアクセス権限を剥奪するようにした技術が提案されている（特許文献２）。

【先行技術文献】

【特許文献】

【0006】

【特許文献1】特許第６８０１９２２号公報

【特許文献2】特許第６９３６７６３号公報

【非特許文献1】前田まゆみ、「診療録の法的考察―判例からの分析―」、医学教育、２００５年６月、第３６巻、第３号、ｐ．１５３－１５７

【発明の概要】

【発明が解決しようとする課題】

【0007】

しかし、上述した従来の技術では、複数の医療機関に保存されている診察記録の可用性を十分に担保することができないという問題があった。例えば、上述した特許文献１に記載の技術では、保険会社などが過去の診察記録を容易に入手可能であるものの、診察記録を入手あるいは提供する行為が、患者や診察記録を作成した医師の同意に基づく行為であることを立証することができない。このため、診察記録を入手あるいは提供したことで予期せぬ訴訟に巻き込まれる虞がある。また、上述した特許文献２に記載の技術では、処方箋に基づいて調剤する際に、患者の同意に基づいて処方箋の提供を受けたことを立証可能であるものの、診察記録の提供を受ける際に、医師や患者の同意に基づいて提供を受けたことは立証することができない。このため、処方箋や診察記録を入手あるいは提供したことで予期せぬ訴訟に巻き込まれる虞がある。

【0008】

この発明は、従来の技術が有する上述した課題を解決するために成されたものであり、医療機関に保存されている診察記録を入手あるいは提供する際に、該当する患者および医師の同意が得られていることを後日に容易に立証可能でありながら、簡単な手続で診察記録を入手あるいは提供可能とすることで、診察記録の可用性を十分に担保することが可能な診察記録管理システムを実現することを目的とする。

【課題を解決するための手段】

【0009】

上述した課題を解決するために、本発明の閲覧手続管理システムは、次の構成を採用した。すなわち、
患者を診察することによって診察データを作成すると共に、複数のブロックデータをブロックチェーン形式で記憶する複数の診察ノードと、前記ブロックデータを生成して前記診察ノードに記憶させる認証ノードとが通信回線で接続されることによって形成され、複数の前記診察ノード間で前記診察データを閲覧する手続を管理する閲覧手続管理システムであって、
前記診察ノードは、
複数のブロックデータをブロックチェーン形式で記憶するブロックデータ記憶部と、
前記診察データを作成すると、前記診察ノードに接続されたデータベースに出力する診察データ出力部と
を備えており、
複数の前記診察ノードの中には、他の前記診察ノードで作成された前記診察データの閲覧を要求する要求ノードと、前記要求ノードから閲覧を要求された前記診察データである対象診察データを作成した作成ノードとが含まれており、
前記要求ノードは、前記作成ノードに対して前記対象診察データの閲覧を要求するメッセージであって、前記対象診察データの診察対象である対象患者の署名が付与された所定の署名用データを含むか、前記対象患者の署名が付与された前記署名用データが添付された前記メッセージである要求メッセージを作成すると、前記要求メッセージを前記作成ノードに送信する要求メッセージ送信部を有しており、
前記作成ノードは、
前記要求メッセージを受け取ると、前記要求メッセージと共に受け取った前記署名用データの前記対象患者の署名を認証する患者署名認証部と、
前記対象患者の署名の認証が成功した場合には、前記対象診察データを特定するための診察データ特定情報と、前記要求ノードを特定するための要求ノード特定情報とを取得する特定情報取得部と、
前記要求ノードが前記対象診察データを閲覧可能となる閲覧権限の設定を依頼するためのメッセージであって、前記診察データ特定情報と、前記要求ノード特定情報とを含むと共に、前記対象患者の署名付きの前記署名用データおよび前記作成ノードの署名付きの前記署名用データを更に含むか、前記対象患者の署名付きの前記署名用データおよび前記作成ノードの署名付きの前記署名用データが添付された前記メッセージである依頼メッセージを作成する依頼メッセージ作成部と、
前記依頼メッセージを前記認証ノードに送信する依頼メッセージ送信部と
を有しており、
前記認証ノードは、
前記依頼メッセージを受け取ると、前記対象患者の署名および前記作成ノードの署名を含み、前記要求ノードに対して前記対象診察データの閲覧権限を設定する前記ブロックデータを生成するブロックデータ生成部と、
生成した前記ブロックデータを複数の前記診察ノードに送信するブロックデータ送信部と
を備えることを特徴とする。

【0010】

また、上述した本発明の閲覧手続管理システムに対応する本発明の閲覧手続管理方法は、次の構成を採用した。すなわち、
患者を診察することによって診察データを作成すると共に複数のブロックデータをブロックチェーン形式で記憶する複数の診察ノードと、前記ブロックデータを生成して前記診察ノードに出力する認証ノードとが通信回線で接続されたネットワーク上で通信することにより、複数の前記診察ノード間で前記診察データを閲覧する手続を管理する閲覧手続管理方法であって、
複数の前記診察ノードの中で、他の前記診察ノードで作成された前記診察データの閲覧を要求する要求ノードが、前記要求ノードから閲覧を要求された前記診察データである対象診察データを作成した作成ノードに対して送信するメッセージであって、前記対象診察データの閲覧を要求すると共に、前記対象診察データの診察対象である対象患者の署名が付与された所定の署名用データを含むか、前記対象患者の署名が付与された前記署名用データが添付された前記メッセージである要求メッセージを作成して、前記作成ノードに送信する工程と、
前記作成ノードが、前記要求メッセージと共に受け取った前記署名用データの前記対象患者の署名を認証する工程と、
前記対象患者の署名の認証が成功した場合には、前記対象診察データを特定するための診察データ特定情報と、前記要求ノードを特定するための要求ノード特定情報とを、前記作成ノードが取得する工程と、
前記対象診察データを前記要求ノードが閲覧可能となる閲覧権限の設定を依頼するためのメッセージであって、前記診察データ特定情報と、前記要求ノード特定情報とを含むと共に、前記対象患者の署名付きの前記署名用データおよび前記作成ノードの署名付きの前記署名用データを更に含むか、前記対象患者の署名付きの前記署名用データおよび前記作成ノードの署名付きの前記署名用データが添付された前記メッセージである依頼メッセージを、前記作成ノードが作成して、前記認証ノードに送信する工程と、
前記認証ノードが前記依頼メッセージを受け取ると、前記認証ノードが、前記対象患者の署名と前記作成ノードの署名とを含み、前記要求ノードに対して前記対象診察データの閲覧権限を設定する前記ブロックデータを生成して、複数の前記診察ノードに送信する工程と
を備えることを特徴とする。

【0011】

このような本発明の閲覧手続管理システムおよび閲覧手続管理方法では、要求ノードが他の診察ノードで作成された診察データの閲覧を要求する場合には、作成ノードに対して診察データ（対象診察データ）の閲覧を求める要求メッセージを作成して、作成ノードに送信する。作成ノードは、要求メッセージと共に送られてくる対象患者の署名に基づいて、対象患者の同意が得られていることを確認すると、要求ノードに対して対象診察データの閲覧権限を設定するように依頼する依頼メッセージを作成して、認証ノードに送信する。認証ノードは、依頼メッセージを受け取ると、要求ノードに対して対象診察データの閲覧権限を設定するブロックデータを生成して、要求ノードを含む複数の診察ノードに送信する。複数の診察ノードでは、認証ノードから送信されてきたブロックデータがブロックチェーン形式で記憶される。

【0012】

こうすれば、複数の診察ノードに記憶されているブロックデータを調べれば、要求ノードに対する対象診察データの閲覧権限が、対象患者および作成ノードの同意に基づいて設定されたことを容易に確認することができる。このため要求ノードにとっては、対象患者および作成ノードの同意を得た上で対象診察データを閲覧したことを、後日になっても容易に立証することができる。また、作成ノードにとっては、対象患者の同意に基づいて、要求ノードに対象診察データを閲覧させたことを、後日になっても容易に立証することができる。その結果、他の診察ノードで作成された診察データを閲覧したり、他の診察ノードに診察データを閲覧させたりした場合でも、予期せぬ訴訟に巻き込まれる虞がないので、診察ノードの可用性を十分に確保することが可能となる。

【図面の簡単な説明】

【0013】

【図1】本実施例の閲覧手続管理システム１の概要を示す説明図である。

【図2】診察ノード２や認証ノード３にブロックチェーン形式で記憶されている複数のブロックデータ１０を例示した説明図である。

【図3】閲覧手続管理システム１の診察ノード２や認証ノード３にブロックデータ１０が記憶される様子を概念的に示した説明図である。

【図4】診察ノード２の内部構造を示したブロック図である。

【図5】認証ノード３の内部構造を示したブロック図である。

【図6】患者が閲覧手続管理システム１に登録する際に患者端末６および認証ノード３で実行される処理についての説明図である。

【図7】診察ノード２が診察データを閲覧手続管理システム１に登録する際に診察ノード２および認証ノード３で実行される処理についての説明図である。

【図8】診察データの登録するための登録メッセージに含まれる複数の情報を示した説明図である。

【図9】診察データを登録するために認証ノード３によって作成されるブロックデータ１０を示した説明図である。

【図10】要求ノード２ａが作成ノード２ｂに対して診察データの閲覧を要求する際に患者端末６および要求ノード２ａで実行される処理についての説明図である。

【図11】要求ノード２ａが作成ノード２ｂに対して診察データの閲覧を要求する際に要求ノード２ａおよび作成ノード２ｂで実行される処理についての説明図である。

【図12】要求ノード２ａが作成ノード２ｂに対して診察データの閲覧を要求する際に作成ノード２ｂおよび認証ノード３で実行される処理についての説明図である。

【図13】患者端末６が署名する承諾メッセージの文面を例示した説明図である。

【図14】要求ノード２ａが作成する要求メッセージに含まれる複数の情報を示した説明図である。

【図15】作成ノード２ｂが作成する依頼メッセージに含まれる複数の情報を示した説明図である。

【図16】認証ノード３によって作成される閲覧許諾のブロックデータ１０を示した説明図である。

【図17】第１変形例の要求メッセージを例示した説明図である。

【図18】第１変形例の依頼メッセージを例示した説明図である。

【図19】要求メッセージに対象患者および要求ノード２ａの署名が添付される第２変形例についての説明図である。

【図20】依頼メッセージに対象患者および作成ノード２ｂの署名が添付される第２変形例についての説明図である。

【発明を実施するための形態】

【0014】

Ａ．閲覧手続管理システム１の概要 ：
図１は、本実施例の閲覧手続管理システム１の概要を示す説明図である。本実施例の閲覧手続管理システム１は、患者を診察することによって診察データを作成する複数の診察ノード２や、認証ノード３が、インターネットなどの通信回線５を介して接続されることによって形成されている。ここで、診察データとは、医師が患者を診察することによって作成された診療録をデータ化したものであり、診療録には検査画像や検査数値や医師のメモなども含まれる。また、後述するように診察ノード２は、複数のブロックデータをブロックチェーン形式で記憶することが可能となっており、認証ノード３が後述する方法で新たなブロックデータを生成して、通信回線５を介して診察ノード２に送信すると、診察ノード２に新たなブロックデータが追加されるようになっている。

【0015】

それぞれの診察ノード２には専用のデータサーバ４が接続されており、診察ノード２は診察データを作成するとデータサーバ４に診察データを記憶しておき、必要に応じてデータサーバ４から診察データを読み出して閲覧することができる。また、他の診察ノード２で作成された診察データを閲覧する必要が生じた場合は、その診察データを作成した診察ノード２に対して、閲覧を要求するメッセージを送信することで、必要とする診察データを閲覧することが可能となる。尚、以下では、他の診察ノード２で作成された診察データの閲覧を要求する診察ノード２を「要求ノード２ａ」と称し、要求ノード２ａが閲覧を要求する対象の診察データを「対象診察データ」と称し、その対象診察データを作成した診察ノード２を「作成ノード２ｂ」と称するものとする。

【0016】

また、本実施例では、診察ノード２毎に専用のデータサーバ４が接続されているものとして説明するが、これに限らず、例えば複数の診察ノード２を共用のデータサーバ４に接続して、それら診察ノード２が診察データを作成すると共用のデータサーバ４に記憶するようにしても良い。あるいは、全ての診察ノード２を中央のデータサーバ４に接続して、全ての診察ノード２で作成された診察データは中央のデータサーバ４に記憶されるようにしても良い。尚、本実施例のデータサーバ４は、本発明における「データベース」に対応する。

【0017】

更に、通信回線５には複数の認証ノード３も接続されている。複数の認証ノード３は通信回線５を介して診察ノード２と通信可能となっており、診察ノード２が診察データを作成したり、要求ノード２ａの要求に応じて作成ノード２ｂが診察データの閲覧を許諾する度にブロックデータを作成する。そして、複数の認証ノード３で作成されたブロックデータは、複数の認証ノード３の合意によって確定されて、全ての診察ノード２に一斉に送信される。その結果、全ての診察ノード２には、複数のブロックデータがブロックチェーン形式で蓄積されるようになっている。また、ブロックデータは、複数の認証ノード３にもブロックチェーン形式で蓄積される。

【0018】

尚、本実施例では、認証ノード３は患者を診察しないので診察データも作成しないとしているため、図１に示した例では、認証ノード３にはデータサーバ４が接続されていない。しかし、認証ノード３でも患者を診察して診察データを作成しても良い。この場合は、認証ノード３にもデータサーバ４が接続されており、認証ノード３で作成された診察データはデータサーバ４に記憶される。

【0019】

また、診察ノード２で診察を受ける患者は、スマートフォンなどの患者端末６に専用のアプリケーションをインストールすることで、患者端末６から通信回線５を介して閲覧手続管理システム１に接続することが可能となる。あるいは患者端末６のＷｅｂブラウザを用いて、閲覧手続管理システム１に接続しても良い。

【0020】

図２は、診察ノード２や認証ノード３にブロックチェーン形式で記憶されている複数のブロックデータ１０を例示した説明図である。図２に示した例では、５つのブロックデータ１０ａ～１０ｅがブロックチェーン形式で記憶されている状態が概念的に示されている。図示されるように、ブロックデータ１０はデータ形式が同一のデータ（すなわち、同じ種類のデータ）である必要はなく、図２に示した例では３種類のブロックデータ１０が記憶されている。すなわち、３つのブロックデータ１０ａ，１０ｂ，１０ｄは、互いに同じデータ形式を有する同じ種類のデータであるが、ブロックデータ１０ｃやブロックデータ１０ｅは、他のブロックデータとは異なる種類のデータとなっている。

【0021】

また、これらのブロックデータ１０ａ～１０ｄは、ブロックチェーン形式で記憶されている。ここで、ブロックチェーン形式とは次のような形式である。例えば、図２中のブロックデータ１０ｂに着目すると、ブロックデータ１０ｂの中には前のブロックデータ１０ａのハッシュ値が含まれている。周知のように、ハッシュ値とは、任意のデータに対してハッシュ関数と呼ばれる特別な操作を行うことによって得られる値である。また、ハッシュ関数は、どのようなサイズのデータであっても同じデータ長のハッシュ値に変換し、変換前のデータの一部でも異なれば変換したハッシュ値は全く異なる値となり、更に、ハッシュ値からは変換前のデータに戻すことが不可能であるという性質を有している。従って、ハッシュ値と元のデータとの間には一対一の関係が成立しており、ハッシュ値は変換前のデータを一意的に代表すると考えて良い。

【0022】

図２のブロックデータ１０ｂの中には、前のブロックデータ１０ａのハッシュ値が含まれており、ブロックデータ１０ｂのハッシュ値は、後ろのブロックデータ１０ｃの中に含まれている。そのブロックデータ１０ｃのハッシュ値は、その後ろのブロックデータ１０ｄの中に含まれており、ブロックデータ１０ｄのハッシュ値は、更に後のブロックデータ１０ｅの中に含まれている。その結果、５つのブロックデータ１０ａ～１０ｅは、鎖のように一つずつ繋がった状態となっている。このような状態が、ブロックチェーン形式と呼ばれる状態である。診察ノード２や認証ノード３には、このようなブロックチェーン形式で複数のブロックデータ１０が記憶されている。尚、本実施例では、複数のブロックデータが、前のブロックデータのハッシュ値を用いて繋がっているものとしているが、これは、前のブロックデータのハッシュ値が、前のブロックデータを一意的に代表するという特性を有するためである。従って、前のブロックデータのハッシュ値の代わりに、前のブロックデータを特定する情報（例えば、前のブロックデータのＵＲＬ（Ｕniform Ｒesouce Ｌocation ）やＵＲＮ（Ｕniform Ｒesouce Ｎame ）など）を用いて、複数のブロックデータを繋げるようにしても良い。また、これらのブロックデータ１０は、次のようにして診察ノード２や認証ノード３に記憶される。

【0023】

図３は、閲覧手続管理システム１の診察ノード２や認証ノード３にブロックデータ１０が記憶される様子を概念的に示した説明図である。例えば、本実施例の診察ノード２は、患者を診察して診察データを作成すると、その診察データをデータサーバ４に記憶すると共に、診察データを登録するように要請するメッセージ（以下、登録メッセージ）を閲覧手続管理システム１に送信する。すると、その登録メッセージが閲覧手続管理システム１の複数の認証ノード３によって認証されて、認証を通った場合は、複数の認証ノード３の合意によって、診察データを登録するためのブロックデータ１０が作成される。そして、そのブロックデータ１０が認証ノード３から複数の診察ノード２に送信されて、診察ノード２および認証ノード３に記憶される。図２中のブロックデータ１０ａやブロックデータ１０ｂ、ブロックデータ１０ｄは、このようにして記憶されたブロックデータ１０である。尚、このようなブロックデータ１０が作成される詳細な動作については後述する。

【0024】

また、ブロックデータ１０の記憶後に、別の診察ノード２から閲覧手続管理システム１に診察データの登録メッセージが送信されてきた場合には、その前に記憶したブロックデータ１０に続けて新たなブロックデータ１０がブロックチェーン形式で記憶される。図３に示した例では、４つの診察ノード２から送信された診察データの登録メッセージに対応して、４つのブロックデータ１０がブロックチェーン形式で記憶される。

【0025】

患者が、患者端末６から閲覧手続管理システム１に対して登録を申請するメッセージ（以下、登録申請メッセージ）を送信した場合には、その登録申請メッセージが閲覧手続管理システム１の認証ノード３によって認証される。そして、認証を通った場合は、患者を登録するためのブロックデータ１０が診察ノード２および認証ノード３に記憶される。図２中のブロックデータ１０ｅは、このようにして記憶されたブロックデータ１０である。このようなブロックデータ１０が作成される詳細な手続きについても後述する。

【0026】

また、要求ノード２ａが作成ノード２ｂに対して診察データの閲覧を要求するメッセージ（以下、要求メッセージ）を送信すると、それに対して作成ノード２ｂが閲覧権限の設定を依頼するメッセージ（以下、依頼メッセージ）を閲覧手続管理システム１に送信する。すると、その依頼メッセージが閲覧手続管理システム１の複数の認証ノード３によって認証されて、認証を通った場合は、複数の認証ノード３の合意によって、要求ノード２ａに閲覧権限を設定するブロックデータ１０が作成されて、診察ノード２および認証ノード３に記憶される。図２中のブロックデータ１０ｃは、このようにして記憶されたブロックデータ１０である。以下では、図２中のブロックデータ１０ｃのように、要求ノード２ａに閲覧権限を設定するブロックデータ１０を、特に「閲覧許諾のブロックデータ１０」と称することがある。尚、図２のブロックデータ１０ｃ中に、「患者と作成ノードによる基準値の二重署名」とあるのは、患者が基準値に署名したものに重ねて作成ノード２ｂが署名したものを指している。また、閲覧許諾のブロックデータ１０が作成される詳細な手続きについても後述する。

【0027】

このように、本実施例の閲覧手続管理システム１では、診察ノード２や、要求ノード２ａや、作成ノード２ｂなどが、閲覧手続管理システム１に対して（あるいは閲覧手続管理システム１を介して）メッセージを送信すると、そのメッセージが認証ノード３によって認証されて、診察ノード２および認証ノード３にブロックデータ１０がブロックチェーン形式で記憶されていく。特に、要求ノード２ａの要求に応じて、作成ノード２ｂが認証ノード３に送信する依頼メッセージには、診察データの対象である患者（以下、対象患者）および作成ノード２ｂによる二重署名が含まれており、依頼メッセージを受信した認証ノード３は二重署名を認証して、認証できた場合に、閲覧許諾のブロックデータ１０（図２中のブロックデータ１０ｃを参照）を作成する。従って、対象患者および作成ノード２ｂの二重署名を認証できなかった場合には、閲覧許諾のブロックデータ１０が作成されることはなく、診察ノード２や認証ノード３に閲覧許諾のブロックデータ１０が記憶されることも無い。尚、対象患者および作成ノード２ｂの二重署名の代わりに、対象患者の署名および作成ノード２ｂの署名を依頼メッセージに含めておき、依頼メッセージを受け取った認証ノード３は、対象患者の署名および作成ノード２ｂの署名を認証しても良い。

【0028】

このことから、要求ノード２ａは、閲覧許諾のブロックデータ１０を確認した上で対象診察データを閲覧している限り、対象患者や作成ノード２ｂの同意を得た上で対象診察データを閲覧したことを、後日になっても容易に立証することができる。加えて、ブロックデータ１０はブロックチェーン形式で記憶されているため、後からブロックデータ１０の内容を改竄することは困難である。更に、ブロックデータ１０は複数の診察ノード２および認証ノード３に重複して記憶されているため、たとえ仮に、ある診察ノード２のブロックデータ１０を改竄できたとしても、他の複数の診察ノード２および認証ノード３のブロックデータ１０と照合することで、改竄されていることが分かってしまう。従って、閲覧許諾のブロックデータ１０が改竄されていないことも容易に立証することができる。その結果、要求ノード２ａは、閲覧手続管理システム１を介して作成ノード２ｂに診察データの閲覧を要求しておけば、その診察データを閲覧したことで、予期せぬ訴訟に巻き込まれる虞を回避することができる。

【0029】

また、作成ノード２ｂにとっても、閲覧手続管理システム１を介して要求ノード２ａに診察データの閲覧を許諾しておけば、予期せぬ訴訟に巻き込まれる虞を回避することができる。すなわち、閲覧許諾のブロックデータ１０には対象患者の署名が含まれているため、作成ノード２ｂが対象患者の署名の無いまま、要求ノード２ａに対して閲覧を許諾しようとして閲覧手続管理システム１にメッセージを送信しても、認証ノード３の認証が通らないため、閲覧許諾のブロックデータ１０が作成されることがない。その結果、作成ノード２ｂは、閲覧手続管理システム１を介して要求ノード２ａに対象診察データの閲覧を許諾しておけば、患者の同意のないまま勝手に診察データの閲覧を許諾してしまい、予期せぬ訴訟に巻き込まれる虞を回避することができる。

【0030】

そして、このような大きな利点が得られるにも拘らず、要求ノード２ａや作成ノード２ｂにとっては、診察データの閲覧を要求したり、要求に応じて閲覧を許諾したりする連絡を、閲覧手続管理システム１を介して行っているに過ぎない。このため、要求ノード２ａや作成ノード２ｂに大きな負担をかけることなく、診察データの可用性を担保することが可能となる。以下では、こうしたことを実現する閲覧手続管理システム１の詳細について説明する。

【0031】

Ｂ．診察ノード２および認証ノード３の内部構造 ：
図４は、本実施例の閲覧手続管理システム１を形成する診察ノード２の内部構造を示したブロック図である。図示されるように、診察ノード２の内部には、診察データ作成部２０や、診察データ出力部２１、メッセージ受信部２２、署名認証部２３、メッセージ作成部２４、特定情報取得部２５、メッセージ送信部２６、ブロックデータ受信部２７、ブロックデータ記憶部２８などが搭載されている。尚、これらの「部」は、診察ノード２に搭載されている機能を表す抽象的な概念であり、これらの「部」に対応する部品が存在することを示しているわけではない。これらの「部」は、診察ノード２に内蔵されたマイクロコンピュータで実行されるソフトウェアプログラムとして実現することもできるし、診察ノード２に搭載されたＬＳＩやＩＣなどによるハードウェアとして実現することもできる。更には、ソフトウェアプログラムとハードウェアとを組み合わせることによって実現しても良い。

【0032】

診察データ作成部２０は、患者を診察した診療録を読み込んでデータ化することによって診察データを作成し、作成した診察データを診察データ出力部２１に出力する。診察データ出力部２１はデータサーバ４に接続されており、診察データ作成部２０から受け取った診察データをデータサーバ４に記憶する。

【0033】

メッセージ受信部２２は、インターネットなどの通信回線５に接続されており、通信回線５を介して送信されてきたメッセージを受信すると、そのメッセージを署名認証部２３および特定情報取得部２５に出力する。詳細には後述するが、メッセージ受信部２２が受信するメッセージには、要求ノード２ａから送信された診察データの閲覧を要求するための要求メッセージなどが含まれる。

【0034】

署名認証部２３は、受け取ったメッセージに署名が含まれていた場合には、その署名を認証する。尚、メッセージに患者の署名が含まれている場合は、その署名を署名認証部２３が認証するから、本実施例の署名認証部２３は本発明における「患者署名認証部」に対応する。そして、認証が通った場合は、認証の結果をメッセージ作成部２４および特定情報取得部２５に出力する。

【0035】

メッセージ作成部２４は、認証が通った旨の結果を受け取ると、受け取っていたメッセージに対応するメッセージを作成する。例えば、要求ノード２ａからの要求メッセージを受け取っていた場合には、閲覧許諾のブロックデータ１０の作成を依頼する依頼メッセージを作成する。また、作成ノード２ｂに対して診察データの閲覧を要求する場合には、要求メッセージを作成する。これらのメッセージを作成するためには所定の情報（以下、特定情報）が必要となるが、これらの特定情報は特定情報取得部２５から供給される。すなわち、特定情報取得部２５は、署名認証部２３での認証が通った旨の通知を受け取ると、メッセージ受信部２２から受け取っていたメッセージの中から特定情報を抽出して、メッセージ作成部２４に出力するようになっている。尚、診察ノード２が作成ノード２ｂである場合は、メッセージ作成部２４が依頼メッセージを作成するから、本実施例のメッセージ作成部２４は本発明における「依頼メッセージ作成部」に対応する。

【0036】

メッセージ作成部２４は、こうして作成したメッセージをメッセージ送信部２６に出力する。メッセージ送信部２６は通信回線５に接続されており、通信回線５に接続された診察ノード２や認証ノード３に向かってメッセージを送信する。尚、診察ノード２が要求ノード２ａである場合は、メッセージ送信部２６が要求メッセージを送信し、診察ノード２が作成ノード２ｂである場合は、メッセージ送信部２６が依頼メッセージを送信するから、本実施例のメッセージ作成部２４は本発明における「要求メッセージ送信部」および「依頼メッセージ送信部」に対応する。

【0037】

また、ブロックデータ受信部２７も通信回線５に接続されており、認証ノード３から送信されてきた新たなブロックデータ１０を受信すると、そのブロックデータ１０をブロックデータ記憶部２８に出力する。ブロックデータ記憶部２８は、ブロックデータ受信部２７から新たなブロックデータ１０を受け取ると、図２を用いて前述したブロックチェーン形式で記憶する。

【0038】

また、図５は、本実施例の閲覧手続管理システム１を形成する認証ノード３の内部構造を示したブロック図である。図示されるように、認証ノード３の内部には、メッセージ受信部３０や、署名認証部３１、ブロックデータ作成部３２、特定情報取得部３３、ブロックデータ送信部３４、ブロックデータ記憶部３５などが搭載されている。尚、これらの「部」も、認証ノード３に搭載されている機能を表す抽象的な概念であり、これらの「部」に対応する部品が存在することを示しているわけではない。これらの「部」は、認証ノード３に内蔵されたマイクロコンピュータで実行されるソフトウェアプログラムとして実現することもできるし、診察ノード２に搭載されたＬＳＩやＩＣなどによるハードウェアとして実現することもできる。更には、ソフトウェアプログラムとハードウェアとを組み合わせることによって実現しても良い。

【0039】

認証ノード３のメッセージ受信部３０は、インターネットなどの通信回線５に接続されており、通信回線５を介して送信されてきたメッセージを受信すると、そのメッセージを署名認証部３１および特定情報取得部３３に出力する。詳細には後述するが、認証ノード３のメッセージ受信部３０には、患者端末６からの登録申請メッセージや、診察ノード２からの登録メッセージや依頼メッセージなど送信されてくる。

【0040】

認証ノード３の署名認証部３１は、メッセージ受信部３０から受け取ったメッセージに署名が含まれていた場合には、その署名を認証する。尚、詳細には後述するが、受け取ったメッセージが作成ノード２ｂからの依頼メッセージであった場合には、その作成ノード２ｂの署名が含まれているので、作成ノード２ｂの署名を認証することになる。従って、本実施例の署名認証部３１は本発明における「作成ノード署名認証部」に対応する。そして、認証が通った場合は、認証の結果をブロックデータ作成部３２および特定情報取得部３３に出力する。また、メッセージ受信部３０から受け取ったメッセージが患者端末６からの登録申請メッセージであった場合には、そのメッセージに含まれている患者の署名を認証することになる。

【0041】

ブロックデータ作成部３２は、メッセージに含まれる署名の認証が通った旨の結果を受け取ると、メッセージに対応するブロックデータ１０を作成する。ブロックデータ１０を作成するためには所定の特定情報が必要となるが、これらの特定情報は特定情報取得部３３から供給される。すなわち、特定情報取得部３３は、署名認証部３１での認証が通った旨の通知を受け取ると、メッセージ受信部３０から受け取っていたメッセージの中から特定情報を抽出して、ブロックデータ作成部３２に出力するようになっている。ブロックデータ作成部３２は、こうして受け取った特定情報に基づいてブロックデータ１０を作成する。また、閲覧手続管理システム１には複数の認証ノード３が存在するが（図１参照）、それぞれの認証ノード３のブロックデータ作成部３２でブロックデータ１０が作成される。そこで、それぞれの認証ノード３のブロックデータ作成部３２は、作成したブロックデータ１０の内容を互いに照合し、齟齬が生じている内容については多数決による合意によって内容を決定してブロックデータ１０を確定させる。

【0042】

ブロックデータ作成部３２は、こうして確定させたブロックデータ１０をブロックデータ送信部３４およびブロックデータ記憶部３５に出力する。ブロックデータ送信部３４は通信回線５に接続されており、通信回線５に接続された複数の診察ノード２に向かってブロックデータ１０を送信する。こうして送信されたブロックデータ１０は、図４を用いて前述した診察ノード２のブロックデータ受信部２７で受診されて、ブロックデータ記憶部２８にブロックチェーン形式で記憶される。

【0043】

本実施例の閲覧手続管理システム１は、上述した内部構造を有する複数の診察ノード２および認証ノード３が通信回線５で接続されており、診察ノード２および認証ノード３が以下のように動作することによって実現されている。

【0044】

Ｃ．患者端末６の登録動作 ：
本実施例の閲覧手続管理システム１では、診察ノード２で診察を受ける患者が、閲覧手続管理システム１に対して自らをあらかじめ登録しておく必要がある。閲覧手続管理システム１に患者を登録する際には、患者の患者端末６および認証ノード３で次のような処理が実行される。

【0045】

図６は、診察ノード２で診察を受ける患者が閲覧手続管理システム１に登録する際に、患者端末６および認証ノード３で実行される処理を示した説明図である。図示されるように、閲覧手続管理システム１に患者を登録する際には、患者端末６では登録申請処理が実行され、認証ノード３では登録受付処理が実行される。患者端末６の登録申請処理では、先ず始めに患者端末６に専用のアプリケーション（以下、専用アプリ）をインストールする（ＳＴＥＰ１０）。続いて、インストールした専用アプリを起動させて、秘密鍵および公開鍵を作成する（ＳＴＥＰ１１）。患者が自分専用の秘密鍵を作成すると、秘密鍵と対になる公開鍵を専用アプリが自動的に生成する。尚、本実施例では、患者端末６に専用アプリをインストールしておき、専用プリを用いて秘密鍵および公開鍵を作成するものとして説明するが、これに限らず、例えば、患者端末６の閲覧用アプリ（Ｗｅｂブラウザなど）上で動作する拡張アプリケーションを用いて秘密鍵および公開鍵を作成しても良い。

【0046】

その後、患者が専用アプリを用いて、閲覧手続管理システム１への登録を申請する旨の意思表示のメッセージ（登録申請メッセージ）を作成すると（ＳＴＥＰ１２）、専用アプリが秘密鍵を用いて登録申請メッセージに署名した後、公開鍵と一緒に、閲覧手続管理システム１に対して送信する（ＳＴＥＰ１３）。すると、このメッセージは閲覧手続管理システム１の認証ノード３によって受診される。

【0047】

認証ノード３では、以下のような登録受付処理が行われる。先ず、患者端末６から送信されてきた登録申請メッセージを受信する（ＳＴＥＰ２０）。続いて、登録申請メッセージの署名を認証する（ＳＴＥＰ２１）。すなわち、患者端末６から送信されてきた登録申請メッセージは公開鍵と一緒に送信されており、登録申請メッセージは患者の秘密鍵によって署名されている。そこで、署名されたメッセージを公開鍵で復号することによって、登録申請メッセージが正しく復号できた場合、そのメッセージは、同時に送られてきた公開鍵と対になる秘密鍵を有する人（ここでは、患者）によって署名されたことになる。しかも、メッセージの内容は、閲覧手続管理システム１への登録を申請する旨の意思を表示する内容となっている。従って、認証が通っていれば、確かに患者が閲覧手続管理システム１への登録を申請していると考えて良い。

【0048】

そこで、認証が通った場合は（ＳＴＥＰ２２：ｙｅｓ）、閲覧手続管理システム１上での患者のアドレス（以下、患者アドレス）を設定して、そのアドレスを患者端末６に返信する（ＳＴＥＰ２３）。患者端末６では、こうして返信されてきた患者アドレスを受け取ると、患者端末６内に記憶した後（ＳＴＥＰ１４）、登録申請処理を終了する。

【0049】

また、認証ノード３では、患者アドレスを患者端末６に返信した後は（ＳＴＥＰ２３）、患者アドレスを登録するためのブロックデータ１０を作成して、他の認証ノード３との合意の元で、そのブロックデータ１０を全ての診察ノード２に送信した後（ＳＴＥＰ２４）、登録受付処理を終了する。尚、ＳＴＥＰ２４でブロックデータ１０を送信する際に、認証ノード３自身もそのブロックデータ１０を記憶しておく。その結果、診察ノード２（および認証ノード３）内には、患者アドレスを登録するブロックデータ１０がブロックチェーン形式で記憶される。図２中のブロックデータ１０（ｅ）は、このようにして記憶されたものである。これに対して、認証が通らなかった場合は（ＳＴＥＰ２２：ｎｏ）、患者端末６に向かってエラーメッセージを送信して（ＳＴＥＰ２５）、登録受付処理を終了する。

【0050】

尚、上述した説明では、患者端末６側で作成した登録申請メッセージに署名して、認証ノード３に送信するものとした。しかし、患者端末６からは署名を付けずに登録申請メッセージを送信してもよい。そして、そのメッセージを受け取った認証ノード３は、署名用のチャレンジコードなどを患者端末６に返信して、そのチャレンジコードに署名して患者端末６から認証ノード３に返信するようにしてもよい。

【0051】

また、上述した説明では、患者端末６の専用アプリを起動させる際には、認証は不要としているが、例えばパスワードを用いた認証や生体認証が通らなければ、専用アプリが起動しないようにしても良い。こうすれば、第三者が勝手に登録を申請したり、登録した公開鍵を変更したりする事態を回避することができる。

【0052】

Ｄ．診察データの登録動作 ：
図７は、患者を診察した診察ノード２が診察データを閲覧手続管理システム１に登録する際に、診察ノード２および認証ノード３で実行される処理を示した説明図である。図示されるように、閲覧手続管理システム１に診察データを登録する際には、診察ノード２では診察データ送信処理が実行され、認証ノード３では診察データ登録処理が実行される。診察データ送信処理では、先ず始めに診療録をデータ化することによって診察データを作成して、その診察データをデータサーバ４に記憶する（ＳＴＥＰ３０）。続いて、記憶した診察データを特定するための情報（以下、診察データ特定情報）を取得する（ＳＴＥＰ３１）。診察データ特定情報とは、後日にデータサーバ４から診察データを読み出す際に、診察データを特定するための情報である。診察データ特定情報としては、診察データを保存した場所を示すＵＲＬ（Ｕniform Ｒesouce Ｌocation ）や、診察データに固有の名称であるＵＲＮ（Ｕniform Ｒesouce Ｎame ）などを用いることができる。

【0053】

診察データ特定情報を取得したら、その情報のハッシュ値を算出する（ＳＴＥＰ３２）。前述したようにハッシュ値とは、任意のデータにハッシュ関数を作用させることによって得られる値であり、ハッシュ値と元のデータとの間には一対一の関係がある。ハッシュ値が得られたら、そのハッシュ値に対して、診察ノード２の秘密鍵を用いて署名する（ＳＴＥＰ３３）。診察ノード２は閲覧手続管理システム１に登録する際に、秘密鍵および公開鍵を生成しており、公開鍵については閲覧手続管理システム１に登録されている。

【0054】

続いて、診察データの対象患者の患者アドレスを取得する（ＳＴＥＰ３４）。患者アドレスとは、患者が閲覧手続管理システム１に登録することによって付与される患者に固有のアドレスであり、患者の患者端末６の専用アプリ内に記憶されている（図６のＳＴＥＰ１４参照）。患者アドレスは、患者端末６の画面に表示されたアドレスを見ながら、診察ノード２の画面上で手入力しても良いし、患者端末６と診察ノード２との間で通信することによって患者アドレスを取得しても良い。

【0055】

以上のような準備が終わったら、以下のような情報を含む登録メッセージ（すなわち、診察データの登録を申請するメッセージ）を作成して、閲覧手続管理システム１に送信する（ＳＴＥＰ３５）。図８は、登録メッセージに含まれる情報を示した説明図である。図示されるように、登録メッセージには、患者アドレスと、診察ノード特定情報と、診察データ特定情報と、診察ノードの署名を付けたハッシュ値とが含まれている。ここで、患者アドレスや、診察データ特定情報や、署名を付けたハッシュ値は、図７のＳＴＥＰ３４や、ＳＴＥＰ３１や、ＳＴＥＰ３２で取得されている。また、診察ノード特定情報とは、診察ノード２が自らを特定する情報（例えば、診察ノード２の閲覧手続管理システム１上でのアドレス）であり、診察ノード２は閲覧手続管理システム１に登録する際に設定された情報を記憶している。図７のＳＴＥＰ３５では、これらの情報を含んだ登録メッセージを作成して、閲覧手続管理システム１に送信する。そして、送信後は、一定時間が経過するまで待機することによって、後述するエラーメッセージが戻って来ないことを確認した後、診察データ送信処理を終了する。

【0056】

また、診察ノード２が閲覧手続管理システム１に送信した登録メッセージは、認証ノード３によって受信される。そして、登録メッセージを受け取った認証ノード３では、以下のような診察データ登録処理が実行される。先ず、登録メッセージに含まれる署名を認証する（ＳＴＥＰ４０）。前述したように、登録メッセージには、診察ノード特定情報や、診察データ特定情報や、診察データ特定情報の署名付きのハッシュ値が含まれている。そこで、署名付きのハッシュ値を、診察ノード特定情報に基づいて取得した診察ノード２の公開鍵を用いて復号する。また、登録メッセージには診察データ特定情報が含まれているので、その診察データ特定情報のハッシュ値を算出する。そして、算出したハッシュ値と、復号して得られたハッシュ値とを比較して、一致していれば認証が通ったものと判断し（ＳＴＥＰ４１：ｙｅｓ）、一致していなければ認証が通っていないものと判断する（ＳＴＥＰ４１：ｎｏ）。

【0057】

その結果、認証が通った場合は（ＳＴＥＰ４１：ｙｅｓ）、診察データのブロックデータ１０を作成する（ＳＴＥＰ４２）。図９は、認証ノード３によって作成されるブロックデータ１０を示した説明図である。図８に示したデータ（登録メッセージに含まれている情報）と、図９のブロックデータ１０とを比較すれば明らかなように、図９のブロックデータ１０は、登録メッセージに含まれる情報から、署名付きのハッシュ値を削除して、「受診通し番号」を加えたデータの組（以下、データ組１１と称する）に、前のブロックデータのハッシュ値を追加した内容となっている。

【0058】

ここで、受診通し番号とは、患者アドレスの患者にとって（何れの診察ノード２であるかを問わずに）何回目の受診であるかを示す番号である。すなわち、図２中のブロックデータ１０ａやブロックデータ１０ｂに例示するように、診察ノード２や認証ノード３には、患者が診察ノード２で受診して診察データが作成される度に、ブロックチェーン形式でブロックデータ１０が記憶されており、そのブロックデータ１０には、対象患者の患者アドレスが含まれている。従って、認証ノード３は、記憶している複数のブロックデータ１０を検索することで、患者アドレス毎に受診回数を調べることができ、今回の受診が、その患者にとって何回目の受診であるかも調べることができる。仮に、今回の受診がＮ回目であったとすれば、受診通し番号はＮとなる。図７のＳＴＥＰ４２では、こうして生成したデータ組１１に前のブロックデータ１０のハッシュ値を追加することによって、診察データを登録するためのブロックデータ１０を作成する。

【0059】

こうしてブロックデータ１０を作成したら、他の認証ノード３との合意の元で、そのブロックデータ１０を全ての診察ノード２に送信した後（ＳＴＥＰ４３）、登録受付処理を終了する。その結果、診察ノード２内には、診察データを登録するブロックデータ１０がブロックチェーン形式で記憶される。また、ＳＴＥＰ４３でブロックデータ１０を診察ノード２に送信する際には、認証ノード３自身も、そのブロックデータを記憶する。認証ノード３は、こうしてブロックデータ１０を送信すると共に自らも記憶した後、診察データ登録処理を終了する。

【0060】

以上のように、患者が診察ノード２を受診して、診察ノード２が診察データを作成すると、以上のような手続きを踏むことによって、図２中のブロックデータ１０ａやブロックデータ１０ｂに例示するようなブロックデータ１０が診察ノード２や認証ノード３内に記憶される。また、患者を診察する診察ノード２が、別の診察ノード２で作成された診察データを閲覧する必要が生じた場合には、以下のような手続きを踏むことによって、図２中のブロックデータ１０ｃに例示するようなブロックデータ１０（すなわち、閲覧許諾のブロックデータ１０）が作成される。

【0061】

Ｅ．診察データの閲覧要求動作 ：
図１０～図１２は、閲覧許諾のブロックデータ１０を作成して、診察ノード２や認証ノード３に記憶する際に実行される処理を示した説明図である。図１０には、要求ノード２ａ（診察データの閲覧を要求する診察ノード２）と、対象患者（閲覧しようとする診察データの患者）の患者端末６との間で実行される処理が示されており、図１１には、要求ノード２ａと作成ノード２ｂ（閲覧しようとする診察データを作成した診察ノード２）との間で実行される処理が示されている。そして、図１２には、作成ノード２ｂと認証ノード３との間で実行される処理が示されている。

【0062】

図１０に示されるように、閲覧許諾のブロックデータ１０を作成する際には、先ず始めに要求ノード２ａで閲覧要求処理が開始され、それに合わせて患者端末６では署名処理が開始される。要求ノード２ａは閲覧要求処理を開始すると、承諾メッセージを作成する（ＳＴＥＰ６０）。図１３は、承諾メッセージの文面を例示した説明図である。図示されるように、承諾メッセージは、要求ノード２ａが対象診察データ（閲覧しようとしている診察データ）を閲覧することを、対象患者が承諾する内容となっている。要求ノード２ａは承諾メッセージを作成すると、対象患者の患者端末６に送信する（ＳＴＥＰ６１）。

【0063】

尚、閲覧の態様には、画面上で診察データの内容を確認することはできるが、閲覧者の元には診察データが保存されない態様と、画面上で確認した診察データが閲覧者の手元に保存されて再び確認可能な態様と、単純に診察データを送信して貰う態様などを考えることができる。本明細書中で「閲覧」とは、上記の何れの態様も含んだ概念である。

【0064】

対象患者の患者端末６では、承諾メッセージを受信すると、署名処理が開始される。署名処理では、患者端末６の画面上に承諾メッセージを表示する（ＳＴＥＰ５０）。対象患者は、表示された承諾メッセージの内容を確認して、内容に異存が無ければ、承諾した日付を記入した後、閲覧期限を設定する（ＳＴＥＰ５１）。そして、閲覧手続管理システム１への登録時に作成した秘密鍵を用いて承諾メッセージに署名した後（ＳＴＥＰ５２）、要求ノード２ａに返信する（ＳＴＥＰ５３）。返信後は、一定時間が経過するまで待機することによって、後述するエラーメッセージが戻って来ないことを確認した後、署名処理を終了する。尚、本実施例の承諾メッセージは、本発明における「署名用データ」に対応する。

【0065】

要求ノード２ａの閲覧要求処理では、患者端末６から返信されてきた署名付きの承諾メッセージを受け取ると、対象患者の公開鍵を用いて認証する（ＳＴＥＰ６２）。対象患者の公開鍵は、閲覧手続管理システム１に登録する際に、全ての診察ノード２にブロックデータ１０として記憶されている。そこで、要求ノード２ａはその公開鍵を用いて署名付きの承諾メッセージを復号して、正しく復号されているか否かを確認することによって認証する（ＳＴＥＰ６３）。その結果、正しく復号されている場合は、認証が通ったものと判断して（ＳＴＥＰ６３：ｙｅｓ）、今後は作成ノード２ｂとの間で、以下のような処理を開始する。これに対して、正しく復号されていなかった場合は、認証が通らなかったものと判断して（ＳＴＥＰ６３：ｎｏ）、その旨のエラーメッセージを患者端末６に送信した後（ＳＴＥＰ６４）、閲覧要求処理を終了する。

【0066】

要求ノード２ａは、患者端末６の署名付きの承諾メッセージの認証が通ると（ＳＴＥＰ６３：ｙｅｓ）、今度は、その署名付きの承諾メッセージを、自分の秘密鍵を用いて署名する（図１１のＳＴＥＰ６５）。すなわち、承諾メッセージは、患者端末６および要求ノード２ａによって二重署名されることになる。

【0067】

続いて、閲覧を要求する診察データを特定するために、患者アドレスの受診通し番号を選択する（ＳＴＥＰ６６）。すなわち、作成ノード２ｂのデータサーバ４に対象患者の診察データが多数記憶されている場合、必ずしも全ての診察データを閲覧する必要があるとは限らないので、患者アドレスの受診通し番号を選択することによって、閲覧を要求する診察データを特定する。また、受診通し番号を選択しない場合は、全ての診察データの閲覧を要求しているものと見なされる。

【0068】

以上のような準備が終わったら、以下のような情報を含む要求メッセージ（すなわち、診察データの閲覧を要求するメッセージ）を作成して、作成ノード２ｂに送信する（ＳＴＥＰ６７）。図１４は、要求メッセージに含まれる情報を示した説明図である。図示されるように、要求メッセージには、患者アドレスと、受診通し番号と、要求ノード特定情報と、承諾メッセージと、対象患者および要求ノード２ａによって二重署名された承諾メッセージと、閲覧期限とが含まれている。ここで、要求ノード特定情報とは、要求ノード２ａが自らを特定する情報（例えば、要求ノード２ａの閲覧手続管理システム１上でのアドレス）である。また、患者アドレスは、患者を診察する際に患者の患者端末６から取得することができる。更に、承諾メッセージは要求ノード２ａが図１０のＳＴＥＰ６０で作成したメッセージであり、二重署名された承諾メッセージや、受診通し番号は、図１１のＳＴＥＰ６５およびＳＴＥＰ６６で取得している。加えて、閲覧期限は、図１０のＳＴＥＰ６２で患者端末６の署名付きの承諾メッセージを認証した際に取得している。そこで、診察データの閲覧を要求し、且つ、これらの情報を含んだ要求メッセージを作成して、閲覧手続管理システム１の作成ノード２ｂに送信する（ＳＴＥＰ６７）。そして、送信後は、一定時間が経過するまで待機することによって、後述するエラーメッセージが戻って来ないことを確認した後、閲覧要求処理を終了する。

【0069】

尚、ここでは、要求ノード２ａが自らを特定するために、要求ノード特定情報を含めた要求メッセージを作成ノード２ｂに送信するものとして説明している。しかし、作成ノード２ｂは、送信されてきた要求メッセージのヘッダ部分を解析することによって、要求ノード特定情報を取得することができる。従って、要求ノード特定情報は、実質的に要求メッセージに含まれていれば良く、明示的に含まれている必要はない。

【0070】

また、作成ノード２ｂでは、要求ノード２ａから送信されてきた要求メッセージを受信すると、以下のような閲覧許諾処理を開始する。先ず、受信した要求メッセージには、対象患者と要求ノード２ａとによって二重署名された承諾メッセージが含まれているので、その二重署名を認証する（ＳＴＥＰ７０）。すなわち、初めに要求ノード２ａの公開鍵を用いて、二重署名された承諾メッセージを復号し、復号した結果を更に対象患者の公開鍵を用いて復号する。要求ノード２ａから受信した要求メッセージには要求ノード特定情報や患者アドレスが含まれているので、要求ノード２ａの公開鍵や対象患者の公開鍵は取得することができる。

【0071】

こうして２つの公開鍵を用いて復号した結果が、元の承諾メッセージと一致した場合は、認証が通ったものと判断することができる（ＳＴＥＰ７１：ｙｅｓ）。尚、本実施例では、復号して得られたメッセージが、承諾メッセージと一致するか否かによって、認証が通ったか否かを判断しているが、復号した結果、意味を成す承諾メッセージが得られた場合は認証が通ったものと判断し、意味を成さない文字列しか得られなかった場合は、認証が通らなかったものと判断しても良い。こうすれば、要求ノード２ａが送信する要求メッセージに、承諾メッセージを含める必要がなくなるので、要求メッセージのデータ量を小さくすることができる。

【0072】

認証が通っていれば、作成ノード２ｂは、確かに要求ノード２ａが対象患者から承諾を得た上で、診察データの閲覧を要求していることを確認できたことになる。これに対して、一致しなかった場合は、認証が通らなかったものと判断することができる（ＳＴＥＰ７１：ｎｏ）。認証が通らなかった場合は、要求ノード２ａが対象患者の承諾を得ずに勝手に診察データの閲覧を要求しているか、要求ノード２ａではない何者かが要求ノード２ａと偽って診察データの閲覧を要求している可能性がある。そこで、認証が通らなかった場合は（ＳＴＥＰ７１：ｎｏ）、要求ノード２ａに対して認証が通らない旨のエラーメッセージを送信して（ＳＴＥＰ７２）、閲覧許諾処理を終了する。

【0073】

これに対して、認証が通った場合は（ＳＴＥＰ７１：ｙｅｓ）、対象患者の署名付きの承諾メッセージを、今度は作成ノード２ｂの秘密鍵を用いて署名することによって、対象患者および作成ノード２ｂによる二重署名を作成する（ＳＴＥＰ７３）。対象患者の署名付きの承諾メッセージは、ＳＴＥＰ７０で、対象患者および要求ノード２ａによる二重署名を認証した際に取得されている。

【0074】

その後、必要な情報を含む依頼メッセージを作成する（ＳＴＥＰ７４）。ここで、依頼メッセージとは、認証ノード３に対して閲覧許諾のブロックデータ１０の作成を依頼するメッセージである。また、依頼メッセージには、図１５に示した一組の情報が含まれている。図１４と図１５とを比較すれば明らかなように、図１５の一組の情報は、図１４の情報（すなわち、要求ノード２ａの要求メッセージに含まれていた情報）に対して、作成ノード２ｂを特定するための情報（以下、作成ノード特定情報）が追加されると共に、「患者と要求ノード２ａによる二重署名」が「患者と作成ノード２ｂによる二重署名」に変更されたものとなっている。作成ノード特定情報としては、閲覧手続管理システム１上での作成ノード２ｂのアドレスなどを用いることができる。

【0075】

尚、図１５に示した一組の情報には、患者アドレスおよび患者アドレスの受診通し番号が含まれているので、これらの情報に基づいて、対象診察データ（すなわち、要求ノード２ａが閲覧を要求している診察データ）を特定することができる。しかし、対象診察データを直接的に特定するための診察データ特定情報（例えば、前述したＵＲＬやＵＲＮなど）を追加しても良い。作成ノード２ｂは、これらの情報を含んだ依頼メッセージを作成する。

【0076】

また、本実施例の作成ノード２ｂは、要求ノード２ａから送信されてきた要求メッセージに、図１４に示した各種の情報が含まれているので、それらの情報を用いて、図１５に示した一組の情報を作成するものとして説明した。しかし、要求メッセージに含まれる二重署名の認証が通った場合には（図１１のＳＴＥＰ７１：ｙｅｓ）、作成ノード２ｂが自ら調べることによって、これらの情報を取得するようにしても良い。この場合は、要求メッセージには、作成ノード２ｂでは取得が困難な情報（例えば、患者アドレスや、受信通し番号や、対象患者および作成ノード２ｂによる二重署名など）を含めておけば良い。

【0077】

作成ノード２ｂは、こうして依頼メッセージを作成したら、依頼メッセージを閲覧手続管理システム１の認証ノード３に送信する（図１２のＳＴＥＰ７５）。そして、送信後は、一定時間が経過するまで待機することによって、後述するエラーメッセージが戻って来ないことを確認した後、閲覧許諾処理を終了する。

【0078】

認証ノード３は、以上のようにして作成ノード２ｂから送信されてきた依頼メッセージを受信すると、以下のような閲覧許諾登録処理を開始する。先ず、受信した依頼メッセージには、対象患者と作成ノード２ｂとによって二重署名された承諾メッセージが含まれている。そこで、対象患者の公開鍵および作成ノード２ｂの公開鍵を用いて、作成ノード２ｂがＳＴＥＰ７０で認証した時と同様な方法によって、二重署名された承諾メッセージを認証する（ＳＴＥＰ８０）。そして、認証が通ったか否かを判断して（ＳＴＥＰ８１）、認証が通らなかった場合は（ＳＴＥＰ８１：ｎｏ）、作成ノード２ｂに対して認証が通らない旨のエラーメッセージを送信して（ＳＴＥＰ８２）、閲覧許諾登録処理を終了する。

【0079】

これに対して、認証が通った場合は（ＳＴＥＰ８１：ｙｅｓ）、要求ノード２ａが診察データを閲覧することに、対象患者も作成ノード２ｂも同意していることを確認できたことになる。そこで、認証ノード３は、閲覧許諾のブロックデータ１０を作成する（ＳＴＥＰ８３）。ここで、閲覧許諾のブロックデータ１０とは、要求ノード２ａに閲覧権限を設定するブロックデータ１０である。図１６には、認証ノード３によって作成される閲覧許諾のブロックデータ１０を示した説明図である。図１５に示したデータ（要求メッセージに含まれている情報）と、図１６のブロックデータ１０とを比較すれば明らかなように、図１６の閲覧許諾のブロックデータ１０は、要求メッセージに含まれていた一組のデータの組（以下、データ組１２）に、前のブロックデータのハッシュ値を追加した内容となっている。

【0080】

認証ノード３は、こうして閲覧許諾のブロックデータ１０を作成したら、他の認証ノード３との合意の元で、その閲覧許諾のブロックデータ１０を全ての診察ノード２に送信する（ＳＴＥＰ４３）。その結果、診察ノード２内には、閲覧許諾のブロックデータ１０がブロックチェーン形式で記憶される。また、認証ノード３は、ＳＴＥＰ８４で閲覧許諾のブロックデータ１０を送信する際に、認証ノード３自身もそのブロックデータを記憶する。こうして閲覧許諾のブロックデータ１０を送信すると共に自らも記憶したら（ＳＴＥＰ８４）、要求ノード２ａおよび作成ノード２ｂに向けて閲覧用パスワードを送信した後（ＳＴＥＰ８５）、閲覧許諾登録処理を終了する。

【0081】

要求ノード２ａは、閲覧用パスワードを受け取ると、作成ノード２ｂに対して確認用パスワードを提示することにより、対象診察データを閲覧することができる。要求ノード２ａおよび作成ノード２ｂは、お互いにブロックチェーン形式で記憶している閲覧許諾のブロックデータ１０を参照することで、対象患者の承諾が得られており、作成ノード２ｂも許諾していることを確認することができるので、安心して診察データを作成ノード２ｂに要求し、また、診察データを要求ノード２ａに提供することができる。

【0082】

加えて、閲覧許諾のブロックデータ１０は、閲覧手続管理システム１を形成する全ての診察ノード２および認証ノード３に、ブロックチェーン形式で記憶されているので、後から改竄することは事実上、不可能である。従って、要求ノード２ａにとっては、対象患者および作成ノード２ｂの同意の元で診察データを閲覧したことを、後日に確実に立証することができる。また、作成ノード２ｂにとっても、対象患者の承諾を得た上で、要求ノード２ａの要求に応じて診察データを提供したことを、後日に確実に立証することができる。その結果、予期せぬ訴訟に巻き込まれる虞が無くなるため、それぞれの診察ノード２のデータサーバ４に記憶されている診察データを、診察ノード２間で有効活用することが可能となる。そして、このように大きな利点が得られるにも拘わらず、要求ノード２ａにとっては、単に診察データの閲覧を要求し、作成ノード２ｂにとっては要求を許諾する手続きを、閲覧手続管理システム１を介して行っているだけなので、要求ノード２ａおよび作成ノード２ｂの何れにとっても、大きな負担になることも無い。

【0083】

Ｆ．変形例 ：
上述した本実施例には幾つかの変形例を考えることができる。以下ではこれらの変形例について、本実施例との相違点を中心として簡単に説明する。

【0084】

Ｆ－１．第１変形例 ：
上述した本実施例では、要求ノード２ａが作成する要求メッセージには、対象患者および要求ノード２ａによる二重署名が含まれているものとして説明した（図１４参照）。また、作成ノード２ｂが作成する依頼メッセージには、対象患者および作成ノード２ｂによる二重署名が含まれているものとして説明した（図１５参照）。しかし、図１４の要求メッセージについては対象患者と要求ノード２ａとが署名していれば十分であり、図１５の依頼メッセージについては対象患者と作成ノード２ｂとが署名していれば十分である。従って、要求メッセージや依頼メッセージでの署名の方法などについては異なっていても良い。

【0085】

例えば、要求メッセージについては、図１４に示したように対象患者および要求ノード２ａが二重署名した承諾メッセージを含めるのではなく、図１７のように、対象患者による署名が付された承諾メッセージと、要求ノード２ａによる署名が付された承諾メッセージとを含む要求メッセージとしてもよい。すなわち、対象患者が署名する承諾メッセージは要求ノード２ａが対象患者に供給しているから、要求ノード２ａは署名前の承諾メッセージに対して署名することによって、自らの署名が付された承諾メッセージを作成することができる。従って、図１７に示すように、対象患者から受け取った署名付きの承諾メッセージと、自らの署名付きの承諾メッセージとを含んだ要求メッセージを作成してもよい。

【0086】

また、依頼メッセージについては、図１５に示したように対象患者および作成ノード２ｂが二重署名した承諾メッセージを含めるのではなく、図１８のように、対象患者による署名が付された承諾メッセージと、作成ノード２ｂによる署名が付された承諾メッセージとを含む要求メッセージとしてもよい。すなわち、作成ノード２ｂは、要求メッセージに含まれる対象患者および要求ノード２ａの署名を認証するために、署名前の承諾メッセージも取得しているから（図１４参照）、作成ノード２ｂは署名前の承諾メッセージに対して署名することによって、自らの署名が付された承諾メッセージを作成することができる。従って、図１８に示すように、対象患者から受け取った署名付きの承諾メッセージと、自らの署名付きの承諾メッセージとを含んだ依頼メッセージを作成してもよい。

【0087】

更に、署名の方法としては、上述した公開鍵と秘密鍵とを用いた方式の代わりに、他の署名方法を用いることもできる。例えば、患者の秘密鍵と作成ノード２ｂの秘密鍵とを用いて楕円曲線上で二重署名を行う方法（Ｅlliptic Ｃurve Ｄigital Ｓignature Ａlgorithm）が知られているので、この方法を用いてもよい。

【0088】

Ｆ－２．第２変形例 ：
上述した本実施例や第１変形例では、要求ノード２ａが作成する要求メッセージは、対象患者および要求ノード２ａの署名（すなわち、署名付きの承諾メッセージ）を含んだメッセージであるものとして説明した。同様に、作成ノード２ｂが作成する依頼メッセージは、対象患者および作成ノード２ｂの署名（すなわち、署名付きの承諾メッセージ）を含んだメッセージであるものとして説明した。しかし、要求メッセージや依頼メッセージは必ずしも署名を含んだメッセージでなくてもよい。

【0089】

例えば、要求メッセージについては、対象患者および要求ノード２ａの署名を含まないメッセージとしておく。そして、要求ノード２ａが作成ノード２ｂに要求メッセージを送信する際には、図１９に示したように、署名を含まない要求メッセージに、対象患者および要求ノード２ａの二重署名（すなわち、二重署名付きの承諾メッセージ）を添付して送信してもよい。あるいは、対象患者および要求ノード２ａの二重署名の代わりに、対象患者の署名（すなわち、署名付きの承諾メッセージ）および要求ノード２ａの署名（すなわち、署名付きの承諾メッセージ）を添付して送信してもよい。

【0090】

また、依頼メッセージについても、対象患者および作成ノード２ｂの署名を含まないメッセージとしてもよい。そして、作成ノード２ｂが認証ノード３に依頼メッセージを送信する際には、図２０に示したように、署名を含まない依頼メッセージに、対象患者および作成ノード２ｂの二重署名（すなわち、二重署名付きの承諾メッセージ）を添付して送信してもよい。あるいは、対象患者および作成ノード２ｂの二重署名の代わりに、対象患者の署名（すなわち、署名付きの承諾メッセージ）および作成ノード２ｂの署名（すなわち、署名付きの承諾メッセージ）を添付して送信してもよい。

【0091】

以上、本実施例および各種変形例の閲覧手続管理システム１について説明したが、本発明は上記の実施例および変形例に限られるものではなく、その要旨を逸脱しない範囲において種々の態様で実施することが可能である。

【符号の説明】

【0092】

１…閲覧手続管理システム、 ２…診察ノード、 ２ａ…要求ノード、
２ｂ…作成ノード、 ３…認証ノード、 ４…データサーバ、
５…通信回線、 ６…患者端末、 １０…ブロックデータ、
１１…データ組、 １２…データ組、 ２０…診察データ作成部、
２１…診察データ出力部、 ２２…メッセージ受信部、 ２３…署名認証部、
２４…メッセージ作成部、 ２５…特定情報取得部、
２６…メッセージ送信部、 ２７…ブロックデータ受信部、
２８…ブロックデータ記憶部、 ３０…メッセージ受信部、
３１…署名認証部、 ３２…ブロックデータ作成部、 ３３…特定情報取得部、
３４…ブロックデータ送信部、 ３５…ブロックデータ記憶部。

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】

【図12】

【図13】

【図14】

【図15】

【図16】

【図17】

【図18】

【図19】

【図20】