An Analysis of the Clinical Decision Support System MYCIN

 With technology becoming such a prominent factor throughout the healthcare field, it is important that these technologies and systems are able to supply users with both the confidence and reliability needed when it comes to the information that is being generated from them. These systems that are designed not only need to analyze and sort through the information that is programmed into them, but also need to have the capacity to store all of this knowledge, as well as, supply the user with accurate information as to how it has arrived at its final decision. From the start of the development of these clinical decision support systems (CDSS), the capability to deliver the requirements expected of them is what gives each individual system the success needed to either advance to the commercial market or remain limited in its use throughout the industry. MYCIN is an example of a system that did in fact display successes, however, was never able to branch out commercially. This report will take a closer look at the successes of the MYCIN system, along with the reasons why it could not advance to the next level.

 MYCIN was first introduced into the field in the 1970s and was a system that aimed to diagnosis and give suggestions of treatment for patients who appeared to have a blood/bacterial infection (Copeland, 2008). In order to understand the qualities that led to MYCIN’s success, it is first important to understand how exactly the system was structured. By utilizing production rules and primarily a backward-chaining approach, MYCIN was able to access information contained in both its inference engine and knowledge base in order to generate probable patient outcomes to then be considered by healthcare providers (Buchanan & Shortliffe, 1984). Eventually, the production rules to be analyzed by the system grew upwards to around 500 rules, and as it turns out, the way in which these rules were structured is one factor that added to MYCIN’s success in operation (Buchanan & Shortliffe, 1984). The way that the system is able to interpret the rules, is effective in regard to the fact that the functionality of the template put in place allows for the system to quickly interpret the information that has been inputted. When dealing with any system, the way the rules are programmed to operate and the features which they possess are extremely important for the success of the system. Depending on how well the system is able to navigate from each rule to the next relates to how effective the usability of the system is for the user. If the system is unable to produce an outcome or gets caught up in its decision process along the way, it is ultimately of little help. Health care providers rely on these systems to assist them by providing a quicker opportunity to diagnosis a patient and start treatment in a timelier manner. With usability being such an essential feature in the product design, a system that does not have a good workflow will in the end, decrease the satisfaction and overall experience for the user, as well as, decrease the patient experience (Berner, 2016).

 Another beneficial feature that led to success with the MYCIN system is the ability to use what is called the Reasoning Status Checker. The addition of this module to the system allowed for users to use the command functions of HOW and WHY in the event that they want to question exactly how the system came to a conclusion or why it chose to go with one rule over another (Buchanan & Shortliffe, 1984). Allowing the user to question why the system took the path it did does more to facilitate the human computer interaction (HCI), and in turn, increases the usability, along with functionality of the system (Berner, 2016). As with any type of technology there is always a chance that there could be room for error to occur. For example, let’s say that the system produces a response that the physician is not familiar with, and is unsure if that diagnosis is appropriate with what he or she feels the patient is experiencing. The HOW and WHY commands allow for the physician to question why each step in the process was necessary for the final outcome of the systems decision. The feature really gives the user a better understanding of the reasoning behind why the system is making certain selections and how the responses given are affecting decisions that may be made in the future (Buchanan & Shortliffe, 1984).

 The aforementioned factors are just two examples of what contributed to MYCIN’s success, however, there is some concern that the flexibility and simplicity of this system is what actually restricted it from becoming a commercial product (Buchanan & Shortliffe, 1984). One concern deals with the fact that the system utilizes production rules. When a production rule system is being used, this means that normally only one rule may be executed at a time (Greenes, 2014). Combining this with IF-THEN statements, which are all independent of one another, means that rules may be executed without any regard to if another rule present may relate more to a specific case (Greenes, 2014). What this ultimately means is that the order in which the system chooses to perform the rules cannot be ensured, and furthermore indicates that the first response may not always be the correct one. When a user inputs the WHY or HOW command the system will still consider all possible options, even if there is a clear path as to what type of infection a patient may have (Buchanan & Shortliffe, 1984). Today, if the product were to be used commercially, it may present a problem when it comes to the experience levels of the physicians who are using the program. Those with less experience may be more inclined to go with the systems first suggestion and not question as to why it chose one type of diagnosis over another.

 Another factor that may have contributed to MYCIN not being launched into the commercial market is the fact that most production rule systems, which is what MYCIN utilized, used a declarative logic approach (Greenes, 2014). In other words, the system could not provide the user with any statistical information of how accurate it believed a diagnosis to be. However, MYCIN was eventually able to include a probability factor that would inform the user how certain it was of the conclusion that was made, yet, the issue that presented itself was, the decision rules determined in one organization could not just simply be implemented into another (Greenes, 2014). If the MYCIN system were to be distributed commercially, there would have had to have been an established set of standards so that each institution would be given the same operation guidelines of the system (Buchanan & Shortliffe, 1984). There are many doctors today who have privileges and provide their services at different hospitals. If they were traveling from one institution to another, who both used the same system but had different approaches in its operation, the usability of the system neither be efficient or effective for the provider.

 Although the MYCIN system was not very long-lived, it clearly had some successes and showed its potential of what could have been. There have been multiple systems developed since then, but many may have used MYCIN as a building block and guideline in order to ensure a successful operation of the systems that we see being utilized today. With the advanced technology that those systems are comprised of, many question why we simply do not have “bot physicians” that are able to make diagnoses for us. As mentioned earlier, there is always a chance for an error when dealing with technology. Some may argue that humans can just as well make a mistake, however, the sole use of technology to make a diagnosis should not be relied on. It may be in the best interest of all to use both of these approaches when dealing with the lives of others. It is true technology may be able to quickly provide a physician with a possible diagnosis, but they can then take that suggestion and interpret it with their physical interaction with the patient. These systems operate with the facts that are programmed into to them and produce a response from the humans who encoded that information into them. Physicians on the other hand, are able to physically see and speak with the patient and possibly find out more information to produce a diagnosis rather than uses just statistics and simple facts. Finding a common middle ground between the two, in my opinion, would produce the best possible outcome for all involved in the process.       

References

• Berner, E. (2016). Clinical decision support systems (3rd ed.). Springer International.
• Buchanan, B., & Shortliffe, E. (1984). Rule-Based Expert Systems. Retrieved from http://people.dbmi.columbia.edu/~ehs7001/Buchanan-Shortliffe-1984/Chapter-04.pdf
• Copeland, B. (2008). MYCIN | artificial intelligence program. Retrieved from https://www.britannica.com/technology/MYCIN
• Greenes, R. (2014). Clinical decision support (2nd ed.). London, UK: Elsevier/Academic Press.