医療情報システム担当者の黄昏

アラ定年の医療情報システム担当のひとり語り

病院情報システムの障害対応/対マルウェア対応(3) 障害レベルごとの対応マニュアル(横糸)マルウェア感染疑い

(前回からの続き)

 前回がソフト的な或いはハード的、インフラ的な障害への対応であるのに対してマルウェア感染への対応は性質が異なる。
 それは、マルウェア感染対応は組織のシステム構成や現状でのマルウェア対策などによって異なってくるからである。
 ここでは自分が在職中に考えていた感染後対応の考え方をメモ的に書いた。

 2000年代の始めの頃にマルウェアに侵入された経験をした時、まあ当時はコンピュータウィルスと呼んでいたんだけど、当時はマルウェアのはしりの頃で今みたいなランサムウェアとか情報漏洩とかセカンダリバックドアがらみとかの犯罪臭プンプンのものではなく、PCを止める、感染を広げる等のイタズラ目的のものであった。目立ちたがりのハッカー(「ハッカー」という言い方の是非も色々言われたが)の腕試し的なものという認識だった。
 その時はマルウェアに感染した個人所有のPCを無許可で病院のネットワークに繋がれたことで一部システムの数台のPCとサーバが感染して動作を停止した。
 幸いだったのは主要システムの感染ではなかったこととシステムに対する依存が今ほど大きくなかったこと。
 それほど大きな影響はなかった。
 持ち込んだのは..。とこれぐらいにしておくけど、当時のゆるゆるの管理体制のスキを突かれた。
 これを奇貨として時間はかかったが体系的にシステム管理/ネットワーク管理体制の強化に努めた。それ以来、外部持ち込みのUSBメモリやSDカード、USBハードディスク等に感染が確認されたことはあるが内部のPC/サーバが感染したことはない。(と信じている...)

 あれから時は流れ、マルウェアも進化した。目的もイタズラから犯罪に移行し国家機関が絡む場合も多い。活動内容も破壊活動、情報窃取、身代金要求、バックドア設置ナドナド。(マルウェアについてごちゃごちゃ説明されているサイトは多いけど、McAfeeこの記事は簡易にまとめているので読みやすい。)
 ここでは侵入されないための予防策等には触れない。感染疑いが発生した後の対応について述べることにした。

 

 まず、状況の発生。
 これは非常にわかりやすい。誰にでもわかる「マルウェア感染を疑われる事態」が発生するからである。

マルウェアを疑う事態の発生
 例えばランサムウェアならば身代金要求メッセージがランサムウェアに感染したPCで表示されるのが事象発生になるし、情報漏洩ならば多くは外部機関から「あんたのところのデータが漏れてるみたいだけど」との連絡がある。
 それ以外には、

マルウェア対策ソフトウェアがマルウェアを検出する。
・PCなどが動作が重い等の動作不良を起こし、調べてみたらなんか入ってた。
・UTMがインターネットへの不正な通信を検出する。
・外部から「あんたのところから変なメールが来ているよ」との通報を受ける。
・外部から「あんたのところのIPアドレスから攻撃を受けてるんだけど」との通報を受ける。

 などなど。

 こういったことが発生しないからと言ってマルウェアに感染していないとは言い切れないことは理解してほしい。
 つまり、事態が発生するまでは「マルウェアはいない」ではなく単にいるもいないもわからない「見つかっていない」と言う状態に過ぎないと考えたほうが良い。
 マルウェア検知率が90%以上と歌われている対策ソフトだが、ゼロデイ(まぁ、出来立てのマルウェアとでも)に関しては検知率が30%程度に落ちると言われていた。数年前のことだけど有名メーカのマルウェア対策ソフトがインストールされていてもゼロデイにPCをズタズタにされてゆく動画を見たことがある。動画ではわかりやすいように感染後に挙動を示すマルウェアを感染させていたみたいだからすぐにPCをズタズタにしていたが、感染後に深く静かに潜航するタイプだったらどうだろう。長い間内部情報をちゅーちゅー吸われたり、十分に組織内部に感染が広がったことを確認して一気に行動に出てくることも考えられるかも。
 内部システムではないが私は準公的機関のHPのマルウェア感染を職場から検出したことがあった。通報したが当のHPの中の人は全く気付いていなかった。準公的機関だったのでマズイとは思ったが通報しても反応がない以上こちらとしては「知~らね」となるしかなかった。一週間ほどして連絡ありがとうのメールが来てその後1ヶ月程度して対応しましたのメールが来たよ。
 自分たちがヤラれることがあるなどとは露ほども考えてなかったんだろうな。
 感染に関して私がパラノイヤなのだろうか。そうだったら良いけど。

●事態への対応
 上記の事態が発生し対応に移ることになる。
 対応については概ね以下のようなものを想定した。
1)発生時の状況確定
 発生時のシステムへの対応(ネットワーク停止を含む病院システム停止の判断)
 侵入経路の調査とマルウェアの特定(穴を塞ぐこと、影響範囲確定のための情報収集、再発防止へ向けて)
2)病院システムへの対応
 システム内の影響範囲の確定とPCやサーバの復旧
 壊れた患者データを含むデータの復旧
3)外部への対応
 身代金への対応
 警察や厚労省、その他外部機関への連絡
 マスコミ発表等。
 漏洩データに個人情報が含まれている場合には謝罪/補償などの対応
4)発生時対応の後
 情報整理、再発防止に向けての対応


 各々について概略を書く。

1)発生時の状況確定
・発生時のシステムへの対応(ネットワーク停止を含む病院システム停止の判断)
 ランサムウェアなどの破壊的なマルウェアだった場合はシステムは止まってしまうし、止まってない部分があったとしても感染拡大の恐れがあるということになったらシステムの全停止はしやすいだろうと思う。
 そうでない場合、まだシステムは稼働している状態でマルウェアが検知された場合等はどうするのか予め考えていたほうが良いと思う。例えば診療中、それも休日明けの平日の10時半頃で外来が華々しい頃に診療現場のPCがマルウェア検知の表示がされたと頻々と情報システム部門に連絡が入るという状態で何らかの判断をしなければならないとしたら?
 そう言った状況で冷静にITシステムの動作継続か停止かを判断できるかな。出来ると言うならば良いんだけどね。
 もう一つはマルウェア感染がある場合にHISが稼働していても緊急で停止をする場合があると事前に取り決められたら、そういう決定を下す可能性があることを院内に周知しておく必要もあると思う。 

