保守管理

第2回 保守管理

刈谷豊田総合病院
JSMIM学術教育委員
伊藤 暢浩
東芝メディカルシステムズ株式会社
サービス本部 サービス企画部
海野 裕喜
  目次
1.はじめに

2.保守管理とは
 2-1 保守管理方針の策定
2-2 品質維持
2-3 セキュリティ管理

3.システム管理の実際
 3-1 システム管理項目
 3-2 日常点検
 3-3 画像付帯情報の修正方法
 3-4 機器更新と増設
 3-5 計画的なシステム停止の運用
 3-6 他院との連携
 3-7 院内の他システムとの連携

4.システム拡張と導入
 4-1 運用管理規程の作成と修正

5.障害対応
 5-1 リスク分析
 5-2 予防保全
 5-3 事前準備
 5-4 障害時の受付から調査 対応方針決定
 5-5 修理、縮退と代替え
 5-6 復旧
 5-7 故障の記録
 5-8 障害後の評価

6.まとめ

1.はじめに
   このテキストでは、システムを安全に使用するための日常管理から、システムの修正や拡張更新を含めた広い意味での保守管理について述べる。また、新規導入に際して留意しておきたい部分についても記載しているので参考にしていただきたい。

 医用画像情報システム管理の特徴は、目的とするデータを、早く正しく要求している場所で利用できるように管理すること、時間・空間を超えて管理することである。モダリティ画像の臨床的意義を理解し、それをふまえてのモダリティ装置の性能管理、画質管理(解像度、階調、リニアリティなど)、データ管理(画像と付帯情報の正確さ)を考える必要がある。画像について正しく理解している人材が管理してこそ真に情報を管理できると言える。

 図1は、医用画像の施設内での利用や保管について示している。空間と時間の広がりの中で、オリジナル画像の正規保管・管理は、何処でいつまで行われているか、院内に配送された画像や、持ち出された画像が何処に行ってどうなるのか等、データの広がり全体を見渡す必要がある。個人情報保護や情報セキュリティを考える元にもなる。


図1 データの広がり

   依頼をうけ、撮影されたデジタル画像は、時間や場所を制限されずに表示できる(いつでも、どこでも)が、動き(流れや広がり)を見ることは出来ない。そのため、画像を扱う画像管理者は、どんな画像が何処に動き、正規保管は何処でいつまでなされるのか、出した画像はどうなるのか、その通りに動いているのか、リスクはどこにあるかを、想定し、確認が出来る部分は確認しながら仕事をする。また、受け側のモニタ精度、送る画像の性質(圧縮などの2次画像か)等で、オリジナルと比べ画質が劣る場合があることも考慮する。レポートの提供をシステム設計時に考える。配信された画像は、短期的にでもその部門で保管されるのか、その場合、もし画像付帯情報の修正が発生した場合、修正対象になるかなど、この図を活用し管理方法を考えていただきたい。現在は少なくなったが、過去には、オリジナルや可逆圧縮画像は磁気ディスク(HD)のみに保管し、光ディスクへは長期保管用に非可逆圧縮画像を残すシステムもあった。この場合、ある時点から画質が変わることになる。現在は、HDでのオリジナル長期保管が多い。
2.保守管理とは
   保守管理とは、装置やシステムの性能を期待するレベルで維持し故障や性能の低下を最小限に抑え復旧させることで、システム管理、データ管理、品質維持、セキュリティ管理に分類できる(表2-1)。これらは施設全体で取り組むべき項目も含んでいるので、担当部門との連携が必要である。

表2-1 保守管理項目

  2-1 保守管理方針の策定
 管理体制の構築に当たっては、保守管理の方針を策定するために、厚生労働省の、「情報システムの安全管理に関するガイドライン 第3版」を理解し、自己責任(「説明責任」、「管理責任」、「結果責任」)を考慮する必要がある。
 具体的には施設における 情報システム運用責任者と、担当者(システム管理者)を決め、施設内情報システムの機器管理、データ保全、運用管理をどのように行うかを決め、保守仕様書に纏める。(表2-2 保守仕様書の目次例)運用開始後は、発生する問題に対しシステムを修正することで対応するか運用で対応するか考える。また、外部との接続要求の変化、セキュリティ強化の必要性など社会環境の変化を捉え、対処しなければならない。

 システム管理者は内部で育成するか、新規に雇用するかが考えられるが、ガイドラインを理解できるスキルが必要である。実務の対応については、外部に委託(ベンダーによる代行)することも考えられる。

