Automated Prescription

Management System

Report on

“

Automated Prescription Management System”

Prepared For

Md. Humayun Kabir Biswas

Assistant Professor

Department of Computer Science and Engineering

College of Engineering and Technology (CEAT)

Prepared By

Group – Problem Solvers

Section - G

SN Name

Program

BCSE

0

1

2

3

4

5

Rihab Rahman

Md. Khalid Hosain

Tasnia Tahsin

Sirajum Munira

Kaisary Zaman

Automated Prescription Management System, The Problem Solvers Group

ii

Executive Summary

Medical Treatment is one of the five fundamental needs of human. For leading a happy and

pleasant life medical facilities are so important. From the very beginning of civilization there were

medicine and treatment. With passage of time sciences have been developed tremendously. On

every respect of our life we can find the contribution of science. The basic human need of medical

treatment is not out of this. Science has made a revolutionary change in this sector.

Previously peoples were died for lack of medicine and medical treatment but now-a-days this rate

has be reduced significantly. It happens because of technological advancement. As the era of

treatment has change along with more diseases have been appeared before us.

Though people are not been died like previously but they are suffering from various kinds of

diseases currently. Therefore, they have to visit doctor regularly and have to keep in touch with

medical treatment. The medical treatments come with the prescription that contains the disease

history of patient and therefore required medicines and tests accordingly.

To maintain the sequence of treatment, the patient always has to look for prescription and every

time they have to bring that to the doctor. Sometimes it happens that the prescription is lost or

damaged. At that time the patient falls in a great trouble as they did not have any other copy of

prescription to buy medicine or to show the doctor for further advice of treatment.

To solve this problem, we have designed and developed this system titled as “Automated

Prescription Management System”. By using the system doctors can keep the medical record of

patient electronically that can be preserved for future reference and can be printed out for buying

medicine and for some other purposes. Doctor can also see the medical history of patient by using

the system therefore the patient need not to bring his/her all medical reports always to the doctor.

This system also allows the patient to have a look over his/her prescriptions anytime as per their

need. This system is also integrated with online appointment system so that the patients can make

the appointment with the doctor before visiting. Patients can see which time slot is free for the

doctor and which one is booked already. So that they can make appointments accordingly.

The main goal of the project is to reduce the hassle of carrying prescription every time to doctor,

keeping prescription safe always, reduce the use of paper and ensuring online appointment of time

saving for both patient and doctor.

Automated Prescription Management System, The Problem Solvers Group

iii

Table of Contents

Executive Summary.......................................................................................................................iii

Table of Contents........................................................................................................................... iv

Table of Figures ............................................................................................................................. vi

List of Tables ................................................................................................................................. vi

Chapter 1: Project Introduction....................................................................................................... 1

1

.1 Introduction......................................................................................................................... 1

.2 Objectives ........................................................................................................................... 1

1

.2.1 Broad Objectives........................................................................................................ 1

.2.2 Specific Objectives .................................................................................................... 1

1

.3 Iterative Process Model....................................................................................................... 1

1

.3.1 The Feature of Iterative Process Model..................................................................... 2

.3.2 Advantages of Iterative Process Model ..................................................................... 2

Chapter 2: Requirement Engineering.............................................................................................. 3

2.1 Requirement Analysis......................................................................................................... 3

2

.1.1 User Requirements..................................................................................................... 3

.1.2 System Requirements................................................................................................. 3

.1.3 Functional Requirements ........................................................................................... 4

.1.4 Non-Functional Requirements................................................................................... 4

.1.5 Hardware Requirements............................................................................................. 4

.1.6 Software Requirements.............................................................................................. 4

2

Chapter 3: System Planning............................................................................................................ 6

.2 Use Case Diagram (UCD)................................................................................................... 5

3

.1 Scope of Project .................................................................................................................. 6

.2 Functions of Proposed System............................................................................................ 6

.3 Function Oriented Matrix ................................................................................................... 6

3

.3.1 Complexity Matrix..................................................................................................... 7

.3.2 Complexity Matrix for Unadjusted Function Point (UFP) ........................................ 7

.3.3 Identifying Complexity for Transaction Function Point Count................................. 8

.3.4 Unadjusted Function Point Contribution ................................................................. 12

.3.5 Performance and Environmental Impact ................................................................. 13

.3.6 Counting Function Point:......................................................................................... 13

Automated Prescription Management System, The Problem Solvers Group

iv

Chapter 4: Design Analysis .......................................................................................................... 14

4

.1 Entity Relationship Diagram (ERD)................................................................................. 14

.2 Data Flow Diagram (DFD) ............................................................................................... 15

4