★対応のための事前準備
 破壊的マルウェアランサムウェア等)侵入検知時のシステム停止権限の調整
 破壊的ではないマルウェア侵入検知時のシステム停止基準と権限の調整
 前回の「障害レベルごとの対応マニュアル(横糸)」。止めてしまったあとで診療を継続するために。 

 

・侵入経路の調査とマルウェアの特定(穴を塞ぐこと、影響範囲確定のための情報収集、再発防止へ向けて)
 情報システムを止めるか継続するか、それとも様子見かの判断をした後に特定する。
 病院の情報システム部門が自力で調査を進められるだろうか?
 以前の病院ではそれなりに詳しい人間もいたし、自分自身が自病院のシステム構成やネットワーク構成は資料を揃えていたし掌を指す様だったり、利用者についても知悉していた(誰が何をやらかしそうかとか)。
 マルウェアの監視システムやUTMのログの確認、プロキシサーバ系の商用システムやメール関係のシステムのログ確認もある程度自力で出来る状態だった。それでもすり抜けて入られたら自力での調査はまぁ厳しかろうな、と覚悟していた。
 感染状況の解析は、簡単なマルウェアなら別だが、現状でのマルウェア動向や動作について知悉している必要がある。OSやネットワークやAP等の動作をわかっていてマルウェア解析するための様々なツールを操ることが出来ると言う能力を通常の医療情報システムの維持管理業務に並行して獲得するのは無理無理だからである。また、実際に感染した場合には感染状況によってはインターネットを使った検索などの調査も自力では困難になる事態も予想される。
 だから各ベンダやマルウェア対策ソフトの営業職などにいつでも相談できるように顔見知りになりツナギを入れていた。(ベンダとか営業って怒鳴りつけ文句垂れるだけの存在じゃない)
 場合によっては高い金出してセキュリティ会社に調査に入ってもらわなければならない場合もあることを考えに入れておいてほしい。その際に、最低でもシステム構成やネットワーク構成の詳細な資料の準備ができてなかったら専門家が入っても時間がかかったり調査は頓挫する可能性もあるんじゃなかろうか。

★対応のための事前準備
 システムの詳細資料
 ネットワークの詳細資料
 IPアドレスとか場合によってはHOST名とかの資料
 OS、アプリケーションなどのUpdateの状況
 外部への接続状況の資料
 院内の監視状況を表す資料
 マルウェア監視システムへのアクセス方法
 UTMを始めとするインターネットアクセス監視システムへのアクセス方法
 ベンダのリモートメンテナンス関連の資料
 ベンダのメンテナンス作業記録
 その他病院職員などのリモートアクセスの資料
 その他システムへの出入りを示す資料(USBメモリの接続履歴など)
 各ベンダとの連絡経路
 マルウェア対策ソフト導入ベンダへの連絡経路
 等

 他にもいるかもしれない。いらないかもしれない。状況次第。どれだけ正確に病院内のICTの構成が把握できているかと言うことになると思う。
 ネットワーク構成図等はリプレースのたびにベンダを変えて資料を取ってなかった場合や、電気と同じつもりでLANケーブルを引くような業者が作業してた場合、わかったつもりの職員が好き勝手にケーブル引く文化の場合にはなーんにも無いよって事態もある。それでも管理IPが振れるようなSwitchが使われていた場合はSwitchのFDBからMACアドレス経由でどこに繋がっているかは追って行ける場合もある。IPを使う場合はL3SwitchのARPを抜いて調べることも可能。
 ただ、導入価格を抑えるためにクソ安いSwitchで構成されFDBが見れなかったらこのやり方では無理。最悪、LANケーブル引っこ抜いて先のSwitchのどのポートが死んだかで判断するか天井裏に潜り込んで手繰ってゆくか。

 ベンダのリモートメンテナンス関連の資料は、ベンダ側のリモート環境経由の侵入の調査を行う際に必要です。電子カルテとか医事とか各部門システム等の病院情報システムの中枢に直結している部分だし、それ以外のシステムのリモメンもそのシステムを通じて病院の基幹ネットワークに繋がっているので念の為。
 それについてはベンダに問い合わせをすると対応に関してベンダごとで温度差があったりする。
 リモートメンテナンスネットワークは攻略側からすれば狙い目。ベンダ側のガードが甘ければ侵入したベンダのリモート環境を使ってそのベンダが納入している複数の病院がターゲットにできるから。

 こんなに資料を集めるのはむり~!という方もいるかも知れない。そういった場合は機会を捉えて集めてゆくとか、計画的に集めてゆくとかして、少しずつでも集める。資料を眺めていると意外な盲点が見えてくることもあるのでやったほうが良いと思う。
 あんまり対応がひどいベンダは次回リプレース時に対象から外すとかね。

 もし、私が厚労省ガイドラインベースでの監査を実施するとすればこのあたりは突っ込む部分かなぁ。というのもモノの確認ということで監査する側は突っ込みやすいよね。「リモートメンテナンスは受けてますか」「それはどのシステムですか」「そのシステムの接続についての資料はありますか」「リモートメンテナンスの接続履歴を見せてください」等など。こんな軽いジャブ程度のツッコミでボロが出るようだったら困る。

 

2)病院システムへの対応
 マルウェアを特定し、穴を塞いだら次は復旧である。
・システム内の影響範囲の確定とPCやサーバの復旧
 どんなマルウェアによってどこまでヤラれてる、どこまで感染しているのかを把握して、システムとして問題を取り除く作業。
 このファイルを消せばいいとかこのレジストリをとかそんな単純な話だったら良いけどね。あの手この手で姿を隠そうとするからたちが悪い。
 このPCはこのファイルが出来ていないから大丈夫とか、レジストリがこうなってないから大丈夫とか、感染しているPCとしていないPCがわかればいいけどわからなければ場合によっては全PC再インストールってなるかも。
 どこまでヤラれているかその判断を行う際にはやはりその道のプロが出してくれるであろう判断基準をもって対応したいものである。素人では結局「この程度で大丈夫だろう」となるか、それでは不安だから「全部インストールし直せ」となるか。

 復旧に関してはHISのPCは情報システム部門がイメージを持っているけど検査システムのクライアントはイチから再インストールとか、例えば検査システムのサブシステムを供給している会社はすでにこの世になくて...とか。
 病院が大きければ大きいほど細々した仕掛けが入っていてすべてシステムの復旧は困難になるかもしれない。
 個々のケースは色々あると思うのでそれに合わせたシステムごとの復旧への環境整備を確認しておく必要があると思う。

