3省2ガイドラインとは何か

Yuki

11 分前

読了時間: 10分

「医療情報を取り扱う情報システム・サービスの提供事業者における安全管理ガイドライン第2.0版」は、2025年3月28日に総務省・経済産業省が公表した、医療情報システムを提供するベンダー・SaaS事業者・クラウド事業者等のための安全管理ガイドラインです。第2.0版では特に、①対象事業者の明確化、②医療機関と事業者の責任分界・合意内容の明確化、③リスクコミュニケーションの実効化が大きく強化されています。パブリックコメント

1. まず、「3省2ガイドライン」との関係

現在の医療情報セキュリティは、大きく2本のガイドラインで整理されています。

ガイドライン	主な対象
厚生労働省「医療情報システムの安全管理に関するガイドライン第6.0版」	病院、診療所、歯科、薬局、訪問看護、介護事業者等
総務省・経産省「医療情報を取り扱う情報システム・サービスの提供事業者における安全管理ガイドライン第2.0版」	医療情報システム、SaaS、クラウド等の提供事業者

この2つを一般に「3省2ガイドライン」と呼びます。

つまり、

医療機関側→ 厚労省ガイドライン

システム提供者側→ 総務省・経産省ガイドライン

という関係です。

ただし両者は別々ではありません。

事業者側には、

医療機関が厚労省ガイドラインを遵守できるようなシステム・サービスを提供する

という考え方が求められています。第2.0版も、事業者が医療機関側の安全管理ガイドラインに対応できるよう設計することを明記しています。パブリックコメント

2. 第2.0版の最大の特徴

第2.0版を一言でいうと、

「セキュリティ機能を実装するだけでは不十分。誰が何を管理し、事故時に誰が何をするかまで医療機関と明確に合意してください」

という方向に大きく進んだものです。

改定履歴でも、第2.0版の目的を

対象事業者の明確化
事業者・医療機関等間の合意内容の明確化
リスクコミュニケーションの実効化

としています。パブリックコメント

特に重要なのは、

「共通理解」＋「明示的な合意」

という考え方です。

3. どんな事業者が対象なのか

ここは非常に重要です。

第2.0版では対象を大きく3種類に整理しています。

① 医療機関との契約に基づいて医療情報システム等を提供する事業者

例えば、

電子カルテ
Web予約システム
クラウド型問診
医療機関向けSaaS
レセコン
PACS
画像管理
診療情報共有システム
医療データ保存サービス

などです。

② 医療機関と直接契約していなくても、システムに必要な資源・役務を提供する事業者

ここが第2.0版で特に重要です。

例えば、

病院
 ↓
SaaS事業者
 ↓
AWS / Azure / Google Cloud
 ↓
データセンター等

という構造の場合、

病院と直接契約しているSaaS事業者だけではなく、

PaaS・IaaS等を含むサプライチェーン全体

を考慮する必要があります。

ガイドラインは明確に、

医療情報システム等に必要な資源や役務の提供に係るサプライチェーン全体

についてリスクマネジメントするよう求めています。パブリックコメント

③ 患者の指示で医療機関から医療情報を受け取る事業者

代表例は、

PHR
健康管理アプリ
患者向け医療情報連携サービス

などです。

したがって、

「病院から委託されていないから対象外」

とは限らないところがポイントです。パブリックコメント

4. 単なる「個人情報」ではなく「医療情報」が対象

対象となるのは、

医療に関する患者情報

です。

典型的には、

氏名
生年月日
患者ID
診療情報
診断名
処方情報
検査結果
画像
診療録
歯科情報
医療従事者が作成した患者情報

などです。

個人情報保護法だけでなく、

医師法
医療法
健康保険法
e-文書法
個人情報保護法

等との関係も出てきます。パブリックコメント

5. 第2.0版の中心は「リスクベースアプローチ」

非常に重要な考え方です。

以前のセキュリティガイドラインは、

○○を実装しなさい○○を暗号化しなさい

という要求事項型になりやすいものでした。

第2.0版は、

リスクを洗い出し、そのリスクに応じて対策する

という「リスクベースアプローチ」を採用しています。

ガイドライン自身も、

一律に要求事項を定めることはせず、リスクベースアプローチに基づくリスクマネジメントプロセス

