TRAINING REPORT

OF
SIX MONTHS INDUSTRIAL TRAINING, UNDERTAKEN
AT

“Oops Info SOLUTIONS PVT. LTD.”

IN
“PYTHON”
ON
“PATIENT INFORMATION SYSTEM”
SUBMITTED IN PARTIAL FULFILMENT OF THE DEGREE
OF
MCA

Under the Guidance of: Submitted By:

Name: Ms. Rashmi Munjal Name: Sunil Kumar
Designation: Assistant Professor Roll No.: 16012002
Department: Computer Science
 Date: 26th May, 2018

CERTIFICATE OF COMPLETION OF TRAINING

This is to certify that Ms. Sunil Kumar S/O. Mr. Umed Singh Student of MCA under
University Roll No. 16012002 of Guru Jambheswer University of Science & Techonology,
Hisar Haaryana. who has completed his Industrial Training project namely “Patient
Information System” in Python & Flask at Oops infosolution pvt. Ltd Chandigarh.

He has been punctual, intellectually alert, and morally capable and has good knowledge of
training subject. To the best of our knowledge and belief, he bears an excellent moral
character. We wish success to his in future.

Yours Sincerely
HRD

Oops infosolution pvt. Ltd

PREFACE

The aim of this project was to design and develop a software prototype which integrates
with an external scheduling component to manage hospital appointments for patients on
fixed treatment pathways and is extendible in the future to include additional functionality.
The application has been designed to be used by hospital receptionists to assist them with
scheduling patients.

A software development methodology was determined and followed to ensure the

successful completion of the project. A number of different tools were researched to
develop the solution. The requirements of the system were established which were then
used in the development phase.

Following the successful implementation of the system, the application was tested and
evaluated for usability and functionality to see overall how successful the project had
been. The final solution developed met all the minimum requirements and also included
some additional features.

The report covers the whole project from start to finish, including the requirements
analysis, background reading, design, implementation, testing and evaluation stages.
ACKNOWLEDGEMENT

I would like to thank everyone that have contributed to the making of this Recommendation
project, which is the final chapter of my Postgraduate education in Computer Science at Guru
Jambheswer University of Science & Techonology, Hisar Haryana. We deeply express our
sincere thanks to our Raps iTech for encouraging and allowing us to present the project on the
topic "Patient Information System" at our department premises for the partial fulfillment of the
requirements leading to the award of MCA degree. We take this opportunity to thank all our
lecturers who have directly or indirectly helped our project.

I would also like to express my sincere gratitude to all my friends who have patiently helped me
in accomplishing this undertaking and for their constant support throughout the project work.

Finally I would like to thank my parents who were always there for me giving encouragement
and guidance.

Name: Sunil Kumar

Roll No.: 16012002
Date: 21st May, 2018

Place: Chandigarh

CONTENTS
Certificate......................................................................................................... - 2 -
Preface............................................................................................................. - 3 -
Acknowledgement............................................................................................ - 4 -

I. Project Undertaken....................................................................................................... - 7 -
I.1 Objective...........................................................................................- 7 -
I.2 Need To Choose The Project............................................................ - 7-
I.3 Industry Application.......................................................................... - 8 -

II. Introduction to Patient Information System..................................................... - 9 -

II.1 Project Schedule.............................................................................. - 10 -

III. Background Research.................................................................................. - 11 -

III.1 Chosen Methodology....................................................................... - 12 -

IV. Requirement Analysis................................................................................. - 13 -

IV.1 OS Compatibility............................................................................ - 14 -
IV.2 Web Application Framework and Database Compatibility................ - 15 -
IV.3 Dataset.......................................................................................... - 16 -

V. Modular description of the Patient information System.................................. - 17 -

V.1 Server Modules............................................................................... - 17 -
V.2 Views............................................................................................. - 17 -
V.3 Templates....................................................................................... - 17 -
V.4 Admin Interface.............................................................................. - 17-
VI. Detailed Analysis of individual module........................................................ - 18 -
VI.1 Application Setup.......................................................................... - 21 -
VII.2 Routing........................................................................................ - 22 -
VI.3 Views........................................................................................... - 25 -
VI.4 Templates..................................................................................... - 25 -
VI.5 Admin Interface............................................................................ - 34 -
VI.5.1 Starting the Admin Interface............................................ - 30 -
VI.5.2 Provide an Admin Interface............................................. - 31 -

VII. Design..................................................................................................... - 32 -
VIII.1 Home Page................................................................................ - 32 -
VIII.2 Add Patient................................................................................ - 33 -
VIII.3 Add Doctor................................................................................ - 33 -
VIII.4 Appointment...................................... .........................................-34 -
VIII.5 Add Appointment....................................................................... - 35 -
VIII.6 Doctor........................................................................................- 36 -

