States don’t need their own API sandboxes, code samples or developer support to enable 3rd party developers to adopt the new Medicaid APIs required by the CMS Interoperability and Patient Access Rule.
The rule basically says each state Medicaid plan (and many other types of plans) needs to “build their own Blue Button API” as many state health IT people say.`
I was part of the team that built the CMS Blue Button API. We had to do a few things:
- Map claims data to FHIR, setup a FHIR server, build an auth service, setup an API gateway
- Build a developer portal with a sandbox, docs, sample apps, production API access process and more.
- Procure the project in a way there was long-term investment in continuous improvement to the infrastructure, APIs and developer experience.
My friend Sam’s blog post Building your own Claims API from 2018 is a great read to better understand what our CMS team did and you’ll have to do for your state.
Because all states will be using the FHIR and OAuth standards, all of their APIs should be pretty much the same. This is super important because it means that states shouldn’t build their own sandboxes, docs or sample apps.
Let’s build a coalition
A group of states and organizations should get together and build an API sandbox. This will give developers a chance to play around with the APIs and prototype them into their own apps.
There should be a github site with a bunch of sample apps or build on CMS’s github along with more tutorials like Install an Angular Client App.
I’m looking forward to seeing what thought-leaders like the CARIN Alliance, CMS, vendors and states will do to bring people together here. Sharing things like a Blue Button sandbox will save taxpayer dollars and accelerate time-to-market for most states.
Happy Building!
Kelly Taylor's Blog 