STATE OF SOUTH DAKOTA DEPARTMENT OF HEALTH

615 E. 4th Street, Pierre, SD 57501

Offeror Questions and Answers RFP #: 27-0908002-001 — Electronic Disease Surveillance System (EDSS) Issued: 8/24/2026 State POC: Elizabeth Burdick Email: Informatics.RFP@state.sd.us This Addendum is issued to provide responses to written inquiries submitted by prospective offerors and is hereby incorporated into and made a part of RFP #: 27-0908002-001.

General Scope, Functionality & Phasing

1. What are the main pain points you are currently having?

2. Section 1.1.4 identifies nine boundary areas whose classification as base scope, optional scope, future phase, or excluded scope remains subject to State decision. Has the State made these determinations, and if so, will the classifications be published before the proposal deadline? If they remain open, how should offerors price and phase these areas so that proposals remain comparable?

3. If nothing changed and you didn’t purchase software, what would happen? What risk would that cost the organization?

4. What are the current manual processes that you are doing now that you would like to be automated?

5. How many hours of manual tasks are you currently going through that could be done with an automated process? How many employees, how many hours per day?

6. Does the state intend to have all the required statement of work features ready at initial go-live, or would it be open to a phased approach to delivery?

7. May offerors propose a phased production go-live by disease program, functionality, or interface rather than a single statewide "big bang" go-live? If so, what capabilities and interfaces does the State consider mandatory for the initial production release?

8. Will the State accept phased go-live by program, disease condition, interface, report, user group, or capability, provided critical operations and reporting continuity are maintained? Please identify capabilities that must be delivered in the first production release.

9. Please clarify which requirements in Sections 3 and 4 are mandatory pass/fail requirements for proposal responsiveness, which must be available by go-live, and which may be satisfied through configuration, development, a workaround, or a committed future release date. Where the RFP expressly permits an offeror to identify a future compliance date, will such a response remain eligible for award?

10. The RFP requires support for situational questionnaires and outbreak-specific data collection. Are these questionnaires expected to be completed exclusively by authorized system users, or does the State require public-facing or participant-facing electronic questionnaires that can be completed directly by patients, contacts, providers, or other external parties?

11. Would the state provide a list of communicable diseases required for inclusion in the system?

12. Section 3.5.1.4 requires the system to apply configurable disease-specific and test-specific reportability, case-creation, case-association, and time-boxing logic using CSTE or CDC case definitions where applicable, and Section 3.4.1 requires condition-specific questionnaires and investigation forms. Will the State provide its current reportable condition list, the condition-specific investigation forms and questionnaires in production use, and an export of the existing case-definition, classification, and reportability rule configuration? Does the State expect the successful offeror to supply condition content as part of the product, or to reproduce and migrate the State's existing configured content?

13. Will this project require development of communicable disease forms by the vendor? If so, should the forms be grouped in accordance with CDC MMG categories (e.g., arboviral, Hepatitis, foodborne and diarrheal)?

14. When the State references “configurable” solutions, does it explicitly seek front end tools to make all required configuration changes or just a smaller range available to front end users with others controlled by backend access?

15. Outside of those documents listed in the RFP, are there any other documents the State envisions requiring ingestion?

16. Please distinguish among current-state reporting, historical point-in-time reporting, versioned data, audit reconstruction, reproducible historical submissions, report snapshots, and lineage to source records.

17. Can the state provide more details as to “Forecasting-Oriented visualization” needs and requirements?

18. Please clarify the minimum required use cases, entities, relationship types, filtering, navigation, export/print, accessibility, performance, and audit requirements for the visual relationship map. Will a configurable or integrated visualization be acceptable?

19. Section: 3.1.1.14 Please provide more context around this requirement. How would tax address vs. true residency would come into play in the disease surveillance system?

20. Are any digital signature features required in EDSS?

21. The state mentions hosting model proposal such as “production, nonproduction, testing, training, and support environments”. What systems does the state operate with their current EDSS system? For example, does the state have a Test, Production, and Train environment only?

22. How many environments are anticipated for this system in addition to the production environment?

23. There are base, optional, future, and excluded classifications. Can the state identify the required scope for the base classification and the pricing expected for any optional or future classifications?

24. Can you provide examples of administrative or template files contemplated by section 3.4.2.18, including file types, volume, size, metadata, destination, validation, versioning, rollback, permissions, and audit requirements. Is this required at initial go-live, and would an approved bulk-import process or API satisfy the requirement?

Response An electronic disease surveillance system is considered essential for the work of our organization.

The scope of work in section 3 of the RFP was developed to address the EDSS needs of the division of Disease Prevention and Control. Proposals should address all requirements listed under the scope of work including areas listed in section 1.1.4. If any requirement is not included in the base software product, please note the optional component if applicable in the response. If applicable, please also list the optional component in the cost proposal.

