Clinical Trial Systems
eSource and automation
Consulting, Project Management
Requirements gathering and analysis
Requests for Information (RFIs)
Requests for Proposals (RFPs)
Vendor selection processes
Audit hosting, privacy, security etc.
Pricing and contract negotiations
Implementation strategy and plans
Overseeing onboarding projects
Handover to implementation teams
Quality systems for software development and implementation
Product documentation
Tech Talk
When launching your new software product, it’s important to ensure it is thoroughly documented, not least for the specialists and end users for whom it will be their ‘daily driver’.
There are several other important stakeholder groups that stand to benefit, not least, the Sales and Marketing teams who need to address questions from prospective customers during initial enquiries and later during more intensive due diligence assessments. If you can quickly find or ‘point to’ the answers to critical questions it immediately engenders confidence in the supplier.
ESource systems not only help clinical staff capture information reliably and efficiently, they also make it accessible immediately to all authorised and interested parties.
They should also be able to present it in a way such that it is easy to review and to spot trends. We should be able to start with a 10,000 ft / 3000 m view, and then drill down if we see something interesting. We need study level visualisations (totals, summaries), the same for cohorts, and ideally for individual participants.
How do we help the clinical teams, the investigators and the monitors see the wood amongst the trees, separate the wheat from the chaff and distinguish the signal from the noise?
We have so many communications channels with friends and family, work colleagues and customers, it’s hard to keep track of it all.
In business, I am keen to use Client (or Customer) Relationship Manager (CRM) software tools. There are many such systems out there, with perhaps the biggest and most expensive (?), being Salesforce. As the name suggests, it is beloved by sales teams needing to track leads, opportunities and deals, and manage the sales pipeline.
My use case is simpler - to keep a timeline of my email conversations with a prospect, current or past customer. When did we last ‘chat’? What was it about? What was the outcome?
I love getting email from my friends and colleagues, but how much of the content has semantic value?
How much is signal? How much is noise?
I have worked with customers selecting eSource solutions for early phase trials, with very specific requirements of the audit trail.
This requirement is presented as a need for a system to audit (record) every keystroke, and by implication every change or correction you make whilst entering data - such as backspacing and correcting your own typos. Essentially the application would be required to act as a ‘keylogger’.
The requirement has been presented as a European Medicines Agency (EMA) regulation.
Somewhat unhelpfully, it is very vague as to which regulation.
I have an email provider, I might have a customer facing project management system, a customer support platform and tools to manage software product development.
Through many of these tools, the one common thread is a person.
That person could be a prospect that becomes a customer, that becomes a user.
That user is probably going to need support, and may offer feedback and request product enhancements or file bug reports.
I have reworked an old presentation that I sweated over profusely at the time, staying up late and sober to finish it off, whilst my colleagues were having one last drink.
It made sense to me, but I am not sure it made sense to anybody else.
I think I struggled, not being a data scientist, but being familiar with the problem space.
Things have moved on surprisingly quickly since that day in Chicago in 2017 with analytical tools such as as R, Python and Jupyter becoming trusted and more prevalent.
So I have had another go and have tried to strip it down to the basics.
I am a huge fan of eSource & automation software in Early Phase (‘Phase I’) trial settings and have been working with them for more than 20 years now.
In early articles I have written about eSource Stakeholders, What is eSource and how is it different to EDC?, and eSource Systems - what’s included?.
I do have a bias in that almost all my experience has been working in, or with, Contract Research Organisation (CRO) clinical pharmacology research units conducting commercially sponsored clinical trials.
I am not trying to put smaller, academic sites off from going paperless - you should!
As fast as you can!