2023-04-10

医療機器のサイバーセキュリティ規制強化へ

2023年3月31日付けで、厚労省から医療機器のサイバーセキュリティ規制強化に関するいくつかの通知が発出された。

どんな通知なのかを説明したいと思う。

  1.  医療機器の基本要件基準第12条第3項の適用について(令和5年3月31日薬生機審発0331第8号)(PDF,155KB) 
  2. 医療機器のサイバーセキュリティ導入に関する手引書の改訂について(令和5年3月31日薬生機審発0331第11号・薬生安発0331第4号)(PDF,1435KB) 
  3. 医療機関における医療機器のサイバーセキュリティ確保のための手引書について(令和5年3月31日医政参発0331第1号・薬生機審発0331第16号・薬生安発0331第8号)(PDF,971KB)

「医療機器の基本要件基準第12条第3項の適用について」の医療機器の基本要件基準とは何か


PMDAに詳しい説明資料があるのでこれを参照して欲しい。

簡単にいうと、薬機法(法律)で医療機器は認証基準への適合が必要となっていて、基本要件基準第41条にて、厚生労働大臣は必要な基準を設けることができるとある。医療機器の基本要件基準は厚労省からの告示によって示されている。





医療機器の基本要件基準の第12条は、「プログラムを用いた医療機器の対する配慮」で、今回 第12条の 3項にサイバーセキュリティ要求が追加された。

実は第12条2項は 2017年5月に追加されたJIS T 2304(医療機器ソフトウェア―ソフトウェアライフサイクルプロセス)への適合を求めた追加だった。

第12条3項は、2023年3月9日に追加の告示が発出されている。今回 出た通知は、第12条3項の施行に関する通知となる。

医療機器の基本要件基準第12条第3項

3.プログラムを用いた医療機器のうち、他の機器及びネットワーク等と接続して使用する医療機器又は外部から不正アクセス及び攻撃アクセス等が想定される医療機器については、当該医療機器における動作環境及びネットワークの使用環境等を踏まえて適切な要件を特定し、当該医療機器の機能の支障が生じる又は安全性の懸念が生じるサイバーセキュリティに係る危険性を特定及び評価するとともに、当該危険性が低減する管理が行われていなければならない。また、当該医療機器は、当該医療機器のライフサイクルの全てにおいて、サイバーセキュリティを確保するための計画に基づいて設計及び製造されていなければならない。

これが追加された第12条3項の内容になる。この3項の説明が冒頭の3/31付けの通知1 に書かれている。その内容を紹介する。

趣旨

基本要件基準は、医療機器が具備すべき品質、有効性及び安全性に係る基本的な要件を規定したものであり、医療機器に対しリスクマネジメントの適用によってリスクを許容可能な範囲まで低減することが要求されている。

サイバーセキュリティ対策については、「医療機器におけるサイバーセキュリティの確保について」(平成27年4月28日付け薬食機参発0428第1号及び薬食安発0428第1号)、「医療機器のサイバーセキュリティの確保に関するガイダンスについて」(平成30年7月24日付け薬生機審発0724第1号及び薬生安発0724第1号)等において必要な対応を行うよう求めてきたところであるが、今般、令和2年3月に国際医療機器規制当局フォーラム(IMDRF)において、「医療機器サイバーセキュリティの原則及び実践に関するガイダンス」が取りまとめられたことに伴い、IMDRF N47文書(Essential Principles of Safety and Performance of Medical Devices and IVD Medical Devices)及びN60文書(Principles and Practices for Medical Device Cybersecurity)を踏まえ、プログラムを用いた医療機器に対しサイバーセキュリティを確保するための設計及び製造、ライフサイクル活動として、①製品の全ライフサイクルにわたって医療機器サイバーセキュリティを確保する計画を備えること、②サイバーリスクを低減する設計及び製造を行うこと、③適切な動作環境に必要となるハードウェア、ネットワーク及びITセキュリティ対策の最低限の要件を設定すること、の3つの観点を基本要件基準に盛り込むこととし、基本要件基準第12条に第3項を追加する改正を行ったものである。

要約すると、

IMDRF N47文書、N60文書をベースにしている。

  1. 製品の全ライフサイクルにわたって医療機器サイバーセキュリティを確保する計画を備えること
  2. サイバーリスクを低減する設計及び製造を行うこと
  3. 適切な動作環境に必要となるハードウェア、ネットワーク及びITセキュリティ対策の最低限の要件を設定すること

の3つの観点を基本要件基準に盛り込んだということになる。

