The importance of SW is growing – also in medical devices and as medical devices. This blog text deals with the change of SW’s role, the tightening regulations landscape as well as how to be agile and compliant with those regulations at the same time.
Ah, before moving on, the term Oxymoron might deserve an explanation… Oxymoron is a figure of speech containing words that seem to contradict each other – often referred to as a contradiction in terms. Examples are act naturally, the only choice and the original copy.
Changing and broadening role of SW
Medical devices are no exception in the long-lasting trend where the role of SW in devices and more recently between devices has increased drastically. This change is transforming even the business models and the competitive landscape. The importance of SW grows in several ways: (i) being a larger and larger contributor to the functionalities and features of the physical medical devices; (ii) providing reliable and secure connections and communication between devices as well as to and from the cloud; (iii) performing analytics of the data collected by the devices – either in the device itself or in the cloud. SW can also be a medical “device” itself without any physical device – in this case a term SW as Medical Device (SaMD) is quite often used.
Innokas Medical participated in the WHINN 2019 conference in Odense, Denmark. Among other inspiring topics there was a session about health-related apps (mobile applications). Did you know that there are over 300 000 “health” applications available – and that number is growing at an astonishing pace: two years ago, there were 100 000+ applications available. Every day, millions of “health” applications are being installed. There were examples of software, both in the medical devices and as “health” apps being far from safe, in fact quite the opposite. For example, one SW calculated the drug dosage for one patient to be more than the entire volume of the planet Earth – and this SW was in real use.
You might wonder why we have used quotation marks around the “health” so far. It is because under the category “health” you will find all kinds of SW for purposes ranging from e.g. tracking your mood or weight to e.g. remote patient monitoring and diagnosing for real diseases like diabetes. The fact that the SW can be downloaded from an app store does not guarantee that it is a medical SW. It is quite alarming to realize how little formalism and evidence of safety and quality is currently required from “health” applications. No one knows for sure what level of scrutiny has been applied to ensure the safety and quality of those apps that are dealing with your real health and wellness issues. Neither there are any qualifications for the SW developers who can develop medical SW, let alone “health” application.
More stringent requirements to medical SW are almost here
In May 26th, 2020, the EU’s Medical Devices Regulation (MDR) will come into full force. From the SW point of view, the biggest change is the stricter classification of SW – many SW currently in use that has not been classified as a medical device at all, or with class I at most, will fall under a medical device classification, typically class IIa. And there is no “grandfathering” of what used to be: if you want to stay in the market, you must eventually become compliant with the MDR requirements in case your SW will be classified as a medical device – that is if you haven’t been compliant before. A transition period has been granted for some current class I devices, but it is a good idea to analyse carefully the implications of the MDR for each device.
Many SW companies will soon face a new situation where they have to define and establish practices and processes that they never have had before.
Medical SW quality and safety considerations
There are many things that contribute to the quality and safety of the software that is to be used in medical devices or as a medical device. Although they do not automatically guarantee the quality (after all, agreeing on what quality means can be source of a never-ending debate), they are crucial when setting up the process framework for medical SW development to produce safe and high-quality results.
There are a few standards that give guidance and set requirements for the way medical SW shall be developed. Some of the most relevant ones are IEC 62304 Medical device software — Software life cycle processes; IEC 82304-1 Health software — Part 1: General requirements for product safety; ISO 14971 Medical devices — Application of risk management to medical devices and IEC 62366-1 Medical devices — Part 1: Application of usability engineering to medical devices. The IEC 62304 and IEC 82304-1 are likely to be harmonized.
IEC 62304 specifies life cycle requirements for the development of medical software and software within medical devices. IEC 82304-1 specifies product safety requirements for health software (SW, which is intended to be used specifically for managing, maintaining or improving health of individual persons, or the delivery of care). ISO 14971 specifies the risk management to cover SW as well – obviously. IEC 62366-1 defines a usability engineering process for medical devices from the patient safety point of view. This gives to the term “usability” quite much different and broader meaning than just “easy and intuitive to use”, which could be a guideline for many UX-designers outside of medical device domain. There is nothing wrong with that approach in a different context, where patient safety is not a concern.
SW cybersecurity aspects are also being harmonized based on ANSI/CAN/UL 2900-2-1 “Software Cybersecurity for Network-Connectable Products, Part 2-1: Particular Requirements for Network Connectable Components of Healthcare and Wellness Systems”. Consideration of SW cybersecurity aspects leads to quite extensive risk management process implications. This is a good example of how different standards are intertwined and their intent should be understood holistically.
Quite rightly, none of the standards forces a particular SW life cycle process to be followed, so agility is not at all in contradiction with developing medical SW. In fact, the incremental development and fast feedback loops enabled by continuous integration and testing help in developing safe and high-quality SW also for medical devices. For further reading, see AAMI Technical Information Report AAMI TIR45:2012 “Guidance on the use of AGILE practices in the development of medical device software”.
A company in medical SW business should understand the overall goal and intention of all relevant standards, not just the individual requirements one by one. The company should then establish and maintain a quality management system (QMS) which incorporates these requirements into a fluent (we can call it “agile” as well) SW development process which is supported by tools that ensure or, even better, enforce e.g. traceability, documentation and audit trail. Without these in place, a company’s medical SW development has a very hard time to survive the regulative scrutiny.
So is “Agile Medical SW Development” an Oxymoron or not?
There used to be a misconception that agile means “license to hack”. But in fact, agile development is very structured and disciplined way of developing new things, in this case medical SW. If one forgoes the misconception, medical SW can be developed in an agile way.
Adaptability is in the heart of agile development – there is no one single cook-book approach to do agile development in all the contexts. Values and principles are there, and they are beautiful, but their implementation should be done according to the business environment and – in the case of medical devices – the regulative framework.
By understanding the essential requirements set for medical SW development and incorporating them in the SW development process and tooling you can ensure that your company can be both agile and professional medical SW developer at the same time.
With good command of the regulatory framework and SW development teams adapting their agility accordingly – Agile Medical SW Development is NOT an Oxymoron.
A good way to ensure that your medical SW development is done in an agile way is to ensure that your co-creation partner has all the key elements in place.
*****
If you are interested to know more about the impacts of EU’s MDR on software and how to deal with them, read also our previous blog post: Are you ready for stricter rules for software as a medical device under the new MDR in EU? Tips available!
*****
This blog post was one writing in a blog post series of creating next generation medical devices in more agile way. In addition to the importance of taking SW development and SW testing into account, the whole medical device development process should follow certain rules and best practices to achieve more agile medical device development cycle. According to our studies, the commonly known three methodologies of product development - Design Thinking, Lean Start-Up and Agile methodologies - are something that can be successfully applied to the design and development of medical devices. When done properly, they reduce the time to market of the device by ensuring that right and well specified customer problem will be solved with a feasible solution, which is going to be incrementally developed.
In our free White Paper we describe in a detailed level how to get high-quality medical product to the market as quickly as possible by using these three methodologies. Please, download yours below!
