EN 62304:2006 の実施におけるよくある質問(MDD 93/42/EEC 関連) 第1版 2013年4月5日

1 略語

小型英大文字で書かれた単語は、定義済み用語です。IEC 62304 の“用語及び定義"セクションを参照して下さい。

AIMDD: Active Implantable Medical Device Directive (能動型埋め込み医療機器指令)
CMS: Configuration Management System (構成管理システム)
COCIR: European Coordination Committee of the Radiological, Electromedical and Healthcare IT Industry (欧州放射線・医療電子機器産業連合会)
COTS: Commercial off-the-shelf (市販製品)
EEC: European Economic Community (欧州経済共同体)
EUROM Ⅵ: European Federation of Precision Mechanical and Optical Industries - Medical Technology (欧州精密光学産業連合会医療光学部門)
FPGA: Field Programmable Gate Array (フィールドプログラマブルゲートアレイ)
GPO: General Practitioner's Office (一般開業医の診療室)
IEC: International Electrotechnical Commission (国際電気標準会議)
ISO: International Organization for Standardization (国際標準化機構)
IVDD: In-Vitro Diagnostic Directive (体外診断用医療機器指令)
MDD: Medical Device Directive (欧州医療機器指令)
MEDDEV: Non-binding guidance for Medical Devices, endorsed by EU Member States (EU 加盟国によって承認された強制力のない医療機器ガイダンス) http://ec.europa.eu/health/medical-devices/documents
MPBetreibV: Medizinprodukte - Betreiberverordnung Verordnung uber das Errichten, Betreiben und Anwende (医療機器の設定、操作、使用及び保守を管理する医療オペレーター規制) ドイツのみ該当
NBs: Notified Body, Notified Bodies (ノーティファイドボディ(NB))
PEMS: Programmable Electrical Medical System (プログラマブル電気医用システム)
SAAS: Software as a service (サービス型ソフトウェア)
SDD: Software Detailed Design (ソフトウェア詳細設計)
SIL: Safety Integrity Levels as per IEC 61508 (IEC 61508 準拠の安全度水準)
SOUP: Software of Unknown Provenance (開発過程が不明なソフトウェア)
TÜV: Technischer Überwachungsverein (技術検査協会)
VDE: Verband der Elektrotechnik, Elektronik und Informationstechnologien (電気、電子情報技術協会)

2 質問と回答

2.1 EN 62304 の適用範囲

2.1.1 EN 62304 規格が関連しているのは、MDD( 93/42/EEC)だけですか。

回答: いいえ、この規格は 3 つの指令すべての整合規格ですが、説明を分かりやすくするため、本ドキュメントでは MDD にのみ言及しています。

2.1.2 ソフトウェアは、どのような場合に医療機器と見なされますか。

回答: MEDDEV 2.1/6(第 2 章)を参照して下さい。

2.1.3 規格は、どうやってオープンシステムとクローズドシステムを区別しますか。

回答: この規格にクローズドシステムとオープンシステムの区別はありません。

2.1.4 以下のソフトウェアが医療目的であると仮定した場合、この規格は、これらのソフトウェアに適用されますか。

a) SAAS
b) FPGA のソフトウェアなどの単一チップコンピュータに組み込まれたソフトウェア
c) FPGA を設計するハードウェア記述言語
d) スタンドアロンソフトウェア
e) 医療用アプリケーション (Medical Apps)
f) エクセルマクロ (Excel macros)
g) オープンシステムとクローズドシステム
h) インターネット又はクラウドベースソフトウェア
i) サーバベースシステム
j) ネットワーク機器

回答: 意図した使用[Intended Use]からソフトウェアを医療機器としてみなせる又はソフトウェアが医療機器の一部であるならば、これらのソフトウェアを目的に基づいて実行する間は、この規格が適用されます。

a) SAAS
場合によって、提供されるサービスはソフトウェアの使用だけではなく、次に示すような様々な追加サービスを含むことがあります。:
- データ保存機能
- 医学的専門診断支援(expertise)/診断(decision)
MDD は、提供されるすべてのサービスを対象とする訳ではありません。MDD が対象とするのは、医療機器の設計、製造及び規制上の市販後活動だけです。しかしながら、より広範なサービスの一部として使用されることを意図したソフトウェアのサービス環境下における特有のリスクを管理するのは、当該ソフトウェアの法律上の製造業者の責任です。

b) FPGA のソフトウェアなどの単一チップコンピュータに組み込まれたソフトウェア
ソフトウェアが意図した運用においてプロセッサ(FPGA に含まれる場合もある)上で実行される場合は、EN 62304 が適用されるソフトウェアアイテムです。

c) FPGA を設計するハードウェア記述言語
FPGA製造中に実現される仕様(例えば、ハードウェア記述言語で書かれた)はツールと見なし、医療機器には該当せず、IEC 62304 の意味するソフトウェアアイテムではありません。

d) スタンドアロンソフトウェア
2007年以降MDDは、医療機器に組み込んで使用することを意図していなくても、意図した使用[Intended Use]に医療用途を含んでいるものはソフトウェア自体を独立した医療機器と見なしています。

e) 医療用アプリケーション
入手とインストールは容易ですが、医療目的で使用されるアプリケーションは、MDD の適用範囲に該当し、EN 62304 に基づいて作成する必要があります。

f) エクセルマクロ
医療目的で販売されるエクセルマクロは、MDD の適用範囲に該当し、EN 62304 に基づいて作成する必要があります。但し、臨床医が自身でマクロを作成した場合、又は既存のマクロを修正した場合、このマクロをドイツで使用する場合、MPBetreibV の適用を受けます。他の加盟国では、別の要求事項が適用されます。

g) オープンシステムとクローズドシステム
質問 2.1.3 を参照して下さい。

h) インターネット又はクラウドベースソフトウェア

i) サーバベースシステム

j) ネットワーク機器
MDD の定義に適合するインターネットベース、サーバベース又はクラウドベースのソフトウェアは、医療機器です。汎用オペレーティングシステム又はネットワークソフトウェアはどれも SOUP です。ネットワークや保存機能のような MDD の付属品の定義を満たしていない汎用の市販ハードウェア機器はどれも非医療コンポーネントです。但し、そのようなハードウェアアーキテクチャに関連するリスクは、医療機器リスクマネジメントファイルで管理する必要があります。

2.1.5 製造業者は、EN 62304 に基づくプロセス証明書及び製品証明書を取得できますか。

回答: NB の中には、EN 62304 関連のサービスを提供し“独自の(private)"証明書を発行しているところもありますが、そのような証明書はまだ具体的な認証評価に該当しないため、必須ではありません。

2.1.6 医療 IT ネットワークに組み込まれた医療機器のライフサイクル管理に関して、EN 62304はどのような情報を提供していますか。

回答: EN 62304 は医療機器に含まれるソフトウェア又はそれ自体が医療機器であるソフトウェアに適用されるため、医療 IT ネットワークに関するいかなる情報も提供していません。

2.1.7 EN 62304 は、「ソフトウェアバリデーションの一般原則」(FDA 発行)における製品ソフトウェアに関するすべての要求事項を対象としていますか。

回答: EN 62304 は、ソフトウェアバリデーションを対象としていません。意図的に規格の適用範囲外にしています。組込みソフトウェアに関しては、PEMSのバリデーションはシステムレベルのアクティビティなので、EN 60601-1(第3 版)の箇条 14 で扱われています。作成中の IEC 82304 [訳注:ISO/IEC 82304-1 は Healthcare software systems -- Part 1:General requirements でまだ発行されていない。]は、ソフトウェア単独の製品(スタンドアロンソフトウェア)のバリデーションを対象とする予定です。EN ISO 13485:2012 もまた細々分箇条 7.3.6 で設計と開発についての要求事項を規定しており、この規格(ISO13485 は、EN 62304 の下では必須ではないが)が、上記の製品のバリデーションを直接的に扱わない要因となっています。FDA ガイダンスが使用する用語“バリデーション"には、EN 62304 の範囲に含まれる検証アクティビティと、検証済みソフトウェアがユーザのニーズと意図した使用[IntendedUse]を満足させていることを確認する妥当性確認の両方を含んでいます。

2.1.8 ソフトウェアのバリデーションと最終リリースは EN 62304 に含まれていませんが、どの規格がこれらのアクティビティが MDD への適合を実現/証明できるような要求事項を提供していますか。

回答: 組込みソフトウェアの場合、バリデーションはシステム全体を対象に EN 60601-1(第 3版)の箇条 14 で扱われています。医療用スタンドアロンソフトウェアの場合、現行のどの規格も MDD のバリデーションに関する基本要件を扱っていません。しかしながら、EN ISO 13485 のような品質マネジメント規格を適用するスタンドアロンソフトウェアの製造業者は、この規格のバリデーション要求事項を満たす必要があります。

