View this PageEdit this Page (locked)Attachments to this PageHistory of this PageHomeRecent ChangesSearch the SwikiHelp Guide
Hotspots: Admin Pages | Turn-in Site |
Current Links: Cases Final Project Summer 2007

Team MedicStar

header.jpg

Team Members:

Tyler Hastings
Jabari Worthy
Chris Sumsky
Jesse Swidler

Project Description:

For our group project we were asked to design a hospital management system using Smalltalk. First we had to develop domain classes which we then hooked up to a GUI. After that we were then asked to implement parts of the project with a webpage.

General:

Our project this semester is to write a basic patient management system for a hospital. Automating health care is a big topic right now, both politically and practically. You will have a chance to build a small system to explore some of the issues involved.

Hospital:

  The hospital needs to maintain the following information:
      o The doctors who practice at that hospital
      o The patients who have been treated at that hospital
      o The rooms that patients can stay in.

Doctor:

  The doctor needs to maintain the following information:
      o Their name
      o A unique id
      o Their specialty (general practice, surgery, internal medicine, etc)

Patient:

  The patient needs to maintain the following information:
      o Their name
      o A Unique id
      o Their primary care doctor
      o A medical history
      o Their current status (inpatient (in the hospital), outpatient (active treatment, but not admitted), inactive (not being treated right now) )

Medical History:

  Each time a patient receives any kind of treatment, there is a record made. The history is a collection of these records. Each record consists of:
      o The date and time of the treatment
      o The patient status at time of treatment (in or out patient)
      o The ordering doctor
      o If inpatient, the room the patient was in.
      o The diagnosis that requires this treatment
      o The actual treatment (drug, therapy, x-ray, lab work, etc).
      o Billing information (cost) for this treatment

Security:

      o There are 3 types of users: Administrator, Doctor, Normal
      o The type of user is dermined by logging into the system with a user id and password. After 3 incorrect logins, that account should be locked  until an administrator unlocks it.
      o An administrator can create new users in the system and assign their types. They also assign them their userid and passwords. They can create rooms, patients and doctors and enter them into the hospital. They can unlock accounts that have been locked due to incorrect login attempts.
      o A doctor can do anything a normal user can plus create a treatment record for a patient and enter it into their history.
      o A normal user can browse the system and get reports.

Reports:

      o Hospital occupancy report - A summary of all rooms, which rooms are vacant and which have patients. For occupied rooms, should also state patient who is in there.
      o Morbidity report - A summary of all current inpatients, and what their diagnosis is. For example, 15 Swine Flu, 3 broken limbs and 1 concussion. This report should provide a pie chart to summarize totals
      o Disease History - For patients affiliated with the hospital, list all those who have a particular diagnosis as provided by the user.
      o Doctor Daily rounds - For a given doctor, list all patients who are inpatients and their room numbers.

GUI Requirements:

      o Login and security screens.
      o Data input screens as required to fulfill functionality.
      o Report screens as required to fulfill functionality.

Possible Extra Credit Opportunities:

      o Use a database for maintaining patient information.
      o Allow multiple users to connect to your application.
      o Allow the system to operate multiple hospitals instead of just 1.
      o Maintain security logs to record who changed what in the system.
      o Additional reports.
      o Remember you may propose your own extra credit. Points will be assigned based on difficulty.
      o Undo/Redo support undoing the last command, or redoing the last command that was undone. supporting multiple undo/redo is additional extra credit. (HINT: Command pattern is useful for this).
      o Design Patterns: Extra credit is given for each unique design pattern (like singleton, observer, command) that is used in the design.
      o More graphics: Include additional graphics (either static or interactive) that provides an enhanced user experience.

Milestones:

      o 6 Group Project Milestones>Fall 2009 Project Milestones (44)
      o ~M3 Domain Design -10% 
      o ~M5 Application/Gui Design - 10% 
      o ~M6 Domain Implementation - 6% 
      o ~M7 Gui Implementation - 6% 
      o ~M8 UI Evaluation - 7% 
      o ~M9 The Twist!!! - 5%

Team Suggestions:

Since this is a group project it is very crucial who you have as your teammates. I would suggest that you try and diversify your group. Get at least one person who will be able to design the GUI for your project because as we all know most CS majors are unable to do this well. Get a couple of people who are able to code well and know how to debug code. It is often times hard to debug in Smalltalk so knowing how to debug on your own will help. Lastly, I would suggest to get a person who knows how to create and setup a database. This will be very useful when your group is trying to get extra credit during the semester.
Another key thing with a group is how well you can work together. It would be great if you all were amazing coders, however if there is no structure to the group and you are unable to mesh correctly then the group will end up failing in the long run.

Link to this Page