[optimal] Re: HIPAA Security initiative
- From: Lydia Dimmer <lydiadimmer@xxxxxxxxxxx>
- To: <optimal@xxxxxxxxxxxxx>
- Date: Tue, 21 Feb 2012 10:06:31 -0800
Remember - HIPAA only asks for "reasonable" action to protect patients privacy.
Most of the equipment used in ophthalmology doesn't require log ins.
It may be enough to simply make the VF room not freely accessible to
non-staff.... However, if you transmit files with pt info out of your network,
you may have the HiTech act or encryption issues to consider.
Lydia Dimmer, COT, CRA, OCT-C
Eye Associates Northwest, PC
Seattle, WA
206/342-6140
From: RSStratton@xxxxxxxxxxxxx
To: optimal@xxxxxxxxxxxxx
Date: Mon, 20 Feb 2012 15:29:38 -0500
Subject: [optimal] Re: HIPAA Security initiative
Not sure why I did not receive this response, but thank you Ditte for
forwarding it to me: “If the patient is being assessed within the health care
entity, they have provided their HIPAA assent to being tested and we have
provided the patient with information regarding their rights and ensuring that
all data is protected. If the DICOM information exchange system is within the
entity and there is no exporting of patient data outside the entity, then it
all falls under the acquisition of patient protected healthcare information for
treatment purposes within the entity (eg., sending info to in-house EMR). No
problem. If the PHI does go outside the healthcare entity for data analysis,
(e.g., site fundus images or vision fields reading), then a Business Associates
Agreement is required which spells out everyone's responsibilities in the
sharing of the patient data. Everything else you mentioned regarding HIPAA
requirements (log-ins, password access, screen time-outs, etc) still holds. If
it for research and the patient data is not de-identified... then NIH research
privacy and security guidelines also come into play. Anastas” “Everything else
you mentioned regarding HIPAA requirements (log-ins, password access, screen
time-outs, etc) still holds. “ This is where we seem to be stuck. Faced with
the scenario that the Zeiss HVF systems are not capable of any of these
criteria [logins, passwords, timeouts, etc], what are we to do? If HIPAA
demands we are responsible for these requirements, is our only recourse to
remove these machines from the clinic[s]? I realize that’s a rather drastic
approach and that is why I’ve posed the question, “Has anyone else thought of
what to do with their non-HIPAA compliant systems?” [HVF’s in particular]
Richard Stratton Systems Analyst / University of Miami Clinical Enterprise
Technologies (UMCET) Audio Visual Manager / Bascom Palmer Eye Institute 900 NW
17th Street Miami, FL 33136 Phone (305) 326-6103 or Phone (305) 482-4002 Phone
(786) 376-3228 (cell) EMail rstratton@xxxxxxxxxxxxx Web
http://www.bascompalmer.org The information contained in this transmission may
contain privileged and confidential information, including patient information
protected by federal and state privacy laws. It is intended only for the use of
the person(s) named above. If you are not the intended recipient, you are
hereby notified that any review, dissemination, distribution, or duplication of
this communication is strictly prohibited. If you are not the intended
recipient, please contact the sender by reply email and destroy all copies of
the original message. From: optimal-bounce@xxxxxxxxxxxxx
[mailto:optimal-bounce@xxxxxxxxxxxxx] On Behalf Of Stratton, Rick
Sent: Monday, February 20, 2012 10:08 AM
To: 'optimal@xxxxxxxxxxxxx'
Subject: [optimal] Re: HIPAA Security initiative Thank you everyone for the
input.Jim, Thanks as well for clarifying the message for me. It’s important to
distinguish DICOM from HIPAA, this is exactly the issue at hand. Two years ago
we updated our Zeiss HVF machines from non-networkable units [750’s] to the
newer networkable units [750i’s]. And although we do not have the
infrastructure in place to make use of either DICOM storage or even the DICOM
Worklists for these machines [long story] we do have them on the network and
synchronizing data among themselves. [no small feat that!] If I can quote you:
“If it were my project, i'd ask my HIPAA expert to come to clinic and look at
the instrument with me so they understand how it is used and then generate a
specific list of concerns and pose that to the vendor. That said, i think this
is a GREAT thread and am also VERY curious if someone out there has gone thru
the process from the perspective of a large institutional hospital, because
it's going to be very interesting. Unfortunately i don't know that there will
be one absolute answer; i think the way HIPAA has been constructed, it leaves
much open to the interpretation.” We did and we are! We [Univ of Miami] have
undertaken a comprehensive HIPAA Security initiative and inclusive of this has
been all Ophthalmology Imaging systems. This list includes 20 systems for
Ophthalmology alone [I think the number was 100+ for the entire Med School] and
that list is still growing. They include any and all systems used in the
Cornea, Retina, Glaucoma, Neuro, Peds and Plastics subspecialties. The
qualifier for the list is any system that uses and stores PHI – Names, MRN#’s
and/or DOB. As you can see, that ends up including just about every system you
can think of in Ophthalmology. The criteria that HIPAA defines as necessary
include:Does this system provide for any Audit trail logging and review
capabilities?Does this system provide for Individual User logins? [software not
machine]Does this system provide for any software inactivity timeouts? [based
on individual software logins]Does this system provide for User Account
lockouts? [x number of bad login attempts locks them out]Does this system
provide any User Account password expiration capability? What we quickly
learned is that although there are a small handful of vendors who made efforts
to comply, the majority of vendors have done very little in this regard. Under
the circumstances that leaves us [anyone who uses these machines] in a bit of a
precarious position – we are still ultimately the ones responsible for making
these systems ‘secure’. By far the single most common issue with these systems
is audit trails. Even among the small handful of systems that make use of
individual user accounts for application accessability, very few of them offer
the ability of producing an audit trail. As a general work around, we’ve taken
the approach of instituting individual OS logins to cover this area – the logic
being if we can tell who was logged into the actual machine [Windows logs] we
can tell who is responsible for the application it’s running at any given time.
Yes, this does have its own set of issues but it’s better than nothing.
However, when we begin to apply these questions to Zeiss HVF machines we begin
to run into all sorts of issues:The system is not Windows based, therefore
there are no options for audit trails. This also means there are no login
capabilities as [and please correct me if I’m wrong] these systems offer no
option for user accounts. In short, to plug it in, fire it up and you’re in.
This is where we’re stuck – how can we make a system such as this secure? What
I was hoping to find out is if anyone else has undertaken this issue? We [UM]
happen to have quite a number of these in our inventory [18 units system wide I
believe] and quite a repository of data on them [at least 10+ years worth,
maybe more]. This fact alone makes retiring them for an alternate system a very
complex issue. We are trying to gather a consensus from other institutions on
what they are doing in situations like this. Has anyone else looked at this and
drawn the same conclusion as we have? Has anyone replaced their Zeiss HVF
systems because of this HIPAA shortcoming? Does anyone plan to replace theirs
because of it? Or perhaps has anyone come up with an alternative solution we
haven’t thought of to make them modestly secure? I will add that efforts in
this regard [HVF] have included efforts to ‘tighten up’ the way it transmits
data. We found early on that the systems are incompatible with our LAN [which
is gigabit] and had to make use of the HVF’s built in FTP protocol for moving
around data. Because it’s not SFTP, that in itself is a bit of an issue.
Richard Stratton Systems Analyst / University of Miami Clinical Enterprise
Technologies (UMCET) Audio Visual Manager / Bascom Palmer Eye Institute 900 NW
17th Street Miami, FL 33136 Phone (305) 326-6103 or Phone (305) 482-4002 Phone
(786) 376-3228 (cell) EMail rstratton@xxxxxxxxxxxxx Web
http://www.bascompalmer.org The information contained in this transmission may
contain privileged and confidential information, including patient information
protected by federal and state privacy laws. It is intended only for the use of
the person(s) named above. If you are not the intended recipient, you are
hereby notified that any review, dissemination, distribution, or duplication of
this communication is strictly prohibited. If you are not the intended
recipient, please contact the sender by reply email and destroy all copies of
the original message. From: optimal-bounce@xxxxxxxxxxxxx
[mailto:optimal-bounce@xxxxxxxxxxxxx] On Behalf Of Hess, Ditte
Sent: Monday, February 20, 2012 9:21 AM
To: 'optimal@xxxxxxxxxxxxx'
Subject: [optimal] Re: HIPAA Security initiative Hi Jim, Thanks for your
response – Rick just joined Optimal and he is looking forward to sharing
information on this subject!! Ditte Ditte J. Hess, CRADir. of Photographic
Educational &Research Training ProgramsBascom Palmer Eye Institute900 NW 17th
StreetMiami, FL 33136Phone (305) 326-6000 x6280EMail dhess@xxxxxxxxxxxxxxxx
http://www.bascompalmer.orgThe information contained in this transmission may
contain privileged and confidential information. It is intended only for the
use of the person(s) named above. If you are not the intended recipient, you
are hereby notified that any review, dissemination, distribution or duplication
of this communication is strictly prohibited. If you are not the intended
recipient, please contact the sender by reply email and destroy all copies of
the original message. P please consider the environment - do you really need to
print this email? From: optimal-bounce@xxxxxxxxxxxxx
[mailto:optimal-bounce@xxxxxxxxxxxxx] On Behalf Of James Strong
Sent: Friday, February 17, 2012 9:15 AM
To: optimal@xxxxxxxxxxxxx
Subject: [optimal] Re: HIPAA Security initiative One thing to keep in mind here
is that DICOM and HIPAA are two completely different animals and don't have
much to do with one another. An instrument being DICOM compliant doesn't mean
it will be HIPAA-fied. DICOM is a "standardised" data structure that means an
instrument that is DICOM compliant "should" be able to exchange data with other
DICOM compliant systems. Be aware that DICOM isn't a silver bullet for
data/system integration; there are varying "flavors" or dialects of DICOM. If
the 2 pieces don't speak the same dialect then things get much more
complicated. HIPAA deals with keeping Protected Health Information safe and
has multiple facets. Some of which are as simple as Password protecting
systems that contain PHI, individual log-ins to such systems, and audit trails
for data access i.e. who is looking at what data. While DICOM-izing an
instrument may ultimately push your data into a HIPAA compliant system, it
doesn't make the instrument itself or the data it can access HIPAA compliant.
If it were my project, i'd ask my HIPAA expert to come to clinic and look at
the instrument with me so they understand how it is used and then generate a
specific list of concerns and pose that to the vendor.
That said, i think this is a GREAT thread and am also VERY curious if someone
out there has gone thru the process from the perspective of a large
institutional hospital, because it's going to be very interesting.
Unfortunately i don't know that there will be one absolute answer; i think the
way HIPAA has been constructed, it leaves much open to the interpretation. j-
Other related posts:
