Kiran's personal website
Blog   Forums   Sitemap   Social    Phone

Clinical Diagnosis Support Systems

Clinical diagnosis support systems are one of the recent and most important inventions in healthcare software systems or medical informatics. They guide and direct the doctors in diagnosing clinical conditions correctly and to make right decisions. The system analyses and processes the patient’s data and come up with recommended diagnosis, this could be a multi stage process or one step process, it may request for more data or further clinical or laboratory examination based on the input.

There are many Clinical diagnosis support systems in the market that aid and guide clinician to diagnose the clinical cases correctly like Present Illness Program (PIP) developed by Pauker, MEDITEL for adult illnesses developed by Waxman and Worley, MYCIN developed by Stanford University, Internist-I developed by Pople, Myers, and Miller in University of Pittsburgh, QMR developed by Miller, Masarie, and Myers, DXplain, developed by Barnett and colleagues, and Iliad developed by Warner and colleagues. Almost all the clinical diagnosis systems take the user input and process the input and come up with possible diagnosis list. Even though there are many clinical diagnosis system are developed or under development. The most popular are the following.

1. QMR(Quick Medical Reference) –First Databank, Inc, CA
2. MYCIN — Stanford University.
3. Iliad –University of Utah.
4. Internist-I –University of Pittsburgh.
5. DXplain –Massachusetts General Hospital, Boston, MA
6. Isabel –Isabel Healthcare Inc, USA

These systems haven’t made big impact on healthcare.
The following graph shows the percentage of the usage of the systems (Usage of these systems for 100 doctors who is aware of the information technology).

CDDS Usage
Figure 3 Clinical diagnosis support systems usage.


QMR (Quick Medical Reference)
Developed by First Databank / Camdat Corp, CA
It is one of the first tried applications to help in the clinical diagnosis; it provides detailed information and resources that help doctors and clinicians to diagnose the diseases. It provides electronic data bank access to more than 750 common diseases and their complete symptomatology that acts as a decision support tool. QMR knowledgebase includes more than 6,000 clinical signs, symptoms and laboratory findings that describes and explain the disease. QMR developers claim that all the clinical findings in the QMR database are extensively reviewed by medical experts.

QMS provides functionality to generate extensive DD (differential diagnosis), suggests possible test to diagnose the case, store and manage the case history, QMR developers claim that it is an “expert system” improves medical care by allowing doctors to manage the medical cases more efficiently. The performance of the program is reasonably good, installation and usage is simple; Physicians enter their clinical findings and search for the suggestions and further help, the program processes the physician input comes with the results similar to search engine. Physician can search by disease for example “Hodgkin lymphoma” is entered then it lists the disease symptomatology, physical signs, lab investigations associated with the disease and differential diagnosis. Developers claim that it is very rare that it returns error however I could not verify and confirm the claim. QMR also provides list of associated conditions and provides you the details of severity, possible complications and the clinical measures of the disease. However it was noticed that the systems was missing many possible complications of many diseases.

QMR is developed mainly to provide a medical diagnostic tool; it provides functionality to generate diagnostic hypotheses based on entered clinical signs and symptoms. The first method is user enters maximum six clinical finding then searches for differential diagnosis to get possible diagnosis. The second method is user enters complete clinical findings of the patient in response it processes the input and provides notes for each finding. Once a list of differential diagnosis is generated, the physician can apply other program features to the proposed diagnostic hypothesis to refine the diagnosis further.

For example “Finger clubbing” generates list of diagnosis that includes Crohn’s disease by double clicking on the disease gives you further details like physical signs, lab tests and its complications. The programme also suggests further input so that physician can get more information from the patient by questioning more and further clinical examinations. I could not get the copy of the software to test it myself and I could not find any doctor used or using this software; my analysis is purely based on the available literature. This software has many significant flaws and errors that potentially misguide the physicians, algorithms used in this software is not sophisticated enough to provide good diagnostic help. I could not find a single hospital or a medical centre using this product, apparently First Databank withdrawn its support for this product and I consider this is a failed product.