を採用するとしています。パブリックコメント

基本プロセスは、

①リスク特定↓②リスク分析↓③リスク評価↓④リスク対応方法の選択↓⑤リスク対応策の設計・評価↓⑥リスクコミュニケーション↓⑦継続的な見直し

です。

ISO 31000やISO/IEC 27001等の考え方を参考にしています。パブリックコメント

6. 特に重要なのが「責任分界」

医療システムでよくある問題が、

「これは病院が管理するのか、ベンダーが管理するのか？」

です。

例えば、

項目	医療機関	SaaS事業者
職員アカウント登録	○	システム提供
パスワード管理	○	機能提供
サーバOS更新		○
アプリ更新		○
DBバックアップ	契約次第	○
クラウドインフラ		○またはクラウド事業者
職員退職時のID削除	○	機能提供
インシデント検知	双方	双方
障害復旧	契約次第	○
患者への説明	○	支援

といった責任分界を決めます。

ガイドラインも、

医療機関等との役割分担を明確化すること

を強く求めています。パブリックコメント

例えば、

高度なアクセス制御を実装していても、

ID：doctor01
Password：123456

を端末に貼っていれば意味がありません。

このため、

システム側の安全対策

だけでなく、

医療機関側の運用

まで含めて設計します。

7. 「共通理解」と「明示的合意」

第2.0版で非常に重要になった部分です。

事業者は医療機関と、

STEP 1

共通理解をつくる

STEP 2

契約書・SLAなどで合意する

という二段階を求められます。

ガイドラインは、契約書やSLAだけでなく、

議事録
打合せ記録
作業記録

などに「共通理解」の過程を残すことも重要としています。パブリックコメント

つまり、

契約書だけ作れば終わり

ではありません。

8. 医療機関に開示すべき情報

医療機関は、

この会社に医療情報を預けて本当に大丈夫か？

を判断する必要があります。

そのため提供事業者は、

かなり多くの情報を開示することになります。

代表的には、

事業者情報

会社概要
財務健全性
セキュリティ体制
個人情報保護体制
認証取得状況

データ関係

データ保存場所
国内／海外
適用法
データセンター
データ保管方法

システム

システム構成図
ネットワーク構成
データフロー
アクセス管理
ログ管理

セキュリティ

サイバー攻撃対策
パッチ管理
インシデント対応
監査
リスク評価

運用

問い合わせ窓口
障害時対応
BCP
データ返却
データ削除

などです。パブリックコメント

9. 「サービス仕様適合開示書」が非常に重要

そこで用意されているのが、

サービス仕様適合開示書

です。

これは簡単にいうと、

「弊社サービスが医療情報ガイドラインにどう対応しているか」

を医療機関に説明するための標準化された資料です。

第2.0版では、

サービス仕様適合開示書＋SLA参考例

も改訂されています。パブリックコメント

実務上は非常に重要です。

医療機関から、

「3省2ガイドライン対応ですか？」

と聞かれたときに、

単に

「対応しています」

ではなく、

サービス仕様適合開示書を提出できる

状態にしておく方が望ましいです。

10. セキュリティ対策の具体例

第2.0版にはかなり具体的なセキュリティ要件もあります。

多要素認証

非常に重要です。

ガイドラインでは、

多要素認証を可能な限り早期に採用すべき

としています。

さらに厚労省ガイドラインとの関係で、

令和9年度（2027年度）時点で稼働すると想定される医療情報システムでは、二要素認証または相当する対応

が前提とされています。パブリックコメント

したがって新規開発なら、

ID + Password

だけではなく、

Password
+
認証アプリ

などを前提に設計しておいた方がよいでしょう。

11. ログ管理

ログも重要です。

例えば、

誰が
いつ
どの患者情報を
閲覧したか
更新したか
削除したか

を追跡できる必要があります。

さらに医療情報の場合、

医療情報の法定保存期間を考慮してログ保存期間を設定する

ことも示されています。パブリックコメント

12. 通信暗号化

ネットワークについても、

原則としてセキュアなネットワーク

を利用する考え方です。

インターネットを利用する場合にはTLS等による暗号化が必要になり、

HTTPS利用時には、CRYPTRECのTLS暗号設定ガイドラインも参考にすることが示されています。パブリックコメント

