every cohort versioned, every analysis showing its own run stateNames anonymized
The Problem
Real-world data is where life-science organizations find their evidence — but getting answers from it was a months-long, engineer-dependent process. Every market definition, every cohort, every patient-flow question required custom programming, and every team’s answer came back slightly different.
The result: analytics bottlenecked behind an engineering queue, and no single consistent view of the data across the organization.
The challenge: give non-technical teams the expressive power of a data engineer — without a single line of code.
The Approach
I designed the platform as four connected modules — Codeset, Cohort Builder, Attributes Definer, and Insights — each turning a formerly technical step of the analytics pipeline into a direct-manipulation interface. Attributes Definer carries seven analyses on its own: comparison cohort, compliance, epidemiology, HCRU, line of therapy, persistence, and physician speciality.
The core bet: the complexity of patient-level analytics lives in a small number of repeatable structures — which codes define a market, which rules define a cohort, how patients move between states. Design those three structures well, and the coding disappears.
On evidence: I designed against Trinity’s own analytics and real-world-evidence consultants — people who build cohorts professionally — standing in for the non-technical teams the product is actually for. For a no-code tool that is close to backwards. The entire premise is that someone without a data background can define a cohort unaided, and my evidence base was people with a data background. The closing section names the test that matters.
Evidence base — internal SME review · domain-expert working sessions · stakeholder walkthroughs. No direct end-user testing.
1 / 3Pick the analysis, see the cohort, tune the method
Key Decisions
No-code market definitions
Markets built from a 4M+ term medical library through searchable, composable controls — replacing hand-written code lists with an interface any analyst can drive.
Cohort rules as visible, editable logic
Inclusion and exclusion rules expressed as structured, readable logic — teams see exactly what defines a population, challenge it, and iterate without re-engaging engineering.
Source-agnostic by design
Claims, EHR, and lab data flow through the same interaction model — learn the platform once, interrogate patient-level data from any source.
A cohort is a versioned artefact, not a saved file
Every cohort carries a version history with one marked default. In evidence generation the cohort definition is the finding — if you can't say which version produced a number, the number isn't defensible. Versioning turns a working file into an auditable record.
Run state on the surface
Analyses take real time and genuinely fail. Rather than hide that behind a spinner, every analysis shows its own state — succeeded, failed, or not yet run — against the version it ran on. A failed run is a normal condition to design for, not an error case to apologise for.
No-code has a boundary, and it should be visible
Defining a market or a cohort is genuinely no-code. Defining a line of therapy is not — it needs grace periods, overlap windows, head/tail thresholds. I chose to expose those as labelled, explained parameters with sensible defaults rather than bury them. The honest claim isn't that the platform removed expertise; it's that it removed the engineering queue between the expert and their answer.
Expert-built analytics as the baseline
Not a blank canvas: the platform ships expert-built analytics that deploy in weeks. Teams start from a trusted foundation and customize, instead of building from zero.
Outcome
Months → weeksanalytics that once required engineer-dependent custom builds now deploy self-serve
4M+term medical library made searchable and composable through no-code controls
4connected modules, with seven analyses inside Attributes Definer
1consistent view of patient-level data across the whole organization
The platform shifted real-world evidence analytics from a service the organization waited on to a product the organization uses.
What I’d Validate Next
A no-code tool validated by people who can already code is the weakest part of this project’s evidence. These three tests would fix that, in priority order.
Can a non-technical user finish a cohort unaided?
This is the single claim the product rests on and the one I have the least evidence for. Task-based testing with the actual target audience, measuring completion without assistance — not satisfaction, not preference, completion.
Is the no-code boundary in the right place?
The line-of-therapy parameters are where I drew the line between no-code and expert-configurable. That was a judgement, not a finding. I’d push real analysts through progressively harder definitions to see whether the boundary lands where they actually hit their limit — or whether I put it somewhere convenient for the build.
Can people find the right term in four million?
A searchable library is only as good as its search, and a 4M+ term count is a liability as easily as an asset. I’d test term-finding as a task in its own right, with known-answer prompts, before treating the library as a feature rather than a haystack.
