SMS Module Data Model and Design

Software Add-on Modules
1

We at AMPATH are in the midst of planning an SMS module for OpenMRS. There are various modules thus far providing this functionality. I wanted though, to open up a discussion about the data model and design for messaging.

I’m attaching some initial thoughts I had here: SMS Module Design v1.pdf (62.3 KB)

If anyone else has either done this or looking to do it, would be very interested to hear your thoughts.

Thanks.

2 Likes
2

Have you seen this? https://wiki.openmrs.org/display/docs/Messaging+Module

3

@michael, I had take a quick look. I think that forms a basis but we’re looking to build something a bit more comprehensive. Something that:

  1. Allows for stored message templates (that can be later sent out)
  2. Can allow one store a scheduled message
  3. Allows for a message “program” containing a set of messages - users can be enrolled in a bulk number of messages which are pre-defined
  4. Allows for users to customize when they want to receive messages for various message programs
  5. Has rest endpoints for everything involved
1 Like
4

Agreed that sounds much more useful. I have not looked at this module’s code in many years but I would consider it abandoned, and if it was useful to save some time and effort, you might consider using it as a starting point perhaps.

5

@jdick, given a feature set like you are describing, I would recommend that you consider using an external system, probably RapidPro / TextIt.

They will always have done a better job at the SMS workflows than an OpenMRS module will have. You should offload the bulk of the work to that system (which is already built, and super slick from what I’ve been hearing). Instead you’d use of your resources/effots to define how OpenMRS should call out to an external system to trigger messages, and get informed of results.

2 Likes
6

@darius, I took a look at RapidPro. The product owners say this is best not to be run locally. It seems to have quite a few parts.

I think there are three components to what I’d like to build that are not necessarily related to each other but may have independent value within OpenMRS.

The first is the concept of a scheduled event that is connected to either a patient/patients/?cohort. Perhpas, a table in which you could specify, a patient, a function to be called and a timestamp. We would then create a scheduler task which looked for “due” scheduled events and calling the function. I could see this having utility for other use cases besides sending text messages.

The second is representation of messaging in OpenMRS. @michael had pointed out a previous attempt at this and it might form a good basis for getting started on this project. This could be useful for not only handling messages sent by sms, but also allow for internal messaging to say different providers within openmrs.

The third would be the UI specific to the text messaging application I’m describing. This would be the least generally useful but would serve a specific need for how to use text messaging within OpenMRS.

1 Like