Response to Offeror Questions document.docx

Can you provide more details about the current data structure in the Iowa OpenELIS system and the specific fields that will need to be imported into the new NBSSS?

This information is not available at this stage. The data structure of the Iowa OpenELIS system and the specific fields to be imported into the new Newborn Screening Surveillance System (NBSSS) will be defined during the planning phase in coordination with Iowa’s State Hygienic Lab, the South Dakota Newborn Screening team, and the selected vendor.

The initial data import will include birth match data in the form of XML and/or HL7, and the vendor is expected to pull from the SD DOH cloud to the NBSS, rather than from Iowa directly.

Is there a state Electronic Master Patient Index (EMPI) the NBSSS is expected to integrate with?

Not at this time.

The RFP mentions integration with FileDirector for document management. Will you share the API documentation or specifications for FileDirector to better understand the integration requirements?

This will be provided to the vendor awarded the contract.

For the single sign-on (SSO) requirements, can you confirm if you're using Azure Business to Customer (B2C) for public/citizen users and Azure Entra ID for state employees and providers? Are there any specific authentication flows that must be supported?

Azure B2C is used for citizen SSO (if required) and Azure Entra ID is used for state staff, contractors and vendors. Onboarding of users (Entra ID) should be done as automatically as possible without a lot of manual intervention by state admins. The use of Azure Security Groups would be helpful to pass to the application for authorization purposes.

What are your expectations for data migration from existing systems? Can you provide estimated volumes of historical data (years of records, number of records) that will need to be migrated?

Data migration will occur in planned stages, with priority given to the most recent records—typically covering the last five years of newborn screening data. Older records will be migrated incrementally based on programmatic priorities and the retention requirements associated with specific conditions. South Dakota averages approximately 12,000 births per year, which serves as a rough estimate for the annual volume of newborn screening records. The total volume of historical data to be migrated will be further defined during the planning phase in collaboration with the selected vendor.

Can you share more information about the DOH Cloud architecture that will serve as the integration point for external systems?

The DOH Cloud Architecture will use Microsoft’s Azure Cloud as the backbone for all services. Implementation will follow Microsoft’s Cloud Adoption Framework design patterns for cloud-scale analytics and well architected framework. One potential design pattern that fits a likely approach is the lakehouse for data processing pattern.

Is all public health electronic transmitted data required to go through Health Link (state HIE) regardless of method?

No. Health Link, South Dakota’s Health Information Exchange (HIE), is one of several data sources that will be integrated into the Department of Health (DOH) cloud environment and subsequently into the Newborn Screening Surveillance System (NBSSS). In Phase 1, additional data sources will include vital records, laboratory data from Iowa's State Hygienic Lab, and other internal DOH data systems. All sources will be linked through the state-approved cloud environment, which will serve as the central integration point for data transmission to the NBSSS.

Per Page 55 of the RFP the State indicates a vendor may be eliminated in the first round of Evaluation if they exceed the budgetary constraints set forth by available funding. During the RFI period, the State shared that their preliminary budget for the initiative was $200,000. Is an updated estimate of the available funding available?

The South Dakota Department of Health is unable to disclose the exact budget or funding allocation at this stage of the procurement process. However, vendors should be aware that budgetary constraints do apply, and proposals that significantly exceed available funding may be disqualified during the First Round of Evaluation, as stated in the RFP.

The project is supported by a combination of federal funding sources, including cooperative agreements and grants that prioritize interoperability, data security, and sustainability. While we cannot provide a precise budget breakdown by phase at this time, vendors are encouraged to submit cost-effective proposals that clearly align pricing with the phased deliverables outlined in the RFP.

Proposals should include transparent pricing by phase and deliverable to allow the evaluation team to assess both cost feasibility and value. Cost realism and alignment with federal public health priorities will be part of the evaluation criteria. Vendors are also encouraged to propose scalable or modular pricing options where appropriate, in case additional funding becomes available to support expanded functionality or future phases.

The RFP outlines a phased implementation approach. Are the timelines for each phase fixed, or is there flexibility based on vendor recommendations?

The timelines outlined in the RFP were developed with feasibility in mind and reflect the Department’s preferred implementation schedule. While we aim to adhere to these timelines as closely as possible, there is flexibility to adjust them based on vendor recommendations, provided that any proposed changes are well-justified and aligned with the overall goals of the project.

Will the State consider proposals that combine certain phases to accelerate implementation while maintaining quality?

Yes

Is there a firm deadline for when Phase 1 must be operational?

The Department of Health has a strong interest in ensuring that Phase 1 becomes operational within the timeline proposed in the RFP. We understand that adjustments may be necessary based on technical considerations, vendor input, or unforeseen technical challenges. Any proposed changes to the Phase 1 timeline must be clearly justified and will be reviewed and considered in alignment with project goals.

What is the State's expected level of involvement during implementation (resources, time commitment, etc.)?

