JPWO2019244949A1 - 生体情報処理方法、生体情報処理装置、および生体情報処理システム - Google Patents

Abstract

対象者の生体情報を取得するステップと、前記生体情報に基づいて前記対象者の生体状態を示す状態情報を生成するステップと、前記状態情報をＰ２Ｐデータベース（２２３）に登録するステップと、を含む、生体情報処理方法が提供される。

Description

本開示は、生体情報処理方法、生体情報処理装置、および生体情報処理システムに関する。

近年、医療データの保存や共有を行うために、医療データを電子カルテとして記録する取り組みが行われている。例えば、以下の特許文献１には、医療データを電子カルテとして記録することと、電子カルテの一部のデータをＥＤＣ（Electronic Data Capture）システムに送信することが開示されている。

特開２０１７−２０８０３９号公報 特開２０１２−３００３８号公報

しかしながら、各病院間での医療データの連携は十分に進んでいない。例えば、電子カルテの方式は各病院によって互いに異なるため、各病院は他の病院から電子カルテを連携されても、当該電子カルテに記録された医療データを適切に活用することができない。

そこで、本開示は上記に鑑みてなされたものであり、本開示は、各病院間で医療データをより適切に連携することが可能な、新規かつ改良された生体情報処理方法、生体情報処理装置、および生体情報処理システムを提供する。

本開示によれば、対象者の生体情報を取得するステップと、前記生体情報に基づいて前記対象者の生体状態を示す状態情報を生成するステップと、前記状態情報をＰ２Ｐデータベースに登録するステップと、を含む、生体情報処理方法が提供される。

また、本開示によれば、対象者の生体情報を取得する取得部と、前記生体情報に基づいて前記対象者の生体状態を示す状態情報を生成する生成部と、前記状態情報をＰ２Ｐデータベースに登録する登録部と、を備える、生体情報処理装置が提供される。

また、本開示によれば、対象者の生体情報を取得する取得部と、前記生体情報に基づいて前記対象者の生体状態を示す状態情報を生成する生成部と、前記状態情報をＰ２Ｐデータベースに登録する登録部と、を備える、生体情報処理システムが提供される。

また、本開示によれば、対象者の生体情報を取得するステップと、前記生体情報に基づいて前記対象者の生体状態を示す状態情報を生成するステップと、前記状態情報を分散ネットワークのデータとして登録するステップと、を含む、生体情報処理方法が提供される。

本開示によれば、Ｐ２Ｐデータベースを保持している各病院に対して、医療データの一種である状態情報を連携することが可能になる。

以上説明したように本開示によれば、各病院間で医療データをより適切に連携することが可能になる。

なお、上記の効果は必ずしも限定的なものではなく、上記の効果とともに、または上記の効果に代えて、本明細書に示されたいずれかの効果、または本明細書から把握され得る他の効果が奏されてもよい。

次元圧縮処理の具体例を示す図である。 最適な次元数に至るまで次元圧縮処理が行われる旨を説明するための図である。 状態情報の具体例を示す図である。 状態情報における身体コードの具体例を示す図である。 状態情報における環境コードの具体例を示す図である。 状態情報の具体例を示す図である。 状態情報の具体例を示す図である。 付随情報の具体例を示す図である。 状態情報および付随情報の生成フローの具体例を示す図である。 状態情報および付随情報の生成フローの具体例を示す図である。 時系列解析の具体例を示す図である。 状態遷移の時系列解析の一例を説明するための図である。 Ｐ２Ｐデータベースの一種であるブロックチェーンの概要を説明するための図である。 Ｐ２Ｐデータベースの一種であるブロックチェーンの概要を説明するための図である。 Ｐ２Ｐデータベースの一種であるブロックチェーンの概要を説明するための図である。 本実施形態に係る生体情報処理システムの構成例を示す図である。 アプリケーションバックエンド１００の機能構成例を示すブロック図である。 院内サーバ２００の機能構成例を示すブロック図である。 トランザクション生成部２１２によって生成されるトランザクションデータの具体例を示す図である。 状態情報のＰ２Ｐデータベースへの登録処理全体の具体例を示すフローチャートである。 状態情報のＰ２Ｐデータベースへの登録適否の判断処理の具体例を示すフローチャートである。 状態情報および付随情報の生成処理の具体例を示すフローチャートである。 状態情報に基づく提案処理の具体例を示すフローチャートである。 本実施形態に係る生体情報処理システムの用途事例の具体例を説明するためのフローチャートである。 アプリケーションバックエンド１００、または院内サーバ２００（または院外サーバ３００）を具現する情報処理装置９００のハードウェア構成例を示すブロック図である。

以下に添付図面を参照しながら、本開示の好適な実施の形態について詳細に説明する。なお、本明細書及び図面において、実質的に同一の機能構成を有する構成要素については、同一の符号を付することにより重複説明を省略する。

なお、説明は以下の順序で行うものとする。
１．背景
１．１．病院間での医療データの連携
１．２．個別医療
１．３．ブロックチェーンの利用
２．本実施形態
２．１．状態割振り
２．２．状態情報の時系列解析
２．３．Ｐ２Ｐデータベース
２．４．システム構成例
２．５．各装置の機能構成例
２．６．各装置の処理フロー例
２．７．用途事例
２．８．各装置のハードウェア構成例
３．まとめ

＜１．背景＞
まず、本開示の背景について説明する。

（１．１．病院間での医療データの連携）
上記のとおり、各病院間での医療データの連携は十分に進んでいない。医療データの連携が十分に進んでいない原因は様々に考えられるところ、その原因の一つとして、電子カルテの方式が各病院または各医師によって互いに異なっていることが挙げられる。より具体的には、電子カルテの項目、項目の順番、およびデータ形式などは各病院（または各病院が採用している電子カルテシステムなど）によって互いに異なる。また、特に、電子カルテにおいて自由記載が可能な項目について、電子カルテに記載されるデータの内容は各医師によって互いに異なる。そのため、適切に理解することが困難なデータや不要なデータが電子カルテに記載される場合がある。

以上によって、各病院は、他の病院から電子カルテを連携されても、当該電子カルテに記録された医療データを適切に活用することが困難であった。例えば、各病院は、他の病院から連携された医療データを活用可能なデータ形式へ変換するため仕組み（例えば、変換システムなど）を、連携元の病院ごとに構築することが求められる場合があり、これは相当の負荷を発生させる。また、他の病院から連携された医療データの中に、適切に理解することが困難なデータや不要なデータが含まれる場合には、それらのデータごとに対応方法を検討することが求められる。

また、各病院間で医療データが適切に連携されたとしても、連携された医療データの適切な解析方法や活用方法（例えば、医療データを解析し、その解析結果を治療に活用する方法など）が確立されておらず、医療データを連携することの効果が明確になっていないため、医療データを連携することに対する各病院のモチベーションは高いとは言えなかった。

また、医療データの中には個人を特定可能なデータが含まれる場合があるため、個人情報保護の観点から病院間で医療データを連携することが困難であったり、医療データを連携するに当たって患者の同意を得ることが必要であったりした。また、医療データにおける各データが、個人を特定可能なデータであるか否かを判断し、それらのデータを区別して管理することも相当の負荷を発生させる。さらに、特に個人を特定可能なデータについては、データが改ざんされ、悪用されることを防ぐためにセキュアな環境で当該データを管理することが求められるところ、多くの病院がアクセス可能なほど大規模であり、かつセキュアなシステム（医療データの連携に用いられるシステム）を実現することは容易ではない。

（１．２．個別医療）
これまでの医療データの利活用について考察すると、治療効果などを評価する方法としてランダム化比較試験（RCT：Randomized Controlled Trial）が盛んに行われてきた。これは、主観的あるいは恣意的な評価のバイアス（偏り）が生じることを防ぐために、母集団から人をランダムに抽出して治療群と対照群に振り分け、各人の治療結果を解析する手法である。しかし、このような統計処理に基づく解析は、集団（例えば、患者全体）に対する治療経過の予測を可能にするが、集団に属する個々のメンバー（例えば、個々の患者）に対する治療経過の予測には限界がある。

アトピー性皮膚炎を例にとってより具体的に説明すると、ランダム化比較試験によってアトピー性皮膚炎に効果的な治療方法が開発され得るところ、これは、アトピー性皮膚炎の患者全体の皮膚の特徴量の平均に基づいてより効果的な治療方法を開発することに等しいと言える。しかしながら、皮膚の敏感さやアレルギーの度合いなどの、発症の背景は患者によって互いに異なるため、アトピー性皮膚炎という同一の病名であっても全く同じ症状を有する患者は理論的に存在しない。

したがって、ランダム化比較試験によって効果的であると判断された治療方法による効果は、患者によって互いに異なる。そのため、各患者に応じて治療方法を変える個別医療の実現が期待されているが、各医者の経験や過去の限られた症例に基づいて患者の症状を診ながら薬の量を調節したり薬の種類を変更したりすることが現在の個別医療の限界であると言える。

ゲノム情報を用いた個別医療は提案されているものの、現在の医療技術によってゲノム情報を解析することで得られる情報は限定的である（例えば、患者についてのある傾向（タイプ）に関する情報が得られる程度であるなど）。例えば、患者の身体に関する情報（例えば、ゲノム情報、身体測定情報、診断情報、治療情報、手術情報または患者によって装着されたウェアラブル端末によって取得された血圧や心電図（ECG）といった患者の身体の状態を示す情報など。以降、これらの情報を「身体情報」と呼称する）、または患者に影響を及ぼす環境に関する情報（例えば、患者の生活習慣に関する情報または投薬情報、または患者によって装着されたウェアラブル端末によって取得された加速度や角速度といった患者の環境の状態を示す情報など。以降、「環境情報」と呼称する）が連携され解析に用いられることで、より効果的な個別医療の実現が可能であると考えられるが、これらの情報を用いる個別医療の仕組みが構築されているとは言い難い。また、医療機関が記録する医療情報と、各個人が記録する非医療情報を組み合わせて個別医療の仕組みが構築されているとは言い難い。

別の視点から考察すると、現在の医療においては、疾病の根本原因を制御しようとする原因療法ではなく、主要な症状を軽減するための治療を行うことで自然治癒能力を高め治癒を促進する対症療法に終始する場合が多いと言える。例えば、アトピー性皮膚炎の根本原因である免疫の異常に対する原因療法はまだ十分確立されていないため、アトピー性皮膚炎の治療方法として、ステロイド外用薬や抗ヒスタミン薬により炎症を抑える対症療法が広く行われている。これは、現在の医療が診断および治療が行われる時点における患者の特徴を理解することに基づく、すなわち空間特性に基づく診断および治療を行っていると言える。

原因療法を普及、発展させるため（または、対症療法をより効果的に実現するため）には、診断時に得られるデータだけでなく、時系列に並べられた時系列データ（時間特性）を解析することが有効であると考えられる。例えば、患者の身体情報または環境情報が時系列に並べられた時系列データを解析することで患者ごとの発症の背景が明らかとなり、より効果的な治療が可能になると考えられる。しかし、現在、身体情報または環境情報の時系列データを収集し、解析可能な仕組みが構築されているとは言い難い。

（１．３．ブロックチェーンの利用）
上記で説明してきた病院間で医療データを連携することや、個別医療の実現のために身体情報および環境情報を連携することを実現する技術として期待されているものの一つに「ブロックチェーン」が存在する。

「ブロックチェーン」とは、データ（トランザクションデータ）が格納された複数のブロックが、ハッシュ値などによってあたかも鎖のように連結されたデータである。そして、複数の情報処理装置（ピア、ノード装置）が分散してブロックチェーンを管理することで、ブロックチェーンに格納されたデータの真正性を担保することができる。さらに、ブロックチェーンによって、患者の個人情報の共有にあたり患者自身の承認が介入されることで、患者の自己決定権を担保することが期待されている。

基本的に、ブロックチェーンは過去に登録されたデータを保持し続けるため、運用されるに連れてブロックチェーン全体のデータサイズが莫大になる可能性がある。また、サイズの大きいデータについては、ハッシュ化のための計算処理の負担が大きい。よって、ブロックチェーンに対してサイズの大きいデータを登録することは好ましくない。そのため、例えば、電子カルテ（または、その一部）のみをブロックチェーンに登録する方法、または医療データを保存した所定のデータベースの場所（パス）のみをブロックチェーンに登録する方法などが提案されている。しかし、前者については、上記のとおり病院間で電子カルテの方式が互いに異なっているため、医療データの連携と活用が依然として困難であり、かつ、電子カルテ外で管理されている身体情報や環境情報の連携ができない。また、後者については、医療データの取得のために所定のデータベースへのアクセスが必要になり、当該データベースへのアクセス制御の仕組みが別途必要になるため、医療データを適切に連携しているとは言い難い。また、前者および後者共に、個人情報保護の観点から、医療データの連携に当たって患者の同意を得ることが必要であったり、各データが個人を特定可能なデータであるか否かを判断し、それらのデータを区別して管理することが必要であったりする課題は残ったままである。

＜２．本実施形態＞
本件の開示者は、上記の背景に鑑みて本開示に係る技術を創作するに至った。本開示に係る生体情報処理装置は、対象者（患者を含む）の生体情報を取得し、当該生体情報に基づいて対象者の生体状態を示す状態情報を生成し、当該状態情報をＰ２Ｐデータベース（ブロックチェーンを含む）に登録する。より具体的には、生体情報処理装置は、所定の方法によって生体情報を符号化することで対象者の生体状態を示す状態コードを生成し、当該状態コードを含めた状態情報をＰ２Ｐデータベースに登録する。以降では、本開示の一実施形態について詳細に説明していく。

（２．１．状態割振り）
まず、本実施形態に係る生体情報処理装置が生体情報に基づいて状態情報を生成する処理（以降、当該処理を「状態割振り」と呼称する）の詳細について説明する。

状態割振りに用いられる「生体情報」とは、対象者の身体情報または環境情報を含む概念である。

