The Centers for Medicare and Medicaid Services (CMS) found a bug in its Blue Button 2.0 API which compromised the protected health information (PHI) of 10,000 beneficiaries of Medicare. Because of this, CMS temporarily suspended access to the Blue Button API while the investigation and extensive code review are ongoing. It is not yet certain when is the resumption of the Blue Button 2.0 service.
On December 4, 2019, a third-party application partner notified CMS about the data anomaly associated with the Blue Button API. The CMS affirmed the data issue and promptly halted access to the system affected while investigating the matter.
The CMS identified the anomaly caused by a coding bug, which potentially permitted data sharing with the wrong Blue Button 2.0 apps and the incorrect beneficiaries. The CMS confirmed that the bug affected 30 applications.
Medicare beneficiaries use the Blue Button platform to permit third-party apps, services, and research systems to gain access to their claims information. A CMS identity management system confirms user information by means of a randomly created unique user ID, which makes certain the sharing of the right beneficiary claims information with the right third-party apps.
The CMS identified a coding bug in the Blue Button 2.0, which truncates a 128-bit user ID to a 96-bit user ID, which lacks randomness. Therefore, a similar truncated user ID was issued to a number of beneficiaries. That further resulted in the passing of the claims data of beneficiaries having similar truncated user ID within the identity management system to other end users and programs through Blue Button 2.0.
It was perfectly clear what is the mistake and why it led to the impermissible disclosure of claims information. What was unclear at the beginning was how the introduction of the bug happened and why it was not immediately identified to avoid the compromise of sensitive beneficiary information.
There are three points to note from the preliminary investigation findings associated with testing, code reviews, and cross-team collaboration.
According to the findings of the CMS investigation, the bug was brought in on January 11, 2018. When there are changes introduced, there is normally a thorough review of the modifications, however, in January there was no comprehensive review. If there was a review, CMS probably identified the bug and fixed it before the disclosure of any sensitive data.
The CMS checks Blue Button 2.0 employing synthetic information to confirm functionality. This makes certain that no PHI is at stake. Incorporating Blue Button 2.0 with other systems was not examined so as to safeguard PHI. As a result, there was no testing done when it was incorporated into the identity management system.
The CMS remarks that a separate identity management team operates the code that creates the user ID token. The Blue Button 2.0 team assumed that the token worked well, and did not validate it. If the enterprise teams had better collaboration, both had the required information when making decisions.
CMS already took the steps to stop more errors later on. A better check and validation process is now in place and the Blue Button 2.0 team is going to do thorough checks of all new code to make sure to identify coding errors and correct them prior to making the code changes live. The Blue Button 2.0 will now keep complete user IDs and not truncated IDs.
A complete platform review is currently being done and the API will stay temporarily suspended until the completed coding review.
CMS will also conduct a detailed analysis to find out the possible impact on beneficiaries and make decisions about the other necessary steps to safeguard impacted beneficiaries, for instance offering credit monitoring services.