Developed by Stanford University
MYCIN was one of earliest diagnosis support systems developed with a short range of functionality operated using simple inference engine with a database of over 600 rules. It is relatively simple diagnostic system and uses simple yes or no questions to get input from the clinician and finally comes up with the possible name of the bacteria. It uses certainty factors as opposed to uncertainty factors and this makes the application fairly simple.

MYCIN usage is simple and limited. Researchers tried the system for therapeutics and they have observed that it suggested relatively correct treatment in about 69% of the cases which was surprisingly better than diagnosing infectious diseases for which the system was originally developed. However there is no agreed standard for treatment hence the observation was not agreed by many researchers. MYCIN’s strength was in its reasoning approach, it introduced the rule based system development which was used and implemented by many other non-medical domains after MYCIN.

Even though it exceeded the expectations and outperformed the Stanford medical school faculty, it was never actually used in practice for various complex reasons. It covers only small area of internal medicine. Doctors are not convinced that computers can actually diagnose the diseases, and for ethical and legal issues relegated the usage of computers in medical diagnosis. MICIN takes very long time to complete its diagnosis process and this time consumption may be realistic to the physicians. Even though this was technically successful but it has failed to impact on the health care system. The system is not in use anywhere outside the Stanford medical school.

Developed by University of Utah
Iliad is a diagnostic expert system for Internal Medicine; developing and improving by the University Of Utah School Of Medicine’s department of Medical Informatics for last two decades. The system supports more than 5000 clinical findings and provides reasonably accurate diagnosis for more than 1,500 medical conditions. One of the important features that Iliad offers is the ability to analyze a particular patient’s case and to determine the most cost-effective method for diagnosing and treating the patient. Iliad was developed originally for the Apple Mac; and a version for the PC running windows has also been released. Iliad is primarily used as a teaching tool for medical students. This helps the students to improve their skill in differential diagnosis. A clinical case can be simulated through this system and students have to diagnose the case.
Students can query Iliad for useful patient history, physical examinations, or required laboratory investigations for the patient. Iliad process the query and evaluates alternative decision strategies with the use of “best Information Algorithm” this is combination of content, weightage and the cost. Process result then provides alternative work-ups in the order of cost-effectiveness
Iliad is developed based on Bavesean logic and Boolean knowledge frames to illustrate disease in internal medicine. The frames allow the use of sensitivities, specifics, and rules to describe the relationship between disease and its symptomatology and provides a basis for Iliad logic.

Developed by University of Pittsburgh
Internist-I is a broad based clinical diagnosis support systems and the major contributors for the development of the project include Randolph A. Miller, Harry E. Pople, and Victor Yu. It was originally developed for cases in internal medicine. Internist-I was core part of “The Logic of Problem-Solving in Clinical Diagnosis” course in university of Pittsburgh for nearly 10 years. With the help of medical experts the fourth year medicos in university of Pittsburgh has been entering and updating the medical data in to the system. They encoded the clinical and pathological finding and standard medical reports in to the system. By 1982 INTERNIST-I project had fifteen person-years medical data entry, and covered 70 to 80% all the possible diagnosis in the medicine.

Information stored in the system includes symptoms and signs, laboratory investigation results, and the patient’s case history. Internist-I did not follow the traditions of other systems instead it used the powerful ranking system. It ranks clinical findings in relation to the disease and it ranks disease itself depending on its occurrence. It also uses heuristic rule based partition algorithm to create problem area and exclusion functions to eliminate diagnostic possibilities. These rules create list of diagnosis in probable ranking order. When input data is not enough to suggest the diagnosis then system asks for further information or further examinations to resolve the case. Some documentation claims that Internist-I works better if the clinical finding of the patient is related to the one disease but other documentation disputes the claim and claims that it handles very complex cases very well. However I believe that it can diagnose cases with a single decease when compared to complex disease because of its dependence on hierarchical decision tree logic which links to the one root disease.

