Validation in Medtech, where getting it right is more important than perfection

”“We’re still talking about this because many people are still looking for a reasonable and sustainable way to handle validation in practice,”,” says Maria Liljevret, an expert at Plantvision with extensive experience in both the pharmaceutical and medical device industries. So it’s not a matter of a lack of willingness, but rather of finding the level at which validation is meaningful and effective, without becoming a hindrance. 

From Regulations to Practice: What Needs to Be Validated? 

The basic requirements for validation are set forth in ISO 13485:2016, the quality management standard for Medtech. It specifies that software applications used in quality assurance, production, or monitoring must be validated both upon implementation and when changes are made. This may include, for example, document management systems, case management systems, training platforms, production-related automation, or systems for data collection and analysis. 

““It’s about the systems that support our operations, our decisions, and our documentation. And so it’s important that these systems work as they should.” explains Lina Stange, a specialist in application validation within the life sciences at Plantvision. 

Not just any risk 

Risk-based decision-making is a central concept in the standard. However, this does not refer to just any risk, but rather risks associated with patient safety, product performance, or regulatory compliance. It is therefore important to distinguish between business-critical and regulatory risks. The assessment must be conducted at both the process level and the application level: In which process will the application be used? Is the data subject to regulatory requirements? Could a failure affect quality or traceability?

”“The important thing is to have the courage to make a judgment,”,” says Lina. “It’s better to have a reasonable and documented analysis than to do nothing at all because it feels too complex.” 

Three Approaches to Validation: Standard, Configured, or Custom-Built 

Not all systems require the same amount of work. One way to structure your validation work is to start with the application's complexity and degree of customization: 

• A standard application that is used without customization generally requires only that you verify that the features meet the needs of the business. 

• A configured application is customized with logic, roles, or workflows. This requires more extensive testing and clear requirements documentation. 

• A custom-developed application has been built for this purpose. It must be thoroughly validated: requirements specification, design specification, test cases, risk analysis, and instructions. 

“The more we customize the functionality, the more important it becomes to test all variations and to have clear documentation on how the application should work,” explains Maria. 

Real-Life Example: Incident Management 

Let’s take a concrete example: an incident and complaint management system. In the first scenario, the organization has chosen to build its own application, but without any help text or guidance in the interface. The system receives reports from customers, forwards them for assessment and investigation, and automatically generates reports for regulatory authorities. This automated logic is critical—if the system does not function as intended, there is a risk that incidents will not be investigated in a timely manner or that incorrect information will be reported. Both patient safety and regulatory compliance can be affected. 

This high degree of in-house development therefore requires extensive validation. In addition to process descriptions, requirements specifications, and risk analyses, a detailed design and configuration specification is needed, along with several test plans—often focusing on different types of functionality—and a separate user manual that guides staff through each step. 

In the second scenario, the company has instead opted for a standardized solution from an established vendor. The interface is intuitive, the features are familiar, and the vendor’s documentation is already well-developed. In this case, validation can be simplified. Often, a simpler validation plan is sufficient, involving a review of the vendor’s test documentation, verification that the features meet the company’s own requirements, and documentation of the conclusions. 

”“The main thing is to tailor the documentation to the level of risk and complexity, not to fill a folder just for the sake of it,”” Lina emphasizes. 

Don't forget the everyday stuff—yes, even Excel 

A common mistake is to underestimate systems that seem simple, such as Excel spreadsheets. But if a spreadsheet is used to make decisions based on data—for example, for litigation or regulatory requirements—then testing and documentation are required. 

Maria explains: 

““You don’t have to overcomplicate things. A simple requirements specification, a test plan, and verification that the calculations work are often enough.” 

The Right Process, Not More Documentation 

Validating systems within the “ Medtech ” is not about producing the most documents, but about making the right decisions. A well-thought-out, risk-based process helps organizations focus on what really matters: functionality, security, and compliance. This means having the courage to tailor the effort to the system’s actual impact and complexity. 

““It’s better to do something than nothing at all. Validation isn’t about perfection; it’s about making a conscious, informed choice,” concludes Lina Stange. 

Would you like to strengthen your validation strategy, build internal processes, or get help getting started? We’re here to listen, share our experience, and provide support where needed. Reach out to us however you prefer—sometimes the smallest step is the one that takes you the farthest.