Medical mobile applications can be a great tool for patients and doctors alike. Before working on the pharmacy app we were involved with the development of medical app Capture Proof that allows doctors of HIPAA to conduct consultations online and to monitor health conditions by looking at patient videos and photographs. This application bridges the gap between patients and doctors and is aimed at medics, providing them with visual and practical examples to facilitate discussions with patients.
Now, we have faced with a similar task again. Our challenge is to develop a medical application for patients. The project is a b2c app that works like an online shop with a delivery service.
The pharmaceutical application was conceived as a geolocation service for those who need to buy medicines urgently, regardless of their location at that moment.
What does a man usually do when he needs to buy medicines? As a rule, he goes to the chemist that is closest to him. What if this need has come upon him suddenly and he doesn’t know where to find the nearest chemists? What if the nearest chemists don’t have the necessary medicines in stock, or they are too expensive? The customer who approached us for development wanted to solve all these issues.
The idea was to simplify the search for medicine. The user scans all the nearest pharmacy shop, compares their prices in online mode, chooses the ones they want to purchase, and orders courier delivery. The user also pays for medicines through the app; we will tell about the app, as described below.
In the case of delivery, the pharmacy shop sends its courier with a pre-paid box, and they deliver the medicines to the customer wherever he is. However, the user can take the order.
The project is under an NDA, so we can’t mention the customer’s name or any other confidential details. Here our customer explains how he came up with the idea for this app:
The pharmaceutical application is intended only for use in Kenya for now, but further, down the line, the customer might expand the area covered by the app. However, such services, which are designed to find the best deal, or to find a suitable object using geolocation, can easily be applied to any sphere and on any territory: for example, in search of an optimal exchange rate from the nearest exchange offices.
The ability to search by a given radius is useful in cases of spontaneous decision making. Sometimes the decision to find something is made suddenly, but google maps may be unable to meet the challenge. The app suggests a variety of locations to the user according to default parameters. Here, the search function is provided with a maximum and minimum preset radius. The admin, who is determined by the customer, can enter the exact figures for maximum and minimum radius in a console on the server.
To make it a little clearer, the development process is explained below. This is not the only application developed by us as part of the order. As a matter of fact, the app made for patients is provided alongside with a server and other applications, all of which work on patients’ needs.
The patient’s application works in a number of ways. First, a user takes a picture of a prescription written by their doctor. The app sends the photo to pharmacies shown on the app within a specific radius. Second, the patient types the required medicine into the search field.
Pharmacies can see all submitted prescriptions and requests for medicines through an application created for them. Here, drugstores accept orders and confirm whether a certain medicine is available or not.
Administration of all app settings is provided with a server. In our case, the customer makes any required adjustments to settings, changing parameters such as radius, for example’
M-Pesa has made a huge breakthrough in Africa’s economic system. It simplifies the payment process significantly, reducing it to just one step. An interesting fact is that M-Pesa spans about 50 percent of all world transactions. The system does make a leap in such depending country as Kenya. The Department of International Development of Great Britain sponsored its creation.
The general principle of the system is to allow payments through a local mobile operator. In Kenya, this was the monopolist of mobile communications Safaricom. Later, by Vodafone’s request, the service was scaled by IBM company.
Usually, a payment system integrates with web and mobile services for four days maximum. Here, M-Pesa uses XML protocols, with no JSON, although the latter one is preferable when it comes to simplifying the code, making it more readable and convenient for future changes.
Our programmers noticed that the documentation was very unclear, with no data about what and where to send. As it turned out, a key was needed. get the key, consisting of 5 digits, we had to wait two weeks for the registration process to be completed. Then, we came up against the next challenge – we needed an additional passkey. To get a passkey, we had to fill out a lengthy inquiry form, which asked the type of system we were using, how many servers we had, what databases, what VPN (if applicable), points of connection, support system, names and telephone numbers in the support service, passwords, API endpoints and many other criteria. We filled it in and sent it. Three days later, M-Pesa support sent us yet another form to fill out. As a result, our team spent a month just on the documentation and integration of the service.
The system works exclusively through mobile connection – an M-Pesa icon appears on the mobile screen from which a user can make all payments. The stumbling block here is that we could not test this during development because testing requires an active Safaricom network. Therefore, testing was left to the client.
A request is sent from the phone and the request is then generated on the server. After that, to send an SMS, you need to make four requests: for connection, authorization, confirmation of authorization and request for confirmation of payment. The customer receives a text message on their phone, to which they need to respond yes or no to payment.
The whole integration process is actually not that complicated, but the processing of requests and documentation for connecting to this payment system takes up a lot of time.
There will be several channels for transactions within the integrated system. The customer-to-business (C2B) model is where the client pays directly to the system. In Kenya, there are no regulated prices for pharmaceutical goods; the price is known only by request, so, chemists charge a range of different prices. Our target pharmacy app chooses the best proposal and saves the time and money of the patients.
Business-to-business (B2B) is when the system pays to pharmacies. Here, the system once a week transfers money to pharmacies with a commission.
Now we have completed the development of the app, we’re currently working on a promo clip that will be published in the various App stores. The projects will be released soon: watch this space!