Giving a patient medications in the ER, having them pop positive on a test, and then withholding further medications because…
Readers Write 11/23/09
Submit your article of up to 500 words in length, subject to editing for clarity and brevity (please note: I run only original articles that have not appeared on any Web site or in any publication and I can’t use anything that looks like a commercial pitch). I’ll use a phony name for you unless you tell me otherwise. Thanks for sharing!
Our Success with EHRs in an Ambulatory Environment
By Stephen L. Badger
Hindsight. It’s the corrective lens which turns progress into a milestone. Imagine that anesthesia, antibiotics, germ theory, and x-rays each once seemed more evolution than revolution. This may be the case, too, with healthcare IT.
A few hundred healthcare institutions are exploring IT — some because the clock is ticking on a federal mandate, and some because their leadership sees value for both practice management and patient care.
The George Washington University Medical Faculty Associates entered the exploration into electronic medical records in 2004. It was a time of tremendous growth in our service capacity. That growth left us drowning in the millions of pieces of paper associated with patient charts. Costs for processing and storing that paper were mounting daily and the records themselves were, at times, unrecoverable. It was an unyielding drag on staff and led to patient dissatisfaction and frustration. For us, electronic healthcare records were like direct pressure on a bleed.
Chart room before and after
Chart room remodeled
The remedy began with a document scan which would play out over nine months and capture over four million bits of paper. It ended with elimination of chart pulls, the elimination of more than 30 full-time staff members, and the elimination of paper records storage. Initial net savings was over $1.5 million, but the dividends are still being delivered through improved accuracy in coding and the conversion of office space. Our old record rooms are now used for executive physicals, nuclear cardiology, digital x-ray, and new physician administrative offices.
The impact on patient care is equally positive on a national scale. Because each physician looks at the same central patient history, redundancy in imaging and other diagnostic orders is reduced at a great savings to the patient and the broader health care system. The prospect of prescription error is controlled, too, because the various treating physicians are working from the same record. That means they are less likely to unwittingly order a prescription which may interact adversely with medication ordered for their patient by another treating physician.
Here at the MFA, our patients can renew prescriptions through an encrypted, private network which processes refill requests typically within 60 minutes. That same system allows the MFA to deliver prompt, targeted alerts about news like FDA drug recalls.
Our records are shielded by firewalls, biometric passwords, and routine data audits which show what staffers have entered a record, what they viewed, and how long they lingered on a page.
MFA patients check in for provider visits at electronic kiosks which are much like those at the nation’s airports. Patients scan in using their unique palm print to preserve security and they answer a brief series of questions to confirm basic demographic data and insurance information. As a result, our records are more up to date and complete.
The kiosk registration will evolve as we extract targeted data which helps us improve an individual patient’s care. We envision that this data may pose tremendous advantage in transforming overall patient care, too, ensuring our patients are being treated on a proactive basis.
These data systems also may be helpful in seeking patients who would likely be helped with clinical trials and research. The potential impact for expediting the quantity and pace of research, especially longitudinal study, is exciting and just one more reason we believe we are living through a milestone in medicine.
Healthcare IT is improving patient care, practice profitability, and has considerable potential as a tool in clinical research. It is nothing short of transformational!
Stephen L. Badger is CEO of The George Washington University Medical Faculty Associates, an academic multi-group practice of world-renowned physicians affiliated with The George Washington University. The MFA consists of over 550 physicians deploying the latest advances of technology and technique through more than 41 medical/surgical specialties.
Are You Sure it’s the Software?
By Fourth Hansen Brother
There’s been a lot of focus on HIStalk lately about the customer side of HIS. Having worked on the “bandit” side of things for a few years, then as a consultant, I’d like to add to what’s been said.
There is an enormous amount of variation in the quality and culture of IT departments serving hospitals and clinics. This has a major impact on the design, quality, and implementation of HIS software. Let me explain.
Most folks on the customer side seem to think that the major vendors don’t consult with the people in the front lines of software. The thought that, “Gee, if only a doctor or hospital IT system created their own software, then we’d finally have a decent system” is common.
Folks, I assure you that every major vendor hires doctors, nurses, pharmacists, and other similar professionals to participate in design, often by the hundreds. There’s no shortage of medical folks willing to be tempted out of healthcare by software vendors. In fact, that’s part of the problem. It’s where they come from.
Your software vendors also find design partners out in the healthcare world, either with formal agreements or informal visits and shadowing. Depending on the luck of the draw, that’s either a good thing or a bad thing.
As noted in a survey that Mr. HIStalk linked to recently, most healthcare workplaces have severe problems. Politics reigns supreme and confrontation about minor issues happens frequently. Refinement or modification of workflows becomes impossible in those environments. These problems are often invisible to vendors at first. Vendors can easily choose a design partner that may have a department that’s become a personal fiefdom of a internal political heavy hitter and has done things the same way for thirty years.
The opposite happens as well — a hospital that’s run by a “thought leader” with oddball workflows in place and little sense of practicality. Vendors may not have the perspective to see that the emperors have no clothes. Hitting these problems with a design partner can cause severe problems with early adapter customers, often resulting in years of workarounds and remedial development.
Often, the vendor doesn’t have enough money to have the in-depth relationship with multiple design partners that it takes to put good software together. Healthcare has more than its fair share of egos. And there’s been more than enough research to show that health care professionals don’t keep up in their education or change their ways, at least on the clinical side.
If a vendor chooses the wrong design partner, or selects a good employee from a bad workplace, chances are that it will show up in a major way in the early versions of the product. As the product matures, these problems can get straightened out with the help of good customers and hard work from the customer-facing staff of the vendor. If the vendor is good, then all of the staff are customer-facing, including developers and testers.
The culture of healthcare customers can create some longer term issues. Many customers have major issues with trusting employees. Often certain types of employees want certain other types of employees monitored or their workflows controlled. Management wants all sorts of reporting and controls as well. The mistrust in certain healthcare organizations is pervasive, omnidirectional, and vicious. The mistrust can result in product enhancement that is weighted heavily towards these issues.
If a vendor has a design partner and early adapters with the same cultural issues, the functionality may be there from the start. Otherwise there will be a struggle to keep up. Of course, regulation (can anyone say HIPAA?) can not only force functionality into the system, but require it in a certain timeframe, causing major development schedule disruptions for the vendors.
Quality of HIT departments can severely affect implementations, or course. The early adapter customers are often the higher quality operations. They can handle implementation practices on the vendor side that are still in development, have a good grasp of the workflows in the organization, and have quality folks who can come to agreements on how to proceed in a organized fashion. Then come customers in the next wave, who may not be the bright stars, who need firm implementation processes, vendor help with workflows, etc.
Then comes the average HIT department. They may have an idea on how babies are conceived, but they often don’t know how they’re born or in which departments. Want to have fun? Ask a CIO what happens in the L&D department. Then ask the L&D department! Or ask where in the hospital babies are born. The answer may surprise you.
Vendors eventually develop lists of these customers who need special help when adding new functionality or upgrades — or when the vendor is sending out a new batch of replacement implementers on a project running several years overdue.
Decisions about configuration are either made off the cuff by top executives with little consultation with the subject matter experts in their organizations or worse yet, take months to bring together hundreds of people for a “consensus” decision. Warfare usually exists in the upper levels, with vendors and consultants often getting caught in the crossfire.
Often, a particular piece of software can go through dozens of implementations with quality healthcare organizations, only to run into problems when traversing to the next level of customer. This usually catches both the customer and vendor by surprise. Often, the vendor gets the blame (and often doesn’t dispute blame, since they shouldn’t be saying that the folks that bought their product turn out to be complete idiots).
If you hear of a product having problems at a particular site, ask at what point the vendor is in the introduction cycle and ask what kinds of problems they are having, Investigation might reveal that it’s not the vendor at all.
Concept – Hospitals that Expect People to Rely on Trust
By Healthfreak
Let us think how it would be to go to a hospital where there will no recourse to legal lawsuits, no visits to courtrooms. Patients come in and get treated quickly — no waiting for 5- 8 hours for a small surgery on a finger — and go back HAPPY.
It is possible, provided some mistakes by the hospital, doctor, or staff are considered "human" and patients do not go overboard in demanding legal action.
What can one achieve by all this ? Quite a bit. One, with legal hassles out of the way, the entire staff will be motivated to provide better and faster service and not resent their jobs. Equipment sold to the hospital will be economical, since the vendor does not factor legal costs in his pricing. Hospital administrators will offer economical service to the same patients. The overall insurance premium per patient will also come down and drive down healthcare costs as a whole. This is exactly what the US is looking for today.
Yes, there will be a fear that this may allow malpractice to go unchecked, vendors to sell faulty equipment, etc. A small percentage of cases may happen, as in any society. This, however, should not deter the introduction of a concept which will reduce the overall cost of healthcare.
The guru of AoL (Art of Living) has said that " the health of a society is determined by how many empty beds are there in hospitals and how many prison cells are vacant". May be we can add "and how many courtrooms do not have cases relating to hospitals".
Too farfetched? Maybe today. Let us debate this a little more openly and I am sure it will trigger some hospital into leading the way.
The problem is that lawsuits are viewed by many, if not most, hospitals as a financial transaction they plan for. They are not used as learning or process improvement opportunities and therefore the “errors” continue. These are not small errors, errors that can happen to anyone, they are life changing or life ending errors that could have been prevented. Good lawyers do not take the case unless they know there is one. What should be changed is 1) Hospitals are incented to learn and improve with every lawsuit, and 2) Lawyers who move forward with frivilous lawsuits are heavily fined and receive zero compensation, 3) Class action lawsuits that benefit the lawyers rather than the patients should be eliminated.
” the health of a society is determined by how many empty beds are there in hospitals and how many prison cells are vacant”.
Yeah, that may be true philosophically, but hospitals make their money by keeping their beds filled.
Congratulations to “Fourth Hansen Brother” for having the guts to voice a HUGE problem in any IT adoption project, especially CPOE. He’s totally right on – IT vendors hire many, many healthcare specialists, like doctors, nurses, pharmacists, med techs, etc., to design, critique, validate, test, and implement their systems.
The first problem is that, of course, there is no standard workflow in healthcare, sadly. Everyone does things somewhat differently. One docs effective drug interaction alert is another major headache. Alerts is an interesting topic on its own – when you know what they are going to alert you to, they are annoying. When they remind you of something you’ve overlooked or forgotten or didn’t know – you love them!
And, as I have also observed many times, the temptation for the “healthcare experts” is to merely automate what they currently do. In other words, these healthcare workers are not healthcare automation visionaries. They cannot see a future state. And even if they could, they do not have the clout, or the time, or the buy-in to actually change/eliminate/improve current processes with healthcare. So, the easiest thing for them to do is to simply automate the exact same workflow that they currently embrace.
How many times have I been to a site of an automation project to see them using the system in a completely inefficient manner. When I would pipe up and say “you know, the system will allow you to skip those three steps with no adverse effects to patient care and which will make your process more efficient and effective” – only to hear the hospital staff say “oh no, we couldn’t possibly do that. Our pharmacist/physician/nurse (pick your poison) insists that we leave that step in” – even though the majority of their staff is resisting adoption of the system BECAUSE of these extraneous steps.
I can play this game all day. I can name hundreds of examples where a really good system was implemented so poorly that it actually resulted in a worse workflow than they previously had. For so many reasons. My favorite is “We can’t do it that way – we’ll kill patients!”. Control freaks run rampant in healthcare. And they love to use the “we’ll kill patients” excuse for every anal rententive required step they want to include in the new system.
These control freaks, with the best of intentions, can take a great system, even one with huge amounts of flexibility, and turn it into a horrible piece of crap that no one ends up wanting to use.
You hear a lot of press about the Cerner implementation in the U.K. I do not work for Cerner, but I assure you that the bastardization of their system, especially regarding patient registration and appointment scheduling and check in, was not the way the vendor recommended it be implemented. And Cerner has yelled loudly about getting it changed – and no one listens. They have created a bureaucratic maze of decision making for the smallest changes that make it impossible to make the tiniest of improvements. They have made extremelyl poor design decisions in implementing the system but they refuse to change them!
You see this all the time – with all IT vendors.
Everyone in healthcare thinks that they know how to design the BEST solution, if only someone would ask THEM. But the truth is, it would only be loved by that designer. Every single physician has their strong opinions about how their apps should work (actually, physicians believe that the system should READ THEIR MINDS and, for example, only display alerts on things like drug interactions when they don’t already know about that interaction – and somehow know which docs know and don’t know, and alert them accordingly. It’s absurd).
It is actually much easier to launch the space shuttle to the space station and return it safely to earth than to design a CPOE application that all physicians will universally embrace. I swear – it has to be one of the most thankless and aggrevating jobs in the world.
EPIC probably comes the closest to happy users, but I have seen some pretty pathetic iimplementations of their system as well.
It’s true what they say – we humans HATE change worse than we fear failure. Or a poorly implemented system.
Yes, vendors hire many clinical people to ensure they understand that perspective. Unfortunately, they and the hospitals which implement their software don’t seem to equally value solid IT knowledge and experience. I was at dinner after an EMR client visit some years ago with two RNs who worked at the the same vendor as I. One was now a functional consultant; one a PM. They stated, “Well, you know clinicians can learn IT, but ITers could never learn the clinical side.” Come on now; let’s get real.
Wow, BeenThere/Done That: I laughed reading your response, because you are so dead-on. It’s no laughing matter, normally, but I loved reading “Everyone in healthcare thinks that they know how to design the BEST solution, if only someone would ask THEM.” That pretty well sums it up for so many on either side of the equation here. There are so many factors that go into a well designed system that actually improves things at a given site, but you’d never know that reading many of the simplistic, bumper-sticker statements made by so many here. I’m an ITer with 30 yrs experience, and I appreciate what you’ve said.
Been There: You’re right… that is so absurd. And if it were true that clinicians can so readily learn IT, I think we’d see the wonderful results of their brilliance by now.
Before the clinicians bring out the pitchforks, I’ll acknowledge on behalf of myself and “No Dr.” that IT (information technology) is EASY to pick up. Anyone can reset a password or follow an install checklist or click on the mouse a few times. Bang on the keyboard. Reboot a server. Make some PowerPoints, drag some boxes with arrows onto a Visio diagram, write up something in Word. Use the administrative interface of whatever vendor product you’re chained to, and call support if you have problems. Not hard to pick up.
On the other hand, system design, specifically flexible/extensible/usable system design, is NOT easy, and should NOT be practiced by amateurs (both clinical and non-clinical folk). User Experience experts, experienced business analysts (who are preferably clinicians), and a competent development team (what I consider competent, you may consider setting the bar high). The older wiser business analysts I’ve had the pleasure to work with have had a knack for :
a) getting to the core problem, instead of taking requirements at face value, i.e. “what are you trying to do again?”
b) simplifying
c) gently, subtly arguing with the customer, without getting their hackles up
d) other things I’m leaving out
Compare this to the clinician who is still enthusiastic about using technology to solve problems…the one who has written Access databases that have a 40 page manual detailing some 10 weekly processes, 50 extraneous tables, and which could be eliminated with Excel and some pivot tables. You don’t want that person designing a system, you want them to get some experience first. Any system they design is inevitably overcomplicated, precisely mirrors current broken workflows, and completely inflexible to change. Their system has 10 forms when an Excel spreadsheet would do. Their heart is in the right place, but they need some experience.
Unfortunately, as far as I know there aren’t good books to cultivate the skill of business analysis, just experience.
I’d be curious to hear if anyone has a good BA book or textbook they’d recommend.
Some EMR “Success Stories”…can be misleading
Regarding Mr. Badgers discussion of “Success with EHR’s in an Ambulatory Environment”—-do you really think you are representative of a typical independent practice? With 280 physicians, and a sense of pride in the important teaching your staff does in association with the University, with students, residents and fellows, clearly it’s not the same “environment” as the typical, fee-for-service, non-salaried ambulatory practitioners out there that make up 60 or 70% of physicians in practice. Even with your stated average of 4,600 patients per day, that’s only 16 patients per physician per day on average. How many practitioners can even make a decent living seeing that many patients per day? But with that kind of load and income non-dependent on seeing more, many more things can be done with their time, I’m sure. Not the case for most physicians in “ambulatory” practices.
Barriers to EMR adoption by ambulatory practices in the broad market have long been more than just the purchase price. The alarming failure rate (“lack of successful deployment, didn’t work as hoped, too much resistance to using it, far more difficult to use than thought, took up way too much time and slowed the patient load, providers quit using it, etc) of EMR in ambulatory practices up to this point has caused considerable “collegial ambivalence”. This is a term now used to describe how providers themselves, when engaged by their colleagues about their EMR usage, are considerably divided on endorsing it. This is especially true among high-performance providers and specialists.
Most “certified” EMR’s available today, incur a significant productivity drag on providers with a high volume of patients, or whose exam-room time is shortened considerably by surgical or procedural schedules. The amount of time and frustration it takes busy providers to navigate the “point & click” menus that a traditional EMR employs to document an exam more that offsets the gains made by the tremendous advantage of getting all records, charts and reports into digital form and universally accessible.
Right now, providers and practices bear all the risk of a “failed” EMR implementation. They pay the price not only in the purchase, deployment and learning cycles, but in the on-going productivity hits to their practice as well. Even the ARRA stimulus funds won’t offset that.
Best advice for providers in ambulatory practices: FIND OUT WHICH EMR VENDOR CANDIDATES will provide several practices in YOUR PRACTICE SPECIALTY and SIZE/VOLUME OF PATIENTS CHARACTERISTICS. Find out how long it took to deploy and how productivity is impacted. Until there are some better industry studies to actually provide this data, all is anecdotal. And stories like Mr. Badger’s could lead practices with far less resources and patient-load burden….to make really wrong decisions.
I have both a clinical background as well as an IT background. I’ve designed and developed systems, and I’ve been out in the field helping to implement them as well.
I will say this again – it is one of the hardest jobs that exists. Everyone wants change but no one wants to BE the one who has to change.
I love and salute ALL healthcare workers, especially physicians, nurses and pharmacists. They work in an incredibly difficult climate of budget cutbacks and governmental and regulatory controls.
And I also love and salute all IT developers who strive valiantly to deliver solutions that healthcare workers will use to deliver better care and save more lives.
Envisioning a “future state” is hard. Most people are not equipped to truly envision it. They might be able to envision some improvements that directly impact a workflow that they use every day. But few can truly envision a radical, enhanced workflow that eliminates existing steps and even anticipates the need for information before its’ requested.
This is a huge conundrum. Healthcare providers want things to be better but they’re not sure what an improved workflow would look like, especially when it crosses interdisciplinary and departmental lines. IT developers ask questions and model new applications and workflow with healthcare providers, but they are often given misguided or highly biased responses. And getting everyone to “buy in” to the design decisions takes months and months of debate in committee meetings. And sadly, another observation from working decades in healthcare IT – many hospitals will assign their “weakest” links to the IT projects – people that they don’t know what to do with or want to keep out of their hair. People that aren’t good communicators and concensus builders. Folks without vision.
So, how does a hospital end up with a great system implementation? By creating the best design they can – and then constantly watching it, adjusting it, making steady and swift incremental changes. Many of this board have made the same observation that I now state – “Once the system is turned on – that’s when the work really begins”. Once you’re using the system, don’t be afraid to constantly revisit your decisions. Keep investing in making it better. Many systems out there are highly configurable – which means you can alter how they will behave by adjusting configuration settings (vs. waiting on IT software modifications).
Keep working at it AFTER the implementation. Don’t hold on to bad decisions out of pride. Watch and listen to your end users. Respond swiftly to improvements that can be made that will help them get the most out of it. Don’t make them wait years while you send things through endless committees. I could tell you horror stories of hospitals dealing with daily pain in using a system when a 2-minute configuration change could have removed it – but they insisted on months of sending the “change control” through a zillion committee meetings.
Be safe. But be practical. Be diligent. And never stop revisiting your design and workflow processes. You will not have the best system on day one of implementation. But with constant improvements, practically and swiftly implemented, you will win over your end users because they will be able to SEE the system adapting to their needs.
Is it expensive to do this? Yep. But, you should have factored that in at the onset.
I wish everyone out there good luck and best wishes. What you’re doing, whether it be on the IT side, or the clinical side, is HARD. Do not believe otherwise. It is incredibly hard. But, it’s do-able. And there ARE returns on investment if you keep at it. Don’t believe those that are afraid of automation and don’t see the benefit in EHR’s. Clinical patient information MUST be readily available in electronic form to those that need it to take care of patient lives. To believe otherwise is, in my opinion, dangerous.
p_anon: I couldn’t agree more.
Been There/Done That: Bravo, bravo… Beautifully stated.
These two entries by p-anon and Been There are SO true, yet so often disbelieved or just not understood how true it really is.
There are many, many attributes needed to help assure an excellent system, and any weak or missing link can decrement the probabilities by magnitudes.