The State expects to be actively involved throughout every step of the implementation process. Both the South Dakota Newborn Screening Program and the Bureau of Information and Telecommunications (BIT) will provide consistent guidance, supervision, and collaboration to ensure that the system aligns with programmatic needs and technical requirements. The implementation will be approached as a partnership, with regular engagement to support timely decision-making and successful outcomes.

Can you provide estimated user counts by role type (e.g., how many hospitals, audiologists, state program staff, etc.) who will need access to the system?

For simplicity, vendors could use “150 users” as an estimate when drafting proposals. Currently, we have a limited number of users accessing our IT systems, which we hope to change. A priority for the state is that users will be able to view, use and update screening results. The NBS program is interested in learning how vendors handle this function in other states. In the meantime:

There are 27 known audiologists in the state, there are at least 66 hospitals that currently send data to Vital Records, not including various non-hospital birth centers (midwiferies), and each birth center will have at least one account. It would be up to each hospital/birth center to decide how many nurses they want to have access.

Anticipated user types could include:

· All hospitals and birthing facilities in South Dakota where births occur, including those that may handle births emergently (at least 66);

· All audiologists who perform newborn hearing screening and diagnostic exams (a subset of all licensed audiologists in the state);

· Midwives who operate independent practices, including those affiliated with birthing centers;

· Authorized newborn screening program personnel and consultants at the South Dakota Department of Health;

· Follow-up care coordinators, including Early Hearing Detection and Intervention (EHDI) staff, consultants, and contractors such as Hands & Voices

· Data analysts and epidemiologists within the Department of Health who support surveillance and reporting;

· State IT staff from the Bureau of Information and Telecommunications (BIT) involved in system administration and technical support; and

· Designated users from tribal health entities, where applicable.

· Border state follow-up teams, who are seeking hearing screening results from SD births who are residents of their state

For mobile and offline functionality in Phase 2, how many users are expected to require this capability?

We expect rural birth centers and midwifes who hold independent practices to be the primary target audience of this feature, though some rural hospitals may also be interested. We estimate 25+ (?) users per year.

Do you have a preferred training approach (train-the-trainer, online, in-person) and expected training schedule?

For the South Dakota Department of Health’s Newborn Screening staff and contractors, an in-person, train-the-trainer model is preferred to ensure deep familiarity with system functionality and to support internal capacity-building. For hospitals, audiologists, midwives, and other users external to DOH, online training—whether live or self-paced—is likely to be more practical and accessible. The specific training schedule and format will be determined collaboratively with the selected vendor during the planning phase to ensure alignment with user needs and availability. The NBS program is also interested in video and quick-guides which can be used in the event of staff changes at either the DOH or provider level.

The RFP describes optional features including a Secure Parent Portal. Would implementation of any optional features be expected during the initial contract period, or would these be considered future enhancements?

These can be considered for future enhancements. A user profile for Hands & Voices parent referral partners would be a useful part of Phase 1.

Can you clarify the expected requirements for the predictive analytics tools mentioned in Phase 4? What types of risk models or predictions are most important to the program?

The ability to flag a baby’s file who may have risk factors for later-onset hearing loss would be helpful to the program, as would the ability to flag a sibling’s file who may be at risk for a later onset genetic condition. Additionally, the ability to flag babies with abnormal screens who may be located further from sources of diagnostic care would be helpful as the program may use more intensive follow-up in those cases.

We are looking for predictive analytical tools which can perform the following:

1. Identify babies for follow-up with designated healthcare provider:

a. Ex 1: Models that flag babies who have no recorded metabolic screen on file within 24-48 hours of birth. Thus, this model should run at least once daily.

b. Ex 2: Models that flag babies who have no recorded hearing screen on file within 30 days of birth. Thus, this model should run at least once weekly.

c. Ex 3: Models that flag babies who did not pass their latest hearing screen and either need to redo it or be sent to an audiologist for diagnosis (if multiple screens came back unpassed). Thus, this model should run at least once weekly.

2. Birth Matching Algorithms: though not exactly a predictive model, birth matching algorithms typically involve some sort of probabilistic methods with statistical thresholds to fuzzy match babies in one data source to another. The birth matching algorithm should also resolve duplicates, mark unreconcilable or un-linkable records for manual review by SDDOH personnel, and flag babies who are likely to be twins rather than duplicates. This algorithm should be run at least once daily to give follow-up nurses the ability to intervene in a timely manner. This algorithm ultimately fuels the daily and weekly reports outlined in number 1 and is critical to the newborn screening program.

3. Predict timeliness based on subpopulation or individual characteristics:

a. Ex 1: models could help predict which hospitals are most at risk for decreased timeliness in newborn metabolic specimen turn-around time. The information gleaned from this model should be communicated to hospitals at least once monthly.

