Junchuan Zhou's profileTechnical Centre...BlogLists Tools Help

Junchuan Zhou

Occupation
Location

Technical Centre...

The One for Study, Research and Work
July 20

The paper for "Student Conference on Electrical Engineering 2006"


Online Medical Assistant (OMA):
A Dynamic Collaborative Web-based
Medical Decision-Support Intelligent System
 

Z. Junchuan, C. Xufeng, W. Jingbo, D. Meyer, M. Fathi-Torbaghan

Institute of Knowledge-based Systems, Department of Electrical Eng. and Computer Science
University of Siegen, Germany

 
Abstract:  The Online Medical Assistant (OMA) is a dynamic collaborative web-based medical decision-support expert system in which medical self-diagnosis expert systems are integrated inside as medical engines which respectively focus on different medical domains, and the portal of the system plays the role of a coordinator which merges the web pages, medical engines and all kinds of application programming interfaces (API) into one web-based system. The Development of such kind of web-based medical decision-support expert system is not intended to replace the role of physicians in the diagnostic inference process, but to be a decision-support assistant for the physicians and medical experts in the procedures of diagnostic reasoning.
 
Keywords:  Fuzzy Logic, Decision-Support systems, Medical Expert Systems, Acute Abdominal Pains, Self-learning, Self-growing, Self-diagnosis Medical systems, Medical Knowledge Base.

 
1.  Introduction
 
The diagnostic reasoning procedure of a physician is to find out a list of diagnostic possibilities for the patient based on the presented symptoms. To master this process he had to study many relationships of obligatory or facultative proving or excluding symptoms for diagnosis in books and journals and in his practical experience. But all of these efforts can not guarantee the diagnostic accuracy.
 
For instance in the field of Acute abdominal pain (AAP) which is the most common surgical emergency. Although AAP is a common problem, diagnosis, particularly in the early stages of presentation, it is often difficult and only around 50% of patients are correctly diagnosed when first presenting to hospital. This leads to unnecessary admissions, investigations and interventions. The introduction of new technologies and investigations, such as ultrasound and CRP, has not significantly improved this situation. The negative appendectomy rate is still between 20 to 30% and as high as 50% in young women. [1] What makes the diagnosis of AAP particularly difficult is the fact that many acute abdominal pains show a large overlap in terms of their symptoms, e.g. the causes of abdominal pain with vomiting and jaundice include: Acute Pancreatitis; Cholecystitis; Gallstones; Pancreatic cancer; Stomach cancer and so on. [2]
 
This situation could be improved by the standardization of the methods for the acquisition of the medical history and examinations, and with the help of computer aided diagnostic systems which named medical expert systems. [3] The most important ingredient in any medical expert system is the medical knowledge bases, as the power of medical expert systems resides in the specific, high-quality knowledge they contain in certain domains.

Medical knowledge bases contain the information about relationships that exist between symptoms and symptoms, symptoms and diagnoses, diagnoses and diagnoses, more complex relationships of combinations of symptoms and diagnoses to a symptom or diagnosis. The knowledge bases are difficult to be improved, because the effort from a few professionals is obviously not enough. For most diagnosis expert systems, it takes many years to develop but still not walk out the laboratory. [4] Due to this fact, nowadays more and more medical experts and software engineers are working together to develop the web-based medical expert systems, as such kind of system provides the possibility to allow the developers from all over the world to take part in the construction of medical knowledge bases and the development of the system.
 
Our medical decision-support expert system “Online Medical Assistant” is such a web-based medical expert system which supports even the normal patient users to take part in the construction of the system. The development of such a dynamic collaborative web-based medical decision-support expert system is totally a new idea, as it not only allows the user to make online medical self-diagnosis, to communicate with medial experts and web developers, the users can even take part in the construction of the medical knowledge bases of the medical engines which focus on different medical domains. The portal of the system is used as the console for the developers, e.g. the medical experts and the software engineers, to cooperate with each other, and the medical knowledge attributes and settings of the medical engines can be modified by the developers just in the browser instead of editing the source code line by line on the server side. Upon the flexible structure of the “Online Medical Assistant”, the accuracy of medical diagnosis is expected to be enhanced remarkably.
 
 
The main features of Online Medical Assistant can be summarized as follows:
 
Flexible: All the settings and attributes of the medical engines which are integrated inside the system can be directly modified in the browser. After the developers trigger the event of “Update System” (click the button of “Update System” in the corresponding web page), then the whole system will be updated immediately.
 