Figure 4 Internist-I user interface –From Internist-I web site

In 1979s Internist-I was used as an experimental clinical diagnostic tool for educational and internal use purpose in the university hospital of Pittsburgh. Even though it was used internally, the developers always intended to make it a global product. Still it is not widely used and lengthy training is required to use the application effectively. It takes longer time to input all the required data and an average consultation may take up to ninety minutes. I could not find any doctor using this product outside the University Hospital in Pittsburgh. I believe it is still used internally as a research and learning tool.

Developed by Massachusetts General Hospital, Boston, MA
DXplain has been in use for the last two decades. It has evolved and gained some popularity over the time. First version was developed in 1984 with illustrations of about 500 common diseases and it was released in 1986. Further versions were released in 1987, 1090, 1991, 1095 and 1996 with deceases and functionality. Since 1996 DXplain has been completely web based.

DXplain is a clinical decision support system and it functions in two modes, electronic medicine book and a medical reference system or case analysis mode. In reference or case analysis mode, it accepts patient’s clinical data like signs, symptoms, and laboratory findings and processes the data and produces the list of probable diagnosis in an order. It also provides logical reasoning for each of the diagnosis and why it was considered so that the physician/student can explore more regarding its manifestations. In medical textbook mode, DXPlain provides illustrations of over 2300 diseases and it explains the signs and symptoms of the each disease. It also provides epidemiology, etiology (cause of the decease), pathology, complications, and the prognosis of the disease. In addition it also provides up to ten references for each disease and these references provide more information, reviews and research information regarding the disease.

The current version of DXplain includes over 2300 diseases and over 4900 clinical manifestations (symptomatology, physical signs, epidemiology, laboratory investigations and other modern investigation findings like endoscopy, CT-Scan and MRI findings). Every disease consist minimum 10 clinical findings to maximum 100 clinical findings. Each clinical finding is related to one or more diseases and with the frequency of its appearance in the disease. There are over 230,000 data relationships between a clinical finding and a disease. Each clinical finding has 1 to 5 disease independent rating to indicate its significance. Each disease also has two related values crude approximation and prevalence and disease also ranked between 1 and 5 based other reasons.

Figure 5 DXplain user interfac

eDXplain accepts variety of clinical findings, including epidemiological findings, signs symptoms, laboratory investigations list such as pathological findings, X-Ray, Ultrasound, Doppler, ECG, EEG, endoscopic findings, Angiocardiogram, CT-Scan, MRI and breathing tests etc can be entered as comma separated values.
In my opinion DXplain is based on very good pragmatic logic; it is very close to my proposed solution and similar to Internist-I. However, it is not hugely popular so only a few doctors are actually using it. It is not clearly mentioned where the stats that the system is using are coming from and what is the credibility and authority behind its ranking. I thing its success is average but it has a good future.

Developed by Isabel Healthcare Inc., USA
Isabel is a widely used web based clinical diagnosis support system, Isabel accepts either key clinical findings or whole text entry of the clinical case and processes the request by using novel search strategy and identifies probable diagnosis from the given clinical findings. The physician can enter unlimited clinical conditions or complete case to find the probable diagnosis. The program also includes the data dictionary of the medical terms and clinical conditions and the library includes six medical textbooks and 49 major medical journals. The search results are filtered on epidemiological findings geographic location, age, sex and hobbies and system then displays more than 30 probable diagnosis. Up to ten diagnoses are presented on first webpage with web links. Physician can then explore each disease by clicking the link, to see other possible diagnosis; physician can click more diagnosis link.
Isabel has web based user friendly interface and usually no training is required to use the interface, and all the links are self explanatory.

Figure 6 Isabel user interface.

The Isabel Clinical Diagnosis Support System originally developed to aid pediatricians, and about 13 clinical staff at St Mary’s Hospital, London submitted 99 clinical case presentations for DD (differential diagnosis). Isabel claimed that it has diagnosed the cases with 91% accuracy, Also Isabel claimed that out of 100 real clinical cases from four major UK teaching hospitals it has diagnosed with 95% accuracy. After these trials Isabel was improved and upgraded to support adult diseases.

