Scribd
Upload
0 views

Basic database schema HMS (1)

The document outlines a comprehensive database schema for a Hospital Management System (HMS) consisting of multiple tables, including Patient, Staff, Appointments, MedicalRecords, Billing, Payment, DischargeManagement, Pharmacy, Inventory, UserRoles, and StaffPermissions. It details the columns for each table, the relationships between them, and constraints to ensure data integrity. Additionally, it suggests enhancements such as audit logs, insurance information, and user authentication for improved functionality.

Uploaded by

aminaashraf1101
Copyright
© © All Rights Reserved
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
0 views

Basic database schema HMS (1)

The document outlines a comprehensive database schema for a Hospital Management System (HMS) consisting of multiple tables, including Patient, Staff, Appointments, MedicalRecords, Billing, Payment, DischargeManagement, Pharmacy, Inventory, UserRoles, and StaffPermissions. It details the columns for each table, the relationships between them, and constraints to ensure data integrity. Additionally, it suggests enhancements such as audit logs, insurance information, and user authentication for improved functionality.

Uploaded by

aminaashraf1101
Copyright
© © All Rights Reserved
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
You are on page 1/ 6

1.

Patient Table

 Columns:
o PatientID (PK)
o Name
o DateOfBirth
o Gender
o ContactInfo
o Address
o RegistrationDate

2. Staff Table

 Columns:
o StaffID (PK)
o Name
o Position
o Department
o ContactInfo
o RoleID (FK to UserRoles Table)

3. Appointments Table

 Columns:
o AppointmentID (PK)
o PatientID (FK to Patient Table)
o StaffID (FK to Staff Table, assuming staff members like doctors handle
appointments)
o AppointmentDate
o AppointmentTime
o Status (e.g., Scheduled, Completed, Canceled)

4. MedicalRecords Table

 Columns:
o RecordID (PK)
o PatientID (FK to Patient Table)
o StaffID (FK to Staff Table, to track who created the record)
o Diagnosis
o Treatment
o DateCreated

5. Billing Table

 Columns:
o BillingID (PK)
o PatientID (FK to Patient Table)
o AppointmentID (FK to Appointments Table, if billing is appointment-based)
o TotalAmount
o BillingDate
o Status (e.g., Paid, Pending)

6. Payment Table

 Columns:
o PaymentID (PK)
o BillingID (FK to Billing Table)
o PaymentAmount
o PaymentDate
o PaymentMethod (e.g., Cash, Credit, Insurance)

7. DischargeManagement Table

 Columns:
o DischargeID (PK)
o PatientID (FK to Patient Table)
o StaffID (FK to Staff Table, staff member managing the discharge)
o DischargeDate
o DischargeNotes

8. Pharmacy Table

 Columns:
o PharmacyID (PK)
o MedicineName
o Stock
o Price
o ExpiryDate

9. Inventory Table

 Columns:
o InventoryID (PK)
o ItemName
o Quantity
o ItemCategory (e.g., Equipment, Medicines, Supplies)
o LastUpdated

10. UserRoles Table

 Columns:
o RoleID (PK)
o RoleName (e.g., Doctor, Nurse, Pharmacist, Admin)
o Permissions

11. StaffPermissions Table


 Columns:
o StaffID (FK to Staff Table)
o PermissionID (FK to UserRoles
Table)
 This table manages many-to-many relationships between staff members and their
roles/permissions.

Relationships Overview

 One-to-Many:
o Patient to Appointments (One patient can have multiple appointments).
o Patient to MedicalRecords (One patient can have multiple medical records).
o Patient to Billing (One patient can have multiple billing entries).
o Billing to Payment (One billing entry can have multiple payments).
o Staff to DischargeManagement (One staff can handle multiple discharges).
 Many-to-Many:
o Staff to UserRoles (handled by StaffPermissions table).

Would you like me to further refine any specific part of this model?

4o

You said:

continue
ChatGPT said:

ChatGPT

To further elaborate on the physical database model, let’s add more details to the tables and
relationships, focusing on constraints, possible indexes, and additional columns that may be
useful for an efficient Hospital Management System (HMS).

12. Audit Logs Table (for tracking activities)

 Purpose: Logs important actions in the system for security and auditing purposes.
 Columns:
o LogID (PK)
o Action (e.g., "Create", "Update", "Delete")
o TableName (name of the table where the action occurred)
o RecordID (ID of the record affected)
o Timestamp
o PerformedBy (FK to StaffID in Staff Table)

