Software Issues

Successfully deploying an EHR (and CPM systems for that matter) is not an install it and forget it affair. When you get in bed with an EHR, you have committed to a long-term relationship. Therefore, be sure you evaluate and are comfortable with the support team of the EHR vendor you select. Vendors that are too small can be a problem, as can vendors that are too large. In both cases (for different reasons), software support may be a disappointment. Actual survey content is available to Registered Users Only.

COMPATABILITY ISSUES

When you install an EHR, unless you are deploying a web-based solution, there will be other software on the host computer. This creates the potential for interactions that can be dangerous or that put sensitive patient information at risk. For in practice deployments there are generally two cases. The first is "thick" client server, where the application runs on individual workstations and the patient files are stored on a centralized server or repository. This provides the greatest exposure as each workstation has potential for conflicts with all the other software running on it. Even if the workstation runs the application alone, there is the OS and all of its constant security patches to contend with. Sometimes security patches can break applications, something that Microsoft does NOT test for against the hundreds of medical EHR products out there. Given that Windows is usually set to download and install such patches, the problem can manifest itself suddenly and unexpectedly.

In addition to the Microsoft or other OS itself, the computers will have anti virus programs, anti-spyware programs and the network at least will have a firewall to contend with. Each of these is a source for interaction with the EHR applications. Should the EHR program's email or remote communications with labs, pharmacies, web decision support or other open Internet applications, the potential of other problems increases. Particularly on Windows-based systems, various media players have been hacked to do ugly things on computers that run them.

Very few EHR vendors filled out that section of the survey, which suggests that either they haven't tested such interactions (or they tested them and were uncomfortable reporting the results). It also suggests that in the area of total system configuration, group practices are "on their own" in doing such compatibility testing. They are also on their own in the area of EHR and other "patch" deployment, which in the case of "thick" client-server configurations is across the entire network. By the way, our Industry Alert™  newsletter carries periodic articles on software applications useful in medical environments. If you want to track this topic, consider a subscription.

WINDOWS - NOT COMPATABLE WITH OTHER MICROSOFT PRODUCTS

We have found that potential for trouble exists in Microsoft's own applications, such as their popular Office Suite, when the version of the Windows is NEWER than the version of the application (in this case Office) that runs on it. Apparently, when newer versions of the operating system are released, the application groups inside of Microsoft do not go back and test or patch older versions of the application suites to be fully compatible with the new version of the OS. What is happening appears to be that calls made by the existing apps are handled differently by the new version of the OS, which can cause Microsoft's own applications that worked on a previous version of the OS, to suddenly fail (with Visual Basic and other errors) when run on the later version of the OS. This is particularly true for inter-application communications, when Excel is called by Access, or when web-based components (not always installed in basic configurations) are invoked. Microsoft only reluctantly acknowledges such issues and does very little to assist developers in fixing them.

Given that Microsoft can't get its own products to work with newer versions of its OS 100% of the time, users of EHR applications need to be very cautious about migrating existing working applications forward onto "later" version of the OS. They need to depend upon the EHR vendors to do the testing that Microsoft fails to do, and to inform them when it is "safe" to upgrade the OS to a new version or even to a new service pack of an existing version. This implies that a group practice should plan to have regular communications with the EHR vendor for the life of the system deployment. It therefore behooves the practice management team to assess and understand the support costs and methods that are available to the practice in keeping their systems current to fixes for discovered security holes and at the same time, fully functional and unbroken by these various patches.

THIN CLIENT-SERVER ALTERNATIVES

One of the major advantages of Thin-Client deployments, apart from the obvious cost savings, is that the interactions between the EHR applications and the other software installed on the "host" server is reduced to ONE computer. This however is a double-edged sword. If you get it right, all is well in the universe. If you get it wrong, everything is in chaos - all at once and your entire practice can come to a grinding halt - which elevates the stress level of everyone at the same time. If a practice decides on a "thin" client (Windows Terminal Server or Citrix) deployment, we suggest using a "blade" hardware arrangement and configuring two servers - one hot server and a second backup that can become a hot server. Keeping parallel server software versions is recommended as well. Updates are asserted to one of the two and the second is left in the non-updated, unpatched state - thus becoming a failsafe, fallback configuration that was known to work (before the updating or patching was applied). This is in addition to Windows own roll-back mechanisms, which don't always work (as not all applications do a good job of extricating themselves from the registry when they are uninstalled, or crash during decommissioning). Absolutely make frequent registry snapshots, or employ utility programs that do this for you. Don't depend on the Windows start-up and shut-down registry updating as your only alternatives.

ACCESS ADDITIONAL "REGISTERED" CONTENT

Software compatibility is a broad topic. For more information on this topic, Register now and explore our tutorials and the courses available to you to help you get up the learning curve of this new tool you are considering deploying.