Isabel uses natural language processing and search algorithm that searches clinical data in the database system and comes up with new 30 diagnosis. However exact algorithm that Isabel uses is undisclosed and company does not want to reveal it.
Recent release of Isabel is called Isabel PRO and it has two major components Isabel PRO Diagnosis Reminder System (IDRS) and Isabel PRO Knowledge Mobilizing System (IKMS).

Isabel PRO Diagnosis Reminder System: Gives a probable diagnosis list for given signs, symptoms, and epidemiological finding and laboratory investigation results. Many physicians were involved in the development of Isabel and many doctors evaluated it. Isabel can be used in every stage of diagnosis process cycle from case taking to the treatment. Physicians can explore improve and refine their differential diagnosis knowledge.

Isabel PRO Knowledge Mobilizing System (IKMS): Has tutored taxonomy of over 10,000 diagnostic categories each of this process kernel of knowledge this intern uses concept search as opposed to keyword search. It also provides tagging functionality that can be used for physician’s workflow.

Isabel Pro is currently available for hospitals and poly clinics interfaced with high profile electronic medical records (EMR) systems in the USA, Isabel provides input filed for age, sex, and clinical conditions and a “Suggest Diagnosis” link button to the process the data. It returns results in separate window when the “Suggest Diagnosis” link is clicked. User can explore and refine the diagnosis by entering more finding and clicking relevant links. It also provides additional intelligent layer suggest more options to the clinician.

Even though Isabel claims that it is more than 95% accurate but in my opinion it is far less than that. No authority approved the Isabel and the search algorithms are dependent on database text that is not 100% accurate. Diagnosis is a life critical process and I do not think searching text database for input clinical condition is appropriate for life critical systems. Even though it gives somewhat better results comparing with other systems, it may not make very big impact on clinical diagnosis and health care.

Most of the existing system can diagnose the cases up to certain extent but they are not mature enough to use in life critical environment, they need to be evolved further with above 99% accuracy with better algorithms and with better data store.
Clinicians are not much impressed with existing clinical diagnosis support systems.
The following graph shows usefulness of the systems:

CDDS Usefulness
Figure 7 Usefulness of clinical diagnosis support systems

Reasons for CDDS unpopularity:
CDD systems are not mature enough to use in a life critical environment.
Developers haven’t deeply understood the medicine, clinical diagnosis process.
Doctors do not have faith that current systems can actually diagnose a clinical case like an experienced physician.

With the advancement of computer technology and networks, clinical practices are using information technology more and more in their clinical practices and it is changing the way they work. Not long time ago, Doctors used to read ECG (or EKG American) manually by analyzing P, Q, R, S and T nodes and generate the ECG report but now doctors are using the automated ECG machines that analyses the lead graphs and generates the accurate ECG report and it is more than 99% accurate, and some of the doctors are even forgetting the ECG reading skills and are relying completely on the automated ECG machine’s report. I can easily speculate that clinical diagnosis support systems will have the same future as we have seen for ECG machines.

There is very bright future for these systems and the capabilities will improve and clinicians will adapt to the technology. Manual clinical diagnosis process is based on human centric medical knowledge, developing applications based on human cantering knowledgebase is more complex, I think, there will be better chances of developing a most reliable clinical diagnosis application if the human centric medical knowledgebase are converted into computational centric data.
In the future there will be no surprise if the patients are treated by robotic doctors.

Storing XML in RDBMS

As XML is the de-facto standard for data exchange, systems need to store large volumes of XML documents and as I discussed earlier RDBMS is the best system to store and manage data.

DBMS provide various storage options, mechanisms and methods to store XML data in the Database.

Storing XML as Non-Native Character Data
In RDBMS you can store entire XML either as a character type (VARCHAR) or as a single value of large object (CLOB). When storing as character type, it can be split into multiple rows. XML stored into CLOBs or VARCHAR columns is not parsed.

