Digital Titties

Dissertation Thesis, Alexandra BOLOVAN, Faculty of Engineering in Foreign Languages, UPB,
2023
UNIVERSITY “POLITEHNICA” OF BUCHAREST

FACULTY OF ENGINEERING IN FOREIGN LANGUAGES
COMPUTERS AND INFORMATION TECHNOLOGY
DISSERTATION PROJECT
Bucharest
2023
1
2023
UNIVERSITY “POLITEHNICA” OF BUCHAREST
FACULTY OF ENGINEERING
IN FOREIGN LANGUAGES
Digital twin for frailty prevention and

management
Project coordinator Student:

Conf. Dr. Ing. Andrei Alexandra BOLOVAN
VASILĂȚEANU
Bucharest
2023
2
2023
“POLITEHNICA” UNIVERSITY OF BUCHAREST

FACULTY OF ENGINEERING IN FOREIGN LANGUAGES
Approved
Director of department:
Prof. dr. ing. Bujor Pavaloiu
DISSERTATION PROJECT THEME FOR:

Alexandra BOLOVAN
1. Theme title:
Digital twin for frailty prevention and management
Folosirea gemenilor digitali pentru preventia si tratarea fragilitatii
2. Initial design data:
The application uses existing frameworks for dashboards in python and data processing
techniques from actual sensors.
3. Student contribution:
- search for relevant bibliography
- design application logic
- design user interface
- implement required software
4. Compulsory graphical material:
UML diagrams
5. The paper is based on the knowledge obtained at the following study courses:
- Software Design Techniques, Software architectures, Programming paradigms,
Technologies for Big Data.
6. Project development environment:

Pycharm, Microsoft Office, Astah Professional, Netbeans IDE
7. The project serves as:

Development
8. Paper preparation date:
June 2023
Project coordinator Student:
Alexandra BOLOVAN
3
2023
Academic Honesty Statement
I, Alexandra BOLOVAN, hereby declare that the work with the title “Digital twin for
frailty prevention and management”, to be openly defended in front of the dissertation
examination commission at the Faculty of Engineering in Foreign Languages, University
"Politehnica" of Bucharest, as partial requirement for completing the masters degree in system
engineering, is the result of my own work, based on my work.
The thesis, simulations, experiments and measurements that are presented are made
entirely by me under the guidance of the scientific adviser, without the implication of persons
that are not cited by name and contribution in the Acknowledgements part.
The thesis has never been presented to a higher education institution or research board in
the country or abroad.
All the information used, including the Internet, is obtained from sources that were cited
and indicated in the notes and in the bibliography, according to ethical standards. I understand
that plagiarism is an offense and is punishable under law.
The results from the simulations, experiments and measurements are genuine.
I understand that the falsification of data and results constitutes fraud and is punished according
to regulations.
Alexandra BOLOVAN
June 2023
Table of Contents
4
2023
Academy honesty statement...................................................................................................... 4
Table of figures..........................................................................................................................7
1. Introduction...........................................................................................................................8
1.1. Context of research........................................................................................................ 8
1.2. Research objective......................................................................................................... 9
1.3. DT and MAS...................................................................................................................9
1.4. Structure of thesis........................................................................................................ 15
2. State of the Art.....................................................................................................................16
2.1 Definitions .....................................................................................................................16
2.2 Usage and anatomy of digital twins ............................................................................17
2.3 Healthcare and frailty applications............................................................................ 21
3. Requirement analysis.......................................................................................................... 30
3.2 Functional requirements.............................................................................................. 30
3.2 Non-functional requirements....................................................................................... 31
3.3 Use cases.........................................................................................................................32
3.4 Activity diagram............................................................................................................33
4.Design................................................................................................................................... 35
4.2 General architecture .................................................................................................... 35
4.2 Package diagram...........................................................................................................37
4.3 Deployment diagram………………….……………………………………….……..38
4.4 Sequence diagrams........................................................................................................39
5.Implementation.....................................................................................................................40
5.1 Technologies used..........................................................................................................40
5.2 Logical flow – backend................................................................................................. 41
5.2.1 Version 1…………………………..…………………………………….……..…….41
5
2023
5.2.2 Version2………………………………………………………………………….…..45
6.Results...................................................................................................................................47
6.1 Version 1………………………………………………………………….……………47
6.2 Version 2 ………………………………………………………………………..……..49
6.3 Conclusion and future work....................................................................................... 51
7. References............................................................................................................................51
8. Glossary .............................................................................................................................. 54
6
2023
Table of figures
Figure 1. Digital twin concept within MBSE (Model Based Systems Engineering)
Framework.[10] …………………………………………………………………………….10
Figure 2 .Prometheus methodology visualized [13] ………………………………………13
Figure 3. Gaia methodology models [14]..............................................................................14
Figure 4. Representation of a digital twin [1]..................................................................... 18
Figure 5. Typical components of an autonomous agent [12]..............................................20
Figure 6. General digital twin system diagram [2]............................................................22
Figure 7 . Healthcare applications for DT [18]...................................................................25
Figure 8. Frailty dependent and independent variables with their area-of-curve index
[8].............................................................................................................................................26
Figure 9. Percentage of devices used in studies for fall
prevention presented in [7]...................................................................................................27
Figure 10. Levels of Digital twins [10]................................................................................28
Figure 11. General patient application for healthcare [21]...............................................30
Figure 12. Use case diagram.................................................................................................33
Figure 13. Activity diagram for the application’s main scenario………………………..34
Figure 14. Pipe and filter pattern for Data flow architecture……………………………35
Figure 15. System flow chart for data flow pattern………………………………………36
Figure 16. Package diagram…………………………………………………………….….37
Figure 17. Deployment diagram……………………………………………………………38
Figure 18. Sequence diagram………………………………………………………………39
Figure 19. Definition formula of the norm for an n-dimensional plane...........................41
Figure 20. Definition formula of computing the jerk…………………………………….41
Figure 21. Getting database code for mongodb data……………………………………..42
Figure 22. Raw data from CSV files in version 1…………………………………………42
Figure 23. Getting HRM data from Mongodb version 1…………………………………43
Figure 24. Code for front-end version 1…………………………………………………...44
Figure 25. creating empty figure code using Plotly……………………………………….44
Figure 26. Code for getting raw vectors from .txt files - version 2………………………45
Figure 27. Example of using callbacks with Dash framework…………………………...46
Figure 28. Dropdown for selecting the users - version 1………………………………….47
7
2023
Figure 29. Dropdown for selecting the time frame - version 1…………………………...47
Figure 30. Graph for heart rate……………………………………………………………48
Figure 31. Graph for acceleration vector magnitude……………………………….…….48
Figure 32. Graph for jerk vector magnitude……………………………………………...48
Figure 33. Dashboard interface - first half……………………………………………….49
Figure 34. Dashboard interface - second half……………………………………………..50
8
2023
1. Introduction
1.1 Context of research

