Appendix_D_Requirements_Template_Scanning.xlsx
XLSX spreadsheet 49 KB Posted
- Solicitation number
- 2023-RFP-017
- Issued by
- Allegheny County, Philadelphia City, Pennsylvania
About this file
The document is a Technical Requirements Template for Document Scanning Services for the City of Pittsburgh, Pennsylvania, specifically focusing on digitization and indexing of various departmental documents. The project involves scanning and indexing documents from multiple city departments, including Permits, Licenses, and Inspections, and the Department of City Planning, with document types ranging from 5"x8" letter-legal size to oversized documents up to 36"x48". The scanning services require rapid turnaround times, with most document sets needing completion within 3-5 working days, and some urgent requests requiring document return within 2 hours. The vendor must provide comprehensive scanning services, including document preparation, OCR compatibility, indexing, and digital file delivery in formats like PDF/A, JPEG, or TIFF, with image resolutions between 200-4500 ppi depending on document type.
The contract includes detailed technical requirements covering data security, network capabilities, system performance, and integration specifications. Key technical requirements mandate that all cloud-hosted data remain in the continental United States, be encrypted at rest and in transit, and maintain 99.99% system uptime. The City requires full data ownership, API access, and the ability to integrate with existing systems like OnBase, Microsoft Outlook, and ArcGIS. The vendor must provide robust security measures, including annual third-party security assessments, comprehensive audit logging, and compliance with industry standards like ISO/IEC 27001. Pricing will be based on document size and type, with setup fees included, and no additional shipping or handling charges will be reimbursed by the City.
View the file
Other files
| File | Type | Posted |
|---|---|---|
| Digitization_&_Scanning_Of_City_Of_Pittsburgh_Documents_(Addendum_#1_Revision).pdf | ||
| Document_Type_DCP_Z&DR_for_scanning.docx | DOCX document | |
| Document_Type_DOMI_(8).docx | DOCX 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
Technical Requirements
| Requirement ID | Requirements | |
| (All of the items apply to any subcontractors that work on the solution. ) | System Capability | |
| (select from dropdown) | Comments: | |
| Outage and Breach Reporting: | ||
| 1.1 | Provide your outage notication communication | |
| 1.2 | Provides fast detection and root cause diagnosis | |
| 1.3 | The City of Pittsburgh (referred to as City) must be notified in writing within 24 hours of the earliest indication or report of a potential breach or unintended disclosure of Confidential Information (CI) or a System that supports CI. | |
| 1.4 | Response actions to incidents that might affect CI or Systems must be conducted quickly and with ample resources. Vendor will hire a professional third-party incident response team if in-house resources do not have sufficient skill or availability. The Vendor is expected to distribute all incident response evidence, reports, communications and related materials to security@pittsburghpa.gov. The format of incident reports will be agreed upon with the City in advance. | |
| 1.5 | City shall have the right to view all incident response evidence, reports, communications and related materials upon request. | |
| 1.6 | If requested by the City, or if required by law, the Vendor shall notify in writing all persons affected by the incident, at its own cost and expense. | |
| 1.7 | Vendors shall have a comprehensive secure development system in place consistent with industry standard best practices, including policies, training, audits, testing, emergency updates, proactive management, and regular updates to the secure development lifecycle System itself. | |
| 1.8 | Vendors will make updates available to the City in a timely fashion at no additional cost. | |
| 1.9 | The system can provide the ability to track and log system uptime and transaction response times in order to provide information for SLA monitoring | |
| 1.10 | Provides for predictive failures and issue alerting functions | |
| 1.11 | Ability to allow for notification of blackouts | |
| Data and Security: | ||
| 2.1 | All cloud-hosted data must remain in the continental United States. | |
| 2.2 | Ownership of all data remains with the City, at no additional cost. | |
| 2.3 | Data should be encrypted at rest and in transit. | |
| 2.4 | The City shall have the right to view all documentation containing the results of any security audits completed within the last twelve (12) months, including documentation regarding security practices and data classification. | |
| 2.5 | The Vendor shall use commercially reasonable efforts to secure and defend any System housing Confidential Information against third parties. | |
| 2.6 | Vendors that handle Confidential Information must respond to and resolve security-related bug reports, inquiries and incidents in a timely and professional manner. The Vendor must notify the City within 24 hours of when Vendor becomes aware of any such incident that poses a potential risk to City data. The Vendor shall send the notification to security@pittsburghpa.gov | |
| 2.7 | Must follow industry standard password requirements. (Passwords must be stored in non-reversible one-way cryptographic hash) | |
| 2.8 | Log all successful and failed authentication attempts, including date, time, IP address, and username. | |
| 2.9 | Offer a secure password reset feature, including verification of identity, email or text notification. | |
| 2.10 | Temporarily lock accounts with repeated failed login attempts and provide support to affected users. | |
| 2.11 | Ability to provide authentication via generally agreed upon SSO methodologies. | |
| 2.12 | Vendors managing City-owned CI must engage an independent third party annually to assess the practical security of Vendor's Systems. These reviews must include penetration tests from the perspective of an external attacker and an internal user with common privileges. The penetration tests must include all Systems exposed to the internet and any Systems, internal or external, that Handle Confidential Information. Such annual assessment shall be at Vendor’s sole expense. | |
| 2.13 | Audit logs must be implemented for all Systems including those that handle CI. All attempted violations of System security must generate an audit log. Audit logs must be secured against unauthorized access or modification. Electronic logs required | |
| 2.14 | In the event of adverse findings through a City or Vendor audit, the Vendor shall cooperate with the City in remediating any risks to CI, including complying with request to temporarily taking the system offline or otherwise limiting access to the system, and any other follow up actions reasonably necessary to secure the CI. | |
| 2.15 | For the life of the contract, all data should be retained and available upon request from the City, available via API calls. | |
| 2.16 | All metadata, logs, notifications of system outages, etc. should also be retained for the life of the contract. | |
| 2.17 | Vendor Systems that Handle Confidential Information shall be available and fully functional 24x7x365 with 99.99% uptime, unless otherwise agreed upon in writing with the City. Vendor shall make plans for colocation, backups and any other Systems necessary to ensure continuity. | |
| 2.18 | Vendor must notify and obtain agreement from the City for any planned interruptions in service, with the exception of emergency security updates. Vendor must notify the City immediately of any unintended service interruption. | |
| 2.19 | RFP responses should include a plan for content availability in the event of the need to migrate to a different platform. Remittance of content directly to the City of Pittsburgh is acceptable. | |
| 2.20 | Include online Help | |
| 2.21 | Comprehensive Security |
o Local certificates, trusted certificates, and 128-bit SSL
| 2.22 | System should be able to provide an unlimited number of different security groups that can be defined, each with their own security settings and group names that are appropriate. |
| 2.23 | ISO/IEC 27001 Certification or in pursiut of audit before working with the City |
| 2.24 | Storage needs to be capable of compliance with CJIS Security Policy storage requirements: https://www.fbi.gov/services/cjis/cjis-security-policy-resource-center |
| Network: | |
| 3.1 | The solution must adhere to latest best network industry practices. |
| 3.2 | The solution must assure that the integrity of the City's network is sustained by the implementation and utilization of modern firewall, VPN and other remote access technologies. |
| 3.3 | The soluton must provide network authentication and system user events logging. |
| 3.4 | The solution must assure that there will be no degradation in performance of City's network due to their system or design. |
| 3.5 | Proposers must include a list of web browsers and devices their system does/does not support |
| Server and Virtualization: | |
| 4.1 | Solutions are preferred to be cloud based solutions hosted with the provider. If solution needs to be customer hosted enviroment, Google Cloud Platform is preferred. |
| 4.2 | Respondent must detail all additional software licenses that would be required to utilize the product/solution. |
| 4.3 | Provider solution must not incur additional software licensing expense. Provider solution must be a complete package. Solutions utilizing industry standard component applications such as MS SQL are preferred . |
| 4.4 | If and when a City owned software license for a component in the solution stack is viable for utilization to avoid additional software licensing expense, it is to be utilized. |
| 4.5 | If the suggested solution is to be implemented on the City Infrastructure, requirements for component resources from a virtualized hardware perspective are required. vCPU, Memory, Storage per server with an overall summary. |
| 4.6 |
| Data and Reporting: | |
| 5.1 | When geospatial information is needed, the Solution should have the ability to use City GIS layers hosted on ArcGIS online to create geocoding for locations and administrative geographies provided by the City |
| 5.2 | The system should allow for exporting of data through an open, REST API to the City's data ingestion system or the Western Pennsylvania Regional Data Center, as needed. |
| 5.3 | Vendor shall provide data dictionary for database fields, field types, number of characters, value ranges, relationship diagram(s) (database map) of the data model, and key fields used in relationships with database tables. |
| 5.4 | The API provided by the system should include documentation that contains: Sample requests, headers and other relevant metadata, Clear, comprehensive descriptions of the data represented in the API, such as its output format (e.g., JSON or CSV), understandable by someone with a basic to intermediate familiarity with the system, Generated code snippets in some of the most popular programming languages (e.g., Python). API documentation should include details of specific encodings, documentation, data types, requests, and objects for the API. |
| 5.5 | Supports a dashboard with a login |
dependent views
| 5.6 | Ability to provide trend analysis |
| 5.7 | Real-time Reporting |
o At least 150 configurable reports, real-time, and historical graphs
| 5.8 | City must have full ownership and free access to data captured by the System, both during and after the contract period |
| 5.9 | Full API Access - Access to our data through the use of an API must be provided. |
| 5.10 | A general site user must have the ability to embed third party code (ex. Google Calendar) |
| 5.11 | Geospatial data must be compatible with ESRI systems and common geospatial data storage formats (.geojson, .dbf, .shp) |
| Miscellaneous: | |
| 6.1 | Companies from outside the United States are welcome to apply, provided they meet the standards as described above. |
| 6.2 | Remote meetings may be acceptable, with prior arrangement from the City. |
| 6.3 | The City's preference is that Adobe Flash not be part of this solution. |
| 6.4 | Role-based Management |
o Access network maps, configuration, alerts, notifications, reporting, and management console
| 6.5 | The system can accommodate separate instances of databases for testing, training, and quality assurance |
| 6.6 | The vendor shall provide customer service support during the City of Pittsburgh's normal business hours. |
| 6.7 | The vendor shall provide "As-Built" documentation to the City of Pittsburgh representing the state of the application service at the time of Go-Live. |
| Project-Specific Technical Requirements (Mandatory): | |
| 7.1 | Solution to run on multiple Windows platforms |
| 7.2 | Ability to support remote administration |
| 7.3 | Ability to export reports in common formats (PDF, Word, Excel) |
| 7.4 | Solution shall have built-in backup and restore capability |
| 7.5 | If solution hosts or utilized a source of data, solution must have built-in database maintenance and reporting tools |
| 7.6 | Vendor shall include a description of the system’s basic architecture |
| 7.7 | Vendor shall describe how the system handles multiple users, data concurrency control, record locking, and conflict resolutions |
| 7.8 | Vendor shall describe the hosting models (customer enviroment or vender enviroment) |
| 7.9 | Vendor shall describe if the solution servers can be virtualized (and if so, describe the system) |
| 7.10 | Vendor shall describe hardware requirements or recommendations |
| 7.11 | If applicable, describe how the solution can perform database maintenance, including, but not limited to, backup and upgrades without requiring system downtime |
| 7.12 | If applicable, describe the solutions ability to auto-discover targets on the network |
| 7.13 | If applicable, describe the solutions ability to monitor an application and its performance with agentless configurations where possible. |
| 7.14 | If applicable, describe the solutions ability to monitor user response time and throughput by location or other logical grouping. |
| 7.15 | If applicable, describe the solutions ability to drill down into the full |
technical details on how the server and the browser interact with one another.
| 7.16 | If applicable, describe the solutions ability to assemble an e-mail, with one click, that includes a complete user session with replay to provide additional information when triaging an incident. |
| 7.17 | Must support alerting and notifications by email, SMS, pager message, and HTTP |
request
| 7.18 | Vender must provide a visual of the solutions network Mapping, Network topology, subnets, devices, applications, and systems. |
| 7.19 | If applicable, solution should have configurable monitoring that identifys performance, passive, active, real-time, custom (scripted), monitoring templates, and bulk changes |
| 7.20 | If applicable, solution should have have predictive Alerting that is customizable and identifies up, down, and threshold (min/max), maintenance mode, device dependency, and escalation. |
| 7.21 | If applicable, solution must support, SNMP (supports SNMP V1, V2c and V3), WMI (Windows Management Instrumentation), HTTP based services, TCP and UDP based services including PING, Port, SMTP, POP3, FTP |
| 7.22 | |
| 7.23 | |
| 7.24 | |
| Interface Requirements (Project-Specific) | |
| 8.1 | Ability to support two-way communication with Microsoft Outlook |
| 8.2 | Ability to integrate with payroll systems to include, but not limited to Ceridien TimePro version |
| 8.3 | Vendor shall describe if the system have built-in integration with other systems |
| 8.4 | Vendor shall describe if the system can import date from various formats (XML, CSV, TXT). |
| 8.5 | The vendor shall INTERACT with City specific applications (for example APRS, Firehouse, CYA, etc) |
| 8.6 | Solution allows for reading/writing of map services specifically created and published via ArcGIS for Server environment |
| 8.7 | Integrates with existing monitoring tools |
| 8.8 | Scanning, indexing, retrieval current and historical |
| 8.9 | Existing Contract and Purchasing workflow |
| 9 | Payment processing |
| 9.1 | Internal tracking manual processes |
| 9.2 | Interdepartmental autmated workflow development |
| 9.3 | Contract & purchasing workflow |
| 9.4 | Full text indexing and search |
| 9.5 | Library and repository services |
| 9.6 | Metadata services |
| 9.7 | Lifecycle management |
| 9.8 | |
| 9.9 | |
| 10 |
Functional Requirements
| Requirement ID | Requirements | |
| (All of the items apply to any subcontractors that work on the solution. ) | System Capability |
(select from dropdown)
| General Features (Required) | Comments: | |
| 1 | Turn Around Time | |
| 1.1 | Turnaround time for Permits, for scanned documents cannot exceed three (3) working days. Scanned documents along with an updated OnBase, must be returned to Permits, Licenses, and Inspections each week. | Turnaround time is defined as the time the order is picked up from the time the order is completed and delivered to requesting City of Pittsburgh department. |
| 1.2 | Turnaround time not to exceed (5) working days for all work received weekly from City of Pittsburgh Departments from time order is placed to time order is completed and delivered. | |
| 1.3 | Turnaround time for special projects not to exceed 3-5 business days from time order is placed to time order is completed and delivered. | |
| 1.4 | Due to the urgency in which the Department of Permits, Licenses, and Inspections may need to recall a set of documents for review or revision, the permit documents must be returned to the offices of the Department of Permits, Licenses, and Inspections within two (2) hours of request. | |
| 1.5 | In the event that Department of City Planning requires the original set of drawings or permits before the scanning is complete, vendor must be able to return the drawings within two (2) days after request. | |
| 1.6 | Completed scanned documents must be returned to the Department of Permits, Licenses, and Inspections and to the Department of City Planning each week. | |
| 1.7 | leather bound volume books | |
| 1.8 | ||
| 1.9 | ||
| 2 | Pick Up & Delivery | |
| 2.1 | When delivering the competed job a list of all plans included on the delivery should be provided and verified with check out list before delivery receipt is signed. | For the Department of Permits, Licenses, and Inspections all pickups are done at the file room area. A check out list of plans should be signed at pick up. |
| 2.2 | For the Department of City Planning, the permit documents must be returned to the offices of the Department of City Planning within two (2) days of request. | For the Department of City Planning, all pickups are done at the Zoning Counter. A check out list of plans should be signed at pick up. When delivering the competed job a list of all plans included on the delivery should be provided and verified with check out list before delivery receipt is signed. |
| 2.3 | All prices are to include pickup and delivery charges as well as document preparation for scanning. | |
| 3 | HOURLY RATE (FOR LARGE PRE-APPROVED PROJECTS ONLY) | |
| 3.1 | The hourly rate bid will be for pre-approved projects only and will not be able to be charged along with the per page fee. For these bigger projects, department's will bring the awarded vendor in to look at what needs to be done and get a quote. The department will then either approve or deny the quote. No invoices will be paid with this hourly rate unless if the awarded vendor has pre-approval from the Director or his/her designee of the using department. | |
| 3.2 | Routine scanning in the sizes bid out are not viewed as projects. | |
| 3.3 | ||
| 3.4 | ||
| 4 | General Specifications for All Departments | |
| 4.1 | F.O.B. customer door to door. | |
| 4.1.1 | Vendor must supply all cartons and labor necessary to pack records for shipment for each job. | |
| 4.1.2 | Vendor must make all necessary arrangements for transporting records to and from their plant by their own personnel and vehicle. | |
| 4.1.3 | Vendor to return docs in same order they were received | |
| 4.1.4 | Records are to be scanned in correct numerical sequence, and/or alphanumerical sequence, as per instructions of the Department of Permits, Licenses, and Inspections or the Department of City Planning. Records that possess pictures of different or unconventional sizes must be scanned in accordance to the record or as instructed. | |
| 4.2 | Records will be prepared by the vendor (removal of staples, sticky notes, paper clips, etc.) and necessary repairs made on torn sheets, and certain sheets deleted as may be required and requested by the department. | |
| 4.3 | After completion of each scanned document, a frame by frame inspection is required by the vendor to ensure legibility and completeness of record. | |
| 4.4 | The vendor will exercise strict security measures to ensure the confidential nature of all records. | |
| 4.5 | Vendors are not allowed to reproduce, duplicate or distribute any content of the scanned documents to any other entity for any reason without written authorization of the Department of PLI. | |
| 4.6 | Vendor must be OCR compatible. | |
| 4.6.1 | Vendor will include an hour of staff training & admin training to each department listed every 6 months as requested by the department. | |
| 4.6.2 | The number of pages for permit documents can range from one (1) page to more than 100 pages for each set of plans and the number of sets for scanning each week can vary from one (1) set to more than 30 sets. | |
| 4.6.3 | All original and duplicate copies must be indexed with the name of the job, beginning and ending address, and permit number and the date scanned. | |
| 4.6.4 | Destruction authorization must be received by the successful vendor in writing and certified in writing back to the requesting City of Pittsburgh department, or, other entity, indicating inventory of destroyed files. | |
| 4.7 | Vendor will create and/or change document types and search keywords within OnBase upon request. | |
| 4.8 | Vendor must be an OnBase provider | |
| 4.9 | Paper documents scanned to On Base must be Microsoft windows XP-professional compliant. | |
| 4.10 | Instant information access. Combined data and all images. including color. | |
| 4.11 | View and print documents from desktop computer. | |
| 4.12 | Define indexing of documents, file, pages from desktop computer. | |
| 4.13 | All documents must be visible to any computer screen; images must be scanned in color if the original document is in color. | |
| 4.14 | All documents must be text-searchable. | |
| 4.15 | Minimal training required. | |
| 4.16 | Vendor to provide include a proposed work schedule to accomplish all of the required scanning for the various document types listed below. | |
| 4.17 | Digital files will be provided as PDF/A, JPEG, or TIFF, depending on departmental specifications. | |
| 4.18 | For text-based documents, image resolution between 200 and 400 ppi, with a bit depth of 8 or 16, depending on departmental specifications. | |
| 4.19 | For microfilm, image resolution between 3000 and 4500 ppi, with a bit depth of 8, depending on departmental specifications. | |
| 4.20 | Vendor should scan images at the appropriate quality / resolution required for digital duplication and basic printing needs | |
| 4.21 | The ability to compile multiple sheets and multiple file types | Examples include the contents of 611 street history files & D files |
| 5 | Shipping & Delivery Terms | |
| 5.1 | Shipping and delivery costs must be included with vendor's submitted response pricing under the Pricing Proposals section. The City of Pittsburgh will not pay for nor reimburse separate shipping, handling, or delivery fees. | |
| 5.2 | Purchase orders placed under an awarded contract will be F.O.B. Destination. | |
| 5.3 | ||
| 5.4 | ||
| 6 | Document Types | |
| 6.1 | Scan & index 5"x"8 | Item Specification for Scan & index 5"x"8 Description:letter-legal size to computer CD. Bid must include a document set up fee. |
| 6.2 | Scan & Index 24" x 36" | Item Specification for Scan & index 24"x36" Description:Size to computer CD' |
| (Z&DR) Scan & Index standard paper documents up to 11" x 17" (paper sizes range from 8.5" x 11" to 11" x 17") | ||
| 6.3 | (Z&DR) Scan & index Oversized paper documents up to 36" x 48" (sizes range from 24" x 36" to 36" x 48") | Item Specification for Scan & index 36"x42" Item Specification for Scan & index 36"x42" Description:extra-large paper documents approximate size. ex. drawings, building plans, etc. unit price must include a document set up fee. |
| 6.4 | (Z&DR) Scan & Index PUD files | Approx. (xx) file folders containing mixed paper sizes ranging from 8.5 x 11" to 36" x 48" |
| 6.x | (Z&DR) Scan & Index ZBA Binders (8.5x11) | Approx. (85) 4-inch binders containing 8.5 x 11 ZBA decisions. Each binder contains approx. 850 single faced sheets, for approx. 72,500 pages. |
| 6.x | (Z&DR) Scan & Index ZBA Bound Books (8.5x11) | Approx. 169 bound books approx. 2-inches thick (varies in thickness, approx. 306-inches overall). 8.5 x 11 page size, single face. Approx. 48,000 pages. |
| 6.x | Bound volumes ranging in size from 9"x 8" to 22" x 14" | To ensure bound volumes are not damaged, vendor must use planetary book scanner or digital cameras (no flatbed scanners) |
| 6.x | Scan and Index blueprints and other maps | Some of these maps are on tracing paper. Others are almost falling apart or in a fragile state due to their age. |
| 6.x | Scan & Index kardex cards & Traffic work orders | The smallest size is 5"x8" |
| 7 | Document Estimates | |
| 7.1 | Please see attached documents with RFP request. | |
| 7.2 | ||
| 7.3 | ||
| 8 | ||
| 8.1 | ||
| 8.2 | ||
| 9 | ||
| 9.1 | ||
| 9.2 | ||
| 10 | ||
| 10.1 | ||
| 10.2 |
Index
| Core Capability |
| Configurable by Vendor |
| Configurable by City Staff |
| Requires Customization |
| Provided in Conjunction with a 3rd Party |
| Not Applicable |
Data Validation
| Core Capability |
| Configurable by Vendor |
| Configurable by City Staff |
| Requires Customization |
| Not Applicable |
File details come from the government source that posted it. Updated .