From Notepad to 10 Terabytes: How a Scottish Gastroenterologist Built an AI-Powered Clinical Research Operating System

When Dr. Shaun Chuah sat down in 2020 to map out the logistics for a sprawling new medical study across Glasgow, he encountered a daunting mathematical reality. The prospective research initiative—focused on inflammatory bowel disease (IBD)—was designed to track approximately 200 patients across three cities and dozens of hospitals, with follow-up appointments scheduled every three months. Over a projected two-year period, the study would yield an estimated 30,000 biological samples, including blood, stool, and saliva.

Faced with this massive influx of incoming material, Chuah did what any clinical researcher would do: he asked his peers how they managed such large-scale tracking. The near-universal answer was Microsoft Excel. For a study involving tens of thousands of individual data points, multiple hospital networks, and complex longitudinal tracking, relying on traditional spreadsheets presented severe risks of data fragmentation, human error, and operational bottlenecks.

Realizing that off-the-shelf laboratory information management systems (LIMS) were prohibitively expensive, overly rigid, and poorly suited for multi-site academic studies, Chuah made a pivotal decision. With virtually no formal programming background—limited to hand-coding basic HTML in Notepad during his high school years—he opened a Django framework tutorial and began to read. Six years later, that rudimentary learning exercise has evolved into Foundry120, a sophisticated research operating system currently managing 10 terabytes of sensitive clinical and genomic data, bolstered by an agentic artificial intelligence engine named Helix.

The Operational Bottlenecks of Modern Biomedical Research

The challenges faced by Chuah and the Gut Translational Research Group at the University of Glasgow reflect a broader systemic issue within modern clinical and translational science. Translational research bridges the gap between clinical practice and laboratory science, requiring researchers to recruit patients, collect biological samples, process them through high-throughput assays, and synthesize vast oceans of multimodal data.

In the early stages of the IBD study, the primary hurdle was physical tracking. Chuah’s custom application initially solved a fundamental supply-chain problem: tracking container movement. By implementing QR-code labeling, researchers could scan samples at point-of-collection in participating hospitals, register them instantly into a centralized database, and track their transit across various testing facilities.

However, successfully managing the physical inventory was only half the battle. Once the samples entered experimental pipelines, they generated staggering volumes of digital data. Microbiome sequencing from stool samples and cell-free DNA (cfDNA) sequencing from blood plasma yielded massive file sizes. A single cfDNA sequencing file for an individual participant regularly measures between 5 and 10 gigabytes. Across cohorts and multiple assay types, data volumes quickly scaled into terabytes, eventually surpassing 10 terabytes as the platform expanded.

Traditionally, this data would remain siloed. Individual researchers would store microbiome results on personal laptops, while clinical records remained locked in hospital databases or scattered across uncoordinated network shares. Correlating clinical symptoms with genomic sequencing required cumbersome manual data joins, turning routine queries into multi-day administrative tasks.

Scaling Up: From Local Host to Cloud Infrastructure

Transitioning from a local development environment to a secure production pipeline presented a steep learning curve for a self-taught developer. To ensure reliability, security, and scalability, Chuah adopted modern software engineering practices, integrating continuous integration and continuous deployment (CI/CD) pipelines via GitHub Actions. This allowed for rapid, automated deployment of bug fixes and feature updates directly to production environments in minutes rather than hours.

Storage limitations also necessitated a shift in infrastructure. Moving away from traditional on-premise university file shares—which frequently impose restrictive storage quotas and require bureaucratic intervention to expand—the project migrated entirely to Microsoft Azure Blob Storage. Operating within the University of Glasgow’s Azure tenancy, the platform leverages cloud scalability to accommodate exponential data growth, replacing hard capacity limits with predictable, managed cloud expenditure.

Furthermore, the technical stack evolved to meet the demands of modern data processing. While the initial iteration relied entirely on Django templates for standard Create, Read, Update, and Delete (CRUD) operations, the contemporary architecture of Foundry120 employs a decoupled model. The backend runs on Django and the Django REST Framework, while the frontend utilizes TypeScript and React. This hybrid architecture pairs the security and robust database management of Python with the asynchronous responsiveness required for complex, multi-step AI interactions.

Introducing Helix: The Role of Agentic AI in Scientific Discovery

As the platform matured, the integration of artificial intelligence shifted from passive text generation to active workflow orchestration. Built on top of Foundry120’s centralized data architecture, the Helix AI system operates as an agentic assistant designed specifically for translational science teams.

Unlike conventional chatbots that function primarily as conversational search engines, agentic AI systems are designed around autonomous loops, tool utilization, and self-correction. When a researcher asks Helix a complex question—such as identifying all available plasma samples from patients treated with a specific therapeutic class—the AI does not attempt to ingest the entire dataset into its context window. Instead, it interacts with deterministic backend tools.

Helix queries the database, writes and executes Python scripts in a secure sandbox virtual machine, joins clinical metadata with experimental outputs, and debugs its own code if errors arise. If requested to generate visualizations, the agent drafts and executes Matplotlib code, returning analytical plots and structured insights to the user in minutes. This capability drastically reduces the time required for exploratory data analysis, shifting the researcher’s role from manual data wrangling to supervisory verification.

Security, Governance, and Compliance in Clinical AI

Deploying artificial intelligence within a clinical research environment introduces stringent regulatory and ethical demands. Patient data privacy is paramount, governed by frameworks such as the Health Insurance Portability and Accountability Act (HIPAA) in the United States and the General Data Protection Regulation (GDPR) in the European Union and the United Kingdom.

Foundry120 was architected with these constraints front and center. Rather than permitting AI agents to directly access raw files or execute arbitrary commands, Django acts as an intermediary security guardrail. All data access, user permissions, and computational tasks are strictly mediated by role-based access control (RBAC) policies enforced at the application layer.

Moreover, data sovereignty requirements dictate that all sensitive clinical data and AI inference processes remain strictly within approved geographic boundaries. By utilizing regional Azure data centers—primarily UK South for domestic studies and Sweden Central for European compliance—the platform ensures that patient information does not cross unauthorized international borders during processing. This localized governance model allows academic research groups to harness the computational power of advanced AI while maintaining strict adherence to institutional ethics boards and research governance approvals.

Broader Implications for Academic Research and IT

The evolution of Foundry120 highlights a broader paradigm shift in how academic and medical institutions approach data infrastructure. Historically, universities relied on centralized, on-premise high-performance computing clusters and rigid enterprise software solutions. However, the sporadic and burst-heavy nature of translational research workloads—where massive computational power is required intermittently for sequencing pipelines and data analysis—makes cloud-based, on-demand infrastructure increasingly attractive from an economic and operational standpoint.

At the same time, the rise of agentic AI threatens to disrupt traditional data management workflows across multiple scientific disciplines. As data volumes continue to swell—with upcoming genomic technologies projecting terabyte-scale outputs per individual sample—manual data curation will become entirely unsustainable. Platforms that successfully bridge the gap between secure data governance and automated, tool-using AI agents offer a glimpse into the future of laboratory operations.

While challenges remain regarding the absolute reliability of AI-generated analyses and the necessity of rigorous human supervision, tools like Helix demonstrate how domain experts can build bespoke, powerful technological solutions to solve localized bottlenecks. For Dr. Shaun Chuah and the Gut Translational Research Group in Glasgow, a journey that began with a Python tutorial and a looming spreadsheet crisis has culminated in a scalable research operating system capable of supporting the next generation of medical breakthroughs.