WO2021181634A1

WO2021181634A1 - 教師データ収集依頼装置および教師データ収集方法

Info

Publication number: WO2021181634A1
Application number: PCT/JP2020/010949
Authority: WO
Inventors: 野中　修; 智子後町; 学市川; 弘達藤原; 亮櫻井
Original assignee: オリンパス株式会社
Priority date: 2020-03-12
Filing date: 2020-03-12
Publication date: 2021-09-16
Also published as: JPWO2021181634A1; US20220384053A1; JP7393518B2; CN114616633A

Abstract

新しい事象が起きた際に、この事象に至った過程を示す情報を容易に収集し、またこの収集した情報を基に推論モデル生成用の教師データを作成する教師データ収集依頼装置および教師データ収集方法を提供する。　医師が特定の患者の病状に関する情報を入力する入力ステップ（Ｓ５）と、患者の過去の時系列データを取得可能な機器を特定する機器特定ステップ（Ｓ１１）と、特定された機器と同様の機器を有する別の人の時系列データと、診察情報を教師データ化して学習を依頼する学習依頼ステップを実行する。　

Description

教師データ収集依頼装置および教師データ収集方法

　本発明は、医師等の専門家による日々の検査や診察の中で、新たな事象を見出した際に、この事象に至った過程を示す情報を容易に収集し、またこの収集した情報を基に推論モデル生成用の教師データを作成することができる教師データ収集依頼装置および教師データ収集方法に関する。

　自然言語処理やディープラーニング技術等の人工知能関連技術を用いて、テキストや画像などの情報を、複数のカテゴリのうちいずれかのカテゴリに分類する技術が知られている。しかし、人工知能に教師データを学習させたり、人工知能の分類結果を評価したり、異なる教師データを学習させた人工知能を切り替えて分類させるといった作業は、サービス提供者にとって煩雑な作業であり、サービス提供者にとって大きな負担となる。

　そこで、サービス提供者の負担を軽減するために、対象データと教師データを用いた学習結果に基づいて対象データを分類する学習モデルの特徴との対応関係を記憶しておき、クライアントから対象データを取得し、この対象データに対応した特徴を持つ学習モデルを指定して、対象データを分類させるようにした分類支援装置が提案されている（特許文献１参照）。

特開２０１８－０２８７９５号公報

　上述の分類支援装置は、既に用意されている分類モデルに分類する際に、支援を行うことができる。しかし、新しい事象が起きた際に、この事象に至った過程を示す情報を容易に収集し、またこの収集した情報を基に推論モデル生成用の教師データを作成することについては記載されていない。

　本発明は、このような事情を鑑みてなされたものであり、新しい事象が起きた際に、この事象に至った過程を示す情報を容易に収集し、またこの収集した情報を基に推論モデル生成用の教師データを作成する教師データ収集依頼装置および教師データ収集方法を提供することを目的とする。

　上記目的を達成するため第１の発明に係る教師データ収集依頼装置は、医師が特定の患者の病状に関する情報を入力する入力部と、上記患者の過去の時系列データを取得可能な機器を特定する機器特定部と、上記機器特定部によって特定された機器と同様の機器を使用している別の人について、上記同様の機器を用いて収集したデータと、診察情報と、を教師データ化して学習を依頼する学習依頼部と、とを有する。

　第２の発明に係る教師データ収集依頼装置は、上記第１の発明において、上記学習依頼部は、学習を依頼して作成する推論モデルの入出力の関係が、上記同様の機器によって収集した収集データが入力となり、医師によって入力された患者の病状に対応する情報が出力となるように、上記教師データを収集する。
　第３の発明に係る教師データ収集依頼装置は、上記第２の発明において、上記教師データ収集依頼装置は、さらにデータ収集用の機器の選択を行うために、機器を表示する表示部を有し、上記機器特定部は、上記表示部に表示された機器の中から特定する。

　第４の発明に係る教師データ収集依頼装置は、上記第２の発明において、教師データを使って学習した上記推論モデルの想定結果は、特定の検体情報および／または生体情報を入力とし、出力を診断補助情報とする。

　第５の発明に係る教師データ収集依頼装置は、上記第１の発明において、複数の対象物と、複数の時点における特定情報の経時変化とを取得可能な機器を表示部に一覧表示させる表示制御部を有する。

　第６の発明に係る教師データ収集依頼装置は、上記第１の発明において、複数の時点における特定情報の経時変化を表示部に一覧表示させる表示制御部を有する。
　第７の発明に係る教師データ収集依頼装置は、上記第１の発明において、上記学習依頼部に依頼して生成した推論モデルに、患者の過去の時系列データを入力し、取得した診断補助情報を表示部に表示させる表示制御部を有する。

　第８の発明に係る教師データ収集装置は、医師が特定の患者に対して診断した結果に基づいて、上記患者の病状に関する情報を入力する入力部と、上記患者の過去の時系列データを取得可能な機器を特定する機器特定部と、上記機器特定部によって特定された機器と同様の機器を使用別の人について、上記同様の機器を用いて収集したデータと、診察情報と、を教師データ化して学習を依頼する学習依頼部と、とを有する。
　第９の発明に係る教師データ収集方法は、特定の患者の病状に関する情報を入力する入力ステップと、上記患者の過去の時系列データを取得可能な機器を特定する機器特定ステップと、上記特定された機器と同様の機器を有する別の人の時系列データの収集を依頼する依頼ステップと、とを有する。

　第１０の発明に係る記録媒体は、教師データ収集装置に設けられたコンピュータに、特定の患者の病状に関する情報を入力する入力ステップと、上記患者の過去の時系列データを取得可能な機器を特定する機器特定ステップと、上記特定された機器と同様の機器を有する別の人の時系列データの収集を依頼する依頼ステップと、を実行させるためのプログラムを記憶する。
　第１１の発明に係る記録媒体は、教師データ収集装置に設けられたコンピュータに、医師が特定の患者に対して診断した結果に基づいて、上記患者の病状に関する情報を入力する入力ステップと、上記患者の過去の時系列データを取得可能な機器を特定する機器特定ステップと、上記機器特定ステップによって特定された機器と同様の機器を使用別の人について、上記同様の機器を用いて収集したデータと、診察情報と、を教師データ化して学習を依頼する学習依頼ステップと、を実行させるためのプログラムを記憶する。

　本発明によれば、新しい事象が起きた際に、この事象に至った過程を示す情報を容易に収集し、またこの収集した情報を基に推論モデル生成用の教師データを作成する教師データ収集依頼装置および教師データ収集方法を提供することができる。

本発明の一実施形態に係る教師データ収集システムの全体構成を示すブロック図である。本発明の一実施形態に係る教師データ収集システムの全体構成を示すブロック図である。本発明の一実施形態に係る教師データ収集システムにおける学習用データの例を示す図である。発明の一実施形態に係る教師データ収集システムのＤＢ部に記録されるデータの一例を示す図である。発明の一実施形態に係る教師データ収集システムにおいて、医師操作用表示部における表示例を示す図である。発明の一実施形態に係る教師データ収集システムにおいて、医師操作用表示部における経時変化を示す表示例を示す図である。発明の一実施形態に係る教師データ収集システムにおいて、医師操作用表示部におけるメニュー画面の表示例を示す図である。発明の一実施形態に係る教師データ収集システムにおいて、医師操作用表示部における患者選択画面の表示例を示す図である。発明の一実施形態に係る教師データ収集システムにおいて、医師操作用表示部における診断入力画面の表示例を示す図である。発明の一実施形態に係る教師データ収集システムにおいて、制御部の動作の一例を示すフローチャートである。発明の一実施形態に係る教師データ収集システムにおいて、制御部の動作の一例を示すフローチャートである。発明の一実施形態に係る教師データ収集システムにおいて、制御部の動作の他の例を示すフローチャートである。発明の一実施形態に係る教師データ収集システムにおいて、制御部の動作の他の例を示すフローチャートである。

　以下、本発明の一実施形態として、ＩＴプラットフォーム等を活用したデータ収集システムに本発明を適用した例について説明する。本実施形態に係るデータ収集システムは、多数の装置の出力データを収集し、この収集したデータを教師データとして学習することによって生成された推論モデルを用いて推論を行う。医師等の専門家が、日々、診察や健診の際に、対象者（ユーザ、患者）が意識していない病状等、正常な状態からの心身の変化を発見する場合がある。この場合、医師等が、対象者が使用している検査機器をデータ収集システムに入力すると、この対象者が検査機器によって習得した過去の時系列データを取得することができる。このデータを見ることによって、対象者のそれまでの過程を確認することができ、疾病等の判断する際の参考になる。

　また、データ収集システムは、対象者に限らず他の者が同様の機器を用いて検査した検査データを収集し、この収集したデータを表示することができる。専門家は、この他の者のデータを参考にすることによって、さらに精度の高い診断を行うことができる。

　また、医師等の専門家は、データ収集システムが収集したデータを教師データとして、推論モデルの生成を依頼することができる。この推論モデルは、見慣れない症状の際に、どのような疾病であるか、今後の症状の推移（例えば、いつ頃、悪化し医院に行くことになるか等）、治療方法等を推論することができる。なお、専門家の補助者が専門家の指導のもとで、専門家以外の人を補佐する等の応用が可能であることは言うまでもない。また、補助者や専門家以外の人が、専門家の方法を真似し、この行為を推論によって、チェックしてもらう方法等があるが、このような様々なケースにおいても、その来歴が明確化されていればよい。図２（ａ）に示すデータファイルのメタデータにアノテーションを付した人の分類やＩＤ等を記録できるようにし、専門家が行ったアノテーション結果に対しては、教師データの重みづけを重くするなどの工夫を行うようにしてもよい。

　また、本実施形態においては、データ収集システムは、ユーザ（対象者）の状況を考慮することによって正確な健康状態を把握し、カスタマイズ情報を提供するために、例えば、日々、健康状態に関する検査データを第１機器や第２機器等の検査機器によってモニタリングし、これらのデータを収集する。このデータ収取システムが収集したデータに基づいて、健康に関する情報を提供する。すなわち、この教師データ収集システムは、日々、複数の機器を用いて、ユーザの健康状態に関する検査データをモニタリングしている。

　このモニタリングによって取得した履歴データを用いて、ユーザに健康に関するアドバイスを表示することができる。また、アドバイスを提示するにあたっては、モニタリングで収集したデータを、推論モデルが設定された推論エンジンに入力し、推論エンジンの推論結果に基づいてアドバイスを表示することもできる。

　なお、この取得したデータは、何か特定項目の数値といったものでもよく、この取得データにメタデータが関連付けられている。このメタデータを含めて判定しても良い。このメタデータと取得データを併せて取得データと呼んでいるが、実際にはファイルやデータの形式によってこれらのデータ群を扱ったり、フォルダによってまとめてデータ群を扱ったりしてもよい。メタデータとしては、どの個人に属しているかという情報や、取得日時情報、データを出力する機器の種類やそのデータの種別などがある。メタデータは測定環境のデータなどを含んでもよい。もちろん、システムとして、これらのメタデータが示す変化要素を限定できる場合は、省略できるデータもある。

　ところで、ユーザが使用する検査機器としては、家庭、勤務先（通学している学校等も含む）に設置されている場合がある。家庭等に設置される検査機器としては、電子血圧計、電子体温計、トイレに設置された大便・尿の検査機器等がある。また家庭等以外にも、定期健康診断や人間ドック、献血等の際の健診等においても種々の検査機器が用いられる。さらに、ユーザが医療機関を受診した際にも種々の検査機器が用いられる。このように、種々の検査機器が使用されることが多く、通常、ユーザ毎に、検査機器は決まっていることが多い。

　また、ユーザの行動範囲や行動内容等が、特定の疾病の発症や悪化のリスクを伴う場合には、ユーザの所持するモバイル端末に備えられたＧＰＳや決済機能等も検査機器となり得る。最近ではウェアラブル端末が上述した機能を有するものがある。スマートハウス等においては、洗面台に健康管理カメラが備えられていたり、室温の設定や電気ガス水道の利用、入浴の有無やタイミングなどを判定できるようにしたものもある。監視カメラや車載のカメラ等も検査機器として利用できる。このように雑多な機器が生活を見守る可能性があるが、すべての機器のデータを集めるとセンシングや記録に手間やエネルギーやメモリ容量、通信負荷の問題が生じて現実的ではない。また、どれが重要な情報かを、いちいち、ユーザが意識することはない。逆に、ユーザに意識させると、面倒な拒否反応も起こりうる。また、個人情報の問題もあり、一般には、これらの機器のデータを勝手に使用することは好ましくなく、サービスを行う事業体やシステムと対象となる特定のユーザとの契約で規定した条件で定められた情報の活用が好ましい。

　本実施形態においては、データ取集システムが、ユーザが使用する複数種類の検査機器からの情報を収集し、データベースに記録しておく。そして、前述したように、医師等の専門家が必要に応じてデータを検索し、またこれらのデータを用いて推論を行って、ユーザに種々のアドバイスを行うことができる。このアドバイスを行うための推論モデルの生成を、データ収集システムを通じて学習装置に依頼することができる。また、専門家以外の個人や団体が情報を得て、リスクの少ない行動の選択をするための推論モデルの生成を依頼することも可能である。

　次に、図１Ａおよび図１Ｂを用いて、本発明の一実施形態にかかわる教師データ収集システムの構成を説明する。この教師データ収集システムは、制御部１、第１機器２ａ、第２機器２ｂ、第３機器３、端末４、学習部５、学習依頼部６、推論エンジン７、データベース（ＤＢ）部８、診断・検査機関（医療機関等を含む）９、医師端末９ｅからなる。なお、図１Ｂに記載の制御部１は、図１Ａに記載の制御部１と同じであり、図１Ｂの制御部１では、内部の詳細な構成を省略している。

　データ収集システムの各部の内、制御部１は、サーバ内に配置されている。第１機器２ａ、第２機器２ｂ、第３機器３、端末４、学習部５、学習依頼部６、推論エンジン７、ＤＢ部８（記録部、ストレージ部とも表現できる）、診断・検査機関９は、インターネット等のネットワークを通じてサーバに接続可能としている。しかし、本実施形態は、この構成に限定されることなく、例えば、制御部１、第１機器２ａ、第２機器２ｂ、第３機器３、学習部５、学習依頼部６、推論エンジン７、ＤＢ部８の内のいずれか１つまたは複数が、サーバ内に配置され、他は別のサーバやパーソナルコンピュータ等の電子機器に、配置されていてもよい。更に、診断・検査機関９が、サーバの機能を有してもよい。