Robust: The medial engines in the system are developed based on fuzzy logic so that these engines can work on the imprecise, incomplete patient data. In the standard web-based patient data questionnaire, the option of “Ignore this Question” is implemented which is used to pass the questions which the patient users are not sure.The diagnostic inference component of the system only works on the symptoms the users have answered unambiguously, and then converts these linguistic patient data into the corresponding numeric symbols which the computer can recognize. The more symptom questions the users answer, the more medical factors will be considered into the heuristic reasoning by the diagnostic inference component of the medical engines, so that the accuracy of the final diagnostic inference results will be enhanced correspondingly.
 
Self-growing: Just in the browser, the patient users can submit his or her personal patient cases to the system with their final official discharge diagnosis acquired from hospitals or other medical institutes. These patient cases can be loaded into the medical knowledge base of the corresponding medical engines and used as reference cases under the agreement of the administrator.
 
Self-learning: The intermediate data and tables which the heuristic reasoning is based on can be refreshed and recreated automatically by the automatic knowledge acquisition component of the medical engines whenever their medical knowledge settings are modified by the medical experts or other developers.
 
2 Medical Engine (MEDUSA)
 
2.1 Overview
 
The OMA is composed of several medical engines which are integrated inside the system and coupled with each other by the portal as showed in Figure 2.
 
The medical expert system MEDUSA is such a medical engine which is a decision-support expert system for the diagnosis of Acute Abdominal Pains (AAP). The system is intended to be an active assistant for the physician in diagnostic situations and helps the physician with diagnosis and therapy by providing diagnostic proposals and explanations. The main features of MEDUSA are listed as follows.
 
1) MEDUSA is based on fuzzy logic, which means the system uses fuzzy sets and fuzzy relations to realize the representation and application of uncertain and imprecise knowledge so that the inexact medical entities can be modelled by fuzzy sets and the uncertain medical associations can be modelled by fuzzy relations. [5][6] In addition, fuzzy logic enables the formal treatment of making approximated inferences on the basis of fuzzy data and fuzzy relations.
 
2) MEDUSA possesses an automatic knowledge acquisition component which starts from a given case database, automatically computes the relations between the medical entities contained in the patient cases database.
 
3) MEDUSA has over 60 rules and 4000 fuzzy relations. Its patient case database consists of 1256 cases. The diagnostic inference process is based on about 200 symptoms.
 
4) The main idea of MEDUSA is to use the rule based reasoning for the representation of normal cases, the heuristic reasoning for making uncertain, hypothetical inferences on the basis of fuzzy data and fuzzy relations.
 
The methodologies are listed as follows:
Rule-based reasoning: Rule-based reasoning makes use of known and safe knowledge about definite causal associations between symptoms, symptom-combinations and diagnoses, and is appropriate for making certain inferences on the basis of accurate data.

Approximate heuristic reasoning: The approximate heuristic reasoning, however, makes use of uncertain knowledge about blurred causal associations in the form of fuzzy relations between symptoms, symptom-combinations and diagnoses and is, therefore, perfectly suited for making uncertain, hypothetical inferences on the basis of fuzzy data and fuzzy relations.
 
2.2 Internal business logic of the Web-Based Medical Engine: MEDUSA
 
The Web-based medical expert decision-support system “MEDUSA” is composed of several basic components. The 4 components which marked with bubbles are the most important ones in MEDUSA, and are introduced in the following sections respectively.
 
Figure 3: internal business logic of MEDUSA
 
2.2.1 Interpretation of Patient Data Component
 
In MEDUSA, a standard patient data questionnaire is used to acquire the symptoms data from the patient with his or her medical history, physical and special examinations. These data are quantities, numeric or qualitative (for instance, the type of pain, and location of pain).
 
Membership functions of the fuzzy sets: The interpretation of patient data component enables the calculation of the degrees of presence for every symptom. The interpretation is based on the representation of the symptoms in form of sharp sets and fuzzy sets. [5] The data are interpreted and thus reach a higher level of abstraction.
 
Let the membership function of the fuzzy set “elevated temperature”, which is defined on the basis of the measured temperatures T, be:        
 
Figure 5: Membership function of Fuzzy Sets
 
With the given measured temperature of 37.7, the degree of presence of the symptom “elevated temperature” is computed as 0.4.
 
