University of Electronic

Science and Technology

Medical Tracing System

Software Development and Technology
School of Computer Science and Engineering
Prof. Sun Guolin

Group C
2016

Table of Contents
Chapter 1: Overview of Medical Tracing System
1. Introduction:....................................................................................................................................... 4
1.2 Background.................................................................................................................................... 5
1.3 Purpose ......................................................................................................................................... 6
1.4 Scope ............................................................................................................................................. 6
1.5 Project Management ..................................................................................................................... 7
1.5.1 Project Organization................................................................................................................ 7
1.5.2 Risk Analysis............................................................................................................................ 8
1.5.3 Hardware and Software Requirements .................................................................................... 9
1.5.4 Work Breakdown/Project Schedule ......................................................................................... 9
2. System Analysis ................................................................................................................................ 11
2.1 Functional Requirement............................................................................................................... 11
2.2 Non-Functional Requirements ..................................................................................................... 12
2.3 Stakeholder and User Description ................................................................................................ 13
2.4 use case ....................................................................................................................................... 14
2.5 Sequence Diagram ....................................................................................................................... 17
2.6 Activity diagrams ......................................................................................................................... 19
2.7 Class Diagram .............................................................................................................................. 23
3. System Design ................................................................................................................................... 24
3.1 The Architecture .......................................................................................................................... 24
3.2 Deployment Model ...................................................................................................................... 25
3.2.1 Client .................................................................................................................................... 25
3.2.2 Server ................................................................................................................................... 26
3.2.3 Database ............................................................................................................................... 27
4. User interface ................................................................................................................................... 27

1. Introduction:
In this project we developed a system to manage the reuse and operation of medical
equipments, in order to improve and regulate private medical operations with tools
and follow-up starting from recycling, washing, packing, sterilizing, dispatching,
and use.
A good equipment planning includes careful Attention to fixed and movable
equipments that will be needed in operations.
The lack of planning will result:
Wastage of millions of rupees
Reduced Operational efficiency
Lower standards of patient care
This document seeks to provide a detailed documentation of Medical Tracing
System. It can also be referred to as a contract between client and contractor. In it,
the document will display all the necessary information used to develop the system,
that is, the prerequisites highlighted by the users and the developers so as to acquire
a working application.
This document is intended to describe the details of required functionalities and
providing a high level view. The main audiences of this document are developers
who are going to work on this project. The purpose of this module is to access and
consider how viable and feasible it is to implement such a system as required by the
4

stake holder, taking into account all hitches and promises for its design and
implementation. The rest of the document is structured as follows. First the
background
1.2 Background

The system will aid the reusing of medical equipment by receiving incoming packets
from different hospital department, and organize the tools in basket, and then register
recycling process by scanning the barcode of the packets. However, upon the
successful registration of a packet, the system will allow the staff to assign the value
of barcode if the barcode is missing.
After recycling they run different operation to the basket until repacking again and
store the packets in different department store in order to use. also the system offers
more organization to the process and let the administrators to monitor the all
information during all steps.
The system will further serve the sterilization process by checking incoming packets
and distribute each in the suitable sterilize process.
Medical tracing system has 6 steps:
Receiving (Packets, Basket) with tag of barcode
First of all, a person receives the packet in basket containing medical tools,
Person has specific bar code. He scans his bar code and also scans the packet
bar code and delivers it to the washing section.
Washing (Basket, Pots) with tag of barcode
In washing section, medical tools are divided into specific pots and then put
into baskets which also have specific barcode. Barcode mentioned on baskets
be scanned by a person and entered into the computer system. After that
baskets are sent to the washing process.
Packing (Packets) with tag of barcode
After the washing process, tools are putted into specific pots and packed the
tools in the packets. Then tag a barcode on the packets and also scan his
barcode. After scanning packets are delivered to the sterilizing section.
5

 Sterilize (Packets with Pots) with tag of barcode