システム管理者は内部で育成するか、新規に雇用するかが考えられるが、ガイドラインを理解できるスキルが必要である。実務の対応については、外部に委託(ベンダーによる代行)することも考えられる。
 システム管理については、一般的なネットワーク関連の管理にとどまらず、デジタル医用画像の情報交換規格であるDICOM関連の記録も行う。適合性を宣言したCS、装置と病院運用を考えて決めた使用キャラクタ、モダリティ毎の、サービスクラスとSCUとSCPを示すAEタイトルの記録も必要となる。DICOM通信をキャプチャーし保管しておくと後日発生するトラブルに対しても、対処しやすい。

  表2-2 保守仕様書の目次例
   保守仕様書
    1 システム概要
    1.1 全体概念図  (導入後どのようになるか)
    1.2 システム概念図  (システムは、どうなっている)
    1.3 ネットワーク構成図(場所、IPアドレスなど)
    2 保守方針
    2.1 保守サービス体制・条件 (時間帯、駐在か、一般ユーザーの窓口はどこか)
    2.2 作業内容        (誰が、どこまでやるか )
    2.3 構成機器一覧
    3 サブシステム・サブユニット毎のサービス方針・手順など
    3.1 サーバ
    3.2 クライアント
    3.3 その他の機器

   仕事の流れを記述し、関係者間の役割が明確になれば、運用保守の院内体制、担当者に要求するスキルが明確になる。具体的な保守内容例を(表2-3 ベンダーによるシステム保守メニュー例)に示す。Level-AはベンダーSEが常駐する保守管理体制で、施設内の管理者が行う業務が増加していくとLevel-E、あるいは全て行うこととなるが、施設内の管理者がその日常管理から障害時の対応まで行うことになり、相応の時間と、高度なスキルが要求される。
 
     表2-3 ベンダーによるシステム保守メニュー例(△オプション)

   施設内の管理者はシステム利用者やベンダーとの関係等を(図2-1 システム保守フロー)整理し、連絡方法やリモートメンテの連絡経路を明確にしておく。また、院内業務を遂行するに当たり、ワークフローやシステム連携図から、誰が、どのようにシステムに関わっているのか、故障や質問をどのように連絡してくるのかを想定し、院内の担当者への事前・事後の連絡方法、記録など施設全体の運用を整理し、教育しておく必要がある。
 
     図2-1 システム保守フロー

   マルチベンダーでの保守は、保守対応方法・分担・内容が異なる場合もあり、(表2-4 施設とベンダーの分担一覧(例))にしておくと、それぞれの仕事内容や責任範囲が明確になり解りやすい。

 
     表2-4 施設とベンダーの分担一覧(例)

  2-2 品質維持
 順法などの社会的責任を果たしながら、システム性能を維持し、ユーザーへの高品質で安定した情報を提供し続けるサービス品質の維持について説明する。システム性能の要因は、アクセス頻度や要求データ量に対するサーバの処理速度、ネットワーク性能、更にサーバや表示装置の点検や調整、修理などによるダウンタイムなどがある。これらは、医療機器の増設、性能アップ、運用変更により要求される質や量が変化する。

  2-3 セキュリティ管理
 システムへのアクセス権限の設定とメンテナンス、個人情報の取り扱いに対する仕組みの構築と維持(教育を含む)である。画像データの生成・作成から利用・廃棄に至るまでの正しい取り扱いを周知徹底させていくことも、セキュリティ管理の一部である。
 リモートメンテナンスは故障時の復旧時間短縮、故障予防の観点で不可欠となっているが、セキュリティ確保、個人情報保護の観点からの検討も必要であり、ベンダーとの覚書等必要な契約を取り交わし、手法と手順の確立、認証制度の導入など様々な要素を検討する。
 また、ベンダーによる施設内でのメンテナンス作業においても外部から持ち込んだパソコンの管理を確実に行う(誰が、いつ、安全が保証された機器(パソコン)をどのコネクタから、何の目的でいつまで接続し、結果はどうだったか、作業中にアクセスした個人情報は確実に消去したか)。いずれにしても、施設による責任の中で最適な方法をベンダーと共に構築する。

3.システム管理の実際
   マルチベンダーシステムの管理は、各ベンダーの責任分担を明確にすることで対応が可能になる。また、ネットワーク関連のトラブルやDICOM接続の不具合は、切り分けが難しい場合もあり、全体を統括管理するベンダーを決めておくとよい。
 管理者はシステムの全体の総合的な管理と、日常的な(1)機器管理と、(2)情報の整合管理を行い、大きな障害に陥らないようログ管理や、DISK状態の管理、システム負荷などの情報を記録し、総合的な観点から稼働状況の監視に努める。
 管理を行うにあたり、業務フローや各システム間の連携を把握するための(図3-1 システム連携図)を作る必要がある。

 
     図3-1 システム連携図

   電子カルテ端末から発した検査依頼が、RISを経由してモダリティに届き(MWM)、検査が行われ、画像がPACSに入る。読影医にオリジナル画像で読影され、レポートが書かれる。依頼した医師は、電子カルテ端末で、画像とレポートをそれぞれのWebサーバから取り出せる。

  3-1 システム管理項目
 システム管理を行うに当たって必要な項目と説明、管理内容を(表3-1 管理項目)に纏めた。青文字は、関連図や補足説明をしている項番号を示している。

  
     表3-1 管理項目

