Response to Offeror Questions document.pdf

RFP27-09RHT-026 Questions and Responses Page 1 of 16

STATE OF SOUTH DAKOTA

OFFICE OF PROCUREMENT MANAGEMENT

523 EAST CAPITOL AVENUE

PIERRE, SOUTH DAKOTA 57501-3182

DSS Rural Health Transformation – Medicaid Primary Accountable Care Transformation

(PACT) Technical Solution for Case Management

Questions and Responses

PROPOSALS ARE DUE NO LATER THAN 10/02/2026 BY 11:59PM CST

RFP #: 27-09RHT-026 BUYER: State of South Dakota

Department of Social Services

POC: Kirsten Blachford Kirsten.Blachford@state.sd.us

Q1: Our software development and support team works remotely from Monterrey, Mexico.

Attachment A, Section XLVIII requires continental US data centers and addresses access by named personnel outside the US or access authorized in writing. Before preparing a response, can you confirm whether an offeror may propose a Mexico-based development and support team, with all State data hosted in the continental US and any overseas access subject to the State’s written approval? Please also clarify whether that approval must be obtained before proposal submission.

A1: Due to the criticality of this application to the State of South Dakota, all development work associated with this project must be performed within the United States.

Q2: RFP Section 4.2.2 and Section 7.1 both state that hosting-option proposals (offeror-hosted, State on-prem, State Azure PaaS) are required "if available," and that "if any of the hosting options is not available, the offeror must clearly state that in the offeror's proposal and provide an explanation as to why the hosting option is not available." However, Attachment C (Security and Vendor Questionnaire) instructs that "your proposal must include options for On-Prem and Vendor Hosted solutions," which reads as a mandatory requirement rather than an "if available" option. Can the State clarify whether an On-Prem hosting option is required to be proposed, or whether an offeror may decline to offer On-Prem hosting (with a written explanation, consistent with Section 4.2.2) while still completing Attachment C's On-Prem section as "Not Applicable"?

A2: The State of South Dakota prefers the use of the State’s Azure PaaS platform as the on-premises hosting solution; however, this is a preference and not a mandatory requirement.

Vendor-hosted solutions may also be proposed but are subject to additional security validation and auditing requirements as outlined in Attachment C, Security and Vendor Questionnaire. Information provided in the questionnaire will serve as the basis for consideration by the Bureau of Information and Telecommunications (BIT) as part of its technical and security review.

Q3: If an offeror declines to propose an On-Prem hosting option, should Attachment C's On- Prem-specific question sections be marked "NA" per the Questionnaire's own response guidance, or omitted entirely?

A3: If an Offeror declines to propose an On-Prem hosting option, the On-Prem-specific sections of Attachment C should be marked “N/A” in accordance with the Questionnaire’s response guidance. The sections should not be omitted.

RFP27-09RHT-026 Questions and Responses Page 2 of 16

Q4: Is South Dakota Health Link (SDHL) the intended backbone for ADT and clinical data exchange with this tool, or is the awarded vendor expected to build direct interfaces with hospitals and providers independent of SDHL?

A4: The offeror should have the capability to interface with SDHL, however since the State does not feel the data will be sufficient, the application should be prepared to operate as an independent solution and meet applicable current CMS interoperability standards and requirements and be capable of supporting future CMS interoperability requirements as they become applicable.

Q5: Is there an existing case management system that this tool will replace? If so, what system is currently in use, and is legacy data migration in scope for this award?

A5: There is no existing Case Management System today.

Q6: Bamboo Health currently serves as South Dakota's PDMP administrator. Does the State anticipate this Case Management Tool integrating with PDMP data to support SDOH and substance use care gap identification, or is that considered out of scope for this procurement?

A6: The proposed solution should align with the CMS Interoperability Framework’s use of FHIR (Fast Healthcare Interoperability Resources) for PDMPs.

Q7: For the centralized referral intake capability from carceral settings described in Section 3.2, which facilities are in scope (state DOC facilities, county jails, or both), and are there existing data-sharing agreements with those facilities the vendor should be aware of?

A7: Facilities potentially included would be county, tribal, state DOC, and judicial circuits.

Specific data-sharing requirements and processes will be further defined and finalized in collaboration with the selected offeror.

Q8: What is the anticipated number of care coordinators, participating primary care practices, and Tribal partner sites expected at go-live?

Please provide the anticipated number of Medicaid members, participating provider organizations, State users, provider users, care coordinators, peak concurrent users, active cases, and annual notifications or messages expected during the initial term, including any planned growth assumptions that vendors should use for pricing and capacity planning.

Please clarify whether the PACT population is intended to include all applicable South Dakota Medicaid members statewide or only members associated with rural, Tribal, and frontier providers. For the initial contract term and each potential renewal year, please provide the estimated:

PACT-eligible or attributed member population.

unique member records expected to be loaded into the system.

Members expected to receive active case management annually Peak number of members actively under case management at one time.

Annual justice-involved youth referrals or cases.

Peak concurrent justice-involved youth cases and expected annual growth in each population.

To support solution sizing and pricing, please provide the expected beneficiary population, active and annual case volumes, users by role, and concurrent users. Please distinguish PACT and justice-involved youth populations and indicate the number of participating provider organizations and anticipated growth.

For solution sizing, licensing, infrastructure, and performance planning, can the State provide the estimated number of Medicaid members expected to participate in PACT at initial implementation, the anticipated number of participating provider organizations/sites, RFP27-09RHT-026 Questions and Responses Page 3 of 16 approximate number of State and provider users by role, expected peak concurrent users, and anticipated growth over the contract period?

Please provide the anticipated number and types of users requiring training, including State staff, care coordinators, case managers, participating providers, Tribal partners, community health workers, administrators, help desk personnel, and other stakeholders.

A8: The PACT program will include all eligible South Dakota Medicaid recipients; however, this tool is not expected to manage all those recipients. The State estimates a PACT- case management eligible population of approximately 20,000 Medicaid members statewide, although the number of members actively receiving case management services is anticipated to be considerably lower. State case management assistance will primarily focus on rural and frontier areas while also supporting other populations. Additionally, the State estimates a potential eligible justice-involved youth population of up to 4,000 individuals. This represents the eligible population rather than anticipated annual referrals or active cases.

The State anticipates approximately 100 or fewer users to start. The number of participating provider organizations, primary care practices, Tribal partner sites, care coordinators, provider users, and other stakeholders has not yet been finalized.

Additional estimates, including active and annual case management volumes, peak concurrent users and cases, annual notifications and messages, users requiring training by role, and anticipated growth throughout the contract period, have not yet been established.

These estimates are preliminary and subject to change as implementation planning progresses. Offerors should clearly identify their assumptions regarding solution sizing, licensing, infrastructure, staffing, training, and pricing. The proposed solution should be flexible and scalable to accommodate changes in program participation, user volumes, caseloads, and operational requirements throughout the contract period.

Q9: Section 3.2 requires the system to "maintain member data history for future searches and reporting for up to 10 years." Is the State open to a shorter data retention period, or is 10 years a firm requirement?

A9: No. The State is not open to a shorter data retention period. Offerors should ensure their proposed solution meets the data retention requirements specified in the RFP.

Q10: Please identify the Medicaid enterprise, eligibility, claims and encounter, HIE, hospital-notification, provider, identity, and data-repository systems expected to interface with the solution; for each interface, please describe available standards or APIs, expected transaction frequency, historical data volumes, and the respective State and contractor responsibilities for development, testing, and operation.

Please provide the anticipated initial interface inventory. For each interface, please identify the source and target system, system owner, direction, required protocol and version, expected frequency or latency, anticipated transaction, or record volume, and whether an existing interface specification is available. Please include, as applicable:

Medicaid eligibility, enrolment, claims, encounter and provider systems.

HIE, ADT, and hospital-notification sources.

Participating-provider EHRs.

Tribal health systems.

Carceral or juvenile-justice referral sources.

Community-resource or referral directories.

State identity management.

State reporting or data repositories and member communication services.

RFP27-09RHT-026 Questions and Responses Page 4 of 16

Please clarify whether the State will provide centralized connectivity through an existing HIE or integration hub, or whether the offeror will be expected to establish and maintain connections with individual organizations.

Please identify the legacy systems and data sources from which information must be migrated. For each source, please provide the anticipated number of records, years of history, data domains, file formats, document or attachment volumes, and known data-quality considerations. Please clarify whether migration includes historical cases, care plans, assessments, notes, tasks, referrals, communications, assignments, and audit history, and identify the State’s responsibilities for data extraction, cleansing, mapping, and validation.

Please distinguish the history required at initial migration from the requirement to retain beneficiary history for up to 10 years and clarify responsibility for source-data extraction and cleansing.

Please identify the systems and interfaces required, including the data exchanged, frequency, and available specifications. Please clarify which existing State or partner connections can be used and responsibility for source-system changes and provision of data feeds.

Can the State provide an inventory of the known systems expected to integrate with the Case Management Tool, including applicable Medicaid enterprise systems, HIE(s), provider/EHR systems, Tribal systems, justice/corrections systems, and other State systems? Where available, please provide the anticipated integration use case, interface method, data exchanged, transaction frequency/volume, existing API/interface documentation, and availability of test endpoints.

