Exhibit_A_Functional_non-functional_workbook_RFP.xlsx
XLSX spreadsheet 48 KB Posted
- Attached to
- Request For Proposal 2025-002 for LIMSR solution
- Solicitation number
- 0000037775
- Issued by
- California
About this file
This is a Functional, Non-Functional, and Transition Requirements Workbook for a Laboratory Information Management System (LIMS) RFP, submitted as part of a state and local contract opportunity for what appears to be a cannabis testing laboratory operated by California's Department of Cannabis Control (DCC). The workbook establishes 110 total requirements that bidders must address in their proposals: 110 functional and non-functional requirements designed to support comprehensive laboratory operations including login and access management, sample receiving, sample preparation, sample analysis, reporting, and integration with external systems such as METRC and seed-to-sale tracking platforms. Of these requirements, 74 are classified as Mandatory Scored (MS), indicating that failure to meet them results in bid disqualification; 28 are classified as Mandatory (M), also requiring fulfillment for responsive bids; and 8 are classified as Desirable Scored (DS) or Desirable (D), which are optional. Bidders must complete the workbook by indicating whether each requirement is met (Y/N) and selecting one of four response codes: Out of the Box (10 points), Minor Configuration (6 points), Major Configuration or Third Party Modules (3 points), or Customization (1 point).
The requirements workbook emphasizes compliance with multiple regulatory standards including ISO 17025, CLIA, CAP, FDA, and California Government Code accessibility requirements, along with comprehensive security and data management protocols. Non-functional requirements include mandatory cloud-based SaaS deployment with no on-premise hardware, HTTPS/TLS 1.2 encryption, comprehensive audit logging, role-based access control, scalability for unlimited users and data storage, and mobile compatibility with iOS and Android platforms. The system must support electronic signatures, automated alerts for expiry dates and quality control failures, real-time sample tracking, chain-of-custody documentation, and integration capabilities with laboratory instruments including LC-MS/MS, GC-MS, ICP-MS, and qPCR. Specific attention is given to quality assurance and quality control functionality, including Westgard rules implementation, statistical process control, and generation of audit-ready reports for regulatory compliance and investigational purposes.
View the file
Other files
| File | Type | Posted |
|---|---|---|
| LIMS_2.0.pdf | ||
| 7._eVAQ-Manual_for_Vendors.pdf | ||
| Part_2_Attachments_and_Exhibits.zip | ZIP file | |
| Exhibit_B_Workflow_Business_Process.pdf | ||
| Exhibit_D_-_Cost_Workbook_DCC_LIMS.xlsx | XLSX spreadsheet |
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
Instructions
| PROJECT FUNCTIONAL, NON-FUNCTIONAL AND TRANSITION REQUIREMENTS |
| This workbook must be completed by the Bidder and submitted as part of their responsive bid. |
| The requirements are presented in the following columns. |
| Req # |
| The unique ID number associated with each requirement. |
| Main Business Capability/Function |
| The main process applicable to the requirement. |
| Sub Business Capability/Function |
| The sub process applicable to the requirement. |
| Process |
| The process applicable to the requirement. |
| Requirement |
| The text of the actual Functional or Non-Functional Requirement |
| Type |
| The requirement type, as follows: |
| MS - Mandatory Scored; fulfillment of requirement must be included in a responsive Bid. If the requirement cannot be met, the Bidder is disqualified. |
| M - Mandatory; fulfillment of requirement must be included in a responsive Bid. If the requirement cannot be met, the Bidder is disqualified. |
| DS - Desirable Scored; fulfillment of requirement is not required to be included in a responsive Bid.The Bidder may choose whether to meet requirements labeled as (DS). |
| D - Desirable; fulfillment of requirement is not required to be included in a responsive Bid. |
| Bidder Response |
| In order for their proposal to be considered responsive, the Bidder must complete all sections below, for the Functional Business Needs worksheet, for every requirement listed. |
| Met (Y/N) |
| Record either “Y” or “N” in this column, indicating that the Bid includes satisfaction of the requirement. Note: any Bid which does not include a "Y" after every Mandatory requirement will be considered non-responsive, not eligible for evaluation, and disqualified from the bidding process. Any Bid which does not include a "Y" after every Desireable requirement will not disqualify the Bid. |
| Response Codes |
| Bidder must choose one, and only one, Response Code for all applicable requirements. Failure to respond to all requirements may result in disqualification of the proposal. Bidder must enter an "1" in the appropriate column; only one column may contain a response |
| Out of the Box - Definition |
| Enter an "1" in this cell if the requirement can be met in its baseline form without, minor or major configuration, customizations or additional software or processes of any kind. Requirement is met “out of the box” would indicate that the system patches or upgrades would not require reconfiguration. Out of the Box receives 10 points. |
| Minor Configuration Required |
| Enter an "1" in this cell if the requirement represents functionality that can be achieved via standard configuration of an existing Bidder component or system. Examples of minor configuration is the flexibility to add fields, change field names, define field parameters. Minor modification requires 16 hours or less to complete. Minor Configuration receives 6 points. |
| Major Configuration Required or Third Party Modules or Tools |
| Enter an "1" in this cell if the requirement represents functionality which must be achieved via additional Major Configuration of any component or system. The requirement can be met, but requires integrator staff who are skilled and knowledgeable of the process. Major configuration requires 16-40 hours to complete. Major Configuration receives 3 points. |
| Customization |
| Enter an "1" in this cell if the requirement can be met with code changes that create functionality that is not available through configuration. If the requirement is met through customization the change must not impact future system upgrades. Customization is more than 40 hours to complete and must be completed before system acceptance is approved. Customization receives 1 points. |
| Scoring |
| Awarded Points |
| The number of points awarded, based on Bidder response. |
| Mandatory Scored and Desirable Scored Requirements |
| For MS requirements the following scoring is applied: |
| Out of the Box (Demonstration) = 10 points |
| Minor Configuration = 6 points |
| Major Configuration/Third party software = 3 points |
| Customization = 1 points |
| Maximum Available Points |
| This column is pre-calculated. Do not enter anything in this column. The total number of possible points available for the requirement. |
Functional Requirements
| Project Functional Requirements | |||||||||||
| <Enter Bidder Name> | Response Codes | ||||||||||
| (See Instructions Tab for Definitions) | Y | 1 | |||||||||
| Bidder Response | 10 | 6 | 3 | 1 | N | ||||||
| Req # | Main Business Capability/Function | Workflow Specification # | Requirement | Type | Met | ||||||
| (Y/N) | Out of the Box | Minor Configuration | |||||||||
| (16 hours or less) | Major Configuration |
(16 - 40 Hours)
| or Third Party Tools | Customization | |
| (More than 40 Hours) | Awarded Points | Maximum Available |
Points
| 1 | LIMS Login Access/Dashboard | 1 | The system shall allow admininstrators to assign and manage roles with permissions. | Mandatory Scored | 0 | 10 |
| 2 | LIMS Login Access/Dashboard | 1 | The system shall allow a user to resume session after auto log-off upon re-authentication. | Desirable Scored | 0 | 10 |
| 3 | LIMS Login Access/Dashboard | 1 | The system shall allow remote access to workstation. | Desirable Scored | 0 | 10 |
| 4 | LIMS Login Access/Dashboard | 1 | That system shall provide an audit trail, including who, when, where, and what was accessed. | Mandatory Scored | 0 | 10 |
| 5 | LIMS Login Access/Dashboard | 1 | The system shall require external users to log in with username/password. | Mandatory Scored | 0 | 10 |
| 6 | LIMS Login Access/Dashboard | 1 | The system shall track extrenal password changes and enforce periodic reset. | Mandatory Scored | 0 | 10 |
| 7 | LIMS Login Access/Dashboard | 1 | That system shall lock external account after set number of failed login attempts. | Mandatory Scored | 0 | 10 |
| 8 | LIMS Login Access/Dashboard | 1 | The system shall allow reset of usernames and passwords. | Mandatory Scored | 0 | 10 |
| 9 | LIMS Login Access/Dashboard | 1 | The system shall provide role-based access control, allowing administrators to define user rights and privileges by user type, including the ability to restrict or permit dataset updates, additions, deletions, edits, and read-only access. | Mandatory Scored | 0 | 10 |
| 10 | LIMS Login Access/Dashboard | 1 | The system shall lock records after creation and unlocked by appropriate user permission settings. | Mandatory Scored | 0 | 10 |
| 11 | LIMS Login Access/Dashboard | 1 | The system shall allow a user to access functions from any workstation. | Desirable Scored | 0 | 10 |
| 12 | LIMS Login Access/Dashboard | 1 | The system shall allow a user to access screens via menus and icons. | Mandatory Scored | 0 | 10 |
| 13 | LIMS Login Access/Dashboard | 1 | The system shall allow a user easy navigation between screens. | Mandatory Scored | 0 | 10 |
| 14 | LIMS Login Access/Dashboard | 1 | The system shall provide configuration screens for administrators to update values. | Mandatory Scored | 0 | 10 |
| 15 | LIMS Login Access/Dashboard | 1 | The system shall track instrument PM/Calibration logs and alert when due. | Desirable Scored | 0 | 10 |
| 16 | LIMS Login Access/Dashboard | 1 | The system shall provide Proficiency Test (PT) and Competency Test records tracked within system. | Desirable Scored | 0 | 10 |
| 17 | LIMS Login Access/Dashboard | 1 | The system shall provide full inventory management of reagents, consumables, standards. | Desirable Scored | 0 | 10 |
| 18 | LIMS Login Access/Dashboard | 1 | The system shall provide automated alerts for expiry dates and stock below thresholds. | Desirable Scored | 0 | 10 |
| 19 | LIMS Login Access/Dashboard | 1 | The system shall provide integration with purchase order workflows (PO → Admin → Acquisitions). | Desirable Scored | 0 | 10 |
| 20 | Sample Receiving | 2 | The system shall support electronic test requests in standard formats (e.g., .csv, .xlsx, .doc, .pdf). | Mandatory Scored | 0 | 10 |
| 21 | Sample Receiving | 2 | The system should be able to link electronic requests to delivered samples, using barcode scanning or other suitable mechanisms to associate samples with their corresponding requests. | Desirable Scored | 0 | 10 |
| 22 | Sample Receiving | 2 | The system shall support instrument-specific datasets for test batches. | Mandatory Scored | 0 | 10 |
| 23 | Sample Receiving | 2 | The system shall handle paper test requests with dual entry verification. | Desirable Scored | 0 | 10 |
| 24 | Sample Receiving | 2 | The system shall support batch entry of multiple requests from same submitter. | Mandatory Scored | 0 | 10 |
| 25 | Sample Receiving | 2 | The system shall record hazard screening before lab receipt. | Desirable Scored | 0 | 10 |
| 26 | Sample Receiving | 2 | The system shall link multiple samples from same individual for same test. | Mandatory Scored | 0 | 10 |
| 27 | Sample Receiving | 2 | The system shall flag sample information problems and notify submitter automatically. | Mandatory Scored | 0 | 10 |
| 28 | Sample Receiving | 2 | The system shall assign unique accession numbers across entire cannabis testing laboratory office. | Mandatory Scored | 0 | 10 |
| 29 | Sample Receiving | 2 | The system shall create sample and barcode labels. | Mandatory Scored | 0 | 10 |
| 30 | Sample Receiving | 2 | The system shall create skeleton test request records if full entry not possible. | Desirable Scored | 0 | 10 |
| 31 | Sample Receiving | 2 | The system shall allow a user the ability to capture chain-of-custody for every sample (who handled it, when, where, how). | Mandatory Scored | 0 | 10 |
| 32 | Sample Receiving | 2 | The system shall provide barcode scanning compatibility with multiple formats (2D, QR, RFID). | Mandatory Scored | 0 | 10 |
| 33 | Sample Receiving | 2 | The system shall automatically reject samples based on user-customized criteria. | Mandatory Scored | 0 | 10 |
| 34 | Sample Receiving | 2 | The system shall allow users to upload sample photos. | Mandatory Scored | 0 | 10 |
| 35 | Sample Receiving | 2 | The system shall keep records of sample receiving and storage informaiton, including temperature, humidity, etc. | Mandatory Scored | 0 | 10 |
| 36 | Sample Preparation | 3 | The system shall support splits and aliquots with post-script numbers. | Mandatory Scored | 0 | 10 |
| 37 | Sample Preparation | 3 | The system shall allow a user to route and track samples to multiple labs. | Mandatory Scored | 0 | 10 |
| 38 | Sample Preparation | 3 | The system shall support shipping to reference labs with documentation. | Mandatory Scored | 0 | 10 |
| 39 | Sample Preparation | 3 | The system shall allow a user the ability to schedule sample prep steps with timestamp and technician ID. | Mandatory Scored | 0 | 10 |
| 40 | Sample Preparation | 3 | The system shall support tracking for multi-step prep (grinding, homogenization, dilution, aliquoting). | Mandatory Scored | 0 | 10 |
| 41 | Sample Preparation | 3 | The system shall support automatic calculation of input mass and dilution factors with traceability. | Mandatory Scored | 0 | 10 |
| 42 | Sample Analysis | 4 | The system must support both manual entry and automatic import of instrument results into the LIMS. | Desirable Scored | 0 | 10 |
| 43 | Sample Analysis | 4 | The system shall allow a user the ability to link analytical methods to SOPs with version control. | Desirable Scored | 0 | 10 |
| 44 | Sample Analysis | 4 | The system shall provide integration with instruments (LC-MS/MS, GC-MS, ICP-MS, qPCR, Sequencers). | Mandatory Scored | 0 | 10 |
| 45 | Sample Analysis | 4 | The system shall support automated import of raw data files and result parsing. | Mandatory Scored | 0 | 10 |
| 46 | Sample Analysis | 4 | The system shall allow users to manage instrument run queues in real time. | Mandatory Scored | 0 | 10 |
| 47 | Sample Analysis | 4 | The system shall support for customized multi-test panels. | Mandatory Scored | 0 | 10 |
| 48 | Reporting | 6 | The system shall generate weekly, monthly, yearly workload reports when required by users. | Desirable Scored | 0 | 10 |
| 49 | Reporting | 6 | The system shall allow a user to generate work time unit reports (labor/laboratory effort). | Desirable Scored | 0 | 10 |
| 50 | Reporting | 6 | The system shall allow a user to generate quality assurance reports (unsatisfactory, rejections). | Mandatory Scored | 0 | 10 |
| 51 | Reporting | 6 | The system shall allow a user to generate turnaround time (TAT) reports. | Desirable Scored | 0 | 10 |
| 52 | Reporting | 6 | The system shall allow a user to generate quality control reports (summaries, exceptions). | Mandatory Scored | 0 | 10 |
| 53 | Reporting | 6 | The system shall allow a user to generate test log reports (pending, reportable test, send-out). | Mandatory Scored | 0 | 10 |
| 54 | Reporting | 6 | The system shall provide a reports menu with standard reports. | Mandatory Scored | 0 | 10 |
| 55 | Reporting | 6 | The system shall schedule reports for off-peak hours. | Desirable Scored | 0 | 10 |
| 56 | Reporting | 6 | The system shall support user-defined query reports. | Mandatory Scored | 0 | 10 |
| 57 | Reporting | 6 | The system shall export data for analysis in standard formats (e.g., .csv, .xlsx, .doc, .pdf). | Mandatory Scored | 0 | 10 |
| 58 | Reporting | 6 | The system shall allow a user to generate reports on QC failures by lab, instrument, or method. | Mandatory Scored | 0 | 10 |
| 59 | Reporting | 6 | The system shall provide configurable Certificate of Analysis (CoA) with lab branding, QR code verification. | Mandatory Scored | 0 | 10 |
| 60 | Reporting | 6 | The system shall provide option to release preliminary reports and mark as Final/Corrected/Amended. | Mandatory Scored | 0 | 10 |
| 61 | Reporting | 6 | The system shall provide automated TAT (Turnaround Time) alerts for overdue samples. | Desirable Scored | 0 | 10 |
| 62 | Reporting | 6 | The system shall provide automatic report delivery to submitter portal + email notifications. | Mandatory Scored | 0 | 10 |
| 63 | Reporting | 6 | The system must allow reporting and generating a Certificate of Analysis (CoA) when only partial samples from a batch are tested or when only a subset of the required tests is completed. | Mandatory Scored | 0 | 10 |
| 64 | Reporting | 6 | The system shall generate audit-ready QC/QA summaries for ISO 17025 compliance. | Desirable Scored | 0 | 10 |
| 65 | Reporting | 6 | The system shall provide ability to generate CAPA (Corrective and Preventive Action) records. | Desirable Scored | 0 | 10 |
| 66 | Reporting | 6 | The system shall track and generate chain-of-custody audit logs for regulators. | Mandatory Scored | 0 | 10 |
| 67 | Reporting | 6 | The system shall allow a user to generate custom regulatory reports (QA/QC, Turnaround Time, Submitter Usage, Rejections). | Mandatory Scored | 0 | 10 |
| 68 | Mulitple | 1,2 | The system shall allow customers an access portal for test requests & barcodes. | Mandatory Scored | 0 | 10 |
| 69 | Mulitple | 1,2 | The system shall provide secure submitter portal for order entry, sample tracking, and report download. | Mandatory Scored | 0 | 10 |
| 70 | Mulitple | 1,2 | The system shall allow submitters can print barcodes/labels before shipping samples. | Desirable Scored | 0 | 10 |
| 71 | Mulitple | 1,2 | The system shall allow ability to batch submit requests (multiple samples with shared metadata). | Mandatory Scored | 0 | 10 |
| 72 | Mulitple | 1,2,3,4,5,6 | The system shall allow a user to QC sample tracking (spikes, duplicates, blanks, controls). | Mandatory Scored | 0 | 10 |
| 73 | Mulitple | 1,2,3,4,5,6 | The system shall allow submitters can view real-time sample status (received, in testing, complete). | Mandatory Scored | 0 | 10 |
| 74 | Mulitple | 1,2,3,4,5,6,7 | The system shall allow a user query/search functionality (elastic, fuzzy, typeahead). | Mandatory Scored | 0 | 10 |
| 75 | Mulitple | 1,2,3,4,5,6,7 | The system shall allow a user to query status of any test request. | Mandatory Scored | 0 | 10 |
| 76 | Mulitple | 1,2,3,4,5,6,7 | The system shall require mandatory fields must be completed before exiting screen. | Mandatory Scored | 0 | 10 |
| 77 | Mulitple | 1,2,3,4,5,6,7 | The system shall support dual entry and verification for critical data. | Mandatory Scored | 0 | 10 |
| 78 | Mulitple | 1,2,3,4,5,6,7 | The system shall validate numeric ranges, dates, alphanumeric fields. | Mandatory Scored | 0 | 10 |
| 79 | Mulitple | 1,2,3,4,5,6,7 | The system shall apply correlation edits between fields. | Desirable Scored | 0 | 10 |
| 80 | Mulitple | 1,2,3,4,5,6,7 | The system shall insert default values (e.g., current date/time). | Mandatory Scored | 0 | 10 |
| 81 | Mulitple | 1,2,3,4,5,6,7 | The system shall distinguish client-ordered versus internal tests. | Mandatory Scored | 0 | 10 |
| 82 | Mulitple | 1,2,3,4,5,6,7 | The system shall provide QC/QA checks with audit trails. | Mandatory Scored | 0 | 10 |
| 83 | Mulitple | 1,2,3,4,5,6,7 | The system shall track QC and QA measures by time/test. | Mandatory Scored | 0 | 10 |
| 84 | Mulitple | 1,2,3,4,5,6,7 | The system shall store SOPs with version control. | Desirable Scored | 0 | 10 |
| 85 | Mulitple | 1,2,3,4,5,6,7 | The system shall require electronic signatures for QC/QA entries. | Mandatory Scored | 0 | 10 |
| 86 | Mulitple | 1,2,3,4,5,6,7 | The system shall allow a user to archive data sets in storage. | Mandatory Scored | 0 | 10 |
| 87 | Mulitple | 1,2,3,4,5,6,7 | The system shall allow a user to retrieve archived data sets. | Mandatory Scored | 0 | 10 |
| 88 | Mulitple | 1,2,3,4,5,6,7 | The system shall allow a user to delete archived data after holding periods. | Mandatory Scored | 0 | 10 |
| 89 | Mulitple | 1,2,3,4,5,6,7 | The system shall allow a user the ability to upload regulatory forms (e.g., CDPH, DCC, ISO) and attach them to sample records. | Mandatory Scored | 0 | 10 |
| 90 | Mulitple | 1,2,3,4,5,6,7 | The system shall provide real-time sample status tracking dashboard (Received → In Prep → In Analysis → Review → Reported). | Mandatory Scored | 0 | 10 |
| 91 | Mulitple | 1,2,3,4,5,6,7 | The system shall provide mobile access. | Mandatory Scored | 0 | 10 |
| 92 | Mulitple | 1,3,4,5,6 | The system shall link reagent lot numbers directly to test results for traceability. | Desirable Scored | 0 | 10 |
| 93 | Mulitple | 1,6 | The system shall allow customers to access limited read-only data. | Mandatory Scored | 0 | 10 |
| 94 | Mulitple | 1,6 | The system shall provide data analytics dashboards (e.g., trending pesticide failure rates, aspergillus detection rates). | Mandatory Scored | 0 | 10 |
| 95 | Mulitple | 1,6 | The system shall integrate with METRC and seed-to-sale tracking systems. | Mandatory Scored | 0 | 10 |
| 96 | Mulitple | 2,3,4 | The system shall allow a user to define instrument-specific batches. | Mandatory Scored | 0 | 10 |
| 97 | Mulitple | 3,4,5,6 | The system shall track dilutions and corrected results. | Mandatory Scored | 0 | 10 |
| 98 | Mulitple | 4,5 | The system shall flag and reject batches with QC failures. | Mandatory Scored | 0 | 10 |
| 99 | Mulitple | 4,5,6 | The system shall track standards, controls, duplicates in batch. | Mandatory Scored | 0 | 10 |
| 100 | Mulitple | 4,5,6 | The system shall trigger retests or reruns automatically. | Mandatory Scored | 0 | 10 |
| 101 | Mulitple | 4,5,6 | The system shall link rejected runs to reruns. | Mandatory Scored | 0 | 10 |
| 102 | Mulitple | 4,5,6 | The system shall capture analyst ID, date, and time for results. | Mandatory Scored | 0 | 10 |
| 103 | Mulitple | 4,5,6 | The system shall support complex calculations and highlight positives. | Mandatory Scored | 0 | 10 |
| 104 | Mulitple | 4,5,6 | The system shall generate Levy-Jennings plots, regression, Westgard rules. | Mandatory Scored | 0 | 10 |
| 105 | Mulitple | 4,5,6 | The system shall provide alerts for QC/QA trending toward limits. | Mandatory Scored | 0 | 10 |
| 106 | Mulitple | 4,5,6 | The system shall auto reschedule tests invalidated by QC failure. | Desirable Scored | 0 | 10 |
| 107 | Mulitple | 4,5,6 | The system shall allow a user the option to flag regulatory thresholds exceeded (e.g., pesticides or Aspergillus detection). | Mandatory Scored | 0 | 10 |
| 108 | Mulitple | 4,5,6 | The system should support integration of Westgard rules, or comparable statistical QC approaches, for qPCR and chemistry QC checks | Mandatory Scored | 0 | 10 |
| 109 | Mulitple | 5,6 | The system shall allow a user to peer review and supervisory review with full audit trail. | Mandatory Scored | 0 | 10 |
| 110 | Mulitple | 5,6 | The system shall provide built-in multi-layer review and e-signature approval system. | Mandatory Scored | 0 | 10 |
| 0 | 1,100 |
Non-Functional Requirements
| Project Non-Functional Requirements | ||||||||
| <Enter Bidder Name> | Y | 1 | ||||||
| Bidder Response | N | |||||||
| Req # | Main Business Capability/Function | Sub Business Capability/Function | Business Process | Requirement | Type | Met |
(Y/N)
| 1 | Accessibility | The system shall be compliant with California Government Code Sections 7405 and 1135, and the Web Content Accessibility Guidelines 2.0 or a subsequent version. Also referenced in SaaS General Provisions section 49. | Mandatory |
| 2 | Archiving & Compliance | The system shall support laboratory operations in compliance with ISO, CLIA, CAP, FDA, and DCC requirements. | Mandatory |
| 3 | Database Management | The system shall have user interface and all interactive database management tools shall be simple to use. | Mandatory |
| 4 | Database Management | The system shall be able to import data file(s), convert, and store. | Mandatory |
| 5 | Database Management | The system shall allow data exchange with other database systems. | Desirable |
| 6 | General specifications | The system shall allow data storage for laboratory operations needs. | Mandatory |
| 7 | General specifications | The system shall allow data processing and manipulation for laboratory operations needs. | Mandatory |
| 8 | Interface | The system shall provide a method to uniquely identify each lab instrument. | Mandatory |
| 9 | Interface | The system shall be able to process analytical data from instruments. | Mandatory |
| 10 | Interface | The system shall be able to interface with METRC. | Mandatory |
| 11 | Maintainability | The system shall facilitate the addition of a comprehensive new business rule/workflow , following a complete analysis of the business process lifecycle (lifecycle shall be agreed to by the State). | |
| Desirable | |||
| 12 | Maintainability | The system shall facilitate the modification of an existing business rule/workflow, following a complete analysis of the business process lifecycle (lifecycle shall be agreed to by the State). . | |
| Desirable | |||
| 13 | Monitoring | The system shall provide automated monitoring of jobs and notify users if a job fails. | Mandatory |
| 14 | Non-Security | The system shall follow the OWASP API Top 10. | Mandatory |
| 15 | Non-Security | The system shall follow OWASP REST Security guidance. | Mandatory |
| 16 | Non-Security | The software provider shall ensure encryption of select data at rest is determined by the DCC’s data classification and risk assessment. | Mandatory |
| 17 | Non-Security | The system shall classify data by the data owner based on data type, value, sensitivity, and criticality to the organization. The data classification must comply with DCC ISO. | Mandatory |
| 18 | Non-Security | The system shall be available continuously, except for scheduled maintenance windows. | Mandatory |
| 19 | Non-Security | The system shall provide appropriate warning and error messages displayed to the user that are clear, specific and include suggested next steps (if relevant). | Mandatory |
| 20 | Non-Security | The system shall support API connectivity for third-party software and instruments. | Desirable |
| 21 | Non-Security | The Contractor shall use relevant and secure APIs to faciliate interoperability and real time bi-directional transmission of data between systems of record. | Desirable |
| 22 | Non-Security | The system shall be compatible with iOS and Android. | Mandatory |
| 23 | Non-Security | The system shall replicate to a reporting only database and the reporting only database be capable to integrate with cloud based data warehouse. | Desirable |
| 24 | Scalability | The system shall be scalable to support unlimited growth in the number of internal and external users without degrading established performance requirements, service level agreements or availability. | |
| Mandatory | |||
| 25 | Scalability | The system shall be scalable to support document storage without degrading established performance requirements, service level agreements or availability. | |
| Mandatory | |||
| 26 | Scalability | The system shall be scalable to support record (row data) storage without degrading established performance requirements, service level agreements or availability. | |
| Mandatory | |||
| 27 | Scalability | The system shall be scalable to support data fields (column data) storage without degrading established performance requirements, service level agreements or availability. | |
| Mandatory | |||
| 28 | Scalability | The system shall be scalable to support API consumption without degrading established performance requirements, service level agreements or availability. | |
| Desirable | |||
| 29 | Security | The system provider shall ensure all traffic must be https with minimum of TLS 1.2, and be adaptable to the latest SSL/TLS versions. | |
| Mandatory | |||
| 30 | Security | The system provider shall ensure traffic between DCC and Vendor will be encrypted and digital certificates used to ensure end to end encryption and data is not readable. | |
| Mandatory | |||
| 31 | Security | The system shall ensure all Logs will contain the following information: Date and Time · Initiating Process · Process Owner · Description | |
| Mandatory | |||
| 32 | Security | The system shall log all Authentication and Authorization Events – logging in, logging out, failed logins. These should include date/time, success/failure, resources being authorized, and the user requesting the authorization, if appropriate an IP address or location of the Authentication Attempt | |
| Mandatory | |||
| 33 | Security | The system shall log all Administrator Activity. | Mandatory |
| 34 | Security | The system shall log the deletion of any data | Mandatory |
| 35 | Security | The system shall log any modification to data characteristics: Permissions, Location, Field Type. | |
| Mandatory | |||
| 36 | Security | The system shall ensure no PII in part or in whole will be logged in the application logs. Primary keys or other ways of identifying the entity will be used instead. | |
| Mandatory | |||
| 37 | Security | The system shall ensure all PII will be encrypted at rest unless approved by DCC. | |
| Mandatory | |||
| 38 | Security | The system shall ensure user credentials will only be stored with a one way hash and a random salt. | |
| Mandatory | |||
| 39 | Security | The system shall ensure any communication to or from the system through FTP will be secured through SFTP or FTPS (FTP with TLS encryption). | |
| Mandatory | |||
| 40 | Security | The system shall comply with the State Model: Cloud Computing Services Special Provisions (Infrastructure as a Service and system as a Service) as defined in CDT's Cloud Security Standards SIMM 5315-B or its successor. | |
| Mandatory | |||
| 41 | Security | All PII data stored in or transferred to non-production environments must be obfuscated. | |
| Mandatory | |||
| 42 | Security | The system shall be configured to provide only essential capabilities – unnecessary functions, ports, protocols, and/or services must be blocked. | Mandatory |
| 43 | Security | The software provider shall ensure when an error occurs that causes the program or a part of the program to fail, it is vital that the system will “fail closed,” blocking an unauthorized user from reaching the system without proper authentication. | Mandatory |
| 44 | Security | The software provider shall recover and reconstitute the system to a known state after a disruption, compromise, or failure. | Mandatory |
| 45 | System Configuration | The system shall be entirely cloud-based software as a service and not require any on-premise hardware. | Mandatory |
| 46 | System Management | The system shall provide security features to ensure only authorized users enter, view, and modify data. | Mandatory |
| 47 | System Management | The system shall provide archival of data at the request of the system administrator or automatically after a specified time. | Mandatory |
| 48 | System Management | The system shall enforce data retention policies by automatically archiving or deleting data in accordance with applicable DCC legal, regulatory, and policy requirements. | Mandatory |
| 49 | System Management | The system shall support data storage to allow each user to store an unlimited amount of data without degradation in performance or availability. | Mandatory |
| 50 | User Management | The Contractor shall provide, setup and configure all components of the Single Sign-On functionality, including any VPN tunnels required to secure the communications. | |
| Mandatory | |||
| 51 | User Management | The system shall restrict user logins to specified workstations and control their ability to access the system remotely. | Desirable |
File details come from the government source that posted it. Updated .