b. Ex 2: models could help predict which individuals are most at risk for decreased timeliness, such as due to geographical location, facility/hospital education on NBS testing, etc. Some individuals may also experience lengthened turn-around time due to the metabolic test itself. For example, borderline CAH often normalize after a repeat test. The time from birth to second test may appear as untimeliness but it is due in fact to the test itself.

4. Flag siblings and or at-risk babies by integrating relevant covariates:

Babies whose sibling was flagged by a newborn screen may also be at risk for the condition themselves, because many conditions can occur when both parents are carriers for a certain trait. These may include: Phenylketonuria (PKU), Maple Syrup Urine Disease (MSUD), Congenital Adrenal Hyperplasia (CAH), Medium-Chain Acyl-CoA Dehydrogenase Deficiency (MCADD), Glutaric Acidemia Type I (GA-1), Cystic Fibrosis (CF), Severe Combined Immunodeficiency (some forms), Biotinidase Deficiency, Sickle Cell Disease, Galactosemia, Homocystinuria. This model should be run concomitantly with other follow-up related models outlined in number 1 and should be done once weekly.

These are non-exhaustive examples of predictive models we would like to implement in the NBSSS.

For the mobile functionality described in Phase 2, do you require native mobile applications or would responsive web design be sufficient?

Either is acceptable, but mobile-native applications must use the appropriate State Identity Provider.

Beyond HIPAA and ONC Health IT Certification, are there any other state-specific security frameworks or requirements that must be adhered to?

Items specified in the BIT security standards or ITSP sections

For security scanning requirements, would the State accept a vendor-provided scan report conducted by a specific third-party security firm, or must BIT conduct all security scans?

The State prefers to do application vulnerability scans on a test environment. Any deviations to that would be discussed with potential vendors during the BIT Tech Review meeting.

What is the process for reviewing and approving BIT's "Banned Services" to ensure compliance throughout the contract term?

BIT’s Security Operations Center (SOC) would be involved in reviewing and approving services.

Can you confirm if the State is willing to consider a subscription-based pricing model for this solution?

The State would like the most financial advantageous pricing module. If there are different pricing modules, proposals should provide those and include any anticipated increases over the contract period.

Are there any grant funding deadlines or fiscal year considerations that would impact the project timeline or payment schedule?

Yes, the NBSSS will be supported via multiple grants with a range of deadlines. The DOH has budgeted for large parts of the project to be completed by November 2025 and June 2026.

The contract term is listed as ending May 30, 2030. Are automatic renewals subject to legislative approval or state procurement rules?

The contract term listed in the RFP, ending May 30, 2030, reflects the expected project period based on current funding. Any renewals beyond that date are not automatic and will depend on continued funding availability, adherence to state procurement rules, and successful performance of the vendor and the NBSSS system. The State is committed to long-term system sustainability, and strong performance during the initial term will be a key factor in renewal considerations.

Would the State consider a milestone-based payment schedule rather than equal monthly payments?

Yes. Specific terms would be negotiated and finalized during the contracting process.

Page 18: Can you provide a detailed inventory and assessment of the historical data currently maintained in legacy systems (e.g., Vital Records, local databases, spreadsheets) specifically, any existing data dictionaries or metadata?

A comprehensive data inventory and assessment of historical data maintained in legacy systems—including Vital Records, internal databases, and locally managed spreadsheets—has not yet been finalized for the purposes of this project. While individual data sources may have partial documentation or internal data dictionaries, a unified metadata framework does not currently exist. The South Dakota Department of Health will work collaboratively with the selected vendor during the planning phase to identify, review, and document available data structures, establish data mapping protocols, and define migration priorities. This will include engagement with the Vital Records team, the Newborn Screening program, and other relevant stakeholders to ensure alignment with programmatic and technical needs.

Page 18: Can you provide a detailed inventory and assessment of the historical data currently maintained in legacy systems (e.g., Vital Records, local databases, spreadsheets) specifically, data quality issues (e.g., completeness, duplication, consistency)?

A formal inventory and assessment of historical data quality across legacy systems has not been completed; however, several known data quality issues have been identified. These include:

· Inconsistencies in data structure and formatting across years, particularly in exported files from legacy systems such as Vital Records;

· Variable completeness, especially in older datasets or records involving emergency births or midwife-attended deliveries;

· Duplication risks due to manual data entry in local spreadsheets or inconsistent unique identifiers across systems; and

· Inconsistent use of codes or free-text fields, which may affect standardization and interoperability.

These issues are being actively documented and will be further assessed in collaboration with the selected vendor. The Department of Health will prioritize the resolution of these issues during planning and implementation to ensure a clean and reliable migration into the Newborn Screening Surveillance System.

Page 18: Can you provide a detailed inventory and assessment of the historical data currently maintained in legacy systems (e.g., Vital Records, local databases, spreadsheets) specifically, volume of data (e.g., number of records/files, total storage size)?

