key: cord-0060089-ofyh7u3p
authors: Ermakov, Alexander; Ormeli, Aleksandr; Beliaev, Matvey
title: Medication Intake Monitoring System for Outpatients
date: 2020-11-09
journal: Recent Research in Control Engineering and Decision Making
DOI: 10.1007/978-3-030-65283-8_46
sha: 7e236d06e86b6304fd3ada49b60cbfad143a1d9f
doc_id: 60089
cord_uid: ofyh7u3p

The subject of this article is the developing and implementing a hardware and software complex for monitoring medication intake by outpatient patients. Unlike today’s common hardware platforms, described complex allows not only remind patients of the need to perform regular admission, but also provide the infrastructure to inform the attending physician about the status of patient medication. The article discusses the implemented hardware prototype and the implemented soft-ware, as well as a description of the current problems and planned research.

The evolution of modern society, especially in the context of the global COVID-19 pandemic, requires new approaches to solving old problems through the use of Internet of things technologies. The use of modern technologies will al-low us to solve the patients compliance problem of undergoing outpatient treatment in a new way. Compliance refers to the patient's ability to take medication and undergo procedures in accordance with the schedule and regimen prescribed by the doctor.

The problem of compliance has been investigated in many medical studies [1, 2] . Failure to follow the therapist recommendations, in particular the pill regimen, leads to the transformation of acute diseases into chronic ones, the appearance of antibioticresistant bacterium, ineffectiveness of treatment in general and many other problems. The main task in forming the schedule of medication in-take is to ensure the required level of concentration of the active substance in the blood, cycles of their fluctuations for a period of time sufficient for healing, but not too long in order to avoid negative effects on the body.

Research shows that the reason why patients lose their medication schedule is most often due to forgetfulness. The patient can easily miss the time of taking the medication more than once in the course of treatment. Other reasons include a decrease in attention on this issue: most often in the acute phase, the patient is ready to take medications on schedule, but stops doing so in the remission phase, even with the ongoing course of treatment. Even worse -the treating doctor of such a patient has little chance to learn about the occurrence of such a situation, since often patients in remission begin to skip control appointments, or do not re-port the true state of things regarding the schedule of medication.

In this paper, we offer a comprehensive solution to this problem based on Internet of things technologies. This solution is based on the idea of tracking the facts of medicines intake by patients, storing the schedule of this reception, providing a mobile application that can take into account the schedule and re-mind the patient about it, as well as exploring the possibility of implementing this technology in existing medical systems.

The main purpose of the study is to try to find out whether it is possible to implement hardware and software complex for tracking medication intake by an outpatient patient in modern medical information systems and improve the quality of treatment as a result of implementation.

• On the basis of the described objective, it was necessary:

• Identify system requirements based on information flow analysis • Analyze the current state of medicines tracking and medical information systems • Design and develop a prototype hardware and software package • Perform load testing and determine system scalability and fault tolerance requirements • Implement this complex in the existing medical system • Determine the possibility of industrial production of hardware and software • Conduct field experiments and statistical analysis of their results.

At this time we are at the stage of completing the prototype development: prepared the sample of hardware and managing service that can receive and store data about the medication, and also developed a demonstration information system for patients management.

The idea of a hardware and software complex is based on the idea of combining functionality for two main users: the patient and the doctor. When developing the system, it is necessary to take into account that both users are not specialists in information technology, and therefore it is necessary to minimize the specialized actions and configuration process for both categories of users. In addition, we consider it necessary to provide two modes of operation of the application: full, in which the patient takes medication under the supervision of a therapist, and custom, in which the patient takes substances that do not require medical supervision, but require compliance with the schedule.

For the patient, the main functionality of the system is a reminder: that is, the system should signal that at the moment you need to take your medication. In terms of modern technologies, this means that there must be not only some device with a light and sound alarm, but also it must be possible to pair it with the patient's personal mobile phone. The functionality of collecting statistics from the patient's point of view will not be mandatory, since they cannot make decisions about the course of their treatment, but it is important to have a schedule of expected appointments.

