特表 2024-523120 臨床医定義分析論のためのスケーラブルアーキテクチャシステム

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

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

(11)【公表番号】

(43)【公表日】2024-06-28

(54)【発明の名称】臨床医定義分析論のためのスケーラブルアーキテクチャシステム

(51)【国際特許分類】

   G16H 50/20 20180101AFI20240621BHJP

【ＦＩ】

G16H50/20

【審査請求】有

【予備審査請求】未請求

(21)【出願番号】P 2023571410

(86)(22)【出願日】2022-05-18

(85)【翻訳文提出日】2024-01-15

(86)【国際出願番号】 US2022029750

(87)【国際公開番号】W WO2022256173

(87)【国際公開日】2022-12-08

(31)【優先権主張番号】17/335,911

(32)【優先日】2021-06-01

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

(81)【指定国・地域】

(71)【出願人】

【識別番号】515058422

【氏名又は名称】ヴァイタル コネクト，インコーポレイテッド

【氏名又は名称原語表記】Ｖｉｔａｌ Ｃｏｎｎｅｃｔ，Ｉｎｃ．

【住所又は居所原語表記】２８７０ Ｚａｎｋｅｒ Ｒｏａｄ， Ｓｕｉｔｅ １００， Ｓａｎ Ｊｏｓｅ， ＣＡ， Ｕ．Ｓ．Ａ

(74)【代理人】

【識別番号】110002952

【氏名又は名称】弁理士法人鷲田国際特許事務所

(72)【発明者】

【氏名】フェリックス イアン

(72)【発明者】

【氏名】ナラタンビ ガブリエル

(72)【発明者】

【氏名】ナザリ ネルシ

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

5L099

【Ｆターム（参考）】

5L099AA04

(57)【要約】

臨床医が、臨床診療を通じて、あらゆる病態をスクリーニングするために、患者及び企業ごとに臨床入力、演算子、及び通知を定義できるようにするための、スケーラブルなモジュラアーキテクチャの方法及びシステム。
【選択図】図１

【特許請求の範囲】

【請求項1】

臨床医定義分析論のためのスケーラブルモジュラアーキテクチャのための方法であって、
１つ以上のデバイスの１つ以上のセンサにより、患者の１つ以上の臨床測定値を測定することと、
前記１つ以上の臨床測定値を、指令センタにより、集約することと、
前記指令センタにより、１つ以上の決定システムに対して、前記集約された臨床測定値から、臨床測定値ベクトルを抽出することと、
前記指令センタにより、入力データのプールから１つ以上の決定システムをトリガすることに関連する適切な臨床測定値を選択することと、
前記指令センタにより、計算を実行して、分析論の仕様及び演算に従って分析論エンジンを定義することと、
を含む、前記方法。

【請求項2】

前記定義済み分析論エンジンを使用して、１つ以上の意思決定支援システムがトリガされる、請求項１に記載の方法。

【請求項3】

前記定義済み分析論エンジンは、臨床医の前記定義に基づいて、前記意思決定支援システムの評価タスク、最適化プロセス、及び計算プロセスをさらに実行する、請求項２に記載の方法。

【請求項4】

前記評価タスクは、計算に使用される数学的形式への前記定義の評価及びコンパイルと、正確な出力を保証するために数学的形式を介して実行される自動化コンパイルルールまたはオペランド値の手動入力テーブルを含む構文の検証とを含む、請求項３に記載の方法。

【請求項5】

前記最適化プロセスは、到達不能な状態またはステートメントを低減することにより、状態または宣言ステートメントを最小化することを含む、請求項４に記載の方法。

【請求項6】

前記計算プロセスは、前記意思決定支援システムの要素を計算するために、前記オペランド及び最適化された数学的構造に関するデータベクトルを使用する、請求項５に記載の方法。

【請求項7】

前記分析論の仕様及び演算の定義及び設定を、臨床医が行うことをさらに含む、請求項１に記載の方法。

【請求項8】

前記分析論の仕様及び演算の前記定義及び設定を行うことは、
臨床医ポータルにより、意思決定支援システムの明示的な説明のための数学的構造を定義するために決定レイヤのプロセスを設定することと、
前記意思決定支援システムに必要なオペランドを定義レイヤで定義することと、
を含み、
前記オペランドが、バイタルサイン測定値またはラボ結果のうちの少なくとも１つを含むセンサ入力を含む、請求項７に記載の方法。

【請求項9】

前記決定レイヤは、ブールプロセス、採点プロセス、動的プロセス、または混合プロセスのうちの少なくとも１つを含む、請求項８に記載の方法。

【請求項10】

前記ブールプロセスは、その結果が単一のアラートをトリガし得る決定構造を定義する、請求項９に記載の方法。

【請求項11】

前記採点プロセスは、その結果が複数のアラートをトリガし得るスコアを生成する決定構造を定義する、請求項９に記載の方法。

【請求項12】

前記動的プロセスは、前記プロセスが、単一のアラートをトリガし得る最終状態に達するまで、前記プロセスが１つの状態から次の状態へと遷移する決定構造を定義する、請求項９に記載の方法。

【請求項13】

前記混合プロセスは、それぞれの状態がブールプロセスまたは採点プロセスである動的プロセスである、請求項９に記載の方法。

【請求項14】

以前の定義及び演算の転帰に基づいて最適な決定を学習することにより、前記分析論の仕様及び演算の定義を選択する際に、臨床医を補助することをさらに含む、請求項１に記載の方法。

【請求項15】

前記１つ以上の臨床測定値を電子健康記録（ＥＨＲ）に組み込むことをさらに含む、請求項１に記載の方法。

【請求項16】

臨床医定義分析論のための実行可能命令を記憶する非一時的コンピュータ可読媒体であって、前記命令が、実行に応答して、コンピュータに、
１つ以上のデバイスの１つ以上のセンサにより、患者の１つ以上の臨床測定値を測定することと、
前記１つ以上の臨床測定値を、指令センタにより、集約することと、
前記指令センタにより、１つ以上の決定システムに対して、前記集約された臨床測定値から、臨床測定値ベクトルを抽出することと、
前記指令センタにより、入力データのプールから１つ以上の決定システムをトリガすることに関連する適切な臨床測定値を選択することと、
前記指令センタにより、計算を実行して、分析論の仕様及び演算に従って分析論エンジンを定義することと、
を含む演算を行わせる、前記非一時的コンピュータ可読媒体。