生体情報に含まれる「身体情報」とは、上記の通り対象者（患者を含む）の身体に関する情報であり、例えば、身体測定情報（例えば、身長、座高、体重、ＢＭＩ（Body Mass Index）、体脂肪率、視力、または聴力など）、診断（問診）情報（例えば、病名、Ｘ線画像、ＭＲＩ画像、ガンマＧＴＰ、または自覚症状など）、治療情報（例えば、治療内容または治療時間など）、または手術情報など（例えば、手術内容または手術時間など）を含む。なお、身体情報の内容はこれらに限定されない。例えば、身体情報は、ゲノム情報やエピゲノム情報などの遺伝情報、リキッドバイオプシーによって得られる、血液など体液サンプル中のホルモン・サイトカイン・増殖因子・遊離核酸等の分子指標の情報または対象者によって装着されたウェアラブル端末や、電波もしくは画像情報などから対象者をセンシングする機能を有するセンシング端末によって取得された患者の身体の状態を示す情報（例えば、心拍数、自律神経、睡眠リズムなどのバイタルサイン、血液酸素量、血糖値、血圧、または尿たんぱくなど、センシング端末に備えられた各種センサによって取得された情報）を含んでいてもよい。また、身体情報は、電子カルテに記録される対象者（患者を含む）の属性情報（例えば、氏名、生年月日、年齢、性別、血液型、住所、電話番号、または勤務先など）や対象者に治療行為や手術行為を行った担当医師名や病院名などの医療情報を含んでもよい。なお、身体測定情報、治療情報、手術情報などの身体情報は、時系列としての要素（各情報の履歴）を含んでいてもよい。なお、治療とは手術に該当しない医療行為を示す。

また、生体情報に含まれる「環境情報」とは、上記の通り対象者（患者を含む）に影響を及ぼす環境に関する情報であり、例えば、対象者の生活習慣に関する情報（例えば、喫煙、飲酒、食事、睡眠、または運動などの習慣、ストレスに関する情報）または投薬情報（例えば、薬の種類、用法、または用量など）、または対象者によって装着されたウェアラブル端末や、電波もしくは画像情報などから対象者をセンシングする機能を有するセンシング端末によって取得された患者の環境の状態を示す情報（例えば、加速度、角速度など、センシング端末に備えられた各種センサによって取得された情報）、リキッドバイオプシーによって得られる、血液、体液などの分子指標の情報を含む。なお、環境情報は、上記身体情報（例えば、心拍数、自律神経、睡眠リズムなどのバイタルサイン、血液酸素量、血糖値、血圧、または尿たんぱく）から推定された環境に関する情報を含んでいてもよい。例えば、睡眠リズムから推定される起床時間等情報や心拍数から推定される運動情報）を含んでいてもよい。また、患者の環境を推定するための情報である場合は、上記身体情報の一部を環境情報として記録してもよい。なお、環境情報の内容はこれらに限定されない。また、各種センサによって取得された情報は、センサ情報そのものでもよいし、センサ情報が解析されることによって出力されたセンサ情報の特徴量情報でもよい（処理効率やデータサイズの観点からは、各種センサによって取得された情報がセンサ情報の特徴量情報であることが好ましい）。なお、治療や手術の間に行われた医師による投薬は、治療情報や手術情報に含めることが好ましく、対象者自身による投薬（薬の摂取）は、投薬情報に含めることが好ましい。

状態割振りは、上記の生体情報（身体情報または環境情報を含む）を所定の分類器に入力することで分類結果を出力し、当該分類結果を用いて状態情報を生成することを指す。分類器は、単なるテーブル（より具体的には、生体情報と状態とが対応付けられたテーブル）を指してもよいし、機械学習の手法を指してもよい。例えば、生体情報が、分類器であるテーブルによって「アトピー性皮膚炎Ａ型→１Ａ、病状箇所は右上腕部→７、赤み多数あり→３」などのように変換されることで状態割振りが行われてもよい。また、生体情報は、サポートベクターマシンやニューラルネットワークなどの機械学習の手法によって状態割り振りを行われてもよい。例えば、所定の生体情報と状態を紐づけた学習データによって学習が行われた分類器が生成され、その分類器に生体情報が入力されることで次元圧縮が行われ、状態割振りが行われる。また、所定のパラメータを有するニューラルネットワークに生体情報が入力され、次元圧縮が行われた際のベクトル値またはスカラー値を状態とする状態割り振りが行われてもよい。上記の分類器による分類は、生体情報の次元を圧縮することができるため、状態割振りは、テーブル変換または機械学習の手法を用いて生体情報の次元を圧縮する処理（以降、「次元圧縮処理」と呼称する）によって状態情報を生成することであるとも言える点に留意されたい。

なお、サポートベクターマシンについては、例えば、複数のサポートベクターマシンが組み合わされることで多クラス分類用のサポートベクターマシンモデルが構築され、当該モデルに学習データ（生体情報）が入力されることで分類器が生成される。また、ニューラルネットワークについては、多層ニューラルネットワークが構築され、学習データ（生体情報と、それに対応する状態の組み合わせデータ）が入力され多層ニューラルネットワークのパラメータの調整が行われることで分類器が生成される。また、生体情報処理装置は、分類器として人工知能(AI：Artificial Intelligence)を用いて状態割振りを行ってもよい。機械学習による次元圧縮については詳細を後述する。

ここで、状態割振りの際に行われる次元圧縮処理の具体例について説明する。例えば、対象者の血圧情報（例えば、最高血圧と最低血圧の数値データ）が上記の分類器に入力されることで、分類器により対象者が「タイプ１：至適血圧」、「タイプ２：正常血圧」、または「タイプ３：高血圧」のうちの「タイプ１：至適血圧」であると判断される場合、生体情報処理装置は、「１」を出力することで次元圧縮処理を実現してもよい。また、例えば、対象者の加速度情報（例えば、所定時間内における加速度の数値データ）が上記の分類器に入力されることで、対象者の生活習慣が「タイプ１：朝型」、「タイプ２：標準」、または「タイプ３：夜型」のうちの「タイプ３：夜型」であると判断される場合、生体情報処理装置は、「３」を出力することで次元圧縮処理を実現してもよい。なお、生体情報処理装置は、より多くの種類の生体情報を用いることで状態割振りの精度を向上させることや割振れる状態を増やすことができる。例えば、生体情報処理装置は、血圧情報や加速度情報だけでなく心拍情報や血糖値情報なども併せて用いることで状態割振りの精度や割振り可能な状態の数を向上させることができる。

また、生体情報処理装置は、上記の分類器を用いて分類を行う際に、生体情報をより分類しやすい形式に変換してもよい。例えば、生体情報処理装置は、生体情報に対して所定の近似処理を施し単純化する（近似モデルを出力する）ことで次元圧縮を行い、生体情報をより分類しやすい形式に変換してもよい。例えば、図１に示すように、生体情報として血圧情報（図１の例では、一日の血圧の推移に関する情報）が取得された場合、図１のＡとＢに示すように、生体情報処理装置は、当該情報を解析することで上の血圧（収縮期血圧）の推移を示す多項式近似曲線１０を算出する。そして、図１のＣに示すように、生体情報処理装置は、多項式の各係数を繋げたデータ列を出力することで、上の血圧（収縮期血圧）に関する情報の次元を圧縮してもよい。同様に、生体情報処理装置は、下の血圧（拡張期血圧）に関する情報の次元を圧縮してもよい。また、生体情報処理装置は、生体情報の粒度を縮減させることで生体情報をより分類しやすい形式に変換してもよい。例えば、生体情報としてＢＭＩに関する情報が取得され、当該情報が「１７．５５」（換言すると、小数点第２位まで含まれる情報）であった場合、生体情報処理装置は、小数点以下を切り捨てて「１７」に変換することで生体情報をより分類しやすい形式に変換してもよい。

また、生体情報処理装置は、上記の分類器を用いて分類を行う際に、生体情報に含まれる情報ごとに異なる分類器を用いて分類を行うことができる。例えば、生体情報処理装置は、血圧情報についてはテーブルを分類器として用いて分類を行い、加速度情報についてはサポートベクターマシンの手法を分類器として用いて分類を行ってもよい。また、生体情報処理装置は、複数種類の分類器を組み合せて分類を行ってもよい。例えば、生体情報処理装置は、血圧情報についてテーブルを分類器として用いて分類を行った後に、サポートベクターマシンの手法を分類器として用いてさらに分類を行ってもよい。

生体情報処理装置は、生体情報の種類ごとに異なる分類器で分類を行った後、それぞれの分類結果に対してさらに次元圧縮処理を行い、状態割り振りを行ってもよい。例えば、生体情報処理装置は、血圧情報を状態割り振りした結果を示す行列Ａ、加速度情報を状態割り振りした結果を示す行列Ｂ、心拍情報を状態割り振りした結果を示す行列Ｃ、…と複数の生体情報の種類ごとの分類結果を示す文字列をそれぞれ所定の順序で並べて行列｛Ａ，Ｂ，Ｃ，…｝を生成する。そして、生体情報処理装置は、この行列に基づいて次元圧縮処理による状態割り振りを行い、生体情報の持ち主の状態を表す情報（状態情報）を生成する。すなわち、状態は状態ベクトル（行列）として表現される。また、身体情報および環境情報も状態ベクトル（行列）で表されてもよい。

身体の特徴量は膨大であるため、生体情報処理装置は、対象者の生体状態の特徴を適切に識別可能な次元にまで次元圧縮処理を行うことが好ましい（以降、対象者の生体状態の特徴を識別可能な度合いを「識別率」と呼称する）。ここで、図２を参照して、生体情報の次元数と識別率との関係について説明する。一般的に、生体情報の次元数が少なすぎる場合には、生体状態の特徴の識別に用いられる情報量が少ないことを理由に識別率が低くなり易い。そして、生体情報の次元数が増加するに連れて識別率も向上していくが、生体情報の次元数が所定値（図中の「最適な次元数」）を超えた後には、不要な情報が多く含まれるなどの理由によって識別率が低下する傾向にある。そこで、生体情報の次元数が、図２における「最適な次元数」（または「最適な次元数」に近い次元数）にまで削減されることが好ましい。生体情報処理装置は、相当数の対象者の生体情報に対して次元圧縮処理を行い、結果として得られた識別率を機械学習の手法等で学習していくことを通して、最適な次元数を算出できてもよい。なお、最適な次元数の算出方法はこれに限定されない。

生体情報処理装置は、医学的知見に基づき次元圧縮処理を行い、状態割り振りを行ってもよい。がんやアトピー性皮膚炎などの疾患では、膨大な生体情報の特徴量から医学的知見に基づき抽出された８つの特徴量（イムノグラム）を用いて、各疾患の評価がなされている。生体情報処理装置は、入力された生体情報から医学的知見に基づき特定された各疾患に紐づく特徴量を抽出することで、次元圧縮を行うことができる。例えば、アトピー性皮膚炎は、臨床治験に基づき皮膚バリア機能や免疫調整機能、細菌叢等を示す８つの生体情報の特徴量にて評価できることが知られている。そこで、生体情報処理装置は、診断情報である「アトピー性皮膚炎」の入力をトリガとして、入力された生体情報からアトピー性皮膚炎に関連する８つの特徴量を抽出し次元圧縮処理を行い、状態情報を生成する。医学的知見に基づいた次元圧縮処理後、上記の分類器を用いてさらに次元圧縮を行い、状態情報を生成しても良い。この次元圧縮法により、さまざまな疾患において、医学的に臨床上意味がある層別化を行うことが可能となる。

生体情報処理装置は、上記で説明してきた分類器を用いた次元圧縮処理を生体情報に施すことによって、符号化された身体コードまたは環境コードを生成する。そして、生体情報処理装置は、身体コードまたは環境コードのうちの少なくともいずれか一方に対して、分類器を用いた次元圧縮処理を施すことで符号化された状態コードを生成する。さらに、生体情報処理装置は、符号化されたこれらの情報を状態情報に含める。次元圧縮処理により、状態情報のデータサイズはブロックチェーンのブロック容量以下となることが好ましい。

続いて、図３〜図８を参照して、生体情報の次元圧縮処理によって生成された状態情報の具体例について説明する。

「状態情報」とは、上記のとおり、対象者（患者を含む）の生体状態を示す情報である。ここで、図３を参照して、状態情報の具体例について説明する。例えば、状態情報は、標準コードと、状態コードと、身体コードと、環境コードと、誤り検出用チェックサムと、を有する。図３で示すように、状態情報は例えば数字とアルファベットによる６４桁の文字列「0291es79A8esdf7y83hr98yeuwofb3ieo2yur9i32br9eypqfj0ewqifj5e4qh3p」で表現される。

「標準コード」は、生体情報に基づいて状態情報が生成される際に用いられた方法を示す情報である（換言すると、標準コードは、状態情報が生成される際に用いられた方法を示す方法コードとも言える点に留意されたい）。図３ではデータ列Ｎｏ（１）の「02」に相当する。より具体的には、生体情報に基づいて以降で説明する身体コード、環境コード、および状態コードを生成する方法は所定の規格（例えば、ＩＳＯ（International Organization for Standardization）規格など）によって標準化されることを想定している。すなわち、複数の企業などの主体が、所定の規格によって標準化された方法を用いることで状態情報を生成するなど、本実施形態に係る生体情報処理システムを利用できることを想定している。状態情報の中に標準コードが含まれることによって、生体情報処理システムの利用者は、状態情報が生成される際に用いられた方法を特定することができるため、状態情報を適切に利用することができる。

「身体コード」は、身体情報に対して次元圧縮処理が施されることによって符号化された情報である。身体情報が次元圧縮処理によって符号化されることで、個人がより特定されにくくなる。

ここで、図３の例では、身体コードがデータ列Ｎｏ（３）の「9A8esdf7y83hr」というデータ列を有するところ、当該データ列に含まれる情報の具体例を、図４を参照して説明する。より具体的には、図４に示すように、身体コードは、診断結果と、自覚症状および問診結果と、非個人情報およびＢＭＩと、病院が位置する地域と、を有する。そして、各情報は次元圧縮処理によって符号化されているところ、例えば、診断結果は「9A8」というデータ列で「右大腿骨頚部骨折」を示し、自覚症状および問診結果は「esd」というデータ列で「自覚症状：2日前に転倒してから右足が痛い、問診結果：右大腿骨頸部付近の痛み」を示し、非個人情報およびＢＭＩは「f7y」というデータ列で「60代男性太り気味（BMI:35）」を示し、病院が位置する地域は「83hr」というデータ列で「アメリカ合衆国ニューヨーク州」を示す。なお、身体コードに含まれる情報は図４の例に限定されない。また、非個人情報は個人情報を加工して個人を特定できないようにした情報である。

