CLINICAL DECISION SUPPORT

Dr. Saeed ShiryClinical Decision SUPPORTRoad Map

Amirkabir University of TechnologyComputer Engineering & Information Technology Department

A Case Study:CLINICAL DECISION SUPPORT at LDS HOSPITAL

Medical decision-making requires the clinician to apply accumulated knowledge to a specific amount of patient information to produce a result that may be a diagnosis, prognosis, course of therapy, or the selection of further tests.

Too often, the decisions are based on limited knowledge, the information is incomplete or imperfect, and the decisions must be made during a limited period of time.

Clinical decision support clinical decision support, has been defined as ‘‘any

computer program designed to help health professionals make clinical decisions, deal with medical data about patients or with the knowledge of medicine necessary to interpret such data’’.

These DS tools can be classified into:1. tools for information management, 2. tools for focusing attention, and 3. tools for patient-specific consultation.

computer applications should identify and reduce the rate of errors, inappropriate or inefficient actions, and adverse events.

Architecture and key features of HELP System

Electronic health record (EHR)

Most patient information is stored in the EHR. Some comes from applications that are part of the System, and Some comes from other applications

A number of medical devices also are interfaced to the System, and patient vital signs, medication pump, and ventilator information is stored automatically in the HER.

The clinical information is stored in a common database. The transcribed dictations from x-rays, history and physical exams, and other reports, and admission diagnoses are stored as free-text, whereas most of the EHR data are stored in a coded format.

Coded data are needed for the decision support process. Each coded element in the database and the free-text data are

stored with an event time.

knowledge base A second key feature of the System is a knowledge base that

contains thousands of medical logic modules (MLMs). The MLMs contain medical logic that has been developed by

medical experts from different knowledge domains. Some contain simple rules to identify patients with elevated

potassium levels based on laboratory results; Others may contain complex logic and require patient information

from a number of data sources in the EHR. Each of the MLMs contains two main parts.

The first part identifies which data elements in the EHR are needed for the logic.

The second part contains the computer logic used to analyze the data elements.

Time and Data Driver The third key feature of the System is the ability to data and time drive

the knowledge base. All data that are stored in the EHR pass though the data-driver, and

each data element is screened. The first task the data-driver does is to make a copy of the data string

being stored into the EHR and to send that copy to the decision support engine.

The decision support engine parses the data string into separate data elements. Each data element is then compared with the code tables to see if there are

any MLMs that should be activated based on that data element. When the decision support engine runs the MLM, it retrieves additional

needed information from the EHR as specified in the MLM. If the logic in the MLM generates an alert, another record is built and stored in the alert file. This enables the system to continuously monitor patients.

The time-driver is simply a program on the system that checks a table each minute to see if there are MLMs or other applications that should be run.

Main functional processes of the data-driver

Data Base Another key feature of the System is that the data in the EHR are never deleted. As patients are discharged from the hospital and all billing is completed, the patient record is moved to an archival EHR. All clinical patient data from the HELP System since 1983 are

stored in the current or archival EHRs. The archival storage of the EHR provides data that are often

analyzed and used to develop the medical logic contained in the MLMs and has been essential for numerous retrospective research studies.

Pharmacy System

The pharmacy application accesses patient data from the EHR to generate alerts of potential adverse drug events; drug–drug, drug–allergy, drug–laboratory, drug–disease, drug–dose, drug–diet, and drug–interval.

The application also generates prescription labels and patient drug profiles that are used for unit dose dispensing.

The alerts are displayed to the pharmacists as they enter the hand-written physician orders into the application. The pharmacists then inform the physicians or nursing staff of the potential problems.

An evaluation of the pharmacy application showed that 5 percent of patients and 0.8 percent of drug orders generated alerts, and that physicians changed patient therapy for 77 percent of the alerts.

The problem with this approach is that patients may receive the drugs before the pharmacists enter the orders into the pharmacy application. An approach to this problem is that physicians should not handwrite their orders but

enter them directly using provider order entry (POE) applications. That way the physicians would immediately get the alerts and change the order before the drug is administered.

Blood Gas Reports

The computerization of laboratory instruments could provide more medical information and in less time.

However, this led tomedical staff being presented with large amounts of patient data. Often this increase in information, although making the medical decisions more accurate, required the medical staff to take more time to gather and assimilate the pertinent information.

This situation resulted in computers being used to provide or assist in the interpretation of laboratory test results.

This resulted in the reporting of blood gas results on the System to automatically include the interpretations without any direct physician interaction .

The accuracy of the computer interpretations was compared with the interpretations of four pulmonary and three nephrology experts: The results ranked the computer interpretations second among the experts. A physician survey found that 80 percent of the blood gas interpretations

were helpful and 28 percent changed patient care.

Emergency Department Infection Report Thousands of patients visit emergency departments every day and based on their specific

clinical manifestations have specimens collected and sent for microbiology examination. Often the laboratory tests are ordered only for precautionary purposes and the patients are

sent home. Every emergency department can relate stories about patients who were sent home and subsequently had laboratory test results that contained important information that was overlooked or not followed up.

