臨床診断分析機のイベントに基づく通信
【課題】遠隔のバックオフィスにより監視するためのサポートを備えた、ネットワーク化された臨床診断分析機を開示する。
【解決手段】開示された臨床診断分析機は、バックオフィスが、関心の対象となるイベントの定義を修正することを可能にすると共に、そのイベントをリアルタイムで検出するためのモジュールを含む。モジュールは、仮想プライベートネットワーキングを用いてバックオフィスネットワークへとネットワーク化され、このネットワークは、通常、臨床診断分析機が配備された場所のネットワークとは異なる。リアルタイムの警報により、実際のエラー状態または予測されるエラー状態に対する迅速な応答、および、最も関心の対象であり、かつ関連性があると思われる、記録データのダウンロードの双方を可能にする。
【解決手段】開示された臨床診断分析機は、バックオフィスが、関心の対象となるイベントの定義を修正することを可能にすると共に、そのイベントをリアルタイムで検出するためのモジュールを含む。モジュールは、仮想プライベートネットワーキングを用いてバックオフィスネットワークへとネットワーク化され、このネットワークは、通常、臨床診断分析機が配備された場所のネットワークとは異なる。リアルタイムの警報により、実際のエラー状態または予測されるエラー状態に対する迅速な応答、および、最も関心の対象であり、かつ関連性があると思われる、記録データのダウンロードの双方を可能にする。
【発明の詳細な説明】
【開示の内容】
【０００１】
〔背景〕
臨床検査および診断システムの、期待されるパフォーマンスの推定および実際のパフォーマンスの監視は、詳細な最新の情報を必要とする。臨床検査および診断システムは、高スループットを維持しつつ、正確な評価分析を行うために、多くの構成要素とサブシステムとを複雑な調整された組合せで含んでいる。ニュージャージー州ラリタン（Raritan）のOrtho Clinical Diagnostics(「ＯＣＤ」)によって製造されたVITROS 5600（商標）およびECi系列の臨床診断分析機により、例が提供される。
【０００２】
臨床検査および診断システムの使用は、研究所によってかなり異なる。医師は、保護下にある患者を効果的に監視することができるように、結果について迅速なターンアラウンドタイムを必要とする。たとえば、腎臓の問題または外傷を抱えた患者は、彼らの電解質レベルを適切に管理するよう評価され監視される必要がある。さらに、ローカルなニーズのために、種々異なる臨床検査室で検査の種々異なる混合が生じ、これにより、分析機のパフォーマンスを評価するのに、カスタマイズされたアプローチが必要とされる場合があり得る。
【０００３】
高水準の信頼性を確実にするための検査には、迅速なサービス時間と分析機パフォーマンスの向上との両方を目指した監視が含まれることが好ましい。この目的のためには、定期的にデータを提供し、分析機の操作を反映する膨大な数のイベントを記録するために、埋め込みコントローラがしばしば信頼されている。このデータは、固定された時間、例えば真夜中等にアップロードされる。このようなデータは、古くなっているばかりではなく、量が膨大であり、関心の対象であるイベントを分析するタスクを退屈なものとしている。
【０００４】
臨床診断分析機における埋め込みコントローラ（「埋め込みデバイス」とも呼ばれる）は、しばしば、インターネットとのインタフェースを有する内部ネットワーク、例えばローカルエリアネットワーク（ＬＡＮ）、無線ＩＥＥＥ(アメリカ電気電子技術者協会) 802.11、無線ブロードバンド、またはHomePlug powerlineに接続される。埋め込みデバイスは、典型的にはファイアウォールの後ろにあり、外部監視システムによって直接アドレスされたり発見されたりするのが防止されている。
【０００５】
埋め込みデバイスの使用に対するこの制限は、ネットワークを安全なものとし、患者データを保護する必要性のために予期されるものである。この結果、遠隔地に据え付けられた臨床診断分析機を自由に監視することは、非実用的でないとしても、困難である。いくつかの監視アプローチが提案されて来ており、その幾つかは、監視のニーズと、秘密データのための安全な環境を維持するための要件とをバランスさせたものである。
【０００６】
米国特許第６，７６８，９６８号（「‘９６８号特許」）は、コンピューターシステムのパフォーマンスを推定するための戦略を開示している。臨床診断分析機には処理能力が含まれるが、この処理能力は、その高度に専門化された特性に鑑み、コンピューターシステムと全く似ているわけではない。‘９６８号特許は、プライバシーのニーズを十分に考慮していない、ある監視戦略を開示している。診断分析機におけるコンピュータは、生物学的材料を正確に検査すること（このデバイスの主目的）のために電気部品および機械部品と統合されている。この統合デザインに影響を与えやすい障害は、コンピューターシステムで経験される障害とは類似していない。
【０００７】
米国特許第７，２５４，６０１号（「‘６０１号特許」）は、一組のアセットのためになりすまし（masquerades for a set of assets）、アドレスを翻訳し、かつ、「事業体の母国語を話す」ために必要とされるプロトコル変換を提供する、ゲートウエイとインターネット標準プロトコルとを介する、遠隔の機器へのコンピュータベースの直接接続を確立することによる、遠くに配備されたインテリジェント機器の管理方法を開示している。‘６０１特許は、ファイアウォールを通る必要性について議論しており、大部分のファイアウォールが、ブラウザがウェブページを検索するのに使用するプロトコルであるＨＴＴＰトラフィックを許容することに注目している。このアクセスは、エクステンシブル・マークアップ言語（ＸＭＬ）でフォーマットされたテキストメッセージに基づくウェブサービスを提供して、リクエストをメッセージとしてパックするために使用できるものである。このような標準の中には、ＷＳＤＬ（ウェブサービス記述言語）、ＳＯＡＰ（シンプル・オブジェクト・アクセス・プロトコル）、およびＸＭＬを含むものがある。しかしながら、この開示物は、リアルタイム警報の提供については教示していない。
【０００８】
米国特許第６，３７７，１６２号（「‘１６２号特許」）は、画像を生成する医学的診断システムの双方向フィールドサービスを提供するためのフィールドサービス装置を開示している。‘１６２号特許は、Ｘ線走査から生じるような画像を生成するシステムに焦点を当てているので、臨床診断分析機が遭遇する障害については開示も対応もしていない。
【０００９】
米国特許公開第２００７／０２８８６２９号（「‘６２９号公開」）は、正常運転条件の間は第一のポーリング速度で、ファイアウォールの外側の事業体システムに対しポーリングコールを定期的に送信し、障害状態の検出に応じて、第二のポーリング速度でファイアウォールの外側のデバイスにポーリングコールを送信することにより、ファイアウォールの外側に障害情報を送信することを開示している。第二のポーリング速度は、第一のポーリング速度より高い。この方法には、障害状態が検出されたとき、このポーリングコールで問題報告書を送信することが含まれる。ファイアウォール内からの要請の送信により、ファイアウォール内のデバイスと外部システムとの間に、ファイアウォールを介した双方向接続の開放が可能になる。しかしながら、ファイアウォール内からのポーリングメッセージがない場合には、埋め込みデバイスは、ファイアウォール外のシステムによって発見されることができないままである。
【００１０】
米国特許第６，７５７，７１４号（「‘７１４号特許」）ならびにこれに関連する特許および特許出願は、リモートサーバーへの電子メールを介する、装置のエラー状態の獲得および伝達について開示している。一以上の変数を得て、テンプレートに挿入することによって、電子メールメッセージを生成するのに、予め定められたテンプレートが用いられる。エラー状態は、電子メールメッセージの本文の一部として、または、電子メールメッセージへの添付ファイルの一部として含まれ得る。エラー状態は、エクステンシブル・マークアップ言語（ＸＭＬ）等の自己記述コンピュータ言語を使用して報告される。一般的に、エラー状態は、埋め込みコントローラの助けにより決定される。リモートサーバーは、エラー状態を顧客関係管理システムに渡す。
【００１１】
‘７１４号特許の開示では、リモートサーバーが、埋め込みコントローラに直接アドレスできなくても、リモートサーバーは、電子メールにより、装置に関する情報を得ることができる。電子メールは、たとえば、リモートサーバーが、埋め込みコントローラと同じ内部ネットワーク上にない場合に、情報を提供することができる。さらに、エラー状態が、ＸＭＬを使用して報告されるので、リモートサーバーは、メンテナンスを自動的にスケジュール化し得る。予期し得るように、このようなシステムにおける電子メールは、監視システムによる抽出のための状態情報を含む。‘７１４号特許では、エラー通知が、予め定義されたイベントの検出に限られ、予め定義されたイベント以外のものを検出するように警報をカスタマイズする能力は持たない。
【００１２】
臨床診断分析機を監視するためのもう一つのオプションは、ターゲットの分析機をプログラムし直すためにターゲットの分析機にプログラムを送信することである。ＸＭＬコーディングを用いて遠隔デバイスをプログラムすることは、米国特許第７，１７８，１４９号に記述されている。しかしながら、そのようなプログラミングは、プログラム言語のそれぞれのコマンドが、ＸＭＬのタグと対応させられ、ＸＭＬのオーバーヘッドが追加されて、伝達されるプログラムコードを非常に膨大なものとすることになるため、分析機を監視するタスクの複雑さをかなり増大させる。ターゲットのデバイスでは、ＸＭＬでコード化されたプログラムは、デコードされる必要があり得るだけでなく、潜在的にコンパイルされ、動作される必要もあり得る。このようにして、ターゲットの遠隔デバイスのオーバーヘッドも、かなりより高いものとなる。ＸＭＬ自体は、単に、そのようなインプリメンテーションにおけるテキスト伝達方法であり、プログラムコードを含む電子メールを送ることと少しも異ならない。これらの考慮すべき問題により、このアプローチは臨床診断分析機のカスタマイズされた遠隔監視には不適切となる。
【００１３】
その代わりに、米国特許第６，８９２，３１７号で記述されるような分散システムで、ネットワーク化されたデバイスを監視するための複雑な回路および機能性を実装し得る。しかしながら、これは、ファイアウォールによって保護された別のネットワークにおける臨床診断分析機では動作しない。このようにして、臨床診断分析機のよりよい監視へのニーズがある。
【００１４】
〔概要〕
本明細書に開示された実施形態により、遠隔の臨床診断分析機におけるイベントのカスタマイズ可能な監視システムと監視方法とが提供される。記述された実施形態により、上述の課題が克服される。
【００１５】
手短に言えば、好ましい一実施形態では、（ａ）監視されるイベントを指定し、カスタマイズするために、効率的で柔軟なコーディング戦略が採用され、（ｂ）プライバシーを損なうことなく、警報を報告するための埋め込みデバイスに対して、また、警報を報告するための埋め込みデバイスによって、必要なアクセスを提供するために、臨床診断分析機が二つのネットワークへ統合され、（ｃ）迅速な応答と関連記録データの遠隔伝達との両方を可能にするために、カスタマイズされたイベントの検出に応じて、リアルタイム警報が発生される。
【００１６】
この好ましい実施形態では、一群のカスタマイズされたイベントのうち一以上の検出に応じて、警報が発せられる。カスタマイズされたイベントは、臨床診断分析機について予め定義された基本的イベントを論理的に結合することによって記述される。その結果、たとえば、分析機の、エラー予測、エラー検出および遠隔監視のサービスを改善するためにイベントをカスタマイズすることが可能になる。
【００１７】
警報可能なイベント（alertable event）が検出された場合、そのイベントは記録され、外部モニターにメッセージが返信される。次いで、外部モニターのサーバが、必要に応じてそのメッセージを処理する。
【００１８】
他の一態様では、好ましい実施形態に、臨床診断分析機で発生したリアルタイム警報を外部モニターに伝達するためのモジュールが含まれる。このモジュールには、カスタマイズされたイベントを検出するための、カスタマイズされたイベント検出サブモジュールが含まれる。接続サブモジュールは、外部モニターが安全なネットワーク接続を介して臨床診断分析機にリンクされる、外部モニターへのリンクを提供する。カスタマイズされたイベントは、カスタマイズされたイベントを動的に更新するためのサブモジュールによって更新され得る。データロギング設備は、外部モニターに送信されるか、または外部モニターにより検索されている情報の記録を容易にする。
【００１９】
好ましい一実施形態では、埋め込みモジュールが、二つのネットワークアドレスを持つ。臨床診断分析機は、典型的には、患者のプライバシーを保護するためのファイアウォールおよび他の安全装置の付いた第一のネットワークに置かれる。埋め込みモジュールは、インターネットを通り抜ける(tunnel through)仮想プライベートネットワークリンクを通って、第二のネットワーク中の外部モニターに接続されることが好ましい。外部モニターは、第一のネットワークに対し外部にあり、埋め込みモジュールと第二のネットワークの外部モニターとの間のリンクを完成するために、インターネットは、第一のネットワークを介してアクセスされる。このようにして、埋め込みモジュールは、患者を特定する情報へのアクセスを伴わないかまたは患者を特定する情報へのアクセスを要しない、限定されたタスクを実施するための第二のネットワークの一部であるものとして取り扱われ得る。
【００２０】
第二のネットワークでは、埋め込みモジュールと外部モニターとが、同じサブネット上にある。このサブネットは、臨床診断分析機に関する通信を保護し、隔離するために、第二のネットワークの他の部分からさらに隔離されているのが好ましい。
【００２１】
外部モニターに警報を伝達するために、モジュールがウェブページに掲示を行うことが好ましい。外部モニターは、ファイル転送プロトコル(File Transfer Protocol)等のプロトコル、またはハイパーテキスト転送プロトコル(Hyper Text Transfer Protocol)のＧＥＴコマンドを用いて、臨床診断分析機の記録データにアクセスし得る。通常、埋め込みモジュールは、臨床診断分析機におけるカスタマイズされたイベントを検出するための回路、外部モニターに警報を伝達するための回路、カスタマイズされたイベントを動的に更新するための回路、および、外部モニターに送信される情報、または外部モニターによって検索される情報を記録するための回路を備える。
【００２２】
カスタマイズされたイベントにおける変化を実行するための回路は、変化で指定された少なくとも一つの論理演算が、特定のタグではなく、ＸＭＬタグの順序とコンテキストとでコード化されるように、ＸＭＬでコード化された命令としてその変化を受け取ることが好ましい。
【００２３】
カスタマイズされたイベントが生じると、カスタマイズされたイベントを検出するための回路は、命令を解釈して、カスタマイズされたイベントを識別する。好ましい一実施形態では、基本的イベントを結合するための命令によって指定された論理演算が、特定のタグの代わりに、ＸＭＬのタグの順序とコンテキストとでコード化される。
【００２４】
都合のよいことに、埋め込みモジュールには、外部モニターが、ＶＰＮリンクを用いて直接アドレスし得る。その結果、情報を記録するための回路が実行されて、定期的に、または、モジュールによって検出された、カスタマイズされたイベントの報告に応じて、外部モニターがログファイルに限定的にアクセスできるようになる。この限定的なアクセスにより、分析機の効果的な監視を可能とするのに充分なアクセスが許容される一方、患者のプライバシーが保護される。当業者に明らかなように、この限定的アクセスさえも、直ちに否定され得る。
【００２５】
好ましい一方法は、臨床診断分析機で発生したリアルタイム警報を、外部モニターに伝達するように適切に設計されたモジュールで実施される。この方法は、臨床診断分析機におけるカスタマイズされたイベントを検出するステップ、カスタマイズされたイベントの検出に応じて、外部モニターとリアルタイムで通信するステップであって、外部モニターは安全なネットワーク接続を介して臨床診断分析機にリンクされる、ステップ、外部モニターから受信した命令に応じて、カスタマイズされたイベントを変化させるステップ、および、外部モニターに送信される情報、または外部モニターによって検索される情報を記録するステップを容易にすることを含む。
【００２６】
カスタマイズされたイベントは動的に指定され得る。好ましくは、命令によって指定された少なくとも一つの論理演算が、特定のタグではなくタグの順序とコンテキストとでコード化されるように、外部モニターから受け取られるカスタマイズされたイベントを記述する命令が、ＸＭＬでコード化される。新しく受信した命令が先の命令に取って代わり、それによって、イベントが動的にカスタマイズされる。さらに、カスタマイズされたイベントの検出に応じて、情報が、データログファイルに書き込むことにより記録され、分析機の障害探索およびパフォーマンスの評価に役立つ。
【００２７】
好ましいいくつかの実施形態のこれらの特徴および他の特徴が、後で簡単に説明する図面の助けを借りて以下に詳細に記述される。
【００２８】
〔好ましい実施形態の詳細な説明〕
臨床診断分析機の「基本的イベント」は、典型的には、一以上のパラメータまたはその中の変化の検出である。パラメータは、臨床診断分析機の状態の値または記述子である。一以上の指定された条件が実現すると、イベントが生じる。多数のこのような基本的イベントは、典型的には、臨床診断分析機について前もって定義される。関心の対象である基本的イベントが、エクステンシブル・マークアップ言語（「ＸＭＬ」）タグを使用して記述されることが好ましい。典型的には、種々のコマンドを実行している間、分析機の機能を監視するのにそのような基本的イベントが用いられる。一般的に、臨床診断分析機の多くの基本的イベントまたは全ての基本的イベントに対して、ＸＭＬタグやその他の記述子を定義し得る。
【００２９】
ＸＭＬを使用することには多くの利点がある。ＸＭＬは、イベント（基本的イベントの組合せまたはバリエーションであるものを含む）を定義するのに役立つ。ＸＭＬでコード化された命令および記述は、インタープリターを使用して、リアルタイムで迅速に実行され得、デバッグされ得る。さらに、ＸＭＬベースの定義は、テキストとして扱うことによって、直ちに伝達される。しかしながら、ＸＭＬタグは、人間が読み取ることはできるが、類似したタグ名を使用してまたは同一のタグ名さえ使用して、非常に異なる機能とデータとを記述することがしばしばある。ＸＭＬでコード化された命令および記述は、インタープリターを使用して、リアルタイムで迅速に実行され得、デバッグされ得る。さらに、ＸＭＬベースの定義は、テキストとして扱うことによって、直ちに伝達される。それにも拘わらず、あるコンテキストでは、ＸＭＬが、ＸＭＬに準拠した命令を実行することによって実施される機能の記述を行う。したがって、コンテキストが適切であれば、ＸＭＬは、データ、命令およびこれらの組合せを伝達する便利な方法を提供する。
【００３０】
実際には、ターゲットで（at a target）特定のタスクのセットを容易にするように設計されたＸＭＬの特定の例は、特定の機能を実施することができる「新しい機械」を創造する。このようにして、ＸＭＬでコード化された命令の解釈に応じて、一以上のＸＭＬタグによって指定される機能を実施する回路は、潜在的に、示された機能を実施する新しい構造体である。
【００３１】
好ましい一実施形態では、カスタマイズされたイベントを定義するために、基本的イベントが論理的に結合され得る。たとえば、長い間にわたるイベントの特定の数の発生が、カスタマイズされた関心対象のイベントを形成し得る。この好ましい実施形態では、そのようなカスタマイズされたイベントの検出に応じて、警報が発せられ得る。好ましい一実施形態では、イベントが、一以上の基本的イベントを結合するためのマークアップ言語（例えばＸＭＬ）でコード化された命令によってカスタマイズされる。結合のための少なくとも一つの論理演算が、特定のタグによってではなく、ＸＭＬタグの順序とコンテキストとでコード化されることが有利である。これにより、イベントを効果的に指定するために必要なタグの数が減り、それゆえに、イベントをカスタマイズする複雑さが減少する。
【００３２】
イベントの結合のための少なくとも一つの論理演算が、特定のタグではなく、ＸＭＬタグの順序と、ことによるとそのコンテキストとでコード化されることが有利である。この特徴により、命令の明快さが増し、イベントをカスタマイズするために必要なタグの数が減る。
【００３３】
イベントに基づく警報(Event Based Alert)は、システムに起こっている特定のシナリオを識別するために確立された一組のルールに対して、臨床診断分析機と関連パラメータとを評価する。例えば、これらのシナリオは、障害が起こる前に障害を防止すること（予知保全）を狙うものであり得、サービス提供者（メーカーであり得る）に障害後のシナリオを知らせるために使用されるものでもあり得る。これは、ＸＭＬまたは別の表示システムでコード化された基本的イベントを使用して、イベントをカスタマイズする能力を提供することによって達成される。
【００３４】
あるシナリオの条件が合致したとき、システム上のイベントが記録され、メッセージが、外部モニターサーバに返信される。次いで、外部モニターサーバは、必要に応じてメッセージを発信する（routes）。
【００３５】
イベントに基づく警報は、そのような警報を実行するための好ましいプラットフォームを提供する、ＯＣＤの臨床診断分析機VITROS 5600（商標）およびVITROS 3600（商標）のデザインと互換性を有する。ただし、イベントに基づく警報は、他の臨床診断分析機でも有用である。VITROS 5600（商標）およびVITROS 3600（商標）のそれぞれは、三つの化学作用プラットフォーム：（ｉ）乾式化学作用を用いるMicroSlides（商標）、（ｉｉ）湿式化学作用のためのMicroTips（商標）および、（ｉｉｉ）湿式化学作用を用いるMicroWells（商標）、をサポートし得る、マスタースケジューラー(Master Scheduler)によって提供される機能を用いる。ＯＣＤのマスタースケジューラーは、種々の化学作用プラットフォーム間で共用されるロボットアームおよびロボットピペッター（pipettors）を制御して、入力された患者のサンプルにランダムにアクセスすることもできる。イベントに基づく警報を提供するために、代替のスケジューラーを適切に改変し得ることは明らかである。
【００３６】
ＯＣＤのマスタースケジューラーは、たとえば、必要とされる検査の種類または量に拘わらず、任意の順序で入力されたサンプルに資源を割り当て、分析機のスループットを維持するかまたは改善するために、スケジューリング機能を実施する。ＯＣＤのマスタースケジューラーは、全体として２セットの検査要件を決定し、全体として、検査のための完了時間(Time to Complete)を最小限にするスケジュールを決定し、それによって、高スループットを維持する。
【００３７】
ＯＣＤのマスタースケジューラーは、種々のプラットフォームの間でのロボットアームおよびロボットピペッターの共有を許容することにより、複数の化学作用に基づく検査の実行もサポートして、入力サンプルへのランダムアクセスを提供することによるサンプルのスループットを管理する。入力サンプルからの二次元のランダムサンプリングを許容するために、種々の化学作用を行うプラットフォームが、革新的なサンプルのレイアウトにより、入力サンプルから切り離される。この入力サンプルへの二次元のランダムアクセスにより、サンプルを入力された順序で処理するという典型的な要件が実質的に取り除かれる。
【００３８】
ＯＣＤのマスタースケジューラーの利点には、例えば、複数のセンシオメトリック(sensiometric)デバイス（例えば、電位計、反射率計、ルミネセンス、光透過率、光子検出、サンプルの加熱のためのインキュベータ、試薬の供給および複数の試薬配送サブシステム）と共に、例えば複数のプラットフォーム、薄いフィルムスライドを含む消耗品の供給、反応槽およびキュベットを含む資源へのアクセスを提供しつつ、入力サンプルに二次元でランダムアクセスすることと言う相乗効果が含まれる。これらの全ては直ちにアクセスして利用することができる。
【００３９】
これらのプロセスおよび検査のそれぞれを制御するために、スケジューラーはサブシステムにコマンドを発行する。コマンドが実行されると、種々の測定がなされ、コマンドが、検出されたイベントに基づいてうまく実行されたことを確認するために、応答メッセージがスケジューラーに送り返され、ループが完了する。それにも拘わらず、臨床分析機の操作中のエラーは、高価で好ましくない現実であり続けている。したがって、臨床診断分析機のダウンタイムを減少させるために、エラーを予測するか、好ましくは防止するか、または修正するための種々の戦略を実行するように、分析機の種々の部品間のメッセージトラフィックを監視し得る。
【００４０】
このタスクは、臨床分析機が、プライバシーと秘密性とを保証するセキュリティを要求する患者サンプルを取り扱うという事実によって困難になっている。また、これらの臨床分析機は、通常、メーカーや修理サービスプロバイダーから遠く離れて据え付けられている。
【００４１】
開示された実施形態は、バックオフィスまたはサービスを提供するための指定の場所での、動的な監視ならびに予想的トラブルシューティングおよび遡及的トラブルシューティングを可能にしつつ、患者のプライバシーや分析機のセキュリティを危険にさらすことなく、そのような遠隔の臨床診断分析機の監視を容易にする。
【００４２】
モジュールは、（共用資源を使用することはあり得るが）、論理的に、その機能を実行するのに自己充足型である。資源は、典型的には、プロセッサタイムスライス、データベースデータ、他のモジュールと共有されるメモリ中のデータ、サブモジュール、共用ライブラリー機能、および当業者に周知の類似資源である。モジュールの作成方法は、当技術分野で通常の技量を有する開発者には既知である。実行可能コードへの機能分割のマッピングは、当業者によく知られている。
【００４３】
図１は、好ましい実施形態を例示する。図２は、ある方法における、概ね対応する基本的な制御の流れを例示する。この例示的な好ましい実施形態は、動的にカスタマイズされたイベントに応じてリアルタイムの警報を提供する。カスタマイズされたイベントは、臨床診断分析機で発生する基本的イベントまたは信号の特定の組合せとなるように定義され得る。いくつかの基本的イベントまたは信号が、一以上の論理演算のために別個のタグを必要とすることなく論理的に結合され得るように、カスタマイズされたイベントは、ＸＭＬを用いてコード化される。この好ましい実施形態の一態様では、ＸＭＬ命令の順序付けが適切な論理演算を指定するので、これが可能となる。
【００４４】
この好ましい臨床診断分析機は、実行されるときに、一連のメッセージを発生させるサブプロセス１００を有する。これらのメッセージの多くは、基本的イベントを反映するものである。メッセージは、データロギングスレッド(Datalogging Thread)１０５によって、ログファイルである一以上のデータログファイル(Datalog Files)１１０中に記録される。データログスレッド１０５は、外部モニターに送信されるかまたは外部モニターによって検索される情報を記録するための回路の一例である。
【００４５】
データログスレッド１０５は、イベントキュー(Event Queue)１１５でイベントのキューイングを発生させるか、または促進し得る。このようにキューに入れられたイベントは、警報スレッド(Alert Thread)１２０によって処理される。警報スレッド１２０は、キューに入れられたイベントを処理するために、標準ルールファイル(Standard Rule File)１２５および、利用できるならば、ダウンロードされたルールファイル(Downloaded Rule File)１３０も読み込む。好ましくは、システムパフォーマンスへの影響を減らすために、警報スレッド１２０には、低い優先順位が割り当てられる。警報スレッド１２０には、ルールファイル(Rule File)によって記述されたカスタマイズされたイベントおよびその他のイベントを実際に検出するために必要である、ルールファイルに含まれたイベントを実行するためのメモリバッファ等の資源のセットアップおよびリリースのための命令が含まれる。
【００４６】
警報スレッド１２０の演算の多くの態様は、データロギングスレッド１０５の演算と共に、図２で例示される。警報スレッド１２０は、臨床診断分析機におけるカスタマイズされたイベントを検出するための回路の例を提供する。有利なことに、図２のステップ２３５およびステップ２４０（後述）は、臨床診断分析機におけるカスタマイズされたイベントを検出するための回路により実行される動作のうちのいくつかを記述する。
【００４７】
図２に例示されるように、ステップ２００中にシステムがブートアップし、ステップ２０５中に警報スレッド１２０とデータロギングスレッド１０５とが初期化される。スレッドとしてのこれらのプロセスの実行は、システムパフォーマンス上のペナルティを減らして、インプリメンテーションを堅牢(robust)にするために好ましい。
【００４８】
ステップ２１５中、新しいルールファイルがダウンロードされたかどうかに関する決定がなされる。新しいルールファイルがダウンロードされたならば、制御はステップ２２０に移る。ステップ２２０中に、新しいルールファイルが警報スレッド１２０によってロードされたならば、制御はステップ２２５に移る。ステップ２２５中、標準ルールファイルの代わりに新しいルールファイルが使われ、制御がステップ２３５に移る。あるいは、制御は、ステップ２２０からステップ２４５に移る。ステップ２４５中、エラー状態を外部モニターサーバに伝達するために警報(Alert)にフラグが立てられる。この手順のバリエーションには、ダウンロードされたルールファイルを新しい「標準ルールファイル」としてマークすることが含まれ得る点に留意する必要がある。
【００４９】
他方、ステップ２１５中に新しくダウンロードされたルールファイルが検出されない場合には、標準ルールファイルのロード後、制御はステップ２３５に移る。
【００５０】
ステップ２３５中、警報スレッド１２０は、ロードしたルールファイル中の任意のカスタマイズされたイベントを含むイベントを考慮して、イベントキュー１１５の一以上のイベントを調べる。
【００５１】
好ましい実施形態の説明に戻って、カスタマイズされたイベントを効率的に指定するために使用されるＸＭＬタグおよび構造を例示するために、以下に、例示的なルールファイルが提供される。
【００５２】
上記のイベントでは、基本的イベントが、デバイスにおける熱電流（thermal current）を評価する。イベントをトリガするために、演算（例えば「ＥＱ」および「ＯＵＴＳＩＤＥ」）と共に種々のパラメータが指定される。パラメータが規定された範囲を満たす回数が、パラメータ「thresholdCount」によって指定される。パラメータthresholdIntervalは、パラメータthresholdCountとの関係で重要である。たとえば、６ヵ月の期間における３のカウントは、１分間における３のカウントとは異なって処理され得る。関連持続時間は、パラメータthresholdIntervalによって指定される。下記の例は、規定された範囲のセットを充足する回数が２回以上であることを要求する複合イベントを例示するものである。
【００５３】
好ましい実施形態では、ネストされたタグによって指定された全ての条件が、イベントを指定するために同時に充足される必要のあるRULEタグ内で、RULEタグの全体が、それ自身、イベントを指定するようになっており、有利である。このようにして、RULEタグ内に含まれるタグが論理的にＡＮＤでつながれる（ANDed）一方、ネスティングの同じレベルのRULEタグは、論理的に論理和をとられる（ORed）。これによって、基本的イベントを適切に組み合わせることにより、関心の対象である複雑なイベントを築き上げることができる。このようにして、ルールファイルを変えることができるだけでなく、臨床診断分析機のために予め定義されたイベントや条件を、より複雑なイベントを編成するための構築用ブロックとして使用できる。下記は、複数のカスタマイズされたイベントを、同一のＸＭＬでコード化されたルールファイルで定義する一例である。
【００５４】
パラメータ「ruleName」は、「THRESHOLD eventType」を使用する、臨床診断分析機のために定義された複合イベントを簡便に表す。VITROS 5600（商標）臨床診断分析機およびVITROS 3600（商標）臨床診断分析機は、臨床診断分析機における複数のデバイスとサブシステムとを監視し、操作するための大量のTHRESHOLD eventType記述子をサポートする。
【００５５】
この好ましい実施形態では、タグ「RULE」は、複合イベントを記述する。構成ファイルまたはルールファイル（実質上「ALERTCONFIG」タグで示される）は、６４個のこのような複合イベントに限定される。このようなイベントのそれぞれのために、「THRESHOLD」タグを使用して、最高１０個の閾値を指定し得る。さらに、それぞれのTHRESHOLDタグに対し、「CRITERIA」タグを使用して、５個以下の基準を指定し得る。要約すると、カスタマイズされたイベントを一つのタグが記述する。このタグには、たとえば、「ｍ」の時間単位内に「ｎ」回の値を上回るといった、閾値仕様（threshold specifications）のセット等がネストされる。閾値仕様のそれぞれについて、指定された基準（好ましくはその中にさらにネストされたタグで示される基準）に従って、検出されたパラメータを用いて演算が実行される。直ちに理解されるように、これらは、インプリメンテーションに特定的な詳細であり、異なるインプリメンテーションでは容易に改変し得るものである。
【００５６】
例示の基本的イベントが、下表に記述されている。
【表１】
【００５７】
上表では、熱制御デバイスの電流を監視するのに用いられる基本的イベント「THERMO_DEVICE_CURRENT」が記述されている。この基本的イベントは、数字コード‘２１４をこのイベントに割当てる。さらに、この表に示されているように、このイベントは三つのパラメータ：タイムスタンプ、電流が監視されているデバイスの識別、および電流の値（value of the current）、を受け入れる。上記のＸＭＬ記述に見られるように、デバイス４２に対し、熱電流が監視され、もしそれが６３〜８３の範囲外にあるならば、イベントが認識される。thresholdCountが１にセットされているので、そのようなただ一つの任意の生起が、警報(Alert)をトリガさせるのに十分である。
【００５８】
以下の例示的ルールファイルは、論理的ＡＮＤ演算を使用して、二つの異なるTHRESHOLD eventTypeコード／パラメータに対応する二つの予め定義された基本的イベントを結合する。このＡＮＤ演算は、同じネスティングレベルにある単一のRULEタグ内に両方のTHRESHOLD eventTypeコードを置くことによって暗黙に定義される。
【００５９】
図２に戻って、ステップ２３５中、関心の対象である警報を発生させる必要があるかどうか識別するためにルールファイルで指定されたイベントを警報スレッド１２０が適用する。臨床診断分析機で、イベントの種々の定義が多くの演算で計算され得るように、イベントを追跡し、カウントするためのバッファを提供するための複数の専用メモリ場所が割り当てられることが好ましい。
【００６０】
ステップ２４０中、警報スレッド１２０は、検査済イベントがルールファイルを充足するかどうかを決定する。ルールファイルを充足するイベントがない場合、すなわち、警報の発生に繋がるイベントがない場合、制御はステップ２１５に戻される。あるいは、イベントの検査時にルールファイルが充足された場合、警報スレッド１２０は、ステップ２４５中に、接続マネージャ(Connectivity Manager)１３５に警報(Alert)状態を知らせる。接続マネージャ１３５は、外部モニターと通信するための回路の例を提供するものである。
【００６１】
さらに、ステップ２５０中、警報スレッド１２０が、データロギングスレッド１０５を用いて警報(Alert)状態を記録し、その後、ステップ２５５中に、データログファイルが作成されるかまたは更新される。分析機の監視の続行のために、制御はステップ２５５からステップ２１５へ戻る。
【００６２】
例えば、接続マネージャ１３５によって発生し、送信されるＨＴＴＰポストコマンドによる、警報が、カスタマイズされたイベントに関する有用な関係情報をログファイルが持っていることを外部監視システムに知らせる。次いで、外部監視システムは、さらなるアクション（たとえば、サービスコール（service call）のスケジュール化）のために、これらのログファイルをダウンロードし得る。あるいは、識別されたデータをさらなる分析に掛け得る。外部モニターを収納しているバックオフィスにおける権限のある個人が、ログファイルのダウンロードを開始し得る場合がしばしばある。
【００６３】
図１の接続マネージャ１３５（好ましくは、外部監視システムへのリンクを提供する接続サブモジュールである）は、仮想プライベートネットワークリンクを利用することによってメッセージを送り、外部の中間ネットワーク（例えばインターネット）を安全に横断して、そのメッセージをバックオフィスサーバー(Back Office Server)１４５に届ける。バックオフィスサーバー１４５は、次に、警報またはその他の関連タスクをサービスセンター(Service Centers)１５０に転送し、そこで、データが分析され、対応が取られる。バックオフィスサーバー１４５は、好ましくはデバイスに依拠して、どこにメッセージを送るかを決め、次いで、適切なサービスセンターまたは個人に電子メールを送り得る。
【００６４】
図３は、好ましい埋め込みモジュールのいくつかの態様を例示する。たとえばイベントをカスタマイズするために、ネットワーク３０５のモジュール３００には、メッセージトラフィックとのインタフェース(Interface to Massage Traffic)３１０、イベント検出(Event Detection)のためのサブモジュール３１５、更新処理のための更新サブモジュール（sub-module Updating）３２０が含まれる。モジュール３００には、外部監視システムへのリンク(Link to External Monitoring System)のためのサブモジュール３２５、および、データロガースレッドへの接続(Connection to Datalogger Thread)３３０も含まれる。ネットワーク３０５は、接続３４５を介して外部監視システム(External Monitoring System)３４０を含むネットワーク(Network)３３５に接続される。外部監視システム３４０は、トンネリング(Tunneling)リンク３５０を経て外部監視システムへのリンクのためのサブモジュール３２５に接続される。外部監視システム３４０には、モジュール(Module)３００によってイベントをカスタマイズするためのデータおよび命令のアップロードとダウンロードとを管理するための、ダウンロード／アップロードインタフェースサブモジュール(sub-module Downloading/Uploading Interface)３５５が含まれる。
【００６５】
臨床診断分析機で発生したリアルタイムの警報を伝達するためのモジュール５００が、警報およびデータ通信用回路(Circuit for Communicating Alerts and Data)５２０と通信する、イベント検出用回路(Circuit for detecting an Event)５１０を含むものとして図５に例示されている。警報およびデータ通信用回路５２０は、外部モニター(External monitor)５５０との通信を管理する。警報およびデータ通信用回路５２０は、イベントの動的更新用回路(Circuit for Dynamically Updating Events)５３０と通信して、新しく受け取ったルールファイルに、更新されたイベント定義を提供する。
【００６６】
ルールファイル全体を、全ての警報可能なイベントの定義と共に受け取ることが好ましいが、ルールファイルを補うための更新版を持つことも請求項の範囲内である。この態様は、ステップ４００におけるイベント監視および、新しいイベント定義が存在するかどうかを決定するステップ４０５の決定ステップに制御が移る様子を示す図４で例示される。新しい定義が存在する場合には、ステップ４１０中にイベント定義が更新される。更新は、ルールファイルを置き換えるか、他の手段で定義を単に補うかまたは修正するかによって、なされ得る。イベントの検出については、図示されるように、制御は、ステップ４０５または４１０からステップ４１５に移る。ステップ４２０中、イベントが警報すべきものかどうかを決定するためにイベントが評価される。警報せず（not alert）が発行される場合には、制御はステップ４００へ戻る。そうでない場合は、制御はステップ４２５に移り、ステップ４２５中に外部モニターに警報が伝達され、警報可能なイベントに関する情報が、ステップ４３０中に記録される。
【００６７】
図１に戻って、サービスセンター(Service Centers)１５０は、ルールファイル１２５に取り込まれるべきイベントの代替の定義を提供し得る。これは、将来のイベントフラグ立てのために埋め込みモジュールに送信される。図２のステップ２１５〜２３０には、カスタマイズされたイベントにおける変更を実行するための例示的な回路のさらなる詳細が示されている。一般的に、ルールファイルは、外部的に造られ、一以上の埋め込みモジュールに送信され得る。これは、標準ルールファイルによってカバーされるシナリオ以外のシナリオを識別するためになされ得る。
【００６８】
バックオフィスサーバー１４５は、新しいルールファイルがダウンロードされたことを臨床診断分析機に告げる。これにより、警報スレッド１２０がダウンロードされたルールファイルをロードし、ソフトウェアで標準ルールファイルの代わりにそれが使用される。このファイルのロード障害は、図２（ステップ２２０からステップ２４５への制御の流れ）に示されているように、警報可能なイベントの一つである。
【００６９】
このようにして、ルールファイル構造により、よく知られている、柔軟性がない単一の（またはほんの少数の）閾値ルール（例えば、インキュベータの温度＞３５ならば警報発令）に比べ、より柔軟なルールの作成が可能になる。一般に、好ましい実施形態では、次のようなイベントにフラグを立てることが可能である。
（ｉ） （例えば、電源を落とすこと、ソフトウェアロードといった）発生する特定のイベント、
（ｉｉ） 特定のイベント属性についての条件で生じる特定のイベント｛例えば、システム環境(System Environment)イベントが記録され、周囲温度センサーが＞４０の値を持ち、始動イベントが生起し、適切なシャットダウンフラグが真にセットされていない｝、
（ｉｉｉ） 指定された時間フレーム（例えば６０秒）の範囲内での、上記に指定したようなイベント群の生起、および、
（ｉｖ） （例えば、閾値が１時間で５回を超えるといった）イベントの規定された数の生起。
【００７０】
さらに、図２に例示されていないが、処理のためにイベントをバッファリングするインメモリのイベントキューがその最大サイズに達すると、接続マネージャ１３５を介してバックオフィスサーバー１４５に警報(Alert)メッセージが送られ、バックオフィスサーバー１４５にイベントを処理する能力が、一時的になくなったことが告げられる。
【００７１】
警報スレッド１２０には、特定の時間枠（たとえば、ルールが別様に設定されていなければ３０分間）内で、同一のイベントを複数回再トリガすることからの防護が組み込まれていることが好ましい。これは、何千もの警報を下流へ押し流し得るカスケード効果を防止するものである。
【００７２】
言及したように、最新のログファイルを検索するよう外部モニターに命ずるように、ルールを構成し得る。条件がさらなるデータ分析を認可する（warrant）予定である場合に、この要請がメッセージに加えて送信され、役に立つ。
【００７３】
好ましい一実施形態では、例えば、セキュリティ違反が検出される場合に、または、疑われる場合にさえ、オペレーターが、リアルタイム警報メッセージをオフにして、制御可能に埋め込みモジュールを隔離するのを許容することにより、セキュリティとプライバシーとが強化される。
【００７４】
当業者ならば、上記の開示について、その教示内容または精神から逸脱することなく、多くのバリエーションおよび代替的インプリメンテーションが許容されることを認識するであろう。添付の請求項の範囲には、そのような変更が含まれる。さらに、本明細書で議論され、引用されたそれぞれの引用文献は、これにより、その全体が、参照により本明細書に取り入れられる。
【図面の簡単な説明】
【００７５】
【図１】遠隔の臨床診断分析機のための、処理モジュールと、外部モニターへの接続性と、の概略図である。
【図２】好ましい実施形態における、カスタマイズされたリアルタイム警報を発生させる際の、いくらかの顕著なステップを例示する図である。
【図３】遠隔の臨床診断分析機のための、処理モジュールと、外部モニターへの接続性と、の概略図である。
【図４】好ましい実施形態における、カスタマイズされたリアルタイム警報を発生させる際の、いくらかの顕著なステップを例示する図である。
【図５】遠隔の臨床診断分析機のための、処理モジュールと、外部モニターへの接続性と、の概略図である。
【開示の内容】
【０００１】
〔背景〕
臨床検査および診断システムの、期待されるパフォーマンスの推定および実際のパフォーマンスの監視は、詳細な最新の情報を必要とする。臨床検査および診断システムは、高スループットを維持しつつ、正確な評価分析を行うために、多くの構成要素とサブシステムとを複雑な調整された組合せで含んでいる。ニュージャージー州ラリタン（Raritan）のOrtho Clinical Diagnostics(「ＯＣＤ」)によって製造されたVITROS 5600（商標）およびECi系列の臨床診断分析機により、例が提供される。
【０００２】
臨床検査および診断システムの使用は、研究所によってかなり異なる。医師は、保護下にある患者を効果的に監視することができるように、結果について迅速なターンアラウンドタイムを必要とする。たとえば、腎臓の問題または外傷を抱えた患者は、彼らの電解質レベルを適切に管理するよう評価され監視される必要がある。さらに、ローカルなニーズのために、種々異なる臨床検査室で検査の種々異なる混合が生じ、これにより、分析機のパフォーマンスを評価するのに、カスタマイズされたアプローチが必要とされる場合があり得る。
【０００３】
高水準の信頼性を確実にするための検査には、迅速なサービス時間と分析機パフォーマンスの向上との両方を目指した監視が含まれることが好ましい。この目的のためには、定期的にデータを提供し、分析機の操作を反映する膨大な数のイベントを記録するために、埋め込みコントローラがしばしば信頼されている。このデータは、固定された時間、例えば真夜中等にアップロードされる。このようなデータは、古くなっているばかりではなく、量が膨大であり、関心の対象であるイベントを分析するタスクを退屈なものとしている。
【０００４】
臨床診断分析機における埋め込みコントローラ（「埋め込みデバイス」とも呼ばれる）は、しばしば、インターネットとのインタフェースを有する内部ネットワーク、例えばローカルエリアネットワーク（ＬＡＮ）、無線ＩＥＥＥ(アメリカ電気電子技術者協会) 802.11、無線ブロードバンド、またはHomePlug powerlineに接続される。埋め込みデバイスは、典型的にはファイアウォールの後ろにあり、外部監視システムによって直接アドレスされたり発見されたりするのが防止されている。
【０００５】
埋め込みデバイスの使用に対するこの制限は、ネットワークを安全なものとし、患者データを保護する必要性のために予期されるものである。この結果、遠隔地に据え付けられた臨床診断分析機を自由に監視することは、非実用的でないとしても、困難である。いくつかの監視アプローチが提案されて来ており、その幾つかは、監視のニーズと、秘密データのための安全な環境を維持するための要件とをバランスさせたものである。
【０００６】
米国特許第６，７６８，９６８号（「‘９６８号特許」）は、コンピューターシステムのパフォーマンスを推定するための戦略を開示している。臨床診断分析機には処理能力が含まれるが、この処理能力は、その高度に専門化された特性に鑑み、コンピューターシステムと全く似ているわけではない。‘９６８号特許は、プライバシーのニーズを十分に考慮していない、ある監視戦略を開示している。診断分析機におけるコンピュータは、生物学的材料を正確に検査すること（このデバイスの主目的）のために電気部品および機械部品と統合されている。この統合デザインに影響を与えやすい障害は、コンピューターシステムで経験される障害とは類似していない。
【０００７】
米国特許第７，２５４，６０１号（「‘６０１号特許」）は、一組のアセットのためになりすまし（masquerades for a set of assets）、アドレスを翻訳し、かつ、「事業体の母国語を話す」ために必要とされるプロトコル変換を提供する、ゲートウエイとインターネット標準プロトコルとを介する、遠隔の機器へのコンピュータベースの直接接続を確立することによる、遠くに配備されたインテリジェント機器の管理方法を開示している。‘６０１特許は、ファイアウォールを通る必要性について議論しており、大部分のファイアウォールが、ブラウザがウェブページを検索するのに使用するプロトコルであるＨＴＴＰトラフィックを許容することに注目している。このアクセスは、エクステンシブル・マークアップ言語（ＸＭＬ）でフォーマットされたテキストメッセージに基づくウェブサービスを提供して、リクエストをメッセージとしてパックするために使用できるものである。このような標準の中には、ＷＳＤＬ（ウェブサービス記述言語）、ＳＯＡＰ（シンプル・オブジェクト・アクセス・プロトコル）、およびＸＭＬを含むものがある。しかしながら、この開示物は、リアルタイム警報の提供については教示していない。
【０００８】
米国特許第６，３７７，１６２号（「‘１６２号特許」）は、画像を生成する医学的診断システムの双方向フィールドサービスを提供するためのフィールドサービス装置を開示している。‘１６２号特許は、Ｘ線走査から生じるような画像を生成するシステムに焦点を当てているので、臨床診断分析機が遭遇する障害については開示も対応もしていない。
【０００９】
米国特許公開第２００７／０２８８６２９号（「‘６２９号公開」）は、正常運転条件の間は第一のポーリング速度で、ファイアウォールの外側の事業体システムに対しポーリングコールを定期的に送信し、障害状態の検出に応じて、第二のポーリング速度でファイアウォールの外側のデバイスにポーリングコールを送信することにより、ファイアウォールの外側に障害情報を送信することを開示している。第二のポーリング速度は、第一のポーリング速度より高い。この方法には、障害状態が検出されたとき、このポーリングコールで問題報告書を送信することが含まれる。ファイアウォール内からの要請の送信により、ファイアウォール内のデバイスと外部システムとの間に、ファイアウォールを介した双方向接続の開放が可能になる。しかしながら、ファイアウォール内からのポーリングメッセージがない場合には、埋め込みデバイスは、ファイアウォール外のシステムによって発見されることができないままである。
【００１０】
米国特許第６，７５７，７１４号（「‘７１４号特許」）ならびにこれに関連する特許および特許出願は、リモートサーバーへの電子メールを介する、装置のエラー状態の獲得および伝達について開示している。一以上の変数を得て、テンプレートに挿入することによって、電子メールメッセージを生成するのに、予め定められたテンプレートが用いられる。エラー状態は、電子メールメッセージの本文の一部として、または、電子メールメッセージへの添付ファイルの一部として含まれ得る。エラー状態は、エクステンシブル・マークアップ言語（ＸＭＬ）等の自己記述コンピュータ言語を使用して報告される。一般的に、エラー状態は、埋め込みコントローラの助けにより決定される。リモートサーバーは、エラー状態を顧客関係管理システムに渡す。
【００１１】
‘７１４号特許の開示では、リモートサーバーが、埋め込みコントローラに直接アドレスできなくても、リモートサーバーは、電子メールにより、装置に関する情報を得ることができる。電子メールは、たとえば、リモートサーバーが、埋め込みコントローラと同じ内部ネットワーク上にない場合に、情報を提供することができる。さらに、エラー状態が、ＸＭＬを使用して報告されるので、リモートサーバーは、メンテナンスを自動的にスケジュール化し得る。予期し得るように、このようなシステムにおける電子メールは、監視システムによる抽出のための状態情報を含む。‘７１４号特許では、エラー通知が、予め定義されたイベントの検出に限られ、予め定義されたイベント以外のものを検出するように警報をカスタマイズする能力は持たない。
【００１２】
臨床診断分析機を監視するためのもう一つのオプションは、ターゲットの分析機をプログラムし直すためにターゲットの分析機にプログラムを送信することである。ＸＭＬコーディングを用いて遠隔デバイスをプログラムすることは、米国特許第７，１７８，１４９号に記述されている。しかしながら、そのようなプログラミングは、プログラム言語のそれぞれのコマンドが、ＸＭＬのタグと対応させられ、ＸＭＬのオーバーヘッドが追加されて、伝達されるプログラムコードを非常に膨大なものとすることになるため、分析機を監視するタスクの複雑さをかなり増大させる。ターゲットのデバイスでは、ＸＭＬでコード化されたプログラムは、デコードされる必要があり得るだけでなく、潜在的にコンパイルされ、動作される必要もあり得る。このようにして、ターゲットの遠隔デバイスのオーバーヘッドも、かなりより高いものとなる。ＸＭＬ自体は、単に、そのようなインプリメンテーションにおけるテキスト伝達方法であり、プログラムコードを含む電子メールを送ることと少しも異ならない。これらの考慮すべき問題により、このアプローチは臨床診断分析機のカスタマイズされた遠隔監視には不適切となる。
【００１３】
その代わりに、米国特許第６，８９２，３１７号で記述されるような分散システムで、ネットワーク化されたデバイスを監視するための複雑な回路および機能性を実装し得る。しかしながら、これは、ファイアウォールによって保護された別のネットワークにおける臨床診断分析機では動作しない。このようにして、臨床診断分析機のよりよい監視へのニーズがある。
【００１４】
〔概要〕
本明細書に開示された実施形態により、遠隔の臨床診断分析機におけるイベントのカスタマイズ可能な監視システムと監視方法とが提供される。記述された実施形態により、上述の課題が克服される。
【００１５】
手短に言えば、好ましい一実施形態では、（ａ）監視されるイベントを指定し、カスタマイズするために、効率的で柔軟なコーディング戦略が採用され、（ｂ）プライバシーを損なうことなく、警報を報告するための埋め込みデバイスに対して、また、警報を報告するための埋め込みデバイスによって、必要なアクセスを提供するために、臨床診断分析機が二つのネットワークへ統合され、（ｃ）迅速な応答と関連記録データの遠隔伝達との両方を可能にするために、カスタマイズされたイベントの検出に応じて、リアルタイム警報が発生される。
【００１６】
この好ましい実施形態では、一群のカスタマイズされたイベントのうち一以上の検出に応じて、警報が発せられる。カスタマイズされたイベントは、臨床診断分析機について予め定義された基本的イベントを論理的に結合することによって記述される。その結果、たとえば、分析機の、エラー予測、エラー検出および遠隔監視のサービスを改善するためにイベントをカスタマイズすることが可能になる。
【００１７】
警報可能なイベント（alertable event）が検出された場合、そのイベントは記録され、外部モニターにメッセージが返信される。次いで、外部モニターのサーバが、必要に応じてそのメッセージを処理する。
【００１８】
他の一態様では、好ましい実施形態に、臨床診断分析機で発生したリアルタイム警報を外部モニターに伝達するためのモジュールが含まれる。このモジュールには、カスタマイズされたイベントを検出するための、カスタマイズされたイベント検出サブモジュールが含まれる。接続サブモジュールは、外部モニターが安全なネットワーク接続を介して臨床診断分析機にリンクされる、外部モニターへのリンクを提供する。カスタマイズされたイベントは、カスタマイズされたイベントを動的に更新するためのサブモジュールによって更新され得る。データロギング設備は、外部モニターに送信されるか、または外部モニターにより検索されている情報の記録を容易にする。
【００１９】
好ましい一実施形態では、埋め込みモジュールが、二つのネットワークアドレスを持つ。臨床診断分析機は、典型的には、患者のプライバシーを保護するためのファイアウォールおよび他の安全装置の付いた第一のネットワークに置かれる。埋め込みモジュールは、インターネットを通り抜ける(tunnel through)仮想プライベートネットワークリンクを通って、第二のネットワーク中の外部モニターに接続されることが好ましい。外部モニターは、第一のネットワークに対し外部にあり、埋め込みモジュールと第二のネットワークの外部モニターとの間のリンクを完成するために、インターネットは、第一のネットワークを介してアクセスされる。このようにして、埋め込みモジュールは、患者を特定する情報へのアクセスを伴わないかまたは患者を特定する情報へのアクセスを要しない、限定されたタスクを実施するための第二のネットワークの一部であるものとして取り扱われ得る。
【００２０】
第二のネットワークでは、埋め込みモジュールと外部モニターとが、同じサブネット上にある。このサブネットは、臨床診断分析機に関する通信を保護し、隔離するために、第二のネットワークの他の部分からさらに隔離されているのが好ましい。
【００２１】
外部モニターに警報を伝達するために、モジュールがウェブページに掲示を行うことが好ましい。外部モニターは、ファイル転送プロトコル(File Transfer Protocol)等のプロトコル、またはハイパーテキスト転送プロトコル(Hyper Text Transfer Protocol)のＧＥＴコマンドを用いて、臨床診断分析機の記録データにアクセスし得る。通常、埋め込みモジュールは、臨床診断分析機におけるカスタマイズされたイベントを検出するための回路、外部モニターに警報を伝達するための回路、カスタマイズされたイベントを動的に更新するための回路、および、外部モニターに送信される情報、または外部モニターによって検索される情報を記録するための回路を備える。
【００２２】
カスタマイズされたイベントにおける変化を実行するための回路は、変化で指定された少なくとも一つの論理演算が、特定のタグではなく、ＸＭＬタグの順序とコンテキストとでコード化されるように、ＸＭＬでコード化された命令としてその変化を受け取ることが好ましい。
【００２３】
カスタマイズされたイベントが生じると、カスタマイズされたイベントを検出するための回路は、命令を解釈して、カスタマイズされたイベントを識別する。好ましい一実施形態では、基本的イベントを結合するための命令によって指定された論理演算が、特定のタグの代わりに、ＸＭＬのタグの順序とコンテキストとでコード化される。
【００２４】
都合のよいことに、埋め込みモジュールには、外部モニターが、ＶＰＮリンクを用いて直接アドレスし得る。その結果、情報を記録するための回路が実行されて、定期的に、または、モジュールによって検出された、カスタマイズされたイベントの報告に応じて、外部モニターがログファイルに限定的にアクセスできるようになる。この限定的なアクセスにより、分析機の効果的な監視を可能とするのに充分なアクセスが許容される一方、患者のプライバシーが保護される。当業者に明らかなように、この限定的アクセスさえも、直ちに否定され得る。
【００２５】
好ましい一方法は、臨床診断分析機で発生したリアルタイム警報を、外部モニターに伝達するように適切に設計されたモジュールで実施される。この方法は、臨床診断分析機におけるカスタマイズされたイベントを検出するステップ、カスタマイズされたイベントの検出に応じて、外部モニターとリアルタイムで通信するステップであって、外部モニターは安全なネットワーク接続を介して臨床診断分析機にリンクされる、ステップ、外部モニターから受信した命令に応じて、カスタマイズされたイベントを変化させるステップ、および、外部モニターに送信される情報、または外部モニターによって検索される情報を記録するステップを容易にすることを含む。
【００２６】
カスタマイズされたイベントは動的に指定され得る。好ましくは、命令によって指定された少なくとも一つの論理演算が、特定のタグではなくタグの順序とコンテキストとでコード化されるように、外部モニターから受け取られるカスタマイズされたイベントを記述する命令が、ＸＭＬでコード化される。新しく受信した命令が先の命令に取って代わり、それによって、イベントが動的にカスタマイズされる。さらに、カスタマイズされたイベントの検出に応じて、情報が、データログファイルに書き込むことにより記録され、分析機の障害探索およびパフォーマンスの評価に役立つ。
【００２７】
好ましいいくつかの実施形態のこれらの特徴および他の特徴が、後で簡単に説明する図面の助けを借りて以下に詳細に記述される。
【００２８】
〔好ましい実施形態の詳細な説明〕
臨床診断分析機の「基本的イベント」は、典型的には、一以上のパラメータまたはその中の変化の検出である。パラメータは、臨床診断分析機の状態の値または記述子である。一以上の指定された条件が実現すると、イベントが生じる。多数のこのような基本的イベントは、典型的には、臨床診断分析機について前もって定義される。関心の対象である基本的イベントが、エクステンシブル・マークアップ言語（「ＸＭＬ」）タグを使用して記述されることが好ましい。典型的には、種々のコマンドを実行している間、分析機の機能を監視するのにそのような基本的イベントが用いられる。一般的に、臨床診断分析機の多くの基本的イベントまたは全ての基本的イベントに対して、ＸＭＬタグやその他の記述子を定義し得る。
【００２９】
ＸＭＬを使用することには多くの利点がある。ＸＭＬは、イベント（基本的イベントの組合せまたはバリエーションであるものを含む）を定義するのに役立つ。ＸＭＬでコード化された命令および記述は、インタープリターを使用して、リアルタイムで迅速に実行され得、デバッグされ得る。さらに、ＸＭＬベースの定義は、テキストとして扱うことによって、直ちに伝達される。しかしながら、ＸＭＬタグは、人間が読み取ることはできるが、類似したタグ名を使用してまたは同一のタグ名さえ使用して、非常に異なる機能とデータとを記述することがしばしばある。ＸＭＬでコード化された命令および記述は、インタープリターを使用して、リアルタイムで迅速に実行され得、デバッグされ得る。さらに、ＸＭＬベースの定義は、テキストとして扱うことによって、直ちに伝達される。それにも拘わらず、あるコンテキストでは、ＸＭＬが、ＸＭＬに準拠した命令を実行することによって実施される機能の記述を行う。したがって、コンテキストが適切であれば、ＸＭＬは、データ、命令およびこれらの組合せを伝達する便利な方法を提供する。
【００３０】
実際には、ターゲットで（at a target）特定のタスクのセットを容易にするように設計されたＸＭＬの特定の例は、特定の機能を実施することができる「新しい機械」を創造する。このようにして、ＸＭＬでコード化された命令の解釈に応じて、一以上のＸＭＬタグによって指定される機能を実施する回路は、潜在的に、示された機能を実施する新しい構造体である。
【００３１】
好ましい一実施形態では、カスタマイズされたイベントを定義するために、基本的イベントが論理的に結合され得る。たとえば、長い間にわたるイベントの特定の数の発生が、カスタマイズされた関心対象のイベントを形成し得る。この好ましい実施形態では、そのようなカスタマイズされたイベントの検出に応じて、警報が発せられ得る。好ましい一実施形態では、イベントが、一以上の基本的イベントを結合するためのマークアップ言語（例えばＸＭＬ）でコード化された命令によってカスタマイズされる。結合のための少なくとも一つの論理演算が、特定のタグによってではなく、ＸＭＬタグの順序とコンテキストとでコード化されることが有利である。これにより、イベントを効果的に指定するために必要なタグの数が減り、それゆえに、イベントをカスタマイズする複雑さが減少する。
【００３２】
イベントの結合のための少なくとも一つの論理演算が、特定のタグではなく、ＸＭＬタグの順序と、ことによるとそのコンテキストとでコード化されることが有利である。この特徴により、命令の明快さが増し、イベントをカスタマイズするために必要なタグの数が減る。
【００３３】
イベントに基づく警報(Event Based Alert)は、システムに起こっている特定のシナリオを識別するために確立された一組のルールに対して、臨床診断分析機と関連パラメータとを評価する。例えば、これらのシナリオは、障害が起こる前に障害を防止すること（予知保全）を狙うものであり得、サービス提供者（メーカーであり得る）に障害後のシナリオを知らせるために使用されるものでもあり得る。これは、ＸＭＬまたは別の表示システムでコード化された基本的イベントを使用して、イベントをカスタマイズする能力を提供することによって達成される。
【００３４】
あるシナリオの条件が合致したとき、システム上のイベントが記録され、メッセージが、外部モニターサーバに返信される。次いで、外部モニターサーバは、必要に応じてメッセージを発信する（routes）。
【００３５】
イベントに基づく警報は、そのような警報を実行するための好ましいプラットフォームを提供する、ＯＣＤの臨床診断分析機VITROS 5600（商標）およびVITROS 3600（商標）のデザインと互換性を有する。ただし、イベントに基づく警報は、他の臨床診断分析機でも有用である。VITROS 5600（商標）およびVITROS 3600（商標）のそれぞれは、三つの化学作用プラットフォーム：（ｉ）乾式化学作用を用いるMicroSlides（商標）、（ｉｉ）湿式化学作用のためのMicroTips（商標）および、（ｉｉｉ）湿式化学作用を用いるMicroWells（商標）、をサポートし得る、マスタースケジューラー(Master Scheduler)によって提供される機能を用いる。ＯＣＤのマスタースケジューラーは、種々の化学作用プラットフォーム間で共用されるロボットアームおよびロボットピペッター（pipettors）を制御して、入力された患者のサンプルにランダムにアクセスすることもできる。イベントに基づく警報を提供するために、代替のスケジューラーを適切に改変し得ることは明らかである。
【００３６】
ＯＣＤのマスタースケジューラーは、たとえば、必要とされる検査の種類または量に拘わらず、任意の順序で入力されたサンプルに資源を割り当て、分析機のスループットを維持するかまたは改善するために、スケジューリング機能を実施する。ＯＣＤのマスタースケジューラーは、全体として２セットの検査要件を決定し、全体として、検査のための完了時間(Time to Complete)を最小限にするスケジュールを決定し、それによって、高スループットを維持する。
【００３７】
ＯＣＤのマスタースケジューラーは、種々のプラットフォームの間でのロボットアームおよびロボットピペッターの共有を許容することにより、複数の化学作用に基づく検査の実行もサポートして、入力サンプルへのランダムアクセスを提供することによるサンプルのスループットを管理する。入力サンプルからの二次元のランダムサンプリングを許容するために、種々の化学作用を行うプラットフォームが、革新的なサンプルのレイアウトにより、入力サンプルから切り離される。この入力サンプルへの二次元のランダムアクセスにより、サンプルを入力された順序で処理するという典型的な要件が実質的に取り除かれる。
【００３８】
ＯＣＤのマスタースケジューラーの利点には、例えば、複数のセンシオメトリック(sensiometric)デバイス（例えば、電位計、反射率計、ルミネセンス、光透過率、光子検出、サンプルの加熱のためのインキュベータ、試薬の供給および複数の試薬配送サブシステム）と共に、例えば複数のプラットフォーム、薄いフィルムスライドを含む消耗品の供給、反応槽およびキュベットを含む資源へのアクセスを提供しつつ、入力サンプルに二次元でランダムアクセスすることと言う相乗効果が含まれる。これらの全ては直ちにアクセスして利用することができる。
【００３９】
これらのプロセスおよび検査のそれぞれを制御するために、スケジューラーはサブシステムにコマンドを発行する。コマンドが実行されると、種々の測定がなされ、コマンドが、検出されたイベントに基づいてうまく実行されたことを確認するために、応答メッセージがスケジューラーに送り返され、ループが完了する。それにも拘わらず、臨床分析機の操作中のエラーは、高価で好ましくない現実であり続けている。したがって、臨床診断分析機のダウンタイムを減少させるために、エラーを予測するか、好ましくは防止するか、または修正するための種々の戦略を実行するように、分析機の種々の部品間のメッセージトラフィックを監視し得る。
【００４０】
このタスクは、臨床分析機が、プライバシーと秘密性とを保証するセキュリティを要求する患者サンプルを取り扱うという事実によって困難になっている。また、これらの臨床分析機は、通常、メーカーや修理サービスプロバイダーから遠く離れて据え付けられている。
【００４１】
開示された実施形態は、バックオフィスまたはサービスを提供するための指定の場所での、動的な監視ならびに予想的トラブルシューティングおよび遡及的トラブルシューティングを可能にしつつ、患者のプライバシーや分析機のセキュリティを危険にさらすことなく、そのような遠隔の臨床診断分析機の監視を容易にする。
【００４２】
モジュールは、（共用資源を使用することはあり得るが）、論理的に、その機能を実行するのに自己充足型である。資源は、典型的には、プロセッサタイムスライス、データベースデータ、他のモジュールと共有されるメモリ中のデータ、サブモジュール、共用ライブラリー機能、および当業者に周知の類似資源である。モジュールの作成方法は、当技術分野で通常の技量を有する開発者には既知である。実行可能コードへの機能分割のマッピングは、当業者によく知られている。
【００４３】
図１は、好ましい実施形態を例示する。図２は、ある方法における、概ね対応する基本的な制御の流れを例示する。この例示的な好ましい実施形態は、動的にカスタマイズされたイベントに応じてリアルタイムの警報を提供する。カスタマイズされたイベントは、臨床診断分析機で発生する基本的イベントまたは信号の特定の組合せとなるように定義され得る。いくつかの基本的イベントまたは信号が、一以上の論理演算のために別個のタグを必要とすることなく論理的に結合され得るように、カスタマイズされたイベントは、ＸＭＬを用いてコード化される。この好ましい実施形態の一態様では、ＸＭＬ命令の順序付けが適切な論理演算を指定するので、これが可能となる。
【００４４】
この好ましい臨床診断分析機は、実行されるときに、一連のメッセージを発生させるサブプロセス１００を有する。これらのメッセージの多くは、基本的イベントを反映するものである。メッセージは、データロギングスレッド(Datalogging Thread)１０５によって、ログファイルである一以上のデータログファイル(Datalog Files)１１０中に記録される。データログスレッド１０５は、外部モニターに送信されるかまたは外部モニターによって検索される情報を記録するための回路の一例である。
【００４５】
データログスレッド１０５は、イベントキュー(Event Queue)１１５でイベントのキューイングを発生させるか、または促進し得る。このようにキューに入れられたイベントは、警報スレッド(Alert Thread)１２０によって処理される。警報スレッド１２０は、キューに入れられたイベントを処理するために、標準ルールファイル(Standard Rule File)１２５および、利用できるならば、ダウンロードされたルールファイル(Downloaded Rule File)１３０も読み込む。好ましくは、システムパフォーマンスへの影響を減らすために、警報スレッド１２０には、低い優先順位が割り当てられる。警報スレッド１２０には、ルールファイル(Rule File)によって記述されたカスタマイズされたイベントおよびその他のイベントを実際に検出するために必要である、ルールファイルに含まれたイベントを実行するためのメモリバッファ等の資源のセットアップおよびリリースのための命令が含まれる。
【００４６】
警報スレッド１２０の演算の多くの態様は、データロギングスレッド１０５の演算と共に、図２で例示される。警報スレッド１２０は、臨床診断分析機におけるカスタマイズされたイベントを検出するための回路の例を提供する。有利なことに、図２のステップ２３５およびステップ２４０（後述）は、臨床診断分析機におけるカスタマイズされたイベントを検出するための回路により実行される動作のうちのいくつかを記述する。
【００４７】
図２に例示されるように、ステップ２００中にシステムがブートアップし、ステップ２０５中に警報スレッド１２０とデータロギングスレッド１０５とが初期化される。スレッドとしてのこれらのプロセスの実行は、システムパフォーマンス上のペナルティを減らして、インプリメンテーションを堅牢(robust)にするために好ましい。
【００４８】
ステップ２１５中、新しいルールファイルがダウンロードされたかどうかに関する決定がなされる。新しいルールファイルがダウンロードされたならば、制御はステップ２２０に移る。ステップ２２０中に、新しいルールファイルが警報スレッド１２０によってロードされたならば、制御はステップ２２５に移る。ステップ２２５中、標準ルールファイルの代わりに新しいルールファイルが使われ、制御がステップ２３５に移る。あるいは、制御は、ステップ２２０からステップ２４５に移る。ステップ２４５中、エラー状態を外部モニターサーバに伝達するために警報(Alert)にフラグが立てられる。この手順のバリエーションには、ダウンロードされたルールファイルを新しい「標準ルールファイル」としてマークすることが含まれ得る点に留意する必要がある。
【００４９】
他方、ステップ２１５中に新しくダウンロードされたルールファイルが検出されない場合には、標準ルールファイルのロード後、制御はステップ２３５に移る。
【００５０】
ステップ２３５中、警報スレッド１２０は、ロードしたルールファイル中の任意のカスタマイズされたイベントを含むイベントを考慮して、イベントキュー１１５の一以上のイベントを調べる。
【００５１】
好ましい実施形態の説明に戻って、カスタマイズされたイベントを効率的に指定するために使用されるＸＭＬタグおよび構造を例示するために、以下に、例示的なルールファイルが提供される。
【００５２】
上記のイベントでは、基本的イベントが、デバイスにおける熱電流（thermal current）を評価する。イベントをトリガするために、演算（例えば「ＥＱ」および「ＯＵＴＳＩＤＥ」）と共に種々のパラメータが指定される。パラメータが規定された範囲を満たす回数が、パラメータ「thresholdCount」によって指定される。パラメータthresholdIntervalは、パラメータthresholdCountとの関係で重要である。たとえば、６ヵ月の期間における３のカウントは、１分間における３のカウントとは異なって処理され得る。関連持続時間は、パラメータthresholdIntervalによって指定される。下記の例は、規定された範囲のセットを充足する回数が２回以上であることを要求する複合イベントを例示するものである。
【００５３】
好ましい実施形態では、ネストされたタグによって指定された全ての条件が、イベントを指定するために同時に充足される必要のあるRULEタグ内で、RULEタグの全体が、それ自身、イベントを指定するようになっており、有利である。このようにして、RULEタグ内に含まれるタグが論理的にＡＮＤでつながれる（ANDed）一方、ネスティングの同じレベルのRULEタグは、論理的に論理和をとられる（ORed）。これによって、基本的イベントを適切に組み合わせることにより、関心の対象である複雑なイベントを築き上げることができる。このようにして、ルールファイルを変えることができるだけでなく、臨床診断分析機のために予め定義されたイベントや条件を、より複雑なイベントを編成するための構築用ブロックとして使用できる。下記は、複数のカスタマイズされたイベントを、同一のＸＭＬでコード化されたルールファイルで定義する一例である。
【００５４】
パラメータ「ruleName」は、「THRESHOLD eventType」を使用する、臨床診断分析機のために定義された複合イベントを簡便に表す。VITROS 5600（商標）臨床診断分析機およびVITROS 3600（商標）臨床診断分析機は、臨床診断分析機における複数のデバイスとサブシステムとを監視し、操作するための大量のTHRESHOLD eventType記述子をサポートする。
【００５５】
この好ましい実施形態では、タグ「RULE」は、複合イベントを記述する。構成ファイルまたはルールファイル（実質上「ALERTCONFIG」タグで示される）は、６４個のこのような複合イベントに限定される。このようなイベントのそれぞれのために、「THRESHOLD」タグを使用して、最高１０個の閾値を指定し得る。さらに、それぞれのTHRESHOLDタグに対し、「CRITERIA」タグを使用して、５個以下の基準を指定し得る。要約すると、カスタマイズされたイベントを一つのタグが記述する。このタグには、たとえば、「ｍ」の時間単位内に「ｎ」回の値を上回るといった、閾値仕様（threshold specifications）のセット等がネストされる。閾値仕様のそれぞれについて、指定された基準（好ましくはその中にさらにネストされたタグで示される基準）に従って、検出されたパラメータを用いて演算が実行される。直ちに理解されるように、これらは、インプリメンテーションに特定的な詳細であり、異なるインプリメンテーションでは容易に改変し得るものである。
【００５６】
例示の基本的イベントが、下表に記述されている。
【表１】
【００５７】
上表では、熱制御デバイスの電流を監視するのに用いられる基本的イベント「THERMO_DEVICE_CURRENT」が記述されている。この基本的イベントは、数字コード‘２１４をこのイベントに割当てる。さらに、この表に示されているように、このイベントは三つのパラメータ：タイムスタンプ、電流が監視されているデバイスの識別、および電流の値（value of the current）、を受け入れる。上記のＸＭＬ記述に見られるように、デバイス４２に対し、熱電流が監視され、もしそれが６３〜８３の範囲外にあるならば、イベントが認識される。thresholdCountが１にセットされているので、そのようなただ一つの任意の生起が、警報(Alert)をトリガさせるのに十分である。
【００５８】
以下の例示的ルールファイルは、論理的ＡＮＤ演算を使用して、二つの異なるTHRESHOLD eventTypeコード／パラメータに対応する二つの予め定義された基本的イベントを結合する。このＡＮＤ演算は、同じネスティングレベルにある単一のRULEタグ内に両方のTHRESHOLD eventTypeコードを置くことによって暗黙に定義される。
【００５９】
図２に戻って、ステップ２３５中、関心の対象である警報を発生させる必要があるかどうか識別するためにルールファイルで指定されたイベントを警報スレッド１２０が適用する。臨床診断分析機で、イベントの種々の定義が多くの演算で計算され得るように、イベントを追跡し、カウントするためのバッファを提供するための複数の専用メモリ場所が割り当てられることが好ましい。
【００６０】
ステップ２４０中、警報スレッド１２０は、検査済イベントがルールファイルを充足するかどうかを決定する。ルールファイルを充足するイベントがない場合、すなわち、警報の発生に繋がるイベントがない場合、制御はステップ２１５に戻される。あるいは、イベントの検査時にルールファイルが充足された場合、警報スレッド１２０は、ステップ２４５中に、接続マネージャ(Connectivity Manager)１３５に警報(Alert)状態を知らせる。接続マネージャ１３５は、外部モニターと通信するための回路の例を提供するものである。
【００６１】
さらに、ステップ２５０中、警報スレッド１２０が、データロギングスレッド１０５を用いて警報(Alert)状態を記録し、その後、ステップ２５５中に、データログファイルが作成されるかまたは更新される。分析機の監視の続行のために、制御はステップ２５５からステップ２１５へ戻る。
【００６２】
例えば、接続マネージャ１３５によって発生し、送信されるＨＴＴＰポストコマンドによる、警報が、カスタマイズされたイベントに関する有用な関係情報をログファイルが持っていることを外部監視システムに知らせる。次いで、外部監視システムは、さらなるアクション（たとえば、サービスコール（service call）のスケジュール化）のために、これらのログファイルをダウンロードし得る。あるいは、識別されたデータをさらなる分析に掛け得る。外部モニターを収納しているバックオフィスにおける権限のある個人が、ログファイルのダウンロードを開始し得る場合がしばしばある。
【００６３】
図１の接続マネージャ１３５（好ましくは、外部監視システムへのリンクを提供する接続サブモジュールである）は、仮想プライベートネットワークリンクを利用することによってメッセージを送り、外部の中間ネットワーク（例えばインターネット）を安全に横断して、そのメッセージをバックオフィスサーバー(Back Office Server)１４５に届ける。バックオフィスサーバー１４５は、次に、警報またはその他の関連タスクをサービスセンター(Service Centers)１５０に転送し、そこで、データが分析され、対応が取られる。バックオフィスサーバー１４５は、好ましくはデバイスに依拠して、どこにメッセージを送るかを決め、次いで、適切なサービスセンターまたは個人に電子メールを送り得る。
【００６４】
図３は、好ましい埋め込みモジュールのいくつかの態様を例示する。たとえばイベントをカスタマイズするために、ネットワーク３０５のモジュール３００には、メッセージトラフィックとのインタフェース(Interface to Massage Traffic)３１０、イベント検出(Event Detection)のためのサブモジュール３１５、更新処理のための更新サブモジュール（sub-module Updating）３２０が含まれる。モジュール３００には、外部監視システムへのリンク(Link to External Monitoring System)のためのサブモジュール３２５、および、データロガースレッドへの接続(Connection to Datalogger Thread)３３０も含まれる。ネットワーク３０５は、接続３４５を介して外部監視システム(External Monitoring System)３４０を含むネットワーク(Network)３３５に接続される。外部監視システム３４０は、トンネリング(Tunneling)リンク３５０を経て外部監視システムへのリンクのためのサブモジュール３２５に接続される。外部監視システム３４０には、モジュール(Module)３００によってイベントをカスタマイズするためのデータおよび命令のアップロードとダウンロードとを管理するための、ダウンロード／アップロードインタフェースサブモジュール(sub-module Downloading/Uploading Interface)３５５が含まれる。
【００６５】
臨床診断分析機で発生したリアルタイムの警報を伝達するためのモジュール５００が、警報およびデータ通信用回路(Circuit for Communicating Alerts and Data)５２０と通信する、イベント検出用回路(Circuit for detecting an Event)５１０を含むものとして図５に例示されている。警報およびデータ通信用回路５２０は、外部モニター(External monitor)５５０との通信を管理する。警報およびデータ通信用回路５２０は、イベントの動的更新用回路(Circuit for Dynamically Updating Events)５３０と通信して、新しく受け取ったルールファイルに、更新されたイベント定義を提供する。
【００６６】
ルールファイル全体を、全ての警報可能なイベントの定義と共に受け取ることが好ましいが、ルールファイルを補うための更新版を持つことも請求項の範囲内である。この態様は、ステップ４００におけるイベント監視および、新しいイベント定義が存在するかどうかを決定するステップ４０５の決定ステップに制御が移る様子を示す図４で例示される。新しい定義が存在する場合には、ステップ４１０中にイベント定義が更新される。更新は、ルールファイルを置き換えるか、他の手段で定義を単に補うかまたは修正するかによって、なされ得る。イベントの検出については、図示されるように、制御は、ステップ４０５または４１０からステップ４１５に移る。ステップ４２０中、イベントが警報すべきものかどうかを決定するためにイベントが評価される。警報せず（not alert）が発行される場合には、制御はステップ４００へ戻る。そうでない場合は、制御はステップ４２５に移り、ステップ４２５中に外部モニターに警報が伝達され、警報可能なイベントに関する情報が、ステップ４３０中に記録される。
【００６７】
図１に戻って、サービスセンター(Service Centers)１５０は、ルールファイル１２５に取り込まれるべきイベントの代替の定義を提供し得る。これは、将来のイベントフラグ立てのために埋め込みモジュールに送信される。図２のステップ２１５〜２３０には、カスタマイズされたイベントにおける変更を実行するための例示的な回路のさらなる詳細が示されている。一般的に、ルールファイルは、外部的に造られ、一以上の埋め込みモジュールに送信され得る。これは、標準ルールファイルによってカバーされるシナリオ以外のシナリオを識別するためになされ得る。
【００６８】
バックオフィスサーバー１４５は、新しいルールファイルがダウンロードされたことを臨床診断分析機に告げる。これにより、警報スレッド１２０がダウンロードされたルールファイルをロードし、ソフトウェアで標準ルールファイルの代わりにそれが使用される。このファイルのロード障害は、図２（ステップ２２０からステップ２４５への制御の流れ）に示されているように、警報可能なイベントの一つである。
【００６９】
このようにして、ルールファイル構造により、よく知られている、柔軟性がない単一の（またはほんの少数の）閾値ルール（例えば、インキュベータの温度＞３５ならば警報発令）に比べ、より柔軟なルールの作成が可能になる。一般に、好ましい実施形態では、次のようなイベントにフラグを立てることが可能である。
（ｉ） （例えば、電源を落とすこと、ソフトウェアロードといった）発生する特定のイベント、
（ｉｉ） 特定のイベント属性についての条件で生じる特定のイベント｛例えば、システム環境(System Environment)イベントが記録され、周囲温度センサーが＞４０の値を持ち、始動イベントが生起し、適切なシャットダウンフラグが真にセットされていない｝、
（ｉｉｉ） 指定された時間フレーム（例えば６０秒）の範囲内での、上記に指定したようなイベント群の生起、および、
（ｉｖ） （例えば、閾値が１時間で５回を超えるといった）イベントの規定された数の生起。
【００７０】
さらに、図２に例示されていないが、処理のためにイベントをバッファリングするインメモリのイベントキューがその最大サイズに達すると、接続マネージャ１３５を介してバックオフィスサーバー１４５に警報(Alert)メッセージが送られ、バックオフィスサーバー１４５にイベントを処理する能力が、一時的になくなったことが告げられる。
【００７１】
警報スレッド１２０には、特定の時間枠（たとえば、ルールが別様に設定されていなければ３０分間）内で、同一のイベントを複数回再トリガすることからの防護が組み込まれていることが好ましい。これは、何千もの警報を下流へ押し流し得るカスケード効果を防止するものである。
【００７２】
言及したように、最新のログファイルを検索するよう外部モニターに命ずるように、ルールを構成し得る。条件がさらなるデータ分析を認可する（warrant）予定である場合に、この要請がメッセージに加えて送信され、役に立つ。
【００７３】
好ましい一実施形態では、例えば、セキュリティ違反が検出される場合に、または、疑われる場合にさえ、オペレーターが、リアルタイム警報メッセージをオフにして、制御可能に埋め込みモジュールを隔離するのを許容することにより、セキュリティとプライバシーとが強化される。
【００７４】
当業者ならば、上記の開示について、その教示内容または精神から逸脱することなく、多くのバリエーションおよび代替的インプリメンテーションが許容されることを認識するであろう。添付の請求項の範囲には、そのような変更が含まれる。さらに、本明細書で議論され、引用されたそれぞれの引用文献は、これにより、その全体が、参照により本明細書に取り入れられる。
【図面の簡単な説明】
【００７５】
【図１】遠隔の臨床診断分析機のための、処理モジュールと、外部モニターへの接続性と、の概略図である。
【図２】好ましい実施形態における、カスタマイズされたリアルタイム警報を発生させる際の、いくらかの顕著なステップを例示する図である。
【図３】遠隔の臨床診断分析機のための、処理モジュールと、外部モニターへの接続性と、の概略図である。
【図４】好ましい実施形態における、カスタマイズされたリアルタイム警報を発生させる際の、いくらかの顕著なステップを例示する図である。
【図５】遠隔の臨床診断分析機のための、処理モジュールと、外部モニターへの接続性と、の概略図である。
【特許請求の範囲】
【請求項１】
臨床診断分析機におけるカスタマイズ可能なリアルタイムの警報を外部モニターに伝達するためのモジュールにおいて、
第一のイベントを含むカスタマイズされたイベントの検出サブモジュールと、
前記外部モニターへのリンクを提供する接続サブモジュールであって、安全な接続を介して前記臨床診断分析機にリンクされる前記外部モニターが、前記第一のイベントの検出に応じて警報を受信する、接続サブモジュールと、
検出さるべきカスタマイズされたイベントを、第二のイベントを含むように動的に更新するためのサブモジュールと、
前記外部モニターに送信される情報、または前記外部モニターによって検索される情報を記録するためのデータロギング設備と、
を備える、モジュール。
【請求項２】
請求項１に記載のモジュールにおいて、
前記第二のイベントを定義する命令が、（ａ）カスタマイズされたイベントを動的に修正する、（ｂ）新しいイベントを加える、および（ｃ）カスタマイズされたイベントを加える、のうちの少なくとも一つを実行するように、マークアップ言語でコード化された命令を介して伝達される、モジュール。
【請求項３】
請求項２に記載のモジュールにおいて、
前記マークアップ言語が、エクステンシブル・マークアップ言語（ＸＭＬ）である、モジュール。
【請求項４】
請求項３に記載のモジュールにおいて、
少なくとも一つの論理演算が、前記エクステンシブル・マークアップ言語のタグの順序でコード化される、モジュール。
【請求項５】
請求項３に記載のモジュールにおいて、
前記第二のイベントが、二つ以上の基本的イベントの論理結合によって定義された、カスタマイズされたイベントである、モジュール。
【請求項６】
請求項２に記載のモジュールにおいて
前記モジュールが、少なくとも二つのネットワークアドレスを持ち、第一のネットワークの一つのアドレスが、第二のネットワークの第二のアドレスと異なっており、
臨床診断分析機が、前記第二のネットワーク中にネットワーク化されており、前記外部モニターが、前記第二のネットワーク中にある、モジュール。
【請求項７】
請求項６に記載のモジュールにおいて、
前記モジュールが、仮想プライベートネットワークリンクを介して前記外部モニターに接続されている、モジュール。
【請求項８】
請求項７に記載のモジュールにおいて、
メッセージトラフィックへアクセスするサブモジュールが、前記臨床診断分析機上の、患者を特定するデータにアクセスしない、モジュール。
【請求項９】
請求項７に記載のモジュールにおいて、
前記モジュールが、前記第一のネットワークのサブネットの一部として、前記外部モニターにより、アドレス指定可能であり、
前記サブネットが、前記第一のネットワーク中のもう一つのサブネットからファイアウォールによって保護されている、モジュール。
【請求項１０】
臨床診断分析機で発生されるリアルタイムの警報を外部モニターに伝達するためのモジュールにおいて、
前記臨床診断分析機におけるカスタマイズされたイベントを検出するための回路と、
前記外部モニターに警報を伝達するための回路と、
カスタマイズされたイベントを動的に更新するための回路と、
前記外部モニターに送信されるべき情報、または前記外部モニターによって検索されるべき情報を記録するための回路と、
を備える、モジュール。
【請求項１１】
請求項１０に記載のモジュールにおいて、
カスタマイズされたイベントを動的に更新するための前記回路が、前記外部モニターに警報を伝達するための前記回路から、第二のイベントの仕様を、エクステンシブル・マークアップ言語でコード化された命令として受け取り、
警報を伝達するための前記回路が、カスタマイズされたイベントを更新する命令も受信する、モジュール。
【請求項１２】
請求項１１に記載のモジュールにおいて、
前記命令で指定された少なくとも一つの論理演算が、前記エクステンシブル・マークアップ言語のタグの順序でコード化される、モジュール。
【請求項１３】
請求項１０に記載のモジュールにおいて、
前記モジュールが、第一のネットワークに少なくとも一つのアドレスと、第二のネットワークに一つのアドレスとを有し、前記第一のネットワークが、前記第二のネットワークとは異なる、モジュール。
【請求項１４】
請求項１３に記載のモジュールにおいて、
カスタマイズされたイベントを動的に更新するための前記回路が、カスタマイズされたイベントを検出するための前記回路に、カスタマイズされた更新イベントを検出させる、モジュール。
【請求項１５】
請求項１２に記載のモジュールにおいて、
前記外部モニターに前記警報を伝達するための前記回路が、前記モジュールと前記外部モニターとの間のリンクを定めるトンネルを使用する、モジュール。
【請求項１６】
請求項１２に記載のモジュールにおいて、
外部モニターの情報を記録するための前記回路が、カスタマイズされたイベントの検出に応じてログファイルを更新する、モジュール。
【請求項１７】
臨床診断分析機で発生したリアルタイムの警報を外部モニターに伝達するためのモジュールで実施される方法において、
前記臨床診断分析機におけるカスタマイズされたイベントを検出するステップ、
前記カスタマイズされたイベントの検出に応じて、警報を前記外部モニターへリアルタイムで伝達するステップであって、前記外部モニターが、安全なネットワーク接続を介して前記臨床診断分析機にリンクされる、ステップ、
前記外部モニターから受信した命令に応じて、第二のイベントを含むように、カスタマイズされたイベントを更新するステップ、および、
前記外部モニターに送信されるべき情報、または前記外部モニターによって検索されるべき情報を記録するステップ、
を容易にすること、
を含む、方法。
【請求項１８】
請求項１７に記載の方法において、
前記臨床診断分析機は、第一のネットワークに少なくとも一つのアドレスを持ち、第二のネットワークにもう一つのアドレスを持つ、方法。
【請求項１９】
請求項１７に記載の方法において、
情報を記録することが、前記検出された、カスタマイズされたイベントに関する条件を、ログファイルに書き込むことを含む、方法。
【請求項２０】
請求項１７に記載の方法において、
前記第二のイベントを記述する前記命令が、前記命令によって指定された少なくとも一つの論理演算がエクステンシブル・マークアップ言語におけるタグの順序でコード化されるように、前記エクステンシブル・マークアップ言語でコード化される、方法。
【請求項２１】
請求項２０に記載の方法において、
前記カスタマイズされたイベントを識別するネストされたタグ、前記複合イベントを定義するのに用いられる閾値、および検出されたパラメータを使用して実行される論理演算を記述する一組の基準を使用して、前記カスタマイズされたイベントを記述するステップ、
をさらに含む、方法。
【請求項１】
臨床診断分析機におけるカスタマイズ可能なリアルタイムの警報を外部モニターに伝達するためのモジュールにおいて、
第一のイベントを含むカスタマイズされたイベントの検出サブモジュールと、
前記外部モニターへのリンクを提供する接続サブモジュールであって、安全な接続を介して前記臨床診断分析機にリンクされる前記外部モニターが、前記第一のイベントの検出に応じて警報を受信する、接続サブモジュールと、
検出さるべきカスタマイズされたイベントを、第二のイベントを含むように動的に更新するためのサブモジュールと、
前記外部モニターに送信される情報、または前記外部モニターによって検索される情報を記録するためのデータロギング設備と、
を備える、モジュール。
【請求項２】
請求項１に記載のモジュールにおいて、
前記第二のイベントを定義する命令が、（ａ）カスタマイズされたイベントを動的に修正する、（ｂ）新しいイベントを加える、および（ｃ）カスタマイズされたイベントを加える、のうちの少なくとも一つを実行するように、マークアップ言語でコード化された命令を介して伝達される、モジュール。
【請求項３】
請求項２に記載のモジュールにおいて、
前記マークアップ言語が、エクステンシブル・マークアップ言語（ＸＭＬ）である、モジュール。
【請求項４】
請求項３に記載のモジュールにおいて、
少なくとも一つの論理演算が、前記エクステンシブル・マークアップ言語のタグの順序でコード化される、モジュール。
【請求項５】
請求項３に記載のモジュールにおいて、
前記第二のイベントが、二つ以上の基本的イベントの論理結合によって定義された、カスタマイズされたイベントである、モジュール。
【請求項６】
請求項２に記載のモジュールにおいて
前記モジュールが、少なくとも二つのネットワークアドレスを持ち、第一のネットワークの一つのアドレスが、第二のネットワークの第二のアドレスと異なっており、
臨床診断分析機が、前記第二のネットワーク中にネットワーク化されており、前記外部モニターが、前記第二のネットワーク中にある、モジュール。
【請求項７】
請求項６に記載のモジュールにおいて、
前記モジュールが、仮想プライベートネットワークリンクを介して前記外部モニターに接続されている、モジュール。
【請求項８】
請求項７に記載のモジュールにおいて、
メッセージトラフィックへアクセスするサブモジュールが、前記臨床診断分析機上の、患者を特定するデータにアクセスしない、モジュール。
【請求項９】
請求項７に記載のモジュールにおいて、
前記モジュールが、前記第一のネットワークのサブネットの一部として、前記外部モニターにより、アドレス指定可能であり、
前記サブネットが、前記第一のネットワーク中のもう一つのサブネットからファイアウォールによって保護されている、モジュール。
【請求項１０】
臨床診断分析機で発生されるリアルタイムの警報を外部モニターに伝達するためのモジュールにおいて、
前記臨床診断分析機におけるカスタマイズされたイベントを検出するための回路と、
前記外部モニターに警報を伝達するための回路と、
カスタマイズされたイベントを動的に更新するための回路と、
前記外部モニターに送信されるべき情報、または前記外部モニターによって検索されるべき情報を記録するための回路と、
を備える、モジュール。
【請求項１１】
請求項１０に記載のモジュールにおいて、
カスタマイズされたイベントを動的に更新するための前記回路が、前記外部モニターに警報を伝達するための前記回路から、第二のイベントの仕様を、エクステンシブル・マークアップ言語でコード化された命令として受け取り、
警報を伝達するための前記回路が、カスタマイズされたイベントを更新する命令も受信する、モジュール。
【請求項１２】
請求項１１に記載のモジュールにおいて、
前記命令で指定された少なくとも一つの論理演算が、前記エクステンシブル・マークアップ言語のタグの順序でコード化される、モジュール。
【請求項１３】
請求項１０に記載のモジュールにおいて、
前記モジュールが、第一のネットワークに少なくとも一つのアドレスと、第二のネットワークに一つのアドレスとを有し、前記第一のネットワークが、前記第二のネットワークとは異なる、モジュール。
【請求項１４】
請求項１３に記載のモジュールにおいて、
カスタマイズされたイベントを動的に更新するための前記回路が、カスタマイズされたイベントを検出するための前記回路に、カスタマイズされた更新イベントを検出させる、モジュール。
【請求項１５】
請求項１２に記載のモジュールにおいて、
前記外部モニターに前記警報を伝達するための前記回路が、前記モジュールと前記外部モニターとの間のリンクを定めるトンネルを使用する、モジュール。
【請求項１６】
請求項１２に記載のモジュールにおいて、
外部モニターの情報を記録するための前記回路が、カスタマイズされたイベントの検出に応じてログファイルを更新する、モジュール。
【請求項１７】
臨床診断分析機で発生したリアルタイムの警報を外部モニターに伝達するためのモジュールで実施される方法において、
前記臨床診断分析機におけるカスタマイズされたイベントを検出するステップ、
前記カスタマイズされたイベントの検出に応じて、警報を前記外部モニターへリアルタイムで伝達するステップであって、前記外部モニターが、安全なネットワーク接続を介して前記臨床診断分析機にリンクされる、ステップ、
前記外部モニターから受信した命令に応じて、第二のイベントを含むように、カスタマイズされたイベントを更新するステップ、および、
前記外部モニターに送信されるべき情報、または前記外部モニターによって検索されるべき情報を記録するステップ、
を容易にすること、
を含む、方法。
【請求項１８】
請求項１７に記載の方法において、
前記臨床診断分析機は、第一のネットワークに少なくとも一つのアドレスを持ち、第二のネットワークにもう一つのアドレスを持つ、方法。
【請求項１９】
請求項１７に記載の方法において、
情報を記録することが、前記検出された、カスタマイズされたイベントに関する条件を、ログファイルに書き込むことを含む、方法。
【請求項２０】
請求項１７に記載の方法において、
前記第二のイベントを記述する前記命令が、前記命令によって指定された少なくとも一つの論理演算がエクステンシブル・マークアップ言語におけるタグの順序でコード化されるように、前記エクステンシブル・マークアップ言語でコード化される、方法。
【請求項２１】
請求項２０に記載の方法において、
前記カスタマイズされたイベントを識別するネストされたタグ、前記複合イベントを定義するのに用いられる閾値、および検出されたパラメータを使用して実行される論理演算を記述する一組の基準を使用して、前記カスタマイズされたイベントを記述するステップ、
をさらに含む、方法。
【図１】
【図２】
【図３】
【図４】
【図５】
【図２】
【図３】
【図４】
【図５】
【公開番号】特開２０１０−１５５６４（Ｐ２０１０−１５５６４Ａ）
【公開日】平成２２年１月２１日（２０１０．１．２１）
【国際特許分類】
【外国語出願】
【出願番号】特願２００９−１５４６８５（Ｐ２００９−１５４６８５）
【出願日】平成２１年６月３０日（２００９．６．３０）
【出願人】（５００１７４６２７）オーソ・クリニカル・ダイアグノスティックス・インコーポレーテッド (5)
【Ｆターム（参考）】
【公開日】平成２２年１月２１日（２０１０．１．２１）
【国際特許分類】
【出願番号】特願２００９−１５４６８５（Ｐ２００９−１５４６８５）
【出願日】平成２１年６月３０日（２００９．６．３０）
【出願人】（５００１７４６２７）オーソ・クリニカル・ダイアグノスティックス・インコーポレーテッド (5)
【Ｆターム（参考）】
[ Back to top ]