Summary

This article describes the configuration options available to Trial Designers for configuring adjudication functionality within Fountayn.

Table of Contents

• Overview
• Determining Adjudication Workflow Requirements
• Casebook Design
  • Define Form Types and Complete Forms Template
  • Define QuestionTypes for Related Forms
    • Adjudication Assignment
    • View Display Type
    • Reader/Reviewer Assessment Form
    • Outcome Form
• Role Configuration
  • Data Entry Roles
    • Restart Adjudication Permissions
    • Update Dynamic Permissions
• Form Flow Configuration
  • Form Flow Example for Adjudication Process
  • Step 1: Form Flow for Adjudicated Form – New and Entered Statuses
    • Create Flow Configuration Row for AE/Image form
    • Define ‘New’ Status Configuration Row for AE/Image form
    • Define ‘Entered’ Status Configuration Row for AE/Image form
    •  Define Flow Status Permissions for New and Entered Statuses
  • Step 2: Form Flow for Adjudicated Form – Rejected Status
    • Define ‘Rejected’ Status Configuration Row for AE/Image form
    • Define Flow Status Permissions for ‘Rejected’ Status
    • Define Manual Flow Transition From ‘Entered’ to ‘Rejected’ Status
  • Step 3: Form Flow for Adjudicated Form – Adjudication Status
    • Define ‘Adjudication’ Status Configuration Row for AE/Image form
    • Define Flow Status Permissions for ‘Adjudication’ Status
    • Define Manual Flow Transition From ‘Entered’ to ‘Adjudication’ Status
  • Step 4: Form Flow to Hide Outcome and Assignment Forms
    • Create Flow Configuration Row for Outcome Form
    • Define ‘Hidden’ Status Configuration Row for Outcome Form
    • Define Flow Status Permissions for ‘hidden’ Status
• App Property Configuration
  • Adjudication Action Handler Properties
  • Adjudication Save Handler Properties
  • Assignment Form Properties
  • Facilitation Task Properties
  • Adjudication Task Properties
• Outcome Form Properties
  • Compare Question Set and Assessment Properties
  • Assessment Complete Detection
  • Adjudication Statuses
  • Dynamic Permission Properties

Design | System

Overview

This page describes the configuration options available to Trial Designers for configuring adjudication functionality within Fountayn. Specific details of the configuration and workflows described can vary from the examples used below, depending on the needs of the study. The design workflow described below is comprised of 5 steps.

• Determine the Adjudication workflow requirements
• Casebook (form and question structure) design
• Role Configuration
• Form Flow design and related Form Flow permissions
• Configuration of Application Properties

Determining Adjudication Workflow Requirements

Prior to completing the casebook design and proceeding with the configuration of other adjudication features, you must first determine the workflow that will be used in your study. One possible workflow, using 3 adjudicators, is described below:

1. Data requiring adjudicator review is entered or imported into EDC (for example image or safety data).
   1. After entry, a user in role X reviews the form and assigns the status of ‘Adjudication Needed’ or ‘Adjudication Not needed’.
   2. When ‘Adjudication Needed’ is selected, the form ‘Adjudication Assignments’ is inserted beneath the form. This form contains fields for assigning a responsible ‘facilitator’, who will then assign 2-3 reviewers for the event. When a facilitator is assigned, a User Task will be created and visible in the User Tasks Manager (link, add page).

Note: Steps 2 and 3 represent an optional workflow, the configuration for which will be described below. Alternatively, step 2 can be bypassed and the creation of the ‘Adjudication Assignments’ form can be automatically inserted upon save of the form in step 1, using typical form creation script programming.

2. Only the selected ‘Facilitator’ will have the ability to complete the reviewer assignments. Upon assignment, Reviewer tasks will be created for the initial reviewers, and the following forms will be inserted beneath the Assignment form:
3. One form for each of the initial Reviewers, visible to only that Reviewer and other configured roles and editable by only the named user.
4. Outcome form, which will typically collect the overall status of the review as well as tracking of assessment consensus for each field designated for review comparison.
5. As each Reviewer completes his/her task, the Outcome form is updated with the current status (such as ‘Waiting for initial assessments’, ‘Third reviewer is needed’, ‘Complete with 2 assessments’ or ‘Complete with 3 assessments’).
6. The overall status is also visible on the Assignments form, as is an indicator of the status of each individual review.
7. If a third Reviewer is needed due to lack of consensus between the first two, a Reviewer Task will be created and the third Reviewer form will be created if/when the third reviewer is assigned.