　また、第１機器２ａ、第２機器２ｂ、第３機器３、端末４、診断・検査機関９が、制御部１と同様の機能を有し、ＤＢ部８と同様の記録機能を有して、以下、制御部１が行うとして説明する制御を実行してもよい。例えば、クラウド上にある制御部１とエッジ（端末）としての第１機器２ａ、第２機器２ｂ、第３機器３、端末４、診断・検査機関９などと連携して制御部１が行うとして説明する制御を実行してもよい。これは、連携時の通信スピードや各エッジのハード構成や消費電力などに限界等のために、システムごとに最適化されることが多い。しかし、ここでは、単純化して説明できるように、制御部１が集中して以下の制御を行うとして記載している。

　制御部１は、本実施形態に係るデータ収集システムを制御するコントローラ（プロセッサ）であり、サーバ等や、ネットワークを通じて他の端末にファイルやデータなどを提供するＣＰＵ（Central Processor Unit）、メモリ、ＨＤＤ（Hard Disc Drive）等から構成されているＩＴ機器を想定している。しかし、制御部１は、この構成に限らず、小規模なシステムとして構築する場合は、パーソナルコンピュータのようなものでも構成は可能である。制御部１は、各種のインターフェース回路を有し、他の機器と連携することができ、プログラムによってさまざまな演算制御が可能である。

　制御部１は、連携する各装置から情報を受け取り、情報を整理し、必要な情報を生み出し、この情報をユーザに提供する。制御部１は、連携する各装置に依頼を出力し、また各装置を操作するような機能も有している。本実施形態においては、システムの自由度の高さや使い勝手を想定し、第１機器２ａ等の機器や、ユーザが有する端末４等と制御部１の間は、無線通信や有線通信で接続可能となっている。このための通信としては、無線ＬＡＮや携帯電話通信網を想定し、状況に応じてブルートゥース（登録商標）や赤外通信などの近距離無線などを併用してもよい。通信回路、アンテナや接続端子等からなる通信部の記載は煩雑になるので図１においては省略してあるが、図中の通信を示す矢印の部分には、通信回路等を有する通信部が設けられている。

　制御部１は、通信制御部１ａ、ＩＤ判定部１ｂ、情報提供部１ｃ、推論モデル仕様決定部１ｄ、推論依頼部１ｅ、検索部１ｆを有する。これらの各部は、制御部１内のＣＰＵ等を有するプロセッサとプログラム等による、ソフトウエアによって実現してもよく、またハードウエア回路によって実現してもよく、またソフトウエアとハードウエア回路を協働させることによって実現してもよい。また、制御部１は、前述したように、ＣＰＵ等を有するプロセッサで構成されており、通信制御部１ａ、ＩＤ判定部１ｂ、情報提供部１ｃ、推論モデル仕様決定部１ｄ、推論依頼部１ｅ、検索部１ｆが有する機能（例えば、入力部（クラウド制御時入力部））、機器特定部、学習依頼部、表示制御部等）を実現する。また、プロセッサは、１つに限らず複数に分割され、それぞれが協調して動作することによって、各部の機能を実現してもよい。

　例えば、図９Ａおよび図９Ｂは、本発明の一実施形態に係るデータ収集システムにおいて、制御部の動作の一例を示すフローチャートであるが、フローチャートとしては、一つの制御部（例えば図１の制御部１）が各ステップをすべて実行しているように、単純化した記載となっている。しかし、実際には、各ステップにおいて他のブロック（例えば、第１機器２ａ～第３機器３、診断・検査機関９、ＤＢ部８、端末４など）と連携している。また、各ブロックそのものも、制御部１と類似の機能を有していることから、フローチャートにおける各ステップを各ブロック間で分担してもよい。このことは、クラウドとエッジ（端末）において、どちらが何をやるかという議論が一般的になされるように、状況やシステムの背景環境によって、どちらが実行するのが良いかが決まる。

　なお、図１Ａにおいて、制御部１内の各部は、互いに連携してそれぞれの機能を果たすため信号の方向は省略しているが、これは、別途、フローチャートで説明する。例えば、図１０ＡのＳ３１のようなステップにおいて、ＩＤ判定部１ｂは、第１機器２ａ、第２機器２ｂ等から、同一のユーザ毎に情報を収集している。

　通信制御部１ａは、通信回路等を有し、第１機器２ａ、第２機器２ｂ、第３機器３、端末４、学習部５、学習依頼部６、推論エンジン７、データベース（ＤＢ）部８、診断・検査機関９内に設けられた通信部（通信回路）と、データ等の送受信を行う。通信制御部１ａは、装置から出力データを入力するデータ入力部（入力回路）としての機能を果たす。また、通信制御部１ａは、情報を取得する情報取得部として機能する。なお、第１、第２機器２ａ、２ｂ、第３機器３、端末４、診断・検査機関９等の各機器・各部もそれぞれ通信部を有しているが、図１においては煩雑になるため、図示を省略している。

　ＩＤ判定部１ｂは、第１機器２ａ等から、同一のユーザ毎に情報を収集する。第１機器２ａ、第２機器２ｂ、第３機器３、診断・検査機関９によって情報が取得された個人を特定するため、個人毎にＩＤが割り当てられている。本実施形態においては、ユーザ個々のデータを取り扱うので、どのユーザの情報を受け取って、どのユーザにガイドを出すかの管理は、ＩＤ判定部１ｂが行っている。この特定ユーザの判定は、第１機器２ａ、第２機器２ｂ、第３機器３が生体認証機能を有したり、ユーザが端末４によってＩＤを入力したり、ユーザが第１、第２機器２ａ、２ｂ内の通信部を通じてＩＤを送信したり、また端末４が固有のコードを読み取ったりすることによって行う。なお、個人情報を保護するために、必要な部分を暗号化することによって管理を厳しくするが、これらは汎用的な技術であることから、詳しい説明を省略する。

　各機器のＩＤとしては、後述するように、各機器は種別情報を記憶しており、種別情報によって、その機器の機種名に関する情報やどの個体であるかを示す固有の情報等を判別するようにしてもよい。機種名から搭載するセンサの機能、性能などを、また個体情報から設置場所や利用環境などを分かるようにしてもよく、またこれらの情報を、ネットワークなどを通じて検索可能にしてもよい。機種名が分かれば、類似機器の情報を判定することが可能であり、また設置場所、利用環境から、緯度経度や室内室外、季節、天候、温度特性などを判定し、この判定結果を加味して、その機器の出力情報の補正を行ってもよい。

　情報提供部１ｃは、ユーザに正しい情報を提供するために、ユーザの情報を取得（他の装置が取得してあった結果を参照してもよい）する機能を有する。また、情報提供部１ｃは、第１機器２ａ等や診断・検査機関９から取得したユーザ（ＩＤによって特定される）の検査データや、医師等による診断結果を取得する。情報提供部１ｃは、医師が特定の患者に対して診断した結果に基づいて、上記患者の病状に関する情報を入力する入力部（入力インターフェース、クラウド制御時入力部）として機能する（例えば、図９ＢのＳ３１参照）。

　また、情報提供部１ｃは、診断・検査機関９から、要求があれば、第１機器２ａ等によって取得した検査データや、ＤＢ部８に記録されているデータ等を、診断・検査機関９に提供する。また、医師端末９ｅを使用する医師等から、診断・検査機関９を通じて要求があった場合にも、同様にデータを提供する。

　さらに情報提供部１ｃは取得した検査データや、診断・検査機関９から取得した種々の情報、およびＤＢ部８に記憶された保有機器に関する情報やユーザのプロフィール情報等を用いて、ユーザの健康状態を判断する。健康状態としては、現在かかっている疾病や、将来、発症する可能性のある疾病を含み、健康状態を判断すると、ユーザに健康状態に関連する情報を提供する。また、ユーザの疾病等を判断した場合には、必要に応じて検査や治療を受けるべき施設に関する情報をユーザに提供する。

　また、特定の状況の利用者の健康状態を確認するために、制御部１が利用者のＩＤ等によって、現在の通院状況や、処方薬などの情報、過去の健康診断結果などを、診断・検査機関９に照会できるようにしておけば、機器データとの関連付けの判定が容易になる。これは、端末４を操作するユーザがその連携を許可したり、また診断・検査機関（のＩＴ機器）９を操作する医師が、連携を許諾するような操作したりする等によって、セキュリティ上の問題を対策することが出来る。

　すなわち、情報提供部１ｃは、ユーザに健康に関する情報、例えば、いつ頃、検査や治療を受けるために施設を訪問することになるという情報や、検査や治療を受けるに適した施設を推奨するための情報を提供してもよい。情報提供部１ｃは、第１機器２ａ等や診断・検査機関９から送信されてきた検査データを取得する。このデータは、後述するように、時間情報が付された検査データ（時系列情報）であり、図５に示すようなグラフにできるようなデータ構造で蓄積される。なお、本実施形態においては、第１機器２ａ等や診断・検査機関９等における機器からの情報を用いて制御部１がユーザへ情報提供を行うことを想定しているが、診断・検査機関９を有するサーバが、同様に情報を収集するような変形例であってもよい。

　また、これらの情報を提供するために、情報提供部１ｃは、第１機器２ａ、第２機器２ｂ等から検査データを収集し、ＤＢ部８に記録する。第１機器２ａや第２機器２ｂ等によって、情報取得の頻度やデータ数は異なっていてもよい。つまり様々な機器で得られた特定の健康関連数値の増減が時系列で整理されており、機器を変えて測定した数値は機器ごとに整理が可能となっている。

　ＤＢ部８にユーザの住所や勤務する場所における行動様式や食生活や就寝時間や食事のタイミングなど生活習慣等が記録されている場合には、情報提供部はこれらの情報を、ＤＢ部８からを取得してもよく、またこれらの情報をインターネット上において取得してもよい。情報提供部１ｃは、この取得した情報も加味して、ユーザに提供する施設等の情報を生成してもよい。これらの情報の取得は、汎用または広く知られた技術で補完が可能である。これらの情報を取得することによって生成した施設等の情報のカスタマイズも、また、情報提供部１ｃが行ってもよい。この施設に関するプロフィール情報は、診断・検査機関９から医療機関情報として取得する。

　情報提供部１ｃは、ユーザの特定期間の時系列パターンとなる検査データを取得する。この取得する時系列パターンは、単に１回だけの測定によって得たデータではなく、複数の異なるタイミングに測定によって取得した個々の検査データによって構成され、検査データのパターンの変化までを情報として利用する。複数の検査データからなる時系列パターンを使用することよって、測定環境や状況の変化によって生ずる誤差の影響を受け難くしている。さらに、特定期間の終了時期から将来の時期（特定期間の延長時）における健康状態を推論し、将来に対する予測を可能にしている。

　また、取得した時系列パターンに対して、ユーザの検査・医療機関への来院のタイミング情報をアノテーション情報として付与すれば教師データができる。この教師データを用いて学習することによって生成された推論モデルを有する推論部があれば、特定期間（時系列変化パターンを取得するための期間）から先のタイミング（特定期間の延長時）に何が起こるかの推論ができる。また、ユーザの病名等が分かれば、この情報をアノテーション情報として付与した教師データを生成することができる。この教師データを用いて学習することによって、病気等の健康情報を推論する推論モデルを生成することができる。なお、ここで使用される推論モデルを生成する際には、特定の入出力情報の仕様を規定し、学習を行う。

　このように、機械学習、深層学習するに際して、データにアノテーション（注釈）が付いたものを教師データとしている。時系列データ等、データ群を収集した時に、それぞれのデータがそのアノテーション結果に寄与する何らかの情報を含んでいると考えられ、この情報を含んでいるデータが、教師データとなる。ただし、何らかのトラブルで誤差やノイズがデータに重畳する場合があり、また情報検出や伝送時の不具合等によって、利用するに値しないものもあり得る。そこで、必要に応じて予め設定したデータ形式、データ仕様、データ種別、データ大きさの範囲などの条件を満たすデータの中から、教師データを選ぶようにしてもよい。

　したがって、本実施形態においては、ユーザの検査データの時系列変化パターンを、推論部に入力し、推論部が推論を行い、この推論結果に基づいて、特定期間から先のタイミングにおける伝達情報を決定する伝達情報決定部を設けている。このため、時系列パターンの検査取得時から先のタイミングにおける予測情報を伝達することができるシステム、装置、方法、プログラム等が提供できる。

　本実施形態において情報提供部１ｃは、学習部５によって生成された推論モデルが設定された推論エンジン７に、検査データの変化パターンを入力し、アドバイスに関する推論結果を得て、入力された検査データに対応するユーザに提供する。このサービスは個人情報を利用する場合があり、アドバイス等の提供を受けるために個人情報利用の契約などが必要な場合がある。その意味で、ユーザのプロフィール情報が重要な場合もある。また、ユーザが幼児や高齢の場合は、そのユーザの世話をする人、介助者などにアドバイスを届けてもよい。これもユーザのプロフィール情報で管理した情報に従ってアドバイスなどの有効情報が届く。

　推論モデル仕様決定部１ｄは、推論依頼部１ｅが学習依頼部６を通じて学習部５に推論モデルの生成を依頼する際に、生成する推論モデルの仕様を決定する。制御部１は、第１機器２ａ等からユーザの生体情報を取得し、この生体情報を蓄積している。制御部１は、蓄積した生体情報を教師データとして、学習依頼部６を通じて、学習部５に種々の推論モデルの生成を依頼する。また、後述するように、医師等が医師端末９ｅから、推論モデルの生成を依頼する場合がある（例えば、図９ＢのＳ２１、Ｓ２３参照）。この場合に、推論モデル仕様決定部１ｄが、推論モデルの仕様を決定するようにしてもよい。この推論モデルは、教師データを使って学習し、この推論モデルの想定結果は、特定の検体情報、生体情報を入力とし、出力を診断補助情報とする。

　類似の症例の患者やその予備軍に対して、有用な推論モデルがあれば、多くの人が自分の、あるいは扶養者などの健康関係情報を推論モデルに入力し、この推論結果を利用することによって、健康を増進できるという考え方がある。この考え方は、ＩＴ技術の進展によって、ＩｏＴ化の流れから、様々な機器がインターネットにつながるようになったので、世の中に様々な見守り機器（例えば、図１Ａの第１～第３機器等）から、多くの人たちの健康関連情報が取得できるようになり、また多くの人が情報端末を使って、有用な情報にアクセスしやすくなった事を背景として、生まれてきている。