VIII. Coding................................................................................................... - 38 -
VIII.1 Application Setup...................................................................... - 38 -
VIII.2 Routing..................................................................................... - 38 -
VIII.3 Templates................................................................................. - 39 -
VIII.4 Static Files...................................................................................-39-
VIII.5 Request Objects......................................................................... - 41 -

IX. Testing..................................................................................................... - 42 -

X. Future Enhancements................................................................................ - 43 -

XI. Conclusion.............................................................................................. - 44 -

XII. Bibliography and References................................................................... - 45 -

I. PROJECT UNDERTAKEN

I.1 Objective

The aim of the project is to develop a framework which allows management of appointments
using the external scheduling component. The system will have a data model which stores
patient, nurse staff, multiday pattern and intraday pattern data. A prototype system will be
developed which inputs, queries and outputs from the data model. It is the aim of this project to
display the results of the generated schedules and not to actually generate schedules for patients
and nurses. The system needs to integrate with a scheduling component which has been
developed by researchers at the University of Leeds to schedule the appointments. The system
should be able to manually modify schedules generated by the external scheduling program. The
system will be operated by hospital receptionists and other staff to assist them in scheduling
appointments for patients in the near future with respect to staffing resources. Also an aim of the
project is to develop the framework so that it is easy to extend in the future.

I.2 Need to choose the project

There are many medical specialties within the NHS which have a standard pathway for patients
to follow while requiring hospital treatment. This could mean a treatment continues for several
days or even several weeks with regular appointments required for patients at fixed intervals.
Also the specific treatment carried out on one of the days may be a standard treatment which
requires a specific duration.

I.3 Industry Application

It is a very complex problem scheduling the patients such that they follow their required pathway
(multiday pattern) accurately while utilising hospital resources to full potential such as nurses
and doctors. It is imperative to schedule patients in a way in which nurses and doctors can be
allocated systematically to each patient within their normal working hours and also not to have
any clashes. It is also important for the patients to have their treatments in accordance to the
prescribed medical procedures.
Currently staff schedule patients using a manual diary with pen and paper , however due to the
large number of patients treated there may be clashes where a single nurse is allocated two
patients at the same time and required to perform treatment on multiple patients at the same time,
which in practice is not possible. Also a problem which arises is that patients end up not
following their required medical procedure so for example a treatment which should be
completed in twenty-one days can take twenty-eight days. Also the treatment pattern on a
specific day is not always followed accurately due to limitations of the current booking and
resource allocation system. This makes it very difficult for both staff and patients to follow the
timetables while conforming to the medical requirements.

This can be frustrating for the patients as sometimes they have to stay longer at the hospital than
they had anticipated and also for staff as they often have high workloads which they cannot
always cope with. This is a major problem for the receptionists who are responsible for booking
patient appointments, as they have to consider the patients preferences for appointments while
ensuring there are sufficient staff to perform the treatments.
II. INTRODUCTION

Currently staff schedule patients using a manual diary with pen and paper , however due
to the large number of patients treated there may be clashes where a single nurse is
allocated two patients at the same time and required to perform treatment on multiple
patients at the same time, which in practice is not possible. Also a problem which arises is
that patients end up not following their required medical procedure so for example a
treatment which should be completed in twenty-one days can take twenty-eight days. Also
the treatment pattern on a specific day is not always followed accurately due to limitations
of the current booking and resource allocation system. This makes it very difficult for both
staff and patients to follow the timetables while conforming to the medical requirements.

This can be frustrating for the patients as sometimes they have to stay longer at the
hospital than they had anticipated and also for staff as they often have high workloads
which they cannot always cope with. Also there are government set targets for the NHS,
which need to be achieved.
An algorithm has been developed by researchers at the University of Leeds to schedule the
patients and allocate nurses to each action slot within an intraday pattern, with the aim of
eliminating clashes and also to fulfil patient requests.
Advancements in information technology have provided methods for capturing and
storing information more effectively and efficiently, while allowing for backups to be
created in the case of data corruption. Such information systems can be used to improve
time management within organisations.

II.1 Project Schedule

Milestone Date
Learning about new technologies 8/1/2018
Background reading
software development methodologies
Database technologies 10/1/18 – 15/01/18
programming languages

Methodologies and project planning

Learning html + bootstrap 15/1/18 – 25/01/18
Develop a project plan
Finish bootstrap 26/01/18
 Start basics of python 27/01/18-01/2/18
Synopsis submission 02/10/18

Learning flask + making our website responsive 10/02/18-19/03/18

Submission of mid term report 20/03/18

Connect database with sqlite 21/03/18-05/04/2018

Project completed till 20-05-2018

III. BACKGROUND RESEARCH

