Making automated messages sent from RapidPro to CHT visible on the message tab

[Evelyn_Waweru]

Your Organization: Medic/University of Washington – CHV-NEO
Organization Type: Technical

What Other Organizations Would Benefit From This Feature: interventions with an interactive messaging component

Describe the Feature: CHV-NEO is an app that integrates the CHT (eCHIS) with RapidPro to provide direct to client communication between community Health volunteers (CHVs) and their clients (specifically peri-partum women). Part of this intervention includes sending automated messages to clients, and clients sending back unstructured conversational responses, which CHVs respond to manually. We would like the automated messages sent from RapidPro to clients to also appear in the Messages tab. We want them to appear as being sent from the community health volunteer (CHV) to the client. This so that the CHV is able to make sense out of the messaging history and respond to their clients appropriately and on time.

What “Pain Point” Does The Proposed Feature Address: Currently on CHT, only manual interactive messages between the CHV and the client are visible on the message tab chat thread. Clients are also receiving daily/weekly automated messages – visit reminders and educational messages – most of which end with a question, but these are not visible in the messages tab. When clients send messages in response to automated messages, the client messages’ meaning cannot be easily understood without the automated message as context. We would like CHVs to be able to see the automated messages so they can follow the conversation, but have automated messages appear as read so that CHVs can prioritize interactive messages from the client that need a prompt response. This feature is essential for launch of the CHV-NEO program June 1.

Proposed Solution:

We explored the following ways of doing this through RapidPro webhooks:

• POSTing to /api/sms and specifying “from” and “to” properties in the payload. This did not seem to work.
• Creating an sms_message data record for the contact directly in CouchDB. This worked. However, we noted that since these automated messages will show up as new messages for the CHV, it would create spam and make it difficult to discern these automated messages from actual client interactions.
• Directly write the message to the database (should not trigger unread message notification)

Where we need help:

• Alternatives to achieving this that may be easier and less complicated
• How to mark the sms_message data record as already read so that we avoid spamming the CHV. This in the case that there are no better ways of achieving what we need.

Do you have funding to cover external developers? Yes with technical support from the product team
Do You Have Resources (Designers, Developers, PMs) Available: we have a designer, PM and developer
Links To Supporting Information / Uploads:
Forum post is here Working with messages between RapidPro and CHT contacts using code additional information on MobileWACh is in the description below

The messaging strategy used in CHV-NEO is adapted from a previous intervention named Mobile WACh (Publications can be found here,. In this strategy, clients receive automated messages grounded in behavioural theory and covering a range of health education topics. Automated messages end with a question to promote engagement and behaviour change. Clients are encouraged to respond to messages with unstructured messages, which CHVs then respond to in an ongoing conversation. Note that unlike previous 2-way texting projects using the CHT, in our messaging strategy we are not expecting structured responses (e.g. 1/0) and we are not asking the same question in every message (e.g. do you need help). In our previous implementations of Mobile WACh across 7 studies in Kenya we have seen that clients message conversationally, including responses that cannot be understood without reading the prior system message (e.g., “Yes”, “No”, “A little”). It is therefore necessary for CHVs to be able to read the automated messages when reading client messages. It is also necessary for the messaging tab of CHT to only indicate unread messages when there are unread client messages for the CHV to respond to (not automated messages that do not need the CHV’s attention). See the screenshots below for examples of the types of messages clients send and how the desired functionality was facilitated in a different messaging system.

[image]

[Keshet]

Here are the screenshots that illustrate how the desired functionality was achieved in another platform. And another reference describing the messaging strategy here

[michael]

@Evelyn_Waweru

POSTing to /api/sms and specifying “from” and “to” properties in the payload. This did not seem to work.

Did you try the solution mentioned here?

@Evelyn_Waweru

Creating an sms_message data record for the contact directly in CouchDB. This worked. However, we noted that since these automated messages will show up as new messages for the CHV, it would create spam and make it difficult to discern these automated messages from actual client interactions.

Do you mean that it showed up as a completely different message on the left hand side (instead of in the thread on the right hand side)?

@Evelyn_Waweru

Directly write the message to the database (should not trigger unread message notification)

Did this work and was just not desirable?

@Evelyn_Waweru

How to mark the sms_message data record as already read so that we avoid spamming the CHV. This in the case that there are no better ways of achieving what we need.

There are documents in the medic-user-xxxx-meta database that keep track of which records are “read”. Would it be possible to create those as well?

[danielmwakanema]

@michael

Did you try the solution mentioned here ?

We did but this does not meet our need. We are trying to record automated messages sent out in RapidPro back into the app. We want to record these automated messages as being sent from the CHV. Whereas this solution only allows us to record messages sent from clients.

@michael

Do you mean that it showed up as a completely different message on the left hand side (instead of in the thread on the right hand side)?

It showed up in the thread on the right hand side.

@michael

Did this work and was just not desirable?

It worked but the challenge we are facing is that creating the record directly in the app database creates a new message notification. We send out a lot of automated messages so this will make it difficult for the CHV to differentiate between real client interactions and automated messages.

@michael

There are documents in the medic-user-xxxx-meta database that keep track of which records are “read”. Would it be possible to create those as well?

Possibly, how do we go about that?

[michael]

@danielmwakanema

Possibly, how do we go about that?

Here’s a quick video showing how the read:message:<guid> docs work.

[danielmwakanema]

Thanks @michael. This is helpful. Lemme give it a try.

[michael]

@danielmwakanema not sure if this will be any easier for you, but here are some examples of approaches that should work as well.

[danielmwakanema]

@michael, this option is good and is relatively easy to implement. Was initially just going to create the doc from RapidPro using webhooks. Was concerned about the number of requests that’d create. Say 500 automated messages likely result in 1000 requests from RapidPro. One to create, one to mark as read. This allays those concerns somewhat. Will consider it.