A10: The State has not identified specific required interfaces currently. Offerors should propose a solution that provides flexibility to support future integration with relevant State and external systems as needs are identified. The solution should support commonly accepted interoperability standards and APIs and be capable of accommodating varying transaction frequencies and data volumes. Specific interface requirements, including development, testing, operational responsibilities, and data exchange specifications, will be determined during implementation in collaboration with the selected Offeror. The State anticipates that the Case Management Tool will support connectivity to the State’s existing Health Information Exchange (HIE), where feasible. The specific approach and ability to integrate with the HIE will be determined during implementation based on technical capabilities, requirements, and available interfaces. Offerors should describe how their proposed solution could support HIE connectivity while also providing the required messaging and record-sharing functionality.

Q11: What are the target dates and acceptance criteria for project kickoff, pilot deployment, production go-live, statewide rollout, and final acceptance, and are there required CMS APD, certification, or enhanced-funding milestones that must be incorporated into the implementation schedule?

Please provide the State’s anticipated project start date, target production go-live date, expected Design, Development and Implementation (DDI) duration, and the point at which DDI will be considered complete. Should DDI completion occur at production go-live, completion of stabilization, or formal State acceptance following stabilization?

Please provide the target implementation start and go-live dates, including any required milestones or dependencies. For phased deployment, please identify the initial priority populations, provider groups, and capabilities, including whether PACT and justice-involved youth workflows must launch together.

RFP27-09RHT-026 Questions and Responses Page 5 of 16

A11: The State has not established specific target dates for project kickoff, pilot deployment, production go-live, statewide rollout, or final acceptance. Offerors should propose a realistic implementation schedule and clearly identify key milestones, dependencies, acceptance criteria, and the anticipated DDI duration. The State’s preference is to implement available out-of-the-box functionality as early as practicable, followed by iterative configuration, customization, and enhancement based on prioritized State requirements. Offerors should describe how their proposed implementation approach supports this phased and iterative model. Specific milestone dates, acceptance criteria, and the point at which DDI will be considered complete will be finalized with the selected Offeror during project planning and implementation.

Q12: Please confirm whether a vendor-hosted commercial SaaS solution is fully responsive if on-premises and State-hosted versions are unavailable, given the Security and Vendor Questionnaire instruction to include on-premises and vendor-hosted options and RFP §4.2.2 permitting vendors to explain unavailable hosting options.

A12: Yes. A vendor-hosted commercial SaaS solution is considered fully responsive to the RFP requirements. However, access to the solution and its systems will be managed and controlled by the State of South Dakota.

Q13: Please confirm that contract §2.16 will be revised or interpreted so State ownership applies only to State data and expressly commissioned project-specific deliverables, while the contractor retains ownership of its pre-existing commercial SaaS platform, source code, reusable components, tools, configurations of general applicability, and derivative improvements, with appropriate State subscription and data-export rights.

The RFP contains requirements regarding State ownership/access to software, source code, object code, and application-code documentation. Please clarify whether these provisions apply to pre-existing proprietary COTS/SaaS platform code and third-party products, or only to custom code, configurations, interfaces, scripts, documentation, and other project-specific work products developed specifically under this contract.

A13: The organization or offeror will retain all intellectual property associated with the COTS/SaaS solution, including platform code and development work completed before the award. This requirement applies to custom code, configurations, interfaces, scripts, documentation, and other project-specific work products developed specifically under this contract.

Q14: Does the ARS control baseline apply at the level of the overall hosting environment or system boundary, or must each integrated software component independently demonstrate full ARS conformance? Will an existing SOC 2 Type II or HITRUST CSF certification for a component be accepted as evidence of equivalent control coverage within an accredited system boundary?

A14: The offeror shall apply the baseline to each software component per the current CMS Acceptable Risk Safeguards (ARS) v5.2. An existing SOC 2 Type II or HITRUST CSF is acceptable.

Q15: Is the requirement to allow messaging and records to be sent between providers and users for clinical encounters intended as a new communication channel within the Case Management Tool itself, or should the proposed solution integrate with and route through the State's existing Health Information Exchange for clinical messaging?

A15: The State anticipates that the Case Management Tool will support connectivity to the State’s existing Health Information Exchange (HIE), where feasible. The specific approach and ability to integrate with the HIE will be determined during implementation based on technical capabilities, requirements, and available interfaces. Offerors should describe how

RFP27-09RHT-026 Questions and Responses Page 6 of 16 their proposed solution could support HIE connectivity while also providing the required messaging and record-sharing functionality.

Q16: Does South Dakota's Health Information Exchange, or another statewide service, currently provide ADT (admission/discharge/transfer) alerting that the Case Management Tool should integrate with, or are offerors expected to establish direct interfaces with individual hospitals? Is ADT the only data required to be searchable or is there a broader utilization data set?