2.1.9 EN 62304 の適合について NB が期待するものは何ですか。

回答: EN 62304 の適合により、MDD 基本要件との整合性を期待できます。規格を適用しない場合、製造業者は、ソフトウェアが対応する基本要件に適合することを示す別の客観的証拠を提供しなければなりません。規格の適用は任意ですが、それにより現在の最新技術水準[the current state of the art]が分かるので、NBはそれを製造業者の客観的証拠を評価する枠組みとして使います。

2.1.10 ある程度の適合しか要求されない場合、それに合わせて規格をテーラリングすることは可能ですか。

回答: ソフトウェア製品は、指令の適用すべき基本要件に適合しなければなりません。EN62304 は、適用する指令の適合要求の裏付けとして利用できます。“適合の度合い"の観点から規格をテーラリングすることはできません; 但し、ソフトウェアの安全クラス分類に応じて、規格が必要とする内容と文書化の範囲についての要求事項は調整されます(クラス A のソフトウェアは要求が少ない)。それでもなお、EN62304 への適合が要求される場合は、適用されるすべての事項について、完全適合を実現する必要があります。

2.1.11 規格の新バージョンが発行された場合、当方の組織は全面的な再評価をする必要がありますか。

回答: IEC 62304 第 2 版がどう改訂されるかによります。また MDD の要求事項に関しては、第2 版が整合され、第 1 版に優先するかどうかによります。

2.1.12 クラス A ソフトウェアについて

正真正銘のクラス A ソフトウェアに対しても EN 62304 の使用を勧めていますが、定義により“負傷又は健康障害の可能性はない"のですから、クラス A に対する規制影響がある整合規格の現状は、制約だとは思いませんか。

回答: いいえ、要求事項は、医療用ソフトウェアを開発/保守する際、それが実際にクラス Aであることを証明するために実行すべきアクティビティとタスクの最小セットです。ライフサイクルの間に、リスク分析を更新してソフトウェアを再度クラス分類する必要があるかも知れません。

2.1.13 IEC 60601-1-4(PEMS)が IEC 60601-1 箇条 14 と置き換えられたので、EN 62304 も更新されると考えるべきですか。

回答: IEC 62304 の改訂は進行中で、2015 年に発行されると予想されますが、今回の IEC60601 の変更は、IEC 62304 改訂が要因ではありません。したがって、IEC 60601 の変更は、IEC 62304 改訂版の変更につながらないでしょう。

2.1.14 IEC 82304 を作成する目的は何ですか。

回答: IEC 82304 の主な目的は、バリデーションやラベリングのようなソフトウェア単独の製品に対する製品関連の要求事項を単一の製品規格で扱うことです。

2.1.15 医療機器ソフトウェア、ヘルスソフトウェア及びヘルスケアソフトウェアの名称は、理解するのが容易ではありません。各カテゴリには、どんなタイプのソフトウェアが含まれるのでしょうか。これらの 3 つの異なるカテゴリの定義を表にしてもらえませんか。

回答: EN 62304 が使用するのは、医療機器ソフトウェアという用語だけです(3.12)。その他の用語の定義は、現在開発中です(例えば、IEC/CD 82304 を参照)。

2.2 医療機器ソフトウェアの上市

2.2.1 スタンドアロンのソフトウェア製品に対する MDD の基本要件を満たすには、EN 62304 だけで十分ですか。

回答: いいえ、EN 62304 の適合は、MDD 附属書Ⅰのすべての基本要件への適合性を保証するものではありません。EN 62304 は、例えば、ソフトウェア製品のユーザビリティ面、臨床評価及び最終バリデーション又は取扱説明書のような付属文書の必要性を扱っていません。したがって、適用されるすべての基本要件の完全な実施を示すためには、別の規格や手順を検討する必要があります。(整合規格が適用されない場合、製造業者は同等の代替手段を明記し、その正当性を証明する必要があります。)

2.2.2 EU ガイドラインや適合性に係わるこれらのすべての負担を負う代わりに、当社のソフトウェアの意図した使用[Intended Use]として、診断又は治療に使用すべきではないと書こうと思います。それでもよろしいですか。そうしないと他の開発者と競争できません。

回答: それはあなたの責任です。意図した使用[Intended Use]の記述には注意して下さい。あなたの製品が多くの人に医療機器として使用されるならば、そして製品がそのように使用できる機能を明確に持っているのなら、ソフトウェアの承認適応症外使用の責任を問われるかも知れません。さらに、あなたの製品が MDD の適用範囲でない場合、より厳しい安全性要件を持つ別の規制(例えば、GPSD(一般製品安全指令))の対象となる可能性があります。MEDDEV 2.1/6(第 4 章)を参照して下さい。

2.2.3 医療機器ソフトウェアの適合性評価手順

a) クラスⅡb 又はⅢの医療機器ソフトウェア(スタンドアロンソフトウェア)は、MDD の附属書Ⅲ+Ⅴ又は附属書Ⅲ+Ⅳだけで評価できますか。
b) 製造業者が IEC 62304 の要求事項を実施したかどうかを調査する附属書Ⅱ.3 の監査中に、NB はどんな手順を用いますか。

回答: a) 指令の第 11 条によると、クラスⅡb またはⅢの医療機器は、附属書Ⅱ、附属書Ⅲ+Ⅳ又は附属書Ⅴを使用できます。しかし、MDD は医療用ソフトウェアのすべての特性を考慮に入れている訳ではありません。また、型式検査はあまり適切であるとは考えられていません。
b) QMS 監査、特に附属書Ⅱ.3 の監査は、MDD 附属書Ⅱ.3 への適合性を判断するために行われます。EN 62304 のような規格への適合性検査は、そうした監査の目的ではありません。
NB は、EN 62304 が適用されたかどうかを調べる妥当性チェックを行うために、監査中にサンプルを取ることができます。しかし、製造業者は監査結果から EN 62304 の完全適合を導き出すことはできません。2.2.4 IEC 62304 は、他の地域/国の規制承認プロセスにおいても受け入れられていますか。また要求されますか。

回答: 他の国々でも IEC 62304 は同様に受け入れられています。例えば、FDA は認識番号 13-8の下にこの規格を認めています。また同一の中国国家規格YY/T 0664としても翻訳されています。

2.2.5 当方では、要件は要件管理ツールに、設計はアーキテクチャモデリングツールに保存しています。そこで質問ですが、ツールから“.pdf"のようなファイルを作成して承認した方がよいでしょうか。それとも、それぞれのツールの保存場所に保管するだけで十分でしょうか。電子形式だけで保存するための条件は何ですか。

回答: EN 62304 では、変更要求の正式な承認を要求しています(6.2.4 及び 8.2.1 を参照)。さらに、ソフトウェアライフサイクルプロセスが組み込まれた、例えば ISO 13485 に準じる品質マネジメントシステム(4.1 を参照)では、文書の管理を要求しています。文書管理には多くの方法があり、多くのツールが存在します。“.pdf"文書の署名もその1つです。質問 2.3.3 と 2.3.4 も参考にして下さい。

2.2.6 医療機器ソフトウェアの分類:a) EN 62304 準拠の安全クラス分類と MDD 附属書Ⅸの分類に何か関連はありますか。b) 医療機器に組み込まれたソフトウェアの場合、機器の分類はどのようにして EN62304 準拠のソフトウェア分類に影響しますか。

回答: a) いいえ、規格の安全クラスと、意図した使用[Intended Use]の解釈から得られる MDD分類の間に関連はありません。b) 直接の影響はありません。

2.2.7 EN 62304 の適合を NB はどのようにして確認しますか。NB は、この適合を認証する機関として認定されていますか。

回答: NB は指令の適合を示すためにシステムと文書を評価するので、ISO/IEC 17021 の認証評価に基づく NB のシステム監査(ISO 9001/ISO 13485/指令の附属書)では EN 62304参考和訳14の完全適合は立証できません。試験所は、ISO/IEC 17025 の認証評価に基づく製品仕様書の評価又は概してソフトウェアライフサイクルプロセスの適合を認証する独自の製品プロセス監査により、EN 62304の完全適合を立証できます。試験所は次に、独自の証明書(質問 2.1.5 を参照)又は ISO/IEC 17065 の認証評価に基づく証明書を発行します。

2.2.8 製造業者は、認証されていない品質マネジメントシステムの構築で EN 62304 に適合できますか。

回答: EN 62304 は、具体的な品質マネジメントシステムを要求していません。しかしながら、4.1により、“医療機器ソフトウェアの製造業者は、顧客要求事項及び該当する規制要求事項に適合する医療機器ソフトウェアを提供する能力があることを実証する必要があります"。これは、必ずしも認証を必要としない品質マネジメントシステムで実証できます。

