Telemedicine and e-Health

Project Report
Faculdade de Engenharia da Universidade do Porto
Academic Year: 2016/17

Professor João Paulo Cunha

Dominika Šaulikova, Gerwin John Rodriguez, Tiago
Gonçalves
ABSTRACT

One of the greatest problems in the flight industry is the need of proceeding with an
emergency landing when a passenger claims to not feeling good or when specific signs
of illness are shown. This involves a great amount of money and time consuming
procedures to the flight companies. In order to overcome these problems and to do more
accurate diagnostics and better decisions we need a tool that reads the vital signs of the
subject and where we can describe basic symptoms, then sends it to a Hospital where a
doctor will analyse the data and send his official opinion about what is really happening.
Based on this opinion, the captain of the plane would then execute a better decision. In
this project we propose a model that takes into account the vital signs that we need to
record, the technology needed to send data, what will be the destination of that data, who
will evaluate it, and how will the decision be made. This work is also be based on the
current state of art and will try to give some new approach and suggestions to what we
have nowadays.

1. INTRODUCTION

The history of aviation starts in the 16th, 17th and 18th centuries with the first research on
aerodynamics (i.e. the study of the forces operating on a solid body) being done by
important scientists such as Leonardo da Vinci and Galileo Galilei, in Italy. Christiaan
Huygens, in the Netherlands, and Isaac Newton, in England, gave important contributions
on the understanding of the relationship between resistance and the surface area of an
object exposed to the stream and the density of a fluid. The relationship between pressure
and velocity was explained by mathematicians Daniel Bernoulli and Leonhard Euler and
British engineer John Smeaton, which helped a later generation of engineers to calculate
aerodynamic forces. Although there are more important names in the history of aviation,
it’s practically undeniable that the turning point happened when the Wright brothers
started to revolutionize the airplane industry in the beginning of the 20th century. [1]

Nowadays, society is used to airplanes as a fast and safe mean of transport, between
continents, countries, states or even cities. The commercial aviation is getting really
popular, especially since the introduction of low-cost services, turning flights accessible
to a bigger amount of people of a variety of social classes. Still, everything has its own
problems and, in the case of commercial aviation, one of them, and where a great amount
of money is consumed, is the problem of doing an emergency landing when a passenger

1
claims to not feeling good or when specific signs of illness are shown. It is estimated that
about forty-four thousand in flight medical emergencies occur worldwide each year, that
star a complex, structured and expensive response that companies struggle to handle. [2]

What are the costs of an emergency landing? First of all, diverting an aircraft is not as
easy as it may seem. Depending on where is the aircraft on the journey, it can be severely
overweight for landing (too much fuel in the tanks can take a great amount of work on
the brakes to stop the aircraft and, at the same time, if they are pushed to the limit and a
reach a very high temperature, there is the necessity of inspection or replacement). On the
other hand, the landing fees that several airlines charge and the environmental and
functional costs of wasting fuel to do an emergency landing represent a big part of a
problem, which solution needs to be improved. [3]

In general, airline companies are prepared, in one way or another, to the fact that a medical
emergency can occur and there several protocols that can help flight crews to be ready to
act in such situations. [4]

Although there are already companies which already have their own procedures or that
already collaborate, telephonically, with a medical consultant on ground in case of these
situations [5], we propose a telemedicine system that, in the case of medical situation,
could read the principal vital signs (body temperature, pulse rate, breathing rate and blood
pressure) [6,7] and then send this data to a medical doctor on ground, through
telecommunication, that will analyse it and then support the captain of the flight to decide
if it is better or not to proceed to an emergency landing and to approve his decision
together with the airport that will receive the aircraft. This work is based on the current
state of art, which enlighten us about the sending of in-flight continuous vital signs
telemetry via the Internet [8] and the cellular radio telecommunication for health care [9],
and it’s expected that the model presented here has pertinent solutions to the nowadays’
problems.

2. METHODOLOGY

The development of this work is based on three distinct phases:

1. Gathering of information: In order to develop an updated model of the system we

have idealized we need to be aware of the current state of art. To do this, the
reading of several scientific articles, newspaper articles and reviews is very

2
 important. On the other hand, doing a correct selection and filtering of the
