InForm On Demand Integrations Service Descriptions

Version 3.0 Page 1 of 55

HSGBU InForm On Demand Integration Service Descriptions and Metrics

04-June-2015

Table of Contents

INFORM ON DEMAND INTEGRATIONS - DIRECT DATA LOADER (DDL) ................................................. 2

INFORM ON DEMAND INTEGRATIONS – EXTRACT ON DEMAND (EOD) ............................................... 11

INFORM ON DEMAND INTEGRATIONS – HISTORICAL LOGIN REPORT (HLR) .................................. 19

INFORM ON DEMAND INTEGRATIONS – AUDIT TRAIL REPORT (IATR) ............................................... 22

INFORM ON DEMAND INTEGRATIONS - IRT.................................................................................................... 25

INFORM ON DEMAND INTEGRATIONS – STANDARD FILE-BASED INTEGRATION* ......................... 30

INFORM ON DEMAND INTEGRATIONS – LAB NORMALS MANAGEMENT TOOL (LNMT) ............... 39

INFORM ON DEMAND INTEGRATIONS – REPORT EXTRACTOR (RE) .................................................... 45

INFORM ON DEMAND INTEGRATIONS – SUBJECT DATA REFERENCE (SDR) ..................................... 50


InForm On Demand Integrations - Direct

Data Loader (DDL)

This is the Services Description for Oracle InForm On Demand Integrations - Direct Data Loader (DDL) to

Customer’s master ordering document for Oracle HSGBU SaaS Services (“Study Order”). This Schedule describes the services provided to Customer for the study listed in each applicable study order under the master ordering document (“Study”). Further details of the Services are shared at the outset of each engagement. The services described herein are part of the SaaS Services provided under the terms of the ordering document. Capitalized terms not otherwise defined herein shall have the meaning ascribed to them in the ordering document, including the HSGBU SaaS Definitions Schedule referenced in the master ordering document. This Schedule is subject to change at Oracle’s discretion; however, Oracle will not materially reduce the level of services provided under this Schedule for the duration of the master ordering document referencing this schedule.

1.0 Overview of Services

The Direct Data Loader (DDL) for InForm™ ITM is designed to facilitate the loading of data files received from External Vendors directly into the InForm™ ITM Reporting Database. DDL accepts flat files via Oracle’s sFTP server, processes those files and imports the data into the InForm reporting database. The imported data is accessible via InForm ad-hoc reports, custom reports, and reporting database extracts. Oracle will provide you with Services for DDL in three phases: FastStart, FastForward, and FastLock. The activities related to these Services are bounded by the parameters in section C of the Study Order and described in more detail below. During the FastStart phase (“Study Setup”), Oracle provides Services related to project initiation and application set-up tasks to ready the DDL application for User Acceptance Testing (UAT). During the FastForward phase (“Study Conduct”), Oracle provides Services related to UAT, DDL application usage, and environment management and maintenance. The FastForward phase starts at the delivery of the InForm Study for UAT and concludes upon trial lock. During FastLock (“Study Closure”), Oracle provides Services leading to decommission of the DDL application.

DDL file processing and loading consists of the following steps:


1) Data files from external vendors are placed in a designated sFTP directory on the Oracle sFTP

server for each study.

2) The DDL solution detects each uploaded file and immediately moves it into the processing queue.

3) If previous files are not being processed at the time of file arrival then the file is processed

immediately.

4) File processing includes preliminary checks and any errors found during the preliminary checks

are logged and made available via the user interface.

5) After the preliminary checks are run and erroneous records are filtered out, the remaining data is

loaded into InForm Reporting.

6) Email notification can be configured to report the load status to a predetermined list of email

addresses.

7) Successfully loaded data is accessible via InForm ad-hoc reporting, custom reports, and reporting

database extracts.

8) Unsuccessful loads are logged and accessible via the DDL administration tab within the InForm

portal.

2.0 Deployment and Environments

Your DDL application will be deployed in a hosting facility and will be maintained and managed by Oracle. The deployment of DDL will be for two instances of a single Study: Production and UAT. The Production instance is the instance which will be used to capture the clinical data (“Data”). The UAT instance will be used to perform User Acceptance Testing pre-go-live and will be used to test changes and fixes post-go-live. (Note, DDL will not be deployed for a Training instance of a Study.) Each instance will be associated with a secure FTP location unique to each Vendor or Data file type for the delivery of data files to be imported by DDL.

3.0 Users and Access by Users

The Services are intended to be used by personnel related to your study as authorized by you. Normally

this consists of three main groupings of personnel: Sponsor, Site, and Patient. The Sponsor group

typically consists of personnel from your company and may also include other sub-contracted personnel

such as Contract Research Organization personnel, Monitors, and Data Managers. The Site personnel

typically consist of the Site Coordinators (Clinical Research Coordinators) and Study Investigators

(Principal Investigators and Sub-Investigators). The Patient population is not expected to interact with

DDL.

4.0 Deliverables and Customer Dependencies

The deliverables for a given project are dependent upon the components included in that project. Not all projects will produce all of the deliverables listed below. Some common deliverables that apply to most projects include:

Data Requirements – These are written by the Oracle project team to document the customer specific data file configuration needs for the DDL Integration. It will also include the necessary external data type definitions necessary to accommodate the DDL Integration.


Vendor Requirements – These are written by the Oracle project team to document the vendor specific configuration needs for the DDL Integration including user access and email notification options.

Project Plan – This plan will be created and maintained by the Oracle Project Manager. It will detail the tasks, timelines, and milestones that Oracle and you are responsible for, as applicable.

Communication Plan – This document is created and maintained by the Oracle Project Manager. It describes the team members, their responsibilities, and their contact information.

DDL Release for UAT – This is the initial release by Oracle of the configured DDL application in a UAT instance of the production environment to enable your UAT to be held.

DDL Application Release for Go-Live – This is the Production release by Oracle of the configured DDL application that customer-approved end-users may access.

Changes and Fixes to the Production DDL Application – Related documents are created by Oracle and approved by you.

Database Extracts – These database extracts may be used by you to analyze and report on your data captured by the configured DDL application. It is your responsibility to request an export online and to download it to a secure location.

Archival Documentation – This is a package of documentation that was maintained by Oracle during the course of the study. After the DDL application is decommissioned, this package is sent to you for archiving.

Help Desk Support – User support will be accessible via local phone numbers (toll-free where available at Oracle’s discretion).

Maintenance of the Production Instance – Oracle will maintain the production instance in

accordance with support services, including product upgrades to new releases and in-place upgrades and migrations in accordance with Oracle InForm Lifetime Support Policies. Upgrades are applied per InForm server and all trials on the same server are upgraded at the same time. Migrations typically include a trial move to a new hardware server. Upgrades and migrations are scheduled with You and are performed during the maintenance window for Production trials. Oracle will coordinate change management requests required for upgrades and migrations..

Maintenance of the UAT Instance – Oracle will update the UAT instance with a fresh extract of the Production instance each time a change or fix to the Production DDL Application needs to be tested by You. This involves removing the UAT instance (including UAT data) and replacing it with a fresh extract of the Production instance containing all the data as it exists in Production. Oracle will maintain the UAT instance in accordance with support services, including product upgrades to new releases and in-place upgrades and migrations in accordance with Oracle InForm Lifetime Support Policies. Upgrades are applied per InForm server. Migrations typically include a trial move to a new hardware server. Upgrades and migrations are scheduled with You and are performed during business hours for UAT trials. Oracle will coordinate change management requests required for upgrades and migrations.

Your responsibilities for a given project are dependent upon the components included in the project. Examples include but are not limited to:

Delivering clear and complete requirements in accordance with the agreed timeline planning. These may include form, study configuration, and database requirements. If final requirements are not available, you and Oracle may mutually agree to begin study design with draft requirements. This latter approach may be subject to additional fees.

Providing input into the creation and maintenance of the project plan as requested by the Oracle Project Manager.

Negotiating in good faith an estimated timetable for any revised or additional milestone dates that are introduced after the initial timeline agreement.

Ensuring that all key stakeholders, decision-makers, and team members are present and/or involved with all key meetings and deliverables (i.e., planning and review of the DDL application specifications, user acceptance testing, etc.).


Ensuring that all key stakeholders, decision-makers, and team members adhere to the agreed timelines.

Ensuring specifications meet the regulatory requirements for the study.

Acceptance of design specifications in a timely manner.

Acceptance of the configured DDL application for release to UAT and for release to go-live.

Testing the DDL application (UAT) to your own standard operating procedures and/or work instructions and for creating and testing your own test cases. This includes capturing UAT feedback that is clear, reproducible, and actionable in the Oracle-provided template. If changes introduced during UAT are required, the change management process will be followed (including additional fees and time).

Ensuring that all users are trained prior to accessing the system. This includes maintaining all training records.

Managing and overseeing third party vendors (i.e., lab vendors, external Customer partners, etc.).

Reviewing and approving documents related to Production DDL application changes and fixes.

5.0 Acceptance of Deliverables

Upon completion of any deliverable, Oracle may provide a copy thereof to you. You will be responsible for any additional review and testing of such deliverable in accordance with any mutually agreed review criteria or test scripts. If the deliverable does not conform with any such review criteria or test scripts, you shall have three (3) business days after Oracle’s submission of the deliverable (“acceptance period”) to give Oracle written notice which shall specify the deficiencies in detail. Oracle shall use reasonable efforts to promptly cure any such deficiencies. After completing such cure, Oracle shall resubmit the deliverable for your review and testing as set forth above. Upon accepting any deliverable submitted by Oracle, you shall provide Oracle with written acceptance of such deliverable. If you fail to provide written notice of any deficiencies within the acceptance period, as provided above, such deliverable shall be deemed accepted at the end of the acceptance period.

6.0 FastStart

FastStart consists of activities prior to the availability of the configured DDL application for User Acceptance Testing (UAT).

6.1. Prerequisites

Coordination is required between you, the data file supplier(s) and Oracle to ensure the data files provided adhere to the DDL external data file requirements and are consistent with conventions agreed upon between you and the data file suppliers.

Specifications for data to be loaded must be incorporated into the study and form layout.

