JP7231674B2 - 医学的アナライザの状態の推論 - Google Patents

Description

本開示は、少なくとも１つの分析デバイスの状態を推論するためのコンピュータ実装方法、ならびに関連する装置、ネットワークシステム、コンピュータプログラム要素およびコンピュータ可読媒体に関する。

臨床ケア環境において、分析デバイスは、ポイントオブケアにおいて、またはその付近で使用され得る。そのような分析デバイスは、「ポイントオブケア（ＰＯＣ）検査デバイス」と指定される。分析デバイスは、たとえば、検査デバイスの技術的ステータスに関する情報を含有する多種多様な自動通知をセントラルサーバと通信することができる。

ＰＯＣデバイス（分析デバイス）は、たとえば、事象、分析結果、または他のアナライザステータス情報を示す多数の自動化通知をＰＯＣ ＩＴデータ管理システムに送る。

典型的なＰＯＣデバイスは、かなりの数のデバイスメッセージを生成する。結果として、多数のＰＯＣデバイスのステータスに関する情報のコヒーレントな監視は困難であり得る。したがって、そのようなＰＯＣデバイスおよびそれらの管理システムは、さらに改善され得る。

第１の態様によれば、ネットワークを介して少なくとも１つの分析デバイスから受信された少なくとも１つの自動通知に基づく分析デバイスの状態を推論するためのコンピュータ実装方法が提供される。この方法は、
データ処理エージェントにおいて、少なくとも１つの分析デバイスから少なくとも１つの自動通知を受信することと、
データ処理エージェントにおいて、少なくとも１つの自動通知を処理し、それにより、少なくとも１つの分析デバイスからの少なくとも１つの自動通知に基づいて、分析デバイスの１つまたは複数の特性を識別することと、
データ処理エージェントにおいて、１つまたは複数の識別された特性をモデルに適用することによって、少なくとも１つの分析デバイスの状態を推論することと、
データ処理エージェントにおいて、分析デバイスの推論された状態を報告する通知を生成することと
を備える。

この効果は、１つまたは複数の分析デバイスの保守管理状態が正確に追跡され得ることである。分析デバイスの第１のネットワークから集められた情報は、分析デバイスのさらなるネットワークに適用され得る。

さらに、多数の自動通知は、保守管理問題の時宜を得た予測を可能にする通知の傾向またはパターンを識別するために処理され得る。代替として、傾向を見定めるため、または識別が難しいデータ内のパターンについて学習するために、履歴通知のデータベースが後処理され得る。

１つまたは複数の分析デバイスのさらなる保守管理状態は、ある特定の時点で予測または推論され得る。

保守管理スケジュールは、１つまたは複数の分析デバイスの物理的なステータスに対する変更の重要度または緊急性を反映するように生成または更新され得る。

１つまたは複数の分析デバイスのユーザは、グラフィカルユーザインターフェースまたは他の表示手段を介して、分析デバイスの推論された状態を解決するために行うべき活動について勧告され得る。

第２の態様によれば、ネットワークを介して少なくとも１つの分析デバイスから受信された少なくとも１つの自動通知に基づく分析デバイスの状態を推論するためのデータ処理エージェントをホストするように構成された装置が提供される。この装置は、
－ 通信インターフェースと、
－ 通信インターフェースに結合されたプロセッサと、
を備える。

通信インターフェースは、少なくとも１つの分析デバイスから少なくとも１つの自動通知を受信するように構成される。

プロセッサは、少なくとも１つの自動通知を処理し、それにより、少なくとも１つの分析デバイスからの少なくとも１つの自動通知に基づいて、分析デバイスの１つまたは複数の特性を識別するように構成される。

プロセッサは、１つまたは複数の識別された特性をモデルに適用することによって、少なくとも１つの分析デバイスの状態を推論するように構成される。

プロセッサは、分析デバイスの推論された状態を報告する通知を生成するように構成される。

第３の態様によれば、分析デバイス管理のためのシステムであって、
－ 少なくとも１つの分析デバイスと、
－ 第１の態様の方法を実行するように構成された、第２の態様の装置からのデータを処理するためのデータ処理エージェントをホストするように構成された装置と
を備えた、システムが提供される。

第３の態様によるシステムは、ユーザインターフェースを備えたコンピューティング装置と、少なくとも１つの分析デバイス、コンピューティング装置、およびデータ処理エージェントをホストするように構成された装置に通信可能に接続するように構成されたネットワークとをさらに備える。

少なくとも１つの分析デバイスは、複数の通知を生成するように構成され、通信ネットワークは、装置上でホストされるデータ処理エージェントに複数の通知を通信するように構成される。

一実施形態では、少なくとも１つの分析デバイスは、患者からの生体試料を分析するように構成される。

一実施形態では、少なくとも１つの分析デバイスは、医学的状態のバイオマーカを識別するために生体試料を分析するように構成される。

第４の態様によれば、第３の態様による装置を制御するためのコンピュータ可読命令を備えたコンピュータプログラム要素であって、コンピュータ可読命令が、装置のプロセッサによって実行されるとき、第２の態様の方法を実行するように適合される、コンピュータプログラム要素が提供される。

第５の態様によれば、第４の態様のコンピュータプログラム要素を記憶した、またはその上に符号化した、コンピュータ可読媒体または信号が提供される。

第６の態様によれば、ネットワークから受信された複数の自動通知に基づいて、分析デバイスの状態を推論するためのモデルを生成するためのコンピュータ実装方法が提供される。この方法は、
１つまたは複数のネットワーク内で１つまたは複数の分析デバイスから複数の自動通知を受信することであって、複数の自動通知の少なくとも１つのサブセットが、１つまたは複数の分析デバイスのうちの少なくとも１つの少なくとも１つの状態に関連付けられる、複数の自動通知を受信することと、
モデルを生成するためのトレーニングデータとして複数の自動通知を使用してモデルをトレーニングすることであって、モデルが、複数の受信された自動通知と１つまたは複数の分析デバイスのうちの少なくとも１つの少なくとも１つの状態の間の関係を提供する、モデルをトレーニングすることと
を備える。

第７の態様によれば、第６の態様に従って取得された、トレーニングされたモデルを備えたコンピュータ可読データ構造が提供される。

随意の実施形態は、読者が次に参照し得る、本明細書においてさらに論じる、従属請求項において定義される。

本出願において一定の用語が使用され、その形成は、選定された特定の用語によって限定されると解釈すべきではなく、その特定の用語の裏にある一般概念に関すると解釈すべきである。

本明細書で使用される「備える（ｃｏｍｐｒｉｓｅｓ）」、「備える（ｃｏｍｐｒｉｓｉｎｇ）」、「含む（ｉｎｃｌｕｄｅｓ）」、「含む（ｉｎｃｌｕｄｉｎｇ）」、「有する（ｈａｓ）」、「有する（ｈａｖｉｎｇ）」という用語、またはそれらの任意の他の変形態は、非排他的な包括を網羅することが意図される。

「患者試料」および「生体試料」という用語は、当該検体を潜在的に含有し得る材料を指す。患者試料は、血液、唾液、眼内レンズ液、脳脊髄液、汗、尿、便、精液、母乳、腹水、粘液、滑液、腹膜液、羊水、組織、培養細胞などを含む生理液など、何らかの生物学的源から導出され得る。患者試料は、血液から血漿を用意する、粘液、溶菌などを希釈する、など、使用に先立って事前に処理され得る。処理の方法は、濾過、蒸留、濃縮、妨害化合物の不活性化、および試薬の追加を伴い得る。患者試料は、源から取得されると直接使用されてよく、または試料の性質を変えるための前処理に続いて使用されてもよい。いくつかの実施形態では、当初は固体または半固体の生体材料は、好適な液状媒体を用いてその材料を溶解または懸濁することによって液体にされる。いくつかの実施形態では、材料は、ある抗原または核酸を含有すると疑われる。

本明細書で使用する「分析デバイス」という用語は、患者の医学的状態に関する測定値を取得するための任意の装置を包含する。一例では、測定値は、患者試料を取得し、患者試料を自動的にまたは半自動的に処理するために分析デバイスを使用することによって提供され得る。分析デバイスは、そこから患者の医学的状態の評価が行われ得る、処理される試料内の検体の存在を検出し得る。分析デバイスが患者の医学的状態の評価を形成することは必須ではなく、たとえば、分析デバイスによって検出された検体の概要は、さらに考慮するために医学専門家に提供され得る。別の例では、「分析デバイス」は、患者の医学的状態を表すデジタルデータを取得および処理し得る。デジタルデータは、他の分析デバイスからの測定値として、かつ／または画像、ビデオ、もしくは音声データとして受信され得る。

一例では、分析デバイスは、患者の医学的状態に関する測定値を提供するために患者から取得される生体（医学的）試料の自動アナライザであり得る。たとえば、分析デバイスは、測定値を提供するために、光吸収、蛍光、電位、または反応の他の物理的もしくは化学的特性を測定し得る。多くの場合、そのような患者試料は、分析検査が行われる前に処理される。患者から採取された血液は、たとえば、血清を取得するために遠心分離機にかけられるか、または血漿を取得するために抗凝血剤で処理される。

分析デバイスによる検体検査は、一例として、患者試料内の検体の存在および／または濃度を決定する目標を有する。「検体」という用語は、存在および／または濃度に関する情報の対象となる物質に対する一般用語である。検体の例は、たとえば、ブドウ糖、凝固パラメータ、内因性タンパク質（たとえば、心筋から放出されるタンパク質）、代謝物、核酸などである。

患者試料を分析するように構成された分析デバイスによる検体検査は、一例として、患者試料内の検体の存在／または濃度を決定する目標を有する。「検体」という用語は、存在および／または濃度に関する情報の対象となる物質に対する一般用語である。検体の例は、たとえば、ブドウ糖、凝固パラメータ、内因性タンパク質（たとえば、心筋から放出されるタンパク質）、代謝物、核酸などである。しかしながら、たとえば、化学反応のカメラセンサーによって取得されたデジタルデータ、または患者の皮膚の画像の取得および処理は、分析検査のもう１つの例である。

「分析デバイス」が、患者の医学的状態に関するデータを取得するために必要とされるすべてのステップを自動的に実行することは必須ではない。たとえば、いくつかの分析デバイスは、検査を実行するのに先立って、試薬をアンプル内の試料の中にピペットで移すことまたはスライドを取り付けることをＰＯＣオペレータに要求することがある。他の場合には、「分析デバイス」は、オペレータの介入なしに、試料分析のすべてのステップを自動的に実行し得る。他の場合には、「分析デバイス」は、ユーザに、分析の段階において手動で介入するように催促し得る。

代替として、分析デバイスは、患者から測定値を捕捉するように構成されたセンサーを備えたハンドヘルドまたはモバイルデバイスである。

「分析デバイス」は、たとえば、ＵＳＢ（商標）、ＷｉＦｉ（商標）、またはＢｌｕｅｔｏｏｔｈ（商標）接続を介して、スマートフォン、タブレットＰＣ、スマートウォッチ、または他のコンピューティングデバイスに通信可能に接続され得るポータブルアプライアンスを備え得る。そのようなポータブルアプライアンスは、センサーのうちの１つまたはセンサーの組合せから取得されるデータを分析することによって、分析検査を実行するように構成され得る。

測定値は、たとえば、スマートフォンのセンサーから収集されたデータを備え得る。単なる例として、測定値は、患者の腫瘍の程度を特徴付ける、スマートフォン加速度計によって取得されたデータであり得る。測定値は、スマートフォンカメラを使用して取得された皮膚の状態の写真であり得る。測定値は、スマートフォンマイクロフォンを使用して取得された録音であり得る。測定値は、たとえば、患者の歩き方を評価するためにスマートフォンを使用して取得されたビデオであり得る。このように、スマートフォン、タブレットＰＣ、または他のコンピューティングデバイスの標準的な特徴が分析デバイスの機能を実行し得る。スマートフォン、または他のコンピューティングデバイス上で実行されるアプリケーションは、そのようなデータを取得し、そのデータをデータ処理エージェントに通信することが可能である。スマートフォンに通信可能に結合された外部デバイスを介して、一連のより幅広い測定値が取得され得る。たとえば、外部デバイスは、デジタル温度計を備え得る。

本明細書で使用される「患者の健康パラメータ」という用語は、１つまたは複数の検体に対する患者試料の分析によって、またはセンサーのうちの１つまたはセンサーの組合せから取得されるデータの分析によって、測定可能であるかまたは示される、患者の生理機能の何らかの態様を包含する。

「分析デバイス」という用語は、患者の病棟の近傍で使用可能であり得るように構成され得、その場合、分析デバイスは、「ポイントオブケア（ＰＯＣ）デバイス」と呼ばれることが多い。しかしながら、本明細書で論じる技法は、ＰＯＣデバイスに限定されず、メッセージデータを生成する多くのタイプの検査室分析システムに適用され得る。

本明細書で使用される「ポイントオブケア」（ＰＯＣ）または「ポイントオブケア環境」という用語は、限定はしないが、病院、救急部門、集中治療室、プライマリケア設定、医療センター、患者の自宅、診療所、薬局、または救急現場を含めて、医療検査および／または治療など、医療サービスまたは医療関係サービスが提供される、患者のケア現場のロケーションまたはその付近を意味するように定義される。

ベッドサイド検査またはポイントオブケア検査の分野において、検査は、典型的には、看護師、医療スタッフ、または医師によって実行されるが、本明細書で「オペレータ」と総称される薬剤師によっても実行される。しかしながら、必要とされる証明書を保有する者は誰でもオペレータであり得る。ポイントオブケアコーディネータＰＯＣＣは、同時に、ＰＯＣアナライザのオペレータであり得、ＰＯＣアナライザのオペレータも、同時に、ポイントオブケアコーディネータＰＯＣＣ、したがって、ポータブルコンピューティングデバイスのユーザであり得る。

本明細書で使用される「ポイントオブケア検査」（ＰＯＣＴ）という用語は、患者の医学的状態に関する情報を取得するために、上記で定義されたような分析デバイスによって提供される１つまたは複数のデータ項目の分析を包含する。ＰＯＣＴは、可搬、ポータブル、およびハンドヘルド器具の使用により達成されることが多いが、ハンドヘルドデバイスが利用可能でないとき、小型ベンチアナライザまたは固定機器も使用されてよく、目標は、患者のロケーションでまたはその（比較的）付近で（比較的）短い時間期間に、患者試料を収集し、分析データを取得することである。

一例では、ＰＯＣＴは、グルコース、凝固、血液ガス、尿検査、心臓および分子検査のための（限定はしないが）アナライザなど、様々なＰＯＣ分析デバイス（ＰＯＣアナライザ）を使用して実行される。結果は、ＰＯＣアナライザ上で直接閲覧され得るか、またはＰＯＣＴシステムに送られ、中央検査室の結果とともに検査室情報システム内に、または画像結果と一緒に病院情報システム内に表示され得る。

したがって、分析デバイスは、（限定はしないが）血糖検査、凝固検査、血液ガスおよび電解質分析、尿検査、心臓マーカー分析、ヘモグロビン診断、感染病検査、コレステロールスクリーニングまたは核酸検査（ＮＡＴ）など、検査を実行するために、ポイントオブケア環境において使用され得る。結果は、ポイントオブケアアナライザ上で直接閲覧され得るか、またはポイントオブケア検査システムに送られ、中央検査室の結果とともに検査室情報システム内に、または画像結果と一緒に病院情報システム内に表示され得る。「患者の健康パラメータ」という用語は、随意に、患者の生理機能の何らかの態様に関する情報を提供する画像またはビデオなどのデジタルデータを包含する。

一例では、ＰＯＣＴは、患者の皮膚の一部分の写真、患者の歩行のビデオ、または患者が音をたてる音声試料など、デジタルデータを取得することによって実行される。

一例では、ＰＯＣＴは、あるロケーションから別のロケーションに容易に移動され得る任意の電子アプライアンス、具体的には、限定はしないが、セルラー電話、衛星電話、ページャ、携帯情報端末（「ＰＤＡ」）、スマートフォン、ナビゲーションデバイス、スマートブックもしくはリーダ、前述のデバイスの組合せ、タブレットコンピュータまたはラップトップコンピュータを含めて、任意のハンドヘルドバッテリー駆動式モバイルアプライアンスを包含する「ポータブルコンピューティングデバイス」を使用して、実行される。

