This case study discusses how we developed a mobile application and a customized device to make it easier for elderly patients in Mexico to order and receive their prescriptions and other medical supplies at home.

Key technologies

Core team

  • Diego Reyes Altamirano – Software and Hardware Developer, Origis
  • Saúl Almeida Montiel – Backend Developer, Origis
  • Leslye Guerrero Mendez – Machine Learning Models Developer, Origis
  • Juan Carlos Govea Tellez – Project Manager, Origis
  • Ludwig Villarreal Guzman – Business Affairs, Microsoft Mexico
  • Amin Espinoza de los Monteros García – Senior Technical Evangelist, Microsoft Mexico
  • Omar Aviles Rosas – Technical Evangelism Manager, Microsoft Mexico

Company profile

Origis, based in Mexico City, is a company that specializes in creating and implementing technology solutions that make the operation of processes in public and private companies much more efficient. Through consulting, automation, and operations, they integrate their products into their clients’ existing systems to create the first step in a continuous improvement process.

Problem statement

In Mexico, many pharmacies maintain a stable clientele and good loyalty indexes, so if they want to increase their numbers, it depends on factors that go beyond prices or the proximity of clients. The main focus of the pharmaceutical chains is on elderly people who do not have good mobility and who are dependent on receiving medications for their treatment.

Based on the success of existing home delivery services for cars, food, or supplies, one of the pharmaceutical companies came up with a great idea: create a physical device that enables their clientele to receive home delivery of their medications and other pharmaceutical items. This allows their clients to remain at home instead of having to physically go to the pharmacy, which makes life easier for their clientele and saves them time.

Solution and steps

The product that Origis is developing is a dual-function device. The first scenario is where a client with a loyalty card for a pharmaceutical chain can order medications with the push of a button; its intention is to compensate the loyalty of pharmacy clientele by making the process of buying medications easier.

The second scenario is where double-clicking that same button sends an alarm to previously established contacts under certain circumstances or previously established scenarios such as an assault in a nearby house, a fire, or symptoms the patient has that need external attention. This option makes the notification process for each contact extremely simple.

Following is a graphic of the sensor button.

Sensor button


Architecture

Mobile app for instant purchase

The instant purchase process was extremely easy to incorporate into the operations of clients with loyalty membership because the pharmacy system is built by Origis, so it was only necessary to add a client registration table to the client’s identifier-associated device and everything was ready. Therefore, the functionality was very simple to adapt. Following is a diagram of the architecture and a description of the steps.

  1. For communication between the device and this system, a POST operation is used in the CRM API that the pharmacy uses to administer the memberships.
  2. The loyalty card sends a notification and obtains the telephone number of the client from the database to confirm their order by telephone.
  3. The pharmacy establishes the purchase order.
  4. The pharmacy calls the client to confirm the order and to collect charges by using a credit card.
  5. After the payment goes through, the client receives a text (SMS) that indicates that his order is on its way.

Instant purchase button architecture


Mobile app for panic button

The panic button was an unplanned feature of the device. It came out of a planning session that considered that, if the device was aimed at adults of an advanced age, such a function could reduce the consequences of accidents or unavoidable but controllable external factors. This device cannot work offline because of the need for direct communication with other devices such as mobile phones or Wi-Fi hotspots.

The general functionality of the device is shown in the following diagram.

Panic button flowchart


The following diagram and steps describe the architecture of the panic button.

  1. The client presses the button twice to notify a previously established group of contacts (alert group) about an emergency; if the situation calls for it, the device also sends an alert to public services such as an ambulance, fire department, or local police.
  2. The message sent by the client arrives at an Azure IoT Hub in a JSON format that goes directly to an Azure Stream Analytics job.
  3. The Stream Analytics job processes the information at various points starting with WebJobs.
  4. WebJobs queries the database where it obtains the necessary data from the client database to process the emergency alert.
  5. The Stream Analytics job also sends a record to another table in the same database to keep track of the alerts that each client sends.
  6. After the database records are obtained, WebJobs obtains them and sends the information to a notification hub (Azure Notification Hubs).
  7. There are two notification hubs: one sends Push notifications to all people involved in the client’s alert group, and the other notifies the client that their message has been sent.
  8. The client receives confirmation that their alert group has received the alert message.

Panic button architecture


Wi-Fi settings

The device has an antenna that allows a Wi-Fi connection to nearby networks. For that to happen, it is necessary to use a device that allows wireless connections to connect to the local network of the device. The local connection allows access to a small website that serves as an administrator of wireless networks.

Wi-Fi Manager


