Michael Christie wrote: > Hello to all, > We backup our Practice Mx software and Clinical software to a removable > HDD which we take home every night.
As someone else commented, hopefully you use a series of removal HDDs which you rotate. Otherwise you risk overwriting your only good backup with a bad backup. This typically happens if your clinical system database or other data files become corrupted on your server. You then overwrite the last backup of uncorrupted files with a version containing corrupted files. You then discover the corruption in your database and decide to restore from backup, only to find that you only have backups of corrupted versions of the database. Then you are stuffed. Hence the need for backup media cycles. There are many schemes for this - the GFS (somewhat sexist: grandfather, father, son) scheme was popular when I last had to worry about such things five or six years ago. perhaps someone can point to a good online discussion of back-up media rotation schemes. > In the clinical package there is a lot of scanned documents and letters > to specialists which are simple Word files, most of which include Pts > names and addresses and Medicare numbers, and lists of medical problems > of individual pts. > I was thinking, if say my car was broken into and the bag containing the > HDD was stolen there is a risk of patients details being accessed. Damn right. This has been discussed at length several times on the former GPCG_TALk list, the archives of which are available online but alas are not searchable, so I can't point you at that discussion. Pity. > The Clinical and Practice Mx databases obviously could be broken into if > one was a computer expert. (Unlikely I would think in the "normal" car > thief.) But the Word docs are easily accessible by plugging the HDD into > another computer.They are all in a folder called Docs. I wouldn't count on the thickness of the thief. Things like portable hard discs quickly find their way onto the second-hand computer gear market, are traded multiple times in quick succession, and end up in the hands of a university computer science student. Life's like that. > Can my colleagues tell me what does a doctor do if this occurs? Besides > the Police, who would need to be notified regarding this? Your medical defence union, for sure. > Would you need to contact ALL the patients from the surgery , say 10,000 > people re the theft and that it is MAYBE possible that their medical > details have been stolen. I have argued that that would be teh ethical thing to do, but gee, it puts you at grave risk of a class action by some of your patients, particularly if some are lawyers or lawyers get wind of it. > put an ad in the paper? Go on Today Tonight? That would guarantee a class action against you, I suspect. Such an action would not need to prove that the data were misused or even accessed by the thief or whoever ends up with the HDD device - I strongly suspect that just "proving" significant mental anguish at the possibility that confidential medical details might be published on the Internet would be enough to make the courts ruin your whole day. > Is there a way of making access to the removable HDD difficult, say > putting password access to the HDD? Strong encryption, as Horst and others have pointed out, is teh solution. > This problem would obviously apply to stolen backup DVD's and tapes as well. > How do we get around this? Strong encryption of all confidential patient data written to all removable digital media which is to be removed from the surgery and which is not stored in the safe. The same applies to clinical databases hosted on laptops, of course. As Horst mentions, an encrypting file system can be used. Even Windows supports this - again, I have posted details of traps with this to bear in mind on the former GPCG_TALK list, but those posts can't easily be found now. Pity. anyway, you can find tutorials on file system encryption with Windows on the Net via Google - but the default Windows file system encryption is insecure - you need to tweak some Registry entries so that you are forced to enter a password at boot time as Horst notes in order to properly secure it. Tim C > > _______________________________________________ > Gpcg_talk mailing list > [email protected] > http://ozdocit.org/cgi-bin/mailman/listinfo/gpcg_talk > _______________________________________________ Gpcg_talk mailing list [email protected] http://ozdocit.org/cgi-bin/mailman/listinfo/gpcg_talk
