2016-09-18

IEC 62304 実践ガイドブック概説(2)-ガイドブックの目次と読み方-

IEC 62304 医療機器ソフトウェア-ソフトウェアライフサイクルプロセス は,IEC(International Electrotechnical Commission:国際電気標準会議)から発行されている国際規格で 初版が2006年に 追補版である Amendment 1 が2015年に出ている。

英語/フランス語版はIEC のWEBサイトで,IEC 62304:2006 を JIS化した JIS T 2304:2012年 はJSA WEBストアで購入できる。ちなみに,JISの番号がなぜ 62304 ではなく,2304なのかと言うと,その当時 JIS の番号は4桁が基準で特例以外は4桁にさせられていたからである。今では5桁が使える。

IEC 62304:2006 は IECのWEBストアで290スイスフ,ラン(IECの本部がスイスにあるのでスイスフラン,290スイスフランは約3万円) IEC 62304:2006 Amd1:2015 は158スイスフラン(Amd1は修正点のみ記述,158スイスフランは 約1万6千円)で買うことができる。

JIS T 2304:2012 は JSA WEB ストアで 4320円で購入できる。 JIS T 2304 の追補1 は現在 JIS 化が進められており,来年には発行されると思われる。

国際規格を規制への適合目的で使用する場合は,必ず規格の原文を入手しておく必要がある。また,JIS版があるからといって JIS だけを買うのではなく,必ず IECやISOの規格も買うことを推奨する。

その理由は,JIS版の日本語では曖昧な点,もしくはよく分からない所については IECやISOの英語の原文を読むとはっきりすることがあるからだ。

例えば,英語では shall と should では,shall の方が「しなければならない」という強制力があるが,日本語にするとどちらも「する」になっていることがある。

IEC 62304 実践ガイドブックを規制への適合目的に使うのであれば,必ず 規格の原文を横においていつでも規格の文言がどうなっているのかを確かめられるようにしておくことを強く推奨する。

IEC規格をJIS化する場合、正確に伝わるように日本語を選ぶのだが、意訳したりむやみに注釈を追加したりはできず、できる限り原文に近い日本語にするため、どうしても意味がストレートに伝わらないことがある。そういった意味が通りにくい部分の解釈を国際規格を検討してきたエキスパートたちの言葉で伝えるという目的もこのガイドブックにはある。

IEC 62304 実践ガイドブックの読み方

IEC 62304 実践ガイドブックは 基本的には IEC 62304:2006 と IEC 62304 Amd1:2015 の規格要求事項の解釈や解説を目的としているが,規格解釈以外の情報も含まれているので想定される読者別に IEC 62304 実践ガイドブックのお勧めの読み方(斜め読みの仕方など)を紹介する。

【IEC 62304 や JIS T 2304 をすでに読み込んでいて,規格適合に取り組んでいる方】

IEC 62304 実践ガイドブックは 第3章~第9章が IEC 62304と同じ章構成になるようにしている。したがって,規格原文で分からないところがあったら,その章と同じ章のガイドブックの箇所を読めば,規格が要求している内容の理解が進む。また,ガイドブック側には Point という囲み記事が各所にあるのでそれも参考になると思う。

Point 囲み記事の例
Point 5.7.1 Fail(失敗)が1つもないソフトウェアシステム試験結果

 ソフトウェアシステムの規模が大きく,複雑になればなるほど,ソフトウェアシステム試験の内容も増大します。そうなるとテストを実施した時点で,試験のテストケースの内容や合否判定基準自体に誤りがみつかることもあります。

 また,ソフトウェアを変更すればするほどテストケースも変わる可能性が高いため,ソフトウェアの完成度が高まらないとテストケースもなかなか固まらないという側面もあります。そのため,ソフトウェア結合試験やソフトウェアシステム試験の仕様書を確定させずに,プレ試験をくり返し,すべての試験項目に合格することが確認できた時点で,試験の仕様書を承認し,その仕様書をもとに実施した試験結果を登録するということもあるようです。この場合,ソフトウェアシステム試験の結果にFail(失敗)が1つもなく,すべての試験に合格していることが試験結果となります。

 このようなFail(失敗)が1つもない試験結果は,欧米の監査官,査察官には奇異に映り,本当にテストをしたのかどうかの疑いの目で見られることもあります。
そういったことが起こらないようにするためには,試験の仕様書はある程度,上流から下流に向けて段階ごとに確定させていきます。テストケースは,要求仕様をつくったときに同時に作成してしまう癖を付けておくとよいでしょう。そして,テスト自体は繰り返し実施し,テストで発見された異常は検証の報告書でレポートするようにします。(Point 5.6 参照)

 設計の上流においても下流においても,設計とテストを常にペアで考えていると,合否判定基準を意識するようになり,設計上のもれや抜けを早期に発見することにもつながります。アジャイルソフトウェア開発でテストファーストが推奨されているのも,テストケースの早期作成が検証の効率化のみならず,ソフトウェア設計にプラスの影響を与えると考えられるからです。

次に,第10章の各国の医療機器ソフトウェア規制を読み,第1章のIEC 62304が策定された背景と今後の見通し と 第2章のリスクベースアプローチを読むとよい。

