SD_EDSS_RFP_v6.pdf

UPDATED DECEMBER 11, 2025 V5.3 1

RSTATE OF SOUTH DAKOTA

INFORMATION TECHNOLOGY (IT) RFP

South Dakota Department of Health 615 East 4th Street Pierre SD 57501

Electronic Disease Surveillance System (EDSS) RFP

PROPOSALS ARE DUE NO LATER THAN 10/19/2026 11:59 p.m. CST

RFP #: 27-0908002-001 STATE POC: Elizabeth Burdick EMAIL: Informatics.RFP@state.sd.us

READ CAREFULLY

FIRM NAME: AUTHORIZED SIGNATURE:

ADDRESS: TYPE OR PRINT NAME:

CITY/STATE: TELEPHONE NO:

ZIP (9 DIGITS): FAX NO:

E-MAIL:

PRIMARY CONTACT INFORMATION

CONTACT NAME:

TELEPHONE NO:

FAX NO: E-MAIL:

UPDATED DECEMBER 11, 2025 V5.3 2

1. General Information

1.1. Purpose of Request for Proposal (RFP)

The State of South Dakota, through the South Dakota Department of Health (SD DOH) and in coordination with the Bureau of Information and Technology (BIT), is issuing this Request for Proposal (RFP) to solicit proposals from qualified offerors for a secure, configurable, interoperable, and supportable Electronic Disease Surveillance System (EDSS) solution and associated implementation services. The selected offeror will provide the software or platform, configuration, integration, data migration, reporting and analytics enablement, testing, training, go-live, transition, and ongoing support services necessary to replace or modernize the State's current EDSS system.

The future EDSS must support statewide communicable disease surveillance and related public health operations, including case intake and triage, disease investigation, workflow and task management, laboratory and clinical data exchange, data quality and reconciliation, federal and State reporting, reporting and analytics, user administration, role-based access, auditability, and secure access for authorized internal and external users. Detailed functional, technical, security, reporting, integration, implementation, and support requirements will be provided in this RFP and its attachments.

1.1.1 Background:

The South Dakota Department of Health currently relies on a Maven Electronic Disease Surveillance System (EDSS) environment as a core component of its communicable disease surveillance and public health reporting operations. The current environment supports case intake and triage, investigation workflows, case assignment, laboratory and diagnostic result review, disease classification, deduplication, data correction, program reporting, and federal and State reporting. SD DOH users and partners rely on EDSS data to support routine surveillance, outbreak response, program administration, partner communications, public health analytics, and required reporting to CDC.

The current EDSS operates within a broader public health technology ecosystem.

Depending on the program area and workflow, that ecosystem may include integration middleware such as Rhapsody, ELR and HL7 interfaces, eCR/AIMS/RCKMS-related workflows, CDC/NNDSS/MMG reporting pathways, SQL or reporting databases, data warehouse or State data repository environments, Power BI or equivalent analytics platforms, SAS, Excel, Azure cloud services, SFTP and file exchange processes, APIs or web services, terminology and reference data sources such as LOINC, SNOMED, and PHVS, and external public health, clinical, tribal, local, contractor, subrecipient, and federal reporting partners.

Stakeholder discovery indicates that the current environment continues to support important core surveillance operations but also requires modernization to reduce risk and improve operational efficiency. Current-state workflows often require users to supplement EDSS functionality with manual entry, external spreadsheets, SQL/SAS/Power BI workflows, email coordination, manually maintained files, custom-coded reporting or configuration processes, and case-by-case reconciliation. Operational pain points include data quality and validation burden, high-volume laboratory triage, sender and terminology mapping changes, incomplete or ambiguous incoming reports, duplicate or fragmented person/case/program records, limited self-service reporting, difficult visibility into workflow status, and the need to preserve auditability and data lineage across manual entry, interfaces, imports, reporting extracts, and administrative configuration changes.

UPDATED DECEMBER 11, 2025 V5.3 3

The future EDSS procurement is intended to provide SD DOH with a sustainable and configurable platform that can support event-based communicable disease surveillance while also accommodating program-specific workflows that may require longitudinal person/client tracking, service documentation, relationship and contact management, geospatial and jurisdictional support, external data exchange, and analytics-ready data outputs. The State expects the implementation to account for current operations, migration of historical and active data, continuity of critical reporting and interfaces, testing and validation across environments, user training, change management, and post-go-live stabilization.

The Background section is intended to provide context only. Detailed vendor obligations, response instructions, evaluation methods, and acceptance criteria will be stated in the scope of work, security/vendor questionnaires, cost proposal instructions, and contract attachments.

1.1.2 Goals and Objectives:

The State’s primary goal is to procure and implement a modern EDSS solution that supports SD DOH’s statewide public health surveillance mission while improving operational efficiency, interoperability, data quality, reporting, security, and long-term maintainability. The solution should provide a sustainable foundation for communicable disease surveillance and related public health program operations, while allowing SD DOH and BIT to manage future change without excessive reliance on custom code, one-off reporting workarounds, or disconnected external tools.

