IEC 62304 outlines the guiding principles for the development of medical software. It is the gold standards for medical device companies, but its importance goes beyond legal manufacturers and established medical software suppliers.
In the vast majority of cases, software embedded in a device (or a device itself) use abundant OTS (Off The Shelf) code, not to mention drivers, libraries or other content available for free on the web. All of these fall under the category of SOUP – Software Of Unknown Provenance (or Pedigree). Although the use of SOUP helps significantly the job of developers, it has the opposite effect on the risk management process. A comprehensive risk analysis has to be carried out for each SOUP item, ensuring its behavior poses no threat to the device; furthermore, published bug lists may not be available at all. A big headache.
If you develop software, standalone or embedded, that is used in Medical Devices but is not a device itself, you can decide to apply IEC 62304 on your process.
Yes, it will increase the overhead, the paperwork and possibly somehow slow down the development, but IEC 62304 compliance will give you a significant competitive advantage over other developers. Although the definition of SOUP is relatively high level, most corporations consider SOUP anything that is not developed per 62304. Finding a certified product may be the make-or-break in the selection of a supplier.
Let’s give a look at the main points regarding the application of IEC 62304 to these products:
1. You do not need ISO 13485 certification, nor other type of registrations or audits.
2. Compliance to IEC 62304 is self-certified, so you don’t need a Notified Body to verify it (although en external reviewer may be still a good idea)
3. You do not need to apply 62304 in its integrity. You can disregard some processes without compromising the compliance.
So, what is the bare minimum you have to do to certify your product? (The relevant section of IEC 62304 is in the brackets)
1. A Quality System. But it does not need to be 13485 compliant. ISO 9001 may suffice. (4.1)
2. A safety classification – You will likely not know the final application of your product as it depends on the customer. You will have to develop it per the class your customer requires. The higher the class the slower the process but the higher the reward. (4.3)
3. If you are working on a pre-existing software not IEC 62304 compliant, no panic: you can use the Legacy Software process to assess it. (4.4)
4. A Development Plan (5.1)
5. High level product requirements
6. Software Requirements (5.2)
7. A Software Architecture (5.3) – Class B and C only
8. A Detail Design (5.4) – Class C only
9. Records of the implementation process (5.5) – Class B and C only
10. Records of integration and integration tests (5.6) – Class B and C only
11. Protocols and records of system tests (5.7)
12. Software release documentation (5.8)
13. A risk management file per ISO 14971 (7)
14. Proper configuration records during development but especially at release.(8)
15. A method to collect, record, evaluate and dispose of bugs, especially the ones found post-launch. (9)
16. A method to communicate existing an new bugs to your customers (9)
17. A method to create and distribute patches and fixes (6)
Consider that paragraphs 6 and 9 of IEC62304 are important if you provide post-sale maintenance and support to your customers. Instead, if your product is off-the-shelf with no support, a published bug list on your website may be enough.
