Bid_Amendment_-_EVT0010848_-_Bid_Amendment_2.pdf

Office of Procurement and Contracts Phone: 785-296-2376 900 SW Jackson St., Room 1001 North Fax: 785-296-7240 Topeka, KS 66612 www.admin.ks.gov/procurement-and-contracts

Adam C. Proffitt, Secretary Laura Kelly, Governor Todd Herman, Director

Amendment

Request for Proposal

Date: July 31, 2026

Amendment Number: 2

Event Number: EVT0010848

Closing Date: August 27th, 2026, 2:00 PM CST

Procurement Officer: Tyrone Gasper

Telephone: 785-296-3126

E-Mail Address: Tyrone.Gasper@ks.gov

Agency: Kansas Department of Health and Environment

Item: Web-Based Preparedness Application

Conditions: 1) Answers to submitted questions follow on page two (2) of this document.

2) Bidder questions round 2 are due by 5:00pm CT August 7th, 2026. Responses to questions will be posted by addendum.

A signed copy of this Addendum must be submitted with your bid. If your bid response has been returned, submit this Addendum by the closing date indicated above.

I (We) have read and understand this addendum and agree it is a part of my (our) bid response.

NAME OF COMPANY OR FIRM:

SIGNED BY:

TITLE: DATE:

It shall be the vendor's responsibility to monitor this website on a regular basis for any changes/addenda.

http://admin.ks.gov/offices/procurement-contract http://www.admin.ks.gov/procurement-and-contracts mailto:Tyrone.Gasper@ks.gov http://admin.ks.gov/offices/procurement-contract

Event ID: EVT0010848

EVT0010848 – Amendment 2

Web-Based Preparedness Application

Questions and Answers

Q1: The RFP references BCHS’s current use of a cloud application for bed tracking and a separate ICS platform. Is the intent of this procurement to replace both existing systems, or would a single unified platform that covers both functional areas be evaluated favorably?

A1: BCHS is seeking a solution for each system.

Q2: Requirement A4 specifies 5,000 concurrent users for Incident Management and D4 specifies 2,000 for Bed Availability. Can BCHS clarify the expected breakdown of user types — for example, state-level administrators, hospital staff, local health department personnel, and EMS partners — and whether those user pools overlap between the two components?

A2: State-level administrators and local users will need to have the ability to use both components. Provide a description indicating whether you have set user types/roles for each component, and/or whether we can create customized user types/roles as needed.

Q3: For the Bed Availability component, will BCHS serve as the primary system administrator configuring resource views and managing the facility database, or is the expectation that individual healthcare facilities will self-administer their own accounts and data entry?

A3: BCHS is the primary system administrator; facility users will maintain facility data.

Q4: Requirement C8 asks for an HVA (Hazard Vulnerability Assessment) that is completable and downloadable. Can BCHS clarify whether there is a specific HVA methodology or template format preferred — for example, the Kaiser Permanente model or a state-specific template — or will the vendor’s standard HVA format be acceptable?

A4: Vendor’s standard HVA format is acceptable.

Q5: Requirement F11 calls for the ability to create “ad-hoc and standard event prompts” to collect point-in-time facility data. Can BCHS describe what a typical event prompt looks like in their current workflow — for example, is this a scheduled check-in form, a triggered survey during an incident, or both?

A5: BCHS wants the ability to create prompts to collect point-in-time facility data for both ad-hoc events and standard event templates.

Q6: Requirement G1 describes API support for automating bed availability data from hospital EHR systems. Does BCHS expect HL7 FHIR-based API integration, or are other data exchange formats and standards acceptable for the initial contract period?

A6: API integration is optional. HL7 is desirable but other options including SFTP and ADU are acceptable. Restricted information is outside the scope of this project.

Q7: Will BCHS be coordinating directly with the hospital systems to establish API access, or is the vendor expected to negotiate access with individual hospital IT departments independently?

A7: Vendor will work directly with hospitals to configure API access.

Q8: The RFP requests a vendor-proposed implementation timeline but does not specify a required go-live date. Does BCHS have a target date when the system needs to be live in production — for instance, ahead of a specific grant reporting cycle or a planned exercise?

A8: Go-live date: July 1, 2027

Q9: Will BCHS provide a list of participating healthcare facilities prior to contract award, or will that be shared during onboarding? This affects how we estimate user provisioning, facility account setup, and initial data loading.

A9: No, it will not be shared prior to contract award.

Q10: Regarding the pilot testing phase, does BCHS have a specific region or subset of facilities in mind for the pilot, or is the expectation that the demo environment covers the full statewide scope from day one?

A10: BCHS will facilitate a representative sample for pilot testing.

Q11: Requirements B10 and E10 specify that all data must remain in the United States. Does this restriction extend to vendor support personnel — specifically, are there limitations on support staff located outside the U.S. accessing the system for troubleshooting or configuration purposes?

A11: Related to Q86, Q112.

5.j Contractor shall ensure that all AGENCY Production Data remains in the United States of America. Contractor shall further ensure no Production Data is accessed by Contractor employees, contractors, or any other authorized individual located outside of the United States.

