JP6454762B2 - 階層データに基づくデバイス制御 - Google Patents

階層データに基づくデバイス制御 Download PDF

Info

Publication number
JP6454762B2
JP6454762B2 JP2017152896A JP2017152896A JP6454762B2 JP 6454762 B2 JP6454762 B2 JP 6454762B2 JP 2017152896 A JP2017152896 A JP 2017152896A JP 2017152896 A JP2017152896 A JP 2017152896A JP 6454762 B2 JP6454762 B2 JP 6454762B2
Authority
JP
Japan
Prior art keywords
features
integration
subset
information
determining
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Expired - Fee Related
Application number
JP2017152896A
Other languages
English (en)
Other versions
JP2018032394A (ja
Inventor
クアン タン シュウ
クアン タン シュウ
ワン ハイエン
ワン ハイエン
太亮 尾崎
太亮 尾崎
フェン シュアン
フェン シュアン
メータ アバイ
メータ アバイ
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Hitachi Ltd
Original Assignee
Hitachi Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Hitachi Ltd filed Critical Hitachi Ltd
Publication of JP2018032394A publication Critical patent/JP2018032394A/ja
Application granted granted Critical
Publication of JP6454762B2 publication Critical patent/JP6454762B2/ja
Expired - Fee Related legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • GPHYSICS
    • G16INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR SPECIFIC APPLICATION FIELDS
    • G16HHEALTHCARE INFORMATICS, i.e. INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR THE HANDLING OR PROCESSING OF MEDICAL OR HEALTHCARE DATA
    • G16H40/00ICT specially adapted for the management or administration of healthcare resources or facilities; ICT specially adapted for the management or operation of medical equipment or devices
    • G16H40/60ICT specially adapted for the management or administration of healthcare resources or facilities; ICT specially adapted for the management or operation of medical equipment or devices for the operation of medical equipment or devices
    • G16H40/63ICT specially adapted for the management or administration of healthcare resources or facilities; ICT specially adapted for the management or operation of medical equipment or devices for the operation of medical equipment or devices for local operation
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06NCOMPUTING ARRANGEMENTS BASED ON SPECIFIC COMPUTATIONAL MODELS
    • G06N20/00Machine learning
    • GPHYSICS
    • G16INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR SPECIFIC APPLICATION FIELDS
    • G16HHEALTHCARE INFORMATICS, i.e. INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR THE HANDLING OR PROCESSING OF MEDICAL OR HEALTHCARE DATA
    • G16H40/00ICT specially adapted for the management or administration of healthcare resources or facilities; ICT specially adapted for the management or operation of medical equipment or devices
    • G16H40/20ICT specially adapted for the management or administration of healthcare resources or facilities; ICT specially adapted for the management or operation of medical equipment or devices for the management or administration of healthcare resources or facilities, e.g. managing hospital staff or surgery rooms
    • GPHYSICS
    • G16INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR SPECIFIC APPLICATION FIELDS
    • G16HHEALTHCARE INFORMATICS, i.e. INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR THE HANDLING OR PROCESSING OF MEDICAL OR HEALTHCARE DATA
    • G16H40/00ICT specially adapted for the management or administration of healthcare resources or facilities; ICT specially adapted for the management or operation of medical equipment or devices
    • G16H40/60ICT specially adapted for the management or administration of healthcare resources or facilities; ICT specially adapted for the management or operation of medical equipment or devices for the operation of medical equipment or devices
    • GPHYSICS
    • G16INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR SPECIFIC APPLICATION FIELDS
    • G16HHEALTHCARE INFORMATICS, i.e. INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR THE HANDLING OR PROCESSING OF MEDICAL OR HEALTHCARE DATA
    • G16H50/00ICT specially adapted for medical diagnosis, medical simulation or medical data mining; ICT specially adapted for detecting, monitoring or modelling epidemics or pandemics
    • G16H50/20ICT specially adapted for medical diagnosis, medical simulation or medical data mining; ICT specially adapted for detecting, monitoring or modelling epidemics or pandemics for computer-aided diagnosis, e.g. based on medical expert systems

Description

病院及び他の医療ケア施設内の患者は、往々にして、様々な体の状態をモニタリングする複数の様々なタイプの医療デバイスに接続されるか、又は他の方法で医療デバイスによりモニタリングされ得る。これらのモニタはそれぞれ、患者についての情報を提供する1つ又は複数のセンサ及び処理構成要素を含み得る。更に、患者は、1つ又は複数の病状に治療を提供する医療デバイスにより治療され得る。これらのデバイスは、デバイスの動作を示すセンサデータを提供することもできる。更に、看護師、医師、医師アシスタント、及び他の医療専門家等の介護者も、介護者記録として患者についての情報を記録し得る。介護者記録に含め得る情報の例としては、患者の状態、予後、治療計画、処方、薬剤のタイプ、薬剤の頻度、実行されたテスト、介護者観察等を挙げ得る。
この膨大な量のデータにもかかわらず、患者の治療は、多くの場合、介護者により手動管理され得る所定の治療レジメンに基づいて実行される。例えば、介護者は、治療デバイス及び他の医療デバイスを手動でオン及びオフすることを担当し得る。更に、介護者の判断は、通常、特定の患者に治療を施すタイミング及び頻度の決定に使用され得る。しかし、介護者は、治療のタイミング、患者の予後、長期ケアプラン、再入院の確率等を特定する場合、利用可能なデータの全てを考慮に入れることができないことがある。
幾つかの実施形態は、階層データに基づいて分析を実行し、通知を送信し、判断し、且つ/又はデバイスを制御する装置及び技法を含む。一例として、計算デバイスは、複数の階層レベルを含む階層構造を有する階層データを受信し得る。計算デバイスは、少なくとも部分的に階層データに基づいて複数のモデル特徴を特定し得、且つ階層構造内の次の上位レベルに統合する候補として、第1のレベルにおける特徴のサブセットを選択し得る。計算デバイスは、特徴のサブセットの統合からの情報の予測損失が閾値未満であると判断し得、且つ特徴のサブセットではなく、次の上位レベルにおける統合特徴を含むように階層構造を改訂し得る。幾つかの例では、統計モデルは、改訂された階層構造に基づいてトレーニングされ得、且つ少なくとも部分的に判断を行い、通知を送信し、及び/又はデバイスを制御するために使用され得る。
詳細な説明が添付図を参照して記載される。図中、参照番号の1つ又は複数の最も左側の桁は、参照番号が最初に出現する図を識別する。異なる図での同じ参照番号の使用は、同様又は同一の物品又は特徴を示す。
幾つかの実施形態による、デバイスを制御し、且つ/又は通知若しくは他の情報を出力として提供することができるシステムのアーキテクチャ例を示す。 幾つかの実施形態による、階層データを含むデータ構造例を示す。 幾つかの実施形態による、階層データ関係を表すツリーデータ構造の例を示す。 幾つかの実施形態による、統計モデルと併用されるトレーニングデータセットのデータ構造例を示す。 幾つかの実施形態による、特徴が上位レベルノードに統合されるツリーデータ構造の例を示す。 幾つかの実施形態による、特徴が上位レベルノードに統合されるツリーデータ構造の例を示す。 幾つかの実施形態による、特徴の統合を終了した後のツリーデータ構造例を示す。 幾つかの実施形態による、統合される特徴を決定するプロセス例を示す流れ図である。 幾つかの実施形態による、選択された特徴を統合するか否かを判断するために図7のブロック716において実行され得るプロセス例を示す流れ図である。 幾つかの実施形態による、評価関数を選択することを含むプロセス例を示す流れ図である。 幾つかの実施形態による、患者デバイスを制御し、且つ/又は患者の状態を特定するプロセス例を示す流れ図である。
本明細書における幾つかの実施形態は、大量のデータを考慮して、治療デバイスの動作に関する決定を行い、及び/又は患者ケアに関する判断を行う技法及び装置に関する。一例として、患者デバイスからのセンサデータ及び介護者記録からの情報は、人間が完全には分析できない多数のデータ入力として受信し得る。データ入力は、治療デバイスのオン又はオフ、治療デバイスでの設定の変更、アラート又は他の通知の介護者への送信、患者の治療有効性についての判断実施、患者の予後についての判断実施、患者が再入院する確率に関する判断実施等の動作をモデルの出力に基づいて実行する管理アプリケーションにより、使用され得る出力を提供する統計モデル内の特徴として使用され得る。
統計モデルの特徴数(例えば、別個のデータ入力数)は非常に大きくなり得る(数百、数千、又はそれよりも多くの数等)ため、本明細書における実施形態は、上記機能に向けて統計モデルをトレーニング及び使用する前に、統計モデルの特徴を結合又は他の方法で統合しようとし得る。例えば、統計モデルの結果に実質的に影響を及ぼさずに統計モデルで計算すべき特徴数を低減することにより、本明細書における実施形態は、計算デバイスが統計モデルをより高速で実行できるようにし、それにより、統計モデルの計算を実行する計算デバイスの動作を改善する。更に、幾つかの例では、本明細書における特徴統合技法は、動作パラメータのより高速の決定の提供及び/又は医療デバイス又は他のデバイスのより大きい自律制御を可能にすることによる等、動作の制御に統計モデルの出力に依存する医療デバイス又は他のデバイスの動作を改善する。
本明細書における幾つかの例は、機械学習を利用し、多数の特徴に基づいて結果を予測する。更に、これらの特徴のうちの少なくとも幾つかは、1つ又は複数のデータ階層に編成し得る。更に、データ階層内の同じ階層レベル及び同じ中間上位レベルノード下の特徴は、予測のために元情報の大半を保持し、一方、特徴の階層編成も尊重するように、中間上位レベルノードに結合及び統合され得る。複数の特徴のセットを1セット当たりの特徴にロールアップ又は他の方法で統合することにより、本明細書における例は、モデルをトレーニングするため及びモデルを実行して結果を得るための両方のために、統計モデリングの計算負荷を低減する。更に、特徴の数がより少ないことにより、より低い処理コストでより複雑なモデル等の残りの特徴のより完全な調査が可能になり得る。
一例として、サービス計算デバイスは、特徴セット内の特徴サブセットを統合するか否かを判断する際、以前選択されなかった内部ノードの中から最大深度の内部ノードnを選択し得る。複数のそのようなノードがある場合、依然として選択されていない内部ノードnの1つをランダムに又は他の考慮事項に基づいて選択し得る。特徴は、データ階層を表すツリーデータ構造の終端ノード(「リーフノード」とも呼ばれる)に対応し得る。最大深度の選択された内部ノードnについて、nの子孫である終端ノードは、「n下の特徴」に対応する。選択された内部ノードnから下った終端ノードが結合可能な場合、計算デバイスは、n下のノードを別個のまま保つか、それともこれらの特徴をロールアップ又は他の方法で統合するかを続けて判断し得る。後述するように、計算デバイスは、選択された特徴の統合が、特徴により提供される情報量に実質的に影響するか否かを判断し得る。計算デバイスにより、提供される情報に統合が実質的に影響しないと判断される場合、計算デバイスは、nにおけるサブツリーを、統合特徴を有する終端ノードで置換し得る。計算デバイスは、予測される情報損失の閾値レベルに基づいて追加の特徴を統合するか否かを判断し得る。
本明細書における実施形態は、この技法を適用して、幾つかのサブツリーが終端ノードに変換されるように、データ階層内の特徴数を低減し得る。統計モデルのトレーニングデータセットは、統合された終端ノードに対応する新しい特徴を取得し、それらのサブツリー下に元々あった特徴を失う。別の例として、元の特徴が複数のデータ階層に編成される場合、本明細書における幾つかの実施形態は、特徴低減技法を各データ階層に別個に適用され得る。更に、本明細書における幾つかの例は、ツリーデータ構造及び関連する技法を使用して、特徴のデータ階層を記述するが、本明細書における例はツリーに限定されず、情報の階層表現を可能にする任意のタイプのデータ構造を包含し得る。
n下の特徴を特徴の何らかの集約関数(例えば、合計、平均等)で置換するか否かを判断するために、幾つかの例は、標的変数「y」を予測するための情報の予測される絶対的又は相対的損失を評価することを含み得る。例えば、情報の予測損失は、相互情報評価関数、R二乗評価関数、又はクラス間/クラス内評価関数に基づく等、yを予測する特徴セットの値に基づいて測定し得る。特徴の統合は、情報の予測損失が第1の閾値未満の場合且つ情報の合計累積絶対損失が第2の閾値を超えない場合に実行され得る。更に、幾つかの例は、同じアプリケーション内の異なる情報測度に基づいて異なる評価関数を使用し得る。適切な情報測度の選択は、標的変数の特性及び統合に考慮される特徴の特性に依存する。
単に特定の特徴をフィルタリングして除去するのではなく、本明細書における実施形態は、特徴を統合して、階層データ内の元の特徴の階層編成を尊重しながら、新しい統合特徴を構築する。更に、必要に応じて、初期特徴統合を適用した後、追加の反復で追加の特徴統合を実行し得る。
幾つかの実施形態は、複数の特徴に基づいて結果を予測し得る。ICU又は他の治療施設での患者の臨床観察、トピックにより階層に編成される文書、ウェブサイトへのユーザ訪問についての検索エンジンデータ等を含め、本明細書における技法から恩恵を受け得る階層特徴を含む多くのデータセット例がある。更に、幾つかの実施形態は、統計モデルを当てはめて、標的変数を予測する前に前処理段階を提供する。例えば、幾つかの例は、階層構造を尊重しながら、予測に元情報の大半を保持するように階層内の特徴を選択的に統合する。したがって、本明細書における技法を使用して、統計モデルのトレーニング及び使用中、計算負荷を低減し得、統計モデルを実行する計算デバイスをより高速且つより効率的に実行できるようにし得る。更に、統計モデルの出力に基づいて制御される医療デバイス又は他のデバイスをより高速且つより正確に制御し得る。
考察を目的として、幾つかの実施形態例は、センサデータ及び介護者記録等の階層データを受信し、階層データを統計モデルに適用して、介護者の計算デバイスに送信される通知及び/又は患者デバイスを制御するために送信される制御信号等の出力を提供する1つ又は複数の計算デバイスの環境で説明される。しかし、本明細書における実施形態は、提供される特定の例に限定されず、本明細書における開示に鑑みて当業者に明らかであるように、他のタイプのデータ、他のタイプの環境、他のシステムアーキテクチャ、他のタイプの数学的モデル等に拡張され得る。例えば、幾つかの例は、医療ケアを患者に提供する環境において説明されるが、本明細書における実施形態は、この環境に限定されず、階層データを統計モデルに適用して、デバイスの制御、通知の提供、判断の実施等に有用な出力を決定し得る他の環境に拡張され得る。
図1は、幾つかの実施形態による、デバイスを制御し、且つ/又は通知若しくは他の情報を出力として提供することができるシステム100のアーキテクチャ例を示す。システム100は、1つ又は複数のネットワーク106を通して等、1つ又は複数の患者ロケーション104と通信可能な少なくとも1つのサービス計算デバイス102を含む。更に、サービス計算デバイス102は、1つ又は複数のネットワーク106を通して1つ又は複数の介護者計算デバイスl08及び1つ又は複数の施設計算デバイス110と通信し得ることが可能であり得る。
別の例では、サービス計算デバイス102は、1つ又は複数のサーバ、パーソナルコンピュータ、又は任意の数の方法で実施され得る他のタイプの計算デバイスを含み得る。例えば、サーバの場合、モジュール、他の機能構成要素、及びデータ記憶装置の少なくとも一部は、サーバのクラスタ、サーバファーム又はデータセンタ、クラウドホスト計算サービス等の少なくとも1つのサーバで実施され得るが、他のコンピュータアーキテクチャを追加又は代替として使用し得る。示される例では、サービス計算デバイス102は、1つ又は複数のプロセッサ112、1つ又は複数の通信インタフェース114、及び1つ又は複数のコンピュータ可読媒体116を含むか、又はそれらに関連付けられ得る。
各プロセッサ112は、単一の処理ユニット若しくは幾つかの処理ユニットであり得、1つ若しくは複数の計算ユニット又は複数の処理コアを含み得る。プロセッサ112は、1つ又は複数の中央演算処理装置、マイクロプロセッサ、マイクロコンピュータ、マイクロコントローラ、デジタル信号プロセッサ、状態機械、論理回路、及び/又は動作命令に基づいて信号を操作する任意のデバイスとして実施することができる。例えば、プロセッサ112は、本明細書に記載されるアルゴリズム及びプロセスを実行するように特にプログラム又は構成される任意の適するタイプの1つ又は複数のハードウェアプロセッサ及び/又は論理回路であり得る。プロセッサ112は、本明細書に記載される機能を実行するようにプロセッサ112をプログラムすることができる、コンピュータ可読媒体116に記憶されたコンピュータ可読命令をフェッチし且つ実行するように構成することができる。
コンピュータ可読媒体116は、コンピュータ可読命令、データ構造、プログラムモジュール、又は他のデータ等の情報を記憶する任意のタイプの技術で実施される揮発性及び不揮発性メモリ及び/又はリムーバブル及び非リムーバブル媒体を含み得る。例えば、コンピュータ可読媒体116は、RAM、ROM、EEPROM、フラッシュメモリ、又は他のメモリ技術、光学記憶装置、固体状態記憶装置、磁気テープ、磁気ディスク記憶装置、RAIDストレージシステム、ストレージアレイ、ネットワーク接続ストレージ、ストレージエリアネットワーク、クラウドストレージ、又は所望の情報の記憶に使用することができ、計算デバイスによりアクセスすることができる任意の他の媒体を含み得るが、これらに限定されない。サービス計算デバイス102の構成に応じて、コンピュータ可読媒体116は、言及される場合、非一時的コンピュータ可読媒体がエネルギー、搬送信号、電磁波、及び/又は信号それ自体等の媒体を除外する限り、有形非一時的媒体であり得る。幾つかの場合、コンピュータ可読媒体116は、サービス計算デバイス102と同じ場所にあり得、一方、他の例では、コンピュータ可読媒体116は部分的にサービス計算デバイス102からリモートであり得る。
コンピュータ可読媒体116を使用して、プロセッサ112により実行可能な任意の数の機能構成要素を記憶し得る。多くの実施形態では、これらの機能構成要素は、プロセッサ112により実行可能であり、実行されると、本明細書においてサービス計算デバイス102に起因する動作を実行するようにプロセッサ112を特にプログラムする命令又はプログラムを含む。コンピュータ可読媒体116に記憶された機能構成要素は、管理アプリケーション118及びオペレーティングシステム(OS)120を含み得る。管理アプリケーション118は、患者ステータスのモニタリング、アラート、情報、又は他の通知の介護者への提供、及び/又は患者デバイスの制御等の様々なタスクをプロセッサ112に実行させるように実行可能な1つ又は複数のコンピュータプログラム、コンピュータ可読命令、実行可能コード、又はその部分を含み得る。更に、オペレーティングシステム120は、サービス計算デバイス102の様々な機能を制御及び管理し得る。幾つかの場合、機能構成要素は、コンピュータ可読媒体116の記憶部分に記憶され、コンピュータ可読媒体116のローカルメモリ部分にロードされ、1つ又は複数のプロセッサ112により実行され得る。本明細書における開示の恩恵を受ける当業者には、多くの他のソフトウェア構成及び/又はハードウェア構成が明らかになるであろう。
更に、コンピュータ可読媒体116は、本明細書に記載される機能及びサービスの実行に使用されるデータ及びデータ構造を記憶し得る。例えば、コンピュータ可読媒体116は、管理アプリケーション118により使用され得るセンサデータ122、介護者記録124、1つ又は複数の統計モデル126、トレーニングデータ128、モデル特徴統合情報130、及び階層データ構造132を記憶し得る。例えば、管理アプリケーション118は、センサデータ122及び介護者記録124を1人又は複数の患者から受信し得、1つ又は複数の統計モデル126内のこの情報を使用して、各患者についての情報を特定し得る。
更に後述するように、管理アプリケーション118は、1つ又は複数の統計モデル126を使用して、患者デバイスの制御、介護者へのアラート又は他の通知の送信、患者ケアのモニタリング、患者結果の予測等の機能を実行し得る。幾つかの例では、トレーニングデータ128は、施設計算デバイス110に関連する記憶装置138から受信される複数の過去の患者の過去センサデータ134及び過去介護者記録136を含み得る。トレーニングデータ128は、階層データとして受信し得、階層データ構造132として配置される。管理アプリケーションは、モデル特徴統合情報130を使用して、1つ又は複数の統計モデル126で使用すべき階層データ構造132内の幾つかの特徴を結合及び統合し得る。サービス計算デバイス102は、プログラム、ドライバ等を含み得る他の機能構成要素及びデータ並びに機能構成要素により使用又は生成される他のデータを包含又は保持することもできる。更に、サービス計算デバイス102は、多くの他の論理的、プログラム的、及び物理的構成要素を含み得、そのうちの上述されたものは、本明細書における考察に関連する単なる例である。
通信インタフェース114は、1つ又は複数のネットワーク106を介する等、様々な他のデバイスとの通信を可能にする1つ又は複数のインタフェース及びハードウェア構成要素を含み得る。したがって、通信インタフェース114は、患者ロケーション104、介護者計算デバイス108、及び施設計算デバイス110と通信するためのネットワーク106への接続を提供する1つ又は複数のポートを含み得るか、又は結合し得る。例えば、通信インタフェース114は、本明細書の他の箇所で更に列挙されるように、LAN(ローカルエリアネットワーク)、WAN(広域ネットワーク)、インターネット、ケーブルネットワーク、セルラネットワーク、無線ネットワーク(例えば、Wi−Fi)及び有線ネットワーク(例えば、光ファイバ、Ethernet、ファイバチャネル)、直接接続、及びBLUETOOTH(登録商標)等の近距離通信等のうちの1つ又は複数を通して通信を可能にし得る。
患者ロケーション104は、患者の部屋又は患者を治療し得る任意の他のロケーションであり得る。幾つかの例では、各患者ロケーションl04は、1つ又は複数の患者モニタリングデバイス140及び/又は1つ又は複数の患者治療デバイス142を含み得る複数の患者デバイスを含み得る。更に、患者デバイスセンサ144をモニタリングデバイス140及び/又は治療デバイス142に関連付けて、患者の状態、モニタリングデバイス140の状態、及び/又は治療デバイス142の状態を検出する等を行い得る。一例として、少なくとも1人の患者146が各患者ロケーション104に存在し得、モニタリングデバイス140によりモニタリングされ得、治療デバイス142により治療され得る。更に、幾つかの場合、患者治療デバイス142は、患者モニタリングデバイス140であってもよく、患者の状態についてのセンサデータを提供するセンサ144のうちの1つ又は複数を含み得る。
幾つかの例では、各患者デバイス140、142は、ネットワーク106を介してサービス計算デバイス102と通信することができ、それにより、センサデータ122をサービス計算デバイス102に送信する等を行い得る。他の例では、患者デバイス140、142の一方は、患者ロケーション104における他方の患者デバイス140、142からセンサデータ122を収集し、センサデータ122をサービス計算デバイス102に送信する計算デバイスを含み得る。幾つかの例として、患者モニタリングデバイス140は、心臓モニタ、パルスオキシメータ、カプノグラフモニタ、呼吸数モニタ、神経モニタ、血糖値モニタ、胎児モニタ、体温モニタ、血液動態モニタ、及び/又は様々な他のタイプのモニタリングデバイスを含み得る。更に、患者治療デバイス142は、人工呼吸器、静脈内(IV)注入ポンプ、ペースメーカー、胸腔チューブ、補給チューブ、麻酔器、人工心肺装置、透析装置、導尿カテーテル、除細動器、及び/又は様々な他のタイプの治療デバイスを含み得る。
介護者計算デバイス108及び施設計算デバイス110は、デスクトップ、ワークステーション、サーバ、ラップトップ、タブレット計算デバイス、モバイルデバイス、スマートフォン、ウェアラブルデバイス、又はネットワークを介してデータを送信可能な任意の他のタイプの計算デバイス等の任意の適するタイプの計算デバイスであり得る。幾つかの場合、介護者計算デバイス108及び/又は施設計算デバイス110は、サービス計算デバイス102に関して説明したものと同様であるが、本明細書において考察される様々な機能を実行できるようにする異なるデータ及び機能構成要素を有するハードウェア構成を含み得る。一例として、介護者計算デバイス108は、患者ロケーション104訪問時に介護者148が携帯するタブレット又はラップトップ等のポータブル計算デバイスであり得、施設計算デバイス110は、例えば、ケア施設又は別のロケーションにオンサイトで配置されるサーバ、ワークステーション、デスクトップコンピュータ等であり得る。
幾つかの場合、施設計算デバイス110は、患者記録を記憶装置138に記憶するサーバであり得、患者記録は、複数の患者146について過去に収集され、1つ又は複数の統計モデル126のトレーニングデータ128として使用され得る過去介護者記録136及び過去センサデータ134を含み得る。更に、幾つかの例では、施設計算デバイス110のうちの1つ又は複数は、患者ロケーション104が、例えば、ICU等に配置されるケア施設内の中央ロケーション等における、ケア施設での個々の患者のモニタリングを可能にするモニタリング計算デバイスであり得る。介護者計算デバイス108は、ディスプレイ150を含み得、施設計算デバイス110はディスプレイ152を含み得る。多くの他の変形形態が本明細書における開示の恩恵を受ける当業者に明らかになるであろう。
幾つかの例では、看護師、医師、医師のアシスタント、付添人、又は他の医療専門家等の介護者148は、患者ロケーション104にいる患者146を訪問し得、介護者計算デバイス108を使用して、特定の患者146の介護者記録124を入力するか、又は他の方法で生成し得る。例えば、介護者記録124は、患者の状態、患者モニタリングデバイス140の設定又は出力、患者治療デバイス142の設定又は出力、介護者観察等に関連し得る。幾つかの例では、介護者記録124は、介護者148が書式での選択等を行えるようにすることによる等、構造化データとして構造化されて入力され得る。代替的には、他の例では、介護者記録124は、受信後、サービス計算デバイス102又は施設計算デバイス110により分析し得る手書き記録、タイプ入力された記録、又は他の方式での自由形式データであり得る。介護者記録124は、介護者148による入力時、介護者148が特定の患者146に面会し終えたとき、介護者のシフト終了時等のときに各介護者計算デバイス108によりサービス計算デバイス102に送信され得る。代替的には、介護者記録124はまず、施設計算デバイス110に送信され得、施設計算デバイス110から、サービス計算デバイス102に送信され得る。同様に、幾つかの例では、施設計算デバイス110はまず、センサデータ122を受信し得、センサデータ122をサービス計算デバイス102に転送し得る。
1つ又は複数のネットワーク106は、イントラネット等のローカルエリアネットワーク(LAN)、インターネット等の広域ネットワーク(WAN)、セルラネットワーク等の無線ネットワーク、Wi−Fi等のローカル無線ネットワーク、及び/又はBLUETOOTH(登録商標)等の近距離無線通信、光ファイバ、Ethernet、ファイバチャネル、若しくは任意の他のそのようなネットワークを含む有線ネットワーク、直接有線接続、又はそれらの任意の組合せを含め、任意のタイプのネットワークを含み得る。したがって、1つ又は複数のネットワーク106は、有線通信技術及び/又は無線通信技術の両方を含み得る。そのような通信に使用される構成要素は、少なくとも部分的にネットワークのタイプ、選択された環境、又は両方に依存することができる。そのようなネットワークを介して通信するためのプロトコルは、周知であり、本明細書では詳述しない。したがって、サービス計算デバイス102、患者ロケーション104、介護者デバイス108、及び施設計算デバイス110は、有線又は無線接続及びそれらの組合せを使用して、1つ又は複数のネットワーク106を介して通信することが可能である。
図1の例では、管理アプリケーション118を実行して、過去センサデータ134及び過去介護者記録136をトレーニングデータ128として受信し得る。統計モデル126は、特徴と呼ばれるトレーニングデータ128から得られる多くの情報を考慮に入れ得る。本明細書での実施形態によれば、特徴及び他のトレーニングデータ128は、階層データとして配置され得、1つ又は複数の統計モデル126内で使用されるデータ階層の編成を維持しながら、幾つかの特徴を統合し得る。本明細書での実施形態により特徴数を低減した後、統合特徴を有する改訂階層データ構造を使用して統計モデルをトレーニングし、正確性についてチェックし、次に、患者の状態の特定、患者デバイスの制御等に使用し得る。統計モデル126は、定期的に更新され、新しいトレーニングデータに基づいて再トレーニングされて、統計モデル126を最新の状態に保ち得る。本明細書での幾つかの実施形態で使用し得る適する統計モデル126の例としては、予測モデル、決定木、人工ニューラルネットワーク、分類器、線形回帰モデル等の回帰モデル、サポートベクターマシン、及びマルコフモデル、隠れマルコフモデル等の確率論的モデルを挙げることができる。
1つ又は複数の統計モデル126が生成及びトレーニングされた後、管理アプリケーション118は、選択された患者146のセンサデータ122及び介護者記録124を1つ又は複数の統計モデル126への入力として使用して、選択された患者146の状態を分析し、出力を生成する等を行い、アラート又は他の通知154を介護者デバイス108又は施設計算デバイス110のうちの少なくとも一方に送信する等を行う。例えば、通知をディスプレイ150及び/又は152にそれぞれ提示して、介護者148又は医療人員に患者の状態を通知し得る。
追加又は代替として、管理アプリケーション118は、特定の患者治療デバイス142又は特定の患者モニタリングデバイス140を制御する制御信号156を送信する等により、1つ又は複数の患者デバイス140、142の設定を自動的に調整し得る。例えば、治療デバイス142がIV注入ポンプであり、統計モデル126を使用して実行された分析により、患者が受け取っているIV流体が多すぎることが示されると考える。制御信号156は、注入ポンプを制御して、患者へのIV流体フローを低減し得る。別の例として、制御信号156は、モニタリングデバイス140を制御して、オンではなかったが、示された患者の状態に基づいて、選択された患者を更にモニタリングするのに使用され得る特定のモニタリングデバイス140をオンにする等を行い得る。
更に、幾つかの場合、統計モデル126の1つは、診断、予後、長期ケア治療の有効性、患者が退院した場合、ケア施設への再入院が必要になるか否かの判断等、患者146についての判断158を下し得る。管理アプリケーション118は、この判断を介護者計算デバイス108又は施設計算デバイス110のうちの少なくとも一方に送信し得る。
1つ又は複数の統計モデル126を準備するために、本明細書での実施形態は、過去センサデータ134及び過去介護者記録136に基づいて利用可能な特徴を特定し得る。この情報から、管理アプリケーション118は、1つ又は複数の階層データ構造132を生成し得る。管理アプリケーション118は次に、モデル特徴統合情報130を使用して、特定の統計モデル126の特徴の全体数(すなわち、特定の標的変数y)を低減しようとし得る。例えば、特徴統合技法は、階層構成を維持しながら、統計モデル126により提供される結果に影響しない情報の実質的な損失なく、確立されたデータ階層下でロールアップ又は他の方法で統合され得る特徴を識別することを含む。特定の統計モデル126の特徴数を低減することの詳細について、更に以下に考察する。
図2は、幾つかの実施形態による、階層データを含む、例としてのデータ構造200を示す。この例では、観察単位(例えば、過去又は現在の患者)の数に関するデータが利用可能であり、このデータを使用して、幾つかの可能な結果から結果を予測する統計モデルを構成及びトレーニングし得ると考える。一例として、病院のICU等のケア施設では、現在、人工呼吸器を付けている患者毎に、その患者が人工呼吸器を外す準備ができているか否かを予測することが望ましいことがある。患者デバイスの様々なセンサは、患者をモニタリングし、センサデータを提供し得る。加えて、介護者記録は、患者についての臨床観察、現在の換気スケジューリング、及び患者についての他の情報を提供し得る。センサデータ及び介護者記録は両方とも、本明細書では「特徴」と呼ばれる潜在的な予測子を提供し得る。例えば、各患者に利用可能な多数、例えば数百、数千、又はそれよりも多くの特徴を有することが一般的であり得る。これらの特徴は、1つ又は複数のデータ階層に編成され得る。
データ構造200は、臨床観察で使用される12の記述を含むデータ例の一部を含む表である。例えば、近代電子健康記録システムでは、記述の数は数千以上であり得る。更に、これらの記述は、通常、階層に編成され、階層は、メニュー、サブメニュー、サブサブメニュー等を使用してデータ入力プロセスを促進し、詳細の異なる階層レベルでデータをまとめることを可能にする。したがって、この例では、第1のレベルの詳細202は、「流体IN」、「流体OUT」、「薬剤」、「評価」等を含む。第2のレベルの詳細204は、第1のレベル202のサブメニューを含み得る。例えば、「IV流体」及び「血液製剤」を「流体IN」のサブメニューに包含し得、「血液」及び「尿」を「流体OUT」のサブメニューに包含し得、「薬物」及び「IV流体」を「薬剤」のサブメニューに包含し得、「状態」を「評価」のサブメニューに包含し得る。加えて、第3のレベルの詳細206は、第2のレベル204のサブメニューを含む。例えば、「モルヒネ」及び「生理食塩水」を「IV流体」のサブメニューに包含し得、「成分1」及び「成分2」を「血液製剤」のサブメニューに包含し得、「薬物1」及び「薬物3」を「IV流体」のサブメニューに包含し得る。更に、3レベルの詳細がこの例に示されるが、幾つかの他の例では、より多くの詳細レベルがあり得る。したがって、管理アプリケーション118は、介護者記録と共に、臨床観察で使用された記述を受信し得、示されるように、情報を様々な階層レベルに解析して、受信データの階層関係を特定し得る。例えば、モニタリングされた状態、センサデータのタイプ、センサデータの単位等に基づいて、受信されたセンサデータも同様に階層関係に配置され得る。
図3は、幾つかの実施形態による、階層データ関係を表すツリーデータ構造300の例を示す。この例では、図2のテーブルデータ構造200からのデータは、図2のデータ構造200に含まれる記述を表す複数のノードを含むツリーデータ構造300として表される。ツリーデータ構造300は、データ階層の最上部にあり、下にある全ての他のノードを含むレベル0ノード「ルート」302を含む。レベル1ノードは、「流体IN」304、「流体OUT」306、「薬剤」308、及び「評価」310を含む。例えば、「流体IN」及び「流体OUT」は、患者に入る流体及び患者から出る流体を指し得、「薬剤」は患者の治療に使用される薬剤を指し得、「評価」は、介護者により実行される患者の様々な種類の評価を指し得る。更に、幾つかの例では、より多くのレベル1ノードを包含し得る。
更に、レベル2ノードは、流体IN304の下に「IV流体」312及び「血液製剤」314を含み、流体OUT306の下に「血液」316及び「尿」318を含み、薬剤308の下に「薬物1」320、「薬物2」322、及び「IV流体」324を含み、評価310の下に「状態1重症度」326及び「状態2重症度」328を含む。加えて、レベル3ノードは、IV流体312の下に「モルヒネ」330及び「生理食塩水」332を含み、血液製剤314の下に「成分1」334及び「成分2」336を含み、IV流体324の下に「薬物1」338及び「薬物3」340を含む。ツリー300は、図3で輪郭が強調表示されて示される12の終端ノード316、318、320、322、326、328、330、332、334、336、338、及び340を含み、各終端ノードは、図2のテーブルデータ構造200からとられた元の記述を含む。
各終端ノードの各記述は、何らかの関連付けられた値を有し得、値は、数値測定値、物理的数量、カテゴリクラス(「オン」又は「オフ」、「1」又は「0」、「真」又は「偽」等)、介護者により入力されたフリーテキスト等であり得る。この例での予測問題では、トレーニングデータセットは、これらの値及び複数の他のデータソースから構築され、図3に示されるデータ階層に基づき得る。トレーニングデータセットの例について図4に関して後述する。
図4は、幾つかの実施形態による、統計モデルにより使用されるトレーニングデータセットの例としてのデータ構造400を示す。この例では、観察単位402は、患者ID404及び日付406を含む特定の患者と日付との組合せであり得る。加えて、標的変数y408は、統計モデルにより予測すべき標的変数であり得る。更に、トレーニングデータセット400は、図2の臨床観察記述又は同等に図3のツリーデータ構造300の終端ノードに対応する特徴1 410(1)、特徴2 410(2),...,特徴K 410(K)等の複数の特徴を含み得る。幾つかの場合、トレーニングデータセット400には数百又は数千の特徴410があり得る。
臨床観察等の未処理データソースからのそのようなトレーニングデータセット400の構築は、通常、未処理データ値を観察単位のレベルに集約することを含み得る。そのようなトレーニングデータセット400及び上述した特徴階層を所与として、本明細書での実施形態は、複数の特徴410を単一の特徴に統合し得る。これにより、より少数の特徴を有するより小さいトレーニングデータセットを作成することができる。本明細書での幾つかの実施形態は、終端ノードの統合を同じサブツリー下の他の終端ノードとの統合に制限し得、その理由は、これにより階層構造が維持されるためである。トレーニングデータセット内の特徴数を低減することにより、統計モデルのサイズが低減し、統計モデルが実行されるたびに管理されるデータ量も低減し、それにより、統計モデルを実行し得る速度を増大させ、計算を実行する計算デバイスの動作を改善させる。これは、アラート又は他の通知の介護者への送信及び/又はオンへの切り替え、オフへの切り替え、又は患者デバイスの調整等の患者デバイスを制御して、患者デバイスの動作を改善する制御信号の送信等の統計モデルに基づいて判断することができる速度も改善する。更に、特徴の統合により、残りの特徴を同様の処理コストでより複雑なモデルでより効率的に使用することができる。
図5A及び図5Bは、幾つかの実施形態による、特徴がより上位レベルのノードに統合されるツリーデータ構造300の例を示す。この例では、管理アプリケーションは、ツリーの終端ノードを調べて、任意の終端ノードをツリー階層の次の上位レベルのノードに統合し得るか否かを調べ得る。図5Aでは、終端ノード330に対応する特徴であるモルヒネ及び終端ノード332に対応する特徴である生理食塩水という2つの特徴が、IV流体312である直上のレベルのノードへの統合(すなわち、ロールアップ)に考慮される。したがって、この場合、サブツリー502はノード312、330、及び332を含む。モルヒネノード330及び生理食塩水ノード332は両方とも、IV流体中間ノード312の下にある。終端ノード330及び332は両方とも、ミリリットル単位で表現され得ると考える。したがって、IV流体ノード312により表される統合特徴は、患者に提供されるIV流体の総量として表わされ得る。別の例として、終端ノード330及び332の特徴が、特定の流体であるモルヒネ及び生理食塩水がそれぞれ投与された回数のカウントである場合、カウントを一緒に加算して、IV流体ノード312により表される特徴として投与されたIV流体の総カウントを得ることにより、これらのカウントを結合し得る。
いずれの場合でも、又は測定若しくは表現の他の単位の場合、統合実行への考慮事項はどの程度情報が失われるかである。この例では、幾つかの統計モデルの目的で、特定の日に患者が受け取ったモルヒネ量及び患者が受け取った生理食塩水量を考慮する代わりに、特定の日に患者が受け取ったIV流体の総量として、2つの数量を結合することは略同じ程度の有益性を有し得る。他方、他の統計モデルでは、患者が受け取ったモルヒネ量及び/又は生理食塩水量は重要な考慮事項であり得、したがって、幾つかの特徴の統合にこれらの2つを結合することは望ましくないことがある。したがって、本明細書での実施形態は、統計モデルにより予測されるべき特定の標的変数yを特定するために、特定の特徴の結合が特定の統計モデルで許容可能であるか否かを判断する。
一例として、上述したトレーニングデータセット400及びツリーデータ構造300の特徴階層を所与として、本明細書での実施形態は、複数の特徴を1つの特徴に統合することを検討し、それにより、より少数の特徴を有するトレーニングセットを取得し得る。更に、幾つかの実施形態は、同じサブツリーの下に他の終端ノードを有する終端ノードの統合に制限され、その理由は、これにより、データの階層構造が維持されるためである。加えて、複数の特徴を次の上位レベルの1つの特徴に結合する集約関数は、ユーザ若しくは特定の特徴の他のソースにより提供されてもよく、又は代替的に統合すべき特徴のコンテキスト若しくはカテゴリから決定され得る。
図5Aに示される例では、管理アプリケーションは、特徴の表現のカテゴリを決定し得る。例えば、モルヒネノード330の特徴及び生理食塩水ノード332の特徴が両方とも、容量単位等、例えば、IV流体のmL単位という同じ物理的数量として表わされ得る場合、これらの特徴は、加算により統合され得、患者に投与されたIV流体の総量に関して表現され得る。他方、モルヒネノード330の特徴及び生理食塩水ノード332の特徴が両方とも、各流体が投与された回数のカウントで表される場合、これらの特徴は、患者に投与されたIV流体のカウントの総数の加算により統合され得る。同様に、ノード330及び332の特徴が、各流体が存在したことの真又は偽インジケータとして表わされ得る場合、統合特徴は、任意の種類のIV流体が投与されたことのインジケータであり得る。したがって、上記の場合、終端ノード330及び332は互いと同等であり、したがって、統合から失われる情報量が閾値未満であると予測される場合に及び/又は後述する他の考慮事項に基づいて統合可能である。
他のタイプの特徴を統合することもできる。例えば、「評価」ノード310の下の「状態1重症度」ノード326及び「状態2重症度」ノード328が調べられる場合、これらは各状態評価の形態に応じて結合可能であることもあれば、結合可能ではないこともある。一例として、状態1及び状態2の評価が同じ尺度(例えば、0〜100)で測定され、方向が一貫する、例えば、両方で値が大きいほど良好である場合、結合された特徴は2つの評価の2つの値の平均として表わされ得る。
他方、幾つかの特徴は、有意味に結合することが可能ではないことがある。例えば、ノード312における特徴「IV流体」は、液体の総量で表され、ノード314における「血液製剤」特徴が、任意の種類の「血液製剤」が投与された回数を示す場合、ノード312における「IV流体」特徴をノード314における「血液製剤」特徴と結合することは意味をなさない。したがって、2つの特徴の単位又は他のカテゴリが一致しない場合、2つの特徴の統合は通常検討されない。
図5Bに示されるように、ノード330からの「モルヒネ」特徴とノード332からの「生理食塩水」特徴とを統合すると、ノード330及び332がデータ構造300から除去される。更に、IV流体ノード312は、ここでは、終端ノードであり、使用される集約関数に基づいて、患者に送達されたIV流体の総量等のノード312における統合IV流体特徴を表す特徴「IV流体」を含む。したがって、ノード330及び332からの特徴を統合して、ノード312における新しい統合特徴にすることを通して、図5Aのサブツリー502は、ここでは、図5Bの終端ノード312で置換されている。トレーニングデータセットは、「モルヒネ」値及び「生理食塩水」値にそれぞれ対応するノード330及び332における2つの元の特徴の代わりに使用される、新しい統合特徴、すなわち「IV流体」特徴を用いて生成され得る。
本明細書での幾つかの実施形態は、統合特徴の評価に基づいて特定の特徴の統合を実行すべきか否かを判断し得る。一例として、現在の特徴がx,x,...,x(サブツリーの終端ノードに対応する)であると考える。統合特徴uは、u=f(x,x,...,x)として表わされ得、式中、fは所与の集約関数である。所与の標的変数yを予測することに関して特徴をランク付け又は他の方法で評価するために、幾つかの異なる技法を適用してもよい。選択された特徴の統合を実行すべきか否かの評価に使用し得るランク付け関数の幾つかの例としては、
(1)相互情報:I(y,x)として示される各x及びyの間の相互情報を特定すること、
(2)R二乗:r(y,x)として示される各xと標的変数yとの間の相関係数を特定すること、又は
(3)クラス間/クラス内比率:標的変数yがカテゴリ変数である場合、各xのクラス間距離とクラス内距離との比率と特定すること
が挙げられる。
上記評価関数(1)〜(3)は、u=f(x,x,...,x)を用いて{x,x,...,x}を集合として比較するように一般化し得、比較を使用して、統合に検討されている選択された特徴を統合するか否かを判断し得る。この比較技法は、特徴の組の値を測定して、標的変数yを予測するように一般化することができる任意のランク付け関数を使用して実行され得る。
少なくとも部分的に統合検討中の特徴x,x,...,xの性質及び標的変数yの特性に応じて、異なる場合で異なる評価関数を適用することが最適であり得る。幾つかの例では、幾つかの異なるランク付け関数を同じ階層内で使用し得る。後述するように、上記ランク付け関数(1)〜(3)は、一般化され得、特定の特徴を統合すべきか否かの判断に使用され得る。更に、異なるランク付け関数が異なるタイプの特徴及び/又は異なる標的変数yに適し得る。
(1)相互情報:第1の例として、相互情報は、統合を実行すべきか否かを判断するように一般化され得る。相互情報は、2つの変数間の相互依存性の尺度である。例えば、相互情報は、別の変数を通して、ある変数について得られる情報量を定量化し得る(ビット等の単位で)。相互情報の概念は、確率変数に保持される「ランダム性」を定義する確率変数のエントロピーの概念にリンクされる。
相互情報を評価関数として適用する場合、集合{x,x,...,x}はuより下にランクされないことが保証され、その理由は、I(y;x,x,...,x)≧I(y;f(x,x,...,x))であるためであり、式中、fは集約関数である。したがって、これらの相互情報値間の差ΔIを計算し得、差ΔIは、x,x,...,xをuに統合する場合の情報の損失を表す。一例として、情報の損失は「ビット」単位で測定され得、ビットは次元のない数量である。
幾つかの場合、管理アプリケーションは、差ΔIが固定の予め指定される閾値ビット数未満の場合に特徴の統合を決定し得る。別の例として、管理アプリケーションは、ΔI/I(y;x,x,...,x)に基づいて特定し得、0〜1の値を提供し得る情報の相対損失を特定することに基づいて特徴を統合すると決定し得る。例えば、情報の相対損失が0.05等の指定された統合閾値b未満である場合、統合を実行し得る。
相互情報の特定は、標的変数及び特徴が離散している場合、すなわち、小さい数の離散値をとる場合に利用され得る。そのような事例の一例は、標的変数yがカテゴリであり、特徴が、特定の記述が存在することの真/偽インジケータである場合である。y又は特徴が離散していない場合、ビニングを使用して、およその相互情報を計算し得る。他方、各特徴が2つのみの可能値を有する場合であっても、p個の特徴全ての結合は2個の可能値を有することができる。特徴数が大きい場合、計算は遅いか又はトレース不可能になり得る。
(2)R二乗:第2の例として、相関係数は、統合を実行すべきか否かを判断するための評価関数として一般化され得る。例えば、相関係数は、2つのランク間の類似度を測定し得、2つのランク間の関連の有意性を評価するのに使用され得る。相関係数を一般化するために、本明細書での幾つかの例は、多重線形回帰で「R二乗」としても知られる多重相関R(y;x,x,...,x)の係数を使用し得る。値1−Rは、標的変数yがyの二乗和に相対してx,x,...,xで回帰する場合、RSS(y;x,x,...,x)として示される残差の二乗和である。この場合の概念はΔRSSを計算することであり、ΔRSSは、標的変数yがu=f(x,x,...,x)で回帰する場合及び標的変数yがx,x,...,xで回帰する場合での残差二乗和間の差である。一般に、前者が後者と少なくとも同じ大きさの残差二乗和を有する保証はない(相互情報例と異なる)が、これは、uがu=x+x+...+xである一般的な場合を含むx,x,...,xの線形関数である場合、真である。
加えて、更に一般的に、yの一般化線形モデルをx,x,...,x及びuに当てはめ得、2つのモデルの逸脱の差を比較し得る。一般化線形モデルの一例は対数回帰であり、これは、標的変数yが2つの可能値を有するカテゴリ変数である場合に適用可能である。表記ΔRSSは、この場合を包含するように拡張され得る。したがって、幾つかの例では、管理アプリケーションは、ΔRSSが指定の閾値未満である場合、統合を実行すると決定し得る。他の例では、管理アプリケーションは、残差二乗和の相対変化ΔRSS/RSS(y;x,x,...,x)が0.05等の指定された統合閾値b又は他の指定される統合閾値b未満である場合、統合の実行を決定し得る。線形回帰の場合、残差二乗和の相対変化は1−Rの相対変化に等しい。
残差二乗和の相対変化(相対逸脱を含む)を使用して、統合を実行すべきか否かを判断することは、特徴が略連続した線形回帰モデルであるか、又は標的変数yの当てはめに適切な一般化線形モデルである場合、良好に機能し得る。R二乗評価関数は、通常、標的変数yが2つの可能値、例えば、真/偽、1/0等を有するカテゴリである場合に使用され得る。この技法は、程々の数の特徴に向けて良好にスケーリングすることもできる。
(3)クラス間/クラス内比率:第3の例として、クラス間距離とクラス内距離との比率は、統合を実行すべきか否かを判断するための評価関数として使用され得る。例えば、個々の特徴xから特徴ベクトル(x,x,...,x)へのクラス間/クラス内距離は、デカルト距離又はp次元空間内の別の距離尺度を使用することにより一般化され得る。次に、(x,x,...,x)及びu=f(x,x,...,x)のクラス間/クラス内距離の比率の変化を比較し得る。次に、選択された特徴を統合すべきか否かについての判断は、変化又は相対変化を指定の閾値と比較することに基づく。
クラス間/クラス内距離を使用するために、標的変数yはカテゴリであり得る。標的変数yが3つ以上のクラスを有する場合、標準ロジスティック回帰を適用することはできず、したがって、ロジスティックモデルからのΔRSSを使用することができないことがある。そのような場合、本明細書での実施形態は、クラス間/クラス内距離に適用され得る。例えば、3つ以上のクラスがあり得、したがって、この評価技法は、yが3つ以上の距離値を有する実施形態に使用され得る。多くの共通距離メトリックの場合、クラス間/クラス内距離計算は、観察数及び特徴数と共に良好にスケーリングする。
1つ又は複数の組の特徴を統合した後、管理アプリケーションは、統合を停止するか、それとも追加の組の特徴を統合するかを判断し得る。管理アプリケーションは、停止するか、それとも続けるかを判断する場合、幾つかの停止基準を適用され得る。第1の例として、管理アプリケーションは、全ての内部ノードが検討された場合、停止を決定し得る。この技法は、同じ計算をエンドレスに繰り返すことを回避し、最も厳しくない基準である。しかし、この技法の一欠点が生じ得、その理由は、次の上位ノードへ統合すべきか否かの判断が、各ノードでローカルに閾値を満たすことに基づく等の他の中間ノードでの判断から独立して行われるためである。相互情報を例として使用すると、相互情報ΔIの損失は、個々では小さく、閾値未満であり得るが、集合的には、続くモデリングの予測精度を損ない得る、情報の許容できないほど大きい累積損失になり得る。
この問題を軽減する一技法は、相互情報の累積損失への情報合計損失(TLI)閾値を設定し、この閾値を超える前に統合を停止することである。この概念は、ΔRSS、クラス間/クラス内距離の変化、及び他の評価関数並びにΔI/I(y;x,x,...,x)等の相対的な相手方に拡張される。複数の評価関数が使用される場合、別個のTLI閾値を各評価関数に設定し得る。したがって、複数の評価関数が同じデータセット内の異なる特徴の統合に使用される場合、第1のTLI閾値を第1の評価関数に設定し得、第2のTLI閾値を第2の評価関数に設定し得、以下同様である。第1の評価関数で第1のTLI閾値に達する場合、第1の評価関数に対応する特性を有する特徴の統合を停止し得るが、第2の評価関数に対応する特性を有する特徴の統合は、第2のTLI閾値に達するまで継続され得、以下同様である。
幾つかの例では、最大深度の複数の内部ノード(すなわち、図5Aでのノード312、314、306、324、及び310)の集合Sのトラバースは、ランダムで実行されて、これらのノードの終端ノードを各内部ノードに統合するか否かを判断し得る。しかし、幾つかの場合、最大深度のこれらの内部ノードをトラバースする他の技法を使用して、よりよい結果を達成し得る。一例として、最大深度の内部ノードの集合Sをトラバースして、各統合の比較価値及びコストを考慮に入れ得る。例えば、各統合に同じ値が割り当てられる場合、ある解決策は、コストが増大する順、すなわち、TLI閾値に達するまで最低コストからより高いコストに増大する順にノードを選択することである。
代替的には、別の例として、幾つかの実施形態は、より多数の特徴を結合するそれらの特徴の統合を選択することを含み得、結合されている特徴の数に基づいて値を設定し得る。しかし、これは、NP困難な最適化問題に繋がり得る。したがって、この問題の解決が実際的であるか否かは、少なくとも部分的にS内のノード数に依存し得、S内のノード数は、総当たり手法にとって十分に小さいことがある。更に、評価関数の3つの例が本明細書に記載されるが、これらの評価関数への追加又は代替として使用され得る他の評価関数が本明細書での開示の恩恵を有する当業者に明らかになるであろう。
図6は、幾つかの実施形態により、特徴の統合を終了した後のツリーデータ構造300の例を示す。複数の特徴セットの幾つかの統合後、ツリー300のデータ階層が図6に示されるようになると考える。この例では、ツリー300は、ここでは、7つの終端ノードを有し、これは、元の12の終端ノードからの大きい低減である。したがって、このデータ階層に基づいて当てはめられた統計モデルは、特徴統合処理が実行されない場合よりも5つ少ない特徴を有する。上述したように、これは、統計モデルをトレーニング及び使用する処理時間を低減し得、したがって、通知が介護者に提供される速度を改善し、及び/又は患者デバイス等のデバイスを制御する速度及び応答性を改善し得る。
加えて、統合特徴は、308に示されるように更に統合され得る。例えば、図5Bを再び参照すると、まず、ノード338及び340における特徴がノード324における新しい統合特徴に統合されると考える。図7のプロセスの第2の反復中等、続けて、324における新しい統合特徴は、図6に示されるように、ノード308における新しい更なる統合特徴への統合により、特徴320及び322と次の上位階層レベルへ更に統合され得る。
更に、本明細書での実施形態は、他の努力分野に適用され得る。一例として、そのような階層構造を有するデータセットは、決定木を使用して元の特徴から追加の特徴を導出する、RuleFit等の機械学習法からも生じ得る。この場合、導出された特徴は、決定木のノードに対応し得、元の特徴に関して定義される「規則」を表し得る。各規則は真/偽インジケータであり得、規則の組の統合は、論理「OR」演算子に対応し得る。本明細書での例は、導出された特徴を選択的に統合するのに使用することもできる。
図7〜図10は、幾つかの実施形態によるプロセス例を示す流れ図である。プロセスは、一連の動作を表す、論理流れ図においてブロックの集合として示され、一連の動作の幾つか又は全ては、ハードウェア、ソフトウェア、又はそれらの組合せで実施され得る。ソフトウェアに関連して、ブロックは、1つ又は複数のプロセッサにより実行されると、記載の動作を実行するようにプロセッサをプログラムする、1つ又は複数のコンピュータ可読媒体に記憶されたコンピュータ実行可能命令を表し得る。一般に、コンピュータ実行可能命令は、特定の機能を実行し、又は特定のデータタイプを実施するルーチン、プログラム、オブジェクト、コンポーネント、データ構造等を含む。ブロックが説明される順序は、限定として解釈されるべきではない。記載される任意の数のブロックは、任意の順序で及び/又は並列して結合して、プロセス又は代替のプロセスを実施することができ、ブロックの全てを実行する必要はない。考察を目的として、プロセスは、本明細書での例で記載される環境、枠組み、及びシステムを参照して説明されるが、プロセスは、広範囲の他の環境、枠組み、及びシステムで実施され得る。
図7は、幾つかの実施形態による、統合される特徴を決定する例としてのプロセス700を示す流れ図である。幾つかの例では、プロセス700は、サービス計算デバイス102又は他の適する計算デバイスにより実行され得る。
702において、計算デバイスは、標的変数y、特徴階層データ構造、統合閾値、評価関数タイプ、及び異なる評価関数IのTLI閾値c(I)を受信し得る。例えば、標的変数yの特性は、構成中のモデルについて既知であり得、例えば、離散値、連続値等であり得る。更に、標的変数yの特性及び特徴に基づいて、評価関数を選択し得る。例えば、標的変数y及び特徴が離散し、特徴数が程々である場合、相互情報を選択し得、標的変数yが、2つのクラスの値を有するカテゴリであり、特徴が略連続している場合、R二乗を選択し得、標的変数がカテゴリであり、3つ以上のクラスの値を有する場合、クラス間/クラス内比率を選択し得る。更に、TLI閾値は、選択された評価関数に基づいて選択され得、モデルの所望の精度レベルとモデルの処理速度とのトレードオフに基づいて選択され得る。非限定的な一例として、情報の損失が0〜1のスケールでの相対値として測定される場合、TLI閾値は0.10〜0.20又は他の所望のTLI閾値であり得る。各評価関数は、それ自体のTLI閾値を有し得、したがって、異なる評価関数は異なるTLI閾値を有し得る。更に、TLI閾値の値は、少なくとも部分的に、情報損失の絶対差が特定されるか、それとも相対差が特定されるかに基づいて指定され得る。個々の統合閾値bも同様の考慮事項に基づいて設定され得る。
704において、計算デバイスは、全ての評価関数のコストc(I)=0に設定され得、最大深度の全ての内部ノードnを新ノードとしてマークする。
706において、計算デバイスは、依然として検討されていない最大深度の任意の新しい内部ノードnがあるか否かを判断し得る。
708において、計算デバイスは、最大深度の新しい内部ノードnを選択し、nを古いノードとしてマークする。
710において、計算デバイスは、nの下の特徴:x,x,...,xを取得し得る。例えば、pは、nをルートとして有するサブツリー内の特徴数(終端ノード数)であり得る。
712において、計算デバイスは、特徴の結合が有意味であるか否かを判断し得る。例えば、特徴が全て同じタイプのものであるか、又は他の様式で同じ特性を有する(例えば、全て同じタイプの数量として表すことができる、全てオン/オフ、0/1等、カテゴリ的に表すことができる等)場合、特徴は結合され得、プロセスは714に進む。他方、特徴が全て同じタイプのものではない(例えば、特徴によっては物理的数量として表されるものもあれば、ブール値として表されるものもある等)場合、これらの特徴を結合することは有意味ではなく、プロセスは706に進み、依然として検討されていない最大深度の別の内部ノードnを選択する。
714において、計算デバイスは、y及び(x,x,...,x)の特性に基づいて、集約関数f及び1つ又は複数の評価関数Iを選択し得る。
716において、計算デバイスは、選択された評価関数に基づいて、統合すべきか否かを判断し得る。統合すべき場合、プロセスは718に進み、統合すべきではない場合、プロセスは706に戻り、検討に残っている任意の他の内部ノードがあるか否かを判断する。図8は、特定の特徴を統合すべきか否かの判断についての更なる詳細を説明している。
718において、計算デバイスは、現在の特徴を統合する統合コストに、既に統合された任意の特徴の統合コストc(N)を加えたものであるコストが、評価関数のTLI閾値であるc(I)以下であるか否かを判断し得る。TLI閾値以下である場合、プロセスは720に進み、TLI閾値以下ではない場合、プロセスは706に進み、検討に残っている任意の他の内部ノードがあるか否かを判断する。上述したように、複数の評価関数が、同じデータセット内の異なる特徴を統合すべきか否かの判断に使用される場合、第1のTLI閾値を第1の評価関数に設定し得、第2のTLI閾値を第2の評価関数に設定し得、以下同様である。第1の評価関数で第1のTLI閾値に達する場合、第1の評価関数に対応する特性を有する特徴の統合を停止し得るが、第2の評価関数に対応する特性を有する特徴の統合は、第2のTLI閾値に達するまで継続され得、以下同様である。
720において、計算デバイスは、現在の統合コストを加算することにより、すなわち、c(I)=c(I)+統合コストにより、統合コストの中間結果を更新し得、nにおけるサブツリーを、新しい統合特徴f(x,x,...,x)を有する終端ノードで置換し得る。プロセスは次に、706に戻り、検討に残っている任意の他の内部ノードがあるか否かを判断し得る。
722において、全ての内部ノードが検討されると、計算デバイスは、改訂された階層データに基づいてトレーニングデータセットを生成し、統計モデルを構成し得る。幾つかの例では、計算デバイスは、ブロック702〜720の複数の反復を実行し、その後、ブロック722に進み得る。例えば、計算デバイスは、TLI閾値を超えずに第1の反復を完了する場合、別の反復を実行して、任意の統合特徴を階層データ構造内の次の上位レベルに更に統合し得るか否かを判断し得る。したがって、プロセスは、TLI閾値を超えるまで繰り返され得、TLI閾値を超えた場合にブロック722を実行し得る。
図8は、幾つかの実施形態による、選択された特徴を統合すべきか否かを判断する、図7のブロック716において実行される例としてのプロセス800を示す流れ図である。幾つかの例では、プロセス800は、サービス計算デバイス102又は他の適する計算デバイスにより実行され得る。
802において、図7のブロック714に続き、計算デバイスは、内部ノードn、集約関数f、評価関数I、評価タイプ(絶対又は相対)、及び統合閾値bを入力として受信し得る。
804において、計算デバイスは、階層データ内の全ての特徴のサブセットであり得る、nの下の特徴x,x,...,xを取得し得る。したがって、選択された内部ノードnから依存する選択された特徴のサブセットx,x,...,xは、階層データ構造内の次の上位階層レベルにおける内部ノードnに統合する候補である。
806において、計算デバイスは、統合特徴u=f(x,x,...,x)を計算し得る。例えば、集約関数fを使用して、統合特徴uを計算する。集約関数は、特徴x,x,...,xの特性に基づいて選択される。
808において、計算デバイスは、評価関数を使用して、I(y;x,x,...,x)に基づいて第1の結果を計算し、I(y;u)に基づいて第2の結果を計算し得る。例えば、選択された評価関数を使用して、x,x,...,xの統合なしに基づいて第1の結果を計算し、統合特徴uに基づいて第2の結果を計算する。第1の結果と第2の結果との間の相対差又は絶対差に基づいて、統合の場合の情報の予測損失を特定し得る。
810において、計算デバイスは、絶対差を特定する場合、g=ΔIに設定し得、相対差を特定する場合、g=ΔI/I(y;x,x,...,x)を設定し得る。例えば、計算デバイスは、ブロック808において特定された第1の結果と第2の結果との間の差として、gの絶対値を特定し得る。追加又は代替として、計算デバイスは、相対値としてgを特定し得、この場合、第1の結果と第2の結果との間の差は第1の結果で除算される。したがって、値gは、統合での情報の予測損失を表し得る。
812において、計算デバイスは、値gが統合閾値b未満であるか否かを判断し得る。統合閾値bは、gの絶対値が使用されるか、それともgの相対値が使用されるかに基づいて選択され得る。
814において、g<bである場合、計算デバイスは、統合を実行し得、統合のコストはΔIである。次に、プロセスは図7のプロセスに戻り、図7のブロック718での処理を続け得る。
他方、816において、g>bの場合、計算デバイスは、統合を実行しないと判断し得、コストはゼロである。次に、プロセスは図7のプロセスに戻り、図7のブロック706において処理を継続し得る。
図9は、幾つかの実施形態による、評価関数を選択することを含む例としてのプロセス900を示す流れ図である。幾つかの例では、プロセス900は、サービス計算デバイス102又は他の適する計算デバイスにより実行され得る。
902において、計算デバイスは、複数の観察単位で、階層構造を有する階層データを受信し得る。医療施設で使用される場合等の幾つかの例では、観察単位は患者を含み得、階層データは、センサデータ及び/又は介護者記録を含み得る。しかし、他の例では、他のタイプのアプリケーション内の他のタイプの統計モデルに他のタイプのデータを使用し得る。
904において、計算デバイスは、受信データに基づいて、受信データの階層構造を有するデータ構造を作成して、複数の特徴を決定し得る。例えば、データ構造がツリーである場合、複数の特徴は、ツリーの終端ノードに対応し得る。データ構造が階層レベルを示すテーブルである場合、複数の特徴は、テーブル内の各エントリの最も遠い階層レベルに対応し得る。更に、2つのデータ構造例を本明細書において説明したが、階層データの表現に使用し得る多くの他のデータ構造が本明細書での開示の恩恵を有する当業者に明らかになるであろう。
906において、計算デバイスは、特徴の特性及び1つ又は複数の標的変数の特性に基づいて、1つ又は複数の評価関数を選択し得る。例えば、この例では、2つの異なる標的変数y及びyがあると考える。一例として、yが、人工呼吸器が使用されるか否かの予測に使用される第1の統計モデルのためのものであり、yが、ケア施設内の特定の患者の滞在長の予測に使用される第2の統計モデルのためのものであると考える。2つの異なる標的変数は異なる特性を有するため、2つの異なる標的変数のそれぞれで、階層データ内でいずれの特徴を統合するかの判断に、異なる評価関数を使用し得る。例えば、幾つかの例では、統合すべき特徴の性質に応じて、複数の評価関数を単一の階層データセットに使用し得る。上述したように、評価関数によっては、幾つかのタイプの特徴及び幾つかのタイプの標的関数を統合すべきか否かの判断に適するものもあれば、他のタイプの特徴及び他のタイプの標的変数を統合すべきか否かの判断に適するものある。更に、階層データセットは、同じデータセット内の他の特徴の特性と異なる特性を有する特徴を含み得る。したがって、図9の例では、1つ又は複数の評価関数が、第1の標的変数yを特定する場合に統合される特徴を特定するために選択され、1つ又は複数の異なる評価関数が、第2の標的変数yを特定する場合に統合される特徴を特定するために選択される。当然のことながら、代替的に、他の例では、標的変数y及びyが同様の特性を有する場合、同じ1つ又は複数の評価関数を両事例に使用し得る。評価関数の選択に使用し得る考慮事項は、例えば、図5A及び図5Bに関して上述されている。
908において、標的変数yについて、計算デバイスは、選択された1つ又は複数の評価関数を使用して、統合される特徴を決定し得る。例えば、計算デバイスは、統合される特徴を決定する図7及び図8のプロセスを実行し得る。
910において、計算デバイスは、統合特徴を含む階層データの第1の改訂データ構造を決定し得る。
912において、計算デバイスは、第1の改訂データ構造に基づいて第1の統計モデルを構成及びトレーニングし得る。
914において、計算デバイスは、現在のデータを第1のトレーニング済みモデルに適用することに基づいてyを特定し得る。
916において、計算デバイスは、y結果に基づいて少なくとも1つの動作を実行し得る。
918において、標的変数yについて、計算デバイスは、選択された1つ又は複数の評価関数を使用して、統合される特徴を決定し得る。例えば、計算デバイスは、統合される特徴を決定する図7及び図8のプロセスを実行し得る。
920において、計算デバイスは、統合特徴を含む階層データの第2の改訂データ構造を決定し得る。幾つかの例では、第2の改訂データ構造の統合特徴は、異なる評価関数を使用することから決定される異なる結果に基づく等、例えば、異なる標的変数の異なる特性に基づいて第1の改訂データ構造の統合特徴と異なり得る。
922において、計算デバイスは、第2の改訂データ構造に基づいて第2の統計モデルを構成及びトレーニングし得る。幾つかの例では、第2の統計モデルは、第1の統計モデルと同じタイプの統計モデルであり得、一方、他の例では、第2の統計モデルは、第1の統計モデルと異なるタイプの統計モデルであり得る。本明細書での幾つかの例により使用し得る統計モデルのタイプの例としては、予測モデル、決定木、人工ニューラルネットワーク、分類器、線形回帰モデル等の回帰モデル、サポートベクターマシン、及びマルコフモデル、隠れマルコフモデル等の確率論的モデルが挙げられる。
924において、計算デバイスは、現在のデータを第2のトレーニング済みモデルに適用することに基づいてyを特定し得る。
926において、計算デバイスは、y結果に基づいて少なくとも1つの動作を実行し得る。
図10は、幾つかの実施形態による、患者データを制御し、及び/又は患者状態を特定する例としてのプロセス1000を示す流れ図である。幾つかの例では、プロセス1000はサービス計算デバイス102又は他の適する計算デバイスにより実行され得る。この例では、本明細書での技法は、上述した図1に対応するシステム等のケア施設における患者及び/又は患者デバイスに適用され得る。
1002において、計算デバイスは、複数の患者のセンサデータ及び介護者記録を含む階層データを受信し得る。階層データは、階層構造内の異なる階層レベルに対応する複数の記述を含む階層構造を有し得る。
1004において、計算デバイスは、階層データの階層構造を決定し、複数の特徴を決定し得る。例えば、階層データは、ツリーデータ構造等のデータ構造で配置され得、ツリーは、特徴に対応し得る複数の終端ノードを含み得る。これらの特徴のそれぞれは、同じサブツリー内の1つ又は複数の他の特徴と統合する候補であり得る。
1006において、計算デバイスは、階層データ内で統合される特徴を決定して、1つ又は複数の新しい統合特徴を含む改訂階層データを取得し得る。例えば、計算デバイスは、階層データ内の統合される特徴を決定して、1つ又は複数の新しい統合特徴を含む改訂階層データ構造を取得する図7及び図8のプロセスを実行し得る。
1008において、計算デバイスは、1つ又は複数の新しい統合特徴を含む改訂階層データ構造に基づいて統計モデルを構成及びトレーニングし得る。
1010において、計算デバイスは、第1の患者のセンサデータ及び/又は介護者記録を受信し得る。例えば、モデルがトレーニングされた後、特定の患者のデータをモデルに適用して、モデルが構成された所望の標的変数を特定し得る。
1012において、計算デバイスは、受信された第1の患者データを統計モデルに適用して標的変数を特定し得る。
1014において、計算デバイスは、統計モデルの出力に基づいて通知を送信し、決定を送信し、制御信号をデバイスに送信し、及び/又は他の動作を実行し得る。一例として、計算デバイスは、通知を介護者計算デバイス及び/又は施設計算デバイスに送信し得る。例えば、計算デバイスは、通知を送信して、アラートを介護者デバイスのディスプレイ及び/又は施設計算デバイスのディスプレイに提示させ得る。通知は、介護者に是正措置をとるように警告し得、及び/又は他の適切な介入を実行し得る。
別の例として、計算デバイスは、決定を別の計算デバイスに送信し得る。例えば、決定は、第1の患者が近い将来、ケア施設に再入院する可能性が高いか否か、第1の患者が特定の治療と必要とする確率、又は第1の患者についての他の所望の情報等の第1の患者に関する予測を含み得る。
追加又は代替として、別の例として、計算デバイスは、治療デバイス及び/又はモニタリングデバイスを制御する信号を送信し得る。例えば、計算デバイスは、患者ロケーションにおける治療デバイスを制御する制御信号を送信し得る。幾つかの場合、計算デバイスは、治療デバイス又はモニタリングデバイス等の患者デバイスをオンに切り替え、オフに切り替え、又は設定を調整し得る。制御信号を患者デバイスに送信することに加えて、介護者への通知を送信することもできる。更に、幾つかの例では、制御信号は、閾値レベルの緊急性が特定される場合等の特定の状況でのみ、患者デバイスに送信し得る。
本明細書に記載されるプロセス例は、考察目的で提供されるプロセスの単なる例である。多くの他の変形形態が本明細書での開示に鑑みて当業者に明らかになるであろう。更に、本明細書での開示は、プロセスの実行に適する枠組み、アーキテクチャ、及び環境の幾つかの例を記載しているが、本明細書での実施形態は、示され考察される特定の例に限定されない。更に、本開示は、説明され、図面に示されるように、様々な実施形態例を提供する。しかし、本開示は、本明細書に説明され示された実施形態に限定されず、当業者に既知であるか又は既知になるように他の実施形態に拡張することができる。
本明細書に記載される様々な命令、プロセス、及び技法は、コンピュータ可読媒体に記憶され、本明細書におけるプロセッサにより実行されるプログラムモジュール等のコンピュータ実行可能命令の一般的な状況で考慮され得る。一般に、プログラムモジュールは、特定のタスクを実行するか、又は特定の抽象データ型を実施するルーチン、プログラム、オブジェクト、コンポーネント、データ構造、実行可能コード等を含む。これらのプログラムモジュール等は、ネイティブコードとして実行してもよく、又は仮想マシン又は他のジャストインタイムコンパイル実行環境等でダウンロードし且つ実行してもよい。通常、プログラムモジュールの機能は、様々な実施形態において必要に応じて結合又は分散され得る。これらのモジュール及び技法の実施形態は、コンピュータ記憶媒体に記憶され得、又は何らかの形態の通信媒体を介して伝送され得る。
主題について、構造的特徴及び/又は方法論的動作に固有の言語で説明したが、添付の特許請求の範囲において定義される主題が必ずしも記載される特定の特徴又は動作に限定されないことを理解されたい。むしろ、特定の特徴及び動作は、特許請求の範囲を実施する形態例として開示される。
100 システム
102 サービス計算デバイス
104 患者ロケーション
106 ネットワーク
108 介護者計算デバイス
110 施設計算デバイス
112 プロセッサ
114 通信インタフェース
116 コンピュータ可読媒体
118 管理アプリケーション
120 オペレーティングシステム
122 センサデータ
124 介護者記録
126 統計モデル
128 トレーニングデータ
130 モデル特徴統合情報
132 階層データ構造
134 過去センサデータ
136 過去介護者記録
138 記憶装置
140 患者モニタリングデバイス
142 患者治療デバイス
144 患者デバイスセンサ
146 患者
148 介護者
150 ディスプレイ
152 ディスプレイ
154 通知
156 制御信号
158 判断
200 データ構造
202 第1のレベルの詳細
204 第2のレベルの詳細
206 第3のレベルの詳細
300 ツリーデータ構造
302 レベルゼロノードルート
304 流体IN
306 流体OUT
308 薬剤
310 評価
312 IV流体
314 血液製剤
316 血液
318 尿
320 薬物1
322 薬剤2
324 IV流体
326 状態1重症度
328 状態2重症度
330 モルヒネ
332 生理食塩水
334 成分1
336 成分2
338 薬物1
340 薬物3
400 データ構造
402 観察単位
404 患者ID
406 日付
408 標的変数
410 特徴
502 サブツリー
700 プロセス
800 プロセス
900 プロセス
1000 プロセス

Claims (20)

  1. 1つ又は複数のプロセッサと、
    実行可能命令を保持する1つ又は複数の非一時的コンピュータ可読媒体と
    を備え、
    前記実行可能命令は、前記1つ又は複数のプロセッサにより実行されると、
    複数の階層レベルを含む階層構造を有する階層データを受信することと、
    少なくとも部分的に前記階層データに基づいて複数の特徴を特定することと、
    前記階層構造内の次の上位レベルに統合する候補として前記特徴のサブセットを選択することと、
    前記特徴のサブセットの統合からの情報の予測損失が第1の閾値未満であると判断することと、
    前記特徴のサブセットではなく、統合特徴を含むように前記階層構造を改訂することと、
    前記統合特徴を含む前記改訂された階層構造に基づいて統計モデルをトレーニングすることと、
    データを受信して前記統計モデルに適用することと、
    前記統計モデルの出力を特定することと、
    計算デバイスへの通知若しくは決定、又は
    デバイスを制御する、デバイスへの制御信号
    のうちの少なくとも1つを送信することと
    を含む動作を実行するように前記1つ又は複数のプロセッサをプログラムする、システム。
  2. 前記特徴のサブセットの統合からの前記情報の予測損失が第1の閾値未満であると判断する前記動作は、
    少なくとも部分的に前記統計モデルの標的変数の特性に基づいて評価関数を選択することと、
    統合なしの前記特徴のサブセットに対する前記評価関数の第1の結果と、前記特徴のサブセットを統合した状態での前記評価関数の第2の結果とを計算することと、
    前記第1の結果と前記第2の結果との差が前記第1の閾値未満であると判断することと
    を含む、請求項1に記載のシステム。
  3. 前記特徴のサブセットの統合からの前記情報の予測損失が第1の閾値未満であると判断することは、
    前記選択された評価関数について、情報の合計損失に対応する第2の閾値を決定することと、
    少なくとも部分的に前記第1の結果と前記第2の結果との前記差に基づいて、前記統合での前記情報の予測損失を特定することと、
    前記統合での前記情報の予測損失に、前記階層データ内の他の特徴の他の統合での情報の予測損失を加えたものが前記第2の閾値未満であると判断することと
    を含む、請求項2に記載のシステム。
  4. 前記動作は、
    少なくとも部分的に、異なる統計モデルの異なる標的変数の特性に基づいて、異なる評価関数を選択することと、
    統合なしの前記特徴のサブセットに対する前記異なる評価関数の第1の結果と、前記特徴のサブセットを統合した状態での前記異なる評価関数の第2の結果とを計算することと、
    前記異なる評価関数の前記第1の結果と前記異なる評価関数の前記第2の結果との差が別の統合閾値未満であると判断することと
    を更に含む、請求項2に記載のシステム。
  5. 前記動作は、
    前記特徴のサブセットではなく、少なくとも1つの統合特徴を含む別の改訂された階層構造を生成するように前記階層構造を改訂することと、
    前記の改訂された階層構造に基づいて異なる統計モデルをトレーニングすることと、
    データを受信して前記異なる統計モデルに適用することと、
    前記異なる統計モデルの出力を特定することと
    を更に含む、請求項4に記載のシステム。
  6. 階層データを受信する前記動作は、複数の患者のセンサデータ及び介護者記録を受信することを含み、前記センサデータは、複数の患者デバイスから取得され、且つ前記介護者記録は、介護者デバイスに手動入力される個々の患者に関連するデータを含み、
    前記データを受信して前記統計モデルに適用する前記動作は、第1の患者に対応するセンサデータ及び介護者記録を受信することを含み、及び
    前記送信する動作は、
    前記第1の患者に関連する通知若しくは決定を介護者計算デバイスに送信すること、又は
    前記患者デバイスを制御する制御信号を前記第1の患者に関連付けられた患者デバイスに送信すること
    のうちの少なくとも1つを含む、請求項1に記載のシステム。
  7. 前記動作は、
    前記特徴のサブセットの1つ又は複数の共通特性に基づいて集約関数を特定することと、
    前記集約関数を使用して前記特徴のサブセットを集約することにより、前記集約関数を使用して新しい統合特徴を特定することと、
    少なくとも部分的に集約なしの前記特徴のサブセットと前記新しい統合特徴との差に基づいて、前記情報の予測損失を特定することと
    を更に含む、請求項1に記載のシステム。
  8. プロセッサにより、階層構造を有する階層データを受信することと、
    少なくとも部分的に前記階層データに基づいて複数の特徴を特定することと、
    前記階層構造内で統合する候補として前記特徴のサブセットを選択することと、
    前記特徴のサブセットの統合からの情報の予測損失が第1の閾値未満であると判断することと、
    前記特徴のサブセットではなく、統合特徴を含むように前記階層構造を改訂することと
    を含む、方法。
  9. 前記統合特徴を含む前記改訂された階層構造に基づいて統計モデルをトレーニングすることと、
    データを受信して前記統計モデルに適用することと、
    前記統計モデルの出力を特定することと、
    前記出力に基づいて少なくとも1つの通信を送信することと
    を更に含む、請求項8に記載の方法。
  10. 前記特徴のサブセットの統合からの前記情報の予測損失が第1の閾値未満であると判断することは、
    少なくとも部分的に前記統計モデルの標的変数の特性に基づいて評価関数を選択することと、
    統合なしの前記特徴のサブセットに対する前記評価関数の第1の結果と、前記特徴のサブセットを統合した状態での前記評価関数の第2の結果とを計算することと、
    前記第1の結果と前記第2の結果との差が前記第1の閾値未満であると判断することと
    を含む、請求項に記載の方法。
  11. 前記選択された評価関数について、情報の合計損失に対応する第2の閾値を決定することと、
    少なくとも部分的に前記第1の結果と前記第2の結果との前記差に基づいて、前記統合での前記情報の予測損失を特定することと、
    前記統合での前記情報の予測損失に、前記階層データ内の他の特徴の他の統合での情報の予測損失を加えたものが前記第2の閾値未満であると判断することと
    を更に含む、請求項10に記載の方法。
  12. 少なくとも部分的に、異なる統計モデルの異なる標的変数の特性に基づいて、異なる評価関数を選択することと、
    統合なしの前記特徴のサブセットに対する前記異なる評価関数の第1の結果と、前記特徴のサブセットを統合した状態での前記異なる評価関数の第2の結果とを計算することと、
    前記異なる評価関数の前記第1の結果と前記異なる評価関数の前記第2の結果との差が別の統合閾値未満であると判断することと
    を更に含む、請求項10に記載の方法。
  13. 前記特徴のサブセットの1つ又は複数の共通特性に基づいて集約関数を特定することと、
    前記集約関数を使用して前記特徴のサブセットを集約することにより、前記集約関数を使用して新しい統合特徴を特定することと、
    少なくとも部分的に集約なしの前記特徴のサブセットと前記新しい統合特徴との差に基づいて、前記情報の予測損失を特定することと
    を更に含む、請求項8に記載の方法。
  14. 前記統合特徴を他の特徴と統合する場合の情報の予測損失が前記第1の閾値未満であると判断することと、
    前記統合特徴の階層レベルの上の階層レベルに前記統合特徴及び前記他の特徴を統合することと
    を更に含む、請求項8に記載の方法。
  15. 1つ又は複数のプロセッサと、
    実行可能命令を保持する1つ又は複数の非一時的コンピュータ可読媒体と
    を備え、
    前記実行可能命令は、前記1つ又は複数のプロセッサにより実行されると、
    複数の階層レベルを含む階層構造を有する階層データを受信することと、
    少なくとも部分的に前記階層データに基づいて複数の特徴を特定することと、
    前記階層構造内の次の上位レベルに統合する候補として前記特徴のサブセットを選択することと、
    前記特徴のサブセットの統合からの情報の予測損失が閾値未満であると判断することと、
    前記特徴のサブセットではなく、統合特徴を含むように前記階層構造を改訂することと
    を行うように前記1つ又は複数のプロセッサをプログラムする、システム。
  16. 前記1つ又は複数のプロセッサは、
    前記改訂された階層構造に基づいて統計モデルをトレーニングすることと、
    データを受信して前記統計モデルに適用することと、
    前記統計モデルの出力を特定することと、
    前記出力に基づいて、デバイスを制御する少なくとも1つの信号を送信することと
    を行うように更にプログラムされる、請求項15に記載のシステム。
  17. 前記特徴のサブセットの統合からの前記情報の予測損失が第1の閾値未満であると判断することは、
    少なくとも部分的に前記統計モデルの標的変数の特性に基づいて評価関数を選択することと、
    統合なしの前記特徴のサブセットに対する前記評価関数の第1の結果と、前記特徴のサブセットを統合した状態での前記評価関数の第2の結果とを計算することと、
    前記第1の結果と前記第2の結果との差が前記第1の閾値未満であると判断することと
    を含む、請求項16に記載のシステム。
  18. 前記1つ又は複数のプロセッサは、
    前記選択された評価関数について、情報の合計損失に対応する第2の閾値を決定することと、
    少なくとも部分的に前記第1の結果と前記第2の結果との前記差に基づいて、前記統合での前記情報の予測損失を特定することと、
    前記統合での前記情報の予測損失に、前記階層データ内の他の特徴の他の統合での情報の予測損失を加えたものが前記第2の閾値未満であると判断することと
    を行うように更にプログラムされる、請求項17に記載のシステム。
  19. 前記1つ又は複数のプロセッサは、
    少なくとも部分的に、前記階層構造内の次の前記上位レベルに統合する候補として選択された前記特徴のサブセットの1つ又は複数の共通特性に基づいて集約関数を決定することと、
    前記集約関数を使用して当該特徴のサブセットを集約することにより、前記集約関数を使用して新しい統合特徴を特定することと、
    少なくとも部分的に集約なしの当該特徴のサブセットと前記新しい統合特徴との差に基づいて、前記情報の予測損失を特定することと
    を行うように更にプログラムされる、請求項17に記載のシステム。
  20. 前記1つ又は複数のプロセッサは、
    前記統合特徴を他の特徴と統合する場合の情報の予測損失が前記閾値未満であると判断することと、
    前記統合特徴の前記階層レベルの上の階層レベルに前記統合特徴及び前記他の特徴を統合することと
    を行うように更にプログラムされる、請求項15に記載のシステム。
JP2017152896A 2016-08-25 2017-08-08 階層データに基づくデバイス制御 Expired - Fee Related JP6454762B2 (ja)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US15/246,685 2016-08-25
US15/246,685 US10692601B2 (en) 2016-08-25 2016-08-25 Controlling devices based on hierarchical data

Publications (2)

Publication Number Publication Date
JP2018032394A JP2018032394A (ja) 2018-03-01
JP6454762B2 true JP6454762B2 (ja) 2019-01-16

Family

ID=59699615

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2017152896A Expired - Fee Related JP6454762B2 (ja) 2016-08-25 2017-08-08 階層データに基づくデバイス制御

Country Status (3)

Country Link
US (1) US10692601B2 (ja)
EP (1) EP3291241A1 (ja)
JP (1) JP6454762B2 (ja)

Families Citing this family (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10692601B2 (en) * 2016-08-25 2020-06-23 Hitachi, Ltd. Controlling devices based on hierarchical data
US11195601B2 (en) * 2017-05-31 2021-12-07 International Business Machines Corporation Constructing prediction targets from a clinically-defined hierarchy
JP7109995B2 (ja) * 2018-05-29 2022-08-01 株式会社日立製作所 介護サービス分析システム、介護サービス分析方法、介護サービス分析処理装置
US11257592B2 (en) * 2019-02-26 2022-02-22 International Business Machines Corporation Architecture for machine learning model to leverage hierarchical semantics between medical concepts in dictionaries
EP3935581A4 (en) 2019-03-04 2022-11-30 Iocurrents, Inc. DATA COMPRESSION AND COMMUNICATION USING MACHINE LEARNING
JP2022045731A (ja) * 2020-09-09 2022-03-22 株式会社Screenホールディングス 情報処理装置、情報処理システムおよび情報処理方法
CN114510518B (zh) * 2022-04-15 2022-07-12 北京快立方科技有限公司 一种海量结构化数据的自适应聚合方法、系统及电子设备

Family Cites Families (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH04184668A (ja) * 1990-11-20 1992-07-01 Sanyo Electric Co Ltd ニューラルネットワークにおける教師データの修正方法
JPH0668150A (ja) * 1992-06-02 1994-03-11 Nec Corp 木構造の末端ノードで発生した値をその上位ノードに高速に集計するコード体系とアルゴリズム
US6689091B2 (en) * 1996-08-02 2004-02-10 Tuan Bui Medical apparatus with remote control
JP3579349B2 (ja) * 2000-12-21 2004-10-20 株式会社東芝 データ分析方法、データ分析装置および記録媒体
WO2002073530A1 (en) 2001-03-07 2002-09-19 Rockwell Scientific Company, Llc Data mining apparatus and method with user interface based ground-truth tool and user algorithms
JP5603639B2 (ja) * 2010-04-23 2014-10-08 国立大学法人京都大学 予測装置の学習装置及びそのコンピュータプログラム
US8892490B2 (en) * 2010-09-22 2014-11-18 Hewlett-Packard Development Company, L.P. Determining whether a point in a data stream is an outlier using hierarchical trees
BR112014020040A8 (pt) * 2012-02-17 2017-07-11 Koninklijke Philips Nv Meio de armazenamento não transitório que armazena as instruções executáveis por um dispositivo de processamento eletrônico de dados que inclui um visor para o monitoramento de um paciente com lesão pulmonar aguda, aparelho, e, método
WO2014201515A1 (en) * 2013-06-18 2014-12-24 Deakin University Medical data processing for risk prediction
US10692601B2 (en) * 2016-08-25 2020-06-23 Hitachi, Ltd. Controlling devices based on hierarchical data
US10313422B2 (en) * 2016-10-17 2019-06-04 Hitachi, Ltd. Controlling a device based on log and sensor data

Also Published As

Publication number Publication date
US10692601B2 (en) 2020-06-23
EP3291241A1 (en) 2018-03-07
US20180060513A1 (en) 2018-03-01
JP2018032394A (ja) 2018-03-01

Similar Documents

Publication Publication Date Title
JP6454762B2 (ja) 階層データに基づくデバイス制御
US10313422B2 (en) Controlling a device based on log and sensor data
Muthu et al. IOT based wearable sensor for diseases prediction and symptom analysis in healthcare sector
Zhang ATTAIN: Attention-based time-aware LSTM networks for disease progression modeling.
Kaur et al. A healthcare monitoring system using random forest and internet of things (IoT)
US20160364544A1 (en) Diagnostic support systems using machine learning techniques
Alazab et al. Digital twins for healthcare 4.0—Recent advances, architecture, and open challenges
CA3015838A1 (en) System and method for monitoring brain health status
CN108366763A (zh) 用于评估精神状态的方法和系统
Priyadharsan et al. Patient health monitoring using IoT with machine learning
EP3599616A1 (en) System and method for providing a medical data structure for a patient
EP3287918B1 (en) Managing patient devices based on sensor data
Massaro et al. Decisional support system with artificial intelligence oriented on health prediction using a wearable device and big data
US20170091406A1 (en) System and method for managing illness outside of a hospital environment
Mohamed et al. Analyzing the patient behavior for improving the medical treatment using smart healthcare and IoT-based deep belief network
CA2997354A1 (en) Experience engine-method and apparatus of learning from similar patients
Dash et al. REVOLUTIONIZING CARDIOVASCULAR DISEASE PREVENTION WITH MACHINE LEARNING: A COMPREHENSIVE REVIEW
US20220415462A1 (en) Remote monitoring methods and systems for monitoring patients suffering from chronical inflammatory diseases
EP4093270A1 (en) Method and system for personalized prediction of infection and sepsis
Wang et al. Artificial intelligence for in silico clinical trials: A review
US20160034619A1 (en) Systems and Methods for Comparative Analysis
Levonevskiy et al. Automation of data processing for patient monitoring in the smart ward environment
Bateja et al. Leveraging latest developments for delivering patient-centric healthcare to diabetic patients
Palanivel Rajan et al. AI role in making IoT-based medical devices a success
US20230042330A1 (en) A tool for selecting relevant features in precision diagnostics

Legal Events

Date Code Title Description
A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20180727

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20180904

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20181029

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20181127

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20181217

R150 Certificate of patent or registration of utility model

Ref document number: 6454762

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150

LAPS Cancellation because of no payment of annual fees