JP2021527880A - 医用イメージングシステムのフィールドサービスのための部品同時交換推奨システム - Google Patents

Abstract

サービス装置１０２において、ユーザインタフェース１０６が提供され、ユーザインタフェース１０６を介して、ユーザは、少なくとも１つのユーザ入力装置１０３により、リクエストされた部品Ｘを注文するための注文リクエスト１１７を送信する。リクエストされた部品Ｘに関する同時交換情報１１６は、同時交換データベース１１４を使用して識別され、ディスプレイ上に表示される。例えば、リクエストされた部品Ｘと同時交換される第２の部品Ｙが識別され、部品Ｘと共に交換することが推奨されることができ、又は２つの部品Ｘ及びＹが注文される場合、同時交換情報は、これらの部品のうちの１つのみを注文することを推奨することができる。データベース１１４をホストするサーバにおいて、サービス装置からの注文リクエストが受信され、リクエストされた部品に関する同時交換情報１１６が、同時交換データベース１１４を用いてを生成され、前記同時交換情報は、サービス装置に送られる。

Description

本発明は一般に、医用イメージング装置のサービス技術、部品交換注文システム、及び関連技術に関する。

医用イメージングシステムは、サービスを必要とする故障を経験することがある。医療機器の既存のフィールドサービスでは、リモートサービスエンジニア（ＲＳＥ）がシステムのログファイルと顧客からの苦情を評価してシステムの問題を判断するか、フィールドサービスエンジニア（ＦＳＥ）が、問題が評価された顧客のサイト（現場）に最初に訪問して問題を判断する。多くの場合、ＲＳＥ又はＦＳＥは、１つ又は複数のコンポーネントを交換すべきであると決定する。ＲＳＥが関与する状況では、ＦＳＥは、問題を迅速に解決する試みとして、１回目の訪問時にＲＳＥが推奨する部品をサイトに持参することができる。ＲＳＥが存在しないか、又は部品を推奨していない場合、この１回目の訪問中に、ＦＳＥは、ノートブックコンピュータ上で実行される部品注文アプリケーションを使用して、顧客サイトを配送先住所として、１つ又は複数の交換部品の注文を行う。２回目の訪問時に、ＦＳＥが、出荷された交換部品のうちの１つ又は複数を取り付けし、問題が解決されたかどうかを評価する。問題が解決されない場合、場合によっては最初の交換部品を取り外すことなく、異なる交換部品が取り付けられることができる。１回目の訪問中に両方の交換部品が注文された場合は、両方の部品の完全な取り付けが、１度の（２回目の）訪問時に行われることができる。一方、１つの交換部品のみが注文された場合、第２の（異なる）交換部品は、２回目の訪問中に注文されなければならず、それによって、その第２の交換部品を取り付けるために、更に３回目の訪問を必要とする。

いくつかの状況では、第１及び第２の交換部品の両方が１回目の訪問中に注文されるが、第１の交換部品の取り付けが問題を解決するので、第２の交換部品が必要でなくなる。他の状況では、第１及び第２の交換部品が、第１の訪問中に注文され、第１の部品の取り付けは問題を解決しないが、第２の交換部品の取り付けが問題を解決する。これらのさまざまな状況は、さまざまな潜在的な非効率性及び／又は余分なコスト、例えば、３回目の訪問のコストと、未使用の第２の部品の配送及び返却のコストと、第１の部品の不必要な取り付けのコストの間の統計的なトレードオフを提示する。

今日、すべてのサービス作業注文情報は、大規模なデータベースに記憶されている。専門家は、特定のサービス作業注文情報を調べたり、モデル、特定のマシン、国、又は期間でフィルタリングされた記録をデータベースから検索したりすることができる。このようにして、さまざまな異なるタイプのマシンで発生する同様の状況を完全に理解することは困難である。従って、それは、専門家及び他の状況から認識するものに依存する。サービスエンジニアは、システムを復旧及び稼働させるために高いプレッシャーの下で作業しているため、どの部品が実際に故障しているかを確かめることなく、複数の部品を注文し、現場に持って行ったり、又はいくつかの部品を同時に交換しようとする。これは、特に、第１の部品を交換し、問題を解決しないことが分かった場合に、次に第２の部品を交換しようとする場合である。サービスエンジニアは、これが問題を解決することが分かった場合に、第１の部品の交換を取り消さない可能性がある。

以下は、特定の改良を開示する。

本明細書で開示されるいくつかの実施形態では、サービス装置は、ディスプレイと、少なくとも１つのユーザ入力装置、前記ディスプレイ及び前記ユーザ入力装置に動作可能に接続された電子プロセッサとを有する。この装置はまた、部品注文方法を実行するために、電子プロセッサによって読み取り可能且つ実行可能な命令を記憶する非一時的記憶媒体を有する。部品注文方法は、ユーザが少なくとも１つのユーザ入力装置を介して、リクエストされた部品を注文するための注文リクエストを提出するユーザインタフェースを提供することを含む。次に、この方法は、同時交換データベースにアクセスするサーバから、リクエストされた部品の同時交換情報を受信することによって動作する。この同時交換情報は、ディスプレイ上に表示される。

本明細書で開示されるいくつかの実施形態において、非一時的記憶媒体は、部品注文方法を実行するために電子機器によって読み取り可能且つ実行可能な命令を記憶する。部品注文方法は、ユーザが少なくとも１つのユーザ入力装置を介して、リクエストされた部品を注文するための注文リクエストを提出するユーザインタフェースを提供することを含む。次に、この方法は、同時交換データベースを使用して、リクエストされた部品の同時交換情報を識別することによって動作する。この同時交換情報は、ディスプレイ上に表示されている。

本明細書で開示されるいくつかの実施形態において、部品注文システムは、サーバと、同時交換データベースと、サーバ及び同時交換データベースに動作可能に接続された電子プロセッサとを有する。部品注文装置は、上述の部品注文方法を実行するために電子プロセッサによって読み取り可能かつ実行可能な命令を記憶する非一時的記憶媒体を更に有する。

１つの利点は、改善された診断によってコスト節約を提供し、使用されなかった部品の量を低減し、サービスエンジニア（ＳＥ）によるサービストリップの回数を低減することにある。

別の利点は、１回目のサービスコール中に特定の追加部品を評価しテストするための提案を、ＳＥに自動的に提供することにある。

