Chaos to Cosmso トップペ−ジへ戻る
目次へ
１．液晶モニタ−比較報告
９万円台で購入できる液晶モニタ−が発売となった。
当院でも、医師の机上におくモニタ−はＸＧＡ規格１０２４×７６８がほしかったが、１７インチモニタ−では大きすぎて、医師の机上で場所をとりすぎるし、１５インチモニタ−ではＳＶＧＡ８００×６００でないと、フォントが小さくなりすぎて使い物にならないという現実であった。
それがパネルサイズ１４インチのＸＧＡ規格の液晶価格が一気に半額になったので、１２台ほど購入して、外来オ−ダリング用の医師のＰＣで活用している。
飯山電気ｉｉｙａｍａのＴＸＡ３６０１ＧＴとＭＥＬＣＯのＦＴＤ−ＸＴ１４Ｓ−ＡＴであるが、値段に差はなかったが購入してみて、だいぶ製品の「でき」がちがうことがわかった。
その比較をここに明らかにするので、みなさまも購入の参考にしてみてください。
まず大きさや重さには大差を感じませんので、だれでも一番気になる「液晶」そのものの比較から。
フルカラ−対応のｉｉｙａｍａは、かなりおとなしい液晶である。
この「おとなしさ」についてはＭＥＬＣＯと使い比べると明度・彩度でやや不満を感ずるかもしれないが、目に優しくて良いとする人もいる。
２６２１４４色対応のＭＥＬＣＯは、明度・彩度ともあざやかで、フルカラ−との差は感じられないし、若い人にはこちらの方がきれいだと評価されている。
インパクトがｉｉｙａｍａよりは強いだけに、あざやかすぎて目が疲れると明度・彩度を落として目への刺激を和らげて使用している医師もいる。
さて液晶の質であるが、ドット落ちはＭＥＬＣＯの液晶には２〜３ドット必ず存在するのに対してｉｉｙａｍａにはなかった。
このドット落ちについては、業務上は３ドット程度までならば支障はないが、プライペ−トでの使用ならば、気になる人もあるかもしれない。
組立では、どちらも信号ケ−ブルの取り付けがしにくい欠点がある。
電源は、ｉｉｙａｍａは本体に内蔵でスッキリしているが、ＭＥＬＣＯは外付け電源アダブタ−形式なのでかなりじゃまである。
使用していて、ＭＥＬＣＯでは液晶モニタ−のパワ−スイッチをＰＣ本体より後でいれると真っ暗な画面でなにも映らなくなることがあり、この場合は、一旦モニタ−電源を落として”コンセントを抜いて”再度モニタ−電源を接続すると液晶が点灯します。
しかし、チラつくのでＷ９５を終了し、再起動で正常にもどすということが２台の液晶で時々発生しています。
結論的には、つくりがていねいでおとなしいｉｉｙａｍａをえらぶのか、つくりはやや落ちるが鮮やかなＭＥＬＣＯか、あなたならどちらをチョイスしますか。
私だったら、プライペ−トはｉｉｙａｍａで業務用はＭＥＬＣＯかなと思いますが。
目次へ
２．注射と栄養の病棟オ−ダリングついに稼働
看護部がどうやったらその気になるのか、最大の山はそこにあった。
１９９８年１２月７日より病棟の注射と栄養のオ−ダリングが正式稼働となった。
注射のオ−ダ−の流れは、医師の注射オ−ダ−によりあらかじめ薬局が中心静脈注射無菌混注や注射薬を準備して出庫し、看護部は医師オ−ダ−と薬局からの薬剤を照合して注射をおこない、コンピュ−タ−に注射実施確認入力をおこなうことで、そのデ−タ−が医事会計レセプトデ−タ−となる一連の流れから組み立てられるシステムである。
医師は大量の注射伝票を書かなくてよい、看護婦は医師の書いた読めない注射伝票で業務をしなくてよいし伝票のカルテ貼り付けをしなくて良いから、カルテはスッキリするし作業もへるし、医事課は、注射実施のデ−タ−を取り込んで会計やレセプト処理おこなうから、正確な計算処理ができる。
こういったメリットいっぱいのシステムである。
ただし、これまでと違い看護婦には積極的なコンピユ−タ−操作が求められることになる。
Ｗ９５のシステムであっても、これまではコンピュ−タ−に触るのを大半の看護婦がさけていたので、メリットがあるらしいとは思えたようであるが、業務スタイルの変更となるので「コンピュ−タ−操作なんかできません」から「注射オ−ダ−システムはいやだ」という感覚が一般的であった。
そこで準備したのが「看護ワ−クシ−ト」である。
これは、入院患者一人一人についての医師の指示と看護度からその日の「食事」「服薬」「注射」「検査」「看護」「処置」などの指示がＡ４サイズ１枚にプリントされて、看護婦業務が遂行できるためのワ−クシ−トである。
こうすることで、カルテからの指示の拾い出し作業がなくなり、仕事内容がだれにとってもスッキリと理解できることとなる。
これは看護部に歓迎されたけれども、結論からいうと今回は見送りとなった。
理由は、処置の指示や実施のコンピユ−タ−入力について、医師と看護婦の業務区分け作業がまにあわなかったことや、検査オ−ダ−稼働を来月に延期したからである。
しかし、この「看護ワ−クシ−ト」検討作業をつうじて注射ワ−クシ−トのイメ−ジを看護部に理解してもらえたことで、注射オ−ダリング開始とすることができた。
同時に開始したのが「栄養オ−ダリング」である。
これは、入院の指示医が患者の食事内容を指示するわけであるが、実際には日常的に患者に接し食事がたべれているのかとかメニュ−への要望を聞くのは看護婦である。
従ってその情報を医師に伝え・判断をあおぎ・栄養科へ伝えると言う業務は、最も看護婦が適しているのでこれまでも看護婦が中心となっておこなっていた。
従って栄養オ−ダリングの入力業務は看護部がになうこととなる。
しかし、これによって看護婦さんは食事処方箋を記入して栄養科へ届ける（届けなければ患者さんの食事がでない）というバタバタした業務をなくすることができるメリットがあったし、栄養科も基礎的な食事デ−タ−がコンピユ−タ−入力されて楽になるし、医事課も栄養科での点検された食事情報を会計やレセプトデ−タ−として取り込むことができる（今までば、栄養科システムはスタンドアロンであったので、医事情報に取り込めなかった）というメリットがあった。
大所帯の看護部を相手にしての準備であったので、稼働までに６ケ月もかかってしまった。
話がすすんでいるのか、看護部内部での準備がされるのだろうか････と雲をつかむような努力（話ではありません）をかさねて、しんぼうづよくじわりじわりと押し上げました。
もっとも医師の一部にも「注射オ−ダ−」は業務をしんどくさせることになるのではないかという懸念もあり、正式稼働１月前の１週間にある病棟で注射オ−ダリングを試験稼働して医師と看護部に実際の業務がどうなのかを体験してもらい、「これならできる」と安心してもらいましたが。
もっか医師にも「同一患者へのほぼ同一内容の注射伝票書きのたいへんな労働がなくなって楽になった」「注射方法や順番についても正確に看護婦に指示できるようになって便利だ」と好評です。
但し、注射実施確認の入力処理がキチンとできない看護婦もまだいるので、婦長にとって指導はたいへんなようである。
画面で一覧表の該当する部分にクリック一発で確認入力ができる様にアプリケ−ションを工夫してあるのに、そのクリックを後回しにして結局入力処理をせずに忘れてしまったり「注射はちゃんとしてあるのだから」と「コンピュ−タ−への入力は余計な仕事」と、どうも感覚的にきらっている雰囲気がある。
「実施確認入力を実施者がきちんとおこなわないということは、注射実施の責任をとろうとしないことで、注射薬を道路に投げ捨ててきたと同じことなのだ」というような本質的理解がピンとこないようである。
ともあれこうした部分的な困難も、順次克服されつつあるので、来月からの検体検査の病棟オ−ダリングもほぼスム−スに稼働できる見通しがでた。
目次へ
３．アプリケ−ションのバ−ジョンアップがだんだん困難になりつつある
当院のシステムは、ドメインサ−バ−機にアプリケ−ションサ−バ−機能ももたせてある。
このため、アプリケ−ションの実行は、クライアントがアプリケ−ション・プログラムをサ−バ−から読み込み、クライアントで実行し、ファイルサ−バ−に必要なデ−タ−を要求して処理が進められる方式である。
この方式の優れている点は、アプリケ−ションの管理が極めて簡単であり、バ−ジョンアップは、アプリケ−ションサ−バ−の該当するアプリケ−ションファイルを更新するだけで良いことである。
ただし、該当するアプリケ−ションがどのクライアントでも実行されていない場合にしか更新できない、という条件があります。
想定している全体のシステムがかなり稼働してきているので、通常の時間帯は全クライアント合計で１２００本以上のアプリケ−ション・タスクが走っている現状となってきた。
今後は検査オ−ダ−関係も稼働する予定なので、さらに増えるであろう。
深夜でも病棟関係の業務に関するアプリケ−ションは使用されるので、２００本以上が走っている。
この「走っている」内容には、実際にクライアントで入出力の処理がされている場合とタスクバ−に待避されている場合が含まれる。
この結果、サ−バ−でアプリケ−ションの更新をおこなおうとしても、どこかのクライアントで現在のバ−ジョンが走っていると「共有違反」の警告が出て、更新ができないこととなる。
よく使われるアプリケ−ションほど、よくバ−ジョンアップが必要となるが、ほぼ常時走っているため更新するタイミングがより困難となる。
更新タイミングは、土曜日・日曜日の２２時から早朝６時頃までが最も条件が良くなる。
しかし、そんなタイミングでしかできないわけではなくて、実際は深夜の時間帯で使用頻度が落ちているであろうと考えられる時間帯に、もしクライアントで走っていた場合にはサ−バ−からそのタスクを強制停止させ「共有違反」にならないようにして、現行バ−ジョンは名称変更して残し、バ−ジョンアップの新ファイルをサ−バ−に設定するという作業をおこなっている。
作業手順は、サ−バ−で現在どのクライアントでどのアプリケ−ションが使用されているかウインドウに表示させる機能を使って、クライアント順にスクロ−ルしながら目でファイルを探すこととなる。
Ｗｉｎｄｏｗｓ−ＮＴではこの場合の作業ウィンドウの広さが決められていて、ナント一度にわずか７行！！しか表示されないから、スクロ−ルしながら探すのはなかなかシンドイ作業である。（悲しいことに、ファイル名順にソ−トして表示する機能さえもないのです(;~-~;)。 ）
で更新したいファイルが見つかったら、そのファイル行をクリックして、強制終了させるわけである。（このとき実際にデ−タ−処理中なのかタスクに待避されているのか、本当ならば該当クライアントの部署に電話連絡で確認して作業をするのが望ましいだろうとは思うが、そんな悠長なことはできない。
そんなことしていると別の部署のクライアントでそのアプリケ−ションを使用開始してしまう。
あらかじめバ−ジョンアップ作業をすることを連絡してあっても、現場が必要で使うときには使うであって、そのままになっている場合が大半で効果ない。）
こうして、その時生きている全クライアントについて探索と発見とタスクの強制終了をおこない、続いて現行フアイルの名称変更と新ファイルの設定でバ−ジョンアップ処理は完了する。
この作業がだんだんと困難な作業になりつつあるので、せめて探索の表示ウィンドウを４倍程度には広げてほしいし、ファイル名でのソ−トができる機能はぜひとも欲しい。
どなたか、こんなユ−ティリティご存じないでしょうか。
追伸 現行ファイルを名称変更で残しておくのは、バ−ジョンアップファイルが実際の業務で使われた場合に欠陥あるアプリケ−ションファイルであることが初めて判明する場合がまれにあるからです。
実際、過去には、前夜バ−ジョンアップした医師オ−ダリングシステムアプリケ−ションが、翌朝の内科ではまともに稼働するのにそれ以外の外来の科では動かない、という事件も発生し、サ−バ−から全クライアントの全アプリケ−ションを一発で強制停止させ、バ−ジョンアップ前のアプリケ−ションに戻して、全クライアントの再起動によって外来診療業務を５分で復旧という荒っぽい事件などもありましたので。（こうしたような心臓に悪い事件はまま発生するもので、私のノミの心臓はいつまでもつのか不安でしかたありません。）
目次へ
４．ＲＡＩＤのハ−ドドライブ１台が不調となるもコンパック社は休みとは
１９９９年２月６日（土）午後５時過ぎ、サ−バ−室でクエリ−処理中のクライアントが突然フリ−ズしてしまった。
「そんなバカな」と、ふとサ−バ−を振り返ってみると、ＲＡＩＤ装置にオレンジのエラ−警告ランプが点灯していた。
プロライアント５０００につないでいる２台のＲＡＩＤ装置のうち、１台の上から２段目のハ−ドディスクにエラ−が発生していた。
「アチャ−、ハ−ドドライブのクラッシュか」と、予備の新品に交換（ホットプラグなので作動中の差し換えができる）したところ、全部のドライブのブル−のアクセスランプがしばらく（３０秒ほど）点灯して、差し替えした新品にオレンジランプが再び点灯。
ゲゲゲ！である。
ＲＡＩＤ５の設定なので、１２台のハ−ドディスクドライブの１台が故障しても、システムダウンにはならず、たまたまそのドライブにアクセスしていたクライアントにフリ−ズが発生する程度の障害なので心配ないが、昨年秋にも１台が故障して、予備に差し替えて事なきを得ていたのに、今回は、新品に差し替えたのにエラ−がなおらないではないか。
故障の原因は、差し替えた新品のドライブも故障していたのか、ハ−ドドライブ不調ではなくて、本体のドライブベイ部分が不調なのかのどちらかであろう。
病院システムは、土日関係なく２４時間稼働させているシステムなので、一刻を争って大至急修理せねばならないからコンパックサポ−トセンタ−へ電話した。
なんたることか「土日と休みだから、月に電話せよ」とアナウンスが流れるのみである。
「あのねえ、コンパックさん、サ−バ−の不調があっても土日はサポ−トサ−ビスお休みです、とは･････顧客のシステムのサ−バ−不調への対応がそんなんでは、安心してコンパックをサ−バ−には使えないではないか。」
・・・・・・とすると、私にできることは「もうこれ以上のハ−ドディスクドライブ不調が発生しません様に」と八百万の神々に、当院のサ−バ−システムの背後霊に、アラ−の神にキリストに如来に、苦しいときの神頼みをして、「もう１台クラッシュしたらそれまでよ」とあきらめの悟りの境地になるしかない。
８日（月）にコンパックに連絡とって、本格的な対策はそれからだ。
ということで、８日コンパックのサポ−トセンタ−に電話をいれた。
前回は、コンパックサポ−トセンタ−から地元のサポ−ト会社に連絡があって、保証書のコピ−をＦＡＸでコンパックに送ったりしたのであるが、今回は直接こちらから地元のサポ−ト会社に連絡してくれとのこと。
レスキュ−サポ−トの方法が変更になっていたようだ。
とにかく、文句をいっているヒマはないので、前回サポ−トしてくれた会社ＰＦ＊に電話をいれる。
で「ハ−ドディスクドライブが２台とも故障だろうということで、コンパックに連絡し、あわせて最悪の場合はＲＡＩＤのベイ部分の故障も考えられるので、それも対処できるようにする」ということになった。
ところがコンパックから交換修理用の機器が到着するのが１０日の予定との連絡。
おいおいコンパックさんよ、サ−バ−の故障なのに、故障発生後５日たたないとレスキュ−できないというのではサポ−トにならんではないか。
故障発生を想定してＲＡＩＤ５に設定しておいたからシステムダウンになっていないだけで、もしそうしてなかったら５日間もシステムダウンとなってしまうではないか。
「朝に故障発生したらその日の夕方にはサポ−トが完了する」というのでなかったらサ−バ−のサポ−トとは言えないと思うが、アメリカで発生した場合でも５日もかかっているのかい。
・・・・・ということで１０日にひきつづきこの顛末をレポ−トする予定であったけれども９日朝に交換のハ−ドディスクがＰＦ＊についたとのことで、昼から対処。
新品のディスクをベイに差し込むと、なんのことはない正常に作動開始で、稼働しながらバリティ情報によりデ−タ−の復旧が自動的におこなわれ完全復旧。
なんたるこっちゃ、予備にコンパックより購入してあった新品のＩＢ＊製のデスクドライブも故障していたという結論であった。
もちろん１台の新品の予備も交換して残してありますので、次回にＲＡＩＤのドライブが不調となったら、直ちに差し替えて復旧できるようにしておきました。
ということで、ひやひやの４日間であったけれど「今日からは安心して統計などのドライブに負荷のかかる処理も再開できるわい、諸々の守護神様ありがとうございました」と、一段落。
なお、この間ＮＥ＊やＦＵＪ＊やＨ＊やＤＥＬ＊などの各社のホ−ムペ−ジを覗いて、サ−バ−の保守についての調査をおこなってみましたが、保守内容について期間や価格も含めきちんと明記してあったのはコンパックのみであったことも皆様に報告しておきます。
追伸 ＮＥ＊は、保守のペ−ジのリンクがバグッていたので、メ−ル入れたところバグフィクスのメ−ルがきた。 再度保守のペ−ジを参照して、５８０＊シリ−ズの保守についての内容は一定わかったが、保証期間や無償修理期間などがわからない。
目次へ
５．ＮＥＣ９８２１ノ−トＰＣのＷ９５再インスト−ルができない原因はＮＥＣ純正の再インスト−ルディスクにバグがあったため
医師オ−ダ−用のノ−トＰＣのうち４台がＷ９５に不具合が発生して役をしなくなった。
しかたないのでＷ９５の再インスト−ルを試みたのにうまくいかないのである。
これまでデスクトップはＮＥＣ・メルコ・東芝・富士通・ツ−トップ・フリ−ジア・プロサイド数々の再インスト−ルもしたし、ＤＯＳＶノ−トの再インスト−ルもしてきたので、軽い気持ちでＮＥＣノ−トＰＣの再インスト−ルにとりかかった。
機種は９８２１ＳＲ１３／Ｎ１４というＣＤＲＯＭのないタイプである。
それで９８用のフロッピ−版のＷ９５を新たに購入して、鼻歌まじりでインスト−ル。
ところがである、セットアップ完了しても８００Ｘ６００の液晶の画面が６００Ｘ４８０でしか作動しないのである。
つまり液晶のドライバ−とそのセットアップウイザ−ドのファイルが添付されていないので、８００Ｘ６００に切り替えられないのである。
まともに動いているノ−トＰＣからドライバ−ファイルを探して、再セットアップ中のノ−トＰＣのＷＩＮ９５￥ＳＹＳＴＥＭデイレクトリにコピ−しても全く機能しない（そりゃそうだろうとは思ったが、万一とかすかな期待はあったのですが）。
ＮＥＣのインフォメ−ションセンタ−と交渉して液晶のドライバ−をダウンロ−ドさせてもらおうとしたが、ドライバ−は公開しないとつれない返事。
ああ、ただこれだけのことなのに、これまで再セットアップをおこなった全てのＰＣにはモニタ−のドライバ−かグラフィックアクセラレ−タ−のドライバ−が必ず添付されていたのにＮＥＣだけは添付もしなければダウンロ−ドもさせないとはどういうこっちゃ。
もうあんたんとこのノ−トＰＣは買わんからな・・・・・。
ということでフロッピ−版からの再インスト−ルをあきらめた。
しかたなく、付属品のシステム再インスト−ルディスクとバックアップＣＤを使って作業する方針に切り替えて、純正のオプションＣＤＲＯＭ（現在セットされているフロッピ−ドライブを抜いて、代わりに挿入するタイプ）と外付けフロッピ−ドライブをやくやく購入。
さて、おもむろに再インスト−ルディスクで作業開始。
ＣＤＲＯＭも認識し、フォ−マットも約１０分ほどかけておこなわれ、システム転送の一部がおこなわれ順調だわいと思っていた矢先。
ところがである、バックアップＣＤを入れよというのでセットし「ＯＫ」をしても全く反応なく、ここから先へどうしてもすすまない。
まさかＣＤＲＯＭ装置故障かと、まともに動くノ−トＰＣにつけてみると、バッチリ作動する。
とすると再インスト−ルディスクのプログラムバグだろうか、目下ここで苦闘中である。
ということで、ＮＥＣのカスタマ−サポ−ト岡山店へ持ち込みとなった。
やったことは私と全く同じ。
最初からノ−トＰＣに添付のシステム再インスト−ルディスクでやって、私と同じところでストップとなる。
念のため、純正の再インスト−ルディスクを購入してやってみて、やっぱり同じところでストップとなった、その純正のディスクでやって、やっぱりだめ。
くびをひねって不審がっていた担当者は、奥から「これは、うちで再インスト−ルに使用しているディスクです」と持ち出してきて、再度試行。
あれ、こんどは停止することなく、バックアップＣＤＲＯＭから再インスト−ルが実施となった。
ということで、結論「ＮＥＣ純正の添付の再インスト−ルディスクも、念のため購入した再インスト−ルディスクもプログラムにバグがあった」ということとなった。
ファイルを少し調べてみたら、バッチ内容に違いがあるのと、ファイルにも過不足がある。
まさかではあるが、大メ−カ−でも、こんなバグのある製品をチェックできずに販売していたとは、全国には再インスト−ルできずに販売店などに持ち込んで有償でインスト−ルしてもらった方が大勢いたのではないだろうか。
ということで、問題解決であるが、しかし本質的には、再インスト−ルディスクがないとＷ９５の入れ直しができないようにしてしまったＮＥＣの政策にこそ問題がある。
初期のＮＥＣのＷ９５ディスクではＯＥＭＳＥＴＵＰコマンドでＣＤＲＯＭから再インスト−ルができたのに、版権問題がらみとはいえ、このコマンドを削除してしまったＮＥＣの政策には納得ができない。
目次へ
６．日経オ−プンシステム1999年3月号に登場
なにせ、あの日経ＢＰ社の雑誌に４ペ−ジわたって登場したのだから、これは自慢話をしてもお許しいただけるでありましょう。
無謀なことにもＳＥでもないし、まして組織のトップでもない私が中心になって、クライアント／サ−バ−型の医師オ−ダリングシステム方式を選定して、システムプロデュ−スをおこなってきたこと、しかも１９９７年というＯＳでもＷ９５がリリ−スされたばかりの時期に、どんな見通しと決断のもとで取り組めたのか、記者の方はそこに一番興味をもったようでした。
１９９３年頃には「ネットウェアとパソコンラン」などという本が書店にならびだし、１９９５年頃には「ウインドウズＮＴとクライアント／サ−バ−型システム」などというアメリカの事例や日本の先進例がぼつぼつ紹介されだした時期に、それこそ目に留まる文献を探しまくり「やっぱりこれしかない」と選んだわけです。
ＭＳＤＯＳ上のｉｎｆｏｒｍｉｘ v3.3で病院の業務アプリケ−ションのいくつかを組んで身につけたデ−タ−ベ−スの考え方とアメリカのソフトウエア技術の能力のすごさがわかったこと、それがあったから１９９６年には決断ができたわけです。
元気が良かったのはそこまで、以下は愚痴ぽい話です。
実際そのあとの１年間は、某大手ソフト屋からの様々な逆流圧力・わずらわしい諸々の風聞による足踏みｅｔｃｅｔｃがあって、不安にゆれる管理部を説得して、どうにかこうにか忍の一字でＧＯまでもちあげたわけです。
管理部も不安で「もし動かなくても、最悪で医事システムだけでも動くならばよしとするか」というような悲壮な決断をしたらしい。
ま、それほど信用されていなかったというわけである。
であるからして「横暴」と言われないように「最小限費用で最大効果を」とかなり「萎縮して首も洗いつつ」着手してきた。
「もう少し金をかけれたら業務ストレスがほとんどなくアプリケ−ションが走るだろうな−」と思いつつも、ガマン・ガマンでやってきた。
画像のことも考えてＬＡＮは全て１００ＢＡＳＥで配線したかったけれど、クライアントへは１０ＢＡＳＥにとレベルを落とした。
クライアントのＣＰＵはＰ２００程度はほしかったのにＰ１３３であきらめた。
ＲＡＭも６４Ｍ程度はと思ったが、３２Ｍであきらめた。
クライアントのＨＤは２Ｇほしかったけれど１．２Ｇであきらめた。
今となっては、どうしようもなくて、安物買いのゼニ失いだったなと思うこともあるわけです。
貧乏性が身について、未だに萎縮しての考え方からぬけだせない。
「こんなに医療情勢きびしいから、コンピュ−タ−にはこれ以上金をかけれんな−」と業務アプリの増大とクライアントＰＣの能力不足の矛盾につらい毎日である。
よ−し、あと３年して設備更新時には思い切って、本当に思いきったシステム能力改善のできるＯＳやハ−ド設備更新をしよう、と････今から自分にネジを巻いている。
目次へ
７．２０００年閏年対応安全確認試験を実施 問題なくシステムが稼働することを確認
去る６月１９日（土）に、オ−ダリングシステムの２０００年対応試験をおこなった。
試験には、医事課・医局・検査室・薬局・放射線科・看護部（病棟）・栄養科が参加し、確実にシステムが稼働することを認証する試験を実施した。
午後２時に通常のシステム稼働を全て停止し、サ−バ−のカレンダ−を２０００年２月２９日（閏年なので、２月２９日試験も絶対必要です。）に設定して再起動させ、続いて再起動させたクライアントＰＣのカレンダ−日付が２０００年２月２９日に自動的に設定変更となっていることを確認した。
当院のシステムでは、クライアントＰＣは起動時にサ−バ−のカレンダ−のデ−タ−に設定されるようにバッチを組み込んである。
また、システムに接続されている自動分析装置などの検査機器、カルテ庫システムや放射線科のＦＣＲ装置などのコンピュ−タ−カレンダ−は手動で同日に設定して試験をした。
医事課でのダミ−患者の登録・カルテ庫システムの作動確認ののち、医師がダミ−オ−ダ−入力をおこない、処方箋が薬局で発行されること、医事会計ではオ−ダ−取り込みで計算ができることなど外来関係システムの稼働を確認しました。
また放射線科では、同患者の撮影デ−タ−がＦＣＲ装置に送られ作動すること、検査室ではダミ−検体を検査機器で分析し、結果がきちんと処理され本システムに転送されることも確認した。
病棟も同患者を入院登録し、栄養のオ−ダ−が栄養科に食事箋として発行されることを確認した。
全ての予定されていた試験が無事に実施されたあとで、試験患者で発生したデ−タ−を削除し、サ−バ−を１９９９年６月１９日のカレンダ−設定に戻して再起動させ、午後４時通常稼働状態になったことを確認し、当初目的を達成して安全確認試験を終わった。
こう記録すると、淡々と平穏に進められた様にみえるかもしれませんが、実はヒヤリとする場面があった。
サ−バ−のＷＩＮＤＯＷＳＮＴ３.５１でカレンダ−を２０００年に変更しようとしたとき、年の設定画面の窓は[９９]と表示されていることに 初めて気がついて、ショック！(･･;) (*_*) 、ギョギョギョであった。
とりあえずトルグスイッチの▲マ−クをクリックして年表示を[００] にする。
これで２０００年になっているはず････、まさか１９００年ではなかろう････、でももし１９００年だったらどうしよう････、と顔を見合わせながら再起動。
ＤＯＳ窓を開いて、ＤＡＴＥコマンド････ヤッタネ！ ＼(^o^)／ ２０００年になっている。＼(^o^)／
というヒヤヒヤもの もありました。
ともあれ「２０００年２月２９日での試験をおこなっても、試験後の日常業務に支障無く稼働できるのか」だいぶ考えて、ほぼ大丈夫と思えたから試験をおこないましたが、汎用機のシステムだったら、こんな試験は後始末が怖くてとてもできないでしょうね。
あちこち病院をあたってみたが、２０００年試験は実施したことにしておいて、なにかおきても１月１日は病院休みだから、正月休み中にどうにかしよう、というところばかりでした。
厚生省さん、こんな試験を真面目にやったのは、うち以外にどこかあるのでしょうか。
目次へ
８．マイクロソフト２０００年対応ＮＴ用パッチあてたら、リアルタイム・デ−タ−・デュプリケ−トは無理となる
バックアップの一番確実な手段としてデ−タ−のリアルタイム・デュプリケ−ト処理をおこなっていたが、サ−バ−に２０００年対応とのパッチをあてたとたん、処理が重くなるわ・リアルタイムどころかだんだんタイムラグが大きくなり１ケ月後には、７日以上もバックアップ未了期間が拡大するわで、全体のレスポンスも低下するしで、ついにデ−タ−・リアルタイム・デュプリケ−ト処理を中止とせざるをえなかった。
調子が良い時には、たとえマイクロソフト推奨といえど、パッチなど当てない方が良いということが教訓である。
また、パフォ−マンス・モニタ−での監視では、このパッチを当てたことで、突然ＲＡＩＤへの書き込みがほぼ４秒毎に櫛の歯状におこなわれだした。
初めてこの現象をモニタリングしたときは、何が始まったのかとビックリして、冷や汗が流れた。
こんな調子で書き込みされたら、そのうちＲＡＩＤから溢れてしまうと思ったわけですが、どうもログかＮＴの内部処理バックアップらしくて、デ−タ−ファイルの浪費は観察できなかったのでやれやれ一安心しました。
マイクロソフトからは、こんな現象が発生するというアナウンスは全くなかった。
プン !(ｰﾑｰ)! プン !(ｰﾑｰ)! プン !(ｰﾑｰ)!
しかし、この書き込み処理はレスポンス・アクティブで、全体的なサ−バ−への負荷がかかると書き込まれなくなったり、クライアントからのアクセスが無くなると書き込まれなくなることがわかったので、サ−バ−の状況判断にも利用できる。
リアルタイム・デュプリケ−トが意味をなさないと解って、どうしようかなと検討中にバックアップ用ＤＡＴ装置が１台故障となった。
ということで、圧縮２４Ｇ対応のＤＡＴ装置（ＤＤＳ３規格）に交換して、デュプリケ−ト処理は停止させ、毎日デ−タ−のバックアップをＤＡＴでおこなうこととした。
現在９Ｇ程度のバックアップに約２時間半程かかるが、深夜にタイマ−設定で処理している。
一度間違えて、午前中の外来診療中にバックアップモ−ドとなったが、約２時間は気持レスポンスが落ちたかなというくらいで、気がつかなかった。
ところが残り３０分の部分になったとたんにレスポンスがほとんど返ってこない状態となって外来診療が事実上ストップとなり、大騒ぎとなってしまった。(･･;)
バックアップモ−ドを解除して正常化したわけですが、いろいろ起きますね−−−。
その後は、とりあえず、ここ３月間は、快調である。
と報告しておきましたが、１１月１０日過ぎてから、医事会計でオ−ダ−取り込みに引っ掛かる例が極まれに発生しだした。
レスポンスが１分程度返ってこない現象である。
で２０日には３０分に１例程度の頻度で発生しだした。
とりあえず、ＳＱＬサ−バ−を深夜に再立ち上げしてみた。（問題はｉｎｄｅｘだろうが、ひょっとすると、ず−と無停止であったから、ガベ−シかメモリ−リ−クでもあるかな・もしそうなら、再立ち上げで解決するはず。）
やはり、解決せずで、半年以上おこなってなかったＩＮＤＥＸの再構築処理を近日中に実施することを決断した。
これで解決するはずであるので、結果は後ほど報告します。
こうご期待。
としていましたが、ＩＮＤＥＸの再構築でも効果がでなかった。
業務内容からいうと、指導料のチェックでそこだけベタ読みでＩＮＤＥＸが利かない現象と思われる。
この人は引っ掛かるぞとあらかじめ予測できるので、業務の流れには不都合であるが、とりあえずパニックにはならずにすんでいる。
とはいえ、どうにかせんといかんので、トレ−スログをはきだすトラップをプログラムに組み込んで、どこでどれだけ引っ掛かるか調査する方向で検討することとする。
かつてこの方法でクエリ−の不備（バグ）を発見できたこともあったので。
その他、ＮＴの古いログを削除してみたところ、全体としての調子は極めて良くなって、パフォ−マンスモニタ−でも、数秒毎のレイドへのログ書き込みと思われていた、櫛の歯状の書き込みが全くなくなった。
皆さん、あの櫛の歯状の書き込みがパフォ−マンスモニタ−に現れたら、ログの貯まりすぎで負荷が発生していると判断してまちがいありませんよ。
これも、ノウハウですね。
などとしていたら、新しいプログラムの入れ替えで、医師オ−ダリングと医事会計は動くのに、その他ほとんどの業務が停止してしまう現象が発生。(*_*;) (*_*;)
ＳＱＬサ−バ−のエンタ−プライズマネ−ジャ−で観たところ、広範囲にロックがかかってしまっていた。
これも午前中の外来診療中に発生したので、少し冷や汗をかきましたが、ロックをかけているプログラムを停止させて、とりあえずは回復。（少々のことでは、動揺しなくなって、だんだんふてぶてしくなりつつあります−−−−）
原因は、以前から使用中のプログラムのバグで、それを修正してもらって、やれやれとなった。
てなこといっていたら、１２月２２日の夜９時家に電話あり。
「システムが今不調です。」 ！！(@_@)！！ 「ナヌ−」である。
レスキュ−要員が１名残業していたので、彼からの報告で、サ−バ−が停止し、クラスタリングが作動してバックアップサ−バ−に切り替わっていることがわかり、やれやれ。
とりあえず、病棟関係などまだ業務中の部署に「クライアントの業務システムが不調になったら、そのＰＣを再起動してもらう」ように指示をして、病院へ向かうこととした。
サ−バ−を観たら、電源が切れている。
電源スイッチを再度ＯＮしても、一瞬電源ランプが光るだけで、なにもおこらない。
ということで、これは多分電源周りのハ−ドウエア故障と判断。
コンパック・サポ−トセンタ−に電話したが「業務は終了している」とのテ−プが流れるのみ。
「ヤッパリ」と思いつつＰＦＵサポ−トに電話する。
電話は転送され、大阪のＰＦＵ当番の方に連絡つく、やれやれであるが、これまでのサポ−トを受けた経験から、ＰＦＵは推薦できますね。
２３日は旗日なので２４日に視てもらい「電源部の故障」ということで、最終的には２７日（月）に電源部取り替え修理となり、完全復旧した。
今回は、クラスタリングが極めて有効に働いて、バックアップに切り替わり、こちらの要員もこれまでの経験から落ち着いて状況判断ができて、しかも夜間で診療が終わっていたこともあり、混乱が発生せずに一件落着。
目次へ
９．Ｙ２Ｋ事件ついに発生・ｍｙ_ＰＣがＹ２Ｋでダウン・付録のＷ２０００は鬼門だった
ということをしながら、Ｙ２Ｋをむかえ、当院も院長以下約２０名の役職者が危機管理本部体制で泊まり込み、２０００年を迎えた。
当院では、すでに６月に２０００年２月２９日のタイム設定でシステム稼働試験をおこなって問題発生の無いことを確認していたし、医師のオ−ダ−関係や診療検査関係の予約は１２月には、２０００年１月の日時で処理がどんどんおこなわれ、なにも問題発生はしていなかったから、個人的には泊まり込み体性など組むのはかったるいと思いましたが、厚生省の方針で１日の午前３時過ぎまで呼吸装置などの医療機器とＰＣシステムの安全確認にあたりました。
結果は、１台の検体検査の機械のタイムスタンプが「１９９９年１２月３２日」となり、ウッソ−！・なにそれ？であったが、簡単に１月１日に訂正して一件落着であった。
ところがである、我が家のＰＣシステムはＹ２Ｋ問題が発生し、すべてのデ−タ−を含むシステムが作動しなくなったり消えてしまったりで、やっと今日２月３日にホ−ムペ−ジへのアップロ−ドができるところまで回復した。
年末年始の休みで、こどもにせがまれて、本の付録のゲ−ムをインスト−ルしたのがＹ２Ｋ問題の出発点。
ゲ−ムのあとからシステムが不安定になって、レジストリ−エラ−がだんだん拡大し、インタ−ネットへの接続が１０回のうち１回程度しか成功しない事態になってしまった。
それで、どうしようかと考え、よい機会だから日経バイト付録のＷ２０００をインスト−ルしてやろうと思ったのが、破滅への道であった。
従来からのＷ９５と共存するようにインスト−ルしたまでは良かったが、ついＮＴＦＳをシステムドライブのファットにえらんでしまった。
しかし、Ｗ２０００が私の周辺機器を認識してくれない（ドライバ−がない）ので、今は使い物にならないと判断して、ＯＳをＷ９８に変更することにした。
ではＷ２０００をインスト−ルしたハ−ドディスクをフォ−マットして・・・・と、フォ−マットできない！！！！・・・「アロケ−ションテ−ブルを修復しようとしています」と表示しカウンタ−が１秒に１ステップアップする・・・・・そのまま３日間放置してどうにかなるかとやらせてみたが、あきらめた。
結局Ｗ２０００システムをいれていたハ−ドディスクが死んでしまった。（Ｗ９８では使えなくなってしまった。）
別のハ−ドディスクを購入追加して、それにＷ９８をインスト−ルした。
ところがなんと、デ−タ−専用にしていたハ−ドディスクのデ−タ−（イタリア環境調査・ロシア旅行・韓国交流訪問・石垣島リゾ−ト・一昼夜かけて撮影した備中神楽、等々のデジカメ画像、それに私のインタ−ネットホ−ムペ−ジファイル等々）が、最初のパ−ティションのデ−タ−以外すべて見えなくなってしまった。
いろいろやってみたが、泣く泣くすべてのハ−ドディスクのフォ−マットをせざるをえなかった。
結局再度システムハ−ドディスクにＷ２０００を再インスト−ルして（９８とのＷブ−トにして）、Ｗ２０００のインスト−ルによってＷ９８で使えなくなったハ−ドディスクは、Ｗ２０００のディスク管理システムでフォ−マットして、Ｗ２０００専用としてのみの使い方とせざるををえなかった。（５１２バイトのファイルアロケ−ションを選ぶと、Ｗ９８でも認識するが不安定でしばしばスキャンディスクが起動し、テ−ブルの末尾に異状状態があると表示してベタ読みチェックのクラスタスキャンになったりするので、Ｗ９８で使用することはあきらめた。)
このさわぎで自分のインタ−ネットのパスワ−ドも消えてしまい、再発行の憂き目にあってしまった。
こうして、ｍｙ_ＰＣに発生したＹ２Ｋ問題は破滅的結果をたどり、１ケ月の経過でやっとホ−ムペ−ジアクセスが可能なところまで回復してきた。
以上の経過よりの教訓。
本の付録のゲ−ムはインスト−ルしてはならない、Ｗ２０００もあわてて飛びつくな、先達が苦労して、こうしたら安全だからもういいよと教えてくれてからインスト−ルするのが王道であろう。
目次へ
１０．検体検査オ−ダリング
さて、その後の報告である。 ２０００年２月２９日は、なにもしなかったし、なにもおきなかった。
この日付での試験は既におこなっていたから、全く心配はしていなかった。
しかし、全国各地の原発では、Ｙ２Ｋと同じ様に制御棒の表示が消えたままで６時間も運転を続けたとか、危険きわまりない事件が発生していた。
これは例えるならば、ジェット旅客機の操縦席のレ−ダ−が表示しないまま６時間も飛行していたのと同じ野蛮無謀な事態である。
旅客機ならば、直ちに最寄りの飛行場に緊急着陸するであろう。
原発を直ちに緊急停止しなかったのは、安全神話どころか、企業利益・国家政策のために日本国民の生命を平然と犠牲にしてはばからないことを世界に宣言したことであり、野蛮の極みと私は思います。
病院では、検体検査の医師オ−ダリングの準備がすすめられた。
これは、医師が指示を入力するとリアルタイムに、あるいは指定の日にラベルプリンタ−からスピッツ用検体ラベルが出力され、検体が検査室に届いた時点でオ−ダ−実施の確認がされ医事課への請求デ−タ−が発生するシステムである。
メニュ−関係は、検査室・医事課・医局の協力で作成し、ラベルプリンタ−は検査室が必要部署に設置してあるいた。
ところが、ＰＣの機種によってはシリアルポ−トがあってもＣＯＭ１、ＣＯＭ２の両ポ−トがそろっていない機種があった。
ＣＯＭ２ポ−トからラベルプリンタ−に接続するようにプログラムしてあったから、設置にまわって「ありゃ、ここには設置できないや」というようなドジなこともあった。
しかたないのでプログラムオプションでポ−ト選択をできるように急遽修正して予定日通りの稼働となった。
やれやれであるが、まだ生理検査や画像検査のオ−ダリングをどうするのか問題が残っている。
医師オ−ダリングを拡張してきて、コンピュ−タ−が得意な医師は仕事が楽になってもっとオ−ダリング方式を拡大してほしいと要望がでるが、苦手の医師は疲れる・楽になっていないと抵抗感がでている。
コマンド入力ではないし、基本的にはメニュ−クリック選択方式でオ−ダ−できるようにシステム開発がされていても、苦手の医師にとっては生理的に苦手感があって、克服はむつかしい。
今後さらに医師オ−ダリングをどうするかのバランス判断が難しい局面になってきた。
目次へ
１１．ネットワ−クのエラ−事件多発
この間、一度病院電気配線のショ−トによる瞬断でのシステム不調を経験した。
「突然医事会計関係が停止してエラ−となって動かない。サ−バ−が止まったのか」と連絡を受けた。
自分の部署のシステムは全く正常で、ネットワ−ククライアントも正常に表示される。
とりあえずサ−バ−室へかけつけパフォ−マンスモニタ−画面をみたが、全く正常である。
ＳＱＬサ−バ−のエンタ−プライズマネ−ジャ−も正常作動を表示した。
ということで「サ−バ−はまともに作動しているのに変だな」と医事課に電話を入れて状況報告うけると「会計まわりだけエラ−がおきていて、まともに作動しているＰＣもある」とのこと。
「アチャ−、医事課に接続しているハブの故障か」と故障ハブの特定にでかけようとしたとき、サ−バ−室の電話が鳴った。
「え、まさか故障範囲の拡大ではあるまいな−」と思いつつ電話をとるとある病棟から「さっき一瞬停電してからＰＣが動きません。」との報告。
この連絡をもらった瞬間、思わず「バンザイ助かった」と喜んでしまった。
念のため施設係に確認の電話をすると「ナ−スコ−ルシステム更新工事で、電気配線のショ−トをおこしてしまって瞬断が院内の一部で発生した。」とのこと。
瞬断配線に含まれる薬局に電話して、処方箋システムが正常に稼働しているか聴いたところ「さっき瞬断でシステム停止したので、ＰＣ再起動して今は正常に作動している。」との報告。
早速、医事課に電話「ナ−スコ−ル工事のミスで、電源ショ−トによる瞬断が発生したため、会計システムにエラ−が発生したと考えられる。直ちに該当するＰＣを再起動して下さい。」と連絡して一見落着。
教訓、停電や瞬断は病院全体でおこる場合ばかりではない、院内の一部の電源配線での瞬断がおこる場合もある。
４月１日現在不調が２件発生している。
１件は、ＰＣ画面にネットワ−クコンピュ−タ−が表示されなくなってしまったことである。
１週間前の土曜日１１時頃であるが、１台のＰＣをセットアップしていたところ、ネットワ−クに接続できなくなってしまった。
「あれ、さっき接続できたのに」と近くの部屋のＰＣをみてみるとちゃんと作動している。
もう一度セットアップ中のＰＣをネットワ−クに接続しようとしても、ドメインサ−バ−から拒絶されてしまう。
それで、サ−バ−室へでかけ、途中で動いていないＰＣの電源を入れて起動し、ネットワ−クへの接続を試してみたところ、やっぱり弾かれる。
「ギョ」である。
「今、ネットワ−クに接続して稼働しているＰＣは、停止しないかぎりシステムは稼働するが、一度電源を落としたり、今作動していないＰＣは起動させてもネットワ−クシステムに接続できない」重大事件発生となった。
ドメインサ−バ−あれこれを点検してみたがどうも異常が発見できない。
たまたまアドミニストレ−タ−資格でパスワ−ドを使用して接続を試みたところ、接続できるではないか。
ということは、全ユ−ザ−にアドミニ資格を与えないとネットワ−ク接続ができないというムチャクチャな混乱がドメインコントロ−ラ−に発生しているのか、とビビッテしまった。
とりあえずサ−バ−システムを設定セットアップしたソフトウエアサ−ビスのサ−バ−システム担当に連絡し、リモ−トでドメインサ−バ−を調査してもらう。
アドミニストレ−タ−でないとネットワ−クに接続できないなどという事例は初めてとのことで、１時間かかりきりで調べてみたが不調の理由がわからないとの返事。
土曜日の午後だから、最後の手段、ドメインサ−バ−の再起動をしてみよう、ということになって「ただいまネットワ−クシステムに異常が発生していますので、システムを停止します。正常に稼働しましたらご連絡します。」と院内放送。
ドメインサ−バ−の停止と再起動をおこなった。
しかし、しかしである。・・・・・システムは正常回復しないではないか。
やっぱりアドミニしかネットワ−ク接続できない。
「これはいよいよアドミニのパスワ−ドを全ユ−ザ−に公開せねばならん、とりあえずその方法で回避しよう。」と決断して、臨時のアドミニのパスワ−ドをユ−ザ−プロフィルエディタ−で設定し、院内へパスワ−ドを印刷配布した。
そのあとである、念のためプロフィルエディタ−のネットワ−ク接続条件をチェックしてみましょう、ということになって開いてみた。
ナント、接続できるのは「アドミニストレ−タ−」だけとなっていた。
あわててドメインユ−ザ−を追加する。
まさか、こんなところが原因とは？？？？。 でも、だれもこんなところいじってないのに・・・・・・？。
で、接続は正常化したのであるが、ところがネットワ−クコンピュ−タ−がＰＣ画面に表示されなくなってしまった。
これが表示されないとネットワ−ク資源（プリンタ−等）の共有設定ができないわけではないが、極めて困難となる。
困ってしまう。
どこかドメインコントロ−ルシステムに異常があるはずであるが、未だ原因が究明できていない。
そうこうしていたら、昨日バックアップのドメインサ−バ−が突然ハングアップしてしまった。
自己エラ−チェックシステムを作動させたところ特に異常が発見できなかったので、再起動させた。
ハ−ドディスクの情報などは、別のサ−バ−にコピ−してやれやれと思っていたら、またもやハングアップし再起動を自動的に繰り返すだけになってしまった。
バックアップのコンパックプロシグニア３００機であるから、とりあえずの被害は目下発生していないが、原因調査のために外付けハ−ドディスクを切り離して再起動させたら、起動後１０分ほどでブル−スクリ−ンのハングアップ画面となってしまった。
で表示がメモリ−エラ−である。
次々とアクシデントがおこるものである。
目次へ
１２．ついにコンパックプロシグニア３００が死んだ。
どのメモリ−がエラ−をおこしているのか、２枚で８０メガのメモリ−（今となったらこんな中途半端なメモリ−サイズもめずらしい）を１枚ずつはずして、順次立ち上げテストをおこなってみたが、メモリ−サイズエラ−表示でどうもよくわからない。
メモリ−カウンタ−は正常カウントとなる。
コンパック社に確認したところ、メモリ−テストは即答試験ではなくて、半日かかる自動診断をおこなってくれとのこと。
昨日２時間かけたといったら、それでは入り口みたいなもので、機器によって異なるが半日つまり６〜１２時間のメモリ−テストロジックが走るらしい。
しぶしぶもう一回やってみるかと起動かけ、ＤＯＳからの試験ロジックを立ち上げようとしたとたん「ＣＰＵキャッシュメモリ−パリティエラ−」が表示されて停止してしまった。
ＰＦＵのサポ−トに確認したところＣＰＵのＰ１５０が死んでいますとのこと。
コンパックの保証期間はとうに切れている。
さすがにＰＦＵもＰ１５０などというＣＰＵは手配不可能とのこと。
サ−バ−だから、ＣＰＵのクロックアップやアクセラレ−タ−での対処でどうにかしてみようかなどという冒険はとてもできない。
ということで、プロシグニア３００は、ゴミとなってしまったけれども、もう１台のプロシグニアの予備部品としてあと２年間はとっておこう。（もっともＰ１６６が入手できたら、Ｐ１５０がわりに差し替えて、クロックダウンで走らせてみようかとも思っていますが）
というとで、当面２年間を（２年後にはサ−バ−システムの全面更新を予定）もたせる臨時のサ−バ−ＰＣを手当する方針とする。
パリティ−付きメモリ−５１２メガでＣＰＵはセレロン４３３、４０ギガのＲＡＩＤ５ドライブシステム、１００ＢＡＳＥ−Ｔカ−ド、ＤＤＳ３のＤＡＴ、２チャンネルのウルトラワイド２ＳＣＳＩＩカ−ド、Ｇ−ＲＡＭは４メガというスペックである。
これで金額は８５万円程度。
セレロン４３３が少し見てくれが悪いが、能力的にはＰ１５０からみたらりっぱなものである。
ＲＡＩＤ５ドライブであるが、内蔵３台で６０ギガなのでＲＡＩＤ５にすると４０ギガとなってしまう。
しかし、これまでの経験からＨＤは必ず故障するからＲＡＩＤ５でないシステムではデ−タ−の保証ができない。
２０ギガをケチッてデ−タ−吹っ飛んだら、その損害の方が回復不能の大損害である。
このＲＡＩＤドライブは、製品名を トラストガ−ドといい、内容的にはＩＢＭの５１２キロキャッシュの最新ＩＤＥドライブ３台で構成されているようだ。
それをインタ−フェイス・コントロ−ルカ−ドをかませてＳＣＳＩＩ接続に組み替えているみたいだ。
診療所システムにもこれを使ってサ−バ−ＰＣを組み立てたので、２台目であるが、なかなか早いし、調子も安定してるし、本院のサ−バ−にも使用してみることとした。
それにしても、３年半前のフルタワ−サイズ２台構成で約４０ギカのＲＡＩＤ５システムが、５インチベイ３段に４０ギガが収まる時代になったという進歩の早さに驚くばかりである。（価格も約４０万円だから当時の９分の１程度という価格破壊である。）
実際デ−タ−ベ−スの構築をＤＡＴからおこなってみたが、サ−バ−の４ＣＰＵのコンパックプロライアントとそのＲＡＩＤ５のシステムでは９時間程度かかったのに、このセレロンでのシステムが３時間程度と、この面での比較ではどうやら３倍程度速いようだ。
コストパフォ−マンスでは、この８５万円のハ−ドシステムの耐久性能さえ良いならば、申し分ないのであるが・・・・・・。
さて、２０００年４月２３日よりドメインサ−バ−とリアルタイムデュプリケ−トバックアップのサ−バ−として稼働開始となったのであるが、快調である。
プロシグニア３００時代には、バックアップレスポンスが悪く、処理のタイムラグが拡大する一方で、サ−バ−も引きずって処理のレスポンスダウンをまねいていたのが、そういった処理のレスポンスダウンが全く発生していない。
ドメインサ−バ−とバックアップドメインサ−バ−が稼働開始したことで、ネットワ−クコンピュ−タ−が正常に表示されるようになった。
なぜ２つのドメインコントロ−ルサ−バ−が稼働すると正常表示となるのか、理由はわからないが、正常化したのだからバンザイである。
追伸、トラストガ−ドの冷却ファン２台がその後の何回かサ−バ−停止にともなって、止まってしまっていた。
本体のハ−ドディスクが、指でさわったら火傷しそうにあつい。
とりあえず、トラストガ−ドに電話で相談したら「ファンが停止しているのでないか」ということで「もし停止していたら無料で修理するから製品を送ってほしい」と言われた。
「ＲＡＩＤのドライブはずして送るわけにもいかんな」と、サ−バ−の側壁板をはずしてよく見たら、やっぱり２台のファンがとまっていた。
テスタ−でモ−タ−端子の電圧測ったら１３Ｖちゃんとある。
「モ−タ−がとんでいるのかな」とファンをピンと弾いたら突然回りだした。
「しめた」ともう１台のファンも弾いてみたが、残念こちらは回らない。
トラストガ−ドのホ−ムペ−ジでは「１台のファンで十分な冷却能力ある」と書いてあるので、しばらく放置したら、熱が冷めて「やや暖かいかな」という程度になった。
それで、目下１台のファンによる冷却で稼働している。
倉敷診療所のサ−バ−もトラストガ−ドでＲＡＩＤ組んでおきましたが、そちらは全く問題なし。
どうにかなったら、みなさんに報告します。
目次へ
１３．バックアップサ−バ−が死んでいた。
さて、６月２日（金）朝、いつものとおり朝礼のあとサ−バ−室をのぞき、定期バックアップタスクが正常に終了しているのか点検をおこなった。
ところが、リアルタイムデュプリケ−トでバックアップをとっているトラストガ−ドのＲＡＩＤ５のドライブ２基が、アクセスランプが点灯したままとなっているではないか。
ゲゲッ！！ (・・？！ 。
あわててモニタ−の電源を入れる、と、ブル−スクリ−ン （+_+) 。
ＮＴのメモリ−エラ−表示となって、一切のキ−入力を受け付けてくれないし、バックアップのＤＡＴのカセット取りだしキ−さえも反応してくれない。
まさか、ＲＡＩＤ５のドライブ２基がふっとんだのではないだろうな−−−と不安がつのる。
１基は予備を購入してあるが、２基とんだらお手上げである。
一切のキ−を受け付けてくれないので、おそるおそるリセットスイッチをプッシュ。
ＲＡＩＤのアクセスランプは消えて、バイオスのロ−ドになる。
やれやれ、どうやら立ち上がるかな・・・・・・、ン？・・・アダプテックのスカジ−カ−ドを認識せずに立ち上げ処理が停止してしまう。
まさか、スカジ−カ−ドが故障した！！？。
もう一度リセット・・・やっぱり止まる。(ToT)
あとやってないことは、電源を切っての立ち上げ直しを試してないだけ。
一縷の望みをかけて、電源を落として、１、２、３、４・・・９、０と数えて、電源入。
バイオスは・・・スカジ−カ−ドも認識したぞ・・・？！・・ＮＴの正常立ち上げモ−ドになって・・・・治っちゃった。('_'?)
ということで、ＤＡＴのテ−プも交換正常におこなえたし、念のためみたサ−バ−の記録も、前夜のＤＡＴへの正常バックアップと、今の立ち上げ処理しか記録なくて、なにが原因でメモリ−エラ−のブル−スクリ−ンが発生して停止となったかは、全くわからない。
とりあえず、正常化したから原因不明とはおそまつだけど、まあいいや。
あ〜−−−ビビッタな−−、２０分ほど冷や汗かいた。
その後１週間してやはりＲＡＩＤがランプ点灯のままで、サ−バ−としてはハングした状態となっていた。
深夜のＤＡＴへのバックアップ中にハングしたことは、イベントビュ−ア−の記録から判明した。
今回はブル−スクリ−ンでなかったし、前回の経験から立ち上げなおして解決。
その後はとりあえず５週間になるが、なにも起こらず走っている。
なぜハングしないのか、不思議だ
なんていっていたら、毎朝ＳＱＬサ−バ−の定期テスクをチェックしているのですが、リアルタイムデュプリケ−トが停止しているのを発見した。
イベントビュ−ア−の記録から、前夜のＤＡＴへのバックアップ中にＳＱＬサ−バ−へデ−タ−処理の書き込みがあり、このためリアルタイムデュプリケ−ト処理がハングして停止したらしいことがわかった。
デュプリケ−トはＣＳＳ社に連絡して停止したログから再開をかけてもらって復旧。
どうやら、ＤＡＴへのバックアップ中とリアルタイムデュプリケ−トとＳＱＬサ−バ−への書き込みのタイミングで事件がおこっているようである。
この報告後、１度だけ異常がＳＱＬサ−バ−の定期タスクに発生した。
それは、定期バックアップのタスクが指定してあったにもかかわらず、リアルタイムデュプリケ−トと定期タスク処理から除かれてしまった事件でした。
つまり、毎朝のＤＡＴテ−プへのバックアップ点検で、ある朝バックアップがされていないことが発見できたので、不審に思って調べたところ、定期タスクより除かれているのを発見したわけです。
この原因は全く不明です。
ただ、イベントビュ−ア−などの記録から、ＤＡＴテ−プへのバックアップ処理中に発生したらしいことは判りました。
とりあえず、その後は不思議と事件が発生していない。
ただ、クライアントの半数が次々とＲＡＭ１２８メガ入れたセレロン４００以上のＰＣになったので、サ−バ−の性能が限界となって、レスポンスが改善しなくなった。
毎年３０台ずつクライアントＰＣを計画的に更新する事にしたので、５年間で全体が更新され、医師用とか医事の会計とかには常に最新のＰＣを設置することができる。
おかげでＰ１３３でＲＡＭ３２メガのＰＣ９８２１では、以前よりいっそう処理に時間がかかるようになってしまった。
ＰＣ９８２１ではなくても、ＲＡＩＤへの読み書き処理が集中すると、レスポンスダウンがひどくなって、例えば後ろで４台のプリンタ−で一斉にレセプト印刷をさせているときの医事会計ではＰＣはセレロン４３３なのに、計算までは速くても、それから結果をＲＡＩＤに書き込んで、会計明細計算書・領収書をプリンタ−から出力して、次の患者の処理に移るのに、これまでは普通１〜２秒で会計画面が切り替わるのに、２０秒くらいかかるようになってしまった。
しかたないので、午前の外来中は２台のプリンタ−でレセプト印刷をすることにして、とりあえず会計のレスポンスを５〜７秒程度に改善させることとした。
レセプトのプリント処理をしていなかったならば、ほぼ５秒以内で切り替わるから、外来の計算処理が間に合わなくて、会計まわりに患者さんがたまるなどということは、外来１０００人を越える日でも全く心配ないが。
ところがある朝、医事課のレスキュ−員が顔色変えてサ−バ−室へ飛び込んできて「サ−バ−動いてますか？」
なにごとが起こったのかと聴いてみると、医事課の会計まわりなどのＰＣが突然一斉にダウンして動かないとのこと。
バックアップのデュプリケ−トしているサ−バ−からＤＡＴのテ−プを交換する作業中だったし、サ−バ−のパフォ−マンス・モニタ−にも異常はない。
良く聴いてみると、どうもモニタ−も消えているとのことなので、室内配線の１００Ｖの電源が落ちているようである。
それも、蛍光灯はついているとのことなので、コンセント回路のブレ−カ−が落ちたのではないかと判断して、施設係に電話する。
医事課へいってみると施設係もきて「ブレ−カ−が落ちる」とのこと。
今まで、コンセント回路でブレ−カ−など落ちたことないから「何か今日から新しい電気製品をコンセントにさして使っていないか」とたずねると「あの−−朝に足下が寒かったので電気スト−ブ入れました」、「バカタレ−−−、それが原因でブレ−カ−落ちたのだ」というわけで、電気スト−ブを抜いて一件落着。
目次へ
１４．サクシンとサクシゾン・病院管理部の責任が問題
北陸のある病院で医師オ−ダリングの際に、薬剤選択でサクシンとサクシゾンが並んでリストに上ったため、クリックミスで筋肉弛緩剤の毒薬サクシンを選んでしまい、医療事故となって患者が死亡したという事件が発生した。
たとえクリックミスでも注射実施のときに看護婦が「おかしい、この患者にはこの注射が指示されるはずがない」と医師に直ちに疑問を問い合わせることができれば、ヒヤリとするニアミスでとどまって事故発生にはならなかったはずである。
つまり、この医療事故をおこした病院は職場の職員間の民主的関係（簡単に言えば、看護婦や薬剤師が医師と気軽に意志疎通できている風通しの良い人間関係）ができていないために事故発生となったものである。
その点では病院管理部の責任は重大であって、一医師や看護婦のみに責任をかぶせることは許されない。
とはいっても、医師のオ−ダリングで検索リストにサクシンとサクシゾンが並んで上がるのはたしかである。
普通は先頭２文字あるいし３文字検索がとられている方式だからである。
たしかに、クリックミスが発生しやすいし、当院の医師に尋ねたところ他の薬でもクリックミスの経験が皆あり、自分でミスに気づいたり、看護婦や薬剤師に言われて気づいたりで、これまで事故になっていないとのこと。
医師オ−ダリングでのこのクリックミス発生をどう防ぐのか、安全対策で絶対必要である。
どうすべきか、全国の民医連の仲間とも相談した。
だいたい良く効く薬は、どれ一つとっても用法や分量を間違えたら危険な薬である。
だから、毒薬は青で劇薬は赤でリストに上げたらミスがなくなるのではないかとか考えても、あまり意味がない方法である。
危険度の高い薬については、先頭に”＋”の符号を付けて検索しないとリストに上がらない方法も考えてみたが、次第に”＋”ばかりになって意味がなくなってしまいそうである。
結局、リストの行間に１行の空白行を入れて、クリックミスでは薬が選択されないようにする方法が一番良いとの結論になり、それでもダメな場合には”＋”を特定の薬剤に付けないとリストに上がらない方式にしようと結論がついた。
早速実施しているが、リスト行が倍になるので薬剤が選択しにくいのでないだろうかと思っていたが、医師からのクレ−ムは全くない。
「ミスがないからいいよ」と好意的な反応である。
さらには、病名に適応のある薬しかリストに上がらない方式も考えられるが、この方式については、病院情報処理システムの構築当初からＣＳＳ社に構想を述べて「考えてやって頂戴」といってきていたのである。
この方式は、発想をかえてみると「薬や検査の実施内容をもとにして、もっとも一般的な病名リストから医師が病名を選ぶことができる」機能をもたせられるソフトでもあって、医師のレセプトへの病名付け業務のわずらわしさから解放もできる側面もあるわけです。
が、日経新聞みていたら残念ながら最近東京の某ソフト会社が特許を申請してしまった。
ともあれこれは、あくまでもオ−ダリング・システムのアプリケ−ション上での技術的な安全対策であり、真の安全対策は「看護婦や薬剤師が医師と気軽に意志疎通できている風通しの良い人間関係」の民主的職場づくりで、病院管理部の責任が一番問われていると強く主張したい。
目次へ
１５．病診連携・診療所オ−ダリングシステム１年のまとめ
昨年の4月にＪＲ倉敷駅の北、約1キロの所に「コ−プくらしき診療所」を開設し、診療所オ−ダリングシステムを稼働させ、水島協同病院システムと結びました。
その1年間のまとめが、診療所の職員によって発表されましたので、以下に一部修正して掲載します。
コ−プくらしき診療所オーダリングシステムのまとめ
センター病院とのシステム連携によって前進した診療所運営の成果と教訓
１．くらしき診療所は、１３番目の院所として、１９９７年度の医療生協総代会でＪＲ倉敷駅北地域への建設が決定されました。
以来、全院所を上げて医療生協を知ってもらう運動を建設予定地域を中心に展開し、２０００年４月の開設時には２０００名の医療生協組合員が生まれていました。
くらしき診療所は、センターの水島協同病院からは、約１０qの距離にあります。
さらに、近くには１２００床もある総合病院や医科大学病院がある立地条件でしたので、診療所がなりたっていくためにはセンター病院の情報力をどうタイムリーに生かすのかが課題でした。
くらしき診療所では内科と小児科の診療をおこない、１．慢患管理、２．健診活動、３．在宅の三本柱を医療活動の基礎に進めていく方針を出しました。
２．日常業務の効率化を図り医療活動を展開するうえで、センター病院が約５年前に構築したオーダリングシステムを活用できないか検討し、コスト面・システムの中身を検討して導入にふみきりました。
そして、水島協同病院のデータを最大限活用するため、水島協同病院と連結したシステムとすることが必要でした。
特徴としては、水島協同病院と共通の患者ＩＤ（番号）、保険情報の共有、検査データの共有、医師オーダリングシステム、慢患管理システムがあります。
３．システムはサーバー１台とコンピュータ５台をネットワークで結び、水島協同病院とはＮＴＴのデジタル回線で結んでいます。
サ−バ−はＣＰＵがセレロン４３３の普通のＰＣで、ＲＡＩＤ５規格の２６ギガストレ−ジドライブをつけて、ハ−ドディスクが１台故障してもデ−タ−が失われないようにしてあります。
念のために、さらに別の１台のＰＣのハ−ドディスクに、毎日自動的にデ−タ−をバックアップコピ−しています。
なお、サ−バ−だけは、安定電源装置をつけて、突然の電源故障がおきないように対策をとっています。
システムが稼働して約1年が経過しましたが、故障なしの安定稼働です。
４．者さんへのサービス面について以下に列挙します。
・患者さんに結果をグラフ化して表示した画面を見てもらいながら、前回と比較して検査結果をわかりやすく説明できます。
・水島協同病院で受けられた健診データも参照して説明ができます。
・処方したお薬の説明書、検査結果データをプリントして患者さんにわたせます。
・水島協同病院にも受診されている患者さんは、病院での投薬情報をリアルタイムに正確に確認できますので、特に小児科の患者さんにとっては安心です。
・オーダリングシステムによって、会計計算と薬の準備が同時進行でできますので、患者さんの待ち時間が短縮されます。
・共通の患者ＩＤによる診療情報ですので、センター病院の診察券があれば様々な診療情報を確認できます。
・水島協同病院での検査や診療も、予約画面を患者さんにみてもらいながら都合を相談して決めることができます。
・くらしき診療所に受診されている患者さんが水島協同病院に入院した場合もタイムリ-に確認できます。
５．業務の効率について列挙します。
・水島協同病院とカルテ情報が共有のため、カルテ情報が正確かつスピーディに活用できます。
・オーダリングシステムにより、薬の作成は処方箋でおこない、会計は医師オ−ダ−デ−タ−取り込みによる自動計算とカルテでの確認でおこなうなど、業務を分担して効率よくできます。
・システムが簡素化されているので、初心者の方にもわかりやすいのですが、会計入力はオ−ダリングデ−タ−の取り込みによる自動計算以外でのアレンジがあるので、そこは勉強が必要です。
・病院と同一能力の統計システムなので、診療所の指標・統計が即時に集計できて医療活動・経営活動に活用できます。
・レセプト８００枚が約１時間でプリントされますので、診療所のシステムとしては十分すぎる処理能力があります。
６．慢性患者管理システムについてあげてみます。
・慢性患者さんの全身管理をきちんとおこない、中断をなくすためのシステムです。
・登録病名や患者さんの病状に応じて、全身管理と必要な検査項目の想定表を作成し、検査漏れをなくすことができます。
・ガンや難しい病気の患者さんの全身管理もきちんとおこなえます。
・会計入力データをもとにしていますのでリアルタイムかつ正確です。
・疾病の統計で、医療活動を分析できます。
７．今後の予定
・慢性患者管理システムを３月初旬より稼働させましたので、患者の全身管理につとめます。
・健診システムの導入を検討中です。
・検査オーダリングシステムの検討中です。
・倉敷医療生協の全院所間の情報ネットワーク化をぜひとも推進したい。
８．患者さんの評価の声をいくつかあげてみます。
患者さんからは「総合病院で出た薬もわかる」「検査結果を画面で説明してもらえる」「処方の薬の説明書がもらえるので、ありがたい」「予約は画面を見ながら相談できるので、自分の空いている時間に合わせられる」など喜んで頂いている声を聞きます。
こういった声を聞く中、診療所職員も、導入して良かったと感じています。
さらに、私ごとではありますが、水島協同病院で同じシステムを使っていたので、診療所業務立ち上げ・研修の期間が最低限でできたと思います。
各院所ごとに、システムが違ったならば、人事移動ごとに一から仕事を覚えなくてはならないし、診察券が違うので患者さんのデータの共有ができないなど、弊害があるのではないでしょうか。
今回、くらしき診療所と水島協同病院のネットワーク化を行いましたが、倉敷医療生協すべての院所のネットワ−クはできていませんので今後の課題です。
今後も一つ一つ課題を克服していき、またみなさんの前で成果を報告ができればと思います。
こうした診療所のまとめをみても、病院と診療所の連携においてオ−ダリングシステムの果たす役割が決定的に重要であることが、確認できます。
苦労してシステムプロデュ−スとメンテナンスやっていて良かったな−−と思えます。
目次へ
１６．3/24地震で病院がどうであったのか、コンピユ−タ−システムはどうだったか
３月２４日（土）午後３時３０分頃、病院５階で患者さん５名と新聞づくりをしていた。
最初は足の裏を突き上げる様な縦揺れで地震とわかる振動が７〜８秒続き、「あっ、これは大きいぞ」と思って身構えていたら震度５強のゆれが襲ってきて３０秒ほど続きました。
いっしょにいた患者さんは、顔をこわばらせて床にしゃがみ込んだりテ−ブルの下に入ったりしましたので「震度５程度ですから病院はつぶれませんから大丈夫です」と話しかけながら地震が終わるのを待ちました。
このとき、同じ５階栄養課の食器がくずれ、サラが割れて、院内が停電しました。
ゆれがおさまって直ちに屋上にでて病院の周囲や水島コンビナ−トを見まわして火の手が上がっていないことを確認しました。
とびだしてきた栄養科の職員に「地震はおさまったから、病院はつぶれないから大丈夫」と声をかけて、地震ではげた壁の塗料がいっぱいおちている階段を１階事務当直室まで走って降りました。
途中には、防火扉が地震で閉まっている階もありましたが、院内放送をしないといけないと思って急ぎました。
１階の事務当直室にきて非常放送装置のマイクをにぎったところ作動しましたので、非常電源が作動していることが確認できました。
「職員患者の皆さんにお知らせします。
震源がかなり近いと想定される震度５程度の地震が発生し、院内の電気が消えていますが、病院の非常電源と非常発電は正常に機能していますので、ご安心下さい。
この程度の地震では病院設備は影響がないようにつくられていますが、職員は直ちに安全がたもたれているか、機器が正常に作動しているか点検をして下さい。」と２回くりかえして放送しました。
この時点では「病院非常電源が生きているから、火災報知システムも生きている。
その火災報知器が発令作動していないから院内火災は発生していない。
そうすると一番心配なのは、レスピレ−タ−などの患者さんに装着してある呼吸装置の電源が落ちていたり、振動でエアのパイプがはずれたりしていないだろうか。
安全点検をしてもらって、もし、電源おちている機器があったら、非常発電コンセントに差し換えてもらわないといけない。」という判断でした。
しかし、あとで考えてみますと、患者さんや職員が「この地震の震源地はどこだろうか」と心配しているだろうからと「とりあえず縦波継続時間から１００キロ程度の割合近い距離の場所」と考えて「震源はかなり近いと想定される」と放送してしまいましたが「いいかげんな放送をおこなった」と反省しています。
また、「職員はただちに入院患者さんの安全を確認してください」と明確に放送すべきだったのに、少し考えすぎの放送だったなとこれも反省です。
さて、３分ほどたったでしょうか、まもなく病院に電気がきてエレベ−タ−も動きだしました。
「やれやれこれで一安心」と、そうこうしていたら「コンピュ−タ−がつながらない」という連絡がはいりだしました。
「やはり」と思いましたが、しかし、しばらくはコンピュ−タ−システムへの対応はほっておきました。
人身事故が起きていないかが一番心配だったからです。
それと、地震でサ−バ−がひっくりかえって破損していないかぎり、瞬断や電源の一時的切断があっても無停電装置と病院の非常発電でサ−バ−の電源が落ちることはないから、システムに異常が発生する確率は低いと判断していたからです。
クライアントがサ−バ−につながらないのは、病院が停電してメインのスイッチングハブの電源が落ちているからです。
そのスイッチングハブが機能を発揮しだすのは、病院に電気がきて後５分程度必要であることもわかっていましたので、クライアントＰＣがすぐにサ−バ−を呼び出しても応答できないから「コンピュ−タ−がサ−バ−に接続されない」となるだろうと想定していました。
この間に病院幹部やＣＳＳ社に電話連絡をと試みましたが「ただいま非常に電話が混雑しています」というアナウンスのみで全くつながりません。
外からは病院に電話がかかってくるのにです。
１０分ほど待機しましたが、緊急連絡がなにもないので「とりあえずの対処は問題ないな」と判断してサ−バ−室へむかいました。
サ−バ−はとりあえずまともに機能しているようにみえました。
スイッチングハブが機能しているか・ＰＤＣやＢＤＣ機能のサ−バ−が働いていてＷＩＮＳによるネットワ−クコンピュ−タ−の表示ができるのかをためしてみたり試験もしました。
ただ、エンタ−プライズ・マネ−ジヤ−でサ−バ−の作動状況をチェックしたところ、原因不明の倉敷診療所サ−バ−との接続不良が発見されました。
しかし、ネットワ−クコンピュ−タ−からは、倉敷診療所のサ−バ−上のファイルも表示できたので、デ−タ−ベ−スＳＱＬの接続のみの異常と判断しました。
なぜそうなったかは全く不明ですが、倉敷診療所職員とは電話が全くつながらないため、対処は月曜日とあきらめました。
こうした対処のときでも中国電力からの病院への電源供給は時々切断しましたが、無停電電源装置が警報を発しながらも機能をはたしてくれました。
やがで病院の電源が安定し、スイッチングハブが機能を発揮して、ネットワ−クコンピュ−タ−が正常表示となり、クライアントＰＣで業務アプリケ−ションも問題なく走ることを確認してから院内放送をしました。
「サ−バ−室より職員におしらせします。
サ−バ−は正常に機能しています。
各部署のコンピユ−タ−が機能しない場合は、電源を切って、そのコンピュ−タ−をもう一度立ち上げなおしてください。」
この放送をしてしばらくして、ある病棟から１台のＰＣの電源が入らず機能しないという連絡がありました。
調べてみると、このＰＣだけは電源も入らない故障・おそらくマザ−ボ−ドにかかわる故障がおきたと思われましたので、予備のＰＣと直ちに交換しました。
この時点での病院の被害は、患者さんへの被害はなく、栄養課のサラ破損・ＰＣ１台故障・患者さん用図書の書棚１台が倒れガラス扉が割れたことでした。
しかし、それから約１時間して突然火災報知器が作動し病院内にベルが鳴り響きました。
再度当直室へ急行して警報表示磐をみると１階での火災と表示されていました。
数人の職員も集まってきて１階にはどこも火も煙もみえないとのことでした。
そこで直ちに院内放送をおこないました。
「ただいま火災報知器が作動し、１階部分での異常が表示されました。
職員が調査中ですが、目下火災は発見されておりませんので地震の影響による誤報である可能性もありひきつづき調査しています。
入院患者のみなさんは、そのまま待機下さい。」
みなで調べ回っていましたが、時々作動したりしなかったりなので、接触不良か漏電が発生しているんではないかと思っていたところ、施設係りより「水漏れ発見」の報告。
水漏れしている上の設備階へ行ってみると、パイプ接続部よりポタポタと漏水していました。
犯人発見です。
「入院患者さん職員の皆さんにお知らせします。
先ほどの火災警報は地震によって配管より水漏れが発生し、火災報知器を誤作動させたことが判明しました。
火災ではないことがはっきりしましたのでご安心下さい。」
という経過で、地震への対処も終わって、５時半過ぎに病院より家にむかいました。
この間ず−と、病院の電話も携帯電話も話し中や局の呼び出しも鳴らなくて、家と連絡がつきませんでした。
ひょっとするとと、４時過ぎに病院の公衆電話で試したところ自宅とつながりました。
ＮＴＴも大規模災害時には、自動的に公衆電話優先に切り替えているようであった。
倉敷診療所とのＳＱＬサ−バ−の接続は、結局、月曜日に診療所に職員が出勤して異常に気づき「本院へＰＩＮＧコマンドが通らない」という連絡を８時２０分にもらってから、復旧対処をおこないました。
エンタ−プライズ・マネ−ジャ−でタスクをチェックすると、定期タスクの倉敷診療所とのレプリケ−ションが停止表示となっていました。
履歴表示によると停止したのは、日曜日の深夜と表示されていました。
実際は、土曜日から異常となっていたのにです？？？
ＰＩＮＧコマンドは、不思議なことにこちらからは倉敷診療所へは通るのです？？？
停止表示のタスクを右クリックで接続開始にしましたが、パフォ−マンス・モニタ−では当院のサ−バ−が急激に処理表示が増加しましたが、２０分たっても倉敷との接続が回復しません。
「これはいかん」とＣＳＳ社に電話してみましたが、受付事務の女性以外未だ出勤せず。
結局、今西氏が出勤して９時前に連絡ついて「こちらのコンピュ−タ−に接続できるか試してみます」と電話して「今、こちらのＰＣに接続しましたが、なにか変です」と電話連絡あった時、こちらのエンタ−プライズ・マネ−ジャ−にも接続表示がされました。
「こちらにも接続表示ありましたよ」「それは、大阪との接続が表示されたのでは」「では、倉敷診療所に連絡して、本院へのＰＩＮＧ通おるか試してもらいます」ということで、倉敷診療所にＰＩＮＧコマンド試験するように連絡しました。
結果は、通った！・本院と診療所のＳＱＬサ−バ−の接続が復旧しました。
アプリケ−ションも作動することを確認して、一件落着。
しかし、倉敷診療所もサ−バ−は安定電源で停電しても５分はもつようにしてあったので、停止することなく作動していたのに、どうしてＳＱＬサ−バ−の接続のみが切れたのか原因は不明である。
地震の対策教訓
以上の報告からくみ取っていただき、対策マニュアルをそれぞれに用意いただかねばならない。
電話は不通になり、外部との連絡は不可能となる。
停電が必ず発生する、安定電源と非常発電でサ−バ−システムを防御せよ。
漏水の発生とそれによる火災報知器の誤作動発生も起きる。
院内や病院近隣に火災発生もありうる。
これだけは想定しての対策が必要と思います。
さて２００１年度の９月２３日と２４日をかけて、いよいよサ−バ−の更新をする計画を進めるつもりである。
現行の４サ−バ−体制から６サ−バ−体制へ移行する方針で、機種選定と予算論議にはいった。
また、南診療所も同時期にオ−ダリングシステムに移行する計画となってきた。
また、生理検査関係オ−ダリングや看護オ−ダリング、画像システムの具体化も急がねばならない。
電子カルテシステムのコンセプト確立の研究も具体化が求められつつある。
こうした課題に対処しつつ、引き続き一つ一つ対策にあたるので、結果はまた報告します。
つづく
目次へ
Chaos to Cosmso トップペ−ジへ戻る