2.3 ライフサイクルプロセス

2.3.1 ソフトウェア開発を外部委託する場合、サービス供給業者のソフトウェア開発プロセスが EN 62304 適合している証拠として、どのようなものが求められますか。

回答: NB は、製造業者がサービス供給業者を管理することを期待しています。EN 62304 の適合に関して、サービス供給業者は、外部委託されたプロセスに対して、EN 62304 が要求するプロセスを構築し、すべての文書を作成する必要があります。製造業者は、供給業者が実行するアクティビティ及びタスクと、製造業者が実行するアクティビティを明確にする必要があります。例えば、コード開発と単体試験を外部委託する場合、サービス供給業者はそれらのアクティビティの証拠を提供し、製造業者は統合などのそれ以外のアクティビティを実行しなければなりません。

2.3.2 EN ISO 13485、EN 62304 及び EN ISO 14971 のどの認証も取得していないソフトウェア開発者にソフトウェア開発を外部委託しました。ソフトウェア開発者は、その他にどのような規制に従う必要がありますか。

回答: EN 62304、EN ISO 14971 及び EN ISO 13485 は規格で、規制ではありません。最終的に、MDD 要件に適合しなければならないのは製造業者です。どのように必要な適合の証拠を立証し、責任を分担するかは、製造業者と供給業者の問題です。両者間の契約上に合意を記載しておくことが望ましいでしょう質問 2.3.1 も参考にして下さい。

2.3.3 この規格は、米国 FDA パート 11(電子記録と署名)に記載された要求事項と同等の期待を求めていますか。

回答: EN 62304 は、具体的な品質マネジメントシステムは要求していませんが、QMS に従って実施するように作られています。EN ISO 13485 に基づくシステムでは、文書管理を要求しています。FDA の 21 CFR パート 11 は、文書の管理方法について明確にしています。FDA の 21 CFR パート 11 は、米国で市販前手続きが要求され、IEC 62304 関連情報をFDA に電子送信するときに適用されます。

2.3.4 バージョンを更新したときに、要求事項、設計、及び試験の仕様に関してどんなレビュープロセスを適用すべきですか。正式な承認は必要ですか。

回答: 製造業者は、審査及び承認プロセスを自由に定義できます。しかし EN 62304 では、これらのプロセスが、開発するソフトウェアシステムの範囲、規模及びソフトウェア安全クラス分類に適合することを要求しています。特に、変更要求については正式の承認を要求しています。EN ISO 14971 は、リスクマネジメント関連の文書の保守管理を要求しています。さらに、品質マネジメントシステム規格である EN ISO 13485 もまた、文書の管理を要求します。例えば、EN 62304 の 5.1.8、5.2.6、5.5.2、6.2.4、8.2.1、9.4、附属書 B、及び表 C.3 を参照して下さい。

2.3.5 EN 62304 は、具体的な開発プロセスを要求しますか。

回答: いいえ、製造業者は自由にソフトウェア開発プロセスを確立できます。しかし EN 62304は、これらのプロセスが、開発されるソフトウェアシステムの適用範囲、規模及びソフトウェア安全クラス分類に適合することを要求しています。5.1.1 を参照して下さい。

2.3.6 EN 62304 が成果物を中心に構成されないのはなぜですか。

回答: EN 62304 はプロセス規格なので、アクティビティを中心に構成しています。具体的な開発プロセスに合わせて成果物を作成することは可能ですが、多くの箇条で成果物に関する要求事項が含まれていることに注意して下さい。特に細分箇条 5.1 では、計画的な文書化が必要なことを明示しています。

2.3.7 製造業者は、箇条 5-9 のプロセスを“プロジェクトレベル"で実施して、ソフトウェアの開発と保守において顧客と規制の要求事項を確保することはできませんか。

回答: はい、箇条 5-9 のプロセスは“プロジェクトレベル"で実施できますが、プロジェクトは、製品の製品寿命まで終わらないことを念頭に置いておく必要があります。2.3.8 EN 62304 の要求事項/責任を製造業者と下請け業者間で分割することに関して何か制約事項はありますか。

回答: あまりありません。大半を下請け業者に委託できます。しかし、次のような制約事項があります。 6.2.1 フィードバックの文書化及び評価 6.2.4 変更要求の承認 6.2.5 ユーザ及び規制当局への通知但し、ソフトウェアシステムに関する最終責任は、製造業者にあります。質問 2.3.1 も参考にして下さい。

2.3.9 EN 62304 は TickIT Plus とどのように関連していますか。

回答: TickITは、ソフトウェア開発に EN ISO 9001 を適用したもので、医療機器固有のものではありません。2.3.10 EN 62304 の保守アクティビティは ISO 20000/ITIL とどのように関連してますか。

回答: ISO/IEC 20000 と ITIL は、ライフサイクルサービスマネジメントを扱っており、EN 62304と比較してプロセスのフレームワークは大きいですが、お互いに矛盾することはありません。EN 62304 における保守アクティビティは、医療機器がリリースされた時点で、製造業者からの視点になります。一方 ISO/IEC 20000-1 と ITIL は、サービスマネジメント全体の中で保守を検討しています。この焦点の違いから、EN 62304 が患者とユーザのリスクマネジメントに注目し、一般的な IT で見られる“修正"アプローチよりも“予防的"保守活動を規定していることに注意する必要があります。

2.3.11 EN 62304 が要求する成果物は何ですか。以下のリストを考えてみました。概要リストと該当する EN 62304 セクションが分かると助かります。

・ソフトウェア開発計画
・ソフトウェアアーキテクチャ文書
・ソフトウェア要求仕様書
・ソフトウェア詳細設計書
・ソフトウェアユニット試験仕様書
・ソフトウェア結合試験仕様書
・ソフトウェアレグレッションテスト仕様書
・ソフトウェアユニット試験報告書
・ソフトウェア結合試験報告書
・ソフトウェアレグレッションテスト報告書
・ソフトウェア構成管理計画

回答: 規格は、以下の文書を要求します。
・リスクマネジメントファイル(4.2、7)
・ソフトウェアの安全クラス分類(4.3.c)
・ソフトウェア開発計画(5.1.1)
・ソフトウェアシステム要求事項(5.2)、リスクコントロール手段(5.2.3)を含む
・ソフトウェアアーキテクチャの設計(5.3、5.4)
・ソフトウェア試験計画(5.5、5.6、5.7、特に 5.7.1 の注記 1 と 2)
・トレーサビリティ概要(ソフトウェア要求事項に従う試験手順に関する)(5.7.4)
・ソフトウェア試験記録の内容(5.7.5)
・残留異常(5.8)
・構成管理(5.8.4、5.8.5、8)

2.3.12 どの段階で問題解決プロセスは適用されますか。問題解決は、ソフトウェアがリリースされる前の正式な設計検証段階で起こりえます。この段階で、監視が必要な異常を試験によって明らかにし、その異常を解決したことを証明する必要があります。問題解決はソフトウェアがリリースされた後にも発生します。リリース後に発見された問題が深刻な場合、修正ソフトウェアを緊急にリリースすることがあります。問題がそれほど大きくない場合は、次のリリースで修正するように計画します。一般にこの段階の問題解決は、QMS の一部として規定され、ソフトウェアよりも広範囲です。箇条 9 はどの段階で適用されますか。我々は設計検証段階のみを想定していましたが、コンサルタントによると、リリース後も適用されるようです。説明していただけますか。

回答: これはライフサイクル規格です。つまり、問題解決プロセスは、ソフトウェアシステムの開発だけでなく、リリースされたソフトウェアシステムの保守にも適用されます。例えば EN 62304 の 5.1.1 の e)、5.6.8、5.7.2、6.1 の d)及び 6.2.2 を参照して下さい。また、本 FAQ 文書の附属書 1-図 1 を参照して下さい。

2.3.13 ソフトウェアのリファクタリングは、正式な変更要求を必要としますか。
ソフトウェア業界で“技術的負債" [技術的負債:Technical debt とは、行き当たりばったりなソフトウェアアーキテクチャと、余裕のないソフトウェア開発が引き起こす結果のことを指す比喩] といわれているものを修正するために、しばしばソフトウェアのリファクタリングを行います。このリファクタリングは、将来のためにコードベースを手直ししますが、不具合や新機能とは無関係です。規格には、この種の変更についてはあまり記載がありません。
我々の結論は、ソフトウェア開発グループの中から起こる変更なのでこれらは正式な変更要求ではありませんが、適切なユニット試験と結合試験を実行し、これらの変更を変更管理システムで文書化しています。このことは、EN 62304 と一致すると思います。なぜなら、B.8.2 で技術責任者による変更要求を可能にしているからです。ソフトウェアを変更するたびに変更要求が必要になると、将来のためにコードベースを手直しする作業の妨げとなり、全く実際的ではありません。

