Researcher-First Data Collection: A Private REDCap Deployment for SMRC
Thomas Beaudry
Open Data Capture is the established and preferred platform of the Douglas Neuroinformatics Platform for clinical research data collection. We build it, deploy it, support it, and continue to expand what it can do for researchers at the Douglas and beyond.
But the goal of the DNP is not to force every project into one tool. The goal is to serve researchers first.
For some groups, the right solution is ODC. For others, the right solution is a custom instrument, a data-cleaning pipeline, a hosted virtual machine, or a carefully managed deployment of an existing research platform. The important question is not “what technology do we prefer?” It is “what does this research team need, and how can we make that need sustainable?”
That was the starting point for our work with St. Mary’s Research Centre.
The need: a private REDCap deployment
St. Mary’s Research Centre needed an internal, private REDCap deployment on the hospital network. REDCap is already familiar to many clinical research groups and is widely used for building surveys, databases, and research data-collection workflows.
The technical request was straightforward in principle: deploy REDCap in a secure internal environment.
The real challenge was longer-term. A research data-collection system is not useful only on the day it launches. It has to keep running. It has to be backed up. It has to be updated. It has to survive staff turnover, server changes, and the inevitable moment when someone needs help months or years after the initial setup.
That is where the DNP model matters.
The problem with one-off technical work
Research groups often end up solving informatics problems in fragile ways.
Sometimes a contractor is hired to build or deploy a tool. The work gets done, but when the contract ends, the practical knowledge leaves with the contractor. Months later, if the server breaks, an upgrade is needed, or a configuration choice has to be revisited, the group may no longer have anyone who understands the system.
Other times, the work falls to a research assistant, student, or trainee. That can work in the short term, especially when the person is talented and motivated. But research teams change. Students graduate. Assistants move on. Documentation is often incomplete because the person was solving an urgent problem, not building a long-term service. The result is a platform that technically exists, but becomes difficult to support.
This is a common pattern in research computing: the first deployment is treated as the project, when the real project is making the system maintainable.
What we built
For SMRC, the DNP deployed an internal REDCap environment designed to be easier to operate, maintain, and move if needed.
A key part of the work was developing a Docker-based deployment pattern for the REDCap stack. Rather than treating the service as a hand-configured server that only one person understands, the stack is described as infrastructure that can be reproduced. The application, database, supporting services, configuration, and deployment procedure are organized so that the system can be managed consistently over time.
That matters for several reasons.
First, it makes the deployment easier to understand. A future administrator does not have to reverse-engineer months of manual server changes. The structure of the service is captured in the deployment itself.
Second, it makes recovery and migration more realistic. If the service ever needs to move to another server, the work is not a full rebuild from scratch. The deployment can be recreated, the data restored, and the service brought back in a controlled way.
Third, it lets the DNP support the system as a team. The deployment is not dependent on one person’s memory. Any qualified member of the platform team can inspect the configuration, understand the stack, and step in when support is needed.
Why SMRC hired the DNP
The advantage of working with the DNP is not only technical skill, although that is essential. The advantage is continuity.
We are a team of developers, system administrators, scientific programmers, and data specialists who work together across projects. We already operate research infrastructure. We already support internal services. We already think about backups, authentication, documentation, reproducibility, and what happens after the initial launch.
For a research centre, that changes the risk profile of a technical project.
Instead of hiring a contractor who may not be available later, or depending on a student who may leave, SMRC gets access to a platform team that can support the deployment over its lifespan. If one team member is unavailable, another can take over. If the infrastructure changes, the service can be adapted. If the project grows, the deployment can evolve with it.
That is the difference between installing software and providing a service.
ODC remains our platform of choice
This project does not change our commitment to Open Data Capture. ODC remains the DNP’s preferred platform for modern, flexible, continuous clinical research data collection. It is the system we are building for form-based instruments, interactive tasks, longitudinal tracking, secure exports, and institutionally managed research workflows.
But platform work has to be pragmatic.
Researchers do not come to us because they want a particular technology stack. They come to us because they have data to collect, participants to support, studies to run, and scientific questions to answer. Sometimes the best answer is to onboard them to ODC. Sometimes it is to build a new ODC instrument. Sometimes it is to support a different tool because that tool is the right fit for the group’s context.
Serving researchers first means knowing the difference.
Sustainable research infrastructure
The SMRC REDCap deployment is a good example of the kind of work that often stays invisible when it is done well. There is no dramatic interface change and no new research method to announce. There is simply a private data-collection system, running where it needs to run, supported by a team that knows how to maintain it.
That is exactly the point.
Modern research depends on software, servers, databases, and secure data workflows. These systems cannot be treated as disposable side projects. They need the same care we expect from other research infrastructure: planning, documentation, maintenance, backups, and people who remain accountable after launch.
The DNP exists to provide that continuity. Whether we are developing Open Data Capture, deploying local services, cleaning historical datasets, or supporting a partner’s preferred research platform, the goal is the same: give researchers reliable technical infrastructure so they can focus on the science.