6.2. Integration Process

Project Management

The Oracle Project Manager will:

Develop a project plan detailing study tasks and milestones.

Coordinate Oracle project team efforts.

Track study/project progress.

Work to ensure the following major sign-off milestones are achieved: o Approval of specifications o Release for User Acceptance Testing (UAT)


DDL Configuration

Oracle will:

Gather the requirements and configuration settings necessary to meet the Customer’s needs.

Generate design specifications from Customer-supplied requirements.*

Configure DDL components as defined in the design specifications. o Create study eCRF configurations corresponding to the specified data file(s). o Create external data type specification files (EDTs) corresponding to the specified data

file(s). o Perform smoke testing to validate the designs and configurations. o Document the test cases needed for this DDL configuration, and perform formal testing of

the DDL Integration using sample data files.

Create secured FTP file directories according to the configuration specified in the Vendor specification requirements document.

Install and configure DDL in the Customer’s UAT environment.

Once testing is complete, install and configure DDL in the Customer’s formal Production (LIVE) environment

*One design iteration is included for the design specifications.

Formal Testing

Oracle will:

Conduct an independent validation of DDL configuration by testing components against approved specifications.

DDL Hosting and Application Management

Oracle will:

Set up the production environment and deploy the DDL configuration in the UAT instance for user acceptance testing.

7.0 FastForward

FastForward consists of activities from availability of the configured DDL application for UAT through confirmation by the customer of completion of trial lock.

Project Management

Oracle will manage the following activities:

One (1) User Acceptance Testing (UAT) findings meeting.

Change Order scoping and initiation, as needed.

Meetings to discuss Change Order deliverables, as needed.

User Acceptance Testing

Oracle will:

Address issues that you find in UAT.

If required, deploy the new configuration to the UAT environment for you to conduct UAT round two.

o If additional rounds of UAT are required, the Change Order process will be followed (including additional fees and time).


Oracle will:


Update the UAT instance with a fresh extract of the Production instance and configuration of DDL only if required, each time a study fix or study Change Order needs to be tested.

o Your use and Oracle’s maintenance of the UAT instance is limited to the implementation of fresh extracts when study fix or study Change Order related corrections are required.

Manage the Production and UAT instances within the production environment.

8.0 FastLock

FastLock services consist of those relating to the management of the production environment from confirmation by you of completion of trial lock to Study Decommission.

Project Management

Oracle will:

Liaise with your team for activities needed to close out the study.


Oracle will:

Remove the UAT DDL configuration instance.

Manage and maintain the Production study DDL configuration until Study Decommission.

Decommission and recycle the study environment.

Provide associated project documents to you. This will include a copy of the Study Lifecycle Records pertaining to the DDL configuration.

9.0 Assumptions & Limitations

1) External Data will not be loaded into InForm core.

a. Loaded data will not be viewable within eCRFs

b. Sites will not see data in InForm

c. Rules will not be applied to data

d. The loaded data will be available within the “Clinical Data Model” for reporting purposes (both

AdHoc and Custom) using the InForm Reporting functionality

e. The loaded data will be available within the InForm reporting database extract.

2) DDL does not provide facilities for editing data – all corrections will be the responsibility of the data

supplier.

3) DDL will display only the latest data loaded from a data provider in reporting. There will not be an

audit trail in InForm reporting.

4) DDL pricing includes the integration of up to 5 data type specification files (EDTs) and eCRF pairs

and up to 10 historical data files archived. (This does not include data imported into the reporting

database.)

5) You are responsible for managing the relationship and communication with the data file supplier(s).

6) The customer and data file suppliers are responsible for correcting and resubmitting rejected records

if records are rejected due to study or data supplier oversights.


7) Performance is dependent on the number and size of files being imported in a given interval.

8) If you/data file supplier cannot meet the DDL base requirements, Oracle may provide programming

services at additional cost.

10.0 Data File Requirements

The following requirements must be met for all data files generated by the data file supplier and

transferred to Oracle for import by DDL.

Data files must be received in ASCII text format.

If a file is compressed in zip format then the zip file must contain single data file without any

directories/folders. (The optional compressed file password will be configurable within the solution.)

A data record must only exist on a single line.

A field delimiter is configurable within the solution. Most common delimiters are pipe "|" and comma

"," with optional quotes for values that contain comma within text.

Empty fields in a record must be designated by two consecutive delimiters.

Every record must contain the same number of fields.

Each data record in the data file must contain fields that constitute a key to uniquely identify each

record.

Data file may be cumulative (All unchanged, changed and new records must exist in the data file to

be uploaded.)

Data file may be incremental (The incoming file will contain records that were created, changed, or

deleted between the last and current data transfers. Records that were not included in the

incremental transfer are assumed to be unchanged by the solution.)

The solution supports transaction type flags with each data record signifying Insert, Update, Delete,

and Retransmit transactions. This will allow support for incremental CDISC transfers where

transaction flags are:

"I" for Insert

"U" for Update

"M" for Delete

"R" for Retransmit

When a transaction specified by a transaction type flag cannot be performed then an error will be

generated.

The solution optionally can process Insert and Delete transactions sent in the same data file.

Data types supported are: Text, Integer, Float, and Date

11.0 File Naming Conventions

Data files sent by the data file supplier to Oracle must adhere to specific file naming conventions

in order to satisfy the requirements for uniqueness and the target destination for processing.

The data file name must be ASCII case insensitive.

A file name must contain the EDT name separated from the other file name components by an

underscore.

Enforcing the existence of the study name within the file name can be optionally selected by

setting an appropriate configuration setting.


12.0 Data Transfer Procedure

All data transfer procedures documented here conform to the Oracle Cloud for Industry (OCI) Secure Data Transmission Standard. Changes to the OCI Secure Data Transmission Standard supersede any data transfer mechanisms described in this document.

The data file supplier must transmit the data files across a secure SFTP channel to the specified

Oracle sFTP server. Data will be sent to a study specific folder on the Oracle sFTP server. The

customer and Oracle users will have access to all folders under a customer’s root, however the

data file supplier will only be granted to the specific DDL integration folder. The folder structure

will adhere to the Oracle standard.

The DDL Windows Service on the machine that hosts the InForm study will monitor this folder on

the Oracle sFTP server for any new data files. Once a file has completed uploading it will be

moved from the Oracle sFTP server, processed and loaded into the appropriate study specific

DDL data repository. The compressed version of the original data file will be archived in

persistent data storage, and viewable on the DDL Log Viewer page within the InForm Portal.

13.0 Secure FTP (sFTP) Access

All data file access must be done using sFTP in accordance with the Oracle Cloud for Industry (OCI) Secure Data Transmission Standard. Changes to the OCI Secure Data Transmission Standard supersede any file access mechanisms described in this document.

Data file suppliers must have a supported sFTP client to login to Oracles’ hosted sFTP server at

sftp.webcrf.net and transmit files. Oracle supports the following sFTP clients:

SecureFX from Vandyke Software (preferred client)

WS_FTP Pro Version 9 from IPSwitch

Putty Command line client

Win SCP

All data file suppliers will be granted named user accounts with access privileges to the

appropriate study DDL folders. Accounts will be created according to Oracle’s SFTP Service

Policy.

Data supplier user accounts can access multiple study folders. If a data supplier account is

associated with more than one study folder, then the data supplier’s transfer process will be

required to navigate to the appropriate folder after login. This navigation can be done through

use of the appropriate commands depending upon the sFTP client.

14.0 Error Handling

Oracle SFTP Server

SFTP provides authentication, data compression and file integrity algorithms to make sure that

the file received is the same as the file that was sent. If there is a connectivity issue to the Oracle

sFTP server (either from the data supplier or from the InForm server), then Oracle Customer

Support will be notified and will resolve.

DDL Import


In terms of importing data into DDL data repositories in the reporting database, audit logs will be

generated for every import indicating success or failure. The audit log along with the copy of the

data file will be stored in persistent data storage, and viewable on the DDL Log Viewer page

within the InForm Portal. The solution can be configured to send email notifications for success

and error.

15.0 Oracle Cloud Policies The Services are subject to the Oracle Cloud for Industry Hosting and Delivery Policies document, which

is part of the Service Specifications of Your order and may be viewed at www.oracle.com/contracts.

15.1. Disaster Recovery Specifications

The Recovery Time Objective (RTO) is 90 days.

The Recovery Point Objective (RPO) is 48 hours.

15.2. Target System Availability Level

The Target System Availability Level is ninety-nine percent (99%).

http://www.oracle.com/contracts


InForm On Demand Integrations –

Extract On Demand (EoD)

This is the Services Description for Oracle InForm On Demand Integrations – Extract On Demand (EoD)

(“Schedule”) to Customer’s master ordering document for Oracle HSGBU SaaS Services (“Study Order”). This Schedule describes the services provided to Customer for the study listed in each applicable study order under the master ordering document (“Study”). Further details of the Services are shared at the outset of each engagement. The services described herein are part of the SaaS Services provided under the terms of the ordering document. Capitalized terms not otherwise defined herein shall have the meaning ascribed to them in the ordering document, including the HSGBU SaaS Definitions Schedule referenced in the master ordering document. This Schedule is subject to change at Oracle’s discretion; however, Oracle will not materially reduce the level of services provided under this Schedule for the duration of the master ordering document referencing this schedule.


Extracts on Demand (EoD) for InForm™ ITM is designed to facilitate the request and delivery of clinical data extracts from within the Oracle hosted environment. Data extracts are available on demand via a tab within the InForm Portal. Alternatively, the extracts can be delivered via Oracle hosted secured FTP server on a regularly scheduled basis. Oracle will provide you with Services for your study in three phases: FastStart, FastForward, and FastLock. The activities related to these Services are bounded by the parameters in section C of the Study Order and described in more detail below. During the FastStart phase (“Study Setup”), Oracle provides Services related to project initiation and application set-up tasks to ready EoD for User Acceptance Testing (UAT). During the FastForward phase (“Study Conduct”), Oracle provides Services related to UAT, EoD usage, and environment management and maintenance. The FastForward phase starts at the delivery of the InForm Study for UAT and concludes upon trial lock. During FastLock (“Study Closure”), Oracle provides Services leading to decommission of EoD.

