1. Not understanding the 3rd party applications, and clearinghouses. a. Once the ink is dry on your EMR contract, you begin the process of understanding all the other pieces of your application. These are often 3rd party software solutions that are provided by the vendor. However, you soon find out that the vendor wants you to work with these “subcontractors” directly in order to resolve integration issues, development deficiencies and customizations. b. RX and billing clearinghouses as well as 3rd party applications are notorious resource sponges. Be prepared for they added effort and workflow changes required to make these pieces fit into your EMR puzzle. Nothing is “plug and play” even if it is solution included with your contract.2. Not being prepared for all the interface work. a. An EMR is a glorified note book without the interfaces to all your clinical data. Your project success metric should included connectivity to your top Lab, Rad and RX hubs. b. Your vendor may surprise you when they tell you that they require their own propriety interface engine. These are conduits that communicate from the application to your primary interface engine (eGate, Cloverleaf). Now you have a double entry HL7 map that will require internal resources to interface to your own systems. Don’t expect the vendor to provide much help here.3. Not developing the requirements up front-trying to back into MU. a. The way you use the EMR will drive your ability to meet all the requirements of Meaningful Use, PQRI, Medical Home, etc. b. Take a deep dive into what is required by physicians in order to properly attest to meeting all the requirements. The EMR requirements will drive the checklist that will come in handy for auditing purposes.4. Developing too many templates/Not developing enough templates. a. You have to love Physician Champions that are cheerleading the efforts of your EMR project. However, if they do not know when to say “no” then it can easily drive up the build timeline of your project. b. Decide on a baseline for new users and build phases with target dates to add additional templates and functionality. This will help grow user proficiency and reduce the development of templates that may be obsolete once they really know what they are doing. This also helps set expectations.5. Setting the proper project time-line for vendor transition to support. a. Contracts are often structured to receive the first payment at go-live. The problem is that you bring up your first phase or first batch of users and then you’re officially live. You may still have 80-90% of your organization still waiting to come up on the product and your vendor has transitioned you to their support team. b. Working with software install teams is easier when you’re troubleshooting problems. Being able to come up with custom code or workarounds is what developers are used to. The vendor support team on the other hand will tell you that in order to solve your problem; it may have to be addressed with the next release. Sound familiar? c. Make sure you negotiate up front what is “live” and what are “pilots.” Hold on to that development team as long as you can.
6. Spending way too much time mapping workflow. a. The beauty of consultants is that they can take the time to do the things that you often don’t have time to do. Workflow assessment is one of those necessary evils. But you can end up with a consulting team that spends too much time with pretty maps and colors and not enough time doing the Gap analysis. What you really need is the measurement between what is being done today and what will it look like tomorrow. b. Keep an eye on what is the Gap in order to manage the change. Pretty diagrams are great for dog and pony shows, but the clinicians want to know up front how their life will change with the EMR.7. Not preparing the providers for the impact. a. Every provider has to be engaged and the expectations set up front. The Doc that attends all the technology conferences and subscribes to Healthcare Informatics Magazine will have a different set of expectations then the one that does not use a Smartphone. b. Understand that everyone is unique and plan accordingly. Hand holding is acceptable for those that need it. But be prepared to remove the training wheels early, before you create a resource drain.8. Understanding that the infrastructure is all in your court. a. If you are using Citrix and it is working well for most of your applications, don’t expect that Citrix will play well with others. Remember that your EMR includes 3rd party applications and additional bandwidth requirements. b. Depending on your organization, the infrastructure team may be integrated with your I.S. department or subcontracted. Review those SLA’s if you don’t own this piece. Not assigning your server and desktop support as part of the project team will significantly reduce your response time to issues that are bound to arise.9. Underestimating the added effort involved with specialty care. a. Primary care and specialty care are two separate universes. Understanding the nuances of both will help develop the proper timeline to bring them all up on the same platform. It may help to have multiple physician champions from both areas. Just a thought.10. Doing “soft” installations using scanning, and dictation that reduce the capability of “mining” data. a. You can call it a “poor man’s” EMR (I may get flack for this one), but if you have dictation coming back into the EMR in the form of static data (stored document not discreet data) and scanning results as an image; then you have a data repository, not an EMR. b. Give the users what they deserve: A full featured EMR, with CPOE, integrated into your billing system, interfaced with your clinical data, and communicating with your RX clearinghouse. If you’re not doing this for the users, then do it because that is what you would expect as a patient.