Determining the details of the workflow are critical to defining the scope of the design, including the forms needed, roles involved in the adjudication process and their needed access rights, and the visibility of adjudication forms to other roles.

Casebook Design

Based on the defined requirements, the casebook (forms and questions) should be built using a variety of question and display types.

Define Form Types and Complete Forms Template

Define the formTypes to be used for Adjudication Assignment, Reviewer assessment, and Adjudication Outcome

• Use your desired variables for these forms. They will be referenced in the configuration of various properties to add in the Adjudication functionality.
• Only one formType is needed for Reviewer/Adjudicator Assessment forms. They should be assigned unique Form Ids on the Forms Template worksheet, as you would for any form that is reused, and auto create should be set to ‘False’.
• Typically, the Assignment form is defined with an autocreate setting of ‘False’, and as the parent of the Reviewer Assessment and Adjudication Outcome forms.

Define QuestionTypes for Related Forms

Adjudication Assignment

1. For questions such as Facilitator Assignment, where the answer options should be based on specific users with the necessary role:
   • Set Display Type (Column D) to ‘User’
   • Set Answer Options / Default Value (Column F) to ‘havingRoles: roleName’ where roleName is the exact name of the user role (defined on the Roles Worksheet) to be evaluated (for example, ‘Facilitator’).

2. For questions such as Reader Assignment, where the answer options should be based on specific users with the necessary role and should create a subform with edit access limited to the selected user:
   • Set Display Type (Column D) to ‘UserForSubForm’
   • Set Date Format (Column E) to the formID of the related subform (for example, for the question Reader A, this value may be set to ‘adjA’, where ‘adjA’ is the Form Id of an instance of the Adjudication Form). Ensure that each Reader Assignment question points to a different instance of the adjudication form.
   • Set Answer Options / Default Value (Column F) to ‘havingRoles: roleName’ where roleName is the exact name of the user role (defined on the Roles Worksheet) to be evaluated (for example, ‘Reader’).
   • Typically, a FormFlow is configured to limit visibility of this form to other roles.

View Display Type

To define questions which should display the current value of a question on another form, use the ‘view’ display type. Note, this display type will result in a question that is displayed on the form to support data entry and review, but will not collect/store metadata. Additionally, the values of these questions will only be displayed in the dataset where they are originally collected.

1. Specify the questionTypeId in Column A
2. Set the Display Type (Column D) to ‘View’
3. Set the Answer Option / Default Value to the relative or absolute path to the source question.

Note: As a short cut, you can also configure the questionTypeId (Column A) to be question_view, where question is the source questionType that will be used. For example, to populate the collected aeterm value on the Assignment form, define the new questionType as aeterm_view. In this case, the Answer Option/Default Value can be set to one of the following values, depending on the location of the source question:

If the source question value needs to be displayed in multiple locations with different relationships to the source question, you can specify up to two additional instances using questionTypeIds question_view2 and question_view3. Use this configuration to display the status of each individual review/assessment beneath the assigned reviewer. (See item 4 below).

Reader/Reviewer Assessment Form

1. By default, all questions will be used in the comparison for Reader agreement, however this is configurable. (See App Properties section below)
2. The comparison process will evaluate the question across each Reviewer/Adjudicator form to determine if values are an exact match. Using free text questions (as opposed to Select or RadioCheckbox) will increase the likelihood of a difference being detected, as the comparison is case and spacing sensitive.
3. Use the ‘View’ display type described above to display the current value of a question on another form, for example to pull in specific values of the image or event being reviewed.
4. Define a question to capture the status of the individual review.
   • Display Type: RadioCheckbox or Select
   • Answer Options: By default, the system will use stored value of ‘01’ to mean ‘Complete’. However, alternate values can be configured. (See App Properties section below).

Outcome Form

To define questions for the Outcome form, follow these tips:

• Define a questionType for tracking the overall Adjudication Status as a single choice question (RadioCheckbox). The value will be automatically assigned by the system during the adjudication process. The following answer options and associated meanings will be used by default, although these can be configured differently (See App Properties section below).

