9 - Chivu, Popa - Medical - Expert - System - PP 61-71

You might also like

Download as pdf or txt
Download as pdf or txt
You are on page 1of 11

61

INTERFACES OF EXPERT SYSTEM FOR CARDIOLOGIC DIAGNOSIS SUPPORT


Robert CHIVU 1), Ilie POPA 2)
MISYS Banking Systems, London, UK E-mail: robertchivu@yahoo.com 2) University of Pitesti, Electronics and Computers Department, Street Targul din Vale, No. 1, Pitesti, Arges, 110040, Romania, e-mail: cipopa@upit.ro
1)

Keywords: expert system, resolution module, cognitive module, knowledge base, knowledge object, human expert, knowledge engineer, explanation module, EKG.

Abstract: The paper presents a system expert general structure that provide support for medical diagnosis based on the EKG information retrieved from the human subject. Its content refers only to interface between external medium (human expert, knowledge engineer or any medical user) and expert system. The interface contains the main special characteristics for the knowledge introducing or extracting in a facile and attractive conversational mode. The expert system enter can be a specific external database too.

INTRODUCTION
An expert system is a system whose goal is to solve problems defined in a specific domain by simulating the reasoning of a human expert. Medicine is one of the domains where the Expert Systems principles can be applied with the most success. Medical expert systems can help the medical personnel by offering decision support regarding the diagnosis and the therapy. The following main domains are currently taking advantage of the Expert Systems help: - Decision support; - Intensive care; - Laboratory; - Medical education; - Medical imaging; - Quality assurance and administration (alerts, monitoring and reporting, intelligent registration of patients). A few future development areas could be: - Acquisition and representation methods for the medical information;

- Development of interoperable medical systems; - Combining more methods of medical systems development in complex systems; - Intelligent agents. Paper is proposing the implementation of an expert system to provide support for medical diagnosis based on the EKG information retrieved from the human subject. The expert system will implement the following functions: - Retrieve the EKG data from the human subject. The data is retrieved as part of the Telemedicine project from a subject that can be located in a remote place. The information is formatted in using the XML representation; - The EKG data is transferred in the Data Base; - The expert system will retrieve the data from DB and it will convert the EKG information to the internal representation of the data: o Human subject personal information;

ISSN 1453 1119

62

UNIVERSITY OF PITESTI ELECTRONICS AND COMPUTERS SCIENCE, SCIENTIFIC BULLETIN,

No. 8, Vol. 1, 2008

o EKG trace represented as a set of time/value points; - The EKG trace will be displayed on the human readable devices (computer display, printer); - Based on the EKG trace characteristics and using embedded rules, the Expert System will provide a set of possible diagnoses or ask for additional patient information to narrow the diagnosis results.

- With the knowledge engineer (the expert systems specialist) building, administering and developing the expert system (K.E.) - Knowledge acquisition module (K.A.M.) - Compatible external database (E.DB). - Diseases dictionary RESOLUTION Module (inference engine) has the role to choose the execution control strategy, checks the consistency of the resolution steps, builds the control information and establishes the reasoning paths. The module is receiving the completely defined problem (cdm) from the user through the User Interface module (U.I.) and submits the knowledge object request (kor) to the Cognitive Module. The selected knowledge objects (ko) consisting of rules and facts are retrieved from the Cognitive Module and are used for problem resolution following the reasoning path. The resolution of the problem (r) is sent to the user if enough data is received to make a decision or additional data request (adr) if additional data is needed. The additional data is submitted by the user as (ad) and the resolution module performs another analysis of the issue based on newly received data. The description of the reasoning path (rp) is sent to the Explanation Module, to be accessible to the user, if requested. EXPLANATION Module has the role to explain to the user the selected diagnostic through the interpretation of the reasoning paths, and performs an analysis of the causes leading to the eventual execution failure, showing the missing information from the inference chain, thus avoiding the error propagation. The reasoning path is represented by a graph. The rules used in the decide chain are exhibited to the human expert, so the diagnosis decision can be verified. The rules and the facts stored in the internal representation are translated to the human language, so those can be easily understood by the human expert. The explanation module is receiving the knowledge objects (ko) (rules and facts) from the Cognitive Module and also receives the resolution path (rp) from the Resolution Module, so all the relevant information can be displayed to the user (medical personnel and/or human expert) for validation or for teaching.