別の利点は、どの部品が高い同時交換頻度を有するかを識別する能力にある。

別の利点は、問題を解決するために複数の部品を交換することができる順序を提案し、問題をできるだけ早く解決することができる能力にある。

別の利点は、修理時間を短縮し、システムのダウンタイムを短縮することにある。

別の利点は、ＳＥにガイダンスを提供する改良された部品注文装置を提供することにある。別の利点は、部品注文装置のための改善されたユーザインタフェースを提供することであり、これは、一緒に注文される可能性のある部品を予想し、（可能性のある）同時注文される部品の注文入力を促進することによって、ユーザの労力を低減する。

所与の実施形態は、本開示を読み理解する際に当業者に明らかになるように、前述の利点のいずれも提供しない、１つ、２つ、より多く又はすべてを提供することができ、及び／又は他の利点を提供することができる。

本発明は、さまざまな構成要素及び構成要素の取り合わせ、ならびにさまざまなステップ及びステップの取り合わせの形をとることができる。図面は、好ましい実施形態を例示する目的のためだけのものであり、本発明を限定するものとして解釈されるものではない。

本開示による部品注文システム及び関連する同時交換データベースバックエンドを概略的に示す図。 第２の部品を注文するための推奨を提供するための、図１の例示的な同時交換データベースマネージャの動作を概略的に示す図。 ２つの部品が一緒に注文されたときにアドバイスを提供するための、図１の例示的な同時交換データベースマネージャの動作を概略的に示す図。

イメージングシステムのような医療装置は相対的に複雑であり、ある時間使用すると、故障を経験することがある。システムの誤動作又は故障を発見すると、機器を収容する病院は、サービスプロバイダによる、サービスコールとしても知られるサービス作業注文を開始することができる。いくつかのケースでは、サービスプロバイダは、元の機器の製造業者に関連するエンティティであり、エンドユーザである病院と契約サービス関係を確立している。

サービスコールの開始時に、遠隔診断及び解決をまず試みることができる。しかしながら、多くの場合、これは不成功であり、フィールドサービスエンジニア（ＦＳＥ）は次に、誤動作している機器の現場、通常は機器が収容されている病院に移動することがある。（「フィールドサービスエンジニア」又はＦＳＥという用語は、単に例示的な命名法であり、これらの用語は、そのような人を指すために使用される特定の肩書きや用語にかかわらず、イメージング装置をオンサイトで検査し、必要に応じてオンサイトで修理を行う任意の保守担当者を広く包含するものとして理解されるべきである。）このとき、ＦＳＥは誤作動している医用イメージング装置を調査し、問題の根本原因を決定する。次いで、ＦＳＥは、問題を解決するために１つ又は複数の部品が交換されるべきかどうかを判定し、交換されるべきと判定される場合、どの部品が交換されるべきかを判定する。

図１を参照すると、サービスエンジニア（ＳＥ）は一般に、サービス装置１０２を持ち運び、又はそれにアクセスする。いくつかの実施形態では、サービス装置１０２は、ラップトップ、スマートデバイス又はモバイルコンピュータシステム等のパーソナル装置である。他の実施形態において、サービス装置１０２がサービスを受けるイメージング装置と一体化される又は動作可能に接続されるイメージングシステムコントローラ又はコンピュータでありうる。別の例として、サービス装置１０２は、コールセンターに、又は初期診断及び部品の注文を実行するＲＳＥの他の場所に配置されるコンピュータでありうる。サービス装置１０２は、他の機能の中でもとりわけ、部品注文エントリフォーム１０６を提供する部品注文アプリケーション１０４を実行するようにプログラムされる。（「サービスエンジニア」又はＳＥという用語は、単に例示的な命名法であり、これらの用語は、ＦＳＥ又はＲＳＥなどの任意の保守担当者を広く包含するものとして理解されるべきである）。他の実施形態では、サービス装置は、携帯電話（セルフォン）又はタブレットコンピュータなどのモバイルデバイスであってもよく、部品注文アプリケーション１０４は、「アプリケーション」（アプリケーションプログラム）として具体化されることができる。更に、部品注文アプリケーション１０４は例えば、サービスログ（例えば、例示的なサービスコール報告アプリケーション１０８）などとインタフェースするための他のコンポーネントを有する、より包括的なアプリケーションのコンポーネントであることも企図される。部品注文アプリケーション１０４は、サービス装置１０２に関連付けられたディスプレイ１０５上に表示されるユーザインタフェースを提示する。ＳＥは、マウス、キーボード、又はタッチスクリーンのような、少なくとも１つのユーザ入力装置１０３を介してアプリケーションと対話することができる。サービス装置は更に、電子プロセッサ１０１及び非一時的記憶媒体１０７（図１に概略的に示される内部コンポーネント）を有する。非一時的記憶媒体１０７は、部品注文アプリケーション１０４を実現するための、電子プロセッサ１０１によって読み取り可能且つ実行可能な命令を記憶する。サービス装置は、サービスエンジニアがバックエンドサーバ１１１と通信できるように、通信インタフェース１０９を有することができる。このような通信インタフェース１０９は例えば、インターネット及び／又はイントラネットへの接続のためのＷｉＦｉ又は４Ｇインタフェース等を含む。部品注文アプリケーション１０４のいくつかの態様は、クラウド処理又は他のリモート処理によって実現されることもできる。

交換すべき１又は複数の部品を決定した後、ＳＥは、注文のためにリクエストされた部品に関連する識別番号又はコード（例えば、部品番号）などを、部品注文アプリケーション１０４の部品注文入力フォーム１０６に入力する。ＳＥは、サービス装置１０２のユーザ入力装置１０３を介して、部品番号を入力フォーム１０６に入力する。