　この考え方によって、個々人の健康意識を後押しし、また通院の必要性を確認するために見守り機器（例えば、図１Ａの第１～第３機器）をツールとして利用することが可能となり、いたずらにクリニック等に出かけての感染してしまうことを防止することが出来る。例えば、第１～第３機器（図１Ａ）として、例えば腕時計型の端末を想定し、睡眠と心拍数のモニタが出来るようにしておけば、近年の研究では、このモニタデータによってインフルエンザの可能性が導けるという報告もあるので、インフルエンザに対処することが可能となる。すなわち、実際に機器データに基づいて医師にインフルエンザと判定された場合と、そうでなかった場合が分かれば（このような方法を想定すると、医師はインフルエンザを疑ったがそうではなかった、といった診察結果、判定結果を入力できるようにしてもよい）、インフルエンザの可能性が低くて、医療機関で他の患者に接触するリスクや、インフルエンザの可能性があるのに、マスクも着用せず出かけて、他の患者にリスクを与えたりするケースを防ぐことができる。また、医師は、診察時に、上述の健康関係情報（日常において時系列的に得られたもの）を参照してもよい。さらに問診など（対面でもテレビ電話でも）に加え、インフルエンザ検査キット（感染症判定キット）などを使って診断を下せばよい。

　このようにして得られた、貴重な診断結果であるから、同様のプロセスを経て同様の診察が行われている、あるいは行われて来た知見を、総合的に利用しようというのが本実施形態である。つまり、様々な医療機関、医師において、様々な患者の診察、診断が行われた結果が教師データ化され、これらの教師データの集合であるビッグデータと上述のプロセスを経て作成された推論モデルを他の医師が参照すれば、昨今の医師不足の問題や、人々の健康意識向上の要求に対処することもできる。

　推論モデル仕様決定部１ｄは、推論モデルの生成に当たって、どのような仕様の推論モデルを依頼するかを決定する。例えば、時系列的な生体情報が蓄積されている場合に、推論モデル仕様決定部１ｄは、どのような検査データ（値）となると、ユーザは何日後に医療施設で治療を受けることになるかを推論するための推論モデルの仕様を決定する。また、推論モデル仕様決定部１ｄは、時系列的な生体情報に基づいて、現在、どんな疾病にかかっているか、また将来（いつ頃）どんな疾病にかかる可能性があるか、更に疾病にかかるかもしれない場合に必要な検査や治療を受けるために推奨される施設を推論する推論モデルを生成するための仕様を決定する。

　推論依頼部１ｅは、推論モデル仕様決定部１ｄによって決定された仕様の推論モデルの生成を、学習依頼部６を通じて、学習部５に依頼する。すなわち、推論依頼部１ｅは、第１機器２ａ等によって取得した生体情報が所定数蓄積している場合に、学習依頼部６を通じて、学習部５に推論モデルの生成を依頼し、生成された推論モデルを、学習依頼部６を通じて受信する。この受信した推論モデルは、推論エンジン７に送信される。なお、制御部１は、推論モデルを複数用意し、ユーザに提供すべき情報に応じて、適宜、推論モデルを選択するとよい。また、制御部１が直接学習部５と通信できれば、学習部５から推論モデルを直接受信してもよい。さらに、後述するように、医師等が医師端末９ｅから、推論モデルの生成を依頼する場合がある（例えば、図９ＢのＳ２３参照）。この場合に、推論依頼部１ｅが、推論モデルの生成を、学習依頼部６を通じて、学習部５に依頼するようにしてもよい。

　推論依頼部１ｅは、収集された想定外のデータを教師データ化して、教師データ収集システムに対応する推論モデルの学習要求を行う推論依頼部として機能する。推論依頼部１ｅは、収集された教師データを用いて学習することによって生成される推論モデルを取得する推論モデル取得部として機能する。推論モデル取得部は、収集された教師データの値の時系列的な推移のパターンを学習し、推論モデルを取得する。推論依頼部１ｅは、定された機器と同様の機器を有する別の人の時系列データと、診察情報を教師データ化して学習を依頼する学習依頼部として機能する（例えば、図１０ＢのＳ６１参照）。

　検索部１ｆは、第１機器２ａ、第２機器２ｂ、第３機器によって取得されたユーザの生体情報に基づいて、現在かかっている疾病、また将来（いつ頃）どんな疾病にかかる可能性があるか、さらに検査や治療が必要であることが判明した際に、検査や治療に必要な設備を有する検査機関や医療機関を、ＤＢ部８に蓄積されているデータベースの中で、検索を行う。これらの情報は、推論エンジン７を用いて、推論によって取得してもよいが、蓄積されているデータと一致する場合もある。このようなケースもあることから、本実施形態では、検索部１ｆによる検索を可能としている。

　また、後述するように、医師等が医師端末９ｅにおいて、患者が使用している検査機器を用いて取得した検査データを検索する場合がある（例えば、図９ＡのＳ１７参照）。この場合に、診断・検査機関９を通じて、検索の依頼があれば、検索部１ｆが依頼に応じた検索を行う。検索部１ｆは、患者の過去の時系列データを取得可能な機器を特定する機器特定部として機能する例えば、図１０ＢのＳ５１、Ｓ５３、Ｓ５５参照）。機器特定部は、機器の一覧からデータ収集用の機器を表示部に表示させ、この表示された機器の中から特定機器を特定する（例えば、図１０ＢのＳ５５参照）。

　機器特定部が、患者の過去の時系列データを取得可能な機器を特定しているのは、共用の機器を多くの人が使う場合、「同じ機器」を用いて検査した別の人のデータを検索したり、「同じ型番の機器」あるいは「同様の仕様の機器」を用いて検査した別の人のデータを検索することによって、データをビッグデータ化し、ノイズデータを薄める効果や、教師データの量を増やす等の効果が有るからである。また、特定の状況が疾病や健康状態に影響することが分かっている場合は、その状況に揃えるために、データを適宜、取捨選択を行ってもよい。例えば、特定の性別、特定の年齢、特定の地域などの検索条件によって、データを選別する方が、効果がある場合は、検索時にその条件を付与する。

　第１機器２ａおよび第２機器２ｂは、ユーザの健康関連情報、例えば、バイタル情報、検体情報等の検査データを取得するための機器である。第１機器２ａと第２機器２ｂは、特定仕様の検査機器であり、同種（同様）の健康関連情報の検査が可能な機器である。第１機器２ａは種別２ａ１を記憶しており、また第２機器２ｂは種別２ｂ１を記憶している。種別２ａ１、種別２ｂ１は、機器の種類、型番、検査項目等に関する情報であり、各機器によってユーザの検査データを制御部１に送信する際に、併せて送信される。

　第１機器２ａと第２機器２ｂによって取得された検査データ群が、互いの検査タイミングが異なっている場合に、両データを補間できるような検査ができればよい。また、第１機器２ａと第２機器２ｂは全く同一の検査項目を検査しなくてもよく、例えば血圧を測定しながら、心拍数を測定した場合であっても、両データは互いに補間することができる。なお、図１には、ユーザの検査データを取得するための機器として、第１機器２ａおよび第２機器２ｂの２つのみを記載しているが、２つに限らず、３以上であってもよい。また、後述するように、ユーザ以外の者の検査データを取得するための機器として、本実施形態においては、第３機器３を想定している。

　なお、同じようなデータを継続して取得することによって、健康状態の確認がより精密にできる場合がある。例えば、一年の春夏秋冬、一日の朝昼晩、就寝直後、食前食後、あるいは勤務中とそれ以外、出勤日とテレワーク時、休日など、様々な要因によって、健康状態を示す数値が変化するので、データを継続して取得することによって、通常の検査では気づかないような異常が発見される場合もあり得る。このような状況に鑑みると、様々な状況で同様のデータを取り続けることが望ましい。しかし、データを取得する機器や装置が、状況ごとに異なっている場合があり、また状況ごとの環境変化や様々な制約によって差異や誤差が生じる場合があることから、同じ基準で比較できないことがあり得る。

　そこで、第１の機器によって対象者の時系列的な第１の検査データ群を取得できると共に、上記第１の検査データ群を補間できるような検査が可能な第２の機器によって上記対象者の時系列的な第２の検査データ群を取得可能とし、これらデータ群を用いることによって、上記第１の検査データ群と、上記第２の検査データ群が、互いに検査タイミングまたは検査項目を補っている関係とすることができる。状況によっては、異なる第１の機器と第２の機器の同様の数値の変化を判定する工夫が必要になるが、上記第１、第２のそれぞれの検査データ群ごとに補正することによって、誤差を解消し、情報を拡充、補充することが可能となる。また、補正した検査データ群を入力として推論した時の信頼性を算出し、この信頼性に従って、伝達情報を決定してもよい。信頼性が低い場合は補正が適切に行われおらず、推論結果を提供するに値しないと考えることが出来るからである。検査データを補正する際に、当該検査データ群に含まれるデータのそれぞれに共通する数値に対して四則演算を行うことで、単に誤差が乗った場合や、センサのゲインが異なる場合などに対応が可能となる。

　第１機器２ａ等が取得する健康関連情報としては、種々の情報があり、例えば、ユーザの体温、血圧、心拍等のバイタル情報がある。また健康関連情報としては、ユーザの尿、大便等の排泄物や、痰や、血液等、種々の検体情報がある。大便の場合には、第１機器２ａ、第２機器２ｂは、その色、形状、量、日時情報を取得する。第１機器２ａ、第２機器２ｂは、制御部１からの指示に従って情報を取得してもよく、またユーザの操作に応じて情報を取得してもよく、また自動的に情報を取得してもよい。さらに、第１機器２ａ等は、医療・健康情報である情報「パーソナル・ヘルス・レコード（(Personal Health Records : PHR) 」に、日常生活、職場／学校での活動、食事、スポーツ活動など、日常生活の様々な活動データを加えたパーソナル・ライフ・レコード（Personal Life Records : PLR）を収集・活用してもよい。取得した情報は、第１機器２ａ等内の通信部（図示を省略）を通じて、制御部１に送信される。

　第１機器２ａ、第２機器２ｂが、ユーザに関する情報を得た場合、制御部１の情報提供部１ｃが健康に関する情報を、ユーザの情報端末４に提示する。この提示が、ユーザの行動を補助することを想定して、説明を行うが、様々な変形が考えられる。健康に関する情報としては、推奨する医療施設に関する情報や、日常の生活習慣に関する情報等がある。

　第３機器３は、第１機器２ａ、第２機器２ｂを利用するユーザとは異なる人のデータを取得する機器であってもよい。第３機器３は、第１機器２ａ、第２機器２ｂを利用するユーザが、新規に使用を開始する場合、または一時的に使用する場合がある。図１Ａには、第３機器３は１個しか記載していないが、複数あってもよく、図１Ａには不特定多数の機器を一括して表現している。

　なお、第３機器３も種別３ａ１を記憶している。種別３ａ１は、第３機器３の種類、型番、検査項目等に関する情報であり、第３機器３がユーザの検査データを制御部１に送信する際に、種別情報が併せて送信される。

　第１機器２ａ、第２機器２ｂ、第３機器３としてウェアラブル端末を利用する場合には、ウェアラブル端末の装着部位によって、皮膚やあるいは身体近傍に密着し、体温、心拍、血圧、脳波、視線、呼吸、呼気などのバイタル情報を得ることが可能となる。また、体重計、血圧計、動脈壁の硬さを意味する動脈スティフネスを測定する測定器として、専用の精密な機器が、健康施設、公衆浴場、薬局、ショッピングモール等に配置され、さらに専門の計測者も一緒に配置されている場合がある。このような施設において、ユーザは空き時間などに測定機器を気楽に利用し、この時の測定結果に基づいて体調管理する場合も多い。これらの測定機器を第１機器２ａ、第２機器２ｂ、第３機器３としてもよい。

　また、第１機器２ａ、第２機器２ｂ、第３機器３は、ユーザが専用の端末等を使用した前後に、アンケートに記入を依頼する場合がある。このような場合には、このアンケートの記載に基づいて、ユーザのプロフィール情報やその他の情報を特定できる。このような情報収集は、第１機器２ａ等に限らず、制御部１が行ってもよい。何時、医療機関、検査機関等を受診したかの情報なども聞き取りできれば、これらも情報として使用することができる。

　第１機器２ａ、第２機器２ｂ、第３機器３は、すでに特定の疾患にかかっていて、医師の指導のもとで使用している体温計や血圧計などでもよい。また、スマートフォンの有するカメラで撮影した顔や爪などの色や顔の表情、患部の画像、喉がおかしくなった時の声をマイクで収音する場合等では、携帯端末（スマートフォン）がそのまま第１機器２ａ、第２機器２ｂ、第３機器３となりうる。

　最近では、簡易の健康管理機器や健康情報取得機器が開発されており、これらの機器がウェアラブル機器に搭載される場合がある、このような装置もスタンドアローンではなく、スマートフォンの周辺機器として扱われる場合が多いので、これも携帯端末として想定してもよい。また、ウェアラブルな機器でなくとも、簡易な測定機器を、人が集まる場所に設置し、健康情報サービスを提供している場合がある。このような機器を第１機器２ａ、第２機器２ｂ、第３機器３として利用してもよい。

　第１機器２ａ、第２機器２ｂ、および第３機器３からは、利用者ＩＤ、機器ＩＤ、出力データ等の情報が、制御部１の通信制御部１ａに送信される。この送信時は、データファイルＤＦ１のファイル形式によって送信される。データファイルＤＦ１は、取得データＲＤ１とメタデータＭＤ１から構成される。取得データＲＤ１は各機器が取得したデータであり、メタデータＭＤ１は、取得データを取得した時の日時情報、検査を受けた人を特定するＩＤ、取得データを取得した機器情報等が含まれる。データファイルＤＦの他の形式については、図２を用いて後述する。

　診断・検査機関９は、ＤＢ部９ａ、制御部９ｂ、表示制御部９ｃを有し、ユーザが健診・診察・検査を受ける施設であり、例えば、検査施設や医療施設があり、また薬局も含まれる。診断・検査機関９において診療等に従事する医師等は、後述する医師端末９ｅによって、診断・検査機関９と情報のやり取りを行うことができる。

　診断・検査機関９は、移動型、例えば、自動車、列車、船、ヘリコプター、ドローン等に一般医療機器や検査機器を搭載し、患者のもとに出向くタイプであっても勿論構わない。制御部１は、どの医療機関に行ったか、またどのような検査結果が出たかなどを診断・検査機関９のシステムを運営するサーバなどから取得可能である。逆に、制御部９ｂが、診断・検査機関９に属する医師等からの依頼に応じて、制御部１から種々のデータ等を取得することも可能である。もちろん、診断・検査機関９のサーバが制御部１と同じであってもよく、また一部の機能を分担してもよい。