1. EXPERT SYSTEM ARCHITECTURE


The proposed architecture of the expert system for the medical diagnosis support in cardiology is presented in Figure 1 and is a simplified form of structure presented in [1, 2]. The name of this expert system is MSES_EFG_UPIT.01. It contains six main modules and their functioning will be bellow shortly presented. COMMUNICATIONS Module has the role to enable the communication between the expert system and the user or the human expert, but also the communication with the external source of the information to be analyzed. The Communication Module is performing the conversion of the information from the external format, humanly understandable, to the internal format of database (DB) and vice versa. The module is submitting the completely defined problem (cdp) to the Resolution Module to be solved, submits the knowledge object input (koi) to the Knowledge Base when the human expert needs to update the facts and the rules databases and also submits the knowledge object request (kor) when the human expert needs to access the information from the Knowledge Base. The communication module from the figure 1 ensures the communication with the external environment through the following interface types: - With the human user: medical personnel (U.I.) exploiting the knowledge and the data; - With the human expert, updating the knowledge base of the expert system (H.E.)

ISSN 1453 1119

Robert CHIVU, Ilie POPA Interface of Expert System for Cardiologic Diagnosis Support

63

COGNITIVE Module is part of the knowledge subsystem, having the role of receiving the knowledge objects (ko) from the various sources, filter the information and prepare it to be added to the knowledge base (rules and facts) and selects the data from the knowledge base. This module has a complex functioning, thus: it receiving the knowledge objects input (koi) from the Communication Module and transmit it to knowledge base, when must be introduce a new object in knowledge base by the Human Expert; receive the knowledge object request (kor) from the Communications Module and transmit it to knowledge base, when a knowledge object is requested by the user, or receive this knowledge requested object from the Resolution Module, when this object is requested by the inference;

receive the knowledge object requested and recognized (ko) from knowledge base and transmit it direct to Communication module for the user, transmit it to Explanation module or to the Resolution Module for reasoning process. It is possible too, that in the resolution process, to be generate news rules or facts which must be introduce in knowledge base by the (koi) line. The conversion between the external formats of the data as it is received through the Communication Module. This module can communicate with the Diseases Dictionary by issuing a request for disease description (ddr) to extract the name of the disease that will used by the explanation module in the representation of the reasoning graph.

ko kor koi cdp e r adr ad rp dd ddr ddi E.DB E.DB.I. K.A.M.+ U.I. H.E.+K.E.+U

- knowledge object; - knowledge object request; - knowledge object input; - completely defined problem; - explanation; - resolution; - additional data request; - additional data; - resolution path; - disease description; - disease description request; - disease description input; - External Database; - External Database Interface; - Knowledge Acquisition Module and User Interface; - Human Expert + Knowledge Engineer + User; Figure 1. The Expert System Architecture
ISSN 1453 1119

64

UNIVERSITY OF PITESTI ELECTRONICS AND COMPUTERS SCIENCE, SCIENTIFIC BULLETIN,

No. 8, Vol. 1, 2008

KNOWLEDGE BASE contains the facts (data, information) and rules added by the human expert or generate in the reasoning process. The solution chosen for representing and storing the knowledge must ensure a facile update and retrieval of the information. Following a knowledge object request (kor), the Knowledge Base returns a knowledge object (ko) to the Cognitive Module. The Knowledge Base can be updated with knowledge objects (koi) through the Cognitive Module which is filtering the information. The Knowledge Base consists from the following components: 1) Rules Database. The rules are elements describing the way the facts are used. All the rules are gathered in the rules database which can be interrogated and updated. 2) Facts Database. It contains the facts from the structure of the expertise domain and the facts needed to solve the problem under investigation. This database is also containing the models used in solving the problem DISEASES DICTIONARY. It is a dictionary containing the standard codes of the diseases associated with the disease name and a short description in the Romanian and the English languages. The dictionary can be updated by the human expert and the knowledge engineer only.

