FR 3059118 A1 20180525 FR 1661257 A 20161121 1 DISPOSITIF ET UN PROCEDE DE GENERATION D'UNE BASE DE DONNEES RELATIVE AUX MEDICAMENTS Domaine technique La présente invention concerne de manière générale le traitement de données, et en particulier un dispositif et un procédé de génération d'une base de données relative aux médicaments à partir d'un modèle ontologie de médicament. Elle concerne également un dispositif et un procédé d'analyse basé sur une telle base de données. Art antérieur et problème technique Les avancées majeures en matière de « BIG Data » (« Données Massives ») sont en train de révolutionner le milieu de la santé. L'un des enjeux en matière de santé concerne notamment le développement des outils d'analyse relatifs aux médicaments tels que des outils d'aide à la prescription médicale. De tels outils s'appuient sur des bases de connaissance ou bases de données propres à stocker des données médicales et à délivrer des données relatives à une prescription médicale, de manière structurée en réponse à des requêtes. De telles bases de données peuvent être utilisées également dans des outils de pharmacovigilance pour détecter, évaluer et prévenir les effets indésirables liés aux médicaments. Les informations relatives aux effets indésirables d'un ensemble de médicaments peuvent être collectées dans une phase amont d'observation menée pendant des étapes expérimentales, ou pendant une phase avale, par exemple lors de la commercialisation et de l'usage des médicaments. Ces informations peuvent être enregistrées au niveau de différentes sources de données en conformité avec des règles de terminologie standardisées. Ces sources peuvent alors être connectées aux bases de connaissance utilisées dans les outils d'aide à la décision en matière de prescription médicale. Il existe aujourd'hui un grand nombre de sources de données concernant le 3059118 2 médicament, partout dans le monde. Ces données sont produites par des organismes différents (Agence nationale de sécurité du médicament et produits de santé- ANSM, Haute Autorité de Santé - HAS, Assurance Maladie etc...), selon des approches variées. Dans de telles sources de données, les données sont organisées 5 et groupées en fonction de règles de classifications et de terminologies spécifiques. Ces sources de données présentent également une hétérogénéité à différents niveaux. D'autres sources de données moins formalisées sont également connues. Elles sont issues par exemple des réseaux sociaux et des forums de discussions sur la 10 santé, et peuvent être exploitées pour différents usages. Des classifications internationales sont également connues. De telles classifications sont communes à tous les pays mais existent dans des versions différentes, comme par exemple la classification Anatomical Therapeutic Chemical - ATC, éditée par l'Organisation mondiale de la Santé mais utilisée et adaptée dans 15 certains pays (Renning et al, 2000). Ainsi les sources de données existantes en matière de médicament répondent à des règles de classification, de formalisme et de terminologie très hétérogènes, ce qui complexifie l'exploitation de ces sources multiples par une même base de connaissance, par exemple pour une application d'aide à la prescription médicale. 20 Or l'exploitation de ces différentes sources de données relatives aux médicaments est fondamentale pour l'élaboration d'outils efficaces d'aide à la prescription médicale ou de support à la pharmacovigilance (détection de toute relation inattendue entre un médicament et un effet technique) par exemple. Elle peut être également utile pour une application à des outils de détection de nouvelles 25 interactions entre médicaments (Ayvaz S et al, 2015). Dans les approches connues de gestion des connaissances en matière de médicaments (Castano et al., 1997, Lawrence et al. 2001, Chawathe et al. 1994, Reynaud et al., 2003, Levy et al. ,2001), l'ontologie est utilisée pour représenter de façon formelle la signification des termes désignant les effets indésirables des 30 médicaments. Le caractère formel de la représentation dans une ontologie est adapté à l'exploitation automatisée des connaissances par les machines (Alani et al, 2003). Il permet l'intégration et le traitement de sources de données hétérogènes, 3059118 3 ainsi que la possibilité d'effectuer du raisonnement et de déduire de nouvelles relations ou de possibles alignements entre les sources de données existantes (Cruz et al, 2005). Il n'existe pas aujourd'hui de solutions efficaces pour intégrer et analyser 5 dynamiquement des sources de connaissances sémantiquement hétérogènes dans le domaine du médicament propres à être utilisées pour générer des recommandations en termes de prescription médicales, le cas échéant en tenant compte des interactions médicamenteuses. Il existe donc un besoin pour un dispositif et un procédé de gestion des données 10 provenant de multiples sources de données au format hétérogène, notamment pour une utilisation dans des outils d'aide à la prescription médicale ou d'analyse des effets des médicaments. Définition générale de l'invention 15 L'invention améliore la situation en proposant un dispositif de génération d'une base de données de médicaments pivot implémenté dans un système informatique, le dispositif comprenant : -une unité d'extraction configurée pour extraire les données d'un ensemble de 20 sources de données de médicaments élémentaires, les sources de données de médicaments élémentaires stockant des données relatives aux médicaments, chaque source de donnée élémentaire étant associée à une représentation des données ; - une unité de structuration configurée pour structurer les données extraites en 25 appliquant une ontologie pivot aux données extraites, l'ontologie pivot définissant des classes dérivées d'une ou plusieurs ontologies du médicament et des relations entre les classes, ce qui fournit des données structurées associées à un graphe représentant les relations entre les classes correspondant auxdites données structurées; 30 le dispositif étant configuré pour générer la base de données de médicament pivot en fonction du graphe et des données structurées, la base de données pivot stockant les données structurées. 3059118 4 Dans un mode de réalisation, l'unité d'extraction peut être configurée pour récupérer les données des sources de données élémentaires sous la forme d'un fichier de description dans un format initial, l'unité d'extraction comprenant un 5 premier parseur configuré pour parcourir les données de chaque fichier de description dans le format initial et une fonction de transformation pour transformer le fichier de description au format initial en un fichier de description dans un format cible, à partir des données parcourues. 10 L'unité de structuration peut comprendre un parseur configuré pour parcourir chaque fichier de description dans le format cible et pour effectuer une recherche d'informations de similarité entre les données parcourues et les classes de l'ontologie pivot, l'unité de structuration étant configurée pour appliquer l'ontologie pivot aux données parcourues en leur associant des classes et des relations en 15 fonction des informations de similarité, le graphe représentant les classes et les liens. Dans un mode de réalisation, l'ontologie pivot peut comprendre trois classes principales : 20 - Une classe principale « Ingredient » ; - Une classe principale « Médicament » ; et - Une classe principale « Médicament Clinique », les trois classes principales étant indépendantes. 25 La classe « Médicament » peut être avantageusement la classe supérieure et comprend un ensemble de classes filles. Les classes filles peuvent comprendre un ensemble de classes de type « clinique » et un ensemble de classe de type « commerciale ». 30 La classe supérieure « médicament » peut être reliée par une relation de type « possède » à la classe « Ingrédient ». En particulier, l'ontologie pivot peut être représentée selon un langage de requête 3059118 5 choisi. Il est en outre proposé un dispositif d'analyse lié aux médicaments, comprenant un serveur et la base de données pivot générée par le dispositif selon l'une des caractéristiques précédentes, le dispositif étant apte à interroger la base de données 5 pivot en réponse à au moins une requête reçu d'un dispositif client et à retourner le résultat au dispositif client. Le dispositif d'analyse lié aux médicaments peut être un dispositif d'aide à la prescription médicale. 10 En variante, le dispositif d'analyse lié aux médicaments peut être un dispositif d'analyse des interactions médicamenteuses. Il est en outre proposé un procédé de génération d'une base de données de 15 médicaments pivot implémenté dans un système informatique, le procédé comprenant les étapes consistant à : -sélectionner des sources de données de médicaments élémentaires stockant des données relatives aux médicaments, chaque source de donnée élémentaire étant associée à une représentation des données ; 20 -extraire les données desdites sources de données de médicaments ; - appliquer une ontologie pivot auxdites données extraites, la ontologie pivot définissant des classes dérivées d'une ou plusieurs ontologies du médicament et des relations entre lesdites classes, ce qui fournit des données structurées associées à un graphe représentant les relations entre les classes correspondant aux données 25 structurées; - générer une base de données pivot à partir du graphe et des données structurées, la base de données pivot stockant les données structurées. D'autres caractéristiques et avantages de l'invention apparaîtront à l'aide de la 30 description qui suit et des figures des dessins annexés dans lesquels: Description des figures 3059118 6 - la figure 1 est un schéma représentant le dispositif de génération de la base de données de médicament pivot, selon certains modes de réalisation ; - la figure 2 est un schéma représentant le dispositif de génération de la base de données de médicaments pivot, selon un mode de réalisation; 5 - la figure 3 est un schéma représentant le dispositif de génération de la base de données de médicaments pivot, selon une variante mode de réalisation; - la figure 4 montre une architecture simplifiée de l'ontologie utilisée par l'unité de structuration, selon certains modes de réalisation - la figure 5 montre des résultats obtenus en interrogeant la base de données pivot 10 selon un exemple de réalisation ; - la figure 6 représente les résultats de la comparaison de classes pour l'ACEBUTOLOL; - la figure 7 est un organigramme illustrant le procédé de génération de la base de données pivot selon certains modes de réalisation; 15 - la figure 8 est un organigramme illustrant le procédé de génération de la base de données pivot selon un mode de réalisation ; et - La figure 9 est une vue schématique d'un système informatique pouvant être utilisé pour implémenter le dispositif et le procédé de génération de la base de donnée pivot selon certains modes de réalisation. 20 Les annexes répertorient des exemples en pseudo-code mentionnés dans la description. Les dessins et les annexes à la description comprennent, pour l'essentiel, des 25 éléments de caractère certain. Ils pourront donc non seulement servir à mieux faire comprendre la description, mais aussi contribuer à la définition de l'invention, le cas échéant. Description détaillée 30 La présente invention propose un dispositif et un procédé de génération d'une base de données relative aux médicaments pour intégrer plusieurs sources hétérogènes à partir d'un modèle ontologique. 305 9 118 7 La figure 1 représente un exemple d'environnement dans lequel peut être implémenté le dispositif 100 de génération d'une base de données de médicaments pivot 10 (encore appelée base de données de médicaments « commune » ou 5 « transversale ») à partir de données extraites d'une pluralité de sources de données 2, chaque source de données stockant des données relatives à des médicaments selon un format ou une structure élémentaire spécifique à la source 2. Les sources de données 2 sont sélectionnées au préalable. 10 Telle qu'utilisée ici, une « base de données » encore appelée « base de connaissance » désigne un outil informatique permettant de stocker et de récupérer une ou plusieurs données parmi les données stockées en exécutant une requête définie en fonction d'un langage de requête. 15 La base de données pivot de médicaments 10 ainsi générée peut être utilisée dans un outil ou dispositif d'analyse relative aux médicaments 20 tel qu'un dispositif d'analyse des interactions médicamenteuses ou un outil d'aide à la prescription médicale. Le dispositif d'analyse 20 peut interagir avec des dispositifs clients 50 selon une architecture client/Serveur : les dispositifs clients 50 peuvent émettre des 20 requêtes selon un langage de requête (par exemple SPARQL) et/ou un protocole choisi via une interface graphique utilisateur 60. En réponse à ces requêtes, le serveur 200 du dispositif d'analyse 20 peut interroger la base de données commune 10 et générer un affichage des résultats qui lui sont renvoyés via l'interface graphique 60. Dans les applications de l'invention de type dispositif d'analyse des 25 interactions médicamenteuses (pharmacologie), l'affichage des résultats peut être généré sous la forme de diagrammes et/ou de données par exemple. Dans les applications de l'invention de type outil d'aide à la prescription médicale, l'affichage des résultats peut être généré sous la forme d'un fichier modifiable au format prescription médicale, l'utilisateur du dispositif client (médecin généraliste ou 30 spécialiste) pouvant modifier ou compléter la prescription avant de la finaliser. La base de données commune 10 peut être associée à un système de gestion de base de données pour contrôler la base de données et l'accès à son contenu, ainsi qu'à des fonctions applicatives et/ou à un ensemble de règles définissant les règles 3059118 8 d'accès aux données. Chaque dispositif client 50 peut être un dispositif électronique qui inclut le matériel, le logiciel, ou des composants logiques intégrés capables d'exécuter des fonctionnalités. Des exemples de dispositifs clients 50 peuvent inclure un système informatique tel qu'un ordinateur de bureau, un dispositif électronique 5 mobile tel qu'un ordinateur portable, une tablette, un téléphone cellulaire, un smartphone, etc. Chaque dispositif client 50 peut permettre à son utilisateur de communiquer avec le dispositif d'analyse via un réseau 3 en utilisant une interface utilisateur graphique 60 et une saisie de commande (manuelle ou vocale), etc. L'interface utilisateur peut faire partie d'une application WEB dédiée, et se présenter 10 sous forme de pages WEB dédiées. Plus généralement, les dispositifs clients peuvent utiliser toute Interface Homme Machine couplée de façon fonctionnelle avec un ou des processeurs du système informatique sur lequel est implémenté le dispositif d'analyse 20 et permettant à un utilisateur d'interagir directement avec ce système informatique. L'Interface Homme 15 Machine (IHM) peut inclure un affichage vidéo ou alphanumérique, un écran tactile, un haut-parleur et tout autre indicateur visuel et audio capable de communiquer des données à l'utilisateur. L'Interface Homme Machine (IHM) peut aussi inclure des dispositifs et des contrôles de saisie tels qu'un clavier alphanumérique, un dispositif de pointage, des claviers, des boutons poussoir, des boutons de commande, des 20 microphones, etc., capables d'accepter des commandes ou des saisies de l'utilisateur et de les transmettre aux processeur(s) du système informatique. Le dispositif 100 de génération d'une base de données pivot 10 peut être connecté en entrée à une ou plusieurs sources de données 2. Les sources de données 2 peuvent être des bases de données hétérogènes stockant des données, 25 chaque donnée étant associée à un médicament selon tout format ou structure de stockage spécifique tel que par exemple : - des bases de données de type "Recommandations Caractéristiques Produit » (RCP), ou - des bases de données de type « Autorisation de mise sur le marché » (AMM). 30 Les sources de données 2 peuvent comprendre des sources de données prévues pour tenir compte des différents acteurs du médicament, comme par exemple : 3059118 9 - les laboratoires pharmaceutiques, chercheurs, innovateurs et producteurs de médicaments ; les sociétés commerciales assurant la diffusion de médicaments ; - les organismes régulateurs comme l'Agence nationale pour la sécurité du médicament et des produits de santé (ANSM) et la Haute Autorité de Santé (HAS)) 5 qui autorise la mise sur le marché des médicaments, et/ou fixe le prix des médicaments ; - les professionnels de santé et établissements de santé prescripteurs; - les consommateurs de médicaments (patients) ; - les lieux d'acquisition des médicaments, 10 - les officines et établissements de santé ; - les organismes de couverture santé, à savoir les caisses d'assurances maladie et les organismes complémentaires. Les sources de données 2 peuvent par exemple comprendre : 15 - des bases de données générées par des organismes privés (Thériaque, Vidal, Claude Bernard, mutuelles, assurances) ; - des bases de données publiques : assurance maladie, ANSM, en liaison avec la HAS ; - des sources de données non structurées générées par les organismes et 20 professionnels de santé comprenant des résumés caractéristiques produits et des formulaires de signalement d'effets indésirables ; - des sources de données non structurées générées par les patients comme par exemple des réseaux sociaux, ou des forums. 25 Les sources de données 2 peuvent être construites en utilisant différentes classifications dans le domaine du médicament. Par exemple, certaines sources de données 2 peuvent utiliser la classification ATC (acronyme pour « Anatomical Therapeutic Chemical classification system » signifiant « système de classification chimique thérapeutique anatomique »). Cette 30 classification ATC, éditée par l'Organisation mondiale de la Santé (OMS) comprend un classement des « principes actifs» ou « substances actives » en fonction de l'organe ou du système sur lequel elles agissent, et de leurs propriétés 305 9 118 10 thérapeutiques et pharmacologiques. La classification ATC comporte 5 niveaux de hiérarchie : - un 1er niveau correspondant à la classe anatomique principale ; - un 2ème niveau correspondant à la sous-classe thérapeutique ; 5 - un 3ème niveau correspondant à la sous-classe pharmacologique ; - un 4ème niveau correspondant à la sous-classe chimique ; et - un 5ème niveau correspondant à la substance active. Un exemple de classification ATC de la Clindamycin est donné ci-dessous : 10 J ANTIINFECTIVES FOR SYSTEMIC USE J01 ANTIBACTERIALS FOR SYSTEMIC USE JO1F MACROLIDES, LINCOSAMIDES AND STREPTOGRAMINS JO1FF Lincosamides 15 ATC Code Name JO1FF01 clindamycin Dans une classification de type ATC, une substance active peut être classée plusieurs fois, selon des codes très différents, et à tous les niveaux. Par exemple 20 l'ASPIRINE « UPSA 325mg » a pour code ATC BO1AC06, qui correspond à la sous-classe pharmacologique des anti-thrombotique, tandis que les ASPIRINES « UPSA 500 mg » et « UPSA 1000 mg » ont toutes les deux pour code ATC NO2BA01, correspondant aux antalgiques et antipyrétiques. Il convient de noter que les indications des principes actifs variant selon les pays, 25 en fonction des Autorisations de Mise sur le Marché (AMM) obtenus, un même principe actif aura donc des codes ATC différents suivant les pays. Il convient également de noter que la notion de substance active n'est pas spécifiquement définie, et que la classification ATC est généralement considérée comme classant des « médicaments ». Pour un médicament donné, il peut arriver 30 (rarement) qu'un autre code soit utilisée lorsque la classification officielle ATC renvoie à un organe et à des caractéristiques thérapeutiques qui ne correspondant 3059118 11 pas à l'AMM délivrée en France. Par ailleurs, certaines associations de principes actifs (par exemple acide clavulanique + amoxicilline) ont leur propre code ATC de 5ème niveau. D'autres sources de données 2 peuvent utiliser la classification 5 DCI (Dénomination Commune Internationale). Les dénominations communes internationales (DCI) identifient « les substances pharmaceutiques ou les principes actifs pharmaceutiques » (OMS). Chaque DCI est une appellation unique reconnue au niveau mondial et qui relève du domaine public. On parle aussi de nom générique. 10 Les noms des sels et esters ayant la même substance active présentent une différence par rapport au fragment inactif de la molécule (oxacilline et ibufénac sont des DCI et leurs sels portent respectivement les noms d'oxacilline sodique et ibufénac sodique). Ces dernières dénominations sont des DCI modifiées (DCIM). La désignation de «DCI modifiée» peut être également utilisée pour une base ou 15 un acide. Par exemple, la dénomination «levothyroxine sodique» a été publiée en tant que DCI; celle de «levothyroxine» peut donc être qualifiée de DCIM. D'autres sources de données 2 peuvent encore utiliser la classification CIS (Code Identifiant de Spécialité) qui désigne la spécialité pharmaceutique correspondant au médicament sous sa forme commercialisé, comportant donc un nom commercial, et 20 complété d'une posologie et d'une forme galénique. Le code CIS est un code numérique de 8 chiffres qui permet d'identifier un médicament quelle que soit sa présentation (ou encore conditionnement). Il est attribué par l'ANSM. Certaines sources de données peuvent être construites en outre selon la Classification CIP (Code Identifiant de Présentation) désigne la présentation 25 correspondant au médicament dans sa forme packagé. Chaque présentation d'une spécialité pharmaceutique est identifiée par un "code CIP ". Une présentation (et une seule) est définie par les éléments suivants : - sa dénomination (nom commercial) - sa forme pharmaceutique (galénique) 3059118 12 - son dosage - son conditionnement et la contenance de son conditionnement. La classification CIP est associée à un code à 13 chiffres (par exemple 5 3400930000120) comprenant : - Le préfixe du médicament France, - une position supplémentaire pour les médicaments avec AMM, - un code à 7 chiffres, - une clé de contrôle. 10 Le code CIP à 13 chiffres est encapsulé dans une matrice de données de codage comprenant un numéro de lot et la date de péremption en plus des 13 chiffres. Le code à 13 chiffres est mentionné dans la décision d'autorisation de mise sur le marché (décision et ses annexes) de toute spécialité pharmaceutique. Pour un 15 même code CIS, il existe plusieurs code CIP, suivant la présentation. Une autre classification pouvant être utilisée par une source de données 2 peut être la classification UCD (Unités Communes de Dispensation). Les UCD sont délivrées en établissements de santé. Il existe une correspondance avec le code UCD et le code ATC. 20 Certaines sources de données peuvent en outre utiliser la classification anatomique EPHMRA (EPHMRA Anatomical Classification). Cette classification est maintenue par l'association « European Pharmaceutical Marketing Research Association (EphMRA) ». Elle décrit des classes thérapeutiques dans lesquelles sont classées indifféremment des molécules, les associations de molécules ou 25 spécialités. À la différence de l'ATC, et malgré ses similarités, le code EPHMRA n'a pas de signification particulière dans sa décomposition, à l'exception de la première lettre, et du nombre 9 signifiant « autres ». La séquence des codes n'implique aucune priorité ou sens particulier. Il convient de noter qu'une même classe ou sous-classe définie dans plusieurs 30 classifications du médicament peut être différente d'une classification à une autre ou plus généralement d'une source de donnée 2 à une autre lorsque ces sources de 3059118 13 données reposent sur des classifications différentes. Par exemple, une même classe ou sous classe peut différer par son label qui peut être légèrement modifié en fonction des sources de données (et donc de la classification qu'elles utilisent), ou par leur sémantiques qui ne décrivent pas les mêmes recoupements. 5 Par exemple, les classes thérapeutiques varient d'une source de données à l'autre. Ainsi, dans le cas des interactions médicamenteuses, les classes thérapeutiques définies par l'ANSM sont différentes de celles de l'ATC. Les classes EPHRMA sont également différentes. L'homme du métier comprendra que les classifications utilisées par les différentes 10 sources de données ne sont pas limitées aux exemples cités ci-avant et peuvent inclure toute classification ou représentation relative aux médicaments. Les sources de données 2 peuvent donc reposer sur une grande variété de classifications dans le domaine du médicament, et constituer un ensemble de sources de données très hétérogènes formant un ensemble d'informations 15 parcellaires, de granularités différentes, et décrites avec des classifications différentes. Le dispositif 100 est adapté pour intégrer cette pluralité de sources de données de manière homogène. En référence à la figure 2, le dispositif 100 de génération de la base de données 20 pivot peut comprendre : - une unité d'extraction de données 3 pour extraire les données hétérogènes issues des différentes sources de données 2 ; les données extraites pourront être désignées ci-après par l'expression « données initiales » ou « données non- structurées » pour désigner ces données organisées selon les 25 formats/représentations hétérogènes des différentes sources de données 2, certaines sources comprenant des données en relation avec le médicament qui peuvent ne pas répondre à la sémantique médicale standard (par exemple source de données de type forum Internet); - une unité de structuration des données 4 configurée pour structurer les données 3059118 14 extraites en leur appliquant une ontologie de médicament pivot 40 aux données extraites ; les données obtenues après traitement par l'unité de structuration 4 seront désignées ci-après par l'expression « données structurées ». 5 Les données ainsi structurées sont alors maintenues/stockées dans une base de données pivot 10 comprenant des entrées, chaque entrée stockant des attributs associés à une valeur correspondant aux classes de l'ontologie pivot. Les données stockées dans les sources de données 2 ainsi que dans la base de 10 données pivot peuvent être représentées par un graphe. Dans certains modes de réalisation, les sources de données 2 et celles de la base de données pivot 10 peuvent être des bases de données spécialisées s'appuyant sur de telles graphes pour garantir la persistance des données et peuvent être associées à des ressources sémantiques à base de faits de type : sujet / prédicat / objet (« triplestores »). 15 Il est fait référence à la figure 3 qui représente le dispositif 100 de génération de base de données selon certains modes de réalisation. Dans de tels modes de réalisation, l'unité d'extraction de données 3 peut 20 comprendre un premier parseur 30 pour parcourir les données de médicaments des différentes sources 2. Dans un mode de réalisation les données peuvent être récupérées des différentes sources 2 sous la forme de un ou plusieurs fichiers de description de données selon un premier format (encore appelé « format initial », par exemple selon le format PDF (Portable Document Format, signifiant littéralement 25 Format de Document Portable). Le premier parseur 30 peut être configuré pour parcourir les données du ou des fichiers de description dans le format initial et transmettre les données parcourues à une fonction de transformation 31 configurée pour transformer chaque fichier de description des données tiré des bases de données source 2 en un fichier de description de données selon un second format 30 modifiable (par exemple un fichier au format texte (txt)). Dans certains modes de réalisation, l'unité de structuration 4 peut être configurée pour rechercher des informations de similarités entre les données extraites des 3059118 15 sources de données 2 en parcourant chaque fichier de description converti dans le deuxième format (encore appelé « format cible »). Un second parseur 41 peut être utilisé pour rechercher les informations de similarités avec les concepts ou classes de l'ontologie pivot 40. En réponse à la détection de données d'informations de 5 similarités en relation avec les concepts ou classes de l'ontologie, les informations de similarités peuvent être collectées puis analysées pour associer les données parcourues à des classes et relations de l'ontologie (instanciation du concept ou de la classe de l'ontologie). Cette instanciation résulte dans la construction d'un graphe représentant les relations entre les classes détectées correspondant aux données 10 parcourues. Les données ainsi structurées sont stockées dans la base de données pivot 10 à partir du graphe obtenu. 15 L'unité de structuration 4 est ainsi configurée pour « contextualiser » les données hétérogènes extraites par l'unité d'extraction 3, ce qui permet de les exploiter au mieux. Telle qu'utilisée ici, l'opération de « contextualisation » réalisée par l'unité de 20 structuration 4 consiste à appliquer le modèle ontologique 40 du médicament (dit «ontologie pivot ») aux données extraites par l'unité d'extraction 3. L'ontologie pivot permet de représenter formellement les données utiles et utilisables dans le domaine du médicament pour permettre leur utilisation dans des applications relatives à l'analyse des interactions médicamenteuses ou pour l'aide à la prescription 25 (génération de recommandations relatives aux médicaments). Une telle opération de « contextualisation » des données permet de transformer les sources de données hétérogènes 2 (encore appelées « sources de données élémentaires ») en une base de connaissances pivot 10 dans laquelle les données 30 hétérogènes extraites relatives aux médicaments sont maintenues selon une structuration commune. Une telle base de connaissance pivot 10 est adaptée pour exécuter des requêtes 3059118 16 complexes propres à exploiter la diversité et l'exhaustivité des données stockées pour des applications relatives à l'analyse des interactions entre médicaments, en prenant en compte des caractéristiques propres aux médicaments (par exemple, la classe thérapeutique, la dose ...). La base de connaissance enrichie 10 telle que 5 générée par le dispositif 100 permet donc de nombreuses applications d'analyse en relation avec le médicament (e.g. étude des relations nouvelles non présentes dans les données originelles). Les sources et ressources termino-ontologiques dans le domaine du médicament, 10 et plus généralement dans le domaine biomédical peuvent être très nombreuses. Il en résulte que certains concepts utilisés en relation avec des médicaments dans ces sources et/ou ressources peuvent être représentés ou décrits de manière hétérogène, leur représentation ou leur définition n'étant pas partagés par toutes les sources/Ressources. 15 Pour regrouper les données extraites dans la base de structurée issues de ces différentes sources, l'unité de structuration 4 du dispositif 100 de génération de base de données de médicament pivot peut être configurée pour structurer de manière homogène les données extraites en appliquant une nouvelle ontologie pivot. L'unité 20 de structuration 4 peut être configurée pour instancier une telle ontologie pivot 40 du médicament avec les données extraites, l'ontologie répondant à une contrainte technique propre au domaine du médicament. L'unité de structuration 4 offre ainsi une approche modulaire du médicament, ce 25 qui garantit plus de souplesse aux outils qui s'appuient sur la base de connaissance hétérogène obtenue tout en permettant, pour des cas d'usage précis, de réutiliser des ontologies ou modèles spécifiques, comme par exemple le modèle DIDEO pour les interactions médicamenteuses. 30 Plus précisément, l'unité de structuration 4 peut mettre en oeuvre une ontologie pivot 40 basée sur une décomposition systématique et logique d'un concept générique de médicament appelé « Drug » (terme anglo-saxon signifiant « Médicament ») en fonction des concepts élémentaires qui le compose. 3059118 17 Le modèle RxNorm, développé et maintenu par l'US National Library of Medicine, au sein de l'Unified Medical Language System (UMLS), fournit des noms normalisés de médicaments liés aux principales bases de données existantes (telles que « First Databank », « Micromedex », « MediSpan », « Gold Standard Drug Database », 5 etc..). RxNorm intègre l'ontologie NDFRT. Rx Norm sert classiquement d'outil et de support pour l'interopérabilité entre les terminologies et les bases de connaissances médicamenteuses. RxNorm, dans ses versions disponibles publiquement, possède 118555 concepts, correspondant aux médicaments. Le modèle de RxNorm est construit à partir de trois entités fondatrices : ingrédient, forme galénique et dose, qui 10 une fois réunis, forment le concept de « Clinical Drug ». Par exemple, en comparaison avec le modèle sémantique classique RXNORM, l'unité de structuration 4 applique une nouvelle ontologie dans laquelle est ajouté ce concept «Drug », qui permet des liens vers CHEBI notamment (Chebi désigne l'ontologie « Chemical Entities of Biological Interest Ontology » qui classe de manière 15 structurée les composants chimiques et biochimiques ; ChEBI est une ontologie chimique, ce qui permet aux relations entre les entités moléculaires ou des classes d'entités d'être décrites de manière structurée). De plus, l'ontologie appliquée comprend un nombre restreint de relations entre concepts, ce qui permet de limiter les conflits qui existent dans les modèles classiques (par exemple RXNORM). 20 Par ailleurs, alors que l'ontologie proposée peut être représentée en langage OWL, il n'existe pas de représentation disponible du modèle sémantique de RXNORM en langage OWL. En structurant les données avec l'ontologie pivot appliquée par l'unité de 25 structuration 4, le dispositif proposé fournit une base de connaissances hétérogènes qui peut être interrogée avec tout langage ou protocole de requête qui permet de rechercher, d'ajouter, de modifier ou de supprimer des données RDF (Resource Description Framework) disponibles à travers le réseau Internet tel que SPARQL (Protocol and RDF Query Language). 30 Les modèles sémantiques utilisés classiquement pour représenter les données de médicaments tels que RXNORM ne permettent pas d'interroger la base de 3059118 18 connaissances dans laquelle sont stockées ces données structurées au moyen de tels langages de requête. Dans certains modes de réalisation, l'unité de structuration 4 peut être configurée 5 pour instancier les données de médicaments extraites dans l'ontologie pivot 40 du médicament, en utilisant une interface de programmation applicative (API) du langage de représentation de connaissance OWL pour sélectionner pour chaque élément de la base de données le concept correspondant dans le modèle sémantique de l'ontologie pivot 40. 10 Les données sont maintenues dans une base de connaissance pivot 10 ainsi structurée. La base de connaissance pivot 10 ainsi obtenue peut recevoir des requêtes selon 15 un langage de requête adapté tel que des requêtes SPARQL. Les requêtes pouvant être traitées par la base de connaissance peuvent être pré-programmées. En réponse à une requête, la base de connaissance pivot hétérogène 10 peut exporter le résultat qui peut être affiché dans une interface graphique configurée en fonction de l'application de l'invention. 20 La figure 4 montre une architecture simplifiée de l'ontologie pivot 40 utilisée par l'unité de structuration 4, selon certains modes de réalisation. Une ontologie est classiquement définie comme une spécification formelle explicite d'une conceptualisation, une « conceptualisation » se référant à une modélisation d'un phénomène dans le monde en identifiant les concepts pertinents 25 de ce phénomène. Une ontologie est « explicite » en ce que le type de concepts et les contraintes appliquées sur les concepts sont explicitement définis. Une ontologie est « formelle » en ce que par essence une ontologie est une spécification compréhensible par une machine, à l'opposé du langage naturel. Plus spécifiquement, une ontologie fait référence à une modélisation d'un 30 ensemble de données (ou connaissances) dans un domaine donné sous forme de : - « Concepts » (encore appelés « classes »), un concept étant la représentation 3059118 19 d'une entité du domaine ; - « Propriétés » (encore appelées « attributs ») liés aux concepts. Des « relations » sont utilisées pour représenter le lien entre les concepts. Le modèle ontologique pivot 40 peut être utilisé par l'unité de structuration 4 pour 5 intégrer et/ou traiter des données extraites des sources de données hétérogènes 2, mais aussi pour déterminer de nouvelles relations à partir d'informations parcellaires tirées des données extraites ou déterminer des alignements possibles entre les sources de données 2 (par exemple alignements entre classes thérapeutiques telles que décrites dans différentes sources 2). 10 Il convient de noter que le domaine du médicament possède un positionnement transversal en lien avec une pluralité de domaines connexes: il est en lien avec le domaine des pathologies, des diagnostics, mais aussi avec des mécanismes biologiques, et les données génomiques, ces domaines étant associés à des ressources ontologiques spécifiques. L'ontologie pivot 40 peut être en outre utilisé 15 par l'unité de structuration 4 pour intégrer de telles ontologies spécifiques à ces domaines connexes à partir de ressources termino-ontologiques du domaine du médicament. Le modèle ontologique pivot 40 peut s'appuyer sur un ou plusieurs modèles de référence, tel que le modèle RXNORM. 20 Le modèle de RxNorm est la référence internationale. Elle décompose le médicament dans ses trois concepts fondamentaux (galénique, dose et ingrédient). Cependant, le concept Médicament (« Drug »), tel que décrit par exemple dans ChEBI, n'est pas retrouvé dans le modèle RxNORM. De plus, RxNorm ne présente pas un modèle de « haut niveau » inférant les relations décrites. Un autre 25 inconvénient de RxNorm est la multiplicité des relations présentes dans ce modèle (28 chemins pour les 8 concepts principaux): si ces relations permettent de passer par plusieurs « chemins » pour retrouver une information, elles ne donnent pas tous le même résultat. Le modèle ontologique pivot 40 est construit en utilisant un langage de 3059118 20 représentation sémantique tel que le langage OWL qui est fondé sur une logique de description. D'autres langages de représentation d'ontologie peuvent être utilisés en variante comme OIL, DAML et DAML+OIL. Le langage OWL a pour composants des classes, des instances et des propriétés 5 dont il existe deux catégories : - les propriétés objet (« owl:ObjectProperty ») qui relient un objet à un autre objet, et - les propriétés typées (« owl:DataTypeProperty ») qui relient un objet a une valeur typée. 10 Il existe 3 sous-langages OWL : - « OWL-lite » qui comprend des contraintes simples ; - « OWL-DL » qui est un langage plus expressif mais décidable ; - « Full-OWL » qui permet une expressivité maximale mais dont la décidabilité n'est pas garantie. 15 Comme montré sur la figure 4, l'ontologie pivot utilisée 40 est basée sur une approche modulaire qui permet d'établir des correspondances (« mappings ») avec les ontologies du médicament existantes (RxNorm, CHEBI, etc). L'ontologie pivot 40 est basée sur des concepts principaux comprenant le concept Ingrédient (« Ingredient ») (400), le concept Médicament (« Drug ») (401), et le concept 20 Médicament Clinique (« Clinical Drug ») (402) tels que définis dans des modèles ontologiques du médicament. Le concept « Drug » (401) est défini par CHEBI, le concept « Ingredient » (400) est défini par RXNORM. Le concept « Clinical Drug » (402) est tiré de RXNORM, des modèles NDFRT et VANDF, et est relié au concept « Drug » par la relation définie en pseudo code « Clinical Drug rdfs :SubclassOf 25 Drug » (le concept « Clinical Drug » est une sous classe du concept « Drug »). Ces trois concepts principaux sont définis comme suit : - Le concept d'intérêt « Ingredient » (400) désignant "un composé ou une fraction 3059118 21 thérapeutique donnant au médicament ses propriétés cliniques » (selon la définition de la ressource terminologique RxNorm) ; - Le Concept d'intérêt « Drug » (401) désignant : « Toute substance qui, lorsqu'elle est absorbée par un organisme vivant, peut modifier une ou plusieurs de 5 ses fonctions. Le terme est généralement admis pour une substance prise dans un but thérapeutique, mais est aussi couramment utilisé pour les drogues ("abused substance')» (selon la définition de l'ontologie CHEBI) ; - Le concept d'intérêt « Clinical Drug » (402) désignant une « entité composée par les concepts Ingrédient, Dose et DoseForm (forme galénique) » (selon la définition 10 de la ressource terminologique RxNorm). Le concept d'intérêt "ingredient" (400) peut par example correspondre à la classification DCI et le concept "clinical drug" (402) peut correspondre à la classification CIS. Chaque module 400, 401, 402 de l'ontologie est indépendant et peut-être 15 développé séparément. Une telle approche modulaire est particulièrement adaptée à une ontologie du médicament pivot, les ontologies existantes étant très nombreuses, et le médicament étant, par définition, en relations avec une multitude d'autres concepts ou domaines connexes (symptômes, maladies, mécanismes d'action biologique, etc.) qui sont 20 associés à de nombreux modèles de connaissances spécifiques. Dans un mode de réalisation préféré, le concept « Drug » (401) peut être modélisé sous la forme d'une classe selon le langage de représentation d'ontologie utilisé (par exemple classe OWL) et est utilisé comme classe supérieure (« top classe) conformément à la définition de l'ontologie CHEBI : 25 - le concept « DRUG » 401 a pour ingrédient un ou plusieurs ingrédients pharmaceutiques « Pharmaceutical Ingredient », - le concept « DRUG » 401 a au moins un ingrédient pharmaceutique (« Pharmaceutical Ingredient »), 3059118 22 - le concept « DRUG » 401 n'a pour ingrédient que des ingrédients pharmaceutiques (« Pharmaceutical Ingredients »). Dans le mode de réalisation considéré, le concept supérieur « Drug » est père de 9 entités, ces entités « filles » étant modélisées sous la forme de classes dans le 5 langage de représentation d'ontologie utilisé (classes OWL par exemple) et comprenant les classes : - Pour la partie « clinique » du modèle :Médicament Clinique (« Clinical Drug »), Composant de Médicament Clinique (« Clinical Drug Component »), Composant de Médicament Clinique Composé (« Composed Clinical Drug Component »), Forme de 10 Médicament Clinique (« Clinical Drug Form »), Forme de Médicament Clinique Composée (« Composed Clinical Drug Form »), - Pour la partie « commerciale » du modèle : Médicament Commercial (« Branded Drug »), Composant Commercial de Médicament (« Branded Drug Component »), Forme Commerciale de Médicament (« Branded Drug Form ») et Nom Commercial 15 (« Brand Name »). Les classes portant le même label que les concepts de l'ontologie RxNORM peuvent décrire les mêmes concepts. Le concept « Clinical Drug » est donc issu de la composition de 3 autres entités selon ce mode de réalisation: Ingrédient, Forme galénique (DoseForm) et Dose (concepts dérivés de l'ontologie RxNorm). 20 Le concept « Clinical Drug » peut être lui-même défini comme un fils de la classe « ClinicalDrug Component » et de la classe « Clinical Drug Form », toute instance de la classe « Clinical Drug » étant également instance de ces deux classes. Les associations des concepts Ingrédient-Dose (« Ingredient-Dose ») et Ingrédient-Forme galénique (« Ingredient-DoseForm ») donnent respectivement les 25 concepts Composant de Médicament Clinique (« Clinical Drug Component ») et Forme Galénique Clinique (« Clinical Dose Form »). Ces deux concepts, ainsi que le concept « Clinical Drug » peuvent être déclinés dans une partie commerciale (Branded part) du modèle, qui correspond aux médicaments portant une marque commerciale. Le concept « BrandName » correspond au nom commercial du 3059118 23 médicament, tel que « Doliprane ». L'annexe 1 montre la hiérarchie de l'ontologie pivot 40, en langage OWL, selon un exemple de réalisation. Les concepts de l'ontologie pivot 40 sont tous des sous-classes du concept 5 « Drug » (liés au concept Drug par la relation « rdfs:SubClassOf Drug »). Le concept « Drug » est relié par la relation « has_ingredient » (relation formé de mots anglo-saxon pouvant se traduire par « possède_ingrédient ») au concept « Ingredient ». Certaines restrictions peuvent être également implémentées. Par exemple, le concept Composant de Médicament Clinique 10 « ClinicalDrugComponent » peut être décrit en langage OWL selon l'Annexe 2. En langage de description, l'ontologie pivot 40 peut être décrite selon l'Annexe 3. L'ontologie pivot 40 a été comparée avec des classes décrites par l'ATC au 2ème niveau (« 2 digit ») et les classes décrites par le Thésaurus des interactions de l'ANSM. Les classes correspondant au dernier niveau de l'ATC (7 digits), et au 15 deuxième niveau (2 digit) ainsi qu'une classe Famille ANSM ont été créée à l'aide de l'Interface d'application OWL API à partir des données décrivant les classes ANSM, construit à partir du thésaurus des interactions médicamenteuses. L'Interface d'Application « OWL API » est une API du langage JAVA pour créer, manipuler et sérialiser des ressources termino-ontologiques au format OWL. 20 Une relation « appartientA » a été créée. La relation haslngredient était présente entre BrandedDrug et Pharmaceuticallngredient, inférée à travers Drug. Une requête en langage SparQL a ensuite été effectuée afin de retrouver l'ensemble des classes ANSM et ATC2 pour lesquelles le label des instances de FamilleATC5 étaient identiques avec le label de Pharmaceuticallngredient. La 25 requête SparQL a été utilisée pour visualiser les résultats, comme illustré sur la figure 5. En considérant l'exemple de la molécule acebutolol, il peut être constaté, d'après le tableau de la figure 5 que cette molécule appartient uniquement à la sous-classe 3059118 24 thérapeutique des Bétabloquants dans l'ATC. En revanche, dans le thésaurus des interactions médicamenteuses de l'ANSM, cette molécule est classée dans cinq classes différentes : i) antihypetenseurs sauf alpha-bloquant, ii) bétabloquant (sauf esmolol et sotalol) iii) béta-bloquant (sauf esmolol) iiii) bradycardisant, iiiii) 5 médicament abaissant la pression artérielle. Il peut être observé une absence totale de concordance entre les labels ANSM et ATC. Cependant, l'ontologie pivot 40 utilisée permet, au moyen du concept « pharmaceuticallngredient » et en utilisant les modules « ANSM » et « ATC » indépendamment, selon l'approche modulaire mise en oeuvre par le dispositif 100, de 10 retrouver que les bétabloquants sont potentiellement une classe servant à « abaisser la pression artérielle », « bradycardisant » comme illustré sur la figure 6, qui représente le résultat de la comparaison de classes pour l'acebutolol. La figure 7 représente le procédé de génération de base de connaissance selon certains modes de réalisation. 15 A l'étape 700, les données non-structurées relatives à des médicaments sont extraites des sources de données 2. A l'étape 702, l'ontologie pivot, préalablement chargée, est appliquée aux données 20 extraites (étape d'instanciation de l'ontologie) et la base de données pivot 10 est générée à l'étape 704. L'étape 702 peut comprendre le parcours des données extraites en utilisant un parseur 30 pour appliquer l'ontologie pivot aux données extraites. 25 Les informations ainsi extraites (données structurées associées le cas échéant à une catégorie) sont ainsi regroupées dans une base de données structurées 10 venant enrichir les bases de données hétérogènes 2 déjà existantes tout en offrant un accès centralisé aux données de médicaments hétérogène dans un format structuré. 30 La figure 8 représente le procédé de génération de la base de données pivot selon un mode de réalisation. 3059118 25 Dans un mode de réalisation où les données hétérogènes sont récupérées des sources de données sous la forme d'un fichier de description ayant un premier format, l'étape d'extraction 700 peut comprendre : 5 - une étape 7001 de récupération des données depuis chaque source de données 2 sous la forme de au moins un fichier de description dans un premier format (par exemple un format « PDF ») ; - une étape 7003 de conversion ou transformation des fichiers de descriptions associés aux données récupérées depuis chaque source de données 2 dans un 10 deuxième format (par exemple « txt »), en parcourant chaque fichier de description (7002) au moyen d'un parseur 30 et en convertissant les informations parcourues en fonction de règles de transformation (« mapping rules »), les règles de transformation définissant les correspondances pour passer du premier format au second format. 15 Le format du fichier de description (premier format) peut être différent pour les différentes sources de données 2. Le format (second format) dans lequel est converti chaque fichier de description extrait des sources de données 2 peut être avantageusement le même quelque soient les formats d'origine des fichiers de description extraits (premiers formats). 20 L'étape d'instanciation de l'ontologie 702 peut alors comprendre le parcours de chaque fichier de description dans le second format 7021, et l'instanciation des classes de l'ontologie à partir des données parcourue 7025 pour chaque fichier parcouru. Par exemple si les fichiers de descriptions des données extraites sont des 25 fichiers dans un format CVS (second format), l'étape 7021 peut comprendre le parcours de chaque fichier CSV puis l'instanciation d'une classe de l'ontologie pivot à partir des informations identifiées 7025. L'étape 702 peut comprendre une recherche d'informations de similitude sémantiques 7023 entre les données parcourues correspondant aux données extraites des sources de données 2 et les concepts de 30 l'ontologie pivot. Les informations de similarités détectées peuvent être ensuite associées à des concepts ou classes de l'ontologie pivots (par exemple la classe « indications », la classe « contre-indications », la classe « interactions connues », la classe « date d'AMM », etc...Les données extraites des sources de données 2 3059118 26 initialement non structurées sont alors structurées en leur affectant les concepts ou classe de l'ontologie pivot. Dans certains modes de réalisation, la base de données pivot 10 peut être utilisée 5 dans un dispositif ou outil d'analyse en relation avec les médicaments 20 comprenant une interface graphique configurée en fonction de l'application de l'invention (aide à la prescription, pharmacovigilance, etc.). Le dispositif 20 peut être implémenté sous la forme d'un outil partagé par plusieurs dispositifs clients via un réseau (le dispositif d'analyse 20 pouvant être implémenté sous la forme d'un outil 10 d'application WEB) ou un dispositif 20 configuré pour l'usage de chaque dispositif client. Les requêtes peuvent être saisies dans l'interface graphique 60 par exemple en renseignant des noms de médicaments dans des champs prévus sur l'interface graphique. La validation de la requête (par exemple SPARQL) par l'utilisateur génère l'interrogation de la base de données. En réponse à cette requête la base de 15 connaissance retourne le résultat de la requête, l'outil 20 générant l'affichage des résultats sur l'interface graphique en s'appuyant sur la représentation des données de l'ontologie pivot. L'affichage des résultats dépend de l'application de l'invention et de la configuration de l'interface graphique 60. Par exemple, une requête SPARQL peut être émise en renseignant un médicament ou une molécule pour interroger les 20 données de la base de connaissance hétérogène qui sont contenues dans le concept équivalent aux molécules ou aux médicaments. Dans un autre exemple, plusieurs médicaments peuvent être renseignés sur l'interface graphique, l'exécution de la requête SPARQL déclenchant la recherche dans la base de connaissance hétérogène des interactions médicamenteuses entre les médicaments renseignés. 25 Dans une application de l'invention, la base de données pivot 10 peut être utilisée dans un dispositif 20 configuré pour gérer les interactions médicamenteuses. Une interaction médicamenteuse (Drug Drug Interaction : DDI) fait référence à l'effet qui résulte de l'administration concomitante ou successive de deux ou plusieurs 30 médicaments. Une interaction a une « traduction clinique significative, décrite ou potentiellement grave », c'est-à-dire susceptible de « provoquer ou majorer des effets indésirables » ou « d'entraîner, par réduction de l'activité, une moindre efficacité des traitements. » 3059118 27 (Source ANSM). Les DDI connues sont décrites dans des référentiels, comme par exemple le Thésaurus des interactions médicamenteuses, édité par l'ANSM tous les 6 mois, et qui décrit les interactions comme suit : « L'interaction est définie par un couple de protagonistes "a + b" qui peuvent être : 5 une substance active, désignée par sa dénomination commune internationale (DCI) ou une classe thérapeutique, elle-même faisant l'objet d'interactions "de classe". » La base de données pivot 10 permet une gestion efficace du DDI et limite le nombre de décès annuels liés aux DDI (il est estimé que les DDI en France sont 10 responsables de 8 000 morts par an en France, et de 130 000 hospitalisations. Les référentiels de DDI peuvent être directement utilisés pour l'aide à la prescription et/ou l'analyse d'ordonnance. Par exemple, le dispositif d'analyse d'interactions médicamenteuses 20 peut être utilisé pour détecter si un patient traité par « zyloric » peut recevoir une pénicilline. La 15 base de données pivot 10 permet par exemple de déterminer que la substance active du « Zyloric » est l'allopurinol, de déterminer tous les médicaments de la classe pénicilline, parmi lesquels se trouve la sous classe pénicillines A par exemple, de rechercher s'il existe des interactions entre l'allopurinol et toutes les substances actives comprises dans les pénicillines, et d'en déduire que l'association entre le « 20 zyloric » et les médicaments de la sous catégories « pénicillines A » est à prendre en compte (amoxicilline, ampicilline...) dans la mesure où il existe un risque accru de maladie de la peau si on associe ces médicaments. Le dispositif 20 d'analyse et de gestion des DDI permet de pallier aux situations où le médecin ne possède pas l'ensemble des informations concernant la prescription 25 en cause ou possède des informations incomplète ou imprécise (i.e « Augmentin » sans posologie ni galénique, ou encore « acide acétylsalicylique » (DCI) sans préciser le nom commercial). En complément, il est possible d'utiliser des sources de données complémentaires concernant les DDI, et les interactions potentielles (PDDI). Les DDI étant 30 susceptibles de changer en fonction de la posologie, de la forme galénique, et même de l'indication dans laquelle a été prescrit le médicament (source Thésaurus ANSM), 3059118 28 il est particulièrement avantageux de traiter l'information provenant d'une multiplicité de sources 2, sur des niveaux sémantiques différents et aux granularités hétérogènes (classes thérapeutiques et DCI). 5 Le dispositif d'analyse 20 peut être également utilisé dans des applications d'identification du mésusage des médicaments sur les forums (pharmaco-vigilance). En effet, certains forums en lien avec la santé peuvent représenter une source importante de données, fournies par les patients sur l'usage réel du médicament. Cette source de donnée 2 de type Forum Internet présente un format non structuré 10 des données qu'elle collecte, ainsi que des types de granularité différents. En effet, les utilisateurs de ces forums sont souvent peu susceptibles de fournir l'ensemble des informations en utilisant la sémantique médicale adaptée (comme par exemple les notions de « posologie » ou « galénique »), et s'expriment plutôt en utilisant le nom commercial du médicament (par exemple « Doliprane » ou « Augmentin ») ou 15 des termes plus généraux (« Antibiotique » ou « Anti dépresseur »). Le procédé et le dispositif de génération d'une base de données pivot de données de médicaments 10 permet de gérer les informations recueillis dans de tels forums internet de manière centralisée, quelle que soit leur niveau de granularité et la sémantique utilisée, en utilisant l'ontologie pivot qui fait correspondre à de telles informations non 20 structurées un niveau de granularité et/ou une sémantique commune. De telles sources de données peuvent être ainsi exploitées de manière transparente dans des outils d'identification du mésusage lié aux médicaments . L'homme du métier comprendra que l'invention n'est pas limitée à une utilisation 25 de la base de données pivot 10 dans des 20 d'aide à la prescription ou d'analyse des interactions médicamenteuse mais peut être utilisée plus généralement dans tous dispositif d'analyse en relation avec les médicaments tel que par exemple un dispositif de gestion des effets indésirables médicamenteux, de « precision medicine » impliquant l'optimisation des traitements pour chaque individu, etc. 30 De tels dispositifs d'analyse 20 permettent de répondre à des enjeux de santé publique importants basés sur l'exploitation de multiples sources de données ayant des représentations ou classifications hétérogènes, pouvant dépendre de différentes 3059118 29 langues lorsqu'elles sont issues de plusieurs pays. Le dispositif 100 de génération d'une base de données de médicaments pivot 10 et le dispositif d'analyse 20 permettent ainsi de gérer, d'intégrer et d'exploiter de telles sources de données hétérogènes concernant le médicament. 5 L'homme du métier comprendra que les procédés selon les modes de réalisation peut être mis en oeuvre de diverses manières par matériel (« hardware »), logiciel, ou une combinaison de matériel et de logiciels, notamment sous la forme de code de programme pouvant être distribué sous la forme d'un produit de programme, sous diverses formes. En particulier, le code de programme peut être distribué à l'aide de 10 supports lisibles par ordinateur, qui peuvent inclure des supports de stockage lisibles par ordinateur et des supports de communication. Les procédés décrits dans la présente description peuvent être notamment implémentés sous la forme d'instructions de programme d'ordinateur exécutables par un ou plusieurs processeurs dans un dispositif informatique d'ordinateur. Ces instructions de 15 programme d'ordinateur peuvent également être stockées dans un support lisible par ordinateur. En particulier, comme illustré sur la figure 9, le dispositif d'analyse 20 peut être implémenté sous la forme d'un ou plusieurs dispositifs ou systèmes informatiques 90 (appelé ci-après ordinateur). L'ordinateur 90 peut comporter un processeur 91, une 20 mémoire 92, un dispositif de mémoire de stockage de masse 95, une interface d'entrée/sortie (I/O) 97 (par exemple, écran vidéo, écran tactile, dispositifs de saisie et des commandes tels qu'un clavier alphanumérique, un dispositif de pointage, des pavés numériques, des boutons poussoirs, des boutons de commande, des microphones, etc.). L'ordinateur 90 peut également être couplé de manière 25 fonctionnelle à une ou plusieurs ressources externes 99 via un réseau 96 et/ou une interface I/O 97. Les ressources externes 99 peuvent inclure, mais sans y être limitées, des serveurs, des bases de données, des dispositifs de stockage de masse, des dispositifs périphériques, des services de réseau à base de nuage (« cloud »), ou toute autre ressource informatique appropriée qui peut être utilisée par 30 l'ordinateur 90. Le processeur 91 peut inclure un ou plusieurs dispositifs processeurs tels que des 3059118 30 microprocesseurs, des microcontrôleurs, des unités centrales de traitement, ou tout autre dispositif qui manipule des signaux (analogiques ou numériques) en fonction d'instructions d'opérations qui sont stockées dans la mémoire 92. Le processeur 91 peut fonctionner sous la commande d'un système d'exploitation 93 qui réside dans 5 la mémoire 92. Le système d'exploitation 96 peut gérer des ressources informatiques telles qu'un code de programme informatique intégré sous la forme d'une ou plusieurs applications logicielles 94 résidant dans la mémoire 92. La base de données pivot 10 peut résider sur un dispositif de mémoire de stockage de masse 95. Elle peut être utilisée pour collecter et organiser les données 10 utilisées par les différents systèmes et modules de l'ordinateur 90. La base de données pivot 10 peut inclure des données et accommoder les structures de données associées qui stockent et organisent les données. En particulier, la base de données 10 pivot peut être organisée selon toute forme de structure de base de données, notamment, mais de façon non exhaustive, sous la forme d'une base de 15 données relationnelle, d'une une base de données de type hiérarchique, d'une base de données en réseau, d'une base de données orientée-objet, ou des combinaisons de ces formes de bases de données. Un système de gestion de base de données sous la forme d'un logiciel informatique d'application qui s'exécute sous la forme d'instructions sur un processeur (processeur 91 par exemple) peut être utilisé pour 20 accéder aux informations ou aux données stockées dans la base de données pivot 10 en réponse à une requête, lorsque la requête est exécutée par le système d'exploitation 93, les applications 94, ou un ou plusieurs modules. L'homme du métier comprendra que les modes de réalisation de l'invention peuvent utiliser tout modèle de gestion de base de données approprié, et ne sont pas limités à un type 25 particulier de base de données. L'invention n'est pas limitée aux modes de réalisation décrits ci-avant à titre d'exemple non limitatif. Elle englobe toutes les variantes de réalisation qui pourront être envisagées par l'homme du métier. 3059118 31 ANNEXES ANNEXE Al 1:Thino Dose DoseForm Drug BrandedDrug BrandedDrugComponent BrandedDrugForm BrandName ClinicalDrug I ClinicalDrug ComposedanicalDrugComponent ClinicalDrugForm ClinicalDrug ComposeddinicalDrugForrn PharmaceuticalIngredient Unit ANNEXE 2 Drug (hasDose only Dose hasDose min 1 Dose) Drug hasIngreclient some PharmaceuticalIngredient) (hasIngredient cnly PharmaceuticalIngredient) (hasIngredient min 1 PharmaceuticalIngredient) 3059118 32 ANNEXE 3 Classes BrandName BrandName E Drug BrandName E Clinica1Drug BrandName C BrandedDrug BrandedDrug BrandedDrug C Drug BrandedDrug Ç BrandName BrandedDrugComponent BrandedDrugComponent V hasBrandedDose Dose H >1. ha.sEiranciedD ase Dose BrandedDrugComponent Ç Drug BrandedDrugForm BrandedDnigForm V hasBrandedDoscForm DoscForm n > 1 hasBrandedDoseForm DoseForm BrandedDrugForm Ç Drug ClinicalDrug GliiiicalDrug Ç ClinicalDrugForui CliiiicalDrug Ç Drug ClinicatDrug E ClinicalDrugComponent ClinicatDrug BrandName ClinicalDrugComponent ClinicalDrugComponent V hasDose Dose n > t hasDose Dose ClinicalDrugComponent C Drug ClinicalDrugForrn ClinicalDrugForm V hasDoseForm DoseForm n > 1 hasDoseForm DoseForm ChnicalDrugForm C Drug ComposedClinicalDrugComponent ComposedClinicalDrugComponent C ClinicalDrugComponent Comp osed Clin icalD rugForm ComposedPharmaceuticalIngredient ComposedPharmaceuticalIng-redient E PharmaceuticalIngredient Dose DoseForm Drug Drug hasingredient Pharmaceutica1Ingredient n V hasIngredient PharmaceuticalIng-redient n > 1 hasIngredient PharmaceuticalIngredient PharmaceuticalIngredient Pharmaceuticalingredient ingredientOf Drug Unit REVENDICATIONS1. Dispositif de génération (100) d'une base de données de médicaments pivot (10) implémenté dans un système informatique, le dispositif comprenant : -une unité d'extraction (3) configurée pour extraire les données d'un ensemble de sources de données de médicaments élémentaires (2), les sources de données de médicaments élémentaires stockant des données relatives aux médicaments, chaque source de donnée élémentaire étant associée à une représentation des données ; - une unité de structuration (4) configurée pour structurer les données extraites en appliquant une ontologie pivot (40) auxdites données extraites, ladite ontologie pivot définissant des classes dérivées d'une ou plusieurs ontologies du médicament et des relations entre lesdites classes, ce qui fournit des données structurées associées à un graphe représentant les relations entre les classes correspondant auxdites données structurées; le dispositif étant configuré pour générer ladite base de données de médicament pivot (10) en fonction dudit graphe et desdites données structurées, la base de données pivot stockant lesdites données structurées. 2. Dispositif selon la revendication 1, caractérisé en ce que l'unité d'extraction (3) est configurée pour récupérer les données des sources de données élémentaires (2) sous la forme d'un fichier de description dans un format initial, l'unité d'extraction (3) comprenant un parseur (30) configuré pour parcourir les données de chaque fichier de description dans le format initial et une fonction de transformation (31) pour transformer le fichier de description au format initial en un fichier de description dans un format cible, à partir des données parcourues. 3. Dispositif selon la revendication 1 ou 2, caractérisé en ce que l'unité de structuration (4) comprend un parseur (41) configuré pour parcourir chaque fichier de description dans le format cible et pour effectuer une recherche d'informations de similarité entre les données parcourues et les classes de l'ontologie pivot, l'unité de structuration étant configurée pour appliquer l'ontologie pivot (40) aux données parcourues en leur associant des classes et des relations en fonction des 3059118 34 informations de similarité, ledit graphe représentant lesdites classes et lesdits liens. 4. Dispositif selon l'une des revendications précédentes, caractérisé en ce que l'ontologie pivot (40) comprend trois classes principales : 5 - Une classe principale « Ingredient » (400) ; - Une classe principale « Médicament » (401) ; et - Une classe principale « Médicament Clinique » (402), les trois classes principales étant indépendantes. 10 5. Dispositif selon la revendication 4, caractérisé en ce que la classe « Médicament » est la classe supérieure et comprend un ensemble de classes filles. 6. Dispositif selon la revendication 5, caractérisé en ce que les classes filles comprennent un ensemble de classes de type « clinique » et un ensemble de classe 15 de type « commerciale ». 7. Dispositif selon l'une des revendications 4 à 5, caractérisé en ce que la classe supérieure « médicament » est reliée par une relation de type « possède » à la classe « Ingrédient ». 8. Dispositif selon l'une des revendications précédentes, caractérisé en ce que 20 l'ontologie pivot (40) est représenté selon un langage de requête choisi. 9. Dispositif d'analyse (20) lié aux médicaments caractérisé en ce qu'il comprend un serveur (200) et la base de données pivot (10) générée par le dispositif selon l'une des revendications précédentes, le dispositif étant apte à interroger ladite base de données pivot (10) en réponse à au moins une requête reçu d'un dispositif client 25 et à retourner le résultat au dispositif client. 10. Dispositif d'analyse lié aux médicaments selon la revendication 9, caractérisé en ce que le dispositif d'analyse (20) est un dispositif d'aide à la prescription médicale. 30 11. Dispositif d'analyse lié aux médicaments selon la revendication 9, caractérisé 3059118 en ce que le dispositif d'analyse (20) est un dispositif d'analyse des interactions médicamenteuses. 12. Procédé de génération d'une base de données de médicaments pivot (10) 5 implémenté dans un système informatique, le procédé comprenant les étapes consistant à : -sélectionner des sources de données de médicaments élémentaires stockant des données relatives aux médicaments, chaque source de donnée élémentaire étant associée à une représentation des données ; 10 -extraire les données desdites sources de données de médicaments 2 (700); - appliquer une ontologie pivot (40) auxdites données extraites, ladite ontologie pivot définissant des classes dérivées d'une ou plusieurs ontologies du médicament et des relations entre lesdites classes, ce qui fournit des données structurées associées à un graphe représentant les relations entre les classes 15 correspondant auxdites données structurées (702); - générer une base de données pivot (704) à partir dudit graphe et des dites données structurées, la base de données pivot stockant lesdites données structurées.