DRUGPOINT

Abstract This project entitled drag point is an application that enables health centers, Care Delivery Organizations (CDOs), and pharmacies to monitor the effects, trends of utilization, and the impact of drugs administered to their patients as means of achieving the millennium development goal of curbing diseases like HIV/AIDS, malaria and others which are targeted by the sixth millennium development goal (MDG 6). When a patient goes to get medicine at any of the drug points mentioned above, their mobile contacts are retained. The drug issuers then monitor their patients by asking them some questions by sending them an SMS to which the patients answer depending on the category of patient that is, depending on the disease that is being treated. The clients are required to provide an answer by selecting the options that relate to their current status or provide their own in case the available options do not relate to their current status. The responses of the patients are collected and analyzed by the medical experts who use this information to improve the use of these drugs and enable improved management of these diseases. Introduction In today’s dynamic world everything is susceptible to change including micro-organisms. So many lives have been lost to diseases especially in developing countries like Uganda which is this project’s primary target, due to lack of effective tools of monitoring the effects, trends of utilization, and the impact of drugs administered to their patients. However with the significant increase in the information and communication sector, a good percentage of the population owns mobile phones and SMS (Short Message Service) is one of the most common modes of communication on these mobile phones. The literacy levels are steadily increasing as many people can now read or there is at least one person in a given family or neighborhood who can read. This project is utilizing these situations to create an application that will enable health centers monitor effects, trends of utilization, and the impact of drugs administered to their patients by use of the mobile phones through SMS. Literature Review SMS SMS (Short Message Service) refers to a communication system in which a short message approximately 255 characters is sent from one communication entity to another for example one mobile pone to another. SMS (Short Message Service) has become one of the easiest, popular, cost-effective methods of communication over mobile phones by users. It is being used by businesses to get as close as they can to their customers with aim of keeping customers up to date with company news, products or service updates, relevant information about their accounts, or to send them notifications for important events. It is also used by other organizations to deliver messages over/ to a number of people, while others also use them to carry out opinion polls hence creating an interactive session among organizations and mobile users. Email messages are widely used for these purposes and that is usually an appropriate way to inform customers. But there is a drawback to using email exclusively for communication with customers. Not all customers have a habit of checking their mailboxes regularly, so information delivery can take longer hors or even days. Sometimes, this is not fast enough, and in most cases very few people have access to Internet or do not know how to use it. Mobile phones are a commodity today, and SMS (Short Message Service) messages offer an intriguing solution. Messages are delivered in a matter of seconds, and customers are far more likely to receive and read them, no matter their current locations. This is by no means the only way SMS messages could work for you. You could provide your users with two-way communication by enabling customers to send you an SMS request in a specified format and get a response from the system. This user interface would be far from being user-friendly, but for simple request-response situations, it would work well enough. Beside SMS messages, there are many technologies currently used for messaging by mobile users. Still, SMS messaging is the most widely adopted, and there are good reasons for that. MMS (Multimedia Messaging Service) messages have become popular, but many mobile devices don’t support them yet, and some people are unlikely to change their current phones for several years. EMS (Enhanced Message Service) is a proprietary technology, which restricts its wide adoption among phone makers. In this light, some analysts predict that SMS will be dominant technology in this field for the next few years. So we can definitely say that it is here to stay. There are many companies that offers SMS gateway services and enable various interfaces (HTTP, FTP, XML-RPC, SMTP) that could be used for sending (and in some cases, receiving) SMS messages. Also, you could find some gateway products and open source projects for the same purpose. This approach is appropriate for most cases, because developers know these technologies well and it doesn't require a big development effort for a solution that will work. But if you want to heavily use SMS messages or greater flexibility in your system, one will probably want to skip the "middleman" and work directly with your mobile provider. This project therefore describes an SMS-powered application that can communicate directly with the mobile operator of any choice choice, all using Java and open source tools and libraries. SMPP Protocol SMS messages are transferred using Short Message Peer to Peer (SMPP) protocol. This is an open industry standard protocol developed to enable transfer of short messages between mobile users, called External Short Message Entities (ESMEs), and Short Message Service Centers (SMSCs). An ESME represents a fixed-network SMS client, and that is where our application resides in the system. For the SMSC, we will assume a mobile provider or a center that is responsible for delivering the message to mobile user. The communication may also involve Routing Entities (REs) that are responsible for message routing between ESMEs and SMSCs (and of course, other routing entities). SMPP defines a set of operations in the form of Protocol Data Units (PDUs). PDUs are well-formed packets that are transferred between entities. A PDU consists of a header and an optional (depending on the PDU type) body. From the OSI stack perspective, SMPP presents an application layer protocol and relies on a TCP/IP (or X.25) network protocol that is responsible for packet delivery. So the basic requirement for using SMS messages is providing a reliable network connection to your mobile provider (just as it would be needed for any HTTP data transfer). The first thing the ESME (SMS application) should do is to establish a session with the message center. There are three connection types that could be used, depending on the application's role in the system. An ESME can establish the connection as a transmitter (TX), meaning it can only send messages to the SMSC for a delivery to mobile users. Next, it can behave as a receiver (RX), in which case it can only receive messages from an SMSC. Finally, first two modes are combined in a transceiver (TRX) session type that enables application to both send and receive SMS messages. The SMPP protocol is an asynchronous protocol, which means that the ESME could send the next message before it receives a confirmation that the previous one had been received by message center. This approach leads to better network utilization and overall performance. The asynchronous nature of the protocol also affects the API architecture, which will be discussed in the later section. Security is always a concern when one is talking about communication protocols. PDUs are transferred plain, so they are vulnerable to interception and impression attacks. If you want to prevent these kinds of attacks, you should consider some additional security measures, such as using a leased line to the message center or using an SSL connection. SMPP API One way to make the application "speak" SMPP is to use the SMPP API, an open source Java API. An API is a collection of already written classes which one can use in the application one does not have to develop the application from scratch but use the available classes and customize his application. Mode of Operation/Functionality Our application uses the asynchronous mode of communication and it will establish a session with the message center as a transceiver (TRX) since it is required to send messages to the patients and expect a reply message from the patient. Overview Figure 1: Overview of the communication process Protocol messages The arrangement shown in Figure 2 below shows the process through which the drag point application exchanges messages with patients through the message center. The labels on the arrows represent the main PDU types that are exchanged between the ESME application and the SMSC. Figure 2: PDUs transferred between the application and the message center ESME to SMSC The ESME establishes a network connection and binds as transceiver to the message center. A message is sent from the application to the message in appropriate format. This message is a question with the appropriate answer options for example, “Did you get drug X that required for your condition? Answers: 1 yes or 2 No” The ESME delivers the answers to the message center, shown as submit_sm and submit_sm_resp. In addition the application may “query” the message for the status of previously submitted messages using the Message ID returned by the SMSC when the particular message was originally submitted. SMSC to ESME When the patient receives the message from the message center, he or she replies to the message with the appropriate options available. The patient is however given the format by which to answer the questions. For example to answer the question in the message shown above the patient is required to type DRUGPOINT or DRUGPOINT . The SMSC delivers the message to the application shown as submit_sm and submit_sm_resp. The application then checks on the format of the message and then sends the second question and processes is continued until the questions are finished. The results are then utilized by the medical experts. The application exchanges messages with the message center as long as it has a valid, bound session to it. When the application has finished the process, it terminates the session, it unbinds the session with the unbind and unbind_resp and closes the network connection. Figure 3: The SMSC simulator showing the message from the patient