South Dakota would prefer a system meeting all requirements at initial go-live, however, offerors may suggest a phased approach they consider more feasible. The approach taken will be decided by DOH with advice from the selected vendor.

The system must be configured for all conditions on the South Dakota Reportable Disease list, which is available on the DOH website at the following link https://doh.sd.gov/topics/diseases/infectious-diseases/reportable-diseases-in-sd/. The successful vendor is expected to deliver pre-built questionnaires for these conditions that include base case investigation information and all required CDC Message Mapping Guide (MMG) fields. Data dictionaries to assist with questionnaire creation will be provided to the selected vendor. Questionnaires must be fully customizable to allow authorized DOH staff to add, remove, or modify questions to meet State-specific investigation needs after system go live.

The system must support both internal and secure, mobile-responsive public-facing questionnaires to allow patients, contacts, and external providers to submit information directly into the system.

Configurable solutions should be a hybrid model. Routine administrative functions (e.g., updating questionnaires, managing picklists) must be manageable through low-code tools. Deeper technical configurations (e.g., complex message parsing, schema extensions) are acceptable via governed backend access.

Files to be uploaded should be easily editable via Microsoft Office Suite programs such as csv, docx, and rtf. The upload functionality should have a clear toggle or setting that allows the user to know where the file will be uploaded. An example of this is uploading of csv files containing Ryan White medication data to be uploaded into cases. Other examples would be uploading of a csv file for appending or editing a list of available medications within the system. Volumes will be user dictated and will be low with file sizes not exceeding 1GB. Files should be validated based on accepted text encoding formats, column names if applicable, and data types for the specific upload specifications. Uploads should be able to be rolled back and changes in the system originating from an upload should be tracked. Upload types and functionality should be gated behind a roles system allowing for control over what different levels of users are able to accomplish within the system.

In addition to structured imports the system is required to ingest unstructured and semi-structured file attachments, including clinical PDFs, supplementary lab results, paper forms, case notes, jpgs, and survey responses.

SD expects the vendor to support full reporting including MMG’s, Ryan White Reports, and custom reports as defined by the programs. This reporting will include historical as well current reporting. This reporting may come from the EDSS system and/or the reporting database.

As part of the reporting capabilities the system must allow for creation of time-series forecasting visualizations that clearly display historical trends alongside future projections. The forecast must visually communicate uncertainty (such as shaded confidence bands or upper/lower scenario limits) so that State epidemiologists can easily interpret projected capacity, demand, and potential case surges.

The system must provide simple native visualizations to graphically represent links between cases, exposed contacts, outbreak clusters, and exposure sites. While complex, highly interactive relationship mapping is not natively required, the system must support the seamless export of this relational data so users can ingest it into external business intelligence tools like Power BI for advanced analysis.

The distinction between an individual's tax/mailing address and their true physical residence is critical for accurate jurisdictional assignment, disease intervention, and morbidity attribution.

The state operates three environments within the current EDSS system: Testing, Development, and Production. The Development environment contains no real data while the Testing environment contains both real and test information. All changes are first validated in Test before being deployed to Production.

Data Volumes, Migration & History

25. To support accurate cost and capacity proposals, will the State provide current operational volumes for the following: annual inbound electronic laboratory reports (ELR) and observed surge peak; annual inbound electronic case reports (eCR); number of reportable conditions configured and annual cases created; annual case notifications transmitted to CDC, broken out by message mapping guide; annual non-person, animal, or location-context events such as rabies and zoonotic records; anticipated named users broken out by SD DOH staff, local or county staff, tribal users, provider or facility users, and subrecipient or other external users; number of distinct data senders and typical new sender onboardings per year; number of production outbound interfaces, scheduled extracts, and recurring reports; and for Ryan White, annual active clients, number of reporting subrecipients, and annual pharmacy or ADAP transaction volume.

26. Does the state have existing or specific target metrics for its peak volume measures for active users and incoming ECR/ELR data loads?

27. For data migration scoping, will the State make available the current EDSS data model, entity relationship documentation, and data dictionary, and a de-identified sample extract? Additionally, approximately how many person records, case or event records, laboratory results, and document attachments exist, how many years of history does the environment hold, and how many of those years must be migrated as live queryable records versus preserved through archival or read-only reporting access? Please also confirm whether historical federal submission records, including NNDSS and NETSS message history and transmission status, and Ryan White ADR and RSR submissions, must be migrated in a form sufficient to reproduce a previously submitted report using the original reporting logic and data state, as contemplated by Section 3.8.1.7.

28. How many reporting facilities and/or laboratories are currently sending Electronic Laboratory Reporting (ELR) data to the current EDSS environment? Does the data flow through a separate ELR system (e.g., Rhapsody, etc.) to route data to the DSS?

29. What is the states average monthly volume for ELR and eCR?

