Imagine a world where a healthcare organization can purchase an EMR that satisfies all of its patient care and revenue cycle needs. One enterprise-wide solution that meets all organizational goals. Unfortunately, reality today is very different.
No single solution in the EMR market can fulfill all of the diverse needs a healthcare organization may require. Whether they choose to go for one of the big vendors or a smaller counterpart, it is very likely that some specific departmental function may compel an organization to implement a specialty application either in the clinical or revenue cycle realm.
The challenge then becomes deciphering how to integrate these applications into the primary EMR and continue to maintain an efficient clinical workflow for providers and avoid dual entry of data in multiple systems. Integration within disparate systems in not an option, but a requirement. However complex the environment, there are a number of strategies that organizations can adopt to make EMR integration a success:
1. Definition of Integration Scope and Early Vendor Engagement
Clear understanding and definition of scope of integration is key to success. On larger projects, it is easy to lose control of the project’s scope of integration. Set some guardrails at the beginning of the project. Coordinating with the vendor, resourcing and project timelines can be challenging. Ensuring that contracts with vendors include the scope of integration is a crucial, yet frequently missed step. If the scope of integration is not agreed upon at the beginning of the project, major delays in the project may ensue. Getting vendor contracts and statements of work (SOWs) through the legal review process can be very time consuming for all parties involved. The sooner you start working on these contracts and the SOWs, the better.
2. Rigorous Test Plan
Each vendor can describe a testing plan in a very different manner. The key to success is to get each party to have a common understanding for the testing plan, timeline and level of detail. There are a wide variety of terms that are commonly used for testing of different phases (e.g. connectivity testing, unit testing, integration testing, user acceptance testing, stress testing, volume testing, field by field testing, functional testing, mapped record testing, small scale testing, large scale testing). Each engagement can use the terms they prefer; however, they need to be clearly identified and defined for an integration project.
o What resources will participate during testing?
o How much time needs to be allocated for testing?
o When will testing be conducted?
Answering these questions will improve your chances for success.
3. Documentation and Review of Business, Functional and Technical Specifications
Understanding what the integration project goal is from a business perspective is absolutely critical. Any experienced integration resource can easily list the HL7 messages or events and triggers, but understanding the business process or clinical workflow that comes into play during integration design is a requirement. Both technical teams and key operational stakeholders should understand how the integration will function. This needs to be documented, reviewed and approved by the stakeholders. When clinical and business stakeholders are not engaged, technical teams often end up delivering a solution that is unsatisfactory to the stakeholders, potentially leading to disappointment at go-live.
4. Dedicated Application Resource for EMR Integration
Application build is an important aspect of integration that sometimes gets overlooked. If the application build is not vetted properly, the integration will not work. Remember it is the integration team that does all the “plumbing” work to build the pipes between the two systems, but the water that flows – in this case the data- is all built by application resources. If the data specifications are not in sync, the two systems will not integrate properly and the end result will be unsatisfactory and potentially detrimental to patient care. This is a shared responsibility between the application team and the integration team.
5. Post Go-Live Support Model
The goal of an integration project is always to deliver on the pre-approved specifications. However, in reality, stakeholders might change their mind on the design or some things get miscommunicated or untested as the implementation project moves forward over time. These kinds of issues typically show up post go-live once users truly work with the newly implemented system. In conjunction with frequent, intermittent reviews of the integration solution, the team should always have an effective plan in place to support issues or challenges that might arise post go-live to close the loop on any discrepancies.
Integration plays an integral role in most implementations, and when done properly, becomes one of those elements that goes unnoticed because it “just works”. If proper focus is not applied in this area, users will be left dissatisfied and likely cast a negative light across the entire implementation. The strategies discussed above summarize some of the most important techniques that can help the smooth integration of third party applications to the EMR when introduced early in an implementation.