Regulated manufacturers face a familiar tradeoff. One large enterprise platform promises visibility across every function, but rarely fits how any single team works day to day. Purpose-built systems fit the work well, yet they leave data stranded in silos. Neither extreme serves quality, operations, and information technology (IT) equally.
Integration offers a third path. Connect specialized, compliant systems through deliberate design, and each team keeps the tools it relies on while data moves cleanly between them. The catch is governance. Connected systems demand stronger controls to protect data integrity, validation, and audit readiness across every boundary.
Blue Mountain’s Lori Bleau and ZenQMS’s Karin Ashkenazi covered this ground in a recent webinar. What follows distills their guidance into a practical playbook for quality, IT, and maintenance leaders working under good practice (GxP) regulations. The full webinar is embedded on this page if you’d prefer to listen to the discussion
Two problems sit on opposite ends of the same spectrum.
A single enterprise system reaches across the whole site, but it rarely suits the people using it. Different roles have different needs, and forcing every team into one shape breeds frustration and workarounds. These platforms are also costly to customize, implement, update, and validate.
Isolated systems flip the problem. Each one fits its users, but data ends up scattered across tools. Teams re-enter the same information, communication breaks down, and audits turn into a hunt across disconnected systems.
Integration takes the strengths from both sides. Consistent data across systems also makes ALCOA++ data integrity easier to maintain. Records that move automatically, rather than getting re-keyed by hand, stay attributable, legible, contemporaneous, original, accurate, complete, consistent, enduring, available, and traceable. Production schedules stay on track because people find what they need in the system they already work in. The document shuffle shrinks, which matters when paid time off, shift work, and hybrid schedules make manual handoffs unreliable. Training narrows to the systems each person actually uses. Access tightens, too: staff see only the data their role requires, which reduces risk. Problems surface earlier because records no longer sit stuck in a handoff, and audits move faster because the story is linked in one place instead of scattered across systems.
Every manual handoff is a place for something to fall through. A person forgets a step, a record sits on a desk, or an issue never reaches the quality team. We are only human, and busy shifts make lapses inevitable.
Integration takes the human step out of the chain. A system tells another system what happened, and the record follows automatically. It also covers the gap when someone is out of office, so you avoid training extra people on extra systems just to keep information moving.
An integration is a data flow, so compliance starts with the data. Karin Ashkenazi framed the work around three specifications.
Teams often hesitate to connect systems because they fear the validation burden. The regulatory direction should ease that fear, because it points toward proportion rather than exhaustive documentation.
The FDA’s current CSA guidance, issued in February 2026, superseded the September 2025 final version. It governs software used in medical device production and the quality management system. It ties directly to the Quality Management System Regulation (QMSR), which took effect February 2, 2026 and incorporates ISO 13485:2016. For drug and biologic good manufacturing practice (GMP), CSA is influential rather than directly binding — a strong signal toward risk-based validation, not a rule that governs your specific product and region. Its approach still lines up with the GAMP 5 Second Edition and the EU Annex 11 revision now in consultation. It also caps more than a decade of FDA work to move computer software validation (CSV) toward a lighter, risk-based footing.
One principle anchors the approach: validation responsibility lies with the regulated entity, not the supplier. Even when the supplier does most of the work, you document that the integration fits your intended use. Sometimes that is a short summary stating you reviewed the supplier’s evidence and accepted it.
From there, effort follows risk. Assess the intended use, the criticality to operations, patient safety, and product quality, and the phase of your product, since clinical work carries more risk than nonclinical. A documentation-only data flow with other controls in place is low risk. An integration that triggers a downstream process with no backstop is higher risk. Ask a sharper question, too: does the data flow affect the product directly, or does it feed reporting and business decisions? The answer changes how much rigor you apply.
Assurance activities scale accordingly. For low-risk flows, accept the supplier’s evidence and confirm behavior through unscripted, exploratory testing. For higher-risk flows, add a short, scripted user acceptance test (UAT) and a focused performance qualification (PQ) on your side. The FDA explicitly endorses unscripted methods, so scripted testing does not have to be exhaustive to be defensible.
Your supplier on each end can test its own side, but it cannot reach your other system. So you verify that data lands correctly in the connected system. In a calibration-to-quality integration, for example, you confirm that a calibration failure actually appears as a deviation, that the fields came through intact, and that the audit trail is complete.
The rest is about how the supplier conducts itself. Ask for proof of security and quality practices: ISO/IEC 27001 certification, a System and Organization Controls 2 (SOC 2) Type II report, and a requirement-by-requirement account of how the system meets 21 CFR Part 11 and EU Annex 11. Both regulations remain shared responsibilities. Many of their requirements are process-driven rather than functionality-driven, so you own the process side no matter what the supplier provides.
The real value sits in the supplier’s software development life cycle (SDLC) artifacts: change-control records, requirements lists, validation risk assessments, test cases, and installation, operational, and performance qualification (IQ/OQ/PQ) reports. Where those artifacts exist and fit your intended use, much of the work shifts from recreating evidence to reviewing it, documenting your acceptance, and running targeted confirmation on your side.
When the webinar asked where integration ownership should sit, most attendees chose shared responsibility with clearly defined governance. That instinct matches the regulatory reality, and it tends to hold as an organization matures.
Software as a service changes constantly, which is an advantage as much as a burden. Vendors fix bugs and improve features, but each release calls for an impact assessment. Ask whether the change affects you and what testing your risk level requires.
A cosmetic change to how a field looks is low risk. A change to authentication is higher, because access control is at stake. Maintaining the validated state matters for every system you run, not just for integrations.
This is where purpose-built GMP systems earn their place. A vendor that builds for regulated industry manages releases under change control and documents its own testing. That reduces your evidence-gathering and regression testing, though you still own intended-use validation and the impact assessment on every release. A generic system you have customized heavily pushes far more of that work back onto you, release after release.
A fair concern follows all of this: give every team its preferred tool, and you risk a tangle of one-to-one connections. Older approaches make that worse. Scheduled file exchanges and point-to-point application programming interfaces (APIs) create the zigzagging paths that become impossible to maintain.
A unified-namespace approach avoids the mess. A central data lake or broker sits in the middle, and each system pushes and pulls from that hub. Message brokers are common for this — an MQTT (Message Queuing Telemetry Transport) broker is one example. The payoff is flexibility: you can replace or add a system without rebuilding every other connection. Each affected flow still needs data mapping, a security review, and risk-based validation before it goes live.
Some data should stay put on purpose. If protected health information would flow into a system that cannot meet Health Insurance Portability and Accountability Act (HIPAA) requirements or sign a business associate agreement (BAA), do not send it there. Most maintenance and calibration integrations never touch patient data, but the principle holds broadly: sensitive data should only cross into systems with controls suited to its classification.
The real choice was never monolith versus silos. Purpose-built systems, connected through compliance-driven design, give each team the tools it needs and give regulators the traceability they expect. Take the risk-based approach the FDA and the EU are both signaling, reuse your suppliers’ evidence, keep the integration in a validated state, and you connect systems without compromising compliance. That is the problem RAM Connect is built to solve — governed data movement between Blue Mountain RAM and the systems your teams already use.
