Guidance for building Study and CRF in OpenClinica

Guidance for building Study and CRF in OpenClinica 1. Use of Patient Identifying information Patient Identifying Data (PID) is any data within clinical data that could potentially be used to identify subjects, either directly or by linkage to other systems. PID obviously includes names and initials, but also patient s zip code, hospital system IDs, social security number / insurance IDs and dates of birth are considered PID. There is no absolute definition of PID - it depends on the size of the dataset and what other data is present in the dataset. Any clinical data can be PID if it is rare, in a small data set, or linked to other information (e.g. geographical location). Registration of BSN is never allowed. If a patient has signed informed consent, then it is allowed to record identifying data in OpenClinica. However, if there is no reason to capture patient identifying information, please do not do so. TraIT will check the use of PID, and will ask study personnel for approval by the authority in case PID needs to be collected in the OpenClinica database. Under no circumstances it is allowed to capture unencrypted BSN (social security number). Note that the Principal Investigator (PI) of the study remains the controller of the data with all corresponding responsibilities regarding personal data. 2. Need for testing The study/crfs should be final when setting up on the TraIT OpenClinica production server. This requires that data entry and data analysis is properly tested. Test data entry It is important to test data entry in the CRFs in the TraIT sandbox environment to make sure that no problems will occur when the CRFs are used in the production environment. - Make sure to test data entry (enter realistic data) in all CRFs for several subjects. - In case the show/hide function is implemented, you need to simulate different scenario s to test correct show/hide behaviour. - Also, test whether calculations and rules are working properly. - Please check the CRFs for typo s. -> It is advised to involve the persons in testing who will enter data in the production environment. Test data export/-analysis It is very important to test whether data can be exported from OpenClinica in a format that is suitable for data analysis. Often this is neglected which may cause serious problems after years of data collection. TraIT will support OpenClinica users with data export to statistical analysis packages, but under the condition that data export from OpenClinica and import in the selected statistical package has been sufficiently tested before the study and CRFs are set-up in the production environment. So testing of this aspect of the study needs to be done in the sandbox environment. Make sure that potential problems are identified in an early stage (i.e. in sandbox environment) and discuss these with TraIT support. This will enable TraIT to support you with data export & -analysis in the production environment. 1

Please also read 3.3.2 Repeating Events versus Repeating Item Groups in CRF with some specific advice on study- and CRF design to minimize problems with data analysis. 3. Guidance for study configuration and study design 3.1 Study Parameters In the Study Parameter Configuration section of OpenClinica you are able to configure the Subject Attributes which will need to be specified when creating a subject in the database as well as a number of study parameters. Study Parameter Configuration can be found through: Tasks-> Build Study->click on pencil icon behind Task 1 (Create Study)-> scroll to the bottom and click on hyperlink Study Parameter Configuration. 3.1.1 Subject attributes In the Study Parameter Configuration section, you can configure which Subject Attributes should be specified when a subject is being created in the OpenClinica database. The following Subject Attributes can be specified: Year of Birth or Date of Birth, Sex and Person ID: indicate whether these should be specified when subject is being created (see screen print below). The default configuration in OpenClinica is such that subject s date of birth, gender and person ID must be specified when creating a subject. However, date of birth is considered Patient Identifying Data (PID) and may only be recorded in OpenClinica if approval was received (see also 1. Use of Patient Identifying information). The preferred option for Collect subject Date of Birth therefore is Not Used. The Person ID parameter allows you to specify an additional ID for the subject besides the Study Subject ID. If you do not need this parameter, please choose Not Used. Otherwise data entry person may record an identifying ID in this field such as EHR number (ZIS nummer) which is not allowed without proper approval. Subject attributes can also be exported from OpenClinica. Therefore it is not necessary to include these items in the CRF. 3.1.2 Study parameters Discrepancy Management (see screen print above; second parameter from top) 2

Please allow Discrepancy Management. Please answer Yes. This is according to Good Clinical Practice (GCP). If answered No, then it is not possible to use the Notes & Discrepancy Module (e.g. not possible to monitor Study). This is not GCP compliant. Other study parameters (see screen print below). Interviewer name / interview date / Event Location Please select not used if not applicable. Forced Reason For Change in Administrative Editing If selected No than it will not be necessary to give a reason for change of data after CRF has been marked complete. This is not GCP compliant. 3.2 Site creation Even if you will run a mono center study, it is still advised to create a site in OpenClinica for this center. You will need to sign up a Unique Protocol ID for this site in this study. Please conform to the following standard: combination of the Unique Protocol ID of the main study and the Site Name or combination of Brief Title of the main study and the Site Name. e.g. Unique protocol ID: MyStudy site name: Site1 site unique protocol ID: MyStudy_Site1 3.3 Event and CRF set-up 3.3.1 Event set-up In interventional (or experimental) studies it is best practice to design events according to time points for data capture that are set in the protocol. For example screening, baseline, week w, week x, month y, month z, follow-up. In observational-, cohort studies or registries another set-up may fit better. In this case events may be structured according to type of data. For example Treatments Event, Pathology Event etc. Best practice is to structure events according to time points in the protocol because this complies to CDISC/OpenClinica model. If this set-up does not fit to your study design then you might choose an alternative structure. 3