回答: リファクタリングの定義:動作又は機能を変更することなく、ソフトウェアを手直しすること又は技術的負債を削減すること。言い換えれば、ソフトウェアの最終結果は同じままですが、結果を生成する方法が変更又は明確化されます(参考文献[6]を参照)。はい、リファクタリングは正式な変更要求を必要とします。試験と統合を開始した瞬間から、構成管理は始まります。これには、正式な変更管理が含まれます。変更要求の精度を決定するのは、製造業者の判断です。質問 2.3.4 も参考にして下さい。

2.3.14 EN 62304 の適合を証明するテクニカルファイルには、どのような情報を記述すべきですか。

回答: テクニカルファイルは、ソフトウェアの開発又は保守に適用するプロセス、アクティビティ及びタスクに関する十分な情報を提供する必要があります。テクニカルファイルはまた、その中に記述されたプロセスで生成した成果物(質問 2.3.11の文書リストを参照)に関する情報を提供しなければなりません。

2.3.15 どうすればアジャイルプロセスは EN 62304 に適合させることができますか。

回答: EN 62304 は具体的な開発プロセスを規定していません。結果的に、アジャイルプロセスも EN 62304 に適合した方法で行うことが出来ます。簡単に言えば、EN 62304 が要求するのはアクティビティと文書だけです。アクティビティは、漸進的な方法で実施され、繰り返されます。文書は、一貫性が必要とされるので、構成管理に従って管理する必要があります。詳しくは、参考文献[6]を参照して下さい。

2.4 リスク評価とリスクマネジメント

2.4.1 7.2.1 は、安全クラス B 又は C のソフトウェアアイテムが、危険状態の一因となる潜在的原因のそれぞれについてリスクコントロール手段を選択し、文書化することを要求しています。個々の原因に対する個別のリスクコントロール手段ではなく、同時に複数の原因に対処するリスクコントロール手段を作成することは容認されますか。

回答: EN 62304 の 7.2.1 は各潜在的原因に対するリスクコントロール手段を要求していますが、単一のリスクコントロール手段で複数の原因に対処することは可能です。実際、個々の原因にそれぞれ別のリスクコントロール手段を使うと、複雑になり安全性の低いソフトウェアの原因となるかも知れません。結局重要なのは、全体的なリスク低減です。

2.4.2 ソフトウェアシステムの安全クラスを変更できるのはどんなときですか。そして、その理由は。

回答: ソフトウェアシステムの安全クラスは、ハードウェアリスクコントロールによって 1 段階だけ下げる(C から B 及び B から A に)ことができます(細分箇条 4.3.a を参照)。理由は、ハードウェアリスクコントロールが、リスクを受容可能になるように故障の重大性又は結果を低減できることを前提としているからです。強調しておかなければならないのは、ハードウェアリスクコントロール手段が受容可能なレベルまでリスクを緩和できる場合に限り、安全クラスが変更可能であるということです(4.3.a を参照)。

2.4.3 ISO 14971 はどのように EN 62304 と関連しているのですか。

回答: EN 62304 は、すべての安全クラスに関して ISO 14971 準拠のリスクマネジメントプロセスを 4.2 で規定しています。また、ソフトウェアとして実装された部分に対しては、幾つかのプロセス要求事項を定義しています。医療機器に組み込まれたソフトウェア及び医療機器としてのソフトウェアの安全性と有効性を実現するためには、受け入れがたいリスクをもたらすことなくソフトウェアが仕様を実行できることを証明しなければなりません。ISO 14971 では医療機器のリスクがシステムレベルで詳しく説明しており、EN 62304 ではその適合を要求しています。ISO 14971に基づき、EN 62304 の箇条 7 ではソフトウェア固有のガイドラインに焦点を当てています。詳しい情報は、IEC/TR 80002-1 を参照して下さい。

2.4.4 発生確率の低減は、要求されたアクティビティとソフトウェアの安全クラスにどのように影響しますか。

回答: ソフトウェアの安全クラスは、発生確率と無関係です。確認される一連の事象に関して、ハザードに対するソフトウェア発生確率は、100%と想定されます。しかし発生確率の低減は、有効で適切な低減策の一部なります。

2.4.5 ソフトウェアとの関連で、ハザード、原因、イベントシーケンスを説明して下さい。

回答: ハザードは抽象概念です。危険状態は、ハザードの事例(発現)です。つまり、危険状態は、現実事象として現れたハザードです。[訳注:ハザード;危害の潜在的な源(ISO14971:2007)]原因:イベントシーケンス又は組合せの結果、最終的にハザードにつながる初期事象。

イベントシーケンスの例:
ハードウェアに組み込まれたソフトウェアの例:
1 状況付き添いのいない患者が患者テーブルの上にいるときに、制御装置の近くの物体が制御装置の上に落ち、患者テーブルの上昇ボタンを押す。
2 ハザード: 患者テーブルの無制御な移動。
3 危険状態: 患者が、患者テーブルと X 線機器の間で動きがとれない。
4 危害: 患者テーブルと X 線機器に挟まれた患者の胸部挫傷。

ソフトウェア単独製品の例:
1 状況データベースからデータセットがインポートされる。
2 ハザード: ソフトウェア処理中に画像が反転する。
3 危険状態: 医師が体部位の左右を間違える。
4 危害: 医師が間違った脚を切断する。

2.4.6 EN 62304 準拠のソフトウェアハザード分析に関する追加ガイダンスはいつでますか。

回答: 安全性評価の実施は、ISO 14971 に詳しく説明されています。追加ガイダンスは、IEC/TR 80002-1 で見ることができます。

2.5 分類と分離

2.5.1 分離とは何ですか。

回答: 分離とは、ソフトウェアアイテムが意図しない方法で影響し合わないようにすることです。分離は、物と物を離す又は隔てることを意味します。その目的は、制御フロー、データフロー及び共有リソースの依存関係から生じる副次的悪影響を回避することです。分離は、機能、論理及び物理的な 3 つの異なるレベルで作用します。機能的分離は、例えばミドルウェア又はラッパーで構築できます。それらは、システムで使用したくない SOUP(本FAQ2.7 を参照)の使用を阻止します。物理的分離の例としては、個別のプロセッサ使用があります。論理的分離には、個別のメモリの割り当てが含まれます。必要とされる分離のタイプは、重大な不具合を引き起こす可能性のあるシステム要素によって決まります。

2.5.2 分離が有効であることをどのように証明すればよいですか。

回答: 分離の目的は、制御フロー、データフロー及び共有リソースの依存関係から生じるソフトウェアの意図しない副次的悪影響を回避することです。分離の証明は、有意な副次的悪影響が存在しないことを証明することで行えます。

分離の例:
オペレーティングシステムはプロセスを分離しようとするので、クラス C アイテムを他のアイテムから分離するには、個別のオペレーティングシステムプロセスが適切です。クラス C ユニットごとに、クリティカルリソースを決定する必要があります。確かな方法は、それぞれのクラス C ユニットの始動時に必要なリソースを要求することです。CPU 時間がクリティカルリソースの場合、プロセスの優先順位、マルチプロセッサ、さらに複数の CPU ボードによってそれを確保することができます。

一般的アプローチ
1. 設計及び構成手段で分離を構築する。
2. FTA(フォルトツリー解析)や FMEA(故障モード影響解析)のような安全解析技術を実施する。
3. 検証によって、分離が有効であることを証明する。
検証では、安全関連ソフトウェアアイテムによるリソース(物理的又は時間的)の使用が実行環境(同じ状況で別のプロセスを実行する)において意図しない影響の回避に適していることを証明する必要があります。もし、試験所のテストケースが、ソフトウェアを加速するために性急に低性能で無効な措置が取られたことを示した場合、これらの手段はおそらく設計にネガティブな影響を与え、予期せぬ悪影響を通じて別のリスクが加わることになるでしょう。

“分離が有効である(予測される動作状況で)ことを検証で証明できるように、以下の通り、分離を明確に記述して下さい。
・データフローの改ざんを阻止する:安全に関連しないソフトウェアアイテムは、安全性に関連するデータを変更できない。
・制御フローの改ざんを阻止する:安全に関連する機能は、安全に関連しないソフトウェアアイテムの作用に影響されることなく、常に正しい時間に実行される。
・安全に関連しないソフトウェアアイテムは、安全に関連するソフトウェアアイテムを変更できない。
・実行環境の改ざんが阻止される:安全に関連するソフトウェアアイテムと安全に関連しないソフトウェアアイテムの両者で使用するソフトウェアシステム(例えば、プロセッサレジスタ、デバイスレジスタ、及びメモリアクセス権)の改ざんは起きない。
"参考文献[1]も参考にして下さい。検証では、クラス C ユニットの本来の機能を検査の際にストレス状態を作ることによって、共有リソースの有用性にも焦点をあてるかも知れません。