information that was gathered is crucial in order to have good pathway to the
development and execution of this project.
2. Getting the requirements: After checking all the information, the next step is all
about choosing what we really want to see implemented in our model. As it is
known, it is very important to establish priorities on the functions that we want
our system to execute in this initial phase, so, the work will be focused on that.
3. Designing the project: Using Visual Paradigm and Pencil, the project will be
designed and we will obtain an organized structure of our model. Based on this
structure it is possible to understand how the system works.

3. REQUIREMENTS

This system has to be capable of fulfilling the following requirements:

a) Connection to the internet: the system has to be connected through 5G or 4G

mobile network system.
b) Connection to the airports systems, so the flight can be identified online. Every
time the plane takes flight, the system is initiated and the flight is identified after
the input of some code that identifies the flight.
c) Connection to the list of passengers in that flight in order to immediately choose
the passenger that will be analysed with the system.
d) Connection to the Hospital where the medical doctor will analyse the report,
through a special platform.
e) The machine must have the capability of reading, what are considered nowadays,
vital signs: body temperature, pulse rate, respiration rate (breathing rate) and
blood pressure.
f) Take notes on what the patient is feeling in order to generate a list of symptoms
(these notes are an input of the flight assistant and are written based on what is
said by the patient).
g) Receive calls through the platform so the doctor could talk with the patient and to
the Captain of the flight in order to generate a final decision that will lead (or not)
to the emergency landing.

3
4. ACTORS

4.1 Diagram

Figure 1 - Actor Diagram.

4.2 Cabin crew

Cabin crew is the team of members of the flight that as IDs and passwords to access the
system and that performs the initial procedures when the passenger is feeling sick.

4.3 Passenger

The passenger is the client of the flight services.

4.4 Captain

The Captain of the flight is the person in charge of establishing the decision to perform
an emergency landing or not.

4.5 Hospital

The Hospital is the entity that will provide support in terms of clinical procedures in the
plain and will also help the Captain to establish a final decision.

4.6 Airport

The Airport is the entity that will receive and accept the decision of the Captain, along
with the approval of the Hospital, of performing the emergency landing.

4
5. USE CASE & ACTIVITY DIAGRAMS

Figure 2 - FlySafe System Use Case Diagram.

Figure 3 - FlySafe System Activity Diagram.

5
6. USE CASE EXPLANATION & STEP-BY-STEP OUTLINES

Get Patient's Info Use Case

1. Brief Description

This use case allows a member of the cabin crew to access basic data about the passenger
that is facing the problem. When this option is selected, the list of passengers in that
specific flight appears and the cabin crew member just needs to choose.

2. Flow of Events

2.1 Basic Flow

2.1.1. Log on

This use case starts when the cabin crew member initiates the system. The system will
ask for identification information and the member will enter his personal ID and

password. The system will validate the information.

2.1.2. Select "Choose ID"

The list of passengers in the flight appears. The member only needs to choose the right
one from the list.

2.1.3. Select "Confirm ID"

The information about the patient appears and the member only needs to confirm that the
passenger is well chosen.

2.1.4. Go to next step

This option allows the user to move on to the next step (i.e next Use Case).

2.2 Alternative Flow

2.2.1. Unidentified member

In the step 1, Log on in the Basic Flow, if the system determines that the member ID and
password are not valid, an error message appears and the user cannot proceed to the next
step. The use case ends.

2.2.2. Quit

6
At any time during the procedures, the user has the option to quit without saving anything.

3. Special Requirements

None.

4. Preconditions

The passenger's list of that flight is already synchronized with the system.

5. Postconditions

At the end of this use case either the passenger was chosen and the user can proceed to
the next step or there was no need to proceed and the system could be shut down with no
saved changes.

6. Extension Points

None.

7. Scenarios

Get Patient's Info: Basic Flow

Unidentified member: Basic Flow, Unidentified member

Quit: Basic Flow, Quit

Read Vital Signs Use Case

1. Brief Description

This use case allows the member of the cabin crew to connect the sensors to the passenger
and start the reading of the vital signs.

2. Flow of Events

2.1 Basic Flow

2.1.1. Connect sensors

After the selection of this options, a brief step-by-step guide appears to help the cabin
crew member to connect the sensors in the right place of the body of the patient. The

