As adoption of the Blue Button 2.0 API (BB2.0 API) grows, the CMS Blue Button team continues to look at ways to improve the API and stay current with evolving standards. A primary goal for CMS with the BB2.0 API is to help beneficiaries make more informed choices about the applications they use and the data they share. To enhance the security and privacy posture for Medicare beneficiaries using the BB2.0 API, we are pleased to announce the following changes to our service:
As adoption of the Blue Button 2.0 API (BB2.0 API) grows, the CMS Blue Button team continues to look at ways to improve the API and stay current with evolving standards. A primary goal for CMS with the BB2.0 API is to help beneficiaries make informed choices about the applications they use and the data they share. To enhance the security and privacy posture for Medicare beneficiaries using the BB2.0 API, we are pleased to announce two changes to the API:
On July 22nd, the Blue Button 2.0 team will make a change to apply a minus sign prefix to the Patient Identifier, the FHIR ID, in the patient records in our sandbox environment. This change will ensure that synthetic records are formatted the same way in both the sandbox and production environments.
On Tuesday, February 12th at HIMSS19, CMS Administrator Seema Verma announced the publication of the list of the production applications connected to the Blue Button 2.0 API on Medicare.gov – you can find the list at: http://go.cms.gov/bluebuttonapps. This announcement demonstrates CMS’ ongoing commitment to MyHealthEData, a government-wide initiative to empower patients by giving them control of their healthcare data and allowing it to follow them through their healthcare journey.
Developers, you asked if we could update Part D prescription claims more frequently than monthly. We heard you!
Introducing Native Mobile App Support
Installing a Client App Using Docker
This is the second in a series of posts in which we work step-by-step through installing, configuring, and running our new sample applications.
Over the past several weeks the Blue Button 2.0 team had been reviewing feedback from our developer community about new features you would like to be added to the API.
As we prepared for our first Blue Button 2.0 Developer Conference we wanted to add to our
portfolio of sample client applications.
Check out our new sample applications. The links to the GitHub repositories are in an earlier blog post here: https://bluebutton.cms.gov/blog/More-Sample-Applications.html
The Google Support forum is a vibrant place. We are always monitoring comments and questions there.
The Blue Button team is continually working to improve the Blue Button 2.0 API and the supporting documentation. When the API was announced at HIMSS in March 2018 it created a lot of interest. That interest came not just from developers wanting to connect to the API and work with the data it contains, but also from other organizations around the healthcare industry, such as insurers and Medicaid agencies. For the latter category of technologists there is significant interest in how The Blue Button team built the Fast Healthcare Interoperability Resource (FHIR) records that hold the beneficiaries’ data.
One of the frequent questions we get is: How does a beneficiary grant access to their claims information to an application?
As we prepared to launch our Production Blue Button 2.0 API we wanted to test the API from the perspective of a third-party client application.