30. What is the current size of the Maven databases?

31. Please provide the number of investigations, number of people, and number of labs currently stored in the Maven EDSS system

32. Section 1.1.4: Beyond the current Maven Electronic Disease Surveillance System, are there any additional legacy, adjacent, or program-specific systems (for example, a laboratory results repository, a locally operated parallel system for a specific jurisdiction, or a single-condition case-management tool) whose data must be migrated, converted, or made available in the new EDSS?

33. What is the raw disk size (GB’s) of the existing EDSS system files that needs to be migrated?

34. How many tables and rows roughly need to be migrated from the existing EDSS system? How many different data sources and what data types need to be migrated?

35. Do DOH anticipate the migrated data coming over in a read-only archive format as opposed to a live operational copy of ongoing cases?

36. The RFP states that the proposed solution shall support governed data retention and archive in accordance with the state policy, law, regulation, and approved retention schedule. What is/are the desired retention period(s) for records, system and event logs which the EDSS shall support? Please also clarify legal holds, deletion or anonymization, historical access, and responsibility for retention and disposition.

37. Section: 3.6(pg 32) Can the State provide the approximate size in gigabytes of data to be migrated from Maven into the new EDSS?

38. For data not converted into the new EDSS, what level of searchable historical access, reporting access, point-in-time reconstruction, auditability, legal-hold support, retention, archival, and disposition is required?

39. Does the State expect full conversion of Maven and related source data, selective conversion, read-only historical access, archival, or a hybrid approach? Please identify any data categories that may remain outside the transactional EDSS.

40. Can the state provide the version of Maven in use, and confirm that at migration time, data dictionaries exported from Maven?

41. Can the state provide current operational reports, federal reports, dashboards, extracts, scheduled jobs, ad hoc queries, self-service products, data warehouses, reporting databases, BI tools, analytics platforms, and downstream consumers?

42. Section 3.5.2.2 requires native generation, validation, and transmission of CDC NNDSS HL7 Message Mapping Guide compliant messages and support for legacy NETSS formats. Which MMG versions and condition-specific message mapping guides does the State transmit today, through what transport, and does the State intend to preserve the existing transmission pathway through transition or replace it as part of this contract? Given the built-in MMG regression testing required by Section 3.4.1.18, does the State maintain an existing MMG test and validation environment, and what is the State's current CDC onboarding status for each guide in production use?

43. Is NETSS reporting a current, active requirement for this implementation, or is it intended as a legacy fallback for conditions not yet supported by MMG-based reporting, given that NETSS is being phased out nationally in favor of MMG?

Response The system imports approximately 7,500 ELR and 9,000 eCR documents over 4,000 unique encounters monthly. In addition to normal message volume, the new EDSS will need to support significant and sudden increases in message volume, such as those experienced during a large outbreak or a pandemic, without requiring emergency hardware changes or resulting in system failure. We currently receive ELR data from South Dakota Health Link and AIMS which includes approximately 15 senders excluding AIMS. AIMS sends ELR data from our Interpartner states and CDC labs. We use Rhapsody to manage these connections.

The State currently transmits approximately 500 NNDSS case notification messages monthly. The Department has fully onboarded and actively transmits production-level HL7 case notifications under Generic v2, Arboviral, and Lyme Disease/Tickborne guides. Active testing and validation are underway with the CDC for Generic v3, Measles, Mumps, Pertussis, Varicella, Congenital Syphilis, and Sexually Transmitted Diseases (STDs), with all these guides expected to be in active production by the project award date. Additionally, the reporting schema for the Tuberculosis (TB) guide is developed but currently reported via manual fallback methods. Leveraging the new system's native generation, validation, and testing capabilities, the State anticipates significantly accelerating its federal reporting velocity and plans to fully implement and onboard all remaining CDC-published MMGs within the first 12 months after going live.

Outbound transmissions route through secure federal pipelines via CDC SAMS, the APHL AIMS platform, and PHIN MS transport mechanisms. The State intends to preserve these transport pathways during transition; however, the vendor's solution must natively generate, validate, and queue valid HL7 v2.5.1 MMG messages without requiring external third-party message construction tools. The state currently tests and develops MMGs within the EDSS development environment. The State will share its existing methodology, test cases and implementation spreadsheets and other CDC onboarding documentation to the successful offeror post-award during Discovery.

NETSS is not the desired future-state standard and is actively being retired nationally. Support for legacy NETSS flat-file extracts is required strictly as a temporary fallback for low-incidence or legacy conditions that have not yet transitioned to an HL7 MMG. Once a condition is fully onboarded to an MMG or retired by CDC, its NETSS extract dependency will be discontinued.

The current EDDS used by South Dakota is Maven 6.0.6. Data dictionaries to assist with questionnaire creation will be provided to the selected vendor. South Dakota currently uses SAS and Power BI for analytics and visualizations of the EDSS data. Samples of reports, extracts, queries, and dashboards will be provided to the selected vendor to assist with migration.