Adverse events and concomitant medications Adverse events and concomitant medications are often designed as a separate event, because time points for these items are not set in the protocol (they occur unplanned). 3.3.2 Repeating Events versus Repeating Item Groups in CRF For recording of adverse events and concomitant medications it is advised not to design the OpenClinica Events as repeating; the event repeats (or Event occurrences) will get a number and it is not clear for the data entry person which AE/co-med belongs to which number. Instead, it is advised to implement repeating item group(s) in the AE / co-med CRF to be able to record multiple AE s / comeds for one subject and add this CRF to a non-repeating Event. Follow-up is typically an event that can be designed as a repeating event. Please note the following: OpenClinica offers a lot of flexibility with respect to study design and CRF design. This may cause problems with loading the exported OpenClinica data in statistical packages. Loading OpenClinica data in a statistical package will be relatively easy if the study and CRFs have a simple, one-dimensional design. It will become more complex if repeating Item Groups or Repeating Events are used. Especially a combination of both (a CRF with repeating item groups in a repeating event) may cause problems with loading the data into analysis tools. In order to simplify data analysis it is advised not to design events as repeating if a CRF with repeating Item Groups is added to that Event. If you decide to use repeating Events in your study you need to properly instruct data entry personnel because it may not be straightforward how to enter data in such a set-up. Off course, you will also need to extensively test data analysis. -> Please contact the TraIT servicedesk if you have any questions about this. 3.3.3 CRF set-up It is good practice to build separate CRFs for items that logically belong together (i.e. belong to the same domain, such as demographics, lab results, vital signs, adverse events etc) and also will be captured at the same time point. Reasons for this are: - It is possible to mark CRF as complete after the data are collected in the CRF which is helpful for data entry. - Performance of OpenClinica may go down if a CRF sections are very large and especially if also many rules are implemented. Please test the performance of such large CRF sections. - These CRFs can more easily be re-used within the study (in another event) and over studies, which makes it easier to harmonize data dictionaries of different studies. - With small CRFs it easier to build interfaces (upload from EMR, ETL to TranSMART) - Such CRF design complies to the CDISC standard which is the data model used in OpenClinica 4

