Clinical Decision Support Systems in Biomedical Informatics and their Limitations

1. Clinical Decision Support Systems in Biomedical Informatics and their Limitations Alberto De la Rosa Algarín Computer Science & Engineering University of Connecticut, Storrs alberto.delarosa.algarin@engr.uconn.edu

2. Overview • Clinical Decisions • What types of clinical decisions exist? • Requirements for excellent decision-making • Definition of Decision Support Systems • History • First possibility of a CDSS • First prototype and the shortcomings • Better CDSS (MYCIN, HELP, Leeds System) • Existing Systems • Pathfinder, Iliad, DiagnosisPro, CKS, HDP, etc. • Limitations • Patient’s Role, Usability (and performance), Knowledge sharing and maintenance and Security

3. Clinical Decisions • Two types of clinical decisions: • Diagnosis decisions • Diagnosis process • Diagnosis decisions • Done analyzing to determine the cause of sickness • Diagnosis process • Used to determine which questions to ask in order to make better diagnosis decisions

4. Requirements for excellent decision-making • Accurate data: • Bad data is useless obviously • Good data is equally useless if there is no knowledge on how to apply it. • Pertinent knowledge • The overload of information affects the process of decision making in a negative way. • Overload of information can be seen in the ICU • Appropriate problem-solving skills • The glue between the correct use of accurate and pertinent knowledge.

5. Goal • The goal of clinical decision support systems (CDSS) is to emulate the clinician’s thought process during diagnosis.

6. Definition of Decision Support Systems • A decision support system is a system in which one or more computers and computer programs assist in decision making by providing information. • They can exist as hardware-software solutions or stand alone software applications.

7. History • The possibility first appeared in 1959 [Ledley & Lusted] • With the use of symbolic logic, probability theory and value theory, the foundations of medical diagnosis could be understood. • The first prototype appeared in 1964 [Walker et al.] • Issues with logistics, scientific shortcomings related to medical diagnosis, and the lack of integration to the workflow made the widespread use and adoption virtually impossible.

8. History • After this, several CDSS appeared that tackled the previous pitfalls (MYCIN, Leeds System and HELP) • MYCIN [Shortliffe, 1976] • A consultation system for patients with infections • Leeds Abdominal Pain System [De Dombal et al., 1972] • A system for the diagnosis of acute abdominal pain • HELP [Warner, 1979] • A system to alert clinicians in case of abnormalities in patient records

9. Types • Information Management Systems • Provide an environment for the storage and retrieval of information. • Decision is left to the clinician. • Focusing Attention Systems • Alert clinicians when a conflict arises. • Follow simple logic. • Patient-specific Recommendation Systems • Offer advice to a single patient using the patient’s medical history. • Can use simple logic, decision theory, cost-benefit analysis, etc.

10. Requirements of a CDSS • Clinical decision support systems must satisfy the following requirements in order to be widely accepted and used: • Patient Data Acquisition and Validation • Medical Knowledge Modeling, Elicitation, Representation and Reasoning • System Performance • Integration to the Workflow

11. Requirements: Patient Data Acquisition • There is no standard way to acquire data. • Current methods range from keyboard to natural language processing. • Some health care professionals even use intermediaries like nurses or secretaries. • The end goal is to capture patient data without disrupting the workflow.

12. Requirements: Patient Data Validation • Tons of coding systems exist for the validation of patient data. • Sadly none of the existing coding systems capture the subtle differences and the high details of the patient’s health care. • A clinical decision support system should be able to work with both detailed and general patient data. • And the system’s performance should not be affected by the type of data.

13. Requirements: Medical Knowledge Modeling • Knowledge modeling is necessary for the identification of relationships and concepts. • Modeling is also used to decide what patient data is pertinent and what strategies to use. • These tasks require a large amount of modeling. • Luckily several methods exist that do a pretty good job regarding medical knowledge modeling. • Common KADS [De Hoog et al., 1994] • CASNET [Weiss et al.]

14. Requirements: Medical Knowledge Elicitation • Current clinical decision support systems obtain knowledge and then work directly with the clinician. • But a clinical decision support system should be able to evoke useful knowledge seamlessly. • But this implies methods that facilitate the use of knowledge-bases.