Extracts on Demand facilitates the ad-hoc or scheduled delivery of clinical data extracts to the

customer.

1) The EoD solution is available as a tab within the InForm Portal.

2) A list of the available extract types and its versions are displayed for selection.


3) Extract types are made available when the customer has elected that option. Extract types

include:

a. InForm Reporting database extracts (RDE)

i. Detailed outline of RDE schema and view definitions are described in the InForm

product documentation, InForm Reporting Database Schema Guide under

subsection Reporting Database Extracts (RDEs).

ii. In addition to the eCRF specific datasets, a set of default trial operational views are included in the RDE Analytics. These views contain select trial design metadata, trial object and administrative data, and trial operational data. Using the key variables, data in these views and can be joined with the eCRF specific datasets. Please refer to the list below for a detailed list of the specific trial operational views provided with the RDE Analytics

iii. 'IRV_STUDYVERSIONS'; 'IRV_STUDYVERSION_VISITS';

'IRV_STUDYVERSION_FORMS'; 'IRV_MD_FORMS_CONTROLS'; 'IRV_CUR_CONFIG'; 'IRV_CUR_RULE'; 'IRV_CUR_RULEITEM'; 'IRV_CUR_SITE'; 'IRV_CUR_SUBJECT'; 'IRV_SUBJECT_STATE_CHANGES';

'IRV_SYSTEMVERSIONS'; 'IRV_CUR_USER'; 'IRV_CUR_USERLIST'; 'IRV_USERS_SITES'; 'IRV_SV_SUBJECTVISITS'; 'IRV_AF_SUBJECT_FORMS'; 'IRV_FORM_ITEMS'; 'IRV_CUR_COMMENT'; 'IRV_CUR_QUERY';

'IRV_QUERY_STATE_CHANGES'; 'IRV_FORM_ASSOC'

b. SDTM extracts

c. Custom Data extracts (CDE)

d. Oracle Clinical extracts (OC)

4) Data is extracted in one of the following formats, where available : a. SASD - Individual SAS datasets (.sas7bdat files) for each dataset b. SAST - A single SAS Transport file in (CPORT and limited XPORT) formats c. TRANS - A single Oracle export file (dmp) d. ACSV - ASCII (CSV, XML, PIPE) formats e. Trial Study Extracts (TSE / ADMP) – Oracle EXP, or Data Pump formats

5) Extracts are cumulative, NOT incremental.

6) Extracts can be requested on an ad-hoc basis and retrieved directly from the InForm Portal or

delivered to the Oracle secured FTP server.

7) Extracts can be scheduled for delivery and delivered to an Oracle secured FTP server.

8) Email notifications are sent to customers indicating a successful extract is available for download

on the InForm Portal.

9) Email notifications are sent to customers indicating a successful scheduled extract is available for

download on the Oracle secured FTP server.

2.0 Functional Overview

http://www.oracle.com/technetwork/documentation/hsgbu-clinical-407519.html

http://www.oracle.com/technetwork/documentation/hsgbu-clinical-407519.html


Extracts can be requested via the InForm Portal (or scheduled and generated at predetermined intervals); however, each extract will require the following steps.

Oracle Steps 1. The data is extracted from the InForm ITM system. 2. A zip file containing either the Oracle export file, CSV files, SAS transport file, or SAS datasets is

downloadable via InForm (or placed on the Oracle sFTP server). 3. An email notification is sent to the email address identified on the DOD Request tab in the InForm

Portal (or the user identified when the schedule is configured) indicating the presence of a new extract.

Customer Steps 4. User downloads the file from the InForm Portal (or retrieves the file from the sFTP server). 5. User imports the extract into the target system.

Standard Request / Data Delivery Process

Extracts can be requested from InForm using the DOD tab in the InForm Portal. A list of the available formats for the particular study is presented in the “Extract Type” dropdown. The corresponding versions available for the selected Extract Type will be displayed for selection.

The version of the Extract Type that was initially deployed for a study will be identified with an asterisk and the version drop down will default to that version. When other extract versions become available the study can be updated to default to the newer version. Once the extract has been generated, an email notification will be sent to the address(es) identified on the DOD tab. The user can then login to InForm and download the extract from the list of available extracts on the DOD tab in the InForm Portal.

A user can also request an ad-hoc generation of the extract and have the results placed on the sFTP server in addition to having the results downloadable from the InForm Portal. The path for the file location on the sFTP server is configured during the provisioning process.

o sftproot\<sponsor>\<trialname>\outbound

3.0 File Format and Naming Convention


Extracts will be delivered as a zip file containing either a SAS transport file, SAS datasets, CSV files, or an Oracle dmp file along with a corresponding log. Details for each file format and contents are listed below.

Oracle Batch filename <trialname>_rdeAora_<today’s_date>.zip RDEoD filename <trialname>_<YYYYMMDD>_<HHMM>_RDE-ADMP.zip

- <trialname>_rdeAora_<today’s_date>.dmp - Oracle_Export_<today’s_date>.log

CSV Batch filename <trialname>_rdeCora_<today’s_date>.zip RDEoD filename <trialname>_<YYYYMMDD>_<HHMM>_RDE-ACSV.zip

- <datasetname>.csv SAS Transport File Batch filename <trialname>_rdeSAS_<today’s_date>.zip RDEoD filename <trialname>_<YYYYMMDD>_<HHMM>_RDE-SAST.zip

- transport.xpt - ProcContents.lst - CreateSASRDEOutput.log

SAS Datasets Batch filename <trialname>_rdeSAS_<today’s_date>.zip RDEoD filename <trialname>_<YYYYMMDD>_<HHMM>_RDE-SASD.zip

- <datasetname>.sas7bdat files - ProcContents.lst - CreateSASRDEOutput.log

Since many extract files will be created, it is important that the naming of the files is unique using a date

component. The date will be formatted to MMDDYYYY


Your EoD application will be deployed in a hosting facility and will be maintained and managed by Oracle.

The deployment of EoD will consist of two instances: Production and UAT. The Production instance is

the instance which will be used to capture the clinical data (“Data”). The UAT instance will be used to

perform User Acceptance Testing pre-go-live and will be used to test changes and fixes post-go-live.

(Note, EoD will not be deployed for a Training instance of a Study)







(Principal Investigators and Sub-Investigators). The Patient population is not expected to interact with

EoD.




Requirements – These are written by the Oracle project team to document the EoD configurations. Requirements may include user rights access, notifications, etc.

EoD Release for UAT – This is the initial release by Oracle of the configured EoD application in a UAT instance of the production environment to enable your UAT to be held.

EoD Release for Go-Live – This is the Production release by Oracle of the configured EoD application that customer-approved end-users may access.

Changes and Fixes to the Production EoD Application – Related documents are created by Oracle and approved by you.

Database Extracts – These database extracts may be used by you to analyze and report on your data captured by the configured InForm Study. It is your responsibility to request an export online and to download it to a secure location.



accordance with support services, including product upgrades to new releases and in-place upgrades and migrations in accordance with Oracle InForm Lifetime Support Policies. Upgrades are applied per InForm server and all trials on the same server are upgraded at the same time. Migrations typically include a trial move to a new hardware server. Upgrades and migrations are scheduled with You and are performed during the maintenance window for Production trials. Oracle will coordinate change management requests required for upgrades and migrations .

Maintenance of the UAT Instance – Oracle will update the UAT instance with a fresh extract of the Production instance each time a change or fix to the Production EOD Application needs to be tested by You. This involves removing the UAT instance (including UAT data) and replacing it with a fresh extract of the Production instance containing all the data as it exists in Production. Oracle will maintain the UAT instance in accordance with support services, including product upgrades to new releases and in-place upgrades and migrations in accordance with Oracle InForm Lifetime Support Policies. Upgrades are applied per InForm server. Migrations typically include a trial move to a new hardware server. Upgrades and migrations are scheduled with You and are performed during business hours for UAT trials. Oracle will coordinate change management requests required for upgrades and migrations.


Delivering clear and complete requirements in accordance with the agreed timeline planning. These may include user rights access and notifications. If final requirements are not available, you and Oracle may mutually agree to install EoD with draft requirements.


Ensuring that all key stakeholders, decision-makers, and team members are present and/or involved with all key meetings and deliverables (i.e., planning and review of the EoD application specifications, user acceptance testing, etc.).



Acceptance of the configured EoD application for release to UAT and for release to go-live.

Testing the EoD application (UAT) to your own standard operating procedures and/or work instructions and for creating and testing your own test cases. This includes capturing UAT feedback that is clear, reproducible, and actionable in the Oracle-provided template. If changes


introduced during UAT are required, the change management process will be followed (including additional fees and time).

Adding site and user information directly into an Oracle-provided tool (User Management Tool (UMT)) or providing a completed Oracle template listing the site and user information to be loaded into the UMT (for the initial creation of sites and users) if Oracle is contracted to provide first tier support.

All data management activities for the study, including but not limited to dictionary coding, query resolution, SAE reconciliation, and trial lock.

Managing and overseeing third party vendors (i.e., lab vendors, external Customer partners, etc.).

Reviewing and approving documents related to Production EoD application changes and fixes.



8.0 FastStart

FastStart consists of activities prior to the availability of the configured InForm Study for User Acceptance Testing (UAT).

Project Management




Work to ensure the following major sign-off milestones are achieved: o Approval of requirements o Release for User Acceptance Testing (UAT)

EoD Configuration

Oracle will:


Configure EoD as defined in the requirements specification.

Install and configure EoD in the Customer’s UAT environment.

Once testing is complete, install and configure EoD in the Customer’s formal Production (LIVE) environment

EoD Hosting and Application Management


Oracle will:

Set up the production environment and deploy the EoD configuration in the UAT instance for user acceptance testing.

9.0 FastForward

FastForward consists of activities from availability of the configured InForm Study for UAT through confirmation by the customer of completion of trial lock.

Project Management





Oracle will:


If required, deploy the new build to the UAT environment for you to conduct UAT round two. o If additional rounds of UAT are required, the Change Order process will be followed

(including additional fees and time).

EoD Hosting and Application Management

Oracle will:

Update the UAT instance with a fresh extract of the Production instance and configuration of EoD only if required, each time a study fix or study Change Order needs to be tested.



10.0 FastLock


Project Management

Oracle will:


Study Hosting and Application Management

Oracle will:

Remove the UAT EoD instance.

Manage and maintain the Production study EoD configuration until Study Decommission.


Provide associated project documents to you. This will include a copy of the Study Lifecycle Records pertaining to the EoD configuration.



1) An InForm study account is required to access the EoD portal page.



Customers must have a supported sFTP client to login to Oracles’ hosted sFTP server at



WS_FTP Pro from IPSwitch


Win SCP

All customers will be granted named user accounts with access privileges to the appropriate study

folders. Accounts will be created according to Oracle’s SFTP Service Policy.

Customer accounts can access multiple study folders. If a data supplier account is associated with

more than one study folder, then the customer will be required to navigate to the appropriate folder

after login. This navigation can be done through use of the appropriate commands depending

upon the sFTP client.

13.0 Error Handling

Oracle SFTP Server

SFTP provides authentication, data compression and file integrity algorithms to make sure that the

file received is the same as the file that was sent. If there is a connectivity issue to the Oracle

sFTP server (either from the data supplier or from the InForm server), then Oracle Customer












Historical Login Report (HLR)

This is the Services Description for Oracle InForm On Demand Integrations – Historical Login Report (HLR) to Customer’s master ordering document for Oracle HSGBU SaaS Services (“Study Order”). This Schedule describes the services provided to Customer for the study listed in each applicable study order under the master ordering document (“Study”). Further details of the Services are shared at the outset of each engagement. The services described herein are part of the SaaS Services provided under the terms of the ordering document. Capitalized terms not otherwise defined herein shall have the meaning ascribed to them in the ordering document, including the HSGBU SaaS Definitions Schedule referenced in the master ordering

document. This Schedule is subject to change at Oracle’s discretion; however, Oracle will not materially reduce the level of services provided under this Schedule for the twelve month period after the effective date of the Master Order Document (or the effective date of the renewal, if applicable), whichever is greater.


The Historical Login Report (HLR) Solution allows authorized users of the InForm™ ITM system to view a report of historical logins to InForm. The solution consists of a report in the InForm Reporting environment. The HLR can be deployed on a per study basis.

The Historical Login Report consists of a prompt page, the report output page, and an Oracle

database component.

Deployment of the solution consists of deploying the report as it is noted below and the

underlying Oracle database components without modification.

The report displays the successful logins to InForm based on the filters noted below.

Filterable by

date range

username

country

rights group

user type

Displays

login date/time

username

first name


last name

country

rights group

user type


Your HLR Solution will be deployed in a hosting facility and will be maintained and managed by Oracle. The deployment of the HLR Solution will be for two instances of a single Study: Production and UAT. The Production instance is the instance which will be used to capture the clinical data (“Data”). The UAT instance will be used to perform User Acceptance Testing pre-go-live and will be used to test changes and fixes post-go-live. (Note, the HLR Solution will not be deployed for a Training instance of a Study)







(Principal Investigators and Sub-Investigators). The Patient population is not expected to interact with the

HLR Solution.

The HLR solution is built into the Reporting environment of a given InForm EDC study. The report can be

accessed by authorized users of that study from the reporting user interface. The reporting environment

also provides for a link to be emailed on a scheduled run of the report.


The deliverables for the Historical Login Report consist of the following:

Report Installation – The installation of the report definition in the InForm Reporting environment for both the UAT and Production study instances.

Specification – This is written by the Oracle team to document the design and functionality of the Historical Login Report.



Performing analysis of the report to confirm its use for your purpose.

Acceptance of the HLR Solution for release to UAT and for release to go-live.


Reviewing and approving documents related to Production HLR Solution changes and fixes.


Upon completion of any deliverable, Oracle may provide a copy thereof to you. You will be responsible for any additional review and testing of such deliverable in accordance with any mutually agreed review


criteria or test scripts. If the deliverable does not conform with any such review criteria or test scripts, you shall have three (3) business days after Oracle’s submission of the deliverable (“acceptance period”) to give Oracle written notice which shall specify the deficiencies in detail. Oracle shall use reasonable efforts to promptly cure any such deficiencies. After completing such cure, Oracle shall resubmit the deliverable for your review and testing as set forth above. Upon accepting any deliverable submitted by Oracle, you shall provide Oracle with written acceptance of such deliverable. If you fail to provide written notice of any deficiencies within the acceptance period, as provided above, such deliverable shall be deemed accepted at the end of the acceptance period.


HLR pricing does not include any modifications to the report.

Historical login information is available only for sessions initiated after the report is deployed.

Report output consists of successful logins only.

7.0 Oracle Cloud Policies The Services are subject to the Oracle Cloud for Industry Hosting and Delivery Policies document, which is part of the Service Specifications of Your order and may be viewed at www.oracle.com/contracts.








InForm On Demand Integrations – Audit Trail Report (IATR)

This is the Services Description for Oracle InForm On Demand Integrations – InForm Audit Trail Report (IATR) to Customer’s master ordering document for Oracle HSGBU SaaS Services (“Study Order”). This Schedule describes the services provided to Customer for the study listed in each applicable study order under the master ordering document (“Study”). Further details of the Services are shared at the outset of each engagement. The services described herein are part of the SaaS Services provided under the terms of the ordering document. Capitalized terms not otherwise defined herein shall have the meaning ascribed to them in the ordering document, including the HSGBU SaaS Definitions Schedule referenced in the master ordering document. This Schedule is subject to change at Oracle’s discretion; however, Oracle will not materially reduce the level of services provided under this Schedule for the duration of the master ordering document referencing this schedule.


The IATR Reporting Solution allows authorized users of the InForm EDC system to view a report

of audit information for all data insertions and updates in the InForm EDC system. The solution

consists of a report in the InForm Reporting environment. The IATR can be deployed on a per

study basis.

The InForm Audit Trail Report consists of a prompt page, the report output page, and an Oracle

database component.

Deployment of the solution consists of deploying the report as it is noted below and the

underlying Oracle database components without modification.

The report displays the Audit information in the InForm EDC study based on predefined filters.

Report output formats supported:

HTML

PDF

Excel 2000 single sheet

Excel 2002

CSV*

XML*

Report output formats not supported:

Excel 2000


*Supported in a separate CSV/XML version of the report


Your IATR Solution will be deployed in a hosting facility and will be maintained and managed by Oracle. The deployment of the IATR Solution will be for two instances of a single Study: Production and UAT. The Production instance is the instance which will be used to capture the clinical data (“Data”). The UAT instance will be used to perform User Acceptance Testing pre-go-live and will be used to test changes and fixes post-go-live. (Note, the IATR Solution will not be deployed for a Training instance of a Study)








IATR Solution.

The IATR solution is built into the Reporting environment of a given InForm EDC study. The report can be

accessed by authorized users of that study from the reporting user interface. The reporting environment

also provides for a link to be emailed on a scheduled run of the report.


The deliverables for the InForm Audit Trail Report consist of the following:

Report Installation – The installation of the report definition in the InForm Reporting environment for both the UAT and Production study instances.

Specification – This is written by the Oracle team to document the design and functionality of the InForm Audit Trail Report.



Performing analysis of the report to ensure its use for your purpose.

Acceptance of the IATR Solution for release to UAT and for release to go-live.


Reviewing and approving documents related to Production IATR Solution changes and fixes.


Upon completion of any deliverable, Oracle may provide a copy thereof to you. You will be responsible for any additional review and testing of such deliverable in accordance with any mutually agreed review criteria or test scripts. If the deliverable does not conform with any such review criteria or test scripts, you shall have three (3) business days after Oracle’s submission of the deliverable (“acceptance period”) to give Oracle written notice which shall specify the deficiencies in detail. Oracle shall use reasonable efforts


to promptly cure any such deficiencies. After completing such cure, Oracle shall resubmit the deliverable for your review and testing as set forth above. Upon accepting any deliverable submitted by Oracle, you shall provide Oracle with written acceptance of such deliverable. If you fail to provide written notice of any deficiencies within the acceptance period, as provided above, such deliverable shall be deemed accepted at the end of the acceptance period.


IATR pricing does not include any modifications to the report.

The IATR does not include information for deleted clinical data.

The IATR does not include information for form status data.

Prompts (filters) for Sites, Subjects, etc. should be used to limit the dataset returned by the report to

ensure acceptable performance when running the report with large studies.










InForm On Demand Integrations - IRT

This is the Services Description for Oracle InForm On Demand Integrations - IRT to Your Study Order for

Oracle IRT On Demand Services (“Study Order”). This Schedule described the services provided by Oracle (the “Services”) for the study listed in the Study Order (“Study”). Additional services ordered in Your Study Order (e.g., integration services, etc.) may be described in other schedules. Further details of the Services are shared at the commencement of the Services.


The IRT Integration for InForm™ ITM provides a two-way integration between Oracle’s InForm EDC application and Oracle’s IRT application to enable a seamless integration of EDC data with IRT data. This integration enables Study designs to perform screening, enrollment, randomization, drug kit dispensing, and subject discontinuation either through the InForm EDC application or through the IRT application. The data necessary for these actions will be visible (and available) in either system. Oracle will provide You with Services for the IRT integration in three phases: FastStart, FastForward, and FastLock. The activities related to these Services are bounded by the parameters in section C of the Study Order and described in more detail below. During the FastStart phase (“Study Setup”), Oracle provides Services related to project initiation and application set-up tasks to ready the IRT Integration for User Acceptance Testing (UAT). During the FastForward phase (“Study Conduct”), Oracle provides Services related to UAT, IRT Integration usage, and management of contracted changes. The FastForward phase starts at the delivery of the InForm Study for UAT and concludes upon trial lock. During FastLock (“Study Closure”), Oracle provides Services leading to decommission of the IRT Integration.

The integrated solution allows for the following integration points:

1.0 Screening / Enrollment / Screen failure initiated from one of the following:

Initiated from an InForm eCRF

Initiated via a call to IRT

Initiated from the IRT web UI

2.0 Randomization




