Vendor IT Staff Perspective on Healthcare IT Difficulties
case presents the perspective of a technical IT support person working for a
vendor. He is young, yet has excellent observational and reasoning skills
exceeding those of many "senior" people I have encountered.
This story of HIT difficulty issues came unsolicited. It is worth reading in its entirety:
Hi Dr. Silverstein, I just
finished reading your website on informatics, thought it covered a lot of the issues in clinical
IT well, very well, one thing though that I thought was missing was the perspective
of the vendor IT staff and how these issues trickle upstream (or is it
downstream) to clinical IT.
I ran into your article while on the http://www.govhealthit.com/ website and saw your webcast 'The Problem with EMRs' and ran into your website.
A brief background about myself first though to give some context of where I am coming from. I graduated from college not too long ago, 2005 to be exact so I am relatively young especially in the healthcare world. I have been working in healthcare IT for almost 3 years now and started with no knowledge of healthcare, my background was/is technical.
I have worked with several hospitals and groups of hospitals to create interfaces to practices (over 50 interfaces and over 15 different EMR/HIS/LIS systems), and in some cases other labs to share HL7 formatted clinical data. I have also been dabbling in (E)MPI's also and working on the design of a light-weight EMR application.
Although I do have limited healthcare experience I have somehow managed to become responsible for the design of these applications or have my hands somehow involved in these projects. Our staff, developers at the least have worked in the healthcare IT space for about 10-15+ years each.
I myself though am the odd one out with just under 3 years, so I spend most of my time learning from them, other industries and other developers to get a grasp of how to develop/design applications.
I for one feel the biggest problem with clinical IT, is as you stated, there's a "magical bullet" that can solve everyone’s problem and IT is that bullet. This magic bullet idea seems to live on both sides, hospitals as well as vendors seem to think that IT will fix it all. The reality that both of us seem to see though is, it won't solve everything, it will solve some things but I think more importantly is that it can only help clinicians.
IT cannot solve all of clinician's problems because as you stated, healthcare is a complex, dynamic beast to tackle, rather than solving problems, I feel it would be best to use IT to make processes more efficient where applicable. Before I go too far though, I need to define people as I see them:
· Clinical people - Folks that understand the healthcare process down into the nitty gritty details, understand the complexity and dynamics of working in healthcare.
· Clinical IT people - These are folks like yourself, understand the clinical process and the IT side of things.
· IT people - These are folks like myself, we understand IT, development and the limitations of computers but don't quite understand all the details we can see the big picture but don't quite understand all the details and how they work in healthcare.
Internally at our company, much the same as with the C level people in hospitals, is that IT will fix [insert problem here]. The reality is though, it won't, if its not thoroughly examined and researched it won't solve the problem, or even worse the problem can't be solved by IT, similar to your ED whiteboard example.
We are currently developing an application where the client is driving the design, while management is trying to keep the application generic enough that we can implement this at other sites. The problem is, we have no expertise in that area, our developers, designers, implementers know and understand interfacing, not development in these other areas.
Management in their infinite wisdom though think we can do this as long as the hospital is giving input, though there's no clinicians involved in the design, just the IT managers of the hospital.
This seems to have become the bane of my employment though, management sees a revenue stream and then sends it down stream to the guys in the trenches to make it happen, the reality though is, we can make SOME of it happen, but not the entire solution, this seems to fall on deaf ears though.
Sales and management are those in a position of power to drive what the front-line soldiers do without understanding the problem. For example we, developers and implementations have been tasked with developing a light-weight MPI [master patient index - ed.], which has been a success though since this falls into some our staffs expertise.
But, the project was doomed to fail since day one because the expectations were to meet a 100% patient match without [additional -ed.] data entry. This was similar to solving CPOE, the last numbers I read were CPOE covers about 20% of total results/orders that exist today.
The expectations and smoke screen put by sales, marketing, vendors etc. seem to have grabbed everyone’s imagination, I think what should be put out there is reality, unfortunately reality doesn't sell as well, which is a shame.
I've seen/heard of projects that range in the tens of thousands to multi-million fail because the expertise isn't there, management sees a glorious one-size-fits all application and bites the bullet only to see their 25 million dollar budget for the year go down the drain in one project and now dozens of other projects are in peril or go on indefinite hold because of the lack of budget.
My cousin works at a small hospital in admissions, they recently installed [major vendor's] application for patient registration. I was speaking with him about this and believe its a multi-million dollar failed project, [major vendor] doesn't internally have the staff to develop such an application, they didn't bring in clinicians, they didn't ask about their work-flow and designed an application that makes no logical (to a clinician or hospital employee) sense.
Options are scattered, the application expects a patient to be registered before being admitted, the problem is what happens in ED situations where the person goes in with no identification and is near-death, not quite easy to ask a person about to die their information.
That's the reality of hospitals, anything goes, [vendors should - ed.] develop the application to work in that manner. I also see another arena where IT has failed healthcare, the notion, the idea of EMR's is grand and could be a good one I believe.
The current standard for transmitting clinical data, HL7 is a partially failed standard as its not a hard-typed standard. I may be showing my ignorance here since I haven't worked with X12 yet only HL7 which seems to be fairly prominent. HL7 in itself already has many jokes about being a standard, funny, but true. HL7 is merely a suggestion on how to format data. In the dozen or so EMR's I have worked with I have yet to see any two EMR's do anything exactly the same, or as stated in HL7.
One thing I cannot seem to emphasize enough is to read the specs of the EMR and translate the data that way. In the interest of my wallet, it's great because it keeps me in the job. But, this seems like a waste of time and talent that's out there which is lacking. A single hard-typed format needs to exist before EMR's and EMR applications can give the push to healthcare everyone wants.
It seems to me the first step would be agreeing on the content of the message not the formatting. From an (E)MPI perspective patient demographics, depending on where you go and who you talk to only some things should be required which is ridiculous when trying to match a dozen John Smiths together.
From and IT perspective, parsing messages is fairly simple as long as the formatting is consistent and data elements are in the same place. Parsing is trivial relatively, its the content of the data that seems to get EMR's, EMPI's [electronic master patient indices - ed.] and other applications confused.
Most of my work isn't parsing data, or even the patient, order/result matching, its the data analysis and normalization of the data.This boom in clinical IT is great, but, the intentions of companies jumping into healthcare overshadow the purpose of the applications. Companies are rapidly developing and deploying applications without ever asking a clinician if it works.
[Major new application] is a $25m dollar application, has many bells and whistles but lacks a fundamental core, how do you get data into it? It seems to be able to manage data well, can do many things, but at the end of the day if you can't get data into it its an expensive application that collects dust.
The revenue bug seems to have bitten many capable IT companies, unfortunately though they seem to have forgotten the fundamentals of simply asking, 'What exactly is it you need?' Vendors aren't entirely to blame of course, hospitals seem to want solutions but refuse, or can't put resources into creating a solution.
It's a pretty vicious circle of failed IT projects, lack of expertise that I think will keep going on until peoples perspectives of clinical IT are changed. If a viable solution is going to be created, the resources have to be put into it, the question I suppose is who is going to do it?
On a current project, we have several staff members of the client designing the application, internally we have several people designing the application, but, neither client nor designers understand each other. This project has gone on for about 2-3 months now, I started on it initially got pulled off and am now back on it again.
It’s almost 3 months later and they're still discussing the items from day 1, there has been no progress in 3 months because neither side wants to put the resources into designing the appropriate application. The limitations on the technical side clash with the needs of the client, the capabilities of technology don't quite meet the clients needs, but no middle ground has been met, no answers and the same questions over and over.
Maybe one day some day, a group of folks will get together from all sides and sit down to nail things out, unfortunately in my few short years, I've seen egos and politics clash too often to think it'll happen any time soon.
Also, one more scenario I ran into. A friend of mine is a doctor practicing internal medicine so I would occasionally ask him about the applications he uses.
So one day I asked him to walk me through the process of him accessing patient records. Watching him access the systems is a nightmare though, he has to log in through 3 different systems before he can access the server hosting the records. For technical folks its not too big of a deal we're used to it right?
For a clinician though it's a thorn in their side, but this is the reality of things, IT concerns vs. usability. Well, after he had logged into the system he was overall happy with the application as it was setup, simple, easy to navigate no bells or whistles, basically the same thing he would do if it were on paper.
But, there were some annoyances, he couldn't skip around from page to page, he could go forward but not backward, to go backward he'd have to close the report and reopen it. The reports weren't text, they were scans of written documents so if he needed to highlight something he couldn't, if he needed to make a note he couldn't, short of digitizing the entire system its a daunting task.
Maybe the advent of netbooks, tablet PC's working their way into hospital environments will help to solve this some day. At the risk of creating a laundry list of fixes, I'll get more to the point, I for one couldn't understand why the system was set up this way, or the application was until I started to think about it more.
From a vendor, implementation and IT staff perspective my conclusions were resource issues. As a vendor it’s always good to keep your application up to date, fix bugs and such, but, at the same time it cuts into your margins and becomes another project to update the application, test, install, test again and make sure everything works. Besides, they already bought it, they're stuck with it now why fix it if they're still paying us anyway?
That was my only reasoning from a vendor standpoint to not fix small trivial user interface problems. From an implementations standpoint, its a cost/resource issue, doctors use the application now, they may gripe about it but they'll live with it, its not stopping them from doing their work now anyway. There's always other projects to work on rather than fix fundamental/core issues.
Implementation all too often lives on the bottom-line, whether they are forced to or not. At the end of day their job is secure depending on how productive they are, not how sound the core is, that's management and development's job right? Ours (I say our, because I am currently most active in implementations) is just to get it up running, working and be done with it, move onto the next job. Development and support can take care of the aftermath.
From an IT staff standpoint, it's similar to implementations only with less understanding of the "why." For the most part, it seems IT staff know that it needs to go in, understand the technical aspects of making something work but don't quite understand why it works and why its there, they just know it has to be there. IT always has more than enough projects to work on than resources are available so one less upgrade is one less thing to worry about.
There's a common theme among all three roles though, why worry about the fundamentals and the core when it’s already 'good enough'. I think this is a mentality that needs to take a back seat, in my humble opinion anyway, the mentality should be, 'Does this work? can it be better?' Of course this has to be aligned with ROI (return on investments).
It seems to me anyway, that there has been so much focus on creating teams, departments and specializing people in specific areas that there are too few people to help bridge the gap. This is where I am hoping I can play a role some day anyway. To me, there's a lack of bridges between departments, fields of expertise and the client, making sense of everything isn't an easy task by any means, but it is a necessary one if an application/solution is to succeed and it seems to me its the first role to be dismissed.