5 lessons from implementing CMS APIs at Medicaid scale

At HIMSS26, I had the chance to present alongside the New Jersey Innovation Institute (NJII) on something that doesn’t get covered honestly enough at conferences: what it actually takes to go from a CMS mandate to working, production-grade FHIR APIs. At Medicaid scale. 

The project was implementing the CMS Patient Access and Provider Directory APIs for New Jersey’s statewide Medicaid program, serving around 1.8 million members. Five months from start to production. 

These are the lessons from that experience that I think apply well beyond New Jersey.

5 things to get right

1. Identity is harder than infrastructure 

Most implementation conversations start with the FHIR server: which product, which cloud, which configuration. Most teams have that part covered. What tends to catch people off guard is identity. 

How do you verify that the person requesting their health data is actually who they say they are, at scale, without making it so painful that nobody bothers? 

For a statewide Medicaid population, this question carries real weight. A significant portion of Medicaid beneficiaries are elderly or living with disabilities, populations for whom a cumbersome verification process isn’t just an inconvenience, it’s a barrier that prevents access entirely. That means the identity solution has to be simple, accessible, and battle-tested. 

Integrating with an established digital identity network like ID.me addresses this directly. Many state residents already have an ID.me account from prior interactions with government services, which eliminates the need to create yet another portal login. ID.me also provides 24/7 live support to help users complete verification, a critical backstop for beneficiaries who may need guidance navigating the process. 

Combined with an Enterprise Master Patient Index (EMPI) service, verified identities are automatically matched to the correct patient records across the system, making registration as seamless as possible while still maintaining the high security standards the data demands. Together, this approach meets NIST 800-63-3 identity assurance standards and reduces friction without compromising security. 

Identity isn’t a downstream concern to revisit after the server is running. For a population this vulnerable, it needs to be part of the conversation from day one.

2. Your data quality problem will become your API quality problem 

FHIR APIs don’t create clean data. They expose whatever is already in your system. If your source data has inconsistencies, duplicates, or gaps, those problems show up directly in your API output. No amount of good implementation work fixes that. 

This is especially true when you’re transforming large volumes of legacy claims data into FHIR. AI-assisted development can speed up the mapping work significantly (which matters a lot when you’re working to a tight deadline), but AI is only as good as the data you give it. Feed it inconsistent source data and you get confidently wrong FHIR resources at scale. 

What makes the combination of AI and FHIR work well in practice is structure. FHIR defines clear, detailed rules about what data should look like, built up over years of development across hundreds of organizations. When AI is used alongside a FHIR validator/tool/SDK that enforces those rules, it gets continuous feedback on the mappings it generates, catching errors before they reach production rather than after. 

AI brings the speed; FHIR brings the guardrails. Together they can compress months of mapping work, but only if the source data is solid enough to work with in the first place. 

Validating continuously against CMS Implementation Guides is what catches the errors before they reach production. The real lesson here: understand your source data quality before you set your timeline, not halfway through.

3. A working endpoint isn’t the same as a usable one 

Passing the compliance check means your API meets the technical requirements. That’s not the same as patients being able to rely on it. 

For that, you need error rates low enough that third-party apps stay connected, response times fast enough that the experience doesn’t frustrate people, and data that’s fresh enough to be meaningful. 

Things like targeting a sub-1% error rate, setting data freshness expectations, and doing real load testing aren’t compliance requirements, but they’re what separates an API that technically exists from one that people actually trust. 

These targets need to be set early, not treated as something to check at the end. If patients can’t rely on the API, they won’t use it, and the whole investment was for nothing.

4. Deadline pressure reveals what you didn’t plan for 

Working to a regulatory deadline concentrates the work, but it doesn’t leave room for the things that are hard to anticipate. 

The pressure of a hard go-live date has a way of bringing up questions that are difficult to answer until you’re deep in the work: who owns cloud deployment, what happens when test data shows up late, which features actually need to be live on day one versus which ones can wait. 

Large amounts of historical data (including claims records, coverage data, and provider information) take time to transform, validate, and load. Rush that work and things start to break. 

The teams that handle this best are the ones who have an honest conversation early about what’s truly required for launch and what isn’t. Getting that agreed and documented before the work starts is worth far more than trying to do everything at once under pressure.

5. Interoperability is ecosystem management, not just API availability 

Getting the Patient Access API live is the prerequisite. What makes it actually useful is everything around it: apps that patients can choose from, a way for those apps to register and be vetted, admin controls so the right people can manage access, and alignment with 21st Century Cures Act requirements. 

This piece tends to get pushed to the bottom of the list, yet it’s often the first thing patients run into. A developer portal isn’t optional. It’s how the API becomes something patients can actually use. An endpoint without an ecosystem around it isn’t really interoperability.

Compliance is the floor. Trust is the goal. 

CMS mandates exist for a reason: to give patients real access to their own health information. 

Meeting the technical requirements gets you to the starting line. What really matters is whether the system works reliably, the data is accurate, and patients can easily get what they came for. That’s where the work really is. 

If you’re working through CMS API implementation and want to compare notes, feel free to reach out.