Countless standards and regulations, confusing classifications, development and validation processes that demand precision, make medical device development unbelievably complex.
Being a medical software and hardware development company, we collected the most frequently asked questions to guide you, giving you the clarity you need.
How do we determine whether our software is classified as a medical or a wellness/lifestyle app?
This is an important question because medical apps must be developed with stricter safety standards and requirements, unlike wellness apps. Medical apps have a specific intended medical use – they are designed for diagnosis, disease mitigation, or prevention. If such apps track and analyze vital signs, suggesting any treatments, they are also considered medical software. Therefore, it falls under medical device classification and is subject to digital health regulations.
In contrast, wellness apps are designed to promote a healthy lifestyle or to improve sleep, nutrition, and physical activity. They can track and display raw data of vitals, but they don’t assign any treatment decisions. Because these apps provide only certain well-being advice and don't pose any harm to users, they face fewer regulatory requirements.
If you promote your wellness app as a medical one, you must reclassify your software, or it can lead to legal consequences. Work with a reliable tech vendor to ensure your software is correctly classified before development begins.
We want to implement a new feature into our medical device. Do we need to re-certify it?
According to EU MDR, implementing a new feature does not necessarily lead to reclassification and recertification. However, if the feature changes the device’s intended purpose or increases the risk for users, it must be treated as an entirely new product. Therefore, before investing in the development, consult with a regulatory advisor or Notified Body to understand whether it will make you undergo the conformity assessment procedure once again.
We want to implement AI into a medical device or software. What do we need to know?
If you want to implement AI in your product, the first thing you need to consider is the EU AI Act. According to its scope, AI systems fall under different risk categories: minimal, limited, high and unacceptable. There are a number of factors that determine which category your AI system will fall into. For example, AI systems integrated as a safety-critical component of a device or as a standalone product that can harm the health and safety of people are considered high-risk; and, therefore, must follow a stricter list of requirements. The same may apply to large language models (LLMs) used to generate code for an app that can directly impact patient safety. However, if AI is used to automate administrative tasks that do not impact patient safety – such as tracking software usage or generating documentation – it is not classified as high-risk.
Additionally, all medical devices, whether with or without AI, must adhere to a quality management framework established by the MDR and standards such as ISO 13485, IEC 62304, and ISO 14971.
To navigate AI integration more smoothly, it is recommended to have a team of different specialists, from technical and regulatory experts to clinical and legal professionals. For example, Lemberg Solutions, as a software and hardware development partner, can help:
- Organize a secure AI development process;
- Prepare and manage datasets for accurate and bias-free AI performance;
- Continuously monitor AI behavior to ensure it provides appropriate decisions;
- Create and maintain technical documentation, including transparent descriptions of AI functionality in the medical device.
When developing an MVP of a medical device, we don’t need to worry about regulations?
This is a dangerous misconception. Healthcare MVP differs from a standard consumer one. The typical MVP aims to prove market fit, whereas the goal of an MVP for a medical device is to demonstrate that it can comply with and function as intended. Therefore, when developing an MVP of a medical device, you must follow all security standards and regulatory requirements. Additionally, your MVP must undergo clinical testing to ensure its safety and efficacy.
Besides that, if you plan to integrate your medical product into a hospital system, you need to consider the interoperability factor early on. It doesn’t mean your MVP should integrate with an external system right away, but you should design the software architecture so it can connect with other platforms in the future.
You cannot afford to think about compliance readiness of your device at the end, as compliance specifies how the process of software or hardware development must be structured and how the product must be built, outlining architectural specifications, data security obligations, and documentation requirements.
Is there a difference between design validation and verification for medical devices, and who is responsible for each?
Design validation and verification are two crucial phases in medical device development, according to MDR. However, many people confuse them, considering them as interchangeable. In reality, they both have different aims.
Verification means checking that a device meets the software and hardware quality requirements. This phase is usually covered by your outsourcing vendor during the development lifecycle. The development team uses different testing approaches, like unit, integration, and regression tests. Additionally, engineers review the documentation to ensure the device is not vulnerable to cybersecurity threats.
Validation, on the other hand, is aimed at checking whether the device meets user requirements and functions as intended in clinical settings. It consists of interoperability, usability, stress, and load testing with patients or clinicians. Validation usually should be conducted after design verification. And only after the validation phase medical device is ready for full-scale manufacturing. Typically, the responsibility for the validation phase lies with the product owner; however, the development team can sometimes help with it.
Can we use open-source components in a medical device?
Open-source components are accepted for the development of medical device software only if they comply with all relevant industry standards and regulations. Additionally, you must adhere to the license obligations of open-source components, as failure to do so may expose sensitive patient or hospital data to vulnerabilities.
The best option in this situation is to continuously monitor and verify the security of open-source components in medical devices; to avoid any risks, updates must be made accordingly. It is recommended to have a responsible expert or a team of experts who can provide continuous support and adherence to open-source standards. A development partner can help by:
- Selecting and incorporating the most appropriate open-source libraries for your product;
- Documenting everything to keep the process transparent for certification;
- Conducting audits to monitor compliance with the license and standards.
What does the perfect project process look like for medical device development?
There is no strict sequence for how the medical development process unfolds; some stages can overlap, allowing the process to progress efficiently without compromising quality or regulatory compliance. In practice, the development process can look like this:
#1 – Concept research. The first and most crucial stage, when the client and tech vendor assess the feasibility of the idea and determine whether there is a market need for the solution.
#2 – Initiation. During this phase, the development team and client team define key deliverables, milestones, and deadlines, setting up a clear roadmap and dividing responsibilities.
#3 – Design and development. The tech vendor works on the architecture and functionality of the product, following regulatory and technical guidelines.
#4 – Verification and validation. After the product is developed, it must undergo verification and clinical validation to meet both technical requirements and user needs.
#5 – Regulatory submission. With the clinical evidence and technical documentation obtained during the previous phase, the product can be submitted for regulatory approval.
#6 – Full-scale manufacturing. Once approved, the device can move into mass production.
#7 – Product maintenance. The tech experts are continuously monitoring the product's performance to ensure it remains safe, effective, and compliant.
Can we retrofit documentation after development — once the product is working?
In theory, documentation can be created after the product is developed; however, doing so can considerably extend time-to-market and increase the risks of inefficiencies within the documentation. EU MDR and IEC 62304 require that the entire development lifecycle must be documented from the start of the requirements phase until the very end of the verification and validation processes. If found, any gaps in the documentation can lead to failed audit and delayed certification.
However, in most cases, a development partner manages this process for you – documentation is created at the same time as development moves forward. At the end of the project, you receive fully functional medical software or hardware along with complete technical documentation, including functional descriptions, design and architecture elements, test reports, and security measures.
Who is legally considered the “manufacturer” if we outsource the entire development?
According to EU MDR, the manufacturer is the one who takes the legal responsibility for placing the medical device on the market under its name and holds all obligations for compliance and safety of the product. An outsourcing development partner does not have any legal rights to the product nor manufacturing responsibilities; they simply act as suppliers or contractors. However, outsourcing vendors can support you in obtaining regulatory approval by providing a secure and high-quality product.
How do we ensure vendor-provided documentation meets audit standards?
To ensure that your vendor provides documentation that meets all audit requirements, define product requirements at the start. Together with the outsourcing team, outline the format and content expected from them, referencing required standards and regulations. Also, it is advisable to have a responsible person who will communicate with the development team and verify that they are on the right track and that the documentation is accurate.
Final thoughts: How to navigate medical device development flawlessly
To navigate medical device development with confidence, it is best to have a reliable outsourcing partner. Experienced vendors will take on the development process, ensuring security and compliance, while you can focus on your business.
Lemberg Solutions has over 15 years of experience in the healthcare sector, with a deep understanding of EU regulations, like MDR, GDPR, and EU AI Act. Additionally, we hold ISO 27001 and ISO 9001 certifications.
For more information on medical device development, check our LinkedIn article!
