ICO probes NHS clinic's data blunder that exposed HIV+ status of 800 patients The ICO is looking into a data blunder at 56 Dean Street, a sexual health clinic operated as part of Chelsea and Westminster NHS Foundation Trust, after it emailed the HIV positive status of nearly 800 patients to the entire group. The data breach was committed through the email circulation of the clinic's "OptionE" newsletter …
Despite the obvious horror of the situation, reading the following nearly made me wet myself...
A second email was quickly circulated in an attempt to recall the previous email, requesting recipients delete the previous email. However this, again, included the email addresses of all recipients in the "To" field.
...and, continuing the obvious farce theme, can't see the intended benefit of the inevitable "never happen again" pledge: Why bother... hardly matters any more, does it?
You clearly don't understand how Exchange and Outlook work when it comes to recalling email. They will use the same To:, Cc: and Bcc: settings as the original email that is being recalled. That of course is not helped by having 780 individual recipients in the To: box, and said blunder that led to the recall is repeated one more time.
Per Dr Alan McOwan, Chelsea and Westminster hospital NHS trust’s director for sexual health: "We recalled/deleted the email as soon as we realised what had happened."
Recall is only possible for in-house clients on the same server. So IT was not involved before this inadvised reaction, cos they'd have told him that. It's called compounding stupidity.
I've had this happen in the past with regards to a role requiring DV clearance. The agency in question emailed with the names in the to: field.
They then did the same thing by asking us to delete it, again using the To: field.
And finally an apology, but this time using the Bcc field.
Alas there's no accounting for user stupidity at the end of the day.
When I ran a forum many years ago, because I didn't want to be seen by my ISP as spamming, on the rare occasions I needed to send bulk mail, I scripted it with delays after ever hundred or so. The beauty being it sent to each user individually rather than in a single, bulk, message. But this was more down to the crappy forum software being flaky rather than the need for maintaining privacy. :)
These are always great when they are accidentally started at a large company.
Then the inevitable "Please delete me from this list" messages start.
Then the inevitable "Please stop sending delete me from this list messages" start.
Then the inevitable "Don't you realise that by sending the 'please stop replying to this email' you're making it worse?'.
Ah the fun.
" did not use the “BCC” field to protect those patients' identities, and instead listed all of them in the "To" field."
haha!! classic This used to happen regularly in the old days when Businesses were making there way onto the net with the aim of turning it into a shopping mall. Not seen it for a feew years . ah nostalgia....
Also, it's sometimes 'good manners' and often sensible to let recipients know who else has a copy of the email, especially in a business environment.
And the best bit about letting the recipients know who else is being copied in is to make sure that the recipient knows their (big scary) boss knows. Or the PFY. Or the accountants. Or whoever will be very pissed off if the problem is not fixed. That's the purpose of cc'ing emails.
@Mahatma Coat
While there might be merit in changing the presentation, in reality that's all you'd do, as you'd be mapping something non-standard onto the underlying email system, because you have to remain compatible with older systems that work on those header field.
Sure, the actual headers in a message are (mostly) informational rather than directional, but not exclusively so. If you designed fields like Cc and so on out of an email client to make the interface clearer - and I'm not quite sure how you could do that - you'd confuse plenty of people who wouldn't be quite sure what's going on.
At worst, you might accidentally re-invent X400 ;)
Why there are still not safeguards in email clients in 2015, I just have no idea.
I would hazard guess that it's all Microsoft's fault:
1) for handing out Outlook Express free to retail customers since donkey's years ago. With no money to be made, there was little incentive to develop third party email clients, and as a result very little was done.
2) for monopolising the enterprise software world, so that again, there was no competition and no development. "Hey! You wanna a ribbon? You gotta ribbon". But nothing that actually made bulk emailing easier and more secure.
I have to occasionally send out a newletter to several thousand colleagues, and the poor quality of Outlook for this purpose is truly dispiriting. Not only are there no safeguards on too many names in the To/CC fields, but the whole way that Outlook manages large contact lists is such a mess you have to assume that the designers wanted it to be a mess.
Microsoft's fault?
Exchange is more than happy having a send limit.
It's equally trivial to have it check for emails that contain key words, you know, like HIV, and present tooltips and even policies preventing the behaviour we've just witnessed.
If anything Microsoft provide pretty comprehensive DLP tools in Exchange. Just needs a competent admin to... You know... Administer it.
Wouldn't it be lovely if there were admins around to help out with this sort of stuff, or at least enough of them?
One of the problems with that, of course, is the utterly simplistic way in which we look at NHS funding. The instant someone says "X% of staff are non-clinical" then someone starts wailing about too much management, when money should be being spent on patient care instead. And, hounded by tabloid dogs, administrators at the top of the tree decide not to replace people lower down. Then, you end up with clinical staff wasting time filling in forms to order drugs, or people who don't have the right skills looking after things like sending out email newsletters or departmental email servers.
(And, I daresay, once lots of money from an IT budget has been squandered on a big "joined up" project that ultimately goes nowhere and gets cancelled, there's probably not as much left around to sort out things like this, either).
Why there are still not safeguards in email clients in 2015, I just have no idea.
Not just in the client. It's highly unlikely that anyone typed in all 780 addresses, so this must have come from some internal database and mass-mailing program. What sort of braindead mass-mailer puts even more than 1 address into the To: field?
Once again, the blame will be on the individual making the copy-and-paste mistake. Or maybe their immediate supervisor.
And nobody will ask the really important questions. Like, why the hell are they using desktop email programs send out newsletters? And why do they have no safeguards in place (like leak prevention rules on their mailserver) to prevent this? They are working in the most privacy-sensitive medicine branch, why don't they have management-level data protection people? Or if they have them, what kind of qualification do they have?
But of course it's much easier to fire some secretary for "not following the rules."
You'd think that every individual who worked in the medical profession, even as non-medical staff, would have some awareness of privacy and data protection issues and think twice. And sometimes there is only one individual to blame. A private physio I used a while back did exactly the same thing and mailed his newsletter CC'ing all his patients - he didn't even seem aware that he was supposed to register his data processing with the ICO and really couldn't see what the problem was. It sometimes seems like everyone takes the day off when the data protection lecture is scheduled.
NHS staff are required to complete Information Governance training (annually, using an online tool) I believe, so it's difficult to believe that this cc'ing incident could be due to lack of understanding about data protection. That said, they did it twice!
I can well imagine the person who made the mistake must be feeling mortified; if they're in a role that involves them having contact with clinic users, they're going to have some very awkward conversations.
You would hope that many of the people who receive the email will delete it and treat anything they learn from it with the same respect that they would hope others will have with regard to their own status.
Things could get very messy, however, if people see names or addresses that they recognise and jump to conclusions, like assuming that a name they recognise might be the person that passed the virus on to them.
And, as the linked blog post mentions, this could cause trust issues not just for current clinic users, but for people who don't yet know their status, and may be reluctant to be tested. Some random tests (mouth swabs in bars) have suggested that as many as a third of people who are HIV+ don't actually know their status. That's a key area for improvement in fighting HIV, as modern treatments can reduce viral load to make transmission much less likely. So I hope that, amongst all the talk that will undoubtedly come from this, people remember that it's still important to get tested.
"The Guardian quoted a spokesbeing who claimed that the breach was caused by a human error and added that the particular employee responsible was distraught."
No... actually 'the human error' was not committed by 'the human' that is understandably 'distraught'. It was in fact committed by 'the human' who did not suitably lock down the system in order to prevent such 'human errors'.
Of course I am guessing that the 'chosen scapegoat' is the person who, with minimal or improper training, hit send and not the 'other scapegoat' who is also 'distraught' because they did not set up the system to minimise the opportunity for such 'problems'.
Of course we will not mention 'Duh Manglement'.
Using a non-medically designed/tested application (the email client - probably Outlook) in a medical environment. A medical application would not allow a client list to be sent by anything other than bcc(OK, "should not" and likely legally actionable fail if it did).The reason being obvious: lower immediate costs.
If the clinic is anything like my office, the person who usually sends the email is probably on holiday, along with most of his/her colleagues. The email was probably sent by someone who had never done it before.
Although BCC is obviously the correct option in this case, my employer's email guidelines advises against using it, due to the slightly under-hand uses it can be put to.
"ICO probes NHS clinic's data blunder that exposed HIV+ status of 800 patients"
Except it didn't. What it did do, was to release the names and email addresses of those on a mailing list. Yes, I know, that in itself is inexusable, but not quite the level of horror that some headlines have been screaming.
One made it seem that it was the Names and Addresses (not email addys) as well as their HIV status that was revealed. Simply being on the mailing list (as confirmed by the clinic) was not confirmation that they had HIV.
Yes, indeed, the clinic has commented that being on the list is not necessarily indicative of status, though given that it was a list primarily concerned with treatment and management, I can't help feeling that largely what they're doing is giving people plausible deniability.
There may well be people on there who have a professional interest, or are (for instance) partners or carers. So it is indeed completely wrong to draw any conclusions from the presence of anyone's address. Nevertheless, a lot of people are likely to do so.
As a couple of people have blogged elsewhere, if you wish to get angry about this, it's probably far more productive to be angry abut a world where someone's status is such an issue than over an unfortunate mistake.
what's all this rubbish about BCC? If you have subscribers, set up a distribution list. That is - supposing you are stupid enough to send sensitive material by email in the first place. Such sheer incompetence leaves the mind boggled.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