15. Requirements: Medical Knowledge Representation • The interpretation of trends is intuitive for clinicians. • For example, trends of sickness, trends of the results of medical treatments. • Clinical decision support systems must be able to represent the knowledge like trends. • But to achieve this, the clinical decision support system must emulate the clinicians intuition.

16. Requirements: Medical Knowledge Reasoning • Computer systems have the capability of storing large amounts of factual knowledge. • Clinical decision support systems should be able to • Discern which knowledge is useful for the task at hand. • Know how to apply the knowledge in order to obtain worthy results. • The solution for this requirement is in the realm of artificial intelligence.

17. Requirements: System Performance • Clinical decision support systems should be able to use ALL the pertinent data and knowledge available. • At the same time, the systems should be able to use the most updated data and knowledge. • This implies a lot when we talk about the use of knowledge-bases. • On top of it all, decision support should appear in an instant manner while maintaining high accuracy.

18. Requirements: Integration to the Workflow • The most difficult of the requirements to fulfill. • Integration to the workflow requires fulfilling a couple of previous requirements: • Patient Data Acquisition • Knowledge Representation • System Performance • If a clinical decision support system is able to fulfill these previous three requirements, integration is given.

19. Existing Systems • There has been a surge of clinical decision support systems from the 1980’s to the present day. • Their applications range from infectious disease diagnosis to cardiovascular treatment predictions.

20. Pathfinder (1992) • Explains, acquires, represents and manipulates uncertain medical knowledge. • Uses probability and decision theory as strategies • Deductive reasoning is used to provide diagnosis • But the system is designed so that no recommendations are done • The user interface is menu based and mouse driven • Feature category, observed features and differential diagnosis are the windows in the initial screen.

21. Pathfinder’s Deductive Reasoning Model

22. Iliad (1988) • Uses Boolean and Bayesian frames to represent knowledge. • The system has four basic components: • Inference engine • User interface • Data driver • Best information algorithm • Currently used as a teaching tool for medical students. • Particular cases are simulated so that students learn how to diagnose.

23. DiagnosisPro (1993) • Uses differential diagnosis to remind the user of possible diagnoses in an effort to reduce medical errors. • The knowledge-base is huge: • 11,000 diseases • 30,000 findings • 300,000 relationships • Information for the knowledge-base is taken from medical sources such as JAMA, Oxford Textbook of Medicine and others.

24. DiagnosisPro’s User Interface

25. Heart Disease Program (HDP) (1980’s – 90’s) • Assists the clinician in anticipating the effects of therapy in cardiovascular disorders. • Uses strategies as: • Knowledge-base and physiologic model • Probabilities • Constraints • Differential Diagnosis • The user interface is menu driven

26. Heart Disease Program’s Differential Summary

27. Clinical Knowledge Summaries (CKS) (2007) • Helps clinicians make decisions about a patient’s health and provides strategies on how to use those decisions. • Provides knowledge on topics about common acute and chronic diseases and their prevention • Offers quick answers on how to manage common clinical scenarios • Built on the existing PRODIGY knowledge-base. • It is a web-based clinical decision support system, accessible from around the world.

28. Clinical Knowledge Summaries’ User Interface

29. Dxplain (1987) • Combines characteristics of an electronic medical textbook with characteristics of a medical reference system. • Provides information on different diseases • Emphasizes in signs and symptoms • The knowledge-base includes: • 2,400+ diseases • 5,000+ symptoms, signs, lab data and clinical findings

30. VisualDx (2006) • Java-based and image driven • Designed for point-of-care reference • One of the main functions is the facilitation of image matching for the end user, achieved with: • Graphical search tools • Knowledge-base of relationships • Thousands of digital images • Used to develop differential diagnoses based on morphologic and patient driven search. • Its focus is on infectious diseases.

31. VisualDx’s User Interface

32. INTERNIST-1 / QMR Project (1974 - 80’s) • Designed to provide assistance in general internal medicine • Both INTERNIST-1 and QMR rely on the INTERNIST-1 knowledge-base • INTERNIST-1 works as a high-powered diagnostic consultant tool. • QMR acts as an information tool • Provides ways to manipulate and review diagnostic information for the knowledge-base

