For four years, ending in 2004, I was Director of Informatics for the HIV/AIDS clinic at the University of Alabama-Birmingham. During that time I led a project to create an EHR. Starting with one programmer and myself, over the course of my tenure, the staff grew to include an in-house tech support position, a systems admin, a full-time programmer, a HIPAA specialist, a terminology specialist, and a few part-timers who helped in important ways.
The clinic was the main center for outpatient HIV/AIDS care with about 65 full-time employees, which included dental staff and other services. When I accepted the position, the clinic had electronic databases that contained information used for research and patient care. My job was to make patient care data completely electronic (or as much as possible). I relished the idea of creating an EHR from scratch. However, one thing I had not given much thought to at the outset was managing computing for 65 employees and clinicians. Although my title was Director of Informatics, my role also encompassed all the usual duties expected of a Director of Information Technology.
Managing purchase requests and deciding who got a new computer, though trying at times, was not unpleasant. However, security concerns gave me nightmares—literally. Good security is a mixture of paranoia and fanaticism, neither of which makes for good mental health.
Security is one of those things that is easy to talk about, but hard to do. Balancing the needs of users against the rights of patients can be draining. For example, I made a policy that any computer connected to the clinic’s network could not have a CD writer; this did not go over well. My objections stemmed from the fact that, at the time, the computer in question (and all others) had access to sensitive databases. A shared password (or one written on a sticky note) could easily have led to a catastrophic data loss.
As the time to deploy the EHR approached, the practical aspects of protecting data that needed to remain essentially secret increased my anxiety. Every computer in the clinic had Internet access—a door out is a door in…
The security plan for the clinic evolved out of the need to keep HIV data secret—not confidential—secret. As a result, the security plan had multiple layers. The clinic’s LAN was shut off from outside access. Wireless access was limited to devices that had certificates generated by my staff. The EHR and clinical data resided on a separate server from other clinic information, and access to all servers was strictly controlled by user role, and in some cases, computers were limited to specific servers. The wireless signal was mapped to determine how far beyond clinic walls it could be detected, and grad students in the engineering school were allowed to try and skirt our security to look for weak points.
The increasing number of ransomware incidents has brought long-distant memories back to the forefront. Identify theft has always been an issue, but complete takeover of practice files could lead to even worse crimes such as blackmail of patients. I had access to talent that most small practices cannot match. My network admin is now a high-level security manager for a major software firm, and my lead programmer now works for one of the major inpatient EHR companies. While small practices may seem like small targets, they are also easy pickings. A practice of two-three clinicians has more than enough patient data to be a good target, and also such practices are more likely to have potential security weaknesses that go unnoticed.
Practices with on-site servers may have security issues of which they are unaware: default passwords on systems software, remote access turned on by default, unencrypted data at-rest, wireless network on the same subnet as the wired network, weak wireless security, a wireless signal that is broadcast far beyond the clinic, data unintentionally exposed to internet access, employee mobile devices with malware, unpatched software, and many others.
Few practice administrators are security experts. Unfortunately, hiring good security people requires some knowledge of security practices. Even then, finding good people is difficult. Once, I tried to hire a Windows NT server administrator. The job description asked for five years of experience. I interviewed more than 20 people and most could not answer basic server admin questions. One even confessed, after a few questions, that many of his listed qualifications were false, and then had to nerve to ask if that would alter his chances of getting the job!
NIST has produced a great cybersecurity framework, but I doubt most practices could make sense of it without expert help. However, it is a good starting point for interacting with potential security firms in determining how good they might be at protecting one’s practice.
I have been trying to figure out the best way to offer practical advice to small practices, which is proving to be challenging because little of it can be implemented by the reader without help. With that in mind, I decided the following could be useful to anyone sufficiently concerned (read paranoid and willing to be fanatical) about securing his/her patient data.
Conduct a HIPAA risk assessment
Conduct a complete HIPAA risk assessment—not one just good enough to say you did it—but one designed to look for real threats and weaknesses. Ideally, have the risk assessment done by a company other than the current (or potential) security firm partner. That way the HIPAA risk assessment personnel can act as reviewers of whatever security personnel implement—two heads (firms) are better than one.
Hire a security firm
Do not let a friend or relative handle security unless he/she is a security professional.
Reserve a server solely for patient data, and limit access to that server to specific devices and people. If wireless access is offered to patients/public, put that on a separate network.
Viruses, passwords, email, and updates
Have virus protection for all systems, use strong passwords and keep software updated. Do not have remote access enabled by default for admin access to desktops or servers—turn it on only when needed. Use a VPN for all remote accesses to the practice network.
Emails can be an easy route to malware. Disable links in emails by default. It may also be a good idea to limit which devices in the practice have Internet access.
Many database systems allow for encryption of data while stored on disk drives so that any unauthorized accesses will obtain only encrypted data.
Security plans should include provisions for disaster recovery and business resumption. Accordingly, arrange for off-site, real-time backup of key data. Use fault-tolerant servers with mirroring locally. One can never have too many ways to protect vital information. Plan for disaster recovery with the idea that if a tornado, gas leak, or other problem levels the practice to the ground, wherever the new office is, the data will be ready the moment you are.
In the age of ransomware and potential add-on crimes directed against patients, such as blackmail, security takes on renewed urgency. It has been many years since I was directly responsible for protecting patient data. Even so, reading about practices hit with ransomware still puts a knot in my stomach.