7
guide has check boxes that the member selects to instruct the program that a specific
action is concluded.

2.1.2. Start Reading

The user selects this option and the program starts the reading of the vital signs of the
patients. All the data is automatically saved.

2.1.3. Confirm reading

The program asks the user to confirm the obtained readings.

2.1.4. Proceed to next step

The user chooses this option to proceed to the next Use Case.

2.2 Alternative Flow

2.2.1. Read Vital Signs again

In Confirm Reading, step 3 of Basic Flow, if some type of reading error is detected by
the program, a popup notification appears and asks the user to read vital signs again.

2.2.2. Quit

At any time during the procedures, the user has the option to quit without saving anything.

3. Special Requirements

The system must have the ability to read vital signs in the maximum time of three minutes
and to instantaneously save the information within a minute.

4. Preconditions

The reading sensors must be already connected to the system before the start of the use
case.

5. Postconditions

At the end of the use case, vital signs must be read and saved in the system.

6. Extension Points

None.

7. Scenarios

8
Read Vital Signs: Basic Flow

Read Vital Signs again: Basic Flow, Read Vital Signs again

Quit: Basic Flow, Quit

Get Patient's Symptoms Use Case

1. Brief Description

This use case allows the cabin crew member to take notes of what the patient is feeling
in that moment.

2. Flow of Events

2.1 Basic Flow

2.1.1 Create note

The user selects this option and a white page appears.

2.1.2 Confirm note

After writing the relevant information on what is being felt by the patient, the user selects
this option to confirm the note.

2.1.3 Go to report

This option appears after the confirmation of the notes that were taken by the user. The
user selects this option and the program proceeds to the next use case.

2.2 Alternative Flow

2.2.1 Edit note

After the Confirm note, step 2 in the Basic Flow, along with the Go to report, step 3 in
the Basic Flow, notification, the user has the option to edit the note (for example, to add
more important information).

2.2.2 Quit

At any time during the procedures, the user has the option to quit without saving anything.

3. Special Requirements

9
The system must have the capability of saving the created note within 20 seconds.

4. Preconditions

None.

5. Postconditions

It is mandatory to have any type of information written in the note, so the program can
advance to next steps.

6. Extension Points

None.

7. Scenarios

Get Patient's Symptoms: Basic Flow

Edit note: Basic Flow, Edit note

Quit: Basic Flow, Quit

Generate Report Use Case

1. Brief Description

This use case allows the user to compile all the gathered information in a report that will
be prepared to be sent to the Hospital.

2. Flow of Events

2.1 Basic Flow

2.1.1 Generate Report

This option starts this use case. After the selection, a formatted report appears.

2.1.2 Confirm Report

The selection of this option ends the use case and starts the next one.

2.2 Alternative Flow

2.2.1 Quit

The user can quit any time during the use case. None of the information is saved.

10
3. Special Requirements

The time needed to generate the report must no surpass twenty seconds

4. Preconditions

None.

5. Postconditions

The report will be formatted and the program will move forward to the next step.

6. Extension Points

None.

7. Scenarios

Generate Report: Basic Flow

Quit: Basic Flow, Quit

Send Report Use Case

1. Brief Description

This use case allows the user to send the report to the nearest Hospital that has the system
installed.

2. Flow of Events

2.1 Basic Flow

2.1.1 Select available Hospital

A list of the nearest available Hospitals (that have the system installed) appears and the
user is able to choose one of them.

2.1.2 Send report

This option appears after the user's choice on the Hospital. The user just need to click a
button and the report is immediately sent.

2.2 Alternative Flow

11
2.2.1 Quit

At any time during the procedures, the user has the option to quit without saving anything.

3. Special Requirements

The GPS system must be considerably fast to detect the nearest available Hospitals.

4. Preconditions

The Hospitals with the system installed must be synchronized with the system present in
the planes.

5. Postconditions

The report is sent and the Hospital will receive a notification within the system interface
for Hospitals.

6. Extension Points

None.

7. Scenarios

Send Report: Basic Flow

Quit: Basic Flow, Quit

Receive Report Use Case

1. Brief Description

This use case allows the Hospital to receive the report from the flight, through an interface
of the system that is installed in the computers of the Hospital. The report will be received
and analysed by a Medical Doctor.

