Decision Support

ES, version 2024-03-26  /

• Problem:
  • A large amount of biomedical knowledge is in principle already available but the question is now how to use the knowledge in a more efficient way.
  • Decision are not always optimal in situations where there is not enough time, less than 5 minutes per patient or limited qualifications on site.
• Objectives:
  • Assisted Intelligence, helping but not replacing the local responsible health professional.
  • Assistance for differential diagnoses in an interactive way.
• Approaches:
  • Task oriented approach:
    • The goal is to try to solve the problems of the patient. Think you are in an emergency department. A new patient arrive. You heave only a few information and you have to take the first decisions, according to meaningful priorities.
    • Up to now many "medical record" systems where only describing what did happen for statistical purposes. Of course already very useful and making at least the patient information available for the doctor who has to take decisions. But on itself not much contribution to the next decisions !
  • Initial decisions:
    • First most basic rules.  For example:
      • Starting from a symptom, seek which Problems may be suspected.
      • Looking at every of these Problems, seek which Observations should be explored in order to increase or decrease the probability of these Problems.
      • Given a Problem it should become possible to recommend some actions with their relative expected usefulness and negative side effects.
    • Play with this small sets of information.  Add or change some Observation and see the consequences on the relative likelihood of problems and following recommenced actions.
    • Any new patient information or any modification should lead to a new evaluation.
      
  • "Obervations":
    • Here Observation of facts without any judgment yet.  Many kinds of Observations like answers from the patient, physical examination, lab test, images, ...
      
    • In general when a new patient arrives few information is available. Only a few major complaints or abnormal findings.
    • Obsevations should be normalized by means of functions. 
      
  •  "Problems":
    • In order to help patient, the very first common sense question is the identification of problems. A problem is here any kind of issue requiring attention, as well abnormal complaints or findings to be understood.  When a Problem is well understood it may become a diagnose.
    • Given the current set of symptoms and observations, evaluate the likelihood of one or more Problems or "Health Issues".
    • At any time the Problem List must be maintained up-to-date. The problem list of the patient could be sorted in different ways according to:
      • Probability of the presence of the problem.
      • Potential severity.
    • Iterations:
      • When new information become available, the problem list should be re-evaluated. The probability of some problems may increase or decrease.
      • Iterations will continue until problem(s) become very likely and become usually called a confirmed "diagnose".
    • Strategies:
      • The initial approach is simply to try to understand the reasoning process of experienced clinicians.  Up to now intuitive decisions of experienced doctors could achieve good results. This analysis should be represented as graphs explaining the diverse arguments which did lead to the identification of problems. Anyhow graphs will facilitate the discussions between several medical experts.
      • In the future the approach could become to try to make more precise decision schema, taking account of the very large body of scientific knowledge nowadays available.
    • Precision of problems:
      • Possibility of several degrees of granularity. For example an "infectious syndrome"  when there is probably an infection while having not yet any idea about location and the infectious agent.  Decision schema could include intermediary steps in hierarchies.
  • "Actions"Evaluation of possible actions in function of the likelihood of problems:
    • Given some "Problem" different types of Action may be proposed:
      • Recommend to require more information in order to confirm or exclude the considered Problem.
      • Recommend to prescribe directly some treatments.
    • Depending on the likelihood of a problem:
      • If very low:
        • The problem will be considered as excluded and no further action is recommended.
      • If intermediary probability:
        • As far as possible new information should be explored, by more questions to the patient, more examinations and/or more technical tests.
        • Since it would never be possible to explore all the possible kinds of information (>10.000) it is necessary to make a selection of the most useful requests, as well to evaluate their relative priorities.
        • Timing, in principle actions are always expected to provide a result soon or later, typically:
          • Immediately e.g. for a question to the patient, of for a blood pressure measurement.
          • After a few hours in case of a lab test. Sometime a reminder may be necessary.
          • After weeks as for example in case of prescriptions. If no news, in general good news are assumed, although the worse cannot be excluded ?
        • Goals of treatment recommendations:
          • Life expectation.
          • Quality of life, for example in case of palliative care.
      • If very high:
        • The problem is considered to become a confirmed diagnose and the possibilities of treatments must be considered based on:
          • Expected advantages.
          • Risks and costs.
          • Level of certainty of the diagnose:
        • Objectives of treatments:
          • Priorities for life expectation or comfort ?
    • Recommendation list:
      • The recommendation list will be sorted on relative priorities. Normally the action proposed at the top of the list will be the next action, but the user does not necessarily validate actions as proposed.
  • Multiple factors:
    • In general multiple factors of decision will be found in the Knowledge Graph.
    • These factors may have different importance or weights, represented by coefficients, in principle normalized from 0. to 1.
    • More than one kind of weight could be relevant.
    • Asymmetry, for example the absence of an Observation may be discriminant, while its presence would not be much useful.
    • Uncertainty is everywhere and recommendations are based on likelihoods.
    • The evaluation of incomplete lists of multiple factors of different weights will require "Fuzzy Logic". Thresholds are critical and must be defined. Trade-off have to be made.
    • Keep in mind that problems are not exclusive. Sometimes more than one problem may exist at the same time.
    • Any unexplained finding  must be explored.
  • Transparency:
    • As far as possible the recommendation must be explained, with the arguments leading to the conclusion.
    • The obligation to formulate explicitly your current vision about a case is on itself a factor of care quality. 
    • Improvement of the collaboration with colleagues in charge of a common patient. Different opinion may appear and stimulate discussions.
    • Indirectly the transparency is a contribution to continued education.
  • Shared decision and Responsibilities:
    • Traditional human decision may be a collaboration between several actors with different level of experience trust. "Computer Assisted Intelligence" can be seen as one more actor, representing the team of medical experts who did build and maintain the medical knowledge base.
      
    • The final responsibility relies on the healthcare professional directly in charge of the patient. The human must always explain his decision.
      
    • In this project, anyhow the patient record must be presented as a graph. To what extend the decision is based on human and computer does not matter.
      
    • The system is trustworthy and reliable as far as the user trust the authors and maintainers of the knowledge base.
    • The maintainers of the knowledge base and the decision engine are responsible to provide the best possible synthesis of current knowledge.
    • Resposability issues arise when:
    • Trusting a poorly trustable actor.
    • Not listening to a well recognized actor, including not listening to an good AI actor.
      
  • Decision engine:
    • Introduction:
    • There are 2 critical components, at one side the decision engine and at the other side the knowledge base.
      
    • The idea is to split the developments in 2 branches:
      • ( 1 ) Here the decision engine:
        • Creation of a set of generic rules intended be steered by the the knowledge graph data base.  As far as possible the decision engine should be reusable  in different situations.
        • The general requirements will be defined by medical experts and here data scientists and software developer will have to find solutions about how to manage the information.
        • Human feeling could sometimes still be included in the decision process, as one of the factors with a relative weight.
      • ( 2 ) A separated chapter of the project will be dealing with the content of the knowledge graph
    • This page look first at a common decision engine. This could be extended with specific rules in function with the objective i.e. finding the most likely diagnose or seeking the most appropriate treatment.
  • Activation of decision procedures:
    • Every time when new information comes in, a new evaluation of the situation is necessary. This should be propagated at different levels.
  • External decision modules:
    • Possibility to delegate some decision processes. For example:
      • Given row ECG signal ask interpretation by an external system.
      • Given images ask if to be seen as normal or not.
    • The result of such an external procedure is then considered as an observation.
  • Pure Artificial Intelligence:
    • It is not yet clear how far pure AI could be useful in healthcare, when not taking account of any bio-medical scientific knowledge.
    • Artificial Intelligence works well when a very large base of reference is available.  In practice individual patients are mostly different.  At the end the reference material is usually based on human experts.