　診断・検査機関９において、健診等を受けたユーザの情報は、データフィルＤＦ２のファイル形式によって、制御部１の通信制御部１ａに送信される。データファイルＤＦ２は、取得データＲＤ２とメタデータＭＤ２から構成される。取得データＲＤ２は各機器が取得したデータと日時の組み合わせであり、メタデータＭＤ２は、取得データを取得した機器情報、診察結果情報等が含まれる。データファイルＤＦの他の形式については、図２を用いて後述する。

　診断・検査機関９のＤＢ部９ａは電気的に書き換え可能な不揮発性メモリである。ＤＢ部９ａは、診断・検査機関９における診断結果や検査結果を個人ＩＤ毎に記録する。またＤＢ部９ａは、ユーザの生活習慣に関連する情報や、生活習慣に対する生活指導（生活習慣対応）等も記録することができる。さらに、ユーザが服用している薬剤等についても記録することができる。

　また、ＤＢ部９ａは、必要に応じて患者ごとの遺伝子情報や、マイクロバーム（常在菌の一種）情報を記録しておき、診察・診断時や、推論時にＤＢ部９ａに記録されている情報を用いて精度を上げてもよい。例えば、これらの情報を、いくつかのタイプごとや、特定の遺伝子や常在菌の有無情報にして単純化して記録してもよい。遺伝子情報が癌などに影響する事が知られており、また、ヒトの常在菌は、口腔内や腸内など生息部位ごとに異なった細菌種や組成比からなる独特の細菌集団（細菌叢，マイクロバイオーム）を形成しており、常在菌叢は外からの菌を寄せつけないので、これらのタイプの差異がヒトの健康において重要な役割を果たしていることも知られている。

　また、ＤＢ部９ａに、各医療機関が保有する機器の利用状況を管理するための管理データベースを設けてもよい。近年、医療機関の専門化が進み、あるいは掛かりつけ医制度が推進されており、特定の病状の患者は同じクリニックに通うことが多い。このクリニックには、その他の疾病用の検査機器や検査キットなどがない場合がある。そこで、医療機関が保有する機器に関する情報も管理できるようにしておけば、余計な診察の手間や感染リスクの問題に対処が可能となる。この情報をＤＢ部８と共用できるようにしておけば、各クリニックも、どのクリニックや病院が、補完機能を持っているかを知ることができ、適切なアドバイスを来院者にすることが出来る。

　診断・検査機関９の制御部９ｂは、コントローラ（プロセッサ）であり、診断・検査機関９に設けられたサーバ等や、ネットワークを通じて他の端末にファイルやデータなどを提供するＣＰＵ（Central Processor Unit）、メモリ、ＨＤＤ（Hard Disc Drive）等から構成されているＩＴ機器を想定している。しかし、制御部９ｂは、この構成に限らず、小規模なシステムとして構築する場合は、パーソナルコンピュータのようなものでも構成は可能である。制御部９ｂは、各種のインターフェース回路を有し、他の機器と連携することができ、プログラムによってさまざまな演算制御が可能である。

　診断・検査機関９の表示制御部９ｃは、表示制御回路および通信回路を有し、医師端末９ｅの表示部９ｆにおける表示の制御を行う。医師端末９ｅは、診断・検査機関９における医師等が使用する端末であり、制御部９ｃとは、院内のイントラネット等の有線通信で接続されていてもよく、ＷｉＦｉ等の無線通信によって接続されていてもよい。

　表示制御部９ｃは、複数の対象物（対象者を含む）と、複数の時点における特定情報の経時変化とを取得可能な機器を表示部に一覧表示させる表示制御部として機能する（例えば、図４、図９ＡのＳ１３参照）。表示制御部９ｃは、複数の時点における特定情報の経時変化を表示部に一覧表示させる表示制御部として機能する（例えば、図５、図９ＡのＳ１７参照）。表示部９ｃは、学習依頼部に依頼して生成した推論モデルに、患者の過去の時系列データを入力し、取得した診断補助情報を表示部に表示させる表示制御部（例えば、図７（ｂ）、図９ＢのＳ２７参照）として機能する。なお、表示制御部の機能は、医師端末９ｅが有していてもよく、また制御部１が有していてもよい。

　医師端末９ｅは、スマートフォンやタブレット等の携帯情報端末であってもよく、またデスクトップタイプやノートパソコン等のパーソナルコンピュータであってもよい。医師端末９ｅの表示部９ｆは、ディスプレイを有し、図４ないし図８に示すように、診断・検査機関９を訪れた人に関する健康に関する情報を表示する。表示部９ｆは、推論モデルの入出力の関係が想定結果となるように教師データを収集するために、機器の一覧からデータ収集用の機器選択の表示を行う表示部（ディスプレイ）として機能する（例えば、図４（ａ）（ｂ）参照）。

　また、医師端末９ｅには、操作部９ｇが設けられている。操作部９ｇは、ユーザの操作情報を入力するための入力インターフェースである。操作部９ｇは、操作用のスイッチや釦等を有し、また表示部９ｆの前面はタッチスクリーンとなっている。操作部９ｇは、医師が特定の患者の病状に入力する入力部（入力インターフェース、端末入力部）として機能する（例えば、図９ＡのＳ５参照）。

　制御部９ｈは、コントローラ（プロセッサ）であり、ＣＰＵ（Central Processor Unit）、メモリ等から構成されている。制御部９ｈは、各種のインターフェース回路を有し、他の機器と連携することができ、プログラムによってさまざまな演算制御が可能である。制御部９ｈは、診断・検査機関９内の制御部９ｂと協働し、操作部９ｇによる操作に応じて、各種表示を行い、また推論モデル依頼や推論動作等、各種動作を実行する。また、制御部９ｈは、前述したように、ＣＰＵ等を有するプロセッサで構成されており、機器特定部、学習依頼部等の機能を実現する。また、制御部９ｈは、機器特定部９ｈａと学習依頼部９ｈｂを有する。医師端末９ｅにおける表示の詳細については、図４ないし図８を用いて後述する。

　制御部９ｈ内の機器特定部９ｈａは、例えば、図４（ａ）（ｂ）および図５に示すように、患者のＩＤを特定すると、その患者が所有（使用可能も含む）する機器と、その機器で取得した時系列データを特定する。すなわち、機器特定部９ｈａは、患者の過去の時系列データを取得可能な機器を特定する機器特定部として機能する（例えば、図９ＡのＳ１３、Ｓ１７参照）。機器特定部は、表示部に表示された機器の中から特定する（例えば、図４、図９ＡのＳ１３参照）。

　また、制御部９ｈ内の学習依頼部９ｈｂは、例えば、図５、図６に示すように、患者が所有（使用可能も含む）する機器と同様の機器を有する人の別の時系列データと、診察情報を用いて、教師データを作成し、この教師データに基づく学習によって推論モデルの作成を依頼する。すなわち、学習依頼部９ｈｂは、特定された機器と同様の機器を有する別の人の時系列データと、診察情報を教師データ化して学習を依頼する学習依頼部として機能する（例えば、図９ＢのＳ２３参照）。学習依頼部は、学習を依頼して作成する推論モデルの入出力の関係が、同様の機器によって収集した収集データが入力となり、医師によって入力された患者の病状に対応する情報が出力となるように、教師データを収集する。推論モデルは、教師データを使って学習することによって得る。この推論モデルの想定結果は、特定の検体情報、生体情報を入力とし、出力を診断補助情報である。

　端末４は、ユーザが使用する携帯情報端末であり、ユーザやその関係者が確認可能な情報を受け取るための装置である。情報としては、健康情報や、健康状態に応じて推奨される施設がある。端末４は、例えばスマートフォンやタブレットＰＣであってもよく、この場合には、内蔵カメラやマイクを情報取得部として利用することができる。また、連携可能なウェアラブル端末その他の家電を端末４として使用してもよく、ウェアラブル端末等によって情報を取得してもよい。したがって、第１機器２ａや第２機器２ｂと端末４は同じものであってもよく、またそれぞれ専用機器であってもよい。ウエラブル端末と連携する端末４が、情報取得や情報の管理を行うようにしてもよい。さらに、状況に応じて、制御部１が有する機能を第１機器２ａや第２機器２ｂや第３機器３や端末４が有してもよく、分担して検出や制御や情報提供を行うような構成にしてもよい。

　データベース（ＤＢ）部８は、電気的に書き換え可能な不揮発性メモリを有する。ＤＢ部８は、ＩＤ別データ履歴一覧を有し、この一覧は、個人ＩＤ毎に、医療情報、機器ＩＤ、検査データの取得日時毎の履歴データを記録する（図３参照）。前述したように、ＩＤ判定部１ｂは、第１機器２ａ等や診断・検査機関９等から、検査データを受信するので、ＤＢ部８は、個人ＩＤ別に検査データを記録する。この際、検査日、検査結果、症状、検査機器、取得データ、診断・検査機関９への来訪日等を記録する。

　また、ＤＢ部８が、各クリニック・病院など医療機関、検査機関が有する検査機器や検査キットの管理情報を収集し、一元管理できるようにしてもよい。どこにどのような機器があるかが分かれば、患者や医師などが、正確な情報をもとに判断し、行動することによって、余計な感染リスクや誤診の問題に対処することが出来る。このような設備管理をもとにしたアドバイスを患者や医師等に行えば、患者や医師等は検査・医療機関ごとの保有機器情報を記憶する記憶部（ＤＢ）のアクセスすることができる。情報提供部１ｃは、保有機器、設備情報を加味した有効情報を対象者に伝達することが出来る。つまり、対象者の検査データやプロフィール情報に加え、検査・医療機関ごとの保有機器情報に従った情報提供が可能となる。

　また、検査をどのように、また何のための検査か等についても記録する。ＤＢ部８は、取得したデータを、５Ｗ１Ｈ、すなわち、ＷＨＯ（誰が）、ＷＨＥＲＥ（どこで）、ＷＨＥＮ（日時）、ＷＨＡＴ（どの検査）、ＷＨＹ（何故）、ＨＯＷ（どのように）に整理し、この整理されたデータを記録してもよい。また、検査場所（医療施設、検査機関、自宅、勤務先）等を記録してもよい。ＤＢ部８におけるデータの記録例については、図３を用いて後述する。

　学習依頼部６（図１Ｂ参照）は、制御部１内の推論依頼部１ｅから推論モデルの生成の依頼を受けると、学習部５に推論モデルの仕様等を伝え、仕様に沿った推論モデルの生成を依頼する。学習依頼部６は、データ分類記録部６ａ、仕様設定部６ｄ、通信部６ｅ、制御部６ｆを有する。

　制御部６ｆは、学習依頼部６内を制御するコントローラ（プロセッサ）であり、サーバ等や、ネットワークを通じて他の端末にファイルやデータなどを提供するＣＰＵ（Central Processor Unit）、メモリ、ＨＤＤ（Hard Disc Drive）等から構成されているＩＴ機器を想定している。しかし、制御部６ｆは、この構成に限らず、小規模なシステムとして構築する場合は、パーソナルコンピュータのようなものでも構成は可能である。制御部６ｆは、各種のインターフェース回路を有し、他の機器と連携することができ、プログラムによってさまざまな演算制御が可能である。

　データ分類部６ａは、対象物種類Ａ画像群６ｂを有し、この中に教師データ６ｃを記録している。対象物種類Ａ画像群６ｂは、学習部５において推論モデルを生成する際に使用する画像群であり、種類Ａ、種類Ｂ・・・と多数の画像群を有する。この画像群に基づいて教師データ６ｃを生成する。すなわち、図５に示すように、検査データを検査日毎にプロットするとグラフを描くことができ、このグラフを画像として扱うことができる。なお、ここでは画像として直感的にわかりやすく説明しているが、必ずしも画像として扱う必要はなく、時系列的な検査データの変化、すなわち検査日時と検査データを集めた複数の検査データ群を教師データとして生成するようにしてもよい。データ記録分類部６ａには、ＤＢ部８に記録されたデータ履歴一覧に基づく、教師データ６ｃが記録される。

　仕様設定部６ｄは、推論モデル仕様決定部１ｄによって決定された推論モデルの仕様に基づいて、どのような推論モデルを生成するかを設定する。また、この仕様を満足するように、ＤＢ部８の履歴一覧に記録されているデータから教師データを生成する。

　通信部６ｅは、制御部１および学習部５と通信するための通信回路を有する。この通信部６ｅを通じて、制御部１から推論モデルの生成の依頼を受け、また学習部５に推論モデルの生成を依頼する。

　学習部５は、入出力モデル化部５ａを有し、学習依頼部６からの仕様に従って、機械学習等によって推論モデルを生成する。入出力モデル化部５ａは、仕様照合部５ｂを有する。この仕様照合部５ｂは、学習依頼部６から受信した仕様と、入出力モデル化部５ａによって生成された推論モデルが合っているか否かを判断する。すなわち、仕様照合部５ｂは、入出力関係のみならず、この推論モデルの推論にかかる時間やエネルギーや回路構成など、「要求仕様」に沿った学習を行うよう、学習の仕方などを規定するものである。

　推論モデルは、取得した生体情報、生検情報など取得情報と疾患の関係を学習し、具体的には、取得情報と診療科・部門の関係を学習することによって生成する。入出力モデル化部５ａは、推論エンジン７と同様に、入力層、複数の中間層、出力層を有し、中間層のニューロンの結合の強さを学習によって求め、推論モデルを生成する。

　このような推論モデルの生成にあたっては、学習依頼部６が検査機器を用いて被検者から取得した検査データの変化パターンを特定の時間幅で抽出し、この抽出した変化パターンを推論エンジン７に入力し、被検者が検査したタイミングから、後のタイミングにおいて出力されるべき健康アドバイスをアノテーション情報とした、教師データを生成する。そして、学習部５は、この教師データを用いて学習を行うことによって、推論モデルを生成する。

　また、学習部５は、検査、通院、服薬の後の検査データ列を用いて学習すれば、生活習慣改善や治療や服薬の効果の将来予想アドバイスを行うことが可能な推論モデルを生成することも出来る。この場合には、検査、通院、服薬の時点を起点として、その後の時系列データを利用する。検査、通院、服薬などをアドバイスする場合は、この前の時系列データを利用する。

