IP Force 特許公報掲載プロジェクト 2022.1.31 β版

知財求人 - 知財ポータルサイト「IP Force」

▶ オリンパス株式会社の特許一覧

特許7393518教師データ収集装置、教師データ収集方法および記録媒体
<>
  • 特許-教師データ収集装置、教師データ収集方法および記録媒体 図1A
  • 特許-教師データ収集装置、教師データ収集方法および記録媒体 図1B
  • 特許-教師データ収集装置、教師データ収集方法および記録媒体 図2
  • 特許-教師データ収集装置、教師データ収集方法および記録媒体 図3
  • 特許-教師データ収集装置、教師データ収集方法および記録媒体 図4
  • 特許-教師データ収集装置、教師データ収集方法および記録媒体 図5
  • 特許-教師データ収集装置、教師データ収集方法および記録媒体 図6
  • 特許-教師データ収集装置、教師データ収集方法および記録媒体 図7
  • 特許-教師データ収集装置、教師データ収集方法および記録媒体 図8
  • 特許-教師データ収集装置、教師データ収集方法および記録媒体 図9A
  • 特許-教師データ収集装置、教師データ収集方法および記録媒体 図9B
  • 特許-教師データ収集装置、教師データ収集方法および記録媒体 図10A
  • 特許-教師データ収集装置、教師データ収集方法および記録媒体 図10B
< >
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】特許公報(B2)
(11)【特許番号】
(24)【登録日】2023-11-28
(45)【発行日】2023-12-06
(54)【発明の名称】教師データ収集装置、教師データ収集方法および記録媒体
(51)【国際特許分類】
   G16H 50/20 20180101AFI20231129BHJP