below. The graphical interface and the functions of those interfaces are designed and implemented using the C# programming language. 2.1. Interface with external specific equipments or external databases This interface achieves the connection with the external data collections for the interesting medical case data. The patient data can be retrieved from the specific medical equipment, from the telemedicine network in an adequate electronic format (file), medical user, the human expert or knowledge engineer. The input data can be stored as: - XML file representing a list of EKG trace values, EKG trace characteristics (derivation, scale), and patient data; The EKG XML point is represented by pairs of: o Amplitude; o Time. - Bitmap files from scanned EKG draws. The image is translated into list of values by recognizing the points of the trace using a digitization device; - Database records in a format that is recognized and accepted by the expert system. The source for the data can be opened by using a special conversational interface of the expert system. The shape and the structure of the external database interface are presented in figure 2.

2. INTERFACES OF EXPERT SYSTEM


The expert system is endowed with a couple of interfaces types specific to the user categories. The interfaces will be presented

ISSN 1453 1119

Robert CHIVU, Ilie POPA Interface of Expert System for Cardiologic Diagnosis Support

65

Figure 2. Interface with the external data collection

There are five main sections of the external database interface window: File selection. In this section the user is allowed to enter the file name and the file path for the input/output data. The section contains the following fields and buttons: - File path: is the initial file path for the input/output data; - File name is the initial name of file for the data; - Open... button: allows the user to select a file as a source for the input data and performs the action of loading the EKG data from the file. The file selection is done by using the operating system standard File Open dialog, where the initial path for the file is retrieved from the File path text entered by the user, and the initial file name is retrieved from the File name text. - Save... button: allows the user to select a file as a destination for the output data and performs the action of saving the EKG data into the file. The file selection is done by using the operating system standard File Save dialog, where the initial directory is set in the same way as for the File Save dialog.

DB selection. This section contains fields allowing the user to enter the name of DB server and database name for input/output data. The section contains following fields and buttons:

the the the the

- Server: is the is the name of the DB server; - Database: is the name for the database; - Open... button: allows the user to retrieve the EKG data from the database specified by the Server and the Database fields. The data will be selected based on the Last Name, First Name and/or CNP information entered in the Patient data section - Save button: is saving the currently loaded data into the database specified. Patient data. This is a section allowing the user to see and to enter the key information about the EKG data: first name, last name and the CNP of the patient. This information is uniquely identifying the patient. Another important information displayed in this section is the time stamp of the EKG data. The first name, last name and the CNP fields can also be used to select the information from the external database.

ISSN 1453 1119

66

UNIVERSITY OF PITESTI ELECTRONICS AND COMPUTERS SCIENCE, SCIENTIFIC BULLETIN,

No. 8, Vol. 1, 2008

There are also two buttons in the Patient data section allowing the user to see the stored information: Details... button fro the patient details such as previous diagnosis, age, sex, etc.; and: Traces... button providing an overview of the EKG traces. Help: is a text area where the system is displaying information helping the user to understand the meaning and the usage of the GUI controls. The text area is displaying the information whenever the user is selecting a specific control from the screen, offering the information about the control. Messages: it is a text area where the system is displaying status messages to the user, such as specific action completion messages, warning messages, error messages. For example, the input data is filtered for the values that are out of the definition domain, and an error messages are issued in the special status window of the interface whenever invalid data is encountered or integrity rules are broken. The following information is stored in the external database: - Patient data: this information is stored in a distinct section of the XML document, marked with the <PatientData> tag. The following relevant patient data is stored: o First name: marked <FirstName> XML tag. o Last name: marked <LastName> XML tag. with with the the

o Age: marked with the <Age> XML tag. o Sex: marked with the <Sex> XML tag. o Previous diagnosis: marked with the <PreviousDiagnosis> XML tag. The diagnosis is encoded such as it can be processed by the expert system. - Time stamp: marked with the <EKGTimeStamp> XML tag, the field contains the date and the time of the EKG data. - EKG traces: the XML document section is marked with the <EKGTraces> XML tag, and each trace is marked with the <EKGTrace> XML tag. Traces are identified by trace type (marked with <TraceType> tag) and contains a list of EKG points (the section being marked with the <Points> tag). 2.2. With the user and with the human expert The interface is exchanging the following information: a. Queries addressed to the expert system, asking for results of the input data processing. b. EKG trace displayed on the screen or/and on the printer. The interface with the user and with the human expert is presented in the figure 3.

o CNP as an unique identifier of the patient, marked with the <CNP> XML tag.

ISSN 1453 1119