The following research paper offers an insight into digital twin and multi-agent system
technology that will later help in developing a smart health monitoring platform. The platform is
presented below after the analysis of several articles, each either introductory or already with a
solution in place.
The application’s aim is to diminish the waiting time between two crucial processes in at home
medical care: time from moment of health decline and given medical care or medical
appointment; time spent handling paperwork between different institutions like insurance
company, work place and the medical facility offering health services.
By default the main user for this application will be a frail elderly person, since they are most
predisposed to numerous afflictions , but it can also represent a chronically ill person. Most such
patients are left at home and given preventive advice and medicine. Without a proper monitoring,
well-being decline could go without notice and problems may be detected only when it is too
late, when it is much more difficult to treat.
The digital twin is meant to offer a virtual , updated and reliable profile that a relative, nurse or
doctor may check at any time , alerts are offered and thus avoiding neglect. All the personal data
being collected and computed are owned by the user and medical physicians. For simplicity, all
parties are simulated alongside the devices connected to the system, thus introducing the
important contribution of software agents.
To what extent is the digital mirroring possible for a live individual, that is being researched in
articles presented in the state of art chapter. It may prove impossible to reflect every gesture and
movement accurately, let alone prevent or predict actions, mainly because a human being is too
complicated for a computer to digitalize entirely, so in this research and application, more
emphasis will be given on the movement and type of movements. The end goal will be to detect
abnormalities or patterns of acceleration and its frequency with respect to time.
Each person has a different style of conduct, therefore AI generated predictions with large
samples of recorded movements from numerous individuals will be overkill for the scope of this
9
2023
research.The interest remains to each individual user, with its own recorded measurements and
its progress , or decline with respect to time. The digital twins used for this research will be
simple, light-weight and with minimum intrusive data collection.
1.2. Research Objective

The objective of this research is to obtain a deeper understanding of a digital twin’s structure,
functions and possible usages in the scope of healthcare and wellbeing tracking. Moreover, a
better view on the IoT applications in e-health is acquired and used for better determining a
person’s physical decline. This research paper comprises a series of other articles that have dived
in the same area of research or at least provided an introductory analysis in digital twins and
biomedical engineering.
The focus is also to determine to what extent a digital twin can reflect a living patient, what
methods were used and what technologies have been applied. Out of which, we determine which
of these options are the most effective and less intrusive for elderly users.
This paper also provides a starting point for future applications concerning use of sensors to
simulate or reflect a physical object and obtain a clearer view on what metrics are required to
detect and manage an elderly person’s frailty.
1.3 DT and MAS

In order to also consider one of the simpler options of designing and simulating real life entities,
we can first consider the Computer Aided Design/Engineering which was first created just for
this purpose. However this tool does not include, history, behavior and predicament, just the
structural part is mainly constructed and it is mostly used in architecture or manufacturing to be
used before the actual modeling.
A digital twin is different from CAE and far more complex with the following features:
- It is an instance meant to reflect not only the physical object’s structure but also
performance, health and history.
- Based on history, it can determine how the real life object is expected to
behave/act/degrade in different scenarios.
- It has a fuller understanding of the system’s environment, whereas the result of the CAE
is a stand-alone digital mockup.
10
2023
- It may schedule or alert the need of maintenance based on current or past experiences.
- It may derive assumptions which become more refined with the increase of data
regarding the environment and the synced twin.
- It combines different data sets coming from both IoT devices and internal data to take
better actions.
- It can reflect the age of the physical object by keeping track of all the operations and
maintenance done on and by the physical twin.
In short, a digital twin may act, decide and predict certain aspects which cannot be concluded by
mere structural design. There is a cognitive and complex anatomy which is meant to reflect the
physical object on a meta-physical level, all for having a better grasp on reality by simulating
multiple scenarios in a virtual world.
Figure 1. Digital twin concept within MBSE (Model Based Systems Engineering)
Framework.[10]
The above figure represents the use of a digital twin in a model based system. This is highly
similar to a software agent acting as its counterpart in a model based environment.The use of
both , with such similarities may prove useful if in an event of having a component highly
11
2023
coupled with a real life object, interacting with completely simulated events and agents meant to
facilitate actions in real life.
A multi-agent system works in a virtual environment that is separate from a physical one. Once
the initial analysis of the real life system is complete, the virtual entities then have everything it
takes to become autonomous, decentralized and aware of only a local scenario. A global view
requires too many variables and shifts in environment to be feasible.
In a multi agent system, we may encounter one of the main methodologies known that help build
the multi-agent system architecture and can serve as models for future hybrid model-based
applications: Gaia[13] and Prometheus [14].
Prometheus is a methodology applied for agent oriented software engineering which use agents
that are intelligent. This implies that the agents , besides their autonomy, have also planning
skills, belief system,updated goals and also take advantage of events. The building process is
simple enough for undergraduates and users with no experience in MAS and makes it a perfect
introduction.
The Promethean approach encapsulates the following phases: system specification, architectural
design and the final one, detailed design. The beginner friendliness is due to the software
engineering likeness and approach for the MAS application. It helps the developer view the
overall architecture from a general level to tiny essential details in a model oriented perspective.
The first phase, the system specification, is considering all values that are serving as input and
output to the users and the devices plugged in the multi agent system. Once these are known then
the full list of functionalities is established.
System specification, a phase that is responsible for keeping track of all input and output
parameters and assigned devices in the system, as well as enlisting and discovering all
functionalities of the multi-agent system. The view of them is general at first, but after taking
into account how each percept and event influence each other, a slightly detailed perception map
is created, as well as a list of appropriate actions.
12
2023
The output of the final phase is a clear view on the data influencing the multi agent system as
well as the system goals and how it is meant to assimilate, react and update to these outside
triggers. Therefore, we obtain the final system specifications needed for the next phase, the
architectural design.
This next phase represents a crucial part in the building of the multi agent system. It is concerned
with the needed components and their structure, in order to achieve the system’s needs and
requirements. After obtaining the functionalities from the first phase, each one needs to be
assigned an agent or reactive component. The key is to delegate each responsibility in a uniform
manner.
In order to obtain that uniformity, the types of agents need to be correctly chosen and assigned.
For that, the functionalities need to be grouped by their area of interest, so that the required roles
are more pronounced. The needed relationships between components stand out and so do the
individual responsibilities. Each found role will influence another and so the dynamics of the
system is also made visible.
To better illustrate the output of the second phase, an agent acquaintance diagram is created. In it
we may better visualize the social aspects of software agents, in which they need to exchange
data, negotiate and sometimes even make up contracts for their mutual goals to be respected.
This autonomous productivity is the main key aspect in MAS which make their approach
intelligent and with little to no external management.
To put together everything discovered in the first two steps, a system overview diagram, with all
the agents, I/O components and events is created. To make sure every interaction is proper and
respecting of system’s rules, interaction protocols are also established and made known in a
communication diagram. Thus we know which interactions are valid and which are not
permitted.
The final phase is the detailed design. In this phase, each component has its details and attributes
revealed and analyzed in order to have their internal structure and local goal clearly set. The right
implementation method is then chosen while considering the belief - desire - intention mindset
present in most MAS applications. The right method is the one which better covers the user’s
defined requirements and needs of the system, while also covering the agents’ responsibilities.
13
2023
To better design each agent’s structure, the final phase focuses most on capabilities. These
depend usually on the triggers launched and data received by the agent and what it needs to
deliver in return or to compute. The layers established must each respect the needed protocols
such that communication is done in the most efficient and clean way as possible.
For a clear visualization, the agent overview diagram is needed for then offering the important
aspects regarding internal architecture of the system’s key components. It mostly highlights
capabilities, unlike the system overview which highlights the agents themselves.
Figure 2 .Prometheus methodology visualized [13]
The above approach represents one of the methodologies used to have a thorough analysis on
how a multi agent system is modeled and created. It is perfect for those still in training but also
appropriate for applications which are more oriented on functionality serving multiple goals,
local or system wise.
14
2023
Another MAS methodology which can prove useful even for hybrid applications is Gaia
methodology. Unlike Prometheus, it is centered around the roles of the agents rather than the
communication between them. The most abstract entity is the overall system which represents
the agents’ society. Each role in that society is defined by four important elements: agents’
activities, permissions, protocols and responsibilities. With the last component comes in
discussion the functionality of the agents , which is a key factor for any agent.
Figure 3. Gaia methodology models [14]
Gaia focuses on two models which compliment one another in any application: the role model
and interaction model. Establishing what each component contributes to the application and how
each interacts is the goal of this methodology.
The steps for applying Gaia [7] are the following:

- create an agent model: discover the types of agents present in the system and aggregate
them in a hierarchy.
- create a service model: discover functionalities and the way agents communicate. For
that, protocols are needed to provide validity to every interaction.
15
2023
- from the above models , develop an acquaintance model.
The models are determined by establishing different ways of reaching the “organizational
goal”.There are multiple similarities to Prometheus, however the approach is from detail to
general which is opposite than the first methodology introduced.
1.4. Structure of thesis

The structure of this paper consists in four main parts, two of which are introductory
to the digital twin and e-health and physical wellbeing management research. They are the
following:
● Introduction: Here the context of the paper is presented alongside the objective of the
application. General information about digital twins and other applications which include them.
A main focus is put on healthcare applications to determine the best methods and parameters to
better visualize frailty indicators.
● State of the art: Background information about DT, methodologies and other
applications that use sensors to mirror movements, predict health conditions and manage overall
mobility. Short reviews on
each selected existing applications and a conclusion on what technologies were used
the most and which proved to be most effective. This part also serves as introductory
for the technologies chosen for this project’s paper.
● Architecture and design: This section reveals the Unified Modelling Language
(UML) diagrams used for underlining the chosen design patterns for the software as well as
overall architecture.
● Implementation and results: Code snippets, logical flow of the code and simulation
output are all shown in this chapter.
16
2023
2 State of art
2.1 Definitions
A digital twin, as its name suggests, is a virtual representation of a real life entity embodying
both its behavior as well as features. Its state is constantly updated by real-time data thus
mimicking the real life object’s lifecycle. It is therefore a more complete and complex
implementation of the standard OOP object, through real life data adaption and smart decision
making supported by machine learning, simulation and reasoning.
Such characteristics are not far from the features of a software agent,although with certain
differences. An agent is a software representation as well, but acts for a real life object, user or
computer program. If the digital twin behaves in a simulated environment alongside its physical
twin in the real world, the agent is completely decoupled from any other environment than its
own. Therefore a software agent is mainly an autonomous entity acting on behalf of another
entity.
The main features of an agent are: autonomy, persistence, social behavior and reactivity.
Persistence of having the code run not on demand but continuously is needed for a digital twin to
maintain its state almost similar to the real life object’s, however this contradicts the autonomy,
making the component too closely connected to its real life twin. Social behavior is not as
common in digital twin applications as in multi agent systems, but can be achieved if needed,
between multiple digital agents representing different entities which perform actions based on
their individual states.
Another key difference is the goal driven behavior. An agent may adapt independently and even
negotiate contracts in order to achieve its set goal which could be entirely unrelated to its current
state (such as a team game, the agent helps win the game but the game is not won if an agent’s
state is a certain way). A digital twin has but one vital goal, to mirror almost perfectly its
counterpart,in both state and action. Simulated environments can be constructed to keep better
track of various evolutions or decisions of the digital twin in order to predict as accurately as it
can a reality of infinite possibilities with only a few most probable outcomes.
17
2023
One may wonder why not use a simple simulation instead of creating such an intricate program
to mimic something already existent. But depending on the context, generating the amount
needed of different input values to sustain successful simulations can prove both redundant and
tedious.
The key difference between a DT and a simulation is that with a DT, one may create as many
simulations as needed , diverse and as complex, without having to manually plug in all the
measured parameters. The values are continuously collected and the simulation is running
depending on the already set profile of the twin. A simulation is just one singular process
achieved virtually by just one set of input values.
A multi agent system is a group of software agents, working together in an environment in order
to achieve a goal or satisfy some predefined requirements [11]. The environment can be
simulated or real (robots playing a game, smart house with real life IoT actuators), but unlike the
DT application, this system is entirely autonomous and doesn’t necessarily mirror the physical
objects of the real world.
Drawing a parallel between the two software entities, one meant for achieving processes
autonomously, the other used as a tool to study different processes of an object in various
simulated conditions, it is clear they are mostly intended for simulating real life objects and
actions. The research done further will show how these two may be used together to better
improve e-health applications and medical care.
2.2 Usage and anatomy of digital twins

