Insightful User Experience with e-MDs EMR

The following is the experience of one user who’s switching their EMR from Penchart to e-MDs that I think is insightful to consider before selecting an EMR so that one day you don’t have to deal with these issues. You can find the original posting on EMRUpdate. I’ll add a few takeaway points at the end.

We are a 10 doc /3 office practice that is going from dinosaur Penchart to e-MDs. We were supposed to go live a few months ago but we are huge issues getting our data converted (it ain’t going work) and getting training. We are a very EMR established practice having started using tablets and our EMR 5-7 years ago. We have pushed back our GO LIVE date 2 times already.

Were are now on our 3 project manager and we are just finding out that our data won’t port well to e-MDs. We new it won’t be great but it took a year to find out how unsuccessful it will be. e-MDs wants to train us but they do not want to look our current workflow to see how customize e-MDs to fit our current methods. “This is how we do it”. Our practice has 40,000 patients and 10 doctors (some of which are old school and have a hard time learning a new way).

I think the software is going to be great but our trasition to is is more painful then we ever thought.

Anyone have same experiences with e-MDs specifically?

Are there similar experiences with many/all other EMR conversions?

Our frustrations are the we get new answers with each or our 3 project managers, the original sales person “is no longer with the company”, 3 rd party conversion company is much less helpful they previously thought, and e-MDs look looking at our situation to see how best to aid our training.

My takeaways:
-Large EMR companies are going to have a problem scaling project managers
-EMR data conversions are a pain and you better have the right people doing it or you’re in trouble
-We need better standards for exporting patient information to avoid EMR data conversions
-Verify your EMR vendors ability to customize to your workflows or prepare to change your workflows

About the author

John Lynn

John Lynn

John Lynn is the Founder of the, a network of leading Healthcare IT resources. The flagship blog, Healthcare IT Today, contains over 13,000 articles with over half of the articles written by John. These EMR and Healthcare IT related articles have been viewed over 20 million times.