13. Wi-Fiも注意

意外に重要なのが無線LANです。

単純な

MACアドレス制限だけでは不十分

としています。

ガイドラインでは、

IEEE 802.1X＋電子証明書

など、より強固な方式を例示しています。パブリックコメント

14. USBメモリ等

医療情報の持ち出しリスクが高いため、

USBメモリ等の小型記憶媒体についても厳しい考え方です。

原則として、

医療情報を格納する小型半導体メモリを使用できないよう配慮する

ことが望ましいとされています。パブリックコメント

15. BCP・ランサムウェア対策

ここも第2.0版で特に重要になっています。

単に、

サーバが止まったら復旧する

というだけではありません。

医療の場合、

システム停止＝診療停止

になり得ます。

そのため、

RTO（何時間以内に復旧するか）
RPO（どこまでデータを戻せるか）
災害時対応
サイバー攻撃時対応
ランサムウェア
復旧後のデータ整合性

などを考える必要があります。

ガイドラインも、

医療の継続性

を考慮してBCPを策定することを求めています。パブリックコメント

16. Pマーク・ISMS

これも重要です。

第2.0版では対象事業者について、

プライバシーマークまたはISMS認証を取得すること

と記載されています。

さらに、

特にプライバシーマーク認定を取得していることが望ましい

としています。パブリックコメント

ただし重要なのは、

ISMSを取れば3省2ガイドライン準拠になるわけではない

ということです。

ガイドラインもISMSについて、

安全対策の有効性までを認証するものではない

と注意しています。パブリックコメント

17. ライフサイクル全体を見る

第2.0版では、

システム導入時だけではなく、

開発

↓

導入

↓

運用

↓

更新

↓

障害対応

↓

契約終了

まで見ます。

特に契約終了時には、

医療情報の返却
データ移行
データ削除
バックアップ削除
アカウント削除

などをあらかじめ決めておく必要があります。

また、運用中もセキュリティ状況について定期的な報告・自己点検を行う考え方です。パブリックコメント

18. 第2.0版で事業者が実際に準備すべきもの

実務として考えると、最低でも次の体系を用意するのがよいでしょう。

情報セキュリティ基本方針
医療情報取扱規程
個人情報保護規程
アクセス管理規程
アカウント管理規程
ログ管理規程
脆弱性・パッチ管理規程
インシデント対応規程
バックアップ・復旧規程
BCP
委託先・クラウド管理規程
システム構成図
データフロー図
リスクアセスメント
リスク対応一覧
責任分界表
サービス仕様適合開示書
SLA
契約終了時データ削除・返却手順
教育・訓練記録

という構成になります。

19. ユーザー様のシステムで特に重要なポイント

例えば医療機関WEB掲示コンプライアンス管理システムの場合、

単に、

医療機関名
届出情報
WEB掲示内容

だけを扱っており、

患者個人の医療情報を扱わない

のであれば、

このガイドラインの適用関係は比較的限定的になる可能性があります。

一方、

365Connectのように、

患者情報
↓
口腔内スキャンデータ
↓
歯科技工指示
↓
歯科技工所
↓
歯科医院

と情報が流れる場合は、

かなり本格的に対象になります。

特に、

患者氏名
医療機関番号
歯科情報
STL
口腔内画像
技工指示書
診療情報

などを扱う場合、

医療情報システムとしての安全管理設計

を最初から組み込んだ方がよいです。

また、AWS、Firebase、Google Cloud等を利用している場合、

歯科医院
↓
365Connect
↓
Firebase / Google Cloud
↓
データセンター

というサプライチェーン全体の整理も必要になります。これは第2.0版が特に強調している部分です。パブリックコメント

20. 一番大事なポイント

第2.0版を理解するとき、

「3省2ガイドライン対応＝暗号化してISMSを取る」

ではありません。

本質は、

① 医療情報を特定
       ↓
② システム構成・情報流を把握
       ↓
③ リスクを特定
       ↓
④ セキュリティ対策
       ↓
⑤ 残存リスクを評価
       ↓
⑥ 医療機関へ説明
       ↓
⑦ 責任分界
       ↓
⑧ SLA・契約
       ↓
⑨ 継続的監査・改善

です。

これが第2.0版の基本思想です。パブリックコメント