eSource Systems - what’s included?
Introduction
eSource systems for early phase clinical trials have been around for a long time. My first direct exposure was over 20 years ago when working in a well known London Phase I site. The software had already been successfully deployed and was in widespread use at its sister unit in Berlin.
These systems have to be good at addressing the core needs of their users - being really good at capturing clinical trial data in real time at the bedside. They must be secure, they must be reliable and they must support and comply with GxP and other applicable rules and regulations.
The best of these systems will be standards-based (e.g. CDISC ODM), integrate with local safety labs and common medical devices and use automation to support efficiency and compliance.
The eSource solution I worked with in London was already so mature that the users and developers respectively had begun to request and deliver functionality in areas outside of the core space, such as revenue recognition and integration with a leading CRM for lead and opportunity tracking (the site was part of a CRO).
A significant challenge lies in front of eSource solution providers that aim to serve a wide and diverse market of different sites with different needs. Sites ranging from smaller more academic units to large ‘industrial’ sites that are embedded within multinational CROs. Where should they invest their finite resources to keep ‘most of the users happy most of the time’? Also, what should they be building to retain existing and attract new customers? Should they build new features themselves, or integrate with ‘best of breed’ off-the-shelf services?
If you integrate with off-the-shelf solutions, are those solutions ‘site friendly’, as opposed to be being ‘sponsor friendly’? Are they scaled to be affordable for single sites? Can they be designed, built, tested and deployed by the sites themselves quickly, in line with the short timelines we see for early phase trials.
What you usually get
Typical device and system integrations with a high-end eSource and automation platform for Early Phase Clinical Trials
A good eSource system should include most, if not all, of the following…
Recruitment / Volunteer Database
Study design, build and test tools
Real time data collection / activity scheduling
Trial medication administration tracking
Consent management and tracking
Barcode label creation and scanning
Sample processing and sample inventory management
Integrations - medical devices and services
Vital Signs / ECG / Telemetry
Messaging
Safety Labs
Participant recruitment website
APIs
Reporting / Exporting
Data standards - CDISC / SAS
Audit trail
What you don’t typically get
Functionality we might not see baked in to early phase eSource systems.
eConsent
I have worked with one eSource platform that had a great process for the management and tracking of traditional paper ICF versions and for blocking the capture of trial data until consent had been obtained. It also had an integration with an eConsent offering from one of the ‘big beasts’ in the space. But generally, we don’t see true eConsent baked in to the eSource platform. If you find one that does, this could be a deciding factor for shortlisting or selecting the system.
Participant Payment
In early phase clinical trials we have to pay participants to take part. This is based on ‘inconvenience’ and (often) some allowance for travel costs. It is certainly not to be so high as to be an inducement, and it is not related to any risk of participation and is always carefully assessed and approved by the IRB / IEC overseeing the trial so that the amount is proportionate.
eSource systems can generally be configured to report or export key data that supports the payment of participants, but I have yet to see an eSource system with first class functionality in this domain or integrations to payment processors or best-in-class apps.
Can you live without it? Is it a nice to have?
Trial Budgeting and Invoicing
As well as paying participants, sites have to charge sponsors for the services they provide. I don’t tend to see this offered out of the box with eSource offerings.
Arguably, eSource solutions could be used to help with costing a trial, but in my view you’d have to ‘sketch out’ the trial design comprehensively to do this, almost to the extent that you are building the trial, even before you have been awarded it.
What would be nice would be a way to do the ‘sketching out’ of the trial design in a very light and fast way, that could form the ‘stub’ of a future trial build, or at least a way to verify the design against the requirements, then the effort is not entirely wasted, it is partly re-used / re-cycled.
Note: I understand that pricing your services is a ‘cost of doing business’, but I just like to be as efficient as possible and follow the ‘write once, use many times’ approach.
On the invoicing side, this could lend itself to sites creating custom reports using read replica databases or reporting APIs, and tallying the actual participants screened, enrolled and completed and the actual numbers of procedures performed. This information can then be used in the creation of invoices or as a way to corroborate or justify them (internally or externally).
Bed Planning
High level capacity planning for your clinic.
Will you have enough beds to house the anticipated number of participants to run six different trials 12 weeks from now? Will you have enough IV pumps, oe enough ‘intensive care’ beds for first-in-man trials? Will you have sufficient staff with the right training to cover the work safely? What is your optimum bed occupancy? Do the wheels start to fall off the bus when you exceed 75% bed occupancy? Can you overbook in the knowledge that something will move? What happens if it doesn’t move and you are looking at 115% occupancy?
Sites already have this expertise, and I believe it is still a largely manual process.
As it stands, I don’t know of an eSource solution that has this baked in.
Perhaps the advent of ML and AI will bring some automated solutions to the fore.
Staff shift planning
Another one of the long standing holy grails of early phase clinical trials, and shares some of the data needs and problem constraints of the ‘Bed Planning’ requirment described above.
How many doctors, nurses, phlebotomists, research assistants, lab techs and pharmacists are you going to need to cover a busy PK day for a first-in-man study whilst also handling follow-up and outpatient visits for other trials? When do you need them most? What skills do they need? Which wards will they be assigned to? What studies will they work on? Is there an app for that?
There are third party software solutions (one I have seen) that will do a lot of this but they rely on a lot of ‘hand shaking’ with your eSource system to work.
Investigator Delegation
This is a tricky one and I have seen sites handle this in completely different ways.
The bottom up approach is where staff are trained in procedures described in their SOPs (perform an ECG, draw a blood sample from a cannula, take vital signs, take adverse event details) and trained in the use of the eSource platform. They are then given access to the production instance of the eSource system and can perform duties in alignment with their assigned system roles on any study after study specific ‘training’. This approach can work well when there are 200+ operational staff working at a site.
The top down approach adheres closely to what is standard practice with the use of EDC / eCRF systems (I use the terms advisedly), especially when there are small numbers of staff at site and/or only limited numbers of staff working on a protocol. Staff do protocol specific training and only then are they authorised by the investigator as a delegate, and added to the study in the eSource system.
In either case, delegation by the principal investigator is handled outside of the eSource system and monitors and auditors typically check to ensure that only delegated staff have worked on a trial and that the work that they did occured before authorisation had been granted.
It’s also the case that keeping track of paper delegation logs in large units is challenging.
I’d love to see an eSource solution address this need simply and effectively, perhaps by the introduction of a workflow where users can apply to the investigator to get added to an electronic delegation list and/or a study or training coordinator could complete a batch application on behalf of the users.
Staff Training
Most larger sites, especially CRO sites have learning management systems (LMS) already, and with most technologies we want to avoid duplication. We are looking for ‘single sources of truth’.
In an ideal world the LMS would push the necessary training transcripts into the eSource system. The eSource system would look for general and protocol specific training ‘tokens’ and delegation approval from the investigator before including the ‘resource’ (member of staff) in the pool that could be made available to the algorithms performing the staff shift planning.
Not holding my breath on this one.
TMF / Investigator Site File
I used to hear this request from time to time, especially in RFIs/RFPs, although I am not yet clear on the business benefit unless it is to store the site delegation log and/or site training records. I am not against building in a TMF / Site File feature into an eSource system, but I would say it is low priority.
eCOA
Patient diaries, rating scales and other patient reported outcomes. These are typically standalone applications and the data must be reviewed, reconciled and later ‘blended’ with the clinical data set outside of the eSource system. In my understanding, eCOA offerings are best suited to later phase multi-site studies and are priced accordingly.
I feel that a good proportion or eCOA requirements could be incorporated directly into the eSource solution directly and that this would add immediate benefit to a proportion of trials at most sites using eSource.
What some customers say they want
EDC / eCRF integration
If your site offers full ‘wrap’ services (like most CRO early phase sites), you are most likely to be able to provide data management and / or biostatistical analysis capabilities to your sponsor. Where this is the case, there should be no need to bridge eSource to EDC as the sponsor can monitor directly in the eSource platform and ask the CRO to produce SDTMs and ADaMs for the trial.
If you are a ‘clinical only’ site, I understand the challenges of sponsors insisting you use each of their preferred EDC / eCRF solutions.
Sites that find themselves in this position must currently, and counterintuitively, manually transcribe electronic data captured in one system to another - using the so called ‘meat interface’. We did this 20 years ago when I was working in Baltimore MD, as the night staff would open up the eSource application on one screen and the EDC application on another and transcribe between the two.
Crazy as it sounds, this was already better than capturing source data on paper. Most of the SDV could be performed remotely.
In an ideal world we would have a way for eSource platforms to export standards-based datasets that can be uploaded into sponsor EDC systems, but I have yet to see that work across all domains and between a range of platforms.
Pharmacy / Randomisation module
A good eSource system will support the production of comprehensive medication labels including barcodes for chain of custody management. Furthermore the system would allow for drug accountability and reconciliation and the production of reports to detail.
What’s debatable is the benefit or otherwise of being able to import blinded treatment allocation information, or ‘the randomisation’, into the eSource system. I’d argue there are some benefits to keeping it outside and merging the randomisation with the ‘clinical data’ once the trial is completed.
I have had sophisticated customers argue strongly in favour of it, and other equally experienced and sophisticated sites say they can manage just fine without it.
Build or integrate (buy)?
From the vendor’s perspective, there are arguments in favour of making a high value and frequently used feature part of the core product. If the feature is somewhat esoteric, and not likely to be used by many customers, then the argument for building something into the application is weak.
The vendor and the customer could screen the market to determine if the need has been met by a third party, and if that that party solution can be usefully connected with the eSource platform. As this is customer driven work then the vendor is going to charge you, and charge you more if you need it prioritised. If I am being honest, they won’t really want to do the work as they will be juggling many other priorities.
If the vendor has public APIs that allow for the consumption of eSource data, they are most likely going to encourage you to take this path and manage downstream integrations yourself without the need for the vendor to write custom features for you. They will want to take this work off the critical path to getting the core eSource system implemented.
Let the vendor focus on creating new features that will be useful to a wide range of users, adding additional APIs, maintaining and boosting the security and privacy protections, and addressing ever increasing audit trail needs.
Timeline Risks
Remember, if you want your vendor to build you something ‘special’, it is almost certain to introduce some unknowns. Unknowns bring timeline, operational and financial risk. I would advise against additional custom features until the core project has been delivered.
Come around again and revisit your needs after using the system for 12-18 months.
Adopting an eSource platform is a huge change to an organisation, you should not rush it.
I realise this approach may not be a popular with CEOs and CFOs, but hopefully the voices of CIOs and CTOs will be heard.
Conclusion
Selecting and implementing an eSource solution is a tough, expensive and timeIy commitment. It’s easy to fall into the trap when selecting your vendor to expect, or even demand, that they fulfil all your business needs and desires in a short window of time.
Try to break your project down into short, medium and long term goals.
Split your requirements using ‘MoSCoW’ or similar priorities…
Must Have
Should Have
Could Have
Won’t have (or Won’t have right now)
Allow your vendor to work with you to support your core project goals, wherever possible avoiding customisation. Use what they have and work hard to recover the investment on that limited set of core goals quickly. Demonstrate the benefit and gather the team for a follow-up project, a second wave of process improvements and fine tuning.
Partner with your vendor, give them some space, allow them to breathe, work together expecting a long and healthy relationship.
Select your vendor and your solution for what they have right now. Don’t choose them in the hope, or based on the promise that they might add some ‘essential’ missing feature in the future, or try to twist their arms to add it.
This has got to be a win for both parties.
