hospital management system documentaion2

  Maintaining patient’s prescription, medicine and diet advice details.

  Providing billing details for indoor/outdoor patients.

  Maintaining backup of data as per user requirements (between mentioned dates).

  If user forgets his/her password then it can be retrieved by hint question.

• In this project collection of data is from different pathology labs.

• Results of tests, prescription, precautions and diet advice will be automatically updated in the database.

• Related test reports, patient details report, prescription and billing reports can be generated as per user requirements

• User or Administrator can search a patient’s record by his/her name or their registration date.

• Patient’s diet advice can be provided in English.

1.        Overall Description

2.1)    Goals of proposed system

1. Planned approach towards working: - The working in the organization will be well planned and organized. The data will be stored properly in data stores, which will help in retrieval of information as well as its storage.

2. Accuracy: - The level of accuracy in the proposed system will be higher. All the operation would be done correctly and it ensures whatever information is coming from the centre is accurate.

3. Reliability: - The reliability of the proposed system will be high due to the above stated reasons. The reason for the increased reliability of the system is that now there would be proper storage of information.

4.  No Redundancy: - In the proposed system utmost care would be that no information is repeated anywhere, in storage or otherwise. This would assure economic use of storage space and consistency in the data stored.

5.  Immediate retrieval of information: - The main objective of proposed system is to provide for a quick and efficient retrieval of information. Any type of information would be available whenever the user requires.

6. Immediate storage of information: - In manual system there are many problems to store the largest amount of information.

7. Easy to Operate: - The system should be easy to operate and should be such that it can be developed within a short period of time and fit in the limited budget of the user.

2.2)    Background

A Hospital is a place where Patients come up for general diseases. Hospitals provide facilities like:-

  Consultation by Doctors on Diseases.

Diagnosis for diseases.

   Providing treatment facility.

  Facility for admitting Patients (providing beds, nursing, medicines etc.)

  Immunization for Patients/Children.

Various operational works that are done in a Hospital are:-

   Recording information about the Patients that come.

  Generating bills.

hospital management system

1.     Introduction

1.1)         Purpose

• The Software is for the automation of Hospital Management.

• It maintains two levels of users:-

 Administrator Level

 User Level

• The Software includes:-

  Maintaining Patient details.

   Providing Prescription, Precautions and Diet advice.

  Providing and maintaining all kinds of tests for a patient.

   Billing and Report generation.

1.2)         Scope

It can be used in any Hospital, Clinic, Dispensary or Pathology labs for maintaining Patient details and their test results.

1.3)   Technologies to be used

This project will be a desktop application to be developed in VB 6.0 having Ms Access as backend.

• Database Design
• Form Design
• Coding
• Testing
• Reporting Tool

1.4)         Overview

• Project is related to Hospital Management System.

• The project maintains two levels of users:-

 Administrator Level-Doctor

 User Level-Data Entry Operator

• Main facilities available in this project are:-

  Maintaining records of indoor/outdoor patients.

  Maintaining patients diagnosis details, advised tests to be done.

v X-Ray

v Urine Test

v Stool Test

v Sonography Test

v GastroscopyTest

v Colonoscopy Test

v Blood Test

v Biochemistry Test

  Providing different test facilities to a doctor for diagnosis of patients.

  Maintaining patient’s injection entry records.

USER DATAGRAM PROTOCOL

What UDP Does

UDP's only real task is to take data from higher-layer protocols and place it in UDP messages, which are then passed down to the Internet Protocol for transmission. The basic steps for transmission using UDP are:

   1. Higher-Layer Data Transfer: An application sends a message to the UDP software.

   2. UDP Message Encapsulation: The higher-layer message is encapsulated into the Data field of a UDP message. The headers of the UDP message are filled in, including the Source Port of the application that sent the data to UDP, and the Destination Port of the intended recipient. The checksum value may also be calculated.

   3. Transfer Message To IP: The UDP message is passed to IP for transmission.

And that's about it. Of course, on reception at the destination device this short procedure is reversed.

What UDP Does Not

