Online Health Monitoring System

Detailed Design:  Doctor Manager

COP 4331, Fall, 2014

 

Modification history:

Version

Date

Who

Comment

v0.0

08/15/00

G. H. Walton

Template

v1.0

10/03/14

C. N. McCue

First revision

...

 

 

 

 

 Team Name: Team 14

Team Members:

 

Contents of this Document

Design Issues

Detailed Design Information

Trace of Requirements to Design

Design Issues: 

Relevant design issues to this module include safety, testability, ease-of-use, portability, performance and maintainability.  Since this is a health-related product, failure could result in harm or death to the user.  Particularly, for this module, pill schedules can become a life and death issue.  Buttons and selections in the user interface must be very clear so that users will not be confused on what they are selecting.  Therefore, it is important that this is tested well.  Key to this module is the Doctor Manager to Database Manager interface.  The appropriate data must be stored in the database properly.  This will be a key area in the Test Plan.  Somewhere, a disclaimer must be posted. 

 

Currently, we are placing the pill scheduling and appointment management in one place.  An alternative is to separate these into two tabs on the Session Manager.  This may make the user interface easier to use.  This alternative will be weighed during the prototyping stage.

 

Since this is an online application it must be portable.  HTML and JavaScript will ensure this is not a problem.  From a user perspective, a user should be able to understand how to use this module in less than 5 minutes.  The user interface visualization demonstrates that the user controls are configured in a standard format that users would already be familiar with.

 

Since this module interfaces with the database, it is important that storage and retrieval of information occurs within 3 seconds.  Otherwise, users will become frustrated with the poor performance.  The pill and appointment data sent and retrieved from the database must be perpetually maintained.               

From the detailed design of this module a prototype will be coded which stands alone.  There will be no interface with the Session Manager.  There will be no interface with the Database Manager.  Instead data files will be used to simulate data storage and retrieval. 

 

After the prototype is developed for this module, it will then be integrated with the Database Manager and Session Manager.  This is where the majority of the risk lies.  I am depending on James’ module to provide a template to follow for database storage and retrieval.  I will need to work with James to determine the optimal data format for storage and retrieval.  It is anticipated that the integration stage will consist of close teamwork.     

 

Detailed Design Information:

Doctor Manager Overview:

 

 

The design of the Doctor Manager module is driven by functional requirements.  Per the requirements, the doctor will manage pill schedules and patient appointments. 

 

 

Data:

 

Pill schedules can be broken down as follows:

 

Date Related Attributes

Start:  for example, December 3, 2014

Duration:  for example, 7 days

Frequency:  for example, daily or every other day

 

Time Related Attributes

Start:  for example, 7:30 a.m.

Frequency:  for example, 3 times/day                                OR                          Interval:  every 6 hours

End:  for example, 10:00 p.m.

 

Pills Related Attributes 

Pill name:  Aspirin

Number to take:  3 pills at a time

Pills left:  15 pills

 

Hence, the pill data attributes are as follows:

Data:  Categories of Pill Schedule Attributes

Date Related

Time Related

Pill Related

dateStart

timeStart

pillName

dateDuration

timeFrequency

numberPillsToTake

dateFrequency

timeEnd

pillsLeft

 

timeInterval

 

 

In a similar fashion, a table is created for appointment data:

Data:  Appointment Schedule Attributes

appointmentDate

appointmentTime

recurringFrequency

endRecurrence

 

 

Data Storage Format:

 

For the example data described above, the data storage format will be as follows:

 

Aspirin           3     15

2014:12:3         7     1

7:30              3     22:00

 

The top row contains pill related data.  The second row contains date related data.  The last row contains time related data.  This is the data storage format for updating and refreshing the Doctor Manager display.  Data which will be displayed in the calendar or data for pill alerts will be stored in a different format.  The database manager should not need to calculate this data.  The doctor manager module will calculate the data and the database will store the data.

 

 

User Interface Visualization:

 

At this point, it is helpful to visualize the functionality-driven user interface.

 

 

Operations:

 

See “Doctor Manager Overview” section for operations and descriptions.

 

Two operations worth noting are calculatePillSchedule() and calculateApptSchedule().  The pill schedule corresponds with SMS pill alerts.  The database must store times of events instead of calculating these events.  Therefore, the doctor manager must calculate an array of events to send to the database. 

 

Using our aspirin example, the events generated are listed below:

 

Aspirin           3           15

2014:12:3         7:30

2014:12:3         15:00

2014:12:3         22:00

2014:12:4         7:30

2014:12:4         15:00

2014:12:4         22:00

2014:12:5         7:30

2014:12:5         15:00

2014:12:5         22:00

2014:12:6         7:30

2014:12:6         15:00

2014:12:6         22:00

2014:12:7         7:30

2014:12:7         15:00

2014:12:7         22:00

2014:12:8         7:30

2014:12:8         15:00

2014:12:8         22:00

2014:12:9         7:30

2014:12:9         15:00

2014:12:9         22:00

 

Similar events would be generated for appointment scheduling.

 

Calculation Algorithm:

 

for(dateStart; dateStart + dateDuration; dateFrequency++)

                for(timeStart; timeEnd; (timeEnd-timeStart)/(timeFrequency - 1))

                                sendEventDateTime();

 

 

Interfaces:

 

Interface A:  Session Manager- The main interface which uses tabs to determine what is displayed in the main window.

Interface B:  Database Manager- The database manager manages the storage and retrieval of data.  This follows the client-server format.  To see how these interfaces interact with the Doctor Manager see “Event Sequence Diagrams” below.

 

Event Sequence Diagrams:

 

The functionality of the Doctor Manager is driven by events, such as a button click.  Because of this, event sequence diagrams are helpful to understand user interaction.  First, there is interaction between the Session Manager and the Doctor Manager.  This opens and closes the Doctor Manager interface.

 

The doctor can submit a pill schedule.

 

The doctor can also set a patient’s appointment.

 

 

Class Diagram:

Trace of Requirements to Design:

Item Description

Detailed Design Section

Document of Origin

Sections of Origin

Overall functionality as pills/appointments manager

Overview

Concept of Operations

Users and Modes of Operation, Operational Features 

Assign patient medicine

Event Sequence Diagrams

Software Requirements Specification

Event Table, Use Case Descriptions

Assign appointments

Event Sequence Diagrams

Software Requirements Specification

Event Table

Pill/appointment management functionality

Overview, Data

Software Requirements Specification

3.1

Pill data specifications

Data, Operations

Software Requirements Specification

3.2

Appointment data specifications

Data, Operations

Software Requirements Specification

3.2

Example data and Data format

Data, Operations

Software Requirements Specification

3.6

Quality attributes

Design Issues

Software Requirements Specification

3.9

 

Template created by G. Walton (GWalton@mail.ucf.edu) on October 8, 1999 and last modified on August 15, 2000

This page last modified by Christopher McCue (christopher.mccue@knights.ucf.edu) on October 3, 2014