33. EON System (1996) • Consists of four general purpose components: • Constructs patient-specific treatment plans • Infers high level abstract components • Performs time-oriented queries in time-oriented patient database • Allows the acquisition of protocol knowledge • The design principles that create a base for the EON system are problem-solving methods and domain ontologies. • Because of the difficulties of long-term maintenance of knowledge-bases, PROTÉGÉ-II is used.

34. EON System Architecture

35. Snapshot of our clinical decision support systems

36. Limitations • Existing clinical decision support systems suffer from limitations difficult to overcome. • Patient’s Role • Usability • System Performance • Knowledge Sharing and Maintenance • Security • Such limitations slow the adoption rate of clinical decision support systems.

37. Limitations: Patient’s Role • The patient’s role is not defined in clinical decision support systems. • Patients are just the source of data for the clinical decision support system to work on.

38. Limitations: Patient’s Role • The answers to those questions do not only have implications in a moral or ethical sense, but can also provide the patient evidence for legal matters. • The patient will want to know every detail regarding his health. • After all, patients provide every bit of their personal information in order to get the best care. • Clinicians would like to withhold information for different matters. • For example, the clinician would like to be the one to break the news in case of a serious disease.

39. Limitations: Usability • Biggest hurdle current clinical decision support systems have to overcome. • Health care professionals don’t like change. • No current system integrates in the workflow seamlessly. • This is the result of shortcomings in system performance and human-computer interaction.

40. Limitations: Usability • A busy clinician would only want pertinent information. • A less busy clinician, or one who needs every detail to reach a diagnosis, would appreciate a high level of detail. • Clinicians do not like to modify the usual workflow to input data. • New methods aim to bridge the gap between non-digital and digital data acquisition. • For example: TIMOS LINK • Preference on data input changes by person.

41. Limitations: System Performance

42. Limitations: System Performance • Accurate support is the purpose of clinical decision support systems. • Current methods are not accurate enough to be widely used. • QMR’s accuracy being % in ED scenarios. • Iliad’s accuracy being % in ED scenarios. • At the same time, no matter how accurate, if a decision support takes to long to appear, it is useless.

43. Limitations: Knowledge Sharing • Knowledge-bases are specific to each clinical decision support system. • Its actually one of the “selling points” of current solutions. • Used to differentiate existing systems from others in an effort to stand above. • The bigger the knowledge-base, the more decision support (and more accurate) the system is able to offer.

44. Limitations: Knowledge Sharing • Having a centralized knowledge-base, or at least a framework that allows for current knowledge-bases to be shared, would improve reliability and accuracy across different clinical decision support systems. • Standards exist in an attempt to consolidate. • The problem is that there are so many standards, everyone uses a different one. • We need a standard of standards.

45. Limitations: Knowledge Maintenance • Maintaining knowledge and managing pieces of the clinical decision support systems are critical for successful delivery of decision support. • Knowledge-base maintenance requires a lot of work. • Current methods rely on periodical update by humans.

46. Limitations: Knowledge Maintenance • Periodical updates by human intervention is a primitive approach to knowledge maintenance. • The latest knowledge and information could be put on hold for months until the knowledge-base’s update is due. • This goes against one of the original requirements: • Clinical decision support systems should utilize the latest knowledge available.

47. Limitations: Security • Clinical decision support systems provide an equal level of recommendations to whoever has access to the system. • Clinical decision support systems that exist as part of an EMR have some level of security. • Systems that exist as stand alone solutions do not.

48. Limitations: Security • We have to remember that other professionals (such as nurses, pharmacists, etc.) are an equal part of the patient’s well-being. • It is natural to think that clinical decision support systems should have some level of role-based access control.

49. Concluding Remarks • A long road lies ahead of CDSS. • Improvements must be made in order to increase the adoption of clinical decision support systems. • Usability • System Performance • Knowledge Handling • Existing technologies and ideas offer possibilities to resolve several of the limitations. • Other limitations require a compromise in order to be solved.