Why EMR Integration Projects Increase Heartburns 🙂
Anyone that has spent any significant time working on or around EMR integration projects is fully aware of what appears to be a lackadaisical attitude towards deadlines and common complaints around the seeming inability to repeat a project if it must be duplicated among difference instances of an EMR. Even those within Information Technology complain about and are aware of these issues. Unfortunately, it seems as if such problems are inherent in the EMR business model and not simply a function of one working with an incompetent vendor or IT department (if that were the case, there would be sufficient instances of projects being completed promptly and replicated easily; however, these complaints are common enough to become a Healthcare IT truism). There are three main reasons why EMR integration projects are exceedingly frustrating: the EMR business model, the lack of a comprehensive data exchange format, and client-side skill shortages/gaps.
The EMR Business Model
One item that needs to be remembered is that in most cases, when it comes to integration projects, EMR vendors make money off of both the per instance sale of an interface and the monthly maintenance per specific interface instance (this is not always the case, but it is an overwhelming norm in the industry). This creates a situation where EMR vendors are incentivized to create a model for integrations that involves spinning off multiple projects instead of one larger more cohesive project (in the case where multiple instances of the same EMR are integrating with a given endpoint such as HIE or population health management system). In this case then, the seemingly similar projects become extremely disjointed, different technicians and project managers get assigned, and prioritization is driven by internal vendor needs. Subsequently both the customers’ goals and pocketbook suffer. Money that could be allocated to more efficiently delivering care is spent on additional interfaces and maintenance. Despite the progress on EMR APIs, some of them still have a similar pricing model and many of them do not allow compete access to the EMR’s data storage; therefore, requiring the involvement of the EMR vendor.
The Dearth of a Comprehensive Standard
Although there are document standards for EMR integrations – notably HL7 2.X and CCDs – often the data available through such standards is not sufficient. The simplest example to illustrate would be with CCDs. Such documents were designed for transfer between care settings – e.g., sending an importable document from a PCP to a specialist upon referral and then sending a document to close the care loop. That said, increasingly, both EMR vendors and analytics system vendors are trying to rely on such documents for quality reporting and benchmarking. From a clinical practice perspective, however, such documents are wholly insufficient because they do not readily track many of the measures that physicians are compensated and measure on – e.g., it is difficult to include measures that are not diagnosis, lab, or procedure code driven in a CCD. A good example is communicating with a third-party system that a diabetic patient both has had a retinal eye exam, the results were negative, and, therefore, another exam is not needed for two years. Such results are often recorded with structured text that does not get sent on a CCDA; moreover, QRDA files – another standard – are not readily available in a critical mass of EMRs on an automated basis and not all EMR vendors report through QRDA files on all of the available quality measures. The result of such deficiencies is a continued reliance on flat files and other non-standard interfaces. These must often be built manually by EMR vendors and configured per instance as each practice may chart an item in a specific manner. The greatly increases the cost and time involved – especially if there are multiple developers involved on the EMR side as each develop must achieve competence with the specifications and a knowledge of the how a given practice charts.
The client, however, is not free from some blame for issues with EMR integrations. It is often the case that at a small or mid-size clinic (or even at small rural hospitals), there is an internal skillset gap in managing projects, keeping IT teams on staff, and developing comprehensive QA plans to ensure project success. This, of course, makes sense economically for many practices. If one owns a single provider practice, having IT staff on payroll is likely not cost-effective; however, not making such investments also has trade-offs. It is important to remember that vendors must be managed. The client must put forth the effort to keep them accountable, require their approval before closing out a project, and escalating as much as possible to ensure that work is completed with the necessary attention to detail. If one is quietly carrying their Health IT cross, the EMR vendor’s leadership will assume that nothing is wrong and is apt to not invest additional resources in managing a compliant customer; one must be willing make oneself heard as loud as necessary to move projects forward. In the worst-case scenario, a practice must be willing to migrate EMRs if they are not being treated well by their existing vendor. If their existing vendor is taking too long of integration projects, not completing them sufficiently, and charging for low-quality work, it is imperative that a practice gird themselves and switch vendors; generally, people get what they are willing to put up with. For the price a practice is paying for their EMR, they should expect conceriege service, not self-checkout.