A clinical trials application built on MCP, layered AI and anonymisation by design

The challenge

The information needed to run a study well is scattered: the protocol PDF, ClinicalTrials.gov and EU CTIS registries, literature, site databases, vendor specs and the sponsor's own SharePoint. Teams stitch it together by hand. Generic chatbots are not an answer — they hallucinate, they cannot show where an answer came from, and they cannot be given protocol or patient-adjacent data without a governance model behind them.

This case describes the architecture we use to build applications of this kind. It is the same approach behind our own platform, Pragma Clinical.

Architecture

1. Sources through the Model Context Protocol

Each external or internal source is exposed to the application as an MCP server with a narrow, typed interface: a registry connector (ClinicalTrials.gov, CTIS), a literature connector (PubMed), a document connector for the sponsor's own files, and internal connectors for the application's own protocol analyses. MCP gives us one standard way to add a source, one place to log every call, and one place to enforce what a model is allowed to ask for. Sources are read-only unless a workflow explicitly grants a write.

2. Layered AI, not one big prompt

Separating the layers keeps each model task small and testable, makes failures visible (a wrong extraction is caught before it becomes a wrong conclusion), and lets us swap or upgrade a model in one layer without re-validating the whole system.

3. Anonymisation and data minimisation by design

• Pseudonymisation at the boundary. Direct identifiers in any uploaded document are detected and replaced with tokens before text reaches a model. The mapping stays inside the sponsor's tenant.
• Data minimisation. Each layer receives only the fields it needs; the reasoning layer never sees raw documents.
• No training on client data; zero retention at the model provider under a data processing agreement.
• Subprocessor discipline. Every AI vendor in the chain is named in the DPA. Adding a new model provider is a documented change, not a config toggle.

4. Traceability and audit

Every fact, every model call and every human decision is recorded: source, timestamp, model version, prompt version, reviewer. Records are immutable and exportable, and electronic signatures close reviewed artefacts — the pattern regulated users expect from 21 CFR Part 11 and EU Annex 11 systems.

Standards and practices

• GDPR — pseudonymisation (Art. 4(5)), data minimisation, EU hosting, DPAs and documented subprocessors.
• EU AI Act readiness — risk classification, human oversight, logging and transparency built in rather than retrofitted.
• 21 CFR Part 11 and EU Annex 11 — audit trails, controlled records, electronic signatures.
• GAMP 5 (2nd ed.) — risk-based assurance of the software itself; the AI layers are treated as components with their own verification.
• OWASP ASVS and OWASP Top 10 for LLM applications — prompt-injection defences, output handling, access control on MCP tools.
• ISO 27001-aligned operational practices for infrastructure, access and change management.

Delivery approach

1. Discovery. Which sources, which decisions, which users, which data classes.
2. Governance first. DPA, subprocessor list, data-flow diagram and risk classification are agreed before the first model call is written.
3. Thin vertical slice. One source, one question, end to end with traceability — reviewed by domain experts.
4. Expand by connector. Each new MCP source is added with its own tests and access rules.
5. Verification and handover. Documented assurance package, admin training, runbooks.