Smart Allergy Medication with BLE Dispenser

Explore the challenges and triumphs of developing specialized firmware, designing an energy-efficient medical device, and integrating custom mobile and web applications for a leading pharmaceutical company.  Their innovative strategy goes beyond traditional drug production, incorporating smart devices into product packaging. This transforms the package into a comprehensive digital ecosystem, complete with mobile and web applications. These applications not only track medication usage but also forge a connection between patients and healthcare providers, enhancing the overall healthcare experience.Their technological advances and tailored solutions have attracted numerous medical providers with specific requirements. This post explores a partnership with a medical clinic launching an allergy medication line with specialized smart packaging. They required a highly customized mobile app and the integration of a new smart device for allergy medications, calling for the development of specialized firmware. Continue reading to discover the technical details of how this project was implemented.

Healthcare Solution for Smart Medications

Our task was to technically implement a specific scenario that begins in the most traditional of settings: a doctor’s office. The partner, a clinic working with our customer, had the following workflow in place. When a patient visits the clinic, their details are entered into the clinic’s internal CRM system. This information then automatically triggers the creation of another account for the patient in a different internal application used by doctors for managing medical records.
The key moment occurs during the doctor’s consultation. If the doctor prescribes allergy medication, they introduce the patient to our cutting-edge solution: medications in smart packaging, coupled with a mobile application designed to interact with the smart device within. The app’s primary functions include reminding the patient about medication schedules set by the doctor, receiving confirmation of medication intake from the smart BLE IoT device integrated with the medication dispenser, and transmitting this data to a server. From there, the information flows into a specialized web application for doctors, allowing them to monitor and, if necessary, adjust the patient’s treatment remotely. If a patient opts to use this smart system, the doctor notes this in their internal application. This action sends a request to our server to create a new patient account and generate a registration code, which is then sent to the patient’s email. As a result, registration in the application is exclusive to those possessing an activation code. Additionally, the doctor has the capability to dynamically customize the application’s functionality for individual patients. For instance, if one patient might benefit from a feature that tracks symptoms and triggers, the doctor can enable this for them. Conversely, for another patient, the doctor may deem this feature unnecessary. These preferences are managed within the doctor’s admin panel and any adjustments made there will be reflected in the patient’s application.

After the patient receives their prescribed medication and the smart device, which is a specially designed holder for the medication dispenser, they pair this device with the app, and the system starts functioning. The patient receives app notifications aligned with their medication schedule. When they dispense the medication, a specialized sensor registers this action, setting off a chain of data transmission that ultimately lands on the doctor’s dashboard in the web application. This enables the doctor to monitor and adapt the treatment plan as needed. This scenario forms the backbone of the solution. Now, let’s examine the technical intricacies of how we helped our customer bring this system to life.

Advanced Application Customization

This chapter explores the workflow of creating a new application for our customer’s partners. For this purpose, our customer utilizes a modular low-code platform developed by us, where a new application can be assembled like a set of functional modules, and its appearance can be customized. A significant part of the assembly and configuration process of a new application is carried out in the admin panel. This significantly reduces the amount of code that developers need to write before the application is fully ready. Learn more about this platform in this blog post.

The process begins when our customer acquires a new partner, like the one highlighted in this blog post. An administrator on our customer’s side sets up a separate instance of the client-server application within their infrastructure. As mentioned earlier, this setup is customizable through an admin panel, where two key aspects are adjusted:

Functional Modules Selection: From a suite of 20 available functional modules, specific ones are chosen to fulfill the customer’s required functionalities.

Application Design: This involves tailoring the app’s visual aesthetics – selecting a color palette, tweaking a limited set of UI elements, and incorporating logos to align with the partner’s brand identity.