The emergency department infection report is a simple printout that contains all the microbiology and other infection-related test results for all the emergency department patients during the past 10 days.

During each shift, a member of the emergency department staff is assigned to run the program and examine the report for any new infection information.

When important information is found, the patients are contacted and given specific instructions based on the test results.

Use of this information management tool resulted in contacting an average of two patients each day and informing them that they need an antibiotic or that their previously prescribed antibiotic needs to be changed.

This application demonstrates that the value of decision support applications is not determined by the sophistication or complexity of the program(s) or database.

Over the past 20 years, the emergency department at LDS Hospital has changed thousands of therapeutic decisions based on the information contained in the emergency department infection reports.

Nurse Bedside Charting

Without the entry of medical data, tools for information management and decision support could not function.

A major question is: how, where, and when the information should be entered.

In some situations, direct data access is provided by interfaces to medical devices, laboratory instruments, or other computer systems.

The data provided from interfaces to other computer systems often requires initial data entry by medical staff.

An important message of this chapter is that accurate and timely computer decision support is dependent on the data available to the decision logic in the knowledge base, hence the importance of the information contained in the EHR.

Nurse Bedside Charting

An important source of medical information is that which is acquired and documented by the nursing staff.

An electronic nurse-charting program was developed which contained some decision logic that would alert the nurse when patient information that was entered was out of range or inappropriate.

nurse documentation done at the nurse station was generally found to take place at the end of the shift, probably less accurately, and thus was believed to have a reduced value for decision support.

Study shows using the nurse-charting program at the bedside is more accurate and useful.

Infectious Disease Monitor

This application identifies patients who have conditions that infection control practitioners and infectious disease physicians want to be aware of: 1) patients with hospital acquired infections, 2) patients with reportable diseases, 3) patients with antibiotic-resistant pathogens, and 4) patients with infections in sterile body sites.

The code for a microbiology test directs the decision support engine to load MLMs that contain logic to identify pathogens based on the specimen and/or body site.

Some MLMs contain logic to determine which infections need to be reported to state and federal health departments whereas others contain criteria for the identification of hospital-acquired or nosocomial infections.

Thus, as patient information from microbiology culture results, urinalyses, and chest X-rays are stored in the EHR, the data-driver provides 24 hour and hospital-wide surveillance.

using the time-driver to notify possible hospital-acquired infections

Prediction of hospital Infection They wondered if they could use statistical methods to identify

patients at high risk of developing an infection in the hospital before the infection onset.

A study database was created with 3,151 patients with hospital-acquired infections and 3,152 control patients. Stepwise logistic regression was used to develop a predictive model for high-risk patients based on 10 of 18 putative risk factors tested.

A computer program was activated each day to use an equation based on the model to monitor all hospitalized patients and create a computer printout of the high-risk patients.

During the first six months 78 percent of hospitalized infections occurred in high-risk patients and 63 percent were predicted before the documented onset of the infection.

Data Mining:Adverse Drug Event Monitor They began to question if a drug that cost a few

dollars less per day to use but caused a number of ADEs was really less expensive than another drug that caused only a few ADEs?

No one at the Hospital had any idea what the actual ADE rate was, nor which drugs caused the ADEs.

MLMs were developed that monitored: 1) laboratory test results that could be indicative of a

possible ADE, 2) elevated serum drug levels, 3) the ordering of drugs that are commonly used to treat

ADEs, and 4) physiologic data that could signal possible ADEs

A New Version of the system

The new Web-based and fully integrated system has allowed a pediatric intensivist to use the Internet and access a child’s laboratory, medication, and ECG information at a hospital 305 miles away and make a life-saving diagnosis and therapeutic change.

The new anti-infective management program is more accurate, with access to microbiology, chest x-ray and other patient information obtained at one IHC facility before the patient is transferred to another IHC hospital.

messages provided from the medical decision support The timing of data entry is critical. Patient information needs to be entered into the EHR as

soon as possible Successful decision support applications are developed by a team consisting of clinical

domain experts providing the why and what needs to be done and the medical informaticists providing the how.

Decision support should be integrated with the daily work processes of the medical staff and occur at the appropriate point of patient care. Patient alerts should be sent directly to the most appropriate people as soon as possible.

Decision support applications need to be tested for safety before they are made available for general use. One bad experience can create barriers or restrictions for any future applications.

Often large patient care improvement projects need to be broken down into smaller more manageable processes.

The medical logic and rules need to be evidence based and match local processes of patient care.

The logic and rules need to be periodically reviewed and updated as patient care and technology change.

The applications must be easy to use and training should not be so difficult that patient safety could be compromised.

Evaluation of medical decision support applications is often the hardest part. The applications need to be cost effective and reasonable to implement and maintain in

order to gain administration support as well as clinical support. Physician support of order entry is easier to get if all orders, laboratory, medication,

radiology, and so on, can be made at the same time using the same application.

Homework

One of the Following Papers from: Clinical Decision Support Systems Theory and

Practice, Second Edition

1. Data Mining and Clinical Decision Support Systems

2. Design and Implementation Issues