Questions and Responses.xlsx
XLSX spreadsheet 432 KB Posted
- Attached to
- Claims System Modernization
- Solicitation number
- ITN-14535
- Issued by
- Leon County, Florida
About this file
This document is a Questions and Responses file for ITN No. 2526-01, issued by the Florida Department of Financial Services, Division of Rehabilitation and Liquidation (DRL), concerning the modernization of the Online Liquidation Claims Processing System (OLCP). DRL seeks to replace its current Visual FoxPro-based system with a cloud-based Platform as a Service (PaaS) solution capable of managing approximately 14.8 million policy records and supporting complex claims workflows across multiple insurance lines including property and casualty, workers' compensation, health, life, and title insurance. The system must process claims for concurrent liquidation estates with 100% data isolation between estates, integrate with Microsoft Dynamics for accounting functions and IBM FileNet for document management, support real-time UDS (Uniform Data System) file exchanges with guaranty associations, and provide comprehensive audit trails and multi-user portal capabilities. The project encompasses full system development, data migration from legacy systems (approximately 406 gigabytes of master database plus 115 terabytes of documents), user acceptance testing, training for approximately 53 internal users, hypercare support lasting four to six weeks post-implementation, and ongoing support services. The response deadline was extended to February 6, 2026, at 3:00 PM Eastern Time, with an anticipated project start date to be determined following contract execution and a five-year initial contract term with potential renewal for an additional five years.
The estimated total project cost is $8,225,658, with $5,441,293 requested for fiscal year 2025-26 and $1,384,365 for fiscal year 2026-27, with annual recurring operational costs of approximately $250,834 beginning in 2026-27 for platform licensing and support services. The Department intends to award a single contract based on best value to the State and reserves the right to make no award if determined to be in its best interest. There is no incumbent contractor as this represents a new modernization initiative rather than a recompete. Funding has been partially appropriated by the Florida Legislature with annual budget request updates required. The proposed solution must comply with Chapter 60GG-2 and -4 Florida Administrative Code regarding data security and residency requirements, maintaining all data at rest within the continental United States. The vendor is responsible for proposing the cloud service provider and platform architecture, with no predetermined preference for specific vendors such as Microsoft Azure or AWS. All implementation and ongoing support work must be performed onshore within the continental United States, and vendors with access to non-open data cannot be located outside the continental U.S. The Department provided extensive clarification through the Questions and Responses document addressing data volumes, integration requirements, business process workflows, security standards including TLS 1.3 encryption requirements and WCAG AA accessibility compliance, disaster recovery parameters, and technical environment specifications to be finalized during contract negotiations.
View the file
Other files
Show all 24
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
Questions
| Department of Financial Services - Division of Rehabilitation and Liquidation (DRL) | ||||||
| ITN No: 2526-01 | ||||||
| Exhibit 1 - Questions Template | ||||||
| ATTACHMENT IDENTIFIER | SECTION REFERENCE | SUB-SECTION REFERENCE (If Applicable) | ITEM REFERENCE (If Applicable) | PAGE NUMBER | QUESTION | Responses |
| Appendix B - Exhibit 5 | Schedule IV-B | Business Need | 7 OF 62 | Does DFS have all the source code of the existing Visual FoxPro system? | Yes. | |
| Appendix B - Exhibit 5 | Schedule IV-B | Business Need | 7 OF 62 | What percentage (estimated) of the database structures, workflow, screens, and reports of the existing Visual FoxPro 9.0 system would DFS like to maintain or keep similar? | Proposed Vendor solutions are intended to fully replace OLCP. | |
| Appendix B - Exhibit 5 | Schedule IV-B | Business Need | 44 OF 62 | Is ALL the existing LCP data in the SQL Server "RL Master Database" or is there some data (i.e. admin tables) in FoxPro tables? | The vast majority of data is housed in the RL Master Data and some data exists within FoxPro Tables. | |
| Appendix B - Exhibit 5 | Schedule IV-B | Business Need | 7 OF 62 | Does a data dictionary and/or an ERD exist for the existing Visual FoxPro system? | No. | |
| Appendix B - Exhibit 5 | Schedule IV-B | Business Need | 7 OF 62 | Is the final caretaker (as mentioned in the Schedule) of the Visual FoxPro system still employed at DFS? | Yes. | |
| Appendix B - Exhibit 5 | Schedule IV-B | Business Need | 7 OF 62 | During the development of the NEW system, if you COULD make minor changes or bug fixes to the existing FoxPro 9.0 system (i.e. adding an email field or avoiding field data truncation), would you WANT to? | The intent of this procurement is to fully replace OLCP. | |
| Appendix B - Exhibit 5 | Schedule IV-B | Business Need | 7 OF 62 | Are the developers who wrote the 'workaround' .NET utility scripts still employed at DFS? | DRL staff have existing expertise in and familiarity with the Visual FoxPro system. | |
| Appendix B - Exhibit 5 | Schedule IV-B | Business Need | 7 OF 62 | Is the author(s) of the Schedule IV-B, Michael Stephens (who did a great job on the document, btw) still employed at North Highlands and available for questions? | North Highland will support the Department during the negotiation process, as needed, pursuant to its contract with the Department. | |
| Appendix B - Exhibit 5 | Schedule IV-B | Business Need | 8 OF 62 | Form Processing. Assuming the NEW claim forms are part of the new web-based system, is there any incoming confidential information in the various modules of the new system (i.e. PHI, PCI, Biometric, Personal Data (SSN, DOB, etc.) | Yes. | |
| Appendix B - Exhibit 5 | Schedule IV-B | Business Need | 9 OF 62 | Does DFS own a license of the DataCap system (OCR document scanning and can that license be shared with the selected vendor? | DRL does not own a DataCap license. | |
| Appendix B - Exhibit 5 | Schedule IV-B | Claims - Migration of Data from Company in Receivership | 14 OF 62 | Assuming that receivership insurance companies all have different systems and data structures, can you summarize how the DFS IT team 'normalizes' data from those disparate systems into the RL Master database(s)? This seems like a nightmare. Over the years, have any scripts been written to 'known' systems to facilitate this data import and normalization process? | DRL has successfully utilized in-house Receivership staff to generate disparate systems data in a flat file format or other mutually agreed-upon formats, utilizing the Data Dictionary as guidance. | |
| Appendix B - Exhibit 5 | Schedule IV-B | Claims - Migration of Data from Company in Receivership | 14 OF 62 | Another way to ask that last question: Pipelines are mentioned: Are there any existing data normalization / data duplication elimination pipelines written to mitigate the data import nightmare? | Current ETL and Stored procedures, data testing reports, data quality checks takes care of most of the data import process. Individual issues are assessed and resolved through discussions with business users. | |
| Appendix B - Exhibit 5 | Schedule IV-B | Claims - Support | 16 OF 62 | Are commissions paid to agents multi-tiered? Is the math for those calculations available in the current Visual FoxPro system? | Calculations for commissions (earned and unearned) are outside the Visual FoxPro system. | |
| Appendix B - Exhibit 5 | Schedule IV-B | Claims - Support | 15 OF 62 | What is Service Point? Does DFS own a license to this? | Service Point is a customer service / inquiry management system has been replaced with another system. The replacement system is CRM (Customer Relationship Management) through EY. The product is licensed to DFS. | |
| Appendix B - Exhibit 5 | Schedule IV-B | Claims - Support | 15 OF 62 | In regards to calcualations in general: Are all the calculations accessible in the existing system? In other words, are all existing claims/ payments / returns SOURCE CODE calculations accessible in Visual FoxPro? | No, most exists outside Visual Foxpro. | |
| Appendix B - Exhibit 5 | Schedule IV-B | Claims | 15 of 62 | Claim CLOSEOUT workflows and calculations can often be complicated. We understand that you want to improve these, but are all the EXISTING workflows / calculations available for reference in the existing Visual FoxPro system? | No. Calculations are run outside of the current Visual FoxPro system. i.e., RP, Claim Evaluations, Distribution. | |
| Appendix B - Exhibit 5 | Schedule IV-B | Current Environment | 45 of 62 | Is the NEW system expected to have any interfaces with PALM? Especially in the area of processing checks and coding those payments? (i.e. ORG CODES, OCAs, FUNDs) | No; The proposed solution is not required to interface with FLAIR's replacement system, PALM. | |
| Appendix B - Exhibit 5 | Schedule IV-B | Current Environment | 45 of 62 | Does the existing Visual FoxPro system send ANY financial data to FLAIR? | No financial information is sent to FLAIR through OLCP. | |
| Appendix B - Exhibit 5 | Schedule IV-B | Current Environment | 45 of 62 | Are the person(s) who wrote the SSIS packages and ad hoc scripts still available as a reference? | DRL staff have existing expertise in and familiarity with the Visual FoxPro system. | |
| Appendix B - Exhibit 5 | Schedule IV-B | Current Environment | 45 of 62 | What version of SQL Server is the RL Master Database(s)? | SQL SERVER 2014 | |
| Appendix B - Exhibit 5 | Schedule IV-B | Recommended Technical Solution | 49 of 62 | Although difficult to read, Figure 22 Proposed Solution Diagram is very specific. Has DFS or North Highlands already identified a PaaS Provider that can provide this proposed solution? | No specific vendor has been previously identified to provide the proposed solution. | |
| Appendix B - Exhibit 5 | Schedule IV-B | Recommended Technical Solution | 49 of 62 | Is the vendor who created the Proposed Solution (North Highlands) excluded from bidding on this ITN ? | Yes, North Highland is excluded. | |
| Appendix B - Exhibit 5 | Schedule IV-B | Recommended Technical Solution | 49 of 62 | When completed, would DFS prefer to LICENSE the new solution or OWN the intellectual property copyright to the new solution? | This is contingent upon Respondent's proposed solutions. | |
| Appendix B - Exhibit 5 | Schedule IV-B | Recommended Technical Solution | 51 of 62 | Does DFS use Active Directory? | Yes | |
| Appendix B - Exhibit 5 | Schedule IV-B | Recommended Technical Solution | 51 of 62 | Mobile access is mentioned. Can we assume that the new system (parts of it at least) MUST be available on all newer mobile devices including iOS and Android? | This would be a nice to have feature both for iOS and Android but not required. | |
| Appendix B - Exhibit 5 | Schedule IV-B | Recommended Technical Solution | 51 of 62 | Mobile access is mentioned. Can we assume that the Android and iOS mobile components of the new system MUST be published on the Google Play Store and the Apple store, respectively? | This would be a nice to have feature both for iOS and Android but not required. | |
| Appendix B - Exhibit 5 | Schedule IV-B | Recommended Technical Solution | 50 of 62 | The API layer is mentioned in the Proposed solution. Can DFS provide an estimate on the number of 3rd party systems that will be accessing this API? Are the State Guaranty Fund, Bulk Mailing Services and NRS Pro Abandoned Property the only ones? | No API access to State Guaranty Fund. Current system has API access to FileNet (Document Mgmt system). New system expected to have API access to Bulk Mailing, HRS Pro, Abandoned Property, Accounting system (Dynamics) and OFAC. | |
| Appendix B - Exhibit 5 | Schedule IV-B | Recommended Technical Solution | 50 of 62 | Push Notifications are mentioned in the diagram. Is this expected be email AND SMS notifications in the new system? | Proposed Respondents alternatives will be considered. | |
| Appendix B - Exhibit 5 | Schedule IV-B | Recommended Technical Solution | 50 of 62 | Single Sign On for the new system is assumed. Is this assumption correct'? | Yes | |
| 2526-01 ITN DRL - Complete Package | SECTION 1. Introduction | 2.2 Timeline | N/A | 7 | We respectfully request a two-week extension to the current deadline for submitting responses and all required documents. This additional time will help ensure a complete and thorough submission that meets the Department’s requirements. | If an extension is granted, an addenda will be published in the Vendor Information Portal. |
| 2526-01 ITN DRL - Complete Package | 1. Introduction | 1.1 Purpose | N/A | 3 | Please confirm the intended award structure for this ITN. Does the Department anticipate awarding one (1) contract to a single vendor, or does it reserve the right to make multiple awards? | "The Department intends to award one (1) Contract resulting from this ITN but reserves the right to make no award as determined to be in the best interest of the State…" |
The intent is for one contract; If a contractor had a subcontractor, the award would still be one contract with a Prime and sub component.
| 2526-01 ITN DRL - Complete Package | I. Schedule IV-B Cover Sheet | Schedule IV-B Preparers | N/A | 134 | Please confirm whether North Highland is eligible to participate in this ITN and if the Department anticipates North Highland submitting a proposal as a competitor. | North Highland is not an eligible participant. | |
| 2526-01 ITN DRL - Complete Package | ATTACHMENT 2 | ||||||
| Statement of Work | 3. Payment Provisions. | c. Invoicing. | 35 | The ITN requires monthly invoicing in arrears, but pricing is requested annually. Should we base the annual price on Schedule IV-B Project Management Planning? Also, will monthly invoices be a prorated portion of the annual price, or handled differently? | These details will depend upon Respondents' proposed pricing structure and may be discussed during the negotiation portion of this process. | ||
| ITN Document | 1.2 Background | Current System Environment | N/A | 5 | What is the expected concurrent user count for the new system (administrative users, standard users, and public portal users) during peak processing periods? | Currently there are 53 internal users. | |
| ITN Document | 1.2 Background | Current System Environment | N/A | 5 | What is the average annual volume of claims processed, POC/NOD notices generated, and payments disbursed across all active liquidations? | These averages are solely dependent upon the number of companies ordered into liquidation and the number of active receiverships at a given point in time, which is unpredictable. The information requested for active and prior receiverships is available via the DRL website. |
Link: https://www.myfloridacfo.com/division/receiver ITN Document 1.2 Background Current System Environment N/A 5 How many concurrent insurance company liquidations does DRL typically manage simultaneously, and what is the maximum number anticipated over the contract term? DRL is currently managing 12 active liquidations (estates). An anticipated maximum number can't be accurately conveyed because of the number of uncontrollable and unpredictable factors. Since 1/1/2013, there have been 22 companies ordered into liquidation. Of those 22, the highest volume of new liquidations was in between April 2021 and September 2022 with 7 new liquidation orders in an 18 month period. The number of concurrent liquidations is largely dependent upon the number of new liquidation orders, the amount of time between them, and the size & complexity of each company ordered into liquidation. Additional information can be found on the Division of Rehabilitation and Liquidation website.
Link: https://www.myfloridacfo.com/division/receiver
| Attachment 8 | System Functionality | SF-01 | Multi-tenancy requirement | 15 | What level of data isolation is required between concurrent liquidation estates? | 100% data isolation between concurrent Liq estates. |
| ITN Document | 1.2 Background | Current System Environment | 14.8 million policy records | 5 | What is the expected annual growth rate of policy records and claims data over the 10-year contract period? | This is solely dependent upon the number of companies ordered into liquidation and the number of active receiverships at a given point in time, which is unpredictable. The information requested for prior receiverships is available via the DRL website. |
Link: https://www.myfloridacfo.com/division/receiver
| Attachment 8 | Documentation Management | DM-02 | Document storage | 8 | What is the current total volume of documents stored in the legacy system? | 115 TB |
| Attachment 2 | 4.2 Contractor Responsibilities | Phase 3: Design | Data migration strategy | 12 | Can DRL provide a detailed data dictionary and ERD for the current Visual FoxPro OLCP system? | Relevant system information will be provided during the negotiations process. |
| Attachment 2 | 4.2 Contractor Responsibilities | Phase 4: Development | Data conversion | 13 | What is DRL’s preferred migration approach? | DRL is interested in reviewing Respondent's proposed solutions regarding this element. |
| ITN Document | 1.2 Background | Current System Environment | Legacy limitations | 5 | Are there active liquidations that must remain operational during migration? | Yes |
| Attachment 8 | Documentation Management | DM-01 | Bulk data loading | 8 | What is the acceptable data migration success rate threshold? | Success is defined based on acceptance criteria set by DRL with 100% data integrity and accuracy rate. |
| ITN Document | 1.2 Background | Current System Environment | Historical data | 5 | How many years of historical data must be migrated? | This may be discussed during negotiations and with the awarded Contractor. |
| Attachment 8 | System Functionality | SF-18 | Accounting integration | 17 | What accounting system is currently used by DRL? | MS Dynamics. |
| Attachment 8 | Business Process | BP-08 | UDS processing | 4 | What is the average monthly volume of UDS files? | Outgoing UDS volume varies significantly depending on Receivership status. File counts can range from fewer than ten to several hundred, with each file containing anywhere from one to tens of thousands of records. Volume is particularly high for new Receiverships. |
| Attachment 8 | System Functionality | SF-17 | FileNet integration | 17 | Is FileNet integration mandatory? | Yes. |
| Attachment 8 | Notification & Communication | NC-04 | ACH/EFT processing | 10 | What ACH/EFT vendor is used? | The Department does not have an ACH/EFT vendor. The Department issues checks for distributions. |
| Attachment 8 | Notification & Communication | NC-05 | Address verification | 10 | Does DRL mandate a specific address verification provider? | No. |
| Attachment 8 | System Functionality | SF-18 | EDI capabilities | 17 | What EDI transaction sets are required? | No EDI transaction sets are required. |
| ITN Document | 2.3 Minimum Qualifications | Security & Compliance | N/A | 8 | What security certifications are required? | No security certifications are required. |
| ITN Document | 2.3 Minimum Qualifications | Security & Compliance | Florida Statutes | 8 | Are there data residency requirements? | Yes. |
| Attachment 3 | Table D | Annual Support Costs | Hosting Services | 3 | Is a specific cloud required? | No. |
| Attachment 8 | Online Portal | OP-08 | Encryption | 12 | What encryption standards are required? | TLS 1.2 is the basic standard, however TLS 1.3 is preferred. The following are examples of other guidelines for in-transit encryption: |
Enforce HTTPS everywhere Enable HSTS (HTTP Strict Transport Security) Disable weak ciphers and protocols TLS 1.3 Ciphers:
TLS_AES_128_GCM_SHA256
TLS_AES_256_GCM_SHA384
TLS 1.2 Ciphers:
ECDHE + AES-GCM
ECDHE + ChaCha20-Poly1305 Key Exchange ECDHE (Elliptic Curve Diffie-Hellman Ephemeral) Certificates RSA 2048+ or ECDSA (P-256 or stronger) Certificates from a trusted CA (e.g., public or enterprise PKI) Encryption At-rest is also desired.
Vendors with access to the network must pass a background check and if CJIS data is involved, must pass a CJIS background screening.
| ITN Document | 2.3 Minimum Qualifications | Disaster Recovery | N/A | 8 | What are RTO/RPO requirements? | Additional details related to RTO and RPO targets will be discussed during the negotiation process. |
| Attachment 2 | 4.2 Contractor Responsibilities | Ongoing Support | N/A | 15 | What system availability SLAs are required? | Respondents must sufficiently respond to the procurement documents. The Department may discuss specific SLAs during the negotiation process. |
| Attachment 8 | Notification & Communication | NC-01 | Bulk notices | 9 | What is the acceptable bulk notice processing time? | Bulk mail processing times vary depending on the size of the mailing. Currently, DRL is able to mail about 17,000 items a week. |
| Attachment 8 | Online Portal | OP-01 | Portal performance | 11 | What are public portal response time requirements? | This may be discussed during negotiations and provided to the awarded Contractor. |
| Attachment 2 | 4.2 Contractor Responsibilities | Support Services | N/A | 15 | What support response times are required? | This may be discussed during negotiations and provided to the awarded Contractor |
| Attachment 2 | 4.2 Contractor Responsibilities | Phase 7: Go-Live | Hypercare | 14 | What is the expected hypercare duration? | This is dependent upon the Respondent's proposed approach; however, hypercare could be approximately 4-6 weeks. |
| Attachment 2 | 4.2 Contractor Responsibilities | Phase 6: Deploy | Training | 14 | How many DRL staff require training? | All active OLCP users will need training. As of 1/7/26, there are 53 users. |
| Attachment 2 | 4.2 Contractor Responsibilities | Phase 5: Test | UAT | 13 | What is the expected UAT duration? | This is contingent on proposed Respondent solutions. |
| ITN Document | 1.3 Project Objectives | Implementation Timeline | N/A | 6 | Are there go-live constraints? | Go-live constraints are unknown at this time as they are contingent upon Respondent's proposed solution. |
| Attachment 8 | Exhibit 5 | Schedule IV-B | Staging Data Validation | The document mentions a "flexible data schema template" for the staging environment. Does a canonical data model defined by DRL already exist to which we must map the insurance company data, or is the provider expected to define this standard model as part of the solution? | Respondent is expected to define this standard model as part of the solution since it has to match with new solution. | |
| Attachment 8 | Exhibit 5 | Sección 1.2 (Background) | Historical Volume | It is indicated that 14.8 million policy records are currently managed. What is the total volume of historical data (in Terabytes or total record count, including transactions and audits) that must be migrated from the current Visual FoxPro system to the new solution? | 406 GB Master database | |
| Attachment 8 | Exhibit 5 | Schedule IV-B | Data Cleansing | The document notes data quality issues in the source systems. What is the expectation regarding the provider's responsibility for data cleansing? Is the system expected to correct errors automatically, or simply flag them for manual review in the staging area? | Where clear, rules-based corrections can be defined (deterministic rules), the proposed solution should automatically cleanse/correct the data without manual intervention. Data issues that don't meet predefined correction criteria should be flagged and routed to a manual review process. | |
| Attachment 8 | Exhibit 5 | Images and Documents | The IBM FileNet and DataCap systems are mentioned. Does the migration include the physical transfer of millions of existing images and documents to a new cloud repository, or should the new solution integrate with and "point" to the existing FileNet repository? | Respondent must provide integration to on-premises FileNet and storage capacity for existing Windows storage containing legacy images. | ||
| Attachment 8 | Exhibit 5 | Accounting System | The use of Microsoft Dynamics for accounting is confirmed. Is the required integration real-time (API) for each payment/reserve transaction, or is a daily batch process preferred for reconciliation? | This is contingent upon the Respondent's proposed solution. | ||
| Attachment 8 | Exhibit 5 | Appendix 1 | UDS Standard | The exchange of UDS files (A, B, C, D, etc.) with NCIGF is mentioned. Should the solution include a validation engine to verify strict compliance with the UDS format before ingestion/submission, or does this validation occur externally in the mentioned "Data Mapper"? | Respondent proposed solutions should include a validation engine to verify strict compliance with UDS format before ingestion/submission. Validation occurs partially in the Data Mapper and within OLCP. | |
| Attachment 8 | Exhibit 5 | Appendix 1 | Mailing Services | The use of a "Bulk Mailer" is mentioned. Must the new solution integrate with DRL’s current print and mail provider via API, or is the solution expected to include its own physical correspondence management module? | There is no API for Bulk Mailer. Respondent alternatives for correspondence management will be considered. | |
| Attachment 8 | Address Verification | Validation and updating of addresses are required. Does DRL have an existing license with an address verification service provider (such as USPS CASS) that we should integrate, or must the provider supply this subscription as part of the solution? | DRL has licenses for BCC Bulkmailer. Respondents should provide responses that integrate into that license. | |||
| Attachment 8 /2 | External User Authentication | For the stakeholder portal, what is the preferred authentication mechanism for public claimants (non-employees)? Is integration required with any Florida state citizen identity provider, or should the provider manage the external user directory? | Respondent must provide a proposed solution for authentication mechanism(s). The Respondent should manage external user information. | |||
| Attachment 8 | Exhibit 5 | Accessibility | Compliance with WCAG is required. What is the specific level of conformity required (A, AA, or AAA) for the public portal and internal interfaces? | AA. | ||
| Attachment 8 | Exhibit 5 | Section 3 | Bulk File Upload | It is mentioned that agents may need to upload multiple claims. Is there a file size limit or a record-per-upload limit that the system must support to ensure performance? | No. | |
| Attachment 8 | Exhibit 5 | Low-Code Configuration | Low-code/no-code configuration capability is requested. Who will be primarily responsible for performing these configurations after implementation: the DRL IT team or the business users (claims analysts)? This impacts the training strategy. | This depends on the specific configuration. For training strategy, this impacts both IT and Business users. Additionally, DRL has 3 developers on staff that have varying experience and will be able to partner with the Contractor to plan for post-implementation support | ||
| Attachment 8 | Exhibit 5 | Class Priority Rules | Asset distribution rules by class are complex. Must the system allow a business user to modify class priority rules and proration percentages without IT intervention, or are these rules considered static by law? | Role based and, for auditing purposes, Respondent's proposed solution should be able to capture who changed any rules and whether they are allowed to change them. Quarterly auditing by ASO is needed for continuity of those roles and users can be given permissions at the discretion of each Director for their respective section. |
The rules are not static according to law, however they must remain largely static due to audit standards. All changes must be tracked and documented, including documentation as to what user(s) made modifications to the rules.
| Attachment 8 | Objection Management | Handling of objections to Notices of Determination (NOD) is mentioned. Should the system include a full legal case management module to track litigation and court hearings, or only record the status and final resolution of the objection? | Full legal case management is likely not needed, but the ability to track dates (date hearing requested and date of the hearing) along with the final resolutions is needed. | |||
| Attachment 8 | Master Claims | The processing of "Master Claims" is mentioned. Could you detail the required data relationship between a master claim and individual subsidiary claims? Should they be processed financially as a single unit or individually? | Master Claims are claims that involve other claims within the estate. As an example, consider subrogation claims. ABC Insurance may have 500 subrogation claims pending against an estate. ABC Insurance has 1 master claim. The individual insureds and claimants in those 500 claims also have their individual claims against the estate. As another example, a Master Claim is filed by a particular vendor to include all of their outstanding/unpaid claims/invoices under one assigned Receiver Claim Number. This eliminates a vendor from filing multiple claims under separate Receiver Claim Numbers. | |||
| Attachment 8 | Exhibit 5 | Cloud Preference | Given that the current architecture uses Microsoft SQL Server and the accounting system is MS Dynamics, is there a preference or mandate for the PaaS solution to be hosted on Microsoft Azure, or is it cloud-agnostic (AWS, Google Cloud) / Pega System / Appian? | No. | ||
| Attachment 5 | Data Security Requirements | Data Custody | The document mentions compliance with Chapter 60GG-2. Are there specific data residency requirements (e.g., data must physically remain within the continental U.S.) that we must certify? Note: Usually yes for government, but it is good to confirm to eliminate doubt. | Yes, pursuant to Chapter 60GG-2 and -4. | ||
| , Attachment 2 | Disaster Recovery (DR) | The current risk of lacking dynamic failover is mentioned. For the new PaaS solution, what are the target Recovery Time Objectives (RTO) and Recovery Point Objectives (RPO) required by the business? | Additional details related to RTO and RPO targets will be discussed during the negotiation process. | |||
| Attachment 2 | Hypercare | A "Hypercare" period following go-live is mentioned. What is the expected duration of this intensive support period before transitioning to standard operational support? | This is dependent upon the Respondent's proposed approach; however, hypercare could be approximately 4-6 weeks. | |||
| Attachment 8 | Exhibit 5 | DRL IT Team | It is indicated that the current DRL IT team (14 people) is overextended. What is the expected role of this team during the implementation phase? Will they be available for data migration, or should the provider assume the full burden of extraction from the legacy system? | The awarded Contractor will work alongside DRL staff as needed. Please refer to Attachment 2, Statement of Work, Department's Responsibilities. | ||
| Attachment 2 | Statement of Work | Data Migration | Data Quality | N/A | What is the estimated data quality level in the current OLCP system? Are there known data quality issues, duplicate records, or incomplete data that should be addressed during migration? | There are no known data quality issues, duplicate records or incomplete data. |
| Attachment 2 | Statement of Work | Data Migration | Historical Access | N/A | Do DRL staff need active access to historical closed estate data for research, audits, or legal inquiries? If so, what query and reporting capabilities are required for archived data? | Access to estate data is needed for some time after the estate is closed / discharged. Additional discussions with the awarded Contractor will determine the level of access needed to archived data. |
| Attachment 2 | Statement of Work | Data Migration | Legacy OLCP Data | N/A | Can DRL provide a data dictionary or schema documentation for the current OLCP system, including historical database structure, to facilitate accurate data mapping and migration planning? | This information is not available. |
| Attachment 2 | Statement of Work | Data Migration | Policy Records | N/A | Of the 14.8 million policy records currently managed, approximately how many are in active receivership estates versus closed estates? Will closed estate data require migration or can it be archived separately? | All 14.8 million policies are within active receivership estates. Additional details may be discussed during negotiations and with the awarded Contractor. |
| Attachment 2 | Statement of Work | Documentation | System Documentation | N/A | What documentation deliverables does DRL require? (e.g., user manuals, technical documentation, system administration guides, API documentation, training materials) | DRL requires at least the following, user manuals, technical documentation, system administration guides, API documentation, and training materials. |
| Attachment 2 | Statement of Work | Project Phases | Implementation Timeline | N/A | Does DRL have a preferred or required timeline for the OLCP replacement implementation? Are there specific milestones or go-live dates that must be met? | Please refer to Exhibit 5, Schedule IV-B DFS (Liquidation Claims Processing System Replacement) for further details. |
| Attachment 2 | Statement of Work | Project Scope | Legacy System Transition | N/A | What is the expected transition period for running both legacy OLCP and the new system in parallel (if any)? When can the legacy system be fully decommissioned? | From the Claim perspective, the two systems will likely run in parallel until all testing and training is complete and for a period of time (possibly 6 - 12 months) after to ensure no additional issues are identified. Decommissioning would occur at that point. |
From the IT perspective, decommissioning would occur after sign-off by business users and IT. The legacy system would be available and maintained within DRL to refer for any comparison.
| Attachment 2 | Statement of Work | Project Scope | Phased Approach | N/A | Is DRL open to a phased implementation approach (e.g., core claims processing first, followed by advanced analytics and portal functionality), or is a complete system replacement required at initial go-live? | The Department prefers that the complete system would be delivered at go-live. Additional details may be discussed during negotiation and with the Contractor. |
| Attachment 2 | Statement of Work | Reporting | Ad Hoc Reporting | N/A | What level of ad hoc reporting capability does DRL require? Should business users be able to create custom reports without IT assistance? | Yes. End users should be able to create reports without IT assistance. |
| Attachment 2 | Statement of Work | System Integration | Bulk Mailers | N/A | Which bulk mailing service provider(s) does DRL currently use for POC and NOD distributions? Are there existing integration specifications or vendor APIs available? | BCC Bulk Mailer is used for POC and NOD distributions. Additional information for respondent APIs could be found at Bulk Mailer's website. |
Link: https://bccsoftware.com/software/mail-presort-suite/bulk-mailer-smb/ Attachment 2 Statement of Work System Integration Document Management N/A What document management system(s) does DRL currently use? Are there existing API specifications or integration requirements for document storage and retrieval? Documents are stored in Windows Storage on premise and some incoming documents are also stored in FileNet which requires API integration.
Image Lookup is web application and there are no plans to integrate with API for future modernizations. Additionally, there is no storage in Image Lookup.
Attachment 2 Statement of Work System Integration MS Dynamics Integration N/A Can DRL provide technical specifications, API documentation, or integration requirements for the MS Dynamics accounting system integration? What version of MS Dynamics is currently in use? MS Dynamics is facilitated through database connections and the current version in use is MS Dynamics SL 2018. Currently, there is no such documentation to provide.
| Attachment 2 | Statement of Work | Technical Environment | Authentication | N/A | Does the State of Florida have a centralized identity and access management (IAM) system that the new OLCP should integrate with for single sign-on (SSO) and multi-factor authentication (MFA)? | No. |
| Attachment 2 | Statement of Work | Technical Environment | Hosting | N/A | Will the State of Florida provide hosting infrastructure (on-premises or state-managed cloud), or does DRL expect the Contractor to propose a hosting solution? If state-hosted, what is the technology stack and platform? | Respondents should propose a cloud hosting solution; There is no requirement/need to embed through State hosting. All proposed solutions should comply with Chapter 60GG-2 and -4. |
| Attachment 2 | Statement of Work | Training | User Training | N/A | Approximately how many DRL staff members will require training on the new system? Should training be provided in phases (super users, then general users) or all at once? | All active OLCP users will need training. As of 1/7/26, there are 53 users. Training timing can be discussed in negotiation and should be outlined in the response. |
| Attachment 2 | Statement of Work | Workflow Automation | Manual Processes | N/A | Can DRL provide a prioritized list of the most time-consuming manual processes currently performed outside OLCP that should be automated in the new system? | Please refer to Exhibit 5, Schedule IV-B DFS (Liquidation Claims Processing System Replacement) for further details. |
| Attachment 5 | Data Security | External Access | Claimant Portal | N/A | For the self-service claimant portal, what level of functionality should claimants have? (e.g., view-only status, document upload, claim submission, secure messaging)? | The self-service claimant portal should, at a minimum, allow for claimants to upload relevant documents (POCs and documents to support their claims), check claims status, and a messenger to ask questions related to their claim. |
| Attachment 5 | Data Security | External Access | Guaranty Associations | N/A | Do guaranty associations require direct system access or is data exchange handled via batch file transfers? If direct access, what are the security and permission requirements? | Data exchange happens with UDS, but Guaranty Association users have access to OLCP. The same level of access is expected in Respondent's proposed solutions. Respondent solutions should propose security and permission requirements for GAs with direct access. |
| Attachment 5 | Data Security | Infrastructure | Disaster Recovery | N/A | What are DRL's specific disaster recovery requirements? (e.g., Recovery Time Objective, Recovery Point Objective, geographic redundancy requirements) | Additional details related to RTO and RPO targets will be discussed during the negotiation process. |
| Attachment 5 | Data Security | User Access | Role Definitions | N/A | How many distinct user roles does DRL anticipate for the new system (e.g., claims analysts, supervisors, liquidation managers, legal staff, read-only auditors)? Can DRL provide role definitions and permission requirements? | Respondents should provide a response that describes personnel roles and provide definitions of each that describe each role's rights and responsibilities within the system. |
| Attachment 8 | Business Requirements | Analytics | KPIs and Dashboards | N/A | What key performance indicators (KPIs) and dashboard metrics are most critical for DRL management to monitor receivership operations (e.g., claims processing cycle time, aging reports, distribution timelines)? | This will depend largely on the solution's capabilities. Examples include cycle times for assigned work items, deadlines for timeline activities, project completion status, etc. |
| Attachment 8 | Business Requirements | Data Ingestion | Insolvent Company Data | N/A | When an insurance company enters receivership, what is the typical format and structure of data received from the insolvent company? Are there standard formats or does it vary significantly by company? | This varies significantly by company. However, DRL includes a data dictionary to standardize formatting. |
| Attachment 8 | Business Requirements | Reporting | Court Reports | N/A | Can DRL provide templates or examples of required court reports, including Interim Claims Reports (ICR), Final Claims Reports, and distribution reports? What are the reporting frequencies and deadlines? | Reports are generated at various intervals - Monthly, quarterly, annually, etc. Sample ICRs, FCRs, and distribution reports can be found on DRL's website attached to their respective motions and orders. |
Link: https://www.myfloridacfo.com/division/receiver
| Attachment 8 | Business Requirements | Stakeholder Access | Guaranty Association Functions | N/A | What specific functions or workflows involve guaranty association participation? (e.g., covered claims identification, early access distributions, coordination on multi-state insurers) | Workflows between GAs and DRL do not currently exist within the current system. Development of these workflows will be dependent on the Respondent's solution capabilities and can be discussed during the negotiation process. |
| Attachment 8 | Business Requirements | System Functionality | Performance Requirements | N/A | What are DRL's performance expectations for the new system? (e.g., maximum page load times, concurrent user capacity, batch processing windows, query response times) | Peak transaction volumes occur during the early stages of an insurance company entering receivership; The timing of this is unpredictable as this is driven by external/unknown events. |
| Attachment 8 | Business Requirements | System Integration | Third-Party Systems | N/A | Beyond MS Dynamics, document management, and bulk mailers, are there other third-party systems that the new OLCP must integrate with (e.g., court filing systems, guaranty association platforms, state financial systems)? | UDS Data Mapper and OFAC. Please refer to Exhibit 5, Schedule IV-B DFS (Liquidation Claims Processing System Replacement), section VI. |
| Exhibit 3 | General Claims Process | Objection Process | Objection Volume | N/A | What is the typical volume and complexity of objections received per receivership estate? What percentage of claims typically receive objections requiring administrative or judicial review? | Objection complexity can vary greatly and is dependent on numerous unpredictable factors. As an example, one active receivership received objections on less than 1% of the claims filed against the estate. The data below represents 5 closed receiverships: |
Comp 1 - 1,759 claims presented, 4 objections received - 0.23% Comp 2 - 53 claims presented, 0 objections received - 0% Comp 3 - 30 claims presented, 0 objections received - 0% Comp 4 - 3,233 claims presented, 23 objections received - 0.71% Comp 5 - 33,606 claims presented, 57 objections received - 0.17% Exhibit 3 General Claims Process Proof of Claim POC Processing Volume N/A What is the typical volume of POC(Proof of Claim) forms received for a new receivership estate (range: small, medium, large estates)? What is the average processing time currently required per POC form? These averages are solely dependent upon the number of companies ordered into liquidation and the number of active receiverships at a given point in time, which is unpredictable. The information requested for active and prior receiverships is available via the DRL website. Processing times can vary based on active receiverships and available resources.
Link: https://www.myfloridacfo.com/division/receiver
| Exhibit 4 | Statutory Reference | Chapter 631 | Statutory Classes | N/A | Are there specific statutory class definitions or priority hierarchies beyond what is specified in Florida Statutes Chapter 631 that should be codified in the system (e.g., DRL internal policies, court precedents)? | No. |
| Exhibit 6 | Process Map | Claims Lifecycle | Process Variations | N/A | Do claims processing workflows vary significantly by insurance line of business (property, casualty, life, health, workers' comp, annuities)? If so, what are the key differences? | DRL claim processing is mostly uniform across all lines of business with some unique differences for specialty lines such as health. Specific workflow differences will be discussed during negotiations. |
| Section 1 | Background | Guaranty Associations | Data Exchange | 3 | What data elements are typically exchanged with guaranty associations? Are there standardized data formats or protocols currently used for this coordination? | Data elements can be found in the UDS manuals available through NCIGF. |
Link: https://www.ncigf.org/
| Section 1 | Background | Policy Records | Historical Archives | 3 | For closed receivership estates, what is the required data retention period? Should historical data be maintained in the active system or moved to a separate archive/data warehouse? | This is contingent on Data Governance. Certain data may need to be maintained within the active system and some data may need to be moved to a separate data warehouse. |
| Section 1 | Background | Scalability | Future Growth | 3 | What is the anticipated growth in receivership volume and policy records over the 5-year contract term? Should the system be designed to scale beyond current 14.8 million policy records? | Unable to provide estimated growth as it's dependent on uncontrollable and unknown factors. Additionally, of the 12 active estates, 7 of them were ordered into liquidation with in a 3 year period, 5 of them in an 18 month period. The system not only needs to be able to scale quickly, but also needs to be able to scale endlessly as we are unable to predict future liquidations. |
| Section 1 | Background | 3 | Does the Department intend for the solution to be based on a configurable commercial product, or are other solution approaches acceptable provided all requirements are met? | Other solution approaches are acceptable if all requirements are met. | ||
| Section 1 | Introduction | Contract Term | Post-Implementation Support | 3 | Beyond the initial 5-year contract term, what level of ongoing maintenance and support does DRL anticipate requiring? Should the solution include provisions for future enhancements and feature additions? | This is dependent upon the Respondent's proposed solution. Provisions for future enhancements and feature additions can certainly be included within the Response and optional/value-added services. Please see ITN Section 3.3, Contents of the Response. |
| Section 1 | Functional Requirements | 25-Oct | Are there any technology platforms, frameworks, or solution types that the Department prefers or does not support for this implementation? | No. Respondents' proposed solutions will be considered. | ||
| Section 1 | Claims Processing | 18-Dec | Can the Department clarify expectations regarding support for statutory claim classifications and distribution logic within the proposed solution? | Currently, DRL staff determine claim classification. This logic would be discussed with the awarded Contractor. | ||
| Attachment 1 | Performance Measures | Section 7(4) | 1 | Ahead does not provide a warranty for non-infringement of its services, but will agree to the proposed indemnication requirements. This should provide the Department with adequate protection. | Please note your exceptions in Volume 4: Contract Exceptions, as indicated in the ITN. | |
| Attachment 1 | Purchase Orders | Section (b), Terms | 4 | The resolution of terms, particularly when additional PO terms have not yet been disclosed, should not be those "most favorable to the Department" when there is no visibility as to what those terms may be. We propose the agreement and solicitation would control. | Please note your exceptions in Volume 4: Contract Exceptions, as indicated in the ITN. | |
| Attachment 1 | Events of Default | Section (c) | 5 | Striking "Failure to honor any term of the Contract". This language creates an event of default for every possible breach of the agreement. | Please note your exceptions in Volume 4: Contract Exceptions, as indicated in the ITN. | |
| Attachment 1 | Intellectual Property | Section (f) (request insertion) | 6 | Ahead requests the following langauge be included as it relates to third-party developed software or other third-party goods sold under this agreement: |
| 1. Third Party Software and Intellectual Property Licensing. The Department acknowledges that any software or other intellectual property included in or relating to Products is supplied by a third-party manufacturer or licensor (not Contractor). Contractor makes no representation or warranty with respect thereto any Product and will have no liability in connection with any such software or intellectual property related to Products. The Department agrees to comply with all third-party requirements, including with regard to proprietary and similar rights in and to any intellectual property (including any requirement to enter into a separate license agreement and prohibitions against duplicating or disclosing the same), even if Contractor has broken the seal on any “shrink wrapped” software. If the Department provides Contractor with any intellectual property, the Department warrants that it has all necessary legal rights to such property. The Department will indemnify Contractor against and hold it harmless from any and all liability, cost or expense arising from a breach or purported breach of this section. | Terms and conditions would be discussed during the negotiation phase of this ITN. Please submit your contract exceptions with your response as Volume 4: Contract Exceptions. | ||||||
| Attachment 1 | Guarantee of Parent Organization | 9 | Ahead's parent entity is not directly involved with the operations of its subsidiary entities and therefore does not agree to sign guarantees of this nature. | Terms and conditions would be discussed during the negotiation phase of this ITN. Please submit your contract exceptions with your response as Volume 4: Contract Exceptions. | |||
| Attachment 4 | Indemnifcation | Infringement indemnification for Products. | 16 | Ahead cannot provide indemnification for third-party manufactured hardware or third-party developed goods. We're comfortable providing this indemnification as it relates to Ahead services but request clarifications in either the definition of "Product" or in the indenmnity section (at the Departments' preference) to reflect this | Terms and conditions would be discussed during the negotiation phase of this ITN. Please submit your contract exceptions with your response as Volume 4: Contract Exceptions. | ||
| Attachment 4 | Limiation of Liability | 16 | Unless otherwise prohibited by relevant law, Ahead requires a cap on all damages in its agreements. While we appreciate the reasonable limitation proposed by the Department in the template, we'd like to propose a cap/hyper-cap structure related to Ahead's indemnification obligations. Ahead is very flexible as to the amount of this cap. | Terms and conditions would be discussed during the negotiation phase of this ITN. Please submit your contract exceptions with your response as Volume 4: Contract Exceptions. | |||
| Exhibit 5 | Budget | Figure 13 Baseline Budget | 38 | Is the budget included of $8.2 M, the budget that is allocated to the project? Can you please confirm the budget that will be alllocated to this project? | Of the total estimated project cost, there is $3,903,338 estimated for the solution vendor. Please refer to the Cost Benefit Analysis section of Exhibit 5, Schedule IV-B DFS (Liquidation Claims Processing System Replacement), Figure 13. The provided figure includes the following lines: Software Configuration, Software Subscription Fees, Data and Records Conversion, API Integration, and System Admin Training. | ||
| Section 3 | Technical Responses | 11 | There are page limits for response sections. If we include an attachment to explain more thoroughly, does that count in the page limit? | While attachments/appendices will not count towards the overall page limit, Respondents are to use attachments/appendices sparingly. Attachments should be concise and used to supplement the Response, not expand it. An example is using attachments for diagrams, flow charts, or other visual aides. Please note, additional attachments and appendices will not be provided to the evaluation team for scoring purposes. | |||
| How many open claims are in the current system that will need to be migrated to a new system? | 14.8 million policies & related claims are all active receivership estates. | ||||||
| Is there any requirement to migrate closed claims? | Yes. | ||||||
| Attachment 8.xlsx | Business Process | General Company Setup | Gen-8 | To be clear, the system will need to store information about an insurance company in receivership that will be tied to claims entered, or imported into the new system, at a later date? | Yes. | ||
| Attachment 8.xlsx | Business Process | General Company Setup | Gen-13 | Can you elaborate on this requirement? For example, what type of claim data would be sufficient to all for a NOD option to be availble? Or, what is the mininum claim data that needs to be present? | This requirement describes the sequencing of DRL claims process. The example given in the requirement describes that an NOD field should be greyed out if claims have not been loaded yet. This is because a NOD would not be issued prior to claims data being loaded and an ICR being approved by the court. For further detail, please refer to Exhibit 5, Schedule IV-B DFS (Liquidation Claims Processing System Replacement), section B. Baseline Analysis. | ||
| Attachment 8.xlsx | Business Process | Data Entry & Transaction Processing | Dat-40 | Can you elaborate, or give an example of a transaction that would block a transactioin in a different module? What different modules are you referring to? | Hypothetically, if a proposed Respondent solution included various modules for intake and payments, it would have Intake accept claims immediately and enqueue payment work to run asynchronously (with retries, rate limits and fallbacks) so a Payments outage won't block Intake. | ||
| Attachment 8.xlsx | Business Process | Data Entry & Transaction Processing | Dat-42 | Can you elaborate, or give an example of a template that you would like to use? | Templates include various worksheets used for evaluations, form letters, and other notices. |
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 .