2.2.2 Automatic Knowledge Acquisition Component
 
Fuzzy Relations: Different from other fields, diagnosis of AAP is not based on unequivocal categorical, or pathognomonic associations, but mainly on imprecise and uncertain symptom-diagnosis relations. The medical relations between symptoms and diagnoses are represented in the form of fuzzy relations.
 
Five different types of fuzzy relations:
1)DS:how often does a certain symptom occur in connection with a certain diagnosis? (frequency)
2)DSC: how often can a certain combination of symptoms are observed in connection with a certain diagnosis? (frequency)
3)SD: to which degree does a certain symptom characterize a certain diagnosis? (selectivity)
4)SCD: to which degree does a certain combination of symptoms characterize a certain diagnosis? (selectivity)
5)SS: the degree of correlation with the correlating symptoms.
 
Figure 6: Automatic Knowledge Acquisition component
 
The automatic knowledge acquisition component enables the automatic acquisition of fuzzy relations between symptoms and diagnoses from a given patient cases database. The SD and DS fuzzy relations are computed by the automatic knowledge acquisition.
 
2.2.3 Diagnostic Inference Component
 
The Diagnostic Inference Component is composed of the categorical rule reasoning and approximate heuristic reasoning.
 
Figure 7: Diagnostic Inference Component
 
1) Categorical Rule Reasoning: Category rules are used to store the knowledge about absolutely certain associations. These rules have the following forms:

IF the patient shows   (respectively   ... ) THEN the diagnosis is   (respectively).

So in this step, all possible certain conclusions are drawn. (For instance, a man will not be a pregnant)
 
2) Approximate Heuristic Reasoning: Diagnoses which have neither been excluded or established (hypothesis diagnoses) are evaluated on the basis of the given symptoms and the stored symptom diagnosis relationship. The fuzzy relations and the hypothesis rules are used in this process. For every diagnosis, an evaluation is computed. Dependent on a comparison of these evaluations, the diagnoses are classified as probable, possible or not probable diagnoses.
 
Hypothetical diagnoses Equations:
Evaluation = the priori evaluation of the diagnosis
+ Evaluation of expected, associated, present or partly present symptoms
-  Evaluation of expected, associated, not present symptoms
-  Evaluation of present, associated, not expected symptoms
 
2.2.4 Case Searching Component
 
For the registered users or medical experts, they can use this component to make composite searching in the patient cases database in the corresponding medical engines.
 
In MEDUSA, the Case Searching Component allows the user to customize the table which is used to display the results from the composite searching so that only the symptom columns which the users are interested in will be displayed on the web page instead of displaying cases with all 45 symptom columns.
 
Every time, the component at most supports the query phrase with the logical relationship between 3 digital symptoms and 5 linguistic symptoms to build the SQL statement to search through the cases database in MEDUSA. After the system feeds back the results, the user can select these cases to view details with their official discharge diagnoses or directly trigger the diagnostic inference component to calculate on. After the calculation, the diagnostic inference results will be displayed on the web-page. Thus, the user has two diagnostic results for one selected patient case, one is the discharge diagnosis from hospital, and the other is the one from our diagnostic inference component of the medical engine. For the registered user, he can click the “View Detail” button to view the report of the entire inference process of the diagnostic inference component which actually provides the possibility for the users to find out the reason why the discharge diagnosis is different or identical with the diagnostic results suggested by our medical engine.
 
2.3 Functions
 
The web-based medical engine MEDUSA provides 5 main functions to different roles of uses as showed in Figure 9.
 
1) Cases base: The one designed for the users to make simple searching through the patient cases database. The searching is based on the answers from the 4 simplest questions which are:
1.Your gender?
2. Where is the pain?
3. Which type of the pain?
4. How hard is the pain?
And then all the cases which meet these 4 answers will be displayed on the web page, the user can choose these cases to view details.
 
2) Fill in: The one designed for the user to make online self-diagnosis.
 
3) Case searching: The one designed for the registered user to make composite searching through the patient cases database.
 
4) Med View: The one specially designed for the medial experts to view the internal knowledge attributes and settings of MEDUSA.
 
5) Config: The one designed only for the administrator to manage, modify and update the medical knowledge attributes or add new patient cases into the patient cases database. The logic flow chart of this function is showed in Figure 10.
 
3 The Portal
 
The Portal is the interface between the Client and Server. The main functions the portal provides are as follows:

- Prompts the user to type in the data which the web-based system can recognize.
- Acquires users’ requests, and delivers them to the Server.
-  Presents the responses from the Server to the Client in the web pages.

-  Displays the public information of the web-based application.
-  Realizes the purview of functions the applications provide to the different roles of users.
-  Directs the user to walk through the whole web-based medical applications.
-  Provides the platform for the users to communicate with each other.
-  Provides the console for the Administrator and other co-operators to work with.

 The portal in Online Medical Assistant is actually the coordinator who merges the web-pages, medical engines and APIs into one web-based system.


3.1 The Roles

 
There are four types of user roles implemented in Online Medical Assistant, who are:
 
- Anonymous Users: The users who have not registered in the portal.
- Registered Users: The users who have registered in the portal.
- Medical Experts: The users who have registered in the portal and been assigned the role of Medical Experts by the Administrator. Normally Medical Experts are the persons who are the physicians in the hospital or the medical experts in official medical institutes or research centres.
- Administrator: The role of the developer or manager of the system. Administrator is not one person, but a kind of persons who have the right to view the internal medical knowledge settings and attributes of the web-based medical engines, to modify and update the whole website configuration as well. The role of Administrator can be delegated by the default Administrator to medical experts, or registered users.
 
3.2 Portal Functions
 
1) Forum: The integration of the Forum into the web-based application is really a big progress in promoting the quality and quantities of the functions the system provides to the users. [7] The Forum in OMA provides the following functions:
 
1. Mailbox:
With which users can use to communicate with others.
- For the medical expert, it can be used as the private channel to express his or her opinions on certain medical knowledge attributes and settings of medical engines to the administrator.
- For the normal registered user, it can be used to send private messages to the medical experts for consultation or to share personal experiences with other users.
 
2. Discussion Sections which is composed of:
- Medical knowledge Section: The one to be used as the medical diagnoses and symptoms lexicon.
- Patient Experience Exchange Section: The one to be used as the platform to share the users’ personal experience in coping with certain specific disease.
- Medical Expert Systems Section: The one to be used as the tutorial for the users to walk through all the functions integrated in Online Medical Assistant.
 
3. Search the topics which the users interest by “post name” or “post author” which proved to be a very efficient way for the users to acquire information they needs instead of finding posts in a dozen of subsections of subsections in the forum.
 
2) Feedback: The Feedback is the function the portal provides for the users to rate the OMA and address their personal opinions or suggestions to the administrator. It consists of the following 2 parts:
1. Rate the Web: The user chooses the numbers from 1-9 to rate the quality of the web. The bigger is the better.
2. Give the Reason (Optional): The user can type in his opinion in the text box on the web page and click the “Submit” button to send it to the Administrator.
 
3) Website configuration Interface: The link of the website configuration interface will only appear on the web page when the administrator logged in to the website. This is the API specially designed to configure and manage the whole website. With using this configuration interface, we can encrypt all the configuration settings of the website, so that the settings in our web-based applications are in the status of secret, and the security of the whole website is correspondingly promoted.
 
4 Conclusion
 
4.1 Summary
 
During the last decades, computer has been widely used in all kinds of fields. The medical diagnosis can't be excluded either. With the help of computer, the relations between the symptoms and diagnoses are concluded based on not only the experience of physicians but also the statistics of the cases.
 
The previous traditional medical expert system are the ones which are only computer-based instead of internet-based which tremendously limited the usage of these perfect medical expert systems, and meanwhile the knowledge bases are difficult to be improved as the effort from only a few professionals are obviously not enough. For this reason, the most diagnosis expert systems took many years to develop but still not walk out of the laboratory.
 
Nowadays, with the big progress in IT technologies, especially the appearance of ASP.NET which is a revolution in the development tools of web-based applications, so that we can locate our medical expert system onto the internet to be a web-based application for the users no matter where they are.
 
As has been introduced, our Online Medical Assistant is not only a medical expert system for the patient users to make self-diagnosis, but it is a dynamic collaborative web-based system which provides consoles for the medical experts, software engineers, to cooperate with so that the system can be updated directly in the browser without editing thousands lines of source code. Besides, the knowledge base of the web-based medical engines can be expanded with the contribution of the normal registered users and medical experts which makes our system to be a self-learning and self-growing one. Upon these advantages, the accuracy of medical diagnosis is expected to be enhanced remarkably.
 
4.2 Shortcomings and Outlook
 
