(57)【特許請求の範囲】
【請求項１】
それぞれの遠隔位置に設けられている多数の装置（２）であって、該装置の各々が識別可能であり、また、データ・ログ記録機能が作動開始したときには運用データをログ記録することが可能であり、前記データ・ログ記録機能が作動停止したときには運用データをログ記録することが不能になる多数の装置（２）と、
データ・ログ記録機能を利用するサービス契約が結ばれる度毎に、サービスの対象となる装置を識別するレコードが登録される契約データベースと、
該多数の装置と連絡している中央位置に設けられているコンピュータ・システム（１６、２２）であって、そのデータ・ログ記録機能の状態に変更を要する装置を識別するレコードをローカル・データベースに記憶しており、前記識別された装置の前記データ・ログ記録機能を、前記作動開始した状態及び作動停止した状態の一方から前記作動開始した状態及び作動停止した状態の他方へ遠隔から変更する工程を実行するようにプログラムされているコンピュータ・システム（１６、２２）と、を備え、
前記コンピュータ・システムは、
前記契約データベースから抽出された、契約中の装置を示し、契約が満了した装置を含まない抽出レコードと前記ローカル・データベースのレコードとをレコードに含まれるサービス契約番号及び装置識別子に基づいて比較する工程と、
前記抽出レコードには見出されるが前記ローカル・データベースには見当たらないレコードを前記ローカル・データベースに追加する工程と、
前記ローカル・データベースには見出されるが前記抽出レコードには見当たらないレコードを前記ローカル・データベースから除去する工程と、
前記追加されたレコードに対応する装置の前記データ・ログ記録機能を、遠隔から作動開始した状態に変更する工程と、
前記除去されたレコードに対応する装置の前記データ・ログ記録機能を、遠隔から作動停止した状態に変更する工程と、
を実行するようにさらにプログラムされている、システム。
【請求項２】
前記コンピュータ・システムは、前記契約データベースを保持している運用サーバ（２２）と、該運用サーバからの要求に応答して、前記識別された装置の前記データ・ログ記録機能の状態を遠隔から変更する自動サポート・センタ・サーバ（１６）とを含んでいる、請求項１に記載のシステム。
【請求項３】
前記運用サーバは、前記自動サポート・センタ・サーバに送られた各々の要求の日時及び該要求に関する装置識別子をログ記録するようにさらにプログラムされている請求項２に記載のシステム。
【請求項４】
前記ローカル・データベースは、顧客プロフィール情報及びサービス契約情報を含んでいる、請求項１乃至３のいずれかに記載のシステム。
【請求項５】
前記コンピュータ・システムは、監査レコードから成る契約監査データベース・テーブルを保持するようにさらにプログラムされており、前記監査レコードの各々が、前記ローカル・データベースの挿入された値又は変更された値を示すフィールドと、前記契約監査データベース・テーブルに監査レコードが挿入されたときを示す日時スタンプを含むフィールドとを含んでいる請求項１乃至５のいずれかに記載のシステム。
【請求項６】
装置において運用データの自動的なログ記録を遠隔から作動開始させる方法であって、
運用データを記録し、データ・ログ記録機能が作動開始したときに該データ・ログ記録機能に従って、記憶されている運用データを含むログ・ファイルを通信チャネルを介して中央位置へ定期的に送るように装置をプログラムする工程と、
データ・ログ記録機能を利用するサービス契約が結ばれる度毎に、サービスの対象となる装置を識別する顧客プロフィール情報及びサービス契約情報を含むレコードが登録される契約データベースを導入する工程と、
データ・ログ記録機能の状態に変更を要する装置を識別するレコードを記憶するローカル・データベースを検索する工程と、
前記契約データベースのレコードと前記ローカル・データベースのレコードとをレコードに含まれるサービス契約番号及び装置識別子に基づいて比較する工程と、
前記契約データベースのレコードには見出されるが前記ローカル・データベースには見当たらないレコードに対応する装置の前記データ・ログ記録機能を作動開始させるべきであると判定する工程と、
該判定する工程に応答して、前記通信チャネルを介して前記中央位置から前記対応する装置において前記データ・ログ記録機能を作動開始させる工程と、
を含んでいる、方法。
【請求項７】
装置において運用データの自動的なログ記録を遠隔から作動停止させる方法であって、
運用データを記録し、データ・ログ記録機能が作動開始したときに該データ・ログ記録機能に従って、記憶されている運用データを含むログ・ファイルを通信チャネルを介して中央位置へ定期的に送るように装置をプログラムする工程と、
データ・ログ記録機能を利用するサービス契約が結ばれる度毎に、サービスの対象となる装置を識別する顧客プロフィール情報及びサービス契約情報を含むレコードが登録される契約データベースを導入する工程と、
データ・ログ記録機能の状態に変更を要する装置を識別するレコードを記憶するローカル・データベースを検索する工程と、
前記契約データベースのレコードと前記ローカル・データベースのレコードとをレコードに含まれるサービス契約番号及び装置識別子に基づいて比較する工程と、
前記ローカル・データベースには見出されるが前記契約データベースのレコードには見当たらないレコードに対応する装置の前記データ・ログ記録機能を作動停の止させるべきであると判定する工程と、
該判定する工程に応答して、前記通信チャネルを介して前記中央位置から前記対応する装置において前記データ・ログ記録機能を作動停止させる工程と、
を含んでいる、方法。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は一般的には、遠隔配置されており利用者が運用する電子装置、例えば医療診断に用いられる撮像装置から得られる運用データを編集し及び／又は要約したリポートの集中型生成に関する。
【０００２】
【発明の技術的背景】
診断用イメージング・システムは、現在の健康管理施設の至る所で利用されている。かかるシステムは、身体の状態を識別し、診断して治療するための重要なツールを提供しており、診断のための外科的な介入の必要性を大幅に減じている。多くの場合には、担当医師又は放射線技師が、１種以上の撮像モダリティを介して関連のある部位及び組織の詳細な画像によって従来式の検査を補完して初めて、最終的な診断及び治療が開始する。
【０００３】
現在、医用診断イメージング・システムとして多くのモダリティが存在している。これらのモダリティには、計算機式断層写真法（ＣＴ）システム、Ｘ線システム（従来式のイメージング・システム及びディジタル式イメージング・システムの両方を含む）、磁気共鳴（ＭＲ）システム、ポジトロン・エミッション断層写真法（ＰＥＴ）システム、超音波システム及び核医学システム等がある。多くの場合に、これらのモダリティは互いに補完し合って、特定の種別の組織、器官及び生理系等を撮像するための広範な手法を医師に提供している。健康管理施設はしばしば、単一の施設又は多数の施設にこれらのイメージング・システムを幾つも配置しており、具体的な患者の必要性によって要求されると施設の医師がかかる資源を利用できるようにしている。
【０００４】
現在の医療診断イメージング・システムは典型的には、画像データを取得すると共に、データを、後に患者の体内の関心のある特徴の再構成画像を作成するように処理される有用な形態へ変換するサーキットリ（回路要素）を含んでいる。この画像データ取得及び処理用サーキットリを、撮像過程の一部として物理的又は電子的な走査が生じさえすればモダリティに拘わらず「スキャナ」と呼ぶものとする。システム及び関連するサーキットリの特定の構成要素は、物理的原理及びデータ処理要求が異なるので、当然モダリティ間で大幅に異なっている。本書では、「スキャナ」、「医用撮像装置」及び「診断用撮像装置」なる用語は互換的に用いられる。
【０００５】
上述した形式の医療診断システムはしばしば、かなりの有効寿命にわたって要求された日程の範囲内で信頼性があり且つ理解可能な画像を生成することが要求される。適正な動作を確実に行なわせるために、システムは高度な訓練を受けた人員によるサービスを定期的に受けて、この人員が撮像上の問題に対処し、システムを構成設定及び較正すると共に、定期的なシステム点検及びソフトウェア更新を行なう。さらに、近年では、サービスの提供が、契約加入施設のスキャナに直接接触可能なサービス・センタによって補われており、施設人員の一部を割いて介入する必要性がなくなっている。かかる集中型サービス提供は、医師又は放射線技師が注意を払う必要なしに診断システムを良好な動作状態に維持することを目的としており、施設から見ると全く透明である場合が多い。
【０００６】
幾つかの集中型サービス提供システムでは、コンピュータ化されたサービス・センタがネットワークを介してスキャナに接触して、システム構成及び動作状態を点検し、リポート生成用のデータを収集すると共に、他の有用なサービス機能を果たす。かかる接触はシステム「スイープ（sweep 、システムに一時的に接触して、必要な作用を与える動作）」時等に定期的に行なうことができる。このシステム・スイープ時には、特定のスキャナについて様々なシステム性能データが収集されて、履歴データと共に記憶される。次いで、これらのデータを用いてシステム性能を評価して、サービス人員の訪問を提案し又は予定に組む等を行なうことができる。
【０００７】
かかるサービス手法は、診断システムを保守するのに極めて有用であることが分かっているが、改良の余地は依然としてある。スキャナとサービス・センタとの間の対話的相互作用（interaction ）が透明であるので、医療人員がサービス更新によって不必要に煩わされることは回避されるが、サービス・センタと施設との間にはある程度の対話的相互作用があることが極めて望ましい。具体的には、対話型サービス・システムであれば、システム性能のリポート、注意を要する特定の事象についてのフィードバック、並びにシステム・ライセンス、ソフトウェア及び撮像プロトコルの更新等を含めた有用な情報交換が容易になる。現状で利用可能なサービス・システムはかかる対話型交換が可能である。具体的には、異なるモダリティが対話型サービスの提供を必要とする場合の基地としての役割を果たすプラットフォームが開発されている。このプラットフォームによって、中央サービス・センタが、遠隔配置されたスキャナと、可能性のあるサービス上の問題についての情報を交換することができ、またこれらのスキャナにサービス提供を行なう目的でスキャナから情報又はデータ・ログ・ファイルを検索することが可能になる。一つの公知のプラットフォームは、医師及び放射線技師が異なるモダリティの様々なスキャナを運転したり、統一的な直感的な形式を介してスキャナについてのサービス上の問題を報告したりすることを可能にする統一的インタフェイスを設けている。
【０００８】
遠隔位置に設けられている診断設備にサービス提供するための公知の統合型利用者対話型プラットフォームは、スキャナ側のソフトウェア、ハードウェア若しくはファームウェアにおいて構成設定されていてもよいし、又は医療施設内の様々なスキャナを結合する中央操作者ステーションに設けられていてもよい。ユーザ・インタフェイスによって、診断設備に対して実行される検査の前、途中又は後に、サービス要求を生成することが可能になる。ユーザ・インタフェイスはまた、サービス・メッセージ送信、リポート生成及び検索等を可能にする。ユーザ・インタフェイスは好ましくは、ネットワーク・ブラウザとして構成されており、イントラネット又はインターネット等のネットワークにスキャナ又は中央施設制御ステーションを結合することも容易にしている。また、同じユーザ・インタフェイスを異なるモダリティのスキャナに組み入れることにより、運転人員によるサービス要求等をさらに容易にすることができ、運転人員が施設の多様なインタフェイスに改めて精通する必要がない。
【０００９】
具体的には、既存の利用者対話型プラットフォームは、遠隔施設のスキャナの運用履歴に基づくスキャナの利用状況リポートを中央サービス・センタから要求する能力をシステム利用者に与えている。かかる利用状況リポートを作成するためには、これらのスキャナから運用データを定期的に収集することが必要である。既存のシステムによれば、スキャナをプログラムして、スキャナ自身の運用データをコンピュータ・メモリに収集し、次いで、このデータを、中央施設がスキャナに入力した予めプログラムされている予定に従って中央施設に先行的に送信しておくようにすることができる。データ・ログ記録及びリポート生成を可能にするサービス契約によってカバーされているスキャナのみが、中央施設に対しログ記録された運用データを送信することになる。中央施設は、契約によってカバーされているすべてのスキャナからの運用データのログ・ファイルを収集して処理した後に、スキャナ利用状況リポートを生成することができる。具体的には、病院の管理者は、広域ネットワーク又はインターネットを介して、当該病院において契約下にある医用撮像装置（すなわちスキャナ）について収集された運用データを編集し且つ／又は要約した利用状況リポートをいつでも要求することができる。
【００１０】
上述の既存のシステムによれば、各々のスキャナにデータ・ログ記録プログラムが記憶されているが、このプログラムは当該スキャナが妥当なサービス契約によってカバーされるまで作動開始しない。同様に、特定のスキャナをカバーしているサービス契約が満了すると、当該スキャナに組み入れられているデータ・ログ記録の特徴を作動停止させる必要がある。スキャナからの運用データの収集に関わる様々な異なるコンピュータ系システム、すなわち契約システム、接続性提供システム及びスキャナ自体、が存在している。現在、これらのシステムを共に繋いでいるのは手動の過程である。具体的には、スキャナ上のデータ・ログ記録の特徴を始動させたり停止させたりするために手動の過程が現在用いられている。新規のサービス契約の場合には、スキャナを手動で作動開始させる際の遅延のため、利用状況リポート発行サービスが期日に提供されないことがある。また、満了したサービス契約の場合には、スキャナを手動で作動停止させる際の遅延のため、利用状況リポート発行サービスがサービス契約停止日を超えて何か月にもわたって無料で提供されることがしばしばである。
【００１１】
従って、新規のサービス契約が開始したときにスキャナのデータ・ログ記録機能を自動的に作動開始させ、一旦サービス契約が満了したらデータ・ログ記録機能を同様に作動停止させることのできる運用モデルが必要とされている。この運用モデルはまた、関連するリポート発行過程を自動的に作動開始させ、また作動停止させるべきである。
【００１２】
【発明の概要】
本発明は、中央サービス施設から、遠隔配置された医用撮像装置の運用データ・ログ記録機能を自動的に作動開始及び作動停止させる方法及びシステムを指向している。具体的には、好適実施形態は、医用撮像装置が定期的なスキャナ利用状況リポートを受領する契約下に現在あることを検出するために中央施設において契約データを自動的に処理する工程と、中央施設からスキャナ・データ・ログ記録機能の特徴を自動的に遠隔から始動させる工程と、処理のために、及び後続の利用状況リポート発行のために、作動開始した医用撮像装置からの最初のデータ・ログ・ファイルの送信が成功したことを確証するように中央施設において受領されるスキャナ・データ・ログ・ファイルを監視する工程とを備えた方法を指向している。満了したサービス契約の場合には、医用撮像装置のデータ・ログ記録機能は中央施設から自動的に作動停止させられる。
【００１３】
好適実施形態の更なる側面によれば、関連するリポート発行機能もまた、新規の又は満了するサービス契約によってカバーされているスキャナでのデータ・ログ記録機能の作動開始及び作動停止と同時に自動的に作動開始及び作動停止させられる。リポートは、顧客からのアクセス要求に応答して、広域ネットワーク、例えばインターネットを介して発行される。ウェブ方式利用状況リポートを発行するリポート・サーバは、データ・ログ・ファイルを受領する中央サービス施設から遠隔に配置されていてもよい。
【００１４】
加えて、好適実施形態によれば、スキャナ・データ・ログ記録機能の自動的な作動開始又は自動的な作動停止が失敗した場合には、中央施設によって修正処置が講じられる。中央サービス施設は、契約下にあるすべてのスキャナのデータ・ログ記録サービス状態を追跡するリポートを生成する「管理ツール」をさらに組み入れている。
【００１５】
顧客が、スキャナからのログ記録データに基づいてスキャナ利用状況リポートを受領するサービス契約を結ぶ度毎に、中央サービス施設によって提供されるあらゆる他のサービスの特徴の場合と同様に、顧客情報及び契約明細がサービス契約データベースに登録される。本発明の好適実施形態によれば、この顧客プロフィール情報及びサービス契約情報は、所謂「抽出出力ファイル」として中央のサービス契約データベースから自動的に定期的に抽出される。「抽出出力ファイル」のレコードは運用サーバによって、同じ運用サーバによってローカル・データベースに保持されている所謂「契約テーブル」のレコードと比較される。相違があればすべてローカル・データベースに登録され、すなわち「抽出出力ファイル」において検出された新規レコード及び変更レコードが「契約テーブル」に追加される一方、「契約テーブル」には見出されるが「抽出出力ファイル」には見当たらないレコードは「契約テーブル」から除去される。上述の相違は、新規の契約、満了した契約、及び契約条件の変更等を示している。ローカル・データベースに以前に存在していなかった新たな医用撮像装置は、契約開始日について追跡される。ローカル・データベースに存在しているが「抽出出力ファイル」には現われない既存の医用撮像装置は、データ・ログ記録機能を停止するように標識を付される。
【００１６】
本発明の好適実施形態によれば、運用サーバから自動サポート・センタ・サーバへ、スキャナを作動開始及び作動停止させるための動作の一覧が自動的に送付される。具体的には、自動サポート・センタ・サーバは、特定の医用撮像装置のデータ・ログ記録機能、及び先行的診断過程を介して自動サポート・センタ・サーバへ運用データを返送する運用データの予定先行的送信を起動（又は停止）させる命令を送る。自動サポート・センタ・サーバによる作動開始の試行が失敗した場合には、手動介入を行なえるようにシステム管理者に自動的に通知される。最初のスキャナ・データ・ログ・ファイルが、割り当てられた予測受領日から所定の日数（例えば２日）以内に受領されなかった場合にも、やはり、データ・ログ記録の特徴が始動されていること、及び遠隔のスキャナと自動サポート・センタ・サーバとの間の接続性が失われていないことを確証する介入を行なうように、システム管理者に自動的に通知される。逆に、スキャナが停止された場合には、割り当てられた停止日の後にも自動サポート・センタ・サーバにスキャナ運用データが到着し続けているようであれば、システム管理者に自動的に通知される。
【００１７】
【好適実施形態の詳細な説明】
本発明は、放射線部門の業務、処理、患者フロー及び臨床実務を支援するための情報を提供するシステム及び方法を指向している。放射線部門に設けられている各々のスキャナが、処理のために中央サーバへ運用データを送付する。収集されるデータは、キー部門の生産性、質、並びに患者の満足度の目標及び課題に基づいてキーのスキャナ・パラメータを測定するものである。収集されたデータに基づいて、中央位置においてスキャナの利用状況レポートが生成される。これらのリポートには、インターネットを介して顧客がアクセスすることができる。スキャナは、計算機式断層写真法（ＣＴ）システム、磁気共鳴（ＭＲ）システム、超音波イメージング・システム又は他の任意の形式の計算機式医用撮像装置を包含している。
【００１８】
図１に、データ及び処理の高レベルでのフローを示す。各々のスキャナ２が、収集及び変換のために中央プロセッサ４へ運用データのログを送付する。変換されたデータは、顧客／施設データベース６から読み出した医療設備のプロフィール・データと共にデータ記憶部８に記憶される。記憶されたデータは、リポート発行システム１０へ定期的に送付される。顧客１２は、セキュリティ・サーバ１４に対し、有効性のある認証セキュリティ因子（例えば、ＩＤ及びパスワード）を入力するとこれらのリポートにアクセスすることができる。セキュリティ・サーバは、リポート発行システム１０へ有効性確認を送る。
【００１９】
図２を参照して述べると、各々のスキャナ２から、モデム１８、私設ネットワーク２０又は他の任意の適当な通信チャネルを介して自動サポート・センタ・サーバ１６によってデータが収集される。各々のスキャナは、所定の運用関連データをログ記録した後に、ログ記録したデータを自動サポート・センタ・サーバ１６へ送付するようにプログラムされている。
【００２０】
好ましいスキャナ出力フォーマットは、システム・データと検査データとを含んでいる。システム・データには、新たな検査が開始したときに示された時刻スタンプ、スキャナ・モダリティ、製品名、システムＩＤ（すなわち、特定の顧客の特定の位置でのスキャナに固有のＩＤ）、所謂固有システム番号（ＵＳＮ。時間、位置及び所有者に拘わらないスキャナの固有キー）、所謂移動位置番号（ＭＬＮ。特定の時刻のスキャナの特定の位置を追跡するのに用いる）、並びに病院名等があるがこれらに限定されない。検査データには、同じ時刻スタンプ、検査日付、検査の開始時刻及び終了時刻、検査番号、患者ＩＤ、患者年齢、患者性別、患者体重、患者病歴、患者状態、放射線技師ＩＤ、担当医ＩＤ、操作者ＩＤ、検査説明、検査データ、検査系列、並びに検査形式等を所謂カレント・プロトコル・ターミノロジ（ＣＰＴ）・コードの形態にしたものがあるがこれらに限定されない。スキャナは、先行的診断転送機構を用いて自動サポート・センタ・サーバ１６へこのデータを転送する。先行的診断データ転送機構を実行する場合には、スキャナはデータ・ログ記録サービスＩＤを用いる。スキャナは、最後の転送からの時間に基づいて、又はデータが所定のサイズ閾値に達した場合に、このデータを転送するようにプログラムされている。転送間の最長時間、及びデータ・サイズ閾値は、スキャナ単位で構成設定可能である。また、運用データが自動サポート・センタ・サーバへ送付される時刻もスキャナ単位で構成設定可能である。
【００２１】
自動サポート・センタ・サーバ１６は、ＵＳＮ、ＭＬＮ又はこれら２つの組み合わせによってスキャナ・データ・ファイルを記憶する。自動サポート・センタ・サーバ１６は、データ・ログ記録サービスＩＤと共に送付された新たなファイルが到着した場合には必ず、サービス提供者の内部ネットワークを介して運用サーバ２２に当該ファイルを送付することにより運用サーバ２２に通知する。自動サポート・センタ・サーバ１６は、運用サーバ２２へデータ・ファイルを送付することに成功しなかった場合には、エラー・メッセージをログ記録して、適当なシステム管理者に通知する。自動サポート・センタ・サーバ１６はまた、有効性のあるサービス契約に従ってログ記録データのリポートを得る認証を受けているスキャナ・システムに対し、システム管理者がデータ・ログ記録の特徴及び先行的診断データ転送を遠隔からイネーブルにしたりディスエーブルにしたりできるようにする機構を提供している。スキャナ・サイトが作動開始又は作動停止した場合には、自動サポート・センタ・サーバ１６は、スキャナ・サイトの新たな状態を運用サーバ２２に通知する。
【００２２】
顧客が、契約によってカバーされているスキャナからのログ記録データに基づいてスキャナ利用状況リポートを受領するサービス契約を結ぶ度毎に、中央サービス施設によって供給されるあらゆる他のサービスの特徴の場合と同様に、顧客プロフィール情報及び契約明細がサービス契約データベースに登録される。本発明の好適実施形態によれば、この顧客プロフィール情報及びサービス契約情報は、運用サーバ２２によって中央のサービス契約データベースから自動的に定期的に抽出されて、運用サーバ２２によって保持されているローカル・データベースの顧客プロフィール情報及び契約情報のテーブルと比較される。それぞれのファイルのレコードの間に相違があればすべてローカル・データベースに登録され、すなわち新規レコード及び変更レコードがローカル・データベースに追加される一方、満了したサービス契約に対応するレコードはローカル・データベースから除去される。ローカル・データベースに以前に記録されていなかった新たなスキャナは、契約開始日について追跡される。ローカル・データベースに記録されているが満了したサービス契約によってカバーされている既存のスキャナは、データ・ログ記録機能を停止するように標識を付される。
【００２３】
本発明の好適実施形態によれば、運用サーバ２２から自動サポート・センタ・サーバ１６へ動作の一覧が自動的に送付される。すると、自動サポート・センタ・サーバ１６は、特定のスキャナ２のデータ・ログ記録機能、及び先行的診断過程を介して自動サポート・センタ・サーバへ運用データを返送する運用データの予定先行的送信を起動（又は停止）させる命令を送る。
【００２４】
一旦、データ・ログ記録が開始してからは、運用サーバ２２は、自動サポート・センタ・サーバ１６からスキャナ・データをログ記録したファイルが到着したとのメール通知を受け取ると、スキャナ・ファイルの有効性を確認する。有効性確認は次の工程を含んでいる。ファイルの「文法」（例えばＭＲ又はＣＴ）を識別する工程、及びサービス製品についてのすべてのフィールドがレコードに存在しており正しい形式となっていることを検証する工程。レコードが完全でなく（すなわちフィールドが欠落している）又は不正確である場合には、レコードをログ記録して削除する。運用サーバ２２は、スキャナ・ファイルのデータ・フィールドの値に基づいてＣＰＴコードを生成する。運用サーバ２２はまた、要求されたフィールドを所定のＸＭＬフォーマットに符号化する。ファイルが処理されたら直ちに、運用サーバ２２は、圧縮ＸＭＬフォーマットの処理済（すなわち変換済）スキャナ・ファイルをサービス提供者の内部ネットワークを介して作成サーバ２８へ送付する。
【００２５】
運用サーバ２２はまた、どのスキャナ・サイトがデータを送付しているか、送られたデータの量、及びデータを受領した時刻を記録する。運用サーバは、保守サービス取り決め（ＭＳＡ）に関連する契約情報によって稼働する作動中サイト一覧／データベースを保持している。ＭＳＡサービス契約情報は、サービス提供者の内部ネットワークを介してＭＳＡ中間処理（staging ）サーバ２６から運用サーバによって毎日受領される。サーバ２６は次に、ＭＳＡ契約情報データベース２４から契約情報を検索する。運用サーバ２２は、作動中サイト一覧にあるスキャナ・サイトが構成設定可能な時間を上回ってファイルを提出していなければシステム管理者に通知する。また、運用サーバ２２は、データ受領頻度及びデータ・ファイル・サイズの履歴をスキャナ単位で表示するシステム管理利用目的のウェブ・ページを提供する。
【００２６】
続けて図２を参照して述べると、データ記憶部３０は、ＸＭＬ符号化されたスキャナ・データを、運用サーバ２２によってデータが送付されたら必ず、作成サーバ２８から受領する。検査間時間及び検査時間等の導出されるデータ値は作成サーバ２８によって算出され、データベース３０に記憶される。データ記憶部３０はまた、ＸＭＬ符号化された更新された施設プロフィール・データを、運用サーバ２２によってデータが送付されたら必ず、作成サーバ２８から受領する。
【００２７】
本発明の好適実施形態によれば、セキュリティ・サーバ１４はリポート・サーバ３２から物理的に離隔している。また、セキュリティ・サーバ・データベースはリポート・サーバ・アプリケーション・データベースから離隔している。すべてのリポートへの顧客のアクセスは、インターネット３４上の所謂セキュア・ソケット・レイヤ（Secure Socket Layer 、ＳＳＬ）を介して行なわれる。顧客は、インターネット３４を介してセキュリティ・サーバ１４へ利用者ＩＤ及びパスワード又はアクセス・コードをアップロードしなければならない。すべての利用者パスワード及び／又はアクセス・コードは暗号化される。セキュリティ・サーバ１４は、利用者の有効性を確認し、利用者の所属資格を判定して、アクセス特権を割り当てる。アクセス特権によって、当該顧客のサービス契約に基づいて顧客がどのリポートを利用できるかが決まる。セキュリティ・サーバ１４は、有効性が確認された利用者が、リポート・サーバ３２から提供されインターネット３４を介して顧客側アクセス・ステーションへ送信される適当なリポートにアクセスすることを許可する。
【００２８】
リポート・サーバ３２によって生成されるすべての利用状況リポートは、作成サーバ２８に送付されたスキャナ・データに基づく。すべての図形的リポートが、出力の外観を変更する構成設定可能な表示オプション（円グラフ、棒グラフ等）をサポートしている。好ましくは、リポート・サーバ３２は、Windows 95／98／NTプラットフォーム上でInternet Explorer 4.01以上、及びNetscape 4.5以上と互換性のある利用状況リポートを発行する。クライアントが互換性を有していなければ、メッセージを利用者に送って、互換性のあるブラウザへのリンクを表示する。リポート・サーバはまた、リポートのための時間軸の構成設定可能な選択肢を提供するようにプログラムされている。リポート・サーバは、傾向を示すリポート及び対基準評価を示すリポートを生成する。
【００２９】
多数のリポートのひな形がサポートされている。これらのひな形は、その各々が幾つかのリポートを含むグループにグループ分けされる。各グループへのアクセスは、利用者アクセスに基づいたものとしてよい。例えば、リポート・サーバは、スタディ・ミックス（study mix 、研究構成）、スタディ量、スタディ形式毎の画像データ及び系列データ、スタディ・ミックス毎の量、時刻及び曜日毎のスタディ・ミックス、スタディ・ミックス毎の検査時刻、検査期間毎のペイシェント・ミックス（patient mix 、患者構成）、時刻毎の検査量、曜日毎のシステム利用状況、スタディ・ミックス毎のＣＴ走査の処理時間、スタディ・ミックス毎の検査内時間、検査期間、放射線技師毎の量、担当医毎の量、放射線技師毎のＣＴ走査の処理時間、検査技師毎の検査時間、年齢毎の患者量（男性及び女性）、担当医毎のスタディ・ミックス（検査回数）、放射線技師毎のスタディ・ミックス（検査回数）、並びに放射線技師毎の検査当たりの系列及び画像数を示すリポートを生成し発行することができる。
【００３０】
本発明の好適実施形態は、患者へのサービス提供のうち「検査」段階を中心とした臨床実務（スタディ、ミックス）、運用管理（量、利用状況）、及び顧客の人口統計的分析（担当医、患者年齢等）について、重要な決定を支援する情報を放射線部門に与えるウェブ送付式サービス製品又はサービス能力である。
【００３１】
好適実施形態によるシステムは、決定支援リポートを生成するのに二つの形式のデータすなわちスキャナ・ログ・データ及び施設プロフィール・データを利用する。施設プロフィール・データは、会計記録及びデータの対基準評価の目的のために保持されている。
【００３２】
好適実施形態によるデータ・リポート発行過程は、サービス契約管理過程に組み入れられている。スキャナ利用状況リポート発行サービス契約に基づく施設プロフィール・データが取得されて処理される。このサービス契約情報に基づいて、スキャナ上でのデータ・ログ記録動作を自動的に制御する機構すなわち作動開始及び作動停止させる機構が確立される。運用サーバが、毎日の作成時にスキャナ状態の記録を取る。ウェブ方式ユーザ・インタフェイスを用いて、顧客、契約及びスキャナ状態に関連した情報を管理する。
【００３３】
インターネットを介して送信された顧客の要求に応答して、遠隔のスキャナから中央オフィスへの自動データ・ログ記録、及び中央オフィスによるデータのリポート発行を提供する各々のサービス契約は、少なくとも次の情報を有している。（１）サービス提供者と契約を交わした顧客名。顧客は、多数の病院から成る団体、多数箇所に分かれた病院施設又は単一箇所の病院施設のいずれであってもよい。（２）契約下にカバーされている病院施設名。多数の病院から成る団体型の顧客でない場合には、施設は顧客と同じであってよい。（３）スキャナが設置されている病院施設の詳細な住所。所番地、都市、州、国及び郵便番号を含む。
（４）契約下にカバーされている各々の病院施設の各スキャナのシステムＩＤ。
（５）各々のスキャナ毎に多階層サービスのどの階層が契約下にあるかを示す標識子。（６）各々のスキャナ毎の契約開始日。（７）契約終了日。すべてのスキャナで同じになる。（８）利用者契約情報。
【００３４】
図３は、顧客プロフィール・データ、契約データ及びスキャナ状態データのデータ・フローを示す。本発明の好適実施形態によれば、中央サービス施設の運用サーバ２２（図２を参照）は、「契約テーブル」及び「スキャナ状態テーブル」を保持している。加えて、運用サーバ２２は、「ログ受領履歴テーブル」を保持するデータ・プリプロセッサ（図示されていない）を組み入れている。これら３つのテーブルのすべてがOracleデータベース内に備えられている。「契約テーブル」はデータベース３０内で毎日更新される。
【００３５】
ＭＳＡ中間処理サーバ２６（図２を参照）は、ＭＳＡ契約データベース２４のような既存のデータ源から顧客プロフィール・データ及び契約データを抽出するようにプログラムされている。有効性のあるスキャナ利用状況リポート発行サービス契約によってカバーされているあらゆるスキャナ２が「抽出出力ファイル」３８（図３を参照）内にレコード（１又は複数）を有している。一つのスキャナは、スキャナが有する多数のサービス契約を反映して多数のレコードを有していてもよい。「抽出出力ファイル」は、ファイルが生成された日時を含めたヘッダ行を有する。「抽出出力ファイル」の各々の記録が、付録の表１に定義されているようなデータ・フィールドを有している。
【００３６】
好ましくは、出力ファイルは、ファイルの１行が１つのレコードを表わしており「｜」を区切り文字とするフラット・ファイルである。好ましくは、ファイルは毎日生成される。「抽出出力ファイル」はＭＳＡ中間処理サーバ２６に記憶されており、運用サーバ２２によるアクセスが可能である。「抽出出力ファイル」は毎日の更新時に上書きされてもよい。
【００３７】
図２に示す好適実施形態によれば、運用サーバ２２はＭＳＡ中間処理サーバ２６からスケジュール、例えば毎日の所定の時刻といったスケジュールに従ってＭＳＡ抽出ファイルを取り出す。運用サーバ２２は、抽出ファイルを、成功するまで１時間に１回ずつ取り出そうと試みるようにプログラムされている。運用サーバは、所定の回数、例えば５回にわたってファイルの取り出しが失敗したら「事象ログ」に「警報」を記録する。運用サーバはファイル名を、YYYY、MM、DDを受領日のそれぞれ年、月、日としてScanPATH#YYYYMMDD.txt と改める。
【００３８】
好適実施形態によれば、運用サーバは、データ源から抽出されたすべての顧客プロフィール・データ及び契約データを記憶する「契約テーブル」との名称のデータベース・テーブルを保持している。「契約テーブル」は１つのスキャナについて１つのレコードを有している。有効性のあるスキャナ利用状況リポート発行サービス契約によってカバーされているあらゆるスキャナが「契約テーブル」内にレコード（１又は複数）を有する。「契約テーブル」の各々のレコードは、付録の表２に定義されているようなデータ・フィールドを有する。「契約テーブル」の第１キーは、「システムＩＤ」／「契約番号」／「認知キー（Ｒｅｃ−Ｋｅｙ）」の組み合わせである。
【００３９】
運用サーバ２２はまた、「契約テーブル」へのすべての挿入及び変更を記録する「契約監査テーブル」との名称のデータベース・テーブルを保持している。契約監査テーブルは、表２のフィールド１〜４１について「：旧値」及び「：新規値」のためのフィールドを有し、また、監査レコードが挿入されたときの日時スタンプのためのフィールドを有している。挿入を追跡するために「契約テーブル」に「挿入トリガ」が設けられており、「契約監査テーブル」の「：新規値」フィールドに、挿入されたレコードを追加できるようにしている。変更を追跡するためには「契約テーブル」に「変更トリガ」が設けられており、「契約監査テーブル」に、変更されたレコードを「：旧値」及び「：新規値」について追加できるようにしている。表２の「監査変更要否」の欄に「要」とマークされたいずれかのフィールドが変更されると、「契約テーブル」は「変更トリガ」を起動して、レコードは決定支援の特徴を有するようになる。
【００４０】
図４に示す流れ図に従って述べると、発効中の契約に対応する「抽出出力ファイル」の次のレコードＹが運用サーバによって読み出されて（ステップ４０）、カレントの「契約テーブル」のレコードと比較される。本発明の好適実施形態によれば、「ＭＳＡ抽出出力ファイル」からの契約のうち次の条件の１つを満たすものが「契約テーブル」の「新規レコード」である（図４のステップ５６、６０及び７４）。（１）「契約テーブル」に以前に存在していない「契約番号」を有する（図４の判定ブロック５４によって決定される）。（２）「契約テーブル」に以前に存在していない「システムＩＤ」を有する（図４の判定ブロック５８によって決定される）。（３）「契約認知キー」フィールドに値１（将来）を有し、且つ同じ「契約番号」及び「システムＩＤ」を有する「契約テーブル」からの固有のレコードが見出される（図４の判定ブロック７０によって決定される）が、このレコードは代わりに「契約認知キー」フィールドに値０（現在）を有する（判定ブロック６２によって決定される）。次の条件を満たす「ＭＳＡ抽出出力ファイル」からの契約は、「契約テーブル」の「無変更レコード」である（図４のステップ４６）。「契約テーブル」の既存のレコードとすべてのデータ・フィールドが完全に一致する（図４の判定ブロック４２によって決定される）。次の条件の１つを満たす「ＭＳＡ抽出出力ファイル」からの契約は、「契約テーブル」の「変更レコード」である（図４のステップ５２及び６８）。（１）同じ「契約番号」、「システムＩＤ」及び「契約認知キー」を有する固有のレコードが「契約テーブル」から見出されるが、少なくとも１つの他のフィールドについて当該レコードと異なる値を有する（図４の判定ブロック４８によって決定される）。（２）同じ「契約番号」及び「システムＩＤ」であるが「契約認知キー」の値が１である固有のレコードが「契約テーブル」から見出される（図４の判定ブロック６４によって決定される）一方で、当該レコードは値０を有する（判定ブロック６２によって決定される）。これは、将来の契約の時期が到来したことを表わす。最新の「ＭＳＡ抽出出力ファイル」に含まれていない「契約テーブル」内のレコードは、「除去レコード」である。構文解析アルゴリズムの様々な段階（すなわち図４のブロック４４、５０、６６及び７２）において、構文解析されているレコード内のデータにエラーが検出された場合にエラー標識子が生成される。
【００４１】
最新の「ＭＳＡ抽出出力ファイル」から「新規レコード」が識別されたら、「契約テーブル」に新規レコードが追加される。「処理日」の値はカレントのシステム日付に設定される。「契約猶予期間終了日」の値は契約終了日から所定の日数後に設定される。「契約状態」フィールドは値Ｌ（発効中）に設定される。「レコード状態」フィールドは値Ａ（追加）に設定される。他のすべてのフィールドの値は「ＭＳＡ抽出出力ファイル」からのレコードに従って設定される。
【００４２】
「契約テーブル」のレコードは、「無変更レコード」と定義された場合には次のようにして変更される。「レコード状態」フィールドの値はＮ（無変更）に設定される。他のすべてのフィールドの値は変更されない。
【００４３】
「契約テーブル」のレコードは、「変更レコード」と定義された場合には次のようにして変更される。「処理日」の値は変更されない。「契約猶予期間終了日」の値は契約終了日から所定の日数後に設定される。「契約状態」フィールドの値は変更されない。「レコード状態」フィールドの値はＣ（変更）に設定される。他のすべてのフィールドの値は「ＭＳＡ抽出出力ファイル」のレコードに従って変更される。「変更レコード」は、すべてのフィールドについてのその旧値及び新規値と共に、変更時のシステム日時と共に運用サーバによって「事象ログ」にログ記録される。
【００４４】
「契約テーブル」のレコードは、「除去レコード」と識別された場合には次のようにして変更される。「契約状態」フィールドの値はＤ（失効）に設定される。「レコード状態」フィールドの値は、更新された「契約テーブル」に基づいて「契約更新ファイル」（後述）が生成された後にＲ（除去）に設定される。他のすべてのフィールドの値は変更されない。
【００４５】
以上に述べた過程から、「ＭＳＡ抽出出力ファイル」を「構文解析」することにより「契約テーブル」が生成される。本書で用いる場合には、「構文解析」という用語は、１つのファイルの各フィールドを選択して値を判定した後に、これらの値を他のファイルの既存のフィールドの値と比較することを指す。好ましくは、ＭＳＡ抽出ファイルは、運用サーバによる受領の後に毎日構文解析される。「ＭＳＡ抽出出力ファイル」を構文解析する前に、「契約テーブル」のあらゆるレコードの「レコード状態」フィールドをＩ（初期）に設定する。運用サーバは、図４に示すアルゴリズムを用いてレコード毎にＭＳＡ抽出ファイルのレコードを構文解析する。「ＭＳＡ抽出出力ファイル」を構文解析した後にも「レコード状態」フィールドに値Ｉを依然として有する「契約テーブル」のあらゆるレコードは「除去レコード」である。抽出アルゴリズムは、「ＭＳＡ抽出出力ファイル」の最後のレコードが構文解析されたと判定したら（図４の判定ブロック７６）終了する。
【００４６】
好適実施形態の更なる特徴によれば、運用サーバ２２（図２を参照）は、作成サーバ２８がそのサービス契約情報を更新するための「契約更新ファイル」を生成する。「契約更新ファイル」は、「ＭＳＡ抽出出力ファイル」の構文解析及び「契約テーブル」のレコードに対する操作が完了した後に毎日生成される。「契約更新ファイル」は運用サーバ２２に記憶されて、作成サーバ２８からアクセスすることが可能である。「契約更新ファイル」は、「契約テーブル」からのすべての発効中レコード（「契約状態」が「Ｌ」）、追加レコード、変更レコード又は除去レコード（それぞれ「レコード状態」が「Ａ」、「Ｃ」又は「Ｒ」）から成っている。「契約更新ファイル」には「無変更レコード」（「レコード状態」が「Ｎ」）は複写されない。「契約更新ファイル」は好ましくは、ＸＭＬフォーマットである。レコードのデータ・フィールドは「契約テーブル」から複写される。
【００４７】
また、スキャナから受領されたログ・データの履歴を追跡するために、「ログ受領履歴テーブル」との名称のデータベース・テーブルが作成されて保持される。運用サーバが受領した各々のログ・ファイルが「ログ受領履歴テーブル」に唯一のレコードを有する。各々のスキャナがテーブル内に多数のレコードを有していてもよく、この場合には、同じスキャナから多数のログ・ファイルが得られていることを表わす。「ログ受領履歴テーブル」のあらゆるレコードは、次のデータ・フィールドを有する。（１）第１キーは「ＩＤ」フィールドであって、レコードが挿入されたときに自動生成される数字列である。（２）ログ・ファイルを送付するスキャナの「システムＩＤ」を保持する「システムＩＤ」フィールド。（３）ログ・ファイルがデータ・プリプロセッサによって受領されたときの日時を有する「受領日時」ファイル。（４）受領したログ・ファイルのサイズを含む「ファイル・サイズ」フィールド。（５）最後にファイルを受領した日付と今回のファイル受領の日付の間の日数を保持する「最後の受領以降の日数」ファイル。
【００４８】
新たなログ・ファイルが受領されて処理されたときに、データ・プリプロセッサによって「ログ受領履歴テーブル」に新規レコードが追加される。「ログ受領履歴テーブル」のレコードは、一旦追加されたら変更も除去もされない。
【００４９】
本発明の好適実施形態によれば、運用サーバ（図２の２２）は、「ログ受領履歴テーブル」のデータを検査して、特定のスキャナから最も最近に受領したデータ・ファイルの受領日又は容量が、当該スキャナからの最近のデータ収集が不成功であった又は不完全であったことを示すか否かを判定する定期的タスクを実行する。
【００５０】
再び図２を参照して述べると、スキャナによるその運用データの送信が不成功又は不完全であった場合には、運用サーバ２２は自動サポート・センタ１６に対し、この特定のスキャナ２上でのデータ・ログ記録の特徴及び先行的診断データ転送の特徴を初期化し直すように要求を送る。加えて、運用サーバ２２に組み入れられている「管理ツール」が、スキャナを初期化し直すように自動サポート・センタ１６に送られた各々の要求毎に、日時及びスキャナの「システムＩＤ」を記録する。「管理ツール」はまた、適当なシステム管理者に、識別されたスキャナからのデータ転送に不整合が生じたことを通知する。
【００５１】
好適実施形態によれば、運用サーバはまた、有効性のある契約を有する各々のスキャナのデータ・ログ記録サービス状態を追跡するための「スキャナ状態テーブル」との名称のデータベース・テーブルを保持している。「スキャナ状態テーブル」には、将来の契約は、該契約がカレントになるまでは一切含められない。有効性のあるスキャナ利用状況リポート発行サービス契約によってカバーされている各々のスキャナが「スキャナ状態テーブル」に唯一の非停止（non-terminated）レコードを有する。図５は、スキャナ上でのデータ・ログ記録プログラムのライフ・サイクルを示す。
【００５２】
図５を参照して述べると、利用状況リポート発行サービスを有するあらゆるスキャナは、そのサービス・ライフ・サイクルにおいて次の境界日付を有する。「スキャナ始動スイープ」日は、自動サポート・センタ（図２の参照番号１６）がスキャナ上でのデータ・ログ記録の特徴を始動させるスイープを実行する予定日である。「スキャナ始動」日は、当該スキャナをカバーする契約の開始日と同一でなければならない。「最初のデータ受領予測」日は、運用サーバ（図２の参照番号２２）がスキャナから最初のログ・データ送信を受領することが予測される日付である。「最後のデータ受領」日は、運用サーバがスキャナからログ・データを受け取った実際の最後の日である。「スキャナ停止スイープ」日は、自動サポート・センタが、スキャナ上でのデータ・ログ記録の特徴を停止させるスイープを実行する予定日である。「スキャナ停止」日は、契約停止に続く猶予期間の満了日と同じでなければならない。一旦、自動サポート・センタの「スキャナ停止」スイープが成功したら、スキャナから受領されるログ・ファイルはなくなる。
【００５３】
利用状況リポート発行サービス契約によってカバーされているあらゆるスキャナは、そのサービス・ライフ・サイクルにおいて次の状態を有する。０（新規）：スキャナは発効中のサービスを有さない、１（始動中）：スキャナに対するサービスが始動されようとしている、２（作動中）：スキャナが発効中のサービスを有する、３（停止中）：スキャナに対するサービスが停止されようとしている、４（停止）：スキャナに対するサービスが既に停止している。
【００５４】
加えて、表２（付録参照）に示すように、「契約テーブル」に次のデータ・フィールドが定義されており、スキャナ状態の境界日付の計算に用いられる。「契約テーブル」のカレントの各々の契約毎に、「処理日」フィールドが、運用サーバが最初に契約を処理した日付を保持している。「契約テーブル」はまた、「契約猶予期間終了日」フィールドを含む。サービスは、契約終了日の直後に停止させなくてもよい。サービスは、所定の猶予期間の間は発効したままにしておいてよい。「契約テーブル」のカレントの各々の契約毎に、契約終了日の後の所定の構成設定可能な時間として「猶予期間終了日」フィールドが設定される。
【００５５】
スキャナ状態の境界日付は、次のようにして算出される。「スイープ始動予定」日は、契約については「契約テーブル」の「処理日」及び「契約開始日」のうち遅い方であり、スキャナについてはそのカレントのすべての契約について最も早く予定された「スキャナ始動」スイープ日となる。「最初のデータ受領予測」日は最初は予定として設定され、後に、最初のデータを実際に受領したときに更新される。「最後のデータ受領」日は、「ログ受領履歴テーブル」に従ってスキャナについて最後のログ受領日として設定される。「スイープ停止予定日」は、契約については「猶予期間終了日」であり、スキャナについてはそのカレントのすべての契約について最も遅い猶予期間終了日として設定される。「スキャナ状態テーブル」のあらゆるレコードは、表３（付録参照）に定義されているようなデータ・フィールドを有する。第１キーは「システムＩＤ」フィールドである。
【００５６】
運用サーバはまた、「スキャナ状態テーブル」へのすべての挿入及び変更を記録する「スキャナ状態監査テーブル」との名称のデータベース・テーブルを保持している。スキャナ状態監査テーブルは好ましくは、表３の第５フィールド（「最後の受領日」）を除くすべてのフィールドの「：旧値」及び「：新規値」用のフィールドを有している。また、監査レコードが挿入されたときの日時スタンプのためのフィールドも有している。挿入を追跡するために「スキャナ状態テーブル」に「挿入トリガ」が設けられており、「スキャナ状態監査テーブル」の「：新規値」フィールドに、挿入されたレコードを追加できるようにしている。変更を追跡するためには「スキャナ状態テーブル」に「変更トリガ」が設けられており、「スキャナ状態監査テーブル」に、変更されたレコードを「：旧値」及び「：新規値」について追加できるようにしている。表３の「監査変更要否」の欄に「要」とマークされたいずれかのフィールドが変更されると、「スキャナ状態テーブル」は「変更トリガ」を起動する。
【００５７】
「スキャナ状態テーブル」は好ましくは、「契約テーブル」が更新された後に毎日更新される。運用サーバは、図６に示すように、「契約テーブル」からのすべての「追加レコード」及び「変更レコード」を構文解析することにより「スキャナ状態テーブル」を生成する。このアルゴリズムは、「契約テーブル」から次の「発効中の追加／変更レコード」を検索する（ステップ７８）。ステップ８０において、アルゴリズムは、検索されたレコードについて、「契約認知キー」フィールドの値が０（カレントの契約であることを示す）であるか１（将来の契約であることを示す）であるかを判定する。値が０に等しいならば、アルゴリズムは、処理されているレコードの「システムＩＤ」が「スキャナ状態テーブル」に存在しているか否かを判定する（ステップ８２）。「スキャナ状態テーブル」のレコード操作は、「システムＩＤ」が「スキャナ状態テーブル」に存在していない場合には新規レコードの追加（図６のステップ８６）を、また「システムＩＤ」が「スキャナ状態テーブル」に存在しており且つエラーが存在していない場合には既存のレコードの変更（図６のステップ８４）を含んでいる。構文解析されているレコードのデータにエラーが検出された場合には、エラー標識子が生成される（ステップ８８）。アルゴリズムが、「契約テーブル」ファイルからの最後の「追加／変更レコード」が構文解析されたものと判定したら（図６の判定ブロック９０）、アルゴリズムは終了する。アルゴリズムは、「契約認知キー」の値が１に等しかった場合には、ステップ８０からステップ９０へ直接進む。
【００５８】
好適実施形態によれば、新規レコードは、次に基づいて「スキャナ状態テーブル」に追加される。（１）「システムＩＤ」の値が「契約テーブル」からのレコードの「システムＩＤ」に従って設定される。（２）「スイープ始動日」フィールドが、「契約テーブル」からのレコードの「処理日」及び「契約開始日」のうち遅い方に設定される。（３）「スイープ始動試行」フィールドが、サービスを始動させようとするスイープ試行の回数に設定される（既定値は０）。（４）「最初の受領日」フィールドが、自動サポート・センタ（図２の参照番号１６）が生成した先行的診断予定に従って設定される。（５）「最後の受領日」フィールドの値はヌルに設定される。（６）「スイープ停止日」フィールドは、「契約テーブル」からのレコードの「契約猶予期間終了日」に設定される。（７）「スイープ停止試行」フィールドは０に設定される。（８）「契約テーブル」のレコードの「包括範囲（room）状態」フィールドが値９Ｘを有している場合には、「状態」フィールドの値は４（停止）に設定される。他の場合には、値は０（新規）に設定される。
【００５９】
「スキャナ状態テーブル」の既存のレコードは、次のようにして修正される。
（１）「システムＩＤ」の値は変更されない。（２）「カレントの状態」フィールドが値０（新規）を有する場合には、「スイープ始動日」の値は、カレントの値と、「契約テーブル」からのレコードから導出される契約で予定されているスイープ始動の日付とのうち近い方に変更される。「カレントの状態」フィールドが０（新規）以外の値を有する場合には、値は変更されない。（３）「スイープ始動試行」フィールドの値は変更されない。（４）「最初の受領日」フィールドは、自動サポート・センタが生成した先行的診断予定に従って変更される。（５）「最後の受領日」フィールドの値は変更されない。（６）「スイープ停止日」フィールドの値は、カレントの値と「契約テーブル」からのレコードの「契約猶予期間終了日」とのうち遅い方に変更される。（７）「スイープ停止試行」フィールドは変更されない。（８）「契約テーブル」のレコードの「包括範囲状態」フィールドが値９Ｘを有する場合には、「状態」フィールドの値は４（停止）に設定される。他の場合には、値は変更されない。
【００６０】
本発明の好適実施形態によれば、すべてのスキャナの状態は、「スキャナ状態テーブル」が「契約テーブル」に基づいて更新された後に毎日更新される。運用サーバは、図７に示すアルゴリズムを用いて「スキャナ状態テーブル」のすべてのスキャナ・レコードの状態を更新する。このアルゴリズムは、「スキャナ状態テーブル」において次のレコードを検索する（ステップ９２）。ステップ９４において、「ログ受領履歴テーブル」に基づいて「最後の受領日」フィールドが更新される。ステップ９６において、アルゴリズムは、処理されているレコードの「状態」フィールドのカレントの値を判定する。
【００６１】
「状態」フィールドが値０（新規）を有する場合には、アルゴリズムは、この日が「スキャナ始動スイープ」日として予定されているか否かを判定する（ステップ１００）。「イエス」であるならば、スキャナ状態を０から１へ変更して（ステップ１０２）、「スイープ始動試行」フィールドの値を１だけインクリメントする。他のすべてのフィールドの値は変更しない。次いで、運用サーバ（図２の参照番号２２）は自動サポート・センタ（図２の参照番号１６）へ電子メールを送って、スキャナ上でのデータ・ログ記録の特徴及び先行的診断データ転送を遠隔からイネーブルにするように自動サポート・センタに要求する。次いで、アルゴリズムは、処理されているレコードが「スキャナ状態テーブル」の最後のレコードであるか否かを判定する（ステップ１１４）。「ノー」であるならば、アルゴリズムは直接ステップ１１４に進む。直前に処理されたレコードが最後のレコードであれば、アルゴリズムは終了する。最後のレコードでなければ、アルゴリズムはステップ９２に戻って次のレコードを処理する。
【００６２】
「状態」フィールドが値１（始動中）を有する場合には、アルゴリズムは「最後の受領日」がヌルであるか否かを判定し（ステップ９８）、「スキャナ始動スイープ」日として今日が予定されているか否かを判定する（ステップ１００）。「イエス」であるならば、アルゴリズムはステップ１１４へ進む。「ノー」であるならば、ステップ１１４に進む前にスキャナ状態を１から２へ変更する（ステップ１０４）。
【００６３】
「状態」フィールドが値２（作動中）を有する場合には、アルゴリズムはこの日が「スキャナ停止スイープ」日として予定されているか否かを判定する（ステップ１０６）。「イエス」であるならば、スキャナ状態を２から３へ変更し（ステップ１１２）、「スイープ停止試行」フィールドの値を１だけインクリメントする。他のすべてのフィールドの値は変更しない。次いで、運用サーバ（図２の参照番号２２）は自動サポート・センタ（図２の参照番号１６）へ電子メールを送って、スキャナ上でのデータ・ログ記録の特徴及び先行的診断データ転送を遠隔からディスエーブルにするように自動サポート・センタに要求する。次いで、アルゴリズムはステップ１１４へ進む。「ノー」であるならば、アルゴリズムは直接ステップ１１４へ進む。
【００６４】
「状態」フィールドが値３（停止中）を有する場合には、アルゴリズムはこの日が「最後の受領日」のＸ日後であるか否かを判定する（ステップ１０８）。「イエス」であるならば、アルゴリズムはステップ１１４へ進む。Ｘの値は構成設定が可能である。「イエス」であるならば、ステップ１１４へ進む前にスキャナ状態を３から４へ変更する（ステップ１１０）。「ノー」であるならば、アルゴリズムは直接ステップ１１４へ進む。
【００６５】
データ・プリプロセッサ（図２に示す運用サーバ２２に組み込まれている）は、自動サポート・センタにスキャナ・データが送られた後に、スキャナ・データの初期処理を行なう。この初期処理（図８に示す）は、新たなスキャナ・ファイルを定期的に点検すると共に収集し（ステップ１１６）、ファイルが由来したスキャナの形式を識別し、スキャナ・ファイルのフィールドを検証し（ステップ１１８）、ＣＰＴコードを生成し（ステップ１２０）、スキャナ・ファイルをＸＭＬフォーマットへ変換し（ステップ１２２）、ファイルを作成サーバへ転送することから成っている。データ・プリプロセッサの動作履歴は、どのスキャナ・ファイルを処理したか、いつ処理したか、処理にはどれ位の時間がかかったか、及び処理に関連するエラーがあればそのエラーを含んでおり、ウェブ配布フォーマットでシステム管理者が利用することが可能になっている。いずれかのスキャナがファイルを送るべきときに送ってこなかったり、処理エラーに遭遇した場合には、データ・プリプロセッサはシステム管理者へ通知する。
【００６６】
データ・プリプロセッサは、新たなスキャナ・ファイルが自動サポート・センタから到着したときを自動的に検出し、次いで、これらのファイルの有効性を自動的に確認する（図８のステップ１１８）。ファイルによっては、圧縮を解凍する必要がある場合もある。データ・プリプロセッサは、ファイルの「文法」（例えばＭＲ又はＣＴ）を識別して、不明の文法があればエラーとしてログ記録する。データ・プリプロセッサはまた、レコード内に、問題となっているサービスを提供するのに必要とされるすべてのフィールドが正しい形式で正しい範囲に存在していることを検証する。データ・プリプロセッサは可能な限り多くの生のスキャナ・ファイルを保存しようとする。レコードが完全でなければ（すなわち欠落したフィールドを有しているならば）、レコードをログ記録して削除する。削除したレコードが他のレコードを包含するレベルにある場合には、当該レコードが包含するレコードも削除する（例えば、検査レコードを削除すると、次の検査レコードまでのすべての後続レコードが削除される）。レコード内の検査又は系列番号が重複している場合には、後続のレコードの番号を振り直してこれを修正する。データ・プリプロセッサはまた、参照ドキュメントに基づいてＣＰＴコードを生成する。
【００６７】
データ・プリプロセッサは、その動作を監視する（ステップ１２６）と共に記録して（ステップ１２８）、これらの動作をシステム管理者へ報告する（ステップ１３０）。具体的には、データ・プリプロセッサは、スキャナ・ファイルが自動サポート・センタから受領された日時、及びファイルのサイズを記録し（「ログ受領履歴テーブル」へ）、スキャナ・ファイルが処理された開始及び終了の日時を記録し（これはシステムＩＤを介してアクセス可能でなければならない）、また、スキャナ・ファイルの処理に関連したあらゆるエラーを記録する（やはりこれもシステムＩＤを介してアクセス可能でなければならない）。加えて、データ・プリプロセッサは、データ・ログ記録及びリポート生成についてイネーブルになっているすべてのスキャナを定期的に点検して（ステップ１２４）、これらのスキャナがデータを送付していることを検証する。この点検を行なう割合は、構成設定可能である。データ・プリプロセッサは、エラー状態、又は動作していないスキャナがあれば、システム管理者へ通知する。また、データ・プリプロセッサは、作成サーバへ転送されてきたファイルの数をログ記録している。データ・プリプロセッサは、処理済のＸＭＬファイルを処理が完了すると直ちに圧縮した後に作成サーバ（図２の参照番号２８）へ送付する。データ・プリプロセッサは、１日１回、作成サーバ（図２の参照番号２８）へ「転送ログ」ファイルを送付する。データ・プリプロセッサは、処理されたファイル数、処理時間統計及びエラー・ログ、すなわち日、週、月及び年当たりに処理されたファイル、並びにファイルを処理した平均時間、最短時間及び最長時間；すべてのシステムＩＤ及び個々のシステムＩＤについてのスキャナ・ファイル統計すなわちシステムＩＤ当たり及びすべてのシステムＩＤ当たりの受領時刻；システムＩＤ当たり及びすべてのシステムＩＤ当たりのファイル・サイズ；並びにシステムＩＤがデータを発行すべき予測される日付を状態と共に示す動的ＨＴＭＬリポートを発行する。
【００６８】
本発明の更なる側面によれば、運用サーバは、事象ログ記録及びリポート発行を含むウェブ方式の管理ツール機能を有するようにプログラムされる。「管理ツール」は「ログ・ファイル」（必ずしもファイル構造でなくてもよい）を保持して、次の各動作を記録する。「ＭＳＡ抽出出力ファイル」の取り出しに失敗したときの日時；受領した「ＭＳＡ抽出出力ファイル」の日時及びファイル・サイズ；「ＭＳＡ抽出出力ファイル」の構文解析されたレコードの日時及び総数；抽出アルゴリズム及び関連する契約テーブルにおける日時及びエラー状態；「契約テーブル」の「新規レコード」の日時及び数、「無変更レコード」の数、「変更レコード」の数、「除去レコード」の数；「契約更新ファイル」の「新規レコード」の日時、ファイル・サイズ、数、「変更レコード」の数及び「除去レコード」の数；作成サーバによって送付され又は検索された「契約更新ファイル」の日時及びファイル・サイズ；「新規レコード」が「スキャナ状態テーブル」に追加された日時；「スキャナ状態テーブル」の「変更レコード」の日時、及び旧値と新規値；並びにスキャナを始動又は停止させるために自動サポート・センタへ送付された電子メール要求の日時、スイープの型及びシステムＩＤ。
【００６９】
加えて、「管理ツール」は要求に応じて異なるリポートを発行する。例えば、「新規顧客追跡」リポートは、新たな利用状況リポート発行サービス契約によってカバーされているが、作成モードにはまだなっていないすべてのスキャナを含んでいる。「スキャナ状態テーブル」から、状態０（新規）及び１（始動中）を有するすべてのスキャナががこの一覧に含められる。一覧に含められた各々のスキャナ毎に、リポートは次の情報を有する。「顧客名」、「スキャナ・システムＩＤ」、「契約開始日」、「サービス始動日」、「スイープ始動試行回数」、「最初のデータ受領予測日」、「状態」及び「補助」。このリポートの一覧に含められたすべてのスキャナについて、「スキャナ・システムＩＤ」、「サービス始動日」、「スイープ始動試行回数」及び「最初のデータ受領予測日」の情報は、「スキャナ状態テーブル」の「システムＩＤ」、「スイープ始動日」、「スイープ始動試行」、「最初の受領日」の各フィールドからそれぞれ検索される。
【００７０】
「新規顧客追跡」リポートの一覧に含められたすべてのスキャナについて、「顧客名」及び「契約開始日」の情報は、「契約テーブル」の「顧客名」及び「契約開始日」フィールドからそれぞれ検索される。「契約テーブル」内で多数のスキャナ利用状況リポート発行サービス契約によってカバーされているスキャナについては、すべての「契約開始日」が検索されて一覧に含められる。
【００７１】
「新規顧客追跡リポート」の一覧に含められた各々のスキャナは、次の状態のうち１つを有する。（ａ）システム日付が「最初のデータ受領予測日」よりも前である場合には、スキャナは「緑」状態を有する。（ｂ）システム日付が「最初のデータ受領予測日」から２日後以内である場合には、スキャナは「黄」状態を有する。（ｃ）システム日付が「最初のデータ受領予測日」から少なくとも２日後である場合には、スキャナは「赤」状態を有する。
【００７２】
「補助」は、「状態」が「赤」であり、且つ「スキャナ状態テーブル」からのスキャナの「カレントの状態」が１（始動中）である場合にのみ利用可能である。運用サーバによって補助要求が発行されたときに、電子メールが自動サポート・センタへ送付されて、データ・ログ記録の特徴及び先行的診断データ転送をこのスキャナに対して遠隔からイネーブルにするように要求する。「スキャナ状態テーブル」では、このスキャナの「スイープ始動日」フィールドがシステム日付に再設定される。「新規顧客追跡」リポートの「最初のデータ受領予測日」は、予定されている「サービス始動日」から所定の構成設定可能な期間後に再設定される。「スイープ始動試行回数」は１だけインクリメントされる。「スイープ始動試行回数」が２よりも大きくなったときには手動の介入が期待される。「新規顧客追跡」リポートは、リポートが要求されたときにデータベースへの問い合わせを通じて実時間で生成される。
【００７３】
「管理ツール」はまた、「満了顧客追跡」リポートを生成することができる。この追跡は、満了する利用状況リポート発行サービス契約によってカバーされているすべてのスキャナを含んでいる。この一覧は、「スキャナ状態テーブル」から状態３（停止中）又は状態２（作動中）を有するが契約猶予期間内にあるすべてのスキャナを含んでいる。一覧に含められた各々のスキャナについて、「満了顧客追跡」リポートは次の情報を有する。「顧客名」、「スキャナ・システムＩＤ」、「契約終了日」、「サービス停止日」、「スイープ停止試行回数」、「最後のデータ受領日」、「状態」及び「補助」。このリポートの一覧に含められたすべてのスキャナについて、「スキャナ・システムＩＤ」、「サービス停止日」、「スイープ停止試行回数」及び「最後のデータ受領日」の情報は、「スキャナ状態テーブル」の「システムＩＤ」、「スイープ停止日」、「スイープ停止試行」及び「最後の受領日」の各フィールドからそれぞれ検索される。このリポートの一覧に含められたすべてのスキャナについて、「顧客名」及び「契約終了日」の情報は、「契約テーブル」の「顧客名」及び「契約終了日」の各フィールドからそれぞれ検索される。「契約テーブル」内で多数のサービス契約を有するスキャナについては、すべての「契約終了日」が検索されて一覧に含められる。
【００７４】
「満了顧客追跡」リポートの一覧に含められた各々のスキャナは、次の状態のうち１つを有する。（ａ）「最後のデータ受領日」が「サービス停止日」よりも前である場合には、スキャナは「緑」状態を有する。（ｂ）「最後のデータ受領日」が「サービス停止日」から１週間後以内である場合には、スキャナは「黄」状態を有する。（ｃ）「最後のデータ受領日」が「サービス停止日」から１週間後を超えている場合には、スキャナは「赤」状態を有する。
【００７５】
「補助」は、状態が「赤」であり、且つ「スキャナ状態テーブル」からのスキャナの「カレントの状態」が３（停止中）である場合にのみ利用可能である。補助要求が発行されたときに、運用サーバによって電子メールが自動サポート・センタへ送付されて、データ・ログ記録の特徴及び先行的診断データ転送をこのスキャナに対して遠隔からディスエーブルにするように要求する。「スキャナ状態テーブル」では、このスキャナの「スイープ停止日」フィールドがシステム日付に再設定される。「スイープ停止試行回数」は１だけインクリメントされる。「スイープ停止試行回数」が２よりも大きくなったときには手動の介入が期待される。このリポートもやはり、リポートが要求されたときにデータベースへの問い合わせを通じて実時間で生成される。
【００７６】
「管理ツール」はまた、「発効中顧客追跡」リポートを生成することができる。この追跡は、生成モードにあるデータ・ログ記録を有するすべてのスキャナを含んでいる。この一覧は、「スキャナ状態テーブル」から状態２（作動中）を有するすべてのスキャナを含んでいる。一覧に含められた各々のスキャナについて、「発効中顧客追跡」リポートは次の情報を有する。「顧客名」、「スキャナ・システムＩＤ」、「始動日」、「最後のデータ受領日」、「次のデータ予測日」、「最後に受領したファイルのサイズ」及び「状態」。このリポートの一覧に含められたあらゆるスキャナについて、「スキャナ・システムＩＤ」、「最後のデータ受領日」及び「最後に受領したファイルのサイズ」の情報は、「ログ受領履歴テーブル」に含まれる「システムＩＤ」フィールド、最新の「受領日時」及び最新の受領の「ファイル・サイズ」から検索され又は導出される。「次のデータ予測日」は、自動サポート・センタの先行的診断予定に従って設定される。このリポートの一覧に含められたあらゆるスキャナについて、「始動日」情報は、「スキャナ状態テーブル」の「スイープ始動日」フィールドから検索され、「顧客名」情報は、「契約テーブル」の「顧客名」フィールドから検索される。
【００７７】
「発効中顧客追跡」リポートの一覧に含められた各々のスキャナは、次の状態のうち１つを有する。（ａ）システム日付が「次のデータ予測日」よりも前であり、且つ「最後に受領したファイルのサイズ」が１５キロバイトよりも大きい場合には、スキャナは「緑」状態を有する。（ｂ）システム日付が「次のデータ予測日」から２日後以内であるか、又は「最後に受領したファイルのサイズ」が５キロバイトと１５キロバイトとの間にある場合には、スキャナは「黄」状態を有する。（ｃ）システム日付が「次のデータ予測日」から２日後を超えているか、又は「最後に受領したファイルのサイズ」が５Ｋよりも小さい場合には、スキャナは「赤」状態を有する。「発効中顧客追跡」リポートは、リポートが要求されたときにデータベースへの問い合わせを通じて実時間で生成される。
【００７８】
「管理ツール」はまた、「ログ・データ履歴」リポートを生成することができる。この追跡は、利用状況リポート発行サービス契約によってカバーされていたことのあるすべてのスキャナを含んでいる。この一覧は、「スキャナ状態テーブル」から状態０（新規）、１（始動中）、２（作動中）、３（停止中）及び４（停止）を有するすべてのスキャナを含んでいる。一覧に含められた各々のスキャナについて、「ログ・データ履歴」リポートは次の情報を有する。「顧客名」、「スキャナ・システムＩＤ」、「始動日」、「受領ファイル数」、「平均ファイル・サイズ」、「データ受領間の平均日数」、「カレントの状態」及び「詳細」。このリポートの一覧に含められたあらゆるスキャナについて、「スキャナ・システムＩＤ」、「受領ファイル数」、「平均ファイル・サイズ」及び「データ受領間の平均日数」の情報は、「ログ受領履歴テーブル」に含まれている「システムＩＤ」フィールド、この「システムＩＤ」を有するレコード数、「ファイル・サイズ」の平均、「最後の受領以降の日数」の平均からそれぞれ検索され又は導出される。このリポートの一覧に含められたあらゆるスキャナについて、「始動日」及び「カレントの状態」の情報は、「スキャナ状態テーブル」の「スイープ始動日」フィールド及び「状態」フィールド（新規、始動中、作動中、停止中又は停止）から検索され、「顧客名」情報は、「契約テーブル」の「顧客名」フィールドから検索される。このリポートは、リポートが要求されたときにデータベースへの問い合わせを通じて実時間で生成される。
【００７９】
本発明は、医用撮像装置における運用データ・ログ記録の自動的な作動開始及び作動停止での応用に限定されている訳ではない。本書に開示した自動的手法を、利用者が運用する他の形式の電子装置から中央サービス施設への運用データのログ記録及び転送を作動開始及び作動停止させるために用いることもできる。
【００８０】
好適実施形態を参照して本発明を説明したが、当業者であれば、本発明の範囲から逸脱せずに様々な変形を施し、また好適実施形態の構成要素を均等構成で置き換え得ることが理解されよう。加えて、本発明の本質的な範囲から逸脱せずに、本発明の教示に合わせて具体的な状況を適応構成するような多くの改変を施してもよい。従って、本発明は、本発明を実施するのに想到される最良の態様として開示された特定の実施形態に限定されている訳ではなく、特許請求の範囲内に含まれるすべての実施形態を包含しているものとする。
【００８１】
特許請求の範囲で用いる場合には、「コンピュータ・システム」という用語は、単一のコンピュータ、サーバ若しくはデータ・プロセッサ、又は相互接続された複数のコンピュータ、サーバ若しくはデータ・プロセッサの群を包含するように広い意味で用いられている。当業者であれば容易に理解されるように、２つのデータ処理機能を別個のコンピュータ若しくはサーバ上で別個のソフトウェア・モジュール若しくはコンピュータ・プログラムとして具現化してもよいし、又は同じコンピュータ若しくはサーバ上で別個のソフトウェア・モジュール若しくはコンピュータ・プログラムとして具現化してもよい。特許請求の範囲で用いる場合には、「データベースにレコードを追加する」との文言は、新たなレコードを導入すること、及び既存のレコードのフィールド値を新たなレコードに一致するように変更することの両方を包含するものとする。
【００８２】
【表１】
0005002093.tif 000002
【００８３】
【表２】
0005002093.tif 000003
【００８４】
【表３】
0005002093.tif 000004
【００８５】
【表４】
0005002093.tif 000005
【００８６】
【表５】
0005002093.tif 000006
【図面の簡単な説明】
【図１】本発明の好適実施形態による遠隔配置されたスキャナからの運用データの流れ及び処理を示す線図である。
【図２】本発明の好適実施形態によるシステムの設計構成要素の相互作用を示すブロック図である。
【図３】本発明の好適実施形態による顧客プロフィール・データ、契約データ及びスキャナ状態データの流れを示す線図である。
【図４Ａ】本発明の好適実施形態に従ってそれぞれの「契約テーブル」を生成するために各々の「抽出出力ファイル」のレコードに対して運用サーバによって実行される構文解析動作を示す流れ図の一部である。
【図４Ｂ】本発明の好適実施形態に従ってそれぞれの「契約テーブル」を生成するために各々の「抽出出力ファイル」のレコードに対して運用サーバによって実行される構文解析動作を示す流れ図の残部である。
【図５】本発明の好適実施形態による遠隔スキャナのためのデータ・ログ記録プログラムのライフ・サイクルを示す時間線の図である。
【図６】本発明の好適実施形態に従って「契約テーブル」の「追加／変更レコード」から「スキャナ状態テーブル」を生成する方法の工程を示す流れ図である。
【図７Ａ】本発明の好適実施形態に従って「スキャナ状態テーブル」に記録されているスキャナの状態を更新する方法の工程を示す流れ図の一部である。
【図７Ｂ】本発明の好適実施形態に従って「スキャナ状態テーブル」に記録されているスキャナの状態を更新する方法の工程を示す流れ図の残部である。
【図８】本発明の好適実施形態によるデータ・プリプロセッサのスキャナ運用データの流れ及び処理を示す線図である。
【図１】
0005002093.tif 000007
【図２】
0005002093.tif 000008
【図３】
0005002093.tif 000009
【図４Ａ】
0005002093.tif 000010
【図４Ｂ】
0005002093.tif 000011
【図５】
0005002093.tif 000012
【図６】
0005002093.tif 000013
【図７Ａ】
0005002093.tif 000014
【図７Ｂ】
0005002093.tif 000015
【図８】
0005002093.tif 000016