Written by:
Last Published:
29 October 2026
•
Clinical trial software is any application used to plan, run or analyse a clinical trial. To build or evaluate it well, start with what it will hold: records that support trial data or a regulatory submission, or personal data. That answer decides how it should be validated, secured, hosted and audited, and what it costs when you get it wrong.
This guide is for CTOs, heads of product and technology leads at contract research organisations (CROs), sponsors and HealthTech vendors. If you build, buy or assess clinical trial software for CROs, it helps you size three things: the regulatory questions, the cost of getting them wrong and the build-or-buy decision.
Our lens is a real project. Aurora Analytica partnered with us to build the Geo Matrix Decision Engine, a clinical trial scenario planning tool that helps CROs simulate scenarios before committing to real ones. We cover what the rules say, which technical decisions deserve a second look and what a bad call costs.
A word on scope. We are not claiming that the Geo Matrix holds any certification. We are not describing what data its users load into it, and we are not publishing outcome figures for the project. We use it to show where the questions begin. None of this is legal advice, and your regulatory counsel gets the last word.
Regulation starts where clinical trial software creates, changes or stores records that support trial data or a regulatory submission, or where it handles personal data. That reach covers everything from electronic data capture to scenario planning. Planning tools often sit just outside that line, but not always.
Picture a customs border. A tool can operate right beside it all day and never cross. Load it with the wrong cargo, such as records that feed a submission or participant-level data, and it is suddenly in the inspection queue. The code did not change. The cargo did.
We use one question to organise the rest of this article, and we call it the cargo test. What cargo does the tool carry? How does that cargo cross in and out? And what paperwork proves it was handled properly?
Cargo is the data and records. Crossings are logins, integrations, imports and exports. Paperwork is validation, audit trails and documentation.
Aurora Analytica asked us to build the Geo Matrix Decision Engine, the first decision engine in its Aurora Suite. It lets CROs run scenarios with custom data and see the results on a world map, so they can predict outcomes virtually before real-world implementation, for example when answering requests for information and requests for proposals (RFIs and RFPs).
The wider Aurora Suite is a web application that covers areas such as trial design, country and site selection and clinical operations. Aurora Analytica developed 11 Decision Engines that perform more than 14 assessments for planning, designing and running clinical trials. The Geo Matrix was the first.
Day to day, the engine offers:
Under the hood, the front end uses Next.js, React and Redux (plus Papa Parse for CSV handling), with authentication through Auth0 by Okta. The back end runs on Nest.js and Prisma, with PostgreSQL as the database and AWS for hosting.
We worked through a minimum viable product (MVP) approach, where product owners, developers and UX/UI designers agree the core features first. Under our Managed Project Working Model, we supplied the whole team: front-end and back-end developers, designers and project managers. You can read the full story in the Aurora Analytica case study.
What does a tool like this do? It moves a costly decision earlier, to a point where changing your mind is cheap. A simulation does not replace a trial. It helps you decide which trials are worth running.
Delay is the expensive part. The Tufts Center for the Study of Drug Development (Tufts CSDD) puts the direct cost of a day of delay at about $23,700 for a Phase II trial and $55,700 for Phase III, plus about $800,000 a day in potential lost prescription sales. Software is one factor among many, but you control it.
Those figures use 2023 US dollars and draw on sales data for 645 drugs and budget data for 447 trial protocols. Treat them as benchmarks, not forecasts.
Planning decisions carry similar weight. A 2012 Tufts CSDD study, described in Applied Clinical Trials, covered nearly 16,000 sites in 151 global Phase II and III trials run between 2008 and 2010. It found that 11% of sites that were ready to recruit enrolled no patients, and that 41% of those activated sites missed their enrolment targets. That is why clinical trial feasibility and site selection get so much attention, and why clinical trial simulation and clinical trial analytics tools exist.
For a CEO, COO or CFO, our view of the value case is simple. Good tooling earns its keep in three ways:
Four decisions matter most: how users are authenticated and what each role can do, where data is hosted and who is responsible for it, how data enters and leaves the system, and what the system records about changes. Each is cheap to design early and costly to retrofit. Regulators and customers ask about all four.
The Geo Matrix handles authentication through Auth0, a managed identity provider. Identity is a specialist job, and few product teams should build it from scratch.
The guideline on computerised systems and electronic data in clinical trials from the European Medicines Agency (EMA) expects checks that only authorised individuals have access to a system, with unique usernames, individual accounts and least-privilege access. In the US, 21 CFR Part 11 sets related requirements. That is the Food and Drug Administration's (FDA) rule on electronic records and signatures, found in Title 21 of the Code of Federal Regulations (CFR). It calls for limiting system access to authorised individuals, and for electronic signatures that are unique to one person.
Using a managed provider moves the work. It does not move the responsibility. The EMA guideline is blunt on this point: relying on a service provider does not hand over responsibility for data integrity, security and confidentiality.
Hosting on AWS is routine, and the EMA guideline treats cloud and on-premises systems alike. The same expectations apply, and the responsible party must make sure the provider is qualified. The useful mental model is the AWS shared responsibility model: the provider secures the cloud itself, and you remain responsible for what you put in it and how you configure it.
For a relational store such as PostgreSQL, add one more question early. What is the retention rule for each kind of data, and does deleting it in one place leave a copy somewhere else?
Any CSV pathway is a border crossing of its own. For a tool with import and export, we would ask these questions in a design review:
(Those are questions for any CSV workflow. They are not a verdict on the Geo Matrix.)
An audit trail is the system's record of who created, changed or deleted data, and when. This is where regulated work is least forgiving.
ICH E6(R3), the International Council for Harmonisation's good clinical practice guideline (third revision), expects changes to source records to be traceable without obscuring the original entry. The EMA guideline is more specific: an audit trail should be enabled for the creation and modification of all electronic data, and normal users should not be able to switch it off. Part 11 asks for secure, computer-generated, time-stamped audit trails, although FDA's 2003 guidance says it will use enforcement discretion on that requirement and on validation, and recommends a justified, documented risk assessment.
For a scenario engine, our view is that reproducibility is the practical version of this. If a result helps justify a decision in an RFP, someone will eventually ask which inputs produced it. A tool that can answer that is easier to trust, and easier to buy.
Four sources do most of the work: ICH E6(R3) for good clinical practice, the EMA guideline on computerised systems for EU trials, FDA's 21 CFR Part 11 for electronic records and signatures, and the General Data Protection Regulation (GDPR) for personal data. Which reach your software depends on where it sits, which records it creates and who uses it.
| Source | What it covers | What it means for software |
|---|---|---|
| ICH E6(R3) | Good clinical practice, including data governance and computerised systems. Effective in the EU from 23 July 2025 (principles and Annex 1). | Systems should be fit for purpose, with validation proportionate to risk. Changes to source records should be traceable, and access should be secure and attributable. |
| EMA guideline on computerised systems | Computerised systems, including software as a service, used to create or capture electronic clinical data or to control other trial processes. In application since 9 September 2023. | Applies to sponsors, investigators and their service providers. Covers validation, audit trails, user management and cloud providers. |
| 21 CFR Part 11 | Electronic records and electronic signatures under FDA record requirements, and electronic records submitted to FDA. FDA reads its scope narrowly. | Validation, secure audit trails, access limits and unique electronic signatures. |
| GDPR | Personal data, with data concerning health treated as a special category under Article 9. | Applies when you or your customers process personal data within its territorial scope, including trial participants' data and, yes, your own user accounts. |
In the EU, the Clinical Trials Regulation has applied since 31 January 2022, and trials approved under the old Directive had to transition by 31 January 2025.
So does all of this apply to a planning or decision-support tool? Usually not directly, in our view. Records used purely for internal planning are often not the records an inspector asks for, although feasibility and site-selection decisions can end up in the trial master file.
But your customers carry the responsibility for the systems they use, so they will ask you to help them evidence it. Vendor questionnaires borrow the language of these rules, whether or not the rules formally reach you.
The GDPR deserves a separate mention. Even a tool that never sees a participant's record holds personal data: user names, work emails and login activity all count.
Buy when a mature product already does the job and your edge lies elsewhere. Build when the workflow is specific to you, as with scenario planning on your own data, or when you need to join several systems together. Either way, check how the tool fits your existing trial systems, and keep validation and vendor qualification in scope.
Most trial technology stacks include four kinds of system worth knowing by name:
CRO software for scenario planning or analytics usually sits beside these, not instead of them. That makes integration the question that decides whether it fits. If it can read from or write to your EDC or CTMS, the integration becomes another crossing to control.
When you compare options, whether commercial products or custom clinical trial software development, we would score each against six criteria:
Vendors price in different ways, for example by study, site, user or subscription, so ask each for a full breakdown. A custom build is priced on scope. Whichever you choose, count validation and change control as part of the cost, not as extras.
If you decide to build, start small. Pick one workflow, agree the core features with the people who will use them and ship a first version, as the Aurora project did with its MVP.
Before you write code, settle what the software will hold and which records it creates. Then work through access, hosting, data movement, audit and validation in that order. The list below turns the cargo test into questions a design review can answer in an hour.
It is any application used to plan, run or analyse a clinical trial. The main types are EDC, CTMS, eTMF, IRT, patient-reported outcome tools and analytics or decision-support tools such as the Aurora Analytica Geo Matrix. How strictly each is regulated depends on the records it creates and the data it holds.
There is no single best product. The right choice depends on your trial phases, your region, the systems you already run and how much validation support you need. Compare options against regulatory fit, integration, validation support, hosting, auditability and total cost, using the six criteria above, and ask each vendor for evidence, not promises.
An EDC is where clinical data is recorded. A CTMS is where the trial is run: sites, milestones, monitoring visits and budgets. Many sponsors and CROs use both, often alongside an eTMF for essential documents.
It depends on scope, so there is no honest single figure. Five things drive most of the cost: the number of user roles, the number of integrations, the depth of validation, the hosting model and whether you license a product or build your own. Count validation, change control and support from the start.
Start by defining what the software will hold, because that sets the regulatory scope. Design access, audit trails and integrations from day one, plan validation alongside development and add modules only once the foundations are stable. The build-or-buy section above covers how to start small.
If it is a computerised system used in a regulated trial process, yes, and the responsible party stays accountable even when it relies on vendor documentation. ICH E6(R3) points to validation that is fit for purpose and risk-based, so the depth follows the risk. A scenario-planning tool needs a documented rationale for its depth. A system capturing trial data needs more.
Not automatically. Part 11 covers electronic records created, changed or stored under FDA record requirements, and electronic records submitted to FDA. FDA's own scope and application guidance says it will interpret Part 11 narrowly, and that electronic records not required by FDA's underlying rules are not Part 11 records. A tool whose outputs never become such records may fall outside it. For clinical investigations, FDA's questions-and-answers guidance on electronic systems and records from October 2024 is the current reference.
If outputs feed a submission, or the tool is used inside a regulated process, the answer changes. Confirm with your regulatory team.
Yes. The same expectations apply as for on-premises systems, so what matters is proof: a qualified provider and a written split of who does what. Responsibility for data integrity, security and confidentiality stays with you.
Yes, wherever it processes personal data. Participant data is the high-risk case, because much of it concerns health and is a special category under Article 9. The names, emails and login records of your own users count too, so most tools are in scope.
Clinical trial software is defined by what it holds, not by what it is called. Run the cargo test first: what the tool carries, how it crosses in and out, and what paperwork proves it was handled properly. The Aurora Analytica Geo Matrix shows how a planning tool sits close to regulated work, and why identity, hosting, data movement and audit trails are what reviewers check first. Delay is costly, so build or buy for fit, integration and validation, and document your reasoning, especially when the answer is "out of scope". Do that, and the customs queue gets much shorter.
If you are planning HealthTech software, or reviewing a product that sits close to a regulated process, we are happy to talk it through. Imaginary Cloud has been building healthcare technology since 2010, and our healthcare page lists more than 300 healthcare solutions delivered.
See how we work with healthcare teams on our healthcare technology solutions page. If your product also handles US patient data, our guide to HIPAA compliant software development covers the architecture checklist.
Ready to talk? Contact us and tell us what you are building. We will help you work out where the regulatory questions start and what a sensible first version looks like.
Alexandra Mendes is a Senior Growth Specialist at Imaginary Cloud with 3+ years of experience writing about software development, AI, and digital transformation. After completing a frontend development course, Alexandra picked up some hands-on coding skills and now works closely with technical teams. Passionate about how new technologies shape business and society, Alexandra enjoys turning complex topics into clear, helpful content for decision-makers.
People who read this post, also found these interesting:
.webp)
.webp)