【請求項17】

前記演算が、さらに、
前記分析論の仕様及び演算の定義及び設定を臨床医が行うことを含み、
前記分析論の仕様及び演算の前記定義及び設定を行うことが、
臨床医ポータルにより、意思決定支援システムの明示的な説明のための数学的構造を定義するために決定レイヤのプロセスを設定することと、
前記意思決定支援システムに必要なオペランドを定義レイヤで定義することと、
を含み、
前記オペランドが、バイタルサイン測定値またはラボ結果のうちの少なくとも１つを含むセンサ入力を含む、請求項１６に記載の非一時的コンピュータ可読媒体。

【請求項18】

前記決定レイヤは、ブールプロセス、採点プロセス、動的プロセス、または混合プロセスのうちの少なくとも１つを含む、請求項１７に記載の非一時的コンピュータ可読媒体。

【請求項19】

前記ブールプロセスは、その結果が単一のアラートをトリガし得る決定構造を定義し、
前記採点プロセスは、その結果が複数のアラートをトリガし得るスコアを生成する決定構造を定義し、
前記動的プロセスは、前記プロセスが、単一のアラートをトリガし得る最終状態に達するまで、前記プロセスが１つの状態から次の状態へと遷移する決定構造を定義し、
前記混合プロセスは、それぞれの状態がブールプロセスである動的プロセスである、請求項１８に記載の非一時的コンピュータ可読媒体。

【請求項20】

前記定義済み分析論エンジンを使用して、１つ以上の意思決定支援システムがトリガされる、請求項１６に記載の非一時的コンピュータ可読媒体。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、臨床医定義分析論のためのスケーラブルアーキテクチャシステムに関する。

【背景技術】

【0002】

臨床医は、様々な種類の疾患の早期発見を支援し、かつ時宜を得た介入を提供するために、意思決定支援システムを利用する。臨床意思決定支援システムは、透明性があり、理解可能であり、説明可能な決定を提供する必要がある。ブラックボックスアルゴリズムから生じる不透明な決定とは異なり、透明なアルゴリズムは、自動化された意思決定支援プラットフォームに対する臨床医の信頼を高める。そのためにも、臨床医は、支援システムの決定がトリガされた理由を知り、理解する必要があることを求められる。さらに、標準的な病院または自宅の環境で患者の疾患の改善または悪化を監視するために使用できる時宜を得た意思決定システムのためには、測定データとラボデータとがシームレスに統合する必要がある。

【0003】

本願は、患者の疾患の改善または悪化を監視するために、標準的な病院または自宅の環境で使用される従来の意思決定システムの制限を克服する。本開示は、臨床ワークフローに組み込むことが可能であり、信頼性が高く、透明性があり、説明可能な意思決定支援システムをトリガするための分析論を臨床医が明示的に定義することを可能にするスケーラブルなモジュラアーキテクチャを提供する。

【発明の概要】

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

【0004】

例示的な一実施形態では、臨床医定義分析論のためのスケーラブルモジュラアーキテクチャのための方法であって、１つ以上のデバイスの１つ以上のセンサによって、患者の１つ以上の臨床測定値を測定することと、１つ以上の臨床測定値を、指令センタによって、集約することと、指令センタにより、１つ以上の決定システムに対して、集約された臨床測定値から、臨床測定値ベクトルを抽出することと、指令センタにより、入力データのプールから１つ以上の決定システムをトリガすることに関連する適切な臨床測定値を選択することと、指令センタにより、計算を実行して、分析論の仕様及び演算に従って分析論エンジンを定義することと、を含む、方法が説明される。

【0005】

上記の概要は単なる例示に過ぎず、いかなる形でも限定することを意図していない。上述の例示的な態様、実施形態、及び特徴に加えて、さらなる態様、実施形態、及び特徴が、図面及び以下の詳細な説明を参照することによって明らかになるであろう。

【0006】

下記の詳細な説明から当業者には様々な変更及び修正が明らかになるので、続く簡単な説明では、実施形態は例示としてのみ説明されている。異なる図の同じ参照番号の使用は、類似または同一の物を示す。

【図面の簡単な説明】

【0007】

【図1】スケーラブルな臨床医定義分析論のためのシステム及び方法の１つ以上の実施形態を実装するための例示的なブロック図を示す。

【図2】臨床医定義分析論のためのアーキテクチャの例示的なブロック図を示す。

【図3】臨床医ポータル及び定義済み分析論エンジンの例示的なブロック図を示す。

【図4】ベクトルレイヤの例示的なブロック図を示す。

【図5】例示的なブール演算プロセスを示す。

【図6】例示的な採点プロセスを示す。

【図7】例示的な動的プロセスを示す。

【図8】例示的な混合プロセスを示す。

【図9】補助エンジンの例示的なブロック図を示す。

【図10】コンピューティングデバイスの例示的なブロック図を示す。

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

【0008】

以下の詳細な説明では、説明の一部を形成する添付図面を参照する。図面中、同様の符号は、通常、文脈から別段の指示がない限りは、同様の構成要素を識別する。さらに、別段の記載がない限り、連続する各図面の説明は、先行する図面のうちの１つ以上の図面に由来する特徴を参照して、現在の例示的な実施形態のより明瞭な文脈及びより実質的な説明を提供することができる。引き続き、詳細な説明、図面及び特許請求の範囲に記載されている例示的な実施形態は、限定することを意図したものではない。本明細書に提示されている主題の趣旨及び範囲から逸脱することなく、他の実施形態を利用すること、及び他の変更を行うことができる。本開示の態様は、本明細書に一般的に説明され、図面に例示されているように、多種多様な構成で配列、置換、結合、分離、及び設計を行うことができ、それらの全てが本明細書に明示的に企図されていることが容易に理解されるであろう。

【0009】

図１は、臨床医定義分析論のための方法及びスケーラブルモジュラアーキテクチャの１つ以上の実施形態を実装するための例示的な図を示す。図１に示されるように、例えば、１つ以上のデバイスの１つ以上のセンサが、１０において１つ以上の臨床測定値を測定する。１１において、１つ以上の臨床測定値及びラボ測定値が、中継装置または指令センタにおいて集約され及び／または蓄積される。１２において、臨床測定ベクトルが、１つ以上の意思決定システムのための集約された臨床測定値から抽出される。すなわち、１２において、１つ以上の意思決定システムのトリガに関連する適切な臨床測定値が、入力データのプールから選択される。１３において、臨床医によって定義され、設定された分析論仕様及び演算に従って分析論エンジンを計算し、定義するために、計算が実行される。１４において、定義された分析論エンジンを使用して、１つ以上の意思決定支援システムがトリガされる。

【0010】

臨床医定義分析論システムはまた、以前の定義及び演算の転帰に基づいて最適な意思決定を学習することによって、分析論仕様及び演算の定義を選択する際に、臨床医を補助する選択肢を含む。１１の中継プロセスからの全ての測定値を、１５で、電子健康記録（ＥＨＲ）に組み込むことができる。臨床医定義分析論システムは、１６において、補助システムを使用して、臨床医の定義をサポートする。臨床医は、１７で、１つ以上の意思決定システムの分析論仕様及び演算を定義する。１６の臨床医による定義は、１３の分析論計算のために入力される。１３の分析論計算はまた、１５のＥＨＲに入力され、組み込まれる。

【0011】

さらに、本システムは、主治医の「デジタル処方箋」を解釈して、次のことを達成することができる。
１．臨床医の指示に従ってバイタルサインの様々な平均及びメトリックを予め計算し、より迅速に対応できるようにする。
２．処方箋の複雑さによって、明示的または暗黙的に、臨床医の指示に応じて必要なリソースを対応させるために、基礎となるコンピューティング構造（通常は「クラウドコンピューティング」）と通信する。
３．臨床医はさらに、患者の電子健康記録に部分的または全体的に基づいて上記調整を行うようにシステムに指示することができる。
４．システムは、所与の患者または患者集団に対して、デジタル処方箋に従い、モジュール形式で、コンピューティングハードウェア及びソフトウェアを追加する。システムはまた、患者（複数可）が退院すると、それらのリソースを解放することができる。
臨床医定義分析論システムのための上記のアーキテクチャは、図２のブロック図表示によって、より詳細に説明される。

【0012】

図２は、センサドメイン２０、患者アプリ２１、指令センタ２２、及び電子健康記録（ＥＨＲ）２３の４つの主要構成要素を含む臨床医定義分析論システムのアーキテクチャを示す。各構成要素は、スケーラビリティ及び統合の容易性を確保する１つ以上のモジュールへと編成される。さらに、各モジュールは、次のような階層、すなわち、エンジン、システム、レイヤ、プロセス及びタスクに分類される。それぞれの階層レベルは、複数の冗長性を有する１つ以上の分散型計算ノードで処理が行われるマイクロサービスアーキテクチャにおける自己完結型の機能であり得る。アーキテクチャの各構成要素を以下に説明する。

【0013】

図２に示されているように、センサドメイン２０システムは、１人または複数人の患者の臨床的に関連する変数を測定するための１つ以上のセンサを含むことができる。このシステムは、自立型であってもよく、あるいは体の１つ以上の位置に配置されるか、または体内に埋め込まれる、別個のデバイスであってもよい。体に接触しているセンサシステム、または非接触のセンサシステムも、本発明の範囲内である。

【0014】

センサドメイン２０のセンサデバイスは、連続型またはスポットチェック式の自動測定、及び手動のスポットチェック測定を行うことができる。連続測定は、本発明を含み、かつ本発明の範囲内にある、例えば、バイタルサインモニタ、ペースメーカ、脊髄刺激装置、インスリンポンプ、及び血糖計等のデバイスの中の１・・・Ｎ個のセンサによって行われる。手動のスポットチェック測定は、本発明の範囲内にある、例えば、温度計、温度プローブ、スパイロメータ、血圧計、秤量スケール、パルスオキシメトリ等のデバイスの中のＮ＋１・・・Ｎ＋Ｍ個のセンサによって行われる。センサドメイン２０はまた、＃１・・・＃Ｎの患者を監視し得る。

【0015】

センサドメイン２０のデバイスは、例えばＷＩＦＩ、Ｂｌｕｅｔｏｏｔｈ（登録商標）、ＺｉｇＢｅｅ（登録商標）等の通信技術を介して、（例えば電話機またはタブレット等のリレーまたはモバイルデバイスに配備された）患者アプリ２１と通信して、暗号化された安全な通信を保証することができる。センサドメイン２０は、患者アプリ２１と通信するための送受信機及び受信機を含むことができる。各通信は、ユーザの認証後に一意の患者セッションを開始する。

【0016】

図２に示すように、患者アプリ２１は、均一なまたは不均一な測定頻度に基づいて、暗号解読プロセス中に、センサドメイン２０からの１つ以上のセンシングモダリティを区別し、処理するためのタスクを含む入力プロセスを含む。患者アプリ２１を介して患者／臨床医タスクが入力され得る。さらに、予め定められた頻度を有する通知プロセスを使用して、測定を行うことをユーザに想起させ、入力プロセスのカスタムタスクによって、手動測定の処理モダリティ（一定のタスクまたは非一定のタスク）が決定される。時間プロセスにより、入ってくるデータサンプルが、必要な解像度の一意のタイムスタンプに関連付けられ、時間ウィンドウ内の情報のグループ化が可能になる。

【0017】

