厚労省の経営管理編は、経営層に対して、定期的に管理状況に関する報告を受けて状況を確認すること、組織内において監査を実施すること、さらに安全管理を適切に維持するための計画を策定し、定期的な見直しと必要な改善措置を指示することを求めています。つまり、26日目の例外台帳、27日目の監査・立入検査対応、28日目の経営報告は、そこで終わりではなく、次の計画へ接続して初めて意味を持つ構造です。

同時に、厚労省のBCP手引きは、BCPは定期的に見直し、必要な項目を更新すること、その前提として事業者その他の関係者とのリスクコミュニケーションが必要だとしています。さらに、現行の第6.0版ページでは、令和7年5月版のチェックリストマニュアルとサイバー攻撃を想定したBCP策定の確認表等が公開されています。したがって、29日目で扱うべき主題は、「何を報告したか」ではなく、その報告から何を年度計画に入れるかです。

1. まず、改善計画を「すぐ直すもの」と「計画して直すもの」に分ける

実務上、例外台帳や監査結果をそのまま一枚の改善計画に並べると、優先順位が崩れやすくなります。厚労省のチェックリストマニュアルは、「いいえ」の項目に目標日を入れる運用を求め、少なくとも年1回の点検を求めています。一方、経営管理編は、経営層に計画の策定と改善措置の指示を求めています。これを実務へ落とすなら、改善計画は少なくとも
①短期で是正できる運用改善
②年度内に実施する案件
③複数年度で更改が必要な案件
の3層に分けるのが分かりやすいです。
この3層整理そのものは、制度文書の固定分類ではなく、現行資料を計画実務へ落とした専門家の見解です。

たとえば、未使用ポート停止、接続元制限、不要アカウント削除、ログ確認手順の明文化のような項目は、比較的短期の運用改善に入りやすい一方、二要素認証の全面実装、EOS機器更改、ネットワーク再設計、クラウド契約見直しのような項目は、年度計画または中期更改計画に乗せる必要があります。ここで挙げた具体例は、厚労省が求める脆弱性対策、認証、台帳管理、契約管理、EOS対応を、計画立案向けに並べた専門家の見解です。

2. 年度計画の材料は、例外台帳から「残留リスク」を抽出して作る

26日目で再設計した例外台帳の価値は、件数管理ではなく、残留リスクの可視化にあります。厚労省は、脆弱性情報を継続収集し、事業者に実施可否を確認し、難しい場合には代替策を講じるよう求めています。また、チェックリストマニュアルは、未対応項目に目標日を持たせる考え方を採っています。したがって、年度計画へ上げるべきなのは、例外台帳の全文ではなく、たとえば
再判定予定日を過ぎた例外
EOSを理由に継続中の機器
外部接続点に関わる未適用案件
代替策だけで延命している重要システム
のような、経営判断が必要な残留リスクです。これは厚労省資料を計画策定向けに再構成した専門家の見解です。

このとき重要なのは、年度計画の項目を「未対応件数」で書かないことです。経営層が判断しやすいのは、何が危ないかではなく、何をいつまでに解消し、解消できない間は何で守るかです。したがって、計画項目は少なくとも対象、残留リスク、暫定措置、期限、責任者で表現する方がよく、これは経営管理編の定期報告・監査・改善措置の流れとも整合します。

3. 優先順位は「件数」より「診療影響」と「外部露出」で決める

厚労省のBCP手引きは、BCP策定時にリスク分析が重要だとし、事業者等とのリスクコミュニケーションを求めています。また、システム関連事業者やサービスの状況については、ソフトウェアやファームウェアのアップデート状況、脆弱性対応状況、サービスの機密性・可用性、規約内容の変更状況などを定期的に確認し、必要なら契約変更等の対応を行うことが示されています。したがって、改善計画の優先順位は、単純な件数順ではなく、少なくとも診療継続への影響、個人情報・重要情報への影響、外部接続点・保守経路への露出、ベンダー依存度と契約変更の必要性で見る方が実務的です。
この4軸は制度文書の固定項目ではなく、現行資料にあるリスク分析、サービス状況確認、契約変更の考え方を、優先順位付けへ落とした専門家の見解です。

この整理に立つと、同じ「未対応1件」でも重さが変わります。たとえば、院内限定で使う周辺端末の運用改善と、VPN・FW・外部保守回線・クラウド規約変更に関わる未対応では、経営判断の重みが違います。29日目では、この違いを「情シス目線の件数」ではなく、病院運営目線の優先順位で書くのがポイントです。

4. 年度計画には「実施項目」だけでなく「確認項目」を入れる

厚労省の現行資料で見落としやすいのは、改善計画が「作業一覧」では足りないという点です。システム関連事業者やサービスについては、アップデート状況、脆弱性対応状況、機密性・可用性、規約変更状況を定期的に確認し、必要に応じて対応することが求められています。つまり、年度計画には「MFA導入」「EOS更改」だけでなく、ベンダー規約変更確認、サービス可用性条件の確認、保守契約条件の見直し、脆弱性情報確認ルートの点検のような確認系タスクも必要です。

この視点を入れると、年度計画は「一度実施したら終わり」ではなく、変化を監視する計画に近づきます。特にクラウドやSaaSを使う医療機関では、院内の設定変更だけでなく、事業者側の仕様変更や規約変更もリスク要因になり得るため、この箱を抜くと計画が机上化しやすくなります。

5. 中期更改計画は、EOSと高依存サービスを中心に作る

厚労省は、脆弱性やEOS対象機器が攻撃対象となり得ると説明しています。また、経営管理編は、経営層に対して改善措置を指示する責任を課し、サービス状況の確認では必要に応じて契約変更等も視野に入れています。したがって、年度計画だけで解決しない案件、特にEOS機器、ベンダー未対応が長引く機器
保守依存度が高い機器、クラウド規約・責任分界の見直しが必要なサービスは、年度計画ではなく中期更改計画へ上げるべきです。
この「年度計画と更改計画を分ける」という考え方は、厚労省の改善措置・契約変更・EOS管理を実務へ落とした専門家の見解です。

ここでのポイントは、EOSは例外台帳で抱え続ける案件ではなく、計画へ昇格させる案件だということです。29日目の記事では、この一線を明確に書くと、26〜28日目とのつながりが良くなります。

6. 計画は、次の年次点検とBCP見直しで必ず検証する

チェックリストマニュアルは、少なくとも年に1回は点検することを求め、BCP手引きは、BCPは定期的に見直し、必要な項目を更新することを求めています。したがって、改善計画は策定した時点では未完成で、次回点検でどこまで進んだか、BCPや規程へ反映されたかを確認して初めて閉じます。

このため、実務上は計画項目ごとに完了、継続、更改計画へ移管、見直し（要件変更）のどれで閉じるかを決めると運用しやすくなります。
この4区分は公的資料の固定用語ではなく、年次点検と定期見直しの要求を、計画管理へ落とした専門家の見解です。