本明細書で使用される「ポイントオブケアデバイス管理システム」（ＰＯＣ－ＤＭＳ）という用語は、ＰＯＣコーディネータがＰＯＣデバイスを管理することを可能にするために、または保守管理員が器機を監視することを可能にするために、コンピュータネットワークを介して１つまたは複数のＰＯＣデバイスと通信し、１つまたは複数のＰＯＣデバイスを管理するように構成されたデータプロセッサを示す。随意に、ＰＯＣ－ＤＭＳは、ＰＯＣデバイスが接続されている同じネットワークに接続された端末コンピュータである。随意に、ＰＯＣ－ＤＭＳは、ＰＯＣデバイスが接続されたネットワークに対して遠隔にホストされ、ＰＯＣデバイスの遠隔管理を可能にする、サーバ、仮想機械、または仮想化サーバとして提供され得る。ＰＯＣデバイス（分析デバイス）が、たとえば、ＰＯＣ－ＤＭＳと同じサブネットまたはネットワーク分岐に接続されていることは必須ではない。

分析デバイスは、「自動通知」を生成し得る。いくつかの自動通知は、分析デバイス上で実行される検査のアッセイ結果を含有するデータメッセージである。他の自動通知は、ハードウェアハードビート、モータ過熱、バッテリー状態、またはふたの目詰まりを報告するメッセージなどの特定のハードウェア故障、ネットワーク化情報（ＬＤＡＰまたはＤＨＣＰルックアップメッセージなど）、試薬情報、温度情報、実行されたアッセイ数の増分カウント、バッテリーレベル、ソフトウェアまたはファームウェア更新要求、ユーザログイン情報、監査ログメッセージ、セキュリティ証明メッセージ、メモリ容量情報、など、分析デバイスの状態に関するフィードバックを含有する。多くの異なるタイプの分析デバイスが多種多様な分析デバイス通知を生成し得ることを当業者は諒解されよう。

分析デバイスに関する「コンテキスト」という用語は、ある状況、ロケーション内の、かつ／またはアナライザの異なるユーザを区別し得る動作状態の、分析デバイスによって行われ得るまたはその分析デバイスに関する観察の収集物を指す。「コンテキスト」は、分析デバイスの使用環境に関する分類可能な技術的概念を表す。コンテキストの存在は、所与の時点で、医学的資料の分析デバイスのセンサーによって、または分析デバイスのネットワークアドレスなどのコンテキスト情報の融合によって、検出される入力刺激要因（ｉｎｐｕｔ ｓｔｉｍｕｌｉ）に基づいて、検出され得るか、またはその入力刺激要因から反復され得る。

さらに、コンテキストを表し得る技術的概念の例示的なカテゴリは、「教育研究室」、「保守管理部門」、および「事故および救急診療部門」における分析デバイスの使用であり得る。

分析デバイスセンサーから導出される技術的入力刺激要因は、ある論理規則範囲に対する入力、またはモデル、たとえば、機械学習技法によって取得されるモデルとして使用され得る。これらの規則は、分析デバイスがどのコンテキストで動作しているかの推論を可能にする。コンテキスト変更の単純な例は、許容温度を有する部屋からアッセイが確実に実行されるためには寒すぎる部屋に分析デバイスを持って行くことであり得る。分析デバイス内に含まれた電子温度計は分析デバイスの温度を経時的に報告し得るため、コンテキスト変更が推論され得る。代替として、分析デバイスの「保守管理部門」への移動は、ハードウェアインターロック信号など、分析デバイスの取外しに関する複数の異常メッセージの分析デバイスからのブロードキャストをもたらし得る。

１つを超える入力刺激要因からのデータの融合は、コンテキストのより正確な決定を可能にする。たとえば、分析デバイスの温度を観察することのみによって、分析デバイスが部屋から移動されたか否か、または同じ部屋の温度が変化したかどうかを決定することは不可能である。しかしながら、ネットワークアドレスデータベースまたはワイヤレスネットワークレジストリなど、外部データベースからの情報は、病院内の部屋周辺の分析デバイスのより正確な追跡を可能にし得る。ユーザデータベースからの情報の分析デバイスからのセンサーデータとのオフライン融合は、分析デバイスの使用履歴の検出を可能にし得る。

「メッセージタイプ」という用語は、各分析デバイスに対して、自動通知を送る分析デバイスのステータスに基づいて、自動通知の有限セットからの１つまたは複数の自動通知が分析デバイスから送信されることを指す。自動通知（メッセージ）の範囲は、メッセージング仕様書において定義され得る。

「少なくとも１つの自動通知の１つまたは複数の特性を識別する」という句は、たとえば、分析デバイスの状態を推論するモデルに対する好適な入力を生成するために自動通知の全体集合のサブサンプリングを暗示し得る。たとえば、バッテリーの状態を推論するとき、たとえば、分析デバイスのソフトウェアバージョンを参照する自動通知に基づいて、モデルをトレーニングすること、またはモデルを適用することは必要でないことがある。１つまたは複数の特性の識別は、したがって、入力された自動通知のストリームの情報コンテンツの低減である。

分析デバイスの「状態」という用語は、そのアナライザに一意である分析デバイスのハードウェアまたはソフトウェア要素のステータスを指す。１つのオプションでは、分析デバイスの「状態」は、「良好状態」、「平均的な状態」、または「来週、保守管理を必要とする」、もしくは「デバイスは保守管理されるまで使用されない」など、いくつかの状態のうちの１つから選択され得る。代替として、分析デバイスの「状態」は、スコアリングシステムに基づいて定義される連続番号であり得る。「測光メータクリーン」など、分析デバイスからの自動通知の緊急ではない特性には低い優先順位スコアが割り当てられてよく、「測光メータ無応答」など、分析デバイスからの自動通知の緊急の特性には高い優先順位スコアが割り当てられてよい。

分析デバイスの「状態」は、アナライザがどの程度使用されているか、アナライザを使用する職員のトレーニングレベル、アナライザのタイプ、アナライザが使用されるコンテキスト、などの関数であり得る。「状態」は、一例として、（ｉ）バッテリーステータス、（ｉｉ）実行されたアッセイの数、（ｉｉｉ）品質制御結果、（ｉｖ）ソフトウェアバージョン、（ｖ）測光メータ状態、（ｖｉ）ドア機構状態、など、幅広い要因の複合物である。したがって、分析デバイスの状態は、自動通知のサブサンプリングされた選択に基づいて推定され得る。検出可能な状態の範囲および定義は、処理のために利用可能な自動通知の範囲、および分析デバイスの保守管理スケジュールを定義するエンドユーザの優先順位にある程度依存することを当業者は諒解されよう。

本明細書で使用される「通信ネットワーク」という用語は、限定はしないが、ＷＩＦＩ、ＧＳＭ、ＵＭＴＳ、またはイーサネットなど、他のワイヤレスデジタルネットワークもしくはワイヤードネットワークを含めて、任意のタイプのワイヤードまたはワイヤレスネットワークを包含する。たとえば、通信ネットワークは、ワイヤードおよびワイヤレスネットワークの組合せを含み得る。自動通知は、通信ネットワークを介して分析デバイスから送信され得る。

「サーバ」という用語は、そこから要求を受け入れ、それに応じて応答を与えることが可能な物理または仮想プロセッサを有する任意の物理的機械または仮想機械を包含する。機械という用語が、物理ハードウェア自体、もしくはＪＡＶＡ（登録商標）仮想機械（ＪＶＭ）などの仮想機械、または、同じ物理的機械上で異なるオペレーティングシステムを実行し、機械のコンピューティングリソースを共有している別々の仮想機械すら指し得ることは、コンピュータプログラミングの当業者には明らかであろう。サーバは、個々に、「サーバ」、または仮想サーバなど、共有リソースと呼ばれることも多い、専用コンピュータを含めて任意のコンピュータ上で実行し得る。多くの場合、コンピュータは、いくつかのサービスを提供し、いくつかのサーバを実行させることが可能である。したがって、サーバという用語は、１つまたは複数のクライアントプロセスに対するリソースを共有する任意のコンピュータデバイスを包含するものとする。サーバは、自動通知を受信、処理、および送信し得る。

「サーバインターフェース」という用語は、外部エンティティ（サーバまたは別のインターフェースなど）との通信を許可するためのプログラム論理を実行するように動作可能な任意のハードウェア、ファームウェア、および／またはソフトウェアベースのモジュールを包含する。

「データ処理エージェント」という用語は、ポイントオブケアデバイスから自動通知、および、随意に、ユーザまたはオペレータから注釈データを受信することが可能な、サーバなど、１つまたは複数のコンピューティングデバイス上で実行するコンピュータ実装ソフトウェアモジュールを指す。一例では、データ処理エージェントは、受信された自動通知に基づいて分析デバイスの特性を推論し得る。一例では、データ処理エージェントは、自動通知および注釈データを関連付けることができる。「データ処理エージェント」は、単一のサーバ上で、もしくは複数のサーバ間で、かつ／またはＡｍａｚｏｎ ＡＷＳ（商標）またはＭｉｃｒｏｓｏｆｔ Ａｚｕｒｅ（商標）など、インターネットベースの「クラウド」処理サービス上で実装され得る。「データ処理エージェント」、またはその一部分は、仮想機械上でホストされ得る。データ処理エージェントは、自動通知を受信、処理、および送信し得る。

「ユーザインターフェース」という用語は、限定はしないが、オペレータからのコマンドを入力として受信し、やはりフィードバックをオペレータに提供し、情報をオペレータに伝えるためのグラフィカルユーザインターフェースを含めて、オペレータと機械との間の対話のための任意の数の適切なソフトウェアおよび／またはハードウェアを包含する。また、システム／デバイスは、異なる種類のユーザ／オペレータにサービスするためのいくつかのユーザインターフェースを明らかにし得る。ユーザインターフェースは、自動通知を表示し得る。ユーザインターフェースは、保守管理報告を表示し得る。

一態様による、分析デバイス管理のためのネットワークシステムを概略的に例示する図である。 分析デバイス管理のためのシステム内のメッセージングフローを概略的に例示する図である。 分析デバイスの一例を概略的に例示する図である。 第２の態様によるデータ処理エージェントをホストするように構成された装置（サーバ）の一例を概略的に例示する図である。 一態様による方法を概略的に例示する図である。 プロセッサまたは他のプロセッサ手段上で実行されるときのデータ処理エージェントの論理環境を概略的に例示する図である。 分析デバイスの特性の識別および状態の後続の推論の一例を概略的に例示する図である。 図７ａの時間事象データ内で識別される少なくとも１つの自動通知の特性の処理を概略的に例示する図である。 自動通知を注釈データに関連付けるための注釈エンジンの一例を概略的に例示する図である。 相関規則セットを使用して自動通知を注釈データと相関させる一例を概略的に例示する図である。 第１の病院内の分析デバイスの推論された状態を報告する通知に基づいて生成された第１のグラフィカルユーザインターフェースの一例を概略的に例示する図である。 第２の病院内の分析デバイスの推論された状態を報告する通知に基づいて生成された第１のグラフィカルユーザインターフェースの一例を概略的に例示する図である。

注記：図面は正確な縮尺率で描かれておらず、例示としてのみ提供され、本発明の範囲を定義するためではなく、本発明の範囲をよりよく理解するのに役立つ。可能な場合、同じ論理エンティティは同じ参照番号を共有する。これらの図面から本発明のいずれの特徴の何の限定も推論すべきではない。

ポイントオブケア（ＰＯＣ）アナライザ（分析デバイスとも呼ばれる）は、サーバ、具体的には、ポイントオブケアデータ管理システム（ＰＯＣ－ＤＭＳ）とも呼ばれるハードウェア管理サーバによって、通常、管理される。ＰＯＣ－ＤＭＳは、分析デバイスに対する接続性、検査結果、オペレータ、品質制御の管理を提供し、分析デバイスの保守管理体制を追跡する。たとえば、１つのＰＯＣ－ＤＭＳは、病院、病院部門、または医療検査センターにおけるすべての分析デバイスを管理し得る。

分析デバイスシステムの管理は困難である。検査の品質を保証するために管理すべき、数十の現場、数百の分析デバイス、および数千のオペレータが存在し得る。大型ＰＯＣデバイスを管理する際の１つの課題は、数十個、または数百個の分析デバイスの保守管理ステータスを追跡することに関する。

分析デバイスは、通常のデバイスメッセージ、事象メッセージ、使用メッセージ、システム警告メッセージ、およびエラー（分析デバイスデータ）を含む大量のデータを分析デバイス管理のためのシステム（ＰＯＣ－ＤＭＳ）に送る。分析デバイス保守管理要件の報告は、さらに改善され得る。

いくつかの保守管理は、所定の位置で実行され得る（バッテリー交換など）が、他の保守管理は、分析デバイスを保守管理センターに送り出すことを必要とする（機械的修理など）。典型的には、分析デバイスの保守管理は、通常の予定表上に提供され得るが、保守管理間の時間間隔の選択は、保守管理を必要としない分析デバイスの不十分な頻度の保守管理、または頻度があまりにも低く、所与のＰＯＣアナライザの考えられる故障を十分早く決定しない、保守管理スケジュールをもたらし得る。

分析デバイス保守管理要件の正確な評価は、たとえば、予備部品がプリエンプティブに注文されることを可能にし得る。分析デバイス保守管理要件の正確な評価はまた、分析デバイス可用率を改善し、所与の分析デバイスが使用中に不意に故障するリスクを低減し得る。

保守管理要件をもたらす分析デバイスが経験するプリエンプティブな状態は、当該分析デバイスのタイプ、その使用履歴、および変化の程度に部分的に依存する。これらの状態は、分析デバイス内の様々な既存のセンサーによって検出され得る。

このコンテキストにおいて、改善された保守管理スケジュールまたは保守管理アラームを決定することは、単に管理上の性質の問題ではなく、１つまたは複数の分析デバイスからのセンサーフィードバックは、保守管理要件の改善された自動評価を可能にし得るか、または故障が、個々の分析デバイスの特定の使用コンテキストに基づいて、正確かつ自動的に事前に回避されることすら可能にし得る。

本明細書は、一般に、１つまたは複数の分析デバイスの推論された状態を報告する通知を生成するために、１つまたは複数の分析デバイスから受信される自動通知を使用することを提案する。一例では、分析デバイスの第１のセットからの自動通知は、モデルをトレーニングするために使用される。モデルは、自動通知の受信されたセットと、自動通知の受信されたセットから推論され得る分析デバイスの状態の間の関係を定義する。

トレーニングされるとき、さらなるネットワーク内で受信される自動通知の同様のパターンがさらなるネットワーク内の１つまたは複数の分析デバイスの状態を推論するために使用され得るように、モデルが分析デバイスのさらなるネットワークに提供され得る。モデルは機械学習技法（たとえば、教師あり学習または教師なし学習）を使用してトレーニングされ得るが、これは必須ではない。

モデルは、入力された通知のセットと推論された状態の間のマッピングを定義する。したがって、単純な事例では、モデルは、たとえば、トレーニングされたモデルではなく、製造会社によって提供される事前定義された論理規則セットとして提供され得る。

代替として、第１のネットワーク１０Ａ内の分析デバイスＰ１Ｂ～Ｐ７Ｂの第１のセットから受信された自動通知を使用してトレーニングされたモデルを備えた、第２のネットワーク１０Ｂ内の分析デバイスＰ１Ｂ～Ｐ７Ｂの第２のセットからの自動通知がデータ処理エージェント４０に提供され得る。

図１は、分析デバイス管理のためのネットワークシステム１０を概略的に例示する。分析デバイス管理のためのネットワークシステム１０は、第１のネットワーク１０Ａを備える。第１のネットワーク１０Ａは、分析デバイスを格納する第１のロケーション１８Ａおよび分析デバイスを格納する第２のロケーション１９Ａに対応する、１つまたは複数のローカルエリアネットワーク（ＬＡＮ）または広域ネットワーク（ＷＡＮ）に分割され得る。たとえば、第１のロケーション１８Ａは、ローカルクリニックを表すことができ、第２のロケーション１９Ａは、総合病院を表すことができる。ネットワークシステム１０の第１のネットワーク１０Ａ内のロケーションの数は、説明するシステムの機能の点で必須ではない。

システムは、通信ネットワーク１６によって通信可能に接続された、１つまたは複数の分析デバイス（ＰＯＣデバイス）Ｐ１Ａ～Ｐ７Ａ、随意に、ポータブルコンピューティングデバイス２６Ａ（スマートフォンなど）、およびサーバ１２Ａを備える。サーバ１２Ａは、一例では、第１の態様によるデータ処理エージェント２３をホストし得る。他の例では、データ処理エージェントは、複数のサーバおよびコンピューティングデバイスにわたって分散されたクラウドコンピューティングサービスによってホストされ得る。具体的には、通信ネットワーク２１は、１つまたは複数の分析デバイスＰ１Ａ～Ｐ７Ａに通信可能に接続するように構成される。

