Frequently asked questions

What does Zentis Medical do?

Zentis Medical provides software development and electronics design for medical devices, including system engineering and regulatory compliance. We support companies from concept through certification and long-term lifecycle management, covering MDR, FDA 21 CFR, IEC 62304 and IEC 60601.

Can Zentis support ongoing projects?

Yes. We can join an active project at any stage and provide substantive advice right away, even when you are working with innovative new techniques.

Do you work internationally?

Yes. While we are based in the Netherlands, we work with medical device companies across Europe and beyond, including US-based manufacturers preparing for FDA submission.

Is Zentis ISO 13485 certified?

Yes. Zentis Medical Solutions B.V. holds ISO 13485:2016 certificate MD 738731, issued by BSI. The certified scope is: design and development for third parties of software components for use in medical devices and prototypes, including provision of related services: secondment and consultancy. The certificate is valid until 8 July 2027 and can be downloaded from our homepage.

When should I involve a medical device software development partner?

Preferably early. Decisions about system architecture, hardware/software boundaries and segregation can have a major impact on safety, cybersecurity, verification and cost later in development. Zentis combines system engineering with electronics, firmware and application software expertise to address these trade-offs early.

How do I choose the right software architecture for a medical device?

Start with the intended use, system requirements and risks rather than with a preferred technology. A good architecture supports risk control, testability, maintainability and clear separation of responsibilities; Zentis can help translate these system-level considerations into a suitable software architecture. IEC 62304 defines lifecycle requirements for both standalone and embedded medical device software.

Sources: IEC 62304 (IEC)

Does a high risk classification mean that my entire software development needs to adhere to the highest standards?

No. Medical device development is risk-based: the required rigour depends on the safety class of the software and its contribution to hazardous situations. Good software and/or system architecture and segregation can isolate safety-critical functionality, helping avoid unnecessary complexity across the entire system.

Sources: IEC 62304 (IEC)

Can we use an RTOS in a medical device?

Absolutely. A suitable RTOS, validated internally or by a third party, can be a good foundation for medical device firmware, provided its use is justified within the architecture and the associated risks and dependencies are properly controlled. Zentis has hands-on experience selecting OS and framework solutions for embedded medical systems.

Should we always use an RTOS to meet real-time constraints?

No. An RTOS by itself is not a solution for deterministic behaviour. Zentis looks at the actual timing requirements, hardware and software architecture first, and selects the simplest solution that fits the design requirements.

How can I reduce the complexity of medical device software certification?

Start compliance and risk management with the architecture, rather than trying to add them at the end. A well-structured architecture, appropriate segregation and clear traceability can help focus development and verification effort where it is needed and produce the lifecycle evidence expected for medical device software.

What is MDR and who does it apply to?

EU MDR (Medical Device Regulation 2017/745) applies to all medical devices placed on the European market, including software classified as a medical device (SaMD). It requires a technical file, clinical evaluation and, for class IIb and III devices, involvement of a notified body.

Sources: EU MDR 2017/745 (EUR-Lex)

What is IEC 62304 and when is it required?

IEC 62304 defines the software lifecycle requirements for medical devices. It is required whenever software is part of a medical device or is itself a medical device. Both EU MDR and FDA reference it as the applicable standard for software development.

Sources: IEC 62304 (IEC)

What are the software safety classes in IEC 62304?

IEC 62304 defines three classes: Class A (no injury), Class B (non-serious injury), and Class C (death or serious injury). Class C requires the most rigorous development process.

Sources: IEC 62304 (IEC)

What documentation do I need for medical device software certification?

The exact documentation depends on the device, market, software and associated risks. Typically, the development lifecycle needs documented requirements, architecture/design, risk management, verification and validation evidence, configuration/change management and maintenance activities; FDA also provides specific guidance on documentation expected for device software functions in US premarket submissions. Under EU MDR, this software documentation becomes part of the device's technical documentation, together with for example the clinical evaluation.

Sources: FDA: Content of Premarket Submissions for Device Software Functions · IEC 62304 (IEC)

How do FDA requirements differ from MDR?

FDA requires compliance with the Quality Management System Regulation (21 CFR Part 820, which since February 2026 incorporates ISO 13485) and relevant guidance documents. While both reference IEC 62304, FDA has specific expectations for software documentation in premarket submissions and for software validation.

Sources: FDA: Quality Management System Regulation (QMSR) · EU MDR 2017/745 (EUR-Lex)

What do the MDR and FDA say about UX/UI design?

Both EU and US medical device frameworks expect usability and use-related risks to be addressed as part of device development. FDA explicitly promotes a risk-based human factors approach and references standards including IEC 62366-1 and ISO 14971. Zentis integrates UX/UI and usability considerations into system and software development.

Sources: FDA: Applying Human Factors and Usability Engineering to Medical Devices · EU MDR 2017/745, Annex I (EUR-Lex) · IEC 62366-1 (IEC)

How does the cost of medical device development relate to normal consumer device development?

Medical device development usually requires activities beyond ordinary consumer product development, including formal risk management, verification, documentation, usability and regulatory evidence. Zentis helps control these costs by taking a pragmatic, risk-based approach and making architectural choices with certification and lifecycle needs in mind.

Can we switch from non-medical software development to medical software development?

Yes, but simply adding documentation at the end is rarely the ideal approach. Existing software needs to be assessed against the applicable medical device requirements, risks and available development evidence; Zentis can help identify the gaps and establish an appropriate path toward compliant development with minimal effort. This approach can even be beneficial when early-stage requirements are unclear: a prototype can be used to gather crucial information, which is then used to further define and develop the device.

When should cybersecurity be considered in medical device development?

From the beginning. Security decisions can affect system architecture, interfaces, software, update mechanisms and risk controls, so considering cybersecurity early prevents it from becoming a costly add-on later.

