Software in Medical Devices, by MD101 Consulting

Edit 01 May 2021: the draft has been rejected. The project is closed. It means that IEC 62304 2006 + Amd1:2015 will remain valid for some more years.
And everything written below is obsolete.

Compared to the last draft version, there isn't any significant change for software qualified as medical devices (MDSW).
Some people keen at verifying the wording of the standard will see true significant changes for editors of software not qualified as medical devices. I dare say that, excepted the addition of cybersecurity, there isn't any fundamental change for MDSW, compared to the version of 2015.

Scope

The 2021 version extends the scope to health software, not qualified as medical device. That was already present in the 2019 version. Here, compared to the 2015 version, the 2021 version makes significant changes for software not qualified as medical device. In this article, we focus on MDSW only.

The main consequence in changing the scope is on SOUPs. In the 2015 version, SOUP is software not made to be incorporated in a medical device. In the 2021 draft (and also 2019 draft), a note is added stating that a health software system is not a SOUP.

Thus , when a manufacturer develops a MDSW built over a health software system not qualified as a medical device, the latter is not a SOUP. Does it mean that the manufacturer shall document the health software system according to the standard? We're in a grey zone, hence the reviewer of the Regulatory Authority is usually mandated to audit the MDSW only. However, we have the FDA Guidance on Multiple Function Device Products saying something similar to the IEC 62304 draft. With a risk-based approach, the health software not qualified as a medical device (the other function in the FDA guidance) may be in some cases documented.

Exit ISO 14971

This is definitely the biggest change in this version. The clause 4.2, which strongly binds ISO 14971 and IEC 62304, has been removed and replaced by requirements on risk management. The new clause requires to have a risk management process for safety risks and security risks. ISO 14971 standard is now referenced in the annexes only.
Remark: cybersecurity risk management was already present in the previous 2019 draft.

Exit ISO 14971? Of course not! It should be a no-brainer that ISO 14971 is still required for MDSW. ISO 14971, bounces back to you by the regulatory path.

That change comes from the scope of IEC 62034 extended to health software, and aligned with the scope of IEC 82304-1. It is possible for health software to have a risk management process not compliant to ISO 14971, like ISO 31000, or ISO 27005.
Some people don't agree with these choices. Personally, I think it won't change the way IEC 62304 impacts the MDSW lifecycle and the documentation to be generated.

Software Process Rigor Level

And you're replaced by the Software process rigor level (SPRL, abbreviation by me), found in clauses 4.3 and 4.4. This is a big change of appearance, and absolutely not a change for the process of determination of the SW Safety Class. Huh, excuse me, the SPRL. The workflow found in clause 4.3 of the 2015 version is still present in the figure 3 of the 2021 version.
The clause has been revised for the sake of clarity, explaining step-by-step the process to determine de SPRL. Especially, the list of hazardous situations found in clause 4.4.2.2 is a good supplement to the list of questions found in Annex A of ISO/TR 24971:2020.
Sake of clarity, I hope this will be the case, and that newcomers will promptly understand how to determine the SPRL. Keep fingers crossed!

Some other explanations can be guessed:

• The SPRL is the result of a brainstorming with marketing specialists, to promote the IEC 62304 in a TV show and make it affordable to the general public,
• Or this is the tip of the iceberg, hiding a malignant scheme to conquer and rule the world with AI-based SaMD.

But I digress.

Other changes

Here are some other minor changes to the normative part:

• clause 5.1.9 configuration management planning, addition of bullet g) requiring to determine when the formal change control process will be used. Thus, it means that in some cases, e.g. during development, it may not be used,
• clause 5.3.3 Specify functional and performance requirements of SOUP item, addition of a clear reason for these functional and performance requirements: they're necessary for the proper integration of SOUPs into the software,
• Clause 5.8.8 was simplified to make it more modern. No more reference to replication, packaging...
• Clause 6.2.5 Communication to regulators was dropped in favor of communication to users. Anyway, regulators bounce back by regulatory requirements,
• Clause 7.1.2 Identify potential causes of contribution to hazardous situation: some additions to bullet d) failures external to the software,
• Clause 7.2.1 Define risk control measures, addition of a little but useful note, on the fact that risk control measures can include application of specific methods and activities in the software development life cycle.

Remark: the spirit of clause 7 on risk management is IMHO left untouched, compared to the 2019 version.

Conclusion

Wait and see if this draft version goes to FDIS and is approved as the official 2nd version. Then, we will be able to move on!

   unsigned int uiYear = 2016;
   bool bPublish = false;
   std::string strVersion;
   
   while (!bPublish) {
       uiYear++;
   
       //Watchdog stability date 2024
       if (uiYear > 2024)
           throw std::out_of_range(strVersion);
   
       strVersion = u8"IEC 62304:";
       strVersion += std::to_string(uiYear);
       strVersion += u8" CDV";
       getWG("IEC_SC_62A_ISO_TC_215").MakeDraftVersion(strVersion);
       bPublish = getWG("IEC_SC_62A_ISO_TC_215").IsDraftVersionAccepted(strVersion);
   }
   
   strVersion = u8"IEC 62304:";
   strVersion += std::to_string(uiYear);
   strVersion += u8" FDIS";

Post Scriptum

The 2nd version doesn’t bring any new element, while software technology evolved a lot since 2015. It would be convenient to have standards or technical reports:

• A general guidance, like IEC 62304-2, something already exists with IEC/TR 80002-3,
• Secure software lifecycle, a draft already exists, named IEC 80001-5-1 (I'll write about it soon).

And some guidance on these subjects:

• A TR on application to agile methods, we already have the AAMI TIR45. It could be internationalized, like what has been done for the AAMI TIR36 and ISO/TR 80002-2,
• A TR on application to Machine Learning based algorithms,
• A TR on application to life-critical software,
• A TR on best design practices for software alarms,
• A TR on application to cloud-based applications,
• A TR on application to mobile platforms,
• A TR on principles of architectural segregation, MDSW vs non-MDSW, SPRL C, SPRL B and SPRL A.