5.k Contractor shall ensure that all AGENCY Non-Production Data remains in the United States of America. Contractor shall further ensure no Non-Production Data is accessed by Contractor employees, contractors, or any other authorized individual located outside of the United States.

Q12: The Data Security Attachment references SOC 2 and NIST 800-53. Does BCHS require FedRAMP or StateRAMP authorization, or is documentation of SOC 2 compliance and NIST 800-53 alignment sufficient for contract award?

A12: FedRAMP or GovRAMP authorization is not required.

Q13: The Data Security Attachment requires breach notification within 12 hours. Can BCHS confirm whether this applies to all security events or only confirmed breaches involving KDHE data?

A13: Related question Q113. Section 7.b. KISO’s web site https://www.ebit.ks.gov/divisions/information-security-office-kiso/resources/incident-reporting

FAQs include the reporting time frames. These apply to all security incidents, not just KDHE data.

• Any public entity shall report within 12 hours after the discovery of the incident.

• Any government contractor that has a significant cybersecurity incident must report within:

o 72 hrs. after the government contractor reasonably believes a significant cybersecurity incident has occurred; or o 12 hrs. if a determination is made during the investigation that such information, network or systems operated by or on behalf of the State were directly impacted.

Q14: Do you have a cyber security resource on your team or a consultant A14: KDHE has the KISO office and access to an ISO, as well as cybersecurity resources within the

IT department.

Q15: What time do you expect after a security breach.

A15: Related to Q113, Q153. Section 7.b of the security attachment says that within a reasonable time frame of the incident, a plan must be submitted to the Agency for reducing the likelihood of recurrence.

https://www.ebit.ks.gov/divisions/information-security-office-kiso/resources/incident-reporting

Q16: Do you need the vendor to carry additional cyber security insurance, if yes, amount?

A16: This is not required.

Q17: Please provide a list of outages of your system over the past three years.

A17: This information is not available

Q18: Do you want the application performance to be monitored A18: No

Q19: The cost sheet requests a fixed implementation price through go-live. Should implementation costs include end-user training for both BCHS staff and individual facility administrators, or is training for facility-level users scoped separately?

A19: Cost should include a set amount of hours of training for BCHS staff and facility administrators.

Q20: The base contract is three years with two optional one-year renewals. Will annual pricing be held flat across all five years, or does BCHS expect pricing locked at Year 3 rates for the optional renewal periods?

A20: Budget Information is not available.

Q21: For the annual license structure, is BCHS expecting flat statewide licensing, or are they open to tiered pricing based on number of active participating facilities or user tiers?

A21: Flat pricing is required.

Q22: We request a two-week extension to the proposal submission deadline to allow us to provide the strongest possible response.

A22: Any modifications to the bid event will be posted in the form of addenda.

Q23: Please identify the current emergency management software platform/provider and clarify whether the current provider is eligible to submit a proposal under this solicitation.

A23: Yes

Q24: When does the contract with your current software vendor end?

A24: The desired contract start date is 1/1/2027

Q25: Will you disclose the Purchase Order or Contract number of your current/previous software contract?

A25: This information cannot be shared

Q26: Did a consultant assist with requirements gathering or development of this RFP? If so, please identify the consultant and confirm whether they are precluded from responding to this solicitation.

A26: No, a consultant did not assist with requirements gathering or development of this RFP.

Q27: What features or tools would your organization and stakeholders like that are not available from the current vendor?

A27: No gaps identified

Q28: Are there specific challenges or gaps with the current software that your organization is looking to address with a new system?

A28: No gaps identified

Q29: Which key workflows, forms, or processes must be migrated from the current vendor solution to the new software, and which must be newly created?

A29: Existing solution data will not need to be migrated.

Q30: Will existing solution data need to be migrated to the new platform? If so, please specify the expected data volume and file or data formats.

A30: Existing solution data will not need to be migrated.

Q31: RFP Sections A and D, as well as Sections B and E, appear duplicative. Could the State, please clarify how vendors should address this?

A31: These sections address two separate applications.

Q32: Requirement A4 states that the application must support 5,000 concurrent users, while Requirement D4 states 2,000 concurrent users. Please clarify the expected concurrent user levels for normal operations and for large-scale public health emergencies.

A32: 5,000 is for incident management and 2,000 is for bed availability

Q33: Are vendors required to complete the Security Questionnaire with their proposals, or will only the selected vendor complete it after award? Vendors are typically reluctant to provide detailed security information during a public proposal process without a confidentiality agreement, as the information is sensitive and could be valuable to malicious actors if made public.

A33: It needs to be submitted with all proposals.

Q34: If a vendor can provide standard software security certifications and compliance documentation, such as ISO 27001 or NIST 800-53, through a secure web portal, would that be an acceptable alternative to completing the Security Questionnaire?

A34: The Security Questionnaire must be completed.

Q35: Regarding the Architecture Document, we typically require a confidentiality agreement / NDA to provide detailed architecture and security documentation; would it be acceptable for vendors to provide the State a secure link or portal access to these documents.

A35: Links will not be accepted. Please refer to section 1.17 Disclosure of Proposal Content and

Proprietary Information.

Q36: If this project is partially or wholly grant funded, will you disclose the name of the grant or contract vehicle?