• Define a question to track the status of each individual Reviewer/Adjudicator. This question should be a single choice question with only one answer option, using a stored value of ‘true’ to indicate ‘Done’ or ‘Complete’.

The remaining questions used for the outcome form should be defined as follows:

• Evaluation comparison questions – each question being answered by an adjudicator and used for comparison should also be added to the outcome form. It can be added by reusing the same questionType, however be aware of any dependency expressions programmed for use on the adjudication form that are not intended for the outcome form and adjust dependency programming accordingly. If a unique questionType is defined, the questionId must match the questionId used on the reviewer form.

• When at least the minimum number of adjudicators agree on the same value, the value will be populated to this field. When less than the minimum number of adjudicators agree on a common value, the field will be left empty.
• Comparison assessment questions – This question stores the results of the comparison of the associated questionType across adjudicators. For each questionType being compared for agreement between adjudicators, define a questionType as follows:
• QuestionTypeId should be questionType­_assessment, where questionType represents the questionType of the comparison question. For example, if each adjudicator is answering a question with questionType aeseryn, the questionType for the comparison results question should be aeseryn_assessment.
• Display type should be Select or Radio Checkbox
• Answers will be assigned by the system during the adjudication process, based on the defined answer options. Default options/meanings are below, but can be configured differently. (See App Properties section below).

• Assessment details questions – This question displays the stored data values of all adjudicators in cases where the assessment of the responses shows dissent/disagreement. Define the questionType as follows:
• QuestionTypeId: questionType­_assessment_details, where questionType represents the questionType of the comparison question. For example, if each adjudicator is answering a question with questionType aeseryn, the questionType for the assessement details question should be aeseryn_assessment_details.
• Data Type: String
• Display Type: PlainText
• Visibility: Optionally, this can be set to ‘False’ (no quotes). This will prevent the question from being displayed by default. If the system assigns a value in the case of disagreement, the visibility logic is overridden.

Once defined, all questions should be added to the Question Layout – Template and Display worksheets.

Role Configuration

Data Entry Roles

Define roles and permissions for each role that will be involved in the adjudication process. Role names can vary based on your own requirements; however the example below defines one possible scenario.

• Each of the above roles should be granted the permission to enter data. Data restrictions will be handled as outlined above.

• Each role above and any other role requiring access to view Adjudication user tasks should be granted access to one or both of the permissions below:
•  The usertaskManager screen will provide users access to the User Tasks Manager.
• The viewAllUsersTasks screen will provide roles with usertaskManager access the ability to see all tasks assigned to all users. Without this permissions, users in roles with usertaskManager access will see only their own individual tasks

Additional configuration on the roles worksheet will be needed once Form Flow Statuses are designed. This configuration is described in Form Flow Configuration section below.

Restart Adjudication Permissions

If the adjudication configuration will have the ability to restart the adjudication process, the ‘Adjudication Restart’ permission will need to be configured. The configuration of this permission will be handled as outlined below:

Update Dynamic Permissions

If Adjudication functionality is added or modified post-deployment, the Update Dynamic Permissions utility may be needed. Define which user role will be responsible for Updating Dynamic Permissions during a mid-study change. This would typically be a Trial Designer or similar role.

More details and how this will look to the end user can be found on the ‘Standard Actions – Miscellaneous’ Fountayn Knowledge Base page.

Form Flow Configuration

Form flow supports the transition of forms from status to status, where unique visibility and editing permissions can be assigned to the form based on the status it is in. Status transition can occur programmatically, via a defined Flow Dependency (link), or through a manually defined Flow Transition. Adjudication configuration can use both types of status transitions. When a user role has no visibility or access to a formType in a defined form flow status, the queries and alerts on those forms are also not visible to the user role in the related manager. For this reason, in addition to the below described form flow configurations, you should define a form flow status for each form outside of the adjudication process that should not be visible to adjudicators and other roles.

Form Flow Example for Adjudication Process

The specific details of the Form Flow configuration will depend on the desired requirements/workflow. Consider the following example Adjudication workflow:

1. Upon entry of data and saving a form to be reviewed in Adjudication (such as image data or an Adverse Event), the form is transitioned to a status of ‘Entered’
2. The Data Entered status adds two buttons to the form: Ready for Adjudication and Adjudication Not Needed, which are available to a specified role. If the user selects the Adjudication Not Needed button, the form is placed in the Rejected status, which can have specific editing and visibility rights defined for each role. If desired, an automatic transition back to the ‘Data entered’ status can be programmed if data on the form is changed, allowing it to be re-evaluated for Adjudication. See Flow Dependency question.data.x.y (link to that Fountayn Knowlege Base page).
3. If the user selects the Ready for Adjudication button, the form is placed into the Adjudication status, which creates the Adjudication Assignment form as a subform.
4. The creation and visibility of individual Assessment forms (once assignment has been made) is controlled by Adjudication App Properties (see App Properties below). However, Form Flow will be needed to hide other forms (such as the Outcome or Assignment forms) from other roles.

Review Form Flow Design for general instructions on configuring Form Flow, and follow the examples below for configuring the above-defined workflow.

Step 1: Form Flow for Adjudicated Form – New and Entered Statuses

Create Flow Configuration Row for AE/Image form

1. FormTypeId: Enter the FormType ID for the form (ae, image, etc.)
2. Status Id: Enter ‘*’
3. Attributes: Enter default=’InitialStatus’ where InitialStatus is the name of the starting status (to be defined below) for the form. For example, default=’new’

Note: If no default value is provided, the first configured status is used as the default status.

Define ‘New’ Status Configuration Row for AE/Image form

1. FormTypeId: Enter the FormType ID for the form (ae, image, etc.)
2. Status Id: Enter a number value. This value should be unique, and is often assigned sequentially.
3. Status Name: Enter a status name that is unique for this specific formType, for example ‘new’
4. Status Label: Enter a label for the status which will be displayed in the system. For example ‘Not Yet Entered’
5. Flow Dependencies: Enter the flow dependency used to automate the transition of the form from this status to the ‘entered’ status, which should occur upon data entry to the form: question.data.x.y=’status.entered’

Define ‘Entered’ Status Configuration Row for AE/Image form

1. FormTypeId: Enter the FormType ID for the form (ae, image, etc.)
2. Status Id: Enter a number value. This value should be unique, and is often assigned sequentially.
3. Status Name: Enter a status name that is unique for this specific formType, for example ‘entered’. Be sure the value used here matches the value used in the flow dependency defined above.
4. Status Label: Enter a label for the status which will be displayed in the system. For example ‘Data Entered’
5. Attributes: Enter ensureSubform=’formTypeAssignmentForm’ where formTypeAssignmentForm is the formType of the form being used to assign facilitators, adjudicators, etc. This setting will trigger the creation of that subForm when the ‘entered’ status is achieved.
6. Flow Dependencies: No flow dependency is needed, as the progression of the form from this status to another status will be handled manually.

 Define Flow Status Permissions for New and Entered Statuses

1. On the Roles tab, scroll to the ‘Flow Status’ permission section.Define the first Flow Status permission for the ‘new’ status:
   1. Flow Status: Enter ‘fflw#formtype.new’ (where formType is the formTypeId used in the above form flow configuration). For example: fflw#ae.new
   2. Flow Status Permission: Enter ‘form.write’.
   3. Assign Permission: Place an ‘X’ for each role that should have ‘write’ access to the form.
2. Define the second Flow Status permission for the ‘new’ status
   1. Flow Status: Enter ‘fflw#formtype.new’ (where formType is the formTypeId used in the above form flow configuration.) For example: fflw#ae.new
   2. Flow Status Permission: Enter ‘form.read’.
   3. Assign Permission: Place an ‘X’ for each role that should have ‘read’ access to the form.
3. Repeat for any additional Flow Status Permissions needed for this form in the ‘new’ status.

Note: If a role is not granted any of the configured flow status permissions, the formType will not be visible to the role when in the specified status.

4. Define the first Flow Status permission for the ‘entered’ status
   1. Flow Status: Enter ‘fflw#formtype.entered’. For example: fflw#ae.entered
   2. Flow Status Permission: Enter ‘form.write’.
   3. Assign Permission: Place an ‘X’ for each role that should have ‘write’ access to the form.