たとえば、通信ネットワーク２１は、たとえば、イーサネットネットワーク、Ｗｉ－Ｆｉネットワーク、および／またはインターネットなどの広域ネットワークＷＡＮを介して提供されるローカルエリアネットワークＬＡＮのうちの１つまたは複数を備え得る。通信ネットワークは、３Ｇ、４Ｇ、または５Ｇシステム２８などのモバイル電話通信ネットワークおよび／または病院のＰＡＣＳネットワークを備え得る。

随意に、通信ネットワーク１６は、サーバ１２を分析デバイス（ＰＯＣデバイス）Ｐ１ＡからＰ７Ｂに直接接続し得る（図示せず）。

随意に、通信ネットワーク２１は、保健医療施設１８Ａの内部通信システム２２Ａとインターフェース接続する。内部通信システム２２Ａは、たとえば、イントラネットであり得る。

自動通知の通信を依然として可能にしながら、セキュリティおよび機密性を確実にするために、ファイアウォールおよび当業者に知られている他のセキュリティ対策が内部通信システム２２Ａと通信ネットワーク２１の間に配置され得る。分析デバイスＰ１Ａ～Ｐ７Ａは、たとえば、内部通信システム２２および通信ネットワーク１６を介して通信することによって、サーバ４０上でホストされるデータ処理エージェント２３と通信し得る。

分析デバイスＰ１Ａ～Ｐ７Ａは、１つまたは複数の患者の健康パラメータを測定するために、１つまたは複数の患者試料を分析するように提供され構成される。

アナライザＰ１Ａ～Ｐ７Ａは、たとえば、第１のロケーション１８Ａ（ローカルクリニックに対応する）内に位置する。固定機器１４は、第２のロケーション１９Ａ（たとえば、総合病院に対応する）内に位置し得る。

特定の分析デバイスＰ１Ａ～Ｐ７Ａを識別するために、各分析デバイスには、アナライザ識別子コードが、具体的には、バーコードおよび／またはＲＦＩＤタグもしくはシリアル番号などの識別子タグの形態で提供される。随意に、そのような識別子は、分析デバイス管理のためのシステムのデータベース内のエントリーに関連付けられ得る。

アナライザＰ１Ａ～Ｐ７Ａは、たとえば、通信ネットワーク１６を介して自動通知（分析デバイスステータスデータまたは事象メッセージ）をアナライザからサーバ１２に送信するように構成される。

分析デバイス管理のためのネットワークシステム１０は、たとえば、サーバ１２Ａ上でホストされるポイントオブケアデータ管理システム（ＰＯＣ－ＤＭＳ）をさらに備える。ＰＯＣ－ＤＭＳの目的は、定義されたエリアまたはネットワーク分岐内で１つまたは複数の分析デバイスＰ１Ａ～Ｐ７Ａを監視および制御することである。たとえば、ＰＯＣ管理職員は、サーバ１２ＡでホストされるＰＯＣ－ＤＭＳを使用して、消耗品の使用および多種多様の他の管理活動を監視するために分析デバイスＰ１Ａ～Ｐ７Ａのうちの１つまたは複数の状態を追跡することができる。

分析デバイス管理のためのネットワークシステム１０は、さらなるネットワーク１０Ｂをやはり備える。さらなるネットワーク１０Ｂは、第１のネットワーク１０Ｂと比較して異なる病院現場、または異なる国、もしくは病院部門内で実行される分析デバイスのネットワークを表す。ネットワーク１０Ａに関して上記で提供された個々の構成要素の説明は、簡潔にするために、さらなるネットワーク１０Ａの例示される構成要素にも適用される。さらなるネットワーク１０Ｂは、例示されるものとはかなり異なるアーキテクチャを有し得ることを当業者は諒解されよう。

具体的には、第２のＰＯＣ－ＤＭＳ１２Ｂは、分析デバイスＰ１Ｂ～Ｐ７Ｂから出力された多数の分析デバイスメッセージデータをどのように処理および／または表示するかの問題にやはり直面することになる。

ネットワーク１０Ａに接続された多数の分析デバイスＰ１Ａ～Ｐ７Ａが、分析デバイスＰ１Ａ～Ｐ７Ａの内部状態を反映する、数千または数万の自動通知を毎時間生成する。

本明細書で紹介される態様によれば、ポイントオブケアデバイス（分析デバイスＰ１Ａ～Ｐ７Ａ）は、通常のデバイスメッセージ（自動通知）をポイントオブケアデータ管理システム１２Ａに送る。それらのデバイスメッセージは、事象、使用、システム警告、およびエラーに関してユーザに知らせる。随意に、デバイスメッセージは、特定のデバイス上で起こった、すべての事象の包括的なオーディットトレイル、または事象のかなりの部分を作成するメモ（注釈）の使用と組み合わされ得る。これは、アナライザの推論された状態に基づいて保守管理決定が行われることを可能にする。

図２は、分析デバイス管理のためのシステム１０、１０Ｂ内のメッセージフローを概略的に示す。

分析デバイスＰ１Ａ（分析デバイスなど）を備えた第１のネットワーク１８Ａおよびポイントオブケアデバイス管理システム（ＰＯＣ－ＤＭＳ）１２Ａは、インターネットなど、通信リンク２１を介してＰＯＣ－ＤＭＳ１２Ａに接続される。随意に、さらなるネットワーク１８Ｂ、１８Ｃ、１８Ｄ．．．が通信リンク２１を介して接続される。第１のネットワーク１８Ａ内のＰ１Ａなどの分析デバイスは、多数の自動通知を毎時間生成する。

やはりネットワーク２１を介して通信可能に結合される、さらなるネットワーク１８Ｅは、分析デバイスの同様の選択（Ｐ１Ｂなど）を含有し得る。

言い換えれば、本明細書のシステムは、たとえば、分析デバイスからの生成された通知を使用して、予想される考えられる分析デバイス障害および／または分析デバイスに対して必要とされる保守管理活動について積極的に知らせることができる。これらの生成された通知は、デバイス障害をもたらす事象の識別されたパターンおよびチェーンに基づいて作成される。そのようなパターンは、収集および分析されたデバイス事象、ならびに異なる病院およびデバイス全体からのメモに基づいて識別され得る。

一例では、いくつかの病院１８Ａ、１９Ａ、１８Ｂ、１９Ｂは、あるタイプの分析デバイスＰ１Ａ～Ｐ７Ａ、Ｐ１Ｂ～Ｐ７Ｂを使用し得る。たとえば、Ｐ１Ａからの自動通知は、ＰＯＣ－ＤＭＳ１２Ａに定期的に送られ、ＰＯＣ－ＤＭＳ１２Ａは、それらの自動通知を中央分析および記憶システム（たとえば、データ処理エージェント４０）と共有する。

たとえば、分析デバイスＰ１Ａ内のセンサー障害が識別された場合、ユーザは、たとえば、分析デバイスＰ１Ａのソフトウェアの再インストールを試みることができる。しかしながら、故障はセンサー障害によるため、問題は続く。分析デバイスＰ１Ａは、その場合、損傷しているとマーキングされ、製造会社に返却されることになり分析デバイスＰ１Ａの返却につながる事象のシーケンスは、将来の分析のために、データ処理エージェント４０およびその関連データベース内に記憶され得る。

他の同様の事例が他の病院内で出現する可能性があり、システムがセンサー障害をもたらすパターン（たとえば、連続しておよそ１００件の障害ＱＣ結果）を認識することを可能にする。システムは、したがって、システムが第２のネットワーク１０Ｂ内の分析デバイスＰ１Ｂ内で同じ障害をもたらすことになる同じパターンを認識するとき、さらなるネットワーク内のＰＯＣ－ＤＭＳ１２Ｂのユーザに積極的に通知し得る。

図３は、分析デバイス２０（ポイントオブケア（ＰＯＣ））の一例を概略的に例示する。

分析デバイス２０の例は、電力を分析デバイス２０に提供するように構成された電源２２を備える。電源２２は、たとえば、分析デバイス２０がポータブルになることを可能にするリチウムイオンバッテリー、または主電源であってよい。電源２２は、分析デバイス２０の他の要素に電気エネルギーを提供する。他の要素は、たとえば、センサーデバイス２４、電気機械サブアセンブリ２６、標本処理セクション２８、および分析ユニット３０を備える。制御および通信サブシステム３２は、事前に列挙したモジュールとインターフェース接続する。通信リンク３４は、分析デバイス２０との間でデータ転送を可能にする。

センサーデバイス２４は、たとえば、液体試料を通した光伝達特性を測定するための測光メータを備えるが、分析デバイス２０のアプリケーションに応じて、多くの他のセンサーが使用され得る。

電気機械サブアセンブリ２６は、試料のアンプルまたはカセットがセンサーデバイス２４によって分析され得るように、それらのアンプルまたはカセットを受信し、それらのアンプルまたはカセットを標本処理セクション２８内にロードするように構成される。分析に続いて、電気機械サブアセンブリ２６は、試料のアンプルまたはカセットをイジェクトし得る。

標本処理セクション２８は、試料のかくはんまたは必要とされる分析温度への過熱などの事前分析機能を実行し得る。

分析ユニット３０は、標本処理セクション２８内に含有された標本の特性を備えたデータをセンサーデバイス２４から受信し得る。分析ユニット３０は、センサーデバイス２４からのデータに対して１つまたは複数のデータ処理動作を実行し得る。たとえば、分析ユニット３０は、センサーデバイス２４からの結果が予想される境界範囲内であることを確実にし得る。

分析に続いて、分析ユニット３０は、通信および制御ユニット３２を介したセンサーデバイス２４からのデータを、通信ネットワーク２１を介して分析デバイス管理のためのシステムに、また最終的に、たとえば、サーバ上でホストされるデータ処理エージェント２３に送信し得る。

一般的な分析デバイス４０の前述の説明は、例示のために提供され、実際の分析デバイスは、より少数のまたはより多数のモジュールおよび機能性を備え得ることを当業者は諒解されよう。

一例では、分析デバイス２０は、血糖検査、凝固検査、血液ガスおよび電解質分析、尿分析、心臓マーカー分析、ヘモグロビン分析、感染病検査、コレステロールスクリーニングまたは核酸検査を実行するように構成される。分析デバイスＰ１Ａ～Ｐ７Ａのいくつかの機能および／または動作態様は、１つまたは複数のアナライザパラメータを使用して構成可能であるかまたはカスタマイズ可能である。

一例では、分析デバイス２０は、たとえば、カメラまたはマイクロフォンからデータを受信し、医学的に関係する表示のためにデータを分析するように構成される。

１つまたは複数の分析デバイス２０（ネットワーク１０Ａ、１９Ｂ内のＰ１Ａ～Ｐ７Ａ）は、幅広い自動通知を生成し、通信ネットワーク２１を介してそれらの自動通知をデータ処理エージェント２３に送信する。分析デバイスＰ１Ａ～Ｐ７Ａの１つまたは複数のモジュールは、異なるタイプの自動通知（たとえば、事象データ、結果データ、較正データ、保守管理関連データ）を生成するように構成され得る。

たとえば、電源２２は、電源２２がその残りの容量の１０％のみを有することを示すために、自動通知「ｂａｔｔ＿ｌｏ＿１０％」を生成し得る。

たとえば、電源２２は、電源２２がバッテリー故障により、またはバッテリー電源を使い果たしたために、バッテリーを単に停止したことを示すために、自動通知「ｂａｔｔ＿ｓｈｕｔｄｏｗｎ」を生成し得る。

たとえば、電気機械サブアセンブリ２６は、電気機械サブアセンブリ２６が連続的に機能的であることを示す反復「ハートビート信号」として、自動通知「ｍｏｔｏｒ＿ＰＣＢ＿ＨＢ」を生成し得る。

たとえば、センサーデバイス２４は、測光計プリント基板「ハートビート」信号を生成し得る。加えて、センサーデバイス２４は、オンボードＬＥＤおよび／またはレーザがクリーニングを必要とすることを示す、自動通知「ｐｈｏｔｏｍｅｔｅｒ＿ｃｌｅａｎ＿ｗａｒｎ」を生成し得る。

たとえば、標本処理セクション２８は、試料をセキュアに含有するために分析デバイスの試料処理ドアが閉まっていないことをシグナリングするために自動通知「ｄｏｏｒ＿ｊａｍ」を報告し得る。

たとえば、制御および通信ユニット３２は、分析デバイスの動作温度が、不正確な結果が提供され得る、安全でない温度に近づいていることを示す「ｔｅｍｐ＿ｈｉ＿９０％」信号の形態で自動通知を生成し得る。たとえば、制御および通信ユニット３２は、分析デバイス２０が過剰な温度のためにオフに切り替えられていることを示す「ｔｅｍｐ＿ａｕｔｏ＿ｓｈｕｔｄｏｗｎ」信号の形態で自動通知を生成し得る。

制御および通信ユニット３２は、個々の検査のステータスが追跡されることを可能にするために、分析状態のシーケンス（「ｓｃａｎ＿ｂａｒｃｏｄｅ」、「ｒｅｐｏｒｔ＿ｂａｒｃｏｄｅ」、「ａｓｓａｙ＿ｌｏａｄｅｄ」、「ｔｅｓｔ＿ｒｅｓｕｌｔ」）として自動通知を送信することもできる。

制御および通信ユニット３２は、内部メモリの状態、現在のソフトウェアまたはファームウェアバージョンなど、分析デバイス２０のソフトウェア構成態様、パスワードの成功または失敗などのセキュリティパラメータ、およびネットワーク構成報告設定、分析デバイスのネットワークまたはＭＡＣアドレス、および、随意に、ネットワークアップタイムおよびダウンタイムなど、ネットワーク接続態様に関して報告する自動通知を提供し得る。

随意に、自動通知は、１０秒、１秒、０．１秒、０．０１秒の精度に、または、たとえば、イーサネットタイムプロトコルまたはネットワークタイムプロトコルによって可能にされるようなより高い精度にすら、制御および通信ユニット３２によってタイムスタンプされる。これは、遠隔サーバによってホストされるデータ処理エージェント２３が、自動通知の生成をトリガする事象が発生した時間に対して、受信された自動通知のシーケンスを再構築することを可能にする。

当然、制御および通信ユニット３２は、分析デバイス２０の制御および通信ユニット３２内に含有された規則に基づいて、個々の自動通知の連結されたグループを備える、より複雑な自動通知を生成し得る。

随意に、自動通知は、患者試料の分析から取得された検査結果データと連結され得る。

自動通知は、当業者によって知られているように、分析デバイス管理のためのシステム内で使用される通信システム１６Ａのプロトコルに従ってカプセル化されたデータパケットとして送信される。データパケットは、自動通知を備え、自動通知のデータ処理エージェントへの信頼できるルーティングを可能にするためにヘッダ情報の何らかの必要な配列を備え得る。

データパケットは、１ビットのペイロード情報（たとえば、ハートビートフラグの場合）のみを備え得る。

代替として、データパケットは、大量の情報（たとえば、長い時間期間にわたる画像もしくは加速度計または録音の場合、数キロバイトまたは数メガバイト）を備え得る。分析デバイス２０の制御および通信ユニット３２は、たとえば、所与の時間量にわたって複数の自動通知メッセージをバッファリングし、メッセージを連結して１つのデータパケットにするように構成され得る。これは、ハンドヘルド分析デバイスのより長いバッテリー寿命をもたらし得る。

一例では、自動通知は、「ＨＬ７」プロトコル（Ｈｅａｌｔｈ Ｌｅｖｅｌ Ｓｅｖｅｎ、Ａｎｎ Ａｒｄｏｒ ＭＩ、ＵＳＡ）および／またはＡＳＴＭプロトコル（たとえば、ＡＳＴＭ １３９４ ＬＩＳ２）に通信準拠である。

分析デバイス２０の前述の説明は、さらなる通信ネットワーク１０Ｂに通信可能に結合された分析デバイスＰ１Ｂ～Ｐ７Ｂにも適用されることを当業者は諒解されよう。本明細書の技法は、上記で説明したものとは異なる、センサー、アクチュエータ、および構成要素の分布を有し得る、ある範囲の異なるタイプの分析デバイスに適用され得る。中央システムによる分析デバイスタイプの識別は、製造会社識別コード、ネットワークアドレス、ＭＡＣアドレス、などを使用して達成される。