A36: This project is wholly funded through the Department of Health and Human Services Hospital

Preparedness Program cooperative agreement.

Q37: Do you have a general budget or target price range for this project? Sharing this information would help vendors propose features and services that align with your scope and expectations.

A37: Budget information is not available

Q38: What is the expected project start date?

A38: January 1, 2027

Q39: What is the expected project completion or system go-live date?

A39: July 1, 2027

Q40: Please clarify your expected implementation timeline following contract award and whether you anticipate a phased implementation approach (e.g., core deployment followed by integrations, training, or jurisdiction onboarding phases).

A40: Please complete the timeline based on your standard implementation process.

Q41: Do you prefer a cloud-hosted solution (SaaS), a traditional on-premises solution, or a hybrid solution?

A41: Cloud-hosted solution

Q42: What format do you prefer for training (virtual, onsite, video, etc.)?

A42: No preference

Q43: How many users will the vendor be expected to train in each category, such as end-user training, administrator training, and train-the-trainer sessions?

A43: 4-6 Administrators and train-the-trainer sessions up to 20 individuals, with provided training materials preferred.

Q44: Please identify your current identity management environment and preferred SSO technologies (e.g., Microsoft Entra ID/Azure AD, Active Directory Federation Services, Okta, or other providers).

A44: We don’t require anything for vendor systems. Expectation would be for vendor to supply login verification system appropriate to types and volume of users. Must incorporate MFA, and account and password management must follow SOK standards as defined in ITEC-7230-A.

Q45: Is the platform expected to store, process, or exchange Criminal Justice Information System (CJIS) data, HIPAA-regulated information, law enforcement-sensitive information, or other regulated data sets that would require comparable compliance standards?

A45: No

Q46: Can vendors include additional content such as an appendix with diagrams/graphics to help illustrate our narrative responses? Will an appendix be included in the page count limitation (if applicable)?

A46: Vendors can submit this additional content with their bid proposal. There is no page count limitation for this bid event.

Q47: Is your organization eligible to purchase products from GSA Multiple Award Schedule (Schedule 70)?

A47: This is an independent bid event in which bidders are expected to submit a response per the requirements of the RFP.

Q48: The RFP does not specify an anticipated contract award date or evaluation period. Can KDHE provide an expected award date and approximate go-live target so vendors can plan staffing and implementation resources?

A48: Contract start date January 1, 2027, and go live target July 1, 2027

Q49: The EHR API integration (Item G1) is listed as optional. Can KDHE identify anticipated EHR systems or interoperability standards (e.g., HL7 FHIR, Epic, Cerner) to allow accurate scoping and pricing?

A49: API integration is highly desirable. HL7 is desirable, but other options, including SFTP and ADU, are acceptable. PHI information is outside the scope of this project.

Q50: The cost sheet spans a 3-year base plus two 1-year option periods. Must pricing be held firm for all five years, or may vendors propose escalation clauses tied to CPI or similar indices for option years?

A50: Budget information is not available.

Q51: The RFP prohibits per-seat or per-use licensing fees. Does this prohibition also apply to fees based on the number of organizations or jurisdictions onboarded, or only to individual user counts?

A51: Yes, this prohibition also applies to fees based on the number of organizations or jurisdictions onboarded

Q52: The RFP requires SOC 2 and NIST 800-53 documentation. Does KDHE require SOC 2 Type I or Type II? And what is the minimum NIST 800-53 baseline required — Low, Moderate, or High?

A52: We require SOC 2. The NIST baseline would be moderate.

Q53: Is there an incumbent vendor currently providing these services to KDHE? If so, will the new vendor be responsible for historical data migration, and will the incumbent be required to cooperate in the transition?

A53: Existing solution data will not need to be migrated.

Q54: Given the 20 MB email attachment limit and the volume of required documents (including the 82-question security questionnaire), will KDHE accept a secure file-sharing link (e.g., SharePoint, Box) as an alternative for oversized submissions?

A54: OPC does not accept secure file-sharing links or zip files for this bid event.

Q55: How many healthcare facilities (hospitals, clinics, long-term care, etc.) are expected to be onboarded into the Bed Availability platform statewide How many distinct organizational tenants (state, regional, local health departments) will need separate administrative access within the system? How are the regional/district boundaries defined for Kansas are these aligned with existing KDHE public health regions, emergency management districts, or a custom geographic structure. Could you please share more information on this.

A55: BCHS estimates approximately 500-700 unique facilities, organized in a custom geographic structure.

Q56: Is there an incumbent vendor currently providing either the ICS or bed management platform, and will transition/data migration from that system be required?

A56: Existing solution data will not need to be migrated.

Q57: What is the expected volume of simultaneous active incidents the system must support (requirement C4 references managing multiple incidents simultaneously)?

A57: Each facility should be able to have an active incident.

Q58: Does BCHS require the ICS to support pre-defined incident templates (e.g., pandemic, mass casualty, natural disaster) or will all incident types be built from scratch by administrators?

A58: BCHS requires the ICS to support pre-defined incident templates that can be customized by facilities.

