Attachment_TSKORD04_JReviewBusinessReqPortesIntegration.docx

Business Requirements Document Food and Drug Administration

JREVIEW-PORTES INTEGRATION V0.1

ENTERPRISE PERFORMANCE LIFECYCLE

BUSINESS REQUIREMENTS DOCUMENT

Document Version Number: 1.0 Document Version Date: December 5, 2013

VERSION HISTORY

Version Number Implemented By Revision Date Approved By Approval Date Description of and Reason for Change

Draft

Version 1.0

Introduction

1.1 Purpose

The purpose of this document is to describe the requirements for the integration for JReview to access and integrate with the Portes environment. 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. A simple Use Case approach will be used to help define the business requirements in this document.

1.2 Intended Audience

The main intended audience for this document is the business owners of JReview. Other audiences are the eData Team responsible for performing the study registrations, the ICS JReview development team and the FDA JReview support team.

Executive Summary

1.3 Project Overview and Background

The JReview application is currently being used by CDER reviewers to tabulate, visualize, and analyze safety and efficacy data. Versioning and validation of the data used by JReview has long been an issue for staff responsible for loading data into this application. Within the past year, CDER has made significant progress in implementing a capability that handles both the versioning and validation of clinical and non-clinical data (Portes).

The project goal is to implement an integration solution for JReview to connect to and utilize the capabilities provided by both Portes and to provide a solution for the automated loading of versioned datasets into JReview. This new process will eventually replace the existing manual “study registration process”

It is critical that there is no negative impact on existing JReview reporting and visualization functionality. No existing functionality will be impacted with the exception of study registration.

1.4 Business Goals/Objectives to be achieved

The major features of the JReview-Portes integration are as follows:

· Implement data loading from Portes to JReview -

· This will support both incremental and full replacement of SAS datasets.

· The loading of the datasets will support both an automated solution as well as a manual solution.

· Medical Officers will have the ability to “refresh” the data from within JReview if newer data exists within Portes.

· Improve error handling -

· Support new Pass/Fail flagging for loading of data allowing for historical views of data loads.

· Error logs will be uploaded to Portes for failures only.

· If information from “Data Fit” is available then to automatically provide access within JReview to the Standard Analysis Panels.

· Continue to support the existing study registration method without negative impact to this method.

1.5 Benefits/Rationale

The Key benefit of this integration project is to be able to utilize the PORTES data storage and data versioning as a replacement of the EDR as the source of the submission data to be viewed within JReview. The main component of this integration is the replacement of the manual registration process with a batch loading/registration process as well as one that can be used as needed.

1.6 Stakeholders

The following comprises the internal and external stakeholders whose requirements are represented by this document.

Stakeholders

1.7 Project Dependencies

The JReview-Portes integration project relies on the existing JReview operating system components as well as a stable and reliable Portes environment.

Assumptions and Constraints

Requirements Scope

1.8 In Scope

The business use cases below are in scope for the integration project.

· Batch data load from Portes to JReview – This case represents the ability of the integration to support loading the data from Portes to JReview utilizing a batch method. This will be managed by the application administrators (eData Team). The study data that is loaded will be controlled by flagging that the study data is to be made available to JReview and will support full and incremental data loading.

· Manual (ad-hoc) data load from Portes to JReview – This case represents the ability of the integration to support the user’s ability to request data to be loaded from Portes into JReview through the JReview application. This will be made available to Medical Reviewers as well as Application Administrators. The study data that is loaded will be controlled by flagging that the study data is to be made available to JReview and will support full and incremental data loading.

· Visualization of data currency – This use case represents the ability of the integration to provide information from within JReview to the users as to the whether newer data is available in Portes for the study data presently loaded into JReview.

· Data load error flagging – This use case represents the ability to of the integration to support providing information back into Portes for any error conditions that occur when data is loaded from Portes to JReview. The information to be made available will not only represent the pass/fail status of the load, but also error logs for failed loads.

1.9 Out of Scope

Any business use cases which is an enhancement not related to the loading of data from Portes to JReview is to be considered out of scope for the integration project.

Functional Requirements The functional requirements listed below represent the key functions that the integration project must provide. Details surrounding the delivery for each of these requirements are captured in other documents. The information is provided in the form of use cases identified in section 4. All of the use cases listed are considered essential.