図３における「環境コード」は、環境情報に対して次元圧縮処理が施されることによって符号化された情報である。環境情報が次元圧縮処理によって符号化されることで、個人がより特定されにくくなる。

ここで、図３の例では、環境コードがデータ列Ｎｏ（４）の「98yeuwofb3ieo2yur9i32br9eypqfj0ewqifj5e4」というデータ列を有するところ、当該データ列に含まれる情報の具体例を、図５を参照して説明する。より具体的には、図５に示すように、環境コードは、センサ情報の統合情報と、各センサ情報と、を有する。センサ情報の統合情報は、各センサ情報に対して次元圧縮処理が施されることによって符号化された情報であり、「98yeuwo」というデータ列で「運動量が急激に低下」という内容を示している。また、各センサ情報には、例えば、ジャイロセンサ、加速度センサ、または脈拍センサなどから取得された情報に対して次元圧縮処理が施されることによって符号化された情報が含まれている。なお、環境コードに含まれる情報は図５の例に限定されない。例えば、環境コードに含まれるセンサ情報の種類は特に限定されない。また、図５の例では、各センサ情報は、センサごとに２桁ずつの情報にまで次元圧縮されているが、センサごとの情報の桁数は特に限定されない。

図３における「状態コード」は、身体コードまたは環境コードのうちの少なくともいずれか一方が次元圧縮処理によって符号化されることで生成された、対象者の生体状態を示す情報である。図３ではデータ列Ｎｏ（２）の「91es7」に相当する。状態コードも、身体コードおよび環境コードと同様に次元圧縮処理によって符号化されることで、個人がより特定されにくくなる。

「誤り検出用チェックサム」は、状態情報における誤り（例えば、状態情報の改ざん、または何らかの原因による状態情報の破損など）を検出するために用いられる情報である。より具体的には、状態情報を取得した生体情報処理装置は、状態情報の一部（より具体的には、状態情報から誤り検出用チェックサムを除いた部分）に対して所定の演算（例えば、ハッシュ値の算出など）を行い、演算結果と誤り検出用チェックサムが一致することによって状態情報に誤りが含まれていないことを確認する。誤り検出用チェックサムが状態情報に含まれることによって、誤った状態情報が処理に用いられることが防がれる。

ここで、例えば、次元圧縮処理にサポートベクターマシンやニューラルネットワークなどの機械学習の手法が用いられた場合においては、生体情報がベクトル空間上の位置に変換される。したがって、図５に示すように、状態コード、身体コード、および環境コードがベクトル空間上の位置を示していてもよい。

なお、状態情報は図３および図６に示す例に限定されない。例えば、状態情報は図３および図６に示した情報の全てを必ずしも含んでいる必要はなく、適宜情報を省略することができる。また、状態情報には図３および図６に示した情報以外の情報が含まれてもよい。より具体的には、図７に示すように、身体コードおよび環境コードが省略されてもよい。また、図３、図６および図７では、処理の効率化などの観点から状態情報が６４文字の英数字によって構成される場合を例として説明したが、状態情報のデータ長は特に限定されない。また、本実施形態では、状態情報がアルファベット２６種類、数字９種類の３５種類の文字で表現された文字列であるとして説明しているが、文字列の表現方法は制限されない。例えば、状態情報は１６進数データ列として表示してもよく、「0201B60AC1E5751957A41AB6BEC66E290AF5263E2AD9F9CC9D824BD40AFE0FAF」として表されてもよい。16進数データ列とすることで記憶容量を減らせる効果を有する。

生体情報処理装置は、生体情報に基づいて状態情報を生成する際に、併せて付随情報を出力する。「付随情報」とは、生体情報のうち、状態情報の生成に用いられなかった情報に基づいて生成された情報を言う。続いて、図８を参照して、付随情報の具体例について説明する。

図８に示すように、例えば、付随情報は、標準コードと、生成元ＩＤと、管理ＩＤと、個人ＩＤと、センシング機器情報と、誤り検出用チェックサムと、を有する。

「標準コード」は、上記で説明した状態情報の標準コードと同様に、生体情報に基づいて付随情報が生成される際に用いられた方法を示す情報である。図８では、データ列Ｎｏ（１）の「je」が相当する。標準コードは、例えば、付随情報が所定の変換処理（例えば、暗号化処理やハッシュ化処理など）を用いて生成される際の、生成に用いられる所定の変換処理の種類などを示してもよい。

「生成元ＩＤ」は、状態情報および付随情報を生成した生成元を示す情報である。例えば、生成元ＩＤは、図８のデータ列Ｎｏ（２）の「ir9wro」というデータ列で「病院の識別情報」を示し、事前に各病院に設定された識別情報（変換前）に対して所定の変換処理（例えば、暗号化処理やハッシュ化処理など）を施すことで生成された情報である。後述するが、付随情報は状態情報と共にＰ２Ｐデータベースに登録されるところ、生成元ＩＤが付随情報に含まれることによって、状態情報および付随情報の生成元の特定が可能となる。

「管理ＩＤ」は、状態情報および付随情報の管理に用いられる情報である。例えば、生成元ＩＤは、データ列Ｎｏ（３）の「3ni89」というデータ列で「電子カルテ番号」を示し、状態情報および付随情報の生成に使用された電子カルテに設定された電子カルテ番号（変換前）に対して所定の変換処理（例えば、暗号化処理やハッシュ化処理など）を施すことで生成された情報である。管理ＩＤが付随情報に含まれることによって、状態情報および付随情報の生成に使用された電子カルテなどの特定が可能となる。

「個人ＩＤ」は、状態情報および付随情報の対象者を示す情報である。例えば、個人ＩＤは、データ列Ｎｏ（４）の「usofna1wor7po」というデータ列で「患者番号」を示し、状態情報および付随情報の対象者である患者に設定された患者番号（変換前）に対して所定の変換処理（例えば、暗号化処理やハッシュ化処理など）を施すことで生成された情報である。個人ＩＤが付随情報に含まれることによって、状態情報および付随情報を生成した機関は、状態情報および付随情報の対象者の特定が可能となる。

「センシング機器情報」は、状態情報の生成に用いられたセンシング機器情報（または、センシング機器の種類）を示す情報である。例えば、センシング機器情報は、データ列Ｎｏ（５）の「3mnrtj0eikpf4dis0uf203pojmfioe8hfj」というデータ列で「患者が使用しているセンシング機器の識別情報」を示し、患者が使用しているセンシング機器（または、センシング機器の種類）に事前に設定された識別情報（変換前）に対して所定の変換処理（例えば、暗号化処理やハッシュ化処理など）を施すことで生成された情報である。センシング機器情報が付随情報に含まれることによって、例えば、状態情報に含まれる各センサ情報の解析が可能となる。

「誤り検出用チェックサム」は、上記で説明した状態情報の誤り検出用チェックサムと同様に、付随情報における誤り（例えば、付随情報の改ざん、または何らかの原因による付随情報の破損など）を検出するために用いられる情報である。誤り検出用チェックサムが付随情報に含まれることによって、誤った付随情報が処理に用いられることが防がれる。

なお、付随情報は図８に示す例に限定されない。例えば、付随情報は図８に示した情報の全てを必ずしも含んでいる必要はなく、適宜情報を省略することができる。また、付随情報には図８に示した情報以外の情報が含まれてもよい。また、状態情報と同様に、付随情報のデータ長は特に限定されない。また、付随情報は１つの文字列に限定されない。例えば、付随情報は複数の文字列を含んでいてもよい。また、１６進数の文字列で表してもよい。

続いて、図９および図１０を参照して、上記で説明してきた状態情報および付随情報の生成フローの概要について説明する。図９および図１０には、身体情報に含まれる電子カルテに記載されている情報（図中では「電子カルテ情報」と表記している）を用いて状態情報および付随情報が生成される際の処理フローの概要が示されている。もちろん、状態情報および付随情報は身体情報だけでなく環境情報に基づいて生成されてもよい。

まず、ステップＳ１０００では、生体情報処理装置は、電子カルテ情報を個人情報と非個人情報に分類する。「個人情報」とは、それ単体で対象者を特定可能な情報（または対象者を特定される可能性が高い情報）であり、例えば、対象者の属性情報、保険情報、病院来歴、またはＸ線画像などが含まれる。また、「非個人情報」とは、それ単体で対象者を特定できない情報（または対象者を特定される可能性が低い情報）であり、例えば、自覚症状、問診症状、または診断結果などが含まれる。

ステップＳ１００４では、生体情報処理装置が、個人情報の一部を非個人情報に変換する（以降、「非個人化処理」と呼称する）。「非個人化処理」とは、例えば、属性情報に含まれる「年齢：２５歳」という情報を「年齢層：２０代」という情報へ変換したり、「勤務先：ＡＢＣ株式会社」という情報を「職業：会社員」という情報へ変換したりすることで、対象者がより特定されにくい情報へと変換することを指す。非個人情報は後段の処理にて状態コードへ変換されるところ、上記の年齢層や職業などの情報も対象者の生体状態に影響を及ぼす因子となり得るため、生体情報処理装置は、非個人化処理によってこれらの情報を非個人情報に追加する。なお、対象者の生体状態に影響を及ぼす因子となり得る情報であれば如何なる情報が非個人化処理の対象になってもよい。

ステップＳ１００８では、生体情報処理装置が、個人情報を病院内のストレージなどに保管すると共に、図８を参照して説明した個人ＩＤ（例えば、患者番号など）および管理ＩＤ（例えば、電子カルテ番号など）を発行する。

ステップＳ１０１２では、生体情報処理装置が、個人ＩＤ（変換前）および管理ＩＤ（変換前）に対して所定の変換処理（例えば、暗号化処理やハッシュ化処理など）を施すことで個人ＩＤ（変換後）および管理ＩＤ（変換後）を生成し、それらを含んだ付随情報を生成する（なお、図８に示した生成元ＩＤおよびセンシング機器情報に関する変換処理の説明は省略している）。なお、生体情報処理装置は、個人ＩＤや管理ＩＤに対してハッシュ化処理を行う場合、異なる文字列から同一のハッシュ値が生成されてしまうハッシュ衝突現象が生じる場合に備えて、個人ＩＤと管理ＩＤそれぞれに対して個別にハッシュ化処理を行い、それぞれのハッシュ値を付随情報に含めるのが好ましい。例えば、病院内のストレージでは管理ＩＤに個人ＩＤが紐づけられて保存されているため（電子カルテに個人ＩＤが記載されている等）、もし個人ＩＤもしくは管理ＩＤでハッシュ衝突現象が生じたとしても、病院内のストレージの記録が参照されることでハッシュ衝突現象による情報の混同が抑制され得る。また、生体情報処理装置は、ハッシュ衝突現象が生じる可能性が低くなるように十分なビット長を有するハッシュ化処理を行うことがより好ましい。

ステップＳ１０１６では、生体情報処理装置が、非個人情報に対して次元圧縮処理による状態割振りを行うことで状態情報を生成する。以上の処理によって、状態情報および付随情報が生成される。なお、その後については、ステップＳ１０２０にて、生体情報処理装置が、状態情報および付随情報を用いてトランザクションデータを生成するなど、状態情報および付随情報のＰ２Ｐデータベースへの登録処理が行われることになる。Ｐ２Ｐデータベースへの登録処理の具体例については後述する。

（２．２．状態情報の時系列解析）
上記では、本実施形態に係る生体情報処理装置による状態割振りについて説明した。続いて、状態情報の時系列解析について説明する。

生体情報処理装置は、上記で生成した状態情報（および付随情報）をＰ２Ｐデータベースに登録するにあたり、状態情報が有効であるか否かを判断し、状態情報が有効であると判断した場合にＰ２Ｐデータベースに登録を行う。

対象者の生体状態は、生体に生じる不可逆的な変化（以降、「不可逆的変化」と呼称する）の連鎖によって表される。例えば、ヒトは受精の瞬間から発生、誕生、成長、老化という不可逆的変化を経て死亡する。疾患の発症も潜在的な変化を受けた発症の前段階、発症、特定の生理機能障害、特定の生理機能消失、身体障害、死へと展開する。そのため、対象者の生体状態を適切に表すためには、不可逆的変化を捉えることがより重要であると言える。

しかし、状態情報の元となる生体情報（身体情報および環境情報）は不可逆的変化以外の変化も含まれた情報である。より具体的には、図１１に示すように、生体情報（例えば、心拍数、自律神経、睡眠リズムなどのバイタルサイン、血液酸素量、血糖値、血圧、または尿たんぱくなど、センシング端末に備えられた各種センサによって取得された情報や、リキッドバイオプシーによって得られる、血液など体液サンプル中のタンパク質・遊離核酸等の分子指標の情報）は、リズム成分と、刺激応答成分と、ベースライン成分と、に分解され得る。

「リズム成分」とは、主に、２４時間周期のサーカディアンリズムに基づく情報であり、不可逆的変化が生じたか否かに関わらず所定のリズムで変化している成分である。

また、「刺激応答成分」とは、生体に対して何らかの入力（刺激）が行われた場合において、当該入力に対する直接の出力（刺激への応答）を示す情報である。例えば、生体に対して投薬という入力が行われた場合において、薬の作用が刺激応答成分として現れる。

そして、「ベースライン成分」とは、生体情報からリズム成分と刺激応答成分が除去されて残った情報であり、生体に対して行われた何らかの入力（刺激）、または経年変化などによって不可逆的に変化していく情報である（ベースライン成分は、時系列データにおける不可逆的な変化を示す情報である）。換言すると、ベースライン成分の変化を捉えることによって、不可逆的変化を捉えることが可能になる。生体状態の不可逆的な変化は、例えば、分子機構としてはゲノム情報とエピゲノム情報の経時的に不可逆的な変化、換言するとジェネティクス修飾とエピジェネティクス修飾による染色体の不可逆的な変化である。生体状態の経時的な変化をベースライン成分に基づいて離散化することで、不可逆的な変化を表現することが可能となる。