★対応のための事前準備
 復旧対象システムのインストールイメージなど
 PC毎のインストールされていた機能や設定の資料
 OS等のライセンスの確認/準備(キッティング時に必要となるもの。Windows等では必要かも)
 等

・壊れた患者データを含むデータの復旧
 主要なシステムのバックアップは取っていると思う。それを戻すんでしょう。バックアップのとり方によっては戻るのは感染した日の午前0時のデータまでというケースが多いのかな。
 バックアップから復旧してちゃんと戻るかどうかが問題ですね。試したことあります?
 バックアップはどれだけ網羅されているんでしょうか?ベンダさんの言いなり?連中は自分の範疇以外は一顧だにしませんよ。これが足りないんじゃないかみたいなことを気がついたら教えてくれるベンダはまぁ優しい方で、そう言ってくれる営業さんとかSEさんが会社に戻ると上司から「いらないことを言うんじゃない」と怒られてるかも。だって値切られた安い保守費の範囲で想定外の仕事をやらされるかもしれない、上長はそう言ったことを考えるだろうから。
 データバックアップの範囲はきちんと確認したほうが良い。
 ベンダ提供のシステムだけじゃなく、OS提供の機能を拡張的に使っている場合(電子カルテサーバ等のシステムハード上のディスクの空き領域をファイル共有領域として使っている場合とか)や同ネットワーク上にファイルサーバを置いている場合、データベースを置いている場合などはそのバックアップとか。
 自分たちで開発したものや運用の仕組みを作ったもののバックアップとかは確認したほうが良い。特に情報システム担当の出入りがあった場合。前担当者が作ったものをヌクヌクと使っていて、事が起こってバックアップがないとか復旧の仕方がわからんとか。

★対応のための事前準備
 病院で必要なすべてのデータのバックアップが取れているかその網羅性の確認
 データを戻した時に稼働するかどうかの確認

 

3)外部への対応(渉外対応)
 外部への対応だから、基本的に総務部門などの渉外担当の範疇になる。専門の部隊がいたりするかもしれない。
 だけど、マルウェア感染時の対応について総務部門へ対応を依頼しよう~!と言ってもな~。
 予め言っておいてもまぁあまり期待はできない。だいたいにおいて情報システム部門以外でITについてあまりわかっていない部署のIT関係への対応や要求は腰が引けてるか目を三角にしての超前のめりになるかのどちらか。
 けど、情報システム部門としてやれることをやっておこう。つまり、以下の内容について要点を整理して説明し検討を依頼する。

・身代金への対応(ランサムウェアの場合等)
 ランサムウェアの場合は身代金を払うのかという問題。
 一般的には犯罪を助長するから「払うな!」と言われているみたいだ。バックアップなどでそれなりの準備がされている場合には払わずにさっさと次のフェーズに進むのも手だ。準備ができてなかった場合やバックアップまで巻き添えを食らった場合はどうするのか。
 上に復旧の準備について書いたが、これ全部やったら何日かかるんだろう。一週間?二週間?その間、停止する規模にも依るけど診療どうするの?外来止めるのか?入院患者はどうするの?どれだけの損害が発生するのか?
 私は軽々に「払うな!」とは言えないなぁ。まぁ、払ったところで情報が戻ってくるかどうかは五分と五分だと聞いた。ハナから戻す気がないランサムウェア(?)もあるらしい。
 ちなみにあの一斉を風靡したワナクライのときは払っても一切戻らなかったらしい。

 他には身代金に関しては漏洩をネタに強請るという手口もあると聞いた。
 病院上層部、法務にデータを人質に取られて発生する問題/リスクについて説明し真剣に検討して病院としての対応を決めたら良いかなと。

・警察や厚労省、その他公的機関への連絡
 まぁ、ヤラなきゃでしょう。警察に連絡したらIT担当等の連中が事情を聞きに来るんじゃないでしょうか?そういう状況になったことがないのでわからないけど。
 あと、ガイドラインには厚労省の医政局への連絡も書いてあったと思う。電話番号もあったように記憶しているが記憶違いかもしれない。確か、これはマルウェア以外の重大事象時も連絡しろと書いてあったような気が。
 他にも県とか、上部組織がある場合には必要に応じてそちらにも。
 このあたりは渉外担当部門の仕事で情報システム部門は言われるがままに情報を上げるしか無いよね。
 他には、と言ったら「先にこっちだろう!」と怒られるかもしれないが、マルウェアや情報漏洩絡みならばIPA独立行政法人 情報処理推進機構)やJPCERT/CC(一般社団法人JPCERTコーディネーションセンター)とかへの通報も忘れたらいけないと思う。JPCERT/CCは情報システム関連のインシデントを扱う組織なので連絡したら何か有益な情報をもらえるかもしれない。なので、マルウェア感染が確定したらさっさと連絡したほうが良いかも。

・マスコミ発表等
 渉外部門やら病院上層部の判断ですね。情報システム部門が勝手に動くことじゃない。

・漏洩データに個人情報が含まれている場合には謝罪/補償などの対応
 渉外部門やら病院上層部の判断ですね。情報システム部門が勝手に動くことじゃない。

4)発生時対応の後
 長い長~い後始末である。
・情報整理、再発防止に向けての対応
 ここに至るまでびすべての情報をメモって残しておくこと。いつ誰が何を話したかとかも超大事。
 それをベースに報告書を作成し再発防止策を練り上げること。多分、ここに至るまでの間に色んな情報に触れ多くを知りどうすればよかったかわかるようになっている。それを報告し、再発防止策を予算化し粛々と進める。
 外部に向けての対応策の公開ということになったら上記の資料が死ぬほど役に立つと思う。
 この項目、たった数行のことだけどね、大変だろうけど。


 これ以前、つまり事象発生する前に、自分や情報システム部門はどう考えてどういう仕組を構築してシステムを守ろうとしたいか、それを文章化して計画書や伺書、報告書という公的な文書として残しておいたらBestだと思う。まだそれがないんだったらそれをまず書こう。報告書や稟議書として簡単に決済されなくてもいいからまず書こう。そういう努力が病院を守るし自分も守る。
 なんとかそれが通ったらあとは着実に実行してゆくのみ。
 その途中で万一マルウェアに入られても「準備途上でした」と言える。それは「何もしてません、考えてませんでした」と言うより比べ物にならないぐらい状況が良くなるはずよ。
 データを失うかもしれないけど、刺される後ろ指の本数は減るし針のむしろの針の数も減るかもしれない。担当者としてつらい状況を緩和できるだろうし、もしかすると同情すら買うことが出来るかも。
 これはフザケているわけじゃないし笑い事でもない。

 計画書などで書く内容は出来もしないことを上げるのではなく、運用規程の強化等すぐ出来そうなことから始めてその後時間をかけて出来ることを積み上げてゆくように。その中で必要な機器やソフトの購入とそれに係る運用を絡めて実効性があるようにすること。
 文章はICTの言葉がわからない人間を相手にするのだから、平易な表現で要点を伝えることを心がけること。
 あと、最初は理解されないかもしれないけど、どんなに対応しても「絶対に侵入されないシステムは無い」ということを前提にすることをきっちりと説明することかな。(ネットワークを別に分けてても感染した事例はあるらしい)


 次回は障害/マルウェア対応の時間的なフローについて。

