(57)【要約】  ユーザの臨床状態を監視するためのシステム、装置、および方法が開示される。ユーザの臨床状態を監視する方法は、医療デバイスのセットからのユーザの臨床情報と、データベースからのユーザの非臨床情報とを取得するステップと、少なくとも1つのメモリデバイス上に、蓄積されたデータセットを形成するために、前記臨床情報および非臨床情報を蓄積するステップと、予測モデルおよび履歴データ比較モデルのいずれかまたは組合せに基づいて前記蓄積されたデータセットを分析するステップであって、蓄積されたデータセットの前記分析がユーザの臨床状態の評価を含み、その評価に基づいて、定義された時間間隔にわたってユーザの縦断的状態が予測される、ステップと、ディスプレイユニットによって、蓄積されたデータセットの一部を形成する分析された臨床情報および分析された非臨床情報のいずれかまたは組合せを表示するステップとを備える。
2020528814.tif 000002
【特許請求の範囲】
【請求項１】
ユーザの臨床状態を監視するための装置であって、前記装置が、
医療デバイスのセットからの前記ユーザの臨床情報と、前記ユーザの過去のバイタル情報を含むデータベースからの前記ユーザの非臨床情報とを取得するように構成された情報取得ユニットと、
前記ユーザの前記臨床情報および前記非臨床情報の蓄積されたデータセットを形成するために、前記医療デバイスのセットおよび前記データベースから取得された前記臨床情報および前記非臨床情報を収集および記憶するための少なくとも1つのメモリデバイスと、
予測モデルおよび履歴データ比較モデルのいずれかまたは組合せに基づいて前記蓄積されたデータセットを分析するように構成された情報処理ユニットであって、前記蓄積されたデータセットの前記分析が前記ユーザの臨床状態の評価を含み、その評価に基づいて、定義された時間間隔にわたって前記ユーザの縦断的状態が予測される、情報処理ユニットと、
前記蓄積されたデータセットの一部を形成する前記分析された臨床情報および前記分析された非臨床情報のいずれかまたは組合せを表示するように適合されたディスプレイユニットと
を備える、装置。
【請求項２】
前記医療デバイスのセットが、心肺モニタ、パルスオキシメータ、血液ガスマシン、および人工呼吸器のいずれかまたは組合せを組み込んでいる、請求項1に記載の装置。
【請求項３】
前記定義された時間間隔にわたる前記ユーザの縦断的状態の前記予測に基づいて、前記情報処理ユニットが、前記ユーザの1つまたは複数の臨床パラメータの制御に関連する1つまたは複数のデバイスを制御することによって、前記1つまたは複数の臨床パラメータの前記制御を可能にする、請求項1に記載の装置。
【請求項４】
前記蓄積されたデータセットの一部を形成する前記臨床情報および前記非臨床情報のいずれかまたは組合せをサーバ/データベースに送信するように構成された情報送信ユニットをさらに備える、請求項1に記載の装置。
【請求項５】
前記情報取得ユニットが、ユーザからの入力を受信するように構成された通信インターフェースを備え、前記通信インターフェースが、画像キャプチャデバイスおよびユーザインターフェースからなる群から選択される、請求項1に記載の装置。
【請求項６】
前記通信インターフェースが、タッチ対応表示画面および音声対応ガイダンスシステムのいずれかまたは組合せである、請求項5に記載の装置。
【請求項７】
ユーザの臨床状態を監視する方法であって、前記方法が、
医療デバイスのセットからの前記ユーザの臨床情報と、前記ユーザの過去のバイタル情報を含むデータベースからの前記ユーザの非臨床情報とを取得するステップと、
少なくとも1つのメモリデバイス上に、前記ユーザの前記臨床情報および前記非臨床情報の蓄積されたデータセットを形成するために、前記医療デバイスのセットおよび前記データベースから取得された前記臨床情報および前記非臨床情報を蓄積するステップと、
予測モデルおよび履歴データ比較モデルのいずれかまたは組合せに基づいて前記蓄積されたデータセットを分析するステップであって、前記蓄積されたデータセットの前記分析がユーザの臨床状態の評価を含み、その評価に基づいて、定義された時間間隔にわたって前記ユーザの縦断的状態が予測される、ステップと、
ディスプレイユニットによって、前記蓄積されたデータセットの一部を形成する前記分析された臨床情報および前記分析された非臨床情報のいずれかまたは組合せを表示するステップと
を備える、方法。
【請求項８】
前記ユーザの1つまたは複数の臨床パラメータの制御に関連する1つまたは複数のデバイスを制御することによって、前記分析に基づいて、前記1つまたは複数の臨床パラメータを制御するステップをさらに備える、請求項7に記載の方法。
【請求項９】
前記1つまたは複数のデバイスが、心肺モニタ、パルスオキシメータ、血液ガスマシン、および人工呼吸器のいずれかまたは組合せを備える、請求項8に記載の方法。
【請求項１０】
ユーザの臨床状態を監視するためのシステムであって、
前記ユーザの臨床状態を監視するように動作可能な1つまたは複数のルーチンが具体化された非一時的記憶デバイスと、
前記非一時的記憶デバイスに結合され、前記1つまたは複数のルーチンを実行するように動作可能な1つまたは複数のプロセッサと
を備え、
前記1つまたは複数のルーチンが、アプリケーション開発およびテストサーバ上に記憶されたルーチンの第2のセットと関連して実行され、前記1つまたは複数のルーチンが、
前記1つまたは複数のプロセッサによって実行されると、医療デバイスのセットからの前記ユーザの臨床情報と、前記ユーザの過去のバイタル情報を含むデータベースからの前記ユーザの非臨床情報とを取得する情報取得モジュールと、
前記1つまたは複数のプロセッサによって実行されると、前記ユーザの前記臨床情報および前記非臨床情報の蓄積されたデータセットを形成するために、前記医療デバイスのセットおよび前記データベースから取得された前記臨床情報および前記非臨床情報を収集および記憶する情報記憶モジュールと、
前記1つまたは複数のプロセッサによって実行されると、予測モデルおよび履歴データ比較モデルのいずれかまたは組合せに基づいて、前記蓄積されたデータセットを分析する情報処理モジュールであって、前記蓄積されたデータセットの前記分析が、前記ユーザの臨床状態の評価を含み、その評価に基づいて、定義された時間間隔にわたって前記ユーザの縦断的状態が予測される、情報処理モジュールと、
前記1つまたは複数のプロセッサによって実行されると、前記蓄積されたデータセットの一部を形成する前記分析された臨床情報および前記分析された非臨床情報のいずれかまたは組合せを表示するディスプレイモジュールと
を含む、システム。
【請求項１１】
前記医療デバイスのセットが、心肺モニタ、パルスオキシメータ、血液ガスマシン、および人工呼吸器のいずれかまたは組合せを組み込んでいる、請求項10に記載のシステム。
【請求項１２】
前記定義された時間間隔にわたる前記ユーザの縦断的状態の前記予測に基づいて、前記情報処理モジュールが、前記ユーザの1つまたは複数の臨床パラメータの制御に関連する1つまたは複数のデバイスを制御することによって、前記1つまたは複数の臨床パラメータの前記制御を可能にする、請求項10に記載のシステム。
【請求項１３】
前記蓄積されたデータセットの一部を形成する前記臨床情報および前記非臨床情報のいずれかまたは組合せをサーバ/データベースに送信するように構成された情報送信モジュールをさらに備える、請求項10に記載のシステム。
【請求項１４】
前記情報取得モジュールが、ユーザからの入力を受信するように構成された通信インターフェースを備え、前記通信インターフェースが、画像キャプチャデバイスおよびユーザインターフェースからなる群から選択される、請求項10に記載のシステム。
【請求項１５】
前記通信インターフェースが、タッチ対応表示画面および音声対応ガイダンスシステムのいずれかまたは組合せである、請求項10に記載のシステム。
【発明の詳細な説明】
【技術分野】
【０００１】
本開示は、患者監視方法およびシステムに関する。具体的には、本開示は、ユーザの臨床状態を監視するための装置、システム、および方法に関する。
【背景技術】
【０００２】
集中治療室(ICU)は、病院の最も無菌で扱いに注意を要する領域である。ICUには、患者のバイタルを継続的に記録および表示する、人工呼吸器、保育器、心電図(ECG)モニタなどの複数のデバイスが装備されている。患者の医療パラメータを測定するセンサとは別に、デバイスの各々は、追加のディスプレイユニットを有し、これは、それらの設計をよりかさばるものにする。医療機器の複数のディスプレイユニットが、ICUの部屋のスペースを占領する。加えて、各医療デバイスは、各患者について1日あたり数百万の独自のデータポイントを生成し、それらを72時間だけ記憶する。したがって、臨床的な意思決定に役立つ可能性がある重要な情報の多くが失われる。この高頻度で大量の生理学的データストリームの処理は、依然として大きな課題であるが、患者に高品質の医療を提供するために重要な洞察をもたらす可能性がある。
【０００３】
これらの重篤な患者は、血液、尿などの体液から得ることができる様々な他の医療パラメータについて監視される必要がある。X線などの撮像を含む詳細な検査は、検査室に依頼される必要がある。依頼された調査および報告は、検査室情報管理システム(LIMS: Laboratory Information Management System)内に維持され、主に病院情報システム(HIS: Hospital Information System)/電子医療記録(EMR: Electronic Medical Record)にリンクされる。しかしながら、介護者は、病院の中央システムを介してこの情報に頻繁にアクセスすることができない。したがって、介護者は、ベッドサイドで患者を診察しながら、臨床検査結果を手動で運ぶ。
【０００４】
これらの患者は、看護師および医師によって反復的に監視することを必要とする。臨床医の一回の訪問ごとにすべての患者の詳細な臨床検査が記録および維持されなければならない。処方された薬物、依頼された調査、および栄養データのすべてが、開業医によって非常に注意深く紙に記録されなければならない。次いで、看護師が、これらの依頼に従い、1時間ごとの記録を維持する。紙への手動のデータ入力は、多数のエラーをもたらし、介護者への追加の作業負荷になる。加えて、新生児集中治療室(NICU: Neonatal Intensive care unit)などの少数の特殊なICUも、新生児の変化する栄養要求、カロリー要求、およびナトリウムバランス要求を継続的に監視する必要がある。これは、難しい計算を必要とし、間違いを生じやすい。
【０００５】
今日まで、標準化された臨床的に承認されたプロトコルは、全国のすべてのICUにおいて実装されているわけではなく、ICUにおいて手動の記録として保持されている。また、これらのプロトコルは、病院の施設に応じて異なる場合がある。様々なICUのエビデンスに基づく品質指標を提供することは、プロトコルの遵守を強化することができる。また、これは、高品質の医療を保証するためのベストプラクティスを構築する際にも役立つ。
【０００６】
臨床的に承認された予測スコアが国際的な臨床診療において広く使用されており、それらの母集団で統計的に検証されている。しかし、そのような記録の維持がなく、したがって、これらのスコアは、グローバルコホートにおいて検証されていない。
【０００７】
技術の進歩または人工知能の導入は、現在、臨床的に関連するパターンを取得するために、数百万のリアルタイムデバイスデータポイントのマイニングを可能にしている。したがって、リアルタイムの縦断的データを使用した深層学習ベースの確率モデルを使用した十分な文献エビデンスが存在し、報告された結果は、患者の疾病率および死亡率の状態とよく相関することが認められた。しかしながら、ハードウェアにおけるこの認知知能は、患者の高品質の医療のためのヘルスケアではまだ利用されていない。
【０００８】
したがって、様々なデバイスからのデータを統合し、ICU固有のプロトコルによって維持可能であり得る臨床データ、検査記録、臨床スコアをリンクする統一プラットフォームの必要性が存在する。堅牢なビッグデータインフラストラクチャによるICUワークフローのそのような自動化は、様々な時間枠における生理学的および臨床的表現型パラメータの監視および記憶を促進し、臨床マーカ発見プロセスにも役立つ。
【０００９】
さらに、そのような自動化により、(NICUからの)子供の出生からの子供の健康、またはICUに入院した任意の患者の縦断的データを記憶し、患者の退院後も患者と容易に共有することができる。これは、臨床医および研究者が早期介入の長期的効果を調査し、様々な併存疾患間の因果関係を理解する際に役立つ。退院後の予約、定期検診、および臨床検査も、そのようなシステムによって容易に管理することができる。現在、すべてのこれらの報告および記録は、患者によって手動で管理される必要がある。また、緊急の場合に電話での診察のために臨床医と連絡を取ることは、依然として困難な作業である。
【発明の概要】
【発明が解決しようとする課題】
【００１０】
本発明の全体的な目的は、多次元(医療デバイス、臨床データ、LIMS、PACS)からのデータを1つのインターフェースに橋渡しする単一のディスプレイ画面を有する多目的のベッドサイドのスマートでコンパクトな統一プラットフォームを提供することである。
【００１１】
本発明の別の目的は、疾患の早期同定のためのパターン発見およびリアルタイム分析において臨床医を支援する認知知能アプリケーションを提供することである。
【００１２】
本発明のさらに別の目的は、全国のICUの品質パラメータに対するこれらの実践の影響に関してエビデンスを集めることによって、臨床プロトコルの遵守を強化することである。
【００１３】
本発明のさらに別の目的は、専門家による地方における資源不足環境において存在するICUの遠隔監視を可能にすることである。
【００１４】
本発明のさらに別の目的は、本開示のシステムを使用して、データを捕捉し、処理し、分析し、記憶および表示するための方法を提供することである。
【００１５】
本発明のさらに別の目的は、患者のすべての病歴と共にリアルタイムのバイタルを監視するためにそれらのモバイルインターフェースにリンクする、自宅における患者のバイタルを捕捉するためにウェアラブルデバイス(例えば、HR、RRなどを捕捉するセンサを有するソックス)を使用して退院後の健康監視を提供することである。
【課題を解決するための手段】
【００１６】
したがって、本開示は、単一のコンパクトなタッチ感知ディスプレイ画面と、部屋のスペースを占有することなく患者のベッドの上に取り付けることができる音声支援ユーザインターフェースとを提供する。標準化されたポートを使用して、様々な医療デバイスを接続することができる。特定のヘルスレベル7(HL7:Specific Health Level 7)/米国材料試験協会(ASTM: American Society for Testing and Materials)の適用が、医療デバイスの各々との接続を確立するために使用される。処理されたデータとともに、すべての波形データが、各患者について表示される。これは、デバイスごとの個別のディスプレイユニットの必要性をなくす。
【００１７】
本システムは、LIMS、HIS/ENIR、および画像保管通信システム(PACS: Picture Archiving and Communication System)とシームレスにリンクする。したがって、検査報告からの生データならびに画像データをワンクリックで表示することができる。個別の臨床評価モジュールが、関連する臨床検査、バイタル、および介入に関して設計された。医師は、イベント/診断を選択し、評価を依頼することができ、評価は、検査室側にリンクされ、また、同じディスプレイを使用する看護師によって続けられる。栄養素も医師の入力によってワンクリックで計算され、受信したカロリーも毎日表示することができる。臨床医の指示に基づいて、本発明の統一プラットフォームに取り付けられた輸液ポンプを調整することができる。
【００１８】
臨床的に承認されたプロトコルは、この画面を使用して表示および追跡することができる。この自動化は、一定のリマインダおよび警報によって、治療のための臨床的に承認されたプロトコルの実装を強化する。病院管理によってICUの品質を監視するための品質指標パラメータを見ることができ、さらなる改善を行うことができる。
【００１９】
このビッグデータハブは、各患者について縦断的に記憶された臨床ストリーム、検査ストリーム、生理学的ストリームから来るすべての非構造化データおよび構造化データを有する。したがって、臨床的にテストされたスコア、および、リアルタイムの長期記録を利用する深層学習ベースの分析モデルが、認知知能モジュールの一部である。臨床データのこの蓄積は、パターン認識における臨床医の困難を軽減するための認知的支援を提供し、それは、患者の治療のためのより体系的な手法を提供するために開業医への臨床的意思決定において役立つことができる。
【００２０】
また、(ICU以降の)病歴全体が、患者のモバイルアプリケーションにおいていつでもアクセス可能になる。このインターフェースは、予防接種リマインダおよびフォローアップリマインダなどの通知/リマインダ/警報を与える。これは、透明な医師-患者の関与プラットフォームとしても機能する。このアプリケーションは、ウェアラブルデバイス、例えば、臨床医および患者によって容易に見ることができる自宅におけるリアルタイムバイタル(心拍数(HR: Heart Rate)、呼吸数(RR: Respiratory Rate)など)を捕捉するセンサを有するソックスに接続される。そのような発明は、自宅においても患者を容易に監視し、必要なケアを提供する際に役立つだけでなく、いかなる遅延もなしに迅速な介入も保証する。
【００２１】
本開示の一態様は、ユーザの臨床状態を監視するための装置に関し、装置は、医療デバイスのセットからのユーザの臨床情報と、ユーザの過去のバイタル情報を含むデータベースからのユーザの非臨床情報とを取得するように構成された情報取得ユニットと、ユーザの臨床情報および非臨床情報の蓄積されたデータセットを形成するために、医療デバイスのセットおよびデータベースから取得された前記臨床情報および非臨床情報を収集および記憶するための少なくとも1つのメモリデバイスと、予測モデルおよび履歴データ比較モデルのいずれかまたは組合せに基づいて前記蓄積されたデータセットを分析するように構成された情報処理ユニットであって、蓄積されたデータセットの前記分析がユーザの臨床状態の評価を含み、その評価に基づいて、定義された時間間隔にわたってユーザの縦断的状態が予測される、情報処理ユニットと、蓄積されたデータセットの一部を形成する分析された臨床情報および分析された非臨床情報のいずれかまたは組合せを表示するように適合されたディスプレイユニットとを含む。
【００２２】
一実施形態において、装置は、蓄積されたデータセットの一部を形成する臨床情報および非臨床情報のいずれかまたは組合せをサーバ/データベースに送信するように構成された情報送信ユニットをさらに含む。
【００２３】
一実施形態において、情報取得ユニットは、ユーザからの入力を受信するように構成された通信インターフェースを含む。一実施形態において、通信インターフェースは、画像キャプチャデバイスおよびユーザインターフェースからなる群から選択される。一実施形態において、ユーザインターフェースは、タッチ対応スクリーンおよび音声対応ユーザインターフェースのいずれかまたは組合せである。
【００２４】
本開示の別の態様は、ユーザの臨床状態を監視する方法に関し、方法は、(i)医療デバイスのセットからのユーザの臨床情報と、ユーザの過去のバイタル情報を含むデータベースからのユーザの非臨床情報とを取得するステップと、(ii)少なくとも1つのメモリデバイス上に、ユーザの臨床情報および非臨床情報の蓄積されたデータセットを形成するために、医療デバイスのセットおよびデータベースから取得された前記臨床情報および非臨床情報を蓄積するステップと、(iii)予測モデルおよび履歴データ比較モデルのいずれかまたは組合せに基づいて前記蓄積されたデータセットを分析するステップであって、蓄積されたデータセットの前記分析がユーザの臨床状態の評価を含み、その評価に基づいて、定義された時間間隔にわたってユーザの縦断的状態が予測される、ステップと、(iv)ディスプレイユニットによって、蓄積されたデータセットの一部を形成する分析された臨床情報および分析された非臨床情報のいずれかまたは組合せを表示するステップとを含む。
【００２５】
一実施形態において、方法は、ユーザの1つまたは複数の臨床パラメータの制御に関連する1つまたは複数のデバイスを制御することによって、前記予測に基づいて、1つまたは複数の臨床パラメータを制御するステップをさらに含む。
【００２６】
本開示の別の態様は、ユーザの臨床状態を監視するためのシステムに関する。提案されるシステムは、ユーザの臨床状態を監視するように動作可能な1つまたは複数のルーチンが具体化された非一時的記憶デバイスと、非一時的記憶デバイスに結合され、1つまたは複数のルーチンを実行するように動作可能な1つまたは複数のプロセッサとを含み、1つまたは複数のルーチンが、アプリケーション開発およびテストサーバ上に記憶されたルーチンの第2のセットと関連して実行され、1つまたは複数のルーチンが、1つまたは複数のプロセッサによって実行されると、医療デバイスのセットからのユーザの臨床情報と、ユーザの過去のバイタル情報を含むデータベースからのユーザの非臨床情報とを取得する情報取得モジュールと、1つまたは複数のプロセッサによって実行されると、ユーザの臨床情報および非臨床情報の蓄積されたデータセットを形成するために、医療デバイスのセットおよびデータベースから取得された前記臨床情報および非臨床情報を収集および記憶する情報記憶モジュールと、1つまたは複数のプロセッサによって実行されると、予測モデルおよび履歴データ比較モデルのいずれかまたは組合せに基づいて、前記蓄積されたデータセットを分析する情報処理モジュールであって、蓄積されたデータセットの前記分析が、ユーザの臨床状態の評価を含み、その評価に基づいて、定義された時間間隔にわたってユーザの縦断的状態が予測される、情報処理モジュールと、1つまたは複数のプロセッサによって実行されると、蓄積されたデータセットの一部を形成する分析された臨床情報および分析された非臨床情報のいずれかまたは組合せを表示するディスプレイモジュールとを含む。
【００２７】
一実施形態において、システムは、蓄積されたデータセットの一部を形成する臨床情報および非臨床情報のいずれかまたは組合せをサーバ/データベースに送信するように構成された情報送信モジュールをさらに含む。
【００２８】
一実施形態において、医療デバイスのセットは、心肺モニタ、パルスオキシメータ、血液ガスマシン、および人工呼吸器のいずれかまたは組合せを組み込んでいる。一実施形態において、医療デバイスは、ラボラトリー情報管理システム(LIMS)、画像保管通信システム(PACS)、病院情報システム(HIS)、および電子医療記録(EMR)のいずれかまたは組合せとインターフェースされる。
【００２９】
一実施形態において、定義された時間間隔にわたるユーザの縦断的状態の前記予測に基づいて、情報処理ユニットは、ユーザの1つまたは複数の臨床パラメータの制御に関連する1つまたは複数のデバイスを制御することによって、1つまたは複数の臨床パラメータの前記制御を可能にする。
【００３０】
一様態において、情報取得モジュールは、ユーザからの入力を受信するように構成された通信インターフェースを含む。一実施形態において、通信インターフェースは、画像キャプチャデバイスおよびユーザインターフェースからなる群から選択される
【００３１】
添付図面は、明細書の一部を構成し、本開示のさらなる理解を提供するために使用される。
【図面の簡単な説明】
【００３２】
【図１】本開示の一実施形態による、ユーザの臨床状態を監視する装置の様々な機能ユニット/構成要素の例示的な表現を示す図である。
【図２Ａ】本開示の一実施形態による、ユーザの臨床状態を監視するための提案されたシステムのネットワークアーキテクチャの例示的な表現を示す図である。
【図２Ｂ】本開示の一実施形態による、ユーザの臨床状態を監視するための提案されたシステムのネットワークアーキテクチャの例示的な表現を示す図である。
【図３】本開示の一実施形態による、提案されたシステムの様々な機能モジュールの例示的な表現を示す図である。
【図４】本開示の一実施形態による、ユーザの臨床状態を監視するための提案された方法の例示的なフローチャート表現を示す図である。
【図５】本開示の一実施形態による、システムとユーザインターフェースとを使用する患者監視のための方法に含まれる様々なステップの例示的なフローチャート表現を示す図である。
【図６Ａ】本開示の一実施形態による、複数のモジュールの同時機能のための複数のタブを表示するフロントパネルの絵画図を示す図である。
【図６Ｂ】本開示の一実施形態による、デバイスおよび電源との接続を確立するための複数のポートを表示するリアパネルを示す図である。
【発明を実施するための形態】
【００３３】
本開示の1つまたは複数の例示的な実装形態が最初に提供されるが、開示されるシステムおよび/または方法は、現在知られているかまたは存在しているかにかかわらず、任意の数の技法を使用して実装されてもよいことが理解されるべきである。本開示は、本明細書で例示または説明されている例示的な設計および実装形態を含む、以下に例示されている例示的な実装形態、図面、および技法に決して限定されるべきではなく、それらのすべての範囲の均等物とともに、添付の特許請求の範囲内で修正されてもよい。
【００３４】
本発明は、ユーザ(以下「患者」とも呼ばれる)の臨床状態を監視するための装置、システム、および方法に関する。より具体的には、本発明は、集中治療室(ICU)固有のプロトコルによって維持可能であり得る臨床データ、検査記録、臨床スコアをリンクする統一プラットフォームを提供することを想定する。堅牢なビッグデータインフラストラクチャによるICUワークフローのそのような自動化は、様々な時間枠における生理学的および臨床的表現型パラメータの監視および記憶を促進し、臨床マーカ発見プロセスにも役立つ。
【００３５】
図1は、本開示の一実施形態による、ユーザの臨床状態を監視する装置の様々な機能ユニット/構成要素の例示的な表現を示す。提案された装置(以下「NEOボックス」とも呼ばれる)100は、医療デバイスのセットからのユーザの臨床情報と、ユーザの過去のバイタル情報を含むデータベースからのユーザの非臨床情報とを取得するように適合/構成された情報取得ユニット102を含む。
【００３６】
装置100は、ユーザの臨床情報および非臨床情報の蓄積されたデータセットを形成するために、医療デバイスのセットおよびデータベースから取得された前記臨床情報および非臨床情報を収集および記憶するための少なくとも1つのメモリデバイス104をさらに含む。一実施形態において、装置100は、必要な情報を引き出すためにデータベースと通信するシステムとインターフェースするか、またはそのようなシステムを用いて構成することができる。
【００３７】
一実施形態において、医療デバイスは、RJ45/RS232/USBコネクタを介して提案された装置100に接続される。2つのRS232ポートがメインPCBにプロビジョニングされ、4つのRJ45ポートが、RJ45 PCBと呼ばれる他の小さいPCB上に設計される。TPリンクモデムを使用してWiFiに接続するために、USBハブを使用して2つのUSBポートが利用可能である。
【００３８】
装置100は、予測モデルおよび履歴データ比較モデルのいずれかまたは組合せに基づいて、前記蓄積されたデータセットを分析するように構成された情報処理ユニット106をさらに含む。
【００３９】
一態様において、蓄積されたデータセットの分析は、ユーザの臨床状態の評価を含み、その評価に基づいて、定義された時間間隔にわたってユーザの縦断的状態が予測される。
【００４０】
装置100は、蓄積されたデータセットの一部を形成する分析された臨床情報および分析された非臨床情報のいずれかまたは組合せを表示するように適合されたディスプレイユニット108をさらに含む。一実施形態において、ディスプレイユニット108は、装置100とインターフェースされたシステムとの間のリアルタイムデータの送信においてなんらかの不一致がある場合、ユーザに通知および/または警告してもよい。
【００４１】
一実施形態において、装置は、蓄積されたデータセットの一部を形成する臨床情報および非臨床情報のいずれかまたは組合せをサーバ/データベースに送信するように構成された情報送信ユニット110をさらに含んでもよい。
【００４２】
一実施形態において、情報取得ユニット102は、ユーザからの入力を受信するための通信インターフェースを含む。通信インターフェースは、画像キャプチャデバイスおよびインタラクティブタッチインターフェースからなる群から選択される。例えば、通信インターフェースは、メインPCBに取り付けられ、2つのBeagleBoneをプログラミングするために使用される2つのUSBポートを含んでもよい。
【００４３】
一実施形態において、電源ユニット112は、装置100の様々な構成要素/ユニットに電力を供給するために、ニッケルカドミウム(Ni-Cd)バッテリ、リチウムイオンバッテリ、およびウルトラキャパシタのいずれかまたは組合せを有するエネルギー蓄積器を含んでもよい。電源ユニット112は、例えば、ある場所から装置100が結合/構成されている別の場所への患者のベッドの輸送中に、AC/DC電源が利用できない場合に、装置100のための予備電源として機能する。
【００４４】
一実施形態において、装置100は、電源ユニット112ならびにイーサネット(登録商標)およびインターネット接続のためのポートをさらに備える。一実施形態において、提案されたシステムの電源ユニット112は、提案された装置内のBeagleBoneがLinux(登録商標)上で実行され、使用されていないときに適切にシャットダウンすることを可能にする。ソフトウェアシャットダウンを開始するBBBのシャットダウンピンをプルダウンすることによってこのシャットダウンを達成するために、電源スイッチPCBが電源ユニット112に構成されている。
【００４５】
医療デバイスとは別に、IPカメラもNEOボックス100とインターフェースされ、IPカメラは、臨床医が裁量で取り外すことができる柔軟な金属コネクタを使用して患者の上のベッドサイドに配置される。このカメラは、プラットフォーム内のライブ映像をユーザ/医療従事者に提供するために、ローカルネットワーク上でRTSPを使用してNEOボックス100と統合される。
【００４６】
一実施形態において、NEOボックス100は、多様なベッド側の機械によって提供されるリアルタイムデータを取得および記憶するために多様なベッド側の機械とリンクする新生児ベッド側安全監視デバイスである。NEOボックス100はまた、電子医療記録および検査室情報管理システムにリンクされたクラウドベースの臨床意思決定サポートシステム(以下、交換可能に統合新生児治療室またはiNICUと呼ばれる)にデータを送信する。そのような統合は、機器パラメータにおいて臨床オーダとのなんらかの不一致がある場合、警告/通知を送信することによって、診療において従う推奨事項に従って、心肺モニタ、パルスオキシメータ、血液ガスマシン、および人工呼吸器などの医療デバイスの使用を保証する。したがって、生体医療デバイスと臨床管理ワークフローとの間の効果的でシームレスな通信を促進することによって、セーフティネットとして機能する。加えて、他の臨床および検査室ベースの観察での生理学的時系列データストリームの可用性は、認知知能モジュールにおけるこのデータの利用を可能にし、それは、タイムリーな臨床介入において臨床医を支援する。このデータは、退院後のプラットフォームにもリンクされる。これは、高いリスクの新生児に関する縦断的研究が、新生児の健康におけるNICU介入の長期的影響を研究することをさらに可能にする。
【００４７】
一実施形態において、NICUにおけるNEOボックス100をセットアップすることは、USBプログラミングインターフェースを使用してBBBをプログラミングすることを必要とする。BBBの完全に「ゼロからの」セットアップは、Java(登録商標) 1.8、RXTXライブラリのインストールと、シリアルRS-232通信のためのttyO1ポートの有効化とを含む。イーサネット(登録商標)ネットワークおよびWiFi(TPLink)セットアップは、Debianオペレーティングシステムにおいて利用可能なconnmanデバイスドライバを使用して達成される。Bulldog APIは、LEDを点灯させるためにbeagleboneにおけるGPIOピンをプログラムするために使用される。システム起動時に、2つのcrontabがスケジュールされ、第1のcrontabは、正しいネットワーク設定でデバイスに接続することができるようにBeagleBoneのネットワーク状態を確立し、第2のcrontabは、シェルファイルからソフトウェアプログラムを呼び出すために、java(登録商標)プログラム、すなわちjarを呼び出す。
【００４８】
図2Aおよび図2Bは、本開示の一実施形態による、ユーザの臨床状態を監視するための提案されたシステムのネットワークアーキテクチャの例示的な表現を示す。
【００４９】
一態様において、提案されたシステム200は、インターネットオブシングス(IoT: Internet of Things)デバイス/器具とインターフェースされたコンピューティングデバイス206を用いて構成することができる。システム200は、ユーザの臨床情報ならびに非臨床情報の分析を容易にするために、様々な分析ツールおよび統計ツール、例えば、Apache Cassandraデータベースを組み込んだサーバ/サーバ208と通信することができてもよい。システム200は、ネットワーク204を介して、ユーザの臨床状態を監視する意図されたタスクを実行するために、限定はしないが、心肺モニタ、パルスオキシメータ、血液ガスマシン、および人工呼吸器などの複数の医療デバイス/システム202-1、202-2、202-3、...202-N(以下、個別に「医療デバイス202」とも呼ばれ、集合的に「医療デバイス202」とも呼ばれる)と通信することができる。一実施形態において、提案されたシステム200は、コンピューティングデバイス206またはサーバ208のいずれかに常駐してもよい。一実施形態において、コンピューティングデバイス206は、独自の装置(図1に示す)、モバイルデバイス、ラップトップ、パーソナルコンピュータ、携帯情報端末(PDA)、ネットワークデバイスなどのいずれかであってもよい。一実施形態において、提案されたシステム200は、提案された装置100を用いて実装される。
【００５０】
一実施形態において、医療デバイスは、ラボラトリー情報管理システム(LIMS)、画像保管通信システム(PACS)、病院情報システム(HIS)、および電子医療記録(EMR)のいずれかまたは組合せとインターフェースされる。
【００５１】
ネットワーク204は、システム200が、例えば、ローカルイントラネット、パーソナルエリアネットワーク(PAN: Personal Area Network)、ローカルエリアネットワーク(LAN: Local Area Network)、ワイドエリアネットワーク(WAN: Wide Area Network)、仮想プライベートネットワーク(VPN: Virtual Private Network)、高度インテリジェントネットワーク(AIN: Advanced Intelligent Network)接続、同期光ネットワーク(SONET: Synchronous Optical Network)接続、デジタル回線接続、デジタルデータサービス(DDS: Digital Data Service)接続、DSL(デジタル加入者線:Digital Subscriber Line)接続、イーサネット(登録商標)接続、ISDN(統合サービスデジタルネットワーク:Integrated Services Digital Network)回線、またはケーブルモデムのダイアルアップポートの任意の1つまたは複数を介して、サーバ208および他の周辺機器と通信することを可能にする。さらに、通信はまた、ワイヤレスアプリケーションプロトコル(WAP: Wireless Application Protocol)、汎用パケット無線サービス(GPRS: General Packet Radio Service)、モバイル通信用グローバルシステム(GSM(登録商標): Global System for Mobile Communication)、符号分割多元接続(CDMA: Code Division Multiple Access)もしくは時分割多元接続(TDMA: Time Division Multiple Access)、携帯電話ネットワーク、Bluetooth(登録商標)無線、またはIEEE802.11ベースの無線周波数ネットワークを含む、様々なワイヤレスネットワークのいずれかへのリンクを含んでもよい。ネットワーク204は、RS-232シリアル接続、IEEE-1394接続、ファイバチャネル接続、IrDA(赤外線)ポート、SCSI(小型コンピュータシステムインターフェース:Small Computer Systems Interface)接続、USB(ユニバーサルシリアルバス:Universal Serial Bus)接続もしくは他の有線またはワイヤレス、デジタルもしくはアナログインターフェースもしくは接続、メッシュ、または他のネットワーキングのうちの任意の1つまたは複数をさらに含むことができ、またはそれとインターフェースすることができる。一実施形態において、ネットワークは、提案されたシステム200のワークフローを管理し、システム200との間でリアルタイムデータを送信するビッグデータインターフェースである。
【００５２】
一態様において、システム200は、医療デバイスのセットからのユーザの臨床情報と、ユーザの過去のバイタル情報を含むデータベースからのユーザの非臨床情報とを取得することができる。システム200は、ユーザの臨床情報および非臨床情報の蓄積されたデータセットを形成するために、医療デバイスのセットおよびデータベースから取得された前記臨床情報および非臨床情報を収集および記憶することができる。一実施形態において、医療デバイス200は、ネットワーク204を介して、提案されたシステム200に接続されてもよい。
【００５３】
ここで図2Bを参照し、医療デバイス202は、コンピューティングデバイス206のRJ45/RS232/USBコネクタを介して、提案されたシステム200に接続されてもよく、コンピューティングデバイス206は、図1に示すように、独自の装置(NEOボックス)100である。2つのRS232ポートがコンピューティングデバイス206のメインPCBにプロビジョニングされ、4つのRJ45ポートが、RJ45 PCBと呼ばれるコンピューティングデバイス206の他の小さいPCB上に設計される。TPリンクモデムを使用してWiFiに接続するために、USBハブを使用して2つのUSBポートが利用可能である。
【００５４】
一実施形態において、データ取得中、データを取得するために、様々なif条件がスレッドにおいて実装され、それは、毎分実行される。情報取得モジュール302は、最初に医療デバイスからデータを受信し、解析し、次いで、dataSend(キー/値ペア)に送り込む。このために、データを送信する毎分実行される個別のスレッドが存在する。次いで、データは、dataSendから取り出され、JSONフォーマットに変換される。ここで、JSONは、TPLinkを介してWi-fiを使用してクラウド(iNICU)に送信される。各取得は、デーモン(独立したスレッドであり、各送信が独立したスレッド)である。最後に、情報取得モジュール302は、サーバから肯定応答を受信し、データ取得の1つのスレッドを終了する。次いで、このループは、毎分繰り返される。
【００５５】
一態様において、システム200は、予測モデルおよび履歴データ比較モデルのいずれかまたは組合せに基づいて前記蓄積されたデータセットを分析することができ、蓄積されたデータセットの前記分析は、ユーザの臨床状態の評価を含み、その評価に基づいて、定義された時間間隔にわたってユーザの縦断的状態が予測され、システム200は、蓄積されたデータセットの一部を形成する分析された臨床情報および分析された非臨床情報のいずれかまたは組合せを表示することができる。一実施形態において、ディスプレイユニットは、システム200の異なる状態を示す4つのLEDを含んでもよい。1つのLEDは、それに構成/接続されたBeagleBone Blackデバイス(BBB)が機能しており、それに組み込まれたjava(登録商標)プログラムが実行されているかどうかを表示する。装置100が医療デバイスからデータを受信しているときに第2のLEDがオンにされる。TPLinkがデータベースにデータを送信しているときに第3のLEDが点灯し、装置100がデータベースから肯定応答を受信すると、第4のLEDが点滅する。
【００５６】
提案されたシステム200は、様々な疾患状態を相関させるために、異なる医療デバイスの生理学的データ、臨床データ、ならびに検査データの経時的なリンクを可能にするために、異なる医療デバイスの異なるパラメータを集約する。疾患状態にリンクされたこの生理学的時系列データは、所与の疾患状態における、または、ICUにおける患者の滞在中に目撃された後のエピソードとのその関連における、デバイスの適切な使用の関連付けを可能にする。
【００５７】
一実施形態において、システム200は、蓄積されたデータセットの一部を形成する臨床情報および非臨床情報のいずれかまたは組合せを、記憶またはさらなる処理のためにサーバ/データベースに送信してもよい。
【００５８】
システム200に帰する本明細書で説明する機能は、コンピューティングデバイス206内で実行されてもよいことが理解されるであろう。すなわち、コンピューティングデバイス206は、本明細書で説明する機能を実行するようにプログラムされてもよい。他の例において、システム200およびコンピューティングデバイス206がクライアント/サーバ関係において動作するように、システム200と相互作用するクライアント側アプリケーションがコンピューティングデバイス206に提供されるように、システム200およびコンピューティングデバイス206は、本明細書で説明する機能を提供するために協働してもよい。
【００５９】
新生児集中治療室(NICU)は、そのドメイン固有のオントロジ上に構築されたそのようなEHRシステムによって大きな利益を得ることができる、病気または早産の新生児のケアに特化した1つのそのようなICUである。NICUは、重い作業負荷、不十分なスタッフ人数、チームメンバー間の不十分なコミュニケーション、ならびに不十分な知識およびトレーニングなどの多くの要因が医療エラーの本質的なリスクに影響を与えることが判明している複雑なシステムである。
【００６０】
一実施形態において、提案されたシステム200は、新生児ケアを標準化するためにNICUとインターフェースされてもよく、それによって、共通ドメインオントロジを介してユニット全体の品質パラメータの比較測定を可能にする。これは、異なるNICUからの一貫した方法における臨床データの収集および比較を可能にする。
【００６１】
提案されたシステム200は、表現型マーカ、分子マーカ、および臨床マーカの発見プロセスのための12歳までの縦断的データを捕捉するために、統合小児健康記録(iCHR: Integrated Child Health Record)を利用することもできる。
【００６２】
図3は、提案されたシステムの機能モジュールの例示的なブロック図を示し、主要な機能モジュールと機能モジュールの相互接続とを示す。典型的なハードウェアおよび電子構成要素は、ユーザの臨床状態を監視するという前記の意図されたタスクを実行するように配置される。
【００６３】
図2Aおよび図2Bに示すようなシステム200は、一般に、1つまたは複数のプロセッサと、ネットワークインターフェースと、メモリとを備える。メモリは、本明細書でより詳細に説明する様々な方法を実行するためにプロセッサによって実行することができるロジック(例えば、命令)を備える。メモリは、1つまたは複数のプロセッサによって実行可能な様々な機能モジュールを記憶してもよく、機能モジュールは、情報取得モジュール302と、情報記憶モジュール304と、情報処理モジュール306と、ディスプレイモジュール308と、他のモジュール310とを含み、これらは、ユーザ/患者の臨床状態を監視する意図された機能を実行するために必要である。
【００６４】
一態様において、情報取得モジュール302は、医療デバイスのセットからのユーザの臨床情報と、ユーザの過去のバイタル情報を含むデータベースからのユーザの非臨床情報とを取得する。
【００６５】
一実施形態において、情報取得モジュール302は、Debianオペレーティングシステム上でJava(登録商標)1.8を実行する2つのプログラム可能なBeagleBone blackマイクロプロセッサからなる。各BeagleBone(BBB)は、それぞれ、デバイスおよびカメラから来るデータを取得するために、1つのUSBと、1つのRJ45と、RS232インターフェースシリアルピンとを有する。1つのUSBポートは、コンピューティングデバイスからbeagle boneをプログラムするように構成される。
【００６６】
一実施形態において、医療デバイス200は、ネットワーク204を介して、提案されたシステム200に接続されてもよい。別の実施形態において、医療デバイス202は、コンピューティングデバイス206のRJ45/RS232/USBコネクタを介して、提案されたシステム200に接続されてもよく、コンピューティングデバイス206は、図1に示すように、適切な装置(NEOボックス)100である。2つのRS232ポートがコンピューティングデバイス206のメインPCBにプロビジョニングされ、4つのRJ45ポートが、RJ45 PCBと呼ばれるコンピューティングデバイス206の他の小さいPCB上に設計される。TPリンクモデムを使用してWiFiに接続するために、USBハブを使用して2つのUSBポートが利用可能である。
【００６７】
一態様において、情報記憶モジュール304は、ユーザの臨床情報および非臨床情報の蓄積されたデータセットを形成するために、医療デバイスのセットおよびデータベースから取得された前記臨床情報および非臨床情報を収集および記憶する。
【００６８】
一態様において、情報処理モジュール306は、予測モデルおよび履歴データ比較モデルのいずれかまたは組合せに基づいて、前記蓄積されたデータセットを分析する。一実施形態において、蓄積されたデータセットの分析は、ユーザの臨床状態の評価を含み、その評価に基づいて、定義された時間間隔にわたってユーザの縦断的状態が予測される。
【００６９】
一実施形態において、定義された時間間隔にわたるユーザの縦断的状態の前記予測に基づいて、情報処理ユニットは、ユーザの1つまたは複数の臨床パラメータの制御に関連する1つまたは複数のデバイスを制御することによって、1つまたは複数の臨床パラメータの前記制御を可能にする。
【００７０】
一態様において、ディスプレイモジュール308は、蓄積されたデータセットの一部を形成する分析された臨床情報および分析された非臨床情報のいずれかまたは組合せを表示する。一実施形態において、ディスプレイモジュール308は、システム200との間のリアルタイムデータの送信においてなんらかの不一致がある場合、ユーザに通知および/または警告してもよい。
【００７１】
一実施形態において、ディスプレイモジュール308は、システム200の異なる状態を示す4つのLEDを含んでもよい。1つのLEDは、それに構成/接続されたBBBが機能しており、それに組み込まれたjava(登録商標)プログラムが実行されているかどうかを表示する。システム200が医療デバイスからデータを受信しているときに第2のLEDがオンにされる。モデム、例えば、TPLinkがデータベースにデータを送信しているときに第3のLEDが点灯し、システム200がデータベースから肯定応答を受信すると、第4のLEDが点滅する。
【００７２】
一実施形態において、他のモジュール310は、蓄積されたデータセットの一部を形成する臨床情報および非臨床情報のいずれかまたは組合せをサーバに送信するように構成された情報送信モジュールを含んでもよい。一実施形態において、情報送信モジュールは、BeagleBoneから取得されたデータをサーバ/クラウド/データベースに送信するためにTPLink WiFi USBドングルからなる。内部的に接続されるUSBハブPCBを使用して、TPリンクをBBBにおけるUSBポートに接続することができる。
【００７３】
一実施形態において、情報取得モジュール302は、ユーザからの入力を受信するように構成された通信インターフェースを含む。一実施形態において、通信インターフェースは、画像キャプチャデバイスおよびインタラクティブタッチインターフェースからなる群から選択される。例えば、通信インターフェースは、2つのBeagleBoneをプログラムするために使用される、メインPCBに取り付けられた2つのUSBポートを含んでもよい。一実施形態において、システム200は、電源ならびにイーサネット(登録商標)およびインターネット接続のためのポートをさらに備える。一実施形態において、提案されたシステムの電源は、提案された装置内のBeagleBoneがLinux(登録商標)上で実行され、使用されていないときに適切にシャットダウンすることを可能にする。ソフトウェアシャットダウンを開始するBBBのシャットダウンピンをプルダウンすることによってこのシャットダウンを達成するために、電源スイッチPCBが電源に構成されている。
【００７４】
一実施形態において、様々な医療デバイスからのデバイスデータを、情報取得モジュール302によってフェッチすることができる。デバイスベンダーは、それらのデバイスからのデータ取得のためにヘルスレベルプロトコル(HL7)をサポートしてもよい。システム200は、ICU設定において様々な医療デバイスからのデータをフェッチするために、オープンソースHAPI(I-1L7 API)を使用し、HL7 2.Xバージョンをサポートする。同時ライブデータフィードを取得するために、サポートするデバイスごとに別個のスレッドが開始される。医療デバイスの各々との接続を確立するために、様々なデバイスの固有のHL7適応が使用される。
【００７５】
医療デバイスデータ統合(MDDI: Medical device data integration)層は、2つのブロック、すなわち、クライアントおよびサーバに分割される。クライアントコードは、様々なデバイスからのデータ取得を可能にするHL7およびRS232におけるラッパーを提供するBBB上で実行されている。クライアント側コードは、NICU設定における様々なデバイスからのデータをフェッチするためにHL7 2.Xおよび3.XバージョンをサポートするオープンソースHAPI(HL7 API)を使用する。RS232インターフェースについて、RXTX Java(登録商標)ベースの通信APIがBBBにおいて使用される。同時ライブデータフィードを取得するために、サポートする医療デバイスごとに別個のスレッドが開始される。BBB上で実行されるJava(登録商標)コードは、デバイスからのデータを取得し、それをJSONフォーマットにおいて解析する。解析されたデータは、次いで、必要なパラメータ、患者ID(またはUHID)、装置識別子、装置のmac id、および医療デバイス名とともにサーバ層に送信される。装置名は、NICU施設に提供されるiNICU医療デバイス/装填の名前である。サーバ層は、オープンソースのSpring-BootとApache Cassandraとを使用して実装される。サーバは、様々なクライアント実装形態から来る非構造化データのリアルタイムストリームにサブスクライブし、それをNoSQL Cassandraデータベース内に記憶する。受信されたデータがアクティブUHIDとの有効なマッピングを有する場合にのみ、データは、Cassandraデータベースに記憶される。サーバソフトウェアプラットフォームはまた、ASTMプロトコル(JAVA(登録商標) ASTM API)を介してLIMSと統合される。画像キャプチャデバイスは、OpenCV Pythonライブラリを使用して構築される。患者のベッドサイドに配置された画像キャプチャデバイスとの接続を確立するために、リアルタイムストリーミングプロトコル(RTSP: Real-Time Streaming Protocol)が使用される。.jpgフォーマットにおける患者のリアルタイム画像フレームは、暗号化され、JSONフォーマットにおいて解析され、装置名とともにMDDIサーバ層に送信される。
【００７６】
RS232USBインターフェースについて、RXTX Java(登録商標)ベースの通信API(アプリケーションプログラムインターフェース)が使用される。これらのデバイスからのデータ集約は、インターネットオブシングス(IoT)ゲートウェイを使用して実行される。
【００７７】
マシンデータ統合(MDI: Machine Data Integration)サーバ層がオープンソースのApache Kafkaを使用して実装される。MDIサーバは、様々なMDIクライアント実装形態から来るデータのリアルタイムストリームにサブスクライブする。それは、非構造化データを記憶するためにApache Cassandraを使用する。MDIサーバピースはまた、ASTMプロトコル(JAVA(登録商標) ASTM API)を介してLIMSと統合される。
【００７８】
一実施形態において、サービス指向アーキテクチャを使用してインタラクティブユーザインターフェースが構築される。ユーザインターフェースは、タッチ対応スクリーン、または人工知能(AI)音声支援/ガイダンスシステム、例えば、Amazon Alexa(登録商標)、Microsoft Cortana(登録商標)、などの音声支援システムのいずれかまたは組合せを含んでもよい。サーバ部分は、Spring Bootフレームワークを活用するJava(登録商標)1.8言語を使用して実装される。ユーザインターフェース層は、応答性のAngularJS(JavaScript(登録商標)フレームワーク)およびHTML5を使用して構築される。これは、ユーザインターフェース層が応答性であることを可能にし、それは、タブレット、ラップトップ、モバイルデバイスにおいてシームレスに実行することができる。JSONベースのREST API統合は、Angular JSとSpring層とを接続する。患者データは、HL7統合を介して入院退院移動(ADT: Admission Discharge Transfer)イベントとして病院情報システムからアクセスされるか、または病院管理によって手動で入力される。臨床データは、PostgreSQL内に自動的かつ頻繁に記憶され、Hibernateは、Java(登録商標)ビジネス層からのデータベースのアクセスを可能にする。様々な新生児計算機(Neonatal calculator)は、Droolsルールエンジンを使用してコーディングされ、メタデータとして記憶される。ソリューションは、IBM Softlayerベースのクラウドインフラストラクチャ上でホストされる。成長チャートは、ハイチャートとJavaScript(登録商標)とを使用して実装される。クラウド構成要素は、webインターフェースを用いて256ビット暗号化によって保護されたHTTPベースの通信のみを許可する。
【００７９】
例示的な実装形態において、様々な医療デバイスからの連続データストリームは、例えば、iNICUデータディクショナリ内に存在する39フィールドを提供する。Cassandraデータベースは、心肺モニタからの11のそのようなフィールド、人工呼吸器からの14のフィールド、および血液ガスからの14のフィールドを記憶する。生データは、キースペース「inicu」と「inicu.patient_continuous」と名付けられたテーブルとを用いてCassandraデータベース内に持続した。使用される圧縮方式は、時間窓に基づく。したがって、時系列データは、主キーとして時間を使用して様々なクラスタにおいてセグメント化した。クラスタキーは、UHID、分、時、および日である。補足Excel 1は、40人の非特定化された新生児のサブセットのためのモニタおよび人工呼吸器から来る連続データを含む。Cassandraデータベースからの生データポイントは、次いで、iNICUインターフェースにおいてエンドユーザに利用可能なPostgreSQLにおいて毎分値を記憶するために処理される。
【００８０】
一実施形態において、情報取得モジュール302によって取得された臨床情報および非臨床情報は、PostgreSQL内に記憶され、波形/マシンデータは、Apache Cassandra内に記憶される。正規化されたデータは、非構造化データストアと構造化データストアの両方からフェッチされる。疾患ベースの新生児スコアは、乳児を様々な疾患に分類するのに役立つ。小児の入来ファクト(尿出力、RR、HR、末梢毛細血管酸素飽和度(Sp02)など)は、臨床ルールへの入力として機能し、マッチングルールの推論が実行される。これらの推論は、SMS/Google Cloud MessagingおよびApple Push Notification Serviceを介して、医師、看護師、および患者(特定の一人)に送信される警告および通知を生成する。
【００８１】
図4は、本開示の一実施形態による、ユーザの臨床状態を監視するための提案された方法の例示的なフローチャート表現を示す。一態様において、提案された方法400は、ステップ402において、医療デバイスのセットからのユーザの臨床情報と、ユーザの過去のバイタル情報を含むデータベースからのユーザの非臨床情報とを取得することを含んでもよい。
【００８２】
方法400は、ステップ404において、少なくとも1つのメモリデバイスにおいて、ユーザの臨床情報および非臨床情報の蓄積されたデータセットを形成するために、医療デバイスのセットおよびデータベースから取得された前記臨床情報および非臨床情報を蓄積することを含んでもよい。
【００８３】
方法400は、ステップ406において、予測モデルおよび履歴データ比較モデルのいずれかまたは組合せに基づいて、前記蓄積されたデータセットを分析することをさらに含んでもよく、蓄積されたデータセットの前記分析は、ユーザの臨床状態の評価を含み、その評価に基づいて、定義された時間間隔にわたってユーザの縦断的状態が予測される。
【００８４】
方法400は、ステップ408において、ディスプレイユニットによって、蓄積されたデータセットの一部を形成する分析された臨床情報および分析された非臨床情報のいずれかまたは組合せを表示することをさらに含んでもよい。
【００８５】
一実施形態において、方法は、ユーザの1つまたは複数の臨床パラメータの制御に関連する1つまたは複数のデバイスを制御することによって、前記予測に基づいて、1つまたは複数の臨床パラメータを制御するステップ410をさらに含んでもよい。
【００８６】
提案された方法/プロセスは、ハードウェアモジュールおよび/またはソフトウェアモジュールとして実装されてもよいことが理解されるであろう。例えば、方法400は、特定用途向け回路として、または、メモリにおいて記憶され、メモリと通信するプロセッサにおいて実行される命令を含むソフトウェアモジュールとして実装することができる。
【００８７】
一実施形態において、モニタおよび人工呼吸器などのベッド側デバイスのために、患者IDによるマッピングが必要である。NEOボックスがモニタおよび/または人工呼吸器に接続され、プローブが患者に接続されたら、ユーザは、正しいNEOボックス番号を接続するために、ダッシュボードの患者カードからiNICUアプリケーションにおいて追加デバイスモジュールをクリックする必要がある。また、ベッドの変更、機械の変更、ステップダウン施設への移動、および退院の場合に起こる場合がある、患者が医療デバイスから切断された場合に、NEOボックスをアプリケーションインターフェースから切断することも等しく重要である。
【００８８】
図5は、本開示の実施形態による、提案されたシステムおよび装置を使用する患者監視のための方法に含まれる様々なステップの例示的なフローチャート表現を示す。一実施形態において、方法は、図1に示すように、提案された装置/デバイスのユーザインターフェースを開始するステップ502を含む。その後、ステップ504において、提案されたシステムとのデバイスの接続が検出される。デバイスが検出されない場合、システムは、デイバスを検出するためにデバイスインターフェースを再び開始する。デバイスが検出された場合、ステップ506において、データがデータ取得ユニットに送信され、ステップ508において、データがフィルタリングされる。システムは、次いで、ステップ510において、フィルタリングされたデータが分析される必要があるかどうかを判定する。必要でない場合、ステップ512において、システムは、データが表示されるべきかどうかをチェックする。必要な場合、ステップ516において、分析なしのデータがディスプレイユニットの表示画面上に表示される。
【００８９】
ステップ510において、データが分析される必要があるとシステムが判定した場合、ステップ514において、データは、データ分析プロセッサに送信され、そこでデータが分析される。プロセッサによるデータの分析後、システムは、データが表示される必要があるかどうかを再びチェックする。必要な場合、分析されたデータがユーザインターフェース画面上に表示される。システムは、次いで、ステップ518において、データが記憶される必要があるかどうかを判定する。データが記憶される必要がある場合、ステップ520において、データは、メモリデバイス内に記憶され、そうでなければ、ステップ522において、システムは、データがサーバ/クラウドに送信される必要があるかどうかをチェックする。yesの場合、ステップ524において、データは、インターネットまたはイーサネット(登録商標)接続を使用してクラウドに送信される。
【００９０】
システムは、次いで、ステップ526において、ユーザからの任意の入力が必要かどうかを判定する。必要でない場合、システムは、ステップ528において、デバイスが検出され、プロセスが再び開始する際に基づく別のデータについてチェックする。ステップ526において、ユーザ入力が必要な場合、ステップ530において、システムは、ユーザ入力から導入された新しいデータが分析される必要があるかどうかを判定する。データが分析されるべきである場合、データは、データ処理ユニットに送信される。ステップ530において、データが分析される必要がない場合、システムは、次いで、ステップ532において、データを制御するためにデータがデバイスに送信される必要があるかどうかをチェックし、ステップ538において、必要な場合、必要なデータをデバイスに送信し、または、ステップ534において、データが記憶される必要があるかどうかをチェックする。データが分析される必要はないが記憶される必要がある場合、または、データが分析される必要はなく、制御のためにデバイスに送信される必要はないが、記憶される必要がある場合、ステップ536において、データは、メモリ内に記憶される。データがまったく記憶される必要がない場合、システムは、別のデータについてチェックし、デバイスを検出し、プロセスは続行する。
【００９１】
図6Aは、本開示の一実施形態による、複数のモジュールの同時機能のための複数のタブを表示するフロントパネルの絵画図を示す。本発明の一実施形態によるインタラクティブタッチインターフェースが示されている。様々な医療デバイスを、本開示の監視システムに接続することができ、これらのデバイスによって記録された臨床データを、単一のインタラクティブタッチユーザインターフェース上に表示することができる。これらのデバイスは、本発明のインタラクティブタッチユーザインターフェースにおけるユーザ定義の入力から直接調整することができる。ユーザは、メモリ内に記憶される必要がある他の関連する臨床情報を入力し、臨床医の指示として看護モジュールに表示することもできる。
【００９２】
一実施形態において、iNICUインターフェースは、様々なデバイスから来る生理学的データの同時データストリームを、任意の時点において離れていてもパラメータ間の任意の相関または相互相関について臨床医によってさらに解釈することができる単一の画面上に表示する。さらに、データは、視覚化することができ、ユーザによる任意の種類の時間分析のために異なるサンプリング頻度(時間または分データポイント)においてcsvファイルとしてダウンロードすることもできる。データの傾向とは別に、これらの変数の現在の値は、webアプリケーション内のカリエス(carious)位置において見ることができる。NICUユニットに入院したすべての患者に関する現在の状態を一度に表示するダッシュボード画面。この画面は、NICUユニットにおいて認められたリアルタイムデバイスパラメータとともに、すべての患者の現在の状態の最初の一瞥を提供する。したがって、提案されたNEOボックスは、患者の全データのシステムへの入力さえなしに、即座の介入を必要とする可能性がある患者の臨床的悪化について一見して臨床的決定を案出することを容易にする。
【００９３】
図6Bは、本開示の一実施形態による、デバイスおよび電源との接続を確立するための複数のポートを表示するリアパネルを示す。監視システムに接続された様々な医療デバイスからの臨床データならびに非臨床データが、図6Aに示すように単一のインタラクティブタッチユーザインターフェース上に表示されるように、これらの医療デバイスを、R.147/RS232/USBコネクタを介してシステムに接続することができる。
【００９４】
これらの実施形態に対する様々な修正は、本明細書における説明および図面から当業者には明らかである。本明細書で定義される様々な実施形態に関連する原理は、他の実施形態に適用されてもよい。したがって、説明は、添付図面とともに示される実施形態に限定されることを意図するものではなく、本明細書において説明/開示または示唆される原理および新規で発明的な特徴と一致する最も広い範囲を提供されることを意図するものである。本発明の要旨および範囲内の任意の修正、同等の置換、改善などは、すべて本発明の保護の範囲に含まれるものとする。
【００９５】
本発明の利点
本開示は、多次元(医療デバイス、臨床データ、LIMS、PACS)からのデータを1つのインターフェースに橋渡しする単一のディスプレイ画面を有する多目的のベッドサイドのスマートでコンパクトな統一プラットフォームを提供する。
【００９６】
本開示は、疾患の早期同定のためのパターン発見およびリアルタイム分析において臨床医を支援する認知知能アプリケーションを提供する。
【００９７】
本開示は、全国のICUの品質パラメータに対するこれらの実践の影響に関してエビデンスを集めることによって、臨床プロトコルの遵守を効果的に強化することを想定している。
【００９８】
本開示は、専門家による地方における資源不足環境において存在するICUの遠隔監視を可能にすることを想定している。
【００９９】
本開示は、本開示のシステムを使用して、データを捕捉し、処理し、分析し、記憶および表示するための方法を提供する。
【０１００】
本開示は、患者のすべての病歴と共にリアルタイムのバイタルを監視するためにそれらのモバイルインターフェースにリンクする、自宅における患者のバイタルを捕捉するためにウェアラブルデバイス(例えば、HR、RRなどを捕捉するセンサを有するソックス)を使用して退院後の健康監視を提供する。
【符号の説明】
【０１０１】
100  装置、NEOボックス
102  情報取得ユニット
104  メモリデバイス
106  情報処理ユニット
108  ディスプレイユニット
110  情報送信ユニット
112  電源ユニット
200  システム
202  医療デバイス
202-1  医療デバイス/システム
202-2  医療デバイス/システム
202-3  医療デバイス/システム
202-N  医療デバイス/システム
204  ネットワーク
206  コンピューティングデバイス
208  サーバ
302  情報取得モジュール
304  情報記憶モジュール
306  情報処理モジュール
308  ディスプレイモジュール
310  他のモジュール
【図１】
2020528814.tif 000003
【図２Ａ】
2020528814.tif 000004
【図２Ｂ】
2020528814.tif 000005
【図３】
2020528814.tif 000006
【図４】
2020528814.tif 000007
【図５】
2020528814.tif 000008
【図６Ａ】
2020528814.tif 000009
【図６Ｂ】
2020528814.tif 000010
【国際調査報告】
2020528814.tif 000011
2020528814.tif 000012