3-1-1 ネットワーク管理
 ネットワーク全体の系統を解りやすく示したものが(図3-2 ネットワーク図)で、ルーターやハブを中心に、セグメントの管理単位ごとに系統立てて図表化する。日常管理やトラブル時に用いることが多いので変更後は常に更新し最新にしておく。


     図3-2 ネットワーク図

 DICOM準拠装置は管理項目として、設置室、装置名、ホスト名、IPアドレス、AEタイトルと、SCPとして動作する場合にはポート番号を記載しておく(表3-2 IPアドレス管理表)。その他、RISクライアントやプリンタなども同様に管理する。この場合はIPアドレス、コンピュータ ネーム、システム設計によってはワークグループや、ドメインなどを記入管理する。
 
     表3-2 IPアドレス管理表

 機器設置やネットワークケーブル設置工事時には、ハブの各ポートがどこのどの端末に接続しているかの記録を残す(図3-3 ハブポート接続図)。また、ルーティングやセグメントの管理もこの表から解るようにしておくと、障害時に役立つ場合がある。まれにポート単位での障害もあるため、明確にすることで素早く対応できる。セキュリティ強化の為に、MACアドレスフィルタリングをする場合は、ケーブルの先に接続する機器をMACアドレスで特定することになる。ベンダーの作業用パソコンはいつも同じ端末でない場合もあり運用を考えておかなければならない。


図3-3 ハブポート接続図

 ネットワーク監視、接続機器の監視には専用のシステムを用意し、タイマー機能にてpingや排出ログ、DICOM-Echoの状態を取得し、機器やアプリケーション、サービスの稼働確認を行う。このシステムは24時間稼働を監視し、異常時には警告灯、アラート音などで知らせることが出来る(図3-4 ネットワークシステム監視装置画面例)。ベンダーのリモート監視部門へ通報できる機能を持ったシステムもある。


     図3-4 ネットワークシステム監視装置画面例

3-1-2 サーバ管理
 サーバ管理は、サーバ使用状況の管理や、1.マスタ(版数)管理、2.カスタマイズ履歴の管理、3.プログラム修正の管理などを行う。
ディスク残量の監視は長期保存エリアが対象となるが、計画的に管理することで増設や移行のタイミングを把握できる。(表3-3 長期保存システム情報)、(図3-5 長期保存使用率)

     表3-3 長期保存システム情報

    
     図3-5 長期保存使用率

1.マスタ(版数)管理
 施設ごとの管理方法によるが電子カルテや部門システムの運用にあわせ適宜修正し、版数を管理する。

2.カスタマイズ履歴の管理
 アプリケーションは複数のサービスやプロセスにより動作しているため、修正した部分に関係するシステム変更内容の要約や、関連するアプリケーションの情報を解りやすく記録し、管理しなければならない。カスタマイズを繰り返すと思わぬところに影響が出ることがあるので、その整合性を取るのに十分な調査を行う必要があり、ベンダーのみならず施設でもある程度の検証ができる管理体制にあると良い。

3.プログラム修正の管理
 カスタマイズ同様、何らかの不具合が発生しシステムのプログラム変更が必要な場合がある。この変更や修正によって他のシステムやアプリケーションに対する影響範囲を調べ、二次的な障害を引き起こさないよう検証し、記録を残す。

3-1-3 モニタ管理
 フィルムレスシステムでは、モニタの品質確認が重要である。画像診断モニタの管理は(社)日本画像医療システム工業会が定める”医用画像表示モニタの品質管理に関するガイドライン” JESRAX-0093 に沿った形で行う。
モニタ性能によって管理グレード1または2に分類し、機器導入時に受入試験をおこなう。その後、不変性試験はCRT医用モニタは3ヶ月ごと、液晶医用モニタは6ヶ月ごと、輝度安定化回路を装備している液晶医用モニタは1年ごとに行う。試験結果は結果報告書を作成し、受入試験は施設の定める期間、不変性試験は3年間保存する必要がある。項目として、全体評価、グレースケール、幾何学的歪み(CRTのみ)、解像度(CRTのみ)、アーチファクト、輝度均一性、コントラスト応答、最大輝度、輝度比、色度を評価または測定する。これらは施設の管理者もしくはベンダーに委託して行う。日常の使用前点検は利用者がテストパターンと基準臨床画像を表示し目視による点検を行う。詳細項目についてはガイドラインを参照してほしい。また、臨床運用に関しては日本医学放射線学会からデジタル画像の取り扱いに関するガイドラインが出されている。

3-2 日常点検
 日常管理における点検は、小さな異常を察知するために行う。点検は、視覚・聴覚・臭覚・触覚での判定や、システムがテストプログラムを自動的に走らせるもの、治具や測定器を使い各種計測を実施するものなど様々で、適正範囲と比較する事により異常を察知する。異常を発見したときは正常範囲にもどすための修正や補正を実施したり、消耗品を補充・交換したりすることで、システム障害を予防することができる。最近ではRAID(Redundant Arrays of Inexpensive Disks)や冗長化しているシステムも普及し、故障してもすぐに停止する事もなく故障を認識できないこともあるので異常を示すランプや表示、アラートを確認することが大事である。
点検は、システム以外の環境管理(サーバ室やデータ保管場所の施錠、鍵の管理などは、セキュリティ上重要)から始め、サーバ管理、データ管理などを行う。

1.エアコンの点検
 室温の管理はハードウエアの安定稼動に重要であり、設定した温度となっているかを確認する。また、停電後は直ちに稼働状態を確認する。

2.消火装置の点検
 電源やエラーの確認。設定を確認する。