When packets are received, these are ready for sterilization process where
medical tools can be sterilizing on 15 C to 32 C.
Dispatch (Packets in Ranks) Ready to dispatch
After sterilization process, packets are putted into ranks for delivery.
Use (Packets) ready to use
Now medical tools are able to reuse.
1.3 Purpose

The purpose of this Requirement Analysis Document is to clarify the functional and
the non-functional requirements of the current system and to define the high-level
design specification of the proposed system.
In this RAD document we included:
General overview over the operation of the system.
Capabilities of our system.
Functional and non-functional requirements
1.4 Scope

The scope of this project is to design Medical tracing system software for the
hospital. This will improve service by providing an information system and a
platform for both Administrators and the staff to be well informed and participate in
activities of the reusing.
The system will be used in conjunction with other pre-existing systems and will
consist largely of a document interaction facade that abstracts document interactions
and handling of the document objects.

1.5 Project Management

This section describes the process of organizing, planning and scheduling of

activities so as to make sure the software is delivered on time and on scheduled as
per according to stared specifications.
1.5.1 Project Organization
This consists of the various team members involved in the project and their various
roles as can be seen below

Table 1: PROJECT MEMBERS ROLES & RESPONSIBILITIES

NAME

PROJECT ROLE

PROJECT RESPONSIBILITIES

Muhammad Mateen

Writing Documentation

Rita Karikari

Writing Documentation

Participate in Requirements gathering

Draft final documentation
Participate in Requirements gathering

Raheel Ahmed Memon

Programmer,
System Expert
Programmer

Sarmad Ali Junejo

Write / assist with writing of functional specification

document(s)

Develop system interfaces

Design, Build, Unit test, migrate and transition all
technical deliverables, including online reports

Abraham Tonny Hagan

Programmer

Participate in Requirements gathering

Nuhoho Raphael elimeli

Writing Documentation

Participate in Requirements gathering

Syed Ahsen Aftab

Programmer

Develop system interfaces

Design, Build, Unit test, migrate and transition all
technical deliverables, including online reports

Ahmed Aftab
Wasif Feroze

Writing Documentation

Draft final documentation

Project Coordinator, Develop system interfaces
Participate in functional specification development
Programmer,
meetings for representative systems
System Expert
Design, Build, Unit test, migrate and transition all
technical deliverables, including online reports

Hamza Mokhtar

Project
Manager, Provide overall project oversight and work with
business offices and Technical Project manager to
Programmer,
keep project on track
System Expert
Develop system interfaces

1.5.2 Risk Analysis

The objective of risk management and analysis is to reduce different risks related to
our software to the level accepted by the end users. :
Estimation and scheduling The unique nature of individual software projects
creates problems for developers and managers in estimating and scheduling
development time.
Sudden growth in requirements as a project progresses, issues that are not
identified earlier can create a last-minute hurdle to meeting deadlines
Risks with the hardware and software (the development platform) chosen to
perform project development.
Non-Availability of application test resources.
Risks associated with using off-the-shelf packages.
Project team member(s) will not be in place when required.
Risks associated with any conversions of existing data required before
implementation of a new system.
Risks associated with personnel assigned to the project who may be pulled off
anytime for another assignment.
The activities that will be done to overcome these risks are:
Get the team more involved in planning and estimating. Get early feedback
and address slips directly with stakeholders
Constant involvement of customers and developers.
Increased collaboration and information sharing on the team.
Conducting Risk Assessment review meeting with the development team.
Profile for Risk coverage is created by mentioning the importance of each
area.
Using maximum resources to work on High Risk areas like allocating more
testers for High risk areas and minimum resources for Medium and Low risk
areas.
8

 Creation of Risk assessment database for future maintenance and management

review
1.5.3 Hardware and Software Requirements
This application requires the following Softwares for successful development
and deployment:
Servers and Server OS (Linux servers)
Computer Terminals and Client OS
Barcode Reader
Barcode Printers
Php 5.6 and above
Mysql 6
Apache 2.0 and above
IDE (NetBeans 8.2 JDK 8)
1.5.4 Work Breakdown/Project Schedule
This section describes the breakdown of the project into the various activities,
milestones and deliverables that were involved in the project. The dependences
between activities, estimated time and allocation of people were also clearly stated

