General
About
The Diabetes Diagnostic System is an automated examining system that uses a probabilistic diagnostics engine to compute the likelihood of a person developing diabetes, based on that person's health history, and lifestyle. The system is geared to do its analysis based on various constraints that are provided both by experts in the field of diabetes and by the statistics that have formed within the system. Along with a diagnosis, the Diabetes Diagnostics System also generates some recommendations for lifestyle changes that will improve the patient's condition. This system stores all of a patient's medical information, along with the results for any of the diagnostic engine's calculations. This way, any changes of a patient's health over time, can be easily observed. The Diabetes Diagnostics System is designed in such a way that it is accessible to health care professionals, individuals, and researchers through the use of the internet. It also provides access to edit constraints and administrate the system remotely. The most helpful and unique attribute of the Diabetes Diagnostics system is that is provides an ever growing database of data and knowledge about diabetes, which can be shared and expanded upon by the community world wide, thus helping to diminish the cloud of mystery that shrouds diabetes.
Proposal
The idea and proposal for the diabetes diagnostics project came from Dr. Barranco-Mendoza a leader in the research and development of multidisciplinary diagnostics tools. When Dr. Barranco-Mendoza was working towards her PhD at Simon Fraser University she designed a cancer diagnostics system that used an innovative statistical engine to diagnose cancer in patients. Although this cancer diagnostics system was not implemented the statistical diagnosis research that Dr. Barranco-Mendoza had completed allowed her to purpose and envision a statistical diabetes diagnostics tool. The implementation of this innovative tool is taking place in two Canadian universities. Dr. Barranco-Mendoza, with assistance of Ms. Kimberly Voll, Ph.D. candidate at Simon Fraser University, are taking on the task of developing the statistical engine for diagnosing diabetes, while the team at T rinity Western University is developing the user and data frame work into which the diagnostics engine will be connected.
Authors
Trinity Western University Development Team
Left to right: Nathan Feng, Edie Lin, Sarah Gillis, Nicholas Erho
Vision
All though the diabetes diagnostics project is the development of a proof of concept prototype system, that is intended to be primarily accessed over the internet by general users for personal diagnosis and health professionals for patient diagnosis, is it envisioned that the project will evolve to be an integrated part of the health care system allowing easier use by medical professionals and more accurate results. Furthermore the additional artificial intelligence components in future versions will allow the system to learn from data stored in its own databases from information like previous results calculated and trends in patient data connected with diabetes so that system can fine tune its own statistical engine to produce more accurate diagnoses and possibly suggest new constraints through data mining techniques. At some point it has been suggested that a natural language processor could be implemented to help mine data out of medical records allowing for a higher volume of information for the system statistical calculation utilization.
Media
Click to View Newspaper Article
Project Documenation
Project Planning
The Diabetes Diagnostics System is a prototype for an automated examining system using a prolog diagnostics engine. The system would be geared to analyze information relating to the past and present health and life style of an individual patient using various constraints. Once this data has been analyzed the resulting statistic for the patient's likeliness to develop diabetes will be displayed along with recommendations for changes that the person can possibly make to reduce their chance of having or developing increased problems with diabetes. Recommendations are also made for further medical tests that will improve the accuracy of the system's statistical calculation.
This system will store information regarding the current and past health status of a patient as well as the results of the prolog diagnostics engine calculation so changes over time can be easily viewed. As well as patient health information the system will store all the constraints needed by the prolog diagnostics database in making the diagnosis calculation. Furthermore these constants in this database will need to be created, deleted, and modified. The data storage and the interfaces will need to meet the current bioinformatics standards. The Diabetes Diagnostics System will be designed in such a way that it will be accessible to health care professionals, individuals, and researchers through the use of the internet and also provide access to edit constraints and administrate the system remotely. In addition to availability of this system it will also have a 'back door' to allow for access with existing medical systems.
The first release of the prototype diabetes diagnostics system is scheduled for the end of April 2006, with the implementation process beginning in January 2006. Various analysis has been done in respect to the cost or problems associated with the undertaking of this project and it has been found that several legal issues could arise if the security of the data and the terms of use of the system are not taken into account.
Requirement Analysis
The prototype diabetes diagnostics engine will need to have the functions that are listed in Table 1. A list of possible user access schemes is also included; however it is important to note that these will not be predefined but user access privileges will be set by the administrator for the various kinds of users.
Table 1: Functional Requirements and User Type Access Summary
| Function Requirement | User Type Access | |||||
| Number | Description | Administrator | Expert | Researcher | Health Care Professional | Random Internet User |
| 1 | Delete Patient Record | Y | N | N | N | N |
| 2 | Creating Patient Record | Y | N | N | Y | N |
| Modifying Patient Record | Y | N | N | Y | N | |
| Updating Patient Record | Y | N | N | Y | N | |
| Search Patient Record | Y | N | N | Y | N | |
| Running the PDE on Patient Record | Y | N | N | Y | N | |
| 3 | Viewing Patient Record | Y | Y | Y | Y | N |
| 4 | Associate Patient Record with User | Y | N | N | Y | N |
| 5 | Create User Account | Y | N | N | N | N |
| Edit User Account | Y | N | N | N | N | |
| Delete User Account | Y | N | N | N | N | |
| 6 | Increase the system access privilege of another user | Y | N | N | N | N |
| 7 | View Constraint | Y | Y | Y | N | N |
| 8 | Create Constraint | Y | Y | N | N | N |
| Edit Constraint | Y | Y | N | N | N | |
| Delete Constraint | Y | Y | N | N | N | |
| Test CDB Logic | Y | Y | N | N | N | |
| 9 | Non Database access diagnosis | Y | Y | Y | Y | Y |
| 10 | Recommend Constraint | Y | N | Y | N | N |
| 11 | Login Users | Y | Y | Y | Y | N |
The interfaces have also been roughly defined with some of the basic elements that the final system will contain. However it is important to note that these are not the final look of the interfaces.
- A graphical walk through of the diabetes diagnostics system. Click to watch flash video.
- A system navigation road map. Click to view the diagram.
The system will be implemented using three data bases, one to hold the constraints needed by the probabilistic diagnostics engine, one to contain patient data, and finally one to store sensitive information that will be used to link the diabetes diagnostics engine to a preexisting medical system. The whole system and database will reside on a operating system and will allow users to connect over the internet through the use of the http protocol and a web server. Click to view the diagram
Due to the fact that the DDS is dealing with health information entered by health care professionals it is very important that the data in the system be secure. To ensure a tight reign of security the http interface between the web server and the user's browser must be encrypted (https) furthermore the personal contact information for patient records, such as a care card number to link an existing health care system to the DDS, will be stored in a separate more secure database. The only entity that can create user accounts is the administrator. This is done to ensure only people who have the credentials and legitimate needs to access the system are the only ones who have the ability to access it. Since, this means an increased amount of data entry by the administrators the system can allow more than one administrator user in order to distribute the task.
The projected users of the diabetes diagnostics system include general users who will be able to run a personal diabetes diagnosis test on themselves. In a similar way, health care professionals will be allowed to log on the system and work with patient records and run the diagnostics engine on any of the patients. To enter, edit, and delete constraints, as well as look after all the well being of the diagnostics part of the system diabetes experts will be required to access the system. Researchers will also need to be able to view constraints and patient data in the system and suggest possible constraints to the experts. Finally the system will have administrator users who would be responsible for the well being the whole system, such as creating and editing user account and keeping an eye on security. At all times there will be at least one administrator account in the database.
High Level Design
In order to help simplify the implementation of the diagnostics system it was broken down in modules shown in the diagram below.
This diagram illustrated the various external system components that the system will be interacting with, such as the web server, the probabilistic diagnostics engine and the various data bases. Furthermore this diagram shows three internal subsystems: one for dealing with users, one for working with constraints, and the last one concerning operations with the patient data.
Low Level Design
The system has been organized into its primary data structures from which a class diagram Click to view the diagram was derived. This class diagram allowed the creation of the following example scenarios with collaboration and sequence diagrams to illustrate the interactions between the classes.
Use Case Name: Create Constraints #8
Scenario: EU will add a new constraint to the CDB.
Preconditions:
- EU has successfully gained access to the DDS.
- DDS is ready to go (Databases have been populated and DDS has been initialized/web accessible)
Main Flow of events:
- EU wishes to add a new constraint to the CDB; he selects "Constraint Editor" on "Activities" page.
- EU clicks "Add" button on "Constraint Editor" page.
- EU inserts new rules of constraint and click "Submit" button on "Edit Constraint" page to add a new constraint to CDB.
Postconditions:
- After EU has added constraint successfully into CDB, he can click "View" button to view the new constraint on "Constraint Editor" page.
Use Case Name: Create Patient Record #1
Scenario: HP will like to create a new patient record in PID.
Preconditions:
- HP has successfully gained access to the DDS.
- DDS is ready to go (Databases have been populated and DDS has been initialized/web accessible)
Main flow of events:
- HP wishes to create a new patient record in PID, he selects "Patient
Record Editor" on "Activities" page.
- HP presses "Create" button on "Patient Records Editor" page.
- DDS will lead HP to "Edit Patient Record" page for HP to insert all necessary patient information and press "Submit" button to add a new patient record to PID.
Postconditions:
- After HP successfully created a new patient record in PID, he can choose to view created patient record by clicking "View" button on "Patient Record Editor" page.
Finally the database design was completed and the table structure has been defined as follows:
User Table
| User ID | Name | Address |
Permission Table
| Permission ID | Description |
User Table
| User ID | Permission ID |
Constraints Master
| Constraint ID | Description |
Patient Master
| Patient ID | Blood Type | Sex | Race | ... |
Patient Constraints
| Patient ID | Constraint ID | Value |
Diagnosis
| Patient ID | Time Stamp | Calcuation | Recommendation |
Implementation
The implementation of the system has been divided into manageable threads and ranked by important so that if there is a time shortage the most important sections of the system are implemented first. These implementation threads are shown in the diagram below:
Each of the threads in the diagram is scheduled in the implementation time line chart Click to view the diagram along with scheduled milestones to keep the implementation on track.
Testing
For unit testing, we have planned the glass box testing strategy, with 100% branch coverage, on the method retrievePatient(int) (Requirement #3) from the Patient class. We also planned the Black box testing strategy on the method ValidatUser(string userid, string password): bool (Requirement #11) from the GUI class.
In order to achieve 100% branch coverage for the glass box testing of the method retrievePatient(int) we plan to try 4 tests. The tests will have the following inputs:
- An erroneous or NULL patient id
- Patient id that is not in the database
- Patient id, when all of the patient's fields are empty
- Patient id when one or more of the patient's fields are not empty
The plan for black box testing of the method ValidatUser(string userid, string password): bool, tests all of the equivalence classes of userid and password. We propose 10 tests. The tests will have the following inputs:
- none
- only a password
- only a userid
- userid (userid is not in the database) and a password
- userid and a password (password is not in the database)
- userid and a password (neither userid nor password are in the database)
- userid and a password (where the password does not match with the userid)
- userid (userid is of the wrong type) and a password
- userid and a password (password is of the wrong type)
- userid and a password (both userid and password are of the wrong type)