For the therapist, the main functionality is the ability to set a schedule for taking one or more medications for all patients they working with and get information about the regularity of taking in the medical history. It should be noted that therapists can work with different information systems and the required solution must be separated from them and provide their data independently, so that existing systems can request data and send requests for the formation of a medication schedule to a specific patient.

Based on the analysis, we have developed a high-level architecture of the system shown in Fig. 1 . There are six main components in the system. Number one is the medicine dispenser. In this case, the dispensers are grouped under number two. This combination shows that a single user can take multiple medications. To simplify the design of the system, it is proposed to use one dispenser for one medication type, and to be able to combine such dispensers into a single design. Thus, Fig. 1 shows two users, one of whom takes three medications and therefore has three dispensers, and the second takes one medication and therefore has one dispenser.

The dispenser should be responsible for two main functions. First, it must be able to signal the need for medication. Ideally, it should support both sound and light alarms (with the possibility of disabling them). At the same time, it is necessary to minimize, in order to reduce the cost, the functionality of the dispenser, and therefore it should not store data about the reception, or about the expected schedule. Therefore, its second function will be the ability to connect to the management service, which is marked with the number three in the figure. The functionality of the management service (or rather, even a group of such services) should include interaction with the dispenser. In fact, this app should be able to track the list of dispensers that it monitors and take into account the schedules of taking medications from these dispensers. When the time for taking medication in the monitored dispenser comes, it sends a command to this device to activate the light and sound alarm. At the end of the control time (depending on the settings, it can be from one minute to several hours), it repeatedly requests the dispenser to get information about whether there were signs of taking the medication during the specified time period or not.

The management service takes information about dispensers and their schedules from the database shown in Fig. 1 by the number four. There the managing service will store the results of the survey of dispensers. The web service shown in Fig. 5 also works with the database. The web service will be the external interface of the system. In particular, it is assumed that it will provide data on the statistics of medication intake by a certain user or dispenser, or enter information about the schedule of medication intake by a certain dispenser into the database. The presence of such a tool, independent of the user interface, allows you to work with any external systems. We also assume that the management service will be able to send the results of the dispenser survey directly to the external systems registered with it.

An example of an external system is the mobile app shown at number six. The mobile app is designed for patients. In it, the patient can track the medication schedule in dispensers, receive notifications about the need for medication, and manage the medication schedule in cases where they are not managed by the attending physician.

Other types of external systems are generally shown here in curly brackets. The main idea of the architecture is based on the assumption that we do not need to write a new system specifically for the solution we have proposed. With this architecture, manufacturers of medical information systems will be able to integrate the functionality of their dispensers data request into their software with minimal effort. However, we should provide our own software product for cases where the only option is to maintain two separate lists -a list in an existing medical history system and a list of patients with dispensers and medication statistics.

Before starting the developing of this system, we conducted a study of the state of the subject area and functionality of existing systems. The study showed that the task of controlling medication intake by patients has been solved for a long time, but the existing solutions do not fully meet the identified requirements. Following systems was conducted:

The hardware platforms we have studied only solve the problem on the patient's side, that is, they are dispensers with a signal function.

Almost every solution found (except Xiaomi) takes into account medication intake after opening and closing the dispenser lid. The solution from Xiaomi requires a special device flip. Schedule tracking is implemented in different ways: there are devices that require you to download medications for each day of intake separately, and there are those that take into account the configured schedule and offer to store all medications together. All devices in one form or another have a light and sound alarm about the need for reception. The latest systems allow you to connect to a mobile phone via Bluetooth channel. However, this solution cannot be considered satisfactory, since for our purposes it means that the patient must have a mobile phone (which is not always true) and that the phone must be close to the dispenser at the time of taking the medicine. For the GlowCap system, we were able to find functionality that includes pre-ordering medicine from the pharmacy after it is finished and not quite clear mentions of the possibility of contacting a doctor via the GSM network.

Based on the analysis, we can conclude that the stage of introduction of dispensers with the possibility of network interaction is a predictable and obvious next step.

At the moment, we have developed a prototype of the hardware. A feature of its architecture is the layout of standardized elements widely used in the market, while the external form is sacrificed to the convenience of development. Figure 2 shows an image of the assembled device.

