FR 2744817 A1 19970814 FR 9601564 A 19960208 La présente invention concerne les dispositifs médicaux implanta- bles actifs et les appareils appelés "programmateurs" destinés à échan- ger des données avec ces derniers. L'invention sera principalement décrite dans le cas d'un stimula- teur cardiaque, mais il ne s'agit là que d'un exemple de mise en oeuvre de l'invention, qui est applicable de façon beaucoup plus générale à une très grande variété de "dispositifs médicaux implantables actifs" tels que définis par la Directive 90/385/CE du 20 juin 1990 du Conseil des Communautés Européennes, définition qui inclut, outre les stimula- teurs cardiaques, les défibrillateurs et/ou cardioverteurs, les pompes de diffusion de substances médicales, les implants cochléaires, les cap- teurs biologiques implantés, etc. Ces dispositifs (ci-après désignés simplement "implants"), une fois mis en place, sont programmés de l'extérieur au moyen d'une console appelée "programmateur" généralement constitué d'un micro-ordina- teur équipé d'une tête de programmation placée en regard du site de l'implant. Le programmateur peut lire par voie électromagnétique ("té- lémétrie") des données conservées dans l'implant (par exemple des pa- ramètres de fonctionnement, des signaux biologiques qui ont été enre- gistrés, etc.) et, d'autre part, envoyer éventuellement certaines données vers cet implant afin de pouvoir le "reprogrammer", c'est-à-dire en mo- difier les paramètres de fonctionnement. Ces programmateurs sont tous spécifiques à un type d'implant, ou à une famille d'implants d'un même fabricant, de sorte que la mise sur le marché d'un nouvel implant impose généralement au fabricant une mise à jour correspondante des programmateurs. En outre, même en l'absence de mise sur le marché d'un nouvel implant, des perfectionne- ments sont régulièrement apportés, qui peuvent conduire à une mise à jour du logiciel du programmateur. Ces mises à jour sont particulièrement délicates. En effet, pour des raisons évidentes de sécurité, elles doivent être réalisées selon un protocole très strict: visite dans chaque centre, changement du programme par une personne qualifiée, récupération des anciens programmes, rédaction et signature de documents de certi- fication, etc. Ces procédures sont lourdes et onéreuses, de sorte que l'on évite de les appliquer trop souvent (par exemple à l'occasion de modifi- cations mineures du logiciel). En outre, les procédures de sécurité, pour complètes qu'elles soient, n'éliminent pas totalement le risque d'une absence de mise à jour (d'un programmateur qui ne serait pas localisé par le fabricant), ni le problème des périodes de transition, et surtout l'utilisation inappropriée d'une ancienne version du logiciel. L'un des buts de l'invention est de remédier à ces difficultés, en proposant un nouveau concept de programmateur dont le logiciel puisse être mis à jour de façon entièrement automatique, sans inter- vention humaine et en s'affranchissant donc des lourdeurs, des coûts et des risques liés aux procédures actuelles. L'invention implique la mise en oeuvre de la notion d"'objet" au sens logiciel du terme, c'est-à-dire d'un ensemble d'éléments, au sens le plus large du terme (données, constructeurs, destructeurs et métho- des), permettant de gérer et d'afficher des données de manière très structurée. En particulier, l'accès aux données ne s'effectue en général qu'au travers de méthodes propres à l'objet, ce qui permet de protéger ce derniers contre les écritures hors limite et de rendre le logiciel par- ticulièrement fiable. Le concept d'héritage" facilite également la con- ception du logiciel, un objet pouvant hériter d'un autre, ce qui lui per- met d'utiliser directement les méthodes de ce dernier. Des exemples d'objets logiciels et de leurs applications au domaine des stimulateurs cardiaques seront donnés plus bas. De façon générale, on pourra se référer à la littérature sur ce sujet, par exemple l'ouvrage de Max Bouché, La démarche objet - Concepts et outils, AFNOR, 1994, ainsi que la documentation des langages de pro- grammation "orientés objet" tels que le C++ qui est un langage typique de programmation orientée objet. Essentiellement, l'idée de l'invention consiste à (i) stocker dans l'implant lui-même les objets logiciels permettant de définir l'affichage, le traitement et la programmation de ses données par un programma- teur externe, (ii) faire comparer par le programmateur la liste des ob- jets que ce programmateur contient à la liste des objets que l'implant contient, et (iii) télécharger de l'implant vers le programmateur les ob- jets manquants ou plus récents pour mettre à jour le logiciel du pro- 3 2744817 grammateur. Cette manière de procéder, que l'on décrira plus en détail par la suite, procure quatre avantages majeurs par rapport à l'art antérieur: 1 sécurité: tout programmateur équipé d'un noyau de base minimal, c'est-à-dire des objets permettant d'établir la communication avec un implant et de gérer les liaisons entre objets, pourra lire tout im- plant, même si celui-ci a été développé bien plus tard que le pro- grammateur. L'opérateur ne peut donc plus se retrouver dans l'im- possibilité de lire et reprogrammer des fonctions d'un modèle ré- cent d'implant, dès lors qu'il dispose d'un programmateur compa- tible, même ancien. De plus, chaque paramètre dispose de son pro- pre mode de gestion, défini par un logiciel dans l'implant lui-même, et les contrôles de saisie de ces paramètres par l'opérateur ne peu- vent pas être faux, puisqu'ils ne sont plus contrôlés par un objet préexistant du programmateur mais par un objet issu de l'implant lui-même. 2 économie: les frais de mise à jour des programmateurs sont consi- dérablement réduits et ne s'imposent que pour les changements importants de matériel (nouvelles générations de programma- teurs). On évite ainsi tous les frais des procédures de sécurité clas- siques qui accompagnent ces changements: fabrication de disquet- tes et de guides de mise à jour, déplacement d'un opérateur qualifié sur chaque site, signature d'un registre attestant la mise à jour, ré- cupération des anciennes disquettes, etc. 3 simplification de la programmation: l'évolution du logiciel du pro- grammateur s'effectue automatiquement et de façon "transparen- te" pour l'utilisateur. Seul des fonctions très générales pourront compléter la gestion des objets de base, et la liste des objets fournis au départ sera complétée par les objets définis dans chaque nouvel implant. 40 standardisation: la souplesse d'emploi de l'invention permet main- tenant d'envisager la création d'un standard permettant à tout pro- grammateur de lire n'importe quel implant, quel que soit son mo- dèle ou son fabricant. Chaque fabricant pourra définir l'aspect gra- phique de son programmateur, les possibilités de gestion des don- nées, les calculs supplémentaires, etc. de façon à garder une cer- taine originalité, mais, les objets de base étant définis de manière identique, la lecture d'un implant "étranger" devient parfaitement possible. On peut ainsi envisager la réalisation de programmateurs universels, ce qui était exclu jusqu'à présent non seulement pour des raisons de coûts et de complexité, mais également pour des rai- sons de sécurité (risques d'incompatibilités imprévues). Plus précisément, on peut définir l'invention par un ensemble com- prenant, d'une part, un implant du type dispositif médical implantable actif et, d'autre part, un programmateur externe d'implant, ensemble caractérisé en ce que: - le programmateur comporte un logiciel composé d'un ensemble d'objets logiciels, - l'implant comporte une mémoire contenant, d'une part, des don- nées de paramétrage du fonctionnement de l'implant et, d'autre part, un ensemble d'objets logiciels nécessaires au fonctionnement d'un programmateur en relation avec lesdites données de paramé- trage de l'implant, - le programmateur et l'implant comportent des moyens pour établir entre eux une liaison bidirectionnelle d'échange d'informations per- mettant notamment le transfert sélectif de tout ou partie desdites données et desdits objets de l'implant vers le programmateur, et - le programmateur comporte des moyens de mise à jour pour com- mander le téléchargement depuis l'implant d'au moins une partie desdits objets contenus dans la mémoire de ce dernier et ajouter et/ou substituer ces objets à ceux du logiciel du programmateur. Avantageusement, les moyens de mise à jour du programmateur sont des moyens pour: établir, par lecture de la mémoire de l'implant, une liste des objets qui s'y trouvent avec leur version respective; com- parer cette liste à celle des objets du logiciel du programmateur; com- mander le téléchargement depuis l'implant des objets absents du logi- ciel du programmateur et ajouter ces objets au logiciel; et/ou comman- der le téléchargement depuis l'implant des objets présents dans le logi- ciel du programmateur mais dont la version est antérieure à celle qui se trouve dans l'implant, et remplacer ces objets dans le logiciel. L'invention couvre également, en tant que produit indépendant, l'implant ou bien le programmateur d'implant présentant les caracté- ristiques précitées. On va maintenant décrire un exemple de mise en oeuvre de l'in- vention. Comme on l'a indiqué plus haut, le logiciel du programmateur, tout comme celui de l'implant, est organisé en "objets logiciels". Dans le cas d'un stimulateur cardiaque, on peut représenter par un objet chaque élément du stimulateur qui est programmable ou simple- ment affichable sur l'écran d'un programmateur. Ainsi, une courbe donnant la fréquence cardiaque en fonction du temps peut être représentée par un objet particulier Fréquence-car- diaque, qui hérite d'un objet plus général que l'on peut appeler Cour- be et comprenant une suite de données correspondant à une courbe, avec son format, ses échelles en abscisse et en ordonnée, son titre, une méthode d'affichage, une méthode d'impression, etc. Le programmateur, quant à lui, dispose d'un objet Gestionnaire- de-liaison qui peut appeler les données correspondant à la fréquence cardiaque stockées dans le stimulateur en appliquant les protocoles de transfert, compression/décompression de données, etc. nécessaires. Le programmateur pourra ensuite afficher une fenêtre présentant ces données, à l'aide de l'objet Courbe permettant toutes les fonctions courantes: zoom, défilement dans la fenêtre, mesures à l'aide de cur- seurs, etc. Le concept de l'invention repose sur trois hypothèses fondamen- tales: - le logiciel du programmateur est "ouvert", c'est-à-dire qu'il peut s'enrichir en recevant et incorporant de nouveaux objets concer- nant l'affichage des données, le traitement de ces données et la programmation de l'implant. Ces objets peuvent provenir soit de l'implant (c'est la caractéristique de l'invention) soit d'une disquet- te ou de tout autre support informatique de manière en elle-même classique, par exemple pour le chargement préalable de l'objet Gestionnaire-de-liaison. - l'implant stocke en lui-même tous les objets permettant de définir l'affichage, le traitement et la programmation des données conte- nues dans cet implant. On verra plus loin que la taille de ces objets peut être relativement réduite, dans la mesure o les objets dont ils héritent (par exemple l'objet Courbe définissant l'affichage et la gestion d'une courbe en général par le programmateur) sont déjà présents dans le programmateur. - les versions des objets sont datées (par exemple par un numéro de version) et toute version plus récente doit remplacer dans le pro- grammateur une version plus ancienne. Les développements des objets s'effectuent en imposant une compatibilité ascendante, c'est- à-dire qu'une version plus récente reste compatible avec tous les échanges de données relatives aux versions plus anciennes. Au début de l'échange de données entre implant et programma- teur, ce dernier appelle systématiquement un bloc appelé Liste-des-ob- jets qui est un répertoire des objets disponibles dans l'implant avec leur version. Il compare alors les codes de ces objets avec ceux qu'il con- naît (liste des objets disponibles dans le logiciel du programmateur, gérée dynamiquement et sauvegardée dans un fichier de configura- tion). Si un ou plusieurs de ces objets est inconnu du programmateur, il appelle alors par le Gestionnaire-de-liaison une procédure de téléchar- gement de ces objets afin de compléter son logiciel et l'adapter ainsi à l'implant. Cette procédure de téléchargement et de mise à jour consiste, pour chaque objet inconnu, à faire fonctionner le Gestionnaire-de- liaison, dont hérite cet objet; le Gestionnaire-de-liaison envoie le numéro de l'objet au stimulateur qui, en retour, lui renvoie un bloc d'informations correspondant. Il en est de même pour les objets qui, bien que présents dans le lo- giciel du programmateur, correspondent à une version plus ancienne que celle contenue dans l'implant. Après cette phase, le programmateur peut appeler toutes les don- nées contenues dans l'implant, afficher les résultats souhaités, repro- grammer l'implant, etc. Ainsi, dans le cas d'un implant disposant de l'objet Fréquence-car- diaque lu par un programmateur ne le connaissant pas, celui-ci repère l'objet dans la Liste-des-objets fournie par le stimulateur. Il demande le transfert de l'objet et l'ajoute à ses bases de programme, l'appel au constructeur de l'objet permettant de réserver une zone mémoire pour recevoir ultérieurement la courbe de fréquence, la sélection d'une fenêtre d'affichage et l'initialisation de diverses variables. Le code de l'objet Fréquence-cardiaque vient alors s'ajouter à la liste dynamique des objets disponibles dans le logiciel du programmateur. Lorsque l'opérateur veut afficher la courbe, il appelle sur le pro- grammateur la fenêtre correspondante. Le programme teste alors la présence de la courbe en mémoire et, dans la négative, il engage une lecture des données de fréquence cardiaque mémorisées dans le stimu- lateur. La courbe s'affiche ensuite dans une fenêtre disposant des com- mandes classiques d'ajustage (gain, zoom, défilement), de mesure (cur- seurs) et éventuellement d'impression, ces diverses fonctions étant gé- rées par l'objet général Courbe déjà présent dans le programmateur. On va maintenant décrire deux exemples détaillés d'objets de sti- mulateur: un objet Fréquence-nominale (valeur fixe programmée) et un objet Fréquence-respiratoire (donnée évolutive au cours du temps). La description des objets peut être réalisée sous plusieurs formes, que l'on peut résumer à trois cas: code machine, code précompilé et métalangage: - Le code machine est trop lié au processeur pour permettre un usa- ge à long terme. - Le code précompilé (comme l'ancien "P-code") est extrêmement per- formant, pouvant décrire toutes les données et les méthodes des nouveaux objets. Il reste par contre d'un volume important, mal adapté aux implants de faible capacité. - Le métalangage ne fait que préciser la valeur des variables appar- tenant à des objets parents prédéfinis par le programmateur. Le volume des données est de ce fait extrêmement réduit. La plupart des données d'un implant peuvent se contenter d'une description sous forme d'un métalangage, mais le recours à un code précompilé doit pouvoir rester accessible pour l'intégration d'objets originaux. Dans l'exemple décrit ici, le langage choisi est un métalangage, qui procure une taille réduite des objets et une indépendance totale au lan- gage de programmation. Par contre, il ne peut faire que référence aux objets de base du programmateur, sans pouvoir les faire directement progresser. Les limites ne sont atteintes que lorsqu'un concept complètement nouveau ne pourra être intégré par ceux-ci, de sorte que le développement de ces objets de base doit être extrêmement bien réalisé pour éviter la survenue trop fréquente de ce genre d'incident qui impo- serait un mise à jour traditionnelle des logiciels des programmateurs. Objet Fréquence-nominale La fréquence nominale, qui est un paramètre essentiel de tout sti- mulateur cardiaque, peut être représenté par un objet décrit de la ma- nière suivante: - numéro d'obiet: code unique affecté à l'objet, par exemple sur huit caractères (deux lettres pour le fabricant, quatre lettres pour l'objet et deux chiffres pour le numéro de version), qui permet de choisir un code à la fois univoque et facilement déchiffrable. - objet ancêtre: un numéro d'objet fournit le code de l'objet ancêtre, qui réside dans ce cas dans le programmateur dès l'origine et qui permet de gérer tous les procédés d'affichage, de saisie, d'impres- sion et de stockage d'une valeur numérique. Cet objet hérite, bien sûr, au minimum, d'un objet plus général qui est le Gestionnaire- de-liaison. Comme il s'agit d'une programmation par pas prédéfi- nis, les valeurs sont codées en nombre de pas. Cette donnée occupe cinq caractères. Les données suivantes paramètrent l'objet ancêtre - phrase descriptive (100 caractères) accompagnant la valeur numé- rique à l'affichage (par exemple vingt caractères, soit cent caractè- res au total pour cinq langues différentes). - unité de mesure (10 caractères). - valeur du pas. du minimum, du maximum et de la valeur nominale (16 caractères): les limites résident dans l'objet ancêtre afin d'em- pêcher la saisie d'une valeur numérique hors limite. Ces limites sont mises à jour par le maximum et le minimum et la valeur no- minale remplace la valeur présente dans l'objet lors de l'appel d'une méthode de "mise au nominal" dont héritent tous les objets programmables. Le pas peut être défini en valeur constante, loga- rithmique ou inverse de façon à répondre aux divers cas de figures présents dans les stimulateurs. - fenêtre de référence (5 caractères): chaque donnée doit être affi- chée dans l'un des écrans du programmateur, qui peut contenir lui- même une à plusieurs fenêtres. Chaque fenêtre est définie par le stimulateur avec au moins un titre, un format (une colonne, deux colonnes, etc.) et des actions que l'on peut mener (déplacement, appel à une lecture momentanée ou continue du stimulateur, menu local, etc.). - position dans la fenêtre de référence (5 caractères): colonne, hau- teur, etc., qui peuvent se résumer sous la forme d'un nombre à cinq chiffres: le premier donne la colonne, les trois suivants un ordre de priorité par rapport aux autres; le noyau de gestion d'écran les place alors de haut en bas par ordre de priorité. L'ensemble de ces données occupent donc 56 caractères en mode mono- lingue et 136 caractères en mode multilingue. Objet Fréquence-respiratoire Dans le cas d'un stimulateur analysant la fréquence respiratoire, celle-ci peut être stockée sur des périodes de plusieurs heures, plu- sieurs jours et même plusieurs mois. L'objet peut être décrit en méta- langage de la façon suivante: - numéro d'objet (8 caractères): voir ci-dessus. - objet ancêtre. (5 caractères): Il s'agit d'un générateur de courbe en ft) possédant une échelle verticale et une échelle horizontale, un format de données et un mode d'affichage (trait, minimum-maxi- mum, etc.), des méthodes de changement d'échelle, d'affichage et d'impression. Cet objet fait partie des objets résidant dans le pro- grammateur. Les données suivantes paramètrent l'objet ancêtre: - phrase descriptive (20 caractères par langue, soit 100 caractères en mode multilingue): voir ci-dessus. - unité de mesure (10 caractères). - format des données (5 caractères): suite d'entiers (8, 16, 24 ou 32 bits), de réels, etc. Ce format est lui-même un objet résidant qui hérite du Gestionnaire-de-liaison afin de le rendre capable de gé- rer le transfert des données entre stimulateur et programmateur. - période de temps séparant chaque donnée, (4 caractères): période en millisecondes, codée par un mot de quatre octets permettant ainsi une dynamique de 1 ms à 1137 heures. - description de l'échelle verticale (12 caractères): valeur basse, va- leur haute, pas. - fenêtre de référence (5 caractères): comme dans le cas de la fré- quence nominale. - position dans la fenêtre de référence (5 caractères): comme pour la fréquence nominale, l'affichage du graphique se positionne selon un certain ordre de priorité; le nombre de colonnes et le nombre d'éléments affichés sont pris en compte par la fenêtre pour accorder à chacun le maximum de place disponible: ainsi, une fenêtre à une colonne ne contenant qu'une courbe affiche celle-ci sur toute la sur- face disponible, une fenêtre à deux colonnes et quatre courbes affi- che chacune sur un quart de la surface totale, etc. L'ensemble de ces données occupe donc 74 caractères en mode mo- nolingue et 154 caractères en mode multilingue. On peut décrire ainsi de la même manière tous les paramètres de fonctionnement du stimulateur. Dans le cas d'un stimulateur cardiaque relativement compliqué, comprenant 20 courbes en mémoire et 50 paramètres programmables, la taille totale des objets est ainsi, en mode multilingue, de 50 x 136 = 6800 caractères pour les paramètres et 20 x 154 = 3080 caractères pour les courbes, soit un total de 9880 caractères, auxquels il faut ajouter le bloc Liste-des-objets qui sera transmis au programmateur préalable- ment à toute mise à jour, soit 70 x 8 = 540 octets. La taille totale réservée au stockage des objets dans le stimulateur n'atteint donc qu'à peine 10 Ko environ dans les cas les plus complexes (par exemple un stimulateur DDD asservi de dernière génération) et ces éléments peuvent être aisément introduits dans une puce de type ROM du stimulateur, sans entraîner de surconsommation tant que cette puce n'est pas activée. REVENDICATIONS 1. Un ensemble comprenant, d'une part, un implant du type dispo- sitif médical implantable actif et, d'autre part, un programmateur ex- terne d'implant, caractérisé en ce que: - le programmateur comporte un logiciel composé d'un ensemble d'objets logiciels, - l'implant comporte une mémoire contenant, d'une part, des don- nées de paramétrage du fonctionnement de l'implant et, d'autre part, un ensemble d'objets logiciels nécessaires au fonctionnement d'un programmateur en relation avec lesdites données de paramé- trage de l'implant, - le programmateur et l'implant comportent des moyens pour établir entre eux une liaison bidirectionnelle d'échange d'informations per- mettant notamment le transfert sélectif de tout ou partie desdites données et desdits objets de l'implant vers le programmateur, et - le programmateur comporte des moyens de mise à jour pour com- mander le téléchargement depuis l'implant d'au moins une partie desdits objets contenus dans la mémoire de ce dernier et ajouter et/ou substituer ces objets à ceux du logiciel du programmateur. 2. L'ensemble de la revendication 1, dans lequel les moyens de mise à jour du programmateur sont des moyens pour: établir, par lecture de la mémoire de l'implant, une liste des ob- jets qui s'y trouvent avec leur version respective, comparer cette liste à celle des objets du logiciel du programma- teur, commander le téléchargement depuis l'implant des objets ab- sents du logiciel du programmateur et ajouter ces objets au lo- giciel, et/ou commander le téléchargement depuis l'implant des objets pré- sents dans le logiciel du programmateur mais dont la version est antérieure à celle qui se trouve dans l'implant, et remplacer ces objets dans le logiciel. 3. Un implant du type dispositif médical implantable actif pour un ensemble selon la revendication 1, implant caractérisé en ce qu'il com- porte: - une mémoire contenant, d'une part, des données de paramétrage du fonctionnement de l'implant et, d'autre part, un ensemble d'ob- jets logiciels nécessaires au fonctionnement d'un programmateur en relation avec lesdites données de paramétrage de l'implant, ces objets étant susceptibles d'être émis vers le programmateur pour compléter ou mettre à jour le logiciel de ce dernier. 4. Un programmateur externe d'implant de type dispositif médical implantable actif, pour un ensemble selon la revendication 1, program- mateur caractérisé en ce qu'il comporte: - un logiciel, composé d'un ensemble d'objets logiciels, - des moyens pour établir avec l'implant une liaison bidirectionnelle d'échange d'informations permettant notamment le transfert sélec- tif, de l'implant vers le programmateur, de tout ou partie de don- nées de paramétrage du fonctionnement de l'implant et d'objets lo- giciels nécessaires au fonctionnement d'un programmateur en rela- tion avec lesdites données de paramétrage de l'implant, et - des moyens de mise à jour pour commander le téléchargement de- puis l'implant d'au moins une partie desdits objets contenus dans la mémoire de ce dernier et ajouter et/ou substituer ces objets à ceux du logiciel du programmateur. 5. Le programmateur de la revendication 4, dans lequel les moyens de mise à jour sont des moyens pour: établir, par lecture de la mémoire de l'implant, une liste des ob- jets qui s'y trouvent avec leur version respective, 30. comparer cette liste à celle des objets du logiciel du programma- teur, commander le téléchargement depuis l'implant des objets ab- sents du logiciel du programmateur et ajouter ces objets au lo- giciel, et/ou 35. commander le téléchargement depuis l'implant des objets pré- sents dans le logiciel du programmateur mais dont la version est antérieure à celle qui se trouve dans l'implant, et remplacer ces objets dans le logiciel. 6. Un ensemble selon la revendication 1, ou un implant selon la re- vendication 3, ou un programmateur externe d'implant selon la reven- dication 4, dans lequel lesdits objets logiciels comprennent chacun au moins un identifiant d'objet, un identifiant de version et un bloc d'ins- tructions de programme.