A complete and centralized inventory of historical data volume across all legacy systems has not yet been finalized. However, South Dakota records approximately 12,000 births per year, and newborn screening data spans more than two decades—resulting in an estimated total of over 240,000 records stored across various formats and systems. These include Vital Records, program-managed databases, and spreadsheets.

We do not anticipate migrating all historical data at once. Instead, we will prioritize the migration of current and recent records—typically covering the past five years—with earlier records to be migrated incrementally based on condition-specific retention requirements and programmatic priorities. Precise record counts, file inventories, and storage estimates will be further defined during the planning phase in collaboration with the selected vendor.

Can you provide a detailed inventory and assessment of the historical data currently maintained in legacy systems (e.g., Vital Records, local databases, spreadsheets) specifically, for data formats and structures (e.g., flat files, Excel, Access, SQL databases)?

Historical data related to the Newborn Screening Program is currently maintained across a variety of legacy systems and formats. These include:

· Flat files (e.g., CSV and TXT formats) generated through manual exports from legacy systems;

· Excel spreadsheets, often used for local tracking, follow-up activities, and condition-specific datasets;

· Structured data housed in SQL-based systems, such as those supporting Vital Records and internal DOH databases.

This list is not exhaustive. While a formal inventory of all file structures has not been consolidated, these are the primary formats currently in use. The selected vendor will work with the Department of Health during the planning phase to conduct a full assessment of data structures, define integration requirements, and support standardized data migration into the new surveillance system.

Pages 24, 26, 31, 32: Can you describe the data sources, types of data, and specific use cases you envision supporting with predictive analytics, risk scoring models, and anomaly detection? Please specify if any of the following apply

- Data domains (e.g., newborn screening, vital records, clinical data, social determinants of health)

- Data accessibility, interoperability, and frequency of updates

- Priority areas for predictive analytics (e.g., early identification of at-risk infants, population health trends, health disparities monitoring)

- Any current tools, models, or algorithms in use, if applicable

We are looking for predictive analytical tools which can perform the following:

1. Identify babies for follow-up with designated healthcare provider:

a. Ex 1: Models that flag babies who have no recorded metabolic screen on file within 24-48 hours of birth. Thus, this model should run at least once daily.

b. Ex 2: Models that flag babies who have no recorded hearing screen on file within 30 days of birth. Thus, this model should run at least once weekly.

c. Ex 3: Models that flag babies who did not pass their latest hearing screen and either need to redo it or be sent to an audiologist for diagnosis (if multiple screens came back unpassed). Thus, this model should run at least once weekly.

2. Birth Matching Algorithms: though not exactly a predictive model, birth matching algorithms typically involve some sort of probabilistic methods with statistical thresholds to fuzzy match babies in one data source to another. The birth matching algorithm should also resolve duplicates, mark unreconcilable or un-linkable records for manual review by SDDOH personnel, and flag babies who are likely to be twins rather than duplicates. This algorithm should be run at least once daily to give follow-up nurses the ability to intervene in a timely manner. This algorithm ultimately fuels the daily and weekly reports outlined in number 1 and is critical to the newborn screening program.

3. Predict timeliness based on subpopulation or individual characteristics:

a. Ex 1: models could help predict which hospitals are most at risk for decreased timeliness in newborn metabolic specimen turn-around time. The information gleaned from this model should be communicated to hospitals at least once monthly.

b. Ex 2: models could help predict which individuals are most at risk for decreased timeliness, such as due to geographical location, facility/hospital education on NBS testing, etc. Some individuals may also experience lengthened turn-around time due to the metabolic test itself. For example, borderline CAH often normalize after a repeat test. The time from birth to second test may appear as untimeliness but it is due in fact to the test itself.

4. Flag siblings and or at-risk babies by integrating relevant covariates:

Babies whose sibling was flagged by a newborn screen may also be at risk for the condition themselves, because many conditions can occur when both parents are carriers for a certain trait. These may include: Phenylketonuria (PKU), Maple Syrup Urine Disease (MSUD), Congenital Adrenal Hyperplasia (CAH), Medium-Chain Acyl-CoA Dehydrogenase Deficiency (MCADD), Glutaric Acidemia Type I (GA-1), Cystic Fibrosis (CF), Severe Combined Immunodeficiency (some forms), Biotinidase Deficiency, Sickle Cell Disease, Galactosemia, Homocystinuria. This model should be run concomitantly with other follow-up related models outlined innumber 1, and should be done once weekly.

These are non-exhaustive examples of predictive models we would like to implement in the NBSSS.

Pages 24, 26, 31, 32: What technical, validation, and operational requirements should guide the development and deployment of risk scoring models and anomaly detection mechanisms? Please address:

- Preferred modeling approaches (e.g., machine learning, traditional statistical methods, hybrid)

- Performance metrics and thresholds (e.g., sensitivity, specificity, positive predictive value)

- Validation expectations (e.g., cross-validation, real-world pilot testing, expert review)

- Operational deployment needs (e.g., dashboards, alerts, integration with existing systems)

