1. History of Health Information Technology in the U.S.
History of Clinical Decision Support Systems
Welcome to History of Health Information Technology in the US, History of Clinical Decision Support systems. This is lecture A, What is CDS? This unit focuses on the history of clinical decision support systems or, as it is abbreviated, C-D-S. This lecture provides an overview of CDS.
Lecture a – What is CDS?
This material Comp5_Unit7 was developed by The University of Alabama Birmingham, funded by the Department of Health and Human Services, Office of the National Coordinator for Health Information Technology under Award Number 1U24OC000023

2. History of Clinical Decision Support Systems Learning Objectives
Describe various types and structures of clinical decision support (CDS) systems
Discuss the evolution of clinical decision support from expert system research
Discuss the changes in focus of clinical decision support from the 1980s to the present
Discuss the change in architecture and mode of access of clinical decision support systems from the 1980s to the present
Describe some of the early clinical decision support systems
Discuss the historical challenges in implementing CDS
The Objectives for this unit, History of Clinical Decision Support Systems are to:
Describe various types and structures of clinical decision support (CDS) systems.
Discuss the evolution of clinical decision support from expert system research.
Discuss the changes in focus of clinical decision support from the 1980s to the present.
Discuss the change in architecture and mode of access of clinical decision support systems from the 1980s to the present.
Describe some of the early clinical decision support systems.
Discuss the historical challenges in implementing CDS.
Health IT Workforce Curriculum Version 3.0/Spring 2012
History of Health Information Technology in the US History of Clinical Decision Support Systems Lecture a

3. Overview Definition Types of CDS
“Classic” clinical decision support systems
Examples of CDS and how they evolved
Evolution of CDS architecture
Challenges to be overcome
We will begin with a definition of CDS and a description of the broad range of possibilities for CDS and what they can accomplish. We will spend more time describing what has been called the “classic” model for CDS, because that model has had a long history. In the second lecture, we will describe specific systems, several of which are still around today. Finally, we will summarize how CDS has evolved and discuss the challenges that still exist.
Health IT Workforce Curriculum Version 3.0/Spring 2012
History of Health Information Technology in the US History of Clinical Decision Support Systems
Lecture a

4. CDS Definition
Clinical decision support (CDS) provides clinicians, staff, patients or other individuals with knowledge and person-specific information, intelligently filtered or presented at appropriate times, to enhance health and healthcare.
Source: (Osheroff, et al., 2007)
This definition of CDS comes from a major report by an expert panel on clinical decision support. Although it is a fairly recent definition, it is broad enough to capture the variety of clinical decision support applications that have been developed. CDS can be used by clinicians and patients, but we will focus on the CDS aimed at clinicians. Let’s take a look at some of the key features of this definition that are in bold – knowledge and information that is filtered, presented at appropriate times with a purpose of enhancing health and healthcare.
Health IT Workforce Curriculum Version 3.0/Spring 2012
History of Health Information Technology in the US History of Clinical Decision Support Systems
Lecture a

5. Knowledge and Information
General Medical Knowledge and Information
Disease, diagnosis, medications, treatments
Formularies, guidelines, requirements
What type of knowledge and information can CDS provide? Some CDS have been designed to provide what may be termed general medical knowledge, although it may apply more to some patients than others. This may be descriptions of the signs and symptoms of diseases or methods to diagnose them.
The general knowledge may also include information on medications and other treatments, such as appropriate dosages, indications, and side effects.
More specific types of information could include a particular insurer’s formulary (pronounced FORM-you-lerry), that is, it includes what medications the insurer will pay for, or clinical guidelines, such as guidelines or other requirements on proper medications and monitoring that are needed for patients with a given condition.
Health IT Workforce Curriculum Version 3.0/Spring 2012
History of Health Information Technology in the US History of Clinical Decision Support Systems
Lecture a