患者アプリ２１の認証レイヤは、安全かつパスワードで保護された患者ポータル、技術者ポータル、及び臨床測定の入力に対して適切な制御を備えたナースポータルを有する。患者アプリ２１の計算レイヤは、エッジでの処理で意味情報を抽出し、データの冗長性を除去することを可能にする。患者アプリ２１の通信レイヤは、センサドメインからの情報を暗号解読して、それらをアプリのユーザインターフェースに表示する標準的なプロセスを有する。通信レイヤはさらに、ＷＩＦＩ、セルラ等の通信技術を用いて、保護されたデータを指令センタへ送信するために、情報を圧縮し、暗号化する。認証レイヤは、各患者セッションが一意であることを保証するために、プロトコルを使用してセンサドメイン及び指令センタと通信する。

【0018】

図２に示すように、指令センタ２２は、組織、階、館、及び患者等の階層のレイヤに編成される。指令センタの測定レイヤは、患者アプリ２１（中継装置）から情報を受信するための中継プロセスを有し、ラボ結果等の入力及び電子健康記録（ＥＨＲ）からの他の測定値を受信するためのＥＨＲプロセスを有する。さらに、中継プロセスからの全ての測定値が、ＥＨＲに組み込まれる選択肢を有する。臨床医認証レイヤは、安全かつパスワードで保護された臨床医ポータル、（測定レイヤのカスタムタスクにより編成された）臨床測定の入力に対して適切な制御を備えた技術者ポータル及びナースポータルと、測定の入力をユーザに想起させる予め定められた頻度を有するユーザ通知プロセスとを有する。

【0019】

図３に示すように、臨床医ポータル３０は、分析論の仕様及び演算に関する臨床医による定義の設定を可能にする。さらに図３は、意思決定支援システムをトリガするための臨床医による決定、ルール、及び定義を設定することに関与する一連のステップを示す。第１のステップは、臨床医ポータル３０によって、意思決定支援システムの明示的な説明のための数学的構造を定義するために決定レイヤ３１のプロセスを設定することである。そして、意思決定支援システムに必要なオペランドが定義レイヤで定義される（定義レイヤ：オペランドプロセス３２）。オペランドは、バイタルサイン測定等のセンサ入力、血液パラメータ測定等のラボ結果、及び他の測定であり得る。続いて、意思決定支援システムで使用される演算子が定義レイヤにおいて定義される。ここで、演算子は、加算、減算、乗算または除算等の算術演算子、ＡＮＤ、ＯＲ、否定等の論理演算子、より大きい、より小さいまたは等しい等の関係演算子、平均、中央値、最頻値、分散、標準偏差等の統計演算子、あるいは関数演算子であり得る（定義レイヤ：演算子プロセス３３）。定義レイヤにおける閾値プロセスは、特定の患者の臨床測定を解釈するための比較の基礎を提供し、健康な人では所与の臨床測定に対して正常であると見なされ、または病理状態では異常であると見なされる絶対値、範囲または間隔であり得る（定義レイヤ：閾値プロセス３４）。定義レイヤにおける重み付けプロセスは、処理要素の重要度に応じて様々な重みを割り当てるために使用される（定義レイヤ：重み付けプロセス３５）。ルールレイヤにおける時間ルールは、処理のインスタンス及びウィンドウを定義し、正確な時間、すなわち、サンプルｔ＿ｉおきに、複数の時点、重複するまたは重複しない時間ウィンドウであり得る（ルールレイヤ：時間ルール３６）。ルールレイヤにおける遷移ルールは、現在の状態及び他の入力に基づいて、次の状態への遷移の定義を指定する（ルールレイヤ：遷移ルール３７）。ルールレイヤにおける優先ルールは、計算のための優先順位を、括弧を用いて定義する（ルールレイヤ：優先ルール３８）。

【0020】

図３にさらに示されているように、定義済み分析論エンジン４０は、臨床医の定義に基づいて意思決定支援システムの評価、最適化、計算、及びトリガを行うために使用される。評価タスクは、計算に使用可能な数学的形式への定義の評価及びコンパイルを含む（計算プロセス：評価タスク４１）。構文の検証には、自動化コンパイルルール、または適切な出力を確実に与えるように数学的な形式を介して実行できるオペランド値の手動入力テーブルが含まれ得る。最適化プロセス４２は、到達不能な状態またはステートメントを低減することにより、状態または宣言文を最小化することを含む。計算プロセスは、オペランドのデータベクトル（計算ベクトルプロセス４３）と、意思決定支援システムの要素を演算するための最適化された数学的構造とを使用する（計算プロセス：算出タスク４４）。トリガプロセス４５は、１つ以上の決定システムの出力に基づいてアラートをトリガするために使用される。

【0021】

図４に示すように、ベクトルレイヤについて説明する。ベクトルレイヤは、測定レイヤ５１からの均一な入力と不均一な入力とに対して演算して、定義済み分析論エンジン５０による計算に使用されることになるオペランド値のベクトルを形成する。集約タスク５２は、臨床医によって定義されたオペランドの測定値（オペランド定義５３）を抽出することを含む。エラー対処プロセス５４は、外れ値、エントリの欠落、及びエントリの誤りを処理すること、及び対処することのためのタスクを含む。スカラー化タスク５５は、所与の臨床測定のサンプル値のグループからスカラー値を計算することを含む。さらに、スカラー化タスク４４は、均一な入力の場合には値のグループをスカラーに変換すること、または均一でない入力の場合には最も近い利用可能なサンプル値に変換する、統計的な演算子（演算子定義５６）を使用することができる。さらに、スカラー化タスク５５は、時間プロセスの時間タスク（時間ルール５７）、すなわち利用可能な場合は常に、または以前の時間ウィンドウもしくは転帰に基づく時間ウィンドウによって駆動される場合がある。各臨床測定のスカラー値は、定義済み分析論エンジン４０によって使用されるオペランドのベクトルを形成する（ベクトル化タスク５９）ために累積される（累積タスク５８）。

【0022】

本発明はさらに、決定レイヤ３１の以下の実施形態を含む。

【0023】

