As technology advances, expectations of medical devices’ capabilities are dramatically rising. Where devices were once closed systems designed to facilitate a single task, today’s medical technologies are increasingly making use of software and connectivity to do much more. Data collection and sharing, remote monitoring and the application of artificial intelligence and machine learning are opening new doors to more predictive models of healthcare, as well as automating tasks that previously would have been done manually by clinicians.
These advanced functions are controlled by increasingly sophisticated embedded software, and while the clinical and economic benefits are clear, there is now a greater need than ever for the highest standards in coding and software design in medtech. Some high-tech industries have blazed a trail for early implementation of coding standards, such as the automotive sector’s adoption of the MISRA software guidelines developed by the Motor Industry Software Reliability Association (MISRA).
The medtech sector has been significantly slower to adopt consistent coding standards. In Perforce Software’s 2019 State of Medical Device Development survey, 70% of responding medical device developers reported that they either weren’t using coding standards, or were unsure about whether they were being used.
There is currently no catch-all set of coding requirements for medical devices, either from international standards organisations or from key medical regulators such as the European Medicines Agency and the US Food and Drug Administration. Regulators require device developers to properly validate their technologies’ safety and cybersecurity, but other than piecemeal guidance documents there is little detail on how device safety and security should be achieved.
Creo Medical’s software development director James Thomas, who has more than three decades of experience in software industries, has championed the growing use of coding standards in the medtech field. Creo was founded in the UK in 2003, and develops electrosurgical devices primarily for colon surgeries, as well as its proprietary CROMA energy platform, which provides radiofrequency and microwave energy for the devices. The company is currently expanding its engineering team, including software engineers, as it works on the next generation of its devices.
Here, Thomas discusses the reasons for the lag in coding standards in medtech, the benefits that consistent coding standards can bring to the sector, and Creo’s own plans for improving its software development process in the coming years.
Chris Lo: Could you give some background on your role at Creo Medical?
James Thomas: I’m the software development director at Creo Medical. It’s a small team at the moment, but we are looking to expand significantly. Our initial product, the CROMA Advanced Energy Platform, connects with our surgical instrument, Speedboat Inject, for conducting minimally-invasive GI surgery. We’ve just announced another five instruments expanding the surgical procedures we can support. All instruments have gained CE Mark, and two of them have received FDA approval as well. We’re moving to get the others through FDA approval.
But we’re also working on other medical devices, and a second-generation energy platform which will be quite transformational. That development will need a much larger team – not just embedded software engineers, but data analysts/scientists, test engineers and so on. We are ramping up recruitment right now.
The CROMA platform generates RF [radiofrequency] and microwave energy for our instruments. All that power generation is under software control so the software is safety-critical. It’s Class C, the highest level of safety-critical software. It’s all written in [programming language] C and fully embedded – there’s a user interface with an integrated screen, fascia buttons, LEDs, sound and control pedals but it’s a standalone medical device not connected to other systems or the internet. For our next generation platform, connectivity will be important.
CL: Could you explain exactly what coding standards are, and how they can benefit med tech organisations?
JT: Really the key things with coding standards are, first of all, to provide a level of consistency and uniformity in the style in which code is laid out. It’s having a project-wide or company-wide standard, so if another programmer has to pick up someone else’s code or understand it, it makes it a lot easier because they’ll be familiar with the layout and style.
Allied to that, naming conventions are an important part of coding standards. If you’ve got a common naming convention rather than programmers making up their conventions, then that also aids code readability.
A third aspect of coding standards is minimising complexity. There are various metrics such as lines of code – if a function or a unit has 300 lines of code, that’s going to take quite an effort to understand, so a coding standard could place a limit on lines of code which, if exceeded, would need approval. There are many more metrics including McCabe’s cyclomatic complexity measure, level of nesting and object-oriented metrics. They are just a means of giving you measures to indicate the complexity of a piece of code.
There is a fourth aspect, which is avoiding constructs that make the code difficult to read. The early one that everybody used to talk about was GoTo statements. If you have GoTos in code, it means jumping from one line in the code to another line somewhere else. If there is jumping back and forward, it can become really difficult to understand what’s going on. That’s a simple example – there are many more code constructs engineers should avoid to minimise the scope for inadvertently introducing software errors.
CL: How have coding standards evolved?
JT: In the late 90s, along came MISRA from the motor industry. That was the first attempt to lay out a list of rules that highlights certain constructs that are unsafe, with the aim of making code more reliable and eliminating obvious errors. Along with that, tools were developed that would analyse source code – so you’re not executing tests; the source code is parsed by a static analysis tool, which will tell you, for those rule checks that can be automated, which rules have been potentially violated.
I always tell people that MISRA isn’t enough in itself – it’s a set of rules to minimise the opportunity for using unsafe code constructs – it doesn’t cover your layout and your style, it doesn’t cover naming conventions. A coding standard is more than just MISRA but if you’re in a safety-critical environment, why wouldn’t you follow MISRA?
Now, connection of medical devices to the web is becoming increasingly common, and people in the embedded and safety-critical sectors are increasingly aware of the need to address security as well as safety. There are relevant standards for security such as CERT and security has been addressed by AUTOSAR and MISRA.
CL: Why do you think medtech lags behind many other safety-critical industries in using coding standards?
JT: I think it may be because of where medical technology companies come from. Many of them tend to have started as small start-ups looking to do some very interesting work, maybe spin-offs from universities. In avionics or rail, larger organisations dominate with larger engineering teams and budgets, and therefore they need standards and can afford to use more expensive tools. When you have a small team you can get away without coding standards. If you have a team of 30-50 people for example, then coding standards become essential because engineers will move around, amend and extend other people’s code.
And possibly there’s not enough collaboration with other safety-critical sectors. MISRA came from the automotive sector but avionics software engineers will be aware of MISRA. Not all software engineers in the medical sector are aware of it though. It may be that it’s just a matter of time, and to be fair, standards have come more recently to medical, and it takes time to really understand why you’d need coding standards.
CL: Do you think it’s likely that medical regulators will tighten up coding requirements for device developers?
JT: It might change so that coding requirements become a little bit more explicit. If you look at [medical device software standard] IEC 62304, it suggests coding standards. But it doesn’t say much more than that, and I think the FDA guidance is pretty similar – there’s an expectation that you should have them; it’s not mandatory, and there’s no detail on what they should cover.
As I mentioned, we’ve been putting devices through FDA approval recently and we’ve found that the FDA is increasingly asking questions about security – have you done a security assessment, what’s your cybersecurity approach? It’s noticeable that they are asking those questions, but the standard is not saying very much about security – it does not mention a threat model, security controls and other things that are part of the typical approach to security in other industry sectors, so the standard is lagging a little behind.
Summing up, I would expect to probably see medical regulators tighten up coding requirements little bit more; I’m not sure they’ll ever go so far as mandating that you must conform to MISRA or CERT or whatever but I’d expect that coding standards will in future be more than a recommendation.
CL: Creo Medical is currently hiring in its software engineering team – can you talk about Creo’s approach to coding, and the expectations you have for new staff?
JT: At the moment we follow MISRA, so every time we make changes to the code we’ll do a full MISRA check. We have coding standards as you’d expect, in terms of layout, style and naming conventions. We’re moving to [static analysis tool] QAC; this will allow us to be more efficient in terms of checking for and managing MISRA compliance. QAC will be more integrated into our development process – developers, as they’re writing code, will be warned if they’re violating a MISRA rule so they get immediate feedback, and we will be able to easily manage any exceptions to MISRA compliance centrally.
For the development of the next-generation CROMA platform, we’ll be taking a lot of design ideas from the initial platform but it will be a brand-new development. Our coding standards will be even more comprehensive, and applied from the start of the development. We’ll be checking for compliance with MISRA and CERT rules from day one.
CL: Do you think the Covid-19 crisis has put the medical device industry on the radar of talented young coders, or that recent graduates are more attracted to the medical technology field than they were before?
JT: I think Covid-19 has highlighed the need for medical technology – companies like Dyson developing new ventilators were in the news and there was the infamous test-and-trace app for example. When people do join a medical device company, [there’s a] sense of worth they get from helping to develop a device that is being used to save lives, reduce the risk of major surgery or improve the lives of people in some way. It’s quite rewarding for many people; there are many other software industries where engineers don’t get that aspect of job satisfaction.
Looking at our products, the CROMA platform and Speedboard Inject device is used to treat growths and lesions in the GI tract, and it’s out there being used now. Our engineers see operations being carried out by the surgeons minimally-invasively with just local anaesthetic and in a few hours the patient is leaving the hospital rather than having undergone a full operation. When you see that and you’ve been working on it, you think, ‘That’s amazing!’.
I think young people are attracted by industries that are making a positive difference in the world today, and certainly the medical device industry falls into that category. I really do hope we see more talented software engineers aware of, and attracted by, the medical technology field now.