2.2.1 70B06C25R00000019 DRAFT Attachment 2- Statement of Work Appendix A- Detailed LIMS Requirements.xlsx
XLSX spreadsheet 78 KB Posted
- Solicitation number
- 70B06C25R00000019
About this file
This file is a detailed requirements appendix for the Statement of Work for a Forensic Laboratory Information Management System (LIMS) for U.S. Customs and Border Protection's Laboratory & Scientific Services division. The appendix outlines comprehensive technical requirements across 12 major sections including customization/configuration, modules, evidence/sample handling, query/reporting, electronic records, user accounts, workflow, labeling, storage management, infrastructure/support, chain of custody, and maintenance/administration.
Key requirements include: support for 400 users with role-based access, PIV/CAC card authentication, FedRAMP compliance, integration with CBP systems, 99.9% system availability, 24/7 maintenance support, barcode/RFID functionality with 400 handheld scanners and 70 printers, chain of custody tracking, electronic signatures, mobile capabilities, and cloud hosting options. The system must comply with NIST, FISMA, and DHS security standards. This is part of solicitation 70B06C25R00000019, which will be a single-award firm-fixed-price contract with a 1-year base period and nine option years. The RFP will be released around March 5, 2025 with Phase I responses due March 30, 2025. Industry feedback on the draft is requested by February 25, 2025. The NAICS code is 513210 with a $47M size standard.
View the file
Other files
On GovTribe
Work with this file
- Download the original file
- Contacts named in this file
- Similar government files
- Ask GovTribe AI about this file
Text version
Implementation & Custimization
| Request for Proposals (RFP) 70B06C25R00000019 | |
| U.S. Customs and Border Protection (CBP) Laboratory & Scientific Services (LSS) Forensic Laboratory Information Management System (LIMS) | |
| Attachment 2- Statement of Work, Appendix A- Detailed LIMS Requirements | |
| Implementation Strategy | |
| Implementation Strategy | Description |
| Base Product | Part of the basic solution. No configuration or customization necessary to meet requirement. |
| Configuration of Base Product | Available as part of the basic solution, configuration required to meet requirement. ***Configuration is changing of existing functionality, features, or settings without needing to change underlying code.*** |
| Customization of Base Product | Not available as part of basic solution, customization of the COTS product to meet requirement. ***Customization involves changing of underlying code to add new functionality, features, or settings.***MUST SELECT CUSTOM COMPLEXITY LEVEL. |
| None | The requirement cannot be met through either the base product offering, configuration, or customization. |
| Customization Complexity | Description |
| Basic Customization | Simple settings like color schemes, language selection, and basic feature toggles, requiring minimal technical knowledge to adjust. Can be accomplished in less than 24 hours. |
| Moderate Customization | Pre-defined options to tailor the software to specific needs, including selecting modules, setting parameters, and defining workflows through user-friendly interfaces. Can be accomplished between 1 and 5 days. |
| Advanced Customization | Access to APIs or scripting capabilities allowing users to extend functionality and integrate with other systems through custom code, requiring a higher level of technical expertise. Can be accomplished in 5 - 30 days. |
| Full Development Customization | Direct access to the software's source code, enabling complete modification of features, logic, and underlying architecture, usually reserved for developers with in-depth knowledge of the software system. Longer than 30 days for completion. |
| None | The requirement cannot be met. |
DRAFT
LSS Requirements
| DHS, CBP LSS Forensic LIMS Requirements | |
| Section | Description |
| 5.1 | Customization, Configuration and Program Management Requirements |
| 5.2 | Module Requirements |
| 5.3 | Evidence/Sample Requirements |
| 5.4 | Query/Reporting Requirements |
| 5.5 | Electronic Record and Audit Trail Requirements |
| 5.6 | User Account Requirements |
| 5.7 | Workflow Requirements |
| 5.8 | Labeling (Barcode/RFID/QR) Requirements |
| 5.9 | Storage Management Requirements |
| 5.10 | Infrastructure and Support Requirements |
| 5.11 | Evidence Handling and Chain of Custody |
| 5.12 | Maintenance and Administration Requirements |
DRAFT
5.1 Customization
| 5.1 | Customization, Configuration and Program Management Requirements | |||
| Number | Requirement | Detailed Description | Implementation Strategy (select appropriate strategy from drop down list) | Customization Complexity (select appropriate complexity from drop down list) |
| 5.1.1 | The system contractor shall support customization, configuration, and program management in support of the Forensic LIMS system | The contractor shall support CBP specific custom updates to the Forensic LIMS system. | ||
| 5.1.2 | The contractor shall provide project management support services that include but are not limited to planning, coordination of activities, project planning, reporting, appointing responsibilities (on the contractor team) and driving the project forward. The project manager shall serve as a single point of contact for the Government project manager and Contracting Officer Representative (COR). | |||
| 5.1.3 | The contractor shall participate in Government led working group discussions to understand the business process, regulations, data management needs, and other requirements. These discussions will also afford the contractor an opportunity to work with LSS’s functional groups to outline the sequence(s) and individual process steps that will serve as the basis for LSS’s various functional workflows. | |||
| 5.1.4 | The contractor shall support Government acceptance tests prior to acceptance by the Government. The COR/technical POC will approve all contractor provided acceptance criteria. These approved tests will be used for acceptance of all contractor deliverables. Government testing shall be conducted at a Government owned or operated facility. | |||
| 5.1.5 | The contractor shall support both onsite and offsite software maintenance services. | |||
| 5.1.6 | Contractor shall provide support, patches, updates, and change requests to address CBP’s needs for evolving security and systems architecture needs in such areas as and not limited to security vulnerabilities, and systems hardening. | |||
| 5.1.7 | A home page/dashboard to Users that displays information relevant to their accounts/submissions in a consolidated view (such as number of submitted requests, item receipt and acceptance acknowledgement, projected turnaround times, etc.), with the ability to see all details and add communications. |
DRAFT
5.2 Module
| 5.2 | Module Requirements | |||
| Number | Requirement | Detailed Description | Implementation Strategy (select appropriate strategy from drop down list) | Customization Complexity (select appropriate complexity from drop down list) |
| 5.2.1 | The system shall support modules | The system shall provide for separate modules for each LSS functional area. | ||
| 5.2.2 | The system shall have the capability to create and modify modules. | |||
| 5.2.3 | The system shall provide for modules to have fillable data-entry fields, dropdown data-entry fields, and automatically generated fields which leverages predictive text based on LSS-specific business rules and logic. | |||
| 5.2.4 | The system shall provide for modules to interoperate and interface with each other, have parallel workflow processes (in the entire system and within and between each module), and have flexibility to change. | |||
| 5.2.5 | The system shall provide a filter capability within each module that is recorded and trackable. | |||
| 5.2.6 | The system shall provide for the capability to transfer multiple items with multiple users at one time between modules with no limit on the number of items in a case. | |||
| 5.2.7 | The system shall provide for the capability to support multiple file attachments at a time and have the capability to select multiple files to upload or drag and drop functionality | |||
| 5.2.8 | The system shall provide for the capability to accommodate file extensions (pdf., jpeg, docx, xlsx, pptx, TIFF, BMP, RAW, .doc, .xls, .ppt, .jpg, .n42, .sir, .msg, .dot, .xml, spc, zip, .rtf and.txt) with no upload size limitations. | |||
| 5.2.9 | The system shall have the capability to add new fields or modify pre-existing fields | |||
| 5.2.10 | Shall have the ability to create various templates that is applied to a QC batch. In addition, QC shall be specified on an ad hoc basis. These templates control the creation and inclusion of QC samples and analytes in the batch such as blanks of multiple types, duplicates, spikes, spike duplicates, calibrations, lab controls of multiple types, negative control of multiple types, check standards, internal standards, surrogates, etc. |
DRAFT
5.3 Evidence-Sample
| 5.3 | Evidence / Sample Requirements | |||
| Number | Requirement | Detailed Description | Implementation Strategy (select appropriate strategy from drop down list) | Customization Complexity (select appropriate complexity from drop down list) |
| 5.3.1 | The system shall support tracking of evidence chain of custody. | The system shall provide for tracking electronic chain of custody of evidence submitted for examination which can be used in U.S. courts of law at the federal, state and local levels. | ||
| 5.3.2 | The system shall support different data entry modes. | The system shall support manual data entry. | ||
| 5.3.3 | The system shall support data entry by selecting from a predefined selection list. | |||
| 5.3.4 | The system shall support the use of default values. | |||
| 5.3.5 | The system shall prohibit the overwriting of display only fields. | |||
| 5.3.6 | The system shall enforce mandatory field entry. | |||
| 5.3.7 | The system shall support the manual and automatic entry of evidence. | |||
| 5.3.8 | The system shall support the creation of a case. | The system shall support the entry of sample, subsample, or item-of-interest using a LSS functional area predefined template. | ||
| 5.3.9 | The system shall support the entry of one or more pieces of evidence at a time. | |||
| 5.3.10 | The system shall support the entry of parent evidence and splitting into child evidence. | |||
| 5.3.11 | The system shall support the entry of evidence at the time of its arrival in the laboratory. | |||
| 5.3.12 | The system shall automatically generate a unique evidence ID of a predefined format. | |||
| 5.3.13 | The system shall support the browsing of a static data table and the display of descriptive information during the entry of evidence information. | |||
| 5.3.14 | The system shall allow evidence to be flagged as a rush or expedite. | |||
| 5.3.15 | The system shall send an email alert to the assigned examiner and/or an alert notification to the assigned entities queue in when evidence is flagged as a rush. | |||
| 5.3.16 | The system shall support the attachment of files to evidence. | |||
| 5.3.17 | The system shall support concurrent users | Able to support multiple concurrent Users accessing the same case at the same time, but to apply network rules to prevent two (2) Users from editing the same service request at the same time (e.g., if two (2) Users are attempting to edit a single analysis request or interpretative report, the system must warn the second User that the service/report is locked for editing.). | ||
| 5.3.18 | The system shall provide evidence life cycle management. | The system shall support evidence life cycles that are specific to the evidence type. | ||
| 5.3.19 | The system shall support the automation of select life cycle steps based upon the evidence type. | |||
| 5.3.20 | The system shall automatically capture the user ID, date, and time for steps in the life cycle of evidence. | |||
| 5.3.21 | The system shall automatically track the status of evidence throughout its life cycle. | |||
| 5.3.22 | The system shall allow the status of evidence to be displayed. | |||
| 5.3.23 | The system shall update the status of evidence based upon the status of its assigned examinations/tests. | |||
| 5.3.24 | The system shall support the manual entry of evidence or the scan of evidence barcode label during workflow processing. | |||
| 5.3.25 | The system shall support a logical grouping of evidence based upon a unique operation/project and/or analytical service request. | |||
| 5.3.26 | The system shall support the prioritization of evidence based upon information including, but not limited to hold time or rush status. | |||
| 5.3.27 | The system shall support the modification of evidence. | The system shall allow evidence information to be modified and enforce the entry of a reason. | ||
| 5.3.28 | The system shall prohibit the modification of evidence following its approval without complete traceability and documentation. | |||
| 5.3.29 | The system shall support the entry of evidence. | The system shall support the approval of evidence and the assignment of a final disposition. | ||
| 5.3.30 | The system shall provide a predefined selection list of evidence dispositions. | |||
| 5.3.31 | The system shall support the entry/logging of a comment at the time of evidence approval. | |||
| 5.3.32 | The system shall support the display of findings or test results at the time of the evidence approval. | |||
| 5.3.33 | The system shall provide a mechanism to undo evidence approval and enforce the entry of a reason. | |||
| 5.3.34 | The system shall support additional evidence functions. | The system shall support the submission of evidence to a contract laboratory for testing and link the contract lab ID to the evidence ID. | ||
| 5.3.35 | The system shall support the assignment of an analyst to a case or item of evidence. | |||
| 5.3.36 | The system shall support the assignment of multiple disciplines to the same piece of evidence. | |||
| 5.3.37 | The system shall support the cancellation of analysis on evidence and enforce the entry of a reason. | |||
| 5.3.33 | The system shall prohibit the cancellation of a case following evidence acceptance. | |||
| 5.3.39 | The system shall allow cancellation of analysis on evidence to be undone and enforce the entry of a reason. | |||
| 5.3.40 | The system shall support the withdrawal of evidence or sample and enforce the entry of a reason. | |||
| 5.3.41 | The system shall support the entry and display of an evidence note to document comments, data qualifiers, or deviations from standard operating procedures, policies and/or practices, with the option to flag the note as reportable or non-reportable. | |||
| 5.3.42 | The system shall provide a list from which evidence comment may be selected, with the ability to override the predefined list. | |||
| 5.3.43 | The system shall support and track the disposal of evidence. | |||
| 5.3.44 | The system shall support evidence planning. | The system shall provide a way to track chemical inventory receipt dates, storage, and disposal. | ||
| 5.3.45 | The system shall provide a mechanism to export an evidence planning schedule. | |||
| 5.3.46 | The system shall support different data types and formats. | The system shall support the use of a text data type to include auto text. | ||
| 5.3.47 | The system shall support the use of an integer data type and allow the entry and display of one or more leading zeros. | |||
| 5.3.48 | The system shall support the use of a decimal data type and allow the entry and display of one or more leading zeros. | |||
| 5.3.49 | The system shall support the use of a date data type. | |||
| 5.3.50 | The system shall support the use of a date/time data type. | |||
| 5.3.51 | The System shall flag cases for follow-up and/or pending activities. | Calendar or interval-based schedules may be defined to create specific testing requests according to pre-determined rules. | ||
| 5.3.52 | • Flag cases re: internal case management by scientists / managers to manage follow-up in cases (e.g., contact User). | |||
| 5.3.53 | • Flag cases for pending case activities (upcoming User case conferences - case calendar (conference, due date, subpoena date(s)). |
5.4 Querry-Reporting
| 5.4 | Query / Reporting Requirements | |||
| Number | Requirement | Detailed Description | Implementation Strategy (select appropriate strategy from drop down list) | Customization Complexity (select appropriate complexity from drop down list) |
| 5.4.1 | The system shall support the use of queries. | The system shall provide one or more queries for each workflow function, where each query provides a logical and intended set of filtered objects to process for a specific purpose. | ||
| 5.4.2 | The system shall support the captures/query of audit trail logs of all transactions within the Forensic LIMS. | |||
| 5.4.3 | The system shall provide a mechanism to sort the results of a query. | |||
| 5.4.4 | The system shall support assigning and tracking of data. | The system shall contain the ability to assign, track, collect, create, and store all data related to LSS laboratory casework and analyses, and maintain a chain of custody for the life cycle of the evidence until disposition. | ||
| 5.4.5 | The system shall be capable of generating reports. | The system shall provide an ad-hoc report writer. | ||
| 5.4.6 | The system shall allow for the use of report templates. | |||
| 5.4.7 | The system shall provide standard, out of the box reports. | |||
| 5.4.8 | The system shall display the following in all reports which can be customized at any time: This U.S. Customs and Border Protection laboratory report and any attached files or information are provided “For Official Use Only”. |
Results contained in this laboratory report relate only to the items tested. The Laboratory report may contain information that may be exempt from public release, under the Freedom of Information Act (5 U.S.C. 552) (FOIA) and/or the Privacy Act (5 U.S.C. 552a), or may be “Law Enforcement Sensitive”. The information provided should not be employed for any other use that is not consistent with a use for which it has been provided and shall not be reproduced, except in full. All FOIA or any other requests for information pertaining to this laboratory report must be directed to the originator, U.S. Customs and Border Protection, Laboratories and Scientific Services Directorate for review and subsequent release.
| 5.4.9 | The system shall be capable of including a barcode in a report. | |
| 5.4.10 | The system shall allow the querying of information based upon predefined criteria including, but not limited to, lab code, medium code, evidence submitter, project, work order code, date range, analyst, presence of a comment or data quality code. | |
| 5.4.11 | The system shall allow the sorting of information based upon predefined criteria including, but not limited to, lab code, medium code, evidence submitter, project, work order code, date range, analyst, presence of a comment or data quality code. | |
| 5.4.12 | The system shall allow the sorting of qualifiers by a predefined, static priority table. | |
| 5.4.13 | The system shall be capable of reporting in tabular format. | |
| 5.4.14 | The system shall be capable of reporting in graphical format. | |
| 5.4.15 | The system shall provide statistical information on test results including mean, standard deviation, relative standard deviation, range, and confidence intervals to be able to pull results that have been input and allow to pull an ad hoc comparing other lab reports.. | |
| 5.4.16 | The system shall support different report generation mechanisms. | The system shall support the manual generation of a report (e.g. Crystal Reports) |
| 5.4.17 | The system shall support the electronic routing of reports for review purposes. | |
| 5.4.18 | The system shall support electronic notification or report status. | |
| 5.4.19 | The system shall support report creation using an intuitive drag-and-drop graphical user interface | |
| 5.4.20 | The system shall enforce the entry of an electronic signature at the time of manual report generation for critical reports. | |
| 5.4.21 | The system shall support the automatic generation of a report based upon a predefined trigger. | |
| 5.4.22 | The system shall support different report delivery modes. | The system shall support the on-screen display of a report. |
| 5.4.23 | The system shall support the hardcopy printout of a report. | |
| 5.4.24 | The system shall support data visualization. | The system shall support the use of dashboards to visualize and display data. |
| 5.4.25 | The system shall support custom dashboards. | |
| 5.4.26 | The system shall support the visualization of all data fields from a single field to all field. | |
| 5.4.27 | The system shall create reports of sub-items. | Shall have the ability to produce Chain of Custody reports for use with items sub-items and containers for its own Chain of Custody tracking of all item /containers for all laboratory operations. |
| 5.4.28 | The system shall create work requests. | A structured query mechanism shall be available to find work requests according to a particular set of criteria. Reports shall be available to provide structured information about work requests. In addition, a User friendly, flexible ad- hoc, general query mechanism must be available to produce any sort of dataset which can be exported to excel, etc. Queries must be able to be saved and reused. |
| 5.4.29 | Various reports shall be available to summarize information about a work request. These shall be User configurable. Also, reports for testing requests shall be customizable for a specific User or for a specific work request specification. Reports shall be issued by push button, by event, included in notifications, etc. Reports includes and not limited to chain of custody, receipt, worksheet, summary, approval chain of approval, etc. | |
| 5.4.30 | The system shall track personnel performing operations. | Shall have the ability to support tracking of personnel performing steps of the operation and their qualifications. |
| 5.4.31 | The system shall customize and be able to report various queries related to tasks. | At a minimum, shall have the ability to customize reports on: |
| • turnaround times for analyses, reports and cases, | ||
| • case workload, | ||
| • delayed cases, | ||
| • work pending. | ||
| The access to specific reports shall be dependent on User permissions |
5.5 Electronic Record
| 5.5 | Electronic Record and Audit Trail Requirements | |||
| Number | Requirement | Detailed Description | Implementation Strategy (select appropriate strategy from drop down list) | Customization Complexity (select appropriate complexity from drop down list) |
| 5.5.1 | The system shall support the use of electronic records. | The electronic record must be viewable in electronic and human readable form. | ||
| 5.5.2 | The electronic record must be accurately and completely displayed in paper form. | |||
| 5.5.3 | The system must retain and be able to retrieve an electronic record throughout the electronic record retention period as specified by Government policy. | |||
| 5.5.4 | The system shall maintain an audit trail. | The system must maintain an audit trail for the creation, update, and deletion of an electronic record. | ||
| 5.5.5 | The audit trail must contain the user id, date and time, action performed, IP address, original value, new value, and reason if appropriate. | |||
| 5.5.6 | The audit trail must not obscure or delete previously recorded information. | |||
| 5.5.7 | The audit trail must be viewable in electronic and human readable form. | |||
| 5.5.8 | The audit trail must be accurately and completely displayed in paper form. | |||
| 5.5.9 | The system must retain and be able to retrieve an audit trail record throughout the electronic record retention period as specified by Government policy. | |||
| 5.5.10 | The system shall preserve the integrity of the audit trail. | The system must prohibit the manual entry of information into the audit trail. | ||
| 5.5.11 | The system must prohibit the modification of information in the audit trail. | |||
| 5.5.12 | The system must prohibit the deletion of information from the audit trail. | |||
| 5.5.13 | The system shall support the tracking of all data. | The system must support the ability to assign, track, collect, create, and store all data related to LSS laboratory casework and analysis and maintain a chain of custody for the life cycle of the evidence until disposition. | ||
| 5.5.14 | The system must support the capture/query of the audit trail/log of all transactions within the Forensic LIMS. | |||
| 5.5.15 | The system must support the ability to perform queries of all workflow functions, Forensic LIMS data fields, sample status and workloads. | |||
| 5.5.16 | The system must support the ability to sort query results. | |||
| 5.5.17 | System must have an internal application audit capability that tracks, records, and provides detailed user account activities tied to specific actions and business rules. Each user account engages with the system and includes date and time stamps to correlate user activity over time; user account maintenance and access activities; and internal system administrator account activities. | |||
| 5.5.18 | System must provide CBP the capability to customize internal audit functions. | |||
| 5.5.19 | System must be able to work in concert with Splunk Forwarding Agents to export internal audit information to external Splunk Audit Dashboard. | |||
| 5.5.20 | System must allow and maintain an official repository of required training materials, standard operating procedures, policies, and forms tracking all versions of the document and archive expired or retired documents and policies. | |||
| 5.5.21 | The system must allow all users in the organization to see the current version of the document and send standard notifications when a new approved version is available. | |||
| 5.5.22 | The system must track all user training and certifications to include demonstration of competence and instrument authorizations as is required by accreditation standards. | |||
| 5.5.23 | The system must support automated messaging when training or evaluations are coming due to minimize any delinquencies. |
DRAFT
5.6 User Account
| 5.6 | User Account Requirements | |||
| Number | Requirement | Detailed Description | Implementation Strategy (select appropriate strategy from drop down list) | Customization Complexity (select appropriate complexity from drop down list) |
| 5.6.1 | The system shall support the management of LIMS and client portal user accounts. | The system shall support the creation of a user account. | ||
| 5.6.2 | The system shall enforce the unique identification of a user account. | |||
| 5.6.3 | The system shall prohibit the reuse of the unique identification of a user account. | |||
| 5.6.4 | The system shall support a role-based assignment of functional privileges to a user account. Roles include but are not limited to: | |||
| - Analyst | ||||
| - Business Analyst | ||||
| - Contract Lab Contracting Officer Representative (COR) | ||||
| - Data Clerk | ||||
| - Field | ||||
| - Lab Manager | ||||
| - Login | ||||
| - Quality Assurance (QA) | ||||
| - QA Manager | ||||
| - System Administrator | ||||
| - Sample Control Specialist | ||||
| - Supervisor | ||||
| - Branch Chief | ||||
| 5.6.5 | The system shall support the manual disabling of a user account. | |||
| 5.6.6 | The system shall support the manual enabling of a user account. | |||
| 5.6.7 | The system shall support an offline mode for use during mobile operations. | |||
| 5.6.8 | The system shall support the management of passwords. | The system shall enforce that a password meets or exceeds predefined format and length criteria and support Identity Management Single Sign On software utilized by CBP. | ||
| 5.6.9 | The system shall provide a mechanism to change a password. | |||
| 5.6.10 | The system shall automatically have a password expire after a predefined time interval as defined by CBP and DHS Windows Security Group Policies. | |||
| 5.6.11 | The system shall provide a mechanism to reset an expired password. | |||
| 5.6.12 | The system shall control access to and within the system. | The system shall restrict access to authorized users and enforce the entry of a valid user id and password. | ||
| 5.6.13 | The system shall not display a password in human readable form. | |||
| 5.6.14 | The system shall prohibit a user with a disabled user account from accessing the system. | |||
| 5.6.15 | The system shall prohibit a user with an expired password from accessing the system. | |||
| 5.6.16 | The system shall record unsuccessful login attempts. | |||
| 5.6.17 | The system shall automatically disable a user account after a predefined number of unsuccessful login attempts. | |||
| 5.6.18 | The system shall restrict function access to those that are assigned to a user account. | |||
| 5.6.19 | The system shall support an automatic timeout. | The system shall automatically log a user account out after a predefined period of inactivity as defined by CBP and DHS Windows Security Group Policies. | ||
| 5.6.20 | The system shall enforce entry of a valid user id and password to regain access following an automatic timeout. |
5.7 Workflow
| 5.7 | Workflow Requirements | |||
| Number | Requirement | Detailed Description | Implementation Strategy (select appropriate strategy from drop down list) | Customization Complexity (select appropriate complexity from drop down list) |
| 5.7.1 | The system shall support the use of electronic signatures eSigning with PIV/CAC smart cards authentication used in U.S. Government Agencies using certificate selection. | The system shall enforce the entry of an electronic signature at predefined processing steps, at the time the step is performed. | ||
| 5.7.2 | The electronic signature shall consist of a user id, password and reason for signing. | |||
| 5.7.3 | The system shall support the use of a predefined selection list of reasons for signing, tailored for the function that is being performed. | |||
| 5.7.4 | The system shall preserve the integrity of an electronic signature. | The system shall prohibit the modification of an electronic signature at the time of signing. | ||
| 5.7.5 | The system shall prohibit the deletion of an electronic signature at the time of signing. | |||
| 5.7.6 | The system shall provide traceability for an electronic signature. | The system shall link an electronic signature to a record that contains the user id, date and time of signing, and meaning of the electronic signature. | ||
| 5.7.7 | The electronic signature shall be traced back to the individual that entered it. | |||
| 5.7.8 | The system shall enforce that an electronic signature is unique to one individual. | |||
| 5.7.9 | The system shall support the entry of test results. | The system shall support both manual and automatic entry of findings and test results. | ||
| 5.7.10 | The system shall support the entry of integer, decimal, and qualitative findings and test results. | |||
| 5.7.11 | The system shall support the creation and update of an analytical batch with the automatic insertion of predefined QC samples in addition to unknown samples. | |||
| 5.7.12 | The system shall support the entry of findings and results by exhibit, test, analytical batch, or by preparation date. | |||
| 5.7.13 | The system shall support the selection of a test result from a predefined list. | |||
| 5.7.14 | The system shall support the display of a specific number of significant figures for numeric test results. | |||
| 5.7.15 | The system shall support the entry and display of test information and findings, including but not limited to: | |||
| • Laboratory Notebook Reference | ||||
| • External Testing Facility | ||||
| • SOP Reference | ||||
| • Tested By (if not entered by the actual analyst) | ||||
| • Test Date (Run Date) (if entered after the fact) | ||||
| • Value Qualifier Code(s) | ||||
| • Dilution Factor | ||||
| • Workorder Number | ||||
| • Comments (at any point of the workflow) | ||||
| 5.7.16 | The system shall support the browsing of a static data table and the display of descriptive information during the entry of findings or test information. | |||
| 5.7.17 | The system shall provide a list from which a finding, conclusion, test, or result comment may be selected, with the ability to override the predefined list. | |||
| 5.7.18 | The system shall maintain the entry of a retest result and include both the original and retest results. | |||
| 5.7.19 | The system shall provide information for tests that will not be completed. | |||
| 5.7.20 | The system shall support the attachment of a file to a case test. | |||
| 5.7.21 | The system shall support different instrument interface modes. | The system shall support the manual and automatic import of test results. | ||
| 5.7.22 | The system shall support the import of test results via a direct connection. | |||
| 5.7.23 | The system shall support the import of test results via a file intermediate. | |||
| 5.7.24 | The system shall support importing of test results. | |||
| 5.7.25 | The system shall support a bidirectional download of worklists and import of test results. | |||
| 5.7.26 | The system shall provide a mechanism to track the import of test results. | |||
| 5.7.27 | The system shall provide a mechanism to manage findings and test result import problems. | The system shall detect and process errors that are encountered during the import of test results. | ||
| 5.7.28 | The system shall provide a contingency plan for a failed import. | |||
| 5.7.29 | The system shall support the review of a finding or test. | The system shall enforce peer review of a test. | ||
| 5.7.30 | The system shall prohibit the review of a test prior to the entry of all its results. | |||
| 5.7.31 | The system shall provide a mechanism to contact the evidence/sample owner during review of a test. | |||
| 5.7.32 | The system shall provide the ability to re-release single or multiple test results. | |||
| 5.7.33 | System shall provide the capability to automatically generate and send laboratory reports as an attachment in email via the CBP mail system (Exchange, or current system). | |||
| 5.7.34 | The system shall the ability to review all tasks, mark each task complete, and publish final results. | Shall have the ability for work requests to be reviewed, usually by taking advantage of a summary report. This must be used as the lab review step. The requirement to review a submission/work request must be specified by the work request template and shall obtain an electronic signature from the reviewer. | ||
| 5.7.35 | Shall have the ability for work requests for the approver, usually by taking advantage of an approval report. This must be used as the QA approval step. The requirement to review a work request must be specified by the work request template and shall obtain an electronic signature from the approver. | |||
| 5.7.36 | Shall have the ability to publish (release/transmittal) of work requests occurs as part of the approval step or as a separate step. Reports shall be automatically distributed through export functionality of the Solution to a User based folder for display. | |||
| 5.7.37 | Shall have the ability to identify cases hitting milestones in workflow (ready to write, ready to technically review) in dashboard. | |||
| 5.7.38 | Shall have ability to identify service testing/sampling assignment, progress, completion, and review. Provide real-time tracking of milestones. | |||
| 5.7.39 | The system shall allow for batch processing. | Shall have the ability for tests/analyses be grouped by for method-based batches or runs to obtain efficiencies in all operations, including prepping, running analysis, data entry, and approvals, and QC testing. | ||
| 5.7.40 | Shall have ability to collect test into uniquely identified batches or runs for barcoding or filters and test conditions. | |||
| 5.7.41 | The system shall have the capability to calculate case data. | Shall have the ability for due dates for work requests calculated based on a combination of turn-around commitments, sequencing of tasks, sample shelf lives before prep and analysis, etc. and must take into account operations with different activity schedules. For example, analyzers can often run 24/7, whereas personnel work 8/5. | ||
| Shall have the ability to test backlog report for lab group, analyst, test, due date, priority, instrument, etc. | ||||
| 5.7.42 | The system shall have the ability to add values. | Shall have the ability to enter all values by any of the methods described below. | ||
| 5.7.43 | The system shall track legality of data entry. | Legality of entry by operator privileges, by status of test/aliquot/sample and by kind of value. | ||
| Legality of data entry format according to pre-specified data types and formats for integer, fixed decimal, precision, scientific notation, date time, elapsed time, text, text in a dataset, numeric with text overrides, use of symbols such as <,>, etc., capture of files and long text paragraphs. | ||||
| Checking against method-based limits such as upper decision limit (UDL), lower decision limit (LDL), etc. | ||||
| Checking against specs at the product, product-customer, product- quality- code, etc. | ||||
| 5.7.44 | Automatically check and flag spelling/grammar with the dictionary based on LSS data context. |
DRAFT
5.8 Labeling-Barcode
| 5.8 | Labeling (Barcode/RFID/OQ) Requirements | |||
| Number | Requirement | Detailed Description | Implementation Strategy (select appropriate strategy from drop down list) | Customization Complexity (select appropriate complexity from drop down list) |
| 5.8.1 | The system shall provide custom labels. | The system shall provide custom labels including, but not limited to: | ||
| • Evidence/Sample Labels | ||||
| • Instrument Labels | ||||
| • Consumable Labels | ||||
| • Unique case number labels | ||||
| 5.8.2 | The system shall support label information in human readable, 2D barcode, QR code, and radiofrequency identification format. | |||
| 5.8.3 | The system shall support the creation of labels of varied sizes and shapes including, but not limited to the American Barcode 0.5” x 1” roll labels | |||
| 5.8.4 | The system shall support label printing. | The system shall support automatic label generation of a default quantity on a predefined label printer and format. | ||
| 5.8.5 | The system shall support manual label generation with a prompt for quantity and label printer. | |||
| 5.8.6 | Print barcode labels for the overall case, test request and/or for the items/containers as they are pre-logged. | |||
| 5.8.7 | Allow users to configure barcode label formats and be flexible to include additional information. | |||
| 5.8.9 | Generate unique and random barcode labels. | |||
| 5.8.10 | Register/link the barcodes to any test request and/or items/containers. | |||
| 5.8.11 | Not permit the same barcode to be registered/linked/used for more than one item. | |||
| 5.8.12 | Include the ability to print labels on barcode network printers. | |||
| 5.8.13 | Shall have the ability to provide optimal management of shipments by tracking of shipments and produces paperwork such as shipping labels and COC. It shall include multiple modes of operation in which individual items generate the barcoded, for all items available for a particular destination, with subsequent validation. | |||
| 5.8.14 | The system shall have the ability to track shipments. | Shall have the ability to track shipments and produce paperwork such as shipping labels and COC. It includes multiple modes of operation in which individual items may be barcoded into a shipment, or all items available for a particular destination, with subsequent validation. This ensures optimal management of shipments so as not to miss items. | ||
| 5.8.15 | The solution shall include Barcode hardware | The offer shall include four hundred (400) compatible/integrated handheld barcode scanners (one for each user). | ||
| The offer shall include seventy (70) compatible/integrated barcode printers | ||||
| The offer shall include High-capacity barcode labels for each printer |
DRAFT
5.9 Storage Management
| 5.9 | Storage Management Requirements | |||
| Number | Requirement | Detailed Description | Implementation Strategy (select appropriate strategy from drop down list) | Customization Complexity (select appropriate complexity from drop down list) |
| 5.9.1 | The system shall support the management of storage locations. | The system shall support the use of single level storage locations (for example: Vaults, safes, secure rooms, freezers, other customized locations descriptors, etc.). | ||
| 5.9.2 | The system shall support the use of multi-level storage locations(for example: Vaults, safes, secure rooms, freezers, other customized locations descriptors, etc.). | |||
| 5.9.3 | The system shall maintain an inventory for each storage location (for example: Vaults, safes, secure rooms, freezers, other customized locations descriptors, etc.). | |||
| 5.9.4 | The system shall have the ability to enter, track, inventory, dispose of laboratory supplies, as well as create notifications for purchases. | Shall have the ability for inventory module that provides report on inventory management of any stored item, from expendables, to reagents, to samples, including complete life cycle and inventory quantity management, warnings for expiration or low or high quantities, support for ELN functionality as integrated with reagent, standards, and sample prep, etc. Product expiration is calculated from manufacturing expiration, shelf life, open shelf life, freeze/thaw cycles, temperature excursions and/or shelf life of component reagents. | ||
| 5.9.5 | Shall have the ability for standard inventory supports tracking and management of lab standards purchase, creation from other reagents, dilutions, storage and retrieval, usage, expiration, lot numbers, properties, SOP document management, and calculations associated with operations performed and QC statistics. | |||
| 5.9.6 | Shall support creation and use of blanks, duplicates, spikes, calibrations, internal standards, surrogates, etc. and their incorporation into batches and aliquots. | |||
| 5.9.7 | The Solution shall have the ability to define storage conditions and locations for the inventory of stored items. | |||
| 5.9.8 | Storage location indicator must be entered for all items and sub-items. The Inventory module shall allow for tracking and storage of items in hierarchical storerooms, freezers, box, slot, sub-slots, etc., including tracking of conditions, locations, check in/check out, COC, storage rules, disposal, etc. | |||
| 5.9.9 | The inventory module shall have the ability to generate reports that includes the location of samples, calculate the number of days the sample has been in that storage location. Item management will ideally include the ability to detect/report on the time that an item resides in a specific storage location. | |||
| 5.9.10 | Shall have the ability for item and sub-item disposal with special provisions for hazardous materials to be managed at the sample level with available schedules and reports. | |||
| 5.9.11 | Shall have the ability to complete ELN for managing and use of reagents. | |||
| 5.9.12 | Shall have the ability for inventory support tracking and management of reagent purchase, creation from other reagents, storage and retrieval, quarantine, testing, usage, expiration using multiple criteria including expiration of ingredients, lot numbers, properties, standard operating procedures (SOP) document management, inventory quantity enforcements with notification, and comprehensive calculations associated with operations performed. | |||
| 5.9.13 | Inventory shall allow for tracking and storage of samples in hierarchical storerooms, freezers, box, slot, sub-slot, etc., including tracking of conditions, locations, check in/check out, freeze/thaw cycles, COC, storage rules, disposal, safety, etc. | |||
| 5.9.14 | Inventory shall allow recording of QA testing results for each reagent (pass or fail) based on a reviewer’s evaluation which shall notify the previous owners of the reagent and any other Users as specified by the reviewer. | |||
| 5.9.15 | Inventory shall notify select individuals or a group of individuals set by a User when current stock of reagents reaches a specified threshold number set by a User. |
DRAFT
5.10 Infrastructure-Support
| 5.10 | Infrastructure and Support Requirements | |||
| Number | Requirement | Detailed Description | Implementation Strategy (select appropriate strategy from drop down list) | Customization Complexity (select appropriate complexity from drop down list) |
| 5.10.1 | The contractor shall provide information on supported infrastructure solutions. | Is an on-site infrastructure solution supported? | ||
| 5.10.2 | If yes, the contractor will provide information on the following components for an on-site infrastructure solution, including the version required for proper execution and support of their product:- Established database platforms |
- Minimum requirements for clients and servers
- Web client interface
- Browsers
| 5.10.3 | The system’s on-site infrastructure components, if any, shall reside in a central location. (Do not use on-prem) | |
| 5.10.4 | Is a cloud hosted infrastructure solution supported? | |
| 5.10.5 | If yes, the contractor will provide information on a cloud hosted infrastructure solution. | |
| 5.10.6 | Is a contractor managed infrastructure solution supported? | |
| 5.10.7 | If yes, the contractor will provide information on a contractor managed infrastructure solution. | |
| 5.10.8 | Is a third-party infrastructure solution supported? | |
| 5.10.9 | If yes, the contractor will provide information on a third-party managed infrastructure solution. | |
| 5.10.10 | The contractor will provide advantages and disadvantages of each supported infrastructure solution with a concrete recommendation on how to proceed. | |
| 5.10.11 | The system shall support unique operating environments. | Does the system support the following unique operating environments? |
| 5.10.12 | The system shall meet CBP operating criteria. | The contractor will provide a list of supported non-proprietary database platforms. |
| 5.10.13 | Does the system support the use of a TCP/IP application programming interface? | |
| 5.10.14 | Does the system support the use of open-source language(s) for development? | |
| 5.10.15 | Does the system support the use of GIT software for tracking files during software development? | |
| 5.10.16 | If the system is Software as a Service, is it FedRamp compliant? | |
| 5.10.17 | Is the system compliant with Section 508 of the Rehabilitation Act (classified to 29 U.S.C. § 794d).? | |
| 5.10.18 | Does the system support Zero Trust principles? | |
| 5.10.1 | The contractor shall provide information on supported infrastructure solutions. | Is an on-site infrastructure solution supported? |
| 5.10.2 | If yes, the contractor will provide information on the following components for an on-site infrastructure solution, including the version required for proper execution and support of their product: | |
| - Established database platforms | ||
| - Minimum requirements for clients and servers | ||
| - Web client interface | ||
| - Browsers | ||
| 5.10.3 | The system’s on-site infrastructure components, if any, shall reside in a central location. (Do not use on-prem) | |
| 5.10.4 | Is a cloud hosted infrastructure solution supported? | |
| 5.10.5 | If yes, the contractor will provide information on a cloud hosted infrastructure solution. | |
| 5.10.6 | Is a contractor managed infrastructure solution supported? | |
| 5.10.7 | If yes, the contractor will provide information on a contractor managed infrastructure solution. | |
| 5.10.8 | Is a third-party infrastructure solution supported? | |
| 5.10.9 | If yes, the contractor will provide information on a third-party managed infrastructure solution. | |
| 5.10.10 | The contractor will provide advantages and disadvantages of each supported infrastructure solution with a concrete recommendation on how to proceed. | |
| 5.10.11 | The system shall support unique operating environments. | Does the system support the following unique operating environments? |
| - Development | ||
| - Training | ||
| - SAT | ||
| - Production | ||
| 5.10.12 | The system shall meet CBP operating criteria. | The contractor will provide a list of supported non-proprietary database platforms. |
| 5.10.13 | Does the system support the use of a TCP/IP application programming interface? | |
| 5.10.14 | Does the system support the use of open-source language(s) for development? | |
| 5.10.15 | Does the system support the use of GIT software for tracking files during software development? | |
| 5.10.16 | If the system is Software as a Service, is it FedRamp compliant? | |
| 5.10.17 | Is the system compliant with Section 508 of the Rehabilitation Act (classified to 29 U.S.C. § 794d).? | |
| 5.10.18 | Does the system support Zero Trust principles? | |
| 5.10.19 | The system’s infrastructure shall be secure and supported. | The contractor will provide information on how a service agreement will establish application support terms including responsibilities, response times, upgrades, patches, release notes and technical support services. (A service agreement shall also exist with internal IT.) |
| 5.10.20 | The contractor shall offer LIMS training courses. | The contractor will provide a listing of training courses, including, but not limited to: |
| · System Administration and Maintenance (30 admin users) | ||
| · System User Operation (400 users) | ||
| 5.10.21 | The contractor will provide onsite training at LSS locations for all user levels and functional areas. | |
| 5.10.22 | The contractor will provide user training guides and material for all user levels for each module with unlimited reproduction rights. | |
| Shall have the ability to access the guides to provide assistance through the submission process. | ||
| 5.10.23 | The contractor shall provide product development, release, change and support Standard Operating Procedures. | The contractor will provide the following information: |
| - Standard Operating Procedures for software development, testing, validation and release | ||
| · Standard Operating Procedures for change management | ||
| · Standard Operating Procedures for customer support.· Evidence of adherence to the above Standard Operating Procedures | ||
| 5.10.24 | The contractor shall provide cost and timing estimates. | The contractor will provide a cost estimate that includes but is not limited to: |
| · Initial LIMS purchase with software license fees for 300 simultaneous users | ||
| · Implementation, configuration and customization of the system | ||
| · Development of design and configuration specification documents | ||
| · Installation of the development environment | ||
| · Installation of the validation environment, including Installation Qualification Protocol | ||
| and test script development and execution | ||
| · Installation of the production environment, including Installation Qualification Protocol and test script development and execution | ||
| 5.10.25 | The contractor will provide a typical implementation schedule with milestones, deliverables and durations. | |
| 5.10.26 | The system shall display system and session information. | The system shall display the currently installed software version |
| 5.10.27 | The system shall display the user account that is currently logged in. | |
| 5.10.28 | The system shall provide an online help facility. | |
| 5.10.29 | The system shall present user functions via a dashboard display. | |
| 5.10.30 | The Forensic LIMS shall run on CBP-provided end user laptop computers. | |
| 5.10.31 | The system shall support compliance requirements | The system shall ensure the application is in compliance with all policy, standards, and guidelines as they apply to the Federal Information Security Modernization Act of 2014 (FISMA); the National Institute of Standards and Technology (NIST) and related special publications covering information and system security including the Federal Information Processing Standard (FIPS); the DHS 4300A Sensitive Systems Policy directive; and, security control requirements (to include configuration baseline guides, system security hardening guidance, and DHS Security Policy, Procedures, and Architectural guidance). |
| 5.10.32 | The system shall support file attachments. | System shall be able to support multiple file attachments at a time and have the capability to select multiple files to upload or drag and drop functionality. |
| 5.10.33 | System should also be able to accommodate file extensions (inclusive to, but not limited to, all software/systems mentioned in this document) with no upload size limitations. | |
| 5.10.34 | The system shall support mobile operations. | Option to have a mobile capability (e.g., application) accessible via a mobile device (phone, tablet) as well as an offline option for users with limited connectivity deployable to IOS and Android devices and follow Section 508 Accessibility policies. |
| 5.10.35 | The system shall be capable of interfacing with information technology and subsystems. | The system shall support the interface and ability to push and/or pull information with and not limited to the following systems: |
| CBP External Collaboration Portal | ||
| LSS LIMS System (currently that are stored in Cobol using CA Datacom and in Oracle Exadata database) | ||
| ACE 2.0 | ||
| PRIDE | ||
| ATS | ||
| SeaCATS | ||
| Imaging Modules (e.g., Mideo Caseworks), Ideagen/Qualtrax, ArcGIS, Tableau, through the database and software user interface. | ||
| Windows, current version | ||
| Windows Server, current version | ||
| AWS cloud solutions | ||
| Web browsers (min. supported versions) | ||
| a. Microsoft Edge, current version | ||
| b. Mozilla – Firefox, current version | ||
| c. Google Chrome, current version | ||
| Database Servers (min. supported versions) | ||
| a. MS SQL Server 2019 and above | ||
| b. Oracle 12C and above |
This is the start of the file's text. The full file is on GovTribe.
File details come from the government source that posted it. Updated .