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 アンケート記入・提出

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

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

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

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

2021-08-31

IEC 62304 準拠と謳っている RTOS が医療機器規制当局から注意喚起を受ける

富士ソフトが扱う blackberry QNX リアルタイムOS に 脆弱性が見つかり、米国FDA, 日本の厚労省が 医療機関や医療機器製造業者に対して注意喚起を行っている。

厚労省通知 2021年8月23日 『医療機器のオペレーティングシステムに係る脆弱性への対応について(注意喚起)

本件については下記の記事の解説が分かり易い。

【ZD Net Japan 『米政府機関、ブラックベリー製品の脆弱性で注意喚起』より引用】

米サイバーセキュリティ・インフラセキュリティ庁(CISA)は、BlackBerryの製品に存在する「BadAlloc」の脆弱性に関するセキュリティアラートを発表した。BadAllocは、2021年の初めにMicrosoftの研究者が発表した脆弱性だ。

 また米国時間8月17日、BlackBerryは同社の「QNX Real Time Operating System(RTOS)」がBadAllocの脆弱性の影響を受ける可能性がある問題についてのアドバイザリーを発表した。QNX RTOSは医療機器や自動車、工場などで使用されており、国際宇宙ステーションでも使われている。同社は最近、QNX RTOSがおよそ2億台の自動車で使われていると明らかにしたばかりだ。

 CISAは、QNX RTOSは一部のIoT機器やOT/ICSシステムで使用されており、これらのシステムを保護するための対策が急務だと付け加えた。BlackBerryは影響を受ける製品の完全なリストを公開している。

 CISAのアラートでは、「リモートの攻撃者にCVE-2021-22156を悪用されると、対象デバイスがサービス妨害状態に陥ったり、任意のコードが実行されたりする可能性がある。BlackBerryのQNX RTOSは幅広い製品で使用されており、この製品が侵害されると、悪意を持った攻撃者に極めて重要度が高いシステムの制御を奪われる可能性があり、国家的に重要な機能のリスクが高まる」と述べている。

 「CISAは、現時点ではこの脆弱性が積極的に悪用されている事例を把握していない。CISAは、重要インフラ企業や、影響を受けるQNXベースのシステムを開発、保守、サポート、使用しているその他の組織に対して、影響を受ける製品にできる限り早くパッチを適用することを強く推奨する」

 CISAによれば、一部のRTOSのソフトウェアをアップデートするには、機器を取り外すか、敷地外の施設に持ち込んで、メモリーを物理的に交換する必要があるという。

 BlackBerryのアドバイザリーには、同社がこの脆弱性を修正するためにリリースした多数のアップデートの情報が掲載されている。Microsoftは4月に、BadAllocは25件のCVEにまたがる問題であり、消費者向け製品から医療用IoTや産業用IoTまでさまざま分野に影響を与える可能性があると述べている。

 米国の政治専門ニュースメディアであるPoliticoは8月17日、4月にBadAllocの脆弱性に関する情報が開示されて以降、BlackBerryと米国の政府関係者との間で交わされてきた舞台裏での議論について報じた。

 記事では、BlackBerryは同社の製品がBadAllocの影響を受けることを否定し、米政府がこの問題に関してアラートを公表することに抵抗したとされている。

 また、CISAの担当者が、QNXシステムに関するセキュリティアラートについて、影響を受ける業界や国防総省などと事前に連携を取っていたことや、外国の政府関係者にもこの脆弱性について説明する予定であることも報じられている。

 BlackBerryは6月に、QNXはAptiv、BMW、Bosch、Ford、GM、本田技研工業、Mercedes-Benz、トヨタ自動車、Volkswagenが製造する多数の自動車に採用されていると発表している。

【引用終わり】

サイバーセキュリティに関する脆弱性は市販後に見つかることがあり、それ自体はあってもまったく不思議ではないので、この脆弱性が見つかったからといって QNXの品質が悪いとは思わない。

どの製品にもありうるので、ここは粛々とパッチを当てたり、QNXの外側の環境で緩和策を取ることが重要と考える。

今回の記事で取り上げたのは、blackberry QNX について、日本の販売元の富士ソフトが QNXは IEC 62304(医療機器ソフトウェア - ソフトウェアライフサイクルプロセス)のソフトウェア安全性クラスC に準拠証明書付きで出荷されると宣伝しており、これが IEC 62304 のリスクベースアプローチの考え方から逸脱していて、単に商品を売るために 規格を利用しているに過ぎないことを示したかったからだ。