上記の特許文献２には、時系列データをリズム成分、刺激応答成分、ベースライン成分に分離する方法が開示されている。より具体的には、上記の特許文献２には、生体で産生される分子の発現量に関する時系列データを、季節調節モデルを用いてリズム成分（特許文献２における周期的成分）に、多重線形モデルを用いて刺激応答成分（特許文献２における環境刺激応答成分）に、多項式平滑化スプラインモデルを用いてベースライン成分に、それぞれ分解する方法が開示されている。

そこで、生体情報処理装置は、特許文献２に記載の方法などを用いて、次元圧縮処理の一種として生体情報が時系列に並べられた時系列データからベースライン成分を抽出し、ベースライン成分の変動に基づいて、対象者の状態情報のＰ２Ｐデータベースへの登録を制御する。より具体的には、生体情報処理装置は、対象者の状態情報が前回Ｐ２Ｐデータベースに登録された時点から、ベースライン成分が所定の閾値より大きく変動したことを確認した場合に、状態情報をＰ２Ｐデータベースへ登録することを決定する。これによって、生体情報処理装置は、より有効な状態情報をＰ２Ｐデータベースに登録することができる。すなわち、生体情報処理装置は、ゲノム情報やエピゲノム情報のような膨大なデータ量を有するデータであっても、ベースライン成分の変化に基づいて離散化することで解析可能な形でデータ量を圧縮してＰ２Ｐデータベースに登録することができる。

また、生体情報処理装置は、対象者の状態情報の時系列解析を行うことで、将来のある時点における対象者の状態を予測し、この予測結果に基づいて適切な提案を行うことができる。

より具体的に説明すると、まず、生体情報処理装置は、ある対象者の状態情報をＰ２Ｐデータベースから取得する。そして、生体情報処理装置は、当該状態情報を解析することで対象者の状態を認識する。なお、生体情報処理装置は、ある期間に生成された複数の状態情報を取得し、これらの状態情報を解析することで、当該期間における対象者の状態の遷移のパターン（以降、「状態の遷移パターン」と呼称する）を認識してもよい。

その後、生体情報処理装置は、当該対象者の状態（または状態の遷移パターン）に類似する状態（または状態の遷移パターン）を過去に有していた別の対象者（以降、「類似者」と呼称する）をＰ２Ｐデータベースにおいて探索する（換言すると、生体情報処理装置は、対象者の状態情報と、他の対象者の状態情報（他の状態情報）とを比較することで類似者を抽出する）。このとき、できる限り長い期間において当該対象者と類似する状態の遷移パターンを有している類似者が発見されることがより好ましい。また、類似者の数は特に限定されない。

生体情報処理装置は、類似者を発見することができた場合、対象者の状態（または状態の遷移パターン）と類似する時点以降の類似者の状態情報をＰ２Ｐデータベースから取得し解析することで、類似者のその後の状態の遷移パターンを認識する。これによって、生体情報処理装置は、将来のある時点における対象者の状態を予測することができる。

生体情報処理装置は、将来のある時点における対象者の状態の予測結果を当該対象者に通知することができる。このとき、生体情報処理装置は、対象者が理解できるように、状態の意味を変換することが好ましい。より具体的に説明すると、対象者の生体状態は状態コードに変換されているところ、対象者は状態コードだけを認識しても自身の生体状態を認識することができない。そこで、生体情報処理装置は、対象者が認識できるように、状態コードを変換する。例えば、生体情報処理装置は、所定のテーブルを用いて状態コードに対して逆変換をかけたり、ベクトル空間上の位置が示す状態を言語化したりする（例えば、ベクトル空間上の対象者の位置が多くの腰痛患者の位置に近い場合、生体情報処理装置は、対象者が腰痛をかかえている状態であると通知するなど）。

また、将来の対象者の状態が良好ではないと予測される場合、生体情報処理装置は、類似者の状態の遷移パターンに基づいて対象者の状態を良好にするための方法を提示することができる。より具体的には、生体情報処理装置は、対象者がｎ年後になる可能性が高い状態のうち、健康的ではないと考えられるベクトル空間に位置する状態が存在すれば、健康的であると考えられるベクトル空間に位置する状態と比較し、健康的な状態になるための方法を提案する。例えば、生体情報処理装置は、健康的な状態になるためにはどのように環境情報を更新すればよいかを算出し、更新に必要な情報（例えば、運動量や薬の内容など）を提示する。また、対象者がｎ年後になる可能性が最も高い状態が健康的ではないと考えられるベクトル空間に位置する場合に、生体情報処理装置は、所定の環境情報（例えば、運動量や薬の内容など）を変化させるとどのように対象者の状態が変化するかを算出し、健康的であると考えられるベクトル空間に状態を移動させるための環境情報を特定して提示してもよい。換言すると、生体情報処理装置は、変化させて意味のあるパラメータ（健康的であると考えられるベクトル空間に状態を移動させることに寄与するパラメータ）を特定し、当該パラメータを変化させる方法（医療的見地から導出される方法など（例えば、尿酸値が高いならＡ薬を処方するなど））を提示してもよい。なお、上記において「健康的であると考えられるベクトル空間」とは、健康的な人の状態が集合しているベクトル空間を指す。

ここで、状態遷移の時系列解析の一例について図１２を用いて詳細を説明する。図１２に示すように、時間ｔｎのとき、対象者の状態情報をｘｔｎ、身体情報をｙｔｎ、環境情報をｕｔｎと表すとする。ｘｔｎ、ｙｔｎ、ｕｔｎはそれぞれ状態ベクトル（行列）で表される。このとき、対象者の状態ｘｔｎは、そのときの環境情報ｕｔｎと身体情報ｙｔｎに基づいて生成される。例えば、現時点をｔ３とすると、環境情報ｕｔ３と身体情報ｙｔ３から対象者の現時点の状態ｘｔ３が算出される。また、ｔ３から時系列として１つ前の時間をｔ２、ｔ３から２つ前の時間をｔ１としたとき、対象者の状態はｘｔ１、ｘｔ２、ｘｔ３と順に変化していくと言える。

また、ｘｔｎは時間ｔを変数とする関数ｆ（ｘｔｎ）と考えることができる。この関数ｆ（ｘｔｎ）を算出することが可能であれば、将来的な時間ｔｎにおける対象者の状態ｘｔｎを推定することが可能となる。しかしながら、リアル世界ではパラメータが莫大なものになるため、この関数ｆ（ｘｔｎ）を算出することは実質的に不可能である。そこで、生体情報処理装置は、人の状態情報（または環境情報や身体情報）の変化を学習データとしてパラメータ調整が行われた機械学習モデルを生成し、対象者の現時点までの状態情報の変化を入力することで、将来の時間ｔｎにおける対象者の状態を統計的に推定する。このとき、ｔ１時点において、状態ｘｔ１が状態ｘｔ２になる確率はｚ１、ｘｔ３になる確率はｚ３と表される。また、ｔ２時点において状態ｘｔ２が状態ｘｔ３になる確率はｚ２と表される。このような状態変化モデル、すなわち時系列として前の状態に依存して現時点の状態が確率的（状態遷移確率）に決まるモデルを隠れマルコフモデル（または多層隠れマルコフモデル）と呼ぶ。そこで、上記の状態遷移確率の推定は、隠れマルコフモデル分析を行いやすいアルゴリズム、例えば、ＲＮＮ（Recurrent Neural Network）を用いた機械学習アルゴリズム、によって行われることがより好ましい。このように、リアル世界のパラメータを全て参照するのではなく、確率的（統計的）に変化を参照することで、将来の状態を推定することが可能となる。

（２．３．Ｐ２Ｐデータベース）
上記では、状態情報の時系列解析について説明した。生体情報処理装置によって生成された状態情報はＰ２Ｐデータベースへ登録されて管理される。そこで、続いて、Ｐ２Ｐデータベースの概要について説明する。

本実施形態に係る生体情報処理システムでは、Ｐ２Ｐネットワークに流通している分散型のＰ２Ｐデータベースが利用される。なお、Ｐ２Ｐネットワークは、Ｐ２Ｐ型分散ファイルシステムと呼ばれる場合もある。Ｐ２Ｐデータベースの例として、Ｐ２Ｐネットワークに流通しているブロックチェーンが挙げられる。そこで、図１３〜図１５を参照して、Ｐ２Ｐデータベースの一例としてブロックチェーンの概要について説明する。

図１３に示すように、ブロックチェーンは、複数のブロックがあたかも鎖のように連なって含まれるデータである。それぞれのブロックには、１または２以上の対象データが、トランザクションデータ（取引）として格納されうる。

ブロックチェーンとしては、例えば、Bitcoin等の仮想通貨のデータのやり取りに用いられるブロックチェーンが挙げられる。仮想通貨のデータのやり取りに用いられるブロックチェーンには、例えば、直前のブロックのハッシュ値と、ナンスと呼ばれる値が含まれる。直前のブロックのハッシュ値は、直前のブロックから正しく連なる、「正しいブロック」であるか否かを判定するために用いられる情報である。ナンスは、ハッシュ値を用いた認証においてなりすましを防ぐために用いられる情報であり、ナンスを用いることによって改ざんが防止される。ナンスとしては、例えば、文字列、数字列、あるいは、これらの組み合わせを示すデータ等が挙げられる。

また、ブロックチェーンでは、各トランザクションデータに暗号鍵を用いた電子署名が付与されることによって、なりすましが防止される。また、各トランザクションデータは公開され、Ｐ２Ｐネットワーク全体で共有される。なお、各トランザクションデータは暗号鍵を用いて暗号化されてもよい。

図１４は、ブロックチェーンシステムにおいて、対象データがユーザＡによって登録される様子を示す図である。ユーザＡは、ブロックチェーンに登録する対象データに対して、ユーザＡの秘密鍵を用いて生成された電子署名を付する。そしてユーザＡは、電子署名が付された対象データを含むトランザクションデータをＰ２Ｐネットワーク上にブロードキャストする。これによって、対象データ（例えば、仮想通貨など）の保有者がユーザＡであることが担保される。

図１５は、ブロックチェーンシステムにおいて、対象データ（例えば、仮想通貨など）がユーザＡからユーザＢに移行される様子を示す図である。ユーザＡは、ユーザＡの秘密鍵を用いて生成した電子署名をトランザクションデータに付し、当該トランザクションデータにユーザＢの公開鍵を含める。これにより、対象データがユーザＡからユーザＢに移行されたことが示される。また、ユーザＢは、対象データの取引に際して、ユーザＡの公開鍵をユーザＡから取得し、電子署名が付された、または暗号化された対象データを取得してもよい。

また、ブロックチェーンシステムでは、例えばサイドチェイン技術を利用することによって、Bitcoinのブロックチェーン等の、既存の仮想通貨のデータのやり取りに用いられるブロックチェーンに、仮想通貨とは異なる他の対象データを含めることも可能である。

なお、上記のとおり、本実施形態に係る生体情報処理システムでは、Ｐ２Ｐネットワークに流通している分散型のＰ２Ｐデータベースが利用されるが、複数の生体情報処理装置によって分散処理が行われる分散ネットワークが利用されてもよいことに留意されたい。ここで、分散ネットワークとは、例えば許可されたユーザのみがアクセス可能なクラウドサーバを含むネットワークであってもよく、各ユーザのＩＤに紐づけられたクラウドサーバ上のストレージに上記で説明した状態情報が記録され、各ユーザがアクセスを許可したＩＤによってのみ状態情報が閲覧される生体情報処理システムが構築されてもよい。

（２．４．システム構成例）
上記では、Ｐ２Ｐデータベースの概要について説明した。続いて、図１６を参照して、本実施形態に係る生体情報処理システムの構成例について説明する。

図１６に示すように、本実施形態に係る生体情報処理システムは、アプリケーションバックエンド１００と、院内サーバ２００と、院外サーバ３００（図中では、院外サーバ３００ａ〜院外サーバ３００ｃ）と、院内ネットワーク４００と、Ｐ２Ｐネットワーク５００と、を備える。

（アプリケーションバックエンド１００）
アプリケーションバックエンド１００は、主に、患者に対して診断、治療または手術を行う医師によって使用される生体情報処理装置である。

より具体的に説明すると、アプリケーションバックエンド１００は、病院内のストレージ、自装置に備えられる記憶部、または外部のサーバ（例えば、クラウドサーバなど）へアクセスすることで生体情報（身体情報または環境情報など）を取得する。そして、アプリケーションバックエンド１００は、生体情報を時系列に並べることで時系列データを生成し、上記の特許文献２で開示された方法などを用いて時系列データからベースライン成分を抽出する。

そして、アプリケーションバックエンド１００は、ベースライン成分の変動に基づいて状態情報をＰ２Ｐデータベースへ登録するか否かを判断する。アプリケーションバックエンド１００は、状態情報をＰ２Ｐデータベースへ登録することを決定した場合、生体情報に対して所定の変換処理（次元圧縮処理、暗号化処理、またはハッシュ化処理など）を行うことで状態情報および付随情報を生成する。

その後、アプリケーションバックエンド１００は、状態情報および付随情報を院外サーバ３００へ提供する。これによって、院外サーバ３００は、これらの情報を用いてトランザクションデータを生成し、当該トランザクションデータをＰ２Ｐデータベースへ登録することができる。

なお、上記で説明したアプリケーションバックエンド１００の処理内容は適宜変更され得る。また、アプリケーションバックエンド１００を具現する装置の種類は特に限定されない。例えば、アプリケーションバックエンド１００は、ＰＣ（Personal Computer）、タブレットＰＣ、またはスマートフォンなどを含む任意の装置によって具現され得る。

（院内サーバ２００、院外サーバ３００）
院内サーバ２００は、Ｐ２Ｐネットワーク５００に接続しており、共有データ（Ｐ２Ｐデータベースを含む）を備えている生体情報処理装置である。院内サーバ２００は、アプリケーションバックエンド１００から提供された状態情報および付随情報を用いてトランザクションデータを生成する。そして、院内サーバ２００は、トランザクションデータを共有データに一時的に格納することで、トランザクションデータを院外サーバ３００と共有する。

院外サーバ３００は、院内サーバ２００と同様の機能を有しており、各病院に備えられるアプリケーションバックエンド（図示なし）によって生成された状態情報および付随情報を用いてトランザクションデータを生成する。そして、院外サーバ３００は、トランザクションデータを共有データに一時的に格納することで、トランザクションデータを院内サーバ２００、および他の院外サーバ３００と共有する。

