Designing a self-medication application on Semantic Web technologies. Olivier Curé UPEM LIGM, France

Transcription

1 Designing a self-medication application on Semantic Web technologies Olivier Curé UPEM LIGM, France

2 Overview Self-medication applications Symptom & Drug DB

3 Overview Self-medication applications Symptom & Drug DB Inductive creation KB / Ontology

4 Overview Self-medication applications Symptom & Drug DB Data quality Inductive creation KB / Ontology

5 Overview Self-medication applications Symptom & Drug DB Data quality Inductive creation KB / Ontology Reasoning To detect profiles

6 Overview Self-medication applications Symptom & Drug DB Data quality Inductive creation KB / Ontology Reasoning To detect profiles

7 Outline 1) Semantic Web background 2) Self-medication & context 3) Inductive creation of an ontology 4) Data quality 5) Traces 6) Integrating medical sources 7) Conclusion 7

8 1. Semantic Web background 8

9 Presentation "The Semantic Web is an extension of the current web in which information is given well-defined meaning, better enabling computers and people to work in cooperation." (T. Berners-Lee & al, The Semantic Web, Scientific American, Vol 284, number 4, 2001) 9

10 Semantic Web cake 10

11 Resource Description Framework (RDF) A data model based on <Subject Predicate Object> triples. Signature de (S,P,O) (U B) x U x (U B L) Supports the definition of labeled oriented graphs <?xml version="1.0"?> <rdf:rdf xmlns:rdf=" xmlns:contact=" <contact:person rdf:about=" <contact:fullname>eric Miller</contact:fullName> <contact:mailbox rdf:resource="mailto:em@w3.org"/> <contact:personaltitle>dr.</contact:personaltitle> </contact:person> </rdf:rdf> 11

12 RDF graph 12

13 RDF Schema A language to describe vocabularies (ontologies) Not expressive, only defines sub classes, sub properties, domain and range. 13

14 Web Ontology Language (OWL) Based on Description Logics 14

15 SPARQL A query language for RDF Conjunctive queries using pattern matching Contains variables ('?' prefixed) joins PREFIX rdfs:< PREFIX ub:< PREFIX owl:< PREFIX rdf:< SELECT?x WHERE {?x rdf:type ub:graduatestudent.?x ub:takescourse < } 15

16 Linked Open Data 16

17 2. Self-medication & context 17

18 Presentation The act of treating oneself: Without advice from health care professionals with or without OTC drugs Associated risks: inefficient drug wrong dosage drug interactions side-effects delay interventions etc. 18

19 What we know about selfmedication Difficult to: access objective and understandable information on mild clinical signs and OTC drugs. find the most efficient drug in a therapeutic class. 19

20 Who is able to provide this information Not the general practitioner Not the pharmacist and commercial pressure not objective information (pharmaceuticals pressure) no time to do it Drug labels contain these information (contra indications, side effects, etc.) 20

21 Goal of the application Provide a user-friendly GUI for an efficient and safe self-medication. Designed with Jean-Paul Giroud (MD PhD, WHO expert). Main author of more than 12 books on pharmacology and self-medication. 21

22 Application Long term collaboration with a team of health care professionals (WHO expert in pharmacology). Design a self-medication web application to supports patients for a safe and efficient practice. Used by 3 major insurance companies and targets over 6 million clients. iphone application released in march

23 Components of the system A database containing: 125 symptoms complete info on 4000 OTC drugs incomplete info on remaining 6000 drugs of the french market a rating of efficiency/tolerance ratio for each drug Ontologies to support reasoning for both the back and front end of the application (ATC/DDD, EphMRA). 23

24 Prototype overview 24

25 Simplified Electronic Health Record For a given patient, stores: general information (login, dob, gender, current state, etc.) allergies known diseases drug treatments All encoded with classifications 25

26 'Diagnostic' module (1) Anamnesis, the patient: selects an anatomical area. then chooses a symptom among a list replies to questions. 26