The main goal of a digital twin is to be used in virtual simulations in order to keep better track of
its real life counterpart. It is also used to observe how the object would behave in different
scenarios while sensing various inputs. This is where decision-making proves critical for a
successful interpretation of the object’s lifecycle.
Both simulation and digital twins use a virtual environment to unfold possible outcomes,
however a simple simulation can only start by running a single input set of variables, whereas a
digital twin uses the outcomes as feedback for future processes as well as multiple entries of the
object’s state. Real time data is also a main feature introduced in DTs as opposed to regular
simulations where this is not generally common.
18
2023
Reasoning is a characteristic that is applied with the use of software agents. Used as an extension
in the AI field, a digital twin component can be extended to that of an agent in order to: settle on
the best course of action depending on environmental change, counterpart status shift or future
desired achievements. The iterative approach mentioned above is another smart characteristic
that allows the digital simulated objects to improve and
Having such a simple concept, it can be easily applicable in various domains, from IoT and
manufacturing to medicine and more human approached contexts. The more unstable and
unpredictable the object counterpart is , the more challenging it will be to have an accurate
mirror effect. Digital twin technology also has the potential to reduce the cost of system
verification and testing while providing early insights into system behavior.
While consulting the introductory survey [1] we observe the main features present in any DT
application. These features are:
a. unique: the digital twin refers to only one object
b. self-sufficient: the digital twin holds all information necessary to characterize and
predict the behavior of its real life counterpart.
c. full time lapse: the twin keeps track of all past, present state and possible futures of the
physical object.
Below we may see a simplified representation of a regular digital component twin.
Figure 4. Representation of a digital twin [1]
19
2023
To meet each of these requirements and form a complete lifecycle of the DT, the application
must complete certain phases. They are presented in [1] as: the product design phase, production
phase, operation phase and disposal.
Each phase has its own processes, many of them are real life processes that involve the real life
object and for simulating them in a virtual environment properly, specific tools and functions are
required. These tools are different, according to what context they are needed, some are related
to the interaction between other elements of the environment, others are coming from the internal
changes of the real life counterpart which the DT must notice and predict.
The first and most crucial phase in the making of any DT application is the design phase. In it,
the physical object is attentively studied in order to model a perfect replica of it digitally in any
state, environment or action. A two way communication is required for constant exchange of
data regarding the object and the real life environment it is in, so that the update can be almost
real time. With the past data collected, the DT can then have an accurate template of that specific
object and can be used for multiple logical instances of that same object.
Next phase is the production phase and is heavily involved with predicting different product
behavior in the simulated environment. It uses development, testing and simulation tools to
collect all possible variants of the product’s lifecycle and all changes that may occur.
Once the design phase is complete for both the digital and the physical twin, the next phase is the
production phase. This phase is meant to connect different components, also made into
prototypes as software representations, in order to test future stages of the real life twin. The
application during this phase is meant to either provide better predictions of the physical object
in real life or optimize the object. The latter usually is present in manufacturing contexts which
without the help of software simulations would require a lot of mockups.
Among the final stages are the operational and , if needed, disposal phases. Having all the data
collected and the designed system ready, the operations represented by simulated processes and
predicted actions from multiple software components are running. The different outcomes are
generally saved for the improvement of future predicament, or are closely followed and
monitored. Disposal is needed usually when the real life object is no longer monitored or
existent.
20
2023
Depending on what is needed to be made digital, whether a full object or group components, or
system processes on a macro level, there are different types of digital twins, all enumerated in
[20] and these are: component/part twin for a singular object study, asset twins for collaborating
components, system twin for collaboration between assets and process twins which show how
multiple digital presented systems influence each other. As it is to be expected, it is a matter of
scale. The area of application is a key indicator of how precise the digitalization must be.
As simple as a DT may prove to be theoretically, with agents, the different types are not
necessarily dependent on scale, but on the type of problem. The internal structure of the agent is
not only related to an existing object, but also on the architecture designed for the software
application. Internal architecture includes the input sensors, local capabilities , possible states
and actions, inference logic and goals.
Figure 5. Typical components of an autonomous agent [12]
This chapter shows the various applications and research centered around digital twins and the
common conclusions drawn which will prove useful in determining a generic architecture and
appropriate approach for a human-based simulation. Advantages and disadvantages will also be
shown and be used as insight for this document’s application and future ones.
Most of the articles chosen will be heavily based on the medical domain,since the documentation
will have as the main subject of research a human digital twin. This will raise many challenges,
from recording of the environment to subtle changes in the subject’s condition.
Based on how other applications in EHealth were successful and where they staggered, will we
know how we can perfect and improve our own digital twin application.
21
2023
First and foremost, it’s important to make a general analysis of a digital twin and a human digital
twin. The common characteristics and differences are also stated in [2] and are as follows:
- For a human digital twin it will be hundred times harder to always successfully achieve
perfect synchronization between digital and real based on : environmental factors, which
affect people more than they do for a physical , lifeless object; social factors, because
people are social beings, the way they interact can influence their actions, decisions ,
even well-beings.
- Another key aspect of the human digital twin is the genetic factor. There are certain
predispositions even diseases which are passed on genetically. A good family history may
improve the medical diagnosis and care process to a great extent.Without them, the
application may definitely have loopholes which may misclassify, ignore or even use for
initial faulty decisions.
- A common characteristic arises from the genetics scenario. The same way people of same
bloodline may suffer same medical problems, same can manufactured good have same
failures if they come from the same batch.
There are challenges in both sectors, but it is known to be worth investing nonetheless. If it is not
yet possible to have a full human digitalized, we may however simulate and have made virtual
certain life cycles of components which can significantly reduce precious time between
discovering of an existing condition and treating it. Or have processes made digital to reduce the
problem of having to wait and commute for paperwork. These are specifics which can be
achieved and improved by first researching the general aspects of both digital twins and software
agents.
2.3 Healthcare and frailty applications

When it comes to medicine, the prevention as well as early detection of certain maladies has
proven crucial since some illnesses are fatal when first symptoms are usually detected by doctors
or noticed by patients. An earlier prediction or monitoring can not only provide milder
treatments, but also save lives.
A proper imaging system can also help doctors, especially surgeons, make the right decision in
critical moments. With one organ clearly mapped or even a tumor, a surgeon can save up to
hours in an operating room, and make the interventions less invasive. Adding real time data
concerning aspects of the real life organ such as oxygen saturation level, blood flow etc. can also
improve the digital assistance drastically.
22
2023
Such applications are taken into account in [2], [3] and the results are making big differences in
the quality of medical care as well as quality of life of anyone benefiting from such technologies,
patients and also doctors, whose work becomes significantly less stressful.
From [2] we notice the differences clearly stated between a regular digital twin being used in
manufacturing and a human digital twin.
- difference between full lifecycle HDT and a partial HDT (concerned with only the
lifecycle of the patient - not the whole human life)
- the architecture and weak points (detecting social environment impacts or more specific
biological changes.)
Figure 6. General digital twin system diagram [2]
Further studies in [3] show the importance of

- DT for patient’s organs
- personalized treatments for personalized digital diagnosis
- images crucial for a physical architecture (of a body / organ / etc. for surgery
mostly)
- DT for management of resources in - a hospital , a hospital’s department, a
factory of vaccines, vaccine centers that provide them to patients etc.
23
2023
Changes made using resource/process digital twin show a significant change in how the
management improved in the health institute:
“
• If less time is spent 13 minutes for CT and 25 minutes for MRI(Magnetic Resonance Imaging),
patients' waiting times may be shortened.
• If less time is spent 28 minutes for CT and 34 minutes for MRI, patients will be able to return
faster…
• If 50 minutes more hours of work per day for MRI, personnel costs can be reduced and 9,500
Euros per year can be saved.
”
Similarly we can use a digital twin application to monitor elderly patients to better visualize their
physical decline and take preventive action in crucial time, such is the purpose of this research.
Frailty is best defined in [6] as a clinical syndrome as result of the decline in old age, manifesting
through increased general vulnerability. A medical syndrome is “a group of signs and symptoms
that occur together and characterize a particular abnormality”.
The symptoms can vary depending on a person’s genetic predispositions, medical history , past
traumas or quality of lifestyle.
Every physiological system is affected differently for different patients but they are indeed
regressing with old age , and each clinical indicator such as: heart rate, blood pressure,
saturation, mobility etc. is in need of surveillance if we desire an up to date status of the patient.
There are health indicators that can be tracked and that provide clues as to which physiological
components are starting to break down and need medical assistance before a more urgent
condition is developed. Such small alerts can prove vital to family doctors ,family members or
caretakers to know when their intervention is needed most, in order to prevent an emergency or a
silent evolution of an already existing condition.
Whenever we are dealing with a frailty condition there are four steps as described in [7]:
prevention, care, diagnosis and treatment. As observed, the highest priority holds the part of
preventive medicine, knowing that once a vulnerability is regressing into an illness it is often
times too late for the frail patients. To best support the preventive care, a DT system can be
24
2023
proven effective for a continuous monitoring of the frailty condition that affects all organs and
biological systems differently.
The goal with this monitoring that could be undesired by some reliable seniors, is not of course
avoiding the inevitable as some tend to ridicule, but the increase of both mental and physical
comfort that can prove scarce with the advancement in age. Time is proven precious at any age
and not only patients but also loved ones can agree.
Some technologies used for frailty have been researched and sampled in [7], but the one thing in
common and the ones proven most successful are always the ones which are as effective as they
are simple.The simple , easy operation and follow-up can make the user experience and use as
friendly as possible, at any age.
Some of these devices or sensors were listed in [7] and are:

- waist sensor for balance
- IoT system of different household items + neural network making prediction of
the level of frailty
- dynamometer
- video games with remote for grip strength measuring and movement tracking
- triaxial accelerometer in phone. ball for grip strength (again IoT), bathroom scales
for weight loss:
The data collected is then sent via smartphone to a remote service which can be accessed by the
environment, an authorized healthcare professional or set user. Another example of which data
collection from various IoT is needed to have a full view of patient’s well-being:
“Participants wore a pendant sensor (PAMSysTM, BioSensics, Newton, MA, USA)

