I’m researching what deployments do to handle training new CHWs during on-boarding. Specifically, when a CHW uses a dev CHT instance for training - how do you ensure that the CHW stops using this instance and starts using the production CHT instance? If they don’t switch, they’ll continue using the dev instance and patient data ends up stored on the wrong CHT server.
This question makes some assumptions. Maybe you disagree with them in which case I would love to know why!
It is bad to use a production instance to on-board CHWs as the data will pollute targets for them and their supervisors. Training data is laborious and error prone to delete
Two apps can be installed on the CHW phone - one for dev instance and one for production instance.
When all this research is done, I’ll be looking to publish the collected best practices on our documentation site.
One of the best practice we have used is to have a checklist before the go live date and one of the activity on the checklist is to ensure supervisors and peer CHVs are able to support CHVs to uninstall the training app and install the production app before the go live date.
Last week, @Patrick_K and the LG-UG team shared the following best practices that the team has adopted:
CHVs usually have two apps on the phone. The production app which is used by CHVs to record real data and the training app which is used during the monthly/regular refresher training.
LG-UG CHVs are using tecno phones and the phones have a feature which supports CHVs to freeze the training app immediately after the refresher training and the training app is moved to a folder.
Since the training app is frozen, CHVs will not be able to use the training app in their daily routine activities
The CHVs also move the production app to the home screen and this makes it easily accessible to CHVs. Thanks @Patrick_K and the LG-UG team for sharing this useful information. @kenasiago Do you have any additional insights you would like to share for LG-KE deployment.
@antony - This is great! Thanks so much for gathering up this information and sharing it!
One idea that has come up is to look into adjusting the session timeout for the training app. Given this works offline, the CHV would be logged out of the training app after a short period, say two weeks. When optionally coupled with changing the user password on the training server, the CHV could not log back in.
The end result would be the CHV could only use the production app (or contact their supervisor if they thought they were using the production app).
We are also using two apps, and theoretically look if there’s any traffic on the training server (this has worked well during the big trainings during the district-by-district roll out, but might work less well going forward with refresher and replacement trainings).
Our worst case scenario is that a) the CHV would use production to play around or b) the training server to work with real clients. We would detect a) when there’s data coming into production during the training period (this will be more complicated for replacement trainings, as we would have to filter by CHV instead of by district). We/the CHV/their supervisor would detect b) when the targets are not achieved and P4P not paid. In practice, we haven’t had big issues with the whole set of potential issues.
I’m not sure we would opt for the session timeout/password option, as this would mean added logistics during refresher trainings (or trainings of added/updated components). We also assume that for refresher trainings, “seasoned” CHVs would run less into this issue, if at all, as their task and household lists would be very different on both servers, so for us going forward, we’ll “just” need to monitor the situation for replacement trainings.
@hhornung - thanks so much for sharing your best practices! There’s some really good information here.
In the documentation we’re finalizing for this, we very much call out that some practices may work and others may not, depending on the specifics of your deployment and training frequency etc.