In recent years we’ve seen widespread adoption of innovative devices and techniques. Examples include implantable drug delivery systems for accurate, highly localised treatment of a wide array of ophthalmic pathologies such as vitreous inflammation. Intraocular sensors are used to monitor increases in fluid pressure that could signal the onset of glaucoma. Electroactive intraocular lenses that are responsive to electrical stimuli that could be implanted inside the eyeball to replace or supplement a natural crystalline lens when treating cataracts, myopia or presbyopia are under development. And minimally invasive glaucoma surgery (MIGS) devices have become more and more commonplace.

Making implants smart means creating a connected device capable of recording and transmitting information. It follows that such a device, with electronics, software, wireless data transmission and associated mobile application, will need to comply with many more requirements from regulators. That will be complicated further by the differences between regulations in different parts of the world.

In our recent report “Towards 2040 – A vision for the future of ophthalmology” we highlighted the imperative of cross-industry collaboration to speed up innovation to address the largest challenges that ophthalmology faces today. In the regulatory space, we are starting to see steps in the right direction, for example regulatory bodies like the FDA in the US are implementing more open systems fostering an open dialogue with innovators.

This article should help you to be better prepared for these conversations with regulators. The article describes the processes and logic behind the requirements from regulators, particularly if you are developing new smart implants, but also helpful for any other complex systems that comprise electronics, software, hardware, artificial intelligence (AI) and wireless data comms.

As a start-up, you will need to implement a Quality Management System (QMS) and associated processes to drive the development of your product, commercialise it, and monitor it once it is on the market. As a developer, you might be a smart device expert eyeing the medical space or a medical device specialist with ambitions in the smart arena. Either way, you’ll need to revise and potentially update your QMS and associated processes to ensure regulatory compliance.

Whatever the starting point, systems and processes will need to enable the transition from a purely mechanical device with no added elements (top) to a larger system with added complexities (bottom).

Similar yet different regulations

In the United States, medical devices are regulated by the Food and Drug Administration (FDA), according to the Code of Federal Regulations (CFR), while in Europe that relationship is mirrored by the European Commission and the Medical Device Regulation (MDR).

When it comes to marketing a device in either domain, the steps appear similar on the surface. But differences exist in the implementation of those steps. For example, radio emitting devices need to comply with requirements from the Federal Communications Commission in the US, and with the Radio Equipment Directive in the EU.

QMS to define and drive process

Development of the overall smart implant system and its additional sub-systems will need to follow a QMS capable of handling not just hardware but also software and electronics. A suitable QMS will follow the requirements from FDA’s Quality System Regulation (QSR) at 21 CFR 820 and ISO 13485 and provide enough flexibility to allow for simple or complex products to be realised. The QMS will define and drive the development process and its implementation.

Product realisation and technical documentation

Systems engineering techniques should be employed to ensure all components of the smart device and their relationships are covered:

Software. The smart implant will need a software component to allow it to record and transmit information. Regulators expect developers of software medical devices to follow a QMS with development needs that are well defined based on the IEC 62304 standard for Medical Device Software. Development needs include plans and requirements for configuration management, source control, development and build environments, use of off-the-shelf (OTS) and software of unknown provenance (SOUP), release procedures and registers, as well as cybersecurity and data protection as applicable.

Electronics, data transmission and storage. The smart implant will also need an electronics component to allow it to record and transmit information. Wireless transmission of data to a storage space must be through the human body, so the implant will have to comply with requirements as defined by the IEC 60601 series of standards for electronics as well as those for radio emitting devices.

Data storage could be in a physical device or in the cloud. Again, different requirements apply to the different systems. Data processing and display, whether with a mobile device or a computer, will include a secondary software element to it which, depending on its intended use, may also be classed as a software medical device.

Use of the processed data. The clinician using the data visualisation tool also needs to be considered during the design and development of the overall system. Usability / Human Factors Engineering (HFE) activities as defined by IEC 62366 will need to be carried out to help with the development of the tool, to ensure that the clinician is able to use it correctly and safely.

What next for smart active implants?

We are on the cusp of further transformative breakthroughs in smart implants. Surgery could be enhanced by using robots to assist or replace the surgeon. AI could be used to aid in the interpretation of the information received to enable diagnosis without the need for a human clinician.

This could then allow diagnostics and follow-on appointments to be carried out remotely rather than in person. When it comes to developing AI and machine learning (ML) systems, consideration needs to be given to whether the system is ‘locked’ or ‘adaptive’. With the former, the system applies a fixed function to a given set of inputs. The output following time on the market will be the same as that provided at the time of submission. With an adaptive system (changing behaviour using a defined learning process), the output following time on the market will be different to that provided at the time of submission.

From a development and regulatory perspective, locked systems can follow normal procedure, with changes or updates made following a defined change control process before or after deployment. New software versions are deployed only after all changes have been successfully verified. In contrast, the regulation of adaptive systems is in its infancy.

The FDA aimed to address this by piloting a Pre-Certification programme for SaMD (standalone software) as my colleague Joe Corrigan and I explained in this article.  The pilot was launched in 2017 with supporting documentation published in 2019.  The key findings from the pilot published in September 2022 conclude that a change in the law would be required to implement the approach described by the programme’s Working Model, as current regulation renders its implementation impractical.

How can we help?

Whether you are a start-up, an established software developer or a medical device company, we can assist you with the design and development of smart devices, either as a complete system or just by taking care of some of it. Our ISO 13485 certified Medical Development Process includes requirements for software as a medical device, and we have teams of engineers who can cover all the requirements of the whole system as well as its individual components. If you’d like to continue the conversation and find out more, do please email me.

Expert authors