IMDRF は 各国の規制当局の集まりで、ここで決まったことを各国の医療機器規制当局が自国の規制に適用することになっている。

IMDRFの成果として有名なのが、MDSAP(医療機器単一審査プログラム)で、各国とも ISO 13485 (ISO 9001 の医療機器版)を医療機器製造販売業者に求めているが、国によって微妙に異なる部分を各国統一部分+差分という形にして、1回審査をパスすれば、それぞれの国で審査し直さなくてもよいというプログラムを作った。これによって、米国の非常に厳しい査察を定期的に受ける必要がなくなった。(全体としては米国の審査基準に近づいたので米国以外の審査としてはハードルが上がったと言える)

IMDRF はN60文書として医療機器の対するサイバーセキュリティのガイダンスを発行していて、冒頭の2の文書が、IMDRF N60文書の日本適用版という位置づけになっている。

冒頭1の施行通知の解説を続ける。

(1) 「プログラムを用いた医療機器のうち、他の機器及びネットワーク等と接続して使用する医療機器」とは、他の機器(医療機器、IoT機器、周辺機器、外部記録媒体(USB、SD、HDD、CD、DVD等)、電子カルテ、PC(外部からの持ち込みPC含む))、ネットワーク(院内システム、院外システム、グローバル)等に接続して電磁的情報のやり取りをする医療機器である。

ここは対象となる医療機器の説明をしてる。

・他の機器にネットワーク等に接続して電磁的情報をやり取りする医療機器が対象。

(2)「外部からの不正アクセス及び攻撃アクセス等」は、脆弱性を攻撃対象とする等の設計者が通常使用において想定していない手法等を用いた悪意を持った不正アクセスや、意図的に過剰な負荷を与えたる攻撃(DoS攻撃(Denial Service Atttack)、DDoS攻撃(Distributed Denial of Service Attack)等)、マルウェア(悪意のあるソフトウェア)の感染を意図する攻撃によるアクセス等を想定している。昨今のサイバー攻撃についてはその攻撃形式が多様化・高度化しており、今後はこれらの攻撃手法の他にも対応することも必要となり得る。

ここは、外部からの不正アクセス及び攻撃アクセスの説明。

(3)「動作環境及びネットワークの使用環境等を踏まえて適切な要件を特定し」とは、医療機関、在宅、救急、植込み型機器等の動作環境並びに接続するネットワーク種別やオペレーティングシステム及び各種ライブラリ等のプラットフォームといった使用環境を特定し、その使用環境に適した運用体制等を含めた医療機器の意図する使用に適切な要件を設定することである。

使用環境の特定について説明と、医療機器の意図する使用と使用環境の要件を設定すること。

(4)「当該医療機器の機能に支障が生じる又は安全性の懸念が生じるサイバーセキュリティに係る危険性を特定及び評価するとともに、当該危険性が低減する管理」とは、他のリスクと同様に、サイバーセキュリティに係るリスクに対しても、適切にリスクマネジメントを行い、例えば、JIS T 81001-5-1に示されている通り、サイバーセキュリティの脆弱性を特定し、その悪用によって生じる脅威や悪影響に伴うリスクを評価し、適切にリスクをコントロールすることである。

サイバーセキュリティのリスクを評価する。悪用によって生じる脅威や悪影響に伴うリスクを評価し、リスクをコントロールする。

(5)「ライフサイクルの全てにおいて、サイバーセキュリティを確保するための計画に基づいて設計及び製造」とは、全ライフサイクルにわたってサイバーセキュリティを確保するため、設計・製造工程における取組だけでなく、医療機関との連携、脆弱性対策(市販後のアップデート等を含む)に係る計画等も踏まえ、それが達成できるように、また、問題点や脆弱性が見つかった場合に対応できるように設計・製造を行うことである。

 設計・製造工程における取り組みだけでなく、脆弱性対策、医療機関への報告、連携を計画し、達成する。

JIS T 81001-5-1 とは IEC 81001-5-1 の JIS版で、「ヘルスソフトウェア及びヘルスITシステムの安全,有効性及びセキュリティ-第5-1部」というタイトルの規格だ。

IEC 81001-5-1は、IEC 62443-4-1 の要求事項を IEC 62304 のプロセスに当てはめた形の規格 であり、すでに産業用の制御システムのセキュリティ規格として存在していた IEC 62443-4-1 を医療機器のライフサイクルプロセスに置き換えた規格だ。

実は、この規格をJIS化するにあたっては、通常は2~3年かかる作業を約1年という短い期間で実現している。これは、厚労省が 医療機器の基本要件基準 のサイバーセキュリティ要求の適合と示すために、この規格を使おうと考えていたからだ。