そして、院内サーバ２００および院外サーバ３００は、互いに連携することで整合をとりながら各装置に備えられるＰ２Ｐデータベースを更新する（以降、当該処理を行うことを「合意形成を行う」と呼称する）。

なお、院内サーバ２００および院外サーバ３００は、Ｐ２Ｐデータベースへのトランザクションデータの登録処理だけでなく、Ｐ２Ｐデータベースからのトランザクションデータの取得処理を行うこともできる。

ここで、院内サーバ２００および院外サーバ３００がＰ２Ｐデータベースへアクセスする場合（すなわち、トランザクションデータの登録や取得などを行う場合）には、院内サーバ２００および院外サーバ３００は、基本的に、Ｐ２Ｐデータベースに設けられ、Ｐ２Ｐデータベース上で実行される所定のプログラム（以降、「Ｐ２Ｐデータベースプログラム」と呼称する）を用いる。Ｐ２Ｐデータベースプログラムが用いられることによって、例えば、Bitcoinなどのような仮想通貨の取引をはじめとする様々な処理が所定のルールに従って実現される。また、Ｐ２ＰデータベースプログラムがＰ２Ｐデータベースに設けられることによって、当該プログラムが不正に改変されるリスクが低減される。

Ｐ２Ｐデータベースプログラムは、ハイパーレッジャー（Hyperledger）におけるチェーンコードであるが、これに限定されない。例えば、Ｐ２Ｐデータベースプログラムは、スマートコントラクトを指してもよい。なお、院内サーバ２００および院外サーバ３００は、適宜、Ｐ２Ｐデータベースプログラム以外のプログラムを用いて、Ｐ２Ｐデータベースへのアクセスを実現してもよい。

また、本実施形態では、院内サーバ２００および院外サーバ３００が互いに同一の機能を有している場合を想定して説明するが、院内サーバ２００および院外サーバ３００は、互いに異なる機能を有していてもよい。例えば、Ｐ２Ｐデータベースへのトランザクションデータの登録を承認する装置（例えば、Endorsing Peer等）、承認後に各装置に対して登録を指示する装置（例えば、Ordering Peer等）、またはＰ２Ｐデータベースにトランザクションデータを登録する装置（例えば、Committing Peer等）が設けられ、これらの装置の機能を院内サーバ２００または院外サーバ３００が分担して実現してもよい。

なお、上記で説明した院内サーバ２００および院外サーバ３００の処理内容は適宜変更され得る。また、院内サーバ２００および院外サーバ３００を具現する装置の種類は特に限定されない。例えば、院内サーバ２００および院外サーバ３００は、汎用コンピュータ、ＰＣ、タブレットＰＣ、またはスマートフォンなどを含む任意の装置によって具現され得る。

（Ｐ２Ｐネットワーク５００）
Ｐ２Ｐネットワーク５００は、Ｐ２Ｐデータベースが流通しているネットワークである。上記のとおり、院内サーバ２００および院外サーバ３００は、Ｐ２Ｐネットワーク５００に接続することで他の装置と合意形成を行うことができる。

なお本実施形態において、Ｐ２Ｐネットワーク５００は、複数組織によって運営されるコンソーシアム方式のネットワークであることを想定しているが、Ｐ２Ｐネットワーク５００の種類はこれに限定されない。例えば、Ｐ２Ｐネットワーク５００は、単一組織によって運営されるプライベート方式のネットワーク、または参加者を特に限定しないパブリック方式のネットワークであってもよい。

なお、Ｐ２Ｐネットワーク５００に用いられる通信方式、または回線の種類などは特に限定されない。例えば、Ｐ２Ｐネットワーク５００は、ＩＰ−ＶＰＮ（Internet Protocol-Virtual Private Network）などの専用回線網で実現されてもよい。また、Ｐ２Ｐネットワーク５００は、インターネット、電話回線網、衛星通信網などの公衆回線網で実現されてもよい。また、Ｐ２Ｐネットワーク５００は、Ｅｔｈｅｒｎｅｔ（登録商標）を含む各種のＬＡＮ（Local Area Network）、ＷＡＮ（Wide Area Network）などで実現されてもよい。さらに、Ｐ２Ｐネットワーク５００は、Ｗｉ−Ｆｉ（登録商標）、Ｂｌｕｅｔｏｏｔｈ（登録商標）などの無線通信網で実現されてもよい。

（院内ネットワーク４００）
院内ネットワーク４００は、アプリケーションバックエンド１００および院内サーバ２００間を接続するネットワークである。なお、Ｐ２Ｐネットワーク５００と同様に、院内ネットワーク４００に用いられる通信方式、または回線の種類などは特に限定されない。

以上、本実施形態に係る生体情報処理システムの構成例について説明した。なお、図１６を参照して説明した上記の構成はあくまで一例であり、本実施形態に係る生体情報処理システムの構成は係る例に限定されない。例えば、アプリケーションバックエンド１００の機能の全部または一部は、院内サーバ２００に備えられてもよい。例えば、アプリケーションバックエンド１００の機能の全部または一部を提供するソフトウェアが院内サーバ２００で実行されてもよい。また、逆に、院内サーバ２００の機能の全部または一部が、アプリケーションバックエンド１００に備えられてもよい。本実施形態に係る生体情報処理システムの構成は、仕様や運用に応じて柔軟に変形可能である。

（２．５．各装置の機能構成例）
上記では、本実施形態に係る生体情報処理システムの構成例について説明した。続いて、各装置の機能構成例について説明する。

（２．５．１．アプリケーションバックエンド１００の機能構成例）
まず、図１７を参照して、アプリケーションバックエンド１００の機能構成例について説明する。図１７は、アプリケーションバックエンド１００の機能構成例を示すブロック図である。

図１７に示すように、アプリケーションバックエンド１００は、処理部１１０と、記憶部１２０と、通信部１３０と、入力部１４０と、出力部１５０と、を備える。

（処理部１１０）
処理部１１０は、アプリケーションバックエンド１００の処理全般を実現する機能構成である。例えば、処理部１１０は、医師の操作入力などをトリガとして、Ｐ２Ｐデータベースへの状態情報の登録に関する処理などを開始し、状態情報および付随情報などを生成した後に、これらの情報を院内サーバ２００へ提供する。また、処理部１１０は、医師の操作入力をトリガとして、患者への提案に関する処理などを開始する。なお、これらの処理が開始されるトリガは特に限定されない。また、処理部１１０によって実現される処理の内容はこれらに限定されない。例えば、処理部１１０は、ＰＣ、タブレットＰＣ、またはスマートフォンなどにおいて一般的に行われる処理（例えば、ＯＳ（Operating System）による処理など）を実現してもよい。図１７に示すように、処理部１１０は、生体情報取得部１１１と、状態情報生成部１１２と、付随情報生成部１１３と、登録判断部１１４と、提案部１１５と、を備える。

（生体情報取得部１１１）
生体情報取得部１１１は、対象者の生体情報である身体情報または環境情報の少なくともいずれか一方を取得する機能構成である。上記のとおり、身体情報は、身体測定情報、診断情報、治療情報、または手術情報などを含み、環境情報は、対象者の生活習慣に関する情報、投薬情報、または対象者によって装着されたウェアラブル端末によって取得された情報などを含むところ、生体情報取得部１１１は、病院内のストレージ、自装置に備えられる記憶部１２０、または外部のサーバなど（例えば、クラウドサーバなど）へアクセスすることでこれらの情報を取得する。例えば、生体情報が個人ＩＤなどによって管理されている場合、生体情報取得部１１１は個人ＩＤなどを用いて病院内のストレージなどの中から当該対象者の生体情報を探索し取得する。なお、Ｐ２Ｐデータベースに生体情報が登録されている場合、生体情報取得部１１１は、院内サーバ２００を介してＰ２Ｐデータベースへアクセスすることで生体情報を取得してもよい。生体情報取得部１１１は、取得した生体情報を状態情報生成部１１２、付随情報生成部１１３、および登録判断部１１４へ提供する。

（状態情報生成部１１２）
状態情報生成部１１２は、生体情報取得部１１１から提供された生体情報に基づいて対象者の生体状態を示す状態情報を生成する機能構成である。図９および図１０などを参照して説明したように、状態情報生成部１１２は、生体情報を個人情報と非個人情報に分類し、適宜、個人情報の一部に対して非個人化処理を施す（例えば、「年齢：２５歳」という情報を「年齢層：２０代」という情報へ変換する処理などを行う）。そして、状態情報生成部１１２は、非個人情報に対して次元圧縮処理による状態割振りを行うことで状態情報を生成する。

（付随情報生成部１１３）
付随情報生成部１１３は、生体情報取得部１１１から提供された生体情報に基づいて状態情報が生成される際に付随情報を生成する機能構成である。図９および図１０などを参照して説明したように、付随情報生成部１１３は、生体情報を個人情報と非個人情報に分類し、個人情報を病院内のストレージなどに保管すると共に、個人ＩＤ（例えば、患者番号など）および管理ＩＤ（例えば、電子カルテ番号など）を発行する。個人ＩＤおよび管理ＩＤが既に発行されている場合、付随情報生成部１１３は、発行元からこれらのＩＤを取得する。そして、付随情報生成部１１３は、個人ＩＤ（変換前）および管理ＩＤ（変換前）に対して所定の変換処理（例えば、暗号化処理やハッシュ化処理など）を施すことで個人ＩＤ（変換後）および管理ＩＤ（変換後）を生成し、これらのＩＤを含んだ付随情報を生成する。

（登録判断部１１４）
登録判断部１１４は、生体情報取得部１１１から提供された生体情報に基づいて状態情報が有効であるか否かを判断することで、状態情報をＰ２Ｐデータベースへ登録するか否かを判断する機能構成である。より具体的には、登録判断部１１４は、生体情報取得部１１１から提供された生体情報を時系列に並べることで時系列データを生成し、特許文献２に記載の方法などを用いて（例えば、多項式平滑化スプラインモデルを用いて）、当該時系列データからベースライン成分を抽出する。

そして、登録判断部１１４は、対象者の状態情報が前回Ｐ２Ｐデータベースに登録された時点から、ベースライン成分が所定の閾値より大きく変動したことを確認した場合に、状態情報をＰ２Ｐデータベースへ登録することを決定する。なお、対象者の状態情報が前回Ｐ２Ｐデータベースに登録された時点におけるベースライン成分の保管方法は特に限定されない。例えば、対象者の状態情報が前回Ｐ２Ｐデータベースに登録された際に、ベースライン成分が病院内のストレージなどに保管されたり、Ｐ２Ｐデータベースに登録されたりしてもよい（ベースライン成分がＰ２Ｐデータベースに登録される場合、登録判断部１１４は、院内サーバ２００を介してＰ２Ｐデータベースからベースライン成分を取得する）。

（提案部１１５）
提案部１１５は、対象者の状態情報の時系列解析を行うことで、将来のある時点における対象者の状態を予測し、この予測結果に基づいて提案を行う機能構成である。より具体的には、提案部１１５は、院内サーバ２００を介して、Ｐ２Ｐデータベースから対象者の状態情報を取得する。そして、提案部１１５は、当該状態情報を解析することで対象者の状態を認識する。なお、提案部１１５は、ある期間に生成された複数の状態情報を取得し、これらの状態情報を解析することで、当該期間における対象者の状態の遷移パターンを認識してもよい。

そして、提案部１１５は、当該対象者の状態（または状態の遷移パターン）に類似する状態（または状態の遷移パターン）を過去に有していた類似者をＰ２Ｐデータベースにおいて探索する。提案部１１５は、類似者を発見することができた場合、対象者の状態（または状態の遷移パターン）と類似する時点以降の類似者の状態情報をＰ２Ｐデータベースから取得し解析することで、類似者のその後の状態の遷移パターンを認識する。これによって、提案部１１５は、将来のある時点（ｎ年後）における対象者の状態を予測することができる。そして、提案部１１５は、ｎ年後における対象者の状態の予測結果を当該対象者に提示する。

また、将来の対象者の状態が良好ではないと予測される場合、提案部１１５は、類似者の状態の遷移パターンに基づいて対象者の状態を良好にするための方法を提示することができる。より具体的には、提案部１１５は、対象者がｎ年後になる可能性が高い状態のうち、健康的ではないと考えられるベクトル空間に位置する状態が存在すれば、健康的であると考えられるベクトル空間に位置する状態と比較することで、健康的な状態になるための方法を提案する。例えば、提案部１１５は、健康的な状態になるためにはどのように環境情報を更新すればよいかを算出し、更新に必要な情報（例えば、運動量や薬の内容など）を対象者へ提示する。また、対象者がｎ年後になる可能性が最も高い状態が健康的ではないと考えられるベクトル空間に位置する場合に、提案部１１５は、所定の環境情報（例えば、運動量や薬の内容など）を変化させるとどのように対象者の状態が変化するかを算出し、健康的だと考えられるベクトル空間に状態を移動させるための環境情報を特定して対象者へ提示してもよい。

なお、提案部１１５による提案方法は上記に限定されない。例えば、提案部１１５は、所定の機械学習の手法、または人工知能(AI：Artificial Intelligence)を用いて提案を行ってもよい。例えば、提案部１１５は、上記の手法による提案処理を相当数学習していくこと（例えば、遷移パターンと提案内容を紐づけた学習データによってパラメータ調整がなされた多層ニューラルネットワークからなる分類器を生成すること）を通して、処理に用いられるパラメータを調整することで提案の精度を向上させてもよい。

また、提案内容の対象者への提示方法は特に限定されない。例えば、提案部１１５は、出力部１５０を制御することで、提案内容をディスプレイへ表示させたり、スピーカから音声出力させたりすることで提案内容を対象者へ提示してもよい。

（記憶部１２０）
記憶部１２０は、各種情報を記憶する機能構成である。例えば、記憶部１２０は、処理部１１０による各種処理に用いられる情報や各種処理によって生成された情報（例えば、身体情報や環境情報を含む生体情報、状態情報、付随情報、個人ＩＤ、または管理ＩＤなど）を記憶する。また、記憶部１２０は、各機能構成による処理に用いられるプログラム、またはパラメータなども記憶する。なお、記憶部１２０によって記憶される情報はこれらに限定されない。