.2.1 Context Level Diagram............................................................................................ 15

.2.2 Level 1 Diagram ...................................................................................................... 16

.2.3 Level 2 DFD of Process 1 (Login)........................................................................... 17

.2.4 Level 2 DFD of Process 2 (Admin)......................................................................... 17

.2.5 Level 2 DFD of Process 3 (Doctor) ......................................................................... 17

.2.6 Level 2 DFD of Process 4 (Patient) ......................................................................... 18

.2.7 Level 2 DFD of Process 5 (Appointment)............................................................... 18

.2.8 Level 2 DFD of Process 6 (Prescription)................................................................. 18

4

.3 Activity Diagram .............................................................................................................. 19

4

.3.1 Activity Diagram for Login, Managing Admin, Doctor and Patient....................... 19

.3.2 Activity Diagram for Appointment and Prescription............................................... 20

4

.4 Swim Lane Diagram ......................................................................................................... 21

.5 Class Diagram................................................................................................................... 22

.6 Database Tables Structure................................................................................................. 23

Chapter 5: Conclusion................................................................................................................... 25

5

.1 Limitation.......................................................................................................................... 25

.2 Conclusion ........................................................................................................................ 25

.3 Contribution Table............................................................................................................ 25

Chapter 6: Bibliography................................................................................................................ 26

.1 References......................................................................................................................... 26

6

Automated Prescription Management System, The Problem Solvers Group

v

Table of Figures

Figure-1.1: Diagram of Iterative process model............................................................................. 2

Figure-2.1: Use Case Diagram (UCD) of APMS ........................................................................... 5

Figure-4.1: Entity Relationship Diagram (ERD) of APMS.......................................................... 14

Figure-4.2: Context Level Diagram of APMS.............................................................................. 15

Figure-4.3: Level 1 DFD of APMS .............................................................................................. 16

Figure-4.4: Level 2 DFD of Process 1.......................................................................................... 17

Figure-4.5: Level 2 DFD of Process 2.......................................................................................... 17

Figure-4.6: Level 2 DFD of Process 3.......................................................................................... 17

Figure-4.7: Level 2 DFD of Process 4.......................................................................................... 18

Figure-4.8: Level 2 DFD of Process 5.......................................................................................... 18

Figure-4.9: Level 2 DFD of Process 6.......................................................................................... 18

Figure-4.10: Activity Diagram for Login, Managing Admin, Doctor and Patient....................... 19

Figure-4.11: Activity Diagram for Appointment and Prescription............................................... 20

Figure-4.12: Swim Lane Diagram for APMS............................................................................... 21

Figure-4.13: Class diagram for APMS ......................................................................................... 22

List of Tables

Table-3.1: Functions of this proposed system: ............................................................................... 6

Table-3.2 : Complexity Matrix for EI ............................................................................................ 7

Table-3.3: Complexity Matrix for EO/EQ...................................................................................... 7

Table-3.4: Complexity Matrix for ILF/ ELF .................................................................................. 7

Table-3.5: Complexity Matrix for UFP ......................................................................................... 7

Table-3.6: Identifying Complexity of Transaction Function Point Count...................................... 8

Table-3.7: Identifying Complexity of Data Function Point Count............................................... 11

Table-3.8: Unadjusted Function Point Contribution of Transition Function................................ 12

Table-3.9: Unadjusted Function Point Contribution of Data Function......................................... 12

Table-3.10: Complexity Adjustment Value Count ....................................................................... 13

Table-4.1:Database table structure for “admin” ........................................................................... 23

Table-4.2:Database table structure for “doctor” ........................................................................... 23

Table-4.3: Database table structure for “appointment” ................................................................ 23

Table-4.4:Database table structure for “patient” .......................................................................... 24

Table-4.5:Database table structure for “prescription” .................................................................. 24

Table-5.1: Contribution table of APMS project ........................................................................... 25

Automated Prescription Management System, The Problem Solvers Group

vi

Chapter 1: Project Introduction

1

.1 Introduction

Automated Prescription Management System (APMS) is the set of processes and technologies that

manages prescription and appointment booking system and store information of admin, doctor,

patient, prescription and appointments.

Creation and preservation of prescription of each patient is the main goal of this project. Automated

Prescription Management System is an inherently collaborative process. We have done this project

using “Iterative Process Model”. This report based on the project that we have completed in the

course CSC 469 (Software Engineering).

At first, we have analyzed the existing systems to gain deep knowledge. Therefore, we have

designed this automated system for maintaining all the information of any hospital or clinic. In

this report we have described how we developed this system and how it will work.

1

.2 Objectives

1

.2.1 Broad Objectives

The aim of the project is to develop an automated prescription system for the patients.

Because for every time visiting to doctor the patient has to bring all his medical records

and those may lose easily. It becomes very troublesome for some cases. So, for solving this

problem we have planned to develop the system so that the patient can get the prescription

anytime and do not need to carry previous prescriptions. Doctors can also see the full

medical history of any patient within a very short time. It will also help him to give proper

diagnosis to the patient. Along with prescription, this software will also maintain and track

down the records of stuffs, doctors, patients, appointments and other related issues.

1

.2.2 Specific Objectives

The specific objectives of this project are listed below:

1

2

3

4

5

. Improve information accuracy.

. Store and manage doctor, patient and stuff details.

. Store and retrieve the appointments and prescriptions.

. Ensure efficiency and reduce duplication of information

. Controlling access of doctor and patient to the system.

1

.3Iterative Process Model

For this project we have used Iterative process model. In Iterative model, iterative process starts

with a simple implementation of a small set of the software requirements and iteratively enhances

the evolving versions until the complete system is implemented and ready to be deployed. The

basic idea behind this method is to develop a system through repeated cycles (iterative) and in

smaller portions at a time (incremental).

Automated Prescription Management System, The Problem Solvers Group

1

Figure-1.1: Diagram of Iterative process model

1

.3.1 The Feature of Iterative Process Model

❖

Requirements of the complete system are clearly defined and understood.

Major requirements must be defined; however, some functionalities or requested

enhancements may evolve with time.

❖

There are some high-risk features and goals which may change in the future.

Better suited for large and mission-critical projects.

.3.2 Advantages of Iterative Process Model

❖

Some working functionality can be developed quickly and early in the life cycle.

Results are obtained early and periodically.

Parallel development can be planned.

Progress can be measured.

Easier to manage risk.

Automated Prescription Management System, The Problem Solvers Group

2

Chapter 2: Requirement Engineering

2

.1Requirement Analysis

2

.1.1 User Requirements

1

2

3

4

5

6

7

8

9

1

. Admin can add login for different actors.

. Admin can add doctors and patient information.

. Admin can manage his profile.

. Admin can see doctors and patient’s information.

. Doctor can see and manage his information.

. Doctor can see appointments and patient’s previous prescription.

. Doctor can make, view and print prescription.

. Patient can see doctors’ information and make appointment.

. Patient can see and print his/her previous prescription.

0. Patient can update his/her profile.

2

.1.2 System Requirements

Admin:

1

2

3

4

5

. Manage login for admins, doctors and patients.

. Make sign up for patients and make appointment.

. Give password to the admins, doctors and patients.

. Back Up facility for data security.

. Generates different types of reports like doctor info, patient info, admin info,

appointment information and list of admins, doctors, patient, appointment etc.

Doctor:

1

2

3

4

5

. Doctors can login and see and update their information.

. This system allows doctors to see patient previous prescription.

. Check appointments.

. This system keeps every information about doctors.

. System can save the report and print the report.

Patient:

1

2

3

4

5

. System require patient registration for login to website.

. Patients can see doctor details.

. Patient can update his/her profile

. Patients can make and delete appointment.

. They can see the prescription and print it.

Automated Prescription Management System, The Problem Solvers Group

3

2

.1.3 Functional Requirements

1

2

3

4

5

6

7

8

9

1

. Add admin

. Manage admin info

. Add patient

. Manage patient info

. Add doctor

. Manage doctor info

. Add appointment

. Manage appointment

. Add prescription

0. Manage prescription

1. Generate report

2

.1.4 Non-Functional Requirements

1

2

3

4

5

6

7

8

9

. Easy tracking of records and updating can be done.

. The System is very interactive.

. Backups for database should be available.

. System will need all mobile no & password to store in database.

. System needs mobile no & password information from the admin.

. System needs information from the patient.

. Admin can login to the system by using mobile no and password.

. Doctor can login to the system by using mobile no and password.

. Patient can login to the system by using mobile no and password.

2

.1.5 Hardware Requirements

1

2

3

. A minimum of Pentium 4 with a speed of 1.3 GHz.

. A minimum RAM capacity of at least 512MB.

. Hard disk capacity of at least 100mb free space

.1.6 Software Requirements

1

2

3

. Windows 7 and above.

. Xampp Server.

. Web Browser (Firefox or Chrome)

Automated Prescription Management System, The Problem Solvers Group

4

2

.2Use Case Diagram (UCD)

In order to achieve the highest understanding of the project next there will be illustrations

containing various cases of system the system functionalities are shown in use case diagram.

Figure-2.1: Use Case Diagram (UCD) of APMS

