Patient Management System (PMS)

View with images and charts

Patient Management System

(PMS)

1.1 Introduction

The objective of this part is to introduce the system that we want to develop .The problem of existing system and why this system should be automated. Doctors are most important part of our country. Doctors help us to take good health. They should be provided with consistent environment for take patient information. It provides an information system, which records necessary for a patient. This is known as Patient Information System (PMS). This system is used by the doctor or legal employee and contains all the relative information about patients and their dieses. This system ensures appropriate with proper security to the stored data within it. PMS helps patients by informing their previous/present dieses and treatment, diagnosis report, details advice and accounts relative information etc.

1.2 Case Study

For the case study we choose Japan Bangladesh Friendship Hospital, Dhaka, Bangladesh. It has about 500 patients in a day. But, the details of patient are kept at the manual system in doctor chamber. This causes many problems. The registry doesn’t know any of the details of the patients and doesn’t have easy access to any details about patients. Sometimes it becomes very much time consuming. Watching those problems of this department we tried to develop new software named “Patient Management System (PMS)” which contains all the necessary information about the patient details, their disease description, treatment, diagnosis report details advice and accounts relative information etc. But have a another great problem that is most of the time patient lose their prescription and report which is very harmful for a patient to take treatment for next time.

1. 2.1 the problems in existing System

Now a day, most of the doctors uses manual system that is they keep their record in the laser book. But this is too much analogues. If any person requests a query then the responsible employee can’t give him answer in a quick way. But this is not correct. Sometimes this manual would be damaged. For this reason, this scheme is not perfect or continues in this time.

1.2.2 Necessity of automation

This is fully computer aided system. In this system, a person can quickly recover any data and query any question. All difficulties and damages are removed in this software.

1.2.3 Future Plan

In future, this software may be developed for auto dieses detection and treatment with proper advice, developed for using through the internet. So that, any patient can easy access of this software for detect dieses and treatment etc.

1.2.4 Methodology

Software is a complex artifact created by human being. The entire complex being is produced in a step-by-step procedure, which is called methodology for that artifact. Therefore, methodology is needed for software in order to build it with consistency. Now as a wise system development follow a deliberate life cycle for precise & stepwise development of the software or system. We also follow Royce’s Software Development Life Cycle (SDLC).

1.2.5 Definition of SDLC

A Software Development Life Cycle (SDLC) is an abstract description of the structured end methodological development and modification process applied to the main stages of producing and developing software.

Request for a system

Feasibility

Study (1)

Change Request

Figure 1: Software Development Life Cycle

Feasibility Study

At first stage of SDLC we have to measure feasibility study of our proposed system that is system feasibility study of economics, implementation etc.

Requirement Definition

At this stage we have to develop system’s requirement by using well-known requirement engineering framework. RE involves three major frames, —

–Requirement Analysis

–Requirement Specification

–Requirement Validation

System Specification

In system specification our first concern is ERD (Entity Relationship Diagram), which shows entity with their attributes, relationship with entities involving one to one, one to many, many to one or many to many, assigning primary keys & perform normalizations to reduce data redundancy.

System Design

System Design accomplished by two ways; overall design and Detailed design. Overall design sets structure of shape of the software. “Structure Charts” might be used here as part of functional design strategy. Detailed design defines the processing that is carried out through the whole program. Stepwise refinement might be applied for our proposed system.

Program Design & Coding

SDLC model program design and coding occupies as little as 10% of project effort. Here we write the coding by using well-known programming language such as Object-Oriented language(C#).

Testing

Testing is one of the most important steps to develop a system. Testing is a process of finding errors. Testing can be implemented in our proposed by two ways, —

–White Box Testing &

–Black Box Testing.

Implementation

In SDLC model, this stage involves implementing our Patient Management System to any types of Information in the Japan Bangladesh Friendship Hospital, Dhaka at chamber of doctors & see how it works.

Change Request Definition

If any request comes after delivering the system then this stage defines the processing of development of the delivered system. This type of maintenance is very important.

Now at conclusion when we have to develop our system (Patient Management System), we must follow SDLC that have been described above.

1.2.6 Necessity of using this model

There are several process models available for the development of software. But we have considered Software Development Life Cycle as the appropriate framework in order to develop our software.

The reasons are given below

Ø Software Development Life Cycle (SDLC) is a complete cyclic process model. The software we need to develop must go throw the various stages of SDLC so that we can develop a more efficient and reliable software.

Ø Software Development Life Cycle (SDLC) has a starting point which has helped us to determine from where to start to develop our software.

Ø Software Development Life Cycle (SDLC) has a system request and change request on maintenance. So does our software. For the maintenance of the software and to make it more reliable we are ready to accept user request.

Ø Software Development Life Cycle (SDLC) is a linear sequential process model and triggered.

Background

2.1 About Process Model

Process is an activity, which operates on an object and changes its state. Model is the graphical representation of an object. So, a process model shows the activities of software graphically.

2.2 Necessity Process Model

We need process model because process is important than product (software). If the process is good, the product also is good.

2.3 A particular Process Model for Patient Management System

Software Development Life Cycle (SDLC) is a general cycle to develop software. But, in this software we use a specific Process Model that is “Throw away Process Model”

Throw Away Process Model

Prototyping loop Specification derived Standard developed

Prototype

Specification

Design
Software

Specification

from Prototype Process

Figure 2.1 Throw Away Prototyping Process Model

We choose Throw Away Prototyping Process Model, because of its following advantages:

1) Requirement become clear as customer actually use the system.

a) Misunderstandings are clarified.

b) Missing functions are clarified.

c) Poor interface can be refined.

d) Missing requirement can be identified.

2) Proper working system is produced, although it is limited in functionality and performance.

3) Prototype becomes Specification.

Requirements

3.1 Functional requirements

Functional requirements for a system describe the functionality or services that the system is expected to provide. They depend on the type of software, which is being developed, the expected users of the software and the type of system, which is being developed.

Functional requirements for a software system may be expressed in a number of different ways. Here are a number of functional requirements for “Patient Management System”:

1) The user shall be able to search either all of the initial set of databases or select a subset from it.

2) The system shall provide appropriate viewers for the user to read documents.

3) Every order shall be allocated a unique identifier.

3.2 Nonfunctional Requirements

Non-functional requirements are used to define system properties and constraints. These types of requirements arise through user needs because of external factors that may control software environment.

For the “Patient Management System”, the non-functional requirements are:

Ø How efficiently and reliably, we can use our system.

Ø How quickly the system delivered services by maintaining standard.

Ø Security, privacy and safety.

Ø User Friendly

3.3 Requirement Engineering

Requirement engineering is that activity transforms the needs and wishes of customers and potential users of computerized systems, usually incomplete, and expressed in informal terms, into complete, precise, and consistent, preferably written in formal notation.

3.4 Requirement Engineering Process

To develop particular software, everyone should follow all the process of requirement engineering. We can define requirement engineering as follows:

Requirement Engineering is the systematic process of developing requirements through an iterative co-operative process of analyzing the problem (Requirement analysis), documenting the observations in a variety of representation formats (Requirement specification) and checking (Validation) the accuracy of the understanding gained.

User feedback

Models to

User be validated

Requirements by user

Requirement

Specifications

Requirement

Knowledgemodels

Request Validation

More knowledge results

Domain Domain

Knowledge Knowledge

Figure 3.1 Requirement Engineering Process

There are three process considered in Requirement engineering. Those are:

i) Requirement Analysis / Elicitation,

ii) Requirement Validation,

iii) Requirement Specification.

3.4.1 Requirement Analysis

Requirement Analysis is the process of acquiring (eliciting) all the relevant knowledge needed to produce a requirement model of a problem domain. It is an iterative process, which involves domain understanding, requirement collection, classification, structuring, conflict resolution, prioritization and validation.

We can diagrammatically represent requirement analysis process as the below figure:

Process entry

Figure 3.1: Requirement Analysis Process Model