3.0 Kit dispensing





4.0 Subject dropout




5.0 Editing of data (demographic information)


Initiated from the IRT web UI (only available prior to the go-live of the InForm Study)

6.0 Other IRT functions (reporting, drug management, etc.)


Your IRT Integration will be deployed in a hosting facility and will be maintained and managed by Oracle. The deployment of the IRT Integration will be for two instances of a single Study: Production and UAT. The Production instance is the instance which will be used to capture the clinical data (“Data”). The UAT instance will be used to perform User Acceptance Testing pre-go-live and will be used to test changes and fixes post-go-live. (Note: the IRT Integration will not be deployed for a Training instance of a Study.)


The Services are intended to be used by personnel related to Your Study as authorized by You. Normally


typically consists of personnel from Your company and may also include other sub-contracted personnel




IRT Integration.



Requirements – These are written by the Oracle project team to document Your specific data integration needs for the IRT Integration.

Specifications – These are written by the Oracle project team to document the design of the IRT Integration configuration. Specifications may include IRT to InForm form data element mappings, data types, data element restrictions, and notification information.

Project Plan – This plan will be created and maintained by the Oracle Project Manager. It will detail the tasks, timelines, and milestones that Oracle and You are responsible for, as applicable.


IRT Integration Release for UAT – This is the initial release by Oracle of the configured IRT Integration in a UAT instance of the production environment to enable Your UAT to be held.

IRT Integration Release for Go-Live – This is the Production release by Oracle of the configured IRT Integration that Your approved End Users may access.

Changes and Fixes to the Production IRT Integration – Related documents are created by Oracle and approved by You.




Delivering clear and complete requirements in accordance with the agreed timeline planning. These may include data mapping, data restrictions, or notifications. If final requirements are not available, You and Oracle may mutually agree to begin Study design with draft requirements. This latter approach may be subject to additional fees.



Ensuring that all key stakeholders, decision-makers, and team members are present and/or involved with all key meetings and deliverables (i.e., planning and review of the IRT Integration specifications, user acceptance testing, etc.).


Ensuring specifications meet the regulatory requirements for the Study.

Acceptance of requirements specifications in a timely manner.

Acceptance of the configured IRT Integration for release to UAT and for release to go-live.

Testing the IRT Integrations (UAT) to Your own standard operating procedures and/or work instructions and for creating and testing Your own test cases. This includes capturing UAT feedback that is clear, reproducible, and actionable in the Oracle-provided template. If changes introduced during UAT are required, the change management process will be followed (including additional fees and time).


Reviewing and approving documents related to Production IRT Integration changes and fixes.


Upon completion of any deliverable, Oracle may provide a copy thereof to You. You will be responsible for any additional review and testing of such deliverable in accordance with any mutually agreed review criteria or test scripts. If the deliverable does not conform with any such review criteria or test scripts, You shall have three (3) business days after Oracle’s submission of the deliverable (“Acceptance Period”) to give Oracle written notice which shall specify the deficiencies in detail. Oracle shall use reasonable efforts to promptly cure any such deficiencies. After completing such cure, Oracle shall resubmit the deliverable for Your review and testing as set forth above. Upon accepting any deliverable submitted by Oracle, You shall provide Oracle with written acceptance of such deliverable. If You fail to provide written notice of any deficiencies within the Acceptance Period, as provided above, such deliverable shall be deemed accepted at the end of the Acceptance Period.

6.0 FastStart

FastStart consists of activities prior to the availability of the configured IRT Integration for User Acceptance Testing (UAT).

6.1. Prerequisites

Specifications for data to be integrated must be identified before construction of either the IRT Study or the InForm Study.

Data collection point – the origin (source) of data (InForm or IRT) - must be known and understood up front.


6.2. Integration Process

Project Management


Create a project plan detailing Study tasks and milestones.


Track Study/project progress.

Endeavor to see the following major sign-off milestones are achieved: o Approval of requirements o Release for User Acceptance Testing (UAT)

IRT Integration Configuration

Oracle will:

Gather Your requirements and configuration settings.

Generate integration specifications from Your requirements.*

Configure IRT Integration components as defined in the requirements and integration specifications.

Perform smoke testing to validate the designs.

Document the test cases needed for this configuration, and perform formal testing of the IRT Integration.

Perform formal QA of the integration configuration.

Install and configure the IRT Integration Solution in Your UAT environment.

Once UAT is complete, install and configure the IRT Integration Solution in the Your formal Production (LIVE) environment.


Formal Testing

Oracle will:

Conduct an independent validation of the IRT Integration configuration by testing components against approved specifications.

7.0 FastForward

FastForward consists of activities from availability of the configured IRT Integration for UAT through confirmation by You of completion of trial lock.

Project Management






Oracle will:

Address issues that You find in UAT.

If required, deploy the new configuration to the UAT environment for You to conduct UAT round two.



IRT Hosting and Application Management

Oracle will:

Update the UAT instance with a fresh extract of the Production instance and configuration of the IRT Integration only if required, each time a Study fix or Study Change Order needs to be tested.

o Your use and Oracle’s maintenance of the UAT instance is limited to the implementation of fresh extracts when Study fix or Study Change Order related corrections are required.

8.0 FastLock

FastLock services consist of those relating to the management of the production environment from confirmation by You of completion of trial lock to Study Decommission.

Project Management

Oracle will:

Liaise with Your team for activities needed to close out the Study.

IRT Integration Hosting and Application Management

Oracle will:

Decommission and recycle the Study environment.

Provide associated project documents to You. This will include a copy of the Study Lifecycle Records pertaining to the IRT Integration configuration.









InForm On Demand Integrations – Standard File-Based Integration*

*Previously called Integrated Voice Response System (IVRS)

This is the Services Description for Oracle InForm On Demand Integrations – Standard File-Based Integration to Customer’s master ordering document for Oracle HSGBU SaaS Services (“Study Order”). This Schedule describes the services provided to Customer for the study listed in each applicable study order under the master ordering document (“Study”). Further details of the Services are shared at the outset of each engagement. The services described herein are part of the SaaS Services provided under the terms of the ordering document. Capitalized terms not otherwise defined herein shall have the meaning ascribed to them in the ordering document, including the HSGBU SaaS Definitions Schedule referenced in the master ordering

document. This Schedule is subject to change at Oracle’s discretion; however, Oracle will not materially reduce the level of services provided under this Schedule for the duration of the master ordering document referencing this schedule.


The Standard File-Based Integration for InForm™ ITM integrates InForm GTM study data with external systems via flat files to screen and enroll patients, perform randomization, add/update clinical patient data and transfer patient data. This feature requires coordination between the Study Sponsor, external Vendor or other source of electronic data and Oracle. There are three flavors of the Standard File-Based integration; inbound integration, outbound integration and two-way integration. Inbound integration is importing data from the external system or Vendor to InForm. Outbound integration is exporting data from InForm and transferring it to an external Vendor/Sponsor. Two-way integration includes inbound and outbound integration. Oracle will provide you with Services for the Standard File-Based integration in three phases: FastStart, FastForward, and FastLock. The activities related to these Services are bounded by the parameters in section C of the Study Order and described in more detail below. During the FastStart phase (“Study Setup”), Oracle provides Services related to project initiation and application set-up tasks to ready the Standard File-Based integration for User Acceptance Testing (UAT). During the FastForward phase (“Study Conduct”), Oracle provides Services related to UAT, Standard File-Based integration usage, and environment management and maintenance. The FastForward phase starts at the delivery of the InForm Study for UAT and concludes upon trial lock.


During FastLock (“Study Closure”), Oracle provides Services leading to decommission of the Standard File-Based integration. The Inbound process of the Standard File-Based integration encompasses the import data flow from the flat file, to InForm. The process consists of the following steps:

1. Site users will enter data through the external system; such as creating and randomizing subjects, adding or updating clinical data for a subject via the telephone or web interface.

2. Once this information is submitted, the external system/Vendor will initiate a process to extract the data into an Oracle specified data format (MedML or pipe-delimited format) and transmit those files across a secure sFTP connection to the Oracle hosted sFTP server.

3. Once the data is received at Oracle, it is detected or “sniffed” and the patient’s data gets recorded into the InForm study.

4. InForm users can now view this patient data within InForm.

The Outbound process of the Standard File-Based integration encompasses a single data flow between the external system and InForm system where InForm is the sending system. The process consists of the following steps:

1. Site users will enter data into the InForm system. 2. Once this information is submitted, InForm will fire off a rule and generate a file (in an agreed

upon format) and transmit the files across a secure sFTP connection to the Oracle hosted sFTP server.

3. The data is then detected or “sniffed” by the external Vendor’s System and the data is processed by the external System.


Your Standard File-Based integration will be deployed in a hosting facility and will be maintained and managed by Oracle. The deployment of the Standard File-Based integration will be for two instances of a single Study: Production and UAT. The Production instance is the instance which will be used to capture the clinical data (“Data”). The UAT instance will be used to perform User Acceptance Testing pre-go-live and will be used to test changes and fixes post-go-live. (Note, the Standard File-Based integration will not be deployed for a Training instance of a Study)








Standard File-Based integration.



Requirements – These are written by the Oracle project team to document the customer specific data integration needs for the Standard File-Based integration.


Specifications – These are written by the Oracle project team to document the design of the Standard File-Based integration configuration. Specifications may include external system to InForm form data element mappings, data types, data element restrictions, and notification information.



Standard File-Based integration Release for UAT – This is the initial release by Oracle of the configured Standard File-Based integration in a UAT instance of the production environment to enable your UAT to be held.

Standard File-Based integration Release for Go-Live – This is the Production release by Oracle of the configured Standard File-Based integration that customer-approved end-users may access.

Changes and Fixes to the Production Standard File-Based integration – Related documents are created by Oracle and approved by you.



accordance with support services, including product upgrades to new releases and in-place upgrades and migrations in accordance with Oracle InForm Lifetime Support Policies. Upgrades are applied per InForm server and all trials on the same server are upgraded at the same time. Migrations typically include a trial move to a new hardware server. Upgrades and migrations are scheduled with You and are performed during the maintenance window for Production trials. Oracle will coordinate change management requests required for upgrades and migrations .