at the sternum level for two consecutive days (48 h), as shown in Figure 1. The 48h
duration for data collection was determined based on the results of our previous stud-
ies [29,30]. The PAMSysTM includes a tri-axial accelerometer and gyroscope, and is small
(3.5 cm (W) × 3.5 cm (H) × 1.5 cm (D)) and light in weight (24 g) (BioSensics, Newton, MA,
USA). The manufacturer’s specifications indicate that the PAMSysTM uses advanced signal
processing algorithms and novel biomechanical models of human motion to continuously
25
2023
record posture, gait, and physical activity data at a rate of 50 Hz. The PAMSysTM can run
for 200 h without charging. It has built-in memory to save data.
“
- and easiest of them all: wireless sensor connection and movement of the upper
extremities - one movement to be compared over time and to track the slow physical
decline. An exercise taking less than a minute.
We see a lot of solutions, mostly hardware centered solutions that revolve around three major
steps: gathering data using sensors, storing them in a centralized datastore, make predictions and
estimations of frailty based on the values collected. But as [8] stated, the digital health sector is
in need of an inclusive platform or tool where to integrate all the devices available for the best
possible measurement.
Such a platform is later presented in the proposed application that involves a partial HDT and
multi-agent system for at-home monitoring of a chronically ill patient. It is one of the healthcare
use cases also presented in the below figure. The use of digital twins to better improve medical
care is presented in [18].
Figure 7 . Healthcare applications for DT [18]
26
2023
The comprehensive assessment needs to take into account the 5 criteria described by Fried.
Fried’s phenotype model of frailty - also from [7] where we have a nearly complete list of
technologies used for frailty between 2005 and 2015.
When measuring a person’s overall condition, many variables need to be considered and their
values computed throughout the day. A complete table with them is presented in figure 4 below.
Figure 8. Frailty dependent and independent variables with their area-of-curve index [8]
In such cases, the HDT is not needed to represent the full extent of a person’s lifespan but the
full evolution of it as a patient. The genetic background as well as full patient history is a key
point to be introduced in the design phase of the digital twin. Such information can come not
only from the patient itself, but their relatives as well as their personal physician.
In [4], grave cases of sepsis are avoided in the recovering patients using the human digital twin
technology. Real time data communication between the DT and the real patient is vital for
monitoring any possible sign of health decline, this will alert a doctor to intervene right before
the sepsis settles in. Such key moments are sometimes overlooked in regular hospitals due to
crowded ERs or poor patient follow-up post-op, but with a proper alerting system, the patient
will not have to wait and get help when it is too late.
27
2023
A possible implementation for tracking and predicting evolution in frailty : As specified in[8] the
data collected with the pendant were later used to feed a machine learning algorithm that would
offer as output a level of frailty, 0 for robust and 1 for frail. This achievement was done using
only one device, which shows the amount of connected devices do not need to be many, but
appropriate.
From [9], a value called “Hospital Frailty Risk Score” still has some areas in need of
improvement, such as better accuracy on the examination of the role of additional variables like
physiological parameters of disease severity.
There could be cases of a patient being able to do certain motions but fear and doubt can tamper
with their will to do them as such, and the system may read these values wrongly. Also the effect
of the score in clinical decision making should be further researched as to not have more
negative impact on the patient’s psyche.
Figure 9. Percentage of devices used in studies for fall

prevention presented in [7].
The application presented in this research will include in theory concepts from each of the
documented articles, however the demo presented in the Implementation section will provide a
perfect starting point for the final milestone presented below. A full considered solution for
frailty tracking through sensors such as gyroscope and accelerometer is discussed in the next
paragraphs.
28
2023
The considered application involves a portable medical platform of a partial human digital twin
( lifecycle as patient only) which has several simulated IoT devices which offer almost
continuous data regarding any health factors such as: blood pressure, oxygen saturation level,
heart rate, space orientation, acceleration and sudden tremors etc. The twin is meant to provide a
clear and reliable representation of the user as a virtual patient, which can be monitored at any
time by a medical professional.
Depending on the level of the digital twin,we can then determine the needed components
required for a functioning application. The design of the architecture will most like comprise of
different platforms communicating in order to keep the DT up to date with its physical entity and
much more.
Figure 10. Levels of Digital twins [10]
For our application,we want to maintain a realistic view, in which the patient may not have the
connected device on him or her self at all time, or there is a power outage or a temporarily lack
of internet, in which case the stream of data may never be continuous at all times. The batches of
data may have small or in some cases higher pauses between each other. After a longer pause the
application will momentarily focus on the current status rather than the whole history.
29
2023
In such case, a regular digital twin, tracking performance, health status, maintenance and batch
updates with no machine learning level is sufficient. Each batch will have a tag with the latest
date time when the last value was sent.
The application serves as a testing platform that can be later used to connect any health check
device, from a bracelet to a modified simple house item that the patient uses daily. The amount is
also not an issue in future implementations, the only requirement would be for them to be in
sync, to avoid such complication, a cloud platform can be used as receiver of all data and the key
to identify latest values is using date times at moment of collection.These dates are later used for
sorting, based on time and heath factor measured.
The platform can be useful to maintain the history of the human digital twin and of the patient.
Thus providing to all users the history, current health status and predispositions. However there
is sensitive data being collected and shared, so the appropriate roles and encryptions are
important to establish from the beginning, this remains a future development.
As for simulated resources package, it will contain all the .csv or .txt files needed to offer each
device a stream of data sent by the minute in batches for each established health factor that needs
measuring. The rest of the methods that send/receive this data from the common cloud platform
will also be held here.
The digital twin, after it receives the input data from the connected devices, it does two things. It
sorts the latest batch by synchronizing all the incoming values and computes the current health
status which later adds to the health history if relevant.
The predicament will be an added component if early recorded status before each anomy is
recorded and then analyzed. Some values do not drop or skyrocket out of the blue, a decline can
be noticed in the early stages of the app usage and in the future predicted. However the
prediction is dependent on a machine learning component, which will also remain a future
development and not included in this demo which has as main purpose a visualization of the
patient’s mobility.
In a full implementation, the agent or the middleware component is meant to track the progress
or regression and notify the physician. While verifying each current state, if a decline in health is
detected, then it will send a signal to the physician. For now in the demo, the physician is
30
2023
capable of sorting and filtering different acceleration,jolt information on each patient, select the
type of activity detected or labeled beforehand, and put a manual label on the patient’s frailty
status.
A similar approach is seen in [21] where we have a DT system with various areas of application
in healthcare. There are three layers as well, at the last and center of the system is the layer of the
patient’s continuously updated profile. The update is fed by ‘devices’ such as: a sensor
augmented shoe, a smart watch, a survey app which computes a health score and lastly a camera.
The patient’s personal factors measured are then: position, activity level, well-being factor and,
for the more invasive method, its posture determined through images. All contribute to provide
the physical health and monitoring for either personal reasons or , most likely, a physician’s or
close relative’s concern. Such measures are often taken for illnesses which can not be fully cured
in a hospital, but are nevertheless in need of constant supervision and care. Hospitals are
generally meant for treating emergencies, but for cases as unpredictable and monotonous as
these, the waiting time and reaction time prove critical in saving the patient’s life.
Figure 11. General patient application for healthcare [21]
31
2023
3 Requirement analysis
3.1 Functional requirements