Records contained in the EDSS should comply with the DOH 80-year retention policy. Log retention will be discussed during the technical review phase with offerors who reach that phase of procurement.

DOH anticipates a hybrid data migration strategy that balances overall system performance with programmatic requirements. Some data is required to be maintained in an operational format to minimize negative downstream impact to programs for case identification, case finding, and new EDSS workflows. The exact, granular details of what specific data elements, tables, and schemas must be maintained for live operational use versus what can be migrated as read-only will be addressed and finalized during the system design phase with the selected vendor. The state does not anticipate migrating any other data outside the existing EDSS system.

While the state cannot adequately predict another pandemic the system should be able to minimally support triple the current ELR, eCR, and user volume.

The current system stores the date first reported to CDC, and the last reported date to CDC. This data should be included in the migrated data for all MMG reported cases. The Ryan White Reports and NETSS submission data are not currently collected.

The main EDSS database is approximately 500gb and our reporting database is approximately 10gb.

The current EDSS database contains approximately 2 million cases associated with approximately 1.1-million-person records, and approximately 5 million lab Records.

Integration, Interfaces & Data Exchange

44. How many total integrations do you foresee will be needed?

45. Please provide an inventory of current and future required inbound and outbound interfaces, including source or destination, owner, message or file type, volume, frequency, criticality, and target implementation phase.

46. Will the State provide an inventory of the existing inbound interfaces, outbound interfaces, recurring extracts, federal submissions, dashboards, and production reports, identifying which must be operational at initial go-live, which may be phased, and which are candidates for retirement?

47. To scope integration work, please describe the current technical environment for each of the following: the Rhapsody interface engine, including version, who administers it, and whether the State intends to retain it as the integration layer or move message processing into the new platform; any current data exchange with the CDC AIMS platform and for which data streams, including whether electronic case reports reach the State directly from AIMS or are routed through Rhapsody; the required eHARS integration and direction of data flow; State-managed terminology services for LOINC, SNOMED, and PHVS versus vendor-maintained reference data, and whether the State maintains its own reportability and condition-mapping rule authority or expects the solution to consume published trigger-code content such as RCKMS or the eRSD Reportable Conditions Trigger Codes; the target State data repository or warehouse platform and preferred connection method; and whether the State provides a geocoding service the solution should consume or expects a commercial geocoding capability to be included in the vendor's price.

48. Is the current EDSS vendor under a contractual obligation to support data extraction, interface documentation, and transition assistance to a successor vendor? If so, through what date and covering what specific deliverables?

49. Can the state elaborate on integration capabilities or data formats of tribal and external partner integrations?

50. Approximately how many new interface or reporting-partner onboarding requests (for example, new laboratories, facilities, or ELR/eCR senders) should be planned for per year on an ongoing basis after go-live? Additionally, are these new onboarding partners generally expected to interface directly (system-to-system), or through manual/file-based methods?

51. For the pharmacy and medication data referenced in these requirements, is the State anticipating a system-to-system interface with an external prescription or pharmacy management system, or a file-based upload of medication data into the EDSS? If the latter, is there a required or fixed file format, or would a standard CSV/Excel template be acceptable?

52. For the tribal data exchange requirement, is the State expecting integration with the Great Plains Tribal Epidemiology Center's Winter Count system specifically, or a different tribal partner exchange mechanism? If integration is expected, would this occur via an API, file-based exchange (e.g., SFTP), or another mechanism?

53. Is vital records data expected to be received through an automated interface with the State's vital records system, or will it continue to be reported manually or in batch?

54. Beyond Electronic Laboratory Reporting, Electronic Case Reporting, eHARS, and tribal partner exchange addressed elsewhere in this RFP, are there additional “justified direct interfaces” the State anticipates — for example, the state immunization information system, a cancer registry, or syndromic surveillance?

55. Does the state consider 3rd party integrated software (e.g. Rhapsody) as “native” to the application for issues of data ingestion or data access?

56. Please describe “bidirectional” data exchange with tribal and other external partners, and how validation and update approval is envisioned.

57. Are animal rabies test results received via ELR, or through a separate/manual reporting pathway?

58. Are environmental test results (e.g., air quality, mold) received via ELR, or through a different intake pathway, or not at all?

59. Does the state consider 3rd party integrated software (e.g. Rhapsody) as “native” to the application for issues of data ingestion or data access?

60. For records associated with a tribe, how does the State determine and record that association, given that complete tribal rosters are not always available and some tribal members reside on non-tribal land?

61. Please clarify whether the State requires direct database access, a replicated reporting database, APIs, flat files, extracts, or another method for accessing raw data, code tables, reports, dashboards, metadata, and reporting datasets.

