27
Oct
10

hammering with a screwdriver

Do you think your Lab software is the tool you need?

Over the past years, I got the chance of get in contact with many Laboratory Information Systems (LIS) available in the market.

And when I look back, and try to analyse them from a safe distance I get the feeling that they all have more similarities than differences.

They all share some common goals:

  • spread as far as posible!!!
  • adapt as fast as you can!!!

damn, look like a virus to me!!!

They all try to reach to different types of Labs, try to do different tasks, try to manage different business environments, try to adapt by all means to the circumstances, etc. And to do this they all seem to loose their vertebra.

Sometimes, it is wise to stop and accept that your software is not tailored to manage all the information concerning your lab.

Let me give you an example, a good clinical management software does not have to be a good stock management software.

Maybe your software is great for communications with lab analysers, but maybe it sucks for data mining.

And sooner or later,  the Lab Manager will ask himself why is he carrying this huge, complicated, heavy, not flexible tool, when most of the time he only need a small tool, and only ocasionally he will need ‘the big stuff’.

Surelly he will wonder, “wouldn’t it be nice to modularize my software, use as I need, and hope my ‘modules’ communicate each other nicely?”

22
Oct
10

blue pill or red pill

Occasionally, every blogger gets into a situation of wondering if he/she should continue to post.

I’ve been in that (in)decisive situation over the past year. Between two house moves, managing family priorities among everything else, this blog has been stalled.

I’ve decided to try to give the blog a new chance.

Hope this is a good decision.

20
Apr
10

while I was out

Now that I’m back in the business, I’m trying to keep up to everything that I missed in this last year.

There was a generous reference to my blog, from DarkDaily that I’d like to share with everybody:

Geek in the Lab
Pedro Fonseca has been an IT healthcare specialist for more than 15 years. It is clear while poking through Geek in the Lab that Fonseca is passionate about information technology as it relates to healthcare. “Geek in the Lab” is laid out so that IT professionals can keep up with the latest in healthcare technology, but it is written in a way that is accessible to the laymen. While many similar blogs are full of difficult to understand technical jargon, Fonseca makes sure his blog is easy for all readers to understand. Far from a “How To” advice column, “Geek in the Lab” keeps track of healthcare IT trends and offers observations on how they may impact the big picture. Fonseca’s “Gadget of the Week” gives readers a glimpse of the latest in IT tech.”

Thanks to Robert L. Michel and his team for such kind words and keep the good work.

19
Apr
10

awakening

Year 2009 was a troubled year.

It was necessary to rethink my life priorities.

This blog was placed behind some other issues.

So, as part of my new year’s resolution for 2010, The Geek is back to the Lab!!!

Have lots of subjects to write about, so I’ll start this week ;-)

01
Apr
09

why login/password should be banned in health-related applications – II

fs567012In my last post I’ve stated that the login/password is not secure.

Maybe the problem resides not in the ‘technology’ but as many times on the human factor.

In fact, the main problem is not the login/password procedure, but the way you use it.

So,  in order to study my customers passwords, I tried to create several simple rules to determine if the password used by them are easily crackable or not.

I have done this study using data from an hospital, and having a 400 user accounts.

Let me remind that although our software has several rules implemented for password management, we were asked to turn them down. This rules include:

- time validity

- minimum chars used

- time period for using the same password

- among others.

So, the rules I’ve come up with, are 10 very simple and common sense rules:

Rule 1: Verify if the users ever changed the password (12% didn’t, meaning that they still use the original random password assigned to them)

Rule 2: Verify that password is the same than login (4% use password=login)

Rule 3: Verify if the password is the Institution name (1%)

Rule 4: Verify that the password is the Application name (4%)

Rule 5: Verify if the password is the official employee number (14% use their official number, that is published in every institution document)

Rule 6: Verify if the password is between 1900 and 2009 (25% a year like password)

Rule 7: Verify that password is a 4 digit number, not like Rule 5 (5%)

Rule 8: Verify that password is the user first name (2%)

Rule 9: Verify that password is the user last name (1% use last name, although I haven’t tried maid name)

Rule 10: Verify if the password is a portuguese name (3% use Portuguese names, which I suppose to be children names, or wife/husband names)

This simple 10 rules, allowed me to crack 71% of a 400 user accounts password, meaning 284 user accounts.

I suppose that if I apply this rules to the same users on different applications, I would have got similar results, because the crackable passwords were personal data.

“Do you really think your health data is safe?”

Let´s ban login/password NOW!

31
Mar
09

why login/password should be banned in health-related applications

fs567012I’ve been working in hospital labs for several years, and have followed the IT evolution in this sector. In the beginning, the lab was an isle, and the information was secure for the physical barriers. The network was restricted to the laboratory, and the access to the software wasn’t password protected.

Then, the hospitals began to connect the several ‘islands’, and implementing a centralized infrastructure.

It was the beginning of domains, and the first contact of the user with logins and passwords.

Then, rapiddly there was a proliferation of software, and each one had different logins and passwords. There was administrative software, clinical, image, lab, infection control, then appeared the intranets and portals, and when the user noticed he had more logins and passwords than he could possibly manage and memorize.

One of the first reaction from users was to unify passwords. But then, some of them had time limit, and others did not, and it was an Herculean task to manage all this info.

Some hospitals tried to implement Single Sign On, others tried to ease access through digital id cards. But the most common access control still is Login/Password.

And why should login/password be banned?

Because it is not secure!

To prove this I have made some tests attempting to figure out what the user password was in several databases installed in different hospitals.

The results leave no doubt that this method is not secure. More than 70% of the passwords were broken in the first 10 rules.

On the next post, I’ll describe the tests I made and the results I got.

24
Mar
09

gadget of the week

68963-0-0-2Health information is a very sensible type of data, and should be secured.

Nevertheless, the most common procedure to protect data is using the login/password procedure. This is the worst way to protect Health Information.

In fact, it’s so bad, that should be forbidden. Would you use it to lock your car or your house? I’m sure you wouldn’t.

So, in order to protect access to Health Information throughout the entire lifecycle, we should use a different approach. One of the cheapest and reliable is the fingertip reader.

I’ve been testing different fingertip readers, and undoubtly the best I’ve tried so far is the Digital Persona.

For start, it has several important compliances: HIPAA and EU directives

Then, it integrates with Active Directory on GPO and provides an SDK.

Digital Persona also provides an add-on module of Privacy manager, that enables digital signing and encryption of instant messaging, Microsoft Outlook email, and Microsoft Office documents.

It also has a really high performance in reading. It’s quick and almost reading failure proof (failed 3 readings in a set of 1000).

front7w-0116

Finally, the hardware itself. It’s very small, elegant and resistant (yes, I’ve done the Drop 2 meters high test, and the Give it to your 2 year old daughter test) and it survived.




Follow

Get every new post delivered to your Inbox.