冒頭1の通知では、「例えば、JIS T 81001-5-1に示されている・・・」というように、JIS T 81001-5-1 以外の規格を使ってもいいよというニュアンスで説明しているが、実際のところは「JIS化したんだから、JIS T 81001-5-1 に適合しろよ」といった本音がにじみでている。

IEC 81001-5-1 のような国際規格を日本が世界に先駆けて医療機器規制に使うというのは非常に珍しいことで、これまではEUが規制に取り入れてから、日本も追随するというパターンだった。

サイバーセキュリティに関しては日本の特に医療分野、医療機器分野では対応が遅れているとされていたため、今回は厚労省が世界に先駆けて、医療機器への規制を強化したといえる。

冒頭の通知3は、医療機関向けのサイバーセキュリティに関するガイダンスになる。

サイバーセキュリティは、医療機器製造業者だけでも医療機関だけでも達成することはできない、両者と規制当局は医療情報システムの提供者などが協力してはじめて達成できる。

よって、各者の情報開示や、レガシーシステムに対する補完的対策などが重要になってくるため、医療機器製造者向けのガイダンスと医療機関向けのガイダンスの両方が発出されている。

また、現行のシステムが医療機関においてどのようなネットワークにつながっているのか、また、どのようなセキュリティ対策(=信頼境界があるのか)、どのような脅威が想定されるのかを分析すること(=脅威分析)が必要であり、医療機器製造販売業者は、今度、脅威分析図、システム構成図を医療機関に示すことが必須になってくる。

このとき使うのが脅威モデリング(データフローダイアグラムを使うのが一般的)だ。

今後、このブログの中で脅威モデリングの説明をしていきたいと考えている。

プログラム医療機器を開発しようとしてる方は、まず3月31日付けで発出された3つの通知をよく読んで内容を理解することをお勧めする。


2023-01-01

久しぶりの投稿

 

1年3ヶ月ぶりの投稿。ふと、Facebook で友人が近況を書き込んでいるのをみて、「あ、そういえばブログ更新してなかった」て気が付いた。

このブログを始めたきっかけは、自分の本を出版して読者との交流しながら情報発信したいと思っていたからだった。あと、組織内で思ったこと、感じたことをブログに書くことである意味ストレス解消していたのかもしれない。また、書くことで自分の考えを整理して伝えるスキルを高めたいという思いもあった。

20年以上、組込みソフトウェアの開発をしてきたが、技術者への支援の仕事を経て、今は、組込み機器からの情報をクラウドに上げて、ユーザにサービスを提供するソフトウェアの開発をマネジメントしている。在宅勤務が増えて仕事の取り組み方も変わって、仕事をしているときとしないときの、ON/OFFがはっきりするようになって、OFFのときは仕事の事を考えなくなった。

若い時は会社にいても家に帰ってきても抱えてる課題をどう解決しようかと考えていたが、今はスキルが高まってきたせいか、ONのときに課題解決の道筋が見えるようになってきたので、OFFのときは仕事のことはあまり考えないようになった。こういった状況の変化で、ブログの更新が滞っていたのかもしれない。

環境が変化したとはいえ、今になってもいろいろを思うところはある。ソフトウェアは複数のエンジニアが関わって作っていくものだし、事業も関係する人々とコミュニケーション取りながら進めて行くので、その中で何かしら感情がぶつかったりすることはある。そういうことがあると、ブログに自分の考えを書きたくなってくる。

最近思うのは、組織ってやっぱり蛸壺的になるもんだということだ。組織が大きくなるほど、エンドユーザとの接点がなくなり、自分のやっていることがユーザのためというよりは、組織のため、さらに自部門のため、さらに自分の利益のためになる。最近、他部門の技術者が「その機能、入れるのか入れないのかだけ、言ってください」という発言をしたので、「そうじゃないだろう、ユーザにとって必要かどうかを考えるんだろう」とたしなめたことがあった。上から言われたことだけやる仕事って面白くないようなって思う。自分が作ったものをユーザが喜んでくれることを糧に仕事ができれば、技術を吸収するスピードだって速くなる。

自分がそういう考えで35年以上働いてきて感じるのは、組織の中にいても自分は個人商店だという認識を持っていたのはよかったなということだ。

入社したてのころはスキルがなくて、とても独立してやっていくことはできなかったので、早く一人前になりたいと貪欲に技術を吸収しようと思っていた。ある程度、外の世界の人達と渡り合えるようになってからは、いつでも独立するぞという気持ちでいたつもりだ。