例示的な部品注文アプリケーション１０４は、サービスコール報告アプリ１０８を含み又はそれとインタフェースする（あるいは、サービスコール報告アプリ１０８は、サービス装置１０２上で実行される別個のプログラムとして実現されることができ、例えば、別個のウィンドウにおいて又はトグルベースのアプリケーションスイッチング及び／又はその他を用いて、実現されることができる）。ＳＥがリクエストされたサービスコールのためにサイトを訪問する場合、ＳＥは、典型的には、各訪問ごとに報告情報を通信するように促される。サービスコール報告アプリ１０８は、サービス作業注文データと呼ばれることもある、サービスコールに関連するデータを収集する。報告情報は、構築情報に関連する機器モデル及びシリアル番号などの、誤動作している機器の識別情報を含むことができる。いくつかの実施形態では、サービス作業指示データは、機器によって生成されたエラーコード及び機器使用のログも含む。サービスコール報告アプリは更に、機器上の部品が交換されたかどうか、及びそれらの部品の交換が問題を解決したかどうかを含む、機器の診断及び修理情報に関連する情報を収集する。多くの場合、ＳＥは、各サービスコールごとに、機器サイトを複数回訪問する。サービスコール報告アプリは、その特定のサービスコールに関連して行われたサービスのヒストリを追跡することができる。問題が解決されると、その問題に関連するサービスコールがクローズされたと見なされる。新たな問題が生じた場合、新たなサービスコールが開始されることができる。新しい問題／誤動作が以前のサービスコールに関連する場合、それに応じて以前のサービスコールが再開され、更新されることができる。

サービスコール報告アプリから収集された情報は、典型的には、サービス提供される医用イメージング装置に関連付けられたサービスログに記憶されるとともに、医用イメージング装置ベンダ又は他のサービスプロバイダによって維持管理されるアーカイブサーバにアップロードされることができる。更に、図１において、サービスコール報告アプリ１０８を使用して収集されたサービス情報は、同時交換データベースバックエンド１１０に供給される。バックエンド処理は、電子プロセッサ１１３を装備したサーバ１１１上で実行される（図では内部コンポーネントが示されている）。サーバ１１１は、非一時的記憶媒体１２７（図１に概略的に示されている内部コンポーネント）を具備する。単一のサーバコンピュータが図示されているが、バックエンド１１０は、より一般に、単一のサーバコンピュータ、サーバクラスタ、又はアドホックに相互接続されたサーバコンピュータなどを含むクラウドコンピューティングリソース上に実現されてもよいことが理解される。同時交換データベースマネージャ１１２は、サービスコール報告アプリ１０８からデータを受信する。同時交換データベースマネージャ１１２はそののち、自動的に、同時交換データベース１１４にデータを入れ、同時交換データベース１１４を更新することができる。同時交換データベース１１４は更に、ＦＳＥ、ＲＳＥ、又はバックエンド１１０にアクセスするサービスプロバイダのエンジニアによる、サービスコールに関連する情報１１５の手動入力によって、データを入れ又は修正されることができる。

同時交換データベース１１４は、すべてのサービスコールから取得された情報を記憶する。特に、同時交換データベース１１４は、すべてのサービスコールにおいて交換されたすべての部品の情報を記憶する。データベースはまた、部品を交換することによって問題を解決した際の成功（又はその欠如）に関する情報により更新されてもよい。例えば、部品「Ｘ」及び「Ｙ」が交換され、後に部品「Ｙ」がまだ機能していることが判明した場合、部品「Ｙ」は、誤動作の問題を解決する成功に貢献していなかった可能性がある。この場合、部品「Ｘ」及び部品「Ｙ」は一般に、同時交換部品と見なされるが、部品「Ｙ」は、ＳＥに提示される同時交換部品を識別することに関して、部品「Ｘ」との関連付けを解除されることができる。従って、フィードバック機構が、同時交換オプティマイザに内蔵されることができる。

使用済み部品がマシンから取り外され、新しい部品と交換される場合、使用済み部品は、分析のためにＯＥＭ又はサービスプロバイダに送られることができる。ＯＥＭ又はサービスプロバイダは、使用済み部品の故障が装置の誤動作の根本原因であったかどうかを判定するために、使用済み部品に対してテストを実行することができる。使用済み部品が完全に機能しており、根本原因に関連しないことが判明した場合、同時交換オプティマイザ及び同時交換データベースを更新して、その特定のサービス作業コールについて、使用済み部品と同時交換済み部品との関連付けを解除することができる。

いくつかの実施形態において、ＳＥは、同時交換オプティマイザ及び同時交換データベースに、フィードバックを提供することができる。部品の同時交換が問題を解決した場合、ＳＥは、部品と同時交換部品との間の肯定的な関係を示すことができる。同時交換が、誤作動する装置の問題を解決することに成功しなかった場合、ＳＥは、部品と同時交換部品との間の否定的な関係を示すことがある。このような解決情報は典型的には、サービスコールの日常的な文書としてサービスログに入力され、従って、いくつかの実施形態においてサービスログから抽出されることもできる。サービスコール報告アプリケーション１０８が解決情報の入力のために制約されたフィールドをもつ構造化されたデータ入力フォーマットを採用する場合、この情報の抽出は、直接的でありうる。より多くのフリーフォームのサービスコールログ記録が使用される場合、キーワード検索、自然言語処理（ＮＬＰ）などが適用されることで、どの部品（複数可）が問題を解決したかについてのフィードバックを抽出することができる。例えば、テキストが文及び段落に構文解析され、部品番号及び成功又は失敗を示す用語を含む文又は段落が識別されることで、この情報が抽出されることができる。これらは単に例示的な例である。

サービス可能なすべてのマシンについて、サービスコールの各訪問ごとにデータベース１１４に含められる総サービス作業指示データは、かなりのボリュームになりうることが理解されよう。このように、エンジニアの人又はチームが手動でデータをふるい分けることは、非常に時間がかかり、非効率的である。更に、サービス装置１０２は典型的にはインターネットを介して接続されており、このような手動検索を実行するために必要なデータをダウンロードするための十分な通信帯域幅を有していないことがある。