Maintenance of the UAT Instance – Oracle will update the UAT instance with a fresh extract of the Production instance each time a change or fix to the Production Standard File-Based integration Application needs to be tested by You. This involves removing the UAT instance (including UAT data) and replacing it with a fresh extract of the Production instance containing all the data as it exists in Production. Oracle will maintain the UAT instance in accordance with support services, including product upgrades to new releases and in-place upgrades and migrations in accordance with Oracle InForm Lifetime Support Policies. Upgrades are applied per InForm server. Migrations typically include a trial move to a new hardware server. Upgrades and migrations are scheduled with You and are performed during business hours for UAT trials. Oracle will coordinate change management requests required for upgrades and migrations .


Delivering clear and complete requirements in accordance with the agreed timeline planning. These may include data mapping, data restrictions, or notifications. If final requirements are not available, you and Oracle may mutually agree to begin the configuration of the integration with draft requirements. This latter approach may be subject to additional fees.



Ensuring that all key stakeholders, decision-makers, and team members are present and/or involved with all key meetings and deliverables (i.e., planning and review of the Standard File-Based integration specifications, user acceptance testing, etc.).





Acceptance of the configured Standard File-Based integration for release to UAT and for release to go-live.

Testing the Standard File-Based integration (UAT) to your own standard operating procedures and/or work instructions and for creating and testing your own test cases. This includes capturing UAT feedback that is clear, reproducible, and actionable in the Oracle-provided template. If changes introduced during UAT are required, the change management process will be followed (including additional fees and time).


Reviewing and approving documents related to Production Standard File-Based integration changes and fixes.



6.0 FastStart

FastStart consists of activities prior to the availability of the configured Standard File-Based integration for User Acceptance Testing (UAT).

6.1 Prerequisites

Specifications for data to be loaded must be incorporated into the study and form layout at the beginning of the InForm study project.

Coordination is required between Study Sponsor, external Vendor, and Oracle. Upload of data files to a secure server from the external Vendor system is necessary. In addition, manual review and correction of rejected files by Study Sponsor and external Vendor is required.

Data files must match the format described by Oracle.

6.2 Integration Process

Project Management







Standard File-Based integration Configuration

Oracle will:


Generate integration specifications from Customer-supplied requirements.*

Configure Standard File-Based integration components as defined in the requirements and integration specifications.


Document the test cases needed for this configuration, and perform formal testing of the Standard File-Based integration.


Install and configure the Standard File-Based integration Solution in the Customer’s UAT environment.

Once UAT is complete, install and configure the Standard File-Based integration Solution in the Customer’s formal Production (LIVE) environment.


Formal Testing

Oracle will:

Conduct an independent validation of the Standard File-Based integration configuration by testing components against approved specifications.

Standard File-Based integration Hosting and Application Management

Oracle will:

Set up the production environment and deploy the Standard File-Based integration configuration in the UAT instance for user acceptance testing.

7.0 FastForward

FastForward consists of activities from availability of the configured IRT Integration for UAT through confirmation by the customer of completion of trial lock.

Project Management






Oracle will:




Standard File-Based Integration Hosting and Application Management

Oracle will:

Update the UAT instance with a fresh extract of the Production instance and configuration of the


Standard File-Based integration only if required, each time a study fix or study Change Order needs to be tested.



8.0 FastLock


Project Management

Oracle will:


Standard File-Based Integration Hosting and Application Management

Oracle will:

Remove the UAT Standard File-Based integration configuration instance.

Manage and maintain the Production study Standard File-Based integration until Study Decommission.


Provide associated project documents to you. This will include a copy of the Study Lifecycle Records pertaining to the Standard File-Based integration configuration.


1) Standard File-Based Integration Pricing includes the integration of a maximum of 20 data fields

spread across up to 5 unique InForm Forms.

2) You are responsible for managing the relationship and communication with the external Vendor that

is necessary to implement the Standard File-Based integration.

3) The external Vendor is responsible for adhering to the approved Configuration Specification, and for

providing files for UAT testing.

4) Performance is dependent on the number and size of files being imported in a given interval.

5) You (and the external Vendor) are responsible for correcting and resubmitting rejected records if

records are rejected due to study or external Vendor oversights.

6) If You/external Vendor cannot meet the Standard File-Based Integration base requirements, Oracle

may provide programming services at additional cost.

10.0 Data File Requirements

The following requirements must be met for all data files generated by the external Vendor and

transferred to Oracle for import into InForm.


Data files must be formatted according to the Oracle’s MedML file format or pipe-delimited format (Screening, Enrollment and Patient Transfer cannot be done using pipe-delimited format).

Data files should contain incremental records.

Separate data files must be created for each study visit-form combination. For example, if there are two forms that will receive uploaded data for a given study, the vendor will create two separate data files for transfer to Oracle. If the same form is used for several visits, a separate data file is required for each instance of this form.

Record must contain the Subject number, Subject initials (or equivalent of what is collected if initials are not used), and site number in order to be loaded.

Record will be rejected if Subject number, Subject initials or site are incorrect or if Subject is not enrolled.

Screening failures can be loaded if identified.

MedML format has tags to accommodate screening, enrollment, adding patient data, editing patient data and transferring patient. Examples of each are outlined below.

MedML format has a tag called DUPLICATEORDER which is a number specifying the order in which patients with the same patient initials are enrolled. This tag is required when two or more patients with same initials are present at a site. The value of this tag can be supplied by the Vendor, OR automatically calculated by the external system solution. Example for this is outlined below.

If the Standard File-Based Integration solution will generate the DUPLICATEORDER value, there is a requirement that screen and enroll transactions must be sent within the same file.

11.0 File Naming Conventions

Data files sent by the external Vendor to Oracle must adhere to specific file naming convention in

order to satisfy the following requirements for uniqueness and the order of processing.

Many files may be received into one directory on the specified Oracle sFTP server from the external

Vendor,

Many files may be received at the same date/time.

Files for a given patient must be processed in a specific order (ex. Adding data to demography before

inclusion/exclusion.)

12.0 Data Transfer Procedure

All data transfer procedures documented here conform to the Oracle Cloud for Industry (OCI) Secure Data Transmission Standard. Changes to the OCI Secure Data Transmission Standard supersede any data transfer mechanisms described in this document.

The external Vendor must transmit the MedML data files across a secure SFTP channel to the

specified Oracle sFTP server. Data will be sent to a study specific inbound folder on the Oracle

sFTP server. Sponsor and Oracle users will have access to all folders under a sponsor’s root,

however the external vendor will only be granted to the specific Standard File-Based Integration

study integration folder. The folder structure will adhere to the Oracle standard.

The Standard File-Based Integration Windows Service on the machine that hosts the InForm

study will poll this folder on the Oracle sFTP server for any new data files. Once a file is found,

the file will be moved from the Oracle sFTP server, processed and loaded into the appropriate


InForm study. The audit information for the import and a copy of the original data file will be

maintained in persistent data storage, and viewable on the Standard File-Based Integration Log

Viewer page within the InForm Portal.



External Vendors must have a supported sFTP client to login to Oracles’ hosted sFTP server at





Win SCP

All external Vendors will be granted named user accounts with access privileges to the

appropriate study Standard File-Based Integration folders. Accounts will be created according to

Oracle’s SFTP Service Policy.

External Vendor user accounts can access multiple study folders. If a vendor account is

associated with more than one study folder, then the file transfer process will be required to

navigate to the appropriate folder after login. This navigation can be done through use of the

appropriate commands depending upon the sFTP client.

14.0 Error Handling

Oracle SFTP Server

SFTP provides authentication, data compression and file integrity algorithms to make sure that

the file received is the same as the file that was sent. If there is a connectivity issue to the Oracle

sFTP server (either from the external Vendor or from the InForm server), then Oracle Customer


InForm Import

In terms of importing data into InForm, audit logs will be generated for every import indicating

success or failure. The audit log along with the copy of the data file will be stored in persistent

data storage, and viewable on the Log Viewer page within the InForm Portal. The Standard File-

Based Integration will perform a graceful exit, such that all resources on the production server are

released. The solution can be configured to send email notifications for success and error.










InForm On Demand Integrations – Lab

Normals Management Tool (LNMT)

This is the Services Description for Oracle InForm On Demand Integrations – Lab Normals Management

Tool (LNMT) to Customer’s master ordering document for Oracle HSGBU SaaS Services (“Study Order”). This Schedule describes the services provided to Customer for the study listed in each applicable study order under the master ordering document (“Study”). Further details of the Services are shared at the outset of each engagement. The services described herein are part of the SaaS Services provided under the terms of the ordering document. Capitalized terms not otherwise defined herein shall have the meaning ascribed to them in the ordering document, including the HSGBU SaaS Definitions Schedule referenced in the master ordering document. This Schedule is subject to change at Oracle’s discretion; however, Oracle will not materially reduce the level of services provided under this Schedule for the twelve month period after the effective date of the Master Order Document (or the effective date of the renewal, if applicable), whichever is greater.


The Lab Normal Management Tool for InForm is a solution that allows sponsors to compare lab data entered into InForm with lab normal ranges. The solution consists of two parts; the cross-study lab normal management portion and the study specific eCRF portion. Oracle will provide you with Services for the LNMT Solution in three phases: FastStart, FastForward, and FastLock. The activities related to these Services are bounded by the parameters in section C of the Study Order and described in more detail below. During the FastStart phase (“Study Setup”), Oracle provides Services related to project initiation and application set-up tasks to ready the LNMT Solution for User Acceptance Testing (UAT). During the FastForward phase (“Study Conduct”), Oracle provides Services related to UAT, LNMT Solution usage, and environment management and maintenance. The FastForward phase starts at the delivery of the InForm Study for UAT and concludes upon trial lock. During FastLock (“Study Closure”), Oracle provides Services leading to decommission of the LNMT Solution. Cross-Study Lab Normal Management This portion of LNMT allows for entry and management of the lab vendors and the lab tests along with their normal ranges. The management portion consists of a set of user interface pages that reside within


