Mobile Application for Healthcare and Medical

Emergencies

Chanok Plaisub
Pattarin Urapevatcharewan
Titichaya Vongbusayamas
Kittipon Suttisirikul

Bachelor of Engineering in Software Engineering

Department of Computer Engineering
School of Engineering
King Mongkut’s Institute of Technology Ladkrabang
Academic Year 2022
COPYRIGHT 2022
SCHOOL OF ENGINEERING
KING MONGKUT’S INSTITUTE OF TECHNOLOGY LADKRABANG
Thesis – Academic Year 2022

Bachelor of Engineering Program in Software Engineering (International Program)

Department of Computer Engineering, School of Engineering
King Mongkut’s Institute of Technology Ladkrabang

Title: Mobile Application for Healthcare and Medical Emergencies

Authors
1. Chanok Plaisub Student ID: 62011104
2. Pattarin Urapevatcharewan Student ID: 62011192
3. Titichaya Vongbusayamas Student ID: 62011282
4. Kittipon Suttisirikul Student ID: 62011299

Approved for submission

................................................
(Natthapong Jungteerapanich)
Advisor

Date ......../......../.......
15 12 2022
 Acknowledgment
We would like to express our sincere appreciation to Dr. Natthapong Jungteerapanich, our
advisor. His guidance and supervision has provided a lot of resources needed in
completing our project. We highly acknowledged his willingness to contribute his time
and resources to assist us in any way he could in order to help our initiative succeed.

Also, we would like to express our deep gratitude to Dr. Pipat Sookvatana, Asst.Prof.Dr.
Visit Hirankitti, and Asst.Prof.Dr. Isara Anantavrasilp, for their participation and
providing us with all the facilities that were required.

Furthermore, we would like to extend our thanks to the School of International and
Interdisciplinary Engineering Programs for supporting us. Lastly, we want to thank our
friends who displayed appreciation of our work and motivated us
 Abstract

The purpose of this software engineering project is to create a mobile application, called
Safe With Us, that provides fastest and efficient emergency medical services and ensures
the user's safety while going on an adventure by letting the user’s contacts know the user
location and activity. The motivation of this project is to decrease transport lethality,
increase chances of survival, shorten stays in hospital, provide appropriate medical
treatment, and lower complication rates. The application acts as a central platform that
collaborates among health organizations and users. When the user requests an ambulance,
the data that user inputs can help the hospital prepare a well-equipped ambulance for the
user. In Case of Emergency (ICE) is a program that allows first responders to contact the
next of kin of a cell phone owner in order to obtain critical medical or support
information. However, the mobile phone must be unlocked and working. To deliver an
alternative option, we offer Near-Field-Communication (NFC) that is portable and able to
be attached with different types of user’s belongings. The NFC contains user’s both
personal and medical information which can be accessed by medical staff to obtain the
user's information and treat the patient accordingly.

In addition, every activity people do in daily life can lead to the situation where they need
help. Letting your loved ones know about your activities, time, and place, could prevent
the worst case scenario. Safe With Us application allows the user to create their In Case
of Emergency event which includes activity description, date, and time. The event will be
notified to the user’s contact so that the contact can access the user location during the
event time. It also lets the contact know when to expect the user to be back home, and can
reach out for help if something goes wrong.
Table of Contents

Chapter 1 1
Objectives and Problem Description 1
1.1 Motivation 1
1.2 Objectives 1
1.3 Scope of Work 1
1.3.1 System Features / Capabilities 1
1.3.2 Benefits 2
1.4 Thesis Structure 2
Chapter 2 4
Related Works 4
2.1 BES I lert u 4
2.2 EMS1669 5
2.3 Medical ID 6
2.4 DIAL 4242 7
2.5 ICE contact 7
Chapter 3
Background Knowledge 9
3.1 REST API 9
3.2 CRUD 9
3.3 Cross Platform Application 10
3.4 NoSQL Databases 11
3.5 Web Application 13
3.6 Cloud Services 13
3.7 Branching Strategy 14
3.7.1 New features 15
3.7.2 Bug fixes 15
3.8 NFC 15
3.8.1 The NFC reader chip 16
Chapter 4
Requirement Analysis / Design / Architecture 18
4.1 Requirements Analysis 18
4.1.1 Functional Requirements 18
4.1.1.1 Ambulance 18
4.1.1.2 Map 19
4.1.1.3 Medical 19
4.1.1.4 NFC 19
 4.1.2 Detailed Functional Requirements 19
4.1.2.1 Ambulance 19
4.1.2.2 Map 20
4.1.2.3 Medical 21
4.1.2.4 NFC 21
4.1.4 Detailed Non-functional requirements 23
4.2 Use Cases 24
4.2.1 Use Case Diagram 24
4.2.2 Brief Use Case Descriptions 25
4.3 System Architecture 27
4.4 Entity Relationship Diagram 34
Chapter 5
Development 35
5.1 Development Tools 35
5.1.1 Client Side 35
5.1.1.1 React 35
5.1.1.2 Next.js 36
5.1.1.2 Vercel cloud 36
5.1.2 Server side 37
5.1.2.1 Express.js 37
5.1.2.2 Databases 37
5.1.2.2.1 MongoDB 37
5.1.2.3 Amazon S3 38
5.1.2.3 Application data storage 38
5.1.2.3 REST API 38
5.1.2.4 Cloud 39
5.1.2.4.1 FireStore 39
5.1.2.4.2 Amazon EC2 39
5.1.2.5 Auto Scaling 40
5.1.2.6 Load Balancing 40
5.1.2.7 Elastic Beanstalk 40
5.1.2.8 Monitoring tool 40
5.1.2.8.1 AWS CloudWatch 40
5.1.2.9 Delivery pipeline 41
5.1.2.9.1 AWS CodePipeline 41
5.1.2.10 Authentication 42
5.1.2.10.1 Firebase Authentication 42
5.1.3 Team and Task Management 42
5.1.3.1 Jira 42
5.1.3.2 Github 43
5.1.3.3 Postman 43
 5.1.3.4 GitKraken 43
5.2 Development Techniques 44
5.2.1 Agile Development Process 44
Chapter 6 45
Preliminary Results 45
6.1 Frontend 45
6.1.1 High fidelity prototype 45
6.1.1.1 Request ambulance feature (user view) 45
6.2 Backend 50
6.2.1 Github repository 50
6.2.2 Database connection 51
6.2.2.1 MongoDB 51
6.2.3 Firebase 52
6.2.4 CRUD 52
Chapter 7 57
Current Progress and Future Plans 57
7.1 Current Progress 57
7.1.1 Gantt Chart 58
7.2 Future Plan 59
7.2.1 Google Maps 59
7.2.2 NFC 59
7.2.3 CI/CD 60
7.2.4 Testing 60
7.2.5 Deploying 61
7.2.6 Features 61
Bibliography 62
List of Figures

Figure 1: BES I lert u application 4

Figure 2: EMS1669 application 5
Figure 3: Medical ID application 6
Figure 4: DIAL 4242 application 7
Figure 5: ICE contact application 8
Figure 6: GitHub branching 15
Figure 7: NFC reader chip (1) 16
Figure 8: NFC reader chip (2) 17
Figure 9: Use Case Diagram 24
Figure 10: System Architecture (full-system) 27
Figure 10.1: Authentication Flow (sub-system) 28
Figure 10.2: Expire Service Flow (sub-system) 29
Figure 10.3: Image Uploading Flow (sub-system) 30
Figure 10.4: Chat Collection (sub-system) 31
Figure 10.5: Development Deployment (sub-system) 32
Figure 10.6: Elastic Beanstalk (sub-system) 32
Figure 10.7: CI and CD (sub-system) 33
Figure 11: Entity relationship diagram 34
Figure 12: React Logo 35
Figure 13: Next.js Logo 36
Figure 14: Vervel Logo 36
Figure 15: Express.js Logo 37
Figure 16: MongoDB Logo 37
Figure 17: Amazon S3 Logo 38
Figure 18: Cloud Firestore Logo 39
Figure 19: Amazon EC2 Logo 39
Figure 20: AWS CloudWatch Logo 40
Figure 21: AWS CodePipeline Logo 41
Figure 22: AWS CodePipeline 41
Figure 23: Firebase Authentication Logo 42
Figure 24: Jira Logo 42
Figure 25: GitHub Logo 43
Figure 26: POSTMAN Logo 43
Figure 27: GitKraken Logo 43
Figure 28: Agile Development Process Cycle 44
Figure 29: Log-in & Sign-Up pages 45
Figure 30: Main pages 46
Figure 31: Chat pages 46
Figure 32: Request pages (1) 47
Figure 33: Request pages (2) 47
Figure 34: Staff page 48
Figure 35: Profile page 48
Figure 36: Emergency pages 49
Figure 37: Github backend repository 50
Figure 38: Database connection 51
Figure 39: Database collections 51
Figure 40: Firebase connection 52
Figure 41: Gantt chart 58
Figure 42: Google Maps Platform 59
Figure 43: NFC connection 59
Figure 44: CI/CD 60
Figure 45: Chai & Mocha 60
Figure 46: Robot Framework 61
List of Tables

