A shared data platform for a disease that crosses borders

The problem

ALS, or motor neurone disease, is rare enough that no single clinic or hospital sees enough patients to answer some of the fundamental research questions about it. Research needs a population and each site has a fraction of one.

The obvious answer is to pool the data. The reason it rarely happens is that the barriers aren't always technical. Every participating site sits under its own institutional governance, its own national reading of data protection law, its own ethics approvals and its own clinical systems. Everyone agrees pooling is a good idea but it's hard to commit to that without knowing exactly what they're agreeing to.

So the real problem isn't just building a database. It's building something that institutions in nine (and growing) different countries can each say yes to, and then keeping it true as sites, staff, funders and regulations change underneath it.

What I built

I lead the technical side of the programme. In practice that means sitting between the people who need the data and the people who can build it: patients, clinicians, allied health professionals, academic researchers, data scientists, industry partners and the development team. Turning what they collectively need into something that can be built, funded and approved.

The data model is the first hard part. Agreeing what gets collected, in what form, with what definitions, across sites that record things differently in different languages and were never designed to interoperate. The schema isn't the difficulty. Getting agreement on the schema, and keeping it current as practice changes, is.

Infrastructure is the bulk of it. The platform has to take in a lot more than clinical records: imaging, genomics, biomarkers, neuro-electric signal and data from remote monitoring, arriving from systems that were never built to talk to each other. Some of it is collected prospectively and some already exists in registries going back years. Those are two quite different engineering problems with the same name.

Then there's where curated data lives, who can reach it, and under what conditions. A trusted research environment handles storage and access, which isn't the same thing as capture. Confusing those two is one of the more expensive mistakes available here, because the controls a researcher needs to query pooled data are nothing like the controls you need at the point a clinician enters it.

Then governance. Data protection impact assessments, data sharing agreements, and the access model that lets researchers work with pooled data without any institution losing control of what it contributed. This is the work that decides whether the platform is usable at all, and it's usually treated as paperwork by people who haven't tried it.

I also write the technical half of funding applications. Research programmes are funded on scientific merit, but the infrastructure has to be costed, justified and credible or the science doesn't get delivered. Platform architecture, infrastructure costing, and the delivery case underneath the proposal.

Where it is now

Precision ALS is a €10 million programme, half from Research Ireland and half from industry, led by ADAPT at Trinity College Dublin and FutureNeuro at RCSI. It runs with TRICALS, Europe's largest ALS research consortium, and collects data at nine TRICALS sites across Europe. The platform also holds historic data from roughly 22,000 patients.

That data now sits somewhere researchers can actually work from. Less visibly, it comes with the governance and contractual scaffolding that lets them do their research, which is the part most multi-site data initiatives never get past.

What's next

The framework was designed from the start to be modular and transferable, so it can be adapted to other diseases facing the same problem. ALS is a good place to prove that, and we have a work package focused on MS as part of the modular setup.

Most of what comes next is depth rather than breadth. More sites, more data types, and continue to build governance model that holds as the programme grows and includes more and more partners and sites.

Why I like this work

None of this is hard in the way software is usually hard. It's hard because correctness is the entry requirement rather than the goal. The system has to stand up to legal, ethical, institutional and clinical scrutiny at the same time, and any one of those failing makes the rest less useful.

I also like that the constraint is other people. Most of the challenging problems here are solved by getting great people in great institutions to agree on a definition, and then writing better code to address that need. That's a different skill and it's the one that actually moves this work forward.