QNX OS for Medical 概要・特長 】より引用

医療機器の複雑さが日増しに増加する昨今、規制の監視が益々厳しくなって来ています。根源が知られており事前認証されたコンポーネントを選択することで、認証プロセスが相当楽になります。QNX OS for Medical(医療用QNX OS)は、独立サードパーティにより「医療機器ソフトウェア - ソフトウェア ライフサイクル プロセス」の標準規格であるIEC 62304準拠であると評価されています。この製品はARMとx86プロセッサーでサポートされています。

医療用QNX® OSは、医療機器メーカー用のQNXソフトウェア システムズソリューションの主要素です。これは、市場投入前の認証業務に必要な時間と手間を低減することで医療関係のお客様が厳しい規制要件を満たすお手伝いをするためにデザインされています。医療用QNX OSは、QNXの標準オペレーティングシステムにより100% API互換で、お客様が最大限にソフトウェアを再使用し、それぞれ異なる認証要件を持つ複数製品用の共通プラットフォームを構築できるようになります。この製品は独立サードパーティ評価によるIEC 62304クラスC準拠証明書付きで出荷されます。

【引用おわり】

このブログサイトでも幾度となく、IEC 62304 が自動車ドメイン等で幅をきかせている機能安全規格ではなく、医療機器のインシデントに対して、医療機器のソフトウェア開発プロセスをリスクベースアプローチでの再発防止を目的として策定されたものであることを説明してきた。

機能安全規格では、製品に使用している部品の開発プロセスが機能安全規格が定めるプロセスどおりに作られているかどうかを認証することを推奨しているが、IEC 62304 はあくまでも医療機器の開発プロセスをリスクベースアプローチで開発することを求めていて、部品単位での規格適合など求めていない。

※機能安全という名前が良くない。安全(Safety)は機能(Function)ではない。機能的安全というのもおかしい。安全機能は手段でしかなく、本質を示していない。機能安全という言葉自体が安全の本質を目指していないと感じる。

そもそも、製品全体の構成要素の信頼性を高めることで安全性を確保しようとする設計は個別最適の発想(フォールト・アボイダンス)であり、ソフトウェアの規模が増大し、複雑化した現代では、まったくもって古い考え方である。1960年代の主流だった発想だ。

今では、左図の緑枠にあるように、製品の安全は「フェールセーフ」「フォールトトレランス」「エラー・プルーフ」といった、個々の構成要素に故障がバグがあっても安全側に倒れるようにしたり、冗長性を持たせたり、操作者は必ずミスをするという前提で設計するといった全体最適の発想を行うことが求められている。これが IEC 62304 で求められているリスクベースアプローチ(患者危害に至る危険状態が起こる要因を分析して、重大な危害が起こらないような対策を行う手法)だ。

だから、RTOSのような汎用部品が何の機器に組み込まれて、どのような機能や性能を実現するために使われるかが分からない状態で、安全性を評価することはできない。

例えば、列車で事故が発生したら速やかに列車を止めることが求められるが、飛行機で事故が発生したら、近くの空港まで飛行機を飛ばし続けなければらならない。同じ移動手段でも前者は止める、後者は動き続けることが求められる。

使用目的(意図する使用 = Intended Use)が定まらないと、リスク分析ができないと教えている。なぜなら、同じ材質、同じ形状をしていても何に使うのかによって、危険状態に至る可能性や発生する危害は変わるからである。

この図にあるように、細い木の棒は、アイスキャンディの棒かもしれないが、医師が口の中を診る際の舌圧子かもしれない。

後者の場合は、医療機器となり滅菌や一つ一つの包装が求められる。

同じ材質、同じ形状でも、意図する使用(Intended Use)によっては、リスクが変わるのだ。

よって、汎用製品である リアルタイムOS について、規格の認証が取れているから安全性が高いと主張しているのは、間違っているし、意味がない。

下記の誤った記事を見て欲しい。IEC 62304 を機能安全規格と同じように扱っている。さらに、IEC 62304 のソフトウェア安全クラスは、機器の意図する使用によってリスク分析を行いその評価によってクラスが変わるはずなのに、なにに使われるのか分からない段階で、ソフトウェア安全クラスC であると言っている。一番高いクラスにしておけばいいでしょという考えならば、それはリスクベースアプローチの本質をまったく理解していないことになる。ようするに、IEC 62304 の規格趣旨が理解できていない証拠である。

