Software in Medical Devices, by MD101 Consulting

ISO/DTR 80002-2 and AAMI TIR 36

ISO/DTR 80002-2 maximizes the reuse of the only existing document on this subject published by a normalization organization: the AAMI TIR 36 Validation of software for regulated processes.
Thus, most of AAMI TIR 36 document is copied-pasted to ISO/DTR 80002-2:
The main chapters:

• 3- Software validation discussion,
• 4- Software validation and critical thinking,
• 5- Documentation,
• 6- Prerequisite processes

And the annexes:

• A - the toolbox,
• B - Risk Management,
• C - Examples

From 21 CFR and FDA, to international scope

The main difference between both documents is the "internationalization" of ISO/DTR 80002-2:

• The introduction found in AMMI TIR 36 on the regulatory context focused on 21 CFR was quite logically removed from this DTR,
• References made to the FDA and 21 CFR throughout the AAMI TIR 36 were replaced by an equivalent wording with an international point of view, when possible.

Other differences are minor changes to the body text:

• to make it more up-to-date, eg. replace the term automated by controlled by software,
• to rephrase, reorganize or remove some portions of texts and graphics to make it more articulate (at last, we hope so!).

In the annexes, the most visible changes are:

• the removal of the "value" column in the Annex A - toolbox,
• the rewording of Annex B on risk management.

The new wording in annex B of ISO/DTR 80002-2 is probably the most significant change. AAMI TIR 36 didn't rely on ISO 14971 the way an international standard should do. Thus, ISO/DTR 80002-2 is totally rewritten to be consistent with ISO 14971 risk management process.

What's inside?

For those who never read AAMI TIR 36, ISO/TR 80002-1 defines a risk-based approach on validation of software used in QMS. Thus it matches the new requirement of ISO 13485:2016.

The validation is split in 3 phases:

• Develop, with
  • Define,
  • Implement,
  • Test,
  • Deploy,
• Maintain, and
• Retire.

Define

This phase contains the definition of the scope, the intended use, use requirements of the QMS software tool. It also contains a risk analysis at process level, i.e. in processes where the QMS software tool is used. And It defines the validation plan.

Implement

This phase is the software design, coding and low-level testing for in-house developed software or bespoke software (even if the manufacturer outsources the software development). It also contains the risk assessment at software level: software failures, mitigations actions and traceability between risks, software requirements, and software tests.

For off-the-shelf software, the design and coding are replaced by vendor audit. The risk assessment shall identify software failures and their consequences. The mitigation actions, however, can be implemented in software only if it is feasible.

Test

This phase is software verification: integration, GUI, non-regression, stress-test, ... whatever test methods relevant to your software. Here, software is supposed to be verified on a test bench or test platform, not the target platform.

Deploy

This phase is the installation of the software tool on the target platform and it commissioning.
This is were you find the traditional IQ/OQ/PQ, and related activities like operators training.
Note that formal IQ/OQ/PQ are not required by this technical report. It reads explicitly: Select and conduct activity where appropriate.

Maintain

This phase is the maintenance of the QMS software tool, with maintenance plan, bugs analysis, system monitoring, backup and recovery processes.

Retire

This phase is the decommissioning of the QMS software tool.

Conclusion - Not a revolution

Based on this draft standard, we can see that ISO/TR 80002-2 won't be a revolution. It is the logical next step after the introduction to ISO 13485:2016 of requirements on QMS software validation, similar to those in 21 CFR 820.
Manufacturers, which already validate and maintain QMS software by applying the principles of AMMI/TIR 36, will simply have to continue their validation efforts.
Manufacturers in transition to ISO 13485:2016 will probably have to apply this new technical report.

Additional reading

If you don't want to start from a white page, see the QMS software validation templates in the Template Repository for software: Software Validation Plan, Software Validation Protocol and Software Validation Report.

See also previous discussions on validation of software used in production and QMS and on validation of IDE or software tools used for software design.

For those who wonder how to validate workflow and data management software like Jira or Redmine, you won't find any example in AAMI TIR 36 or ISO/TR 80002-2. This is the subject of the next article on this blog.