　ここで、学習部５が行う学習の一例として、深層学習について、説明する。「深層学習（ディープ・ラーニング）」は、ニューラル・ネットワークを用いた「機械学習」の過程を多層構造化したものである。情報を前から後ろに送って判定を行う「順伝搬型ニューラル・ネットワーク」が代表的なものである。順伝搬型ニューラル・ネットワークは、最も単純なものでは、Ｎ１個のニューロンで構成される入力層、パラメータで与えられるＮ２個のニューロンで構成される中間層、判別するクラスの数に対応するＮ３個のニューロンで構成される出力層の３層があればよい。入力層と中間層、中間層と出力層の各ニューロンはそれぞれが結合加重で結ばれ、中間層と出力層はバイアス値が加えられることによって、論理ゲートを容易に形成できる。

　ニューラル・ネットワークは、簡単な判別を行うのであれば３層でもよいが、中間層を多数にすることによって、機械学習の過程において複数の特徴量の組み合わせ方を学習することも可能となる。近年では、９層～１５２層のものが、学習にかかる時間や判定精度、消費エネルギーの観点から実用的になっている。また、画像の特徴量を圧縮する、「畳み込み」と呼ばれる処理を行い、最小限の処理で動作し、パターン認識に強い「畳み込み型ニューラル・ネットワーク」を利用してもよい。また、より複雑な情報を扱え、順番や順序によって意味合いが変わる情報分析に対応して、情報を双方向に流れる「再帰型ニューラル・ネットワーク」（全結合リカレントニューラルネット）を利用してもよい。

　これらの技術を実現するために、ＣＰＵやＦＰＧＡ（Field Programmable Gate Array）等の従来からある汎用的な演算処理回路を使用してもよい。しかし、これに限らず、ニューラル・ネットワークの処理の多くが行列の掛け算であることから、行列計算に特化したＧＰＵ（Graphic Processing Unit）やTensor Processing Unit（TPU）と呼ばれるプロセッサを利用してもよい。近年ではこのような人工知能（ＡＩ）専用ハードの「ニューラル・ネットワーク・プロセッシング・ユニット（ＮＰＵ）」がＣＰＵ等その他の回路とともに集積して組み込み可能に設計され、処理回路の一部になっている場合もある。

　その他、機械学習の方法としては、例えば、サポートベクトルマシン、サポートベクトル回帰という手法もある。ここでの学習は、識別器の重み、フィルター係数、オフセットを算出するものあり、これ以外にも、ロジスティック回帰処理を利用する手法もある。機械に何かを判定させる場合、人間が機械に判定の仕方を教える必要がある。本実施形態においては、画像の判定を、機械学習によって導出する手法を採用したが、そのほか、人間が経験則・ヒューリスティクスによって獲得したルールを適応するルールベースの手法を用いてもよい。

　推論エンジン７は、学習部５の入出力モデル化部５ａと同様の入出力層、ニューラル・ネットワークを有している。推論エンジン７は、学習部５によって生成された推論モデルを用いて、推論を行う。例えば、推論エンジン７は、第１機器２ａ等によって測定され、時系列的な生体情報を入力し、例えば、ユーザの健康状態を検査、治療等を行うに適切な検査機関・医療機関を推論によって求める。また、時系列的な生体情報に基づいて、いつ頃、医療機関で受診を受けることになるかの推論等を行ってもよい。

　このように、制御部１は、検索部１ｆがＤＢ部８を検索する以外にも、推論エンジン７を利用して、ユーザの疾病に関する情報を提供しても良い。推論エンジン７は、学習部５が生成した推論モデルを用いて、疾病に関する推論を行う。この推論モデルは、取得した生体情報、生検情報など取得情報と疾患の関係を学習することによって生成する。このように、制御部１は、推論エンジン７による推論によっても、提示すべきガイド情報を出力してもよい。

　制御部１が検索によって、または推論によって、一度に得られた取得情報に基づいて、一回の判定で疾病などをガイドすると、いたずらに生活に医療情報を持ち込んで、健全に安心して生活するのを妨げる可能性がある。そこで、複数回の取得情報の履歴（時系列的情報）を用いて、精度アップしてもよい。

　次に、図２を用いて、学習用教師データとして使用可能なデータファイルＤＦのファイル構造について説明する。図２（ａ）は、第１の学習用教師データとして使用可能なデータファイルＤＦ３のファイル構造を示す。このデータファイルＤＦ３は、異なる日時に検査機器によって取得された取得データＲＤ３ａ、ＲＤ３ｂ、ＲＤ３ｃと、これらのデータのメタデータＭＤ３を有する。取得データとしては、図２（ａ）には３つしか記載されていないが、この数は検査の回数が増えれば、それに応じて増加する。また、メタデータＭＤ３としては、検査に使用された機器の情報、診察結果、検査を受けたユーザを識別するＩＤ等が記録される。このメタデータにアノテーションを付与した人の分類や専門家の関与の仕方、アノテーションした個人や組織を特定するＩＤなどを記載できるようにしてもよい。

　図２（ｂ）は、データファイルをフォルダ形式によってまとめている場合を示す。図２（ｂ）に示す例では、患者Ａの診察結果をフォルダにまとめている。このフォルダには、患者Ａを特定するための識別用データＩＤａ４、診察結果を記録するためのデータＭＤＲｅ４が記録されている。また、個々の取得データについては、データファイルＤＦ４ａ、ＤＦ４ｂ、ＤＦ４ｃに記録されている。ここのデータファイルの形式は、図１Ａに示したデータファイルＤＦ１と略同じであるので、詳しい説明は省略する。なお、このデータファイルＤＦ４ａ等は、図２（ｂ）には３つしか記載されていないが、この数は検査の回数が増えれば、それに応じて増加する。

　次に、図３を用いて、ＤＢ部８に記録される履歴データ等について説明する。この履歴データは、ユーザの一人一人を識別するための個人ＩＤ毎に作成される。履歴データは、ＩＤ毎に、検査結果、症状、機器ＩＤ、取得データを記録する。検査結果としては、検査日付けと診察結果に基づいて疾病に関する情報が記録される。症状としては、症状名が記載され、症状毎に検査機器ＩＤと、その検査機器を用いて取得された取得データが日付け毎に記録される。さらに、医院等の診断・検査機関９で受診した日が記録される。

　図３に示す履歴データの例では、ＩＤ１のユーザは、症状Ｘについて検査可能な機器ａを用いて日時ｔ１、ｔ３、ｔ５、ｔ７において検査データＤａ（ｔ１）、Ｄａ（ｔ３）、Ｄａ（ｔ５）、Ｄａ（ｔ７）を取得している。またＩＤ１のユーザは、症状Ｙについて検査可能な機器ｂを用いて日時ｔ２、ｔ４において検査データＤｂ１（ｔ２）、Ｄｂ１（ｔ４）を取得している。ＩＤ１は、日時ｔ５において、来院し受診したところ、医師は疾病Ａ１に罹患していると判断している。

　また、ＩＤ２のユーザは、症状Ｙについて検査可能な機器ａを用いて日時ｔ２、ｔ４において検査データＤａ２（ｔ２）、Ｄａ２（ｔ４）を取得している。そして、ＩＤ２は日時ｔ５において、来院し受診したところ、医師は疾病Ｂ２に罹患していると判断している。

　また、日時ｔ５において、ＩＤ１、ＩＤ２が来院した際に、医師が両者の履歴データを用いて、学習を依頼している。すなわち、ＩＤ１は疾病Ａ１を罹患している例として、またＩＤ２は疾病Ａ１を罹患していない例として、時系列的な検査データがあり、更に、同様の機器で検査した時系列データを学習用の教師データとして、学習部５に推論モデルの生成を依頼している。

　また、ＩＤ３やＩＤ４についても、同様に、機器ａ、機器ｃによってデータが取得され、ＤＢ部８に記録される。両者は、日時ｔ８に来院し、受診している。ＩＤ３については機器ａによるデータがあり、症状Ｘがある。一方ＩＤ４については、機器ｃについてしかデータがないが、症状Ｘがある。前述したように、日時ｔ５において医師は学習を依頼し、推論モデルを取得している。この推論モデルに、ＩＤ３の時系列的な検査データと、ＩＤ４の時系列的な検査データを入力することによって、疾病Ａ１であるか否かを推論することができる。医師はこの推論結果を参考にして、疾病Ａ１であるか否かの診断を行うことができる。

　次に、図４を用いて、医師端末９ｅの表示部９ｆにおける表示について説明する。なお、図４に示す例は、図３に示した履歴データを有するＩＤ１、ＩＤ２等が受診した場合である。

　図４（ａ）は、Ａ１病で来院した患者の一覧表を示す。医師は、疾病の判断をする際に、疑われる疾病を罹患している患者が使用している検査機器や履歴データを確認したいと思う場合がある（例えば、図９ＡのＳ１１、Ｓ１５参照）。図４（ａ）は、同一の疾病で来院した患者毎に、来院日時と、その患者が使用している機器の一覧表を示す。図４（ａ）の例では、患者ＩＤ１、ＩＤ３、ＩＤ５は機器ａによって検査した履歴データがあり、患者ＩＤ４は機器ｃによって検査した履歴データが有ることを示している。

　図４（ａ）における表示は、診断・検査機関９の制御部９ｂが、ＤＢ部９ａに記録されているデータの中から該当のデータを検索し、表示制御部９ｃが検索結果を医師端末９ｅに表示できるように、データを送信する。すなわち、表示制御部９ｃは、特定の疾病（Ａ１病）と判定された複数の対象物（対象者）と、複数の時点における特定情報の経時変化とを取得可能な機器を一覧表示可能な表示制御部として機能する。なお、制御部９ｂがデータの検索を行う以外にも、制御部１がＤＢ部８に記録されているデータを検索してもよい。後述する図４（ｂ）の場合も同様である。

　図４（ｂ）は、Ａ１病で来院した患者の時系列情報を示す。医師は、図４（ａ）に示すように、Ａ１病で来院した患者の一覧表に続いて、彼らの検査および来院した日時情報を確認したいと思う場合がある。図４（ｂ）は、同一の疾病で来院した患者の検査日時および来院日時を示す一覧表である。

　図４（ｂ）に示す表示は、診断・検査機関９の制御部９ｂが、ＤＢ部９ａに記録されているデータの中から該当のデータを検索し、表示制御部９ｃが検索結果を医師端末９ｅに表示できるように、データを送信する。すなわち、表示制御部９ｃは、特定の疾病（Ａ１病）と判定された複数の時点における特定情報の経時変化を一覧表示可能な表示制御として機能する。

　次に、図５を用いて、来院した患者のデータ表示について説明する（例えば、図９ＡのＳ１５、Ｓ１７参照）。図４に示したように、医師端末９ｅの表示部９ｆには、Ａ１病で来院した患者のリスト（所有機器、来院日時情報付き）が表示される。医院に来院した患者がいる場合に、これらの患者の検査データについて、医師が端末で時系列的変化を見ることができれば便利である。そこで、本実施形態においては、医師端末９ｅのメニュー画面等（図６参照）において、グラフ表示を選択すると、図５に示すようなグラフが表示される。

　図５（ａ）は、日時ｔ９までの間に、Ａ１病と診察された患者の検査データＤを示す。図５（ａ）のグラフにおいて、横軸は来院日時を示し、縦軸は検査データＤを示す。グラフ中の丸印は患者ＩＤ１、ＩＤ３、ＩＤ５の検査データＤを示す。図５（ａ）の右側には、「診察あり」「診察なし」「両方」のアイコンが表示されている。図５（ａ）は、Ａ１病と診断された患者の履歴データを示しているので、「診察あり」のアイコンが白黒反転表示されている。

　図５（ａ）の表示状態において、「診察なし」のアイコンがタッチされると、図５（ｂ）に示すように、「診察なし」のアイコンが白黒反転し、「Ａ１病で来院していない人」のグラフが表示される。図５（ｂ）においても、横軸は来院日時を示し、縦軸は検査データＤを示す。グラフ中の丸印は患者ＩＤ２、ＩＤ４、ＩＤ６の検査データＤを示す。ＩＤ２、ＩＤ４、ＩＤ６は、来院したが、Ａ１病とは診断されていない人である。この状態で、「両方」のアイコンがタッチされると、Ａ１病と診断された者と診断されなかった者の両方の履歴データがグラフ表示される。

　図５（ａ）、（ｂ）のような表示によって、目視で、この症例の時系列変化が確認でき、また他の情報も合わせて表示することによって、医師が診断、治療を行う時の参考になる可能性も高い。この表示は、データ収集とグラフ化だけで達成でき、教師データを作成するまでもなく、あるいは推論を待つまでもなく、何らかの知見が得られる場合がある。医師が特定の患者の病状に関する情報を入力する入力部と、上記患者の過去の時系列データを取得可能な機器を特定する機器特定部と、上記特定された機器と同様の機器を有する別の人の機器による収集データを収集するデータ収集部を有するデータ収集装置は、上述したように、医師が診断、治療する際に参考になる情報を収集することができる。また、この収集結果を表示して、医師が気づきを得れば、多くの人の健康維持情報に役立つ。

さらに、診察情報を教師データ化して学習を依頼する学習依頼部を有する教師データ収集装置は、より客観的な情報を得ることが出来る。この教師データ収集装置によって収集した教師データを使用することによって、信頼性の高い推論モデルを作成すれば、医師の気づきや知見を共用することが可能となり、世界中で診療方法が共通化でき、医師の経験に依存しない高度な健康回復策、健康維持策を提示することが可能になる。ただし、全ての雑多な情報を教師データとして使用すると、信頼性の高い推論モデルを得ることは出来ないので、データの要不要を取捨選択できるようにしておいた方が良い。

　収集したデータの時間軸をみれば、例えば、感染症などの場合、どのあたりで流行が始まったかなどの判定が出来る。特定の日に発熱した人が多い場合、その日に海外などから感染症が広がった等を確認、判断する際の目安となる。また、来院時を基準にした時間軸表示で、その疾病特有の症例（病状）変化を、患者の自覚や患者を見た他の人の勧めで来院が必要と判断したタイミングをもとにして、来院に至る過程などが確認しやすくなる。

　また、特定のデータ変化の時点（例えば、熱が上がったタイミングなど）を基準にした時間軸で収集データを表示すれば、その疾病特有の病状の変化が分かり、診断に役立つ基礎データとなる。当然、機器が携帯端末であれば、その人の行動履歴やインターネットアクセスなどの履歴も情報として（クラウド上の情報も含めシステムとして）記録されているので、行動履歴をさらに解析しての病状の変化の傾向を捉えて、病気の進行を押さえたり、健康を改善するための情報にしたりすることが出来る。

