History of Healthcare IT in the US: History of Clinical Decision Support Systems
Audio Transcript
Slide 1
Welcome to History of Health Information Technology in the US, History of Clinical Decision Support Systems. This is lecture B, Examples of Early CDS Systems. This lecture illustrates some examples of the types of early CDS (pronounced C-D-S).
Slide 2
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.
Slide 3
We will discuss five well known CDS. Their names are listed in the slide. All of these systems were originally developed from the 1960s to the 1980s. But what happened to them differed. Studying these differences can provide insight into the use of CDS today. In essence, some of them essentially died not too long after development, some have continued to be used pretty much in the manner in which they were developed, and others adapted and had major modifications over the years.
For those of you whose interest is piqued (pronounced peaked) by this discussion, there are two classic books that have recently become freely available on the web that describe some of the CDS and provide more technical detail. These books are listed on the screen and the development of the first two CDS, MYCIN (pronounced Mice in) and INTERNIST-1 (pronounced Internist one) are described in them.
Slide 4
MYCIN was developed at Stanford University in the 1970s. It was developed by Dr. Ted Shortliffe (pronounced Short liff) as the focus for his PhD dissertation in 1975. It was designed to behave like an expert medical consultant.
Those of you who are familiar with the names of some common medications may be able to figure out what MYCIN’s area of expertise was. For those of you not familiar with the name, erythromycin (pronounced uh-rith-row-mycin), streptomycin (pronounced STREP-toe-mycin) and other MYCINs are antibiotics used to treat infections.
Slide 5
MYCIN’s focus was infectious diseases of the bloodstream. Treating these infections requires the system to identify the causal organism and to recommend the appropriate drug to treat the infection.
Slide 6
There were many challenges in developing expert systems in medicine, one of which is that almost nothing is 100% certain. That is, in some diseases certain symptoms appear most of the time, but not always. Lab tests are not 100% accurate. Many symptoms are common to a wide range of diseases.
Shortliffe and his colleagues developed a way to deal with the uncertainty (which they labeled certainty factors) so that the rules in the system did not have to rely on perfectly certain data. MYCIN performed well compared to experts like Stanford's faculty. An oncology system was developed modeled on MYCIN and it was also expanded to other domains.
Slide 7
MYCIN was a stand-alone system. That is, it was not connected to a hospital information system or medical record system. Data had to be entered manually into the system. And due to a combination of lack of funding and lack of interest on the part of potential physician users, it was never used in actual practice. Remember: this was the 1970s when the only physicians who were interested in using computers to address clinical problems were the academic informaticians (pronounced INfer-muh-ticians) like Shortliffe, who, by the way, had both an MD and a PhD. So this is one of the systems that did not get used beyond its role as a research prototype of this type of medical expert system. However, it remains as one of the most cited examples of these systems.
Slide 8
At around the same period of time, on the other side of the US, another system was being developed at the University of Pittsburgh. There is an interesting story to INTERNIST-1's (pronounced internist ones) development. Dr. Jack Myers was a well-known diagnostic expert who had recently retired as Chairman of Medicine at Pittsburgh. He thought it would be interesting to try to capture his expertise in a computer program. That gives new meaning to the term “Doc-in-a-box.” For those of you unfamiliar with that expression, it often refers to free standing clinics that will see walk-in patients.
Myers teamed up with a computer scientist named Harry Pople (pronounced POPE-uhl). Randolph Miller was a medical student at Pittsburgh at the time who had an interest in computers, and he was recruited to work on the project. Today Dr. Miller is an informatics leader and his is the name most associated with this project (and its successor called QMR (pronounced Q-M-R), which we will discuss in a minute).
Slide 9
In the Internist-1 system, the user enters the patient's findings, that is, the signs, symptoms and lab test or procedure results, into the system. The system used a controlled vocabulary. If a user wanted to enter the term “heart murmur,” for example, the system might list 40 kinds of heart murmurs and the physician would have to pick the one that best described the patient's murmur.
The system also could accommodate negative findings, for instance things that would normally be present but were absent in this patient. For example, like a patient who obviously had flu-like symptoms, but did NOT have a fever. The system used a weighting system that combined the data to arrive at a diagnosis. The weighting terms included evoking strength, that is, how strongly a given finding suggested a particular disease. Frequency was how often you would expect to see the finding if the patient had the disease and importance was how significant the finding was.
Slide 10
In the early 1980s there was a shift in the thinking about what would be the most useful type of CDS to develop. Whereas expert systems might be interesting as an idea for research, it became clear that were physicians not interested in that type of expert help because they still valued their autonomy as decision makers. It was felt that the systems might be better used to provide decision support.
In 1990, Randolph Miller (who had worked on the Internist-1 project years earlier when he was a medical student) was a co-author of an influential article called “The Demise of the Greek Oracle Model for Medical Diagnostic Systems.” You may remember from your study of Greek mythology that the ancient oracle made "pronouncements" much like the expert systems. The article proposed that the expert system model was not appropriate and said that systems should be designed to enhance, but not replace, clinician decision making. That intent is still the model for today's CDS.
Slide 11
The Quick Medical Reference program or QMR (pronounced Q-M-R) was designed as a decision support system. It utilized the INTERNIST-1 knowledge base, but provided a list of potential diagnoses for the physician to consider rather than even trying to identify the single correct diagnosis. You notice that even the name change conveys that it is a reference for physicians rather than an expert internist. In the early 90s the system was available commercially, initially with a small company founded by some of the developers, and later it was acquired by a larger company. However, eventually the larger company no longer supported it and stopped selling it.
When Dr. Miller moved to Vanderbilt University in the mid 90s he integrated a research version of QMR with Vanderbilt's EHR (pronounced E-H-R). When the IT company McKesson (pronounced Mick-Essen) acquired rights to some of Vanderbilt's EHR software, some of QMR's features were integrated with McKesson's Horizon Expert Orders feature.
Slide 12
DXplain (pronounced D- explain) is another diagnostic decision support system, this one developed at Massachusetts General Hospital in the mid 1980s. “D-X” is medical shorthand for the word “diagnosis” and the name is a combination of diagnosis and explain. DXplain has a similar structure to QMR in that it is a stand-alone program, and combines signs and symptoms using evoking strength and frequency type weights to arrive at a list of possible diagnoses. However, DXplain evolved very differently.
Slide 13
From the beginning, the developers of DXplain saw it as a constantly evolving system and they recognized that distributing updates to individual computers was not an optimal way to capture the continual evolution. So they distributed it from a central source via a dial-up system called AMA/NET (pronounced A-M-A net) that was sponsored by the American Medical Association. Of course, accessing networks in the 1980s was much slower than it is today.
Slide 14
As the developers of the systems said in 1987, "It requires about two minutes to complete the dial-in sequence to log onto AMA/NET and to connect to the computer located at Massachusetts General Hospital." Although the system itself was much faster than that, the slowness of connection, and the fact that in the 80s physicians were not used to using computers altogether, undoubtedly contributed to the demise of the network.
Slide 15
For a time DXplain was available on floppy disks for individual users, but once the World Wide Web took off, access was done via the Web. DXplain is still alive and well, and still evolving!
Slide 16
The next CDS that we will discuss in this section is the Antibiotic Assistant, which began as a CDS system integrated with the HELP (pronounced help) hospital information system at LDS (pronounced L-D-S) Hospital in Utah. The Help system at LDS Hospital has been around since the late 1960s and has a variety of decision support applications. The name HELP stands officially for Health Evaluation through Logical Processing, although it was called HELP first, and the full name came later!
The Antibiotic Assistant uses data in the patient's record to advise on likely causes and appropriate treatment for infections. It also includes additional resources to inform physicians more about particular diseases. It is used regularly at LDS Hospital and is available to other hospitals within the Intermountain Healthcare network.
Slide 17
The last system we will discuss here that was built from the start with integrated clinical decision support is the Regenstrief (pronounced REE-gen (like again)-streef) Medical Record System or RMRS (pronounced R-M-R-S). A good way to remember the focus of the early decision support here is to think of R for Regenstrief and Reminders. The original intent of the developers in building the RMRS was to use the data in the system to develop decision aids to remind physicians of things that they wanted to do, but might forget. Over time hundreds of rules were developed that could automatically review patient data and generate reminders, drug interaction alerts, and other types of clinical decision support. The number of hospitals and clinics using RMRS has expanded over the years and this system is one of the models often pointed to for its sophistication.
In the next presentation we will look at how CDS systems have continued to evolve.
Slide 18
This concludes Lecture b of History of Clinical Decision Support Systems. In summary, we described specific systems, several of which are still around today.
Slide 19
No audio
end
Health IT Workforce Curriculum History of Healthcare IT in the US 1
Version .0 / Spring 2012 History of CDSS
Lecture b
This material (Comp5_Unit7b was developed by the University of Alabama at Birmingham funded by the Department of Health and Human Services, Office of the National Coordinator for Health Information Technology under Award Number IU24OC0000.