Working in healthcare IT (HIT) means learning to quickly

adapt and implement new technologies at breakneck speeds.  Healthcare has so embraced technology that

businesses must continue developing new and better methods of providing patient

care or else lose the competitive edge that is essential to their

survival.  That competitive edge ensures the

best physicians are retained, patients get higher quality care which is safer

and less invasive, and the bottom line is maintained against ever decreasing

insurance reimbursements.

So where does the HIT professional fit in all of this?  He fits right smack in the middle, holding

hundreds of spider-like threads together which stretch from the data center

back to every aspect of healthcare operations. 

Technology is entrenched enough that a down server could mean a doctor performing

a heart procedure can’t pull up needed images, or it could mean a recently

vacated patient room goes uncleaned because the bed and patient tracking system

couldn’t send the notification page to the environmental services

employee.  Heck, I just completed a new hospital

dietary system installation to replace an old paper system.  So now every time the Citrix server crashes

(ahem, last night), I get a call from panicked dietary workers who don’t know

what the patient in room 2217 ordered for dinner.  Two months ago, they used an entirely paper

driven system, and now they are completely immobilized if their new electronic

system hiccups.

To make matters worse, many times vendors ship out buggy

software in an attempt to be first with a new idea.  I know, buggy software is not unlike software

being sold in every other market, but its impact in this case is to patient

care, which takes it to an altogether different level.  Installing a poorly written software package compounds

the problems facing HIT departments because subsequent “patches” and

“enhancements” become less optional and more often translate into required

upgrades.  Features seen on a glossy

brochure and included in a slick sales presentation are nowhere to be seen after

the initial installation or they often work less than perfectly.  Let’s see a show of hands if you’ve ever

installed a dot release upgrade to a system which wasn’t yet live.  My last system installation included four separate

dot upgrades before it ever made it to production status.  Depending on the complexity of the system,

this could mean required updates and testing to database, application,

interface and terminal servers; not to mention updating workstations and

handheld devices or rebuilding automated software deployment packages.

In all fairness, often software vendors and HIT departments

are pitted against each other to solve implementation problems when the root

issue originates with a hospital director or president who purchases a system

without involving the people responsible for its installation.  “We bought this, now make it work” is a

phrase I’ve heard before.  Seemingly out

of nowhere, a contract is signed, money changes hands and then it’s sent to IT for review and installation.  Problems inevitably arise when you’re

speaking with the vendor’s technical support, and they reluctantly inform you

that they’ve never assisted with a thin-client implementation of their product or

don’t know if their software will run on a virtual server.

However, vendors will work with you much of the time to

install their software according to the standards and technologies in your

environment even when their support documentation doesn’t officially list it as

an accepted platform.  But what happens

when they won’t?  Then IT is left holding

CDs for a purchased system which doesn’t adhere to internal processes.  A decision must be made at this point either to

refuse installation (this never happens) or engage in a bit of creative

engineering which involves magic behind a pulled curtain.  Voila! 

A new system is installed and no one quite knows how it’s working.  Just don’t breathe too hard on the server on

the left.

As computerized methods replace the last remaining manual

procedures in healthcare operations, IT departments find themselves playing a

direct role in the delivery of patient care. 

This means promptly responding to problems that arise while juggling the

constantly evolving solutions passed down from vendors and into our laps.  Now if only I could learn to recognize the

beta software builds from the “final” releases