Ecosyste.ms: Awesome
An open API service indexing awesome lists of open source software.
https://github.com/sukima/simnotify
A domain specific scheduling program for Medical Simulation Centers
https://github.com/sukima/simnotify
Last synced: 17 days ago
JSON representation
A domain specific scheduling program for Medical Simulation Centers
- Host: GitHub
- URL: https://github.com/sukima/simnotify
- Owner: sukima
- Created: 2010-07-01T02:51:53.000Z (over 14 years ago)
- Default Branch: master
- Last Pushed: 2011-11-11T16:05:25.000Z (about 13 years ago)
- Last Synced: 2024-10-21T20:58:15.310Z (30 days ago)
- Language: JavaScript
- Size: 6.21 MB
- Stars: 2
- Watchers: 2
- Forks: 0
- Open Issues: 0
-
Metadata Files:
- Readme: README.mkd
Awesome Lists containing this project
README
SimNotify
=========
Version: 1.4.4
Author: Devin Weaver
SimNotify is a simple web app designed to make it easy for instructors to
schedule a class (Event) and register equipment needs. Basically it is a
simple form that they can fill out and the system will store the information
and then send a notification to the administrator(s) who will accept, reject,
coordinate, and schedule.
Requirements
============
Phase 1
-------
1. An instructor can register and login
2. An instructor can submit an event
3. event submissions will send a notification (email?) to a designated
administrator.
4. Every event has one Instructor, Instructors can have many Events.
5. Events have many scenarios, Scenarios can be in many events.
6. A scenario has one manikin. A manikin can be in many scenarios.
7. An event can be a "live in" were the there is a manikin (which implies a
scenario) that stays in use for the duration.
Phase 2
-------
1. Instructors can see the calendar of Events.
2. Events can have a accept reject option.
3. Acceptance and rejects have email confirmations.
4. Entering data can be picked from prior templates and/or walk the instructor
through the process using a wizard style setup.
5. Application will determine if a manikin is available based on if it's in
service or not and if it is in use or not.
Data Model
==========
,--------------------.
| events_instructors |
|--------------------|
| event_id |--,
,---------------| instructor_id | | ,----------------------.
| `--------------------' `-->| event |
| ,---------------------. |----------------------|<<-.
`->>| instructor |<-----------+----| technition | |
,-->|---------------------| `----| instructor | |
| | name | | title | |
| | email | | benefit | |
| | office | ,----------. | notes | |
| | phone | | facility |<-. | location |.. |
| | admin? | |----------| | | start_time | . |
| | notify_recipient? | | name | | | end_time | . |
| | new_user? | `----------' | | live_in? | . |
| | facility |---------------'-| facility | . |
| | (acts_as_authentic) | ,--------| scenarios | . |
| `---------------------' | | submitted? | . |
| ,------------------. | | approved? | . |
| ..| scenario |<<---------' | followup_email_sent? | . |
| . |------------------| `----------------------' . |
| . | equipment |........ ............. |
| . | staff_support? | . . `-----.
| . | moulage? | . ,---------------------. . ,---------------. |
| . | notes | . | location_suggestion |.. | assets_events | |
| . | support_material | . |---------------------| |---------------| |
| . | description | . | location | | event_id |-'
| . | video? | . `---------------------' ,-| asset_id |
| . | mobile? | . ,-------------------. | `---------------'
| . | manikin_req_type |<----. ..| equipment_suggest | `----.
| . | manikin |<---.| |-------------------| |
| . | title | || | name | |
| . `------------------' || `-------------------' |
| . ,-------------------. || ,------------------. |
| ..| scenario_template | |+----| manikin_req_type | |
| |-------------------| || |------------------| |
| | title | || | type | |
| | equipment | || `------------------' |
| | staff_support? | || ,------------------. |
| | moulage? | `|----| manikin | |
| | notes | | |------------------| |
| | support_material | | | name | |
| | description | | | serial_number | |
| | video? | | | type | |
| | mobile? | | | oos? | |
| | manikin_req_type |<---'--->| manikin_req_type | |
| `-------------------' `------------------' |
| ,----------------------------. |
| | assets |<<--'
| |----------------------------|
| | session_asset_file_name |
| | session_asset_content_type |
| | session_asset_file_size |
| | session_asset_updated_at |
`---------------------------| instructor |
`----------------------------'
,---------.
| options |
|---------|
| name |
| value |
`---------'
Notes
=====
What we are looking at is a simple data entry form with a basic relational
data model. The interface is not the concern yet. Just the ability to enter
data. Data management is for later.
Building
========
The following setup procedures are required with a fresh build.
1. `bundle install` - Installs needed gems. (Requires the bundler gem:
`gem install bundler`)
2. `rake init:config` - Copyies over the sample config to the real config.
Provides defaults. _Please edit the files for your purpose_
3. `rake mailer:views` - Builds the views needed to send mail. You can
clean the genrated files with `rake mailer:clean`
4. `rake db:schema:load` - Loads the database.
5. `rake db:seed` - Load default values to the database.
Requirements Refactor
=====================
The requirements of this project have changed so drastically it is time to
refactor a lot of the old ideas into new ones. The following is that set of new
requirements.
A program is what instructors develop. They will consist of a creator, Assigned
contact, involved instructors, and Benefit to the system. A program has many
simulations.
Instructors (or administrators) will add SimSession (sessions and events were
taken keywords in old system) which are associated to a program. It has a
creator, assigned instructor, a carbon copy list of contacts, a facility and a
location. It has a start and end time. It has an assigned technician.
A SimSession will have multiple file attachments which should be a filled in
predefined word document specific to the department. This document will
describe a simulation.
After entering, if the creator is not an admin the SimSession is submitted to
the admins for approval first. Otherwise it is official on the calendar. Only
admins can make changes to the facility, location, start and end time after
that. Creators and admins can make changes to the attached documents anytime.
There are special events that have a creator, carbon copy contact list,
facility, location, start and end times. These are used for booking locations
when there is no program or simulation. (ie. A meeting, holiday, facility day,
etc.). Location is optional to handle cases like holidays.)
Whiteboard is at: http://bit.ly/qahhtz
Versions
========
Be sure to update the following files to the correct version number:
1. `README.md`
2. `public/humans.txt`
3. `config/initializers/load_config.rb`