As you can see, the device consists of two compartments -the upper one is a dispenser box with a lid where the medicine is placed. The lower compartment is a protected space for placing the microcontroller. The most common solution used to record information about taking a medicine suggests that medicine is accepted if the dispenser lid was opened and closed. We tracking opening by the KY-021 magnetic field sensor. This sensor is quite small in size compared to other solutions, and also has a short response range, which should help eliminate the possibility of a false result.

The main logic of the device is implemented by the Arduino Uno microcontroller. The logic of the hardware complex is simple enough that we do not need to use a microcomputer, while the response speed of the microcontroller is higher, and the power consumption is lower, which allows you to increase battery life. The choice of standardized microcontrollers can be found quite large, but the Arduino line can be considered as a reference for rapid prototyping systems. A huge number of libraries have been written for Arduino that allow you to work with almost any peripherals. A large number of connection modules, expansion boards and sensors are being developed for Arduino. To develop software for Arduino, a very convenient development environment is used -the Arduino IDE, and the development language itself is look like C++, which allows you to quickly adapt to writing sketches (that is name for Arduino microcontrollers programms). For this task, we chose a specific\implementation: Arduino Uno, because it implemented the desired combination of sizes and connectivity.

A separate issue is the organization of communication between the hardware complex and external services. At the moment, the market is experiencing rapid development and cheapening of communication means, which allows you to make a wide selection. After analyzing existing systems and the proposed architecture, it was decided to use the prototype to connect the dispenser via an Ethernet cable to the Internet. The main advantage of this solution is again speed and ease of prototyping. For Arduino, a standard solution is provided in the form of an Ethernet Shield W5100 expansion board, which is well protected from voltage changes, has a high data transfer rate, and has a large selection of libraries in the development environment. However, it should be noted that this solution clearly requires the patient to have a home Internet connection, and with the possibility of connecting a cable, which is not always true. In the future, we will continue to investigate this issue.

In addition to the above devices, the system also includes three led sensors designed for light signaling of the device status. We will describe how they work later in this article. Figure 3 shows the scheme of Assembly of the device.

The Ethernet Shield W5100 expansion board connects to a board with an Arduino Uno microcontroller. Due to the fact that the form factor of the plug-in coincides with the each other form factor, connecting can be done by placing the Ethernet Shield on Arduino board, with the Ethernet cable connector right above the USB cable connector of the Arduino Uno. After connecting, the contacts located on the Ethernet Shield start working as contacts of the Arduino Uno Board, which means that in the future it is necessary to connect all the wires to the contacts of the expansion board.

To organize the operation of the led at optimal brightness, it is necessary to connect a 220 resistor to the anodes of all LEDs. Then connect the resistor and the digital output as shown in the Fig. 3 .

The red led indicating an Internet connection error must be connected to digital output number 8. The Yellow led indicating the need to close the device cover is connected to digital output 7. The Green led indicating the need to take medication is included in digital output 5. Ground wires are connected to the cathodes of all LEDs. The Arduino Uno Board has a limited number of connectors for connecting the ground due to which it is necessary to combine the ground for all LEDs and connect the resulting wire to the free ground on the board. The assembly ends by connecting the magnetic field module. For its correct functioning, it is necessary to connect the module contacts to the board contacts in the correct sequence. The contact located near the label "-" on the module board is a ground connection. It must be connected to the ground contact on the board with the microcontroller. The next contact must be connected to an empty socket on the Board marked "5V". The last contact is necessary for reading information from the sensor and it must be connected to the digital output 9. The connection as shown on Fig. 4.   Fig. 4 . Connection diagram of the magnetic field sensor The last step is to attach the magnet to the lid of the dispenser, which will interact with the opening/closing sensor. When applied, the magnet will close two open contacts in the vacuum flask located on the magnetic field sensor.

An important part of the describing complex is the implementation of software that ensures the functioning of the entire system. Currently implemented:

• scripts manage the state of the microcontroller; • management service;

• external interface of the management service; • demonstration information system.

The main functionality is provided by the management service: its tasks include sending HTTP requests to the microcontroller to activate scripts and collect data, as well as sending the collected data to external systems. The service is implemented using PHP scripts and runs under the OpenServer application server.

