Python Project: Hospital Management System for Efficient Operations
VerifiedAdded on 2022/09/01
|14
|3884
|38
Project
AI Summary
This document details a Python-based hospital management system project. The system, developed using Python, Django, and a SQL database, allows users to perform tasks such as signing up, logging in, checking staff availability, patient registration, and generating unique patient IDs. It includes functionalities for patient search, appointment booking, cancellation, and modification, prescription management, and test result display. The project utilizes Django-rest-framework (DRF) for API creation, employing REST architecture for data handling and ensuring data protection. The application is designed with a user-centric approach, focusing on synchronous operations for appointment management. Implementation involves Agile project management principles, with a focus on ERD design, database models, and the use of libraries like requests, Django countries, and Psycopg2 binary. The system is deployed on Heroku, with the SQLite database data transferred to a PostgreSQL database. The project aims to enhance hospital operations through efficient patient and staff management.

Hospital Management Website 1
Hospital Management Website.
by(Student Name)
Course Title:
Name of Professor
Name of the School:
Location of school:
Date
A Hospital Management System
Hospital Management Website.
by(Student Name)
Course Title:
Name of Professor
Name of the School:
Location of school:
Date
A Hospital Management System
Secure Best Marks with AI Grader
Need help grading? Try our AI Grader for instant feedback on your assignments.

