Key takeaways
- "Touch a validated system and you re-validate everything" is a myth, but it grew from real disasters, so the caution behind it deserves respect.
- Validation has a boundary. An integration designed to sit outside that boundary, connecting through defined interfaces, leaves your existing validation evidence intact.
- The integration itself needs its own focused validation package, scoped to the connection rather than the systems it connects.
- The right questions, asked before a partner touches anything, will tell you whether they understand this or are about to learn it at your expense.
Every quality manager has heard the story, or lived it. A well-meaning IT project connected something to the QMS, data appeared where it shouldn't, and the company spent months re-validating and explaining itself to an auditor. Stories like that are why integration proposals die in quality review, and why plenty of device companies keep re-typing data between systems years after everyone agreed it was absurd.
The caution is earned. The conclusion drawn from it, that connected systems and validated systems can't coexist, is wrong, and it's costing quality teams exactly the time they don't have.
Why the fear exists
The disasters were real, and they shared a pattern. Someone connected to a validated system in a way that could alter its behaviour: writing records directly into its database, modifying its configuration, or inserting themselves into its workflow. Once an outside process can change what a system does, the validation evidence for that system no longer describes reality. Everything it touched becomes suspect, and the re-validation cascade begins.
So the fear is a correct response to bad integration design, applied indiscriminately to all integration design.
Validation boundaries, in plain terms
When you validated your QMS, you defined its intended use and demonstrated the system performs it reliably: these workflows, these records, these controls. That definition draws a boundary. Inside it sits everything your validation evidence makes claims about. Outside it sits everything else, including the rest of your software estate.
The whole question of integrating safely reduces to one principle: stay outside the boundary. A connection that observes a validated system without altering how it behaves makes no claim your validation evidence contradicts. The system still does exactly what it was validated to do; it's simply no longer the only place that information exists.
Auditors have no quarrel with connected systems. Their concern is a system whose behaviour can no longer be accounted for.
Design patterns that keep the boundary intact
A few patterns do most of the work. You don't need to implement them yourself, but knowing them lets you interrogate anyone who proposes to.
Read-only connectors. The safest integration takes data out and changes nothing. Complaint records flow to a dashboard, CAPA closures trigger tasks elsewhere, and the QMS itself experiences nothing but the occasional read, something it was built to handle. A large share of the value in connecting quality and regulatory workflows comes from read-only patterns alone.
Defined interfaces over direct access. Where data must flow into a validated system, it should enter through the front door: the vendor's supported API or import mechanism, the same routes a human user's actions take. Those routes are part of what the vendor tests and what your validation covered. Writing directly to the database behind the application is the cardinal sin; it bypasses every control the application enforces.
An interface specification. A short document stating exactly what the connection reads, what it writes, through which mechanism, and what happens when something fails. This becomes the anchor for validation and change control later, and writing it first forces every design decision into the open.
Staged rollout. The connection runs first against a test environment, then in production in observation mode, checked against reality, before anyone relies on it. Legacy systems deserve extra care here, since their interfaces are often undocumented, a challenge we cover in our guide to legacy system integration.
Validating the integration itself
Sitting outside your existing validated boundary doesn't mean the integration escapes validation. It gets its own, scoped to what it actually does.
A risk-based package for a typical connection is compact: intended use and requirements for the integration, a risk assessment focused on data integrity (what happens if a transfer fails, duplicates, or arrives incomplete), and IQ/OQ/PQ appropriate to the risk. Installation qualification confirms the connector is deployed as specified, operational qualification exercises it against the interface specification including failure cases, and performance qualification confirms it behaves under real operating conditions.
The scope discipline matters. You're validating the pipe, and only the pipe. Companies that miss this either under-validate, treating the integration as mere IT infrastructure, or over-validate, reopening qualified systems the connection never touches. Both mistakes are expensive in opposite directions.
Change control after go-live
Connected systems keep evolving. Your QMS vendor ships an update; your ERP gets reconfigured. Each change on either side of a connection raises the question of whether the interface specification still holds.
This is where the specification pays for itself. Vendor release notes get checked against a two-page document describing exactly which interfaces you depend on, and most updates clear in minutes. When one does affect the connection, the impact is visible before deployment instead of after. The integration enters your change control process as its own configuration item, with its own review trigger, and stops being the invisible dependency that nobody remembered until it broke.
Questions to ask before anyone touches your systems
A partner's answers to five questions will tell you most of what you need to know:
- Will this connection read, write, or both, and through exactly which mechanism?
- What happens inside my validated system when your integration fails mid-transfer?
- What validation deliverables do you produce, and who writes them?
- How will I know when a vendor update on either side affects the connection?
- Have you done this against systems like mine, and can I speak to that client?
Confident specifics on all five suggest a partner who has done this in anger. Hand-waving on question two or three suggests your quality team's instincts were right all along.
"Integrations that respect what's already validated" is the first sentence on our integrations page because it's the discipline the rest of our work depends on. ULAM LABS maps every system and data flow before connecting anything, ships each integration with its interface specification and validation documentation, and stays involved as your systems evolve. Your team keeps the tools they trust and loses the manual work between them. If there's an integration your company needs but validation concerns have kept on hold, book a discovery call and bring your hardest questions, you'll be talking to an engineer, and we'll tell you within a week whether we're the right fit.