【国内薬事申請担当または,各国規制担当の方】

まず,第1章のIEC 62304が策定された背景と今後の見通し と 第10章の各国の医療機器ソフトウェア規制 を読み,次に第2章のリスクベースアプローチ を読んで,ソフトウェア起因の事故の再発防止が目的で規格が作られていることを理解し,米国や中国に医療機器を輸出しているまたは,これから輸出するならば,付録のFDAやCFDAのソフトウェアの関するガイダンスの邦訳を読む。

【医療機器ソフトウェアのサプライヤ】

医療機器ソフトウェアのサプライヤは,医療機器製造業者からソフトウェア開発を委託され,ソフトウェアを供給するソフトウェアハウスだ。よって,医療機器性業者がIEC 62304 を規制目的で採用しているならば,規格の内容を理解している必要がある。よって,規格原文とガイドブックの第3章~第9章に目を通し,自分達が委託されているソフトウェアの開発プロセスの要求部分を詳細に読むとよい。

また,それらの規格要求がどのような背景で作られていったのかと知るために,第1章,第2章を読む。また,第10章の各国規制の章を読めば,医療機器性業者がどんな規制を受けているのかが分かる。

【医療機器ソフトウェアの業務ドメインへの新規参入者】

規制が求められる医療機器や医療機器ソフトウェア,また,規制対象外のヘルスソフトウェアの開発者製造業者で,将来規制対象の医療機器や医療機器ソフトウェアを開発したいと考えている方は,第1章で規格制定の概要と 第2章のリスクベースアプローチ と 第10章の各国規制についてまず読み,次に第3章~第9章の規格要求の解説を読むとよい。

【医療機器ドメイン外でソフトウェア規制について興味がある方】

医療機器ドメイン外でソフトウェア規制について興味がある方には,是非 第1章の IEC 62304が策定された背景と今後の見通し と 第2章のリスクベースアプローチを読んで欲しい。

第2章の リスクベースアプローチは 1980年代の発生したソフトウェア起因の医療機器の事故から米国FDAが医療機器ソフトウェア規制の乗りだし,さらにその後も発生し続けているソフトウェア起因のインシデントやアクシデントは,どうしたら防ぐことができるのかという再発防止のために,IEC 62304 が作られたという背景を知って欲しい。

一言で医療機器といっても多種多様であるため,一つの対策,一つの方法論では安全を確保することはできないということが,医療機器業界では共通認識となっている。この多様性の中で培ってきた安全を実現するためのリスクベースアプローチは今後,ITイノベーションが進み限られた機能から多様な機能へ変異するさまざまな業界において,利用者から安全が求められるシーンがあるなら必ずや参考になると思う。

第2章のリスクベースアプローチを理解した上で,第3章~第9章の IEC 62304 の要求を読み進むと,なぜ,そのような要求になっているのかが分かると思う。

※IEC 62304 と機能安全と同じだと勘違いしている人には,第2章と第10章をよく読んで欲しいと思う。

 目次 概要 
第1章 IEC 62304が策定された背景と今後の見通し IEC 62304 が策定された背景や,Amd1 の変更点,関連する規格 IEC 80001シリーズや IEC 82304-1 の規格を紹介している。
第2章 リスクベースアプローチ放射線治療器 Therac-25 の事故でソフトウェアの何が影響したのか,また事故から学ぶ教訓とはなにか。安全(セーフティ)の概念とは何か,米国のヘルスITに対するリスクベースアプローチの考え方を紹介。

※本章の記事は,現MIT教授ナンシー・レブソンらが1980年代に書いた論文(An Investigation of the Therac-25 Accidents)を元にソフトウェア設計の観点で再分析した。
第3章 IEC 62304で使われる用語の解説 第3章~第9章までは IEC 62304 Amd1 の章立てに対応しており,IEC 62304 の規格の横に本書を置いて,規格要求の意味を知るためのリファレンスとして使用する。