図５は、決定レイヤ３１の例示的な実施形態を示す。例えば、図５は、結果（１または０）が単一のアラートをトリガし得る数学的決定構造を定義するブール（Ｂｏｏｌｅａｎ）プロセスを開示する。このプロセスは、関係演算子φを使用してオペランドＡを閾値λと比較することから始まる。これらの個々の演算の結果は、論理演算子εを使用して結合されて、アラートをトリガするべきか（１の場合）、否か（０の場合）を決定し得る。

【0024】

図６は、決定レイヤ３１の別の例示的実施形態を示す。例えば、図６は、複数のアラートをトリガし得るスコアを結果として生成する数学的決定構造を定義する採点プロセスを開示する。このプロセスは、各ステートメントがブールプロセスである複数のステートメントを計算することから始まる。すなわち、関係演算子φを使用してオペランドＡを閾値λと比較し、論理演算子εを使用して演算を組み合わせることで１または０を出力する。各ステートメントには、重みＷを乗算することによって、異なる臨床レベルが割り当てられる。次いで、重み付けされた結果が、算術演算子Σを使用して結合されて、スコアＳが生成される。次に、このスコアが、関係演算子を使用して、１つ以上のアラートを生成する複数の下限の閾値及び上限の閾値と比較される。

【0025】

図７は、決定レイヤ３１の別の例示的実施形態を示す。例えば、図７は、単一のアラートをトリガする可能性のある最終状態に達するまで、プロセスがある状態から次の状態へと遷移する数学的決定構造を定義する動的プロセスを開示する。このプロセスは、関係演算子φを使用して閾値λと比較されたオペランドＡを評価して、出力１または０を生成することから始まる。出力に基づいて、プロセスは、最終状態に達してアラートがトリガされるまで、臨床医が定義した遷移ルールを使用して、ある状態から次の状態へと遷移する。

【0026】

決定レイヤ３１の別の例示的な実施形態は、上記のプロセスの組み合わせである異種混合の数学的決定構造を定義する混合プロセスを含む。例えば、図８は、各状態がブールプロセスである動的プロセスである混合プロセスを示す。

【0027】

図９は、患者の特定の状態に関する最適な定義及びルールを選択するために臨床医を支援する補助エンジンを示す。補助タスクは、状態固有または患者固有あるいはその両方であってよい。状態固有タスクの例示的な実施形態は、知識ベース８３を含むデータベースに問い合わせて、特定の状態及び決定レイヤ８１に対して、臨床的に許容可能な定義及びルール８７を提供することができる。患者固有タスクの例示的な実施形態は、臨床医が患者に対して設定した事前の定義及び演算をＥＨＲ８２から取得する抽出タスク８４と、特定の患者の以前の転帰に基づいて最適な決定／ルールを学習するアルゴリズムプロセス８４とを含み得る。状態固有タスクと患者固有タスクとの組み合わせの例示的な実施形態は、状態を知識ベース８３に照合すること８４、及び患者を以前の転帰に基づいて学習された最適な決定／ルールに照合することである場合があり、定義及びルールを臨床医ポータルに設定するために臨床医に包括的な情報を提供する場合がある。補助エンジンの出力は、支援のみを目的として意図されており、いずれの時点においても、このアーキテクチャは、臨床医に、定義及びルール８７に対する補助エンジンの支援を無効にする機能を提供する。

【0028】

したがって、開示されたモジュラアーキテクチャにより、臨床医は、臨床診療を通じて、あらゆる病態をスクリーニングするために、患者及び企業ごとに臨床入力、演算子、及びアラームを定義すること、ならびに透明性があり、理解可能かつ説明可能な決定を行うことが可能になる。

【0029】

図に描かれ、図に従って説明された構成要素及び演算に関しては、演算及びサブ演算のいずれもが、コンピュータ可読媒体に格納された非一時的なコンピュータ可読命令として実装され得る。コンピュータ可読命令は、例えば、本明細書で言及されるように、ネットワーク要素及び／またはこれに対応する他の任意のデバイスを有して、特に上記のアプリケーション及び／またはプログラムに適用可能なように、センサドメイン２０、患者アプリ２１、及び／または指令センタ２２の１つ以上のプロセッサによって実行され得る。

【0030】

前述のことから、本開示の様々な実施形態が、本明細書に例示の目的で記載されており、本開示の範囲及び趣旨から逸脱することなく、様々な修正が行われ得ることが理解されよう。さらに、当業者であれば、様々な実施形態を組み合わせること、または分離することが可能であり、様々な実施形態を組み合わせることは、本発明者らの所有、検討、及び意図の範囲内であることを理解するはずである。したがって、本明細書に開示された様々な実施形態は、限定することは意図されてなく、真の範囲及び趣旨は、以下の特許請求の範囲によって示される。

【0031】

当業者は、本明細書に開示される本プロセス及び方法ならびに他のプロセス及び方法については、プロセス及び方法で実施される機能が、異なる順序で実施されてもよいことを理解するであろう。さらに、概説したステップ及び演算は、単に例として提供されているに過ぎず、ステップ及び動作のいくつかは、開示された実施形態の本質を損なうことなく、任意選択であってもよく、より少ないステップ及び演算に組み合わされてもよく、または追加のステップ及び演算に拡張されてもよい。

【0032】

さらに、本開示は、本出願に記載されている特定の実施形態に関して限定されるべきものではなく、これらの特定の実施形態は様々な態様を例示するものとして意図されている。当業者には明らかであるように、その趣旨及び範囲から逸脱することなく、多くの修正形態及び変形形態が行われることが可能である。本明細書に列挙されるものに加えて、本開示の範囲内で機能的に等価な方法、及び装置さえもが、上記の説明から当業者に明らかであろう。そのような修正形態及び変形形態は、添付の特許請求の範囲内に含まれるものとする。本開示は、添付の特許請求の範囲が権利を有する均等物の全範囲と併せて、そのような特許請求の範囲の条項によってのみ限定されるべきである。本開示は、特定の方法、試薬、化合物、組成物、または生体系に限定されず、これらは、当然、変更可能であることを理解されたい。本明細書で使用される専門用語が、特定の実施形態を説明することのみを目的としており、限定するようには意図されていないことも理解されたい。