2. Flow of Events

2.1 Basic Flow

2.1.1 Open report

A notification appears on the interface installed in the computer from the Hospital. An
authorized user (a Medical Doctor) selects the notification and opens the report.

12
2.1.2 Mark as read

After the analysis of the report the user selects this option to notify the plane that the
report is read. The selection of this option is mandatory to initiate the next use case.

2.2 Alternative Flow

None.

3. Special Requirements

None.

4. Preconditions

Connection to the servers of the system.

5. Postconditions

The report is mark as read and the Medical Doctor can proceed to the next use case.

6. Extension Points

None.

7. Scenarios

Receive Report: Basic Flow

Make Call Use Case

1. Brief Description

This use case allows the Hospital to contact with the flight through a call, executed
between the interface at the Hospital and the interface present in the flight.

2. Flow of Events

2.1 Basic Flow

2.1.1 Call flight

This option is selected after marking the report as read. A screen with the call appears.
On the side of the screen there is a dashboard to receive possible pictures or video.

13
2.2 Alternative Flow

2.2.1 Quit

At any time during the procedures, the user has the option to quit without saving anything.

3. Special Requirements

Good connection to the internet is required to have a good quality call.

4. Preconditions

None.

5. Postconditions

The call stays active.

6. Extension Points

None

7. Scenarios

Make Call: Basic Flow

Quit: Basic Flow, Quit

Receive Call Use Case

1. Brief Description

This use case allows the interface on the flight to receive the call made by the Hospital
on ground.

2. Flow of Events

2.1 Basic Flow

2.1.1 Answer Call

A screen with this single option appears. The user has to click the notification to answer
the call.

2.2 Alternative Flow

14
None.

3. Special Requirements

Good internet connection is required to have a good quality call.

4. Preconditions

None.

5. Postconditions

After the answering the call stays active and the program proceeds to the next use case.

6. Extension Points

None.

7. Scenarios

Receive Call: Basic Flow

Answer Call Use Case

1. Brief Description

This use case allows the user in the flight (in this case, the Captain) to maintain the call
and to send pictures or videos, if requested by the medical doctor at the Hospital, on
ground. A dashboard on the screen will be present in order to send media.

2. Flow of Events

2.1 Basic Flow

2.1.1 Send media

This option allows the user to send pictures or videos. The media is recorded directly
through the screen of the use case.

2.2 Alternative Flow

None.

3. Special Requirements

15
The system has to have a camera connected in order to record and send media.

4. Preconditions

None.

5. Postconditions

The call can last until a decision is made.

6. Extension Points

None.

7. Scenarios

Send Media: Basic Flow

Decide landing Use Case

1. Brief Description

This use case allows the user (in this case, the Captain) to register the decision made with
the evaluation of the medical doctor at the Hospital.

2. Flow of Events

2.1 Basic Flow

2.1.1 Select decision

This is thick box where the Captain can select the decision to do an emergency landing
(and, consequently, communicate with the nearest Airport) or the decision to not do an
emergency landing and proceed with principal flight plan. This decision will be saved in
the system and maintained in the historic of decisions.

2.2 Alternative Flow

None.

3. Special Requirements

None.

16
4. Preconditions

None.

5. Postconditions

The decision is to do an emergency landing and the system proceeds to the next use case
or the system is not to do an emergency landing and the system can be shut down.

6. Extension Points

None.

7. Scenarios

Decide landing: Basic Flow

Communicate Landing Use Case

1. Brief Description

This use case allows the user in the flight (in this case the Captain) to contact the nearest
Airport, while in call with the medical doctor at the Hospital.

2. Flow of Events

2.1 Basic Flow

2.1.1 Contact Airport

This option will open a list of available airports. The user can select the nearest one and
start communication.

2.1.2 Save Decision

This option is a record of the decision that is proposed and will be saved in the system.
This is done through a checklist where the Captain, after the decision, selects the option.

2.2 Alternative Flow

None.

3. Special Requirements

17
The system needs to be sufficiently fast to update the list of available and nearest airports
in agreement with the services of location (via GPS).

4. Preconditions

The system must be connected to some kind of server or database to automatically detect
which airports actually exist and are available.

5. Postconditions