ところどころに Point の囲み記事を配置し,より突っ込んだ解釈・解説をしている。      
第4章 IEC 62304の一般要求事項
第5章 ソフトウェア開発プロセス
5.1 ソフトウェア開発計画
5.2 ソフトウェア要求事項分析
5.3 ソフトウェアアーキテクチャの設計
5.4 ソフトウェア詳細設計
5.5 ソフトウェアユニットの実装
5.6 ソフトウェア結合及び結合試験
5.7 ソフトウェアシステム試験
5.8 システムレベルで使用するためのソフトウェアリリース
第6章 ソフトウェア保守プロセス
第7章 ソフトウェアリスクマネジメントプロセス
第8章 ソフトウェア構成管理プロセス
第9章 ソフトウェア問題解決プロセス
第10章 医療機器のソフトウェア規制 医療機器ソフトウェアの各国規制について説明
10.1 医療機器の各国規制について
10.2 IMDRFが定義するSaMD
10.3 IMDRF参加各国のIEC 62304:2006に対する考え方
10.4 医療機器ソフトウェアの各国規制の状況
10.5 医用電気機器安全通則から参照されるIEC 62304
10.6 米国FDAの医療機器ソフトウェア規制
10.7 EUの医療機器ソフトウェア規制
10.8 中国の医療機器ソフトウェア規制
10.9 日本の医療機器ソフトウェア規制
各国の医療機器規制当局が集結する IMDRF の動きと現在までに IMDRF が発行するドキュメントを紹介。米国,EU,中国,日本の医療機器ソフトウェアの規制状況について解説している。医用電気機器安全通則と IEC 62304 の関係についても説明。
付   録
1 ソフトウェアバリデーションの一般原則(製造業者およびFDAスタッフのための最終ガイダンス)
2 医療機器における既製(OTS)ソフトウェアの使用に関する企業,FDA 審査官および適合性のためのガイダンス
3 医療機器に含まれるソフトウェアのための市販前申請の内容に関する ガイダンス
4 市販(OTS)ソフトウェアを含むネットワーク接続医療機器のサイバー セキュリティ
米国FDAが発行するソフトウェア系のガイダンス4種の参考和訳を掲載。原文は公開されているものの,邦訳は貴重。
5  医療機器ソフトウェア登録技術審査指導原則 中国CFDAが2015年に発行した医療機器ソフトウェア登録技術審査指導原則の邦訳版を掲載。本内容は中国にソフトウェアが搭載されている医療機器を輸出する際には申請の要件となるため,必読の内容となる。
6  IEC 62304:2006のAmd 1:2015における追加・修正部分一覧表
7  IEC 62304/米国FDA/CFDAソフトウェア要求比較表(目安とするための比較表)
IEC 62304 Amd1 の要求と FDAが発行するソフトウェア系ガイダンス,中国CFDAの要求の違いを比較表で示した。また,IEC 62304:2006 と IEC 62304 Amd1:2015 でどこが変わったのかも付録6の表で確認することができる。

2016-09-04

IEC 62304 実践ガイドブック概説(1)-ガイドブックを編纂した背景-


IEC 62304 実践ガイドブックの概要

IEC 62304 (医療機器ソフトウェア-ソフトウェアライフサイクルプロセス-)の実践ガイドブックがJEITA ヘルスケアインダストリ事業委員会/医療用ソフトウェア専門委員会 編纂で2016年9月28日予定で出版される。(現在はAmazonで予約受付中)

このガイドブックが編纂された背景を紹介する。下記の 本の内容紹介が簡潔で分かりやすいので引用する。

【Amazon 内容紹介より】
2017年11月より実質的な規制要件となるIEC 62304(JIS T 2304)の現場レベルでの解釈、および各国の医療機器ソフトウェア規制要求をまとめたガイドブック!
日本国内において、2017年11月より、IEC 62304(医療機器ソフトウェア ‐ ソフトウェアライフサイクルプロセス)への適合が医療機器ソフトウェアの実質的な規制要件となります(医療機器の基本要件基準 第12条2。現在は経過措置期間中)。しかし、IEC 62304のJIS版であるJIS T 2304を読んだだけでは、要求の背景や意味がわからず、具体的にどのような対応をとればよいのか不明な部分も多くあります。
本書は、JEITAヘルスケアインダストリ事業委員会/医療用ソフトウェア専門委員会の活動成果の集大成であり、IEC 62304(JIS T 2304)の策定に携わったエキスパートらが直接、本規格の要点と対応のコツをわかりやすく解説した実践書です。
規格本文と付属書からだけでは読み取りにくい事柄や、欧米のソフトウェア開発と異なる文化をもつ日本の医療機器ソフトウェア開発において、本規格を適合させるためのヒントと各国の医療機器ソフトウェア規制の内容を紹介しており、今後、規制対象の医療機器ソフトウェアの開発に携わるソフトウェア技術者にとって必修の内容をコンパクトにまとめています。

◇本書によってIEC 62304の求める要件について的確な理解が得ることで、スムーズに適合を示すことが可能になります。
◇日本、EU、中国、米国の医療機器ソフトウェア規制要件とそれらの違いがわかります。
◇医療機器ソフトウェアが規制されるようになった背景と今後の国際規格の見通しがわかります。
◇医療機器ソフトウェア業界へ新規参入する企業や医療機器製造業者へソフトウェアを供給するサプライヤにとって最適なガイドとなります。

医療機器ソフトウェアの規制要件について

医療機器ソフトウェアは世界各国で法規制の対象となるソフトウェアだ。規制の対象になっている理由は2つある。一つは診断・治療・予防に対する有効性を担保する必要があることと,二つ目は医療機器としての安全性を担保する必要があり,国は国民のために医療機器の安全性や有効性が保たれていることを確認し監督しなければならないからだ。

安全性や有効性の確認や監督といった堅い責務とソフトウェアという柔らかい対象物は相性がいいとは言えない。ハードウェアについては安全性や信頼性の試験で担保できるものでも,ソフトウェアの場合は(簡単に変更できてしまい,かつ問題が分かりにくいという意味で)ふわふわしているため,こうすれば大丈夫という決めてがない。だから,プロセス規格によって間接的に安全性や信頼性を担保しようとする。