6. Knowledge and Information
General Medical Knowledge and Information
Disease, diagnosis, medications, treatments
Formularies, guidelines, requirements
Patient-Specific Information
Patient’s signs, symptoms
Allergies
Lab results
Patient-specific information includes the unique information for the given patient. It might include the particular patient’s signs and symptoms. Signs are physical findings that the doctor can observe. Symptoms are what the patient tells the doctor. It can also include allergies, and even the results of laboratory tests, among other information. In the future, we are likely to see CDS that even can deal with information on a patient’s individual genetic profile. Now that is really patient specific information!
Health IT Workforce Curriculum Version 3.0/Spring 2012
History of Health Information Technology in the US History of Clinical Decision Support Systems
Lecture a

7. Filtered For the particular clinician Usable form Context sensitive
Tailored to patient
The filtered aspect is very important. For information to be useful, it has to be able to be absorbed by the clinician. Given the vast amount of potential information, it is important that there be some selection in information that is presented to the clinician. Some mechanisms of filtering may include those that the particular clinician wants, say, for instance, reminders for certain preventive measures for patients that the clinician wants to do but may forget.
The information must be displayed in usable form and be sensitive to the context of care. For instance, if a doctor is with a patient and the doctor wants to know the correct dosage for a medication she is about to prescribe, a twenty-page article on the medication would be too much information to be usable at that time. An example of context sensitivity might be displaying a patient’s drug allergies at the time that the physician is ordering medications.
Finally, the information should be tailored to the patient. As an example, some medications require special monitoring for elderly patients, but not for children. If a pediatrician treating a child is using the medication, the pediatrician does not need a warning about how the medication should be monitored for an eighty-year-old.
Health IT Workforce Curriculum Version 3.0/Spring 2012
History of Health Information Technology in the US History of Clinical Decision Support Systems
Lecture a

8. Appropriate Time At the point of decision making When new data arrives
To stop dangerous decisions
When clinician requests it
Appropriate frequency
The timing of the presentation of the information is also crucial if it is to have an impact. The information should be presented at the time it is needed, which is usually when a decision has to be made. For example, drug dosage information is best to have available at the time the doctor is prescribing medications.
Another choice in timing may be to present new information when it arrives, especially if the information would influence the clinician’s decision. An example of this might be if the report form monitoring a patient’s blood level shows the patient has too much of a prescribed medication in his or her system. The physician might need to take immediate action based on that information.
In addition, information may need to reach the clinician to stop a dangerous decision so the patient is not harmed. An example might be if the physician has just ordered a drug that the patient is allergic to; the warning should be presented before the order goes through.
In some cases, the information is not presented automatically, but is available “on demand,” that is to say, when it is requested by the physician. An example might be references related to a particular treatment question.
Finally, the frequency of presentation of information is important. Too frequent repetitions of similar information can tend to get ignored.
Health IT Workforce Curriculum Version 3.0/Spring 2012
History of Health Information Technology in the US History of Clinical Decision Support Systems
Lecture a

9. Enhance Health and Healthcare
EHRs without CDS
Accessible
Legible
Complete
Added value of CDS
Improve quality
Greater return on investment
Source: (Johnston, et al., 2004)
Now let us move to the last part of the definition of CDS, which is “to enhance health and healthcare.” There are other types of decision support systems that are more administrative in nature, such as providing information of the costs of different services in a hospital. This is often retrospective information and is regularly used by administrators. Clinical decision support is usually aimed at clinicians while they are in the process of clinical care and is aimed to aid their decision making and ultimately to enhance care.
An electronic health record that does not include clinical decision support features can still do much to enhance care in that it makes the patient information accessible and legible and is more likely (although not guaranteed) to be complete.
However, CDS provides added value. Studies have shown increases in quality, which can also lead to greater return on investment with the use of sophisticated clinical decision support. Let’s take a look at how CDS can improve quality.
Health IT Workforce Curriculum Version 3.0/Spring 2012
History of Health Information Technology in the US History of Clinical Decision Support Systems
Lecture a