図４は、データ処理エージェントをホストするように構成されたサーバ４０の一例を概略的に例示する。

この例では、サーバ４０は、ランダムアクセスメモリ４４、読取り専用メモリ４６、中央処理装置４７、入出力インターフェース４８、データ記憶インターフェース５０（不揮発性メモリ４９に対するインターフェースなど）、ディスプレイインターフェース５２、および通信インターフェース５４を備えたマザーボード４２を備えるが、他の機能性を有する、より少数または多数のモジュールを備えた、多くの異なるタイプのサーバ構成が提供され得ることを当業者は諒解されよう。

サーバ４０の中央処理装置４７は、実行されるとき、サーバ４０のランダムアクセスメモリ４４内でネットワーク１０内の少なくとも１つの分析デバイスＰ１Ａ～Ｐ７Ａ、Ｐ１Ｂ～Ｐ７Ｂの状態を推論するためのデータ処理エージェントをインスタンス化するコンピュータ可読命令をインターフェース接続された不揮発性メモリ４９（たとえば）から取得するように構成される。

サーバの通信インターフェース５４は、通信ネットワーク２１とインターフェース接続するように構成される。分析デバイスＰ１Ａ～Ｐ７Ａからの自動通知は、サーバの通信インターフェース５４を介してサーバ４０において受信される。

随意に、自動通知は、中央処理装置４７によって処理および分析することによってランダムアクセスメモリ４４に直接提供される。随意に、自動通知は、後続の分析のために不揮発性メモリ４９に書き込まれる。

随意に、自動通知は、外部ファイルストア（図示せず）に書き込まれ（キャッシュされ）得る。中央処理装置４７による要求時に、自動通知に対する要求は、通信ネットワーク２１を介して外部ファイルストアに送られ得る。外部ファイルストアは、認証および許可を未決にして、少なくとも１つの自動通知をサーバ４０に送信し得、サーバ４０において、このデータは後続処理され得る。

前述の随意の実施形態の利点は、大量の自動通知が、処理される必要があるまで、ロバストに記憶され得ることである。分析デバイスの状態が、分析デバイス通知が受信されるのと同時に推論されることは必須ではない。

代替として、推論は、たとえば、自動通知のタイムスタンプデータを使用して、後処理ステップにおいて実行され得る。

随意に、分析デバイスの推論された状態は、自動通知がデータ処理エージェントによって受信されるとき即時に更新または生成される。

データ処理エージェント２３は、たとえば、ランダムアクセスメモリ４４、もしくは読取り専用メモリ４６、入出力インターフェース４８、またはデータ記憶インターフェース５０から取得された機械可読命令からサーバ４０上でインスタンス化される。

データ処理エージェント２３は、したがって、１つまたは複数の自動通知を受信するように構成される。サーバ４０上でインスタンス化されたデータ処理エージェント２３は、後で論じるような技法に基づいて、１つまたは複数のネットワーク１０Ａ、１０Ｂ内の１つまたは複数の分析デバイスＰ１Ａ～Ｐ７Ａ、Ｐ１Ｂ～Ｐ７Ｂの推論された状態を報告する自動通知を生成し、推論された状態を報告する少なくとも通知をデータ構造（信号）として、さらなる通信ネットワーク１０Ｂに通信可能に結合された１つまたは複数のさらなるポイントオブケアデバイスＰ１Ｂ～Ｐ７Ｂに、かつ／またはＰＯＣ－ＤＭＳ１２Ａ、１２Ｂに送信するように構成される。

随意に、データ処理エージェント２３をホストしているサーバ４０は、分析デバイスＰ１Ａ～Ｐ７Ａの推論された状態を、ローカルディスプレイドライバ５６を介して、または推論された状態を、スマートフォン２６Ａなど、さらなるデバイスに通信することによって、ローカルディスプレイ上でユーザに表示するように構成される。

第１の態様によれば、ネットワーク２１を介して少なくとも１つの分析デバイスＰ１Ａ～Ｐ７Ａ、Ｐ１Ｂ～Ｐ７Ｂから受信された少なくとも１つの自動通知に基づく分析デバイスの状態を推論するためのコンピュータ実装方法６０が提供される。この方法は、
データ処理エージェント４０において、少なくとも１つの分析デバイスから少なくとも１つの自動通知を受信すること（６１）と、
データ処理エージェント４０において、少なくとも１つの自動通知を処理し（６２）、それにより、少なくとも１つの分析デバイスからの少なくとも１つの自動通知に基づいて自動化されたアナライザの１つまたは複数の特性を識別すること（６２）と、
データ処理エージェント４０において、１つまたは複数の識別された特性をモデルに適用することによって、少なくとも１つの分析デバイスの状態を推論すること（６３）と、
データ処理エージェント４０において、分析デバイスの推論された状態を報告する通知を生成すること（６４）と
を備える。

図５は、第１の態様によるコンピュータ実装方法を概略的に例示する。サーバプロセッサまたは他のプロセッサ手段上で実行されるとき、特許請求される方法を実行するように構成されたデータ処理エージェントは、図６に例示するように、１つまたは複数のデータベースとインターフェース接続し得る。

図６は、サーバプロセッサまたは他のプロセッサ手段上で実行されるときのデータ処理エージェント４０の論理環境の一例を概略的に例示する。図６の論理環境表現は、便宜上、その動作コンテキストにおいて、データ処理エージェントの内部および外部コンテキストを例証することを目的とする。しかしながら、図６の要素間の接続線または要素の位置の不在は、限定と解釈されるべきではない。

病院１９Ａ、１９Ｂにおける分析デバイスＰ１Ａ～Ｐ７Ａ、Ｐ１Ｂ～Ｐ７Ｂは、データ処理エージェント４０（たとえば、サーバまたはクラウドサーバ上で実行している）に通信可能に結合される。

データ処理エージェント４０は、ネットワーク１０とインターフェース接続し、ネットワークから自動通知を受信するように構成された受信エンジン６６を備える。代替または追加として、受信エンジンは、過去の通知にアクセスするために通知データベース７０とインターフェース接続し得る。受信エンジン６６は、随意に、たとえば、自動通知内の不要なフィールドを除去することによって処理するように自動通知を準備するための前処理を実行する。

随意に、受信エンジン６６は、ネットワーク１０から自動通知をサブサンプリングするように構成される。たとえば、受信エンジン６６は、同じタイプの分析デバイスからの通知が受信されるように、自動通知をサブサンプリングし得る。このオプションによれば、特定のタイプの分析の保守管理状態は、所与の製造会社からの例示的なすべての分析デバイスについて追跡または推論され得る。

随意に、受信エンジン６６は、同じタイプのメッセージのサブクラスを参照する通知が受信されるように、自動通知をサブサンプリングし得る。たとえば、バッテリー交換と信頼性に主に関心がある保守管理プロバイダは、一例として、データ処理エージェントの処理をバッテリーの調子に関するメッセージに基づかせることを選ぶことがある。

随意に、受信エンジン６６は、ネットワーク１０内の１つのターゲットにされた分析デバイスからの通知が受信されるように、自動通知をサブサンプリングし得る。このオプションによれば、１つの特定のターゲットにされた分析デバイスの保守管理状態が追跡または推論され得る。

データ処理エージェント４０は、受信エンジン６６および／または通知データベース７０から事前処理された自動通知を受信するように構成された識別エンジン６７を備える。識別エンジン６７は、自動通知の特性を識別するために、自動通知のうちの１つまたは複数を分析するように構成される。

一例では、複数の自動通知の特性は、分析デバイスの状態に関する推論が実行されることを可能にする、自動通知の何らかの組合せ、または配列である。一例では、この特性は、分析デバイスの効果または状態に関する、データ処理エージェント４０によって受信された自動通知のセットのサブセットである。

実際には、１つまたは複数の識別された特性は、ネットワーク１０内で少なくとも１つの分析デバイスによって送信される自動通知のサブセットを備え得る。

随意に、自動通知のサブセット内の通知間の相対的な時間関係は、分析デバイスの状態に関する推論が行われることを可能にするために、記録または保存される。随意に、識別された特性は、たとえば、所与の時間窓にわたって受信された異なるタイプの自動通知のヒストグラムを備え得る。

たとえば、分析デバイスＰ１Ａに影響を及ぼす複数の「ドアの目詰まり」について忠告する同じタイプの繰り返される自動通知のセットは、特性パターンの一例であるが、１つを超えるタイプの自動通知を組み合わせる他のより複雑な規則を使用する、または特定の時間窓に従って自動通知をウィンドウイングする（ｗｉｎｄｏｗｉｎｇ）、自動通知の特性パターンが構成され得る。１つまたは複数の識別された特性は、たとえば、推論プロセスのための入力として使用される、ネットワーク１０から受信された自動通知のフィルタリングされた、低減された、または要約されたバージョンとして閲覧され得る。

データ処理エージェント４０は、推論エンジン６８を備える。推論エンジン６８は、識別エンジン６７から１つまたは複数の識別された特性を受信するように構成される。１つまたは複数の識別された特性をモデルに適用することによって、少なくとも１つの分析デバイスＰ１Ａの状態に関する情報が推論され得る。

データ処理エージェント４０は、通知生成器６９を備える。推論エンジン６８が識別された１つまたは複数の特性をそのモデルに適用し、分析デバイスＰ１Ａが、通知が生成されることを必要とする状態にあることを後で推論する場合、通知生成器６９は、分析デバイスＰ１Ａの状態に関する通知を生成する。

通知は、「来週のＰＯＣ Ｐ１Ａ内のバッテリー障害の可能性８０％」など、比較的単純な推論を定義するデータ記録であってよい。代替として、通知は、たとえば、保守管理技術者に有用であり得る分析デバイスＰ１Ａの過去の、現在の、または（モデルによって予測されるような）将来の時点における、１つまたは複数の分析デバイスＰ１Ａ～Ｐ７Ａの状態範囲を定義するデータ構造であってよい。

通知生成器６９によって生成されるデータ記録またはデータ構造は、保守管理データベース７５など、データベース内に記憶され得る。通知生成器によって生成されるデータ記録またはデータ構造は、オペレータがネットワーク１０内の１つまたは複数の分析デバイスの保守管理状態の概要を取得することを可能にするために、ネットワーク１０内で１つまたは複数のＰＯＣ－ＤＭＳコンピュータ１２に通信され得る。

随意に、推論エンジン６８は、ネットワーク１０Ａ内のいくつかの分析デバイスＰ１Ａ～Ｐ７Ａに対して対応する数のモデルを実行する。随意に、推論エンジン６８は、複数の異なるタイプのモデルを実行し、推論エンジン６８によって実行されるモデルのタイプは、ネットワーク１０Ａ内で動作している分析デバイスＰ１Ａ～Ｐ７Ａのタイプに対応する。

随意に、推論エンジン６８によって実行される各モデルは、ネットワーク１０Ａ内で動作している対応する分析デバイスＰ１Ａの状態の一態様を追跡する。

随意に、第１の分析デバイスＰ１Ａがネットワーク１０Ａに接続されるとき、対応する第１のモデルが推論エンジン６８内でインスタンス化される。データ処理エージェント４０が第１の分析デバイスＰ１Ａから自動通知を受信すると、推論エンジン６８は、受信された自動通知に基づいて、モデル６８によって定義される、第１の分析デバイスＰ１Ａの推論された状態の少なくとも一態様を反復する。第１の分析デバイスＰ１Ａがネットワーク１０Ａから除去されるとき、第１のモデルは、記憶され、推論エンジン６８から除去される。したがって、一実施形態では、モデル６８は、ネットワーク１０に現在接続されている分析デバイスによって反映される合成物を備えた合成モデルである。

随意に、通知生成器６９は、推論された状態を報告する通知をＰＯＣ管理コンピュータ１２Ａ、１２Ｂに送信するように構成される。

随意に、通知生成器６９は、推論された状態を報告する通知を保守管理データベース７５に送信するように構成される。

データ処理エージェント４０は、必須ではないが、それでもなお、有利な特性を実施形態に提供する、いくつかの補助的に論理的なエンジンを備える。具体的には、以下の通りである。

データ処理エージェント４０は、ネットワーク監視エンジン７８を備え得る。ネットワーク監視エンジン７８は、ネットワーク１０に接続された分析デバイスＰ１Ａ～Ｐ７Ａ、Ｐ１Ｂ～Ｐ７Ｂを識別するためにネットワーク１０を調べるように構成される。代替または追加として、ネットワーク監視エンジン７８は、たとえば、ＰＯＣ－ＤＭＳ１２Ａによって維持されるデバイスレジストリに問い合わせることができる。したがって、アクティブなデバイス、および履歴的にアクティブであるが、現在休止であるデバイスのレジスタが構築され得る。随意に、ネットワーク監視エンジン７８は、Ｓｉｍｐｌｅ Ｎｅｔｗｏｒｋ Ｍａｎａｇｅｍｅｎｔ Ｐｒｏｔｏｃｏｌバージョン３（ＳＮＭＰ ｖ．３）などのプロトコルを使用して、ネットワーク１０の階層を調査し、関係する分析デバイスを識別する。ネットワーク監視エンジン７８は、データ処理エージェント４０が現在ネットワーク１０に接続されている分析デバイスの正確なインプレッション（ｉｍｐｒｅｓｓｉｏｎ）を維持することを可能にする。

データ処理エージェント４０は、注釈エンジン８０を備え得る。注釈エンジン８０は、注釈データを取得するように構成される。注釈データは、たとえば、ポイントオブケアデバイスマネージャなどの医療専門家によってＰＯＣ－ＤＭＳ内に入力される非構造化または半構造化テキストである。注釈データは、「２０／３／２０１９－ＰＯＣ Ｐ３Ａはセンサークリーニングが必要です、夜間にクリーニングしてください」など、フリーテキストコメントを指し得る。注釈データは、分析デバイスから受信された、または少なくとも１つの自動通知の１つまたは複数の特性を識別するために、もしくは少なくとも１つの分析デバイスの状態を推論するために、使用される、自動通知データと融合され得る。したがって、注釈エンジン８０は、識別エンジン６７または推論エンジン６８におけるプロセスと組み合わせて注釈を使用する前に、関係する注釈を取得および処理するために注釈データベース７３を調査するように構成される。これは、自動通知が、たとえば、技術的により良好にコンテキスト化されることを許可し得る。

データ処理エージェント４０は、モデル生成器７９を備え得る。受信された自動通知に基づいて、モデル生成器７９は、分析デバイスの状態の推論を生成するために使用されるモデルを調整または再計算するように構成され得る。モデル生成器７９は、自動通知を入力するために機械学習手法を適用し得る。モデルは、規則ベースのモデル、線形回帰、決定木、サポートベクトル機械、ｋ最近傍法モデル、ランダムフォレストモデル、オートエンコーダ、畳み込みニューラルネットワーク、再帰的ニューラルネットワーク、ディープビリーフネットワーク、または転移学習モデルのうちの１つまたは複数を使用して取得され得る。モデルが機械学習を使用して生成されることは、必須ではない。事前定義された論理規則に基づく固定モデルが推論エンジン６８内で提供され得る。

このモデルは、ネットワーク１０内の分析デバイスの１つまたは複数の機能の行動を特徴付けることができる。モデルは、サブモデルを備え得る。言い換えれば、第１のタイプのモデルは、分析デバイスの電源性能を追跡するために使用され得、第２のタイプのモデルは、分析デバイスの機構および／またはセンサーサブシステムを追跡するために使用され得る。

データ処理エージェント４０は、アナライザタイプモニタ７６を備え得る。アナライザタイプモニタ７６の目的は、ネットワーク１０に接続された各分析デバイスＰ１Ａ～Ｐ７Ａ、Ｐ１Ｂ～Ｐ７Ｂに対して、各分析デバイスＰ１Ａ～Ｐ７Ａ、Ｐ１Ｂ～Ｐ７Ｂの一意の製造会社モデルを識別することである。したがって、ネットワーク監視エンジン７８は、未知の分析デバイスＰ３Ｂのネットワーク１０への接続を検出し得る。ネットワーク監視エンジン７８は、未知の分析デバイスＰ３Ｂがネットワーク１０に接続されていることをアナライザタイプモニタ７６にシグナリングし得る。アナライザタイプモニタ７６は、未知の分析デバイスＰ３Ｂから識別情報を取得し得る。アナライザタイプモニタ７６は、未知の分析デバイスＰ３Ｂの問合せを指示することによって、または未知の分析デバイスＰ３Ｂからの自動通知の積極的な監視（「スニッフィング」）によって、のいずれかで、識別情報を取得し得る。たとえば、識別情報は、製造会社識別コード、またはファームウェアバージョンコードであり得る。