3.4.1.1 Requirement Analysis using VORD method

We are applying here VORD method. Here are four phases in the VORD method.

Discovering Grouping them into Refinement of the

Viewpoints into a hierarchy description of the viewpoints

And services identified

Those are

· Viewpoint Identification

· Viewpoint structuring

· Viewpoint documentation

· Viewpoint System mapping

? Viewpoint Identification

Viewpoint Identification, which involves discovering viewpoints that receive system services and identifying the specific services provided to each viewpoint.

? Viewpoint structuring

Viewpoint structuring, which involves into a hierarchy. Common services are provided at higher levels in the hierarchy and are inherited by lower – level viewpoints.

? Viewpoint Documentation

Viewpoint documentation, which involves refining the description of the identified viewpoints and services.

? Viewpoint – system mapping

Viewpoint – system mapping, which involves identifying objects in an object – oriented design using service information, which is encapsulated in viewpoints.

3.4.1.2 Viewpoint Identification using Brainstorming

The approach used to identify the viewpoint is brainstorming, which is given in the below:

Figure 3.2: Viewpoint Identification using Brainstorming

3.4.1.2.1 View Points

Ø Patient

Ø Dieses

Ø Treatment

Ø Accounts

3.4.1.2.2 Service

Ø Patient Information

Ø Patient Treatments

Ø Accounts

3.4.1.2.3 Data input

Ø Patient ID number, Patient Name, Age, Address, Referrer

Ø Treatment, Advice

Ø Accounts (Visit Fee)

3.4.1.2.4 Exception

Ø Security of user information

Ø Invalid ID

Ø Consistency in staff scheduling

3.4.1.2.5 Non-functional requirements

Ø Friendly Behaviour from employees and patients

Ø Crashing OS

Ø Electricity Failure

3.4.1.2.6 Control event

Ø Valid user ID

Ø Select Service

PMS viewpoints and their service templates

Template For Service – 1:

3.4.1.3 Scenarios

Scenario can be particularly useful adding detail to an outline requirement description. At its most general, a scenario may include:

1) A system state description at the beginning of the scenario.

2) A description of the normal flow of events in the scenario.

3) A description of what can go wrong and how this is handled.

4) Information about other activities, which might be going on the same time.

5) A description of the state of the system after completion of the scenario.

3.4.1.4 Event scenario

Event Scenario is used in VORD method to document the system behavior when presented with specific events. Event scenarios for “Student Information System”, is given below:

Figure 3.3: Event scenario

3.4.2 Requirement Specification

Requirement Specification can be viewed as a contract between user and software developer which defines the desired behavior of the software artifacts without showing hoe such functionality is going too achieved.

3.4.2.1 Requirement definition

n Requirement Definition associated with a problem in a formal way

Reference: Information about patients

Definition: This service holds all the patients details.

Action/Process: Request patient ID, enter the ID into system, shows the information.

Rationale: This helps to know patient details perfectly.

Reference: Requirement analysis service template-1

Reference: How to Admit

Definition: The patient who seeks to admit gets all the information from this service.

Action/Process: Asking for the process to get admitted

Rationale: This helps doctors about the process of the treatment.

3.4.2.2 Requirement Specification (using PDL)

Procedure PMS

ID Patient_ID;

Service Avail_Service;

Password, Valid_ID_No;

Begin

Loop

Get_ID (Password, Valid_ID_No);

If Valid_ ID_No & Password then

Get_Details (ID);

Get_Service (Service);

While a Service is selected Loop

Deliver_Service (Service);

Get_Service (Service);

End While;

Else

Print (“Error Message”);

End if;

End Loop

End procedure PMS

3.4.3 Requirement Validation

The identified requirements are checked to discover if they are complete and consistent in accordance with that subscriber really want from the system.

3.4.3.1 Different types of check in validation

During the requirement validation process, different types of checks should be carried out. These checks include:

1) Validity checks

2) Consistency checks

3) Completeness checks

4) Realism checks

5) Verifiability

For “Patient Management System”, the above validities were checked.