【0033】

図１０は、スケーラブルな臨床医定義分析論のためのシステム及び方法の様々な実施形態を実装することができるサンプルコンピューティングデバイス６００を示す。より詳細には、図１０は、本明細書に記載されている演算、プロセス等のいずれかがコンピュータ可読媒体に記憶されたコンピュータ可読命令として実装され得る、例示的なコンピューティングの実施形態を示す。コンピュータ可読命令は、例えば、モバイルユニットのプロセッサ、ネットワーク要素、及び／または他の任意のコンピューティングデバイスによって実行され得る。

【0034】

非常に基本的な構成６０２では、コンピューティングデバイス６００は、典型的には、１つ以上のプロセッサ６０４と、システムメモリ６０６とを備える。プロセッサ６０４とシステムメモリ６０６との間の通信には、メモリバス６０８を使用することができる。

【0035】

所望の構成に応じて、プロセッサ６０４は、マイクロプロセッサ（μＰ）、マイクロコントローラ（μＣ）、デジタル信号プロセッサ（ＤＳＰ）、またはこれらの任意の組み合わせを含むが、これらに限定されない任意のタイプのものにすることができる。プロセッサ６０４は、レベル１キャッシュ６１０及びレベル２キャッシュ６１２等の１つ以上のキャッシュングレベルと、プロセッサコア６１４と、レジスタ６１６とを含み得る。例示的なプロセッサコア６１４は、算術論理ユニット（ＡＬＵ）、浮動小数点ユニット（ＦＰＵ）、デジタル信号処理コア（ＤＳＰコア）、またはこれらの任意の組み合わせを含み得る。例示的なメモリコントローラ６１８もまた、プロセッサ６０４と共に使用され得、または一部の実装では、メモリコントローラ６１８は、プロセッサ６０４の内部部品であり得る。

【0036】

所望の構成に応じて、システムメモリ６０６は、揮発性メモリ（ＲＡＭ等）、不揮発性メモリ（ＲＯＭ、フラッシュメモリ等）、またはこれらの任意の組み合わせを含むが、これらに限定されない任意のタイプのものにすることができる。システムメモリ６０６は、オペレーティングシステム６２０と、１つ以上のアプリケーション６２２と、プログラムデータ６２４とを含み得る。

【0037】

アプリケーション６２２は、図１～図９に関して前述されたものを含む、本明細書に記載されている機能を実行するように構成されたクライアントアプリケーション６８０を含み得る。プログラムデータ６２４は、テーブル６５０を含むことができ、このテーブルは、代わりに、「図表６５０」または「分布表６５０」と称されることもあり、これは、本明細書に記載されているように、患者の皮膚表面上のＥＣＧ、ＰＣＧ及びＡＣＣ信号を測定するのに有用であり得る。

【0038】

コンピューティングデバイス６００は、基本構成６０２と必要な任意のデバイス及びインターフェースとの間の通信を容易にするために、追加の特徴または機能、及び追加のインターフェースを有することができる。例えば、基本構成６０２と１つ以上のデータ記憶装置６３２との間の通信を容易にするために、記憶装置インターフェースバス６３４を介して、バス／インターフェースコントローラ６３０が使用され得る。データ記憶装置６３２は、リムーバブル記憶装置６３６、ノンリムーバブル記憶装置６３８、またはこれらの組み合わせとすることができる。リムーバブル記憶装置及びノンリムーバブル記憶装置の例には、いくつかの例を挙げると、フレキシブルディスクドライブ及びハードディスクドライブ（ＨＤＤ）等の磁気ディスク装置、コンパクトディスク（ＣＤ）ドライブまたはデジタル多用途ディスク（ＤＶＤ）ドライブ等の光ディスクドライブ、ソリッドステートドライブ（ＳＳＤ）、ならびにテープドライブが含まれる。例示的なコンピュータ記憶媒体は、コンピュータ可読命令、データ構造、プログラムモジュール、またはその他のデータ等の情報を記憶するために、任意の方法、または技術で実装される、揮発性、及び不揮発性、リムーバブル、及びンリムーバブル媒体を含み得る。

【0039】

システムメモリ６０６、リムーバブル記憶装置６３６、及びノンリムーバブル記憶装置６３８は、コンピュータ記憶媒体の例である。コンピュータ記憶媒体は、これに限定されないが、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、フラッシュメモリもしくは他のメモリ技術、ＣＤ‐ＲＯＭ、デジタル多用途ディスク（ＤＶＤ）もしくは他の光記憶装置、磁気カセット、磁気テープ、磁気ディスク記憶装置もしくは他の磁気記憶デバイス、またはコンピューティングデバイス６００によってアクセスされ得る所望の情報を記憶するために使用され得る、任意の他の媒体を含み得る。かかるコンピュータ記憶媒体は、いずれも、コンピューティングデバイス６００の一部であってもよい。

【0040】

コンピューティングデバイス６００はまた、様々なインターフェースデバイス、例えば、出力デバイス６４２、周辺インターフェース６４４、及び通信デバイス６４６から、バス／インターフェースコントローラ６３０を介して基本構成６０２への通信を容易にするためインターフェースバス６４０を含み得る。例示的な出力デバイス６４２は、グラフィックス処理ユニット６４８及びオーディオ処理ユニット６５０を含む場合があり、これらは、１つ以上のＡ／Ｖポート６５２を介して、ディスプレイまたはスピーカ等の様々な外部デバイスと通信するように構成され得る。例示的な周辺インターフェース６４４は、シリアルインターフェースコントローラ６５４またはパラレルインターフェースコントローラ６５６を含むことがあり、これらは、１つ以上のＩ／Ｏポート４５８を介して、入力デバイス（例えば、キーボード、マウス、ペン、音声入力デバイス、タッチ入力デバイス等）または他の周辺デバイス（例えば、プリンタ、スキャナ等）等の外部デバイスと通信するように構成され得る。例示的な通信デバイス６４６は、ネットワークコントローラ６６０を含み得、このネットワークコントローラ６６０は、１つ以上の通信ポート６６４を介して、ネットワーク通信リンクを通じて、１つ以上の他のコンピューティングデバイス６６２との通信を容易にするように構成され得る。

