1. Injury Tracking System Project Definition

2. Team Members: Robbie Marsh Robbie Marsh –Project Manager/Webmaster Ken Metcalf Ken Metcalf –Lead Programmer Julie Ostrander Julie Ostrander –Systems Analyst Tamae Buechler Tamae Buechler –Systems Architect

3. Client Information: Dan Stephens, ATC/L Dan Stephens, ATC/L –Assistant Director of Athletics –Coordinator for Sports Medicine –Intercollegiate Athletics

4. Purpose: Create a more efficient method of tracking student athlete’s information Create a more efficient method of tracking student athlete’s information Consolidating the two current databases into one relational database Consolidating the two current databases into one relational database Create a PDA application that will streamline data entry into the system Create a PDA application that will streamline data entry into the system Create a user friendly interface Create a user friendly interface

5. Project Scope: Primary goal: Primary goal: –To develop a system that will keep track of all of the athletes’ injuries at SIUE. Other goals: Other goals: –To convert the old system into a new fully functional database system. –To implement a side application that will run on a Palm OS.

6. Current System: Two separate databases Two separate databases –Injury database Stores athletes’ injury information. Stores athletes’ injury information. –Physical database Stores athletes’ physical information. Stores athletes’ physical information. Insurance Claims folder Insurance Claims folder –Stores information about each insurance claim into separate files.

7. Current System: (Cont.) Databases Databases –Written in Symantec Q & A. –The two databases are not currently connected. –The databases are copied from one PC to another.

8. Current System: (Cont.) Initial Forms Initial Forms –Physical –History –Flex Assessment –Proof of Insurance Injury Forms Injury Forms –There are eight unique injury forms for each frequently occurring injury

10. Current System: (Cont.) Archived Information Archived Information –Annually, the client archives each database by saving it to disk. –A hard copy of the athletes’ records is required to be stored for forty-two years.

11. Current System: (Cont.) Sequence Models Sequence Models – Creating the new databases – Completing an Insurance Claim – Tracking an injury Work Flow Model Work Flow Model

12. Intent: To create new databases for the current school year. Creating the new Databases Trigger: New school year begins. A copy of each database from the previous year is made and saved to the desktop Menu options are then selected to clear fields of their data. Each copy is then renamed to match the current school year. Certain selected fields are cleared for every record in the Physical Database using the “Selective Delete” option. Inadvertent fields may be cleared by accident Original and copied database could get mixed up Intent: To clear these databases to begin data-entry for the new school year. All fields for every record are cleared in the Injury Database using the “Mass Delete” option. Certain selected fields are cleared for every record in the Physical Database using the “Selective Delete” option.

13. Intent: To complete all necessary forms for an insurance claim. Insurance Claims Trigger: Athlete suffers an injury severe enough to see a doctor Four Insurance forms must be completed. Some Information from this form is then exported to the 3 other forms. The first formed filled out is the SIUE Sports Medicine Injury Report. The remaining forms are then completed. Possible loss of forms Error while exporting data

14. Intent: To keep track of an injury Tracking an Injury Trigger: Athlete injures themselves. Athlete is evaluated by trainer. The user enters injury information from the forms into the injury database. The proper injury forms are completed. Trainer is not always present Forms lack certain fields for a complete evaluation A progress report is completed in paper form for the athlete’s therapy. If hard copy is lost, then progress report is lost as well

16. Proposed System: Overview Overview –Combine two databases into one relational database –Allow for a PDA application to interact with the database –Allow the user to more easily track and query athletes’ information –Have a more user-friendly interface

17. Proposed System: (Cont.) Functional Requirements Functional Requirements –The system must contain all of the information from the currently used forms. –The system should contain information about the time of injury, and environmental conditions.

18. Proposed System: (Cont.) Functional Requirements (Cont.) Functional Requirements (Cont.) –The system must provide a method to archive each injury after 30 days from the date of entry. –The system must provide a method of making reports based on athlete, sport, and injury.

19. Proposed System: (Cont.) Non-functional Requirements Non-functional Requirements –The system should have a user-friendly system. –The current forms group related information into sections. The new system must maintain the same sections.

20. Proposed System: (Cont.) Software Considerations Software Considerations –Microsoft VB 6.0 VS. Microsoft.NET Pros and Cons Pros and Cons PDA application tool PDA application tool –Pendragon Forms –Handspring 3.0.1 H Palm

21. Proposed System: (Cont.) Database Migration Considerations Database Migration Considerations –Export from Symantec Q & A to dBase format then to Microsoft Access –The schema of the current system has not yet been examined, so the extent of the differences cannot be determined.

22. Proposed System: (Cont.) Security Issues Security Issues –The system will have two levels of security. Administrator (Dan Stephens) Administrator (Dan Stephens) Grad/Undergrad students Grad/Undergrad students The system will block access after a set time of inactivity until password is re-entered. The system will block access after a set time of inactivity until password is re-entered.

23. System Models: Modular Overview Modular Overview –Main application –PDA application

25. Questions?