Slide 1

Slide 1 text

医療情報システムの安全管理に関するガイドライン第7.0版の変更 点を確認してみた さっぽろ医療IT勉強会 #2「札幌 × 医療DX2!」 1

Slide 2

Slide 2 text

自己紹介 名前:岩浅貴大(いわさ) 所属:クラスメソッド株式会社 ロール:ソリューションアーキテクト 1. 前々職で医療システム(電子カルテ、レセコン、 検査システムなど)の開発業務に従事 2. 現職は様々なお客様(医療関係もあり)へのクラ ウドを軸にした課題解決を提案するソリューショ ンアーキテクトとして活動中 2

Slide 3

Slide 3 text

本日のスライドについて ガイドライン第7.0版は令和8年6月29日に公表されたばかりで、私もまだすべて を確認できているわけではありません 本スライドの内容は本日時点での私の解釈です 解釈違いや補足などあればぜひコメントください! 3

Slide 4

Slide 4 text

ガイドラインについて 医療機関等が医療情報システムを安全に管理・運用するための要件をまとめた厚 生労働省のガイドライン e-文書法や個人情報保護法等への対応を目的として平成17年3月に第1版策定 令和8年6月29日付で第7.0版が策定 経産省・総務省の「2省ガイドライン(医療情報を取り扱う情報システム・サービ スの提供事業者における安全管理ガイドライン)」と合わせて「3省2ガイドライ ン」と呼ばれる 4

Slide 5

Slide 5 text

7.0版の主な変更点 1. 保守委託機関編の新設 2. パスワードルールの変更 3. 二要素認証の対象の明確化 4. データ保管場所の要件明確化 5. サプライチェーンリスクの追記 ※厚労省「医療情報システムの安全管理に関するガイドライン第7.0版の概要及び主な改定内容」に基づく 5

Slide 6

Slide 6 text

1. 保守委託機関編の新設 6

Slide 7

Slide 7 text

保守委託機関編の新設 6.0版:概説編・経営管理編・企画管理編・システム運用編の4編 7.0版:上記+保守委託機関編の5編に セキュリティアップデートを含むサーバの保守を事業者に全て委託できている医療機関等におい ては、「概説編」と「保守委託機関編」のみを参照し、その遵守事項に対応することで本ガイド ラインを遵守できているものとみなす。 「保守委託機関」= 保守を委託している側、つまり医療機関自身を指す呼称 主に専任のシステム担当者がいない小規模医療機関等を想定 SaaS型システムを積極的に採用することで、特別な契約なく保守委託を実現する ことを想定している ガイドライン対応のハードルを下げ、小規模医療機関がSaaS等を活用しやすくす 7 る効果が期待される

Slide 8

Slide 8 text

保守委託機関編でのMDS/SDSの位置づけ 保守委託機関編の「はじめに」より: 特に「システム運用編」における事項については、MDS/SDSを用いて機器、サービスのセキュ リティ対応状況を確認することで、遵守事項に対応されたものとみなす。 保守委託機関編の構造: 医療機関自身がやるべきこと(体制整備、BCP、事業者選定、職員教育など)→ 遵守項目のチェックリスト 技術的な安全管理(システム運用編相当)→ 事業者にMDS/SDSを提出させ、【別 紙】の項目が「はい」または「対象外」であることを確認する つまり「医療機関が自ら確認すべき項目」+「事業者から出させた書類で確認する項 目」の2本立て。 8

Slide 9

Slide 9 text

事業者選定の要件(原文) 外部保存の委託先事業者選定の際は、プライバシーマーク、ISMS又はこれと同等の規格の認証を 受けている事業者を選定すること。 また、安全管理方針、体制、バックアップ状況、信用度、認証(ISMAPやプライバシーマーク、 ISMS等)の取得状況、保存場所を確認し、情報機器等が、国内法の適用及び執行の及ぶ範囲に あることを確実にすること。 事業者選定時の認証確認(ISMAP・ISMS等)とMDS/SDSは別の遵守項目。 9

Slide 10

Slide 10 text

2. パスワードルールの変更 10

Slide 11

Slide 11 text

パスワードルールの変更(6.0版) 背景:単純なパスワードやその使い回しによるサイバー攻撃被害が発生している(改定 概要資料より) 6.0版 遵守事項⑤: 情報機器に対して起動パスワード等を設定すること。設定に当たっては製品等の出荷時における パスワードから変更し、推定しやすいパスワード等の利用を避けるとともに、情報機器の利用方 法等に応じて必要があれば、定期的なパスワードの変更等の対策を実施すること。 11

Slide 12

Slide 12 text

パスワードルールの変更(7.0版) 上記の「定期的なパスワードの変更」が削除され、代わりに以下が明記: いずれの場合においても、パスワードの定期的な変更は不要とする。 ⑥(2) 異なる医療情報システムにおいて用いるパスワードの使い回しは行わないこと。 ⑥(6) 一定回数、認証に失敗した場合には、以降一定時間ログイン試行が不能となる仕組みを講 じること。 定期変更の削除根拠:NIST SP 800-63B(2017年)で「定期変更を強制するとユー ザーが弱いパスワードを選ぶ傾向がある」として非推奨に。NISCも2018年に同様の 見解を公表。 12