ＳＥの部品リクエスト１１７は、部品注文フォーム１０６への部品番号入力を通じて、同時交換部品アドバイザ１１８に送信される（１１９）。一般性を失うことなく、リクエストされた部品は、図１において部品番号「Ｘ」として示される。同時交換部品アドバイザ１１８は、リクエストされた部品番号「Ｘ」をデータベースバックエンド１１０の同時交換オプティマイザ１１６に送る。同時交換オプティマイザ１１６は、データベース１１４をスキャンして、少なくとも１つのサービスコールにおいてリクエストされた部品「Ｘ」と同時交換されたことのある１つ又は複数の他の部品を識別する。しかしながら、部品が同時交換されることを知ることは、特に、毎回異なる部品との同時交換が行われていた場合及び／又は何度も追加の部品が同時交換されなかった場合は、あまり多くを示さないことが多い。従って、同時交換オプティマイザ１１６は、リクエストされた部品「Ｘ」が過去に（又はいくつかの実施形態では指定された過去の時間フレーム、例えば、昨年の間に）同時交換された頻度に関する追加の情報を取り出すことができる。そのような時間的な制約は、新しいイメージング装置構成などのために現在では陳腐化している同時交換に関する情報を取り出すことを回避するために有用でありうる。この点に関して、同時交換のパーセンテージは、１回のサービス作業注文において、リクエストされた部品「Ｘ」が他の部品「Ｙ」と同時交換された過去のサービスコールの回数に関連して計算されてもよい。いくつかの実施形態では、同時交換オプティマイザ１１６は、リクエストされた部品「Ｘ」が交換されるサービスコールのＴ％以上（他の場合は、割合Ｔ以上）において、部品「Ｘ」と同時交換されたことのある関連する交換部品を識別する。これらの実施形態において、閾値Ｔは、ＳＥによって設定されてもよいし、サーバ１１１を操作するサービスプロバイダによって同時交換オプティマイザ１１６にハードコーディングされてもよい。例えば、オプティマイザ１１６は、部品「Ｘ」との同時交換のパーセンテージがそれぞれ４０％、３０％、及び１０％である３つの部品Ａ、Ｂ、及びＣのリストを生成することができる。閾値Ｔが２０％である場合、同時交換オプティマイザ１１６は、部品「Ｘ」と同時交換されることが多い部品として、Ａ及びＢを同時交換部品アドバイザ１１８に出力する。このようにして、問題を解決するために最も関連性があり且つ可能性のある代替物のみが提示される。場合によっては、サービスコールの少なくともＴ％の割合で部品「Ｘ」と同時交換されている部品が識別されないこともあり、そのような場合には同時交換部品アドバイザ１１８は、部品「Ｘ」と一緒に注文するための部品を提案しない。

一般に、サービス装置１０２は、部品「Ｘ」の注文を行うためにサーバ１１０と接続され、従って、同時交換バックエンド１１０をサーバに配置することは実用的な実現例である。しかし、いくつかの実施形態では、非一時的記憶媒体１０７が十分な容量を有する場合、データベース１１４及び同時交換オプティマイザ１１６は、サービス装置１０２において部品注文アプリケーション１０４と統合されることもできる。このようにして、サービス装置１０２は、オフラインで（すなわち、サーバ１１１への接続なしで）動作することができるとともに、なお同時交換推奨を提供することができる。

価格設定、出荷コスト、及び各同時交換部品の在庫／可用性を含む他の情報が検索され、リクエストされた部品に関連付けられることも可能である。次に、同時交換オプティマイザ１１６は、取り出された同時交換情報を部品注文アプリケーション１０４の同時交換部品アドバイザ１１８に送り返す。このとき、同時交換情報が、ＳＥに対して、ラップトップ１０５上に表示される。この情報は、例示的な部品「Ｘ」と共に注文されるべき部品の推奨を行う際に同時交換オプティマイザ１１６によって考慮に入れられてもよい。例えば、閾値Ｔは、可能な同時交換部品のコストに基づいてスケーリングされることができる。より具体的な例として、同時交換データベース１１４が統計的に、部品「Ａ」が１５％の割合で部品「Ｘ」と同時交換され、部品「Ｂ」が３０％の割合で部品「Ｘ」と同時交換されることを示すデータを記憶している状況を考える。これらの頻度のみに基づいて、オプティマイザ１１６は、部品「Ｘ」とともに、部品「Ａ」ではなく部品「Ｂ」を注文することを推奨することができる。しかしながら、部品「Ｂ」が、重い及び／又はかさばる部品であり、高い出荷コストを有し、他方、部品「Ａ」が、より小さくより軽い部品であり、非常に低い出荷コストを有する場合、オプティマイザ１１６は、部品「Ｂ」の高い出荷コストと比較して、部品「Ａ」の出荷コストが低いため、部品「Ｘ」と共に、部品「Ｂ」ではなく部品「Ａ」を注文することを推奨することができる。データベース１１４において利用可能であり得る他の情報、例えば部品コスト、部品がすでに在庫にあるかどうか、及び／又はその他の情報が、同様に考慮されることができる。出荷コストの最適化は、返品を必要とする可能性のある部品の返品出荷コスト（場合によっては部品の返品レートによって更にスケーリングされる）などの他のファクタを調べることもできる。コスト分析はまた、閾値Ｔをスケーリングするための他の態様、及び／又は配送コスト以外の優先順位付けを調べることができ、例えば、機器の位置と比較したＦＳＥの位置（例えば、そこに到着するのに車で５時間かかる）、利用可能な時間及びスケジュールされた位置の両方に関するＦＳＥのスケジュール、リクエストされた部品及び同時交換部品の両方を交換するのに必要とされる追加の時間（リクエストされた部品のみを交換する時間と比較して）、追加のコストのリスクを負うなどの契約上の考慮事項（顧客又は供給者）、などである。いくつかのコスト分析の実施形態では、閾値及び／又は優先度は、全体的なコスト分析が与えられると変化しうる。

いくつかの実施形態において、同時交換オプティマイザ１１６又は同時交換部品アドバイザ１１８のいずれかが、リクエストされた部品と同時に交換するための現在の潜在的な候補をランク付けすることができる。これは、リクエストされた部品と同時交換された割合が４０％である部品がより高くランク付けされ、リクエストされた部品と同時交換された割合がたった１５％である部品より先に潜在的に列挙されうることを意味する（この例におけるランク付けは同時交換の頻度のみに基づく）。いくつかの実施形態において、ランク付けは、同時交換のパーセンテージに関連して部品リストを順序付ける。

他の実施形態では、ランク付けは、費用効果に関して部品リストを順序付けし、従って、出荷及び／又は部品価格設定を考慮に入れる。例えば、安価な小型で出荷しやすい部品は、大型でかさばり、高価な部品より先にランク付けされ列挙されることができる。このようにして、同時交換オプティマイザ１１６及び部品アドバイザ１１８は、問題を潜在的に解決するために、最も費用のかからないルートを提案することができる。