3.データベースのバックアップ
 日々のデータベースをバックアップする。通常テープドライブを数本用意し取り替えながら使用する。サーバ本体のクラッシュ時に画像データとのひも付けをする大切なデータベースである。

4.ログ管理と点検
 処理に対して生成されるのがログである。このログは様々な状況変化を示し、ユーザーにとっては理解できない内容も多いかもしれないが、ログファイルの所在は最低限知っておくと良い。また、内容をある程度把握できるようになれば、小さなエラーを発見できることもあり、大きな障害を未然に防ぐことができる。また、障害時には切り分けを行うのに非常に有効であり、日頃から見慣れておくと良い。

5.RAIDの点検 各サーバのインジケーター確認
 電源、アクセスランプ、エラー、ハードディスクなどのインジケーターが点灯している事を確認し(図3-6 RAIDの点検箇所)、点検簿に記録する。

    
     図3-6 RAIDの点検箇所

6.保存画像の管理
 保存画像の中には正当に保存義務のある画像ばかりでなく、保存対象外の画像も存在する。たとえばID違いなどが、何らかの理由でサーバに保存された場合は非公開画像もしくは消去対象画像となる。これはサーバ管理における手法の中では部門システムなどの実施情報との整合を確認することで発見できる。サーバーデータベースより該当期間の整合表を作成し、確認することで多くの不具合は発見できる。その一例を(表3-4 整合表)に示す。
 
     表3-4 整合表

3-3 画像付帯情報の修正方法

 画像管理は、正しい付帯情報がつけられたものを保管管理することであるが、画像と付帯情報の不一致を発生させない事や、不要な画像を整理することは、日常的に対応する必要がある。万が一発生した場合は、速やかに対応するとともに再発の防止を考えることが重要である。
不一致の指摘は、放射線技師以外の職種、読影医や診療サイドからとなる場合もあり、処理手順を院内全体で決め、確実に対処できる体制を整えておかねばならない。さらに管理者は、読影レポートや診療サイドへの連絡と確認を確実に行う必要がある。
画像付帯情報を修正する時は、改ざんや不正な変更と区別する必要がある。修正は、不一致画像や、他施設からの持ち込み画像を自施設保管する場合も含め、規程を作成し対応する。(図3-7 データ修正の規程)

3-4 機器更新と増設
 システム構成機器の中には、UPS(Uninterruptible Power Supply;無停電電源装置)やハブのように数年のスパンで計画的に機器更新を行う必要があるものや、画像保存用ディスクなど容量を確保するための増設が必要な機器がある。システムは経営的には直接的な利益を上げにくいため更新や増設に対し理解されにくいが、不具合が発生した場合の影響が非常に大きいので予算化しておくか、管理者はそのリスクを経営者に説明し意識を共有しておく。正常稼働している機器を交換するのは勇気が要るが、その製品の機能・性能と、コスト(減価償却・耐用年数)を考慮し、切り替えていく。

3-5 計画的なシステム停止の運用
 OSやシステムの制約による計画的なシャットダウンや、機器のメンテナンスのため、あるいは電源設備の点検のためにシステム停止が必要になる場合がある。この時、影響が最小になる時間帯を選び、停止時の代替え運用も含め事前にアナウンスをする。復旧の手順や確認方法は、事前にリハーサルをしておき、さらに不測の事態にそなえ連絡体制を決めておく。電源系による停止の場合、ネットワーク機器を含むシステム全体が影響を受けるが、無停電電源の系統や、UPS付きで停電時間が短い場合などは、影響を受けない場合もあるので事前に調査しておく。
2重化しているシステムでは、片方ずつ停止させることが出来るが、2重化していないサーバの停止は、撮影系や表示系の稼働を調整して乗り切ることが考えられる。また、システム再起動後は画像サーバと他のシステム(電子カルテ、部門システムなど)との連携アプリケーションが正しく起動し情報連携が行われているか、テスト患者データなどを用い一通り確認した方がよい場合が多い。計画的なシステム停止も故障の場合も実際の運用方法に沿った最終確認が重要である。

     図3-7 データ修正の規程

3-6 他院との連携
 他院との連携は、カルテや検査データ、医用画像データの共有などを、オンラインや可搬媒体を用いて行う。ここでは、オフラインで医用画像データを相互利用する場合に限定するが、(図3-8 他院との連携)で示す内容を頭に入れ、システム構築を進める。
 
     図3-8 他院との連携

オンラインを目指す場合、IHE XDS-I等の動向を調べ、オンラインで画像を共有したい病院と組んで具体化を検討する。特定の病院間を繋ぐだけなら現在の技術の最適解で対応すればよいが、将来は標準規格に収束すると思われる。オンラインでデータ渡し(または参照)をするには、相手側の設備やセキュリティ確保などの問題がある。

IHEの PDI,IRWF
 IHEにはCD-Rなどの可搬型媒体でデータをやり取りするPDI(Portable Data for Imaging)というプロファイルがあり、CDからデータを読み込んでその一部を書き換えることができるアクターをMedia Importerと呼んでいる。どのタグを書き換えるのかまでは決めていない。
