Status

colour	Purple
title	status: Future work

Short description

Traditionally, clinical data was captured using paper case report forms (CRFs) and manually digitised afterwards. Nowadays data is digitally collected in Electronic Data Capture systems (EDCs) in electronic Case Report Forms (eCRFS). Many EDCs exist, such as OpenClinica / LibreClinica, Castor EDC and REDCap and the majority of the Dutch UMCs have a site license for such tools. EDCs offer a variety of functionality, such as data entry validation, import/export functionality and monitoring [hri_edc].

When designing your eCRF, it is essential to first have a clear definition of what data you will be collecting. Generally, there are a number of things to keep in mind when designing eCRFs, such as visibility Quality of the eCRF is influenced by design aspects such as visibility of data elements, dependencies, validations, etc. (see the How to section). Furthermore, to

To make clinical data semantically interoperable, the eCRF should be built with interoperability in mind. Instead of using your own local definitions for you data items or defining definitions from scratch, reuse of existing definitions should be considered. For this purpose, many initiatives exist that aim to provide templates, such as CDASH, provided by CDISC and Common Data Elements (CDEs) offered by, for example, the National Institute of Health. Furthermore, data definitions (codebooks) may be available for reuse in online solutions such as ART-DECOR or OpenEHR [iCRF].

Assuming common data elements (CDEs) are used (Step X), these should be used as the basis for your eCRFs, since the items in the CDEs have been unambiguously defined. Furthermore, if the CDEs have been annotated with ontologies, these should be used in the eCRF.

[hri_edc] https://www.health-ri.nl/electronic-data-capture-edc-or-electronic-case-record-form-ecrf-systems

[iCRF] https://f1000research.com/articles/9-81

-------------------

The eCRF was designed to collect data for the CDEs (described in step 2) in the Castor EDC system [5]. Several dependencies, e.g. only show ‘Date of death’ when the patient is deceased, and validations, e.g. validate whether the entered Online Mendelian Inheritance in Man (OMIM) genetic disorder code follows the OMIM standard, were included in order to collect high-quality data (the eCRF questions can be found in [6]). To this end, we mostly worked with closed questions and/or drop-down menus and prevented entering free text as much as possible. An example from the eCRF is shown in Figure S1A. The eCRF template containing the CDEs and the ontologies to annotate them (see step 5) was described in a codebook. This codebook was made openly available in ART-DECOR, a platform from Nictiz, the Dutch competence centre for electronic exchange of health and care information [7], and can be directly implemented in the Castor EDC system or other EDC systems using the openly available iCRF Generator tool [8].

...

The eCRF was designed to collect data for the CDEs (described in step 2) in the Castor EDC system [5]. Several dependencies, e.g. only show ‘Date of death’ when the patient is deceased, and validations, e.g. validate whether the entered Online Mendelian Inheritance in Man (OMIM) genetic disorder code follows the OMIM standard, were included in order to collect high-quality data (the eCRF questions can be found in [6]). To this end, we mostly worked with closed questions and/or drop-down menus and prevented entering free text as much as possible. An example from the eCRF is shown in Figure S1A. The eCRF template containing the CDEs and the ontologies to annotate them (see step 5) was described in a codebook. This codebook was made openly available in ART-DECOR, a platform from Nictiz, the Dutch competence centre for electronic exchange of health and care information [7], and can be directly implemented in the Castor EDC system or other EDC systems using the openly available iCRF Generator tool [8].

Why is this step important

This section should explain why this step is crucial

Expertise requirements for this step

This section could describe the expertise required. Perhaps the Build Your Team step could then be an aggregation of all the “Expertise requirements for this step” steps that someone needs to fulfil his/her FAIRification goals.

How to

The quality of the eCRF will greatly influence the quality of the collected data. Furthermore, by using reusing existing definitions to build these eCRFs, the collected data will be more interoperable. <say something about semantic modelling?>

How to

If common data elements (CDEs) are used (Step X), these should be used as the basis for your eCRFs, since the items in the CDEs have been unambiguously defined. Furthermore, if the CDEs have been annotated with ontologies, these should be used in the eCRF.

To design an eCRF, a number of things must be kept in mind:

...

Depending on your project, data collection could take place in one or more EDCs.

Practical Examples from the Community

This section should show the step applied in a real project. Links to demonstrator projects.

Authors / Contributors

Experts who contributed to this step and whom you can contact for further information The How to section should:

be split into easy to follow steps;
- Step 1
- Step 2
- etc.
help the reader to complete the step;
aspire to be readable for everyone, but, depending on the topic, may require specialised knowledge;
be a general, widely applicable approach;
if possible / applicable, add (links to) the solution necessary for onboarding in the Health-RI National Catalogue;
aim to be practical and simple, while keeping in mind: if I would come to this page looking for a solution to this problem, would this How-to actually help me solve this problem;
contain references to solutions such as those provided by FAIR Cookbook, RMDkit, Turing way and FAIR Sharing;
contain custom recipes/best-practices written by/together with experts from the field if necessary.