電子カルテの監査ログは、どう作れば証拠になるのか

電子カルテの要件を並べた資料には、たいてい「操作ログを保存すること」と書かれています。ところが保存しているだけでは、監査の場面で証拠になりません。

理由は単純で、ログそのものを書き換えられるなら、ログを残す意味がないからです。

「保存している」と「改ざんされていない」は別

操作履歴をテーブルに書き込むだけの実装だと、次の問いに答えられません。

ログの1件があとから書き換えられたとしたら、それを検知できるか
ログの1件があとから削除されたとしたら、欠けたことに気づけるか
ログの並び順が入れ替えられたとしたら、分かるか

どれも、記録があるだけでは分かりません。「そこにあること」と「そのままであること」は別の性質です。

記録どうしを、鎖でつなぐ

MENTRAでは、監査ログをハッシュチェーンで連結しています。仕組みは次のとおりです。

1件ごとに、その内容からSHA-256のハッシュ値を計算する
そのとき、直前の1件のハッシュ値も材料に含める
結果として、各レコードが「前の1件のハッシュ」と「自分のハッシュ」を持つ

こうすると、途中の1件を書き換えた瞬間にその先すべてのハッシュが合わなくなります。 1件消せば鎖が切れ、順番を入れ替えても合いません。書き換えを防ぐのではなく、書き換えたら必ず分かる状態を作るという設計です。

あわせて、連番を持たせて欠番も検知できるようにしています。ハッシュと連番の両方が通って初めて、整合しているとみなします。

起こりうること	追記するだけの実装	ハッシュチェーン＋連番
途中の1件が書き換えられた	検知できない	その先すべてのハッシュが合わなくなる
途中の1件が削除された	検知できない	鎖が切れ、連番が欠ける
並び順が入れ替えられた	検知できない	前後のつながりが合わなくなる

記録は消さない

もうひとつの前提が、物理削除をしないことです。診療記録は削除フラグで扱い、実体は残します。監査ログ自体は追記専用で、更新も削除もしません。

ここを緩めると、鎖の意味がなくなります。「消せる経路がひとつでもあれば、それは消される」という前提で設計しています。

並行して書き込まれたときに、鎖は壊れないか

実装してみて分かったのが、ここが一番の難所だという点です。

ハッシュチェーンは「直前の1件」を参照します。ということは、2つの操作が同時に起きたとき、両方が同じ「直前の1件」を読んでしまう可能性があります。そうなると、同じ位置に2つの続きができて、鎖が枝分かれします。

電子カルテは、複数の職員が同時に使うシステムです。診察中の医師と、病棟の看護師と、受付が、同じ瞬間に記録を触ります。同時実行は例外ではなく、常態です。

MENTRAではここに排他制御を入れて、鎖の末尾を読んでから書き込むまでの間に別の書き込みが割り込めないようにしています。「めったに起きない」ではなく「起きる前提」で作らないと、監査ログは静かに壊れます。

壊れていないことを、定期的に確かめる

そして、仕組みを入れたことと、実際に壊れていないことは別です。

MENTRAでは、チェーンの整合性を定期的に自動検証しています。ハッシュの連結と連番の連続性を通しで検査し、食い違いがあれば運用側に届きます。

「改ざんを検知できる構造にした」だけでは、検知が動いているかどうかは分かりません。平常時に何も起きない仕組みほど、生きているかを別途測る必要があります。

何が残っていると、監査で使えるのか

MENTRAの監査ログには、操作した方・日時・対象・操作の種類に加えて、変更前の内容と変更後の内容の両方が入ります。「更新された」だけでは、何がどう変わったかを説明できないためです。

これを画面から読める形にしているのが変更履歴の機能で、操作した方・種類・対象・期間で絞り込めます。AIによる自動保存と、人が手で行った操作は区別して表示されます。 下書きを作ったのが機械で、確定したのが人だからです。どこまでが機械の仕事だったのかが読めることは、記録を後から検証できる状態の一部だと考えています。

埋まっている欄が、いつも事実とは限らない

ハッシュチェーンが守るのは「記録があとから書き換えられていないこと」です。そのうえでもうひとつ、最初に書き込む値そのものが事実かという問いが残ります。

分かりやすいのが、機能を導入するときに過去のデータをまとめて初期化する場面です。「確認済み」を表す欄を新しく作るとき、導入前からある記録をすべて確認済みとして埋めることがあります。このとき確認した時刻の欄には、その処理を流した時刻が入ります。

欄は埋まります。画面にも日時が出ます。けれどその日時は、誰かがその記録を開いて確認した時刻ではありません。

欄	人が確認したとき	導入時にまとめて初期化したとき
確認済みか	はい	はい
確認した人	記録される	空欄（誰が確認したかは存在しない）
確認した時刻	その人が開いた時刻	処理を流した時刻（全件が同じ秒に並ぶ）

空欄は「分からない」と読めますが、埋まっている欄は「分かっている」と読まれます。 確認者が空欄なら、画面を見た方は「誰かは分からないのだな」と受け取れます。ところが時刻が入っていると、その時刻に誰かが確認したのだと読んでしまう。同じ1行の中で、片方の欄は正直で、もう片方の欄だけが饒舌という状態です。

MENTRAでは、この型の初期化をするときその行がどこから来たかを列で持ちます。 人が操作したのか、機能の導入時にまとめて入れたのかを値として区別し、後者は画面で時刻も名前も出さず「この機能の導入時に取り込み」と表示します。書き換えられないよう、由来の列も監査の対象に含めています。

監査の場面で問われるのは「いつ・誰が」です。答えられないものを空欄にするのは弱さではなく、正確さです。 埋まっている欄のほうが親切に見えますが、中身が事実でなければ、その1件だけでなく記録全体の信用が下がります。

記録を預かる側として何をしているかはセキュリティの考え方にまとめています。院内のチェックシートで監査ログの要件を問われる場合は、貴院の様式のままご回答しますのでお気軽にお申し付けください。