Clinical Trial Data Platforms
Systems that move, process and track study data end to end, with the audit trail built in, not bolted on.
Software engineering for pharma and life sciences
Software that stands up to scrutiny.
We build scientific software and clinical data platforms for pharmaceutical teams, with 7+ years of US life-sciences delivery behind every engagement.
DiligenceFidelityConfidence
- 7+yrsof US life-sciences delivery
- Pharmaand life-sciences focus
- AWSnative architecture
- Full stackReactPythonRSAS
What we do
Engineering for the people doing the science.
From the first data file to the final audit trail, we build the systems pharmaceutical teams rely on every day.
Scientific Software Development
Applications for the people doing the science: modelling, simulation and analysis workflows with an interface a researcher will actually use.
Research Computing Environments
Multi-language environments where teams run R, Python, SAS and SQL side by side, provisioned and managed for them.
Cloud & DevOps Engineering
AWS architecture, containers, Kubernetes, infrastructure-as-code, secrets and access management.
Full-Stack Application Development
React and React Native front ends over Python and .NET back ends, on PostgreSQL or SQL Server.
Automation & Internal Tooling
CLIs, APIs, scheduled jobs and dashboards that remove the manual steps nobody should still be doing.
Our work
Systems we have built, and the problems they solved.
Each engagement starts with a real pain point in a study team’s day. Here is what we built, what was getting in the way, and what changed.
Clinical trial software
Clinical trial data management platform
What it does
A browser-based platform for clinical study teams to move, process and track study data. Configurable pipelines ingest from any source (CRO extracts, lab feeds, EDC exports) and route data through processing steps without anyone writing a script. Orchestration triggers jobs, manages file transfer tasks, sends notifications on every state (info, warning, error), and records a complete audit history of each task, configuration change and data movement. Existing SAS and R code plugs directly into the pipeline, so prior investment in edit checks, safety outputs and analysis datasets keeps working.
Pain points addressed
- Every new data source needed custom scripting, so study teams waited days or weeks to see their own data
- Manual file movement left no reliable audit trail, which becomes a problem at inspection
- Programmers spent their time on data plumbing instead of analysis
- No single view of what ran, when, by whom, or whether it succeeded
- Folder and permission provisioning handled by hand, study by study
What changed
- Time to first file import drops from days of scripting to minutes of configuration
- New sources onboarded without programming
- Every action audited automatically, with no separate documentation effort
- Repeatable pipelines remove the rework between studies
- Study teams self-serve instead of queuing behind IT
Pharmacometrics · current engagementDraft: project details pending
Modelling software for pharmacometrics
What it does
Purpose-built software for a pharmacometrician’s day-to-day work: a workspace organised around how modelling is actually done, from preparing analysis-ready data through to running, tracking and reviewing model work, in an interface designed for scientists rather than for programmers.
Pain points addressed
- Modelling workflows held together by scripts, spreadsheets and folder conventions
- Run history that is hard to reconstruct after the fact
- Results that are difficult to reproduce months later
What changed
- One workspace instead of a scattering of tools and files
- A clear record of what was run and why
- More of the scientist’s time spent on the science
Research computing
Multi-language research computing studio
What it does
A browser-based studio where researchers write and run SAS, Python, R and SQL from one interface against shared compute, with no local installs and no per-machine setup.
Pain points
Environment drift between analysts. Code that runs on one machine and not another. Analysts blocked waiting on IT for installs. Cross-language work split across disconnected tools.
What changed
Analysts are productive on day one instead of after a setup cycle. There is one environment to maintain instead of many, and cross-language work happens in one place.
For a top global pharmaceutical company
Role-based provisioning automation
What it does
Command-line tooling that reads role-based security definitions and provisions folder structures and permissions across a large research estate.
Pain points
Manual provisioning was slow, inconsistent and error-prone. Access mistakes carry compliance consequences. Onboarding a study or a user meant a ticket and a wait.
What changed
Provisioning runs as one command instead of a manual checklist. Permissions match policy by construction, and structure stays consistent across every study.
Python · Observability
Redshift usage monitoring dashboard
What it does
A Python service for a pharma client that polls Amazon Redshift for live connections and query state (running, blocked, completed, failed), turns it into charts, and emails an admin dashboard on a schedule, no login required.
Pain points
Cluster health was only visible by hand-querying system tables. Blocked queries and connection saturation went unnoticed until study teams complained, with no historical view of usage.
What changed
Admins get proactive visibility in their inbox instead of a portal to check. Issues surface before they affect study teams, and usage trends now inform capacity planning.
React Native · Field sales
Field sales mobile app
What it does
A React Native app that gives on-site sales representatives secure, offline-first access to the patient and visit information they need in the field, syncing back once connected.
Pain points
Reps relied on printouts, memory or a spotty connection to look up information on site, with no reliable way to capture visit data while offline.
What changed
Reps work the same way with or without a signal, and data captured in the field lands back in the system automatically instead of via manual re-entry.
SAS · Cloud storage
Provider-agnostic SAS storage macros
What it does
A SAS macro library exposing one create/read/update/delete interface for cloud object storage, with adapters underneath for AWS S3, Azure Blob and Google Cloud Storage.
Pain points
Programs were hardwired to one vendor’s storage API. Multi-cloud or cloud-migration work meant rewriting SAS code, and programmers needed vendor-specific knowledge to touch it.
What changed
Programmers write to one macro interface regardless of provider. Moving between clouds, or running on more than one, needs no changes to study programs.
CDISC SDTM · Clinical data standards
SDTM mapping tool
What it does
A tool that maps collected clinical data into CDISC SDTM domains, applying controlled terminology and structural rules on the way to submission-ready datasets.
Pain points
SDTM mapping was done with one-off scripts per study, so terminology and structure were applied inconsistently and submission prep was slow and error-prone.
What changed
Mapping is consistent and repeatable across studies, with less bespoke programming per study and a faster path to submission-ready output.
Python · Reusable component
Data ingestion pipeline module
What it does
A reusable ingestion module that parses, validates and lands files from CRO extracts, lab feeds and EDC exports into a common shape before downstream processing, shared across pipelines rather than built per study.
Pain points
Every new source format meant one-off parsing code. Validation and error handling were duplicated, and inconsistent, across pipelines, so failures were hard to trace.
What changed
New source formats are added by configuration, not new code, and validation and error handling behave the same way everywhere the module is used.
Ansible · Terraform · Apptainer
Infrastructure automation for research computing
What it does
Infrastructure-as-code and configuration management with Terraform and Ansible, plus Apptainer containers for portable, reproducible compute environments on shared and HPC-style research infrastructure.
Pain points
Environments were built by hand and drifted between servers. Root-requiring containers were not viable on shared research infrastructure, and infrastructure changes were untracked and hard to reproduce or audit.
What changed
Environments are defined as code, version-controlled and reproducible. Apptainer containers run without root, so they fit HPC and shared research computing policy, and infrastructure changes are reviewable like any other code change.
React · R package validation
R package risk-scoring dashboard
What it does
A React front end presenting automated risk and quality scores, maintenance activity, test coverage, community adoption, for R packages under evaluation for use in a validated environment.
Pain points
Deciding whether a package was safe to use was a manual, ad hoc review, with criteria applied inconsistently across teams and no lasting record of why a package was approved.
What changed
One place shows a package’s risk profile before adoption, giving teams a consistent, defensible basis for approval and an auditable record of what was evaluated.
How we work
A simple, disciplined way of working.
Four stages, the same every time. It keeps projects predictable and keeps your QA team comfortable.
-
01
Discover
We start with the workflow, not the technology: who does the work today, where it stalls, and what an auditor would need to see.
-
02
Build
Short iterations with working software in front of your users early. Code is reviewed and decisions are written down.
-
03
Harden
Access control, secrets management, logging and audit history verified before anything goes near production data.
-
04
Support
We stay on after go-live: monitoring, enhancements and the small fixes that keep a system trusted.
Why Dilifi
The name is the promise.
Diligence + Fidelity, delivered with confidence.
Diligence
Requirements traced, code reviewed, decisions documented. Nothing ships unverified.
Fidelity
Your data and your science arrive intact. Lineage, reproducibility and traceability are part of the design from the first day.
Confidence
A result your team, your QA group and your auditor can all stand behind.
Technology
A proven stack, chosen for the job.
We are equally at home with the open-source and commercial tools life-sciences teams already run.
Languages
- Python
- R
- JavaScript
- C#
- C / C++
- SQL
- Bash
- PowerShell
- HTML / CSS
Front end
- React
- React Native
AWS
- EC2
- EKS
- ECR
- S3
- Lambda
- Step Functions
- RDS
- Transfer Family
- Secrets Manager
Platform
- Docker
- Kubernetes
- Ansible
- Talend
Data
- PostgreSQL
- MS SQL Server
- Amazon Redshift
- Amazon RDS
Scientific
- SAS
- RStudio
- Jupyter
- Dash
- Flask
Quality
Built for regulated environments.
Pharma work has a different bar. We build with it in mind: audit history on every action, role-based access control, secrets in managed stores, traceable data movement, and reproducible environments. Seven years inside that constraint is why it is the default rather than an afterthought.
Audit history on every action
Who did what, when, and to which data, recorded automatically and reviewable in the interface.
Role-based access control
Permissions follow roles and policy, so people see the studies they should and nothing else.
Secrets in managed stores
Credentials never live in code or config files. They sit in managed secret stores with controlled access.
Traceable data movement
Follow a file from where it arrived, through each processing step, to where it ended up.
Reproducible environments
Infrastructure and environments defined as code, so what ran last quarter can be rebuilt today.
Working to a specific standard?
Tell us what your QA team needs to see and we will build to it.
Talk to us
Leadership
Safi Ahmed
DirectorDilifi Tech is led by Safi Ahmed, who builds full-stack systems end to end: React and React Native front ends, Python and .NET back ends, the databases beneath them and the AWS infrastructure they run on. His work has centred on clinical study data management and scientific computing platforms. He holds a Master’s in Management Information Systems.
Contact
Let’s talk about what you’re building.
Tell us about the study, the workflow or the system. We will come back to you personally.