【MONOist  組込み開発ニュース『工業、自動車、医療機器の機能安全認証を取得した最新版RTOSを提供開始』】より引用

BlackBerryは2020年11月9日、機能安全認証を取得したリアルタイムOSの最新版「QNX OS for Safety 2.2」の提供を開始した。自動車や組み込みソフトウェア開発などにおいて、認証取得作業を軽減し、迅速なシステム開発を可能とする。

最新版のQNX OS for Safety 2.2は、「QNX Neutrino RTOS」をベースとする。第三者認証機関のテュフ ラインランドから、「IEC 61508 SIL3」(工業)、「ISO 26262 ASIL D」(自動車)、「IEC 62304 Class C」(医療機器)の機能安全認証を取得している。

 さらに、「ISO 26262」「IEC 61508 TCL3/T3」の要件に準拠したC/C++ツールチェーンも採用している。これにより、QNXの機能安全性製品に安全認証取得済みのC++ランタイムライブラリが含まれることとなった。

 同社は、最新版のQNX OSを利用することで、開発期間を短縮しながら安全性や信頼性の高いシステムを開発し、開発費用の削減が可能になるとしている。

【引用おわり】

一方で、富士ソフトは、IEC 62304 を医療機器のソフトウェア開発に適用する際に、支援を行うサービスも行っており、そのサービスを紹介したページでは、IEC 62304 の趣旨を正しく理解しているように見える。【対象ページ

なぜ、このような矛盾が生じるのか。理由は簡単だ。QNX が IEC 62304 に準拠したと宣伝に使っている部門と、IEC 62304 をコンサルテーションしますといっている部門が異なっており、前者は IEC 62304 の中身を読んでおらず(または読んでいても理解しておらず)規格適合したと表明すれば、他のRTOSと差別化ができ、規格の趣旨をよく理解できていないユーザから購入してもらえると考えているからだ。

そして、規格の内容や趣旨を熟知している 第三者認証機関が 機能安全ではない IEC 62304 を汎用ソフトウェア製品に対して適合証明してしまうのか、これも商売になるからだ。(規格適合を証明するには相当な費用がかかる)

規格を熟知した認証機関が誤った使い方をしていることを知っていながら、規格適合証明を出しているのだから、こっちの方が罪が重いと思う。

このブログで必要に問題のあるソフトウェア製品について批判する記事を書くのは、これらの認証がエンドユーザの安全を目指して実施されているのではなく、単に商品を売りたいために認証を取っていると思うからだ。

ここで冒頭の blackberry QNX リアルタイムOS に 脆弱性が見つかり、米国FDA, 日本の厚労省が 医療機関や医療機器製造業者に対して注意喚起を行っているという件に話しを戻す。

blackberry QNX リアルタイムOS は 第三者認証機関のテュフ ラインランドから、「IEC
61508 SIL3」(工業)、「ISO 26262 ASIL D」(自動車)、「IEC 62304 Class C」(医療機器)の機能安全認証を取得している(IEC 62304は機能安全規格ではないので、この記述は誤り)と、富士ソフトはWEBサイトで、規格の認証を取得していて、他の製品より安全ですよと主張している。

揚げ足を取るつもりはないが、今回の脆弱性の発見で脆弱性を突かれると リアルタイムOSを使っている製品が悪用され、患者危害に至る可能性があるためパッチを当てる必要があることが分かった。

QNX は「信頼性が高いとされていた」ため、医療機器にも多く使用されていたので、米国や日本の規制当局が冒頭の注意喚起を出したわけだ。

QNXは自動車にも多く使われているようなので、自動車業界でも対応が求められているだろう。

ただ、QNXが対象システムのどこに、何に使われているのかによって、リスクの大きさは異なる。だから、製品ごとにリスク分析を行うことが重要なのであって、部品の製品開発のプロセスが規格に適合していることを主張するのはおかしいし、医療機器の場合、規格趣旨から特に間違っている。

この図を再掲するが、個別最適で安全設計をする時代ではないのだ。全体最適の発想で、意図する使用を明確にして、その上でリスクを分析し、危害の重大度を考慮し、重大な危害に至るケースを優先して、対策を立てていることが、患者や利用者の被害を効率てきに低減することにつながる。

このリスクベースアプローチの考え方を理解せずに、規格適合を主張し、商品を売ろうとする者は、場合によっては、エンドユーザのリスクを高めてしまっている可能性さえある。