ＳＥに対して潜在的な現在の同時交換のリストを提示することは、誤作動しているマシンの追加コンポーネントをチェックするようにＳＥに示唆することができる。例えば、ＳＥは、部品「Ｘ」をリクエストすることができ、同時交換オプティマイザ１１６は、３０％の割合で部品「Ｙ」がリクエストされた部品と同時交換されていることを識別することができる。これは、部品「Ｙ」に焦点を当てた追加の診断試験がシステムの誤動作に対する洞察を提供することができるという示唆をＳＥに提供する。実際、問題の根本原因は、部品「Ｘ」ではなく部品「Ｙ」にあったこと、又は部品「Ｘ」及び「Ｙ」の両方が交換される必要があること、が決定されることができる。

いくつかの実施形態において、同時交換部品オプティマイザ１１６及び部品アドバイザ１１８は、予防保守に関するものであってもよい。ここで、同時交換オプティマイザ１１６は、リクエストされた部品「Ｘ」の交換と共に、定期的な保守アイテムである部品「Ｙ」の交換を提案することができる。一般に、定期的な保守部品は、周期的に交換される必要がありうる。しかし、部品「Ｘ」の交換は部品「Ｙ」への容易なアクセスを提供することができ、従って、部品「Ｘ」及び「Ｙ」の両方を同時に交換して、ＳＥが後で定期的な保守を実行するのに費やすトリップ数又は時間を低減することは、費用対効果が高いことがある。有利なことに、予防保守の考慮事項に基づく部品のこのような同時交換は、経験的データベース１１４の統計に自動的に反映される。予防保守のための部品同時交換の最適化はまた、好適には、現在取り付けされている部品「Ｙ」の可能性のある残存耐用年数、従ってその値を考慮に入れて、依然として長い残存耐用年数を有する部品の不必要な早期交換を回避する。最適化は、部品「Ｘ」を交換するためにすでに必要とされたダウンタイムに追加された、上記の例における部品「Ｙ」を交換するための追加のダウンタイムなど、他の要因も考慮に入れることができる。例えば、部品「Ｘ」を交換するためのダウンタイムがすでに顧客に強い悪影響を及ぼしている場合、定期的な保守アイテム「Ｙ」を更に交換するための追加のダウンタイムが保証されないことがある。これは、例えば合計ダウンタイムが長くなるほど（例えば、指数関数的に）大きくなるペナルティによって定量化されることができる。

いくつかの実施形態では、図２を参照して、交換シーケンスが計算され、同時交換アドバイザ１１８に送られることができる。ここで、部品「Ｘ」１１７の注文リクエストは、同時交換部品オプティマイザ１１６に送られる。同時交換オプティマイザ１１６は、同時交換データベース１１４をスキャンして、サービスコールの閾値Ｔ％より高い頻度で、リクエストされた部品「Ｘ」と同時に注文されたすべての部品を決定し、それらのリストを生成する。任意のステップ２１６において、２つの部品（例えば、「Ｘ」及び「Ｙ」）がＴ％の割合よりも高い頻度で同時交換される場合、部品「Ｘ」及び「Ｙ」の交換順序が、２１６において最適化され、交換順序が決定される。最適化された交換シーケンスは、複数の部品が交換されるべきシーケンス／順序であり、このシーケンス／順序では、問題を効率的に解決する可能性が統計的に最も高いものとされる（時間、総コスト、又は別の適切な効率メトリックで判定される）。前述の例では、可能なシーケンスは、（１）問題が持続する場合に「Ｘ」を最初に交換する、（２）問題が持続する場合に「Ｙ」を最初に交換する、又は（３）問題が解決されたかどうかを評価する前に「Ｘ」と「Ｙ」の両方を一緒に交換することである。（いくつかの実施形態又は状況では、シーケンス（３）が任意と見なされなくてもよい。最適なシーケンスの選択は、問題をできるだけ早く解決することに基づくことができ、又はコスト引数によって駆動されることができ、あるいはこれらの考慮事項の何らかの重み付けされた組み合わせに基づくことができる。従って、比較的安価な部品が、より高価な部品を交換する前に最初に交換されることができる。

以下に、交換順序を選択するためのいくつかの定量的アプローチを記載する。頻繁に同時交換される一対の部品Ｐ（部品「Ｘ」）及びＰ'（部品「Ｙ」）について、問題を解決するためにＰ、Ｐ'のみ、又はＰとＰ'の両方を交換される必要がある確率を示す確率ｐ（Ｐ）、ｐ（Ｐ'）、及びｐ（Ｐ＋Ｐ'）が知られている。確率を知ることにより、問題を解決するために部品を交換しなければならない順序を決定することができる。ここで、Ｔ（ｐ）、Ｔ（ｐ'）、Ｔ（ｐ→ｐ'）、及びＴ（ｐ'→ｐ）は、それぞれ、ｐのみ、ｐ'のみ、ｐ'の前にｐ、ｐの前にｐ'を交換することに関与する時間を示す。次に、これらのパラメータを使用して、交換の最良の順序を決定することができる。

ルールを使用することにより、対応する予想される総交換時間が最小であるときはいつでも、最初に交換されるべき部品として部品ｐを選択することが可能である。対応する予想総交換時間（すなわち、期待値）は、式１によって与えられる。
Ｅ_{ｐ ｆｉｒｓｔ}（Ｔ）＝Ｐ（ｐ）・Ｔ（ｐ）＋Ｐ（ｐ'）・Ｔ（ｐ→ｐ'）＋Ｐ（ｐ→ｐ'）・Ｔ（ｐ→ｐ'） 式１

これは、式（２）のように書き換えることができる。
Ｅ_{ｐ ｆｉｒｓｔ}（Ｔ）＝Ｐ（ｐ）・Ｔ（ｐ）＋（１−Ｐ（ｐ））・Ｔ（ｐ→ｐ'） 式２