IRWF (Import Reconciliation Workflow)は、他施設から持ち込まれた可搬媒体(CD, フィルムなど)内のデータを、自施設のシステムにインポート(取り込み)する。インポート後、患者情報やオーダ関連情報を(必要に応じ)書き換え、自施設内で運用できるようにする。変更されたオリジナルの情報は保持される。患者情報は、その施設内のシステムに予め登録されていることが前提条件となっている。
 IHEでは、その他に、施設間で画像を共有するXDS-Iというプロファイルがある。

3-6-1 他院への紹介
 他院への紹介時のデータ受け渡しは、フィルムか、CD-Rが一般的である。
フィルムで運用する場合、どの装置から出力するのか、その装置で何処までの画像処理が可能か調べておく。ワークステーションにはプリントサービスクラスを実装していない場合があるので事前にベンダーに確認をする。その場合、モダリティに戻してプリントする必要があるが、データを戻せるのか、モダリティ独自のパラメータがDICOMフォーマットにしたときに欠落し制限される画像処理がないかなど事前の確認が必要である。

3-6-2 他院からの紹介
 他院からの紹介患者が放射線画像を持参することが日常的に行われている。フィルム画像を取り込む場合は日本医学放射線学会電子情報委員会が平成18年4月に「デジタル画像の取り扱いに関するガイドライン2.0版」を出しているので参考にする。

デジタル画像の取り扱いに関するガイドライン2.0版
フィルムデジタイズ装置
フィルムデジタイズ装置を電子保存に用いる場合には,次の特性を有すること
(但し、マンモグラフィは除く)。
(1)サンプリングピッチ:200μm以下
(2)空間分解能:CTF(0.25)≧0.9、CTF(0.5)≧0.8、CTF(1.0)≧0.7
   ここでCTF(n)は、nlp/mmのContrast Transfer Functionを示す。
(3)濃度階調数:1024以上(10ビットグレイスケール以上)
(4)デジタイズ濃度範囲:0.0D-3.0D以上

 CD-Rなどのメディアで他院からの画像をPACSへ取り込む場合、そのまま取り込んでしまうと他院IDを取り込むことになり、画像参照する場合、IDでは検索できず氏名などで検索することになるが、同姓同名患者となるリスクが生じる。取り込み時に情報の修正を行うなど混同しないよう自施設での運用ルールを策定し保存する必要がある。

3-7 院内の他システムとの連携
 PACS構築にあたり、連携するシステムは電子カルテ(オーダーシステム)、放射線部門システム、レポートシステムとの連携や既存PACSとの連携も必要になる。ユーザーから見て、使いやすく管理者が管理しやすいシステムとは、オペレーションがシンプルで無駄な入力の無いこと、連携の確認ができることなどである。
システムが複雑になるとトラブルの切り分けが難しくなるが、各システム間の情報の流れと制御を把握し、正しく判断出来るようにする。

PACSシステム導入時のキャラクタセット確認
 PACSシステムの仕様を検討するときには、利用可能なキャラクタセットと、どのような情報がDICOMタグにあるかを、全ての機器のCSを集めて調べておく。機器によっては、2バイト文字や日本語を扱えない場合もある。また、サーバやワークステーションなどの受信側が、取り込み可能か、表示可能かを確認する必要もある。
システム構築時は、仮名や漢字が使えない機器もあり、構成機器の最低のレベル(英数字のみ:IR6)で運用を始める場合が多い。機器の更新が進み仮名や漢字が使える装置が増えた場合でもモダリティで利用可能な漢字は、事務系のシステムほど多くはない。

4.システム拡張と導入
 システムは、めまぐるしく変化していく周りの影響(ネットワーク、システム機器、DICOM規格など)や、病院の成長・変化(新装置の設置、増設、画像枚数、閲覧範囲の増大、患者数の増加、診療科目の増減)の影響を受けるため、まるで生き物の様に同様の成長と変化を遂げる。これらをいち早く察知し、正しく対応していくことが重要である。
システム拡張や導入には明確な目的を定義することが重要であり、ユーザーはその主目的を要求仕様書の中に纏める。ベンダーは、目的を達成するためのシステムを提案する。何をどの様にするのか、その時どんなリスクがあるか、システムの機能で対応する部分と、運用で対応する部分を検討し、システムの承認仕様書や運用仕様書に纏めていく。それと前後して、運用管理の方法や保守仕様を考えていく。(図4?1)
導入により、日常業務、特にデータ確認や点検等運用管理部分が増えるが、やりやすい仕組みかどうか、また、勤務時間内外に、故障や予期せぬ事態が発生することがあるが、システムを二重化・三重化し自動切り替えで対応するのか、運用で対応するのか、手動で交換するのか、費用と効果を比較しながら検討する。
 また、当該システムが市場の中で成熟しているのか、新しい取り組みなのかにより導入までのスタンスは変わってくる。いずれの場合も、そのシステムが目的に合った状態で稼働することが最重要だが、さらに将来様々なシステムとの連携やシステム自体の更新を考慮し、データ移行の手法として標準規格でのデータ出力をサポートしているか、またはどうすれば可能かを確認する必要がある。ここでは、ベンダー自身の体力も考慮する必要がある。多くの場合、診療諸記録として数年間はデータが必要なときに利用できなければならない。ガイドラインに沿った運用を続けるために十分な検討が必要となる。

     図4-1 システム導入フロー