the InForm Portal. A single set of normal ranges can be leveraged across multiple studies if a sponsor desires. Access to the management user interface is controlled through InForm rights groups. Association of Lab Results in a Study with Lab Normal Ranges The association of subject lab results and the defined Lab Normal Ranges is specific to the studies leveraging the LNMT Integration solution. A common eCRF design practice must be used in designing the lab eCRF’s for the data capture of the lab data. In conjunction with the eCRF design, a set of edit checks that are study specific are used to auto generate InForm queries. LNMT then supplies the functionality to extract the lab results data from the InForm eCRF’s, compare them against the pre-defined normal ranges, and insert/update the results back to the original InForm eCRF. This is an automated process that is scheduled to run in batch. The batch can be scheduled to run as frequently as hourly.


Your LNMT Solution will be deployed in a hosting facility and will be maintained and managed by Oracle. The deployment of the LNMT Solution will be for two instances of a single Study: Production and UAT. The Production instance is the instance which will be used to capture the clinical data (“Data”). The UAT instance will be used to perform User Acceptance Testing pre-go-live and will be used to test changes and fixes post-go-live. (Note, the LNMT Solution will not be deployed for a Training instance of a Study) An LNMT setup in each environment consists of a central LNMT database server (the backend) along with the configuration of LNMT with each InForm study it will be used for (the front end). Each InForm study configured with LNMT will access the shared LNMT backend within that environment (UAT or LIVE).








LNMT Solution.



Requirements – These are written by the Oracle project team to document the customer specific data integration needs for the LNMT Solution.

Specifications – These are written by the Oracle project team to document the design of the LNMT Solution configuration. Specifications may include form data element mappings, data types, data element restrictions, and notification information.




LNMT Solution Release for UAT – This is the initial release by Oracle of the configured LNMT Solution in a UAT instance of the production environment to enable your UAT to be held.

LNMT Solution Release for Go-Live – This is the Production release by Oracle of the configured LNMT Solution that customer-approved end-users may access.

Changes and Fixes to the Production LNMT Solution – Related documents are created by Oracle and approved by you.



accordance with support services, including product upgrades to new releases and in-place upgrades and migrations in accordance with Oracle InForm Lifetime Support Policies. Upgrades are applied per InForm server and all trials on the same server are upgraded at the same time. Migrations typically include a trial move to a new hardware server. Upgrades and migrations are scheduled with You and are performed during the maintenance window for Production trials. Oracle will coordinate change management requests required for upgrades and migrations.

Maintenance of the UAT Instance – Oracle will update the UAT instance with a fresh extract of the Production instance each time a change or fix to the Production LNMT Application needs to be tested by You. This involves removing the UAT instance (including UAT data) and replacing it with a fresh extract of the Production instance containing all the data as it exists in Production. Oracle will maintain the UAT instance in accordance with support services, including product upgrades to new releases and in-place upgrades and migrations in accordance with Oracle InForm Lifetime Support Policies. Upgrades are applied per InForm server. Migrations typically include a trial move to a new hardware server. Upgrades and migrations are scheduled with You and are performed during business hours for UAT trials. Oracle will coordinate change management requests required for upgrades and migrations.


Delivering clear and complete requirements in accordance with the agreed timeline planning. These may include data mapping, data restrictions, or notifications. If final requirements are not available, you and Oracle may mutually agree to begin the configuration of the LNMT Solution with draft requirements. This latter approach may be subject to additional fees.



Ensuring that all key stakeholders, decision-makers, and team members are present and/or involved with all key meetings and deliverables (i.e., planning and review of the LNMT Solution specifications, user acceptance testing, etc.).




Acceptance of the configured LNMT Solution for release to UAT and for release to go-live.

Testing the LNMT Solution (UAT) to your own standard operating procedures and/or work instructions and for creating and testing your own test cases. This includes capturing UAT feedback that is clear, reproducible, and actionable in the Oracle-provided template. If changes introduced during UAT are required, the change management process will be followed (including additional fees and time).


Reviewing and approving documents related to Production LNMT Solution changes and fixes.



Upon completion of any deliverable, Oracle may provide a copy thereof to you. You will be responsible for any additional review and Standard InForm Lab testing of such deliverable in accordance with any mutually agreed review criteria or test scripts. If the deliverable does not conform with any such review criteria or test scripts, you shall have three (3) business days after Oracle’s submission of the deliverable (“acceptance period”) to give Oracle written notice which shall specify the def iciencies in detail. Oracle shall use reasonable efforts to promptly cure any such deficiencies. After completing such cure, Oracle shall resubmit the deliverable for your review and testing as set forth above. Upon accepting any deliverable submitted by Oracle, you shall provide Oracle with written acceptance of such deliverable. If you fail to provide written notice of any deficiencies within the acceptance period, as provided above, such deliverable shall be deemed accepted at the end of the acceptance period.

6.0 FastStart

FastStart consists of activities prior to the availability of the configured LNMT Solution for User Acceptance Testing (UAT).

6.1 Prerequisites

eCRFs must be designed using LNMT specifications

All Lab Tests may/may not be associated with Units on the InForm Lab eCRFs

All Lab Test controls (control refnames) on InForm Lab eCRF’s are named intuitively and uniquely for each Lab eCRF where possible to allow for a quicker and clearer LMNT configuration

All Lab Tests and Units are pre-identified for each study for entering normal ranges through the LNMT User Interface.


Project Management


Create a project plan detailing study tasks and milestones.



Endeavor to see the following major sign-off milestones are achieved: o Approval of requirements o Release for User Acceptance Testing (UAT)


LNMT Solution Configuration

Oracle will:



Configure LNMT Solution components as defined in the requirements and integration specifications.


Document the test cases needed for this configuration, and perform formal testing of the LNMT Solution.


Install and configure the LNMT Solution in the Customer’s UAT environment.

Once UAT is complete, install and configure the LNMT Solution in the Customer’s formal Production (LIVE) environment.


Formal Testing

Oracle will:

Conduct an independent validation of the LNMT Solution configuration by testing components against approved specifications.

LNMT Solution Hosting and Application Management

Oracle will:

Set up the production environment and deploy the LNMT Solution configuration in the UAT instance for user acceptance testing.

7.0 FastForward

FastForward consists of activities from availability of the configured LNMT Solution for UAT through confirmation by the customer of completion of trial lock.

Project Management






Oracle will:





Oracle will:

Update the UAT instance with a fresh extract of the Production instance and configuration of the LNMT Solution only if required, each time a study fix or study Change Order needs to be tested.




8.0 FastLock


Project Management

Oracle will:



Oracle will:

Remove the UAT LNMT Solution configuration instance.

Manage and maintain the Production study LNMT Solution until Study Decommission.


Provide associated project documents to you. This will include a copy of the Study Lifecycle Records pertaining to the LNMT Solution configuration.










Report Extractor (RE)

This is the Services Description for Oracle InForm On Demand Integrations – Report Extractor (RE) to Customer’s master ordering document for Oracle HSGBU SaaS Services (“Study Order”). This Schedule describes the services provided to Customer for the study listed in each applicable study order under the master ordering document (“Study”). Further details of the Services are shared at the outset of each engagement. The services described herein are part of the SaaS Services provided under the terms of the ordering document. Capitalized terms not otherwise defined herein shall have the meaning ascribed to them in the ordering document, including the HSGBU SaaS Definitions Schedule referenced in the master ordering



The Report Extractor (RE) solution addresses the need to extract data from an InForm trial on a scheduled basis. It relies on the creation of Customer defined Cognos reports to extract data from the InForm Reporting Database on one or more InForm studies. The Report Extractor is configured to install, run, save, extract and aggregate (or any combination thereof) reports on a schedule. The results may be saved to the Oracle sFTP server for delivery to Customer. The Report Extractor solution offering is configured depending upon Customer requirements. The Report Extractor core functionality includes performing one or more of the following actions on one or more Cognos Reports on one or more InForm studies:

Installation of SQL object(s)

Installation of report(s)

Execution of report(s)

Saving report(s) output in InForm

Extracting report(s) output to the Oracle sFTP server

Aggregation of report output across multiple InForm studies and outputting to the Oracle sFTP server


The Report Extractor can obtain the list of InForm studies to run against via a preconfigured list or the Oracle Remedy master database. A configuration of the Report Extractor supports multiple schedules interacting with multiple groupings of reports. The Reports are Customer specific Cognos reports that are constructed and configured in such manner as to facilitate silent execution on a schedule. A single Report Extractor server is provisioned per customer, which can run multiple instances of the Report Extractor.


Your RE Solution will be deployed in a hosting facility and will be maintained and managed by Oracle. The deployment of the RE Solution will be for two instances: Production and UAT. The Production instance is the instance which will be used to capture the clinical data (“Data”). The UAT instance will be used to perform User Acceptance Testing pre-go-live and will be used to test changes and fixes post-go-live. (Note, the RE Solution will not be deployed for a Training instance of a Study)






and Patient population are not expected to interact with the RE Solution.



Requirements – These are written by the Oracle project team to document the customer specific data integration needs for the RE Solution.

RE Solution Release for UAT – This is the initial release by Oracle of the configured RE Solution in a UAT instance of the production environment to enable your UAT to be held.

RE Solution Release for Go-Live – This is the Production release by Oracle of the configured RE Solution that customer-approved end-users may access.

Changes and Fixes to the Production RE Solution – Related documents are created by Oracle and approved by you.


accordance with support services, including product upgrades to new releases in accordance with Oracle InForm Lifetime Support Policies. Oracle will coordinate change management requests required for upgrades.


Delivering clear and complete requirements in accordance with the agreed timeline planning. These may include data mapping, data restrictions, or notifications. If final requirements are not available, you and Oracle may mutually agree to begin the configuration of the RE Solution with draft requirements. This latter approach may be subject to additional fees.

Ensuring that all key stakeholders, decision-makers, and team members are present and/or involved with all key meetings and deliverables (i.e., planning and review of the RE Solution specifications, user acceptance testing, etc.).





Acceptance of the configured RE Solution for release to UAT and for release to go-live.

Testing the RE Solution (UAT) to your own standard operating procedures and/or work instructions and for creating and testing your own test cases. This includes capturing UAT feedback that is clear, reproducible, and actionable in the Oracle-provided template. If changes introduced during UAT are required, the change management process will be followed (including additional fees and time).


