FDA Draft Guidance_Computer Software Assurance for Production and Quality System Software (2022 年 9月 13 日) 参考対訳
2023 年 8 月 8 日 医療機器 QMS コンサルタント 矢部久雄

Computer Software Assurance for Production andQuality System Software
Draft Guidance for Industry and Food and Drug Administration Staff
This draft guidance document is being distributed for comment purposes only. Document issued on
September 13, 2022.
I. Introduction.........................................................................................................................................................4
II. Background .......................................................................................................................................................5
III. Scope.................................................................................................................................................................6
IV. Computer Software Assurance.........................................................................................................................6
V. Computer Software Assurance Risk Framework .............................................................................................7
Identifying the Intended Use ........................................................................................................................7
Determining

theRisk-BasedApproach........................................................................................................9

Determining the Appropriate Assurance Activities ...................................................................................13
Establishing the Appropriate Record .........................................................................................................16
Appendix A. Examples..........................................................................................................................................20
Example 1: Nonconformance Management System............................................................................................20
Example 2: Learning Management System (LMS) ............................................................................................23
Example 3: Business Intelligence Applications...................................................................................................24

I. Introduction
FDA is issuing this draft guidance to provide recommendations on computer software assurance forcomputers and automated data processing systems used as part of medical device production or the quality
system. This draft guidance is intended to:· Describe “computer software assurance” as a risk-based approach to establish confidence in the automation
used for production or quality systems, and identify where additional rigor may be appropriate; and· Describe various methods and testing activities that may be applied to establish computer software
assurance and provide objective evidence to fulfill regulatory requirements, such as computer software
validation requirements in 21 CFR part 820 (Part 820).
When final, this guidance will supplement FDA’s guidance, “General Principles of Software Validation”(“Software Validation guidance”) except this guidance will supersede Section 6 (“Validation of AutomatedProcess Equipment and Quality System Software”) of the Software Validation guidance.

