IEC 60601 is an important series of technical standards that aim to guarantee that medical electrical equipment is safe and effective. As such, this piece of regulation is of key importance to developers of medical technology. But does it apply to your organization, and if so, what implications does it have?
Picture this: you’re in a hospital emergency room, observing a patient in critical condition. They are lying unconscious and immobile in bed and have been connected to various electrical devices that are helping stabilize them so they can recover. A team of doctors and nurses are working in tandem with these appliances in order to save this patient’s life as well as many others – and trust that the technology at their disposal will help them get the job done.
Just to give you an idea of what’s at stake, in this scenario, or during invasive treatment when the skin of the body no longer provides a base layer of insulation against electrical currents, even a small electrical current gone astray can cause a person’s heart to fibrillate or paralyse the respiratory system. Not to mention that where there is mains-powered electrical equipment, there is also the risk of fire, which in certain environments can even cause explosions. The threats posed by electrical appliances in medical treatment and patient care can be severe, which is why the design of these appliances needs to be thoroughly regulated in order to get it right.
That’s where the IEC 60601 comes in.
Medtech software developers, meet IEC 60601
The IEC 60601 is a series of technical standards designed to ensure the safety and effectiveness of medical electrical equipment. This includes any type of medical electrical device, ranging from something as small as an endoscopic camera to something as large-scale as MRI or gamma imaging systems. It is the cornerstone guide to electrical medical device development which addresses all the risks that come along with the process – including those related to software failure. While compliance with the IEC 60601 can be quite a task (Edition 3.1 comes with 1500 single specific requirements alone) the purpose of these safety standards is pretty simple: to make sure that no electrical, mechanical, or functional failure poses an unacceptable risk to patients and operators of these devices.
That being said, there’s another key reason businesses need to design medical devices with compliance in mind. The IEC 60601-1 (Edition 3.1) is the widely accepted and required standard for electrical medical devices sold in the EU, U.S., Canada, Japan, Brazil, Russia, and Australia. These countries have been enforcing implementation of this standard since January 2014, so if you are planning to enter any of these and other markets as a developer and manufacturer of electrical medical devices, you need to make sure that your product is compliant.
We won’t beat around the bush. IEC 60601 documentation is long, and at times, hard to digest. But getting a handle on the standards and designing your product software with them in mind can help you save time, money, and with the successful manufacturing and marketing of your product – human lives. Let’s dive into the details of the standard and the implications it has for medical technology developers throughout the process of getting software certified.
IEC 60601 – Medical electrical equipment: Let’s take a closer look
The IEC 60601 was originally published by the International Electrotechnical Commission in 1977. It has been updated several times since then to keep up with the evolution of technology and our understanding of safety requirements, with the most recent version, the IEC 60601-1-2 4th edition published in 2014.
Each section of the standard addresses a different quality control aspect of medical device development. This includes for example, the general requirements for risk management, testing, classification and marking, protection against different hazards, construction, EMC and more. For anyone developing software for medical devices, the most relevant part of IEC 60601 will be Section 14, which is dedicated to ‘PEMS’, or Programmable Electrical Medical Systems. This part of the standard covers the safety regulations of devices containing hardware or software and is designed to address the unique challenges for this field.
One of these is the design and execution of appropriate tests for these systems, which is one of the primary reasons PEMS features a significant focus on risk management and the development lifecycle, as well as validation and verification activities. It also provides regulatory guidelines about hardware and software interfaces, especially network interfaces, which are increasingly a security concern with the amount of cyber-attacks resulting in the theft of patient data and the disruption of medical services on the rise.
On a side note, you’ve probably already noticed that PEMS overlaps significantly with IEC 62304, which regulates medical device software and software life cycle processes specifically. It is probable that businesses developing software for electrical medical devices will need to comply with both.
If you’re still not sure if Section 14 of the IEC 60601 applies to the work you do, consider this: if the software included in your device provides basic safety support, or failure of the software leads to a form of unacceptable risk as defined by the general standard of the document, then the software performance and efficiency must be designed, tested and evaluated according to the requirements of this regulation.
Brace yourselves… compliance is coming
Most developers make the same mistake when it comes to IEC 60601: they treat it as an afterthought, rather than plan and design with it in advance (not unlike some of our favourite protagonists in TV shows refusing to face their demons head on). The complexity of the standard means that just testing can easily take 6-12 weeks to comply with the basic standards, and not being prepared for this process means going back to the drawing board over and over, not to mention losing time and money.
It is crucial that software errors like bugs and usability problems are avoided right from the start. For this reason, the IEC 60601 obliges manufacturers of programmable electrical medical systems (PEMS) to follow a life cycle process.
Said process can vary a little bit depending on the applied methodology, but generally all approaches include typical project management like identifying the business case and stakeholder needs, as well as the specification and review of software requirements, establishing coding best practices, code verification, integration tests, software tests, and system validation, amongst others. Developers need to plan, document, and verify what they do with meticulous precision to demonstrate that these activities have been performed up to standard.
To make this process less of a headache, developers could adopt a risk-based approach from the start – supported by an Agile methodology, if applicable. Since TIR 45 (Guidance on the use of AGILE practices in the development of medical device software) was published, we know Agile is an accepted way of developing medical technology. Agile tools and practices address specific stages of the development lifecycle and therefore can more easily align with the requirements of the standard. Working with a dedicated platform for Requirements, Risk and Test Management like Intland Retina is one way to streamline these activities and make sure nothing is left out.
Meanwhile, you also need to be crystal clear on the essential clinical function and category of the device you are developing, to better define what class of software you’re creating for it. Understanding the high-level risks within the system of the device will help you assess the most plausible risks for software hazards for the type of device. Then developers need to consider what the risks of the software failing are, and if they can be mitigated with hardware. If you have easily measurable parameters where an electronic ‘cut-out’ can prevent the worst-case scenario from coming to pass, then this is a solid approach.
Finally, you’ll want to plan ahead for maintenance and upgrades. These machines typically represent a large investment for healthcare institutions who will want to use them for a long time. As a developer, you’ll need to factor in the time and cost of fixing bugs and the upgrades that will be needed periodically.
The big picture
The IEC 60601 is complex and at times can be frustrating but ensuring that your product is safe for patients and operators (and that you can go to market seamlessly) makes it all worth it. In the end, it simply comes down to a ‘designing proactively for compliance’ mindset. And rigorous preparation! Using Intland Retina can cut the costs of compliance significantly – which is why global MedTech leaders like Medtronic, Roche Diagnostics, or Zimmer Biomet are using it.
For medical Quality Assurance specialists, Intland also offers a Medical Audit & CAPA Template, supporting MedTech developers in controlling quality documents, simplifying compliance assessments, and accelerating audits.