（通信部１３０）
通信部１３０は、外部装置との通信を行う機能構成である。例えば、通信部１３０は、状態情報生成部１１２によって生成された状態情報、および付随情報生成部１１３によって生成された付随情報などを院内サーバ２００へ送信したり、院内サーバ２００によってＰ２Ｐデータベースから取得された各種データなどを院内サーバ２００から受信したりする。なお、通信部１３０が通信する情報の内容はこれらに限定されない。

（入力部１４０）
入力部１４０は、医師による入力を取得する。例えば、入力部１４０は、タッチパネル、キーボード、マウス、またはボタンなどの入力機構を備えており、医師がこれらの入力機構に対して各種操作を行った場合、入力部１４０は当該操作に基づいて入力情報を生成し、処理部１１０に対して入力情報を提供する。なお、入力部１４０が備える入力機構および入力される内容は特に限定されない。

（出力部１５０）
出力部１５０は、各種出力を制御する。例えば、出力部１５０は、ディスプレイ、スピーカ、またはランプなどの出力機構を備えており、処理部１１０による処理結果などに応じて各種情報をディスプレイに表示させたり、各種音声をスピーカによって出力させたりする。なお、出力部１５０が備える出力機構および出力される内容は特に限定されない。

以上、アプリケーションバックエンド１００の機能構成例について説明した。なお、図１７を用いて説明した上記の機能構成はあくまで一例であり、アプリケーションバックエンド１００の機能構成は係る例に限定されない。例えば、アプリケーションバックエンド１００は、図１７に示す構成の全てを必ずしも備えなくてもよい。また、アプリケーションバックエンド１００の機能構成は、仕様や運用に応じて柔軟に変形可能である。

（２．５．２．院内サーバ２００の機能構成例）
続いて、図１８を参照して、院内サーバ２００の機能構成例について説明する。図１８は、院内サーバ２００の機能構成例を示すブロック図である。

図１８に示すように、院内サーバ２００は、処理部２１０と、記憶部２２０と、通信部２３０と、を備える。

（処理部２１０）
処理部２１０は、院内サーバ２００の処理全般を実現する機能構成である。例えば、処理部２１０は、アプリケーションバックエンド１００から提供される状態情報および付随情報などをＰ２Ｐデータベースへ登録する処理の開始や終了を制御する。なお、処理部２１０によって実現される処理の内容はこれに限定されない。例えば、処理部２１０は、各種サーバ、ＰＣ、タブレットＰＣ、またはスマートフォンなどにおいて一般的に行われる処理（例えば、ＯＳによる処理など）を実現してもよい。図１８に示すように、処理部２１０は、取得部２１１と、トランザクション生成部２１２と、合意形成部２１３と、を備える。

（取得部２１１）
取得部２１１は、各種情報を取得する機能構成である。例えば、取得部２１１は、通信部２３０を介してアプリケーションバックエンド１００から状態情報および付随情報などを取得する。また、取得部２１１は、Ｐ２Ｐデータベースから各種情報（例えば、対象者の状態情報など）を取得することもできる。なお、取得部２１１によって取得される情報はこれらに限定されない。

（トランザクション生成部２１２）
トランザクション生成部２１２は、Ｐ２Ｐデータベースへ登録されるトランザクションデータを生成する機能構成である。より具体的には、アプリケーションバックエンド１００から提供された状態情報および付随情報などが取得部２１１によって取得された場合、トランザクション生成部２１２は、これらの情報を含むトランザクションデータを生成する。

ここで、図１９を参照して、トランザクション生成部２１２によって生成されるトランザクションデータの具体例について説明する。図１９に示すように、例えば、トランザクション生成部２１２によって生成されるトランザクションデータは、院内サーバ２００の秘密鍵による電子署名と、院内サーバ２００の公開鍵と、院内サーバ２００のアドレスと、受信者のアドレスと、直前トランザクションデータのハッシュ値と、状態情報と、付随情報と、付随情報（対象者の属性情報のハッシュ値）と、バージョン情報と、を有する。

「院内サーバ２００の秘密鍵による電子署名」は、トランザクションデータを生成した院内サーバ２００の秘密鍵によって生成された情報であり、なりすましの検出に使用される情報である。「院内サーバ２００の秘密鍵による電子署名」は、院内サーバ２００以外の、例えば、トランザクションデータを生成した病院や医師などが保持する秘密鍵によって生成された電子署名に代替されてもよい。

「院内サーバ２００の公開鍵」は、上記の電子署名を復号することが可能な情報である。「院内サーバ２００の公開鍵」がトランザクションデータに含まれることによって、電子署名の復号結果に基づいてなりすましが行われたか否かの検証が可能になる。

「院内サーバ２００のアドレス」は、トランザクションデータを生成した院内サーバ２００を識別可能な情報である。「院内サーバ２００のアドレス」がトランザクションデータに含まれることによって、トランザクションデータの生成元の識別が可能になる。なお、「院内サーバ２００のアドレス」は、上記の「院内サーバ２００の公開鍵」や、図８に示した「生成元ＩＤ」に代替されてもよい。また、「院内サーバ２００のアドレス」は、院内サーバ２００以外の、例えば、トランザクションデータを生成した病院や医師などのアドレスに代替されてもよい。

「受信者のアドレス」は、トランザクションデータ（または、状態情報など）を受信する受信者が存在する場合に登録される情報である。「受信者のアドレス」がトランザクションデータに含まれることによって、トランザクションデータの受信者の識別が可能になる。

「直前トランザクションデータのハッシュ値」とは、対象者の状態情報が前回Ｐ２Ｐデータベースに登録されたときのトランザクションデータのハッシュ値である。「直前トランザクションデータのハッシュ値」がトランザクションデータに含まれることによって、同一の対象者に関するトランザクションデータ間の繋がりが示される（換言すると、同一対象者についての状態情報の変化が示される）。

「状態情報」は、図３などを参照して説明してきた情報である。「状態情報」がトランザクションデータに含まれることによって、対象者の生体状態の解析が可能になる。

「付随情報」は、図８などを参照して説明してきた情報である。「付随情報」がトランザクションデータに含まれることによって、病院内のストレージなどに保管されている個人ＩＤや管理ＩＤに基づいて、状態情報の対象者の特定が可能になる。

「付随情報（対象者の属性情報のハッシュ値）」は、付随情報の生成に使用された対象者の属性情報（例えば、氏名、生年月日、年齢、性別、血液型、住所、電話番号、または勤務先など）のハッシュ値である。上記の「付随情報」に基づいて状態情報の対象者を特定するためには、病院内のストレージなどに保管されている個人ＩＤや管理ＩＤの取得が必要となる。一方、「付随情報（対象者の属性情報のハッシュ値）」がトランザクションデータに含まれることによって、所定の属性情報を取得できれば状態情報の対象者の特定が可能になる。

「バージョン情報」は、トランザクションデータ（または状態情報など）の生成に用いられた方式など（または、ソフトウェアなど）のバージョンを示す情報である。「バージョン情報」がトランザクションデータに含まれることによって、トランザクションデータを取得した生体情報処理装置が、トランザクションデータを用いて適切に各種処理を行うことができる。

なお、トランザクション生成部２１２によって生成されるトランザクションデータの内容は上記に限定されない。例えば、トランザクション生成部２１２は、上記に示した情報を省略したり、上記に示していない情報を追加したりするなどしてトランザクションデータを生成してもよい。

（合意形成部２１３）
合意形成部２１３は、院外サーバ３００と合意形成に関する処理（以降、「合意形成処理」と呼称する）を行うことで、トランザクション生成部２１２によって生成されたトランザクションデータをＰ２Ｐデータベースへ登録する機能構成である（換言すると、合意形成部２１３は、状態情報をＰ２Ｐデータベースへ登録する登録部として機能する）。合意形成部２１３が行う合意形成処理の内容は特に限定されない。例えば、Ｐ２Ｐデータベースがブロックチェーンである場合、合意形成部２１３は、ブロックチェーン技術で公知のコンセンサスアルゴリズムを用いて合意形成処理を行うことができる。例えば、合意形成部２１３は、ＰＢＦＴ（Practical Byzantine Fault Tolerance）を用いて合意形成処理を行うことにより、トランザクションデータを新たなブロックに格納し、ブロックチェーンに登録することができる。なお、合意形成部２１３は、Proof of Work、Proof of Stake、Paxos、Raft、Sieveなどの他のコンセンサスアルゴリズムを用いて合意形成処理を行ってもよい。

（記憶部２２０）
記憶部２２０は、各種情報を記憶する機能構成である。例えば、記憶部２２０は、院内サーバ２００の各機能構成によって使用されるプログラム、またはパラメータなどを記憶する。なお、記憶部２２０が記憶する情報の内容はこれらに限定されない。図１８に示すように、記憶部２２０は、共有データ２２１を備える。

（共有データ２２１）
共有データ２２１は、Ｐ２Ｐネットワーク５００に接続している生体情報処理装置間で共有されるデータの集合である。各生体情報処理装置は、Ｐ２Ｐネットワーク５００を介して共有データ２２１を取得し、他の生体情報処理装置が保持する共有データと整合性を保ちながら当該共有データ２２１を更新していく。図１８に示すように、共有データ２２１は、トランザクション記憶部２２２と、Ｐ２Ｐデータベース２２３と、を備える。

（トランザクション記憶部２２２）
トランザクション記憶部２２２は、Ｐ２Ｐデータベース２２３に登録されていないトランザクションデータを記憶する機能構成である。トランザクション記憶部２２２には、トランザクション生成部２１２によって生成されたトランザクションデータ、および院外サーバ３００によって生成されてＰ２Ｐネットワーク５００を介して共有されたトランザクションデータが登録される。トランザクション記憶部２２２に登録されているトランザクションデータは、院外サーバ３００に登録されているトランザクションデータと基本的に同一である。

（Ｐ２Ｐデータベース２２３）
Ｐ２Ｐデータベース２２３は、院内サーバ２００に保持されるデータベースであり、例えば、ブロックチェーンである。上記のとおり、Ｐ２Ｐデータベース２２３には、対象者の状態情報および付随情報が含まれるトランザクションデータが登録される。なお、Ｐ２Ｐデータベース２２３に登録されるデータはこれに限定されない。例えば、Ｐ２Ｐデータベース２２３へのトランザクションデータの登録、またはＰ２Ｐデータベース２２３からのトランザクションデータの取得の際に課金が行われる場合には、Ｐ２Ｐデータベース２２３には、対象者が有する資産（例えば、Bitcoinにおけるコイン等）に関するデータが登録されていてもよい。また、Ｐ２Ｐデータベース２２３には、上記で説明したＰ２Ｐデータベースプログラムが登録されてもよい。なお、Ｐ２Ｐデータベースプログラムの開発言語、またはＰ２Ｐデータベース２２３上に設けられるＰ２Ｐデータベースプログラムの個数等は特に限定されない。

（通信部２３０）
通信部２３０は、外部装置との通信を行う機能構成である。例えば、通信部２３０は、状態情報および付随情報などをアプリケーションバックエンド１００から受信したり、取得部２１１によってＰ２Ｐデータベース２２３から取得された各種データをアプリケーションバックエンド１００へ送信したりする。また、通信部２３０は、合意形成部２１３による合意形成処理に用いられる各種情報を院外サーバ３００と送受信する。なお、通信部２３０が通信する情報の内容はこれらに限定されない。

以上、院内サーバ２００の機能構成例について説明した。なお、図１８を用いて説明した上記の機能構成はあくまで一例であり、院内サーバ２００の機能構成は係る例に限定されない。例えば、院内サーバ２００は、図１８に示す構成の全てを必ずしも備えなくてもよい。また、院内サーバ２００の機能構成は、仕様や運用に応じて柔軟に変形可能である。

また、院外サーバ３００は、院内サーバ２００と同様の機能構成を備え得るため説明を省略する。なお、院外サーバ３００は、必ずしも院内サーバ２００と同一の機能構成を備えている必要はなく、一部の機能構成を省略したり、院内サーバ２００にはない機能構成を備えたりしてもよい。

（２．６．各装置の処理フロー例）
上記では、各装置の機能構成例について説明した。続いて、各装置の処理フロー例について説明する。

（２．６．１．状態情報のＰ２Ｐデータベースへの登録処理）
まず、図２０を参照して、状態情報のＰ２Ｐデータベース２２３への登録処理について説明する。図２０は、状態情報のＰ２Ｐデータベース２２３への登録処理全体の具体例を示すフローチャートである。

ステップＳ１１００では、アプリケーションバックエンド１００の登録判断部１１４が生体情報に基づいて状態情報が有効であるか否かを判断することで、状態情報をＰ２Ｐデータベース２２３へ登録するか否かを判断する。登録判断部１１４が、状態情報をＰ２Ｐデータベース２２３へ登録すると判断した場合（ステップＳ１１０４／Ｙｅｓ）、ステップＳ１１０８にて、状態情報生成部１１２が生体情報に基づいて対象者の状態情報を生成し、付随情報生成部１１３が生体情報に基づいて付随情報を生成する。

ステップＳ１１１２では、院内サーバ２００のトランザクション生成部２１２が、アプリケーションバックエンド１００から提供された状態情報および付随情報などを用いてトランザクションデータを生成する。ステップＳ１１１６では、合意形成部２１３がＰＢＦＴなどのコンセンサスアルゴリズムを用いて合意形成処理を行うことによってトランザクションデータをＰ２Ｐデータベース２２３へ登録し、一連の処理が終了する。

なお、ステップＳ１１０４にて、登録判断部１１４が、状態情報をＰ２Ｐデータベース２２３へ登録しないと判断した場合（ステップＳ１１０４／Ｎｏ）には、ステップＳ１１０８〜ステップＳ１１１６の処理によって状態情報がＰ２Ｐデータベース２２３に登録されることなく一連の処理が終了する。

（２．６．２．状態情報のＰ２Ｐデータベースへの登録適否の判断処理）
続いて、図２０のステップＳ１１００で説明した、状態情報をＰ２Ｐデータベース２２３へ登録するか否かの判断に関する処理を、図２１を参照して説明する。図２１は、状態情報のＰ２Ｐデータベース２２３への登録適否の判断処理の具体例を示すフローチャートである。