Some Shortcomings of OMA will have to be eliminated in the course of further development and many functions need to be improved and expanded. The most important of these are:
 
1) The improvement of diagnostic inference reports: The diagnostic inference results should be not as simple as a list of the diagnoses ranked by their corresponding presence possibilities, but also with more additional information, for instance the diagnoses urgency statuses and the corresponding recommendations.
 
2)  Optimize the medical knowledge settings of the medical engine: These medical knowledge settings include the weights and the relationship status between symptoms and diagnoses need to be optimized.
 
3) The hypothetical diagnoses equations of the web-based MEDUSA should be expanded: The following two sub-equations can be added into the main hypothetical diagnoses equation.
1. Evaluation of associated, present or partly present combination symptoms
2. Correlations between present symptoms
 
4) More abdominal diagnoses can be added into the web-based MEDUSA: Now the web-based MEDUSA can only give diagnostic inferences on 12 abdominal diagnoses, but the inferences on more diagnoses are expected.
 
5) More Medical Expert Engines can be added into the system: The Medical Engine MEDUSA is only working on AAP. Later there can be more and more medical engines integrated into OMA which focus on other medical domains.
 

Acknowledgements:
 
The Online Medical Assistant studies have been conducted in the Institute of Knowledge-based systems at the University of Siegen by Prof. Fathi, and cooperated with Microsoft and Prof. Reul from the hospital of Kreisklinikum Siegen in Germany.
 

Reference:
 
[1] Computer aided diagnosis of Acute Abdominal Pain from the Clinical Information Science Unit, University of Leeds & Media Innovations Ltd,  Education and Decision Support for Junior Doctors, [Accessed 22nd, May, 2006] Available from:URL:http://www.media-innovations.ltd.uk/AAP.htm

[2] The National Medical Society, Library of the National Medical Society, 2005 [Accessed 25th, May, 2006], Available from URL: http://www.medical-library.org/

[3] M. Fathi-Torbaghan, D. Meyer, MEDUSA: A Fuzzy Expert System for Medical Diagnosis of Acute Abdominal Pains, Meth. Inform. Med., Vol. 33, No. 5, 1994

[4] Bonnie Kaplan, Evaluating informatics applications - clinical decision support systems literature review, International Journal of Medical Informatics 64 (2001) 15–37

[5] L.A. Zadeh., Fuzzy sets, Inf. Control, 8, 338, 1965

[6] L.A. Zadeh., Fuzzy Algorithms, Info. & Ctl., Vol.12, 1968, pp.94-102

[7] Rick Kulkarni, MD, Medical Informatics in Emergency Medicine, E-Medicine from WebMD, February 9th,2005 [Accessed June, 28th, 2006], Available from URL: http://www.emedicine.com/emerg/topic879.htm
 

Address of the authors:
 
Prof. Dr.-Ing. Madjid Fathi Torbaghan
Dipl.-Inform. Daniel Meyer
M.Sc. Zhou, Junchuan
M.Sc. Chen, Xufeng
M.Sc. Wu, Jingbo
Institute: Knowledge-based Systems
Department: Electrical Eng. & Computer Science
University of Siegen
Hoelderlinstr.3
D-57072 Siegen, Germany
July 02

Documentation Centre:


Master Degree Certificate:
 

Siegen Univeristy School Reports: (Oct, 2003 - July, 2006)
 

APS Certificate:
(Botschaft der Bundesrepublik Deutschland Kulturreferat -Akademische Pruefstelle)
 

Language Certificate:
 
English:  TOEFL Certificate  (Oct, 2002)
German: TestDaF Certificate  (April, 2003)

Shanghai University School Reports:
 
The 1st and 2nd Year  (1999, 2000)
The 3rd and 4th Year  (2001, 2002)

Graduation Certificate: (July, 2002)
 

 Bachelor Degree Certificate: (July, 2002)
 

Study Project:


GPS & Sensor Node Integration
 
Final Grade:  1.0
Duration: 8 Months 
Submission Date: 28-02-2006

NAME :                  Zhou, Junchuan / Wu, Jingbo
DEPARTMENT:        Electrical Engineering and Computer Science
SUPERVISORS:      Prof. Dr. - Ing. habil. Otmar Loffeld
                             Dr. - Ing. Stefan Knedlik
                             M.Sc. Tech. Gustave Franck Tchere