同様に、ｐ'が最初に交換される場合の予想される総交換時間は、式３によって与えられる。
Ｅ_{ｐ' ｆｉｒｓｔ}（Ｔ）＝Ｐ（ｐ'）・Ｔ（ｐ'）＋（１−Ｐ（ｐ'）・Ｔ（ｐ'→ｐ） 式３

図２の例では、ＳＥが単一の部品「Ｘ」を注文することに応答して、同時交換部品アドバイザを用いて、同時交換頻度、合計時間及び／又はコスト、又は別の効率メトリックに基づいて、何らかの他の部品「Ｙ」を追加的に注文することを推奨すべきかどうかを判定する。他の想定される用途では、ＳＥが２つの部品（再び、一般性を失うことなく、部品「Ｘ」及び「Ｙ」として示される）の注文を行っている状況で、これらの部品のうちの１つを注文しないように推奨を提供するために、同時交換部品アドバイザを使用することができる。変形実施形態では、推奨は、部品「Ｘ」及び「Ｙ」の両方を一緒に注文する場合に必要となる時間及びコストを負担するのではなく、部品「Ｘ」及び「Ｙ」のうちのどちらを単独で注文するかを決定するために何らかの識別テストを実行することできる。

従って、いくつかの実施形態において図３を参照して、同時交換オプティマイザ１１６は、複数の部品を交換するというＳＥによる決定を評価することができる。ここで、注文フォーム１０６に入力された複数の部品「Ｘ」及び「Ｙ」１１７の注文のリクエストは、同時交換部品オプティマイザ１１６に送られる。同時交換オプティマイザ１１６は、同時交換データベース１１４をスキャンして、部品「Ｘ」のみ、部品「Ｙ」のみ、又は「Ｘ」及び「Ｙ」の両方を順序付けるための最適な選択肢を決定し、生成する。例えば、データベース１１４は、部品「Ｘ」のみが注文された、部品「Ｙ」のみが注文された、又は部品「Ｘ」と「Ｙ」の両方が注文された、というすべてのインスタンス（例えば、サービスコール）を識別するためにスキャンされ、どの部品が、最も高い頻度で問題を解決したか（すなわち、サービスコールを解決したか）が決定されることができる。例えば、部品「Ｘ」を取り付けることが、９０％の割合で問題を解決し、部品「Ｙ」を取り付けることが、たった「７％」の割合で問題を解決していた場合、推奨は、この時点で部品「Ｘ」のみを注文することを考慮することができる。この場合も、解決の頻度以外のファクタ、例えば、それぞれの部品「Ｘ」及び「Ｙ」の出荷コストなどを考慮に入れることもできる。加えて又は代替的に、オプティマイザ１１６は、３１６において、誤動作の問題を解決するのに実際に必要となる部品に対する付加の洞察を提供するために、識別テストがＳＥにとって利用可能かどうか決定することができる。これらのテストは一般に、同時交換データベース１１４に手動で注釈付けする必要があるが、代替的に、サービスログに適用されるＮＬＰ、キーワード検索などを使用して、所与のコンテキスト（例えば、所与の問題、ならびに部品「Ｘ」及び／又は「Ｙ」の順序付け）について一般に使用される識別テストを自動的に学習することが企図される。部品の最適な選択に従うランク付け及び利用可能なテストの通知は、同時交換部品アドバイザ１１８を介してＳＥに提示される。同時交換部品アドバイザ１１８は更に、適切な場合には、アドバイス処理を人間の専門家にまでエスカレートすることもできる。例えば、問題の注文が大きい（例えば、部品のコスト、部品の数、及び／又はその他によって測定される）場合、又は２回目の（又は３回目の、又は他の選択された閾値）サービスコールのバックと共に行われている場合、注文処理は、同時交換部品アドバイザ１１８によって推奨されるように及び／又はＳＥによって入力されるように、同時交換部品が出荷されるべきかどうか、又は修正されるべきかどうかを決定するのを助けるために、相談のために専門家にエスカレートされることができる。この場合、生成されて送られる同時交換情報は、大きな注文を示すエスカレーション状態の識別を含み、結果として表示される同時交換情報は例えば、専門家とのユーザインターフェースダイアログの表示を含むことができる。

図１に戻ると、アドバイザ１１８からの同時交換推奨を活用する実際の注文実行１２０は、さまざまなやり方で実施されることができる。いくつかの実施形態では、ＳＥが、同時交換部品アドバイザ１１８によって提供される１又は複数の推奨を検討し、ＳＥが推奨に同意する場合、この同意は、ユーザ入力装置１０３を介して示され、最初にリクエストされた部品「Ｘ」と任意の推奨された追加の同時交換部品の注文が、処理１２０において、自動的に実行される。このアプローチは、追加の推奨部品の注文が自動化されるので、ユーザインタフェース効率を向上させ、ＳＥによって入力される必要があるデータの量を低減する（例えば、推奨される同時交換部品「Ｙ」の部品番号を入力する必要がない）。他の実施形態では、同時交換部品「Ｙ」が同時交換部品アドバイザ１１８によって示唆されるが、実際の注文は、処理１２０において、ＳＥによって手動で実行される。更に他の実施形態では、いくつかの中間アプローチを使用することができ、例えば、ＳＥが同時交換部品「Ｙ」を注文する推奨に同意すると、注文入力フォーム１０６の第２のインスタンスが、フォームに自動的に入力される部品「Ｙ」の部品番号などの情報を提示することができる。そのような中間アプローチはなお、ＳＥが注文プロセスの完全な制御を保持することを保証しながら、ユーザインタフェース効率をかなりの程度まで増加させる。

いくつかの実施形態では、提案された同時交換部品に対応する誤作動しているマシン内の部品の検査の確認をＳＥが入力するまで、注文は実行されない。確認は、部品注文アプリケーションのダイアログ・ボックス内の肯定的なクリックなど、ユーザインタフェースによって提示される条件を満たすことによって入力されることができる。このようにして、提案された同時交換部品は、提案された同時交換部品が正しく機能していることをテストを通じてＳＥが判定した場合、注文されなくてもよい。

いくつかの実施形態では、同時交換オプティマイザ１１６は、頻繁に同時交換される部品のグループを識別することができる。これは、３、４、又はそれ以上の部品のグループであり得る。同時交換される部品のこれらのグループは、特定の製品に関する共通の問題にリンクされることができる。

いくつかの実施形態では、データベースが、一続きの交換（replace-by-chain）を表すデータを含むことができる。すなわち、識別番号の異なる複数の部品を１つの交換部品とみなすことができる。一続きの交換は、同じ機能をもつ部品の連続バージョンとみなすことができる部品のシーケンスＰ_１、Ｐ_２、・・Ｐ_ｎを指定する。Ｐ_ｎより古い部品が在庫にないと仮定すると、Ｐ_１、Ｐ_２、・・、Ｐ_ｎのいずれかの交換は、Ｐ_ｎを注文することにいたる。交換統計量を決定するために、Ｐ_１，...，Ｐ_ｎは同じ部品と考えられることができ、それゆえ、Ｐ_１及び「Ｙ」の交換と、Ｐ_２及び「Ｙ」の別の交換とは、実際には同じ同時交換の２つのインスタンスである。

非一時的記憶媒体は、マシン（例えば、コンピュータ）によって読み取り可能な形式で情報を記憶し又は送信する任意の媒体を含む。例えば、機械可読媒体は、リードオンリメモリ、ソリッドステートドライブ、フラッシュメモリ、ハードディスクドライブやＲＡＩＤアレイなどの他の電子記憶媒体、又は光ディスク又は他の光記憶媒体などの他の磁気ディスク記憶媒体等を含む。

明細書を通して示される方法は、非一時的記憶媒体上に記憶され、コンピュータ又は他の電子プロセッサによって読み取られ、実行される命令として実施することができる。

本発明が、好ましい実施形態を参照して説明されてきた。前述の詳細な説明を読み理解することにより、修正及び変更が、当業者に思いつくであろう。例示的な実施形態は、そのようなすべての修正及び変更が添付の特許請求の範囲又はそれと等価なものの範囲内に入る限りにおいて、それらはすべての修正及び変更を含むものと解釈されることが意図される。

Claims (28)

1. サービス装置であって、
   ディスプレイと、
   少なくとも１つのユーザ入力装置と、
   前記ディスプレイと前記少なくとも１つのユーザ入力装置とに動作可能に接続された電子プロセッサと、
   部品注文方法を実行するために前記電子プロセッサによって読み取り可能かつ実行可能な命令を記憶する非一時的記憶媒体と、
   を有し、前記部品注文方法は、
   ユーザインタフェースを提供するステップであって、ユーザは、当該ユーザインタフェースを通じて、前記少なくとも１つのユーザ入力装置により、リクエストされた部品を注文するための注文リクエストを提出する、ステップと、
   同時交換データベースにアクセスするサーバから、前記リクエストされた部品の同時交換情報を受信するステップと、
   前記ディスプレイ上に前記同時交換情報を表示するステップと、
   を有する、サービス装置。
2. 前記リクエストされた部品の同時交換情報を受信するステップは、前記リクエストされた部品に関連する第２の部品の識別を受信することを含み、前記表示するステップは、前記リクエストされた部品と共に前記第２の部品を同時注文することの推奨を含む、請求項１に記載のサービス装置。
3. 前記部品注文方法は更に、
   前記ユーザインタフェースを介して、前記リクエストされた部品及び前記第２の部品を含むように前記注文リクエストを更新するステップと、
   前記更新された注文リクエストを実行するステップであって、前記更新された注文リクエストを、通信インタフェースを介して注文システムに送信することを含む、ステップと、
   を有する、請求項２に記載のサービス装置。
4. 前記リクエストされた部品は、第１のリクエストされた部品及び第２のリクエストされた部品を含み、前記同時交換情報を受信するステップは、前記第１のリクエストされた部品又は前記第２のリクエストされた部品のうちの一方の識別子を受信することを含み、前記表示するステップは、前記第１のリクエストされた部品又は前記第２のリクエストされた部品のうち識別された１つのみを注文するることの推奨を含む、請求項１に記載のサービス装置。
5. 前記部品注文方法は更に、
   前記ユーザインタフェースを介して、前記第１のリクエストされた部品又は前記第２のリクエストされた部品のうち識別された一方のみを含むように前記注文リクエストを更新するステップと、
   前記更新された注文リクエストを実行するステップであって、前記更新された注文リクエストを、通信インタフェースを介して注文システムに送信することを含む、ステップと、
   を有する、請求項４に記載のサービス装置。
6. 前記同時交換データベースは、サービス作業注文データを有し、前記部品注文方法は更に、
   サービス作業注文情報を前記ユーザインタフェースに入力するステップと、
   入力されたサービス作業注文情報を遠隔サーバのデータベースマネージャに送信するステップと、
   を有し、前記データベースマネージャは、前記入力されたサービス作業注文情報を、前記同時交換データベースに自動的に記憶し更新する、請求項１乃至５のいずれか１項に記載のサービス装置。
7. 前記受信された同時交換情報は、前記リクエストされた部品に関連付けられた同時交換部品の識別情報を含み、前記サービス装置は更に、識別される前記同時交換部品の状態をチェックするために前記ディスプレイを介して通知を提供するステップを有する診断提案方法を実行する、請求項１乃至６のいずれか１項に記載のサービス装置。
8. 前記診断提案方法は、利用可能なテストを前記ディスプレイに提示するステップを更に有する、請求項７に記載のサービス装置。
9. 前記受信された同時交換情報は、前記リクエストされた部品に関連付けられた少なくとも１つの追加部品の識別情報と、前記リクエストされた部品及び前記少なくとも１つの追加部品に関して提案された交換シーケンスとを有し、前記表示するステップが、前記提案された交換シーケンスを表示することを含む、請求項１乃至８のいずれか１項に記載のサービス装置。
10. 前記サービス装置は、モバイルコンピュータ、携帯電話、コールセンターコンピュータ、又は撮像デバイスに一体化された若しくは撮像デバイスに動作可能に接続されたイメージングシステムコントローラ若しくはコンピュータを有する、請求項１乃至９のいずれか１項に記載のサービス装置。
11. 非一時的記憶媒体であって、
    少なくとも１つのサービスコール中に交換された部品の少なくとも１つのデータベースを含むサービス作業注文命令データと、
    同時交換最適化方法を実行するために電子プロセッサによって読み取り可能かつ実行可能な命令と、
    を有し、
    前記同時交換最適化方法は、
    交換部品のリクエストを含む注文リクエストを、前記サービス装置から受信するステップと、
    前記同時交換データベースを使用して、前記リクエストされた部品に関する同時交換情報を生成するステップと、
    前記サービス装置に、前記リクエストされた部品に関する前記同時交換情報を送信するステップと、
    を有する、非一時的記憶媒体。
12. 前記リクエストされた部品に関する前記同時交換情報を生成する前記ステップは、前記リクエストされた部品に関連付けられる第２の部品を識別することを含み、前記同時交換情報を送信するステップは、前記リクエストされた部品と共に第２の部品を同時注文することを推奨することを含む、請求項１１に記載の非一時的記憶媒体。
13. 前記リクエストされた部品に関連付けられる前記第２の部品を識別することは、前記同時交換データベースにおいて前記リクエストされた部品と一緒に前記第２の部品が交換された割合が閾値を超える割合であることに少なくとも基づく、請求項１２に記載の非一時的記憶媒体。
14. 前記閾値は、前記第２の部品を識別する際に使用されるとともに、前記第２の部品の少なくとも出荷コストを含む追加のファクタに基づいてスケーリングされる、請求項１３に記載の非一時的記憶媒体。
15. 前記リクエストされた部品は、第１のリクエストされた部品と第２のリクエストされた部品とを有し、前記同時交換情報を生成する前記ステップは、前記第１のリクエストされた部品又は前記第２のリクエストされた部品のうちの１つを識別することを含み、前記同時交換情報を送信する前記ステップは、前記第１のリクエストされた部品又は前記第２のリクエストされた部品のうちの一方のみを注文するための推奨を送信することを含む、請求項１１に記載の非一時記憶媒体。
16. 前記第１のリクエストされた部品又は前記第２のリクエストされた部品のうちの１つの識別は、関連するサービスコールを解決した回数が最も多かったのはどのリクエストかに関する前記同時交換データベース内のデータに基づく、請求項１５に記載の非一時的記憶媒体。
17. 前記同時交換最適化方法は更に、
    前記同時交換情報の送信に続いて、前記サービス装置からサービス作業注文データを受信し、受信したサービス作業注文データに従って交換された部品に関する情報でデータベースを更新するステップを有する、請求項１１乃至１６のいずれか１項に記載の非一時的記憶媒体。
18. 前記同時交換最適化方法は更に、交換シーケンスを提案することを更に含み、前記交換シーケンスは、部品Ｘ及び部品Ｙが交換されるべきシーケンスであり、前記問題を効率的に解決する可能性が統計的に最も高く、前記交換シーケンスは、総交換時間を含む効率メトリックの期待値を計算することによって決定され、前記期待値の計算は、部品Ｘのみが交換される必要のある確率Ｐ（Ｘ）と部品Ｙのみが交換される確率Ｐ（Ｙ）に基づき、及び、部品Ｘのみを交換するための時間Ｔ（Ｘ）と、部品Ｙのみを交換するための時間Ｔ（Ｙ）と、部品Ｘを交換した後に部品Ｙを交換するための時間Ｔ（Ｘ→Ｙ）と、部品Ｙを交換した後に部品Ｘを交換するための時間Ｔ（Ｙ→Ｘ）とを含む交換時間に基づく、請求項１１乃至１７のいずれか１項に記載の非一時的記憶媒体。
19. 前記リクエストされた部品に関する前記同時交換情報を生成する前記ステップは、定期的に交換されるとともに前記リクエストされた部品の交換中により容易にアクセスされる予防保守部品を識別することを含み、前記同時交換情報を送信する前記ステップは、前記リクエストされた部品と共に前記予防保守部品を同時注文することを推奨することを含む、請求項１１乃至１８のいずれか１項に記載の非一時的記憶媒体。
20. 部品注文システムでであって、
    請求項１１乃至１９のいずれか１項に記載の非一時的記憶媒体と、
    前記非一時的記憶媒体に動作可能に接続されて前記同時交換最適化方法を実行する電子プロセッサを有するサーバと、
    を有する部品注文システム。
21. 前記同時交換データベースに、少なくとも１つのサービス装置から受信されたサービス作業注文データが保存され、前記保存は、データベースマネージャ及び前記同時交換データベースへの手動サービスエンジニア入力の１つによって、実行される、請求項２０に記載の部品注文システム。
22. 同時交換最適化方法であって、
    サービスコール中に交換される部品の識別を少なくとも含む、医用イメージングシステムに関連するサービスコールのための同時交換データベースを保守するステップと、
    サーバにおいて、リクエストされた部品の注文リクエストを受信するステップと、
    前記同時交換データベースを使用して前記リクエストされた部品のための同時交換情報を生成するステップと、
    前記同時交換情報を送信することによって前記注文リクエストに応答するステップと、
    を有する、同時交換最適化方法。
23. サービス装置において、前記注文リクエストを生成し、前記注文リクエストを前記サーバに送信するステップと、
    前記サービス装置において、前記サーバにより送信された前記同時交換情報を受信するステップと、
    前記サービス装置において、前記同時交換情報を表示するステップと、
    を更に有する、請求項２２に記載の同時交換最適化方法。
24. 前記リクエストされた部品に関する前記同時交換情報を生成する前記ステップは、前記注文リクエストが大きな注文リクエストであることを示すメトリックによって規定されるエスカレーション条件を識別することを含み、前記サービス装置において前記同時交換情報を表示する前記ステップは、専門家とのユーザインターフェースダイアログを表示することを含む、請求項２３に記載の同時交換最適化方法。
25. 前記同時交換情報は、前記同時交換データベースにおいて前記リクエストされた部品と一緒に追加の部品が交換される割合に少なくとも基づいて、前記リクエストされた部品と同時交換されることが推奨される前記追加の部品の識別を含む、請求項２２乃至２４のいずれか１項に記載の同時交換最適化方法。
26. 前記リクエストされた部品と同時交換されることが推奨される前記追加の部品の前記識別は、前記同時交換データベースにおいて前記追加の部品が前記リクエストされた部品と一緒に、閾値を超える割合で交換されていることに少なくとも基づく、請求項２５に記載の同時交換最適化方法。
27. 前記閾値は、前記追加の部品のコスト、前記追加の部品の出荷コスト、及び前記追加の部品の返品率のうちの１つ又は複数に基づいてスケーリングされる、請求項２６に記載の同時交換最適化方法。
28. 前記同時交換情報は、少なくとも２つのリクエストされた部品のうち１つのリクエストされた部品を注文するための推奨を含み、前記推奨は、前記同時交換データベースに示されるように、各リクエストされた部品が対応するサービスコールを解決する割合に少なくとも基づく、請求項２２乃至２７のいずれか１項に記載の同時交換最適化方法。

Images