PHI of 10,000 Medicare Beneficiaries Exposed in CMS Blue Button 2.0 Coding Bug
The Centers for Medicare and Medicaid Services (CMS) has found that a bug in its Blue Button 2.0 API that exposed the protected health information of around 10,000 Medicare beneficiaries. Access to the Blue Button API has been temporarily disabled while the CMS investigates and finished an in-depth code review. The CMS has not given a timeline for when the Blue Button 2.0 service will be back online.
On December 4, 2019, the CMS was warned to a data anomaly with the Blue Button API by a third-party application partner. The CMS confirmed the data anomaly and immediately disabled access to the production environment while the matter was reviewed.
The CMS determined the anomaly was caused by a coding bug. That bug potentially permitted data to be shared with incorrect Blue Button 2.0 applications and the wrong beneficiaries. The CMS found that 30 applications have been affected by the bug.
The Blue Button platform is used by Medicare beneficiaries to allow third-party applications, services, and research programs to view their claims data. A CMS identity management system verifies user details through a randomly generated unique user ID, which ensures the proper beneficiary claims data is shared with the correct third-party applications.
The CMS found that a coding bug was causing Blue Button 2.0 to truncate a 128-bit user ID to a 96-bit user ID. A 96-bit user ID is not sufficiently random and, due to this, the same truncated user ID was assigned to different beneficiaries. That meant that some of the beneficiaries with the same truncated user ID in the identity management system had their claims data shared with other users and applications using Blue Button 2.0.
The mistake and why it lead to the impermissible disclosure of claims data are perfectly understood, what was not initially obvious was how the bug was introduced and why it was not found in time to stop the exposure and disclosure of sensitive beneficiary data.
There are three takeaways from the initial findings of the inquiry related to code reviews, testing, and cross team collaboration.
The CMS investigation discovered that the bug was introduced on January 11, 2018. When changes are made, there is usually a thorough review of the changes, but in January an in-depth review was not finished. If the review had taken place, the bug could have been identified and corrected before any sensitive information was shared.
The CMS tests Blue Button 2.0 using synthetic data to verify functionality. This means that no personal health information is put in danger. Integration of Blue Button 2.0 with other systems is not tested in order to secure personal health information. Due to this, integration with the identity management system was not tested.
The CMS notes that the code that produces the user ID token is run by a separate identity management team. The Blue Button 2.0 team made assumptions about how the token was deployed, and they were not validated. If there was better collaboration between enterprise teams, the necessary data would have been present in decision making.
Steps have now been taken to stop further mistakes from occurring in the future. An enhanced quality review and validation process has now been created and the Blue Button 2.0 team will be performing comprehensive reviews of all new code to ensure that any coding mistakes are identified and corrected before the code changes go live and Blue Button 2.0 will now store full user IDs and not truncated IDs.
A complete review of the platform is now being conducted and the API will remain disable d until that coding review has been finished.
An thorough analysis will also be conducted to determine the potential impact on impacted beneficiaries. Decisions will then be made about what other steps are necessary to protect impacted beneficiaries, such as the provision of credit monitoring services.