Robert CHIVU, Ilie POPA Interface of Expert System for Cardiologic Diagnosis Support

67

Figure 3. Interface with the user and with the human expert

There are six main sections for this interface: Resulting diagnosis: where the diagnosis obtained from EKG data analysis is displayed in text format. Reasoning explanation: where reasoning path is explained to the user. the

- Load data: the External database interface is involved, and the user can select the patient data for analysis; - Analyze: the button to trigger the data analysis with the purpose of generating the diagnosis; - Show traces: the button will trigger the display of a sub screen where all the available EKG derivations are displayed. The EKG traces screen is shown in the figure 4. - Patient data: showing a sub window where the user can review all the patent data details. The EKG traces sub screen can display all the 12 derivations of the EKG. The EKG traces are scaled to fit into the display area and the user can chose to display or to hide each trace by selecting the associated check boxes. The checkboxes are disabled if the specific trace is not available.

Q&A: where the expert system is posting the questions to the user and the user can answer in text format dialog. The questions are needed to gather additional information from the user, whenever the EKG data is not enough to reach a conclusion. Help: contextual help area, showing the context sensitive information to the user. Message: messages. text area for the status

Actions: it is an area where the user can select the following actions:

ISSN 1453 1119

68

UNIVERSITY OF PITESTI ELECTRONICS AND COMPUTERS SCIENCE, SCIENTIFIC BULLETIN,

No. 8, Vol. 1, 2008

Figure 4. EKG traces

2.3. With the knowledge engineer The knowledge engineer is also the expert system administrator, having the role to add the facts and the rules to the system through an interactive screen. The administrator is also defining the user access rules from this interface, such as the data protection is ensured. The following user roles can be defined by the administrator, each user role having a specific set of access privileges to the application functionalities: - User: which is the final user of the system such as medical personnel; - Human expert: who is providing the medical information to the knowledge engineer; - Knowledge engineer: who is the administrator of the system and can enter and maintain the set of decision rules. The expert system can be used in one of the following modes: - Learning mode - Query mode The steps to be followed in the learning mode are: 1) Get the EKG data from the selected source (file, database). 2) Display the available traces (up to 12 leads). 3) For each EKG lead, the user will select the derivation (aVL, etc.) if the data is

not available at the moment. In the future it could be possible to acquire the 12 lead EKGs directly from the source. 4) Define the usable area(s) of the EKG, necessary when the trace is not stabilized from the beginning of the points array. It is possible to define more usable segments. 5) Select trace segments and associate them with morphological characteristics (i.e. wide QRS, negative T wave, etc.). 6) Save the morphologic characteristics in the knowledge database. 7) Define the reasoning rules combining the characteristics to reach a diagnosis. The knowledge engineer morphological characteristics in data structure for the characteristics will contain information: - Characteristics (negative example); - Description (free text). The steps to be followed in the query mode are: 1) Get the EKG data from the selected source (file, database). can define the this phase. The morphological the following

- Trace identifier (V1, V2, aVL, etc.); T wave for

ISSN 1453 1119

Robert CHIVU, Ilie POPA Interface of Expert System for Cardiologic Diagnosis Support

69

2) Display the available traces (up to 12 leads). 3) For each lead, the user will specify the derivation (aVL, etc.) if the data is not available at the moment. In the future is could be possible to acquire the 12 lead EKGs directly from the source. 4) Define the usable area(s) of the EKG, necessary when the trace is not stabilized from the beginning of the points array. It is possible to define more usable segments.

5) Use the morphologic information to build the curve characterization. 6) Based on the morphologic characteristics we can infer the electrophysiological characteristics. An interesting feature that could be developer in the future could be to specify an electro-physiological syndrome and to display the corresponding EKG trace. This feature would be useful both the educational purposed and for the medical expert to query the knowledge database.

Figure 5. Interface with the knowledge engineer

3. IMPLEMENTATION
The expert system interfaces presented in this paper are implemented using the C# programming language and .NET Framework. C# is a simple, type-safe, object oriented, general-purpose programming language. Visual C# provides code-focused developers with powerful tools and language support to build rich, connected web and client applications on the .NET Framework. The .NET Framework is Microsoft's managed code programming model for building applications that have reach user experiences, seamless and secure

