Coding in medtech:
setting standards for
the digital age

A

s 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 (FDA). 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.

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.

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.

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.

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.

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.

I think Covid-19 has highlighted 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.

Share this article