10. Improve Quality Improve adherence to guidelines
Avoid inappropriate procedures
Studies have demonstrated that CDS can improve adherence to guidelines and other similar protocols, often by helping the physician avoid inappropriate procedures.
Health IT Workforce Curriculum Version 3.0/Spring 2012
History of Health Information Technology in the US History of Clinical Decision Support Systems
Lecture a

11. Improve Quality Improve adherence to guidelines
Avoid inappropriate procedures
Avoid diagnostic/therapy errors
Drug Interactions
Delay in diagnosis
The systems can minimize errors by alerting the physician to potentially dangerous drug interactions. The diagnostic programs have also been shown to improve physician diagnoses. Although little research has been done on these programs in actual practice, they could potentially avoid delay in diagnosis.
Health IT Workforce Curriculum Version 3.0/Spring 2012
History of Health Information Technology in the US History of Clinical Decision Support Systems
Lecture a

12. Improve Quality Improve adherence to guidelines
Avoid inappropriate procedures
Avoid diagnostic/therapy errors
Drug Interactions
Delay in diagnosis
Minimize problem severity/complications
Early alerts to abnormal lab values
Alerts to adverse drug events
Diagnostic screening reminders
Immunization reminders
Source: (Classen, et al., 1997)
The reminder and alerting programs can potentially minimize problem severity and prevent complications. These include programs to alert the clinician to abnormal lab values or adverse drug events. An adverse drug event is harm to the patient as a result of taking a medication. For instance, there have been articles in major medical journals that have shown how programs that warn of the signs of early adverse drug events have had an impact on both cost and quality of care. Other reminder programs include those screening procedures such as mammography, which can diagnose breast cancer at an early stage, or reminders for immunizations such as flu shots that can prevent costly hospitalizations.
Health IT Workforce Curriculum Version 3.0/Spring 2012
History of Health Information Technology in the US History of Clinical Decision Support Systems
Lecture a

13. Taxonomy of Interventions
Documentation forms/templates
Relevant data presentation
Order creation facilitators
Time-based checking/protocol, pathway support
Reference information and guidance
Reactive alerts and reminders
Source: (Osheroff, 2009)
Jerome Osheroff (pronounced Osh (like gosh)-er-off) and his colleagues have developed several practical guidebooks on implementing CDS and they have formulated what they call a taxonomy of CDS interventions. The taxonomy presents a very broad view of what CDS can cover. In addition to the alerts and reminders, CDS includes methods for organizing the information in the EHR to make it more useful for influencing decisions.
These include forms and templates and data presentation that aids decision making. An example of the latter may be a graphical display of blood pressure over time to assist the physician in deciding whether a particular blood pressure medication is working. Order creation facilitators might include order sets that consist of appropriate lab tests for a given condition, or even a list of a physician’s preferred medications for given conditions. Time-based checking for protocol support might include reminders on a given day post-surgery for things for nurses to do at that time.
Health IT Workforce Curriculum Version 3.0/Spring 2012
History of Health Information Technology in the US History of Clinical Decision Support Systems
Lecture a

14. Taxonomy of Interventions
Documentation forms/templates
Relevant data presentation
Order creation facilitators
Time-based checking/protocol, pathway support
Reference information and guidance
Reactive alerts and reminders
Source: (Osheroff, 2009)
The last two items on the list are what some of the early decision support systems focused on and what have been referred to as “classic” decision support. Although as we said, there are a variety of “types and functions” of “clinical decision support,” some people think of “reference information and guidance,” and “alerts and reminders,” as the only aspects of "clinical decision support."  We will focus the remainder of this lecture and the next on systems that exemplify these types of classic decision support.
Health IT Workforce Curriculum Version 3.0/Spring 2012
History of Health Information Technology in the US History of Clinical Decision Support Systems
Lecture a

