CMS pulled its Blue Button 2.0 API offline after a coding error potentially exposed beneficiary data from about 10,000 patients. The security incident likely began as early as January 2018.
The Centers for Medicare and Medicaid Services has taken its Blue Button 2.0 API offline, as it investigates a coding error that potentially exposed the protected health information of about 10,000 beneficiaries.
The BB2.0 platform is used by Medicare beneficiaries to authorize third-party applications to access their Medicare claims data. The system verifies user credentials through a CMS identity management system, using a randomly generated, unique user ID generated by the system.
According to a CMS blog posting, the agency was contacted by a third-party application partner that reported a data anomaly with the BB2.0. The anomaly was verified and the production environment was immediately suspended.
Want to publish your own articles on DistilINFO Publications?
Send us an email, we will get in touch with you.
A bug was detected in the API’s codebase, which officials said could have inadvertently sent some beneficiary PHI to the wrong recipient or BB2.0 application. CMS is contacting the impacted patients and third-party applications.
“We discovered BB2.0 was truncating a 128-bit user ID to a 96-bit user ID,” officials explained. “The 96-bits remaining were not sufficiently random to uniquely identify a single user. This resulted in the same truncated user ID being assigned to different beneficiaries.”
“Because BB2.0 was truncating the user ID provided by the identity management system, some beneficiaries with the same truncated ID were passed data pertaining to other users via BB2.0,” they added.
The investigation so far has determined that the coding error began on January 11, 2018, and CMS officials determined a comprehensive review of the system was not completed, which could have detected this coding error earlier.
What’s more, CMS uses synthetic data to test the functionality of BB2.0 without risk to PHI. However, integration with other systems like the identity management system were not tested. Again, officials said reviews of test scenarios would have spotted the gap in integration testing.
“The code that generates the user ID token is run by a separate identity management team. Assumptions were made by the BB2.0 team about how the token works and were not validated,” officials wrote. “Better collaboration across enterprise teams could have ensured that necessary information was present in decision making.”
CMS has since enhanced the quality review and validation process to ensure code issues are caught before they are applied to CMS APIs like BB2.0, as well as implementing additional monitoring and alerting to ensure CMS can track BB2.0 use.
The BB2.0 will also be updated to store full user IDs instead of the truncated version. Users will be asked to reauthenticate through the portal to receive a new ID. CMS said the team is also reviewing the code and implementing any necessary changes.
“This technical issue potentially affected less than 10,000 beneficiaries and 50 apps,” officials wrote. “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).”
CMS is also creating new processes for documenting code changes and improvements, such as implementing the use of templates for all code changes that explain the reason, intention, and consequences of the change, descriptive code changes that must be tested beforehand, and a request for comment process that will require developers to document system behavioral changes.
“Test scenarios are reviewed and documented to confirm code has the intended impact,” officials explained. “Before restoring the BB2.0 API, the team will be implementing a layered approach to audit tracking. Auditing will be enabled at the database level, to log from the bottom up, as well as at the API level.”
“This additional logging will provide more details into user activity and provide more traceability into actions taken by the API. Monitoring and alerting will be enhanced to notify CMS of any unexpected changes in the data to ensure unintended changes are prevented,” they added.
The BB2.0 API will remain closed as CMS conducts its review. Officials stressed that the Medicare.gov, Plan Finder, and other systems were not impacted by the error.
This is the second security incident for CMS in a little over a year. The Department of Health and Human Services Office of Inspector General launched an investigation in October 2018 to determine the scope of Healthcare.gov breach that impacted 75,000 beneficiaries.
The timing of the coding error comes as Congress and industry stakeholders make the case for an API framework designed to protect patient health information and other sensitive information, given the risk third-party apps pose to patient privacy. HIPAA does not cover all third-party app use.
Source: HealthIT Security
