Team:Thessaly/Software
Overview
According to the 2019 opinion of the Expert Panel on Effective Ways of Investing in Health (EXPH),
digital technologies offer new opportunities for delivering more personalized, effective and efficient
healthcare. EU policies have consistently emphasized the importance of digital solutions such as eHealth
and have accentuated positive aspects of digital innovations. However, digital health services may
require additional and alternative evaluative frameworks, so the existing methods should be adapted
to accommodate the evaluation of the impact of digital health services. In order for digital health
to adapt to modern everyday life and integrate itself in contemporary medical practices, a solid
framework is needed, and for these purposes every platform like AMALTHEA needs to be supported by
a software tool. With this concept in mind, we started ideating a software tool, a mobile application,
which would link AMALTHEA’s complex measurement processes with the convenience a mobile device provides.
This was the beginning of e-AMALTHEA.
Technical Part
To design the implementation process we had in mind, we had to “break” it into subprocesses and
form a pipeline that consists of clear steps. We did so, by integrating experts’ knowledge on
every step of the pipeline, especially in platform-related, technical implementation-related,
and data privacy-related subjects. In this section, we will thoroughly examine our thought
process from ideation to coding, by exhibiting a version-based analysis of the development of
e-AMALTHEA.
To initiate the ideation process and determine the application’s functionality, we had to set
specific goals. The app’s main values should revolve around ease of use, user-friendliness,
simplicity and compatibility. We wanted an outcome that could be easily integrated into the
average person’s everyday life. Our main end goal was to organize the application and develop
it in a way that would operate on conventional mobile devices, and more specifically on
smartphones. We separated the functions we wanted it to have into primary and secondary, both
conceptually and implementation-wise. The primary functions build the software backbone,
whereas the secondary ones constitute a set of utensils that would attract a potential user;
these secondary functions involve expert’s feedback in the whole evaluation process, to ensure
a holistic approach.
v1.1: Architecture
Finding a motto, though, is only the first step. Every information system of a complex internal organization requires a formal method to represent its design, components and the relationships between them. This is why one of our first concerns was to clearly depict our application’s architecture, not only to display its function better, but also to compartmentalize our work. Modeling our application in this way helped us to focus on the important parts of its implementation and filter out any unnecessary details, code-wise, and also provided a formal documentation of its architecture in a language that is universal. Indicatively, we show the architectural model of the login and register functions:
The GUI is the main interface of any application that assists the user to interact with it and
explore its functions through the use of icons, and constructs of graphical nature in general,
with no special knowledge requirements. The second version of our app development process
involves the front-end development, which is the making of the Graphical User Interface -after
all, developing the front-end part first and the back-end afterwards is a usual tactic in such
occasions.
v2.1: Login and Register Pages
We began by designing the login and register pages, which pretty much follow the standard authentication- identification process used in an ordinary phone application. In the login page, the user has to enter their email address and their password, and then tap on “Login”. On the bottom, there is the choice of registering, in case they have not created a profile yet. Tapping on “Don’t have an account? Register Here” leads to the register page, where they have to enter their first and last name, their email address, and a password of their choice, twice for verification purposes. When all required fields are filled properly, tapping on “Continue” leads to the main menu, just like the “Login” button does.
These pages, though, are built for all kinds of potential users, who may be either on the giving or the receiving end of a holistic treatment, meaning that the user can be either an expert or a patient. In our design we make a clear distinction between these two “modes”. Thus, besides the standard registering options that a patient-user would have to make, we designed a separate page where a user can register as an expert.
By tapping on “Register as an expert”, the additional credentials that are required are the Taxpayer Identification Number (TIN), Social Security Number (SSN), and personal ID number, and soon after these fields are filled properly, an “expert” account is made. These particular credentials are the ones mainly required to identify a health professional digitally, and ensure the authenticity of their alleged expertise, as we learned in our Integrated Human Practices meeting with Dr Vlachos. Of course, in all fields, e-AMALTHEA automatically performs validation checks, meaning every time they are required, the software checks if they are empty, invalid, or correspond to another account.
v2.2: Main Menu
By logging in -or registering, accordingly- the user is granted access to the main menu of e-AMALTHEA, where they can navigate to all the utilities it has to offer. As the icons indicate, the user has the ability to: view their profile, display their capsule results, answer a set of daily questions about their mental health, communicate (asynchronously or synchronously) and with their nutritionist, view a map with experts in their area and translate the app.
v2.3: Profile
In “Profile”, the user can view the credentials they are logged in with, and they can also log out. The Profile page has many perspectives for back-end development in possible future versions, including functions like editing/changing the profile picture, a history of past measurements, or the number of experts that are logged in and online.
v2.4: Results
In “Results”, the user can display their capsule measurements plotted in a signal-versus-time diagram, and also “mess” with the time scale. That means they can view the measurements curve for any given time interval, regardless of its size. By zooming in or out, they can determine the size of the interval of interest.
Since e-AMALTHEA is designed to handle medical data, data privacy is the most important issue
we had to address. Such an application needs the support of a database infrastructure that is
fast, versatile and most importantly, safe, and this is the reason we decided to employ cloud
computing. According to C. Stergiou and K. E. Psannis, (2017), cloud computing is the latest
and one of the most famous information technologies nowadays. Many enterprises are making a
shift towards it, due to its advantages, namely high computational power, reduction in
infrastructure and maintenance costs coupled with on-demand storage capacity. Cloud computing
can be defined as a setup where storage and all data processing happen beyond the user’s
devices, and the data traverses through these databases.
The database system we used for the alpha version of our application was Cloud Firestore. There, the useful information is saved in the form of text files (with a “.txt” extension), as opposed to any regular SQL databases that form hierarchies and dependencies between entities in which they store data. As soon as the files are stored in the database, every one of them is assigned a primary key, which is a number unique for each file and serves as an identifier. Nevertheless, the original primary key of each file is not visible to any user of the database; instead, a secondary, token key is created for every entry. After it is subjected to encryption by algorithms Firestore provides, the token key can be seen from a user who has reading/writing rights on the entry that the token key corresponds to. Thus, our whole database is neither a pure cloud service nor a totally local server, but rather a hybrid combination of the two. As Dr Vlachos advised us, we did not place our hopes entirely on cloud computing for the sake of it being a cutting-edge technology, but combined it with more conventional ways to form a solution that cancels out the one method’s disadvantages with the advantages of the other, thus improving the safety of the whole system.
Consequently, we draw a stark distinction between the user’s private information (e.g. SSN) which is stored in the cloud and the information that concerns the authentication system (email, password) which is not.
Authentication System
We achieve user identification through Firebase’s standard Authentication System. As we mentioned before, the Authentication System creates a second, autonomous database that handles this identification data, so that the main base (which stores data of sensitive nature such as the SSN) stays safely uninvolved. As soon as a user enters their email and password, the application connects with the Authentication System’s secondary database and checks if the email entered exists in the latter, and if so, the user is successfully logged in. This “handshake” is finished with a primary key being assigned to the newly logged in user and encrypted to a token key with a back-end process, so that they are identifiable at any given time and their activity is fully trackable. It is really important to note that while the primary key is constant for a single user, the token key changes every time that user logs in, a mechanism that adds an extra layer of safety in the user identification process.
User’s Data
The cloud component of our database follows a .txt file tree logic, which means that the hierarchies between the files are arranged in a way that resembles, or better yet mimics the tree data structure. It features two “tree” file collections: “users”, which contains all the information relative to the user logged in, and “results” which keeps their measurements. When a user registers, a descendant file is created in the “user” tree which includes both private and authentication data. Similarly, when the results are transmitted, a descendant file is created in the “results” tree that represents that user, which in turn has descendant files -the “leaves” of the tree, actually- that store the results (as numbers), the user’s primary key and a unique capsule ID (used to identify the particular capsule) respectively. The correspondence between the user and their results is achieved with the token ID, which is extracted with encryption from the primary one stored (back-end) at “results”. This constructs an extra safety net for the user’s data, that not only makes our database more hard and complex to attack, but also makes a big step towards data anonymization, a type of information sanitization that is extremely important in medical data privacy, as we confirmed in our Integrated Human Practices meeting with Dr Vlachos.
The function’s implementation marks the most technical part in the development of e-AMALTHEA.
It includes the
programmatic creation of all the back-end operations that are performed and which grant the ability of a
“both-ways” interaction between the application and the user. As interaction, we define all the possible
ways in which a user is able to navigate themselves throughout the applications environment. We
developed our application using object-oriented logic. The back-end part is organizing its structure
using the concept of objects that can store code (procedures) and/or data (fields). What proved to be
particularly important here, is the concept of classes: a class represents a “template” of an object, a
general format of what its fields and procedures will be - and inversely, we can say that an object is
an instance of a class, “a special case”. By defining classes, we are able to create new classes, or
subclasses, that are based on the already existing ones, share exactly the same characteristics and also
contain some additional. Accordingly, we can create child objects based on already defined objects,
parent objects. This mechanism is called inheritance, and is the most useful tool the object-oriented
approach offers us:
In the development of e-AMALTHEA we make a clear distinction between a patient-user and an expert-user and, at the same time, between different kinds of expert-users to ensure good practice, data safety and, of course, a holistic approach. This is where inheritance actually helped us, because it gave us the ability to create a hierarchy of structures and choose the level of abstraction we want to work in. For example, if we have conceptually separated a patient-user from an expert-user and we want to depict that to our code, all we have to do is define a user class, and two subclasses for patients and experts with separate fields and procedures that give them different attributes and rights in the app accordingly. But this is fully extensible: if we also want to separate the attributes and rights in our environment based on the specialty of an expert, we can derive subclasses from the class “expert”, “ gastroenterologist” and “dietician”, for instance. On the other hand, if we hypothetically wanted to create an object that is a user, or refer to the user property in general, we could just ignore all the subclasses that exist and create an object which is of class “user”.
Here you can see all the classes that we have created during our app making process. Ideally, there would be more, but, as we remarked above, our code is fully extensible, which means that more classes can be created in a future version of our app, and that would require no code modifications, just building on the classes we have already created.
In addition, as a part of the Proof of Concept of our project, we also wrote the code necessary for the connection of e-AMALTHEA to our Arduino UNO testing hardware. We created an extra class which contains a method that is used to scan a certain radius for a device with the same MAC address as the antenna attached to our hardware, and then performs a full handshake using the Bluetooth protocols, thus creating a back-end feature for our application that allows communication with specific hardware that transmits data. For more details on this process, visit the Hardware page.
Lastly, we started upgrading our GUI graphistically: we changed the application’s graphical
environment so that it is aesthetically better. After all, a more attractive user interface
contributes significantly in the application’s whole user-friendliness and also is a great
asset for a piece of software that is launched as a product. Unfortunately, we didn’t have
enough time to actually connect the new GUI with the back-end functions, so it remains as
a part of our future vision for e-AMALTHEA.
To visualize our application’s architecture and modeling in a standard way, we used the Unified Modeling
Language (UML), which is the most popular way to achieve a digital, object-oriented, accurate depiction
of a system’s design in software engineering. For these purposes we used Star UML, an open-source,
cross-platform software tool designed to create and edit UML models.
All the software for the application was developed in Android Studio, an Integrated Development Environment (IDE) specifically designed for developing software that operates on Android devices - since we didn’t have enough time to develop software that runs on more than one operating systems, we chose the Android operating system, which offers an extremely big demographic of commercial mobile devices globally.
The programming language we used in this environment to implement the main functions was Java, one of the most popular high-level, general-purpose, object-oriented languages, and to develop the GUI we used the Extensible Markup Language (XML).
Lastly, to support e-AMALTHEA with a manageable back-end infrastructure, we used Firebase’s Cloud Firestore. It enabled us to develop e-AMALTHEA as a global, serverless application, meaning we didn’t have to develop an entity-based database in an SQL environment, but use an already built, file-based system that can store, sync, and query data using cloud technology, for any user, at a global scale.
e-AMALTHEA as a tool has numerous extensions as a product launched within a kit-like product along with AMALTHEA or
as a tool intended only for research purposes. These are two very different perspectives, especially as far as legislation
is concerned, yet they are equally realistic for our tool and represent our future vision for e-AMALTHEA. Its commercial use
is pretty much summed up by its main functionality, as already seen in our project: the collection of data for the evaluation
of a person’s gastrointestinal health as a part of a greater holistic approach. Its research use is also very possible to be implemented,
considering that, if paired with the Amnesia anonymization tool, it can function as a database for the storage of anonymized, in vivo data,
filling the significant need for accurate experimental data in areas such as GI disorders. For more details on the future use of e-AMALTHEA,
visit our Implementation Page.
1st version: Ideation
v1.1: Architecture
Finding a motto, though, is only the first step. Every information system of a complex internal organization requires a formal method to represent its design, components and the relationships between them. This is why one of our first concerns was to clearly depict our application’s architecture, not only to display its function better, but also to compartmentalize our work. Modeling our application in this way helped us to focus on the important parts of its implementation and filter out any unnecessary details, code-wise, and also provided a formal documentation of its architecture in a language that is universal. Indicatively, we show the architectural model of the login and register functions:
Figure 1: Flow diagram of e-AMALTHEA’s functions.
2nd version: Graphical User Interface (GUI) Implementation
Figure 2: Activity_home.xml. In this part of the code, we are displaying the way we created the boxes of the menu.
v2.1: Login and Register Pages
We began by designing the login and register pages, which pretty much follow the standard authentication- identification process used in an ordinary phone application. In the login page, the user has to enter their email address and their password, and then tap on “Login”. On the bottom, there is the choice of registering, in case they have not created a profile yet. Tapping on “Don’t have an account? Register Here” leads to the register page, where they have to enter their first and last name, their email address, and a password of their choice, twice for verification purposes. When all required fields are filled properly, tapping on “Continue” leads to the main menu, just like the “Login” button does.
These pages, though, are built for all kinds of potential users, who may be either on the giving or the receiving end of a holistic treatment, meaning that the user can be either an expert or a patient. In our design we make a clear distinction between these two “modes”. Thus, besides the standard registering options that a patient-user would have to make, we designed a separate page where a user can register as an expert.
By tapping on “Register as an expert”, the additional credentials that are required are the Taxpayer Identification Number (TIN), Social Security Number (SSN), and personal ID number, and soon after these fields are filled properly, an “expert” account is made. These particular credentials are the ones mainly required to identify a health professional digitally, and ensure the authenticity of their alleged expertise, as we learned in our Integrated Human Practices meeting with Dr Vlachos. Of course, in all fields, e-AMALTHEA automatically performs validation checks, meaning every time they are required, the software checks if they are empty, invalid, or correspond to another account.
Figure 3: Login layout.
Figure 4: The register interfaces. A patient-user is required to fill only the fields of “Step 1” (on the left), whereas an expert-user also needs to also pass through “Step 2” so as to be recognized as an expert.
v2.2: Main Menu
By logging in -or registering, accordingly- the user is granted access to the main menu of e-AMALTHEA, where they can navigate to all the utilities it has to offer. As the icons indicate, the user has the ability to: view their profile, display their capsule results, answer a set of daily questions about their mental health, communicate (asynchronously or synchronously) and with their nutritionist, view a map with experts in their area and translate the app.
Figure 5: The main menu interface
v2.3: Profile
In “Profile”, the user can view the credentials they are logged in with, and they can also log out. The Profile page has many perspectives for back-end development in possible future versions, including functions like editing/changing the profile picture, a history of past measurements, or the number of experts that are logged in and online.
v2.4: Results
In “Results”, the user can display their capsule measurements plotted in a signal-versus-time diagram, and also “mess” with the time scale. That means they can view the measurements curve for any given time interval, regardless of its size. By zooming in or out, they can determine the size of the interval of interest.
Figure 6: Diagrams that display the results of a patient. A diagram that suggests an unhealthy state of the gut microbiome (on the left), and a diagram that suggests a healthy one (on the right).
3rd version: Database Connection
The database system we used for the alpha version of our application was Cloud Firestore. There, the useful information is saved in the form of text files (with a “.txt” extension), as opposed to any regular SQL databases that form hierarchies and dependencies between entities in which they store data. As soon as the files are stored in the database, every one of them is assigned a primary key, which is a number unique for each file and serves as an identifier. Nevertheless, the original primary key of each file is not visible to any user of the database; instead, a secondary, token key is created for every entry. After it is subjected to encryption by algorithms Firestore provides, the token key can be seen from a user who has reading/writing rights on the entry that the token key corresponds to. Thus, our whole database is neither a pure cloud service nor a totally local server, but rather a hybrid combination of the two. As Dr Vlachos advised us, we did not place our hopes entirely on cloud computing for the sake of it being a cutting-edge technology, but combined it with more conventional ways to form a solution that cancels out the one method’s disadvantages with the advantages of the other, thus improving the safety of the whole system.
Consequently, we draw a stark distinction between the user’s private information (e.g. SSN) which is stored in the cloud and the information that concerns the authentication system (email, password) which is not.
Authentication System
We achieve user identification through Firebase’s standard Authentication System. As we mentioned before, the Authentication System creates a second, autonomous database that handles this identification data, so that the main base (which stores data of sensitive nature such as the SSN) stays safely uninvolved. As soon as a user enters their email and password, the application connects with the Authentication System’s secondary database and checks if the email entered exists in the latter, and if so, the user is successfully logged in. This “handshake” is finished with a primary key being assigned to the newly logged in user and encrypted to a token key with a back-end process, so that they are identifiable at any given time and their activity is fully trackable. It is really important to note that while the primary key is constant for a single user, the token key changes every time that user logs in, a mechanism that adds an extra layer of safety in the user identification process.
User’s Data
The cloud component of our database follows a .txt file tree logic, which means that the hierarchies between the files are arranged in a way that resembles, or better yet mimics the tree data structure. It features two “tree” file collections: “users”, which contains all the information relative to the user logged in, and “results” which keeps their measurements. When a user registers, a descendant file is created in the “user” tree which includes both private and authentication data. Similarly, when the results are transmitted, a descendant file is created in the “results” tree that represents that user, which in turn has descendant files -the “leaves” of the tree, actually- that store the results (as numbers), the user’s primary key and a unique capsule ID (used to identify the particular capsule) respectively. The correspondence between the user and their results is achieved with the token ID, which is extracted with encryption from the primary one stored (back-end) at “results”. This constructs an extra safety net for the user’s data, that not only makes our database more hard and complex to attack, but also makes a big step towards data anonymization, a type of information sanitization that is extremely important in medical data privacy, as we confirmed in our Integrated Human Practices meeting with Dr Vlachos.
4th version: Functions Implementation
In the development of e-AMALTHEA we make a clear distinction between a patient-user and an expert-user and, at the same time, between different kinds of expert-users to ensure good practice, data safety and, of course, a holistic approach. This is where inheritance actually helped us, because it gave us the ability to create a hierarchy of structures and choose the level of abstraction we want to work in. For example, if we have conceptually separated a patient-user from an expert-user and we want to depict that to our code, all we have to do is define a user class, and two subclasses for patients and experts with separate fields and procedures that give them different attributes and rights in the app accordingly. But this is fully extensible: if we also want to separate the attributes and rights in our environment based on the specialty of an expert, we can derive subclasses from the class “expert”, “ gastroenterologist” and “dietician”, for instance. On the other hand, if we hypothetically wanted to create an object that is a user, or refer to the user property in general, we could just ignore all the subclasses that exist and create an object which is of class “user”.
Here you can see all the classes that we have created during our app making process. Ideally, there would be more, but, as we remarked above, our code is fully extensible, which means that more classes can be created in a future version of our app, and that would require no code modifications, just building on the classes we have already created.
In addition, as a part of the Proof of Concept of our project, we also wrote the code necessary for the connection of e-AMALTHEA to our Arduino UNO testing hardware. We created an extra class which contains a method that is used to scan a certain radius for a device with the same MAC address as the antenna attached to our hardware, and then performs a full handshake using the Bluetooth protocols, thus creating a back-end feature for our application that allows communication with specific hardware that transmits data. For more details on this process, visit the Hardware page.
Figure 7: The data transmitted, visualized in a terminal environment.
Figure 8: The login, Main Menu, and Chatting with experts interfaces accordingly in the new GUI.
Figure 9: Diagrams that display the results of a patient in the new GUI. A diagram that suggests an unhealthy state of the gut microbiome (on the left), and a diagram that suggests a healthy one (on the right).
Software Analysis
All the software for the application was developed in Android Studio, an Integrated Development Environment (IDE) specifically designed for developing software that operates on Android devices - since we didn’t have enough time to develop software that runs on more than one operating systems, we chose the Android operating system, which offers an extremely big demographic of commercial mobile devices globally.
The programming language we used in this environment to implement the main functions was Java, one of the most popular high-level, general-purpose, object-oriented languages, and to develop the GUI we used the Extensible Markup Language (XML).
Lastly, to support e-AMALTHEA with a manageable back-end infrastructure, we used Firebase’s Cloud Firestore. It enabled us to develop e-AMALTHEA as a global, serverless application, meaning we didn’t have to develop an entity-based database in an SQL environment, but use an already built, file-based system that can store, sync, and query data using cloud technology, for any user, at a global scale.
Future Perspectives
References
- European Commission. (2019). ASSESSING THE IMPACT OF DIGITAL TRANSFORMATION OF HEALTH SERVICES. European Commission Official Website. https://ec.europa.eu/health/exph/overview_en
- Stergiou, C., & Psannis, K. E. (2017). Efficient and secure BIG data delivery in Cloud Computing. Multimedia Tools and Applications. Published.