Stakeholders in an Integration Project
Integration projects are often the bane of many clinicians and practice managers/administrators. Often there are concerns that Information Technology staff or contractors essentially hijack the project and control both its goals and implementations despite the fact that most integration projects – especially those relevant to clinicians and staff – are original envisioned by non-IT users. There are even some administrators that prefer to let IT staff dictate such projects as it removes the need for difficult decision making and some honestly believe that IT is best equipped to make decisions regarding the project. As with most projects, however, this is not necessarily the case. If one were to need a decision about specific technical items within the project – e.g., what connection mechanism (such as through secure file transfer or via a secure web service or API) – than it is likely that the best decisions are made within IT. If, however, there are needs elsewhere, it is likely that the best answer for the organization is to keep a multi-stakeholder team on standby to provider overall direction for the integration project and to advise on specific issues.
It is important to remember that integration projects are not IT projects; rather they are automation projects that are designed to increase productivity. Their means, however, is through information technology. Allowing IT to control the fate of an integration project would be akin to a large retailer allowing trucking firms to dictate which products it carried in stores. IT is a means to achieving a specific administrative end.
To that end it is important for organizations undertaking integration projects to determine who the stakeholders are. If, for example, one is undertaking a project to EMR data amongst two different organizations – such a project may be initiated because a clinic is now affiliated with a specific clinical network and data is needed to more efficiently effect transitions of care, to provide benchmarking for population health management, and to provide adequate data for payer reporting.
In such cases, those leading the project ought to strongly consider involving clinical personnel in order to establish trust in the data being transferred and measured (from the point of being sent from the originating system to being received, processed, and calculated by the destination system) as it is clinicians who are likely being measured as a result of such integrations and their support is paramount to success; administrative/quality assurance personnel to ensure that data is being sent and processed at the correct intervals, that the data is sufficient for the administrative and data purposes envisioned, and the project’s work fits within the respective organization’s overall strategic goals; IT personnel ought to be involved so that the work of the project can fit into overall IT planning and to ensure that proper maintenance and possible scalability concerns are addressed prior to a project going live; finally, to the extent possible, one ought include the ultimate customer in the project – or at least check-in with the customer frequently. Their support and buy-in is important as the project was originally envisioned to meet a requirement they were placing on the organizations (this is true even if the customer is internal).
At its simplest level, the clearest way to determine who ought to be included as a stakeholder is to diagram the processes involved and also to determine the processes both prior to, during, and after the integration that are impacted by the integration itself. In essence, figuring out dynamically the individuals and work processes impacted by the integration project and to keep them involved as stakeholders from the origination of the project will greatly assist – but certainly not guarantee – more buy-in from end users, better ensure project success, and provide different perspectives on the project and its impacts. This latter point is especially important as it may allow one specific project to be leveraged for multiple users and to, in effect, compound the benefits from the project. The interface project described above, for example, may also be partially used to connect the clinic to a health information exchange – as data is already being extracted in a given format – and leveraging part of the integration for another end can more save time and money later (in this case, if one were to send data to the clinical network in a CCD format, that same CCD may be sent to a health information exchange especially if there is an integration or interface engine involved in the original data integration project. This would save the practice from having to both wait on and to purchase, from the EMR vendor, another CCD interface).
Data integration projects are often going to be headaches for organizations – they can be overly complex, the technology is not as efficient and readily accessible as it ought to be (especially when compared to other industries), and there will be competing demands for resources and interests within an organization. That said, risk mitigation is possible through the simple exercise of mapping out who will be impacted and what processes will be impacted – both directly and indirectly – and including such individuals in the decision-making process for the project. For the IT teams at organizations, while it may seem to be a step back from directly leading projects, more successful projects, through the involvement and input from multiple stakeholder groups, will build more trust in the IT staff’s ability to complete projects and to deliver on customer requirements while, at the same time, taking some of the decision-making load of IT’s back. Despite some additional upfront work, such a multi-stakeholder model for integration projects is apt to deliver strong divedends to organizations of all sizes.