Automated Prescription Management System, The Problem Solvers Group

5

Chapter 3: System Planning

3

.1 Scope of Project

A project scope is the clear identification of the work required to successfully complete or

deliver a given project. Project scope control and management is often overlooked in the

management ranks. Software scope determination is the first and most important activity in

software project planning. The statement of software scope must bind. The software should

have ability to manage the members, operators and package information’s and the database.

This project has given the power of re-usability. Present developers are hard to strict towards

giving the system a fully dynamic come across.

3

.2 Functions of Proposed System

Table-3.1: Functions of this proposed system:

Login into the System

Add Admin

F1

F2

Update profile

Add Doctor

F3

F4

Update profile

Add Patient

F5

F6

Update profile

Add Appointment

Update Status

Add Prescription

Generate Report

F7

F8

F9

F10

F11

3

.3 Function Oriented Matrix

Function point-based estimation focuses on information domain values rather than

software values. Function points are computed by comparing five information domain

characteristics.

Data Functions

•

External Inputs [EI]

External Output [EO]

External Inquiries [EQ]

Transaction Functions

•

Internal Logical Files [ILF]

External Interface Files [EIF]

Automated Prescription Management System, The Problem Solvers Group

6

Functional Complexity: The first adjustment factor considers the Functional Complexity

for each unique function. Functional Complexity is determined based on the combination of

data groupings and data elements of a particular function. The number of data elements and

unique groupings are counted and compared to a complexity matrix that will rate the function

as low, average or high complexity. Each of the five functional components (ILF, EIF, EI,

EO and EQ) has its own unique complexity matrix. The complexity matrixes are listed below.

3

.3.1 Complexity Matrix

Table-3.2 : Complexity Matrix for EI

EI

1 - 4 DETs

Low

5 - 15 DETs 16 or more DETs

FTR < 2

FTRs = 2

FTRs = > 3

Low

Average

High

Average

High

Low

Average

High

Table-3.3: Complexity Matrix for EO/EQ

EO/EQ

1 - 5 DETs

Low

6 - 19 DETs 20 or more DETs

FTR<= 1

Low

Average

High

Average

High

2

<= FTRs <= 3

FTRs > 3

Low

Average

High

Table-3.4: Complexity Matrix for ILF/ ELF

ILF/ ELF

RETs <= 1

<= RETs <= 5

RETs > 5

1 - 19 DETs

Low

20 - 50 DETs

Low

51 or more DETs

Average

High

2

Low

Average

High

Average

High

3

.3.2 Complexity Matrix for Unadjusted Function Point (UFP)

Table-3.5: Complexity Matrix for UFP

Complexity

Transaction Function Type

Data Function Type

EI/EQ

EO

4

ILF

7

EIF

5

L (Low)

A (Average)

H (High)

3

4

6

5

10

15

7

10

Automated Prescription Management System, The Problem Solvers Group

7

3

.3.3 Identifying Complexity for Transaction Function Point Count

Table-3.6: Identifying Complexity of Transaction Function Point Count

Transition function

Field/ File Involved

FTRs DETs

Search admin list (EQ) Fields: id, mobile, email, textbox, button

File: admin

1

3

5

6

Search doctor list (EQ) Fields: id, mobile, specialty, textbox, button

File: doctor

Search patient list Fields: id, mobile, email, textbox, button

(EQ)

File: patient

Search appointment Fields: app_id, doc_name, pat_name, date,

list (EQ)

textbox, button

File: patient, appointment, doctor

Search prescription list Fields: pat_name, pres_id, doc_name,

3

1

5

(EQ)

textbox, button

File: patient, doctor, prescription

Fields: adm_name, adm_fname,

adm_mname, adm_mobile, adm_email,

adm_address, adm_dob, adm_gender,

adm_desig, adm_nid_pp, password

File: admin

Add new admin (EI)

11

Add new doctor (EI)

Field: doc_name, doc_mobile, doc_email,

1

13

doc_address,

doc_dob,

doc_gender,

doc_desig, doc_specialist, doc_consult_day,

doc_consult_from, doc_consult_to, doc_fee,

password

File: doctor

Add new patient (EI)

Field: pat_name, pat_mobile, pat_email,

pat_address, pat_age, pat_bg, pat_gender,

password

1

3

8

File: patient

Add new prescription Field: pat_mobile, doc_mobile, pres_date,

26

(EI)

bp, pulse, med_name1, med_strength1,

med_dose1, med_length1, med_taken1,

med_name2, med_strength2, med_dose2,

med_length2, med_taken2, med_name3,

med_strength3, med_dose3, med_length3,

med_taken3, test1, test1_result, test2,

test2_result, c/c, Advice

File: prescription, patient, doctor

Automated Prescription Management System, The Problem Solvers Group

8

Transition function

Field/ File Involved

FTRs

DETs

Add new appointment Field: pat_mobile, doc_mobile, status,

3

5

(

EI)

doc_consult_hour, doc_consult_date

File: appointment, patient, doctor

Fields: user, profile, adm_name,

adm_email, adm_address, adm_dob,

adm_gender, adm_desig, password, save

button.

Update admin

information (EI)

1

10

15

File: admin

Update

information (EI)

doctor Fields: user, profile, doc_name,

doc_email, doc_address, doc_dob,

doc_gender, doc_desig, doc_specialist,

doc_consult_day, doc_consult_from,

doc_consult_to, doc_fee, password, save

button.

File: doctor

Update

patient Fields: user, profile,

pat_name,

1

11

information (EI)

pat_mobile, pat_email, pat_address,

pat_age, pat_bg, pat_gender, pat_pass,

save button.

File: patient

Generating admin list Fields: sidebar, search admin info,

1

5

9

(EO)

admin list, print all button, print.

File: admin

Generating

admin

single Fields: sidebar, search admin info,

information admin list, id, mobile, email, search

button, print button, print.

(EO)

File: admin

Generating doctor list Fields: sidebar, search doctor info,

1

5

9

(EO)

doctor list, print all button, print.

File: doctor

Generating

doctor

single Fields: sidebar, search doctor info,

information doctor list, id, mobile, specialty, search

button, print button, print.

(EO)

File: doctor

Generating patient list Fields: sidebar, search patient info,

1

5

(EO)

patient list, print all button, print.

File: patient

Automated Prescription Management System, The Problem Solvers Group

9

Transition function

Field/ File Involved

FTRs

DETs

Generating

patient

single Fields: sidebar, search patient info,

information patient list, id, mobile, email, search

button, print button, print.

1

9

(EO)

File: patient

Generating

Fields: sidebar, search appointment info,

1

5

appointment list (EO) appointment list, print all button, print.

File: appointment

Generating

appointment (EO)

single Fields: sidebar, search appointment info,

appointment list, app_id, date,

10

doc_name, pat_name, search button,

print button, print.

File: appointment

Generating

prescription (EO)

single Fields: sidebar, search prescription info,

prescription list, pres_id, doc_name,

pat_name, search button, print button,

print.

1

9

File: appointment

Remove admin (EI)

Remove doctor (EI)

Remove patient (EI)

Fields: sidebar, search admin info,

admin list, adm_id, mobile, email, search

button, delete button.

1

3

8

9

File: admin

Fields: sidebar, search doctor info,

doctor list, doc_id, mobile, specialty,

search button, delete button.

File: doctor

Fields: sidebar, search patient info,

patient list, pat_id, mobile, email, search

button, delete button.

File: patient

Remove appointment Fields: sidebar, search appointment info,

(EI)

appointment list, app_id, doc_name,

pat_name, doc_consult_date, search

button, delete button.

File: patient, appointment, doctor

Automated Prescription Management System, The Problem Solvers Group

10

Table-3.7: Identifying Complexity of Data Function Point Count

Data function

Fields/File involve

Field: adm_id, adm_name, adm_mobile,

adm_email, adm_address, adm_dob,

adm_gender,adm_desig, adm_pass

File: admin

RETs

DETs

admin (ILF)

1

9

doctor (ILF)

Field: doc_id, doc_name, doc_mobile,

1

14

doc_email,

doc_gender, doc_desig, doc_specialist,

doc_consult_day, doc_consult_from,

doc_address,

doc_dob,

doc_consult_to, doc_fee, doc_pass

File: doctor

patient (ILF)

Field: pat_id, pat_name, pat_mobile,

pat_email, pat_address, pat_age, pat_bg,

pat_gender, pat_pass

1

3

9

File: patient

appointment (ILF)

Field: app_id, pat_id, pat_name,

pat_mobile, pat_email, pat_age,

pat_problem, doc_id, doc_name,

doc_mobile, doc_desig, doc_specialist,

doc_consult_hour, doc_fee

14

File: appointment, patient, doctor

Field: pres_id, pat_mobile, doc_mobile,

pres_date, bp, pulse, med_name1,

med_strength1, med_dose1, med_length1,

med_taken1, med_name2, med_strength2,

med_dose2, med_length2, med_taken2,

med_name3, med_strength3, med_dose3,

med_length3, med_taken3, test1,

test1_result, test2, test2_result, c/c,

Advice

prescription (ILF)

3

27

File: prescription, patient, doctor