ソフトウェアは柔らかく締め付けがしにくいが,それでもいろいろな製品の中で中心的な役割を果たしつつあり,業務ドメインによっては,国民の安全のために規制をしなければいけないところまで来ている。

ちなみに,自動車業界において話題になっている機能安全規格 ISO 26262 は,現在,どの国においても法規制に使われてはいない。国際規格もたくさんあるが,規制目的で使用されているかどうかの切り分けはとても重要だ。規制目的に使われるには,それなりの背景や理由がある。規格の利用者はその背景や理由を理解しておく必要がある。

さて,ここまで,IEC 62304 が医療機器ドメインにおいて,規制に使われているかのような書き方をしたが,上記の本の内容説明にあるように正確には「実質的な規制要件」になるというのが正しい。

一体それはどういうことか説明するとこのようになる。

まず,医療機器は日本では薬事法で規制をされていた。薬事法では対象が有体物だったので,無体物であるソフトウェアは規制の対象ではなかった。(医療機器に組み込まれたソフトウェアは以前から規制の対象だったが,現在,汎用プラットフォームに搭載するソフトウェア単体も医療機器と見なすのが一般的になりつつある)

そこで,日本も米国やEUに習って,薬事法が2014年11月25日に医薬品医療機器法(正式名称:医薬品、医療機器等の品質、有効性及び安全性の確保等に関する法律,略して薬機法と呼ばれることもある)に変わり,ソフトウェアが法律の中では「プログラム」と称されて医療機器として規制の対象になることになった。

医薬品医療機器法には,旧薬事法時代から 第四十一条第三項 が設けられており,「厚生労働大臣は必要な基準を設けることができる。」となっている。

厚生労働大臣が設ける必要な基準というのが,厚生労働省告示のようなものであり,2014年11月5日に 厚生労働省告示 403号 (医療機器の基本要件)が発行され,次の 2の条件が追加された

第十二条プログラムを用いた医療機器(医療機器プログラム又はこれを記録した記録媒体たる医療機器を含む。以下同じ。)は、その使用目的に照らし、システムの再現性、信頼性及び性能が確保されるよう設計されていなければならない。また、システムに一つでも故障が発生した場合、当該故障から生じる可能性がある危険性を、合理的に実行可能な限り除去又は低減できるよう、適切な手段が講じられていなければならない。
2 プログラムを用いた医療機器については、最新の技術に基づく開発のライフサイクル、リスクマネジメント並びに当該医療機器を適切に動作させるための確認及び検証の方法を考慮し、その品質及び性能についての検証が実施されていなければならない。

この条文の内容は GHTF(現在はIMDRFで各国の医療機器規制当局の連合体)が定めたもので,EUも同様に医療機器の基本要件として採用している。

IEC 62304 実践ガイドブック 10章 「医療機器のソフトウェア規制」より引用
 医療機器の基本要件(Essential Principles of Safety and Performance of Medical Devices Study Group 1 Final Document GHTF/SG1/N68:2012)を策定したのはGHTFです。GHTF は日本,米国,EU,カナダ,オーストラリアといった各国・地域の規制当局及び産業界の代表者が参加して国際的な医療機器規制の整合化と収束を促進するために1992年に創設されました。その後,GHTFは解散し,その役割は2011年に創設された IMDRF(International Medical Device Regulators Forum, 国際医療機器規制当局フォーラム)に引き継がれています。
 現在,IMDRFはGHTFの参加国に新興国も加わり,オーストラリア,ブラジル,カナダ,中国,欧州連合(EU),日本,ロシア,アメリカがマネジメントコミッティを組織し,図10.1にあるようにワーキンググループで活動を行っています。

さて,この厚労省告示 403号の 第12条 2 に書かれている「プログラムを用いた医療機器については,最新の技術に基づく開発のライフサイクルを考慮し,その品質及び性能についての検証が実施されていなければならない」という条件は,すべての医療機器に対して求められている規制要件であるから,要件が満たされていなければ罰せられる。(法律に付随する厚労省の告示の条件であるため)

そして,医療機器ソフトウェアにおける「最新の技術に基づく開発のライフサイクル」に対して,2016年9月現在,存在する国際規格は IEC 62304 しかないため,IEC 62304 が実質的な規制要件になるのだ。

ただし,厚労省告示 403号の 第12条 2 は,IEC 62304 に適合せよ とは言っていない。だから,最新の技術に基づく開発のライフサイクルを採用して,品質及び性能について検証が実施されていると主張すれば,他のライフサイクルプロセスを採用することは可能だ。

しかし,医療機器製造業者の 99.9 % は IEC 62304 を使って,厚労省告示 403号 第12条 2 に適合していることを示す。医療機器の基本要件への適合を審査する審査機関も IEC 62304 が使われる事になれているため,他のライフサイクルプロセスで要件を満たすのかどうか判断するには相当な時間がかかるだろう。

だから,ほとんど全ての医療機器製造業者が IEC 62304 への適合を示すし,その方が医療機器の薬事申請がスムーズに進む。

こういった背景により,IEC 62304 は実質的な規制要件となっているのである。