The State’s goals for the future EDSS include the following:

• Support core surveillance operations, including case intake, triage, investigation, person/client and event records, workflow management, laboratory and clinical data review, outbreak support, program-specific work, and authorized internal and external user access.

• Improve usability and efficiency for epidemiology, investigation, informatics, program, reporting, administrative, and technical users by reducing duplicate entry, manual reconciliation, unnecessary navigation, spreadsheet-dependent tracking, and other avoidable workarounds.

• Strengthen interoperability with public health data sources and destinations, including ELR/HL7, eCR-related workflows, CDC/NNDSS/MMG and other federal reporting pathways, integration middleware, APIs, SFTP/file exchange, reporting databases, data warehouse or State data repository environments, BI tools, terminology services, and external public health partners where authorized.

• Improve data quality, traceability, and governance through validation, reconciliation, deduplication support, source attribution, audit trails, configuration control, clear data lineage, and consistent reporting-ready data structures.

• Provide secure, role-appropriate access to sensitive public health data, including

PHI and PII, with identity management, access controls, auditability, data-governance boundaries, and support for State security and BIT technical review requirements.

• Enable reporting, analytics, dashboards, extracts, and self-service query capabilities that support operational management, program reporting, federal and State reporting, partner reporting, leadership visibility, and approved downstream

UPDATED DECEMBER 11, 2025 V5.3 4

analytics.

• Support governed configuration of forms, questionnaires, workflows, rules, reference data, terminology, templates, user roles, and reporting-related structures with appropriate testing, validation, versioning, promotion, rollback, and change-control safeguards.

• Maintain performance, reliability, availability, operational monitoring, error handling, scalability, environment separation, and supportability appropriate for high-volume laboratory processing, outbreak response, routine surveillance, federal reporting cycles, and State technology operations.

• Support implementation, migration, testing, training, change management, go-live readiness, stabilization, documentation, and ongoing operations in a manner that protects continuity of surveillance and reporting during transition from the current EDSS environment.

The State’s objectives for the resulting contract are to obtain a solution and implementation partner that can configure and deploy the EDSS; migrate or make available required historical data; preserve or replace critical interfaces and reporting pathways; support user acceptance testing, security review, training, and cutover; provide post-go-live stabilization; and deliver support, maintenance, documentation, and knowledge transfer sufficient for sustainable operations.

These goals and objectives are intended to guide offerors’ understanding of the procurement and the State’s desired outcomes. Detailed vendor obligations, response requirements, evaluation methods, and acceptance criteria will be stated in the Scope of Work, IT Requirements, Security and Vendor Questionnaire, Cost Proposal instructions, and related attachments.

1.1.3 Description of Components or Phases:

For purposes of this RFP, the State describes the work in terms of major solution and service components and anticipated implementation phases. Components describe the major capabilities, technology areas, and vendor services that must be addressed by the proposed solution. Phases describe the expected sequence for planning, configuring, validating, deploying, and supporting the future EDSS. The State may refine the final phasing approach during contract negotiation and project planning, and offerors may propose alternate sequencing when it reduces implementation risk, protects public health operations, or better supports the State’s objectives.

The major components of the EDSS procurement are expected to include the following:

• EDSS application and platform component. A configurable EDSS application or platform that supports disease surveillance, person/client and case/event records, investigation workflows, outbreak tracking, contact tracing, and clinical history management.

• Integration and interoperability component. Interfaces, APIs, file exchange, message processing, and related integration services needed to preserve or replace critical inbound and outbound public health data exchange, including ELR/HL7, eCR-related workflows, CDC/NNDSS/MMG or other federal reporting pathways.

• Data migration, conversion, and historical access component. Services and tools needed to analyze, convert, migrate, reconcile, validate, archive, or otherwise

UPDATED DECEMBER 11, 2025 V5.3 5

make available required data from the current EDSS environment and related source systems, including audit, lineage, reporting, and retention considerations.

• Reporting, analytics, and data access component. Operational reporting, dashboards, extracts, self-service query, reporting-ready datasets, BI or data warehouse integration, approved downstream analytics, and governance controls for internal and external reporting needs.

• Security, identity, privacy, and audit component. Role-based access control, user provisioning and deprovisioning, single sign-on or identity integration where applicable, external user access controls where approved, PHI/PII protections, audit trails, logging, monitoring, and evidence needed for BIT/security review.

• Hosting, environments, operations, and support component. The hosting model or models proposed by the offeror; production, non-production, testing, training, and support environments; performance, reliability, backup, disaster recovery, monitoring, maintenance, upgrade, service desk, and support arrangements; and documentation and knowledge transfer needed for sustainable operations.

• Implementation and transition services component. Project management, discovery, requirements validation, configuration, design, interface planning, testing, user acceptance support, training, change management, cutover planning, go-live support, stabilization, transition assistance, and vendor support required to place the future EDSS into production safely.