27 'Diagnostic' module (2) A set of drugs may be proposed, e.g. coughing 27

28 3. A self-medication ontology 28

29 Using knowledge To diagnose proper drug to a given patient To enhance data quality in terms of completeness soundness Existing classifications do not contain enough knowledge 29

30 Inductive reasoning Enriching terminologies on some selected characteristics using probabilistic inductive reasoning from DB tuples Inductively inferred axioms correspond to dependencies needed to be satisfied contraindication Indication classification Drug sideeffect 30

31 Concept creation ATC relation Code Name R Respiratory system R5 Cough and cold preparations R5D Cough suppressants, excluding combinations with expectorants R5DA Opium alkaloids and derivatives R5DA8 Pholcodine R5DA9 Dextromethorphan Tuples become OWL concepts Concepts at the same level are disjoint Cascade of codes is represented as a subsumption hierarchy. <owl:class rdf:about="&p1;r5da9"> <rdfs:subclassof rdf:resource="&p1;r05da"/> <owl:disjointwith rdf:resource="&p1;r05da8"/> <rdfs:comment xml:lang="en">dextromethorphan </rdfs:comment> 31 </owl:class>

32 Ontology enrichment Using DB to enrich ontology concepts Enrichment in terms of data stored in relations. For each selected attribute: Create a Concept, e.g. ContraIndication Create instances for these concepts using the tuples of the database, e.g. Respiratory insufficiency. Create a Data type property, e.g. hascontraindication. 32

33 Concept enrichment For a given concept hierarchy in the ontology: Create groups of tuples for each concept involved in the hierarchy. For each selected attribute: Calculate the ratio of attribute value occurences on the total number of elements of the group. For a given hierarchy, the most general concept with a ratio superior to a (predefined) selection threshold is enriched. 33

34 Example 1 Drug relations Contra-indications for the respiratory system R R5 R5D R5DA R5DA Occurences Inductive reasoning ContraId

35 Example 2 Contra-indications for the respiratory system R R5 R5D R5DA R5DA Occurences ContraId <owl:class rdf:about="&p1;r5da9"> <rdfs:comment xml:lang="en">dextromethorphan </rdfs:comment> <rdfs:subclassof> <owl:restriction> Enrichment <owl:onproperty rdf:resource="&p1;hascontraindication"/> <owl:hasvalue rdf:resource="&p1;ci_20"/> </owl:restriction> </rdfs:subclassof>... </owl:class> <p1:contraindication rdf:about="&p1;ci_20"> 35 <rdfs:comment xml:lang="en">pregnancy </rdfs:comment></p1:contraindication>

36 Resulting ontology Can be used to generate labels Can be used to check stored labels GUIs to deal with uncertainty Semi-automatic approach 36

37 Future works Integrate disease, adverse events classifications Translate in other languages (drug database is needed for each country) Analyze patient traces 37

38 4. Data quality 38

39 Motivation Quality of the applications depends on the quality of the database (DB). Dynamic aspect of the domain: drugs (dis)appear on the market, compositions are modified, some active principles become excipients, etc. 39

40 DB checking Dealing with exceptions: Semi-automatic approach, meaning that Health care professionals are involved in the process of data quality checking. To ease this task, we designed a graphical approach: a matrix emphasizes possible violations of the ontology constraints enables direct interaction to repair data 40

41 Semi-automatic repairing Groups of tuples are formed according to concepts of the ontology, e.g. a concept corresponding to a given EphMRA code. 41

42 Declarative approach Defining novel forms of dependencies with constant values: conditional dependencies. We have defined functional, inclusion and exclusion conditional dependencies. They are represented as SPARQL queries which are performed after database updates. They tackle both completeness and correctness of the database. The system is able to propose possible values. 42

43 Declarative approach (2) Intuitively, they extend their non conditional counterpart with tableau patterns containing constants. Example: contra[id; CINAME ] compo[id; COMPNAME ], T with T : 43