ただ、組織と自分のポリシーにオーバラップがある内は、多少イヤなことがあっても我慢しようと思った。実力さえ身につけることができれば、組織が方向性が自分の生き方と異なると思ったら、迷わずに外に出ようと考えることができた。個人商店として何とかやっていきそうという自信が付いてなければ、組織にかじり付くしかなかったけれど、いつでも個人商店としてやっていけるとなれば、組織に対してもそれ相当の発言ができる。

そして、組織の事業を支えるようなプロジェクトに関わるようになれば、顧客満足を高めることの実感を得ることができるようになる。

自分はエンドユーザにどのような価値が提供できるのかから始まり、それを実現するための技術は何か、その技術を習得するためにどうしたからいいかという順番で物事を考えるようにしている。

いろいろな技術者と話しをしていると、そういう思考ではなくて、このファンクションをどうやったら実現できるかから話しをはじめる人がいることに気が付く。

「組込みソフトエンジニアを極める」の著書では、技術的なこととともに、エンドユーザに提供する価値を実現する技術を身につけることの大切さを書いたつもりだ。

そういった思考をする訓練をしてきたことによって、さまざまな課題にぶつかったときに、組織内のセクショナリズムなど、エンドユーザ価値に関係がない、また逆行するような事柄は実にくだらないと考えることができるようになった。

35年以上ソフトウェアエンジニアとして働いてきて思うのは、やっぱりソフトウェアは人が作ってるので、人=技術者のことをよく理解しないと何事もうまくいかないということだ。

「組込みソフトエンジニアを極める」や「リコールを起こさないソフトウェアのつくり方」で、欧米と日本の技術者の考え方の違いについてしつこいくらい書いたのは、そこを理解しなければ開発はうまくいかないと直感していたし、実際、欧米で培われたプロセスアプローチはそのまま適用したのでは日本ではうまくいかないと実感したからだ。

ソフトウェアの面白さって、人と密接に関係しているところかもしれないと、今更ながら感じる。

2021-09-10

2021年11月1日にヘルスソフトウェア向けリスクマネジメント・トレーニング講座(オンライン)を開催します

GHS 一般社団法人ヘルスソフトウェア推進協議会は、2021年11月1日にヘルスソフトウェア向けリスクマネジメント・トレーニング講座(オンライン)を開催します。

本リスクマネジメント・トレーニング講座は、GHS 開発ガイドラインの Level-1 の要求を実践するために必要な知識、技術を習得するための講座です。一般社団法人 ヘルスソフトウェア推進協議会(GHS)は、これまで、9回に渡りトレーニング講座を開催し、のべ200名以上の参加者が ヘルスソフトウェアのリスクマネジメントに関するスキルを修了しています。

本講座は、分かり易い資料、少人数に分かれたグループワーク・グループディスカッション、経験豊富な講師やモデレータによる丁寧な指導が特長の参加者の満足度が高いセミナです。

リスクマネジメント・トレーニング講座(オンラインセミナ)プログラム

10:00~10:05 開講挨拶(トレーニング講座開講の挨拶とスケジュール確認,連絡)
10:05~10:15 テスト 受講者事前知識調査
10:15~11:00 講義1 安全(セーフティ)の考え方
11:00~11:10 アイスブレイク(Zoomのブレイクアウトルームを使ってみる)
11:10~12:00 演習1 Intended Use(意図する使用)の定義と安全面とセキュリティの特質を明確化
12:00~12:45 昼食休憩
12:45~16:25 ※途中休憩あり
                演習2 演習1 Intended Use(意図する使用)の発表
演習3 仮想ヘルスソフトウェアアプリのリスク分析演習
演習4 リスク分析結果発表(各グループ)とディスカッション
解説  分析例の解説
16:25~16:40 GHS リスクマネジメント様式集(3種)と記入例とヘルスソフトウェアのサイバーセキュリティ要求について
16:40~16:50 質疑応答
16:50~17:00 アンケート記入・提出

詳しくは、こちらをご覧下さい。

演習では仮想のヘルスソフトウェア(健康アプリ)を題材にして、危害にいたる可能性のある一連の事象、危険状態、具体的な危害をリストアップし、それらが発生する確率(可能性)と重大度を分析して対策を考えます。

個人ワークの結果を持ち寄り、他社の参加者とグループディスカッションを行うことにより、自分では気が付かなかった視点があることに気付き、演習を経験することで、持ち帰って自社製品でもリスク分析できるようになることを目指します。

※コンサルティング関係の方の参加はお断りしています。