The State anticipates that implementation will include the following phases, subject to refinement through the selected offeror’s proposal, contract negotiation, and approved project plan:

• Phase 1 - Project initiation and planning. Confirm governance, communication channels, project management processes, staffing, schedule, risk management, decision management, deliverables, and acceptance processes.

• Phase 2 - Discovery, validation, and solution design. Validate current-state workflows, program needs, technical architecture, data sources, interfaces, reports, security requirements, user roles, data migration needs, and requirements traceability; produce the baseline design and implementation plan.

• Phase 3 - Configuration, build, and integration preparation. Configure the EDSS solution; establish environments; prepare integrations, reporting structures, data migration processes, security controls, and administrative configuration; and maintain traceability to RFP requirements and approved design decisions.

• Phase 4 - Data migration, interface development, and reporting enablement.

Execute and validate data conversion or historical access activities; develop, configure, or connect required interfaces; establish reporting and analytics pathways; and validate critical federal, State, partner, and program reporting outputs.

• Phase 5 - Testing, security review, training, and go-live readiness. Complete system, integration, regression, performance, accessibility, security, user acceptance, migration, reporting, and operational readiness testing; train users and administrators; finalize cutover and support plans; and confirm go-live decision criteria.

UPDATED DECEMBER 11, 2025 V5.3 6

• Phase 6 - Go-live, stabilization, and transition to operations. Place the solution into production; support cutover; monitor workflows, interfaces, reporting, performance, security, and user adoption; resolve defects; complete knowledge transfer; and transition to ongoing operations and maintenance.

• Phase 7 - Ongoing maintenance, support, and continuous improvement.

Provide post-implementation support, maintenance, upgrades, release management, documentation updates, service-level reporting, and optional enhancements or phased program refinements as authorized by the State.

The phases above are intended to help offerors organize their proposals and implementation approach. The State does not intend this section to prevent offerors from proposing an iterative, agile, hybrid, program-phased, interface-phased, or other risk-managed delivery model, provided the proposal explains how all required components, deliverables, testing, migration, reporting, security review, training, go-live, and stabilization obligations will be satisfied.

1.1.4 Scope of Components or Phases:

The scope of this RFP includes the products, services, labor, configuration, documentation, licenses or subscriptions, hosting or environment services, integrations, data migration, testing, training, go-live, stabilization, and ongoing support necessary to deliver a production-ready EDSS for SD DOH. The scope applies across all solution components and implementation phases described in this RFP and its attachments.

Offerors must address scope at both the solution level and the implementation level.

Offerors must identify all assumptions, dependencies, State responsibilities, third-party products or services, required interfaces, optional items, exclusions, and known scope limitations.

EDSS solution scope includes, at a minimum, the following capability areas.

• Case, person, client, event, and outbreak records. Core record management for persons, clients, cases, events, episodes, contacts, exposures, outbreaks, clusters, deduplication, merge/unmerge, record search, lifecycle status, assignment, jurisdiction, and case-linking needs.

• Workflow, task, and work queue management. Configurable work queues, triage, routing, assignment, exception handling, alerts, notifications, bulk actions, high-volume review, workflow transparency, user override, and operational status tracking.

• Program-specific and longitudinal workflows. Program enrollment, eligibility, services, treatment, interventions, funding attribution, longitudinal program history, contact investigation, partner services, and related program documentation where included in the approved procurement scope.

• Data capture, forms, questionnaires, and structured documentation.

Configurable forms, structured and narrative fields, required/preferred/optional fields, questionnaires, temporary or event-specific data elements, external survey or form integration where approved, and efficient manual-entry workflows.

• Laboratory, diagnostic, and clinical data management. ELR, HL7, manual lab entry, supplemental diagnostic data, eCR-related clinical data, test interpretation, condition-specific reportability logic, lab association, message identifiers, historical

UPDATED DECEMBER 11, 2025 V5.3 7

lab visibility, missing-data follow-up, and review of updates to existing or closed cases.

• Inbound integration, message processing, and external data ingestion.

Inbound ELR, eCR, HL7, API, file-based import, interface-engine, sender onboarding, message validation, parsing, mapping, quarantine, error handling, reprocessing, and external data source integration.

• Outbound reporting and public health data exchange. CDC/NNDSS/MMG, HRSA or other federal and program reporting where applicable, pre-submission validation, transmission status, correction, resubmission, reporting snapshots, partner exchange, and other authorized outbound data-sharing workflows.

• Reporting, analytics, dashboards, and governed data access. Operational reports, dashboards, self-service query, exports, reporting-ready datasets, BI/data warehouse or reporting-layer integration, scheduled reports, public or leadership dashboards where approved, and authorized analytic access through tools such as Power BI, SAS, SQL, R, Excel, or equivalents.

• User experience, navigation, and role-based views. Usable role-specific views, consolidated displays, minimized screen switching, search and lookup, high-volume navigation, clear lab and case visibility, workload/status awareness, and accessible user interface behavior.