In fact, UDP is so simple, that its operation is very often described in terms of what it does not do, instead of what it does. As a transport protocol, some of the most important things UDP does not do include the following:

    * UDP does not establish connections before sending data. It just packages it and… off it goes.

    * UDP does not provide acknowledgments to show that data was received.

    * UDP does not provide any guarantees that its messages will arrive.

    * UDP does not detect lost messages and retransmit them.

    * UDP does not ensure that data is received in the same order that they were sent.

    * UDP does not provide any mechanism to manage the flow of data between devices, or handle congestion.

UDP CHECKSUM CALCULATION

UDP CHECKSUM CALCULATION

The checksum is calculated over all the octets of the pseudo header, UDP header and data.

If the data contains an odd number of octets a pad, zero octet is added to the end of data.

The pseudo header and the pad are not transmitted with the packet.

In the example code,

u16 buff[] is an array containing all the octets in the UDP header and data.

u16 len_udp is the length (number of octets) of the UDP header and data.

BOOL padding is 1 if data has an even number of octets and 0 for an odd number.

u16 src_addr[4] and u16 dest_addr[4] are the IP source and destination address octets

Function: udp_sum_calc()

Description: Calculate UDP checksum

typedef unsigned short u16;

typedef unsigned long u32;

u16 udp_sum_calc(u16 len_udp, u16 src_addr[],u16 dest_addr[], BOOL padding, u16 buff[])

{

u16 prot_udp=17;

u16 padd=0;

u16 word16;

u32 sum;         

           

            // Find out if the length of data is even or odd number. If odd,

            // add a padding byte = 0 at the end of packet

            if (padding&1==1){

                        padd=1;

                        buff[len_udp]=0;

            }

           

            //initialize sum to zero

            sum=0;

           

            // make 16 bit words out of every two adjacent 8 bit words and

            // calculate the sum of all 16 vit words

            for (i=0;i

                        word16 =((buff[i]<<8)&0xFF00)+(buff[i+1]&0xFF);

                        sum = sum + (unsigned long)word16;

            }         

            // add the UDP pseudo header which contains the IP source and destinationn addresses

            for (i=0;i<4;i=i+2){

                        word16 =((src_addr[i]<<8)&0xFF00)+(src_addr[i+1]&0xFF);

                        sum=sum+word16;    

            }

            for (i=0;i<4;i=i+2){

                        word16 =((dest_addr[i]<<8)&0xFF00)+(dest_addr[i+1]&0xFF);

                        sum=sum+word16;    

            }

            // the protocol number and the length of the UDP packet

            sum = sum + prot_udp + len_udp;

            // keep only the last 16 bits of the 32 bit calculated sum and add the carries

            while (sum>>16)

                        sum = (sum & 0xFFFF)+(sum >> 16);

                       

            // Take the one's complement of sum

            sum = ~sum;

return ((u16) sum);

}

Here we give a simple example of the checksum calculation. You can find details about efficient implementation of the calculation in the [RFC 1071]. As an example, suppose that we have the following three 16-bit words:

0110011001100110

0101010101010101

0000111100001111

The sum of first of these 16-bit words is:

0110011001100110

0101010101010101

---------------------

1011101110111011

Adding the third word to the above sum gives

1011101110111011

0000111100001111

---------------------

1100101011001010

The 1's complement is obtained by converting all the 0s to 1s and converting all the 1s to 0s. Thus the 1's complement of the sum 1100101011001010 is 0011010100110101, which becomes the checksum. At the receiver, all four 16-bit words are added, including the checksum. If no errors are introduced into the segment, then clearly the sum at the receiver will be 1111111111111111. If one of the bits is a zero, then we know that errors have been introduced into the segment. In section 5.1, we'll see that the Internet checksum is not foolproof -- even if the sum equals 111111111111111, it is still possible that there are undetected errors in the segment.  For this reason, a number of protocols use more sophisticated error detection techniques than simple check summing.

Notice that this does not equate to making the number of 1's even or odd

0110011001100110

0101010101010101

0000111100001111

0011010100110101

----------------

EEEEOEEOEEEEOEEO