ステップＳ１２００では、アプリケーションバックエンド１００の登録判断部１１４が、生体情報取得部１１１から提供された生体情報を時系列に並べることで時系列データを生成する。ステップＳ１２０４では、登録判断部１１４が、特許文献２に記載の方法などを用いて（例えば、多項式平滑化スプラインモデルを用いて）当該時系列データからベースライン成分を抽出する。

ステップＳ１２０８では、登録判断部１１４が、対象者の状態情報が前回Ｐ２Ｐデータベース２２３に登録された時点でのベースライン成分と、ステップＳ１２０４で抽出したベースライン成分とを比較する。そして、対象者の状態情報が前回Ｐ２Ｐデータベースに登録された時点から、ベースライン成分が所定の閾値より大きく変動している場合（ステップＳ１２１２／Ｙｅｓ）、ステップＳ１２１６にて、登録判断部１１４は、状態情報をＰ２Ｐデータベース２２３へ登録することを決定し、一連の処理が終了する。一方、対象者の状態情報が前回Ｐ２Ｐデータベースに登録された時点から、ベースライン成分が所定の閾値より大きく変動していない場合（ステップＳ１２１２／Ｎｏ）、ステップＳ１２２０にて、登録判断部１１４は、状態情報をＰ２Ｐデータベース２２３へ登録しないことを決定し、一連の処理が終了する。

（２．６．３．状態情報および付随情報の生成処理）
続いて、図２０のステップＳ１１０８で説明した、状態情報および付随情報の生成処理を、図２２を参照して説明する。図２２は、状態情報および付随情報の生成処理の具体例を示すフローチャートである。

ステップＳ１３００では、アプリケーションバックエンド１００の状態情報生成部１１２および付随情報生成部１１３が、生体情報取得部１１１から提供された生体情報を個人情報と非個人情報に分類する。ステップＳ１３０４では、状態情報生成部１１２が、個人情報の一部に対して非個人化処理を行う（例えば、「年齢：２５歳」という情報を「年齢層：２０代」という情報へ変換する処理などを行う）。ステップＳ１３０８では、状態情報生成部１１２が、非個人情報に対して次元圧縮処理による状態割振りを実施することで状態情報を生成する。

ステップＳ１３１２では、付随情報生成部１１３が、個人情報を用いて個人ＩＤ（例えば、患者番号など）および管理ＩＤ（例えば、電子カルテ番号など）を発行する。ステップＳ１３１６では、付随情報生成部１１３が、個人ＩＤ（変換前）および管理ＩＤ（変換前）に対して所定の変換処理（例えば、暗号化処理やハッシュ化処理など）を行うことで個人ＩＤ（変換後）および管理ＩＤ（変換後）を生成し、これらのＩＤを含んだ付随情報を生成する。以上によって一連の処理が終了する。

（２．６．４．状態情報に基づく提案処理）
続いて、図２３を参照して、状態情報に基づく提案処理について説明する。図２３は、状態情報に基づく提案処理の具体例を示すフローチャートである。

ステップＳ１４００では、アプリケーションバックエンド１００の提案部１１５が、院内サーバ２００を介して、対象者の状態情報をＰ２Ｐデータベース２２３から取得する。ステップＳ１４０４では、提案部１１５が当該状態情報を解析することで対象者の状態を認識した上で、当該対象者の状態（または状態の遷移パターン）に類似する状態（または状態の遷移パターン）を過去に有していた類似者をＰ２Ｐデータベース２２３にて探索する。

Ｐ２Ｐデータベース２２３にて類似者が発見された場合（ステップＳ１４０８／Ｙｅｓ）、ステップＳ１４１２にて、提案部１１５は、対象者の状態（または状態の遷移パターン）と類似する時点以降の類似者の状態情報をＰ２Ｐデータベース２２３から取得し解析することで、類似者のその後の状態の遷移パターンを認識する。ステップＳ１４１６では、提案部１１５は、類似者のその後の状態の遷移パターンに基づいて対象者の状態の遷移パターンを予測し、対象者へ提示する。

ステップＳ１４２０では、提案部１１５が対象者の状態を改善するための改善案を提案する。例えば、将来のある時点において対象者がなる可能性が高い状態のうち、健康的ではないと考えられるベクトル空間に位置する状態が存在すれば、提案部１１５は、健康的であると考えられるベクトル空間に位置する状態と比較することで、健康的な状態になるための方法を提案する。以上によって一連の処理が終了する。

なお、Ｐ２Ｐデータベース２２３にて類似者が発見されなかった場合（ステップＳ１４０８／Ｎｏ）、ステップＳ１４２４にて、提案部１１５は、類似者が発見されなかった旨を出力し、一連の処理が終了する。

（２．７．用途事例）
上記では、各装置の処理フロー例について説明した。続いて、本実施形態に係る生体情報処理システムの用途事例について説明する。

上記のように、対象者の状態情報がＰ２Ｐデータベース２２３に登録されることで、Ｐ２Ｐネットワーク５００にアクセス可能な装置は、当該状態情報を用いて様々なサービスを提供することができる。上記の図２３などでは、医師などが使用するアプリケーションバックエンド１００が対象者に対して改善案を提案することができる旨を説明したところ、状態情報の利用方法はこれに限定されない。

例えば、任意のソリューション提供者であるＸ社（例えば、薬などの製品を製造するメーカーや、トレーニングジムなどサービス提供会社など）が、状態情報を用いてサービスを提供してもよい。

例えば、図２４のステップＳ１５００にて、対象者がスマートフォンなどの電子機器を操作することで、Ｘ社が運営する診断アプリケーションを起動する。ステップＳ１５０４では、対象者が、当該アプリケーションに対して情報提供に同意する旨の入力を行い、併せて、予め用意された個人ＩＤ（変換前）とパスワードを入力する。ステップＳ１５０８では、当該アプリケーションがパスワード認証を行い、当該認証に成功した場合には、個人ＩＤ（変換前）に対して所定の変換処理（例えば、暗号化処理やハッシュ化処理など）を施すことによって個人ＩＤ（変換後）を生成する。

ステップＳ１５１２では、当該アプリケーションが、所定のＡＰＩを介してＰ２Ｐネットワーク５００へアクセスし、個人ＩＤ（変換後）を用いてＰ２Ｐデータベース２２３から対象者の状態情報を抽出する。そして、ステップＳ１５１６では、当該アプリケーションが状態情報を用いて図２３で説明したような提案処理を実施する。例えば、対象者がｎ年後になる可能性が最も高い状態が健康的ではないと考えられるベクトル空間に位置する場合に、Ｘ社のアプリケーションは、Ｘ社の製品の提供やＸ社によるサービスの提供を環境情報として入力すると対象者の状態がどのように変化するかを算出し、健康的だと考えられるベクトル空間に状態を移動させるための製品やサービスの内容を特定して提案する。

このように、本実施形態に係る生体情報処理システムは、対象者に対して製品やサービスを提供する様々な提供者によって広く利用され得る。

他にも例えば、Ｐ２Ｐデータベース２２３に記録された状態情報を地域や年齢ごとに集約して解析を行うことで、感染病の拡大度合いや地域病の検出を行うこともできる。例えば、所定の期間ごとにＰ２Ｐデータベース２２３に記録された状態情報を取得し、状態情報から状態コードおよび身体コードに含まれる病院が位置する地域を抽出する。さらに抽出した情報を時系列の統計解析、例えば自己回帰モデルまたは移動平均モデルによる解析を行う。これにより、地域ごとの状態コードが期間により統計的な変化を有するかどうか、例えば高熱状態の人が徐々に増えているかどうかや、他地域に比べて高熱状態の人が多い等を解析することができる。なお、年代ごとに解析を行うことでより精度を向上することができる。

なお、上記で説明した図２０〜図２４のフローチャートにおける各ステップは、必ずしも記載された順序に沿って時系列に処理される必要はない。すなわち、フローチャートにおける各ステップは、記載された順序と異なる順序で処理されても、並列的に処理されてもよい。

（２．８．各装置のハードウェア構成例）
上記では、各装置の処理フロー例について説明した。続いて、図２５を参照して、各装置のハードウェア構成例について説明する。

図２５は、アプリケーションバックエンド１００、または院内サーバ２００（または院外サーバ３００）のハードウェア構成の一例を示すブロック図である。これらの装置は、図２５に示す情報処理装置９００によって具現され得る。

情報処理装置９００は、例えば、ＭＰＵ９０１と、ＲＯＭ９０２と、ＲＡＭ９０３と、記録媒体９０４と、入出力インタフェース９０５と、操作入力デバイス９０６と、表示デバイス９０７と、通信インタフェース９０８とを備える。また、情報処理装置９００は、例えば、データの伝送路としてのバス９０９で各構成要素間を接続する。

ＭＰＵ９０１は、例えば、ＭＰＵなどの演算回路で構成される、１または２以上のプロセッサや、各種処理回路などで構成され、アプリケーションバックエンド１００の処理部１１０、または院内サーバ２００の処理部２１０として機能する。なお、これらの機能構成は、上記で説明した各種処理を実現可能な専用の（または汎用の）回路（例えば、ＭＰＵ９０１とは別体のプロセッサなど）で構成されていてもよい。

ＲＯＭ９０２は、ＭＰＵ９０１が使用するプログラムや演算パラメータなどの制御用データなどを記憶する。ＲＡＭ９０３は、例えば、ＭＰＵ９０１により実行されるプログラムなどを一時的に記憶する。

記録媒体９０４は、アプリケーションバックエンド１００の記憶部１２０、または院内サーバ２００の記憶部２２０として機能し、情報処理に関するデータや各種プログラムなど様々なデータを記憶する。ここで、記録媒体９０４としては、例えば、ハードディスクなどの磁気記録媒体や、フラッシュメモリなどの不揮発性メモリが挙げられる。また、記録媒体９０４は、情報処理装置９００から着脱可能であってもよい。

入出力インタフェース９０５は、例えば、操作入力デバイス９０６や、表示デバイス９０７を接続する。ここで、入出力インタフェース９０５としては、例えば、ＵＳＢ（Universal Serial Bus）端子や、ＤＶＩ（Digital Visual Interface）端子、ＨＤＭＩ（High-Definition Multimedia Interface）（登録商標）端子、各種処理回路などが挙げられる。

また、操作入力デバイス９０６は、例えば、情報処理装置９００上に備えられ、情報処理装置９００の内部で入出力インタフェース９０５と接続される。操作入力デバイス９０６としては、例えば、キーボード、マウス、キーパッド、タッチパネル、マイクロホン、操作ボタン、方向キーまたはジョグダイヤルなどの回転型セレクタ、あるいは、これらの組み合わせなどが挙げられる。操作入力デバイス９０６は、アプリケーションバックエンド１００の入力部１４０として機能する。

また、表示デバイス９０７は、例えば、情報処理装置９００上に備えられ、情報処理装置９００の内部で入出力インタフェース９０５と接続される。表示デバイス９０７としては、例えば、液晶ディスプレイ（Liquid Crystal Display）や有機ＥＬディスプレイ（Organic Electro-Luminescence Display）などが挙げられる。表示デバイス９０７は、アプリケーションバックエンド１００の出力部１５０として機能する。

なお、入出力インタフェース９０５が、情報処理装置９００の外部の操作入力デバイスや外部の表示デバイスなどの外部デバイスと接続することも可能であることは、言うまでもない。また、表示デバイス９０７は、例えばタッチパネルなど、表示とユーザ操作とが可能なデバイスであってもよい。

通信インタフェース９０８は、情報処理装置９００が備える通信手段であり、アプリケーションバックエンド１００の通信部１３０、または院内サーバ２００の通信部２３０として機能する。また、通信インタフェース９０８は、任意のネットワークを介して（あるいは、直接的に）、サーバなどの任意の外部装置と無線または有線で通信を行う機能を有していてもよい。ここで、通信インタフェース９０８としては、例えば、通信アンテナおよびＲＦ（Radio Frequency）回路（無線通信）や、ＩＥＥＥ８０２．１５．１ポートおよび送受信回路（無線通信）、ＩＥＥＥ８０２．１１ポートおよび送受信回路（無線通信）、あるいはＬＡＮ（Local Area Network）端子および送受信回路（有線通信）などが挙げられる。

なお、情報処理装置９００のハードウェア構成は、図２５に示す構成に限られない。例えば、情報処理装置９００は、接続されている外部の通信デバイスを介して通信を行う場合には、通信インタフェース９０８を備えていなくてもよい。また、通信インタフェース９０８は、複数の通信方式によって通信を行うことが可能な構成であってもよい。また、情報処理装置９００は、例えば、操作入力デバイス９０６または表示デバイス９０７等を備えなくてもよい。また、例えば、図２５に示す構成の全部または一部は、１または２以上のＩＣ（Integrated Circuit）で実現されてもよい。

続いて、上記で説明した機械学習手法による次元圧縮について詳細に説明する。ここでは、次元圧縮処理を多層ニューラルネットワークの一種であるＳＡＥ（Stacked Auto-Encoders）で実現する場合について述べる。ＳＡＥとは、Ａｕｔｏ−Ｅｎｃｏｄｅｒと呼ばれるニューラルネットワークを積み重ねて多層とした構成のニューラルネットワークである。ＳＡＥにおいては、学習データに基づき、ＳＡＥのパラメータ（これは各層のネットワーク係数を意味する）が調整される。ここで、Ａｕｔｏ−Ｅｎｃｏｄｅｒとは、入力層と出力層のニューロン数（ユニット数ともいう）が同数であり、かつ、中間層（隠れ層ともいう）のニューロン数が入力層（または出力層）より少ない構成のニューラルネットワークである。このとき、ＳＡＥの学習は、ＳＡＥを構成するＡｕｔｏ−Ｅｎｃｏｄｅｒ毎に行われ、例えば学習データを用いた誤差逆伝搬法による学習が行われ、パラメータ調整が行われる。

例えば、５層から構成されるＳＡＥの各層の次元数を４９次元、１６次元、３次元、１６次元、４９次元として、次元圧縮と次元復元が行われながら生体情報と状態が紐づけられた学習データにより学習が行われ、適切な分類が可能なパラメータ調整が行われることで分類器が生成される。この分類器に生体情報が入力されると、３次元までの圧縮が行われ、３次元空間ベクトル上の数値に変換される。このとき、状態の分類まで行われてもよい。これにより、機械学習手法を用いることで、次元圧縮された任意のｎ次元空間ベクトル上の数値または分類結果を生成することができる。このとき、ｎ次元空間ベクトル上の数値が状態（または状態コード）として扱われる、または分類結果が状態（または状態コード）として扱われる。なお、次元圧縮の次元数は設計事項であり、分類が可能であれば３次元に限られず、任意の次元数が採用され得る。また、次元圧縮が可能であれば機械学習の手法は特に制限されない。