communication, and the ability to model a range of business processes. In addition to the .NET Framework 2.0, it includes Windows Presentation Foundation (WPF), Windows Workflow Foundation (WF), Windows Communication Foundation (WCF), and Windows CardSpace. The implementation of this interfaces uses the following classes for:
GUI System.Windows.Forms.Form, System.Windows.Forms. PictureBox, System.Windows.Forms.OpenFileDialog DB Connection

ISSN 1453 1119

70

UNIVERSITY OF PITESTI ELECTRONICS AND COMPUTERS SCIENCE, SCIENTIFIC BULLETIN,

No. 8, Vol. 1, 2008

System.Data.SqlClient.SqlConnection, System.Data.SqlClient. SqlCommand, System.Data.SqlClient. SqlDataReader Generic utilities System.Collections.Generic.List, System.Math IO System.IO.Stream, System.IO.StreamWriter public class EKGTrace { List<EKGPoint> _points; public void DisplayTrace(Graphics Graph, int Width, int Height, uint Mode) { float min = (float)0.0, max = (float)0.0; int unit = 0, needed = 0; float diff = (float)0.0; int width = Width; int height = Height; GetMinMaxValues(ref min, ref max); diff = max - min; needed = (int)Math.Ceiling(diff); unit = height / needed; float bottom = (height - diff*unit)/2; Pen myPen = new Pen(Color.Black, 2); for (int i = 1; i < _points.Count; i++) { EKGPoint point = _points[i]; myX = (int)Math.Round((point.X) * (float)unit, 0); myY = (int)Math.Round((point.Y - min) * (float)unit + bottom, 0); Graph.DrawLine(myPen, myPrevX, myPrevY, myX, myY); Implementation of graph shape EKG with class above presented is showed in Figure 6. Figure 6.

4. TESTING AND ASSESSING


The interface prototype purpose was implemented and tested by a using various sets of real data (from some cardiology medical clinic), retrieved both from the database and from files in the described format. The data was previous verified and introduced in an external file in the off-line mode and when all these data was correctly are transferred in the database files The GUI class was implemented and tested, checking if accurate traces are correct scaled and displayed. The results of tests was good for used data, in accord with the purposes formats, but the complete and real tests can be made only when will be design and realize all others module of this expert system architecture. The complete verifying and eventually adapters of these interfaces will be made when the purpose expert system will be full.

5. CONCLUSIONS
The paper present an expert system general architecture (figure 1) with applications in medical field that provide support for medical diagnosis based on the EKG information retrieved from the human subject. The general functions of all architecture modules are presented, but is detailed only the communications module with their interfaces. All others parts will be presented in others papers. The interface are realize thus that to be easy to use, friendliness, intuitive, reliable, without to involve a special sophisticated preparation for the medical personnel that use it. The complete operationally of these interfaces will be tested when will be design,
ISSN 1453 1119

Robert CHIVU, Ilie POPA Interface of Expert System for Cardiologic Diagnosis Support

71

implement and full tested all modules of the expert system. Is possible that make some adjusted when will be design and realize the other modules.

[4] Vincent Jacquemet, Adriaan Van Oosterom, Jean-Marc Vesin, Lukas Kappeber, Analysis of Electrocardiograms During Atrial Fibrillation, IEEE Engineering in Medicine and Biology Magazine, November/December 2006 [5] Richard P.M. Houben, Maurits A. Allessie, Processing of Intracardiac Electrocardiongrams in Atrial Fibrillation, IEEE Engineering in Medicine and Biology Magazine, November/December 2006 [6] Ph. Bourlas, E. Giakoumakis, G. Papakonstantinou, A knowledge acquisition and management system for ECG diagnosis, www.iit.demokritos.gr/skel/eetn/ acai99/workshops/w13/w13_06.pdf.gz

REFERENCES
[1] Ilie Popa, Expert Systems for Nuclear Processes Control, PhD. Thesis, Transylvania University, Brasov, 1997 [2] Ilie Popa, Expert Systems, University of Pitesti, 2001 [3] Warren K. Muldrow, CALVIN: A Rule Based Expert System for Improving Arrhythmia Detector Performance During Noisy ECGs, Massachusetts Institute of Technology, 1987, MIT/LCS/TR-406

ISSN 1453 1119

You might also like