A methodology provides a structured approach to development and thus decreases the
chances of aspects of the project failing, it provides a recommendation of a series of
steps to be followed . There are many different types of software development
methodologies some of which have been studied and deployed by the developer in
university modules and in external software projects. Some of these include the waterfall
model described as the ‘classical’ model , the spiral model, the unified process and
extreme programming. Many of these were designed to replace the waterfall methodology
and introduced an iterative approach. For example the spiral model does this , as this was
one of the biggest weaknesses of the now obsolete waterfall methodology. Also a lot of
these methodologies are very generic and are not suitable for every software engineering
project; the spiral model is one that is criticised for its ability to follow strictly. The Rapid
Application Development (RAD) methodology became popular in the early 1990’s ‘due to
the perceived deficiencies of the traditional waterfall approach’ . RAD is designed for
projects where the requirements are likely to change however with this system all the
requirements are known so it will not be necessary to refine requirements. An advantage
of RAD is its speed which may be advantageous in this project as time is limited.
Prototyping is a common methodology where the developer quickly builds an initial
system from the requirements. There are two ways of using prototyping; evolutionary
prototyping and throw-away prototyping and it is important to decide in advance which
approach to take if using prototyping .

After analysing several methodologies in detail it has been decided no single

methodology is suitable for this project. The chosen methodology is explained in the
following section.

III.1 Chosen Methodology

It has been decided after reviewing the methodologies that the most appropriate methodology in
this project is the prototyping methodology using an evolutionary prototype, however RAD will be
used within prototyping so that features of the solution can be quickly developed. It has been
decided to not solely use RAD as has been discussed it can lead to errors and prototyping will
allow for any errors to be corrected, by modifying a prototype.
III.2 FRAMEWORK SYSTEM ARCHITECTURE

The proposed solution has two main components which need to be designed and combined
together to form the end solution. The first part of this section is about the design of the main
application architecture and the second part is the design of the data model which will store the
data.

III.2.1 Framework System Architecture

In this section the overall architecture of the proposed system is designed. It shows the different
components of the system and the links between them. The application is split into four
components; the main application that users interact with, the database storing the data, the CSV
parser and the external scheduling component responsible for generating schedules. A data
transfer method is required to send and receive schedules from the external scheduling
component. There are a number of ways in which this can be achieved including allowing the
scheduling component direct read and write access to the database. Other methods for storing
and transferring tabular data include the CSV and XML file data structures.
A CSV (Comma-Separated Values) parser will act as a barrier between the database and the
external scheduling component to stop the schedule generator from directly accessing the
database. This will aim to reduce the likelihood of data corruption. The CSV parser will be
controlled from the main application. It has been decided to use CSV files which have a flat-file
structure unlike XML, as transferring and processing flat-file structures is relatively quick
compared to XML due to there being no metadata which there is with XML. CSV parsing is also
supported by VB, the development language in this project. As CSV files have a flat-file
structure it will be possible to extract them directly from the database tables and append them in
without any data manipulation required which will ensure performance of the system is not
affected.
To access the data from the database users make requests from the main application via the user
interfaces and then the database is queried and the results are displayed on a GUI on the main
application.
A user will be able to trigger the CSV parser and the schedule generator from the main
application. A user will be able to select which data they want to extract from the database in a
CSV file to send to the schedule generator. This may be updated multiday patterns or if they
require a schedule to be generated for new patient(s) then they would extract the patient data and
future schedule data and send it to the schedule generator. The future schedule will also be sent
so that the schedule generator does not generate a schedule for a patient that clashes with the
existing schedule.
The presentation layer will contain the graphical user interfaces and user controls and the code
behind them. This will enable a developer to make changes to the interfaces without manually
needing to modify the code as it will be automatically changed to correspond to the new
interfaces. This separates the interfaces from the .vb class files, which control the functionality of
the controls placed on the interfaces. The application layer will contain all the code behind the
interfaces required for the functionality of the framework. This will include the code to extract
CSV files from the database and append schedules in and also the code to trigger the scheduling
component. The data access layer will be a sub layer of the application layer which is responsible
for accessing data stored in the database. The data layer will manage the physical storage of the
data and its retrieval. It will contain the tables which define the physical storage of the data in the
database. This layer will also include queries, which are recognised as stored procedures and
views to retrieve data. These will allow a user to manipulate the data as it is entered into the
database and extracted from the database, so that if in future the structure of the database tables
is changed, the stored procedures can remain in the same format hence not requiring a developer
to make changes in the application layer. Using this layered design will reduce the impact of
changes to the framework in the future, as a developer would only have to make changes to the
necessary layers.
IV. REQUIREMENT ANALYSIS

IV.1 OS Compatibility

OS compatibility: - Built on Windows, compatible on both Windows and UNIX (Linux)

• The system should be 64-bit.

IV.2 Web Application Framework and Database Compatibility

I have opted for Flask framework with Python version 3.6 to build this web application. Because
it has provides some key features such as tons of packages, speed (it is very fast, encourages
rapid development), security, scalability (can serve many users simultaneously) and many more.
Flask in its 'out-of-the-box' state is set up to communicate with SQLite -- a lightweight relational
database included with the Python distribution. So by default, Flask automatically creates a
SQLite database for my project.

