Domain 1- System Infrastructure- This domain examines the technology the application is built upon. This includes everything from the operating systems at the user level, the server operating systems, server software for web servers, applications server architecture, database servers, development tools, deployment tools, and any technology required directly or peripherally to the software. The ability for local staff to support and maintain and generally work with the software components is also important as well as the ability to find human resources locally who are familiar with the components. The ability for local staff to work with and support the technology is also an important consideration.
Domain 2- Utilization- This domain examines the breadth of the user base and utilization in the target countries. Some tools are utilized heavily in a low number of settings and other might many countries utilizing the tool but one installation per country. Some tools may only need small number of installations in each country if the tool is used at a central level by the Ministry of Health. Another tool might have dozens of installations in each country.
Domain 3- Country eHealth Strategy
Domain 4- Roadmap- Provides a detail understanding of intent and direction in which the company /tool provider plans to go, serving as a strategic communication tool. Due to evolving technologies and user expectations, determining future needs is challenging. Tool vendors/providers are having to change their approach to developing roadmaps and adopt different procedures for the development and management of product roadmaps.
Domain 5-Technical Support and Multi-Language- The day to day users who interact with the tool will have questions and encounter problems. There are different models to support those users. One convenient method is to have a small number of staff who receive extra training and become "super users". The regular staff should have easy access to these super users to ask questions and resolve issues. This is a convenient model because the super users are typically staff at the same location or nearby, speak the same language and are familiar with the specifics of the installation. Another method for supporting the end users is a help-line they can call which is staffed by the tool provider or other the implementing organization. For this model consideration should be made for the languages spoken, the ease with which someone can be contacted, how easy they are to communicate with and any language issues. Some tools are easier than others to support remotely. Other considerations are the ability to support the tool by remote login or even the availability and ease/cost of on-site visits for troubleshooting more advanced issues. It is also more common to have online forums or knowledgebases that can be searched for information about the tool.
Domain 6- Technical/Developer Documentation- The degree to which a tool can be modified varies greatly. Some tools are completed locked and there are relatively few configurations changes that can be made. Some tools may have their source code locked but have an extremely high degree of reconfigurability on top of the base product including the ability to add new storage tables and user interface changes. Some tools will allow complete access to the underlying source code of the system. The ability to make highly technical changes to the system needs to have some level of documentation. In the case of configurability this documentation is extremely valuable. Where source code is accessible the documentation should focus less on the specifics of the underlying tools and languages and focus more on how to set up the development environment, specific versions of tools and libraries, descriptions of where specific types of changes should be made, and how to create the final product utilizing all those tools. If the software is part of a shared codebase like an Opensource software system, the documentation should also be very specific about how to interact with that shared code repository.
Domain 7- Tools vary greatly in the level of effort required to get the tool installed and integrated into the workflow of the laboratory. Some tools will be able to be installed remotely by the provider or require very little site-specific configuration or training. Some systems may be so critical to the laboratory workflow they required detailed requirements gathering and gap analysis to determine small changes to make sure they conform to the local laboratory's workflow as well as also take time and expertise to make sure all of those requirements are captured. In general, the more dependent the staff are on the tool as part of their workflow you should expect a similar level of configuration and time required for implementation.