4-1 運用管理規程の作成と修正
 稼動するまでに、院内の運用管理規程を作成する。これは、個人情報保護法や情報セキュリティ、電子保存等、病院全体の運用を考慮する必要があるからである。その際には、厚労省のガイドラインを参考にして作成する。
 実際の運用にあたっては、委員会を設け、運用変更やシステム変更時に遅滞なく対応する。細部については、手順書や細則、運用マニュアルに記載し、通常の運用から起こりうる変更は細則を委員会にて検討し、改定する運用をする。

ガイドラインの概要
個人情報保護法20条-22条に対し、厚労省は、
医療・介護関係事業者における個人情報の適切な取扱のためのガイドライン」
第?章 医療・介護関係事業者の義務等 
第4項.安全管理措置、従業者の監督及び委託先の監督で詳しく解説した。
 さらに、「医療情報システムの安全管理に関するガイドライン(平成17年3月)」で法令に保存義務が規定されている診療録 及び、平成14年3月通知「診療録等の保存を行う場所について」に基づき作成された各ガイドラインを統合し、新規に法令保存義務が規定されている診療録及び診療諸記録の電子媒体による保存に関するガイドライン(紙等の媒体における外部保存含む)、及び医療介護関連機関における個人情報保護のための情報システム運用管理ガイドラインを含んだガイドラインとして作成、医療情報システムの安全管理措置について定めた。
また、情勢にあわせた補足を行っている。「医療情報システムの安全管理に関するガイドライン 第2版(平成19年3月)」6.8章,6.10章を加えた。
「同 第3版(平成20年3月)」6.9章,6.12章を加えた。
(第2版の6.9章6.10章は、第3版では、6.10章 6.11章となっている。) 

 電子化への移行に際し、PACS導入であればフィルム保管場所の空け渡し、画像保管管理室の確保、施錠、空調など建物の検討も必要となる。システムに係わる確認事項としては、人の動き、情報の収集方法や内容、署名が必要な書類などの扱い、他院との連携、他システムとの連携、休日夜間の扱い、定期的なシステム停止、電源設備、点検休止などがある。確認事項を列挙しベンダーとの交渉や院内の調整を行い検討内容は議事録を作成し確認を取り、事前に取り決めを行う。

5.障害対応
5-1 リスク分析
故障時のリスクが大きいシステムは、
  1.代替(フィルム、紙、電話連絡での運用)が無い場合

  2.規模が大きい:  現時点もしくは、将来大規模となる場合
     発生画像数が多い
    院内参照端末が多い

  3.ノンストップの運用をする場合
    24時間×365日稼動(定期保守を除くが、含めて考慮)

  4.データが、他のシステムでも使われている場合
などで、病院の業務が本システムへかなり依存している、代替え運用が不可能、切替をコントロールしにくい場合があると、深刻な事態に至る。どんな故障が考えられ、発生時にはどう対処し、どういう結果になるかを想定し、それでよいかを関係者全員で検討し、リスクと対処を共有する。

リスク対応の観点で、システム仕様、運用仕様を決める為の考え方や手法を示す。

1.ISMS(情報セキュリティマネジメントシステム)
 (財)日本情報処理開発協会は、情報セキュリティの見地から、医療機関向けISMSユーザーズガイドで、リスクアセスメントについて説明している。リスクアセスメントは、リスク分析からリスク評価までを実施し、リスク対応が必要な事項を選び出し対応する。

リスク値=「情報資産の価値」×「脅威」×「ぜい弱性」

情報資産の価値が高いもの、脅威が大きいもの、脆弱なものほど、リスクが高いので、その部分に金をかける、運用管理を厳しくする。

2.FMEA(潜在的故障モード影響解析:Failure Mode and Effects Analysis)の手法では、リスクとなる要因を列挙し、リスク発生時の損害、発生する確率、発生発見の見つけにくさ(検出難度)を点数化し、掛け合わせた結果、高得点の項目から対策を実施する。

危険優先指数:RPN (Risk Priority Number)=

「リスク発生時の損害」 × 「発生する確率」 × 「発生発見のし難さ」
影響 原因 検出方法
5-2 予防保全
 フィルムレス・ペーパーレスのシステムにおいては、故障が発生しフィルム・紙運用に切り替えて運用した場合、バックアップデータからの復旧や切り替え運用中のデータの取り込み、データベースの復旧に要する作業も発生する。システムダウンに至らない様に故障の兆候を掴み事前に対応することが要求される。
ハードウエア・ソフトウエア 特に磁気ディスクなどは、故障に至る前に、リトライ回数の増加が起こることがある。エラーとして表示される場合や、リトライのための時間が増えることで知ることがある。ベンダー管理のエラーログに残っている場合もあるので管理方法を話し合っておくとよい。エラー情報からのアラートを、リモートメンテによりサービスセンタに通知するベンダーもある。