【FI】
G16H50/20
【請求項の数】 16
(21)【出願番号】P 2022505669
(86)(22)【出願日】2020-03-12
(86)【国際出願番号】 JP2020010949
(87)【国際公開番号】W WO2021181634
(87)【国際公開日】2021-09-16
【審査請求日】2022-08-12
(73)【特許権者】
【識別番号】000000376
【氏名又は名称】オリンパス株式会社
(74)【代理人】
【識別番号】100109209
【弁理士】
【氏名又は名称】小林 一任
(72)【発明者】
【氏名】野中 修
(72)【発明者】
【氏名】後町 智子
(72)【発明者】
【氏名】市川 学
(72)【発明者】
【氏名】藤原 弘達
(72)【発明者】
【氏名】櫻井 亮
【審査官】玉木 宏治
(56)【参考文献】
【文献】特開2009-076102(JP,A)
【文献】特開2019-114222(JP,A)
(58)【調査した分野】(Int.Cl.,DB名)
G16H 10/00-80/00
G06Q 50/22
(57)【特許請求の範囲】
【請求項1】
特定の患者の病状に関する情報を入力する入力部と、
上記入力部によって入力された上記患者の病状に関する情報に基づいて、上記患者の過去の上記病状に関連する時系列データを取得可能な機器を特定する機器特定部と、
上記機器特定部によって特定された機器と同種時系列データを取得可能な機器を使用している別の人について、上記同種時系列データを取得可能な機器を用いて収集したデータと、上記病状に関連する診察情報とを、教師データを作成するために、収集する収集部と、
を有することを特徴とする教師データ収集装置。
【請求項2】
上記収集部は、収集した上記データと、上記診察情報と、を教師データ化することを特徴とする請求項1に記載の教師データ収集装置。
【請求項3】
上記収集部は、教師データにて学習を依頼することを特徴とする請求項2に記載の教師データ収集装置。
【請求項4】
上記収集部は、上記同種時系列データを取得可能な機器を用いて収集した上記データが入力となり、上記診察情報における上記患者の病状に対応する情報が出力となるように、上記教師データ化を行うことを特徴とする請求項1に記載の教師データ収集装置。
【請求項5】
上記機器特定部は、データ収集用の機器の選択を行うために、機器を表示する表示部に表示された機器の中から上記患者の過去の時系列データを取得可能な機器を特定する、
ことを特徴とする請求項1に記載の教師データ収集装置。
【請求項6】
教師データを使って学習した推論モデルの想定結果は、特定の検体情報および/または生体情報を入力とし、出力を診断補助情報とすることを特徴とする請求項3に記載の教師データ収集装置。
【請求項7】
複数の対象物と、複数の時点における特定情報の経時変化とを取得可能な機器を表示部に一覧表示させることを特徴とする請求項1に記載の教師データ収集装置。
【請求項8】
複数の時点における特定情報の経時変化を表示部に一覧表示させることを特徴とする請求項1に記載の教師データ収集装置。
【請求項9】
上記教師データを用いて生成した推論モデルに、患者の過去の時系列データを入力して取得した診断補助情報を、表示部に表示させることを特徴とする請求項3に記載の教師データ収集装置。
【請求項10】
特定の患者に対して診断した結果に基づいて、上記患者の病状に関する情報を入力する入力部と、
上記入力部によって入力された上記患者の病状に関する情報に基づいて、上記患者の過去の上記病状に関連する時系列データを取得可能な機器を特定する機器特定部と、
上記機器特定部によって特定された機器と同種時系列データを取得可能な機器を使用している別の人について、上記同種時系列データを取得可能な機器を用いて収集したデータと、上記病状に関連する診察情報とを、教師データを作成するために、収集する収集部と、
を有することを特徴とする教師データ収集装置。
【請求項11】
上記収集部は、収集した上記データと、上記診察情報とを、教師データ化することを特徴とする請求項10に記載の教師データ収集装置。
【請求項12】
上記収集部は、教師データにて学習を依頼することを特徴とする請求項11に記載の教師データ収集装置。
【請求項13】
特定の患者の病状に関する情報を入力する入力ステップと、
上記入力ステップによって入力された上記患者の病状に関する情報に基づいて、上記患者の過去の上記病状に関連する時系列データを取得可能な機器を特定する機器特定ステップと、
上記特定された機器と同種時系列データを取得可能な機器を有する別の人の時系列データを、教師データを作成するために、収集する収集ステップと、
を有することを特徴とする教師データ収集方法。
【請求項14】
特定の患者に対して診断した結果に基づいて、上記患者の病状に関する情報を入力する入力ステップと、
上記入力ステップによって入力された上記患者の病状に関する情報に基づいて、上記患者の過去の上記病状に関連する時系列データを取得可能な機器を特定する機器特定ステップと、
上記機器特定ステップによって特定された機器と同種の時系列データを取得可能な機器を使用する別の人について、上記同種の時系列データを取得可能な機器を用いて収集したデータと、上記病状に関連する診察情報とを、教師データを作成するために、収集する収集ステップと、
を有することを特徴とする教師データ収集方法。
【請求項15】
教師データ収集装置に設けられたコンピュータに、
特定の患者の病状に関する情報を入力する入力ステップと、
上記入力ステップによって入力された上記患者の病状に関する情報に基づいて、上記患者の過去の上記病状に関連する時系列データを取得可能な機器を特定する機器特定ステップと、
上記特定された機器と同種時系列データを取得可能な機器を有する別の人の時系列データを、教師データを作成するために、収集する収集ステップと、
を実行させるためのプログラムを記憶したことを特徴とする記録媒体。
【請求項16】
教師データ収集装置に設けられたコンピュータに、
特定の患者に対して診断した結果に基づいて、上記患者の病状に関する情報を入力する入力ステップと、
上記入力ステップによって入力された上記患者の病状に関する情報に基づいて、上記患者の過去の上記病状に関連する時系列データを取得可能な機器を特定する機器特定ステップと、
上記機器特定ステップによって特定された機器と同種時系列データを取得可能な機器を使用する別の人について、上記同種時系列データを取得可能な機器を用いて収集したデータと、上記病状に関連する診察情報とを、教師データを作成するために、収集する収集ステップと、
を実行させるためのプログラムを記憶したことを特徴とする記録媒体。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は、医師等の専門家による日々の検査や診察の中で、新たな事象を見出した際に、この事象に至った過程を示す情報を容易に収集し、またこの収集した情報を基に推論モデル生成用の教師データを作成することができる教師データ収集装置、教師データ収集方法および記録媒体に関する。
【背景技術】
【0002】
自然言語処理やディープラーニング技術等の人工知能関連技術を用いて、テキストや画像などの情報を、複数のカテゴリのうちいずれかのカテゴリに分類する技術が知られている。しかし、人工知能に教師データを学習させたり、人工知能の分類結果を評価したり、異なる教師データを学習させた人工知能を切り替えて分類させるといった作業は、サービス提供者にとって煩雑な作業であり、サービス提供者にとって大きな負担となる。
【0003】
そこで、サービス提供者の負担を軽減するために、対象データと教師データを用いた学習結果に基づいて対象データを分類する学習モデルの特徴との対応関係を記憶しておき、クライアントから対象データを取得し、この対象データに対応した特徴を持つ学習モデルを指定して、対象データを分類させるようにした分類支援装置が提案されている(特許文献1参照)。
【先行技術文献】
【特許文献】
【0004】
【文献】特開2018-028795号公報
【発明の概要】
【発明が解決しようとする課題】
【0005】
上述の分類支援装置は、既に用意されている分類モデルに分類する際に、支援を行うことができる。しかし、新しい事象が起きた際に、この事象に至った過程を示す情報を容易に収集し、またこの収集した情報を基に推論モデル生成用の教師データを作成することについては記載されていない。
【0006】
本発明は、このような事情を鑑みてなされたものであり、新しい事象が起きた際に、この事象に至った過程を示す情報を容易に収集し、またこの収集した情報を基に推論モデル生成用の教師データを作成する教師データ収集装置、教師データ収集方法および記録媒体を提供することを目的とする。
【課題を解決するための手段】
【0007】
上記目的を達成するため第1の発明に係る教師データ収集装置は、特定の患者の病状に関する情報を入力する入力部と、上記入力部によって入力された上記患者の病状に関する情報に基づいて、上記患者の過去の上記病状に関連する時系列データを取得可能な機器を特定する機器特定部と、上記機器特定部によって特定された機器と同種時系列データを取得可能な機器を使用している別の人について、上記同種時系列データを取得可能な機器を用いて収集したデータと、上記病状に関連する診察情報とを、教師データを作成するために、収集する収集部と、を有する。
【0008】
第2の発明に係る教師データ収集装置は、上記第1の発明において、上記収集部は、収集した上記データと、上記診察情報と、を教師データ化する。
第3の発明に係る教師データ収集装置は、上記第2の発明において、上記収集部は、教師データにて学習を依頼する。
第4の発明に係る教師データ収集装置は、上記第1の発明において、上記収集部は、上記同種時系列データを取得可能な機器を用いて収集した上記データが入力となり、上記診察情報における上記患者の病状に対応する情報が出力となるように、上記教師データ化を行う。
第5の発明に係る教師データ収集装置は、上記第2の発明において、上記機器特定部は、データ収集用の機器の選択を行うために、機器を表示する表示部に表示された機器の中から上記患者の過去の時系列データを取得可能な機器を特定する。
【0009】
の発明に係る教師データ収集装置は、上記第の発明において、教師データを使って学習した推論モデルの想定結果は、特定の検体情報および/または生体情報を入力とし、出力を診断補助情報とする。
【0010】
の発明に係る教師データ収集装置は、上記第1の発明において、複数の対象物と、複数の時点における特定情報の経時変化とを取得可能な機器を表示部に一覧表示させる表示制御部を有する。
【0011】
の発明に係る教師データ収集装置は、上記第1の発明において、複数の時点における特定情報の経時変化を表示部に一覧表示させ
の発明に係る教師データ収集装置は、上記第3の発明において、上記教師データを用いて生成した推論モデルに、患者の過去の時系列データを入力し取得した診断補助情報を、表示部に表示させ
【0012】
第10の発明に係る教師データ収集装置は、特定の患者に対して診断した結果に基づいて、上記患者の病状に関する情報を入力する入力部と、上記入力部によって入力された上記患者の病状に関する情報に基づいて、上記患者の過去の上記病状に関連する時系列データを取得可能な機器を特定する機器特定部と、上記機器特定部によって特定された機器と同種時系列データを取得可能な機器を使用している別の人について、上記同種時系列データを取得可能な機器を用いて収集したデータと、上記病状に関連する診察情報とを、教師データを作成するために、収集する収集部と、を有する。
第11の発明に係る教師データ収集装置は、上記第10の発明において、上記収集部は、収集した上記データと、上記診察情報とを、教師データ化する。
第12の発明に係る教師データ収集装置は、上記第11の発明において、上記収集部は、教師データにて学習を依頼する。
第13の発明に係る教師データ収集方法は、特定の患者の病状に関する情報を入力する入力ステップと、上記入力ステップによって入力された上記患者の病状に関する情報に基づいて、上記患者の過去の上記病状に関連する時系列データを取得可能な機器を特定する機器特定ステップと、上記特定された機器と同種時系列データを取得可能な機器を有する別の人の時系列データを、教師データを作成するために、収集する収集ステップと、を有する。
第14の発明に係る教師データ収集方法は、特定の患者に対して診断した結果に基づいて、上記患者の病状に関する情報を入力する入力ステップと、上記入力ステップによって入力された上記患者の病状に関する情報に基づいて、上記患者の過去の上記病状に関連する時系列データを取得可能な機器を特定する機器特定ステップと、上記機器特定ステップによって特定された機器と同種の時系列データを取得可能な機器を使用する別の人について、上記同種の時系列データを取得可能な機器を用いて収集したデータと、上記病状に関連する診察情報とを、教師データを作成するために、収集する収集ステップと、を有する。
【0013】
15の発明に係る記録媒体は、教師データ収集装置に設けられたコンピュータに、特定の患者の病状に関する情報を入力する入力ステップと、上記入力ステップによって入力された上記患者の病状に関する情報に基づいて、上記患者の過去の上記病状に関連する時系列データを取得可能な機器を特定する機器特定ステップと、上記特定された機器と同種時系列データを取得可能な機器を有する別の人の時系列データを、教師データを作成するために、収集する収集ステップと、を実行させるためのプログラムを記憶する。
16の発明に係る記録媒体は、教師データ収集装置に設けられたコンピュータに、特定の患者に対して診断した結果に基づいて、上記患者の病状に関する情報を入力する入力ステップと、上記入力ステップによって入力された上記患者の病状に関する情報に基づいて、上記患者の過去の上記病状に関連する時系列データを取得可能な機器を特定する機器特定ステップと、上記機器特定ステップによって特定された機器と同種時系列データを取得可能な機器を使用する別の人について、上記同種時系列データを取得可能な機器を用いて収集したデータと、上記病状に関連する診察情報とを、教師データを作成するために、収集する収集ステップと、を実行させるためのプログラムを記憶する。
【発明の効果】
【0014】
本発明によれば、新しい事象が起きた際に、この事象に至った過程を示す情報を容易に収集し、またこの収集した情報を基に推論モデル生成用の教師データを作成する教師データ収集装置、教師データ収集方法および記録媒体を提供することができる。
【図面の簡単な説明】
【0015】
図1A】本発明の一実施形態に係る教師データ収集システムの全体構成を示すブロック図である。
図1B】本発明の一実施形態に係る教師データ収集システムの全体構成を示すブロック図である。
図2】本発明の一実施形態に係る教師データ収集システムにおける学習用データの例を示す図である。
図3】発明の一実施形態に係る教師データ収集システムのDB部に記録されるデータの一例を示す図である。
図4】発明の一実施形態に係る教師データ収集システムにおいて、医師操作用表示部における表示例を示す図である。
図5】発明の一実施形態に係る教師データ収集システムにおいて、医師操作用表示部における経時変化を示す表示例を示す図である。
図6】発明の一実施形態に係る教師データ収集システムにおいて、医師操作用表示部におけるメニュー画面の表示例を示す図である。
図7】発明の一実施形態に係る教師データ収集システムにおいて、医師操作用表示部における患者選択画面の表示例を示す図である。
図8】発明の一実施形態に係る教師データ収集システムにおいて、医師操作用表示部における診断入力画面の表示例を示す図である。
図9A】発明の一実施形態に係る教師データ収集システムにおいて、制御部の動作の一例を示すフローチャートである。
図9B】発明の一実施形態に係る教師データ収集システムにおいて、制御部の動作の一例を示すフローチャートである。
図10A】発明の一実施形態に係る教師データ収集システムにおいて、制御部の動作の他の例を示すフローチャートである。
図10B】発明の一実施形態に係る教師データ収集システムにおいて、制御部の動作の他の例を示すフローチャートである。
【発明を実施するための形態】
【0016】
以下、本発明の一実施形態として、ITプラットフォーム等を活用したデータ収集システムに本発明を適用した例について説明する。本実施形態に係るデータ収集システムは、多数の装置の出力データを収集し、この収集したデータを教師データとして学習することによって生成された推論モデルを用いて推論を行う。医師等の専門家が、日々、診察や健診の際に、対象者(ユーザ、患者)が意識していない病状等、正常な状態からの心身の変化を発見する場合がある。この場合、医師等が、対象者が使用している検査機器をデータ収集システムに入力すると、この対象者が検査機器によって習得した過去の時系列データを取得することができる。このデータを見ることによって、対象者のそれまでの過程を確認することができ、疾病等の判断する際の参考になる。
【0017】
また、データ収集システムは、対象者に限らず他の者が同様の機器を用いて検査した検査データを収集し、この収集したデータを表示することができる。専門家は、この他の者のデータを参考にすることによって、さらに精度の高い診断を行うことができる。
【0018】
また、医師等の専門家は、データ収集システムが収集したデータを教師データとして、推論モデルの生成を依頼することができる。この推論モデルは、見慣れない症状の際に、どのような疾病であるか、今後の症状の推移(例えば、いつ頃、悪化し医院に行くことになるか等)、治療方法等を推論することができる。なお、専門家の補助者が専門家の指導のもとで、専門家以外の人を補佐する等の応用が可能であることは言うまでもない。また、補助者や専門家以外の人が、専門家の方法を真似し、この行為を推論によって、チェックしてもらう方法等があるが、このような様々なケースにおいても、その来歴が明確化されていればよい。図2(a)に示すデータファイルのメタデータにアノテーションを付した人の分類やID等を記録できるようにし、専門家が行ったアノテーション結果に対しては、教師データの重みづけを重くするなどの工夫を行うようにしてもよい。
【0019】
また、本実施形態においては、データ収集システムは、ユーザ(対象者)の状況を考慮することによって正確な健康状態を把握し、カスタマイズ情報を提供するために、例えば、日々、健康状態に関する検査データを第1機器や第2機器等の検査機器によってモニタリングし、これらのデータを収集する。このデータ収取システムが収集したデータに基づいて、健康に関する情報を提供する。すなわち、この教師データ収集システムは、日々、複数の機器を用いて、ユーザの健康状態に関する検査データをモニタリングしている。
【0020】
このモニタリングによって取得した履歴データを用いて、ユーザに健康に関するアドバイスを表示することができる。また、アドバイスを提示するにあたっては、モニタリングで収集したデータを、推論モデルが設定された推論エンジンに入力し、推論エンジンの推論結果に基づいてアドバイスを表示することもできる。
【0021】
なお、この取得したデータは、何か特定項目の数値といったものでもよく、この取得データにメタデータが関連付けられている。このメタデータを含めて判定しても良い。このメタデータと取得データを併せて取得データと呼んでいるが、実際にはファイルやデータの形式によってこれらのデータ群を扱ったり、フォルダによってまとめてデータ群を扱ったりしてもよい。メタデータとしては、どの個人に属しているかという情報や、取得日時情報、データを出力する機器の種類やそのデータの種別などがある。メタデータは測定環境のデータなどを含んでもよい。もちろん、システムとして、これらのメタデータが示す変化要素を限定できる場合は、省略できるデータもある。
【0022】
ところで、ユーザが使用する検査機器としては、家庭、勤務先(通学している学校等も含む)に設置されている場合がある。家庭等に設置される検査機器としては、電子血圧計、電子体温計、トイレに設置された大便・尿の検査機器等がある。また家庭等以外にも、定期健康診断や人間ドック、献血等の際の健診等においても種々の検査機器が用いられる。さらに、ユーザが医療機関を受診した際にも種々の検査機器が用いられる。このように、種々の検査機器が使用されることが多く、通常、ユーザ毎に、検査機器は決まっていることが多い。
【0023】
また、ユーザの行動範囲や行動内容等が、特定の疾病の発症や悪化のリスクを伴う場合には、ユーザの所持するモバイル端末に備えられたGPSや決済機能等も検査機器となり得る。最近ではウェアラブル端末が上述した機能を有するものがある。スマートハウス等においては、洗面台に健康管理カメラが備えられていたり、室温の設定や電気ガス水道の利用、入浴の有無やタイミングなどを判定できるようにしたものもある。監視カメラや車載のカメラ等も検査機器として利用できる。このように雑多な機器が生活を見守る可能性があるが、すべての機器のデータを集めるとセンシングや記録に手間やエネルギーやメモリ容量、通信負荷の問題が生じて現実的ではない。また、どれが重要な情報かを、いちいち、ユーザが意識することはない。逆に、ユーザに意識させると、面倒な拒否反応も起こりうる。また、個人情報の問題もあり、一般には、これらの機器のデータを勝手に使用することは好ましくなく、サービスを行う事業体やシステムと対象となる特定のユーザとの契約で規定した条件で定められた情報の活用が好ましい。
【0024】
本実施形態においては、データ取集システムが、ユーザが使用する複数種類の検査機器からの情報を収集し、データベースに記録しておく。そして、前述したように、医師等の専門家が必要に応じてデータを検索し、またこれらのデータを用いて推論を行って、ユーザに種々のアドバイスを行うことができる。このアドバイスを行うための推論モデルの生成を、データ収集システムを通じて学習装置に依頼することができる。また、専門家以外の個人や団体が情報を得て、リスクの少ない行動の選択をするための推論モデルの生成を依頼することも可能である。
【0025】
次に、図1Aおよび図1Bを用いて、本発明の一実施形態にかかわる教師データ収集システムの構成を説明する。この教師データ収集システムは、制御部1、第1機器2a、第2機器2b、第3機器3、端末4、学習部5、学習依頼部6、推論エンジン7、データベース(DB)部8、診断・検査機関(医療機関等を含む)9、医師端末 9eからなる。なお、図1Bに記載の制御部1は、図1Aに記載の制御部1と同じであり、図1Bの制御部1では、内部の詳細な構成を省略している。
【0026】
データ収集システムの各部の内、制御部1は、サーバ内に配置されている。第1機器2a、第2機器2b、第3機器3、端末4、学習部5、学習依頼部6、推論エンジン7、DB部8(記録部、ストレージ部とも表現できる)、診断・検査機関9は、インターネット等のネットワークを通じてサーバに接続可能としている。しかし、本実施形態は、この構成に限定されることなく、例えば、制御部1、第1機器2a、第2機器2b、第3機器3、学習部5、学習依頼部6、推論エンジン7、DB部8の内のいずれか1つまたは複数が、サーバ内に配置され、他は別のサーバやパーソナルコンピュータ等の電子機器に、配置されていてもよい。更に、診断・検査機関9が、サーバの機能を有してもよい。
【0027】
また、第1機器2a、第2機器2b、第3機器3、端末4、診断・検査機関9が、制御部1と同様の機能を有し、DB部8と同様の記録機能を有して、以下、制御部1が行うとして説明する制御を実行してもよい。例えば、クラウド上にある制御部1とエッジ(端末)としての第1機器2a、第2機器2b、第3機器3、端末4、診断・検査機関9などと連携して制御部1が行うとして説明する制御を実行してもよい。これは、連携時の通信スピードや各エッジのハード構成や消費電力などに限界等のために、システムごとに最適化されることが多い。しかし、ここでは、単純化して説明できるように、制御部1が集中して以下の制御を行うとして記載している。
【0028】
制御部1は、本実施形態に係るデータ収集システムを制御するコントローラ(プロセッサ)であり、サーバ等や、ネットワークを通じて他の端末にファイルやデータなどを提供するCPU(Central Processor Unit)、メモリ、HDD(Hard Disc Drive)等から構成されているIT機器を想定している。しかし、制御部1は、この構成に限らず、小規模なシステムとして構築する場合は、パーソナルコンピュータのようなものでも構成は可能である。制御部1は、各種のインターフェース回路を有し、他の機器と連携することができ、プログラムによってさまざまな演算制御が可能である。
【0029】
制御部1は、連携する各装置から情報を受け取り、情報を整理し、必要な情報を生み出し、この情報をユーザに提供する。制御部1は、連携する各装置に依頼を出力し、また各装置を操作するような機能も有している。本実施形態においては、システムの自由度の高さや使い勝手を想定し、第1機器2a等の機器や、ユーザが有する端末4等と制御部1の間は、無線通信や有線通信で接続可能となっている。このための通信としては、無線LANや携帯電話通信網を想定し、状況に応じてブルートゥース(登録商標)や赤外通信などの近距離無線などを併用してもよい。通信回路、アンテナや接続端子等からなる通信部の記載は煩雑になるので図1においては省略してあるが、図中の通信を示す矢印の部分には、通信回路等を有する通信部が設けられている。
【0030】
制御部1は、通信制御部1a、ID判定部1b、情報提供部1c、推論モデル仕様決定部1d、推論依頼部1e、検索部1fを有する。これらの各部は、制御部1内のCPU等を有するプロセッサとプログラム等による、ソフトウエアによって実現してもよく、またハードウエア回路によって実現してもよく、またソフトウエアとハードウエア回路を協働させることによって実現してもよい。また、制御部1は、前述したように、CPU等を有するプロセッサで構成されており、通信制御部1a、ID判定部1b、情報提供部1c、推論モデル仕様決定部1d、推論依頼部1e、検索部1fが有する機能(例えば、入力部(クラウド制御時入力部))、機器特定部、学習依頼部、表示制御部等)を実現する。また、プロセッサは、1つに限らず複数に分割され、それぞれが協調して動作することによって、各部の機能を実現してもよい。
【0031】
例えば、図9Aおよび図9Bは、本発明の一実施形態に係るデータ収集システムにおいて、制御部の動作の一例を示すフローチャートであるが、フローチャートとしては、一つの制御部(例えば図1の制御部1)が各ステップをすべて実行しているように、単純化した記載となっている。しかし、実際には、各ステップにおいて他のブロック(例えば、第1機器2a~第3機器3、診断・検査機関9、DB部8、端末4など)と連携している。また、各ブロックそのものも、制御部1と類似の機能を有していることから、フローチャートにおける各ステップを各ブロック間で分担してもよい。このことは、クラウドとエッジ(端末)において、どちらが何をやるかという議論が一般的になされるように、状況やシステムの背景環境によって、どちらが実行するのが良いかが決まる。
【0032】
なお、図1Aにおいて、制御部1内の各部は、互いに連携してそれぞれの機能を果たすため信号の方向は省略しているが、これは、別途、フローチャートで説明する。例えば、図10AのS31のようなステップにおいて、ID判定部1bは、第1機器2a、第2機器2b等から、同一のユーザ毎に情報を収集している。
【0033】
通信制御部1aは、通信回路等を有し、第1機器2a、第2機器2b、第3機器3、端末4、学習部5、学習依頼部6、推論エンジン7、データベース(DB)部8、診断・検査機関9内に設けられた通信部(通信回路)と、データ等の送受信を行う。通信制御部1aは、装置から出力データを入力するデータ入力部(入力回路)としての機能を果たす。また、通信制御部1aは、情報を取得する情報取得部として機能する。なお、第1、第2機器2a、2b、第3機器3、端末4、診断・検査機関9等の各機器・各部もそれぞれ通信部を有しているが、図1においては煩雑になるため、図示を省略している。
【0034】
ID判定部1bは、第1機器2a等から、同一のユーザ毎に情報を収集する。第1機器2a、第2機器2b、第3機器3、診断・検査機関9によって情報が取得された個人を特定するため、個人毎にIDが割り当てられている。本実施形態においては、ユーザ個々のデータを取り扱うので、どのユーザの情報を受け取って、どのユーザにガイドを出すかの管理は、ID判定部1bが行っている。この特定ユーザの判定は、第1機器2a、第2機器2b、第3機器3が生体認証機能を有したり、ユーザが端末4によってIDを入力したり、ユーザが第1、第2機器2a、2b内の通信部を通じてIDを送信したり、また端末4が固有のコードを読み取ったりすることによって行う。なお、個人情報を保護するために、必要な部分を暗号化することによって管理を厳しくするが、これらは汎用的な技術であることから、詳しい説明を省略する。
【0035】
各機器のIDとしては、後述するように、各機器は種別情報を記憶しており、種別情報によって、その機器の機種名に関する情報やどの個体であるかを示す固有の情報等を判別するようにしてもよい。機種名から搭載するセンサの機能、性能などを、また個体情報から設置場所や利用環境などを分かるようにしてもよく、またこれらの情報を、ネットワークなどを通じて検索可能にしてもよい。機種名が分かれば、類似機器の情報を判定することが可能であり、また設置場所、利用環境から、緯度経度や室内室外、季節、天候、温度特性などを判定し、この判定結果を加味して、その機器の出力情報の補正を行ってもよい。
【0036】
情報提供部1cは、ユーザに正しい情報を提供するために、ユーザの情報を取得(他の装置が取得してあった結果を参照してもよい)する機能を有する。また、情報提供部1cは、第1機器2a等や診断・検査機関9から取得したユーザ(IDによって特定される)の検査データや、医師等による診断結果を取得する。情報提供部1cは、医師が特定の患者に対して診断した結果に基づいて、上記患者の病状に関する情報を入力する入力部(入力インターフェース、クラウド制御時入力部)として機能する(例えば、図9BのS31参照)。
【0037】
また、情報提供部1cは、診断・検査機関9から、要求があれば、第1機器2a等によって取得した検査データや、DB部8に記録されているデータ等を、診断・検査機関9に提供する。また、医師端末9eを使用する医師等から、診断・検査機関9を通じて要求があった場合にも、同様にデータを提供する。
【0038】
さらに情報提供部1cは取得した検査データや、診断・検査機関9から取得した種々の情報、およびDB部8に記憶された保有機器に関する情報やユーザのプロフィール情報等を用いて、ユーザの健康状態を判断する。健康状態としては、現在かかっている疾病や、将来、発症する可能性のある疾病を含み、健康状態を判断すると、ユーザに健康状態に関連する情報を提供する。また、ユーザの疾病等を判断した場合には、必要に応じて検査や治療を受けるべき施設に関する情報をユーザに提供する。
【0039】
また、特定の状況の利用者の健康状態を確認するために、制御部1が利用者のID等によって、現在の通院状況や、処方薬などの情報、過去の健康診断結果などを、診断・検査機関9に照会できるようにしておけば、機器データとの関連付けの判定が容易になる。これは、端末4を操作するユーザがその連携を許可したり、また診断・検査機関(のIT機器)9を操作する医師が、連携を許諾するような操作したりする等によって、セキュリティ上の問題を対策することが出来る。
【0040】
すなわち、情報提供部1cは、ユーザに健康に関する情報、例えば、いつ頃、検査や治療を受けるために施設を訪問することになるという情報や、検査や治療を受けるに適した施設を推奨するための情報を提供してもよい。情報提供部1cは、第1機器2a等や診断・検査機関9から送信されてきた検査データを取得する。このデータは、後述するように、時間情報が付された検査データ(時系列情報)であり、図5に示すようなグラフにできるようなデータ構造で蓄積される。なお、本実施形態においては、第1機器2a等や診断・検査機関9等における機器からの情報を用いて制御部1がユーザへ情報提供を行うことを想定しているが、診断・検査機関9を有するサーバが、同様に情報を収集するような変形例であってもよい。
【0041】
また、これらの情報を提供するために、情報提供部1cは、第1機器2a、第2機器2b等から検査データを収集し、DB部8に記録する。第1機器2aや第2機器2b等によって、情報取得の頻度やデータ数は異なっていてもよい。つまり様々な機器で得られた特定の健康関連数値の増減が時系列で整理されており、機器を変えて測定した数値は機器ごとに整理が可能となっている。
【0042】
DB部8にユーザの住所や勤務する場所における行動様式や食生活や就寝時間や食事のタイミングなど生活習慣等が記録されている場合には、情報提供部はこれらの情報を、DB部8からを取得してもよく、またこれらの情報をインターネット上において取得してもよい。情報提供部1cは、この取得した情報も加味して、ユーザに提供する施設等の情報を生成してもよい。これらの情報の取得は、汎用または広く知られた技術で補完が可能である。これらの情報を取得することによって生成した施設等の情報のカスタマイズも、また、情報提供部1cが行ってもよい。この施設に関するプロフィール情報は、診断・検査機関9から医療機関情報として取得する。
【0043】
情報提供部1cは、ユーザの特定期間の時系列パターンとなる検査データを取得する。この取得する時系列パターンは、単に1回だけの測定によって得たデータではなく、複数の異なるタイミングに測定によって取得した個々の検査データによって構成され、検査データのパターンの変化までを情報として利用する。複数の検査データからなる時系列パターンを使用することよって、測定環境や状況の変化によって生ずる誤差の影響を受け難くしている。さらに、特定期間の終了時期から将来の時期(特定期間の延長時)における健康状態を推論し、将来に対する予測を可能にしている。
【0044】
また、取得した時系列パターンに対して、ユーザの検査・医療機関への来院のタイミング情報をアノテーション情報として付与すれば教師データができる。この教師データを用いて学習することによって生成された推論モデルを有する推論部があれば、特定期間(時系列変化パターンを取得するための期間)から先のタイミング(特定期間の延長時)に何が起こるかの推論ができる。また、ユーザの病名等が分かれば、この情報をアノテーション情報として付与した教師データを生成することができる。この教師データを用いて学習することによって、病気等の健康情報を推論する推論モデルを生成することができる。なお、ここで使用される推論モデルを生成する際には、特定の入出力情報の仕様を規定し、学習を行う。
【0045】
このように、機械学習、深層学習するに際して、データにアノテーション(注釈)が付いたものを教師データとしている。時系列データ等、データ群を収集した時に、それぞれのデータがそのアノテーション結果に寄与する何らかの情報を含んでいると考えられ、この情報を含んでいるデータが、教師データとなる。ただし、何らかのトラブルで誤差やノイズがデータに重畳する場合があり、また情報検出や伝送時の不具合等によって、利用するに値しないものもあり得る。そこで、必要に応じて予め設定したデータ形式、データ仕様、データ種別、データ大きさの範囲などの条件を満たすデータの中から、教師データを選ぶようにしてもよい。
【0046】
したがって、本実施形態においては、ユーザの検査データの時系列変化パターンを、推論部に入力し、推論部が推論を行い、この推論結果に基づいて、特定期間から先のタイミングにおける伝達情報を決定する伝達情報決定部を設けている。このため、時系列パターンの検査取得時から先のタイミングにおける予測情報を伝達することができるシステム、装置、方法、プログラム等が提供できる。
【0047】
本実施形態において情報提供部1cは、学習部5によって生成された推論モデルが設定された推論エンジン7に、検査データの変化パターンを入力し、アドバイスに関する推論結果を得て、入力された検査データに対応するユーザに提供する。このサービスは個人情報を利用する場合があり、アドバイス等の提供を受けるために個人情報利用の契約などが必要な場合がある。その意味で、ユーザのプロフィール情報が重要な場合もある。また、ユーザが幼児や高齢の場合は、そのユーザの世話をする人、介助者などにアドバイスを届けてもよい。これもユーザのプロフィール情報で管理した情報に従ってアドバイスなどの有効情報が届く。
【0048】
推論モデル仕様決定部1dは、推論依頼部1eが学習依頼部6を通じて学習部5に推論モデルの生成を依頼する際に、生成する推論モデルの仕様を決定する。制御部1は、第1機器2a等からユーザの生体情報を取得し、この生体情報を蓄積している。制御部1は、蓄積した生体情報を教師データとして、学習依頼部6を通じて、学習部5に種々の推論モデルの生成を依頼する。また、後述するように、医師等が医師端末9eから、推論モデルの生成を依頼する場合がある(例えば、図9BのS21、S23参照)。この場合に、推論モデル仕様決定部1dが、推論モデルの仕様を決定するようにしてもよい。この推論モデルは、教師データを使って学習し、この推論モデルの想定結果は、特定の検体情報、生体情報を入力とし、出力を診断補助情報とする。
【0049】
類似の症例の患者やその予備軍に対して、有用な推論モデルがあれば、多くの人が自分の、あるいは扶養者などの健康関係情報を推論モデルに入力し、この推論結果を利用することによって、健康を増進できるという考え方がある。この考え方は、IT技術の進展によって、IoT化の流れから、様々な機器がインターネットにつながるようになったので、世の中に様々な見守り機器(例えば、図1Aの第1~第3機器等)から、多くの人たちの健康関連情報が取得できるようになり、また多くの人が情報端末を使って、有用な情報にアクセスしやすくなった事を背景として、生まれてきている。
【0050】
この考え方によって、個々人の健康意識を後押しし、また通院の必要性を確認するために見守り機器(例えば、図1Aの第1~第3機器)をツールとして利用することが可能となり、いたずらにクリニック等に出かけての感染してしまうことを防止することが出来る。例えば、第1~第3機器(図1A)として、例えば腕時計型の端末を想定し、睡眠と心拍数のモニタが出来るようにしておけば、近年の研究では、このモニタデータによってインフルエンザの可能性が導けるという報告もあるので、インフルエンザに対処することが可能となる。すなわち、実際に機器データに基づいて医師にインフルエンザと判定された場合と、そうでなかった場合が分かれば(このような方法を想定すると、医師はインフルエンザを疑ったがそうではなかった、といった診察結果、判定結果を入力できるようにしてもよい)、インフルエンザの可能性が低くて、医療機関で他の患者に接触するリスクや、インフルエンザの可能性があるのに、マスクも着用せず出かけて、他の患者にリスクを与えたりするケースを防ぐことができる。また、医師は、診察時に、上述の健康関係情報(日常において時系列的に得られたもの)を参照してもよい。さらに問診など(対面でもテレビ電話でも)に加え、インフルエンザ検査キット(感染症判定キット)などを使って診断を下せばよい。
【0051】
このようにして得られた、貴重な診断結果であるから、同様のプロセスを経て同様の診察が行われている、あるいは行われて来た知見を、総合的に利用しようというのが本実施形態である。つまり、様々な医療機関、医師において、様々な患者の診察、診断が行われた結果が教師データ化され、これらの教師データの集合であるビッグデータと上述のプロセスを経て作成された推論モデルを他の医師が参照すれば、昨今の医師不足の問題や、人々の健康意識向上の要求に対処することもできる。
【0052】
推論モデル仕様決定部1dは、推論モデルの生成に当たって、どのような仕様の推論モデルを依頼するかを決定する。例えば、時系列的な生体情報が蓄積されている場合に、推論モデル仕様決定部1dは、どのような検査データ(値)となると、ユーザは何日後に医療施設で治療を受けることになるかを推論するための推論モデルの仕様を決定する。また、推論モデル仕様決定部1dは、時系列的な生体情報に基づいて、現在、どんな疾病にかかっているか、また将来(いつ頃)どんな疾病にかかる可能性があるか、更に疾病にかかるかもしれない場合に必要な検査や治療を受けるために推奨される施設を推論する推論モデルを生成するための仕様を決定する。
【0053】
推論依頼部1eは、推論モデル仕様決定部1dによって決定された仕様の推論モデルの生成を、学習依頼部6を通じて、学習部5に依頼する。すなわち、推論依頼部1eは、第1機器2a等によって取得した生体情報が所定数蓄積している場合に、学習依頼部6を通じて、学習部5に推論モデルの生成を依頼し、生成された推論モデルを、学習依頼部6を通じて受信する。この受信した推論モデルは、推論エンジン7に送信される。なお、制御部1は、推論モデルを複数用意し、ユーザに提供すべき情報に応じて、適宜、推論モデルを選択するとよい。また、制御部1が直接学習部5と通信できれば、学習部5から推論モデルを直接受信してもよい。さらに、後述するように、医師等が医師端末9eから、推論モデルの生成を依頼する場合がある(例えば、図9BのS23参照)。この場合に、推論依頼部1eが、推論モデルの生成を、学習依頼部6を通じて、学習部5に依頼するようにしてもよい。
【0054】
推論依頼部1eは、収集された想定外のデータを教師データ化して、教師データ収集システムに対応する推論モデルの学習要求を行う推論依頼部として機能する。推論依頼部1eは、収集された教師データを用いて学習することによって生成される推論モデルを取得する推論モデル取得部として機能する。推論モデル取得部は、収集された教師データの値の時系列的な推移のパターンを学習し、推論モデルを取得する。推論依頼部1eは、定された機器と同様の機器を有する別の人の時系列データと、診察情報を教師データ化して学習を依頼する学習依頼部として機能する(例えば、図10BのS61参照)。
【0055】
検索部1fは、第1機器2a、第2機器2b、第3機器によって取得されたユーザの生体情報に基づいて、現在かかっている疾病、また将来(いつ頃)どんな疾病にかかる可能性があるか、さらに検査や治療が必要であることが判明した際に、検査や治療に必要な設備を有する検査機関や医療機関を、DB部8に蓄積されているデータベースの中で、検索を行う。これらの情報は、推論エンジン7を用いて、推論によって取得してもよいが、蓄積されているデータと一致する場合もある。このようなケースもあることから、本実施形態では、検索部1fによる検索を可能としている。
【0056】
また、後述するように、医師等が医師端末9eにおいて、患者が使用している検査機器を用いて取得した検査データを検索する場合がある(例えば、図9AのS17参照)。この場合に、診断・検査機関9を通じて、検索の依頼があれば、検索部1fが依頼に応じた検索を行う。検索部1fは、患者の過去の時系列データを取得可能な機器を特定する機器特定部として機能する例えば、図10BのS51、S53、S55参照)。機器特定部は、機器の一覧からデータ収集用の機器を表示部に表示させ、この表示された機器の中から特定機器を特定する(例えば、図10BのS55参照)。
【0057】
機器特定部が、患者の過去の時系列データを取得可能な機器を特定しているのは、共用の機器を多くの人が使う場合、「同じ機器」を用いて検査した別の人のデータを検索したり、「同じ型番の機器」あるいは「同様の仕様の機器」を用いて検査した別の人のデータを検索することによって、データをビッグデータ化し、ノイズデータを薄める効果や、教師データの量を増やす等の効果が有るからである。また、特定の状況が疾病や健康状態に影響することが分かっている場合は、その状況に揃えるために、データを適宜、取捨選択を行ってもよい。例えば、特定の性別、特定の年齢、特定の地域などの検索条件によって、データを選別する方が、効果がある場合は、検索時にその条件を付与する。
【0058】
第1機器2aおよび第2機器2bは、ユーザの健康関連情報、例えば、バイタル情報、検体情報等の検査データを取得するための機器である。第1機器2aと第2機器2bは、特定仕様の検査機器であり、同種(同様)の健康関連情報の検査が可能な機器である。第1機器2aは種別2a1を記憶しており、また第2機器2bは種別2b1を記憶している。種別2a1、種別2b1は、機器の種類、型番、検査項目等に関する情報であり、各機器によってユーザの検査データを制御部1に送信する際に、併せて送信される。
【0059】
第1機器2aと第2機器2bによって取得された検査データ群が、互いの検査タイミングが異なっている場合に、両データを補間できるような検査ができればよい。また、第1機器2aと第2機器2bは全く同一の検査項目を検査しなくてもよく、例えば血圧を測定しながら、心拍数を測定した場合であっても、両データは互いに補間することができる。なお、図1には、ユーザの検査データを取得するための機器として、第1機器2aおよび第2機器2bの2つのみを記載しているが、2つに限らず、3以上であってもよい。また、後述するように、ユーザ以外の者の検査データを取得するための機器として、本実施形態においては、第3機器3を想定している。
【0060】
なお、同じようなデータを継続して取得することによって、健康状態の確認がより精密にできる場合がある。例えば、一年の春夏秋冬、一日の朝昼晩、就寝直後、食前食後、あるいは勤務中とそれ以外、出勤日とテレワーク時、休日など、様々な要因によって、健康状態を示す数値が変化するので、データを継続して取得することによって、通常の検査では気づかないような異常が発見される場合もあり得る。このような状況に鑑みると、様々な状況で同様のデータを取り続けることが望ましい。しかし、データを取得する機器や装置が、状況ごとに異なっている場合があり、また状況ごとの環境変化や様々な制約によって差異や誤差が生じる場合があることから、同じ基準で比較できないことがあり得る。
【0061】
そこで、第1の機器によって対象者の時系列的な第1の検査データ群を取得できると共に、上記第1の検査データ群を補間できるような検査が可能な第2の機器によって上記対象者の時系列的な第2の検査データ群を取得可能とし、これらデータ群を用いることによって、上記第1の検査データ群と、上記第2の検査データ群が、互いに検査タイミングまたは検査項目を補っている関係とすることができる。状況によっては、異なる第1の機器と第2の機器の同様の数値の変化を判定する工夫が必要になるが、上記第1、第2のそれぞれの検査データ群ごとに補正することによって、誤差を解消し、情報を拡充、補充することが可能となる。また、補正した検査データ群を入力として推論した時の信頼性を算出し、この信頼性に従って、伝達情報を決定してもよい。信頼性が低い場合は補正が適切に行われおらず、推論結果を提供するに値しないと考えることが出来るからである。検査データを補正する際に、当該検査データ群に含まれるデータのそれぞれに共通する数値に対して四則演算を行うことで、単に誤差が乗った場合や、センサのゲインが異なる場合などに対応が可能となる。
【0062】
第1機器2a等が取得する健康関連情報としては、種々の情報があり、例えば、ユーザの体温、血圧、心拍等のバイタル情報がある。また健康関連情報としては、ユーザの尿、大便等の排泄物や、痰や、血液等、種々の検体情報がある。大便の場合には、第1機器2a、第2機器2bは、その色、形状、量、日時情報を取得する。第1機器2a、第2機器2bは、制御部1からの指示に従って情報を取得してもよく、またユーザの操作に応じて情報を取得してもよく、また自動的に情報を取得してもよい。さらに、第1機器2a等は、医療・健康情報である情報「パーソナル・ヘルス・レコード((Personal Health Records : PHR) 」に、日常生活、職場/学校での活動、食事、スポーツ活動など、日常生活の様々な活動データを加えたパーソナル・ライフ・レコード(Personal Life Records : PLR) を収集・活用してもよい。取得した情報は、第1機器2a等内の通信部(図示を省略)を通じて、制御部1に送信される。
【0063】
第1機器2a、第2機器2bが、ユーザに関する情報を得た場合、制御部1の情報提供部1cが健康に関する情報を、ユーザの情報端末4に提示する。この提示が、ユーザの行動を補助することを想定して、説明を行うが、様々な変形が考えられる。健康に関する情報としては、推奨する医療施設に関する情報や、日常の生活習慣に関する情報等がある。
【0064】
第3機器3は、第1機器2a、第2機器2bを利用するユーザとは異なる人のデータを取得する機器であってもよい。第3機器3は、第1機器2a、第2機器2bを利用するユーザが、新規に使用を開始する場合、または一時的に使用する場合がある。図1Aには、第3機器3は1個しか記載していないが、複数あってもよく、図1Aには不特定多数の機器を一括して表現している。
【0065】
なお、第3機器3も種別3a1を記憶している。種別3a1は、第3機器3の種類、型番、検査項目等に関する情報であり、第3機器3がユーザの検査データを制御部1に送信する際に、種別情報が併せて送信される。
【0066】
第1機器2a、第2機器2b、第3機器3としてウェアラブル端末を利用する場合には、ウェアラブル端末の装着部位によって、皮膚やあるいは身体近傍に密着し、体温、心拍、血圧、脳波、視線、呼吸、呼気などのバイタル情報を得ることが可能となる。また、体重計、血圧計、動脈壁の硬さを意味する動脈スティフネスを測定する測定器として、専用の精密な機器が、健康施設、公衆浴場、薬局、ショッピングモール等に配置され、さらに専門の計測者も一緒に配置されている場合がある。このような施設において、ユーザは空き時間などに測定機器を気楽に利用し、この時の測定結果に基づいて体調管理する場合も多い。これらの測定機器を第1機器2a、第2機器2b、第3機器3としてもよい。
【0067】
また、第1機器2a、第2機器2b、第3機器3は、ユーザが専用の端末等を使用した前後に、アンケートに記入を依頼する場合がある。このような場合には、このアンケートの記載に基づいて、ユーザのプロフィール情報やその他の情報を特定できる。このような情報収集は、第1機器2a等に限らず、制御部1が行ってもよい。何時、医療機関、検査機関等を受診したかの情報なども聞き取りできれば、これらも情報として使用することができる。
【0068】
第1機器2a、第2機器2b、第3機器3は、すでに特定の疾患にかかっていて、医師の指導のもとで使用している体温計や血圧計などでもよい。また、スマートフォンの有するカメラで撮影した顔や爪などの色や顔の表情、患部の画像、喉がおかしくなった時の声をマイクで収音する場合等では、携帯端末(スマートフォン)がそのまま第1機器2a、第2機器2b、第3機器3となりうる。
【0069】
最近では、簡易の健康管理機器や健康情報取得機器が開発されており、これらの機器がウェアラブル機器に搭載される場合がある、このような装置もスタンドアローンではなく、スマートフォンの周辺機器として扱われる場合が多いので、これも携帯端末として想定してもよい。また、ウェアラブルな機器でなくとも、簡易な測定機器を、人が集まる場所に設置し、健康情報サービスを提供している場合がある。このような機器を第1機器2a、第2機器2b、第3機器3として利用してもよい。
【0070】
第1機器2a、第2機器2b、および第3機器3からは、利用者ID、機器ID、出力データ等の情報が、制御部1の通信制御部1aに送信される。この送信時は、データファイルDF1のファイル形式によって送信される。データファイルDF1は、取得データRD1とメタデータMD1から構成される。取得データRD1は各機器が取得したデータであり、メタデータMD1は、取得データを取得した時の日時情報、検査を受けた人を特定するID、取得データを取得した機器情報等が含まれる。データファイルDFの他の形式については、図2を用いて後述する。
【0071】
診断・検査機関9は、DB部9a、制御部9b、表示制御部9cを有し、ユーザが健診・診察・検査を受ける施設であり、例えば、検査施設や医療施設があり、また薬局も含まれる。診断・検査機関9において診療等に従事する医師等は、後述する医師端末9eによって、診断・検査機関9と情報のやり取りを行うことができる。
【0072】
診断・検査機関9は、移動型、例えば、自動車、列車、船、ヘリコプター、ドローン等に一般医療機器や検査機器を搭載し、患者のもとに出向くタイプであっても勿論構わない。制御部1は、どの医療機関に行ったか、またどのような検査結果が出たかなどを診断・検査機関9のシステムを運営するサーバなどから取得可能である。逆に、制御部9bが、診断・検査機関9に属する医師等からの依頼に応じて、制御部1から種々のデータ等を取得することも可能である。もちろん、診断・検査機関9のサーバが制御部1と同じであってもよく、また一部の機能を分担してもよい。
【0073】
診断・検査機関9において、健診等を受けたユーザの情報は、データフィルDF2のファイル形式によって、制御部1の通信制御部1aに送信される。データファイルDF2は、取得データRD2とメタデータMD2から構成される。取得データRD2は各機器が取得したデータと日時の組み合わせであり、メタデータMD2は、取得データを取得した機器情報、診察結果情報等が含まれる。データファイルDFの他の形式については、図2を用いて後述する。
【0074】
診断・検査機関9のDB部9aは電気的に書き換え可能な不揮発性メモリである。DB部9aは、診断・検査機関9における診断結果や検査結果を個人ID毎に記録する。またDB部9aは、ユーザの生活習慣に関連する情報や、生活習慣に対する生活指導(生活習慣対応)等も記録することができる。さらに、ユーザが服用している薬剤等についても記録することができる。
【0075】
また、DB部9aは、必要に応じて患者ごとの遺伝子情報や、マイクロバーム(常在菌の一種)情報を記録しておき、診察・診断時や、推論時にDB部9aに記録されている情報を用いて精度を上げてもよい。例えば、これらの情報を、いくつかのタイプごとや、特定の遺伝子や常在菌の有無情報にして単純化して記録してもよい。遺伝子情報が癌などに影響する事が知られており、また、ヒトの常在菌は、口腔内や腸内など生息部位ごとに異なった細菌種や組成比からなる独特の細菌集団(細菌叢,マイクロバイオーム)を形成しており、常在菌叢は外からの菌を寄せつけないので、これらのタイプの差異がヒトの健康において重要な役割を果たしていることも知られている。
【0076】
また、DB部9aに、各医療機関が保有する機器の利用状況を管理するための管理データベースを設けてもよい。近年、医療機関の専門化が進み、あるいは掛かりつけ医制度が推進されており、特定の病状の患者は同じクリニックに通うことが多い。このクリニックには、その他の疾病用の検査機器や検査キットなどがない場合がある。そこで、医療機関が保有する機器に関する情報も管理できるようにしておけば、余計な診察の手間や感染リスクの問題に対処が可能となる。この情報をDB部8と共用できるようにしておけば、各クリニックも、どのクリニックや病院が、補完機能を持っているかを知ることができ、適切なアドバイスを来院者にすることが出来る。
【0077】
診断・検査機関9の制御部9bは、コントローラ(プロセッサ)であり、診断・検査機関9に設けられたサーバ等や、ネットワークを通じて他の端末にファイルやデータなどを提供するCPU(Central Processor Unit)、メモリ、HDD(Hard Disc Drive)等から構成されているIT機器を想定している。しかし、制御部9bは、この構成に限らず、小規模なシステムとして構築する場合は、パーソナルコンピュータのようなものでも構成は可能である。制御部9bは、各種のインターフェース回路を有し、他の機器と連携することができ、プログラムによってさまざまな演算制御が可能である。
【0078】
診断・検査機関9の表示制御部9cは、表示制御回路および通信回路を有し、医師端末9eの表示部9fにおける表示の制御を行う。医師端末9eは、診断・検査機関9における医師等が使用する端末であり、制御部9cとは、院内のイントラネット等の有線通信で接続されていてもよく、WiFi等の無線通信によって接続されていてもよい。
【0079】
表示制御部9cは、複数の対象物(対象者を含む)と、複数の時点における特定情報の経時変化とを取得可能な機器を表示部に一覧表示させる表示制御部として機能する(例えば、図4図9AのS13参照)。表示制御部9cは、複数の時点における特定情報の経時変化を表示部に一覧表示させる表示制御部として機能する(例えば、図5図9AのS17参照)。表示制御部9cは、学習依頼部に依頼して生成した推論モデルに、患者の過去の時系列データを入力し、取得した診断補助情報を表示部に表示させる表示制御部(例えば、図7(b)、図9BのS27参照)として機能する。なお、表示制御部の機能は、医師端末9eが有していてもよく、また制御部1が有していてもよい。
【0080】
医師端末9eは、スマートフォンやタブレット等の携帯情報端末であってもよく、またデスクトップタイプやノートパソコン等のパーソナルコンピュータであってもよい。医師端末9eの表示部9fは、ディスプレイを有し、図4ないし図8に示すように、診断・検査機関9を訪れた人に関する健康に関する情報を表示する。表示部9fは、推論モデルの入出力の関係が想定結果となるように教師データを収集するために、機器の一覧からデータ収集用の機器選択の表示を行う表示部(ディスプレイ)として機能する(例えば、図4(a)(b)参照)。
【0081】
また、医師端末9eには、操作部9gが設けられている。操作部9gは、ユーザの操作情報を入力するための入力インターフェースである。操作部9gは、操作用のスイッチや釦等を有し、また表示部9fの前面はタッチスクリーンとなっている。操作部9gは、医師が特定の患者の病状に入力する入力部(入力インターフェース、端末入力部)として機能する(例えば、図9AのS5参照)。
【0082】
制御部9hは、コントローラ(プロセッサ)であり、CPU(Central Processor Unit)、メモリ等から構成されている。制御部9hは、各種のインターフェース回路を有し、他の機器と連携することができ、プログラムによってさまざまな演算制御が可能である。制御部9hは、診断・検査機関9内の制御部9bと協働し、操作部9gによる操作に応じて、各種表示を行い、また推論モデル依頼や推論動作等、各種動作を実行する。また、制御部9hは、前述したように、CPU等を有するプロセッサで構成されており、機器特定部、学習依頼部等の機能を実現する。また、制御部9hは、機器特定部9haと学習依頼部9hbを有する。医師端末9eにおける表示の詳細については、図4ないし図8を用いて後述する。
【0083】
制御部9h内の機器特定部9haは、例えば、図4(a)(b)および図5に示すように、患者のIDを特定すると、その患者が所有(使用可能も含む)する機器と、その機器で取得した時系列データを特定する。すなわち、機器特定部9haは、患者の過去の時系列データを取得可能な機器を特定する機器特定部として機能する(例えば、図9AのS13、S17参照)。機器特定部は、表示部に表示された機器の中から特定する(例えば、図4図9AのS13参照)。
【0084】
また、制御部9h内の学習依頼部9hbは、例えば、図5図6に示すように、患者が所有(使用可能も含む)する機器と同様の機器を有する人の別の時系列データと、診察情報を用いて、教師データを作成し、この教師データに基づく学習によって推論モデルの作成を依頼する。すなわち、学習依頼部9hbは、特定された機器と同様の機器を有する別の人の時系列データと、診察情報を教師データ化して学習を依頼する学習依頼部として機能する(例えば、図9BのS23参照)。学習依頼部は、学習を依頼して作成する推論モデルの入出力の関係が、同様の機器によって収集した収集データが入力となり、医師によって入力された患者の病状に対応する情報が出力となるように、教師データを収集する。推論モデルは、教師データを使って学習することによって得る。この推論モデルの想定結果は、特定の検体情報、生体情報を入力とし、出力を診断補助情報である。
【0085】
端末4は、ユーザが使用する携帯情報端末であり、ユーザやその関係者が確認可能な情報を受け取るための装置である。情報としては、健康情報や、健康状態に応じて推奨される施設がある。端末4は、例えばスマートフォンやタブレットPCであってもよく、この場合には、内蔵カメラやマイクを情報取得部として利用することができる。また、連携可能なウェアラブル端末その他の家電を端末4として使用してもよく、ウェアラブル端末等によって情報を取得してもよい。したがって、第1機器2aや第2機器2bと端末4は同じものであってもよく、またそれぞれ専用機器であってもよい。ウエラブル端末と連携する端末4が、情報取得や情報の管理を行うようにしてもよい。さらに、状況に応じて、制御部1が有する機能を第1機器2aや第2機器2bや第3機器3や端末4が有してもよく、分担して検出や制御や情報提供を行うような構成にしてもよい。
【0086】
データベース(DB)部8は、電気的に書き換え可能な不揮発性メモリを有する。DB部8は、ID別データ履歴一覧を有し、この一覧は、個人ID毎に、医療情報、機器ID、検査データの取得日時毎の履歴データを記録する(図3参照)。前述したように、ID判定部1bは、第1機器2a等や診断・検査機関9等から、検査データを受信するので、DB部8は、個人ID別に検査データを記録する。この際、検査日、検査結果、症状、検査機器、取得データ、診断・検査機関9への来訪日等を記録する。
【0087】
また、DB部8が、各クリニック・病院など医療機関、検査機関が有する検査機器や検査キットの管理情報を収集し、一元管理できるようにしてもよい。どこにどのような機器があるかが分かれば、患者や医師などが、正確な情報をもとに判断し、行動することによって、余計な感染リスクや誤診の問題に対処することが出来る。このような設備管理をもとにしたアドバイスを患者や医師等に行えば、患者や医師等は検査・医療機関ごとの保有機器情報を記憶する記憶部(DB)のアクセスすることができる。情報提供部1cは、保有機器、設備情報を加味した有効情報を対象者に伝達することが出来る。つまり、対象者の検査データやプロフィール情報に加え、検査・医療機関ごとの保有機器情報に従った情報提供が可能となる。
【0088】
また、検査をどのように、また何のための検査か等についても記録する。DB部8は、取得したデータを、5W1H、すなわち、WHO(誰が)、WHERE(どこで)、WHEN(日時)、WHAT(どの検査)、WHY(何故)、HOW(どのように)に整理し、この整理されたデータを記録してもよい。また、検査場所(医療施設、検査機関、自宅、勤務先)等を記録してもよい。DB部8におけるデータの記録例については、図3を用いて後述する。
【0089】
学習依頼部6(図1B参照)は、制御部1内の推論依頼部1eから推論モデルの生成の依頼を受けると、学習部5に推論モデルの仕様等を伝え、仕様に沿った推論モデルの生成を依頼する。学習依頼部6は、データ分類記録部6a、仕様設定部6d、通信部6e、制御部6fを有する。
【0090】
制御部6fは、学習依頼部6内を制御するコントローラ(プロセッサ)であり、サーバ等や、ネットワークを通じて他の端末にファイルやデータなどを提供するCPU(Central Processor Unit)、メモリ、HDD(Hard Disc Drive)等から構成されているIT機器を想定している。しかし、制御部6fは、この構成に限らず、小規模なシステムとして構築する場合は、パーソナルコンピュータのようなものでも構成は可能である。制御部6fは、各種のインターフェース回路を有し、他の機器と連携することができ、プログラムによってさまざまな演算制御が可能である。
【0091】
データ分類部6aは、対象物種類A画像群6bを有し、この中に教師データ6cを記録している。対象物種類A画像群6bは、学習部5において推論モデルを生成する際に使用する画像群であり、種類A、種類B・・・と多数の画像群を有する。この画像群に基づいて教師データ6cを生成する。すなわち、図5に示すように、検査データを検査日毎にプロットするとグラフを描くことができ、このグラフを画像として扱うことができる。なお、ここでは画像として直感的にわかりやすく説明しているが、必ずしも画像として扱う必要はなく、時系列的な検査データの変化、すなわち検査日時と検査データを集めた複数の検査データ群を教師データとして生成するようにしてもよい。データ記録分類部6aには、DB部8に記録されたデータ履歴一覧に基づく、教師データ6cが記録される。
【0092】
仕様設定部6dは、推論モデル仕様決定部1dによって決定された推論モデルの仕様に基づいて、どのような推論モデルを生成するかを設定する。また、この仕様を満足するように、DB部8の履歴一覧に記録されているデータから教師データを生成する。
【0093】
通信部6eは、制御部1および学習部5と通信するための通信回路を有する。この通信部6eを通じて、制御部1から推論モデルの生成の依頼を受け、また学習部5に推論モデルの生成を依頼する。
【0094】
学習部5は、入出力モデル化部5aを有し、学習依頼部6からの仕様に従って、機械学習等によって推論モデルを生成する。入出力モデル化部5aは、仕様照合部5bを有する。この仕様照合部5bは、学習依頼部6から受信した仕様と、入出力モデル化部5aによって生成された推論モデルが合っているか否かを判断する。すなわち、仕様照合部5bは、入出力関係のみならず、この推論モデルの推論にかかる時間やエネルギーや回路構成など、「要求仕様」に沿った学習を行うよう、学習の仕方などを規定するものである。
【0095】
推論モデルは、取得した生体情報、生検情報など取得情報と疾患の関係を学習し、具体的には、取得情報と診療科・部門の関係を学習することによって生成する。入出力モデル化部5aは、推論エンジン7と同様に、入力層、複数の中間層、出力層を有し、中間層のニューロンの結合の強さを学習によって求め、推論モデルを生成する。
【0096】
このような推論モデルの生成にあたっては、学習依頼部6が検査機器を用いて被検者から取得した検査データの変化パターンを特定の時間幅で抽出し、この抽出した変化パターンを推論エンジン7に入力し、被検者が検査したタイミングから、後のタイミングにおいて出力されるべき健康アドバイスをアノテーション情報とした、教師データを生成する。そして、学習部5は、この教師データを用いて学習を行うことによって、推論モデルを生成する。
【0097】
また、学習部5は、検査、通院、服薬の後の検査データ列を用いて学習すれば、生活習慣改善や治療や服薬の効果の将来予想アドバイスを行うことが可能な推論モデルを生成することも出来る。この場合には、検査、通院、服薬の時点を起点として、その後の時系列データを利用する。検査、通院、服薬などをアドバイスする場合は、この前の時系列データを利用する。
【0098】
ここで、学習部5が行う学習の一例として、深層学習について、説明する。「深層学習(ディープ・ラーニング)」は、ニューラル・ネットワークを用いた「機械学習」の過程を多層構造化したものである。情報を前から後ろに送って判定を行う「順伝搬型ニューラル・ネットワーク」が代表的なものである。順伝搬型ニューラル・ネットワークは、最も単純なものでは、N1個のニューロンで構成される入力層、パラメータで与えられるN2個のニューロンで構成される中間層、判別するクラスの数に対応するN3個のニューロンで構成される出力層の3層があればよい。入力層と中間層、中間層と出力層の各ニューロンはそれぞれが結合加重で結ばれ、中間層と出力層はバイアス値が加えられることによって、論理ゲートを容易に形成できる。
【0099】
ニューラル・ネットワークは、簡単な判別を行うのであれば3層でもよいが、中間層を多数にすることによって、機械学習の過程において複数の特徴量の組み合わせ方を学習することも可能となる。近年では、9層~152層のものが、学習にかかる時間や判定精度、消費エネルギーの観点から実用的になっている。また、画像の特徴量を圧縮する、「畳み込み」と呼ばれる処理を行い、最小限の処理で動作し、パターン認識に強い「畳み込み型ニューラル・ネットワーク」を利用してもよい。また、より複雑な情報を扱え、順番や順序によって意味合いが変わる情報分析に対応して、情報を双方向に流れる「再帰型ニューラル・ネットワーク」(全結合リカレントニューラルネット)を利用してもよい。
【0100】
これらの技術を実現するために、CPUやFPGA(Field Programmable Gate Array)等の従来からある汎用的な演算処理回路を使用してもよい。しかし、これに限らず、ニューラル・ネットワークの処理の多くが行列の掛け算であることから、行列計算に特化したGPU(Graphic Processing Unit)やTensor Processing Unit(TPU)と呼ばれるプロセッサを利用してもよい。近年ではこのような人工知能(AI)専用ハードの「ニューラル・ネットワーク・プロセッシング・ユニット(NPU)」がCPU等その他の回路とともに集積して組み込み可能に設計され、処理回路の一部になっている場合もある。
【0101】
その他、機械学習の方法としては、例えば、サポートベクトルマシン、サポートベクトル回帰という手法もある。ここでの学習は、識別器の重み、フィルター係数、オフセットを算出するものあり、これ以外にも、ロジスティック回帰処理を利用する手法もある。機械に何かを判定させる場合、人間が機械に判定の仕方を教える必要がある。本実施形態においては、画像の判定を、機械学習によって導出する手法を採用したが、そのほか、人間が経験則・ヒューリスティクスによって獲得したルールを適応するルールベースの手法を用いてもよい。
【0102】
推論エンジン7は、学習部5の入出力モデル化部5aと同様の入出力層、ニューラル・ネットワークを有している。推論エンジン7は、学習部5によって生成された推論モデルを用いて、推論を行う。例えば、推論エンジン7は、第1機器2a等によって測定され、時系列的な生体情報を入力し、例えば、ユーザの健康状態を検査、治療等を行うに適切な検査機関・医療機関を推論によって求める。また、時系列的な生体情報に基づいて、いつ頃、医療機関で受診を受けることになるかの推論等を行ってもよい。
【0103】
このように、制御部1は、検索部1fがDB部8を検索する以外にも、推論エンジン7を利用して、ユーザの疾病に関する情報を提供しても良い。推論エンジン7は、学習部5が生成した推論モデルを用いて、疾病に関する推論を行う。この推論モデルは、取得した生体情報、生検情報など取得情報と疾患の関係を学習することによって生成する。このように、制御部1は、推論エンジン7による推論によっても、提示すべきガイド情報を出力してもよい。
【0104】
制御部1が検索によって、または推論によって、一度に得られた取得情報に基づいて、一回の判定で疾病などをガイドすると、いたずらに生活に医療情報を持ち込んで、健全に安心して生活するのを妨げる可能性がある。そこで、複数回の取得情報の履歴(時系列的情報)を用いて、精度アップしてもよい。
【0105】
次に、図2を用いて、学習用教師データとして使用可能なデータファイルDFのファイル構造について説明する。図2(a)は、第1の学習用教師データとして使用可能なデータファイルDF3のファイル構造を示す。このデータファイルDF3は、異なる日時に検査機器によって取得された取得データRD3a、RD3b、RD3cと、これらのデータのメタデータMD3を有する。取得データとしては、図2(a)には3つしか記載されていないが、この数は検査の回数が増えれば、それに応じて増加する。また、メタデータMD3としては、検査に使用された機器の情報、診察結果、検査を受けたユーザを識別するID等が記録される。このメタデータにアノテーションを付与した人の分類や専門家の関与の仕方、アノテーションした個人や組織を特定するIDなどを記載できるようにしてもよい。
【0106】
図2(b)は、データファイルをフォルダ形式によってまとめている場合を示す。図2(b)に示す例では、患者Aの診察結果をフォルダにまとめている。このフォルダには、患者Aを特定するための識別用データIDa4、診察結果を記録するためのデータMDRe4が記録されている。また、個々の取得データについては、データファイルDF4a、DF4b、DF4cに記録されている。ここのデータファイルの形式は、図1Aに示したデータファイルDF1と略同じであるので、詳しい説明は省略する。なお、このデータファイルDF4a等は、図2(b)には3つしか記載されていないが、この数は検査の回数が増えれば、それに応じて増加する。
【0107】
次に、図3を用いて、DB部8に記録される履歴データ等について説明する。この履歴データは、ユーザの一人一人を識別するための個人ID毎に作成される。履歴データは、ID毎に、検査結果、症状、機器ID、取得データを記録する。検査結果としては、検査日付けと診察結果に基づいて疾病に関する情報が記録される。症状としては、症状名が記載され、症状毎に検査機器IDと、その検査機器を用いて取得された取得データが日付け毎に記録される。さらに、医院等の診断・検査機関9で受診した日が記録される。
【0108】
図3に示す履歴データの例では、ID1のユーザは、症状Xについて検査可能な機器aを用いて日時t1、t3、t5、t7において検査データDa(t1)、Da(t3)、Da(t5)、Da(t7)を取得している。またID1のユーザは、症状Yについて検査可能な機器bを用いて日時t2、t4において検査データDb1(t2)、Db1(t4)を取得している。ID1は、日時t5において、来院し受診したところ、医師は疾病A1に罹患していると判断している。
【0109】
また、ID2のユーザは、症状Yについて検査可能な機器aを用いて日時t2、t4において検査データDa2(t2)、Da2(t4)を取得している。そして、ID2は日時t5において、来院し受診したところ、医師は疾病B2に罹患していると判断している。
【0110】
また、日時t5において、ID1、ID2が来院した際に、医師が両者の履歴データを用いて、学習を依頼している。すなわち、ID1は疾病A1を罹患している例として、またID2は疾病A1を罹患していない例として、時系列的な検査データがあり、更に、同様の機器で検査した時系列データを学習用の教師データとして、学習部5に推論モデルの生成を依頼している。
【0111】
また、ID3やID4についても、同様に、機器a、機器cによってデータが取得され、DB部8に記録される。両者は、日時t8に来院し、受診している。ID3については機器aによるデータがあり、症状Xがある。一方ID4については、機器cについてしかデータがないが、症状Xがある。前述したように、日時t5において医師は学習を依頼し、推論モデルを取得している。この推論モデルに、ID3の時系列的な検査データと、ID4の時系列的な検査データを入力することによって、疾病A1であるか否かを推論することができる。医師はこの推論結果を参考にして、疾病A1であるか否かの診断を行うことができる。
【0112】
次に、図4を用いて、医師端末9eの表示部9fにおける表示について説明する。なお、図4に示す例は、図3に示した履歴データを有するID1、ID2等が受診した場合である。
【0113】
図4(a)は、A1病で来院した患者の一覧表を示す。医師は、疾病の判断をする際に、疑われる疾病を罹患している患者が使用している検査機器や履歴データを確認したいと思う場合がある(例えば、図9AのS11、S15参照)。図4(a)は、同一の疾病で来院した患者毎に、来院日時と、その患者が使用している機器の一覧表を示す。図4(a)の例では、患者ID1、ID3、ID5は機器aによって検査した履歴データがあり、患者ID4は機器cによって検査した履歴データが有ることを示している。
【0114】
図4(a)における表示は、診断・検査機関9の制御部9bが、DB部9aに記録されているデータの中から該当のデータを検索し、表示制御部9cが検索結果を医師端末9eに表示できるように、データを送信する。すなわち、表示制御部9cは、特定の疾病(A1病)と判定された複数の対象物(対象者)と、複数の時点における特定情報の経時変化とを取得可能な機器を一覧表示可能な表示制御部として機能する。なお、制御部9bがデータの検索を行う以外にも、制御部1がDB部8に記録されているデータを検索してもよい。後述する図4(b)の場合も同様である。
【0115】
図4(b)は、A1病で来院した患者の時系列情報を示す。医師は、図4(a)に示すように、A1病で来院した患者の一覧表に続いて、彼らの検査および来院した日時情報を確認したいと思う場合がある。図4(b)は、同一の疾病で来院した患者の検査日時および来院日時を示す一覧表である。
【0116】
図4(b)に示す表示は、診断・検査機関9の制御部9bが、DB部9aに記録されているデータの中から該当のデータを検索し、表示制御部9cが検索結果を医師端末9eに表示できるように、データを送信する。すなわち、表示制御部9cは、特定の疾病(A1病)と判定された複数の時点における特定情報の経時変化を一覧表示可能な表示制御として機能する。
【0117】
次に、図5を用いて、来院した患者のデータ表示について説明する(例えば、図9AのS15、S17参照)。図4に示したように、医師端末9eの表示部9fには、A1病で来院した患者のリスト(所有機器、来院日時情報付き)が表示される。医院に来院した患者がいる場合に、これらの患者の検査データについて、医師が端末で時系列的変化を見ることができれば便利である。そこで、本実施形態においては、医師端末9eのメニュー画面等(図6参照)において、グラフ表示を選択すると、図5に示すようなグラフが表示される。
【0118】
図5(a)は、日時t9までの間に、A1病と診察された患者の検査データDを示す。図5(a)のグラフにおいて、横軸は来院日時を示し、縦軸は検査データDを示す。グラフ中の丸印は患者ID1、ID3、ID5の検査データDを示す。図5(a)の右側には、「診察あり」「診察なし」「両方」のアイコンが表示されている。図5(a)は、A1病と診断された患者の履歴データを示しているので、「診察あり」のアイコンが白黒反転表示されている。
【0119】
図5(a)の表示状態において、「診察なし」のアイコンがタッチされると、図5(b)に示すように、「診察なし」のアイコンが白黒反転し、「A1病で来院していない人」のグラフが表示される。図5(b)においても、横軸は来院日時を示し、縦軸は検査データDを示す。グラフ中の丸印は患者ID2、ID4、ID6の検査データDを示す。ID2、ID4、ID6は、来院したが、A1病とは診断されていない人である。この状態で、「両方」のアイコンがタッチされると、A1病と診断された者と診断されなかった者の両方の履歴データがグラフ表示される。
【0120】
図5(a)、(b)のような表示によって、目視で、この症例の時系列変化が確認でき、また他の情報も合わせて表示することによって、医師が診断、治療を行う時の参考になる可能性も高い。この表示は、データ収集とグラフ化だけで達成でき、教師データを作成するまでもなく、あるいは推論を待つまでもなく、何らかの知見が得られる場合がある。医師が特定の患者の病状に関する情報を入力する入力部と、上記患者の過去の時系列データを取得可能な機器を特定する機器特定部と、上記特定された機器と同様の機器を有する別の人の機器による収集データを収集するデータ収集部を有するデータ収集装置は、上述したように、医師が診断、治療する際に参考になる情報を収集することができる。また、この収集結果を表示して、医師が気づきを得れば、多くの人の健康維持情報に役立つ。
【0121】
さらに、診察情報を教師データ化して学習を依頼する学習依頼部を有する教師データ収集装置は、より客観的な情報を得ることが出来る。この教師データ収集装置によって収集した教師データを使用することによって、信頼性の高い推論モデルを作成すれば、医師の気づきや知見を共用することが可能となり、世界中で診療方法が共通化でき、医師の経験に依存しない高度な健康回復策、健康維持策を提示することが可能になる。ただし、全ての雑多な情報を教師データとして使用すると、信頼性の高い推論モデルを得ることは出来ないので、データの要不要を取捨選択できるようにしておいた方が良い。
【0122】
収集したデータの時間軸をみれば、例えば、感染症などの場合、どのあたりで流行が始まったかなどの判定が出来る。特定の日に発熱した人が多い場合、その日に海外などから感染症が広がった等を確認、判断する際の目安となる。また、来院時を基準にした時間軸表示で、その疾病特有の症例(病状)変化を、患者の自覚や患者を見た他の人の勧めで来院が必要と判断したタイミングをもとにして、来院に至る過程などが確認しやすくなる。
【0123】
また、特定のデータ変化の時点(例えば、熱が上がったタイミングなど)を基準にした時間軸で収集データを表示すれば、その疾病特有の病状の変化が分かり、診断に役立つ基礎データとなる。当然、機器が携帯端末であれば、その人の行動履歴やインターネットアクセスなどの履歴も情報として(クラウド上の情報も含めシステムとして)記録されているので、行動履歴をさらに解析しての病状の変化の傾向を捉えて、病気の進行を押さえたり、健康を改善するための情報にしたりすることが出来る。
【0124】
図5における表示は、診断・検査機関9の制御部9bが、DB部9aに記録されているデータの中から該当のデータを検索し、表示制御部9cが医師端末9eに検索結果を表示できるように、データを送信する。すなわち、表示制御部9cは、特定の疾病(A1病)と判定された複数の時点における特定情報の経時変化を一覧表示可能な表示制御部として機能する。
【0125】
図5(a)に示す履歴データは、いずれもA1病と診断された者のデータであることから、これらの者のデータに対して、「A1病の疾患あり」のアノテーションを付した教師データを作成することができる。また、図5(b)に示す履歴データは、いずれもA1病と診断されなかった者のデータであることから、これらの者のデータに対して、「A1病の疾患なし」のアノテーションを付した教師データを作成することができる(例えば、図9AのS15、S17参照)。この学習用の教師データのファイル形式は、データファイルDF1、DF2、DF3、DF4等、適宜選択すればよい。
【0126】
教師データが作成できれば、医師端末9eは、制御部1の推論依頼部1e、および学習依頼部6を通じて、学習部5にA1病に適した推論モデルの生成を依頼できる(例えば、図9AのS23参照)。なお、診断・検査機関9から直接、学習依頼部6、学習部5に依頼するようにしてもよい。
【0127】
次に、図6を用いて、医師端末9eにおけるメニュー画面について説明する。医師端末9e起動すると、端末メニューが表示される。端末メニューにおいて、分析アプリを起動すると、図6(a)に示される「分析アプリ」の画面が表示される(図9AのS7参照)。この分析アプリの画面には、「診断結果選択」「テーブル表示」「グラフ表示」教師データ表示」「学習依頼」「学習結果性能確認」推論データ取得」「推論依頼」「推論結果表示」「戻る」「MENU」のアイコンが表示される。
【0128】
分析アプリの画面において、「診断結果選択」が選択されると(例えば、図9AのS11参照)、疾病のリストが表示され、その中から、疾病の名称を選択することができる。例えば、A1病を選択すると、図4(a)に示すような来院した患者の一覧表が表示される。診断結果を選択した状態で、「テーブル表示」を選択すると(例えば、図9AのS15参照)、図4(b)に示すような時系列情報がテーブル表示される。
【0129】
また、図6(a)のメニュー画面において、「グラフ表示」が選択されると(例えば、図9AのS15参照)、図5に示すような履歴データがグラフ表示される。図5のグラフ表示の際に、右上の「MENU」がタッチされると、図6(b)に示すようなアイコンが表示される。この表示状態で、「手動修正」がタッチされると、データの修正が可能になる。「データ選択」によって特定のデータを選択し、「データ削除」をタッチすると、そのデータが削除される。
【0130】
図5(a)のA1病で来院した患者が選択された状態で、「一括アノテーション」がタッチされると、「A1病の疾患あり」のアノテーションを付した教師データが、一括で生成される。また、「追加アノテーション」がタッチされると、教師データに付するアノテーションを追加することができる。A1病で来院した患者に共通してみられる症状等を一括してアノテーションとして付加することができる。図6(b)に示す例では、「発熱と発疹」がアノテーションとして追加されている。このアノテーションは、医師端末9eの操作部9gを操作し、テキスト入力すればよい。
【0131】
図6(a)に戻り、「教師データ表示」がタッチされると(例えば、図9AのS15参照)、医師が図5等においてデータを選択し、教師データとしたデータが表示される。「学習依頼」がタッチされると(例えば、図9BのS21参照)、医師端末9eは、「教師データ表示」で表示された教師データを用いて、推論モデルの生成を学習部5に依頼する。「学習結果性能確認」がタッチされると(例えば、図9BのS21参照)、学習を依頼した際に、学習部5が生成した推論モデルの性能、例えば、信頼性を評価する。この評価は、例えば、評価用のデータを用意しておき、この評価用データを推論モデルに入力し、その出力結果に基づいて行う。学習結果性能確認を行った結果、満足する結果が得られれば、推論モデルを取得する。
【0132】
図6(a)において、「推論データ取得」をタッチすると(例えば、図9BのS25参照)、推論モデルに入力する推論データを取得する。例えば、図3の例において、日時t9のタイミングで、ID3およびID4が来院した際に、医師はID3およびID4のそれまでの履歴データを、推論モデルに入力し、疾病について推論を行う場合がある。推論データは、このように、診察対象となった患者の過去の履歴データである。
【0133】
図6(a)において、「推論依頼」をタッチすると(例えば、図9BのS25参照)、取得した推論データを、推論モデルに入力し、推論結果を出力するように依頼する。推論の依頼先は診断・検査機関9が推論エンジンを有していれば、診断・検査機関9とする。診断・検査機関9が推論エンジンを有していない場合には、制御部1に依頼してもよい。もちろん、医師端末9eが推論エンジンを有してれば、医師端末9e内で推論を行ってもよい。この推論依頼の詳細画面については、図7を用いて後述する。「推論結果表示」をタッチすると、推論結果が表示される。
【0134】
次に、図7を用いて、推論依頼の画面について説明する。医師は、患者の過去の履歴データから、今後の症状の変化について推論モデルを用いて推論結果を得ることが望む場合がある(例えば、図9BのS25参照)。この場合には、図6(a)の画面において、医師は「推論依頼」をタッチする。タッチすると、図7(a)に示すように、まず、患者データ選択の画面が表示される。図7(a)に示される例では、「Gさん」等、患者名が表示される。
【0135】
図7(a)において、患者名をタッチによって選択すると、図7(b)に示すように、選択された患者の履歴データがグラフ表示される。このグラフ表示によって、医師は患者の過去のデータについて知ることができ、更に、将来の予測を行いたい場合には、下部の「推論」をタッチする。タッチすると、推論が行われ、推論結果が画面内に表示される。図7(b)に示す例では、A1病に罹患する確率が「7割」あり、注意が必要と表示される。医師は、この推論結果を参考にして、診断結果を出すことができる。
【0136】
次に、図8を用いて、診断入力を行う画面について説明する。端末メニュー画面から診断入力を行う画面を開き(例えば、図9AのS1、S3、S5参照))、患者名を選択すると、図8の診断入力用の画面が表示される。この診断入力用画面において、医師が特定の患者の病状に入力する。図8の例では、患者名として「Gさん」が選択されている。この画面には、既にデータ入力されていれば、Gさんの診察券No.と日時が表示される。また、初診、症状、診断結果、所有機器について、データが入力されていれば表示され、未入力であって記入できる項目については医師が医師端末9eにおいて入力する。また、患者の個人情報を利用することについて、患者から同意を得られる場合には、画面下部のチェック欄をチェックしてもらう。図8においては、同意が得られたので、チェックマークが付されている。
【0137】
次に、図9Aおよび図9Bに示すフローチャートを用いて、医師端末9eにおける制御部9hの動作について説明する。このフローは、医師端末9e内の制御部9hが、診断・検査機関9内の制御部9bと協働し、診断・検査機関9および医師端末9e内の各部を制御することによって実現する。
【0138】
医師端末9eの電源がオンとなり、図9Aに示すフローが開始すると、まず、端末メニューが表示される(S1)。ここでは、制御部9hは、表示部9fにメニュー画面を表示する。メニュー表示としては、「診断結果入力」「分析アプリ起動」や、その他の機能等、操作可能な項目をアイコンで表示する。
【0139】
メニュー表示を行うと、次に、判定結果を入力するか否かを判定する(S3)。ここでは、制御部9hが、メニュー画面における「診断結果入力」がタッチ操作されたか否かに基づいて判定する。
【0140】
ステップS3における判定の結果、判定結果を入力する場合には、入力を行う(S5)。ここでは、制御部9hは、図8に示す診断結果の入力画面を表示部9fに表示する。前述したように、診断結果の入力画面では、医師は患者の診断結果等を、操作部9g等によって入力することができる。すなわち、このステップにおいて、医師が特定の患者の病状に入力する。その他、診察時の検査データ結果等の入力も行う。
【0141】
ステップS5において入力を行うと、またはステップS3における判定の結果、診断結果の入力でない場合には、次に、分析アプリ起動か否かを判定する(S7)。ここでは、制御部9hは、メニュー画面における「分析アプリ」がタッチ操作されたか否かに基づいて判定する。
【0142】
ステップS7における判定の結果、分析アプリの起動でない場合には、その他の機能を実行する(S9)。ここでは、制御部9hが、他の機能、例えば、機器の貸し出し、機器の登録、患者等の同意署名、通常のカルテ記入・確認等を行う。その他機能を実行すると、ステップS1に戻る。
【0143】
ステップS7における判定の結果、分析アプリの起動であった場合には、診断結果一覧確認か否かを判定する(S11)。ここでは、制御部9hが、まず、図6(a)に示す分析アプリのメニュー画面を表示部9fに表示する。メニュー画面には、前述したように種々の項目に対応したアイコンが表示されるので、このステップでは、制御部9hは、「診断結果選択」のアイコンが選択されたか否かを判定する。
【0144】
ステップS11における判定の結果、診断結果一覧確認が選択された場合には、診断結果に従った患者と機器を表示、機器選択を行う(S13)。ここでは、制御部9hは、図4(a)に示したような特定疾病で来院した患者の一覧表を示す。この一覧表には、患者が所有し、または使用可能な検査機器を表示する。医師は、表示された検査機器を選択することができる。例えば、図4(a)において、A1病のために来院した患者の多くが機器aを所有(または使用可能)な場合には、機器aを選択することができる。
【0145】
ステップS13において機器の選択を行うと、またはステップS11における判定の結果、診断結果一覧確認を選択しない場合には、次に、テーブル表示、グラフ、教師データを表示するか否かを判定する(S15)。ここでは、制御部9hは、図6(a)に示した「テーブル表示」「グラフ表示」「教師データ表示」のいずれかが選択されたか否かを判定する。
【0146】
ステップS15における判定の結果、テーブル表示等のいずれかが選択された場合には、選択機器に対応する患者別データ表示、確認、取捨選択を可能にする(S17)。ここでは、制御部9hは、図4(b)に示した、特定疾病で来院した人の時系列情報、図5に示した特定疾病で来院した人の履歴データ、特定疾病で来院していない人の履歴データを、表示部9fに表示する。例えば、図4(a)に示したように、特定疾病(A1病)のために来院した患者が、所有また使用可能な特定機器によって検査されたデータを多数収集することができる(図5(a)参照)。このデータは、特定疾病の患者の判定用の教師データとして使用することができる。また、特定疾病のために来院していない患者であって、特定機器によって検査されたデータも多数収集することができる。このデータは、特定疾病の患者ではないと判定するための判定用の教師データとして使用することができる。このデータを用いて学習の結果得られる推論モデルの入出力関係は、同様の機器によって収集した収集データが入力となり、医師によって入力された患者の病状に対応する情報が出力となるようにする。このような推論モデルの入出力関係が得られるように、データを収集する。
【0147】
また、ステップS15においては、表示部9fのメニュー画面上の「教師データ」を選択することによって、学習の依頼に使用する教師データを確認することができる。また、履歴データ(教師データ)を表示した際に、MENUがタッチされた際には、データの選択、データ削除等の取捨選択を行うことができる(例えば、図6(b)参照)。このように、これらのアイコンを利用することによって、特定疾病の判定用の推論モデルを生成するための、教師データを作成することができる。
【0148】
ステップS17における処理を実行すると、またはステップS15における判定の結果、テーブル表示等を行わない場合には、次に、学習依頼を行うか、または学習結果を確認するか否かを判定する(S21)。ここでは、制御部9hは、図6(a)に示した「学習依頼」「学習結果性能確認」のいずれかが選択されたか否かを判定する。
【0149】
ステップS21における判定の結果、学習依頼、または学習結果確認の場合には、選択済みの教師データで学習を依頼し、または結果を取得する(S23)。ここでは、ステップS17において、選定した教師データを用いて、推論モデルを生成するように、学習部5に依頼することができる。推論依頼は、例えば、図7(b)に示すような「推論」のアイコンを選択することによって、実行される。
【0150】
また、ステップS23において、学習部5に学習を依頼し、推論モデルが生成された場合には、その推論モデルの性能・信頼性等の結果を取得し、表示する。推論モデルの性能、信頼性は、例えば、LOSS値等を算出し、このLOSS値に基づいて行う。LOSS値は、予め評価用に用意したデータを推論モデルに入力し、このときの推論結果が予め用意したデータの結果と、どの位の割合で一致するかを示す値である。この性能・信頼性の評価は、推論エンジンを有する機器において行う。評価の結果、性能・信頼性が所定のレベル以下の場合には、教師データを作り直し、また機器選択をやり直す等を行って、再度、学習部5によって推論モデルを作成し直す。
【0151】
ステップS23において、信頼性の高い推論モデルが生成された確認できた場合には、特定のサーバ等において推論モデルを利用可能とし、多くの医療機関で使用可能にしたり、一般ユーザが自分の状態を確認したりするのを利用可能にする。これによって、救急車の手配を適切にすることができ、また医療機関での受診などを減らし、医療現場の多忙さを解消できるようになる。通院過程や通院先で、感染したり感染させたりすることを防止できる。また、この推論モデルにIDを設け、どの推論モデルで判定したかが分かるようにしても良い。無数の類似モデルが出回ると品質の悪いものが、過度な不安を蔓延させることもあれば、緊急の患者を手遅れにしてしまう可能性がある。このように、IDによってAIを特定することが望ましく、またAIの立証性にも役立つ。
【0152】
また、医師の気づきと教師データ取捨選択で生成された推論モデル(AI)の場合、誰が作成したかを明確にしておくことが望ましい。作成者を明確にすることによって、AIを苦労して作った時の成果が、その医師の努力によるものと広く認められ、その努力に報いる手立てなどを講じることが出来る。また、安易に悪質なAIが出回ることを防止することも可能となる。このようなAIは、どのようなデータを必要とするかが決まっているので、そのAIに適したデータには、その条件を明確にできる工夫を行ってもよい。つまり、そのAI向けのデータを取得する際には、そのAIを指定してデータ取得開始といったアプリを機器が実装し、図2(a)のような取得データのデータファイルのメタデータとして、想定AI情報(IDなど)を付記できるようにすれば良い。
【0153】
ステップS23において推論モデルの結果を取得すると、またはステップS21における判定の結果、学習依頼・学習結果確認でない場合には、次に、推論データを取得し、推論を依頼し、推論結果を取得したかを判定する(S25)。前述したように、医師が患者を診察した際に、この患者の履歴データを推論モデルに入力し、疾病に関する推論結果を得たい場合がある。このステップでは、推論モデルを用いた推論を行う。このステップでは、制御部9hは、図6(a)に示した「推論データ取得」「推論依頼」「推論結果表示」のいずれかが選択されたか否かを判定する。
【0154】
ステップS25における判定の結果、推論データ取得等であった場合には、次に、推論モデルのダウンロードと依頼、結果取得を行う(S27)。ここでは、制御部9hは、学習部5に対して、ステップS23において所定の性能・信頼性を満たした推論モデルのダウンロードを依頼する。また、推論したい患者の履歴データを取得し、この履歴データをダウンロードした推論モデルに入力し、推論結果を取得する。取得した推論結果は、表示部9fに表示する(例えば、図7(b)参照)。
【0155】
ステップS27において、推論結果を取得すると、次に、戻るか否かを判定する(S29)。ここでは、制御部9hは、メニュー画面上の「戻る」(図6図7(a)、図8参照)が選択されたか否かに基づいて判定する。この判定の結果、戻るが選択されていない場合には、ステップS11に戻り、一方、戻るが選択された場合には、ステップS1に戻る。
【0156】
このように、医師端末9eにおける制御部の動作によれば、医師が患者の病状に関する情報を入力し(S5)、患者の時系列データを取得可能な機器を特定し(S13)、特定された機器と同様の機器を有する他の人の時系列データと診察情報を、教師データ化して学習を依頼している(S27)。このため、新しい症状に遭遇した場合であっても、同様の機器による他の人の検査データと、その他の人の診察情報を用いて、推論モデルを生成することができる。この推論モデルを使用すれば、新しい症状に遭遇した場合でも、的確な診察をする際の参考情報として使用することができる。また、このデータはどの人のどの時刻におけるデータであるかが分かれば、時系列でなくとも良い。例えば、発熱などは、突発的な場合があり、時系列のデータを解析せずに使える教師データとなり得る。
【0157】
また、推論モデルが生成された後であって、医師が患者を診察した際に、患者の履歴データに基づいて、疾病に関する推論を行いたい場合には(S25Yes)、患者の履歴データを推論モデルに入力し、推論結果を得るようにしている(S27)。医師はこの推論結果を参照して、患者の病状を診断することができる
【0158】
このように、健康関連データから、どのような診察結果、診断結果になりうるかの推論モデルが作られ、使いたい人や使いたいサービス、システム等が、適宜、使えるようにすれば、第1~第3機器(図1A参照)から、日常的に得られるデータを、この推論モデルの入力にすることによって、多くの診断支援や健康管理に利用可能となる。これは、IT技術の進展によって、IoT化の流れから、様々な機器がインターネットにつながるようになったので、世の中に様々な見守り機器(例えば、図1Aの第1~第3機器等)から、多くの人たちの健康関連情報が取得できるようになった事、多くの人が情報端末を使って、有用な情報にアクセスしやすくなった事等を、背景として可能になったものである。
【0159】
これらの技術によって、上述の見守り機器(例えば、図1Aの第1~第3機器等)を、個々人の健康意識を後押ししたり、通院の必要性を確認したりするためのツールにすることが可能となる。患者が病気を押してわざわざ診察を求め、医師が様々な検査情報や問診などによって、時間をかけて得られた貴重な診断結果であるから、上述のプロセスを経て作成された推論モデルを、他の医師が診断の際に参照すれば、昨今の医師不足の問題や感染症の問題に対処することもできる。
【0160】
なお、ステップS11ないしS29における処理は、制御部9hが医師と連携して行うようにしているが、コンピュータが特定のプログラムをルーチンベースで行うようにしても勿論かまわない。すなわち、医師が医師端末9eのメニュー画面(図6(a)参照)においてアイコンを選択しなくても、自動的に各ステップを順次実行するようにしてもよい。
【0161】
次に、図10Aおよび図10Bのフローチャートを用いて、制御部の動作の他の例を説明する。前述の制御部の動作の一例は、医師端末9eの制御部9hにおける動作であった。すなわち、制御部動作の一例では、医師端末9eの制御部9hが主体的に表示等の動作を実行していた。これに対して、制御部の動作の他の例では、サーバ側の制御部1が、医師端末9eおよび診断・検査機関9からの依頼を受け、表示等の動作を実行する。すなわち、クラウドによって、医師端末9eにおける表示等の動作を実行する。なお、クラウドとしての機能は、制御部1以外にも、診断・検査機関9の制御部9bが実行してもよい。
【0162】
図10Aに示すフローが開始すると、まず、各機器からデータを収集し、データベース(DB)化する(S31)。ここでは、制御部1が第1機器2a、第2機器2b、第3機器3等の検査機器から、検査データを収集し、DB部8に記録する。
【0163】
ステップS31において、データの収集を開始しているが、データ収集開始のタイミングは、医師の指示でもよく、また各ユーザ自身(患者や患者候補、あるいは機器利用者)、あるいは各ユーザが使用しているの機器自体が異変に気付いて、データ収集を自動的に開始してもよい。また、機器導入時、購入時、あるいは特定のサービス契約時に機器がこうしたデータ蓄積を開始してもよい。機器が自動的にデータ収集を行う場合には、データ入力部によって入力したデータが想定外のデータの際には、想定外のデータであることを指定し、この指定したデータを収集する対応判定部を有するようにすればよい。この対応判定部を有するシステムであれば、医師が介在できないような状況下でも、異常の原因を推論可能なシステムにすることができる。
【0164】
制御部1が収集したデータ、あるいは時系列データ群は、後述するステップS61において、推論依頼部1eおよび学習依頼部6を通じて学習部5に送信され、推論モデルの生成が依頼される。この推論モデルは、制御部1が有していてもよく、あるいは各機器(例えば、第1~第3機器等)が有しててもよい。推論モデルに、ユーザの健康関連データ・見守りデータを入力するによって、健康状態の推論が可能となり、その結果から、各ユーザは自分の健康状態を把握することができる。
【0165】
推論モデルには、医師の診断結果が反映されるので、信頼性、確度の高い推論が可能となる。必要に応じて、どの医師が作った推論モデルか、どのような仕様のものかをユーザ端末に推論結果と合わせて表示してもよい。多くの医師が同様の気づきがあり、医師の社会貢献意識があることから、独自の工夫を加えたりしながら、またどのデータを使うべきか等の情報を加たりしながら、同様の推論モデルを作る可能性がある。推論モデルが入力(見守り)データの特徴から自動で選択されてもよく、人気モデルをユーザが選択したり、評価をインターネット上に公表したりできるようにしてもよい。
【0166】
また、収集された想定外のデータを教師データとして、推論システムに対応する推論モデルの学習要求を行う推論依頼部を有するシステムとしてもよい。このシステムは、ユーザの実際の異常や機器の何らかのトラブルも含め、同様の事象が起こっている他の機器の、あるいは類似の状況の他の機器のデータをビッグデータとして扱い、その状況がどのような状況であるか(例えば、よくあることなのか、集団で起こっていることなのか、単発の偶然なのか)を判断するための情報を収集することが可能となる。その人にとって未知の事象は不安ばかりが募るが、不安を緩和する情報を集めることも可能であり、また緊急である場合に、収集された類似のデータから確認、判断することもできる。例えば、未知の感染症が突発した場合、その感染が起こった場所の情報なども特定でき、その場所に行った事があるか否かによって、その後の行動を変えることが出来る。
【0167】
データを収集して、DB化すると、次に、医師が特定疾患(A)を指定したか否かを判定する(S33)。医師が患者を診察し、特定疾患(A)と診断すると、その旨を記録したデータファイルDF2が診断・検査機関9から制御部1に送信される。このステップでは、制御部1がデータファイルDF2に記録されている情報に基づいて判定する。医師が診断・診察を行うたびに、データファイルを制御部1に送信し、教師データ化しても良い。しかしこれに限らず、医師がこれはと思う疾患を指定してもよい。この指定疾患としては、慢性的なもので生活習慣などの影響があり、他の患者予備軍の参考になる場合や、遺伝性、あるいは特定の体質や病歴があり、同様の来歴を有する特定疾患の患者予備軍として参考になる場合や、あるいは感染性で、多くの人に影響があり急を要する場合がある。
【0168】
ステップS33における判定の結果、医師が特定疾患(A)と指定したと判定した場合には、DBの中でA患者を検索する(S51)。ここでは、制御部1(検索部1f)が、DB部8の中から疾病Aに罹患した患者を検索する(図3参照)。
【0169】
次に、疾病Aの患者が生活習慣機器を保有しているか否かを判定する(S53)。前述したように、DB部8には、個人ID、疾病名、所有機器(使用可能機器)が記録されている(図3参照)。ここでは、制御部1は、疾病Aの患者が所有(使用)している機器があるか否かを判定する。
【0170】
ステップS53における判定の結果、機器を保有している場合には、A患者と保有機器を表示する(S53)。ここでは、制御部1は、DB部8から検索された結果、すなわち、疾病Aの患者が保有している機器の種類を、診断・検査機関9を通じて、医師端末9eの表示部9fに表示する(例えば、図4(a)参照)。
【0171】
ステップS55において保有機器の表示を行うと、またはステップS53における判定の結果、機器を保有していない場合には、次に、医師が機器aを選択か否かを判定する(S57)。ステップS55において、機器が表示された際に、医師が機器を選択すると、選択結果が、診断・検査機関9を通じて制御部1に送信される。ここでは、医師端末9eからの情報に基づいて、医師が機器aを選択したか否かを判定する。医師がその経験、知識などによる判断によって、意味のある関連ありそうなデータを取得可能な機器を選択するので、本フローでは、医師の選択結果を判定している。しかし、これに限らず、この工程を自動化して、あらゆる情報、あるいは特定のロジック、プログラムによって、機器を選択するようにしてもよい。
【0172】
ステップS57における判定の結果、医師が機器aを選択した場合には、次に、選択機器aの過去情報を取得し、また医師端末に表示確認を行ってもよい(S59)。ここでは、制御部1は、DB部8に記録されている機器aによる過去の検査データを取得する。この取得した検査データを、医師端末9eに送信し、表示部9fに表示してもよい。この場合には、医師は機器aによって取得された、他の人の検査データを確認することができる。
【0173】
続いて、教師データ化し、学習を依頼し、推論モデルを取得する(S61)。ここでは、制御部1は、ステップS59において取得した、機器aによって取得された検査データを教師データとし(たとえば、図5参照)、この教師データを用いて推論モデルを生成するように、学習依頼部6を通じて、学習部5に依頼する。ここでの推論モデルを用いた推論は、特定の検体情報、生体情報を入力し多彩に、診断補助情報を推論結果として取得する。また、学習部5が推論モデルを生成すると、学習依頼部6を通じて、推論モデルを取得する。
【0174】
ステップS61において推論モデルを取得すると、またはステップS57における判定の結果、医師が機器aを選択していない場合には、次に、検索終了か否かを判定する(S63)。ここでは、制御部1は、医師がステップS51における検索を終了したか否かを判定する。この判定の結果、検索が終了していない場合には、ステップS53に戻る。一方、検索を終了した場合には、ステップS31に戻る。
【0175】
ステップS33に戻り、このステップにおける判定の結果、医師が特定疾患(A)と指定していないと判定した場合には、次に、推論モデルに入力する対応データがあるか否かを判定する(S35)。ここでは、制御部1は、推論モデルを用いて推論を行う必要のある対応データがあるか否かを判定する。例えば、医師端末9eから検査データと共に推論の依頼を受けているか否かに基づいて判定してもよい。この判定の結果、対応データがない場合には、ステップS31に戻る。
【0176】
また、生活習慣や遺伝性、感染性の疾患に関するデータである場合、家族などにも同様の疾患が起こりうるので、推論するデータとして、対象者の家族のデータを入力し、個人ではなく、その家庭に対する健康アドバイスを行えるようにしてもよい。また、健康診断の際に何か異常が発見された場合、その項目を中心とする推論を行ってもよい。そのために、この対象者が使用しているセンサの中から、その症例に相応しい機器を見守りセンサとして指定してデータを収集してもよい。つまり、制御部1が、特定人物の健診結果のうち、特定の診断がなされた特定診断結果を判定する判定部(DBなどを検索して判定する)と、遺伝や生活習慣に依存する症状を抽出する症状抽出部と、抽出された症状に対応する見守りセンサを決定する決定部を有し、この決定に応じて、各機器との通信を行うよう通信制御部1aを制御して、必要なデータを集めるようにする。
【0177】
また、患者が、癌や慢性疾患を罹患している場合には、DB部9a(他のDB部や端末のメモリ記録部でもよい)に記録されている患者ごとの遺伝子情報や、マイクロバーム(常在菌の一種)情報を用いて、診察・診断時や、推論時に精度を向上させてもよい。例えば、これらの情報を、いくつかのタイプごとや、特定の遺伝子や常在菌の有無情報にして単純化して記録してもよい。
【0178】
一方、ステップS35における判定の結果、対応データがある場合には、推論を行う(S37)。前述したように、推論モデルを用いた推論は、特定の検体情報、生体情報を入力し多彩に、診断補助情報を推論結果として取得する。ここでは、制御部1は、対応データを推論エンジン7の入力層に入力して、推論結果を得る。推論結果として、例えば、如何なる疾病に罹患しているかについての確率等が出力される。
【0179】
推論を行うと、次に、疾患Aに近いか否かが判定される(S39)。ここでは、制御部1は、ステップS37における推論結果に基づいて、疾病Aに近いか否かを判定する。この判定の結果、疾病Aに近くない場合には、ステップS31に戻る。
【0180】
一方、ステップS39における判定の結果、疾病Aに近い場合には、必要に応じて、医師にも情報を出力する(S41)。ここでは、制御部1は、診断・検査機関9を通じて、医師端末9eに推論結果を出力する。
【0181】
また、判定個人に推論結果情報を出力する(S43)。この場合には、制御部1は、疾患Aに近いことを、患者の所有する端末4等に出力する。疾患Aに近い場合のアドバイスとしては、時系列の生体データなどの解析で、予測推論が可能な場合、早めの精密検査や治療開始を勧める表示等がある。
【0182】
また、このDB部8が、各クリニック、病院など医療機関、検査機関が有する検査機器や検査キットの管理情報を集めて一元管理できるようにしてもよい。どこにどのような機器があると分かっていれば、患者や医師などが、正確な情報をもとに判断し、行動することで、余計な感染リスクや誤診の問題に対処することが出来る。このような設備管理をもとにしたアドバイスを患者や医師等に行えば、患者や医師等は検査・医療機関ごとの保有機器情報を記憶する記憶部(DB)のアクセスすることができる。情報提供部1cは、こうした保有機器、設備情報を加味した有効情報を対象者に伝達することが出来る。つまり、対象者の検査データやプロフィール情報に加え、上記検査・医療機関ごとの保有機器情報に従った情報提供が可能となる。
【0183】
その他、食事、睡眠時間、運動など、生活習慣に関するアドバイスを情報出ししてもよい。「推論結果の情報出し」は、出す情報の全てを推論で作る必要はなく、推論結果から検索可能な一般的な情報を提示したりしてもよい。ステップS43において情報を出力すると、またはステップS39における判定の結果、疾患Aに近くない場合には、ステップS31に戻る。
【0184】
このように、図10Aおよび図10Bに示す、制御部1における制御部の動作によれば、医師が患者の病状に関する情報を入力し(S33参照)、患者の時系列データを取得可能な機器を特定し(S53、S55参照)、特定された機器と同様の機器を有する他の人の時系列データと診察情報を、教師データ化して学習を依頼している(S59、S61参照)。このため、新しい症状に遭遇した場合であっても、同様の機器による他の人の検査データと、その他の人の診察情報を用いて、推論モデルを生成することができる。この推論モデルを使用すれば、新しい症状に遭遇した場合でも、的確な診察をする際の参考情報として使用することができる。
【0185】
なお、ステップS59、S61における処理は、医師と連携して行うようにしているが、コンピュータが特定のプログラムをルーチンベースで行うようにしてもよい。また、本フローでは、人工知能(AI)を前提にして記載したが、必ずしも深層学習による推論モデルを使った推論である必要はない。特定のロジックやルールに従ったプログラムによる分岐やテーブル参照などであってもよい。
【0186】
以上説明したように、本発明の一実施形態とその変形例においては、医師が特定の患者の病状に入力する入力ステップ(例えば、図8図9AのS5、図10AのS31参照)と、患者の過去の時系列データを取得可能な機器を特定する機器特定ステップ(例えば、図4図9AのS11、S13参照)と、特定された機器と同様の機器を有する別の人の時系列データと、診察情報を教師データ化して学習を依頼する学習依頼ステップ(例えば、図5図7図9BのS21、図10BのS61参照)を実行している。このため、医師等が診察している際に、患者の過去のデータを簡単に確認することができ、さらに、患者が検査に使用している機器と同様の機器を使用している他の人のデータを用いて、疾病推論用の推論モデルを生成することが容易にできる。すなわち、本実施形態によれば、新しい事象が起きた際に、この事象に至った過程を示す情報を容易に収集し、またこの収集した情報を基に推論モデル生成用の教師データを作成することができる。
【0187】
また、本発明の一実施形態とその変形例において、対象者の検査データを取得する検査データ取得部と上記対象者のプロフィール情報と、検査・医療機関ごとの保有機器情報を記憶する記憶部の情報に基づいて、上記検査・医療機関ごとの保有機器情報に従って、上記対象者に伝達する伝達情報を決定する伝達情報決定部とを有する情報伝達用の装置や方法が提案可能となる。この場合には、診断・検査機関のDB部9aに、保有機器情報を記憶し、またDB部8にも保有機器情報を記憶すればよい。
【0188】
また、本発明の一実施形態とその変形例において、第1の機器によって対象者の時系列的な第1の検査データ群を取得する第1の検査データ取得部と、上記第1の検査データ群を補間できるような検査が可能な第2の機器によって上記対象者の時系列的な第2の検査データ群を取得する第2の検査データ取得部を設ける、あるいは利用することによって、上記第1の検査データ群と上記第2の検査データ群を用いて、上記対象者に提供する伝達情報を決定する情報伝達の装置や方法を提供することが可能である。なお、上記第1の検査データ群と、上記第2の検査データ群は、互いに検査タイミングまたは検査項目を補っていることによって、機器に束縛されず、豊富な分析、推論等が可能となる。前述したように、複数の機器によって、ユーザの時系列的検査データを取得した場合には、個々の機器の誤差や特性の差等があることから、複数の時系列的検査データを同一のグラフにプロットすることができない。但し、同一対象者の時系列的検査データであることから、データの変化パターンの傾向は同じである。そこで、複数の時系列的検査データに対して、補正演算を行う等、第1、第2の検査データを補う処理を施すことによって、複数の時系列的検査データを用いて、伝達情報を決定すればよい。
【0189】
また、本発明の一実施形態とその変形例において、多数の装置から収集したデータを教師データとして学習することによって生成された推論モデルを用いて推論を行う推論システムであって、収集データが想定外のデータが得られた場合に、想定外のデータを指定し、この指定したデータを収集する対応判定部を持たせ、このように集めた想定外のデータを少なくとも教師データの一部として、上記推論システムに対応する推論モデルの学習要求を行うような推論システムや装置、方法が提供可能となる。
【0190】
また、本発明の一実施形態とその変形例において、特定人物の健診結果が特定の診断であった場合、特定診断結果とし、また、遺伝や生活習慣に依存する症状を抽出し、上記抽出された症状に対応する見守りセンサを決定するセンサ決定装置や方法も提供可能である。この場合には、DB部8aに記録されるID別の利用可能な機器の一覧表には、個人利用可能な機器とその機能、および対応症例を記録する。個人利用可能機器は、第1機器2a、第2機器2b、第3機器3、診断・検査機関9、ユーザ情報部等から自動的に送信されてきてもよく、またユーザがアンケート等によって入力したデータを取得するようにしてもよい。また、DB部8aに記録される履歴データは、ユーザの一人一人を識別するための個人ID毎に作成される。履歴データは、ID毎に、扶養関係、血縁関係、医療情報、機器ID、取得データを記録する。遺伝や生活習慣に関する症状は、扶養関係や血縁関係に関連することが多いので、これらの者にも見守りセンサを決定してもよい。
【0191】
なお、本発明の各実施形態や変形例においては、制御部1、制御部9b、制御部9hは、CPU、メモリ、HDD等から構成されているIT機器として説明した。しかし、CPUとプログラムによってソフトウエア的に構成する以外にも、各部の一部または全部をハードウエア回路で構成してもよく、ヴェリログ(Verilog)によって記述されたプログラム言語に基づいて生成されたゲート回路等のハードウエア構成でもよく、またDSP(Digital Signal Processor)等のソフトを利用したハードウエア構成を利用してもよい。これらは適宜組み合わせてもよいことは勿論である。
【0192】
また、制御部1、制御部9b、制御部9hは、CPUに限らず、コントローラとしての機能を果たす素子であればよく、上述した各部の処理は、ハードウエアとして構成された1つ以上のプロセッサが行ってもよい。例えば、各部は、それぞれが電子回路として構成されたプロセッサであっても構わないし、FPGA(Field Programmable Gate Array)等の集積回路で構成されたプロセッサにおける各回路部であってもよい。または、1つ以上のCPUで構成されるプロセッサが、記録媒体に記録されたコンピュータプログラムを読み込んで実行することによって、各部としての機能を実行しても構わない。
【0193】
また、本明細書において説明した技術のうち、主にフローチャートで説明した制御に関しては、プログラムで設定可能であることが多く、記録媒体や記録部に収められる場合もある。この記録媒体、記録部への記録の仕方は、製品出荷時に記録してもよく、配布された記録媒体を利用してもよく、インターネットを通じてダウンロードしたものでもよい。
【0194】
また、本発明の一実施形態においては、フローチャートを用いて、本実施形態における動作を説明したが、処理手順は、順番を変えてもよく、また、いずれかのステップを省略してもよく、ステップを追加してもよく、さらに各ステップ内における具体的な処理内容を変更してもよい。
【0195】
また、特許請求の範囲、明細書、および図面中の動作フローに関して、便宜上「まず」、「次に」等の順番を表現する言葉を用いて説明したとしても、特に説明していない箇所では、この順で実施することが必須であることを意味するものではない。
【0196】
本発明は、上記実施形態にそのまま限定されるものではなく、実施段階ではその要旨を逸脱しない範囲で構成要素を変形して具体化できる。また、上記実施形態に開示されている複数の構成要素の適宜な組み合わせによって、種々の発明を形成できる。例えば、実施形態に示される全構成要素の幾つかの構成要素を削除してもよい。さらに、異なる実施形態にわたる構成要素を適宜組み合わせてもよい。
【符号の説明】
【0197】
1・・・制御部、1a・・・通信制御部、1b・・・ID判定部、1c・・・情報提供部、1d・・・推論モデル仕様決定部、1e・・・推論依頼部、1f・・・検索部、2a・・・第1機器、2a1・・・種別情報、2b・・・第2機器、2b1・・・種別情報、3・・・第3機器、3a1・・・種別情報、4・・・端末、5・・・学習部、5a・・・入出力モデル化部、5b・・・仕様照合部、6・・・学習依頼部、6a・・・記録部、6b・・・対象物種類A画像群、6c・・・教師データ、6d・・・仕様設定部、6e・・・通信部、6f・・・制御部、7・・・推論エンジン、8・・・DB部、8a・・・ID別履歴一覧、9・・・診断・検査機関、9a・・・DB部、9b・・・制御部、9c・・・表示制御部、9e・・・医師端末、9f・・・表示部、9g・・・操作部、9h・・・制御部
図1A
図1B
図2
図3
図4
図5
図6
図7
図8
図9A
図9B
図10A
図10B