This thesis only presents the case of M-health implementation in one local context. It is not given that the findings in that context are transferable to other local contexts within the HISP network. But the answers received during the interviews conducted in Oslo are coinciding with the experiences gained in Uganda. This resemblance can be an indication that it could be similar situations in other contexts. It is also important to keep in mind that finding a recipe on how to enable participatory design in the development and implementation of a HIS is difficult. What succeeded in one context will not necessarily work for other HIS’ in other contexts.
Although the data gathered resulted in useful findings the data collection process has limitations.
10.2.1 Personal limitations
The preparation process before going to Uganda could have been better. If the communication with HISP Uganda had been better, the need for changing focus whilst in the field could have been avoided.
Also, if conducting interviews had been practiced beforehand, the situation where interviewees’ answers did not seem to make sense could be avoided. It took some time realizing the interviewees were afraid to admit they didn’t understand the questions and ask for repetition or answering that they don’t know. After realizing the issue, the interviewees were informed that it was perfectly fine to say they don’t know or ask for repetition of the question. It is possible the interviewees found it hard to admit lack of knowledge due to their culture.
When conducting interviews, a barrier of language was discovered. During one of the interviews, the question asked was about the health workers’ workflow when using the DHIS2 Patient Tracker, but instead of saying Tracker, the word register was used. Later on, when the interview was transcribed it was no doubt that the health worker was referring to the journal, not the Tracker. This is a perfect example of how important it is to be specific when asking questions, there shouldn’t be any room for misunderstanding. The language barrier is also relevant for designers gathering requirements. If they are unable to get a deep understanding of the end users’ needs and requirements the design-reality gap will increase (Heeks 2006).
10.2.2 Limitations within context
Looking at the number of interviews, observations and meetings conduc- ted, the time spent in Uganda probably could be exploited better, but as Hein once wrote: "Things take time” (Hein 1969).
First of all the number of facilities to visit were limited. The DHIS2 software was tested in 10 facilities, in which 5 were in Kampala, the capital of Uganda, and the other 5 in Mpigi, a rural district a one-hour drive from Kampala.
Visiting a facility more than once could have been a possibility to con- duct more interviews, but given the circumstances it wasn’t appropriate. The facilities in Kampala were extremely busy, and holding of health work- ers from taking care of patients to answer a student’s questions felt wrong. Therefore most of the interviews done were conducted in-group with the fellow students.
Another time-consuming factor was that the local project team had to plan the visits and make appointments with the facilities for the interviews to happen. Also when visiting the facilities the local team often helped out with various tasks, as a return of favor for the interviews, thus when visiting a facility the stay usually took a couple of hours.
As the Kampala district was so busy, it was decided to go to the more rural Mpigi district, to visit health facilities there. Going there also was a time-consuming task; first the driver for the day was 2 hours late, and to Mpigi it was a one-hour drive. At the clinic 3 hours were spent before driving back to Kampala. At the facility visited there was only one health worker so conducting one single interview took about 6 hours. Luckily the facility visited only had three visiting patients on that day so there was plenty of time to conduct a proper interview and even demonstrate the mobile clients and letting the health worker test them out. On that particular day, they were also given tablets, so an observation of their use of it was done.
10.2.3 Limitations of the study
To spend one month in Uganda was a bit short when looking at how the process developed. Spending more time in Uganda could maybe have made the implementation of the mobile client easier due to closer cooperation and communication with users, instead of being located in Oslo and coordinate between users in Uganda and developers in Manila. The reason for the short stay was because the original focus was to develop an application to facilitate feedback to health workers. The plan was to follow the five phases of action research and go to Uganda to gather requirements for the application, go back to Norway and develop it and go to Uganda one more time to test it out. After the change of focus, there was not necessary to return to Uganda, so time was spent gathering data from the HISP Oslo team by conducting interviews instead.
In Oslo, it was difficult to arrange interviews. The actors in the HISP Oslo team are very busy and travel a lot; so finding time for an interview was hard. For example, to get an interview with the core development leader failed, even though it was tried to arrange the interview for over a month. By interviewing the core development leader, the results could have been different as he probably has a different view on PD and development of DHIS2 than the implementers interviewed.
10.2.4 Limitations of the suggested model
The model suggested in section 9.5 is a simplification of how to enable PD in the development of generic software. Based on Titlestad et al. (2009) and Roland et al.’s (Forthcoming) theories, and the experiences from the Ugandan project, the suggested model makes some assumptions. It could be that the Ugandan project was a special case and that these assumptions are too strong.