However, the requests from this particular partner extended beyond the existing scope of our platform’s functionality and design. For example, our standard module for displaying a patient’s medication intake history was initially created to manage the records of a single patient. The partner’s request involved the ability to display medication intake history for a larger number of patients. They also brought to the table a range of other unique requirements that pushed our standard framework to evolve. On the design front, the existing customization options allowed for altering color schemes, logos, some UI elements, and other minor visual aspects. Yet, this partner desired a complete overhaul of the UI, proposing their own design. Our customer’s original concept for design customization was to offer a limited set of options to maintain a consistent and recognizable style across all applications. However, to accommodate this specific partner’s needs, it was decided to extend these boundaries significantly. Addressing these challenges involved a strategic expansion of the unified codebase. New functional modules were developed, enhancing the platform’s capability. Additionally, the scope for design customization was broadened, enabling future partners to have greater freedom in tailoring the application’s appearance to their specific brand requirements.

Firmware Development for Embedded Systems

In this chapter, we focus on the central aspect of our smart device – its firmware. This device, disguised as a simple medication dispenser, is anything but ordinary. It houses a tension resistor sensor, like those found in electronic scales. This sensor, a thin plate, generates an electrical signal upon pressure application – the stronger the pressure, the stronger the signal. This mechanism is crucial for registering not only the act of dispensing medication but also the quantity based on the force applied. However, crafting the firmware for such a device was a journey of overcoming multiple challenges, ensuring accurate dose measurement and efficient energy use.

Waking Up the Smart Device: The device stays in sleep mode until activated by pressing the pump, which exerts pressure on the tension resistor. This pressure generates an electrical signal, awakening the microcontroller. We meticulously calibrated the signal threshold for waking the microcontroller. If the signal generated by the sensor falls below this threshold, the microcontroller might not detect it and fail to activate, leading to an unregistered dose of medication.

Click or tap on the picture to open it in full size

Temperature Compensations: The device’s accuracy hinges on the tension resistor’s stability, requiring it to be on a flat surface and pressed by a lens with a specific curvature. However, factors like temperature variations (as the medication is stored in a fridge but often used at room temperature) affect the plastic’s rigidity in the pump mechanism, influencing the sensor readings. To address this, we implemented a temperature compensation algorithm in the firmware, adjusting the readings based on the plastic’s temperature-induced flexibility changes. To accurately determine the compensation coefficient, the device includes a temperature sensor, based on which a temperature compensation coefficient is calculated using a formula.

Click or tap on the picture to open it in full size

Partial Pump Presses: Another aspect was recognizing ‘Partial Pumps’ – incomplete presses of the pump, which could lead to incorrect dosage intake. These events are also reported to the application for the doctor’s review.

Bluetooth Connectivity: Our firmware engineers developed robust Bluetooth communication protocols within the firmware, considering the stringent reliability and security requirements of medical devices. These protocols needed to be consistent across the wide range of smart devices supported by our customer’s system.

Application Side SDK: On the application side, our developers created an SDK for this smart device, considering their unique functionalities. This SDK, developed for Android in Kotlin and for iOS in Swift, manages communication with the smart devices via APIs.

Energy Efficiency: Since the device is powered by a non-replaceable battery designed to last at least a year, energy efficiency was paramount. The firmware was optimized for low energy consumption to ensure both prolonged battery life and stable device operation. For an in-depth look at our approach to low-energy device design practices, stay tuned for a dedicated blog post.

Meeting Backend Requirements

The challenge we faced in meeting the backend requirements was integrating the data flow from two external systems – the CRM and the doctors’ application utilized within the clinic’s infrastructure. Our solution was built on a flexible modular architecture, which greatly facilitated the integration of incoming request streams into our system. While the core architecture of our client-server application remains consistent across our customer’s partner base, the unique patient service scenario presented by this partner required some architectural modifications. Illustrated in the diagram below is a simplified high-level schema of our backend system and its integration with partner applications and third-party services.

Click or tap on the picture to open it in full size

For those interested in a detailed analysis of the architecture built on AWS services, we invite you to explore an in-depth blog post dedicated to this topic.

Let’s Get Started

Our team’s expertise covers a broad spectrum of healthcare solution development, from IoT device connectivity and AI technology development and integration to cloud data management and adherence to personal medical information protection standards.

Let’s talk about your project! Reach out to arrange a consultation and discover how we can support you.