Q59: Is the Hazard Vulnerability Assessment (requirement C8) expected to follow a specific methodology or scoring framework A59: Vendor’s standard HVA format is acceptable.

Q60: What Essential Elements of Information (EEI) are currently being collected, is there an existing data dictionary or field list KDHE can share?

A60: This information is not available.

Q61: Is the EHR API integration (G1) expected to be bidirectional or read-only pull from hospital systems?

A61: Read-only pull.

Q62: How frequently does KDHE expect bed availability data to be refreshed, real-time, hourly, or on-demand during activations only?

A62: At a minimum, on-demand with additional frequency through automation.

Q63: Are facilities expected to self-report data manually in addition to or instead of automated EHR feeds?

A63: In the absence of automation, facilities can self-report data manually.

Q64: Is there an existing identity provider (IdP) such as Active Directory or an SSO platform that the system must integrate with for MFA A64: Related to 464, Q91, Q105, Q132

We don’t require anything for vendor systems. The expectation would be for the vendor to supply a login verification system appropriate to the types and volumes of users. Must incorporate MFA, and account and password management must follow SOK standards as defined in ITEC-7230-A.

Q65: What is KDHE's expected go-live timeline, is there a hard deadline driven by preparedness exercise cycles A65: Go-live date: July 1, 2027

Q66: Can KDHE confirm whether there is an incumbent vendor (or vendors) currently providing the Incident Management and Bed Availability platforms? If so, can you please identify the vendors?

A66: This information is not available.

Q67: What applications are currently supporting the Incident Management and Bed Availability functions? For each application, what primary business or technical limitations prompted this procurement?

A67: This information is not available.

Q68: Is KDHE seeking a single integrated platform, or will proposals consisting of two tightly integrated commercial applications be evaluated equally?

A68: Make sure to include the functional requirement table(s) in your submission. The Application for incident management and the Application for bed availability will each be evaluated separately.

Q69: How will technical capability versus cost be balanced during evaluation? Are there any evaluation factors that carry greater weight despite not being numerically weighted?

A69: Please refer to Section 1.14 Evaluation of Proposals.

Q70: Will oral presentations, demonstrations, or scripted use-case scenarios be part of negotiations or finalist evaluations?

A70: Reference Section 1.14 Evaluation of Proposals and Section 1.5 Appearance Before Committee.

Q71: Has funding been fully appropriated for this procurement? If so, can KDHE provide an estimated implementation budget or not-to-exceed amount?

A71: Budget information is not available.

Q72: Since per-user licensing is prohibited, does KDHE prefer enterprise, organizational, facility-based, or transaction-based pricing?

A72: Flat licensing is required. Enterprise or organizational is preferred over transaction-based.

Q73: Can KDHE describe the primary business, operational, or technical drivers that led to this procurement?

A73: This information is not available.

Q74: Approximately how many organizations (hospitals, local health departments, EMS agencies, emergency management organizations, etc.) and total user accounts will be onboarded at contract start?

A74: Onboarding will be conducted on a rolling basis.

Q75: Can KDHE provide estimates for:

* number of facilities

* number of healthcare systems

* regional organizations

* annual incidents

* annual exercises

* expected notification volumes (email/SMS)

A75: BCHS estimates approximately 500-700 unique facilities, organized in a custom geographic structure.

Q76: What specific data elements are currently collected within the existing Bed Availability platform that vendors must migrate or support?

A76: Existing solution data will not need to be migrated.

Q77: For the Incident Management component, are there existing incident plans, ICS forms, workflows, or templates that vendors are expected to migrate into the new system?

A77: Existing solution data will not need to be migrated.

Q78: Are there minimum mobile device support requirements (iOS, Android, ruggedized devices, offline capability), and approximately how many field users are expected to access the platform from mobile devices?

A78: Mobile application access for all users if available.

Q79: Regarding G1 (EHR API integration), which EHR vendors and interface standards are currently in use (Epic, Oracle/Cerner, MEDITECH, HL7, FHIR, etc.)? Is implementation of the API required at contract award or priced as an optional add-on?

A79: It may be priced as an add-on.

Q80: Beyond EHR connectivity, are integrations expected with systems such as:

* HAN

* EMResource

* HAvBED

* WebEOC

* FEMA systems

* Active Directory/Entra ID

* GIS platforms

* SMS gateways

A80: None of these integrations is required.

Q81: Does KDHE anticipate a phased implementation (Incident Management first, Resource Management second), or a single statewide go-live?

A81: Preference is for a single go-live.

Q82: Will the State provide dedicated project management resources and subject matter experts during implementation?

A82: BCHS staff will work directly with vendor(s)

Q83: Is historical data migration from the current applications required? If so, approximately how much historical data should vendors plan to migrate?

A83: Existing solution data will not need to be migrated.

Q84: Is there a target “go live” date? If so can you share?

A84: July 1, 2027

Q85: Will a current SOC 2 Type II report satisfy the annual security audit requirement, or are additional independent assessments expected?

A85: If a SOC-2 report can be provided, that will suffice for the first year.

Q86: Does the requirement that all production and non-production data remain within the United States also prohibit the use of offshore support personnel for monitoring, maintenance, or software development?

A86: Related to Q11, Q112. IT security attachment