Project's
WBS
Management

Design

Development

Acceptance
Testing

Installation

Maintenance

Plan Project

Prepare
Preliminary
Design

Develop
Software

Plan
Acceptance
Test

Develop
Installation
Plan

Hardware
Maintenance

Track Project

Prepare
Detailed
Design

Get Hardware

Conduct
Acceptance
Test

Site
Preparation

Software
Maintained

Perform
Quality
Activities

Document
Design

Get Software
Packages

Develop Test
Report

Install at
Locations

Review
Design

Perform
Integration
Testing
Convert Data

Develop User
Manual

Figure 1: Work Breakdown Structure (WBS)

The activities involve:

els development

system evaluation
The principal milestones of the project have been identified as follows:
Table 2: Project schedule Milestone
10

Activities / week

First Month

Second
month

Third
month

Analysis
Design
Developing the project

Evaluate
Testing

2. System Analysis:
2.1 Functional Requirement:

Functional Requirements includes:

1.

The system allows the actor to create equipment record and equipment type
record.

2.

The system should allow actor and administrator to view, update and print
their document

3.

The system must force the actor to input the barcode of equipment and the
classification

4.

The system must be able to determine the equipment type and the state from
the barcode identity.

5.

The system should know what the process needed to each equipment
(sterilization)
11

6.

The system should know the current available equipments.

7.

The system registers the equipment lifetime.

8.

The system monitors the machine in the system.

9.

The system should generate new barcode id to each packages.

10. The system register and store the packages information.

11. The system should allow the administrator to monitor the all process of
recycling.
2.2 Non-Functional Requirements:

1.

The system must know the privileges of each user

2.

The system just allows authorized user to do specifics things

3.

The system must be easy to use of end users like nurses and worker

4.

The system must send notification to the administrator if any fault happen

5.

The system must work if have partial failure

6.

The system offers good organization to the clinic

7.

The system must have technical support

8.

Security Requirements: Security requirements are important factors in this

system as classified data will be stored in the database; we are going to develop
a secured database. There are different categories of users namely
Administrator, Student who will be viewing either all or some specific
information from the database. User validation will be done during login to
insure that the user is valid and that the user only has access to his or her
permission data. Example: Depending upon the category of user the access
rights are decided. It means if the user is an administrator then he can be able
to modify the data, append etc. All other users only have the rights to retrieve
the information about database. General users will only have access through
the user interface.

12

9.

Interactive User Interface: The system will have consistent interface formats
and button sets for all forms in the application, it will have a form based
interface for all data entry and viewing formats, and will generate reports that
are formatted in a table and that should look like the existing manual report
formats for user friendliness.

10. Performance: The proposed system that we are going to develop will be used
as the Chief performance system for providing information and in managing
the whole database of the student studying in the university. Therefore, it is
expected that the database would perform functionally all the requirements that
are specified. Easy tracking of records and updating can be done. Other
performance issues are a good response time and throughput.
11. Scalability: The system will be a scalable system which will have the capability
of handling more hardware and devices which will be added in order to handle
the growing amount of work as time goes on and as the university grows. This
feature will enable the system to increase its total output under an increased
load when resources are added to meet the needs of the institution. Besides, it
could expand to accommodate more information as more student information
is added.
12. Manageability: With a friendly user interface, easy configuration, automatic
backups, and other features including the provision of user manual,
administrators would not have any difficulty in managing the system.

2.3 Stakeholder and User Description

The stakeholders of this system are the staff, doctor, and the Administrators. The
system is managing by the system administrator. The doctor is given some
administrative privileges in the system. The staff are users and given standard
privilege of the system. Therefore, any staff who is work into the hospital is
considered as user of the system.

13

2.4 use case

