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
|
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
|
|
|
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
|
||
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
|
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
|
|||||||||||||
|
|
|
|||||||||||
|
|
||||||||||||
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:
|
|
|
|
|
|
|
|
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
|
|
|
|
|
|
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
*