WO2018091714A1 - Dispositif et procede de generation d'une base de donnees relative aux medicaments - Google Patents

Dispositif et procede de generation d'une base de donnees relative aux medicaments Download PDF

Info

Publication number
WO2018091714A1
WO2018091714A1 PCT/EP2017/079810 EP2017079810W WO2018091714A1 WO 2018091714 A1 WO2018091714 A1 WO 2018091714A1 EP 2017079810 W EP2017079810 W EP 2017079810W WO 2018091714 A1 WO2018091714 A1 WO 2018091714A1
Authority
WO
WIPO (PCT)
Prior art keywords
data
drug
pivot
classes
ontology
Prior art date
Application number
PCT/EP2017/079810
Other languages
English (en)
Inventor
Louis LETINIER
Clément GOEHRS
Sébastien COSSIN
Bruno THIAO-LAYEL
Frantz THIESSARD
Antoine PARIENTE
Gayo DIALLO
Vianney JOUHET
Original Assignee
Universite de Bordeaux
Centre Hospitalier Universitaire De Bordeaux
Institut National De La Sante Et De La Recherche Medicale - Inserm
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Universite de Bordeaux, Centre Hospitalier Universitaire De Bordeaux, Institut National De La Sante Et De La Recherche Medicale - Inserm filed Critical Universite de Bordeaux
Priority to US16/461,776 priority Critical patent/US11210314B2/en
Publication of WO2018091714A1 publication Critical patent/WO2018091714A1/fr

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/25—Integrating or interfacing systems involving database management systems
    • G06F16/254—Extract, transform and load [ETL] procedures, e.g. ETL data flows in data warehouses
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/24—Querying
    • G06F16/245—Query processing
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/30—Information retrieval; Database structures therefor; File system structures therefor of unstructured textual data
    • G06F16/36—Creation of semantic tools, e.g. ontology or thesauri
    • G06F16/367—Ontology
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/90—Details of database functions independent of the retrieved data types
    • G06F16/901—Indexing; Data structures therefor; Storage structures
    • G06F16/9024—Graphs; Linked lists
    • G—PHYSICS
    • G16—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR SPECIFIC APPLICATION FIELDS
    • G16H—HEALTHCARE INFORMATICS, i.e. INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR THE HANDLING OR PROCESSING OF MEDICAL OR HEALTHCARE DATA
    • G16H50/00—ICT specially adapted for medical diagnosis, medical simulation or medical data mining; ICT specially adapted for detecting, monitoring or modelling epidemics or pandemics
    • G16H50/70—ICT specially adapted for medical diagnosis, medical simulation or medical data mining; ICT specially adapted for detecting, monitoring or modelling epidemics or pandemics for mining of medical data, e.g. analysing previous cases of other patients
    • G—PHYSICS
    • G16—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR SPECIFIC APPLICATION FIELDS
    • G16H—HEALTHCARE INFORMATICS, i.e. INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR THE HANDLING OR PROCESSING OF MEDICAL OR HEALTHCARE DATA
    • G16H70/00—ICT specially adapted for the handling or processing of medical references
    • G16H70/40—ICT specially adapted for the handling or processing of medical references relating to drugs, e.g. their side effects or intended usage