Hybrid or traditional statistical methods are preferred. Industry standard favors interpretable models due to public health accountability. Many NBS systems (e.g., NewSTEPs data exchange, APHL-coordinated systems) use statistical baselines at present but are open to ML in the future. The system must support secure, scalable, and modular implementation of risk scoring and anomaly detection models, with the ability to integrate seamlessly with other systems using standards such as HL7 or FHIR. Additional details will be available to the vendor awarded the contract.

Has the proposed budget as mentioned in the RFI of $200,000, changed or increased for the RFP?

The South Dakota Department of Health is unable to disclose the exact budget or funding allocation at this stage of the procurement process. However, vendors should be aware that budgetary constraints do apply, and proposals that significantly exceed available funding may be disqualified during the First Round of Evaluation, as stated in the RFP.

The project is supported by a combination of federal funding sources, including cooperative agreements and grants that prioritize interoperability, data security, and sustainability. While we cannot provide a precise budget breakdown by phase at this time, vendors are encouraged to submit cost-effective proposals that clearly align pricing with the phased deliverables outlined in the RFP.

Proposals should include transparent pricing by phase and deliverable to allow the evaluation team to assess both cost feasibility and value. Cost realism and alignment with federal public health priorities will be part of the evaluation criteria. Vendors are also encouraged to propose scalable or modular pricing options where appropriate, in case additional funding becomes available to support expanded functionality or future phases.

As QLIMS is delivered as a SaaS cloud-based solution, could you please clarify your expectations for offline functionality, especially for users working without internet access in rural areas? Is internet connection via cellular data (SIM card) an option or does it need an offline mobile component with local device storage, the data from which to be synced when the device is back online as described in the RFP document?

We recognize that some users—particularly in rural or frontier areas—may have limited or intermittent internet access. Our primary expectation is that the system be accessible in those contexts without compromising data collection or reporting. We are open to solutions that address this need in a secure and sustainable way, whether through cellular connectivity (e.g., SIM-enabled devices) or a dedicated offline functionality that allows for local data entry and secure syncing once the device reconnects to the internet. The selected approach should ensure that essential functions can be performed without continuous connectivity, particularly for users in the field or in low-connectivity environments.

What format do you want the project plan in? MS Project or MS Excel?

The Department of Health uses Microsoft Project internally and would welcome project plans in that format. Microsoft Planner is also an acceptable option. However, vendors are free to use any project management tool—such as MS Project, Smartsheet, or others—as long as the format clearly outlines timelines, milestones, dependencies, and resource assignments. The cost and access to the chosen project tracking tool are the responsibility of the vendor.

What are you looking for in the Project Plan & Timeline section of the proposal that is different than what will be in the MS Excel Project Plan?

The Project Plan & Timeline section of the proposal should provide a narrative overview of your approach to implementation. This includes key phases, major activities, decision points, resource allocation, and any assumptions, risks, or dependencies that could impact the timeline. It should explain how you plan to execute the work, not just when tasks will occur.

In contrast, the Excel or MS Project plan should serve as a detailed, structured timeline—a visual and functional representation of project activities, durations, sequencing, and deadlines. It should complement the narrative by providing a clear schedule of deliverables and milestones.

What are you looking for in the Costs (Pricing Proposal) section of the proposal that is different than what will be in the Cost Proposal - [Vendor Name] document?

The Costs (Pricing Proposal) and the Cost Proposal – [Vendor Name] refer to the same document to be submitted. We are seeking a single, detailed pricing document that is organized by project phase and clearly outlines the associated deliverables and costs within each phase. This should include all relevant one-time and recurring costs, with clarity around licensing, support, maintenance, and any optional services. There is no need to submit separate documents—the same cost proposal should be referenced consistently throughout the submission.

What is the weight of each evaluation criteria? I see discrepancies in Section 9.1.3 and 9.2.

Thank you for pointing out the discrepancy between Sections 9.1.3 and 9.2 regarding evaluation criteria weights. The correct and final scoring breakdown is the one listed in Section 9.2:

· System Functionality & Compliance with Requirements – 35%

· Interoperability & Integration Capabilities – 20%

· Cost Proposal & Total Cost of Ownership – 20%

· Vendor Experience & References – 15%

· Implementation & Training Plan – 10%

Please clarify the expectation for the Deliverables section of the response. Which section should this be based off in the RFP? Section 1.4 is the ISSUING OFFICE AND RFP REFERENCE NUMBER, not the Phased Deliverable approach as described.

You're correct that Section 1.4 refers to the Issuing Office and RFP Reference Number. For the purposes of your proposal, the Deliverables section should be based on:

· Section 3, which outlines the required deliverables tied to the scope of work for each phase of this project; and

· Section 5, which provides guidance on the phased implementation approach and outlines the minimum criteria and expectations that each deliverable should meet.

We recommend structuring your response by addressing the deliverables listed in Section 3, while demonstrating how they will be implemented in accordance with the standards and timelines described in Section 5.

