EHR Vendor Mistake Impacts 150,000 U.K. PatientsCase is Reminder to All Healthcare Entities About Vendor Risks
A coding mistake by an electronic health records vendor has resulted in a data breach impacting 150,000 patients in the United Kingdom.
See Also: A Toolkit for CISOs
The incident also serves as a reminder to all healthcare entities in the U.S. and elsewhere about the variety of risks vendors can pose to the security and privacy of patient data.
In a July 2 statement, NHS Digital - which oversees IT for the U.K.'s National Health Service - says a "coding error" by vendor TPP, which provides the SystmOne EHR system that's used by general practitioners, or GPs, in England, caused data of some patients to be disseminated despite the individuals having opted out of having their information shared for clinical research and planning purposes.
"The TPP coding error meant that we did not receive these preferences and so have not been able to apply them to our data," says Nic Fox, director of primary and social care technology at NHS Digital in the statement.
Affected patients are those that registered a "type 2 opt-out" in a GP practice using SystmOne after March 31, 2015, NHS Digital says.
Fox notes that NHS Digital and TPP have "worked swiftly to put this right and the problem has been resolved for any future data disseminations."
Additionally, he says this issue would not be able to occur in the future because a recently introduced National Data Opt-Out "puts the individual in direct control of their data sharing preferences. Data sharing preferences can now be registered via a simple to use website or by phone or paper form, with the information going directly to NHS Digital rather than being recorded by a GP on a third party system."
In a statement provided to Information Security Media Group, a spokesman for NHS Digital says NHS is taking steps to further mitigate the breach.
That includes NHS contacting organizations with whom it has shared data that may have been affected in the mishap.
"We will be asking those organizations to destroy the data they hold which has not had the opt outs supplied as soon as practically possible, and we would look to resupply data where required," the spokesman says. "In some exceptional circumstances however that may not be practicable - for example where the data has been used for a research project and has been included in a publication, or where the data has subsequently been combined with other data sources - but this will be considered on a case by case basis."
In a statement, vendor TPP says, "the privacy of patient data is a key priority for TPP, and we continually make improvements to our system to ensure that patients have optimum control over information. In light of this, TPP apologizes unreservedly for its role in this issue."
While the incident in the U.K. potentially resulted in patients' data being shared against their wishes with the NHS for research and planning purposes related to improving clinical outcomes, a variety of other incidents involving vendors have resulted in recent major breaches in the U.S., as well.
In some cases, protected health information of U.S. patients was left exposed on the internet by vendors because of coding mistakes, as well as a result of cyberattacks.
For example, Wichita, Kansas-based medical transcription services vendor MEDantex in April said it inadvertently exposed "a few hundred patient records" of the company's 2,300 physician practice clients because of an unsecured web portal following a ransomware attack and mitigation efforts to rebuild its online servers. (See Recent Ransomware Incidents Serve Up Lessons).
California-based Center for Orthopaedics Specialists also in April notified about 85,000 patients that their data might have been compromised in a ransomware attack on an unnamed IT vendor.
Working with the affected IT vendor, COS says it immediately launched an investigation into the matter. "The investigation determined that the unauthorized party began attempting to access our system beginning Feb. 18," the statement notes. "The IT vendor indicated that the affected system was permanently taken offline before any patient information could be removed by the unauthorized party."
But when it comes other recent, major health data breaches involving coding mishaps, as well as other mistakes, such as misconfigured servers, vendors aren't always to blame. Often, healthcare entities themselves have been the culprits.
For instance, in March, a New York-based medical practice's misconfigured database server allegedly left information about thousands of patients - plus staff - exposed on the internet for an unspecified length of time (see Misconfigured Server Exposes Patient Data).
In some of these misconfiguration or miscoding incidents in the U.S., federal regulators have stepped in with hefty enforcement actions.
For example, in 2016, the U.S. Department of Health and Human Services' Office for Civil Rights smacked California-based St. Joseph Health System with a $2.14 million HIPAA penalty after investigating a 2012 breach that left PHI of nearly 32,000 individuals exposed to internet searches for more than a year.
As for whether the recent U.K. incident will draw the attention of European regulators, the NHS Digital spokesman tells ISMG, "this issue initially occurred before the General Data Protection Regulation was introduced but we have reported it to the [U.K.] Information Commissioner's Office in order that they can make appropriate enquiries."
Healthcare entities can take measures to avoid breaches involving their vendors, including the type of data sharing issues that can occur through third-party software, as seen in the case of NHS Digital incident, some experts note.
"Get together with internal stakeholders to agree on acceptable vendor coding and security standards," says Jeannie Warner, security manager at WhiteHat Security, a security vendor.
"Establish controls that third-party vendors must meet before they can be deployed in the organization."
—Jeannie Warner, WhiteHat
"Establish controls that third-party vendors must meet before they can be deployed in the organization. Ask for attestation letters or other certification reviews before employing third-party software on any system that handles personally identifiable information," she says.
Also, entities must communicate their security standards and requirements to the vendors. "Educate them, answer their questions and get their commitment to meeting the standards. Establish a timeline to make them achieve compliance, if they are not already compliant," she says.
Also important: "Monitor the security status of third-party vendors at regular intervals," she adds.
David Holtzman, vice president of compliance at security consultancy CynergisTek notes that organizations outsourcing any process that involves the handling of sensitive personal information face significant financial, regulatory and risk to their reputation if they "bungle" how they select and manage their business partner.
He also emphasizes the importance of vendor monitoring. "Among the steps they should take is to examine any prospective vendor to assure that they have information processes that continually monitor and audit their security management performance. Another step is to manage the work of the business partners' performance of their information security processes including their quality review programs that monitor the confidentiality of sensitive personal information."
Warner notes, "the U.S. Government created the Federal Information Security Management Act to manage the very question of vendor risk - and it's a good guideline to start with, even for non-government entities. We should all be asking our vendors, when they have services or applications which touch our network, 'yes that sounds nice - but what are your security testing methodologies, and how will I know that you patch quickly when someone finds a way to hack your system/application/widget?.'"
She adds: "It's a truth from children's toys to web pages to quick payment apps and games, and we're all waking up to the reality that this is a question we are not used to asking but should."