What is it? Why is it important?
The set-up of the study database is ready once:
- An applicable access protected server is available
- A CDMS complying with regulatory requirements has been selected
- A final and EC approved study protocol is available, including its list of required variables
- Metadata, variable specifications, automated data processing are defined
- Data confidentiality is guaranteed (e.g. data coding and anonymisation)
Once the database is set-up, validation tests are implemented to ensure the database performs according to required specifications. Upon successful validation the database can be put into productive operation.
Productive or real-life data entry is only possible:
- Upon successful testing of the database with dummy data
- The SP-INV has validated and deemed the database fit for productive data entry (the switch from test phase to productive phase must be approved by the SP-INV in writing)
- Study staff has been trained on data entry procedures and been given access through individualised passwords and logins
The switch from a test to a productive database must be documented. This is automatically tracked in an electronic database.
Example of database version management
- Version tracking is documented using 3 digits
- The first release is given the number 1.0.0
- Small changes result in adaptations in the 3rd digit (e.g. 1.0.1, 1.0.2, 1.0.3)
- Medium changes result in adaptations in the 2nd digit. (e.g. 1.1.0, 1.2.0, 1.3.0)
- Major changes result in adaptations in the 1st digit (e.g. 1.0.0, 2.0.0, 3.0.0)
What do I need to do?
As a SP-INV:
- Ensure requirements needed for the development of the study database are met (e.g. selection of CDMS, protected server location, qualified staff)
- Implement database according to specifications given in the study protocol (e.g. study design, variable selection, planned study visits)
- Perform functionality tests exclusively with dummy data:
- On the non-released database
- Include staff with regard to functionality tests, as they might more easily identify inconsistencies
- Once functionality tests have been successfully completed:
- Release the database in order to allow for productive or real life data entry
- Provide secure logins to staff responsible for study data entry
- Ensure the database is provided with a release date and version number
Database validation tests should be performed diligently until data entry performs as intended, without delays or problems. It will save time and resources later on during study conduct.
Changes to an already released database might require a protocol amendment (e.g. changes in inclusion/exclusion criteria, changes in study methods or data collection).
A substantial protocol amendment will result in:
- An analysis and a risk assessment in order to ensure that data quality, of already collected data, is not jeopardised
- Requied submission and approval by EC and if applicable RA
- A significant delay in study conduct
- The potential need for additional resources (e.g. staff, infrastructure, partners)
- An increase in overall study cost
Where can I get help?
Your local CTU↧ can support you with experienced staff regarding this topic
Basel, Departement Klinische Forschung, CTU, dkf.unibas.ch
Lugano, Clinical Trials Unit, CTU-EOC, www.ctueoc.ch
Bern, Clinical Trials Unit, CTU, www.ctu.unibe.ch
Geneva, Clinical Research Center, CRC, crc.hug.ch
Lausanne, Clinical Research Center, CRC, www.chuv.ch
St. Gallen, Clinical Trials Unit, CTU, www.kssg.ch
Zürich, Clinical Trials Center, CTC, www.usz.ch
Swissethics – search text
- Definition of substantial and non-substantial amendments
ICH GCP E6(R2) – see in particular guidelines
- 5.5. Trial Management, data handling, and record-keeping