2020年の医療機器ソフトウェアに求められる要件の予想

前回のブログ記事『ソフトウェア製品の認証は可能か？』で，医療機器では「基礎安全，基本機能，基本性能」「リスクマネジメント」「ソフトウェアライフサイクル」「ユーザビリティ」の4つについて正当性を示すことが規制当局から求められると書いた。

適合が求められる規格でこのことを表すとこの図のようになる。

専用のハードウェアにソフトウェアを搭載する医療機器の場合は，製品安全規格として IEC 60601-1 と，ソフトウェアライフサイクルプロセス規格として IEC 62304 が求められる。汎用のITプラットフォーム上で動作する医療機器ソフトウェアの場合は，製品安全規格として，IEC 82304-1と ソフトウェアライフサイクルプロセス規格 の IEC 62304 が求められる。（IEC 82304-1 は規制要件になるかどうかはまだ決まっていない）

IEC 82304-1 は 2018年3月1日に JIS T 82304-1 として日本語で参照できるようになった。この規格の目次は次のようになっている。

JIS T 82304-1 目次

1. 目的及び適用範囲
2. 引用規格
3. 用語及び定義
4. ヘルスソフトウェア製品の要求事項
5. ヘルスソフトウェア－ソフトウェアライフサイクルプロセス
6. ヘルスソフトウェア製品のバリデーション
7. ヘルスソフトウェア製品の識別情報と附属文書
8. ヘルスソフトウェア製品の市販後活動

箇条5 は IEC 62304 を参照しているので，IEC 82304-1 がソフトウェアライフサイクルプロセスの要求として IEC 62304 を呼んでいる形になっている。

ようするに，ライフサイクルプロセスの要求に加えて，製品の要求事項を明確にした上で，バリデーションの計画，実施，報告を行い，製品の識別情報や附属文書への記載内容を指定し，さらに，市販後の活動も行うことでヘルスソフトウェア製品の安全を実現しようとしている。

なお，IEC 82304-1 は規制対象と規制対象外の両方のヘルスソフトウェアを対象としているのに対し，現在の IEC 62304 Ed.1.1は規制対象の医療機器ソフトウェアのみがスコープとなっている。そこで，IEC 62304 は Ed.2 において，IEC 82304-1 と同様に，規制対象と規制対象外のヘルスソフトウェアにスコープを拡大しようとしている。

どちらの規格も製品安全やリスク低減を目的としているのだが，今や規制対象のヘルスソフトウェアだけでなく，規制に至らないヘルスソフトウェアに対しても必要な要件があるという考え方だ。

IEC 62304 Ed.2 は現在検討中であり，2000年までには策定されると予想される。そこで，2020年時点でのヘルスソフトウェアの規格体系を予想してみると次のようになる。

IEC 82304-1 は ヘルスソフトウェアのソフトウェアライフサイクルプロセス規格である IEC 62304 Ed.2 を箇条5で呼んでいる。IEC 62304 が Ed.2 になると一般要求事項として 品質マネジメント，リスクマネジメント，ユーザビリティを要求するようになると予想される。

品質マネジメントは規制対象の医療機器の場合は，ISO 13485（ISO 13485 は ISO 9001の医療機器版で文書化要求などが強化されている） を 規制対象外の場合は，ISO 9001でもよしとし，リスクマネジメントは ISO 14971 を，ユーザビリティは IEC 62366-1 で適合を示してもよいという方向性が検討されている。

ちなみに，ユーザビリティは 使いやすさを目的にしたユーザビリティではなく，ヘルスソフトウェア製品の使用に伴うリスクを特定しコントロールすつためにユーザビリティエンジニアリングを要求している。また，セキュリティに関してもヘルスソフトウェアの安全に影響する脅威を特定，評価し，対策することを求めている。

医療機器ソフトウェアについては 2020年に向けて「バリデーションを含む製品安全」「ソフトウェアライフサイクル」「品質マネジメント」「リスクマネジメント」「安全のためのユーザビリティ」「安全のためのセキュリティ」を求めることで，医療機器ソフトウェアの製品安全を確立しようとしている。

このブログで繰り返し主張しているように，ソフトウェアのプロセス要求だけで，ソフトウェアの製品安全を示すことは出来ず，いろいろな確度から安全について証明していく必要があるということだ。

セキュリティはソフトウェア製品がネットワークで他のソフトウェアとつながるようになって，また，ユーザビリティはユーザインタフェースがリッチになるに従って，使い方を間違うことで危害に至ることが増えてきたことが背景にある。

また，バリデーションやリスクマネジメントが重要視されてきたのは，システムを構成する個々のソフトウェア部品の信頼性を高めることでは，システム全体の安全性や信頼性を確保できないほど，ソフトウェアは大規模・複雑化していることを示している。

「バリデーションを含む製品安全」「ソフトウェアライフサイクル」「品質マネジメント」「リスクマネジメント」「安全のためのユーザビリティ」「安全のためのセキュリティ」ひとつひとつが規格に適合しているしていないということに着目するのではなく，そのシステムに対してどの要求がどのように安全に寄与しているのかをよく考えて，全体として安全を確かなものにするにはどこを強く抑えると効果的かを考えることが求められるようになる。

規格適合は過程であって目的ではない。このことを忘れてはいけない。