• Data quality, validation, reconciliation, and cleanup. Validation rules, data completeness checks, duplicate detection, data correction, exception management, field standardization, transformation documentation, reporting-database consistency, reconciliation, and safeguards for administrative or model changes.

• Audit, traceability, provenance, and lineage. Auditable history of record changes, data source, interface/import provenance, user and administrative actions, reporting lineage, prior/new values where applicable, and traceability needed for compliance, operational troubleshooting, and reporting validation.

• Configuration, governance, rules, and change control. Configurable disease logic, forms, workflows, model/rule management, reference data, terminology, template lifecycle controls, testing before production, versioning, promotion, rollback, separation of duties, and change documentation.

• Security, privacy, identity, and access control. Role-based access, least-privilege controls, user provisioning and deprovisioning, SSO or identity integration where applicable, external-user controls where approved, PHI/PII protections, audit reporting, incident-support evidence, and security review support.

• Documents, templates, uploads, imports, and file management. Document generation, templates, attachments, structured uploads, import preview/validation, bulk import where approved, secure storage, access controls, versioning, audit history, and transition of required documents or file-based records.

• Terminology and reference data. LOINC, SNOMED, PHVS, NDC, value sets, disease/condition mappings, sender-specific mappings, medication or formulary reference data where applicable, effective dating, retirements, historical mapping preservation, and governance workflows.

UPDATED DECEMBER 11, 2025 V5.3 8

• Performance, reliability, scalability, and operational continuity. Stable remote access, high-volume case and message processing, operational monitoring, error handling, alerting, backup and recovery, service availability, disaster recovery, release management, and continuity through implementation and post-go-live operations.

• Infrastructure, architecture, implementation, and support. Hosting or environment architecture, integration architecture, data pipeline compatibility, multiple environments, technical administration, documentation, training environments, vendor support, transition assistance, and sustainable operations support.

Implementation services scope includes, at a minimum, the following activities and deliverables:

• Project governance and planning. Project management, schedule, communications, risk and issue management, decision tracking, deliverable management, status reporting, and acceptance processes.

• Current-state discovery and validation. Review of current workflows, user roles, program requirements, data structures, interfaces, reports, dashboards, security controls, operational procedures, and known pain points.

• Requirements traceability and solution design. Traceability from the RFP to the proposed design, configuration, testing, demonstrations, acceptance evidence, and future operational documentation.

• Configuration, build, and environment setup. Configuration of the EDSS solution, establishment of required environments, administrative controls, role profiles, reference data, forms, workflows, reports, and technical configuration needed for testing and production use.

• Interface and reporting inventory. Identification, design, prioritization, testing, cutover, and stabilization of required inbound interfaces, outbound reports, partner exchanges, reporting datasets, dashboards, and data access patterns.

• Data migration and historical access. Profiling, mapping, conversion, validation, reconciliation, retention, archival, reporting continuity, historical lookup, and acceptance of data migrated or otherwise preserved from the current EDSS and related sources.

• Security, architecture, and compliance review. Architecture documentation, security questionnaire responses, vulnerability and remediation support, identity/access design, audit evidence, privacy controls, hosting review, and BIT/security approval activities.

• Testing and acceptance. System, configuration, integration, data migration, reporting, regression, performance, accessibility, security, user acceptance, operational readiness, and defect-resolution testing with documented acceptance criteria.

• Training, documentation, and change management. Role-based training, administrator training, training materials, job aids, release notes, knowledge transfer, communication support, and readiness activities for internal and authorized

UPDATED DECEMBER 11, 2025 V5.3 9

external users.

• Cutover, go-live, stabilization, and transition to operations. Cutover planning, production readiness, go-live support, issue triage, performance and interface monitoring, stabilization support, transition documentation, operational handoff, and post-implementation support.

• Maintenance, support, and continuous improvement. Ongoing maintenance, support desk model, incident and enhancement processes, updates/upgrades, release management, service-level reporting, documentation updates, and optional future-phase services authorized by the State.

Scope boundaries and optional/future-phase handling. The State expects offerors to address the following boundary areas clearly in their proposals, even where final classification as base scope, optional scope, future phase, or excluded scope remains subject to State decision before release or during procurement: Ryan White and subrecipient workflows; tribal data exchange, including Winter Count or equivalent tribal EDSS integration; city, county, tribal, provider, contractor, or other external user access; public-facing forms or survey workflows; public or leadership dashboards; GIS/geocoding and spatial analytics; analytics sandbox, data warehouse, or reporting-layer access; replacement of disconnected external tools; and decommissioning or archival support for the current Maven-based EDSS environment.

Unless expressly authorized elsewhere in the RFP or resulting contract, this procurement does not require the selected offeror to replace unrelated State systems, make independent policy or data-sharing decisions, assume authority reserved to State procurement/legal/security/governance offices, or deploy production data exchange with external partners without approved agreements and State authorization. Offerors may, however, be required to support analysis, documentation, migration, interfaces, reporting, testing, or transition activities that involve those systems, partners, or governance decisions.

