本番の医療データに一括更新をかけるとき、何を確かめるか

システムを運用していると、保存済みのデータをまとめて書き換える必要が出てきます。新しい項目を既存のレコードに埋める、区分を付け直す、といった作業です。

一般的なシステムでも慎重に扱う操作ですが、医療データではさらに重くなります。 対象がひとつの医療機関の診療記録全体になりうるからです。

MENTRAで一括更新を行うときに必須にしている確認を、順に整理します。

① 対象を、医療機関ごとに数える

一括更新の前に、同じ条件でまずSELECTして件数を見るというのは基本です。ただし全体の件数だけを見ても足りません。

医療機関ごとに分けて数える必要があります。理由は、全体では一部でも、ある1施設にとっては全件になりうるからです。

やることは2つです。医療機関ごとに「影響する件数」と「残る件数」を並べて出し、残る件数が 0 になる施設がないかを確かめます。1施設でも 0 になるなら、その時点で手を止めます。

残りが0になる施設が出たら、そこで止めます。 その施設が本番で使われているなら、実行してはいけない条件だということです。

② 使い方は、施設ごとに違うと考える

同じテーブル、同じ列でも、施設によって埋まり方が違います。

たとえば、患者さんが問診に回答して作られたレコードと、職員が手で患者登録だけを行って作られたレコードでは、同じ列が埋まっていたり空だったりします。空だからといって不要なデータとは限りません。

「この値は使われていない」という前提を置く前に、全施設の実態を確かめます。 ひとつの施設の使い方だけを見て一般化すると、別の施設で正常なデータを消すことになります。

③ 更新日時が、勝手に書き換わっていないか

これは見落とされやすいところです。多くのデータベースでは、行が更新されると更新日時の列を自動で現在時刻に書き換える仕組み（BEFORE UPDATEトリガー）が入っています。

すると、一括更新をかけた瞬間に、対象の全行の「最終更新」が実行した時刻に揃います。 画面で「最終更新」を表示していたり、更新日時で並べ替えていたりすると、そこが一斉に壊れます。データの中身は正しいのに、いつ書かれたかという情報だけが失われます。

やっかいなのは、「更新日時は元の値のままにする」と明示的に書いても効かない点です。トリガーはその指定の後に評価されるので、上書きされます。

対処は、その行の更新日時を書き換えるトリガーを、その操作の間だけ止めることです。そして止めたあと、確実に戻す。戻し忘れは、それ自体が重大な事故になるので、戻ったことを機械で検証します。

④ 「意図してそうする」を、コードに残す

更新日時を現在時刻に揃えること自体が正しい場面もあります。新しい雛形を投入するようなケースです。

そのときは、明示的に「現在時刻にする」と書きます。 自動でそうなるのに任せるのではなく、意図としてコードに残す。こうしておくと、後から読んだ人が「これは意図的か、事故か」を判断できます。

書いていないものは、意図なのか漏れなのか区別がつきません。

⑤ 戻す手順を、実行の前に用意する

実行してから戻し方を考えるのでは間に合いません。逆の操作を行うSQLを、実行の前に書いて手元に置きます。

あわせて、可能なら1施設ずつ実行して、結果を確かめてから次に進みます。全施設を一度に処理すると、問題に気づいたときには全部に及んでいます。

⑥ 画面に、リアルタイムで伝わることを忘れない

最近のシステムは、データの変更を画面へ即時に反映する仕組みを持っていることがあります。この対象になっているテーブルに一括更新をかけると、行数ぶんの通知が一斉に発火します。

診療中の職員の画面で、意図しない反応が起きることになります。だから対象テーブルがその仕組みに載っているかを確認し、載っているなら深夜帯・低負荷の時間に実施します。

検証環境で通ったことは、本番の保証にならない

最後にひとつ。検証環境で問題なく通っても、本番で同じとは限りません。本番には、検証環境に存在しない使い方があるからです。

だから検証環境での実行は「必要条件」であって「十分条件」ではありません。本番では改めて、①〜⑥を通します。

---

こうした手順を運用ルールとして持っているのは、手順があれば人の記憶に頼らなくて済むからです。MENTRAでは、本番データへの破壊的な操作は自動でブロックし、複数件に影響する操作は影響範囲を事前に確認するルールで運用しています。

変更管理の考え方はセキュリティの考え方にまとめています。院内のシステム部門から運用体制について確認がある場合は、貴院の様式のままご回答しますのでお気軽にお申し付けください。