近年、規制当局（特にFDA）は医療機器におけるソフトウェアの承認審査を強化してきている。
2010年にFDAは510(k)プロセスの見直しを実施した。従前は510(k)におけるソフトウェアのレビュがかなり不十分だったため、安全性の確保されていない機器が市場に出回り、市場での機器のリコールが相次いだ。
その結果、FDAは議会から糾弾された。
そのため、FDAは以下のページにまとめられているようなアクションプランを立てた。https://www.fda.gov/aboutfda/centersoffices/officeofmedicalproductsandtobacco/cdrh/cdrhreports/ucm239448.htm
また、下記資料の196ページを見ると、FDAが510(k)サブミッションに対し、AI（additional information：申請資料における追加資料の提出）を要求する率が上昇していることが分かる。https://www.fda.gov/downloads/ForIndustry/UserFees/MedicalDeviceUserFee/UCM575208.pdf
本邦においても、2017年11月より、IEC 62304（医療機器ソフトウェア ‐ ソフトウェアライフサイクルプロセス）が実質的な規制要件となった。
IEC 62304は、2006年5月に発行され、日本では2012年にJIS化（JIS T 2304）された。2014年11月に施行された医薬品医療機器法第12条第2項において参照される「最新のライフサイクルモデル」となっている。
IEC 62304は、米国FDAにおいても2008年7月にRecognized Consensus Standardと認定されている。
IEC 62304は「医療機器ソフトウェア」の開発と保守に関するプロセスを規定している。
日本以外でも欧州・北米・中国などにおいて医療機器申請時にIEC 62304に基づくソフトウェア開発の証拠が必要である。
つまりIEC 62304に従って「医療機器ソフトウェア」を開発しなければ、国内外においてソフトウェアを搭載した医療機器（単体プログラムを含む）を販売することができない。
しかしながら、IEC 62304は非常に難解である。
一般にプロセス規格は各社によってまちまちの解釈が行われ、手順書の内容が大きく異なってしまう。
かと言ってIEC 62304は特別なソフトウェア開発方法論を要求しているわけではない。いわゆるウオーターフォールモデルのソフトウェア開発である。
最も特徴的なのはソフトウェアの安全性クラスの定義であろう。
FDAのGeneral Principles of Software Validation（GPSV）でも同様のことが言えるが、安全性にかかわる設計とそれ以外をアーキテクチャ仕様書で明確に区別しなければならない。
ここで注意が必要であることは、FDAのGPSVはリスクコントロール手段を講じる前のリスクをもって安全性を測ることに対して、IEC 62304は他のコントロール手段（例：メカ設計、エレキ設計等）によってリスクが低減される場合、その低減後のリスクを用いて安全性分類を行っても良いとしていることであろう。
Comment