Software Validation
Manage continuous software updates with AI assistance, while staying audit-ready.
Three Ways to Rethink Regulated Work with Res_Q Connect
Contents
For years, life sciences companies have invested in specialized systems for quality, validation, IT, manufacturing, laboratories, training, documents, and development. Most of those systems work well at the job they were purchased to do. The problem is everything that happens between them.
A change happens in one application. Someone notices it. Someone else decides what it means. A ticket gets opened somewhere else. Information gets copied into another record. Emails go out. Tasks get assigned. Evidence gets downloaded, renamed, uploaded, and linked. Then, months later, someone reconstructs the whole sequence for an audit.
None of those individual steps is particularly difficult. But multiply them across hundreds of changes, deviations, systems, vendors, and validation activities, and an enormous amount of regulated work becomes administrative coordination.
That's the part we think is ready to change.
In our previous article, APIs Built the Connected Enterprise. MCP Will Build the Agentic One, we looked at how emerging technology can allow intelligent systems to work across the enterprise rather than remaining trapped inside individual applications.
But the technology isn't really the interesting part. The interesting question is: what work can we finally stop asking people to do manually?
Here are three examples, and how Res_Q Connect is built to take them on:
1. A system changes. The validation process starts before anyone has to chase it.
Consider a familiar situation: one of your regulated SaaS applications releases an update.
Today, that can kick off a surprisingly manual chain of events. Someone receives the release notification. Someone has to determine whether the release affects your organization. The relevant changes have to be compared against intended use, configuration, requirements, or existing controls. If there is potential GxP impact, a change record needs to be created. The right people need to be notified. Testing may need to be assigned. Evidence eventually needs to be collected and attached to the validation record.
The software vendor automated the release. Your organization is still manually administering the response to it.
Now imagine a different process.
The change is detected automatically. The relevant information about the release is brought together with what your organization already knows about the validated system. The potential impact is prepared for review. If action is required, the appropriate change or validation activity is opened and routed to the right owner.
A person still makes the decision where your process requires human judgment. But that person isn't spending the first hour finding release notes, copying information between systems, creating records, assigning tasks, and figuring out where everything belongs. The work arrives prepared for a decision — and once that decision is made, the downstream work keeps moving on its own.
This idea extends well beyond SaaS releases. It could begin with an equipment configuration change, a new software version, an updated interface, a modified requirement, or any other event your organization has determined may affect validated state.
The goal isn't to remove people from change control. It's to remove the administration surrounding change control. Instead of relying on someone to notice that something changed and manually start the process, the change itself becomes the beginning of the process.
That's a fundamentally different operating model.
2. Something goes wrong. Enter it once.
Now consider what happens when there's an exception. A deviation is opened in the quality system. An instrument becomes overdue for calibration. A validation test fails. A production event needs investigation. A quality issue requires work from an IT or engineering team.
In many companies, the first record is only the beginning. Someone creates a Jira or ServiceNow ticket. Details from the original issue are copied into it. Someone emails the responsible team. A task gets assigned. Status is tracked in multiple places. When the issue changes, someone has to remember which other records need to change with it. Eventually, QA or Validation has to confirm that the records all tell the same story.
The business process may cross three or four systems. The integration between those systems is a person. That's exactly the type of work that should disappear.
Imagine instead that the deviation is entered once.
Based on type, severity, system, or other defined criteria, the appropriate downstream work is automatically created. Relevant context travels with it. The correct team is notified. Required validation activity can be initiated. As work progresses, the resulting evidence and status stay connected to the original issue.
The employee doesn't have to understand every system that needs updating. They don't have to copy the same information into multiple places. And Quality doesn't have to reconcile disconnected records later to determine whether the process was followed.
The distinction here matters: this isn't about automating the investigation or letting software make an uncontrolled quality decision. It's about automating the movement around the decision. People investigate. People assess risk. People approve. But software can create the record, move the information, assign the work, monitor the due date, escalate an exception, and preserve the history.
That makes the process easier for the person doing the work — and more reliable for the organization overseeing it.
Res_Q Connect is designed around that separation: automate the handoffs and repetitive actions while retaining human review, approval, and exception gates wherever your policy and risk model require them.
3. Someone asks for the evidence. You don't have to go find it.
The third example may be the most familiar. An auditor, QA reviewer, customer, or internal stakeholder asks a simple question: Show me what happened. Show me the change. Show me why you determined it mattered. Show me what you tested. Show me the failed test and the associated issue. Show me who approved it. Show me whether the corrective work was completed.
In theory, all of that information exists. In practice, it may live in six different places. The change request is in one system. Development work is in another. Automated test results are somewhere else. Screenshots were attached to a document. An approval is in the validation platform. A related deviation is in the QMS.
So a highly qualified person spends hours becoming a human search engine — downloading, exporting, renaming, copying, linking, checking versions, comparing dates, assembling the package, and hoping nothing was missed.
There's a better model.
What if the evidence was connected while the work was happening? When a test runs, its evidence is associated with the appropriate activity. When an approval happens, that approval becomes part of the history. When a ticket resolves an exception, the relationship is preserved. When an automated action occurs, the action, timing, authority, outcome, and any exception are recorded.
By the time someone asks for proof, there's far less to assemble. The organization hasn't automated the audit — it has stopped waiting until the audit to create the story.
This is one of the most important opportunities created by connecting regulated systems: the compliance record can increasingly become a by-product of doing the work, instead of a second body of work performed afterward.
The opportunity isn't replacing your systems. It's removing the work between them.
Most life sciences companies don't need another system of record — they already have plenty. The QMS may be where the quality event belongs. Jira may remain where engineering manages its work. ServiceNow may remain where IT manages requests. The LIMS may remain where laboratory results originate. Res_Q may remain where validation is governed and evidenced.
The opportunity is to make those systems participate in a single business process without requiring people to carry information from one to the next. That's the idea behind Res_Q Connect.
It can move data and trigger actions across existing regulated systems while maintaining the controls around execution, evidence, exceptions, approvals, and human oversight. It can use MCP, APIs, SFTP, browser automation, and other methods depending on the system involved — but a business user shouldn't have to care which one is operating underneath.
What they should notice is that the work got easier. A system changed, and the right process was already waiting. A deviation occurred, and nobody had to enter it three times. An auditor asked for evidence, and nobody spent two days reconstructing it.
Start with the work everyone hates doing
When people think about enterprise AI and automation, there's a temptation to begin with the most ambitious possible use case. We think there's another place to start.
Look for the processes where highly trained people are still acting as the connective tissue between systems. Where are people copying information? Where are they creating the same record twice? Where does someone have to remember to initiate the next step? Where are teams chasing overdue work? Where does evidence have to be collected after the fact? Where do people spend time preparing information so someone else can finally make a decision?
Those aren't edge cases. In regulated organizations, they're everywhere. And they're exactly the kinds of processes we built Res_Q Connect to take on.
The future of regulated work isn't removing people from the process. It's removing the manual work that keeps people from doing the parts of the process that actually require them.
About the Author
Bryan Ennis
Bryan Ennis is a life sciences technology and compliance strategist with deep expertise in regulated software development, GxP validation, and enterprise digital transformation. As a co-founder of Sware, Bryan works with pharmaceutical, biotechnology, and medical device organizations to modernize their technology and quality management practices in the face of rapidly evolving regulatory and technological landscapes.
Before Sware, Bryan founded R&D Customer Success at Veeva and led customer retention as Veeva scaled from 3 to 300+ customers and to $240M in annual revenue in addition to developing Veeva’s compliance programs to support regulated companies. Before his Veeva days, Bryan was the head of Regulatory Systems at Genzyme – selecting, implementing, integrating, and validation regulatory content management applications for life sciences.