Table Page

Table 1: Non-functional requirements 22

Table 2: Address API 52
Table 3: Emergency case API 53
Table 4: Emergency contact API 53
Table 5: Hospital API 54
Table 6: Insurance API 54
Table 7: Medical Information API 55
Table 8: Medical staff API 55
Table 9: NFC API 55
Table 10: User API 56
 Chapter 1

Objectives and Problem Description

1.1 Motivation
We propose a Mobile application for healthcare and medical emergencies called Safe
With Us. Safe With Us wants to solve the present world health issue by providing decent
health care and medical emergency services. Traditionally, when people need emergency
care, they have to call 1669 or search hospitals’ numbers on the internet. The problems
are the caller might not know the precise location, the dispatch takes a long time to pick
up the call or does not respond to the call at all, the caller might not be able to explain the
symptoms clearly, and some of the callers also complain about the poor services they had
experienced. Additionally, the application allows users to send users’ current location to
their acquaintances in case of an emergency when going to areas where accidents are
likely to happen.

1.2 Objectives
The objective of our project is to develop a mobile application that helps:
1. Save lives by providing medical emergency services to people in the
shortest time
2. Providing health care matching for bedridden patients
3. Ensuring appropriate medical treatment and fastening the treatment
process through the use of medical cards
4. Providing first aid knowledge to increase the survival rate
5. Allowing users to send their current location to their acquaintances

1.3 Scope of Work

The system is a mobile application for healthcare services and medical emergency cases.
The users are Thailand citizens who are struggling with traditional calling services and
those who have bedridden as their family members.

1.3.1 System Features / Capabilities

● Allow users to call an ambulance for themselves or others from their current
location

1
 ● Allow users to input or make changes to personal information in their NFC card
where the information can only be seen by authorized person

● Provide users’ profiles with basic medical information when using an NFC card

● Allow user to disable their NFC card

● Allow users to call medical staff for home services

● Allow users to navigate through nearby hospitals in the map

● Provide suggested aid protocol according to patients’ medical situation

● Allow users to chat with an ambulance for further information

● Allow hospitals to decline or accept an emergency case that proposed to the

nearby hospitals

1.3.2 Benefits
When visiting doctors, basic medical information can be seen right away when using an
NFC card. Therefore, users do not have to fill out the medical form over and over again
when visiting new hospitals where their information is not recorded in the hospital's
database. Moreover, calling an ambulance through the application will allow users to see
an estimated arrival time of the incoming ambulance. The first aid protocol will also be
shown on the users’ screen, the information will help increase the survival rate of the
patient. Additionally, sharing location when approaching risky areas can help increase
survival rate when it comes to emergency situations.

1.4 Thesis Structure

This thesis consists of seven chapters which are arranged as follows:

● Chapter 1 Introduction - refers to the motivation, objectives, scope of work, and

thesis structure of this thesis.

● Chapter 2 Related Works – proposes the Literature survey, various software that
are relevant to this project, and comparison.

● Chapter 3 Background Knowledge - explains the knowledge and technology

necessary for the reader to understand the thesis.

● Chapter 4 Requirement Analysis / System Design / System Architecture –

presents the requirements of the system, the use case diagram, and the relevant
system architecture diagram.

● Chapter 5 System Development - explains the concepts, tools, and techniques that
are used in developing the project.

2
● Chapter 6 Results - refers to the results of the software demonstration, which
consists of the user interfaces of the software and real-world applications.

● Chapter 7 Conclusion and Future work - is the chapter that talks about the
conclusion, future work and improvements to the project.

3
 Chapter 2

Related Works

This chapter provides brief details and a comparison of existing software related to
emergency medical services in Thailand and other countries, which is BES I lert u,
EMS1669, Medical ID, DIAL 4242, and ICE contact.

2.1 BES I lert u

BES I lert u is an emergency ambulance command and control center application that
provides patient convenience and time-efficient rescue. Before transporting the patient to
the hospital, the nearest hospital in Bangkok Hospital Group will pick up the patient and
provide basic life support, including first aid.

Figure 1: BES I lert u application