2.5.3 クラス B のソフトウェアで COTS(例えば、コンパイラのランタイムライブラリのような)を使用する場合、クラス B のソフトウェアをクラス A の COTS から分離するには、どんな基準に従う必要がありますか。あるいは、COTS がクラス B 以上のプロセスに従って開発される場合、COTS の使用は許可されますか。あるいは、クラス A の COTS のバリデーションは可能ですか。また、どんな基準に従いますか。

回答: 定義 3.29 により、すべての COTS(市販のソフトウェア)は SOUP です。EN 62304 の細々分箇条 5.3.3 と 5.3.4 は機能性能要求事項を、5.3.6 は SOUP の動作を検証する必要性をそれぞれ説明しています。SOUP を分離するための明示的な要求事項はありません。SOUP の開発方法に関する前提もありません。しかしながら、5.3.3 と 5.3.4 で規定されているように、ソフトウェアアーキテクチャに適合した意図した使用[Intended Use]に従ってSOUP を検証(5.3.6)することは重要です。実際これは、SOUP の機能を規定し、SOUP に対する十分な典型的なテストケースを実装することを意味します。ランタイムライブラリの例の場合、明確な方法で、必要な機能を使用し、結果を試験する別のソフトウェアを作成することになります。SOUP には安全クラス分類(A、B、C)がありますが、EN 62304 ではそのような安全クラスに応じた具体的な要求事項には触れていないことに留意して下さい。

2.5.4 意図した使用[Intended Use]に基づく重大度はソフトウェアの安全クラスとどのように関連していますか。

回答: EN 62304では、まず安全クラスC を適用するよう要求しています。しかし、安全性評価を行う前から機器の意図した使用[Intended Use]は明白で、機器及びソフトウェアアイテムの安全クラス分類にも繋がると想定されます。ソフトウェアが潜在的にハザードを引き起こす一連の事象の要素となるのかを判断するには、ISO 14971 が役立ちます。
合理的な状況で製造業者がハザードと確認したあらゆる一連の事象に対処する必要があります。ソフトウェアの安全クラス分類を決定する前に、機器の意図した使用[Intended Use]は明確にしておかなければいけません。安全性評価の際には、合理的な状況で健康にリスクをもたらす可能性のある一連の事象の各々を特定し分析します。
一連の事象が重傷をもたらす可能性がある場合、ソフトウェアはクラス C です。重傷の可能性がない場合(意図した使用[Intended Use]に従った使用に対して)、クラスB です。負傷の可能性がない場合、安全クラスは A となります。その後、ハードウェアリスクコントロール手段によってリスクを大幅に低減することができれば、安全クラスを 1 レベル(C から B 若しくは B から A に)下げることができます。安全クラスの引き下げは、結果を医師がレビューするものやユーザ向け情報(マニュアルのトレーニングや安全性上の注意)ではできません。これらはハードウェアリスクコントロール手段ではないからです。ソフトウェアアイテムを分割する場合、製造業者が分割されたアイテムが同じ重大度のハザードに関与していないことの正当な根拠を文書化しない限り、新しく生成されたアイテムは元のアイテムの安全クラスを継承します(4.3.d を参照)。文書化により分割したソフトウェアアイテムの安全クラスを、元のソフトウェアアイテムの安全クラスよりも低くすることができます。重大性と発生確率の組合せで、残留リスクの受容性が決定します。ISO 14971 を参照して下さい。
重傷でなければ、アイテムのクラスは A か B です。損傷がなければ、安全クラスは A になります。その後のハードウェアリスクコントロール手段で、リスクを大幅に低減できるならば、安全クラスを 1 レベル(C から B 又は B から A に)下げることができます。安全クラスの引き下げは、ユーザ向け情報(トレーニングのような)や医師の専門的検査では不可能です。これらはハードウェアリスクコントロール手段ではないからです。ソフトウェアアイテムを分割する場合、分割されたアイテムは元のアイテムの安全クラスを継承します。ハザードに関与しない細分化されたアイテム及びユニットの場合、そのソフトウェア安全クラスを元のソフトウェアアイテムの安全クラスよりも下げることができます。ISO 14971 と発生確率は、残留リスクの受容性の決定に役立ちます。

2.5.5 ソフトウェアアイテムが構造的に分離できない場合、設計管理のレベルに差はありません。そのような一枚岩のソフトウェアの開発に関して、ソフトウェアアイテムごとに安全クラスを決定するのは、無駄です。我々の手順で細分箇条 4.3(ソフトウェア安全クラス分類)を任意として、すなわち、プロジェクトチームの要求に応じて、様々なソフトウェアアイテムに様々なレベルの設計管理を使用する場合、EN 62304 への準拠を主張できますか。

回答: いいえ、ソフトウェア安全クラスの指定は必須です。任意ではありません。但し、これをソフトウェアシステム全体の初期の分類に制限することは許されます。

2.5.6 EN 62304 は、医療管理システムと保護システムから成る完全な医療機器に適用しなければなりません。管理システムは、死亡又は重傷の可能性に基づき、主にクラス C に分類されます。独立の保護システムを導入しても、保護システムは純粋なハードウェアではないので(ソフトウェアが組み込まれている)、管理システムのクラス分類は変更されません。保護システムは、死亡若又は重傷の発生確率のためクラス C に分類されます。つまり、どちらのシステムもクラス C ということになります。この解釈は正しいですか。

回答: 保護システムが管理システム関連のリスクコントロールとして実装されている場合、質問の論理的根拠は EN 62304 の 7.2.2b に反します。細々分箇条 7.2.2 によると、保護システムは C に分類される必要があります。つまり、指定されたソフトウェアの安全クラスがリスクコントロール手段を適用するソフトウェアプロセスの程度を定義します。この場合、保護システムが死亡又は重傷を引き起こさないかどうかは重要ではありません。安全クラスの引き下げは、その後に純粋なハードウェア保護がある場合にのみ許されます。従って、指摘のとおり管理システムのクラス分類は C クラスのままです。保護システムは純粋なハードウェアリスクコントロールではないので、完全な医療機器(管理と保護)はクラス C のままです。

2.5.7 コンパイラが作成したソフトウェアがクラス B なら、そのコンパイラもクラス B と考えていいですか。クラス B のソフトウェアとクラス A のコンパイラを分類するどんな基準がありますか。あるいは、クラス A のコンパイラがクラス B のソフトウェアを作成する妥当性を確認するどんな基準がありますか。コンパイラのクラス B 適合を立証するために、供給業者はどのような資料を求められますか。

回答: ツールを安全クラス分類する必要はありませんが、バリデーションは必要です(ISO13485 の 7.5.2.1 を参照)。コンパイラの再配布可能なコンポーネント(例えば、ランタイムライブラリ)は SOUP であることに留意してください。

2.5.8 開発プラットフォームとツールは、ソフトウェア安全クラスとどのように関連していますか。

回答: 開発プラットフォームとツールは医療用ソフトウェアとは見なされないので、安全クラスを分類する必要はありません。医療機器ソフトウェア(EN 62304 細分箇条 1.2 による)とその要素だけが、安全クラス分類を必要とします。開発プラットフォームおよびその他のツールは、EN 62304 1.2 に該当しないので、クラス分類されません。

2.5.9 システムレベルのリスク分析とソフトウェア安全クラスの間にはどんな関連がありますか。

回答: ソフトウェアシステムのソフトウェア安全クラスは、ソフトウェアシステムの使用に関連したリスクの重大性全体への寄与を示す指標となります。この重大性への寄与は、ソフトウェアシステムレベルのリスク分析に基づきます。安全クラスは、ソフトウェアシステムの開発と保守に使用するプロセス要求を厳密に決定します。

2.5.10 EN 62304 の 3 つの安全クラス分類は、FDA が定義する 3 つの懸念レベルと類似しているように思われます。もし違いがあるのなら、その違いを説明して下さい。

