Any form can be used as a common event, but typically it is used for adverse event, medical history, and use of medications. Common for all of them is that they are typically not directly connected to a scheduled event.

A few things are common for the design of all common events. Data is only entered in a common event when an event has occurred or when there is a medication to enter. Therefore, it is recommended not to use any leading questions, for example, "Did the subject experience any adverse event?". These kind of check questions could serve as a reminder, but would be better placed in the scheduled events (see Check questions form).

The system variable StudyEventRepeatKey ensures that there is always a unique identifier for each form added within an event. This is particularly useful in the common events. It is recommended to populate this system variable in the form as a sequence number (for example, AESEQ) so that this key is also displayed to the end user. This removes the need for the site to manually keep track of sequence numbers of each event. See the lesson Adding an auto counter in common events for more information. It is recommended that this item is also used in the summary format in the study event settings, together with a few selected items to make the common event overview as informative as possible.

An optional approach for the medical history form could be to design it as a repeating form on the first scheduled event, see Repeating form.

In this study, the medical history is captured in an event form. In most designs, medical history is captured in a common event, but some users prefer to capture this data at the first event.

In this design, a repeating form has been used at the first event as an example of that approach. "Medical history" is added as an activity name to make this clearer in the patient overview.
The system variable FormRepeatKey is used as a sequence number in the form. Also, the relevant details have been included in the form summary format to make the forms as clear as possible when viewing them in Viedoc Clinic.

A general Check questions form can be used to remind the site staff of the data to be entered in the common events, such as adverse events and concomitant medications, as well as other study-specific reminders.

For the use of Check questions form in unscheduled events, see Unscheduled events.

In clinical trials, unscheduled events are commonly performed as needed, and usually only a some of the assessments are performed in scheduled events. A general recommendation is to include a question about assessments performed in the Check questions form.

Note! In these designs, an item group has been used with “assessments performed” that is only displayed in the unscheduled events. Visibility conditions on the activity level will then control what forms are displayed based on the selections in the Check questions form. This way you can build one single unscheduled event in the study workflow, and in Viedoc Clinic keep one single unscheduled event flexible when it comes to the forms required. It will also make it easy for the end user to decide what forms to trigger for the event.

Adding multiple unscheduled events in the design is therefore only used when you have very distinct types of events and you want to direct the user by triggering the relevant forms, for example, “Unscheduled drug dispense” or “Unscheduled lab sampling”. Even in these examples you can question the need for these because it would still work well with one flexible unscheduled event.

In most studies, it is recommended to use a single question for confirming all eligibility criteria, or one question for inclusion criteria and one for exclusion criteria. Whenever a patient is not eligible, the individual criteria can be triggered so the user can specify the criteria not met (for inclusion criteria) or criteria met (for exclusion criteria).

This design is according to the recommendations in CDASH. The reason for not having individual questions for each criterion is that the moment when the site staff is entering data in the eligibility form is usually not the moment when the site is actually reviewing each eligibility criterion. Usually, the site has already made their review with the patient beforehand, and entering data in the eligibility form is just about confirming this. Answering questions about each criterion will risk being a tedious activity with limited value, because the site staff is unlikely to review and evaluate each criterion again.

If you want to display the criteria from the protocol, there are several ways to do that without having individual questions for each criterion:

• You can just display them at all time as static text.
• You can include this in the section "instructions for user" for any of the items in the form so that the user can open and read the individual criteria by clicking the icon ?.
• You can have a checkbox with "show/hide criteria" to control that static text field.

At the end of the form, a calculated eligibility summary triggers subsequent activities.

Although there are variations to designs of RECIST forms, they all share the same principle.
A number of target lesions and possibly non-target lesions are identified and captured at an initial event.

Lesion IDs are populated through functions. In subsequent events, follow-ups are being made on the previously registered lesions. For these events, the lesion identifiers are populated with default values and only selected parameters are presented as blank and requiring new information entered.

Possible new lesions would be added in a separate form, but would in this study not be tracked in the same way. An overall assessment would be done in the disease response form.

