Pilulier automatique
Sommaire
Présentation générale du projet
Contexte du projet
D'après des statistiques établis en 2014, un meilleur suivi des traitements médicaux et des médicaments dans le monde permettrait de réaliser 8% d'économies sur le coût total des dépenses de santé.
De plus, on estime en Europe que la mauvaise prise de médicaments est à l’origine de plusieurs dizaines de milliers de décès chaque année.
Selon le rapport IGAS2, en France, un mauvais suivi des heures de prises et de dosage de médicament aurait causé entre 8 000 à 12 000 décès par an et coûté près de 2 milliards € à l’Assurance Maladie.
13 millions de patients résidents en France seraient polymédiqués, et parmi eux de nombreuses personnes âgées de plus de 60 ans.
La santé connectée est donc devenue un marché porteur.
C'est ainsi que de nombreuses solutions se développent chaque jour qui a pour but de venir en aide aux personnes âgées dans les horaires de leurs prises de médicaments et éviter les surdosages ou les erreurs de traitement.
Objectif du projet
L’objectif de ce projet est d'adapter un pilulier hebdomadaire pour le rendre connecté pour faciliter le suivi et la prise de médicaments quotidiens à différents moment de la journée.
Description du projet
Afin de mettre en place ce pilulier connecté, il faut bien prendre en compte la donnée suivante : il doit être transportable. Cela sous-entend d’avoir un modèle suffisamment compact ainsi qu’une autonomie sur batterie. Nous devons donc trouver une entre son autonomie et sa connectivité et sa taille/forme. Actuellement, il existe sur le marché différentes propositions de pilulier connecté. Chacun avec leurs caractéristiques propres :
- Imedipac de Medissimo : envoie un SMS et/ou un email à l’utilisateur pour lui rappeler de prendre tel médicament à telle heure.
- Do-Pill de SecuR : rend accessible les comprimés et gélules à la date et à l'heure indiqué par le médecin pour éviter les surdosages ou les erreurs de traitement.
- Sivan de MedSecure : prévient l'entourage si erreur du patient dans la prise de ses comprimées et alerte le patient si il doit prendre un comprimé.
Afin de proposer une solution alternative à ses piluliers connectés déjà existant, le patient pourra utiliser son pilulier hebdomadaire standard auquel il intégra une base qu'il rendra connecté celui ci.
Notre pilulier connecté sera composé d’un socle contenant toute l’électronique et la batterie et de 7 boîtiers à cachets amovibles
Cahiers de charges
Fonctionnalités
Ce support permettra au pilulier de remplir les fonctions suivantes :
- Emission d'une alarme lorsque l'usager doit prendre une pilule à une heure et date précise (alarme différente selon le moment de la journée : matin, midi, soir, nuit)
- Indication par une LED la boîte du jour à prendre et par une autre, le compartiment de cette journée.
- Détection si l'usager a pris la bonne journée (sinon émission d'un son)
- Détection si l'usager a pris la bonne pilule à la bonne heure (sinon émission d'un son)
- Détection de la présence des tiroirs
- Suivi par application Androïd.
Matériels
Le socle sera composé :
- 7 LED RGB pour indiquer par une couleur verte le bon boîtier et une rouge tout problème avec la boîte correspondante 7 LED RGB CMS ou LED déjà dispo depuis le Projet du Dé Electronique
- 28 IR émetteur [fournis le 22/02/2016]
- 28 Phototransistor pour la détection de l’intérieur des compartiments [fournis le 22/02/2016]
- 10, 20 ou 70 aimants conducteur d'électricité (5 par boîtier en face de 5 autres sur le socle, donc 10 pour une journée - possibilité de faire le proto sur 1, 2 ou 7 journée) pour assurer la tenue du boîtier et détecter sa présence 1, 2 ou 7 sachets de 10 aimants [10 fournis le 22/02/2016]
( 1 écran LCD pour afficher les messages comme la date et l'heure ou des alertes 1 Ecran LCD 2*16)
- 1 HP ou buzzer pour émettre une sonnerie Buzzer
- 1 arduino nano pour assurer le contrôle arduino nano [fourni le 04/02/2016]
- 1 shield BLE pour la connectivité bluetooth contenant le composant nRF8001 (déjà disponible du projet Surveillance passive de sommeil de IMA4 2014/2015) [fourni le 04/02/2016]
- 1 RTC pour avoir le temps et la date réel contenant le composant DS1307 (MOD-RTC déjà disponible du projet Surveillance passive de sommeil de IMA4 2014/2015) [fourni le 05/02/2016]
- 1 smartphone sous android pour développer l'application de suivi [fourni le 05/02/2016]
- 1 pilulier standard (Corentin)
- 1 rouleau de papier réfléchissant
- 1 décodeur 3 entrées / 8 sorties pour allumer les LEDs 2 décodeur 3E/8S
Chaque boite contenant les 4 compartiments de la journée est composée :
- 1 interfaçage de 28 LED pour indiquer le bon compartiment 28 LED Verte CMS [fournis le 22/02/2016]
- 7 super-condensateur pour allumer les diodes de chaque compartiment sur le boitier 7 super-condensateur
- 7 résistances de 525 ohm
- 1 microcontrôleur ATTiny pour enregistrer le compartiment à allumer (fourni par l'arduino) et allumer la diode Lien [fourni le 22/02/2016]
Planning Prévisionnel
| Semaines | du 25/01 au 31/01 | du 1/02 au 7/02 | du 8/02 au 14/02 | du 15/02 au 21/02 | du 22/02 au 25/02 |
|---|---|---|---|---|---|
| Étapes | Etude bibliographique | Détection pour chaque boitier journalier si il a été enlever du support et détection si la bonne pilule a été récupéré par le patient | Programmation et interfaçage des différentes shields avec le microcontrôleur | Test pour correction d'erreur et amélioration | Rédaction du rapport de projet et Préparation à la soutenance |
Tableau de bord
Boîtes journalières
Chaque boîte sera équipée d'un petit micro-processeur, de 4 LED, 1 résistance, une grosse capacité, 5 aimants. Par les 5 aimants vont transiter :
- Le Vc+ correspondant à la tension pour charger la capacité et permettre à l'éclairage de fonctionner pour quelques minutes.
- Le Vp correspondant à la tension envoyée pour détecter la présence de la boîte
- La masse GND
- Les entrées p0 et p1 pour connaître la LED à allumer.
Nous aurons donc les cas suivants :
| Inputs | Vc+ | Vp | p0 | p1 | GND |
|---|---|---|---|---|---|
| Pilulier repos/Détection boîte | 0 | 1 | X | X | GND |
| Heure médicaments | 1 | 0 | 0/1 | 0/1 | GND |
| Après quelques seconde de charge/Détection boîte | 0 | 1 | X | X | GND |
Pour les inputs p0 et p1, elles dépendront du moment de la prise des médicaments :
| Moment | p0 | p1 |
|---|---|---|
| Matin | 0 | 0 |
| Midi | 0 | 1 |
| Soir | 1 | 0 |
| Coucher | 1 | 1 |
Après configuration de l'ATTiny13 via Arduino, les tests ont avérés que cette méthode était limitée. En effet, il y a 4 LEDs et 4 combinaisons, ce qui rend compliqué de laisser un cas "auncune LED allumée".
Une autre solution a été adoptée :
- La pin Vcc pour l'alimentation en 5v
- La pin GND pour la masse
- La pin PB0 pour la LED 4
- La pin PB1 pour la LED 3
- La pin PB2 pour la LED 2
- La pin PB3 pour la LED 1
- La pin PB4 pour une liaison UART
Principe de L'UART : Le signal envoyé sur la pin PB4 est à l'état par défaut. Dès qu'on détecte un front descendant, on récupère à chaque tic d'horloge la valeur haute ou basse du signal entrant en pin PB4. Nous avons décidé de faire une vérification sur les 4 premiers bits envoyés et de donner la LED à allumer sur les 4 derniers bits. On peut voir un chronogramme ci-contre.
On utilise un AVRISP pour l'ATTiny13 comme on peut le voir sur l'image.
Voici le code pour le programmer:
#define F_CPU 10000000
#include <avr/io.h>
#include <util/delay.h>
int main (void){
DDRB |= 0x0F;
int i, code=0;
while(1){
while((PINB & 0x10) == 0x10){}
_delay_us(1000);
for(i=128 ; i>=1 ; i=i/2){
code = (((PINB & 0x10)/16) * i) + code;
_delay_us(2000);
}
if((code & 0xF0) == 0x50){
PORTB |= (code - 0x50);
}
else {
code = 0;}}}
On réalise le branchement puis pour tester, on programme l'arduino micro comme ceci :
int state10;
int laststate10=0;
void setup(){
pinMode(11, OUTPUT);
pinMode(12, OUTPUT);
pinMode(13, INPUT);
digitalWrite(11, HIGH);
digitalWrite(12, HIGH);}
void loop(){
state10 = digitalRead(13);
if ((state10 != laststate10)){
if ((state10 == 0)){
digitalWrite(11,LOW);
Serial.print(digitalRead(11));
delayMicroseconds(2000);
digitalWrite(11,HIGH);
Serial.print(digitalRead(11));
delayMicroseconds(2000);
digitalWrite(11,LOW);
Serial.print(digitalRead(11));
delayMicroseconds(2000);
digitalWrite(11,HIGH);
Serial.print(digitalRead(11));
delayMicroseconds(2000);
digitalWrite(11,LOW);
Serial.print(digitalRead(11));
delayMicroseconds(2000);
digitalWrite(11,LOW);
Serial.print(digitalRead(11));
delayMicroseconds(2000);
digitalWrite(11,HIGH);
Serial.print(digitalRead(11));
delayMicroseconds(2000);
digitalWrite(11,LOW);
Serial.print(digitalRead(11));
delayMicroseconds(2000);
digitalWrite(11,HIGH);
Serial.println(digitalRead(11));}}
laststate10 = state10;}
On attend un front descendant sur le pin 13, qu'on réalisera en débranchant le câble déjà branché sur celle-ci. Les 4 premiers bits 0101 sont pour la vérification d'un envoie. Sur les 4 suivants, nous avons 0010 ce qui veut dire que le PB1 sera en état haut et que nous allumerons la LED3. Le dernier bit est pour remettre par défaut en état haut.
Voici un GIF du résultat des tests.
Le support
Le support, lui, est composé de l’Arduino micro, du RTC, du RFduino ainsi que le système de détection Infrarouge. Selon le schematic suivant, on crée un faisceau Infrarouge à l’aide d’un diode IR et d’une photorésistance de même longueur d’onde pour éviter les interferances avec la lumière ambiante. Lorsque la photorésistance capte l’Infrarouge de la diode, un micro courant circule et permet de rendre le transistor NPN passant. Le potentiel au noeud « S » est donc 0. Au contraire, s’il y a présence d’un obstacle empêchant la photorésistance de capter le rayon Infrarouge, le transistor de peut être activé et est donc bloquant. Le potentiel au noeud « S » est 5V (‘1’ logique). On peut ainsi détecter la présence d’objet entre les deux composants, dans le cas présent, un quelconque médicament. Nous avons réalisé le test avec le circuit suivant :
On programme l’Arduino micro pour allumer la LED en présence d’un obstacle avec le code suivant :
const int IRDetectorPin = 2;
const int ledPin = 13;
void setup() {
pinMode(ledPin, OUTPUT);
pinMode(IRDetectorPin, INPUT);
}
void loop(){
digitalWrite(ledPin, digitalRead(IRDetectorPin));
}
Voici deux photos qui confirment le fonctionnement de cette méthode :
Les diodes IR et photorésistances devant être de part et d’autre de la boîte, il était nécessaire de réaliser deux cartes PCB que nous avons réalisées.
App Android
L’application Android est complémentaire de la partie Arduino. Il est possible à l’aide de cette application d’établir un suivi permanent du pilulier connecté. La communication entre l’application et le capteur s’effectue à travers le protocole Bluetooth Low Energy. L’application se compose d’une seule interface qui peut exécuter plusieurs activités en arrière-plan. L’interface se décompose en 4 parties, chacune ayant une fonction précise. La première partie correspond à la communication Bluetooth. On y aperçu trois boutons qui se succèdent dont chacun correspond à une étape de la mise en communication avec le RFduino :
- Enable Bluetooth permet de mettre en marche le BLE du téléphone si celui-ci est éteint.
- Scan permet de détecter le RFduino.
- Connect met en connexion et récupère les informations de la balise BLE.
La seconde partie a pour rôle d’enregistrer le numéro du médecin ou du responsable de l’utilisateur. L’enregistrement du numéro est nécessaire à l’envoi d’un SMS si le patient n’a pas pris son médicament dans un temps spécifié.
Nous arrivons ensuite à la troisième partie qui renseigne le suivi hebdomadaire du patient. On retrouve les 4 zones de journées comme l’est indiqué sur les piluliers standards, à savoir le matin, le midi, le soir et la nuit ; ainsi que la date en temps réel. Pour chaque période de la journée, on indique l’état du compartiment du pilulier correspondant à la période. Cet état est représenté par un point pouvant avoir 4 couleurs différentes selon le contexte :
- Si un point jaune apparait, le médicament à ingurgiter actuellement est dans le compartiment correspondant à ce moment de la journée.
- Si un point vert apparait, le médicament présent dans ce compartiment devra être ingurgité plus tard dans la journée.
- Si un point rouge apparait, le médicament dans ce compartiment a oublié d’être ingurgité plus tôt dans la journée.
- Si un point noir apparaît, il n’y a pas de médicament à prendre dans ce compartiment ou il a déjà été pris.
Enfin dans la dernière partie, on retrouve un bouton Stop Alarm qui désactive l’alarme. Celui-ci se déclenche lorsqu’on passe à une nouvelle période de la journée. Plus précisément, lorsqu’on passe du matin au midi. Si l’utilisateur n’a pas désactiver lui-même l’alarme, celui-ci s’arrête automatiquement au bout d’une période spécifié et entraîne l’envoi d’un SMS.
A savoir que l’interface intègre un conteneur ScrollView qui permet le défilement du contenu et donc l’accès à l’ensemble de différentes parties de l’application. Explication du firmware de l’application Android Le développement de l’application Android a été long mais instructif. En effet, nous n’avons jamais développé d’application Android et codé en Java auparavant. Nous nous sommes basé alors sur les nombreux tutoriels accessibles en ligne pour réaliser cette application et acquérir quelques bases en Java et développement Android. L’application a été développée en Java sous le logiciel Android Studio. Son développement s’est déroulé en plusieurs étapes : 1. Mise en place de la communication Bluetooth Low Energy entre le smartphone et le RFduino (module BLE du socle). 2. Développement de l’interface de suivi hebdomadaire 3. Programmation de l’alarme et de l’envoi du SMS d’alerte
Communication Bluetooth Low Energy
Afin de mettre en place de la communication entre le smartphone et le pilulier, nous nous sommes basé sur le code opensource disponible sur le site officiel GitHub. Le Bluetooth Low Energy est un protocole de communication rapide qui demande peu d’énergie pour son fonctionnement. C’est le système de communication recommandé et primordiale pour les objets connectés du fait de la nécessité d’avoir des composants à faible consommation énergétique. La communication est construite selon un profil définit la manière dont les périphériques transmettent leurs données aux appareils (Generic Attribute Profile) en utilisant des concepts appelés Services et Characteristics. 16 Les Services peuvent contenir une collection de Characteristics. Les Characteristics sont des flags de propriété ou les valeurs de capteurs. Chaque Service et Characteristic a son identifiant (UUID) propre. Le profil GATT propose seulement des connections exclusives ; c’est-à-dire que les périphériques BLE ne peuvent être connecté qu’à un seul smartphone à la fois.
Ici, nous nous retrouvons avec :
- Generic Attribute Profile Client pour l’application.
- Generic Attribute Profile Server pour le pilulier connecté (RFduino) avec un service propre et plusieurs caractéristiques (communication I2C, UART...).
Suivi Hebdomadaire
L’application Android reçoit les données à travers l’objet BroadcastReceiver qui par sa fonction onReceive va recevoir les events que reçoit l’application dans son Activity principal. Lorsqu’un event spécifique, par exemple dans notre cas lorsque une donnée est disponible par Bluetooth, le code correspondant du BroadcastReceiver s’exécute dès que possible. Pour obtenir un suivi hebdomadaire en temps réel, nous avons utilisé la fonction runOnUiThread qui exécute l'action spécifiée sur le Thread d'interface utilisateur de manière immédiate étant donné que dans notre situation le Thread courant correspond au Thread d'interface utilisateur. L’appel de cette fonction, une fois les données du RFduino reçu et récupéré dans le BroadcastReceiver, permet d’identifier les quatre périodes de la journée (matin, midi, soir et nuit) et d’adapter automatiquement de manière visuel (jaune, vert, rouge, noir) selon les données reçus (respectivement : 1, 2, 3, 4).
Alarme et envoi du SMS d'alerte
L’alarme est déclenchée suite à la réception, via la communication Bluetooth, de la commande « alarme ». Afin de mettre en place l’alarme, nous avons exploité les services d’alarme du système Android, AlarmManager class, qui permet de planifier une activité à être exécuté à un moment donné dans l'avenir. Pour cela, nous avons planifié deux alarmes : 1. Une première alarme qui se répète toutes les 3 secondes. 2. Une deuxième alarme qui permet d’arrêter la première alarme au bout d’une heure. 17 Pour que l’alarme soit toujours exécutée en background de l’application et même à sa fermeture, nous avons utilisé le système d’évènement, BroadcastReceiver object, combiné à la création d’un nouveau Thread ou Tâche dans le service sur lequel dirige le BroadcastReceiver. Ce Thread utilise les fonctionnalités de MediaPlayer, qui permet le contrôle de la lecture de flux audio. De plus, au bout de l’activation de la seconde alarme, si la première alarme n’est pas déjà désactivée, on envoie un SMS d’alerte au numéro enregistré au préalable, à partir du service SmsManager d’Android. Ce service permet de faire appel à l’application intégrée à Android « Message », et d’envoyer un SMS. Enfin, si l’utilisateur appui sur le bouton Stop Alarm, la fonction appelé va d’abord arrêter la future planification de la prochaine sonnerie de l’alarme, puis annuler l’appel de l’event BroadcastReceiver.
Fichiers Rendus
Rapport
Codes
Fichier:Code Android PillBox.zip