【0041】

ネットワーク通信リンクは、通信媒体の一例であり得る。通信媒体は、通常、搬送波または他の転送機構等の変調データ信号内のコンピュータ可読命令、データ構造、プログラムモジュール、または他のデータによって具体化され得、任意の情報配信媒体を含み得る。「変調データ信号」とは、その信号中の情報を符号化するように設定または変更された、その信号の特性のうちの１つ以上を有する信号であり得る。限定ではないが例として、通信媒体には、有線ネットワークまたは直接有線接続等の有線媒体、ならびに音響、無線周波数（ＲＦ）、マイクロ波、赤外線（ＩＲ）、及びその他の無線媒体等の無線媒体が含まれ得る。本明細書で使用されるコンピュータ可読媒体という用語は、記憶媒体と通信媒体との両方を含む場合がある。

【0042】

コンピューティングデバイス６００は、携帯電話、パーソナルデータアシスタント（ＰＤＡ）、パーソナルメディアプレーヤデバイス、無線ウェブ時計デバイス、パーソナルヘッドセットデバイス、特定用途向けデバイス、または上記の機能のいずれかを含むハイブリッドデバイス等の小型のポータブル（またはモバイル）電子デバイスの一部として実装することができる。コンピューティングデバイス６００は、ラップトップコンピュータ及び非ラップトップ型コンピュータの構成の双方を含むパーソナルコンピュータとして実装することもできる。

【0043】

システムの態様のハードウェア実装とソフトウェア実装との間に、ほとんど区別はない。つまり、ハードウェアまたはソフトウェアの使用は、一般に（常にではないが、特定の状況ではハードウェアとソフトウェアの選択が重要になる場合がある）、コスト対効率のトレードオフに相当する設計上の選択である。本明細書で説明されるプロセス及び／またはシステム及び／または他の技術、例えばハードウェア、ソフトウェア及び／またはファームウェアを実装できる様々な車両が存在し、しかもプロセス及び／またはシステム及び／または他の技術が配備される状況によって、好ましい車両が変化し得る。例えば、速度及び精度が最優先されることを実装者が決定した場合には、実装者は、主にハードウェア及び／またはファームウェアの車両を選択することができ、可撓性が最優先される場合には、実装者は、主にソフトウェア実装を選択することができ、またはさらに代替的に、実装者は、ハードウェア、ソフトウェア及び／またはファームウェアのいくつかの組み合わせを選択することができる。

【0044】

上記の詳細な説明では、ブロック図、フローチャート及び／または実施例を使用して、患者の体温を求めるためのデバイス及び／またはプロセスの様々な実施形態を説明してきた。かかるブロック図、フローチャート及び／または実施例等が１つ以上の機能及び／または演算を含む限り、当業者であれば、かかるブロック図、フローチャートまたは実施例の各機能及び／または演算を、広範囲のハードウェア、ソフトウェア、ファームウェア、またはこれらの実質的に任意の組み合わせによって、個別に及び／または集合的に実装できることを理解するであろう。一実施形態では、本明細書に記載される主題のいくつかの部分は、特定用途向け集積回路（ＡＳＩＣ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）、デジタル信号プロセッサ（ＤＳＰ）、または他の集積形式によって実装することができる。しかしながら、当業者であれば、本明細書に開示する実施形態の一部の態様は、全体的にまたは部分的に、１つ以上のコンピュータ上で実行される１つ以上のコンピュータプログラム（例えば、１つ以上のコンピュータシステム上で実行される１つ以上のプログラム）として、１つ以上のプロセッサ上で実行される１つ以上のプログラム（例えば、１つ以上のマイクロプロセッサ上で実行される１つ以上のプログラム）として、ファームウェアとして、または実質的にそれらの任意の組み合わせとして、集積回路内に等価に実装できることを認識するようになること、ならびに回路を設計すること、及び／またはソフトウェア及び／またはファームウェアのコードを書くことは、本開示を考慮すれば十分、当業者の技術の範囲内である。さらに当業者であれば、本明細書に記載されている主題のメカニズムが様々な形式のプログラム製品として頒布できること、及び本明細書に記載されている主題の例示的な実施形態は、実際に頒布を実行するために使用される信号担持媒体の特定のタイプに関係なく適用されること、を理解するであろう。信号担持媒体の例には、次のもの、すなわち、フロッピーディスク、ハードディスクドライブ、ＣＤ、ＤＶＤ、デジタルテープ、コンピュータメモリ等の記録可能なタイプの媒体、及びデジタル及び／またはアナログ通信媒体（例えば、光ファイバケーブル、導波管、有線通信リンク、無線通信リンク等）等の伝送タイプの媒体が含まれるが、これらに限定されない。

【0045】

当業者であれば、本明細書に記載されたようにデバイス及び／またはプロセスを記述し、その後、エンジニアリング方式を使用して、そのような記述されたデバイス及び／またはプロセスをデータ処理システムに統合することが、当技術分野において一般的であることを認識するであろう。すなわち、本明細書に記載されている装置及び／またはプロセスの少なくとも一部は、合理的な量の実験を経てデータ処理システムに組み込むことができる。当業者は、典型的なデータ処理システムが、一般に、システムユニットハウジング、ビデオディスプレイ装置、揮発性及び不揮発性メモリ等のメモリ、マイクロプロセッサ及びデジタル信号プロセッサ等のプロセッサ、オペレーティングシステム、ドライバ、グラフィカルユーザインターフェース、及びアプリケーションプログラム等の計算エンティティ、タッチパッドまたはスクリーン等の１つ以上のインタラクションデバイス、及び／またはフィードバックループ及び制御モータを含む制御システム（例えば、位置及び／または速度を検出するためのフィードバック、構成要素及び／または量の移動及び／または調整を行うための制御モータ）、のうちの１つ以上を含むことを認識するであろう。典型的なデータ処理システムは、データコンピューティング／通信システム及び／またはネットワークコンピューティング／通信システムに典型的に見られる構成要素等、任意の適切な市販の構成要素を利用して実装することができる。