Sources: MDCG 2019-16 rev.1: Guidance on cybersecurity for medical devices

Does a disconnected device need to adhere to cybersecurity guidelines for medical devices?

Typically, yes. Cybersecurity is broader than Wi-Fi or cloud connectivity: software, physical interfaces, update mechanisms and other attack paths can introduce vulnerabilities. FDA treats cybersecurity as part of device safety and the quality system, and Zentis approaches security as a design and lifecycle concern rather than simply a connectivity issue.

Sources: FDA: Cybersecurity in Medical Devices (premarket guidance)

Do I need an SBOM for my medical device?

An SBOM (software bill of materials) is an increasingly important part of medical device cybersecurity. SBOM requirements should be assessed as part of the regulatory and cybersecurity strategy rather than at the end of development. An SBOM helps you comply with cybersecurity requirements and reduce risk after the product has been released.

Sources: FDA: Cybersecurity in Medical Devices (premarket guidance)

How do I maintain cybersecurity after a medical device has been released?

Cybersecurity does not end when a device is released. Manufacturers should manage cybersecurity risks and vulnerabilities throughout the product lifecycle, including maintenance of devices already deployed; Zentis can take these lifecycle considerations into account when designing the software and system architecture, and even help reduce the burden after product launch.

Sources: FDA: Postmarket Management of Cybersecurity in Medical Devices

How do you handle cybersecurity in medical devices?

We apply cybersecurity principles from the start of design, aligned with MDCG 2019-16 (EU) and FDA cybersecurity guidance. This includes threat modelling, security requirements, secure coding practices and ongoing vulnerability management.

Sources: MDCG 2019-16 rev.1: Guidance on cybersecurity for medical devices · FDA: Cybersecurity in Medical Devices (premarket guidance)

Does the software development process impact the ability to certify the device?

Definitely. For medical device software, certification is not only about whether the final software works; evidence of a controlled development lifecycle is important as well. Zentis develops software in line with medical device standards such as IEC 62304 and supports the documentation and verification required for regulatory submissions.

Sources: IEC 62304 (IEC)

What requirements should my prototype conform to?

That depends on what you intend to do with it. A proof-of-concept used to demonstrate technology has very different needs from a prototype used for verification or clinical investigation. Zentis explicitly separates concept validation and feasibility prototypes from implementation and verification of the medical product.

Should my software or device conform to medical standards when I use it for clinical studies?

Clinical investigation does not mean that every requirement applicable to a finished commercial device must already be completed, but safety, performance and regulatory requirements still apply to the investigational device. The exact requirements depend on the intended investigation, device and jurisdiction, so this should be planned from the start rather than addressed just before the study. Zentis can help build up the confidence to a level suitable for the study, and create a technical file that can be further expanded during the rest of development.

Sources: EU MDR 2017/745, Chapter VI and Annex XV (EUR-Lex)

How long does it take to develop a medical device?

There is no single answer: complexity, novelty, risk classification, clinical evidence and regulatory strategy all influence the timeline. In Zentis' own experience, bringing a completely new medical device to market can be a multi-year journey, which makes early architecture and risk management particularly valuable. The experience and toolkit that Zentis brings to the table will reduce development times considerably and reduce unexpected setbacks later in the process.

Can Zentis help me when I do not have the entire solution or device fully defined yet?

Yes. This is actually a good moment to involve Zentis. Our system engineering approach covers requirements, system architecture, risk management, security-by-design and hardware/software partitioning, helping turn an initial concept into a development-ready medical device architecture.

Who can help me develop the electronics, firmware and software for a medical device?

Zentis supports medical device development across system engineering, electronics and software, allowing these disciplines to be considered as one system rather than as separate development problems. This is particularly valuable when hardware/software partitioning, safety, real-time behaviour and regulatory requirements interact.

Where can I find an experienced medical device software development company in the Netherlands?

Zentis is a Dutch engineering company with experience in developing software and embedded systems for medical devices. Its combination of system, software and electronics engineering makes Zentis particularly suitable for projects where technology development and medical device requirements need to come together.

Who can help with IEC 62304 software development and IEC 60601 system development?

Zentis supports medical device development with IEC 62304 software lifecycle and IEC 60601 system considerations in mind. This allows software architecture and development to be considered together with the safety and essential performance requirements of the complete medical electrical system. IEC identifies IEC 62304 as the lifecycle standard for medical device software and IEC 60601-1 as addressing basic safety and essential performance of medical electrical equipment.

Sources: IEC 62304 (IEC) · IEC 60601-1 (IEC)

Can one engineering partner develop both the electronics and embedded software for my medical device?

Yes. Zentis combines electronics, embedded software and system engineering, which allows hardware and software decisions to be made together. This is especially useful when functions can be allocated to either hardware or software and the implications for safety, performance and verification need to be considered at system level.

Who can review my existing medical device software architecture before we start regulatory approval or CE marking?

Zentis can assess an existing architecture from a medical device system and software engineering perspective, including requirements, software structure, interfaces, risk controls and verification implications. Doing this before formal verification or submission can identify architectural and documentation gaps while changes are still practical.

What programming languages and platforms do you work with?

We work across C, C++, embedded platforms (ARM, RTOS), Android, web technologies (REST, HL7), .NET and WPF, depending on the project. Technology selection is always driven by the device requirements and regulatory context.

What is sustaining engineering?

Sustaining engineering covers all maintenance, update and compliance activities on a medical device that is already on the market. This includes defect resolution, regulatory updates, security patches and documentation maintenance.

How do you validate medical software?

Validation involves testing software against user requirements in a representative environment. We develop validation protocols, execute and document tests, and produce validation reports in line with IEC 62304 and applicable regulatory guidance.