HIPAA Privacy versus HIPAA Security
But most of the effort historically has concentrated on the
HIPAA Privacy Rule, which protects paper records. The
other, more nebulous half of the guidelines ? governing
protection of electronic patient records ? is the HIPAA
Security Rule, which didn?t go into effect until April of
2005. But by that time, because most covered entities had
been so busy addressing HIPAA Privacy, many were caught
confused or unaware, or simply ignored the new regulations.
Further complicating matters is the technical nature
of HIPAA Security specifications, which require business,
legal and technological expertise.
This combination of factors probably explains why an estimated
80 percent (according to some national estimates) of
covered ambulatory healthcare entities are non-compliant
with HIPAA Security. That doesn?t mean ASCs aren?t trying;
many simply aren?t equipped for HIPAA Security,
which deals exclusively with EPHI, or electronic protected
health information.
Don?t be lulled into a sense of false security because you have
HIPAA Privacy compliance manuals and use software labeled
HIPAA-compliant. There are 42 specifications in the HIPAA
Security Rule, broken down into three categories: administrative
safeguards, physical safeguards and technical safeguards.
Each of the specifications is categorized as either required or
addressable. The term ?addressable? is a bit of a misnomer,
because you are still required to deal with each addressable
specification, but you may be able to satisfy the compliance
requirements of the addressable specifications simply by stating
that it does not apply to your situation ? that is, address
the requirement one way or the other.
Note that the Security Rule is very generic; it doesn?t require
or recommend specific technology solutions. Any software
or hardware vendor who claims its product is endorsed or
recommended by the HIPAA Security Rule lacks integrity.
And there is no single hardware, software or security product
or service that addresses all specifications. Further, software
that is technically HIPAA-compliant can be implemented
and used in a manner that makes it completely
non-compliant.
Also keep in mind that less than one-third of the specifications
are even categorized as technical in nature, as there are
also administrative and physical safeguard categories, which
have nothing to do with software. And just to avoid confusion
and point out a common misconception, even though
the name administrative safeguards may imply some simple procedures and manuals, they are very critical and
should not be overlooked.
Keys to compliance
So how do you tell if you are compliant? The
process is actually fairly involved, in spite of any
?Instant Compliance in a Box/in a Book/on a
Web site/in a Seminar? offers you might see out
there. And it is also much more involved than
simply relying on the HIPAA-compliant statements
of your software provider. In many ways, it
is easier to look for obvious non-compliance and
then deal with those than try to start with the
HIPAA Rule. The following list contains the most
common non-compliance issues we see in ambulatory
healthcare; if even one of these issues is present
in your facility, you have a problem.
1. Workstations running anything other than the
most current operating systems. That means
Windows Vista Business (Service Pack 1)
Windows XP (Service Pack 2) or Windows 2000
(Service Pack 4). (Therefore, Windows 98,
Windows Me, Windows NT Workstation, XP
Home, Vista Home, etc., are all non-compliant.)
2. Lack of a client/server architecture. If you are
using a workgroup, where there is no domain controller
to centrally control user security and permissions,
you are non-compliant. Client/server architecture
can be implemented with as few as five users.
3. ?Weak? or shared logons/passwords (such
as ?staff ? or ?billing? or ?front desk?). This
also includes usernames/passwords posted on
sticky notes on the monitor, keyboard or taped
to the desk. If you are doing this to save on
software-licensing fees, you face a double whammy:
The Business Software Alliance
(BSA ? not the Boys Scouts) can hit you with
a fine of up to $3,000 per instance for this
violation, on top of HIPAA sanctions.
4. No formal employee acceptable use policy (AUP)
covering IT systems.
5. No written security incident reporting policy.
You must have this ? and about 10 other written
policies/practices ? in place to be fully compliant.
6. Lack of good data backup/disaster recovery system(
s), including RAID data storage systems and
rotation procedures. Taking the backup tapes home
isn?t a good idea. The news media is full of stories of
loss/theft in this scenario, and we once worked on a
medical practice where the practice manager was
going through a messy divorce and the soon-to-beex-
spouse stole the practice?s backup tapes.
7. EPHI stored on local workstations and/or
laptops, or on portable media like floppies, thumb
drives or CDs. In fact, you should strongly consider
disabling the ability to use those devices on workstations,
as it makes it theoretically possible for someone
to download all your data to portable media.
8. Any user account that has system administrator
rights. We frequently see this situation because of
some issue where the IT company is unable to make
something work on the network without giving users
admin rights.
9. Use of any ?public? email address or domain name
(such as AOL, MSN, Comcast). If you are using an
email address with Gmail, MSN, Hotmail, Yahoo,
etc., then you are non-compliant. This also governs
any outside partner entities as well; we have seen practices
and surgery centers e-mail dictation files to an
outsider who was using an AOL e-mail address.
10. Not having a hardware firewall. Your Internet
provider probably put a firewall when they installed
your Internet circuit, but that?s to protect them from
you, not to protect you from the outside.
11. Lack of updated, business-class anti-virus, AND
anti-spyware, AND anti-adware software. It?s worth
the cost, and it should be installed on the server and
?pushed? out to all the workstations on the network.
12. Peer-to-peer/file-sharing applications. Allowing
use of applications such as Kazaa, Morpheus,
Limewire, Bit-Torrent and chat apps is like sharing a
soda straw with others at the local bus station.
13. Most ?free-ware.? Do no allow staff to downloaded
screensavers, weather apps, horoscopes,
Internet search bars, etc., and even some anti-virus and
anti-malware software. Only approved software should
be used, and installed only by your IT professional.
14. Internet games such as partypoker.com, wildtangent.
com, empirepoker.com, etc. Don?t allow
your facility?s computers to be used for this purpose,
no exceptions.
15. Unsecured WiFi (wireless), or WiFi with WEP
security. This isn?t a coffee shop; you need to ensure
information is locked down, virtually speaking.
16. Laptops that move in and out of the facility
(especially physicians? personal machines).
These can too easily compromised by other users,
loss or theft.
17. Using ?remote control? software to access your
desktop remotely instead of using a hardware/software
VPN (virtual private network) solution. We
aren?t going to name names here, but there are several
commonly used commercial software products in
the marketplace that could easily allow your systems
to be compromised.
Further resources
What should you do to determine if your facility is
compliant, and what should you do if you find out
(such as using the checklist above) that your facility
may have issues? There are several good background
resources available on the web, including
www.cms.hhs.gov and www.hipaaadvisory.com.
FASA has published a HIPAA Security manual. In
our opinion, HIPAA Security compliance requires
hands-on assessment and possible remediation by a
combination of competent and experienced technical
and business/operational resources. Our first suggestion,
though, is to find out if your IT provider
even knows how to properly spell HIPAA. If they
spell it wrong, that should be a clue that you need to
get a different provider.
Dr. Jenkins (marion.jenkins@qsetech.com) is the
CEO and founder of Englewood, Colo.-based QSE
Technologies, a provider of IT consulting and
implementation services to ASCs, physician clinics and
medical office buildings nationwide.
