Balancing innovation & risk: software in MedTech device design
01 February 2019
One of the biggest challenges in medical product design and development is remaining innovative and competitive against a backdrop of functional safety, risk management and regulatory compliance.
This article was originally featured in the February 2019 issue of EPDT magazine [read the digital issue]. Sign up to receive your own copy.
As Nico Krüger, Technical Sales & Professional Services Manager (ALM) at application development software specialists, Perforce Software explains, a 2018 Perforce survey confirms that many organisations are struggling to balance these sometimes competing needs. Fewer than half of the 200+ medical device professionals who responded to the survey were confident they could pass an FDA audit. Additionally, risk analysis, objective evidence, traceability, design history files and audit trails were the top challenges cited by individuals involved in reporting to the FDA, or other compliance requirements (such as IEC 62304, ISO 14971, ISO 13485 or the European Medical Device Directives).
Medical device developers also have concerns around securing software code, which has become an increasing focus given dependence on embedded software and the growth of the IoT. Vulnerabilities that creep in during software development can cause products to malfunction or pose security risks in the future. Unfortunately, security is often not native to software development processes. Instead, development teams (often siloed) focus on creating great code, while letting other teams worry about security.
Clearly, organisations need to overcome these hurdles. Many are attempting it: an increasing volume of firms are now embracing the necessary techniques, cultural practices and tools. They are demonstrating that agility and innovation can exist within a safety-conscious, compliant environment.
Automating code control
For instance, coding standards — already widespread in automotive design — can prevent, detect and eliminate errors that could otherwise compromise software security. They are especially used in C and C++, the preferred languages for embedded development. These languages are preferred because they are flexible and high-performance, but that functionality can come at the cost of increased risk.
Obviously, no one wants to slow down developers. As a result, coding standards are often managed by static code analysis tools, which automatically and continually inspect code. Any issues, such as deviation from a coding standard or a bug that would otherwise be hard to fix, get flagged quickly. The theory is that finding and dealing with problems earlier is less expensive – and has reduced impact compared to later stages. Static code analysis also supports compliance processes, encourages more consistent code quality across teams and reduces the load on testing that traditionally takes place at a later stage.
Ongoing code inspection chimes well with the trend towards continuous testing, and also ‘shift left’, whereby more testing tasks are carried out by developers, rather than only by test managers and quality assurance engineers. By automating the process, organisations overcome the limitation of developers not being test experts and minimise unnecessary workload.
This more transparent environment, with continuous processes, is also representative of how software development teams are working more closely with other parts within an organisation. For example, a huge trend in recent years has been DevOps, which is more collaboration between software development and operations teams. DevOps often coexists with Agile development. By incorporating more frequent customer feedback, Agile can bring the product closer to customer’s needs. At the same time, it breaks development down into smaller, iterative value streams. The end goal is to get the right product to market, and with less risk. While Agile development is arguably still in its infancy in risk-averse markets such as medical devices, Perforce’s survey found that 49 percent of medical device professionals said they were using either ‘pure’ Agile, or a hybrid version (for instance, Waterfall and Agile together). Hybrid Agile can provide flexibility and room for innovation.
Traceability & compliance
Demonstrating compliance was traditionally a manual process – and for many organisations, still is: over 60 percent of those surveyed reported using Microsoft Word to manage requirements and test cases, with over 50 percent using Microsoft Excel to manage and track issues. This comes at a price: 33 percent of respondents said documenting and reviewing work was their most time-consuming task.
However, many are overcoming this with a hybrid version, such as integrating application lifecycle management (ALM) tools with Microsoft Office. ALM tools ensure traceability between requirements, testing and code, to be sure that every requirement is tested and fulfilled. Using an ALM tool to generate your Office document delivers the best of both worlds: the requirements, tests and issue-tracking that development teams need, as well as compliant documentation. Importantly, traceability needs to happen at every stage of each digital asset’s life, from ideation through to delivery, maintenance and archiving – so organisations can later prove compliance, while continuously delivering.
Not surprisingly, traceability is very important across medical device development, with 85 percent using it for more than just compliance, for instance to manage change or risk, to support impact analysis or decision-making. One popular way that this is manifested is through a traceability matrix. Usually in the form of a table, this tracks the relationship
between different documents, requirements and testing. As the need for agility and traceability rise in regulated and safety-critical industries, we can expect a rising need for requirements management methods and tools that can sustain both.
Another technique is to link requirements and changes to code stored in a ‘single source of truth’. Typically based on a version control system(VCS), the benefit is that contributors have a window into what everyone else is doing and can see the impact of any actions, while allowing individuals to carry on working in their usual ways. The best VCS tools support disparate contributors across different types of file types (not just code), locations, tools and processes.
By making problems more visible and traceable, all these tools and techniques help to mitigate security risk. However, it is also good practice to lock down who has access to digital assets in the software development process. Fine-grained access control, where users are only given access to what they need to do their jobs well, reduces the risk of code becoming inadvertently or deliberately vulnerable (for instance, stolen or sold). Need-to-know access can be controlled via IP address, user and group, code repository, branch directory or at individual file level, local or across multiple sites. This is one example of how better security, risk and compliance management can be built in to the software development process, which can still be agile and fast.
While there is no easy overnight fix, medical device firms have tools available to be innovative and competitive, without compromising safety, compliance or quality.
Contact Details and Archive...