Response South Dakota currently uses the following integrations.

Inbound integrations

· Rhapsody is used to send ELR, transformed eCR, Vital Records Data, and other data to EDSS.

· Transmission Type: Web Service (SOAP)

· Frequency: Near Real-Time (every few seconds)

· Microsoft Azure, specifically Azure Function Apps, is currently used for geocoding of address information. EDSS must receive response from geocoding request.

· Transmission Type: REST (GET, POST) API using JSON Request Body

· Frequency: Near Real-Time (every few seconds to few minutes)

· Immunizations System integration is used to query against the South Dakota Immunizations Information System (SDIIS) to find immunization information relating to a person attached to a disease investigation.

· Transmission Type: Web Service (REST API)

· Frequency: Upon User-Triggered Action (Low Frequency)

· Local Drive (File Import) integration is used to allow files to be imported from a file on the local drive. Files existing on a specified drive location are automatically ingested.

· Transmission Type: Application Ingestion

· Frequency: Every 20 minutes

· Outbound integrations

· Rhapsody is a routing tool and ingests data from EDSS to route to CDC, Azure Cloud, and Partners.

· Transmission Type: File drop, SQL Database Polling

· Frequency: Varies from Intervals to Near Real-Time

· Microsoft Azure specifically Azure Function Apps is currently used for geocoding of address information. EDSS must send information for geocoding request.

· Transmission Type: REST (GET, POST) API using JSON Request Body

· Frequency: Near Real-Time (every few seconds to few minutes)

· Reporting Tables/Access Tables are used to allow applications and scripts to access tables using ODBC connections and credentials.

· Transmission Type: SQL Triggers

· Frequency: Frequent Intervals

· Local Drive (File Export) is used to allow files to be exported to a file on the local drive. Scheduled jobs can be specified within EDSS to automatically export files to local drive.

· Transmission Type: Application Export

· Frequency: Every 20 minutes

South Dakota requires the proposed system to support direct database access, a replicated reporting database, APIs, flat files and extracts for accessing raw data, code tables, reports, and reporting datasets.

DOH has informatics staff that support the current EDSS (and BIT staff that support the on-premises deployment). Informatics and BIT staff will be the primary resources to the selected vendor for data extraction, interface documentation, and transition assistance.

Vital records data is currently being received through Rhapsody which is expected to be maintained. Alternatively, the offeror may propose an automated interface with South Dakota’s vital records system.

South Dakota's Rhapsody instance is not considered to be native to the application for issues of data ingestion or data access. The application should be able to ingest data from Rhapsody and other integrations using file imports, web service requests, and SQL connections

Tribal data exchange is currently done through integration with the Winter Count system and via permissioned tribal dashboards. Tribal data exchange should be maintained with the ability to expand through bidirectional data exchange with our tribal partners. The new system should support connectivity with the Great Plains Tribal Epidemiology Center’s Winter Count system or equivalent platforms by leveraging secure REST APIs using JSON request body format. The Web Service response should be able to be ingested into case data.

Tribal records are determined by a combination of demographic data and geospatial analysis.

Currently, the State does not have an active system-to-system integration with the Electronic HIV/AIDS Registry System (eHARS). Implementing a secure, automated data exchange with eHARS is a highly desired capability for the new EDSS to streamline HIV surveillance and reporting.

SDDOH also has its own geocoding service solution that can be accessed using Web Service Requests (API and JSON).

The state currently leverages APHL’s terminology exchange service (TES) for LOINC, SNOMED, and RxNorm, wherever possible. Preferably the EDSS would integrate with the TES for LOINC, SNOMED, and RxNorm list management while maintaining the ability to manually add additional codes to the EDSS lists such as “Local Codes” to support jurisdictional and sending partner’s needs. The state does not currently see a need for an RCKMS interface.

We estimate onboarding 5-10 new reporting partners per year. New partners onboard through South Dakota Health Link. SD Health Link sends ELR data to our Rhapsody system. eCR is received from AIMS through our Rhapsody system. Rhapsody sends both ELR and eCR data to our EDSS.

Pharmacy and medication data (e.g., Ryan White ADAP dispensations) may be transmitted via direct interface or recurring file uploads using standardized CSV formats.

Animal rabies test results are currently imported from in-state labs into the surveillance system through a manual upload while some out-of-state labs are automatically imported via ELR. Non-infectious environmental laboratory results (e.g., air quality, mold) are outside the automated ELR scope and are not currently received by South Dakota.

Program-Specific Workflows (Ryan White, HIV, etc.)

62. For the Ryan White requirements in Sections 3.1.7 and 3.5.2.4, what system does the State use today to manage Ryan White client, service, eligibility, and ADAP data and to produce the RSR and ADR federal reports? Is the intent to replace that system with the future EDSS, or to interface with it?