Hospital Management Website 2
This is a hospital management system for a hospital. The goal is for the users of this
website to access different hospital functionalities, the tasks range from signing up and logging
in to the application, checking the availability of a nurse or of a general practitioner, checking the
nurses and general practitioners on duty on specific days, registration of patients and generation
of unique patient identities, to search and find patients. The patient search functionality should
provide the unique patient details, the patient details are the unique ID, date of birth, name and
the patient’s address. The patient should be able to book, cancel or change an appointment on the
system. Booking of appointments is based on the availability of a general practitioner or nurse
and availability of the patient to be attended to, in cases of emergencies patients can book and be
attended to immediately. Prescriptions given by the doctors should be extended to the patient, the
receptionist should also be able to communicate to patients and attend to their requests on
approval of the patient’s doctor. A patient can for example request for an extension of a
painkiller prescription, the receptionist will then consult with the doctor and extend the
prescription.
To build this server-side application, Python programming language will be used, Heroku
will be used to host the server-side application and a SQL database will be used. The SQLite
database will be used in the application, SQLite comes out of the box with the Django web
framework ("How to migrate data from SQLite to PostgreSQL in Django - DEV Community 👩👩 👩💻
", 2019)💻 . Django-rest-framework(DRF) shall be used to create the Application Programme
Interface(API) for the application, the API will enable the patients to book, cancel or postpone
appointments, general practitioners, nurses and receptionists to show the days they will be
available and to create the prescriptions. The API is an interface that allows the client to
communicate with the server, it allows the hospital to expose their services to the clients and
This is a hospital management system for a hospital. The goal is for the users of this
website to access different hospital functionalities, the tasks range from signing up and logging
in to the application, checking the availability of a nurse or of a general practitioner, checking the
nurses and general practitioners on duty on specific days, registration of patients and generation
of unique patient identities, to search and find patients. The patient search functionality should
provide the unique patient details, the patient details are the unique ID, date of birth, name and
the patient’s address. The patient should be able to book, cancel or change an appointment on the
system. Booking of appointments is based on the availability of a general practitioner or nurse
and availability of the patient to be attended to, in cases of emergencies patients can book and be
attended to immediately. Prescriptions given by the doctors should be extended to the patient, the
receptionist should also be able to communicate to patients and attend to their requests on
approval of the patient’s doctor. A patient can for example request for an extension of a
painkiller prescription, the receptionist will then consult with the doctor and extend the
prescription.
To build this server-side application, Python programming language will be used, Heroku
will be used to host the server-side application and a SQL database will be used. The SQLite
database will be used in the application, SQLite comes out of the box with the Django web
framework ("How to migrate data from SQLite to PostgreSQL in Django - DEV Community 👩👩 👩💻
", 2019)💻 . Django-rest-framework(DRF) shall be used to create the Application Programme
Interface(API) for the application, the API will enable the patients to book, cancel or postpone
appointments, general practitioners, nurses and receptionists to show the days they will be
available and to create the prescriptions. The API is an interface that allows the client to
communicate with the server, it allows the hospital to expose their services to the clients and

Hospital Management Website 3
staff (Rouse, 2019). In this web application, the API will implement different methods to make
services available to its clients, the API will allow data to be used more efficiently and in an
easy manner (Sleter, 2014). Our API will ensure data protection, data will be protected and
access levels will be implemented, not everyone will be able to access all the data, only
permitted people will be able to access the API. Our choice of DRF for the API is due to its
speed in implementation, out of the box security features and flexibility (Guzman, 2019). The
API will follow a Representational State Transfer(REST) architecture. Django is the python
framework that will be used, DRF is a subset of Django, it follows the same principles and is
installed in a Django application for the purposes of creation of the REST API. REST API is
preferred due to being stateless, cacheable and having a uniform interface (Andrew, 2014). The
choice of rest is also due to REST implementing methods that make it easy to query, to create
you use the POST method, to remove you use the DELETE method, to retrieve you use the GET
method and to edit you use the PUT or PATCH methods (Lahoti, 2018). This makes it easy to
query data, create data, analyze and interpret data. REST also uses JavaScript Object Notation
(JSON) data type which formats data in a minimal and readable form. JSON is used for
communication between the client and the server (Farcic, 2014).
Heroku will be the cloud service provider, to run the application on different physical
computers it needs to be available on the cloud. Heroku will be the provider of the cloud
services, it will also handle the load balancing to ensure the services can be accessed by many
clients at the same time. The data will be stored on a HeroquPostgreSQL database once it is
deployed to the cloud. Load balancing will ensure the services are efficiently accessed by
multiple users logging in and using the services simultaneously. To deploy our application the
SQLite database will have to transfer the data to a PostgreSQL database. For the client to
staff (Rouse, 2019). In this web application, the API will implement different methods to make
services available to its clients, the API will allow data to be used more efficiently and in an
easy manner (Sleter, 2014). Our API will ensure data protection, data will be protected and
access levels will be implemented, not everyone will be able to access all the data, only
permitted people will be able to access the API. Our choice of DRF for the API is due to its
speed in implementation, out of the box security features and flexibility (Guzman, 2019). The
API will follow a Representational State Transfer(REST) architecture. Django is the python
framework that will be used, DRF is a subset of Django, it follows the same principles and is
installed in a Django application for the purposes of creation of the REST API. REST API is
preferred due to being stateless, cacheable and having a uniform interface (Andrew, 2014). The
choice of rest is also due to REST implementing methods that make it easy to query, to create
you use the POST method, to remove you use the DELETE method, to retrieve you use the GET
method and to edit you use the PUT or PATCH methods (Lahoti, 2018). This makes it easy to
query data, create data, analyze and interpret data. REST also uses JavaScript Object Notation
(JSON) data type which formats data in a minimal and readable form. JSON is used for
communication between the client and the server (Farcic, 2014).
Heroku will be the cloud service provider, to run the application on different physical
computers it needs to be available on the cloud. Heroku will be the provider of the cloud
services, it will also handle the load balancing to ensure the services can be accessed by many
clients at the same time. The data will be stored on a HeroquPostgreSQL database once it is
deployed to the cloud. Load balancing will ensure the services are efficiently accessed by
multiple users logging in and using the services simultaneously. To deploy our application the
SQLite database will have to transfer the data to a PostgreSQL database. For the client to

Hospital Management Website 4
communicate with the server they need an internet connection, once a local client has signed up,
if they’re patients they can make, cancel and postpone bookings from their computer or phone
from anywhere. Heroku ensures that general practitioners and nurses can see the bookings made
even without reporting to work.
Plan and Design
Dynamic application development involves developing applications which can handle
changing information. A hospital management system should be able to handle the constantly
changing client information. The information should also be accessible from anywhere and
updated synchronously (Stringelflow, 2017). We need synchronous functionality for making,
cancelling and postponing appointments. Both the patients and GP operate on the same cycle,
this prevents clashes on the calendar, synchronous ensures that the command that is initiated first
is completed before moving on to the next.
The design of this application is with a user in mind, the end-user for purposes of this
report is the client, the client computer is the device used by the client to access the system.
The application will be hosted on a server, application hosting will allow the hospital
management website to be stored in cloud infrastructure, it can, therefore, be accessed globally
over the internet.
A user will sign up to create an account, once the user signs up the user will be created in
the account. The user signup form will take in the username, email, date of birth, password and
phone number. Once the user has signed up they can now log in to the system, the username and
password are needed to login to the system if the two don’t match the user can’t sign up to the
system. If the user has forgotten their password there is an option to reset the password. After the
user is authenticated, the user can now access the application’s features, to check the availability
communicate with the server they need an internet connection, once a local client has signed up,
if they’re patients they can make, cancel and postpone bookings from their computer or phone
from anywhere. Heroku ensures that general practitioners and nurses can see the bookings made
even without reporting to work.
Plan and Design
Dynamic application development involves developing applications which can handle
changing information. A hospital management system should be able to handle the constantly
changing client information. The information should also be accessible from anywhere and
updated synchronously (Stringelflow, 2017). We need synchronous functionality for making,
cancelling and postponing appointments. Both the patients and GP operate on the same cycle,
this prevents clashes on the calendar, synchronous ensures that the command that is initiated first
is completed before moving on to the next.
The design of this application is with a user in mind, the end-user for purposes of this
report is the client, the client computer is the device used by the client to access the system.
The application will be hosted on a server, application hosting will allow the hospital
management website to be stored in cloud infrastructure, it can, therefore, be accessed globally
over the internet.
A user will sign up to create an account, once the user signs up the user will be created in
the account. The user signup form will take in the username, email, date of birth, password and
phone number. Once the user has signed up they can now log in to the system, the username and
password are needed to login to the system if the two don’t match the user can’t sign up to the
system. If the user has forgotten their password there is an option to reset the password. After the
user is authenticated, the user can now access the application’s features, to check the availability
Secure Best Marks with AI Grader
Need help grading? Try our AI Grader for instant feedback on your assignments.

Hospital Management Website 5
of a GP or nurse the users will look at the GP’s or nurse’s profile, to register as a patient the user
will complete a form. The patient form takes in the patient name, identity number, patient
allergies, assigned GP’s, pre-existing medical conditions and next of kin. A unique patient ID
will be generated upon the patient creating their profile. Patients will be able to update their
profile whenever they need to. Both patients and GP’s should be able to book, change or cancel
appointments. A GP can confirm a booking but later change it due to emergencies, they may
decide to cancel or postpone in liaise with the customer. The receptionist should be able to
extend a prescription.
Implementation
This application is primarily built in python, in this stage, I will focus on the
implementation of the system. The application uses several python libraries and packages, the
requests library is used to send HTTP requests using Python. When you type a URL on a web
browser it then returns information on the web page, this is an example of a request. The requests
library sends API requests, the requests verbs are GET to request data, PUT/PATCH requests to
modify data, POST request to create data and DELETE requests to remove data. Django
countries is a Django package used to give a list of all countries, phone numbers is a python
package that ensures only valid phone numbers are input by the clients, it does phone number
validation by verifying against telcos. Redis is used as a message broker, it’s an open-source
library, Redis makes it fast to transfer messages (Gorgia, 2018). Psycopg2 binary is a python
package that is used as a PostgreSQL adapter, it matches python data types to PostgreSQL
understandable types.
To design this application I followed agile project management principles, I had clearly
defined the steps to build the software (Westland, 2020). The steps were clearly defining the
of a GP or nurse the users will look at the GP’s or nurse’s profile, to register as a patient the user
will complete a form. The patient form takes in the patient name, identity number, patient
allergies, assigned GP’s, pre-existing medical conditions and next of kin. A unique patient ID
will be generated upon the patient creating their profile. Patients will be able to update their
profile whenever they need to. Both patients and GP’s should be able to book, change or cancel
appointments. A GP can confirm a booking but later change it due to emergencies, they may
decide to cancel or postpone in liaise with the customer. The receptionist should be able to
extend a prescription.
Implementation
This application is primarily built in python, in this stage, I will focus on the
implementation of the system. The application uses several python libraries and packages, the
requests library is used to send HTTP requests using Python. When you type a URL on a web
browser it then returns information on the web page, this is an example of a request. The requests
library sends API requests, the requests verbs are GET to request data, PUT/PATCH requests to
modify data, POST request to create data and DELETE requests to remove data. Django
countries is a Django package used to give a list of all countries, phone numbers is a python
package that ensures only valid phone numbers are input by the clients, it does phone number
validation by verifying against telcos. Redis is used as a message broker, it’s an open-source
library, Redis makes it fast to transfer messages (Gorgia, 2018). Psycopg2 binary is a python
package that is used as a PostgreSQL adapter, it matches python data types to PostgreSQL
understandable types.
To design this application I followed agile project management principles, I had clearly
defined the steps to build the software (Westland, 2020). The steps were clearly defining the

Hospital Management Website 6
purpose the software is to meet, the core purpose was to ensure communication between patients
and staff of a hospital, the communication is to ensure clients can make, cancel and postpone
bookings, receive prescriptions and request prescription extensions and check availability of
nurses and GP’s. To achieve this, I needed an API as the core of the system, the API is
developed in DRF a subset of Django framework. I also needed a database to persist the data for
future retrieval. Developing the Enterprise Relationship Diagram (ERD) was the first
implementation step. The ERD shows the relationships of components of data stored in a
database (Smartdraw.com, 2019). The ERD shows the logical relationships or database structure.
An ERD visualizes how the information will be displayed, it shows how the information
provided is related, how the objects relate in the database (Visual-paradigm.com, 2019). Our
project will have five database tables, we will have the user table, the patients, staff, booking and
prescriptions table. The user table is the table that facilitates the sign-up and logging in, it has
username field a character field maximum length 255 and it’s compulsory, email a character
field, date of birth date is picked from the system using pythons inbuilt DateTime package,
password a character field and phone number a character field with a maximum length of 20.
The patient’s table has patients details, the patient name field is a character field with a
maximum length of 100, identity number is an integer field that takes the patient’s national
identity details, patient allergies is a text field where patients input their allergies, it’s not a
compulsory field, assigned GP’s is a choice field that isn’t compulsory, if a patient has an
assigned GP they can select them from a list the table has a foreign key(FK) to the staff table,
pre-existing medical conditions is an optional text field where the patients can input existing
conditions to make it easy for the doctor and next of kin field which is an optional character
field. The Staff table has the staff name which is a character field maximum length 100, the staff
purpose the software is to meet, the core purpose was to ensure communication between patients
and staff of a hospital, the communication is to ensure clients can make, cancel and postpone
bookings, receive prescriptions and request prescription extensions and check availability of
nurses and GP’s. To achieve this, I needed an API as the core of the system, the API is
developed in DRF a subset of Django framework. I also needed a database to persist the data for
future retrieval. Developing the Enterprise Relationship Diagram (ERD) was the first
implementation step. The ERD shows the relationships of components of data stored in a
database (Smartdraw.com, 2019). The ERD shows the logical relationships or database structure.
An ERD visualizes how the information will be displayed, it shows how the information
provided is related, how the objects relate in the database (Visual-paradigm.com, 2019). Our
project will have five database tables, we will have the user table, the patients, staff, booking and
prescriptions table. The user table is the table that facilitates the sign-up and logging in, it has
username field a character field maximum length 255 and it’s compulsory, email a character
field, date of birth date is picked from the system using pythons inbuilt DateTime package,
password a character field and phone number a character field with a maximum length of 20.
The patient’s table has patients details, the patient name field is a character field with a
maximum length of 100, identity number is an integer field that takes the patient’s national
identity details, patient allergies is a text field where patients input their allergies, it’s not a
compulsory field, assigned GP’s is a choice field that isn’t compulsory, if a patient has an
assigned GP they can select them from a list the table has a foreign key(FK) to the staff table,
pre-existing medical conditions is an optional text field where the patients can input existing
conditions to make it easy for the doctor and next of kin field which is an optional character
field. The Staff table has the staff name which is a character field maximum length 100, the staff

Hospital Management Website 7
roles which is a choice field we will have three choices receptionist, GP and nurses, the staff
number will also be a field, calendar field will be a character field. The bookings table is the
table where a booking is handled, it has a booking date field, patient name field which is a FK to
the patient’s table, a staff name field which is a FK to the staff table, urgency field which is a
choices field choosing from very urgent, mild urgency, normal and emergency. The prescriptions
table is a table that has the medicine available and doctors instructions, it will have a patient
name field which is a FK to the patient’s table, a staff name field which is a FK to the staff table,
prescription field which is a text field and a staff responsible field which is a character field.
The database models define how data is stored, for this application we used relational
models. In relational models data is stored in tables, the relational model has set the base for use
of structured query language (SQL). The relational model has been in use since it was introduced
in 1970 by C.F. Codd (Whatt, 2017). We had several SQL databases to select from, the databases
were MySQL, PostgreSQL, Microsoft SQL, Oracle and SQLite databases. MySQL is the most
used SQL database, the choice not to use it is based on it no longer being open source, to use
MySQL in the cloud it meant having to pay, SQLite has been used in the project and PostgreSQL
has been used on Heroku. SQLite can only be used on local devices, unlike PostgreSQL it can’t
be used over the internet. It is preferred for this project because it is lightweight it doesn’t use
much of computer resources, it emphasizes efficiency, speed and simplicity. To use our
application on Heroku we transfer it to PostgreSQL.
The models decide what data types are input, they prevent users from inputting invalid
data and make it easier to input data, when you have an integer field the data can only be an
integer. In addition to the different fields unique to every field, every table will have a created_at
and updated_at field. The created_at field will show the time a record is created the updated_at
roles which is a choice field we will have three choices receptionist, GP and nurses, the staff
number will also be a field, calendar field will be a character field. The bookings table is the
table where a booking is handled, it has a booking date field, patient name field which is a FK to
the patient’s table, a staff name field which is a FK to the staff table, urgency field which is a
choices field choosing from very urgent, mild urgency, normal and emergency. The prescriptions
table is a table that has the medicine available and doctors instructions, it will have a patient
name field which is a FK to the patient’s table, a staff name field which is a FK to the staff table,
prescription field which is a text field and a staff responsible field which is a character field.
The database models define how data is stored, for this application we used relational
models. In relational models data is stored in tables, the relational model has set the base for use
of structured query language (SQL). The relational model has been in use since it was introduced
in 1970 by C.F. Codd (Whatt, 2017). We had several SQL databases to select from, the databases
were MySQL, PostgreSQL, Microsoft SQL, Oracle and SQLite databases. MySQL is the most
used SQL database, the choice not to use it is based on it no longer being open source, to use
MySQL in the cloud it meant having to pay, SQLite has been used in the project and PostgreSQL
has been used on Heroku. SQLite can only be used on local devices, unlike PostgreSQL it can’t
be used over the internet. It is preferred for this project because it is lightweight it doesn’t use
much of computer resources, it emphasizes efficiency, speed and simplicity. To use our
application on Heroku we transfer it to PostgreSQL.
The models decide what data types are input, they prevent users from inputting invalid
data and make it easier to input data, when you have an integer field the data can only be an
integer. In addition to the different fields unique to every field, every table will have a created_at
and updated_at field. The created_at field will show the time a record is created the updated_at
Paraphrase This Document
Need a fresh take? Get an instant paraphrase of this document with our AI Paraphraser

Hospital Management Website 8
will show the most recent time changes are made to a model, they’re fields that automatically
fill, users don’t have to input the times. The fields won’t be visible to the clients of the
application.
The API is built using DRF. The DRF runs in a virtual environment, to start development
of the application we activate a virtual environment using the commands:
python3 -m venv venv
source venv/bin/activate
The above command installs and activates a virtual environment called venv. Once in a virtual
environment, you install Django and DjangoRestFramework into venv using the commands
below.
pip install django
pip install djangorestframework
To set up a new project and new application the following commands will be used.
django-admin startproject healthmgt . # Ensure a trailing full stop '.' character
cd healthmgt
django-admin startapp healthmgtapp
cd ..
Once you have followed all the steps above, you should be able to run the naked project to
confirm it’s working. You will run the local server by running:
python manage.py runserver 8000
This ensures that the project is running on the localhost and on port 8000. After confirming the
project is running well, you will run commands to make migrations and afterwards create a
superuser. The superuser will enable you login to Django admin, Django admin is necessary for
will show the most recent time changes are made to a model, they’re fields that automatically
fill, users don’t have to input the times. The fields won’t be visible to the clients of the
application.
The API is built using DRF. The DRF runs in a virtual environment, to start development
of the application we activate a virtual environment using the commands:
python3 -m venv venv
source venv/bin/activate
The above command installs and activates a virtual environment called venv. Once in a virtual
environment, you install Django and DjangoRestFramework into venv using the commands
below.
pip install django
pip install djangorestframework
To set up a new project and new application the following commands will be used.
django-admin startproject healthmgt . # Ensure a trailing full stop '.' character
cd healthmgt
django-admin startapp healthmgtapp
cd ..
Once you have followed all the steps above, you should be able to run the naked project to
confirm it’s working. You will run the local server by running:
python manage.py runserver 8000
This ensures that the project is running on the localhost and on port 8000. After confirming the
project is running well, you will run commands to make migrations and afterwards create a
superuser. The superuser will enable you login to Django admin, Django admin is necessary for

Hospital Management Website 9
performing some of the Admin duties and for testing the application. Once you run migrations a
db.SQLite3 file will be created, it is the database file.
python manage.py makemigrations
python manage.py migrate
python manage.py createsuperuser
Username (leave blank to use 'k19'):
Email address: x@ymail.com
Password: xxxxxxx
Password (again): xxxxxxx
Superuser created successfully.
The newly created Django app has views.py, admin.py, models.py and apps.py files.
Once the files are created the API functionality is created in the views.py, the admin.py is where
admins are registered for access via the localhost admin, the models.py is where the models are.
In the models.py we import:
from django.db import models
The models module helps to create models, the models have been created in classes: each table
with a different class. An example of a database table is below, this is the User models table:
class User(models.Model):
username = models.CharField(max_length=255, null=True, blank=True)
email = models.CharField(max_length=70, null=True, blank=True)
phonenumber = models.CharField(max_length=100, null=True, blank=True)
dob = models.CharField(max_length=70, null=True, blank=True)
country = CountryField(default='KE')
password = models.CharField(max_length=35, null=True, blank=True)
created_at = models.DateTimeField(auto_now_add=True, null=True, blank=True)
updated_at = models.DateTimeField(auto_now=True, null=True, blank=True)
performing some of the Admin duties and for testing the application. Once you run migrations a
db.SQLite3 file will be created, it is the database file.
python manage.py makemigrations
python manage.py migrate
python manage.py createsuperuser
Username (leave blank to use 'k19'):
Email address: x@ymail.com
Password: xxxxxxx
Password (again): xxxxxxx
Superuser created successfully.
The newly created Django app has views.py, admin.py, models.py and apps.py files.
Once the files are created the API functionality is created in the views.py, the admin.py is where
admins are registered for access via the localhost admin, the models.py is where the models are.
In the models.py we import:
from django.db import models
The models module helps to create models, the models have been created in classes: each table
with a different class. An example of a database table is below, this is the User models table:
class User(models.Model):
username = models.CharField(max_length=255, null=True, blank=True)
email = models.CharField(max_length=70, null=True, blank=True)
phonenumber = models.CharField(max_length=100, null=True, blank=True)
dob = models.CharField(max_length=70, null=True, blank=True)
country = CountryField(default='KE')
password = models.CharField(max_length=35, null=True, blank=True)
created_at = models.DateTimeField(auto_now_add=True, null=True, blank=True)
updated_at = models.DateTimeField(auto_now=True, null=True, blank=True)

Hospital Management Website 10
Views.py is where the API calls are made, it’s a common convention in python for a view
file to be handling the requests, requests, in this case, GET, PUT, PATCH, DELETE and POST
requests are made in the views.py file. A serializer.py file will also be created, this is to allow
conversion of complex data types into types that Python understands. The Python data types can
easily be rendered into JSON or XML types. To use serializers we import them as below:
from rest_framework import serializers
Once we have imported serializers the model fields can be serialized. For this project, we shall
use view sets in DRF, once the models have been serialized. This will enable the creation of
users and getting users. The queryset gets all the objects in the User models whereas the
serializer_class gets all the serialized data. At the top of the views.py, you have to import the
userSerializers and User model classes to be able to use them in the views. Using viewsets keeps
the logic well organized and concise, the logic can, however, be broken into individual views.
class UserAPIView(viewsets.ModelViewSet):
queryset = User.objects.all()
serializer_class = userSerializers
http_method_names = ['get', 'post']
The url.py file lets you decide your uniform resource locator(URL’s) with no limitations,
in Django settings the urls.py comes as below, you can, however, make changes to it to suit your
needs.
from django.contrib import admin
from django.urls import path
urlpatterns = [
path('admin/', admin.site.urls),
]
Views.py is where the API calls are made, it’s a common convention in python for a view
file to be handling the requests, requests, in this case, GET, PUT, PATCH, DELETE and POST
requests are made in the views.py file. A serializer.py file will also be created, this is to allow
conversion of complex data types into types that Python understands. The Python data types can
easily be rendered into JSON or XML types. To use serializers we import them as below:
from rest_framework import serializers
Once we have imported serializers the model fields can be serialized. For this project, we shall
use view sets in DRF, once the models have been serialized. This will enable the creation of
users and getting users. The queryset gets all the objects in the User models whereas the
serializer_class gets all the serialized data. At the top of the views.py, you have to import the
userSerializers and User model classes to be able to use them in the views. Using viewsets keeps
the logic well organized and concise, the logic can, however, be broken into individual views.
class UserAPIView(viewsets.ModelViewSet):
queryset = User.objects.all()
serializer_class = userSerializers
http_method_names = ['get', 'post']
The url.py file lets you decide your uniform resource locator(URL’s) with no limitations,
in Django settings the urls.py comes as below, you can, however, make changes to it to suit your
needs.
from django.contrib import admin
from django.urls import path
urlpatterns = [
path('admin/', admin.site.urls),
]
Secure Best Marks with AI Grader
Need help grading? Try our AI Grader for instant feedback on your assignments.

Hospital Management Website 11
In the settings.py allowed hosts are specified and the database connection happens as
illustrated below:
DATABASES = {
'default': {
'ENGINE': 'django.db.backends.sqlite3',
'NAME': os.path.join(BASE_DIR, 'db.sqlite3'),
}
}
Conclusion
To access the services of the hospital management system a server is involved, this is
mandatory for the application to be accessed across board. The server handles communication
between the client and the application, in order to get or update information remotely, the server
is used as the intermediary. The client is the user of the service, a client makes requests and
receives responses through the server. If two clients try to simultaneously make a booking at the
same time, only the first one should be able to complete it, this is due to the services being
synchronous. Different routes in the application require different protection, unregistered users
can only access the signup and login functionalities, registered patients can only see the booking
features, their profile whereas a GP can see several patients profiles. This is possible due to
implementing different permissions on the URLs. If a user does not logout in time, the
application will automatically sign them out after thirty minutes of inactivity. As many users as
possible can run the application simultaneously, this is due to Heroku handling the load
balancing. The users will be able to sign up without affecting the speeds.
References
Anderson J. and Rainie L. 2014. Main Report: An In-depth Look at Expert Responses.
In the settings.py allowed hosts are specified and the database connection happens as
illustrated below:
DATABASES = {
'default': {
'ENGINE': 'django.db.backends.sqlite3',
'NAME': os.path.join(BASE_DIR, 'db.sqlite3'),
}
}
Conclusion
To access the services of the hospital management system a server is involved, this is
mandatory for the application to be accessed across board. The server handles communication
between the client and the application, in order to get or update information remotely, the server
is used as the intermediary. The client is the user of the service, a client makes requests and
receives responses through the server. If two clients try to simultaneously make a booking at the
same time, only the first one should be able to complete it, this is due to the services being
synchronous. Different routes in the application require different protection, unregistered users
can only access the signup and login functionalities, registered patients can only see the booking
features, their profile whereas a GP can see several patients profiles. This is possible due to
implementing different permissions on the URLs. If a user does not logout in time, the
application will automatically sign them out after thirty minutes of inactivity. As many users as
possible can run the application simultaneously, this is due to Heroku handling the load
balancing. The users will be able to sign up without affecting the speeds.
References
Anderson J. and Rainie L. 2014. Main Report: An In-depth Look at Expert Responses.

Hospital Management Website 12
Pew Research Center Internet, Science & Tech. Consulted 22.4.2015
http://www.pewinternet.org/2014/05/14/main-report-an-in-depth-look-at-expert-responses/
Farcic, V. (2014). REST API with JSON. [online] Technology Conversations.
Available at: https://technologyconversations.com/2014/08/12/rest-api-with-json/ [Accessed 4
Jan. 2020].
Gorgia, P. (2018). Redis: What and Why?. [online] Medium.
Available at: https://codeburst.io/redis-what-and-why-d52b6829813
[Accessed 4 Jan. 2020].
Guzman, J. (2019). Developing Restful APIs with Python, Django and
Django Rest Framework - DEV Community 👩👩 👩👩💻💻 . [online] Dev.to.
Available at: https://dev.to/joshuadeguzman/definitive-guide-developing-restful-apis-using-
python-django-and-drf-2h7e [Accessed 3 Jan. 2020].
How to migrate data from SQLite to PostgreSQL in Django - DEV Community 👩👩 👩👩 . (2019).💻💻
Retrieved 3 January 2020, from
https://dev.to/coderasha/how-to-migrate-data-from-sqlite-to-postgresql-in-django-182h
Lahoti, S. (2018). What are REST verbs and status codes [Tutorial] | Packt Hub. [online]
Packt Hub. Available at: https://hub.packtpub.com/what-are-rest-verbs-and-status-codes-tutorial/
[Accessed 4 Jan. 2020].
Pew Research Center Internet, Science & Tech. Consulted 22.4.2015
http://www.pewinternet.org/2014/05/14/main-report-an-in-depth-look-at-expert-responses/
Farcic, V. (2014). REST API with JSON. [online] Technology Conversations.
Available at: https://technologyconversations.com/2014/08/12/rest-api-with-json/ [Accessed 4
Jan. 2020].
Gorgia, P. (2018). Redis: What and Why?. [online] Medium.
Available at: https://codeburst.io/redis-what-and-why-d52b6829813
[Accessed 4 Jan. 2020].
Guzman, J. (2019). Developing Restful APIs with Python, Django and
Django Rest Framework - DEV Community 👩👩 👩👩💻💻 . [online] Dev.to.
Available at: https://dev.to/joshuadeguzman/definitive-guide-developing-restful-apis-using-
python-django-and-drf-2h7e [Accessed 3 Jan. 2020].
How to migrate data from SQLite to PostgreSQL in Django - DEV Community 👩👩 👩👩 . (2019).💻💻
Retrieved 3 January 2020, from
https://dev.to/coderasha/how-to-migrate-data-from-sqlite-to-postgresql-in-django-182h
Lahoti, S. (2018). What are REST verbs and status codes [Tutorial] | Packt Hub. [online]
Packt Hub. Available at: https://hub.packtpub.com/what-are-rest-verbs-and-status-codes-tutorial/
[Accessed 4 Jan. 2020].

