Transcript Clinical Decision Support Systems in Biomedical Informatics and their Limitations

CSE
5095
Clinical Decision Support Systems in
Biomedical Informatics
and their Limitations
Alberto De la Rosa Algarín
Computer Science & Engineering
University of Connecticut, Storrs
[email protected]
CDSS-1
Overview
CSE

5095



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
CDSS-2
Clinical Decisions
CSE

5095
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
CDSS-3
Requirements for excellent decision-making
CSE

5095
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.
CDSS-4
Goal
CSE
5095

The goal of clinical decision support systems (CDSS)
is to emulate the clinician’s thought process during
diagnosis.
CDSS-5
Definition of Decision Support Systems
CSE
5095

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.
CDSS-6
History
CSE

5095

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.
CDSS-7
History
CSE

5095
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
CDSS-8
Types
CSE
Information
5095


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.
CDSS-9
Requirements of a CDSS
CSE

5095
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
CDSS-10
Requirements: Patient Data Acquisition
CSE

5095
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.
CDSS-11
Requirements: Patient Data Validation
CSE

5095
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.
CDSS-12
Requirements: Medical Knowledge Modeling
CSE

5095
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.]
CDSS-13
Requirements: Medical Knowledge Elicitation
CSE

5095
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.
CDSS-14
Requirements: Medical Knowledge Representation
CSE

5095
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.
CDSS-15
Requirements: Medical Knowledge Reasoning
CSE

5095
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.
CDSS-16
Requirements: System Performance
CSE

5095
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.
CDSS-17
Requirements: Integration to the Workflow
CSE

5095
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.
CDSS-18
Existing Systems
CSE

5095

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.
CDSS-19
Pathfinder (1992)
CSE

5095
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.
CDSS-20
Pathfinder’s Deductive Reasoning Model
CSE
5095
CDSS-21
Iliad (1988)
CSE

5095
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.
CDSS-22
DiagnosisPro (1993)
CSE

5095
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.
CDSS-23
DiagnosisPro’s User Interface
CSE
5095
CDSS-24
Heart Disease Program (HDP) (1980’s – 90’s)
CSE

5095
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
CDSS-25
Heart Disease Program’s Differential Summary
CSE
5095
CDSS-26
Clinical Knowledge Summaries (CKS) (2007)
CSE

5095
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.
CDSS-27
Clinical Knowledge Summaries’ User Interface
CSE
5095
CDSS-28
Dxplain (1987)
CSE

5095
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
CDSS-29
VisualDx (2006)
CSE

5095
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.
CDSS-30
VisualDx’s User Interface
CSE
5095
CDSS-31
INTERNIST-1 / QMR Project (1974 - 80’s)
CSE

5095
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
CDSS-32
EON System (1996)
CSE

5095
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.
CDSS-33
EON System Architecture
CSE
5095
CDSS-34
Snapshot of our clinical decision support systems
CSE
5095
CDSS-35
Limitations
CSE

5095

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.
CDSS-36
Limitations: Patient’s Role
CSE

5095

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.
CDSS-37
Limitations: Patient’s Role
CSE

5095
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.
CDSS-38
Limitations: Usability
CSE

5095

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.
CDSS-39
Limitations: Usability
CSE

5095

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 nondigital and digital data acquisition.
 For example: TIMOS LINK

Preference on data input changes by person.

CDSS-40
Limitations: System Performance
CSE
5095
CDSS-41
Limitations: System Performance
CSE

5095
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.
CDSS-42
Limitations: Knowledge Sharing
CSE

5095


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.
CDSS-43
Limitations: Knowledge Sharing
CSE

5095
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.
CDSS-44
Limitations: Knowledge Maintenance
CSE

5095
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.
CDSS-45
Limitations: Knowledge Maintenance
CSE

5095
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.
CDSS-46
Limitations: Security
CSE

5095
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.
CDSS-47
Limitations: Security
CSE

5095

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.
CDSS-48
Concluding Remarks
CSE

5095
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.
CDSS-49