It is a truism in Healthcare Information Technology that EMR integration projects take excessive periods of time and tend to frustrate customers. Even for a single provider practices seeking to implement a fairly standard interface – e.g., an admission, discharge, and transfer interface from the EMR to a specified endpoint such as a medical device – there are multiple individuals involved whose must be able to communicate well and complete their respective roles in a timely manner for the project to be completed both competently and in a timely manner. A typical project involves customers (sometimes both on the sending or receiving end, other projects have the same customer as both the sender and receiver), at least one project manager, EMR experts, integration experts/engineers, and, in some cases, network infrastructure resources. Understanding the flow of a typical integration project and each’s role can help clinic and hospital administrators better avoid some of the common pitfalls that are encountered.

Project Flow

            After the need for an integration project is determined – and the need is often driven by the implementation of new technology or to implement a component of an organization’s overall strategy (such as being part of an accountable care organization and thus fulfilling the requirement to send data to the ACO) – the organization’s overall sponsor or project owner begins to engage with IT resources. The project owner/sponsor for many integration projects could be someone such as a practice manager, physician, or a department head in a health system. The IT resources and owner typically determine the type of interface needed, produce an estimate of the work involved, and get the project put into the appropriate prioritization queue. If an EMR vendor needs to be involved, they are typically engaging in the same process on their end. Ideally, as the project’s work begins, test plans and success metrics will either have already been developed or – at a minimum – be in progress. After the work is initially completed, testing will commence. Testing is designed to determine that the appropriate data is sent, that there are no unintended consequences (performance issues are an example), and that the desired reliability is achieved. Once the customer is comfortable with the testing and IT can be relatively confident that the integration can safely be moved to production, a project go-live occurs. Any issues that occur during the go-live are remediated, and the project is closed shortly thereafter. Note, this is a very high-level description of such a project, one ought to consult relevant project management resources for additional detail. Understanding – even at a ten-thousand-foot level – can, however, help one to avoid some of the traps can ensnare many integration projects.

            It is critical that the project sponsor and the IT lead whether it be the integration engineer, EMR analyst, or a business analyst are extremely clear about the requirements of the customer. The requirements gathering process can seem tedious; nevertheless, its importance cannot be overstated. The customer must also work with experts from both the sending and receiving system to determine – from a workflow perspective – how to handle exceptions and errors to ensure proper system functionality. Also, the project owner will need to engage with personnel impacted by the project to ensure that adequate information has been provided to encourage project acceptance by staff. If the integration engineer, is not involved from the beginning of the project, it is imperative to ensure that the engineer understands fully the business and functional requirements of the project so that be sure that the actual interface is implemented properly.

            In many projects, communication that either didn’t occur or that individuals thought was implied is often the cause of project issues. This is especially the case around two areas: clearly describing the requirements of the project (and ensuring that all team members understand it) and explaining to the client – who may not be technically savvy – the areas where errors and information communication breakdowns can occur. The latter issue – if understood fully – will help the customer plan workflow redesign around both the intended and primary behavior but to also prepare contingencies for what need to happen in case errors occur. The former issue can create a situation where the wrong functionality or not enough functionality is implemented because the integration analyst is unaware of the project’s goals and requirements. This can subsequently lead to dissatisfied customers and a deficient end product.

            While integration projects are fraught – like any other IT project – with challenges and communications and preparatory risks, proper planning and an eye for accurate and clear communication can mitigate many of the risks.


0 Comments

Leave a Reply

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