Excellence in Software Engineering
On The Road to Medical Device Software Development
06 March 2019

Author: Nihal SARMAŞIK, Group Manager (Health & Transportation)

Today, medical device technology is growing fast for enhanced patient care and therapies. Wide variety of medical devices and systems have been developed over decades.  These devices are indispensable part of diagnostics and treatment of diseases and they’re still evolving to enhance their functionality. Guided surgical tools, CAD’s, CT’s, MRI’s, X-Ray and fluoroscopy imaging systems, surgical robotics are examples of such devices. These consist of high technology and complex components.  That sort of complexity requires more software-oriented solutions; and thus, software becomes a vital part of the systems.

Beside their complexity, these systems are safety-critical. That means any kind of failure or malfunction may result in serious injury or even death. For this particular reason, faults in these systems are main elements to be avoided for achieving an acceptable risk level. On the other hand, trends in healthcare show a path towards home-care and personalized usage of medical devices; meaning the usage extends to non-clinical environments. This alone increases the importance of safety and reliability. To cope with these challenges rigid set of rules must be applied, as shown in Figure-1. These rules are regulated by MDR 2017/745 (Medical Device Regulations) in Europe.

MDR lays down rules to ensure high standards of quality and safety for medical devices. This makes sure that a high level of protection is maintained for the health and safety of patients and users. MDR defines classification rules to identify a severity level for a medical device. Severity level depends on the harm on a patient in case of a device malfunction. MDR demands systematically defined and applied risk management process that works hand-in-hand with other disciplines. Being in the core of regulation and standards ecosystem, IEC 14971 precisely defines the application of risk management to medical devices. Risk management process plays an important role to identify safety class of the related software and its components.  In addition to that, based on this safety class, the level of deliverables required for a certification is determined with the standard IEC 62304. This is a harmonized standard within EU (European Union) and it is also recognized by the FDA (Food and Drug Administration). IEC 62304 defines software life-cycle process for medical devices.

Usability engineering is another main concern for risk assessment. The standard of IEC 62366 defines a process to analyze, specify, develop and evaluate the usability of a medical device as it relates to safety. This process permits to assess and mitigate the risks associated with the “correct use” and “use errors”.

Figure-1: Relationship between medical device standards

 

All the standards above declare the requirements in a generic way to cover a wide range of medical devices and their software. For this reason, good understanding of these standards with a deep experience is essential to develop norm-compliant complex systems. In order to pass legitimate audits, one needs dedicated resources and time upon development.

Aside from all, time-to-market is a critical commercial issue. This puts great pressure on development teams. Even though the medical device development is highly regulated by industry standards, changes in the requirement set are quite often.  Therefore, quick adaption to such changes is critical. Delivering solutions on time under high rate of requirement changes while ensuring safety is a great challenge. To overcome this challenge, new development approaches should be thought. The “V-Model”, widely used in avionics, automotive and healthcare domains, is an essential part of complex and safety-critical system development. To keep pace with this challenge, V-Model can also be leveraged by adapting agile paradigm while keeping safety in focus. A special hybrid process may be used where “V-model” is blended with the iterative and incremental methods, as shown in Figure-2. The main idea behind this mixture is to reevaluate design issues with respect to safety and reliability concerns at the end of each coding cycle.

Figure-2: Hybrid V-Model

Marketing a medical device is subject to certification. As shown in Figure-3, certification requires that one provides acceptable proof to the authorities to show system requirements have been satisfied. To provide evidence systematically, all process artifacts and their dependencies should be linked. This can be done using bi-directional traceability. Traceability provides a systematic method to present acceptable proof to the authorities. There are various kinds of links between process artifacts and their dependencies. To handle this variety and to present this bi-directional traceability in a systematic manner, one requires a solid set of integrated tools chain.

Figure-3: Bi-directional Traceability – Acceptable proof for certification

To summarize, software development for medical devices requires solid understanding of regulations and standards. Changing market dynamics, new challenges and technology should be considered at every stage of development. Before hitting this road, software development tools and techniques should be evaluated carefully, and processes must be established concisely.

References:

  • EU 2017/745 Medical Device Regulations, the European Parliament and the Council of the European Union, 2017
  • ISO 14971:2012 Medical Devices — Application of risk management to medical devices, The British Standards Institution, 2012
  • BS EN 62304:2006 Medical Device Software — Software life-cycle processes, The British Standards Institution, 2008
  • BS EN 62366-1:2015 Medical Devices Part 1: Application of usability engineering to medical devices, The British Standards Institution, 2015

Past Articles

Secure Coding

Secure Coding

It is hard to withstand ever-expanding attacks with old coding habits. Many attacks on corporate applications come from inside the network, thus rendering such protection mechanisms as firewalls useless. It has become imperative that the application is capable of protecting itself. All security issues are rooted in the code itself. The starting point of the secure coding concept is based on the idea of avoiding security errors in the first place instead of fixing them. So, what should be done to gain secure coding skills?

Why Built-Operate-Transfer (BOT)?

Why Built-Operate-Transfer (BOT)?

“ In the last months we have received some BOT demands from some large enterprises especially from Europe and we had several negotiations with them. Below we want to share with our followers our impressions regarding the concerns, feelings and the alternative searches of any CEO of any enterprise in case of expanding their production into other countries.”

Common Criteria provides a wealth of information about IT security

Common Criteria provides a wealth of information about IT security

Setting up a multilingual full functional support team in a short timeframe is not easy. It requires well-planned transition and efficient team selection process. There are more incompetent support advocates compared to excellent ones and also transition process planning requires unique experience and has lots of technical and business risks to overcome.

Navigation