National Payer Deploys FHIR Member-Access API at Scale

State Medicaid's non-compliance warning landed in March. CMS-0057 Patient Access + Provider Directory APIs were due in July. The payer's internal estimate to comply was 14 months.
Business Challenges
The non-compliance warning from the state Medicaid agency arrived in March 2025. Sandstone Health Plan—a regional Medicaid managed-care organization covering 2.1 million members—had been working toward CMS-0057 Interoperability Rule compliance for 18 months. The internal IT team had built two of the four required FHIR endpoints. The Patient Access API and the Provider Directory API were still in design. The deadline was July. Five months. The internal estimate to complete both APIs was 14 months.
The CIO, Marisa Volkov, had been escalating the timeline risk for six months. The state's warning forced the conversation to the executive committee and then to the board. The board's first question was simple: what does non-compliance look like? The general counsel laid out the consequences: financial penalty (manageable), CMS public-reporting of non-compliance (reputationally damaging), and likely loss of two upcoming state-managed Medicaid contract renewals (existential).
The board approved an emergency budget. The CIO had four months to deliver the APIs. The internal team couldn't do it. The procurement process for an outsourced engagement had to be compressed to two weeks. The technical scope had to be deterministic — fixed timeline, fixed deliverables, fixed price.
- State Medicaid non-compliance warning issued in March; CMS-0057 deadline in July (5 months).
- Internal IT estimate to complete the Patient Access + Provider Directory APIs was 14 months.
- Member data spanned legacy claims, care-management, and authorization systems with no consolidated FHIR layer.
- Provider directory data was duplicated across 4 source systems with conflicting truth.
- The engineering team had no in-house FHIR R4 expertise; outsourcing estimates from large systems integrators ran $2.4M.
Solution
The procurement was compressed to nine days. Three vendors responded. eCareConnect was the only one that committed to the 4-month delivery timeline at a fixed price below $1M. The other two vendors quoted 6–8 month timelines at $2M+.
The selection conversation centered on a specific operational question: how would the vendor handle the provider directory data-quality problem? The Patient Access API was a relatively straightforward FHIR R4 build. The Provider Directory API was operationally harder because the source data was inconsistent across the four internal systems. Sandstone needed a vendor who would solve the data-quality problem as part of the engagement, not flag it as a Sandstone problem to solve before integration could begin.
eCareConnect's deployment lead proposed a master-provider-record build as part of the engagement. The platform would consolidate the four source systems into a single canonical provider record, resolve the duplications and conflicts, and surface a data-quality dashboard for Sandstone's network management team to maintain ongoing. The proposal turned a data-quality risk into an operational asset. That framing closed the procurement.
Value Delivered
The two APIs went into production three weeks ahead of the CMS deadline. The state Medicaid agency closed the non-compliance warning within 30 days of the production go-live. The CIO's board update in August framed the engagement as "the policy deadline we made on the math, and the data-quality problem we fixed on the side."
- 3 weeks early — Patient Access + Provider Directory APIs in production; state non-compliance warning closed.
- $640K — total spend against vendor estimates of $2.4M, 73% under budget.
- 100% — FHIR R4 endpoint test-suite pass rate on independent compliance audit.
- 73% → 97% — provider directory data quality across the four source systems, via the live master provider record.
- Full audit trail — on every member API access event, required for regulatory reporting.
Solution Provided
The deployment ran 14 weeks. The eCareConnect team treated the deadline as binding and managed the work in two parallel streams: the API build and the data-quality consolidation.
Weeks 1–3: Source System Discovery and FHIR Schema Mapping
The first three weeks were technical discovery. eCareConnect's data engineers mapped Sandstone's claims, care-management, authorization, and provider-network source systems against the CMS-0057 FHIR R4 schema requirements. The output was a documented mapping that became the build specification.
Weeks 3–7: Patient Access API Build
The Patient Access API came up first because the data was cleaner — member coverage, claims history, and care-plan information lived in well-structured source systems. By week 7, the Patient Access API was in Sandstone's staging environment with full test-suite coverage.
Weeks 5–11: Provider Directory + Master Record Build
The Provider Directory work overlapped with the Patient Access work. The data consolidation was the harder problem. The four source systems had conflicting truth on roughly 14% of providers — different addresses, different specialties, different accepting-new-patient status. eCareConnect's data team built resolution rules in collaboration with Sandstone's network management team. By week 11, the master record was clean and the API was in staging.
Weeks 11–14: Production Deployment and Compliance Validation
The final three weeks were production deployment and independent compliance audit. An external auditor ran the CMS-0057 conformance test suite against both APIs; both passed at 100%. The state Medicaid agency was invited to review the deployment and confirmed compliance within two weeks of production launch.
The data-quality dashboard that wasn't in scope but mattered
The provider master record exposed a data-quality dashboard that Sandstone's network management team began using as a daily operational tool. Provider records that drifted from accuracy were flagged automatically. The network team's quarterly data-cleanup project—which historically consumed two FTEs for four weeks—became a continuous low-effort process. The dashboard wasn't a scoped deliverable; it was a side effect that became a permanent operational capability.
Business Value
Marisa presented the engagement to the board in late summer 2025. The framing was that Sandstone had solved a regulatory compliance problem and simultaneously built operational data infrastructure the organization had needed for years.
What the engagement preserved
The two state-managed Medicaid contract renewals that had been at risk closed on their original terms. The combined revenue across those contracts was approximately $340M over five years. The engagement preserved the foundation of Sandstone's business.
The financial picture against the alternative
The $640K engagement cost compares to a $2.4M alternative-vendor estimate, plus the avoided regulatory penalty, plus the preserved contract revenue. The strict cost-benefit math is favorable by a wide margin. The CIO has been clear that the strict math understates the impact; the regulatory posture change has reduced Sandstone's operational risk profile in a way that doesn't fit into a single number.
What changed about Sandstone's IT roadmap
The successful FHIR R4 build positioned Sandstone to absorb subsequent interoperability rules with much less infrastructure work. The Prior Authorization API requirement that came into effect 12 months later took 7 weeks to deploy because the underlying FHIR infrastructure was already in production. Sandstone's IT team has internalized the master-data-management capability and now applies it to other operational domains.
The CIO's summary line
"The deadline was the gift. Without it, we would have been on the 14-month timeline and the data-quality problem would have continued to slide. The forcing function produced infrastructure we should have built years ago. We are operationally better than we were before the warning arrived."

