Strabismus Checking System

1
Strabismus Checking System
Application Requirements Document

• The Team
• Lior Barak
• Omri Mosseri

2
Introduction And Vision
3
Introduction

• What is Strabismus?
• Causes
• types
• Danger of no treatment
• depth precision problems
• vision problems
• Lazy eye

4
Introduction Cont.

• Importance of early diagnosis
• Vision development completes around the age of 9
  month
• Correcting the problem
• Preventing evolvement of other vision related
  problems (lazy eye).
• Improving appearance

5
Introduction cont.

• Treatment methods
• Glasses
• Patching
• Using Drugs
• Eye Exercises
• Botox
• Surgery

6
Problem Domain

• Today, strabismus checking is done manually by
  doctors and nurses.
• Diagnosis today
• False positive
• cover test
• Hirschberg test
• Deviation test (prism)

7
Problem Domain

• Takes time, effort and is hard on both the
  patient and the examiner
• Very heavy load on eye clinics

8
Problem Domain Current solution

• Problems with the current diagnosis methods
• Requires Cooperation
• Checking takes time
• Inconvenient for patients (especially babies)

9
Vision

• A unique automated strabismus checking unit,
  integrated with a full eye clinic management
  system
• Handling patients data
• Scheduling appointments
• Analyzing images and video segments of patients
  eyes
• Returning results including the deviation angle
  of the eyes

10
Vision Proposed solution

• Innovation of our new system
• Quick check
• Doesnt require patients cooperation
• Non invasive technique
• Can be preformed easily on babies
• Efficient management of the clinic

11
Stakeholders

• Customers
• Hospitals
• Eye Clinics
• Schools

• Users
• Doctors
• Nurses
• Secretaries

12
Architecture
Video Processing Unit
Database
Patient Managing Unit
13
Functional Requirements

• GUI
• User management
• Adding a user
• Handling permissions
• Login
• Logout
• Restricting functionality to authorized users

14
Functional Requirements cont.

• Examination of patients
• Returning deviation angle from a video segment
• Adding results to a patient

15
Functional requirement cont.

• Patients Management
• Adding a patient
• Updating details
• Viewing patient medical history
• Results from each examination
• Treatment history
• Progress graph
• Scheduling appointments

16
Functional requirement cont.

• Database
• Handling database actions
• saving backups for patients data (automatic and
  manual)

17
Non-Functional Requirements

• Performance Constraints
• Speed and capacity
• Processing a video will take no longer than 2
  minutes
• The system will be able to save at least 2000
  patient records
• Safety and security
• Login will be required
• Each user will have its own authorized
  functionality

18
Non-Functional Requirements cont.

• Usability
• The video files must be taken in a predefined
  manner and format
• Easy to learn not more than a day to learn how
  to use the system
• Understandable results to the doctors
• Availability
• Available at all times

19
Non-Functional Requirements cont.

• Platform Constraints
• C for the video processing unit
• Java for the rest of the system
• Using MySQL database
• The system will run under Linux OS

20
Use Case Diagram
21
Main Use Cases

• Analyze new examination
• Enter examination video
• Analyze video
• Returning results
• View patient history
• Pervious exam results
• Progress graph
• Previous treatments

22
Main Use Cases (Cont.)

• Add a new treatment for a patient
• Add new examination
• View patient history
• Add treatment session
• Schedule an appointment
• Find free time slot
• Occupy free time slot with patient

23
Difficulties

• Writing the algorithm dealing with image and
  video processing
• Dealing with databases
• Integrating modules from c and java

24
Risks

• Supplied video segments and images wont be good
  enough to give accurate results