[optimal] Re: HIPAA Security initiative

  • From: "Stratton, Rick" <RSStratton@xxxxxxxxxxxxx>
  • To: "'optimal@xxxxxxxxxxxxx'" <optimal@xxxxxxxxxxxxx>
  • Date: Mon, 20 Feb 2012 10:07:34 -0500

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<mailto:rstratton@xxxxxxxxxxxxx>
Web http://www.bascompalmer.org<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, CRA
Dir. of Photographic Educational &
Research Training Programs
Bascom Palmer Eye Institute
900 NW 17th Street
Miami, FL 33136
Phone (305) 326-6000 x6280
EMail dhess@xxxxxxxxxxxxx<mailto:dhess@xxxxxxxxxxxxx>
Web http://www.bascompalmer.org<http://www.bascompalmer.org/>
The 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: