/
General Feedback Mechanism (Implementation Ideas)

General Feedback Mechanism (Implementation Ideas)

Jun 08, 2011

Primary mentor

@Ben Wolfe

Backup mentor

@Burke Mamlin

Assigned to

@Gaurav Paliwal

 

Introduction

Basic Description about this module is available here .

Workflow

Flow Chart for Feedback Submission
Administrator FLOW Chart for Feedback Module
Use Case OpenMRS Feedback Module

Database Schema

Tables

Relations that will be required for the General Feedback Mechanism

  1. feedback_feedback

  2. user_properties

  3. feedback_severity

  4. feedback_status

  5. feedback_predefined_subject

In order to give clear distinction between the module tables and the other tables, the tables created while installing will have prefix “feedback” , this will help to prevent the name collision with other modules.

feedback_feedback

Attribute Name

Intention

Properties

feedback_id

This will be the unique ID number to identify each and every feedback.

  1. Int(11) --Quite Large to hold about 9^11 feedback.

  2. Primary Key

  3. Index (preferably BTREE based implementation)

creator

This will be the user id of the user, that has submitted the feedback.

  1. This is the foreign key that references the user_id attribute of the openmrs.users relation that is already existing in the table.

  2. This key is basically used for users mapping

  3. This key is can't be null ( NOT NULL Attribute )

  4. Size int(11) , same as that of user_id in users attribute.

subject

This is the subject of the feedback that the user is submitting.
( predefined as well as customed allowed )

  1. size varchar(255)

  2. This can't be NULL (NOT NULL attribute)

content

This is the content of the feedback that the user has submitted.

  1. size varchar(5000)

  2. Only simple plain text is allowed.

  3. This can't be NULL (NOT NULL attribute)

severity

This is used to tell the severity of the feedback.
(pre defined level)

  1. Size varchar(25)

  2. This attribute can't be NULL

comment

This field is used to store the administrator action over the feedback

  1. Size varchar(5000)

  2. This attribute can be NULL

status

This is used to store the current status of the feedback.
(pre defined level)

  1. Size varchar(25)

  2. This attribute can be NULL

date_created

This is the used to store the time at which the user has made submitted the feedback

  1. This will generated by the database trigger. This will be generated before the insert operation of the every new feedback.

  2. Type : Date

date_changed

This is the used to store the time at which the administrator has made the comment on feedback.

  1. This will be generated by the database trigger. This will be generated before the update operation of the comment.

  2. Type : Date

user_property

Following property will exist for all system users specific to the feedback mechanism module :

creator
email_id
phone_number
receipt_preference
followup_preference

feedback_severity

Attribute Name

Intention

Properties

index

To store the index of the severity table

AUTO_INCREMENT , NOT NULL

severity

This stores the predefined severity level by the administrator. I have intentionally not declaring it as a foreign key to the relation feedback(severity).
It can be on a scale of 1,2,3... or something like urgent , extremely severe,@ urgent etc.
So, that the user can pick the severity level from the drop-down while submitting the feedback.

Varchar(50)
Not a Primary Key, as there is no need to have index built over this attribute, resulting in decrease in system performance.