Scribd
Upload
123 views2 pages

Hospital Management System

This document describes 11 database tables that would be used to store information for a hospital management system. The tables store data about departments, doctors, patients, procedures, and more. Each table has a defined purpose and set of constraints to ensure data integrity. Relationships between tables are defined to link related data points as patients move between check-ins, admissions, operations and discharge.

Uploaded by

Lester King Cabuay
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
123 views2 pages

Hospital Management System

This document describes 11 database tables that would be used to store information for a hospital management system. The tables store data about departments, doctors, patients, procedures, and more. Each table has a defined purpose and set of constraints to ensure data integrity. Relationships between tables are defined to link related data points as patients move between check-ins, admissions, operations and discharge.

Uploaded by

Lester King Cabuay
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
You are on page 1/ 2

1. DEPARTMENT: This table consists of details about the various departments in the hospital.

The
information stored in this table includes department name, department location, and facilities
available in that department. Constraint: Department name will be unique for each department.

2. ALL_DOCTORS: This table stores information about all the doctors working for the hospital and
the departments they are associated with. Each doctor is given an identity number starting with DR
or DC prefixes only. Constraint: Identity number is unique for each doctor and the corresponding
department should exist in DEPARTMENT table.

3. DOC_REG: This table stores details of regular doctors working in the hospital. Doctors are
referred to by their doctor number. This table also stores personal details of doctors like name,
qualification, address, phone number, salary, date of joining, etc. Constraint: Doctor’s number
entered should contain DR only as a prefix and must exist in ALL_DOCTORS table.

4. DOC_ON_CALL: This table stores details of doctors called by hospital when additional doctors
are required. Doctors are referred to by their doctor number. Other personal details like name,
qualification, fees per call, payment due, address, phone number, etc., are also stored. Constraint:
Doctor’s number entered should contain DC only as a prefix and must exist in ALL_DOCTORS
table.

5. PAT_ENTRY: The record in this table is created when any patient arrives in the hospital for a
check up. When patient arrives, a patient number is generated which acts as a primary key. Other
details like name, age, sex, address, city, phone number, entry date, name of the doctor referred to,
diagnosis, and department name are also stored. After storing the necessary details patient is sent
to the doctor for check up. Constraint: Patient number should begin with prefix PT. Sex should be M
or F only. Doctor’s name and department referred must exist.

6. PAT_CHKUP: This table stores the details about the patients who get treatment from the doctor
referred to. Details like patient number from patient entry table, doctor number, date of check up,
diagnosis, and treatment are stored. One more field status is used to indicate whether patient is
admitted, referred for operation or is a regular patient to the hospital. If patient is admitted, further
details are stored in PAT_ADMIT table. If patient is referred for operation, the further details are
stored in PAT_OPR table and if patient is a regular patient to the hospital, the further details are
stored in PAT_REG table. Constraint: Patient number should exist in PAT_ENTRY table and it
should be unique.

7. PAT_ADMIT: When patient is admitted, his/her related details are stored in this table. Information
stored includes patient number, advance payment, mode of payment, room number, department,
date of admission, initial condition, diagnosis, treatment, number of the doctor under whom
treatment is done, attendant name, etc. Constraint: Patient number should exist in PAT_ENTRY
table. Department, doctor number, room number must be valid.

8. PAT_DIS: An entry is made in this table whenever a patient gets discharged from the hospital.
Each entry includes details like patient number, treatment given, treatment advice, payment made,
mode of payment, date of discharge, etc. Constraint: Patient number should exist in PAT_ENTRY
table.

9. PAT_REG: Details of regular patients are stored in this table. Information stored includes date of
visit, diagnosis, treatment, medicine recommended, status of treatment, etc. Constraint: Patient
number should exist in patient entry table. There can be multiple entries of one patient as patient
might be visiting hospital repeatedly for checkup and there will be entry for patient’s each visit.
10. PAT_OPR: If patient is operated in the hospital, his/her details are stored in this table.
Information stored includes patient number, date of admission, date of operation, number of the
doctor who conducted the operation, number of the operation theater in which operation was carried
out, type of operation, patient’s condition before and after operation, treatment advice, etc.
Constraint: Patient number should exist in PAT_ENTRY table. Department, doctor number should
exist or should be valid.

11. ROOM_DETAILS: It contains details of all rooms in the hospital. The details stored in this table
include room number, room type (general or private), status (whether occupied or not), if occupied,
then patient number, patient name, charges per day, etc. Constraint: Room number should be
unique. Room type can only be G or P and status can only be Y or N E-R Diagram Relational
Database Schema for Case Study The relational database schema for Hospital Management
database is as follows: 

You might also like

pFad - Phonifier reborn

Pfad - The Proxy pFad of © 2024 Garber Painting. All rights reserved.

Note: This service is not intended for secure transactions such as banking, social media, email, or purchasing. Use at your own risk. We assume no liability whatsoever for broken pages.


Alternative Proxies:

Alternative Proxy

pFad Proxy

pFad v3 Proxy

pFad v4 Proxy