Two message threads for the same patient

[cliff]

Helo community

We recently started experiencing a scenario where the messages for a patient are split into two threads in CHT ie the ones sent in a different thread plus the ones received as seen below

as seen above when i text the patient using rapidpro with Hello joel,Merry Xmas n happy new year , He responds back with Great but in different thread . This is also happening when a flow is triggered in textit ie the responses in the flow are in a different thread from what the patient responded back with

[marc]

Hi @cliff, without looking at the actual messages, my guess is that for some reason the phone numbers don’t fully match. I think I’ve seen this happen in the past when the international number is used in one place, and the local number is used elsewhere, but they don’t get consolidated into the same number. Have you set the default country code in the settings for CHT and RapidPro?

If you are still experiencing the problem after setting the country codes, can you confirm that two numbers? Is the ******** the name for the phone number, or did you cover up the phone number manually for privacy reasons? If reposting the numbers here don’t forget to exclude at least the last 4 digits to not post the number publicly. On that note, is the number in the right pane of the screenshot a real number? If so, please edit the post with the number removed.

[marc]

Actually, I went ahead and redacted the phone number directly to avoid keeping the potentially real number up.

[cliff]

@marc

Have you set the default country code in the settings for CHT and RapidPro?

hello @marc i did set the country code in CHT but there is default way to set the the country code in textit

@marc

can you confirm that two numbers?

Am not getting you exactly here

@marc

Is the ******** the name for the phone number, or did you cover up the phone number manually for privacy reasons?

yes @marc , this is the number ,the reason why it is showing ******* instead of the autally phone number is because we did anonymize contact numbers in textit . Could this be the reaseon why CHT is failing to harmonize the anonymous number and the actual contact number in CHT hence creating separate threads for them in the messages tab

[marc]

Ah, thanks for clarifying. Since RapidPro is sending the message to your CHT app with ******** in the phone number, the CHT won’t be able to match it to the contact’s actual phone number, and will show the responses in a separate thread.

Based on this setup, it seems like responses from all phone numbers would show in that ****** thread. Is that what you are seeing?

[cliff]

@marc

Based on this setup, it seems like responses from all phone numbers would show in that ****** thread. Is that what you are seeing?

yes @marc thats what i’m seeing.
the reason for this is that we had earlier on requested the textit team to make contact numbers for our work space anonymous hence the system generating some random digits to cover the actual contact number in CHT , so when CHT receives this number as the contact number upon posting to it ,it doesn’t know how match it to the actual number initially captured while registering the patient hence using ********* in a separate thread. The tricky part is that the textit team said they can’t reverse this contact number anonymizing process once its done on a particular workspace…

[cliff]

@marc By the way what’s the unique way of identifying contacts in CHT ?

[marc]

That sounds tricky! If you can’t know the contact’s real number within the TextIt Flow,
then unfortunately you can’t rely on phone number for matching for the threads.

By the way what’s the unique way of identifying contacts in CHT ?

All contacts in the CHT, whether they are a person or a place, have a universally unique identifier (UUID) that is used as the primary way to identify them in the app, and in the database. You’ll see this UUID as 32 hex characters, such as 1234567890abcdef1234567890abcdef

Additionally, if you have the generate_shortcode_on_contacts transition enabled, the CHT generates short identifiers for new people and places. This shorter ID is unique within each CHT instance, and can be useful when reporting about a person or place using SMS forms.

This means that if you add the CHT UUID or short ID to each contact in TextIt you might be able to report about them without knowing their phone number, but it won’t help with merging message threads. It would also defeat the anonymization that you’re hoping to have.

If anonymization within TextIt isn’t actually necessary, you may find it easier to reset and rebuild your workspace there. I hope you find a way around this!

[cliff]

@marc

All contacts in the CHT, whether they are a person or a place, have a universally unique identifier (UUID) that is used as the primary way to identify them in the app, and in the database. You’ll see this UUID as 32 hex characters, such as 1234567890abcdef1234567890abcdef

Additionally, if you have the generate_shortcode_on_contacts transition enabled, the CHT generates short identifiers for new people and places. This shorter ID is unique within each CHT instance, and can be useful when reporting about a person or place using SMS forms.

thanks @marc

@marc