アナライザタイプモニタ７６は、次いで、分析デバイスタイプを未知の分析デバイスＰ３Ｂに割り当てるために、アナライザタイプデータベース７１とインターフェース接続し得る。

データ処理エージェント４０は、アナライザ特性検出エンジン７７を備え得る。アナライザ特性検出エンジン７７の機能は、多数の自動通知の中から、一意であるかまたは固定タイプの分析デバイスを識別する可能性が高い自動通知のパターンを識別することである。したがって、アナライザタイプデータベース内の各タイプ記録Ｐ（ｘ）に対して、関連するアナライザ自動通知アルファベットＭｐ（ｘ）が存在する。アナライザ自動通知アルファベットＭｐ（ｘ）は、所与のアナライザが送信し得る自動通知のセットを特徴付ける。

さらに、アナライザタイプデータベース内の各タイプ記録Ｐ（ｘ）はまた、関連する分析デバイスの技術的状態または事象を潜在的に特徴付ける特性のセット（様々な時間間隔における、様々なタイプの自動通知の組合せなど）をやはり備え得る。１つの効果は、特性のセットを監視することが、データ処理エージェントにおいて受信される自動通知の大きなセットから状態または事象が識別されることを可能にすることである。

さらに、データ処理エージェント４０は、必須ではないが、それでもなお、有利な特性を実施形態に提供する、１つまたは複数の補助的データベースとインターフェース接続し得る。補助的データベースについて次に説明する。

通知データベース７０は、ネットワーク１０に接続された分析デバイスＰ１Ａ～Ｐ７Ａ、Ｐ１Ｂ～Ｐ７Ｂから受信される複数の分析デバイス通知を備える。一実施形態では、データ処理エージェント４０は、ネットワーク１０からの生データを処理する。別の実施形態では、データ処理エージェント４０は、通知データベース７０内に記憶された履歴データを処理し得る。

随意に、通知データベース７０内の少なくとも１つの自動通知は、標示７０ｂに関連付けられ得る。たとえば、ユーザは、分析デバイスＰ１Ａ内の識別された保守管理故障に関連する通知データベース７０ｂ内の自動通知のセットを閲覧し得る。ユーザは、識別された自動通知のセットが識別された保守管理故障に関連付けられるという標示を定義し得る。

分析デバイスＰ１Ａ～Ｐ７Ａ、Ｐ１Ｂ～Ｐ７Ｂによって送られた複数の自動通知は、通知データベース７０内に随意に記憶される。通知データベース７０は、すべての自動アナライザＰ１Ａ～Ｐ７Ａ、Ｐ１Ｂ～Ｐ７Ｂからのすべての履歴自動通知を記憶し得る。通知データベース７０は、代替として、分析デバイスＰ１Ａ～Ｐ７Ａのサブセットから自動通知を記憶し得る。

随意に、通知データベース７０は、（たとえば、通知が一定の年数を超える場合など）削除基準に従って自動通知を削除し得る。

随意に、少なくとも１つのタイプの自動通知に対して、データ処理エージェントの動作に先立って、またはデータ処理エージェントの動作中、のいずれかで、自動通知の１つまたは複数の特性パターン７０ａが定義され、たとえば、通知データベース７０内に関連テーブルとして記憶され得る。１つまたは複数の特性パターンは、１つまたは複数の分析デバイスから送信された自動通知を使用して、１つまたは複数の特性の識別を可能にする。

アナライザタイプデータベース７１は、ネットワーク１０上で使用され得る分析デバイスタイプのセットを定義するデータ記録のセットを記憶する。アナライザタイプデータベース内の各分析デバイスタイプ記録Ｐ（ｘ）に対して、関連するアナライザメッセージアルファベットＭｐ（ｘ）が存在する。アナライザタイプデータベース内の各分析デバイスタイプ記録Ｐ（ｘ）に対して、分析デバイスの製造会社によって定義された初期モデルまたは複数の初期サブモデルが提供され得る。

随意に、タイプデータベース７０からの１つまたは複数の特性パターン７０ａは、少なくとも１つの通知の１つまたは複数の特性を識別するために着信自動通知データと比較され得る。

たとえば、識別エンジン６７が「ドアの目詰まり」を報告する１つの自動通知が平均で３か月ごとに分析デバイスＰ１Ａによって発行されているという自動通知の識別された特性を通信する場合、モデルは、分析デバイスＰ１Ａの状態はドア機構が保守管理を必要としないようなものであるという推論を可能にし得る。しかしながら、識別エンジン６７が３つのアッセイのうち１つを超えるアッセイが結果として分析デバイスＰ１Ａから「ドアの目詰まり」を報告する自動通知をもたらすという自動通知の識別された特性を通信する場合、推論エンジン６８によって適用されるモデルは、たとえば、ドア機構障害のより高いリスクがあるとしてＰ１Ａを分類し得る。

初期モデルは、たとえば、未使用状態にあるとき、または所与の使用時間数の後で、初期モデルが参照するタイプの分析デバイスの予想される状態を定義する。

モデルデータベース７２は、たとえば、ネットワーク１０内でアクティブであるか、またはずっとアクティブである、分析デバイスのモデルのレジストリとして機能する。モデルデータベース７２は、一例では、アクティブアナライザパーティション７２ａおよび休止アナライザパーティション７２ｂに分割される。例示される例では、分析デバイスＰ５Ａは、ネットワーク監視エンジン７８によって識別されるようにネットワーク１０に最近接続され、したがって、そのモデル記録は、休止パーティション７２ｂからアクティブパーティション７２ａに移動されている。

分析デバイスＰ１Ａがネットワーク１０に接続され、モデルデータベース７２内のその付随するモデルＰ１Ａ（Ｍ）がアクティブパーティション７２ａ内にあるとき、識別エンジン６７によって識別される自動通知の特性に基づいて推論エンジン６８によって推論される分析デバイスＰ１Ａの１つまたは複数の態様の現在の状態を追跡するために、モデルＰ１Ａ（Ｍ）は更新される。言い換えれば、モデルＰ１Ａ（Ｍ）は、モデルデータベース７２ａのアクティブパーティション内にあるとき、１つまたは複数の関連で分析デバイスＰ１Ａの技術的状態を反映する。たとえば、測光メータセンサーの技術的状態は、経時的に受信された「測光メータクリーン」メッセージの数および組合せから推論され得る。

一例では、モデルＰ１Ａ（Ｍ）は、分析デバイスＰ１Ａの少なくともバッテリー状態を追跡し得る。ネットワーク監視エンジン７８が分析デバイスＰ１Ａのネットワーク１０への接続を検出するとき、前のバッテリー充電特徴を保持する、付随するモデルＰ１Ａ（Ｍ）は、モデルデータベース７２の休止パーティション７２ｂからアクティブパーティション７２ａに移動される。

モデルＰ１Ａ（Ｍ）は、分析デバイスＰ１Ａのバッテリーの現在の充電に関する情報のみではなく、充電時間および強度に関する履歴情報を含有し得る。たとえば、短い充電持続時間の繰り返しの使用は、一定のタイプのバッテリーの接続性を通常よりも早く低減し得る。この例では、推論エンジン６８は、識別エンジン６７によって識別された特性に基づいて充電状態を推論し得る。推論エンジン６８は、バッテリー充電持続時間を追跡するためにモデルＰ１Ａ（Ｍ）を更新し得る。その後、これは、アナライザＰ１Ａのバッテリーが充電行動により予想されるよりも早く劣化するリスクがあった場合、通知生成器が警告を生成することを可能にすることになる。

注釈データベース７３は、検査室または他の医療関係者によって提供される非構造化または半構造化注釈を備えた記録を記憶する。注釈データベース内の記録の分析デバイスから受信された自動通知データとの融合は、分析デバイスの推論された状態を報告する通知の精度を改善し得る。

随意に、複数の自動化通知の１つまたは複数の識別された特性の識別は、注釈データの一部分と複数の自動化通知の間の比較に基づいて実行される。たとえば、自動化通知のサブセットは、注釈データの部分に基づいてモデルを使用して後続の推定ステップに対して選択され得る。たとえば、特定の時点におけるバッテリー故障を参照する注釈コメントは、特定の時点において、またはその近位で、受信される自動化通知に複数の自動化通知をウィンドイングするために使用され得る。自動化注釈のタイプは、注釈データに基づいてサブサンプリングされ得る。たとえば、バッテリーの調子に関する注釈は、１つまたは複数の識別された特性の識別をバッテリーに接続された自動化通知のサブセットに基づかせることが可能である。

随意に、少なくとも１つの分析デバイスの状態の推論は、注釈データに基づく影響を受けてよい。たとえば、注釈データは、機械学習モデルの入力レイヤに提供され得る。自動通知は、同じ機械学習モデルの入力レイヤに提供され得る。モデルは、注釈データと自動通知の両方に基づいてトレーニングされ得る。

ユーザデータベース７４は、ネットワーク１０内の１つまたは複数の分析デバイスの許可されたユーザのレジスタを備える。一例では、分析デバイスＰ１Ａから受信された自動通知は、ユーザデータベース７４内のユーザ記録に関連付けられ得る。したがって、分析デバイスＰ１Ａ～Ｐ７Ａ、Ｐ１Ｂ～Ｐ７Ｂの１人または複数のユーザに基づく分析デバイス保守管理傾向が検出され得る。機密性を確実にするために、ユーザデータベース７４の適切な匿名化が提供され得る。

保守管理データベース７５は、ネットワーク１０に対して選ばれた、またはネットワーク１０に履歴的に接続されている、少なくとも１つの分析デバイスに対する保守管理記録７５ａ、７５ｂを備える。随意に、同じ病院現場１９Ａにおけるアナライザのグループは、ジョイント保守管理記録内に維持され得る。保守管理記録７５ａは、分析デバイスＰ１Ａに対して、分析デバイスＰ１Ａから受信された自動通知に基づいて使用中に更新されるように、モデルＰ１Ａ（Ｍ）に基づいて分析デバイスＰ１Ａの態様の予想される保守管理状態を定義する。保守管理記録７５ａは、アクティブモデルデータベース７２ａまたは休止モデルデータベース７２ｂ内の１つまたは複数のモデルのステータスに基づいて、ネットワーク１０内の１つまたは複数の分析デバイスに対する諮問または強制保守管理活動を含有する報告の生成を可能にし得る。たとえば、報告は、複数の置換可能な分析デバイス構成要素の「バスタブ信頼性曲線」に対して予想されるロケーションの視覚的表示を提供し得る。

データ処理エージェント４０の一例の動作について次に論じる。

ユーザは、分析デバイスＰ１Ａをネットワーク１０Ａに接続し得る。サーバ２３上で実行するデータ処理エージェント４０はまた、通信ネットワーク（広域ネットワーク）２１を介してネットワーク１０Ａに通信可能に結合される。ネットワーク監視エンジン７８は、分析デバイスＰ１Ａのネットワーク１０Ａへの接続を検出する。ネットワーク監視エンジン７８は、分析デバイスＰ１Ａのネットワーク１０Ａへの接続についてアナライザタイプモニタ７６に知らせる。アナライザタイプモニタ７６は、受信エンジン６６を介して分析デバイスＰ１Ａから少なくとも１つの自動通知を受信する。アナライザタイプモニタ７６は、少なくとも１つの自動通知内の分析デバイスＰ１Ａの製造会社コードなど、識別子を識別し、タイプデータベース７１内の分析デバイスＰ１Ａの割り当てられたタイプをルックアップする。アナライザタイプモニタ７６は、モデルデータベース７２内の識別子をさらにルックアップする。

識別子がモデルデータベース７２内の休止部分７２内に存在しない分析デバイスＰ１Ａのタイプを参照する場合、データ処理エージェント４０は、識別子が参照する分析デバイスＰ１ＡのタイプのモデルＰ１Ａ（Ｍ）のコピーを取得し、モデルデータベース７２のアクティブ部分内でモデルＰ１Ａ（Ｍ）のコピーをインスタンス化する。さらに、分析デバイスＰ１Ａの現在の状態の１つまたは複数の態様を反映する、推論エンジン６８によってモデルＰ１Ａ（Ｍ）に行われた変更の日付がモデルデータベース７２のアクティブセクション７２ｂ内でもやはり定められるように、モデルＰ１Ａ（Ｍ）のコピーは、データ処理エンジン４０の推論エンジン６８にリンクされる。

代替事例は、識別子がモデルデータベース７２の休止部分７２ｂ内に存在するモデルを備えた分析デバイスＰ３Ａを参照することである。これは、分析デバイスＰ３Ａがネットワーク１０内ですでに使用されていることを意味する。この場合、モデルＰ３Ａ（Ｍ）は、モデルデータベース７２のアクティブ部分７２ａに移動され、推論エンジン６８内でインスタンス化される。

受信エンジン６６は、分析デバイスＰ１Ａから自動通知を連続的に受信する。この例では、識別エンジン６７は、受信された自動通知の少なくとも１つの特性を識別するために、受信された自動通知を連続的に監視する。たとえば、識別エンジン６７は、所与の時間期間内に６つの「バッテリー低」警告のシーケンスを識別し、その特性が分析デバイスＰ１Ａからの複数の自動通知内で識別される場合、データ処理エージェント４０内の論理フラグをアサートする。

推論エンジン６８内のモデルＰ１Ａ（Ｍ）は、分析デバイスＰ１Ａのバッテリーステータスの状態を推論するように構成されたサブモデルを備え得る。所与の時間期間内の６つの「バッテリー低」警告のシーケンスを表す論理フラグのアサート時に、推論エンジン６８内のＰ１Ａ（Ｍ）は、分析デバイスＰ１Ａ上で所定の時間期間内に６つの「バッテリー低」警告の発生の効果をモデル形成するために更新される。たとえば、ドア機構に関する「バッテリー交換する時間」変数は減少し得、かつ／または分析デバイスＰ１Ａのバッテリーの状態を反映する状態変数は、加速したバッテリー障害の機会増大を反映するように更新され得る。

通知生成器６９は、この例では、加速したバッテリー障害の機会増大を報告する通知を生成するように構成される。通知生成器６９は、新しく接続された分析デバイスＰ１Ａに対する新しい保守管理報告を生成し、加速したバッテリー障害の機会増大を報告する通知を報告内に入力する。

最終的に、ユーザは、分析デバイスＰ１Ａの電源を切るか、または分析デバイスＰ１Ａをネットワーク１０Ａから切断することができる。この活動は、ネットワーク監視エンジン７８によって検出され、データ処理エンジン４０に報告される。応答して、推論エンジン６８内のモデルＰ１Ａ（Ｍ）の現在の状態（および、モデルデータベース７２のアクティブパーティション７２ａ内のモデルＰ１Ａ（Ｍ）の付随するエントリーは凍結される。モデルＰ１Ａ（Ｍ）（分析デバイスＰ１Ａのバッテリー状態の正確な概要を少なくとも含有する）は、分析デバイスＰ１Ａがネットワーク１０Ａに再度接続されるまで、モデルデータベース７２の休止パーティション７２ａにコピーされる。

図７ａは、分析デバイスの特性の識別および状態の後続の推論の例示的な時間事象プロットを概略的に例示する。時間軸８４は、ＰＯＣコンテキストにおける典型的なシフトの持続時間を示す。分析デバイスからの自動通知フローの一例を例示するために、異なるタイプの自動通知のセット８２の一例が時間軸８４に対してプロットされる。時間事象プロット内の各正方形エントリーは、分析デバイスＰ１Ａからのネットワーク１０を介した１つのデータパケットの送信を表す。

一例では、受信された自動通知のすべては、モデルＭｐ（ｘ）に直接提供され得、モデルは、分析デバイスの状態を直接推論し得る。たとえば、モデルは、１つのオプションとして、畳み込みニューラルネットワークを使用して生成された深層学習モデルであり得る。したがって、第１の態様による少なくとも１つの分析デバイスから、少なくとも１つの自動通知に基づいて分析デバイスの１つまたは複数の特性を識別するステップは、いくつかの実施形態では、必須ではない。少なくとも１つの分析デバイスＰ１Ａの状態の推論は、すべての受信された自動通知に、またはすべての受信された自動通知のサブサンプリングに基づいて行われ得る。

