Healthcare IT Doesn't Reduce Costs

A study in the Harvard Medical Journal shows that healthcare IT doesn't reduce costs, and perhaps provides a very marginal increase in quality of care. The authors speculate that one of the reasons may be that the cost of obtaining and running the system outweighs the benefit. No kidding. That fits what I've seen completely.

It's a short article, and worth reading. Thanks to Andrew for pointing me to it.

Securing Healthcare Data with MySQL

As a follow-up to an earlier post, I should mention that part of the reason I had healthcare data on my personal laptop was to do some data analysis with MySQL. Between MySQL and the command line tools, it was very easy for me to load data from other sources and run queries to monitor or predict the amount of medication we were packaging.

When I was done doing the data analysis, I wanted to scrub the data off my hard drive. On the version of MySQL that was installed via Synaptic on Ubuntu 8.10, the default database engine was MyISAM. When a table is dropped, it deletes the MyISAM file. No need to worry about deleted records retaining data in a "tablespace" file that one might have to worry about in other RDBMSs.

Then all I had to do was scrub the hard drive as I described in my earlier post.

Securing Healthcare Data with Ubuntu Desktop

People's personal health care data has to be kept confidential. The reality of working in health care IT is that you have to put work on a USB stick or use a laptop. At least Ubuntu makes it easier to do the right thing.

I knew I had to do something about the data on my laptop (Ubuntu 8.10), so I sat down one day to figure out what to do. I knew the tools were there, but where to start? Almost absent-mindedly I right clicked on the folder I needed to encrypt, and saw that there's an "Encrypt..." command right there on the menu. (Note that you have to be pointing at the file or folder in the right pane of the Nautilus file manager.)

"That was easy," I said to myself. I selected the "Encrypt..." command. Since this was the first time, it took me through a number of steps to generate some keys. I just followed the dialogues. On my Lenovo x300 it took several minutes to generate the keys after I got through the dialogues. I was starting to worry if something was wrong, but patience prevailed.

Once the key is generated, I could go back to encrypting my folder. I selected the option to "Encrypt all files together in a package." After it was done, which wasn't long at all, I was left with the original folder, the folder.zip file, and a folder.zip.pgp file. The ".pgp" file is the encrypted one, so I deleted the original folder and the folder.zip file.

Then I had to make sure that the files can't be reconstructed by someone with the right tools and access to my laptop. I opened a terminal window and did this:

dd if=/dev/zero of=junk
rm junk