なお,2014年11月25日に医薬品医療機器法ができたとき,告示403号 第12条 2 は3年間の経過措置が設けられた。

その理由は開発ライフサイクルの基準を実践するのは,それなりの時間がかかるので IEC 62304 が示すライフサイクルプロセス基準を満たせるようになるための猶予期間が3年設けられたのだ。

だから,3年後の 2017年11月25日からは,医療機器製造業者にとって IEC 62304 への適合が実質的に必須になる。

IEC 62304 は初版が 2006年に制定されており,EUに医療機器を出荷している製造業者は 2006年頃から IEC 62304 の対応を始めているので,焦る必要もないのだが,国内で規制対象の医療機器プログラムを製造している製造業者や,国内の医療機器製造業者にソフトウェアを供給しているサプライヤにとっては,2017年11月25日から日本においても,IEC 62304 が実質的な規制要件になるということはよく理解しておく必要がある。

各国規制当局の IEC 62304 の使用に関する考え方

ちなみに,IMDRF は IMDRF/MC/N35:2015 文書として,IEC 62304 の使用に関する声明を IMDRF 参加各国の規制当局の言葉で下記のように示している。

これにより 各国規制当局の IEC 62304 の扱いに関する考え方が分かる。日本は IEC 62304 を参照していないと書いているが,それは2015年時点のことで,2017年11月25日以降は,経過措置が切れるので,ヨーロッパと同じような考え方になると予想される。

IMDRF/MC/N35:2015 IEC 62304の使用に関する声明
 Statement regarding Use of IEC 62304:2006 “Medical device software – Software life cycle processes”
国・地域
規制当局
説明原文
参考和訳
Australia
オーストラリア
Therapeutic Goods Administration (TGA)
保険省薬品・医薬品行政局
All medical devices are required to meet Australian Essential Principles (EPs). IEC 62304 - Software lifecycle process (or equivalent or better) and IEC 62366 - Usability engineering (or equivalent or better) are referenced in the supporting data form and compliance with these standards is used as evidence of compliance with the EPs.
すべての医療機器は,オーストラリア基本原則に適合することが要求されます。IEC62304--ソフトウェアライフサイクルプロセス(または,同等かそれ以上)IEC62366—ユーザビリティエンジニアリング(または,同等かそれ以上)は申請書フォームで参照され,そして,これらの規格への適合は基本原則への適合の証拠として使用されます。
Brazil
ブラジル
National Health Surveillance Agency (ANVISA)
ブラジル国家衛生監督庁
All medical devices must meet requirements of safety and effectiveness. IES 62304/2006 may be employed in technical reports (technical dossiers). It is currently not mandatory to be certified on that standard.
すべての医療機器は安全性と有効性の要求を満たさなければなりません。IEC 62304:2006は技術報告書(技術的な関係書類)で使われるかもしれません。現在,この規格の認証は義務ではありません。

20168月より,IEC 62304:2006への適合が求められるようになる。
Canada
カナダ
Health Canada (HC)
カナダ保健省
In Canada, conformance to specific standards is not mandatory. However, evidence of conformity to recognized standards can be submitted to demonstrate that specific requirements of the Medical Devices Regulations have been met. HC publishes a list of recognized standards, and the level of evidence expected is equivalent or better” to these recognized standards.
IEC 62304:2006 is currently a recognized standard, and represents an accepted approach to the software development process for medical devices.
カナダでは,特定の規格への適合は義務ではありません。しかしながら,認知規格への適合の証明は医療機器規制の要求を満たしていることを示すために提出することができます。カナダ保健省は認知規格のリストを公開しており,期待される証拠のレベルはこれらの認知規格に対して「同等か,それ以上」です。
IEC 62304:2006 は現在,認知規格の一つであり,医療機器のソフトウェア開発プロセスとして受け入れられているアプローチです。

China
中国
China Food and Drug Administration (CFDA)
中国食品医薬品局
The IEC 62304:2006 had been translated into China industry standard: YY/T 0664-2008 equally and implement from 2009.6.1, it isnt mandatory standardand just is recommended standard.
IEC 62304:2006は中国産業標準YY/T0664-2008に翻訳されており,200961日より実行しています。
この規格は強制規格ではなく推奨規格です。
Europe
ヨーロッパ
European Commission
(EC)
The corresponding European standard EN 62304:2006 is a European harmonized standard, which provides presumption of conformity with legal requirements on development lifecycle for software which are incorporated in medical devices and software which are medical devices in themselves. The use of this standard (to the extent specified in its Annex ZZ) provides one solution for compliance with the relevant legal requirements. Compliance with the legal requirements can however be ensured also by other means.
対応する欧州規格 EN 62304:2006は,医療機器に組み込まれるソフトウェア及び医療機器としてのソフトウェアが,開発ライフサイクルの法的要求事項に適合しているかを判断するための欧州整合規格です。
関連する法的要求への適合の一つの解決策を提供します。しかしながら,他の手段でも法的要求への適合を示すことができます。
Japan
日本
Ministry of Health, Labor and Welfare (MHLW)
厚生労働省
Pharmaceuticals and
Medical Devices
Agency (PMDA)
独立行政法人 医薬品医療機器総合機構
IEC 62304:2006 is not referred to so far, but, for example, it may be used for rational explanation through a pre-market application process to satisfy the EPs that align with those defined in GHTF/SG1/N68:2012 Essential Principles of Safety and Performance of Medical Devices.
IEC 62304:2006 は今のところ参照されていません。しかし,市販前申請においてGHTF/SG1/N68:2012医療機器の安全性と有効性の基本要件で定義されている基本要件への適合証明への根拠の説明に使用されるかもしれません。