If anonymization within TextIt isn’t actually necessary, you may find it easier to reset and rebuild your workspace there. I hope you find a way around this!

Will talk to the team about this option

[Beth]

@marc - thanks for the reply! I’m wondering if CHT could use UUID instead of a phone number to match contacts between RapidPro & CHT? In my (non-programmer) mind, this swap would merge messages into one thread?

[marc]

Hi @Beth, that would be a change to CHT Core, which could be time consuming and complicated, but your suggestion gives me another idea!

How would you put the UUID for each person in RapidPro? I imagine that would be by adding a custom field to each contact. If you can do that for each user, then presumably you could add their phone number instead, and use it from the RapidPro Flow so that the numbers would match in the CHT.

Create the custom field

1. Add a custom field by going to the Contacts page, then Manage Fields button.
   

   

2. You can then select Create Field, and create a phone text field. Using “phone” because “tel” is a reserved word.
   

   

Add number to each contact

You’ll need to add each contact’s phone number to their custom field. I am not sure how you’ll know to match the phone number to the contacts, but that would be the same with UUID, so guessing you have a way.

For each contact:

1. On contact’s page, open the menu and select Custom Fields.
   

   

2. Select phone and add the number and save.
   

   

Set up flow

You’ll also need to update the RapidPro Flow. If you are using the RapidProFlow as suggested in the CHT docs, instead of the suggested flow code:

@(json(object(
 "id", run.uuid,
 "from", replace(urns.tel,"tel:+", "+"),
 "content", input.text
)))

…you’d replace the flow’s phone number urns.tel with the contact’s new custom phone field that you added, giving you:

@(json(object(
  "id", run.uuid,
  "from", contact.fields.phone,
  "content", input.text
)))

Note that you don’t need the replace bit if you format the phone number the same way as it is in the CHT, which is + followed by the country code and complete phone number.

---

This approach should work if you know how to associate the phone numbers to the contacts in RapidPro, but I’d suggest testing with a couple numbers first to avoid the effort of updating the numbers unnecessarily.

Hope this helps, and let us know how you fare with it!

[Beth]

@marc - thanks, I like this idea and think we should explore it more. Let’s get a phone call on to talk about the core changes though. Our use case is a seemingly a unique application:

• web version: we can’t store data on tablets
• facility-based: case managers will use system to support case management, and enter patient data into CHT
• our team is supporting RapidPro flows and aren’t allowed to access patient data per MOH regulation
• CHT split into docker containers to patient data from software, so our team can update CHT and MOH has access to data

I’m nervous (assuming I understand this approach) about us storing any kind of phone numbers in RapidPro so we meet MOH regulations. We’ll also need to explore how to avoid seeing the two-way text messages between patients and case managers.

I’ll ping you in an email to set up a (overdue) call with the team for deeper dive, and include our colleagues in-country.

cc: @cliff @mozzy

[marc]

Ya, those sound like tricky requirements! Looking forward to chatting about it more to better understand the situation.

[cliff]

@marc

You’ll need to add each contact’s phone number to their custom field.

thanks @marc ,

adding this number will be possible though it looks like it will require someone to always add it manually for each contact …

@marc

I am not sure how you’ll know to match the phone number to the contacts, but that would be the same with UUID, so guessing you have a way.

Am thinking if we attouch the tel number of the contact to the json mapping key property of the outbound payload sent to text it like

"mapping": {
        "patient_id": {
          "expr": "doc.patient_id",
          "optional": false
        },

        "flow": {
          "expr": "'f26b6f2f-168b-4690-a52d-a27f54f88fc6'"
        },
        "urns": {
          "expr": "['tel:' + doc.phone]"
        }
      }

then i think we can tap into that tel number and associate it with the custom field update of the contact (still figuring out how to achieve this in textit )

[marc]

It looks like you are creating the TextIt contact programmatically when the person is created in the CHT, is that correct? If so, the Flow that creates the contact could add the phone number to the custom field, as per these docs. That may simplify your workflow, and may be defeating your anonymization efforts.

[cliff]

@marc

It looks like you are creating the TextIt contact programmatically when the person is created in the CHT, is that correct?

yes @marc

@marc

That may simplify your workflow, and may be defeating your anonymization efforts.

oh i see, thanks