3.4.3.2 Requirement Validation techniques

There are a number of requirements validation techniques, which can be used in conjunction or individually. The validation techniques are:

1) Requirement reviews

2) Prototyping

3) Test-case generation

4) Automated Consistency

For “Patient Management System”, we prefer Prototyping requirement validation technique.

Design & System Specification

4.1 Software Specification

There are three levels of software specification, which may be developed. These are:

1) User requirement

2) System requirement

3) A software design specification

The user requirements are the most abstract specification and the software design specification is the most detailed.

4.2 Formal Software Specification

Formal Software Specification can be expressed in a language whose vocabulary, syntax and semantics are formally defined. Specification language cannot be based on natural language but on mathematics.

In general, formal mathematical specification lie somewhere between system requirement and software design specifications. They don’t include implementation detail but should present a complete mathematical model of the system.

4.3 Formal Specification in the Software process

The following figure shows the stages of software specification and its interface with the design process:

Figure 4.1 Formal Specification in the Software process

4.4 Formal Specification language

There are two approaches to formal specification that have been used to write detailed specifications for non-trivial software system. These are:

1) An algebraic approach where the system is described in terms of operations and their relationships.

2) A model based approach where a model of the system is build using mathematical constructs such as sets and sequence and the system operations are defined by how they modify the system state.

Overall Design

4.5 A general Model of software design process

Design is the process of translating between the specifications of what the system must do in to a specification of how the system will accomplish it. Software engineer conduct each of the design task. In the design process for Registration Management System, we have to translate the system’s requirement specification into a design that can be implemented by using many tools and techniques by the programmer.

A general Model of software design process is shown in below figure:

Figure 4.2: A general Model of software design process

Here,

Architecture Design specifies the set of components that make up the program.

Interface Designspecifies the way in which the component interacts.

The Component Design specifies the responsibilities that are allowed to the components.

Data Structure Design specifies the data structure usedin the program are designed in detail and specified.

Algorithm Design specifies the algorithm that allows the components to fulfill their responsibilities must be identified.

4.6 Structure Analysis

The aim of structured analysis is to transform the textural description of a problem into graphical model.

Process à Data flow à

File à External à

Entity

Figure 4.3: Context Diagram

4.7 Entity Relationship Diagram (ERD)

The Entity Relationship Diagram for “Patient Management System”is drawn below:

Figure 4.4 Entity Relationship Diagram

Here,

Data Flow

Represents entity

Represents attribute

Represents relationship

Represents link to the attributes and relationship.

4.8 Data Flow diagram (DFD)

Data flow Diagram (DFD) is concerned with understanding the processing within an organization and the relationship between those processes. DFD graphically illustrates movement of data between external entities and the processes and data stores within a system.

DFD for “Patent Management System” will be as follows:

DFD For Level 1

Giving Valid Data

Data (ID)

Request

Patient

Sending

Details

Transmitting Asking Sending Information Treatment Treatment

Transmitting

Information

Request

Treatment

Sending Name

Figure 4.5 DFD Level 1

4.9 Afferent Data Flow

Incoming data flows

Giving Valid Data

Data (ID)

Requesting Asking

Type Type

Request

Patient

Sending

Details

Transmitting Asking Sending Information Dieses Courses

Transmitting

Information

Request

Treatment

Sending Name

Figure 4.6 Afferent Data Flow

4.10 Efferent Data Flow

Outgoing data flows

Request

Patient

Sending

Details

Transmitting

Information

Transmitting

Information

User

Request

Showing

Figure 4.7 Efferent Data Flow

4.11 Structured Chart

Valid Data PPD Rece_Cou_info

ACAD_ID Print

ACAD_Info

P_File Deliver_Info p_File Re_Co

Delivering Details
Dieses Information
Sending request to file
Deliver information
Sending request to file
Receiving Dieses *

Figure 4.8 Structured Charts

In the above figure we describe the “Structure chart” notation for our proposed Patient Management System. The figure —

Represents Modules that mean where we write code.

Represents as like as Library Function.

Represents Data couples.