The functionalities in the proposed application revolve around efficient and simple data
visualization in order to draw reliable conclusions. There are two aspects to consider: having the
sensor data synchronized in the same time frame and having proper filters to separate each
patient, each activity and each type of results wanted for display on the dashboard. The goal
remains the one presented in the Research Objective chapter, having a singular , easy to use
application for sensor data that helps a physician draw a conclusion regarding a person’s
mobility level or frailty stage.
In order to achieve this goal, the solution needs the right filters like what activity to track, for
which patient and what results to be displayed on the dashboard. The right results computed
from the raw sensor data consist in values such as acceleration vector magnitude, the
acceleration mean , average acceleration and frequency of it.
Another important component is composed of medical thresholds that the physician can add as
input or keep in mind, like the target heart rate with respect to the patient’s age. In a complete
version of the application, where historical values are stored, these resulted values are compared
and the patient’s progress or decline is then visible, the rate of it easier to visualize and manage.
Overall , the resulted functional requirements are described as such:
● Apply mathematical formulas to obtain relevant results from raw sensor data.
● Filter sensor input from each patient for the desired activity to track.
● Design and populate graphs to display these results in the selected time frame.
● Have an input where the physician can put the frailty diagnosis and further
observations concerning the patient’s physical condition.
These functionalities are combined together from two different versions of the applications
which will be further detailed and explained in the Implementation chapter.
3.2 Non-functional requirements

When considering an online dashboard application, three characteristics are evident:
simplicity from its compact design, efficiency from the well comprised data visualized on it and
32
2023
easy accessibility due to its place of deployment, the world wide web. Therefore, the presented
frailty monitoring dashboard has the following qualities:
● Flexibility, sensors or graphs can be easily added without affecting the overall backend
logic.
● Distributed, the sensors feeding the data source used in the dashboard send their data
independently and without waiting on other feedback , devices or applications which
makes managing them easier and uncentralized.
● Scalability, relevant to the first requirement, the project can be scaled at ease with more
graphs or dashboards, and for a full version implementation, Dash offers an enterprise
version which allows for distributed and efficient deployment.
● Availability, the application can be easily accessed on any browser type or version.
● Reliability, the application is as reliable as its data source. It is working with the raw data
given to it and if that is validated, the results computed and displayed on it are relevant
enough to draw conclusions from it.
● Performance, the system should constantly and instantly update in real time the computed
means and values in the graphs, making it easy for a real-time monitoring .
● Usability, the application provides a light and intuitive interface for the user to access and
operate.
● Resilience, if one sensor stops transmitting , no half-measured or incomplete graphs are
displayed and the application does not crash.
● Portability, the application runs on any operating system or browser as long as the needed
packages are downloaded, python and the needed libraries.
3.3 Use cases

Use cases represent the main functionalities a user has available in the application demo, they are
discussed also in the functional requirements section. The only stakeholder meant for this
dashboard is a medical physician appointed to the patient or elderly user who wears a device
containing an accelerometer and gyroscope. For simplicity and considering the other similar
applications for healthcare reviewed in the State of the Art part, only the accelerometer values
are taken into account and have proven enough.
The below diagram shows the key actions triggered on the dashboard:
33
2023
Figure 12. Use case diagram
3.4 Activity Diagram

In the following activity diagram we can visualize a successful scenario run by the dashboard.
Important steps from obtaining and filtering the data source to updating the graphs in the
front-end are presented chronologically and synchronously .
There are three main components:

● The dashboard user which represents the physician, who chooses the graphs they want to
inspect, the activity they wish to track and for which specific patient
● The dash component integrated in the Dash module in python, its logic is within the
Dash framework and cannot be accessed inside the project, only used.
● Backend script representing the main script containing all methods to filter, order and
display the data.It represents the central logic and middleware between the Dash
front-end parts and the data source .txt files.
34
2023
Figure 13. Activity diagram for the application’s main scenario
For the set frailty label the process is a much simpler one, it involves updating a text area that
contains further observations.
35
2023
4 Design
4.1 General architecture

In this section of the paper, we will adopt an analysis approach that moves from an overview of
the system to a more in depth perspective such as modules, files and libraries. The most general
review is captured best in the package and deployment diagrams. Each package represents a
category of concern of the software components stored inside. This separation is key in
maintaining low coupling and a high level of cohesion, which supports the necessary
non-functional requirements for a successful and reliable application.
Since the overall functionalities and requirements are centered around a data source and
independent filtering methods, the architecture that best describes such a behavior is the data
flow pattern architecture. In this architecture , the system is viewed as a series of transformations
using consecutive method calls which run independently from each other with one or multiple
data sources.
There are methods in the designed solution which are not dependent on the other method’s
output, making this solution perfect for the pipe and filter pattern.The inputs and outputs of the
different methods are called pipes and each filter represents a transformation method. As shown
in the diagram below, these filters can be synchronous or asynchronous. They can also be run in
parallel.
Figure 14. Pipe and filter pattern for Data flow architecture
An overall, detailed representation of the system can be seen in the flowchart below. There are
four main “flows” of data, one is obtaining a more structured data than the files alone with only
36
2023
the necessary vectors required for the graphs, the second involves sectioning of the transformed
data to have it available for filters like user, activity and other needed results like means,
maximum, minimum values etc. , the last two are related to the front-end and the dynamics of
the web interface.
Figure 15. System flow chart for data flow pattern
4.2 Package diagram

The existent packages in the application are clearly defining the different phases the data
experiences. The detachment is key for separating raw input from the interface settings which
have nothing in common with the logic concerning the mobility parameter visualization.
37
2023
Figure 16. Package diagram
The package assets is a predefined package used by Dash module to extract the .css files for
configuring the main dashboard page. The files are empty by default but the module considers
the files within only at a certain address, hence why there needs to be packaged nested within the
main package, data_processing which holds the main running script which searches for them at
runtime.
Data_collection package holds all the different data sources needed for the interface. In this case,
the inner package users has all the .csvs used in the version 1 of the applications. In version 2 it
is a folder holding .txt files with space separated values representing the acceleration vectors and
extra recorded values per user, each row with a specific activity labeled, label which is missing
in the first version.
38
2023
4.3 Deployment diagram
Figure 17. Deployment diagram
The system envisioned for the overall application is a standard all-in-one architecture , since the
dashboard is meant to connect to any type of data source, it can be deployed and run on a
separate server as a single unit. In time if there is need for scaling, it can happen horizontally,
with one deployable unit per server or virtual machine.
In the next chapter where Implementation is discussed, the application is presented as a mere
demo so the deployment procedure is not entirely tackled, but left as future work.
39
2023
4.4 Sequence diagram
Figure 18. Sequence diagram
Since the architecture is event-based, in the above sequence diagrams we can observe what
triggers the events and what leads to the creation of the dashboard and the data manipulation
behind it.
The dashboard interface is a responsive, user-friendly web interface which updates with each
modification of the code, without reloading the page, thus sending an update_figure message
with each modification of the input coming from the physician. Once the user selects all the
necessary filters, the data is the collected, filtered and displayed on the graphs.
40
2023
5 Implementation
5.1 Technologies used

