MetDRA: eight modules, one platform, built from a blank page
Pakistan had no indigenous clinical trials platform. I owned the product that became one, and decided what got built in what order.
The situation
Clinical research in Pakistan ran on two things: licensed foreign software priced for Western sponsors, or spreadsheets. The first consumed study margin and could not be configured for local regulatory reality. The second could not survive an inspection.
The decision to build an alternative was made before I came to the problem. What had not been decided was what to build, in what order, or how a small team's output could count as a credible regulated product.
MetDRA is now eight modules: electronic data capture, trial management, document management, randomisation and trial supply, imaging grading, subject logging, study budgeting and workforce management. It runs live studies across 25 or more international sites.
The connected trial workflow
Metrics Research describes MetDRA as a platform for sponsors, sites, CROs and SMOs that connects trial operations with electronic data capture. Its public product overview groups the platform around CTMS and EDC.
CTMS covers study configuration, participants and visits, document versions, safety events, staffing and budgets. EDC covers eCRF configuration, study publishing and data entry. Shared dashboards make trial progress visible across the two.
The product page also describes audit trails, role-based access, encryption and multi-factor authentication, alongside HIPAA and 21 CFR Part 11 compliance claims. These are the platform's published capabilities and claims; my own contribution is described in the roadmap, requirements and team sections below.
For a product demonstration, contact the Metrics Research team.
The decision that mattered most
The instinct on a platform this size is to build broadly, so every function has something. That produces eight half products and no usable system.
I sequenced the roadmap around one question: which module, shipped alone, lets us run a real study end to end?
The answer was electronic data capture. Trial management can be done in spreadsheets badly. Document management can be done in folders badly. Data capture cannot be done badly at all, because it is what an inspector examines and what a sponsor pays for.
So EDC shipped first, alone, and funded everything after it. Each subsequent module earned its place by removing a specific manual process that was already costing the business money, not by completing a feature matrix.
Leading the team that builds it
I lead a cross-functional team of twelve: three backend developers, two frontend developers, a UI and UX designer, a DevOps engineer, a QA engineer, a project manager, two IT staff and a clinical data assistant.
That composition is deliberate and it is unusual for a product this size in this market. Most teams building internal clinical software are three developers and a hopeful deadline. Having dedicated QA, DevOps and design means the platform can make a claim a regulated product has to make: that releases are tested, traceable and repeatable, rather than shipped and hoped over.
My job across that group is to be the single point of decision on what gets built and why. The project manager owns delivery and sequencing within a sprint. I own the problem definition, the priority order and the acceptance criteria, which keeps the two roles from blurring into each other and keeps the team from waiting on a committee.
The written artefact does a lot of work here. Requirements live in Confluence, one page per workflow, with the regulatory rationale attached to anything a developer might otherwise treat as optional. Epics and stories live in Jira with acceptance criteria written to be testable rather than aspirational. "The audit trail records the change" is not acceptance criteria. "Given a user edits a submitted value, when they save, then the system records old value, new value, user, timestamp and a mandatory reason" is.
The clinical data assistant inside the team matters more than the org chart suggests. It means every feature is checked against how a study actually runs before it reaches a developer, rather than after it reaches a site.
What the platform is actually for
Three audiences with conflicting needs, and almost every product decision is a trade between them.
Site staff enter data on unreliable connections between clinic appointments. They want fewer clicks and forms that forgive interruption. They will not read documentation.
Data managers and monitors want the opposite: complete audit trails, edit checks that fire early, query workflows, and proof of who changed what and when.
Sponsors and regulators never open the interface. They care whether the system holds up under inspection.
Designing for the first group at the expense of the second produces a product that cannot be used in a real trial. Designing for the second at the expense of the first produces a product nobody at a site will use. The craft is in finding the version that serves both.
Where it stands
The trial management module launched publicly at the Clinical Trials Summit of Pakistan 2026, demonstrated live alongside NUMS, Aga Khan University and the Drug Regulatory Authority of Pakistan. The platform was recognised internally with the Innovation Champion Award in 2026.
Each case study here goes deeper into one part of it.
Inside the platform
Inside this workflow
Real interfaces with demonstration data. Select a screen for a closer look.
The study at a glance.
Sites, queries and study progress in one operational view.
From protocol to working form.
Configure fields, branching logic and structured inputs.
Independent review starts here.
Configure grading workflows and assign independent readers.