The Physician’s Guide to Electronic Medical Records Software

A challenge awaits the physician who has had enough of the frustrating inefficiencies, financial penalties, and antiquated practices associated with maintaining a paper-based medical office. So the decision is made to digitize the practice. Any initial enthusiasm quickly wanes once an initial search for medical software uncovers hundreds of products and vendors. It doesn’t take long before the 300 or so electronic medical records system screenshots and feature/benefit grids begin to look remarkably similar. The sheer number of vendors occupying the EMR (electronic medical records) market is unmanageable without a basic product assessment/elimination strategy.

For physician practices with limited time and resources, the selection process can appear overwhelming. Fortunately, physicians can begin to narrow down potential systems by eliminating uncertified products, as well as those built upon dated technology architectures.

  • Eliminate products not certified by the CCHIT® (Certification Commission for Healthcare Information Technology).
  • By confining research only to CCHIT-certified EHR (electronic health record) products, a substantial number of systems are quickly eliminated. As of this writing, 53 ambulatory EHR systems have successfully met the 2007 standards, while only 18 have met the more rigorous 2008 criteria. Using CCHIT certification as an initial benchmark is prudent for a variety of reasons: The CCHIT is the leading Healthcare I.T. certification organization, and is publicly endorsed by the American Academy of Family Physicians; the American Academy of Pediatrics; the American College of Cardiology; and the American Medical Association, among others. In addition, a CCHIT Certified designation ensures that a product has met the basic requirements for functionality; interoperability; and security and privacy.

    A 2008 CCHIT certification warrants the product’s utilization of standard formats enabling the exchange information with other systems – known as interoperability. The exchange of patient information on a regional or national level is the underpinning of a more efficient and less costly healthcare system. Future tax incentives and Medicare reimbursements may be tied not only to utilization of digital medical records in general – but specifically benefiting practices with CCHIT-certified EHR systems.

  • Eliminate products that do not operate on a shared database for billing and patient charting.
  • As little as five years ago, “interfaced” practice management/billing and patient charting systems were the norm. Today, “interfaced” systems are technologically inferior to medical software that has been developed from the ground up by a single vendor, on a single platform, and utilizing a single database – described as ‘integrated’ or ‘unified’ electronic medical records and practice management systems.

    Interfaced systems are still sold today, so it is a “buyers beware” market. In the past several years, there have been a number of mergers and acquisitions between vendors having market share in one side or the other (scheduling and billing or charting/EMR) but desired a comprehensive solution to offer physicians. As a result, there are products currently marketed as a “suite,” but were developed by disparate vendors on different platforms, tied together using a separate application. Although generally transparent to the practice, there may be questions of data integrity; patient safety (for example, a patient’s practice management/billing record does not match the clinical record and lab results get overlooked in the mess); and even the vendor’s long-term maintenance of the system.

    Unfortunately, uncovering if a system is integrated or interfaced is not always straightforward and may require the buyer to conduct some detective work. The first step is to ask the vendor questions about the product’s history – which company developed it, does it utilize a common database, and is there a single login for billing and charting? Some interfaced systems require users to log in separately to access the practice management/billing and the clinical portions of the software.

    Following the elimination of uncertified products with dated technology, the pool of suitable products begins to shrink and the specific needs of the practice should be defined and considered.

  • Establish a Budget. Medical software systems vary widely in cost. By establishing a flexible budget early in the process, practices can avoid wasted time looking at systems that are too expensive or potentially not robust enough to meet the needs of the practice. Ask questions about ongoing maintenance costs and what the maintenance covers, just as a buyer would ask when making decision to purchase a car.
  • Specialty-Specific Content. Not all EMRs accommodate all specialties – regardless of what the sales rep claims. For example, some leading vendors have well-developed content for family practice; ob/gyn; internal medicine; and ear, nose, and throat; but may not fare as well in specialties such as oncology or chiropractic. By asking the vendor to demonstrate the product’s performance in a specific specialty, the number of potential candidates will decrease.
  • Scalability. Just as not all electronic medical records systems accommodate all specialties, most are geared toward a specific practice size – with features and cost typically reflecting the product’s expansion capacity. In general, if the practice expects to add providers or additional locations over time, it is important to start with a product that is stable and feature-rich enough to handle the workflow of a larger practice – even if the product’s features may not be fully leveraged early in the product’s lifecycle.
  • Finally, it is time to ask questions about the vendor’s service and support – the most ambiguous, but arguably most important aspect in the decision making process. After all, you can purchase an electronic medical records software system with every bell and whistle, but if the implementation is disorganized; the training inadequate; or the post-installation support lacking – productivity will drop; providers and staff will be frustrated; cash flow may be interrupted, or worse.

  • Take stock of in-house I.T. (information technology) resources.
  • Does the practice have a staff I.T. department or a trusted medical office I.T. company? If not, it’s important to ensure that the software vendor offers I.T. services. Improperly installed hardware or inaccessible support personnel can have a detrimental effect on the success of the training and implementation.

    Some smaller practices opt for a web-based installation to decrease the cost of hardware and eliminate the need to maintain servers and other equipment. Web-based installations are known as SaaS (Software as a Service) and are delivered by an ASP (Application Service Provider). The electronic medical record ASP hosts the software in a secured data center, and the end-user (the practice) simply accesses the system using a web browser. All that is required is a high-speed internet connection and a workstation. Access to the data is dependent upon the internet connection, so mission-critical applications are not appropriate in a SaaS environment under most circumstances.

    The alternative to a web-based installation is Client/Server, requiring an onsite server and regular maintenance of the system by the vendor. Both types of installations have advantages and disadvantages, so it is important to discuss installation with potential vendors.

  • Assess technological skills of clinicians and administrative staff. Ensure the vendor’s project planning and implementation staff can aid the practice in choosing who the functional area “champions” will be.
  • Training, EMR implementation, and “go-live” support expenditures account for a substantial portion of the total initial system cost, and careful planning is essential for a smooth implementation. The vendor should provide a project coordinator that will help the practice make critical decisions and schedule the project timeline. Most practices utilize a combination of web-based and on-site training prior to go-live (the days or weeks dedicated to using the new system). In addition, the vendor should provide onsite support for the practice during the go-live. The number of training days, go-live days, and the delivery (web-based or onsite) is determined by the size of the practice and the skill levels of the staff. Follow-up sessions to reinforce original training or introduce advanced concepts is important for continuity.

    To keep costs down, some practices may utilize a heavier web-based training plan for the bulk of the staff with designated superusers who attend advanced training. For practices with less technologically savvy staff, more handholding through onsite training may be the best option. In addition to improperly installed I.T. (hardware, networking, security, workstations), insufficient training or post-implementation technical support are prominent failure points in medical software implementations.

  • Who supports the practice following the go-live? The original training and implementation staff, or a separate call center?
  • Not only does unresponsive medical software technical support frustrate and discourage users, it fosters lost productivity when users struggle with denied claims; unanswered questions; or broken functionality. Still, large vendors often outsource support to overseas call centers – lowering vendor overhead at the expense of high-quality, timely, and knowledgeable support.

    By asking relevant questions, evaluating the needs and culture of the practice, and systematically eliminating unsuitable products and vendors – practices can enjoy the host of current and future financial and patient safety benefits that an electronic health records system provides.

Andrea Schroeder




Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>