🧑🏻‍⚕️ Medibook

Group project

Domain analysis

Problem

Medicine and the technology surrounding it have continued to improve over the years; however, the system around the public accessing this has remained relatively archaic. To make an appointment with a local GP an individual who is in poor health that should be resting must wake up in the early hours of the morning to call in and book an appointment. Due to the number of people who call in early to try to get an appointment for that day, many individuals are left waiting on hold or having to repeatedly call until they can get through.

Solution

MediBook looks to solve the booking problem by providing clients a way to book appointments quickly and easily with their GP online. This allows them to book an appointment when they are feeling well enough on an available date that suits them.

The system also will free up some time for both the doctors and the receptionists. The receptionists will be able to split their time taking phone calls to book appointments but also it allows them to spend more time for paperwork and helping to provide a friendly service in the GP.

A description box will be provided when booking an appointment, allowing doctors to quickly look over the details of the patient’s illness before seeing them.

User analysis

The MediBook system has 3 different user roles these are the admin role, doctor role and patient role.

Admin

The system administrator is the user group that is responsible for setting up and maintaining the system.

• The admin group has the right to use all the features available in a MediBook website such as check doctor availability, manage patient's information, set appointments and create new patient file.
• Has an excellent understanding of the system and be able to answer all inquiries regarding our system.
• Ensure all correspondence is presented in a professional manner.

Doctor

Doctors are the users who use the system to provide preventive care and quality management of the diagnosis for all, which is very important to promote the health of patients.

• Has the right to view patient’s profiles, provide prescriptions, handle medical reports and schedule patient appointments.
• Monitor and provide general care to patients.
• Requires basic computer skills and experience in diagnosis.

Patient

The aim of our system is trying to improve upon the current system to make a better and a more user-friendly system for them.

• Can only manage appointments, change appointments, update information and be able to select the doctor they wish to see.
• Be able to take control of their healthcare.
• Can access the system widely from either desktop or mobile devices.

The environment

Currently, booking an appointment is done online, by visiting the GP practice or by phone call. The reason for this is that it allows people to easily book an appointment to a local GP online or by phone and if they are near a GP they can just go in and book a time. The online GP web design is very simple as well as basic and we want to improve it by adding better and more exciting features.

The software that we are going to be using are HTML, CSS, PHP and JavaScript. This is used to make it easy and simple for users to use the website with minimal problems. We will use HTML to create the web page with CSS to edit and style the HTML web pages to make it look more attractive as well as appealing.

Requirements

Use-case diagram

Use-case description

Use case name	Book appointment
Brief description	This use case describes how a patient would book an appointment for a selected doctor through the MediBook system.
Actors	Patient
Preconditions	The patient must be logged in with their username and password.
Basic flow	After the patient has logged in successfully, a welcome page will display and show a dashboard of activities such as: View profile Book appointments Medical record Messages Visit support centre/ Health advice B1. Patient select “Book appointments”. B2. In a field “Slot”, select the Date. B3. The system will show list of available doctors for the date chosen. B4. Patient then selects a Time for the doctor. B5. FIll appointment reason (optional).
Alternative flows	a) Apart from the online booking system, we also have the telephone system. The admin checks the appointment schedule to see if the chosen date is available. Next the admin will ask the patient if that date is acceptable, if not then repeat the (1) step. Once a date has been chosen, the admin will ask the patient to select the suitable time slot and doctor. Lastly, the admin will ask for patient’s details and a security question such as “what is your date of birth?”, “can you confirm your postcode”, … Then enter the required information of the patient into the appointment form. Once all information has been filled, submit the form into the database. b) (B1) User doesn’t have an account 1.1 Select Register Now 1.2 Fill in all Your Personal Details 1.3 Create a Password 1.4 Accept the Terms and Conditions 1.5 Click Register and create account (B3) There are no time slots available for the chosen date. 3.1 The system will suggest patient to select another available date. 3.1.1 Incase of emergency, the patient can call the gp and explain the situation. 3.1.2 Then follow (a) 3.2 Patient then select Time for the doctor. 3.3 FIll appointment reason (optional). 3.4 Click “book appointment”
Post condition	An appointment is successfully created and appears on the doctors schedule.

Class diagram

Design discussion

The class diagram helps the developer to understand the important of associations and multiplicities when implemment such as:

• The most important associations in our class diagram are those between Doctor and Appointment and Appointmentb and Patient, the multiplicities used for these associations are to ensure that it is clear that each appointment can only have 1 Doctor and 1 Patient assigned to it, but a single Doctor can have many appointments, and a single Patient can have many appointments.
• Both Doctor andPatient are generalizations of User this is because as stated in the requirements, each user of the system is required to have a username, password and contact information
• patientRecord exists as a composition of Patient, if a patient is removed from the system so should their information, and so the patientRecord should not exist without the patient and hence a composition.
• prescriptionHistory is an aggregation of Prescription as the patient will have a history of prescriptions without the patient having to order a prescription using the system, and thus prescriptionHistory can exist with the existence of its parent Prescription.

Sequence diagram - Book an appointment

Wireframes

Implementation and testing

---

---

---

More projects