The general algorithm of the management service is as follows:

1. In the management service system configured Cron scripts that describing the schedule of medication intake. They describe the time of the next intake and the duration of waiting for the end of medication. When the time has come for intake, a POST request is sent to the address of the dispenser using a script activate LED.php. 2. When receiving a described request, the microcontroller triggers the sketch code block on the microcontroller to turn on the green led, which means that you need to take medication. The variable "lid" is set to 0, i.e. the dispenser lid was not opened yet. 3. If the lid of the dispenser was opened, the sketch block turns on yellow led, which means that the lid must be closed. The variable "lid" is set to 1, i.e. the dispenser lid is open. 4. If the lid was opened and closed, the sketch block for switching off both LEDs is triggered. The "lid" variable is set to 2, i.e. the medication is taken. 5. On the control service side, there is a pending operation the following Cron script. The next scenario lags behind by an arbitrary time, on average about an hour, then activates the script readINFO.php, which sends a signal to send data from the dispenser to the service. 6. When the microcontroller receives a signal to return data, it sends the value of the variable "cover" and turns off the light indication (if it is not off yet). 7. On the service side, the script is activated when data is received sendInfoToDB.php which sends information about the date, time, and status of medication to all registered external systems. External systems are currently registered manually.

The described algorithm allows you to make a complete diagnosis of the system and use it. For test purposes, several scenarios were also developed for manually managing the service's requests to the dispenser and visualizing them as a web form. An example of applying these scenarios is shown in Fig. 5 . The interaction of the therapists with this system is carried out through the usual information system. As mentioned earlier, the management service is able to send data to a registered external system if it is able to receive incoming HTTP requests. In our work, we have implemented a demo version of such an external system. In Fig. 7 , we can see a form for the therapist to keep a patient's medical history, in which, in addition to standard information, presented information about the percentage of successful medicines intake by the patient. The information on the necessary medications, dosages, and frequency of admissions are selected by the doctor when registering the medication, and then it is need to perform, in one way or another, pairing the dispenser with information about the medication in the system. In the current solution, we simplified the system and suggests that the therapist issues a dispenser with its number written on it, signs the type of medicine for this dispenser and gives it to the patient for use. The dispenser is returned by the patient after the end of the course of treatment. In addition, the external system can access or store information about all medications independently, as shown in Fig. 8 .

In Fig. 8 , we can see the number of the dispenser passed by the doctor to the patient, the date and time of taking the medication, and the status of the reception -missed or received.

The described complex is the basic implementation for the medication intake monitoring task. It includes both standard features of existing systems for notificating the patient about the need for medication, and more advanced features for providing information about admission to external systems. However, it should be noted that this system has several interesting scientific and practical problems.

The further work with the hardware:

• the Arduino system is effective for prototyping, but expensive when producing dispensers in bulk volumes. It is needed to find a cheaper, and possibly simpler analog. At a time we are exploring the possibility of applying the solution described in [3] ; • the dispenser microcontroller can be powered by both mains and battery, but the battery life is lower than desired (and a minimum of a month is required). It is needed to find a way to increase the battery life; • connecting the dispenser to the management service via an Ethernet cable requires the patient to have an appropriate connector or computer with the Internet. Alternative and more convenient implementation options should be considered; • the device itself requires improvement in its appearance for distribution to patients.

• The further work with the software:

• it is necessary to implement a service that is independent of external data storage systems; • it is needed to implement a mobile app for the most popular operating systems;

• the management service needs to be improved in order to provide flexibility in setting the medication schedule and connecting external systems;

• it is necessary to conduct load testing and investigate the issues of scaling the system when increasing the number of dispensers served. It is necessary to implement the appropriate system architecture for the research results.

In addition to all of the above, a major challenge is to determine the best way to configure and interact with the therapist and patient with the dispenser and the system, based on the assumption that it is necessary to ensure the minimum possible level of understanding of the system by users.

Solving all of these tasks can help improve medical monitoring of outpatient patients.

Enhancing Medication Adherence

Encyclopedia of Behavioral Medicine

A petri net model for the waste disposal process system in the