Automated Prescription Management System, The Problem Solvers Group

11

3

.3.4 Unadjusted Function Point Contribution

Table-3.8: Unadjusted Function Point Contribution of Transition Function

Transition function

FTRs DETs Complexity UFP

Search admin list (EQ)

1

3

1

3

1

3

5

Low

Average

Low

High

Low

High

3

4

3

6

3

4

3

6

97

Search doctor list (EQ)

Search patient list (EQ)

5

Search appointment list (EQ)

Search prescription list (EQ)

Add new admin (EI)

6

5

11

13

8

Add new doctor (EI)

Add new patient (EI)

Add new prescription (EI)

Add new appointment (EI)

Update admin information (EI)

Update doctor information (EI)

Update patient information (EI)

Generating admin list (EO)

Generating single admin information (EO)

Generating doctor list (EO)

Generating single doctor information (EO)

Generating patient list (EO)

Generating single patient information (EO)

Generating appointment list (EO)

Generating single appointment (EO)

Generating single prescription (EO)

Remove admin (EI)

26

5

10

15

11

5

9

5

9

5

9

5

10

9

8

Remove doctor (EI)

8

Remove patient (EI)

8

Remove appointment (EI)

Total =

9

Table-3.9: Unadjusted Function Point Contribution of Data Function

Data Function

RETs

DETs Complexity

UFP

admin (ILF)

1

3

9

Low

7

doctor (ILF)

14

9

7

patient (ILF)

Low

7

appointment (ILF)

prescription (ILF)

14

27

Low

7

Average

10

38

Total =

Automated Prescription Management System, The Problem Solvers Group

12

3

.3.5 Performance and Environmental Impact

Table-3.10: Complexity Adjustment Value Count

GSC (General System Characteristics)

DI

4

1

. Data communication

. Distributed data processing

. Performance

2

3

4

5

6

7

8

9

1

0

4

. Heavily used configuration

. Transaction rate

2

0

. Online data entry

. End user efficiency

. Online update

3

4

0

. Complex processing

0. Reusability

2

4

1. Installation ease

2. Operational ease

3. Multiple sites

3

0

4. Facilitate change

3

Total Degree of Influence (TDI), ΣFi =

32

3

.3.6 Counting Function Point:

Function Point Count = Count-Total * [ 0.65+0.01 * ΣFi]

Here,

Count-Total = Total UFP of Transition Function + Total UFP of Data Function

97 + 38 = 135

=

ΣFi = Total Degree of Influence (TDI) = 32

So,

Function Point Count = Count-Total * [0.65 + 0.01 * ΣFi]

=

135 * [ 0.65 + 0.01 * 32]

130.95

Effort for PHP = AFP * Productivity

=

130.95 * 15.5

2029.73 person hours / 8 hours

253.72 person days / 5 persons

50.74 person days / 24 days [In a month there are 24 working days]

2.11 months

[Productivity of PHP is = 15.5]

[Standard working hour is = 8]

[Group consists of 5 members]

Automated Prescription Management System, The Problem Solvers Group

13

Chapter 4: Design Analysis

4

.1Entity Relationship Diagram (ERD)

The Entity Relationship Diagram (ERD) enables a software engineer to specify the data objects

that are input and output from a system, the attributes that define the properties of these objects

and their relationship. It provides an excellent graphical representation of the data structures and

relationship. The ERD of Automated Prescription Management System is drawn below

Figure-4.1: Entity Relationship Diagram (ERD) of APMS

Automated Prescription Management System, The Problem Solvers Group

14

4

.2Data Flow Diagram (DFD)

Data flow diagram is the graphical representation of the process of the content management

system. It will show all processes of this project. In this software, to design the system, Data Flow

Diagram (DFD) has been used which is a graphical representation of the depict information move

from input to output. The DFD may be sued to represent a system or software at any level of

abstraction.

4

.2.1 Context Level Diagram

A Context Level Diagram (CLD) in software engineering and systems engineering is a diagram

that defines the boundary between the system, or part of a system, and its environment, showing

the entities that interact with it. Context level diagram of our system is given below:

Figure-4.2: Context Level Diagram of APMS

Automated Prescription Management System, The Problem Solvers Group

15

4

.2.2 Level 1 Diagram

The Level 1 DFD shows how the system is divided into sub-systems (processes), each of which

deals with one or more of the data flows to or from an external agent, and which together provide

all of the functionality of the system as a whole. Level 1 diagram of our system is given below:

Figure-4.3: Level 1 DFD of APMS

Automated Prescription Management System, The Problem Solvers Group

16

4

.2.3 Level 2 DFD of Process 1 (Login)