A component or phase will not be considered complete merely because software has been installed or configured. Completion should require accepted deliverables, demonstrated or tested requirements, approved security and architecture evidence where applicable, accepted data migration and reporting validation, operationally ready interfaces, trained users and administrators, completed documentation, resolved priority defects, and State acceptance under the contract and project plan.

Any proposed exclusion, substitution, dependency on State resources, third-party product, or optional item must be clearly identified so the State can evaluate risk, cost, schedule, and contractual impact.

1.2. Issuing Office and RFP Reference Number

The Department of Health (“Agency”) is the issuing office for this document and all subsequent addenda relating to it, on behalf of the State of South Dakota (“State”).

The reference number for this transaction is RFP# 27-0908002-001. This reference number must be referred to on all proposals, correspondence, and documentation relating to this RFP. For purposes of this RFP, the State’s centralized IT agency, the Bureau of Information and Technology (“BIT”), must approve all IT related purchases.

1.3. Schedule of Activities (Subject to Change)

All deadlines in the Schedule of Activities are due by 11:59 p.m. CST. The Schedule

UPDATED DECEMBER 11, 2025 V5.3 10

of Activities for this RFP is as follows:

RFP Publication 8/24/2026 Deadline for Letter of Intent to Respond 9/8/2026 Deadline for Submission of Written Inquiries 9/14/2026 Deadline for Responses to offeror Questions 9/28/2026 Deadline for Request for SFTP Folder 10/5/2026 Deadline for Proposal Submission 10/19/2026 Discussions / Technical Review 11/1/2026-11/13/2026 Demonstrations and presentations (if required) 11/16/2026 Proposal Revisions (if required) 12/7/2026 Anticipated Award Decision/Contract Negotiation 12/31/2026

1.4. Letter of Intent

All interested offerors must submit a Letter of Intent to respond to this RFP.

The Letter of Intent must be submitted to the Agency via email at Informatics.RFP@state.sd.us by the date and time indicated in Section 1.3 Schedule of Activities. Please place the following in the subject line of your email:

“Letter of Intent for RFP# 27-0908002-001”.

1.5. Submitting a Proposal

All proposals must be completed and received by the Agency by the date and time indicated in Section 1.3 Schedule of Activities.

Proposals received after the Deadline for Proposal Submission will be late and ineligible for consideration.

All proposals must be signed, in ink or electronically, by a representative of the offeror who is legally authorized to bind the offeror to the proposal. Proposals that are not properly signed may be rejected. The offeror’s proposal must be prepared pursuant to the requirements of Section 6 Proposal Submission Requirements of this RFP.

Proposals must be submitted as PDFs via Secured File Transfer Protocol (SFTP).

Offerors must request an SFTP folder by the date and time indicated in Section 1.3 Schedule of Activities by emailing Elizabeth Burdick at Informatics.RFP@state.sd.us with the subject line of “RFP# 27-0908002-001 SFTP Request”. The email should contain the name and the email of the person who will be responsible for uploading the document(s).

Please note, the offeror will need to work with its own technical support staff to set up SFTP compatible software on the offeror’s end. While the State can answer questions, the State is not responsible for the software required to access the SFTP folder.

No proposal will be accepted from, or no contract or purchase order will be awarded to, any person, firm, or corporation that is in arrears upon any obligations to the State of South Dakota, or that otherwise may be deemed irresponsible or unreliable by the State of South Dakota.

mailto:Informatics.RFP@state.sd.us

UPDATED DECEMBER 11, 2025 V5.3 11

1.6. Certification Regarding Debarment, Suspension, Ineligibility, and Voluntary

Exclusion – Lower Tier Covered Transactions

By signing and submitting this proposal, the offeror certifies that neither it nor its principals is presently debarred, suspended, proposed for debarment, declared ineligible, or voluntarily excluded from participation, by any Federal department or agency, from transactions involving the use of Federal funds. Where the offeror is unable to certify to any of the statements in this certification, the offeror shall attach an explanation to its offer.

1.7. Non-Discrimination Statement

The State of South Dakota requires that all contractors, vendors, and suppliers doing business with any State agency, department, or institution, provide a statement of non-discrimination. By signing and submitting their proposal, the offeror certifies they do not discriminate in their employment practices with regard to race, color, creed, religion, age, sex, ancestry, national origin, or disability.

1.8. Restriction of Boycott of Israel

For contractors, vendors, suppliers, or subcontractors with five (5) or more employees who enter into a contract with the State of South Dakota that involves the expenditure of one hundred thousand dollars ($100,000) or more, by submitting a response to this solicitation or agreeing to contract with the State, the bidder or offeror certifies and agrees that the following information is correct:

