-
Notifications
You must be signed in to change notification settings - Fork 9
RIS Project Description
Term Project
Due Time: 18:00 April 3, 2015
Clarification
- None so far.
1. Introduction
In this project you are going to develop a web-based database application system, called Radiology Information System.
A Radiology Information System (RIS) is a computer information system that stores and processes the information for a radiology lab, including all the data regarding patients, and all medical images generated by various diagnostic and therapeutic equipments, such as X-ray, Computed Tomography (CT/CAT), Ultrasound (US), Magnetic resonance imaging (MRI). A Radiology Information System is optimally complemented with a Picture Archiving and Communication System (PACS).
In general, the digital images generated by radiology equipments shall be in the format of Digital Imaging and Communications in Medicine (DICOM). (DICOM is the industry standard for transferal of radiologic images and other medical information between computers.) For this project, however, a jpg format will be used instead.
The RIS will be used by the following classes (types) of users, and each is provided with specified functionalities.
- administrator,
- patient,
- doctor,
- radiologist
2. System Specification
The system must contain the information about its users and radiology records. For your convenience, the following tables have been specified using the given sql statements , and they shall not be altered. You may create supplementary tables and/or sequences, depending on your own implementation.
users(user_name,password,class,person_id,date_registered)
persons(person_id,first_name,last_name,address,email,phone)
family_doctor(doctor_id,patient_id)
radiology_record(record_id,patient_id,doctor_id,radiologist_id,test_type,prescribing_date,test_date,diagnosis, description)
pacs_images(record_id,image_id,thumbnail,regular_size,full_size)
users stores the name, password, class of, person_id,and time registered for each user;
persons stores all the personal information about each person;
family_doctor indicates who is whose family doctor;
radiology_record records relevant information for each radiology record, including the patient id, the id of the doctor who prescribes the test, the id of the radiologist who conducts the test, the diagnosis information, and the description of the test, and other relevant information;
pacs_images record all the DICOM images of various sizes.
Note that (1) a person may have several user accounts, depending on his/her log-in roles; and (2) a patient may have several family doctors, and of course, a doctor takes any number of patients.
The system must contain the following modules, each with the specified functionalities.
-
login module
This module will be used by all users to login to the system with proper privileges, and to modify their personal information and/or the password. (See a sample login module). -
user management module
This module allows a system administrator to manage (to enter or update) the user information, i.e., the information stored in tables
users,persons, family_doctor. -
report generating module
This module will be used by a system administrator to get the list of all patients with a specified diagnosis for a given time period. For each patient, the list must contain the name, address and phone number of the patient, and testing date of the first radiology record that contains the specified diagnosis. For example, a system administrator shall be able to use this tool to generate the list of all patients who have been diagnosed having breast cancer in 2014. -
uploading module
This module will be used by radiologists to first enter a radiology record, and then to upload medical images into the radiology record. In reality, all radiology images are atomically uploaded from various radiology diagnostic equipments to the database. In this project, however, you are asked to implement this module to upload an image stored in the user's local file system to the database. A sample uploading program can be found at Samples with source code. -
search module
This module will be used by all the registered users to search the database for a list of relevant radiology records and to view medical images with the zoom-in facility.
The search condition includes
- a list of key words, and/or
- a time periods
The search module, upon receiving the above condition, will display a list of all radiology records that
- satisfy the search condition, and
- are accessible to the user by the security module.
Each record displayed shall contain all the information, including the list of thumbnails of medical images, of the record.
By the zoom-in facility we mean to view an image in various resolutions. For simplicity, this can be implemented by modifying the displaying size of the image or by retrieving different size of the same image.) (see an example and the sample code.)
The viewer shall first display all the relevant radiology records according to the search specification, together with the thumbnails of the medical images. It will then display the specified medical image in a separate browser upon an explicit request from its user.
The security module of your system shall guarantee proper accesses to radiology records. That is, a patient can only view his/her own records; a doctor can only view records of their patients; a radiologist can only review records conducted by oneself; and an administrator can view any records.
The radiology records must be ranked according to the following schema:- If the client indicates that the ranking shall be based on timing, i.e., most-recent-first or most-recent-last, then the ranking shall be done accordingly.
- Otherwise, the ranking shall be based on the value of the following function with the largest first.
Rank(record_id) = 6*frequency(patient_name) + 3*frequency(diagnosis) + frequency(description)
where the term frequency(column_name) represents the value returned by the SCORE function of the corresponding CONTAINS function. Note that the value returned by SCORE(n) is propositional to, but not exactly, the number of occurrences of the key word(s) in the respective column.
See another sample program for the search and its source code.) -
data analysis module
This module will be used by the system administrator (i.e., a user named "admin") to generate and display an OLAP report for data analysis. A user of this module may choose to display the number of images for each patient , test type, and/or period of time. For example, a user may choose to display the number of images for each patient; or display the number of images for each test type for each month.
- One must generate a data cube information of the number of records for all the combinations of three columns, i.e., patient_name, test_type, and time(according to the values of column test_date).
- The user must be able to perform generalization (roll up) and specialization (drill down) on three levels of time hierarchies, i.e., weekly, monthly, and yearly.
- To speed up the OLAP operations, one might materialize the data cube information by creating a fact table/view storing all information needed, including the lowest level of time hierarchy.
3. Requirements
- This is a group project, with two or three students in each group, and of course, all students in a group will receive the same mark for the project. Send an email to Talat Syed ([email protected]) with the list of students in your group, together with your choice of the project (Radiology Information System) before February 10.
- Your system must be a three tier system: the database server, the web server, and clients are running on different computer systems that are connected via the Internet. There are many different approaches to interfacing a web site to a database server, such as Java Servlets/JSP and PHP, and you may choose any of these. You may use Oracle in our lab as the database server, and the Java Tomcat in your C391 account as the web server. The client, however, must be able to access your system using a web browser in any computer system through the Internet (with some restrictions due to recent security concerns). We will provide support for Java Servlets/JSP, JDBC, and PHP in the lab, and it is your responsibility to make sure your system will work properly during the demo if you choose any other approaches.
- You are required to submit
- Project Report
The report must describe the system architecture: all the major modules (classes/methods) used in the system, and relationships among them. For each module, the report must explain how the solutions were implemented, and list all the main SQL statements used. The explanation should be a concise, high level description such that your implementation can be easily understood by its readers. The report should be written in font size 12 and at most 8 pages. - Source Code
You are free to use the demo source code in the course web page, and you must explicitly acknowledge use and respect to the copyright of any source code that you did not develop yourself. - Follow all the proper programming guidelines learned in your previous courses and add proper comments to make your programs readable.
- A simple makefile that will compile all necessary files must be part of your source code.
- User Documentation
You must submit an electronic copy of the user documentation.
The user documentation must contain
- the installation guideline that tells the user how to install your system; and
- a user manual for each module.
- Each group will be asked to demo the system in our lab. The demo will last at most 30 minutes, and please make sure
the project compiles and runs correctly on the lab machine (CSC 2-19), and your web-pages display correctly using a browser available in the lab machines.You must make sure your system is ready before your scheduled demo.
- Project Report