Attachment_TSKORD05_JReviewSystemReqPortesIntegration.docx

Version: 1.0 Error! Unknown document property name.

System Requirements Specification

Food and Drug Administration

JREview Project Integration with portes

ENTERPRISE PERFORMANCE LIFECYCLE

SYSTEM REQUIREMENTS SPECIFICATION

Document Version Number: 1.0 Document Version Date: 12/05/2013

Requirements Definition Version: 1.0 Error! Unknown document property name.

Template Version 2.1 (Last Modified on Oct, 29 2010)

Revision Date: Error! Unknown document property name. Page 2 of 16 EPLC_System_Req_Spec_v#.#.doc

VERSION HISTORY

Version Number Implemented By Revision Date Approved By Approval Date Description of Change

Draft

Version 1.0

SYSTEM REQUIREMENTS SPECIFICATION APPROVAL

The undersigned acknowledge that they have reviewed the JReview System Requirements Specification and agree with the information presented within this document. Changes to this System Requirements Specification will be coordinated with, and approved by, the undersigned, or their designated representatives.

Signature:

Date:

Print Name:

Title:

Table of Contents

Introduction

1.1 PURPOSE

The purpose of the System Requirements document is to specify the overall system requirements that will govern the development and implementation of the integration for JReview to access and integrate with the Portes environment. The document will also establish initial security, training, capacity and system architecture requirements, as well as, system acceptance criteria agreed upon be the project sponsor and key stakeholders.

Business Requirements Overview The Portes environment contains the submission data as SAS Transport files which need to be utilized by the Medical Officers using JReview. Both JReview and Portes are systems within the FDA environment. The currently the SAS transport files are stored in the EDR and are moved upon request by the Medical Officer to a staging area for the registration and use from within JReview. This interaction will be replaced by the results of this integration project.

The list of major requirements are:

1. Batch method for loading submission data from Portes to JReview.

2. Manual (ad-hoc) method for loading a single study’s data from Portes to JReview.

2.1 ASSUMPTIONS / CONSTRAINTS

2.2 STAKEHOLDERS AND USERS

See the Business Requirements Document

2.3 SYSTEM SCOPE

The scope of the JR-Portes integration is defined within the system framework of JReview and Portes. The integration will not include data from outside or Portes and will only load data to JReview. The data being loaded will be clinical data from submissions to the FDA. The data will be stored in the form of SAS datasets in transport format within Portes and will be stored as SAS datasets for use with JReview.

The existing JReview environment will be utilized as the environment for JReview data storage. The SAS datasets reside on a UNIX file system. This will not change from the existing JReview environment running against SAS datasets.

FUNCTIONAL REQUIREMENTS

i) Batch Load Requirements

(1) Scan all Portes submissions/study folder to detect studies added to Portes that are set to be loaded into JReview and automatically load those studies.

(2) Support both CDISC SDTM/AdAM data structures for a single JReview Study (using standard conventions) to be loaded per study.

(3) Support loading legacy data by providing1 a method to determine CaseID, VisitID & Demography dataset (a SAS dataset with 1 row per patient).

(4) Only allow a study to be loaded if there error flag has been cleared, if present.

(5) Support the repetitive SAS Scheduling.

ii) Manual (ad-hoc) Load Requirements

(1) Detect studies that had been set to be loaded into JReview – and previously loaded, that now have updated data.

(2) Store ‘lastModifiedDate’ for datasets updated – compared to current ‘lastModifiedDate’ in previously loaded study’s datasets.

(3) When user accesses study with updated versions available, prompt user (if they have study update privilege) – if they want to update to latest version. If so, schedule update job to run immediately (or overnight).

(4) Prompt user to keep original version of study, as well as the new version – to be able to compare or refer back to the original set.

(5) Support ‘auto-update’ study status (if user with privilege sets study to be in auto-update mode).

(6) Only allow a study to be loaded if there error flag has been cleared, if present.

iii) Provide Currency of Study Data

(1) Provide visual status of the currency of the data loaded from Portes.

(2) If the data is loaded from Portes then it should be clear to the user as to the data within JReview is the most current.

(3) If the origin of the data is not Portes then it should be clear that this information is not available.

iv) Data Load Error Status

(1) After load job completes (batch or manual), the loading process will need to write back status info into Portes in ‘load JReview’ flag file.

(2) If problems with load job, write summary of issues back to Portes status file.

3.2 SYSTEM MESSAGES

The only system messages are those described in the system functional requirements namely:

· ii(3) When user accesses study with updated versions available, prompt user (if they have study update privilege) – if they want to update to latest version. If so, schedule update job to run immediately (or overnight).