5.j Contractor shall ensure that all AGENCY Production Data remains in the United States of America. Contractor shall further ensure no Production Data is accessed by Contractor employees, contractors, or any other authorized individual located outside of the United States.

5.k Contractor shall ensure that all AGENCY Non-Production Data remains in the United States of America. Contractor shall further ensure no Non-Production Data is accessed by Contractor employees, contractors, or any other authorized individual located outside of the United States.

Q87: What service level expectations exist beyond 99.95% uptime (e.g., response times, severity definitions, issue resolution SLAs, maintenance windows)?

A87: Standard communication and response expectations.

Q88: Is SMS messaging expected to be included within the contract price, or should vendors assume usage-based pricing for notifications?

A88: Messaging Credit Allowance - Line item for the initial allowance.

Q89: Does KDHE require automation with healthcare facilities? If so, please provide additional details.

A89: No

Q90: Does KDHE require the Incident Management system and the Bed Availability & Resource Management System to be interoperable and integrated with one another?

A90: No

Q91: Does KDHE require the solution to support Security Assertion Markup Language (SAML) and OpenID Connect (OIDC)?

A91: Not a requirement on our behalf.

Q92: Does KDHE require the solution to be able to create EEI/data elements? If so, please provide additional details.

A92: Yes, for the bed availability application, we would like the ability to create customized data elements.

Q93: The RFP requires bidders to address both the Incident Management and Bed Availability and Resource Management components. Will KDHE consider proposals where both components are substantially implemented, but a limited number of specific requirements within the Bed Availability and Resource Management component are under active development with committed delivery timelines prior to go-live?

A93: No

Q94: May the two components (Incident Management and Bed Availability/Resource Management) be delivered as separate integrated applications from a single vendor, or must they be provided as a single unified platform?

A94: Yes, they can be separate applications.

Q95: Section 3.61 states that award will be made “by line item or group total, whichever is in the best interest of the State.” Does KDHE anticipate the possibility of awarding the two components to different vendors, or awarding a single vendor only one of the two components? Or is the State’s intent to award both components to a single vendor?

A95: This information is not available.

Q96: BCHS currently operates cloud applications for both incident management and healthcare resource/bed availability. Will the State provide data export and migration assistance from the incumbent system(s), in what formats, and is migration of historical data within the awarded vendor’s scope of work?

A96: Migration of historical data is not included in the scope of work

Q97: Requirements A4 and D4 state the application shall not have per-seat or per-use license fees.

Would KDHE consider an event-based licensing model (fees associated with declared incidents or activations) to be compliant with this requirement, provided there are no per-seat or per-user charges?

A97: No

Q98: Page 1 states a three-year term with two optional twelve-month renewals, while the Cost Sheet (Section 5.B) requests annual pricing for Years 1 through 5. Should bidders price all five years as the evaluated cost, with Years 4 and 5 treated as renewal options?

A98: Yes

Q99: Requirements A4 and D4 specify support for 5,000 and 2,000 “concurrent users” respectively, but the RFP does not define this term. Does KDHE intend “concurrent users” to mean (a) registered/named user accounts, (b) users with simultaneous active sessions, or (c) users simultaneously generating system activity? Additionally, are these figures peak-capacity thresholds expected only during a major declared emergency, or anticipated routine day-to-day usage levels?

A99: (a) registered/named user accounts and day-to-day usage levels

Q100: Requirement G1 identifies API support for automated import of bed availability data from Hospital EHR systems as “Add-On Functionality.” Should bidders treat G1 as a mandatory requirement or as a desirable enhancement? Will proposals that include a roadmap for EHR integration, rather than current availability, be considered responsive?

A100: Proposals that include a roadmap will be considered

Q101: For the Bed Availability and Resource Management component, can KDHE share the current number of participating healthcare facilities, the regional structure used for reporting, and the essential elements of information (resource and status types) presently collected? This directly informs configuration and implementation scope.

A101: BCHS estimates approximately 500-700 unique facilities, organized in a custom geographic structure.

Q102: Requirement C2 references a FEMA-compatible After-Action Report and C8 references a Hazard Vulnerability Assessment, both completed and downloadable. Does KDHE have a required template, format, or methodology the application must produce (for example, a specific FEMA AAR/Improvement Plan format or a particular Hazard Vulnerability Assessment model)?

A102: No

Q103: Requirements B10 and E10 require all production and non-production data to remain within the United States, and the Cloud Service Provider Questionnaire (page 41, Q1) references a federally authorized environment at the FIPS-199 Moderate level. Does KDHE require a FedRAMP-authorized government community cloud (e.g., Azure Government), or is any FIPS-199 Moderate– capable U.S. commercial cloud region acceptable?

A103: FIPS option is acceptable if it’s in the U.S.

BCHS is not aware of a requirement for FedRAMP or GovRAMP authorization.

Q104: Requirements A5 and D6 specify 99.95% availability excluding scheduled maintenance. Will this be a contractual service-level commitment with associated credits or remedies, and how does KDHE define and bound scheduled-maintenance windows?

A104: This is an expected service-level commitment. Scheduled maintenance covers all planned downtime for system updates and corrections.