FDA は、医療機器の製造または品質システムの一部として使用されるコンピューターおよび自動データ処理シ
ステムのコンピューター ソフトウェア保証に関する推奨事項を提供するために、このドラフト ガイダンスを発行しています。このドラフト ガイダンスは、次のことを目的としています。
· 生産または品質システムに使用される自動化の信頼性を確立するためのリスクベースのアプローチとして「コンピュータ ソフトウェア保証」を説明し、追加の厳密さが適切な場合を特定します。と· コンピュータ ソフトウェアの保証を確立し、21 CFR パート 820 (パート 820) のコンピュータ ソフトウェ
ア検証要件などの規制要件を満たすための客観的な証拠を提供するために適用できるさまざまな方法とテスト活動について説明します。
最終的に、このガイダンスは FDA のガイダンス「ソフトウェア検証の一般原則」(「ソフトウェア検証ガイダンス」) を補足するものですが、このガイダンスはソフトウェア検証ガイダンスのセクション 6 (「自動化されたプロセス機器および品質システムソフトウェアの検証」) に取って代わるものです。
For the current edition of the FDA-recognized consensus standard referenced in this document, see the FDA
Recognized Consensus Standards Database. In general, FDA’s guidance documents do not establish legally
enforceable responsibilities. Instead, guidances describe the Agency’s current thinking on a topic and should
be viewed only as recommendations, unless specific regulatory or statutory requirements are cited. The useof the word should in Agency guidances means that something is suggested or recommended, but not required.
このドキュメントで参照されている FDA 承認コンセンサス標準の最新版については、FDA 承認コンセンサス
標準データベースを参照してください。 一般に、FDA のガイダンス文書は、法的強制力のある責任を確立していません。 代わりに、ガイダンスはトピックに関する当局の現在の考え方を説明しており、特定の規制または法定要件が引用されていない限り、推奨事項としてのみ見なされるべきです。 エージェンシーのガイダンスでの[「should べき」という言葉の使用は、何かが提案または推奨されているが、必須ではないことを意味します。

II. Background
FDA envisions a future state where the medical device ecosystem is inherently focused on device featuresand manufacturing practices that promote product quality and patient safety. FDA has sought to identify
and promote successful manufacturing practices and help device manufacturers raise their manufacturing
quality level. In doing so, one goal is to help manufacturers produce high-quality medical devices that alignwith the laws and regulations implemented by FDA. Compliance with the Quality System regulation, Part
820, is required for manufacturers of finished medical devices to the extent they engage in operations towhich Part 820 applies. The Quality System regulation includes requirements for medical device
manufacturers to develop, conduct, control, and monitor production processes to ensure that a device
conforms to its specifications (21 CFR 820.70, Production and Process Controls), including requirements for
manufacturers to validate computer software used as part of production or the quality system for its intendeduse (see 21 CFR 820.70(i)). Recommending best practices should promote product quality and patient safety,
and correlate to higher-quality outcomes. This draft guidance addresses practices relating to computers andautomated data processing systems used as part of production or the quality system.
FDA は、医療機器のエコシステムが本質的に製品の品質と患者の安全を促進する機器の機能と製造慣行に焦点を当てている将来の状態を想定しています。 FDA は、成功している製造慣行を特定して促進し、デバイス メーカーが製造品質レベルを上げるのを支援しようとしてきました。そうすることで、1 つの目標は、製造業者がFDA によって実施される法律および規制に沿った高品質の医療機器を製造できるようにすることです。品質システム規則、パート 820 への準拠は、パート 820 が適用される業務に携わる限り、完成した医療機器の製造業

者に要求されます。品質システム規則には、医療機器メーカーが製造プロセスを開発、実施、管理、および監視して、機器がその仕様に適合していることを確認するための要件 (21 CFR 820.70、生産およびプロセス管理) が含まれています。意図された用途のための生産または品質システムの一部として (21 CFR 820.70(i) を参照)。
ベスト プラクティスを推奨することで、製品の品質と患者の安全性が向上し、より質の高い結果につながるはずです。このドラフトガイダンスは、生産または品質システムの一部として使用されるコンピューターおよび自動データ処理システムに関連する慣行に対応しています。
In recent years, advances in manufacturing technologies, including the adoption of automation, robotics,
simulation, and other digital capabilities, have allowed manufacturers to reduce sources of error, optimize
resources, and reduce patient risk. FDA recognizes the potential for these technologies to provide significant
benefits for enhancing the quality, availability, and safety of medical devices, and has undertaken several
efforts to help foster the adoption and use of such technologies.
近年、自動化、ロボティクス、シミュレーション、およびその他のデジタル機能の採用を含む製造技術の進歩により、メーカーはエラーの原因を減らし、リソースを最適化し、患者のリスクを軽減することができました。 FDAは、これらの技術が医療機器の品質、入手可能性、および安全性を向上させる上で大きな利益をもたらす可能性を認識しており、そのような技術の採用と使用を促進するためにいくつかの取り組みを行ってきました。
Specifically, FDA has engaged with stakeholders via the Medical Device Innovation Consortium (MDIC), site
visits to medical device manufacturers, and benchmarking efforts with other industries (e.g., automotive,
consumer electronics) to keep abreast of the latest technologies and to better understand stakeholders’challenges and opportunities for further advancement. As part of these ongoing efforts, medical device
manufacturers have expressed a desire for greater clarity regarding the Agency’s expectations for software
validation for computers and automated data processing systems used as part of production or the quality
system. Given the rapidly changing nature of software, manufacturers have also expressed a desire for amore iterative, agile approach for validation of computer software used as part of production or the quality
system.
具体的には、FDA は医療機器イノベーション コンソーシアム (MDIC)、医療機器メーカーへのサイト訪問、および他の業界 (自動車、家電など) とのベンチマークの取り組みを通じて、最新の技術に遅れずについていき、
利害関係者をよりよく理解するために利害関係者と協力してきました。 さらなる進歩のための課題と機会。 こ
れらの継続的な取り組みの一環として、医療機器メーカーは、製造または品質システムの一部として使用されるコンピューターおよび自動データ処理システムのソフトウェア検証に対する当局の期待について、より明確にすることを望んでいます。 ソフトウェアの性質が急速に変化していることを考えると、メーカーは、生産または品質システムの一部として使用されるコンピューター ソフトウェアの検証のための、より反復的で機敏なアプローチに対する要望も表明しています。
Traditionally, software validation has often been accomplished via software testing and other verification
activities conducted at each stage of the software development lifecycle. However, as explained in FDA’s
Software Validation guidance, software testing alone is often insufficient to establish confidence that thesoftware is fit for its intended use. Instead, the Software Validation guidance recommends that “software
quality assurance” focus on preventing the introduction of defects into the software development process, andit encourages use of a risk-based approach for establishing confidence that software is fit for its intended use.
従来、ソフトウェアの検証は、多くの場合、ソフトウェア開発ライフサイクルの各段階で実施されるソフトウェ

ア テストやその他の検証活動を通じて行われてきました。 ただし、FDA のソフトウェア検証ガイダンスで説明されているように、ソフトウェアのテストだけでは、ソフトウェアが意図した用途に適しているという確信を確立するには不十分なことがよくあります。 代わりに、ソフトウェア検証ガイダンスは、「ソフトウェア品質保証」がソフトウェア開発プロセスへの欠陥の導入を防ぐことに重点を置くことを推奨し、ソフトウェアが意図した用途に適合しているという信頼を確立するためのリスクベースのアプローチの使用を奨励しています。
FDA believes that applying a risk-based approach to computer software used as part of production or thequality system would better focus manufacturers’ assurance activities to help ensure product quality while
helping to fulfill the validation requirements of 21 CFR 820.70(i). For these reasons, FDA is now providing
recommendations on computer software assurance for computers and automated data processing systems
used as part of medical device production or the quality system. FDA believes that these recommendations
will help foster the adoption and use of innovative technologies that promote patient access to high-quality
medical devices and help manufacturers to keep pace with the dynamic, rapidly changing technology
landscape, while promoting compliance with laws and regulations implemented by FDA.
FDA は、生産または品質システムの一部として使用されるコンピューター ソフトウェアにリスクベースのアプ
ローチを適用することで、21 CFR 820.70(i) の検証要件を満たすのに役立ちながら、製品の品質を確保するのに役立つ製造業者の保証活動に焦点を当てることができると考えています。 これらの理由から、FDA は現在、医療機器の製造または品質システムの一部として使用されるコンピューターおよび自動データ処理システムのコ
ンピューター ソフトウェア保証に関する推奨事項を提供しています。 FDA は、これらの推奨事項が、高品質の医療機器への患者のアクセスを促進する革新的な技術の採用と使用を促進し、製造業者が動的で急速に変化す
る技術環境に遅れずについていくのを支援すると同時に、FDA が実施する法律および規制への準拠を促進するのに役立つと考えています。

III. Scope
When final, this guidance is intended to provide recommendations regarding computer software assurance
for computers or automated data processing systems used as part of production or the quality system.
最終的に、このガイダンスは、生産または品質システムの一部として使用されるコンピューターまたは自動デー
タ処理システムのコンピューター ソフトウェア保証に関する推奨事項を提供することを目的としています。
This guidance is not intended to provide a complete description of all software validation principles. FDA has
previously outlined principles for software validation, including managing changes as part of the software
lifecycle, in FDA’s Software Validation guidance. This guidance applies the risk-based approach to software
validation discussed in the Software Validation guidance to production or quality system software. This
guidance additionally discusses specific risk considerations, acceptable testing methods, and efficient
generation of objective evidence for production or quality system software.
このガイダンスは、すべてのソフトウェア検証の原則を完全に説明することを意図したものではありません。
FDA は以前、FDA のソフトウェア検証ガイダンスで、ソフトウェア ライフサイクルの一部として変更を管理することを含め、ソフトウェア検証の原則を概説しました。 このガイダンスは、ソフトウェア検証ガイダンスで説明されているソフトウェア検証へのリスクベースのアプローチを、運用または品質システム ソフトウェアに適用します。 このガイダンスでは、特定のリスクに関する考慮事項、許容されるテスト方法、および生産または品質システム ソフトウェアの客観的な証拠の効率的な生成についても説明します。

This guidance does not provide recommendations for the design verification or validation requirements
specified in 21 CFR 820.30 when applied to software in a medical device (SiMD) or software as a medical
device (SaMD). For more information regarding FDA’s recommendations for design verification or validationof SiMD or SaMD, see the Software Validation guidance.
このガイダンスは、医療機器内のソフトウェア (SiMD) または医療機器としてのソフトウェア (SaMD) に適用される場合、21 CFR 820.30 で指定されている設計検証または検証要件の推奨事項を提供しません。 SiMD ま
たは SaMD の設計検証または検証に関する FDA の推奨事項の詳細については、ソフトウェア検証ガイダンス
を参照してください。

IV. Computer Software Assurance
Computer software assurance is a risk-based approach for establishing and maintaining confidence thatsoftware is fit for its intended use. This approach considers the risk of compromised safety and/or quality ofthe device (should the software fail to perform as intended) to determine the level of assurance effort andactivities appropriate to establish confidence in the software. Because the computer software assurance effort
is risk-based, it follows a least-burdensome approach, where the burden of validation is no more thannecessary to address the risk. Such an approach supports the efficient use of resources, in turn promoting
product quality.
コンピュータ ソフトウェア アシュアランスは、ソフトウェアが意図した用途に適合しているという信頼を確立し、維持するためのリスクベースのアプローチです。 このアプローチでは、デバイスの安全性および/または品質が損なわれるリスク (ソフトウェアが意図したとおりに機能しない場合) を考慮して、ソフトウェアに対する信頼を確立するのに適切な保証の取り組みと活動のレベルを決定します。 コンピュータ ソフトウェア保証の取り組みはリスクに基づくものであるため、検証の負担がリスクに対処するのに必要以上ではない、負担の少ないアプローチに従います。 このようなアプローチは、リソースの効率的な使用をサポートし、ひいては製品の品質を向上させます。
In addition, computer software assurance establishes and maintains that the software used in production or
the quality system is in a state of control throughout its lifecycle (“validated state”). This is important because
manufacturers increasingly rely on computers and automated processing systems to monitor and operate
production, alert responsible personnel, and transfer and analyze production data, among other uses. By
allowing manufacturers to leverage principles such as risk-based testing, unscripted testing, continuous
performance monitoring, and data monitoring, as well as validation activities performed by other entities(e.g., developers, suppliers), the computer software assurance approach provides flexibility and agility inhelping to assure that the software maintains a validated state consistent with 21 CFR 820.70(i).
さらに、コンピュータ ソフトウェア アシュアランスは、生産または品質システムで使用されるソフトウェアがそのライフサイクルを通じて管理された状態 (「検証済み状態」) にあることを確立し、維持します。 これは重要なことです。製造業者は、生産の監視と操作、担当者への警告、生産データの転送と分析などの目的で、コン
ピューターと自動処理システムにますます依存するようになっているからです。 製造業者がリスクベースのテスト、スクリプト化されていないテスト、継続的なパフォーマンス監視、データ監視などの原則を活用できるよ
うにすることで、コンピューター ソフトウェア保証アプローチは、他のエンティティ (開発者、サプライヤーなど) によって実行される検証活動と同様に、柔軟性と俊敏性を提供します。 ソフトウェアが 21 CFR 820.70(i)と一致する検証済みの状態を維持することを保証するのに役立ちます。

Software that is fit for its intended use and that maintains a validated state should perform as intended,
helping to ensure that finished devices will be safe and effective and in compliance with regulatory
requirements (see 21 CFR 820.1(a)(1)). Section V below outlines a risk-based framework for computer
software assurance
意図した用途に適合し、検証済みの状態を維持するソフトウェアは、意図したとおりに機能し、完成したデバイ
スが安全かつ効果的であり、規制要件に準拠していることを保証するのに役立ちます (21 CFR 820.1(a)(1) を参照)。 以下のセクション V では、コンピュータ ソフトウェア保証のためのリスクベースのフレームワークについて概説します。

V. Computer Software Assurance Risk Framework
The following approach is intended to help manufacturers establish a risk-based framework for computer
software assurance throughout the software’s lifecycle. Examples of applying this risk framework to various
computer software assurance situations are provided in Appendix A.
次のアプローチは、製造業者がソフトウェアのライフサイクル全体にわたってコンピュータ ソフトウェアを保証するためのリスクベースのフレームワークを確立するのを支援することを目的としています。 このリスク フ
レームワークをさまざまなコンピュータ ソフトウェア保証の状況に適用する例は、付録 A に記載されています。

A Identifying the Intended Use
The regulation requires manufacturers to validate software that is used as part of production or the quality
system for its intended use (see 21 CFR 820.70(i)). To determine whether the requirement for validation
applies, manufacturers must first determine whether the software is intended for use as part of productionor the quality system.
この規制は、製造業者に対し、製造または品質システムの一部として使用されるソフトウェアをその意図された用途のために検証することを要求しています (21 CFR 820.70(i) を参照)。 バリデーションの要件が適用されるかどうかを判断するために、メーカーはまず、ソフトウェアが生産または品質システムの一部として使用されることを意図しているかどうかを判断する必要があります。
In general, software used as part of production or the quality system falls into one of two categories: softwarethat is used directly as part of production or the quality system, and software that supports production or
the quality system.
一般に、生産または品質システムの一部として使用されるソフトウェアは、生産または品質システムの一部として直接使用されるソフトウェアと、生産または品質システムをサポートするソフトウェアの 2 つのカテゴリのいずれかに分類されます。
Software with the following intended uses are considered to be used directly as part of production or thequality system:· Software intended for automating production processes, inspection, testing, or the collection andprocessing of production data; and· Software intended for automating quality system processes, collection and processing of quality systemdata, or maintaining a quality record established under the Quality System regulation.
次の用途を意図したソフトウェアは、生産または品質システムの一部として直接使用されると見なされます。
· 生産プロセス、検査、テスト、または生産データの収集と処理の自動化を目的としたソフトウェア。 と· 品質システム プロセスの自動化、品質システム データの収集と処理、または品質システム規則に基づいて確立された品質記録の維持を目的としたソフトウェア。
Software with the following intended uses are considered to be used to support production or the quality
system:· Software intended for use as development tools that test or monitor software systems or that automate
testing activities for the software used as part of production or the quality system, such as those used fordeveloping and running scripts; and· Software intended for automating general record-keeping that is not part of the quality record.
次の用途を意図したソフトウェアは、生産または品質システムをサポートするために使用されると見なされます。
· ソフトウェア システムをテストまたは監視する開発ツールとしての使用を意図したソフトウェア、またはスクリプトの開発および実行に使用されるものなど、生産または品質システムの一部として使用されるソフト
ウェアのテスト活動を自動化するソフトウェア。 と· 品質記録の一部ではない一般的な記録管理の自動化を目的としたソフトウェア。
Both kinds of software are used as “part of” production or the quality system and must be validated under
21 CFR 820.70(i). However, as further discussed below, supporting software often carries lower risk, suchthat under a risk-based computer software assurance approach, the effort of validation may be reduced
accordingly without compromising safety.
どちらの種類のソフトウェアも、生産または品質システムの「一部」として使用され、21 CFR 820.70(i) に基づいて検証する必要があります。 ただし、以下でさらに説明するように、ソフトウェアをサポートすることでリ
スクが低くなることが多いため、リスクベースのコンピューターソフトウェア保証アプローチでは、安全性を損なうことなく、それに応じて検証の労力を減らすことができます。
On the other hand, software with the following intended uses generally are not considered to be used as partof production or the quality system, such that the requirement for validation in 21 CFR 820.70(i) would not
apply:· Software intended for management of general business processes or operations, such as email or
accounting applications; and· Software intended for establishing or supporting infrastructure not specific to production or the quality
system, such as networking or continuity of operations.
一方、次の用途を意図したソフトウェアは、一般に生産または品質システムの一部として使用されるとは見なされないため、21 CFR 820.70(i) の検証要件は適用されません。
· 電子メールや会計アプリケーションなど、一般的なビジネス プロセスまたは操作の管理を目的としたソ
フトウェア。 と· ネットワークや運用の継続性など、生産または品質システムに固有ではないインフラストラクチャの確立
またはサポートを目的としたソフトウェア。
FDA recognizes that software used in production or the quality system is often complex and comprised ofseveral features, functions, and operations; software may have one or more intended uses depending on theindividual features, functions, and operations of that software. In cases where the individual features,functions, and operations have different roles within production or the quality system, they may presentdifferent risks with different levels of validation effort. FDA recommends that manufacturers examine theintended uses of the individual features, functions, and operations to facilitate development of a risk-based
assurance strategy. Manufacturers may decide to conduct different assurance activities for individualfeatures, functions, or operations.
FDA は、製造または品質システムで使用されるソフトウェアがしばしば複雑であり、いくつかの特徴、機能、および操作で構成されていることを認識しています。 ソフトウェアには、そのソフトウェアの個々の特徴、機能、および操作に応じて、1 つまたは複数の使用目的がある場合があります。 個々の特徴、機能、および操作が生産または品質システム内で異なる役割を果たしている場合、それらはさまざまなレベルの検証作業でさまざまなリスクをもたらす可能性があります。 FDA は、製造業者がリスクベースの保証戦略の開発を促進するために、個々の特徴、機能、および操作の意図された使用を検討することを推奨しています。 製造業者は、個々の特徴、機能、または操作に対して異なる保証活動を実施することを決定する場合があります。
For example, a commercial off-the-shelf (COTS) spreadsheet software may be comprised of various functions
with different intended uses. When utilizing the basic input functions of the COTS spreadsheet software for
an intended use of documenting the time and temperature readings for a curing process, a manufacturer may
not need to perform additional assurance activities beyond those conducted by the COTS software developerand initial installation and configuration. The intended use of the software, “documenting readings,” only
supports maintaining the quality system record and poses a low process risk. As such, initial activities suchas the vendor assessment and software installation and configuration may be sufficient to establish that thesoftware is fit for its intended use and maintains a validated state. However, if a manufacturer utilizes builtin functions of the COTS spreadsheet to create custom formulas that are directly used in production or thequality system, then additional risks may be present. For example, if a custom formula automaticallycalculates time and temperature statistics to monitor the performance and suitability of the curing process,then additional validation by the manufacturer might be necessary.
例えば、市販の（COTS）表計算ソフトウェアは、異なる使用目的の様々な機能から構成されている場合がある。
COTS 表計算ソフトウェアの基本的な入力機能を使用して、硬化プロセスの時間と温度の読み取り値を文書化する目的で使用する場合、製造業者は、COTS ソフトウェア開発者および初期インストールと構成によって実施されるもの以外の追加の保証活動を実行する必要がない場合があります。ソフトウェアの使用目的である「測定値の文書化」は、品質システムの記録を維持することのみをサポートし、プロセス リスクを低く抑えます。そのため、ベンダーの評価やソフトウェアのインストールと構成などの初期作業は、ソフトウェアが意図した用途に適合し、検証済みの状態を維持していることを確認するのに十分な場合があります。ただし、メーカーが COTS
スプレッドシートの組み込み関数を利用して、生産または品質システムで直接使用されるカスタム式を作成する
場合、追加のリスクが存在する可能性があります。たとえば、硬化プロセスのパフォーマンスと適合性を監視するためにカスタム式が時間と温度の統計を自動的に計算する場合、メーカーによる追加の検証が必要になる場合があります。
For the purposes of this guidance, we describe and recommend a computer software assurance framework by
examining the intended uses of the individual features, functions, or operations of the software. However, in
simple cases where software only has one intended use (e.g., if all of the features, functions, and operations
within the software share the same intended use), manufacturers may not find it helpful to examine eachfeature, function, and operation individually. In such cases, manufacturers may develop a risk-based
approach and consider assurance activities based on the intended use of the software overall.

このガイダンスの目的のために、ソフトウェアの個々の特徴、機能、または操作の意図された使用を調べること
によって、コンピューター ソフトウェア保証フレームワークについて説明し、推奨します。 ただし、ソフトウ
ェアの使用目的が 1 つしかない単純なケース (たとえば、ソフトウェア内のすべての特徴、機能、および操作が同じ使用目的を共有している場合) では、製造業者は各特徴、機能、および操作を調べることが役に立たない場
合があります。 個別に。 このような場合、メーカーはリスクベースのアプローチを開発し、ソフトウェア全体の使用目的に基づいて保証活動を検討することができます。
FDA recommends that manufacturers document their decision-making process for determining whether asoftware feature, function, or operation is intended for use as part of production or the quality system in their
Standard Operating Procedures (SOPs).
FDA は、製造業者が、ソフトウェアの特徴、機能、または操作が製造または品質システムの一部として使用されることを意図しているかどうかを判断するための意思決定プロセスを標準操作手順 (SOP) に文書化することを推奨しています。

B. Determining the Risk-Based Approach
Once a manufacturer has determined that a software feature, function, or operation is intended for use aspart of production or the quality system, FDA recommends using a risk-based analysis to determine
appropriate assurance activities. Broadly, this risk-based approach entails systematically identifying
reasonably foreseeable software failures, determining whether such a failure poses a high process risk, andsystematically selecting and performing assurance activities commensurate with the medical device orprocess risk, as applicable.
ソフトウェアの特徴、機能、または操作が生産または品質システムの一部として使用されることを意図していると製造業者が判断した場合、FDA はリスクベースの分析を使用して適切な保証活動を決定することを推奨します。 概して、このリスクベースのアプローチには、合理的に予見可能なソフトウェア障害を体系的に特定し、そのような障害が高いプロセス リスクをもたらすかどうかを判断し、必要に応じて医療機器またはプロセス リス
クに見合った保証活動を体系的に選択して実行する必要があります。
Note that conducting a risk-based analysis for computer software assurance for production or quality system
software is distinct from performing a risk analysis for a medical device as described in ISO 14971:2019 –Medical devices – Application of risk management to medical devices. Unlike the risks contemplated in ISO
14971:2019 for analysis (medical device risks), failures of the production or the quality system software to
perform as intended do not occur in a probabilistic manner where an assessment for the likelihood of
occurrence for a particular risk could be estimated based on historical data or modeling.
ISO 14971:2019 – 医療機器 – 医療機器へのリスク管理の適用に記載されているように、生産または品質シス
テム ソフトウェアのコンピューター ソフトウェア保証のためにリスクベースの分析を実施することは、医療機器のリスク分析を実施することとは異なることに注意してください。 ISO 14971:2019 で分析のために検討されているリスク (医療機器のリスク) とは異なり、製造または品質システム ソフトウェアが意図したとおりに機能しないことは、特定のリスクの発生可能性の評価が可能であるような確率論的な方法では発生しません。 過去のデータまたはモデリングに基づいて推定されます。
Instead, the risk-based analysis for production or quality system software considers those factors that may
impact or prevent the software from performing as intended, such as proper system configuration andmanagement, security of the system, data storage, data transfer, or operation error. Thus, a risk-based
analysis for production or quality system software should consider which failures are reasonably foreseeable(as opposed to likely) and the risks resulting from each such failure. This guidance discusses both processrisks and medical device risks. A process risk refers to the potential to compromise production or the quality
system. A medical device risk refers to the potential for a device to harm the patient or user. When discussing
medical device risks, this guidance focuses on the medical device risk resulting from a quality problem thatcompromises safety.
代わりに、生産または品質システム ソフトウェアのリスクベースの分析では、適切なシステム構成と管理、シス
テムのセキュリティ、データ ストレージ、データ転送、または操作エラーなど、ソフトウェアが意図したとおりに実行するのに影響を与えたり妨げたりする可能性のある要因を考慮します。 したがって、生産または品質シ
ステム ソフトウェアのリスクベースの分析では、どの障害が合理的に予見可能であり (可能性が高いのではなく)、そのような障害のそれぞれから生じるリスクを考慮する必要があります。 このガイダンスでは、プロセスのリスクと医療機器のリスクの両方について説明しています。 プロセス リスクとは、生産または品質システムを危険にさらす可能性を指します。 医療機器のリスクとは、機器が患者やユーザーに危害を与える可能性を指します。 医療機器のリスクについて議論する場合、このガイダンスは、安全性を損なう品質問題に起因する医療機器のリスクに焦点を当てています。
Specifically, FDA considers a software feature, function, or operation to pose a high process risk when its
failure to perform as intended may result in a quality problem that foreseeably compromises safety, meaning
an increased medical device risk. This process risk identification step focuses only on the process, as opposedto the medical device risk posed to the patient or user. Examples of software features, functions, or operations
that are generally high process risk are those that:· maintain process parameters (e.g., temperature, pressure, or humidity) that affect the physicalproperties of product or manufacturing processes that are identified as essential to device safety or quality;· measure, inspect, analyze and/or determine acceptability of product or process with limited or no
additional human awareness or review;· perform process corrections or adjustments of process parameters based on data monitoring or
automated feedback from other process steps without additional human awareness or review;· produce directions for use or other labeling provided to patients and users that are necessary for safe
operation of the medical device; and/or· automate surveillance, trending, or tracking of data that the manufacturer identifies as essential todevice safety and quality.
具体的には、FDA は、ソフトウェアの特徴、機能、または操作が意図したとおりに実行されないことにより、安全性を損なう品質問題が発生する可能性があり、医療機器のリスクが高まる可能性がある場合、そのソフトウェ
アの特徴、機能、または操作が高いプロセス リスクをもたらすと見なします。このプロセス リスクの特定ステップでは、患者またはユーザーにもたらされる医療機器のリスクとは対照的に、プロセスのみに焦点を当てます。
一般にプロセスのリスクが高いソフトウェアの特徴、機能、または操作の例は次のとおりです。
· デバイスの安全性または品質に不可欠であると特定された製品または製造プロセスの物理的特性に影響を与えるプロセス パラメータ (温度、圧力、または湿度など) を維持します。
· 製品またはプロセスの受容性を測定、検査、分析、および/または決定する際に、人による追加の認識またはレビューが制限されているか、またはまったく行われていない。
· データモニタリングまたは他のプロセスステップからの自動フィードバックに基づいて、追加の人間の認識またはレビューなしで、プロセスの修正またはプロセスパラメーターの調整を実行します。
· 医療機器の安全な操作に必要な、患者およびユーザーに提供される使用説明書またはその他のラベルを作成する。および/または· メーカーがデバイスの安全性と品質に不可欠であると特定したデータの監視、傾向分析、または追跡を自動化します。
In contrast, FDA considers a software feature, function, or operation not to pose a high process risk when its
failure to perform as intended would not result in a quality problem that foreseeably compromises safety.
This includes situations where failure to perform as intended would not result in a quality problem, as wellas situations where failure to perform as intended may result in a quality problem that does not foreseeably
lead to compromised safety. Examples of software features, functions, or operations that generally are nothigh process risk include those that:· collect and record data from the process for monitoring and review purposes that do not have a direct
impact on production or process performance;· are used as part the quality system for Corrective and Preventive Actions (CAPA) routing, automatedlogging/tracking of complaints, automated change control management, or automated procedure
management;· are intended to manage data (process, store, and/or organize data), automate an existing calculation,
increase process monitoring, or provide alerts when an exception occurs in an established process; and/or· are used to support production or the quality system, as explained in Section V.A. above.
対照的に、FDA は、ソフトウェアの特徴、機能、または操作が、意図したとおりに実行されなくても安全性を損なうことが予見できる品質問題につながらない場合、高いプロセス リスクをもたらさないと考えています。これには、意図したとおりに機能しなくても品質上の問題が生じない状況や、意図したとおりに機能しなくても安全性の低下につながるとは予測できない品質上の問題が生じる可能性がある状況が含まれます。一般にプロセスのリスクが高くないソフトウェアの特徴、機能、または操作の例には、次のようなものがあります。
· 生産またはプロセスのパフォーマンスに直接影響を与えない監視およびレビューの目的で、プロセスからデータを収集および記録する。
· 是正措置および予防措置 (CAPA) ルーティング、苦情の自動記録/追跡、自動変更管理、または自動手順
管理のための品質システムの一部として使用されます。
· データの管理 (データの処理、保存、および/または整理)、既存の計算の自動化、プロセスの監視の強化、または確立されたプロセスで例外が発生した場合のアラートの提供を目的としています。および/または· セクション V.A で説明されているように、生産または品質システムをサポートするために使用されます。
その上。
FDA acknowledges that process risks associated with software used as part of production or the quality
system are on a spectrum, ranging from high risk to low risk. Manufacturers should determine the risk ofeach software feature, function, or operation as the risk falls on that spectrum, depending on the intended
use of the software. However, FDA is primarily concerned with the review and assurance for those softwarefeatures, functions, and operations that are high process risk because a failure also poses a medical device
risk. Therefore, for the purposes of this guidance, FDA is presenting the process risks in a binary manner,“high process risk” and “not high process risk.” A manufacturer may still determine that a process risk is, forexample, “moderate,” “intermediate,” or even “low” for purposes of determining assurance activities; in such

a case, the portions of this guidance concerning “not high process risk” would apply. As discussed in Section
V.C. below, assurance activities should be conducted for software that is “high process risk” and “not highprocess risk” commensurate with the risk.
FDA は、生産または品質システムの一部として使用されるソフトウェアに関連するプロセス リスクが、高リス
クから低リスクまでの範囲にあることを認めています。メーカーは、ソフトウェアの使用目的に応じて、各ソフ
トウェアの特徴、機能、または操作のリスクを特定する必要があります。ただし、FDA は主に、障害が医療機器のリスクももたらすため、プロセスのリスクが高いソフトウェアの特徴、機能、および操作のレビューと保証に関心を持っています。したがって、このガイダンスの目的のために、FDA はプロセス リスクを「プロセス リ
スクが高い」と「プロセス リスクが高くない」という 2 つの方法で提示しています。製造業者は、保証活動を決定する目的で、プロセスリスクが、例えば、「中程度」、「中程度」、または「低」でさえあると決定する場合があります。そのような場合、このガイダンスの「プロセスリスクが高くない」に関する部分が適用されます。セクション V.C で説明したように、以下では、「プロセスリスクが高い」ソフトウェアと「プロセスリスクが高くない」ソフトウェアに対して、リスクに見合った保証活動を実施する必要があります。
Example 1: An Enterprise Resource Planning (ERP) Management system contains a feature that automates
manufacturing material restocking. This feature ensures that the right materials are ordered and delivered
to appropriate production operations. However, a qualified person checks the materials before their use inproduction. The failure of this feature to perform as intended may result in a mix-up in restocking anddelivery, which would be a quality problem because the wrong materials would be restocked and delivered.
However, the delivery of the wrong materials to the qualified person should result in the rejection of thosematerials before use in production; as such, the quality problem should not foreseeably lead to compromised
safety. The manufacturer identifies this as an intermediate (not high) process risk and determines assurance
activities commensurate with the process risk. The manufacturer already undertakes some of those identified
assurance activities so implements only the remaining identified assurance activities.
例 1: エンタープライズ リソース プランニング (ERP) 管理システムには、製造資材の補充を自動化する機能が含まれています。この機能により、適切な材料が注文され、適切な生産オペレーションに届けられることが保証されます。ただし、有資格者は、生産に使用する前に材料をチェックします。この機能が意図したとおりに実行されない場合、補充と配送に混乱が生じる可能性があり、間違った材料が補充されて配送されるため、品質上の問題が発生する可能性があります。ただし、資格のある人に間違った材料を届けた場合、生産に使用する前にそれらの材料を拒否する必要があります。そのため、品質の問題によって安全性が損なわれることが予見できるものであってはなりません。製造業者は、これを中程度の (高くない) プロセス リスクとして識別し、プロセス
リスクに見合った保証活動を決定します。製造業者は、これらの特定された保証活動の一部をすでに実施しているため、残りの特定された保証活動のみを実施します。
Example 2: A similar feature in another ERP management system performs the same tasks as in the previous
example except that it also automates checking the materials before their use in production. A qualified
person does not check the material first. The manufacturer identifies this as a high process risk because thefailure of the feature to perform as intended may result in a quality problem that foreseeably compromises
safety. As such, the manufacturer will determine assurance activities that are commensurate with the related
medical device risk. The manufacturer already undertakes some of those identified assurance activities so
implements only the remaining identified assurance activities.
例 2: 別の ERP 管理システムの同様の機能は、前の例と同じタスクを実行しますが、生産で使用する前の材料

のチェックも自動化します。 有資格者は最初に材料をチェックしません。 製造業者は、機能が意図したとおりに機能しないと、安全性が損なわれると予測される品質上の問題が発生する可能性があるため、これをプロセスのリスクが高いと認識しています。 そのため、製造業者は、関連する医療機器のリスクに見合った保証活動を決定します。 製造業者は、これらの特定された保証活動の一部をすでに実施しているため、残りの特定された保証活動のみを実施します。
Example 3: An ERP management system contains a feature to automate product delivery. The medical device
risk depends upon, among other factors, the correct product being delivered to the device user. A failure ofthis feature to perform as intended may result in a delivery mix-up, which would be a quality problem that
foreseeably compromises safety; as such, the manufacturer identifies this as a high process risk. Since thefailure would compromise safety, the manufacturer will next determine the related increase in device risk
and identify the assurance activities that are commensurate with the device risk. In this case, themanufacturer has not already implemented any of the identified assurance activities so implements all of
the assurance activities identified in the analysis.
例 3: ERP 管理システムには、製品配送を自動化する機能が含まれています。 医療機器のリスクは、他の要因の中でも、適切な製品が機器のユーザーに届けられるかどうかによって異なります。 この機能が意図したとおりに実行されない場合、配信の取り違えが発生する可能性があり、これは品質上の問題であり、安全性が損なわれることが予測されます。 そのため、製造業者はこれをプロセスリスクが高いと認識しています。 失敗すると安全性が損なわれるため、製造業者は次に関連するデバイス リスクの増加を判断し、デバイス リスクに見合った保証活動を特定します。 この場合、製造業者は特定された保証活動をまだ実施していないため、分析で特定されたすべての保証活動を実施します。
Example 4: An automated graphical user interface (GUI) function in the production software is used fordeveloping test scripts based on user interactions and to automate future testing of modifications to the userinterface of a system used in production. A failure of this GUI function to perform as intended may result in
implementation disruptions and delay updates to the production system, but in this case, these errors should
not foreseeably lead to compromised safety because the GUI function operates in a separate test environment.
The manufacturer identifies this as a low (not high) process risk and determines assurance activities thatare commensurate with the process risk. The manufacturer already undertakes some of those identified
assurance activities so implements only the remaining identified assurance activities.
例 4: 実動ソフトウェアの自動化されたグラフィカル・ユーザー・インターフェース (GUI) 機能は、ユーザーの対話に基づいてテスト・スクリプトを開発し、実動で使用されるシステムのユーザー・インターフェースに対す
る変更の将来のテストを自動化するために使用されます。 この GUI 機能が意図したとおりに実行されない場
合、実装が中断され、実稼働システムへの更新が遅れる可能性がありますが、この場合、GUI 機能は別のテスト
環境で動作するため、これらのエラーによって安全性が損なわれることは予見できません。 製造業者は、これを低い (高くない) プロセス リスクとして識別し、プロセス リスクに見合った保証活動を決定します。 製造業者
は、これらの特定された保証活動の一部をすでに実施しているため、残りの特定された保証活動のみを実施します。
As noted in FDA’s guidance, “30-Day Notices, 135 Day Premarket Approval (PMA) Supplements and 75-Day
Humanitarian Device Exemption (HDE) Supplements for Manufacturing Method or Process Changes,” fordevices subject to a PMA or HDE, changes to the manufacturing procedure or method of manufacturing that

do not affect the safety or effectiveness of the device must be submitted in a periodic report (usually referred
to as an annual report). In contrast, modifications to manufacturing procedures or methods of manufacturethat affect the safety and effectiveness of the device must be submitted in a 30-day notice. Changes to the
manufacturing procedure or method of manufacturing may include changes to software used in productionor the quality system. For an addition or change to software used in production or the quality system ofdevices subject to a PMA or HDE, FDA recommends that manufacturers apply the principles outlined above
in determining whether the change may affect the safety or effectiveness of the device. In general, if a change
may result in a quality problem that foreseeably compromises safety, then it should be submitted in a 30-day
notice. If a change would not result in a quality problem that foreseeably compromises safety, an annual
report may be appropriate.
FDA のガイダンス「30 日前の通知、135 日前の市販前承認 (PMA) 補足、および 75 日間の人道的機器免除(HDE) による製造方法またはプロセスの変更に関する補足」に記載されているように、PMA または HDE の対象となる機器については、次のように変更されます。装置の安全性または有効性に影響を与えない製造手順または製造方法は、定期報告書 (通常、年次報告書と呼ばれます) で提出する必要があります。対照的に、デバイスの安全性と有効性に影響を与える製造手順または製造方法の変更は、30 日前に通知する必要があります。製
造手順または製造方法の変更には、生産に使用されるソフトウェアまたは品質システムの変更が含まれる場合があります。 PMA または HDE の対象となるデバイスの製造または品質システムで使用されるソフトウェアへの追加または変更について、FDA は、変更がデバイスの安全性または有効性に影響を与える可能性があるかどうかを判断する際に、製造業者が上記の原則を適用することを推奨します。一般に、変更によって安全性が損なわれることが予測される品質上の問題が発生する可能性がある場合は、30 日前に通知する必要があります。変更によって安全性が損なわれることが予見できる品質問題にならない場合は、年次報告書が適切かもしれません。
For example, a Manufacturing Execution System (MES) may be used to manage workflow, track progress,
record data, and establish alerts or thresholds based on validated parameters, which are part of maintaining
the quality system. Failure of such an MES to perform as intended may disrupt operations but not affect theprocess parameters established to produce a safe and effective device. Changes affecting these MES
operations are generally considered annually reportable. In contrast, an MES used to automatically control
and adjust established critical production parameters (e.g., temperature, pressure, process time) may be achange to a manufacturing procedure that affects the safety or effectiveness of the device. If so, changes
affecting this specific operation would require a 30-day notice.
たとえば、製造実行システム (MES) を使用して、ワークフローの管理、進行状況の追跡、データの記録、および検証済みのパラメーターに基づくアラートまたはしきい値の確立を行うことができます。これらは、品質シス
テムの維持の一部です。 このような MES が意図したとおりに機能しない場合、操作が中断される可能性がありますが、安全で効果的なデバイスを製造するために確立されたプロセス パラメータには影響しません。 これらの MES 業務に影響を与える変更は、通常、毎年報告する必要があると見なされます。 対照的に、確立された重要な生産パラメーター (温度、圧力、処理時間など) を自動的に制御および調整するために使用される MESは、デバイスの安全性または有効性に影響を与える製造手順の変更になる可能性があります。 その場合、この特定の操作に影響する変更には 30 日前の通知が必要です。

C. Determining the Appropriate Assurance Activities
Once the manufacturer has determined whether a software feature, function, or operation poses a highprocess risk (a quality problem that may foreseeably compromise safety), the manufacturer should identify
the assurance activities commensurate with the medical device risk or the process risk. In cases where thequality problem may foreseeably compromise safety (high process risk), the level of assurance should becommensurate with the medical device risk. In cases where the quality problem may not foreseeablycompromise safety (not high process risk), the level of assurance rigor should be commensurate with theprocess risk. In either case, heightened risks of software features, functions, or operations generally entail
greater rigor, i.e., a greater amount of objective evidence. Conversely, relatively less risk (i.e., not high processrisk) of compromised safety and/or quality generally entails less collection of objective evidence for thecomputer software assurance effort.
メーカーは、ソフトウェアの特徴、機能、または操作が高いプロセス リスク (安全性を危うくすることが予見できる品質問題) をもたらすかどうかを判断したら、医療機器リスクまたはプロセス リスクに見合った保証活動を特定する必要があります。 品質問題により安全性が損なわれる可能性が予見できる場合 (プロセス リスクが高い)、保証のレベルは医療機器のリスクに見合ったものにする必要があります。 品質問題が予見できるほど安全性を損なう可能性がない場合 (プロセス リスクが高くない場合)、保証の厳密さのレベルはプロセス リスクに見合ったものにする必要があります。 どちらの場合でも、ソフトウェアの特徴、機能、または操作のリスクが高
まると、一般に、より厳格な、つまりより多くの客観的な証拠が必要になります。 逆に、安全性および/または
品質が損なわれるリスクが比較的低い (つまり、プロセスのリスクが高くない) 場合、一般に、コンピューター
ソフトウェア保証の取り組みのための客観的な証拠の収集が少なくなります。
A feature, function, or operation that could lead to severe harm to a patient or user would generally be highdevice risk. In contrast, a feature, function, or operation that would not foreseeably lead to severe harm would
likely not be high device risk. In either case, the risk of the software’s failure to perform as intended iscommensurate with the resulting medical device risk.
患者またはユーザーに重大な危害をもたらす可能性のある特徴、機能、または操作は、一般にデバイス リスクが高くなります。 対照的に、深刻な害をもたらすことが予見できない特徴、機能、または操作は、デバイスのリス
クが高くない可能性があります。 どちらの場合でも、ソフトウェアが意図したとおりに機能しないリスクは、結果として生じる医療機器のリスクに見合ったものです。
If the manufacturer instead determined that the software feature, function, or operation does not pose a highprocess risk (i.e., it would not lead to a quality problem that foreseeably compromises safety), themanufacturer should consider the risk relative to the process, i.e., production or the quality system. This isbecause the failure would not compromise safety, so the failure would not introduce additional medical device
risk. For example, a function that collects and records process data for review would pose a lower process
risk than a function that determines acceptability of product prior to human review.
代わりに、ソフトウェアの特徴、機能、または操作が高いプロセス リスクをもたらさない (つまり、安全性を損なうことが予見できる品質問題につながらない) とメーカーが判断した場合、メーカーはプロセスに関連するリ
スクを考慮する必要があります。生産または品質システム。 これは、故障によって安全性が損なわれることはな
く、故障によって医療機器のリスクが増えることはないからです。 たとえば、レビューのためにプロセス デー
タを収集して記録する機能は、人によるレビューの前に製品の許容性を判断する機能よりもプロセス リスクが低くなります。
Types of assurance activities commonly performed by manufacturers include, but are not limited to, thefollowing:
製造業者が一般的に実施する保証活動の種類には、以下が含まれますが、これらに限定されません。
· Unscripted testing – Dynamic testing in which the tester’s actions are not prescribed by written instructions
in a test case. It includes:· Ad-hoc testing – A concept derived from unscripted practice that focuses primarily on performing
testing that does not rely on large amounts of documentation (e.g., test procedures) to execute.
· Error-guessing – A test design technique in which test cases are derived on the basis of the tester’sknowledge of past failures or general knowledge of failure modes.
· Exploratory testing – Experience-based testing in which the tester spontaneously designs and executes
tests based on the tester’s existing relevant knowledge, prior exploration of the test item (including resultsfrom previous tests), and heuristic “rules of thumb” regarding common software behaviors and types of failure.
Exploratory testing looks for hidden properties, including hidden, unanticipated user behaviors, or accidental
use situations that could interfere with other software properties being tested and could pose a risk ofsoftware failure.
· スクリプト化されていないテスト – テスターのアクションがテスト ケースの書面による指示によって規定されていない動的テスト。以下が含まれます。
· アドホック（必要に応じた） テスト – 実行するために大量のドキュメント (テスト手順など) に依存しないテストの実行に主に焦点を当てたスクリプト化されていない実践から派生した概念。
· エラー推測 – 過去の失敗に関するテスト担当者の知識または失敗モードに関する一般的な知識に基づいてテスト ケースを導出するテスト設計手法。
· 探索的テスト - テスターが既存の関連知識、テスト項目の以前の調査 (以前のテストの結果を含む)、および一般的なソフトウェア動作に関するヒューリスティック（誰かに何かを発見したり学ぶことを可能にすること）な「経験則」に基づいて自発的にテストを設計および実行する経験ベースのテスト。そして失敗の種類。探索的テストでは、隠された予期しないユーザーの行動や、テスト対象の他のソフトウェア プロパティに干渉し、ソフトウェア障害のリスクを引き起こす可能性のある偶発的な使用状況など、隠されたプロパティを探します。
· Scripted testing – Dynamic testing in which the tester’s actions are prescribed by written instructions in atest case. Scripted testing includes both robust and limited scripted testing.
· Robust scripted testing – Scripted testing efforts in which the risk of the computer system or
automation includes evidence of repeatability, traceability to requirements, and auditability.
· Limited scripted testing – A hybrid approach of scripted and unscripted testing that is appropriately
scaled according to the risk of the computer system or automation. This approach may apply scripted testingfor high-risk features or operations and unscripted testing for low- to medium-risk items as part of the sameassurance effort.
· スクリプト化されたテスト – テスターのアクションがテスト ケースの書面による指示によって規定される
動的テスト。 スクリプト テストには、堅牢なスクリプト テストと限定的なスクリプト テストの両方が含まれます。
· 堅牢なスクリプト テスト – コンピュータ システムまたは自動化のリスクに、再現性、要件への追跡可
能性、および監査可能性の証拠が含まれるスクリプト テスト作業。
· 限定的なスクリプト テスト – コンピュータ システムまたは自動化のリスクに応じて適切に拡張される、スクリプト テストと非スクリプト テストのハイブリッド アプローチ。 このアプローチでは、同じ保証作業の一環として、高リスクの機能または操作に対するスクリプト化されたテストと、低から中リスクの項目に対するスクリプト化されていないテストを適用できます。

In general, FDA recommends that manufacturers apply principles of risk-based testing in which the
management, selection, prioritization, and use of testing activities and resources are consciously based oncorresponding types and levels of analyzed risk to determine the appropriate activities. For high-risk
software features, functions, and operations, manufacturers may choose to consider more rigor such as theuse of scripted testing or limited scripted testing, as appropriate, when determining their assurance activities.
In contrast, for software features, functions, and operations that are not high-risk, manufacturers may
consider using unscripted testing methods such as ad-hoc testing, error-guessing, exploratory testing, or a
combination of methods that is suitable for the risk of the intended use.
一般に、FDA は、適切な活動を決定するために、分析されたリスクの対応するタイプとレベルに意識的に基づいて、テスト活動とリソースの管理、選択、優先順位付け、および使用を行う、リスクベースのテストの原則を製造業者が適用することを推奨しています。 リスクの高いソフトウェアの特徴、機能、および操作については、製造業者は、保証活動を決定する際に、必要に応じて、スクリプト化されたテストまたは限定的なスクリプト化されたテストの使用など、より厳密に検討することを選択できます。 対照的に、リスクが高くないソフトウェアの特徴、機能、および操作については、メーカーは、アドホック テスト、エラー推測、探索的テスト、またはリスクに適した方法の組み合わせなど、スクリプト化されていないテスト方法の使用を検討できます。 使用目的の。
When deciding on the appropriate assurance activities, manufacturers should consider whether there are
any additional controls or mechanisms in place throughout the quality system that may decrease the impact
of compromised safety and/or quality if failure of the software feature, function or operation were to occur.
For example, as part of a comprehensive assurance approach, manufacturers can leverage the following to
reduce the effort of additional assurance activities:
適切な保証活動を決定する際、製造業者は、ソフトウェアの特徴、機能、または操作に障害が発生した場合に、安全性および/または品質が損なわれた場合の影響を軽減する可能性のある追加の管理またはメカニズムが品質システム全体に導入されているかどうかを検討する必要があります。 たとえば、包括的な保証アプローチの一環として、製造業者は以下を活用して、追加の保証活動の労力を削減できます。
· Activities, people, and established processes that provide control in production. Such activities may
include procedures to ensure integrity in the data supporting production or software quality assurance
processes performed by other organizational units.
· 生産における制御を提供する活動、人、および確立されたプロセス。 このような活動には、他の組織単位
によって実行される生産またはソフトウェアの品質保証プロセスをサポートするデータの整合性を確保するための手順が含まれる場合があります。
· Established purchasing control processes for selecting and monitoring software developers. For
example, the manufacturer could incorporate the practices, validation work, and electronic information
already performed by developers of the software as the starting point and determine what additional
activities may be needed. For some lower-risk software features, functions, and operations, this may be all
the assurance that is needed by the manufacturer.
· ソフトウェア開発企業を選択および監視するための購入管理プロセスを確立しました。 たとえば、製造業者は、ソフトウェアの開発者がすでに実施しているプラクティス、検証作業、および電子情報を出発点として組み込み、どのような追加の活動が必要になるかを判断できます。 一部のリスクの低いソフトウェアの特徴、機能、および操作については、これがメーカーが必要とするすべての保証である場合があります。

· Additional process controls that have been incorporated throughout production. For example, if aprocess is fully understood, all critical process parameters are monitored, and/or all outputs of a process
undergo verification testing, these controls can serve as additional mechanisms to detect and correct theoccurrence of quality problems that may occur if a software feature, function, or operation were to fail toperform as intended. In this example, the presence of these controls can be leveraged to reduce the effort ofassurance activities appropriate for the software.
· 生産全体に組み込まれた追加のプロセス管理。 たとえば、プロセスが完全に理解されている場合、すべての重要なプロセス パラメータが監視されている場合、および/またはプロセスのすべての出力が検証テストを受けている場合、これらのコントロールは、次の場合に発生する可能性のある品質問題の発生を検出および修正するための追加のメカニズムとして機能します。 ソフトウェアの特徴、機能、または操作が意図したとおりに実行されない可能性があります。 この例では、これらのコントロールの存在を活用して、ソフトウェアに適した保証
アクティビティの労力を削減できます。
· The data and information periodically or continuously collected by the software for the purposes ofmonitoring or detecting issues and anomalies in the software after implementation of the software. The
capability to monitor and detect performance issues or deviations and system errors may reduce the risk
associated with a failure of the software to perform as intended and may be considered when deciding on
assurance activities.
· ソフトウェアの実装後にソフトウェアの問題や異常を監視または検出する目的で、ソフトウェアによって定期的または継続的に収集されるデータおよび情報。 パフォーマンスの問題または逸脱およびシステムエラーを監視および検出する機能は、ソフトウェアが意図したとおりに機能しないことに関連するリスクを軽減する可能性があり、保証活動を決定する際に考慮することができます。
· The use of Computer System Validation tools (e.g., bug tracker, automated testing) for the assurance ofsoftware used in production or as part of the quality system whenever possible.
· 本番環境で、または品質システムの一部として使用されるソフトウェアを可能な限り保証するためのコンピュータ システム検証ツール (バグ トラッカー、自動テストなど) の使用。
· The use of testing done in iterative cycles and continuously throughout the lifecycle of the software
used in production or as part of the quality system.
· 本番環境または品質システムの一部として使用されるソフトウェアのライフサイクル全体にわたって、反復サイクルで継続的に行われるテストの使用。
For example, supporting software, as referenced in Section V.A., often carries lower risk, such that theassurance effort may generally be reduced accordingly. Because assurance activities used “directly” inproduction or the quality system often inherently cover the performance of supporting software, assurance
that this supporting software performs as intended may be sufficiently established by leveraging vendor
validation records, software installation, or software configuration, such that additional assurance activities(e.g., scripted or unscripted testing) may be unnecessary.
たとえば、セクション V.A. で参照されているように、サポートするソフトウェアは、多くの場合、リスクが低
いため、それに応じて保証作業が一般的に削減される可能性があります。 生産または品質システムで「直接」使用される保証活動は、多くの場合、本質的にサポート ソフトウェアのパフォーマンスをカバーするため、このサ
ポート ソフトウェアが意図したとおりに機能するという保証は、ベンダーの検証記録、ソフトウェアのインス
トール、またはソフトウェアの構成を活用することによって十分に確立される可能性があります。 保証活動 (例:スクリプト化またはスクリプト化されていないテスト) は不要な場合があります。

Manufacturers are responsible for determining the appropriate assurance activities for ensuring the softwarefeatures, functions, or operations maintain a validated state. The assurance activities and considerations
noted above are some possible ways of providing assurance and are not intended to be prescriptive or
exhaustive. Manufacturers may leverage any of the activities or a combination of activities that are mostappropriate for risk associated with the intended use.
製造業者は、ソフトウェアの特徴、機能、または操作が検証済みの状態を維持することを保証するための適切な保証活動を決定する責任があります。 上記の保証活動と考慮事項は、保証を提供するためのいくつかの可能な方法であり、規範的または網羅的なものではありません。 製造業者は、意図された使用に関連するリスクに最も適した活動のいずれか、または活動の組み合わせを活用することができます。

D. Establishing the Appropriate Record
When establishing the record, the manufacturer should capture sufficient objective evidence to demonstratethat the software feature, function, or operation was assessed and performs as intended. In general, therecord should include the following:· the intended use of the software feature, function, or operation;· the determination of risk of the software feature, function, or operation;· documentation of the assurance activities conducted, including:· description of the testing conducted based on the assurance activity;· issues found (e.g., deviations, failures) and the disposition;· conclusion statement declaring acceptability of the results;· the date of testing/assessment and the name of the person who conducted the testing/assessment;· established review and approval when appropriate (e.g., when necessary, a signature and date of anindividual with signatory authority)
記録を確立する際、メーカーは、ソフトウェアの特徴、機能、または操作が評価され、意図したとおりに実行されたことを示す十分な客観的証拠を取得する必要があります。 一般に、記録には次の内容を含める必要があります。
· ソフトウェアの特徴、機能、または操作の使用目的。
· ソフトウェアの特徴、機能、または操作のリスクの決定。
· 以下を含む、実施された保証活動の文書化:· 保証活動に基づいて実施されたテストの説明。
· 見つかった問題 (例: 逸脱、失敗) と処置。
· 結果の許容可能性を宣言する結論声明。
· テスト/評価の日付とテスト/評価を実施した人物の名前。
· 必要に応じて確立されたレビューと承認 (たとえば、必要に応じて、署名権限を持つ個人の署名と日付)
Documentation of assurance activities need not include more evidence than necessary to show that thesoftware feature, function, or operation performs as intended for the risk identified. FDA recommends therecord retain sufficient details of the assurance activity to serve as a baseline for improvements or as areference point if issues occur.
保証活動の文書化には、特定されたリスクに対してソフトウェアの特徴、機能、または操作が意図したとおりに機能することを示すために必要以上の証拠を含める必要はありません。 FDA は、改善のためのベースラインとして、または問題が発生した場合の参照点として機能するように、記録が保証活動の十分な詳細を保持することを推奨します。
Table 1 provides some examples of ways to implement and develop the record when using the risk-based
testing approaches identified in Section V.C. above. Manufacturers may use alternative approaches andprovide different documentation so long as their approach satisfies applicable legal documentation
requirements.
表 1 は、上記セクション V.C. で特定されたリスクベースのテスト アプローチを使用する場合に記録を実装および作成する方法の例をいくつか示しています。 製造業者は、そのアプローチが該当する法的文書要件を満たす限り、別のアプローチを使用して別の文書を提供することができます。
Table 1 – Examples of Assurance Activities and Records
Assurance

Test Plan

Test Results

RecordActivity(Including Digital)

Scripted· Test objectives*Pass/fail for test case*Intended use

Testing:· Test cases (step-by-·· Risk determination · Detailed report ofRobuststep procedure)

any

testing performed· Expected results

failures/deviations· Pass/fail result for each test case ·· Independent review

foundIssues found and disposition

Details

regardingand approval of test

· Conclusion statement

cases· Record of who performed testing anddate· Established review and approval whenappropriate

Scripted· Limited test cases*Pass/fail for test case*Intended use

Testing:(step-by-step

identified· Risk determination

Limitedprocedure) identified·· Expected results forany

performed

the test cases

failures/deviations· Pass/fail test result for each test case

· Identify unscripted

found· Issues found and disposition

Details

regarding·Summary

descriptionoftesting

testing applied· Conclusion statement· Independent review· Record of who performed testing andand approval of test

date

plan

· Established review and approval whenappropriate

Unscripted*Testing of features*Details

regarding*Intended use

Testing:and functions withany

· Risk determination

Ad-hocno test plan

failures/deviations· Summary description of features andfound

functions tested and testing performed· Issues found and disposition· Conclusion statement· Record of who performed testing anddate of testing· Established review and approval whenappropriate
Unscripted

Testing

Testing:
Error guessingoffailure-Details regarding any*Intended use

modes with no test

failures/· Risk determination

plan

found

deviations· Summary description of features andfunctions tested and testing performed· Issues found and disposition· Conclusion statement· Record of who performed testing anddate of testing· Established review and approval whenappropriate

Unscripted

Establish high level*Pass/fail for each test

*Intended use

Testing:

test plan objectives

plan objective· Risk determination

Exploratory(no·· Summary description of the objectives

Testing

procedure

step-by-stepisnecessary)

Details

regardinganytested and testing performed

failures/deviations· Pass/fail test result for each objectivefound· Issues found and disposition· Conclusion statement· Record of who performed testing anddate of testing· Established review and approval whenappropriate

Assurance

Test Plan

Test Results

Activity

Record(Including Digital)

スクリプト化さ· テストの目的

・テストケースの合格/

・使用目的

れたテスト:

・テストケース（段階

不合格· リスクの決定

屈強

的な手順）

· 見つかった不具合/逸· 実施されたテストの詳細なレポート

・ 予想される結果脱に関する詳細

・各テストケースの合否結果

・テストケースの独立・見つかった課題と処置したレビューと承認・結論書
・誰がテストを実施したか、および日付の記録
・必要に応じて確立されたレビューと承認スクリプト化さ· 限定的なテスト ケ

・識別されたテストケ

・使用目的

れたテスト:ース (段階的な手順)

ースの合格/不合格

・リスク判定限定的の特定· 見つかった不具合/逸·実施した試験の概要説明· テストケースの期脱に関する詳細

・各テストケースの合否判定結果

待される結果・見つかった問題と処分

· 適用されたスクリ・結論文

プト化されていない

・誰がテストを実施したか、および日付のテストを特定する

記録· テスト計画の独立

・必要に応じて確立されたレビューと承したレビューと承認

認スクリプト化さ・テスト計画のない特· 見つかった不具合/逸・使用目的

れていないテス

徴と機能のテスト

脱に関する詳細・リスク判定ト:· テスト済みおよび実施済みのテストのアドホック

特徴と機能の概要説明
・見つかった問題と処分・結論文· 誰がテストを実施したか、およびテストの日付の記録
・必要に応じて確立されたレビューと承認スクリプト化さ

テスト計画のない故· 見つかった不具合/逸*使用目的れていないテス

障モードのテスト

脱に関する詳細・リスク判定ト:· テスト済みおよび実施済みのテストのエラー推測

特徴と機能の概要説明
・見つかった問題と処分・結論文· 誰がテストを実施したか、およびテストの日付の記録
・必要に応じて確立されたレビューと承認スクリプト化さ高レベルのテスト計

・テスト計画の目的ご・使用目的

れていないテス

画の目標を確立しまとに合格/不合格

・リスク判定ト:

す (段 階 的 な 手 順 は· 見つかった不具合/逸· テスト対象と実行されたテストの概要

探索的テスト

必要ありません)。

脱に関する詳細説明・各目標の合否判定結果
・見つかった問題と処分・結論文· 誰がテストを実施したか、およびテストの日付の記録
・必要に応じて確立されたレビューと承認

The following is an example of a record of assurance in a scenario where a manufacturer has developed a
spreadsheet with the intended use of collecting and graphing nonconformance data stored in a controlled
system for monitoring purposes. In this example, the manufacturer has established additional processcontrols and inspections that ensure non-conforming product is not released. In this case, failure of the
spreadsheet to perform as intended would not result in a quality problem that foreseeably leads tocompromised safety, so the spreadsheet would not pose a high process risk. The manufacturer conducted
rapid exploratory testing of specific functions used in the spreadsheet to ensure that analyses can be created,
read, updated, and/or deleted. During exploratory testing, all calculated fields updated correctly except for
one deviation that occurred during update testing. In this scenario, the record would be documented asfollows:
以下は、監視目的で管理されたシステムに保存された不適合データを収集してグラフ化する目的で製造業者がス
プレッドシートを開発したシナリオにおける保証の記録の例です。 この例では、製造業者は、不適合製品がリリースされないようにする追加のプロセス管理と検査を確立しています。 この場合、スプレッドシートが意図したとおりに実行されなくても、安全性が損なわれることが予見できる品質問題にはならないため、スプレッドシートが高いプロセス リスクをもたらすことはありません。 製造業者は、スプレッドシートで使用される特定の機能の迅速な探索的テストを実施して、分析を作成、読み取り、更新、および/または削除できることを確認しました。 探索的テスト中に、更新テスト中に発生した 1 つの逸脱を除いて、すべての計算フィールドが正しく更新されました。 このシナリオでは、レコードは次のように文書化されます。
· Intended Use: The spreadsheet is intended for use in collecting and graphing nonconformance data stored
in a controlled system for monitoring purposes; as such, it is used as part of production or the quality system.
Because of this use, the spreadsheet is different from similar software used for business operations such as
for accounting.
· 使用目的: スプレッドシートは、監視目的で管理されたシステムに保存されている不適合データを収集してグラフ化するために使用することを目的としています。 そのため、生産または品質システムの一部として使用されます。 このため、スプレッドシートは、会計などの業務に使用される同様のソフトウェアとは異なります。
· Risk-Based Analysis: In this case, the software is only used to collect and display data for monitoring
nonconformances, and the manufacturer has established additional process controls and inspections toensure that nonconforming product is not released. Therefore, failure of the spreadsheet to perform as
intended should not result in a quality problem that foreseeably leads to compromised safety. As such, thesoftware does not pose a high process risk, and the assurance activities should be commensurate with theprocess risk.
· リスクベース分析: この場合、ソフトウェアは不適合を監視するためのデータを収集して表示するためにのみ使用され、メーカーは追加のプロセス管理と検査を確立して、不適合製品がリリースされないようにします。 したがって、スプレッドシートが意図したとおりに機能しなくても、安全性が損なわれることが予測されるような品質上の問題が発生することはありません。 そのため、ソフトウェアが高いプロセス リスクをもたらすことはなく、保証活動はプロセス リスクに見合ったものでなければなりません。
· Tested: Spreadsheet X, Version 1.2· テスト済み: スプレッドシート X、バージョン 1.2· Test type: Unscripted testing – exploratory testing· テストの種類: スクリプト化されていないテスト – 探索的テスト· Goal: Ensure that analyses can be correctly created, read, updated, and deleted· 目標: 分析を正しく作成、読み取り、更新、および削除できるようにする· Testing objectives and activities:o Create new analysis – Passedo Read data from the required source – Passed
o Update data in the analysis – Failed due to input error, then passedo Delete data – Passed

o Verify through observation that all calculated fields correctly update with changes – Passed with
noted deviation· テストの対象と活動:
o 新しい分析の作成 – 合格
o 必要なソースからデータを読み取る – 合格
o 分析でデータを更新する – 入力エラーが原因で失敗し、その後合格しました
o データの削除 – 合格o すべての計算フィールドが変更に応じて正しく更新されることを観察によって検証する –合格（指摘された逸脱あり）· Deviation: During update testing, when the user inadvertently input text into an updatable field requiring
numeric data, the associated row showed an immediate error· 逸脱: 更新のテスト中に、ユーザーが数値データを必要とする更新可能なフィールドに誤ってテキストを入力すると、関連する行にすぐにエラーが表示されました。
· Conclusion: No errors were observed in the spreadsheet functions beyond the deviation. Incorrectly
inputting text into the field is immediately visible and does not impact the risk of the intended use. In
addition, a validation rule was placed on the field to permit only numeric data inputs.
· 結論: 表計算関数に上記逸脱以上のエラーは見られませんでした。 フィールドにテキストを誤って入力するとすぐに表示され、意図された使用のリスクに影響を与えません。 さらに、数値データ入力のみを許可する検証
ルールがフィールドに配置されました。
· When/Who: July 9, 2019, by Jane Smith
Advances in digital technology may allow for manufacturers to leverage automated traceability, testing, andthe electronic capture of work performed to document the results, reducing the need for manual or paperbased documentation. As a least burdensome method, FDA recommends the use of electronic records, suchas system logs, audit trails, and other data generated by the software, as opposed to paper documentationand screenshots, in establishing the record associated with the assurance activities
デジタル技術の進歩により、メーカーは自動化されたトレーサビリティ、テスト、および結果を文書化するために実行された作業の電子キャプチャを活用できるようになり、手動または紙ベースの文書化の必要性が減少します。 最も負担の少ない方法として、FDA は、保証活動に関連する記録を確立する際に、紙の文書やスクリーン
ショットではなく、システム ログ、監査証跡、およびソフトウェアによって生成されたその他のデータなどの電子記録の使用を推奨しています。
Manufacturers have expressed confusion and concern regarding the application of Part 11, Electronic
Records; Electronic Signatures, to computers or automated data processing systems used as part ofproduction or the quality system. As described in the “Part 11, Electronic Records; Electronic Signatures –Scope and Application” guidance, the Agency intends to exercise enforcement discretion regarding Part 11
requirements for validation of computerized systems used to create, modify, maintain, or transmit electronic
records (see 21 CFR 11.10(a) and 11.30). In general, Part 11 applies to records in electronic form that are
created, modified, maintained, archived, retrieved, or transmitted under any records requirements set forthin Agency regulations (see 21 CFR 11.1(b)). Part 11 also applies to electronic records submitted to the Agency
under requirements of the Federal Food, Drug, and Cosmetic Act (FD&C Act) and the Public Health Service
Act (PHS Act), even if such records are not specifically identified in Agency regulations (see 21 CFR 11.1(b)).

製造業者は、パート 11、電子記録の適用に関して混乱と懸念を表明しています。生産または品質システムの一部として使用されるコンピューターまたは自動データ処理システムへの電子署名。 「第 11 部、電子記録;電子署名 – 範囲と適用」のガイダンスに従って、当局は、電子記録の作成、変更、維持、または送信に使用されるコンピュータ化されたシステムの検証に関するパート 11 要件に関して執行の裁量権を行使する予定です (21CFR 11.10(a) および 11.30 を参照)。
一般に、パート 11 は、当局の規則で定められた記録要件に基づいて作成、変更、維持、アーカイブ、検索、または送信される電子形式の記録に適用されます (21 CFR 11.1(b) を参照)。パート 11 は、連邦食品医薬品化粧品法 (FD&C 法) および公衆衛生サービス法 (PHS 法) の要件に基づいて当局に提出された電子記録にも適用されます。 21 CFR 11.1(b)を参照)。
In the context of computer or automated data processing systems, for computer software used as part ofproduction or the quality system, a document required under Part 820 and maintained in electronic form
would generally be an “electronic record” within the meaning of Part 11 (see 21 CFR 11.3(b)(6)). For example,
if a document requires a signature under Part 820 and is maintained in electronic form, then Part 11 applies(see, e.g., 21 CFR 820.40 (requiring signatures for control of required documents)).
コンピュータまたは自動化されたデータ処理システムのコンテキストでは、生産または品質システムの一部として使用されるコンピュータ ソフトウェアの場合、パート 820 で要求され、電子形式で維持されるドキュメント
は、通常、パート 11 ( 21 CFR 11.3(b)(6)を参照)が定義する“電子記録”です。 たとえば、文書がパート 820に基づく署名を必要とし、電子形式で維持される場合、パート 11 が適用されます (たとえば、21 CFR 820.40(必要な文書の管理のために署名を要求する) を参照)。