5-3 事前準備
 事前準備は、システム導入時点での故障対応方法の決定に始まることを既述しているが、これが最も重要である。次に、それを前提にした障害時の連絡体制、対応方法の準備で、故障発生時に、病院関係者や患者に、必要事項を的確に最短時間で伝え、経過報告など充分な情報を伝えることにより、不信感不安感を抱かせず、患者が受ける不利益を最小にする事が目的である。最も重要な患者に対するフォローは、問題解決とは別の人員を充てる体制を取る。

1.連絡方法・経路の確立
 院内全体に関係する場合は院内放送を利用するのが迅速で効果的である。院内関係者と患者への対応が同時に行え、情報から取り残される不安が無い。部分的な障害であれば関係部署に電話で連絡する。この場合、部門毎に窓口を決めておき関係者全員に伝わるルートを作っておく。

2.連絡内容の整理
 必要最小限の情報で、的確に対応して貰うために、現場レベルでの対応法をパターン化し配布しておく。不必要な状況説明は、時間のロスであり混乱を助長する。他システムが原因の場合もありその窓口担当や上位のシステム管理者を確認しておくとともに、ワークフローや、データフローを作っておき現象から原因が想定できるようにしておく。

3.患者対応担当者との事前確認

 患者と直接向き合うスタッフに、患者対応を適切に行なうための指示書を、言葉遣いも含め、マニュアル化して渡しておく。
 また、不具合や故障を検知した場合の院内連絡方法や調査・復旧のためのマニュアルを準備し配布する。障害発生を最初に検知するのは、検査を担当する技師と、WSのユーザーである。システム管理部門は、窓口を決め対応する。ヘルプデスクの様に担当者に電話がいつでも繋がる環境に無い場合、管理者が緊急連絡用のPHSを持ち、院内の電話帳に登録し、いつでも対応できる体制をとる。
 次に、故障が疑われたときにやって貰いたいことや、故障箇所の特定を容易にするための確認法を、現場担当者が行えるレベルでマニュアル化して渡しておく。ただし、障害時にいろいろ操作されると状況を悪化させる場合もあり、現場がやるべき事、管理者に任せる事の区分けは明確にする必要がある。
 管理者は、ベンダーと協力して障害システムの復旧をするが、現在ではマルチベンダーでシステム構築をする場合が多く、不具合に対する責任の所在を明確にすべく責任範囲を明文化しておく。特に切り分けが難しいのは、ネットワークを介した接続に関係する部分で、これに対応するには、機器導入時から、特定のベンダーにネットワーク管理や全体の調整を依託するのもよい。障害時に管理者からのファーストコールを受付け、全体を把握し、故障箇所を特定し、ベンダー間を調整し、解決を図る。

5-4 障害時の受付から調査 対応方針決定 
 障害時においてまず運用方法を決定する。障害対応手順(システム稼働時に手順と時間を決める)に則った運用を行うが、選択肢として ?そのまま使う、?使用をやめて待機する、?縮退運用する、?代替え運用に切り替えるのかを、15分程度で判断する。(救急室などの緊急検査は、即時伝票運用となる)少なくとも30分以上障害が続くと判断した場合は伝票運用、フィルム運用に切り替える。
同時に、調査を行い、影響範囲の把握と診療全体への影響度を判断し、管理者が対応できるかベンダー調査や対応が必要か判断し、対応方針を決め関係部署へ指示する。
サーバに繋がらない場合などの切り分け調査法は、N/Wやサーバのベンダーと打ち合わせマニュアル化し訓練しておく。

5-5 修理、縮退と代替え
 故障時には予め決めておいた基準で修理や縮退や代替え運用に切り替える。
接触不良や、予備機への切り替えで済む簡単な故障はその場で対応する。ネットワーク機器(ハブやルーターなど)やケーブルなど、予備が設置・敷設してあれば、それを利用する。RAIDやFT(フォールト トレラント)システムでは、自動で切り替わるが、故障に気づかない場合もあるので点検項目に入れておく。

5-6 復旧
 縮退運用の場合と、フィルムや伝票での代替運用があるが、DBに係わる故障の場合は、機能的に復旧しても、故障中のDBの整合をとる必要がある。障害直前のデータが欠落していることがあるので障害前からのデータ付け合せを実施する。フィルムや伝票で運用した場合、そのデータの入力、複数のHD故障などで過去のデータを失った場合、バックアップデータを読み出しデータベースの再構築が必要な場合もある。復旧時の作業手順を用意しておくことも重要である。

5-7 故障の記録
 全ての障害から復旧した時点で、ベンダーからの報告を受け、故障原因を究明し、報告書を作成、管理責任者へ報告する。必要に応じ障害時運用の見直し、新たなルールの作成、システム要件の見直しを行うことが重要である。
故障や不具合時には、報告者、発生日時、現象、原因、対応など、後々経過をたどる事が出来るように記録する。
ベンダー対応となる場合は、上記内容を告げたあと、ベンダーから、作業者氏名、開始時刻、作業内容(予定)、修復予定時刻等を確認し、障害の影響を受ける部署に伝え、協力を要請する。復帰後は、復旧時刻、原因、処置、結果の記録を残す。

