医療システムの異常を、気づける形で見張るには

医療システムでは、異常に早く気づくことが求められます。カルテが開けない、記録が保存されない、音声の処理が止まっている。現場が気づいて連絡してくるより先に、こちら側が知っているのが望ましい状態です。

そこで監視と通知の仕組みを入れるわけですが、ここには入れただけでは解決しない問題があります。

通知は、出しすぎると読まれなくなる

まず起きるのが、通知が多すぎる問題です。

異常を漏らしたくないので、判定をゆるくします。すると軽微なものまで通知され、毎日のように警告が届きます。毎朝それが出ていると、人は読み飛ばすようになります。

そして本当に重い異常が起きたとき、その1件も同じように読み飛ばされます。狼少年になった監視は、無いのと変わりません。

だから通知は、出す条件を絞るほうに倒します。「異常かもしれない」ではなく「これが出たら対応が要る」だけを通知する。判断が要るものは、人が見に行く場所に置いておきます。

通知が来ない日は、正常なのか、壊れているのか

絞ると、次の問題が出ます。平常時は何も通知されないので、仕組みが生きているのか死んでいるのかが分かりません。

監視の仕組み自体が止まっていても、画面上は「異常なし」と同じに見えます。沈黙は、正常と故障の両方を意味します。 これは監視で最も危険な状態です。

MENTRAでこれを実測したときに分かったのは、「通知が0件だった」という事実からは何も判定できないということでした。

だから、動いたことを別に記録する

対処は、判定が実行されたこと自体をログに残すことです。

異常があったかどうかとは別に、検査が走ったことを記録する
検査の実行そのものが途絶えたら、それを異常として扱う
「異常0件」と「検査が動いていない」を、別の状態として区別する

3つ目が要点です。この2つを同じ表示にしてしまうと、永久に原因に辿り着けません。

同じ理屈は、失敗を握りつぶす関数にも当てはまります。エラーのときに空の配列を返すような関数を判定の入力に使うと、「異常なし」と「確認できなかった」が同じ結果になります。原因が違うなら、出す文面も変えます。

画面に出ていること	実際に起きていること	区別するために残すもの
通知が0件	異常が無かった	検査が走った記録が続いている
通知が0件	監視そのものが止まっている	検査が走った記録が途絶えている
「異常なし」	確認できなかった（失敗を握りつぶした）	確認できなかったことを、別の文面で出す

医療システムでは、遅れが実害になる

一般的なシステムなら「翌営業日に対応」で済むことも、医療では違います。

診察は待ってくれません。訪問看護は次の訪問先へ移動します。その場で使えないことが、そのまま業務の停止になります。だから、検知してから人が動き出すまでの時間そのものを短くする必要があります。

MENTRAでは、システムの異常を自動で検知して開発・運用チームへ即時に通知する監視を常時稼働させています。あわせて、対応が始まらないまま放置されていないかを見張る仕組みも持っています。通知が届いても、誰も動いていなければ検知した意味がないためです。

「何も起きていない」を、どう確かめ続けるか

監視を入れたあと、それが効いているかを確かめる機会は、めったに来ません。 異常が起きなければ、試されないからです。

だから重要な守りは、意図的に壊して赤くなることを確かめます。 本番で動いているものではなく、複製を使って、守りが実際に働くかを見ます。

見るのは「そうなるはずの値」ではなく、実際に渡っている引数と、実際に出た文字列です。「たぶん動く」と「動くことを確かめた」の差は、異常が起きた日にしか現れません。

数えるときは、「何の異常か」まで分ける

見張りの話には、もうひとつ表と裏があります。異常に気づくことと、気づいた異常を数えることは別で、後者を雑にやると、見張りそのものが二次被害を作る側にまわります。

分かりやすいのがログインの失敗回数です。多くのシステムは、同じ利用者が短時間に何度も失敗したら一時的に受け付けを止めます。総当たりを防ぐための、ごく普通の守りです。

ところが「失敗」をひとまとめに数えると、そこには性質のまったく違うものが混ざります。

実際に起きたこと	ひとまとめに数えると	本当は
パスワードが違う	失敗1回	✅ 数えるべき
認証基盤が一時的に応答しない	失敗1回	❌ 利用者は何も間違えていない
こちらが出した回数制限に当たった	失敗1回	❌ すでに止めている。二重に数えている
通信が届かなかった	失敗1回	❌ 入力すら届いていない

上の3つを数に入れると、外の不調が続いているあいだ、こちらが自分で締め出しを重ねていくことになります。利用者から見れば、繋がりにくいうえに「あと数回で使えなくなります」と警告される状態です。 いちばん困っているときに、こちらの守りが追い打ちをかける。

MENTRAでは、失敗を入力の誤り／接続できなかった／回数制限／サービスが応答しないの4種類に分け、 回数として数えるのは「入力の誤り」だけにしています。画面に出す文面も種類ごとに変えます。「パスワードが違います」と「いま繋がりにくくなっています」は、利用者が次にとる行動がまったく違うためです。同じ文面にしてしまうと、通信が復帰すれば直る状況で、利用者はパスワードを疑い続けることになります。

🔴 ただし、分類が付かなかったものは「数える」側に倒しています。 判定に漏れがあったとき、締め出しが甘くなるほうが、余計に数えるより危ないからです。安全側がどちらかは、守りごとに決めておく必要があります。

もうひとつ、この手の分岐にはテストが効かなくなる落とし穴があります。「数えない」条件を2つの書き方で二重に塞いでいると、片方を壊しても、もう片方が拾ってしまい検査は緑のままです。守りが1枚素通りしていることに気づけません。1つの条件につき、それだけが効く入力を1つ用意して、故意に壊して赤くなるところまで確かめています。

稼働の実績

MENTRAでは、サービス開始からこれまで重大な情報漏えい・データ消失は発生していません。 毎日の自動バックアップを取得し、障害が起きた場合の復旧の目標値（8時間以内に復旧・失われるデータは最大でも直近24時間分）を定めて運用しています。

監視と復旧の考え方はセキュリティの考え方にまとめています。院内のシステム部門から可用性や監視体制について確認がある場合は、貴院のチェックシートの様式のままご回答しますのでお気軽にお申し付けください。