Online
Health Monitoring System
High Level Design
COP 4331, Fall, 2014
Modification history:
|
Version |
Date |
Who |
Comment |
|
v0.0 |
|
G. H. Walton |
Template |
|
v1.0 |
|
C. N. McCue |
First Draft |
Team Name: Team 14
Team Members:
- Jon Carelli - email - page
- Chris McCue - email - page
- Chris Chaffin - email - page
- Ethan Pitts - email - page
- David Gundler - email - page
- James Luke - email - page
Contents
of this Document
- Diagrams of Major Components and Interfaces
For High-Level design, the team organized the operational
features from the Concept of Operations in logical order. Functionality was divided between two
users: doctors and patients. Functionality was furthered divided into
modules, such as chat and pill/appointment manager. At this point, we essentially have the front
end modules.
We then sketched a diagram of the user interfaces and the
flow from one to another. Button, list
boxes and other controls were discussed and added to these blocks. However, in the detailed design phase, more
thought will be given to these controls.
Below is a visualization of a user interface screen with the Navigator
tabs:
Visualization of User Interface
(Doctor View)
In the sketch, it was determined that Settings, Login and
New Account management would also be needed.
At this point, we have a diagram of the front end.
Diagram of Front End User Interface
Flow
Additionally, back end modules need to be considered. The Database and Database Manager are central
to this system. Also, there must be an
SMS Alert module in the back end.
Diagram with Back End Modules
In the end, it was determined that Login is intimately tied
with the Database and Settings.
Therefore, the Database, Database Manager, Login and Settings are
considered one module. This is the
central module of the whole system.
Hence, there are six modules.
These are described in detail in the next section.
- Description of modules and interfaces
1.
Database/Database
Manager/Login/Settings (James)
Accessibility: Neither doctors nor patients use this back
end module directly.
Functionality:
·
Login: Creates login session. User logs in with id and password.
·
Settings: Users can change settings of this system.
·
Database
Manager: Stores and retrieves
information from the database.
·
Database: This is the central storage for all modules.
Interface
with:
·
Database
interfaces with every module except Video Chat
·
Other
team members will use James’ work as a “template”.
2.
Navigator (Ethan)
Accessibility: This is the main interface for both doctors
and patients alike.
Functionality:
·
This
will be the “template” into which are modules fit. The Navigator is the style of the user
interface more than a module.
Interfaces
with:
·
The
Navigator interfaces with the Chat Manager, Pill/Appointment Manager, Calendar
and, possibly, the Video Chat.
Integration is as simple as calling up a HTML page.
·
The
Navigator also interfaces with the Login screen. The login screen will call the Navigator
page.
3.
Chat Manager (Jon)
Accessibility: Both doctor and patient use
Functionality:
·
Patients
must be able to read, delete, reply, etc. to one doctor
·
Doctors
must be able to read, delete, reply, etc. to multiple patients
Interfaces
with:
·
Database
Manager- Receive messages from database.
Send messages to database.
·
Navigator, or Session Manager- Chat Manager integrates
with Navigator.
·
See
next page for diagram.
Development
Stages:
·
During
prototyping stage, get chat information from data file. Emphasis on functionality, not design. No need to follow Ethan’s design scheme.
·
During
integration stage, get information from database. Use Ethan’s design scheme.
4.
Calendar (Chris C.)
Accessibility: Only patient uses this
Functionality:
·
Calendar
will be filled in with pill times and medical appointments.
·
Navigate
forward and backwards to different months.
·
This
will be implemented with a plug in API calendar. Tentatively, http://arshaw.com/fullcalendar will
be implemented. An example of this
calendar is shown below:
Interfaces
with:
·
Database
Manager- Read database information and place on calendar. No need to write to database.
·
Navigator, or Session Manager- Navigator will place
Calendar in blank area of Navigator.
Development
Stages:
·
During
prototype stage, get information from a data file to fill in calendar
·
During
integration state, will need to get data from database and place in Ethan’s
design
5.
Pill/Appointment Manager (Chris M.)
Accessibility: Only doctor uses this.
Functionality:
·
Use
list boxes, buttons and other controls to create pill schedules.
·
Use
list boxes, buttons and other controls to create appointments.
Interfaces
with:
·
Database
Manager- Database information is read in to fill in previous appointments and
pill schedules. New appointments and
pills schedules are stored in the database.
·
Navigator, or Session Manager- This module is
integrated into the Navigator tab scheme.
·
See
diagram on next page.
Development
Stages:
·
During
prototype stage, get information to fill in forms from data file and store
information in that same data file
·
During
integration stage, get information from and send information to database. Also, integrate with Ethan’s design.
6.
Alert Manager (David)
Accessibility: Neither doctors nor patients interact with
this. Text alerts are automatically sent
to patient’s cell phone.
Functionality:
·
Send
automatic SMS texts to patients based on pill schedule.
·
Send
automatic SMS texts to patients based on appointments.
Interfaces
with:
·
Database
Manager- Queries database and auto generates alerts accordingly.
·
SMS
devices- Sends SMS texts to devices, such as cell phones.
Development
Stages:
·
During
prototype stage, the main focus should be on using a computer to send a text to
a cell phone.
·
During
integration stage, constantly query database and send alerts based on these
queries.
7.
Video Chat (optional)
At this point, we will not be
implementing video chat.
Issues relative to
this project include safety, ease-of-use, performance and portability. Since this is a health-related product,
failure could result in harm or death to the user. Pill schedules can become a life and death
issue. Doctors could enter pill
schedules wrong or software could fail causing botched pill schedules. Appointments are a crucial issue. If one misses an appointment, it may be weeks
or months before one can reschedule.
Waiting is not an option when one is sick. It is important that there is no software
failure. Otherwise, the patient’s life
could be endangered.
Ease-of-use is
related to safety. If the system is easy
to use, doctors will be able to enter pill schedule and appointment data
correctly. We want to eliminate the
possibility of doctors entering bad pill schedules because of complicated
controls. In addition, ease-of-use is
important in itself. Many patients will
be elderly or vulnerable since they are sick.
Therefore, the Navigator must be as simple as possible. A user should be able to understand how to
use the Online Health Monitoring System in 10 minutes or less. Buttons and selections in the user interface
must be very clear so that users will not be confused on what they are
selecting. The user interface
visualization demonstrates that the user controls are configured in a standard
format that users would already be familiar with. Since this is an online application it must
be portable. Since this system deals
with many patients and patient data, it is important that it have high
performance. Storage and retrieval of
information should occur within 3 seconds.
Otherwise, users will become frustrated with the poor performance.
Future relevant
issues include reusability and maintainability.
Certainly, other features would be added to this as time goes on. Therefore, it would need to have reusability. The Navigator should allow for more tabs to
be added. The database should be capable
of handling more data. Maintainability
would also be crucial. The pill and
appointment data sent and retrieved from the database must be perpetually
maintained. This data is safety
critical. At some point, database
capabilities would need to be expanded.
Realistically, a health monitoring product has a great deal of liability
and risk. It would be difficult to use
this product in the real world. Doctors
would not want to waste their time on a new product. Therefore, the issues of reusability and
maintainability are not realistic.
Due to time
constraints, it is not feasible to consider alternative design strategies. Our prototyping is solely for the purpose of
stepping towards integration. Since we
are using an incremental phased development approach, we plan to make
prototypes of each of the modules. Then
we will integrate these modules one by one.
The Calendar, Pill/Appointment Manager and Chat Manager will be
integrated with the Database Manager.
These will then be integrated with the Navigator. In the meantime, the Navigator will be
integrated with Login. Finally, the SMS
Alert Manager will be integrated with the Database Manager.
We expect most of
our technical difficulties to come from integration with the Database
Manager. Most of the team is
inexperienced with databases. However,
James does have database experience. He
will help us integrate our modules with the database. He is planning on making wrappers to make
integration easier for other team members.
Still, this does pose a challenge.
Other technical difficulties are team inexperience with JavaScript, SMS
messaging and video chat. Our solution
to all the difficulties was to start research early. We started learning JavaScript early in the
project. David started researching SMS
messaging early in the project as well.
Although James did some video chat research early in the project, this
is optional. Due to time constraints, it
is unlikely that we will implement this option.
Our architecture style is a hybrid of client-server and repositories architectures. Since this is an online project, the client-server was an obvious choice of architecture. Due to this system storing and retrieving data from a database, the repositories architecture was also used. There were no design trade-offs in this selection of architecture. This project is straightforward. We are just using the established tools and techniques for this sort of problem. Again, the technical risks are team member inexperience with databases. However, James does have database experience. He is planning to help each team member with database integration. Communication from other team members and James will be crucial for the coding phase of this system.
Template
created by G. Walton (GWalton@mail.ucf.edu) on
This
page last modified by Christopher McCue (christopher.mccue@knights.ucf.edu) on