• Evolution:
  • Begin with simple problems:
    • Kind of decisions:
      • Initial focus simply on recommendations about what should be investigated next, given what is already available. For example:
        • If complaints of pain the next questions would be where, when, how long, etc...
        • If anemia, recommend next lab test for iron, vitamin B12, etc...
      • Risks:
      • At the initial stage the risks of the experimental model are limited. Maybe a few wasted minute for unnecessary question, or a few unnecessary lab tests.
        
      • Recommendation about treatments should also be considered. but maybe at a later stage.
    • Medical domains:
      • Initial prototype limited to a small medical domain. Which one exactly does not much matter since the goal is to make prototypes of  some generic decision rules. The medical domains will mostly depend on the preference of the participants of the project.
    • Assume that all the data are already available as graph:
      • Write small prototypes directly as graph, both for knowledge and patient information. Do not yet spend time on NLP, Natural Language Processing.
  • Needed resources:
    • Decision support require graph of both medical knowledge and patient record.
    • Expertise in medicine and data science.
• Challenges:
  • Analysis of the current situation:
    • Traditional decision strategies currently in use by doctors, decision trees, scores, ...
  • Prototype:
    • Begin to make a very simple prototype limited to a few symptoms and disease, which can be presented as a visual graph.
    • Take account of relationships of different weights.
    • Recommendation of more investigations
    • ...
• Contacts:
  • etienne@saliez.be, ...