Installations Required:
• Installing Python v3.6
• Installing Flask– latest version

IV.3 Dataset
Flask is a web framework. This means flask provides you with tools, libraries and technologies
that allow you to build a web application. This web application can be some web pages, a blog, a
wiki or go as big as a web-based calendar application or a commercial website.
Flask is part of the categories of the micro-framework. Micro-framework are normally
framework with little to no dependencies to external libraries. This has pros and cons. Pros
would be that the framework is light, there are little dependency to update and watch for security
bugs, cons is that some time you will have to do more work by yourself or increase yourself the
list of dependencies by adding plugins. In the case of Flask, its dependencies are:
• Werkzeug a WSGI utility library
• jinja2 which is its template engine
IV.4 Template Engine

If your website contains only few pages, changing its style will take you some time but is doable.
However, if you have a lot of pages (for example the list of items you sell in your store), this task
become overwhelming.
Using templates you are able to set a basic layout for your pages and mention which element will
change. This way you can define your header once and keep it consistent over all the pages of
your website, and if you need to change your header, you will only have to update it in one place.
Using a template engine will save you a lot of time when creating your application but also when
updating and maintaining it.
V. MODULAR DESCRIPTION OF THE PATIENT INFORMATION
SYSTEM

A project is a sum of many applications. Every application has an objective and can be reused
into another project, like the contact form on a website can be an application, and can be reused
for others. See it as a module of your project.

There are several modules that were created and used during the building of this movie
recommender system. The project follows the design of the high-level architecture system. All of
which are listed as below:

V.1 URL Building

The url_for() function is very useful for dynamically building a URL for a specific function. The
function accepts the name of a function as first argument, and one or more keyword arguments,
each corresponding to the variable part of URL.
The User() function checks if an argument received matches ‘admin’ or not. If it matches, the
application is redirected to the hello_admin() function using url_for(), otherwise to
the hello_guest() function passing the received argument as guest parameter to it.

V.2 Templates

It is possible to return the output of a function bound to a certain URL in the form of HTML.
However, generating HTML content from Python code is cumbersome, especially when variable
data and Python language elements like conditionals or loops need to be put. This would require
frequent escaping from HTML.
This is where one can take advantage of Jinja2 template engine, on which Flask is based. Instead
of returning hardcode HTML from the function, a HTML file can be rendered by
the render_template() function.

V.3 Static Files

A web application often requires a static file such as a javascript file or a CSSfile supporting
the display of a web page. Usually, the web server is configured to serve them for you, but
during the development, these files are served from static folder in your package or next to your
module and it will be available at /static on the application.
A special endpoint ‘static’ is used to generate URL for static files.
V.4 Request Object

The data from a client’s web page is sent to the server as a global request object. In order to
process the request data, it should be imported from the Flask module.
Important attributes of request object are listed below −
• Form − It is a dictionary object containing key and value pairs of form parameters and
their values.
• args − parsed contents of query string which is part of URL after question mark (?).
• Cookies − dictionary object holding Cookie names and values.
• files − data pertaining to uploaded file.
• method − current request method.

VI. DETAILED ANALYSIS OF INDIVIDUAL MODULE

VI.1 Application Setup

A Flask application is an instance of the Flask class. Everything about the application, such as
configuration and URLs, will be registered with this class.
Instead of creating a Flask instance globally, you will create it inside a function. This function is
known as the application factory. Any configuration, registration, and other setup the application
needs will happen inside the function, then the application will be returned.

VI.1.1 Application Factory

Create the flaskr directory and add the __init__.py file. The __init__.py serves double
duty: it will contain the application factory, and it tells Python that the flaskr directory
should be treated as a package.
mkdir flaskr
VI.1.2 Create app

create_app is the application factory function:

• app = Flask(__name__, instance_relative_config=True) creates the Flask instance.

• __name__ is the name of the current Python module. The app needs to know
where it’s located to set up some paths, and __name__ is a convenient way to tell it
that.
• instance_relative_config=True tells the app that configuration files are
relative to the instance folder. The instance folder is located outside
the flaskr package and can hold local data that shouldn’t be committed to version
control, such as configuration secrets and the database file.
• app.config.from_mapping() sets some default configuration that the app will use:
• SECRET_KEY is used by Flask and extensions to keep data safe. It’s set
to 'dev' to provide a convenient value during development, but it should be
overridden with a random value when deploying.
• DATABASE is the path where the SQLite database file will be saved. It’s
under app.instance_path, which is the path that Flask has chosen for the instance
folder. You’ll learn more about the database in the next section.
• app.config.from_pyfile() overrides the default configuration with values taken
from the config.py file in the instance folder if it exists. For example, when
deploying, this can be used to set a real SECRET_KEY.
 • test_config can also be passed to the factory, and will be used instead of the
