電子カルテ更新時のセキュリティ要件｜移行期が最も危ない

電子カルテの更新は、多くの医療機関にとって5〜10年に一度の大仕事です。要件定義、機能比較、費用交渉、そして移行と稼働。プロジェクト管理の議論は尽きないのですが、セキュリティの観点から見ると、この期間は通常運用よりはるかに危険な状態にあります。

理由は単純です。移行期には、平常時にはあり得ないことが次々に起きます。全患者データが一度に取り出され、外部媒体に載って移動します。ふだん院内にいない移行業者の技術者が、本番データに触れます。新旧2つのシステムが同時に動き、権限管理が二重になります。そして最後に、患者データが入ったままの旧サーバと旧媒体が院内に残ります。

これらはいずれも「移行だから仕方ない」で済まされがちです。しかし、移行期に何を要件として決めておくかは、更改後の10年のセキュリティ水準を決めます。本記事では、移行の3つの局面——データの持ち出し、並行稼働、旧システムの廃棄——ごとに、発注側が押さえるべき要件を整理します。移行の技術的な進め方そのものは 電子カルテのデータ移行ガイド を、調達要件全体は 医療情報システムの調達要件にセキュリティを入れる をご覧ください。

免責：本記事は一般的な情報提供です。診療録等の保存義務および外部保存の取扱いは関係法令と厚生労働省の通知・ガイドライン本文が正本です。契約条項については顧問弁護士にご確認ください。

移行期に平常時と何が違うのか

まず、何が変わるのかを整理します。

**「1件の事故で全患者が影響を受ける」**という一行が、移行期の本質です。通常運用での情報漏えいは、往々にして特定の患者・特定の部門に限られます。移行期の事故は、範囲が全件になります。同じ注意力では釣り合いません。

局面1：データの持ち出し

移行では、旧システムからデータを抽出し、変換し、新システムへ投入します。この過程でデータは必ず本番環境の外に出ます。要件として決めておくべきことは次のとおりです。

最も抜けやすいのが「中間ファイルの削除」です。 移行作業では、抽出したCSV、変換スクリプトの出力、エラー確認用の抜粋、検証用のサンプルなど、多数の中間ファイルが生まれます。これらは作業者のPCやファイルサーバに散らばり、プロジェクト終了とともに誰も管理しなくなります。**「移行完了後30日以内に、抽出データおよび作業過程で生成した全ての中間ファイルを削除し、削除完了を書面で報告すること」**という要件を、契約に入れてください。

作業者の特定も重要です。移行は繁忙期にあたるため、事業者側で応援要員や協力会社の技術者が入ることがあります。これ自体は避けられませんが、誰が本番データに触れたかを記録に残せる状態は維持すべきです。事前の名簿提出と、変更時の通知を要件にしてください。再委託の把握については 医療機関のサプライチェーンリスク と 事業者に確認すべき質問リスト を参照してください。移行業者側が自社の要員と委託先をどう管理しているかを第三者に示す枠組みとしては、ISO/IEC 27001（ISMS）があります。認証の意味と適用範囲の読み方は ISMS（ISO/IEC 27001）とは｜ヘルスケア企業のための完全ガイド をご覧ください。

検証環境に本番データを置くかどうか

移行の検証は、本物のデータでなければ意味がない場面が多くあります。氏名の文字化け、長い病名の切れ、旧システム固有の入力パターン——これらはテストデータでは出てきません。

一方で、検証環境は本番と同じ管理水準にないことがほとんどです。ここが移行期の典型的な穴になります。実務上の落としどころは次のようなものです。

1. 検証環境を本番と同等の管理下に置く（ネットワーク分離、アクセス制限、ログ取得）
2. 検証に使うデータを期間・診療科・件数で絞る
3. 検証環境のデータを検証完了後ただちに削除し、削除を記録する
4. 検証環境へのアクセスを作業者を限定して付与し、作業終了時に削除する

「匿名化すればよい」という案は、移行検証では機能しにくいことが多い点に注意してください。氏名・病名の表示崩れを確認する作業では、そのデータ自体が検証対象だからです。匿名化より、期間を絞って管理下に置き、速やかに消すほうが現実的です。

局面2：新旧の並行稼働

多くの更新プロジェクトでは、一定期間、新旧2つのシステムが同時に使える状態になります。旧システムは参照専用、新システムは入力用、といった運用です。この期間に生じる論点は次のとおりです。

「終了の判断」が最大の問題です。並行稼働は、当初「3か月」と計画されていても、現場から「あの時期のデータを見たい」という声が出続けるため、延びます。そして延びた旧システムは、保守契約が切れ、パッチが当たらず、誰も管理していない状態でネットワークに接続され続けます。