5. Define the second Flow status permission for the ‘entered’ status
   1. Flow Status: Enter fflw#formtype.entered. For example: fflw#ae.entered
   2. Flow Status Permission: Enter ‘form.read’
   3. Assign Permission: Place an ‘X’ for each role that should have ‘read’ access to the form.
6. Repeat for any additional Flow Status Permissions needed for this form in the ‘new’ status

Step 2: Form Flow for Adjudicated Form – Rejected Status

Define ‘Rejected’ Status Configuration Row for AE/Image form

1. FormTypeId: Enter the FormType ID for the form (ae, image, etc.)
2. Status Id: Enter a number value. This value should be unique, and is often assigned sequentially.
3. Status Name: Enter a status name that is unique for this specific formType, for example ‘rejected’
4. Status Label: Enter a label for the status which will be displayed in the system. For example ‘Adjudication Not Needed’
5. Flow Dependencies: No flow dependency is needed, unless it desired to have the form return to the ‘Entered’ status in cases where data is updated after being rejected.

Define Flow Status Permissions for ‘Rejected’ Status

1. On the Roles tab, scroll to the ‘Flow Status’ permission section.
2. Define the first Flow Status permission for the ‘rejected’ status
   1. Flow Status: Enter ‘fflw#formtype.rejected’. For example: fflw#ae.rejected
   2. Flow Status Permission: Enter ‘form.write’
   3. Assign Permission: Place an ‘X’ for each role that should have ‘write’ access to the form
3. Repeat for the form.read Permission any additional Flow Status Permissions needed for this form in the ‘rejected’ status.

Define Manual Flow Transition From ‘Entered’ to ‘Rejected’ Status

Follow the below instructions to define the button that will appear on the FormType (for example, ‘Adjudication Not Needed’) and the status associated with clicking that button

1. On the Roles tab, scroll to the ‘Flow Transition’ permission section.
2. Configure the transition:
   1. Flow Transition: Enter ‘fflow#formtype.entered>>formtype.rejected’ to specify the transition will be from the ‘entered’ status to the ‘rejected’ status. Example: fflw#ae.entered>> ae.rejected
   2. Flow Transition Label: Enter the text label for the button, for example ‘Adjudication Not Needed’
   3. Transition Attributes: Enter any attributes to be associated with transitioning to the status, for example allowing or requiring a comment.
   4. Assign Permissions: Place an ‘X’ for each role that should have the ability to perform the transition. The role should also have form.read or form.write level permission to the form when it is in the starting status (in this case, ‘entered’)

Step 3: Form Flow for Adjudicated Form – Adjudication Status

Define ‘Adjudication’ Status Configuration Row for AE/Image form

1. FormTypeId: Enter the FormType ID for the form (ae, image, etc.)
2. Status Id: Enter a number value. This value should be unique, and is often assigned sequentially.
3. Status Name: Enter a status name that is unique for this specific formType, for example ‘adj’
4. Status Label: Enter a label for the status which will be displayed in the system. For example ‘Adjudication’
5. Flow Dependencies: No flow dependency is needed, as the progression of the form from this status to another status will be handled manually.

Define Flow Status Permissions for ‘Adjudication’ Status

1. On the Roles tab, scroll to the ‘Flow Status’ permission section.
2. Define the first Flow Status permission for the ‘rejected’ status:
   1. Flow Status: Enter ‘fflw#formtype.adj’. For example: fflw#ae.adj
   2. Flow Status Permission: Enter ‘form.write’.
   3. Assign Permission: Place an ‘X’ for each role that should have ‘write’ access to the form, including any role that should be able to enter data on any subform (such as the Assignment subform).
3. Repeat for the form.read Permission any additional Flow Status Permissions needed for this form in the ‘adj’ status.

Define Manual Flow Transition From ‘Entered’ to ‘Adjudication’ Status

Follow the below instructions to define the button that will appear on the FormType (for example, ‘Ready for Adjudication) and the status associated with clicking that button

1. On the Roles tab, scroll to the ‘Flow Transition’ permission section.

   

2. Configure the transition:
   1. Flow Transition: Enter ‘fflow#formtype.entered>>formtype.adj’ to specify the transition will be from the ‘entered’ status to the ‘adj’ status. Example: fflw#ae.entered>> ae.adj
   2. Flow Transition Label: Enter the text label for the button, for example ‘Ready for Adjudication’
   3. Transition Attributes: Enter any attributes to be associated with transitioning to the status, for example allowing or requiring a comment.
   4. Assign Permissions: Place an ‘X’ for each role that should have the ability to perform the transition. The role should also have form.read or form.write level permission to the form when it is in the starting status (in this case, ‘adj’)