回答: EN 62304 のソフトウェア安全クラス分類は、開発及び保守プロセスの厳密性を予め定義する手段です。ソフトウェアの懸念レベルは、申請書類に含まれるソフトウェア成果物を定義する手段です。通常、必要な成果物(FDA)は、申請に適合するための従うべきプロセスを間接的に導くと言われています。多少の相関はありますが、概して規制区分は、EN 62304 のリスククラスの分類とは無関係です。ソフトウェアの安全クラスはリスクの重大度にのみ依存し、危害又は発生確率の可能性は考慮に入れていません。懸念レベルは、機器にさらされた患者に起こるリスクの総体的評価で、確実にこれらのリスク要因を組み込んでいます。定義の語法は若干異なりますが、危害の重大度にのみついて言えば、レベルは一致すると思います。従って、IEC の A、B 及び C は、FDA の Minor(軽度)、Moderate(中程度)及び Major(重度)の懸念レベルと関連づけることができます。EN 62304 はソフトウェアのクラス変更を認めますが(4.3 項に基づき)、FDA の等級付けは変更できません。

2.5.11 どのようにして IEC 61508 の SIL(安全度水準)と EN 62304 の安全クラス分類を関連づけていますか。

回答: 安全クラスはリスク低減の影響を評価する前の分析時に決定されるので、また SIL は評価されたリスクの低減における 1 要素なので、SIL と安全クラスの関連づけられるのは、システムレベルのリスク分析だけです。

2.5.12 ソフトウェア安全クラスをリスクマネジメントファイルではなくソフトウェアアーキテクチャ文書に記述することは可能ですか。リスクマネジメントファイルに、ソフトウェアアーキテクチャを指し示す記述はありますか。
4.3c には、分類した各ソフトウェアシステムの安全クラスは、リスクマネジメントファイルに文書化すると記述されています(7.2.2b も参照)。
ソフトウェアアーキテクチャの変更は、クラス分類に影響を与え、検知されない可能性があります。安全クラス分類をソフトウェアアーキテクチャに記述し、リスクマネジメントファイルがソフトウェアアーキテクチャを指し示すようにしたいと思います。これによって、安全クラス分類の変更の未検出を引き起こすソフトウェアアーキテクチャ変更のリスクを最小限に抑えられます。この対応は許容されるものであると FAQ に記述すべきです。

回答: 規格は安全クラス分類を要求していますが、この実施を示す文書は指定していません。従って、ソフトウェアアーキテクチャ文書あるいは別の文書に安全クラスを記述することは可能です。安全クラス分類をどのように文書化したいかは製造業者の決定に任されています。安全クラスが記述されている文書はリスクマネジメントファイルの一部であることに注意して下さい。

2.5.13 ソフトウェアクラス分類は、現実の問題として大きな影響を持っています。NB 監査員が、重傷の定義で“間接的(indirectly)"という用語を使用するのは、ほぼすべての関連診断情報に関して、そのようなソフトウェアの大部分はクラス C であると結論付けるためです。理論的にありそうもないシナリオ(最新医療とはほど遠い)に遭遇する可能性はありますが、クラス分類は重大性にのみ関連しているので、それはクラス C と主張されます。さらに、頻繁に B が選択されますが(“非重傷(non serious injury)"の概念さえあまり適切とは言えない)、その理由は:要求と意図した使用[Intended Use]に照らして、重傷の可能性はないと証明できるからです。医療機器に関して、“負傷又は健康障害の可能性がない"と言うことは難しいかも知れません。例えば、少なくとも治療のわずかな遅れ(緊急事態ではない)や検査の繰り返し(X 線照射はない)はあるからです。
クラス分類に関して、以下のことは可能でしょうか。
a) 用語“間接的(indirectly)"の意味を定義してください。私の理解する“間接的"とは、医療スタッフによる何らかの取り組みがなければ間接的に重傷又は死亡につながる可能性のある機能していないモニタのアラームのように時間の問題/緊急事態と関連づけられます。
b) クラス分類(特にクラス A と B のため)の際の手がかりとなるような各クラスのソフトウェアの例を提供してください。

回答: 現行の IEC 62304 第 1 版においても、ISO 14971 においても、重傷との関連で“間接的"は定義されていません。当分は、COCIR/EUROM Ⅵ共同の方針書“Position Paper onDirect Diagnosis"(2011 年 10 月 14 日)に従って間接的と直接的の違いを解釈することを推奨します。本 FAQ 文書の附属書 4 を参照して下さい。

2.6 仕様書、試験及びツール

2.6.1 ハードウェアと組込ソフトウェアで構成される医療機器の製造業者です。要求事項と試験の文書化はどのようにすればよいですか。文書を分割する必要がありますか。

回答: 文書の分割は正式には要求していませんが、経験から言うと、文書をハードウェア関連とソフトウェア関連で分けることは非常に実用的です。

2.6.2 製造業者施設内のサーバにインストールされたソフトウェアがあり、医師が、治療の計測にアクセスするために、Web 経由でこのソフトウェアに入力するパスワードとユーザ名を持っていると仮定します。EN 62304 には、デジタル証明書(http/https)、サーバ要件、サーバ室要件に関連した具体的な要求事項はありますか。

回答: EN 62304は、アクティビティとそれを立証するための文書を説明するプロセス規格です。製品の具体的な要求事項は扱いません。初期の時点で、医療機器ソフトウェアの製品規格ではありませんでした。(2.2 項も参照して下さい。)

2.6.3 EN 62304 はライフサイクルプロセスに関する規格です。機器固有のソフトウェア要求事項(非プロセス関連)についてはどうお考えですか。

回答: 当規格は、機器固有の成果物を含むソフトウェア開発プロセスを説明しています。従って、特定機器のソフトウェア要求事項は、特定機器のソフトウェア要求仕様書に文書化します(5.2)。

2.6.4 リスク分析と機能仕様の間には循環依存関係があります。すなわちリスク分析は、一方で機能仕様書に記述されている機能に基づき、他方で機能仕様書にリスク低減策の情報を提供します。そこで、この状況をどう解決しますか。リリースされた機能仕様書をまず入手して、リスク低減策が規定された後にもう一度検討すべきですか。

回答: 循環依存関係というよりもむしろ、反復プロセスです。出発点とアプローチを規定するのは製造業者の判断です。

2.6.5 要求事項と設計入力設計入力などの要求事項における適正な精度はどれくらいですか。要求仕様書で十分ですか、それとも正式に審査された機能仕様書が必要ですか。

回答: EN 62304 は、要求事項又はソフトウェアユニットの特定の精度を規定していません。要求事項は、“合格"又は“不合格の"の結果を得られる基準を用いて試験されなければなりません。商用規模のシステムの場合、機能仕様書を作成し、ソフトウェアシステムをアイテムとユニットに分割することを推奨しています。

2.6.6 設計の記述設計に関する記述の適正な精度はどれくらいですか。アーキテクチャ仕様書で十分ですか、それとも正式に審査された詳細なコンポーネント設計仕様書が必要ですか。安全関連規定だけも大丈夫ですか。

回答: 5.3 は、クラス B 又は C のソフトウェアに対してアーキテクチャ文書を要求しています。5.4.2 では、クラス C に関しては、詳細設計の文書化を要求しています。

2.6.7 どの要求事項が双方向になっていますか(もしあるとして)。

回答: 細々分箇条 5.1.1、7.3.3 及び 8.2.4 が示すとおり、規格はトレーサビリティだけを要求します。それぞれが示すのは、システムレベル(クラス A、B、C)、リスクマネジメントレベル(クラス B、C)及び変更管理レベル(クラス A、B、C)のトレーサビリティです。双方向性に関する明確な要求事項はありません。もちろん、規格は双方向のトレーサビリティを禁止してはいません。すべての要求事項に対して、実施された試験の概要を知っておくとは有益です。追跡を必要とする依存関係の概要については、この FAQ 文書の附属書 3 を参照して下さい。

2.6.8 配置インストール媒体:記憶媒体(例えば、DVD)及びネットワーク(例えば、インターネット)経由でクラス B のソフトウェアをインストールする場合、インストールされたクラス B のソフトウェアの画像がソース画像と同一であることを立証するために要求される、標準的技術を超えた特別の手段はありますか。この目的のための検査プログラムは、クラス B として分類されますか。また、例えばチェックサムの信頼性に関して、どの基準を満たす必要がありますか。

回答: ソフトウェアの開発、配置又は保守用のツールは、一緒に使用する製品の安全クラスを継承しません。ツールにクラスはないので、ランタイムコンパイラにクラスはありません(コンパイラが医療機器の一部である稀なケースを除いて)。しかし、クラスB又はCのソフトウェアアイテムと一緒に使用する場合、規格はツールを管理することを要求しています。意図した目的に基づきツール使用の妥当性を確認するのは、製造業者の判断です(ISO 13485の7.5.2.1を参照)。ツールのバリデーション(さらに言えば、チェックサムの信頼性に必要なバリデーション基準)は、本規格の適用範囲外です。