Reviewing and approving documents related to Production RE Solution changes and fixes.



6.0 Deployment

Deployment consists of activities prior to the availability of the configured RE Solution for User Acceptance Testing (UAT).

6.1 Prerequisites

Coordination is required between you and Oracle to ensure the configuration of the Report Extractor conforms to the Customer requirements and specifications.

Reports to be aggregated must be constructed in such a way (single query) to support such aggregation.


Project Management






RE Solution Configuration

Oracle will:


Configure RE Solution components as defined in the requirements specifications.

Perform smoke testing to validate the configuration.

Document the test cases needed for this configuration, and perform formal testing of the RE Solution.


Install and configure the RE Solution in the Customer’s UAT environment.

Once UAT is complete, install and configure the RE Solution in the Customer’s formal Production (LIVE) environment.

Formal Testing

Oracle will:

Conduct an independent validation of the RE Solution configuration by testing components against approved specifications.

RE Solution Hosting and Application Management

Oracle will:

Set up the production environment and deploy the RE Solution configuration in the UAT instance for user acceptance testing.


Design of the Cognos Reports must conform to Report Extractor requirements and specifications.

Development of the Cognos Reports is not included in this scope of work and must be addressed

under a separate work order.

Files extracted from InForm studies will be placed in the agreed upon Customer folder on the Oracle

sFTP server.

If the customer cannot meet the Report Extractor base requirements, Oracle may provide

programming services at additional cost.



Customer must have a supported sFTP client to login to Oracles’ hosted sFTP server at

sftp.webcrf.net and download files. Oracle supports the following sFTP clients:




Win SCP

Customers will be granted named user accounts with access privileges to the appropriate Report

Extractor folders. Accounts will be created according to Oracle’s SFTP Service Policy.


Customer accounts can access multiple study folders. If a customer account is associated with

more than one study folder, then the customer will be required to navigate to the appropriate

folder after login. This navigation can be done through use of the appropriate commands

depending upon the sFTP client.











Subject Data Reference (SDR)

This is the Services Description for Oracle InForm On Demand Integrations – Subject Data Reference (SDR) to Customer’s master ordering document for Oracle HSGBU SaaS Services (“Study Order”). This Schedule describes the services provided to Customer for the study listed in each applicable study order under the master ordering document (“Study”). Further details of the Services are shared at the outset of each engagement. The services described herein are part of the SaaS Services provided under the terms of the ordering document. Capitalized terms not otherwise defined herein shall have the meaning ascribed to them in the ordering document, including the HSGBU SaaS Definitions Schedule referenced in the master ordering



The Subject Data Reference (SDR) solution addresses the need to link reference files and information to a patient eCRF. The SDR solution allows authorized users of InForm to upload file attachments to InForm. The attachments may be associated with a particular subject’s eCRF. Authorized users may view or download those files. Files can be uploaded from within the InForm Portal or from individual, pre-configured InForm eCRFs. Oracle will provide you with Services for the SDR Solution in three phases: FastStart, FastForward, and FastLock. The activities related to these Services are bounded by the parameters in section C of the Study Order and described in more detail below. During the FastStart phase (“Study Setup”), Oracle provides Services related to project initiation and application set-up tasks to ready the SDR Solution for User Acceptance Testing (UAT). During the FastForward phase (“Study Conduct”), Oracle provides Services related to UAT, SDR Solution usage, and environment management and maintenance. The FastForward phase starts at the delivery of the InForm Study for UAT and concludes upon trial lock. During FastLock (“Study Closure”), Oracle provides Services leading to decommission of the SDR Solution. The Subject Data Reference solution offering utilizes a secured web-based user interface for SDR users to upload/view/extract and audit reference files that are associated to a patient eCRF. The SDR web


application is integrated into InForm eCRF(s) and within the InForm Portal. Uploaded reference files are stored within a dedicated Oracle database infrastructure. The core functional components to the SDR include:

Upload Reference Files

View Reference Files

Extract Reference Files

Audit Reference Files

Administration


Your SDR Solution will be deployed in a hosting facility and will be maintained and managed by Oracle. The deployment of the SDR Solution will be for two instances of a single Study: Production and UAT. The Production instance is the instance which will be used to capture the clinical data (“Data”). The UAT instance will be used to perform User Acceptance Testing pre-go-live and will be used to test changes and fixes post-go-live. (Note, the SDR Solution will not be deployed for a Training instance of a Study.)








SDR Solution.



Requirements – These are written by the Oracle project team to document the customer specific data integration needs for the SDR Solution.

Specifications – These are written by the Oracle project team to document the design of the SDR Solution configuration. Specifications may include form data element mappings, data types, data element restrictions, and notification information.



SDR Solution Release for UAT – This is the initial release by Oracle of the configured SDR Solution in a UAT instance of the production environment to enable your UAT to be held.

SDR Solution Release for Go-Live – This is the Production release by Oracle of the configured SDR Solution that customer-approved end-users may access.

Changes and Fixes to the Production SDR Solution – Related documents are created by Oracle and approved by you.




accordance with support services, including product upgrades to new releases and in-place upgrades and migrations in accordance with Oracle InForm Lifetime Support Policies. Upgrades are applied per InForm server and all trials on the same server are upgraded at the same time. Migrations typically include a trial move to a new hardware server. Upgrades and migrations are scheduled with You and are performed during the maintenance window for Production trials. Oracle will coordinate change management requests required for upgrades and migrations.

Maintenance of the UAT Instance – Oracle will update the UAT instance with a fresh extract of the Production instance each time a change or fix to the Production SDR Application needs to be tested by You. This involves removing the UAT instance (including UAT data) and replacing it with a fresh extract of the Production instance containing all the data as it exists in Production. Oracle will maintain the UAT instance in accordance with support services, including product upgrades to new releases and in-place upgrades and migrations in accordance with Oracle InForm Lifetime Support Policies. Upgrades are applied per InForm server. Migrations typically include a trial move to a new hardware server. Upgrades and migrations are scheduled with You and are performed during business hours for UAT trials. Oracle will coordinate change management requests required for upgrades and migrations.


Delivering clear and complete requirements in accordance with the agreed timeline planning. These may include data mapping, data restrictions, or notifications. If final requirements are not available, you and Oracle may mutually agree to begin the configuration of the SDR Solution with draft requirements. This latter approach may be subject to additional fees.



Ensuring that all key stakeholders, decision-makers, and team members are present and/or involved with all key meetings and deliverables (i.e., planning and review of the LNMT Solution specifications, user acceptance testing, etc.).




Acceptance of the configured SDR Solution for release to UAT and for release to go-live.

Testing the SDR Solution (UAT) to your own standard operating procedures and/or work instructions and for creating and testing your own test cases. This includes capturing UAT feedback that is clear, reproducible, and actionable in the Oracle-provided template. If changes introduced during UAT are required, the change management process will be followed (including additional fees and time).


Reviewing and approving documents related to Production SDR Solution changes and fixes.


Upon completion of any deliverable, Oracle may provide a copy thereof to you. You will be responsible for any additional review and testing of such deliverable in accordance with any mutually agreed review criteria or test scripts. If the deliverable does not conform with any such review criteria or test scripts, you shall have three (3) business days after Oracle’s submission of the deliverable (“acceptance period”) to give Oracle written notice which shall specify the deficiencies in detail. Oracle shall use reasonable efforts


to promptly cure any such deficiencies. After completing such cure, Oracle shall resubmit the deliverable for your review and testing as set forth above. Upon accepting any deliverable submitted by Oracle, you shall provide Oracle with written acceptance of such deliverable. If you fail to provide written notice of any deficiencies within the acceptance period, as provided above, such deliverable shall be deemed accepted at the end of the acceptance period.

6.0 FastStart

FastStart consists of activities prior to the availability of the configured LNMT Solution for User Acceptance Testing (UAT).

12.1 Prerequisites

eCRF design must conform to the SDR requirements and specifications for attaching files.

eCRFs that support reference data associations must contain a hyperlink for navigating to the upload page.


Project Management






SDR Solution Configuration

Oracle will:



Configure SDR Solution components as defined in the requirements and integration specifications.


Document the test cases needed for this configuration, and perform formal testing of the SDR Solution.


Install and configure the SDR Solution in the Customer’s UAT environment.

Once UAT is complete, install and configure the SDR Solution in the Customer’s formal Production (LIVE) environment.


Formal Testing

Oracle will:

Conduct an independent validation of the SDR Solution configuration by testing components against approved specifications.

SDR Solution Hosting and Application Management


Oracle will:

Set up the production environment and deploy the SDR Solution configuration in the UAT instance for user acceptance testing.

7.0 FastForward

FastForward consists of activities from availability of the configured SDR Solution for UAT through confirmation by the customer of completion of trial lock.

Project Management






Oracle will:





Oracle will:

Update the UAT instance with a fresh extract of the Production instance and configuration of the SDR Solution only if required, each time a study fix or study Change Order needs to be tested.



8.0 FastLock


Project Management

Oracle will:



Oracle will:

Remove the UAT SDR Solution configuration instance.

Manage and maintain the Production study SDR Solution until Study Decommission.


Provide associated project documents to you. This will include a copy of the Study Lifecycle Records pertaining to the SDR Solution configuration.



eCRF design must conform to SDR requirements and specifications.

Files uploaded from a specific eCRF will automatically be associated to that subject, visit, and eCRF

InForm study database extracts will not include SDR information. The SDR Administration page

provides the facility for extracting sets of attachments based on a user defined query.

If the customer cannot meet the SDR base requirements, Oracle may provide programming services

at additional cost.



Data file suppliers must have a supported sFTP client to login to Oracles’ hosted sFTP server at





Win SCP

Customers will be granted named user accounts with access privileges to the appropriate study

SDR folders. Accounts will be created according to Oracle’s SFTP Service Policy.

Customer accounts can access multiple study folders. If a customer account is associated with

more than one study folder, then the customer will be required to navigate to the appropriate

folder after login. This navigation can be done through use of the appropriate commands

depending upon the sFTP client.








Documents

InForm On Demand Integrations Service Descriptions