Q105: Requirements B8 and E8 require Multi-Factor Authentication “upon every login attempt.” Is multi-factor authentication established at session sign-in sufficient, or is an additional factor expected on each authentication event within an active session?

A105: Related to Q64, Q91, Q105, Q132

We don’t require anything for vendor systems. Expectation would be for vendor to supply login verification system appropriate to types and volume of users. Must incorporate MFA and account and password management must follow SOK standards as defined in ITEC-7230-A.

Q106: The Data Security Attachment (Section 11) requires SOC 2 and NIST 800-53 documentation to be made available on request. Are these expected with the technical proposal or following award, and is a SOC 2 Type II report a mandatory expectation for award?

A106: SOC 2 is required. If a SOC-2 report can be provided, that will suffice for the first year.

Q107: The Data Security Attachment defines Restricted-Use Information to include Criminal Justice Information Services (CJIS) data. Given that patient data and PHI are out of scope, does KDHE anticipate any CJIS data being stored or processed in either application? Confirming this clarifies which compliance controls apply.

A107: No

Q108: The WCAG 2.1 Level AA form asks whether the application will be compliant by April 26, 2027. If a bidder’s application is not fully WCAG 2.1 AA compliant today but can commit to full compliance by that date, will the proposal still be considered responsive? Will KDHE require a VPAT or remediation plan as part of the technical proposal?

A108: Related to Q160

The form asks for the status of both compliance today and for compliance by that date. If the vendor is willing to sign a contract including an agreement to become compliant by the date, then they are acceptable to submit the proposal.

They will need to submit a plan to become compliant for approval by the KPAT office, but that’s outside of the proposal process. The VPAT is not required as part of the proposal. The form allows for an “N/A” entry if it’s not applicable or not available.

Q109: The RFP states the Procurement Negotiation Committee may award based solely on the initial proposal without conducting formal negotiations. Does KDHE anticipate requesting product demonstrations from any or all bidders prior to award, or is the expectation that award will be made on the written technical proposal alone?

A109: Demonstrations may be requested.

Q110: Is there an anticipated award timeline KDHE can share, such as a target contract start date or go-live date for the application?

A110: Contract start date January 1, 2027, and go-live date 7/1/2027.

Q111: Section 3.54 (Ownership) states that “all data, forms, procedures, software, manuals, system descriptions and work flows developed or accumulated by the Contractor under this contract shall be owned by the using agency.” Bidder proposes a commercially available, pre-existing software product. Please confirm that this provision applies only to State data and to deliverables created specifically for the State under the contract, and that the Contractor retains all ownership of its pre-existing and commercial software, intellectual property, and underlying platform, with the State receiving a license to use the application for the contract term.

A111: That is correct.

Q112: The Data Security Attachment, Section 4.a, requires that Data Centers be “owned, operated, and controlled by Contractor,” with written AGENCY approval required for use of alternate (including leased) Data Centers. Modern cloud applications are commonly hosted on a major U.S.-based cloud platform (e.g., Microsoft Azure or Azure Government) rather than vendor-owned facilities. Will KDHE accept hosting in a U.S.-based commercial or government cloud region that meets the data-residency and security requirements of this RFP, and will the requisite written approval for such hosting be considered granted upon award?

A112: Data Centers must be owned/operated/controlled by contractor. This would be acceptable. We would provide the written approval upon submission of proof they are using a qualified environment.

Q113: The Data Security Attachment, Section 7.b, requires the Contractor to notify AGENCY of an Information Security Incident “within twelve hours,” while the Cloud Service Provider Questionnaire (page 41, Q15) references reporting potential privacy or security breaches “within 1-hour.” Please clarify which notification timeframe governs for the awarded contract so that bidders can commit accurately.

A113: Related to Q15, Q153. Section 7.b says that within a reasonable time frame of the incident, a plan must be submitted to the Agency for reducing the likelihood of recurrence.

Q114: The Scope states offers "must respond to both" Incident Management and Bed Availability/Resource Management, but Section 3.61 says award may be "by line item or group total." Does the State intend to make a single award covering both components, or could the two components be awarded to different vendors?

A114: An Award will be made for both components to a single vendor.

Q115: The Scope states offers "must respond to both" Incident Management and Bed Availability/Resource Management, but Section 3.61 says award may be "by line item or group total." Does the State intend to make a single award covering both components, or could the two components be awarded to different vendors?

A115: An Award will be made for both components to a single vendor.

Q116: The RFP references "a cloud-based application or applications." Does the State have a preference for a single integrated platform serving both functions versus two separate applications?

A116: Yes, they can be separate applications.

Q117: This certificate is listed as a mandatory technical proposal submission item but is completely omitted from the detailed layout instructions on Page 33 and Sections 2 and 3. Please clarify if a specific form is required and where vendors can locate the template.

A117: It is unclear what certificate the vendor is asking about. Refer to RFP Documents for instructions on requirements of the RFP.

Q118: Please provide:

● Legacy application(s)

● Approximate database size

● Number of records/documents

● Years of historical data to migrate

A118: Historical data migration is not expected. Legacy application and database size information are unavailable.