· ii(4) Prompt user to keep original version of study, as well as the new version – to be able to compare or refer back to the original set.

· iv(1) After load job completes (batch or manual), the loading process will need to write back status info into Portes in ‘load JReview’ flag file.

Non-Functional Requirements

4.1 DESIGN CONSTRAINTS

Since this is an integration project, there are 2 main constraints:

i) All JReview interfaces will need to adhere to the JReview UI interface requirements and remain within the Java framework.

ii) Any access to Portes will be via an acceptable and published API method.

4.2 HARDWARE REQUIREMENTS

Since this is an integration project, there are no new hardware requirements.

4.3 SOFTWARE REQUIREMENTS

Since this is an integration project, there are 2 main software requirements:

i) All JReview interfaces will need to adhere to the JReview UI interface requirements and remain within the Java framework.

ii) Any access to Portes will be via an acceptable and published API method.

4.4 PERFORMANCE REQUIREMENTS

Since the performance of the loading process (batch or manual) is dependent on the size of the data being loaded, this cannot be specific as a specific set of values in a requirement. What is required is that the new process does not cause performance issues by increasing the response time of the existing JReview functionality.

4.5 CAPACITY REQUIREMENTS

The Manual (ad-hoc) Data Loading process needs to be able to support requests from multiple users requesting that their study data is to be refreshed without failure. It should be able to support up to 6 simultaneous data loading requests without failure.

4.6 RELIABILITY REQUIREMENTS

Since the JReview-Portes integration processes are processes that rely on the underlying systems (JReview and Portes) to be available, the loading processes must be as reliable as the underlying systems. When both systems are available then the loading processes must be available. The uptime and availability requirements for the loading processes will be dependent on the uptime and availability of the combined JReview and Portes systems.

4.7 SUPPORTABILITY REQUIREMENTS

The support requirement for the JReview-Portes integration project is that it does not require any additional resources than the existing resources allocated for support of the existing systems.

4.8 USER DOCUMENTATION REQUIREMENTS

Any features that effect the UI will require changes to the existing user manual for JReview. Documentation for the usage of the loading process via the batch method will be created and provided to the technical support and end-user support groups.

4.9 records management REQUIREMENTS The records management requirements are the same as they are for JReview.

4.10 INTERFACE STANDARDS

4.10.1 USER INTERFACE STANDARDS

The only component of the JReview-Portes integration which has a UI component is the section relating to the Manual (ad-hoc) data loading with the data currency. The data currency will need to be clearly displayed within JReview along with the study information that has been registered to JReview so that the end-user knows that newer data resides in Portes than it does in JReview. The method for updating this data must be clear to the end-user so that the steps to be taken are easily understood.

If the loading of the study data has failed, this failure should be clearly visible within JReview’s list of studies.

4.10.2 HARDWARE INTERFACE STANDARDS

No new hardware requirements are needed for this system.

4.10.3 SOFTWARE INTERFACE STANDARDS

Software that will be utilized in this integration will be the JReview software, SAS, and the SASDD (base system of Portes).

4.10.4 COMMUNICATIONS INTERFACE

The communication requirements between JReview and Portes will be using the published SDD API methodology and communication standards.

4.11 SECURITY AND PRIVACY REQUIREMENTS

The JReview-Portes integration security and privacy requirements do not exceed the existing requirements for either system. The data loading process will respect and utilize Portes security for data read access and the study level access to the data loaded for use by JReview will adhere to the JReview security model.

4.12 COMPLIANCE AND STANDARDS REQUIREMENTS

Please see the Compliance and Standards requirements for JReview.

4.13 LICENSING REQUIREMENTS

The JReview-Portes Integration project will not require any additional licensing of software.

4.14 LEGAL, COPYRIGHT, AND OTHER NOTICES

The JReview-Portes Integration project will not require any additional legal, copyright, or other notices.

4.15 Applicable Data-exchange and Terminology Standards

The data standards referenced within this project are the CDISC (Clinical Data Interchange Consortium) SDTM and the CDISC AdAM data standards.

APPENDIX A: REFERENCES

The following table summarizes the documents referenced in this document.

TBD

<Document Name and Version Number>

TBD

<Document description>

TBD

<URL or Network path where document is located>

APPENDIX B: KEY TERMS

The following table provides definitions and explanations for terms and acronyms relevant to the content presented within this document.

TBD

[Insert Term]

TBD

<Provide definition of term and acronyms used in this document.>

APPENDIX C: Business Process Model [Insert Business Process Model here.]

APPENDIX D: Logical Data Model [Insert Logical Data Model here.] Revision Date: Error! Unknown document property name.

image1.png