バックアップは、医療機関のセキュリティ対策のなかで最も投資対効果が高い領域です。侵入を完全に防ぐことはできませんが、確実に戻せる状態があれば、攻撃者との交渉に応じる必要はなくなります。そして2026年度診療報酬改定によって、この領域は算定要件にも直結しました。
ところが実務では、「バックアップは取っています」という回答の中身が医療機関ごとに大きく異なります。同じサーバ室内のNASに1世代だけ、本番と同じネットワーク上、認証情報も共通——この状態は、ランサムウェアの観点ではバックアップを取っていないのとほぼ同じです。公表されている被害事例で復旧に失敗した構造の多くが、まさにこれに当たります。
本記事では、加算の要件として何が求められているのか、要件を満たすとされる方式は具体的に何か、世代はどれだけ確保すべきか、そして最後に最も重要な論点である復旧試験について整理します。
免責:本記事は一般的な情報提供です。診療報酬の算定要件および疑義解釈の取扱いは、厚生労働省の告示・通知および地方厚生局の通知が正本です。実際の対応判断はそれらに基づいて行ってください。
加算1の要件になった「複数方式・一部オフライン」
まず制度の位置づけを押さえます。2026年度診療報酬改定で新設された電子的診療情報連携体制整備加算は、医療情報取得加算と医療DX推進体制整備加算を廃止・統合し、そこにサイバーセキュリティ対策の評価を組み込んだものです。診療録管理体制加算1にあったサイバーセキュリティ要件も本加算へ移管・統合されました。
入院に係る加算の要件は次の構造です。
| 区分 | 点数 | 要件 |
|---|---|---|
| 加算1 | 160点 | 共通要件 + 複数方式によるバックアップ(一部はオフライン保管) + サイバー攻撃等に対するBCP策定と訓練 |
| 加算2 | 80点 | 共通要件(ガイドライン準拠 + 専任の医療情報システム安全管理責任者の配置) |
つまり、加算1と加算2を分ける要素のひとつがバックアップ設計です。加算2の80点から加算1の160点へ上げるために何が必要かという問いは、実質的に「バックアップを複数方式にし、一部をオフラインにできるか」という問いになります。
ここで重要なのは、要件が「バックアップを取っていること」ではなく、**「複数方式であること」と「一部がオフラインであること」**を明示している点です。一つの方式で日次取得していても、それだけでは要件を満たしません。改定の全体像は 2026年度診療報酬改定の全体像 を、加算全体の構造は 医療機関のランサムウェア対策 をご覧ください。
3-2-1ルールとの対応
バックアップ設計の古典的な指針に3-2-1ルールがあります。
- 3 つのコピーを持つ(本番1つ+バックアップ2つ)
- 2 種類の異なる媒体/方式に保存する
- 1 つはオフサイト(別の場所)に置く
このルールが生まれたのは自然災害や機器故障を想定した時代ですが、ランサムウェアの文脈ではもう1つの条件が加わります。少なくとも1つは、本番から到達できない状態にあることです。オフサイトでも、同じネットワークから同じ認証情報で書き込めるのであれば、暗号化のリスクは残ります。
3-2-1ルールと加算要件の対応を整理すると次のようになります。
| 3-2-1の要素 | 加算要件との関係 | 実装上の注意 |
|---|---|---|
| 3つのコピー | 直接の要件ではないが世代管理で実質的に必要 | 本番+2系統が最小構成 |
| 2種類の方式 | 「複数方式」に対応 | 同一製品の設定違いは「複数方式」と言いにくい |
| 1つはオフサイト | 災害対策として必要 | 地理的分散はランサムウェア対策そのものではない |
| (追加)1つはオフライン | 「一部はオフライン保管」に対応 | ここが最重要。本番から到達できないこと |
オフサイトとオフラインは違う概念です。 遠隔地のデータセンターに置いていても、常時ネットワークで繋がっていればオフラインではありません。逆に、同じ建物内でも、取得後に物理的に切り離して金庫にしまえばオフラインです。加算要件が求めているのは後者の性質です。
要件を満たすとされる3つの方式
疑義解釈に基づけば、次のいずれの方式も要件を満たすとされています。自院の規模と運用体制に合わせて選ぶことになります。
方式1:外部媒体方式
RDX等の外部媒体にバックアップを取得し、別の場所で保管します。世代管理も併せて実施します。取得後に媒体を物理的に取り外すため、オフラインの要件を最も素直に満たせる方式です。
- 長所:オフラインであることが明確。仕組みが単純で、監査時の説明もしやすい
- 短所:媒体交換に人手がかかる。交換忘れが発生しやすい。媒体の劣化と保管場所の管理が必要
- 向くケース:中小規模で、担当者が日次の運用を回せる体制がある場合
方式2:自動転送方式(NAS等)
NAS等の機器へバックアップを自動転送し、常時ネットワークから切り離された状態で保管します。転送のときだけ接続し、それ以外は切り離すという運用です。
- 長所:人手による媒体交換が不要。取得漏れが起きにくい
- 短所:「常時ネットワークから切り離されている」ことを技術的にどう担保するかが設計の肝。設定次第では単なる同一ネットワーク上のNASになってしまう
- 向くケース:日次運用の人手を割けない医療機関。ただし設計と証跡の残し方に注意が必要
方式3:クラウド内方式
クラウドサービス内の論理的に切り離された領域へバックアップし、速やかな復旧が可能な状態にします。
- 長所:媒体管理が不要。遠隔保管を同時に満たせる
- 短所:論理分離の実装がクラウド事業者の機能に依存する。責任範囲の整理が必要
- 向くケース:既にクラウド型の電子カルテ・システムを利用している場合
方式選択の考え方:加算1が求めるのは「複数方式」ですから、上記から2つ以上を組み合わせるのが基本形になります。実務でよく見るのは、日次の自動転送+週次または月次の外部媒体という構成です。自動化で取得漏れを防ぎつつ、物理的に切り離されたコピーも確保できます。
クラウド方式を採る場合は、どこまでが事業者の責任でどこからが自院の責任かを文書で確認してください。医療機関のクラウドセキュリティ と 責任共有モデル が参考になります。事業者側の管理体制を見る観点としては、ISMS(ISO/IEC 27001)の全体像 も押さえておくと判断がしやすくなります。
世代管理をどう決めるか
「最新のバックアップがあればよい」という考え方は、ランサムウェアに対しては通用しません。侵入から暗号化の発動までに時間が空くことがあり、最新のバックアップが既に汚染されている可能性があるためです。過去に遡れる世代が必要になります。
世代数について確認できている目安は次のとおりです。
| 取得頻度 | 世代数の目安 | 備考 |
|---|---|---|
| 日次 | 少なくとも3世代 | 確認済みの目安 |
| 週次・月次 | 一概に示されていない | 病院規模やバックアップ方式によって異なるとされる |
日次で3世代というのは、あくまで最低ラインとして理解すべき数字です。3日前まで遡れるということは、侵入に3日以内に気づける体制があることが前提になります。気づくまでに時間がかかる可能性を考えれば、方式のいずれかで週次・月次のより長い世代を確保しておくほうが安全です。
設計の考え方として、次の3つを決めると議論がまとまります。
- RPO(どこまでのデータ損失を許容するか):日次取得なら最大1日分の診療記録が失われる。それを許容できるか
- RTO(どれだけの時間で戻すか):外来再開までに許容できる時間。これが方式選択を規定する
- 遡及可能期間(どこまで戻れるか):汚染されていない世代に到達できるか
医療機関の場合、RPOとRTOは診療科や業務によって異なります。電子カルテの参照ができれば診療は続けられるが、医事会計が止まると請求ができない、といった具合です。全システム一律ではなく、優先順位をつけた復旧順序を決めておくことが実効性につながります。この設計は サイバー攻撃を想定したBCP と一体で考えるべき領域です。
復旧試験をしていないバックアップは、無いのと同じ
本記事で最も伝えたいのはこの点です。
バックアップ設計の議論は、どうしても「どう取るか」に集中します。しかし実際の被害時に問われるのは**「戻せるか」**であり、両者は別の問題です。取得が成功していても復旧できない構造は、いくらでも存在します。
- バックアップジョブは成功しているが、対象から外れていたデータベースがあった
- 媒体は読めるが、復旧に必要なソフトウェアのライセンス情報が本番サーバにしかなかった
- 復旧手順がベンダーの担当者の頭の中にしかなく、その担当者に連絡がつかなかった
- 復旧に必要な管理者パスワードが、暗号化された電子ファイルに保管されていた
- 手順どおりに戻したが、想定の5倍の時間がかかり、その間の代替運用が決まっていなかった
これらは技術的な失敗ではなく、検証していないことによる失敗です。そして一度でも復旧試験を実施していれば、いずれも事前に発見できます。
復旧試験の設計は次の要素で構成します。
| 項目 | 決めること | 記録すること |
|---|---|---|
| 範囲 | どのシステムを対象にするか | 対象外にしたものとその理由 |
| 頻度 | 年何回実施するか | 実施日と参加者 |
| 環境 | 本番か検証環境か | 本番と異なる点 |
| 手順 | 誰がどの順序で何をするか | 手順書との差異 |
| 所要時間 | 目標時間 | 実測値。これが最も重要 |
| 判定 | どこまでできれば成功か | 判定結果と是正事項 |
とくに所要時間の実測は、BCPの前提そのものです。「1日で戻せるはず」という想定で紙運用の準備をしていたのに、実際には1週間かかるとなれば、備えるべき紙帳票の量も、応援要請の判断も変わります。
なお、加算1はBCPの策定と訓練の実施を要件としています。復旧試験は訓練の中核に位置づけられる要素です。バックアップ設計と訓練を別々の課題として扱わず、**「戻せることを証明する一連の活動」**としてまとめるほうが、院内の工数も証跡も効率的になります。
運用に落とすためのチェックリスト
自院の現状を点検する際の観点を整理します。
| # | 確認項目 | 確認の仕方 |
|---|---|---|
| 1 | バックアップ対象に漏れはないか | 電子カルテ以外(医事、部門システム、ファイルサーバ、設定情報)を個別に確認 |
| 2 | 方式は複数か | 「同一製品の別設定」ではなく、性質の異なる方式になっているか |
| 3 | 一部はオフラインか | 本番ネットワークから到達できない状態にあるか。図で説明できるか |
| 4 | 認証情報は分離されているか | 本番の管理者アカウントでバックアップ領域を削除できないか |
| 5 | 世代は十分か | 日次なら少なくとも3世代。遡及可能期間を説明できるか |
| 6 | 取得の成否を監視しているか | 失敗時に誰に通知が届くか。通知を見る人がいるか |
| 7 | 復旧試験を実施したか | 直近の実施日、所要時間の実測値、是正事項 |
| 8 | 手順は文書化されているか | 特定の担当者がいなくても実行できるか |
| 9 | 復旧に必要な情報は本番外にあるか | ライセンス、パスワード、連絡先、構成情報 |
| 10 | 委託先の役割は明確か | ベンダーがどこまで担うかを契約・SLAで確認 |
項目4と9は見落とされやすい論点です。本番環境の管理者権限でバックアップも削除できる構成は、権限が奪われた時点でバックアップも失われます。権限設計との接続については アクセス権限設計と特権ID管理 を、バックアップ領域への到達経路の管理は ネットワーク分離と資産管理 をご覧ください。
まとめ
- 2026年度改定で新設された電子的診療情報連携体制整備加算は、複数方式によるバックアップ(一部はオフライン保管)とBCP・訓練を加算1(160点)の要件としている
- 要件を満たすとされる方式は、外部媒体方式・NAS等への自動転送で常時ネットワーク分離・クラウド内の論理分離領域の3つ。複数方式が求められるため組み合わせが基本
- オフサイトとオフラインは別概念。遠隔地でも常時接続されていればランサムウェア対策にはならない
- 世代管理は、日次取得なら少なくとも3世代。週次・月次は規模や方式によるとされ、一概の目安は示されていない
- RPO・RTO・遡及可能期間の3つを決め、システムごとに優先順位をつけた復旧順序を用意する
- 復旧試験を実施していないバックアップは、あるとは言えない。 とくに所要時間の実測はBCPの前提であり、訓練要件とまとめて扱うのが効率的
自院のバックアップ構成が要件を満たしているか、ベンダー提案の内容が「複数方式・一部オフライン」に該当するかの判断に迷われる場合は、お問い合わせ からご相談ください。構成図の読み解きと、不足している論点の洗い出しをお手伝いします。
参考・出典
- 医療情報システムの安全管理に関するガイドライン|厚生労働省
- 医療情報システムの安全管理に関するガイドライン 第6.0版|厚生労働省
- 令和8年度診療報酬改定について|厚生労働省
- 情報処理推進機構(IPA)
※算定要件、世代管理の目安、方式の解釈は厚生労働省の告示・通知および疑義解釈が正本です。本記事の記載は執筆時点の理解に基づくもので、改定や解釈の更新により変わり得ます。