Table of Contents
Oracle Health Sciences InForm Cloud Services
Service Descriptions and Metrics
October 9, 2014
Table of Contents
Metric Definitions .................................................................................................................................................. 2
Instance ........................................................................................................................................................................................ 2
Patient .......................................................................................................................................................................................... 2
Site ............................................................................................................................................................................................... 2
Trial .............................................................................................................................................................................................. 2
Customer...................................................................................................................................................................................... 2
Service Descriptions for Cloud Services .................................................................................................................. 3
Oracle Health Sciences InForm Cloud Service, InForm Direct Cloud Service, InForm MultiTrial Cloud Service options including Cloud Service Set Up ....................................................... 3
Oracle Health Sciences InForm Cloud Service End User Help Desk ........................................ 8
Oracle Health Sciences InForm Cloud Service Central Coding ................................................. 9
Oracle Health Sciences InForm Cloud Service Lab Normals Management Tool (LNMT) .... 11
Oracle Health Sciences InForm Cloud Service InForm Integration ......................................... 13
Oracle Health Sciences InForm Cloud Service Report Extractor (RE) .................................... 14
Oracle Health Sciences InForm Cloud Service Medication Adherence Insights (MAI) ......... 17
Service Descriptions for Configuration Services ................................................................................................... 21
InForm Cloud Service Trial Build ................................................................................................... 21
InForm Cloud Service Study Project Management ..................................................................... 22
InForm Cloud Service Study Project Management and Advisory Services ............................ 23
Central Coding Configuration ......................................................................................................... 23
Lab Normals Management Tool Configuration ............................................................................ 24
InForm Integrations Configuration - Standard File-Based Integration*.................................. 25
InForm Integrations Configuration - Direct Data Loader (DDL) ** .......................................... 30
CRF Submit – Additional Runs ...................................................................................................... 35
Acceptance of Deliverables .................................................................................................................................. 35
Page 1 of 35
Metric Definitions
Instance: is defined as single deployment of the Oracle program. For details of deployment specific to
the Oracle program please refer to service descriptions/entitlements.
Patient: is defined as a person receiving healthcare related treatment such as receiving drugs, medical
devices or alternate treatment/therapies and/or enrolled/participating in a clinical study. For the purposes
of licensing, the maximum number of Patients enrolled in the Study must be counted. The quantity stated
for ‘Patients’ excludes screen-failed patients (i.e. patients who have not received medication). The
terminology ‘Patient’ is use interchangeable with ‘Subject’.
Site: is defined as a single location from which the Service will be accessed (e.g., an investigator site or
a customer location).
Trial: is defined as each research project, study or procedure created, modified, tracked and/or
conducted by a sponsor using the Oracle program(s) or Service(s).
Customer: is defined as the customer entity specified on your order. The programs may not be used or
accessed for the business operations of any third party, including but not limited to your customers,
partners, or your affiliates. There is no limitation on the number of computers on which such programs
may be copied, installed and used.
Page 2 of 35
Service Descriptions for Cloud Services
Oracle Health Sciences InForm Cloud Service, InForm Direct Cloud Service,
InForm Multi-Trial Cloud Service options including Cloud Service Set Up
Cloud Service Set Up
Your InForm Services Environment will be deployed in a hosting facility and will be maintained and
managed by Oracle. The deployment of the Services Environment will consist of three instances:
Production, UAT, and Training. 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 after go-live. The Training instance may be used by You to
conduct training in addition to the online training provided. You may also contact Oracle for additional
training options for which there may be additional cost. This information can be provided based on
request to Oracle. More information is available here.
InForm Direct Cloud Service
InForm Direct is a type of InForm that excludes Reporting. Specifically this excludes:
installation of Cognos in hosted environment (including access to Cognos custom reporting tool)
access to the 28 built-in standard reports
access to reporting Ad hoc clinical and operational data model
The offering provides full access to Data Viewer for clinical data review and RDE (Reporting Data Extract)
for clinical data analysis. You have the option to build Your own reports - Oracle can provide an extract of
the Review/InForm Schema for You to build Your own reports and /or You may purchase consulting
services from Oracle to build custom reports.
InForm Cloud Service - Users and Access by Users
Your use of the Services is limited to personnel related to Your Study as authorized by You. Normally
this consists of two main groupings of personnel: Sponsor and Site. 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).
InForm Cloud Service - 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 and entitlements listed below. Some common deliverables
and entitlements that apply to most projects include:
Page 3 of 35
Validation Package – If you build Your own trials, this documentation may be used by You to perform
Installation Qualification (IQ), Operational Qualification (OQ) and/or Performance Qualification (PQ)
for the InForm product. It is Your responsibility to request the package from Oracle if desired.
InForm Application Release for UAT – This is the initial release by Oracle of the configured InForm
application in a UAT instance of Your environment that You may use to conduct UAT activities.
InForm Application Release for Go-Live – This is the release by Oracle of the configured InForm
application in a Production instance or Your environment that Your approved Users may access.
Database Extracts – These database extracts may be used by You to analyze and report on Your
data captured by the configured InForm application. It is Your responsibility to request an export
online and to download the export. Authorized Users may obtain a database extract in one of two
ways:
o Proactively log into InForm and generate an extract as needed
o Request Oracle to schedule the extract generation – You may request up to once per day
in this manner
Up to two generations of PDFs – PDFs may be generated by Oracle at the end of the Study after
confirmation of Your final trial lock or during the course of the Study (1 set per site containing that
site’s data and Your 2 copies containing all Study data). These are intended to document the data as
it existed in the Production instance of the configured InForm application. Generation of additional
set(s) of output with different output requirements, such as a subset of data for auditing purposes, is
not covered by this Services Description and would need to be contracted for separately.
Online training for InForm for the named study(ies) for InForm users. The list of available online
courses for InForm is provided in the Oracle Health Sciences Online Training for Oracle Health
Sciences InForm Cloud Service Data Sheet
User Management Tool and Site Assessment
Online training for User Management Tool (UMT) for the named study(ies) for UMT users. The list of
available online course(s) for User Management Tool are provided in the Oracle Health Sciences
Online Training for Oracle Health Sciences InForm Cloud Service Data Sheet
Archival Documentation – This is a package of documentation that was maintained by Oracle during
the course of the Study. After the InForm application is decommissioned, this package is sent to You.
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. Oracle will coordinate change management requests
required for upgrades and migrations.
Maintenance of the UAT Instance – Upon request, Oracle will update the UAT instance with a fresh
extract of the Production instance each time a change or fix to the Production InForm application
requires testing. 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 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 business hours for UAT Trials. Oracle
will coordinate change management requests required for upgrades and migrations..
Maintenance of the Training Instance – Oracle will set up a Training instance using Study
implementation files similar to those used for the Production instance. Upon request, the training
environment is updated to reflect subsequent changes or fixes within the Production instance unless
agreed otherwise. Copying data from the Production instance to the Training Instance is not allowed.
Oracle will maintain the Training 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 business hours for
Page 4 of 35
Training trials. Oracle will coordinate change management requests required for upgrades and
migrations.
Production Instance Backups - Oracle will make the following backups for the production
environments for Customer’s data hosted by Oracle: (Backup media is not intended for use as
archive of study for any purposes other than as a means of data protection at a secure off-site
location and to provide the ability for recovery activities to occur in the event of a disaster)
Daily backups of hosted application system and database files.
On four-hour intervals, backups are made of the Oracle Database Archive files where
applicable.
Daily replication of backups to an offsite facility.
Your responsibilities related to the above services are dependent upon the components included in the
project. Examples include but are not limited to:
Testing the InForm application (e.g., conducting UAT) in accordance with Your own standard
operating procedures and/or work instructions as well as creating and testing Your own test cases.
Ensuring packages and scripts are adequately tested as per Your own standard operating procedures
and/or work instructions before sending it to Oracle Cloud Services for implementation on
UAT/Production instances. For packages or scripts submitted by You for implementation, it is Your
responsibility to examine the implementation logs for potential error messages and take appropriate
action. Note that a ‘successful’ ticket completion means the script completed with or without errors.
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).
Ensuring that all users are trained prior to accessing the system. This includes maintaining all training
records.
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 (e.g., lab vendors, external partners, Your
subcontractors, etc.). If Oracle will not supply End User Help Desk support then You must ensure
Your End User Help Desk vendor is aware they need to administer Oracle users where appropriate.
Working with Oracle to upgrade the contract to provide a dedicated environment if not contracted as
such at the outset and Your usage exceeds the limits defined below.
Submitting Your PDF archival requirements promptly allowing for Your Request to Decommission to
be submitted by the end of Your Services Period. It is recommended that the request for archival
PDFs is submitted ninety (90) days prior to the end of the Services Period to allow time for PDF
generation and Your review. Failure to request archival PDFs with at least ninety (90) days
remaining in the Services Period may require You to execute an extension to Your order
and/or result in Oracle decommissioning Your Study at the end of the Services Period.
Distributing archival PDFs and Trial Archival Package (TAP), as appropriate.
Submitting the Request to Decommission prior to the end of the Services Period.
o If You require additional time beyond Your Services Period, You will be required to execute
an extension to Your contract.
o If You fail to meet Your obligation to submit the Request for Decommission prior to the end of
the Services Period and You have not contracted for an extension to the Services Period,
Your Study will be decommissioned upon the end of the Services Period.
o If You submit the Request to Decommission no later than thirty (30) days prior to the end of
the Services Period, then, following Your written request, Oracle will provide You with a
refund of any recurring fees actually paid to Oracle for the period following Oracle’s receipt of
Your Request to Decommission.
Page 5 of 35
o
If You build Your studies, You are responsible for submitting a ticket to request
decommission.
Reviewing and accepting the Trial Archive Package (TAP) within sixty (60) days of delivery.
Users of the InForm Cloud Service and InForm Direct Cloud Service are authorized to access the
following modules:
InForm application
InForm Portal
User Management Interface
InForm Publisher
InForm Adaptor
Usage Limits: The InForm Cloud Service and InForm Direct Cloud Service are subject to usage limits
based on:
Number of Patients contracted
The following usage limits apply per licensed metric:
Licensed Metric
Database Storage
(Records)
File Storage (GB)
Bandwidth
# of Instances
included with
License
Patient/Trial –
standard hosting
25 GB
N/A
N/A
1 Trial pack ( UAT,
Training and
Production)
Patient/Trial – Study
on dedicated hosting
2000 GB
N/A
N/A
1 Trial pack ( UAT,
Training and
Production)
Service Level Targets: The InForm Cloud Service and InForm Direct Cloud Service have the following
service level targets:
Cloud Service
Recovery Time Objective
(RTO)
Recovery Point Objective
(RPO)
Target System
Availability
InForm Cloud Service
90 days
48 hours
99%
Cognos Reporting installations will be completed within 5 business days from the date the request was submitted.
Third Party License Requirements:
InForm cloud service includes the use of Cognos reporting model embedded into the InForm application.
The use of IBM Cognos Report Studio is not included in this service and needs to be licensed by You
separately.
Page 6 of 35
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 Multi-Trial Cloud Service Options
The InForm Multi-Trial Cloud Service Options comprise two contracting approaches for large numbers of
trials. As the services significantly overlap with the above described Inform Cloud Services, the approach
taken is to refer to the relevant sub-section above unless there is a difference specific to the Multi-Trial
Cloud Service option.
Multi-Trial Dedicated Hosting – per Customer
The Services available for this offering are described in the sub-sections above entitled:
o Cloud Service Set Up
o InForm Cloud Service - Deliverables and Customer Dependencies. (Note that User
Management Tool and Site Assessment may be included in this Multi-Trial offering or
purchased separately as agreed by You and Oracle.)
o Service Level Targets
o Third Party License Requirements
o Oracle Cloud Policies
Users of InForm Multi-Trial Dedicated Hosting are authorized to access the following modules:
InForm Application
Inform Portal
User Management Interface
InForm Publisher
InForm Adaptor
Usage Limits: The Multi-Trial Dedicated Hosting Service is subject to usage limits based on:
Number of Customers
The following usage limits apply per licensed metric:
Licensed
Metric
Database Storage
(Records)
File Storage
(GB)
Bandwidth
# of Instances included
with License
Customer
Per customer specified
requirements
N/A
N/A
1 Trial pack ( UAT, Training
and Production)
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.
Page 7 of 35
Multi-Trial Hosting – Application Management & Hosting – per Trial
The Services available for this offering are described in the sub-sections above entitled
o Cloud Service Set Up
o InForm Cloud Service - Deliverables and Customer Dependencies. (Note that User
Management Tool and Site Assessment may be included in the Multi-Trial offering or
purchased separately as agreed by You and Oracle.)
o Service Level Targets
o Third Party License Requirements
o Oracle Cloud Policies
Users of the Multi-Trial Hosting – Application Management & Hosting are authorized to access the
following modules:
InForm Application
Inform Portal
User Management Interface
InForm Publisher
InForm Adaptor
Usage Limits: The Multi-Trial Hosting – Application Management & Hosting Service is subject to usage
limits based on:
Contracted as a Trial
The following usage limits apply per licensed metric:
Licensed
Metric
Database Storage
(Records)
File Storage
(GB)
Bandwidth
# of Instances included with
License
Trial
25 GB
N/A
N/A
1 Trial pack ( UAT, Training and
Production)
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.
Oracle Health Sciences InForm Cloud Service End User Help Desk
Users of the InForm Cloud Service End User Help Desk are able to perform the following activities:
Routine User Management
o InForm user activation/inactivation requests
o InForm user termination/un-termination
o InForm site or user addition or change
Page 8 of 35
o
InForm user password change
Management of UMT accounts
Change of InForm Study configuration settings
Creation/change of rights, roles and groups
Change of Study version
Usage Limits: The InForm Cloud Service End User Help Desk is subject to usage limits based on:
Number of Sites contracted
Service Level Targets:
The Cloud Service End User Help Desk has the following service level targets:
Severity one issues will be responded to within one hour.
Severity one = A catastrophic issue impacting multiple system users of an active production system. The
issue may be perceived as presenting potential data integrity risks.
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.
Oracle Health Sciences InForm Cloud Service Central Coding
Users of Cloud Service Central Coding are authorized to access the following modules or functionalities:
Central Coding
Refer to Usage Limits for differences when purchased per Trial versus per Instance
Central coding purchased per Trial allows the purchased Study to connect to a central coding application:
for the exchange of relevant data including
o verbatim terms
o indication and route of administration from the InForm Study
to return codes, terms, coder name, and dictionary used in Central Coding.
A purchased Instance of Central Coding allows multiple studies to connect to that Instance for the use of
the coding application
for the exchange of relevant data including
o verbatim terms
o indication and route of administration from the InForm studies
to return codes, terms, coder name, and dictionary used in Central Coding.
Users and Access by Users
The Services may be accessed only by personnel involved in coding activity for Your Study.
Page 9 of 35
Oracle will grant User Manager and User Administrator roles to the Central Coding customer, The
customer will then be able to create individual end user accounts for their personnel in the Central Coding
application. Oracle will not create individual end user accounts for the customer.
Deliverables
Online training for Central Coding for the named study(ies) for Central Coding users. The list of available
online course(s) for Central Coding is provided in the Oracle Health Sciences Online Training for Oracle
Health Sciences InForm Cloud Service Data Sheet
Validation Package – If you build Your own trials and Central Coding integration, this Validation Package
documentation may be used by You to perform Installation Qualification (IQ), Operational Qualification
(OQ) and/or Performance Qualification (PQ) for the Central Coding integration. It is Your responsibility to
request the Validation Package from Oracle if desired.
Third Party Licensing Requirements
You are solely responsible for licensing any dictionaries used (e.g., MedDRA or WHODD) and must
maintain a valid license to such dictionaries for the duration of the Services Period. Such dictionaries are
considered “materials” provided by You for purposes of the infringement indemnification obligations of the
applicable agreement governing use of the Cloud Services. Dictionaries need to be licensed separately.
Oracle will use reasonable efforts to attempt to verify with the appropriate licensing authority (e.g., MSSO
or WHO) that You have a valid license prior to loading the dictionary in the Central Coding environment
and on an annual basis. However, this does not alleviate customer obligations to maintain a valid license
to such dictionaries.
Oracle may suspend access to the Cloud Services immediately if Your dictionary licenses have expired.
In such an event, You remain responsible for payment obligations hereunder .
Usage Limits: The InForm Cloud Service Central Coding is subject to usage limits based on:
Contracted as a Trial
OR
Number of purchased Instances
The following usage limits apply per licensed metric:
Licensed Metric
Database Storage
(Records)
File Storage (GB)
Bandwidth
# of Instances
included with
License
Central Coding - Trial
60GB
N/A
N/A
one Production and
one UAT
implementation
Page 10 of 35
Central Coding Instance *
250GB
N/A
N/A
One Production
Instance supports
up to 50 Studies and
one UAT instance
supports up to 50
Studies
*You will need to purchase another Instance of Central Coding should you deploy more than 50 Studies
Service Level Targets:
The InForm Cloud Service Central Coding has the following service level targets:
Cloud Service
Recovery Time Objective
(RTO)
Recovery Point Objective
(RPO)
Target System
Availability
InForm Cloud Central
Coding
90 days
48 hours
99%
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.
Oracle Health Sciences InForm Cloud Service Lab Normals Management Tool
(LNMT)
Users of the Cloud Service Lab Normals Management Tool are authorized to access the following
modules or functionalities:
Association of Lab Results in a Study with Lab Normal Ranges
Users and Access by Users
The Services are intended to be used by personnel involved in the management of Your Study as
authorized by You.
Deliverables
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:
Page 11 of 35
LNMT Application Release for UAT – This is the initial release by Oracle of the configured LNMT
Application in a UAT instance of the production environment that You may use to conduct UAT
activities.
LNMT Application Release for Go-Live – This is the Production release by Oracle of the
configured LNMT Application that Your Users may access.
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 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.
Remove the UAT LNMT Application configuration instance.
Decommission and recycle the Study environment.
Usage Limits: The InForm Cloud Service Lab Normals Management Tool is subject to usage limits
based on:
Contracted as a Trial
The following usage limits apply per licensed metric:
Licensed Metric
Database Storage
(Records)
File Storage (GB)
Bandwidth
# of Instances
included with
License
Trial
N/A
N/A
N/A
one Production and
one UAT
implementation
Service Level Targets: The Cloud Service Lab Normals Management Tool has the following service
level targets:
Cloud Service
Recovery Time Objective
(RTO)
Recovery Point Objective
(RPO)
Target System
Availability
Lab Normal
Management Tool
(LNMT)
90 days
48 hours
99%
Oracle Cloud Policies
Page 12 of 35
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.
Oracle Health Sciences InForm Cloud Service InForm Integration
Your InForm Integration will be deployed and will integrate Your main InForm Study with any of the
contracted integrations below. These contracted integrations may be configured by Oracle or by You as
contracted.
Standard File-Based Integration*
Direct Data Loader (DDL)**
* Previously named Integrated Voice Response System (IVRS)
** DDL no longer available for purchase from August 2014
The InForm Cloud Service InForm Integration as described below may also be purchased independently
of the specific integration types listed immediately above.
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 the
Integration.
Deliverables
The deliverables for an InForm Integration 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:
Release for UAT – This is the initial release by Oracle of the configured Integration in a UAT instance
of the production environment that You may use to conduct UAT activities.
Release for Go-Live – This is the Production release by Oracle of the configured Integration that
Your-approved end-users may access.
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 Integration needs to be tested by
Page 13 of 35
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.
Remove the UAT Integration configuration instance.
Decommission and recycle the Study environment.
Usage Limits: The InForm Cloud Service InForm Integration is subject to usage limits based on:
Contracted as a Trial
The following usage limits apply per licensed metric:
Licensed Metric
Database Storage
(Records)
File Storage (GB)
Bandwidth
# of Instances
included with
License
Trial
N/A
N/A
N/A
Implementation on
one Production and
one UAT Study for
each integration
purchased
Service Level Targets: The Cloud Service InForm Integration has the following service level targets:
Cloud Service
Recovery Time
Objective (RTO)
Recovery Point
Objective (RPO)
Target System
Availability
Cloud Service InForm Integration
90 days
48 hours
99%
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.
Oracle Health Sciences InForm Cloud Service Report Extractor (RE)
Users of the Cloud Service Report Extractor are authorized to access the following modules or
functionalities:
Report Extractor (RE) - is configured to install, run, save, extract and aggregate (or any
combination thereof) reports on a schedule. The Report Extractor addresses the need to extract
data from one or more InForm studies on a scheduled basis. It relies on the creation of Your
defined Cognos reports to extract data from the InForm Reporting Database. The output of the
Page 14 of 35
Report Extractor are may be saved to the Oracle sFTP server for delivery to You.
Users and Access by Users
The Services are intended to be used by personnel involved in the management of Your Study as
authorized by You.
Configuration
The Report Extractor application offering is configured based on mutually agreed requirements.
The configuration of the Report Extractor includes performing one or more of the following actions on a
maximum of 20 Cognos Reports (or SQL objects) per Study and connecting to a maximum of 200 InForm
Studies:
Installation of a maximum of 4 SQL objects per Study
Installation of a maximum of 15 reports per Study
Saving a maximum of 10 unique report outputs in InForm per Study
Extracting a maximum of 20 unique report output formats per Study to the Oracle sFTP
server
Aggregation of a maximum of 10 unique report outputs across multiple InForm Studies and
outputting to the Oracle sFTP server
Prerequisites
Coordination is required between You and Oracle to ensure the configuration of the Report
Extractor conforms to Your requirements and specifications.
Reports to be aggregated must be constructed in such a way (single query) to support such
aggregation.
Assumptions & Limitations
Design of the Cognos Reports must conform to Report Extractor requirements and specifications.
Development of the Cognos Reports is not included in with this Service and must be purchased
separately.
Files extracted from InForm studies will be placed in Your agreed upon folder on the Oracle sFTP
server.
If You cannot meet the Report Extractor base requirements, Oracle may provide programming
services at additional cost.
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:
Requirements – These are written by the Oracle project team to document Your specific data
integration needs for the RE Application.
Page 15 of 35
Configure RE Application 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
Application.
Conduct an independent validation of the RE Application configuration by testing components
against approved specifications.
Install and configure the RE Application in Your UAT environment.
Changes and Fixes to the Production RE Application.
RE Application Release for UAT – This is the initial release by Oracle of the configured RE
Application in a UAT instance of the production environment that You may use to conduct UAT
activities.
RE Application Release for Go-Live – This is the Production release by Oracle of the configured
RE Application that Your-approved end-users may access.
Maintenance of the Production Instance – Oracle will maintain the production instance in
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.
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 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 Application
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 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 requirements specifications in a timely manner.
Acceptance of the configured RE Application for release to UAT and for release to go-live.
Testing the RE 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).
Reviewing and approving documents related to Production RE Application changes and fixes.
Ensuring that all users are trained prior to accessing the system. This includes maintaining all
training records.
Usage Limits: The Cloud Service Report Extractor is subject to usage limits based on:
Contracted as a Trial
The following usage limits apply per licensed metric:
Licensed Metric
Database Storage
(Records)
File Storage (GB)
Bandwidth
# of Instances
included with
License
Trial
N/A
N/A
N/A
one Production and
one UAT
implementation
Page 16 of 35
Service Level Targets: The Cloud Service has the following service level targets:
Cloud Service
Recovery Time Objective
(RTO)
Recovery Point Objective
(RPO)
Target System
Availability
Report Extractor
90 days
48 days
99%
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.
Oracle Health Sciences InForm Cloud Service Medication Adherence Insights
(MAI)
The Medication Adherence Insights (MAI) option for InForm integrates data from the Proteus Digital
Health Feedback System (DHFS) with InForm Studies. For purposes of the InForm Cloud Service,
including the MAI, data from the Proteus DHFS shall be considered Your data (also referred to as “Your
Content”).
Users and Access by Users
Your use of the InForm Cloud Service, including the MAI and data from the Proteus DHFS, is limited to
personnel related to Your Study as authorized by You.
Secure Data Transfer Procedure
Data transfer procedures between the Proteus DHFS data center and the InForm Services Environment
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 for the InForm
Cloud Services.
Data is transferred from the Proteus DHFS data center to Your InForm Services Environment via a set of
secure (SSL based) and authenticated web service calls.
Error Handling
Oracle Medication Adherence Insights Web Services
If there is a connectivity issue between Your InForm Services Environment and the Proteus DHFS data
center (for example due to Proteus web services or due to the InForm server), then Oracle Customer
Support may work directly with Proteus for purposes of resolving the issue.
InForm Import
After You import or data is otherwise transferred from Proteus DHFS into the InForm Services
Environment, the standard audit log will be generated to indicate the status of the import or transfer. The
Page 17 of 35
audit log, along with the copy of the data file, will be stored in persistent data storage, and viewable on
the Adherence Data Log Viewer page within the InForm Portal.
Cloud Services Deliverables and 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:
End User Help desk support of MAI for Your Users of the InForm Cloud Services.
MAI Release for UAT – This is the initial release by Oracle of the configured MAI integration in a
UAT instance of the production environment that You may use to conduct UAT activities.
MAI integration Release for Go-Live – This is the Production release by Oracle of the configured
MAI integration that Your Users may access.
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 MAI 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.
Remove the UAT MAI integration configuration instance.
Decommission and recycle the Study environment.
Your responsibilities for a given project are dependent upon the components included in the project. Your
responsibilities and obligations include, but are not limited to:
You must contract directly with Proteus Digital Health ("Proteus") for the Proteus DHFS. Oracle
will use reasonable efforts to coordinate with Proteus, but You are ultimately responsible for
interacting with Proteus and ensuring all components of the Proteus DHFS are available for
usage during the Study.
You are responsible for enrolling Patients participating in the Study using the Proteus DHFS
You must acquire, from Proteus, training and support of the Proteus DHFS for Your Site,
personnel and Patients. Oracle does not provide any training and support for the Proteus DHFS.
You will not place into Your InForm Services Environment any protected health information
(“PHI”) as that term is defined by the Health Insurance Portability and Accountability Act
(“HIPAA”) of 1996, as amended, unless prior to delivery to Oracle You have de-identified the PHI
in accordance with 45 C.F.R. § 164.514(b)(1) (“Statistical De-Identification”) or 45 C.F.R. §
164.514(b)(2) (“Removal of Identifiers”).
The Proteus DHFS, including maintenance, manufacturing, distribution, and use, is the sole
responsibility of You and Proteus.
Page 18 of 35
You and Proteus are responsible for correcting and resubmitting incomplete, inaccurate or
corrupted data and records.
Assumptions
The availability and performance of importing or otherwise transferring data into InForm is
dependent on Proteus, including the Proteus data center, which can be impacted by Patient
interaction with the Proteus DHFS (e.g., not wearing the patch sensor).
Configuration
The Medication Adherence Insights (MAI) option for InForm uses standard integration capabilities and
forms to integrate data from the Proteus Digital Health Feedback System (DHFS) with InForm Studies.
Configuration - 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:
Requirements (RDD) – These are written by the Oracle project team to document Your form
requirements related to the MAI integration.
Specifications – These are written by the Oracle project team to document the design of the MAI
integration configuration. Specifications may include form data element mappings, data types,
data element restrictions, and notification information. One design iteration is included for the
design specifications.
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.
MAI InForm eCRF - Oracle will document and implement the standard forms in InForm to
accommodate the MAI integration.
Configuration - Configure MAI integration in support of the requirements and integration
specifications.
Testing –
o Perform smoke testing.
o Document the test cases needed for this configuration, and perform formal testing of the
MAI integration.
UAT (up to 1 round(s)) –
o Install and configure the MAI integration in Your UAT environment.
o One (1) User Acceptance Testing (UAT) findings meeting.
o Respond to questions that You raise in UAT.
o If required, deploy a new configuration to the UAT environment for You to re-test.
o If additional rounds of UAT are required, the Change Order process will be followed
(including additional fees and time).
Once UAT is concluded, install and configure the MAI integration in Your Production instance.
Fixes to the Production MAI integration – Related documents are created by Oracle and provided
to You.
Decommission - Provide associated project documents to You. This will include a copy of the
Study Lifecycle Records pertaining to the MAI integration configuration.
Page 19 of 35
Your responsibilities for a given project are dependent upon the components included in the project.
Your responsibilities include but are not limited to:
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 MAI integration
with draft requirements. This latter approach may be subject to additional fees.
Specifications for data to be integrated by MAI integration must be identified and any update
required in standard MAI forms must be finalized before construction of the InForm study.
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 MAI integration
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 requirements specifications in a timely manner.
Acceptance of the configured MAI integration for release to UAT and for release to go-live.
Testing the MAI 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).
Ensuring that all users are trained prior to accessing the system. This includes maintaining all
training records.
Reviewing and approving documents related to Production MAI integration changes and fixes.
Usage Limits: MAI is subject to usage limits based on:
Number of Patients contracted
The following usage limits apply per licensed metric:
Licensed Metric
Database Storage
(Records)
File Storage (GB)
Bandwidth
# of Instances
included with
License
Patient
N/A
N/A
N/A
one Production and
one UAT
implementation
Service Level Targets: The Cloud Service has the following service level targets:
Cloud Service
Recovery Time Objective
(RTO)
Recovery Point Objective
(RPO)
Target System
Availability
MAI
90 days
48 hours
99%
Page 20 of 35
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
Service Descriptions for Configuration Services
InForm Cloud Service Trial Build
InForm Cloud Service Trial Build services relate to project initiation and application set-up tasks to ready
the InForm application for UAT.
The deliverables for InForm Cloud Service Trial Build services 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:
Specifications – These are written by the Oracle project team to document the design of the
InForm application configurations. Specifications may include EDC form content, rules and edit
checks, InForm application configurations, and database requirements.
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.
Team List – This document is created and maintained by the Oracle Project Manager. It
describes the Oracle team members, their responsibilities, and their contact information.
Configuration – Oracle will configure or build Study components in support of the mutually agreed
Study requirements.
Oracle will conduct an independent test of Your Study by testing Study components against the
mutually agreed Study requirements
UAT (up to 1 round) –
o One (1) User Acceptance Testing (UAT) findings meeting.
o Respond to questions that You raise in UAT.
o If required, deploy a new configuration to the UAT environment for You to re-test Your
findings.
o If additional rounds of UAT are required, the Change Order process will be followed
(including additional fees and time).
Once UAT is concluded, install the Study in Your Production instance.
Fixes to the Production InForm Application – Related documents are created by Oracle and
approved by You.
Your responsibilities for InForm Cloud Service Trial Build are dependent upon the components included in
the project. Examples include but are not limited to:
Testing the InForm application (UAT) in accordance with Your own standard operating
procedures and/or work instructions as well as creating and testing Your own test cases. This
includes capturing UAT feedback that is clear, reproducible, and actionable in the Oracleprovided template. If changes are introduced following finalization of the documented
Page 21 of 35
requirements, the change management process will be followed (including additional fees and
time, as appropriate).
Delivering clear and complete requirements in accordance with the agreed timeline planning.
These may include form, edit check, Study configuration, and database requirements.
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 (e.g. requirements discussion and user
acceptance testing, etc.).
Ensuring that all key stakeholders, decision-makers, and team members adhere to the agreed
timelines.
Ensuring requirements meet the regulatory needs for the Study.
Reviewing and approving documents related to Production InForm application changes and fixes.
InForm Cloud Service Trial Build Assumptions:
A Form is considered to be ‘reused’ from a client library or previous InForm Study when no changes are
required. There are certain updates that can be made to a “re-used” form (at the discretion of the Oracle
form designer):
updating the year range for a date field
deleting items that do not impact rules, reports or integrations, or
minor updates to text that do not impact rules, reports or integrations.
The quantities stated in the Study Order for Total, Unique and Re-Used eCRF pages and for Rules
represent Oracle’s estimate of the effort involved to build the eCRF based on the parameters that You
provided to Oracle prior to execution of the Study Order. A different combination of forms, rules and reuse may be necessary as the Study build proceeds, and this may require additional effort. You agree to
enter into a Change Order with Oracle for any such additional effort, which must be executed prior to
Study go-live.
InForm Cloud Service Study Project Management
Applies either to studies built by Oracle or to studies Built by You.
InForm Cloud Service Study Project Management provides project management services for an
InForm SaaS Study during the Services Period.
Project management services include coordination of professional services requests and
communications and Study project planning (project plan containing key milestones to be
mutually agreed with You).
InForm Cloud Service Study Project Management specifically excludes contractual additions,
such as change orders
A Project Manager will be assigned as the primary contact to You for services activity.
Page 22 of 35
InForm Cloud Service Study Project Management and Advisory Services
Study Project Management and Advisory Services applies either to studies built by Oracle or to
studies built by You.
Oracle will provide these Services up to the number of hours contracted in the Study Order.
Once the number of hours purchased has been utilized, additional hours may be purchased.
Hours not used on or before the end of the Services Period expire without refund and are not
available for future use by You.
Hours are restricted to Services performed by Project Management (PM), Design Consultant
(DC) & Technical Consultant (TC) roles.
InForm Cloud Service Study Project Management and Advisory Services may include assistance
with the following as mutually agreed:
o Assisting You with questions regarding: Study design, form design, workflow and rule
design, deployment packages, data extract setup and data extract usage.
Project management services may include coordination of professional services requests and
communications, project planning and project status reporting. A project manager will be
assigned as the primary contact to You for services activity.
Assumptions:
o Services will be delivered from the location of the Oracle staff employee.
o Services can be applied only to the specific Study contracted for in the Study Order.
o You must request use of these hours is via the project manager assigned to the Study.
Oracle requires lead time of at least 2 business days to respond to a request for
consumption of these hours.
Study Project Management and Advisory Services specifically excludes:
o Customizations related to the Study build.
o Change orders related to the Study build.
Central Coding Configuration
For the configuration of Central Coding with one (1) InForm integrated Study, Oracle will provide the
following services that apply to most projects:
Initial set-up including defined rights and roles.
Demonstration of the Central Coding application for use during requirements gathering and
specifications.
In coordination with You, documentation of requirements in the Central Coding Configuration
Specification for the setup and integration of one (1) InForm Study with Central Coding.
Configuration of the Central Coding application in the two environments, one for user acceptance
testing (UAT) and one for live, based on the Configuration Specification including:
Coding Algorithm
Coding definitions for up to two standard coding dictionaries
Assignment rules based on the agreed specification for coding work teams
Configuration of synonym lists and stopword lists
Configuration of one (1) integrated InForm Study with the InForm Adapter and associated
Central Coding job scheduler and
Configuration of a version of MedDRA and WHODD standard dictionaries in the Central
Coding application (subject to Your separate licensing requirements for such
dictionaries).
Page 23 of 35
Standard dictionary upgrades of MedDRA and WHODD up to two (2) times per calendar year per
mutually agreed schedule. This includes any required impact analysis in preparation for an
upgrade assuming total Oracle effort per upgrade does not exceed 32 hours.
Central Coding version upgrades per mutually agreed schedule.
Any Central Coding mappings required for the InForm Cloud Service Trial Build will be the
responsibility of the party building the Study builder, which may be Oracle for InForm on-Demand
studies where Study build services are ordered in the applicable Study Order or Enterprise
customers who are responsible for Study build.
Lab Normals Management Tool Configuration
The Lab Normal Management Tool for InForm is an application that allows sponsors to compare lab data
entered into InForm 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 application. 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 predefined 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.
Prerequisites: eCRFs must be designed using LNMT specifications
All Lab Tests and Units are pre-identified for each Study for entering normal ranges through the
LNMT User Interface.
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:
Requirements – These are written by the Oracle project team to document Your specific data
integration needs for the LNMT Application.
Specifications – These are written by the Oracle project team to document the design of the
LNMT Application configuration. Specifications may include form data element mappings, data
types, data element restrictions, and notification information. One design iteration is included for
the design specifications.
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.
Page 24 of 35
Configuration - Configure LNMT Application components in support of the requirements and
integration specifications.
Testing –
o Perform smoke testing.
o Document the test cases needed for this configuration, and perform formal testing of the
LNMT Application.
UAT (up to 1 round(s)) –
o Install and configure the LNMT Application in Your UAT environment.
o One (1) User Acceptance Testing (UAT) findings meeting.
o Respond to questions that You raise in UAT.
o If required, deploy a new configuration to the UAT environment for You to re-test.
o If additional rounds of UAT are required, the Change Order process will be followed
(including additional fees and time).
Once UAT is concluded, install and configure the LNMT Application in Your Production instance.
Fixes to the Production LNMT Application – Related documents are created by Oracle and
approved by You.
Decommission - Provide associated project documents to You. This will include a copy of the
Study Lifecycle Records pertaining to the LNMT Application configuration.
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 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 Application
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 LNMT 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 requirements specifications in a timely manner.
Acceptance of the configured LNMT Application for release to UAT and for release to go-live.
Testing the LNMT 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.
Reviewing and approving documents related to Production LNMT Application changes and fixes.
InForm Integrations Configuration - Standard File-Based Integration*
* Previously named Integrated Voice Response System (IVRS)
Page 25 of 35
The Standard File-Based Integration for InForm integrates InForm Studies with external systems via a flat
file transfer. This feature requires coordination between the Study Sponsor, Vendor or other source of
electronic data and Oracle. There are three possible configurations of the Standard File-Based
integration; inbound integration, outbound integration and two-way integration. Inbound integration is
importing data from the external system to InForm via a flat file. Outbound integration is exporting data
from InForm and transferring it to the external system or to You via a flat file. Two-way integration
includes inbound and outbound integration.
The Inbound process encompasses the import data flow from the external system to the InForm Service.
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 will initiate a process to extract the data
into an Oracle specified data format (MedML or pipe-delimited format) and transmit those files
across an sFTP connection to the Oracle hosted sFTP server.
3. Once the data is received at Oracle, the data is thereafter recorded into the InForm Study
database.
4. InForm users can now view this data within InForm.
The Outbound process of 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 generate a data 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 thereafter received and processed by the external system.
The Two-way integration process consists of both the Inbound and Outbound processes configured on a
single Study.
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, the external system vendor, and Oracle. Oracle
will use reasonable efforts to coordinate with the external system vendor, but You are ultimately
responsible for interacting with such vendor. 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 You and the external system vendor is required.
Inbound data files must match the format described by Oracle.
Outbound data file format must be mutually agreed upon.
Assumptions & Limitations
Pricing includes the integration of a maximum of 20 data fields spread across up to 5 unique
InForm Forms.
You must ensure that the external system vendor adheres to the approved Configuration
Specification, and provides necessary files for UAT testing.
Performance is dependent on the number and size of files being imported in a given interval.
Page 26 of 35
You (and the external system vendor) are responsible for correcting and resubmitting rejected
records if records are rejected due to Study or external system problems.
Data File Requirements
The following requirements must be met for all data files generated by the external system 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 application. Example for this is outlined
below.
If the external system will generate the DUPLICATEORDER value, there is a requirement that
screen and enroll transactions must be sent within the same file.
File Naming Conventions
Data files sent by the external system 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 system,
Many files may be received at the same date/time.
Files for a given Subject must be processed in a specific order (ex. Adding data to demography
before inclusion/exclusion.)
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 system 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. The
folder structure will adhere to the Oracle standard.
Page 27 of 35
A Windows service on the system that hosts the InForm Study will poll the folder on the Oracle sFTP
server for any new data files. Once a file is found, the file will be copied 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 Log Viewer page
within the InForm Portal.
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.
External system vendors must have a supported sFTP client to login to Oracle’s hosted sFTP server at
sftp.webcrf.net and transmit files. Oracle currently supports the following sFTP clients:
SecureFX from Vandyke Software (preferred client)
WS_FTP Pro Version 9 from IPSwitch
Putty Command line client
Win SCP
External system vendors 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.
External system vendor user accounts can access multiple Study folders. If a vendor account is
associated with more than one Study folder, then the vendor’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.
Error Handling
Oracle SFTP Server
SFTP provides authentication, data compression and file integrity algorithms to help confirm 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 system vendor or from the InForm server), then Oracle Customer Support may
assist with resolution.
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.
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:
Page 28 of 35
Requirements – These are written by the Oracle project team to document Your 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 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.
Communication Plan – This document is created and maintained by the Oracle Project Manager.
It describes the team members, their responsibilities, and their contact information.
Configure Standard File-Based integration components as defined in the requirements and
integration specifications.
Testing –
o Perform smoke testing to validate the designs.
o Document the test cases needed for this configuration, and perform formal testing of the
Standard File-Based Integration.
o Conduct an independent validation of the Standard File-Based integration configuration
by testing components against approved specifications.
UAT (up to 1 round(s)) –
o Install and configure the Standard File-Based integration Application in Your UAT
environment.
o One (1) User Acceptance Testing (UAT) findings meeting.
o Respond to questions that You raise in UAT.
o If required, deploy a new configuration to the UAT environment for You to re-test.
o If additional rounds of UAT are required, the Change Order process will be followed
(including additional fees and time).
Once UAT is concluded, install and configure the Standard File-Based integration Application in
Your Production instance.
Fixes to the Production Standard File-Based integration Application
o Related documents are created by Oracle and approved by You.
o 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.
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 activities are required.
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.
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 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.
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 Standard FileBased integration 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.
Page 29 of 35
Acceptance of requirements specifications in a timely manner.
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).
Ensuring that all users are trained prior to accessing the system. This includes maintaining all
training records.
Reviewing and approving documents related to Production Standard File-Based integration
changes and fixes.
You are responsible for managing the relationship and communication with the IVR Vendor that is
necessary to implement the Standard File-Based integration.
InForm Integrations Configuration - Direct Data Loader (DDL) **
** DDL no longer available for purchase from August 2014
The Direct Data Loader (DDL) for InForm™ ITM is designed to facilitate the loading of data files received
from third party 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.
DDL file processing and loading consists of the following steps:
Data files from external vendors must be uploaded to a designated sFTP directory on the Oracle
sFTP server for each Study.
The DDL Service detects each uploaded file and moves it into the processing queue.
Files are processed in a FIFO manner.
File processing includes preliminary checks and any errors found during the preliminary checks
are logged and made available to Users via the DDL user interface.
After the preliminary checks are run and erroneous records are filtered out, the remaining data is
loaded into InForm Reporting.
Email notification can be configured to report the load status to a predetermined list of email
addresses.
Loaded data is accessible via InForm ad-hoc reporting, custom reports, and reporting database
extracts.
Records that fail to load are logged and accessible via the DDL administration tab within the
InForm portal.
Prerequisites
Coordination is required between You and the third party vendor 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 vendors.
Specifications for data to be loaded must be incorporated into the Study and form layout.
Page 30 of 35
Assumptions & Limitations
External Data will not be loaded into InForm core.
o Loaded data will not be viewable within eCRFs
o Sites will not see data in InForm
o Rules will not be applied to data
o The loaded data will be available within the “Clinical Data Model” for reporting purposes (both
AdHoc and Custom) using the InForm Reporting functionality
o The loaded data will be available within the InForm reporting database extract.
DDL does not provide facilities for editing data – all corrections will be the responsibility of the data
supplier.
DDL will display only the latest data loaded from a data provider in reporting. There will not be an
audit trail in InForm reporting.
DDL pricing includes the integration of a maximum of 5 distinct data file formats and associated
eCRF’s. A maximum of 10 historical data files may be archived for retention purpose. (This does not
include data imported into the reporting database)
Performance is dependent on the number and size of files being imported in a given interval.
If You/data file supplier cannot meet the DDL base requirements, Oracle may provide programming
services at additional cost.
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
application.)
A data record must only exist on a single line.
A field delimiter is configurable within the application. 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 application.)
The application 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:
o "I" for Insert
o "U" for Update
o "M" for Delete
o "R" for Retransmit
When a transaction specified by a transaction type flag cannot be performed then an error will be
generated.
Page 31 of 35
The application optionally can process Insert and Delete transactions sent in the same data file.
Data types supported are: Text, Integer, Float, and Date
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.
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 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 copied 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.
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.
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
Data file suppliers must have a supported sFTP client to login to Oracles’ hosted sFTP server at
sftp.webcrf.net and transmit files. Oracle currently 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.
Page 32 of 35
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.
Error Handling
Oracle SFTP Server
SFTP provides authentication, data compression and file integrity algorithms to help confirm 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 may assist with
resolution.
DDL Import
For the import of 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 application can be configured to send email notifications for success and error.
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 Your 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.
Generate design specifications from Your-supplied requirements. One design iteration is
included for the design specifications.
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.
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).
Create secured FTP file directories according to the configuration specified in the Vendor
specification requirements document.
Testing –
o Perform smoke testing to validate the designs.
o Document the test cases needed for this configuration, and perform formal testing of the
DDL Application.
Page 33 of 35
o
Conduct an independent validation of the DDL Application configuration by testing
components against approved specifications.
UAT (up to 1 round(s)) –
o Install and configure the DDL Application in Your UAT environment.
o One (1) User Acceptance Testing (UAT) findings meeting.
o Respond to questions that You raise in UAT.
o If required, deploy a new configuration to the UAT environment for You to re-test.
o If additional rounds of UAT are required, the Change Order process will be followed
(including additional fees and time).
Once UAT is concluded, install and configure the DDL Application in Your Production instance.
Fixes to the Production DDL Application –
o Related documents are created by Oracle and approved by You.
o 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 activities are required.
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.
Your responsibilities for a given project are dependent upon the components included in the project.
Examples include but are not limited to:
You are responsible for managing the relationship and communication with the data file
supplier(s).
You and data file suppliers are responsible for correcting and resubmitting rejected records if
records are rejected due to Study or data supplier oversights.
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, Your external partners, etc.).
Reviewing and approving documents related to Production DDL application changes and fixes.
Page 34 of 35
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.
CRF Submit – Additional Runs
Deliverables and Customer Dependencies
The deliverables are dependent upon the requirements. Some common deliverables that apply to most
requests include:
Requirements – These are written, with Your input, by the Oracle project team to document Your
needs.
Study data in either an Archive Portable Data Format ("PDF") file or a Submission Ready
PDF file, as specified by You in the requirements document.
o These are intended to document the data as it existed at the time the trial was locked in
the Production instance of the configured InForm Study.
o Generation of additional set(s) of output with different output requirements, such as a
subset of data for auditing purposes, is not covered by this Service.
Your responsibilities are dependent upon the requirements. Examples include but are not limited to:
Delivering clear and complete requirements in accordance with the agreed timeline planning.
You must complete and return to Oracle a CRF Submit requirements document for each
request for PDF files to select required data elements to be included in the files and selection of
output types.
Distributing archival PDFs and Trial Archival Package (TAP), as appropriate.
Acceptance of Deliverables
Upon Oracle’s completion of any deliverable, 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 will have five (5) business
days after Oracle’s submission of the deliverable (“Acceptance Period”) to give Oracle written notice
which shall specify the deficiencies in detail. Oracle will use reasonable efforts to promptly cure any such
deficiencies. After completing such cure, Oracle will resubmit the deliverable for Your review and testing
as set forth above. Upon accepting any deliverable submitted by Oracle, You must 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 will be deemed accepted at the end of the
Acceptance Period.
Page 35 of 35
© Copyright 2024