The Objective:
Integrating GPS data into sensor nodes will help in localizing those sensor nodes with a certain precision depending on the quality of the GPS receiver. The Objective of our work is to integrate the GPS receiver with the 8051 Microcontroller and display the navigation values (longitude, latitude and UTC time) on the screen of the LCD.

Content:

Acknowledgement 1
Preface 2
Figures list 6
Tables list 7
Introduction 8
Brief introduction on GPS 8
Objective of the project 9
Brief introduction of all the chapters 9
Chapter 1: Extracting and parsing the GPS NMEA messages 10
    1.1 GPS receiver 10
        1.1.1 Hardware interface of the Rikaline GPS module 11
        1.1.2 Software interface 11
        1.1.3 Transmitted messages 11
    1.2 NMEA 0183 protocol 11
        1.2.1 The “GPxxx” sentence codes with the short descriptions 12
        1.2.2 An example in “$GPGGA” NMEA sentence message 12
    1.3 Reading GPS strings 13
    1.4 Parsing the GPS message strings 13
        1.4.1 Dissecting the GPS message strings 14
        1.4.2 Software flowchart for extracting the required information 15
        1.4.3 Source code for the identification of the “$GPGGA” message strings 16
            1.4.3.1 The “$GPGGA” message string format 16
            1.4.3.2 The source code to identify the “$GPGGA” message strings 16
        1.4.4 Source code to extract the UTC time 17
            1.4.4.1 The format of the UTC time values in the “$GPGGA” message strings 17
            1.4.4.2 The source code to extract the UTC time values 17
        1.4.5 Source code to extract the latitude information from GPS message strings 18
            1.4.5.1 The format of the latitude values in the “$GPGGA” message strings 18
            1.4.5.2 The source code to extract the latitude values 18
        1.4.6 Source code to extract the latitude cardinal direction values from GPS message strings 19
            1.4.6.1 The format of latitude cardinal direction values in the “$GPGGA” message string 19
            1.4.6.2 The source code to extract the latitude cardinal direction values 19
        1.4.7 Extracting and parsing longitude information from GPS message string 20
            1.4.7.1 The format of longitude values in the “$GPGGA” message strings 20
            1.4.7.2 The source code to extract the longitude values 20
        1.4.8 Source code to extract the longitude cardinal direction values from GPS message strings 21
            1.4.8.1 The format of longitude cardinal direction values in the “$GPGGA” message string 21
            1.4.8.2 The source code to extract the longitude cardinal direction values 21
Chapter 2: Interfacing serially with GPS receiver 22
    2.1 EZ-USB Microcontroller 22
    2.2 UART 23
    2.3 Serial communication 23
        2.3.1 Asynchronous serial transmission 23
        2.3.2 Baud rate 24
    2.4 The RS232 standard 24
        2.4.1 Ports 25
        2.4.2 Devices 25
        2.4.3 Connections 26
    2.5 The reasons to use UART ICs instead of normal I/O ports 26
    2.6 The Intel8251A programmable communication interface 27
        2.6.1 General introduction of Intel 8251A 27
        2.6.2 Functions descriptions of Intel 8251A 28
            2.6.2.1 Data bus buffer block 29
            2.6.2.2 Read/Write control logic block 29
            2.6.2.3 Receiver buffer block 29
            2.6.2.4 Receiver control block 29
    2.7 Connecting the Intel8251A to the EZ-USB MCU 31
        2.7.1 The Intel8251A interface 31
        2.7.2 Programming the Intel8251A 31
            2.7.2.1 Mode instruction definition 32
            2.7.2.2 Asynchronous mode (Receive) 32
            2.7.2.3 Command instruction definition 34
            2.7.2.4 Status read definition 34
        2.7.3 The connection with RS232 35
    2.8 The Philips SC16C2552B serial communication interface 36
        2.8.1 SC16C2552B block diagram 37
           2.8.1.1 Data bus and control logic block 37
           2.8.1.2 Register select logic 37
           2.8.1.3 Internal registers 37
        2.8.2 Programmable baud rate generator 37
        2.8.3 Hardware navigation diagram 38
Chapter 3: Programming the EZ-USB 8051 MCU 40
    3.1 Interrupt for serial communication 41
        3.1.1 Setting up interrupts 41
        3.1.2 Serial interrupts 42
        3.1.3 Serial interrupt service routine 42
    3.2 Timer setting to generate baud rate 43
        3.2.1 TMOD 43
        3.2.2 Baud rate 43
    3.3 Serial port controls 44
        3.3.1 SCON 44
        3.3.2 TMOD 45
        3.3.3 Program routine to initialize serial communication 45
