A Practical Guide To Developing Software For Medical Devices

IEC 62304 is the accepted medical device software process for both CE marking and FDA approval

IEC 62304 is less explicit in defining what is and what isn’t medical device software compared to the description in the Medical Device Regulation (MDR). However, there are always going to be grey areas, so how do you assess where the boundary lies? I would recommend looking at the full picture, making sure you are clear about your intended use and considering the risks.

In a usability test, we want to observe how users might use the product imperfectly, to determine what use errors occur because of our design; in a clinical evaluation, we want to remove the chance of use error occurring, to determine the clinical effectiveness of the product when used perfectly. Variation is deliberately tested by observation and assessment is more subjective in usability studies, whereas variation is deliberately minimised or controlled in clinical evaluations and the aim is to produce objective evidence.

As an example, if you’re running some medical device software on Windows, does the associated PC become a medical device? Well, it depends… if you’re using a PC in a doctor’s office to run your software and show a live feed from a USB imaging device and you meet any other applicable requirements (for example electrical safety), it might be reasonable to assume that you don’t need to validate the whole operating system.

While we have all experienced Windows crashing, it’s also being ‘tested’ globally on a daily basis far more rigorously than your company can reasonably achieve. So, given the ‘intended use’, if the risk of a video dropout is simply having to wait a few minutes while the PC reboots then you might make the overall assessment that the risk is acceptably low. However, if you’re using Windows as the underlying operating system to run a ventilator keeping someone alive, you’d want to be pretty sure that it isn’t going to go off and install windows updates and reboot while you’re not looking.

This risk aspect is key, and throughout IEC 63204 you will see reference to risk management with specific mention of ISO 14971.

Standards

The use of harmonized standards gives a presumption of conformity with the essential requirements of the regulation. Theoretically, you don’t have to follow IEC 62304 but you do have to meet the essential requirements, and would have to justify any alternative route.

It is worth noting that ‘state of the art’ does not necessarily imply the most technologically advanced solution; it simply embodies what is currently and generally accepted as good practice in technology and medicine.

Software development for medical devices is intimately linked with overall quality management

At its heart, IEC 62304 tells you what processes you need to implement and what activities are necessary for the safe design and maintenance of medical device software. This is similar to the way a quality management system is described in ISO 13485; which is essentially how 62304 has been designed to work. It should be integrated as part of your quality management system to make sure that your processes meet the particular challenges of software development, test and maintenance. But, how is compliance to IEC 63204 assessed? In the same way as risk management or electrical safety; you apply the principles as part of your product development process and demonstrate them in your technical file.

Adopt a risk-based approach for the whole device including the software

One of the biggest strengths of the standard is that you can adopt a pragmatic development approach appropriate to the product in question. So, modern life-cycle methodologies like Agile can be incorporated into your processes. Agile can be adapted to the unique needs of medical device software, bringing value, and establishes robust change management systems to manage development uncertainty and mitigate risks associated with rapid change. Agile tools and practices specifically address the software development life-cycle and therefore can be easily aligned with the requirements of IEC 62304 (AAMI TIR45:2012 Technical Information Report Guidance on the use of AGILE practices in the development of medical device software).

Software safety classification – be pragmatic, don’t overdo/underdo it

Having decided that you’re developing a medical device, it’s important to first work out the device classification and then to consider the software safety classification, in light of this. While the two aren’t directly linked, the device classification and high-level risks within the system will help direct you to the most appropriate software safety class.

I believe it’s important to think about software hazards in a time-bound way and then look at the outcome of these risks over time. If a ventilator fails due to a software issue, the implications are obvious and immediate. However, if the software fails on a dermatology camera, what are the implications? Is the software system the only method of diagnosis? Does the software ‘diagnose’ or provide an aid to the clinician making an assessment? How immediate is the risk if the patient has to wait 30 minutes or come back another day? You need to be honest in your assessment of risk, don’t hide anything but also remember, you aren’t required to mitigate implausible risks.

Document your decisions

As the safety concerns in the software increase, so does the level of rigour which you need to apply to the software development. There is nothing stopping you applying more than is required and it might make sense to err on the side of caution. From experience I would particularly caution against trying to justify (get away with) Software Safety Class A for anything but the very simplest, lowest risk software components. But, if you’re confident, be sure to document your rationale, so you have something to point at, if questioned by an auditor.

Follow good software design principles

This really doesn’t need to be as daunting as it sounds. In general, the software system takes on the same risk category as the riskiest subsection or software ‘item’ inside that system. Fortunately, the standard gives some room for manoeuvre on this, provided you can make a reasoned argument for the approach that you have taken (BS EN 62304:2006+A1:2015, 4.3 Software Safety Classification) again, be sure to document your rationale!

Software Segregation

The first thing we consider in a project is whether the risks arising from the software can be mitigated in hardware. This is a good approach if you have fixed, easily measurable parameters where electronic ‘cut-out’ type functions can ensure the worst risks are mitigated. Another way to think about this is if software can only control the system within a safe range with hardware providing the functional limits. Within the safe range you might still have risks associated with sub-optimal treatment or risks with lower levels of harm but the worst have been taken care of possibly allowing you to reduce the safety classification.

Unfortunately, in some systems the determination of an error could require more complex measurement or there may be too many scenarios which need to be covered. Hardware mitigation is a valuable tool but don’t be too afraid to look for software solutions. This could include:

Ensure you plan your maintenance and upgrade strategy

A unique property of software is the ease of introducing safety issues through upgrades after the product is placed on the market. As the developer you need to factor in the time and cost of fixing software bugs, even if changes to the code required to fix the bug are large, expensive, or delay finishing the project. Once out in the field, you also need to start considering usability issues and if users may in fact be relying on the undocumented ‘buggy’ behaviour.  If a user has adapted their way of working to cater for the bug, fixing it could actually cause operational issues.

Regulatory bodies are as concerned, if not more so, about the on-going maintenance and support of software following product release. Maintaining software in the field introduces new commercial and safety challenges which don’t typically occur during the initial development. There may be different software versions in the field, or it may need to run on multiple hardware configurations. So, you need to keep a handle on the distribution of your software; particularly if selling software and on-going support is a core part of your business.

To see an example of how we incorporate software development and algorithms into our product design programmes, please click here and view our Camcon Medical Limited case study.