2.6.9 要求事項間の一貫性細々分箇条 5.4.2 によると、クラス B のソフトウェアユニットの場合:すべてのユニットに文書化されたソフトウェア設計説明書が必要な訳ではない。5.4.1 ソフトウェアアーキテクチャのソフトウェアユニットへの分解製造業者は、最小単位であるソフトウェアユニットによって表現できるまで、ソフトウェアアーキテクチャを分解する。[クラス B、C]5.4.2 ソフトウェアユニットごとの詳細設計の開発製造業者は、ソフトウェアアイテムのソフトウェアユニットごとに詳細設計を開発し、文書化する。[クラス C]
しかし、5.5.5 によると:5.5.5 ソフトウェアユニットの検証製造業者は、ソフトウェアユニットの検証を実行し、結果を文書化する。
[クラス B、C]すべてのソフトウェアユニットに正式なソフトウェア設計説明書が文書化されていなくて、どうやってソフトウェアユニットの検証を文書化できますか。この点を明確にする例を幾つか挙げていただけますか。あるいは、クラス B の場合、ソフトウェアユニットの検証をソフトウェアアイテム(ソフトウェアユニットを含む)の試験で間接的に行うことは可能ですか。質問を単純化すると:規格はクラス B アイテムのソフトウェアユニットの検証の文書化を要求していますが(5.5.5)、クラスBアイテムの詳細設計仕様書の文書化は要求していません。どうすれば文書化する必要のなかったものに照らして検証できるのでしょうか。

回答: 文書化されないからと言って、それが存在しない訳ではありません。詳細設計仕様書は、開発者と検査者の頭の中にあります。クラス B アイテムの場合、ユニット試験で十分と考えられます。文書化されていない仕様に照らして試験するとは、ユニット試験中に実施された詳細な手順を報告せずに、単にソフトウェアアイテムをリストアップし、合否の結論を出すということです。クラス C アイテムの場合、詳細設計仕様書が要求され、より詳細にユニット試験を文書化することを求めています。さらに、細々分箇条 5.5.3 および 5.5.4 も注意してよく読む必要があります。ユニットの合否基準はしばしばユニットの検証の一部なので、これらの細々分箇条は別の検証方法を示唆する可能性があります。

2.6.10 ソフトウェアの開発及び試験は、検証が実施されているとは考えられない共有オープンソース(フォーラム)で見つけたツールとオブジェクトを使用します。当規格は、そのようなオープンソースツールの管理を優先しますか。EN 62304 では、そのようなツールに対してどのようなアクティビティ又は文書を要求しますか

回答: この規格はオープンソースコードにも適用します。コードを利用する場合、そのコードはSOUP の要求事項に従います。自分でコードを書き換えた場合、それは自身が開発したソフトウェアアイテムと見なされます。管理レベルはコードの安全クラスに依存します。

2.6.11 ユニット試験ツールにおける外部ソース:ユニット試験ツールを外部のライブラリから入手したソースコードを使って開発した場合、EN 62304 ではどのようなアクティビティ/文書を要求しますか。

回答: 試験ツールは、CMS(構成管理システム)の一部として評価される必要があります。EN 62304 の細々分箇条 5.1.4、5.5.2 及び 5.8.8、さらに ISO 13485 の 7.5.2.1 を参照して下さい。

2.7 SOUP とレガシーソフトウェア

2.7.1 SOUP(Software of Unknown Provenance:開発過程が不明なソフトウェア)ソフトウェアの供給業者をどのようにして評価し、適格と認めればよいですか。作成時、ソフトウェアは医療機器に組み込むことを目的として具体的に開発されたわけではありません。

回答: EN 62304 には、供給業者マネジメントの一般要求事項(EN 62304 細分箇条 4.1 と例えば EN ISO 13485)以外の SOUP 供給業者に関する特定の要求事項はありません。SOUP アイテムには、以下の特定の要求事項が適用されます。細々分箇条:5.1.7、5.3.3、5.3.4、6.1、7.1.2、7.1.3、8.1.2詳しくは、本 FAQ 文書の附属書 2 を参照して下さい。

2.7.2 EN 62304 は SOUP の存在を認識しています。この規格の要求事項を満たすために、SOUP はどの程度の試験と文書化を必要としますか。

回答: SOUP は、詳細設計の開発(5.4)とソフトウェアコーディングアクティビティ(5.5 )以外は、SOUP については、自身で開発したソフトウェアアイテムと同じアクティビティを要求します。

2.7.3 製造業者がソフトウェアはすべて SOUP であると宣言し(本当かどうかは別にして)仕事の分量を減らすことを、EN 62304 の何が妨げているのですか。

回答: 実際、SOUP の定義(3.29)を満たしているのであれば、すべてのソフトウェアが SOUP であるとする製造業者の宣言を妨げるものは何もありません。ここで留意すべきは、必ずしも仕事の分量が減るとは限らないということです。製品を上市するまでに、かえって多くの仕事が必要とされるかも知れません。詳細設計の開発(細分箇条 5.4)とソフトウェアコーディングアクティビティ(細分箇条 5.5)を除けば、SOUP は、自身で開発したソフトウェアアイテムと同じアクティビティを要求します。さらに、EN 62304 では、SOUP 固有のタスクを追加しています(例えば、SOUP の監視)。体裁を気にしすぎると、SOUP の供給業者選択活動(クリティカル又は非クリティカルな供給業者の選択、認証及び決定)で更なる努力が要求され、しかもそれさえ結局無駄に終わるかも知れません。MDD の観点から見ると、製造業者は、基本要件への適合を示さなければならないときに問題に遭遇します。例えば、基本要件第2条:“機器の設計と製造に係る製造業者によって採択された解決法は、広く認められた最新技術を考慮して、安全原則に従わなければならない。"製造業者の解決法は、たぶん最新技術ではありません。附属書 2 の図 2 を参照して下さい。

2.7.4 EN 62304 発行前に設計されたソフトウェア(スタンドアロン又は組み込まれた)がいまも市販されています(レガシーソフトウェア):
a) 何らかの手を打つ必要がありますか。
b) もしあるとすれば、それは何ですか。

回答:
a) はい
b) 医療機器ソフトウェアの場合、下記の決定をして、現在の“最新技術" [the state ofthe art]に対応する必要があります。
・直ちに EN 62304 に適合させる
(この場合、ソフトウェアの市販に関して、EN 62304 適合の証明では十分とはいえません。MDD の要件は、たぶんソフトウェアとテクニカルファイルのさらなる変更を要求するでしょう。)
あるいは
・発行予定の EN 62304 第 2 版附属書 E の提案に従う。
[訳注:IEC 62304 Amd Ed.1 は 2013 年 7 月時点では CD である。附属書 E Application of software lifecycle PROCESSES for LEGACY SOFTWARE は審議中であり、公式には参照できない。]
当附属書の目的は、下記のようなソースから得られる情報に基づき、レガシーソフトウェアの基準を作成することです。
・当該機器の使用から得られる市販後情報
・開発プロセスから得られた文書記録及び EN 62304 と照らし合わせたギャップ分析の結果情報をすべて収集した後に、今後の進め方を決定できます。
1 つの可能性は、規格を適合するのに十分な情報を持っている場合です。もしそうでない場合は、規格適合に必要な情報をすべて作成するため、ソフトウェアの分類から始めて、下記のようなその他の情報を引き続き収集します。
・リスク分析、要求事項、アーキテクチャ、設計、実装及び追跡
・ビルドプロセス、結合及び試験アクティビティを繰り返す。試験アクティビティにより新しい試験記録が作成される。

前提
構成管理が必要です(バージョン管理及びビルド環境と SOUP の再構築)。レガシーソフトウェアを変更する場合には規格全体に従う必要があることに注意して下さい。
IEC 62304 第 2 版のレガシーソフトウェアに関する附属書では、より詳細なガイドラインを利用できます。

2.7.5 レガシーソフトウェアの大幅な変更が必要な場合、EN 62304 の適合を実現/維持するためにどんなプロセス及び文書が必要ですか。また、変更が有意と見なされるのはどんなときですか。

回答: それは、レガシーソフトウェアのどんな情報が得られるかによります。完全な適合の場合、要求されるすべてのプロセス及び文書を検討する必要があります。EN 62304 は、変更の重要性を考慮しません。どのような変更でも製品に対する影響又は意味を検討する必要があります。その結果、実施される適切なアクティビティが決定されます。

参考文献 [1] David A. Vogel (2010 年 11 月 30 日). Medical Device Software Verification, Validation, andCompliance. Artech House. ISBN 978-1-59693-422-1
[2] MEDDEV 2.1/6 (2012 年 1 月): Guidelines on the qualification and classification of standalone software used in healthcare within the regulatory framework of medical devices
[3] IEC 62304 第 2 版は現在準備中で 2014 年から 2015 年に発行を予定されています。
[4] IEC 82304 第 1 版は現在準備中で 2015 年に発行を予定されています。
[5] COCIR/EUROM VI Position Paper on Direct Diagnosis (2011 年 10 月 14 日)
[6] AAMI TIR 45 Guidance of the use of AGILE practices in the development of medical devicesoftware (2012 年)

