RFP 120277 O3 Vital Records Management System Q&A Addendum Two.docx
DOCX document 53 KB Posted
- Attached to
- Vital Records Management System
- Solicitation number
- 120277 O3
- Issued by
- Douglas County, Nebraska
About this file
This is an Addendum Two Q&A document issued by the Nebraska Department of Health and Human Services (DHHS) for RFP 120277 O3 regarding a Vital Records Management System, with responses due December 20, 2024, at 2:00 PM CST. The solicitation seeks a vendor-hosted, web-based Vital Records Management System that must include modules for birth, death, marriage, fetal death, dissolution of marriage, and induced terminations of pregnancy, with all modules required to be in UAT within 12 months and production within 15 months following kickoff. The system must provide 24x7x365 support for critical issues and include concurrent access capabilities, data conversion of existing records, and integration with various interfaces including OVS and FHIR messaging.
The current environment consists of a 15-year-old hybrid application built by Netsmart Technologies, with a SQL database of approximately 164GB containing 10 million records and 3,376 table columns. The State will provide its own payment processing system and credit card processor. While the budget is not disclosed, the implementation costs must be structured with 40% allocated to implementation deliverables and 10% to design and configuration. The system must be hosted on a public cloud, and while COTS software intellectual property can remain with the vendor, a royalty-free perpetual license must be provided to the State.
View the file
Other files
Show 40 more
50 files listed here. See the rest on GovTribe.
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
SOLICITATION ADDENDUM TWO
QUESTIONS AND ANSWERS
Date: 12/02/2024
To: All Bidders
| From: | Dhinesh Santhakumar |
| Department of Health and Human Services |
RE: Addendum for 120277 O3 to be opened December 20, 2024, at 2.00 p.m. CST
Questions and Answers
Following are the questions submitted and answers provided for the above-mentioned solicitation. The questions and answers are to be considered as part of the solicitation. It is the responsibility of bidders to check the State Purchasing Bureau website for all addenda or amendments.
| Question Number |
| RFP/ITB |
Section Reference
RFP/ITB
Page Number
| Question |
| State Response |
| 1. |
| Document 12077 03 RFP Vital Records Management System, Section Z Liquidated Damages, Table 1 the first item. |
| Page 15 |
| The implementation schedule for all modules (birth, death, marriage, fetal death, dissolution of marriage, induced terminations of pregnancy and associated order processing for each vital event) within 12 months to be in UAT, and to be in production in 15 months, is very aggressive. There are numerous items that could delay the project, such as getting access to the current data in a proper format, the State making timely decisions with no delay to revisit the decision due to the schedule, and many others. We would much rather deliver a vital records solution that is the best solution for the State, rather than one that is hurried throughout every step to meet an arbitrary deadline. With the State currently having a 15-year-old hybrid application, many new business methods to performing the State’s work should be reviewed, analyzed, and decided upon by the State. This schedule only allows for very limited time to revisit the current business methods. Will the State consider alternative timelines, and or staggered roll outs of modules? If not, does the State accept that every delay caused by the State and/or external entities not under control of the vendor (such as SSA, NCHS, NAPHSIS, etc.) will delay the schedule and the application of liquidated damages? |
| No, the State will not accept an approach with staggered roll outs of modules. |
The State will consider all relevant circumstances in assessing liquidated damages.
| 2. |
| Document 12077 03 RFP Vital Records Management System, Section Z Liquidated Damages, Table 1 Data Movement. |
| Page 16 |
| The item states: The Critical Incident pertains to any interfaces required by the Vital Records Unit, such as the interface with the Online Verification System (OVS) or Fast Healthcare Interoperability Resources (FHIR) messaging at any point following system implementation. The State is imposing liquidated damages for items outside the control of the vendor. The Vendor does not maintain the interface with OVS, the FHIR interface, or any other third-party interfaces that the Vital Records Unit may require. Therefore, we cannot ensure their availability for the Vital Records Unit. Additionally, based on the numerous recent death FHIR changes, and the fact that the birth FHIR is not in production anywhere at this time and is only in initial testing, we cannot be held responsible for the FHIR interfaces being available to the Vital Records Unit. Will the State eliminate this requirement? |
No, the State will not eliminate this requirement. The State expects this requirement to be applicable to only vendor related issues.
| 3. |
| Document 12077 03 RFP Vital Records Management System, Section Z Liquidated Damages, Table 1 all of it. |
| Page 16 |
| Will the State accept alternate, reasonable liquidated damages in lieu of these uncapped liquidated damages? If not, will the State at least consider a reasonable cap on the damages, such as the total cannot exceed 20% of the contract awarded? |
| No, the State believes that the amounts specified for liquidated damages are reasonable. |
| 4. |
| Attachment 2, Row 23 Ref: 1.2.5 |
| Tab Functional Specifications |
| The system should provide functionality to disallow any other screen shot tool, such as the “Snipping Tool” or the like. The is requesting a web based vital records application, and as such a web browser must be utilized. At this time there are no known solutions for a browser to disable or prevent a snipping tool, screen shot, or other similar tools from executing against the browser. Did the State have some specific solution in mind to be able for the vendor to comply with this requirement? |
No, the State does not have a specific solution in mind. This is a desire rather than a necessity.
| 5. |
| Attachment 2, Row 33 Ref: 1.3.1 |
| Tab Functional Specifications |
| The system must have the ability to complete a data conversion of all existing data, including images and files. To confirm that images can be converted, and to be able to estimate the level of effort to convert them, we must know how the current images are stored. For example, if they are stored in a proprietary format, they may not be able to be converted. Can the State confirm the type of images they want converted, such as TIFFs, JPEG, database blobs, etc.? |
| Yes, the State can confirm that the files are not stored in a proprietary format. Most of the images are TIFFs, some are JPEG, PDF, PNG, etc., and database blobs. |
| 6. |
| Attachment 2, Row 64 Ref: 2.2.4 |
| Tab Functional Specifications |
| The system must enable concurrent access to a single record by multiple users without conflicts or the need for file, record, or field locking. Additionally, this is a gold star requirement which is pass or fail. If the application allows multiple users in the same record concurrently, neither user will be aware of changes being made by the other user at the same moment. The introduction of concurrent users to the same field at the same time will introduce update clashes that are never 100% resolvable due to the inherit nature of 2 people updating at the exact same time. Optimistic concurrency control (or locking) can be introduced to alleviate the issue, however even that requires roll backs of locks and for the user to restart their update process, in addition to introducing additional overhead to each transaction. We have developed alternatives to concurrent use, where limits on the time a user can keep a record locked and ensuring users can do their work in a reasonable time with the overhead and issues of concurrent access. Will the State consider removing this requirement as a gold star requirement and allow vendors to propose reasonable alternatives? |
| No the State will not remove this requirement. Concurrent access is necessary. Additionally the state expects the ability to concurrent updates based on the role-based security. The State expects the system to be able to handle various use cases, such as a physician entering medical information at the same time a funeral director is entering demographic information for a single record. At no point should any record be locked out of access for any user role that should have access. |
| 7. |
| Attachment 2, Row 82 Ref: 2.2.6 |
| Tab Functional Specifications |
| The system should allow a user with necessary access the ability to view more detailed information on any field when appropriate. Typically, a user either has read/write, or just read, access to a field. If a user can read the field typically this means they view all the data on the field. Can the State give an example of “view more detailed information on any field when appropriate”? |
| Yes, such example is that a super user can view the metadata (e.g., table name, field name, validation table, etc.) of a specific field. |
| 8. |
| Attachment 2, Row 138 Ref: 5.1.1 |
| Tab Functional Specifications |
| The system must contain all existing and future records or orders with any associated images and/or attachments synchronously. Can the State provide additional clarity to this requirement? Is this requirement the same as the system must continually maintain all records and orders, with associated images? |
| Yes, all past, present, and future records and/or orders must be maintained with associated images (i.e., there is no secondary program to access historical images). |
| 9. |
| Attachment 2, Row 192 Ref: 5.7.3 |
| Tab Functional Specifications |
| The system must contain a universal queue for each module. Can the State provide additional information about what a universal queue is? Can the State provide an example of a universal queue? |
| The state acknowledges that Attachment 2, Row 192 Ref: 5.7.3 is ambiguous, therefore it is being removed as a requirement. No new Attachment 2 – Functional Specifications will be posted. Therefore, bidders may respond within this respective row as follows: |
“As per Addendum Two, this requirement has been removed.”
| 10. |
| Attachment 2, Row 270 Ref: 13.1.5 |
| Tab Functional Specifications |
| The system must link the order to an invoice and payment. Does the State provide invoices prior to collecting payment for services to allow the payment to be linked to an invoice? If not, how would the payment and invoice be linked if the payment is made and then the invoice generated? |
| The Invoice should be generated after the transaction is logged in the system, regardless of payment being billed or received for the service. |
| 11. |
| Attachment 2, Row 314 Ref: 13.1.5 |
| Tab Functional Specifications |
| The system must provide a print queue including Document Control Number for review and approval statuses. Can the State provide additional information about this requirement? For example, is this a queue that lists items to be printed, or that were printed? Also, what is the approval status that is being reviewed? If this queue is presented prior to the document being printed, how can the document control number be provided? Typically, the document control number is assigned when the document is printed, or is this a queue of printed documents and thus the control number is available? |
| Yes, this should be a work queue that lists items to be printed. From this work queue the Unit will review and approve the request and print the document with a sequential Document Control Number as assigned by the system. The system must have the capability to store the Document Control Number in the database. |
| 12. |
| Section (III)(I) |
| 19 |
| Is there flexibility on the ownership requirement for deliverables under the contract? A COTS vendor would typically retain IP ownership (excluding client data) but provide a royalty-free, perpetual license. Would this be acceptable, or is exclusive ownership by the State required? |
| Intellectual property ownership of commercial off-the-shelf software is not expected, provided a royalty-free, perpetual license is given to the State. |
| 13. |
| Section (VI)(A)(4)(i) |
| 44 |
| With reference to Section (VI)(A)(4)(i) of the RFP, does the State expect the vendor to provide hardware as part of the proposed solution? |
| No, the State does not require that the vendor is to provide hardware as a part of the proposed solution. |
If bidder’s proposed solution does not have capability to offer a Kiosk and/or Credit Card machines, this needs to be clearly indicated as such within the respective “Vendor Response” column for 13.10.1 and/or 13.10.2.
If specialized, fully integrated hardware is part of the bidder’s proposed solution, depending on if the hardware will be owned or leased, the bidders shall express such costs based on the following:
If bidder’s solution reflects that the State will own the hardware, the bidder shall embed the cost of owning the hardware within the “Implementation” deliverable category of the Cost Sheet for the Kiosk and/or Credit Card machines.
The total for the “Implementation” deliverable category must remain at 40% of the total cost for Part I.
Any ongoing costs such as, but not limited to, maintenance shall be reflected in Part II of the Cost Sheet for each respective year of Support, Maintenance, and Operations and Part III - Optional Renewal for Support, Maintenance, and Operations.
If bidder’s solution reflects that the State will be leasing the hardware, then all costs associated with leasing and maintenance shall be reflected in Part II of the Cost Sheet for each respective year of Support, Maintenance, and Operations and Part III - Optional Renewal for Support, Maintenance, and Operations.
Bidder to indicate within the respective specifications within Attachment 2 – Functional Specifications “Vendor Response” whether their solution includes hardware for a Kiosk or Credit Card machines respectively. The response to also indicate if the solution being proposed reflects that the State will own or be leasing hardware.
Bidders shall not just merely indicate that the hardware is available at an additional cost. Any associated costs are to be expressed as indicated above.
Bidders shall note that the following system modules and specifications for 13.10.1 and 13.10.2 within Attachment 2 – Functional Specifications have been revised and shall now read as follows:
13.10.1 The vendor’s solution should provide and maintain a Kiosk for the state to process vital record orders and payments for customers.
13.10.2 The vendor’s solution should provide and maintain three (3) Credit Card machines for the state to process payments for customers.
| 14. |
| Section (VI)(A)(4)(j)(c)) |
| 46 |
| Could you please clarify if the requirement for 24x7x365 support for all critical system failures or issues is a strict and non-negotiable expectation? If our company does not have a 24x7 support desk, nor one that includes weekends and holidays, and we want to understand if alternative support arrangements would be considered. |
| Yes, this is non-negotiable expectation and the requirement shall remain as written. |
State expects that if the system encounters a critical failure (complete outage), the Unit would be able to communicate with the selected vendor at any time. If the selected vendor intends to use any alternative support arrangements/sub-contractors, it must be properly disclosed in the Solicitation Response with respective sections.
| 15. |
| Section (VI)(E)(2)(c) |
| 49 |
| Considering the critical nature of achieving a fully accessible production environment within the specified fifteen (15) months following the 'Kick-off' meeting, is there a provision or flexibility within the agreement that would allow both parties, through mutual consent, to extend this deadline? |
| See sections (II.) (F.) and (G.) of the Request for Proposal regarding reasonable amendment, change orders, or substitutions. |
| 16. |
| Section (VII)(A)(1)(h) |
| 51 |
| Could you clarify if we are allowed to submit more than three past projects for Section (VII)(A)(1)(h)? |
| No, as per the language outlined in the Request for Proposal document, section (VII)(A)(1)(h), “The bidder shall provide a summary matrix listing three (3) previously implemented state-level |
Vital Record Management System projects which are similar to this Solicitation in size, scope, and complexity.”
| 17. |
| Attachment 2- |
1.3.1
| 1 |
| Is there any specific requirement for database? Is SQL ok? |
No, there is no specific requirement for the database. Therefore, yes, SQL can be used for the database.
| 18. |
| VI.A.1- |
Scope of Work
| 30 |
| Does the state have a credit card processor or will the vendor supply the connection? |
| Yes, the State currently has a credit card processor, and it will continue to be provided by the State. |
Payment processing will be handled by the State. Any associated fees with processing the payment would come from the State’s provider for processing the credit cards.
| 19. |
| VII.A.1.b-Financial Statements |
| 50 |
| If the bidder is a privately held company would copies of the prior 2 years filed tax returns meet the requirement for this section? |
| No, copies of the prior 2 years filed tax return would not meet the requirement. Section (VII)(A)(b) paragraph two of the Request for Proposal document provides the following instructions If the bidder is not a publicly held corporation: “If the bidder is not a publicly held corporation, either the reports and statements required of a publicly held corporation, or a description of the organization, including size, longevity, client base, areas of specialization and expertise, and any other pertinent information, should be submitted in such a manner that solicitation evaluators may reasonably formulate a determination about the stability and financial strength of the organization. Additionally, a non-publicly held firm should provide a banking reference.” |
Bidders are strongly encouraged to provide the requested information to enable the evaluators to have appropriate content to be evaluated in accordance with the criteria set forth in this respective section.
| 20. |
| Attachment 3-ARCH-2 |
| 2 |
| Is the State open to the system being hosted in an environment that is not cloud-based? |
| No, the State requires the system to be hosted on a public cloud. |
| 21. |
| 2. Project Environment a. |
| 30 |
| Who built the existing VRMS? |
| Netsmart Technologies built the existing VRMS. |
| 22. |
| 2. Project Environment a. |
| 30 |
| Is there any current vendor supporting the VRMS? |
| Yes, the state currently has a vendor supporting the VRMS. |
| 23. |
| f.ii.a. Data Inventory |
0.
0.
| 40 |
| Can state provide the list of Data sources in scope for migration? With details such as: |
· Size of source database
· Number of tables
· Number of columns in each table
· Number of records Any additional details that will help vendors to estimate the migration efforts.
Yes, the current data source is SQL.
-The size of source database is 164GB.
-The number of tables cannot be provided as they are vendor specific.
-The current table column count is 3,376.
-The estimated number of Records is 10,000,000. Please note the number of records is an estimate as the number of records continues to increase daily.
| 24. |
| Attachment 3: ARCH-4* |
| 3 |
| In the "120277 O3 Cost Sheet," where should vendors list the costs associated with hosting during the Year One of the initial term? |
| Any cost associated with hosting shall be embedded within the “Design and Configuration” deliverable category within the Cost Sheet. The total for Design and Configuration must remain at 10% of the total cost for Part I. |
| 25. |
| Attachment 3: SPC-6 |
| 5 |
| Is state intend use State’s IDentity Management (IDM) solution (i.e. SSO)? |
| No, the State does not intend to use the State’s IDM. |
| 26. |
| Schedule of Events |
| 2 |
| Please confirm that bidders should join the Electronic Submission Opening December 20, 2024, at 2:00 PM |
Central Time Bidders are not required to join the Electronic Solicitation Opening – Online Via WEBEX. Bidders may elect to not attend the event, attendance is optional.
| 27. |
| Attachment 2 - Functional Specifications |
13.7 Payments
13.7.1 Does the State intend to use its own payment processor?
The State currently has a credit card processor, and it will continue to be provided by the State.
28.
How many total users would need to have a license to access the new vital records management system?
0. How many internal?
0. How many external?
See Attachment 2 - Functional Specifications 1.2.9 and Attachment 2 - Functional Specifications 1.2.10.
29.
What is the overall budget for the purchase of this solution across 5 years?
The budget information is not being provided. Bidders are highly encouraged to submit their best pricing.
30.
| Clearly defined is the ideal contract execution date of 3/18/25, what is the expected “build timeline”, i.e. when is the project expected to be “launched”? |
| See (VI)(E)(2) of the Request for Proposal document - Due Dates and/or Completion. |
This addendum will be incorporated into the solicitation.
SPB Form 26 Effective 7-19-2024
File details come from the government source that posted it. Updated .