　　図５における表示は、診断・検査機関９の制御部９ｂが、ＤＢ部９ａに記録されているデータの中から該当のデータを検索し、表示制御部９ｃが医師端末９ｅに検索結果を表示できるように、データを送信する。すなわち、表示制御部９ｃは、特定の疾病（Ａ１病）と判定された複数の時点における特定情報の経時変化を一覧表示可能な表示制御部として機能する。

　図５（ａ）に示す履歴データは、いずれもＡ１病と診断された者のデータであることから、これらの者のデータに対して、「Ａ１病の疾患あり」のアノテーションを付した教師データを作成することができる。また、図５（ｂ）に示す履歴データは、いずれもＡ１病と診断されなかった者のデータであることから、これらの者のデータに対して、「Ａ１病の疾患なし」のアノテーションを付した教師データを作成することができる（例えば、図９ＡのＳ１５、Ｓ１７参照）。この学習用の教師データのファイル形式は、データファイルＤＦ１、ＤＦ２、ＤＦ３、ＤＦ４等、適宜選択すればよい。

　教師データが作成できれば、医師端末９ｅは、制御部１の推論依頼部１ｅ、および学習依頼部６を通じて、学習部５にＡ１病に適した推論モデルの生成を依頼できる（例えば、図９ＡのＳ２３参照）。なお、診断・検査機関９から直接、学習依頼部６、学習部５に依頼するようにしてもよい。

　次に、図６を用いて、医師端末９ｅにおけるメニュー画面について説明する。医師端末９ｅ起動すると、端末メニューが表示される。端末メニューにおいて、分析アプリを起動すると、図６（ａ）に示される「分析アプリ」の画面が表示される（図９ＡのＳ７参照）。この分析アプリの画面には、「診断結果選択」「テーブル表示」「グラフ表示」教師データ表示」「学習依頼」「学習結果性能確認」推論データ取得」「推論依頼」「推論結果表示」「戻る」「ＭＥＮＵ」のアイコンが表示される。

　分析アプリの画面において、「診断結果選択」が選択されると（例えば、図９ＡのＳ１１参照）、疾病のリストが表示され、その中から、疾病の名称を選択することができる。例えば、Ａ１病を選択すると、図４（ａ）に示すような来院した患者の一覧表が表示される。診断結果を選択した状態で、「テーブル表示」を選択すると（例えば、図９ＡのＳ１５参照）、図４（ｂ）に示すような時系列情報がテーブル表示される。

　また、図６（ａ）のメニュー画面において、「グラフ表示」が選択されると（例えば、図９ＡのＳ１５参照）、図５に示すような履歴データがグラフ表示される。図５のグラフ表示の際に、右上の「ＭＥＮＵ」がタッチされると、図６（ｂ）に示すようなアイコンが表示される。この表示状態で、「手動修正」がタッチされると、データの修正が可能になる。「データ選択」によって特定のデータを選択し、「データ削除」をタッチすると、そのデータが削除される。

　図５（ａ）のＡ１病で来院した患者が選択された状態で、「一括アノテーション」がタッチされると、「Ａ１病の疾患あり」のアノテーションを付した教師データが、一括で生成される。また、「追加アノテーション」がタッチされると、教師データに付するアノテーションを追加することができる。Ａ１病で来院した患者に共通してみられる症状等を一括してアノテーションとして付加することができる。図６（ｂ）に示す例では、「発熱と発疹」がアノテーションとして追加されている。このアノテーションは、医師端末９ｅの操作部９ｇを操作し、テキスト入力すればよい。

　図６（ａ）に戻り、「教師データ表示」がタッチされると（例えば、図９ＡのＳ１５参照）、医師が図５等においてデータを選択し、教師データとしたデータが表示される。「学習依頼」がタッチされると（例えば、図９ＢのＳ２１参照）、医師端末９ｅは、「教師データ表示」で表示された教師データを用いて、推論モデルの生成を学習部５に依頼する。「学習結果性能確認」がタッチされると（例えば、図９ＢのＳ２１参照）、学習を依頼した際に、学習部５が生成した推論モデルの性能、例えば、信頼性を評価する。この評価は、例えば、評価用のデータを用意しておき、この評価用データを推論モデルに入力し、その出力結果に基づいて行う。学習結果性能確認を行った結果、満足する結果が得られれば、推論モデルを取得する。

　図６（ａ）において、「推論データ取得」をタッチすると（例えば、図９ＢのＳ２５参照）、推論モデルに入力する推論データを取得する。例えば、図３の例において、日時ｔ９のタイミングで、ＩＤ３およびＩＤ４が来院した際に、医師はＩＤ３およびＩＤ４のそれまでの履歴データを、推論モデルに入力し、疾病について推論を行う場合がある。推論データは、このように、診察対象となった患者の過去の履歴データである。

　図６（ａ）において、「推論依頼」をタッチすると（例えば、図９ＢのＳ２５参照）、取得した推論データを、推論モデルに入力し、推論結果を出力するように依頼する。推論の依頼先は診断・検査機関９が推論エンジンを有していれば、診断・検査機関９とする。診断・検査機関９が推論エンジンを有していない場合には、制御部１に依頼してもよい。もちろん、医師端末９ｅが推論エンジンを有してれば、医師端末９ｅ内で推論を行ってもよい。この推論依頼の詳細画面については、図７を用いて後述する。「推論結果表示」をタッチすると、推論結果が表示される。

　次に、図７を用いて、推論依頼の画面について説明する。医師は、患者の過去の履歴データから、今後の症状の変化について推論モデルを用いて推論結果を得ることが望む場合がある（例えば、図９ＢのＳ２５参照）。この場合には、図６（ａ）の画面において、医師は「推論依頼」をタッチする。タッチすると、図７（ａ）に示すように、まず、患者データ選択の画面が表示される。図７（ａ）に示される例では、「Ｇさん」等、患者名が表示される。

　図７（ａ）において、患者名をタッチによって選択すると、図７（ｂ）に示すように、選択された患者の履歴データがグラフ表示される。このグラフ表示によって、医師は患者の過去のデータについて知ることができ、更に、将来の予測を行いたい場合には、下部の「推論」をタッチする。タッチすると、推論が行われ、推論結果が画面内に表示される。図７（ｂ）に示す例では、Ａ１病に罹患する確率が「７割」あり、注意が必要と表示される。医師は、この推論結果を参考にして、診断結果を出すことができる。

　次に、図８を用いて、診断入力を行う画面について説明する。端末メニュー画面から診断入力を行う画面を開き（例えば、図９ＡのＳ１、Ｓ３、Ｓ５参照））、患者名を選択すると、図８の診断入力用の画面が表示される。この診断入力用画面において、医師が特定の患者の病状に入力する。図８の例では、患者名として「Ｇさん」が選択されている。この画面には、既にデータ入力されていれば、Ｇさんの診察券Ｎｏ．と日時が表示される。また、初診、症状、診断結果、所有機器について、データが入力されていれば表示され、未入力であって記入できる項目については医師が医師端末９ｅにおいて入力する。また、患者の個人情報を利用することについて、患者から同意を得られる場合には、画面下部のチェック欄をチェックしてもらう。図８においては、同意が得られたので、チェックマークが付されている。

　次に、図９Ａおよび図９Ｂに示すフローチャートを用いて、医師端末９ｅにおける制御部９ｈの動作について説明する。このフローは、医師端末９ｅ内の制御部９ｈが、診断・検査機関９内の制御部９ｂと協働し、診断・検査機関９および医師端末９ｅ内の各部を制御することによって実現する。

　医師端末９ｅの電源がオンとなり、図９Ａに示すフローが開始すると、まず、端末メニューが表示される（Ｓ１）。ここでは、制御部９ｈは、表示部９ｆにメニュー画面を表示する。メニュー表示としては、「診断結果入力」「分析アプリ起動」や、その他の機能等、操作可能な項目をアイコンで表示する。

　メニュー表示を行うと、次に、判定結果を入力するか否かを判定する（Ｓ３）。ここでは、制御部９ｈが、メニュー画面における「診断結果入力」がタッチ操作されたか否かに基づいて判定する。

　ステップＳ３における判定の結果、判定結果を入力する場合には、入力を行う（Ｓ５）。ここでは、制御部９ｈは、図８に示す診断結果の入力画面を表示部９ｆに表示する。前述したように、診断結果の入力画面では、医師は患者の診断結果等を、操作部９ｇ等によって入力することができる。すなわち、このステップにおいて、医師が特定の患者の病状に入力する。その他、診察時の検査データ結果等の入力も行う。

　ステップＳ５において入力を行うと、またはステップＳ３における判定の結果、診断結果の入力でない場合には、次に、分析アプリ起動か否かを判定する（Ｓ７）。ここでは、制御部９ｈは、メニュー画面における「分析アプリ」がタッチ操作されたか否かに基づいて判定する。

　ステップＳ７における判定の結果、分析アプリの起動でない場合には、その他の機能を実行する（Ｓ９）。ここでは、制御部９ｈが、他の機能、例えば、機器の貸し出し、機器の登録、患者等の同意署名、通常のカルテ記入・確認等を行う。その他機能を実行すると、ステップＳ１に戻る。

　ステップＳ７における判定の結果、分析アプリの起動であった場合には、診断結果一覧確認か否かを判定する（Ｓ１１）。ここでは、制御部９ｈが、まず、図６（ａ）に示す分析アプリのメニュー画面を表示部９ｆに表示する。メニュー画面には、前述したように種々の項目に対応したアイコンが表示されるので、このステップでは、制御部９ｈは、「診断結果選択」のアイコンが選択されたか否かを判定する。

　ステップＳ１１における判定の結果、診断結果一覧確認が選択された場合には、診断結果に従った患者と機器を表示、機器選択を行う（Ｓ１３）。ここでは、制御部９ｈは、図４（ａ）に示したような特定疾病で来院した患者の一覧表を示す。この一覧表には、患者が所有し、または使用可能な検査機器を表示する。医師は、表示された検査機器を選択することができる。例えば、図４（ａ）において、Ａ１病のために来院した患者の多くが機器ａを所有（または使用可能）な場合には、機器ａを選択することができる。

　ステップＳ１３において機器の選択を行うと、またはステップＳ１１における判定の結果、診断結果一覧確認を選択しない場合には、次に、テーブル表示、グラフ、教師データを表示するか否かを判定する（Ｓ１５）。ここでは、制御部９ｈは、図６（ａ）に示した「テーブル表示」「グラフ表示」「教師データ表示」のいずれかが選択されたか否かを判定する。

　ステップＳ１５における判定の結果、テーブル表示等のいずれかが選択された場合には、選択機器に対応する患者別データ表示、確認、取捨選択を可能にする（Ｓ１７）。ここでは、制御部９ｈは、図４（ｂ）に示した、特定疾病で来院した人の時系列情報、図５に示した特定疾病で来院した人の履歴データ、特定疾病で来院していない人の履歴データを、表示部９ｆに表示する。例えば、図４（ａ）に示したように、特定疾病（Ａ１病）のために来院した患者が、所有また使用可能な特定機器によって検査されたデータを多数収集することができる（図５（ａ）参照）。このデータは、特定疾病の患者の判定用の教師データとして使用することができる。また、特定疾病のために来院していない患者であって、特定機器によって検査されたデータも多数収集することができる。このデータは、特定疾病の患者ではないと判定するための判定用の教師データとして使用することができる。このデータを用いて学習の結果の結果得られる推論モデルの入出力関係は、同様の機器によって収集した収集データが入力となり、医師によって入力された患者の病状に対応する情報が出力となるようにする。このような推論モデルの入出力関係が得られるように、データを収集する。

　また、ステップＳ１５においては、表示部９ｆのメニュー画面上の「教師データ」を選択することによって、学習の依頼に使用する教師データを確認することができる。また、履歴データ（教師データ）を表示した際に、ＭＥＮＵがタッチされた際には、データの選択、データ削除等の取捨選択を行うことができる（例えば、図６（ｂ）参照）。このように、これらのアイコンを利用することによって、特定疾病の判定用の推論モデルを生成するための、教師データを作成することができる。

　ステップＳ１７における処理を実行すると、またはステップＳ１５における判定の結果、テーブル表示等を行わない場合には、次に、学習依頼を行うか、または学習結果を確認するか否かを判定する（Ｓ２１）。ここでは、制御部９ｈは、図６（ａ）に示した「学習依頼」「学習結果性能確認」のいずれかが選択されたか否かを判定する。

　ステップＳ２１における判定の結果、学習依頼、または学習結果確認の場合には、選択済みの教師データで学習を依頼し、または結果を取得する（Ｓ２３）。ここでは、ステップＳ１７において、選定した教師データを用いて、推論モデルを生成するように、学習部５に依頼することができる。推論依頼は、例えば、図７（ｂ）に示すような「推論」のアイコンを選択することによって、実行される。

　また、ステップＳ２３において、学習部５に学習を依頼し、推論モデルが生成された場合には、その推論モデルの性能・信頼性等の結果を取得し、表示する。推論モデルの性能、信頼性は、例えば、ＬＯＳＳ値等を算出し、このＬＯＳＳ値に基づいて行う。ＬＯＳＳ値は、予め評価用に用意したデータを推論モデルに入力し、このときの推論結果が予め用意したデータの結果と、どの位の割合で一致するかを示す値である。この性能・信頼性の評価は、推論エンジンを有する機器において行う。評価の結果、性能・信頼性が所定のレベル以下の場合には、教師データを作り直し、また機器選択をやり直す等を行って、再度、学習部５によって推論モデルを作成し直す。

　ステップＳ２３において、信頼性の高い推論モデルが生成された確認できた場合には、特定のサーバ等において推論モデルを利用可能とし、多くの医療機関で使用可能にしたり、一般ユーザが自分の状態を確認したりするのを利用可能にする。これによって、救急車の手配を適切にすることができ、また医療機関での受診などを減らし、医療現場の多忙さを解消できるようになる。通院過程や通院先で、感染したり感染させたりすることを防止できる。また、この推論モデルにＩＤを設け、どの推論モデルで判定したかが分かるようにしても良い。無数の類似モデルが出回ると品質の悪いものが、過度な不安を蔓延させることもあれば、緊急の患者を手遅れにしてしまう可能性がある。このように、ＩＤによってＡＩを特定することが望ましく、またＡＩの立証性にも役立つ。