Figure-4.4: Level 2 DFD of Process 1

4

.2.4 Level 2 DFD of Process 2 (Admin)

Figure-4.5: Level 2 DFD of Process 2

4

.2.5 Level 2 DFD of Process 3 (Doctor)

Figure-4.6: Level 2 DFD of Process 2

Automated Prescription Management System, The Problem Solvers Group

17

4

.2.6 Level 2 DFD of Process 4 (Patient)

Figure-4.7: Level 2 DFD of Process 4

4

.2.7 Level 2 DFD of Process 5 (Appointment)

Figure-4.8: Level 2 DFD of Process 5

4

.2.8 Level 2 DFD of Process 6 (Prescription)

Figure-4.9: Level 2 DFD of Process 6

Automated Prescription Management System, The Problem Solvers Group

18

4

.3Activity Diagram

Activity diagram is an important behavioral diagram in UML diagram to describe dynamic aspects

of the system. Activity diagram is essentially an advanced version of flow chart that modeling the

flow from one activity to another activity.

4

.3.1 Activity Diagram for Login, Managing Admin, Doctor and Patient

Figure-4.10: Activity Diagram for Login, Managing Admin, Doctor and Patient

Automated Prescription Management System, The Problem Solvers Group

19

4

.3.2 Activity Diagram for Appointment and Prescription

Figure-4.11: Activity Diagram for Appointment and Prescription

Automated Prescription Management System, The Problem Solvers Group

20

4

.4Swim Lane Diagram

A swim lane diagram is a type of flowchart. Like a flowchart, it diagrams a process from start to

finish, but it also divides these steps into categories to help distinguish which departments or

employees are responsible for each set of actions.

Figure-4. 12: Swim Lane Diagram for APMS

Automated Prescription Management System, The Problem Solvers Group

21

4

.5Class Diagram

Class diagram is a static diagram. It represents the static view of an application. Class diagram is

not only used for visualizing, describing, and documenting different aspects of a system but also

for constructing executable code of the software application. Class diagram shows a collection of

classes, interfaces, associations, collaborations, and constraints. It is also known as a structural

diagram. Class diagram for APMS is drawn below:

Figure-4.13: Class diagram for APMS

Automated Prescription Management System, The Problem Solvers Group

22

4

.6 Database Tables Structure

Table-4.1:Database table structure for “admin”

Sl

Attribute Name

adm_id

Size

8

Data Type

Integer (AI)

Varchar

Number

Varchar

Date

Constraints

Primary Key

Not Null

1

2

3

4

5

6

7

8

9

1

.

adm_name

adm_fname

adm_mname

adm_mobile

adm_email

adm_address

adm_dob

30

15

50

100

10

8

.

Not Null

.

Not Null

.

Unique Key

Not Null

.

Not Null

.

Not Null

.

adm_gender

adm_desig

adm_pass

Varchar

Not Null

0.

1.

25

300

Not Null

Table-4.2:Database table structure for “doctor”

Sl

Attribute Name

doc_id

Size

8

Type

Integer (AI)

Varchar

Number

Varchar

Date

Varchar

Time

Constraints

Primary Key

Not Null

Unique Key

Not Null

1

2

3

4

5

6

7

8

9

1

.

doc_name

doc_mobile

doc_email

doc_address

doc_dob

doc_gender

doc_desig

30

15

50

100

10

6

20

50

10

4

.

doc_specialist

doc_consult_day

doc_consult_from

doc_consult_to

doc_fee

0.

1.

2.

3.

4.

Time

Integer

Varchar

doc_pass

300

Table-4.3: Database table structure for “appointment”

Sl

Attribute Name

app_id

Size

8

Type

Integer (AI)

Integer

Constraints

Primary Key

Index Key

Not Null

1

2

3

4

5

6

.

pat_mobile

15

8

doc_mobile

status

Integer

Varchar

Date

doc_consult_hour

doc_consult_date

20

10

Not Null

Automated Prescription Management System, The Problem Solvers Group

23

Table-4.4:Database table structure for “patient”

Sl

Attribute Name

pat_id

Size

8

Type

Integer (AI)

Varchar

Number

Varchar

Integer

Constraints

Primary Key

Not Null

1

2

3

4

5

6

7

8

9

.

pat_name

pat_mobile

pat_email

pat_address

pat_age

30

15

50

100

2

Unique Key

Not Null

pat_bg

3

Varchar

Not Null

pat_gender

pat_pass

6

Not Null

300

Not Null

Table-4. 5:Database table structure for “prescription”

Sl

Attribute Name

pres_id

Size

8

Type

Integer (AI)

Integer

Date

Varchar

Integer