公表されている被害事例に共通する構造として、管理が手薄になった機器やシステムが侵入口になったパターンが繰り返し指摘されています。並行稼働の延長は、この構造をそのまま作り出します。

対処は2つです。第一に、並行稼働の終了日を計画段階で決め、延長には院内の承認手続を要する設計にすること。第二に、参照が必要なデータを新システムまたは別形式で保持する手段を、移行要件に含めておくことです。後者があれば、旧システムを残す必要そのものがなくなります。ネットワーク上の資産把握については ネットワーク分離と資産管理 をご覧ください。

局面3：旧システムと旧媒体の廃棄

更新プロジェクトの最後に残るのが、患者データが入ったままの旧サーバ、旧端末、バックアップ媒体です。プロジェクトが終わり、担当者の関心が薄れた頃に残るため、最も放置されやすい局面です。

実務上のポイントは3つです。

1. 廃棄を委託する場合、処理の証明を受け取る

産業廃棄物として処理を委託する場合でも、記録媒体については消去または破壊の証明を別途求めてください。マニフェストは廃棄物の処理を証明するもので、データ消去を証明するものではありません。

2. 「回収」と「消去」を分けて管理する

回収された媒体が倉庫に積まれたまま数か月、というのはよくある状態です。回収と消去を別の工程として台帳で管理し、それぞれ完了日を記録してください。

3. 旧媒体の台帳を移行開始前に作る

廃棄の段階で台帳を作ろうとすると、何がどこにあったか分からなくなります。移行開始前に、旧システムに関係する機器・媒体の一覧を作成しておくと、廃棄漏れが防げます。可搬媒体の管理全般は USBメモリ・可搬媒体の管理 で扱っています。

契約と要件に落とす

ここまでの内容を、契約・仕様に落とすと次のようになります。移行は保守契約とは別の契約になることが多いため、移行契約のほうに書く必要がある点に注意してください。

旧システムのベンダーからデータを取り出す場面では、返還形式と費用が交渉の焦点になります。独自形式でしか出せない、返還作業が高額、といった状況は、更改の直前になってから解決できるものではありません。新規導入時に「標準的な形式での出力が可能であること」を要件化しておくことが、次の更改を楽にします。この点は 事業者に確認すべき質問リスト と クラウド事業者の選定基準 でも扱っています。

なお、更新を機にセキュリティ体制を見直すのであれば、2026年度診療報酬改定で新設された電子的診療情報連携体制整備加算の要件を、新システムの調達要件に織り込むのが合理的です。複数方式によるバックアップ（一部はオフライン保管）やBCPの策定・訓練は、システムの構成に依存します。医療機関のバックアップ設計｜3-2-1ルール、サイバー攻撃を想定したBCP、2026年度診療報酬改定 をあわせてご覧ください。

まとめ

電子カルテ更新時のセキュリティについて、押さえるべき点は次のとおりです。

1. 移行期は全患者データが一括で動く期間。1件の事故の影響範囲が通常運用と桁違いになる
2. 持ち出しでは中間ファイルの削除が最も抜ける。削除期限と削除報告を契約に書く
3. 検証は期間を絞って本番同等の管理下に置き、速やかに消す。匿名化は移行検証では機能しにくい
4. 並行稼働は終了日を計画段階で決める。延長した旧システムが放置されて侵入口になる構造は繰り返し指摘されている
5. 廃棄は回収と消去を分けて台帳管理し、消去・破壊の証明を受け取る。マニフェストは消去の証明ではない
6. 旧媒体の台帳は移行開始前に作る。廃棄段階で作ろうとしても把握できない
7. 移行は保守契約と別契約になることが多い。移行契約のほうに要件を書く

更新プロジェクトは、要件定義から稼働まで1年以上かかることも珍しくありません。セキュリティ要件を後工程で足そうとすると、費用と工期の再交渉になります。要件定義の段階から整理しておきたい場合は、お問い合わせ からご相談ください。

参考・出典

• 医療情報システムの安全管理に関するガイドライン｜厚生労働省
• 医療情報システムの安全管理に関するガイドライン 第6.0版（本文PDF）｜厚生労働省
• 令和8年度診療報酬改定について｜厚生労働省
• 情報処理推進機構（IPA）
• 個人情報保護委員会

※ガイドラインの要求事項および診療報酬の算定要件は改定・疑義解釈により変わります。契約条項の効力は適用法令と個別契約によります。最新の公表資料をご確認ください。