The first command takes quite a while. It writes zeros to all the free space on my disk. The more free space, the longer it takes. When it fills the disk, it stops. The second command deletes the file, so I have all my free space back. (If you don't know why I did this, read the last paragraph of this article.)

I've heard that there are ways to get data back from disks even if they've been completely re-written. Leave a comment if you know more about the practicality of restoring zeroed hard drives. The above approach certainly foils a relatively determined attempt to get the data back, and should put you in good stead with your privacy people.

Note that this process still isn't one I'd want to do every time I had to access some personal health care data on my laptop. It's a manual process, meaning I might forget to do it or won't have time to do it that one time just before I leave my laptop in the rental car at the airport. It also takes time, especially if you have a lot of free space on your disk.

If you don't know why you have to write zeros on all your free space, here's why: When you delete a file on your computer, you don't actually erase the data. You just mark it as available for re-use. Someone with the right knowledge (and there are many who have this knowledge) can reconstruct old data on your disk. If you write zeros over the free space, you ensure that there's no data for them to reconstruct.

Unit Dose Roll-Out Part III

Another key element to our success: Bring candy to nurses. Not only do you make nurses happy because they get candy, but you're also showing that you understand their culture and are at least a little bit willing to move yourself closer to it.

Just make sure you don't buy only "granny candy". As project managers and senior nurse educators, we tend to be closer to the end of our career than to the beginning. Don't forget that a significant number of nurses nowadays carry iPhones and have a huge number of friends on Facebook.

Unit Dose Roll-Out Part II

The machines we're using to package the medications are the FastPak EXP from Automed (AmerisourceBergen). They have an awesome pre-installation support team. The front-end sales people were so-so -- your mileage will vary, of course, depending on the region. The sales team was Western Canada; the pre-installation support is for all of Canada.

The machines themselves have a number of quirks. Nothing that can't be worked around, but don't believe that you won't have to make any decisions yourself. Also, since we're running three machines, we've written our own little database scripts to keep the data in the machines synchronized. There's no way you should try to do it by hand, although I suspect that's what most people do because the vendor doesn't have anything to help.

The main competition to Automed are the Pacmed machines from McKesson. There are some differences between the two that will require a change to your extract or interface from whatever Pharmacy Information System you're using. Nothing big, but in software even a small thing can cost a lot of money. It's worth looking into the interface in detail if you're looking at switching from Pacmed or running both in parallel.

Because we're packaging all regularly scheduled oral solids (with some exceptions) we've found that our Pharmacy Information System wasn't really set up to handle some of the scenarios. Our distribution model seems to be different from the typical hospital pharmacy, but I don't have enough experience with hospital pharmacies to say if these challenges would generalize to other installations.

Successful Unit Dose Roll-Out Part I

We've begun to roll out a just-in-time unit dose medication distribution system at GF Strong, UBC and Vancouver General Hospitals. Just-in-time unit dose medication distribution increases patient safety by making it easier for nurses to do what they always do: provide quality care, including medications.

Nurses are loving the new approach. "You just saved me ten minutes", "I really like it", and a big two thumbs up are some of the comments I've heard as I provide go-live support on a pair of medical nursing units.

I'd say there are two major reasons why it's going so well: First, the system is intrinsically good for nurses. Nurses are over-worked, under-paid, and totally committed to their patients. Anything that improves patient safety while making their job easier is going to be a hit.

The second reason is the excellent communication and training by our team of nurse educators. We have to train about 3,000 nurses. We started four weeks before the first units went live, and will continue up to the last go-live week in December. With four nurse educators giving a half-hour session, we're reaching 100 percent of the nurses on most nursing units, and well over 80 percent on the rest.

On any future front-line health care projects I may do, I'm going to insist on the budget to adequately listen to and train the front-line health care providers. This has been so key.

I've been the project manager on this project for just over a year. It's been a complicated, multi-faceted project with a lot of challenges. It's totally satisfying to see a successful start to the roll-out. We're phasing in nursing units for the next three months, so I'm sure there'll be some challenges along the way, but it's clear that we've got a winner.

Stay tuned for future posts about why this project is so successful, and what the challenges have been.

Is This the Beginning of the End for Microsoft...

...or... The end of the... or whatever.

Here you can read about Microsoft explaining their Health Vault product (sorry, I think you might need to register). "We're coining a new term, the Unified Intelligence system." I think experience in IT shows that if you have to "coin a new term" you're selling something that no one wants. Is Tim Bray right, that the options to Microsoft are here "right now" and we could be seeing the start of a big change?

Challenge # 42 of Healthcare IT

Many who've worked in healthcare IT believe it's more difficult than IT in other contexts. Everyone has their reasons. I'd like to add mine here.

Mistakes in healthcare are really bad. They literally lead to people's health being compromised, or in the worst case, people dying. Projects are about doing something new. Doing something new is about making mistakes and learning from them, or at least trying out new ideas, some of which will turn out to be wrong.

Sometimes these two things are in direct contradiction. More often it leads to all sorts of misunderstandings between the healthcare team and the external project team that are hard for either side to recognize, let alone overcome.

For example, it's pretty standard practice on a project to do a design and put it in front of a group of people for review. While it can be hard to listen to others criticize your design after all the work you've done on it, we all get used to it.

Now imagine you're a nurse, doctor or pharmacist. All your life you've been terrified of making a mistake because someone might die because of it. Everyone around you is also terrified of making a mistake, and in fact the best way for them to feel good is to catch you making a mistake. It's pretty easy to fall into a pattern of avoiding mistakes at all costs, avoiding blame for mistakes when they do occur, and catching others' mistakes in order to appear to be a better nurse, doctor or pharmacist than the others.

You're not likely even to be able to understand a consultant who suggest you put up a proposed design and let others criticize it. And if you understand, you're not likely to want to go along with it. Every fibre in your being is about avoiding mistakes. And everyone you work with considers making a mistake to be the worst thing anyone can do. No consultant is going to convince you that you should publicly set yourself up to "make a mistake".

If you're running a project in a healthcare environment, you need to understand the depth of fear of making mistakes. To move the project forward in spite of this fear, try some of these ideas:

• Let the people you're working with tell you what makes them comfortable. They won't necessarily tell you just because you ask them. You have to listen to how they want to do the project
• Bring groups together and facilitate group decision making, rather than expecting one person to tell you an answer. It will take longer than if you could find one person to make the decision, but the reality is, you aren't going to find that one person
• Use project staff if you can. Just let them know they're going to take a beating. The passion with which many people expose other people's mistakes in healthcare is unnerving
  

By the way, I'm really glad that healthcare providers have a phobia about mistakes. If I'm ever in the hospital I want to know that everyone there is doing everything they can to avoid mistakes. It's only difficult when you're trying to run a project.

Task vs. Service

At my current client, a large health care organization, I needed to dispose of some old equipment that had personal health information about patients on it. I got directed to a front-line employee who operates a machine to degauss disk drives.

Knowing the organization, I knew that wasn't all I needed to do. And fortunately I knew how to track down the financial, inventory and other people who would be interested in reselling the machine if possible, and then getting rid of it all the way to the dump and removing it from the financial books. In total, I'll have to manage the disposal myself through three or four departments, and at least that many individuals.

What I really wanted was a single phone number I could call and say, "In April, get rid of this thing for me." and be done with it.

I think that's why we hear so much about "aligning IT with the business" these days. It's not just the big picture, find-a-way-to-put-your-business-on-the-web-and-make-yourself-rich alignment. It's also because we confuse an IT task with a business service. To the business there's value in an internal 1-800-got-junk number for information assets. There's very marginal value having someone in a room who can degauss disk drives (and who only gets called if someone is technologically savvy enough to know to call them anyway).

How can you tell if something is an IT task or a business service? Start by really getting into the head of the person who would use your service. Like ask them. If you can't sell the service, or at least get someone excited in about five minutes, then you better re-think your service.

By the way, my remarks about tasks shouldn't be taken as disparaging the people who do the real work. The internal 1-800-got-junk model needs someone to run the degausser, and their work is critical to making the whole model work. IT is sufficiently complicated that in medium to large organizations almost any business service will require multiple tasks carried out by multiple individuals. The shift to service thinking has to happen at the management level. The people doing the tasks are usually doing the right thing.

Google and Healthcare IT

Google is showing interest in becoming the provider of people's electronic health record. It's an interesting idea, but the ramifications of the U.S. Patriot Act are probably unacceptable to the vast majority of people who think about the privacy of their health record.

Basically, the Patriot Act gives the U.S. Government the right to look at any data in any computer in the United States, and they don't have to tell anyone they're looking at it. In fact, it's a crime to tell anyone their data was looked at. This basically violates any privacy legislation in any country that has such a thing. You need to give permission to anyone to look at your data, and you need to be informed if someone looks at your data for any reason.

In healthcare IT here in Canada we now live with the fact that healthcare data about Canadians can't be stored in or even pass through the United States. At least we can build an electronic health record. We just have to keep the data in Canada. Thanks to the Patriot Act, Americans may miss out on a great chance to improve their health.

(There might be an opportunity for enterprising Canadians to host the U.S. electronic health record, but if I recall correctly HIPAA says you can't store U.S. healthcare data outside the U.S.)