The bidder or offeror, in preparing its response or offer or in considering proposals submitted from qualified, potential vendors, suppliers, and subcontractors, or in the solicitation, selection, or commercial treatment of any vendor, supplier, or subcontractor, has not refused to transact business activities, has not terminated business activities, and has not taken other similar actions intended to limit its commercial relations, related to the subject matter of the bid or offer, with a person or entity on the basis of Israeli national origin, or residence or incorporation in Israel or its territories, with the specific intent to accomplish a boycott or divestment of Israel in a discriminatory manner. It is understood and agreed that, if this certification is false, such false certification will constitute grounds for the State to reject the bid or response submitted by the bidder or offeror on this project and terminate any contract awarded based on the bid or response. The successful bidder or offeror further agrees to provide immediate written notice to the contracting executive branch agency if during the term of the contract it no longer complies with this certification and agrees such noncompliance may be grounds for contract termination.

1.9. Certification Relating to Prohibited Entity

For contractors, vendors, suppliers, or subcontractors who enter into a contract with the State of South Dakota by submitting a response to this solicitation or agreeing to contract with the State, the bidder or offeror certifies and agrees that the following information is correct:

UPDATED DECEMBER 11, 2025 V5.3 12

The bidder or offeror, in preparing its response or offer or in considering proposals submitted from qualified, potential vendors, suppliers, and subcontractors, or in the solicitation, selection, or commercial treatment of any vendor, supplier, or subcontractor, is not a prohibited entity, regardless of its principal place of business, that is ultimately owned or controlled, directly or indirectly, by a foreign national, a foreign parent entity, or foreign government from China, Iran, North Korea, Russia, Cuba, or Venezuela, as defined by South Dakota Codified Law § 5-18A. It is understood and agreed that, if this certification is false, such false certification will constitute grounds for the State to reject the bid or response submitted by the bidder or offeror on this project and terminate any contract awarded based on the bid or response. The successful bidder or offeror further agrees to provide immediate written notice to the contracting executive branch agency if during the term of the contract it no longer complies with this certification and agrees such noncompliance may be grounds for contract termination and would be cause to suspend and debar a business under SDCL § 5-18D-12.

1.10. Modification or Withdrawal of Proposals

Proposals may be modified or withdrawn by the offeror prior to the established due date and time.

No oral, telephonic, telegraphic or facsimile responses or modifications to informal, formal bids, or Request for Proposals will be considered.

1.11. Questions Regarding RFP

All written questions should be sent to: Informatics.RFP@state.sd.us, only emailed questions will be accepted.

Each offeror may submit up to 50 questions via email concerning this RFP to obtain clarification of requirements. No questions will be accepted after the date and time indicated in the above schedule of activities. Email questions to the email address listed above with the subject line “RFP# 27-0908002-001”. The questions and their answers will be sent to all offerors that submitted Letters of Intent, submitted questions, or requested the questions and answers via email before the proposal submittal date and will be sent by the date and time indicated in the above calendar of events. Offeror may not rely on any other statements, either of a written or oral nature, that alter any specification or other term or condition of this RFP that have not originated from the SD RFP Project Contact. Offerors will be notified in the same manner as indicated above regarding any modifications to this RFP. Offerors and their agents may not contact any state employee other than the buyer of record regarding any of these matters during the solicitation and evaluation process. Inappropriate contacts are grounds for suspension and exclusion from specific procurements.

1.12. Proprietary Information

The proposal of the successful offeror(s) becomes public information. Proprietary information can be protected under limited circumstances such as client lists and non-public financial statements. An entire proposal may not be marked as proprietary.

Offerors must clearly identify in the Executive Summary and mark in the body of the mailto:%20Informatics.RFP@state.sd.us

UPDATED DECEMBER 11, 2025 V5.3 13

proposal any specific proprietary information they are requesting to be protected. The Executive Summary must contain specific justification explaining why the information is to be protected. Proposals may be reviewed and evaluated by any person at the discretion of the State. All materials submitted become the property of the State of South Dakota and may be returned only at the State's option.

1.13. Length of Contract

The length of the contract will be for a term of 4 year(s). The State will have the opportunity to renew the contract annually for up to 1 one-year time extensions. The extension(s) will not be automatic.

1.14. Governing Law

This RFP will be governed by and construed in accordance with the laws of the State of South Dakota. Any lawsuit pertaining to or affecting this RFP will be venued in Circuit Court, Sixth Judicial Circuit, Hughes County, South Dakota.

1.15. Site Visit

If site visits are required, they will be scheduled before the submission of the proposal.

Site visits will be made at the offeror’s expense.

1.16. Presentations/Demonstrations

At the State’s discretion, the State may require a presentation or demonstration by an offeror to clarify a proposal. However, the State may award a contract based on the initial proposals received without a presentation or demonstration by the offeror. If presentations or demonstrations are required, they will be scheduled after the submission of proposals. Presentations and demonstrations will be made at the offeror’s expense.

1.17. Discussions

At the State’s discretion, the offeror may or may not be invited to have discussions with the State. The discussions can be before or after the RFP has been submitted.

Discussions will be made at the offeror’s expense.

1.18. Technical Review

At the State’s discretion, the State may require a technical review of the offeror based on the offeror’s proposal and response to the Security and Vendor Questionnaire.

1.19. Negotiations

This process is a Request for Proposal/Competitive Negotiation process. Each proposal will be evaluated, and each respondent will be available for negotiation meetings at the State’s request. The State reserves the right to negotiate on any component of every proposal submitted. From the time the proposals are submitted

UPDATED DECEMBER 11, 2025 V5.3 14

until the formal award of a contract, each proposal is considered a working document and as such, will be kept confidential. The negotiation discussions will also be held as confidential until such time as the award is completed.

2. Standard Contract Terms and Conditions

Any contract or agreement resulting from this RFP will include the State’s standard terms and conditions as listed below, the State’s standard Information Technology (“IT”) contract terms listed in Appendix A, and any additional terms and conditions as negotiated by the parties. The offeror must indicate in its response any issues it has with specific contract terms. If the offeror does not indicate that there is an issue with a specific contract term, then the offeror will be deemed to have accepted the contract terms as written.

2.1. The Contractor will perform those services described in the Scope of Work, attached hereto as Section 3 of the RFP and by this reference incorporated herein.

2.2. The Contractor’s services under this Agreement will start on , and end on

, unless terminated sooner pursuant to the terms of the Agreement.

2.3. The Contractor will not use State equipment, supplies, or facilities. The Contractor will provide the State with its Employer Identification Number, Federal Tax Identification Number, or Social Security Number upon execution of this Agreement.

2.4. The State will make payment for services upon satisfactory completion of the services.

The TOTAL CONTRACT AMOUNT is an amount not to exceed $ . The State will not pay Contractor's expenses as a separate item. Payment will be made pursuant to itemized invoices submitted with a signed state voucher. Payment will be made consistent with SDCL chapter 5-26.

2.5. The Contractor agrees to indemnify the State of South Dakota, its officers, agents, and employees, from and against all claims or proceedings for actions, suits, damages, liabilities, other losses or equitable relief that may arise at least in part as a result of an act or omission in performing services under this Agreement. The Contractor will defend the State of South Dakota, its officers, agents, and employees against any claim, including any claim, action, suit, or other proceeding related to the claim. The Contractor’s obligation to indemnify includes the payment of attorney fees and other costs of defense. In defending the State of South Dakota, its officers, agents, and employees, the Contractor will engage other professionals, subject to the written approval of the State which will not be unreasonably withheld. Notwithstanding the foregoing, the State may, in its sole discretion and at the expense of the Contractor, engage attorneys and other professionals to defend the State of South Dakota, its officers, agents, and employees, or to assist the Contractor in the defense. This section does not require the Contractor to be responsible for or defend against claims or proceedings for damages, liabilities, losses, or equitable relief arising solely from errors or omissions of the State, its officers, agents, or employees.

2.6. During the term of this Agreement, the Contractor will obtain and maintain in force insurance coverage of the types and with the limits as follows:

2.6.1 Commercial General Liability Insurance:

UPDATED DECEMBER 11, 2025 V5.3 15

The Contractor will maintain occurrence based commercial general liability insurance or equivalent form with a limit of not less than $1 million for each occurrence. If such insurance contains a general aggregate limit it will apply separately to this Agreement or be no less than two times the occurrence limit.

The insurance policy will name the State of South Dakota, its officers and employees, as additional insureds, but liability coverage is limited to claims not barred by sovereign immunity. The State of South Dakota, its officers and employees do not hereby waive sovereign immunity for discretionary conduct as provided by law.

2.6.2 Professional Liability Insurance or Miscellaneous Professional Liability

Insurance:

The Contractor will procure and maintain professional liability insurance or miscellaneous professional liability insurance with a limit not less than $1 million.

2.6.3 Business Automobile Liability Insurance:

The Contractor will maintain business automobile liability insurance or equivalent form with a limit of not less than $1 million for each accident. Such insurance will include coverage for owned, hired, and non-owned vehicles.

2.6.4 Workers’ Compensation Insurance:

The Contractor will procure and maintain workers’ compensation and employers’ liability insurance as required by South Dakota or federal law.

Before beginning work under this Agreement, Contractor will furnish the State with properly executed Certificates of Insurance which will clearly evidence all insurance required in this Agreement. In the event a substantial change in insurance, issuance of a new policy, cancellation, or nonrenewal of the policy, the Contractor agrees to provide immediate notice to the State and provide a new certificate of insurance showing continuous coverage in the amounts required. Contractor will furnish copies of insurance policies if requested by the State.

2.7. While performing services under this Agreement, the Contractor is an independent contractor and not an officer, agent, or employee of the State of South Dakota.

