JP7560634B2 - Viewing procedure management system and viewing procedure management method - Google Patents
Viewing procedure management system and viewing procedure management method Download PDFInfo
- Publication number
- JP7560634B2 JP7560634B2 JP2023161785A JP2023161785A JP7560634B2 JP 7560634 B2 JP7560634 B2 JP 7560634B2 JP 2023161785 A JP2023161785 A JP 2023161785A JP 2023161785 A JP2023161785 A JP 2023161785A JP 7560634 B2 JP7560634 B2 JP 7560634B2
- Authority
- JP
- Japan
- Prior art keywords
- node
- data
- medical examination
- signature
- request
- 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.)
- Active
Links
Images
Landscapes
- Medical Treatment And Welfare Office Work (AREA)
Description
本発明は、患者を診察することによって診察データを作成し、通信回線で接続された複数の診察ノードが、互いの診察データを閲覧する手続を管理する技術に関する。 The present invention relates to a technology that creates diagnostic data by examining patients and manages the procedure for multiple diagnostic nodes connected via communication lines to view each other's diagnostic data.
医師が患者を診察する際には、患者が他の医療機関で受診した時の診察記録（例えば検査画像や検査数値や医師の所見など）を参照する必要が生じることがある。このような場合、患者が以前に受信した医療機関に依頼して、診察記録を提供して貰うことになる。 When a doctor examines a patient, it may be necessary for the doctor to refer to the medical records (such as test images, test results, doctor's findings, etc.) from when the patient was examined at another medical institution. In such cases, the patient will request the medical institution from which the doctor previously received medical information to provide the medical records.
ところが、依頼を受けた医療機関にとっては、依頼に応じて診察記録を提供すれば良いという単純な話ではない。その理由は、次のようなものである。先ず、診察記録は単に検査結果（検査画像や検査数値など）を記載したものではなく、医師の長年の臨床経験や、医学的な知識や、それらを踏まえた医療方針などが反映されて生み出される創作物である。このため、診察記録には医師の著作権が混入している可能性がある。加えて、診察記録は患者にとっては極めて敏感な個人情報となり得るため、取扱いによっては患者のプライバシー権を侵害する虞がある。これらの事情から、依頼に応じてむやみに診察記録を提供すると、予期せぬ訴訟に巻き込まれる虞が生じるためである。実際に医療の現場では、複数の医療機関で診察記録を積極的に相互利用しようとしても、上述した事情が障害となっている旨が報告されている（非特許文献１）。 However, for the medical institution that receives the request, it is not as simple as just providing the medical records in response to the request. The reasons are as follows. First, medical records are not simply records of test results (such as test images and test values), but are creative works that reflect the doctor's many years of clinical experience, medical knowledge, and medical policies based on these. For this reason, there is a possibility that the doctor's copyright may be mixed in with the medical records. In addition, since medical records can be extremely sensitive personal information for patients, there is a risk of violating the patient's right to privacy depending on how they are handled. For these reasons, if medical records are provided in response to a request without thinking, there is a risk of being involved in unexpected lawsuits. In fact, in the medical field, it has been reported that the above-mentioned circumstances are an obstacle to multiple medical institutions actively trying to share medical records (Non-Patent Document 1).
これに対して、複数の医療機関で作成された診察記録を診察記録データベースに記憶すると共に、診察記録を参照するための記録識別情報をブロックチェーンデータベースに記憶し、更に、登録情報データベースに、患者を識別する患者識別情報に対応付けて記録識別情報を記憶しておくことで、保険会社などの第三者機関が患者の診察記録を長期に亘って参照できるようにした技術が提案されている（特許文献１）。 In response to this, a technology has been proposed in which medical records created at multiple medical institutions are stored in a medical record database, record identification information for referencing the medical records is stored in a blockchain database, and the record identification information is stored in a registration information database in association with patient identification information that identifies the patient, allowing third-party institutions such as insurance companies to refer to patient medical records over the long term (Patent Document 1).
あるいは、患者の処方箋データをブロックチェーンデータベースに記憶しておき、医者が処方箋を発行する場合や、薬剤師が処方箋を参照する場合は、患者が端末を操作することによって、医者または薬剤師に対してブロックチェーンデータベース上での処方箋データへのアクセス権限を付与し、処方箋の会計処理が終わったら、医者または薬剤師のアクセス権限を剥奪するようにした技術が提案されている（特許文献２）。 Alternatively, a technology has been proposed in which a patient's prescription data is stored in a blockchain database, and when a doctor issues a prescription or a pharmacist refers to a prescription, the patient operates a terminal to grant the doctor or pharmacist access to the prescription data on the blockchain database, and once the prescription accounting process is complete, the doctor or pharmacist's access authority is revoked (Patent Document 2).
しかし、上述した従来の技術では、複数の医療機関に保存されている診察記録の可用性を十分に担保することができないという問題があった。例えば、上述した特許文献１に記載の技術では、保険会社などが過去の診察記録を容易に入手可能であるものの、診察記録を入手あるいは提供する行為が、患者や診察記録を作成した医師の同意に基づく行為であることを立証することができない。このため、診察記録を入手あるいは提供したことで予期せぬ訴訟に巻き込まれる虞がある。また、上述した特許文献２に記載の技術では、処方箋に基づいて調剤する際に、患者の同意に基づいて処方箋の提供を受けたことを立証可能であるものの、診察記録の提供を受ける際に、医師や患者の同意に基づいて提供を受けたことは立証することができない。このため、処方箋や診察記録を入手あるいは提供したことで予期せぬ訴訟に巻き込まれる虞がある。
However, the above-mentioned conventional technology has a problem in that it is not possible to fully guarantee the availability of medical records stored in multiple medical institutions. For example, with the technology described in the above-mentioned
この発明は、従来の技術が有する上述した課題を解決するために成されたものであり、医療機関に保存されている診察記録を入手あるいは提供する際に、該当する患者および医師の同意が得られていることを後日に容易に立証可能でありながら、簡単な手続で診察記録を入手あるいは提供可能とすることで、診察記録の可用性を十分に担保することが可能な診察記録管理システムを実現することを目的とする。 This invention has been made to solve the above-mentioned problems with the conventional technology, and aims to realize a medical record management system that can fully guarantee the availability of medical records by making it possible to obtain or provide medical records stored in a medical institution through a simple procedure while easily proving at a later date that consent has been obtained from the relevant patient and doctor when obtaining or providing the records.
上述した課題を解決するために、本発明の閲覧手続管理システムは、次の構成を採用した。すなわち、
患者を診察することによって診察データを作成すると共に、複数のブロックデータをブロックチェーン形式で記憶する複数の診察ノードと、前記ブロックデータを生成して前記診察ノードに記憶させる認証ノードとが通信回線で接続されることによって形成され、複数の前記診察ノード間で前記診察データを閲覧する手続を管理する閲覧手続管理システムであって、
前記診察ノードは、
複数のブロックデータをブロックチェーン形式で記憶するブロックデータ記憶部と、
前記診察データを作成すると、前記診察ノードに接続されたデータベースに出力する診察データ出力部と
を備えており、
複数の前記診察ノードの中には、他の前記診察ノードで作成された前記診察データの閲覧を要求する要求ノードと、前記要求ノードから閲覧を要求された前記診察データである対象診察データを作成した作成ノードとが含まれており、
前記要求ノードは、前記作成ノードに対して前記対象診察データの閲覧を要求するメッセージであって、前記対象診察データの診察対象である対象患者の署名が付与された所定の署名用データを含むか、前記対象患者の署名が付与された前記署名用データが添付された前記メッセージである要求メッセージを作成すると、前記要求メッセージを前記作成ノードに送信する要求メッセージ送信部を有しており、
前記作成ノードは、
前記要求メッセージを受け取ると、前記要求メッセージと共に受け取った前記署名用データの前記対象患者の署名を認証する患者署名認証部と、
前記対象患者の署名の認証が成功した場合には、前記対象診察データを特定するための診察データ特定情報と、前記要求ノードを特定するための要求ノード特定情報とを取得する特定情報取得部と、
前記要求ノードが前記対象診察データを閲覧可能となる閲覧権限の設定を依頼するためのメッセージであって、前記診察データ特定情報と、前記要求ノード特定情報とを含むと共に、前記対象患者の署名付きの前記署名用データおよび前記作成ノードの署名付きの前記署名用データを更に含むか、前記対象患者の署名付きの前記署名用データおよび前記作成ノードの署名付きの前記署名用データが添付された前記メッセージである依頼メッセージを作成する依頼メッセージ作成部と、
前記依頼メッセージを前記認証ノードに送信する依頼メッセージ送信部と
を有しており、
前記認証ノードは、
前記依頼メッセージを受け取ると、前記対象患者の署名および前記作成ノードの署名を含み、前記要求ノードに対して前記対象診察データの閲覧権限を設定する前記ブロックデータを生成するブロックデータ生成部と、
生成した前記ブロックデータを複数の前記診察ノードに送信するブロックデータ送信部と
を備えることを特徴とする。
In order to solve the above-mentioned problems, the browsing procedure management system of the present invention adopts the following configuration.
A viewing procedure management system that is formed by connecting a plurality of medical examination nodes that create medical examination data by examining a patient and store a plurality of block data in a block chain format with an authentication node that generates the block data and stores it in the medical examination nodes through a communication line, and that manages a procedure for viewing the medical examination data between the plurality of medical examination nodes,
The medical examination node includes:
A block data storage unit that stores a plurality of block data in a blockchain format;
a diagnosis data output unit that outputs the diagnosis data to a database connected to the diagnosis node when the diagnosis data is created;
Among the plurality of medical examination nodes, there are included a request node which requests to view the medical examination data created by another medical examination node, and a creating node which creates target medical examination data which is the medical examination data requested to be viewed by the request node,
the request node has a request message sending unit which, when creating a request message which is a message requesting the creation node to view the target medical examination data, includes predetermined signature data to which a signature of a target patient who is a medical examination target of the target medical examination data is attached, or is a message to which the signature data to which the signature data of the target patient is attached is attached, sends the request message to the creation node;
The creation node is
a patient signature authentication unit that, upon receiving the request message, authenticates the signature of the target patient in the signature data received together with the request message;
a specific information acquisition unit that acquires, when the authentication of the signature of the target patient is successful, diagnostic data specific information for identifying the target diagnostic data and request node specific information for identifying the request node;
a request message creation unit that creates a request message for requesting the setting of a viewing authority that enables the request node to view the target medical examination data, the request message including the medical examination data identification information and the request node identification information, and further including the signature data with the signature of the target patient and the signature data with the signature of the creating node, or a message to which the signature data with the signature of the target patient and the signature data with the signature of the creating node are attached;
a request message sending unit that sends the request message to the authentication node,
The authentication node,
a block data generating unit that, upon receiving the request message, generates the block data including the signature of the target patient and the signature of the generating node, and sets a viewing authority of the target medical examination data for the requesting node;
and a block data transmission unit that transmits the generated block data to the plurality of medical examination nodes.
また、上述した本発明の閲覧手続管理システムに対応する本発明の閲覧手続管理方法は、次の構成を採用した。すなわち、
患者を診察することによって診察データを作成すると共に複数のブロックデータをブロックチェーン形式で記憶する複数の診察ノードと、前記ブロックデータを生成して前記診察ノードに出力する認証ノードとが通信回線で接続されたネットワーク上で通信することにより、複数の前記診察ノード間で前記診察データを閲覧する手続を管理する閲覧手続管理方法であって、
複数の前記診察ノードの中で、他の前記診察ノードで作成された前記診察データの閲覧を要求する要求ノードが、前記要求ノードから閲覧を要求された前記診察データである対象診察データを作成した作成ノードに対して送信するメッセージであって、前記対象診察データの閲覧を要求すると共に、前記対象診察データの診察対象である対象患者の署名が付与された所定の署名用データを含むか、前記対象患者の署名が付与された前記署名用データが添付された前記メッセージである要求メッセージを作成して、前記作成ノードに送信する工程と、
前記作成ノードが、前記要求メッセージと共に受け取った前記署名用データの前記対象患者の署名を認証する工程と、
前記対象患者の署名の認証が成功した場合には、前記対象診察データを特定するための診察データ特定情報と、前記要求ノードを特定するための要求ノード特定情報とを、前記作成ノードが取得する工程と、
前記対象診察データを前記要求ノードが閲覧可能となる閲覧権限の設定を依頼するためのメッセージであって、前記診察データ特定情報と、前記要求ノード特定情報とを含むと共に、前記対象患者の署名付きの前記署名用データおよび前記作成ノードの署名付きの前記署名用データを更に含むか、前記対象患者の署名付きの前記署名用データおよび前記作成ノードの署名付きの前記署名用データが添付された前記メッセージである依頼メッセージを、前記作成ノードが作成して、前記認証ノードに送信する工程と、
前記認証ノードが前記依頼メッセージを受け取ると、前記認証ノードが、前記対象患者の署名と前記作成ノードの署名とを含み、前記要求ノードに対して前記対象診察データの閲覧権限を設定する前記ブロックデータを生成して、複数の前記診察ノードに送信する工程と
を備えることを特徴とする。
The browsing procedure management method of the present invention, which corresponds to the browsing procedure management system of the present invention described above, employs the following configuration.
A viewing procedure management method for managing a procedure for viewing the medical examination data between a plurality of medical examination nodes, the plurality of medical examination nodes creating medical examination data by examining a patient and storing a plurality of block data in a block chain format, and an authentication node generating the block data and outputting the block data to the medical examination nodes, by communicating with each other on a network connected by a communication line, the plurality of medical examination nodes comprising:
a request node, among the plurality of said diagnosis nodes, which requests to view said diagnosis data created by another said diagnosis node, sends a message to a creating node which created target diagnosis data, which is the diagnosis data requested to be viewed by said request node, the request message being a message requesting to view said target diagnosis data and including predetermined signature data to which a signature of a target patient who is a diagnosis target of said target diagnosis data is affixed, or a message to which the signature data to which the signature of said target patient is affixed is attached, and sending the request message to said creating node;
the generating node authenticating the signature of the target patient in the signature data received together with the request message;
When the authentication of the signature of the target patient is successful, the creating node acquires diagnostic data identification information for identifying the target diagnostic data and request node identification information for identifying the request node;
a step of the creating node creating a request message for requesting the setting of a viewing authority to allow the request node to view the target diagnostic data, the request message including the diagnostic data identifying information and the request node identifying information, and further including the signature data with the signature of the target patient and the signature data with the signature of the creating node, or the signature data with the signature of the target patient and the signature data with the signature of the creating node being attached, and transmitting the request message to the authentication node;
When the authentication node receives the request message, the authentication node generates the block data, which includes the signature of the target patient and the signature of the creating node and sets the viewing authority of the target medical examination data for the requesting node, and transmits the block data to multiple medical examination nodes.
このような本発明の閲覧手続管理システムおよび閲覧手続管理方法では、要求ノードが他の診察ノードで作成された診察データの閲覧を要求する場合には、作成ノードに対して診察データ（対象診察データ）の閲覧を求める要求メッセージを作成して、作成ノードに送信する。作成ノードは、要求メッセージと共に送られてくる対象患者の署名に基づいて、対象患者の同意が得られていることを確認すると、要求ノードに対して対象診察データの閲覧権限を設定するように依頼する依頼メッセージを作成して、認証ノードに送信する。認証ノードは、依頼メッセージを受け取ると、要求ノードに対して対象診察データの閲覧権限を設定するブロックデータを生成して、要求ノードを含む複数の診察ノードに送信する。複数の診察ノードでは、認証ノードから送信されてきたブロックデータがブロックチェーン形式で記憶される。 In the browsing procedure management system and browsing procedure management method of the present invention, when a requesting node requests to browse medical examination data created by another medical examination node, it creates a request message requesting the creating node to view the medical examination data (target medical examination data) and sends it to the creating node. When the creating node confirms that the target patient's consent has been obtained based on the target patient's signature sent together with the request message, it creates a request message requesting the requesting node to set the viewing authority for the target medical examination data and sends it to the authentication node. When the authentication node receives the request message, it generates block data that sets the viewing authority for the target medical examination data for the requesting node and sends it to multiple medical examination nodes including the requesting node. In the multiple medical examination nodes, the block data sent from the authentication node is stored in blockchain format.
こうすれば、複数の診察ノードに記憶されているブロックデータを調べれば、要求ノードに対する対象診察データの閲覧権限が、対象患者および作成ノードの同意に基づいて設定されたことを容易に確認することができる。このため要求ノードにとっては、対象患者および作成ノードの同意を得た上で対象診察データを閲覧したことを、後日になっても容易に立証することができる。また、作成ノードにとっては、対象患者の同意に基づいて、要求ノードに対象診察データを閲覧させたことを、後日になっても容易に立証することができる。その結果、他の診察ノードで作成された診察データを閲覧したり、他の診察ノードに診察データを閲覧させたりした場合でも、予期せぬ訴訟に巻き込まれる虞がないので、診察ノードの可用性を十分に確保することが可能となる。 In this way, by checking the block data stored in multiple medical examination nodes, it is easy to confirm that the request node's viewing authority for the target medical examination data was set based on the consent of the target patient and the creating node. Therefore, the request node can easily prove at a later date that it viewed the target medical examination data with the consent of the target patient and the creating node. In addition, the creating node can easily prove at a later date that it allowed the request node to view the target medical examination data based on the target patient's consent. As a result, even if the medical examination data created by another medical examination node is viewed or if another medical examination node is allowed to view the medical examination data, there is no risk of being involved in unexpected litigation, and the availability of the medical examination node can be sufficiently ensured.
Ａ．閲覧手続管理システム１の概要 ：
図１は、本実施例の閲覧手続管理システム１の概要を示す説明図である。本実施例の閲覧手続管理システム１は、患者を診察することによって診察データを作成する複数の診察ノード２や、認証ノード３が、インターネットなどの通信回線５を介して接続されることによって形成されている。ここで、診察データとは、医師が患者を診察することによって作成された診療録をデータ化したものであり、診療録には検査画像や検査数値や医師のメモなども含まれる。また、後述するように診察ノード２は、複数のブロックデータをブロックチェーン形式で記憶することが可能となっており、認証ノード３が後述する方法で新たなブロックデータを生成して、通信回線５を介して診察ノード２に送信すると、診察ノード２に新たなブロックデータが追加されるようになっている。
A. Overview of the Inspection Procedure Management System 1:
FIG. 1 is an explanatory diagram showing an overview of the browsing
それぞれの診察ノード２には専用のデータサーバ４が接続されており、診察ノード２は診察データを作成するとデータサーバ４に診察データを記憶しておき、必要に応じてデータサーバ４から診察データを読み出して閲覧することができる。また、他の診察ノード２で作成された診察データを閲覧する必要が生じた場合は、その診察データを作成した診察ノード２に対して、閲覧を要求するメッセージを送信することで、必要とする診察データを閲覧することが可能となる。尚、以下では、他の診察ノード２で作成された診察データの閲覧を要求する診察ノード２を「要求ノード２ａ」と称し、要求ノード２ａが閲覧を要求する対象の診察データを「対象診察データ」と称し、その対象診察データを作成した診察ノード２を「作成ノード２ｂ」と称するものとする。
A
また、本実施例では、診察ノード２毎に専用のデータサーバ４が接続されているものとして説明するが、これに限らず、例えば複数の診察ノード２を共用のデータサーバ４に接続して、それら診察ノード２が診察データを作成すると共用のデータサーバ４に記憶するようにしても良い。あるいは、全ての診察ノード２を中央のデータサーバ４に接続して、全ての診察ノード２で作成された診察データは中央のデータサーバ４に記憶されるようにしても良い。尚、本実施例のデータサーバ４は、本発明における「データベース」に対応する。
In addition, in this embodiment, it is described that a
更に、通信回線５には複数の認証ノード３も接続されている。複数の認証ノード３は通信回線５を介して診察ノード２と通信可能となっており、診察ノード２が診察データを作成したり、要求ノード２ａの要求に応じて作成ノード２ｂが診察データの閲覧を許諾する度にブロックデータを作成する。そして、複数の認証ノード３で作成されたブロックデータは、複数の認証ノード３の合意によって確定されて、全ての診察ノード２に一斉に送信される。その結果、全ての診察ノード２には、複数のブロックデータがブロックチェーン形式で蓄積されるようになっている。また、ブロックデータは、複数の認証ノード３にもブロックチェーン形式で蓄積される。
Furthermore, a plurality of
尚、本実施例では、認証ノード３は患者を診察しないので診察データも作成しないとしているため、図１に示した例では、認証ノード３にはデータサーバ４が接続されていない。しかし、認証ノード３でも患者を診察して診察データを作成しても良い。この場合は、認証ノード３にもデータサーバ４が接続されており、認証ノード３で作成された診察データはデータサーバ４に記憶される。
In this embodiment, the
また、診察ノード２で診察を受ける患者は、スマートフォンなどの患者端末６に専用のアプリケーションをインストールすることで、患者端末６から通信回線５を介して閲覧手続管理システム１に接続することが可能となる。あるいは患者端末６のＷｅｂブラウザを用いて、閲覧手続管理システム１に接続しても良い。
In addition, a patient who is examined at the
図２は、診察ノード２や認証ノード３にブロックチェーン形式で記憶されている複数のブロックデータ１０を例示した説明図である。図２に示した例では、５つのブロックデータ１０ａ～１０ｅがブロックチェーン形式で記憶されている状態が概念的に示されている。図示されるように、ブロックデータ１０はデータ形式が同一のデータ（すなわち、同じ種類のデータ）である必要はなく、図２に示した例では３種類のブロックデータ１０が記憶されている。すなわち、３つのブロックデータ１０ａ，１０ｂ，１０ｄは、互いに同じデータ形式を有する同じ種類のデータであるが、ブロックデータ１０ｃやブロックデータ１０ｅは、他のブロックデータとは異なる種類のデータとなっている。
Figure 2 is an explanatory diagram illustrating
また、これらのブロックデータ１０ａ～１０ｄは、ブロックチェーン形式で記憶されている。ここで、ブロックチェーン形式とは次のような形式である。例えば、図２中のブロックデータ１０ｂに着目すると、ブロックデータ１０ｂの中には前のブロックデータ１０ａのハッシュ値が含まれている。周知のように、ハッシュ値とは、任意のデータに対してハッシュ関数と呼ばれる特別な操作を行うことによって得られる値である。また、ハッシュ関数は、どのようなサイズのデータであっても同じデータ長のハッシュ値に変換し、変換前のデータの一部でも異なれば変換したハッシュ値は全く異なる値となり、更に、ハッシュ値からは変換前のデータに戻すことが不可能であるという性質を有している。従って、ハッシュ値と元のデータとの間には一対一の関係が成立しており、ハッシュ値は変換前のデータを一意的に代表すると考えて良い。
These
図２のブロックデータ１０ｂの中には、前のブロックデータ１０ａのハッシュ値が含まれており、ブロックデータ１０ｂのハッシュ値は、後ろのブロックデータ１０ｃの中に含まれている。そのブロックデータ１０ｃのハッシュ値は、その後ろのブロックデータ１０ｄの中に含まれており、ブロックデータ１０ｄのハッシュ値は、更に後のブロックデータ１０ｅの中に含まれている。その結果、５つのブロックデータ１０ａ～１０ｅは、鎖のように一つずつ繋がった状態となっている。このような状態が、ブロックチェーン形式と呼ばれる状態である。診察ノード２や認証ノード３には、このようなブロックチェーン形式で複数のブロックデータ１０が記憶されている。尚、本実施例では、複数のブロックデータが、前のブロックデータのハッシュ値を用いて繋がっているものとしているが、これは、前のブロックデータのハッシュ値が、前のブロックデータを一意的に代表するという特性を有するためである。従って、前のブロックデータのハッシュ値の代わりに、前のブロックデータを特定する情報（例えば、前のブロックデータのＵＲＬ（Ｕniform Ｒesouce Ｌocation ）やＵＲＮ（Ｕniform Ｒesouce Ｎame ）など）を用いて、複数のブロックデータを繋げるようにしても良い。また、これらのブロックデータ１０は、次のようにして診察ノード２や認証ノード３に記憶される。
図３は、閲覧手続管理システム１の診察ノード２や認証ノード３にブロックデータ１０が記憶される様子を概念的に示した説明図である。例えば、本実施例の診察ノード２は、患者を診察して診察データを作成すると、その診察データをデータサーバ４に記憶すると共に、診察データを登録するように要請するメッセージ（以下、登録メッセージ）を閲覧手続管理システム１に送信する。すると、その登録メッセージが閲覧手続管理システム１の複数の認証ノード３によって認証されて、認証を通った場合は、複数の認証ノード３の合意によって、診察データを登録するためのブロックデータ１０が作成される。そして、そのブロックデータ１０が認証ノード３から複数の診察ノード２に送信されて、診察ノード２および認証ノード３に記憶される。図２中のブロックデータ１０ａやブロックデータ１０ｂ、ブロックデータ１０ｄは、このようにして記憶されたブロックデータ１０である。尚、このようなブロックデータ１０が作成される詳細な動作については後述する。
Figure 3 is an explanatory diagram conceptually showing how
また、ブロックデータ１０の記憶後に、別の診察ノード２から閲覧手続管理システム１に診察データの登録メッセージが送信されてきた場合には、その前に記憶したブロックデータ１０に続けて新たなブロックデータ１０がブロックチェーン形式で記憶される。図３に示した例では、４つの診察ノード２から送信された診察データの登録メッセージに対応して、４つのブロックデータ１０がブロックチェーン形式で記憶される。
In addition, after the
患者が、患者端末６から閲覧手続管理システム１に対して登録を申請するメッセージ（以下、登録申請メッセージ）を送信した場合には、その登録申請メッセージが閲覧手続管理システム１の認証ノード３によって認証される。そして、認証を通った場合は、患者を登録するためのブロックデータ１０が診察ノード２および認証ノード３に記憶される。図２中のブロックデータ１０ｅは、このようにして記憶されたブロックデータ１０である。このようなブロックデータ１０が作成される詳細な手続きについても後述する。
When a patient sends a message requesting registration (hereinafter, a registration request message) from the
また、要求ノード２ａが作成ノード２ｂに対して診察データの閲覧を要求するメッセージ（以下、要求メッセージ）を送信すると、それに対して作成ノード２ｂが閲覧権限の設定を依頼するメッセージ（以下、依頼メッセージ）を閲覧手続管理システム１に送信する。すると、その依頼メッセージが閲覧手続管理システム１の複数の認証ノード３によって認証されて、認証を通った場合は、複数の認証ノード３の合意によって、要求ノード２ａに閲覧権限を設定するブロックデータ１０が作成されて、診察ノード２および認証ノード３に記憶される。図２中のブロックデータ１０ｃは、このようにして記憶されたブロックデータ１０である。以下では、図２中のブロックデータ１０ｃのように、要求ノード２ａに閲覧権限を設定するブロックデータ１０を、特に「閲覧許諾のブロックデータ１０」と称することがある。尚、図２のブロックデータ１０ｃ中に、「患者と作成ノードによる基準値の二重署名」とあるのは、患者が基準値に署名したものに重ねて作成ノード２ｂが署名したものを指している。また、閲覧許諾のブロックデータ１０が作成される詳細な手続きについても後述する。
When the
このように、本実施例の閲覧手続管理システム１では、診察ノード２や、要求ノード２ａや、作成ノード２ｂなどが、閲覧手続管理システム１に対して（あるいは閲覧手続管理システム１を介して）メッセージを送信すると、そのメッセージが認証ノード３によって認証されて、診察ノード２および認証ノード３にブロックデータ１０がブロックチェーン形式で記憶されていく。特に、要求ノード２ａの要求に応じて、作成ノード２ｂが認証ノード３に送信する依頼メッセージには、診察データの対象である患者（以下、対象患者）および作成ノード２ｂによる二重署名が含まれており、依頼メッセージを受信した認証ノード３は二重署名を認証して、認証できた場合に、閲覧許諾のブロックデータ１０（図２中のブロックデータ１０ｃを参照）を作成する。従って、対象患者および作成ノード２ｂの二重署名を認証できなかった場合には、閲覧許諾のブロックデータ１０が作成されることはなく、診察ノード２や認証ノード３に閲覧許諾のブロックデータ１０が記憶されることも無い。尚、対象患者および作成ノード２ｂの二重署名の代わりに、対象患者の署名および作成ノード２ｂの署名を依頼メッセージに含めておき、依頼メッセージを受け取った認証ノード３は、対象患者の署名および作成ノード２ｂの署名を認証しても良い。
In this way, in the browsing
このことから、要求ノード２ａは、閲覧許諾のブロックデータ１０を確認した上で対象診察データを閲覧している限り、対象患者や作成ノード２ｂの同意を得た上で対象診察データを閲覧したことを、後日になっても容易に立証することができる。加えて、ブロックデータ１０はブロックチェーン形式で記憶されているため、後からブロックデータ１０の内容を改竄することは困難である。更に、ブロックデータ１０は複数の診察ノード２および認証ノード３に重複して記憶されているため、たとえ仮に、ある診察ノード２のブロックデータ１０を改竄できたとしても、他の複数の診察ノード２および認証ノード３のブロックデータ１０と照合することで、改竄されていることが分かってしまう。従って、閲覧許諾のブロックデータ１０が改竄されていないことも容易に立証することができる。その結果、要求ノード２ａは、閲覧手続管理システム１を介して作成ノード２ｂに診察データの閲覧を要求しておけば、その診察データを閲覧したことで、予期せぬ訴訟に巻き込まれる虞を回避することができる。
Therefore, as long as the
また、作成ノード２ｂにとっても、閲覧手続管理システム１を介して要求ノード２ａに診察データの閲覧を許諾しておけば、予期せぬ訴訟に巻き込まれる虞を回避することができる。すなわち、閲覧許諾のブロックデータ１０には対象患者の署名が含まれているため、作成ノード２ｂが対象患者の署名の無いまま、要求ノード２ａに対して閲覧を許諾しようとして閲覧手続管理システム１にメッセージを送信しても、認証ノード３の認証が通らないため、閲覧許諾のブロックデータ１０が作成されることがない。その結果、作成ノード２ｂは、閲覧手続管理システム１を介して要求ノード２ａに対象診察データの閲覧を許諾しておけば、患者の同意のないまま勝手に診察データの閲覧を許諾してしまい、予期せぬ訴訟に巻き込まれる虞を回避することができる。
Also, for the
そして、このような大きな利点が得られるにも拘らず、要求ノード２ａや作成ノード２ｂにとっては、診察データの閲覧を要求したり、要求に応じて閲覧を許諾したりする連絡を、閲覧手続管理システム１を介して行っているに過ぎない。このため、要求ノード２ａや作成ノード２ｂに大きな負担をかけることなく、診察データの可用性を担保することが可能となる。以下では、こうしたことを実現する閲覧手続管理システム１の詳細について説明する。
And yet, despite these great advantages, for the requesting
Ｂ．診察ノード２および認証ノード３の内部構造 ：
図４は、本実施例の閲覧手続管理システム１を形成する診察ノード２の内部構造を示したブロック図である。図示されるように、診察ノード２の内部には、診察データ作成部２０や、診察データ出力部２１、メッセージ受信部２２、署名認証部２３、メッセージ作成部２４、特定情報取得部２５、メッセージ送信部２６、ブロックデータ受信部２７、ブロックデータ記憶部２８などが搭載されている。尚、これらの「部」は、診察ノード２に搭載されている機能を表す抽象的な概念であり、これらの「部」に対応する部品が存在することを示しているわけではない。これらの「部」は、診察ノード２に内蔵されたマイクロコンピュータで実行されるソフトウェアプログラムとして実現することもできるし、診察ノード２に搭載されたＬＳＩやＩＣなどによるハードウェアとして実現することもできる。更には、ソフトウェアプログラムとハードウェアとを組み合わせることによって実現しても良い。
B. Internal structure of the
4 is a block diagram showing the internal structure of the
診察データ作成部２０は、患者を診察した診療録を読み込んでデータ化することによって診察データを作成し、作成した診察データを診察データ出力部２１に出力する。診察データ出力部２１はデータサーバ４に接続されており、診察データ作成部２０から受け取った診察データをデータサーバ４に記憶する。
The examination
メッセージ受信部２２は、インターネットなどの通信回線５に接続されており、通信回線５を介して送信されてきたメッセージを受信すると、そのメッセージを署名認証部２３および特定情報取得部２５に出力する。詳細には後述するが、メッセージ受信部２２が受信するメッセージには、要求ノード２ａから送信された診察データの閲覧を要求するための要求メッセージなどが含まれる。
The
署名認証部２３は、受け取ったメッセージに署名が含まれていた場合には、その署名を認証する。尚、メッセージに患者の署名が含まれている場合は、その署名を署名認証部２３が認証するから、本実施例の署名認証部２３は本発明における「患者署名認証部」に対応する。そして、認証が通った場合は、認証の結果をメッセージ作成部２４および特定情報取得部２５に出力する。
If a signature is included in the received message, the
メッセージ作成部２４は、認証が通った旨の結果を受け取ると、受け取っていたメッセージに対応するメッセージを作成する。例えば、要求ノード２ａからの要求メッセージを受け取っていた場合には、閲覧許諾のブロックデータ１０の作成を依頼する依頼メッセージを作成する。また、作成ノード２ｂに対して診察データの閲覧を要求する場合には、要求メッセージを作成する。これらのメッセージを作成するためには所定の情報（以下、特定情報）が必要となるが、これらの特定情報は特定情報取得部２５から供給される。すなわち、特定情報取得部２５は、署名認証部２３での認証が通った旨の通知を受け取ると、メッセージ受信部２２から受け取っていたメッセージの中から特定情報を抽出して、メッセージ作成部２４に出力するようになっている。尚、診察ノード２が作成ノード２ｂである場合は、メッセージ作成部２４が依頼メッセージを作成するから、本実施例のメッセージ作成部２４は本発明における「依頼メッセージ作成部」に対応する。
When the
メッセージ作成部２４は、こうして作成したメッセージをメッセージ送信部２６に出力する。メッセージ送信部２６は通信回線５に接続されており、通信回線５に接続された診察ノード２や認証ノード３に向かってメッセージを送信する。尚、診察ノード２が要求ノード２ａである場合は、メッセージ送信部２６が要求メッセージを送信し、診察ノード２が作成ノード２ｂである場合は、メッセージ送信部２６が依頼メッセージを送信するから、本実施例のメッセージ作成部２４は本発明における「要求メッセージ送信部」および「依頼メッセージ送信部」に対応する。
The
また、ブロックデータ受信部２７も通信回線５に接続されており、認証ノード３から送信されてきた新たなブロックデータ１０を受信すると、そのブロックデータ１０をブロックデータ記憶部２８に出力する。ブロックデータ記憶部２８は、ブロックデータ受信部２７から新たなブロックデータ１０を受け取ると、図２を用いて前述したブロックチェーン形式で記憶する。
The block
また、図５は、本実施例の閲覧手続管理システム１を形成する認証ノード３の内部構造を示したブロック図である。図示されるように、認証ノード３の内部には、メッセージ受信部３０や、署名認証部３１、ブロックデータ作成部３２、特定情報取得部３３、ブロックデータ送信部３４、ブロックデータ記憶部３５などが搭載されている。尚、これらの「部」も、認証ノード３に搭載されている機能を表す抽象的な概念であり、これらの「部」に対応する部品が存在することを示しているわけではない。これらの「部」は、認証ノード３に内蔵されたマイクロコンピュータで実行されるソフトウェアプログラムとして実現することもできるし、診察ノード２に搭載されたＬＳＩやＩＣなどによるハードウェアとして実現することもできる。更には、ソフトウェアプログラムとハードウェアとを組み合わせることによって実現しても良い。
Figure 5 is a block diagram showing the internal structure of the
認証ノード３のメッセージ受信部３０は、インターネットなどの通信回線５に接続されており、通信回線５を介して送信されてきたメッセージを受信すると、そのメッセージを署名認証部３１および特定情報取得部３３に出力する。詳細には後述するが、認証ノード３のメッセージ受信部３０には、患者端末６からの登録申請メッセージや、診察ノード２からの登録メッセージや依頼メッセージなど送信されてくる。
The
認証ノード３の署名認証部３１は、メッセージ受信部３０から受け取ったメッセージに署名が含まれていた場合には、その署名を認証する。尚、詳細には後述するが、受け取ったメッセージが作成ノード２ｂからの依頼メッセージであった場合には、その作成ノード２ｂの署名が含まれているので、作成ノード２ｂの署名を認証することになる。従って、本実施例の署名認証部３１は本発明における「作成ノード署名認証部」に対応する。そして、認証が通った場合は、認証の結果をブロックデータ作成部３２および特定情報取得部３３に出力する。また、メッセージ受信部３０から受け取ったメッセージが患者端末６からの登録申請メッセージであった場合には、そのメッセージに含まれている患者の署名を認証することになる。
If the message received from the
ブロックデータ作成部３２は、メッセージに含まれる署名の認証が通った旨の結果を受け取ると、メッセージに対応するブロックデータ１０を作成する。ブロックデータ１０を作成するためには所定の特定情報が必要となるが、これらの特定情報は特定情報取得部３３から供給される。すなわち、特定情報取得部３３は、署名認証部３１での認証が通った旨の通知を受け取ると、メッセージ受信部３０から受け取っていたメッセージの中から特定情報を抽出して、ブロックデータ作成部３２に出力するようになっている。ブロックデータ作成部３２は、こうして受け取った特定情報に基づいてブロックデータ１０を作成する。また、閲覧手続管理システム１には複数の認証ノード３が存在するが（図１参照）、それぞれの認証ノード３のブロックデータ作成部３２でブロックデータ１０が作成される。そこで、それぞれの認証ノード３のブロックデータ作成部３２は、作成したブロックデータ１０の内容を互いに照合し、齟齬が生じている内容については多数決による合意によって内容を決定してブロックデータ１０を確定させる。
When the block
ブロックデータ作成部３２は、こうして確定させたブロックデータ１０をブロックデータ送信部３４およびブロックデータ記憶部３５に出力する。ブロックデータ送信部３４は通信回線５に接続されており、通信回線５に接続された複数の診察ノード２に向かってブロックデータ１０を送信する。こうして送信されたブロックデータ１０は、図４を用いて前述した診察ノード２のブロックデータ受信部２７で受診されて、ブロックデータ記憶部２８にブロックチェーン形式で記憶される。
The block
本実施例の閲覧手続管理システム１は、上述した内部構造を有する複数の診察ノード２および認証ノード３が通信回線５で接続されており、診察ノード２および認証ノード３が以下のように動作することによって実現されている。
The browsing
Ｃ．患者端末６の登録動作 ：
本実施例の閲覧手続管理システム１では、診察ノード２で診察を受ける患者が、閲覧手続管理システム１に対して自らをあらかじめ登録しておく必要がある。閲覧手続管理システム１に患者を登録する際には、患者の患者端末６および認証ノード３で次のような処理が実行される。
C. Registration operation of patient terminal 6:
In the browsing
図６は、診察ノード２で診察を受ける患者が閲覧手続管理システム１に登録する際に、患者端末６および認証ノード３で実行される処理を示した説明図である。図示されるように、閲覧手続管理システム１に患者を登録する際には、患者端末６では登録申請処理が実行され、認証ノード３では登録受付処理が実行される。患者端末６の登録申請処理では、先ず始めに患者端末６に専用のアプリケーション（以下、専用アプリ）をインストールする（ＳＴＥＰ１０）。続いて、インストールした専用アプリを起動させて、秘密鍵および公開鍵を作成する（ＳＴＥＰ１１）。患者が自分専用の秘密鍵を作成すると、秘密鍵と対になる公開鍵を専用アプリが自動的に生成する。尚、本実施例では、患者端末６に専用アプリをインストールしておき、専用プリを用いて秘密鍵および公開鍵を作成するものとして説明するが、これに限らず、例えば、患者端末６の閲覧用アプリ（Ｗｅｂブラウザなど）上で動作する拡張アプリケーションを用いて秘密鍵および公開鍵を作成しても良い。
Figure 6 is an explanatory diagram showing the processing executed by the
その後、患者が専用アプリを用いて、閲覧手続管理システム１への登録を申請する旨の意思表示のメッセージ（登録申請メッセージ）を作成すると（ＳＴＥＰ１２）、専用アプリが秘密鍵を用いて登録申請メッセージに署名した後、公開鍵と一緒に、閲覧手続管理システム１に対して送信する（ＳＴＥＰ１３）。すると、このメッセージは閲覧手続管理システム１の認証ノード３によって受診される。
After that, when the patient uses the dedicated app to create a message (registration request message) expressing his/her intention to apply for registration in the browsing procedure management system 1 (STEP 12), the dedicated app signs the registration request message using the private key and then sends it together with the public key to the browsing procedure management system 1 (STEP 13). This message is then received by the
認証ノード３では、以下のような登録受付処理が行われる。先ず、患者端末６から送信されてきた登録申請メッセージを受信する（ＳＴＥＰ２０）。続いて、登録申請メッセージの署名を認証する（ＳＴＥＰ２１）。すなわち、患者端末６から送信されてきた登録申請メッセージは公開鍵と一緒に送信されており、登録申請メッセージは患者の秘密鍵によって署名されている。そこで、署名されたメッセージを公開鍵で復号することによって、登録申請メッセージが正しく復号できた場合、そのメッセージは、同時に送られてきた公開鍵と対になる秘密鍵を有する人（ここでは、患者）によって署名されたことになる。しかも、メッセージの内容は、閲覧手続管理システム１への登録を申請する旨の意思を表示する内容となっている。従って、認証が通っていれば、確かに患者が閲覧手続管理システム１への登録を申請していると考えて良い。
In the
そこで、認証が通った場合は（ＳＴＥＰ２２：ｙｅｓ）、閲覧手続管理システム１上での患者のアドレス（以下、患者アドレス）を設定して、そのアドレスを患者端末６に返信する（ＳＴＥＰ２３）。患者端末６では、こうして返信されてきた患者アドレスを受け取ると、患者端末６内に記憶した後（ＳＴＥＰ１４）、登録申請処理を終了する。
If the authentication is successful (STEP 22: yes), the patient's address on the viewing procedure management system 1 (hereinafter, the patient address) is set, and the address is returned to the patient terminal 6 (STEP 23). When the
また、認証ノード３では、患者アドレスを患者端末６に返信した後は（ＳＴＥＰ２３）、患者アドレスを登録するためのブロックデータ１０を作成して、他の認証ノード３との合意の元で、そのブロックデータ１０を全ての診察ノード２に送信した後（ＳＴＥＰ２４）、登録受付処理を終了する。尚、ＳＴＥＰ２４でブロックデータ１０を送信する際に、認証ノード３自身もそのブロックデータ１０を記憶しておく。その結果、診察ノード２（および認証ノード３）内には、患者アドレスを登録するブロックデータ１０がブロックチェーン形式で記憶される。図２中のブロックデータ１０（ｅ）は、このようにして記憶されたものである。これに対して、認証が通らなかった場合は（ＳＴＥＰ２２：ｎｏ）、患者端末６に向かってエラーメッセージを送信して（ＳＴＥＰ２５）、登録受付処理を終了する。
After the
尚、上述した説明では、患者端末６側で作成した登録申請メッセージに署名して、認証ノード３に送信するものとした。しかし、患者端末６からは署名を付けずに登録申請メッセージを送信してもよい。そして、そのメッセージを受け取った認証ノード３は、署名用のチャレンジコードなどを患者端末６に返信して、そのチャレンジコードに署名して患者端末６から認証ノード３に返信するようにしてもよい。
In the above explanation, the registration request message created on the
また、上述した説明では、患者端末６の専用アプリを起動させる際には、認証は不要としているが、例えばパスワードを用いた認証や生体認証が通らなければ、専用アプリが起動しないようにしても良い。こうすれば、第三者が勝手に登録を申請したり、登録した公開鍵を変更したりする事態を回避することができる。
In the above explanation, authentication is not required when starting the dedicated app on the
Ｄ．診察データの登録動作 ：
図７は、患者を診察した診察ノード２が診察データを閲覧手続管理システム１に登録する際に、診察ノード２および認証ノード３で実行される処理を示した説明図である。図示されるように、閲覧手続管理システム１に診察データを登録する際には、診察ノード２では診察データ送信処理が実行され、認証ノード３では診察データ登録処理が実行される。診察データ送信処理では、先ず始めに診療録をデータ化することによって診察データを作成して、その診察データをデータサーバ４に記憶する（ＳＴＥＰ３０）。続いて、記憶した診察データを特定するための情報（以下、診察データ特定情報）を取得する（ＳＴＥＰ３１）。診察データ特定情報とは、後日にデータサーバ４から診察データを読み出す際に、診察データを特定するための情報である。診察データ特定情報としては、診察データを保存した場所を示すＵＲＬ（Ｕniform Ｒesouce Ｌocation ）や、診察データに固有の名称であるＵＲＮ（Ｕniform Ｒesouce Ｎame ）などを用いることができる。
D. Registration of medical examination data:
7 is an explanatory diagram showing the process executed by the
診察データ特定情報を取得したら、その情報のハッシュ値を算出する（ＳＴＥＰ３２）。前述したようにハッシュ値とは、任意のデータにハッシュ関数を作用させることによって得られる値であり、ハッシュ値と元のデータとの間には一対一の関係がある。ハッシュ値が得られたら、そのハッシュ値に対して、診察ノード２の秘密鍵を用いて署名する（ＳＴＥＰ３３）。診察ノード２は閲覧手続管理システム１に登録する際に、秘密鍵および公開鍵を生成しており、公開鍵については閲覧手続管理システム１に登録されている。
Once the examination data specific information is obtained, a hash value of that information is calculated (STEP 32). As described above, a hash value is a value obtained by applying a hash function to any data, and there is a one-to-one relationship between the hash value and the original data. Once the hash value is obtained, the hash value is signed using the private key of the examination node 2 (STEP 33). When the
続いて、診察データの対象患者の患者アドレスを取得する（ＳＴＥＰ３４）。患者アドレスとは、患者が閲覧手続管理システム１に登録することによって付与される患者に固有のアドレスであり、患者の患者端末６の専用アプリ内に記憶されている（図６のＳＴＥＰ１４参照）。患者アドレスは、患者端末６の画面に表示されたアドレスを見ながら、診察ノード２の画面上で手入力しても良いし、患者端末６と診察ノード２との間で通信することによって患者アドレスを取得しても良い。
Next, the patient address of the patient for whom the medical examination data is to be processed is obtained (STEP 34). The patient address is a unique address given to the patient when the patient registers with the viewing
以上のような準備が終わったら、以下のような情報を含む登録メッセージ（すなわち、診察データの登録を申請するメッセージ）を作成して、閲覧手続管理システム１に送信する（ＳＴＥＰ３５）。図８は、登録メッセージに含まれる情報を示した説明図である。図示されるように、登録メッセージには、患者アドレスと、診察ノード特定情報と、診察データ特定情報と、診察ノードの署名を付けたハッシュ値とが含まれている。ここで、患者アドレスや、診察データ特定情報や、署名を付けたハッシュ値は、図７のＳＴＥＰ３４や、ＳＴＥＰ３１や、ＳＴＥＰ３２で取得されている。また、診察ノード特定情報とは、診察ノード２が自らを特定する情報（例えば、診察ノード２の閲覧手続管理システム１上でのアドレス）であり、診察ノード２は閲覧手続管理システム１に登録する際に設定された情報を記憶している。図７のＳＴＥＰ３５では、これらの情報を含んだ登録メッセージを作成して、閲覧手続管理システム１に送信する。そして、送信後は、一定時間が経過するまで待機することによって、後述するエラーメッセージが戻って来ないことを確認した後、診察データ送信処理を終了する。
After the above preparations are completed, a registration message (i.e., a message requesting registration of medical examination data) containing the following information is created and sent to the browsing procedure management system 1 (STEP 35). FIG. 8 is an explanatory diagram showing the information contained in the registration message. As shown in the figure, the registration message contains the patient address, medical examination node identification information, medical examination data identification information, and a hash value with the signature of the medical examination node. Here, the patient address, medical examination data identification information, and the hash value with the signature are acquired in
また、診察ノード２が閲覧手続管理システム１に送信した登録メッセージは、認証ノード３によって受信される。そして、登録メッセージを受け取った認証ノード３では、以下のような診察データ登録処理が実行される。先ず、登録メッセージに含まれる署名を認証する（ＳＴＥＰ４０）。前述したように、登録メッセージには、診察ノード特定情報や、診察データ特定情報や、診察データ特定情報の署名付きのハッシュ値が含まれている。そこで、署名付きのハッシュ値を、診察ノード特定情報に基づいて取得した診察ノード２の公開鍵を用いて復号する。また、登録メッセージには診察データ特定情報が含まれているので、その診察データ特定情報のハッシュ値を算出する。そして、算出したハッシュ値と、復号して得られたハッシュ値とを比較して、一致していれば認証が通ったものと判断し（ＳＴＥＰ４１：ｙｅｓ）、一致していなければ認証が通っていないものと判断する（ＳＴＥＰ４１：ｎｏ）。
The registration message sent by the
その結果、認証が通った場合は（ＳＴＥＰ４１：ｙｅｓ）、診察データのブロックデータ１０を作成する（ＳＴＥＰ４２）。図９は、認証ノード３によって作成されるブロックデータ１０を示した説明図である。図８に示したデータ（登録メッセージに含まれている情報）と、図９のブロックデータ１０とを比較すれば明らかなように、図９のブロックデータ１０は、登録メッセージに含まれる情報から、署名付きのハッシュ値を削除して、「受診通し番号」を加えたデータの組（以下、データ組１１と称する）に、前のブロックデータのハッシュ値を追加した内容となっている。
As a result, if the authentication passes (STEP 41: yes),
ここで、受診通し番号とは、患者アドレスの患者にとって（何れの診察ノード２であるかを問わずに）何回目の受診であるかを示す番号である。すなわち、図２中のブロックデータ１０ａやブロックデータ１０ｂに例示するように、診察ノード２や認証ノード３には、患者が診察ノード２で受診して診察データが作成される度に、ブロックチェーン形式でブロックデータ１０が記憶されており、そのブロックデータ１０には、対象患者の患者アドレスが含まれている。従って、認証ノード３は、記憶している複数のブロックデータ１０を検索することで、患者アドレス毎に受診回数を調べることができ、今回の受診が、その患者にとって何回目の受診であるかも調べることができる。仮に、今回の受診がＮ回目であったとすれば、受診通し番号はＮとなる。図７のＳＴＥＰ４２では、こうして生成したデータ組１１に前のブロックデータ１０のハッシュ値を追加することによって、診察データを登録するためのブロックデータ１０を作成する。
Here, the visit serial number is a number indicating the number of visits (regardless of which medical examination node 2) for the patient of the patient address. That is, as exemplified by
こうしてブロックデータ１０を作成したら、他の認証ノード３との合意の元で、そのブロックデータ１０を全ての診察ノード２に送信した後（ＳＴＥＰ４３）、登録受付処理を終了する。その結果、診察ノード２内には、診察データを登録するブロックデータ１０がブロックチェーン形式で記憶される。また、ＳＴＥＰ４３でブロックデータ１０を診察ノード２に送信する際には、認証ノード３自身も、そのブロックデータを記憶する。認証ノード３は、こうしてブロックデータ１０を送信すると共に自らも記憶した後、診察データ登録処理を終了する。
Once the
以上のように、患者が診察ノード２を受診して、診察ノード２が診察データを作成すると、以上のような手続きを踏むことによって、図２中のブロックデータ１０ａやブロックデータ１０ｂに例示するようなブロックデータ１０が診察ノード２や認証ノード３内に記憶される。また、患者を診察する診察ノード２が、別の診察ノード２で作成された診察データを閲覧する必要が生じた場合には、以下のような手続きを踏むことによって、図２中のブロックデータ１０ｃに例示するようなブロックデータ１０（すなわち、閲覧許諾のブロックデータ１０）が作成される。
As described above, when a patient visits the
Ｅ．診察データの閲覧要求動作 ：
図１０～図１２は、閲覧許諾のブロックデータ１０を作成して、診察ノード２や認証ノード３に記憶する際に実行される処理を示した説明図である。図１０には、要求ノード２ａ（診察データの閲覧を要求する診察ノード２）と、対象患者（閲覧しようとする診察データの患者）の患者端末６との間で実行される処理が示されており、図１１には、要求ノード２ａと作成ノード２ｂ（閲覧しようとする診察データを作成した診察ノード２）との間で実行される処理が示されている。そして、図１２には、作成ノード２ｂと認証ノード３との間で実行される処理が示されている。
E. Request to view medical data:
10 to 12 are explanatory diagrams showing the processing executed when creating
図１０に示されるように、閲覧許諾のブロックデータ１０を作成する際には、先ず始めに要求ノード２ａで閲覧要求処理が開始され、それに合わせて患者端末６では署名処理が開始される。要求ノード２ａは閲覧要求処理を開始すると、承諾メッセージを作成する（ＳＴＥＰ６０）。図１３は、承諾メッセージの文面を例示した説明図である。図示されるように、承諾メッセージは、要求ノード２ａが対象診察データ（閲覧しようとしている診察データ）を閲覧することを、対象患者が承諾する内容となっている。要求ノード２ａは承諾メッセージを作成すると、対象患者の患者端末６に送信する（ＳＴＥＰ６１）。
As shown in FIG. 10, when creating
尚、閲覧の態様には、画面上で診察データの内容を確認することはできるが、閲覧者の元には診察データが保存されない態様と、画面上で確認した診察データが閲覧者の手元に保存されて再び確認可能な態様と、単純に診察データを送信して貰う態様などを考えることができる。本明細書中で「閲覧」とは、上記の何れの態様も含んだ概念である。 Note that possible modes of viewing include a mode in which the contents of the medical examination data can be confirmed on the screen, but the medical examination data is not saved to the viewer, a mode in which the medical examination data confirmed on the screen is saved to the viewer so that it can be confirmed again, and a mode in which the medical examination data is simply sent to the viewer. In this specification, "viewing" is a concept that includes all of the above modes.
対象患者の患者端末６では、承諾メッセージを受信すると、署名処理が開始される。署名処理では、患者端末６の画面上に承諾メッセージを表示する（ＳＴＥＰ５０）。対象患者は、表示された承諾メッセージの内容を確認して、内容に異存が無ければ、承諾した日付を記入した後、閲覧期限を設定する（ＳＴＥＰ５１）。そして、閲覧手続管理システム１への登録時に作成した秘密鍵を用いて承諾メッセージに署名した後（ＳＴＥＰ５２）、要求ノード２ａに返信する（ＳＴＥＰ５３）。返信後は、一定時間が経過するまで待機することによって、後述するエラーメッセージが戻って来ないことを確認した後、署名処理を終了する。尚、本実施例の承諾メッセージは、本発明における「署名用データ」に対応する。
When the
要求ノード２ａの閲覧要求処理では、患者端末６から返信されてきた署名付きの承諾メッセージを受け取ると、対象患者の公開鍵を用いて認証する（ＳＴＥＰ６２）。対象患者の公開鍵は、閲覧手続管理システム１に登録する際に、全ての診察ノード２にブロックデータ１０として記憶されている。そこで、要求ノード２ａはその公開鍵を用いて署名付きの承諾メッセージを復号して、正しく復号されているか否かを確認することによって認証する（ＳＴＥＰ６３）。その結果、正しく復号されている場合は、認証が通ったものと判断して（ＳＴＥＰ６３：ｙｅｓ）、今後は作成ノード２ｂとの間で、以下のような処理を開始する。これに対して、正しく復号されていなかった場合は、認証が通らなかったものと判断して（ＳＴＥＰ６３：ｎｏ）、その旨のエラーメッセージを患者端末６に送信した後（ＳＴＥＰ６４）、閲覧要求処理を終了する。
In the
要求ノード２ａは、患者端末６の署名付きの承諾メッセージの認証が通ると（ＳＴＥＰ６３：ｙｅｓ）、今度は、その署名付きの承諾メッセージを、自分の秘密鍵を用いて署名する（図１１のＳＴＥＰ６５）。すなわち、承諾メッセージは、患者端末６および要求ノード２ａによって二重署名されることになる。
When the authentication of the signed consent message from the
続いて、閲覧を要求する診察データを特定するために、患者アドレスの受診通し番号を選択する（ＳＴＥＰ６６）。すなわち、作成ノード２ｂのデータサーバ４に対象患者の診察データが多数記憶されている場合、必ずしも全ての診察データを閲覧する必要があるとは限らないので、患者アドレスの受診通し番号を選択することによって、閲覧を要求する診察データを特定する。また、受診通し番号を選択しない場合は、全ての診察データの閲覧を要求しているものと見なされる。
Next, the patient's serial number is selected in order to identify the medical examination data that is requested to be viewed (STEP 66). In other words, when a large amount of medical examination data for the target patient is stored in the
以上のような準備が終わったら、以下のような情報を含む要求メッセージ（すなわち、診察データの閲覧を要求するメッセージ）を作成して、作成ノード２ｂに送信する（ＳＴＥＰ６７）。図１４は、要求メッセージに含まれる情報を示した説明図である。図示されるように、要求メッセージには、患者アドレスと、受診通し番号と、要求ノード特定情報と、承諾メッセージと、対象患者および要求ノード２ａによって二重署名された承諾メッセージと、閲覧期限とが含まれている。ここで、要求ノード特定情報とは、要求ノード２ａが自らを特定する情報（例えば、要求ノード２ａの閲覧手続管理システム１上でのアドレス）である。また、患者アドレスは、患者を診察する際に患者の患者端末６から取得することができる。更に、承諾メッセージは要求ノード２ａが図１０のＳＴＥＰ６０で作成したメッセージであり、二重署名された承諾メッセージや、受診通し番号は、図１１のＳＴＥＰ６５およびＳＴＥＰ６６で取得している。加えて、閲覧期限は、図１０のＳＴＥＰ６２で患者端末６の署名付きの承諾メッセージを認証した際に取得している。そこで、診察データの閲覧を要求し、且つ、これらの情報を含んだ要求メッセージを作成して、閲覧手続管理システム１の作成ノード２ｂに送信する（ＳＴＥＰ６７）。そして、送信後は、一定時間が経過するまで待機することによって、後述するエラーメッセージが戻って来ないことを確認した後、閲覧要求処理を終了する。
After the above preparations are completed, a request message (i.e., a message requesting viewing of medical examination data) containing the following information is created and sent to the
尚、ここでは、要求ノード２ａが自らを特定するために、要求ノード特定情報を含めた要求メッセージを作成ノード２ｂに送信するものとして説明している。しかし、作成ノード２ｂは、送信されてきた要求メッセージのヘッダ部分を解析することによって、要求ノード特定情報を取得することができる。従って、要求ノード特定情報は、実質的に要求メッセージに含まれていれば良く、明示的に含まれている必要はない。
Note that, in this example, the
また、作成ノード２ｂでは、要求ノード２ａから送信されてきた要求メッセージを受信すると、以下のような閲覧許諾処理を開始する。先ず、受信した要求メッセージには、対象患者と要求ノード２ａとによって二重署名された承諾メッセージが含まれているので、その二重署名を認証する（ＳＴＥＰ７０）。すなわち、初めに要求ノード２ａの公開鍵を用いて、二重署名された承諾メッセージを復号し、復号した結果を更に対象患者の公開鍵を用いて復号する。要求ノード２ａから受信した要求メッセージには要求ノード特定情報や患者アドレスが含まれているので、要求ノード２ａの公開鍵や対象患者の公開鍵は取得することができる。
Furthermore, when the
こうして２つの公開鍵を用いて復号した結果が、元の承諾メッセージと一致した場合は、認証が通ったものと判断することができる（ＳＴＥＰ７１：ｙｅｓ）。尚、本実施例では、復号して得られたメッセージが、承諾メッセージと一致するか否かによって、認証が通ったか否かを判断しているが、復号した結果、意味を成す承諾メッセージが得られた場合は認証が通ったものと判断し、意味を成さない文字列しか得られなかった場合は、認証が通らなかったものと判断しても良い。こうすれば、要求ノード２ａが送信する要求メッセージに、承諾メッセージを含める必要がなくなるので、要求メッセージのデータ量を小さくすることができる。
If the result of decryption using the two public keys in this way matches the original acceptance message, it can be determined that authentication has passed (STEP 71: yes). Note that in this embodiment, whether authentication has passed is determined based on whether the decrypted message matches the acceptance message, but it is also possible to determine that authentication has passed if a meaningful acceptance message is obtained as a result of decryption, and that authentication has not passed if only a meaningless character string is obtained. In this way, it is no longer necessary to include the acceptance message in the request message sent by
認証が通っていれば、作成ノード２ｂは、確かに要求ノード２ａが対象患者から承諾を得た上で、診察データの閲覧を要求していることを確認できたことになる。これに対して、一致しなかった場合は、認証が通らなかったものと判断することができる（ＳＴＥＰ７１：ｎｏ）。認証が通らなかった場合は、要求ノード２ａが対象患者の承諾を得ずに勝手に診察データの閲覧を要求しているか、要求ノード２ａではない何者かが要求ノード２ａと偽って診察データの閲覧を要求している可能性がある。そこで、認証が通らなかった場合は（ＳＴＥＰ７１：ｎｏ）、要求ノード２ａに対して認証が通らない旨のエラーメッセージを送信して（ＳＴＥＰ７２）、閲覧許諾処理を終了する。
If the authentication is successful, the
これに対して、認証が通った場合は（ＳＴＥＰ７１：ｙｅｓ）、対象患者の署名付きの承諾メッセージを、今度は作成ノード２ｂの秘密鍵を用いて署名することによって、対象患者および作成ノード２ｂによる二重署名を作成する（ＳＴＥＰ７３）。対象患者の署名付きの承諾メッセージは、ＳＴＥＰ７０で、対象患者および要求ノード２ａによる二重署名を認証した際に取得されている。
On the other hand, if the authentication passes (STEP 71: yes), the consent message signed by the target patient is then signed using the private key of
その後、必要な情報を含む依頼メッセージを作成する（ＳＴＥＰ７４）。ここで、依頼メッセージとは、認証ノード３に対して閲覧許諾のブロックデータ１０の作成を依頼するメッセージである。また、依頼メッセージには、図１５に示した一組の情報が含まれている。図１４と図１５とを比較すれば明らかなように、図１５の一組の情報は、図１４の情報（すなわち、要求ノード２ａの要求メッセージに含まれていた情報）に対して、作成ノード２ｂを特定するための情報（以下、作成ノード特定情報）が追加されると共に、「患者と要求ノード２ａによる二重署名」が「患者と作成ノード２ｂによる二重署名」に変更されたものとなっている。作成ノード特定情報としては、閲覧手続管理システム１上での作成ノード２ｂのアドレスなどを用いることができる。
Then, a request message including the necessary information is created (STEP 74). Here, the request message is a message that requests the
尚、図１５に示した一組の情報には、患者アドレスおよび患者アドレスの受診通し番号が含まれているので、これらの情報に基づいて、対象診察データ（すなわち、要求ノード２ａが閲覧を要求している診察データ）を特定することができる。しかし、対象診察データを直接的に特定するための診察データ特定情報（例えば、前述したＵＲＬやＵＲＮなど）を追加しても良い。作成ノード２ｂは、これらの情報を含んだ依頼メッセージを作成する。
The set of information shown in FIG. 15 includes the patient address and the patient address's consultation serial number, so the target medical examination data (i.e., the medical examination data that the
また、本実施例の作成ノード２ｂは、要求ノード２ａから送信されてきた要求メッセージに、図１４に示した各種の情報が含まれているので、それらの情報を用いて、図１５に示した一組の情報を作成するものとして説明した。しかし、要求メッセージに含まれる二重署名の認証が通った場合には（図１１のＳＴＥＰ７１：ｙｅｓ）、作成ノード２ｂが自ら調べることによって、これらの情報を取得するようにしても良い。この場合は、要求メッセージには、作成ノード２ｂでは取得が困難な情報（例えば、患者アドレスや、受信通し番号や、対象患者および作成ノード２ｂによる二重署名など）を含めておけば良い。
In the present embodiment, the
作成ノード２ｂは、こうして依頼メッセージを作成したら、依頼メッセージを閲覧手続管理システム１の認証ノード３に送信する（図１２のＳＴＥＰ７５）。そして、送信後は、一定時間が経過するまで待機することによって、後述するエラーメッセージが戻って来ないことを確認した後、閲覧許諾処理を終了する。
After creating the request message in this way, the
認証ノード３は、以上のようにして作成ノード２ｂから送信されてきた依頼メッセージを受信すると、以下のような閲覧許諾登録処理を開始する。先ず、受信した依頼メッセージには、対象患者と作成ノード２ｂとによって二重署名された承諾メッセージが含まれている。そこで、対象患者の公開鍵および作成ノード２ｂの公開鍵を用いて、作成ノード２ｂがＳＴＥＰ７０で認証した時と同様な方法によって、二重署名された承諾メッセージを認証する（ＳＴＥＰ８０）。そして、認証が通ったか否かを判断して（ＳＴＥＰ８１）、認証が通らなかった場合は（ＳＴＥＰ８１：ｎｏ）、作成ノード２ｂに対して認証が通らない旨のエラーメッセージを送信して（ＳＴＥＰ８２）、閲覧許諾登録処理を終了する。
When the
これに対して、認証が通った場合は（ＳＴＥＰ８１：ｙｅｓ）、要求ノード２ａが診察データを閲覧することに、対象患者も作成ノード２ｂも同意していることを確認できたことになる。そこで、認証ノード３は、閲覧許諾のブロックデータ１０を作成する（ＳＴＥＰ８３）。ここで、閲覧許諾のブロックデータ１０とは、要求ノード２ａに閲覧権限を設定するブロックデータ１０である。図１６には、認証ノード３によって作成される閲覧許諾のブロックデータ１０を示した説明図である。図１５に示したデータ（要求メッセージに含まれている情報）と、図１６のブロックデータ１０とを比較すれば明らかなように、図１６の閲覧許諾のブロックデータ１０は、要求メッセージに含まれていた一組のデータの組（以下、データ組１２）に、前のブロックデータのハッシュ値を追加した内容となっている。
On the other hand, if the authentication is successful (STEP 81: yes), it is confirmed that both the target patient and the
認証ノード３は、こうして閲覧許諾のブロックデータ１０を作成したら、他の認証ノード３との合意の元で、その閲覧許諾のブロックデータ１０を全ての診察ノード２に送信する（ＳＴＥＰ４３）。その結果、診察ノード２内には、閲覧許諾のブロックデータ１０がブロックチェーン形式で記憶される。また、認証ノード３は、ＳＴＥＰ８４で閲覧許諾のブロックデータ１０を送信する際に、認証ノード３自身もそのブロックデータを記憶する。こうして閲覧許諾のブロックデータ１０を送信すると共に自らも記憶したら（ＳＴＥＰ８４）、要求ノード２ａおよび作成ノード２ｂに向けて閲覧用パスワードを送信した後（ＳＴＥＰ８５）、閲覧許諾登録処理を終了する。
After creating the
要求ノード２ａは、閲覧用パスワードを受け取ると、作成ノード２ｂに対して確認用パスワードを提示することにより、対象診察データを閲覧することができる。要求ノード２ａおよび作成ノード２ｂは、お互いにブロックチェーン形式で記憶している閲覧許諾のブロックデータ１０を参照することで、対象患者の承諾が得られており、作成ノード２ｂも許諾していることを確認することができるので、安心して診察データを作成ノード２ｂに要求し、また、診察データを要求ノード２ａに提供することができる。
When the requesting
加えて、閲覧許諾のブロックデータ１０は、閲覧手続管理システム１を形成する全ての診察ノード２および認証ノード３に、ブロックチェーン形式で記憶されているので、後から改竄することは事実上、不可能である。従って、要求ノード２ａにとっては、対象患者および作成ノード２ｂの同意の元で診察データを閲覧したことを、後日に確実に立証することができる。また、作成ノード２ｂにとっても、対象患者の承諾を得た上で、要求ノード２ａの要求に応じて診察データを提供したことを、後日に確実に立証することができる。その結果、予期せぬ訴訟に巻き込まれる虞が無くなるため、それぞれの診察ノード２のデータサーバ４に記憶されている診察データを、診察ノード２間で有効活用することが可能となる。そして、このように大きな利点が得られるにも拘わらず、要求ノード２ａにとっては、単に診察データの閲覧を要求し、作成ノード２ｂにとっては要求を許諾する手続きを、閲覧手続管理システム１を介して行っているだけなので、要求ノード２ａおよび作成ノード２ｂの何れにとっても、大きな負担になることも無い。
In addition, since the
Ｆ．変形例 ：
上述した本実施例には幾つかの変形例を考えることができる。以下ではこれらの変形例について、本実施例との相違点を中心として簡単に説明する。
F. Variations:
Several modifications of the present embodiment described above are possible. These modifications will be briefly described below, focusing on the differences from the present embodiment.
Ｆ－１．第１変形例 ：
上述した本実施例では、要求ノード２ａが作成する要求メッセージには、対象患者および要求ノード２ａによる二重署名が含まれているものとして説明した（図１４参照）。また、作成ノード２ｂが作成する依頼メッセージには、対象患者および作成ノード２ｂによる二重署名が含まれているものとして説明した（図１５参照）。しかし、図１４の要求メッセージについては対象患者と要求ノード２ａとが署名していれば十分であり、図１５の依頼メッセージについては対象患者と作成ノード２ｂとが署名していれば十分である。従って、要求メッセージや依頼メッセージでの署名の方法などについては異なっていても良い。
F-1. First modified example:
In the above embodiment, the request message created by the
例えば、要求メッセージについては、図１４に示したように対象患者および要求ノード２ａが二重署名した承諾メッセージを含めるのではなく、図１７のように、対象患者による署名が付された承諾メッセージと、要求ノード２ａによる署名が付された承諾メッセージとを含む要求メッセージとしてもよい。すなわち、対象患者が署名する承諾メッセージは要求ノード２ａが対象患者に供給しているから、要求ノード２ａは署名前の承諾メッセージに対して署名することによって、自らの署名が付された承諾メッセージを作成することができる。従って、図１７に示すように、対象患者から受け取った署名付きの承諾メッセージと、自らの署名付きの承諾メッセージとを含んだ要求メッセージを作成してもよい。
For example, instead of including an acceptance message double-signed by the target patient and
また、依頼メッセージについては、図１５に示したように対象患者および作成ノード２ｂが二重署名した承諾メッセージを含めるのではなく、図１８のように、対象患者による署名が付された承諾メッセージと、作成ノード２ｂによる署名が付された承諾メッセージとを含む要求メッセージとしてもよい。すなわち、作成ノード２ｂは、要求メッセージに含まれる対象患者および要求ノード２ａの署名を認証するために、署名前の承諾メッセージも取得しているから（図１４参照）、作成ノード２ｂは署名前の承諾メッセージに対して署名することによって、自らの署名が付された承諾メッセージを作成することができる。従って、図１８に示すように、対象患者から受け取った署名付きの承諾メッセージと、自らの署名付きの承諾メッセージとを含んだ依頼メッセージを作成してもよい。
In addition, the request message may not include an acceptance message double-signed by the target patient and the
更に、署名の方法としては、上述した公開鍵と秘密鍵とを用いた方式の代わりに、他の署名方法を用いることもできる。例えば、患者の秘密鍵と作成ノード２ｂの秘密鍵とを用いて楕円曲線上で二重署名を行う方法（Ｅlliptic Ｃurve Ｄigital Ｓignature Ａlgorithm）が知られているので、この方法を用いてもよい。
Furthermore, as a signature method, other signature methods can be used instead of the above-mentioned method using a public key and a private key. For example, a method of performing a double signature on an elliptic curve using the private key of the patient and the private key of the creating
Ｆ－２．第２変形例 ：
上述した本実施例や第１変形例では、要求ノード２ａが作成する要求メッセージは、対象患者および要求ノード２ａの署名（すなわち、署名付きの承諾メッセージ）を含んだメッセージであるものとして説明した。同様に、作成ノード２ｂが作成する依頼メッセージは、対象患者および作成ノード２ｂの署名（すなわち、署名付きの承諾メッセージ）を含んだメッセージであるものとして説明した。しかし、要求メッセージや依頼メッセージは必ずしも署名を含んだメッセージでなくてもよい。
F-2. Second modified example:
In the above-described embodiment and the first modified example, the request message created by the
例えば、要求メッセージについては、対象患者および要求ノード２ａの署名を含まないメッセージとしておく。そして、要求ノード２ａが作成ノード２ｂに要求メッセージを送信する際には、図１９に示したように、署名を含まない要求メッセージに、対象患者および要求ノード２ａの二重署名（すなわち、二重署名付きの承諾メッセージ）を添付して送信してもよい。あるいは、対象患者および要求ノード２ａの二重署名の代わりに、対象患者の署名（すなわち、署名付きの承諾メッセージ）および要求ノード２ａの署名（すなわち、署名付きの承諾メッセージ）を添付して送信してもよい。
For example, the request message is a message that does not include the signatures of the target patient and the
また、依頼メッセージについても、対象患者および作成ノード２ｂの署名を含まないメッセージとしてもよい。そして、作成ノード２ｂが認証ノード３に依頼メッセージを送信する際には、図２０に示したように、署名を含まない依頼メッセージに、対象患者および作成ノード２ｂの二重署名（すなわち、二重署名付きの承諾メッセージ）を添付して送信してもよい。あるいは、対象患者および作成ノード２ｂの二重署名の代わりに、対象患者の署名（すなわち、署名付きの承諾メッセージ）および作成ノード２ｂの署名（すなわち、署名付きの承諾メッセージ）を添付して送信してもよい。
The request message may also be a message that does not include the signatures of the target patient and the
以上、本実施例および各種変形例の閲覧手続管理システム１について説明したが、本発明は上記の実施例および変形例に限られるものではなく、その要旨を逸脱しない範囲において種々の態様で実施することが可能である。
The above describes the present embodiment and various modified examples of the viewing
１…閲覧手続管理システム、 ２…診察ノード、 ２ａ…要求ノード、
２ｂ…作成ノード、 ３…認証ノード、 ４…データサーバ、
５…通信回線、 ６…患者端末、 １０…ブロックデータ、
１１…データ組、 １２…データ組、 ２０…診察データ作成部、
２１…診察データ出力部、 ２２…メッセージ受信部、 ２３…署名認証部、
２４…メッセージ作成部、 ２５…特定情報取得部、
２６…メッセージ送信部、 ２７…ブロックデータ受信部、
２８…ブロックデータ記憶部、 ３０…メッセージ受信部、
３１…署名認証部、 ３２…ブロックデータ作成部、 ３３…特定情報取得部、
３４…ブロックデータ送信部、 ３５…ブロックデータ記憶部。
1... Browsing procedure management system, 2... Medical examination node, 2a... Request node,
2b: creation node; 3: authentication node; 4: data server;
5...communication line, 6...patient terminal, 10...block data,
11...data set, 12...data set, 20...diagnosis data creation unit,
21: medical examination data output unit; 22: message receiving unit; 23: signature authentication unit;
24: Message creation unit; 25: Specific information acquisition unit;
26: message transmission unit; 27: block data reception unit;
28: block data storage unit; 30: message receiving unit;
31: Signature authentication unit; 32: Block data creation unit; 33: Specific information acquisition unit;
34: block data transmission unit; 35: block data storage unit.
Claims (2)
前記診察ノードは、
複数のブロックデータをブロックチェーン形式で記憶するブロックデータ記憶部と、
前記診察データを作成すると、前記診察ノードに接続されたデータベースに出力する診察データ出力部と
を備えており、
複数の前記診察ノードの中には、他の前記診察ノードで作成された前記診察データの閲覧を要求する要求ノードと、前記要求ノードから閲覧を要求された前記診察データである対象診察データを作成した作成ノードとが含まれており、
前記要求ノードは、前記作成ノードに対して前記対象診察データの閲覧を要求するメッセージであって、前記対象診察データの診察対象である対象患者の署名が付与された所定の署名用データを含むか、前記対象患者の署名が付与された前記署名用データが添付された前記メッセージである要求メッセージを作成すると、前記要求メッセージを前記作成ノードに送信する要求メッセージ送信部を有しており、
前記作成ノードは、
前記要求メッセージを受け取ると、前記要求メッセージと共に受け取った前記署名用データの前記対象患者の署名を認証する患者署名認証部と、
前記対象患者の署名の認証が成功した場合には、前記対象診察データを特定するための診察データ特定情報と、前記要求ノードを特定するための要求ノード特定情報とを取得する特定情報取得部と、
前記要求ノードが前記対象診察データを閲覧可能となる閲覧権限の設定を依頼するためのメッセージであって、前記診察データ特定情報と、前記要求ノード特定情報とを含むと共に、前記対象患者の署名付きの前記署名用データおよび前記作成ノードの署名付きの前記署名用データを更に含むか、前記対象患者の署名付きの前記署名用データおよび前記作成ノードの署名付きの前記署名用データが添付された前記メッセージである依頼メッセージを作成する依頼メッセージ作成部と、
前記依頼メッセージを前記認証ノードに送信する依頼メッセージ送信部と
を有しており、
前記認証ノードは、
前記依頼メッセージを受け取ると、前記対象患者の署名および前記作成ノードの署名を含み、前記要求ノードに対して前記対象診察データの閲覧権限を設定する前記ブロックデータを生成するブロックデータ生成部と、
生成した前記ブロックデータを複数の前記診察ノードに送信するブロックデータ送信部と
を備えることを特徴とする閲覧手続管理システム。 A viewing procedure management system that is formed by connecting a plurality of medical examination nodes that create medical examination data by examining a patient and store a plurality of block data in a block chain format with an authentication node that generates the block data and stores it in the medical examination nodes through a communication line, and that manages a procedure for viewing the medical examination data between the plurality of medical examination nodes,
The medical examination node includes:
A block data storage unit that stores a plurality of block data in a blockchain format;
a diagnosis data output unit that outputs the diagnosis data to a database connected to the diagnosis node when the diagnosis data is created;
Among the plurality of medical examination nodes, there are included a request node which requests to view the medical examination data created by another medical examination node, and a creating node which creates target medical examination data which is the medical examination data requested to be viewed by the request node,
the request node has a request message sending unit which, when creating a request message which is a message requesting the creation node to view the target medical examination data, includes predetermined signature data to which a signature of a target patient who is a medical examination target of the target medical examination data is attached, or is a message to which the signature data to which the signature data of the target patient is attached is attached, sends the request message to the creation node;
The creation node is
a patient signature authentication unit that, upon receiving the request message, authenticates the signature of the target patient in the signature data received together with the request message;
a specific information acquisition unit that acquires, when the authentication of the signature of the target patient is successful, diagnostic data specific information for identifying the target diagnostic data and request node specific information for identifying the request node;
a request message creation unit that creates a request message for requesting the setting of a viewing authority that enables the request node to view the target medical examination data, the request message including the medical examination data identification information and the request node identification information, and further including the signature data with the signature of the target patient and the signature data with the signature of the creating node, or a message to which the signature data with the signature of the target patient and the signature data with the signature of the creating node are attached;
a request message sending unit that sends the request message to the authentication node,
The authentication node,
a block data generating unit that, upon receiving the request message, generates the block data including the signature of the target patient and the signature of the generating node, and sets a viewing authority of the target medical examination data for the requesting node;
a block data transmission unit that transmits the generated block data to the plurality of medical examination nodes.
複数の前記診察ノードの中で、他の前記診察ノードで作成された前記診察データの閲覧を要求する要求ノードが、前記要求ノードから閲覧を要求された前記診察データである対象診察データを作成した作成ノードに対して送信するメッセージであって、前記対象診察データの閲覧を要求すると共に、前記対象診察データの診察対象である対象患者の署名が付与された所定の署名用データを含むか、前記対象患者の署名が付与された前記署名用データが添付された前記メッセージである要求メッセージを作成して、前記作成ノードに送信する工程と、
前記作成ノードが、前記要求メッセージと共に受け取った前記署名用データの前記対象患者の署名を認証する工程と、
前記対象患者の署名の認証が成功した場合には、前記対象診察データを特定するための診察データ特定情報と、前記要求ノードを特定するための要求ノード特定情報とを、前記作成ノードが取得する工程と、
前記対象診察データを前記要求ノードが閲覧可能となる閲覧権限の設定を依頼するためのメッセージであって、前記診察データ特定情報と、前記要求ノード特定情報とを含むと共に、前記対象患者の署名付きの前記署名用データおよび前記作成ノードの署名付きの前記署名用データを更に含むか、前記対象患者の署名付きの前記署名用データおよび前記作成ノードの署名付きの前記署名用データが添付された前記メッセージである依頼メッセージを、前記作成ノードが作成して、前記認証ノードに送信する工程と、
前記認証ノードが前記依頼メッセージを受け取ると、前記認証ノードが、前記対象患者の署名と前記作成ノードの署名とを含み、前記要求ノードに対して前記対象診察データの閲覧権限を設定する前記ブロックデータを生成して、複数の前記診察ノードに送信する工程と
を備えることを特徴とする閲覧手続管理方法。 A viewing procedure management method for managing a procedure for viewing the medical examination data between a plurality of medical examination nodes, the plurality of medical examination nodes creating medical examination data by examining a patient and storing a plurality of block data in a block chain format, and an authentication node generating the block data and outputting the block data to the medical examination nodes, by communicating with each other on a network connected by a communication line, the plurality of medical examination nodes comprising:
a request node, among the plurality of said diagnosis nodes, which requests to view said diagnosis data created by another said diagnosis node, sends a message to a creating node which created target diagnosis data, which is the diagnosis data requested to be viewed by said request node, the request message being a message requesting to view said target diagnosis data and including predetermined signature data to which a signature of a target patient who is a subject of diagnosis of said target diagnosis data is affixed, or a message to which the signature data to which the signature of said target patient is affixed is attached, and sending the request message to said creating node;
the generating node authenticating the signature of the target patient in the signature data received together with the request message;
When the authentication of the signature of the target patient is successful, the creating node acquires diagnostic data identification information for identifying the target diagnostic data and request node identification information for identifying the request node;
a step of the creating node creating a request message for requesting the setting of a viewing authority to allow the request node to view the target diagnostic data, the request message including the diagnostic data identifying information and the request node identifying information, and further including the signature data with the signature of the target patient and the signature data with the signature of the creating node, or the signature data with the signature of the target patient and the signature data with the signature of the creating node being attached, and transmitting the request message to the authentication node;
A viewing procedure management method characterized by comprising a step of: when the authentication node receives the request message, the authentication node generates the block data, which includes the signature of the target patient and the signature of the creating node, and sets the viewing authority of the target medical examination data for the requesting node, and transmitting the block data to multiple medical examination nodes.
Applications Claiming Priority (3)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2022154939 | 2022-09-28 | ||
| JP2022154939 | 2022-09-28 | ||
| JP2023032503A JP7357174B1 (en) | 2022-09-28 | 2023-03-03 | Viewing procedure management system, viewing procedure management method |
Related Parent Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2023032503A Division JP7357174B1 (en) | 2022-09-28 | 2023-03-03 | Viewing procedure management system, viewing procedure management method |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2024049373A JP2024049373A (en) | 2024-04-09 |
| JP7560634B2 true JP7560634B2 (en) | 2024-10-02 |
Family
ID=88198185
Family Applications (2)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2023032503A Active JP7357174B1 (en) | 2022-09-28 | 2023-03-03 | Viewing procedure management system, viewing procedure management method |
| JP2023161785A Active JP7560634B2 (en) | 2022-09-28 | 2023-09-25 | Viewing procedure management system and viewing procedure management method |
Family Applications Before (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2023032503A Active JP7357174B1 (en) | 2022-09-28 | 2023-03-03 | Viewing procedure management system, viewing procedure management method |
Country Status (1)
| Country | Link |
|---|---|
| JP (2) | JP7357174B1 (en) |
Citations (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN112910840A (en) | 2021-01-14 | 2021-06-04 | 重庆邮电大学 | Medical data storage and sharing method and system based on alliance blockchain |
Family Cites Families (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2020010267A (en) * | 2018-07-12 | 2020-01-16 | コニカミノルタ株式会社 | Distributed medical information sharing system, medical information provision server, and program |
| JP2020052457A (en) * | 2018-09-21 | 2020-04-02 | 大日本印刷株式会社 | User information management system, user information management device, authority management device, user terminal device, computer program, user information management method, and system construction method |
| KR20210067353A (en) * | 2019-11-29 | 2021-06-08 | 주식회사 아우룸블록체인 | Method and system for storing and providing medical records by strengthening individual's control over medical records with multi-signature smart contract on blockchain |
-
2023
- 2023-03-03 JP JP2023032503A patent/JP7357174B1/en active Active
- 2023-09-25 JP JP2023161785A patent/JP7560634B2/en active Active
Patent Citations (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN112910840A (en) | 2021-01-14 | 2021-06-04 | 重庆邮电大学 | Medical data storage and sharing method and system based on alliance blockchain |
Also Published As
| Publication number | Publication date |
|---|---|
| JP2024049288A (en) | 2024-04-09 |
| JP7357174B1 (en) | 2023-10-05 |
| JP2024049373A (en) | 2024-04-09 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| Seol et al. | Privacy-preserving attribute-based access control model for XML-based electronic health record system | |
| US20200168306A1 (en) | Method and system for sharing electronic medical and health records | |
| US12235984B1 (en) | Patient-empowered data management: a secure blockchain architecture with decentralized ownership | |
| Ghayvat et al. | Sharif: Solid pod-based secured healthcare information storage and exchange solution in internet of things | |
| WO2007120799A2 (en) | Dynamic binding of access and usage rights to computer-based resources | |
| JP2001505341A (en) | Digital authentication center for medical image authentication | |
| US11526955B2 (en) | Protocol-based system and method for establishing a multi-party contract | |
| KR101925322B1 (en) | Method for providing medical counseling service including digital certification, digital signature, and forgery prevention | |
| JP2013537669A (en) | Anonymous healthcare and record system | |
| CN110600096A (en) | Medical data management method and system and computer storage medium | |
| JP5090425B2 (en) | Information access control system and method | |
| CN112735552A (en) | Electronic medical record folder information system based on block chain and IPFS | |
| CN119363345B (en) | Data transmission method, system, electronic equipment and storage medium | |
| US20210019436A1 (en) | Communicating content over a communications network | |
| WO2014201599A1 (en) | Method and system for information authentication authorization and secure use | |
| US11341273B2 (en) | Method for combining different partial data | |
| CN119072898A (en) | Blockchain data processing method, platform, system, device and electronic device | |
| JP2000331101A (en) | Medical related information management system and method | |
| WO2019095552A1 (en) | Regional healthcare system and method for enhancing security and synergetic integration of electronic medical record | |
| Weaver et al. | Federated, secure trust networks for distributed healthcare it services | |
| JP7560634B2 (en) | Viewing procedure management system and viewing procedure management method | |
| CN114743695A (en) | Combined consultation system, method, electronic device and medium based on small program | |
| CN119132487A (en) | Electronic medical record sharing system, method and device | |
| JP4521514B2 (en) | Medical information distribution system, information access control method thereof, and computer program | |
| Nimer et al. | Implementation of a peer-to-peer network using blockchain to manage and secure electronic medical records |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20231003 |
|
| A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20240823 |
|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20240903 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20240919 |
|
| R150 | Certificate of patent or registration of utility model |
Ref document number: 7560634 Country of ref document: JP Free format text: JAPANESE INTERMEDIATE CODE: R150 |