Integrations

Oracle Site Select provides optional account integration solutions at access (user authentication), data (API), and application levels. Use settings on the Account integrations page to manage API tokens, configure PUSH event notifications, setup digital signature authentication, configure survey vendor authentication, and define preferred user authentication.

Data Integration APIs

Oracle Site Select uses RESTful APIs, formatted as JSON objects, strings, and arrays to send information between systems. This is a well-understood and well-supported technology capable of handling complex and high-volume messages. The APIs accept requests as JSON objects encoded using the UTF-8 character set.

Oracle Site Select supports the following API routes:

• Version GET – Fetch the version and host name of the Oracle Site Select instance hosting the API
• Datasource PUT – Add datasources to a study by sending an array of IDs to identify all datasources that should be attached to the study
• Datasource GET – Fetch a list of datasources in an account
• Datasource and Composite Datasource Counts GET – Fetch the counts of entities in a flat or composite datasource
• Datasource Records PUT, GET, and DELETE – Imports one or more records into a datasource; returns a record from a datasource; or physically deletes an investigator, institution, or site record from a datasource
• Composite Datasource Records PUT and DELETE – Import one or more entity (investigator, institution, site, trial, or trial_site) records into a composite datasource; retrieves investigator, institution, site, trial, or trial_site record from composite datasource; or physically delete an investigator, institution, site, trial, or trial_site record
• Datasource Clone – Clone an existing composite or flat datasource within your organization's account and keep the existing data column mapping of the cloned datasource.
• Study Put and GET – Create a new or update an existing study, retrieve information about an existing study, or retrieve a list of studies within an account.
• Study Sites in Study PUT, POST, and GET – Invite a study site to a study; import a site record from a datasource into a study and create a study site; or fetch information related to a specific study site like bucket state, profile details, and more.
• Document Library PUT, POST, and GET – Upload, update, or download a document scoped to institution or investigator.
• Document Download GET – Download a workflow document with a specific document ID.

You can access API documentation with full Request/Response details for the APIs using the link above the API token field on the Integrations page. Alternatively, click the circular avatar at the far right of the page header, and choose API documentation. Both options open the API documentation page in a new browser tab.

The REST apis page also provides options to generate or regenerate the API token. Please use the regenerate option with care, as regenerating the inbound API token will invalidate the existing token, and you must confirm this action. Invalidating will break all existing integrations. If you proceed, please ensure to update all existing integrations with the new token. Click the "copy to clipboard" button to copy the new token.

Event notifications

Oracle Site Select offers an optional PUSH service that sends event messages to a customer’s deployed and managed integration endpoint(s), such as a Clinical Trial Management System (CTMS). When configured, the PUSH service sends a JSON format POST message for each site profile, site status, or investigator library document update event.

Site profile updates

The PUSH service sends a POST message to the configured endpoint(s) when an Oracle Site Select or site portal user saves the site profile, regardless of whether the user edits the profile and saves it. Updates to an investigator, institution, or site's datasource record do not initiate a POST message for a site profile change.

When pushed, the POST message for a site profile update event includes the following fields:

A-I	I-P	P-Z
address_1 address_2 city compound country customer_last_updated_at degree department fax_number first_name institution institution_data_sources institution_fax_numbers institution_integration_id institution_phone_numbers institution_sip_id institution_staff institution_status institution_status_reason institution_type investigator_data_sources investigator_integration_id investigator_sip_id	investigator_status investigator_status_reason irb_coord_email irb_coord_first_name irb_coord_last_name irb_coord_phone_number irb_type last_name middle_name npi oracle_master_profile_id phone_number pi_address_1 pi_address_2 pi_central_irb_experience pi_city pi_country pi_department pi_emails pi_postal_code pi_region pi_state protocol_number	protocol_title site_data_sources site_integration_id site_last_verified_at specialties state study_id study_indications study_name study_phase study_sponsor study_status study_therapeutic_area study_type studysite_id suffix therapeutic_area title trial_coord_email trial_coord_first_name trial_coord_last_name trial_coord_phone_number zip

Site status

When configured for the account, the push service sends a site status change notification message each time a site has moved bucket states, provided the site is beyond Nominate Step 1 (i.e., Master list, Review, and Dropped bucket states). Messages are not sent for sites added to or moved within Step 1. This is expected behavior.

When pushed, the POST message for the site status change event includes the following fields:

A-I	I-P	P-Z
address_1 address_2 bucket_after bucket_before bucket_state_after bucket_state_before city compound country department first_name gb_additional_site_staff institution institution_data_sources institution_integration_id institution_sip_id institution_type investigator_data_sources	investigator_integration_id investigator_sip_id last_name middle_name oracle_master_site_id phone_number pi_address_1 pi_address_2 pi_city pi_country pi_emails pi_postal_code pi_state protocol_number protocol_title site_data_sources site_department site_integration_id	site_sip_id specialties state study_id study_indications study_integration_id study_name study_phase study_sponsor study_status study_therapeutic_area study_type studysite_id suffix title updated_at updated_by_emal updated_by_full

