臨床診断分析機の冗長エラー検出
【課題】臨床診断分析機における疑わしい試験結果を検出するための、臨床診断分析機のプロセッサで実行可能なモジュールを提供する。
【解決手段】検査データベースと構成ファイルを用いて、実際のパラメータを、それぞれの検査について生成されたフィンガープリントに対して比較することによって、あり得るエラーまたは疑わしい結果がないか内部メッセージトラフィックを更に調べるために、冗長エラー検出能力を採用する、臨床診断分析機を開示する。このテストは、テストされるソフトウェアモジュールからの入力に依存せず、それゆえに、独立したテストである。更に、冗長エラー検出(Redundant Error Detection, 「RED」)能力自体をテストするためのテストメカニズムが提供される。
【解決手段】検査データベースと構成ファイルを用いて、実際のパラメータを、それぞれの検査について生成されたフィンガープリントに対して比較することによって、あり得るエラーまたは疑わしい結果がないか内部メッセージトラフィックを更に調べるために、冗長エラー検出能力を採用する、臨床診断分析機を開示する。このテストは、テストされるソフトウェアモジュールからの入力に依存せず、それゆえに、独立したテストである。更に、冗長エラー検出(Redundant Error Detection, 「RED」)能力自体をテストするためのテストメカニズムが提供される。
【発明の詳細な説明】
【開示の内容】
【０００１】
〔背景〕
臨床分析機システムにおける検査パフォーマンスの低下の補修または修正は、電気的または機械的問題を修正することに比べより困難であることが判明してきた。臨床試験テストシステムおよび診断システムの予想されるパフォーマンスの推定および実際のパフォーマンスの監視は、詳細な最新の情報を必要とする。臨床診断システムの設計と製造には、高スループットを維持しつつ、正確な検査を行うために、何千もの構成要素とサブシステムとを複雑なソフトウェアの調整組合せでテストし統合することが必要とされる。Raritan、ニュージャージー州のOrtho Clinical Diagnostics ("ＯＣＤ")によって製造されたVITROS 4,3（商標）およびECi系列の臨床診断分析機が、その例である。
【０００２】
臨床診断分析機には、その操作を監視し、制御する大規模なソフトウェアが含まれる。分析機のすべてのあり得る状態をテストし検討することは、分析機の予想される寿命と用途とに関し、ソフトウェアとハードウェアとの組合せについてあり得る状態の数の大きさを考慮すると、可能ではないことがしばしばである。臨床診断分析機のソフトウェアのテストは、高価で、時間が掛かり、困難である。たとえば、分析機のサブシステムが故障した場合、分析機は縮小され、休止状態と宣言され、使用前に再スタートし、初期化される必要がある。たとえば、インキュベーションチャンバーのカバーの予想外の開口のために生成した非同期メッセージは、その影響を受けた反復試験を、潜在的に不正に変更されたものとして取り扱う必要があるであろう。さらに、エラーコンディションからの回復は、制限の超過、ステップの失敗、および、その他の多くの検出されていないエラーにより、多くの他のテストに影響を与え得る。エラーは、また、更なるエラーを生じさせ、多くの他のテストを通じて波及し得る。さらに、異なるテストが異なる程度に影響を受け得るので、このようなエラーまたはその影響が、臨床診断分析機の操作を制御、調整するルーチンのプロセスでは、適時に検出されない場合がある。この代替法では、しばしば、処理の種々の段階における価値ある患者サンプルを放棄し、装置の全体を再スタートすることになり、これにより、スループットと効率とが減少する。
【０００３】
臨床診断分析機の設計における目標のうちの一つは、誤った結果に基づく処置またはその処置の欠如によって患者に与え得る危害を考慮して、疑わしい試験結果のリリースを防止することである。このようにして、タイムリーなエラー検出は、臨床診断分析機にとってかなり重要である。特に、検査結果の信頼性を改善しつつ、検査コストを低減するためには、健康と安全性のガイドラインを充足するためだけの検査と装置のパフォーマンスを確実なものにする以上のことをすることが好ましい。同時に、基準の含めすぎ(over-inclusive criterion)により正当な結果を放棄しないことが必須である。
【０００４】
試験室は、誤った結果やさらには潜在的に誤った結果さえリリースされるのを防止することを助けるために、広範囲にわたる技術を使用する。これらには、検査管理図、器材メンテナンスプロセス／記録、定期的な分析機のメンテナンス、特定の検査についての患者の通常のパフォーマンスとの比較、患者の最後の結果からの変化のレビュー、生理的に安定した量を計算するための結果のグループ化が含まれるが、これらに限定されるわけではない。これらのアプローチの全ては、結果がリリースされた後にパフォーマンスの問題に反応するように設計されている。一般的に、結果をリリースすることは、結果を提供することだけではなく、結果の信頼性を示すことも意味する。多くのチェックが、一日に一回程度の少ない頻度で実施され、長期の傾向または頻繁な異常値または非常に大きなパフォーマンスの低下の検出にのみ適している。このことは、これらの方法を使用して検出される前に、何時間も、さらには何日もの間さえ、低下したパフォーマンスの検査データをリリースするリスクに試験所と患者とを曝すことになる。このことは、忙しい試験所では、何百もの患者サンプルが再試験され、試験所のスループットが減少する一方、所望のものではない治療をするというリスクを高めることになり得る。
【０００５】
臨床診断分析機は、他の複合システムと同様、スケジューラライクのコントローラ、コマンドを含むメッセージトラフィックを使用する制御サブシステム、応答と非同期メッセージ、割り込み等を含んでいる。典型的には、スケジューラ（通常、ソフトウェアモジュールとして実行される）は、資源を割り当て、所望のテストをスケジュール化し、種々のコマンドのパフォーマンスを追跡することによって、臨床診断分析機の操作を制御する。スケジューラは、種々のサブシステムにコマンドを発行し、これらのサブシステムは、コマンドの実行結果を示す応答を返信する。これらのサブシステムは、今度は、スケジューラからのコマンドの受け取りに応じて、他のソフトウェアモジュールに一以上のコマンドを送信し、対応するコマンドの実行結果を示すメッセージをそれらから受け取り得る。
【０００６】
全てのサブシステムコマンド、コマンド応答および非同期メッセージは、サブシステム入出力であると考えることができる。サブシステムマネージャであるソフトウェアモジュールは、エミュレータファイルにこれらのメッセージを書き込む。エミュレータファイルは、膨大なものであるが、トラブルシューティング中にレビューし得る。しかしながら、このタスクは、遅くなりがちであり、過度に結果のリリースを遅延させることなく、疑わしい結果にフラッグを立て、疑わしい結果のリリースを防止するには非実用的である。とりわけ、臨床診断分析機は、典型的には、促進処理を必要とするＳＴＡＴサンプルのテストをサポートする。臨床診断分析機を取り扱うにはやはり適切でない複合システムのパフォーマンスを追跡し、推定する若干の更なる戦略について次に記述する。
【０００７】
米国特許第７，２５４，６０１号（「’６０１特許」）は、遠隔地に配備されたインテリジェント装置を管理する方法を開示しているが、疑わしい試験結果のリリースのタイムリーな防止については教示していない。
【０００８】
米国特許第６，７５７，７１４号（「’７１４特許」）ならびにこれに関連する特許および特許出願は、リモートサーバーへの電子メールを介する、装置のエラーコンディションの獲得と伝達について開示している。一以上の変数を得て、それらをテンプレートに挿入することにより、電子メールメッセージを生成するのに、予め定義されたテンプレートが用いられる。エラーコンディションは、電子メールメッセージの本文の一部として、または、電子メールメッセージへの添付物の一部として含まれ得る。エラーコンディションは、eXtensible Markup Language(ＸＭＬ)等の自己記述コンピュータ言語を使用して報告される。一般的に、エラーコンディションは、組み込みコントローラの助けにより決定される。リモートサーバーは、エラーコンディションを顧客関係管理システムに渡す。’７１４特許は、機械が、予想外のスケジューラまたはソフトウェアエラーに起因する疑わしい結果をリリースするのを妨げることによって、誤った結果のリリースを防止する問題には対応していない。
【０００９】
高いパフォーマンスを確実なものにするために、臨床診断分析機のあり得るあらゆる状態を網羅的にレビューし、テストするようなニーズを減らすことが必要である。それどころか、試験所からリリースされる結果の信頼性を確実なものにするために、より良いエラー検出戦略が必要である。
【００１０】
〔概要〕
好ましい一実施形態によれば、疑わしい試験テスト結果のリリースを防止するために、エラーを検出しまたは予測するシステムと方法とが提供される。手短かに言えば、この好ましい実施形態では、検査データベースと構成ファイルまたは構成仕様を用いて、実際のパラメータを、それぞれの検査について生成された予想されるフィンガープリントに対して比較することによって、あり得るエラーまたは疑わしい結果がないかメッセージトラフィックを更に調べるために、冗長エラー検出能力を採用する。このテストは、テストされるソフトウェアモジュールからの入力に依存せず、それゆえに、独立したテストである。たとえば、スケジューラソフトウェアの実施が予想外のやり方である場合、そのようなエラーや問題によって影響を受けた結果がリリースされる前に、そのようなエラーにフラッグを立てる独立した方法があることが好ましい。更に、冗長エラー検出(Redundant Error Detection, 「RED」)能力自体をテストするためのテストメカニズムが提供される。
【００１１】
フィンガープリントは、（ｉ）それぞれの検査について、プロトコル情報を提供することができる検査データベース、および、（ｉｉ）検査、反復試験または関心の対象であるデバイスについての構成ファイルの形態でハードコード化された情報からダイナミックに生成されるのが好ましい。フィンガープリントは、問題のテストの成功裏の完了のために必要な予期されるイベントの集合である。同時に、一つのフィンガープリント中のイベントの数は、一般的に、そのテストのために実際に実行されるイベントの網羅的な列挙数より少ない。フィンガープリントを生み出すプロトコルデータベース中のイベントの数の減少は、構成仕様がそのガイドになる。構成仕様が検査データベースからの情報に併合されて、予想されるフィンガープリントが生成されることが好ましい。
【００１２】
生成したフィンガープリントを用いて、ＲＥＤは、メッセージトラフィックをレビューし、メッセージトラフィックにはない、フィンガープリントによって要求されるイベントの形態の相違点を識別し、疑わしい結果にフラッグを立てる。ＲＥＤは、エミュレータファイルまたはデータロギングファイルをレビューしてメッセージデータにアクセスし、結果が処理された後、相違点を識別することもできる。この能力は、ＲＥＤ自体のより新しいバージョンを検証することを含むソフトウェアを、経済的な方法で検証およびテストするのに有用である。
【００１３】
他の一態様では、ＲＥＤは、ほとんど修正を要せず、サブシステム入出力トラフィックの大部分を不変のままにするため、既存の分析機に容易に一体化される。
【００１４】
好ましい一実施形態には、臨床診断分析機における疑わしい試験結果を検出するための、臨床診断分析機のプロセッサで実行可能なモジュールが含まれる。このモジュールには、サブシステムコマンド、コマンド応答および非同期メッセージを含むメッセージのコピーを受け取るためのメカニズムが含まれる。このモジュールには、反復試験でテストされる予想イベントのフィンガープリントも含まれる。フィンガープリントは、少なくとも構成ファイルと、反復試験に必要な検査に関する詳細を含む検査データベースとから、反復試験プレビューコマンドに応じて生成される。このモジュールには、反復試験チェックコマンドに応じて、受け取りメッセージとフィンガープリントとの間の比較を完了するための命令が含まれる。このモジュールは、比較の結果を報告するための命令を含み、また、反復試験の完了コマンドの受け取りに応じて、反復試験の冗長検査(redundant checking)のために必要な資源をリリースする。
【００１５】
この好ましい実施形態では、ＲＥＤの機能は、オペレータが、容易にダイナミックにオフにし得る。このことは、ＲＥＤにおけるエラーが疑われる場合には有用であり得る。失敗または疑わしい結果が発見される場合は、ＲＥＤ機能が、対応するコンディションの記録を付ける。そのような記録付けにより、発見されたコンディションがオペレータに知らされる。これは、ソフトウェアをデバッグして、改善する上で有用である。しかしながら、ＲＥＤ自体の疑わしい問題が解決されるまで、結果をリリースしないという決定は、オフにされ得る。
【００１６】
本開示には、臨床診断分析機におけるソフトウェアモジュールをテストする方法が含まれる。この方法には、冗長エラーディテクタへの引き渡しに適した、サブシステムコマンド、コマンド応答および非同期メッセージを生成するステップが含まれる。冗長エラーディテクタは、不一致点について、生成したサブシステムコマンド、コマンド応答および非同期メッセージをレビューする。そのような不一致点が識別された場合には、ソフトウェアモジュールが、信頼できかつ一貫性のあるパフォーマンスを確実なものにするためにデバッグされる。特に、テストされるソフトウェアモジュールは、冗長エラーディテクタソフトウェアであり得る。さらに、ソフトウェアモジュールを含むシステムの一部または全体が、このようなやり方でテストされ得る。
【００１７】
サブシステムコマンド、コマンド応答および非同期メッセージは、分析機の一以上前の実行記録を含んでいるスクリプトファイルから生成されるのが有利である。ついで、冗長エラーディテクタを用いて、フィンガープリントで要求される任意のイベントにおける不一致点を検出するために、別のバージョンのソフトウェアを用いる臨床診断分析機のパフォーマンスを比較し得る。スクリプトファイルには、臨床診断分析機の例示的操作からのデータに加え、コマンドが含まれ得る。
【００１８】
他の一態様では、好ましい一実施形態には、臨床診断分析機による疑わしい結果のリリースを防止するための方法がある。この方法には、反復試験のための反復試験プレビューコマンドを受け取るステップ、反復試験についての冗長エラー検査のための資源を割り当てるステップ、少なくとも一つの構成ファイルと検査データベース（ここで、フィンガープリントは、反復試験(replicate)のために検査データベースから生成され得るイベントより少ない数のイベントを有する）とを用いて、反復試験のために必要なイベントのフィンガープリントを生成するステップ、反復試験処理に対応するメッセージをフィンガープリントと比較するステップ、比較の結果を送信し、臨床診断分析機による反復試験に対応する結果のリリースを防止するステップ、および、反復試験に対応するコンディションの記録を付けるステップ、を容易にすることが含まれる。冗長エラー検査のために必要な資源の割り当てとリリースとは、明示的なものである必要はなく、その代わりに、システムまたは基礎となっているプログラミング言語に応じて、自動的に、オペレーティングシステム等の機能によって取り扱われ得る点に留意する必要がある。インプリメンテーションの柔軟性のために、構成ファイルが、人が読むことができ、遠隔地の分析機にテキストとして容易に送信できるeXtensible Markup Languageでコード化されるのが有利である。
【００１９】
好ましいいくつかの実施形態における種々の特徴を、例示図面の助けを借りて、以下に、より詳細に記述する。好ましいいくつかの実施形態における種々の特徴は、例示図面および、モジュールまたはサブモジュールの助けを借りて、以下に、より詳細に記述される。好ましい実施形態では、モジュール（およびサブモジュール）は機能的区分を反映するものである。モジュールまたはサブモジュールは、その機能を実行するために、共用資源を使用し得る。資源は、典型的には、当業者に周知の、プロセッサタイムスライス、データベースデータ、他のモジュールと共有されるメモリ中のデータ、サブモジュール、共用ライブラリー関数等である。モジュールを作成する方法は、当業者である開発者に知られている。機能的区分を実行可能コードにマッピングすることは、当業者によく知られている。図面については次に簡単に記述する。
【００２０】
〔好ましい実施形態の詳細な説明〕
臨床診断分析機の「基本的イベント」は、典型的には、一以上のパラメータまたはその中の変化の検出である。パラメータは、臨床診断分析機の状態の値または記述子である。イベントは、一以上の指定されたコンディションの遂行で生じる。多数のそのような基本的イベントは、典型的には、臨床診断分析機に対し前もって定義される。コマンド、応答および非同期メッセージを含むメッセージトラフィックは、関心の対象であるイベントのサブセットの例である。
【００２１】
ソフトウェア機能である冗長エラーディテクタ（「ＲＥＤ」）モジュールは、分析機または他の高度な処理システムを操作する過程における、予想イベントの繋がりと実際に観察されたイベントの繋がりとの間の相違点を検出する。全てのイベントの網羅的な重複レビューを避けるために、それぞれのテストタイプの実行についてフィンガープリントを提供するための予想イベントの繋がりが策定される。ＲＥＤは、ソフトウェアの検証のみならず、実行された反復試験の回帰テストも提供する。このコンテキストにおいて、イベントとは、一以上のパラメータまたはその中の変化の検出を示すものである。イベントのいくつかの例には、コマンドの発行または受け取り、測定の実施、コマンドの実行を確認するための応答の発行または受け取り、割り込み等が含まれる。
【００２２】
ＲＥＤは、ＯＣＤの臨床診断分析機VITROS 5600（商標）およびVITROS 3600（商標）との互換性を有する。これらは、ＲＥＤを実行するための好ましいプラットフォームを提供する。ＲＥＤは、他の臨床診断分析機にとっても有用であることが期待される。VITROS 5600（商標）とVITROS 3600（商標）とのそれぞれは、複数の相異なるタイプの化学作用プラットフォームをサポートし得る、マスタースケジューラ(Master Scheduler)によって提供される機能を用いる。ＯＣＤのマスタースケジューラは、これら種々のプラットフォーム間で共用されるロボットアームおよびロボットピペッターを制御して、入力された患者のサンプルにランダムにアクセスすることもできる。これはスループットの改善になる。入力サンプルへのランダムアクセスは、サンプルを入力の順に処理するという典型的な要請を実質的に除外するものである。
【００２３】
ＯＣＤのマスタースケジューラは、たとえば、入力されたサンプルに任意の順序で資源を割り当てるための、スケジューリング機能を実施する。これほど多様ではない他のスケジューラも、ＲＥＤ機能の追加による利益を享受する。ＯＣＤのマスタースケジューラは、適用可能なプロトコルの制限を遵守する一方、テストのための完了時間(Time to Complete)を全体として最小にするようスケジュールを決定し、これによって、高スループットを維持する。
【００２４】
ＯＣＤのマスタースケジューラの利点には、例えば、複数のセンシオメトリック(sensiometric)デバイス（例えば、電位計、反射率計、ルミネセンス、光透過率、光子検出、サンプルの加熱のためのインキュベータ、試薬の供給および複数の試薬配送サブシステム）と共に、複数のプラットフォーム、薄いフィルムスライド等の消耗品の供給、反応槽およびキュベット等の資源へのアクセスを提供しつつ、入力サンプルに二次元のランダムアクセスをすることと言う相乗効果が含まれる。これらの全ては直ちにアクセスして利用することができる。
【００２５】
この機能は、当然、付加的な複雑さを伴う。そして、この複雑さにより、今度は、信頼性を確実なものにするためのテストが要求される。ＲＥＤは、疑わしい結果のリリースに対して追加的な確実さを提供する。典型的には、臨床診断分析機のメーカーが、その分析機でサポートされる検査プロトコルの詳細のマスターリストを提供する。このプロトコルの詳細のマスターリストは、サポートされるテストを加えるか修正するために、種々の程度に編集し得る。このプロトコルの詳細は、検査データベースに格納され、または、もう一つの情報源から入手され、前処理モジュールによってサポートされるそれぞれの検査について検討され、テストに必要なパラメータと資源とが生み出される。プロトコルの詳細は、対応する分析機で予想されるイベントの形式ではないかもしれないが、そのようなイベントは、特定の分析機についての知識を用いて生み出され得る。スケジューラ（Scheduler）は、プロトコルの詳細を使用して、資源を割り当て、種々のステップをスケジュール化して、スループットを向上させ、品質を確実なものにする。
【００２６】
それぞれのテストを行うために、スケジューラモジュールは、サブシステムモジュールに複数のコマンドを発行する。コマンドが実行されると、種々の測定がなされ、ギアが回り得、あるいは、その他の操作が起こり、そして、コマンドがうまく実行され、ループが完了したことを確認するために、応答メッセージがスケジューラに返信される。サブシステムがコマンドの実行不成功を検出した場合、スケジューラに送信される対応の応答には、典型的にはこの情報が含まれる。
【００２７】
それにも拘わらず、臨床分析機の操作の未検出エラーは、高価で好ましくない現実である。たとえば、サブシステムが失敗する場合には、そのサブシステムは「削減」され、すなわち、利用できなくなり、削減されたサブシステム利用を必要とする全ての反復試験が進行不能になる。しかしながら、その他のテストは進行し、分析機の資源を最良に使用し続ける。信頼性を確実なものにするために、削減されたサブシステムは、サンプルの処理前に再開される。この手順により、サブシステムのパフォーマンスが予想可能になるが、スケジューリングの予期しない遅れや変動を生じ得る。同様の不確実性は、計画外のイベント（例えば、オペレータが、インキュベーションチャンバーのふたを開け、その中に含まれる全てのサンプルを潜在的に汚染すること）により起こり得る。スケジューラソフトウェアの異常は、特定のステップが続かないという結果を引き起こし得る。そのステップの実行の失敗が希な出来事である場合には、それは、テスト中直ちには検出されないかもしれない。スケジューラソフトウェアにおけるそういったエラーの中には、計画外のイベント（例えば種々のサブシステムの削減、これらのサブシステムの初期化およびその他の割込み）によって悪化するものもある。
【００２８】
好ましい一実施形態では、疑わしい試験テスト結果のリリースを防止するための、エラーを検出しまたは予測するためのシステムと方法とが提供される。それぞれのサポートされるテストについて、要求されるイベント対全ての起こりうるイベントのリストは、予め、構成ファイルの形式で準備される。この構成仕様は、eXtensible Markup Language（「ＸＭＬ」）フォーマットで定義されるのが好ましい。
【００２９】
ＸＭＬを使用することには多くの利点がある。ＸＭＬは、イベント（基本的イベントの組合せまたはバリエーションであるものを含む）を定義するのに役立つ。ＸＭＬでコード化された命令および記述子は、インタープリターを使用して、リアルタイムで迅速に実行され得、デバッグされ得る。さらに、ＸＭＬベースの定義は、テキストとみなすことによって、直ちに伝達される。しかしながら、ＸＭＬタグは、人間が読み取ることはできるが、同様のタグ名を使用してまたは同一のタグ名さえ使用して、非常に異なる機能とデータを記述することがしばしばある。それにも拘わらず、コンテキストでは、ＸＭＬが、ＸＭＬに準拠した命令を実行することによって実行される機能の記述を行う。したがって、コンテキストが適切であれば、ＸＭＬは、データ、命令およびこれらの組合せを伝達する便利な方法を提供する。
【００３０】
実際には、ターゲットで特定のタスクのセットを容易にするように設計されたＸＭＬの特定の例は、特定の機能を実施することができる「新しい機械」を創造する。このようにして、ＸＭＬでコード化された命令の解釈に応じて、一以上のＸＭＬタグによって指定される機能を実施する回路は、示された機能を実施する構造体である。
【００３１】
構成仕様中、ＸＭＬを用いて記述されたイベントの例を下に示す。
【００３２】
上記のイベント仕様では、複数のイベントは、典型的には、（構成ファイルの形式であり得る）構成仕様中で記述されるが、一つのイベントは、「RED STEP」タグ内で記述される。タグを記述する基準のセットにより、背景とコンテキスト情報とが提供され、その後、複数の「RED ACTION」タグセットが続く。「RED ACTION」タグセットのそれぞれの中には、「RED LIST」タグが入れ子にされ得、「RED LIST」タグのそれぞれの中には、そのイベントを充足するためのコンディションを定義する個々の要件を記述する「RED VALUE」タグがリストされ得る。好ましい実施形態においては、そのように定義された全てのイベントが、検証されるべきテスト結果について、関心の対象であるテストに対応するメッセージストリームによって、充足されなければならない。さらに、コメントおよびその他のコマンドまたは命令と共に、失敗または成功の場合には渡されるパラメータも含まれ得る。これが、フィンガープリントでイベントを指定する唯一のスキームではないことは明らかであろう。開示された好ましい実施形態の精神から逸脱することなく、一般化の損失または特定の修正したタグの解釈の損失のない別のタグセットを案出し得る。
【００３３】
したがって、実行時、それぞれのテストのために要求されるイベント（フィンガープリント）のより完全な記述が、検査データベースを構成仕様と組み合わせて用いることにより生み出される。検査データベースまたは構成仕様への更新または変化が、生成したフィンガープリント中に自動的に反映されるので、このアプローチは、必要なメモリ資源を節約するだけでなく、柔軟性をも提供する。
【００３４】
図１に示すように、スケジューラ１００は、スクリプティング(Scripting)１０５を含む種々のサブシステムと通信し、これらのサブシステムは、今度は、サブシステムマネージャ１１０と双方向通信する。サブシステムマネージャ１１０は、図示のように、サブシステム１１５にコマンドを発行し、コマンドの実行を確認する応答を受け取る。サブシステムマネージャ１１０は、典型的には、コマンド、応答および非同期メッセージを含むメッセージトラフィックを、エミュレータファイル１６０および、メッセージと情報とを冗長エラーディテクタ１３０へ移すためのメカニズムであるＲＥＤバッファ１２０に送信する。好ましいＲＥＤバッファ１２０は、キューとして実行される。
【００３５】
スケジューラ１００は、ポストプロセッシングバッファ１５０にコマンドを送信することによって、ポストプロセッサ１５５にもコマンドを送信する。ポストプロセッサ１５５は、ＲＥＤバッファ１２０にコマンドを送信する。ＲＥＤバッファ１２０は、エミュレータファイル１６０に記録されているメッセージトラフィックのコピーも受け取る。このようにして、冗長エラーディテクタ１３０は、コマンド、応答および非同期メッセージならびにポストプロセッサ１５５からのコマンドを含むメッセージトラフィックを入力として受け取る。さらに、冗長エラーディテクタ１３０は、構成ファイル１４５にアクセスする。
【００３６】
コントロール１８０は、双方向リンクを介してスケジューラ１００を制御する。同様のリンクにより、サンプルハンドラー１７０が、コントロール１８０とサブシステムマネージャ１１０とに接続される。コントロール１８０の指示の下、患者サンプルの入力セットに要求されるテスト命令は、プリプロセッサ機能により、検査データベース１４０を用いて、スケジューラ１００のためのコマンドに変換される。ついで、スケジューラ１００は、資源を割り当て、命令を実行するためのコマンドを発行する。スケジューラ１００によるイベントの予想される実行順序が、必ずしも真ではないかも知れない点が注意される。
【００３７】
図３は、スケジューラ１００等の構成要素の複雑さを増すことなく、疑わしい結果を識別するために、結果に対し独立のテストを提供する際の冗長エラーディテクタ１３０の役割を例示するものである。反復試験の開始において、ステップ３００中、ポストプロセッサ１５５は、反復試験プレビューコマンドをＲＥＤバッファ１２０に送信する。このコマンドに応じて、冗長エラーディテクタ１３０は、ステップ３１０で資源を割り当て、構成ファイル１４５と検査データベース１４０とを用いてフィンガープリントを生成し、パラメータと、（ＲＥＤバッファ１２０でも受け取られる）メッセージトラフィックでチェックされるイベントの性質とを決定する。
【００３８】
フィンガープリントは、（ｉ）それぞれの検査または反復試験のためのプロトコル情報を提供することのできる検査データベースと、（ｉｉ）検査のための構成ファイル、反復試験または関心の対象であるデバイスの形式のハードコード化された情報、から、動的に生成されるのが好ましい。フィンガープリントは、問題のテストの成功裏の完了のために必要な予想イベントの集合である。同時に、フィンガープリント中のイベントの数は、典型的には、テストを実行することが要求されるイベントの網羅的な列挙数より少ない。構成ファイル１４５は、プロトコルにおける所与のステップについて予想イベントのリストを定める。イベントの減少は、ＲＥＤの複雑さとＲＥＤに必要な労力とを減少させる。
【００３９】
好ましいフィンガープリントには、そのパフォーマンスが、信頼できる結果と結果の正確さを改善するイベントとを生み出すのに必要である重要なイベントが含まれる。重要なイベントの成功裏の完了は、フィンガープリントの一部として明示的にはチェックされない多くのイベントの成功裏の完了をそれ自身で示し得る。
【００４０】
この好ましい実施形態では、検査毎の構成可能なパラメータは、実行時に、検査データベース１４０から読み込まれる。この好ましい実施形態では、MicroWellおよびMicroTip反復試験（追加的な二つのタイプのプラットフォーム上で動作）に対応する予想イベントが、複数の構成ファイルを一緒に併合することによって定義される一方、MicroSlideおよびＳＩ反復試験（二つのタイプのプラットホーム上で動作）の予想イベントは、構成ファイル１４５中単一の構成ファイルによって完全に定義される。この好ましい実施形態では、それぞれの構成ファイルが一つのプロトコルステップを定め、検査データベース１４０は、それぞれの反復試験を行うために要求されるプロトコルステップを決定するよう問い合わせられる。実行時に、冗長エラーディテクタ１３０が、所与の検査タイプのそれぞれのプロトコルステップに対応する構成ファイル１４５を併合することによって、予想イベントのリストを生成する。反復試験の一ステップ内のそれぞれのコマンドイベントには、イベントが許容時間範囲内に起こったことを冗長エラーディテクタ１３０にチェックさせるアクションが含まれる。許容時間範囲は、（併合されたステップとしての）実行時に、ステップ期間とインキュベーション期間とに基づいて修正される。
【００４１】
冗長エラーディテクタ１３０が、全てのデバイスに対するそれぞれのイベントを、処理が完了していない全ての反復試験のイベントを処理する前に、処理することが好ましい。ＲＥＤが受け取るそれぞれのイベントは、予想イベントが定義される順序で、それぞれのデバイスシーケンス中の予想イベントのそれぞれと比較される。あるイベントが、その予想イベントについて定義された一セットの標準にマッチする場合には、その予想イベント内で定められたアクションが実行される。受け取られたイベントが、（イベント、標準、アクションおよび、あるデバイスに対応するパラメータの定義である）デバイスシーケンス内のある予想イベントにマッチした場合には、次のイベントがＲＥＤバッファ１２０から受け取られるまで、そのデバイスシーケンス内の他の予想イベントはどれもチェックされず、実行されない。
【００４２】
図６は、更に、ＲＥＤを用いるテストのためのそのような例示的な好ましい方法を示すものである。ステップ６０５中、生成したフィンガープリントからイベントが選択される。この後、ステップ６１０中に、選択されたフィンガープリントイベントに対応するあるデバイスイベントが選択される。デバイスイベントは、構成仕様で指定されることが好ましい。しかしながら、デバイスイベントは、フィンガープリントを生成する場合のように検査プロトコル情報と併合されるわけではない。その代わりに、デバイスイベントは、デバイス状態を独立に評価するために使用される。デバイスイベントは、関心の対象であるイベントが生じた時のデバイスの状態を検証する。
【００４３】
たとえば、選択されたイベントで光学式読取り装置からの読み取りが得られる場合、対応するデバイスイベントは、テスト読み取りの前の指定期間内に、光学式読取り装置が、コントロールに対してテストされたかどうかをチェックするためのものであり得、場合によっては、光学式読取り装置が充分に機能したことを確実なものとするための、テスト読み取り後のイベントであり得る。（テスト読み取りの直前および直後のデバイス状態の比較によってチェックされる）これらのデバイスイベントの一方または両方の失敗は、反復試験を疑惑あるものとしてマーク付けすることになり得る。このようにして、（テスト読み取りの直前および直後のデバイス状態の比較によってチェックされる）デバイスイベントの失敗は、疑わしい反復試験を識別することになり得る。
【００４４】
ステップ６１０から決定ステップ６１５へ制御が移り、決定ステップ６１５中、選択されたデバイスイベントが充足されていることを確実なものとするために監視されているメッセージストリーム中のメッセージを考慮して、選択されたデバイスイベントがテストされる。イベントが充足されていない場合には、制御はステップ６２０に移り、その反復試験を疑わしいものとしてマーク付けし、この方法が終了する。他の実施形態では、この方法が一般性を失うことなく実行し続けることが許容され得る。あるいは、イベントが充足された場合、制御はステップ６２５に移り、その間に、別のデバイスイベントを評価する必要性が評価される。この段階で少なくとも一つの追加的デバイスイベントがある場合には、制御がステップ６３０に移り、他のデバイスイベントが選択され、制御がステップ６１０に戻る。
【００４５】
あるいは、ステップ６０５で選択されたフィンガープリントイベントに対応する更なるデバイスイベントがない場合には、選択されたイベントが、ステップ６３５で評価される。選択されたイベントが充足される場合には、制御はステップ６４０に移り、フィンガープリント中に更なるイベントがあるかどうかを決定する。ついで、可能ならば、ステップ６４５中に他のイベントが選択され、制御はステップ６１０に戻る。そうでない場合には、制御はステップ６５０に移り、調べられているメッセージストリームまたはイベントデータと、フィンガープリントとのマッチングが成功したとのマーク付けがされる。ついで、本方法が完了する。直ちに認識できるように、本方法は、リアルタイムで解析されないメッセージストリームまたはシミュレーションによって生成するメッセージストリームを含め、メッセージストリームを解析するのに適している。
【００４６】
予想イベントは、プラットフォームと分析機との間で異なり得る。冗長エラーディテクタ１３０の好ましいインプリメンテーションは、（ｉ）反復試験イベントおよび（ｉｉ）デバイスイベントの二種類のイベントを主に評価する。これは、図７の好ましい例示的実施形態に示されている。
【００４７】
ステップ７００中、メッセージが、監視されているメッセージトラフィックの一部として受け取られる。ステップ７０５中、このメッセージは、（適用できる場合にはＲＥＤによって維持された）デバイス状態情報の記述を更新するのに用いられる。好ましい実施形態では、ＲＥＤが、関心の対象であるそれぞれのデバイスの、ＲＥＤにより監視されるメッセージトラフィックに基づく状態を維持する。デバイス状態の更新に帰着する全てのメッセージが、関連したフィンガープリントの一部であり得るわけではない点に留意する必要がある。
【００４８】
次に、デバイスイベントのテストに受け取りメッセージが使用される。ステップ７１０中に、デバイスイベントが選択される。デバイスイベントは、好ましくは、構成仕様中に指定される。しかしながら、デバイスイベントは、フィンガープリントを生成させる場合のように検査プロトコル情報と併合されるわけではない。その代わりに、デバイス状態を独立に評価するためにデバイスイベントが使用される。デバイスイベントは、関心の対象であるイベントが生じた時のデバイスの状態を検証する。（テスト読み取りの直前および直後のデバイス状態の比較によってチェックされる）デバイスイベントの失敗は、疑わしい反復試験を識別することになり得る。
【００４９】
制御は、ステップ７１０から決定ステップ７１５に移り、決定ステップ７１５の間に、選択されたデバイスイベントが充足されることを確実なものとするためのメッセージを考慮して、選択されたデバイスイベントがテストされる。イベントが充足されない場合、制御はステップ７２０に移り、反復試験を疑わしいものとしてマーク付けする。あるいは、イベントが充足される場合には、制御はステップ７２５に移り、ステップ７２５の間に、別のデバイスイベントを評価する必要性が評価される。この段階で、少なくとも一つの追加的デバイスイベントがある場合には、制御はステップ７３０に移り、他のデバイスイベントが選択され、制御はステップ７１５に戻る。
【００５０】
あるいは、更なるデバイスイベントがない場合には、ステップ７３５中、対応するフィンガープリントからイベントが選択される。選択されたイベントは、ステップ７４０で、メッセージを考慮して評価される。選択されたイベントが充足される場合には、制御はステップ７４５に移り、フィンガープリントに更なるイベントがあるかどうかを決定する。ついで、もし可能ならば、ステップ７５０中、もう一つのイベントが選択され、制御はステップ７４０に戻る。そうでない場合には、制御はステップ７５５に移り、メッセージストリームまたはイベントデータが検討され、フィンガープリントのマッチングに成功したとのマーク付けがされる。ついで、本方法が終了する。直ちに認識されるように、本方法は、リアルタイムで解析されないメッセージストリームやシミュレーションで生成したメッセージストリームを含むメッセージストリームを解析するのに適している。
【００５１】
〔反復試験イベント〕
好ましい実施形態における反復試験イベントの若干の例は次の通りである。
MicroSlide PM Replicateは、Potentimetric MicroSlide反復試験の処理に必要な一連の重要なイベントである。MicroSlide PM Replicateの一例には、好ましくは、以下のような多数のイベントが含まれる。
イベント＃１：液吸引コマンド、
イベント＃２：液吸引応答、
イベント＃３：スライドサプライカート押し込みコマンド、
イベント＃４：スライドサプライカート押し込み応答、
イベント＃５：カートからのスライド分配コマンド、
イベント＃６：カートからのスライド分配応答、
イベント＃７：スライドへのサンプル分配コマンド、
イベント＃８：スライドへのサンプル分配応答、
イベント＃９：スライドへの分配コマンド、
イベント＃１０：スライドへの分配応答、
イベント＃１１：リングへのスライドのプッシュコマンド、
イベント＃１２：リングへのスライドのプッシュ応答、
イベント＃１３：電位計読み取りコマンド、および、
イベント＃１４：電位計読み取り応答。
【００５２】
それぞれのイベントには、指定されたパラメータによって記述されているように、いくつかのコンディションが合致することが要求される。たとえば、イベント＃１１： PMリングへのスライドのプッシュコマンドでは、ステップの始まりから指定された時間幅内にイベントが開始されることをテストすることが要求される。その他のイベント、たとえばイベント＃１０は、「成功」をテストすることだけがパスの要件である。反復試験イベントの、更なる、網羅的でない例には、次のものが含まれる。
【００５３】
MicroSlide CM Replicate Incubating in the Outer Ringは、CM Rate Incbatorの外部リング中、主要なインキュベーション時間中に行われるColormetric or Rate MicroSlide反復試験を処理するのに必要な一連の重要なイベントである。
【００５４】
MicroSlide CM Replicate Incubating in the Inner Ringは、CM Rate Incbatorの内部リング中、主要なインキュベーション時間中に行われるColormetric or Rate MicroSlide反復試験を処理するのに必要な一連の重要なイベントである。
【００５５】
MicroSlide IR Replicateは、ImmunoRate MicroSlide反復試験を処理するのに必要な一連の重要なイベントである。
【００５６】
MicroTip Reagent Addition Stepは、MicroTip反復試験中、試薬がキュベットに加えられるステップを処理するのに必要な一連の重要なイベントである。
【００５７】
MicroTip Sample Addition Stepは、MicroTip反復試験中、生のサンプルがキュベットに加えられるステップを処理するのに必要な一連の重要なイベントである。
【００５８】
MicroTip Diluted Sample Addition Stepは、MicroTip反復試験中、希釈されたサンプルがキュベットに加えられるステップを処理するのに必要な一連の重要なイベントである。
【００５９】
MicroTip Read Stepは、MicroTip反復試験中、光度計を用いてキュベットを読み取るステップを処理するのに必要な一連の重要なイベントである。
【００６０】
MicroWell 1st Well Pretreatment Stepは、MicroWell反復試験中、生のサンプルが前処理ウエルに加えられるステップを処理するのに必要な一連の重要なイベントである。
【００６１】
MicroWell Not 1st Well Pretreatment Stepは、MicroWell反復試験中、希釈されたサンプルが前処理ウエルに加えられるステップを処理するのに必要な一連の重要なイベントである。
【００６２】
MicroWell 1st Well Dilution Stepは、MicroWell反復試験中、生のサンプルが希釈ウエルに加えられるステップを処理するのに必要な一連の重要なイベントである。
【００６３】
MicroWell Not 1st Well Pretreatment Stepは、MicroWell反復試験中、希釈されたサンプルが希釈ウエルに加えられるステップを処理するのに必要な一連の重要なイベントである。
【００６４】
MicroWell Reagent Addition Step To Middle Ring Wellは、MicroWell反復試験中、試薬が前処理ウエルまたは希釈ウエルに加えられるステップを処理するのに必要な一連の重要なイベントである。
【００６５】
MicroWell Reagent Addition Step To Outer Ring Wellは、MicroWell反復試験中、反応ウエルステップを処理するのに必要な一連の重要なイベントである。
【００６６】
MicroWell 1st Well Sample Stepは、MicroWell反復試験中、生のサンプルが反応ウエルに加えられるステップを処理するのに必要な一連の重要なイベントである。
【００６７】
MicroWell Not 1st Well Sample Stepは、MicroWell反復試験中、希釈されたまたは前処理されたサンプルが反応ウエルに加えられるステップを処理するのに必要な一連の重要なイベントである。
【００６８】
MicroWell Preliminary Wash Stepは、MicroWell反復試験中、反応ウエルがその予備ウエル洗浄を受けるステップを処理するのに必要な一連の重要なイベントである。
【００６９】
MicroWell Final Wash Stepは、MicroWell反復試験中、反応ウエルがその最終的なウエル洗浄を受け、照度計を用いて読み取られるステップを処理するのに必要な一連の重要なイベントである。
【００７０】
Sample Integrity Stepは、サンプルのSample Integrity読み取りを処理するのに必要な一連の重要なイベントである。
【００７１】
〔デバイスイベント〕
デバイスイベントの若干の好ましい例には、MicroSlide電位計のイベントが含まれる。サンプルスライドとは独立して、電位計は、参照スライドを読み取り、指定期間内に参照スライドの少なくとも一つの読み取りに確実に成功する。フィンガープリントに含まれる複数の重要なイベントを指定することで、この要件が満たされる。指定された重要なイベントを持つその他のデバイスには、インキュベーションリングまたは領域、コンベヤまたはリング搬送機構、シャトル、計量装置、計量における制御、リフレクトメータ、スライド供給品、バッファ・リング、移動アーム、ＳＴＡＴレーン、試薬供給品、洗浄ステーション、ブレードインサータ、ブレードダンパ−、光度計等が含まれ得る。このリストは網羅的なものではない。
【００７２】
生成したフィンガープリントを用いて、冗長エラーディテクタ１３０は、メッセージトラフィックをレビューし、メッセージトラフィックから欠如している、フィンガープリントによって要求されたイベント形態における相違点を識別する。それぞれの受け取りメッセージについて、ＲＥＤは、関連のアクションを実施するために、好ましくは、図７に例示されるように、反復試験イベントとデバイスイベントとをフィンガープリントでマッチさせる。
【００７３】
図３のステップ３４０では、ステップ３３０の反復試験チェックコマンドの受け取りに応じて、冗長エラーディテクタ１３０は、反復試験プレビューコマンドのタイムスタンプと反復試験チェックコマンドとの間のタイムスタンプでメッセージをレビューすることによって、相違点の識別サーベイを完了する。このような相違したイベントに対応する結果には、疑わしいものとのフラッグが立てられる。
【００７４】
ステップ３５０中、冗長エラーディテクタ１３０は、相違点識別の結果をポストプロセッシングバッファ１５０に送る。これは、メッセージと情報とをポストプロセッサ１５５へ渡すためのメカニズムである。ステップ３６０で結果が疑わしいものと決定された場合、冗長エラーディテクタ１３０は、ステップ３７０中においても、テスト結果を疑わしいものとして、対応するコンディションの記録を付けて識別する。最後に、ステップ３８０中、Complete Replicateコマンドが受け取られる。疑わしい結果は、好ましくは、ポストプロセッサ１５５によってリリースされず、当然ながら臨床診断分析機によってリリースされない。必要ならば、ステップ３９０中、隔離された資源がリリースされる。
【００７５】
冗長エラーディテクタは、非リアルタイムモードで、メッセージデータにアクセスし、相違点を識別するために、エミュレータファイルまたはデータロギングファイルをレビューすることもできる。この能力は、経済的なやり方でＲＥＤ自体のより新しいバージョンを検証することを含むソフトウェアの検証およびテストに有用である。図２が、そのようなテストのための好ましい構成を示す一方、図４は、好ましい実施形態におけるこれらのステップのいくつかを例示する。
【００７６】
図４のステップ４００中、スクリプトファイルであるＲＥＤスクリプトファイル２００は、ＲＥＤバッファ２２０の規則正しいエントリを生じるために、冗長エラーディテクタドライバ２１０により用いられる。ＲＥＤスクリプトファイル２００は、（典型的にはテストにおける支援のための）いくつかのコマンドと結合された、臨床診断分析機の例示操作におけるメッセージの記録である。冗長エラーディテクタ２３０は、ＲＥＤバッファ２２０を処理し、構成ファイルと検査データベース２４０とを用いて、ダイナミックに生成させられたフィンガープリントにマッチさせる。冗長エラーディテクタ２３０による処理の結果は、PostProcバッファ２５０に送信され、今度は、それが、テストソフトウェアのパフォーマンスを評価する冗長エラーディテクタドライバ２１０に戻り、そして、これがそのデバッギングへと移行し得る。テストソフトウェアは、好ましくは冗長エラーディテクタ２３０である。あるいは、テストソフトウェアは、ＲＥＤスクリプトファイル２００で反映されるデータを生み出すための、例示操作において使用されるモジュールであり得る。別の実施形態におけるＲＥＤスクリプトファイル２００で反映されるデータは、図１で示されるように生成したエミュレータファイルからのもの、あるいは、調査中の分析機におけるエラーを識別するために調査されているデータロガーファイルからのものでさえある。冗長エラーディテクタドライバ２１０は、これら全ての潜在的に異なるフォーマットを、冗長エラーディテクタ２３０によるアクションに適したものに変換する役割を果たす。
【００７７】
他の一態様では、ＲＥＤは、ほとんど修正を必要とせず、サブシステムの入出力トラフィックを大部分不変のままにするので、既存の分析機に容易に組み入れられる。これは、冗長エラーディテクタ２３０が、臨床診断分析機の内部のメッセージトラフィックにあまり影響を及ぼすことなく接続される、図１，２から直ちに理解される。ＲＥＤは、たとえば、全ての結果をリリースするようにダイナミックに構成され得ることが好ましい。このようにして、異常が発見されたとき、ＲＥＤによって課せられるペナルティを制御し得るかまたは構成し得ることが好ましい。
【００７８】
効率的なエラー検出システムの目標には、誤った結果のリリースを防止するために、エラーをタイムリーに発見することが含まれる。構成ファイルは、ＲＥＤによって実施されるチェックを定義する。このようにして、それぞれの検査モデルタイプについて、ＲＥＤが、結果の品質にとって重大なイベント；結果の品質に有害なイベント；それぞれのイベントについて、もし存在するとすれば、合格／失敗／警報標準；および、要求されるサンプルの一貫性チェック、についてチェックすることが好ましい。
【００７９】
ほとんどの場合、ＲＥＤによってチェックされるイベントは、関心の対象である臨床診断分析機やその他のシステムの、ルーチンのコマンド応答デザインによってもチェックされる。分析機のパフォーマンスへのＲＥＤの影響が小さいことに鑑み、ＲＥＤの実行は、許容し得る結果のリリースをあまり遅らせない。よい結果の予測をＲＥＤが妨げる可能性を減少させる努力における有用なガイドラインには、チェックされるイベントの数を要求されたイベントだけに制限すること；パラメータの有効な範囲を全てのシナリオをカバーするように正しく設定すること；および、ＲＥＤモジュールが故障していると思われるときでも、ＲＥＤモジュールが結果に失敗し得ることを防止するような構成にすること、が含まれる。
【００８０】
さらに、ＲＥＤモジュール自体が、全てのチェックが予想されるシナリオで正しく実行されていることを検証するためにテストされる。たとえば、これは、図２で提示されるシミュレーション戦略によって実行され得る。
【００８１】
〔別のエラー検出戦略〕
ＲＥＤは、潜在的に誤って報告された結果を検出し、防止する。所望の品質水準を達成するための好ましいアプローチとして、テストとコードレビューとに主に依存するのが慣例である。しかしながら、ＲＥＤは、複雑なモジュールをテストする場合、必然的に困難であり、資源集約的な作業であるコードレビューの必要性を大きく減らす。
【００８２】
クローズループチェックはもう一つの戦略であるが、かなりの開発費用、統合費用および検証費用を招来する。さらに、問題のモジュール内で実施されるクローズループチェックは、全ての状況で信頼できるというわけではない。モジュール内で実行されるクローズループチェックは、テストされているモジュールとは独立していないことがしばしばある。
【００８３】
ＲＥＤのアーキテクチャは、多くの異なるタイプの入力を受け入れることができる。２つの明らかな選択は、サブシステムＩ／Ｏ（サブシステムコマンド、応答および非同期メッセージから構成）およびデータロガーイベントである。
【００８４】
好ましい一実施形態では、ＲＥＤは、要請されたチェックを実施し、その状態（合格、失敗または、オプションで警告レベル）を示す応答を返す。ＲＥＤは、それぞれの検査モデルが、異なるプロトコルステップを持ち、したがって、異なる完全性チェックを有することを認識する。反復試験に関連するチェックのカテゴリーはリストされている。それぞれのカテゴリーは、反復試験のプロトコル情報に依存してダイナミックに変えられ得る予想イベントの表と相互に関連付けられている。このようにして、ＲＥＤは、分析機等の複合システムでメッセージトラフィックのリアルタイム処理に固有の複雑さから独立したテストを提供することによって、分析機のために潜在的にコーディングを単純化し、結果について改善された信頼性を与える。
【００８５】
図５はＲＥＤの機能を例示する。典型的には、メッセージと情報とを転送するためのメカニズム（ここでは、コマンドとデータとを冗長エラーディテクタ機能５１０に提供するＲＥＤバッファ５００）がある。好ましい一実施形態では、冗長エラーディテクタ機能５１０には、構成ファイル、フィンガープリントおよびその生成能力、フィンガープリントをＲＥＤバッファ５００からのメッセージと比較する能力、結果報告能力ならびに資源割り当ておよびリリース機能が含まれる。検査データベース５２０は、冗長エラーディテクタ機能５１０にアクセスし得る。このアクセスは、フィンガープリントを生成するのに有用である。
【００８６】
当業者ならば、この開示が、その教示内容または精神から逸脱することなく、多くのバリエーションおよび代替的実現方法を許容するものであることを認識するであろう。たとえば、イベントのフィンガープリントを用いて評価される一貫性についてのそれぞれの出力の評価に基づいて、臨床分析機以外の複合システムが、ここに記載されたような冗長エラーテストにより利益を得るであろう。添付の請求の範囲には、このような多くの修正が含まれる。さらに、ここで説明され、引用されたそれぞれの引用文献は、参照によってここにその全体が取り入れられる。
【図面の簡単な説明】
【００８７】
【図１】冗長エラーディテクタに連結された臨床診断分析機における処理モジュールの概略図である。
【図２】冗長エラーディテクタを使用するソフトウェアテスト配置の概略図である。
【図３】冗長エラー検出機能および、冗長エラー検出機能の内部にあるまたは冗長エラー検出機能と密接に対話する種々の構成要素（これらは更に統合し得る）を例示する図である。
【図４】冗長エラーディテクタを用いてエラーをチェックする方法を例示する図である。
【図５】冗長エラーディテクタを用いてソフトウェアを評価し、デバッグする方法を例示する図である。
【図６】冗長エラー検出機能および、冗長エラー検出機能の内部にあるまたは冗長エラー検出機能と密接に対話する種々の構成要素（これらは更に統合し得る）を例示する図である。
【図７】冗長エラー検出機能によって維持されているデバイス状態を更新しつつ、デバイスイベントと反復試験のイベントについてのメッセージストリームをチェックする冗長エラー検出機能の例を示す図である。
【開示の内容】
【０００１】
〔背景〕
臨床分析機システムにおける検査パフォーマンスの低下の補修または修正は、電気的または機械的問題を修正することに比べより困難であることが判明してきた。臨床試験テストシステムおよび診断システムの予想されるパフォーマンスの推定および実際のパフォーマンスの監視は、詳細な最新の情報を必要とする。臨床診断システムの設計と製造には、高スループットを維持しつつ、正確な検査を行うために、何千もの構成要素とサブシステムとを複雑なソフトウェアの調整組合せでテストし統合することが必要とされる。Raritan、ニュージャージー州のOrtho Clinical Diagnostics ("ＯＣＤ")によって製造されたVITROS 4,3（商標）およびECi系列の臨床診断分析機が、その例である。
【０００２】
臨床診断分析機には、その操作を監視し、制御する大規模なソフトウェアが含まれる。分析機のすべてのあり得る状態をテストし検討することは、分析機の予想される寿命と用途とに関し、ソフトウェアとハードウェアとの組合せについてあり得る状態の数の大きさを考慮すると、可能ではないことがしばしばである。臨床診断分析機のソフトウェアのテストは、高価で、時間が掛かり、困難である。たとえば、分析機のサブシステムが故障した場合、分析機は縮小され、休止状態と宣言され、使用前に再スタートし、初期化される必要がある。たとえば、インキュベーションチャンバーのカバーの予想外の開口のために生成した非同期メッセージは、その影響を受けた反復試験を、潜在的に不正に変更されたものとして取り扱う必要があるであろう。さらに、エラーコンディションからの回復は、制限の超過、ステップの失敗、および、その他の多くの検出されていないエラーにより、多くの他のテストに影響を与え得る。エラーは、また、更なるエラーを生じさせ、多くの他のテストを通じて波及し得る。さらに、異なるテストが異なる程度に影響を受け得るので、このようなエラーまたはその影響が、臨床診断分析機の操作を制御、調整するルーチンのプロセスでは、適時に検出されない場合がある。この代替法では、しばしば、処理の種々の段階における価値ある患者サンプルを放棄し、装置の全体を再スタートすることになり、これにより、スループットと効率とが減少する。
【０００３】
臨床診断分析機の設計における目標のうちの一つは、誤った結果に基づく処置またはその処置の欠如によって患者に与え得る危害を考慮して、疑わしい試験結果のリリースを防止することである。このようにして、タイムリーなエラー検出は、臨床診断分析機にとってかなり重要である。特に、検査結果の信頼性を改善しつつ、検査コストを低減するためには、健康と安全性のガイドラインを充足するためだけの検査と装置のパフォーマンスを確実なものにする以上のことをすることが好ましい。同時に、基準の含めすぎ(over-inclusive criterion)により正当な結果を放棄しないことが必須である。
【０００４】
試験室は、誤った結果やさらには潜在的に誤った結果さえリリースされるのを防止することを助けるために、広範囲にわたる技術を使用する。これらには、検査管理図、器材メンテナンスプロセス／記録、定期的な分析機のメンテナンス、特定の検査についての患者の通常のパフォーマンスとの比較、患者の最後の結果からの変化のレビュー、生理的に安定した量を計算するための結果のグループ化が含まれるが、これらに限定されるわけではない。これらのアプローチの全ては、結果がリリースされた後にパフォーマンスの問題に反応するように設計されている。一般的に、結果をリリースすることは、結果を提供することだけではなく、結果の信頼性を示すことも意味する。多くのチェックが、一日に一回程度の少ない頻度で実施され、長期の傾向または頻繁な異常値または非常に大きなパフォーマンスの低下の検出にのみ適している。このことは、これらの方法を使用して検出される前に、何時間も、さらには何日もの間さえ、低下したパフォーマンスの検査データをリリースするリスクに試験所と患者とを曝すことになる。このことは、忙しい試験所では、何百もの患者サンプルが再試験され、試験所のスループットが減少する一方、所望のものではない治療をするというリスクを高めることになり得る。
【０００５】
臨床診断分析機は、他の複合システムと同様、スケジューラライクのコントローラ、コマンドを含むメッセージトラフィックを使用する制御サブシステム、応答と非同期メッセージ、割り込み等を含んでいる。典型的には、スケジューラ（通常、ソフトウェアモジュールとして実行される）は、資源を割り当て、所望のテストをスケジュール化し、種々のコマンドのパフォーマンスを追跡することによって、臨床診断分析機の操作を制御する。スケジューラは、種々のサブシステムにコマンドを発行し、これらのサブシステムは、コマンドの実行結果を示す応答を返信する。これらのサブシステムは、今度は、スケジューラからのコマンドの受け取りに応じて、他のソフトウェアモジュールに一以上のコマンドを送信し、対応するコマンドの実行結果を示すメッセージをそれらから受け取り得る。
【０００６】
全てのサブシステムコマンド、コマンド応答および非同期メッセージは、サブシステム入出力であると考えることができる。サブシステムマネージャであるソフトウェアモジュールは、エミュレータファイルにこれらのメッセージを書き込む。エミュレータファイルは、膨大なものであるが、トラブルシューティング中にレビューし得る。しかしながら、このタスクは、遅くなりがちであり、過度に結果のリリースを遅延させることなく、疑わしい結果にフラッグを立て、疑わしい結果のリリースを防止するには非実用的である。とりわけ、臨床診断分析機は、典型的には、促進処理を必要とするＳＴＡＴサンプルのテストをサポートする。臨床診断分析機を取り扱うにはやはり適切でない複合システムのパフォーマンスを追跡し、推定する若干の更なる戦略について次に記述する。
【０００７】
米国特許第７，２５４，６０１号（「’６０１特許」）は、遠隔地に配備されたインテリジェント装置を管理する方法を開示しているが、疑わしい試験結果のリリースのタイムリーな防止については教示していない。
【０００８】
米国特許第６，７５７，７１４号（「’７１４特許」）ならびにこれに関連する特許および特許出願は、リモートサーバーへの電子メールを介する、装置のエラーコンディションの獲得と伝達について開示している。一以上の変数を得て、それらをテンプレートに挿入することにより、電子メールメッセージを生成するのに、予め定義されたテンプレートが用いられる。エラーコンディションは、電子メールメッセージの本文の一部として、または、電子メールメッセージへの添付物の一部として含まれ得る。エラーコンディションは、eXtensible Markup Language(ＸＭＬ)等の自己記述コンピュータ言語を使用して報告される。一般的に、エラーコンディションは、組み込みコントローラの助けにより決定される。リモートサーバーは、エラーコンディションを顧客関係管理システムに渡す。’７１４特許は、機械が、予想外のスケジューラまたはソフトウェアエラーに起因する疑わしい結果をリリースするのを妨げることによって、誤った結果のリリースを防止する問題には対応していない。
【０００９】
高いパフォーマンスを確実なものにするために、臨床診断分析機のあり得るあらゆる状態を網羅的にレビューし、テストするようなニーズを減らすことが必要である。それどころか、試験所からリリースされる結果の信頼性を確実なものにするために、より良いエラー検出戦略が必要である。
【００１０】
〔概要〕
好ましい一実施形態によれば、疑わしい試験テスト結果のリリースを防止するために、エラーを検出しまたは予測するシステムと方法とが提供される。手短かに言えば、この好ましい実施形態では、検査データベースと構成ファイルまたは構成仕様を用いて、実際のパラメータを、それぞれの検査について生成された予想されるフィンガープリントに対して比較することによって、あり得るエラーまたは疑わしい結果がないかメッセージトラフィックを更に調べるために、冗長エラー検出能力を採用する。このテストは、テストされるソフトウェアモジュールからの入力に依存せず、それゆえに、独立したテストである。たとえば、スケジューラソフトウェアの実施が予想外のやり方である場合、そのようなエラーや問題によって影響を受けた結果がリリースされる前に、そのようなエラーにフラッグを立てる独立した方法があることが好ましい。更に、冗長エラー検出(Redundant Error Detection, 「RED」)能力自体をテストするためのテストメカニズムが提供される。
【００１１】
フィンガープリントは、（ｉ）それぞれの検査について、プロトコル情報を提供することができる検査データベース、および、（ｉｉ）検査、反復試験または関心の対象であるデバイスについての構成ファイルの形態でハードコード化された情報からダイナミックに生成されるのが好ましい。フィンガープリントは、問題のテストの成功裏の完了のために必要な予期されるイベントの集合である。同時に、一つのフィンガープリント中のイベントの数は、一般的に、そのテストのために実際に実行されるイベントの網羅的な列挙数より少ない。フィンガープリントを生み出すプロトコルデータベース中のイベントの数の減少は、構成仕様がそのガイドになる。構成仕様が検査データベースからの情報に併合されて、予想されるフィンガープリントが生成されることが好ましい。
【００１２】
生成したフィンガープリントを用いて、ＲＥＤは、メッセージトラフィックをレビューし、メッセージトラフィックにはない、フィンガープリントによって要求されるイベントの形態の相違点を識別し、疑わしい結果にフラッグを立てる。ＲＥＤは、エミュレータファイルまたはデータロギングファイルをレビューしてメッセージデータにアクセスし、結果が処理された後、相違点を識別することもできる。この能力は、ＲＥＤ自体のより新しいバージョンを検証することを含むソフトウェアを、経済的な方法で検証およびテストするのに有用である。
【００１３】
他の一態様では、ＲＥＤは、ほとんど修正を要せず、サブシステム入出力トラフィックの大部分を不変のままにするため、既存の分析機に容易に一体化される。
【００１４】
好ましい一実施形態には、臨床診断分析機における疑わしい試験結果を検出するための、臨床診断分析機のプロセッサで実行可能なモジュールが含まれる。このモジュールには、サブシステムコマンド、コマンド応答および非同期メッセージを含むメッセージのコピーを受け取るためのメカニズムが含まれる。このモジュールには、反復試験でテストされる予想イベントのフィンガープリントも含まれる。フィンガープリントは、少なくとも構成ファイルと、反復試験に必要な検査に関する詳細を含む検査データベースとから、反復試験プレビューコマンドに応じて生成される。このモジュールには、反復試験チェックコマンドに応じて、受け取りメッセージとフィンガープリントとの間の比較を完了するための命令が含まれる。このモジュールは、比較の結果を報告するための命令を含み、また、反復試験の完了コマンドの受け取りに応じて、反復試験の冗長検査(redundant checking)のために必要な資源をリリースする。
【００１５】
この好ましい実施形態では、ＲＥＤの機能は、オペレータが、容易にダイナミックにオフにし得る。このことは、ＲＥＤにおけるエラーが疑われる場合には有用であり得る。失敗または疑わしい結果が発見される場合は、ＲＥＤ機能が、対応するコンディションの記録を付ける。そのような記録付けにより、発見されたコンディションがオペレータに知らされる。これは、ソフトウェアをデバッグして、改善する上で有用である。しかしながら、ＲＥＤ自体の疑わしい問題が解決されるまで、結果をリリースしないという決定は、オフにされ得る。
【００１６】
本開示には、臨床診断分析機におけるソフトウェアモジュールをテストする方法が含まれる。この方法には、冗長エラーディテクタへの引き渡しに適した、サブシステムコマンド、コマンド応答および非同期メッセージを生成するステップが含まれる。冗長エラーディテクタは、不一致点について、生成したサブシステムコマンド、コマンド応答および非同期メッセージをレビューする。そのような不一致点が識別された場合には、ソフトウェアモジュールが、信頼できかつ一貫性のあるパフォーマンスを確実なものにするためにデバッグされる。特に、テストされるソフトウェアモジュールは、冗長エラーディテクタソフトウェアであり得る。さらに、ソフトウェアモジュールを含むシステムの一部または全体が、このようなやり方でテストされ得る。
【００１７】
サブシステムコマンド、コマンド応答および非同期メッセージは、分析機の一以上前の実行記録を含んでいるスクリプトファイルから生成されるのが有利である。ついで、冗長エラーディテクタを用いて、フィンガープリントで要求される任意のイベントにおける不一致点を検出するために、別のバージョンのソフトウェアを用いる臨床診断分析機のパフォーマンスを比較し得る。スクリプトファイルには、臨床診断分析機の例示的操作からのデータに加え、コマンドが含まれ得る。
【００１８】
他の一態様では、好ましい一実施形態には、臨床診断分析機による疑わしい結果のリリースを防止するための方法がある。この方法には、反復試験のための反復試験プレビューコマンドを受け取るステップ、反復試験についての冗長エラー検査のための資源を割り当てるステップ、少なくとも一つの構成ファイルと検査データベース（ここで、フィンガープリントは、反復試験(replicate)のために検査データベースから生成され得るイベントより少ない数のイベントを有する）とを用いて、反復試験のために必要なイベントのフィンガープリントを生成するステップ、反復試験処理に対応するメッセージをフィンガープリントと比較するステップ、比較の結果を送信し、臨床診断分析機による反復試験に対応する結果のリリースを防止するステップ、および、反復試験に対応するコンディションの記録を付けるステップ、を容易にすることが含まれる。冗長エラー検査のために必要な資源の割り当てとリリースとは、明示的なものである必要はなく、その代わりに、システムまたは基礎となっているプログラミング言語に応じて、自動的に、オペレーティングシステム等の機能によって取り扱われ得る点に留意する必要がある。インプリメンテーションの柔軟性のために、構成ファイルが、人が読むことができ、遠隔地の分析機にテキストとして容易に送信できるeXtensible Markup Languageでコード化されるのが有利である。
【００１９】
好ましいいくつかの実施形態における種々の特徴を、例示図面の助けを借りて、以下に、より詳細に記述する。好ましいいくつかの実施形態における種々の特徴は、例示図面および、モジュールまたはサブモジュールの助けを借りて、以下に、より詳細に記述される。好ましい実施形態では、モジュール（およびサブモジュール）は機能的区分を反映するものである。モジュールまたはサブモジュールは、その機能を実行するために、共用資源を使用し得る。資源は、典型的には、当業者に周知の、プロセッサタイムスライス、データベースデータ、他のモジュールと共有されるメモリ中のデータ、サブモジュール、共用ライブラリー関数等である。モジュールを作成する方法は、当業者である開発者に知られている。機能的区分を実行可能コードにマッピングすることは、当業者によく知られている。図面については次に簡単に記述する。
【００２０】
〔好ましい実施形態の詳細な説明〕
臨床診断分析機の「基本的イベント」は、典型的には、一以上のパラメータまたはその中の変化の検出である。パラメータは、臨床診断分析機の状態の値または記述子である。イベントは、一以上の指定されたコンディションの遂行で生じる。多数のそのような基本的イベントは、典型的には、臨床診断分析機に対し前もって定義される。コマンド、応答および非同期メッセージを含むメッセージトラフィックは、関心の対象であるイベントのサブセットの例である。
【００２１】
ソフトウェア機能である冗長エラーディテクタ（「ＲＥＤ」）モジュールは、分析機または他の高度な処理システムを操作する過程における、予想イベントの繋がりと実際に観察されたイベントの繋がりとの間の相違点を検出する。全てのイベントの網羅的な重複レビューを避けるために、それぞれのテストタイプの実行についてフィンガープリントを提供するための予想イベントの繋がりが策定される。ＲＥＤは、ソフトウェアの検証のみならず、実行された反復試験の回帰テストも提供する。このコンテキストにおいて、イベントとは、一以上のパラメータまたはその中の変化の検出を示すものである。イベントのいくつかの例には、コマンドの発行または受け取り、測定の実施、コマンドの実行を確認するための応答の発行または受け取り、割り込み等が含まれる。
【００２２】
ＲＥＤは、ＯＣＤの臨床診断分析機VITROS 5600（商標）およびVITROS 3600（商標）との互換性を有する。これらは、ＲＥＤを実行するための好ましいプラットフォームを提供する。ＲＥＤは、他の臨床診断分析機にとっても有用であることが期待される。VITROS 5600（商標）とVITROS 3600（商標）とのそれぞれは、複数の相異なるタイプの化学作用プラットフォームをサポートし得る、マスタースケジューラ(Master Scheduler)によって提供される機能を用いる。ＯＣＤのマスタースケジューラは、これら種々のプラットフォーム間で共用されるロボットアームおよびロボットピペッターを制御して、入力された患者のサンプルにランダムにアクセスすることもできる。これはスループットの改善になる。入力サンプルへのランダムアクセスは、サンプルを入力の順に処理するという典型的な要請を実質的に除外するものである。
【００２３】
ＯＣＤのマスタースケジューラは、たとえば、入力されたサンプルに任意の順序で資源を割り当てるための、スケジューリング機能を実施する。これほど多様ではない他のスケジューラも、ＲＥＤ機能の追加による利益を享受する。ＯＣＤのマスタースケジューラは、適用可能なプロトコルの制限を遵守する一方、テストのための完了時間(Time to Complete)を全体として最小にするようスケジュールを決定し、これによって、高スループットを維持する。
【００２４】
ＯＣＤのマスタースケジューラの利点には、例えば、複数のセンシオメトリック(sensiometric)デバイス（例えば、電位計、反射率計、ルミネセンス、光透過率、光子検出、サンプルの加熱のためのインキュベータ、試薬の供給および複数の試薬配送サブシステム）と共に、複数のプラットフォーム、薄いフィルムスライド等の消耗品の供給、反応槽およびキュベット等の資源へのアクセスを提供しつつ、入力サンプルに二次元のランダムアクセスをすることと言う相乗効果が含まれる。これらの全ては直ちにアクセスして利用することができる。
【００２５】
この機能は、当然、付加的な複雑さを伴う。そして、この複雑さにより、今度は、信頼性を確実なものにするためのテストが要求される。ＲＥＤは、疑わしい結果のリリースに対して追加的な確実さを提供する。典型的には、臨床診断分析機のメーカーが、その分析機でサポートされる検査プロトコルの詳細のマスターリストを提供する。このプロトコルの詳細のマスターリストは、サポートされるテストを加えるか修正するために、種々の程度に編集し得る。このプロトコルの詳細は、検査データベースに格納され、または、もう一つの情報源から入手され、前処理モジュールによってサポートされるそれぞれの検査について検討され、テストに必要なパラメータと資源とが生み出される。プロトコルの詳細は、対応する分析機で予想されるイベントの形式ではないかもしれないが、そのようなイベントは、特定の分析機についての知識を用いて生み出され得る。スケジューラ（Scheduler）は、プロトコルの詳細を使用して、資源を割り当て、種々のステップをスケジュール化して、スループットを向上させ、品質を確実なものにする。
【００２６】
それぞれのテストを行うために、スケジューラモジュールは、サブシステムモジュールに複数のコマンドを発行する。コマンドが実行されると、種々の測定がなされ、ギアが回り得、あるいは、その他の操作が起こり、そして、コマンドがうまく実行され、ループが完了したことを確認するために、応答メッセージがスケジューラに返信される。サブシステムがコマンドの実行不成功を検出した場合、スケジューラに送信される対応の応答には、典型的にはこの情報が含まれる。
【００２７】
それにも拘わらず、臨床分析機の操作の未検出エラーは、高価で好ましくない現実である。たとえば、サブシステムが失敗する場合には、そのサブシステムは「削減」され、すなわち、利用できなくなり、削減されたサブシステム利用を必要とする全ての反復試験が進行不能になる。しかしながら、その他のテストは進行し、分析機の資源を最良に使用し続ける。信頼性を確実なものにするために、削減されたサブシステムは、サンプルの処理前に再開される。この手順により、サブシステムのパフォーマンスが予想可能になるが、スケジューリングの予期しない遅れや変動を生じ得る。同様の不確実性は、計画外のイベント（例えば、オペレータが、インキュベーションチャンバーのふたを開け、その中に含まれる全てのサンプルを潜在的に汚染すること）により起こり得る。スケジューラソフトウェアの異常は、特定のステップが続かないという結果を引き起こし得る。そのステップの実行の失敗が希な出来事である場合には、それは、テスト中直ちには検出されないかもしれない。スケジューラソフトウェアにおけるそういったエラーの中には、計画外のイベント（例えば種々のサブシステムの削減、これらのサブシステムの初期化およびその他の割込み）によって悪化するものもある。
【００２８】
好ましい一実施形態では、疑わしい試験テスト結果のリリースを防止するための、エラーを検出しまたは予測するためのシステムと方法とが提供される。それぞれのサポートされるテストについて、要求されるイベント対全ての起こりうるイベントのリストは、予め、構成ファイルの形式で準備される。この構成仕様は、eXtensible Markup Language（「ＸＭＬ」）フォーマットで定義されるのが好ましい。
【００２９】
ＸＭＬを使用することには多くの利点がある。ＸＭＬは、イベント（基本的イベントの組合せまたはバリエーションであるものを含む）を定義するのに役立つ。ＸＭＬでコード化された命令および記述子は、インタープリターを使用して、リアルタイムで迅速に実行され得、デバッグされ得る。さらに、ＸＭＬベースの定義は、テキストとみなすことによって、直ちに伝達される。しかしながら、ＸＭＬタグは、人間が読み取ることはできるが、同様のタグ名を使用してまたは同一のタグ名さえ使用して、非常に異なる機能とデータを記述することがしばしばある。それにも拘わらず、コンテキストでは、ＸＭＬが、ＸＭＬに準拠した命令を実行することによって実行される機能の記述を行う。したがって、コンテキストが適切であれば、ＸＭＬは、データ、命令およびこれらの組合せを伝達する便利な方法を提供する。
【００３０】
実際には、ターゲットで特定のタスクのセットを容易にするように設計されたＸＭＬの特定の例は、特定の機能を実施することができる「新しい機械」を創造する。このようにして、ＸＭＬでコード化された命令の解釈に応じて、一以上のＸＭＬタグによって指定される機能を実施する回路は、示された機能を実施する構造体である。
【００３１】
構成仕様中、ＸＭＬを用いて記述されたイベントの例を下に示す。
【００３２】
上記のイベント仕様では、複数のイベントは、典型的には、（構成ファイルの形式であり得る）構成仕様中で記述されるが、一つのイベントは、「RED STEP」タグ内で記述される。タグを記述する基準のセットにより、背景とコンテキスト情報とが提供され、その後、複数の「RED ACTION」タグセットが続く。「RED ACTION」タグセットのそれぞれの中には、「RED LIST」タグが入れ子にされ得、「RED LIST」タグのそれぞれの中には、そのイベントを充足するためのコンディションを定義する個々の要件を記述する「RED VALUE」タグがリストされ得る。好ましい実施形態においては、そのように定義された全てのイベントが、検証されるべきテスト結果について、関心の対象であるテストに対応するメッセージストリームによって、充足されなければならない。さらに、コメントおよびその他のコマンドまたは命令と共に、失敗または成功の場合には渡されるパラメータも含まれ得る。これが、フィンガープリントでイベントを指定する唯一のスキームではないことは明らかであろう。開示された好ましい実施形態の精神から逸脱することなく、一般化の損失または特定の修正したタグの解釈の損失のない別のタグセットを案出し得る。
【００３３】
したがって、実行時、それぞれのテストのために要求されるイベント（フィンガープリント）のより完全な記述が、検査データベースを構成仕様と組み合わせて用いることにより生み出される。検査データベースまたは構成仕様への更新または変化が、生成したフィンガープリント中に自動的に反映されるので、このアプローチは、必要なメモリ資源を節約するだけでなく、柔軟性をも提供する。
【００３４】
図１に示すように、スケジューラ１００は、スクリプティング(Scripting)１０５を含む種々のサブシステムと通信し、これらのサブシステムは、今度は、サブシステムマネージャ１１０と双方向通信する。サブシステムマネージャ１１０は、図示のように、サブシステム１１５にコマンドを発行し、コマンドの実行を確認する応答を受け取る。サブシステムマネージャ１１０は、典型的には、コマンド、応答および非同期メッセージを含むメッセージトラフィックを、エミュレータファイル１６０および、メッセージと情報とを冗長エラーディテクタ１３０へ移すためのメカニズムであるＲＥＤバッファ１２０に送信する。好ましいＲＥＤバッファ１２０は、キューとして実行される。
【００３５】
スケジューラ１００は、ポストプロセッシングバッファ１５０にコマンドを送信することによって、ポストプロセッサ１５５にもコマンドを送信する。ポストプロセッサ１５５は、ＲＥＤバッファ１２０にコマンドを送信する。ＲＥＤバッファ１２０は、エミュレータファイル１６０に記録されているメッセージトラフィックのコピーも受け取る。このようにして、冗長エラーディテクタ１３０は、コマンド、応答および非同期メッセージならびにポストプロセッサ１５５からのコマンドを含むメッセージトラフィックを入力として受け取る。さらに、冗長エラーディテクタ１３０は、構成ファイル１４５にアクセスする。
【００３６】
コントロール１８０は、双方向リンクを介してスケジューラ１００を制御する。同様のリンクにより、サンプルハンドラー１７０が、コントロール１８０とサブシステムマネージャ１１０とに接続される。コントロール１８０の指示の下、患者サンプルの入力セットに要求されるテスト命令は、プリプロセッサ機能により、検査データベース１４０を用いて、スケジューラ１００のためのコマンドに変換される。ついで、スケジューラ１００は、資源を割り当て、命令を実行するためのコマンドを発行する。スケジューラ１００によるイベントの予想される実行順序が、必ずしも真ではないかも知れない点が注意される。
【００３７】
図３は、スケジューラ１００等の構成要素の複雑さを増すことなく、疑わしい結果を識別するために、結果に対し独立のテストを提供する際の冗長エラーディテクタ１３０の役割を例示するものである。反復試験の開始において、ステップ３００中、ポストプロセッサ１５５は、反復試験プレビューコマンドをＲＥＤバッファ１２０に送信する。このコマンドに応じて、冗長エラーディテクタ１３０は、ステップ３１０で資源を割り当て、構成ファイル１４５と検査データベース１４０とを用いてフィンガープリントを生成し、パラメータと、（ＲＥＤバッファ１２０でも受け取られる）メッセージトラフィックでチェックされるイベントの性質とを決定する。
【００３８】
フィンガープリントは、（ｉ）それぞれの検査または反復試験のためのプロトコル情報を提供することのできる検査データベースと、（ｉｉ）検査のための構成ファイル、反復試験または関心の対象であるデバイスの形式のハードコード化された情報、から、動的に生成されるのが好ましい。フィンガープリントは、問題のテストの成功裏の完了のために必要な予想イベントの集合である。同時に、フィンガープリント中のイベントの数は、典型的には、テストを実行することが要求されるイベントの網羅的な列挙数より少ない。構成ファイル１４５は、プロトコルにおける所与のステップについて予想イベントのリストを定める。イベントの減少は、ＲＥＤの複雑さとＲＥＤに必要な労力とを減少させる。
【００３９】
好ましいフィンガープリントには、そのパフォーマンスが、信頼できる結果と結果の正確さを改善するイベントとを生み出すのに必要である重要なイベントが含まれる。重要なイベントの成功裏の完了は、フィンガープリントの一部として明示的にはチェックされない多くのイベントの成功裏の完了をそれ自身で示し得る。
【００４０】
この好ましい実施形態では、検査毎の構成可能なパラメータは、実行時に、検査データベース１４０から読み込まれる。この好ましい実施形態では、MicroWellおよびMicroTip反復試験（追加的な二つのタイプのプラットフォーム上で動作）に対応する予想イベントが、複数の構成ファイルを一緒に併合することによって定義される一方、MicroSlideおよびＳＩ反復試験（二つのタイプのプラットホーム上で動作）の予想イベントは、構成ファイル１４５中単一の構成ファイルによって完全に定義される。この好ましい実施形態では、それぞれの構成ファイルが一つのプロトコルステップを定め、検査データベース１４０は、それぞれの反復試験を行うために要求されるプロトコルステップを決定するよう問い合わせられる。実行時に、冗長エラーディテクタ１３０が、所与の検査タイプのそれぞれのプロトコルステップに対応する構成ファイル１４５を併合することによって、予想イベントのリストを生成する。反復試験の一ステップ内のそれぞれのコマンドイベントには、イベントが許容時間範囲内に起こったことを冗長エラーディテクタ１３０にチェックさせるアクションが含まれる。許容時間範囲は、（併合されたステップとしての）実行時に、ステップ期間とインキュベーション期間とに基づいて修正される。
【００４１】
冗長エラーディテクタ１３０が、全てのデバイスに対するそれぞれのイベントを、処理が完了していない全ての反復試験のイベントを処理する前に、処理することが好ましい。ＲＥＤが受け取るそれぞれのイベントは、予想イベントが定義される順序で、それぞれのデバイスシーケンス中の予想イベントのそれぞれと比較される。あるイベントが、その予想イベントについて定義された一セットの標準にマッチする場合には、その予想イベント内で定められたアクションが実行される。受け取られたイベントが、（イベント、標準、アクションおよび、あるデバイスに対応するパラメータの定義である）デバイスシーケンス内のある予想イベントにマッチした場合には、次のイベントがＲＥＤバッファ１２０から受け取られるまで、そのデバイスシーケンス内の他の予想イベントはどれもチェックされず、実行されない。
【００４２】
図６は、更に、ＲＥＤを用いるテストのためのそのような例示的な好ましい方法を示すものである。ステップ６０５中、生成したフィンガープリントからイベントが選択される。この後、ステップ６１０中に、選択されたフィンガープリントイベントに対応するあるデバイスイベントが選択される。デバイスイベントは、構成仕様で指定されることが好ましい。しかしながら、デバイスイベントは、フィンガープリントを生成する場合のように検査プロトコル情報と併合されるわけではない。その代わりに、デバイスイベントは、デバイス状態を独立に評価するために使用される。デバイスイベントは、関心の対象であるイベントが生じた時のデバイスの状態を検証する。
【００４３】
たとえば、選択されたイベントで光学式読取り装置からの読み取りが得られる場合、対応するデバイスイベントは、テスト読み取りの前の指定期間内に、光学式読取り装置が、コントロールに対してテストされたかどうかをチェックするためのものであり得、場合によっては、光学式読取り装置が充分に機能したことを確実なものとするための、テスト読み取り後のイベントであり得る。（テスト読み取りの直前および直後のデバイス状態の比較によってチェックされる）これらのデバイスイベントの一方または両方の失敗は、反復試験を疑惑あるものとしてマーク付けすることになり得る。このようにして、（テスト読み取りの直前および直後のデバイス状態の比較によってチェックされる）デバイスイベントの失敗は、疑わしい反復試験を識別することになり得る。
【００４４】
ステップ６１０から決定ステップ６１５へ制御が移り、決定ステップ６１５中、選択されたデバイスイベントが充足されていることを確実なものとするために監視されているメッセージストリーム中のメッセージを考慮して、選択されたデバイスイベントがテストされる。イベントが充足されていない場合には、制御はステップ６２０に移り、その反復試験を疑わしいものとしてマーク付けし、この方法が終了する。他の実施形態では、この方法が一般性を失うことなく実行し続けることが許容され得る。あるいは、イベントが充足された場合、制御はステップ６２５に移り、その間に、別のデバイスイベントを評価する必要性が評価される。この段階で少なくとも一つの追加的デバイスイベントがある場合には、制御がステップ６３０に移り、他のデバイスイベントが選択され、制御がステップ６１０に戻る。
【００４５】
あるいは、ステップ６０５で選択されたフィンガープリントイベントに対応する更なるデバイスイベントがない場合には、選択されたイベントが、ステップ６３５で評価される。選択されたイベントが充足される場合には、制御はステップ６４０に移り、フィンガープリント中に更なるイベントがあるかどうかを決定する。ついで、可能ならば、ステップ６４５中に他のイベントが選択され、制御はステップ６１０に戻る。そうでない場合には、制御はステップ６５０に移り、調べられているメッセージストリームまたはイベントデータと、フィンガープリントとのマッチングが成功したとのマーク付けがされる。ついで、本方法が完了する。直ちに認識できるように、本方法は、リアルタイムで解析されないメッセージストリームまたはシミュレーションによって生成するメッセージストリームを含め、メッセージストリームを解析するのに適している。
【００４６】
予想イベントは、プラットフォームと分析機との間で異なり得る。冗長エラーディテクタ１３０の好ましいインプリメンテーションは、（ｉ）反復試験イベントおよび（ｉｉ）デバイスイベントの二種類のイベントを主に評価する。これは、図７の好ましい例示的実施形態に示されている。
【００４７】
ステップ７００中、メッセージが、監視されているメッセージトラフィックの一部として受け取られる。ステップ７０５中、このメッセージは、（適用できる場合にはＲＥＤによって維持された）デバイス状態情報の記述を更新するのに用いられる。好ましい実施形態では、ＲＥＤが、関心の対象であるそれぞれのデバイスの、ＲＥＤにより監視されるメッセージトラフィックに基づく状態を維持する。デバイス状態の更新に帰着する全てのメッセージが、関連したフィンガープリントの一部であり得るわけではない点に留意する必要がある。
【００４８】
次に、デバイスイベントのテストに受け取りメッセージが使用される。ステップ７１０中に、デバイスイベントが選択される。デバイスイベントは、好ましくは、構成仕様中に指定される。しかしながら、デバイスイベントは、フィンガープリントを生成させる場合のように検査プロトコル情報と併合されるわけではない。その代わりに、デバイス状態を独立に評価するためにデバイスイベントが使用される。デバイスイベントは、関心の対象であるイベントが生じた時のデバイスの状態を検証する。（テスト読み取りの直前および直後のデバイス状態の比較によってチェックされる）デバイスイベントの失敗は、疑わしい反復試験を識別することになり得る。
【００４９】
制御は、ステップ７１０から決定ステップ７１５に移り、決定ステップ７１５の間に、選択されたデバイスイベントが充足されることを確実なものとするためのメッセージを考慮して、選択されたデバイスイベントがテストされる。イベントが充足されない場合、制御はステップ７２０に移り、反復試験を疑わしいものとしてマーク付けする。あるいは、イベントが充足される場合には、制御はステップ７２５に移り、ステップ７２５の間に、別のデバイスイベントを評価する必要性が評価される。この段階で、少なくとも一つの追加的デバイスイベントがある場合には、制御はステップ７３０に移り、他のデバイスイベントが選択され、制御はステップ７１５に戻る。
【００５０】
あるいは、更なるデバイスイベントがない場合には、ステップ７３５中、対応するフィンガープリントからイベントが選択される。選択されたイベントは、ステップ７４０で、メッセージを考慮して評価される。選択されたイベントが充足される場合には、制御はステップ７４５に移り、フィンガープリントに更なるイベントがあるかどうかを決定する。ついで、もし可能ならば、ステップ７５０中、もう一つのイベントが選択され、制御はステップ７４０に戻る。そうでない場合には、制御はステップ７５５に移り、メッセージストリームまたはイベントデータが検討され、フィンガープリントのマッチングに成功したとのマーク付けがされる。ついで、本方法が終了する。直ちに認識されるように、本方法は、リアルタイムで解析されないメッセージストリームやシミュレーションで生成したメッセージストリームを含むメッセージストリームを解析するのに適している。
【００５１】
〔反復試験イベント〕
好ましい実施形態における反復試験イベントの若干の例は次の通りである。
MicroSlide PM Replicateは、Potentimetric MicroSlide反復試験の処理に必要な一連の重要なイベントである。MicroSlide PM Replicateの一例には、好ましくは、以下のような多数のイベントが含まれる。
イベント＃１：液吸引コマンド、
イベント＃２：液吸引応答、
イベント＃３：スライドサプライカート押し込みコマンド、
イベント＃４：スライドサプライカート押し込み応答、
イベント＃５：カートからのスライド分配コマンド、
イベント＃６：カートからのスライド分配応答、
イベント＃７：スライドへのサンプル分配コマンド、
イベント＃８：スライドへのサンプル分配応答、
イベント＃９：スライドへの分配コマンド、
イベント＃１０：スライドへの分配応答、
イベント＃１１：リングへのスライドのプッシュコマンド、
イベント＃１２：リングへのスライドのプッシュ応答、
イベント＃１３：電位計読み取りコマンド、および、
イベント＃１４：電位計読み取り応答。
【００５２】
それぞれのイベントには、指定されたパラメータによって記述されているように、いくつかのコンディションが合致することが要求される。たとえば、イベント＃１１： PMリングへのスライドのプッシュコマンドでは、ステップの始まりから指定された時間幅内にイベントが開始されることをテストすることが要求される。その他のイベント、たとえばイベント＃１０は、「成功」をテストすることだけがパスの要件である。反復試験イベントの、更なる、網羅的でない例には、次のものが含まれる。
【００５３】
MicroSlide CM Replicate Incubating in the Outer Ringは、CM Rate Incbatorの外部リング中、主要なインキュベーション時間中に行われるColormetric or Rate MicroSlide反復試験を処理するのに必要な一連の重要なイベントである。
【００５４】
MicroSlide CM Replicate Incubating in the Inner Ringは、CM Rate Incbatorの内部リング中、主要なインキュベーション時間中に行われるColormetric or Rate MicroSlide反復試験を処理するのに必要な一連の重要なイベントである。
【００５５】
MicroSlide IR Replicateは、ImmunoRate MicroSlide反復試験を処理するのに必要な一連の重要なイベントである。
【００５６】
MicroTip Reagent Addition Stepは、MicroTip反復試験中、試薬がキュベットに加えられるステップを処理するのに必要な一連の重要なイベントである。
【００５７】
MicroTip Sample Addition Stepは、MicroTip反復試験中、生のサンプルがキュベットに加えられるステップを処理するのに必要な一連の重要なイベントである。
【００５８】
MicroTip Diluted Sample Addition Stepは、MicroTip反復試験中、希釈されたサンプルがキュベットに加えられるステップを処理するのに必要な一連の重要なイベントである。
【００５９】
MicroTip Read Stepは、MicroTip反復試験中、光度計を用いてキュベットを読み取るステップを処理するのに必要な一連の重要なイベントである。
【００６０】
MicroWell 1st Well Pretreatment Stepは、MicroWell反復試験中、生のサンプルが前処理ウエルに加えられるステップを処理するのに必要な一連の重要なイベントである。
【００６１】
MicroWell Not 1st Well Pretreatment Stepは、MicroWell反復試験中、希釈されたサンプルが前処理ウエルに加えられるステップを処理するのに必要な一連の重要なイベントである。
【００６２】
MicroWell 1st Well Dilution Stepは、MicroWell反復試験中、生のサンプルが希釈ウエルに加えられるステップを処理するのに必要な一連の重要なイベントである。
【００６３】
MicroWell Not 1st Well Pretreatment Stepは、MicroWell反復試験中、希釈されたサンプルが希釈ウエルに加えられるステップを処理するのに必要な一連の重要なイベントである。
【００６４】
MicroWell Reagent Addition Step To Middle Ring Wellは、MicroWell反復試験中、試薬が前処理ウエルまたは希釈ウエルに加えられるステップを処理するのに必要な一連の重要なイベントである。
【００６５】
MicroWell Reagent Addition Step To Outer Ring Wellは、MicroWell反復試験中、反応ウエルステップを処理するのに必要な一連の重要なイベントである。
【００６６】
MicroWell 1st Well Sample Stepは、MicroWell反復試験中、生のサンプルが反応ウエルに加えられるステップを処理するのに必要な一連の重要なイベントである。
【００６７】
MicroWell Not 1st Well Sample Stepは、MicroWell反復試験中、希釈されたまたは前処理されたサンプルが反応ウエルに加えられるステップを処理するのに必要な一連の重要なイベントである。
【００６８】
MicroWell Preliminary Wash Stepは、MicroWell反復試験中、反応ウエルがその予備ウエル洗浄を受けるステップを処理するのに必要な一連の重要なイベントである。
【００６９】
MicroWell Final Wash Stepは、MicroWell反復試験中、反応ウエルがその最終的なウエル洗浄を受け、照度計を用いて読み取られるステップを処理するのに必要な一連の重要なイベントである。
【００７０】
Sample Integrity Stepは、サンプルのSample Integrity読み取りを処理するのに必要な一連の重要なイベントである。
【００７１】
〔デバイスイベント〕
デバイスイベントの若干の好ましい例には、MicroSlide電位計のイベントが含まれる。サンプルスライドとは独立して、電位計は、参照スライドを読み取り、指定期間内に参照スライドの少なくとも一つの読み取りに確実に成功する。フィンガープリントに含まれる複数の重要なイベントを指定することで、この要件が満たされる。指定された重要なイベントを持つその他のデバイスには、インキュベーションリングまたは領域、コンベヤまたはリング搬送機構、シャトル、計量装置、計量における制御、リフレクトメータ、スライド供給品、バッファ・リング、移動アーム、ＳＴＡＴレーン、試薬供給品、洗浄ステーション、ブレードインサータ、ブレードダンパ−、光度計等が含まれ得る。このリストは網羅的なものではない。
【００７２】
生成したフィンガープリントを用いて、冗長エラーディテクタ１３０は、メッセージトラフィックをレビューし、メッセージトラフィックから欠如している、フィンガープリントによって要求されたイベント形態における相違点を識別する。それぞれの受け取りメッセージについて、ＲＥＤは、関連のアクションを実施するために、好ましくは、図７に例示されるように、反復試験イベントとデバイスイベントとをフィンガープリントでマッチさせる。
【００７３】
図３のステップ３４０では、ステップ３３０の反復試験チェックコマンドの受け取りに応じて、冗長エラーディテクタ１３０は、反復試験プレビューコマンドのタイムスタンプと反復試験チェックコマンドとの間のタイムスタンプでメッセージをレビューすることによって、相違点の識別サーベイを完了する。このような相違したイベントに対応する結果には、疑わしいものとのフラッグが立てられる。
【００７４】
ステップ３５０中、冗長エラーディテクタ１３０は、相違点識別の結果をポストプロセッシングバッファ１５０に送る。これは、メッセージと情報とをポストプロセッサ１５５へ渡すためのメカニズムである。ステップ３６０で結果が疑わしいものと決定された場合、冗長エラーディテクタ１３０は、ステップ３７０中においても、テスト結果を疑わしいものとして、対応するコンディションの記録を付けて識別する。最後に、ステップ３８０中、Complete Replicateコマンドが受け取られる。疑わしい結果は、好ましくは、ポストプロセッサ１５５によってリリースされず、当然ながら臨床診断分析機によってリリースされない。必要ならば、ステップ３９０中、隔離された資源がリリースされる。
【００７５】
冗長エラーディテクタは、非リアルタイムモードで、メッセージデータにアクセスし、相違点を識別するために、エミュレータファイルまたはデータロギングファイルをレビューすることもできる。この能力は、経済的なやり方でＲＥＤ自体のより新しいバージョンを検証することを含むソフトウェアの検証およびテストに有用である。図２が、そのようなテストのための好ましい構成を示す一方、図４は、好ましい実施形態におけるこれらのステップのいくつかを例示する。
【００７６】
図４のステップ４００中、スクリプトファイルであるＲＥＤスクリプトファイル２００は、ＲＥＤバッファ２２０の規則正しいエントリを生じるために、冗長エラーディテクタドライバ２１０により用いられる。ＲＥＤスクリプトファイル２００は、（典型的にはテストにおける支援のための）いくつかのコマンドと結合された、臨床診断分析機の例示操作におけるメッセージの記録である。冗長エラーディテクタ２３０は、ＲＥＤバッファ２２０を処理し、構成ファイルと検査データベース２４０とを用いて、ダイナミックに生成させられたフィンガープリントにマッチさせる。冗長エラーディテクタ２３０による処理の結果は、PostProcバッファ２５０に送信され、今度は、それが、テストソフトウェアのパフォーマンスを評価する冗長エラーディテクタドライバ２１０に戻り、そして、これがそのデバッギングへと移行し得る。テストソフトウェアは、好ましくは冗長エラーディテクタ２３０である。あるいは、テストソフトウェアは、ＲＥＤスクリプトファイル２００で反映されるデータを生み出すための、例示操作において使用されるモジュールであり得る。別の実施形態におけるＲＥＤスクリプトファイル２００で反映されるデータは、図１で示されるように生成したエミュレータファイルからのもの、あるいは、調査中の分析機におけるエラーを識別するために調査されているデータロガーファイルからのものでさえある。冗長エラーディテクタドライバ２１０は、これら全ての潜在的に異なるフォーマットを、冗長エラーディテクタ２３０によるアクションに適したものに変換する役割を果たす。
【００７７】
他の一態様では、ＲＥＤは、ほとんど修正を必要とせず、サブシステムの入出力トラフィックを大部分不変のままにするので、既存の分析機に容易に組み入れられる。これは、冗長エラーディテクタ２３０が、臨床診断分析機の内部のメッセージトラフィックにあまり影響を及ぼすことなく接続される、図１，２から直ちに理解される。ＲＥＤは、たとえば、全ての結果をリリースするようにダイナミックに構成され得ることが好ましい。このようにして、異常が発見されたとき、ＲＥＤによって課せられるペナルティを制御し得るかまたは構成し得ることが好ましい。
【００７８】
効率的なエラー検出システムの目標には、誤った結果のリリースを防止するために、エラーをタイムリーに発見することが含まれる。構成ファイルは、ＲＥＤによって実施されるチェックを定義する。このようにして、それぞれの検査モデルタイプについて、ＲＥＤが、結果の品質にとって重大なイベント；結果の品質に有害なイベント；それぞれのイベントについて、もし存在するとすれば、合格／失敗／警報標準；および、要求されるサンプルの一貫性チェック、についてチェックすることが好ましい。
【００７９】
ほとんどの場合、ＲＥＤによってチェックされるイベントは、関心の対象である臨床診断分析機やその他のシステムの、ルーチンのコマンド応答デザインによってもチェックされる。分析機のパフォーマンスへのＲＥＤの影響が小さいことに鑑み、ＲＥＤの実行は、許容し得る結果のリリースをあまり遅らせない。よい結果の予測をＲＥＤが妨げる可能性を減少させる努力における有用なガイドラインには、チェックされるイベントの数を要求されたイベントだけに制限すること；パラメータの有効な範囲を全てのシナリオをカバーするように正しく設定すること；および、ＲＥＤモジュールが故障していると思われるときでも、ＲＥＤモジュールが結果に失敗し得ることを防止するような構成にすること、が含まれる。
【００８０】
さらに、ＲＥＤモジュール自体が、全てのチェックが予想されるシナリオで正しく実行されていることを検証するためにテストされる。たとえば、これは、図２で提示されるシミュレーション戦略によって実行され得る。
【００８１】
〔別のエラー検出戦略〕
ＲＥＤは、潜在的に誤って報告された結果を検出し、防止する。所望の品質水準を達成するための好ましいアプローチとして、テストとコードレビューとに主に依存するのが慣例である。しかしながら、ＲＥＤは、複雑なモジュールをテストする場合、必然的に困難であり、資源集約的な作業であるコードレビューの必要性を大きく減らす。
【００８２】
クローズループチェックはもう一つの戦略であるが、かなりの開発費用、統合費用および検証費用を招来する。さらに、問題のモジュール内で実施されるクローズループチェックは、全ての状況で信頼できるというわけではない。モジュール内で実行されるクローズループチェックは、テストされているモジュールとは独立していないことがしばしばある。
【００８３】
ＲＥＤのアーキテクチャは、多くの異なるタイプの入力を受け入れることができる。２つの明らかな選択は、サブシステムＩ／Ｏ（サブシステムコマンド、応答および非同期メッセージから構成）およびデータロガーイベントである。
【００８４】
好ましい一実施形態では、ＲＥＤは、要請されたチェックを実施し、その状態（合格、失敗または、オプションで警告レベル）を示す応答を返す。ＲＥＤは、それぞれの検査モデルが、異なるプロトコルステップを持ち、したがって、異なる完全性チェックを有することを認識する。反復試験に関連するチェックのカテゴリーはリストされている。それぞれのカテゴリーは、反復試験のプロトコル情報に依存してダイナミックに変えられ得る予想イベントの表と相互に関連付けられている。このようにして、ＲＥＤは、分析機等の複合システムでメッセージトラフィックのリアルタイム処理に固有の複雑さから独立したテストを提供することによって、分析機のために潜在的にコーディングを単純化し、結果について改善された信頼性を与える。
【００８５】
図５はＲＥＤの機能を例示する。典型的には、メッセージと情報とを転送するためのメカニズム（ここでは、コマンドとデータとを冗長エラーディテクタ機能５１０に提供するＲＥＤバッファ５００）がある。好ましい一実施形態では、冗長エラーディテクタ機能５１０には、構成ファイル、フィンガープリントおよびその生成能力、フィンガープリントをＲＥＤバッファ５００からのメッセージと比較する能力、結果報告能力ならびに資源割り当ておよびリリース機能が含まれる。検査データベース５２０は、冗長エラーディテクタ機能５１０にアクセスし得る。このアクセスは、フィンガープリントを生成するのに有用である。
【００８６】
当業者ならば、この開示が、その教示内容または精神から逸脱することなく、多くのバリエーションおよび代替的実現方法を許容するものであることを認識するであろう。たとえば、イベントのフィンガープリントを用いて評価される一貫性についてのそれぞれの出力の評価に基づいて、臨床分析機以外の複合システムが、ここに記載されたような冗長エラーテストにより利益を得るであろう。添付の請求の範囲には、このような多くの修正が含まれる。さらに、ここで説明され、引用されたそれぞれの引用文献は、参照によってここにその全体が取り入れられる。
【図面の簡単な説明】
【００８７】
【図１】冗長エラーディテクタに連結された臨床診断分析機における処理モジュールの概略図である。
【図２】冗長エラーディテクタを使用するソフトウェアテスト配置の概略図である。
【図３】冗長エラー検出機能および、冗長エラー検出機能の内部にあるまたは冗長エラー検出機能と密接に対話する種々の構成要素（これらは更に統合し得る）を例示する図である。
【図４】冗長エラーディテクタを用いてエラーをチェックする方法を例示する図である。
【図５】冗長エラーディテクタを用いてソフトウェアを評価し、デバッグする方法を例示する図である。
【図６】冗長エラー検出機能および、冗長エラー検出機能の内部にあるまたは冗長エラー検出機能と密接に対話する種々の構成要素（これらは更に統合し得る）を例示する図である。
【図７】冗長エラー検出機能によって維持されているデバイス状態を更新しつつ、デバイスイベントと反復試験のイベントについてのメッセージストリームをチェックする冗長エラー検出機能の例を示す図である。
【特許請求の範囲】
【請求項１】
臨床診断分析機における疑わしい試験結果を検出するための、前記臨床診断分析機のプロセッサで実行可能なモジュールにおいて、
当該モジュールが、
サブシステムコマンド、コマンド応答および非同期メッセージを含むメッセージを受け取るためのメカニズムと、
反復試験についてテストされるべき予想イベントのフィンガープリントであって、当該フィンガープリントは、少なくとも一つの構成情報とプロトコル情報とから生成され、当該プロトコル情報は、前記反復試験によって要求される検査に関する詳細を含む、フィンガープリントと、
前記受け取ったメッセージと前記フィンガープリントとの間の比較を完了するための命令と、
前記比較の結果を報告するための命令と、
を含む、モジュール。
【請求項２】
請求項１に記載のモジュールにおいて、
前記反復試験のためのプレビューコマンドの受け取りに応じて前記フィンガープリントを生成するための命令、
を更に含んでいる、モジュール。
【請求項３】
請求項１に記載のモジュールにおいて、
チェックコマンドに応じて前記フィンガープリントと受け取りメッセージとの比較を完了するための命令、
を更に含んでいる、モジュール。
【請求項４】
請求項１に記載のモジュールにおいて、
前記反復試験のための前記プレビューコマンドの受け取りに応じて隔離された全ての資源を、完了命令の受け取りに応じてリリースするための命令、
を含む、モジュール。
【請求項５】
請求項１に記載のモジュールにおいて、
前記比較の結果をリリースするための前記命令をダイナミックに再構成するための命令、
を含む、モジュール。
【請求項６】
請求項１に記載のモジュールにおいて、
前記結果が疑わしいとの決定に応じてコンディションの記録を付けるための命令、
を含む、モジュール。
【請求項７】
請求項１に記載のモジュールにおいて、
前記検査結果に警告のフラグを立てることに応じてコンディションの記録を付けるための命令、
を含む、モジュール。
【請求項８】
請求項１に記載のモジュールにおいて、
前記反復試験のためのプレビューコマンドの受け取りに応じて、サブシステムに対応するイベントを生成するための命令であって、当該生成が、前記構成情報に基づくものである、命令、
を更に含む、モジュール。
【請求項９】
臨床診断分析機におけるソフトウェアモジュールをテストするための品質管理法において、
冗長エラーディテクタへの引き渡しに適した、サブシステムコマンド、コマンド応答および非同期メッセージを生成するステップと、
前記冗長エラーディテクタを用いて、不一致点について、前記生成したサブシステムコマンド、コマンド応答および非同期メッセージをレビューするステップと、
不一致点の検出に応じて、前記ソフトウェアモジュールをデバッグするステップと、
を含む、方法。
【請求項１０】
請求項９に記載の方法において、
前記サブシステムコマンド、コマンド応答および非同期メッセージが、前記臨床診断分析機の例示操作におけるメッセージの記録に加えて、少なくとも一つのコマンドを含む少なくとも一つのスクリプトファイルを用いる前記臨床診断分析機のパフォーマンスのシミュレーションにおいて生成される、方法。
【請求項１１】
請求項１０に記載の方法において、
前記ソフトウェアモジュールが、前記メッセージの記録を生成するために、前記臨床診断分析機の前記例示操作で使用される、方法。
【請求項１２】
請求項９に記載の方法において、
前記冗長エラーディテクタが、構成ファイルと検査データベースとを使用して、前記少なくとも一つのスクリプトファイルに少なくとも一つの反復試験のためのフィンガープリントを生成する、方法。
【請求項１３】
請求項９に記載の方法において、
前記ソフトウェアモジュールが、テスト冗長エラーディテクタである、方法。
【請求項１４】
請求項９に記載の方法において、
前記ソフトウェアモジュールが、テスト冗長エラーディテクタではない、方法。
【請求項１５】
請求項９に記載の方法において、
システムがいくつかのソフトウェアモジュールをテストすることによってテストされる、方法。
【請求項１６】
臨床診断分析機による疑わしい結果のリリースを防止するための方法において、
当該方法が、
反復試験のための反復試験プレビューコマンドを受け取るステップ、
前記反復試験の冗長エラーチェックのための資源を割り当てるステップ、
少なくとも一つの構成情報とプロトコル情報とを用いて、前記反復試験のために要求されるイベントのフィンガープリントを生成するステップであって、当該フィンガープリントが、前記反復試験のための前記プロトコル情報に従って実施された前記イベントより少ない数のイベントを有する、ステップ、
前記反復試験の実行に対応するメッセージを前記フィンガープリントと比較するステップ、
前記比較の結果を送信するステップ、および、
前記反復試験に対応するコンディションの記録を付けるステップ、
を容易にすることを含む、方法。
【請求項１７】
請求項１６に記載の方法において、
前記構成情報が、eXtensible Markup Languageでコード化される、方法。
【請求項１８】
請求項１６に記載の方法において、
コンディションの記録を付けることが、特定のイベントに関するデータを特定のフォーマットでログファイルに書き込むことを含む、方法。
【請求項１９】
請求項１６に記載の方法において、
前記反復試験の失敗に対応する前記結果が、前記臨床診断分析機に当該結果をリリースさせないようにする、方法。
【請求項１】
臨床診断分析機における疑わしい試験結果を検出するための、前記臨床診断分析機のプロセッサで実行可能なモジュールにおいて、
当該モジュールが、
サブシステムコマンド、コマンド応答および非同期メッセージを含むメッセージを受け取るためのメカニズムと、
反復試験についてテストされるべき予想イベントのフィンガープリントであって、当該フィンガープリントは、少なくとも一つの構成情報とプロトコル情報とから生成され、当該プロトコル情報は、前記反復試験によって要求される検査に関する詳細を含む、フィンガープリントと、
前記受け取ったメッセージと前記フィンガープリントとの間の比較を完了するための命令と、
前記比較の結果を報告するための命令と、
を含む、モジュール。
【請求項２】
請求項１に記載のモジュールにおいて、
前記反復試験のためのプレビューコマンドの受け取りに応じて前記フィンガープリントを生成するための命令、
を更に含んでいる、モジュール。
【請求項３】
請求項１に記載のモジュールにおいて、
チェックコマンドに応じて前記フィンガープリントと受け取りメッセージとの比較を完了するための命令、
を更に含んでいる、モジュール。
【請求項４】
請求項１に記載のモジュールにおいて、
前記反復試験のための前記プレビューコマンドの受け取りに応じて隔離された全ての資源を、完了命令の受け取りに応じてリリースするための命令、
を含む、モジュール。
【請求項５】
請求項１に記載のモジュールにおいて、
前記比較の結果をリリースするための前記命令をダイナミックに再構成するための命令、
を含む、モジュール。
【請求項６】
請求項１に記載のモジュールにおいて、
前記結果が疑わしいとの決定に応じてコンディションの記録を付けるための命令、
を含む、モジュール。
【請求項７】
請求項１に記載のモジュールにおいて、
前記検査結果に警告のフラグを立てることに応じてコンディションの記録を付けるための命令、
を含む、モジュール。
【請求項８】
請求項１に記載のモジュールにおいて、
前記反復試験のためのプレビューコマンドの受け取りに応じて、サブシステムに対応するイベントを生成するための命令であって、当該生成が、前記構成情報に基づくものである、命令、
を更に含む、モジュール。
【請求項９】
臨床診断分析機におけるソフトウェアモジュールをテストするための品質管理法において、
冗長エラーディテクタへの引き渡しに適した、サブシステムコマンド、コマンド応答および非同期メッセージを生成するステップと、
前記冗長エラーディテクタを用いて、不一致点について、前記生成したサブシステムコマンド、コマンド応答および非同期メッセージをレビューするステップと、
不一致点の検出に応じて、前記ソフトウェアモジュールをデバッグするステップと、
を含む、方法。
【請求項１０】
請求項９に記載の方法において、
前記サブシステムコマンド、コマンド応答および非同期メッセージが、前記臨床診断分析機の例示操作におけるメッセージの記録に加えて、少なくとも一つのコマンドを含む少なくとも一つのスクリプトファイルを用いる前記臨床診断分析機のパフォーマンスのシミュレーションにおいて生成される、方法。
【請求項１１】
請求項１０に記載の方法において、
前記ソフトウェアモジュールが、前記メッセージの記録を生成するために、前記臨床診断分析機の前記例示操作で使用される、方法。
【請求項１２】
請求項９に記載の方法において、
前記冗長エラーディテクタが、構成ファイルと検査データベースとを使用して、前記少なくとも一つのスクリプトファイルに少なくとも一つの反復試験のためのフィンガープリントを生成する、方法。
【請求項１３】
請求項９に記載の方法において、
前記ソフトウェアモジュールが、テスト冗長エラーディテクタである、方法。
【請求項１４】
請求項９に記載の方法において、
前記ソフトウェアモジュールが、テスト冗長エラーディテクタではない、方法。
【請求項１５】
請求項９に記載の方法において、
システムがいくつかのソフトウェアモジュールをテストすることによってテストされる、方法。
【請求項１６】
臨床診断分析機による疑わしい結果のリリースを防止するための方法において、
当該方法が、
反復試験のための反復試験プレビューコマンドを受け取るステップ、
前記反復試験の冗長エラーチェックのための資源を割り当てるステップ、
少なくとも一つの構成情報とプロトコル情報とを用いて、前記反復試験のために要求されるイベントのフィンガープリントを生成するステップであって、当該フィンガープリントが、前記反復試験のための前記プロトコル情報に従って実施された前記イベントより少ない数のイベントを有する、ステップ、
前記反復試験の実行に対応するメッセージを前記フィンガープリントと比較するステップ、
前記比較の結果を送信するステップ、および、
前記反復試験に対応するコンディションの記録を付けるステップ、
を容易にすることを含む、方法。
【請求項１７】
請求項１６に記載の方法において、
前記構成情報が、eXtensible Markup Languageでコード化される、方法。
【請求項１８】
請求項１６に記載の方法において、
コンディションの記録を付けることが、特定のイベントに関するデータを特定のフォーマットでログファイルに書き込むことを含む、方法。
【請求項１９】
請求項１６に記載の方法において、
前記反復試験の失敗に対応する前記結果が、前記臨床診断分析機に当該結果をリリースさせないようにする、方法。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【公開番号】特開２０１０−１４７１１（Ｐ２０１０−１４７１１Ａ）
【公開日】平成２２年１月２１日（２０１０．１．２１）
【国際特許分類】
【外国語出願】
【出願番号】特願２００９−１５４６９１（Ｐ２００９−１５４６９１）
【出願日】平成２１年６月３０日（２００９．６．３０）
【出願人】（５００１７４６２７）オーソ・クリニカル・ダイアグノスティックス・インコーポレーテッド (5)
【Ｆターム（参考）】
【公開日】平成２２年１月２１日（２０１０．１．２１）
【国際特許分類】
【出願番号】特願２００９−１５４６９１（Ｐ２００９−１５４６９１）
【出願日】平成２１年６月３０日（２００９．６．３０）
【出願人】（５００１７４６２７）オーソ・クリニカル・ダイアグノスティックス・インコーポレーテッド (5)
【Ｆターム（参考）】
[ Back to top ]