Implementation Best Practices

**Pathway to Successful Lab Information Software Implementation **

What do we mean by “Implementation?”

Implementation has different meaning depending on who you talk to. From the donors perspective, they will be asking if high quality data is flowing from facilities to national and international levels. Managers may be asking if the software is up and running and whether or not people are using it day to day. Ask a developer and they will likely say that software is implemented once it has been packaged and shipped to the deployment team. The deployment team will consider software implemented once it is installed and the Help Desk active. Trainers may consider implementation complete once users are trained on the software and using it in their daily work routine. For the end user, they may say software has been implemented when they have integrated the digital tool into their work and they are using it on a routine basis.

The purpose of this document is to outline the pathway towards successful software implementation. While implementation intersects with software development, the considerations outlined here does not address software development processes and best practices.

All together, implementation consists of several activities that happen consecutively (see Figure 1). Four major elements serve as a strong foundation for successful implementation and lead to integrated and ongoing use of system applications for data management. These are:

  • Leadership engagement
  • Deployment
  • User training and coaching
  • Technical support and ongoing maintenance

In order to have a successful implementation, these elements, described in greater detail below, must be ready to roll out _with _the software. Not only that, implementation goals may influence decisions about how the software is designed and developed. The best time to do implementation planning is early on, when the software or application is being designed.

Leadership Engagement

Leadership support for using digital tools is essential. In Kenya, facilities where leadership was excited and engaged about the EMR tended to have better use than sites where leadership was not on board or absent/not consulted prior to and during initial implementation. When leadership at all levels are engaged and involved in the implementation process, uptake and adoption by users improves.

Leaders and managers clearly benefit from having improved access to quality data. However, successful and sustainable use of digital solutions mean more than supporting staff training or encouraging the use of a tool and its data within the workplace. Keeping patient data private and confidential translates into taking steps to maintain data security, both physically (ie: a dedicated server room) or electronically (i.e.: unique user logins, role-based access). Digital tools require ongoing maintenance and, like all technology, replacement when their performance is no longer optimal or the warranty expires. Taking these components into consideration, preparing and supporting leadership for implementation becomes increasingly important.

Leadership outreach. At the national, regional, and district levels, leaders who are aware of digital solutions being implemented at facilities under their supervision can be important allies. Outreach activities, such as breakfast meetings or other one on one meetings, are opportunities to highlight how the system or application will make decision making, reporting, and data management easier for everyone.

_Orientation. _Orienting leaders to a digital tool is one way to provide them with the information they need to support implementation, assure technical system support when needed, and ultimately, to use the data collected by the tool.

_Letters of agreement. _Letters of agreement or other documentation that lays out the responsibilities of the national MOH (ie: HIS Unit or M&E Department), district teams, facility leadership, service delivery or implementing partners, donors, and I-TECH lead to improved coordination and contribute to longer term efforts to make applications sustainable. These should include not only who is responsible for initially purchasing different types of equipment, but who will replace them if they malfunction or their warranty expires, who will install or deliver the application, how ongoing maintenance will be handled, additional duties that staff will be expected to take on, etc.

_Recognition _


Much of the planning for deployment will depend on the answers to four questions:

  • What is the potential scale of the deployment?
  • What deployment guidelines and procedures are currently available?
  • What hardware is required in order to run the software?
  • What infrastructure needs to be in place?

Depending on the robustness of the application and the availability of local capacity to support training, deployment and ongoing maintenance, it may be advisable to adopt a phased approach to deployment. Starting with a contained roll out provides an opportunity to identify any unanticipated issues and address them prior to rolling out to a larger number of sites or users as well as build up the training and deployment capacity needed.

The answers to these questions can guide your deployment plan. This plan identifies:

  • What steps will be taken to identify sites
  • How site readiness will be determined
  • What hardware and networking specifications will guide procurement and installation
  • Who will receive training by whom
  • When technical support will begin