Hospital Management Website 13
Rouse, M. (2019). What is an API? - Definition from WhatIs.com.
Retrieved 3 January 2020, From
https://searchapparchitecture.techtarget.com/definition/application-program-interface-API
Sleter, G. (2014). What's an API and Why Do You Need One?. [online] Govtech.com.
Available at:
https://www.govtech.com/applications/Whats-an-API-and-Why-Do-You-Need-One.html
[Accessed 3 Jan. 2020].
Smartdraw.com. (2019). Entity Relationship Diagram (ERD) - What is an ER Diagram?.
[online]
Available at: https://www.smartdraw.com/entity-relationship-diagram/
[Accessed 10 Dec. 2019].
Stringelflow, A. (2017). When to Use (and Not to Use) Asynchronous Programming.
[online] Stackify.
Available at: https://stackify.com/when-to-use-asynchronous-programming/
[Accessed 4 Jan. 2020].
Visual-paradigm.com. (2019). What is Entity Relationship Diagram (ERD)?. [online]
Available at: https://www.visual-paradigm.com/guide/data-modeling/what-is-entity-relationship-
diagram/
[Accessed 10 Dec. 2019].
Rouse, M. (2019). What is an API? - Definition from WhatIs.com.
Retrieved 3 January 2020, From
https://searchapparchitecture.techtarget.com/definition/application-program-interface-API
Sleter, G. (2014). What's an API and Why Do You Need One?. [online] Govtech.com.
Available at:
https://www.govtech.com/applications/Whats-an-API-and-Why-Do-You-Need-One.html
[Accessed 3 Jan. 2020].
Smartdraw.com. (2019). Entity Relationship Diagram (ERD) - What is an ER Diagram?.
[online]
Available at: https://www.smartdraw.com/entity-relationship-diagram/
[Accessed 10 Dec. 2019].
Stringelflow, A. (2017). When to Use (and Not to Use) Asynchronous Programming.
[online] Stackify.
Available at: https://stackify.com/when-to-use-asynchronous-programming/
[Accessed 4 Jan. 2020].
Visual-paradigm.com. (2019). What is Entity Relationship Diagram (ERD)?. [online]
Available at: https://www.visual-paradigm.com/guide/data-modeling/what-is-entity-relationship-
diagram/
[Accessed 10 Dec. 2019].
Paraphrase This Document
Need a fresh take? Get an instant paraphrase of this document with our AI Paraphraser

Hospital Management Website 14
Westland, J. and Westland, J. (2020). Understanding Scrum Methodology - A Guide. [online]
ProjectManager.com.
Available at: https://www.projectmanager.com/blog/scrum-methodology
[Accessed 4 Jan. 2020].
Whatt, A. (2017). Database Design. 2nd ed. New York: Nguyen Kim Anh, p.Chapter 7.
Westland, J. and Westland, J. (2020). Understanding Scrum Methodology - A Guide. [online]
ProjectManager.com.
Available at: https://www.projectmanager.com/blog/scrum-methodology
[Accessed 4 Jan. 2020].
Whatt, A. (2017). Database Design. 2nd ed. New York: Nguyen Kim Anh, p.Chapter 7.
1 out of 14

Your All-in-One AI-Powered Toolkit for Academic Success.
+13062052269
info@desklib.com
Available 24*7 on WhatsApp / Email
Unlock your academic potential
© 2024 | Zucol Services PVT LTD | All rights reserved.