34938_Attachment A_v2.xlsx
XLSX spreadsheet 24 KB Posted
- Solicitation number
- S-73000-00000088
- Issued by
- Oregon
About this file
This is an Attachment A System Features/Functionality Checklist related to a Request for Qualification (RFQ) issued by the Oregon Department of Transportation (ODOT). The document outlines ODOT's requirements for a public records request management solution, including the ability to track various types of public records requests, fees, and services; generate and print rejection letters; process batch receipts; archive redacted records; integrate with Microsoft Outlook; and provide public access to previously requested records without requiring registration or payment. The solution must also include account management features such as the ability to allow requesters to create accounts, track request status, grant fee waivers, and calculate fees. Additionally, the solution must have robust search, reporting, security, and payment processing capabilities.
The checklist indicates that the solution must be web-based, secure, and compliant with HIPAA and CJIS standards. It must also provide a public portal for submitting requests and making payments, as well as an internal portal for ODOT staff. The solution must be cloud-based and offer concurrent licensing, with integration to ODOT's Active Directory for user authentication.
View the file
Other files
| File | Type | Posted |
|---|---|---|
| 34938_RFQ.doc | DOC document | |
| RFPAttF.doc | DOC document |
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
| Following is a list of ODOT’s requirements for the Solution. Offerors shall indicate compliance with each requirement using the methodology as follows: |
| “Y” for “Yes”, fully complies with specification requirement. |
| “N” for “No”, does not comply with specification requirement. |
| “P” for “Partial”, complies with some aspects of the specification requirement. |
| “D” for “Development”, currently in the development stage. |
| For a Yes, or Partial answer in the Comply column, Offerors shall provide an explanation in the Offer submittal column as to how their solution will meet this requirement or where the explanation can be found |
| in your Offer submittal. |
| For a Development answer in the Comply column, Offerors shall provide an explanation in the Detailed Explanation/Packet Reference column as to when and how their solution will meet this requirement |
| or where the explanation can be found in your Offer submittal. |
| In the Customizable column, indicate Yes, No, or Not Applicable. Also identify any functionality that is available at an additional cost |
| Offerors must provide detailed explanations as provided in the Details tab of this Attachment as necessary to provide a fuller explanation of their response to items, denoting by item number to which they are referring. |
Checklist
| Comply Y/N/P/D | Customizable Y/N/NA | ||
| 1 | Document Request Management | ||
| 1.1 | Track a variety of public records requests, fees, and services, including: Dispatch Center tapes, audio tapes, incident reports, photos, records check letters (DMV only) | ||
| 1.2 | Track public record requests and other department services whether or not a fee was assigned and/or collected. | ||
| 1.3 | Generate and print rejection letters if a request is denied, which would include a selection of ORS exemptions to choose from. | ||
| 1.4 | Ability to process batch receipts for multiple requests received from the same requestor within a specified time period. | ||
| 1.5 | Ability to log all activity on request, including if/when any communication occurred, any documents/letters that were generated, or a request and data/information provided was viewed by requestor, staff or public (if appropriate). | ||
| 1.6 | Ability to process and store large files, including a variety of standard media formats, including but not limited to images, audio, and video. Please specify any limits on file size | ||
| 1.7 | Redaction tool with ability to archive redacted records. | ||
| 1.8 | Compatible with Microsoft products, specifically Outlook to allow inclusion of emails in account record. | ||
| 1.9 | Retention of any correspondence generated via inside the system or outside the system. | ||
| 1.10 | Ability to optionally provide public access to previously requested records without requiring registration or payment. | ||
| 1.11 | Ability to drag and drop files, et al. |
| 2 | Account Management |
| 2.1 | Ability to allow for the public to create requester accounts (for repeat requesters) and pre-fill requestor information if they are a returning customer. |
| 2.2 | Ability to track the status of the request (approved, denied, pending) via an external customer web portal. |
| 2.3 | Ability to grant fee waivers for certain types of requester accounts or specific requester accounts, such as media, government institutions, etc. |
| 2.4 | Allow internal staff to view history of request (who entered it, when it was created or updated and what has been modified). |
| 2.5 | Ability to copy information from a previous request to a new request (record). |
| 2.6 | Ability to track time spent on requests and auto calculate cost. |
| 2.7 | Ability to track payments for requests and be able to see past account payments. |
| 2.8 | Ability to calculate fees by both a flat fee cost and a per page cost. |
| 2.9 | Allow deposits to be charged for requests. |
| 2.10 | Ability to track departmental budget cost-centers for request types. |
| 2.11 | Ability to batch payments to pay for multiple requests with a single check or credit card or a combination of both. |
| 2.12 | Ability to account for all receipt numbers. |
| 2.13 | Ability to lock requests down after the total has been paid so no changes can be made to the totals. |
| 2.14 | Ability to account for all invoice numbers. |
| 2.15 | Ability to prevent users from changing invoice after it has been generated (an invoice can be voided and reissued but never modified). |
| 2.16 | Ability to track days since invoice was issued. Requests are closed after 60 days if payment hasn't been received. |
| 2.17 | Ability to generate unique customer/tracking identifier for each request received, possibly with a name/number combination. |
| 2.18 | Ability to add public notes (for view by requester) to request regarding status. |
| 2.19 | Ability to add private notes (for view by City staff) to request. |
| 2.20 | Ability to create accounts for requestors who fill out a paper form and mail it in. |
| 2.21 | Automated and customizable customer relations management updates sent to requester (request received, request assigned, request ready, etc.). |
| 2.22 | Ability to enforce payment of any outstanding fees prior to requester being able to retrieve requested information. |
| 2.23 | Ability to setup a request process workflow (by request type), including the ability to identify any approvals that a request type may require. |
| 2.24 | Ability to customize web online public records request portal with ODOT-specific branding elements (logo, header, footer, color scheme, etc). |
| 3 | Search Features |
| 3.1 | Ability for internal staff to search by any field. |
| 3.2 | Ability for internal staff to search by any field plus employee who processed the request and department that processed the request. |
| 3.3 | Ability for internal staff and the public to search document (records) content and any associated meta data. |
| 4 | Reporting |
| 4.1 | Ability to produce secure online delivery of reports to requestor. |
| 4.2 | Built in reports to provide ability to obtain a variety of statistics and data. |
| 4.3 | Easily export statistical data to standard formats such as Excel or CSV. |
| 4.4 | Ability to run on demand or ad hoc queries or reports for a variety of requests, requestors, payments, and request performance data. |
| 4.5 | Ability for employees to report time spent on request. |
| 5 | Additional Features |
| 5.1 | Web based online records request system that is secure meets HIPAA requirements. |
| 5.2 | Ability to mark certain requests and the data/information delivered as available on demand for the public to access. |
| 5.3 | Provide a portal to the public to accept online payments via credit card transactions. |
| 5.4 | Built in online payments processing capability and integration with ODOT's bank of choice or other leading payment processors doing business in Oregon. |
| 5.5 | Application programming interface (API) to allow for staff development of custom interfaces to or from public records request application. |
| 5.6 | Role based security structure, with functions and application permissions limited by role. |
| 5.7 | User account and role security integration with Active Directory. |
| 5.8 | Multi-factor (two factor) account authentication in order to access the public records request solution by staff. |
| 5.9 | Cloud based, software as a service, hosting model that is secure and CJIS and HIPAA compliant. |
| 5.10 | Concurrent licensing. |
| 5.11 | Web-based public portal solution is ADA 503 compliant and mobile friendly (responsive design). |
| 5.12 | Web-based employee internal portal solution is ADA 503 compliant and mobile friendly (responsive design). |
RFQ 34826 Attachment A: SYSTEM FEATURES/FUNCTIONALITY CHECKLIST
Details
| Checklist No. | Detailed Explanation | Included in Offer? (Y/N) | Page No. |
| Ex: 1.1 | Answer goes here | Y | 6 |
File details come from the government source that posted it. Updated .