Perspectives on the Acute Care Continuum

The Acute Care Continuum is the integration of urgent, emergent, inpatient and post-discharge care of patients with acute medical conditions. 

Your EMR Conversion: What Can Go Wrong (Often Did)

5/16/2013 4:53:19 PM | 0 comments

If you have practiced healthcare pretty much anywhere in the United States during the last five years, you have probably been involved in at least one Electronic Health Record (EHR) conversion or implementation. In some cases, you may have converted from a user friendly template to a less user friendly EMR. In other cases, your hospital may have converted from one EHR brand to another. Regardless of the specifics of your transition, it is likely that some degree of frustration happened at the point when you adjusted to the first EHR. And it is also likely that after months of frustration you contacted one of those Scribe companies.

EHRs are still in their relative infancy and continuously improving. Penalties for not automating will be implemented in 2015, so they are here to stay. Learning from implementation issues is critical to improving implementation and effective use of EMRs. 

I have been involved in a number of client EHR conversions during the last decade. And although EMR systems are improving, the start up phase is often problematic. Much has been written about EHR implementation and training, but not much about the implementation aftermath; as well as how to prevent the implementation issues from recurring the next time your hospital converts (as they most likely will).  Below are some of the key issues that may arise during an EMR implementation, along with a few lessons and questions from my experience over the years working in the Acute Care Continuum.  (A note: I am using the terms EHR and EMR (Electronic Medical Record) interchangeably, although a distinction is that an EHR tends to be a hospital wide implementation that is inflicted on the ED, while an EMR tends to be a self-inflicted practice-specific implementation). 

Provider Training

It is a given that time and planning were allotted for provider and stakeholder training. In addition, an EMR “super user” or champion was probably appointed from your colleagues. But post start-up, charting speed and accuracy have  suffered. What went wrong?

Was enough time really allotted for provider training? Learning to use an EMR and becoming fast and proficient at complete documentation are separate issues. Training must be organized, well documented and geared toward the challenges of your specialty. 

Was the training appropriate? You did receive adequate training in use of the EMR. But was the training geared toward achieving complete documentation? Often EMR trainers are more versed in computer coding than Current Procedural Terminology (CPT) Coding. ER coding personnel at your facility should have input and be involved in the implementation and training.

Was the training complete? Were there meaningful EMR competency benchmarks? Consider developing a course for EMR use that leads to a completion certificate. Providers can learn from coding entities that typically require at least 95% accuracy as well as reasonable speed in coding your services. To prevent the type productivity and quality drop off that is often experienced post implementation, consider establishing benchmarks for key chart completion elements such as HPI, ROS, FH, SH etc... as well as procedures. Training is not complete until the provider has achieved 95% compliance.

EHR Implementation Deadlines

A second issue is the problems often encountered in meeting EMR implementation deadlines. For example, a client of mine in the Midwest once experienced multiple deadline delays with their EMR conversion. In addition to causing stress and affecting productivity, the missed deadlines had the effect of delaying other projects affecting the ED. What can be done?

Set realistic, flexible deadlines. Deadlines are important as a measure of project management. But time must be allotted for the training, testing and connectivity issues that come with EMR implementation. If the necessary time is not allotted at the front-end of the project, often a great deal of hospital IT personnel time is burned trying to make the EMR work.

Have a back up plan. Things that are controllable, and some that can’t be controlled, do go wrong. I once saw a client with a well-planned EHR conversion in the direct path of Hurricane Sandy in the middle of their EMR implementation. In fact, their project manager was stranded in a shelter on Long Island! We all want to believe new technology will work in a timely fashion, but a Plan B is often necessary. If you are converting from a paper template to an EMR, a phased in approach might be considered with the necessary supply to cover implementation emergencies kept on hand. If possible, the same phased approach should be considered for an EMR to EMR conversion.

Get the necessary support. Support is typically provided with EMRs. However, the support required for a clean, timely EMR implementation is sometimes lacking. Your hospital should be contracting for the support needed, but that doesn’t always happen. Additionally, the support personnel might not understand all of the documentation issues specific to your practice. A commitment and proper time allotment from all of the stakeholders whether clinical, IT, EHR or from the EMR entity is necessary for a timely conversion.

Connectivity

A major selling point of many EHRs is the ability to interface with multiple provider sites, such as the lab, other practices etc... And the good systems generally do connect. But the assumption can’t be made that connectivity will be seamless. For example, EDs often outsource their coding. This means that the EMR must interface with an outside vendor or the vendor must have access to the EMR.

A client of mine once put major effort into all interfaces, including the billing company. The entire chart was visible to coding personnel. But there was only one problem: the provider signature was not visible to the outside coders. A workaround was then completed to solve the problem, but only after a major back log of unsigned charts developed.

All interfaces and connections of any sort must be identified and tested multiple times prior to go live.
I hope this helps, and I would be interested in your comments and experiences working to integrate this technology that is such an important part of the future of healthcare.

Topics: Health IT

Comments
Blog post currently doesn't have any comments.