Request for Proposal · 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

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


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


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

http://www.dndi.org/


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


Page 5 of 18

ID Category

(min-must have




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


Page 6 of 18

ID Category

(min-must have




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


Page 7 of 18

ID Category

(min-must have




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


Page 8 of 18

ID Category

(min-must have




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


Page 9 of 18

ID Category

(min-must have




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


Page 10 of 18

ID Category

(min-must have




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


Page 11 of 18

ID Category

(min-must have




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.


Page 12 of 18

ID Category

(min-must have




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


Page 13 of 18

ID Category

(min-must have




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.


Page 14 of 18

ID Category

(min-must have




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


Page 15 of 18

ID Category

(min-must have




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


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


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


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

mailto:[email protected]

mailto:[email protected]

Request for Proposal · 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

Documents