This section describes the sequence of events of the user (actor) in the various
processes carried out in registering, awarding scholarship, information about
job/internships and allocation of courses.
Use Case diagrams are used for this description because they give a graphical
representation of the interactions among the elements of a system and this helps to
identify, clarify, and organize system requirements.

Medical Tracing System

Receiving Tool
Packets

Entries
With barcode

Worker/Receiver

Without barcode

Scan

Register

Handler for
Missing Tools

Scan Basket

Organize the
Tools in Basket

Figure 2: Receiver use case diagram

14

Medical Tracing System

Basket Scan

Staff

Chemical
Process

Washing
Machine

Washing

Quality Verification

Analyst
Store
Figure 3: Use-Case
Diagram for Washing

Medical Tracing System

Borrow
Order Title
Basket Scan

Staff

Tools
Distribution

Analyst

Packaging

Quality
Verification

Figure 4: Use-Case Diaing

15

Figure 5: Use-Case Diagram for Sterilization

Medical Tracing System

Borrow
Order Title

Scan Packet

Staff
Quality
Verification

Dispatch

16

Analyst

Figure 6: Use-Case Diagram for Dispatch

2.5 Sequence Diagram

Sequence diagram is used to represent or model the flow of messages, events and
actions between the objects or components of a system. This section shows the
design and logic of the to-be system by describing the sequence of actions that need
to be performed to complete a task or scenario.

Recycling

Scan
Code

Scan
basket

Missing
Tool
s

Scan/
Register Pkt

Store

Registeration

update
Treatment
update
update

update

Figure 7: Sequence Diagram Recycling Process

Staff

Scan
Code

Quality
Ve rification

Washing

Store

Registeration
update
Unsatisfied
update

update

17

Figure 8: Sequence Diagram Washing Process

Staff

Packaging

Store

Scan
Code
Unsatisfied

update
update
update

Figure 9: Sequence Diagram Packaging Process

Staff

Sterilization

Store

Scan
Code
Unsatisfied
update
update
update

Figure 10: Sequence Diagram Sterilizing Process

18

Staff

Quality

Dispatch

Scan
Code

update
update
update

Figure 11: Sequence Diagram Dispatching Process

2.6 Activity diagrams

State transition diagram is a type of directed graph, in which the graph nodes
represent states and labels on the graph edges represent actions.
This section uses state diagram to specify the sequencing/timing behavior of objects
in a class states, events and transitions

Receiving From
Clinic

ReceivingPacket
fromClinic

Missing Tools
Registeration

Scanning/
Registeration

BarcodeScan/
Availablity

Y es

Y es
Instruments Missing

Ready for next

phase (Washing)

Register Missing
Instruments

Ready for
NextPhase

No

No

ScanBarcode

Registeration

19

Receiving From
Recycling Phase

Quality
Verification

Washing

Y es

ReceivingBasket
from Recycling

Quality Verification

Quality
Verification

Ready for next

phase (Packaging)

Y es

Receiving Basket
from Recycling

Ready for
NextPhase

Quality Verification

No

No

Returntoprevious Phase

Figure 13: Activity Diagram - Washing Process

Receiving From
Washing Phase

ReceivingBasket
from Washing

Pakcaging

Ready for next

phase (Sterilization)

Quality
Verification

Y es
Packaging

Quality Verification

No

20

Packets Ready
for Next Phase

Figure 14: Activity Diagram - Packaging Process

Receiving From
Packaging Phase

Ready for next

phase (Dispatch)

Quality
Verification

Sterilization

Y es
ReceivingPackets
fromPackaging

Quality Verification

Sterilization

No

Figure 15: Activity Diagram - Sterilization Process

21

Store inTemp
Location for
NextPhase

Receiving From
Sterilization Phase

Ready for delivering

Clinic

Quality
Verification

Y es

Receiving Packets
fromSterilization

Quality Verification

No
Returnto previous Phase

22

Store inTemp
Location for
NextPhase

- Was hing
- Sterilization
- P ac kaging
- E xpiry