※訳注 2017年11月25日以降は実質的に要件となる。


IEC 62304 実践ガイドブックを編纂した理由

「はじめに」より引用

IEC 62304(医療機器ソフトウェア-ソフトウェアライフサイクルプロセス)はEUではすでに,日本では2017年11月より医療機器ソフトウェアに対して実質的な規制要件となります。 
このように,IEC 62304は各国の医療機器ソフトウェアの規制要件として採用されつつあり,対象となる仕向地で医療機器を販売するためには,医療機器ソフトウェアがIEC 62304に適合していることを証明することが求められます。
適合証明の方法として第三者認証機関で試験を受ける場合もあります。IEC 62304は医療機器ソフトウェアの開発や保守についての「プロセス規格」であることから,電気的安全性試験のように,誰が試験を実施しても同じ結果にはならず,規格に対する知識レベルや経験が不十分なために判定結果や見解が変わったり,試験結果に詳細な説明を付け加える必要があったりします。医療機器ソフトウェア開発者にとって規格適合が目的になってしまうと,規格要求事項は形式化,形骸化してしまい,「高品質で安全な医療機器ソフトウェアを継続して製造するための開発プロセスとその要求事項を示す」というIEC 62304の本来の目的から乖離してしまう危険性があります。
また,IEC 62304はJIS T 2304として邦訳版を入手することも可能ですが,規格を読んだだけでは,規格策定にかかわった各国のエキスパートらの議論の過程や意図が読者に十分に伝わらないこともあります。
そこで,IEC 62304や関連する国際規格の策定にかかわったISOやIECの国際エキスパートが中心となり,また,IEC 62304の実戦経験が豊富な一般社団法人 電子情報技術産業協会(JEITA)のヘルスケアインダストリ事業委員会 / 医療用ソフトウェア専門委員会の有志の監修のもと本ガイドブックを作ることにしました。本ガイドブックのコンセプトはIEC 62304の趣旨と要求内容を正確に読者に理解してもらい,IEC 62304の本来の目的である「高品質で安全な医療機器ソフトウェアを継続して製造する開発プロセス」が実践できるようになることです。 
本書の読者には,医療機器の製造業者(薬事担当,ソフトウェア開発担当),医療機器の製造販売業者(薬事担当,QA担当),ソフトウェア開発受託業者や,医療機器ならびにヘルスケア業界への新規参入を目指している方々,さらには未来の医療機器ソフトウェア技術者を育成するアカデミアの方々を想定しています。 
執筆者一同,本ガイドブックが高品質で安全な医療機器ソフトウェア開発の一助となることを願っています。
2016年8月 執筆者一同

今後,このブログサイトでも,少しずつ,本ガイドブックの内容を解説してきたいと思う。


2016-07-04

テスラ社死亡事故で考える Intended Use (意図する使用)


GHS(ヘルスソフトウェア推進協議会)のリスクマネジメントトレーニング講座で,Intended Use(意図する使用)が決まっていないとリスク分析はできないと教えている。

Intended Use を決める・定義するということは,製造業者が提供する製品やサービスにおいて,誰が,何を,どのように使うことを意図しているのかを明確にすることである。

日本人の技術者は特にこれが苦手だと感じる。

その理由は,多くの日本の製造業者がすでに市場にある自社製品やライバル会社の製品の機能や性能を模倣・継承して,それらに付加価値として追加することで「売れる」製品を作ることができてしまうからではないかと考えている。

だから,日本の技術者は自分が開発に携わった製品の新たに付け足した機能や性能のことはスラスラと答えることができるのに,その製品の Intended Use (意図する使用)は何かと聞いてもバシッと答えが返ってこない。

こちらが聞いているのは,付け足した付加機能のディテールではなく,基本機能や基本性能を誰のために,何のために作ったのかを答えた欲しいのだが,そういった基本機能・基本性能は,すでに前の機種で実現してしまっていて,再利用するだけなので,付け足し機能しか担当していない技術者の頭の中に残らないのだろう。

しかし,製品やサービスの基本機能や基本性能が故障したり不具合を起こしたりすると,とたんに大問題となる。だから,市場で不具合が発覚してリコールになったりしたときにはじめてそれが製品にとって重大な機能だったのだと気が付いたりする。

GHSのセミナーでは,Intended Use を説明するのにMobile MIM という iPad iPhone のアプリケーションソフトウェアを例示している。

このアプリケーションソフトウェアは,医療機器である画像診断装置のデータをクラウド上に格納し,その画像を iPad や iPhone で閲覧するソフトウェアだ。iPhone を持っている方は,アプリをダウンロードしてサンプル画像を無料で見ることができるので試してみるとよい。