Readiness assessment. Not all facilities are ready to have a system or application “go live.” Facilities where HIS digital solutions are successful share certain characteristics, aside from engaged leadership.

_Infrastructure and procurement. _ Building from the readiness assessment, plans can be made to address infrastructure weaknesses and procure only the supplies needed for installation. This is another opportunity to work with facility leadership so that they understand the infrastructure requirements (hardware, networking, security, etc) that must be in place for successful implementation, allowing them to take action and show their initial commitment to making the system work in their facility.

Training and Coaching

_User Training and Coaching. _

User manuals and training on data collection tools tend to go from end to end of the application. Most of the time, however, we expect different users to enter or retrieve data from different parts of the application - depending on their responsibilities within the facility. Effective user training begins by defining what the user is expected to do with the tool during their routine work day. If people know how to a) enter data using a number of different formats (radio button, drop down, alphanumeric text fields) and b) know how to navigate the application, then any additional training can focus specifically on how to use the application to collect data pertaining to a specific task.

New Release Orientation. _If user training is done well, then refresher training can be done in a number of different ways – a half/full day meeting and/or one-on-one meetings if the upgrade contains significant additions to functionality or has a significant impact on workflow, a demo or video tour of the changes if the changes are minor (addition of a field or a new report). In both cases, making a well-written, updated job-aid available is important. Different mechanisms for training include: _Release notes, job aids, videos, presentations at meetings, mentorship

Technical Support

The lack of a clear mechanism for getting technical support can sometimes get in the way of uptake: users experience a problem, they try to fix it but can’t, and the next thing you know, they are setting aside the computer or tablet to go back to their old ways. In order to avoid this from the outset, it’s important to make technical support available - and responsive. Most often, technical support rests with the implementing partner or with the national MOH. Their numbers are few and the demand, particularly in the first few weeks following deployment, is great. Three practices can alleviate this potential problem from the start.

During the application or program development phase, projects can take two actions to reduce the demands on technical support:

  1. Design robust features and functionality that address user needs. Sometimes, users complain that a system isn’t working right because they expect it to work differently - and more easily - than it has actually been developed. Taking the time to design user-friendly features will reduce this kind of feedback as well as the need for “just-in-time” support by making the application easier to use.
  2. Test each software release thoroughly before deploying it to users. This reduces the need for on-demand support and developer fixes because application problems are found and addressed before roll out!

Leading up to deployment, three different practices can be put into place in order to increase responsiveness to any issues that do arise:

  1. Adopt a tiered “Help Desk” structure. The size of the deployment and facility will inform how many tiers and technical support staff will be needed. Regardless of the size of the deployment, the structure should include a contact point or champion at the work site or facility. This focal point does not need to be highly technical: they are the user’s immediate access to assistance. As such, they should be able to perform some basic troubleshooting, administrative duties (ie: manage user accounts), and contact more experienced technical support when an issue is more than they can handle. Most user issues occur at lower tiers.

    The next tier of technical support should include specialists who can handle any issues that are escalated from the site. They are familiar with the hardware, network, and system. It’s important to note that these specialists do not need to be programmers. Remember: any issues that require a programmer should dealt with before deployment, during testing. That said, technical support may refer issues that can only be addressed by improving functionality to the development team.

  2. Operationalize the Help Desk by making standard operating procedures for reporting and resolving technical issues available.

  3. Include some basic troubleshooting and Help Desk content into user training. This prepares users for the types of problems they may encounter, gives them some simple solutions to try themselves (check cables, turn the application or device on and then off again), and most importantly - tells them who to contact if the problem persists.

It’s important to recognize that the initial need for technical support will be greater in the beginning: the application or program is new to users and they will have more questions as they learn the ins and outs of the software. As they become more adept, the need for support will decrease. For this reason, scheduling 3-5 days of on-site time for technical support staff to be on hand and weekly technical support calls to new sites is recommended.