これにより、例えば「アトピー性皮膚炎Ａ型で右上腕部に赤みが多数あり、ＢＭＩは２０であり、…」という情報を「アレルギーにより皮膚炎症を起こしやすいタイプ１であり反応度合いはレベル２、ＢＭＩは平均を示す５であり、…」というようにテーブル変換し、数列ベクトルＸ（１、２、２、…）を生成することが可能となる。所定の状態と数列ベクトルを含む学習データにより予めパラメータ調整が行われたニューラルネットワークに、上記数列ベクトルＸを入力することで、状態Ｙを生成することができる。なお、状態Ｙはｎ次元空間ベクトル上の数値であってもよいし、予め用意したテーブルに沿って分類された結果であってもよい。

例えば、所定の規格に基づいて、生体情報を身長や体重、ＭＢＩなどの項目ごとにａ１＝身長、ａ２＝体重、と入力することで、ｎ次元の情報を有する行列｛a1，a2，a3，…, an｝を生成する。そして、多層ニューラルネットワークによる機械学習モデルに入力して行列｛b1, b2｝という二次元の情報に圧縮する。この機械学習モデルは、多層ニューラルネットワークにｎ次元の情報と二次元の情報とが紐づいた学習データを学習してパラメータが設定された機械学習モデルである。これにより、ｎ次元の情報を二次元に圧縮し、行列｛b1, b2｝という状態に割り振ることが可能となる。なお、上記は生体情報を１行ｎ列の行列として表して１行２列の行列に次元圧縮する手法について説明したが、計算モデルに合わせて任意の行列形式をとってもよい。また、同一人物に関して１回目の測定時の生体情報を行列Ｔ１｛a1, a2, a3, …,an｝で表し、２回目の測定時の生体情報を行列Ｔ２｛b1, b2, b3, …, bn｝で表し、行列Ｔ１と行列Ｔ２を連結してもよい。すなわち、１行目が行列Ｔ１、２行目が行列Ｔ２の行列Ｔｎを生成する。この行列Ｔｎを上記と同様に多層ニューラルネットワークに入力することで二次元の情報に圧縮して状態割り振りを行ってもよい。

＜３．まとめ＞
以上で説明してきたように、本開示に係る生体情報処理装置（例えば、アプリケーションバックエンド１００）は、対象者の生体情報を取得し、当該生体情報に基づいて対象者の生体状態を示す状態情報を生成し、当該状態情報をＰ２Ｐデータベース２２３（ブロックチェーンを含む）に登録する。より具体的には、生体情報処理装置は、次元圧縮処理によって生体情報を符号化することで対象者の生体状態を示す状態コードを生成し、当該状態コードを含めた状態情報をＰ２Ｐデータベース２２３に登録する。生体情報が次元圧縮処理によって符号化されることによって、個人がより特定されにくくなり、状態情報のデータサイズがより小さくなる。また、状態情報がＰ２Ｐデータベース２２３に登録されることによって、状態情報の真正性が担保された状態で状態情報が他の病院に連携される。また、状態情報が所定の規格によって標準化されることによって、各病院は状態情報を適切に解析し活用することができる。

また、生体情報処理装置は、所定の方法により状態情報の時系列解析を行うことで、対象者の状態の遷移パターンを認識することができるため、疾病発症の背景などを対象者ごとに把握することができる。また、生体情報処理装置は、医師による診断情報だけでなく環境情報なども考慮した上で状態情報を生成するため、高い精度で対象者の状態情報を算出することができる。これによって、本開示に係る生体情報処理装置は、個別医療の実現（または、対症療法の改善など）に寄与することができる。

以上、添付図面を参照しながら本開示の好適な実施形態について詳細に説明したが、本開示の技術的範囲はかかる例に限定されない。本開示の技術分野における通常の知識を有する者であれば、請求の範囲に記載された技術的思想の範疇内において、各種の変更例または修正例に想到し得ることは明らかであり、これらについても、当然に本開示の技術的範囲に属するものと了解される。

また、本明細書に記載された効果は、あくまで説明的または例示的なものであって限定的ではない。つまり、本開示に係る技術は、上記の効果とともに、または上記の効果に代えて、本明細書の記載から当業者には明らかな他の効果を奏しうる。

なお、以下のような構成も本開示の技術的範囲に属する。
（１）
対象者の生体情報を取得するステップと、
前記生体情報に基づいて前記対象者の生体状態を示す状態情報を生成するステップと、
前記状態情報をＰ２Ｐデータベースに登録するステップと、を含む、
生体情報処理方法。
（２）
前記状態情報は、所定の方法によって前記生体情報が符号化されることで生成された、前記生体状態を示す状態コードを含む、
前記（１）に記載の生体情報処理方法。
（３）
前記生体情報は、前記対象者の身体に関する情報である身体情報、または前記対象者に影響を及ぼす環境に関する情報である環境情報のうちの少なくともいずれか一方を含む、
前記（２）に記載の生体情報処理方法。
（４）
前記状態コードは、前記所定の方法によって前記身体情報が符号化されることで生成された身体コード、または前記所定の方法によって前記環境情報が符号化されることで生成された環境コードのうちの少なくともいずれか一方が前記所定の方法によって符号化されることで生成される、
前記（３）に記載の生体情報処理方法。
（５）
前記状態情報は、前記身体コード、または前記環境コードのうちの少なくともいずれか一方を前記状態コードの他に含む、
前記（４）に記載の生体情報処理方法。
（６）
前記状態情報は、前記所定の方法を示す方法コードを前記状態コードの他に含む、
前記（２）から（５）のいずれか１項に記載の生体情報処理方法。
（７）
前記生体情報処理方法は、前記所定の方法として前記生体情報の次元を圧縮することで前記状態コードを生成する、
前記（２）から（６）のいずれか１項に記載の生体情報処理方法。
（８）
前記生体情報処理方法は、テーブル変換、または機械学習の手法のうちの少なくともいずれか一方によって前記次元を圧縮する、
前記（７）に記載の生体情報処理方法。
（９）
前記身体情報は、前記対象者の身体測定情報、診断情報、治療情報、または手術情報のうちの少なくともいずれか一つを含む、
前記（３）から（５）のいずれか１項に記載の生体情報処理方法。
（１０）
前記環境情報は、前記対象者の生活習慣に関する情報、投薬情報、または前記対象者によって装着されたウェアラブル端末によって取得された情報のうちの少なくともいずれか一つを含む、
前記（３）から（５）のいずれか１項に記載の生体情報処理方法。
（１１）
前記生体情報が時系列に並べられた時系列データから、前記時系列データにおける不可逆的な変化を示すベースライン成分を抽出するステップと、
前記ベースライン成分の変動に基づいて前記状態情報の前記Ｐ２Ｐデータベースへの登録を制御するステップと、をさらに含む、
前記（１）から（１０）のいずれか１項に記載の生体情報処理方法。
（１２）
前記生体情報処理方法は、前記対象者の前記状態情報が前記Ｐ２Ｐデータベースに前回登録された時点から、前記ベースライン成分が所定の閾値より大きく変動したことを確認した場合に、前記状態情報を前記Ｐ２Ｐデータベースへ登録することを決定する、
前記（１１）に記載の生体情報処理方法。
（１３）
前記対象者の生体状態を示す状態情報と、他の対象者の生体状態を示す他の状態情報とを比較することで、前記対象者に類似する生体状態を過去に有していた類似者を前記他の対象者の中から抽出するステップと、
前記類似者の生体状態の遷移パターンに基づいて、将来の前記対象者の生体状態の遷移パターンを予測するステップと、をさらに含む、
前記（１）から（１２）のいずれか１項に記載の生体情報処理方法。
（１４）
将来の前記対象者の生体状態が良好ではないと予測される場合、前記類似者の生体状態の遷移パターンに基づいて、前記対象者の生体状態を良好にするための方法を提示するステップをさらに含む、
前記（１３）に記載の生体情報処理方法。
（１５）
前記Ｐ２Ｐデータベースはブロックチェーンである、
前記（１）から（１４）のいずれか１項に記載の生体情報処理方法。
（１６）
対象者の生体情報を取得する生体情報取得部と、
前記生体情報に基づいて前記対象者の生体状態を示す状態情報を生成する状態情報生成部と、
前記状態情報をＰ２Ｐデータベースに登録する登録部と、を備える、
生体情報処理装置。
（１７）
対象者の生体情報を取得する生体情報取得部と、
前記生体情報に基づいて前記対象者の生体状態を示す状態情報を生成する状態情報生成部と、
前記状態情報をＰ２Ｐデータベースに登録する登録部と、を備える、
生体情報処理システム。
（１８）
対象者の生体情報を取得するステップと、
前記生体情報に基づいて前記対象者の生体状態を示す状態情報を生成するステップと、
前記状態情報を分散ネットワークのデータとして登録するステップと、を含む、
生体情報処理方法。

１００ アプリケーションバックエンド
１１０ 処理部
１１１ 生体情報取得部
１１２ 状態情報生成部
１１３ 付随情報生成部
１１４ 登録判断部
１１５ 提案部
１２０ 記憶部
１３０ 通信部
１４０ 入力部
１５０ 出力部
２００ 院内サーバ
２１０ 処理部
２１１ 取得部
２１２ トランザクション生成部
２１３ 合意形成部
２２０ 記憶部
２２１ 共有データ
２２２ トランザクション記憶部
２２３ Ｐ２Ｐデータベース
２３０ 通信部
３００ 院外サーバ
４００ 院内ネットワーク
５００ Ｐ２Ｐネットワーク

Claims (18)

1. 対象者の生体情報を取得するステップと、
   前記生体情報に基づいて前記対象者の生体状態を示す状態情報を生成するステップと、
   前記状態情報をＰ２Ｐデータベースに登録するステップと、を含む、
   生体情報処理方法。
2. 前記状態情報は、所定の方法によって前記生体情報が符号化されることで生成された、前記生体状態を示す状態コードを含む、
   請求項１に記載の生体情報処理方法。
3. 前記生体情報は、前記対象者の身体に関する情報である身体情報、または前記対象者に影響を及ぼす環境に関する情報である環境情報のうちの少なくともいずれか一方を含む、
   請求項２に記載の生体情報処理方法。
4. 前記状態コードは、前記所定の方法によって前記身体情報が符号化されることで生成された身体コード、または前記所定の方法によって前記環境情報が符号化されることで生成された環境コードのうちの少なくともいずれか一方が前記所定の方法によって符号化されることで生成される、
   請求項３に記載の生体情報処理方法。
5. 前記状態情報は、前記身体コード、または前記環境コードのうちの少なくともいずれか一方を前記状態コードの他に含む、
   請求項４に記載の生体情報処理方法。
6. 前記状態情報は、前記所定の方法を示す方法コードを前記状態コードの他に含む、
   請求項２に記載の生体情報処理方法。
7. 前記生体情報処理方法は、前記所定の方法として前記生体情報の次元を圧縮することで前記状態コードを生成する、
   請求項２に記載の生体情報処理方法。
8. 前記生体情報処理方法は、テーブル変換、または機械学習の手法のうちの少なくともいずれか一方によって前記次元を圧縮する、
   請求項７に記載の生体情報処理方法。
9. 前記身体情報は、前記対象者の身体測定情報、診断情報、治療情報、または手術情報のうちの少なくともいずれか一つを含む、
   請求項３に記載の生体情報処理方法。
10. 前記環境情報は、前記対象者の生活習慣に関する情報、投薬情報、または前記対象者によって装着されたウェアラブル端末によって取得された情報のうちの少なくともいずれか一つを含む、
    請求項３に記載の生体情報処理方法。
11. 前記生体情報が時系列に並べられた時系列データから、前記時系列データにおける不可逆的な変化を示すベースライン成分を抽出するステップと、
    前記ベースライン成分の変動に基づいて前記状態情報の前記Ｐ２Ｐデータベースへの登録を制御するステップと、をさらに含む、
    請求項１に記載の生体情報処理方法。
12. 前記生体情報処理方法は、前記対象者の前記状態情報が前記Ｐ２Ｐデータベースに前回登録された時点から、前記ベースライン成分が所定の閾値より大きく変動したことを確認した場合に、前記状態情報を前記Ｐ２Ｐデータベースへ登録することを決定する、
    請求項１１に記載の生体情報処理方法。
13. 前記対象者の生体状態を示す状態情報と、他の対象者の生体状態を示す他の状態情報とを比較することで、前記対象者に類似する生体状態を過去に有していた類似者を前記他の対象者の中から抽出するステップと、
    前記類似者の生体状態の遷移パターンに基づいて、将来の前記対象者の生体状態の遷移パターンを予測するステップと、をさらに含む、
    請求項１に記載の生体情報処理方法。
14. 将来の前記対象者の生体状態が良好ではないと予測される場合、前記類似者の生体状態の遷移パターンに基づいて、前記対象者の生体状態を良好にするための方法を提示するステップをさらに含む、
    請求項１３に記載の生体情報処理方法。
15. 前記Ｐ２Ｐデータベースはブロックチェーンである、
    請求項１に記載の生体情報処理方法。
16. 対象者の生体情報を取得する生体情報取得部と、
    前記生体情報に基づいて前記対象者の生体状態を示す状態情報を生成する状態情報生成部と、
    前記状態情報をＰ２Ｐデータベースに登録する登録部と、を備える、
    生体情報処理装置。
17. 対象者の生体情報を取得する生体情報取得部と、
    前記生体情報に基づいて前記対象者の生体状態を示す状態情報を生成する状態情報生成部と、
    前記状態情報をＰ２Ｐデータベースに登録する登録部と、を備える、
    生体情報処理システム。
18. 対象者の生体情報を取得するステップと、
    前記生体情報に基づいて前記対象者の生体状態を示す状態情報を生成するステップと、
    前記状態情報を分散ネットワークのデータとして登録するステップと、を含む、
    生体情報処理方法。

Images