Step 4: Form Flow to Hide Outcome and Assignment Forms

Typically, the Outcome and the individual Reviewer Assessment forms are not visible to all roles. These and any additional forms that should be hidden from some roles will need to have a Form Flow Configuration.

Create Flow Configuration Row for Outcome Form

1. FormTypeId: Enter the FormType ID for the Outcome form (For example: imageout, cecadjout)
2. Status Id: Enter ‘*’
3. Attributes: Enter ‘default=InitialStatus’ where InitialStatus is the name of the starting status (to be defined below) for the form. For example, default=’hidden’.

Note: If no default value is provided, the first configured status is used as the default status.

Define ‘Hidden’ Status Configuration Row for Outcome Form

1. FormTypeId: Enter the FormType ID for the form (imageout, cecadjout, etc.
2. Status Id: Enter a number value. This value should be unique, and is often assigned sequentially.
3. Status Name: Enter a status name that is unique for this specific formType, for example ‘hidden’
4. Status Label: Enter a label for the status which will be displayed in the system. For example ‘Not Visible to All Roles’
5. Flow Dependencies: No other statuses are needed to hide the form, therefore no Flow Dependency is needed.

Define Flow Status Permissions for ‘hidden’ Status

1. On the Roles tab, scroll to the ‘Flow Status’ permission section.
2. Define the first Flow Status permission for the ‘hidden’ status:
   1. Flow Status: Enter ‘fflw#formtype.hidden’. For example: fflw#imageout.hidden
   2. Flow Status Permission:Enter ‘form.read’.
   3. Assign Permission: Place an ‘X’ for each role that should have ‘read’ access to the form.
3. Typically, form.write permissions are not needed for the individual Reviewer Assessment forms and the Outcome form. Access to write to the individual assessment form is already controlled by other elements of the Adjudication configuration, and the Outcome form is typically fully populated by the system. However, when configuring a ‘hidden’ status for other forms, a form.write level of permissions may be needed.

Repeat all above steps to hide the Assignment form and other formTypes as needed.

App Property Configuration

Adjudication functionality allows for the configuration of several App Properties which control the workflow. Properties below are grouped by their function within the Adjudication Process. In cases where default values are specified, the property does not need to be explicitly configured if the default should be used.

Adjudication Action Handler Properties

The actionHandler property must be configured for each Assignment formType and Adjudicator’s Interpretation formType to identify the forms which ‘Restart Adjudication’ can be initiated. This is an optional property and is not needed within the core configuration of adjudication.

Adjudication Save Handler Properties

The saveHandler property must be configured for each Assignment formType and Adjudicator’s Interpretation formType to identify that an adjudication workflow will be used. The value will determine the minimum and maximum number of assessments used in the workflow.

Assignment Form Properties

The following properties identify specific components of the Adjudication form/question design that should be designated for use in the Adjudication workflow.

Facilitation Task Properties

The following properties can be used to configure options for facilitation tasks.

Adjudication Task Properties

The following properties can be used to configure options for adjudication tasks.

Outcome Form Properties

The following properties identify specific components of the Outcome form/question design that should be designated for use in the Adjudication workflow.

Compare Question Set and Assessment Properties

The following properties specify behavior for Assessment form comparison.

Assessment Complete Detection

The following properties specify determination of an assessment being complete.

Adjudication Statuses

The following properties specify the values used to display the Adjudication Status on the Outcome form, based on the completion of individual assessments and the comparison of questions.

Dynamic Permission Properties

The following properties are configured to specify the dynamic permissions used in the adjudication workflow. With Dynamic Permissions, a user’s access permissions do not depend on a role configuration, but on expressions configured for individually referenced questions. Dynamic permissions are required for the Assignment Form, when only a selected user shall perform the adjudicator assignments.

Note: QuestionTypes that are hidden by role using dynamic permissions should have a 'Blank Check' value of 'None' (or field left blank) and should not have any dependencies configured for them. 

Need more help?

Please visit the Fountayn Contact Information page.