A16: The solution should have the ability to ingest ADT information via HL7 v2.5.1, v2.3.1 and FHIR standards. Direct API capabilities should also be available. The system should be able to provide integrated, multi-sector data to effectively track patient outcomes, coordinate care across different health systems, and manage public health resources.

Q17: Does “primary care referral management” mean managing referrals originated by primary care providers, managing referrals into primary care, or both?

A17: Primary care referral management would include the management of referrals to a primary care provider, as well as referrals the primary care provider completed to a provider outside of the primary care provider’s practice. “Management” of these referrals would include ensuring the patient received care with the preferred provider and appropriate recommended follow up actions were taken.

Q18: Does this requirement mean the Case Management Tool must author clinical documentation itself, ingest and act on documentation authored elsewhere, or maintain a copy of the clinical record?

A18: The Case Management Tool should support both the creation of clinical documentation within the system and the ability to ingest and utilize clinical documentation from external sources. The tool is expected to maintain relevant portions of the clinical record necessary to support case management activities, rather than a complete clinical record.

Q19: This section states that all proposals must be submitted within the total contract ceiling as stated in Section 1 of the RFP. No contract ceiling appears in Section 1 or elsewhere in the RFP. Will the State please provide the total contract ceiling, or confirm that no ceiling has been established?

Section 7.1 states that proposals must remain within the total contract ceiling stated in Section 1; however, a contract ceiling is not identified. Please provide the total available budget or maximum contract value and clarify whether it is intended to cover DDI, licensing/subscriptions, hosting/infrastructure, M&O, and renewal periods.

A19: Offerors should submit their best and final pricing based on the full scope and requirements outlined in the RFP, including all applicable implementation, licensing/subscription, hosting/infrastructure, maintenance and operations, and renewal costs.

Q20: Given the breadth and complexity of RFP #27-09RHT-026, including the detailed technical and functional requirements, multiple hosting options, Security and Vendor Questionnaire, required diagrams, project plan, cost proposal, contractual terms, and supporting documentation, would the State consider extending the proposal submission deadline by four to six weeks to allow Offerors sufficient time to prepare a complete and responsive proposal?

A20: The State is unable to extend the proposal submission deadline. Due to required CMS Rural Health Transformation (RHT) funding timelines and associated implementation deadlines, the State must proceed with the dates established in the RFP.

Q21: Section 6.3 limits the Executive Summary to no more than two pages. Section 1.12 also requires proprietary information to be specifically identified and justified in the Executive Summary. Please clarify whether the proprietary information identification and justification

RFP27-09RHT-026 Questions and Responses Page 7 of 16 must be included within the two-page Executive Summary limit. If so, would the State consider increasing the Executive Summary page limit to accommodate this required information?

A21: The two-page limit applies to the substantive Executive Summary described in Section

6.3. Any identification and justification of proprietary information required by Section 1.12 may be included as an attachment or addendum to the Executive Summary and will not count toward the two-page limit.

Q22: Section 7.3 requires a detailed, itemized budget in spreadsheet format; however, we do not see a prescribed Cost Proposal Workbook or pricing template included with the RFP.

Please confirm whether the State will provide a standardized Cost Proposal template/workbook that all Offerors must use. If so, please provide the template and associated pricing instructions.

A22: The State will not provide a standardized Cost Proposal template or workbook. Offerors should submit a detailed, itemized budget in spreadsheet format in accordance with the requirements outlined in Section 7.3.

Q23: Attachment C states that the Security and Vendor Questionnaire is considered confidential and will not be released to the public pursuant to SDCL 1-27-1.9. Please confirm whether Attachment C should be submitted as a separate confidential file and whether the Offeror is required to identify or justify proprietary information contained within Attachment C elsewhere in the proposal.

A23: Attachment C can be submitted as a separate file in the Microsoft Word format provided.

As stated in Attachment C, the completed Security and Vendor Questionnaire is considered confidential and will not be released to the public pursuant to SDCL 1-27-1.9. Offerors are not required to separately identify or justify proprietary information contained within Attachment C elsewhere in the proposal.

Q24: The RFP references a Requirements Traceability Matrix (RTM) Plan. Please clarify what the State means by RTM Plan and what is expected from Offerors in response to this requirement.

A24: The Requirements Traceability Matrix (RTM) should identify and track the requirements outlined in the RFP and demonstrate how the Offeror’s proposed solution addresses each requirement. At a minimum, the RTM should reference the applicable RFP requirement, indicate how the proposed solution meets the requirement, and identify any relevant supporting documentation or proposal section.

Q25: Section 3 states that the Offeror’s proposal must summarize its understanding of the State’s needs as an “Executive Summary” and limits the Executive Summary to no more than two pages. Please clarify where the Executive Summary should be placed within the proposal and whether it is intended to serve as the response to Section 3 or as a separate section of the proposal.