病院情報システムの障害対応/対マルウェア対応(2)障害レベルごとの対応マニュアル(横糸)

(前回からの続き)
 「障害レベルごとの対応マニュアル」はマトリックス形式で記載される。マトリックスの横軸が対応すべき各部門、縦軸が障害レベル。そのマトリックスの一つのマスごとにその事象発生時に様々な部門でやるべきことを記す。

 各部門とは外来、病棟、検査科や薬剤科、画像、栄養科などの各部門、OPE室、医事課やリハ、必要があれば臨工、中材等、病院の機能単位である。

 障害レベルというのは発生事象を病院診療での影響度で軽い順に並べたものである。
 軽いものから順に1)部門システムの停止。2)医事システムの停止、3)電子カルテシステムの停止、4)ネットワーク停止、5)電源喪失で考えている。医事システムの停止以上はBCPとも被る項目も多くなるのではないか。
 また障害レベルには6)マルウェア感染疑いがこれらとは別に定義される。マルウェア感染疑いはそれ以外の1)〜5)とは性質が異なるので章を改めて記す。

マトリックスの一つのマスについて

 マトリックスのマスについての考え方を以下に示す。

 例えば検査システムが停止した場合、検査自体を停止するのか、それとも機器を使用して検査自体は続行するのか。その際の診療現場からのオーダの受領方法、結果をどうやって診療現場に返すか。そう言った情報伝達の手段の検討。
 また、薬剤管理システム停止時はオーダの受領方法、調剤分包機や薬袋発行機にどうやってデータを渡すかなど。アンプルピッカーがあればそれへの対応。
 それ以外にも画像での造影剤使用時の同意書など、画像検査やOPE時に必要とされる分書類をシステムから出力しているなど。実際に電子カルテシステム等のシステムがダウンしている際、縮退運用中にその行為をするかどうかということも含めて検討した方が良い。
 ドキュメント類の多くは電子カルテシステム導入前に使用していた伝票の流用、結果票の流用になると思うが、電子カルテシステム導入から時間が経っている場合が多く看護師や医師、部署のスタッフの入職退職などでの人の入れ替えで伝票の入力方法などがすでに失伝している場合も多い。面倒だろうが過去のマニュアルの発掘するか新たに作成する必要がある。
 実際に事象が発生した場合に備えてマニュアルや伝票は印刷して常備した方が良い。よく聞くのは病棟などに予め準備していたんだけど、長い間使わなかったので散逸してしまったという話。もう一つは緊急時の伝票、マニュアル類をグループウェアやファイルサーバなどに保管していて緊急時に開こうとしたが、ネットワークが切れていたり電源喪失だったりで見ることができませんでしたという話。
 このような場合のために緊急時に必要な伝票やマニュアルは事務や医事課やカルテ保管スペースの隅に部署ごとにまとめて保管しておくようにして、緊急時には部署から緊急事運用切替の放送などを契機に取りに来るように取り決めておいた方がいいかもしれない。

 また、診療現場からのオーダの伝達や結果の返送以外にも電子カルテならばカルテ記載の問題がある。何らかの原因でその場で記載ができなかった場合の記載、オーダ内容、結果データを電子カルテに対してどうするかの検討は必要である。誰がどうするか。等。
 その運用に関しては電子カルテならば電子保存の3条件との整合性を考える必要がある。ベンダを交えて検討した方が良いと思う。

●各障害レベルの概要

 各障害レベルについては以下の通りである。

 

1)部門システムの停止

 部門システムの停止は各部門での主要システムの停止を扱う。
 検査システム、薬剤管理システム、RISやPACSなど、給食管理システム等の停止時の運用を扱う。
 部門システム障害以外にHIS内の各部門システムとのインタフェース部分の停止(一部ネットワークの停止含む)時はHISも部門システムも外見的に動いているがHISからのオーダ情報や部門システムからの結果情報のやりとりができない状況の場合もある。他にも再来受付機等の重要なサブシステム停止時の対応も検討した方が良い。(再来受付機の停止は受付運用に影響するので検討自体は次項の「2)医事システムの停止」と絡めて検討することになるかな)

 

2)医事システムの停止

 医事システムは受付や会計などの業務を担う。
 医事システムの停止は新患受付や再来受付の停止、つまり患者情報を病院情報システムへエントリできない状況や患者来院をシステムに知らせることができない状況が発生する。医事システムと電子カルテシステムの連動が前提になっているシステムの場合は新来患者情報が電子カルテにエントリできず新来患者の診療に支障をきたすことがあるので新来患者の運用は注意して検討する必要がある。
 再来受付機導入病院も再来患者のエントリができない状況になる。停止した再来受付機は受付で代用できるが医事課のスタッフに負荷をかける。
 受付は患者番号の発番他様々な診療行為の起点になるので、止まった場合にHISへの新患のエントリはどうするのか検討が必要である。
 以前の病院では元々1ヶ月に1回程度医事会計システムを再起動させていた。再起動に要する時間は1時間程度だが病院が救急指定病院なので再起動中にも患者が救急車で運ばれてくる。新規に来院した患者の場合医事システム再起動のためIDの発番ができないので困る。そこで別途システムを作って発番データと患者氏名などの情報を作成し、エンボッサでIDカードの作成を行った。臨時IDカード発行システムと言った。各部門システムも患者IDで管理していたので必要だったからである。
 電子カルテシステム導入時には医事会計システムと電子カルテシステムの通信インタフェースを臨時IDカード発行システムでエミュレートし医事停止時でも臨時IDカード発行システムから電子カルテシステムに患者属性情報が飛ぶようにしたため患者受付ができるようにした。
 これは24時間365日受け入れている救急病院だから必要だということで検討したが、全ての病院で必要なものではないだろう。
 そこまでするかどうかは別にしても医事停止時の患者受付の検討は必要である。
 また、会計ができない状況についても院内で予め決めておいた方が良い。

 医事システムは電子カルテシステムなどよりはるか以前から稼働しているので医事課内部でクリアできる問題は解決済みだろう。医事システム停止時には内金精算や次回来院時に精算としている病院も多いのではないかと思う。
 医事課の責任者不在時に混乱しないように予め内部で意識合わせしたほうが良い。

 

