1 / 40

Automatic Strategies for Decision Support in Telephone Triage

Automatic Strategies for Decision Support in Telephone Triage. Framework and Testbed in Smalltalk. Carlos E. Ferro ceferro@ciudad.com.ar Director: Dan Rozenfarb. Agenda. Introduction Software Application: ExpertCare Overview of the Framework: Concept representation

corinne
Télécharger la présentation

Automatic Strategies for Decision Support in Telephone Triage

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Automatic Strategies for Decision Support in Telephone Triage Framework and Testbed in Smalltalk Carlos E. Ferro ceferro@ciudad.com.ar Director: Dan Rozenfarb

  2. Agenda • Introduction • Software Application: ExpertCare • Overview of the Framework: • Concept representation • Session, automation and simulation • Strategies • Some statistics • Examples and results

  3. Telephone Triage • Phone call from a patient • Initial data gathered • Questions and answers • Presumptive diagnosis • Ambulance dispatch or treatment indications

  4. ExpertCare Initial identification data on a standard form

  5. ExpertCare Selection of all initial symptoms reported by the caller

  6. ExpertCare • New questions are suggested. • Answers are recorded. • Diagnoses are re-evaluated. Question in plain Spanish Session information List of scored diagnoses List of symptoms

  7. ExpertCare As new information is gathered,some diagnoses are separated according to their score

  8. ExpertCare composition Ontology Inference Engine Scorer Knowledge base:Symptoms, Syndromeswith attributes Interrogator Modules of ExpertCare system Interrogatory Rules

  9. ExpertCare ontology • Symptoms (e.g. fever, headache, dyspnea) • Syndromes (e.g. appendicitis, osteomyelitis, asthma, schizofrenia) • Systems (e.g. circulatory, digestive) • Severities (red, yellow, green) • Frequencies (high, medium, low)

  10. ExpertCare syndrome definition Syndrome definitions are logical expressions in terms of symptoms. Examples: Definition of Appendicitis : “right iliac fossa pain” AND “abdominal pain” ANDNOT “appendix operation” Definition of Massive Obesity : “intense weight increase” OR “intense body fat increase”

  11. ExpertCare size in numbers Rules account for 50% of size, but 80% of complexity and 90% of costs. They also hinder software evolution.

  12. Target Our main metrics is the amount of questions: • Red (Emergency): 3 or 4 questions • Yellow (Urgency): 4 or 5 questions • Green: around 6, but may reach 12

  13. Solution approach • Automated strategy • Dynamic interrogatory • Navigation and gathering of information from the knowledge base • Adaptation to session status • Framework for session and strategies • Virtual lab as testbed

  14. Concept representation

  15. Logical expressions for definitions

  16. Session, Diagnoses and other

  17. Automation • AnswerProvider simulates a patient/caller • Strategy guides the interrogatory, suggesting #nextQuestionFor: aCallSession • SUnit tests run through all syndromes using different strategies • StatisticalCollector gathers and caches information from the knowledge base

  18. Grouping and statistics

  19. Grouping and statistics

  20. Grouping and statistics

  21. Step-by-step example • This is a typical red syndrome. • According to the definition, AnswerProvider can choose among 8 pairs of symptoms (2x4). • Each one is called a subsyndrome Diabetic Ketoacidosis System: Metabolic Frequency: Low Severity: Red Definition: (DiabetesOR History of diabetes) AND (UnconsciousnessOR ConfusionOR Ketonic breath ORDyspnea)

  22. Step-by-step example Choosing clues: • Diabetes Systems pregnancy and metabolic • Confusion  Associated to 9 different systems • Let’s choose Diabetes as a clue, and try to establish the presence of Confusion, in order to make a Diabetic Ketoacidosis diagnosis. Diabetic Ketoacidosis_2 Definition: DiabetesANDConfusion

  23. Example - Step 1 Choosing symptoms to ask: We should try to discern the system from among these two 772 syndromes 51 systems Diabetes positive evidence 2 systems 18 syndromes 6 syndromes 2 systems

  24. Example - Step 1 Choosing symptoms to ask: Using information from the knowledge base and some abductive reasoning, we have 9 candidates left. We choose symptompregnancy, in order to confirm or discard system pregnancy. System pregnancy 6 syndromes 31 symptoms System metabolic 13 syndromes 48 symptoms Diabetes System pregnancy 1 syndrome 1 symptom System metabolic 5 syndromes 8 symptoms

  25. Example - Step 2 Now we “know” that only one system has chances left. 772 syndromes 51 systems Diabetes Not pregnancy positive evidence 1 system 5 syndromes

  26. Example - Step 2 Now we try to discern severity, first trying to decide whether it is red or yellow. Using information from the knowledge base and some abductive reasoning, we have 8 symptom candidates left. Here is where we need some tool for comparing or choosing among them. For instance, we could ask for symptom dyspnea. System pregnancy 6 syndromes 31 symptoms System metabolic 13 syndromes 48 symptoms 1 syndrome 3 syndromes 9 syndromes Diabetes Not pregnancy System pregnancy 0 syndrome 0 symptom System metabolic 5 syndromes 8 symptoms 1 syndrome 2 syndromes 2 syndromes

  27. Example - Step 3 The new information did not reduce syndromes 772 syndromes 51 systems Diabetes Not pregnancy Not dyspnea positive evidence 1 system 5 syndromes

  28. Example - Step 3 System metabolic 13 syndromes 48 symptoms 1 syndrome We still try to discern severity, because “not dyspnea” only rejected some branches of some syndromes, but did not reduce the total number. Now we have 7 symptom candidates left. This way, we could use up to 7 more questions to “hit” the symptom that the simulated patient has and make a diagnosis. 3 syndromes 9 syndromes Diabetes Not pregnancy Not dyspnea System metabolic 5 syndromes 8 symptoms 1 syndrome 2 syndromes 2 syndromes

  29. Strategies • One family of first attempts, using none or little information: SequentialStrategy, RandomStrategy, MoreSatisfiersStrategy, LessSatisfiersStrategy, MiddleSatisfiersStrategy, MoreCriticSeparationStrategy • Second family, attempting to guess the system by different indicators: GuessSystemByFrequencyStrategy, MoreCorrelationStrategy, LessNegationStrategy, GuessSystemStrategy, GuessSystemUsingPairsStrategy, LessNegationPairStrategy

  30. Results of preliminary strategies

  31. Strategies - Support We coined the notion of support • Intuitively, it is a numeric representation of the degree of likelihood of a given set of syndromes in the current session. • Calculation is straigthforward. • Syndromes with full diagnoses add a large positive value. • Syndromes with disproved diagnoses add a large negative value. • For the rest, symptoms confirmed add positive value and symptoms negated add negative value. • Finally we perform a normalization.

  32. SupportSeparationStrategy The third family of strategies is based on support. • Most promising results • 15 different strategies • Hierarchy 7 levels deep • Every level evolving from the previous one • SUCCESS according to target

  33. Results of support strategies

  34. Results of support strategies

  35. Results of support strategies

  36. Conclusions and remarks It was great doing this work because: • Enhancing the ExpertCare application could have a direct impact on the population’s health. • Automated strategies allow ExpertCare architecture to be used in other domains. • We applied a scientific research approach and techniques to this “real world” software problem. • We learned from Artificial Intelligence, Object-Oriented Programming and Medicine in an interdisciplinary work.

  37. Conclusions and remarks Smalltalk proved to be an adequate tool because: • Representation of the knowledge base was almost trivial. • Building a virtual lab for essays and benchmarks was very easy. • Additional tools for exploring the knowledge base and studying it were easy to implement. • There were no barriers for implementing and testing several strategies with diverse heuristics. • It was easy to get feedback and to debug troublesome cases, in order to enhance and refine strategies

  38. Future work (technical) • A visual tool for representing the session. It should be some navigational metaphor. • The tool could be enhanced for tracing during simulation runs. • More tools for developers to understand and interact with strategy/session. • More tools for better comparative benchmarking.

  39. Future work (domain model) • Integrate with ExpertCare • Incorporate exceptions and special rules • Test with real samples • Try some adaptation to other knowledge bases

  40. The End Questions?

More Related