Enhanced Relationships and Constraints


 Indexes:
o Add indexes to frequently queried columns such as PatientID in the
Appointments, MedicalRecords, and Billing tables.
o Add an index on AppointmentDate in the Appointments table for quick
searching by date.
o Consider adding a composite index on StaffID and Position in the Staff table,
if queries often filter on both.
 Foreign Key Constraints:
o Ensure foreign keys enforce referential integrity:
 PatientID in Appointments, MedicalRecords, Billing, and
DischargeManagement should reference the PatientID in the Patient
table.
 StaffID in Appointments, MedicalRecords, and DischargeManagement
should reference the StaffID in the Staff table.
 BillingID in Payment should reference BillingID in the Billing table.
 Relationship Type Constraints:
o In the Appointments table, set up a constraint for the Status column to ensure it
only accepts values like Scheduled, Completed, or Canceled.
o In the Billing and Payment tables, the Status column can be restricted to values
like Paid and Pending to track billing status.
 Composite Keys:
o For tables handling many-to-many relationships, such as StaffPermissions, use
a composite primary key of StaffID and PermissionID.

Example SQL Statements

Here are example SQL statements for creating some of the tables with primary keys, foreign
keys, and constraints:

sql
Copy code
CREATE TABLE Patient (
PatientID INT PRIMARY KEY,
Name VARCHAR(100),
DateOfBirth DATE,
Gender CHAR(1),
ContactInfo VARCHAR(100),
Address TEXT,
RegistrationDate DATE
);

CREATE TABLE Staff (


StaffID INT PRIMARY KEY,
Name VARCHAR(100),
Position VARCHAR(50),
Department VARCHAR(50),
ContactInfo VARCHAR(100),
RoleID INT,
FOREIGN KEY (RoleID) REFERENCES UserRoles(RoleID)
);
CREATE TABLE Appointments (
AppointmentID INT PRIMARY KEY,
PatientID INT,
StaffID INT,
AppointmentDate DATE,
AppointmentTime TIME,
Status VARCHAR(20) CHECK (Status IN ('Scheduled', 'Completed',
'Canceled')),
FOREIGN KEY (PatientID) REFERENCES Patient(PatientID),
FOREIGN KEY (StaffID) REFERENCES Staff(StaffID)
);

CREATE TABLE MedicalRecords (


RecordID INT PRIMARY KEY,
PatientID INT,
StaffID INT,
Diagnosis TEXT,
Treatment TEXT,
DateCreated DATE,
FOREIGN KEY (PatientID) REFERENCES Patient(PatientID),
FOREIGN KEY (StaffID) REFERENCES Staff(StaffID)
);

CREATE TABLE Billing (


BillingID INT PRIMARY KEY,
PatientID INT,
AppointmentID INT,
TotalAmount DECIMAL(10, 2),
BillingDate DATE,
Status VARCHAR(20) CHECK (Status IN ('Paid', 'Pending')),
FOREIGN KEY (PatientID) REFERENCES Patient(PatientID),
FOREIGN KEY (AppointmentID) REFERENCES Appointments(AppointmentID)
);

Additional Tables for Enhanced Functionality

1. Insurance Table (if applicable):


o Purpose: Stores patient insurance information.
o Columns:
 InsuranceID (PK)
 PatientID (FK to Patient Table)
 InsuranceProvider
 PolicyNumber
 CoverageAmount
 ExpiryDate
2. User Table (for user authentication)
o Columns:
 UserID (PK)
 Username (unique)
 PasswordHash (for secure password storage)
 StaffID (FK to Staff Table)
3. RolePermissions Table (defining permissions for each role):
o Purpose: Helps manage what actions each role is allowed to perform within the
system.
o Columns:
 RoleID (FK to UserRoles Table)
 Permission (e.g., "View Medical Records", "Manage Appointments")
o Composite primary key: RoleID, Permission.

Many-to-Many Relationships

The UserRoles and RolePermissions tables create a flexible system for managing permissions,
allowing multiple staff members to be assigned roles with specific permissions.

Summary of Relationships

 One-to-Many:
o Patient ↔ Appointments
o Patient ↔ MedicalRecords
o Patient ↔ Billing
o Billing ↔ Payment
o Staff ↔ DischargeManagement
o UserRoles ↔ Staff
o Pharmacy ↔ Inventory (if managing stock levels of each medicine individually)
 Many-to-Many:
o Staff ↔ Permissions (via RolePermissions table)

You might also like