Software in Medical Devices, by MD101 Consulting

ISO 13485 is generic

Since it is made for any medical device manufacturer or repackager or even distributor, ISO 13485 is very generic. Its requirements have high-level considerations without dealing with the specific tasks of any type of medical devices (excepted a few requirements for active implantable medical devices).
Software is a peculiar industry, compared to others, with a big design phase, a tiny production phase and huge maintenance (bugs fixes and enhancements) phase. Applying ISO 13485 for software industry needs a few adjustments.

What is mandatory?

ISO 13845 states that everything it contains is mandatory, excepted chapter 7. The content of chapter 7 is optional and a company has the right to exclude some paragraphs of this chapter, with good justification based on rationale about its organization and the type of medical devices it sells.
Dealing with software is like dealing with any other type of medical device. ISO 13485 doesn't make any difference for software and all requirements from chapter 4 to 6 and chapter 8 of the standard are mandatory. So, that's simple, you have to do everything that is mandatory in ISO 13485, excepted requirements in chapter 7, with good justifications!
OK, everything is mandatory in Chapter 4 to 6 and Chapter 8. Most of what they contain is implemented the same way for any company (certainly with differences in implementation, but not in the spirit of the standard). I want however to focus on a few points which it is not straightforward to deal with.

Purchase control

The types of purchase for a pure software company are very limited: computers, peripherals, storage media, books... This is not a big problem if you buy corrupted CDROMs or crap printer cartridges, you just replace them. This is just annoying and doesn't a-priori result in any danger for a patient. But purchase control is mandatory in ISO 13485, to ensure that purchased items have the good level of quality and won't be the cause of a hazardous situation. So a software company has to control its purchases and its suppliers even if the purchased items don't have any impact on the final product.
Yet, purchase control is still helpful, especially for the paper documents shipped with the software. But purchases remain a very minor source of risks, compared to a company which buys, say, sterile items.

Working environment

The working environment of a pure software company is very simple to set-up and maintain: offices for software developers and a coffee machine to share ideas. ISO 13485 has requirements about controlling the working environment. This is adapted to companies with sterile conditions, with production lines... But this is abolutely not a big deal for software companies. Controlling the working environment is still mandatory and a software company could limit this control to the good working conditions of the software developers: good PC with good tools, good servers, processes to archive data ... It is true that a developer working on a bad/slow workstation could have an impact on the quality of the software but this is again a very minor source of risks, compared to a company which manufactures goods.

Production

ISO 13485 has a list of requirements about production. This is obviously mandatory for any company, since the quality level of products as to be controlled. This is also the case for software and production shouldn't be underestimated. A software company shall have a rigorous production process/procedures to ensure that the delivered software is the right one: software version + patches, plugins, extensions (customer tailor made or not), configuration files, input data ... All what is shipped with the software itself shall be controlled and this can result in a list of procedures, work instructions and forms. Again, production shouldn't be underestimated.

CAPA, Change control, Post Market surveillance, customer communication

Maintenance of software is an important task. A software is never finished and there are always fixes and enhancements to do. CAPA, Change control, Post Market surveillance, Customer Communication are activities required by ISO 13485, which are all "active" when the software is used and maintained. All these processes required by ISO may (and will, for sure!) result in bugs discovered in the software.
The last chapter of IEC 62304 is devoted to problems resolution (ie how to fix problems and especially software bugs). This problem resolution process/procedure of IEC 62304 should be linked to the other activities of ISO 13485 I quoted above.
When something goes wrong with the software, should it be discovered by a sales person (customer communication), by the regulatory affairs (post market surveillance), by the quality manager (CAPA), it should be "passed" to the software teams, which will treat it according to IEC 62304.

What to exclude?

Having quickly seen other chapters, back to chapter 7. You will find that it contains a few activities about cleaning, sterilizing and specific tasks for active implantable devices. There are good chances that your company excudes the following requirements if it sells pure software (no hardware):

• Cleanliness of product and contamination control: §7.5.1.2.1,
• Particular requirements for sterile medical devices: §7.5.1.3 and §7.5.2.2,
• Particular requirements for active implantable medical devices and implantable medical devices: §7.5.3.2.2 and §8.2.4.2 (not in §7 but still excluded).

Still in chapter 7, there is another possibility of excluding requirements, your company doesn't use monitoring and measuring devices (MMD) in design, production and maintenance.
A software doesn't produce physical measurements and usually the software development team doesn't use MMD to design software. There are good chances that your company excludes the following requirement:

• 7.6 Control of Monitoring and Measuring Devices

Warning; if you use measurement devices during tests phases, then you have to implement §7.6. Eg: your company sells software for post treament of ECG data. If you use libraries of archived data to do your tests, you can exclude §7.6. I you use a real ECG to do your tests, it is a MMD and you can't exclude §7.6.

Design is mandatory for software

Last word about chapter 7, but not least, design activies are in section §7.3. So they are optional!!! It is possible for multiple reasons for a lot the types of medical devices to exclude design, that's why it is there. But this is absolutely not a good solution for software medical devices. So, §7.3 of the standard about design is de-facto mandatory for software medical devices manufacturers. This is consistent with IEC 62304.
Without design procedures, it's not possible to implement the requirements of IEC 62304. So design is mandatory for software medical devices.

QMS of a pure software company

To end with a summary, here are the main characteristics of a QMS for a software company:

• "Support" activities like purchase and working environment are very limited
• Design is mandatory, consistent with IEC 62304
• Production shouldn't be neglected
• Activities when software is used and maintained like NC, CAPA, vigilence, post market, regulatory affairs, customer communication should have a link to problem resolution of IEC 62304
• Anything about sterile products and implantable products is excluded

To conclude, IEC 62304 helps defining the way things are implemented with respect to the generic requirements of ISO 13485.

Note: I did not mentioned risk management in this article, this is described in the article: how to deal with ISO 14971 in a software company.