Chapter 4: LCD setting 46
    4.1 Introduction of HD44780-based LCD modules 46
        4.1.1 The HD44780 standard 46
        4.1.2 An example of hardware configuration 47
    4.2 Pin assignment 47
    4.3 Function description 48
        4.3.1 Registers 48
        4.3.2 Instruction set 49
        4.3.3 Visible DDRAM addresses 50
    4.4 Interfacing 51
    4.5 Functions 52
        4.5.1 Checking the busy status of the LCD 52
        4.5.2 Initializing the LCD 53
        4.5.3 Additional functions 54
            4.5.3.1 Cursor positioning 54
            4.5.3.2 Writing a character to LCD 54
            4.5.3.3 Display data on the LCD in the format of 2 lines 55
Chapter 5: The demo 57
    5.1 Description of the simulation process 57
    5.2 The demo’s source code 58
    5.3 Test 61
Conclusion 63
Summary 63
Outlook for further development 63
Bibliography 64


Master Thesis:


Design & Implementation of the Dynamic Collaborative
Web-based Medical Decision-Support Expert System:
Online Medical Assistant
 
Final Grade:   1.0
Duration: 12 months
Submission Date: 14-06-2006

MAME:                  Zhou, Junchuan / Chen, Xufeng / Wu, Jingbo
DEPARTMENT:       Electrical Engineering and Computer Science
SUPERVISORS:     Prof. Dr. -Ing. Madjid Fathi Torbaghan
                           Prof. MD. J. Reul
                           Dipl. -Inform. Daniel Meyer

The objective of this project is to develop a dynamic collaborative web-based medial decision-support expert system in which medical diagnosis expert systems can be integrated as medical engines which specially focus on different medical domains, and the portal of the system plays the role of a coordinator which merges the web pages, medical engines and all kinds of API into one web-based system.

The content

Acknowledgement 
Preface II
Content V
Chapter 1: Introduction and Motivation 1

Chapter 2: Medical Diagnosis Expert System 4

    2.1 Introduction of Expert System 4
        2.1.1 The Structure of Expert System 4
            2.1.1.1 Knowledge Base 5
            2.1.1.2 Inference Engine 5
            2.1.1.3 Interface 6
        2.1.2 Knowledge Engineering 6
            2.1.2.1 Knowledge Acquisition 6
            2.1.2.2 Knowledge Representation 7
                2.1.2.2.1 Production Rules 7
                2.1.2.2.2 Semantic Networks 7
                2.1.2.2.3 Frame 8
            2.1.2.3 Validation of Expert System 9
                2.1.2.3.1 The concerns of validation 9
                2.1.2.3.2 The Validation Process 9
        2.1.3 Advantages and Limitations of Expert System 10
        2.1.4 Main Areas of Application of Expert System [4] 11
    2.2 Medical Diagnosis Expert System 11
        2.2.1 BBN-based diagnostic models [8] 11
        2.2.2 Relationships between Diagnosis and Symptoms 13
        2.2.3 Medical Diagnosis Expert System 13
        2.2.4 Introduction of the Available Diagnosis Expert System 14
            2.2.4.1 Mycin 14
            2.2.4.2 CADIAG-I/CADIAG-II 16
            2.2.4.3 An Intelligent Medical System for Diagnosis of Bone Diseases 17
                2.2.4.3.1 System Description [32] 17
                2.2.4.3.2 Knowledge Representation in XBONE 19
    2.3 Conclusion 20
Chapter 3: Fuzziness Theories 21
    3.1 Introduction 21
    3.2 Fuzzy set theory 22
    3.3 Linguistic variables 26
    3.4 Fuzzy control 28
    3.5 Fuzzy algorithms 30
    3.6 Fuzzy Expert Systems 32
Chapter 4: Acute Abdominal Pains 34
    4.1 Introduction 34
    4.2 Patient Data 37
        4.2.1 Anamnesis 37
        4.2.2 Physical Examination 38
        4.2.3 Tests 39
    4.3 Medical Knowledge 44
    4.4 Diagnosis 45