附属書1 ソフトウェア問題解決プロセス

問題解決プロセスには、ソフトウェアの開発と保守のどちらの場合にも複数のエントリーポイントが存在します(質問 2.3.1 関連)。

附属書 2 SOUP の選択、評価及び認定

SOUP は、製品のコンポーネントとして又はシステムの製品として統合することができます。簡単にするため、コンポーネントと統合ソフトウェアのどちらにも“製品"という用語を使用します。製品とシステムの区別が必要な場合は、以下の説明を参考にして下さい(質問 2.7.1 及び 2.7.3 関連)。

SOUP フローチャート(附属書 2 の図 2 を参照)は、SOUP 供給業者の選択、評価及び認定プロセスの一例です。仕様(4)に適合する潜在的な SOUP 供給業者を調査(2)し特定(3)した後、当該供給業者を“認定供給業者"として指定します。供給業者が“クリティカル"として分類される場合、選択基準により審査が要求されるかも知れません。

供給業者がクリティカルかどうかを判断するためには、製品の安全性(10)と有効性(11)に対する SOUPの潜在的影響を考慮する必要があります。さらに、SOUPがスタンドアロンソフトウェア、すなわちシステムに統合される製品として使用される場合、SOUP 製造業者の責任を誰が取るのかを判断する必要があります(12)。これらの質問に答える際には、SOUP に関する追加要求など、SOUP に対して予定している変更を考慮すべきです。会社の中には供給業者をクリティカルと認定するために付加的な基準を用意するところもあります。

(10)SOUP の安全性がクラス B 又は C ならば、供給業者は自動的に“クリティカル"になります。

(11)製品の有効性に対する SOUP の影響を自身で試験できない場合、供給業者は“クリティカル"です。例えば、臨床的異常の検出アルゴリズムが高コストまたは困難な臨床評価を含む場合、製造業者が提供する証拠が頼りになります。同様に、SOUP を変更したい又は新しい要求をしたい場合、供給業者が提供する臨床評価が頼りになります。

(12)製造業者の責任を自ら取る場合又は SOUP の代理人として役目を務める場合、あなたの供給業者は“クリティカル"です。供給業者を“クリティカル"として指定する場合、供給業者対する監査を行う必要があります。監査は、現地監査か自己診断アンケートの形で行います。自身の監査基準を使って、クリティカルな供給業者が認定される資格があるかどうかを判断します。例えば、供給業者が品質システム(例えば、ISO 13485)を確立しているならば、又は自らの基準に合わせて製品を設計及び試験しているのであれば、その供給業者は認定できます。供給業者が監査基準に適合しない場合、SOUP は使用できません。留意すべきは、監査基準が本附属書の質問 10 と 11 の結果に依存できるということです。例えば、システムの有効性を試験するために製造業者に頼らなければならないのであれば、より厳しい監査を適用できます。すなわち、SOUP の安全性への影響に基づいて、より厳しい試験基準を要求することができます。

附属書 3 トレーサビリティ

図 3 は、EN 62304 に準じて追跡調査する必要のある依存関係の概要を示します(質問2.6.7 関連)。

図3 トレーサビリティ

要求事項のトレーサビリティ(条項5.1.1.c)

すべてのクラス
・システム要求事項
・ソフトウェア要求事項
・テストケース

ソフトウェアハザードのトレーサビリティ(条項7.3.3)

クラスBとCのみ・ハザード
・危険状態
・ソフトウェアアイテム
・ソフトウェアの原因
・リスクコントロール手段
・リスクコントロール手段の検証テスト

変更のトレーサビリティ(条項8.2.4)

すべてのクラス
・承認された変更要求
・実際の修正
・修正の検証テスト

附属書 4 直接診断に関する方針説明書(COCIR、 2011)(質問 2.5.13 関連)

用語“直接診断"に対する医療産業の共同解釈

医療機器指令 93/42/EEC に含まれる附属書Ⅸ(“クラス分類基準")の項目 3.2 規則 10には、“直接診断"という用語が使われています。この用語は様々な利害関係者によって異なって解釈されるので、COCIR と EUROM Ⅵは、“直接診断"について独自の理解を共有することとしました。指令には、次のように記述されています。
“診断を意図する能動機器は、クラスⅡa である: -[...]
- 機器が、重要な生理学的プロセスの直接診断や監視を可能にすることを意図する場合。但し、変化の性質が、例えば、心臓の機能、呼吸、中枢神経系の活動の変化など、患者の差し迫った危険をもたらす重要な生理学的パラメータの監視を特に意図する場合を除く。その場合、機器はクラスⅡb である。"

COCIR と EUROM Ⅵの意見では、上記のパラグラフは以下のように解釈すべきである。

診断を意図する能動機器の使用で、医療専門家が以下のことが可能になる場合
1. 直接診断(例えば、疾患若しくは病態)、あるいは
2. 重要な生理学的プロセスの監視
1 と 2 のどちらの場合も、能動機器はクラスⅡa である。但し、能動機器で、が以下のことが可能になる場合を除く。
3. 変化の性質が、例えば、心臓の機能、呼吸、中枢神経系の活動の変化など、患者の差し迫った危険をもたらす重要な生理学的パラメータの監視。その場合、機器はクラスⅡb である。

“直接診断を可能にする機器"の定義

疾患又は病態の診断を単独で提供する場合、又は診断の決定的情報を提供する場合、機器は直接診断を可能にすると考えられる。

論理的根拠

1. “診断用能動機器"の定義

MDD 附属書Ⅸの項目 1.6 では、診断用能動機器を次のように定義しています:“単独か又は他の医療機器と組合せて使用するかにかかわらず、生理的状態、健康状態、疾患又は先天性異常を検出、診断、監視又は治療するための情報を提供する任意の能動医療機器。"この定義は、上記の目的(検出など)のために、医療専門家が利用できるように情報を提供することと解釈されるべきです。

2. “診断"の定義

“診断"は、一般に次のように解釈されます。“可能性のある疾患又は病態を判断/特定し、治療法を決定するプロセス。進行する疾患、病態及び治療の経過観察を含む。"診断プロセスは、患者の具体的な兆候や症状を観察し、具体的な病歴を聴取する(例えば、兆候や症状の原因など)ことから開始されます。具体的な兆候、症状、及び病歴から得た手がかりにより、医師は具体的な身体検査を実施し、具体的な診断的研究を命じることができます。医師は通常、可能性の高い診断の候補リストを作成し、さらに競合する診断を確認又は除外する検査を要求し、その後に治療法を提供します。

3.“直接"の定義(用語“直接診断"のような場合)

“直接"は、完全性との関わりで解釈すべきです。すなわち、追加情報を入手したり考慮したりする必要がありません。診断は、医療専門家又は医療機器自体がその場で行うことができます。留意すべきは、利用できる情報は、完璧でないかも知れないということです(すなわち、他のパラメータが測定されるかも知れないし、既往歴は完全でないかも知れません)。しかし、具体的な診断を導くには十分です。機器は、様々な医療関連の情報を提供します。・指示的情報:情報は、患者に関するその他の臨床及び技術データとともに医療関係者が診断を行う際のディシジョンツリーで使用できます。・決定的情報:情報は、診断を決定する上での重要な要素の 1 つです。機器は、疾患又は病態の診断を単独で提供する場合、又は診断のための決定的情報を提供する場合、“直接診断を可能"にすると考えられます。指示的情報は、“直接診断"を導くには不十分です。

4.実例

直接診断に使われる機器の非網羅的な実例リスト: ・“骨減少性"又は“骨粗鬆症"として患者を分類する骨密度測定装置・“心臓不整脈"として患者を分類する ECG システム・結腸ポリープを検出する仮想結腸内視鏡や肺塞栓症を検出する血管アプリケーションのような、医療専門家の病態検出を可能にするために画像データを修正する画像処理アプリケーション

出典:「EN 62304：2006 の実施におけるよくある質問（MDD 93/42/EEC 関連）第1版 2013年4月5日」（経済産業省）（http://www.meti.go.jp/committee/kenkyukai/shoujo/iryou_software/pdf/h25_01_s03_00.pdf）（2018年1月15日に利用）
「EN 62304：2006 の実施におけるよくある質問（MDD 93/42/EEC 関連）第1版 2013年4月5日」（経済産業省）（http://www.meti.go.jp/committee/kenkyukai/shoujo/iryou_software/pdf/h25_01_s03_00.pdf）よりIEC62304関連記事を抜粋しました。