Can you explain this section “3.2.7 Support longitudinal tracking of outcomes across conditions and time.”?

Our expectation for this functionality is that the data system will enable longitudinal tracking of newborns identified through screening—from initial screening through diagnosis, treatment, and long-term outcomes—across multiple conditions and developmental stages.

For metabolic and other blood spot conditions, this includes the ability to:

· Track the initial screening result, diagnostic confirmation by the appropriate physician (such as a specialty doctor, geneticist, audiologist, or any combination of the above), and treatment initiation.

· Maintain case records that support short-term follow-up (STFU) activities such as provider communication, confirmatory testing, and case closure documentation.

· Support long-term follow-up (LTFU) For hearing screening, this includes integration with Early Hearing Detection and Intervention (EHDI) protocols:

· Documenting initial screen results adapting the EHDI & CDC’s 1-3-6 model: hearing screen done by 1 month of age, audiologic diagnostic testing by 3 months of age, and enrollment in early intervention services by 6 months of age.

· Counts and demographic summaries of the number of children who complete each step in the 1-3-6 model will be required for EDHI/CDC annual reports. We are mandated to submit them.

· Enabling data sharing and linkage with Part C (Birth to Three) programs and, where possible, Part B (Department of Education) to monitor the continuum of services through school age;

· Allowing tracking of intervention types (e.g., hearing aids, cochlear implants), speech/language development, and educational support plans (e.g., IEPs).

The system should provide cohesive timelines and case histories for each child, supporting both population-level reporting, case-level decision-making, and a wealth of longitudinal data for future research. Importantly, the platform must be designed to support cross-agency coordination especially on the hearing program side, with the ability to incorporate or export data for integration with systems used by early intervention and education partners.

This longitudinal capacity is essential to fulfilling the public health mandate of ensuring that all children identified through newborn screening receive timely and appropriate care throughout early childhood and beyond.

Please expand on what this question in Appendix B means, “Please list any required license information for software/devices connected to state devices.”?

The State needs to understand all software/device information that will be used for the solution, and any costs that may be the responsibility of the State.

Approximately how many data sources will be required for ingestion for this system?

We anticipate integrating approximately 4 to 6 primary data sources during the initial phases of the Newborn Screening Surveillance System. These include:

· South Dakota Vital Records, including birth and death data

· Iowa laboratory data from the OpenELIS system

· Hearing screening data, from both internal DOH systems and external providers

· Follow-up tracking systems, including spreadsheets and locally stored databases maintained by the Newborn Screening Program

· Health Link, South Dakota’s Health Information Exchange (HIE), as a potential source of relevant clinical data

· MyInsight, DOH Public Health EHR.

In addition to these structured sources, the system must also accommodate unstructured data that is currently received via fax or secure email, such as:

· PDFs of refusals

· Lab or screening results

· Other scanned clinical documentation All structured and unstructured data will be routed through the South Dakota Department of Health’s state-managed cloud environment, which serves as the central integration and staging hub. From the cloud, data will be securely transmitted to the selected vendor’s system.

Therefore, the vendor’s solution must support secure, automated ingestion from the DOH cloud and be able to:

· Interface with both structured datasets and unstructured files (e.g., PDFs, TIFFs)

· Associate documents with the correct patient or screening record

· Apply metadata tagging (e.g., document type, date, origin)

· Enforce access controls and audit logging

· Accommodate enhancements such as fax-to-file or email parsing tools, if needed in future phases The final number and configuration of data sources will be determined during the planning phase, in coordination with the selected vendor.

What is the format, frequency, and approximate size (for ingress and egress) of each of the core data sources?

a. Iowa OpenELIS

b. South Dakota Vital Records

c. Health Link

d. MyInsight

Exact formats, transfer frequencies, and file sizes for each data source will be finalized during the planning phase in collaboration with the selected vendor and data source owners. However, based on current operations and an estimated 12,000 births per year in South Dakota, the following planning-level expectations apply:

Iowa OpenELIS (Laboratory Data)

· Format: Structured flat files or HL7 messages (to be confirmed)

· Frequency: Likely daily or near-real-time batch delivery

· Estimated Volume: One record per newborn, including screening results and panels

· Ingress/Egress Size: Estimated at tens to hundreds of MB per month, depending on file format and frequency South Dakota Vital Records

· Format: Structured flat files (e.g., CSV/XML) and/or SQL exports from the EVRSS system

· Frequency: Daily exports

· Estimated Volume: High-priority dataset covering all birth and death records for approximately 12,000 births per year

· Ingress/Egress Size: The largest known file containing a full year of data is approximately 80 MB (80,000 KB); daily exports are significantly smaller, likely in the range of 1–5 MB each Health Link (State Health Information Exchange)

· Format: HL7 or FHIR messages, depending on technical integration and use case

· Frequency: To be determined—may be event-based or batched