Chapter 5: MEDUSA 47
    5.1 Introduction 47
    5.2 Medical Knowledge 48
    5.3 MEUDSA 49
        5.3.1 Overview: 49
        5.3.2 Diagnostic Inference process of MEDUSA 51
            5.3.2.1 Overview 51
            5.3.2.2 Acquisition of Patient Data and Examination of Patient Data 51
            5.3.2.3 Interpretation of Patient Data 52
            5.3.2.4 The Hybrid Concept of the diagnostic inference procedure 52
            5.3.2.5 Display the Report of Diagnostic inference 53
    5.4 Data documentation and interpretation 54
        5.4.1 Membership function of the fuzzy sets 55
        5.4.2 Fuzzy Relations 55
    5.5 Automatic Knowledge Acquisition Component 56
    5.6 Special Case Acquisition Component 57
    5.7 Evaluation of Hypothetical diagnoses 58
    5.8 Hypothetical diagnoses Equations 59
Chapter 6: Online Medical Diagnosis Systems 61
    6.1 Introduction 61
    6.2 The Online medical Diagnosis Systems 61
        6.2.1 The AnalystTM 62
        6.2.2 YourDiagnosis 64
        6.2.3 MyElectronicMD 66
        6.2.4 Online Medical Assistant 68
    6.3 Summary 71
Chapter 7: Overview of Online Medical Assistant 73
    7.1 Introduction 73
    7.2 Technology Overview [53] 74
        7.2.1 The Microsoft .NET 74
        7.2.2 The .NET Framework 75
            7.2.2.1 Introduction of .NET Framework 75
            7.2.2.2 Common Language Runtime 75
            7.2.2.3 Class Libraries 76
    7.3 The 3-Tier architecture of Online Medical Assistant 76
        7.3.1 The Architecture of Online Medical Assistant 76
        7.3.2 The 3-tier architecture 77
        7.3.3 Presentation layer (GUI layer) 78
        7.3.4 Logic Layer 78
        7.3.5 Data Layer 78
            7.3.5.1 ADO.NET [58] 79
            7.3.5.2 The .NET Data Providers 80
            7.3.5.3 Connection strings 81
            7.3.5.4 Namespace Organization [58] 81
            7.3.5.5 The process of a DataSet populated by a DataAdapter object 82
            7.3.5.6 Data Binding 82
    7.4 Options of Client in .NET 83
        7.4.1 Introduction 83
        7.4.2 Win Form UI in C/S (Client and Server) 84
        7.4.3 ASP.NET UI in B/S (Browser and Server) 84
        7.4.4 Hybrid UI 85
    7.5 The Components of Online Medical Assistant 85
        7.5.1 Users 85
            7.5.1.1 Roles 85
            7.5.1.2 Functions 86
        7.5.2 Web-based decision-support expert system “MEDUSA” 87
            7.5.2.1 Architecture & business logic 87
                7.5.2.1.1 Automatic Knowledge Acquisition Component 88
                7.5.2.1.2 Interpretation of Patient Data Component 88
                7.5.2.1.3 Diagnostic Inference Component 88
                7.5.2.1.4 Case Searching Component 89
           7.5.2.2 The functions provided in the web-based MEDUSA 90
                7.5.2.2.1 Overview 90
                7.5.2.2.2 Cases Base 91
                7.5.2.2.3 Fill in 94
                7.5.2.2.4 Case Searching 98
                7.5.2.2.5 MedView 104
                7.5.2.2.6 MEDUSA Config 106  
7.5.3  The portal 111
                7.5.3.1 Introduction 111
                7.5.3.2 Login 112
                7.5.3.3 Forum 112
                7.5.3.4 Feedback 114
                7.5.3.5 Website configuration Interface 115
Chapter 8: Implementation of Online Medical Assistant 116
    8.1 Introduction 116
    8.2 Implementation of Online Medical Assistant 117
        8.2.1 Automatic knowledge acquisition component design. 117
        8.2.2 Interpretation of Patient Data Component design. 122
        8.2.3 Diagnostic Inference Component design. 128
        8.2.4 Case Searching Component design 134
        8.2.5 The API for update medical knowledge and system parameters design 137
        8.2.6 The user membership design 140
        8.2.7 Website configuration API design 144
Chapter 9: Conclusion 147
    9.1 Summary 147
    9.2 Outlook 148
Appendix 150
    Appendix-A: Bibliography 150
    Appendix-B: Figures list 153
    Appendix-C: Milestones and Time Flow 157
    Appendix-D: XML files index 158