44 Conclusion Investigate other forms of conditional dependencies With disjunction With uncertainty measures Novel methods to discover conditional dependencies 44

45 5. Traces Join work with Yannick Prié and Pierre-Antoine Champin from Université Lyon 1, LIRIS 45

46 Motivation Interaction traces consist of temporally situated recordings of Observed elements (obsels). Obsels are elements observed during the interaction of an end-user within a given application. Given a set of interaction traces harvested from a given end-user, can we assist the personalization user interface, enrichment of end-user experience and improve the efficiency of the application? 46

47 Approach Providing a semantics to interaction traces using an approach characterized as follows: Declarative Logic-based (Description Logics) Dealing with uncertainty via probabilities Modular ontologies Use case: a data cleaning medical application 47

48 Architecture overview 48

49 Ontology distribution 49

50 Graph instance 50

51 5 interaction levels 1) Field level: which kind of fields in the Domain Specific Ontology have been observed. 2) Object level: generalize on a given object description 3) Obsel level: generalization of obsels 4) Trace level: generalize an interaction trace 5) Subject level: defining a user-profile 51

52 Reasoning other traces 3 algorithms are proposed Simplified Most Speficic Concept (MSC) is based on a normal form and produces a DL concept for the object and obsel levels. Probabilistic Least Common Subsumer (LCS) approximates a probabilistic (using simpmsc) view of the obsels to generate a definition trace. Set Probabilitic Concept is used at the subject level to generalize on a set of interaction traces. A certain rewriting of a probabilistic concept is computed based on a predefined threshold. 52

53 Conclusion Useful to many actors of the system: End-user, developer and staff manager Evaluation Gain in productivity Accuracy of generated profiles 53

54 6. Integrating medical sources 54

55 Motivation Design a self-medication Web application using data sets and ontologies of Linked Open Data Participation to the Semantic Web Challenge at ISWC Finished 3rd over 21 contenders in the open track. 55

56 LOD data sets Used: DailyMed: marketed drugs DBpedia: general health information DrugBank: small molecules SIDER: adverse events of marketed drugs Currently not used Diseasome: disease and disease genes Freebase: general health information... 56

57 Symptom feature Select among a list of selfmedication symptoms Select among a list adapted molecules and get LOD information on that molecule Interact to obtain contraindicated drugs Go to DrugBank for drug prices Get information on drugs containing this molecule 57

58 Symptoms and molecules selection Store mappings between our molecule identifiers and LOD identifiers, e.g., Drugbank. Search the molecule ontologies for a set of self medication molecules. Extract Symptoms and therapeutic classes to create correspondences to DBPedia entries. Add a rating to selected molecules. 58

59 Drug selection Consider completeness of the Dailymed dataset given our molecule ontology: A link to a drug page is created only if sufficient data can be retrieved. Completeness operation is performed: using identifier correspondences, e.g., side effects, contraindications. amount of information that can be retrieved 59

60 Additional feature Obtain information on LOD molecules and drugs Get explanations on how to practice self-medication and how molecules are rated Get instructions to drive/walk to a nearby pharmacy. 60

61 Used technologies RDF, SPARQL and triple store for LOD OWL molecule ontology Reasoning over the ontology to select selfmedication symptoms, molecules and drugs. Mappings between different sets of identifiers Web application: HTML5, CSS, APIs (geolocation, Google Maps and places) Rest services returning JSON 61

62 Conclusion Easier to design a LOD-based tool for health-care professionals than the general public. Certainly more datasets to consider. Work needed on data quality: propose contents that can be understood to the general public guarantee completeness and correctness of drug information 62

63 7. Conclusion Most of the approaches presented here can be applied to other domains. There is room for more ontology-based solutions to concrete problems. Future works (medical) Handle compound drugs more efficiently, consider all drugs Future works (SW) More efficient RDF stores: compressed, distributed and RDFS inferences enabled Extend query languages Uncertain reasoning 63

64 Thanks Questions? 64