In the configuration, you can select the desired network and connect quickly.

Connect to Wi-Fi


After you’ve connected, the button sends a confirmation message by means of its indicator LED changing color and thus showing that it is ready for continuous use.

Indicator light


The indicator light colors indicate the following:

  1. Blue: A Wi-Fi connection has completed successfully.
  2. Green: The device has sent a request (the LED turns off only after fifteen seconds).
  3. Red: The device is on but does not have a configured connection.

With the device configured, the client can just press the button to receive a call from the nearest pharmacy and confirm their order. When the order has been confirmed, they will receive a text (SMS) confirmation message and then another that the order has arrived at the client’s location. The payment will have already been made electronically to the client’s loyalty membership, and then the process is finished.

Because this process doesn’t require any knowledge of how the app works, and the only thing the client needs to know is how to press a button, it will be really helpful to people who are not familiar with operating smartphones, or who just don’t want to start a process with the application. Actually, they could send the request without a mobile phone thanks to the Wi-Fi sensor, and the pharmacy could call their home to verify.

The following workflow describes the process. The client:

  1. Receives their device at the pharmacy.
  2. Connects the device to a Wi-Fi signal.
  3. Receives a synchronization call to confirm that the device is enabled and ready to use.
  4. Presses the button to place an order.
  5. Receives a call to confirm or modify the order.
  6. Receives a text (SMS) to be notified that their order is online.

Wi-Fi flowchart


Mobile phone application

To synchronize the device with the entire process in the cloud, clients need to install an application on their mobile phone. The application has the following views.

Access screen. The client can be registered as a user or administrator; the separation between roles is only possible by creating new groups and adding new members to them. This is intended to eliminate the possibility of children or the elderly adding members to groups without control.

Access screen


Registration. This screen is a classic form that simply obtains the required data from the clients.

Registration screen


Connect to Wi-Fi. The application must be connected via Wi-Fi in the same network as the device in order to interact between them. In addition, when the device emits an alarm, the application has the ability to send a notification to an established group of contacts (alert group).

Connect to Wi-Fi screen


Contacts. On this screen, the administrator can set who will be notified and which groups are established between the different pre-set scenarios.

Contacts screen


Type of alert. The established groups must have an alert type set up so that the sent message can carry the appropriate content.

Alerts screen


Group invitation. The person who is added to each group will receive a notification that they have been added to the group for the purpose specified in the previous screen. They can be notified in one of two ways, either by text (SMS) or email. SMS uses the service Twilio, and email uses SendGrid in Azure.

Group invitation screen


Email sample. Following is an example of what the invited person will see when receiving an email asking that the application be installed on their phone and the steps to follow for a correct configuration.

Email sample


Emergency information. On this screen you can view the emergency history that has been activated from the device that is linked to the application.

Emergency screen


Notification received. This screen shows an example of how the notification looks when it is received by one of the members added to the alert group specified in the application by the client.

Notifications screen


The following diagram describes the processes the device takes with the application and in the cloud. Column 1 describes the device configuration and column 2 describes what happens when sending an alert.

Device processes


Technical delivery

Device and operation

The center of the whole process in this project is the device. This device only has one button, and the button only has two operational gestures. Pressing the button once indicates that the client wants to place an order to the pharmacy, and pressing it twice indicates that he is notifying the receiver about an emergency. After either gesture, isolated processes are triggered that allow those involved on both sides to react.

The heart of the device is an ESP8266 version ESP12, which is really easy to connect to by Wi-Fi and has a low energy consumption. Energy is provided by two AA batteries that are intended to last seven months. Replacing batteries is as easy as doing so for a TV remote control. Any client with a loyalty card from the pharmaceutical chain is invited to obtain a device, and after configuring a connection between the device and the membership, the client can begin to use this tool right away.

Device 1


Device 2


Security

In the device

The device has a Wi-Fi connection antenna, so for security it uses the type of configuration that the hotspot to which it connects is established from WEP to WPA2 systems. It can also connect to open Wi-Fi networks without a problem. Personal information cannot be compromised thanks to the connection with Azure IoT Hub. As a matter of fact, the device doesn’t keep any kind of personal information; everything is in the company’s system, and they connect to each other by using only the device ID.

Preventing the chance to get infiltrated information or even just fake data, the Azure Stream Analytics job query can identify an unusual amount of requests and send an alert to block the device temporarily; the pharmacy’s own system can block the device remotely. The system now is separated, but they’d like to eventually incorporate it in their CRM. What is great here is that Origis created this CRM, so it will be easier to do it, but it’s not their main goal for now. The pharmacy calls the client associated with the device to verify that everything is working fine or if there is a problem with the device that needs to be solved; if the latter is the case, the device is replaced for a new one.