These lab forms are adapted for the reference data editor. The forms have been designed assuming there will be many different labs, reporting results in different units, result formats and age ranges. So these forms are intended to work well on all occasions when the reference data editor is to be used, but the form design will also work for manual data entry.

• For the analyte item, a function displays the name of the analyte. It is displayed in its own item in order to include the analyte name as an item in the export. This design is preferred by many because it gives the user more clarity in the export and makes it a little bit more "Study Data Tabulation Module (SDTM)-like". An option is to instead specify the analyte name in the label for the result item or as a label for the item group.
• Prior to the result item, a "prefix" item with <, = or > is used. This is used to capture results correctly when a result is reported by one lab as for example "<0.2", although results are rarely reported this way from laboratories. By keeping the prefix in a separate item, the result item can be kept as a numeric item. = is set as a default value for the prefix because this is expected for the vast majority of entries.
• In the unit items, standard lists of units adapted to the specific analyte have been added. To cover for possible rare cases when another unit is used, the option "other" can also be included. This is particularly useful for studies where you have many sites, and you know that you will be adding new labs continuously during the study and therefore you do not know what units might be used in the study when you are designing it. Please note that the item for "other unit, specify" is mapped as its own target type in the reference data scope.
  
• The range item is added in order to let the ranges be added appropriately.
• Both the result and range items have been added to allow for 6 decimals. This might seem excessive and is probably more than what will ever be needed. It is recommended that you do not limit the number of allowed decimals too much though, especially when you are planning for a study with many labs and some of them not even known to you at the study configuration stage.
• The evaluation item has a complex visibility condition to ensure that it is only shown when the value is out of range. Please note that this visibility condition could be significantly simpler if the prefix item (<, = or >) was not used.
• Because the evaluation field is triggered for any value out of range, it is generally not required to add validation checks for the standard ranges by default. If validation checks are added on the lab results, they are better used on selective analytes of special importance for a study, such as having an edit check to check if for example Creatinine is > 3 * upper range.
• Finally, for the age factor, the age at the relevant event is used, because the study has a long duration. An option is to use only one age item (for example age at screening) for all lab forms. Using "age at event" will ensure correct ranges are populated even if there are different ranges for different age spans for a specific lab and the subject is moving from one age span to the other during the course of the study. The age will need to be calculated prior to opening the lab form and because there is no need to display the "age at event" for the site staff, the age at event is added in a hidden form, meaning it is added as soon as the event is initiated and therefore always generated when the lab forms are going to be completed.

This is a lab form adapted for data import. The items in this form will need to be adapted to what the lab will transfer.

• Visibility for the activity with each form is controlled by the sample collection form. The lab import form is shown by default and when the sample has been confirmed as taken, but will be hidden if the site confirms that the sample was not taken. Please note that if lab data would be imported to this form, it would still become visible, so there is no risk of hiding data with this approach. Only an uninitiated form can be hidden and remains hidden.
• Most items are designed as free text items. The reason is to make it possible for Viedoc to import all data even if the lab would send data in an unexpected format. For example, < in a result field would not be allowed in a numeric field, and an incorrect date format would be discarded if a date item was used. The exception used is the out-of-range item where we use a drop-down, because we use that result to trigger the evaluation item. The setup will be more flexible if the lab can distinctly trigger and cancel an evaluation field (for example through a data change from "Yes" to "No" for the out-of-range item).
• One single item has been used for a reference ID (called "accession number" in this case as an identifier for the sample) and a sampling date and a sampling time. In this scenario, all results in this form are taken from the same sample, so there is no point in repeating these items for each analyte. Even though the test file includes an accession number, sampling date and sampling time for each analyte, the items are only displayed once in the forms. So for the import, these items are mapped from one of the analytes. This approach can be used when you are confident that results for all or no analytes will be sent. If you have a study where all analytes will not be included in all events, you need to map these variables from an analyte that you know will be present at all events or possibly include these items for all analytes in the form design.
• For the analyte item, a function displays the name of the analyte. It is displayed in its own item in order to include the analyte name as an item in the export. This design is preferred by many because it gives the user more clarity in the export and makes it a little bit more "SDTM-like". An option is to instead specify the analyte name in the label for the result item or as label for the item group.
• In Viedoc Designer, this form might look crowded at a first glance, but less so in Viedoc Clinic. The reason is that we have included result items, units, and ranges in two different units, "reported units" and "SI units".