63. Beyond Ryan White, are there other categorical programs the State envisions as separate modules outside the core DSS framework, rather than case types integrated within it?

64. Is HIV linkage-to-care tracking required for all individuals living with HIV, or only for those enrolled in the Ryan White program?

65. For Ryan White eligibility determination (pharmacy and other benefits), is eligibility data expected to be entered manually, or should the EDSS integrate with another system for that data?

66. Does South Dakota currently collect and store Ryan White and ADAP data in CAREWare?

67. Please describe required Ryan White business processes, interfaces, data exchanges, update frequencies, active-client volumes, reporting-period data, and reconciliation responsibilities.

68. Please provide Ryan White ADR/RSR reporting cycles, required data elements, active-client definitions, validation rules, reconciliation expectations, historical comparison requirements, and traceability from submitted reports to source records.

69. Do you use careware? If not, what system do you use for Ryan White?

70. What are the pain points with your current Ryan White data system?

71. Will the department require unique privacy and security standards for HIV case data and its authorized users?

72. Please clarify whether the system is expected to track funding sources and associated changes natively, or whether this requirement applies only when funding-source data is received through an external system or interface. Also, please define the types of service records in scope and the required audit details for corrections, voids, reversals, and reclassifications.

73. How does the State envision this requirement to preserve the historical state of data for reproducible reports coexisting with intentional corrections of errors, hard-deletion of data due to legal or other data controls, duplicate merges, etc.?

Response South Dakota currently manages Ryan White client, service, eligibility, and ADAP data, as well as the generation of federal Ryan White Services Reports (RSR) and ADAP Data Reports (ADR), through a highly customized module/package embedded directly within our existing disease surveillance system. The intent is to fully replace this current implementation with the future EDSS.

South Dakota does not use Careware.

HIV linkage-to-care tracking is a mandatory public health surveillance requirement for all individuals diagnosed and living with HIV in South Dakota, regardless of their enrollment status in the Ryan White program. The proposed EDSS must treat linkage-to-care as a universal epidemiological metric, utilizing incoming electronic laboratory reports (such as viral loads and CD4 counts) to automatically monitor care milestones, while enforcing strict role-based access controls to restrict this sensitive surveillance data to authorized HIV program staff. For those clients who are also enrolled in the Ryan White program, this surveillance data must securely coordinate with their case files to eliminate duplicate data entry and streamline case management workflows.

The future EDSS must support the native, manual entry and calculation of Ryan White and ADAP eligibility parameters directly within the platform. The State does not require an integration with an external, third-party eligibility determination database or software application for this function.

The system must include an active, built-in eligibility calculator. Case managers must be able to input a client's household income and family size directly into the patient record, and the system should automatically calculate the client's percentage relative to the Federal Poverty Level (FPL).

State program administrators must be capable of updating the baseline FPL income guidelines, eligibility thresholds, and calculation rules annually without requiring custom vendor coding, database manipulation, or system downtime.