· Estimated Volume: Variable, depending on which clinical data (e.g., diagnostic follow-up or encounter data) is accessed

· Ingress/Egress Size: Currently unknown; anticipated to be moderate, depending on scope and availability MyInsight (Public Health EHR)

· Format: Structured exports from internal SQL-based systems (e.g., CSV, Excel)

· Frequency: Likely bi-weekly or monthly, depending on program reporting needs

· Estimated Volume: Focused on follow-up tracking or outcome data

· Ingress/Egress Size: Generally under 10 MB per file These are estimates. File sizes may also be affected by format and frequency of transfer. All structured and unstructured data—including scanned documents, lab PDFs, refusals, and clinical forms currently received via fax or secure email—will be routed through the South Dakota Department of Health’s state-managed cloud environment. This cloud infrastructure serves as the central data integration hub, from which the selected vendor’s system will securely retrieve required files and records.

How many total users are expected to be part of this system? How many in each of the following categories -

a. SD DOH program staff (e.g., case managers, epidemiologists, analysts)

b. Hospital and birth facility users

c. Audiologists and hearing follow-up providers

d. Laboratory partners and support contractors

Vendors may use an estimate of approximately 150 total users when drafting proposals. While current system access is limited, a core priority for South Dakota is to significantly expand user access so that authorized individuals—including those outside DOH—can view, use, and update screening results directly within the system. We are particularly interested in understanding how vendors have supported this functionality in other state implementations.

At present, user volume estimates are based on the following known groups and assumptions:

· There are at least 66 hospitals currently reporting data to South Dakota Vital Records, each of which will require at least one user account (likely more, at the hospital’s discretion).

· There are 27 known audiologists in the state who conduct newborn hearing screening and diagnostic evaluations.

· Midwives affiliated with non-hospital birthing centers or operating independent practices will require individual accounts.

· Additional users will include DOH program staff, consultants, epidemiologists, BIT system administrators, tribal health partners, and border state follow-up teams requesting access to relevant hearing screening results.

Anticipated user types include:

· All hospitals and birthing facilities in South Dakota where births occur, including those that may handle births emergently (at least 66)

· Audiologists who perform newborn hearing screening and diagnostic follow-up

· Midwives who operate independent practices, including those at birthing centers

· DOH newborn screening program personnel and consultants

· Follow-up care coordinators, including EHDI staff and contractors (e.g., Hands & Voices)

· DOH data analysts and epidemiologists involved in surveillance and reporting

· State IT staff from the Bureau of Information and Telecommunications (BIT)

· Designated users from tribal health entities, where applicable

· Border state follow-up teams seeking hearing results for SD-born infants The NBS program anticipates working with the vendor to determine user categories and access levels needed. This user framework is expected to expand as the system matures. Specific access levels, permissions, and onboarding strategies will be refined during implementation planning in coordination with the selected vendor.

Is OCR required to extract and upload document content to the system or to scan and upload documents without extracting content?

OCR (Optical Character Recognition) along with extracting and parsing content into structured fields is a highly desired feature but not required. Independently of OCR capabilities, the system must support the ability to scan or upload documents—such as lab reports, refusals, or screening forms—and associate them with the appropriate infant’s record.

All such documents will be routed through the South Dakota Department of Health’s state-managed cloud environment, which serves as the central integration point. The selected system must be able to securely ingest these documents from the DOH cloud, store them appropriately, and enable tagging (e.g., document type, date received) and retrieval.

In summary, if OCR capabilities are available and can enhance future functionality—such as making documents searchable or enabling metadata extraction—they may be considered a value-add but are not a core requirement in the initial implementation phase.

As the requested system does not appear to be an EHR is there a requirement for the solution to have ONC Health IT Certification Program? In our past experience, ONC Certification is not a standard requirement of public health systems.

Yes, compliance with the ONC Health IT Certification Program is required for this system. While the Newborn Screening Surveillance System is not an Electronic Health Record (EHR), this requirement is in place due to federal grant funding conditions that apply to systems handling clinical data, including newborn screening results and interoperability with providers and laboratories.

Certification ensures alignment with national standards for data exchange, privacy, and security, and supports interoperability with systems such as EHRs, HIEs, and laboratory information systems. Vendors are encouraged to highlight their experience with ONC-certified modules or equivalent capabilities.

Given that the First Round of Evaluation includes elimination in this round if Vendor’s exceed the budgetary constraints set forth by available funding. Can South Dakota Department of Health share details with Vendors around the available funding or documentation detailing the sources of support? Additionally, can the South Dakota Department of Health provide the projected budget for each Phase of this project?

The South Dakota Department of Health is unable to disclose the exact budget or funding allocation at this stage of the procurement process. However, vendors should be aware that budgetary constraints do apply, and proposals that significantly exceed available funding may be disqualified during the First Round of Evaluation, as stated in the RFP.

