連載⑤現場発,病院と患者のためのシステム連載⑤現場発,病院と患者のためのシステム優れた機能をもったシステムでもダウンしたら終わりです.航空管制システムや新幹線の制御システムのダウンは生死にかかわり,原子炉制御のシステムダウンは,生死のみならず,その地域でノンストップのための条件*杉浦和史生活できるかどうかにさえかかわってきます.システムに頼っている度合いが強ければ強いほど,医療情報システムに限らず,システムが止まってしまう要因は大きく分けて5つあります.電源断/ハードウェア障害/ソフトウェア障害/アプリケーション不具合/操作ミスです.これら5つの要因と対策につき,説明します.ダウンした際のダメージは大きくなります.どうすれば問題なく稼働し続けられるか..電源断電源の供給が止まると,コンピュータ本体のみならず,周辺機器がすべて動かなくなり,システムは機能しなくなってしまいます.これに備えてバッテリーで電源供給するのが普通ですが,間違って理解されている場合があります.それは,電源の供給が止まっても,バッテリーを使ってシステムを稼働し続けられると考えていることです.モバイル環境で使うことが多いノートパソコンは,バッテリー駆動で何時間も動くよう省電力設計になっているものがありますが,システムの心臓部ともいえるサーバーは,電力消費量が多く,バッテリーだけで長時間動かし続けるには限界があります.サーバー用のバッテリーは,電源供給が止まったら,データの保全性(Integrity)を確保したうえで,安全に停止するための時間稼ぎをする手段と考えたほうが無難です.サーバーだけではなく,周辺機器にも安全に停止させる間,電源を供給してやらなければなりません.安全に停止させれば,電源の問題が解決すると支障なく再開することができます..ハードウェア障害コンピュータを構成する部品の中で故障が発生するのは,おもにハードディスク(HDD)です.これは常に高速で回転し,一般的に振動に弱く,正常に動くための温湿度条件も設定されています.HDDには,アプリケーションやデータが記録されているので,故障するとシステムは運転を続けられなくなります.以前に比べ,耐故障性が高まっていますが,それでも0にはなりません.万が一に備えてバックアップをとっておかなければなり(89)0910-1810/12/\100/頁/JCOPYませんが,バックアップは,できるだけ離れた場所に置く必要があります.それは,近くに置いておくと,地震,津波,火災,落雷などで一緒に使えなくなってしまうからです.東日本大震災の際の原発事故は,緊急炉心冷却用のバックアップ電源が同じ建屋にあり,大津波で一挙にやられてしまいましたが,同じ理屈です.当院では,本院と分院の両方に同じ環境をつくり,相互にバックアップするようにしています.さらに,CPUはじめ,すべての部品,機構を二重化して耐故障性を高めたFT(Faulttolerant)と呼ばれるサーバーを用い,可能な限り正常な稼働が続けられるよう考えています.ハードウェア障害対策で見逃しがちなことがありますが,それは予備機の扱いです.業務が止まってしまうクリティカルな機器の場合には,あらかじめ同じ機種を用意し,万が一に備えます.しかし,最近の機械は信頼性が高く,なかなか故障せず,予備機の出番がありません.出番がないまま置いておくと,ラベルプリンタなど,可動部分をもつ機器の場合,ローラ部分がくっついていて動かないという事態が起きる可能性があります.これはスペアタイヤを積んでいても,空気が少なくなっていて使えなかったということと似ています.予備機のまましまっておくのではなく,定期的に入れ替えて使うことを勧めます..ソフトウェア障害OS,データベース,通信などシステムのインフラとなるソフトウェア群に障害が発生すると,システムは止まります.もちろん,製品の性格上,十分な品質テスト*KazushiSugiura:宮田眼科病院CIO/技術士(情報工学部門)あたらしい眼科Vol.29,No.6,2012811医事会計検査外来図1現場スタッフによるテストをしてから出荷されるので,滅多なことではトラブルは発生しない信頼性をもっていることになっています.しかし,0にはなりません.リリースされたばかりの製品,新機能はできるだけ使わないというのが当院の方針ですが,それは机上ではテストしきれず,現場で使って初めて発生する不具合というものがあり,これらが吸収され,安定性が増すまで様子をみるということです.一般的に,バージョン3が無難だといわれます.バージョン1は品質が安定せず,機能が揃っていない,バージョンアップ2はそれらを吸収し,皆さんが使い込み,バージョン3で比較的安心して使える状態になり,バージョン4以降は,余分な機能がつき重たくなる.この評価は,今までの経験からも同感できる見方です.付和雷同にブームに迎合せず,ベンダ(システム開発会社)の甘言に乗らない,これもポイントではないかと思います..アプリケーション不具合これは,現場の業務と作業実態を,BPRしたうえで整理整頓し,どれだけシステムに反映できたかという仕様の完成度と,それを確実にプログラミングする技術,仕様通りに動作するかのテストに依存します.もの作りに起因する技術的なものはベンダに任せるしかありませんが,ユーザー(病院)側でも積極的に参加できるものがあります.仕様の作成,それにレビューとテストです.これをベンダ任せにせず自前で行うことにより,稼働中に起きる不具合が減り,システムが止まり,業務が止まる危険を減らすことができます.簡単にいえば,“このケースでは,この操作をしたら,こうなるはず”ということができているかどうかです.ベンダの技術者に業務の内容を伝え,彼らにやってもらう方法では,伝えきれなかったり,ベンダが理解しきれないことにより,不具合が作り込まれてしまうことを防ぐことができます.病院側スタッフがテストすれば,日頃処理してい812あたらしい眼科Vol.29,No.6,2012ることができるかをチェックするだけなので,比較的容易に,実務に即したチェックができます.ベンダには難しいことでしょう.当院には,2002年7月に稼働を始めた予約業務を主体とするリソースマネジメントシステムM-Magicがありますが,稼働以来,約10年間,ノーダウンを続けています.これは,現場のスタッフが,イレギュラーな場合も含め,稼働前に実際に使うシーンを想定して機能をチェックするなかで,品質を向上させたことが一因ではないかと考えています.現在開発中の院内総合電子化計画Hayabusaでも,もちろん,現場がテストし,品質と実用性を高めています(図1)..操作ミス本来,操作ミスによってシステムダウンになることは考えられないことです.仮にあるとすれば,それはテストの段階ではじかれているはずであり,万が一,操作ミスをしてもシステムダウンを引き起こすような仕様にはなっていないはずです.しかし,起きてしまうことがあります.簡単にいえば仕様の不備,テストの疎漏です.これを防ぐには,デザインレビュー,テスト方法のレビューが必須ですが,この工程を疎かにした開発をすると,その可能性が高くなります.Wordで文書を作り,“保存しなくてもいいですか”に対し,“はい”を応答してしまい,ファイルを失った経験をした方も多いと思います.メッセージの内容を確認せず,惰性でEnterキーを押してしまい,デフォルトになっている選択肢が選択され,その結果思わぬ事態になることがあります.デフォルトはフェールセーフ(できるだけ悪くならない選択)を基本としなければなりませんが,操作ミスによる思わぬ事態にならないかは,デザインレビューでたたき出しておかなければならないことです.(90)