A bug in the Blue Button 2.0 API codebase has potentially exposed the protected health information of 10,000 beneficiaries and caused the Centers for Medicare & Medicaid Services to pull the service offline.
Blue Button 2.0 is a standards-based API that gives Medicare beneficiaries the ability to connect their claims data to apps and services they trust.
In a blog post, CMS said a third-party application partner reported a data anomaly with the Blue Button 2.0 API on Dec. 4. CMS verified the anomaly and immediately suspended API access. The bug could cause beneficiary PHI to be shared with another beneficiary, or the wrong Blue Button 2.0 application, according to the post.
CMS said access to the API will remain closed while the agency conducts a full review, and restoration of the service is pending. The agency has not detected intrusion by unauthorized users or an outside source.
The incident is playing out against a backdrop of federal regulators like CMS pushing for healthcare organizations to use APIs that would give patients greater access to their health data. Yet a concern among healthcare CIOs is that the drive toward interoperability is ahead of app developers’ technical ability to safely facilitate that sharing of health data, said Clyde Hewitt, executive advisor for healthcare cybersecurity firm CynergisTek Inc., in Austin, Texas.
“There is a massive push for data interoperability, and organizations that spend a lot of time looking at the security and privacy issues around this realize that the need to share data is probably outrunning the technical savvy of the developers to get solid interface specification,” Hewitt said.
Medicare beneficiaries authorize third-party apps to use their Medicare claims data through Blue Button 2.0, and the Blue Button 2.0 system verifies users through a CMS identity management system. The identity management system uses a code to provide randomly generated, unique user IDs, which Blue Button 2.0 uses to identify each beneficiary.
The data anomaly was “truncating” user IDs from a 128-bit user ID to a 96-bit user ID, which was too short to be sufficiently random to “uniquely identify a single user,” according to the blog post. As a result, Blue Button 2.0 began assigning the same user IDs to different beneficiaries.
The root cause of the problem is unclear. CMS said the code causing the bug was implemented Jan. 11, 2018 and that a comprehensive review of the code was not completed at the time, which may have identified the coding error.
CMS also said the identity management system code was not tested, stating that “assumptions were made” by the Blue Button 2.0 team that the identity management system code worked but was not validated.
The coding error should be a warning to healthcare organizations as they march toward interoperability and the use of APIs, according to Hewitt. They should, for example, put greater emphasis on regression testing, which is used to make sure a recent code change hasn’t negatively impacted existing software. CMS failed to do just that.
“You can’t make changes to your system without looking at how it’s going to impact other systems,” Hewitt said. “As this spider web continues to grow, doing an end-to-end test becomes more and more complicated.”
What CMS is doing now
The Blue Button 2.0 team has implemented a new review and validation process to make sure coding errors are caught before being implemented within Blue Button 2.0 or other CMS APIs, according to the blog post.
The team is also adding additional monitoring and alerting for Blue Button 2.0, and CMS is updating Blue Button 2.0 code to store full user IDs instead of shortened versions, meaning all users will be asked to re-authenticate with Blue Button 2.0 so the system can generate new user IDs.
Fewer than 10,000 beneficiaries and 30 apps were affected by the issue, CMS said, and it was contained to Blue Button 2.0 users and developers. The issue didn’t affect Medicare beneficiaries who do not use the API.
Before bringing the API back online, CMS said the Blue Button 2.0 team will be adding additional auditing layers at the API database level, as well as the API level to give more details into user activity and provide greater traceability to actions the API takes. Monitoring and alerting capabilities are also being enhanced to notify CMS of unexpected changes in data.
David Chou, vice president and principal analyst at Constellation Research in Cupertino, Calif., said while the PHI exposure from this incident may not be as damaging as in other incidents, if CMS discovers more security issues after it conducts its review, it will cause alarm in the industry.
“This is a learning experience and I am optimistic that CMS will get past this with a new and improved Blue Button,” he said.
Yet Chou believes the Blue Button 2.0 initiative has been a good thing overall, and said CMS should be recognized for their effort to improve interoperability in healthcare.
Go to Original Article