John manages Healthcare IT Central, the leading career Health IT job board. He also organizes the first of its kind conference and community focused on healthcare marketing, Healthcare and IT Marketing Conference, and a healthcare IT conference,, focused on practical healthcare IT innovation. John is an advisor to multiple healthcare IT companies. John is highly involved in social media, and in addition to his blogs can be found on Twitter: @techguy.


  • Data portability is always going to be a problem. Everyone has their own way of wanting to look at the data, their own beliefs on what is the most efficient way to store and what is most efficient way to transfers/transport.

    One of few things need to happen to improve the situation:

    * The federal government mandates data compatibility. Probably the worst case.

    * The AMA or specific practice groups (ENTs, Orthos, etc) dictate data compatibility requirements, along with best practices (ie, dictate the data flow)

    * The EMR/EHR vendors form a trade association that mandates data interchange requirements. Probably the best solution but the one that will take the longest to emerge, as it seems each of the vendors currently see vendor lock in as good thing.

  • Of course, the short term temporary solution is to export the data from the old system in PDF files (or something like that) and import it that way. Still a less than ideal solution, but better than guessing how to convert the data in many cases.

    I like the analysis of 3 ways. The best one is the EMR/EHR vendors joining together, but that’s not even on the horizon yet.

  • The issue goes deeper than just how to extract the existing data.

    For example if the old system generates a patient id that it tacks on to the patient’s last name as an identifier, how does that map to the new system? What if the new system uses an encrytped SSN or Tax ID as the identifier?

    What is the old system stores physician notes indexed by patient id and CPT code in a separate table and the new system contains it all in one table .. even the reverse will cause problems in migrating data.

    The situation becomes even more complex if the vendor is using internally developed storage as opposed to commercial RDBMs, but even with a commercial RDBMs (Oracle, DB2, MySQL, etc) you still have the issue of mapping data between fields.

    Maybe I should just start a company to do nothing be data migrations from one EMR/EHR system to another. 🙂

  • We’re a 6 physician, 2 office practice using e-mds Solution Series for 4 1/2 years. Most practices convert from an old paper chart practice to an EMR as we did. Overall, the transition went smoother than everyone expected. Converting from one EMR to another is a difficult undertaking. As John commented, exporting the data as PDF’s seems like the best way to go. The 3rd party vendor should be able to pre-load your patient demographics. As far as trying to customize a practice mgt EMR to an existing workflow seems odd?? The EMR should customize your workflow not vice-versa. Otherwise, I’d suggest you just design your own EMR if you have a certain workflow that you wish to use. Our workflow can’t be any better than it is with e-mds Solution series. Sounds like you’re all trying to put a square peg in a round hole. I’d recommend you just use the round peg.

  • Mike,
    There’s a lot of money to be made converting data from one EMR company to another. Plus, that market will never dry up. Even if we have 100% adoption of EMR software, there will still be people switching EMR.

  • Clyde,
    I disagree that you should customize your workflow to the EMR. I also don’t think you necessarily should take all your existing processes and move them to EMR. It’s a balance of the two. An EMR vendor should facilitate that balance. However, when selecting an EMR you should have a good idea of which processes you want to keep in an EMR. This is especially true in the case that you already have an EMR and are just switching.

  • Being in healthcare implementation and support for quite some time now, I can totally understand what the problem is. Porting is always a problem. It was a recent experience I had similar to this. A new customer wanted all his existing data into our new system. This was not initially contracted. So we never knew they had this expectation to see their existing patient data in the new system, we thought they wanted it all fresh. Finally after a lot of discussions we succeeded. For this I can only thank the framework my company application is built on. Our aim is to be like a glass, you pour water or whisky it takes the shape of the glass but still retains its basic nature. 😉

    only a recommendation: ever get a chance visit and tell us how our application wont suit you!!

  • Poorna,
    Data conversion is a challenge and the hardest part is that you really never know that you got everything out. You can know you did pretty good, but there’s always that lingering doubt that there was some exception that you didn’t know about.

    What did you think about the challenge of adapting the workflow of the EMR with the clinical workflow?

    One problem I do see with your application is that they’re not advertising on my website: 😉

  • I agree with your point that we cannot always be sure that every thing has been covered when we do data porting, but its good if we are optimal. And as always, porting data can be cyclic. Data porting must happen in multilevel, integrity should be maintained.

    When it comes to maintaining the workflows, why would I want the doctors to change their regular process and follow what is there in my system? It would be just like asking a C programmer to implement high level Object oriented concepts which is possible but worthless. Let the doctor command the application not the application dictating the doctor.

    I am strictly not making a sell on this discussion but I am sharing a concept that Nd Orange implements. We dont decide what the doctor should do, we let the doctor decide what he/she wants to do. We actually have a plug and play framework, so your workflows are intact always. its a fact that 60-80% of most practices have a similar workflow (do you agree with me on this?) and there is a requirement for the balance to be customized. This is what ND Orange adheres to. First quarter of 2010 we have couple of large rollouts of which porting customer data is one challenge activity. Will try to keep you posting on how things will go and new challenges if any as most of them are/will be handled prior. Merry christmas all!!

  • The problem with customizing the application (EMR/EHR system) to each practitioner is that you loose a standard base for service and support. A problem at customer A with resolution A, frequently will not have the same resolution at customer B, if the solutions are highly customized. The more customization there is the bigger the issue.

    As a customer, the more customization that occurs affects 3 things: 1) Probably better, quicker adaptation by the users because it seems familiar.
    2) When problems occur, longer and more expensive resolutions
    3) More money spent on “consultants” to keep things running and up to date

    While is certainly possible to do it, as a provider you need a very good, very strong service oriented reputation, otherwise you won’t get to be the size of Oracle or SAP (two computer industry companies that make a large portion of their income from customization and upgrade services). In my 25 years in the computer and software industries, Oracle and SAP style companies are the rarities.

  • Poorna,
    I agree that there should be a reasonable amount of customization. If there isn’t, you’ll never sell any product. However, finding the balance of customization with standards is a real challenge.

    As Mike says, once you start customizing the solution for the various clinics you increase the number of problems you can have next time you upgrade. It’s always amazing to me when we upgrade our software how our EMR vendor can make a small change which has a significant and unforeseen impact.

  • Right said. Unless there is customization it would be tough for any EMR make a sell. The general architecture should be: Core EMR + Customized EMR. As told earlier, the core EHR would make more than 70% in most of the cases. And the extra 30% should be practice specific, however this will be at a cost. When you upgrade, you upgrade the 70% in common for every customer and the 30% is customer specific upgrade.

    Again if there is a problem identified with Customer A and exists with Customer B it means it falls in the 70% core and is fixed with an upgrade for both at the same time. It is on how we decide which part falls in the core and which goes for customization.

    However the real concern is when it comes to support, problem identification, and making a decision on a resolution as you must also analyze the impact for another customer.

    Very few companies can follow Oracle and SAP style, but healthcare being no less to any industry, it is mandatory that we have customer based workflows than a practice/industry based generalized one.

    When I talk about my company application, we don’t develop a standard EMR and sell it to customers instead we have implemented the core Clinical Operating System. Over which you can have any customization as requested by the practice and physician. Am happy we are one among the so called Rarities in this industry.

  • It’s the issue of agency costs that is always present when buying software. It sounds like the “project manager” here is really someone working for the software vendor, whose job is really to support the sales process. I wonder if the practice needs a CIO or professional IT project manager on their staff to deal with the complexities, rather than relying on the new vendor who is never going to be as much of and expert on your workflows or existing systems.

  • Marc,
    Most clinics could use that. The problem is that most can’t afford to have that type of IT support. Especially small clinics. Even the large ones often have a hard time finding the right CIO or project manager that can balance the IT and the clinical. Not an easy task all around. So, many of them rely on the EMR vendor’s services.

  • Hi All,

    I am in the process of ordering a Server to host e_mds and was wondering if someone could give me an idea of how large your database has grown to?

    For the number of providers, patients, number of years of data would probably be a good metric.

    Thanks in advance,

  • This blog appears to recieve a great deal of visitors. How do you promote it? It gives a nice unique twist on things. I guess having something useful or substantial to say is the most important thing.

  • We are 10-provider 1 location multi-specialty (fam med, urg care, occmed, PT, with in-house lab & xray) using e-MDs for 3 months now on remote server and struggling mightily with technical /connectivity issues (mainly with vitals, EKGs, e-scripts) that are killing our ability to gain trust of our med providers who are having a hard time letting go of paper. How long should it realistically take until providers feel comfortable with new EHR system ?

  • Rick,
    Every situation is a little different, but I think there’s little doubt that 3 months is far too long to be waiting for what sounds like a technical/connectivity issue to still be plaguing you. Sounds like you’re not talking to the right people that can resolve those problems satisfactorily.

    I’d start raising cain online, on Twitter, on, and every other place you can find about your problems. As one doctor once told me, the squeaky wheel gets greased. Plus, EMR companies are so afraid to have negative information out there about them that they are more likely to respond.

    Of course, just make sure all your ducks are in a row before you do this, because you have to be accountable on your end as well. Do remember that there are always two sides to every story. However, far too often in larger EHR companies you can’t find the right people that can cut through the standard answer and get to the real problem.

    Hopefully this is helpful.

Click here to post a comment