(57)【要約】【課題】  ソフトウェア制御がなされる機器に搭載されたソフトウェアの現状構成を簡易かつ確実に管理することを可能とする。【解決手段】  ＣＰＵ１２は、記憶部１３に記憶された制御ソフトウェア１３１のバージョンについてのマスタデータをマスタデータ管理サーバ５から取得する。ＣＰＵ１２は、記憶部１３に記憶された制御ソフトウェア１３１に含まれる複数のファイルの属性と上記のマスタデータに示される各ファイルの属性との比較により、前記バージョンのソフトウェアの標準的な構成と制御ソフトウェア１３１の構成との相違を検出する。【選択図】      図１
2005258765.tif 000002
【特許請求の範囲】
【請求項１】
複数のファイルを含んで構成されるとともにそれぞれ含まれる前記ファイルの一部が異なる複数のバージョンのソフトウェアのうちの１つに基づいて制御される機器を管理する管理装置であって、
前記機器が使用しているバージョンのソフトウェアに標準的に含まれる複数のファイルの属性をそれぞれ示したソフトウェア構成情報を取得する取得手段と、
前記機器が使用しているソフトウェアに含まれる複数のファイルの属性と前記取得手段により取得されたソフトウェア構成情報に示される各ファイルの属性との比較により、前記バージョンのソフトウェアと前記機器が使用しているソフトウェアとの相違を検出する検出手段と、
この検出手段による検出結果を示した相違情報を生成する生成手段とを具備したことを特徴とする管理装置。
【請求項２】
前記生成手段は、比較する属性として、ファイルサイズ、ファイルタイプおよび更新日の少なくとも１つを使用することを特徴とする請求項１に記載の管理装置。
【請求項３】
前記判定手段により判定されたバージョンのソフトウェアにそれぞれ含まれる複数のファイルの一部を取得する第２の取得手段をさらに具備し、
かつ前記生成手段は、前記第２の取得手段により取得されたファイルと前記機器が使用しているソフトウェアに含まれる同一名称のファイルとの内容の比較により当該ファイルの一致を判定することを特徴とする請求項１に記載の管理装置。
【請求項４】
前記取得手段は、遠隔した場所に設置されたマスタデータ管理サーバからネットワークを解して前記ソフトウェア構成情報を取得することを特徴とする請求項１に記載の管理装置。
【請求項５】
複数のファイルを含んで構成されるとともにそれぞれ含まれる前記ファイルの一部が異なる複数のバージョンのソフトウェアのうちの１つに基づいて制御される機器を管理する管理装置としてコンピュータを機能させるプログラムであって、
前記コンピュータを、
前記機器が使用しているバージョンのソフトウェアに標準的に含まれる複数のファイルの属性をそれぞれ示したソフトウェア構成情報を取得する取得手段と、
前記機器が使用しているソフトウェアに含まれる複数のファイルの属性と前記取得手段により取得されたソフトウェア構成情報に示される各ファイルの属性との比較により、前記バージョンのソフトウェアと前記機器が使用しているソフトウェアとの相違を検出する検出手段と、
この検出手段による検出結果を示した相違情報を生成する生成手段としてそれぞれ機能させることを特徴とするプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、モダリティシステムのようなソフトウェア制御がなされる機器が使用しているソフトウェアを管理する管理装置に関する。
【背景技術】
【０００２】
病院等で利用されるモダリティシステムを制御するソフトウェアをバージョンアップしたり、当該ソフトウェアの障害を復旧する場合、サービスマンが病院へ出張する。診察を止められないため、深夜や休日などにサービスマンが手作業でソフトウェアのバージョンアップや病院情報の取り出し、再インストールを行う。この作業に当ってサービスマンは、手順書などを参照する。工場側担当者は、リモートメンテナンスなどによるシステム状態の調査や各担当者への確認を行う。
【０００３】
さて、この様な作業を行う場合にサービスマンは、モダリティシステムに搭載済みのソフトウェアの現状構成を確認する必要がある。そしてこの確認のためには従来、ソフトウェアの管理情報に含まれるバージョン情報が利用されていた。
【特許文献１】特開平９−２３４２０１号公報
【発明の開示】
【発明が解決しようとする課題】
【０００４】
ところが、ソフトウェアのバージョンアップが不適切な手順で行われた場合には、バージョン情報の更新が行われないことがあり、この様なケースではバージョン情報からはソフトウェアの現状構成を正しく判断することができない。また、ソフトウェアの一部のファイルに障害が生じている場合にも、バージョン情報からはソフトウェアの現状構成を正しく判断することができない。
【０００５】
本発明はこのような事情を考慮してなされたものであり、その目的とするところは、ソフトウェア制御がなされる機器に搭載されたソフトウェアの現状構成を簡易かつ確実に管理することを可能とする管理装置を提供することにある。
【課題を解決するための手段】
【０００６】
以上の目的を達成するために本発明は、複数のファイルを含んで構成されるとともにそれぞれ含まれる前記ファイルの一部が異なる複数のバージョンのソフトウェアのうちの１つに基づいて制御される機器を管理する管理装置であって、前記機器が使用しているバージョンのソフトウェアに標準的に含まれる複数のファイルの属性をそれぞれ示したソフトウェア構成情報を取得する取得手段と、前記機器が使用しているソフトウェアに含まれる複数のファイルの属性と前記取得手段により取得されたソフトウェア構成情報に示される各ファイルの属性との比較により、前記バージョンのソフトウェアと前記機器が使用しているソフトウェアとの相違を検出する検出手段と、この検出手段による検出結果を示した相違情報を生成する生成手段とを具備する。
【発明の効果】
【０００７】
本発明によれば、ソフトウェア制御がなされる機器に搭載されたソフトウェアに含まれるファイルの属性比較によりファイルの相違として検出され、この検出結果を示した相違情報が作成されるので、この相違情報に基づいて上記ソフトウェアの現状構成を簡易かつ確実に管理することを可能となる。
【発明を実施するための最良の形態】
【０００８】
以下、図面を参照して本発明の一実施形態について説明する。  
図１は本実施形態に係るマスタデータ管理システムの構成を示す図である。  
モダリティシステム1-1，1-2，1-3は、ＣＴ（Computed Tomography）やＭＲ（Magnetic Resonance）などのような医療用の検査を行うシステムである。なお以下においてモダリティシステム1-1，1-2，1-3を互いに区別する必要がないときには、モダリティシステム１と表記する。モダリティシステム１は、病院内ＬＡＮ（Local Area Network）２を介してプロキシサーバ３に接続されている。プロキシサーバ３は、病院内ＬＡＮ２とインターネットなどのネットワーク４とを接続する。
【０００９】
マスタデータ管理サーバ５は、ネットワーク４、プロキシサーバ３および病院内ＬＡＮ２を介してモダリティシステム１にアクセス可能である。マスタデータ管理サーバ５は、マスタデータデータベース（以下、マスタデータＤＢと称する）６およびサービスデータデータベース（以下、サービスデータＤＢと称する）７にもアクセス可能である。
【００１０】
マスタデータＤＢ６は、モダリティシステム１の制御ソフトウェアを構成する各ファイルのバイナリデータや、このバイナリデータのコンフィグレーション情報などが登録される。マスタデータＤＢ６は、制御ソフトウェアのパッチなど登録することができる。そしてマスターデータＤＢ６は、バイナリデータ、コンフィグレーション情報およびパッチなどを、制御ソフトウェアのバージョン毎のマスタデータとして管理する。すなわち、１つのマスタデータは制御ソフトウェアの１つのバージョンに対応する。そしてマスタデータは、対応するバージョンの制御ソフトウェアに含まれる複数のファイルのそれぞれについての属性情報が含まれる。さらにはマスタデータには、対応するバージョンの制御ソフトウェアに含まれる複数のファイルの一部のバイナリデータや、対応するバージョンの制御ソフトウェアに適用可能なパッチが含まれる場合がある。サービスデータＤＢ７は、病院情報や契約情報（モダリティシステム１毎のライセンス情報などを含む）などが登録される。サービスデータＤＢ７は、サービス要求の履歴を管理するためのサービス履歴情報も登録される。
【００１１】
マスタデータ管理サーバ５は、サービスデータＤＢ７に登録されたライセンス情報などを元に、マスタデータやパッチなどを管理する。マスタデータ管理サーバ５は、モダリティシステム１からのサービス要求によりマスタデータＤＢ６およびサービスデータＤＢ７から必要な情報を取り出し、そのサービス要求に合わせた処理を行う。マスタデータ管理サーバ５は、病院内ＬＡＮ２に接続して備えられたローカルサーバ（図示せず）からなされるサービス要求を受け付けるようにしても良い。マスタデータ管理サーバ５は、サービス要求に応答した履歴を示すようにサービス履歴情報を作成し、サービスデータＤＢ７に登録する。
【００１２】
なお、モダリティシステム1-1，1-2，1-3、病院内ＬＡＮ２およびプロキシサーバ３は、病院に配置される。マスタデータ管理サーバ５、マスタデータＤＢ６およびサービスデータＤＢ７は、医療機器の保守管理を行なう保守管理センタに配置される。保守管理センタは、病院から遠隔した場所にある。
【００１３】
さてモダリティシステム１はそれぞれ同様に、測定系１１、ＣＰＵ１２、記憶部１３、通信部１４およびユーザインタフェース部（ＵＩＦ部）１５を含む。  
測定系１１は、例えばＣＴシステムであればスキャナ部や寝台部などであり、ＭＲシステムであれば磁石部、ＲＦ部あるいは寝台部などである。モダリティシステム1-1，1-2，1-3は、互いに同種である必要はなく、測定系１１はそれぞれ異なる場合もある。ＣＰＵ１２は、記憶部１３に記憶された制御ソフトウェア１３１に基づいて測定系１１を制御する。記憶部１３は、例えばハードディスクドライブや半導体メモリなどを含み、上記の制御ソフトウェア１３１の他に、ＣＰＵ１２が使用する管理ソフトウェア１３２等のようなソフトウェアや各種のデータを記憶する。管理ソフトウェア１３２は、ＣＰＵ１２に制御ソフトウェアの構成を判定するための後述する処理を行わせる。管理ソフトウェア１３２は、当該モダリティシステム１の製造段階において予め記憶部１３にインストールされても良い。あるいは、CD-ROMなどのようなリムーバブルな記録媒体に記録して、あるいはＬＡＮ２やネットワーク４などを介して配布される管理ソフトウェア１３２が上記の記憶部１３に適宜にインストールされても良い。
【００１４】
通信部１４は、病院内ＬＡＮ２を介する通信を行う。ユーザインタフェース部１５は、例えば液晶表示器などの表示デバイスと、例えばキーボードやマウスなどの入力デバイスとを含む。ユーザインタフェース部１５は、ＣＰＵ１２に対する指示を入力するとともに、情報報知のための表示をＣＰＵ１２の制御の下に行う。
【００１５】
次に以上のように構成されたマスタデータ管理システムの動作について説明する。  
まず、新しいバージョンの制御ソフトウェアがリリースされる場合に、その制御ソフトウェアの各ファイルのバイナリデータをマスタデータＤＢ６に登録しておく。出荷する状態の製品マシン（第一号機などを使用する）にマスタデータ管理サーバ５からリモートでアクセスして、この製品マシンに搭載された制御ソフトウェアのバイナリデータをマスタデータ管理サーバ５が取得してマスタデータＤＢ６に登録することも可能である。
【００１６】
ただし、制御ソフトウェアに含まれるファイルの一部には、運用に伴って内容が改変されるものなどのようなマスタデータとして不適切なファイルも有る。そこでマスタデータ管理サーバ５では、図２に示すようなマスタデータ作成用のＧＵＩ（Graphical User Interface）上でのユーザ指示に基づいてマスタデータを作成する。
【００１７】
マスタデータ管理サーバ５は、表示フィールドＦ１には既に管理対象として選択されたディレクトリ（以下、管理ディレクトリと称する）を表示する。マスタデータ管理サーバ５は、ボタンＢ１が押下されたことに応じて、マスタデータＤＢ６に登録されているバイナリデータのディレクトリの中から管理ディレクトリの選択を受け付ける。そして新たに選択された管理ディレクトリを表示フィールドＦ１に追加表示する。
【００１８】
マスタデータ管理サーバ５は、表示フィールドＦ２には管理ディレクトリに含まれるファイルのファイル名を表示する。またマスタデータ管理サーバ５は、表示フィールドＦ２に、ファイル名に対応付けて「ConfigurationFile」「ExecutionFile」「EtcFile」の各チェックボックスを表示する。マスタデータ管理サーバ５は、１つのファイル名に対応づけれらた３つのチェックボックスを択一的にチェック可能とする。
【００１９】
マスタデータ管理サーバ５は、ボタンＢ２が押下されたことに応じて、対応する３つのチェックボックスのいずれかにチェックがなされている管理ファイルを、そのチェックがされているチェックボックスに対応したファイルタイプのファイルとしてマスタデータに登録する。対応する３つのチェックボックスのいずれにもチェックがなされていない管理ファイルは、マスタデータには登録しない。従って、制御ソフトウェアに含まれたファイルであるものの、マスタデータとして不適切なファイルをマスタデータから除外し、必要なファイルは全てマスタデータに登録することができる。
【００２０】
なお、マスタデータに登録するマシンは、ネットワークに接続することによりマスタデータを取得することが可能である。また、ネットワークに接続しなくても、マシン同士の直接接続によりマスタデータを構築することが可能である。
【００２１】
さて、モダリティシステム１では、管理ソフトウェア１３２に基づく処理の実行がユーザインタフェース部１５から指定されたことに応じて、ＣＰＵ１２が管理ソフトウェア１３２に基づいて図３に示すような処理を開始する。
【００２２】
ステップＳａ１においてＣＰＵ１２は、ユーザ操作画面をユーザインタフェース部１５に表示させる。ここで表示させるユーザ操作画面はＧＵＩベースであって、ユーザ操作画面中に配置した比較開始ボタンの押下により制御ソフトウェア１３１の検査の開始指示を受け付けることができる。そして上記の比較開始ボタンが押下されたことに応じてＣＰＵ１２はステップＳａ１からステップＳａ２に進む。
【００２３】
ステップＳａ２においてＣＰＵ１２は、通信部１４、病院内ＬＡＮ２、プロキシサーバ３およびネットワーク４を介してマスタデータ管理サーバ５にアクセスし、予め登録されている病院名やモダリティ名などを元にマスタデータ管理サーバ５に対して接続を要求する。
【００２４】
このような接続要求を受けるとマスタデータ管理サーバ５は、図３に示すような処理を開始する。  
ステップＳｂ１においてマスタデータ管理サーバ５は、上記の病院名やモダリティ名などと、サービスデータＤＢ７に記憶された病院情報や契約情報に基づいて、要求元のモダリティシステム１を認証する。ステップＳｂ２においてマスタデータ管理サーバ５は、上記の認証に成功したかどうかを確認する。もし認証に失敗したならばマスタデータ管理サーバ５は、ステップＳｂ２からステップＳｂ３へ進む。そしてステップＳｂ３においてマスタデータ管理サーバ５は、未登録であることを要求元のモダリティシステム１に通知する。
【００２５】
さて、ステップＳａ２にて接続を要求した後にＣＰＵ１２は、ステップＳａ２からステップＳａ３へ進む。ステップＳａ３においてＣＰＵ１２は、マスタデータ管理サーバ５から接続が許可されたか否かを確認する。そして上述のように未登録であることが通知された場合には、マスタデータ管理サーバ５は接続が許可されないと判断して、ステップＳａ３からステップＳａ４へ進む。ステップＳａ４においてＣＰＵ１２は、病院情報の登録をマスタデータ管理サーバ５に要求する。こののちにＣＰＵ１２は、ステップＳａ３に戻る。
【００２６】
一方、マスタデータ管理サーバ５は、ステップＳｂ３での通知を終えた後、上述のようにモダリティシステム１から病院情報の登録が要求されたならば、ステップＳｂ４においいて、この要求に応じた登録処理を行う。そしてこののちにマスタデータ管理サーバ５は、ステップＳｂ１に戻る。
【００２７】
マスタデータ管理サーバ５は、ステップＳｂ１での認証処理において認証に成功したならば、ステップＳｂ２からステップＳｂ５へ進む。ステップＳｂ５においてマスタデータ管理サーバ５は、接続を許可することを接続要求元のモダリティシステム１に通知する。
【００２８】
このように接続を許可することが通知されたモダリティシステム１のＣＰＵ１２は、ステップＳａ３からステップＳａ５へ進む。ステップＳａ５においてＣＰＵ１２は、マスタデータをマスタデータ管理サーバ５に要求する。この要求を受けると、ステップＳｂ６においてマスタデータ管理サーバ５は、マスタデータおよびサービス履歴データを要求元のモダリティシステム１へ送信する。このときマスタデータ管理サーバ５は、要求元のモダリティシステム１が使用中の制御ソフトウェアのバージョンに関するマスタデータをマスタデータＤＢ６から取り出し、送信対象とする。またマスタデータ管理サーバ５は、要求元のモダリティシステム１に関するサービス履歴データをサービスデータＤＢ７から取り出し、送信対象とする。
【００２９】
このようにマスタデータおよびサービス履歴データがマスタデータ管理サーバ５より送信されたならば、ステップＳａ６においてＣＰＵ１２は当該マスタデータおよびサービス履歴データを受信する。すなわちＣＰＵ１２は、ネットワーク４、プロキシサーバ３および病院内ＬＡＮ２を介して到来するマスタデータおよびサービス履歴データを通信部１４に受信させ、当該マスタデータおよびサービス履歴データを記憶部１３に記憶させる。続いてステップＳａ７においてＣＰＵ１２は、制御ソフトウェア１３１を構成するファイルを検査する。具体的にはＣＰＵ１２は、マスタデータにファイル名が示される各ファイルについて、記憶部１３に記憶された制御ソフトウェア１３１に含まれる同名のファイルの属性と、マスタデータに示される属性とを個々に比較する。そしてＣＰＵ１２はこの比較の結果に基づき、ファイルの過不足や、内容の不一致を検出する。比較に用いる属性としては、ファイルサイズ、ファイルタイプ、あるいは更新日などが利用できる。これらの属性の１つのみの比較であっても良いし、複数の属性の比較をそれぞれ行っても良い。また、一部のファイルに関しては、バイナリデータの内容の比較を行うようにしても良い。
【００３０】
ステップＳａ８においてＣＰＵ１２は、上記の検査の結果をユーザインタフェース部１５に表示させる。図４はこの検査結果の表示画面の一例を示す図である。図４の例では、表示フィールドＦ１１に検査の結果を示している。また図４の例では、ステップＳａ６で受信したサービス履歴データの内容を表示フィールドＦ１２に表示している。モダリティシステム１の保守作業者は、この画面に表示される情報から、使用中の制御ソフトウェア１３１が現バージョンの標準的な構成に対してどのような構成の相違があるかを知ることができる。また保守作業者は、バージョンアップやパッチなどのダウンロードの履歴、モダリティシステム１のバージョン、あるいは病院情報などを確認できる。
【００３１】
なお、図４に示す表示画面はＧＵＩベースであって、いくつかのボタンが配置されている。アップデートが可能であるファイルに対応付けて、UpdateボタンＢ１１および説明ボタンＢ１２が配置される。UpdateボタンＢ１１が押下された場合にＣＰＵ１２は、当該ファイルのアップデートを行う。説明ボタンＢ１２が押下された場合にＣＰＵ１２は、アップデートする内容などの説明を表示する。適用可能なパッチがある場合、このパッチに対応付けてUpdateボタンＢ１１を配置し、このUpdateボタンＢ１１の押下に応じてＣＰＵ１２が当該パッチをマスタデータ管理サーバ５からダウンロードし、適用するようにしても良い。
【００３２】
過去に行ったバージョンアップやアップデートの項目に対応付けて、戻すボタンＢ１３および説明ボタンＢ１４が配置されている。戻すボタンＢ１３が押下された場合にＣＰＵ１２は、制御ソフトウェア１３１を当該バージョンアップやアップデートを行う前の状態に戻す。説明ボタンＢ１２が押下された場合にＣＰＵ１２は、戻すときに必要なマニュアルを表示する。パッチの適用を示す項目が含まれていた場合、この項目に対しても戻すボタンＢ１３を配置し、この戻すボタンＢ１３の押下に応じてＣＰＵ１２が適用したパッチを戻すようにしても良い。
【００３３】
比較レポート提出ボタンＢ１５が配置されている。この比較レポート提出ボタンＢ１５が押下された場合にＣＰＵ１２は、ネットワークを利用して比較レポートや対応レポートを提出したり、比較レポートや対応レポートをファイルに落として工場へ送る。すなわち例えばステップＳａ９においてＣＰＵ１２は、結果ファイルおよび対応方法の登録をマスタデータ管理サーバ５に要求する。そしてこれをもって、ＣＰＵ１２はこの図３の処理を終了する。結果ファイルおよび対応方法ファイルの登録の要求を受けると、ステップＳｂ７においてマスタデータ管理サーバ５は、結果ファイルおよび対応方法ファイルをサービスデータＤＢ７に登録する。そしてこれをもって、マスタデータ管理サーバ５はこの図３の処理を終了する。結果ファイルは、検査結果を含んだ比較レポートを示すデータである。対応方法ファイルは、保守作業者が問題に対応した場合の対応方法を示したデータである。
【００３４】
このように結果ファイルおよび対応方法を登録しておくことにより、次回から同じ結果を表示したものに、参考表示できる。すなわち、保守作業者が表示された検査結果を理解できないために問題を解決できない場合に、対応方法を工場において判断して保守作業者に指示するようなことが可能となる。また、ある問題に保守作業者が対応した場合などに、その対応方法を新たに同じ問題に対応しなければならない保守作業者が閲覧できるようにできる。具体的には、モダリティＡで「AAA」というファイルをアップデートした結果、当該モダリティＡが起動しなくなったために、保守作業者Ａが「BBB」というファイルを修正してモダリティＡを起動できるようにしたならば、このことを示した対応方法ファイルを登録しておく。そうすれば、モダリティＢで「AAA」というファイルをアップデートしたためにモダリティＢが起動しなくなったとき、保守作業者Ｂが上記の登録された対応方法ファイルを閲覧することにより、「BBB」というファイルを修正すれば良いことが分り、そのような対応を行なうことができる。一方、もし保守作業者Ａが上記の大砲方法が分らなかった場合には、結果ファイルを工場に提出し、工場の担当者から「BBB」というファイルを修正すればよいことを教えて貰うことができる。
【００３５】
なお、モダリティシステム毎のオプション（例えばＤＩＣＯＭ送信機能など）についても、病院毎の情報としてマスタデータ管理サーバ５へ登録することができる。これにより、ソフトウェアオプションについても比較・確認が可能である。
【００３６】
病院毎またはモダリティシステム毎に固有情報（スキャンするための設定情報や病院名など）を登録することができる。これにより、保守作業を行なった際に、これらの固有情報を再設定して、作業前の状態に容易に戻すことができる。
【００３７】
ソフトウェアオプションについてもディレクトリ構造で管理することで、多くのデータを比較することが可能である。
【００３８】
病院固有情報などは、そのデータの整合性を取ることが可能である。
【００３９】
ソフトウェアシステムのブロック単位でバージョンを管理することができるため、病院毎のオプションに対する比較が可能である。例えば、／ａａａ／ａａａディレクトリ内はＡＡＡオプションデータのため、そのディレクトリ以下の比較結果によりオプション設定が確実にできているか、足りないものはないか等がわかる。
【００４０】
以上のように本実施形態によれば、モダリティシステム１が使用中の制御ソフトウェア１３１が現バージョンの標準的な構成に対してどのような構成の相違があるかを検出することができる。従って、制御ソフトウェア１３１の現状構成を正確に把握することが可能である。例えば、構築ミスによる動作不安定原因の特定が容易となる。このため、複雑なソフトウェアシステムの管理を、開発者や保守作業者の手間を増やすことなく実施することができる。また、不適切なバージョンアップ作業に伴う構築ミスを解消するための前環境への復旧作業などを特別な知識無しに行うことが可能になる。このようなことから、保守作業を行うサービスマンへのソフトウェア構成の教育を簡易とすることが可能になる。また、アップデートや病院固有情報の入れ替えにミスがなくなり、モダリティシステムの占有時間が減るためサービスマンや病院側への負荷を削減できる。
【００４１】
さらに本実施形態によれば、マスターサーバへ登録することにより、全国で一斉にバージョンアップやパッチのインストールが可能になり配布の手間がかからない。
【００４２】
この実施形態は、次のような種々の変形実施が可能である。  
検査の結果を表示するのではなく、例えば検査結果に基づいて制御ソフトウェア１３１の構成と現バージョンの標準的な構成との相違を解消するように自動的にファイルの更新を行うなどの別の措置を講ずるようにしても良い。  
制御ソフトウェア１３１の構成の検査は、マスタデータ管理サーバ５で行うこともできる。あるいは、病院内ＬＡＮ２またはネットワーク４に接続して検査端末を設け、この検査端末にて制御ソフトウェア１３１の構成の検査を行うようにしても良い。  
検査対象となる制御ソフトウェアは、モダリティシステム１の制御のためのものには限らない。
【００４３】
なお、本発明は上記実施形態そのままに限定されるものではなく、実施段階ではその要旨を逸脱しない範囲で構成要素を変形して具体化できる。また、上記実施形態に開示されている複数の構成要素の適宜な組み合わせにより、種々の発明を形成できる。例えば、実施形態に示される全構成要素から幾つかの構成要素を削除してもよい。さらに、異なる実施形態にわたる構成要素を適宜組み合わせてもよい。
【図面の簡単な説明】
【００４４】
【図１】本発明の一実施形態に係るマスタデータ管理システムの構成を示す図。
【図２】マスタデータ作成用のＧＵＩの一例を示す図。
【図３】制御ソフトウェア１３１の現状構成を検査するためのＣＰＵ１２およびマスタデータ管理サーバ５の処理手順を示すフローチャート。
【図４】検査結果の表示画面の一例を示す図。
【符号の説明】
【００４５】
１，1-1，1-2，1-3…モダリティシステム、２…病院内ＬＡＮ、３…プロキシサーバ、４…ネットワーク、５…マスタデータ管理サーバ、６…マスタデータデータベース、７…サービスデータデータベース、１１…測定系、１３…記憶部、１４…通信部、１５…ユーザインタフェース部、１３１…制御ソフトウェア、１３２…管理ソフトウェア。
【図１】
2005258765.tif 000003
【図２】
2005258765.tif 000004
【図３】
2005258765.tif 000005
【図４】
2005258765.tif 000006