2.8. The Contractor agrees to report to the State any event encountered in the course of performance of this Agreement which results in injury to the person or property of third parties, or which may otherwise subject Contractor or the State to liability. The Contractor will report any such event to the State immediately upon discovery.

The Contractor's obligation under this section will only be to report the occurrence of any event to the State and to make any other report provided for by their duties or applicable law. The Contractor’s obligation to report will not require disclosure of any information subject to privilege or confidentiality under law (e.g., attorney-client communications). Reporting to the State under this section will not excuse or satisfy any obligation of the Contractor to report any event to law enforcement or other entities under the requirements of any applicable law.

2.9. This Agreement may be terminated by either party hereto upon thirty (30) days’ written

UPDATED DECEMBER 11, 2025 V5.3 16

notice. In the event the Contractor breaches any of the terms or conditions of this Agreement, this Agreement may be terminated by the State at any time with or without notice. If termination for a breach is affected by the State, any payments due to the Contractor at the time of termination may be adjusted to cover any additional costs to the State because of the Contractor's breach. Upon termination the State may take over the work and may award another party an agreement to complete the work under this Agreement. If after the State terminates for a breach by the Contractor it is determined that the Contractor was not at fault, then the Contractor will be paid for eligible services rendered and expenses incurred up to the date of termination.

2.10. This Agreement depends upon the continued availability of appropriated funds and expenditure authority from the Legislature for this purpose. If for any reason the Legislature fails to appropriate funds or grant expenditure authority, or funds become unavailable by operation of law or federal funds reductions, this Agreement will be terminated by the State upon five (5) business days’ written notice. The Contractor agrees that termination for any of these reasons is not a default by the State nor does it give rise to a claim against the State or any officer, agent, or employee of the State, and the Contractor waives any claim against the same.

2.11. This Agreement may not be assigned without the express prior written consent of the

State. This Agreement may not be amended except in writing, which writing will be expressly identified as a part of this Agreement and be signed by an authorized representative of each of the parties to this Agreement.

2.12. This Agreement will be governed by and construed in accordance with the laws of the

State of South Dakota, without regard to any conflicts of law principles, decisional law, or statutory provision which would require or permit the application of another jurisdiction’s substantive law. Venue for any lawsuit pertaining to or affecting this Agreement will be in Circuit Court, Sixth Judicial Circuit, Hughes County, South Dakota.

2.13. The Contractor will comply with all federal, tribal, state, and local laws, regulations, ordinances, guidelines, permits, requirements, and other standards applicable to providing services pursuant to this Agreement and will be solely responsible for obtaining current information on such requirements. Nothing herein will constitute a waiver by the State to any defense to jurisdiction nor will anything under this Agreement constitute an acknowledgement by the State that any tribe has or exercises any jurisdiction over this Agreement or the parties.

2.14. The Contractor may not use subcontractors to perform the services described in this

Agreement without the express prior written consent of the State. The Contractor will include provisions in its subcontracts requiring its subcontractors to comply with the applicable provisions of this Agreement, to indemnify the State, and to provide insurance coverage for the benefit of the State in a manner consistent with this Agreement. The Contractor will cause its subcontractors, agents, and employees to comply with applicable federal, tribal, state, and local laws, regulations, ordinances, guidelines, permits, and other standards and will adopt such review and inspection procedures as are necessary to assure such compliance. The State, at its option, may require the vetting of any subcontractors. The Contractor will assist in the vetting process.

UPDATED DECEMBER 11, 2025 V5.3 17

2.15. The State reserves the right to reject any person from performing services under this

Agreement who the State believes would be detrimental to the services, presents insufficient skills, presents inappropriate behavior, or is considered by the State to be a security risk.

2.16. The Contractor hereby acknowledges and agrees that all reports, plans, specifications, technical data, miscellaneous drawings, software system programs and documentation, procedures, or files, operating instructions and procedures, source code(s) and documentation, including those necessary to upgrade and maintain the software program, and all information contained therein provided to the State by the Contractor in connection with its performance of services under this Agreement will belong to and is the property of the State and will not be used in any way by the Contractor without the written consent of the State. Papers, reports, forms, software programs, source code(s), and other material which are a part of the work under this Agreement will not be copyrighted without written approval of the State.

2.17. The Contractor certifies that neither Contractor nor its principals are presently debarred, suspended, proposed for debarment or suspension, or declared ineligible from participating in transactions by the federal government or any state or local government department or agency. Contractor further agrees that it will immediately notify the State if during the term of this Agreement Contractor or its principals become subject to debarment, suspension, or ineligibility from participating in transactions by the federal government, or by any state or local government department or agency.

2.18. By signing this Agreement, the Contractor certifies and agrees that is has not refused to transact business activities, have not terminated business activities, and have not taken other similar actions intended to limit its commercial relations, related to the subject matter of this Agreement, with a person or entity that is either the State of Israel, or a company doing business in or with Israel or authorized by, licensed by, or organized under the laws of the State of Israel to do business, or doing business in the State of Israel, with the…