No one really likes dealing with sales people. There is just a general feeling of mistrust that usually exists around salespeople. However, it is important that you create a good relationship of trust with that person so you can ask good questions. During an EMR demo you will see a lot of great features on the ideal system. Unfortunately, it is often the ideal system for a specific office for which it was designed. If your office is ideal then there isn’t a problem.

Since you are still reading I assume that you don’t have the ideal office(not to mention it doesn’t exist). This means that your office is going to have to adapt to the EMR software. Don’t expect the EMR software to adapt to you. Even with the most reactive customer service friendly EMR(which I consider mine to be at the top in this area), it just takes time to make changes to software, test them and then deliver them to the customer. So, the ease or difficulty in implementing a software depends on how close the software mimics your method of doing business.

Let me give an example for those visual learners. One of my evaluating clinicians asked, “Can your EMR handle a walk in ONLY system?” The EMR vendor had some great features to handle walk ins and intermix them into a clinicians schedule. However, somehow the ONLY was missed in a sales communication. It would have been much better to ask the EMR vendor, “How can your EMR handle a walk in ONLY system?” Then, follow it up with the question, “Can I see it?” Now you can actually envision what this EMR vendor would be like in your “ideal office” and what you would need to adapt to use that EMR in your environment.

If you are implementing an EMR you need to understand the difference in types of interfaces. Unfortunately I bet this is a significant misunderstanding that occurs when discussing interfaces in an EMR purchase. Maybe this opinion is biased because that is what happened to my clinic. After a few long discussions we finally understood the questions we should have asked rather than assuming we knew how an interface works.

The assumption that was made by my clinic(thankfull not me since I hadn’t been hired) was that the interface would be bi-directional. What does that mean? That means that when a Pharmacy is ordered by a Doctor the script would automatically be available in the Pharmacy program(one direction). Then, when the script was filled it would post the charge back to your EMR(second direction). The assumption was made that this would just happen without considering a few questions. First, what happens when someone doesn’t want to fill their script at our pharmacy? Then, the Pharmacy database is filled with a ton of scripts that they never needed to fill. Also, what happens when a drug is filled in your EMR that isn’t available in your Pharmacy program? How does your HL7 interface match a prescribed drug with the drug in the pharmacy database which has enough inventory? How does the interface pass the charge back when someone brings in a pharmacy from another doctor?

For those of you familiar with HL7 interfaces you know that many of these things can be solved. In fact, I hope that somebody will post some ideas on the best ways to accomplish this. However, these are important things to consider and discuss when purchasing an interface. In many cases the “mythical” concept of it all just working may leave you with a uni directional interface.

Not that a uni-directional interface is bad. The fact is that my clinic currently have two uni-directional interfaces. One direction patient information and insurance eligibility is passed. The other direction charges get passed back. This has worked out quite well even though we expected a bi-directional interface.

The moral of the story is to Ask Questions and then Ask MORE Questions! You aren’t an expert on HL7 and you have the right to know what your vendor means by an HL7 interface.

I imagine there are other options than HL7, but so far I haven’t seen any. So, I’ll assume for now that there aren’t any until someone corrects me.

I was just browsing an EMR company’s website(which I shall keep nameless) and I clicked on a link that I thought would be interesting. Here’s what I found:

Appointment Scheduler
Automatic Call&Confirm Phone Appt. Reminder.
Electronic Medical Records (EMR)
Complete Billing
Web Access and Security
Call Center (Document Calls)
Transcription Integration

Electronic Prescription Writer
Electronic Orders (Labs, X-Rays)
Image/Document Management
Wireless Enabled
Secure Internal Email
HIPAA compliant security
Solo/Group Features
FREE Customization

I’ve put in bold a few of the features that actually sound pretty nice. Having the Automatic Call and Confirm built into your EMR is great. Web Access to your EMR could be great if that means you could access it remotely. There are some security questions there, but they could be dealt with appropriately. Web access also is nice if you can avoid managing client installs. Secure Internet Email could be a nice thing, but unfortunately that requires your patients to have a secure messaging system too. There are ways around it, but that’s a topic for a different post.

When I took a look at the rest of the list I couldn’t help but laugh. Appointment Scheduler, EMR and complete billing seems a bit vague. Isn’t that what the page is suppose to describe? I was hoping to see a list of how they implemented appointments, EMR, and billing. They did at least tell us that their billing is complete.

It is nice that they told us that their EMR has security. Although I still don’t know what that really means. Is there such a thing as an EMR that doesn’t have security? None that would claim that as a feature.

The rest of the features are pretty vague, but the one that killed me most was “Wireless Enabled.” Amazing!! Maybe someone can point me to an EMR that isn’t.

At least you can feel comfortable with buying this EMR because if you don’t like something there is FREE customization. I’d get that one in writing!

My point is that if an EMR vendor wants to have a website then they should offer some worthwhile information and not just put up junk because “They Have to have a website.”

When implementing an EMR we really wanted the ability to pull up patient’s record with the swipe of the card. Not to mention being able to allow patient’s to check in using their card. I understand that this situation may be unique to a Student Health Center at a University since you know that each person has a university ID card. However, this was an important request for a College Health Center. Not to mention it illustrates a perfect example of a miscommunication that could occur during an EMR sales discussion.

In the discussion the EMR vendor was excited to point out the ability to be able to swipe a student ID card and pull up a patient’s account. Everyone was excited until we found out how the swipe worked. Basically it would match the strip on the card with one of the ID’s stored in the EMR. No problem, until we found out that the Student ID wasn’t actually what was encoded on the strip of the ID card. Instead it was some ISO number that was only used by the proprietary campus card reader system. We could have uploaded the ISO number instead of the Student ID, but then that complicates pulling up patients that don’t have a card and we really didn’t want to expose the ISO number to anyone. Oh the details of implementation.

I don’t think the EMR vendor lied or did anything wrong. It’s just that we didn’t ask the right questions or have the information we needed to understand what is really possible. To our vendor’s credit they have since implemented a hidden field in the database that can use our super secret ISO number.

When purchasing our EMR we were told that you could get a lab interface with the EMR system. All sounded great, but there was so much information that we found out later. Here’s a few things we wished we’d asked when talking about a Lab Interface.

First, how much does it cost us for our EMR vendor to implement a lab interface. This is important, because usually the lab interface has to be customized to each client and often incurs a cost to the emr user. There are some possibilities that the EMR vendor will provide it at no cost. However, you must check it out. During the sales process the EMR vendor will most certainly say that they have built a lab interface with and that they shouldn’t have a problem doing it. This is great, but you need to know how much it costs.

Second, how much does it cost for your Lab vendor(or software program for in house labs) to interface with your specific EMR. Many labs may already have an interface with a certain vendor and offer this service for free. Also, if you are a large enough customer they may do it for free also. However, it all has to be negotiated and you don’t want to learn down the road that they want another $5k for their part because you chose a certain EMR vendor that they have never interfaced with before.

Third, you need to ask your EMR and lab if they can interface together. Usually this isn’t a problem because most people will use a standard HL7 interface. However, you don’t want to find out later they don’t.

Fourth, will your interface be able to run on your EMR server or do you need to purchase another server(or workstation) to host your interface? Many times the answer will be you could run it on the same machine. Anytime they say could that means you need to look at the pros and cons and decide for yourself whether you want them on the same machine. I personally reccomend having a redundant server for your EMR system and using that as the interface server. Kills 2 birds with one stone.

These are the major factors that we didn’t understand about an interface. In another post I’ll discuss bi-directional interfaces vs. uni-directional interfaces and why interface with a lab and costs to implement.