● Python, version 3.9, this programming language used for the implementation is a
high-level, dynamic, general-purpose language, perfect for either object-oriented
programming , purely mathematical scripting or like this demo, an event-based,
integrated web application. The PEP8 standard has also been used to support code
readability and best practices for writing in python.
● Plotly, is an open-source python library for creating interactive,diverse and quality graphs
and charts.
● Dash, a framework for rapidly creating data applications in python. Plotly is as well
available in it and with Dash, the front-end components blend together with the graph
models and its callbacks. This library made it easy to create a full web applications using
only one python script.
● Pycharm Community, a python IDE that helped construct and test the final demo
application.
In version 1 there were also used:
● Pymongo, a python library for executing CRUD operations in mongodb. In our
application versions, only the reading operations were performed and needed.
● Mongodb, An unstructured database perfect for key-value pair data. It is light-weight,
low-maintenance and is popular among light applications which do not require
5.2 Logical Flow - Back-end
5.2.1 Version 1
The extra data calculated and extracted from the collected data are the : average values in the
measurement window, peak values.If values are provided as vectors for XYZ axes then the
Euclidean norm is used to determine the mean:
Figure 19. Definition formula of the norm for an n-dimensional plane
Along with the mean acceleration velocity, the mean jerk vector magnitude is also computed,
using the acceleration vectors and the timestamps of one second:
41
2023
Figure 20. Definition formula of computing the jerk
Where:
● a is acceleration
● v is velocity
● r is position
● t is time
The jerk or jolt is the rate of change in an object’s acceleration, it is useful for determining
sudden movements or high and sudden acceleration increases. Knowing acceleration vector, the
following formula was used in the code: a2−a1t/2−t1.
● The connection to mongodb for user data is made with the use of MongoClient object,
imported from pymongo.
Figure 21. Getting database code for mongodb data
This data source was used in the beginning of the research when the data was not quite complete,
later on, most of them were comprised in CSV files, organized already per patient.
42
2023
Figure 22. Raw data from CSV files in version 1

● Get heart rate raw sensor data from Mongodb
Figure 23. Getting HRM data from Mongodb version 1
In the above method, 40 is used a minimum threshold for an elderly person’s heart rate, any
value below this threshold is considered an invalid reading. The threshold was taken from [23].
43
2023
Figure 24. Code for front-end version 1
● An example of python code combined with Dash integrated front-end components.
Figure 25. creating empty figure code using Plotly
44
2023
The figure represents each graph in the dashboard, it is created empty at the start of program and
it receives the data and layout after filter inputs from the dropdown are selected , at callback.
Version 3 was tested with two users.
5.2.2 Version 2
In version 2, a different data set has been used, one for training a neural network to detect and
activity type using an accelerometer and gyroscope sensors. Although the users measured were
between ages 18 and 50 and were not elderly, the acceleration and jerk vectors were precisely the
ones needed for the full application to detect frailty in the future,or label it by a doctor.
● Getting the lists later used for graphs
Figure 26. Code for getting raw vectors from .txt files - version 2
There is not much difference from first version in terms of implementation, except the data
source, callback method update_figure() and the front-end design.
45
2023
Figure 28. Example of using callbacks with Dash framework
● Using the identifiers of the dropdowns and graphs, the callback method
update_figure() takes the inputs from the user and uses them to generate and
return the figures of the dashboard.
46
2023
6 Results
In this chapter we view the different interfaces used for the dashboard. The main differences
between the two versions consist in: data sources, where the second version has labeled vectors
of acceleration that indicate the type of activity: walking, walking upstairs, sitting and so on,
frailty label input and of course the front-end design.
6.1 Version 1
Figure 28. Dropdown for selecting the users - version 1

In the above figure, we see the version 1 being tested with already labeled data concerning the
patient’s frailty status.
Figure 29. Dropdown for selecting the time frame - version 1

The time frames can also be selected, however most data can be visualized in the 10 minute time
frame . The data collection process proved to be a challenge since there are interruptions caused
by: unsynced sensors, human errors, connection issues.
47
2023
Figure 30. Graph for heart rate

In figure 30 we can observe the heart rate each second of the measuring process. The relevant
information will be in the maximum and minimum values.
Figure 31. Graph for acceleration vector magnitude

In figure 32 we see a high activity moment detected and a sudden drop in acceleration, since it is
version 1, details regarding the type of activity are unknown.
48
2023
Figure 32. Graph for jerk vector magnitude

When we observe the jerk magnitude graph we can observe sudden movements and their
frequency since they indicate tremors or balance problems.
6.2 Version 2 - final dashboard
Figure 33. Dashboard interface - first half
49
2023
Figure 34. Dashboard interface - second half
50
2023
6.3 Conclusions and future work

In the current state of the demo, the frailty management is tackled but not the prevention or
labeling. As a future improvement, after much data collection and cleaning, enough will be
gathered to be fed to a neural network to have the application set the frailty label on its own and
have the physician only as a validator.
The prevention as mentioned in the research title, is still mostly a human effort, for the user or
doctor to see the patient’s progress or decline and set a conclusion, the challenge still lies in the
lack of data collection from each individual as well as validating the raw data the sensors
transmit. The sensors may start to transmit even before the activity has even started or the patient
might forget to take it off in time and it will send data even after the activity is over, offering
inconclusive vector values. Until such a complete data set is available, the making of this part of
the digital twin application will remain a challenge, hence why the current versions are so
simplistic. It is however a good starting point for future research in frailty management and
detection.
51
2023
7 References
[1] R. Minerva, G. M. Lee and N. Crespi, "Digital Twin in the IoT Context: A Survey on
Technical Features, Scenarios, and Architectural Models," in Proceedings of the IEEE, vol. 108,
no. 10, pp. 1785-1824, Oct. 2020, doi: 10.1109/JPROC.2020.2998530.
[2 ] Wei, Shengli. (2021). Is Human Digital Twin Possible?. Computer Methods and Programs in
Biomedicine Update. 1. 100014. 10.1016/j.cmpbup.2021.100014.
[3] Erol, Tolga & Mendi, Arif & Dogan, Dilara. (2020). The Digital Twin Revolution in
Healthcare. 1-7. 10.1109/ISMSIT50672.2020.9255249.
[4 ] Lal, Amos & Li, Guangxi & Cubro, Edin & Chalmers, Sarah & Li, Heyi & Herasevich,
Vitaly & Dong, Yue & Pickering, Brian & Oguz, Kilickaya & Gajic, Ognjen. (2021).
Development and Verification of a Digital Twin Patient Model to Predict Treatment Response in
Sepsis. Critical Care Medicine. 49. 611-611. 10.1097/01.ccm.0000730744.82258.38.
[5] Nyholm, Sven. “Should a Medical Digital Twin Be Viewed as an Extension of the Patient's
Body?” Journal of Medical Ethics, 2021. doi:10.1136/medethics-2021-107448.
[6] The Frailty Syndrome: Definition and Natural History

Qian-Li Xue, PhD
Department of Medicine, Johns Hopkins University School of Medicine, 2024 East Monument
Street, Suite 2-700, Baltimore, MD 21205-1179, USA.
[7] Iranzu Mugueta-Aguinaga , Begonya Garcia-Zapirain. Is Technology Present in Frailty?

