Understand signature configurations

As a sponsor user, your study may encounter different scenarios where a signature is required, such as signing the subject's entire casebook, or signing a specific visit or form.

By creating custom signature configurations, you can:

• Allow sites to sign off at the form or visit level for given forms and visits using customized affidavits.

  For example, having specific configurations to sign adverse events, adjudication forms, or other specific forms that capture certain protocol deviations. See Define a signature configuration at the form or visit level.

• Define casebook signature configurations to sign all data in a subject's casebook.

  The Casebook Signature configuration is generated by default and it is listed as required by all users with the Approve and sign subject data permission. However, you can further define additional details about the casebook signature, including setting it as optional. See Define signature configurations at the casebook level.

What sponsor users must know

Before you begin your work with signature configurations, consider the following to assure you approach your task properly:

Concept	Description
Permission to create signature configurations	You must be assigned the Manage signature settings permission in order to create and edit signature configurations.
Display of signature elements	Signature elements on the Study and Subject homepages are hidden by default for existing studies. In the Study Settings, selecting Yes for the Display signature elements for site staff and sponsors option enables the Signature widget to display in Production mode, while the Signature Request side panel appears in all modes. Warning: It is not possible to go back and select No for the Display signature elements for site staff and sponsors option once Yes has been selected and saved for the corresponding mode.
Signature configuration	To add more than one combination of an affidavit and role(s) for a given set of forms or visits, you must create an additional signature configuration for each combination. Every form that has been created is available in the Forms list when creating a signature configuration, regardless of whether they have been assigned to a visit or not. If a new visit is named the same as a deleted visit, both appear as options in the Signature Configuration.
Signature configuration: Roles who can sign	When defining the roles by which a given signature is required, only roles with permission to sign will appear in the configuration drop-down list. These permissions include Approve and Sign Assigned Data Only and Approve and sign subject data. Template study roles will not appear in the drop-down list for form and visit level signatures. If more than one role is selected in a signature configuration, a user assigned any of the selected roles can sign and fulfill the signature requirement. If two roles are required to sign, then two signature configurations are required. When a role referenced in a signature configuration has been retired, it will not be removed from the signature configuration, but the role will no longer have the ability to sign the data. When removing signature related permissions from study roles, be aware that if a role is still referenced in a signature configuration they no longer have permission to sign. The Sign option will still be available, but users will receive an error when attempting to sign.
Updates to existing signature configurations	Modifications made to a signature configuration are applied to unsigned data and data that has never been signed, but does not affect signed data unless it becomes unsigned. Note:Changes in configuration are handled asynchronously. This means it may take up to 60 minutes for new or updated signature requests to apply in your study.
Overdue signature notifications	Once a signature's target date has been reached or become overdue, you have the option to trigger an email notification each day until the overdue signature is applied. For notification details, see the Signature request notification.
Overall signed status	Standalone form or visit level signature configurations and the casebook level signature configuration are mutually exclusive. This means a form or visit will be in an overall signed status of Partially Signed until all the applicable required signature configurations are signed. These could be at the form or visit level, and the subject's casebook signature. In general, that depends on whether the casebook signature is either required or optional: If the casebook signature is required, the overall signed status changes to signed only when both the casebook level signature and any configured form or visit level signatures have been completed. Note: The system does not store partial signatures at the subject level. Subjects can only be signed, unsigned, or never signed. If the casebook signature is optional, it impacts the overall sign status at each level: If no other signature configuration applies (like at the form or visit level), the item level signature is driven by the casebook signature. This means that, even if it is optional, if the casebook is signed all items, forms and visits for the subject are also signed. If another signature configuration applies, the item level record is not driven by the casebook signature configuration. This means that if an item is signed as part of the casebook signature but not as part of the required applicable signature configurations, the overall sign status remains as unsigned or never signed. The item only changes to a signed status if signed at all the applicable signature configurations (disregarding the optional casebook signature). If all visits and forms that have configured signatures are signed, regardless of the status of other visits and forms with no applicable signature configuration defined, those signed visits and forms but also the subject get an overall status of signed. The other visits and forms that don't have a defined signature configuration may remain unsigned or never signed. The overall signed status is persisted in the system and flows to Oracle Clinical One Analytics.