このアプリは,2008年に 米国FDAに医療機器としての申請をしており,3年間に渡るFDAの交渉を経て,医療機器と認められている。

この経緯はアプリのようこその Mobile MIMのストーリーに書いてあるので,読んで見ると面白い。

そして,ユーザーガイドの配下に左記の使用目的が書いてある。

日本語では使用目的となっているが英語モードで表示させると Intended Use だ。

Intended Use には,「何の目的のソフトウェアであるか」「アプリが扱う医療画像は何から得たものか」がまず書かれている。

そして次が大事なのだが,このアプリは医療行為に関わることとして「放射線治療のプランを承認することに使用できる」と書いてある。

そしてさらに重要なのは,このアプリが医療機器である画像ワークステーションに取った代わるように設計していないことと,画像ワークステーションへのアクセスができないときにのみ使用すべきと明示している。

そういった場合であってもマンモグラフィには使用できないと明確に書いている。

ようするに Intended Use を定義した上で,でできることと,できないことをはっきりと書いているのだ。

このような書きぶりは,海外の医療機器では珍しくない。海外の医療機器ではIntended Useの中で,できることと出来ないことがはっきりと書かれている。

米国で特にそういう書きぶりになるのは,できることと出来ないことを明確にしておかないと,その製品で事故が起こったときに,製造業者側の責任分解点が曖昧になるからである。

なお,訴訟対策という意味以外でも,冒頭に書いたように Intended Use が明確になっていないとリスク分析ができない。

Mobile MIM に関して言えば,「放射線治療のプランを承認する」目的での使用は意図しているので,その目的に際して,間違った判定にならないようにリスク分析を行い対策しておく責務が製造業者側に生まれる。

おそらくそのためであろう。このアプリは自然光が強い場所では使えないように,医療用途で使用する場合には,少しだけコントラストを変えたエリアをランダムに表示させて,そこをポイントできないと先に進めないようなくふうがされている。

これは,微妙な輝度の違いを読み取れないような環境でアプリを使うと誤診につながるので,それを回避するためのリスクコントロール手段である。想像するにFDAと何回も Intended Use と想定されるリスクについて議論した末に設定したリスクコントロール手段だと思われる。

そして,何を意図しているのかと同様に「何を意図していないのか」ことも明確に示した。これによって「製造業者が意図していないこと」をユーザーが行った場合は,誤使用となる。医療機器ドメインでは「合理的に予見可能な誤使用」は製造業者の責任でリスクコントロールをする義務があるが,Intended Use で明確に出来ないこと,意図していないことを明示している場合に,ユーザーがそれをやってしまった場合は,よっぽどのことが無い限り,製造業者の意図に反した誤った使い方となる。

日本人がこのような Intended Use を見ると,販売に悪影響がでるのではないかと思うかもしれない。しかし,組織が取扱説明書等で出来ないと書いているのに,セールスの担当者が「公式にはできないと書いてありますが,実際には多くのお客さんがこんな使い方をしていますよ」などとユーザーに耳打ちしていれば,FDAは取扱説明書上に明記された Intended Use と 医療機器の使用の実態との乖離を許さない。