(1) Reported units are the units that the site will want to see and are used to seeing in lab reports and so on, commonly SI in Europe and conventional in the US. These are also the items displayed in Viedoc Clinic. This will ensure that the site can view and evaluate the lab data in the units they are used to.
(2) The SI units are the units that the data managers and statisticians will want to use for comparing all data and analyzing the results during and after the study. By having them reported in the EDC by the central lab, no conversion is needed at the end. These items are set to "hide always" in the design and will never be displayed in Clinic, but always in the export.
(X) This approach is assuming that the lab can send both the results in reported unit and SI unit. Some sites will have SI units twice, and some sites will have conventional units + SI units. Sites are ensured to always view the data the way they are used to in Viedoc Clinic, and still all data is available with SI units when exported by the Data Manager.

• A comments field per analyte has been included in case the lab needs to send additional information.
• All items will need to be agreed with the lab, see sample Data Transfer Agreement for an example.

• In these forms, date of randomization and time of randomization is populated through functions. This is the date and time when the form was opened, so in theory the exact timing of randomization could be one or several minutes later. This approach is a good way of making the date and time visible immediately in the form, but is only a preference and will not give any other added value. If the exact timing of randomization is needed, you will still have it in the audit trail as "Function execution" by “System (0)” or when exporting the data including "edit status".
• To make the form as clean and as simple as possible, we recommend to hide the items that will be populated through the randomization by using a visibility condition, that is, "i.e. RANDID != null". This way there is minimal risk that the site misunderstands the form and tries to enter data in items that will be populated by the randomization. For a blinded study, the form can also look cleaner if another visibility condition is added on the ARMCD item, "ARMCD != null", so that this is only visible when the treatment is populated, that is, if the subject is unblinded.
  
  Before randomization:
  
  
  After randomization:
  
• A randomization number is used as an outcome of the randomization. This is not required, but preferred by some to give clarity on what subjects that have been randomized. If preferred, this item can also be populated on the subject card.

It is recommended to avoid manual data entry in randomization and kit allocation forms (see below).

Recommendations for use of an input factor
The assumption for the phase II study is a randomization with one input factor: Sex, and 2 outcomes; randomization number (not blinded) and the treatment group (blinded).

Note! For the gender item, manual data entry is not used, but a function to populate this value from its original form, in this case the demographics form.

This is done for two reasons:

• First of all manual data entry within a randomization form should be avoided. Limiting manual data entry in the randomization form will minimize the risk of error prior to randomizing a subject. Therefore, it is recommended to keep the manual entry in the original form.
• The second reason is to keep the possibility of correcting the value. Once randomization is performed, the randomization form will be automatically locked by the system, so in the rare event that the incorrect gender had been given in the demographics form, the site can still correct the value in the demographics form. The randomization form cannot be manipulated. In such a case. it would be clear that a subject was for example randomized as a male, but data has been updated to show that the correct gender for the subject is female.

This form assumes the use of an allocation list and that kits are allocated from a kit list. None of the items in this form are intended for manual entry. Just like with the randomization form, it is recommended to not have any manual entry fields within an allocation form because they will not be editable once the allocation is performed. Because the kit number is the most critical output item, it is kept in a separate item group at the top so that it is displayed clearly.

