Request for Proposal · CDMS - Request for Proposal Page 3 of 18 1. Context and purpose 1.1. DNDi...
Transcript of Request for Proposal · CDMS - Request for Proposal Page 3 of 18 1. Context and purpose 1.1. DNDi...
CDMS - Request for Proposal
Page 1 of 18
Request for Proposal
Clinical Data Management System
Drugs for Neglected Diseases initiative – Africa Regional Office Nairobi, Kenya
Dated: 22th July, 2020
CDMS - Request for Proposal
Page 2 of 18
Table of Contents
1. Context and purpose ...................................................................................................................... 3
1.1. DNDi Overview ................................................................................................................................... 3
1.2. Objective of the request .................................................................................................................... 3
2. The CDMS System .......................................................................................................................... 4
2.1. Data management ............................................................................................................................. 4
2.1.1. General Information ....................................................................................................... 4
2.1.2. CDMS functional requirements ...................................................................................... 4
2.2. Other Data Management Activities .................................................................................................. 15
3. Timelines ...................................................................................................................................... 16
4. RFP instructions ............................................................................................................................ 17
4.1. General information ......................................................................................................................... 17
4.2. RFP Timelines ................................................................................................................................... 17
4.3. Format and content of the proposal................................................................................................. 17
4.4. Selection criteria .............................................................................................................................. 17
4.5. Contact details ................................................................................................................................. 18
5. Appendices ................................................................................................................................... 18
CDMS - Request for Proposal
Page 3 of 18
1. Context and purpose
1.1. DNDi Overview
Neglected tropical diseases continue to cause significant morbidity and mortality in the developing
world. Yet, of the 1,556 new drugs approved between 1975 and 2004, only 21 (1.3%) were specifically
developed for tropical diseases and tuberculosis, even though these diseases account for 11.4% of the
global disease burden.
Founded in 2003 to address the needs of patients with the most neglected diseases, DNDi is a
collaborative, patient’s needs driven, not for profit drug R&D organization.
Acting in the public interest, DNDi bridges existing R&D gaps in essential drugs for these diseases by
initiating and coordinating drug R&D projects in collaboration with the international research
community, the public sector, the pharmaceutical industry, and other relevant partners.
DNDi’s primary focus has been the development of drugs for the most neglected diseases, such as
Human African Trypanosomiasis (HAT, or sleeping sickness), visceral leishmaniasis (kala-azar), and
Chagas disease, while considering engagement in R&D projects for other neglected diseases to address
unmet needs that others are unable or unwilling to address.
The primary objective of DNDi is to deliver new treatments for leishmaniasis, sleeping sickness, Chagas
disease, malaria, paediatric HIV, and specific helminth infections and to establish a strong R&D
portfolio that addresses patient needs. Expanding upon R&D networks built on South-South and North-
South collaborations, DNDi aims to bring medical innovation to neglected patients by developing field-
adapted treatments.
In doing this, DNDi has two further objectives:
• Use and strengthen existing capacities in disease-endemic countries via project
implementation
• Raise awareness about the need to develop new drugs for neglected diseases and advocate
for increased public responsibility.
For more information, please visit DNDi website: http://www.dndi.org
1.2. Objective of the request
DNDi is seeking a regulatory compliant clinical data management system (CDMS) for use in electronic
data capture (EDC) environment. The objective of this request therefore is to;
1) To identify a suitable CDMS for use in DNDi EDC operations
2) To identify a CDMS that meets the requirements described in the systems requirements
section below
3) To identify a system whose cost is within DNDi’s limited budget for the EDC system
CDMS - Request for Proposal
Page 4 of 18
2. The CDMS System
DNDi conducts clinical trials in diverse disease areas in different regions globally and is improving its
data managenement processes to use electronic data capture in these trials. Some of the trials are
conducted in resource-constrained settings with intermittent internet connectivity. The desired
CDMS is expected to be light-weight and with ability to operate in such settings. Key requirements
for the CDMS are highlighted below.
2.1. Data management
2.1.1. General Information
Below are general requirements of the desired CDMS.
• Data management systems must be compliant with 21 CFR Part 11 and ICH-GCP requirements for clinical data management.
• System validation: The CDMS vendor must ensure that the system is validated and provide all applicable validation documentation
• The systems should have multilingual support for eCRF including but not limited to English, French and Arabic languages.
• The system should be Web-based with support for data capture using mobile devices and tablets running on Android or iPhone Operating systems.
• Support and documentation in French and English, ideally self-explanatory with a super-easy user interface.
• Offline capability a plus, at least tolerance to low bandwidth and high latency (lightweight interface)
2.1.2. CDMS functional requirements
The table below summarizes the minimum CDMS functional requirements. The vendor should address whether the requirements are met or not in their proposal
ID Category
(min-must have
bp-best practice or good to have)
Requirement Fully met/ Partially met/ Not met
Suppliers response/ statement
URS02: Clinical Data Management Application – Design and Development
URS02.01 min CRF Development: The system should provide a functionality for the development, testing and deployment of the CRFs within the system.
URS02.02 min CRF Version control: The system should
have CRF version control functionality in place which will ensure ease of implementation of new CRF versions.
URS02.03 min Annotated CRF: The system should provide a mechanism for generating annotated CRF once CRF is developed
CDMS - Request for Proposal
Page 5 of 18
ID Category
(min-must have
bp-best practice or good to have)
Requirement Fully met/ Partially met/ Not met
Suppliers response/ statement
URS02.04 min Data Dictionary: The system should provide
a mechanism for generation of a data dictionary once CRF development is complete
URS03: Clinical Data Management Application – Clinical database Validation
URS03.01 min Functional specification testing: The
system should provide a functionality for testing with sample data against functional specifications.
URS03.02 min Test of data checks: The system should have a functionality for testing implemented data checks
URS03.03 min Validation report generation: The system should have a functionality for generating validation reports
URS04: Randomization
URS04.01 min Randomisation Implementation: The system should have a functionality for implementation of different randomizations schemes and importation randomization lists
URS04.02 min Updates to implemented randomization:
The system should have functionality for implementing changes to existing randomizations schemes arising during study periods
URS05: Site management
URS05.01 min Study site setup: The system should have a
functionality for setting up distinct sites within a defined study.
URS05.02 min Site user management: The system admin
should be able to create users and assign them to a particular site(s).
URS05.03 min Handling multiple sites: When a user is
assigned to more than one site, the user should be able to switch between the sites accordingly and should be able to see which site they are currently logged into.
URS05.04 min Site deactivation: System should have a
functionality for disabling existing study site
CDMS - Request for Proposal
Page 6 of 18
ID Category
(min-must have
bp-best practice or good to have)
Requirement Fully met/ Partially met/ Not met
Suppliers response/ statement
URS05.05 min Site user restriction: The study site users
must only have access to their site specific data.
URS06: Training and support
URS06.01 min Training support: The system should
provide a test or training environment to support user training before they can access production environment.
URS06.02 min Test or production environment: Users should be able to clearly see that they are working in test environment or whether they are working in production environment.
URS06.03 bp Access to production database: The
system should have controlled access to production environment only when necessary training has been done in the test environment and all relevant paperwork completed
URS06.04 min System support: In case of a hosted solution, the system vendor must have a support plan with 24/7 dedicated support team
URS06.05 min Training modules: providing on-site and
online trainings
URS07: Data Entry and processing
URS07.01 min Restriction of Data Access: site staff have
access only to data of their site
URS07.02 min Tracking of CRFs: a CRF tracking system is
in place.
URS07.03 min Management of missing CRFs: system
should be able to identify and report on
missing or late CRFs /data
URS07.04 min Simple Checks: simple checks (e.g. range
checks) should be available and executable
at the point of data entry
URS07.05 min Complex Checks: complex checks with
critical variables (e.g. cross form validation)
are available
CDMS - Request for Proposal
Page 7 of 18
ID Category
(min-must have
bp-best practice or good to have)
Requirement Fully met/ Partially met/ Not met
Suppliers response/ statement
URS07.06 min Audit Trail: All transactions to the trial
database (insert, update, delete) must have a
clear and complete audit trail, covering the
date and time of the input, the person making
the change and the old and new values
URS07.07 bp Data entry progress report: The system
should be able to generate data entry
progress report showing what has been
entered, when and by who
URS08: Data Quality Checks
URS08.01 min Batch Validation Checks: The system
should have support for validation checks
execution via a batch process, to identify new
warnings, missing, illogical and inconsistent
data
URS08.02 min Data Review: The system should provide
support for data checks by generating
specified data in formats that match input
format (e.g. that mimic CRFs) for manual
review of data, e.g. medical consistency
checks, lab data pointing to an AE
URS08.03 min Risk Based Source Data Verification: The
system should have support for configuration
of a risk-based source data verification
regime implemented as specified in the
protocol, with the emphasis on primary target
variables and other essential data. A check of
primary endpoints and other essential data is
conducted
URS08.04 min Quality Monitoring of Sites: The system
should provide support for monitoring of
quantity / types of errors to identify potential
problems, e.g. with particular preset trigger
levels
URS08.05 bp Statistical Evaluation of Data Quality: The
system should provide support for statistical
methods use in assessing and evaluating
data quality (e.g. measures to analyse
possible problems and irregularities should
cover e.g. multivariate analysis of possible
CDMS - Request for Proposal
Page 8 of 18
ID Category
(min-must have
bp-best practice or good to have)
Requirement Fully met/ Partially met/ Not met
Suppliers response/ statement
outlier candidates, conspicuous data patterns,
preferred numerical sequences, accumulation
of values close to defined limits) and the
impact on analysis should be evaluated
URS09: Query Management
URS09.01 min Query generation: The system should have
functionality for generating queries on each data item in a subject’s record
URS09.02 min Auto generated vs manual queries: The
system should be able to generate queries automatically at the point of data entry and should also support manual creation of queries by authorized users
URS09.03 min Query tracking: The system should provide
support for detailed tracking of generated queries clearly specifying who created the query, when query was created or updated and current status of the query whether new, updated or closed.
URS09.04 min Responses to Queries: Query responses
are recorded when returned, identified when
outstanding and resent as necessary
URS09.05 min Actions in Response to Queries: Query
resolution tracked, and appropriate action
taken within agreed timelines and
documented in the audit trail
URS09.06 min Avoidance of Query Duplications: The
system avoids accidental duplication of
queries
URS09.07 bp Generation of Messages: system is able to
generate messages to users not linked to
specific data items (i.e. information giving, not
expecting a reply)
URS09.08 bp Generation of Query Reports: reports are
generated showing query generation data,
return times etc. broken down by site, by
source form, etc.
URS09.09 min Query notification: The system should
provide functionality through e-mail or
CDMS - Request for Proposal
Page 9 of 18
ID Category
(min-must have
bp-best practice or good to have)
Requirement Fully met/ Partially met/ Not met
Suppliers response/ statement
otherwise to notify users of the assigned discrepancy notes
URS09.10 min Query filtering within the system: The system should provide an interface to list, sort or filters available queries based on subject and query status
URS10: Data Coding and Standards
URS10.01 min Autocoding: The system should provide
support for automated coding of Medical
safety data using acceptable industry
standard coding tools such as MedDRA and
WHODRUG.
URS10.02 min Manual coding: In cases where safety data
is not automatically coded, the system should
provide an interface for manual coding of
safety data by study team member
responsible directly within the system.
URS10.03 min Handling of different versions of coding
tools: The system should be able to
seamlessly manage different versions of tools
used to code safety data e.g MedDRA during
the study
URS10.04 min CDISC standards: The system should be
CDISC standard compliant in all aspects
including development of eCRFs, data
extraction and reporting.
URS11: Safety Data Management
URS11.01 min Safety Data Management: The system
should allow logging of all forms, faxes and
correspondence involved in safety data
reporting, and subsequent information /
evaluation requests
URS11.02 min Expedited Reporting: The system should
support expedited reporting of safety data to
authorities
URS11.03 min Routine Reporting: The system should
support routine reporting to all relevant
CDMS - Request for Proposal
Page 10 of 18
ID Category
(min-must have
bp-best practice or good to have)
Requirement Fully met/ Partially met/ Not met
Suppliers response/ statement
authorities when required (e.g. annual line
listings)
URS11.04 min Electronic Reporting: The system should
support reporting via electronic transfer to
authorities
URS11.05 min Safety Data Reconciliation: The system
should support the reconciliation of SAEs with
other safety data
URS12: Importing and Uploading data
URS12.01 min Data import/ upload support: The system should provide support for importing or uploading bulk data through secure API into the specified study or site within the system.
URS12.02 min Logging of Uploads: The system should
keep and audit trail and logs for each upload process.
URS12.03 min Validation of imported/ uploaded data: The
system should run/execute in-built checks on the imported data and generate queries as per normal data entry.
URS12.04 bp File Retention: The system should be able to
store the original files in a read only regime,
and be available as a reference data set for
audit /reconstruction purposes
URS13: Data Extraction /Export
URS13.01 min Data Extraction: The system should allow data extraction at least in the following standard formats: STATA, SAS, MS Excel, CSV, TAB delimited formats, CDISC ODM formats.
URS13.02 min Electronic Archiving of exported data:
Standardised formats for electronic archiving
(e.g. ASCII, PDF, XML, CDISC ODM, FDA
approved SAS format) are used
URS14: Reporting
URS14.01 min Report generation: The system should be able to generate standardized reports based on user specified criteria
CDMS - Request for Proposal
Page 11 of 18
ID Category
(min-must have
bp-best practice or good to have)
Requirement Fully met/ Partially met/ Not met
Suppliers response/ statement
URS14.02 min Single Subject Data: It should be possible to
examine and export a full record of a single
subject’s data (excluding personal identifying
data)
URS14.03 min User Interface (UI) Ad Hoc Reports: It
should be possible to extract ad-hoc filtered datasets (reports) via the UI
URS14.04 min Audit Data: Selected reports should include
the option of including audit related data
URS14.05 min Report Rerun: Once a report is generated by user it should be possible to save and rerun it
URS14.06 min Metadata included: The option should exist
to include a metadata description of extracted data
URS14.07 min Study definition: Standard reports should
include the details of the current study definition in an approved XML schema (trial schedule and data items)
URS14.08 min Format of Reports: Report data can be generated / exported in formats agreed with local report consumers , e.g. PDF, HTML, XML
URS14.09 min Data Personnel: It should be possible to
examine and export a record of a single data entry clerk’s input data
URS14.10 min Key Field Changes: It should be possible to
examine and export a full list of changes to identified key fields, e.g. fields reporting toxicity as part of monitoring
URS14.11 min Automatic Generation: The generation of reports can be automated and can be scheduled
URS15: Database lock
URS15.01 min Database lock: The system must have a functionality for locking the database before planned final analysis
URS15.02 bp Database soft lock: The system should have a functionality for managing temporary lock before a planned interim analysis.
CDMS - Request for Proposal
Page 12 of 18
ID Category
(min-must have
bp-best practice or good to have)
Requirement Fully met/ Partially met/ Not met
Suppliers response/ statement
URS15.03 min Participant level data lock: The system
should have a functionality to ensure that participants data can be locked for those who have completed study
URS15.04 min Unlocking the database: The system should provide a functionality for un-locking the database ensuring that the reason for un-lock is provided and authorized
URS16: Logical Access Control
URS16.01 min Access Control Management: The system
must have an access control mechanism e.g. using roles, group membership, etc., that can be used to effectively differentiate and manage access
URS16.02 min Granularity of Access: Access control
mechanisms should be granular enough so that users only see the data they need to see
URS16.03 min Password management: Use of complex
password should be enforced on all users, including regular password change enforcement
URS16.04 min System time-out: The system should be designed to automatically time-out after a pre-specified time limit
URS16.05 min Controlled access to clinical data: Access to clinical data should be granted to users based on their roles in the study e.g read only rights to Monitors and read/write rights to Investigators
URS16.06 min Failed login attempts: The system should be able to lock out a user of a number of unsuccessful attempts to log in.
URS16.07 bp Single Sign On (SSO) and Integration with Active Directory (AD): The system should provide an interface for integrated access with existing AD such as MS Azure.
URS17: Clinical DBMS System
URS17.01 min Development, Production and Test
Instances: The system offers three instances: development, test, production. The
CDMS - Request for Proposal
Page 13 of 18
ID Category
(min-must have
bp-best practice or good to have)
Requirement Fully met/ Partially met/ Not met
Suppliers response/ statement
test environment and the production environment are identical
URS17.02 bp Latin Characters: Systems support a full range of accented Latin characters
URS17.03 bp Date/numerical Representation: It is
possible to set and use different date and numerical representations in the system
URS17.04 min Light web page: for remote sites (Africa,
India settings with poor connectivity)
URS17.05 min Hosting: availability of the solution on premises, or cloud based.; specify SLA if cloud based. Possibility of cloud based hosting within the regions where clinical trials are taking place is an added advantage.
URS17.06 min Capacity: The system must be robust, even beyond its capacity.
URS17.07 min 3rd party integration: Access via REST and
SOAP web services can be done via HTTPS. This access has to be protected by basic authentication.
URS17.08 bp Offline mode: DNDi conducts trials in remote settings with intermittent internet connectivity. Ability of the system to work in offline mode is highly desired
URS18: System Audit trails and electronic signatures
URS18.01 min User login audits: The system should audit
all user login and logout activities.
URS18.02 min Generation of audit trails: The audit trail
must be computer generated.
URS18.03 min Secure audit trails: The audit trail must be
secure (read only access)
URS18.04 min Audit trail accuracy: The audit trail must
have accurate date/time stamp.
URS18.05 min Audit trail contents: Must record date of
operator entries and actions that create,
modify, and delete electronic records.
CDMS - Request for Proposal
Page 14 of 18
ID Category
(min-must have
bp-best practice or good to have)
Requirement Fully met/ Partially met/ Not met
Suppliers response/ statement
URS18.06 min The audit trail to be embedded within the
records and must not be separable
URS18.07 min Access to audit trails: Audit trail must be
accessible by clicking appropriate link.
URS18.08 min Searchable audit trail: The audit trail is
searchable and capable of producing audit
trail reports
URS18.09 min Metadata Audit Trail: An audit trail for metadata changes is implemented
URS18.10 min Electronic signatures: The system should
provide electronic signature functionality
which requires use of ID and passwords.
URS18.11 min Data associated with electronic signature
cannot be deleted unless the signature is
removed.
URS18.12 min Electronic signatures contents: Include the
printed name of the user applying the
signature as well as date/time of the signature
and meaning of the signature.
URS18.13 min The signature should be human readable
URS19: Implementation and maintainability
URS19.01 min Installation: The installation of new system
releases happens automatically after the
initial configuration was done. Automated
smoke tests monitor the installation and
report the completion of the installation (e.g.
by email).
URS19.02 min Installation: The system can be installed and
tested within the maintenance time frame. In
case of an error the installation procedure can
be repeated at least once.
URS19.03 min Fall-back: If the system release installation
was not successful (even after one iteration)
the installation can be rolled-back (without
side effects, within the maintenance time
CDMS - Request for Proposal
Page 15 of 18
ID Category
(min-must have
bp-best practice or good to have)
Requirement Fully met/ Partially met/ Not met
Suppliers response/ statement
frame). The roll-back process happens
automatically.
URS19.04 min Maintenance time frame: DNDI is a global
organisation and expected users are
connected from Nairobi to Geneva, therefore
maintenance windows are narrow but
sufficient; how do you proceed with
maintenace
URS19.05 min Pre-production environment:
a preproduction environment is available at
no cost to test development and integrations
URS20: License model
URS20.01 min NGO pricing: DNDi and GARDP are Non for
profit 15rganization, do you provide specific Licence costing in that case
URS20.02 min License model: The license fees should be
variable using business-oriented cost drivers (e.g. number of enrolled participant, number of study sites etc).
URS21: Integration with CTMS/eTMF
URS21.01 bp Integration with CTMS/eTMF: DNDi uses Veeva CTMS/ eTMF and as such the ability of the CDMS to integrate with CTMS/eTMF is highly desired
2.2. Other Data Management Activities
In addition to the general and functional requirements, the CDMS should be able to support other study data management process and activities such as;
• Patient registration process for both screen failure and randomized participants
• Support for study management and follow-up. The CDMS should be able to;
o Edit and send (study team + investigator) electronic visit calendar for each patient included.
o Send reminder for FU visits (study team + investigator) (3 months) o Send reminder for missing visits (study team + investigator) o Provide online access to study data (clean and unclean data – based on ‘Optional
extra’) allowing remote monitoring
• Reporting needs including: o Query reports to CRAs and investigators
CDMS - Request for Proposal
Page 16 of 18
o Reports to Investigators before monitoring visits. o Monthly progress report on study data or online access to data / reports to DNDi
Project Management. o Reports can be suggested by the vendor, according to current practice. It is preferred
that the reports can be generated and exported by DNDi study team (as many times as needed). Example of reports: study and site enrollment, population set, reason for non-inclusion, demographics, medical history, concomitant medication, abnormal laboratory values, AE and SAE e.t.c. Reports should be ready for implementation since first patient in order to follow the study progress. Ensure flexibility for unscheduled demands.
o Activity report (metrics such as: enrollment status, data entry and data cleaning status, query status, protocol deviation listing e.t.c)
• Patient profiles (criteria to be later defined) and data listings edited for DSMB and interim locks
3. Timelines
For successfuf adoption of the new CDMS, It is expected that within 6 months, we will be able to finalize on the vendor selection process, train the data management team and also undertake system validation with support from the CDMS vendor. A small pilot study is planned early next year to assess the suitability of the system and there after new DNDi studies will be rolled out in the selected CDMS. DNDi conduct trials in several trial sites spread across countries in Africa, Latin America and India. Some trials are multi-site multi countries whereas other as run in a single country depending on the study design. The table below highlights key timelines in the adoption of the new CDMS.
Activities Task Estimated Dates
EDC Vendor selection • Select appropriate vendor 30th Sep 2020
Training to DNDi Staff
Training to DNDi Staff including;
• 5 Data Managers
• 3 Data Management assistants
• 1 statistician
• 10 CRAs
1st Oct 2020 - 31st Dec 2020
CDMS System validation
Provide support for;
• Overall system validation
• Study database specific
validation
1st Oct 2020 - 31st Dec 2020
Development of Pilot study
Provide support for;
• Development of eCRFs
• Programming of Editchecks
• Development of study reports
1st Jan 2021 – 28th Feb 2021
Pilot study • Selected study to assess CDMS
suitability
1st Mar 2021-30th June 2021
CDMS - Request for Proposal
Page 17 of 18
4. RFP instructions
4.1. General information
DNDi invites you, as a CDMS vendor, to submit a proposal to support DNDi activities described above.
The issuance of this current Request for Proposal in no way commits DNDi to make an award.
4.2. RFP Timelines
Process steps Responsible party Timelines
RFP launch DNDi 22th Jul 2020
Questions sent to DNDi (using Annex 1) Vendor 30 Jul 2020
DNDi responses to Q&A DNDi 7th Aug 2020
Reception of proposals DNDi 14th Aug 2020
Vendor Demo Vendor 16th Aug -31st Aug 2020
Bidder award DNDi 7th Sep 2020
Project Start (contract drafting and KO
meeting) Vendor and DNDi 7th Sep -30th Sep 2020
4.3. Format and content of the proposal
Responses to this RFP must be in English and should contain the following information:
• Company profile e.g. o Management team, history, key contacts and specific business approach
with NGOs o Key figures (revenue and headcounts for the past 3 years, financial stability,
locations) o Customer’s reference in related area
• Technical proposal e.g. o Detailed presentation of team and organization proposed to answer the
needs described above o Samples of CVs from key team members o Any other relevant information
• Financial proposal o Costing strategy for the proposed system
4.4. Selection criteria
The decision to award any contract resulting from this RFP process will be based on CDMS vendor’s
responses and any subsequent negotiations or discussions. The decision-making process will consider
the ability of each the vendot to fulfil DNDi’s requirements as outlined within this RFP.
Proposals will be assessed against the main following criteria but not limited to:
• Track record and references for similar projects and in similar countries/context
• Experiences/skill level of company representatives assigned to this project
CDMS - Request for Proposal
Page 18 of 18
• Quality and applicability of proposal presentation
• Customer references / Experience in related area and countries
• Capacity to deliver the services as per DNDi requirements
• Costing strategy/proposal non-for-profit organizations
4.5. Contact details
Questions types Contact person Title Contact information
Contractual & Business aspects Olivier DEGODET Sr Procurement
Manager
15 Chemin Louis Dunant,
1202 Geneva, Switzerland
Phone: +41 22 555 1911
Email: [email protected]
Data Management & Technical
aspects Michael OCHIENG
Data Operations
Manager
Tetezi Towers, 3rd Floor,
George Padmore Rd,
Kilimani,Nairobi, Kenya
Phone: +254796864740
Email: [email protected]
5. Appendices
– Annex 1: Q&A Template