　また、医師の気づきと教師データ取捨選択で生成された推論モデル（ＡＩ）の場合、誰が作成したかを明確にしておくことが望ましい。作成者を明確にすることによって、ＡＩを苦労して作った時の成果が、その医師の努力によるものと広く認められ、その努力に報いる手立てなどを講じることが出来る。また、安易に悪質なＡＩが出回ることを防止することも可能となる。このようなＡＩは、どのようなデータを必要とするかが決まっているので、そのＡＩに適したデータには、その条件を明確にできる工夫を行ってもよい。つまり、そのＡＩ向けのデータを取得する際には、そのＡＩを指定してデータ取得開始といったアプリを機器が実装し、図２（ａ）のような取得データのデータファイルのメタデータとして、想定ＡＩ情報（ＩＤなど）を付記できるようにすれば良い。

　ステップＳ２３において推論モデルの結果を取得すると、またはステップＳ２１における判定の結果、学習依頼・学習結果確認でない場合には、次に、推論データを取得し、推論を依頼し、推論結果を取得したかを判定する（Ｓ２５）。前述したように、医師が患者を診察した際に、この患者の履歴データを推論モデルに入力し、疾病に関する推論結果を得たい場合がある。このステップでは、推論モデルを用いた推論を行う。このステップでは、制御部９ｈは、図６（ａ）に示した「推論データ取得」「推論依頼」「推論結果表示」のいずれかが選択されたか否かを判定する。

　ステップＳ２５における判定の結果、推論データ取得等であった場合には、次に、推論モデルのダウンロードと依頼、結果取得を行う（Ｓ２７）。ここでは、制御部９ｈは、学習部５に対して、ステップＳ２３において所定の性能・信頼性を満たした推論モデルのダウンロードを依頼する。また、推論したい患者の履歴データを取得し、この履歴データをダウンロードした推論モデルに入力し、推論結果を取得する。取得した推論結果は、表示部９ｆに表示する（例えば、図７（ｂ）参照）。

　ステップＳ２７において、推論結果を取得すると、次に、戻るか否かを判定する（Ｓ２９）。ここでは、制御部９ｈは、メニュー画面上の「戻る」（図６、図７（ａ）、図８参照）が選択されたか否かに基づいて判定する。この判定の結果、戻るが選択されていない場合には、ステップＳ１１に戻り、一方、戻るが選択された場合には、ステップＳ１に戻る。

　このように、医師端末９ｅにおける制御部の動作によれば、医師が患者の病状に関する情報を入力し（Ｓ５）、患者の時系列データを取得可能な機器を特定し（Ｓ１３）、特定された機器と同様の機器を有する他の人の時系列データと診察情報を、教師データ化して学習を依頼している（Ｓ２７）。このため、新しい症状に遭遇した場合であっても、同様の機器による他の人の検査データと、その他の人の診察情報を用いて、推論モデルを生成することができる。この推論モデルを使用すれば、新しい症状に遭遇した場合でも、的確な診察をする際の参考情報として使用することができる。また、このデータはどの人のどの時刻におけるデータであるかが分かれば、時系列でなくとも良い。例えば、発熱などは、突発的な場合があり、時系列のデータを解析せずに使える教師データとなり得る。

　また、推論モデルが生成された後であって、医師が患者を診察した際に、患者の履歴データに基づいて、疾病に関する推論を行いたい場合には（Ｓ２５Ｙｅｓ）、患者の履歴データを推論モデルに入力し、推論結果を得るようにしている（Ｓ２７）。医師はこの推論結果を参照して、患者の病状を診断することができる

　このように、健康関連データから、どのような診察結果、診断結果になりうるかの推論モデルが作られ、使いたい人や使いたいサービス、システム等が、適宜、使えるようにすれば、第１～第３機器（図１Ａ参照）から、日常的に得られるデータを、この推論モデルの入力にすることによって、多くの診断支援や健康管理に利用可能となる。これは、ＩＴ技術の進展によって、ＩｏＴ化の流れから、様々な機器がインターネットにつながるようになったので、世の中に様々な見守り機器（例えば、図１Ａの第１～第３機器等）から、多くの人たちの健康関連情報が取得できるようになった事、多くの人が情報端末を使って、有用な情報にアクセスしやすくなった事等を、背景として可能になったものである。

　これらの技術によって、上述の見守り機器（例えば、図１Ａの第１～第３機器等）を、個々人の健康意識を後押ししたり、通院の必要性を確認したりするためのツールにすることが可能となる。患者が病気を押してわざわざ診察を求め、医師が様々な検査情報や問診などによって、時間をかけて得られた貴重な診断結果であるから、上述のプロセスを経て作成された推論モデルを、他の医師が診断の際に参照すれば、昨今の医師不足の問題や感染症の問題に対処することもできる。

　なお、ステップＳ１１ないしＳ２９における処理は、制御部９ｈが医師と連携して行うようにしているが、コンピュータが特定のプログラムをルーチンベースで行うようにしても勿論かまわない。すなわち、医師が医師端末９ｅのメニュー画面（図６（ａ）参照）においてアイコンを選択しなくても、自動的に各ステップを順次実行するようにしてもよい。

　次に、図１０Ａおよび図１０Ｂのフローチャートを用いて、制御部の動作の他の例を説明する。前述の制御部の動作の一例は、医師端末９ｅの制御部９ｈにおける動作であった。すなわち、制御部動作の一例では、医師端末９ｅの制御部９ｈが主体的に表示等の動作を実行していた。これに対して、制御部の動作の他の例では、サーバ側の制御部１が、医師端末９ｅおよび診断・検査機関９からの依頼を受け、表示等の動作を実行する。すなわち、クラウドによって、医師端末９ｅにおける表示等の動作を実行する。なお、クラウドとしての機能は、制御部１以外にも、診断・検査機関９の制御部９ｂが実行してもよい。

　図１０Ａに示すフローが開始すると、まず、各機器からデータを収集し、データベース（ＤＢ）化する（Ｓ３１）。ここでは、制御部１が第１機器２ａ、第２機器２ｂ、第３機器３等の検査機器から、検査データを収集し、ＤＢ部８に記録する。

　ステップＳ３１において、データの収集を開始しているが、データ収集開始のタイミングは、医師の指示でもよく、また各ユーザ自身（患者や患者候補、あるいは機器利用者）、あるいは各ユーザが使用しているの機器自体が異変に気付いて、データ収集を自動的に開始してもよい。また、機器導入時、購入時、あるいは特定のサービス契約時に機器がこうしたデータ蓄積を開始してもよい。機器が自動的にデータ収集を行う場合には、データ入力部によって入力したデータが想定外のデータの際には、想定外のデータであることを指定し、この指定したデータを収集する対応判定部を有するようにすればよい。この対応判定部を有するシステムであれば、医師が介在できないような状況下でも、異常の原因を推論可能なシステムにすることができる。

　制御部１が収集したデータ、あるいは時系列データ群は、後述するステップＳ６１において、推論依頼部１ｅおよび学習依頼部６を通じて学習部５に送信され、推論モデルの生成が依頼される。この推論モデルは、制御部１が有していてもよく、あるいは各機器（例えば、第１～第３機器等）が有しててもよい。推論モデルに、ユーザの健康関連データ・見守りデータを入力するによって、健康状態の推論が可能となり、その結果から、各ユーザは自分の健康状態を把握することができる。

　推論モデルには、医師の診断結果が反映されるので、信頼性、確度の高い推論が可能となる。必要に応じて、どの医師が作った推論モデルか、どのような仕様のものかをユーザ端末に推論結果と合わせて表示してもよい。多くの医師が同様の気づきがあり、医師の社会貢献意識があることから、独自の工夫を加えたりしながら、またどのデータを使うべきか等の情報を加たりしながら、同様の推論モデルを作る可能性がある。推論モデルが入力（見守り）データの特徴から自動で選択されてもよく、人気モデルをユーザが選択したり、評価をインターネット上に公表したりできるようにしてもよい。

　また、収集された想定外のデータを教師データとして、推論システムに対応する推論モデルの学習要求を行う推論依頼部を有するシステムとしてもよい。このシステムは、ユーザの実際の異常や機器の何らかのトラブルも含め、同様の事象が起こっている他の機器の、あるいは類似の状況の他の機器のデータをビッグデータとして扱い、その状況がどのような状況であるか（例えば、よくあることなのか、集団で起こっていることなのか、単発の偶然なのか）を判断するための情報を収集することが可能となる。その人にとって未知の事象は不安ばかりが募るが、不安を緩和する情報を集めることも可能であり、また緊急である場合に、収集された類似のデータから確認、判断することもできる。例えば、未知の感染症が突発した場合、その感染が起こった場所の情報なども特定でき、その場所に行った事があるか否かによって、その後の行動を変えることが出来る。

　データを収集して、ＤＢ化すると、次に、医師が特定疾患（Ａ）を指定したか否かを判定する（Ｓ３３）。医師が患者を診察し、特定疾患（Ａ）と診断すると、その旨を記録したデータファイルＤＦ２が診断・検査機関９から制御部１に送信される。このステップでは、制御部１がデータファイルＤＦ２に記録されている情報に基づいて判定する。医師が診断・診察を行うたびに、データファイルを制御部１に送信し、教師データ化しても良い。しかしこれに限らず、医師がこれはと思う疾患を指定してもよい。この指定疾患としては、慢性的なもので生活習慣などの影響があり、他の患者予備軍の参考になる場合や、遺伝性、あるいは特定の体質や病歴があり、同様の来歴を有する特定疾患の患者予備軍として参考になる場合や、あるいは感染性で、多くの人に影響があり急を要する場合がある。

　ステップＳ３３における判定の結果、医師が特定疾患（Ａ）と指定したと判定した場合には、ＤＢの中でＡ患者を検索する（Ｓ５１）。ここでは、制御部１（検索部１ｆ）が、ＤＢ部８の中から疾病Ａに罹患した患者を検索する（図３参照）。

　次に、疾病Ａの患者が生活習慣機器を保有しているか否かを判定する（Ｓ５３）。前述したように、ＤＢ部８には、個人ＩＤ、疾病名、所有機器（使用可能機器）が記録されている（図３参照）。ここでは、制御部１は、疾病Ａの患者が所有（使用）している機器があるか否かを判定する。

　ステップＳ５３における判定の結果、機器を保有している場合には、Ａ患者と保有機器を表示する（Ｓ５３）。ここでは、制御部１は、ＤＢ部８から検索された結果、すなわち、疾病Ａの患者が保有している機器の種類を、診断・検査機関９を通じて、医師端末９ｅの表示部９ｆに表示する（例えば、図４（ａ）参照）。

　ステップＳ５５において保有機器の表示を行うと、またはステップＳ５３における判定の結果、機器を保有していない場合には、次に、医師が機器ａを選択か否かを判定する（Ｓ５７）。ステップＳ５５において、機器が表示された際に、医師が機器を選択すると、選択結果が、診断・検査機関９を通じて制御部１に送信される。ここでは、医師端末９ｅからの情報に基づいて、医師が機器ａを選択したか否かを判定する。医師がその経験、知識などによる判断によって、意味のある関連ありそうなデータを取得可能な機器を選択するので、本フローでは、医師の選択結果を判定している。しかし、これに限らず、この工程を自動化して、あらゆる情報、あるいは特定のロジック、プログラムによって、機器を選択するようにしてもよい。

　ステップＳ５７における判定の結果、医師が機器ａを選択した場合には、次に、選択機器ａの過去情報を取得し、また医師端末に表示確認を行ってもよい（Ｓ５９）。ここでは、制御部１は、ＤＢ部８に記録されている機器ａによる過去の検査データを取得する。この取得した検査データを、医師端末９ｅに送信し、表示部９ｆに表示してもよい。この場合には、医師は機器ａによって取得された、他の人の検査データを確認することができる。

　続いて、教師データ化し、学習を依頼し、推論モデルを取得する（Ｓ６１）。ここでは、制御部１は、ステップＳ５９において取得した、機器ａによって取得された検査データを教師データとし（たとえば、図５参照）、この教師データを用いて推論モデルを生成するように、学習依頼部６を通じて、学習部５に依頼する。ここでの推論モデルを用いた推論は、特定の検体情報、生体情報を入力し多彩に、診断補助情報を推論結果として取得する。また、学習部５が推論モデルを生成すると、学習依頼部６を通じて、推論モデルを取得する。

　ステップＳ６１において推論モデルを取得すると、またはステップＳ５７における判定の結果、医師が機器ａを選択していない場合には、次に、検索終了か否かを判定する（Ｓ６３）。ここでは、制御部１は、医師がステップＳ５１における検索を終了したか否かを判定する。この判定の結果、検索が終了していない場合には、ステップＳ５３に戻る。一方、検索を終了した場合には、ステップＳ３１に戻る。

　ステップＳ３３に戻り、このステップにおける判定の結果、医師が特定疾患（Ａ）と指定していないと判定した場合には、次に、推論モデルに入力する対応データがあるか否かを判定する（Ｓ３５）。ここでは、制御部１は、推論モデルを用いて推論を行う必要のある対応データがあるか否かを判定する。例えば、医師端末９ｅから検査データと共に推論の依頼を受けているか否かに基づいて判定してもよい。この判定の結果、対応データがない場合には、ステップＳ３１に戻る。

　また、生活習慣や遺伝性、感染性の疾患に関するデータである場合、家族などにも同様の疾患が起こりうるので、推論するデータとして、対象者の家族のデータを入力し、個人ではなく、その家庭に対する健康アドバイスを行えるようにしてもよい。また、健康診断の際に何か異常が発見された場合、その項目を中心とする推論を行ってもよい。そのために、この対象者が使用しているセンサの中から、その症例に相応しい機器を見守りセンサとして指定してデータを収集してもよい。つまり、制御部１が、特定人物の健診結果のうち、特定の診断がなされた特定診断結果を判定する判定部（ＤＢなどを検索して判定する）と、遺伝や生活習慣に依存する症状を抽出する症状抽出部と、抽出された症状に対応する見守りセンサを決定する決定部を有し、この決定に応じて、各機器との通信を行うよう通信制御部１ａを制御して、必要なデータを集めるようにする。

　また、患者が、癌や慢性疾患を罹患している場合には、ＤＢ部９ａ（他のＤＢ部や端末のメモリ記録部でもよい）に記録されている患者ごとの遺伝子情報や、マイクロバーム（常在菌の一種）情報を用いて、診察・診断時や、推論時に精度を向上させてもよい。例えば、これらの情報を、いくつかのタイプごとや、特定の遺伝子や常在菌の有無情報にして単純化して記録してもよい。

　一方、ステップＳ３５における判定の結果、対応データがある場合には、推論を行う（Ｓ３７）。前述したように、推論モデルを用いた推論は、特定の検体情報、生体情報を入力し多彩に、診断補助情報を推論結果として取得する。ここでは、制御部１は、対応データを推論エンジン７の入力層に入力して、推論結果を得る。推論結果として、例えば、如何なる疾病に罹患しているかについての確率等が出力される。

