Innovations in medical robotics and healthtech

Jill Britton and Steve Howard, Perforce Software, further explore.

This article originally appeared in the April'23 magazine issue of Electronic Specifier Design – see ES's Magazine Archives for more featured publications.

For example, a company in the Middle East is developing a system whereby a surgeon can remotely guide a microscopic robotic arm for spinal surgery, supported by augmented reality images of the patient both pre- and interoperation.

Intelligent medication dispensers are already widely available, allowing medical professionals to track intake and be alerted if a dose has been missed. One day that medicine may be administered to patients by robots, as even now there are robot assistants which can schedule reminders and check-ins.

Remote patient monitoring (RPM) systems already use sensors to deliver real-time data, for instance, covering heartbeats, glucose levels, and blood pressure. Innovations such as these have the power to transform healthcare with the ability to react more efficiently and faster to patient needs.

Hospitals are beginning to use smart beds, which can monitor a patient’s condition and adjust the bed to the proper position for the patient. This frees up precious nursing time from routine tasks and reduces the risk of injuries caused by moving patients. Hospital robots are also being used to sanitise rooms and areas, reducing the risk of hospital staff coming into contact with any potential pathogens.

Furthermore, on a personal level, people worldwide benefit from health-related features built into smartwatches, such as raising an alert when the wearer appears to have taken a tumble. 

These developments and many more have the potential to improve patient health, support medical and care professionals more effectively, reduce costs, improve efficiency, and enable healthcare on a larger, often remote, scale.

Of course, all this represents some exciting business opportunities for the electronics industry. For example, in December 2022, Data Bridge Market Research estimated that the IoMT market worldwide would rocket to $270.4 billion by 2029 (up from $48.69 billion in 2021).

Code concerns

However, all these innovations depend on software, so the safety and security of code must be a priority. Traditionally, security has not been a top priority for software development teams in the medical industry – as systems were traditionally ‘stand-alone’ – but, with the growth of IoMT and ‘connected’ medical devices, this has had to change.

Without security, risks to patients and users could be catastrophic, ranging from an attacker remotely accessing personal and private medical data, to taking control of a healthcare aid or medication dispenser, and ultimately then to the loss of human life. Any risks that are not addressed could lead to future vulnerabilities leading to malfunction, data breaches, or cyberattacks.

Most medical device security vulnerabilities stem from the software development stage, so security at this stage needs to be the frontline. Industry regulation is also an important driver for both software safety and security. Regulation not only ensures that software is compliant to the standards deemed appropriate, but that this compliance can be demonstrated.  

Both the US Food and Drug Administration (FDA)’s Software Contained in Medical Devices and Europe’s Medical Device Regulations (MDR) are either in the process of – or have published – recent updates to their requirements for software to address the security risks being posed. In both cases, the regulations are stricter than the previous versions, particularly for ‘invasive’ devices. 

This includes following software development lifecycle processes from design, to coding, through to unit test and verification. IEC 62304 specifies a set of processes, activities, and tasks for the design and test of safe medical device software. FDA suggests conformity to IEC 62304 as part of its requirements and, following these same processes, is recommended for MDR (although a certification is not currently required).

As well as considering safety in the software development lifecycle, security must also be considered at every stage, engendering a ‘security-first’ mindset. This helps to build a culture of security throughout the team and helps ensure that security is considered to be everyone’s responsibility. Organisations that overlook this run the risk of developers bypassing security measures, particularly when under pressure to get software into production rapidly.

Coding standards

One practical way to improve the safety and security robustness of code and support compliance to regulatory requirements is through the use of coding standards. The use of coding standards is already mandatory in some cases. For instance, section B.5.5. of IEC 62304 (Software Unit implementation and verification) specifies the use of a coding standard for style, understandability, language usage rules or restrictions, and complexity management.

Coding standards help to address some of the challenges introduced by the growing complexity and connectedness of healthcare devices and software.  This is especially the case for the widely used C and C++ programming languages, which are more ‘open’ than others, requiring more interpretation and hence leave room for error.

For instance, in C and C++, dynamic memory allocation is a well-known area where flaws can inadvertently be built-in to the code. As identified by The Open Web Application Security Project (OWASP), ‘An attacker can intentionally trigger a memory leak and might be able to launch a denial-of-service attack (by crashing or hanging the program) or take advantage of other unexpected program behaviour resulting from a low memory condition.’

Coding standards are simply sets of rules or guidelines to help software developers when writing code and bring together collective industry knowledge from multiple sources. The aim is to reduce the number of bugs and vulnerabilities while, at the same time, ensuring consistent quality of code.

Example coding standards

While organisations can (and often do) create their own coding standards, it is more common to apply recognised ones such as MISRA C/C++, initially developed for the automotive industry but now used in other safety-critical markets; and CERT, developed by the Software Engineering Institute at Carnegie Mellon University.

Many organisations will use a combination of coding standards, often to cover different programming languages being used, and sometimes augmented by in-house coding standards to create uniformity of naming conventions and layout guidelines.

To detect security vulnerabilities, organisations can also frequently review the weaknesses as listed in the Common Weakness Enumeration (CWE) – especially the ‘Top 25’ most commonly seen vulnerabilities occurring in each year – (championed by the National Institute of Standards and Technology (NIST)) or the OWASP Top 10, updated every four years.

Static analysis

Applying coding standards can require quite some effort and time, so they are usually checked or enforced using static analysis tools. In fact, both the FDA and the International Medical Device Regulators Forum (IMDFR) have published content encouraging the use of static analysis. Static analysis tools inspect and analyse source code, byte code, and binaries in a non-running state (potentially even before it has been compiled) to unearth coding defects and vulnerabilities as early as possible. As a result, the potential extra workload of enforcing coding standards on developers is reduced while giving them the confidence that they are writing safe, secure, and high-quality code.

All these approaches will help maximise software's safety and security so that medical engineering organisations can focus on developing and delivering their life-enhancing or even life-saving innovations. The world is on the brink of many medical advancements, and software has an enormous and positive contribution to make if managed correctly.