Free EMR Newsletter Want to receive the latest news on EMR, Meaningful Use, ARRA and Healthcare IT sent straight to your email? Join thousands of healthcare pros who subscribe to EMR and EHR for FREE!

EHRs Don’t Support Key Parts of Practice

Posted on June 3, 2013 I Written By

Anne Zieger is veteran healthcare consultant and analyst with 20 years of industry experience. Zieger formerly served as editor-in-chief of FierceHealthcare.com and her commentaries have appeared in dozens of international business publications, including Forbes, Business Week and Information Week. She has also contributed content to hundreds of healthcare and health IT organizations, including several Fortune 500 companies. Contact her at @ziegerhealth on Twitter or visit her site at Zieger Healthcare.

Ideally, EHRs make the clinical exams more efficient and effective, ultimately saving or even making more money for medical practices.  But the reality is that they bypass other parts of the patient encounter where much of the costs and inefficiencies are generated, according to a whitepaper by athenahealth, “The Economics of Patient Workflow: Cracking the Code of Successful EHR Design.

As the paper notes, 100 percent of practice revenue is generated by the patient exam. Other stages of managing a practice, such as orders and results management, generate 30 percent to 40 percent of costs but no revenue at all. So having an EHR in place which does little to improve exam efficiency — or actually reduces it — is a dangerous thing to do to a practice.

Worse, as the paper points out, there are some major flaws with typical, software-based EHRs:

* They’re too expensive:  Typical cost is $33,000 per physician plus $1,500 per doctor per month for maintenance.

* They don’t save money because they slow doctors down:  Most EHRs force physicians to do a lot of data entry, much in time-consuming, structured formats.

* They aren’t designed to manage the P4P cycle seamlessly:  With most EHRs, doctors have to dig out the data needed to create pay for performance reports.

* They usually don’t offer an efficient, closed-loop solution to the problem of monitoring paper and electronic orders and results:  Remember, orders and result management generates as much as 40 percent of practice expenses.  EHRs’ failure to make such tracking efficient is a major obstacle for medical practices.

Few EHRs support follow-up work from orders and results effectively:  Most EHRs don’t include built-in management and tracking of patient communications, forcing providers to do inefficient and potentially risky manual follow-up.

The white paper goes on to make the argument that there are several reasons why Web-based EHRs solve these problems, largely by requiring no up front cost, using up less physician time on data entry, optimizing collection of data for P4P programs, digitizing all paperwork and tracking practice results.

Pay For Performance, Patient Outcomes, and the Rock of Gilbraltar

Posted on April 30, 2009 I Written By

Quickly, now — which is easier to support?  I’ll give you a hint — most times, my little 5’0 personage would be choosing hoisting that rock on my shoulders.  Honestly, though, I’ll say that famous answer in healthcare, that it depends on the clinic.

Many years ago, when I was working for a very large multi-site cancer center,  I was called into a meeting with all the bigwigs.  You know, VP’s and such.  It was my first time, so be gentle.  I really didn’t understand why I was being asked, and the meeting invite was notoriously vague.  I was ushered into a very posh board room that I didn’t even know that we had (complete with video conferencing), at a round table with approximately 27 other people who were most definitely paid a lot more than I was (and had a bit better fashion sense, compared to my frazzled, just out of the data center look).  One of the VP’s announced that he was planning to look for a cancer-specific EHR/EMR that would encompass both radiation oncology and medical oncology, and interface with the main EHR that the hospital overall was going to implement.   He wanted to use the data that we gleaned from such a system to support one of the largest research studies done in a particular type of cancer therapy, in a prepatory round for pay for performance.  Then, he informed us that one of our vendors had said they were able to fill this need. 

The problem was, I knew that they couldn’t.  And I’m one of those people who doesn’t know, apparently, how to keep her mouth shut.  My immediate response was “They’re lying.”

“Oh, but they promised me.”

“I understand that, sir.  But they ARE lying.”

 I ended up with another four hours cut out another one of my days to be one of the folks who had to sit in on the demo.  Even worse “SM” pulled me aside and told me I had to run it, and I had to prove or disprove whether or not this integration was possible.   It was a grueling four hour ordeal for both me and the dog and pony show man, during which I did indeed uncover that they weren’t an integrated solution.   When I did, someone actually got up and ran to tell SM.

Moments like those make you wonder.

Even after we reported back to SM that we absolutely would not be able to support this research with a system (this vendor, we knew, was the closest), it was decided they were going to go forward.  Somewhere in all of this, I was assigned the entire deal — from the construction of the database to hold it (and the ability for folks working remotely to log into it to use it), to the design of the forms to gather the data (ranged from size of tumor to dosimetry data to whether or not they could still spit or eat steak), to the management of the bodies in motion.

Because I started as a database guru, I was given the task of cleaning up the treatment system data for radiation oncology, and bumping it up next to the chemo information we gleaned from registrars examining paper charts, and minimal amounts of information regarding the medical oncology from the paper chart and billing data.   Two of our radiation sites were ‘islands’, and yet another one at the time didn’t even have a robust record and verify system at the time.  This made for an extensive process.  Since part of the research was being administered as a telephone questionnaire, I also had to come up with the best call lists as I could.

I made sure to filter all the dead patients I possibly could out of the data set — not only did I use the SSI Death Index (doesn’t include goverment workers or teachers, and several other occupations), but I also used all the systems we had for the entire health system (I was a cool kid with the access).  I did everything I could, but in the end all of that was beaten when I sent the list to the site managers, who had their secretaries note additional deaths they had recorded from the newspaper.  You see, that was actually our best way of determining if a patient was, in their terminology “CTB.”  Which means Cease to Breathe.  I requested in earnest that if I died, that I was called dead.

In the end, they got their data — and we went through this painful process two more times for two other studies of the same therapy across differing diagnoses.  But one of the hard lessons came when I was cleaning up some of the data (I was one of the people who helped to type it in, since some of the clinics didn’t even have remote access due to affiliation issues).

The question was regarding whether or not the patient could chew their food.  You see, shoot enough radiation at someone’s head (it was a head and neck study), and their salivary glands won’t work. 

Unfortunately, the doctor had not properly noted the patient’s diagnosis ANYWHERE – it was billed wrong and clinically noted wrong.  We knew it was somewhere in the head, but it was a very non-specific head and neck ICD-9 (lemme show some ICD-10 love).  So, when the nurse called and asked the question, the patient’s wife had answered:

“You cut my husband’s tongue out.”

Lesson:  Every physician must be a champion of health data in order for HIT to truly succeed in any realm.