Selecting the best possible MedTech solution development strategy involves engineering, business and regulatory considerations that will immensely impact your development, maintenance and operations costs. For medical devices, as with any other form of product development, there is no one-size-fits-all approach.
At Star, to ensure the successful development of connected and compliant MedTech and Digital Healthcare solutions, we draw on our experience helping clients build patient-centric, compliant and scalable medical device technology through end-to-end product development support.
We start by walking through perhaps the most fundamental consideration: what makes something a medical device? From our experience, many companies think in terms of black and white – either something is a medical device or isn’t. The reality is that there are many options and different approaches available to you.
Taking the right course of action from stage one streamlines your regulatory processes and sets the foundation for the future development and maintenance of your product and your company in the overall medical device landscape. In this article, we outline a few important considerations that help shape our thinking about MedTech and Digital Healthcare solution development here at Star.
The importance of device classification
Many companies approach us with the idea that their entire product needs to be a medical device. This often isn’t the case.
Understanding why begins not by looking at the project idea but the company itself. Is it the owner of an existing medical device or suite of devices? Or is it a startup creating something quite new in the ecosystem? Budget, history and expertise make all the difference here.
Entire product strategies are often based around medical device classification. We’ve outlined below a simplified interpretation of the FDA process that can help you determine if the product you want to build will be considered a medical device:
- Describe your product in an "intended purpose" document including intended use.
- Compare the intended purpose vs. medical device or in vitro medical device definitions for the market you intend to launch in.
- From here, you document, reason in "regulatory strategy" and collect information for your product across all planned regulatory regimes.
Understanding these nuances is critical because some companies deliberately do not want their product to be considered a medical device. If so, they’ll adjust the functionality or add a clinician step in between the patient and the course of action to prevent this classification.
For example, let’s say you wanted to create a solution that supports the management of multiple sclerosis (MS). Since many MS interventions are delivered weekly via painful intramuscular injection, knowing which sites to locate injections is crucial for patient wellbeing and adherence. An app that just shows a history of injection sites would not be considered a medical device. It’s basically the digital equivalent of a notebook with a sleek UI.
However, if you created an app that tracked injection sites and had an algorithm that advised patients where they should inject based on their recent history, that would be a medical device. This is a crucial distinction because you can have two devices essentially performing the same function with one that directly suggests an injection site while the other tracks it, falling under different product classifications. This has massive implications for your product strategy, design, development and time to market.
What approach should my company take?
Each of our clients is different and we always advise accordingly. In some instances, we may suggest they pursue the route of building a regulated medical device. For other companies, the timing just might not be right. Often, we'll recommend that certain components of their product be medical devices and other elements not (a key benefit of developing MedTech solutions).
From our experience bringing innovative medical devices to market, we can help clients better understand where exactly these classifications lie and what approach best suits their current and long-term goals. For example, younger companies might not have the budget to pursue building a regulated medical device though this may be a goal down the road.
So what we can do is provide them guidance on healthcare topics and give them a strong roadmap for developing connected medical devices. This is exactly the strategy we pursued with an ongoing project. We developed an overall solution in which some parts of it are medical devices, and some aren't, and have supported that journey from ideation through launch.
We are currently in phase 2 of product development with this partner and are helping them navigate the regulatory channels to get the next iteration of functionality certified. Our value comes from our ability to take an endgame-driven approach that begins by creating a roadmap to help clients navigate and pursue the right strategy for them and then help them along every step of the way.
MedTech solutions and a modular approach
It’s still easy to think about medical devices mainly being pieces of physical hardware since SaMD solutions are still in their relative infancy.
Most MedTech solutions have a 10+ year lifespan. We have to design/architect the system so updates will be easy to schedule, release and deploy from that perspective.
Working with a digital product gives you more flexibility in creating, iterating, deploying and updating it. With MedTech solutions, we can segment different components of a software solution into medical and non-medical devices inside the same ecosystem to achieve the following benefits:
- Be able to release and, if needed, certify each of the medical devices separately.
- Reflect the different frequency of changes vs. other medical devices, e.g., mobile apps being updated more frequently than the backend systems.
- Have high flexibility and low regulatory requirements in non-MD elements of the solution.
- Enable clients operating the solution to update only part of the system.
- Make each of the elements encapsulate specific logic and architecturally independent.
As important as the initial time to market is, most of the total ownership costs come after the GoLive milestone (placing on the market). With the right planning and development, you can lower these costs and give your product what it needs to evolve in the future.
Approaching intended purpose statements
A device’s intended purpose is the overarching element that guides its design. Knowing how to structure your intended purpose statement gives you the flexibility needed for successful medical device development – and therefore flexibility in terms of time and cost. Small changes in how we described the intended purpose may have a big impact on how we go through the certification process.
Sometimes the regulatory effort is the same for different products depending on how we structure the intended purpose. It's very intertwined with the business plan for what we are going to do with the design and how you are going to be able to sell, market and maintain it down the road.
According to the EU Medical Device Regulation (MDR) Article 2, “‘intended purpose’ means the use for which a device is intended according to the data supplied by the manufacturer on the label, in the instructions for use or in promotional or sales materials or statements and as specified by the manufacturer in the clinical evaluation.”
Everything starts and ends with your intended purpose statement. Your product's classification will be based entirely on it. If you end up changing our intended use, then you may have to go through the complete certification process all over again. This is where we emphasize the importance of working with the right ecosystem partner. Sometimes, these changes are unavoidable. The longest part is the clinical evaluation and conformity assessment procedure, but with the right strategy and notified body the time this takes can be reduced to 3-6 months.
At Star, when defining an "intended purpose" document with our clients we usually evaluate the following information: intended use statement, main functions, medical indications, medical contraindications, user groups with profile and population, body part/tissue type, intended usage environment, functioning principle, other intended uses, and medical device limitations/device misuse.
This master document guides design control, product development, risk management and everything to do with bringing your product to market.
Updates and product changes
Connected medical devices create opportunities and challenges legacy manufacturers never had to consider. From further iterations of the software to patching security vulnerabilities, flexibility needs to be baked into any product.
If we define the medical device product with a narrow focus in the intended purpose statement, then as long as future changes are not changing the uses of the medical devices, then we're just updating an application (just like any other piece of software) and shouldn’t have to recertify it with the regulatory bodies.
Security updates are a great example of this. The same would also go with updating the library that operates a piece of software without changing the interface. You'd only have to go through the verification and validation process again if you made a major change like overhauling the AI algorithm with something entirely different.
There are three levels of update divided by whether it’s a significant or non-significant change, which is then sub-grouped into version and Hotfix releases.
- Significant change – requires new version release, as well as usually repeating clinical evaluation process, new UDI-DI (unique device identifier-device identifier), as the medical device performance has been significantly changed. In this case, you may have to repeat clinical evaluation, new CE mark, audit of product and so on.
- Non-significant change (minor software revision) – does not require repeating Clinical Evaluation Process, as the device performance remains unchanged. For these modifications, you have to show that the intended purpose has not been changed. Product requirements have not been changed. Thus we are just updating a new product version that's fully equivalent to what's been on the market. Such a change from software perspective can be introduced in two ways:
- Version Release – a new product version which still does not impact the medical device performance. Full verification and validation activities are applied.
- Hotfix Release – a software revision associated with bug fixes, usability enhancement. Verification and Validation activities specific to the modified element are applied.
Below are three examples of medical device product updates that highlight whether products have to be re-certified or not after changes are made to them.
- Adding a new medical device feature initiated by extending an Intended Purpose document would be introduced as the significant change, resulting in repeating clinical evaluation process, new UDI-DI assignment, and a new software product identification string increased e.g. from version 1.1.0 to 2.0.0 (please note product identification string is not UDI-DI). The result would require a re-certification to repeat market approval.
- Technology stack update for the existing product would be done by releasing a new Version Release, as a non-significant change. The UDI-DI would remain the same, the software product identification string would be updated e.g. from version 2.0.0 to 2.1.0.
- A security patch combined with minor problem report fix would be by releasing a Hotfix Release, as non-significant change. The UDI-DI would remain the same, the software product identification string would be updated e.g. from version 2.1.0 to 2.1.1.
The bottom line is that once we start to look at SaMD and how modular and communicative its different components can be, you're opening up a world of flexibility to not only clear regulatory hurdles more easily but also more quickly update and evolve your product offering.
The world of medical device development might be complex, but it’s full of potential to deliver value to patients, providers and the entire spectrum of healthcare ecosystem partners.