15. “Classic” CDS Origin Expert systems research
Medical process improvement
Today’s clinical decision support systems that would fall in the classic category arose out of earlier expert systems research. The earlier research was related to research in artificial intelligence where the aim was to build a computer program that could simulate human thinking and which could function as an expert consultant. Medicine was considered a good domain to which these concepts could be applied. Although they began as research projects, the developers of these systems began to adapt them from expert systems to clinical decision support systems and to apply them to real life patient care processes.
Health IT Workforce Curriculum Version 3.0/Spring 2012
History of Health Information Technology in the US History of Clinical Decision Support Systems
Lecture a

16. “Classic” CDS Origin Expert systems research
Medical process improvement
Intent
Assist clinician
Provide information for user
Source: (Miller & Masarie, 1990)
The intent of the decision support systems was not to simulate an expert’s decision making, but to assist the clinician in his or her own decision making. The system was expected to provide information for the user, rather than to come up with “the answer.”
Health IT Workforce Curriculum Version 3.0/Spring 2012
History of Health Information Technology in the US History of Clinical Decision Support Systems
Lecture a

17. “Classic” CDS Origin Expert systems research
Medical process improvement
Intent
Assist clinician
Provide information for user
User’s Role
Filter information
Interact with system
The user was expected to filter that information and to discard erroneous or useless information. The user was expected to be active and to interact with the system, rather than just be a passive recipient of the output.
Health IT Workforce Curriculum Version 3.0/Spring 2012
History of Health Information Technology in the US History of Clinical Decision Support Systems
Lecture a

18. CDS Structure Knowledge Base Inference Engine Communication Mechanism
There are three parts to most of the clinical decision support systems. These parts are the knowledge base, the inference or reasoning engine, and a mechanism to communicate with the user.
Health IT Workforce Curriculum Version 3.0/Spring 2012
History of Health Information Technology in the US History of Clinical Decision Support Systems
Lecture a

19. CDS Structure Knowledge Base Compiled information If-then rules
Other types of associations
The knowledge base consists of compiled information, often, but not always, in the form of if-then (pronounced if then) rules. An example of an if-then rule might be, for instance, IF a new order is placed for a particular blood test that tends to change very slowly, AND IF that blood test was initially ordered within the previous 48 hours, THEN alert the physician. In this case, the rule is designed to prevent duplicate test ordering.
Other types of associations might include probabilistic associations of signs and symptoms with diagnoses. Signs and symptoms are rarely present 100% of the time in a given disease, but some are more likely than others in certain diseases. As an example, if you have the flu, you might have a fever, cough, and body aches, but not everyone who has the flu has all three. Similarly, there are other diseases that might also include some of these features, but all three in combination may be less likely in these other diseases. Some knowledge bases are organized with this type of information about signs and symptoms in various diseases, rather than If-then rules.
Health IT Workforce Curriculum Version 3.0/Spring 2012
History of Health Information Technology in the US History of Clinical Decision Support Systems
Lecture a

20. CDS Structure Knowledge Base Inference Engine Compiled information
If-then rules
Other types of associations
Inference Engine
Model/formulas for combining the knowledge base with patient-specific data
The second part is called the inference engine, which contains the formula for combining the rules or associations in the knowledge base with actual patient data.
Health IT Workforce Curriculum Version 3.0/Spring 2012
History of Health Information Technology in the US History of Clinical Decision Support Systems
Lecture a

21. CDS Structure Knowledge Base Inference Engine Communication Mechanism
Compiled information
If - then rules
Other types of associations
Inference Engine
Model/formulas for combining the knowledge base with patient-specific data
Communication Mechanism
Input of patient data
Output of information to user
Finally, there has to be a communication mechanism, a way of getting the patient data into the system and getting the output of the system to the user who will make the actual decision. Let’s look at some examples.
Health IT Workforce Curriculum Version 3.0/Spring 2012
History of Health Information Technology in the US History of Clinical Decision Support Systems
Lecture a