Definitions

  • the present invention generally relates to data processing, and in particular to a device and method for generating a drug database from a drug ontology model. It also relates to a device and an analysis method based on such a database.
  • BIG Data Prior art and technical problem Major advances in "BIG Data” are revolutionizing the healthcare environment.
  • One of the challenges in health concerns the development of analytical tools for drugs such as tools to help prescription.
  • Such tools rely on knowledge bases or databases to store medical data and to deliver data relating to a medical prescription, in a structured manner in response to requests.
  • databases can also be used in pharmacovigilance tools to detect, evaluate and prevent drug-related adverse events.
  • Information on the adverse effects of a set of drugs can be collected in an upstream observation phase conducted during experimental stages, or during a downstream phase, for example during the marketing and use of drugs. This information can be stored at different data sources in accordance with standardized terminology rules. These sources can then be connected to the knowledge bases used in decision support tools for medical prescription.
  • ontology is used to formally represent the meaning of terms for adverse drug effects.
  • the formal character of representation in an ontology is adapted to the automated exploitation of knowledge by machines (Alani et al, 2003). It allows the integration and processing of heterogeneous data sources, as well as the possibility of reasoning and inferring new relationships or possible alignments between existing data sources (Cruz et al, 2005).
  • the invention improves the situation by providing a device for generating a pivot drug database implemented in a computer system, the device comprising:
  • an extraction unit configured to extract data from a set of elementary drug data sources, the elementary drug data sources storing drug data, each data item source being associated with a representation of the data;
  • a structuring unit configured to structure the extracted data by applying a pivot ontology to the extracted data, the pivotal ontology defining classes derived from one or more drug ontologies and class relationships, thereby providing associated structured data a graph representing the relationships between the classes corresponding to said structured data;
  • the retrieval unit may be configured to retrieve data from the elementary data sources as a description file in an initial format, the retrieval unit including a first parser configured to browse the data of each description file in the initial format and a transformation function to transform the description file in the initial format into a description file in a target format, from the data scanned.
  • the structuring unit may comprise a parser configured to browse each description file in the target format and to perform a similarity information search between the traversed data and the classes of the pivot ontology, the structuring unit being configured to apply the pivot ontology to the traversed data by associating them classes and relations according to the similarity information, the graph representing the classes and the links.
  • the pivotal ontology can comprise three main classes:
  • the class "Drug” can be advantageously the upper class and includes a set of girls classes.
  • the child classes may include a set of "clinical” class classes and a "commercial” class set.
  • the upper class “drug” can be linked by a "possesses” relationship to the "Ingredient” class.
  • the pivot ontology can be represented according to a query language selected.
  • a drug-related analysis device comprising a server and the pivot database generated by the device according to one of the preceding features, the device being able to interrogate the pivot database in response to the minus a request received from a client device and return the result to the client device.
  • the drug-related analysis device may be a device for assisting the medical prescription.
  • the drug-related assay device may be a device for analyzing drug interactions.
  • pivotal ontology defining classes derived from one or more drug ontologies and relationships between said classes, thereby providing structured data associated with a graph representing the relationships between the classes corresponding to the data structured;
  • Figure 1 is a diagram showing the device for generating the pivot drug database, according to some embodiments.
  • FIG. 2 is a diagram showing the device for generating the pivot drug database, according to one embodiment
  • FIG. 3 is a diagram showing the device for generating the pivot drug database, according to a variant embodiment
  • FIG. 4 shows a simplified architecture of the ontology used by the structuring unit, according to some embodiments
  • FIG. 5 shows results obtained by interrogating the pivot database according to an exemplary embodiment
  • FIG. 6 represents the results of the class comparison for ACEBUTOLOL
  • Fig. 7 is a flowchart illustrating the method of generating the pivot database according to some embodiments.
  • FIG. 8 is a flowchart illustrating the method of generating the pivot database according to one embodiment.
  • FIG. 9 is a schematic view of a computer system that can be used to implement the device and method for generating the pivot database according to some embodiments.
  • FIG. 1 represents an example of an environment in which the device 1 00 for generating a pivot drug database 10 (also called a "common” or “transverse” drug database) can be implemented from data extracted from a plurality of data sources 2, each data source storing data relating to drugs according to a format or elementary structure specific to the source 2.
  • the data sources 2 are selected beforehand.
  • a “database” still referred to as “knowledge base” refers to a computer tool for storing and retrieving one or more data from the stored data by executing a query defined according to a query language. .
  • an 'ontology' refers to a semantic resource that best defines a field of knowledge.
  • An ontology can be represented as an oriented graph comprising nodes, the nodes representing concepts defined and connected by arcs - relations. Such definitions are described as logics of descriptions. In Noy N F, McGuinness DL.
  • Ontology development 1 01 A guide to creating your first ontology, an ontology is defined in particular as a formal explicit description of concepts in a knowledge domain (classes or concepts), the properties of each concept describing various characteristics and attributes of the concept ( still called roles or properties), and restrictions on attributes (also called role restrictions).
  • a 'reasoner' (computer tool) based on the various formal definitions of entities and concepts of an ontology can be used to infer new knowledge in the form of facts.
  • a 'fact' refers to the representation of an action or notion conceptually in the form of triplets. For example :
  • a 'pivotal ontology' refers to an ontology containing at least two joins to at least two other independent ontologies. It thus forms a thoughtful composition of several other ontologies of the same domain of knowledge in order to facilitate and better represent a notion, a concept through several formal definitions. A prior method can be applied to select and (re) form the desired definitions. This pivotal aspect makes it possible to quickly link annotated data by these different ontologies separately which were not intended to be interoperable at the origin.
  • an "annotation” refers to an assigned label on top of an object. An annotation thus makes it possible to provide a reference point above an object that does not have one.
  • a “knowledge base” refers to an ontology and a set of individual class instances (Noy NF, McGuinness DL). first ontology).
  • a knowledge base of the drug according to the invention is therefore a pivotal ontology instantiated with data describing the domain of the drug.
  • a knowledge base is thus associated with an instantiation of the pivotal ontology with real data coming from open access open data (for example Public Drug Database, Health Insurance ).
  • the structuring allows not only labeling by measures of textual similarities, but also semantic labeling.
  • the annotation process can use a structuring step to bring about disambiguation by providing a semantic context (semantic annotation).
  • semantic context semantic annotation
  • the data below can be considered elementary knowledge that can be integrated into the knowledge base (reentrant aspect): "I have a heart problem” ⁇ heart myocardium? , cardiac problem ?
  • an "extraction” designates a functionality making it possible to annotate / structure above more or less structured data. For example, for tabular data, this makes it possible to take into account the different columns and to make alignments between similar notions by means of annotations and to provide a context (of use, of definition) by means of a structuring. Since each source data has a heterogeneous nature, specific tools can be used for their deserialization and their comprehension. Extraction provides a link between structured vocabularies and real data.
  • the drug pivot database 10 thus generated according to the embodiments of the invention can be used in a drug analysis tool or device such as a drug interaction analyzer or a drug tool. help with the medical prescription.
  • the analysis device 20 can interact with client devices 50 according to a client / server architecture: the client devices 50 can issue requests according to a query language (for example SPARQL) and / or a protocol chosen via a graphical user interface 60
  • the server 200 of the analysis device 20 can query the common database 10 and generate a display of the results returned to it via the graphical interface 60.
  • the display of the results can be generated in the form of diagrams and / or data for example.
  • the display of the results can be generated in the form of an editable file in the prescription medical format, the user of the client device (general practitioner or specialist ) that can modify or supplement the prescription before finalizing it.
  • the common database 10 can be associated with a database management system for controlling the database and access to its contents, as well as application functions and / or a set of rules defining the rules. access to data.
  • Each client device 50 may be an electronic device that includes hardware, software, or integrated logic components capable of performing features. Examples of client devices 50 may include a computer system such as a desktop computer, a mobile electronic device such as a laptop, a tablet, a cell phone, a smartphone, etc.
  • Each client device 50 may allow its user to communicate with the analyzer over a network 3 using a graphical user interface 60 and command input (manual or voice), etc.
  • the user interface can be part of a dedicated WEB application, and be in the form of dedicated WEB pages.
  • the client devices can use any Man-Machine Interface functionally coupled with one or more processors of the computer system on which the analysis device 20 is implemented and allowing a user to interact directly with this computer system.
  • the Human Machine Interface may include a video or alphanumeric display, a touch screen, a speaker and any other visual and audio indicator capable of communicating data to the user.
  • the Human Machine Interface can also include devices and input controls such as an alphanumeric keypad, pointing device, keyboards, push buttons, control buttons, microphones, etc., capable of accept commands or inputs from the user and transmit them to the processor (s) of the computer system.
  • the device 100 for generating a pivot database 10 may be inputted to one or more data sources 2.
  • the data sources 2 may be heterogeneous databases storing data, each data being associated with a medicament according to any specific format or storage structure such as for example:
  • Data sources 2 may include data sources intended to take into account the different actors of the drug, for example:
  • Data sources 2 may for example include:
  • Data sources 2 can be constructed using different classifications in the field of medicine.
  • some data sources 2 may use the ATC classification (acronym for "Anatomical Therapeutic Chemical Classification System” meaning “anatomical therapeutic chemical classification system”).
  • This ATC classification published by the World Health Organization (WHO), includes a classification of "active ingredients” or “active substances” according to the organ or system on which they act, and their therapeutic and pharmacological properties. .
  • the ATC classification has 5 levels of hierarchy a 1st level corresponding to the main anatomical class; a second level corresponding to the therapeutic subclass;
  • an active substance can be classified several times, according to very different codes, and at all levels.
  • ⁇ ASPIRINE "UPSA 325mg” has ATC code B01 AC06, which corresponds to the pharmacological subclass of anti-thrombotic
  • ASPIRINES "UPSA 500 mg” and "UPSA 1000 mg” have both for ATC code N02BA01, corresponding to analgesics and antipyretics.
  • the indications of the active ingredients vary according to the countries, according to the Authorizations of placing on the Market (AMM) obtained, the same active principle will thus have different ATC codes according to the countries.
  • the concept of active substance is not specifically defined, and that the ATC classification is generally considered to classify "medicines". For a given drug, it may happen (rarely) that another code is used when the official ATC classification refers to an organ and therapeutic characteristics that do not correspond to ⁇ delivered in France.
  • certain combinations of active ingredients eg clavulanic acid + amoxicillin have their own ATC code of 5th level.
  • DCI International Nonproprietary Name
  • INNs International Nonproprietary Names identify "pharmaceutical substances or active pharmaceutical ingredients” (WHO). Each ICD is a globally recognized unique name in the public domain. We also speak of generic name.
  • oxacillin and ibufenac are INN and their salts are respectively called oxacillin sodium and ibufenac sodium). These last names are modified DCIs (DCIM).
  • modified INN may also be used for a base or an acid.
  • the name “levothyroxine sodium” has been published as INN; that of “levothyroxine” can therefore be described as DCIM.
  • Other data sources 2 can still use the CIS (Specialty Identifier Code) classification which designates the pharmaceutical specialty corresponding to the drug in its marketed form, thus having a commercial name, and supplemented with a dosage and a galenic form.
  • the CIS code is an 8-digit numeric code that identifies a drug regardless of its presentation (or conditioning). It is awarded by the ANSM.
  • CIP Presentation Identifier Code
  • the CIP classification is associated with a 13-digit code (for example 3400930000120) comprising:
  • the 13-digit CIP code is encapsulated in a coding data matrix that includes a lot number and the expiry date in addition to the 13 digits.
  • the 13-digit code is mentioned in the marketing authorization decision (decision and its annexes) of any proprietary medicinal product.
  • the marketing authorization decision decision and its annexes
  • UCD Common Dispensing Units
  • EPHMRA EPHMRA Anatomical Classification
  • EphMRA European Pharmaceutical Marketing Research Association
  • the same class or subclass defined in several classifications of the drug may differ from one classification to another or more generally from one data source 2 to another when these data sources are based on different classifications.
  • the same class or subclass may differ by its label which may be slightly modified in function of the data sources (and therefore of the classification they use), or by their semantics which do not describe the same overlaps.
  • therapeutic classes vary from one data source to another.
  • therapeutic classes defined by ANSM are different from those of ATC.
  • EPHRMA classes are also different.
  • the classifications used by the different data sources are not limited to the examples cited above and may include any classification or representation relating to the drugs.
  • the data sources 2 can therefore be based on a wide variety of classifications in the field of the drug, and constitute a set of very heterogeneous data sources forming a set of parcel information, of different granularities, and described with different classifications.
  • the device 100 is adapted to integrate this plurality of data sources in a homogeneous manner.
  • the device 100 for generating the pivot database can comprise:
  • a data extraction unit 3 for extracting the heterogeneous data coming from the different data sources 2; the extracted data may be referred to hereinafter as "initial data” or "unstructured data” to designate these data organized according to the heterogeneous formats / representations of the different data sources 2, some sources including data related to the drug that may not respond to standard medical semantics (eg Internet forum type data source);
  • a data structuring unit 4 configured to structure the extracted data by applying a pivotal drug ontology 40 to the extracted data; the data obtained after processing by the structuring unit 4 will be hereinafter referred to as "structured data”.
  • pivot database 10 comprising entries, each entry storing attributes associated with a value corresponding to the classes of the pivot ontology.
  • the data stored in the data sources 2 as well as in the pivot database can be represented by a graph.
  • the data sources 2 and those of the pivot database 10 may be specialized databases based on such graphs to ensure the persistence of the data and may be associated with semantic resources based on of facts of type: subject / predicate / object ("triplestores").
  • Figure 3 shows the database generation device 100 according to some embodiments.
  • the data extraction unit 3 may include a first parser 30 for browsing the drug data from the different sources 2.
  • the data can be retrieved from the different sources 2 in the form of one or more data description files according to a first format (also called "initial format", for example according to the Portable Document Format (PDF), meaning that the first parser 30 can be configured to browse through data from the description file (s) in the initial format and transmit the scanned data to a transformation function 31 configured to transform each data description file taken from the source databases 2 into a data description file according to a second editable format (for example, a text file (txt)).
  • a first format also called "initial format"
  • PDF Portable Document Format
  • the structuring unit 4 may be configured to search for similarity information between the data extracted from the data sources 2 by browsing each converted description file in the second format (also called "target format").
  • a second parser 41 can be used to search for similarity information with pivotal ontology concepts or classes 40.
  • similarity information may be collected then analyzed to associate the traversed data with classes and relations of the ontology (instantiation of the concept or the class of the ontology). This instantiation results in the construction of a graph representing the relations between the detected classes corresponding to the data traversed.
  • the data thus structured are stored in the pivot database 10 from the graph obtained.
  • the structuring unit 4 is thus configured to "contextualize" the heterogeneous data extracted by the extraction unit 3, which makes it possible to exploit them at best.
  • the "contextualization" operation carried out by the structuring unit 4 consists in applying the ontological model 40 of the drug (called “pivot ontology") to the data extracted by the extraction unit 3.
  • the pivotal ontology provides a useful representation of useful and usable data in the field of drug for use in applications related to drug interaction analysis or for prescription assistance (generation of drug recommendations).
  • Such a “contextualization” operation of the data makes it possible to transform the heterogeneous data sources 2 (also called “elementary data sources”) into a pivotal knowledge base 10 in which the extracted heterogeneous data relating to the drugs are maintained according to a common structuring. .
  • Such pivotal knowledge base 10 is adapted to execute complex queries that exploit the diversity and completeness of the data stored for applications relating to the analysis of interactions between drugs, in particular taking into account characteristics specific to the drugs (for example, the therapeutic class, the dose ).
  • the enriched knowledge base 10 as generated by the device 100 therefore allows many analysis applications in relation to the drug (eg study of new relationships not present in the original data).
  • Termino-ontological sources and resources in the field of the drug can be very numerous. As a result, some concepts used in relation to drugs in these sources and / or resources may be heterogeneously represented or described, their representation or definition not being shared by all the sources / resources.
  • the structuring unit 4 of the pivot drug database generation device 100 can be configured to homogeneously structure the extracted data by applying a new ontology pivot.
  • the structuring unit 4 can be configured to instantiate such pivotal ontology 40 of the drug with the extracted data, the ontology responding to a technical constraint specific to the field of the drug.
  • the structuring unit 4 thus offers a modular approach to the drug, which guarantees more flexibility for tools that rely on the heterogeneous knowledge base obtained while allowing, for specific use cases, the reuse of ontologies or specific models, such as the DIDEO model for drug interactions.
  • the structuring unit 4 can implement a pivotal ontology 40 based on a systematic and logical decomposition of a generic drug concept called "Drug” (Anglo-Saxon meaning “Drug”) according to the basic concepts. who composes it.
  • RxNorm The RxNorm model, developed and maintained by the US National Library of Medicine, within the Unified Medical Language System (UMLS), provides standardized drug names linked to the main existing databases (such as "First Databank”, “Micromedex”, “MediSpan”, “Gold Standard Drug Database”, etc. .).
  • RxNorm integrates the NDFRT ontology.
  • Rx Norm is typically used as a tool and support for interoperability between terminologies and drug knowledge bases.
  • RxNorm in its publicly available versions, has 1,18555 concepts, corresponding to drugs.
  • the RxNorm model is built from three founding entities: ingredient, dosage form and dose, which when combined, form the concept of "Clinical Drug".
  • the structuring unit 4 applies a new ontology in which is added this "Drug" concept, which allows links to CHEBI in particular (Chebi refers to the ontology "Chemical Entities of Biological Interest Ontology "which classifies the chemical and biochemical components in a structured way, ChEBI is a chemical ontology, which allows relationships between molecular entities or feature classes to be described in a structured way).
  • applied ontology includes a limited number of relationships between concepts, which limits the conflicts that exist in classical models (eg RXNORM).
  • the proposed ontology can be represented in OWL, there is no available representation of the semantic model of RXNORM in OWL.
  • the proposed device By structuring the data with the pivotal ontology applied by the structuring unit 4, the proposed device provides a heterogeneous knowledge base that can be queried with any query language or protocol that allows searching, adding, modifying or Remove Resource Description Framework (RDF) data available across the Internet such as Protocol and RDF Query Language (SPARQL).
  • RDF Resource Description Framework
  • the structuring unit 4 may be configured to instantiate the extracted drug data in the pivotal ontology 40 of the drug, using an application programming interface (API) of the OWL knowledge representation language to select for each element of the database the corresponding concept in the semantic model of the pivot ontology 40.
  • API application programming interface
  • the data are maintained in a pivotal knowledge base 10 thus structured.
  • the pivot knowledge base 10 thus obtained can receive requests according to a suitable query language such as SPARQL queries. Queries that can be processed by the knowledge base can be pre-programmed. In response to a request, the heterogeneous pivot knowledge base 10 can export the result that can be displayed in a graphical interface configured according to the application of the invention.
  • a suitable query language such as SPARQL queries. Queries that can be processed by the knowledge base can be pre-programmed.
  • the heterogeneous pivot knowledge base 10 can export the result that can be displayed in a graphical interface configured according to the application of the invention.
  • Figure 4 shows a simplified architecture of the pivot ontology 40 used by the structuring unit 4, according to some embodiments.
  • An ontology is classically defined as an explicit formal specification of a conceptualization, a “conceptualization” referring to a modeling of a phenomenon in the world by identifying the relevant concepts of this phenomenon.
  • An ontology is "explicit” in that the type of concepts and the constraints applied to the concepts are explicitly defined.
  • An ontology is "formal” in that, in essence, an ontology is a specification understandable by a machine, as opposed to natural language.
  • an ontology refers to a modeling of a set of data (or knowledge) in a given domain in the form of: - "Concepts” (also called “classes”), a concept being the representation of an entity of the domain; - "Properties” (also called “attributes”) related to the concepts.
  • the pivotal ontological model 40 can be used by the structuring unit 4 to integrate and / or process data extracted from the heterogeneous data sources 2, but also to determine new relationships based on parcel information extracted from the extracted data or to determine possible alignments between the data sources 2 (for example alignments between therapeutic classes as described in different sources 2).
  • the field of the drug has a transversal positioning related to a plurality of related domains: it is related to the field of pathologies, diagnoses, but also with biological mechanisms, and the genomic data, these domains being associated with specific ontological resources.
  • the pivotal ontology 40 can be further used by the structuring unit 4 to integrate such ontologies specific to these related domains from termino-ontological resources of the drug domain.
  • the pivotal ontological model 40 can rely on one or more reference models, such as the RXNORM model.
  • the RxNorm model is the international reference. It breaks down the drug into its three basic concepts (galenic, dose and ingredient). However, the Drug concept, as described for example in ChEBI, is not found in the RxNORM model. Moreover, RxNorm does not present a "high level" model inferring the relations described. Another disadvantage of RxNorm is the multiplicity of relations present in this model (28 paths for the 8 main concepts): if these relations make it possible to go through several "paths" to find information, they do not give all the same result.
  • the pivotal ontological model 40 is built using a semantic representation language such as the OWL language which is based on a logic of description.
  • a semantic representation language such as the OWL language which is based on a logic of description.
  • Other ontology representation languages may be alternatively used as OIL, DAML and DAML + OIL.
  • the OWL language consists of classes, instances and properties of which there are two categories: - the object properties ("owLObjectProperty”) which connect an object to another object, and
  • OWL sub-languages There are 3 OWL sub-languages: - "OWL-lite” which includes simple constraints;
  • the pivot ontology used 40 is based on a modular approach that makes it possible to establish mappings with the existing drug ontologies (RxNorm, CHEBI, etc.).
  • the pivot ontology 40 is based on key concepts including the concept Ingredient ("Ingredient") (400), the concept Drug ("Drug”) (401), and the concept Clinical Drug (“Clinical Drug”) (402) as defined in ontological models of the drug.
  • the concept "Drug” (401) is defined by CHEBI
  • the concept "Ingredient” (400) is defined by RXNORM.
  • the “Clinical Drug” concept (402) is derived from RXNORM, the NDFRT and VANDF models, and is related to the "Drug” concept through the pseudo-code relationship "Clinical Drug rdfs: SubclassOf Drug” (the “Clinical Drug” concept). is a subclass of the "Drug” concept).
  • Drug designating: "Any substance which, when absorbed by a living organism, can modify one or more of its functions. The term is generally accepted for a substance taken for therapeutic purposes, but is also commonly used for drugs ("abused substance”) "(as defined by the CHEBI ontology);
  • the concept of interest "ingredient” (400) can for example correspond to the classification DCI and the concept “clinical drug” (402) can correspond to the classification CIS.
  • Each module 400, 401, 402 of the ontology is independent and can be developed separately.
  • Such a modular approach is particularly adapted to a ontology of the pivotal drug, the existing ontologies being very numerous, and the drug being, by definition, in relation with a multitude of other concepts or related fields (symptoms, diseases, mechanisms of action biological, etc.) that are associated with many specific knowledge models.
  • the concept "Drug" (401) can be modeled as a class according to the ontology representation language used (eg OWL class) and is used as a higher class ("top class"). ) in accordance with the CHEBI ontology definition:
  • the higher concept "Drug” is the father of 9 entities, these "daughter” entities being modeled in the form of classes in the ontology representation language used (OWL classes for example) and including the classes :
  • Clinical Drug Clinical Drug Component
  • Composed Clinical Drug Component Form of Clinical Drug ( "Clinical Drug Form")
  • Form of Clinical Drug Compound “Composed Clinical Drug Form”
  • Clinical Drug can itself be defined as a son of the class “ClinicaIDrug Component” and the class “Clinical Drug Form", any instance of the class “Clinical Drug” being also an instance of these two classes.
  • pivotal ontology 40 are all subclasses of the "Drug” concept (related to the Drug concept by the “rdfs: SubClassOf Drug” relationship).
  • the concept of "Drug” is linked by the relation "has_ingredient” (relation formed of Anglo-Saxon words that can be translated as “own_ingredient”) to the concept "Ingredient”. Some restrictions may also be implemented.
  • Clinical Drug Component "ClinicaIDrugComponent"
  • the pivotal ontology 40 can be described according to Appendix 3.
  • the pivotal ontology 40 has been compared with classes described by ATC at the 2 nd level ("2 digit") and the classes described by the ANSM Interaction Thesaurus.
  • the classes corresponding to the last level of the ATC (7 digits), and the second level (2 digit) as well as an ANSM family class were created using the OWL API application interface from the data describing ANSM classes, constructed from the thesaurus of drug interactions.
  • the "OWL API" Application Interface is a JAVA language API for creating, manipulating and serializing OWL termino-ontological resources.
  • this molecule belongs only to the therapeutic subclass of beta-blockers in ATC.
  • this molecule is classified in five different classes: i) antihypetens except alpha-blocker, ii) betablocker (except esmolol and sotalol) iii) beta-blocker (except esmolol) iiii) bradycardic, iiiii) blood pressure lowering drug.
  • Fig. 7 shows the knowledge base generation method according to some embodiments.
  • step 700 the unstructured drug data is extracted from the data sources 2.
  • step 702 the pivotal ontology, previously loaded, is applied to the extracted data (instantiation step of the ontology) and the pivot database 10 is generated in step 704.
  • Step 702 can comprise retrieving the extracted data using a parser 30 to apply the pivot ontology to the retrieved data.
  • structured data associated where appropriate with a category are thus grouped in a structured database 10 enriching existing heterogeneous databases 2 while offering centralized access to heterogeneous drug data in a structured format.
  • Figure 8 shows the method of generating the pivot database according to one embodiment.
  • the extraction step 700 may comprise:
  • a step 7001 of retrieving the data from each data source 2 in the form of at least one description file in a first format for example a "PDF" format
  • transformation rules transformation rules
  • the format of the description file may be different for the different data sources 2.
  • the format (second format) in which each description file is converted from the data sources 2 may advantageously be the same regardless of the formats original extracted description files (first formats).
  • the instantiation step of the ontology 702 can then include the path of each description file in the second format 7021, and the instantiation of the classes of the ontology from the traversed data 7025 for each file traversed.
  • step 7021 can include the traversal of each CSV file and then the instantiation of a class of the pivot ontology from the identified information 7025.
  • the step 702 may include a search for semantic similarity information 7023 between the traversed data corresponding to the data extracted from the data sources 2 and the concepts of the pivot ontology.
  • the similarity information detected can then be associated with concepts or classes of the pivotal ontology (for example the class "indications”, the class “contraindications”, the class "known interactions", the class "date of AMM
  • the data extracted from initially unstructured data sources 2 are then structured by assigning them the concepts or class of the pivot ontology.
  • the pivot database 10 can be used in a drug-related analysis device or tool 20 including a graphical interface configured according to the application of the invention (prescription assistance , pharmacovigilance, etc.).
  • the device 20 may be implemented as a tool shared by a plurality of client devices via a network (the analyzer 20 may be implemented as a WEB application tool) or a device configured for use with the client. use of each client device.
  • the requests can be entered in the graphical interface 60 for example by entering drug names in fields provided on the graphical interface.
  • the validation of the request (for example SPARQL) by the user generates the interrogation of the database.
  • the knowledge base returns the result of the query, the tool 20 generating the display of the results on the graphical interface based on the representation of the data of the pivot ontology.
  • the display of the results depends on the application of the invention and the configuration of the graphical interface 60.
  • a SPARQL request may be issued by informing a drug or a molecule to query the data of the knowledge base.
  • heterogeneous that are contained in the concept equivalent to molecules or drugs.
  • several drugs can be entered on the graphical interface, the execution of the SPARQL query triggering the search in the heterogeneous knowledge base of drug interactions between the drugs filled.
  • the pivot database 10 can be used in a device 20 configured to handle drug interactions.
  • a Drug Drug Interaction refers to the effect that results from concomitant or sequential administration of two or more drugs.
  • the pivot database 1 0 allows efficient management of DDI and limits the number of annual deaths related to DDI (it is estimated that the DDI in France are responsible for 8,000 deaths per year in France, and 1 30 000 hospitalizations. DDI repositories can be directly used for help with prescription and / or prescription analysis.
  • the drug interaction analysis device 20 can be used to detect whether a patient treated with "zyloric” can receive a penicillin.
  • the pivot database 10 makes it possible, for example, to determine that the active substance of "Zyloric” is allopurinol, to determine all the drugs of the penicillin class, among which is the penicillin subclass A for example, to search for there are interactions between allopurinol and all active substances included in penicillins, and to deduce that the association between "zyloric” and drugs sub-category "penicillin A" is to be taken into account (amoxicillin , ampicillin ...) to the extent that there is an increased risk of skin disease if these drugs are combined.
  • the device 20 for analyzing and managing DDI makes it possible to overcome situations in which the physician does not have all the information concerning the prescription in question or has incomplete or inaccurate information (ie "Augmentin” without dosage or galenic, or still “acetylsalicylic acid” (INN) without specifying the trade name).
  • DDI complementary data sources
  • PDDI potential interactions
  • DDI may change depending on the dosage, the dosage form, and even the indication in which the drug has been prescribed (source ANSM Thesaurus), it is particularly advantageous to treat information from a multiplicity from sources 2, on different semantic levels and with granularities heterogeneous (therapeutic classes and DCI).
  • the analysis device 20 can also be used in applications for identifying the misuse of drugs on the forums (pharmacovigilance). Indeed, some forums related to health can represent an important source of data, provided by patients on the actual use of the drug.
  • This Internet Forum type data source 2 has an unstructured format of the data it collects, as well as different types of granularity. Indeed, the users of these forums are often unlikely to provide all the information using the appropriate medical semantics (such as the notions of "dosage” or "galenic”), and express themselves rather using the name commercial drug (eg "Doliprane” or "Augmentin") or more general terms ("Antibiotic” or "Anti depressant”).
  • the method and device for generating a drug data pivot database 10 makes it possible to manage the information collected in such internet forums in a centralized manner, regardless of their level of granularity and the semantics used, by using the a pivotal ontology that maps such unstructured information to a common level of granularity and / or semantics. Such data sources can thus be exploited transparently in drug misuse identification tools.
  • the invention is not limited to use of the pivot database in prescription assistance or drug interaction analysis but may be used more generally in all drug-related analysis device such as, for example, a device for the management of undesirable drug effects, "precision medicine” involving the optimization of treatments for each individual, etc.
  • Such analysis devices 20 make it possible to respond to important public health issues based on the exploitation of multiple data sources having heterogeneous representations or classifications, which can depend on different languages when they come from several countries.
  • the device 1 00 for generating a pivot drug database 10 and the analysis device 20 thus make it possible to manage, integrate and exploit such heterogeneous sources of data concerning the drug.
  • the methods according to the embodiments may be implemented in a variety of hardware or software or hardware and software combinations, such as program code be distributed in the form of a program product, in various forms.
  • the program code may be distributed using computer readable media, which may include computer readable storage media and communication media.
  • the methods described in the present description can in particular be implemented in the form of computer program instructions executable by one or more processors in a computer computing device. These computer program instructions may also be stored in a computer readable medium.
  • the analysis device 20 can be implemented in the form of one or more computer devices or systems 90 (hereinafter referred to as a computer).
  • the computer 90 may comprise a processor 91, a memory 92, a mass storage memory device 95, an input / output (I / O) interface 97 (for example, a video screen, a touch screen, input devices and commands such as alphanumeric keyboard, pointing device, keypads, pushbuttons, control buttons, microphones, etc.).
  • the computer 90 may also be operatively coupled to one or more external resources 99 via a network 96 and / or an I / O interface 97.
  • the external resources 99 may include, but are not limited to, servers, bases data, mass storage devices, peripheral devices, cloud-based network services, or any other appropriate computer resource that can be used by the computer 90.
  • the processor 91 may include one or more processor devices such as microprocessors, microcontrollers, central processing units, or any other device that manipulates signals (analog or digital) based on operations instructions which are stored in the memory 92.
  • the processor 91 may operate under the control of an operating system 93 which resides in the memory 92.
  • the operating system 96 may manage computer resources such as an integrated computer program code in the form of one or more software applications 94 residing in the memory 92.
  • the pivot database 10 can reside on a mass storage memory device 95. It can be used to collect and organize the data used by the different systems and modules of the computer 90.
  • the pivot database 10 can include data and accommodate the associated data structures that store and organize the data.
  • the pivot database can be organized according to any form of database structure, including, but not limited to, a relational database, a database of the type hierarchical, a networked database, an object-oriented database, or combinations of these forms of databases.
  • a database management system in the form of application computer software that executes as instructions on a processor eg processor 91
  • the pivot database 10 in response to a request, when the request is executed by the operating system 93, the applications 94, or one or more modules. It will be understood by those skilled in the art that the embodiments of the invention can use any appropriate database management model, and are not limited to a particular type of database.

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Databases & Information Systems (AREA)
  • Data Mining & Analysis (AREA)
  • Health & Medical Sciences (AREA)
  • Medical Informatics (AREA)
  • Public Health (AREA)
  • General Physics & Mathematics (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • Epidemiology (AREA)
  • General Health & Medical Sciences (AREA)
  • Primary Health Care (AREA)
  • Pathology (AREA)
  • Biomedical Technology (AREA)
  • Chemical & Material Sciences (AREA)
  • Bioinformatics & Cheminformatics (AREA)
  • Medicinal Chemistry (AREA)
  • Pharmacology & Pharmacy (AREA)
  • Toxicology (AREA)
  • Computational Linguistics (AREA)
  • Software Systems (AREA)
  • Life Sciences & Earth Sciences (AREA)
  • Animal Behavior & Ethology (AREA)
  • Medical Treatment And Welfare Office Work (AREA)

Abstract

Dispositif et procédé de génération d'une base de données relative aux médicaments L'invention propose un 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) 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 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 la 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 Applications : outils d'analyse des interactions médicamenteuse, outil d'aide à la prescription médicale.

Description

DISPOSITIF ET 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 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 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 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 certains pays (Ronning 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. 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 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 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, 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 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 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
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 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 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;
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. 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 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. 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 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 :
- Une classe principale « Ingrédient » ;
- Une classe principale « Médicament » ; et
- Une classe principale « Médicament Clinique »,
les trois classes principales étant indépendantes. 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 ». 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 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 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.
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 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 ;
-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 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 description qui suit et des figures des dessins annexés dans lesquels:
Description des figures - 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;
- 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 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;
- 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.
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 é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
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. La figure 1 représente un exemple d'environnement dans lequel peut être implémenté le dispositif 1 00 de génération d'une base de données de médicaments pivot 1 0 (encore appelée base de données de médicaments « commune » ou « 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.
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.
Pour faciliter la compréhension de certains modes de réalisation, les définitions additionnelles ci-dessous sont fournies :
Telle qu'utilisée ici une 'ontologie' désigne une ressource sémantique définissant au mieux un domaine de connaissances. Une ontologie peut être représentée comme un graphe orienté comprenant des nœuds, les nœuds représentant des concepts définis et connectés par des arcs - relations. De telles définitions sont décrites comme des logiques de descriptions. Dans Noy N F, McGuinness DL. Ontology development 1 01 : A guide to creating your first ontology, une ontologie est notamment définie comme une description explicite formelle de concepts dans un domaine connaissances (classes ou concepts), les propriétés de chaque concept décrivant des caractéristiques et des attributs variés du concept (encore appelés rôles ou propriétés), et des restrictions sur les attributs (encore appelés restrictions de rôles). Un 'raisonneur' (outil informatique) s'appuyant sur les différentes définitions formelles d'entités et de concepts d'une ontologie peut être utilisé pour inférer de nouvelles connaissances sous formes de faits. De plus, un 'fait' désigne la représentation d'une action ou d'une notion de manière conceptuelle sous forme de triplets. Par exemple :
DOLIPRANE_BIOGARAN_lG_PELL - "est une"" SPECIALITE_PHARMACEUTIQUE
En liant ces différentes entités (concepts et relations), des inférences selon les natures des relations peuvent être obtenues. Ainsi, si la relation est transitive : pour A → B → C, il est inféré que A→C
Plusieurs natures peuvent être décrites dans le format de représentation de logiques de descriptions. Un 'raisonneur' représente alors le moteur s'appuyant sur ces différentes natures des entités liées afin d'inférer de nouvelles connaissances.
- Telle qu'utilisée ici, une 'ontologie pivot' désigne une ontologie contenant au moins deux jointures, vers au moins deux autres ontologies indépendantes. Elle forme ainsi une composition réfléchie de plusieurs autres ontologies du même domaine de connaissance afin de faciliter et de mieux représenter une notion, un concept au travers de plusieurs définitions formelles. Un procédé préalable peut être appliqué afin de choisir et de (re)former les définitions recherchées. Cet aspect pivot permet de rapidement inter-lier des données annotées par ces différentes ontologies séparément qui n'avaient pas pour but d'être interopérables à l'origine.
Telle qu'utilisée ici, une « annotation » fait référence à une étiquette assignée au dessus d'un objet. Une annotation permet ainsi de fournir un point de référence au dessus d'un objet qui en est dépourvu.
Telle qu'utilisée ici, une « base de connaissance » (encore appelée ici 'base de données') désigne une ontologie et un ensemble d'instances individuelles de classes (Noy NF, McGuinness DL. Ontology development 101 : A guide to creating your first ontology). Une base de connaissance du médicament, selon l'invention, est donc une ontologie pivot instanciée avec des données décrivant le domaine du médicament. Une base de connaissances est ainsi associée à une instanciation de l'ontologie pivot avec des données réelles provenant de données ouvertes libre d'accès (par exemple Base de données publique de médicaments, Assurance Maladie ...).
- Une 'structuration' désigne un processus réentrant via l'usage d'une base de connaissance et du raisonneur afin de donner du sens à une donnée. S'appuyant sur les différentes notions formellement décrites, la structuration permet non seulement un étiquetage par des mesures de similarités textuelles, mais aussi un étiquetage sémantique. Le procédé d'annotation peut utiliser une étape de structuration afin d'apporter une désambiguïsation en apportant alors un contexte sémantique (annotation sémantique). Par exemple, la donnée ci-dessous peut être considérée comme connaissance élémentaire qui pourra être ensuite intégrée au sein de la base de connaissance (aspect réentrant) : " j ' ai un problème de coeur " → coeur le myocarde ? , problème cardiaque ?
- Telle qu'utilisée ici, une « extraction » désigne une fonctionnalité permettant de rendre possible l'annotation / structuration au dessus de données plus ou moins structurées. Par exemple, pour des données tabulaires, cela permet de prendre en compte les différentes colonnes et effectuer des alignements entre des notions approchantes au moyen d'annotations et apporter un contexte (d'usage, de définition) au moyen d'une structuration. Chaque donnée source possédant une nature hétérogène, des outils spécifiques peuvent être utilisés pour leur désérialisation et leur compréhension. L'extraction permet d'établir un lien entre les vocabulaires structurés et les données réelles.
La base de données pivot de médicaments 10 ainsi générée selon les modes de réalisation de l'invention 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 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 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 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 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 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 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 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 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, 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).
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 :
- 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)) 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,
- 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 :
- 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 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.
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 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 thérapeutiques et pharmacologiques.
La classification ATC comporte 5 niveaux de hiérarchie un 1 er niveau correspondant à la classe anatomique principale ; un 2ème niveau correspondant à la sous-classe thérapeutique ;
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 :
J ANTI INFECTIVES FOR SYSTEMIC USE
J01 ANTIBACTERIALS FOR SYSTEMIC USE
J01F MACROLIDES , LINCOSAMIDES AND STREPTOGRAMINS
JOIFF Lincosamides
ATC Code Name
J01FF01 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 Γ ASPIRINE « UPSA 325mg » a pour code ATC B01 AC06, 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 N02BA01 , correspondant aux antalgiques et antipyrétiques.
Il convient de noter que les indications des principes actifs variant selon les pays, 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. II 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 (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 pas à ΓΑΜΜ 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 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.
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 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 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 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)
son dosage
son conditionnement et la contenance de son conditionnement. La classification CIP est associée à un code à 13 chiffres (par exemple 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.
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 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.
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 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 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 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.
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 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 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 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 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 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 ».
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 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 »).
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 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 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 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 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 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 parcourues. Les données ainsi structurées sont stockées dans la base de données pivot 10 à partir du graphe obtenu.
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 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 (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 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 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 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, 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 sou rces/Ressou rces.
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é 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 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.
Plus précisément, l'unité de structuration 4 peut mettre en œuvre 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.
Le modèle RxNorm, développé et maintenu par l'US National Library of Medicine, au sein de l'Unified Médical 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 », 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 1 18555 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 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 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). 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 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 .
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 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 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. 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 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.
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 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 ensemble de données (ou connaissances) dans un domaine donné sous forme de : - « Concepts » (encore appelés « classes »), un concept étant la représentation 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 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).
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é 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.
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 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 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 dont il existe deux catégories : - les propriétés objet (« owLObjectProperty ») qui relient un objet à un autre objet, et
- les propriétés typées (« owLDataTypeProperty ») qui relient un objet a une valeur typée.
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.
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 (« Ingrédient ») (400), le concept Médicament (« Drug ») (401 ), et le concept 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 « Ingrédient » (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 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 « Ingrédient » (400) désignant "un composé ou une fraction 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 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 de la ressource terminologique RxNorm). Le concept d'intérêt "ingrédient" (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 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 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 :
• le concept « DRUG » 401 a pour ingrédient un ou plusieurs ingrédients pharmaceutiques « Pharmaceutical Ingrédient »,
• le concept « DRUG » 401 a au moins un ingrédient pharmaceutique (« Pharmaceutical Ingrédient »),
• le concept « DRUG » 401 n'a pour ingrédient que des ingrédients pharmaceutiques (« Pharmaceutical Ingrédients »).
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 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 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 (« 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).
Le concept « Clinical Drug » peut être lui-même défini comme un fils de la classe « ClinicaIDrug 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 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 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 « 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 « Ingrédient ». Certaines restrictions peuvent être également implémentées.
Par exemple, le concept Composant de Médicament Clinique « ClinicaIDrugComponent » 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 2eme 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 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.
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 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 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) 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 œuvre par le dispositif 100, de 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.
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 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.
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é.
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.
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 :
- 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 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.
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).
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 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 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 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 1 0 peut être utilisée 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 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 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 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.
Dans une application de l'invention, la base de données pivot 1 0 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 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. » (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 : 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 1 0 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 responsables de 8 000 morts par an en France, et de 1 30 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 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 « 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 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 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), 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).
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é 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 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 1 0 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 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 de la base de données pivot 1 0 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 « précision medicine » impliquant l'optimisation des traitements pour chaque individu, etc.
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 langues lorsqu'elles sont issues de plusieurs pays.
Le dispositif 1 00 de génération d'une base de données de médicaments pivot 1 0 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.
L'homme du métier comprendra que les procédés selon les modes de réalisation peut être mis en œuvre 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 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 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 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 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 l'ordinateur 90.
Le processeur 91 peut inclure un ou plusieurs dispositifs processeurs tels que des 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 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 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 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 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 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. ANNEXES
Figure imgf000035_0001
ANNEXE 3
Figure imgf000036_0001

Claims

REVENDICATIONS
1 . Dispositif de génération (100) d'une base de données de médicaments pivot (1 0) 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 (1 0) 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 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 :
- Une classe principale « Ingrédient » (400) ;
- Une classe principale « Médicament » (401 ) ; et
- Une classe principale « Médicament Clinique » (402),
les trois classes principales étant indépendantes.
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 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 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 (1 0) 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 (1 0) en réponse à au moins une requête reçu d'un dispositif client et à retourner le résultat au dispositif client.
1 0. 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.
1 1 . 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'analyse des interactions médicamenteuses.
12. Procédé de génération d'une base de données de médicaments pivot (10) 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 ;
-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 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.
PCT/EP2017/079810 2016-11-21 2017-11-20 Dispositif et procede de generation d'une base de donnees relative aux medicaments WO2018091714A1 (fr)

Priority Applications (1)

Application Number Priority Date Filing Date Title
US16/461,776 US11210314B2 (en) 2016-11-21 2017-11-20 Device and method for generating a drug database

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR1661257 2016-11-21
FR1661257A FR3059118B1 (fr) 2016-11-21 2016-11-21 Dispositif et procede de generation d'une base de donnees relative aux medicaments

Publications (1)

Publication Number Publication Date
WO2018091714A1 true WO2018091714A1 (fr) 2018-05-24

Family

ID=58401679

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2017/079810 WO2018091714A1 (fr) 2016-11-21 2017-11-20 Dispositif et procede de generation d'une base de donnees relative aux medicaments

Country Status (3)

Country Link
US (1) US11210314B2 (fr)
FR (1) FR3059118B1 (fr)
WO (1) WO2018091714A1 (fr)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FR3112019A1 (fr) 2020-06-26 2021-12-31 Posos Système de recommandation pharmacologique

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20090037389A1 (en) * 2005-12-15 2009-02-05 International Business Machines Corporation Document Comparison Using Multiple Similarity Measures
US8429179B1 (en) * 2009-12-16 2013-04-23 Board Of Regents, The University Of Texas System Method and system for ontology driven data collection and processing

Family Cites Families (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20100318537A1 (en) * 2009-06-12 2010-12-16 Microsoft Corporation Providing knowledge content to users
US10509814B2 (en) * 2014-12-19 2019-12-17 Universidad Nacional De Educacion A Distancia (Uned) System and method for the indexing and retrieval of semantically annotated data using an ontology-based information retrieval model

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20090037389A1 (en) * 2005-12-15 2009-02-05 International Business Machines Corporation Document Comparison Using Multiple Similarity Measures
US8429179B1 (en) * 2009-12-16 2013-04-23 Board Of Regents, The University Of Texas System Method and system for ontology driven data collection and processing

Non-Patent Citations (4)

* Cited by examiner, † Cited by third party
Title
CLÉMENT JONQUET ET AL: "The Open Biomedical Annotator", PROCEEDINGS OF AMIA JOINT SUMMITS N TRANSLATIONAL SCIENCE, 1 March 2009 (2009-03-01), XP055382112, Retrieved from the Internet <URL:https://www.ncbi.nlm.nih.gov/pmc/articles/PMC3041576/> [retrieved on 20170616] *
FOOD AND DRUGS ADMINISTRATION: "Structured Product Labeling > Section Headings (LOINC)", 9 February 2016 (2016-02-09), XP055382141, Retrieved from the Internet <URL:https://www.fda.gov/ForIndustry/DataStandards/StructuredProductLabeling/ucm162057.htm> [retrieved on 20170616] *
GUOQIAN JIANG ET AL: "ADEpedia: a scalable and standardized knowledge base of Adverse Drug Events using semantic web technology", AMIA ... ANNUAL SYMPOSIUM PROCEEDINGS / AMIA SYMPOSIUM. AMIA SYMPOSIUM, 1 January 2011 (2011-01-01), United States, pages 607, XP055382031, Retrieved from the Internet <URL:https://www.ncbi.nlm.nih.gov/pmc/articles/PMC3243176/pdf/0607_amia_2011_proc.pdf> [retrieved on 20170614] *
SOON AE CHUN ET AL: "Social Health Data Integration using Semantic Web", SAC'12, MARCH 25-29, 2012, RIVA DEL GARDA, ITALY, 29 March 2012 (2012-03-29), pages 392 - 397, XP055232354, Retrieved from the Internet <URL:http://dl.acm.org/citation.cfm?id=2245351> [retrieved on 20151130], DOI: 10.1145/2245276.2245351 *

Also Published As

Publication number Publication date
FR3059118A1 (fr) 2018-05-25
US11210314B2 (en) 2021-12-28
US20190361906A1 (en) 2019-11-28
FR3059118B1 (fr) 2019-11-01

Similar Documents

Publication Publication Date Title
US12093271B2 (en) Method and system for text understanding in an ontology driven platform
US9384327B2 (en) Semantic interoperability system for medicinal information
JP2022526242A (ja) テキストドキュメントのアノテーションのための方法、装置、およびシステム
Schulz et al. Strengths and limitations of formal ontologies in the biomedical domain
Marco-Ruiz et al. Publication, discovery and interoperability of clinical decision support systems: a linked data approach
Batra et al. Organizing standardized electronic healthcare records data for mining
CN111415719B (zh) 患者用药教育的推送方法及装置、电子设备及介质
KR20170052020A (ko) 질의 응답형 질병분류코드 제공 시스템
Naz et al. Ontology-driven advanced drug-drug interaction
Cossin et al. Romedi: an open data source about French drugs on the semantic web
WO2021260333A1 (fr) Système de recommandation pharmacologique
FR3059118B1 (fr) Dispositif et procede de generation d&#39;une base de donnees relative aux medicaments
Drezen et al. From medico‐administrative databases analysis to care trajectories analytics: an example with the French SNDS
Chapman et al. A semi-autonomous approach to connecting proprietary EHR standards to FHIR
Stenzhorn MOnSTER: Multi-Ontology Trial Enrichment Resource
Ataman An ontology based representation of semantic annotations for biomedical relations extracted from scientific documents
Jagesar Neonatal Care Admission Optimized-a data processing architecture for real time data, to manage the bed capacity at birth centres
Krimpen A Multi API approach for Natural Language Processing in Unstructured Clinical Documents
Elkin et al. Compositionality
Milward Semantic model driven engineering
Safaei et al. Requirement specification of an ontology-based semantic recommender system for medical prescriptions and drug interaction detection
IL283262A (en) An automatic system for diagnosis that includes rodents
Elkin et al. Compositionality: An implementation guide
BEALE et al. 78 Electronic Health Records and Communication
Grebla et al. A proposed data driven architecture for cardiology network application

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 17801452

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 17801452

Country of ref document: EP

Kind code of ref document: A1