The Interoperability and Patient Access final rule requires CMS-regulated payers to implement and maintain a secure, standards-based Patient Access API using Health Level 7® (HL7) Fast Healthcare Interoperability Resources® (FHIR) 4.0.1 that allows patients to easily access their claims and encounter information through third-party applications of their choice.
The Blue Button 2.0 API team is excited to announce feature enhancements that will enable third-party partner applications to request only the claims data they need. These enhancements will allow apps to request certain claim types, such as Medicare Part D Pharmacy Claims (PDE), or only request new claims information since the last updated date.
Update – December 27, 2019: The Centers for Medicare & Medicaid Services (CMS) has conducted a full review of Blue Button 2.0, corrected the faulty code, implemented additional protections, and is resuming normal operations of the system.
The technical issue discovered on December 4th only impacted 30 authorized Blue Button 2.0 applications (apps). These apps will be able to reconnect to the Blue Button 2.0 API after providing CMS with written confirmation that they have implemented a plan to address incorrect data in their app. CMS has been working closely with app developers and appreciates their cooperation in resolving the matter as quickly as possible to ensure patient privacy is protected. If you have any questions, please reach out to BlueButtonAPI@cms.hhs.gov.
As adoption of the Blue Button 2.0 API (BB2.0 API) grows, the CMS Blue Button 2.0 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:
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 2.0 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 2.0 team built the Fast Healthcare Interoperability Resource (FHIR) records that hold the beneficiaries’ data.
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.