South Dakota DSS, Medicaid PACT case management tool (RFP# 27-09RHT-026)

Recommendation: do not bid. The queued check asked whether Medicaid claiming is in scope and how many seats are involved. I have the full RFP and both answers are now clear. Medicaid enterprise scope is central to the ask. Seat count is never stated, and it no longer matters, because four separate rubric hard disqualifiers appear in the document.

The requirement that kills it

Section 4.2.3, Single Sign-On Requirements:

The State's SSO supports the industry standard OAuth 2.0 protocol. This identity management will handle password recovery and multi-factor authentication (MFA). MFA is required for all application Administrators and may be required for other users. The State's SSO requirement and links to Microsoft's official documentation can be found at: https://www.sd.gov/bit?id=bit_standards_single_sign_on If the offeror is not able to fulfill this identity management standard, the offeror's proposal will be rejected from consideration.

Carepatron cannot meet this today. Supported sign-in is email and password with MFA, plus Google and Apple SSO (known-gap-no-microsoft-365-sso). The state points offerors at Microsoft's documentation, so this is Entra ID federation. The clause is not a scoring deduction. It is an explicit instruction to reject the proposal, so a bid would be disqualified on receipt regardless of how well the rest of it read.

Three more disqualifiers, each independently fatal

System eligibility for enhanced federal financial participation (FFP)". Section 3.3 requires secure data exchange with "Medicaid enterprise systems". Section 3.6 requires "Documentation necessary to support Advance Planning Document (APD) submissions" and "Documentation supporting enhanced federal funding eligibility". Section 3.2 puts "claims/encounter" data in the longitudinal member record, and section 3.4 requires support for "42 CFR Part 2 protections where applicable". This is the Medicaid claiming pattern the rubric names as an automatic skip.

notifications for designated length of stays, clinical and case management updates, discharge notifications, and overdue activities", and to "Allow specific searchable fields and queries by hospital, admission status, recipient information, and dates". That is an ADT feed. Carepatron has no HL7 or FHIR interfaces and no ADT feeds (known-gap-no-hl7-fhir).

states: "Your proposal must include options for On-Prem and Vendor Hosted solutions, and State Cloud Hosted if your solution is a Platform as a Service (PaaS) solution." Section 7.1 repeats this, requiring a separate cost proposal for "a state-hosted on-prem solution". Carepatron is cloud-only multi-tenant SaaS and has no on-premise or customer-tenant deployment option.

Requirements we would fail even without the above

These do not change the call. They are recorded so nobody re-opens the file thinking the SSO clause is the only obstacle.

The buyer is also wrong for us on its face. This is a state payer building programme infrastructure to administer a shared-savings model across clinics, RHCs, FQHCs and Tribal partners. It is not an outpatient practice buying an EHR. The rubric flags exactly this class of opportunity as the honeypot to resist.

What would change the call

Nothing inside this procurement. Entra ID SSO, FHIR interfaces and a contractual uptime commitment are three separate roadmap items, and even all three together would leave the Medicaid enterprise and on-premise requirements standing. South Dakota DSS is not a buyer Carepatron can serve.

The narrower signal worth keeping is that the state wants "an option for small or remote primary care providers without their own care management tool to participate in the PACT model" (section 3.1). Those providers are closer to the ICP than the state is. They are not reachable through this RFP, which contracts with one vendor at the state level.

Corrections made to the stored record

The radar held facts that the document contradicts.

The 3 October date came from the posting board rendering the deadline in Eastern time, which pushes it past midnight. The state's own document says 2 October.

One further correction, for accuracy rather than action. Starbridge described this as "an invitation-only vendor procurement". The posting board does label it Invitation Only, but it applies that label to all 35 current opportunities, including rest area cleaning contracts. Section 1.4 of the RFP says "All interested offerors may submit a Letter of Intent to respond to this RFP". The solicitation is open. The label is a portal default, not a restriction.

How I read it

Recorded because the route was not obvious and will recur. The ESM Solutions posting board is an Angular application that curl cannot read, and its own detail API returns 404 to anonymous callers. Two things still worked without a login or an account:

1. Firecrawl rendered the detail page at /<board-uid>/eventDetail/<eventId>, which carried the solicitation number, the contact and the full event description.
2. The board's attachment bundler is open to anonymous callers. validateeventvisibility reported isLoginNeededToDownloadDocuments: false, and downloadalleventattachments?eventId=...&totalCount=2 returned a base64 zip holding the complete 100 page RFP and Attachment C.

No account was created and no terms were accepted.

Assessment

Score 12 of 100. Product fit near zero against four hard disqualifiers. Buyer fit near zero, since the buyer is a state payer rather than an outpatient provider. Winnability near zero: this is systems integrator work, priced against a contract ceiling, evaluated on NIST 800-53 Moderate controls and APD documentation. Recorded as SKIP so it does not resurface.

No action for Carlos.