(57)【要約】【課題】  階層データに基づくデバイス制御を提供する。【解決手段】  幾つかの例では、計算デバイスは、複数のレベルを含む階層構造を有する階層データを受信し得る。計算デバイスは、少なくとも部分的に階層データに基づいて複数の特徴を特定し得、且つ階層構造内の次の上位レベルに統合する候補として、第１のレベルにおける特徴のサブセットを選択し得る。計算デバイスは、特徴のサブセットの統合からの情報の予測損失が閾値未満であると判断し得、且つ特徴のサブセットではなく、次の上位レベルにおける統合特徴を含むように階層構造を改訂し得る。幾つかの例では、統計モデルは、改訂された階層構造に基づいてトレーニングされ得、且つ少なくとも部分的に判断を行い、通知を送信し、及び／又はデバイスを制御するために使用され得る。【選択図】図１
2018032394.tif 000002
【特許請求の範囲】
【請求項１】
１つ又は複数のプロセッサと、
実行可能命令を保持する１つ又は複数の非一時的コンピュータ可読媒体と
を備え、
前記実行可能命令は、前記１つ又は複数のプロセッサにより実行されると、
複数の階層レベルを含む階層構造を有する階層データを受信することと、
少なくとも部分的に前記階層データに基づいて複数の特徴を特定することと、
前記階層構造内の次の上位レベルに統合する候補として前記特徴のサブセットを選択することと、
前記特徴のサブセットの統合からの情報の予測損失が第１の閾値未満であると判断することと、
前記特徴のサブセットではなく、統合特徴を含むように前記階層構造を改訂することと、
前記統合特徴を含む前記改訂された階層構造に基づいて統計モデルをトレーニングすることと、
データを受信して前記統計モデルに適用することと、
前記統計モデルの出力を特定することと、
計算デバイスへの通知若しくは決定、又は
デバイスを制御する、デバイスへの制御信号
のうちの少なくとも１つを送信することと
を含む動作を実行するように前記１つ又は複数のプロセッサをプログラムする、システム。
【請求項２】
前記特徴のサブセットの統合からの前記情報の予測損失が第１の閾値未満であると判断する前記動作は、
少なくとも部分的に前記統計モデルの標的変数の特性に基づいて評価関数を選択することと、
統合なしの前記特徴のサブセットに対する前記評価関数の第１の結果と、前記特徴のサブセットを統合した状態での前記評価関数の第２の結果とを計算することと、
前記第１の結果と前記第２の結果との差が前記第１の閾値未満であると判断することと
を含む、請求項１に記載のシステム。
【請求項３】
前記特徴のサブセットの統合からの前記情報の予測損失が第１の閾値未満であると判断することは、
前記選択された評価関数について、情報の合計損失に対応する第２の閾値を決定することと、
少なくとも部分的に前記第１の結果と前記第２の結果との前記差に基づいて、前記統合での前記情報の予測損失を特定することと、
前記統合での前記情報の予測損失に、前記階層データ内の他の特徴の他の統合での情報の予測損失を加えたものが前記第２の閾値未満であると判断することと
を含む、請求項２に記載のシステム。
【請求項４】
前記動作は、
少なくとも部分的に、異なる統計モデルの異なる標的変数の特性に基づいて、異なる評価関数を選択することと、
統合なしの前記特徴のサブセットに対する前記異なる評価関数の第１の結果と、前記特徴のサブセットを統合した状態での前記異なる評価関数の第２の結果とを計算することと、
前記異なる評価関数の前記第１の結果と前記異なる評価関数の前記第２の結果との差が別の統合閾値未満であると判断することと
を更に含む、請求項２に記載のシステム。
【請求項５】
前記動作は、
前記特徴のサブセットではなく、少なくとも１つの統合特徴を含む別の改訂された階層構造を生成するように前記階層構造を改訂することと、
前記他の改訂された階層構造に基づいて異なる統計モデルをトレーニングすることと、
データを受信して前記他の統計モデルに適用することと、
前記他の統計モデルの出力を特定することと
を更に含む、請求項４に記載のシステム。
【請求項６】
階層データを受信する前記動作は、複数の患者のセンサデータ及び介護者記録を受信することを含み、前記センサデータは、複数の患者デバイスから取得され、且つ前記介護者記録は、介護者デバイスに手動入力される個々の患者に関連するデータを含み、
前記データを受信して前記統計モデルに適用する前記動作は、第１の患者に対応するセンサデータ及び介護者記録を受信することを含み、及び
前記送信する動作は、
前記第１の患者に関連する通知若しくは決定を介護者計算デバイスに送信すること、又は
前記患者デバイスを制御する制御信号を前記第１の患者に関連付けられた患者デバイスに送信すること
のうちの少なくとも１つを含む、請求項１に記載のシステム。
【請求項７】
前記動作は、
前記特徴のサブセットの１つ又は複数の共通特性に基づいて集約関数を特定することと、
前記集約関数を使用して前記特徴のサブセットを集約することにより、前記集約関数を使用して新しい統合特徴を特定することと、
少なくとも部分的に集約なしの前記特徴のサブセットと前記新しい統合特徴との差に基づいて、前記情報の予測損失を特定することと
を更に含む、請求項１に記載のシステム。
【請求項８】
プロセッサにより、階層構造を有する階層データを受信することと、
少なくとも部分的に前記階層データに基づいて複数の特徴を特定することと、
前記階層構造内で統合する候補として前記特徴のサブセットを選択することと、
前記特徴のサブセットの統合からの情報の予測損失が第１の閾値未満であると判断することと、
前記特徴のサブセットではなく、統合特徴を含むように前記階層構造を改訂することと
を含む、方法。
【請求項９】
前記統合特徴を含む前記改訂された階層構造に基づいて統計モデルをトレーニングすることと、
データを受信して前記統計モデルに適用することと、
前記統計モデルの出力を特定することと、
前記出力に基づいて少なくとも１つの通信を送信することと
を更に含む、請求項８に記載の方法。
【請求項１０】
前記特徴のサブセットの統合からの前記情報の予測損失が第１の閾値未満であると判断することは、
少なくとも部分的に前記統計モデルの標的変数の特性に基づいて評価関数を選択することと、
統合なしの前記特徴のサブセットに対する前記評価関数の第１の結果と、前記特徴のサブセットを統合した状態での前記評価関数の第２の結果とを計算することと、
前記第１の結果と前記第２の結果との差が前記第１の閾値未満であると判断することと
を含む、請求項８に記載の方法。
【請求項１１】
前記選択された評価関数について、情報の合計損失に対応する第２の閾値を決定することと、
少なくとも部分的に前記第１の結果と前記第２の結果との前記差に基づいて、前記統合での前記情報の予測損失を特定することと、
前記統合での前記情報の予測損失に、前記階層データ内の他の特徴の他の統合での情報の予測損失を加えたものが前記第２の閾値未満であると判断することと
を更に含む、請求項１０に記載の方法。
【請求項１２】
少なくとも部分的に、異なる統計モデルの異なる標的変数の特性に基づいて、異なる評価関数を選択することと、
統合なしの前記特徴のサブセットに対する前記異なる評価関数の第１の結果と、前記特徴のサブセットを統合した状態での前記異なる評価関数の第２の結果とを計算することと、
前記異なる評価関数の前記第１の結果と前記異なる評価関数の前記第２の結果との差が別の統合閾値未満であると判断することと
を更に含む、請求項１０に記載の方法。
【請求項１３】
前記特徴のサブセットの１つ又は複数の共通特性に基づいて集約関数を特定することと、
前記集約関数を使用して前記特徴のサブセットを集約することにより、前記集約関数を使用して新しい統合特徴を特定することと、
少なくとも部分的に集約なしの前記特徴のサブセットと前記新しい統合特徴との差に基づいて、前記情報の予測損失を特定することと
を更に含む、請求項８に記載の方法。
【請求項１４】
前記統合特徴を他の特徴と統合する場合の情報の予測損失が前記第１の閾値未満であると判断することと、
前記統合特徴の階層レベルの上の階層レベルに前記統合特徴及び前記他の特徴を統合することと
を更に含む、請求項８に記載の方法。
【請求項１５】
１つ又は複数のプロセッサと、
実行可能命令を保持する１つ又は複数の非一時的コンピュータ可読媒体と
を備え、
前記実行可能命令は、前記１つ又は複数のプロセッサにより実行されると、
複数の階層レベルを含む階層構造を有する階層データを受信することと、
少なくとも部分的に前記階層データに基づいて複数の特徴を特定することと、
前記階層構造内の次の上位レベルに統合する候補として前記特徴のサブセットを選択することと、
前記特徴のサブセットの統合からの情報の予測損失が閾値未満であると判断することと、
前記特徴のサブセットではなく、統合特徴を含むように前記階層構造を改訂することと
を行うように前記１つ又は複数のプロセッサをプログラムする、システム。
【請求項１６】
前記１つ又は複数のプロセッサは、
前記改訂された階層構造に基づいて統計モデルをトレーニングすることと、
データを受信して前記統計モデルに適用することと、
前記統計モデルの出力を特定することと、
前記出力に基づいて、デバイスを制御する少なくとも１つの信号を送信することと
を行うように更にプログラムされる、請求項１５に記載のシステム。
【請求項１７】
前記特徴のサブセットの統合からの前記情報の予測損失が第１の閾値未満であると判断することは、
少なくとも部分的に前記統計モデルの標的変数の特性に基づいて評価関数を選択することと、
統合なしの前記特徴のサブセットに対する前記評価関数の第１の結果と、前記特徴のサブセットを統合した状態での前記評価関数の第２の結果とを計算することと、
前記第１の結果と前記第２の結果との差が前記第１の閾値未満であると判断することと
を含む、請求項１５に記載のシステム。
【請求項１８】
前記１つ又は複数のプロセッサは、
前記選択された評価関数について、情報の合計損失に対応する第２の閾値を決定することと、
少なくとも部分的に前記第１の結果と前記第２の結果との前記差に基づいて、前記統合での前記情報の予測損失を特定することと、
前記統合での前記情報の予測損失に、前記階層データ内の他の特徴の他の統合での情報の予測損失を加えたものが前記第２の閾値未満であると判断することと
を行うように更にプログラムされる、請求項１７に記載のシステム。
【請求項１９】
前記１つ又は複数のプロセッサは、
少なくとも部分的に前記候補特徴の１つ又は複数の共通特性に基づいて集約関数を決定することと、
前記集約関数を使用して前記候補特徴を集約することにより、前記集約関数を使用して新しい統合特徴を特定することと、
少なくとも部分的に集約なしの前記候補特徴と前記新しい統合特徴との差に基づいて、前記情報の予測損失を特定することと
を行うように更にプログラムされる、請求項１７に記載のシステム。
【請求項２０】
前記１つ又は複数のプロセッサは、
前記統合特徴を他の特徴と統合する場合の情報の予測損失が前記第１の閾値未満であると判断することと、
前記統合特徴の前記階層レベルの上の階層レベルに前記統合特徴及び前記他の特徴を統合することと
を行うように更にプログラムされる、請求項１５に記載のシステム。
【発明の詳細な説明】
【背景技術】
【０００１】
病院及び他の医療ケア施設内の患者は、往々にして、様々な体の状態をモニタリングする複数の様々なタイプの医療デバイスに接続されるか、又は他の方法で医療デバイスによりモニタリングされ得る。これらのモニタはそれぞれ、患者についての情報を提供する１つ又は複数のセンサ及び処理構成要素を含み得る。更に、患者は、１つ又は複数の病状に治療を提供する医療デバイスにより治療され得る。これらのデバイスは、デバイスの動作を示すセンサデータを提供することもできる。更に、看護師、医師、医師アシスタント、及び他の医療専門家等の介護者も、介護者記録として患者についての情報を記録し得る。介護者記録に含め得る情報の例としては、患者の状態、予後、治療計画、処方、薬剤のタイプ、薬剤の頻度、実行されたテスト、介護者観察等を挙げ得る。
【０００２】
この膨大な量のデータにもかかわらず、患者の治療は、多くの場合、介護者により手動管理され得る所定の治療レジメンに基づいて実行される。例えば、介護者は、治療デバイス及び他の医療デバイスを手動でオン及びオフすることを担当し得る。更に、介護者の判断は、通常、特定の患者に治療を施すタイミング及び頻度の決定に使用され得る。しかし、介護者は、治療のタイミング、患者の予後、長期ケアプラン、再入院の確率等を特定する場合、利用可能なデータの全てを考慮に入れることができないことがある。
【発明の概要】
【課題を解決するための手段】
【０００３】
幾つかの実施形態は、階層データに基づいて分析を実行し、通知を送信し、判断し、且つ／又はデバイスを制御する装置及び技法を含む。一例として、計算デバイスは、複数の階層レベルを含む階層構造を有する階層データを受信し得る。計算デバイスは、少なくとも部分的に階層データに基づいて複数のモデル特徴を特定し得、且つ階層構造内の次の上位レベルに統合する候補として、第１のレベルにおける特徴のサブセットを選択し得る。計算デバイスは、特徴のサブセットの統合からの情報の予測損失が閾値未満であると判断し得、且つ特徴のサブセットではなく、次の上位レベルにおける統合特徴を含むように階層構造を改訂し得る。幾つかの例では、統計モデルは、改訂された階層構造に基づいてトレーニングされ得、且つ少なくとも部分的に判断を行い、通知を送信し、及び／又はデバイスを制御するために使用され得る。
【０００４】
詳細な説明が添付図を参照して記載される。図中、参照番号の１つ又は複数の最も左側の桁は、参照番号が最初に出現する図を識別する。異なる図での同じ参照番号の使用は、同様又は同一の物品又は特徴を示す。
【図面の簡単な説明】
【０００５】
【図１】幾つかの実施形態による、デバイスを制御し、且つ／又は通知若しくは他の情報を出力として提供することができるシステムのアーキテクチャ例を示す。
【図２】幾つかの実施形態による、階層データを含むデータ構造例を示す。
【図３】幾つかの実施形態による、階層データ関係を表すツリーデータ構造の例を示す。
【図４】幾つかの実施形態による、統計モデルと併用されるトレーニングデータセットのデータ構造例を示す。
【図５Ａ】幾つかの実施形態による、特徴が上位レベルノードに統合されるツリーデータ構造の例を示す。
【図５Ｂ】幾つかの実施形態による、特徴が上位レベルノードに統合されるツリーデータ構造の例を示す。
【図６】幾つかの実施形態による、特徴の統合を終了した後のツリーデータ構造例を示す。
【図７】幾つかの実施形態による、統合される特徴を決定するプロセス例を示す流れ図である。
【図８】幾つかの実施形態による、選択された特徴を統合するか否かを判断するために図７のブロック７１６において実行され得るプロセス例を示す流れ図である。
【図９】幾つかの実施形態による、評価関数を選択することを含むプロセス例を示す流れ図である。
【図１０】幾つかの実施形態による、患者デバイスを制御し、且つ／又は患者の状態を特定するプロセス例を示す流れ図である。
【発明を実施するための形態】
【０００６】
本明細書における幾つかの実施形態は、大量のデータを考慮して、治療デバイスの動作に関する決定を行い、及び／又は患者ケアに関する判断を行う技法及び装置に関する。一例として、患者デバイスからのセンサデータ及び介護者記録からの情報は、人間が完全には分析できない多数のデータ入力として受信し得る。データ入力は、治療デバイスのオン又はオフ、治療デバイスでの設定の変更、アラート又は他の通知の介護者への送信、患者の治療有効性についての判断実施、患者の予後についての判断実施、患者が再入院する確率に関する判断実施等の動作をモデルの出力に基づいて実行する管理アプリケーションにより、使用され得る出力を提供する統計モデル内の特徴として使用され得る。
【０００７】
統計モデルの特徴数（例えば、別個のデータ入力数）は非常に大きくなり得る（数百、数千、又はそれよりも多くの数等）ため、本明細書における実施形態は、上記機能に向けて統計モデルをトレーニング及び使用する前に、統計モデルの特徴を結合又は他の方法で統合しようとし得る。例えば、統計モデルの結果に実質的に影響を及ぼさずに統計モデルで計算すべき特徴数を低減することにより、本明細書における実施形態は、計算デバイスが統計モデルをより高速で実行できるようにし、それにより、統計モデルの計算を実行する計算デバイスの動作を改善する。更に、幾つかの例では、本明細書における特徴統合技法は、動作パラメータのより高速の決定の提供及び／又は医療デバイス又は他のデバイスのより大きい自律制御を可能にすることによる等、動作の制御に統計モデルの出力に依存する医療デバイス又は他のデバイスの動作を改善する。
【０００８】
本明細書における幾つかの例は、機械学習を利用し、多数の特徴に基づいて結果を予測する。更に、これらの特徴のうちの少なくとも幾つかは、１つ又は複数のデータ階層に編成し得る。更に、データ階層内の同じ階層レベル及び同じ中間上位レベルノード下の特徴は、予測のために元情報の大半を保持し、一方、特徴の階層編成も尊重するように、中間上位レベルノードに結合及び統合され得る。複数の特徴のセットを１セット当たりの特徴にロールアップ又は他の方法で統合することにより、本明細書における例は、モデルをトレーニングするため及びモデルを実行して結果を得るための両方のために、統計モデリングの計算負荷を低減する。更に、特徴の数がより少ないことにより、より低い処理コストでより複雑なモデル等の残りの特徴のより完全な調査が可能になり得る。
【０００９】
一例として、サービス計算デバイスは、特徴セット内の特徴サブセットを統合するか否かを判断する際、以前選択されなかった内部ノードの中から最大深度の内部ノードｎを選択し得る。複数のそのようなノードがある場合、依然として選択されていない内部ノードｎの１つをランダムに又は他の考慮事項に基づいて選択し得る。特徴は、データ階層を表すツリーデータ構造の終端ノード（「リーフノード」とも呼ばれる）に対応し得る。最大深度の選択された内部ノードｎについて、ｎの子孫である終端ノードは、「ｎ下の特徴」に対応する。選択された内部ノードｎから下った終端ノードが結合可能な場合、計算デバイスは、ｎ下のノードを別個のまま保つか、それともこれらの特徴をロールアップ又は他の方法で統合するかを続けて判断し得る。後述するように、計算デバイスは、選択された特徴の統合が、特徴により提供される情報量に実質的に影響するか否かを判断し得る。計算デバイスにより、提供される情報に統合が実質的に影響しないと判断される場合、計算デバイスは、ｎにおけるサブツリーを、統合特徴を有する終端ノードで置換し得る。計算デバイスは、予測される情報損失の閾値レベルに基づいて追加の特徴を統合するか否かを判断し得る。
【００１０】
本明細書における実施形態は、この技法を適用して、幾つかのサブツリーが終端ノードに変換されるように、データ階層内の特徴数を低減し得る。統計モデルのトレーニングデータセットは、統合された終端ノードに対応する新しい特徴を取得し、それらのサブツリー下に元々あった特徴を失う。別の例として、元の特徴が複数のデータ階層に編成される場合、本明細書における幾つかの実施形態は、特徴低減技法を各データ階層に別個に適用され得る。更に、本明細書における幾つかの例は、ツリーデータ構造及び関連する技法を使用して、特徴のデータ階層を記述するが、本明細書における例はツリーに限定されず、情報の階層表現を可能にする任意のタイプのデータ構造を包含し得る。
【００１１】
ｎ下の特徴を特徴の何らかの集約関数（例えば、合計、平均等）で置換するか否かを判断するために、幾つかの例は、標的変数「ｙ」を予測するための情報の予測される絶対的又は相対的損失を評価することを含み得る。例えば、情報の予測損失は、相互情報評価関数、Ｒ二乗評価関数、又はクラス間／クラス内評価関数に基づく等、ｙを予測する特徴セットの値に基づいて測定し得る。特徴の統合は、情報の予測損失が第１の閾値未満の場合且つ情報の合計累積絶対損失が第２の閾値を超えない場合に実行され得る。更に、幾つかの例は、同じアプリケーション内の異なる情報測度に基づいて異なる評価関数を使用し得る。適切な情報測度の選択は、標的変数の特性及び統合に考慮される特徴の特性に依存する。
【００１２】
単に特定の特徴をフィルタリングして除去するのではなく、本明細書における実施形態は、特徴を統合して、階層データ内の元の特徴の階層編成を尊重しながら、新しい統合特徴を構築する。更に、必要に応じて、初期特徴統合を適用した後、追加の反復で追加の特徴統合を実行し得る。
【００１３】
幾つかの実施形態は、複数の特徴に基づいて結果を予測し得る。ＩＣＵ又は他の治療施設での患者の臨床観察、トピックにより階層に編成される文書、ウェブサイトへのユーザ訪問についての検索エンジンデータ等を含め、本明細書における技法から恩恵を受け得る階層特徴を含む多くのデータセット例がある。更に、幾つかの実施形態は、統計モデルを当てはめて、標的変数を予測する前に前処理段階を提供する。例えば、幾つかの例は、階層構造を尊重しながら、予測に元情報の大半を保持するように階層内の特徴を選択的に統合する。したがって、本明細書における技法を使用して、統計モデルのトレーニング及び使用中、計算負荷を低減し得、統計モデルを実行する計算デバイスをより高速且つより効率的に実行できるようにし得る。更に、統計モデルの出力に基づいて制御される医療デバイス又は他のデバイスをより高速且つより正確に制御し得る。
【００１４】
考察を目的として、幾つかの実施形態例は、センサデータ及び介護者記録等の階層データを受信し、階層データを統計モデルに適用して、介護者の計算デバイスに送信される通知及び／又は患者デバイスを制御するために送信される制御信号等の出力を提供する１つ又は複数の計算デバイスの環境で説明される。しかし、本明細書における実施形態は、提供される特定の例に限定されず、本明細書における開示に鑑みて当業者に明らかであるように、他のタイプのデータ、他のタイプの環境、他のシステムアーキテクチャ、他のタイプの数学的モデル等に拡張され得る。例えば、幾つかの例は、医療ケアを患者に提供する環境において説明されるが、本明細書における実施形態は、この環境に限定されず、階層データを統計モデルに適用して、デバイスの制御、通知の提供、判断の実施等に有用な出力を決定し得る他の環境に拡張され得る。
【００１５】
図１は、幾つかの実施形態による、デバイスを制御し、且つ／又は通知若しくは他の情報を出力として提供することができるシステム１００のアーキテクチャ例を示す。システム１００は、１つ又は複数のネットワーク１０６を通して等、１つ又は複数の患者ロケーション１０４と通信可能な少なくとも１つのサービス計算デバイス１０２を含む。更に、サービス計算デバイス１０２は、１つ又は複数のネットワーク１０６を通して１つ又は複数の介護者計算デバイスｌ０８及び１つ又は複数の施設計算デバイス１１０と通信し得ることが可能であり得る。
【００１６】
別の例では、サービス計算デバイス１０２は、１つ又は複数のサーバ、パーソナルコンピュータ、又は任意の数の方法で実施され得る他のタイプの計算デバイスを含み得る。例えば、サーバの場合、モジュール、他の機能構成要素、及びデータ記憶装置の少なくとも一部は、サーバのクラスタ、サーバファーム又はデータセンタ、クラウドホスト計算サービス等の少なくとも１つのサーバで実施され得るが、他のコンピュータアーキテクチャを追加又は代替として使用し得る。示される例では、サービス計算デバイス１０２は、１つ又は複数のプロセッサ１１２、１つ又は複数の通信インタフェース１１４、及び１つ又は複数のコンピュータ可読媒体１１６を含むか、又はそれらに関連付けられ得る。
【００１７】
各プロセッサ１１２は、単一の処理ユニット若しくは幾つかの処理ユニットであり得、１つ若しくは複数の計算ユニット又は複数の処理コアを含み得る。プロセッサ１１２は、１つ又は複数の中央演算処理装置、マイクロプロセッサ、マイクロコンピュータ、マイクロコントローラ、デジタル信号プロセッサ、状態機械、論理回路、及び／又は動作命令に基づいて信号を操作する任意のデバイスとして実施することができる。例えば、プロセッサ１１２は、本明細書に記載されるアルゴリズム及びプロセスを実行するように特にプログラム又は構成される任意の適するタイプの１つ又は複数のハードウェアプロセッサ及び／又は論理回路であり得る。プロセッサ１１２は、本明細書に記載される機能を実行するようにプロセッサ１１２をプログラムすることができる、コンピュータ可読媒体１１６に記憶されたコンピュータ可読命令をフェッチし且つ実行するように構成することができる。
【００１８】
コンピュータ可読媒体１１６は、コンピュータ可読命令、データ構造、プログラムモジュール、又は他のデータ等の情報を記憶する任意のタイプの技術で実施される揮発性及び不揮発性メモリ及び／又はリムーバブル及び非リムーバブル媒体を含み得る。例えば、コンピュータ可読媒体１１６は、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、フラッシュメモリ、又は他のメモリ技術、光学記憶装置、固体状態記憶装置、磁気テープ、磁気ディスク記憶装置、ＲＡＩＤストレージシステム、ストレージアレイ、ネットワーク接続ストレージ、ストレージエリアネットワーク、クラウドストレージ、又は所望の情報の記憶に使用することができ、計算デバイスによりアクセスすることができる任意の他の媒体を含み得るが、これらに限定されない。サービス計算デバイス１０２の構成に応じて、コンピュータ可読媒体１１６は、言及される場合、非一時的コンピュータ可読媒体がエネルギー、搬送信号、電磁波、及び／又は信号それ自体等の媒体を除外する限り、有形非一時的媒体であり得る。幾つかの場合、コンピュータ可読媒体１１６は、サービス計算デバイス１０２と同じ場所にあり得、一方、他の例では、コンピュータ可読媒体１１６は部分的にサービス計算デバイス１０２からリモートであり得る。
【００１９】
コンピュータ可読媒体１１６を使用して、プロセッサ１１２により実行可能な任意の数の機能構成要素を記憶し得る。多くの実施形態では、これらの機能構成要素は、プロセッサ１１２により実行可能であり、実行されると、本明細書においてサービス計算デバイス１０２に起因する動作を実行するようにプロセッサ１１２を特にプログラムする命令又はプログラムを含む。コンピュータ可読媒体１１６に記憶された機能構成要素は、管理アプリケーション１１８及びオペレーティングシステム（ＯＳ）１２０を含み得る。管理アプリケーション１１８は、患者ステータスのモニタリング、アラート、情報、又は他の通知の介護者への提供、及び／又は患者デバイスの制御等の様々なタスクをプロセッサ１１２に実行させるように実行可能な１つ又は複数のコンピュータプログラム、コンピュータ可読命令、実行可能コード、又はその部分を含み得る。更に、オペレーティングシステム１２０は、サービス計算デバイス１０２の様々な機能を制御及び管理し得る。幾つかの場合、機能構成要素は、コンピュータ可読媒体１１６の記憶部分に記憶され、コンピュータ可読媒体１１６のローカルメモリ部分にロードされ、１つ又は複数のプロセッサ１１２により実行され得る。本明細書における開示の恩恵を受ける当業者には、多くの他のソフトウェア構成及び／又はハードウェア構成が明らかになるであろう。
【００２０】
更に、コンピュータ可読媒体１１６は、本明細書に記載される機能及びサービスの実行に使用されるデータ及びデータ構造を記憶し得る。例えば、コンピュータ可読媒体１１６は、管理アプリケーション１１８により使用され得るセンサデータ１２２、介護者記録１２４、１つ又は複数の統計モデル１２６、トレーニングデータ１２８、モデル特徴統合情報１３０、及び階層データ構造１３２を記憶し得る。例えば、管理アプリケーション１１８は、センサデータ１２２及び介護者記録１２４を１人又は複数の患者から受信し得、１つ又は複数の統計モデル１２６内のこの情報を使用して、各患者についての情報を特定し得る。
【００２１】
更に後述するように、管理アプリケーション１１８は、１つ又は複数の統計モデル１２６を使用して、患者デバイスの制御、介護者へのアラート又は他の通知の送信、患者ケアのモニタリング、患者結果の予測等の機能を実行し得る。幾つかの例では、トレーニングデータ１２８は、施設計算デバイス１１０に関連する記憶装置１３８から受信される複数の過去の患者の過去センサデータ１３４及び過去介護者記録１３６を含み得る。トレーニングデータ１２８は、階層データとして受信し得、階層データ構造１３２として配置される。管理アプリケーションは、モデル特徴統合情報１３０を使用して、１つ又は複数の統計モデル１２６で使用すべき階層データ構造１３２内の幾つかの特徴を結合及び統合し得る。サービス計算デバイス１０２は、プログラム、ドライバ等を含み得る他の機能構成要素及びデータ並びに機能構成要素により使用又は生成される他のデータを包含又は保持することもできる。更に、サービス計算デバイス１０２は、多くの他の論理的、プログラム的、及び物理的構成要素を含み得、そのうちの上述されたものは、本明細書における考察に関連する単なる例である。
【００２２】
通信インタフェース１１４は、１つ又は複数のネットワーク１０６を介する等、様々な他のデバイスとの通信を可能にする１つ又は複数のインタフェース及びハードウェア構成要素を含み得る。したがって、通信インタフェース１１４は、患者ロケーション１０４、介護者計算デバイス１０８、及び施設計算デバイス１１０と通信するためのネットワーク１０６への接続を提供する１つ又は複数のポートを含み得るか、又は結合し得る。例えば、通信インタフェース１１４は、本明細書の他の箇所で更に列挙されるように、ＬＡＮ（ローカルエリアネットワーク）、ＷＡＮ（広域ネットワーク）、インターネット、ケーブルネットワーク、セルラネットワーク、無線ネットワーク（例えば、Ｗｉ−Ｆｉ）及び有線ネットワーク（例えば、光ファイバ、Ｅｔｈｅｒｎｅｔ、ファイバチャネル）、直接接続、及びＢＬＵＥＴＯＯＴＨ（登録商標）等の近距離通信等のうちの１つ又は複数を通して通信を可能にし得る。
【００２３】
患者ロケーション１０４は、患者の部屋又は患者を治療し得る任意の他のロケーションであり得る。幾つかの例では、各患者ロケーションｌ０４は、１つ又は複数の患者モニタリングデバイス１４０及び／又は１つ又は複数の患者治療デバイス１４２を含み得る複数の患者デバイスを含み得る。更に、患者デバイスセンサ１４４をモニタリングデバイス１４０及び／又は治療デバイス１４２に関連付けて、患者の状態、モニタリングデバイス１４０の状態、及び／又は治療デバイス１４２の状態を検出する等を行い得る。一例として、少なくとも１人の患者１４６が各患者ロケーション１０４に存在し得、モニタリングデバイス１４０によりモニタリングされ得、治療デバイス１４２により治療され得る。更に、幾つかの場合、患者治療デバイス１４２は、患者モニタリングデバイス１４０であってもよく、患者の状態についてのセンサデータを提供するセンサ１４４のうちの１つ又は複数を含み得る。
【００２４】
幾つかの例では、各患者デバイス１４０、１４２は、ネットワーク１０６を介してサービス計算デバイス１０２と通信することができ、それにより、センサデータ１２２をサービス計算デバイス１０２に送信する等を行い得る。他の例では、患者デバイス１４０、１４２の一方は、患者ロケーション１０４における他方の患者デバイス１４０、１４２からセンサデータ１２２を収集し、センサデータ１２２をサービス計算デバイス１０２に送信する計算デバイスを含み得る。幾つかの例として、患者モニタリングデバイス１４０は、心臓モニタ、パルスオキシメータ、カプノグラフモニタ、呼吸数モニタ、神経モニタ、血糖値モニタ、胎児モニタ、体温モニタ、血液動態モニタ、及び／又は様々な他のタイプのモニタリングデバイスを含み得る。更に、患者治療デバイス１４２は、人工呼吸器、静脈内（ＩＶ）注入ポンプ、ペースメーカー、胸腔チューブ、補給チューブ、麻酔器、人工心肺装置、透析装置、導尿カテーテル、除細動器、及び／又は様々な他のタイプの治療デバイスを含み得る。
【００２５】
介護者計算デバイス１０８及び施設計算デバイス１１０は、デスクトップ、ワークステーション、サーバ、ラップトップ、タブレット計算デバイス、モバイルデバイス、スマートフォン、ウェアラブルデバイス、又はネットワークを介してデータを送信可能な任意の他のタイプの計算デバイス等の任意の適するタイプの計算デバイスであり得る。幾つかの場合、介護者計算デバイス１０８及び／又は施設計算デバイス１１０は、サービス計算デバイス１０２に関して説明したものと同様であるが、本明細書において考察される様々な機能を実行できるようにする異なるデータ及び機能構成要素を有するハードウェア構成を含み得る。一例として、介護者計算デバイス１０８は、患者ロケーション１０４訪問時に介護者１４８が携帯するタブレット又はラップトップ等のポータブル計算デバイスであり得、施設計算デバイス１１０は、例えば、ケア施設又は別のロケーションにオンサイトで配置されるサーバ、ワークステーション、デスクトップコンピュータ等であり得る。
【００２６】
幾つかの場合、施設計算デバイス１１０は、患者記録を記憶装置１３８に記憶するサーバであり得、患者記録は、複数の患者１４６について過去に収集され、１つ又は複数の統計モデル１２６のトレーニングデータ１２８として使用され得る過去介護者記録１３６及び過去センサデータ１３４を含み得る。更に、幾つかの例では、施設計算デバイス１１０のうちの１つ又は複数は、患者ロケーション１０４が、例えば、ＩＣＵ等に配置されるケア施設内の中央ロケーション等における、ケア施設での個々の患者のモニタリングを可能にするモニタリング計算デバイスであり得る。介護者計算デバイス１０８は、ディスプレイ１５０を含み得、施設計算デバイス１１０はディスプレイ１５２を含み得る。多くの他の変形形態が本明細書における開示の恩恵を受ける当業者に明らかになるであろう。
【００２７】
幾つかの例では、看護師、医師、医師のアシスタント、付添人、又は他の医療専門家等の介護者１４８は、患者ロケーション１０４にいる患者１４６を訪問し得、介護者計算デバイス１０８を使用して、特定の患者１４６の介護者記録１２４を入力するか、又は他の方法で生成し得る。例えば、介護者記録１２４は、患者の状態、患者モニタリングデバイス１４０の設定又は出力、患者治療デバイス１４２の設定又は出力、介護者観察等に関連し得る。幾つかの例では、介護者記録１２４は、介護者１４８が書式での選択等を行えるようにすることによる等、構造化データとして構造化されて入力され得る。代替的には、他の例では、介護者記録１２４は、受信後、サービス計算デバイス１０２又は施設計算デバイス１１０により分析し得る手書き記録、タイプ入力された記録、又は他の方式での自由形式データであり得る。介護者記録１２４は、介護者１４８による入力時、介護者１４８が特定の患者１４６に面会し終えたとき、介護者のシフト終了時等のときに各介護者計算デバイス１０８によりサービス計算デバイス１０２に送信され得る。代替的には、介護者記録１２４はまず、施設計算デバイス１１０に送信され得、施設計算デバイス１１０から、サービス計算デバイス１０２に送信され得る。同様に、幾つかの例では、施設計算デバイス１１０はまず、センサデータ１２２を受信し得、センサデータ１２２をサービス計算デバイス１０２に転送し得る。
【００２８】
１つ又は複数のネットワーク１０６は、イントラネット等のローカルエリアネットワーク（ＬＡＮ）、インターネット等の広域ネットワーク（ＷＡＮ）、セルラネットワーク等の無線ネットワーク、Ｗｉ−Ｆｉ等のローカル無線ネットワーク、及び／又はＢＬＵＥＴＯＯＴＨ（登録商標）等の近距離無線通信、光ファイバ、Ｅｔｈｅｒｎｅｔ、ファイバチャネル、若しくは任意の他のそのようなネットワークを含む有線ネットワーク、直接有線接続、又はそれらの任意の組合せを含め、任意のタイプのネットワークを含み得る。したがって、１つ又は複数のネットワーク１０６は、有線通信技術及び／又は無線通信技術の両方を含み得る。そのような通信に使用される構成要素は、少なくとも部分的にネットワークのタイプ、選択された環境、又は両方に依存することができる。そのようなネットワークを介して通信するためのプロトコルは、周知であり、本明細書では詳述しない。したがって、サービス計算デバイス１０２、患者ロケーション１０４、介護者デバイス１０８、及び施設計算デバイス１１０は、有線又は無線接続及びそれらの組合せを使用して、１つ又は複数のネットワーク１０６を介して通信することが可能である。
【００２９】
図１の例では、管理アプリケーション１１８を実行して、過去センサデータ１３４及び過去介護者記録１３６をトレーニングデータ１２８として受信し得る。統計モデル１２６は、特徴と呼ばれるトレーニングデータ１２８から得られる多くの情報を考慮に入れ得る。本明細書での実施形態によれば、特徴及び他のトレーニングデータ１２８は、階層データとして配置され得、１つ又は複数の統計モデル１２６内で使用されるデータ階層の編成を維持しながら、幾つかの特徴を統合し得る。本明細書での実施形態により特徴数を低減した後、統合特徴を有する改訂階層データ構造を使用して統計モデルをトレーニングし、正確性についてチェックし、次に、患者の状態の特定、患者デバイスの制御等に使用し得る。統計モデル１２６は、定期的に更新され、新しいトレーニングデータに基づいて再トレーニングされて、統計モデル１２６を最新の状態に保ち得る。本明細書での幾つかの実施形態で使用し得る適する統計モデル１２６の例としては、予測モデル、決定木、人工ニューラルネットワーク、分類器、線形回帰モデル等の回帰モデル、サポートベクターマシン、及びマルコフモデル、隠れマルコフモデル等の確率論的モデルを挙げることができる。
【００３０】
１つ又は複数の統計モデル１２６が生成及びトレーニングされた後、管理アプリケーション１１８は、選択された患者１４６のセンサデータ１２２及び介護者記録１２４を１つ又は複数の統計モデル１２６への入力として使用して、選択された患者１４６の状態を分析し、出力を生成する等を行い、アラート又は他の通知１５４を介護者デバイス１０８又は施設計算デバイス１１０のうちの少なくとも一方に送信する等を行う。例えば、通知をディスプレイ１５０及び／又は１５２にそれぞれ提示して、介護者１４８又は医療人員に患者の状態を通知し得る。
【００３１】
追加又は代替として、管理アプリケーション１１８は、特定の患者治療デバイス１４２又は特定の患者モニタリングデバイス１４０を制御する制御信号１５６を送信する等により、１つ又は複数の患者デバイス１４０、１４２の設定を自動的に調整し得る。例えば、治療デバイス１４２がＩＶ注入ポンプであり、統計モデル１２６を使用して実行された分析により、患者が受け取っているＩＶ流体が多すぎることが示されると考える。制御信号１５６は、注入ポンプを制御して、患者へのＩＶ流体フローを低減し得る。別の例として、制御信号１５６は、モニタリングデバイス１４０を制御して、オンではなかったが、示された患者の状態に基づいて、選択された患者を更にモニタリングするのに使用され得る特定のモニタリングデバイス１４０をオンにする等を行い得る。
【００３２】
更に、幾つかの場合、統計モデル１２６の１つは、診断、予後、長期ケア治療の有効性、患者が退院した場合、ケア施設への再入院が必要になるか否かの判断等、患者１４６についての判断１５８を下し得る。管理アプリケーション１１８は、この判断を介護者計算デバイス１０８又は施設計算デバイス１１０のうちの少なくとも一方に送信し得る。
【００３３】
１つ又は複数の統計モデル１２６を準備するために、本明細書での実施形態は、過去センサデータ１３４及び過去介護者記録１３６に基づいて利用可能な特徴を特定し得る。この情報から、管理アプリケーション１１８は、１つ又は複数の階層データ構造１３２を生成し得る。管理アプリケーション１１８は次に、モデル特徴統合情報１３０を使用して、特定の統計モデル１２６の特徴の全体数（すなわち、特定の標的変数ｙ）を低減しようとし得る。例えば、特徴統合技法は、階層構成を維持しながら、統計モデル１２６により提供される結果に影響しない情報の実質的な損失なく、確立されたデータ階層下でロールアップ又は他の方法で統合され得る特徴を識別することを含む。特定の統計モデル１２６の特徴数を低減することの詳細について、更に以下に考察する。
【００３４】
図２は、幾つかの実施形態による、階層データを含む、例としてのデータ構造２００を示す。この例では、観察単位（例えば、過去又は現在の患者）の数に関するデータが利用可能であり、このデータを使用して、幾つかの可能な結果から結果を予測する統計モデルを構成及びトレーニングし得ると考える。一例として、病院のＩＣＵ等のケア施設では、現在、人工呼吸器を付けている患者毎に、その患者が人工呼吸器を外す準備ができているか否かを予測することが望ましいことがある。患者デバイスの様々なセンサは、患者をモニタリングし、センサデータを提供し得る。加えて、介護者記録は、患者についての臨床観察、現在の換気スケジューリング、及び患者についての他の情報を提供し得る。センサデータ及び介護者記録は両方とも、本明細書では「特徴」と呼ばれる潜在的な予測子を提供し得る。例えば、各患者に利用可能な多数、例えば数百、数千、又はそれよりも多くの特徴を有することが一般的であり得る。これらの特徴は、１つ又は複数のデータ階層に編成され得る。
【００３５】
データ構造２００は、臨床観察で使用される１２の記述を含むデータ例の一部を含む表である。例えば、近代電子健康記録システムでは、記述の数は数千以上であり得る。更に、これらの記述は、通常、階層に編成され、階層は、メニュー、サブメニュー、サブサブメニュー等を使用してデータ入力プロセスを促進し、詳細の異なる階層レベルでデータをまとめることを可能にする。したがって、この例では、第１のレベルの詳細２０２は、「流体ＩＮ」、「流体ＯＵＴ」、「薬剤」、「評価」等を含む。第２のレベルの詳細２０４は、第１のレベル２０２のサブメニューを含み得る。例えば、「ＩＶ流体」及び「血液製剤」を「流体ＩＮ」のサブメニューに包含し得、「血液」及び「尿」を「流体ＯＵＴ」のサブメニューに包含し得、「薬物」及び「ＩＶ流体」を「薬剤」のサブメニューに包含し得、「状態」を「評価」のサブメニューに包含し得る。加えて、第３のレベルの詳細２０６は、第２のレベル２０４のサブメニューを含む。例えば、「モルヒネ」及び「生理食塩水」を「ＩＶ流体」のサブメニューに包含し得、「成分１」及び「成分２」を「血液製剤」のサブメニューに包含し得、「薬物１」及び「薬物３」を「ＩＶ流体」のサブメニューに包含し得る。更に、３レベルの詳細がこの例に示されるが、幾つかの他の例では、より多くの詳細レベルがあり得る。したがって、管理アプリケーション１１８は、介護者記録と共に、臨床観察で使用された記述を受信し得、示されるように、情報を様々な階層レベルに解析して、受信データの階層関係を特定し得る。例えば、モニタリングされた状態、センサデータのタイプ、センサデータの単位等に基づいて、受信されたセンサデータも同様に階層関係に配置され得る。
【００３６】
図３は、幾つかの実施形態による、階層データ関係を表すツリーデータ構造３００の例を示す。この例では、図２のテーブルデータ構造２００からのデータは、図２のデータ構造２００に含まれる記述を表す複数のノードを含むツリーデータ構造３００として表される。ツリーデータ構造３００は、データ階層の最上部にあり、下にある全ての他のノードを含むレベル０ノード「ルート」３０２を含む。レベル１ノードは、「流体ＩＮ」３０４、「流体ＯＵＴ」３０６、「薬剤」３０８、及び「評価」３１０を含む。例えば、「流体ＩＮ」及び「流体ＯＵＴ」は、患者に入る流体及び患者から出る流体を指し得、「薬剤」は患者の治療に使用される薬剤を指し得、「評価」は、介護者により実行される患者の様々な種類の評価を指し得る。更に、幾つかの例では、より多くのレベル１ノードを包含し得る。
【００３７】
更に、レベル２ノードは、流体ＩＮ３０４の下に「ＩＶ流体」３１２及び「血液製剤」３１４を含み、流体ＯＵＴ３０６の下に「血液」３１６及び「尿」３１８を含み、薬剤３０８の下に「薬物１」３２０、「薬物２」３２２、及び「ＩＶ流体」３２４を含み、評価３１０の下に「状態１重症度」３２６及び「状態２重症度」３２８を含む。加えて、レベル３ノードは、ＩＶ流体３１２の下に「モルヒネ」３３０及び「生理食塩水」３３２を含み、血液製剤３１４の下に「成分１」３３４及び「成分２」３３６を含み、ＩＶ流体３２４の下に「薬物１」３３８及び「薬物３」３４０を含む。ツリー３００は、図３で輪郭が強調表示されて示される１２の終端ノード３１６、３１８、３２０、３２２、３２６、３２８、３３０、３３２、３３４、３３６、３３８、及び３４０を含み、各終端ノードは、図２のテーブルデータ構造２００からとられた元の記述を含む。
【００３８】
各終端ノードの各記述は、何らかの関連付けられた値を有し得、値は、数値測定値、物理的数量、カテゴリクラス（「オン」又は「オフ」、「１」又は「０」、「真」又は「偽」等）、介護者により入力されたフリーテキスト等であり得る。この例での予測問題では、トレーニングデータセットは、これらの値及び複数の他のデータソースから構築され、図３に示されるデータ階層に基づき得る。トレーニングデータセットの例について図４に関して後述する。
【００３９】
図４は、幾つかの実施形態による、統計モデルにより使用されるトレーニングデータセットの例としてのデータ構造４００を示す。この例では、観察単位４０２は、患者ＩＤ４０４及び日付４０６を含む特定の患者と日付との組合せであり得る。加えて、標的変数ｙ４０８は、統計モデルにより予測すべき標的変数であり得る。更に、トレーニングデータセット４００は、図２の臨床観察記述又は同等に図３のツリーデータ構造３００の終端ノードに対応する特徴１  ４１０（１）、特徴２  ４１０（２），．．．，特徴Ｋ  ４１０（Ｋ）等の複数の特徴を含み得る。幾つかの場合、トレーニングデータセット４００には数百又は数千の特徴４１０があり得る。
【００４０】
臨床観察等の未処理データソースからのそのようなトレーニングデータセット４００の構築は、通常、未処理データ値を観察単位のレベルに集約することを含み得る。そのようなトレーニングデータセット４００及び上述した特徴階層を所与として、本明細書での実施形態は、複数の特徴４１０を単一の特徴に統合し得る。これにより、より少数の特徴を有するより小さいトレーニングデータセットを作成することができる。本明細書での幾つかの実施形態は、終端ノードの統合を同じサブツリー下の他の終端ノードとの統合に制限し得、その理由は、これにより階層構造が維持されるためである。トレーニングデータセット内の特徴数を低減することにより、統計モデルのサイズが低減し、統計モデルが実行されるたびに管理されるデータ量も低減し、それにより、統計モデルを実行し得る速度を増大させ、計算を実行する計算デバイスの動作を改善させる。これは、アラート又は他の通知の介護者への送信及び／又はオンへの切り替え、オフへの切り替え、又は患者デバイスの調整等の患者デバイスを制御して、患者デバイスの動作を改善する制御信号の送信等の統計モデルに基づいて判断することができる速度も改善する。更に、特徴の統合により、残りの特徴を同様の処理コストでより複雑なモデルでより効率的に使用することができる。
【００４１】
図５Ａ及び図５Ｂは、幾つかの実施形態による、特徴がより上位レベルのノードに統合されるツリーデータ構造３００の例を示す。この例では、管理アプリケーションは、ツリーの終端ノードを調べて、任意の終端ノードをツリー階層の次の上位レベルのノードに統合し得るか否かを調べ得る。図５Ａでは、終端ノード３３０に対応する特徴であるモルヒネ及び終端ノード３３２に対応する特徴である生理食塩水という２つの特徴が、ＩＶ流体３１２である直上のレベルのノードへの統合（すなわち、ロールアップ）に考慮される。したがって、この場合、サブツリー５０２はノード３１２、３３０、及び３３２を含む。モルヒネノード３３０及び生理食塩水ノード３３２は両方とも、ＩＶ流体中間ノード３１２の下にある。終端ノード３３０及び３３２は両方とも、ミリリットル単位で表現され得ると考える。したがって、ＩＶ流体ノード３１２により表される統合特徴は、患者に提供されるＩＶ流体の総量として表わされ得る。別の例として、終端ノード３３０及び３３２の特徴が、特定の流体であるモルヒネ及び生理食塩水がそれぞれ投与された回数のカウントである場合、カウントを一緒に加算して、ＩＶ流体ノード３１２により表される特徴として投与されたＩＶ流体の総カウントを得ることにより、これらのカウントを結合し得る。
【００４２】
いずれの場合でも、又は測定若しくは表現の他の単位の場合、統合実行への考慮事項はどの程度情報が失われるかである。この例では、幾つかの統計モデルの目的で、特定の日に患者が受け取ったモルヒネ量及び患者が受け取った生理食塩水量を考慮する代わりに、特定の日に患者が受け取ったＩＶ流体の総量として、２つの数量を結合することは略同じ程度の有益性を有し得る。他方、他の統計モデルでは、患者が受け取ったモルヒネ量及び／又は生理食塩水量は重要な考慮事項であり得、したがって、幾つかの特徴の統合にこれらの２つを結合することは望ましくないことがある。したがって、本明細書での実施形態は、統計モデルにより予測されるべき特定の標的変数ｙを特定するために、特定の特徴の結合が特定の統計モデルで許容可能であるか否かを判断する。
【００４３】
一例として、上述したトレーニングデータセット４００及びツリーデータ構造３００の特徴階層を所与として、本明細書での実施形態は、複数の特徴を１つの特徴に統合することを検討し、それにより、より少数の特徴を有するトレーニングセットを取得し得る。更に、幾つかの実施形態は、同じサブツリーの下に他の終端ノードを有する終端ノードの統合に制限され、その理由は、これにより、データの階層構造が維持されるためである。加えて、複数の特徴を次の上位レベルの１つの特徴に結合する集約関数は、ユーザ若しくは特定の特徴の他のソースにより提供されてもよく、又は代替的に統合すべき特徴のコンテキスト若しくはカテゴリから決定され得る。
【００４４】
図５Ａに示される例では、管理アプリケーションは、特徴の表現のカテゴリを決定し得る。例えば、モルヒネノード３３０の特徴及び生理食塩水ノード３３２の特徴が両方とも、容量単位等、例えば、ＩＶ流体のｍＬ単位という同じ物理的数量として表わされ得る場合、これらの特徴は、加算により統合され得、患者に投与されたＩＶ流体の総量に関して表現され得る。他方、モルヒネノード３３０の特徴及び生理食塩水ノード３３２の特徴が両方とも、各流体が投与された回数のカウントで表される場合、これらの特徴は、患者に投与されたＩＶ流体のカウントの総数の加算により統合され得る。同様に、ノード３３０及び３３２の特徴が、各流体が存在したことの真又は偽インジケータとして表わされ得る場合、統合特徴は、任意の種類のＩＶ流体が投与されたことのインジケータであり得る。したがって、上記の場合、終端ノード３３０及び３３２は互いと同等であり、したがって、統合から失われる情報量が閾値未満であると予測される場合に及び／又は後述する他の考慮事項に基づいて統合可能である。
【００４５】
他のタイプの特徴を統合することもできる。例えば、「評価」ノード３１０の下の「状態１重症度」ノード３２６及び「状態２重症度」ノード３２８が調べられる場合、これらは各状態評価の形態に応じて結合可能であることもあれば、結合可能ではないこともある。一例として、状態１及び状態２の評価が同じ尺度（例えば、０〜１００）で測定され、方向が一貫する、例えば、両方で値が大きいほど良好である場合、結合された特徴は２つの評価の２つの値の平均として表わされ得る。
【００４６】
他方、幾つかの特徴は、有意味に結合することが可能ではないことがある。例えば、ノード３１２における特徴「ＩＶ流体」は、液体の総量で表され、ノード３１４における「血液製剤」特徴が、任意の種類の「血液製剤」が投与された回数を示す場合、ノード３１２における「ＩＶ流体」特徴をノード３１４における「血液製剤」特徴と結合することは意味をなさない。したがって、２つの特徴の単位又は他のカテゴリが一致しない場合、２つの特徴の統合は通常検討されない。
【００４７】
図５Ｂに示されるように、ノード３３０からの「モルヒネ」特徴とノード３３２からの「生理食塩水」特徴とを統合すると、ノード３３０及び３３２がデータ構造３００から除去される。更に、ＩＶ流体ノード３１２は、ここでは、終端ノードであり、使用される集約関数に基づいて、患者に送達されたＩＶ流体の総量等のノード３１２における統合ＩＶ流体特徴を表す特徴「ＩＶ流体」を含む。したがって、ノード３３０及び３３２からの特徴を統合して、ノード３１２における新しい統合特徴にすることを通して、図５Ａのサブツリー５０２は、ここでは、図５Ｂの終端ノード３１２で置換されている。トレーニングデータセットは、「モルヒネ」値及び「生理食塩水」値にそれぞれ対応するノード３３０及び３３２における２つの元の特徴の代わりに使用される、新しい統合特徴、すなわち「ＩＶ流体」特徴を用いて生成され得る。
【００４８】
本明細書での幾つかの実施形態は、統合特徴の評価に基づいて特定の特徴の統合を実行すべきか否かを判断し得る。一例として、現在の特徴がｘ１，ｘ２，．．．，ｘｐ（サブツリーの終端ノードに対応する）であると考える。統合特徴ｕは、ｕ＝ｆ（ｘ１，ｘ２，．．．，ｘｐ）として表わされ得、式中、ｆは所与の集約関数である。所与の標的変数ｙを予測することに関して特徴をランク付け又は他の方法で評価するために、幾つかの異なる技法を適用してもよい。選択された特徴の統合を実行すべきか否かの評価に使用し得るランク付け関数の幾つかの例としては、
（１）相互情報：Ｉ（ｙ，ｘｉ）として示される各ｘｉ及びｙの間の相互情報を特定すること、
（２）Ｒ二乗：ｒ（ｙ，ｘｉ）として示される各ｘｉと標的変数ｙとの間の相関係数を特定すること、又は
（３）クラス間／クラス内比率：標的変数ｙがカテゴリ変数である場合、各ｘｉのクラス間距離とクラス内距離との比率と特定すること
が挙げられる。
【００４９】
上記評価関数（１）〜（３）は、ｕ＝ｆ（ｘ１，ｘ２，．．．，ｘｐ）を用いて｛ｘ１，ｘ２，．．．，ｘｐ｝を集合として比較するように一般化し得、比較を使用して、統合に検討されている選択された特徴を統合するか否かを判断し得る。この比較技法は、特徴の組の値を測定して、標的変数ｙを予測するように一般化することができる任意のランク付け関数を使用して実行され得る。
【００５０】
少なくとも部分的に統合検討中の特徴ｘ１，ｘ２，．．．，ｘｐの性質及び標的変数ｙの特性に応じて、異なる場合で異なる評価関数を適用することが最適であり得る。幾つかの例では、幾つかの異なるランク付け関数を同じ階層内で使用し得る。後述するように、上記ランク付け関数（１）〜（３）は、一般化され得、特定の特徴を統合すべきか否かの判断に使用され得る。更に、異なるランク付け関数が異なるタイプの特徴及び／又は異なる標的変数ｙに適し得る。
【００５１】
（１）相互情報：第１の例として、相互情報は、統合を実行すべきか否かを判断するように一般化され得る。相互情報は、２つの変数間の相互依存性の尺度である。例えば、相互情報は、別の変数を通して、ある変数について得られる情報量を定量化し得る（ビット等の単位で）。相互情報の概念は、確率変数に保持される「ランダム性」を定義する確率変数のエントロピーの概念にリンクされる。
【００５２】
相互情報を評価関数として適用する場合、集合｛ｘ１，ｘ２，．．．，ｘｐ｝はｕより下にランクされないことが保証され、その理由は、Ｉ（ｙ；ｘ１，ｘ２，．．．，ｘｐ）≧Ｉ（ｙ；ｆ（ｘ１，ｘ２，．．．，ｘｐ））であるためであり、式中、ｆは集約関数である。したがって、これらの相互情報値間の差ΔＩを計算し得、差ΔＩは、ｘ１，ｘ２，．．．，ｘｐをｕに統合する場合の情報の損失を表す。一例として、情報の損失は「ビット」単位で測定され得、ビットは次元のない数量である。
【００５３】
幾つかの場合、管理アプリケーションは、差ΔＩが固定の予め指定される閾値ビット数未満の場合に特徴の統合を決定し得る。別の例として、管理アプリケーションは、ΔＩ／Ｉ（ｙ；ｘ１，ｘ２，．．．，ｘｐ）に基づいて特定し得、０〜１の値を提供し得る情報の相対損失を特定することに基づいて特徴を統合すると決定し得る。例えば、情報の相対損失が０．０５等の指定された統合閾値ｂ未満である場合、統合を実行し得る。
【００５４】
相互情報の特定は、標的変数及び特徴が離散している場合、すなわち、小さい数の離散値をとる場合に利用され得る。そのような事例の一例は、標的変数ｙがカテゴリであり、特徴が、特定の記述が存在することの真／偽インジケータである場合である。ｙ又は特徴が離散していない場合、ビニングを使用して、およその相互情報を計算し得る。他方、各特徴が２つのみの可能値を有する場合であっても、ｐ個の特徴全ての結合は２ｐ個の可能値を有することができる。特徴数が大きい場合、計算は遅いか又はトレース不可能になり得る。
【００５５】
（２）Ｒ二乗：第２の例として、相関係数は、統合を実行すべきか否かを判断するための評価関数として一般化され得る。例えば、相関係数は、２つのランク間の類似度を測定し得、２つのランク間の関連の有意性を評価するのに使用され得る。相関係数を一般化するために、本明細書での幾つかの例は、多重線形回帰で「Ｒ二乗」としても知られる多重相関Ｒ２（ｙ；ｘ１，ｘ２，．．．，ｘｐ）の係数を使用し得る。値１−Ｒ２は、標的変数ｙがｙの二乗和に相対してｘ１，ｘ２，．．．，ｘｐで回帰する場合、ＲＳＳ（ｙ；ｘ１，ｘ２，．．．，ｘｐ）として示される残差の二乗和である。この場合の概念はΔＲＳＳを計算することであり、ΔＲＳＳは、標的変数ｙがｕ＝ｆ（ｘ１，ｘ２，．．．，ｘｐ）で回帰する場合及び標的変数ｙがｘ１，ｘ２，．．．，ｘｐで回帰する場合での残差二乗和間の差である。一般に、前者が後者と少なくとも同じ大きさの残差二乗和を有する保証はない（相互情報例と異なる）が、これは、ｕがｕ＝ｘ１＋ｘ２＋．．．＋ｘｐである一般的な場合を含むｘ１，ｘ２，．．．，ｘｐの線形関数である場合、真である。
【００５６】
加えて、更に一般的に、ｙの一般化線形モデルをｘ１，ｘ２，．．．，ｘｐ及びｕに当てはめ得、２つのモデルの逸脱の差を比較し得る。一般化線形モデルの一例は対数回帰であり、これは、標的変数ｙが２つの可能値を有するカテゴリ変数である場合に適用可能である。表記ΔＲＳＳは、この場合を包含するように拡張され得る。したがって、幾つかの例では、管理アプリケーションは、ΔＲＳＳが指定の閾値未満である場合、統合を実行すると決定し得る。他の例では、管理アプリケーションは、残差二乗和の相対変化ΔＲＳＳ／ＲＳＳ（ｙ；ｘ１，ｘ２，．．．，ｘｐ）が０．０５等の指定された統合閾値ｂ又は他の指定される統合閾値ｂ未満である場合、統合の実行を決定し得る。線形回帰の場合、残差二乗和の相対変化は１−Ｒ２の相対変化に等しい。
【００５７】
残差二乗和の相対変化（相対逸脱を含む）を使用して、統合を実行すべきか否かを判断することは、特徴が略連続した線形回帰モデルであるか、又は標的変数ｙの当てはめに適切な一般化線形モデルである場合、良好に機能し得る。Ｒ二乗評価関数は、通常、標的変数ｙが２つの可能値、例えば、真／偽、１／０等を有するカテゴリである場合に使用され得る。この技法は、程々の数の特徴に向けて良好にスケーリングすることもできる。
【００５８】
（３）クラス間／クラス内比率：第３の例として、クラス間距離とクラス内距離との比率は、統合を実行すべきか否かを判断するための評価関数として使用され得る。例えば、個々の特徴ｘｉから特徴ベクトル（ｘ１，ｘ２，．．．，ｘｐ）へのクラス間／クラス内距離は、デカルト距離又はｐ次元空間内の別の距離尺度を使用することにより一般化され得る。次に、（ｘ１，ｘ２，．．．，ｘｐ）及びｕ＝ｆ（ｘ１，ｘ２，．．．，ｘｐ）のクラス間／クラス内距離の比率の変化を比較し得る。次に、選択された特徴を統合すべきか否かについての判断は、変化又は相対変化を指定の閾値と比較することに基づく。
【００５９】
クラス間／クラス内距離を使用するために、標的変数ｙはカテゴリであり得る。標的変数ｙが３つ以上のクラスを有する場合、標準ロジスティック回帰を適用することはできず、したがって、ロジスティックモデルからのΔＲＳＳを使用することができないことがある。そのような場合、本明細書での実施形態は、クラス間／クラス内距離に適用され得る。例えば、３つ以上のクラスがあり得、したがって、この評価技法は、ｙが３つ以上の距離値を有する実施形態に使用され得る。多くの共通距離メトリックの場合、クラス間／クラス内距離計算は、観察数及び特徴数と共に良好にスケーリングする。
【００６０】
１つ又は複数の組の特徴を統合した後、管理アプリケーションは、統合を停止するか、それとも追加の組の特徴を統合するかを判断し得る。管理アプリケーションは、停止するか、それとも続けるかを判断する場合、幾つかの停止基準を適用され得る。第１の例として、管理アプリケーションは、全ての内部ノードが検討された場合、停止を決定し得る。この技法は、同じ計算をエンドレスに繰り返すことを回避し、最も厳しくない基準である。しかし、この技法の一欠点が生じ得、その理由は、次の上位ノードへ統合すべきか否かの判断が、各ノードでローカルに閾値を満たすことに基づく等の他の中間ノードでの判断から独立して行われるためである。相互情報を例として使用すると、相互情報ΔＩの損失は、個々では小さく、閾値未満であり得るが、集合的には、続くモデリングの予測精度を損ない得る、情報の許容できないほど大きい累積損失になり得る。
【００６１】
この問題を軽減する一技法は、相互情報の累積損失への情報合計損失（ＴＬＩ）閾値を設定し、この閾値を超える前に統合を停止することである。この概念は、ΔＲＳＳ、クラス間／クラス内距離の変化、及び他の評価関数並びにΔＩ／Ｉ（ｙ；ｘ１，ｘ２，．．．，ｘｐ）等の相対的な相手方に拡張される。複数の評価関数が使用される場合、別個のＴＬＩ閾値を各評価関数に設定し得る。したがって、複数の評価関数が同じデータセット内の異なる特徴の統合に使用される場合、第１のＴＬＩ閾値を第１の評価関数に設定し得、第２のＴＬＩ閾値を第２の評価関数に設定し得、以下同様である。第１の評価関数で第１のＴＬＩ閾値に達する場合、第１の評価関数に対応する特性を有する特徴の統合を停止し得るが、第２の評価関数に対応する特性を有する特徴の統合は、第２のＴＬＩ閾値に達するまで継続され得、以下同様である。
【００６２】
幾つかの例では、最大深度の複数の内部ノード（すなわち、図５Ａでのノード３１２、３１４、３０６、３２４、及び３１０）の集合Ｓのトラバースは、ランダムで実行されて、これらのノードの終端ノードを各内部ノードに統合するか否かを判断し得る。しかし、幾つかの場合、最大深度のこれらの内部ノードをトラバースする他の技法を使用して、よりよい結果を達成し得る。一例として、最大深度の内部ノードの集合Ｓをトラバースして、各統合の比較価値及びコストを考慮に入れ得る。例えば、各統合に同じ値が割り当てられる場合、ある解決策は、コストが増大する順、すなわち、ＴＬＩ閾値に達するまで最低コストからより高いコストに増大する順にノードを選択することである。
【００６３】
代替的には、別の例として、幾つかの実施形態は、より多数の特徴を結合するそれらの特徴の統合を選択することを含み得、結合されている特徴の数に基づいて値を設定し得る。しかし、これは、ＮＰ困難な最適化問題に繋がり得る。したがって、この問題の解決が実際的であるか否かは、少なくとも部分的にＳ内のノード数に依存し得、Ｓ内のノード数は、総当たり手法にとって十分に小さいことがある。更に、評価関数の３つの例が本明細書に記載されるが、これらの評価関数への追加又は代替として使用され得る他の評価関数が本明細書での開示の恩恵を有する当業者に明らかになるであろう。
【００６４】
図６は、幾つかの実施形態により、特徴の統合を終了した後のツリーデータ構造３００の例を示す。複数の特徴セットの幾つかの統合後、ツリー３００のデータ階層が図６に示されるようになると考える。この例では、ツリー３００は、ここでは、７つの終端ノードを有し、これは、元の１２の終端ノードからの大きい低減である。したがって、このデータ階層に基づいて当てはめられた統計モデルは、特徴統合処理が実行されない場合よりも５つ少ない特徴を有する。上述したように、これは、統計モデルをトレーニング及び使用する処理時間を低減し得、したがって、通知が介護者に提供される速度を改善し、及び／又は患者デバイス等のデバイスを制御する速度及び応答性を改善し得る。
【００６５】
加えて、統合特徴は、３０８に示されるように更に統合され得る。例えば、図５Ｂを再び参照すると、まず、ノード３３８及び３４０における特徴がノード３２４における新しい統合特徴に統合されると考える。図７のプロセスの第２の反復中等、続けて、３２４における新しい統合特徴は、図６に示されるように、ノード３０８における新しい更なる統合特徴への統合により、特徴３２０及び３２２と次の上位階層レベルへ更に統合され得る。
【００６６】
更に、本明細書での実施形態は、他の努力分野に適用され得る。一例として、そのような階層構造を有するデータセットは、決定木を使用して元の特徴から追加の特徴を導出する、ＲｕｌｅＦｉｔ等の機械学習法からも生じ得る。この場合、導出された特徴は、決定木のノードに対応し得、元の特徴に関して定義される「規則」を表し得る。各規則は真／偽インジケータであり得、規則の組の統合は、論理「ＯＲ」演算子に対応し得る。本明細書での例は、導出された特徴を選択的に統合するのに使用することもできる。
【００６７】
図７〜図１０は、幾つかの実施形態によるプロセス例を示す流れ図である。プロセスは、一連の動作を表す、論理流れ図においてブロックの集合として示され、一連の動作の幾つか又は全ては、ハードウェア、ソフトウェア、又はそれらの組合せで実施され得る。ソフトウェアに関連して、ブロックは、１つ又は複数のプロセッサにより実行されると、記載の動作を実行するようにプロセッサをプログラムする、１つ又は複数のコンピュータ可読媒体に記憶されたコンピュータ実行可能命令を表し得る。一般に、コンピュータ実行可能命令は、特定の機能を実行し、又は特定のデータタイプを実施するルーチン、プログラム、オブジェクト、コンポーネント、データ構造等を含む。ブロックが説明される順序は、限定として解釈されるべきではない。記載される任意の数のブロックは、任意の順序で及び／又は並列して結合して、プロセス又は代替のプロセスを実施することができ、ブロックの全てを実行する必要はない。考察を目的として、プロセスは、本明細書での例で記載される環境、枠組み、及びシステムを参照して説明されるが、プロセスは、広範囲の他の環境、枠組み、及びシステムで実施され得る。
【００６８】
図７は、幾つかの実施形態による、統合される特徴を決定する例としてのプロセス７００を示す流れ図である。幾つかの例では、プロセス７００は、サービス計算デバイス１０２又は他の適する計算デバイスにより実行され得る。
【００６９】
７０２において、計算デバイスは、標的変数ｙ、特徴階層データ構造、統合閾値、評価関数タイプ、及び異なる評価関数ＩのＴＬＩ閾値ｃ＊（Ｉ）を受信し得る。例えば、標的変数ｙの特性は、構成中のモデルについて既知であり得、例えば、離散値、連続値等であり得る。更に、標的変数ｙの特性及び特徴に基づいて、評価関数を選択し得る。例えば、標的変数ｙ及び特徴が離散し、特徴数が程々である場合、相互情報を選択し得、標的変数ｙが、２つのクラスの値を有するカテゴリであり、特徴が略連続している場合、Ｒ二乗を選択し得、標的変数がカテゴリであり、３つ以上のクラスの値を有する場合、クラス間／クラス内比率を選択し得る。更に、ＴＬＩ閾値は、選択された評価関数に基づいて選択され得、モデルの所望の精度レベルとモデルの処理速度とのトレードオフに基づいて選択され得る。非限定的な一例として、情報の損失が０〜１のスケールでの相対値として測定される場合、ＴＬＩ閾値は０．１０〜０．２０又は他の所望のＴＬＩ閾値であり得る。各評価関数は、それ自体のＴＬＩ閾値を有し得、したがって、異なる評価関数は異なるＴＬＩ閾値を有し得る。更に、ＴＬＩ閾値の値は、少なくとも部分的に、情報損失の絶対差が特定されるか、それとも相対差が特定されるかに基づいて指定され得る。個々の統合閾値ｂも同様の考慮事項に基づいて設定され得る。
【００７０】
７０４において、計算デバイスは、全ての評価関数のコストｃ（Ｉ）＝０に設定され得、最大深度の全ての内部ノードｎを新ノードとしてマークする。
【００７１】
７０６において、計算デバイスは、依然として検討されていない最大深度の任意の新しい内部ノードｎがあるか否かを判断し得る。
【００７２】
７０８において、計算デバイスは、最大深度の新しい内部ノードｎを選択し、ｎを古いノードとしてマークする。
【００７３】
７１０において、計算デバイスは、ｎの下の特徴：ｘ１，ｘ２，．．．，ｘｐを取得し得る。例えば、ｐは、ｎをルートとして有するサブツリー内の特徴数（終端ノード数）であり得る。
【００７４】
７１２において、計算デバイスは、特徴の結合が有意味であるか否かを判断し得る。例えば、特徴が全て同じタイプのものであるか、又は他の様式で同じ特性を有する（例えば、全て同じタイプの数量として表すことができる、全てオン／オフ、０／１等、カテゴリ的に表すことができる等）場合、特徴は結合され得、プロセスは７１４に進む。他方、特徴が全て同じタイプのものではない（例えば、特徴によっては物理的数量として表されるものもあれば、ブール値として表されるものもある等）場合、これらの特徴を結合することは有意味ではなく、プロセスは７０６に進み、依然として検討されていない最大深度の別の内部ノードｎを選択する。
【００７５】
７１４において、計算デバイスは、ｙ及び（ｘ１，ｘ２，．．．，ｘｐ）の特性に基づいて、集約関数ｆ及び１つ又は複数の評価関数Ｉを選択し得る。
【００７６】
７１６において、計算デバイスは、選択された評価関数に基づいて、統合すべきか否かを判断し得る。統合すべき場合、プロセスは７１８に進み、統合すべきではない場合、プロセスは７０６に戻り、検討に残っている任意の他の内部ノードがあるか否かを判断する。図８は、特定の特徴を統合すべきか否かの判断についての更なる詳細を説明している。
【００７７】
７１８において、計算デバイスは、現在の特徴を統合する統合コストに、既に統合された任意の特徴の統合コストｃ（Ｎ）を加えたものであるコストが、評価関数のＴＬＩ閾値であるｃ＊（Ｉ）以下であるか否かを判断し得る。ＴＬＩ閾値以下である場合、プロセスは７２０に進み、ＴＬＩ閾値以下ではない場合、プロセスは７０６に進み、検討に残っている任意の他の内部ノードがあるか否かを判断する。上述したように、複数の評価関数が、同じデータセット内の異なる特徴を統合すべきか否かの判断に使用される場合、第１のＴＬＩ閾値を第１の評価関数に設定し得、第２のＴＬＩ閾値を第２の評価関数に設定し得、以下同様である。第１の評価関数で第１のＴＬＩ閾値に達する場合、第１の評価関数に対応する特性を有する特徴の統合を停止し得るが、第２の評価関数に対応する特性を有する特徴の統合は、第２のＴＬＩ閾値に達するまで継続され得、以下同様である。
【００７８】
７２０において、計算デバイスは、現在の統合コストを加算することにより、すなわち、ｃ（Ｉ）＝ｃ（Ｉ）＋統合コストにより、統合コストの中間結果を更新し得、ｎにおけるサブツリーを、新しい統合特徴ｆ（ｘ１，ｘ２，．．．，ｘｐ）を有する終端ノードで置換し得る。プロセスは次に、７０６に戻り、検討に残っている任意の他の内部ノードがあるか否かを判断し得る。
【００７９】
７２２において、全ての内部ノードが検討されると、計算デバイスは、改訂された階層データに基づいてトレーニングデータセットを生成し、統計モデルを構成し得る。幾つかの例では、計算デバイスは、ブロック７０２〜７２０の複数の反復を実行し、その後、ブロック７２２に進み得る。例えば、計算デバイスは、ＴＬＩ閾値を超えずに第１の反復を完了する場合、別の反復を実行して、任意の統合特徴を階層データ構造内の次の上位レベルに更に統合し得るか否かを判断し得る。したがって、プロセスは、ＴＬＩ閾値を超えるまで繰り返され得、ＴＬＩ閾値を超えた場合にブロック７２２を実行し得る。
【００８０】
図８は、幾つかの実施形態による、選択された特徴を統合すべきか否かを判断する、図７のブロック７１６において実行される例としてのプロセス８００を示す流れ図である。幾つかの例では、プロセス８００は、サービス計算デバイス１０２又は他の適する計算デバイスにより実行され得る。
【００８１】
８０２において、図７のブロック７１４に続き、計算デバイスは、内部ノードｎ、集約関数ｆ、評価関数Ｉ、評価タイプ（絶対又は相対）、及び統合閾値ｂを入力として受信し得る。
【００８２】
８０４において、計算デバイスは、階層データ内の全ての特徴のサブセットであり得る、ｎの下の特徴ｘ１，ｘ２，．．．，ｘｐを取得し得る。したがって、選択された内部ノードｎから依存する選択された特徴のサブセットｘ１，ｘ２，．．．，ｘｐは、階層データ構造内の次の上位階層レベルにおける内部ノードｎに統合する候補である。
【００８３】
８０６において、計算デバイスは、統合特徴ｕ＝ｆ（ｘ１，ｘ２，．．．，ｘｐ）を計算し得る。例えば、集約関数ｆを使用して、統合特徴ｕを計算する。集約関数は、特徴ｘ１，ｘ２，．．．，ｘｐの特性に基づいて選択される。
【００８４】
８０８において、計算デバイスは、評価関数を使用して、Ｉ（ｙ；ｘ１，ｘ２，．．．，ｘｐ）に基づいて第１の結果を計算し、Ｉ（ｙ；ｕ）に基づいて第２の結果を計算し得る。例えば、選択された評価関数を使用して、ｘ１，ｘ２，．．．，ｘｐの統合なしに基づいて第１の結果を計算し、統合特徴ｕに基づいて第２の結果を計算する。第１の結果と第２の結果との間の相対差又は絶対差に基づいて、統合の場合の情報の予測損失を特定し得る。
【００８５】
８１０において、計算デバイスは、絶対差を特定する場合、ｇ＝ΔＩに設定し得、相対差を特定する場合、ｇ＝ΔＩ／Ｉ（ｙ；ｘ１，ｘ２，．．．，ｘｐ）を設定し得る。例えば、計算デバイスは、ブロック８０８において特定された第１の結果と第２の結果との間の差として、ｇの絶対値を特定し得る。追加又は代替として、計算デバイスは、相対値としてｇを特定し得、この場合、第１の結果と第２の結果との間の差は第１の結果で除算される。したがって、値ｇは、統合での情報の予測損失を表し得る。
【００８６】
８１２において、計算デバイスは、値ｇが統合閾値ｂ未満であるか否かを判断し得る。統合閾値ｂは、ｇの絶対値が使用されるか、それともｇの相対値が使用されるかに基づいて選択され得る。
【００８７】
８１４において、ｇ＜ｂである場合、計算デバイスは、統合を実行し得、統合のコストはΔＩである。次に、プロセスは図７のプロセスに戻り、図７のブロック７１８での処理を続け得る。
【００８８】
他方、８１６において、ｇ＞ｂの場合、計算デバイスは、統合を実行しないと判断し得、コストはゼロである。次に、プロセスは図７のプロセスに戻り、図７のブロック７０６において処理を継続し得る。
【００８９】
図９は、幾つかの実施形態による、評価関数を選択することを含む例としてのプロセス９００を示す流れ図である。幾つかの例では、プロセス９００は、サービス計算デバイス１０２又は他の適する計算デバイスにより実行され得る。
【００９０】
９０２において、計算デバイスは、複数の観察単位で、階層構造を有する階層データを受信し得る。医療施設で使用される場合等の幾つかの例では、観察単位は患者を含み得、階層データは、センサデータ及び／又は介護者記録を含み得る。しかし、他の例では、他のタイプのアプリケーション内の他のタイプの統計モデルに他のタイプのデータを使用し得る。
【００９１】
９０４において、計算デバイスは、受信データに基づいて、受信データの階層構造を有するデータ構造を作成して、複数の特徴を決定し得る。例えば、データ構造がツリーである場合、複数の特徴は、ツリーの終端ノードに対応し得る。データ構造が階層レベルを示すテーブルである場合、複数の特徴は、テーブル内の各エントリの最も遠い階層レベルに対応し得る。更に、２つのデータ構造例を本明細書において説明したが、階層データの表現に使用し得る多くの他のデータ構造が本明細書での開示の恩恵を有する当業者に明らかになるであろう。
【００９２】
９０６において、計算デバイスは、特徴の特性及び１つ又は複数の標的変数の特性に基づいて、１つ又は複数の評価関数を選択し得る。例えば、この例では、２つの異なる標的変数ｙ１及びｙ２があると考える。一例として、ｙ１が、人工呼吸器が使用されるか否かの予測に使用される第１の統計モデルのためのものであり、ｙ２が、ケア施設内の特定の患者の滞在長の予測に使用される第２の統計モデルのためのものであると考える。２つの異なる標的変数は異なる特性を有するため、２つの異なる標的変数のそれぞれで、階層データ内でいずれの特徴を統合するかの判断に、異なる評価関数を使用し得る。例えば、幾つかの例では、統合すべき特徴の性質に応じて、複数の評価関数を単一の階層データセットに使用し得る。上述したように、評価関数によっては、幾つかのタイプの特徴及び幾つかのタイプの標的関数を統合すべきか否かの判断に適するものもあれば、他のタイプの特徴及び他のタイプの標的変数を統合すべきか否かの判断に適するものある。更に、階層データセットは、同じデータセット内の他の特徴の特性と異なる特性を有する特徴を含み得る。したがって、図９の例では、１つ又は複数の評価関数が、第１の標的変数ｙ１を特定する場合に統合される特徴を特定するために選択され、１つ又は複数の異なる評価関数が、第２の標的変数ｙ２を特定する場合に統合される特徴を特定するために選択される。当然のことながら、代替的に、他の例では、標的変数ｙ１及びｙ２が同様の特性を有する場合、同じ１つ又は複数の評価関数を両事例に使用し得る。評価関数の選択に使用し得る考慮事項は、例えば、図５Ａ及び図５Ｂに関して上述されている。
【００９３】
９０８において、標的変数ｙ１について、計算デバイスは、選択された１つ又は複数の評価関数を使用して、統合される特徴を決定し得る。例えば、計算デバイスは、統合される特徴を決定する図７及び図８のプロセスを実行し得る。
【００９４】
９１０において、計算デバイスは、統合特徴を含む階層データの第１の改訂データ構造を決定し得る。
【００９５】
９１２において、計算デバイスは、第１の改訂データ構造に基づいて第１の統計モデルを構成及びトレーニングし得る。
【００９６】
９１４において、計算デバイスは、現在のデータを第１のトレーニング済みモデルに適用することに基づいてｙ１を特定し得る。
【００９７】
９１６において、計算デバイスは、ｙ１結果に基づいて少なくとも１つの動作を実行し得る。
【００９８】
９１８において、標的変数ｙ２について、計算デバイスは、選択された１つ又は複数の評価関数を使用して、統合される特徴を決定し得る。例えば、計算デバイスは、統合される特徴を決定する図７及び図８のプロセスを実行し得る。
【００９９】
９２０において、計算デバイスは、統合特徴を含む階層データの第２の改訂データ構造を決定し得る。幾つかの例では、第２の改訂データ構造の統合特徴は、異なる評価関数を使用することから決定される異なる結果に基づく等、例えば、異なる標的変数の異なる特性に基づいて第１の改訂データ構造の統合特徴と異なり得る。
【０１００】
９２２において、計算デバイスは、第２の改訂データ構造に基づいて第２の統計モデルを構成及びトレーニングし得る。幾つかの例では、第２の統計モデルは、第１の統計モデルと同じタイプの統計モデルであり得、一方、他の例では、第２の統計モデルは、第１の統計モデルと異なるタイプの統計モデルであり得る。本明細書での幾つかの例により使用し得る統計モデルのタイプの例としては、予測モデル、決定木、人工ニューラルネットワーク、分類器、線形回帰モデル等の回帰モデル、サポートベクターマシン、及びマルコフモデル、隠れマルコフモデル等の確率論的モデルが挙げられる。
【０１０１】
９２４において、計算デバイスは、現在のデータを第２のトレーニング済みモデルに適用することに基づいてｙ２を特定し得る。
【０１０２】
９２６において、計算デバイスは、ｙ２結果に基づいて少なくとも１つの動作を実行し得る。
【０１０３】
図１０は、幾つかの実施形態による、患者データを制御し、及び／又は患者状態を特定する例としてのプロセス１０００を示す流れ図である。幾つかの例では、プロセス１０００はサービス計算デバイス１０２又は他の適する計算デバイスにより実行され得る。この例では、本明細書での技法は、上述した図１に対応するシステム等のケア施設における患者及び／又は患者デバイスに適用され得る。
【０１０４】
１００２において、計算デバイスは、複数の患者のセンサデータ及び介護者記録を含む階層データを受信し得る。階層データは、階層構造内の異なる階層レベルに対応する複数の記述を含む階層構造を有し得る。
【０１０５】
１００４において、計算デバイスは、階層データの階層構造を決定し、複数の特徴を決定し得る。例えば、階層データは、ツリーデータ構造等のデータ構造で配置され得、ツリーは、特徴に対応し得る複数の終端ノードを含み得る。これらの特徴のそれぞれは、同じサブツリー内の１つ又は複数の他の特徴と統合する候補であり得る。
【０１０６】
１００６において、計算デバイスは、階層データ内で統合される特徴を決定して、１つ又は複数の新しい統合特徴を含む改訂階層データを取得し得る。例えば、計算デバイスは、階層データ内の統合される特徴を決定して、１つ又は複数の新しい統合特徴を含む改訂階層データ構造を取得する図７及び図８のプロセスを実行し得る。
【０１０７】
１００８において、計算デバイスは、１つ又は複数の新しい統合特徴を含む改訂階層データ構造に基づいて統計モデルを構成及びトレーニングし得る。
【０１０８】
１０１０において、計算デバイスは、第１の患者のセンサデータ及び／又は介護者記録を受信し得る。例えば、モデルがトレーニングされた後、特定の患者のデータをモデルに適用して、モデルが構成された所望の標的変数を特定し得る。
【０１０９】
１０１２において、計算デバイスは、受信された第１の患者データを統計モデルに適用して標的変数を特定し得る。
【０１１０】
１０１４において、計算デバイスは、統計モデルの出力に基づいて通知を送信し、決定を送信し、制御信号をデバイスに送信し、及び／又は他の動作を実行し得る。一例として、計算デバイスは、通知を介護者計算デバイス及び／又は施設計算デバイスに送信し得る。例えば、計算デバイスは、通知を送信して、アラートを介護者デバイスのディスプレイ及び／又は施設計算デバイスのディスプレイに提示させ得る。通知は、介護者に是正措置をとるように警告し得、及び／又は他の適切な介入を実行し得る。
【０１１１】
別の例として、計算デバイスは、決定を別の計算デバイスに送信し得る。例えば、決定は、第１の患者が近い将来、ケア施設に再入院する可能性が高いか否か、第１の患者が特定の治療と必要とする確率、又は第１の患者についての他の所望の情報等の第１の患者に関する予測を含み得る。
【０１１２】
追加又は代替として、別の例として、計算デバイスは、治療デバイス及び／又はモニタリングデバイスを制御する信号を送信し得る。例えば、計算デバイスは、患者ロケーションにおける治療デバイスを制御する制御信号を送信し得る。幾つかの場合、計算デバイスは、治療デバイス又はモニタリングデバイス等の患者デバイスをオンに切り替え、オフに切り替え、又は設定を調整し得る。制御信号を患者デバイスに送信することに加えて、介護者への通知を送信することもできる。更に、幾つかの例では、制御信号は、閾値レベルの緊急性が特定される場合等の特定の状況でのみ、患者デバイスに送信し得る。
【０１１３】
本明細書に記載されるプロセス例は、考察目的で提供されるプロセスの単なる例である。多くの他の変形形態が本明細書での開示に鑑みて当業者に明らかになるであろう。更に、本明細書での開示は、プロセスの実行に適する枠組み、アーキテクチャ、及び環境の幾つかの例を記載しているが、本明細書での実施形態は、示され考察される特定の例に限定されない。更に、本開示は、説明され、図面に示されるように、様々な実施形態例を提供する。しかし、本開示は、本明細書に説明され示された実施形態に限定されず、当業者に既知であるか又は既知になるように他の実施形態に拡張することができる。
【０１１４】
本明細書に記載される様々な命令、プロセス、及び技法は、コンピュータ可読媒体に記憶され、本明細書におけるプロセッサにより実行されるプログラムモジュール等のコンピュータ実行可能命令の一般的な状況で考慮され得る。一般に、プログラムモジュールは、特定のタスクを実行するか、又は特定の抽象データ型を実施するルーチン、プログラム、オブジェクト、コンポーネント、データ構造、実行可能コード等を含む。これらのプログラムモジュール等は、ネイティブコードとして実行してもよく、又は仮想マシン又は他のジャストインタイムコンパイル実行環境等でダウンロードし且つ実行してもよい。通常、プログラムモジュールの機能は、様々な実施形態において必要に応じて結合又は分散され得る。これらのモジュール及び技法の実施形態は、コンピュータ記憶媒体に記憶され得、又は何らかの形態の通信媒体を介して伝送され得る。
【０１１５】
主題について、構造的特徴及び／又は方法論的動作に固有の言語で説明したが、添付の特許請求の範囲において定義される主題が必ずしも記載される特定の特徴又は動作に限定されないことを理解されたい。むしろ、特定の特徴及び動作は、特許請求の範囲を実施する形態例として開示される。
【符号の説明】
【０１１６】
１００  システム
１０２  サービス計算デバイス
１０４  患者ロケーション
１０６  ネットワーク
１０８  介護者計算デバイス
１１０  施設計算デバイス
１１２  プロセッサ
１１４  通信インタフェース
１１６  コンピュータ可読媒体
１１８  管理アプリケーション
１２０  オペレーティングシステム
１２２  センサデータ
１２４  介護者記録
１２６  統計モデル
１２８  トレーニングデータ
１３０  モデル特徴統合情報
１３２  階層データ構造
１３４  過去センサデータ
１３６  過去介護者記録
１３８  記憶装置
１４０  患者モニタリングデバイス
１４２  患者治療デバイス
１４４  患者デバイスセンサ
１４６  患者
１４８  介護者
１５０  ディスプレイ
１５２  ディスプレイ
１５４  通知
１５６  制御信号
１５８  判断
２００  データ構造
２０２  第１のレベルの詳細
２０４  第２のレベルの詳細
２０６  第３のレベルの詳細
３００  ツリーデータ構造
３０２  レベルゼロノードルート
３０４  流体ＩＮ
３０６  流体ＯＵＴ
３０８  薬剤
３１０  評価
３１２  ＩＶ流体
３１４  血液製剤
３１６  血液
３１８  尿
３２０  薬物１
３２２  薬剤２
３２４  ＩＶ流体
３２６  状態１重症度
３２８  状態２重症度
３３０  モルヒネ
３３２  生理食塩水
３３４  成分１
３３６  成分２
３３８  薬物１
３４０  薬物３
４００  データ構造
４０２  観察単位
４０４  患者ＩＤ
４０６  日付
４０８  標的変数
４１０  特徴
５０２  サブツリー
７００  プロセス
８００  プロセス
９００  プロセス
１０００  プロセス
【図１】
2018032394.tif 000003
【図２】
2018032394.tif 000004
【図３】
2018032394.tif 000005
【図４】
2018032394.tif 000006
【図５Ａ】
2018032394.tif 000007
【図５Ｂ】
2018032394.tif 000008
【図６】
2018032394.tif 000009
【図７】
2018032394.tif 000010
【図８】
2018032394.tif 000011
【図９】
2018032394.tif 000012
【図１０】
2018032394.tif 000013