Q119: The first bullet point explicitly demands digital versions on separate flash drives, whereas the second point implies physical paper document copies packaged inside sealed containers.

Please clarify if the courier submission should consist purely of flash drives or if printed hard copies are also required.

A119: The proposal should be sent either flash drives or by mail/courier.

Q120: This section notes that Word and Excel formats are acceptable file extensions for email delivery. However, the Checklist on Page 3 exclusively references a "searchable PDF" format for technical content. Please confirm if mixed Word and Excel files are permissible for the final technical submission.

A120: A searchable PDF is preferred but will accept Microsoft Word and Excel documents.

Q121: The word "may" leaves this mandatory configuration open-ended. Please clarify if a financial statement must be enclosed with the initial submission package, and if so, specify the required format (e.g., audited balance sheets) and the necessary historical duration (e.g., last 2 or 3 fiscal years).

A121: This may be requested during the bid process.

Q122: The text under Section 3.13 on Page 20 mirrors the scope of Section 3.46 on Pages 24–25.

Please confirm if Section 3.46 is intended to entirely replace Section 3.13 or if both separate text blocks hold independent legal weight.

A122: These sections appear to be redundant.

Q123: The RFP does not define telephony ownership or volume metrics for short message services. Is the vendor expected to provision their own cellular carrier gateway and wrap transactional SMS messaging gateway fees directly into the software subscription, or will the agency expose a pre-configured internal gateway system?

A123: SMS Gateway integration is not required

Q124: There are no explicit definitions outlining the core engineering frameworks or structural profiles utilized by the local hospitals. Please identify the dominant EHR vendors deployed in the target network and specify the standard protocols required (e.g., HL7 v2, FHIR JSON schemas).

A124: API integration optional. HL7 is desirable but other options including SFTP and ADU are acceptable. Restricted information is outside the scope of this project.

Q125: These legacy prompts explicitly demand answers referencing highly outdated Microsoft Internet Explorer 5.0 browser behavior and classic IIS web server directory configurations. Please confirm if vendors may address these questions by specifying modern HTML5 attributes and modern secure reverse-proxy web routing infrastructure definitions instead.

A125: BCHS is unaware of any requirements prohibiting responses that include modern infrastructure.

Q126: The RFP explicitly states that Protected Health Information (PHI) and patient movement/tracking are out of scope. To confirm architectural boundaries, is this application strictly meant to serve as an aggregate, anonymous resource inventory (e.g., "Hospital A has 5 trauma beds available"), completely decoupled from individual patient identity, intake registries, or clinical dispatch files?

A126: Yes

Q127: Requirement A4 specifies supporting 5,000 concurrent users for Incident Management , and Requirement D4 specifies 2,000 concurrent users for Bed Availability. Are these numbers representative of daily routine operational baselines, or are they spike thresholds reserved exclusively for active, statewide emergency/catastrophic disaster simulations? Approximately how many total registered users and how many participating facilities/local health entities does the State anticipate onboarding?

A127: These numbers reflect the desired concurrent user capacity.

Q128: Since per-seat/per-use license fees are prohibited, does the State expect an enterprise-wide license covering an unlimited pool of named state, regional, and local health users, provided the concurrent traffic caps are respected?

A128: Concurrent traffic caps must address 2,000 concurrent users (bed availability) and 5,000 concurrent users (incident management)

Q129: Regarding the requirement to generate incident notifications via email and SMS: Is this alerting intended to be an automated, one-way broadcast tool to notify emergency staff of facility status shifts, or does it require interactive, two-way conversational routing (e.g., text-back confirmations to update bed counts directly via SMS)?

A129: One-way broadcast tool

Q130: The Scope of Work requires a statewide electronic healthcare facility resource management platform that captures "customizable essential elements of information (EEI)". Should the application provide an administrative front-end allowing KDHE staff to dynamically build and modify these data fields on the fly during a live crisis, or will these data points be statically hardcoded during initial system configuration?

A130: Desired ability to create customizable data elements, as needed.

Q131: Will the State (or incumbent) provide a data dictionary / export of current records to support migration and onboarding?

A131: No

Q132: Does the State require Single Sign-On (SSO) integration with a State identity provider (e.g., SAML 2.0 / OpenID Connect)? The functional requirements specify unique ID/password + MFA but do not mention SSO; please clarify whether SSO is required, preferred, or out of scope.

A132: The state does not require anything for vendor systems. Expectation would be for vendor to supply login verification system appropriate to types and volume of users. Must incorporate MFA and account and password management must follow SOK standards as defined in ITEC-7230-A.

Q133: Requirement G1 requests API support to automate the import of bed availability data from Hospital EHR systems. Is this automation intended to pull live bed availability statistics directly from hospital systems, or is the system expected to act as a passive receiver for pushes initiated by the hospitals' middleware?

A133: API integration is optional. HL7 is desirable but other options including SFTP and ADU are acceptable. Restricted information is outside the scope of this project.

Q134: Please provide the anticipated list of integrations A134: None

Q135: Are there existing middleware or enterprise integration standards that vendors must use?

A135: None that BCHS is aware of.

Q136: Are low code / no code applications platforms such as Salesforce in consideration? Is there a preference for any specific technology or platform?

A136: This information is not available