A25: The Executive Summary should be included as a separate section of the proposal and should not replace the Offeror’s detailed response to the requirements outlined in Section 3.

The Executive Summary should provide a high-level summary of the Offeror’s understanding of the State’s needs, proposed approach, expertise, capabilities, and understanding of the project scope and deliverables, and must not exceed two pages.

Q26: Section 6.8 requires Offerors to complete the Security and Vendor Questionnaire (Attachment C) in the Microsoft Word format provided by the State. The RFP also states the proposal to be submitted in PDF format. Please clarify how the completed Attachment C should be submitted. Specifically, should the completed Attachment C in Microsoft Word format be submitted as a separate file or should it be converted to PDF and included within the consolidated proposal submission?

RFP27-09RHT-026 Questions and Responses Page 8 of 16

A26: The completed Security and Vendor Questionnaire (Attachment C) may be submitted as a separate Microsoft Word file in or can be converted to PDF.

Q27: Please provide anticipated named-user and peak concurrent-user counts, broken out by role and organization type, including State program staff, administrators, care coordinators, case managers, social workers, clinicians, community health workers, provider staff, Tribal partners, carceral-setting users, reporting users, and support personnel. Please also confirm whether the State and participating organizations will provide these operational and clinical personnel, or whether the selected offeror is expected to provide any clinical or case-management staffing.

A27: For preliminary planning purposes, the State anticipates up to approximately 100 users, although the specific breakdown by role and organization type has not yet been finalized.

Anticipated participants include approximately three Tribal partners and up to 60 carceral settings that may initiate referrals. Additional users may include community health workers, community mental health center staff, care coordinators, case managers, clinicians, and other personnel responsible for receiving, managing, and tracking referrals.

The State has not yet established named-user or peak concurrent-user estimates by role or organization type. These estimates are preliminary and subject to change as implementation planning progresses. Offerors should propose a flexible and scalable solution to accommodate varying user roles and participation levels.

Q28: Please provide the anticipated number of participating organizations and physical locations at initial go-live and full deployment, broken out where possible by primary care practices, Rural Health Clinics, Federally Qualified Health Centers, Tribal partners, carceral settings, and other participating entities. Please also indicate whether all organizations are expected to participate at go-live or through phased rollout waves.

A28: The State has not yet finalized the anticipated number of participating organizations or physical locations at initial go-live or full deployment. Preliminary estimates include up to 60 carceral settings. The number of participating primary care practices, Rural Health Clinics, Federally Qualified Health Centers, Tribal partners and other participating entities has not yet been established.

The State has not established a required pilot, phased rollout, or regional deployment approach at this time. Offerors should propose a recommended implementation and rollout approach based on their solution, experience, and industry best practices, including any recommended sequencing of populations or organizations. Specific State resource assignments, decision and approval timeframes, provider outreach and onboarding responsibilities, and acceptance and sign-off criteria have not yet been finalized. These items will be defined collaboratively with the selected Offeror during project planning and implementation. Offerors should identify their assumptions regarding State participation and clearly describe their recommended roles, responsibilities, acceptance criteria, and governance approach within their proposal.

Q29: Please identify the authoritative source and business rules for member alignment or attribution to participating practices. Is the selected offeror expected to calculate attribution, or will the State transmit completed member-to-practice assignments?

A29: The state will complete the members’ practice assignments, but the offeror should have the ability to intake this information and further attribute and manage those assignments within caseloads and to allow for further tracking of the assignments and caseloads.

Q30: Please identify the standard reports, dashboards, measures, and regulatory or program-governance outputs required for the initial release, including an estimated count and required refresh frequency. Please also clarify:

whether direct database or warehouse access is required, whether Power BI, ESRI, or

RFP27-09RHT-026 Questions and Responses Page 9 of 16

Tableau will connect directly to the solution data, required API or file-export formats, required export frequency and latency, whether the State has a required data model or repository schema and whether the State requires access to transactional data, curated data, or both.

A30: The State prefers direct access to the underlying database to enable authorized State agencies and users to independently create customized reports and perform data analysis as needed.

Q31: Please provide the State’s desired production go-live date or maximum acceptable implementation duration following contract execution. Please identify any required pilot, phased rollout, or regional deployment approach, including the populations and organizations expected in each phase. Please also identify:

the State resources expected to support requirements, interfaces, migration, UAT, training, and provider onboarding.

Expected State decision and approval timeframes.

The parties responsible for provider outreach and onboarding; and the acceptance and sign-off criteria for implementation, interfaces, migration, security, performance, training and production go-live.