Actor Profiles Specification The main Actors in this project are: Medical Reviewer; Application Administrator; and Systems Administrator.

· Manual (ad-hoc) data load from Portes to JReview from within JReview.

· Manual (ad-hoc) data load from Portes to JReview from within JReview.

· The ability to review and monitor any data load errors via information provided by the load process into Portes.

· The ability to monitor and provide technical support for the batch process for loading data from Portes to JReview.

Essential Use Case Specifications All of the use cases listed are to be considered essential use cases.

Use Case Narrative

2. JReview components are running.

3. Portes is running.

4. Batch process starts without error.

5. Data is flagged for loading from Portes to JReview.

2. Study available and the data is usable in JReview

Includes:

2. JReview components are running.

3. Portes is running.

4. Data currency is visible to the end-user.

2. Study available and the data is usable in JReview

Includes:

2. JReview components are running.

3. Portes is running.

4. Study data as SAS datasets has been loaded into JReview from Portes.

5. Last modification date for the data in Portes is available and retrievable.

Includes:

2. JReview components are running.

3. Portes is running.

4. Definition as to the structure and location of the logs is known.

Includes:

Data Requirements Data Architecture The data requirements for the JReview-Portes integration is similar to the existing JReview-EDR loading process. The source data as it resides in Portes is in SAS Transport format. The data once loaded into JReview is SAS datasets extracted from the transport files.

The structural content of the datasets for each study will have the same requirements as the existing JReview environment. Each study will need to have a dataset which contains one patient record per patient. This dataset is typically identified as the demography dataset. The loading system will also need to know which variable contains the unique patient identifier as well as which variable is the “visit” variable. For studies which adhere to the CDISC SDTM or ADaM data models, the patient and visit variables as well as the demographic datasets are known and will not need to be set per study.

The system will also be required to support data from different Portes locations for the same study’s registration/loading. An example of this is having the ADaM and the SDTM data for a study stored in separate containers within Portes and for the loading of the data into JReview it will need to be available to the single study.

Data Volumes The volume of data for this project is expected to be no more than the current JReview-EDR environment.

Data Conversion The only data conversion required for this project is the conversion of SAS Transport files (stored in Portes) to SAS datasets (used by JReview).

Data Retention and Archiving Since the data loading project is a sub-system of the JReview environment, there is no special data retention policy required for this system.

Privacy Implications All data privacy will adhere to the JReview system privacy requirements. There are no new requirements for this system.

Non-Functional requirements Security Requirements As part of the loading process, no individual user will be granted access to Portes. All access will be granted via a general account through the JReview integration. This account needs to be able to read from the clinical data and write to the area for logging and flagging as defined in the Use Cases. The only users who will have access to this account will be the System Administrators. No Medical Reviewer will have access to this secure account for direct access to Portes.

Authentication There will be no change in the current authentication methods for JReview.

Authorization and Access Controls Actor / Business Unit Name

C Create R Read U Update D Delete Q Request

Availability Requirements The requirements for availability are the same as they are for JReview. The availability of the data loading process and its related components need to be available whenever JReview and Portes is available.

Usability Requirements The data loading system needs to provide clear information as to the status of the load (successful or failure) as well as it needs to be clear to the JReview user as to the data currency of the study data that has been loaded into JReview from Portes.

The Manual (ad-hoc) data loading needs to support requests from multiple users concurrently.

System Help Requirements The existing JReview “Help” will need to include information for the new processes.

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.

Scalability Requirements User Scalability 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.

Application Scalability The Batch Load process needs to be able to complete the loading of the data within an eight hour period.

Interface Requirements User Interface Requirements The main requirement for the user interface for the loading system is that the currency of the study data is easily visible and easy to understand by the Medical Reviewer when looking at the submission from within JReview. It must be clear, from within JReview, to the user as to how to choose to load the study data manually if newer data exists within Portes. It must also be clear, from within JReview, is a data load has failed.

System Interface Requirements The main system interface requirement is that the new data loading integration processes and error logging, must not require system changes to Portes that would invalidate the existing system. These integration processes need to utilize the provided and documented APIs provided by SAS Institute.

Appendix As Is Diagram

To Be Diagram

Version 1.0, 7/21/2015

Business Requirements Document Page 14 of 14 image1.png image2.emf

Microsoft_Visio_Drawing1.vsdx image3.png image4.png