The PUSH message also identifies the user who performed the status change (i.e., “updated_by”) as follows:

• If the create/update occurs as an action within Oracle Site Select, the PUSH message includes the user’s full name and email address
• If the create/update occurs as an action via API, the PUSH message includes the user's full name as "Site Import," and the user’s email will be <null>

On the Event notification configuration page, account administrators can optionally configure a list of email addresses that receive notification in the event of a event message failure. The administrator can configure the notification list separately for Site profile, Site status, or Library documents event notification messages.

An internal service checks for failed event messages every three hours. If an event message fails to send, each email address configured for that event message type receives a templated notification about the failure.

Investigator document library

When an account has a primary composite datasource created, the account administrator can configure event notification messages that send each time an investigator library entry has been created or updated within Oracle Site Select, site portal, or via API. The PUSH service sends a message to the configured endpoint, and customers can use the message to keep their systems updated with changes to an investigator's document library.

The PUSH service does not send the document file itself, but rather the associated metadata. Customers that require the document can request it using the Document Library GET API described below.

When sent to the configured endpoint, the PUSH service notification message includes the following metadata, as appropriate:

A-D	D-I	I-Z
accept_text attestation created_at created_by_email created_by_full_name decline_text document_file document_get_route document_id	document_type invalid_reason investigator_id investigator_integration_id investigator_sip_id is_invalid is_invalid_by_email is_invalid_by_full_name is_invalid_on	is_latest_version response_accepted response_by_email response_by_full_name response_change_reason response_on updated_at updated_by_email updated_by_full_name

When you have a role with API and Authentication Management permission, you can define Event notification endpoints for the Site status, Site profile, and Library document update event message types, as appropriate to the account. You can also set up email notifications for individuals who should receive notice of failed messages.

Event notification message history

When you have a role with the API and Authentication Management permission, you can track the status of messages sent via event notification message integration. The Event notification message history and status page, accessed from the Account menu, shows a list of matching event messages sent outbound based on your specified date range, status, and type search criteria. For instance, you can filter the list to see only Successful Document library event messages sent this week.

The sortable result list includes a scrollable message content field and other message details. Each row also includes a Response link (opens the response object in a modal window) and a Resend or Retry action button. Resend and Retry will re-queue the exact message to resend or retry based on any updated integration settings (URL, security, etc.). If you click Resend or Retry, the original message's action button is disabled, and the table will list the newly queued message as a separate row upon page refresh.

Digital signature configuration

When you have a role with API and Authentication Management permission you can configure electronic and digital signature authentication on your account’s Account management: Integrations page. Your organization can use any contracted Adobe Sign account you prefer. User and permission management is the responsibility of your organization. Site users will be created in the Oracle Adobe Sign account.

To configure, you'll input your organization's proprietary account data for the following required fields:

• Customer Adobe sign account URL
• Application client ID
• Application client secret

When authenticated to Adobe Sign with your organization's account credentials, Adobe Sign creates signature transactions in your organization's account. For example, in an Oracle Site Select environment configured with customer-provided account credentials, the your organization can authenticate a user on a European Union (EU) server to activate digital signatures on the account, and signature transactions will be created in the your organization's EU Adobe Sign account.

In the customer-provided account credential model, your organization has responsibility for Adobe Sign user and permission management. For example, an EU user should be granted transaction creation/management permissions in Adobe Sign. Note that site user signature accounts are created only in the Oracle Adobe Sign account.

Note:

Oracle Site Select creates a document sign transaction by specifying the email and name of the site user who will sign the document. If that site user needs to create an account, the site user will receive an email from Adobe Sign and Adobe Sign will manage the creation of the site user's account.

Survey vendor configuration

When you have a role with API and Authentication Management permission you can authenticate your Oracle Site Select account to your organization's Alchemer account.

Oracle Site Select customers outside of the United States can authenticate with the Alchemer European Union server if appropriate using the option in the Alchemer hosting region drop-down.

On the study Feasibility survey setup page, Oracle Site Select persists the chosen server region (e.g., EU) to the study level when Alchemer is set as the account survey vendor. When the account is configured to authenticate to the Alchemer EU region server, and the Oracle Site Select survey administrator visits the Feasibility survey page, the administrator must sign in to Alchemer to direct authentication to the Alchemer EU authentication page. All survey data for that study survey will reflect from the authenticated EU Alchemer account.

User Authentication

All Oracle Site Select customers use Oracle Identity Cloud Service (IDCS) for user authentication. Users can access Oracle Site Select and other licensed Oracle Identity Cloud Service applications using a single login portal when enabled and configured for the account. This authentication method also supports automatic, just-in-time user account provisioning in Oracle Site Select to provision new users with a default user role. Oracle Identity Cloud Service also supports federation with a customer's existing identity management solution.

Note:

An Oracle representative must enable integration with Oracle Identity Cloud Service at the customer account level. Please contact your Oracle client services representative to discuss requirements.

When your account has been enabled and if you have a role with API and Authentication Management permission, you can configure this authentication on the User authentication tab on the Account management: Integrations page. When enabled, the Oracle IDCS configuration section will include SSO URLs as well as several additional fields that let you specify:

• Entry point
• Issuer
• Default role
• IDCS logout URL
• IDP public certificate

If you disable authentication for an account where an IDCS configuration was enabled and saved, the saved configuration will persist should the authentication be re-enabled. This includes persisting the IDP public certificate. Additionally, for an account where IDCS integration is turned off, the configuration can still be provisioned or updated via API. The changes will persist should an Oracle Site Select user enable or re-disable the integration.

When enabled for the account, IDCS Test Mode allows users to authenticate to Oracle Site Select via ICDS or the configured local or IDP (SSO) method. If testing mode is enabled but IDCS is later disabled, an Oracle Site Select user cannot log in via IDCS and must use the configured local or IDP method. API administrators with access to the ICDS provisioning API can toggle the IDCS testing mode on and off via API.

You can optionally configure authentication method(s) specifically for Oracle Site Select testing purposes. Under the Select login test preference section specify an authentication type:

1. User name and password (standard local login)
2. Single Sign On (SSO)

User name and password

Manual login with user name and password is the default user authentication method in the testing authentication section. This option allows for periodic password changes and users can manually change their passwords at any time using a reset option in their user profiles. If you choose this authentication method, the Oracle Site Select login page displays upon either manual or timed logout.

Single Sign On (SSO) - Oracle Site Select users

Single Sign On (SSO) authentication requires integration between Oracle Site Select and your organization's trusted Identity Provider (IDP) system (e.g., an employee portal). When you choose this authentication method for testing, you will see URLs under the Authentication type drop-down that you will use to manage your account’s Oracle Site Select IDP configuration. You'll need to specify the Entry point URL, Issuer, Default user role, and upload the IDP public certificate in the appropriate fields.

The SSO integration you set up for testing will affect all users in the Oracle Site Select account. Once enabled, SSO authentication overrides the default user name and password authentication, and all users in the account must access Oracle Site Select via SSO.

Log in controls:

• The customer IDP or portal controls access to Oracle Site Select. Oracle Site Select will authenticate based on the customer's IDP settings.
• A user who is part of an account that has SSO enabled but attempts to login directly via the Oracle Site Select login page is redirected to the IDP instead.
• An SSO user will not be able to log in to Oracle Site Select directly using a SSO password and will not have the ability to change the SSO password in Oracle Site Select. The user will redirect to their IDP and must be authenticated via SSO.
• A user who attempts to access Oracle Site Select but does not have an active IDP session redirects to the account's IDP for login. Once authorized, the user will be redirected and logged into Oracle Site Select.

Oracle Site Select SSO uses the SAML authentication protocol and will accept the following properly formatted elements to authenticate an individual user:

1. Email address
2. First name
3. Last name

Upon log out, Oracle Site Select redirects the user to the IDP entry point URL configured for the account. If a user’s Oracle Site Select session times out, and if the user is still logged in to the IDP, the user will be able to log back in with a click of a button. When SSO users manually log out of Oracle Site Select, they will also be redirected to the IDP entry point URL configured for the account.

Single Sign On (SSO) - Site portal users

For testing you can also optionally configure SSO authentication for invited sites. When a site accesses the site portal via SSO authentication, studies to which the site has access are limited to those in which the site has been invited to participate within the logged-in account. By design, site users can log in manually to access studies in another account, if necessary. Upon timeout or manual log out, site portal users who logged in with SSO are redirected to their IDP.

• Access API documentation
  By design, you must be logged into the Oracle Site Select application to access the link to API documentation.
• Generate API access token
  When you need to generate an API access token for use with a Oracle Site Select API, you can do so with one click then copy the token to your clipboard for use.
• Regenerate API access token
  You can regenerate an API access token if one was already created for your organization's account and you need to replace it.
• Copy API access token
  Once you generate or regenerate an API access token, you can copy the token's text as needed.
• Enable event notifications
  The optional PUSH service sends a JSON format POST message for each site profile, site status, or investigator library document update event. The event messages transmit to one or more of your organization's deployed and managed integration endpoint(s), such as a Clinical Trial Management System (CTMS).
• Retry or resend event messages
  You can track the status of event history notification messages and resend or retry messages when necessary.
• Enable Adobe Sign Integration
  Administrative users can enable their document signature workflow to allow digital signatures using any contracted Adobe Sign account they wish. Oracle Site Select currently supports an integration with Adobe Sign for the CDA workflow only.
• Configure survey vendor integration
  Enable Alchemer survey integration and authenticate your Oracle Site Select account to your Alchemer account.
• Configure user authentication
  Your organization's account will be configured to authenticate with Oracle Site Select via Oracle's Identity Cloud Service (IDCS). This service can be federated with your own identity provider (IDP) so your users will not be managed in two separate systems. The IDCS configuration will be set by Oracle services and managed by Oracle support.
• Enable preferred test authentication method
  You may configure a secondary (non-Oracle IDCS) authentication method for testing purposes. This can either be via the Oracle Site Select login page (local login) wherein user management is performed directly in the application, or via single sign-on (SSO) with your identity provider.