The project is supported by a combination of federal funding sources, including cooperative agreements and grants that prioritize interoperability, data security, and sustainability. While we cannot provide a precise budget breakdown by phase at this time, vendors are encouraged to submit cost-effective proposals that clearly align pricing with the phased deliverables outlined in the RFP.

Proposals should include transparent pricing by phase and deliverable to allow the evaluation team to assess both cost feasibility and value. Cost realism and alignment with federal public health priorities will be part of the evaluation criteria. Vendors are also encouraged to propose scalable or modular pricing options where appropriate, in case additional funding becomes available to support expanded functionality or future phases.

The proposal lists HL7, FHIR and IJE as options as well as the methods defined by 45 CFR Part 170. Will the agency look to modernize these interfaces or consolidate the number of data interoperability standards?

Yes, the South Dakota Department of Health is actively interested in modernizing and consolidating the data interoperability standards used across the Newborn Screening Surveillance System (NBSSS). While the RFP lists multiple formats—including HL7 v2.x, FHIR, IJE, and methods defined under 45 CFR Part 170—this reflects the diversity of formats currently in use across data partners rather than a preference to maintain them all long-term.

The Department recognizes the burden and inefficiencies created by maintaining multiple data exchange standards and is committed to moving toward a streamlined and modern interoperability architecture. In the near term, this may involve standardizing around HL7 v2.x, which is broadly adopted in laboratory and public health systems and better aligned with current partner capabilities.

We welcome vendor expertise in helping define a roadmap toward interoperability modernization, including strategies for:

· Standardization and simplification of message formats across data sources

· Reducing custom interfaces and one-off connections

· Enhancing scalability and future-proofing through open, standards-based APIs Proposals that include thoughtful approaches to interoperability modernization, while still accommodating current data exchange needs, will be viewed favorably.

The 45 CFR Part 170 standard appears to be more comprehensive than the scope of the desired solution. In addition to data/user auditing, encryption at rest and transit, using HL7/FHIR standard messages and vocabulary for ingesting which sections are required to be compliant?

You are correct that 45 CFR Part 170, which governs the ONC Health IT Certification Program, includes a broad set of standards—many of which extend beyond the immediate scope of the Newborn Screening Surveillance System (NBSSS).

However, because this project is supported by federal funding, the Department of Health must ensure alignment with applicable standards within 45 CFR Part 170, especially those related to data interoperability, security, and system integrity.

Compliance is expected in areas such as:

· Encryption of data at rest and in transit

· User and data audit logging

· Role-based access controls

· Use of HL7 v2, FHIR, or other recognized standards for messaging and vocabulary

· Support for standardized code sets (e.g., LOINC, SNOMED) These alignments are necessary to meet federal grant requirements and to support long-term interoperability, security, and public health program sustainability.

Vendors are encouraged to describe how their solutions meet or align with these standards and to highlight any certified components where relevant.

Will the State of South Dakota Department of Health prefer the Vendor to host or will the State provide their own Azure infrastructure?

The State of South Dakota Department of Health prefers to host Platform as a Service (PaaS) solutions within its own Microsoft Azure tenant. This preference ensures centralized management, enhanced security, and compliance with state IT policies. For solutions necessitating Virtual Machines (VMs), the State favors hosting within its on-premises infrastructure. If on-premises hosting is not feasible, vendor-hosted environments may be considered, provided they meet the State's security and compliance standards. This approach aligns with the State's commitment to maintaining control over its data and systems while ensuring optimal performance and reliability.

Will the external stakeholders need federated login capabilities via Azure EntraID or B2C?

Azure B2C is used for citizen SSO (if required) and Azure Entra ID is used for state staff, contractors and vendors. Onboarding of users (Entra ID) should be done as automatically as possible without a lot of manual intervention by state admins. The use of Azure Security Groups would be helpful to pass to the application for authorization purposes.

Could the South Dakota Department of Health provide the template(s) for the specific reports for CDC, HRSA, and APHL identified within 3.4.3 Federal Reporting Support?

The South Dakota Department of Health cannot share official CDC, HRSA, or APHL reporting templates as part of the RFP materials. However, the system is expected to support federal reporting requirements by enabling flexible data extraction and formatting that aligns with common reporting expectations under cooperative agreements and grant conditions.

Vendors should plan to support the generation of outputs that accommodate:

· Aggregate case counts and condition-level data for CDC reports

· Performance measures and screening indicators for HRSA’s Title V and Maternal Health programs

· Data extracts in standardized formats (e.g., CSV, XML) for APHL or other technical partners The Department will work with the selected vendor during implementation to define the exact output specifications and ensure the system can generate reports or export files in alignment with evolving federal requirements.

Can you confirm the standardized data exchange formats currently used for real-time bloodspot and hearing screening data (e.g., HL7 v2.x, FHIR R4)?

At present, standardized real-time data exchange formats are not uniformly implemented across all partners for bloodspot and hearing screening data.