[source: https://apps.apple.com/us/app/bes-i-lert-u/id650810264]

There are several similarities with our application. First, both applications concentrate on
providing medical emergency services where the user can request an ambulance by filling
out an assessment form including images and symptoms. Second, the application will use
the location of the user and the locations of the hospitals in the group and dispatch the
nearest hospital to the user. Third, there is a first aid feature where the first aid procedures

4
are displayed in both applications. However, the Health Care application allows the user
to input their medical information for better medical treatment and has more variety of
first aid procedures. When the user requests an ambulance the hospitals are able to choose
whether to accept the request based on medical information and insurance coverage of the
user, location, and hospital’s facilities to avoid problems while treating the patient.

2.2 EMS1669
Medical emergency notifications were received through the EMS1669 application, with
information including full name, telephone number, email address, gender, year of birth,
and medical information. The application will also display nearby hospitals and first aid
procedures. To request an ambulance the user must provide a telephone number and
attach the incident image. The location of the incident is determined by latitude and
longitude. Additionally, the user is also able to track the ambulance.

Figure 2: EMS1669 application

[source: https://m.apkpure.com/ems1669/com.niems.ems1669#com.niems.ems1669-2]

The core features of both applications are similar. However, our health care application
has Near-Field Communication where it is used by medical staff to evaluate the most
efficient way to treat patients based on their condition and medical history.

5
2.3 Medical ID
Medical ID allows the creation of medical profiles that can be accessed from your lock
screen. In the case of emergencies, profiles provide quick access to vital information such
as allergies, blood type, medical contacts, and so on, which are critical for first
responders, medics, or medical staff who must take action. Even when the app is closed,
you can share your location with emergency contacts (for up to 24 hours or until you stop
sharing). The display and access of your medical information from your lock screen are
made possible by enabling an accessibility service, which is one of the app's core
features. When you enable the accessibility service, a widget appears on your lock screen.
This widget enables people with disabilities, as well as first responders in an emergency,
to take action and access medical data.

Figure 3: Medical ID application

[source: https://play.google.com/store/apps/details?id=app.medicalid.free]

The feature of the Medical ID application is similar to our NFC feature where the
first-responder or medical staff can access a patient's medical information such as blood
type, regular medications, gender, age, etc.

6
2.4 DIAL 4242
DIAL4242, India's largest app-based ambulance network, is designed to provide the best
in emergency care to people across the country through its ambulance services, which are
not only limited to emergencies but can also be used by patients to schedule check-ups
and appointments or simply to get home after being discharged from the hospital. The
mobile app connects users to emergency facilities by providing timely ambulance service
when needed, tracking the vehicle once assigned, and predicting when it will arrive at the
desired location. The cost of the ambulance ride will also be predictable.

Figure 4: DIAL 4242 application

[source: https://www.dial4242.com/]

Both applications aim to deliver medical services whenever the user needs. Nevertheless,
the Dial 4242 offers an ambulance transportation service for the user that has scheduled
check-ups and appointments. Meanwhile, our application limits the service to those
people who encounter trauma or life-threatening incidents only.

2.5 ICE contact

The ICE contact main concept is to let your family or friend (in case of emergency
contact) know about what you are planning to do. Those activities may have some risks.
The application has two core features to support that concept. First, instant Messages are
delivered to your ICE Contacts with your GPS location letting them know you need help
right away. They will be notified via In-App, Text or Email. Second, the user is able to set
a Delayed Message and it will deliver it to your ICE Contacts anytime the user wants.
Include a personal note about the activity, enable GPS location tracking and more.

7
 Figure 5: ICE contact application
[source: ICE Contact - FREE Personal Safety App - In Case of Emergency]

We adopt the concept about letting your loved ones know about your activities that
include risks such as hiking, partying, and more. Our application has the feature that
functions like delayed message feature in ICE contact. The user will be able to send
notification to their determined contact including their information, date and time, and
location.

8
 Chapter 3

Background Knowledge

In this chapter, relevant background knowledge is described in order to get a better

understanding of the project.

3.1 REST API

API stands for Application Programming Interface. APIs are mechanisms that enable two
software components to communicate with each other using a set of definitions and
protocols [1].

Developers often implement RESTful APIs by using the Hypertext Transfer Protocol
(HTTP). An HTTP method tells the server what it needs to do to the resource. The
following are four common HTTP methods [2]:

● GET - Clients use GET to access resources that are located at the specified URL
on the server.

● POST - Clients use POST to send data to the server.

● PUT - Clients use PUT to update existing resources on the server.

● DELETE - Clients use the DELETE request to remove the resource.

3.2 CRUD
When we are building APIs, we want our models to provide four basic types of
functionality. The model must be able to Create, Read, Update, and Delete resources.
Computer scientists often refer to these functions by the acronym CRUD. A model should
have the ability to perform at most these four functions in order to be complete. If an
action cannot be described by one of these four operations, then it should potentially be a
model of its own. The following are CRUD operations [3]:

● Create - To create resources in a REST environment, we most commonly use the

HTTP POST method. POST creates a new resource of the specified resource type.

● Read - To read resources in a REST environment, we use the GET method.

Reading a resource should never change any information

9
 ● Update - PUT is the HTTP method used for the CRUD operation, Update.

● Delete - The CRUD operation Delete corresponds to the HTTP method DELETE.
It is used to remove a resource from the system.

3.3 Cross Platform Application

Cross-platform application development is about building a single application that can
run on various operating systems, instead of developing different app versions for each
platform such as IOS, android and Web [4].

Major advantages of using cross platform applications are listed as follows [5]:

● Faster updates and flexibility: Compiling the code faster is a key benefit of
cross-platform application development. Developers can easily share the code
across multiple platforms when using the same programming language.
Cross-platform apps are built with technology that allows switching between
various languages. This also gives developers the flexibility to adopt other
technologies as and when needed.

● Do not have to hire a developer for each platform: Since cross-platform apps
use a single code base and common API, there is no need to hire different teams
for different platforms. This leads to a reduction in developers’ count, which in
turn results in the reduction of total development costs. With cross-platform app
development, businesses don’t have to worry about going over budget.

● Reducing the time and cost of app development: When it comes to time,
cross-platform applications help reduce the time required for the development.
Not only does it take less time overall, but it also reduces time spent on
maintenance and updates because one team is responsible for all versions of your
application instead of many teams like native development requires. This makes it
ideal for quick startups who want to get their presence quickly on multiple
platforms with just one app.

● Easier Implementation: Consistency is a boon for users and developers alike.

With the help of cross platform technologies like React Native and Flutter, the app
development process is streamlined in a way that becomes easier to develop for
multiple platforms and devices. These platforms have been created to build
high-quality native apps across Android and iOS using only one codebase.

● Uniform Design: Developing a mobile application development for multiple

devices can be quite a tedious task. Not only creating the app separately on both
android and iOS platforms, but the user has to see the same look and feel of the
application irrespective of the platform from which it is being accessed. This can
become a problem especially when considering that these platforms have different

10
 functionality. This is where cross-platform app development for android and iOS
Devices can help developing an app for multiple devices which will look and feel
similar irrespective of the platform used for accessing it.

Major disadvantages are listed as follows [6]:

● Performance issues: These apps face performance issues due to the integration
problems with certain operating systems. This arises due to the lack of
compatibility between the native and non-native components of the devices on
which it runs. These apps perform lower in comparison with their native
counterparts.

● Limited number of tools: The app developers find it difficult to bring about cross
platform compliance as the tools for developing these apps are limited. We find
Android and iOS platforms coming out with updated versions that are more
advanced which leaves cross-platform apps lagging behind .

● UX Challenges: It is not that cross platform apps do not have a good user
interface but they sometimes cannot match the seamless performance and
attractive UI as the native apps. They fail to meet user expectations. The slow
loading time with performance related issues can be very discouraging.

● Security Issues: Cyber attacks are not at all that uncommon and mobile apps are
vulnerable to them. With frequent updates, native apps are able to rectify their
loopholes but cross-platform apps are not up to the level of that agility in
addressing security issues.

3.4 NoSQL Databases

NoSQL databases (aka "not only SQL") are non-tabular databases and store data
differently than relational tables. NoSQL databases come in a variety of types based on
their data model. The main types are document, key-value, wide-column, and graph. They
provide flexible schemas and scale easily with large amounts of data and high user loads
[7].

Major advantages of using NoSQL databases are listed as followed [8]:

● Handle large volumes of data at high speed with a scale-out architecture:

NoSQL databases were created in internet and cloud computing eras that made it
possible to more easily implement a scale-out architecture. In a scale-out
architecture, scalability is achieved by spreading the storage of data and the work
to process the data over a large cluster of computers. To increase capacity, more
computers are added to the cluster.

11
 ● Store unstructured, semi-structured, or structured data: NoSQL databases
have proven popular because they allow the data to be stored in ways that are
easier to understand or closer to the way the data is used by applications. Fewer
transformations are required when the data is stored or retrieved for use. Many
different types of data, whether structured, unstructured, or semi-structured, can
be stored and retrieved more easily.

● Enable easy updates to schema and fields: In addition, NoSQL databases often
allow developers to directly change the structure of the data.

○ Document databases don’t have a set data structure to start with, so a new
document type can be stored just as easily as what is currently being
stored.

○ With key-value and column-oriented stores, new values and new columns
can be added without disrupting the current structure.

○ In response to new kinds of data, graph database developers add nodes

with new properties and arcs with new meanings.

● Developer-friendly: NoSQL databases can store data in native formats, which

means developers don’t have to adapt the data to the store. Storing data “as is”
means not having a front-end ETL system to shoe-horn semi-structured data into
row and column formats, and fewer applications to develop or buy to get a new
database launched.

Most NoSQL databases have a strong community of developers surrounding

them. This means that there is an ecosystem of tools available and a community of
other developers with which to connect.

● Take full advantage of the cloud to deliver zero downtime: The scale-out
architecture that most NoSQL databases use does more than provide a clear path
to scaling to accommodate huge datasets and high volumes of traffic. Delivering a
database using a cluster of computers also allows the database to expand and
contract capacity automatically.

Major disadvantages of using NoSQL databases are listed as followed [9]:

● Queries are less flexible: NoSQL databases are more flexible when storing a
wide variety of data structures, but they lack the complex query functionality
found in SQL.

● Less mature: Since SQL has been around a lot longer, it is generally universal
and more mature.

12
In general, NoSQL is preferable to SQL when [10]:

● The organization works with a huge amount of data

● The data is not strongly related

● The data is not structured

● The database needs to consistently scale

3.5 Web Application

A Web application (Web app) is an application program that is stored on a remote server
and delivered over the Internet through a browser interface. Web services are Web apps
by definition and many, although not all, websites contain Web apps. According to
Web.AppStorm editor Jarel Remick, any website component that performs some function
for the user qualifies as a Web app.
Web applications can be designed for a wide variety of uses and can be used by anyone;
from an organization to an individual for numerous reasons. Commonly used Web
applications can include webmail, online calculators, or e-commerce shops. Some Web
apps can be only accessed by a specific browser; however, most are available no matter
the browser.

How Web applications work Web applications do not need to be downloaded since they
are accessed through a network. Users can access a Web application through a web
browser such as Google Chrome, Mozilla Firefox or Safari. For a web app to operate, it
needs a Web server, application server, and a database. Web servers manage the requests
that come from a client, while the application server completes the requested task. A
database can be used to store any needed information. Web applications typically have
short development cycles and can be made with small development teams. Most Web
apps are written in JavaScript, HTML5, or Cascading Style Sheets (CSS). Client-side
programming typically utilizes these languages, which help build an application's
front-end. Server-side programming is done to create the scripts a Web app will use.
Languages such as Python, Java, and Ruby are commonly used in server-side
programming [11].

3.6 Cloud Services

Cloud services are infrastructure, platforms, or software that are hosted by third-party
providers and made available to users through the internet.
Cloud services facilitate the flow of user data from front-end clients (e.g., users’ servers,
tablets, desktops, laptops—anything on the users’ ends), through the internet, to the
provider’s systems, and back. Cloud services promote the building of cloud-native

13
applications and the flexibility of working in the cloud. Users can access cloud services
with nothing more than a computer, operating system, and internet connectivity.

All infrastructure, platforms, software, or technologies that users access through the
internet without requiring additional software downloads can be considered cloud
computing services—including the following as-a-Service solutions

● Infrastructure-as-a-Service (IaaS) provides users with compute, networking, and

storage resources.

● Platforms-as-a-Service (PaaS) provides users with a platform on which

applications can run, as well as all the IT infrastructure required for it to run.

● Software-as-a-Service (SaaS) provides users with—essentially—a cloud

application, the platform on which it runs, and the platform’s underlying
infrastructure.

● Function-as-a-Service (FaaS), an event-driven execution model, lets developers

build, run, and manage app packages as functions without maintaining the
infrastructure.

Clouds are IT environments that abstract, pool, and share scalable resources across a
network. Clouds enable cloud computing, which is the act of running workloads within a
cloud environment. Clouds are a type of PaaS, because hardware and an application
software platform is provided by another party [12].

3.7 Branching Strategy

There are many different branching strategies available. We will look at one such strategy
which will immensely aid release management.

Initially, the default branch would-be master. We will create the staging and develop
branches and we will make the develop branch the default branch [13].

● develop (default)
● staging
● master

14
 Figure 6: GitHub branching
[source: https://bluecast.tech/blog/git-switch-branch/]

The above branches should be created before developing any features and should not be
deleted at any point in time, as long as the project/application exists.
The analogy is that any commit in the develop branch will be deployed in the
development environment, any commit in the staging branch will be deployed in the
staging environment and any commit in the master branch will be deployed in the
production environment.

3.7.1 New features

So for any new feature to be developed, a new branch should be created from the develop
branch, which should be named feature/x.

3.7.2 Bug fixes

For any bug to be fixed, here also a new branch should be created from the develop
branch, which should be named bugfix/x.

3.8 NFC
A Near-Field Communication chip (NFC chip or NFC chipset) is a silicon component or
Integrated Circuit (IC) that can be used in different ways, depending on the targeted
application. When connected to an appropriate antenna, an NFC chip enables short-range,
wireless communication between two devices. This provides an additional layer of
security, as only devices within close proximity of each other can communicate via NFC.
An NFC communication system includes two separate parts: an NFC reader chip and an
NFC tag. The NFC reader chip is the active part of the system because as its name
suggests, it “reads” (or processes) the information before triggering a specific response. It

15
provides power and sends NFC commands to the passive part of the system, the NFC tag.
The NFC technology is frequently used in public transport, where users can pay using
their NFC-enabled ticket or smartphone. In this example, the NFC reader chip would be
embedded in the bus payment terminal, and the NFC passive tag would be in the ticket
(or the smartphone) that receives and replies to the NFC commands sent by the terminal.
There are three types of NFC chips: NFC readers, NFC tags, and NFC controller chips.

3.8.1 The NFC reader chip

An NFC reader chip can be considered the main controller of the communication system,
as it initiates the communication, powers up the NFC tag, and sends commands through
the magnetic field to the passive tag. An NFC reader can also be called an NFC writer,
because of its ability to write data into the NFC tag.

Usually, combined with a microcontroller, the NFC reader chip powers up and exchanges
information with one or more NFC tags. Supporting multiple RF protocols and features,
an NFC reader chip can be used in three different modes: Read/Write, Peer to Peer (P2P),
and Card Emulation.

Figure 7: NFC reader chip (1)

[source: https://www.st.com/content/st_com/en/support/learning/essentials-and-insights

/connectivity/nfc/nfc-chips.html]

16
NFC reader chips are often embedded in smartphones, payment terminals, ticket
machines, car door handles, car center consoles, or as part of a broader payment system,
such as an automotive or transport application, or a gaming device.

Figure 8: NFC reader chip (2)

[source: https://www.st.com/content/st_com/en/support/learning

/essentials-and-insights/connectivity/nfc/nfc-chips.html]

For example, if an NFC reader is embedded in a door handle, the door can be unlocked
when the authorized NFC-enabled smartphone is brought in close proximity to the door
handle [14].

17
 Chapter 4

Requirement Analysis / Design / Architecture

This chapter presents the requirement analysis which provides a comprehensive

understanding of the details and specifications of the system. It contains system
information ranging from the system analysis which consists of requirements and use
cases, followed by the system architecture, and system design, and ends with the system
architecture.

4.1 Requirements Analysis

Our team members are people that have experience in calling ambulances and requesting
medical service, which nowadays requires lots of unnecessary effort. Pattarin
Urapevatcharewan, one of our team members has multiple cousins that work in the
medical field and have plenty of knowledge in that department. We do an interview with
her cousin to gather information and he also helps us create the requirements.

4.1.1 Functional Requirements

4.1.1.1 Ambulance

● The system must allow the user to request an ambulance

● The system must allow the user to request an ambulance for themselves or other
people.
● The system must categorize the user's urgency based on the medical assessment
form
● The system must display the patient waiting list along with patient symptoms and
medical information to the hospital
● The system must allow the hospital to accept or decline the case
● The system must display the ambulance estimated time arrival to the user
● The system must allow the user to confirm the arrival of ambulance
● The system must show the status of all accepted case in the hospital view
● The system must allow the user to chat with an ambulance for further information
● The system must record the user's ambulance request in the history tab

18
4.1.1.2 Map

● The system must display nearby hospitals on a map

● The system must allow users to share their location with other users
● The system must allow users to send an in case of the emergency event to other
users

4.1.1.3 Medical

● The system must allow the doctors to assess the patient's symptoms by means of
medical assessment form
● The system must provide suggested first aid protocol according to user's medical
situation

4.1.1.4 NFC

● The system must allow users to disable their health card

● The system must allow the only doctor to read full data from patient’s NFC card
● The system must allow the user to change their data in the NFC card
● The system must allow the user to scan other people's NFC in case that person is
lost

4.1.2 Detailed Functional Requirements

4.1.2.1 Ambulance

● The system must allow the user to request ambulance

● The system must allow the user to request an ambulance for themselves or
other people.
Users are able to call an ambulance at any time either for themselves or other
people in need. When requesting, the user can put a brief detail of what happened
and scan the NFC tag of other people if the user doesn’t request for themselves.
Once the user requests an ambulance, the user must wait for the hospital to accept
the request.

● The system must categorize the user's urgency based on the medical
assessment form
Once the user requests the ambulance, the system will do a brief categorization of
the emergency case then it will display the result to both the user and the hospital.

● The system must display the patient waiting list along with patient symptoms
and medical information to the hospital

19
 The hospital can view all emergency cases that are either pending or accepted. In
each emergency case, it will show all the information of that case and the people
who are requested.

● The system must allow the hospital to accept or decline the case
Some hospitals can not accept all emergency cases, so the system will require the
hospital to either accept or decline. However, the hospital can still see the full
information of each case even though it has not been accepted.

● The system must display the ambulance's estimated time of arrival to the
user
Users can see the estimated time of arrival of the ambulance when the
user-requested case has been accepted. The time that is estimated came from the
estimated time of arrival from the hospital to the requested location at that time.

● The system must allow the user to confirm the arrival of the ambulance
Once the ambulance has arrived the user can confirm to the hospital that it has
arrived.

● The system must show the status of all accepted cases in the hospital view
Each emergency case has various statuses such as dispatched, arrived, or finished.
Each case will also be sorted by status when displayed to the hospital.

● The system must allow the user to chat with an ambulance for further
information
Once the emergency case has been accepted by the hospital, both the hospital and
the requested user can text chat with the hospital for further information while
chatting the hospital can put in the information for easier categorization.

● The system must record the user's ambulance request in the history tab
After the emergency case has been finished, the user that created that case and the
hospital that accepted that case will be able to view it.

4.1.2.2 Map

● The system must display nearby hospitals on a map

Users will be able to see all nearby hospitals on a map, and they can also see the
full detail of each hospital. The information about each hospital includes hospital
type, distance to the hospital, price range, and rating.

● The system must allow users to share their location with other users
With the Alert system, users can share their location if they feel unsafe, the user
that can view the shared location must be accepted by the sharer.

● The system must allow users to send an emergency message to other users

20
 The user can send either a pre-written emergency message or a new emergency
message to all other users that are in the same group or family, the details in the
message will automatically include the date, time, and the location of the sender.

4.1.2.3 Medical

● The system must allow the doctors to assess the patient's symptoms by means
of a medical assessment form
The hospital will have doctors chat with the patient for further information on the
case, and from the doctors’ view, they can fill out a medical assessment form and
send the result to the patient afterward.

● The system must provide suggested first aid protocol according to the user's
medical situation
Users can look up first aid details of most symptoms on the first aid page, and
after the user creates an emergency case and puts in brief detail or chat with the
doctor, first-aid information of that symptom will pop up and suggest the user.

4.1.2.4 NFC

● The system must allow users to disable their health card

Users can disable their card. A disabled card means that the information within it
can not be accessed by both other users and the doctor. This is to provide personal
security.

● The system must allow the only doctor to read full data from the patient’s
NFC card
Doctors can scan a patient's NFC card to access all data within the card if the card
is not disabled, but if other users scan it, the system will display brief information
or some information that the card owner is willing to share.

● The system must allow the user to change their data on the NFC card
Data in the NFC card can be changed only by the owner of that card such as a
Home address, Guardian, Phone number, or Name. Once the user has changed the
information a physical NFC card is required to confirm the change.

● The system must allow the user to scan other people's NFC in case that
person is lost
When users scan an NFC card of another user it will not show the full information
of that card’s owner, but it will only show some information such as Guardian’s
contact information, Home address, or Name. And when the card owner is
reported to be lost, if the card has been scanned it will report to the guardian of
that missing person.

21
4.1.3 Non-functional requirements

Description FURPS+

The interface of the system must be user-friendly. Usability

The design interface of the system must have clear instructions. Usability

The system must be able to handle the basic authentication Reliability

problem.

The system must not allow unauthorized users to request an Reliability

ambulance.

The data in an NFC card must not be able to be accessed by Reliability

non-doctor users.

The system must have 99% uptime or more. Performance

The system must be able to handle multiple users at the same time. Performance

The system should be a mobile application that supports both iOS Supportability
and Android.

The system should be hosted in AWS cloud service. Supportability

Table 1: Non-functional requirement

22
4.1.4 Detailed Non-functional requirements
● The interface of the system must be user-friendly.
The interface must be easy to use, recognizable, and minimalistic as this
application’s target users are elderly people, and people in need.

● The design interface of the system must have clear instructions.

Some users, especially elderly people, could not recognize icons or buttons that do
not have a clear label of what it does, so each functionality in the application must
have at least some instructions about what they do.

● The system must be able to handle the basic authentication problem.

The system must indefinitely avoid authentication errors as they can violate users’
privacy and data privacy laws.

● The system must not allow unauthorized users to request an ambulance.

Users that are unauthorized should not be able to request an ambulance as
unauthorized users could lead to system abuse.

● The data in an NFC card must not be able to be accessed by non-doctor

users.
Data that is linked to the NFC card won’t be accessible to all users except doctors,
to avoid personal privacy violations while allowing doctors to access information
during an emergency case.

● The system must have 99% uptime or more.

Having high uptime means our users can request an ambulance whenever they
need it, which means users can be assured that they are safe when the time is
needed.

● The system must be able to handle multiple users at the same time.
As our application is an emergency request application it means user requests
must be responded to instantaneously, and multiple users can request emergency
cases at the same time.

● The system should be a mobile application that supports both iOS and
Android.
Our application aims to be easily accessible to everyone, whether they are young
or old, either using iOS or Android. To help people who need to request an
ambulance or people that feel unsafe.

23
4.2 Use Cases

4.2.1 Use Case Diagram

Figure 9: Use Case Diagram

24
4.2.2 Brief Use Case Descriptions
1. Sign in: The user must input their email address and password, then press the
sign-in button or the user can sign in via google email. The system will do
authentication on the user input. Then, the system will navigate the user to the
Home page.

2. Sign up: The user that does not have an account will input his/her email and the
user will also have to input a matched password into the password fields. Then,
the user selects the role (normal user or medical staff) and presses the sign-up
button. The system will create a new account for her/him. After that, the system
will navigate the user to the Feed page.

3. Forgot password: When the user presses “forgot password?’’, he/she will input
the registered email address. Then the firebase authentication will send the email
for resetting the password directly to that email address which allows the user to
change/ reset the password.

4. Request ambulance: When the user presses the SOS button, the user must input
the requested information. After the user finishes filling in the information and
presses the request button, the system will use that data and send it to nearby
hospitals.

5. View ambulance request history: The user is able to view all ambulance
requests they have made.

6. View first aid: The user can click the First aid button to view suggested first aid.

7. Update medical information: The user can edit medical information at any time
and press the save button to sync the information to the system and NFC.

8. View contacts’ location: The user can view the contacts’ location.

9. CRUD ICE event: The user can create/read/update/delete In Case of an

Emergency Event.

10. Disable/enable location sharing: The user can disable and enable location.

11. Disable/activate NFC: The user can disable his/her own NFC when it is lost and
activate it when found.

12. Scan NFC to view personal data: When the normal user scans the NFC of
another user, only a part of personal data will be displayed.

13. Scan NFC to view medical data: When the medical staff scan an NFC the
personal and medical data of the patient will be displayed.

14. Chat with medical staff: The user(Patient) is able to chat with other
users(Medical Staff).

25
15. Call with medical staff: The user(Patient) is able to call other users(Medical
Staff).

16. Chat with patient: The user(Medical Staff) is able to chat with other
users(Patients).

17. Call with patient: The user(Medical Staff) is able to call other users(Patients).

18. View patient’s ambulance request: The hospitals must be able to view all
ambulance requests made by users (patient).

19. Accept request: The user(Hospital) is able to accept the request for an ambulance
from the users(Patients).

20. Decline Request: The user(Hospital) is able to decline the request for an
ambulance from the users(Patients).

21. Assign request to medical staff: The hospital is able to assign the ambulance
request to medical staff.

22. View status of accepted request: The hospitals must be able to view the status of
an accepted ambulance request.

26
4.3 System Architecture

Figure 10: System Architecture (full-system)

The overall design demonstrates that we make use of the ElasticBean Stalk, which sits on
top of the EC2 instance and offers an automatic scaling procedure for the server side as
well as the client side. In addition, ElasticBean additionally gives AWS Cloudwatch for
the debugging process. Furthermore, it offers hardware status, information logging, and
other features. For the client-side development that will take place on an EC2 instance,
the tools that we have decided to use are React and React Native (Expo). Our program
utilizes MongoDB and Firestore for the database component, which is responsible for
data collection from the application. Any request that requires real-time communication
to be handled, such as chat, notice, and so on, will be handled by Firestore.

27
 Figure 10.1: Authentication Flow (sub-system)
Firebase Authentication provides backend services, easy-to-use SDKs, and ready-made
UI libraries to authenticate users to your app. It supports authentication using passwords,
phone numbers, popular federated identity providers like Google, Facebook and Twitter,
and more. As a result, we came to the conclusion that a more robust web authentication
solution would be Firebase Authentication. It is also simple to scale up the system in the
event that the program in question needs to work with an external source such as Line,
Facebook, or Twitter.

The first step in the Authentication Flow is for the client to register the application with
the Firebase Authentication service, which offers APIs for logging in, registering, and
resetting passwords. Each user will be given a token by Firebase Authentication, and the
client can then provide any API in the system by supplying this token. The backend will
validate the token and decrypt the user information, including the user's id and email
address, in order to map the information to the database (mongoDB).

28
 Figure 10.2: Expire Service Flow (sub-system)
This service was developed in response to a business need to establish a framework for
the scheduling or setting of time limits for customer activities, such as the payment
service offered by Shopee. Shopee requires clients to complete a transaction only after
they have placed an order and waited two hours. After this period of time, the system will
stop the transaction process in order to make the payment available to other customers.
This system will continually monitor the process to ensure that the time has arrived, and if
it reaches the predetermined time, it will call back to the backend and perform additional
processing.

Using Redis with Bull.js enables our application to open several nodes on its instance
with a time restriction. Once all of the work has been completed, Redis will close all
instances, which is preferable for business cases that include lowering revenue.

In the event that there is a significant amount of traffic on the system, the load balancer
that Redis offers can be of great assistance to us in our efforts to scale out the instance.

29
 Figure 10.3: Image Uploading Flow (sub-system)
We chose to use AWS S3 to store images and videos in the cloud for the image uploading
process. The process starts when the client sends an HTTP (POST) request to the backend
to add an object to the database. Backend will upload the File image to the S3 storage and
get a response as a path on the bucket. Backend will then store these paths on the model
in case there are more GET requests in the future.

# Chat-App Collection
-------------------------
user
user_id_1
user_id_2
name : "chanok"
surname : "plaisub"
//array not suitable
block
0 : user_id_3
1 : user_id_4
2 : user_id_5
mute
0 : user_id_6
1 : user_id_7
2 : user_id_8
//this one is better
delete
user_id_1

30
 timestamp
user_id_3
timestamp

group
group_id_1
group_id_2
group_id_3
members :
0 : user_id_2
1 : user_id_3
name : "himb" #optional
type : "private" || "group" #optional for group will set default at
private.
recentMessage
messageText:"hell"
readBy
sendAt: ...
sendBy: ...
message
group_id_1
group_id_2
message
document_id_1
document_id_2
messageText : "Hello my name is Jeff"
sentAt : ...
sentBy : ... @user_id
seen : 1 || 0 #optional seen will set to 1 by !(sendBy)
messageType : ...

Figure 10.4: Chat Collection (sub-system)

Document data structure is a unique type of firestore database which provides real-time
communication on both client to client and client to server. It allows clients to
communicate with low latency time as normal communication services such as Line,
Meta, and etc. This service also provides mini features such as mute, block, and delete.
The system contains three main collections including user, group, and message each has
its own responsibility for handling unique data.

User collection is a collection that handles the data of users, any data that provides user
information can be collected here.

31
Group collection is a collection that manages the data associated with chat rooms,
including recentMessage and field members.
Members : contain a uid of user
RecentMessage : display the most recent message, containing sender and recipient
information as well as the message itself.

Message collection is a collection of messages.

Figure 10.5: Development Deployment (sub-system)

For the purposes of development, the website was launched on Vercel, which is a free
platform that makes it possible to operate on other processes simultaneously, such as unit
testing, integration testing, and so on. Because Vercel is integrated with Github,
debugging issues may be resolved quickly and easily. It will automatically update itself in
accordance with the branch commitment.

Figure 10.6: Elastic Beanstalk (sub-system)

32
Elastic Beanstalk is a service for deploying and scaling web applications and services.
Upload your code and Elastic Beanstalk automatically handles the deployment—from
capacity provisioning, load balancing, and auto scaling to application health monitoring.

Figure 10.7: CI and CD (sub-system)

An S3 bucket for holding artifacts. An Elastic Beanstalk environment that acts as the
target when the application’s latest build package is deployed. A CI/CD pipeline with
source, build, and deploy stages. The source stage invokes CodePipeline every time the
code changes in the configured GitHub repository branch. This stage configures GitHub,
which integrates the application source code via webhooks. It then fetches the latest
GitHub code and places it in an S3 bucket in the Source Artifacts directory. The build
stage invokes CodeBuild, which fetches the source code from the S3 bucket. The
CodeBuild-provided Amazon Linux 2 Docker image for .NET Core compiles the latest
source code using the steps provided in the associated BuildSpec.yml file. The resulting
build package is placed in the Build Artifacts directory in the S3 bucket. The deploy stage
invokes CodeDeploy to fetch the build package from the S3 bucket and deploy it to the
Elastic Beanstalk environment.

33
4.4 Entity Relationship Diagram

Figure 11: Entity relationship diagram

34
 Chapter 5

Development

This chapter describes the system development of the project. This chapter describes the
development techniques used while developing the system. The system components are
divided into 2 main parts, client-side and server-side.

5.1 Development Tools

5.1.1 Client Side

On the client side the processing takes place on the user’s computer. It requires browsers
to run the scripts on the client machine without involving any processing on the server.

5.1.1.1 React

Figure 12: React Logo

[source: https://logos-download.com/9747-react-logo-download.html]

React (also known as React.js or ReactJS) is a free and open-source front-end JavaScript
library for building user interfaces based on UI components. It is maintained by Meta
(formerly Facebook) and a community of individual developers and companies [15].

35
5.1.1.2 Next.js

Figure 13: Next.js Logo

[source: https://commons.wikimedia.org/wiki/File:Nextjs-logo.svg]

Next.js; a React library extension is the development framework of our choice. It gives us
the benefits of SEO optimization on our single-page application. A single-page
application (SPA) is a web application or website that interacts with the user by
dynamically rewriting the current web page with new data from the web server, instead of
the default method of a web browser loading entire new pages.

Next.js enables us to create a single-page application that has all the functionalities and
interactivity we require and still enjoys all the SEO benefits of a static text-based website.
– According to the findings of the State of Frontend report, more than half of developers
do not think of SEO as an important factor during development.

5.1.1.2 Vercel cloud

Figure 14: Vervel Logo

[source: https://logovtor.com/vercel-inc-logo-vector-svg/]

We hosted our frontend Application on Vercel cloud; a cloud platform that enables
developers to host websites that deploy instantly, scale automatically, and require little to
no supervision.

36
5.1.2 Server side
In the client-server model, server-side refers to programs and operations that run on the
server. This is in contrast to client-side programs and operations which run on the client
[16].

5.1.2.1 Express.js

Figure 15: Express.js Logo

[source: https://www.edureka.co/blog/expressjs-tutorial/]

Express is a node js web application framework that provides broad features for building
web and mobile applications. It is used to build a single page, multipage, and hybrid web
application. It's a layer built on top of the Node js that helps manage servers and routes
[17].

5.1.2.2 Databases

5.1.2.2.1 MongoDB

Figure 16: MongoDB Logo

[source: https://commons.wikimedia.org/wiki/File:MongoDB_Logo.svg]

MongoDB is a document-oriented NoSQL database used for high-volume data storage.

Instead of using tables and rows as in traditional relational databases, MongoDB makes
use of collections and documents. Documents consist of key-value pairs which are the
basic unit of data in MongoDB. Collections contain sets of documents and functions
which is the equivalent of relational database tables. MongoDB is a database that came
into light around the mid-2000s [18].

37
5.1.2.3 Amazon S3

Figure 17: Amazon S3 Logo

[source: https://blog.lawrencemcdaniel.com/setting-up-aws-s3-for-open-edx/]

Amazon S3 offers scalable storage that lets businesses store and manage endless amounts
of items in the cloud. It not only offers a huge storage allowance but it does so with
extremely fast speeds, allowing users to quickly retrieve and share their stored images.
It’s widely known that AWS is extremely secure, ensuring that each image stored is under
extremely safe protocols and security checks.

In our architecture, we employ S3 storage to store all media files that are uploaded by the
users such as profile pictures, uploaded images, and logos. We can achieve this by using
S3 SDK in our Beanstalk backend to expose upload and retrieve API to the client side
[19].

5.1.2.3 Application data storage

Our main application data storage is MongoDB. MongoDB provides a simple interface to
retrieve data from the database. Since our application does not require any complex
relationships between data models, an easy-to-use Document store like MongoDB is a
prime choice for data storage.

5.1.2.3 REST API

The REST API approach uses Express JS as the back-end web server and MongoDB as
the document store. This concept easily maps MongoDB’s document model to the REST
API payloads which are JSON by nature.
We chose to deploy our NodeJS backend application in the AWS Elastic Beanstalk
platform. AWS Elastic Beanstalk platform as a service (PaaS) takes our application code
and deploys it while provisioning the supporting architecture and compute resources
required for our code to run. Beanstalk also fully manages the patching and security
updates for those provisioned

38
5.1.2.4 Cloud

5.1.2.4.1 FireStore

Figure 18: Cloud Firestore Logo

[source:
https://manuelernest0.medium.com/the-journey-of-firebase-cloud-firestore-52d0fe8362e9
]

Cloud Firestore is a flexible, scalable database for mobile, web, and server development
from Firebase and Google Cloud. Like Firebase Realtime Database, it keeps your data in
sync across client apps through real time listeners and offers offline support for mobile
and web so you can build responsive apps that work regardless of network latency or
Internet connectivity. Cloud Firestore also offers seamless integration with other Firebase
and Google Cloud products, including Cloud Functions [19].

5.1.2.4.2 Amazon EC2

Figure 19: Amazon EC2 Logo

[source: https://www.educative.io/answers/what-is-amazon-ec2]

Amazon Elastic Compute Cloud (Amazon EC2) provides scalable computing capacity in
the Amazon Web Services (AWS) Cloud. Using Amazon EC2 eliminates your need to
invest in hardware upfront, so you can develop and deploy applications faster. You can
use Amazon EC2 to launch as many or as few virtual servers as you need, configure
security and networking, and manage storage. Amazon EC2 enables you to scale up or
down to handle changes in requirements or spikes in popularity, reducing your need to
forecast traffic [20].

39
5.1.2.5 Auto Scaling

We have configured our AWS Elastic Beanstalk environment to include an Auto Scaling
group that manages the Amazon EC2 instances in our environment. In a single-instance
environment, the Auto Scaling group ensures that there is always one instance running. It
will also scale up and down in numbers to the required capacity to handle increasing and
decreasing loads alike.

5.1.2.6 Load Balancing

Together with that we deployed Elastic Load Balancing to automatically distribute our
incoming traffic across multiple targets of Beanstalk instances. It will monitor the health
of its registered targets, and route traffic only to the healthy targets. Elastic Load
Balancing scales our load balancer as our incoming traffic changes over time. It can
automatically scale to the vast majority of workloads [21].

5.1.2.7 Elastic Beanstalk

Elastic Beanstalk is a platform within AWS that is used for deploying and scaling web
applications. In simple terms, this platform as a service (PaaS) takes your application
code and deploys it while provisioning the supporting architecture and compute resources
required for your code to run. Elastic Beanstalk also fully manages the patching and
security updates for those provisioned resources [22].

5.1.2.8 Monitoring tool

5.1.2.8.1 AWS CloudWatch

Figure 20: AWS CloudWatch Logo

[source: https://aws.plainenglish.io/aws-cloudwatch-introduction-9750af3d91f9]

We also employ monitoring automation to add visibility into our project infrastructure.
By using AWS CloudWatch we can stream metrics and log out to the monitoring
dashboard to troubleshoot any problem we might face during development or releases.

40
5.1.2.9 Delivery pipeline

5.1.2.9.1 AWS CodePipeline

Figure 21: AWS CodePipeline Logo

[source: https://vecta.io/symbols/12/aws-developer-tools/3/aws-codepipeline]

We decided to use automation to aid our development process. By using AWS

CodePipeline we are enabling automatic code deployment to the AWS platform by
configuring the tool to watch for changes to specific branches in the Github repository.
This not only reduces errors when deploying manually but also increases the speed at
which we get the latest update of our code to the deployment environment.

Figure 22: AWS CodePipeline

[source: https://levelup.gitconnected.com/ci-cd-with-aws-codepipeline-a452c5b88c60]

41
5.1.2.10 Authentication

5.1.2.10.1 Firebase Authentication

Figure 23: Firebase Authentication Logo

[source:
https://www.linkedin.com/pulse/user-authentication-using-firebase-priyanshu-gaur?trk=p
ulse-article]

In addition to the client-side and server-side security architecture, we use Firebase

authentication which provides methods to create and manage users that use their email
addresses and passwords to sign in securely. Firebase Authentication integrates tightly
with other Firebase services, and it leverages industry standards like OAuth 2.0 and
OpenID Connect, so it can be easily integrated with our custom backend [23].

5.1.3 Team and Task Management

5.1.3.1 Jira

Figure 24: Jira Logo

[source: https://www.atlassian.com/software/jira]

Jira is a project management tool that supports the agile methodologies we use, which is
scrum. Our team used Jira to plan, assign, track and manage the workflow of our team.
Our team employed Jira features, such as project board, project backlog, roadmap, and git
repository features

42
5.1.3.2 Github

Figure 25: GitHub Logo

[source: https://1000logos.net/github-logo/]

Github is an online software development platform used for storing, tracking, and
collaborating on our team software project. Allowing us to upload our own code files,
track files revision, and to work together on projects from anywhere. We employed
essential features like repositories, branches, commits, and pull requests. We add and
modify files locally, then “push” our changes back to the repository where our changes
are displayed to the team enabling us to view changes to the document at different points
in time and able to revert files back to the old version.

5.1.3.3 Postman

Figure 26: POSTMAN Logo

[source: https://commons.wikimedia.org/wiki/File:Postman_%28software%29.png]

Postman is an API platform for building and using APIs. Postman simplifies each step of
the API lifecycle and streamlines collaboration so you can create better APIs—faster.
Using Postman will allow our team to access APIs which are developed by backend
developers [24].

5.1.3.4 GitKraken

Figure 27: GitKraken Logo

[source: https://www.gitkraken.com/store]

GitKraken is a graphical user interface for Git built on top of the Electron framework –
much like the popular Visual Code editor. GitKraken is cross-platform, which means that

43
developers can use it on Windows, Mac, and/or Linux. We used gitkraken for committing
or making changes to the Git repository. Moreover, Gitkraken also shows the summary of
the previous commit in the form of a graph [25].

5.2 Development Techniques

5.2.1 Agile Development Process

An Agile development process is applied to the software development methodologies
centered around the idea of iterative development, where requirements and solutions
evolve through collaboration. Scrum and Kanban are two of the Agile methodologies
and both are applied to our development process also.

Figure 28: Agile Development Process Cycle

[source:
https://orionadvisortech.com/blog/why-were-moving-to-agile-software-development/?pri
nt=print]

A timebox is a period of time during which a team works steadily towards the completion
of some goal. An iteration of the Agile process is a timebox during which development
takes place and each timebox is called a Sprint and counted as one cycle of development.
In this project, the duration of each sprint is two weeks long.

44
 Chapter 6

Preliminary Results

6.1 Frontend

6.1.1 High fidelity prototype

6.1.1.1 Request ambulance feature (user view)

Figure 29: Log-in & Sign-Up pages

45
Users are able to sign in or sign up by clicking a button in the landing page, and reset
password by clicking “Forget Password?” in the sign in page. If the user does not have an
account yet, the user can click “Don’t have an account yet?” to create an account. If the
user wants to complete the signup process, the user must also fill in the medical
information.

Figure 30: Main pages

Figure 31: Chat pages

To request an ambulance, the user must click the “SOS” button and fill out necessary
information. Then, click the “Request” button to request an ambulance. The estimated
time of arrival will be displayed. The user is also able to view the first aid procedures via
the first aid page while waiting for the ambulance. After the ambulance arrives, the user
must click the “confirm arrival” button to confirm the arrival of an ambulance and the
status will be reported to the hospital. The user is able to chat with and call the medical
staff assigned by the hospital via chat page.

46
6.1.1.2 Request Ambulance feature (hospital view)

Figure 32: Request pages (1)

After the hospital admin signs in, the list of emergency incidents will be displayed. The
admin can choose to accept or decline the incidents by clicking either the “Accept” ot
“Decline” button. The hospital staff can view the details of the incident by clicking the
emergency ID of the desired emergency.

Figure 33: Request pages (2)

For the emergency detail page, the first photo is the detail of an emergency that includes
the medical information registered on our system (the caller is a patient). Meanwhile, the
second photo does not include the medical information (the caller is not the patient).

47
 Figure 34: Staff page

The hospital staff can view the status of the dispatched ambulance in the “Ambulance
status” page.

6.1.1.3 Profile page

Figure 35: Profile page

The user can manage their profile by clicking on the profile icon in the navigation bar.
The user can edit their medical information, View ambulance history, disable or enable
location sharing, and disable or enable their own NFC.

48
6.1.1.4 In Case of Emergency event

Figure 36: Emergency pages

The user can view the list of contact’s events and their own events. To view the detail, the
user can simply click the determined event and the event detail page will be displayed.
Also, the user can add more ICE contacts by clicking + button. By clicking the “Create
your event” button, the system will navigate the user to the create event page where the
user can choose the desired contact(s), input all the information about the event. When the
user presses the “Create event” button, the event will be created. Lastly, the user can
remove the event by clicking the “Remove” button.

49
6.2 Backend

6.2.1 Github repository

Figure 37: Github backend repository

GitHub repository for backend development has been created and shared among the team
members. Allowing all team members to access the same code and work together on the
same project via GitHub.

50
6.2.2 Database connection

6.2.2.1 MongoDB

The database for storing text data in backend development has been created and
established. And we created data collections for testing purposes.

Figure 38: Database connection

Figure 39: Database collections

51
6.2.3 Firebase

The connection for Firebase has been established. We successfully connected to our
Firebase project and tested the authentication process.

Figure 40: Firebase connection

6.2.4 CRUD
All CRUD for the APIs has been implemented and tested that it is working properly via
Postman.

APIs documentation:
https://documenter.getpostman.com/view/16038273/2s8YzWR1DB

Request Path Http Method Action

Create new
Address /address POST
address

/addresses GET Get all addresses

/address/:id GET Get address by id

Update address
/address/:id PUT
by id

Delete address by
/address/:id DELETE
id
Table 2: Address API

52
 Create new
Emergency case /emergency/case POST
emergency case

Get all emergency

/emergency/cases GET
cases

Get emergency
/emergency/case/:id GET
case by id

Update
/emergency/case/:id PUT emergency case
by id

Delete emergency
/emergency/case/:id DELETE
case by id
Table 3: Emergency case API

Create new
Emergency
/emergency/contact POST emergency
contact
contact

Get all emergency

/emergency/contacts GET
contacts

Get emergency
/emergency/contact/:id GET
contact by id

Get emergency
/emergency/contact/user
GET contacts by user
/:userid
id

Update
/emergency/contact/:id PUT emergency
contact by id

Delete emergency
/emergency/contact/:id DELETE
contact by id
Table 4: Emergency contact API

53
Hospital /hospital POST Create new
hospital

/hospitals GET Get all hospitals

/hospital/:id GET Get hospital by id

/hospital/address Get hospitals by

GET
/:addressid address id

Update hospital
/hospital/:id PUT
by id

Delete hospital by
/hospital/:id DELETE
id
Table 5: Hospital API

Create new
Insurance /insurance POST
insurance

/insurances GET Get all insurances

Get insurances by
/insurance/user/:userid GET
user id

Get insurance by
/insurance/:id GET
id

Update insurance
/insurance/:id PUT
by id

Delete insurance
/insurance/:id DELETE
by id
Table 6: Insurance API

54
 Create new
Medical
/medical/information POST medical
Information
information

Get all medical

/medical/informations GET
informations

Get medical
/medical/information/:id GET
information by id

Update medical
/medical/information/:id PUT
information by id

Delete medical
/medical/information/:id DELETE
information by id
Table 7: Medical Information API

Medical staff Create new

/medical/staff POST
medical staff

Get all medical

/medical/staffs GET
staffs

Get medical staff

/medical/staff/:id GET
by id

/medical/staff/hospital Get medical staffs

GET
/:hospitalid by hospital id

Update hospital
/medical/staff/:id PUT
staff by id

Delete hospital
/medical/staff/:id DELETE
staff by id
Table 8: Medical staff API

NFC /nfc POST Create new NFC

/nfcs GET Get all NFCs

/nfc/:id GET Get NFC by id

/nfc/:id PUT Update NFC by id

/nfc/:id DELETE Delete NFC by id

Table 9: NFC API

55
User user POST Create new user

users GET Get all users

user/:id GET Get user by id

user/:id DELETE Delete user by id

Table 10: User API

56
 Chapter 7

Current Progress and Future Plans

7.1 Current Progress

In the planning and analysis process, we did an interview with potential users, including
Dr. Gun medical staff at Siriraj Hospital, Ms. Nattawan medical student in United
Kingdom, Ms. Ginjutha pharmacy student at Mahidol University, Mr. Chatetha who had
experience in requesting an ambulance and an anonymous person who was the victim of
crime, then we analyze the results and adapt it to our requirements. After that we have
designed multiple diagrams such as ER diagram, use case diagram and architecture
diagram to support our program before implementing the code.

We have passed the phase of planning, analyzing, and designing. Most of our main UI
including sign-in, sign-up, medical information, home, and ambulance request page has
already been implemented. During each process, we also record and document this report.

For the back-end part, we have established database connections for mongoDB and
firebase and implemented our database models and CRUD. Moreover the APIs have been
tested with mockup data to ensure that it is working properly. After that, we also create
APIs documentation via Postman since we used Postman to test out our APIs. Our APIs
documentation includes sample requests and responses. Currently, we are in the phase of
implementing where we have to integrate the back-end part to our application and
implement side features.

57
7.1.1 Gantt Chart

Figure 41: Gantt chart

58
7.2 Future Plan
7.2.1 Google Maps

Figure 42: Google Maps Platform

[source: https://mapsplatform.google.com/]

We will implement Google Map Platform api into our application in order to embed
Google Maps into mobile apps and web pages, or to retrieve data from Google Maps. We
might also implement Google Map Directions API and Google Map Distance Matrix to
show the direction and distance between two locations. However, both services use a
pay-as-you-go pricing model.

7.2.2 NFC

Figure 43: NFC connection

[source: https://gorillalogic.com/blog/mobile-nfc-a-practical-use-case-part-ii/]

We will implement the NFC card feature where users can read or write data in the NFC
card. The data that is stored in the NFC card or we could say linked to the NFC card will
be stored in our MongoDB database. NFC data could also be managed using GoToTags

59
Encoder. GoToTags is a Software to encode NFC tags that allows us to encode NFC tags
and integrate the encoding data into our system.

7.2.3 CI/CD

Figure 44: CI/CD

[source: https://faun.pub/most-popular-ci-cd-pipelines-and-tools-ccfdce429867]

CI/CD is a two-step process that streamlines code development and delivery using
automation. We will implement CI/CD practice to reduce the developers' workload. The
process makes it possible to identify issues and solve them more quickly. Additionally,
CI/CD helps in fast system update releases and quick reaction to customer feedback.

7.2.4 Testing

Figure 45: Chai & Mocha

[source:
https://medium.com/the-web-tub/mocha-chai-js-unit-testing-for-es6-with-istanbul-code-c
overage-11b2a141a446]

60
In the future we will use Chai and/or Mocha for unit testing as it makes a small part of the
system to carry out a task and then evaluate the outcome. A failed unit test clearly
identifies the problematic part of the code to easily pinpoint the problem and fix it.

Figure 46: Robot Framework

[source: https://robotframework.org/]

Robot Framework could also be implemented for automated testing. Software testers are
prone to mistakes when manually testing a system, especially when an application has
many lines of code. Testing is made easier for the QA by automation, which also
streamlines check execution compared to manual testing.

7.2.5 Deploying
At some point in the future we will start deploying our frontend application in Vercel and
our backend application in the AWS Elastic Beanstalk platform. Even Though we deploy
our application early, we can still update the application and fix the error quickly using
CI/CD process.

7.2.6 Features
One major problem that we face is that this application is an application that is rarely
used, or you could say users do not want to open our application often, as it is used for
emergency cases and used when the user feels unsafe. We intend to develop a new feature
in the future that will let users use our app more frequently and use the application when
they want to, not when they need to. One feature that we came up with is first-aid and
health information which will show first-aid basics and guide to healthy living.

61
 Bibliography

[1] “What Is a Rest Api?” Red Hat - We Make Open Source Technologies for the
Enterprise, https://www.redhat.com/en/topics/api/what-is-a-rest-api.
[2] “What Is RESTful API?” Amazon, The University, 1978,
https://aws.amazon.com/what-is/restful-api/.
[3] “What Is Crud?” Codecademy, https://www.codecademy.com/article/what-is-crud.
[4] “Cross-Platform App Development - Explore Frameworks, Technology and Business
Benefits.” ASPER BROTHERS, 29 Oct. 2022,
https://asperbrothers.com/blog/cross-platform-app-development/.
[5] Admin. “What Are the Benefits of Cross-Platform Application Development?”
Techmango, 2 June 2022,
https://www.techmango.net/what-are-the-benefits-of-cross-platform-application-develop
ment#:~:text=What%20are%20the%20benefits%20of%20cross%2Dplatform%20apps%3
F,platforms%20instead%20of%20just%20one.
[6] The Pros and Cons of Cross-Platform Apps.
https://www.focaloid.com/blog/the-pros-and-cons-of-cross-platform-apps/.
[7] “What Is Nosql? NoSQL Databases Explained.” MongoDB,
https://www.mongodb.com/nosql-explained.
[8] “Advantages of Nosql.” MongoDB,
https://www.mongodb.com/nosql-explained/advantages.
[9] “What Are the Pros and Cons of Nosql.” Adservio,
https://www.adservio.fr/post/what-are-the-pros-and-cons-of-nosql.
[10] Mamun, Al Mahmud Al. “NoSQL Databases: When to Use NoSQL VS SQL.”
ServerWatch, ServerWatch, 19 Jan. 2022,
https://www.serverwatch.com/guides/when-to-use-nosql/.
[11] Contributor, TechTarget. “What Is Web Application (Web Apps) and Its Benefits.”
SearchSoftwareQuality, TechTarget, 26 Aug. 2019,
https://www.techtarget.com/searchsoftwarequality/definition/Web-application-Web-app.
[12] “What Are Cloud Services?” Red Hat - We Make Open Source Technologies for the
Enterprise,
https://www.redhat.com/en/topics/cloud-computing/what-are-cloud-services#what-are-ex
amples-of-cloud-services.

62
[13] Preetham. “Git Branching and Branching Strategy.” DEV Community , DEV
Community , 10 July 2020,
https://dev.to/preethamsathyamurthy/git-branching-and-branching-strategy-4mci.
[14] “What Is an NFC Chip?” STMicroelectronics,
https://www.st.com/content/st_com/en/support/learning/essentials-and-insights/connectivi
ty/nfc/nfc-chips.html.
[15] “React (JavaScript Library).” Wikipedia, Wikimedia Foundation, 8 Nov. 2022,
https://en.wikipedia.org/wiki/React_(JavaScript_library).
[16] Server-Side - Wikipedia. https://en.wikipedia.org/wiki/Server-side.
[17] Sharma, Anubhav. “Express JS Tutorial: What Is Express in Node JS?”
Simplilearn.com, Simplilearn, 13 Oct. 2022,
https://www.simplilearn.com/tutorials/nodejs-tutorial/what-is-express-js.
[18] Taylor, David. “What Is Mongodb? Introduction, Architecture, Features &
Example.” Guru99, 12 Nov. 2022, https://www.guru99.com/what-is-mongodb.html.
[19] “Firestore | Firebase.” Google, Google, https://firebase.google.com/docs/firestore.
[20] What Is Amazon EC2? - Amazon Elastic Compute Cloud.
https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/concepts.html.
[21] What Is an Application Load Balancer? - Elastic Load Balancing.
https://docs.aws.amazon.com/elasticloadbalancing/latest/application/introduction.html.
[22] Hava, Team. “What Is AWS Elastic Beanstalk?” Azure, GCP, Kubernetes and AWS
Diagrams Automated, Hava Pty Ltd, 25 Aug. 2021,
https://www.hava.io/blog/what-is-aws-elastic-beanstalk.
[23] “Firebase Authentication.” Google, Google, https://firebase.google.com/docs/auth.
[24] Postman, https://www.postman.com/.
[25] Berry, Chris. “Git Made Easy with Gitkraken.” Keyhole Software, 19 Jan. 2021,
https://keyholesoftware.com/2021/01/19/git-made-easy-with-gitkraken/.

63