自動通知の第１のグループ（サブセット）８１は、実行されている６つのアッセイの特性の一例を表し、実行される各アッセイに対して自動通知「ｓｃａｎ＿ｂａｒｃｏｄｅ」、「ｒｅｐｏｒｔ＿ｂａｒｃｏｄｅ」、「ａｓｓａｙ＿ｌｏａｄｅｄ」、および「ｔｅｓｔ＿ｒｅｓｕｌｔ」が順番に発行される。

自動通知の第２のグループ８３は、バッテリー故障の展開の特性の一例を表す。多くのタイプのバッテリーがバッテリー信頼性欠如の小さなリスクを持っており、バッテリー故障の展開の検出は望ましいことがある。たとえば、繰り返される「ｔｅｍｐ＿ｈｉ＿９０％」信号の発生は、単独では、分析デバイスＰ１Ａが日当たりのよい窓辺に残されていることをただ暗示し得る。しかしながら、繰り返される「ｔｅｍｐ＿ｈｉ＿９０％」の発生、および所定の時間期間ｔ₁の後、繰り返される「ｂａｔｔ＿ｌｏｗ＿１０％」通知、および最終的に単一の「ｂａｔｔ＿ｓｈｕｔｄｏｗｎ」通知の発生は、あまりにも急速に放電していることによりバッテリーが過熱していることを示すことにより、バッテリー障害状態が示され得る。第１の「ｔｅｍｐ＿ｈｉ＿９０％」と第１の「ｂａｔｔ＿ｌｏｗ＿１０％」通知の間の開始の速度は、バッテリー障害の深刻さがモデル形成されることを可能にし得る。

「ｔｅｍｐ＿ｈｉ＿９０％」、「ｂａｔｔ＿ｌｏｗ＿１０％」、および「ｂａｔｔ＿ｓｈｕｔｄｏｗｎ」メッセージを識別することは、したがって、モデル内に後で入力され得る自動通知のサブセットの特性の識別であり得る。

自動通知の第３のグループ８５は、分析デバイスのスタートアップ活動を表す。

自動通知の第４のグループ８６ａ、８６ｂは、分析デバイスの通常の動作を示す「ハートビート」信号を表す。

特定の事例における自動通知のセットのこの特定の例は、限定的でないことを当業者は諒解されよう。１つまたは複数の分析デバイスからの異なるカテゴリの自動通知を使用して、多くの異なる特性が識別され得る。たとえば、品質制御障害を示す、２つの異なる分析デバイスＰ１ＡおよびＰ２Ａからの自動通知が検出され得る。自動通知のそのようなセットは、モデルを使用して、検査室内で使用される試薬のバッチに欠陥があることを後で推論するために使用され得る特性である。

言い換えれば、少なくとも１つの自動通知の１つまたは複数の特性の識別は、少なくとも１つの分析デバイスの状態を推論するためにモデルを使用するのに先立って、受信された自動通知のセット全体のサブサンプリングとして閲覧され得る。

図７ｂは、図７ａの時間事象データ内で識別される少なくとも１つの自動通知の特性の処理を概略的に例示する。

第１のデータ構造８３ａは、「ｔｅｍｐ＿ｈｉ＿９０％」通知が発行された時間を定義する、アナライザＰ１Ａからの９つ自動通知を備える。第２のデータ構造８０ ３Ｂは、「ｂａｔｔ＿ｌｏ＿１０％」通知が発行された時間を定義する、アナライザＰ１Ａからの５つの自動通知を備える。

第１の「ｔｅｍｐ＿ｈｉ＿９０％」通知の発行から０９：３０における「ｂａｔｔ＿ｓｈｕｔｄｏｗｎ」通知（分析デバイスＰ１Ａの停止を暗示する）の発行までの時間中、バッテリー故障の結果として分析デバイスが停止する確率について推論が行われ得る。この時間中、１つまたは複数の特性８３ａおよび８３ｂがモデル８８に適用される。１つまたは複数の特性８３ａおよび８３ｂは、２つの時系列を形成する。時系列を事前計算されたモデル８８に適用することによって、分析デバイスの存在および／または将来の状態の推論が行われ得る。この場合、推論ベクトル９０は、受信された「ｔｅｍｐ＿ｈｉ＿９０％」および「ｂａｔｔ＿ｌｏ＿１０％」通知に基づいて、バッテリー障害が生じることになるシフト過程の時間の確率の予想を表す。

バッテリー性能の事前計算モデルは、バッテリー製造会社から、またはシステム１０にわたってキャプチャされるデータから取得され得る。随意に、バッテリー性能の事前計算モデルは、多くの選択肢のうちの１つとして、自己回帰和分移動平均（ＡＲＩＭＡ）、関連ベクトルマシン、Ｋａｌｍａｎフィルタ、または粒子フィルタを使用して生成され得る。前述の説明はバッテリー障害状態の可能性を推論する特定のシナリオを参照するが、システム１０内の１つまたは複数の分析デバイスの状態を推論するために、自動通知によって表される時系列データが使用され得ることを当業者は認識されよう。

一態様によれば、ネットワーク１０Ａから受信された複数の自動通知に基づいて、分析デバイスＰ１Ａの状態を推論するためのモデルＰ１Ａ（Ｍ）を生成するためのコンピュータ実装方法が提供される。この方法は、
１つまたは複数のネットワーク１０Ａ、１０Ｂ内で１つまたは複数の分析デバイスＰ１Ａ～Ｐ７Ａ、Ｐ１Ｂ～Ｐ７Ｂから複数の自動通知を受信することであって、複数の自動通知の少なくとも１つのサブセットが、１つまたは複数の分析デバイスＰ１Ａ～Ｐ７Ａ、Ｐ１Ｂ～Ｐ７Ｂのうちの少なくとも１つの少なくとも１つの状態に関連付けられる、複数の自動通知を受信することと、
モデルＰ１Ａ（Ｍ）を生成するためのトレーニングデータとして複数の自動通知を使用してモデルＭｐ（ｘ）をトレーニングすることであって、モデルＭｐ（ｘ）が、複数の受信された自動通知と１つまたは複数の分析デバイスＰ１Ａ～Ｐ７Ａ、Ｐ１Ｂ～Ｐ７Ｂのうちの少なくとも１つの少なくとも１つの状態の間の関係を提供する、モデルＭｐ（ｘ）をトレーニングすることと
を備える。

一例では、モデルＭｐ（ｘ）は、データ処理エージェント４０のモデル生成器７９を使用してトレーニングまたは生成される。

一例では、モデルは、１つまたは複数の分析デバイスからの時系列データを使用してトレーニングまたは生成される。このモデルは、多くの選択肢のうちの１つとして、自己回帰和分移動平均（ＡＲＩＭＡ）、関連ベクトルマシン、Ｋａｌｍａｎフィルタ、または粒子フィルタを使用してトレーニングまたは生成され得る。

一例では、モデルのトレーニングの後、モデルＭｐ（ｘ）は、データ処理エージェント４０のタイプデータベース７１および／またはモデルデータベース７２内に記憶される。

一例では、モデルＭｐ（ｘ）は、一意のタイプＰ（ｘ）の分析デバイスに関連付けられる。一例では、モデルＭｐ（ｘ）は、データ処理エージェント４０にアクセス可能なタイプデータベース７１内の一意のタイプＰ（ｘ）の分析デバイスに関連付けられる。

一例では、モデルＭｐ（ｘ）は、外部サーバなど、外部コンピュータ処理手段によってトレーニングまたは生成され得る。モデルＭｐ（ｘ）は、外部サーバによってデータ処理エージェント４０に送信される。データ処理エージェント４０への送信の後、モデルＭｐ（ｘ）は、データ処理エージェント４０のタイプデータベース７１および／またはモデルデータベース７２内に記憶される。

一例では、複数の自動通知内のトリガ通知の存在は、トリガ通知に関する特性を表す自動通知のサブセットに対してモデルＭｐ（ｘ）をトレーニングまたは保つようにデータ処理エージェント４０をトリガし得る。

一例として、図７ａでは、通知「ｂａｔｔ＿ｓｈｕｔｄｏｗｎ」は、「ｂａｔｔ＿ｓｈｕｔｄｏｗｎ」通知が送信された時間に先行する任意の時間窓内で最初に履歴「ｂａｔｔ＿ｌｏ＿１０％」および「ｔｅｍｐ＿ｈｉ＿９０」通知を識別するためのトリガ通知としてサービスし得る。モデルＭｐ（ｘ）は、識別された履歴通知に基づいてモデルをトレーニングまたは保つことによって更新され得る。有利には、これは、自動通知に適用されたモデルがシステム１０内の変更に適応することを可能にする。たとえば、バッテリーの例では、バッテリーサプライヤが変更された場合、そのようなバッテリーの放電および障害の予測に関するモデルは、１つの分析デバイスＰ１Ａに対して、またはネットワーク１０上のそのタイプのすべての分析デバイスに対して、動的に更新され得る。

第１の態様の一実施形態によれば、モデルは、少なくとも１つの自動通知をデータ処理エージェント４０に送信するために使用される分析デバイスＰ１Ａ～Ｐ７Ａ、Ｐ１Ｂ～Ｐ７Ｂのタイプを少なくとも部分的に特徴付ける。

データ処理エージェントは、特定の分析デバイスＰ１Ａから受信された自動通知に基づいて、特定の分析デバイスＰ１Ａが使用されるにつれて、そのＰ１Ａに関連するモデルインスタンスＰ１Ａ（Ｍ）を更新し得る。したがって、モデルインスタンスＰ１Ａ（Ｍ）は、分析デバイスＰ１Ａの異なる部分に対する複数のサブモデルを備え得る。サブモデルは、電源２２、センサーデバイス２４、電気機械サブアセンブリ２６、標本処理セクション２８、および分析ユニット３０のうちの１つまたは複数に対して提供され、モデルインスタンスＰ１Ａ（Ｍ）の現在または履歴ステータスを参照することによって、分析デバイスＰ１Ａの保守管理状態の追跡を可能にし得る。

第１の態様の一実施形態によれば、モデルは、規則ベースのモデル、線形回帰、決定木、サポートベクトル機械、ｋ最近傍法モデル、ランダムフォレストモデル、オートエンコーダ、畳み込みニューラルネットワーク、再帰的ニューラルネットワーク、ディープビリーフネットワーク、または転移学習モデルのうちの１つまたは組合せである。

第１の態様の一実施形態によれば、この方法は、データ処理エージェント４０において、さらなる分析デバイスＰ１Ａ～Ｐ７Ａ、Ｐ１Ｂ～Ｐ７Ｂのネットワークへの接続を検出することと、データ処理エージェント４０において、さらなる分析デバイスが（ｉ）事前にネットワークに接続されているか、または（ｉｉ）事前にネットワークに接続されていないか、を識別することとを備える。

さらなる分析デバイスが事前にネットワークに接続されている場合、この方法は、データ処理エージェント４０において、モデルとして使用するために、記憶されたモデルをローディングすることであって、記憶されたモデルが、さらなる分析デバイスがネットワークから切断された前の時点におけるさらなる分析デバイスの状態を特徴付ける、モデルをローディングすることと、データ処理エージェント４０において、少なくとも１つの分析デバイスからの少なくとも１つの自動通知の１つまたは複数の特性を識別するために、さらなる分析デバイスからの少なくとも１つの自動通知を処理することとを備える。さらに、この方法は、データ処理エージェント４０において、１つまたは複数の識別された特性を記憶されたモデルに適用することによって、少なくとも１つの分析デバイスの状態を推論することを備える。

第１の態様の一実施形態によれば、この方法は、データ処理エージェント４０において、さらなる分析デバイス（Ｐ１Ａ～Ｐ７Ａ、Ｐ１Ｂ～Ｐ７Ｂ）のネットワークへの接続を検出することを備える。

さらなる分析デバイスＰ１Ａ～Ｐ７Ａ、Ｐ１Ｂ～Ｐ７Ｂが事前にネットワークに接続されていない場合、この方法は、データ処理エージェント４０において、さらなる分析デバイスのタイプを識別することと、データ処理エージェント４０において、モデルとして使用するために追加のモデルをインスタンス化することであって、追加のモデルが、識別されたタイプのさらなる分析デバイスに関連付けられる、追加のモデルをインスタンス化することと、データ処理エージェント４０において、１つまたは複数の識別された特性を追加のモデルに適用することによって、さらなる分析デバイスの状態を推論することとを備える。

一実施形態によれば、モデルは、少なくとも１つの分析デバイスＰ１Ａ～Ｐ７Ａ、Ｐ１Ｂ～Ｐ７Ｂの以下の状態、すなわち、（ｉ）センサー障害状態、（ｉｉ）センサー信頼性欠如状態、（ｉｉｉ）熱故障状態、（ｉｖ）ソフトウェアまたはファームウェア故障状態、（ｖ）品質制御故障状態、（ｖｉ）機械故障状態、（ｖｉｉ）バッテリー故障状態、（ｖｉｉｉ）物理的衝撃状態、および／または（ｉｘ）セキュリティ故障状態のうちの少なくとも１つ、またはそれらの開始を識別するように構成される。

一態様によれば、この方法は、データ処理エージェント４０において、少なくとも１つの分析デバイスＰ１Ａ～Ｐ７Ａ、Ｐ１Ｂ～Ｐ７Ｂから第２の自動通知を受信することによって、データ処理エージェント４０において、少なくとも１つの分析デバイスＰ１Ａ～Ｐ７Ａ、Ｐ１Ｂ～Ｐ７Ｂからの少なくとも１つの自動通知の１つまたは複数の特性を識別するために、少なくとも１つの自動通知を備えたデータを処理することをさらに備える。

少なくとも１つの自動通知および第２の自動通知は、それぞれ、第１および第２の時点において少なくとも１つの分析デバイスＰ１Ａ～Ｐ７Ａ、Ｐ１Ｂ～Ｐ７Ｂによって生成される。

この方法は、第１および第２の時点に基づいて、少なくとも１つの自動通知と第２の自動通知の間の時間関係を検出することと、検出された時間関係に少なくとも基づいて、１つまたは複数の特性を識別することとをさらに備える。

随意に、識別はまた、少なくとも１つの自動通信および／もしくは第２の自動通知のタイプ、ならびに／または少なくとも１つの自動通信および第２の自動通知が由来する分析デバイスのタイプに基づく。

一態様によれば、この方法は、データ処理エージェント４０において、ネットワーク内の少なくとも１つの分析デバイスＰ１Ａ～Ｐ７Ａ、Ｐ１Ｂ～Ｐ７Ｂの１つまたは複数のコンテキストを識別することと、識別されたコンテキストにさらに基づいて、モデルを提供または更新することとをさらに備える。

分析デバイスＰ１Ａは、異なる病棟、検査室、病院現場の間で、使用中に、移動され得るか、または在宅看護訪問にすら用いられ得る。これらは、分析デバイスＰ１Ａが、いくつかの例として、異なる職員によって使用され得る、異なる検査パターンを生成するために使用され得る、または異なる試薬の源とともに使用され得る、異なるコンテキストまたはロケーションを表す。コンテキストまたはロケーション内の変化は、分析デバイスＰ１Ａの異なる絶対確実な状態をもたらし得る。

たとえば、ネットワーク監視エンジン７８は、ネットワーク１０にアクセスするために使用されるネットワークアドレスの変化を使用して、分析デバイスＰ１Ａから自動通知のネットワーク１０上のソースを識別し得る。たとえば、モデルインスタンスＰ１Ａ（Ｍ）は、１つまたは複数の異なるコンテキスト内の分析デバイスの使用を表す１つまたは複数のサブモデルで補完され得る。

一態様によれば、この方法は、データ処理エージェント４０において、ネットワークを介して少なくとも１つの注釈データ項目を受信することと、データ処理エージェント４０において、１つまたは複数の注釈データ項目を少なくとも１つの自動通知のうちの１つまたは複数に関連付けることと、少なくとも１つの注釈データ項目と少なくとも１つの自動通知の関連付けにさらに基づいて、少なくとも１つの分析デバイスＰ１Ａ～Ｐ７Ａ、Ｐ１Ｂ～Ｐ７Ｂの状態を推論することとをさらに備える。

ＰＯＣ管理スタッフは、シフト中に彼らのケアの対象である１つまたは複数の分析デバイスの状態をロギングするノートブックを維持する。ノートブックは、本明細書で論じる技法に従って、推論された状態の精度を高めるために使用され得る、１つまたは複数の分析デバイスから受信される自動通知のうちの１つまたは複数で融合され得るメタデータの非構造化または半構造化ソースを表す。たとえば、電子検査室ノートブック内の各エントリーは、タイムスタンプされ、したがって、時間の点で自動通知と容易に相関され得る。