Slide 13

Slide 13 text

3. 二要素認証の対象の明確化 13

Slide 14

Slide 14 text

二要素認証の対象の明確化 6.0版: 二要素認証を採用するシステムの導入、又はこれに相当する対応を行うこと。 → 「何に対して」二要素認証を求めるのかが不明確だった 7.0版(システム運用編 14.1.1): クライアント端末とサーバのいずれも二要素認証の実装を要する。 クライアント端末では電子カルテ等のアプリケーションのログイン時に二要素認証を実装するこ と。 サーバについてはOSでの二要素認証を実装すること。 14

Slide 15

Slide 15 text

補足:サーバOSの二要素認証 「サーバOSでの二要素認証」= SSH/RDPでサーバにログインする際にMFAを求 めるということ 難易度は環境による: Linux + SSH:PAMモジュールでTOTP設定が比較的容易 Windows + RDP:RDゲートウェイ+認証サーバ拡張が必要で手軽ではない RDPのMFAは「設定はできるが手軽ではない」のが現状。代替措置が認められて いる背景にはこの実装難易度があると思われる 期限は令和9年度だが、原文では以下の猶予措置がある: 対応が困難な場合には、令和9年度以降のシステム更新時に対応可能な事業者を選定すること。 15

Slide 16

Slide 16 text

サーバOSのMFA代替措置 7.0版では以下2パターンが代替措置として認められている: ①別ドメインに設置した踏み台端末からの接続のみに限定し、踏み台端末のOSログイン時に MFAを実装する → サーバとは異なるネットワークセグメント上の踏み台端末でMFAすれば、その先の サーバではMFA不要 ②踏み台端末にEDR(端末上の不審な挙動をリアルタイムに検知・対処するソフトウェア)を備 え、外部からの接続はVPN経由に限定する → このパターンはMFAなしでも認められる 16

Slide 17

Slide 17 text

4. データ保管場所の要件明確化 17

Slide 18

Slide 18 text

データ保管場所の要件明確化 保守委託機関編5.③: 情報機器等が、国内法の適用及び執行の及ぶ範囲にあることを確実にすること。 データの物理的な保管場所が国内であることが求められている。クラウドに限らずオ ンプレミスも含む話だが、クラウド活用が推進される中で保管場所を意識する必要が ある。 背景: 7.0版ではセキュリティ対応を事業者に委託しクラウドを積極活用する方針が追記 標準型電子カルテ(デジタル庁で開発中)もSaaS型・ガバメントクラウド対応を 要件としている(ガイドラインの遵守項目ではなく国の方針としての参考情報) クラウド推進とデータ主権のバランスとして、保管場所の要件が明確化された 18

Slide 19

Slide 19 text

データ保管場所の積み残し課題 この「国内法の適用及び執行の及ぶ範囲」という要件について、7.1版で見直しが検討 されている。 パブリックコメントや検討会で議論された論点: がんパネル検査(がんゲノム医療で腫瘍の遺伝子を網羅的に調べる検査)では、 解析を行う検査会社が国内に少なく、検体データを海外の会社に送って解析・保 管するケースが実態として存在する 「国内法の及ぶ範囲に置くこと」がこの実態に則さない可能性 19

Slide 20

Slide 20 text

5. サプライチェーンリスクの追記 20

Slide 21

Slide 21 text

サプライチェーンリスクの追記 NCO(国家サイバー統括室、旧NISC)が策定する「政府機関等のサイバーセキュリテ ィ対策のための統一基準群」が令和7年7月に令和7年度版へ改定された。この改定を 受けて、医療情報システムのガイドラインにもサプライチェーンリスクへの対応が追 記。 ガイドラインで求められていること: 医療情報システムで利用するソフトウェアやライブラリの構成を把握し、脆弱性 が発見された際に該当するか判断できる状態にすること 脆弱性情報を継続的に収集し、パッチが公開された場合は速やかに適用すること 21

Slide 22

Slide 22 text

SBOM(ソフトウェア部品表) 構成の把握手段として、SBOMの活用が挙げられている。 SBOM = Software Bill of Materials システムを構成するソフトウェアの「部品リスト」。例えば: 電子カルテシステムが使っているWebフレームワークのバージョン そのフレームワークが依存しているライブラリ群とバージョン →「Log4j に脆弱性が見つかった」というとき、自分たちのシステムにLog4j が含ま れているかをSBOMから即座に確認し、パッチ適用の要否を判断できる。 22

Slide 23

Slide 23 text

まとめ 23

Slide 24

Slide 24 text

まとめ 保守委託機関編の新設が最大の変化。SaaS活用により小規模医療機関のガイドラ イン対応が簡素化された パスワード定期変更が不要に。使い回し禁止・ロックアウトが追加 二要素認証の対象が「端末はアプリ、サーバはOS」と整理された クラウド活用は推進方向だが、データ保管場所は国内法の及ぶ範囲 サプライチェーンリスクへの対応(構成把握・脆弱性対応の迅速化)が新たに求 められるように 24