One goal of the Product team at Lindus Health is to help sponsors, clinicians, and clinical operations staff manage trials more efficiently.
The reality is that every clinical trial is unique in its objectives. Every therapeutic area and the corresponding clinical trial will have custom requirements, and each site staff engaged in a trial will want our product to fit the habits and quirks of their research practice. As sponsors will know, with many CROs configuring an existing feature (let alone implementing a new one) can take months and cost a pretty penny.
At Lindus Health, we pride ourselves in our ability to move fast and add new functionality without causing any trial delays. Implementing a new feature across our products to accommodate a slight change in trial configuration requires a thorough understanding of the existing codebase and the implications of adding that feature. So how do we ensure our suite of products is ready at a moment's notice to accommodate the changes required by the protocol?
Well, there are several viable solutions. One solution is to specialise in a small subset of complementary therapeutic areas, for example, in trials that require only ePRO patient diaries collected remotely. A tempting but unfavourable approach that goes against our mission statement – to accelerate trials for ALL healthcare pioneers.
Another is to build a productised offering to serve a specific industry segment, for example, patient recruitment and onboarding - a solution which prevents us from delivering end-to-end clinical trials in-house.
At Lindus Health, we’ve decided to go the path that ultimately delivers the most value to Patients and Sponsors alike. We’ve decided to build our products so that they minimise the amount of time from onboarding a new Sponsor to preparing a regulatory submission. To deliver this across the entire trial lifecycle requires intense prioritisation.
Our chosen strategy requires us to be flexible by design and ruthlessly prioritise what we will build. Our approach is to assign guiding principles to how we prioritise features in our roadmap. This framework has three levels.
These features typically take precedence over others, and we are more likely to deploy time, people and resources to ensure our ClinOps team can comfortably prepare for the trial to start.
We recognise that we will have to rewrite and rethink these over time. For example, we’ve built an ePRO scheduling tool that tracked which patients were overdue on surveys and withdrew them if patients were unresponsive for a long time. We used the overdue logic but removed the automatic withdrawals based on ClinOps feedback.
We identify these features as relevant and applicable to the broader clinical trial management. These include mainstay features like adverse event reporting that we will use in virtually every clinical trial we run.
An upcoming clinical trial does not necessarily require these features, but they are essential to our product functionality. We use this prioritisation level to be creative and experiment with building great user experiences. You can read more about a specific feature in a blog post by one of our software engineers.
Of course, frameworks are only helpful if we use them. We want to strike the right balance between forcing a framework and having a valuable mechanism to help us make better decisions. Over time we’ve observed that the boundaries between these levels are often blurred - but having a framework on which we can build helps us to guide our decisions during planning and roadmap meetings.
All of this helps us build one product to rule all clinical trials, and deliver on our mission of accelerating trials for biotech and healthtech pioneers.
Discussing DTx challenges and go-to-market in the UK with Charlotte Lee-Sinclair (ex-Big Health)
A fireside chat, this time by an actual fire! Our conversation with Dr Charlotte Lee-Sinclair is a must-read on DTx challenges and the road to go-to-market in the UK. Read here.
Debunking the 3 biggest myths about decentralised trials
You've probably heard of decentralised clinical trials, but there are a lot of myths out there. Here we debunk the 3 biggest myths.
Product Clinic #6: Releasing, Fast and Slow
Depending on your background, our 6 to 8 week product release cycle will evoke one of two reactions. If you work in the clinical space: Woah, what an incredibly fast release cycle! But if you work in a typical SaaS startup: How quaint, I release 3 times a day! Heard of Daniel Kahnemann's bestseller Thinking, Fast and Slow? Well, there is our inspiration!