3)電子カルテシステムの停止
 診療部門と各部門の間の情報伝達が止まる。各種オーダが止まり結果の返送が止まり医事への送信が止まる。また、カルテの持つ記載機能が停止する。
 オーダに関しては診療部門と各部門間で使用されていた旧来の伝票運用に切り替わるのが通例だろうと思う。各部門と病棟、外来などと打ち合わせをして運用について検討する。
 また、電子カルテ停止時に発生した検査などのオーダ情報は再開時にどうなるのか。オーダ情報がない場合の結果情報は部門システムから受け取れるのか?また、医師や看護師ほかの記載については復旧後に入力する形になるのではないか。
 電子カルテベンダを交えて検討する必要がある。
 電子保存の3条件を満たすような運用や取り決めを検討する必要があるのではないか。

 電子カルテシステムからの診療情報が受け取れないことで会計処理が難しくなる。電子カルテの導入により電子カルテから医事システムに直接データが送られるようになるにつれて伝票から医事システムへのエントリをしたことがないスタッフが年々増える。慣れない作業は時間がかかり患者さんを待たせることになる。この場合の対応も内金精算や次回来院時に精算となるかもしれない。

 

4)ネットワーク停止

 病院の規模やシステム/ネットワーク構成と障害規模により対応が異なると思う。

 例えば各部門のネットワークが止まった場合、1)の各部門システム停止時の運用と同様となる。医事システム関連のネットワークが逝った場合は2)の医事システム停止時の運用と同様になる。電子カルテシステムサーバ関連のネットワークが逝った場合は3)の電子カルテシステムの停止時の運用となる。
 情報を提供する側のシステムサーバのネットワークが逝った場合の対応は1)~3)と同様になる。
 これは各部門システムサーバが部門にありその部門のネットワークが逝ってしまった場合の対応である。

 それ以外に外来や病棟などの診療側のネットワークが逝った場合は他の領域が元気に稼働しているがその領域だけすべての情報サービスが停止する。その診療単位のみ全ネットワーク停止と同じ対応になる。

 規模が大きい病院の場合などは情報システム部門がサーバ室にて一括管理していることがある。その場合に情報システム部門のネットワークが逝った場合には全部止まる。復旧までの間1)~3)の対応になるのかな?

 仮想環境やサーバ集約などでサーバ室に部門システムのサーバを集めている環境で部門側のネットワークが止まってしまった場合など、ややこしいケースはある。この場合も1)と同じ対応になるかな。

 それ以外にも例えば全体を統括しているL3スイッチが死んだとか。そうしたら全部止まる。対応的には1)~3)だと思う。
 診療系の情報収集に部門システムや医事システム、電子カルテ以外のものを使っている場合(exp.共有フォルダ内のファイル共有や院内HP上/グループウェアなどの情報)はそれらも逝ってしまうので覚悟は必要である。

 大規模ネットワークが死んでしまったらほんと大汗かくよ。
 戻らなかったらITに関わる病院機能は止まるからね。
 上に覚悟って書いたけど、本当に必要ですね。「覚悟」。自分がやらかしたわけじゃないのに(そういう場合もあるかもだけど)全病院から「お前何しとんねん」的な目で見られ、どやされるんだけどそれでも悪い情報を話さなければならない「覚悟」。

 ネットワーク構成によってはある部門のネットワークが止まり同時に特定の病棟のネットワークが止まったりする。この時の止まった原因は病棟側で外れていたネットワークケーブルを病棟にいた誰かが何気に壁のネットワークコンセントにプチッと挿した。同一ネットワークだったので見事なループを形成しブロードキャストストームが発生した。該当のVLANを持つSwitchの通信が溢れてSwitch配下にある病棟や部門のネットワークが止まった。ように見えた。実際、通信できないから止まったと同じだろう。
 今はループガードがあるSwitchがあるのでそれを上手く使えば防げることではあるけど、最近の製品動向を見てないからわからないなー。当時は高速で動かさなければならないSwitchでループガード機能を動かすと能力が低下するので機能を切っていたような気がする。

 ネットワーク障害は障害を起こしたネットワーク機器やネットワーク構成によって影響範囲がまるて変わってくる。自環境にあわせた対応を検討するべきである。

 もう一つ、電話でIP電話で運用している施設はネットワークが切れたら電話も切れる。
 自分が電話交換機をリプレースした病院ではそういった事態を避けるためにIP電話にせずにレガシーな電話回線のまま残した。もう一つの理由としてはナースコールのIP電話対応が事実上ナースコールの入れ替えになってしまうのでコスト的に問題になった。

 