4.12 Detailed Design

Detailed design defines the processing that is carried out in the modules. It specifies “the how” for each module in the design. We can use “stepwise Refinement” strategy to develop detailed design for “Patient Management System”. In stepwise refinement we start at the high level & refine it progressively down into sets of lower level statements. This can be done using a number of notations and techniques. In the most cases, we prefer pseudocode because- it is flexible and is familiar to programming language.

There is well known techniques to develop the detailed design for any wise system. This is the JSP (Jackson Structured Programming). It is a methodical approach proposed by “structured methods” which are sets of notations and guidelines for software design.

4.12.1 Jackson Structured Programming

PMS Process’s sequences

Entering Data

Processing Personal Details

Retrieving Dieses

Displaying Information

PMS end

Information of Patients selects like Personal Life

Personal Life record

Information of patients or like Personal

Personal record

Information of patients end

Retrieving Dieses

Receiving Dieses Symptom

Retrieving Dieses end

4.13 Data Dictionary

Data Dictionary is known as Meta data that is data about data.

Data Name: Doctor Name

Definition: The doctor who want to gather information from patient.

Details: Data Type: Char First Name + Middle Name + Last Name.

Data Name: Patient Information

Definition: Total Information of the patients.

Details: Data Type: Char, Integer; P_Name, ID_No,Sex, Age, Address, Ph_no

Data Name: Treatment Information

Definition: The doctor who identify the dieses & treatment.

Details: Data Type: Char, P_ame, P_ID, Medicine, Advice.

Data Name: Accounts Information

Definition: Payment of visit fee, Dues, Advance.

Details: Data Type: Char, integer, P_Name, P_ID, Total bill, Payment, Dues, Advance, balance.

4.14 User Interface Design process

While developing the Student Information System, we use the following User Interface Design Process.

Figure 4.9 User Interface Design Process

4.14.1 User Interface Design principles

The following “User Interface Design principles” were considered while developing the software:

a) User Familiarity:

b) Consistency

c) Minimal Surprise

d) Recoverability

e) User guidance

f) User diversity

4.15 Some Snapshots of PMS

Main Window

Figure 4.10 Log in window

Figure 4.11 Data Entry Form

Figure 4.11 Data Entry Form

Figure 4.12 Data Report

Testing

5.1 Testing

Testing is a process of executing a program with the intent of finding errors

Ø A good test case is one that has a high probability of finding an as-yet undiscovered error

Ø A successful test is one that uncovers an as-yet undiscovered error

Ø Testing cannot show the absence of defects, it can only show that software errors are present

To ensure software quality we must need to test software. To accomplish testing for our software we have considered White Box Testing for Search patient module in this regard.

We can diagrammatically show different stags of a testing process in below:

Final operational test
Validation testing, does it meet the user’s expectation, black box test
System test
Validation test
Verification of system and overall program structure uses black box and limited white box
Integration testing
Test a module’s control structure uses white box techniques carried out by developer
Unit testing

Figure 5.1 the testing process

5.2 Classification of Testing

There are two basic type of testing. These are:

1) Static testing

2) Dynamic testing

5.2.1 Static testing

Static testing is related with inspecting the code. For this software, all the codes are reviewed several times.

5.2.2 Dynamic Testing

There are two types of dynamic testing. These are:

a) White box testing

b) Black box testing

5.2.2.1White box testing

In this type of testing all the lines are tested by executing the program. For “Patient Management System”, executing the program all the lines is tested. To perform white box testing, basis set testing is applied.

5.3 Basis set testing

Basis set testing is a testing method that is used to find the logical path of a module. A module is given below to Sell Products:

stmt.executeQuery (“select P_ID from Sum where P_ID = ‘”+jTextField1.getText()+”‘”);

if(!rs.next()) //1 {

JOptionPane.showMessageDialog (null, “ID does not match “,” Error”, JOptionPane.ERROR_MESSAGE); //2

Return ;

} //3

else

stmt.execute (“delete * from Sum1 where St_ID = ‘”+jTextField1.getText()+”‘”); //4

}//5

