CMS shuts down access to Blue Button 2.0 temporarily due to security glitch
The Centers for Medicare and Medicaid Services has closed off access to its Blue Button 2.0 production environment after a third-party app developer alerted the agency to a bug in its code base that could lead to exposure of some patients' protected health information.
WHY IT MATTERS
In a blog post that details the root cause of the issue, CMS notes that the glitch in the BB2.0 codebase "may be causing certain beneficiary protected health information to be inadvertently shared with another beneficiary or the wrong BB2.0 application."
Essentially, the problem stems from the fact that the system was truncating 128-bit user IDs to 96 bits, which "were not sufficiently random to uniquely identify a single user."
CMS contacting affected beneficiaries and third-party applications directly, and have closed access to BB2.0 pending a full review.
"This technical issue potentially affected less than 10,000 beneficiaries and 30 apps. It was contained to Blue Button 2.0 API authorized users and developers – not Medicare beneficiaries more broadly or outside entities," officials said.
"CMS will communicate directly with affected beneficiaries in the coming weeks through a letter. After the agency completes an in-depth analysis of the impact to affected beneficiaries, CMS will determine necessary additional protections to offer affected beneficiaries (e.g., credit monitoring, a Special Enrollment Period)."
Beneficiaries can also call 1-800-MEDICARE with questions.
In the meantime, officials note that BB2.0 developers have put in place an "enhanced quality review and validation process to ensure code issues like this one are caught before any new code is committed to BB2.0 or any CMS APIs. The team is implementing additional monitoring and alerting for BB2.0. This will enhance CMS’s ability to track BB2.0’s use."
CMS also said that, once services is restored, all users will have to re-authenticate with BB2.0 enable generation a new user ID.
THE LARGER TREND
Blue Button 2.0 is an API with four years of Medicare Part A, B and D data for 53 million Medicare beneficiaries – information about their type of Medicare coverage, drug prescriptions, primary care treatment and cost. It uses HL7's FHIR standard for beneficiary data and the OAuth 2.0 standard for beneficiary authorization.
In the Blue Button 2.0 sandbox, hundreds of developers are able to build and test applications using synthetic sample beneficiary data.
CMS specified that the security issue only impacts BB2.0, not Plan Finder, Medicare.gov, or any other system.
"We have not detected any intrusion by unauthorized users and system integrity has not been compromised by any external source," officials added.
The impacted applications, according to CMS:
- Advise delivered by Ascend Quote & Enrollment
- Allwell - Absolute Total Care delivered by Ascend Quote & Enrollment
- Allwell - Arizona Complete Health delivered by Ascend Quote & Enrollment
- Allwell - Arkansas Health & Wellness delivered by Ascend Quote & Enrollment
- Allwell - Buckeye Health Plan delivered by Ascend Quote & Enrollment
- Allwell - Home State Health delivered by Ascend Quote & Enrollment
- Allwell - Louisiana Healthcare Connections delivered by Ascend Quote & Enrollment
- Allwell - Magnolia Health Plan delivered by Ascend Quote & Enrollment
- Allwell - Sunflower Health Plan delivered by Ascend Quote & Enrollment
- Allwell - Superior Health Plan delivered by Ascend Quote & Enrollment
- Ascension Complete - Florida
- Ascension Complete - Kansas delivered by Ascend Quote & Enrollment
- Enroll Hero
- Get Your Health Record
- Human API
- Medicare Suggest
- Project Baseline
- Project Seamless
- Prominence Health Plan delivered by Ascend Quote & Enrollment
- Rush University Medical Center
ON THE RECORD
"The root cause for the incident is clear and CMS is taking steps to better understand how this bug occurred," said agency officials in the blog post. "The current BB2.0 team has a strong culture of code review in place. The code that caused this bug was committed on January 11, 2018. Based on check-in notes around the change, it appears that a comprehensive review was not completed. A more comprehensive review may have identified this coding error."