Build Medtech hardware and software more effectively

Medtech hardware development is evolving. Medical devices are increasingly built around software, which is already proved by a number of cases. Our needs, amplified by the pandemic, have made medicine more “tele-orientated” than it ever was. Of course, almost any medical device with a battery or power cord has a software component of some kind. This evolution of medical devices is shaping a new era of virtual healthcare.

Move medtech hardware forward

The rise of medical devices integrated with bigger systems means many medical tech companies more often work closely with hardware engineers, sometimes for the first time. My perspective is that software companies can perceive the physical components of a device as somehow less valuable or something less cool. But if you slap together the hardware that houses your software offering, you risk creating a product that doesn’t fit your users’ needs. Poorly designed hardware, on the other hand, can interfere with the software’s functioning and lead to a product owner nightmare – a faulty product.

Before starting a project it’s better to ask yourself:

• Does my idea need a hardware device and are there any existing competitors?
• If so, should it be a medical device – with all strings attached?
• Do I have enough resources to develop my idea?
• Who will become my technology (hardware and/or software) partner?
• Do I know anything about medical regulations and certifications?
• Is my idea validated in terms of business?

If you find answers to these questions you can move further with the process. Remember – any answer will guide you ahead to focus on the most underdeveloped elements of the project.

Medtech technical due diligence

Hardware development process isn’t easy.There’s plenty of opportunity for missteps throughout the project life cycle that can set you back millions of Euros and several years – or worse, leading to the company’s downfall. We learnt from more than 50 medical projects we’ve been involved in the last 7 years that any Medtech device product should start with a technical feasibility study or a technical audit. These documents that by their content represent knowledge, competence and instructions for actions in the process of creating a medical device or software and its certification. They allow us to prepare for the prototyping process, suggest which components to use, what to pay special attention to in terms of design, and what challenges you have to face in order for the regulatory office to approve your innovation. In these documents, there is also a preliminary analysis of the medical device class, which – after a positive certification process – will be maintained. 

Due diligence report is not an offer, with pricing only and simple instructions. It is an integral piece of work, performed by engineers and regulatory experts. If I were to point out a direct benefit – you can simply save a lot of hours of work, preparation and avoid re-prototyping the device due to a change of electronic component or casing design.

Medical product ideation

Medical product ideation is the effective gathering, prioritizing and implementing of ideas in order to provide a better Medtech product or service. What we’ve learned so far is that product ideation takes a significant amount of effort to deliver the right Medtech solution that meets customer demands. Common perception of the final product requires everybody staying on the same page, with strong scope definition from end user’s need, collaborative efforts across the team (and sometimes companies), adherence to specifications and requirements extracted from product definition, simultaneously mitigating risks, and sticking to the best possible quality. As you see, a lot of things can go wrong, so my piece of advice is: focus on collaboration. Single player mode here is a recipe for failure and Medtech professionals should always keep that in mind.

Medtech design

If you’d ask me about the key difference between software and hardware engineering, I’d say tha hardware engineers must translate their designs and images into physical form, a process that is both time-consuming and costly. Mind that in the process of development to set appropriate expectations and reduce your stress. Another thing to keep in mind is that the physical aspect of hardware development will impact your medical device’s overall budget and production timeline.

Both software developers and hardware engineers begin with initial designs and iterate on them as they build toward a production-ready end product. But the pace makes a difference. Being rapid and agile in software development is a key to deliver. Code can be rendered fast into a functioning prototype that can then be further iterated on as soon as additional changes need to be made. It means adjusting software on the fly is possible and truly agile.

But hardware development is a very different animal. Cycles are longer and each design iteration must be translated into a physical prototype before it can be further reprised. Depending on the complexity of the product and the fidelity of the prototype, physical prototype production can take weeks or even months.

This means hardware engineers must approach product development differently than their software counterparts.

What engineer first: hardware or software?

While software developers traditionally refer to some of their development tasks as “hardware-dependent” or “hardware-aware,” hardware developers also are calling some of their tasks “software-aware” or “application-driven.” Doesn’t that sound like the classic chicken-and-egg problem? Each device requires software in order to operate, and the sheer number of users imagining new ways to use these gadgets – and the ease of creating instructions that tell the hardware what to do – almost guarantees that software will always be a step ahead of the machines running it.

54% of projects are delivered late, according to VDC. To fix schedule issues, more than 30% of developers would improve debug and analysis tools to better understand hardware, software, and their interaction with each other.

The interaction between semiconductor providers and software houses has become increasingly complex. This means you can’t think about hardware and software as separate projects. The best possible solution is to start with formulation of precise design assumptions. Then, most projects should take care of choosing a processor which is a device’s core. After that – you can start developing software, iterate, and debug. This can have a serious impact later on hardware evolution. My point is – work together on both ends to better understand and deliver the outcome you want to see.

Medical product certification

Like other industries, Medtech innovation starts with analyzing and identifying the market, the need of which is untapped or unmet or there is a more efficient way to address those particular needs. Innovation in healthcare is regulated by quality processes and certificates which are inevitable if we want to introduce a medical device to the market. It doesn’t matter whether we work on a software medical product or hardware or both. Medical regulations should be considered from the very beginning as a certification strategy. Gluing the software and hardware development with a certification strategy allows to avoid misunderstandings, unnecessary costs and putting the project at risk. 

Summary

For most Medtech projects, which aim to deliver a telemedical solution, software and hardware are really two sides of the same coin. Both have the ability to make or break your product. Understanding the ways that software development and hardware engineering differ will help your team chart a realistic course for your medical device’s development — and make the necessary investment in hardware engineering, too. Also, keep in mind that there four steps for Medtech projects that I want you to consider as key takeaways today:

1. Initiation – opportunity and risk analysis.
2. Formulation – concept and technical feasibility analysis.
3. Design and development, including verification and validation to ensure the design output matches the specified design input.
4. Final validation and product launch preparation.

These points are a great insight into the next article about the Medtech development process which is about to come soon. Stay tuned!