5.4 Flow Graph

We can draw flow graph for the module patient Register in below:

i

The distinct paths

Path-1

Path-2

5.5 Cyclomatic Complexity

Cyclometric complexity is the number of paths used in the graph:

Cyclometric complexity is calculated by the following equation:

V (G) = E – N + 2

= 5 – 5 + 2 Where,

= 2 V (G) = Cyclometric complexity of the graph.

E = Number of Edges.

N = Number of nodes.

5.6 Test Log

  • This is a log that records the tests applied and the results of each test
  • For a module this may look like a table
Conditions Expected results Actual results Comment
User-Name=1

Password= 01

False False Ignore
User-Name =A

Password= 1

True True Pass

Application

6.1 Problem Domain

We apply this system in the Japan Bangladesh Friendship Hospital, Dhaka where every patient will get their personal and dieses information using our System. It will be connected through network.

6.2 How it Works

Admin login: At first user open the software and gives His / Her Name and password. If invalid id or password be given then it cannot be access. And If valid id or password be given then it can be access.

Fig: Login page

Figure 6.1 Log in Form

Service

There are three types are available.

1. Patient Information

2. Treatment Information

3. Accounts Information

Figure 6.1 Code Form

Discussion and conclusions

7.1 Discussion

Maintenance

“Maintenance is the general process of changing a system after it has been delivered.” Our proposed Patient Management System is applied to the Japan Bangladesh Friendship Hospital.

Necessity of maintenance

Though software does not ware out, it needs maintenance for the following reasons:

1) It was delivered bugs. The bugs may be coding error, design error or analysis error.

2) The environment in which the software operates may change. For example: the operating system may change or hardware platform may change.

3) The customer requirement may change. For example: the software requires new features.

Therefore, software needs maintenance.

Several types of maintenance

There are three kinds of maintenance. These are:

1) Corrective Maintenance

2) Adaptive Maintenance

3) Perfective Maintenance

Corrective Maintenance

When bugs appear in the software, these bugs need to be correct. The process of removing bugs is corrective maintenance.

Adaptive Maintenance

When the environment of the software changes, the software must adapt with its environment. The process of adapting with environment is adapting maintenance.

Perfective Maintenance

When the customer requirement changes, the software must fulfill its customer requirement. To fulfill customer requirement is perfective maintenance

For “Patient Management System”, any one of the three maintenance will be carried out if necessary.

Iterative Development of Maintenance

Standard Development Process
Software Development
Update Requests
Change Analysis
Change Request

Ideally maintenance can be thought of as an iteration through a standard software development.

Figure7.1. Iterative Development of Maintenance

In “Patient Management System” We use this kind of Maintenance.

Maintenance as Fault Repair

In practical situation, the maintenance activity has to take place urgently to respond to customer problems. So, when problem occurs, we prefer “Maintenance as Fault Repair” process for “Patient Management System”. The process is shown below:

Fig: Maintenance as Fault Repair

Necessity for documentation

For the following reasons, software documentation is needed:

1) Software has no physical form. To give software physical form,

Documentation is necessary.

1) Software is abstract because they are intangible. We can tangible software by documenting it.

Documentation

Textual Documentation

We can textually document the software by writing comment in the code. Textual documentation is done when the developer writes the code.

Documentation providing manuals

We can document software by providing manuals. There are two types’ manuals. These are:

1) Developer manual

2) User manual

Developer manual

The manual, which is useful for the developer, is called developers manual.

User manual

As we’re new developer and we have not yet develop any big project such like that, we can’t fulfill user manual completely. But we ‘are trying to develop this. And we’ll develop this perfectly in the next version of this software.

System Requirements

Any person who want to run “Patient Management System” in his/her computer then he/she must have the following minimum software and hardware requirements.

Hardware Requirements

** Processor: 1.6 MHz

** RAM: 256 MB

** Hard Disk: 500 MB free memory

Software Requirements

** Object-Oriented Programming Language (C#)

** MS SQL Server

** Seagate Crystal Report

*