The Centers for Medicare and Medicaid Services (CMS) has found that a vulnerability in its Blue Button 2.0 API that allowed access to the protected health information of 10,000 Medicare beneficiaries.
Access to the Blue Button API has been temporarily disabled while the CMS reviews the situation and completes a thorough code review. The CMS has not created a timeline for when the Blue Button 2.0 service will be turned back on.
On December 4, 2019, the CMS was warned of a data anomaly with the Blue Button API by a third-party application partner. The CMS revealed that the data anomaly and immediately suspended access to the production environment while the matter was looked into.
The CMS found that the anomaly was caused by a coding bug. That bug may have permitted data to be shared with incorrect Blue Button 2.0 applications and the wrong beneficiaries. The CMS found that 30 applications have been impacted by the bug.
The Blue Button platform is utilized by Medicare beneficiaries to authorize 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 disclosed with the correct third-party applications.
The CMS found 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 given 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 passed to other users and applications via Blue Button 2.0.
The mistake and why it resulted in the impermissible sharing of claims data are perfectly comprehended, what was not at first obvious how the bug was introduced and why it was not found in time to prevent the exposure and sharing of sensitive beneficiary data.
There are three takeaways from the initial results of the investigation linked to code reviews, testing, and cross team collaboration.
The CMS investigation discovered that the bug was introduced on January 11, 2018. When amendments are made, there is usually a thorough review of the changes, but in January a comprehensive review was not carried out. If the review had taken place, the bug could have been identified and addressed before any sensitive information was accessed.
The CMS tests Blue Button 2.0 using synthetic data to verify functionality. This ensures that no personal health information is put in danger. Integration of Blue Button 2.0 with other systems is not tested in order to safeguard personal health information. Due to this, integration with the identity management system was not tested.
The CMS notes that the code that creates the user ID token is run by a separate identity management team. The Blue Button 2.0 team made assumptions about how the token operated, and they were not validated. If there was stronger collaboration between enterprise teams, the necessary information would have been in existence for decision making.
Measures have now been taken to prevent further mistakes from happening in the future. An enhanced quality review and validation process has now been put in place and the Blue Button 2.0 team will be performing thorough 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 instead of truncated IDs.
A complete review of the platform is now being carried out and the API will remain suspended until that coding review has been finished.
An in-depth review will also be completed to determine the possible impact on impacted beneficiaries.