例では、電子検査室ノートブック内のエントリーのキーワードは、自動通知の特性の識別を変えるために、または分析デバイスの状態の影響を変えるために、識別および使用され得る。

当然、注釈データは、物理的検査室ノートブック内の非電子注釈として提供され、光学式文字認識を使用して注釈データに変換され得る。注釈データは、音声信号が音声認識ソフトウェアを使用して注釈データに変換されるときに提供され得る。

図８は、自動通知を注釈データに関連付けるための注釈エンジン８０の一例を概略的に例示する。

図８に例示される注釈エンジン８０は、一実施形態では、サーバ１２のデータ処理エージェント内で実行するソフトウェアエンジンとして実装される。別の実施形態では、注釈エンジン９０は、遠隔クラウドサーバ内のソフトウェアエンジンとして実装され、相関された注釈データおよび自動通知をデータ処理エージェントに提供することができる。注釈データは、注釈データベース７３から取得されてもよい。

随意に、注釈エンジン８０は、注釈データおよび自動通知をリアルタイムで（言い換えれば、それぞれのデータが注釈エンジン９０において受信される時点で）相関させ得る。

随意に、注釈データおよび分析デバイスからの自動通知は、注釈データおよび自動通知が分析デバイスにおいて作成された、かつ／またはデータ処理エージェントにおいて受信されたときのタイムスタンプに基づいて、相関されるかまたは関連付けられる。

随意に、注釈データおよび自動通知は、データ処理エージェントにおける注釈データのコンテンツ分析、およびデータ処理エージェントにおいて受信された複数の自動通知の比較に基づいて、注釈エンジン８０によって相関されるかまたは関連付けられる。

代替または追加として、注釈エンジン８０は、データが分析デバイスから受信された時間の後の時点において注釈データおよび自動通知をバッチラン（ｂａｔｃｈ－ｒｕｎ）で相関させ得る。

注釈エンジン８０は、注釈データ受信ユニット９２を備える。注釈データ受信ユニットは、たとえば、上記で論じたモダリティのうちの１つに従ってユーザによって生成された１つまたは複数の注釈データ項目を受信する（テキストアプリケーションからの非構造化または半構造化テキストの受信、手書きコメントのＯＣＲ認識、電子スタイラスからのコメントの認識、オーディオまたはビデオ分析、など）。

注釈エンジン８０は、随意に、注釈データ分類ユニット９３を備える。受信された自動通知は、たとえば、受信時間、メッセージのカテゴリ（ソフトウェア構成、セキュリティ、認証、検査性能、ハードウェアステータス、バッテリーステータス、などに関する）に基づいて分類される。分類は、たとえば、「低バッテリー」、または「クリーン測光メータ」など、異なるタイプの自動通知を意味的概念にリンクする、製造会社によって提供されるプライアーセマンティックスキーマ（ｐｒｉｏｒ ｓｅｍａｎｔｉｃ ｓｃｈｅｍａ）に基づき得る。

注釈エンジン８０は、自動通知分析エンジン９４を備える。分析エンジン９４の機能は、受信された自動通知のセットまたはサブセットから、たとえば、分析デバイスに関する意味的に重要な事象（事象データ）の前の表示を示す自動通知内の傾向のパターンまたは表示を取得することである。

一例では、分析エンジン９４は、所与の時間窓にわたって受信された、受信された注釈データのヒストグラムを取得する。

言い換えれば、自動通知９４は、たとえば、データ内の重要な傾向を識別するために、受信された注釈データに対して、数理分析、もしくは統計分析、または信号処理を実行するように機能する。

随意に、時間窓は構成可能である。時間窓は、一年、一月、一週間、一日であってよく、またはシフトパターンなど、動作上の考慮事項にリンクされてもよい。随意に、時間窓は、分析デバイスの有資格ユーザに関連付けられてよい。

注釈エンジン８０は、重要性エンジン９６を備える。重要性エンジン９６は、データ分析エンジン９４から事象データを受信する。いくつかのタイプの相対的に重要でない自動通知は通常の測定対策として頻繁に送信され得るため（ＰＣＢハートビート信号など）、自動通知の統計分析は偏ることがあることを当業者は諒解されよう。他方で、重要な自動通知、たとえば、分析デバイスが床に落下したことを示す「衝撃」信号は、一回のみ送信され得る。

したがって、重要性エンジン９６の目的は、ルックアップテーブルとしてまたは他の方法で定義され得る、当業者が諒解するような、優先順位付け関数に従って重要な自動通知を優先順位付けするためにデータ分析エンジン９４からのデータをフィルタリングすることである。

注釈エンジン８０は、語彙変換エンジン９８を備える。語彙変換エンジン９８は、重要性エンジン９６から優先順位付けされたアナライザ通知を取得し、重要な分析デバイス通知の対応する語彙概念データへのマッピングを実行する。

語彙概念データは、たとえば、ポイントオブケア機器の製造会社によって定義される。一例として、語彙概念データは、一例では、ユーザが注釈データとして入力した非構造化テキストデータ（たとえば）と１つまたは複数の分析デバイスが出力された自動通知の間に接続性を提供する。各優先順位関数φは、「バッテリー充電」、「アナライザ落下」、「メモリ満杯」など、意味的概念を表す。

自動通知が注釈エンジン８０によって受信されるとき、重要性エンジン９６は、１つまたは複数の自動通知項目のパターンがそのような意味的概念を参照し得ることを識別し、意味的概念を参照する識別子を語彙変換エンジン９８に送信する。

語彙変換エンジン９８は、各意味的概念に対して少なくとも１つの記録を備えた、データ構造、またはデータベースを含有する。各記録は、意味的概念に関連し、分析デバイスユーザによって注釈データ内に提供される関連する非構造化コメント内に存在する可能性が高い、１つまたは複数の語、ワードフラグメント（ｗｏｒｄ ｆｒａｇｍｅｎｔ）、文などを定義する。

注釈エンジン８０は、語彙変換エンジンから少なくとも１つの記録を、かつ（随意に、注釈データ分類ユニット９３によって分類される）注釈データ受信ユニット９２から少なくとも１つの注釈データ項目を受信するように構成された比較エンジン１００をさらに備える。

比較エンジン１００は、注釈データ内で、語彙分析エンジンによって識別された意味的概念に関係する、１つまたは複数の関係する非構造化または半構造化テキスト項目を分離する。

分離されると、関係する非構造化または半構造化テキスト項目は、１つまたは複数の対応する自動通知項目に関連付けられ得る。たとえば、「バッテリーが上がった」ことを告知するログブックエントリーは、分析デバイスＰ１Ａの状態を推論するために使用され得る、１つまたは複数の特徴的な自動通知の識別をトリガし得る。

これは、関係する非構造化または半構造化テキストおよび関連する対応する自動通知が関連付けられる分析デバイスシステムデータ記録が生成されることを可能にする。

随意に、分析デバイスシステムデータ記録は、出力され、データ処理エージェント４０を格納するサーバ内および／または外部の記憶手段内のいずれかにおいて記憶され得る。

一態様によれば、この方法は、相関関係が１つまたは複数の自動通知の生成と１つまたは複数の注釈データ項目の時間関係に基づくこと、または相関関係がデータ処理エージェントにおいて受信される自動通知のタイプに関する１つまたは複数の相関関係規則に基づくこと、をさらに備える。

図９は、相関関係規則セットを使用して自動通知を注釈データと相関させる一例を概略的に例示する。

記録１０４は、非限定的な例において、パーソナルコンピューティングデバイス２６上のグラフィカルユーザインターフェースを介して入力されたテキストから受信され得る、フォーマットされていない非構造化注釈データを例示する。

分析エンジン９４によって生成されたヒストグラム１１４は、この例では、多数のメッセージにより、強調されないことが選好される「ｍｏｔｏｒ＿ＰＣＢ」ハンドシェークを指す、タイプ１１５の自動通知の高い発生率を示す。他方で、分析デバイス通知１１７は、「ｂａｔｔ＿ｌｏ＿１０％」注釈データを指す。電力課題に関する概念を参照する非構造化注釈データを強調することが選好される。

したがって、重要性エンジン９４は、「ｂａｔｔ＿ｌｏ＿１０％」が存在し、強調されるべきであることを検出する。

語彙変換エンジン９８は、バッテリーおよび電力問題に関する概念が識別されるべきであることを識別する。語彙変換エンジン９８内のデータ記録１１６は、重要性エンジン９４の出力を使用して取得される。データ記録１１６は、自動通知によって示される意味的概念を指し得る非構造化テキスト内に潜在的なエントリーのテキストサンプルを提供する。

たとえば、「ｂａｔｔ＿ｌｏ＿１０％」注釈データに関するデータ記録１１６内のテキストサンプルは、テキストフラグメント「バッテリー」、「充電器」、「ケーブル」、「アダプター」、「プラグ」、「ソケット」を備える。

分析デバイスに関する他の意味的概念に対して完全に異なるテキストサンプルがデータ記録１１６内に提供されることになることを当業者は諒解されよう。

比較エンジンは、元の非構造化テキストデータ１０４および語彙変換エンジンによって生成されたデータ記録１１６を受信する。一例では、データ記録１１６内の各テキストサンプルのテキスト検索は、注釈データの非構造化テキストデータ１０６を介して実行される。

１つの事例では、データ記録１１６内の語に完全にかつ／または密に整合する語が標示される。たとえば、「バッテリー」という用語はデータ記録１１６内で発生するため、「低バッテリー照明」１０８という句が標示される。

別の事例では、「充電器」という語は、注釈データの非構造化テキストデータ１０６内で最初に識別され、そのフラグメントの標示は、「充電器」という語に付随する節全体を包含するように拡張される。

したがって、データ記録１１６内のテキストに対する密な整合を識別すること、および／またはデータ記録１１６からのテキストがその中で発生する非構造化注釈データから文または節全体を抽出することが可能である。

一例では、注釈エンジン９０の出力は、１つまたは複数の分析デバイスから受信された分析デバイス通知に関連付けられるテキスト断片１１２のセットである。

一例では、注釈エンジン９０の出力は、注釈データからの関係するテキスト断片の表現としてグラフィカルユーザインターフェース上に直接提供される。

一実施形態によれば、この方法は、データ処理エージェント４０において、分析デバイスＰ１Ａ～Ｐ７Ａ、Ｐ１Ｂ～Ｐ７Ｂの状態を報告する通知を使用して、機器保守管理データベースから記録を取得することであって、機器保守管理データベースが、少なくとも１つの分析デバイスに関する少なくとも１つの機器保守管理活動、結果として、分析デバイスの状態を報告する通知を定義する、記録を取得することと、データ処理エージェント４０において、少なくとも１つの機器保守管理活動を備えた機器保守管理通知を生成することとを備える。

たとえば、データ処理エージェント４０が、分析デバイスＰ１Ａが数日中に交換バッテリーを必要とすると推論する場合、保守管理スケジュール内に適切なエントリーが生成され、機器保守管理データベース７５内に記憶され得る。

随意に、保守管理データベース７５は、ネットワーク１０内の個々の分析デバイスＰ１Ａ、Ｐ２Ａに対応する個々の記録７４ａ、７４ｂを備える。

随意に、個々の記録７４ａ、７４ｂは、それぞれの分析デバイスＰ１Ａ、Ｐ２Ａを参照する個々のモデルインスタンスＰ１Ａ（Ｍ）、Ｐ２Ａ（Ｍ）のステータスに基づいて生成および／または更新される。

随意に、データ処理エージェント４０は、ネットワーク１０内の分析デバイスのサブセットに対するカスタム保守管理スケジュールを生成し、カスタム保守管理スケジュールをユーザに表示するように構成される。

随意に、保守管理オペラティブ（ｏｐｅｒａｔｉｖｅ）のスケジュールは、それぞれのモデルインスタンスＰ１Ａ（Ｍ）、Ｐ２Ａ（Ｍ）によって定義されるそれぞれのアナライザの保守管理状態の深刻さに基づいて保守管理タスクの選択を可能にするために、保守管理データベース７５と融合され得る。たとえば、分析デバイスＰ１Ａ内の品質制御結果の悪化は、アナライザＰ２Ａが落下したという検出に続くルーチン損害検査よりも優先され得る。

一態様によれば、この方法は、グラフィカルユーザインターフェースを介して第１の分析デバイスＰ１Ａ～Ｐ７Ａ、Ｐ１Ｂ～Ｐ７Ｂの状態をユーザに表示することを備える。

データ処理エージェント４０は、ネットワーク１０Ａ、１０Ｂ内の１つまたは複数の分析デバイスＰ１Ａ～Ｐ７Ａ、Ｐ１Ｂ～Ｐ７Ｂの状態を追跡し、一例として、分析デバイスの現在の推論された状態を反映させるために、対応するモデルインスタンス（Ｐ１Ａ（Ｍ）など）を更新する。したがって、モデルインスタンスの現在の状態は、ユーザに関するフィードバック情報を導出するために使用され得る。

たとえば、データ処理エージェント４０は、ネットワークＰＯＣ－ＤＭＳ１２Ａのディスプレイ２４Ａ、またはスマートフォン監視ソフトウェア２６Ａなど、ネットワーク１０内のユーザデバイス上に表示され得る、ユーザに対するメッセージを生成し得る。データ処理エージェント４０は、それを通して１つまたは複数のアナライザの推論された状態が認証されたユーザに表示され得るセキュアウェブページを生成し得る。

たとえば、メッセージは、この方法が参照する分析デバイスＰ１Ａのインターフェース上に表示され得る。

データ処理エージェント４０は、ネットワーク１０Ａ、１０Ｂ内の分析デバイスＰ１Ａ～Ｐ７Ａ、Ｐ１Ｂ～Ｐ７Ｂのすべてまたはサブセットのステータスを要約する、組み合わされたディスプレイを生成し得る。

随意に、保守管理データベース７５からのデータに基づいて、保守管理タスクが優先順位付けされた方法で表示され得る。

図１０は、第１の病院（図１０の「病院Ａ」）内の分析デバイスの推論された状態を報告する通知に基づいて生成された第１のグラフィカルユーザインターフェースの一例を概略的に例示する。

グラフィカルユーザインターフェースは、たとえば、ＰＯＣ－ＤＭＳ１２、またはスマートフォン２６インターフェースのウェブブラウザ内に表示され得るブラウザウィンドウ１２０を備える。

随意に、ブラウザウィンドウは、複数の通知を生成した分析デバイスの識別を可能にする識別部分１２２を備える。ブラウザウィンドウは、病院Ａ内の分析デバイス「デバイスＡ」によってデータ処理エージェント４０に送られた自動通知から生成された複数のデバイスメッセージ１２３～１２７を表示するメッセージディスプレイ部分１２１をさらに備える。

随意に、ブラウザウィンドウ１２０は、ユーザが自動通知のうちの１つまたは複数に注釈データを添付することを可能にするボタン１２８を備える。

非公式に、メッセージディスプレイ部分１２１内に例示されるメッセージの履歴を日付順に読み取ることによって、１００個の品質制御障害メッセージ１２７の後に内部センサー障害１２６が生成されたことは明らかである。ユーザは、ユーザがデバイスＡ上にソフトウェアの再インストールを試みたことに言及する注釈データ１２５を追加した。しかしながら、その後に、デバイスが製造会社に送られているという最終的な注釈１２１が続く後続のセンサー障害１２４は、ソフトウェアのインストールがデバイスＡを修復しなかったことを暗示する。メッセージディスプレイ部分１２１内に表示されたメッセージおよび／またはメモは、データ処理エージェント４０のモデルに入力され、第２のネットワーク１０Ｂにおける自動通知および注釈の同様のシーケンスが将来のデバイスの状態のより正確な診断を可能にするようにモデルを更新するために使用される。

図１１は、第２の病院（図１１の「病院Ｂ」）内の分析デバイスの推論された状態を報告する通知に基づいて生成された第１のグラフィカルユーザインターフェースの一例を概略的に例示する。言い換えれば、データ処理エージェント４０は、デバイスＢ、すなわち、第２のネットワーク１０Ｂ内の分析デバイスから複数の自動通知を受信する。

自動通知および第１のネットワーク１０Ａから受信された注釈に基づいてトレーニングされたデータ処理エージェント４０のモデルを使用して、データ処理エージェント４０は、ポップアップボックス１２９によって示されるように、デバイスＢ内の品質制御障害の数が１００に近づくにつれて行うべき活動、この場合、デバイスＢの交換、をユーザに忠告する通知が生成され得ると推論することが可能である。したがって、ユーザは、通知１３０によって忠告されたように、デバイスＢの再インストールを試みない。