Technology a Back-up Tool for Dealing with Frailty in the Elderly: A Systematic Review. Aging
and disease. 2017, 8(2): 2005-2015 https://doi.org/10.14336/AD.2016.0901
[8] Citation: Park, C.; Mishra, R.; Golledge, J.; Najafi, B. Digital Biomarkers of Physical Frailty
and Frailty Phenotypes UsingSensor-Based Physical Activity and Machine Learning. Sensors
2021, 21,5289. https://doi.org/10.3390/s21165289
[9] Thomas Gilbert*, Jenny Neuburger*, Joshua Kraindler*, Eilis Keeble, Paul Smith, Cono
Ariti, Sandeepa Arora, Andrew Street, Stuart Parker,
Helen C Roberts, Martin Bardsley, Simon Conroy, “Development and validation of a Hospital
Frailty Risk Score focusing on older people in acute care settings using electronic hospital
records: an observational study” ,Lancet 2018; 391: 1775–82, April 26, 2018
http://dx.doi.org/10.1016/S0140-6736(18)30668-8
52
2023
[10] Madni, Azad M., Carla C. Madni, and Scott D. Lucero. 2019. "Leveraging Digital Twin
Technology in Model-Based Systems Engineering" Systems 7, no. 1: 7.
https://doi.org/10.3390/systems7010007
[11] Wooldridge, Michael,”An Introduction to Multi agent Systems”,Wiley, 2002
[12]Balaji & Srinivasan, D. (2010). “An Introduction to Multi-Agent Systems”, Chapter · July
2010, from Book “Innovations in Multi-Agent Systems and Applications”
[13] Padgham, Lin & Winikoff, Michael. (2002). “Prometheus: A Methodology for Developing
Intelligent Agents”.
[14] M. Wooldridge, N. Jennings, and D. Kinney. The Gaia methodology for agent-oriented
analysis and design. Autonomous Agents and Multi-Agent Systems, 3(3), 2000.
[15].Kshitij Bakliwal, Maharshi Harshadbhai Dhada, Adrià Salvador Palau, Ajith Kumar
Parlikad, Bhupesh Kumar Lad,
“A Multi Agent System architecture to implement Collaborative Learning for social industrial
assets”Volume 51, Issue 11,2018.
[16] Ruairi O’Driscoll , Jake Turicchi , Mark Hopkins , Graham. W. Horgan , Graham
Finlayson & James. R. Stubbs (2020) Improving energy expenditure estimates from wearable
devices: A machine learning approach, Journal of Sports Sciences, 38:13, 1496-1505, DOI:
10.1080/02640414.2020.1746088
[17 ] Barricelli, Barbara Rita, Elena Casiraghi, Jessica Gliozzo, Alessandro Petrini, and Stefano
Valtolina. “Human Digital Twin for Fitness Management.” IEEE Access 8 (n.d.): 26637–64.
doi:10.1109/ACCESS.2020.2971576.
[18 ] Fardousi, Rahatara & Laamarti, Fedwa & Hossain, M. & Yang, Chunsheng & El Saddik,
Abdulmotaleb. (2021). Digital twins for well-being: an overview. Digital Twin. 1. 7.
10.12688/digitaltwin.17475.1.
[19] Emerging Computer Technologies, Journal. “Digital Twin Based Disaster Management
System Proposal: DT-DMS.” Journal of Emerging Computer Technologies 1.2 (2021): 25–30.
[20] What is a digital twin? IBM. Available at:

https://www.ibm.com/topics/what-is-a-digital-twin (Accessed: 05 February 2022).
[21] Spinsante, S. et al. (2021) ‘Clinically-validated technologies for Assisted Living’, Journal
of Ambient Intelligence and Humanized Computing, 14(3), pp. 2095–2116.
doi:10.1007/s12652-021-03419-y.
[22] ‘A quantitative research for determining the user requirements for developing a system to
assist people with frailty’, T2 - 2021 23rd International Conference on Control Systems and
53
2023
Computer Science (CSCS) B. -I. Ciubotaru AU - V. -G. Sasu AU - A. Vasilateanu AU - N. Goga

AU - R. Dragomir AU - A. -F. Popovici PY - 2021 DO - 10.1109/CSCS52396.2021.00014 JO -
2021 23rd International Conference on Control Systems and Computer Science (CSCS) IS - SN -
2379-0482 VO - VL - JA - 2021 23rd International Conference on Control Systems and
Computer Science (CSCS) Y1 - 26-28 May 2021 ER
[23] Target heart rates chart (2023) www.heart.org. Available at:

https://www.heart.org/en/healthy-living/fitness/fitness-basics/target-heart-rates (Accessed: 5
February 2022).
54
2023
8 Glossary
● AI - Artificial Intelligence
● IOT - Internet of Things
● CAE - Computer Aided Engineering
● MBSE - Model Based System Engineering
● MAS - Multi Agent System
● I/O - Input / Output
● DT - Digital twin
● UML - Unified Modeling Language
● OOP - Object Oriented Programming
● HDT - Healthcare digital twin
● CT - Computed tomography
● MRI - Magnetic Resonance Imaging
● CSV - Comma Separated Values
● TXT - Text file
● CRUD - Create, Read, Update, Delete
● IDE - Integrated Drive Electronics
55

Digital Titties

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Digital Titties

Uploaded by

Copyright:

Available Formats

Dissertation Thesis, Alexandra BOLOVAN, Faculty of Engineering in Foreign Languages, UPB,

UNIVERSITY “POLITEHNICA” OF BUCHAREST

UNIVERSITY “POLITEHNICA” OF BUCHAREST

COMPUTERS AND INFORMATION TECHNOLOGY

Digital twin for frailty prevention and

Project coordinator Student:

“POLITEHNICA” UNIVERSITY OF BUCHAREST

DISSERTATION PROJECT THEME FOR:

6. Project development environment:

7. The project serves as:

Project coordinator Student:

Academic Honesty Statement

Academy honesty statement...................................................................................................... 4

1.1. Context of research........................................................................................................ 8

1.2. Research objective......................................................................................................... 9

1.3. DT and MAS...................................................................................................................9

1.4. Structure of thesis........................................................................................................ 15

2. State of the Art.....................................................................................................................16

2.1 Definitions .....................................................................................................................16

2.2 Usage and anatomy of digital twins ............................................................................17

2.3 Healthcare and frailty applications............................................................................ 21

3.2 Functional requirements.............................................................................................. 30

3.2 Non-functional requirements....................................................................................... 31

3.3 Use cases.........................................................................................................................32

3.4 Activity diagram............................................................................................................33

4.2 General architecture .................................................................................................... 35

4.2 Package diagram...........................................................................................................37

4.3 Deployment diagram………………….……………………………………….……..38

4.4 Sequence diagrams........................................................................................................39

5.1 Technologies used..........................................................................................................40

5.2 Logical flow – backend................................................................................................. 41

5.2.1 Version 1…………………………..…………………………………….……..…….41

6.1 Version 1………………………………………………………………….……………47

6.2 Version 2 ………………………………………………………………………..……..49

6.3 Conclusion and future work....................................................................................... 51

1.1 Context of research

1.2. Research Objective

1.3 DT and MAS

Figure 2 .Prometheus methodology visualized [13]

Figure 3. Gaia methodology models [14]

The steps for applying Gaia [7] are the following:

- from the above models , develop an acquaintance model.

1.4. Structure of thesis

2.2 Usage and anatomy of digital twins

Figure 4. Representation of a digital twin [1]

Figure 5. Typical components of an autonomous agent [12]

2.3 Healthcare and frailty applications

Figure 6. General digital twin system diagram [2]

Further studies in [3] show the importance of

Some of these devices or sensors were listed in [7] and are:

“Participants wore a pendant sensor (PAMSysTM, BioSensics, Newton, MA, USA)

Figure 7 . Healthcare applications for DT [18]

Figure 9. Percentage of devices used in studies for fall

Figure 10. Levels of Digital twins [10]

Figure 11. General patient application for healthcare [21]

3.1 Functional requirements

3.2 Non-functional requirements

3.3 Use cases

Figure 12. Use case diagram

3.4 Activity Diagram

There are three main components:

Figure 13. Activity diagram for the application’s main scenario

4.1 General architecture