5)電源喪失(停電)

 病院のシステム構成やネットワーク構成による。
 情報システムは基本的にサーバとネットワークとPCから成り立っている。そのどこが停電で止まってもシステムは稼働していると言えない。
 サーバ室はUPSや発電機で守ってもそれを各所と繋ぐネットワークはどうだろう。経路上のHUBは重要な場所だけでもUPSや発電機で電源供給されているだろうか?また、各所のPCに関しても同様である。

 また、そもそも電源喪失をした場合には病院の診療業務はどうなっているのか?どうするつもりなのか?現状を把握した上で病院側で決めておかないと電源喪失時の運用は決められない。

 同じ電源喪失でも、落雷や台風などの一時的な停電の場合はサーバやその他の最低限必要なPCなどは発電機回路からの電力供給を受けるようにして、一般商用電源から発電機にフェイルオーバーする時間を保証するためにUPSを設置していると停電中も最低限の業務は可能かもしれない。

 停電時でもシステムを動かし続ける選択をした場合、発電機の電力供給可能時間を超えて停電が長引くことも検討したほうが良い。
 情報システム部門内部でシステムシャットダウン手順の確立は必要だと思う。
 稼働中のサーバへ電力供給が停止した場合には復電後の再起動時にデータベースが上手く起動しないとかサーバ事態の損傷、OSの損傷などでシステムが再稼働できない可能性がある。
 電力供給されているうちにシステムを正常にShutdownするために予め全システムShutdownに必要な時間を検討したほうが良い。

 IP電話の場合はネットワークが止まると電話も繋がらなくなる。
 レガシーな電話交換機(今どきの交換機は中身はデジタルで動いてるんだけどね)は伝統的に内部にバッテリーを持っていることが多い。長時間停電した場合にバッテリーが切れるが、それまでは通話は可能である。


 これらの検討に際しては情報システム部門と各部門が協力して動かなければならない。検討にあたってお客さん気分の部署があればその部署は事象発生時には吠え面をかくことになりかねない。
 診療部門以外にも総務などの管理部門、病院上層部との意識合わせも必須だと思う(まぁ、なかなか難しいんだけども)。
 緊急時運用への切り替えってドえらいことなんだけど実質情報システム部門の一担当者が何の権限も根拠もなしに切り替えた、と言うのは組織運営上はあまり望ましいことじゃないだろう。実際にはシステムが稼働してなければICTを使った診療は望めないので事態に立ち至れば否応はないんだけど。診療部門が復旧を急ぐあまりに先走ることを留めるためにもシステム停止時の緊急運用開始、終了の権限を正式に貰っておいたほうが良いと思う。
 対応策策定前に上層部に方針を説明し、重要性を理解してもらい最終案は切り替え権限者の件も含めて稟議を通すなりの筋を通すのが病院にとっても担当者にとっても吉ではないだろうか。

 上に「覚悟」って書いたけど、予め「そう言ったこともありうるから検討してるんだよ」的なことを上に認識させるためにもまぁやっといた良いと思うよ。
 システムが使えない、患者を目の前にして検査結果も見れない、オーダも出せない、画像も見えない、言うなれば極限状態では不安に駆られた人々は石を投げつける相手を探そうとするからね。(遠い目...)

 次回はマルウェア感染疑い。

病院情報システムの障害対応/対マルウェア対応(1)

 病院情報システム(あえて医療情報システムとは言わないよ)にとって障害やマルウェア感染は重大事象である。そのような事態に立ち至らないように対策を打っておきたいし現に打っている施設も多いと思う。
 残念ながら人間が作り運用しているシステムなのでどんなに気をつけても障害はある。一時は嫌われていた言葉だが「想定外」もある。またマルウェアは様々な機会を捉えて侵入を図ろうとする。

 「なんとかなるよ」と思うかもしれない。実際なんとかなれば幸いである。

 ある日イキナリ事が起きる。

 「あなたのコンピュータに何が起こったんでしょう。あなたのコンピュータは暗号化されてしまいました。私に連絡したらもとに戻ります。そのためにはビットコインで...」的なメッセージが表示されたら?

 同じメッセージが表示されるPCがあっちでもこっちでも増えていって...。ディスクの中は同じような識別子のファイルだらけ。中身は見えない。そして頻々と電話が鳴り始める。

 或いは、

 平日10時頃の外来診療がピークを迎え始めた頃に、電子カルテがつながらないと言う連絡が入る。手元の電子カルテPCでログインしようとするとログインできる。ところが外来やら病棟各所から電子カルテの記載をしようとしたらエラーで弾かれる。オーダが登録できない、等の連絡が頻々と入り始める。

 どちらも電話がじゃんじゃん鳴って、「どうしたらいい!?」「早くなんとかして!」「診療できん!」とギャンギャン言われる。どうします?
 ストレスマックスである。めちゃくちゃうろたえると思う。
 現場も相当にうろたえているので相手のことが見えなくなっている。

 自分も以前にネットワーク障害の対応中に電話で立ち往生したことがある。
 ネットワーク障害と思しき障害が発生したので高い所に設置されている盤の中のSwitchを触ろうと脚立の上で作業していたらPHSが鳴って、如何に困っているかの長めのご講義(抗議でもいい)をされたことがある。脚立の上で数分間。PHSを持つ片手が塞がって肝心の確認作業ができない。何もできない。相手はうろたえてるから「対応中だから」と言っても聞こえないんですね。「今調べてますから」「あとどれぐらいで治る」(それを調べてるんだけど!!)

 事象が発生したら問題を解決し復旧させることが大切なのは当然である。しかし、当座必要なのは復旧までの見通しを診療現場や経営に提示することである。そして準備しておいた縮退運転に逃げ込む。それは診療現場で発生している混乱をいたずらに助長させないようにするためである。そのためにはある程度事象を想定して準備をしておいたほうが良い。

 100%の対応はできないにしても、予め縮退運転や復旧手順の定義を行い、診療や病院経営への影響を最小限度に抑える準備をすること。予め定義することで迷うことなく対応や復旧手順を進めるし、診療現場や経営などへ復旧までの見通しも示せる。

 そういった事前準備をするために検討を行うことで現状での不備を洗い出し、事前準備を深化させる。また、検討に診療現場や部門を巻き込むことで障害対応中の縮退運転についての意識付けが出来る。

 ただ、いきなり準備しろと言う話になった場合、領域があまりに広いので思考停止になる病院システム部門も多いと思う。

 昨今では「BCPを準備するように」と様々な機会に要求されてきていると思う。
 これはICTのBCPみたいなものである。自分の経験を交えて記するので対応の端緒になってくれれば幸いである。各施設ごとにシステムや運用は異なるのでローカライズを上手くやって欲しい。

・対応のための準備

 病院情報システムの障害対応では
1)病院情報システムの障害レベルごとの対応マニュアル
2)障害対応の時間的な処理フロー
を準備してきた。

 「1)病院情報システムの障害レベルごとの対応マニュアル」を障害対応の横糸とすれば「2)障害対応の時間的なフロー」は縦糸である。

 システム運用経験がある担当者は障害発生時の対応について問われたら「ああすれば良いこうすれば良い」と思い浮かぶであろう。が、余程肝が太いか障害慣れしてないと実際の事象発生に臨んだら狼狽して対応を誤る可能性は高い。それ故マニュアルとワークフローを作った。

 対応マニュアルやマニュアル作成中に発生した課題に対する対応策の検討があれば診療や病院経営に与える影響を最小化できると思う。(もちろん、影響を0にはできないが)

 準備した内容を説明する。