Storing XML in non-native XML type gives very high performance because no parsing takes place in the process. Parsing can be done only at retrieval time. Storing XML data in not-native type is simple and easy.


Figure 1 Storing XML as non-native character data

1 Storing XML as non-native character data

Storing in to VARCHAR or CLOBs is easy to implement but DBMS does not know XML data structure and it’s not be parsed and no DOM object is created hence querying and searching of data is not possible or very difficult.

This type of storage is reasonable choice for following requirements
• When DBMS does not support native XML types
• Element search is not required
• Full documents insert and retrieval is more common operation rather than accessing partial data or individual elements of data.
• No updates or deletes required for XML elements
• XML validation is not required
• XML parsing and random access is not required
• When entire Documents need to be stored and retrieved in encrypted format

Storing XML as Non-Native Relational Values
Storing XML as Relational values is removing entire XML format and converting all the values in to relational values and saving them in to normal RDBMS tables.

In this approach it discards all the XML structure element tags and coverts all the elements, text and attributes in to relational values, normally this involves very complex table structure and multiple inserts or updates and involves significant time.

Figure 2 Storing XML as non-native relational values
Figure 2 Storing XML as non-native relational values

With this approach you loose all the XML capabilities and simply uses RDBMS capabilities, depending on the level of complexity and hierarchy of XML elements it might requires large number of relational tables and columns, defining such complex relational table schema could be very complicated and cumbersome; mapping XML elements and attributes in to relational fields is also a very complicated task.

This type of storage is reasonable choice for following requirements
• XML structure is very simple and data is regular and repetitive
• DBMS data retrieval performance is high priority
• Decomposition and reconstruction of XML to/form relational values is simple and straight forward
• Query data with plain SQL

Following example shows simple XML structure that can be easily converted in to relational values

<CLASS CLSID="007" CLSNAME=“Database“>

Example 2 Class Students XML Document

The XML in the above example can be easily converted in to relational values and relational values can reconstruct back to XML Document.

Above example requires only two database tables as follows
























Example 3 Class and Students tables

Once the values are inserted in to relational tables, you can use all the DBMS SQL capabilities; for example you can retrieve all the students’ details that are in the Database class with following simple SQL.

AND CLSNAME = ‘Database’
Example 4 SQL for Database class students

Results from the above SQL query can re-construct back to XML Document by using any programming language. Many main stream programming languages like JAVA, C++ and C# provide native XML writers and readers.

Storing XML in a Native XML Data Type

Many popular DBMS provides native XML storage with native XML Data types which preserve XML structure.

Figure 3 Storing XML as a native XML type
Figure 3 Storing XML as a native XML type

XML enabled DBMS provides not only XML types but also provides all the XML capabilities such as Xquery, XPath etc.. You can define a table schema and a create table in a simple way; for example you can create table with the following create statement:


Following example Course details XML document can be directly inserted in to COURSE_DETAILS column and you can easily query individual elements with XQuery/XPath

Example 5 Course XML Document

Even though DBMS stores XML in its native form, different Database Management Systems store XML documents using different technologies internally, some databases might convert data in to relational and XQuery into SQL (this is basically either storing XML as non-native character objects or storing XML as non-native relational values) but more databases are now using native XML types and its technologies like DOM (Document Object Model).

XML type supported databases that store native XML types follow XML Data model or XQuery Data model. This is completely different with previous non-native XML storage. Stored XML represents hierarchical structure and DBMS parses XML before inserting it to XMLType.

XML enabled native XML database systems uses trees representation of elements as the fundamental storage and processing model. Some DBMS requires serialization to retrieve full XML document but DBMS like Oracle, SQL server full document can be retrieved without serialization.

This type of storage is reasonable choice for following requirements
• High query performance is required
• XML Schema is very complex and mapping is very difficult
• Need to query individual data elements or partial document.
• Changing evolving XML Schema
• Parsing and validation is required
• Require to manipulate data elements in the XML document
• The internal structure of XML documents must be preserved