• Also note that similar visibility conditions like in the randomization forms has been used to only display the items once a kit is allocated.
• In the RTSM settings in the design, "replace allocation" has been enabled to allow for some flexibility in the allocation at the sites. We recommend that "replace allocation" is enabled by default. "undo allocation" has been disabled, because it comes with a slight unblinding concern and should only be used when relevant. It is recommended that "Undo allocation" is disabled by default. If an allocation is undone through the "undo allocation" button, and that same kit is at a later stage allocated to another subject, the end users would understand that those two subjects are on the same treatment. They would not know which treatment it is, but the fact that sites could understand that some subjects are on the same treatment is in most cases a good reason to disable this feature by default. "Undo allocation" is better used in unblinded studies or in studies where a minimum kit waste is more important than the potential blinding issue explained above.
• In the example kit list, the kit number format consists of both numbers and letters. In blinded studies, it is recommended to avoid any kind of sequential numbering for the kits, to avoid showing any kind of pattern that could give away clues of what treatment the kits contain.

This is a standardized questionnaire designed for use in Viedoc Me. Within each item, the field layout is vertical, because this will ensure the answer options are more clearly presented regardless of screen resolution on the subjects' device.

An important consideration when designing forms intended for Viedoc Me is how the items should be grouped. All items within one item group will be displayed on one page in Viedoc Me. Sometimes it is preferable to have fewer and longer pages in Viedoc Me, and sometimes many short pages.

There are no strict rules to apply to this, so you will need to test what is most suitable for each form designed. The general recommendations are to keep the pages fairly short unless there are many similar questions that fall under the same category. In the Viedoc Me forms for this study, the same question is asked for a number of different problems. In such a scenario, it is easy to enter data even if the page is a little bit longer. If each item was a question in its own with a completely different category/question text, it is generally recommended to separate these items in different item groups. For the PHQ-9 questionnaire, the decision was to separate the final item in a separate item group, because this was considered as a completely different question.

A calculation for the total score of the questionnaires has not been added in Viedoc. Although it is possible to add a function for calculating the score in a separate form in a site-initiated event, the needs for the study should be considered. If a total score would be needed for, for example, the continuous safety follow-up of a patient or to take any other action during the study, like changing a subject’s treatment dose and so on, it is warmly recommended to use a function to calculate the score in Viedoc. On the other hand, if it is only used for the final outcome analysis towards the end, it might as well be calculated outside Viedoc by the study statistician.

Please also note how the Viedoc Me events and activities have been configured in the study workflow. The Viedoc Me schedule has been set up so that submissions are expected in association with the clinic events, but with a few days difference from the event date allowed. Reminders have also been activated, to ensure that compliance is as high as possible. Note the visibility conditions for the Viedoc Me events. The Viedoc Me event and corresponding clinic event will be triggered with the same conditions. Thus, the Viedoc Me event will always become visible when the corresponding clinic event does. This is expected to work well in this study, but will be less suitable if a site is running several events behind in data entry. If that is a concern, you could consider triggering all Viedoc Me events upfront. In such a scenario, you could add visibility conditions to hide uninitiated events as soon as a subject is withdrawn, to avoid them from showing when no longer relevant. So be mindful of how the visibility for the Viedoc Me events is used.

Three separate Viedoc Me reminders have been set up. Under normal circumstances, one reminder is sufficient, but when low compliance is a concern, you could consider using multiple reminders.

The intended workflow is the following:

1. The site starts the process by completing the Video Upload form and uploading a video.
2. An email alert is generated to two different roles: “Reviewer 1” and “Reviewer 2”.
3. The users with access as “Reviewer 1” and “Reviewer 2” have view access only to the Video Upload form and edit access to Reviewer 1 Assessment form (for the Reviewer 1 role only) and Reviewer 2 Assessment form (for the Reviewer 2 role only). So a reviewer cannot view the other reviewer’s assessment.
4. The reviewers perform their reviews independently and they can enter their assessments without affecting each other or requiring any additional action from the site. If they consider the quality of the recorded video to be too low, an email alert is sent back to the site, so they know they need to record a new video. And a tracker is set up in the email alert so that if a new video is uploaded, a new email is generated to the reviewers.
5. The reviewers’ assessments are in this study used to provide an “assessment score”. This is not visible for the site staff or the study team.