【0046】

本明細書で説明される主題は、異なる他の構成要素内に含まれる、または異なる他の構成要素と接続される、異なる構成要素を示すことがある。かかる描写されたアーキテクチャは実施例にすぎず、実際に多くの他の同一の機能性を達成するアーキテクチャが実施されることが可能であることが理解される。概念的な意味では、その同一の機能性を達成する構成要素のいかなる配置も、所望の機能性が達成されるように効果的に「関連付け」られる。したがって、本明細書において特定の機能性を達成するように組み合わせられる任意の２つの構成要素は、アーキテクチャまたは中間構成要素に関係なく、所望の機能性が達成されるように、互いに「関連付けられる」と見なされることが可能である。同様に、そのように関連付けられた任意の２つの構成要素も所望の機能を達成するために互いに「動作可能に接続」または「動作可能に結合」されているということもでき、そのように関連付けることができる任意の２つの構成要素も、所望の機能を達成するために互いに「動作可能に結合可能」であるということもできる。動作可能に結合可能な具体例には、物理的に嵌合可能な構成要素及び／または物理的に相互作用する構成要素、及び／または無線で相互作用可能な構成要素及び／または無線で相互作用する構成要素、及び／または論理的に相互作用する構成要素及び／または論理的に相互作用可能な構成要素が含まれるが、これらに限定されない。

【0047】

最後に、本明細書における実質的に全ての複数形及び／または単数形の用語の使用に関して、当業者は、文脈及び／または用途に応じて適切であるように、複数形から単数形へ、及び／または単数形から複数形へ変換することができる。様々な単数形／複数形の置換が、明確化のため本明細書に明示的に記載されている場合がある。

【0048】

概して、本明細書、及び特に特許請求の範囲（例えば、特許請求の範囲の本文）で使用される用語は、概して、「限定されない」用語（例えば、用語「含んでいる」は、「含んでいるがこれに限定されない」、用語「有する」は、「少なくとも有する」、用語「含む」は「含むがこれに限定されない」、等、として解釈されるべきである）として意図されることは当業者には理解されるであろう。当業者であれば、導入された請求項の記載の特定の数が意図されている場合、そのような意図は請求項に明示的に記載され、そのような記載がない場合には、そのような意図は存在しないことが、さらに理解されるであろう。例えば、理解への補助として、以下の特許請求の範囲は、請求項の記述を導入する、導入句である「少なくとも１つの」及び「１つ以上の」の使用を含む場合がある。しかしながら、かかる句の使用は、不定冠詞「ａ」または「ａｎ」による請求項の記述の導入が、その同じ請求項が導入句「１つ以上の」または「少なくとも１つの」及び「ａ」または「ａｎ」のような不定冠詞を含むときであっても（例えば、「ａ」及び／または「ａｎ」は、「少なくとも１つの」または「１つ以上の」を意味すると解釈されるべきである）、かかる導入された請求項の記述を含む任意の特定の記述を１つのかかる記述のみを含む実施形態に限定することを暗示するように解釈されるべきではなく、請求項の記述を導入するために使用される定冠詞の使用に対しても同じことが当てはまる。加えて、導入される請求項の記述の特定の数が明示的に記述される場合、当業者は、かかる記述が少なくとも１つの記述された数（例えば、他の修飾語句なしの「２つの記述」の最低限の記述が、少なくとも２つの記述、または２つ以上の記述を意味する）を意味すると解釈されるべきであることを理解するであろう。さらに、「Ａ、Ｂ、及びＣのうちの少なくとも１つ」に類似した慣例が使用されている場合、一般に、そのような構成は、当業者であれば、この慣例を理解するという意味で意図されるものであり、例えば、「Ａ、Ｂ、及びＣのうちの少なくとも１つを有するシステム」は、Ａ単独で有するシステム、Ｂ単独で有するシステム、Ｃ単独で有するシステム、Ａ及びＢ共に有するシステム、Ａ及びＣ共に有するシステム、Ｂ及びＣ共に有するシステム、及び／またはＡ、Ｂ、及びＣ共に有するシステム等を含むが、これらに限定されない。「Ａ、Ｂ、またはＣのうちの少なくとも１つ」に類似した慣例が使用されている場合、一般に、そのような構成は、当業者であれば、この慣例を理解するという意味で意図されるものであり、例えば、「Ａ、Ｂ、またはＣのうちの少なくとも１つを有するシステム」は、Ａ単独で有するシステム、Ｂ単独で有するシステム、Ｃ単独で有するシステム、Ａ及びＢ共に有するシステム、Ａ及びＣ共に有するシステム、Ｂ及びＣ共に有するシステム、及び／またはＡ、Ｂ、及びＣ共に有するシステム等を含むが、これらに限定されない。当業者には、さらに、明細書、特許請求の範囲、または図面のいずれにおいても、２つ以上の代替的な用語を提示する実質的に任意の接続詞的な単語及び／または語句は、用語の１つ、用語のいずれか、または両方の用語を含む可能性を想定していると理解されるべきであることが理解されよう。例えば「ＡまたはＢ」という語句は、「Ａ」または「Ｂ」または「Ａ及びＢ」の可能性を含むものと解される。

【0049】

また、本開示の特徴または態様がマーカッシュグループに関して記載される場合、当業者は、本開示が、それにより、そのマーカッシュグループの任意の個別の構成要因または構成要因のサブグループに関しても記載されていることを理解するであろう。

【0050】

前述のことから、本開示の様々な実施形態が、本明細書に例示の目的で記載されており、本開示の範囲及び趣旨から逸脱することなく、様々な修正が行われ得ることが理解されよう。したがって、本明細書に開示された種々の実施形態は、限定することを意図しておらず、真の範囲及び趣旨は、以下の特許請求の範囲によって示される。

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【国際調査報告】