In the application

The application requires a physical device that is unable to issue alerts fictitiously or by an unregistered public.

All clients’ information, contact groups, and group topics are stored in Azure SQL Database so that if the client decides to switch devices, they can access everything previously saved by registering the application from the new device.

In communication

The link between the application, device, and the cloud is via IoT Hub, and to establish communication, the device is automatically registered in the first configuration process from the pharmacy’s own system.

void setup_wifi() {
  WiFiManager wifiManager;

  wifiManager.autoConnect();
  digitalWrite(verde, LOW);

  digitalWrite(verde, HIGH);
  digitalWrite(azul, HIGH);
  digitalWrite(rojo, HIGH);
}


The following are the methods used to send emergency alerts to the contact groups.

void oneFunction() {
  String str = String(ID);
  String payload1 = "{\"idBoton\" :\"" + str + "\",\"Oprimio\":\"1\"}";
  digitalWrite(verde,LOW);
  payload1.toCharArray(emergencia, (payload1.length() + 1));
  Serial.println("Button 2.1");
  client.publish("devices/btn01/messages/events/", emergencia);
  Serial.println("Haciendo Subscribe");
  client.subscribe("devices/btn01/messages/devicebound/#");
  Serial.println("envie el mensaje2");
  digitalWrite(verde,HIGH);
}

void twoFunction() {
  wifi_set_sleep_type(NONE_SLEEP_T);      
  String str = String(ID);
  String payload2 = "{\"idBoton\" :\"" + str + "\",\"Oprimio\":\"2\"}";
  digitalWrite(rojo,LOW);
  payload2.toCharArray(emergencia, (payload2.length() + 1));
  Serial.println("Button 2.2");
  client.publish("devices/btn01/messages/events/", emergencia);
  Serial.println("Haciendo Subscribe");
  client.subscribe("devices/btn01/messages/devicebound/#");
  Serial.println("envie el mensaje2");
  digitalWrite(rojo,HIGH);
}


The following is a sample of a JSON message sent to IoT Hub.

[
	{
	"idBoton":"13842698",
	"Oprimio":"1",
	"EventProcessedUtcTime":"2017-01-09T19:48:30.7144250Z",
	"PartitionId":0,
	"EventEnqueuedUtcTime":"2017-01-09T19:47:52.4000000Z",
	"IoTHub":
		{
		"MessageId":null,
		"CorrelationId":null,
		"ConnectionDeviceId":"btn01",
		"ConnectionDeviceGenerationId":"636135329032629096",
		"EnqueuedTime":"0001-01-01T00:00:00.0000000",
		"StreamId":null
		}
	}
]


IoT Hub is encrypted by using an SSL certificate that is already added to this feature.

Azure WebJobs, Azure Stream Analytics, and Azure SQL Database are in no way accessible to clients by means of the device or the application. For queries, an API is used that delivers certain services only.

The main idea behind securing the communication is to restrict the service to subscribed clients. If outsiders could access the service, it could result in fake alerts and other problems, making the device no longer useful for its intended clients.

Device authentication is not only a great security measure, but also the best way to block service for clients who are not members of the program anymore. Having a list of members associated to the devices will help ensure this.

Conclusion

The idea of a single “push to buy” button was good enough for pharmacies to proceed, but when they found that the app could be much more useful with the added panic button, they saw a great chance to increase their client base more quickly. The only problem was finding a cloud platform that could provide reliability for all their operations. They started evaluating Azure as their first choice, and after a couple of tests and simulated scenarios, they decided on Azure because they found what they needed and didn’t want to take more time looking at other options.

In the architectural diagrams for the instant purchase button and the panic button, the scenarios for sending data to Power BI were considered, and for the panic button, they also considered Azure Machine Learning. Origis found that data analytics could be useful to the pharmacies in determining client patterns such as age, common medications, and sales territories. With this information added to the companies’ databases, they could evaluate the opening of new pharmacies, have a greater inventory of medications, and suggest new offerings to their clients as well as different brands or products that complemented their purchases. In addition, it would be a great starting point to work with emergency services to better handle alerts, locate the most conflict-prone areas, and create faster routes. Origis found here the chance of an independent solution focused on government.

In the case of alerts, the plans are greater because with a display of data on a heat map and with the statistics of alerts usage, it is possible to gradually predict incidents and establish efforts in conjunction with different associations that for the moment are involved in the project.

We will implement this data model after six months of using the devices because at the moment there is no information to share.