The system must provide structured, auditable fields for case managers to manually input, track, and verify secondary eligibility criteria, including South Dakota physical residency (which can be validated via the system's geocoding tools), effective-dated enrollment periods, bi-annual renewal dates, and third-party insurance coverage parameters.

Our active client volume averages approximately 300 to 400 active clients enrolled in Ryan White Part B and ADAP annually.

Our subrecipient agency, Heartland Health, currently utilizes Apricot for day-to-day case management. While the State currently relies on monthly manual file imports (CSV/Excel) to transfer this data into the surveillance system, developing a direct, automated system-to-system interface between the proposed EDSS and Apricot is highly preferred to eliminate manual duplicate entry, accelerate update frequencies, and improve overall data quality.

The DOH informatics team extracts and runs preliminary validation reports. The Ryan White Program Manager and Program Coordinator then work directly with Heartland Health case managers to reconcile data discrepancies, correct errors, and update missing values within the surveillance system prior to final federal submission.

RSR (Ryan White Services Report) is due annually at the end of March, covering the full preceding calendar year (January 1 to December 31). ADR (ADAP Data Report) Cycle is due annually in early June, covering the preceding calendar year. More information regarding these reports can be found on HRSA’s website.

The system must run pre-submission validation checks that align with the HRSA Electronic Handbooks (EHB) data-validation schema for both RSR and ADR reports. System validation must flag critical Errors (which block submission), Warnings (which require corrective action or administrative comments), and Alerts (which allow submission but denote data anomalies).

To ensure data integrity, administrators must be able to trace any aggregate data point or eUCI record in a generated RSR/ADR XML export directly back to the individual clinical, service, or demographic source transactions within the EDSS. The system should also support the ability to compare current reporting-year metrics against archived, past-year XML submissions for longitudinal data validation.

Department of Health requires strict, specialized privacy and security standards for HIV/AIDS case data and its authorized users, in compliance with federal HRSA guidelines and state confidentiality statutes. However, our existing role-based access control (RBAC) and security requirements, as outlined in the RFP, are fully designed to cover these unique standards.

The EDSS must natively track service records and transaction-level costs linked to specific grant funding sources for the Ryan White program. The audit trail must log all corrections, voids, and reversals, recording the previous value, new value, authorizing user, timestamp, and transaction reason.

The system must provide a report population validation view for aggregate reports like the Ryan White RSR/ADR or NNDSS submissions. This allows epidemiologists to trace any aggregate count (e.g., "52 clients served") back to the specific, individual records that contribute to that total, making it easy to identify and resolve inconsistencies.

Beyond Ryan White, DOH uses the current EDSS for an enhanced Blood Lead surveillance program.

Information Technology, Security & Hosting

74. Section 4.2.3 states that an offeror unable to fulfill the State's identity management standard will be rejected from consideration, and identifies OAuth 2.0 as the protocol the State's SSO supports. Section 3.8.2.12 refers to ""standards-based identity federation such as OpenID Connect or SAML."" Please confirm which standard governs for purposes of responsiveness, and whether a solution supporting SAML 2.0 today, with OpenID Connect delivered on a committed date before go-live, satisfies Section 4.2.3.

Response:

SAML 2.0 is acceptable and meets SSO requirements for internal staff, OpenID Connect is required for citizen authentication. SSO is required before any system can go-live in production.

75. Section 4.2.2 requires separate complete proposals for vendor-hosted, State on-premises, and State Azure PaaS hosting ""if available,"" and permits an offeror to state that an option is not available with an explanation. The Security and Vendor Questionnaire directions state that ""your proposal must include options for On-Prem and Vendor Hosted solutions."" Please confirm that a vendor-hosted SaaS offeror may propose a single hosting model with a written explanation, and that a single completed questionnaire covering the System/Product General and Vendor Hosted sections satisfies Section 6.8.

Response:

Vendors may propose a single hosting model.

76. Does the State require or give preference to a third-party cloud security authorization such as StateRAMP, GovRAMP, or FedRAMP for a vendor-hosted solution? If a preference exists, how is it weighted relative to SOC 2 Type II certification with an executed business associate agreement?

Response:

The State does not give preference on third-party cloud security authorization unless that is a requirement stated in the RFP.

77. For a vendor-hosted SaaS solution, please clarify the requirement in Section 4.2.2 that the State have access to raw data and the ability to manipulate data. Will a secure, governed reporting database or data-access layer, documented APIs, and scheduled or on-demand exports in non-proprietary formats satisfy this requirement, or does the State require direct database-level access to the production transactional database?

Response:

The State will accept a secure, governed reporting database or data-access layer, documented APIs, and scheduled or on-demand exports in non-proprietary formats.

78. What service-level requirements should offerors assume for pricing, including required system availability, support coverage hours, severity definitions, incident response and resolution targets, planned maintenance windows, Recovery Time Objective (RTO), Recovery Point Objective (RPO), backup retention, and disaster-recovery testing frequency?

Response:

The below targets ensure that DPC staff can access the system 24/7, particularly during active outbreak investigations.

The information below outlines response and resolution timelines based on severity level.

Severity 1 (Critical - System Down/Data Integrity Risk)

· Initial Response: 30 Minutes (24/7/365 support coverage).

· Resolution / Workaround: 4 Hours.

Severity 2 (High - Major Feature Blocked, e.g., ELR Ingestion Failed)

· Initial Response: 2 Hours (During business hours).

· Resolution / Workaround: 24 Hours.

Severity 3 (Medium - System Operational, Workaround Exists)

· Initial Response: 8 Hours / 1 Business Day.

· Resolution: 5 Business Days.

Severity 4 (Low - Cosmetic/Minor Bug)

· Initial Response: 24 Hours.

· Resolution: To be resolved in the next scheduled maintenance release.

79. What evidence will the State require to demonstrate WCAG 2.1 Level AA compliance: vendor attestation, VPAT/Accessibility Conformance Report, independent accessibility assessment, or State testing? Does the requirement apply to all administrative interfaces as well as internal and external user-facing functionality?

Response:

The only option listed that we don't "accept" is state testing, as we do not test for this. It will simply be a contractual requirement. If we are found to be out of compliance and subject to liability, the vendor will be held responsible and liable. By default, the State prefers the admirative interfaces to be WCAG compliant as well so the State can meet its ADA requirements. If that is a concern, please note that concern in your proposal and how you would resolve that concern if it becomes an accommodation ADA issue.

80. For the vulnerability scan required during Technical Review, how recent must the scan be, must it be performed by an independent third party, and what scan methodology or scope is considered acceptable? Will a current independent penetration test and/or application vulnerability assessment satisfying the stated OWASP requirements meet this requirement?

Response:

A supplied scan should be no older than one year. The vendor must use a modern DAST/AppSec platform capable of authenticated scanning, API testing, business logic checks, exploitability validation, and OWASP Top 10 coverage. A detailed penetration test report is acceptable given it provides details of the findings and relevant remediation status of each.

81. Does the Department currently maintain an enterprise data warehouse, reporting repository, or analytical data platform that the proposed EDSS solution is expected to integrate with?

Response:

The Department maintains an enterprise analytical data platform on Microsoft Azure, utilizing an Azure Data Lake to securely store raw incoming surveillance data—including electronic case reports (eCRs), electronic laboratory reports (ELRs), syndromic surveillance feeds, and external survey responses—as well as copies of all outgoing CDC Message Mapping Guide (MMG) transmissions. In addition to this raw data lake, the State deploys a replicated reporting database built on Azure Cosmos DB to support analytics, BI dashboards, and custom epidemiologic queries. The proposed EDSS solution is expected to seamlessly integrate with this Azure-based ecosystem.

82. Section: 3.8.2.20(pg 36) The RFP states that the proposed solution shall support security event monitoring. For State-hosted solution, does the state currently operate a centralized Security Information and Event Management (SIEM) which the EDSS should be integrated to?

Response:

Yes, for State-hosted solutions the State will provide security event monitoring.

83. Appendix A requires Level 2 Authentication Assurance for vendor-hosted MFA, while ITSP 230.76.4.1 requires Level 3 for remote access to State information systems. Please confirm the applicable assurance level required.

Response:

Level 2 Authentication Assurance is the applicable requirement for the vendor-hosted SaaS solution (as specified in Appendix A).

84. Appendix A says all Critical, High, Medium, and Low issues are resolved at signing, then gives post-discovery remediation periods of 7, 14, and 30 days. Please confirm if the warranty applies to all issues regardless of accepted risk.

Response:

Yes, it does. If there is a concern with that contractual requirement, then you must identify the concern in your proposal.

85. Section: 4.2.9(pg 45) For state-hosted deliverables where the Vulnerability Scan is performed by the State, could the State identify the scanning tool or toolset that will be used?

Response:

Invicti

86. Will the State accept vendor performed background checks that are a requirement of onboarding new employees in place of State fingerprint-based background investigations?

Response:

The State does not negotiate security clauses through the question/answer phase of an RFP. As an offeror, the RFP directs you to comment on contractual obligations that are problematic for you.

87. RFP IT Exhibit DOH EDSS 07.22.26, IT Exhibit Section XXVII. Would South Dakota consider accepting the Contractor’s existing comprehensive background screening program as equivalent, or limiting the fingerprint requirement to personnel with direct access to production PHI systems?

Response:

As indicated in Section 2 of the RFP, the offeror must indicate in its proposal any issues it has with specific contract terms. Negotiations may occur with the winning offeror.

88. Would the State agree that changes to the IT Exhibit, ITSP, or other security requirements after contract execution will apply only when required by law and mutually agreed in a written amendment, with any resulting scope, schedule, or cost addressed through change control?

Response:

No, we do not limit changes to our security contract clauses to what changes in law. If we believe we need to create a new security contract clause and it would apply to this contract, we will address it through the amendment process or at the time of contract renewal.

89. Can the state share any specific RPO and RTO requirements?

Response:

The below targets ensure that DPC staff can access the system 24/7, particularly during active outbreak investigations.

The information below outlines response and resolution timelines based on severity level.

Severity 1 (Critical - System Down/Data Integrity Risk)

· Initial Response: 30 Minutes (24/7/365 support coverage).

· Resolution / Workaround: 4 Hours.

Severity 2 (High - Major Feature Blocked, e.g., ELR Ingestion Failed)

· Initial Response: 2 Hours (During business hours).

· Resolution / Workaround: 24 Hours.

Severity 3 (Medium - System Operational, Workaround Exists)

· Initial Response: 8 Hours / 1 Business Day.

· Resolution: 5 Business Days.

Severity 4 (Low - Cosmetic/Minor Bug)

· Initial Response: 24 Hours.

· Resolution: To be resolved in the next scheduled maintenance release.

90. Please clarify what are the security intelligence requirements in which the vendor shall meet for the vendor's hosted solution Response:

The state is answering based on Security Intelligence as it pertains to industry best practices. We require a vendor’s hosted solution to conform to OWASP best practices from the web application perspective and hardening guidance in any part of the shared responsibility model that applies to the vendor as provided by the platform owner. Toward that end, the State requires a full explanation of how the Vendor detects, monitors, analyzes, and responds to threats, as part of its overall cybersecurity posture.

91. For State-hosted deliverables, please identify scanning tools, cadence, credentialed versus uncredentialed approach, environments included, vendor participation, remediation timelines, retesting expectations, and procedures for…