A31: The State has not established a required pilot, phased rollout, or regional deployment approach at this time. Offerors should propose a recommended implementation and rollout approach based on their solution, experience, and industry best practices, including any recommended sequencing of populations or organizations. Specific State resource assignments, decision and approval timeframes, provider outreach and onboarding responsibilities, and acceptance and sign-off criteria have not yet been finalized. These items will be defined collaboratively with the selected Offeror during project planning and implementation. Offerors should identify their assumptions regarding State participation and clearly describe their recommended roles, responsibilities, acceptance criteria, and governance approach within their proposal.

Q32: In addition to Production and the required test system, please confirm whether the State expects separate development/configuration, training, and disaster-recovery environments.

Section 4.2.10 requires a test system that is a mirror image of the production code base.

Please clarify whether the State expects separate development, test/SIT, UAT, and production environments, or whether a single continuously available test environment in addition to production will satisfy this requirement. Will the State provide masked/de-identified representative test data for State and interface testing?

A32: Yes. The State will require four separate environments. The test environment should mirror the production code base to support consistent testing, promote quality software development, and reduce the potential for rework or deployment issues. The State will provide appropriate test data as needed to support testing activities.

Q33: Please clarify the intended division of responsibility among the State, BIT, participating providers, and the selected offeror for:

Tier 1 service-desk intake, access assistance, and technical triage.

Tier 2 functional and application support, including navigation, case-management workflows, care plans, referrals, reporting, and other “how-to” questions.

Tier 3 product, integration, hosting, infrastructure, and engineering support; and Clinical, Medicaid policy, or programmatic questions that require State or provider subject-matter expertise.

Please also provide:

Required service-desk hours and any after-hours or on-call coverage.

Required support channels, such as telephone, email, portal, or chat.

RFP27-09RHT-026 Questions and Responses Page 10 of 16

Incident severity definitions.

Required response, update, escalation, and resolution targets.

Expected monthly ticket volumes.

The State’s service-management or ticketing platform and any required integration.

Whether the selected offeror is expected to provide direct support to State staff, care coordinators, case managers, social workers, clinicians, participating providers, and/or members.

Whether the State expects a separate clinician or functional help-desk capability, or whether a single service desk with escalation to functional application support is acceptable and whether functional support personnel must have clinical credentials, case-management experience or other specific qualifications.

A33: The selected vendor will collaborate with the State’s Bureau of Information and Technology (BIT) team. Additional information will be provided upon selection. The scope of services and coordination requirements will depend on available resources and the vendor’s capacity to deliver the required services. Prospective vendors are encouraged to include a detailed service delivery model in their proposals.

Q34: Section LXI states that security audits must meet PCI DSS requirements irrespective of whether PCI DSS data is involved. Please clarify which specific PCI DSS requirements, assessment methodology, testing activities, and evidence the State expects to apply to a system that does not process, store, or transmit payment card data.

A34: All proposed applications must support and be compatible with applicable PCI DSS security and audit requirements, including vulnerability scanning, penetration testing, intrusion detection, file-integrity monitoring, network-segmentation testing, unauthorized-device detection, and continuous security monitoring. The solution must not prevent or interfere with the State’s ability to perform or implement these required security activities and controls.

Q35: Attachment B requires NIST SP 800-63 Assurance Level 3 for remote access, while Section LXV requires hosted-system MFA to meet at least Level 2 Authentication Assurance.

Please clarify which assurance level applies to application users, privileged administrators, vendor personnel, and remote access to the proposed solution.

A35: Application users, vendor personnel, and remote users must meet a minimum of Authentication Assurance Level 2 (AAL2). Users with privileged or administrative access must meet Authentication Assurance Level 3 (AAL3).

Q36: Please confirm whether offshore personnel may perform development, configuration, and testing using synthetic data, without access to State data or production systems, while all State data storage, processing, and disaster recovery remain within the United States.

A36: The State of South Dakota requires all development, configuration, and testing activities associated with the proposed solution to be performed within the United States.

Q37: Please clarify the intended member alignment/attribution methodology to participating primary care practices. Will the State provide the authoritative member-to-practice attribution file/rules, or is the Case Management Tool expected to calculate attribution? Please also identify the anticipated frequency of attribution updates and whether retroactive adjustments or manual overrides must be supported.

A37: The State will be responsible for completing member-to-practice assignments. However, the proposed solution must have the capability to receive this information and support further attribution, caseload management, and ongoing tracking of member assignments and caseloads. The solution should also support flexible attribution frequency, including the ability to make retroactive adjustments and manual overrides.

Q38: The RFP requires support for Medicaid Enterprise System eligibility for enhanced Federal Financial Participation and documentation supporting APD submissions. Can the

RFP27-09RHT-026 Questions and Responses Page 11 of 16