5-8 障害後の評価
 忘れないうちに、障害発生から対応体制への移行がどれだけ早く完了したかなど、障害対応の評価を行う。例として
  1 最初の連絡から、障害と認識できるまでの時間
  2 障害認識から、障害時の体制への切替時間
  3 復旧までの時間 
    いずれも短いほど評価が高い。
  4 故障が発生するまでの時間(期間) 
    長いほうが評価が高い

 個人レベルから組織レベルまで、それぞれが、何をすべきかを理解して、遅滞なく対応できたか考える。想定したことが確実に行われたか、改善点は何かをまとめ、必要に応じ障害時運用の見直し、新たなルールの作成、システム要件の見直しを行うことも重要で、1.は、発見のしやすさ(出来れば兆候を掴んで故障前に対応)、連絡ルートやシステムの改善。2.は、非常事態における切替体制の整備・準備・訓練の評価ができる。また、3.と4.は、MTTR)、MTBF)であり、向上に努める。
改善点などが有れば、対象部門と調整を行う。院内HPなども活用し情報を共有できると、連絡とマニュアルの管理がしやすい。このような業務支援システムの構築も重要である。

6.まとめ
 システムの運用管理は、始業点検やデータバックアップ、システムの故障対応という基本となる仕事から、救急患者や他施設からの紹介画像、誤入力等によるID・氏名の不一致画像の修正等の日常的なデータメンテナンス、モダリティ画像の画質管理、モニタの画質管理等、それだけで専任者が必要なほどの運用管理業務まで多岐に亘る。
情報システムのセキュリティや個人情報保護の対応は、病院全体での取り組みになる。現状を把握し、最新情報を取り入れながら、改善サイクルをまわし、常に将来のことを考えなければならない。それには、日々の業務記録を残すことが不可欠で、データの真正性が確保され、故障対応やシステム改善への正確な判断を引き出すことになる。近年、医用画像やヘルスデータは、施設内に留まらない運用が始まっており、画質やデータ管理・業務プロセスまでが外部から評価され、システム管理部門の責務は重くなっている。
医用画像装置や、医用画像の価値を最も良く知る管理者が、最良の管理を行えると言える。

参考資料


医政局研究開発振興課 医療機器・情報室管理係
  「情報システムの安全管理に関するガイドライン(平成17年3月)」
  「情報システムの安全管理に関するガイドライン第2版(平成19年3月)」
  情報システムの安全管理に関するガイドライン第3版(平成20年3月)」
   http://www.mhlw.go.jp/shingi/2008/03/s0301-2.html


(社)日本画像医療システム工業会(JIRA)
  「医用画像表示モニタの品質管理に関するガイドライン」 JESRAX-0093
   http://www.jira-net.or.jp/commission/system/04_information/files/JESRAX-0093.pdf


日本医学放射線学会
  「デジタル画像取り扱いガイドラインv.2.0 (2006年4月)」
   http://www.radiology.jp/modules/news/article.php?storyid=100


日本IHE協会
  「IHE-Jベンダワークショップ2006 の (1-4)可搬媒体系」
   http://www.ihe-j.org/events/n9/index.html
   http://www.ihe-j.org/file2/n9/2_1_kahan_baitai.pdf
   Portable Data for Imaging (PDI)に関する技術文書


(財)日本情報処理開発協会
  医療機関向けISMSユーザーズガイドp.62
   http://www.isms.jipdec.jp/doc/JIP-ISMS114-21.pdf

解説

CS(Conformance Statement)DICOM適合性宣言書。
装置の「DICOMサポート範囲」を明記したドキュメント。通常、DICOM対応機器の販売元から提供される。DICOMは非常に膨大な規格であり、モダリティ、サーバとも、機能の全てをサポートしているわけではない。また、DICOM対応機器同士でも「サポート範囲」が噛み合わなければ通信できない。使用するキャラクタセットの確認も必要である。


サービスクラス DICOMで提供されるサービスの種別

Storage データ保存
Query/Retrieve データ問合せ/検索(取得)
Basic Worklist Management 基本ワークリスト管理
Print Management プリント出力管理
Verification 交信確認
Study Management スタディ(検査)管理
Storage Commitment データ保存委託

 


SCU(Service Class User)
  DICOMのサービスを利用(要求)する側の呼び方。


SCP(Service Class Provider)
  DICOMのサービスを提供する側の呼び方。


AEタイトル
  DICOM通信を行うアプリケーションの実体であるAE(Application Entity)[アプリケーション・エンティティ]を識別するために付けられる名前。


 MTTR (Mean Time To Repair)
  故障から復旧までにかかる時間の平均。「修理時間の和÷故障回数」として計算される。システムの保全性の指標として用いられ、値が小さいほど復旧までの時間が短く、保全性が高いシステムといえる。


MTBF(Mean Time Between Failure)
  平均故障間隔。システムや機器が、使用を開始してから、または、修復してから次に故障するまでの時間の平均。稼動時間の和を、その間に生じた故障回数で割った値として求められ、これが長いほど、故障が少なくシステムの信頼性が高いといえる。機器やシステムの安定性の指標として用いられ、例えば、「MTBF=2000H」とは、「2000Hに一度故障や不具合が生じる」ということを意味している。