汎用ソフトウェア部品を利用する開発者は、ソフトウェア部品の開発プロセスの認証を気にするのではなく、そのソフトウェアがどのような検証を行ったのか、テストの網羅性やテストケースの設計はどうだったのかを精査するべきだ。

規格ビジネスの悪は、規格が求める内容を理解しないユーザにお墨付きをちらつかせて商品を売ろうとする側面を増長させる点にある。

単純な商品販売における競争のための手段ならまあ、無駄ではないし、それもありかと思うが、そこにユーザの健康や安全がかかっているとすれば、それは間違いだと言わなければかえって危ないと思っている。

セキュリティ上の脆弱性は市販後に見つかったら、粛々を対応することでよい。

だた、これを期に、汎用ソフトウェア製品の規格適合証明が製品の安全性で担保するのは間違いであるということを再認識して欲しい。

2021-07-07

医療機器プログラムの該当性のガイドラインが改訂され、非医療機器の範囲が広がった?(間違い)

 医療機器プログラムの該当性のガイドラインは 2021年3月31日に発行されたもので2014年に発行されたものから置き換わりました。(厚労省のページ

GHS(ヘルスソフトウェア推進協議会)にて、第3回ヘルスソフトウェアのリスク分析入門セミナー(オンライン)を 2021年8月23日に実施します。

このオンラインセミナーの「ヘルスソフトウェアー規制と規制対象外の境界の考え方」にて、今回改訂されたプログラム医療機器該当性のガイドラインについても解説します。


ヘルスソフトウェアのリスク分析入門オンラインセミナー プログラム

13:00~13:10 開講挨拶(スケジュール確認,連絡)

13:10~13:30 GHS と GHS 開発ガイドラインの紹介 

13:30~14:00 ヘルスソフトウェア-規制と規制対象外の境界の考え方

14:00~14:15 休憩

14:15~15:00 ヘルスソフトウェアの周辺に存在するリスク(健康リスク)

15:00~16:00 リスク分析の考え方とリスク分析演習(仮想ヘルスソフトウェアを想定して)

16:00~16:15 質疑応答

16:15~16:30 アンケート記入・提出

厚労省のページ(医療機器プログラムについて)では、対象のソフトウェアが医療機器に該当するかしないかを判定した事例も随時 Excel 表にて提示されています。

また、厚労省は医療機器プログラムの早期実現推進を目的として、医療機器プログラムに関する相談を「医療機器プログラム総合相談」として一元的に受け付ける窓口をPMDAに設置しました。

SaMD一元的相談窓口(医療機器プログラム総合相談)

一方で、これまで医療機器の該当性の相談を都道府県の担当窓口にて受けてきましたが、今後、プログラムの医療機器該当性の相談については、厚生労働省医薬・生活衛生局監視指導・麻薬対策課にて一元的に行うこととなったようです。

なお、医療機器に該当しないプログラムの広告相談につきましては、引き続き、都道府県にご相談とのことです。

医療機器プログラムの該当性のガイドライン が改定されたことで、非医療機器の範囲が拡大されたとミスリードして、下記のようなことを書いているサイトがありますが、これは間違いです。(厚労省確認ずみ)
厚労省が今年3月31日より施行したプログラム医療機器のガイドラインによると、このような健康管理のためのプログラムは非医療機器としてリリースが可能とのこと。

つまり非医療機器部分が拡大されたわけで、このガイドラインを活用すれば、非医療機器=薬事法の外でいろいろな仕掛を行うことが可能となります。

米国もそうですが、医療機器と非医療機器の境界にあるヘルスソフトウェア、ヘルスアプリはどんどんリリースされてきており、各国の規制当局もそのソフトウェアが医療費の削減に貢献されるのであれば歓迎したいというスタンスで、厚労省も効果・効能があって、医療機器にするなら支援しますよといっています。

一方で、医療機器と非医療機器の違いや、健康被害に至るようなリスクがあるのかないのかといったリスクマネジメントについて、よく分からないままソフトウェアをリリースし、商品を売りたいがために、効果・効能的なことを謳ってしまって、広告規制に引っかかるといったケースも増えてくると思います。

GHSのリスク分析入門セミナーでは、規制と規制対象外の違いや、どんなリスクが想定されるのか、また、リスク分析とはどのようにやるのかについて解説します。

セミナーの詳細については、GHSのこちらのページからご確認ください。