State clarify the specific CMS certification outcomes, APD artifacts, federal funding documentation, or MES standards the Contractor will be expected to support?

A38: There are no specific CMS certification outcomes, APD artifacts, federal funding documentation, or additional MES standards have been identified beyond the requirements stated in the RFP. The selected Contractor will be expected to support applicable CMS and federal requirements as necessary throughout the project.

Q39: Can the State identify the initial chronic disease programs, quality measures/care-gap measures, and validated SDOH screening tool(s) expected for PACT implementation? Please also clarify whether specific CMS Core Set, HEDIS, State-defined, or PACT-specific measures must be available at initial go-live.

A39: The State has not yet finalized the initial chronic disease programs or quality and care-gap measures for PACT implementation. However, the State anticipates that the initial measures will include a subset of HEDIS measures. Offerors are free to propose options for validated Social Determinants of Health (SDOH) screening tools.

Q40: For inpatient hospital stay and discharge notifications, can the State identify the anticipated source of the notifications and the applicable events/thresholds, including the “designated length of stay” criteria? Should the solution expect to receive these notifications through an HIE/ADT feed, directly from hospitals, or another State-designated source?

A40: The solution should have the capability to receive inpatient hospital stay and discharge notifications from multiple sources, including directly from hospital Electronic Health Record (EHR) systems, through a Health Information Exchange (HIE) feed, or from another State-designated source.

Q41: The solution must maintain member data history for up to ten years and support migration from legacy systems. Does the State expect the Contractor to migrate ten years of historical data at implementation, or does the ten-year requirement apply to retention after implementation? Please identify the anticipated legacy source systems, data domains, approximate data volumes, available extract formats, and responsibility for source-system extraction.

A41: No, the State does not anticipate requiring the Contractor to migrate ten years of historical data at implementation. The ten-year requirement applies to the solution’s ability to retain member data following implementation. Specific legacy source systems, data domains, data volumes, extract formats, and responsibilities for source-system extraction have not been finalized and will be determined during implementation in collaboration with the selected Contractor.

Q42: For justice-involved youth eligible for up to 90 days of targeted case management, can the State further define the required workflow, including the participating carceral settings, referral/intake process, user roles, eligibility information, transition-of-care activities, and systems/interfaces with which the Case Management Tool must exchange information?

A42: The Case Management Tool should support the tracking and management of referrals from carceral settings to Targeted Case Management (TCM) services, as well as subsequent referrals from TCM to recommended services, such as primary care visits and other appropriate community-based services. Carceral settings may refer individuals under the age of 21 with active South Dakota Medicaid coverage to TCM services beginning 30 days prior to release, once adjudicated, with services continuing for up to 60 days following release into the community. The solution should have the capability to receive referral information from multiple sources and through various methods, including but not limited to fax, online submission, direct data entry, and electronic interfaces. Receiving entities, such as community health workers and TCM case managers, should have the option to manage and track referrals and submit supporting data and documentation either through integration with

RFP27-09RHT-026 Questions and Responses Page 12 of 16 their existing documentation systems or through manual entry within the Case Management Tool. There are approximately 50–60 carceral settings statewide that may initiate referrals for TCM services and approximately 50 TCM entities receiving referrals. Given that the specific systems and technical capabilities of these facilities have not yet been fully identified, the State expects the proposed solution to provide flexibility in its integration and data exchange capabilities to accommodate various referral sources and methods as they are identified.

Q43: For closed-loop community resource referrals, does the State currently use or plan to use an existing community resource directory/referral platform that the solution must integrate with, or is the Contractor expected to provide and maintain the resource directory, referral workflow, and outcome tracking capability within the Case Management Tool?

A43: The State does not currently use or have plans to require integration with a specific community resource directory or referral platform. Offerors should describe the capabilities available within their proposed solution to support community resource referrals, referral workflows, and outcome tracking, as applicable.

Q44: Section 3.2 states that offerors must demonstrate full compliance with each mandatory functional requirement, while Section 4 permits offerors to identify noncompliance and provide a workaround or future compliance date. Please clarify whether a workaround or future compliance date is acceptable for a Section 3.2 mandatory functional requirement, and at what point full compliance must be achieved.

A44: The offeror should structure its response to demonstrate full compliance with the requirements outlined in the statement of work. The information provided in Section 4 offers the State an additional option to consider if none of the responses satisfies the mandatory requirements. This approach will enable the State to select the partner offering the most viable roadmap for achieving full compliance.

Q45: Please specify the required HL7 FHIR version, USCDI version, and applicable implementation guides/profiles expected for PACT interfaces. For example, should offerors assume US Core and/or specific Da Vinci implementation guides, or will the applicable profiles be determined during implementation?

A45: The required interoperability standard is FL7 FHIR R5.