1)病院情報システムの障害レベルごとの対応マニュアル
 横糸の障害レベルごとの対応マニュアルは、該当の事象が発生した場合に各部署が行う運用(縮退運用)について定義して、事象発生時に病院業務を迷わず該当する縮退運用に移行させるのが目的である。
 以前在籍した病院で同僚と一緒に検討した。同僚はその後その内容で学会発表や医事関係の雑誌で記事を書いたりしていた。(今回の記事を書くにあたってこの部分は元同僚の了解はとったよ)
 彼と私は違う人間だし、彼の書いた記事は読んでないので書いている内容が異なるかもしれない。適宜自分の施設にあったように読み替えてもらったらいいと思う。

 

2)障害対応の時間的な処理フロー
 縦糸の障害対応のワークフローは主に情報システム部門が事象発生から復旧までに行うことをシリアルに並べ定義して、各ステージごとにやらなければならないことを漏らさず実施することや、検討することで発生する疑問や課題を予めクリアにしておくことが目的である。
 この縦糸をベースにシステム、或いはシステムの障害で毀損した病院機能の復旧の道筋を示す。
 今回提示する処理フローの初版は以前に実施された分野横断的演習で実戦経験済みである。

 

・準備したものを有効利用するために

 準備した対応マニュアルや処理フローを事象発生時に有効に利用できるようにするためには
3)作成後の演習
4)定期的な内容の見直し
が必要である。

3)作成後の演習
 これら横糸と縦糸は一度作ったら「あー、できたできた。終わったー」とせずに、実際に演習を行い運用してみて問題点の有無の確認を行う。経験上、担当者が集まって読み合わせをするだけでも意識合わせになるし改めて気付くことは多い。
 実際に演習することで動線の確認などもできる。

 

4)定期的な内容の見直し
 内容については数年に一回程度見直しを行うべきだと考える。病院が運営されていれば発生する機能やシステムの追加、更新、削除への対応である。

 

 正直、作成は結構面倒だと思う。が、準備することによって障害時の対応が円滑迅速になることが期待できるし、検討中に通常の業務内で行っている手順の見直しに繋がり、省力化に手助けになることもあった。

 次回は障害レベルごとの対応マニュアル(横糸)について示す。

病院入口での検温目的のサーモグラフィ導入について

 Covid19対応で体温測定を施設入り口でやっているところは多い。
 少し前に行った福岡市天神のデパートでも主な入り口には人を立たせ検温をやっていた。(あれからもう2ヶ月以上天神には行ってない)
 今、Covid19第3波で警戒レベルが上がっている病院も多いと思う。

 病院でも入院患者でクラスタが発生したら罹患した患者対応やら病棟での対応、外来閉鎖などが考えられ、Covid19のせいで前例のない減収が続く病院としては死活問題である。クラスタが発生した場合の対応とその後の対応での減収を考えたらせめて入り口での検温/問診によるスクリーニングで感染の可能性のある患者を引っ掛けて別に対応しようとする当然だと思う。

 ただ、検温/問診だけではCovid19感染者を院内に入れないようにするのはほぼ不可能なこともわかっている。
 もっと確実性が高いPCR検査等の他のCovid19の検出手段を来院者に全員に施すには手間や時間やお金がかかりすぎ現実的ではないので検温と問診という手段に頼らざるを得ない。

 検温するための職員がどこからともなく湧いてくるわけない。今いる職員を本来の業務から引っ剥がして代わり番こに風除室あたりに立たせることになる。一日何人かの有熱者を検出(それも概ねCovid19ではない)するのは本来業務が遅延する上に人件費がかかるし対応する職員も疲弊する。

 自分もやっていた。風除室に来院者が来るたびに猫なで声で「お熱測らせてくださーい」とか言って。二、三日に一回、30分から1時間程度立っていた。一日中狭苦しい情報システム室にいると気が滅入るので明るい風除室は自分的にはいい気晴らしになったが、他の殆どの部門では要員配置の関係などで業務上かなり苦しいところもあったようだ。
 そう言った状況で検温の手間を省くために注目されたのがサーモグラフィである。
 私が情報屋の分際で専門外のCovid19がどうのとか言ってるのはサーモグラフィ導入について検討しろと病院の上の方の方に命令され、感染制御をやっている他の病院スタッフと話をしながら検討したからである。

 昔のサーモグラフィは本当に表面温度を測ってそれをグラデーションや色分けして表示するだけのもので、病院に設置してもディスプレイに移ったそれらの画像を誰かがじっと見て判断するしかなかった。実用的ではないので、旧来のサーモグラフィを持っていた病院では今回使わなかった病院もあるらしい。
 当時より時代が進んでいることもあり、私は今回の検討はもっと高い機能を期待した。

 私が病院の入り口/受付に設置して意味があるサーモグラフィの条件としては以下のように考えていた。温度を測る機能は必要だが、それよりその後の運用を支援する機能も重視した。

1)有熱者を検知したらアラーム等で注意喚起できること。
 サーモグラフィを監視する目的だけの要員を割かないようにしたい。

2)複数の来院者が同時にサーモグラフィの画角内を通過する際に来院者各々を識別し各々の体温を個別に計測できること。
 病院では同時に複数の患者/付添の来院があるので。

3)サーモグラフィで検出した体温を同時に撮影しているビデオカメラの映像上の人物にオーバレイ表示することができ、どの人の体温が何度であると表示されること。予め設定された閾値より高い体温の人物と低い体温の人物は色分けされること。
 有熱者を特定するため。

4)有熱者検出時(アラーム発報時)に3)の画面を画面分割でしばらく画面上に保持できること。または人物特定のためその画面がすぐ呼び出せる機能でも良い。
 アラーム時にサーモグラフィが特定した有熱者対して声掛けなどで対応する職員が画面上で有熱者の顔などを確認/特定するため。