3.4 Guidance for building CRF 3.4.1 General remarks Make sure that CRF pages do not become very large. Between 0-20 questions per CRF section is small, 20-40 questions is average, 40-60 questions is large and more than 60 is very large. A good measure is not to have more questions on one CRF section (i.e. one page) than your computer screen can handle. This avoids scrolling back and forth which makes it more inconvenient. So, if you want to include many items in a CRF, please divide them over different CRF sections. This will improve clarity for data entry and will improve performance of the system (saving many CRF data at once will slow OpenClinica). Please avoid combination fields, e.g. one CRF field for both systolic and diastolic blood pressure. Preferably one CRF field is created for each individual item. This will make it easier to analyse the data (please also see 2. Need for testing). 3.4.2 Response type There are several response types within OpenClinica. Text Please avoid as much as possible free text fields in the CRF (response type 'Text' with data type "Character String ') because this information is more difficult than analysing coded information. Single-and Multiple Select boxes Make sure there is a default option that is meaningless. Column S (DEFAULT_VALUE) in the Excel CRF template allows you to indicate a default value in the CRF without a corresponding response value. In this way no value is saved in the database if you save the CRF with default value in this field. A default value such as (please select) also makes the data entry person aware that he/she needs to choose an option. You may also leave choose a blank option as default as shown below. Include other as response option if completeness of the select list is not guaranteed. In this case you are advised to add a text field in the CRF where data entry person can specify other. Radio button Please be aware that a checked radio button can be changed, but cannot be erased or deselected. Our general advise is to add an escape option such as no information. If needed, you also can implement java-script in your CRF to enable deselecting of a chosen option. 5

3.4.3 Data type There are different data types. For each item in the CRF you need to specify the data type. This can be one of the following: - ST = String. Any characters can be provided for this data type. - INT = Integer. Only numbers with no decimal places are allowed for this data type. - REAL = Real. Numbers with decimal places are allowed for this data type. - DATE = Date. Only full dates are allowed for this data type. The default date format the user must provide the value in is DD-MMM-YYYY. - PDATE = Partial dates are allowed for this data type. The default date format is DD-MMM-YYYY so users can provide either MMM-YYYY or YYYY values. Some users have experienced difficulties in writing rules on PDATE. Please take this into consideration in case you want to use this data type (see also 2. Need for testing). - FILE = File. This data type allows files to be attached to the item. It must be used in conjunction with a RESPONSE_TYPE of file. The attached file is saved to the server and a URL is displayed to the user viewing the form. It is important that you choose the appropriate data type for each item. The Data Type field should not be changed in any subsequent versions of the CRF. If you do change it and you are the owner of the CRF and no data have been entered for this item, the DATA_TYPE attribute for this item will be changed for all versions of the CRF. If original DATA_TYPE for the item was DATE, owner of the CRF can change it to PDATE even if data have been submitted for the CRF. It may be tempting to choose the Data Type String (ST) as it allows entry of all data types in the CRF. However, please only use this data type if it is the only option (i.e. for fields in which text characters- and spaces need to be entered). The reason for this is that correct definition of the data type will improve the quality of the data in the database as OpenClinica will perform edit checks during data entry and will produce an error message if entry does not comply with the definition of the data type. Also, some statistical packages will not handle data as numbers if the accompanying data type is not set to INT or REAL. Make sure that the text fields were you expect a number have data type INT or REAL. In Column U (WIDTH_DECIMAL) you can specify the number of decimal places that are allowed to enter in the field. OpenClinica will produce an error message if more decimals are entered. Please make use of this option if appropriate to improve data quality. Partial Dates in OpenClinica OpenClinica supports use of partial dates in a CRF. With the data type PDATE a full date can be entered in the CRF field (DD-MMM-YYYY) but also MMM-YYYY or YYYY values can be entered. However, there are some limitations to this data type that should be considered before using partial dates in your CRF. Importing in OpenClinica study Validation checks on partial dates in the OpenClinica import module are not fully implemented. This is overcome by using the OpenClinica Data Importer. This tool performs the validation checks on the dataset to make sure that the partial dates appear correctly in the OpenClinica database. There is a data contract available that describes the data formats for the different data types in the dataset. 6

Please refer to the OpenClinica Data Importer data contract that describes what data formats are supported by the data importer (requirements to the formats in the dataset). Running OpenClinica study PDATE fields act like String fields with regard to validation. As there is a lot of freedom for data entry in these fields (day-month-year, month-year and year are all allowed) it is less suitable to build rules or regular expressions on these types of fields. The only component that always will be present in fields of the type PDATE is year and rules/regular expressions can be build on this component. Please keep in mind that it is not possible to build rules that compare a PDATE value with a DATE value; only textual checks are possible. So checks like partial date (PDATE) > date (DATE) and partial date (PDATE) > current date (DATE) are not possible. Analysis of OpenClinica data SPSS: Dates with OpenClinica data type PDATE will appear as string variable in the SPSS dataset. Full dates with data type PDATE can be converted to a date format in SPSS. Unfortunately, SPSS does not have a partial date format to support MMM-YYYY and YYYY. Excel: Dates with OpenClinica data type PDATE will appear as string variable in the Excel dataset. However, in Excel these data elements can be converted to either a full date, Month-Year of Year data type. Please first test your data export in the analysis tool of your choice before using data type PDATE in your CRF. 3.4.4 Left / right item text Make sure that it is clear for data entry personnel what needs to be entered in the CRF. -> The left item text (column C in Excel CRF template) is generally used to specify clearly which information needs to be entered in that field (e.g. systolic blood pressure or body weight ). -> The right item text (column E in Excel CRF template) is generally used to give some additional explanation (e.g. mean of three measurements). -> Units column (column D in Excel CRF template) is used to specify the unit of the variable (e.g. mmhg or cm). 3.4.5 Update CRF If you want to modify a CRF during the duration of the study, please use the 'create new version option. Do not upload a new CRF if you want to change something in the current definition CRF. If a new version of the CRF is created, this will enable data that were collected in a previous CRF version to be migrated to the new CRF version. Restore your CRFs in Excel to version one before you upload it to the TraIT OpenClinica production environment (www.openclinica.nl). A new CRF version is immediately available for data entry. Therefore, new CRF versions need to be tested thoroughly on the sandbox server before you upload them to OpenClinica.nl server. 7