instance configuration. This is so the tests you’ll write later in the tutorial can be
configured independently of any development values you have configured.
• os.makedirs() ensures that app.instance_path exists. Flask doesn’t create the
instance folder automatically, but it needs to be created because your project will
create the SQLite database file there.
• @app.route() creates a simple route so you can see the application working before
getting into the rest of the tutorial. It creates a connection between the
URL /hello and a function that returns a response, the string 'Hello, World!' in this
case.

VI.1.3 Run The Application

Now you can run your application using the flask command. From the terminal, tell
Flask where to find your application, then run it in development mode. Development
mode shows an interactive debugger whenever a page raises an exception, and
restarts the server whenever you make changes to the code.
For Windows cmd, use set instead of export:
set FLASK_APP=flaskr
set FLASK_ENV=development
flask run

VI.2 Routing

Modern web frameworks use the routing technique to help a user remember application URLs.
It is useful to access the desired page directly without having to navigate from the home page.
The route() decorator in Flask is used to bind URL to a function
As a result, if a user visits http://localhost:5000/appointment URL, the output of
the appointment() function will be rendered in the browser.
The add_url_rule() function of an application object is also available to bind a URL with a
function as in the above example, route() is used.
@app.route('/appointment')
VI.3 Templates
 • It is possible to return the output of a function bound to a certain URL in the form of
HTML. For instance, in the following script, hello() function will render ‘Hello
World’ with <h1> tag attached to it.
• However, generating HTML content from Python code is cumbersome, especially when
variable data and Python language elements like conditionals or loops need to be put.
This would require frequent escaping from HTML.
• This is where one can take advantage of Jinja2 template engine, on which Flask is based.
Instead of returning hardcode HTML from the function, a HTML file can be rendered by
the render_template() function.

All my flask project templates are as follows:

• appointment.html
• Adding session controls - to provide the login and logout buttons in our menu.
• Adding the nav bar.
• The important part here is how I make use of the context object user.is_authenticated
within a {% if %} expression in order to show the right menu elements. When the
user is logged in, we show the logout button and vice versa.
• Registration
• logged_out.html
• login.html
• registration_complete.html
• registration_form.html
• about.html
• home.html
• doctors.html
• patient.html
• addpatient.html
• deletepatient.html
• updatepatient.html
• contacts.html

VI.4 Static Files

A web application often requires a static file such as a javascript file or a CSS file supporting the
display of a web page. Usually, the web server is configured to serve them for you, but during
the development, these files are served from static folder in your package or next to your module
and it will be available at /static on the application.
A special endpoint ‘static’ is used to generate URL for static files.

VI.4 Request Object

The data from a client’s web page is sent to the server as a global request object. In order
to process the request data, it should be imported from the Flask module.

VI.5.1 Important Attributes

• Form − It is a dictionary object containing key and value pairs of form
parameters and their values.

• args − parsed contents of query string which is part of URL after

question mark (?).

• Cookies − dictionary object holding Cookie names and values.

• files − data pertaining to uploaded file.

• method − current request method.

VI.6 Sending Form Data To Template

We have already seen that the http method can be specified in URL rule. The Form data
received by the triggered function can collect it in the form of a dictionary object and forward it
to a template to render it on a corresponding web page.
In the following example, ‘/’ URL renders a web page (student.html) which has a form. The
data filled in it is posted to the ‘/result’ URL which triggers the result() function.
The results() function collects form data present in request.form in a dictionary object and
sends it for rendering to result.html.

VI.7 Views with Database SQLite

Our Flask application has three View functions.
First new_student() function is bound to the URL rule (‘/addnew’). It renders an HTML file
containing student information form.
@app.route('/enternew')
def new_student():
return render_template('student.html')

The HTML script for ‘student.html’ is as follows −

<html>
<body>

<form action = "{{ url_for('addrec') }}" method = "POST">

<h3>Student Information</h3>
Name<br>
<input type = "text" name = "nm" /></br>

Address<br>
<textarea name = "add" ></textarea><br>

City<br>
<input type = "text" name = "city" /><br>

PINCODE<br>
<input type = "text" name = "pin" /><br>
<input type = "submit" value = "submit" /><br>
</form>
 </body>
</html>

As it can be seen, form data is posted to the ‘/addrec’ URL which binds the addrec() function.
This addrec() function retrieves the form’s data by POST method and inserts in students table.
Message corresponding to success or error in insert operation is rendered to ‘result.html’.

