[{"innerBlocks":[],"name":"core\/freeform","postId":175,"blockType":{"name":"core\/freeform","keywords":[],"attributes":{"content":{"type":"string","source":"raw"},"lock":{"type":"object"}},"providesContext":[],"usesContext":[],"selectors":[],"supports":{"className":false,"customClassName":false,"reusable":false},"styles":[],"variations":[],"apiVersion":3,"title":"Classic","description":"Use the classic WordPress editor.","category":"text"},"originalContent":"A data breach at the Centers for Medicare and Medicaid Services has affected the protected health information of about 10,000 Medicare beneficiaries and 30 applications.Early analysis suggests that the leak of information was a result of a series of missed opportunities by CMS and a third-party application partner.For example, the code that caused the bug that created the breach was put in place on Jan. 11, 2018, and there were no follow-up checks for 11 months. \u201cBased on check-in notes around the change, it appears that a comprehensive review was not completed,\u201d CMS acknowledges. \u201cA more comprehensive review may have identified this coding error.\u201dMedicare offers Blue Button, a service that enables beneficiaries to access their own claims data via an application. However, Blue Button has been getting an upgrade, and the code in question likely was installed as a result of this.Beneficiaries use Blue Button to access their own personal Medicare claims data. The bug caused certain beneficiary-protected health information to be inadvertently shared with another beneficiary or the wrong Blue Button application.

CMS uses synthetic data to test Blue Button to verify functionality without risking beneficiary personal health information. But in an attempt to protect beneficiary PHI, integration with other systems, such as the identity management system, was not tested. Experts believe that using early reviews of test scenarios would have found the gaps in security.Other experts contend that cross-team collaboration was not optimal. The code that generates the user ID token was run by a separate identity management team. Assumptions were made by the Blue Button team about how the token works, and those assumptions were not validated.\u201cBetter collaboration across enterprise teams could have ensured that necessary information was present in decision making,\u201d according to CMS.The incident does not affect other CMS beneficiary systems, such as PlanFinder and Medicare.gov. The breach was contained to Blue Button 2.0 API authorized users and developers, and not Medicare beneficiaries more broadly or outside entities.Now, CMS is implementing new processes for documenting code changes and will implement a new approach to audit tracking.\u201cThis wasn\u2019t a hacking; this was an individual coding error,\u201d says Linn Freedman, a cybersecurity specialist at Brown University and a partner at the Robinson+Cole law firm in Providence, R.I.\u201cCMS should not be held to a different standard than any other entity,\u201d Freedman adds. \u201cThis is an incident that is unfortunate, but CMS holds the Medicare health information of everyone over age 65 and Medicaid beneficiaries. They fixed the bug, but it\u2019s unclear if unauthorized content was disclosed.\u201dBrian Murphy, a healthcare industry analyst at the Chilmark data security research firm, says monitoring security status is a standard remedy, but the level of monitoring varies. \u201cMany organizations think they follow standard information security protocols, but the lesson is that there is no amount of perfect preparations and there are always circumstances\u2014to expect perfection is beyond us. CMS needs to redouble efforts and see if other changes need to be made because every breach is an opportunity to learn.\u201dMurphy says he hopes the agency will set an example and disclose more information on the breach\u2014beyond that which most organizations disclose. But he adds that he would not be shocked if CMS hasn\u2019t been breached before, whether the agency knew it or not.CMS has admitted that the breach could have been detected if agency personal and the third-party application partner had conducted a comprehensive view of the entire system, which was not done.CMS has not communicated whether it will offer credit-monitoring services and other protective services to affected individuals.\u201cAfter 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 and a special enrollment period,\u201d the agency noted. CMS did not respond to a request for more clarification on protective services.","saveContent":"A data breach at the Centers for Medicare and Medicaid Services has affected the protected health information of about 10,000 Medicare beneficiaries and 30 applications.Early analysis suggests that the leak of information was a result of a series of missed opportunities by CMS and a third-party application partner.For example, the code that caused the bug that created the breach was put in place on Jan. 11, 2018, and there were no follow-up checks for 11 months. \u201cBased on check-in notes around the change, it appears that a comprehensive review was not completed,\u201d CMS acknowledges. \u201cA more comprehensive review may have identified this coding error.\u201dMedicare offers Blue Button, a service that enables beneficiaries to access their own claims data via an application. However, Blue Button has been getting an upgrade, and the code in question likely was installed as a result of this.Beneficiaries use Blue Button to access their own personal Medicare claims data. The bug caused certain beneficiary-protected health information to be inadvertently shared with another beneficiary or the wrong Blue Button application.

CMS uses synthetic data to test Blue Button to verify functionality without risking beneficiary personal health information. But in an attempt to protect beneficiary PHI, integration with other systems, such as the identity management system, was not tested. Experts believe that using early reviews of test scenarios would have found the gaps in security.Other experts contend that cross-team collaboration was not optimal. The code that generates the user ID token was run by a separate identity management team. Assumptions were made by the Blue Button team about how the token works, and those assumptions were not validated.\u201cBetter collaboration across enterprise teams could have ensured that necessary information was present in decision making,\u201d according to CMS.The incident does not affect other CMS beneficiary systems, such as PlanFinder and Medicare.gov. The breach was contained to Blue Button 2.0 API authorized users and developers, and not Medicare beneficiaries more broadly or outside entities.Now, CMS is implementing new processes for documenting code changes and will implement a new approach to audit tracking.\u201cThis wasn\u2019t a hacking; this was an individual coding error,\u201d says Linn Freedman, a cybersecurity specialist at Brown University and a partner at the Robinson+Cole law firm in Providence, R.I.\u201cCMS should not be held to a different standard than any other entity,\u201d Freedman adds. \u201cThis is an incident that is unfortunate, but CMS holds the Medicare health information of everyone over age 65 and Medicaid beneficiaries. They fixed the bug, but it\u2019s unclear if unauthorized content was disclosed.\u201dBrian Murphy, a healthcare industry analyst at the Chilmark data security research firm, says monitoring security status is a standard remedy, but the level of monitoring varies. \u201cMany organizations think they follow standard information security protocols, but the lesson is that there is no amount of perfect preparations and there are always circumstances\u2014to expect perfection is beyond us. CMS needs to redouble efforts and see if other changes need to be made because every breach is an opportunity to learn.\u201dMurphy says he hopes the agency will set an example and disclose more information on the breach\u2014beyond that which most organizations disclose. But he adds that he would not be shocked if CMS hasn\u2019t been breached before, whether the agency knew it or not.CMS has admitted that the breach could have been detected if agency personal and the third-party application partner had conducted a comprehensive view of the entire system, which was not done.CMS has not communicated whether it will offer credit-monitoring services and other protective services to affected individuals.\u201cAfter 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 and a special enrollment period,\u201d the agency noted. CMS did not respond to a request for more clarification on protective services.","order":0,"get_parent":{},"attributes":[],"attributesType":{"content":{"type":"string","source":"raw"},"lock":{"type":"object"}},"dynamicContent":""}]

Blue Button breach stems from coding issue, data of 10K affected

More for you