After the establishment of communication, the Airport, the Captain and the Hospital are
connected.

6. Extension Points

None.

7. Scenarios

Communicate Landing: Basic Flow

Approve Landing Use Case

1. Brief Description

This use case allows the medical doctor at the Hospital to send an approval proof of the
urgency and validity of the emergency landing request made by the Captain.

2. Flow of Events

2.1 Basic Flow

2.1.1 Send approval

This is a pop-up window with a button to send the approval directly to the Airport, through
the interface of the system.

2.2 Alternative Flow

None.

3. Special Requirements

None.

18
4. Preconditions

None.

5. Postconditions

None.

6. Extension Points

None.

7. Scenarios

Approve landing: Basic Flow

7. FLYSAFE SYSTEM MOCK-UPS

Figure 4 - Get Patient's Info Mock-up.

19
Figure 5 - Read Vital Signs Mock-up.

Figure 6 - Get Patient's Symptoms Mock-up.

20
Figure 7 - Generate Report & Send Report Mock-ups.

Figure 8 - Receive Report & Make Call Mock-ups.

21
Figure 9 - Receive Call & Answer Call Mock-ups.

Figure 10 - Decide Landing & Communicate Landing Mock-ups.

22
Figure 11 - Approve Landing Mock-up.

8. CONCLUSIONS & FURTHER WORK RECOMMENDATIONS

The development of this project showed us how complex and difficult could be the
idealization of a system and the transcription of it to a model. From the idealization of the
system, to the development of requirements and, finally, the usage of Visual Paradigm
and Pencil to generate diagrams and mock-ups was an important factor in the process of
acquiring knowledge and know on this field of software engineering and telemedicine.
Overall, as a conclusion, we are satisfied with the system that we proposed and we think
that is a feasible thing to put in practice in the future.

For further work recommendations, it would be interesting to see and evaluate the
implementation of this system to check if it would be running according to the main plan.

23
REFERENCES
1. Bilstein, Roger E., Crouch, Tom D. and Boyne, Walter James. history of flight.
Encyclopædia Britannica. [Online] [Cited: 22 May 2017.]
https://www.britannica.com/technology/history-of-flight.

2. Taschler, Joe. For in-flight medical emergencies, airlines follow detailed game plan.
The Milwaukee Journal Sentinel. [Online] [Cited: 23 May 2017.]
http://archive.jsonline.com/business/for-in-flight-medical-emergencies-airlines-follow-
detailed-game-plan-b99138188z1-232204581.html.

3. Martin, Grant. How much does an airplane diversion cost? Gadling. [Online] 19
August 2008. [Cited: 23 May 2017.] http://gadling.com/2008/08/19/how-much-does-an-
airplane-diversion-cost/.

4. Medical Emergencies - Guidance for Flight Crew. Skybrary. [Online] [Cited: 23

May 2017.] http://www.skybrary.aero/index.php/Medical_Emergencies_-
_Guidance_for_Flight_Crew.

5. Taylor, Marygrace. Here’s What Happens If You Have a Medical Emergency—

35,000 Feet In the Air. Men's Health. [Online] 18 April 2016. [Cited: 23 May 2017.]
http://www.menshealth.com/health/medical-emergency-on-airplane.

6. Vital Signs (Body Temperature, Pulse Rate, Respiration Rate, Blood Pressure).
JOHNS HOPKINS MEDICINE. [Online] [Cited: 23 May 2017.]
http://www.hopkinsmedicine.org/healthlibrary/conditions/cardiovascular_diseases/
vital_signs_body_temperature_pulse_rate_respiration_rate_blood_pressure_85,P0
0866/ .

7. Fish, Tim. Patient's Guide to Vital Signs. RxEconsult. [Online] 25 October 2011.
[Cited: 23 May 2017.] http://www.rxeconsult.com/healthcare-articles/Patients-
Guide-to-Vital-Signs-74/.

8. In-flight continuous vital signs telemetry via the Internet. A., Gandsas, et al. 2000,
Aviation, space and environmental medicine.

9. Cellular radio telecommunication for health care: benefits and risks. CA.,
Sneiderman and MJ., Ackerman. 2004, Journal of the American Medical
Informatics Association.

24


AUTHOR’S SIGNATURES

25