The HTML script of result.html contains an escaping statement {{msg}}that displays the result
of Insert operation.
cur.execute("INSERT INTO students (name,addr,city,pin) VALUES
(?,?,?,?)",(nm,addr,city,pin) )

The application contains another list() function represented by ‘/list’ URL. It

populates ‘rows’ as a MultiDict object containing all records in the students table. This object
is passed to the list.html template.
@app.route('/list')
def list():
con = sqlconnect("database.db")
con.row_factory = sql.Row
con = con.cursor()
cur.execute("select * from doctors")
rows = cur.fetchall();
return render_template(list.html",rows = rows)

This list.html is a template, which iterates over the row set and renders the data in an HTML
table.
Finally, the ‘/’ URL rule renders a ‘home.html’ which acts as the entry point of the application.
@app.route('/')
def home():
return render_template('home.html')
VII. DESIGN

VII.1 Home Page

VII.2 Patient

VII.3 Add Patient

VII.4 Doctor

VII.5 Add doctor

VII.6 Add Appointment

VII.7 Choose Date

VII.8 Book Appointment

VII.9 EDIT Doctor

VII.10 Patient Delete

VII11. Search Patient

VII12. Main Home page

VII.13. MAIN doctor page

VII.14 Project Architecture

Patient Information System Project in Flask web Framework Architecture with all the project
modules defined in the section above.
VIII. CODING

I have coded the entire project in Python version 3.6 with Django Web Framework.

VIII.1 Application Setup

A Flask application is an instance of the Flask class. Everything about the application, such as
configuration and URLs, will be registered with this class.
Instead of creating a Flask instance globally, you will create it inside a function. This function is
known as the application factory. Any configuration, registration, and other setup the application
needs will happen inside the function, then the application will be returned.

VIII.1.1 Application Factory

Create the flaskr directory and add the __init__.py file. The __init__.py serves double
duty: it will contain the application factory, and it tells Python that the flaskr directory
 should be treated as a package.
mkdir flaskr
VIII.1.2 Create app

create_app is the application factory function:

1. app = Flask(__name__, instance_relative_config=True) creates

the Flask instance.
• __name__ is the name of the current Python module. The app needs to know
where it’s located to set up some paths, and __name__ is a convenient way to tell it
that.
• instance_relative_config=True tells the app that configuration files are
relative to the instance folder. The instance folder is located outside
the flaskr package and can hold local data that shouldn’t be committed to version
control, such as configuration secrets and the database file.
2. app.config.from_mapping() sets some default configuration that the app will
use:
• SECRET_KEY is used by Flask and extensions to keep data safe. It’s set
to 'dev' to provide a convenient value during development, but it should be
overridden with a random value when deploying.
• DATABASE is the path where the SQLite database file will be saved. It’s
under app.instance_path, which is the path that Flask has chosen for the instance
folder. You’ll learn more about the database in the next section.
3. app.config.from_pyfile() overrides the default configuration with values taken
from the config.py file in the instance folder if it exists. For example, when
deploying, this can be used to set a real SECRET_KEY.
• test_config can also be passed to the factory, and will be used instead of the
instance configuration. This is so the tests you’ll write later in the tutorial can be
configured independently of any development values you have configured.
4. os.makedirs() ensures that app.instance_path exists. Flask doesn’t create the
instance folder automatically, but it needs to be created because your project will
create the SQLite database file there.
5. @app.route() creates a simple route so you can see the application working
before getting into the rest of the tutorial. It creates a connection between the
URL /hello and a function that returns a response, the string 'Hello, World!' in this
case.
 VIII.1.3 Run The Application
Now you can run your application using the flask command. From the terminal, tell
Flask where to find your application, then run it in development mode. Development
mode shows an interactive debugger whenever a page raises an exception, and
restarts the server whenever you make changes to the code.
For Windows cmd, use set instead of export:
set FLASK_APP=flaskr
set FLASK_ENV=development
flask run

VIII.2 Routing

Modern web frameworks use the routing technique to help a user remember application URLs.
It is useful to access the desired page directly without having to navigate from the home page.
The route() decorator in Flask is used to bind URL to a function
As a result, if a user visits http://localhost:5000/appointment URL, the output of
the appointment() function will be rendered in the browser.
The add_url_rule() function of an application object is also available to bind a URL with a
function as in the above example, route() is used.
from flask import Flask,send_from_directory,render_template
from flask_restful import Resource, Api
from package.patient import Patients, Patient
from package.doctor import Doctors, Doctor
from package.appointment import Appointments, Appointment
from package.common import Common
import json

with open('config.json') as data_file:

config = json.load(data_file)
app = Flask(__name__, static_url_path='')
api = Api(app)

api.add_resource(Patients, '/patient')
api.add_resource(Patient, '/patient/<int:id>')
api.add_resource(Doctors, '/doctor')
api.add_resource(Doctor, '/doctor/<int:id>')
api.add_resource(Appointments, '/appointment')
api.add_resource(Appointment, '/appointment/<int:id>')
api.add_resource(Common, '/common')

VIII.3 Templates

• It is possible to return the output of a function bound to a certain URL in the form of
HTML. For instance, in the following script, hello() function will render ‘Hello
World’ with <h1> tag attached to it.
• However, generating HTML content from Python code is cumbersome, especially when
variable data and Python language elements like conditionals or loops need to be put.
This would require frequent escaping from HTML.
• This is where one can take advantage of Jinja2 template engine, on which Flask is based.
Instead of returning hardcode HTML from the function, a HTML file can be rendered by
the render_template() function.

All my flask project templates are as follows:

• appointment.html
• Adding session controls - to provide the login and logout buttons in our menu.
• Adding the nav bar.
• The important part here is how I make use of the context object user.is_authenticated
within a {% if %} expression in order to show the right menu elements. When the
user is logged in, we show the logout button and vice versa.
• Registration
logged_out.html
login.html
registration_complete.html
registration_form.html
about.html

<head>
<meta charset="utf-8">
<meta name="viewport" content="width=device-width, initial-scale=1,
maximum-scale=1">
<meta name="description" content="Bootstrap Admin App + jQuery">
<meta name="keywords" content="app, responsive, jquery, bootstrap, dashboard,
admin">
<title>HospitalManagementSystem</title>
<link rel="stylesheet" href="vendor/fontawesome/css/font-awesome.min.css">
<link rel="stylesheet" href="vendor/simple-line-icons/css/simple-line-icons.css">
<link rel="stylesheet" href="vendor/animate.css/animate.min.css">
<link rel="stylesheet" href="vendor/whirl/dist/whirl.css">

home.html

• doctors.html
• patient.html
• addpatient.html
• deletepatient.html
• updatepatient.html
• contacts.html

VIII.4 Static Files

A web application often requires a static file such as a javascript file or a CSS file supporting the
display of a web page. Usually, the web server is configured to serve them for you, but during
the development, these files are served from static folder in your package or next to your module
and it will be available at /static on the application.
A special endpoint ‘static’ is used to generate URL for static files.

VIII.4 Request Object

The data from a client’s web page is sent to the server as a global request object. In order
to process the request data, it should be imported from the Flask module.
 VIII.4.1 Important Attributes
• Form − It is a dictionary object containing key and value pairs of form
parameters and their values.

• args − parsed contents of query string which is part of URL after

question mark (?).

• Cookies − dictionary object holding Cookie names and values.

• files − data pertaining to uploaded file.

• method − current request method.

VIII.5 Sending Form Data To Template

We have already seen that the http method can be specified in URL rule. The Form data
received by the triggered function can collect it in the form of a dictionary object and forward it
to a template to render it on a corresponding web page.
In the following example, ‘/’ URL renders a web page (student.html) which has a form. The
data filled in it is posted to the ‘/result’ URL which triggers the result() function.
The results() function collects form data present in request.form in a dictionary object and
sends it for rendering to result.html.

VIII.5.1 Managing static files (e.g. images, JavaScript, CSS)

A web application often requires a static file such as a javascript file or a CSS file
supporting the display of a web page. Usually, the web server is configured to serve
them for you, but during the development, these files are served from static folder in
your package or next to your module and it will be available at /static on the
application.
A special endpoint ‘static’ is used to generate URL for static files.
 VIII.5.2 Debug Mode

A Flask application is started by calling the run() method. However, while the
application is under development, it should be restarted manually for each change
in the code. To avoid this inconvenience, enable debug support. The server will
then reload itself if the code changes. It will also provide a useful debugger to
track the errors if any, in the application.
The Debug mode is enabled by setting the debug property of
the application object to True before running or passing the debug parameter to
the run() method.

VIII.6 Views with Database SQLite

Our Flask application has three View functions.

First new_student() function is bound to the URL rule (‘/addnew’). It renders an HTML file
containing student information form.
@app.route('/enternew')
def new_student():
return render_template('student.html')

The HTML script for ‘student.html’ is as follows −

<html>
<body>

<form action = "{{ url_for('addrec') }}" method = "POST">

<h3>Student Information</h3>
Name<br>
<input type = "text" name = "nm" /></br>
 Address<br>
<textarea name = "add" ></textarea><br>

City<br>
<input type = "text" name = "city" /><br>

PINCODE<br>
<input type = "text" name = "pin" /><br>
<input type = "submit" value = "submit" /><br>
</form>

</body>
</html>

As it can be seen, form data is posted to the ‘/addrec’ URL which binds the addrec() function.
This addrec() function retrieves the form’s data by POST method and inserts in students table.
Message corresponding to success or error in insert operation is rendered to ‘result.html’.

The HTML script of result.html contains an escaping statement {{msg}}that displays the result
of Insert operation.
cur.execute("INSERT INTO students (name,addr,city,pin) VALUES
(?,?,?,?)",(nm,addr,city,pin) )

The application contains another list() function represented by ‘/list’ URL. It

populates ‘rows’ as a MultiDict object containing all records in the students table. This object
is passed to the list.html template.
@app.route('/list')
def list():
con = sqlconnect("database.db")
con.row_factory = sql.Row
con = con.cursor()
cur.execute("select * from doctors")
rows = cur.fetchall();
return render_template(list.html",rows = rows)

This list.html is a template, which iterates over the row set and renders the data in an HTML
table.
Finally, the ‘/’ URL rule renders a ‘home.html’ which acts as the entry point of the application.
@app.route('/')
def home():
return render_template('home.html')

IX. TESTING (TEST CASES)

This chapter will look at the testing of the system developed to ensure it has met its
requirements. As a fairly flexible methodology was adopted for the development the
testing of the application started during its development with bugs being fixed as they
were discovered. One of the advantages of using a prototyping methodology was that it
allowed for several iterations for improvement where bugs were fixed. After each section
of the application was completed or some code was written it was tested so that errors
could be corrected. Following the completion of the system further testing was done to test
the final system.

IX.1 UNIT TESTING

Unit testing was undertaken during the actual implementation of the system. Each time some
code was written it was run and monitored using the ‘debug’ feature in MS Visual Studio which
proved to be extremely useful throughout the development phase. As bugs were discovered they
were corrected by adding additional code or modifying the existing code. Several bugs were
corrected using ‘try and catch’ block statements using VB.NETs exception class, for example the
try and catch statement in the actual executable code had been written, as it was discovered
during testing that if a user clicked on cancel when prompted for a patient ID the application
would terminate and go into debug mode. Similarly many other minor errors were discovered
and corrected. This method of testing proved to be very effective in discovering trivial errors
relatively quickly, which were fixed before they created more complicated problems further
down the line during development. After development of the system had been completed testing
was also performed.

IX.1 Integration Testing

Integration testing involves testing the interfaces between programs. Integration testing
was applied to this project by testing the integration between the database and the main
application. Integration testing between the main application, scheduling component and
database was also performed however due to the developer not having the scheduling
component available only the parsing was tested.
Information needs to be read from the database and also inserted into the database by the
main application for the system to work successfully as intended. To perform these tasks
INSERT and SELECT queries are executed by the main application. Using dummy data
several tests were carried out to ensure data is being correctly entered into the appropriate
fields and tables in the database and also retrieved from the database. Some problems were
discovered using this method, for example there are several fields which are required for a
patient, for example their multiday pattern ID is required however the system was still
allowing records to be added without this data. This was solved by adding validation code
to the ‘Save’ button to ensure all required fields had been filled in. Reading data from the
data was successful and required no further coding or modification.
X. FUTURE ENHANCEMENTS

From the results of the evaluation and during development further enhancements were
found which could be incorporated in future extensions to the project enhancing system
functionality. As the framework has been designed and developed to be extended there are
many extensions possible to the system. Some of these are stated below:

• Include a help feature. This could be done by including more help messages in the
application and could be done by creating an interactive screen which
demonstrates use of the software and explain features more clearly. This was
identified by evaluators of the system.
• Include nurse break times when entering the rota for each day. This could be done
by modifying the database to include break times for nurses.
• A calendar feature could be incorporated within the application or by linking the
application to an external calendar. This was another feature identified by
evaluators of the system who said a ‘clever calendar’ could be used with various
views enabling users to zoom in and out of several timeframes; for example an
entire month could be shown or a user could zoom into a specific day. This feature
could also allow for ‘drag and drop’ of appointments.
 • A web based application could be added to allow patients to view their
appointments. This major addition could allow patients to change their intraday
appointments. More focus on the actual scheduling could be placed on such a
project to re-allocate nurses to patients if they wish to change their appointments.
Also nurses could login to view their security would have to be a consideration
with such a project.
• The system could be extended to deal with the preparation of medicines prior to a
patients appointment, so that any required medications are ready for a patient and
this process does not have to be done manually.

XI. CONCLUSION
We conclude that the objective of the project were completed successfully thus the project
aim has been achieved.
• The problem was analysed in detail and all the requirements were sought at the
initial stages which made development of the solution easier as no new
requirements were introduced during development
• A software engineering was chosen which was then successfully followed during
the project which can be seen from the Gantt chart in appendix B with the actual
schedule
• A data model has been developed using MS Access which accurately stores all the
data required from which data can be retrieved and inserted appropriately
• An application has been developed which integrates with the data model and can
query it successfully
• The system has been tested and several bugs have been corrected.
• The framework developed can be easily extended in the future using the same or
additional technologies. Using the software engineering principle of ‘Separation of
Concerns’ with a layered design has achieved the required adaptability, reusability
and extensibility.
XII. BIBLIOGRAPHY AND REFERENCES

• https://coursera.org/learn/patient-information/
• https://medium.com/patient
• https://www.data.com/community/tutorials/patientinformation-systems-python
• https://www.analyticsvidhya.com/blog/2016/06/quick-guide-build-patient-engine-python/
• https://www.klipfolio.com/blog/patient-system
• services.lovelycoding.org/medical-store-billing-management-system-project