5)撮影した画像を一定期間保持する機能(レコーダなどで)があること。
 事後の確認のためで2W~4W程度保持できればいいのかな

 1)2)3)4)が出来たら有熱者検知は結構無人化できるのではないだろうか。

 前髪が長い人や帽子をかぶっている人、高齢者で腰が曲がって顔の正面が撮影できない人などはサーモグラフィでは検温できない。スクリーニングなのである程度仕方がないと割りきっていた。

 第2波の頃ぐらいから病院にいろんなベンダから連絡があった。また知り合いのベンダに提案可能なベンダを問い合わせてもらったりした。それで連絡があった複数のベンダのデモを見た。日本製の装置、海外製の装置などいくつかあった。

 日本製、海外製問わず1)ができる製品は多かった(できない製品もあった)。日本製で1)と3)が出来るものとか。一人ずつ装置の前に立たなきゃならないけど、それはそれで受付とか再来受付機とかと絡めた運用を考えればなんとかなるのかなと思った。(装置のがわが出来上がってたのでそれをなんとかすればであるが)あと、再来受付機と絡めて持ってきたベンダもあった。
 海外製で1)2)3)4)5)が全部実現されているものがあった。

 その海外製の全部実現されている製品だがその一社だけ機能的に突出していて、その社の製品は流石世界最大の監視カメラメーカの製品だなと思った。価格も手頃だし機種によっては日本のベンダがOEMしてたりする。
 広角で撮影できて顔認証技術で顔を検知して目の間か額で体温を測る。複数の人間を同時に処理できる。
 ネットワーク対応されていてカメラとPCを離して置くことも出来るし、3)の画像を大きく表示させるためのモニタを接続可能である。大きなモニタは来院者側に向けて来院者の体温を知らせることも出来るし受付内部で来院者の確認のために使うことも出来る。
 他にはレコーダも接続可能である、と至れり尽くせり。

 そのメーカの製品はメーカの本国では大規模に展開されていて監視カメラとして犯罪捜査とかそれ以外の用途にも使用されているらしい。
 実戦ですでに稼働している「人を認識する技術」、「顔を認識する技術」に赤外線での温度測定を付けている感じ。それ故、いざ発見した人物をユーザに知らせる技術には長けているなとか利用現場の運用でのニーズをちゃんと拾ってるなという感じ。

 その製品だが、米中の貿易戦争で米国が人種差別/弾圧に加担しているとして目の敵にしている企業の製品なので日本国内での今後の機器の入手やサポートの継続はどうなるのかなと思う。米国さんは目の敵にしている企業と取引がある企業を締め出す的な法律を成立させるとかの話をしており、それもあって米国追随の我が国での事業は今後はどうなるんだろうかな、と言うのがリスク。

 ちなみに、離れたところからサーモグラフィの画像を見るためにネットワークを使ってサーモグラフィとPCを繋ぐ際には自分だったら病院内のネットワークとは物理的に分けるか、せめてVLANを切って論理的に電子カルテなどの病院ネットワークとは分けるし、インターネットにつながるネットワーク設定もしないと思う。ちょっと怖いから念の為ね。

 イマイチな日本のメーカさんには価格面と機能面、頑張って欲しいものである。サーモグラフィだから温度計る、だけじゃなくてもっと利用現場での運用を考えて欲しいなぁ、と言いたい。(まぁ、半年ぐらい前の話なのですでに発奮した日本メーカが作っているかもしれないが)

 スクリーニングをすり抜けた感染者に関してはその病院がこれまで対応してるCovid19対策に依る。
 サーモグラフィでの対応は病院の対策の一つに位置付けられ、検温業務の軽減に資することで病院の負荷を軽減することになると思う。

 ここまで書いて情報システムのマルウェア対策と似ていることに気がついた。
 マルウェアが日進月歩の進化を遂げ防御側が100%確実に防御するのが困難になっている。今のマルウェア対策は侵入されないことも重要だが侵入されても大きな問題が発生しないように縦深がある防御をとることが推奨される。それはICT的な対応のみならず、運用やシステム構成、ネットワーク構成などでもそれに見合った対策を取ることである。複層的な防御を行うことで一番深いレベルを守るというふうに考えるようになっている。

 まぁ、何事にも絶対はないので、層を重ねて重要な部分まで届かないようにする。サーモグラフィは一般のCovid19感染対策にプラスする層の一つであるという認識である。

 

PS.サーモグラフィネタは「今頃言ってんの!?もう入ってるよ」的な話が聞こえてきそうな周回遅れみたいなネタかも知れないけど直近でやってきたことなので綴ってみた。

 

初回のご挨拶

 私はもうすぐ定年を迎える病院情報システム担当者である。
 病院以前の経歴としては、最初は金融、その後工場の生産管理システムやいろんなシステムの基本ソフト開発やミドルウェア開発、アプリケーション開発を行って来た。
 
 20数年前に病院に再就職し、医事システムからオーダリングシステム、電子カルテシステム等の病院のIT化の波に乗り、病院の情報システムにどっぷり頭のテッペンまで浸かってここまでやって来た。二年ほど前にそれまでいた1000床規模の大きな病院から100床規模の小さな病院に転職した。
 
 病院に入ってからここまで病院情報システム導入、バックオフィス系の導入、電源周り、ネットワーク周り等のインフラ周りから病院情報セキュリティまでいろんなことをやって来たけど、その経験をリタイアと共に墓まで持ってゆくのもなんとなくもったいない気持ちからこのページを立ち上げることにした。
 
 病院というところは多くの企業と違い医療に従事するために様々な資格を持った専門職が働いている。その職種を要員とする部署がある。IT化の進展に伴いそれらの職種ごとや彼らが使う機器ごとにシステムが導入され、それらは各システムごとにベンダやメーカが異なる。ユーザ認証方式もバラバラ、ネットワーク体系が異なるとか無線LANの暗号化方式が異なるとか、(そもそも暗号化してないとか!!)そういう事を平気でやってる。
 前にも書いた通り、病院って結構な種類のシステムが入っている。そこでバラバラとそういうことをやられたら病院情報の全体システムとしての状況は推して知るべしである。
 
 最初の病院では基本的に部署やベンダに対して病院で決めた管理状態に持ってゆくようにしていた。(ウルサイやつだとか頑固者だとか嫌われていたかもしれないけど、業務だから仕方がないよ)
 次の病院では前担当者が残してきた遺産のメンテナンス、最適化や更新を行ってきた。
 どちらの病院の場合も安全で診療が止まらないシステムを目指したつもりである。
 
 その経験の中で伝えられることがあれば綴って行こうと思う。
 
PS. 最初にこの手のBlogを書こうと思ってからすでに2年以上の歳月が過ぎた。気が乗らなかったり、他のことに気を取られていたからだけど、規模や機能が違う病院を2つ経験していろいろ幅が広がったのは良かったように思える。