08-16-2017, 08:49 PM
Objective And Scope Of The Project
OBJECTIVE
Providing user friendly interface
To store all the information about the patient online.
Easy access of data
Easy maintenance
Maintaining data consistency
Providing better performance
Increasing the efficiency through automation
Proper authorization
Proper security
Providing timely information to the users
Theoretical Background:
E-Card allows for the storage of vital patient information and for the electronic access to a health care provider's data base. The flexibility of E-Card allows affiliated hospital sites and clinics with different computer systems to retrieve vital patient information from the same card. E-card relieves the patient from carrying their details with them by providing online access. Thus the E-card system can be beneficial for both the patient and doctors. E-Card is a challenging area, where one needs expertise in both domain and as well as technical understanding with hold on language used to implement the application. E-card is being used in western countries but this is a concept that needs to be implemented in India too. In the coming times, this facility will be available across India also. In the span of the development of this project, I studied software engineering concepts, technical language details and testing issues. I started with studying the existing system and then pin pointing to the specifications needed in the new system being developed. Later on I focused more on coding details. After the coding was complete, thorough testing was performed for verifying the system.
Definition Of Problem:
Statement About the Problem
In spite of boasting of million of Patients of India, it is seen that a number of patients have their report details, test reports. Of the diseases they suffered in the form of Files , Papers .
Patients have the problem that many times they forgot their reports that in the form of files bring out when they go to Hospital. As Most of the population in India lived in village and hospitals located in big cities . this leads to the problem for the pertinent , they have to again charge by the hospital for the their test. This leads to harassing for the patients in the form of fees and time consuming.
SYSTEM ANALYSIS AND DESIGN
EXISTING SYSTEM
The existing system is manual system and all the information about the patient s treatment is maintained on the patient s card. When the patient visits the hospital for treatment he/she is given a card indicating the date of visit, the name of the doctor giving the treatment, the check ups done, the name of the disease and the proper prescription. Thus the card contains the complete history of the patient. When the patient visits the hospital he/she has to carry all the reports and the card with him/her. The disadvantage is that the patient needs to carry his/her card with him/her every time. It may be the case that the patient gets ill on the way; when he/she is out of city and may not carry the card with him/her, in that case he/she may have to undergo all the tests again in the other hospital. Thus the treatment may be delayed.
PROPOSED SYSTEM OVERVIEW
In the proposed system, the patient s card gets computerized. Therefore it is know as an ELECTRONIC CARD. The patient s details will now be maintained through the computer system. It is just like the normal card that the patient gets when he/she visits for treatment. The benefit is that the electronic card can be accessed by the patient/Doctor anywhere across the world through INTERNET by just entering his/her Patient ID. Thus the doctor, he/she visits can get complete information about the patient s treatment by just entering the ID. This is thus the benefit of the e-card- the patient now doesn t need to carry all the reports with him/her.
Proper authorization will be done to take care of who is accessing the database; for example CMO, doctors, operator and patients. Proper security measures will be taken.
SYSTEM DESIGN
System design is the process of developing specifications for a candidate system that meet the criteria established in the system analysis. The plan of the project provides a review of the different modules in which the project is divided. The modules are designed and tested individually and then merged together to form an integrated project.
The different types of tables being used are:
1) Master tables 2) Transaction tables
(i) Country
(ii) State
(ii) City
(iv) Hospital
(v) Employee
(vi) Disease Group
(vii) Disease
(vii) Test Group
(ix) Test
(x) Patient
(xi) Company
(xii) Equipment
(xii) Visit
(xiv) User
(xv) User Type
(xvi) Order
(xvii) Order Details
(xvii) Disease Details
(xix) Test Details
The various roles through which the data flows used in the project are:
1) Admin
2) Operator
3) Doctor
4) CMO
5) Patient
SOFTWARE REQUIREMENT SPECIFICATION(SRS)
TABLE OF CONTENTS
1. Introduction
1.1 Purpose
1.2 Scope
1.3 Definitions, Acronyms, or Abbreviations
1.4 References
1.5 Overview
2. General Description
2.1 Product Perspective
2.2 Product Functions
2.3 User Characteristics
2.4 General Constraints
2.5 Assumptions
3. Specific Requirements
3.1 Functional Requirements
3.1.1 Introduction
3.1.2 Inputs
3.1.3 Processing
3.1.4 Outputs
3.1.5 Performance Requirements
3.1.6 Design Constraints
3.1.6.1 Standards Compliance
3.1.6.2 Hardware Limitations
3.1.7 Attributes
3.1.7.1 Security
3.1.7.2 Maintainability
3.1.8 Other Requirements
3.1.8.1 Database
3.1.8.2 Operations
3.1.8.3 Site Adaptation
3.2 External Interface Requirements
3.2.1 Usability Requirement
3.2.2 Reliability Requirement
3.2.3 Performance Requirement
3.2.4 Supportability Requirement
3.2.5 Design Constraints
3.2.6 Online User Documentation and Help System Requirements
3.2.7 Purchased Components
3.2.8 Interfaces
3.2.8.1 User Interfaces
3.2.8.2 Hardware Interfaces
3.2.8.3 Software Interfaces
3.2.8.4 Communication Interfaces
3.2.9 Licensing Requirements
3.2.10 Legal, Copyright and Other Notices
3.2.11 Applicable Standards
4. Supporting Information
1. Introduction
1.1 Purpose
The purpose of this Software Requirement Specification (SRS) is to
fully describe the behavior of the Hospital E-Card System being developed. It also describes the nonfunctional requirements, design constraints and other factors necessary to provide a complete and comprehensive description of the requirements.
1.2 Scope
This document is developed by Gunjeet herself. Good care has been taken to maintain consistency in the document as well as the application.
The patient records need to be maintained online and accessible at all times.
1.4 References
3) Introduction
4) Objective
5) System Analysis
6) Feasibility Study
7) Technologies Used
8) System Design
(i) Entities
(ii) ER-Diagrams
(ii) DFDs/Sequence Diagrams
9) Implementation
(i) Form Layouts
(ii) Technological Specifications
10) Testing
11) Appendix
12) Bibliography
1.5 Overview
The rest of the SRS is divided into different sections and sub-sections.
In context to each sub-section, details are given along with relevant formats and sample reports. All the references are enclosed. Also, for clear understanding of the concept and implementation ER-Model, DFDs, Designs of forms are also attached.
2. General Description
2.1 Product Perspective
This application is an independent product and doesn t depend on any
other application for its normal working. This software interfaces with the data-entry operator s keyboard and mouse. It makes usage of the standard QWERTY keyboard with special key combinations that are made available to the user to reduce the number of keystrokes that are required to effect common steps in data updation transactions. The mouse under usage is also the normal standardized three-button mouse or optical mouse. Also, this system requires a printer dotmatrix/inkjet/laser, as per the requirements for the generation of reports to be saved as hard copy or to be provided to the patients or otherwise.
2.2 Product Functions
This project requires automating the patient cards. For this the system has been analyzed and clearly understood. The patient records till date are maintained on the cards. We are required to make this computerized and also provide online access of the cards to the patient.
Providing user friendly interface
To store all the information about the patient online.
Easy access of data
Easy maintenance
Maintaining data consistency
Providing better performance
Increasing the efficiency through automation
Proper authorization
Proper security
Providing timely information to the users
2.3 User Characteristics
Administrator: Deep knowledge of computers as well as medical field.
Doctor/CMO/Patient: Computer-literate with minimum on 40-hour week hands-on training on workstation.
The data-entry Operators:
High school graduate frequently with one to two years additional academic training.
Selected for ability to deal with processes having medical terminology.
Highly motivated and conscientious.
Computer-literate with minimum on 40-hour week hands-on training on workstation.
Operators are not computer professionals.
System-to-operator interface design standards are general.
2.4 General Constraints
The Hospital E-Card System shall execute online. The said application is a server-side application and the product code shall be written in ASP.NET using C#.NET and VB.NET. The database will be managed in SQL Server. A standard QWERTY keyboard is associated with each workstation.
The application is allocated the responsibility for ensuring that only authorized data-entry operators, doctors, CMOs and patients can access the records and availability to anyone who has a computer and an internet connection.
2.5 Assumptions
This application is released with an implicit assumption that it is made to work online for storing and viewing patient records of various hospitals.
3. Specific Requirements
3.1 Functional Requirements
The function and performance specification for the system is divided into five major roles: Admin, Doctor, Operator, CMO and Patient. These functions can be accessed after going through the Login Screen on loading the Default page.
Get the full report here:
http://4shareddocument/sbfQLyXh/Project_..._amit.html