22. "Classic” CDS
This is a model of how the system works. Patient data is the input into the system. The data may be entered by the clinician or it may be imported from the EHR. The system itself combines the patient’s data with its “knowledge base,” using the formulas in the "inference engine" to provide information to the user.
Health IT Workforce Curriculum Version 3.0/Spring 2012
History of Health Information Technology in the US History of Clinical Decision Support Systems
Lecture a

23. "Classic” CDS
In this example, let’s assume we have information about the patient in our EHR that the CDS can use. The input might be a medication prescription or order for a patient, the knowledge base might consist of information on interactions of the medication with other drugs, foods, etc. By combining the known information about the patient (like what drugs he is already taking or is allergic to and what the new prescription is) with the information in the knowledge base, the CDS might produce an alert to potential interactions.
Health IT Workforce Curriculum Version 3.0/Spring 2012
History of Health Information Technology in the US History of Clinical Decision Support Systems
Lecture a

24. "Classic” CDS
Here is another example, this time of a diagnostic decision support system. The physician might enter the key signs and symptoms a patient has, the knowledge base might consist of information on diseases and their associated signs and symptoms, and the output might be a list of possible diagnoses.
Health IT Workforce Curriculum Version 3.0/Spring 2012
History of Health Information Technology in the US History of Clinical Decision Support Systems
Lecture a

25. "Classic” CDS
There are also critiquing systems. The physician might propose a therapy plan for a given condition and the system might include preferred protocols. The system would compare the planned treatment with the protocol and provide a critique and possibly even alternative recommendations.
Health IT Workforce Curriculum Version 3.0/Spring 2012
History of Health Information Technology in the US History of Clinical Decision Support Systems
Lecture a

26. History of Clinical Decision Support Systems Summary – Lecture a
Definition
Types of CDS
“Classic” clinical decision support systems
This concludes Lecture a of History of Clinical Decision Support Systems. In summary, we defined CDS and described the broad range of possibilities for CDS and what they can accomplish. We spent more time describing what has been called the “classic” model for CDS, because that model has had a long history.
Health IT Workforce Curriculum Version 3.0/Spring 2012
History of Health Information Technology in the US History of Clinical Decision Support Systems
Lecture a

27. Credits
Some of the material in this presentation is also included in the following and is used with permission:
Berner ES, La Lande TJ. Overview of CDSS. In: Berner ES, editor. Clinical decision support systems: theory and practice. 2nd ed., New York: Springer; 2007, p
“No Audio”
Health IT Workforce Curriculum Version 3.0/Spring 2012
History of Health Information Technology in the US History of Clinical Decision Support Systems
Lecture a

28. History of Clinical Decision Support Systems References – Lecture a
Berner ES, La Lande TJ. Overview of CDSS. In: Berner ES, editor. Clinical decision support systems: theory and practice. 2nd ed., New York: Springer; 2007, p
Classen DC, Pestotnik SL, Evans RS, Lloyd JF, Burke JP. Adverse drug events in hospitalized patients. Excess length of stay, extra costs, and attributable mortality. JAMA Jan 22-29;277(4):301-6.
Johnston D, Pan E, Walker J. The value of CPOE in ambulatory settings. J Healthc Inf Manag. 2004;18(1):5-8.
Miller RA, Masarie FE Jr. The demise of the "Greek Oracle" model for medical diagnostic systems. Methods Inf Med Jan;29(1):1-2.
Osheroff J, editor. Improving medication use and outcomes with clinical decision support: a step-by-step guide. 1st ed. Chicago: HIMSS, 2009.
Osheroff JA, Teich JM, Middleton B, Steen EB, Wright A, Detmer DE. A roadmap for national action on clinical decision support. JAMIA 2007;14:141-5.
“No Audio”
Health IT Workforce Curriculum Version 3.0/Spring 2012
History of Health Information Technology in the US History of Clinical Decision Support Systems
Lecture a