• In the assumptions for this study, the assessments by the reviewers should be blinded for the entire study team. Therefore, a single role, "Reviewer Oversight", has been created to review the data and status of all forms (including the reviewers’ assessments). If the reviewers assessments do not need to be blinded to the study team, this role is not necessary and instead monitors, data managers, project manager and so on can have access to view these forms.
• In the reviewer assessment forms, any data generated by the reviewers could be collected, for example “tumor size”, “wound size”, and “disease progression”. It does not necessarily need to be an assessment on an uploaded file, but could also be review of other data that are relevant for the study. This workflow could be expanded further to feed information of the results of the assessments back to the site through additional email alerts, for example “subject is eligible”, “safety concern, subject should be withdrawn”, or “treatment dose to be reduced”.

There are several advantages of using Viedoc for a workflow like this: the email alerts will ensure that appropriate actions can be taken quickly, all assessments are properly documented, and they are all available in the same system.

For the body system (physical examination) item and analyte (serology), a function displays the name of the body system/analyte. It is displayed in its own item to include the body system/analyte as an item in the export. This design is preferred by many because it gives the user more clarity in the export and makes it a little bit more "SDTM-like". This approach has also been used in the lab forms for the template studies

An option is to instead specify the body system in the label for the item or as label for the item group.

As the name suggests, this is a hidden form in Viedoc Clinic (yet visible in study design) with two items with different purposes:

• The first item only returns the status of the subject to the subject card. A function in this item in the form returns the subject's status and this is populated on the subject card. This item is only included in the study start event, because it is only needed once. The auto-update function is enabled for the form so that this function is always validated when any form for the subject is saved. This is a good example of when it is suitable to use the auto-update function in the form settings, because it is needed for the function to work as intended and also because it is only one form per subject. It is recommended to use auto-update with caution, to avoid having a high number of forms being validated upon saving one individual form (that could be the case if auto-update is being used on multiple forms, or one form present at many events).
• The second item calculates the "age at the event" (see lab forms for reference data editor for more information). In this scenario, the hidden form is being used on multiple events, but because there is only one item per event, and there are not too many events with the hidden form, using an auto-update function is in this setup considered acceptable. If the hidden form included more items and validations and/or present in more events, there would be reason to reconsider using auto-update for a form like this.

The recommended approach is to use a leading question to capture whether an overall assessment was performed, for example, "Was the physical examination performed?". This can even be set to YES as a default value in the item function settings to simplify data entry. In this form, an alternative approach has been used for capturing details if an examination of each body system has not been performed. Normally, for each body system, it would be recommended to use the system functionality to confirm items as missing if an assessment has not been performed. This requires a reason to be provided by the site and it will be flagged for the monitor to approve. The items confirmed as missing are also included in the query export, which makes them easy to identify in any given study. Therefore, this is the recommended approach to use.

However, in certain scenarios, although rare, this is not desired. One example could be if the study has an exploratory part, or for any other reason, expect and accept that there will be a lot of assessments/examinations not performed and there is no need to flag this or capture the reason for why the assessment was not performed. In such a scenario, this design with "not done-checkboxes" for each (or all) body system will mean fewer clicks and quicker data entry from the site staff if many assessments are expected to be missing. The downside would be a reduced control, because these items will not be flagged for the monitor and a reduced overview of missing values because you would have to collect this information in different items and forms. So this approach is not recommended, unless there is a good reason to use it.

In this study, height is collected once, but weight and the BMI in several events. Note that the BMI calculation compares the weight of the current event with the height of the screening event.

Note! In pediatric studies, where height changes during the study are expected, the height will commonly be collected in each event, and BMI will be calculated from height and weight in the same form.

Oncology studies can often have a complex workflow. In this design, we assume a study where data needs to be collected from several treatment days only during the first treatment cycle, but for remaining treatment cycles data is only registered for the first day. If the need for the study is different and some limited data needs to be collected for multiple days within multiple cycles, it could also be considered to add multiple days within each event and let an event constitute an entire treatment cycle rather than an individual day in the treatment cycle. If such an approach is used, each day in the treatment cycle could be set up within a separate activity.