Figure 16: Activity Diagram - Dispatch Process

2.7 Class Diagram

Class diagram shows all the classes used by a system, their attributes, and the
methods they utilize to accomplish the various tasks required. This section depicts
a static view of the model describing what attributes and behavior it has rather than
detailing the methods for achieving operations. The class diagram will also
illustrate the relationships between classes and interfaces.

UML Class Diagram

Staff

- staffID: int
- staffName: string
- staffAdress: string
- hireDate: date
- salary: double
*
Recycling
- time: date
- staffID: Staff
- deptID: Department
- instrumentList: string
- quantity: int
- basketID: int

+ AddStaff (): void

+ ModifyStaff): void
+ DeleteStaff(): int
+ CalculateSalary(): double

Washing
1

- basketId: int
- staffID: int
- machineID: int
1 - time: Date
+ MachineWash(): void
+ MunaulWash(): void
+ IsWashed(): bool

Sterilizing
Department

1 - staffID: int
- packgID: int
- status: string
- time: date
- equipmentName: string
- picture: Image

1
- deptID: int
- deptName: string
- deptAdress: string

+ BarcodeReader(): int
+ BarcodeGenerator(): int
+ RegisterInfo(): void
+ ProcessComplete ():
bool

+ AddDept (): void

+ ModifyDept(): void
+ DeleteDept(): int

+ StartProcess(): void
+ Completed(): void
+ AddPicture(): void

*
1

1
1

Dispatching

Packaging

- packgID: int
- packgName: string
- packgDept: string
+ IsPackaged(): bool
*

Instrument
1
*

- instID: int
- instName: string
- instType: string
+ Add (): void
+ Modify(): void
+ Delete(): int
+ Use(): void

23

- packgID: int
- packgName: string
- deptID: int
- staffID: int
- time: date
- recient: string
- totalPackg: int

+ Dispatch(): void

3. System Design
In this section, the document presents a detailed approach of how the system is
built and the processes related to it and how each functions relays to the user and
system requirements. This section is divided into the following subsections
3.1 The Architecture

First, the user needs to open web browser and send http request to web server for
any page or information. The webserver goes through the app files and if it is a
static file for instance an image, the server will fetch directly from the app
resource. If the user needs to login or inquire for sensitive data, s/he needs to be
authenticated through the process page. The process page will check the
authentication of the user and see if s/he satisfies the correct credentials. The user
will get a response from the query if (or not) s/he is successful. After the checkup
of the user authentication, the php engine will fetch the data from the database
server and send it through the webserver to the user via the web browser. The user
can be any of the actors mentioned.

24

Figure 17: System Architecture

3.2 Deployment Model

Medical Tracing System will be deployed as a generic 3-tier application which

comprises of client, Server and Database hosted online and managed on the
Hospital network infrastructure.
3.2.1 Client
The client basically serves in the form of web pages that ran on the users computer
when the required URL address has been entered. The client is often likened as the
25

presentation tier because it renders the graphical user interface where majority of the
process that user and system takes place. Form validation, constraints, help tips and
miscellaneous operations are carried out at this level before it is transported or
fetched from requested destination.
3.2.2 Server
The server is the transport mechanism between the client and the Database
(repository) in our deployment model. The server is implement by MySQL. This
creates a connection anytime request is made to the database. It sends a post and
get commands from and to the database.
Results of these requests are displayed as notifications at the client level

Figure 18: deployment diagram

26

3.2.3 Database
All information is stored permanently on the database until modified or otherwise.
User requests and submissions are served by the database repository. It is therefore
critical to keep the database system secured and online at all times. Root operations
on the database can only be invoked by developers of this application. This is to
ensure absolute consistency and reliability of our Database system.

Figure 19: database tables

4. User interface

27

Figure 20: login form

Figure 21: registration form

28

Figure 22: recycle form

Figure 23: instrument form

29

Figure 24: sterilization form

Figure 25: washing form

30

Figure 26: dispatching form

31