Using APIs to Transform the way CMS Shares Medicare Claims Data
summary
CMS reworks a single claims back end into a standards-based platform that serves multiple APIs: beneficiary FHIR data server ingests ETL'd warehouse data and exposes three endpoints (patient, coverage, EOB) via an OAuth pass-through model used by Blue Button 2.0, BCDA and others. It holds six years of records for 61 million beneficiaries, faces ~40% unexpected work requiring reserved capacity, and is piloting developer on‑boarding so partner teams can contribute code while maintaining FHIR/SMART compliance.
AI-written summary · about
chapters (20)
- 0:00Introduction
- 3:12Medicare Claims Data
- 5:40Blue Button 20 API
- 8:50Blue Button
- 9:05Beneficiary Claims Data API
- 11:54BlueButton Identity Crisis
- 12:05What we found
- 12:15The opportunity
- 12:32The rebrand
- 13:03What is the VFD
- 14:30What is the BFD
- 16:20How to be clear
- 17:04Treating the BFD as its own product
- 18:21Planning as an ecosystem
- 19:27Building capacity
- 20:16Whats next
- 21:09Growing the ecosystem
- 21:35Learning from our success
- 22:29Questions
- 23:03Conclusion
related talks
30mCMS: Data at the Point of Care
13mLightning Talks - Leveraging APIs to Transform Healthcare
45mPanel: State Implementation of Patient Access API
20mMastering API Management for Enhanced Patient Care
20mClaims on FHIR
22mAPI’s in public healthcare – case Health Village
42mCMS: Provider API
26mFireside Chat