さて,2016年6月30日に米テスラモーターズの「自動運転モード」作動中に初の死亡事故が起きた。(日経記事

死亡した運転手は自動運転中にポータブルDVDプレーヤーでハリーポッターのDVDを鑑賞していた可能性があるらしい。(ロイター記事

この記事の中で,下記のように書かれている。
事故車となったセダン「モデルS」の2015年モデルの運転手が道路を見ていたのかどうかという疑問は、テスラにとって重大な意味がある。同社は、オートパイロットの安全性に関して連邦当局から予備調査を受けている。  
オートパイロット搭載車は運転しなくても、車線内を走行し、スピードを維持できる。同社は1日に声明を出し、「オートパイロットは路上での最先端のドライバー支援システムだ。ただ、これにより、テスラ車が自律走行車になったり、運転車が責任を放棄できたりするわけではない」との見解を示した。  
この,「オートパイロットは路上での最先端のドライバー支援システムだ。ただ、これにより、テスラ車が自律走行車になったり、運転車が責任を放棄できたりするわけではない」というテスラモーターズの主張に思い切り突っ込みを入れたい。

テスラモーターズは オートパイロット機能による自動運転を Intended Use として意図しているのか,意図していないのかを明確にしておらず,曖昧なままにして,状況によって都合良く解釈していないかと。

ようするに,ユーザーがオートパイロットに任せきった運転をすることを想定もしくは,黙認しながら,公式には自律走行は許していないとする,2つの顔を使い分けていないかということだ。

こういうことをすると,有効なリスク分析できない。製造業者として意図していることと意図していないことが明確になっていないから,運転手がオートパイロットに運転を任せきってしまうことが,正常使用なのか,明確な誤使用なのか,それとも合理的に予見可能な誤使用なのかがはっきりしない。

自律走行を意図していないのなら,まず,「オートパイロット」で運転手が運転を任せてしまうことは禁忌・禁止として,明確に,常に意識できるようにラベリング(みえるところに表示する)必要があり,かつ,そうしてでも運転を任せきってしまうことは合理的に予見可能な誤使用としてありうると考えて,リスクコントロール手段を講じることが必要だ。

例えば,運転手の視線が前方を向いていなければ警告音を鳴らすといったリスクコントロールだ。

こういったリリスクコントロール手段にはコストがかかるから,やるやらないの判断するためには,組織として承認された Intended Use が必要になる。そこがはっきりしないと,開発の過程で組織の都合のよい解釈が成されて,リスクが残ったまま,製品が市場で使われることになる。

今一度,自動車メーカーに問いたいのは自動車メーカーは「運転手から運転を解放するため」に自動車に自動運転機能を装備しようとしているのではないのかということだ。目標は高く掲げ,社会への貢献を高らかに謳い,「やっちゃえ」と言ってユーザに期待させておきながら,事故が起きると責任は回避するという態度はいただけない。

医療機器の場合,単純化すると,製造業者が「診断」「治療」「予防」を標榜すると医療機器として規制されることになる。支援するとか,補助するとかで,誤魔化すのではなく,左記のようにビシッと線を引くことが Intended Use を定義することになる。

自動運転機能を自動車に装備する目的は「運転からの開放」なのに,事故が起こったときだけ「自動運転はあくまでも運転の補助だ」と言っていないか。上の図の例だと線が右にいったり左にいったりしていないかということだ。

「運転からの開放」か「あくまでも運転の補助かなのか」の使用目的の違いによって,リスク分析の結果や必要なリスクコントロールが変わってくる。

だからこそ,大事なのは「その機能があるかないかではなく,製造業者がどんな意図でその機能を製品に搭載したのかという意図の問題」だ。それが Intended Use を特定することだ。

そして,その機能を意図して搭載すると決めたのなら,その使用目的を想定したリスク分析を行い,リスクが受容できるまでリスクコントロール手段を講じなければいけない。

Mibile MIM の例では「放射線治療プランの承認に使用することを意図する」と決めたから,放射線治療プランを誤って承認するリスク(例えば実際には病巣があるのにないと判断して治療が遅れ病状が悪化するなど)が抽出され,リスクコントロール手段を取ることができたのだ。

Intended Use を曖昧にしていると「コントラストが確認できない状況でアプリを使わせてはいけない」というリスク分析が出てこないかったかもしれないし,コストがかかるからといわれ採用できなかったかもしれない。

自動運転に関しては,何のためにその機能を搭載するのかの Intended Use を定義しないまま,自動車業界は世の中のムードや早く実現しろというプレッシャーに押されて開発を進めていないだろうか。

一番危ないのは,サプライヤーが「その機能作れって言われたので作りました」というスタンスで部品として自動運転の機能を自動車メーカーに提供するというケースだ。

「ASIL-D として自動運転機能を仕上げましたので安心してどうぞご使用ください」というスタンスだと,Intended Use をベースにしたリスク分析やリスクコントロール手段に結び付かない。ようするに自動運転が「運転からの開放」なのか,「運転の一部肩代わり」なのか曖昧なままでは,リスク分析の結果とリスクコントロール手段が変わり,受容できないリスクが残留するいうことだ。

また,事故が起こってからリスクコントロール手段を考え直すということを繰り返していくと,付け足したリスクコントロール手段が新たなリスクを生む可能性がある。

医療機器業界は,そういった経験を繰り返した結果,機能安全(Functional Safety)とは異なる,リスクベースアプローチ(Risk Based Approach)を中心した基準を確立してきた。

自動車業界は今後,自動車運転を未来に向かって推し進めようとするならば,自動運転の Intended Use を明確に定義すべきだ。

運転支援だなどと曖昧にごまかして,事故が起こらないうちは,さんざんメリットとして宣伝に使い,いざ事故が起こったら使用者の誤使用にして責任を逃れるやり方は許されない。

これまで自動車は走る・止まる・曲がるの基本性能と付加価値となる機能の間に独立性があったが,時代が変わって,付加価値の機能と基本機能・基本性能が絡み合うようになってきたのだと思う。

医療機器の世界では,ひとつに特定しきれないさまざまな機能をもった機器があり,その使い方に絡む事故もたくさん起こっていたので,事故の再発防止のためにも Intended Use の定義とリスクマネジメントの重要性が叫ばれてきた。

自動車業界もITとの融合が本格的になってきて,Intended Use を明確にしなければ,有効なリスク分析ができず,これまでにはなかった複雑な要因の事故が多発する世界に足を踏み入れてきたのではないだろうか。

P.S.

テスラ社の事故に関して「これは運転支援システムであるから,ドライバーが運転を機械任せにしてしまったことが間違い」という識者の見解を散見するが,こういう考え方をしていると未来に発生するであろうオートパイロットの事故は減らない。オートパイロットを導入することで交通事故が減少するというメリットと天秤にかけるという考え方はあるが,それを正当化したいのなら社会的なコンセンサスを得たうえで,利用者にもリスクを理解させ,オートパイロットの使用における禁忌・禁止事項を守らせることが必要だと思う。