Q46: The RFP requires the solution to function reliably with minimal or unstable internet connectivity. Is a true offline/disconnected operating mode with subsequent synchronization required, or will a low-bandwidth-optimized, mobile-responsive connected application satisfy this requirement?

A46: The State will consider either solution approach for this project. Regardless of the approach proposed, the selected solution must support timely data synchronization and initiate data transfer as soon as connectivity and sufficient bandwidth are available, rather than relying solely on scheduled batch transfers.

Q47: Regarding Tribal data sovereignty, can the State identify any specific Tribal data-sharing agreements, consent requirements, data segmentation requirements, access restrictions, storage requirements, or Tribe-specific governance requirements that the proposed solution must accommodate?

A47: The State will provide the selected vendor with the relevant information necessary to support and ensure application functionality.

Q48: For SMS and alternative communication channels, does the State have an existing enterprise messaging service that the Contractor should utilize, or should the offeror include an SMS/messaging service in its solution and pricing? Please also clarify whether PHI may be communicated through SMS and whether specific member consent/opt-out requirements must be supported.

RFP27-09RHT-026 Questions and Responses Page 13 of 16

A48: The State does not currently have an enterprise SMS service available for contractor use. SMS functionality is outside the scope of this project and is not intended to be used for the communication or transmission of PHI.

Q49: Section 4.2.2 states that the State will own all data tables and must be able to manipulate data, access raw data, and develop dashboards using tools such as Power BI, ESRI, and Tableau. For a vendor-hosted/SaaS solution, does the State require direct database/table-level query access, or would State ownership and access be satisfied through complete data replication/export, APIs, and/or a State-controlled analytical repository?

A49: The State requires access to raw data to create queries and dashboards for its agencies. For vendor-hosted or SaaS solutions, acceptable options include direct database or table-level access, data replication, or API export to a State-controlled repository.

Q50: For a solution deployed in the State’s Azure tenant, can the State provide the applicable Azure landing-zone standards, permitted regions/services, networking/security patterns, and responsibility model? Please also clarify whether the Contractor is responsible for application-level backup, cross-region recovery, and the stated RTO/RPO, or whether any platform-level backup/DR capabilities will be provided by BIT.

A50: The State will provide applicable Azure landing-zone standards, approved regions and services, network and security patterns, and the defined responsibility model. The selected offeror will be expected to work collaboratively with the Bureau of Information and Telecommunications (BIT) to support system availability, resiliency, and timely recovery following a security incident, system disruption, or application failure.

Q51: Please clarify the State’s identity architecture for State staff and external provider/Tribal users. Will all application users receive identities through the State’s identity-management service, or should the solution support federation/B2B identities for external organizations?

Please also confirm the required protocol and whether the State expects automated provisioning through standards such as SCIM, SSO claims/groups, or another mechanism.

A51: The State will work collaboratively with the selected offeror to ensure the proposed solution meets the State’s Single Sign-On (SSO) standards and applicable authentication and access requirements.

Q52: Section 3.4 requires full audit logging for a minimum of six years, while Attachment A Section XVI requires access-attempt logs to be maintained for not less than seven years.

Please confirm the audit-log retention period that should be used for solution design, storage sizing, and pricing.

A52: For purposes of solution design, storage sizing, and pricing, Offerors should use a minimum audit-log retention period of seven (7) years.

Q53: For NIST SP 800-53 Rev. 5 Moderate and CMS ARS requirements, please clarify the expected compliance evidence. Is the Contractor expected to provide a control mapping only, or formal artifacts such as an SSP, security assessment report, POA&M, and/or documentation supporting a State/CMS authorization process?

A53: The selected offeror will be expected to provide both the applicable control mapping and the formal supporting artifacts identified in this question.

Q54: Section 6.8 requires completion of Attachment C – Security and Vendor Questionnaire in the Microsoft Word format provided by the State for each applicable deliverable/hosting option. Attachment C does not appear to be included in the RFP package provided. Please provide the native Microsoft Word version of Attachment C.

RFP27-09RHT-026 Questions and Responses Page 14 of 16

A54:

Attachment C BIT

Security and Vendor

Q55: Does the State anticipate a single statewide go-live or a phased implementation by provider group, geography, program, functionality, or member population? If phased deployment is anticipated, please provide the preferred sequencing or implementation priorities.

A55: The State has not established a required pilot, phased rollout, or regional deployment approach at this time. Offerors should propose a recommended implementation and rollout approach based on their solution, experience, and industry best practices, including any recommended sequencing of populations or organizations. Specific State resource assignments, decision and approval timeframes, provider outreach and onboarding responsibilities, and acceptance and sign-off criteria have not yet been finalized. These items will be defined collaboratively with the selected Offeror during project planning and implementation.