eSource Stakeholders
Stakeholders and beneficiaries of eSource and automation systems in Early Phase trials
Introduction
As usual I am focusing on users of eSource and automation systems in ‘Clinical Pharmacology Research Units’ (CPRUs, CPUs, Phase I Units, Clinical Trial Units etc.).
I am splitting the users in two ways - site versus sponsor, and by the immediacy of the benefit, their ‘proximity’ to the application, whether they are using the software everyday - primary, secondary and tertiary stakeholders.
The roles are based on my personal experience of working in four different CPRUs and supporting many customers implementing eSource solutions. I appreciate not all sites will have all these roles, and if they do, might name them differently.
Feel free to let me know if I missed out an obvious stakeholder group or whether you’d put them at a different level in the hierarchy.
Primary Stakeholders
The site staff that use the software everyday to identify and screen participants and conduct clinical trials. It’s their primary platform and ‘workhorse’ for performing their job. They capture trial data and process specimens with the application. They review it for completeness and compliance, they may raise queries to their colleagues to confirm an observation or measurement. They review the data for trends and safety signals. They might extract data for dose escalation meetings.
Some of these stakeholder groups will have access to private, personal and identifiable information about trial participants. Access privileges will be set on a ‘need-to-know’ basis.
I have included the CRA / Monitor in the Sponsor bucket, knowing that many CRAs will be independent of the Sponsor (contractor, or from a Contract Research Organisation etc.). Either way, they are the Sponsor’s representatives.
Secondary Stakeholders
Users that may be inside or outside of the CPRU, or both. They may ‘belong’ to the wider site organisation, or they may be associated with the Sponsor, directly or via third parties.
Data Managers (DMs) may be ‘pulling’ or receiving regular data dumps from trials that they are authorised to work on. They may use the software everyday, especially if they are part of the study build and test team.
Site QA staff are likely to have access privileges similar to those afforded to CRAs. Sponsor QA may not, depending on the sites policies and procedures. In either case, I would not expect this group (or even internal DMs) to be able to view private, personal and identifiable information about trial participants.
Sponsor Study Team - this one might be contentious, but I have placed it here to indicate what you could choose to do if your policies and procedures support it, or even require it. Perhaps there is a medical monitor that needs blinded access to the source data as it is being collected. Perhaps the site / investigator is the Sponsor. You will have the controls to define the appropriate levels of access based on the role and responsibility of the user.
Tertiary Stakeholders
Biostatistics and Medical Writing teams are not likely to be users of the software. They will receive cleaned and formatted data extracts ready for analysis and inclusion in Clinical Study Reports, or even dose escalation summary reports, if the site has the resources in house to connect those dots.
The Site Head, Chief Financial Officer (CFO) and Sales Team won’t necessarily need to access the software to perform their roles, but they will benefit from the data quality assurance, compliance and efficiency gains from adopting automation, process controls and systems integration.
They are looking to increase or sustain capacity, whilst reducing cycle times and presenting their site as having the necessary combination of medical and scientific expertise, customer service, speed and quality to meet their Sponsor’s needs.