推論された状態を報告する通知の視覚表示を提供する多くの方法が提供され得、その中のＧＵＩが１つのオプションとして例示されていることを当業者は諒解されよう。

第２の態様によれば、ネットワークを介して少なくとも１つの分析デバイスＰ１Ａ～Ｐ７Ａ、Ｐ１Ｂ～Ｐ７Ｂから受信された少なくとも１つの自動通知に基づく分析デバイスの状態を推論するためのデータ処理エージェント４０をホストするように構成された装置３９が提供される。装置３９は、
－ 通信インターフェース５４と、
－ 通信インターフェース５４に結合され、動作中、プロセッサ４７上でデータ処理エージェント４０の機能を実行するように構成された、プロセッサ４７と
を備える。

通信インターフェース５４は、少なくとも１つの分析デバイスＰ１Ａから少なくとも１つの自動通知を受信するように構成される。

プロセッサ４７は、データ処理エージェント４０を使用して、少なくとも１つの自動通知を処理し、それにより、少なくとも１つの分析デバイスＰ１Ａからの少なくとも１つの自動通知の１つまたは複数の特性を識別するように構成される。

プロセッサ４７は、データ処理エージェント４０を使用して、１つまたは複数の識別された特性をモデルに適用することによって、少なくとも１つの分析デバイスＰ１Ａの状態を推論するように構成される。プロセッサ４７は、データ処理エージェント４０において、分析デバイスＰ１Ａの推論された状態を報告する通知を生成するように構成される。

一例として、装置３９は、汎用サーバであってよい。装置３９は、パーソナルコンピュータであってよい。一例として、装置３９は、データ処理エンジンがＰＯＣ－ＤＭＳ上でホストされるように、ＰＯＣ－ＤＭＳコンピュータ１２と同一であってよい。装置３９は、「エッジコンピュータ」であってよい。

第３の態様によれば、分析デバイス管理のためのシステム１０Ａ、１０Ｂであって、
－ 少なくとも１つの分析デバイスＰ１Ａ～Ｐ７Ａ、Ｐ１Ｂ～Ｐ７Ｂと、
－ 第１の態様の方法を実行するように構成された、請求項１２の装置からのデータを処理するためのデータ処理エージェント４０をホストするように構成された、装置３９、２３と、
－ ユーザインターフェース２４Ａを備えたコンピューティング装置１２Ａと、
－ 少なくとも１つの分析デバイスＰ１Ａ～Ｐ７Ａ、Ｐ１Ｂ～Ｐ７Ｂ、コンピューティング装置、およびデータ処理エージェント４０をホストするように構成された装置を通信可能に接続するように構成された、ネットワーク１６Ａ、１６Ｂ、２１と
を備え、
少なくとも１つの分析デバイスが、少なくとも１つの通知を生成するように構成され、通信ネットワークが、装置３９、２３上でホストされるデータ処理エージェント４０に少なくとも１つの通知を通信するように構成される
分析デバイス管理のためのシステム１０Ａ、１０Ｂが提供される。

随意に、装置３９、２３上でホストされるデータ処理エージェント４０は、第１のネットワーク１０Ａ内の分析デバイスＰ１Ａ～Ｐ７Ａの第１のセットから第１の複数の自動通知を受信するように構成される。データ処理エージェント４０は、第１のネットワーク１０Ａ内の分析デバイスＰ１Ａ～Ｐ７Ａの第１のセットからの複数の自動通知に基づいて、少なくとも１つのモデルをトレーニングするように構成される。装置３９、２３によってホストされるデータ処理エージェント４０は、第２のネットワーク１０Ｂ内の分析デバイスＰ１Ｂ～Ｐ７Ｂの第２のセットから第２の複数の自動通知を受信するように構成される。データ処理エージェントは、第１のネットワーク１０Ａ内の分析デバイスＰ１Ａ～Ｐ７Ａの第１のセットからの複数の自動通知に基づいてトレーニングされた少なくとも１つのモデルを使用して、第２のネットワーク内の少なくとも１つの分析デバイスＰ１Ｂの少なくとも１つの状態を推論するように構成される。データ処理エージェント４０は、第２のネットワーク１０Ｂ内の少なくとも１つの分析デバイスＰ１Ｂの推論された状態を報告する通知を生成するように構成される。

第４の態様によれば、第２の態様による装置を制御するためのコンピュータ可読命令を備えたコンピュータプログラム要素であって、コンピュータ可読命令が、装置の処理ユニットによって実行されているとき、第１の態様の方法、またはその実施形態を実行するように適合される、コンピュータプログラム要素が提供される。

第５の態様によれば、第４の態様のコンピュータプログラム要素を記憶した、またはその上に符号化した、コンピュータ可読媒体または信号が提供される。

Claims (14)

1. ネットワーク（２１）を介して少なくとも１つの分析デバイス（Ｐ１Ａ～Ｐ７Ａ、Ｐ１Ｂ～Ｐ７Ｂ）から受信された複数の自動通知に基づく前記分析デバイスの状態を推論するためのコンピュータ実装方法（６０）であって、前記コンピュータ実装方法（６０）が、前記分析デバイス（Ｐ１Ａ～Ｐ７Ａ、Ｐ１Ｂ～Ｐ７Ｂ）の状態を推論するためのデータ処理エージェント（４０）をホストするように構成された１つまたは複数の装置（３９、２３）によって実行され、前記１つまたは複数の装置（３９、２３）が、通信インターフェースと、前記通信インターフェースに結合され、動作中、プロセッサ上でデータ処理エージェント（４０）の機能を実行するように構成された、プロセッサと、を備え、
   前記コンピュータ実装方法（６０）は、
   データ処理エージェント（４０）において、少なくとも１つの分析デバイスから自動通知のセットを受信すること（６１）と、
   前記データ処理エージェント（４０）において、前記自動通知のセットから前記自動通知のサブセットを抽出し、それにより、前記少なくとも１つの分析デバイスからの前記自動通知のサブセットに基づいて、前記分析デバイスの１つまたは複数の特性を識別すること（６２）であって、
   前記データ処理エージェント（４０）において、前記ネットワーク（２１）を介して少なくとも１つの注釈データを受信することであって、前記少なくとも１つの注釈データが、ユーザまたはオペレータから入力される、少なくとも１つの注釈データを受信することと、
   前記データ処理エージェント（４０）において、前記少なくとも１つの注釈データの少なくとも１つの注釈コメントに基づいて、前記自動通知のセットから前記自動通知のサブセットを抽出することと、
   前記データ処理エージェント（４０）において、前記自動通知のサブセットに基づいて、前記分析デバイスの前記１つまたは複数の特性を識別することと
   を備える、前記分析デバイスの１つまたは複数の特性を識別すること（６２）と、
   前記データ処理エージェント（４０）において、前記１つまたは複数の識別された特性に基づいて、モデルを更新または生成し、それにより、前記少なくとも１つの分析デバイスの前記状態を推論すること（６３）と、
   前記データ処理エージェント（４０）において、前記分析デバイスの推論された状態を報告する通知を生成すること（６４）と
   を備える、コンピュータ実装方法（６０）。
2. 前記モデルが、前記自動通知のセットを前記データ処理エージェント（４０）に送信するために使用される分析デバイス（Ｐ１Ａ～Ｐ７Ａ、Ｐ１Ｂ～Ｐ７Ｂ）のタイプを少なくとも部分的に特徴付ける
   請求項１に記載のコンピュータ実装方法（６０）。
3. 前記データ処理エージェント（４０）において、さらなる分析デバイス（Ｐ１Ａ～Ｐ７Ａ、Ｐ１Ｂ～Ｐ７Ｂ）の前記ネットワークへの接続を検出することと、
   前記データ処理エージェント（４０）において、前記さらなる分析デバイスが（ｉ）事前に前記ネットワークに接続されているか、または（ｉｉ）事前に前記ネットワークに接続されていないか、を識別することと、
   前記さらなる分析デバイスが事前に前記ネットワークに接続されている場合、
   前記データ処理エージェント（４０）において、前記モデルとして使用するために、記憶されたモデルをローディングすることであって、前記記憶されたモデルが、前記さらなる分析デバイスが前記ネットワークから切断された前の時点における前記さらなる分析デバイスの状態を特徴付ける、モデルをローディングすることと
   をさらに備える、請求項１または２に記載のコンピュータ実装方法（６０）。
4. 前記データ処理エージェント（４０）において、さらなる分析デバイス（Ｐ１Ａ～Ｐ７Ａ、Ｐ１Ｂ～Ｐ７Ｂ）の前記ネットワークに対する接続を検出することと、
   前記さらなる分析デバイス（Ｐ１Ａ～Ｐ７Ａ、Ｐ１Ｂ～Ｐ７Ｂ）が事前に前記ネットワークに接続されていない場合、
   前記データ処理エージェント（４０）において、前記さらなる分析デバイスのタイプを識別することと、
   前記データ処理エージェント（４０）において、前記モデルとして使用するために追加のモデルをインスタンス化することであって、前記追加のモデルが、識別されたタイプの前記さらなる分析デバイスに関連付けられる、追加のモデルをインスタンス化することと
   をさらに備える、請求項１または２に記載のコンピュータ実装方法（６０）。
5. 前記モデルが、前記少なくとも１つの分析デバイス（Ｐ１Ａ～Ｐ７Ａ、Ｐ１Ｂ～Ｐ７Ｂ）の以下の状態、すなわち、
   （ｉ） センサー障害状態、
   （ｉｉ） センサー信頼性欠如の状態、
   （ｉｉｉ） 熱故障状態、
   （ｉｖ） ソフトウェアまたはファームウェア故障状態、
   （ｖ） 品質制御故障状態、
   （ｖｉ） 機械故障状態、
   （ｖｉｉ） バッテリー故障状態、
   （ｖｉｉｉ） 物理的衝撃状態、および／または
   （ｉｘ） セキュリティ故障状態
   のうちの少なくとも１つ、またはその開始を識別するように構成される
   請求項１から４のいずれか一項に記載のコンピュータ実装方法（６０）。
6. 前記データ処理エージェント（４０）において、前記少なくとも１つの分析デバイス（Ｐ１Ａ～Ｐ７Ａ、Ｐ１Ｂ～Ｐ７Ｂ）からの前記自動通知の１つまたは複数の特徴を識別するために、前記自動通知を備えたデータを処理することが、
   前記データ処理エージェント（４０）において、前記少なくとも１つの分析デバイスから第２の自動通知を受信することであって、前記自動通知および前記第２の自動通知が、それぞれ、第１および第２の時点において前記少なくとも１つの分析デバイスによって生成される、第２の自動通知を受信することと、
   前記第１および第２の時点に基づいて、前記自動通知と前記第２の自動通知の間の時間関係を検出することと、
   前記検出された時間関係に基づいて、前記１つまたは複数の特性を識別することと
   をさらに備える、請求項１から５のいずれか一項に記載のコンピュータ実装方法（６０）。
7. 前記分析デバイスが、医学的状態のバイオマーカを識別するために生体試料を分析するように構成される、請求項１から６のいずれか一項に記載のコンピュータ実装方法（６０）。
8. 前記モデルが、規則ベースのモデル、線形回帰、決定木、サポートベクトル機械、ｋ最近傍法モデル、ランダムフォレストモデル、オートエンコーダ、畳み込みニューラルネットワーク、再帰的ニューラルネットワーク、ディープビリーフネットワーク、または転移学習モデルのうちの１つまたはこれらの組合せである
   請求項１から７のいずれか一項に記載のコンピュータ実装方法（６０）。
9. グラフィカルユーザインターフェースを介して前記分析デバイス（Ｐ１Ａ～Ｐ７Ａ、Ｐ１Ｂ～Ｐ７Ｂ）の前記状態をユーザに表示すること
   をさらに備える、請求項１から８のいずれか一項に記載のコンピュータ実装方法（６０）。
10. 前記データ処理エージェント（４０）において、前記分析デバイス（Ｐ１Ａ～Ｐ７Ａ、Ｐ１Ｂ～Ｐ７Ｂ）の前記状態を報告する前記通知を使用して、機器保守管理データベースから記録を取得することであって、
    前記機器保守管理データベースが、前記少なくとも１つの分析デバイスに関する少なくとも１つの機器保守管理活動、結果として、前記分析デバイスの前記状態を報告する前記通知を定義する、記録を取得することと、
    前記データ処理エージェント（４０）において、前記少なくとも１つの機器保守管理活動を備えた機器保守管理通知を生成することと
    をさらに備える、請求項１から９のいずれか一項に記載のコンピュータ実装方法（６０）。
11. ネットワークを介して少なくとも１つの分析デバイス（Ｐ１Ａ～Ｐ７Ａ、Ｐ１Ｂ～Ｐ７Ｂ）から受信された複数の自動通知に基づく前記分析デバイスの状態を推論するためのデータ処理エージェント（４０）をホストするように構成された１つまたは複数の装置であって、
    通信インターフェースと、
    前記通信インターフェースに結合され、動作中、プロセッサ上でデータ処理エージェント（４０）の機能を実行するように構成された、プロセッサと、
    を備え、
    前記通信インターフェースが、データ処理エージェント（４０）において、少なくとも１つの分析デバイスから自動通知のセットを受信するように構成され、
    前記プロセッサが、前記データ処理エージェント（４０）を使用して、前記自動通知のセットから前記自動通知のサブセットを抽出し、それにより、前記少なくとも１つの分析デバイスからの前記自動通知のサブセットに基づいて、前記分析デバイスの１つまたは複数の特性を識別するように構成され、
    前記プロセッサが、前記データ処理エージェント（４０）を使用して、１つまたは複数の識別された特性に基づいて、モデルを更新または生成し、それにより、前記少なくとも１つの分析デバイスの状態を推論するように構成され、前記プロセッサが、
    前記データ処理エージェント（４０）において、前記ネットワークを介して、ユーザまたはオペレータから入力される少なくとも１つの注釈データを受信し、
    前記データ処理エージェント（４０）において、前記少なくとも１つの注釈データの少なくとも１つの注釈コメントに基づいて、前記自動通知のセットから前記自動通知のサブセットを抽出し、
    前記データ処理エージェント（４０）において、前記自動通知のサブセットに基づいて、前記分析デバイスの前記１つまたは複数の特性を識別し、
    前記データ処理エージェント（４０）において、前記１つまたは複数の識別された特性に基づいて、モデルを更新または生成し、それにより、前記少なくとも１つの分析デバイス（Ｐ１Ａ～Ｐ７Ａ、Ｐ１Ｂ～Ｐ７Ｂ）の前記状態を推論し、
    前記データ処理エージェント（４０）において、前記分析デバイスの推論された状態を報告する通知を生成する
    ようにさらに構成される、１つまたは複数の装置。
12. 分析デバイス管理のためのシステム（１０Ａ、１０Ｂ）であって、
    少なくとも１つの分析デバイス（Ｐ１Ａ～Ｐ７Ａ、Ｐ１Ｂ～Ｐ７Ｂ）と、
    請求項１から１０に記載のコンピュータ実装方法を実行するように構成された、請求項１１に記載の１つまたは複数の装置からのデータを処理するためのデータ処理エージェント（４０）をホストするように構成された１つまたは複数の装置（３９、２３）と、
    ユーザインターフェース（２４Ａ）を備えた１つまたは複数のコンピューティング装置（１２Ａ）と、
    前記少なくとも１つの分析デバイス（Ｐ１Ａ～Ｐ７Ａ、Ｐ１Ｂ～Ｐ７Ｂ）、前記１つまたは複数のコンピューティング装置、および前記データ処理エージェント（４０）をホストするように構成された前記１つまたは複数の装置（３９）を通信可能に接続するように構成されたネットワーク（１６Ａ、１６Ｂ、２１）と
    を備え、
    前記少なくとも１つの分析デバイスが、少なくとも１つの通知を生成するように構成され、前記ネットワークが、前記データ処理エージェント（４０）に少なくとも１つの通知を通信するように構成される
    システム（１０Ａ、１０Ｂ）。
13. 請求項１１に記載の１つまたは複数の装置を制御するためのコンピュータ可読命令を備えたコンピュータプログラム要素であって、前記コンピュータ可読命令が、前記１つまたは複数の装置の処理ユニットによって実行されているとき、請求項１から１０のいずれか一項に記載のコンピュータ実装方法を実行するように適合される、コンピュータプログラム要素。
14. 請求項１３に記載のコンピュータプログラム要素を記憶した、コンピュータ可読媒体。

Images