Q137: What is the anticipated budget for this project, and does it include both implementation and recurring costs?

A137: Budget information is not available.

Q138: Is mobile browser support sufficient, or are native iOS/Android applications expected?

A138: Mobile browser support is sufficient

Q139: Are offline capabilities required for field personnel?

A139: No

Q140: Is there an expected implementation timeline or target go-live date?

A140: Contract execution 1/1/2027; Go-live 7/1/2027

Q141: Does KDHE anticipate a phased rollout or a single statewide deployment?

A141: statewide

Q142: Determine the user personas who will require access to the system and their count.

A142: 2,000 active user bed availability and 5,000 active user incident management.

Q143: What is the expected number of internal users who will need access to the system?

A143: There is a desire for 2,000 active users for the bed availability system and 5,000 active users for the incident management system.

Q144: Will external stakeholders need access to the system? If yes, determine their requirements and their count.

A144: There is a desire for 2,000 active users for the bed availability system and 5,000 active users for the incident management system.

Q145: Most modern cloud (SaaS) solutions are hosted in the data centers of an established cloud platform provider rather than in the vendor’s own facilities. Will the State accept a solution hosted on a reputable US-based cloud platform — backed by that provider’s data-center certifications and a US-only data-residency commitment — as meeting this requirement, with written disclosure/approval, instead of requiring vendor-owned data centers?

A145: Yes (see section 4.a)

Q146: Does the State require the hosting platform to be FedRAMP Authorized (Moderate) and/or hosted in a dedicated US government-cloud region? Or will a commercial US cloud with a contractual US-only data-residency commitment and equivalent independent certifications (e.g., SOC 2 Type II, ISO 27001) be acceptable?

A146: related to question 11, 12, 112.

FedRAMP or GovRAMP authorization is not required.

5.j Contractor shall ensure that all AGENCY Production Data remains in the United States of America. Contractor shall further ensure no Production Data is accessed by Contractor employees, contractors, or any other authorized individual located outside of the United States.

5.k Contractor shall ensure that all AGENCY Non-Production Data remains in the United States of America. Contractor shall further ensure no Non-Production Data is accessed by Contractor employees, contractors, or any other authorized individual located outside of the United States.

Data Centers must be owned/operated/controlled by contractor. This would be acceptable. We would provide the written approval upon submission of proof they are using a qualified environment.

Q147: Some platforms offer an optional mobile app (installed from an app store) in addition to full web-browser access. Does this requirement prohibit offering such an optional mobile app, as long as all functionality is fully available through a supported web browser with nothing required to be installed?

A147: No

Q148: The functional requirements assume users are connected to the internet, but the Architecture Document asks for a "Disconnected Operations" section. Is offline data entry (for example, capturing bed counts or incident forms with no internet during an emergency) an actual requirement, or is this a standard template section that can be answered as "online-only / not applicable"?

A148: This is a standard template section that can be answered as "online-only / not applicable."

Q149: Several questions and the "Microsoft Enterprise Library" section appear to assume a custom Microsoft (.NET / IIS) application installed on State servers. For a cloud (SaaS) solution where the platform provider manages the servers and infrastructure, may the vendor mark these items "Not applicable - managed cloud platform" and respond instead with the provider’s security documentation? (This builds on Question 10, which addressed only the Internet Explorer 5.0 / IIS items.)

A149: Not applicable is acceptable.

Q150: What is the required period for keeping audit logs and change history available within the application? Some platforms keep standard change history for about 18-24 months and offer longer retention as an add-on. Would exporting logs to the State’s own log archive be acceptable to meet the five-year retention requirement?

A150: Change history audit log is not under a required time period. The five year retention requirement only applies to the record of destruction of data. That log should be maintained by the vendor.

Q151: Is the platform’s standard encryption-at-rest sufficient, or does the State require additional encryption of specific fields and/or State-managed encryption keys? Since the RFP states no PHI is in scope, confirming this helps us recommend the right platform tier.

A151: Standard encryption is acceptable.

Q152: On a shared cloud platform, a vendor or customer typically cannot run their own vulnerability scans or penetration tests against the underlying infrastructure without the provider’s authorization. Will the State accept the platform provider’s independent penetration-test summaries, SOC 2 Type II report, and ongoing monitoring attestations in place of vendor- or agency-run scans of that infrastructure?

A152: Yes, we will accept and review 3rd party test results.

Q153: These two sections give different breach-notification windows (1 hour vs. 12 hours). Please confirm the single timeframe the vendor should follow for reporting a security incident.

A153: 12 hours for breach-notification window refer to section 7.B security attachment

Q154: Beyond importing bed-availability data from hospital EHR systems (G1), does the State need this application to share data with or pull data from other systems — for example, a State emergency operations center / WebEOC, federal reporting (such as HHS TeleTracking or NHSN), mapping/GIS, or a State data warehouse? Please list any required connections and their direction (incoming/outgoing).

A154: No

Q155: How many separate non-production environments does the State expect (for example, Development, Testing, Training)? How often should their data be refreshed, and should all of these be included in the base subscription at no extra per-environment cost?

A155: Demo environment and live environment.

Q156: With thousands of users across many…