Varchar

Integer

Varchar

Integer

Varchar

Integer

Varchar

Integer

Varchar

Integer

Constraints

Primary Key

Index Key

Not Null

1

2

3

4

5

6

7

8

9

1

2

.

pat_mobile

doc_ mobile

pres_date

15

10

20

3

20

5

10

3

15

20

5

10

3

15

20

5

10

3

bp

pulse

med_name1

med_strength1

med_dose1

med_length1

med_taken1

med_name2

med_strength2

med_dose2

med_length2

med_taken2

med_name3

med_strength3

med_dose3

med_length3

med_taken3

test1

.

Not Null

0.

1.

2.

3.

4.

5.

6.

7.

8.

9.

0.

1.

2.

3.

4.

5.

6.

7.

Varchar

Integer

15

20

100

20

100

300

Varchar

test1_result

test2

test2_result

c/c

Not Null

Advice

Automated Prescription Management System, The Problem Solvers Group

24

Chapter 5: Conclusion

5

.1 Limitation

This project has some limitations those we have planned to develop in futures. The limitations are-

❖

Patients cannot pay consultation fee via the system.

Interfaces may seem little bit complex to understand at first glance.

Online payment gateway needs to be implemented

More data and function validation are required for future debugging.

5

.2 Conclusion

Our project is only a humble venture to satisfy the needs in Automated Prescription Management

System. Several user-friendly coding has also adopted. This package shall prove to be a powerful

package in satisfying all the requirements of the client.

The objective of software planning was to provide a frame work that enables the manger to make

reasonable estimates made within a limited time frame at the beginning of the software project and

should be updated regularly as the project progresses.

Although we could not include all the functionality that we thought to include in this software, we

worked hard to make it fully functional in this small amount of time. As our knowledge of

programming grows by time, we shall look to make it a better one in every possible way. We hope

this software project serve well to its benefactor and give idea to programmer about more advanced

automated patient and prescription management system and related problem solving.

We thank our honorable faculty for supporting us by giving valuable advices and guide lines to

accomplish project goal. We believe we can use this experience in our future career as well.

5

.3 Contribution Table

Table-5.1: Contribution table of APMS project

SL. ID Number

Name

Rihab Rahman

Contribution

Signature

1

.

16103327

Develop admin, appointment module &

prescription output, activity and class

diagram and FPA,

2

3

.

16103323 Md. Khalid Hosain Swim lane diagram, class diagram,

develop login & signup system and FPA,

16103326

16103367

16103390

Tasnia Tahsin

Sirajum Munira

Kaisary Zaman

Requirement analysis, process model

selection, data flow diagram, develop

doctor module and FPA

4

5

.

Requirement

analysis,

database

architecture, develop prescription input

form and FPA

Process

model

selection,

entity

relationship diagram and use case

diagram, develop patient module & FPA

Automated Prescription Management System, The Problem Solvers Group

25

Chapter 6: Bibliography

6

.1 References

1

2

3

. Islam, Md. Shaiful. Content Management System. 15 Jan. 2018.

. Juhura, Fatema Tuj. Point of Sales System for Aparajito Enabler Limited. 10 Aug. 2018.

. Fundamentals & Introduction of Function Point Analysis,

www.softwaremetrics.com/fpafund.htm .

4

5

. Shahnaj, Saika. Development of Online Service Management Application For “iXora

Solution Ltd.”. 20 December. 2018

. “Use Case Diagram Tutorial (Guide with Examples ).” Creately Blog, 19 Sept. 2018,

creately.com/blog/diagrams/use-case-diagram-tutorial/.

6

7

. Function Point Analysis, www.qpmg.com/fp-intro.htm .

. Watt, Adrienne. “Database Design – 2nd Edition.” Database Design 2nd Edition,

BCcampus, 24 Oct. 2014, opentextbc.ca/dbdesign01/chapter/chapter-8-entity-

relationship-model/.

8

9

1

. “Data Flow Diagram Symbols, Types, and Tips.” Lucidchart,

www.lucidchart.com/blog/data-flow-diagram-tutorial .

. T utorialspoint.com. “UML - Activity Diagrams.” Www.tutorialspoint.com,

www.tutorialspoint.com/uml/uml_activity_diagram.htm .

0. “Swim Lane Diagram.” Swim Lane Diagram - Learn Everything About SwimLane

Diagrams, www.smartdraw.com/swim-lane-diagram/.

1. Tutorialspoint.com. “UML - Class Diagram.” Www.tutorialspoint.com,

www.tutorialspoint.com/uml/uml_class_diagram.htm .

Automated Prescription Management System, The Problem Solvers Group

26