　推論を行うと、次に、疾患Ａに近いか否かが判定される（Ｓ３９）。ここでは、制御部１は、ステップＳ３７における推論結果に基づいて、疾病Ａに近いか否かを判定する。この判定の結果、疾病Ａに近くない場合には、ステップＳ３１に戻る。

　一方、ステップＳ３９における判定の結果、疾病Ａに近い場合には、必要に応じて、医師にも情報を出力する（Ｓ４１）。ここでは、制御部１は、診断・検査機関９を通じて、医師端末９ｅに推論結果を出力する。

　また、判定個人に推論結果情報を出力する（Ｓ４３）。この場合には、制御部１は、疾患Ａに近いことを、患者の所有する端末４等に出力する。疾患Ａに近い場合のアドバイスとしては、時系列の生体データなどの解析で、予測推論が可能な場合、早めの精密検査や治療開始を勧める表示等がある。

　また、このＤＢ部８が、各クリニック、病院など医療機関、検査機関が有する検査機器や検査キットの管理情報を集めて一元管理できるようにしてもよい。どこにどのような機器があると分かっていれば、患者や医師などが、正確な情報をもとに判断し、行動することで、余計な感染リスクや誤診の問題に対処することが出来る。このような設備管理をもとにしたアドバイスを患者や医師等に行えば、患者や医師等は検査・医療機関ごとの保有機器情報を記憶する記憶部（ＤＢ）のアクセスすることができる。情報提供部１ｃは、こうした保有機器、設備情報を加味した有効情報を対象者に伝達することが出来る。つまり、対象者の検査データやプロフィール情報に加え、上記検査・医療機関ごとの保有機器情報に従った情報提供が可能となる。

　その他、食事、睡眠時間、運動など、生活習慣に関するアドバイスを情報出ししてもよい。「推論結果の情報出し」は、出す情報の全てを推論で作る必要はなく、推論結果から検索可能な一般的な情報を提示したりしてもよい。ステップＳ４３において情報を出力すると、またはステップＳ３９における判定の結果、疾患Ａに近くない場合には、ステップＳ３１に戻る。

　このように、図１０Ａおよび図１０Ｂに示す、制御部１における制御部の動作によれば、医師が患者の病状に関する情報を入力し（Ｓ３３参照）、患者の時系列データを取得可能な機器を特定し（Ｓ５３、Ｓ５５参照）、特定された機器と同様の機器を有する他の人の時系列データと診察情報を、教師データ化して学習を依頼している（Ｓ５９、Ｓ６１参照）。このため、新しい症状に遭遇した場合であっても、同様の機器による他の人の検査データと、その他の人の診察情報を用いて、推論モデルを生成することができる。この推論モデルを使用すれば、新しい症状に遭遇した場合でも、的確な診察をする際の参考情報として使用することができる。

　なお、ステップＳ５９、Ｓ６１における処理は、医師と連携して行うようにしているが、コンピュータが特定のプログラムをルーチンベースで行うようにしてもよい。また、本フローでは、人工知能（ＡＩ）を前提にして記載したが、必ずしも深層学習による推論モデルを使った推論である必要はない。特定のロジックやルールに従ったプログラムによる分岐やテーブル参照などであってもよい。

　以上説明したように、本発明の一実施形態とその変形例においては、医師が特定の患者の病状に入力する入力ステップ（例えば、図８、図９ＡのＳ５、図１０ＡのＳ３１参照）と、患者の過去の時系列データを取得可能な機器を特定する機器特定ステップ（例えば、図４、図９ＡのＳ１１、Ｓ１３参照）と、特定された機器と同様の機器を有する別の人の時系列データと、診察情報を教師データ化して学習を依頼する学習依頼ステップ（例えば、図５、図７、図９ＢのＳ２１、図１０ＢのＳ６１参照）を実行している。このため、医師等が診察している際に、患者の過去のデータを簡単に確認することができ、さらに、患者が検査に使用している機器と同様の機器を使用している他の人のデータを用いて、疾病推論用の推論モデルを生成することが容易にできる。すなわち、本実施形態によれば、新しい事象が起きた際に、この事象に至った過程を示す情報を容易に収集し、またこの収集した情報を基に推論モデル生成用の教師データを作成することができる。

　また、本発明の一実施形態とその変形例において、対象者の検査データを取得する検査データ取得部と上記対象者のプロフィール情報と、検査・医療機関ごとの保有機器情報を記憶する記憶部の情報に基づいて、上記検査・医療機関ごとの保有機器情報に従って、上記対象者に伝達する伝達情報を決定する伝達情報決定部とを有する情報伝達用の装置や方法が提案可能となる。この場合には、診断・検査機関のＤＢ部９ａに、保有機器情報を記憶し、またＤＢ部８にも保有機器情報を記憶すればよい。

　また、本発明の一実施形態とその変形例において、第１の機器によって対象者の時系列的な第１の検査データ群を取得する第１の検査データ取得部と、上記第１の検査データ群を補間できるような検査が可能な第２の機器によって上記対象者の時系列的な第２の検査データ群を取得する第２の検査データ取得部を設ける、あるいは利用することによって、上記第１の検査データ群と上記第２の検査データ群を用いて、上記対象者に提供する伝達情報を決定する情報伝達の装置や方法を提供することが可能である。なお、上記第１の検査データ群と、上記第２の検査データ群は、互いに検査タイミングまたは検査項目を補っていることによって、機器に束縛されず、豊富な分析、推論等が可能となる。前述したように、複数の機器によって、ユーザの時系列的検査データを取得した場合には、個々の機器の誤差や特性の差等があることから、複数の時系列的検査データを同一のグラフにプロットすることができない。但し、同一対象者の時系列的検査データであることから、データの変化パターンの傾向は同じである。そこで、複数の時系列的検査データに対して、補正演算を行う等、第１、第２の検査データを補う処理を施すことによって、複数の時系列的検査データを用いて、伝達情報を決定すればよい。

　また、本発明の一実施形態とその変形例において、多数の装置から収集したデータを教師データとして学習することによって生成された推論モデルを用いて推論を行う推論システムであって、収集データが想定外のデータが得られた場合に、想定外のデータを指定し、この指定したデータを収集する対応判定部を持たせ、このように集めた想定外のデータを少なくとも教師データの一部として、上記推論システムに対応する推論モデルの学習要求を行うような推論システムや装置、方法が提供可能となる。

　また、本発明の一実施形態とその変形例において、特定人物の健診結果が特定の診断であった場合、特定診断結果とし、また、遺伝や生活習慣に依存する症状を抽出し、上記抽出された症状に対応する見守りセンサを決定するセンサ決定装置や方法も提供可能である。この場合には、ＤＢ部８ａに記録されるＩＤ別の利用可能な機器の一覧表には、個人利用可能な機器とその機能、および対応症例を記録する。個人利用可能機器は、第１機器２ａ、第２機器２ｂ、第３機器３、診断・検査機関９、ユーザ情報部等から自動的に送信されてきてもよく、またユーザがアンケート等によって入力したデータを取得するようにしてもよい。また、ＤＢ部８ａに記録される履歴データは、ユーザの一人一人を識別するための個人ＩＤ毎に作成される。履歴データは、ＩＤ毎に、扶養関係、血縁関係、医療情報、機器ＩＤ、取得データを記録する。遺伝や生活習慣に関する症状は、扶養関係や血縁関係に関連することが多いので、これらの者にも見守りセンサを決定してもよい。

　なお、本発明の各実施形態や変形例においては、制御部１、制御部９ｂ、制御部９ｈは、ＣＰＵ、メモリ、ＨＤＤ等から構成されているＩＴ機器として説明した。しかし、ＣＰＵとプログラムによってソフトウエア的に構成する以外にも、各部の一部または全部をハードウエア回路で構成してもよく、ヴェリログ（Verilog）によって記述されたプログラム言語に基づいて生成されたゲート回路等のハードウエア構成でもよく、またＤＳＰ（Digital Signal Processor）等のソフトを利用したハードウエア構成を利用してもよい。これらは適宜組み合わせてもよいことは勿論である。

　また、制御部１、制御部９ｂ、制御部９ｈは、ＣＰＵに限らず、コントローラとしての機能を果たす素子であればよく、上述した各部の処理は、ハードウエアとして構成された１つ以上のプロセッサが行ってもよい。例えば、各部は、それぞれが電子回路として構成されたプロセッサであっても構わないし、ＦＰＧＡ（Field Programmable Gate Array）等の集積回路で構成されたプロセッサにおける各回路部であってもよい。または、１つ以上のＣＰＵで構成されるプロセッサが、記録媒体に記録されたコンピュータプログラムを読み込んで実行することによって、各部としての機能を実行しても構わない。

　また、本明細書において説明した技術のうち、主にフローチャートで説明した制御に関しては、プログラムで設定可能であることが多く、記録媒体や記録部に収められる場合もある。この記録媒体、記録部への記録の仕方は、製品出荷時に記録してもよく、配布された記録媒体を利用してもよく、インターネットを通じてダウンロードしたものでもよい。

　また、本発明の一実施形態においては、フローチャートを用いて、本実施形態における動作を説明したが、処理手順は、順番を変えてもよく、また、いずれかのステップを省略してもよく、ステップを追加してもよく、さらに各ステップ内における具体的な処理内容を変更してもよい。

　また、特許請求の範囲、明細書、および図面中の動作フローに関して、便宜上「まず」、「次に」等の順番を表現する言葉を用いて説明したとしても、特に説明していない箇所では、この順で実施することが必須であることを意味するものではない。

　本発明は、上記実施形態にそのまま限定されるものではなく、実施段階ではその要旨を逸脱しない範囲で構成要素を変形して具体化できる。また、上記実施形態に開示されている複数の構成要素の適宜な組み合わせによって、種々の発明を形成できる。例えば、実施形態に示される全構成要素の幾つかの構成要素を削除してもよい。さらに、異なる実施形態にわたる構成要素を適宜組み合わせてもよい。

１・・・制御部、１ａ・・・通信制御部、１ｂ・・・ＩＤ判定部、１ｃ・・・情報提供部、１ｄ・・・推論モデル仕様決定部、１ｅ・・・推論依頼部、１ｆ・・・検索部、２ａ・・・第１機器、２ａ１・・・種別情報、２ｂ・・・第２機器、２ｂ１・・・種別情報、３・・・第３機器、３ａ１・・・種別情報、４・・・端末、５・・・学習部、５ａ・・・入出力モデル化部、５ｂ・・・仕様照合部、６・・・学習依頼部、６ａ・・・記録部、６ｂ・・・対象物種類Ａ画像群、６ｃ・・・教師データ、６ｄ・・・仕様設定部、６ｅ・・・通信部、６ｆ・・・制御部、７・・・推論エンジン、８・・・ＤＢ部、８ａ・・・ＩＤ別履歴一覧、９・・・診断・検査機関、９ａ・・・ＤＢ部、９ｂ・・・制御部、９ｃ・・・表示制御部、９ｅ・・・医師端末、９ｆ・・・表示部、９ｇ・・・操作部、９ｈ・・・制御部

Claims

　医師が特定の患者の病状に関する情報を入力する入力部と、
　上記患者の過去の時系列データを取得可能な機器を特定する機器特定部と、
　上記機器特定部によって特定された機器と同様の機器を使用している別の人について、上記同様の機器を用いて収集したデータと、診察情報と、を教師データ化して学習を依頼する学習依頼部と、
　を有することを特徴とする教師データ収集依頼装置。
　上記学習依頼部は、学習を依頼して作成する推論モデルの入出力の関係が、上記同様の機器によって収集した収集データが入力となり、医師によって入力された患者の病状に対応する情報が出力となるように、上記教師データを収集することを特徴とする請求項１に記載の教師データ収集依頼装置。
　上記教師データ収集依頼装置は、さらにデータ収集用の機器の選択を行うために、機器を表示する表示部を有し、
　上記機器特定部は、上記表示部に表示された機器の中から特定する、
　ことを特徴とする請求項１に記載の教師データ収集依頼装置。
　教師データを使って学習した上記推論モデルの想定結果は、特定の検体情報および／または生体情報を入力とし、出力を診断補助情報とすることを特徴とする請求項２に記載の教師データ収集依頼装置。
　複数の対象物と、複数の時点における特定情報の経時変化とを取得可能な機器を表示部に一覧表示させる表示制御部を有することを特徴とする請求項１に記載の教師データ収集依頼装置。
　複数の時点における特定情報の経時変化を表示部に一覧表示させる表示制御部を有することを特徴とする請求項１に記載の教師データ収集依頼装置。
　上記学習依頼部に依頼して生成した推論モデルに、患者の過去の時系列データを入力し、取得した診断補助情報を表示部に表示させる表示制御部を有することを特徴とする請求項１に記載の教師データ収集依頼装置。
　医師が特定の患者に対して診断した結果に基づいて、上記患者の病状に関する情報を入力する入力部と、
　上記患者の過去の時系列データを取得可能な機器を特定する機器特定部と、
　上記機器特定部によって特定された機器と同様の機器を使用別の人について、上記同様の機器を用いて収集したデータと、診察情報と、を教師データ化して学習を依頼する学習依頼部と、
　を有することを特徴とする教師データ収集装置。
　特定の患者の病状に関する情報を入力する入力ステップと、
　上記患者の過去の時系列データを取得可能な機器を特定する機器特定ステップと、
　上記特定された機器と同様の機器を有する別の人の時系列データの収集を依頼する依頼ステップと、
　を有することを特徴とする教師データ収集方法。
　教師データ収集装置に設けられたコンピュータに、
　特定の患者の病状に関する情報を入力する入力ステップと、
　上記患者の過去の時系列データを取得可能な機器を特定する機器特定ステップと、
　上記特定された機器と同様の機器を有する別の人の時系列データの収集を依頼する依頼ステップと、
　を実行させるためのプログラムを記憶したことを特徴とする記録媒体。
　教師データ収集装置に設けられたコンピュータに、
　医師が特定の患者に対して診断した結果に基づいて、上記患者の病状に関する情報を入力する入力ステップと、
　上記患者の過去の時系列データを取得可能な機器を特定する機器特定ステップと、
　上記機器特定ステップによって特定された機器と同様の機器を使用別の人について、上記同様の機器を用いて収集したデータと、診察情報と、を教師データ化して学習を依頼する学習依頼ステップと、
　を実行させるためのプログラムを記憶したことを特徴とする記録媒体。