Platform

Validation that does not restart every quarter.

In a regulated environment the question is never whether a system works. It is whether you can prove it works, and whether that proof survives the next release.

The shape of a validation.

The standard three qualifications, in the order they run. What differs between vendors is not the names but how much of the evidence you have to produce yourself.

  1. Installation qualification.

    Evidence that the system is installed and configured as specified, in the environment it will run in. For a SaaS deployment this covers the environment and configuration rather than a local install.

  2. Operational qualification.

    Evidence that each function behaves as specified across its operating range, including the controls that carry your compliance case: audit trail, signature, permissions, change control.

  3. Performance qualification.

    Evidence that the system performs as intended in your process, with your labels, your printers and your people. This is the qualification that cannot be delivered generically, because it is about your workflow.

What keeps it proportionate.

Risk-based, not uniform.

GAMP 5's premise is that testing depth should follow the risk of the function. Applied honestly it means the signature path and the audit trail get rigour, and a colour picker does not.

Change control defines the scope.

Because every change carries its reason and links every object it alters, the question "what does this change affect" has an answer in the system. Revalidation scope follows that answer instead of defaulting to everything.

Configuration is where your risk lives.

Two companies running the same product have different validation exposure because they configured different workflows. Validation is executed against your configuration for that reason.

One system, not one per site.

Browser-based printing means there is no local installation at each plant to qualify separately, which is where multi-site validation effort usually multiplies.

Questions people ask.

Does Innovatum supply IQ/OQ/PQ documentation?

Yes. Innovatum supplies IQ/OQ/PQ documentation and validation support for RONOVA. Ask during evaluation which documents are templates you execute and which Innovatum executes and hands over, because that split is what determines your internal effort.

What happens to our validated state when RONOVA is updated?

That depends on the release and on what your configuration actually uses, which is why change control matters: because every change records its reason and links the objects it alters, the impact of a change is a question the system can answer rather than an assumption you have to make. Ask Innovatum for the release cadence, the notice period and the regression evidence that accompanies a release. Those three decide the ongoing cost of a validated deployment far more than the size of the initial package does, and they are the right thing to settle before signing rather than after.

Do we have to revalidate everything when we change one label?

No, and a system that made you do so would be unusable. Changes are made under change control with the reason captured and every affected object linked, so the scope of any revalidation follows what the change actually touched. Your own validation procedure sets where that line falls.

Is validation different for a multi-site deployment?

The performance qualification covers each site's own process and printing, since that is what differs. What does not multiply is the installation: printing is browser-based and there is no local install per plant to qualify separately.

Cookie preferences