Monitoring Platform for Biomedical Sensors [302726]

[anonimizat]. The collection of locally waveforms is resulting in real time parameters inside a database; this is performed by the patient at home and can be used to verify the status of the illness via specific algorithms ([anonimizat], and diagnosis). [anonimizat], pulse and temperature algorithms. [anonimizat] a [anonimizat]. The advantage of such a [anonimizat] a [anonimizat].

Additionally, the created prototype will occupy a small space that can be loaded quickly into a specific box and the webpages and databases can be uploaded online. Designing of the software is done using the Java and C [anonimizat]. [anonimizat], [anonimizat]. It is possible to discuss of the emergence of the medical and engineering field by using an application as a communication channel. [anonimizat], [anonimizat].

[anonimizat]. [anonimizat], such as: EKG, pulse, temperature and so on. [anonimizat]. Thus, a [anonimizat].

This is the main reason why there is an importance of understanding the signal and illness before building an application useful to medical personnel. Last but not least, a [anonimizat]. Thus, it is possible to choose a medical database close to the application model that is to be implemented.

[anonimizat]. [anonimizat] or Raspberry Pi. As a framework for the electronical part, databases contributions play an important role in encapsulating the information and providing quality access to the medical data.

Telemedicine increasing services in modern society lead to an explosion in the application field, especially as a result of aging population over 60 years old in the European continent. Additionally, a constant monitoring is made on people between 80 and 90 years old, as a key element of the home care. As an example, PANCEA platform is used to facilitate the monitoring of cardiac functions inside home, with usage of different sensors located inside the rooms. [1]

Another approach is using Raspberry Pi to hold the sensor nodes and send biomedical data such as heart rate collected via ZigBee or Bluetooth to the user email accounts and support health monitoring. Project can be organized such that cardiovascular diseases are monitored for applications including anxiety or diabetes. Temperature sensors can also be used. Proposal methods can additionally include respiration information such as: respiration rate or body movement, the result being the same approach of using a server and sending data with normal/abnormal notification to the doctor/patient email. [2]

Bio-monitoring solutions also approaches the rise of wireless sensor networks (WSN), expanding the quality of clinical monitoring. The cheap and easily implemented solutions help at the construction of smart environment for the chronic illnesses monitoring or other long term monitoring cases such as daily activity recognition (ADL). Special standards have to be used in order to send the data. Normally, the IEEE 802.15.4 standard is used in hospital applications, at approximately 250 Kb/s. [3]

Furthermore, advances in micro-electro-mechanical systems (MEMS) allow the construction of low cost solution networks. Security and optimization are key terms in the challenges of WSN and wireless body area networks (WBAN). Also the biocompatibility is important to be considered, especially if device attached to the body or sensors implanted to a specific target organ. The functionality of such devices works using similar principles: user is automatically sent to a screen device, whereas the receiver unit can be connected to the user. Data is being further pushed using ZigBee as one possible approach. [4],[5]

In conclusion, physiological parameters can be easily monitored and easily sent via a receiving unit or server to be displayed. Other alternative options might be to alert the doctor via email. One important aspect is the sensor signals might be susceptible to noise and this has to be considered especially in high risk illness or elderly monitoring.

1.1.1. Types of sensors and biomedical uses

Another important aspect is understanding of the types of bio signals and therefore the means of data collecting. The electrical effects on living organisms results from the fundamental cellular properties, meaning the transmembrane potential and potential action. The mentioned properties appear because of the cellular excitation from the exterior and interior electrical charge. [6] The potential is given by the non-uniform ionic distribution in the intra and extra cellular space, as a consequence of active transportation. The cellular excitability lead to a manifestation in less than a fraction of millisecond, followed by a potential increase and a stabilization at the normal value with the enclosing and opening of the ionic channels, as seen in figure 1.1. [7]

Figure 1.1 – Ionic channel: General View

For the informational exchange in the medical world and the unification of medical and functional devices, methods were accepted as gathering techniques, as well as methods of interpreting the bioelectrical signals given by the human body. Therefore, the electrical activity generated by the functioning heart, detectable in the most parts of the body, is called electrocardiogram (EKG). This recording is made on different axes, conventionally chosen. It is discussed about frontal, transverse and sagittal plane. These anatomical planes are hypothetically used for the characterization of the human body, such that the sagittal plane divides the body into right and left, coronal into anterior and posterior, and transversal into superior and inferior respectively. [8]

The knowledge given by the positioning is important for the gathering of the data. Practically, the signal is gathered in the form of a vector given by the electrode positioning. The wrong positioning might lead to an error in diagnosis of the patient. The Einthoven triangle includes the positioning of the sensors in an equilateral triangle. Therefore, the points are right and left hand, plus the left foot. The reference in this case is the right foot. [9]

The signal appreciates the pump function determined by the moving muscular muscle of the heart (myocardium). The regular, rhythmic contraction of it determines a cardiac cycle and is correlated with the depolarization of its cells, cells of the type pacemaker. This auto depolarization takes place automatically and therefore, can be considered that the cardiac muscle has the property of inherent rhythmicity. The cells have a rate of 60-100 depolarizations per minute and are located in the sinoatrial node. The structure of the heart is presented in figure 1.2. [10]

Figure 1.2 – Heart structure

This parameter of depolarization indicates also if there is a good functioning of the heart. In the moment at which the parameter reaches 40-50 depolarizations per minute, the source can be further taken by the atrioventricular node and further, at 20-40 depolarizations per minute, by the ventricular muscle. The problems can be therefore detected at the level of EKG, a normal functioning being presented in the figure 1.3.

Figure 1.3 – Electrical activity of heart

Other parameters are given by the registered QRS complex, such that every segment presents itself at a specific duration and amplitude. The most important information can be taken from the P wave (atrial depolarization), QRS complex (ventricular depolarization) and T wave (ventricular repolarization). [4], [12]

Figure 1.4 – EKG: QRS complex

All the data presented above are only the base of what the EKG represents and the type of information taken from it. This proves the importance of knowing this particular data in order to realize an interface that would properly display and store the signal. The most frequent utilized processing method is using the frontal plane. Still, other variation can be given by the vector cardiogram, an analysis of the cardiac vector and distribution at the separation level between polarized and non-polarized field. One example for this system is the Frank system. Another important knowledge is given by the type of EKG signal also. A usual EKG signal gathered by 3 electrodes is different than an abdominal fetal EKG, for example. In the case of extracting the fetal EKG (f-EKG), different processing algorithms are used. [13]

As a complementary technique to EEG, a discussion can be made on medical imaging, as well as EMG signals. Of course, a variety of parameters can be discussed, but the most important in case of monitoring is the cardiac function. It is therefore demonstrated that the multiple information achieved by each of the signal is important, although different fields are accessed by it. From this the importance of the bioengineer to find the best interface that can integrate the information, depending on the analysis. It is necessary the type of data, the informational content, connection to the biological world and possibilities given to display the data to an unauthorized medical staff.

1.1.2. Commercial solutions

For the purpose of analysis of commercial solutions, different monitoring solutions are presented in respect to sensing and market availability. If referring to simple EKG monitoring solutions, the price of a medical device ranges from $73 to $158. Nevertheless, as the solution gets more personalized and includes more signals, the price can rise up over $1000.

Modern solutions try to integrate them on single chips such that the price might decay in large productions. Samsung is therefore one example for bio-monitoring solutions, integrated on a single chip. The bio-processor is dedicated to smart accessories such as mobile devices. In principle, the technology can be integrated to fitness applications, but not only. Besides the pulse, the system integrates also bioelectrical impedance, PPG and EKG, as well as GSR. [18] It can operate as co-processor or just stand-alone system. The configurations available are presented in figure 1.5.

Figure 1.5 – Samsung Monitoring Solution: Hardware View

Another solution implemented in Japan is the bio-signal telemetry application, gathering bio-medical data and transmitting it via wireless connection to the phone or PC. The solution called HRS-I is collecting data through sensors attached to the chest, leading to information such as body temperature, EKG or stress levels from the fluctuation of the heart beating.

The majority of technologies used are integrating Bluetooth for data transmission to medical or other personnel, such that personal activity can be tracked. A solution for long term monitoring is given by 9Solutions, implementing also some alarm functions in case of caregivers requirement. [19]

The directions of the applications do not stop here. Smart textile implementation lead to existing of biomonitoring t-shirts for EKG, EEG or EMG signals. Cameras can be also integrated for monitoring, although the discussion about ethical aspects holds here. Solutions examples include AiQ Smart Clothing, presented in figure 1.6 a).

Figure – Commercial Monitoring Devices: 1.6 a) – Sirpa and BioMac monitoring health solutions

Of course, solutions can also be implemented by just directly adding them to the body. This can be done by using bio compatible adhesives, such that data is being collected and send to a mobile phone. Such a system is implemented by Metria Wearable Sensor, presented in figure 1.6 b).

Figure – Commercial Monitoring Devices: 1.6 b) – Metria and Imec’s biomonitoring solutions

Depending on the signal needed, devices can be focused on a signal solely. For example, the Imec’s EEG headsets develop a monitoring signal that gives a better EEG quality and sends the data in real time. [20]

What can be summed up after the commercial medical solutions description is that the advances are made regarding both efficiency and price balance, such that the research and development currently done in the field might lead to worldly used integrated devices. This is the main reason why the current device performed in this thesis is meant to be a both feasible and cheap solution, according to current market solutions.

1.2. Rheumatic heart disease

Rheumatic heart disease (RHD) is the most common acquired heart disease in children in many countries of the world, caused by one of the top 10 deathly infections, bacteria A Streptococcus (GAS). Still, RHD is a condition that can be prevented and controlled with strep throat antibiotics, such as penicillin. Furthermore, normal strep injection might bring benefits for avoiding the catching of other infections. [21], [22]

One common result is the fever that primarily has effect on the heart, nervous system, skin and joints, leading to fibrosis or heart failure if not treated. Moreover, the damage might lead to a valve disorder (mitral valve particularly) that remains even after treatment and modification of the pericardium and endocardium. [23], [24]

RHD became into medical attention after reaching the number of 325.000 children each year and about 18 million people having the illness.

In India, the first clinical evidence of RF came in 1935, being a relatively new disease. The figure 1.7 presents the admissions in hospitals under RHD diagnosis for India, as a special case example. [25, p. 50]

Figure 1.7 – Case Study: Percentage of RHD patients in India

Globally, the estimation of the children reaches the number of 2.4 million, as seen in figure 1.8. In Asia, the number raised from 1.9 to 2.21 million, reaching a mortality of 1.5 % per year and estimated global deaths up to 290.000 per year.

About 282.000 cases of RF are added each year, whereas the remaining hospitalizing cases have potentially RHD.

Figure 1.8 – Case Study: Global and Asian cases of RF and RHD

Studies were also made in Australia, from which 1.479 cases were reported in 2010. Out of them, 969 were reported in females and 510 in males, data being grouped into age intervals in figure 1.9.

Figure 1.9 – Case Study: RHD in Australia, Northern Territory

1.2.1. Description of biological changes

In this subchapter, a short overview of the biological changes is presented, in order to better link the diagnosis methods. As an inflammatory illness, the debut comes at approximately 3 weeks after a streptococcus respiratory infection. Usually is a pharyngeal infection and is caused by beta-hemolytic streptococcus that causes the hemolysis of red blood cells. Nevertheless, not all patients with streptococcus infection can inquire rheumatic fever symptoms.

A streptococcal infection is mostly located in the upper respiratory tract: rhino pharyngitis. The most common form of manifestation is that of an erythematous angina, accompanied by fever and dysphagia, the intensity of which is particularly variable. It should be kept in mind that this precursor angiogram, which prepares the disease-causing pathogenic reactions, has no characteristic of differentiation in favor of streptococcal etiology, other than positive pharyngeal cultures, which cannot be available within a few days. Local phenomena yield promptly to antibiotics administered at the dose and for the appropriate period, when the pharyngeal cultures usually fail. [26] The mechanism of RHD is shortly described by figure 1.10.

Figure 1.10 – Mechanism of RHD

Since there is no criterion identifying the rheumatic future at this stage, any erythematous angina should be suspected as streptococcal etiology, especially in children and adolescents, even before bacteriological confirmation.

The following latency period is a period of definitive development of the multiple manifestations of the disease, which is presented first in the analytical aspect, then in their sequence and grouping. In the status period, general manifestations, arthritis, cerebral, cutaneous and other manifestations are included. General manifestations refer to fever, tachycardia, sweating, pallor, and asthenia with weight loss. Fever is the most common sign, which has been present since its inception and has been relatively loyal to the morbid process.

The duration of the fever usually does not exceed three weeks, but spontaneous developments in which the fever persisted for over a month have also been described. Still, it can be deduced that the absence of fever does not definitely signify the extinction of the active rheumatic process. Weight loss is more characteristic of children and is, as it seems, one of the clinical arguments for affirming the evolution of rheumatic disease. [23],[27]

Symptoms of the disease are therefore extremely variable. Children that suffer from cardiac damage have frequent skin manifestations and joint manifestations are more likely to be articular pains than arthritis. Instead, adults experience a more nocturnal arthralgia and rarely cause neurological and cutaneous damage.

Out of all, cardiac damage is the most severe manifestation of the disease. Symptoms are the result of affecting all cardiac structures: endocardium, myocardium, pericardium, and are chest pain, palpitations, fatigue, choking. Most of the time, however, cardiac damage is completely asymptomatic, being discovered late in adulthood. [24]

In conclusion, a constant monitoring is needed to prevent this possible complication, especially when referring to children.

1.2.2. Diagnosis of rheumatic heart disease

One of the major problems of RHD is that there is not a simple test in order to diagnose it, meaning that it might look at first as an inflammation in the body, arthritis seen with redness and pain in joints (knee, ankles) or fatigue. Therefore, the test combined with discussions with the patient might lead to a final diagnosis [28]

Rheumatic heart disease is most accurately diagnosed using ultrasound, referred to as echocardiography. For this specific analysis type, standard guidelines have been developed, the importance being put on heart valves and the severity of damage to each of them. The doctor may order a throat culture or a blood test to check for strep throat or signs of a recent strep infection, as well as performing other blood tests. Analysis involves EKG, MRI or chest X-ray to check size of heart/excess fluid in lungs. The doctor might also look for skin nodules or listen to hear possible heart abnormalities, especially at children in first phase of examination. [29], [30]

Additionally, it might me that some valves are affected and symptoms are not noticed for a period of years, regardless of developing small ones such as murmur or chest pain, weakness and breathlessness. The risk factors might also have a strong influence on patients, such as family history or environmental factors (sanitation condition, working in overcrowded places, etc.). [31], [32]

Figure 1.11 – a) Hematoxylin and eosin stain of RHD b) Culture of streptococcal in 16 years old12

A number of different blood tests may also be used to look for indications of rheumatic fever. These include:

C reactive protein (CRP) – produced by the liver and shows inflammation in the body if seen in a larger amount;

Antistreptolysin O titre (ASOT) – antibodies produced in response to streptococcal infection;

Erythrocyte sedimentation rate (ESR) – changes due to various substances produced during the immune response. [33]

Furthermore, CD4 and CD8 T-cell subsets are present within acute rheumatic fever valves, immunochemistry test being able to confirm the diagnosis. [34]

The Jones criteria, introduced in 1944, are as a set of clinical guidelines, based on the prevalence and specificity of manifestations of rheumatic fever summarized from major and minor considerations, as referred in figure 1.12.

Figure 1.12 – Case Study: Changes following reviews from AHA and WHO

1.3. Online medical platforms

Biomedical databases represent a modern field of study, especially if referring to the medical image storage and to intelligent systems for detection of specific illnesses. The growth of medical databases revolutionized telemedicine as adjacent field, bringing essential advantages to the survival rate through distance treatment or under specific unexpected situations.

The main goal is the possibility of offering a variety of parameters and data that might lead to high benefits in the medical community through the organization of databases as qualitative as possible, under main categories of illnesses and medical changes. A better understanding of physiological and pathological changes in humans can be reflected in a growth in the living quality, as well as in medical applications for diagnosis and treatment. [35], [36], [37] The necessity of understanding the human physiology lead to the construction of a database such as PhysioNet, database held by NIH National Center for Research Resources. This became in short time a main location of interest for over 50 types of physiological signals, as well as the adjacent hardware. There exist over 650 published documents, all of which contributed to the growth of the academic and research medium. Having the main motivation the display of the data, in the last 16 years researchers had a wish to reduce hard configuration for accessing the database.

If we extend this software idea to open source, massive resources organized in databases could represent the foundation for new projects, bringing benefits to not only the data, but also to the research itself. The studies and results in computational field lead to a future growth of the algorithms that support the instrumentation. Even if the progress might be visible, the interest in extraction of the right amount of data comes with some problems to overcome. [38], [39]

Different applications in beta or commercial versions offer the interaction with databases, difficulties coming into account when there is a matter of interface standardization. In other words, they are destined to a specific signal and permit one predefined function. It exists nowadays solution to gather EKG, EMG and EEG signals, as well as genetic information, each coming with a series of parameters. Moreover, the actual interfaces permit full access to the code. This is an advantage for the engineers that might want to create open source programs, but not in case of an unauthorized medical staff.

Furthermore, since the doctor meetings on long distance are becoming a routine, it is important that data is shown for discussions, whereas not compressed with errors that can disturb the information presented to the patient/nurse. The images presenting skin rupture for example, or ultrasound images or X-ray images, should preserve the colors and image quality without adding additional noise. The key of success in telemedicine therefore includes the accepting of a specific format accessible to physicians, medical staff, bio-engineers, etc. [40]

1.3.1. Importance of online platforms and current research facilities

Essentially, medical databases follow the access facilitation and information display for the authorized medical staff. On the other hand, the integrated systems have a different behavior, but in the end the tendency and desire of engineers towards standardization of the data gathering is applicable. [41]

The studies involve the medical, as well as the engineering-related fields, massively depending on the quantity of the medical data. Therefore, it can be estimated, for example, that 82% of the medical files in Taiwan already adopted a digital model. As a result, over 200 articles from scientific domain mentioned techniques for design and integration of the medical data. The National Health Institute from Taiwan supports scientific research, emphasizing the importance of the clinical data management in different countries. [42] The National Health Insurance System in France organized as well a database through the National Informing System for Illnesses that covers the whole country population (over 65 million inhabitants). For study facilitation, the medical data were made available for using in applications. [43]

Furthermore, once with the appearance of such medical databases, an increased interest also arose from the medical error costs perspective in healthcare institution. The perspectives from 2010 were to prevent such errors, leading to large amount of money invested in projects. Of course, additional to the repercussions on patients, such errors reduce the hospital profit. [44] Methods for management of the databases can depend also of the information type, acquisition location or sampling method. The methods that are content-based became an efficient instrument for interrogation. The features and right representation is therefore an important aspect of the topic. [47], [48]

Besides these methods, it is necessary to have a support system that can take the decision, having the capacity to sustain the clinical process through continuous learning, from diagnosis to investigations or long term treatment. Nowadays, informational system for web management can be found, being used in processes of neuroscience and clinical data processing. [49], [50] The growth in computer science also lead to an informational explosion, subject to security and recovery of the data. This can lead to pattern based organization of the data, where the term machine learning refers to the learning process and adaptation through genetic algorithms most frequently. [51] Principally, the algorithms used are named data mining (DM) algorithms, the success depending on the minimizing and decision making processes, without information loss. [52],[53] Of great interest is the category making and processing, storage and also reconstruction, realizable more or less stable by using fuzzy algorithms. [54]

In the presented context, it can be concluded that, together with the management of the data, there is a general concert regarding protection. In the present there is a discussion of integrating large amount of biomedical information, therefore smart integration is required.

1.3.2. Examples, interface use cases and issues

Databases are one key element for storage and gathering all together biomedical information. Databases as NCBI offer informational support and data acquisition through different technologies, such that the signal data can be stored and analyzed. Once with the understanding of this necessity, the management of such information comes into account. With this purpose, different databases available online can be accessed and compared.

ECG Web Database is an online database, created especially for the academic field, in association with Northwestern Medical University and Technological Academy from the same institution. It presents a collection of ECG signals and their interpretation, for a didactical purpose. The interface is presented in figure 1.13.

Figure 1.13 – Search into the ECG Web Database

Nevertheless, the database presents the data in an image format, being just physical scans of the acquired biomedical data. Therefore, they cannot be used for the purpose of automatic data gathering and processing. One data sample is listed in figure 1.14.

Figure 1.14 – EKG Analysis from ECG Web Database14

One online available database, held by Dean Jenkins, was set up from early 1995 under the name ECG Library. The data is presented in form of scans, with different affections presented. A shortcoming of these types of databases is the format in which the data is presented, leading to problems for the following processing steps.

As a conclusion to the analysis given in this sub chapter, a table containing some databases is presented. In it, advantages and disadvantages are presented, supporting the reference n close link with the EKG signal, as a priority data in this master thesis.

Table 1.1 – Database review for EKG

1.3.3. Current solutions and security issues

As presented in previous chapters, there are special principles for guidance in designing such databases. For example, finding and organizing the necessary data from the current management system. Such an application becomes a complex program to provide user interface for the medical staff and patients. Therefore, security is the first issue that comes into account, completed by the personalized version made for different users.

Another aspect is existence of special categories such as: age, sex, id or other necessary additional information needed to compare or parse for the biomedical data. This comes with disadvantages mostly for the table based databases. Still, some solutions already exist in the hospitals, not available online and not outside internal network.

Such an application is given by NORAV ECG Management System, being used for the management of patients. Is an easily implemented interface designed for hospitals and allows data availability by an SQL interrogation application. The interface is presented in the figure 1.15 below.

Figure 1.15 – NORAV ECG Management System Interface

All such applications come also with the possibility of data transmission, in and outside the medical unit. For example, systems such as AcqKnowledge come as support of the acquisition system Biopac, representing a simple and interactive program that can be used for different monitor types, as well as for just data storage. The system permits processing of the data, but in an engineering approach. Functions such as display of the EKG signal or calculating the heart rate are included.

Other applications can be related to genetic engineering study or bioinformatics related fields. Experimental databases for genetic expression have to, in this case, deal with subsets of relevant bio-information. [57] Institutions as Illumina offer programs of detection for sequences of mRNA type, genetic information search from RNA, as well as methods for segmentation of the data. Computational analysis over genes is also provided by ZENONBio, where marker identification is introduced to help potential therapies. [58], [59]

Because of legislation and ethical issues, there exists standards specially integrated to protect and add non visible watermarks without modification of the data. Initially created to offer multimedia rights, watermarks were successfully integrated into the healthcare field. [60] Furthermore, the personal data should not be shared by any means outside the medical network. Although security platforms already exist for data administration (BlackBerry Secure), the problem of medical data extends also the ethical aspect of data scarring.

The policy of data security inside health institutions always requires special terms and conditions for usage. Besides personal/general information such as phone, address, sex or family data, the biomedical and physical data is being included. A concrete security definition of the system is therefore needed.

Inside EU, directives and norms are already implemented regarding electronical health data. In the official monitor of each country, the health ministry is required to add specific information regarding the medical historical data, medical data as well as personal data. All of the data given by medical service provides has to present an electronical signature and fulfill the requirements.

To conclude with, the development of the platforms includes not only the solution itself, but also the security requirements presented in the respective country. Without it, the solution cannot be valid or taken to commercial stage. Furthermore, the ethical aspect is always taken into account, irrespective of the laws and rules available.

Methods

Bio-monitoring device

This section presents the implementation of the data collecting and monitoring device, as well as additional web and storage related topics. The sensor selection, algorithm and solution description for the web platform is further described in detail. Additionally, a full description of the processing of the data, transmission protocol and data flow and management is presented. Figure 2.1 illustrates a hardware model of the used sensors used in the implementation stage of the prototype for data monitoring and data collecting device as complete medical equipment.

Figure 2.1 – Presentation of Hardware for the biomonitoring device

For the implementation, a Raspberry Pi 3 and an Arduino Feather M0 are used in order to present the biomonitoring and storage solution. The signal acquired by the selected sensors is being encapsulated inside the Arduino microcontroller, together with additional code for extraction of: temperature, pulse, and EKG, as well as for the final data transmission. The main steps in the data collecting part are the following:

Figure 2.2 – Arduino implementation as biomonitoring device

Furthermore, the Raspberry Pi holds the other part of the communication algorithm. The remaining elements from figure 2.3 will be incorporated in the data storage and management subchapter, including the realization of the additional web platforms: locally, for the user and outside the internal network, to any user that hold login rights (normally, the medical staff but also technicians).

Figure 2.3 – Raspberry Pi implementation as data management device

Description of sensors used

For the acquisition of the EKG signal, sensors provided from OLIMEX together with the Arduino shield were used. The passive electrodes allow biofeedback capture and therefore, biomonitoring. The hardware elements are presented in figure 2.4.

Figure 2.4 a) EKG/EMG sensors b) EKG/EMG Olimex shield

The shield provided by OLIMEX allows the Arduino to easily connect to the sensors and record the cardiac information. The data comes in 6 channels as analog input signals (A0-A6), generation of calibration signals being seen on digital outputs D4-D9. The product is working connected to Arduino boards at 3.3 and 5 V (default is 3.3V).

The OLIMEX solution converts the analog differential signal attached to its inputs into a single stream of analog data, discretized for processing. The total gain is made out of the instrumental amplifiers and 3rd order Bessel filter, with a cutoff frequency set to 40Hz. [61]

Figure 2.5 – Connections available on OLIMEX EKG/EMG shield

Nevertheless, the shield brings some problems in regard to usage of the 3V connection for the other 5 sensors, making the Adafruit’s Arduino product Feather M0 more approachable because of the size and the 4 extra pin extensions available, compared with Arduino Uno. This implies reducing the number of cables and solves the problem of the voltage quality.

Figure 2.6 – Arduino Feather M0

For the new EKG testing, the AD8232 Heart Rate Monitor Sensor has been used. The block-integrated solution is designed to amplify bio-potential signals in noisy condition, with an operating voltage of 3.3 V. The sensor gives an analog output and has a 3.5mm Jack for the pad connections. The pins SDN, LO+, LO-, OUTPUT, 3.3V and GND are connected together with RA, RL and LA in order to remove wire connections. The sensors include a gain of 100 and a low-pass filter with adjustable gain, being presented in figure below.

Figure 2.7 – AD8232 Heart Monitor solution

For the connection, five pins needed for the board are: GND, 3.3V, OUTPUT, LO- and LO+, all of which are initially attached to male-male header strips on the Feather. The pads are already attached, therefore the RA, LA and RL are considered predefined in the hardware solution. The table 2.1 presents the reference connections on the Arduino side, in our case Feather M0 device.

Table 2.1 – Pin connections between Arduino and AD8232 Heart Monitoring

The sensor has pins for the input signals (IN+ and IN- of the instrumentation amplifier) connected to the left and right arm, as well as for the right leg feedback. It contains elements as reference buffers, operational amplifiers and comparators that detects a possible disconnection of the electrodes. Shutdown control inputs, as well as power supplies ground and terminals are also available in the pin configuration. The complete table for the schematic at figure 2.8 is presented below.

Table 2.2 – Pin function description for AD8232 Heart Monitoring Sensor

Figure 2.8 – Functional block diagram for AD8232 EKG sensor24

For the electrodes marked with L, R and DRL for left, right and right leg respectively, some possibilities of positioning are presented in figure 2.9.

Figure 2.9 – EKG: different sensor connections23

In the testing procedure, the Lionheart 1 ECG/Arrhythmia Simulator was used to verify the accuracy of the chosen AD 8232 solution. The resulting EKG waveform was compared to the original one displayed using Biopac systems solution.

The specification of the chosen simulator includes using different EKG waveforms as well as amplitudes and different configurations. In this particular case, only the RL, RA and LA were used. Best pads were also chosen during this testing: SKINTACT EKG sensors. The configuration for the testing phase is presented in the next figure.

Figure 2.10 – Lionheart 1 ECG/Arrhythmia Simulator and connections to AD8232 and Arduino Feather M0

SKINTACT Monitoring ECG Electrodes chosen for the monitoring device are of 50 mm diameter and used for single data gathering. This implies a hygienically usage for the patient and easy application method due to the solid adhesive hydrogel. The patient can attach the electrode for long, as well as short term, with minimal skin reaction even in not prepared skin (no medical preparation needed). The electrodes have an Ag/AgCl layer and the AgCl solution is only positioned at the interface to the gel to prevent possible corrosive effects.

Figure 2.11 – SKINTACT Monitoring EKG Electrodes

The next sensor used is a pulse sensor that connects to the Arduino device in order to refer to the oxygen load in the blood. The model used is the one represented in figure 2.12.

Figure 2.12 – Pulse Sensor

Pulse oximetry refers to O2 concentration in blood (hemoglobin bounded or dissolved in plasma). The principle of the sensor is referring spectrophotometry, as well as Bees’ law that determines absorbance based on detected light intensity. The modification comes in two types of hemoglobin (Hb), which is: reduced and oxygenated.

The light can be of visible source in infrared (IR) and in visible spectrum (red light). Furthermore, the source and light sensors are coupled mounted. As the consistency of the tissue remains the same, the only variation is in Hg concentration. The differences of absorption are calculated for both sources, as they have significantly different optical spectra in the wavelength range from 500nm to 1000nm. [62], [63] Then, in the direction in which the proteins are aligned orthogonal to the flow direction, a high flows appear (systolic phase). The reflective area of the blood cells is decreasing during the systolic and increasing and diastolic phase. [64]

Figure 2.13 – a) Absorption spectra of Hb and HbO2 b) the systolic and diastolic phase

Figure 2.14 – Sensor parts and connections of the Pulse Sensor

Conventionally, the time at which pulse waveform reaches 50% of its maximum value is used to indicate the beginning of a pulse, therefore the N-N interval is the time between pulses or between the R’s wave of the EKG, as illustrated in figure 2.15. [65]

Figure 2.15 – R-R and N-N interval for the pulse sensor signal registration

For the connections, the ground and supply are firstly considered for connection. The signal is connected to the microcontroller’s analog pin.

For the BPM extraction needed, the signal is registered every 2 ms such that interval between beats (IBI) is being tracked as a sample difference between two consecutive peaks. In this case, the track is made according to the steepest slope point, when signal is reaching 50% of its maximum value. An additional testing is done for the presence of the pulse.

Another important bio-parameter to be recorded is the body temperature, of which presence can indicate a malfunction in the immune system or better said a first stage body reaction to illness. For this, DS18B20 temperature sensor is being used with the 1-wire protocol. For the connections, 3 main wires are available to be set as GND, voltage (between 3 and 5.5V maximum) and the digital pin connection on the Arduino side. [66] The connections, as well as the temperature sensor are presented in figure 2.16.

Figure 2.16 – DS18B20 Digital temperature sensor

The chosen sensor has a good range up to 125°C, temperature that can never be overpassed. Furthermore, the precision of the sensor is of 12 bits and a 4.7k resistor was added as pullup when using the sensor. [67] The temperature data acquisition was further added to both database and online local web page, as well as in all rheumatic heart disease algorithms.

2.1.2. Wireless communication

Figure 2.17 – The CC1101 Wireless module (RF1100SE) with pins available

For the wireless connections, the CC1101 modules were chosen. The sensor can operate on a range of frequencies from 433 to 915 MHz, being of ideal use for the Arduino microcontroller range, as well as Raspberry Pi. The minimum operating speed is 1.2kbps, whereas the highest is 500kbps.

Figure 2.18 – Arduino Connections Example to CC1101

The other connections for Raspberry Pi are presented in table 2.3. When communicating using the SPI bus, GDO0/GDO2 header is not needed.

Table 2.3 – Pin Connections for Arduino Uno and Raspberry Pi 3 with the CC1101 module

The first part of the communication protocol was the set-up of the registers such that on both Arduino and Raspberry Pi side, the data would match. This registers used in the transmission code also implies the chosen parameters for frequency, channel, address or modulation. In this particular case, the 868 MHZ. 115 kBaud for data rate and a 2-FSK modulation format with the 199 kHz channel spacing was chosen. Furthermore, a carrier-sense above threshold solution was chosen for the sync word, as well as a fixed length (PKTLEN). The data was first tested with the software provided by Texas Instruments, SmartRF Studio, as shown in figure 2.19.

Figure 2.19 – Register settings for CC1101 module inside SmartRF Studio

2.1.3. Processing algorithm

For the EKG feature extraction, pulse and AD8232 Monitoring sensor are being used. The BPM extraction is done using the pulse sensor, having good performance even on noisy signals. The 3 connections are done according to the table below.

Table 2.4 – Pulse Sensor connection to the Arduino Feather M0

The algorithm uses 5 main variables to track the BPM value: signal (the raw analog input that is updated every 2 milliseconds), IBI (time interval between beats), pulse (used to give a sensing of the heartbeat that was found), QS (similar to pulse, but holds the updating of the BPM value) and not the least, the BPM value searched. Every maximum local peak is tracked such that the intervals between two consecutively peaks are being stored. The average of the interval is then used to get the beats per one minute.

The acquisition of the pulse signal, as well as the tracking of the IBI values for the BPM algorithm is being presented in figure 2.20 below.

Figure 2.20 – Pulse signal (green) and IBI tracking for the BPM extraction algorithm (red)

To continue with the EKG feature extraction, a first step in the processing algorithm is the filtering of the signal. As many biological signals, EKG is particularly sensitive to the noises existents in the operating background. With the signal strength being very small, any additional noise or unwanted signal will be together amplified by the operational amplifier included in the AD8232 monitoring sensor.

Among them, the most common noise sources include: the muscular movement, interfaces with the power line or the baseline wander. The filtering is important in order to get a good QRS complex, whereas the process is to be taken carefully. Any additional distortion can alter the desired intervals. Baseline wander is one of the most prominent noises in the EKG signal, especially since the monitoring is performed at home and respiration, as well as body movements might appear. This low frequency high-bandwidth components cause problems in detection of the segments including S or T peaks. Muscular noise filtering, on the other hand, might add some further problems with the filtering dependent on the intensity of the movement.

Nevertheless, a local time-variant filtering can easily solve most of the problems by adapting in respect to the reference local mean that is adaptively learnt during the signal acquisition. Some examples of the signals taken with the AD8232 Monitoring sensor including baseline wander and small muscular movement are presented in figure 2.21.

Figure 2.21 – Different motion and baseline wander noise on the EKG signal during acquisition via AS8232 Monitoring sensors

Figure 2.22 – a) filtered EKG signal b) noisy EKG signal

Figure 2.22 illustrates the increased signal quality after applying a local filter including the mean learned during the acquisition process. The quality of the signal is immediately increased only by subtracting this mean value, such that the resulting amplitudes can be used for extraction of the RR and PR interval.

The PR interval is extracted in order to give more information about the existence of problems in the AV node, completing the RR interval information which is also used in the pulse algorithm for the BPM extraction. Normal interval values for the PR are from 120 up to approximately 200 but no more than 240 milliseconds, whereas the RR interval should have values between 0.6 and 1.2 seconds (600-1200 milliseconds). The intervals are obtained by difference between two consecutive peaks in the referenced amplitude sectors. When more noise occurs, PR intervals are no longer relevant in the referred levels, therefore an additional variable for noise is added to count the variation of local peaks during specific data acquisition time intervals. Some locally visualized results are presented in figure 2.23 below.

Figure 2.23 – Results for the PR and RR interval (ms) during the EKG data acquisition of the AD8232 module

Online platform

The term for telemedicine is mostly used for communication and multimedia, such that the patient can be consulted from distance and all the personal medical records are made available for the doctor that is offering the consultancy. For that, secured database and connection with the patient should be ensured.

In this project, there is a mixed usage of both tele diagnosis and tele consultancy aspects. A predefined algorithm can alarm the doctor when the parameters are out of rage or there are some equipment problems, whereas the data is stored on long term for analysis and the patient can interact in real time with the doctor via emails.

Therefore, two main web page interfaces are implemented: one locally via internal network, (for the patient) and one online (for the doctor) with the possibility of visualizing the data for all the patients allocated. In between, storage of the data is assured. The steps in implementation are presented in the following 2.24 scheme.

Figure 2.24 – Main steps in implementation of the two online platforms

The application implies therefore the construction of two main websites, each of it having its core algorithm and alarming functions, as well as communication channels available. The doctor is being able to visualize a wider range of data out of all his registered patients, whereas the patient can visualize the main parameters and interact with the doctor in emergency situations.

2.1.1. Web service implementation

For the implementation of the web service, a local solution was first tested. In order to provide the development tools, some open source development solutions were found. XAMPP is an Apache distribution containing MySQL and PHP interpretation scripts, needed to communicate with the medical database via an interactional website. Furthermore, the Raspberry Pi device is able to push data to the database, data to be displayed to the users. Figure 2.25 below presents the interface of the program.

Figure 2.25 – XAMPP Control Panel for Database/Web Testing

After locally testing the database and the website, the code is transferred to a domain that is holding its own online hosting. This will assure that data can be visualized also outside the local network. Figure below presents the main cPanel of the domain e-medicals.eu.

Figure 2.26 – cPanel of domain e-medicals.eu

Figure 2.27 – FTP file for connection e-medicals.eu

For pushing the data on the website, a FTP transfer is used. In figure 2.27, the configuration file, client name and log in information is presented. After the connection, the database and html/php content can easily pushed on the domain. Figure 2.28 presents the connection to the domain e-medicals.eu for file transfer.

Figure 2.28 – Web files transfer to online domain e-medicals.eu

Figure 2.29 – Data presentation on e-medicals.eu

The primary goal of the domain is to hold the public html files (figure 2.29), as well as the database that is required for the back-end development. The structure of the database includes patient and doctor information, as well as login information.

The sessions provide a secure access to the medical data, whereas the IP information and a predefined time are taken into account. The verification of this parameters and direct access to the database is provided on each of the pages available on the domain, such that no undesired authentication is permitted.

Furthermore, medical diagnosis information is hold and associated with each of the patients available in the database. Figure 2.30 below presents the database structure in the back of the domain e-medicals.eu. The bold elements are the primary keys of the database tables, whereas the italic ones represent the connections between them (one-to-one relationship).

Figure 2.30 – Database structure on e-medicals.eu

The application is further tested, such that all pages meet the 3 main requirements:

Users – review of biomedical parameters

Content – display of the parameters

Context – what the parameters are needed for

The structure should be accessible via all internet connections, having a clear design for all platforms: web, tablet, phone (IOS and Android).

The principal login page is linked from the homepage to the two main directions: doctor review (personal information and possibility of adding new database information regarding security) and patient review (data with possibility of disease information display or adding to new doctor, etc.).

All of the presented pages are encapsulated in an easy design for accessible display via all means of login. Pages are reviewed after design also via different phone operating systems. Figure 2.31 presents a review of a random page on the domain e-medicals.eu via IOS operating system.

Figure 2.31 – View on IOS for e-medicals.eu

Figure 2.32 – Login on e-medicals.eu via Android device

The next important concept of the web interface is encapsulated in the main index file. The login for the e-medicals.eu platform is designed around the concept of sessions to be verified at each of the webpage branches available.

The database already contains the name of the username and associated passwords that are allowed inside the web platform. Furthermore, each login assures the creation of a new session stored inside the database with information regarding IP and given time on the platform. The timing ensured an automatic logoff of the user, such that people using the mentioned login devices cannot access later the information without an additional password confirmation.

Nevertheless, the user can always decide the time in which he wants to leave the platform and logoff via specific buttons attached at each bottom of the pages. Figure 2.32 presents the interface for the login on an Android device. Furthermore, the next pages available presented in figures 2.33 and 2.34 gives an overview over the possible data available for personal usage (doctors) and patient usage (medical records, doctors and associated illnesses).

Figure 2.33 – Contact and personal page presentation on e-medicals.eu

Figure 2.34 – Details about patients and illness on e-medicals.eu

Figure 2.35 – Adding new information in database via e-medicals.eu

Moreover, the medical staff has the possibility to directly alter the database by adding new information to the patient, such as new diagnosis or new associated doctor in case of further analysis needed. All these mentioned pages are available by selecting the patient needed for modification.

As pages visibility and functions were tested via web and mobile devices, the database IP information was verified in comparison to the cPanel e-medicals.eu functionalities, such as in figure 2.36.

Figure 2.36 – Verify visitors and check security issues on e-medicals.eu via cPanel

2.1.2. Wireless communication protocol

After the configuration of the CC1101 module, a next step is the decision over the communication protocol such that the data is being correctly receipted on the Raspberry Pi 3 monitoring device site and further pushed on the e-medicals.eu database.

For a secure communication, the built-in state machine used to switch operational states on the CC1101 module is used for verification of the sensors. This ensures avoiding the overflow on the RX state or the IDLE state and verification if the sensor is still on the right RX states. The states are plotted continuously inside a threat.

To continue with, the data has a predefined 9 positions of useful data, including packet length (in our case fixed), biomedical parameters such as bpm, temperature, RR and RS intervals (last 3 parameters in float extension), as well as binary information of the quality of the signal (if EKG too noisy, the RR values are not taken into account by the algorithm).

All values are reconstructed from the hexadecimal format and data received is displayed on the screen and formatting includes 6 positions for the BPM, temperature, RR and RS intervals respectively. The temperature and the RR interval presented in seconds on the Raspberry Pi side have two fields for the precision (float numbers).

To avoid misleading parameters and track the changes, the medical data that is not newly received is switched back to a null state. Therefore, only the real, non-zero parameters are further processed. Figure 2.37 below presents the Raspberry Pi display and an example of received event in the described above format.

Figure 2.37 – Data received on Raspberry Pi 3 via the wireless module

2.1.3. Processing algorithm

The presentation of the biomedical signals in the electronical format is an advantage if referred to the data analysis and therapy, if needed. In the monitoring approach, important information regarding the health of the patient can be extracted from the pulse, EKG and temperature sensor data. The pulse and EKG data is presented in figure 2.38, whereas the BPM detection algorithm (red line) is interrupted during the EKG data collecting.

Figure 2.38 – Biomedical signals visualization on the Arduino device

The signal displayed on the data collecting device is already cleaned by the drift noise caused by breathing or involuntary movement of the patient. Data is therefore preprocessed before the transmission to the Raspberry Pi monitoring device, able to push it further to the e-medicals.eu database, local user webpage or email alerting, if needed. For this, the IP of the Raspberry Pi device has to be fixed inside the network and added on the domain remote access hosts. This is done due to security reasons to avoid undesired access to the medical information. The discussed cPanel interface is illustrated in figure 2.39.

Figure 2.39 – Remote access of Raspberry Pi 3 via e-medicals database for pushing new data

Furthermore, some extra safety regulations are configured on the host side. After this security configuration, the monitoring device is able to push data in real time to the paired patient id. Each device has a predefined user, such that it can automatically make modification inside the database, but only to the paired location.

The alerts are also stored together with the abnormal parameters, date and time, as well as some possible reasons of the outcome: for example, patient movement or not connected temperature device.

An example of database information associated to a specific patient id is shown in figure 2.40 below.

Figure 2.40 – Actualization of data in the e-medicals.eu database

Figure 2.41 – Alert template for e-medicals.eu on mobile devices

If the monitoring device decides to push data inside the alert field, an additional event is being triggered: sending of the email alerts. Templates are provided for both medical and technical staff, each of them being able to proceed further (figure 2.41); the doctor will have access to the online webpage in order to monitor the parameters found, whereas the technical staff can receive some technical details or parameters in order to decide the cause of the event and act accordingly. Some examples of alert messages are presented in figures 2.42 and 2.43.

Figure 2.42 – Alert template for e-medicals.eu on PC

Figure 2.43 – Receiving general alert templates on Gmail from Raspberry Pi 3

Another email sending events are triggered simultaneously to the contact page of the online platform, with information on the parameters detected and possible problem solutions: for example, pulse device problems.

In conclusion, the algorithm on the Raspberry Pi can decide, based on all the information gathered (medical data, presence of noise and RHD detection) where to push the data and what type of alert event should be sent if needed (technical or medical staff email alerts).

Solution description

In this section, a description of the implemented solution is being encapsulated. The solution is based on a real person model, with its own health condition and special requirements. The application takes into account this model when dealing with both implementing and choosing of the materials and technology used.

Furthermore, the interface of both user and doctor/technical staff is centralized on the user needs, such that a constant implementation is integrated in the workflow.

2.3.1. ICF enriched PERSONA

2.3.1.1. General Information

2.3.1.2. Social Network

2.3.1.3. Health

2.3.1.4. Functional Level

2.3.1.5. Daily Schedule

2.3.1.6. User Needs

2.3.2. Use Case, Scenario and Task List

2.3.2.1. Tasklist

2.3.2.2. Task Matrix

2.3.2.3. Use Case & Scenario

For the scenario part, general variables are presented:

BPM

RR interval

RS interval

Temperature

Noise

RHD

Therefore, the application priorities are the following:

Data storage

User data presentation

Doctor/Medical data presentation

Alerts

Interactions with the sensors in this case will be:

Scenarios taken into account:

Scenario 1: Data Collecting Device: collecting pulse signals, temporary storage for filtering before sending – Scenario: Data Storage

Scenario 2: Data Monitoring Device: temporary data storage for user interface, data send to storage on e-medicals.eu database – Scenario: Data Storage

Scenario 3: Data Collecting Device: filtering the EKG signal, continuous track of peaks for BPM algorithm, noise detection by counting local number of peaks, RHD algorithm – Scenario: Data Processing

Scenario 4: Data Monitoring Device: test parameters threshold and noise level – Scenario: Data Processing

Scenario 5: Data Collecting Device: display full acquired signals locally, track peaks in pulse – Scenario: Data Display

Scenario 6: Data Monitoring Device: data locally displayed inside the network and via domain e-medicals.eu – Scenario: Data Display

Definition of scenarios

Scenario 1: Data Collecting Device: collecting pulse signals, temporary storage for filtering before sending – Scenario: Data Storage

EKG signal managed by local filtering;

Storage pulse, EKG and temperature temporary stored before sending to the Monitoring Device for extraction of parameters such as BPM, RR and RS interval

Scenario 2: Data Monitoring Device: data storage temporary for user interface, data send to storage on e-medicals.eu database – Scenario: Data Storage

Interactions with Scenario 1.

Data received is temporary stored in order to be locally presented in the user interface, as well as on the e-medicals.eu platform for the medical staff.

Scenario 3: Data Collecting Device: filtering the EKG signal, continuous track of peaks for BPM algorithm, noise detection by counting locak number of peaks, RHD algorithm – Scenario: Data Processing

EKG signal filtering to remove noise, RR and RS extraction noise detection by tracking number of changes in amplitude;

Pulse signal BPM tracking and extraction.

The body temperature, BPM, RR and RS interval are extracted RHD function is being implemented.

Scenario 4: Data Monitoring Device: test parameters threshold and noise level – Scenario: Data Processing

Interactions with Scenario 3.

Data is being run through a threshold, decision is made whether to alert via email or store the data in different parts of the database.

Scenario 5: Data Collecting Device: display full acquired signals locally, track peaks in pulse – Scenario: Data Display

Track all signals and display pulse, EKG and continuously tracking of BPM.

It has to be highlighted that it’s important to have the visualization of the data on the device side, such that a possible signal problems can be detected on the Arduino or Raspberry Pi.

Scenario 6: Data Monitoring Device: data locally displayed inside the network and via domain e-medicals.eu – Scenario: Data Display

Interactions with Scenario 5.

Data is being locally presented to the user and also on the webpage side.

2.3.2.4. Use Case Overview

Scenario 1: Data Collecting Device: Data Storage

Narrative of Use Case

Brief synthesis

Diagrams of Use Case

Actors

Scenario 2: Data Monitoring Device: Data Storage

Narrative of Use Case

Brief synthesis

Diagrams of Use Case

Actors

Scenario 3: Data Collecting Device: Data Processing

Narrative of Use Case

Brief synthesis

Diagrams of Use Case

Actors

Scenario 4: Data Collecting Device: Data Processing

Narrative of Use Case

Brief synthesis

Diagrams of Use Case

Actors

Scenario 5: Data Collecting Device: Data Display

Narrative of Use Case

Brief synthesis

Diagrams of Use Case

Actors

Scenario 6: Data Monitoring Device: Data Display

Narrative of Use Case

Brief synthesis

Diagrams of Use Case

Actors

2.3.3. User Interface Flow Diagram

The web interface on e-medicals.eu is implemented based on the display cases presented in previous subchapter for both the collecting and the monitoring device. The model has similarities to the user display on the Raspberry Pi side, as well as from the technician display on the Arduino side.

The model includes the first stage authentication, such that the created session is being verified at all included subpages. No parsing through the web subpages can be therefore allowed without performing the main steps.

Further, the user of the online platform can decide whether to go on the medical staff side with personal details and possibility of altering the database information, or to the patient side where data can also be altered in the database concerning associated doctors or illnesses/diagnosis. Figure 2.44 illustrated the flow through the web interface.

Figure 2.44 – User Interface Flow for e-medicals.eu web domain

Results

For this project, the developments of hardware and software components include testing of each of the following scenarios: data collecting, data storage, data display and data monitoring. The testing was performed with main focus on the stability of the platform (web, database and general signal accuracy on the data collecting platform), data communication (database and data transmission) and hardware (versions and final results).

The results of these medical applications include the sub testing parts: data acquisition, data visualization, data storage and transmission.

Data Acquisition from the monitoring device including testing of all sensors: EKG sensors with both filtering and processing parts (accurate signal via mean tracking, algorithms for extraction of RR and RS intervals), pulse sensor with tracking algorithm of the BPM (average) and temperature sensor with values in °C.

Data Visualization of the collected pulse, EKG and temperature sensors is presented via the local network (user solution) or medical staff/technician solution: web application and connected database on e-medicals.eu, as well as the local web application.

The online web application with secure login and session control through the web platform has main focus on parameters, patients, illnesses associated and medical staff, whereas the associated database holds the main parameters and security information for login (session storage). Furthermore, the local web application for the user is designed in order to track the evolution of BPM, temperature and RR interval and contact the medical staff via messages.

Data Storage in designed in direct link with Data Visualization by maintaining the connection with the web interface, whereas the Data Transmission includes both exchange between the Data Collecting and Data Monitoring Device, as well as connection with the database to push the new data.

In this particular case, database holds both alerts and parameters, as well as connectivity information: alerts with unusual or abnormal parameters (email alerting) performed by the algorithm on the Data Monitoring Device with BPM, temperature and EKG information: RR/RS interval, medical staff information and personal login data: sessions information with time, IP and associated user ID.

3.1. Stability of the platform

For the monitoring platform, some approaches were taken into account:

Web platform stability

The platform implemented (figure 3.1) was implemented taking into account both design, accessibility and response, having the presented results. Firstly, according to Google, a good speed of page access is below 2 seconds. In this case, the web platform response of e-medicals.eu is below 1 second, making it approachable for the users. As for the stability of platform, it can hold multiple platform users at a time.

To extend the platform further, security of the platform is held both by IP control of the Raspberry Pi devices, security from provider, user and password, as well as sessions creation.

Figure 3.1 – E-medicals.eu primary page display

For the local user, the implemented platform has a simple design and has good response: real time data display for BPM, temperature and RR intervals if available via graphical evolution of the parameters and normal display of values. Furthermore, the response time is less than 2 seconds and message alert is available for the patient via real time feedback and directly connection to the associated primary doctor email, based on ID.

Figure 3.2 – Local web platform view for the user (initial view)

Figure 3.3 – Local web platform view for the user (data collecting with graph presentation)

Database

The database connectivity was tested both locally (XAMPP) and online (e-medicals.eu), with fast results for both pushing and retrieving data, such that database response is under 2 seconds (higher download than upload speed and data displayed in real time on the e-medicals.eu domain). To continue with the local platform, database response is under 1 second for both pushing and retrieving data, but holds less security needed with local IP.

Figure 3.4 – Database e-medicals.eu with information added from the data monitoring device

Signal Accuracy

For the signal processing, the most important step is verifying the signals. This is performed on different patients, with or without movement from hands and/or breathing of the user and for all the required signals: temperature, pulse and EKG. A closer look-up is needed for the pulse and EKG signals (figure 3.5), such that for pulse, the track is made on the peaks (BPM track algorithm) and for EKG, a local filtering is performed to remove artifacts and noise from breathing/small movements.

Figure 3.5 – Signal presentation from the data collecting device

For EKG signals, an additional test was performed using Lionheart 1 ECG/Arrhythmia Simulator in the particular case of chosen SKINTACT EKG sensors. Results are accurate, such that signal visualization is similar on Biopac systems solution and on Arduino C-solution with the AD 8232 sensors. Without additional noise, sensors performed good results. (figure 3.6)

Figure 3.6 – Simulated signal visualization on the Arduino platform

Data communication issues

Communication connection has some main aspects that were tested, based on transmission protocol or communication to the database.

Transmission protocol and correct retreiving of the biomedical data was tested. For it, protocol was analysed for data collecting device such that Raspberry Pi can interpret the received data in real time and display it locally to the user (specific format of the data and decision whether to display or alert technician/medical staff based on: abnormal parameters thresholding, possible technical errors: nonconnection of sensors).

Figure 3.7 – Local web platform display with information received on the Raspberry Pi data monitoring device

Communication to the database, both locally (XAMPP) and on e-medicals.eu for pushing data from the Raspberry PI was performed such that data can be retrieved in both cases on the web platform and can be further pushed in both situations to the databases. Special requirements for e-medicals.eu include a fixed IP declared on platform and IP secured by the domain provider.

Figure 3.8 – Database information e-medicals.eu with information received on the Raspberry Pi data monitoring device

Overview of the hardware results

To continue with, the monitoring and collecting devices have to integrate all the needed sensors for data acquisition, as well as data transmission.

The monitoring device (figure 3.9) include the following pieces of hardware: the core: the Raspberry Pi holding the algorithms for data receiving, processing and data pushing to the e-medicals.eu database, as well as local display; and the RF modules (CC1101 wireless sensors) for the data receiving (RX).

Figure 3.9 – Hardware connections for the monitoring and data collecting device

The data collecting device presents a series of connections and hardware results. In the initial stage, Arduino Uno and OLIMEX EKG/EMG shield solutions was used. Nevertheless, the results included very noisy and inaccurate results. In final stage, AD8232 Heart Monitor solution and Arduino Feather M0 were used, with accurate results and more compact solution.

Final setup was performed in order to remove wires and possible noises, such that prototype was designed on a stripboard and connections soldered for all sensors and the Arduino part, voltage and GND connections were tested together with the final verifications to ensure same results.

Figure 3.10 – Device prototype connected on patient

Discussion

According to the results presented in the Results chapter, the solution integrates itself among possible medical devices; the prototype created has good performances and specifications that make it an appropriate informatics system to reduce medical costs and time for needed hospital visits. Therefore, some aspects can be stated:

Cost is lower compared to current market solutions for biomonitoring. The value reaches more than 10% of the cheapest solution by using predefined sensors.

Accuracy of signal provided is tracked;

Biocompatibility is achieved, as all sensors are made of biocompatible material: includes testing of reactions during recording.

Power provided to Arduino can be made via 4 AA batteries for supporting the EKG sensors and board (approximately 80 mA); during testing, nevertheless, the solution can be connected to external source such as PC for the visualization of the data on the data collecting side. For a battery at 1.5V, the number of hours per battery would be 16 hours per battery and since the data is collected daily for about 1 hour, the autonomy can range between 1-2 weeks, depending on the usage.

The web interface is also provided and tested via both local platform and online e-medicals.eu platform with good time response (<1.5 seconds).

Database solution tested both locally and online, with necessary connection for pushing or extracting data.

Size of 480 cm3 ranges the solution in between small home solutions (value reaches the first 20% level of the current market solutions in respect to size).

The biomedical device solution is therefore simple to use, appropriate for usage of children. This will furthermore reduce time spent in hospitals, time that can be used simultaneously for watching cartoons or other activities; children can be more relaxed and parents can monitor and assist (parents can assist biomonitoring also outside office hours).

Algorithm for monitoring RHD can be extended, but the temperature and EKG are the main parameters to be monitored for long term. Furthermore, alerting/doctors can decide any time going to hospital for further imaging or biochemical analysis.

Conclusion

In this paper, a biomonitoring device was created, application that was extended on the storage and data management side, as well as security and different alert algorithms and data filtering.

For the database exploration, a study was performed in order to understand the necessity of databases and functions (management based on illness, age, data type, etc.). Without this, it would be hard for a clinical staff to find and visualize the desired information. A study was also performed on existing toolboxes, devices and sensor units for the biomonitoring, as well as solutions for RHD in particular. The RHD was explored in order to find proper detection devices or sensor units, as well as important parameters and ranges for the final algorithm. Moreover, solutions for children were researched during the study part of the project.

Next step was the implementation of the sensorial unit, whereas performing a few preprocessing algorithms. The EKG sensor was used in order to perform the monitoring of the cardiac functions such that the parameters for channel or frequency could be set up in order to achieve a clearer signal. The right sensor was chosen and tested via EKG simulators, including a mean filtering implementation in order to extract a well-defined shape of RR and RS intervals that will be used for RHS detection. Different sensor placement tests were performed in this stage.

The Wireless sensor was connected to Arduino and Raspberry Pi in order to test the data transfer. The Arduino Uno setup pins was made and TX part of the algorithm was tested, including the Raspberry Pi 3 setup, working with the RX part of the transmission protocol. A final protocol was designed for the transmission of the data and understanding of the receiver-transmitter in real time.

Pulse sensor was also implemented in order to find more in-depth information about the cardiac functions; positioning of the sensor was performed in different ways to get a clear signal and BPM extraction algorithm was implanted via peak tracking. Furthermore, the temperature sensor is gathering the remaining biomedical data (body temperature in °C) and correct attachment to the body (feet or hands) is performed.

After the realization of the data collecting device, the sensors data are merged into the biomonitoring algorithm. Data is parsed to the data monitoring device via specific transmission protocol such that each position cover specific data: sensor data (temperature and RR interval as float values, BPM as an integer value), RHD parameters and noise information. Data is being parsed through threshold and decision is being performed in order to alert the medical staff or data storing/visualization. Alerting is done via email and special notation on database and if noise is present, results are annulated. Decision on RHD alerting is performed at this stage, including verification of biomedical parameters such as BPM and temperature and tracking of possible abnormal changes.

The databases and information management is implemented on the Raspberry Pi device side. The login for the web platform is made with secure connection involving the fix IP of the Raspberry Pi device, recognizable in the e-medicals.eu domain and specific user and database associated with website platform and the data monitoring device. Data is parsed inside the local network via the user interface, such that visualization of parameters collected can be performed: BPM, temperature, RR interval.

Tracking of the parameters currently registered is done via a real time plot: BPM and temperature and includes the possibility of alerting via email the associated doctor.

Furthermore, the web platform e-medicals.eu is implemented in association with the database for storing of the biomedical signals (given by the data collecting device). Platform is simple to use and include security parts, such as: user and password verification, sessions for each subpage. The web platform is reachable via any internet network including PC and mobile (IOS and Android availability). Connected pages are giving information in 3 main directions: doctor including personal information and associated patients, patient with associated parameters, Illnesses and other personal doctors and illnesses description respectively. All mentioned data can be altered, such that modification of associated doctors, illnesses (add new ones) and change in personal data, e.g. password can be performed.

Final hardware solution is done by integrating the sensors used in the data acquisition implementation: monitoring device includes a Raspberry Pi 3 and the CC1101 wireless transceiver and the collecting device includes the Arduino Feather M0 and the sensors for pulse, temperature and EKG, as well as data transmission (RF modules). Data is being encapsulated in a single prototype and soldered on a stripboard and final testing is performed.

Future directions of the model can also be discussed for the monitoring device. Together with the realization of a solution for data collecting, the prototype can be subject to new features adding in the sense of extending the illness available information (RHD). This can lead to the standardization of the monitoring devices as a specific solution with features implementation of both user and doctor side.

Moreover, the adding of new data can lead to a better monitoring by merging with other databases: imaging information as a historical data or biochemical results in real time merged with the e-medicals.eu body temperature and cardiac information. Converging can be done also with more specific subpages, such that only RHD parameters are to be tested.

Not least, the data can be extracted for the usage of specific algorithms such that, with the merged medical information, devices performances can be increased.

Table of Abbreviations

Table of Figures

Figure 1.1 – Ionic channel: General View 3

Figure 1.2 – Heart structure 4

Figure 1.3 – Electrical activity of heart 4

Figure 1.4 – EKG: QRS complex 5

Figure 1.5 – Samsung Monitoring Solution: Hardware View 6

Figure 1.6 – Commercial Monitoring Devices 7

Figure 1.7 – Case Study: Percentage of RHD patients in India 8

Figure 1.8 – Case Study: Global and Asian cases of RF and RHD 9

Figure 1.9 – Case Study: RHD in Australia, Northern Territory 9

Figure 1.10 – Mechanism of RHD 10

Figure 1.11 – a) Hematoxylin and eosin stain of RHD b) Culture of streptococcal in 16 years old2 12

Figure 1.12 – Case Study: Changes following reviews from AHA and WHO 13

Figure 1.13 – Search into the ECG Web Database 16

Figure 1.14 – EKG Analysis from ECG Web Database14 16

Figure 1.15 – NORAV ECG Management System Interface 18

Figure 2.1 – Presentation of Hardware for the biomonitoring device 20

Figure 2.2 – Arduino implementation as biomonitoring device 21

Figure 2.3 – Raspberry Pi implementation as data management device 21

Figure 2.4 a) EKG/EMG sensors b) EKG/EMG Olimex shield 22

Figure 2.5 – Connections available on OLIMEX EKG/EMG shield 22

Figure 2.6 – Arduino Feather M0 23

Figure 2.7 – AD8232 Heart Monitor solution 23

Figure 2.8 – Functional block diagram for AD8232 EKG sensor24 25

Figure 2.9 – EKG: different sensor connections3 25

Figure 2.10 – Lionheart 1 ECG/Arrhythmia Simulator and connections to AD8232 and Arduino Feather M0 26

Figure 2.11 – SKINTACT Monitoring EKG Electrodes 26

Figure 2.12 – Pulse Sensor 27

Figure 2.13 – a) Absorption spectra of Hb and HbO2 b) the systolic and diastolic phase 27

Figure 2.14 – Sensor parts and connections of the Pulse Sensor 28

Figure 2.15 – R-R and N-N interval for the pulse sensor signal registration 28

Figure 2.16 – DS18B20 Digital temperature sensor 29

Figure 2.17 – The CC1101 Wireless module (RF1100SE) with pins available 30

Figure 2.18 – Arduino Connections Example to CC1101 30

Figure 2.19 – Register settings for CC1101 module inside SmartRF Studio 31

Figure 2.20 – Pulse signal (green) and IBI tracking for the BPM extraction algorithm (red) 32

Figure 2.21 – Different motion and baseline wander noise on the EKG signal during acquisition via AS8232 Monitoring sensors 33

Figure 2.22 – a) filtered EKG signal b) noisy EKG signal 34

Figure 2.23 – Results for the PR and RR interval (ms) during the EKG data acquisition of the AD8232 module 34

Figure 2.24 – Main steps in implementation of the two online platforms 35

Figure 2.25 – XAMPP Control Panel for Database/Web Testing 36

Figure 2.26 – cPanel of domain e-medicals.eu 36

Figure 2.27 – FTP file for connection e-medicals.eu 37

Figure 2.28 – Web files transfer to online domain e-medicals.eu 37

Figure 2.29 – Data presentation on e-medicals.eu 38

Figure 2.30 – Database structure e-medicals.eu 38

Figure 2.31 – View on IOS for e-medicals.eu 39

Figure 2.32 – Login on e-medicals.eu via Android device 40

Figure 2.33 – Contact and personal page presentation on e-medicals.eu 41

Figure 2.34 – Details about patients and illness on e-medicals.eu 41

Figure 2.35 – Adding new information in database via e-medicals.eu 42

Figure 2.36 – Verify visitors and check security issues on e-medicals.eu via cPanel 42

Figure 2.37 – Data received on Raspberry Pi 3 via the wireless module 43

Figure 2.38 – Biomedical signals visualization on the Arduino device 44

Figure 2.39 – Remote access of Raspberry Pi 3 via e-medicals database for pushing new data 45

Figure 2.40 – Actualization of data in the e-medicals.eu database 45

Figure 2.41 – Alert template for e-medicals.eu on mobile devices 46

Figure 2.42 – Alert template for e-medicals.eu on PC 46

Figure 2.43 – Receiving general alert templates on Gmail from Raspberry Pi 3 47

Figure 2.44 – User Interface Flow for e-medicals.eu web domain 59

Figure 3.1 – E-medicals.eu primary page display 61

Figure 3.2 – Local web platform view for the user (initial view) 62

Figure 3.3 – Local web platform view for the user (data collecting with graph presentation) 62

Figure 3.4 – Database e-medicals.eu with information added from the data monitoring device 63

Figure 3.5 – Signal presentation from the data collecting device 63

Figure 3.6 – Simulated signal visualization on the Arduino platform 64

Figure 3.7 – Local web platform display with information received on the Raspberry Pi data monitoring device 65

Figure 3.8 – Database information e-medicals.eu with information received on the Raspberry Pi data monitoring device 65

Figure 3.9 – Hardware connections for the monitoring and data collecting device 66

Figure 3.10 – Device prototype connected on patient 66

Table of Tables

Table 1.1 – Database review for EKG 17

Table 2.1 – Pin connections between Arduino and AD8232 Heart Monitoring 24

Table 2.2 – Pin function description for AD8232 Heart Monitoring Sensor 24

Table 2.3 – Pin Connections for Arduino Uno and Raspberry Pi 3 with the CC1101 module 31

Table 2.4 – Pulse Sensor connection to the Arduino Feather M0 32

[1] G. Villarrubia, J. Bajo, J. F. De Paz, and J. M. Corchado, “Monitoring and Detection Platform to Prevent Anomalous Situations in Home Care,” Sensors, vol. 14, no. 6, pp. 9900–9921, Jun. 2014.

[2] R.Kumar, Dr.M.Pallikonda Rajasekaran, "Raspberry Pi based patient health status observing methhod using internet of things", International Conference on Current Research in Engineering Science and Technology (ICCREST 2016)

[3] JeongGil Ko, Chenyang Lu, Mani B. Srivastava, John A. Stankovic, "Wireless Sensor Networks for Healthcare" [Online]. Available: https://vs.inf.ethz.ch/edu/HS2011/CPS/papers/ko10_wsn-for-healthcare.pdf. [Accessed: 09-Feb-2017].

[4] Pervez Khan, Md.Asdaque Hussain, "Medical Applications of Wireless Body Area Networks", International Journal of Digital Content Technology and its Applications, Volume 3, Number 3, September 2009 [Online]. Available: https://pdfs.semanticscholar.org/910f/599baed6b62d596ad901220153b4f003eba0.pdf. [Accessed: 09-Feb-2017].

[5] “Monitoring (Medicine) | Wireless Sensor Network.” [Online]. Available: https://www.scribd.com/document/336875050/10-1-1-590-6006-pdf. [Accessed: 09-Feb-2017].

[6] M. M., Bioelectromagnetism, 2000th ed. Matrixrom.

[7] “Canal ionic,” Wikipedia. 19-Feb-2016.

[8] “Anatomical plane,” Wikipedia. 17-Oct-2016.

[9] M. B. Conover, Understanding Electrocardiography. Elsevier Health Sciences, 2003.

[10] “Heart Valve Bank ~ Congenital Heart Disease.” [Online]. Available: http://www.heartvalvebank.info/heartvalves-chd.html. [Accessed: 26-Nov-2016].

[11] “Meditech Group: ECG machine,Ultrasound Scanner,Patient Monitor,Fetal Doppler,Pulse Oximeter,Fetal monitor,Spirometer,Defibrillator,Visual Stethoscope,ECG Holter and home health care products.” [Online]. Available: http://www.meditech.com.cn/. [Accessed: 26-Nov-2016].

[12] “QRS complex,” Wikipedia. 17-Nov-2016.

[13] “Simulink Model for Fetal ECG Extraction » File Exchange Pick of the Week.” [Online]. Available: http://blogs.mathworks.com/pick/2012/06/22/simulink-model-for-fetal-ecg-extraction/?s_tid=srchtitle. [Accessed: 26-Nov-2016].

[14] C. Ravariu, “Contributions to Novel Methods in Electrophysiology Aided by Electronic Devices and Circuits,” 2011.

[15] “Electroencephalography,” Wikipedia. 12-Nov-2016.

[16] R. Ferrari, A. I. C. Arce, M. P. de Melo, and E. J. X. Costa, “Noninvasive method to assess the electrical brain activity from rats,” Ciênc. Rural, vol. 43, no. 10, pp. 1838–1842, Oct. 2013.

[17] “Magnetic resonance imaging – Wikipedia.” [Online]. Available: https://en.wikipedia.org/wiki/Magnetic_resonance_imaging. [Accessed: 26-Nov-2016].

[18] “SAMSUNG BIO-PROCESSOR FOR HEALTH MONITORING” [Online]. Available: http://www.samsung.com/us/samsungsemiconductor/pdfs/health-monitoring-whitepaper.pdf. [Accessed: 04-Jun-2017].

[19] “Wearable wireless health sensor for remote bio-monitoring.” [Online]. Available: http://newatlas.com/health-monitoring-system-japan/14047/. [Accessed: 04-Jun-2017].

[20] “10 Wearable Health Tech Devices To Watch,” InformationWeek. [Online]. Available: http://www.informationweek.com/healthcare/mobile-wireless/10-wearable-health-tech-devices-to-watch/240012613. [Accessed: 04-Jun-2017].

[21] “Rheumatic Heart Disease | Conditions & Treatments | UCSF Benioff Children’s Hospital.” [Online]. Available: https://www.ucsfbenioffchildrens.org/conditions/rheumatic_heart_disease/. [Accessed: 14-Jan-2017].

[22] “Spotlight on Rheumatic Heart Disease: A Cardiothoracic Surgeon’s Perspective,” Rheumatology Advisor, 22-Nov-2016. [Online]. Available: http://www.rheumatologyadvisor.com/rheumatoid-arthritis/a-cardiothoracic-surgeons-perspective-on-rheumatic-heart-disease/article/574719/. [Accessed: 14-Jan-2017].

[23] “Rheumatic heart disease,” Heart and Stroke Foundation of Canada. [Online]. Available: https://www.heartandstroke.ca:443/heart/conditions/rheumatic-heart-disease. [Accessed: 14-Jan-2017].

[24] “Rheumatic Heart Disease | World Heart Federation.” [Online]. Available: http://www.world-heart-federation.org/press/fact-sheets/rheumatic-heart-disease/. [Accessed: 14-Jan-2017].

[25] R. K. Kumar and R. Tandon, “Rheumatic fever & rheumatic heart disease: The last 50 years,” Indian J. Med. Res., vol. 137, no. 4, pp. 643–658, Apr. 2013.

[26] “Reumatism articular acut (RAA) – simptome, diagnostic, tratament,” CSID.ro. [Online]. Available: http://www.csid.ro/boli-afectiuni/reumatologie/reumatismul-articular-acut-12816705/. [Accessed: 04-Jun-2017].

[27] “Reumatismul articular acut: aspecte clinice si terapeutice – EMCB.” [Online]. Available: https://www.emcb.ro/article.php?story=20080801122423813. [Accessed: 04-Jun-2017].

[28] T. C. H. of Philadelphia, “Rheumatic Fever and Rheumatic Heart Disease,” 25-Mar-2014. [Online]. Available: http://www.chop.edu/conditions-diseases/rheumatic-fever-and-rheumatic-heart-disease. [Accessed: 14-Jan-2017].

[29] “Symptoms and causes – Rheumatic fever – Mayo Clinic.” [Online]. Available: http://www.mayoclinic.org/diseases-conditions/rheumatic-fever/symptoms-causes/dxc-20261256. [Accessed: 14-Jan-2017].

[30] “Rheumatic Fever: Causes, Treatment, & Prevention.” [Online]. Available: http://www.healthline.com/health/rheumatic-fever#Diagnosis4. [Accessed: 14-Jan-2017].

[31] “How is it diagnosed and managed?,” Rheumatic Heart Disease Australia, 23-Dec-2015. [Online]. Available: https://www.rhdaustralia.org.au/how-it-diagnosed-and-managed. [Accessed: 14-Jan-2017].

[32] “Rheumatic Heart Disease | Seattle Children’s Hospital.” [Online]. Available: http://www.seattlechildrens.org/medical-conditions/heart-blood-conditions/rheumatic-heart-disease/. [Accessed: 14-Jan-2017].

[33] “Rheumatic fever – Diagnosis – NHS Choices.” [Online]. Available: http://www.nhs.uk/Conditions/Rheumatic-fever/Pages/Diagnosis.aspx. [Accessed: 14-Jan-2017].

[34] “Pathology of Rheumatic Heart Disease: Overview, Etiology and Pathophysiology, Clinical Features.” [Online]. Available: http://emedicine.medscape.com/article/1962779-overview#a6. [Accessed: 14-Jan-2017].

[35] “PhysioNet: a research resource for studies of complex physiologic and biomedical signals.” [Online]. Available: https://www.researchgate.net/publication/6750526_PhysioNet_a_research_resource_for_studies_of_complex_physiologic_and_biomedical_signals. [Accessed: 26-Nov-2016].

[36] G. B. Moody, R. G. Mark, and A. L. Goldberger, “PhysioNet: a Web-based resource for the study of physiologic signals,” IEEE Eng. Med. Biol. Mag., vol. 20, no. 3, pp. 70–75, May 2001.

[37] I. C. Henry, A. L. Goldberger, G. B. Moody, and R. G. Mark, “PhysioNet: an NIH research resource for physiologic datasets and open-source software,” 2001, pp. 245–250.

[38] “Introduction of Computational Models to PhysioNet,” PubMed Journals. [Online]. Available: https://ncbi.nlm.nih.gov/labs/articles/14640090/. [Accessed: 26-Nov-2016].

[39] G. B. Moody, R. G. Mark, and A. L. Goldberger, “PhysioNet: Physiologic signals, time series and related open source software for basic, clinical, and applied research,” in 2011 Annual International Conference of the IEEE Engineering in Medicine and Biology Society, 2011, pp. 8327–8330.

[40] I. K. Kim, J. F. Winchester, A. Alaoui, S. K. Mun, and W. K. Choi, “A Multimedia Medical Database Component for a Dialysis Telemedicine Application,” in Proceedings of the Symposium on Pacific Medical Technology, Washington, DC, USA, 1998, p. 428–.

[41] P. Tirilly, K. Lu, X. Mu, T. Zhao, and Y. Cao, “On modality classification and its use in text-based image retrieval in medical databases,” in 2011 9th International Workshop on Content-Based Multimedia Indexing (CBMI), 2011, pp. 109–114.

[42] H. I. Wang, “The preliminary survey for the design of multipurpose medical databases for Taiwan – The usage oriented approach,” in 2011 Eighth International Conference on Fuzzy Systems and Knowledge Discovery (FSKD), 2011, vol. 4, pp. 2632–2636.

[43] M. G, L.-M. M, P. A, P. G, M. Jl, and S. L, “French health insurance databases: What interest for medical research?,” Rev. Med. Interne, vol. 36, no. 6, pp. 411–417, 2015 2015.

[44] “Economic Measurement of Medical Errors Using a Hospital Claims Database.” [Online]. Available: http://www.sciencedirect.com/science/article/pii/S1098301512042660. [Accessed: 26-Nov-2016].

[45] Y. An, R. Khare, X. Hu, and I. Y. Song, “Bridging encounter forms and electronic medical record databases: Annotation, mapping, and integration,” in 2012 IEEE International Conference on Bioinformatics and Biomedicine, 2012, pp. 1–4.

[46] “Image data model for an efficient multi-criteria query: a case in medical databases – IEEE Xplore Document.” [Online]. Available: http://ieeexplore.ieee.org/document/1029717/. [Accessed: 26-Nov-2016].

[47] A. Mojsilovic and J. Gomes, “Semantic based categorization, browsing and retrieval in medical image databases,” in Proceedings. International Conference on Image Processing, 2002, vol. 3, p. III-145-III-148 vol.3.

[48] A. Kak and C. Pavlopoulou, “Content-based image retrieval from large medical databases,” in First International Symposium on 3D Data Processing Visualization and Transmission Proceedings, 2002, pp. 138–147.

[49] I. D. Falco, “A Differential Evolution-Based System Supporting Medical Diagnosis through Automatic Knowledge Extraction from Databases,” in 2011 IEEE International Conference on Bioinformatics and Biomedicine, 2011, pp. 321–326.

[50] E. Marcos, C. J. Acuña, B. Vela, J. M. Cavero, and J. A. Hernández, “A Database for Medical Image Management,” Comput Methods Prog Biomed, vol. 86, no. 3, pp. 255–269, Jun. 2007.

[51] M. L. Wong, W. Lam, J. C. Y. Cheng, and K. S. Leung, “Discovering knowledge from medical databases using evolutionary algorithms,” in IEEE Engineering in Medicine and Biology Magazine, 2000, pp. 45–55.

[52] S. ZahidHassan and B. Verma, “A Hybrid Data Mining Approach for Knowledge Extraction and Classification in Medical Databases,” in Seventh International Conference on Intelligent Systems Design and Applications (ISDA 2007), 2007, pp. 503–510.

[53] K. Zuhtuogullari and N. Allahverdi, “An improved itemset generation approach for mining medical databases,” in 2011 International Symposium on Innovations in Intelligent Systems and Applications, 2011, pp. 39–43.

[54] S. Tsumoto, “Temporal knowledge discovery in time-series medical databases based on fuzzy-rough reasoning,” in Proceedings Joint 9th IFSA World Congress and 20th NAFIPS International Conference (Cat. No. 01TH8569), 2001, vol. 4, pp. 1973–1978 vol.4.

[55] E. German, A. Leibowitz, and Y. Shahar, “An Architecture for Linking Medical Decision-support Applications to Clinical Databases and Its Evaluation,” J Biomed. Inform., vol. 42, no. 2, pp. 203–218, Apr. 2009.

[56] K. Kerdprasop and N. Kerdprasop, “SUT-Miner: A Knowledge Mining and Managing System for Medical Databases,” in 2009 20th International Workshop on Database and Expert Systems Application, 2009, pp. 318–322.

[57] L. Burlibasa, R. Irina, and G. Lucian, Introducere in Genomica, 2013th ed. MatrixROM Bucuresti.

[58] “Sequencing | Sequencing Methods.” [Online]. Available: http://www.illumina.com/techniques/sequencing.html. [Accessed: 27-Nov-2016].

[59] “Zenon Bio Kft.: segítünk lépést tartani laborja változó igényeivel.” [Online]. Available: http://www.zenonbio.hu/index.html. [Accessed: 27-Nov-2016].

[60] J. Franco Contreras, G. Coatrieux, E. Chazard, F. Cuppens, N. Cuppens-Boulahia, and C. Roux, “Robust lossless watermarking based on circular interpretation of bijective transformations for the protection of medical databases,” Conf. Proc. Annu. Int. Conf. IEEE Eng. Med. Biol. Soc. IEEE Eng. Med. Biol. Soc. Annu. Conf., vol. 2012, pp. 5875–5878, 2012.

[61] Olimex, “SHIELD-EKG-EMG – Open Source Hardware Board,” Olimex. [Online]. Available: https://www.olimex.com/Products/Duino/Shields/SHIELD-EKG-EMG/. [Accessed: 21-Jan-2017].

[62] “Pulsoximetria in practica medicala.” [Online]. Available: http://www.slideshare.net/tmihaescu/pulsoximetria-in-practica-medicala. [Accessed: 21-Jan-2017].

[63] “Pulse Oximetry Notes” [Online]. Available: http://www.robots.ox.ac.uk/~neil/teaching/lectures/med_elec/notes6.pdf. [Accessed: 21-Jan-2017].

[64] “LED Pulse Sensor (PPG) for Arduino,” Instructables.com. [Online]. Available: http://www.instructables.com/id/LED-Pulse-Sensor-PPG-for-Arduino/. [Accessed: 21-Jan-2017].

[65] F. C. J. González, O. O. V. Villegas, D. E. T. Ramírez, V. G. C. Sánchez, and H. O. Domínguez, “Smart Multi-Level Tool for Remote Patient Monitoring Based on a Wireless Sensor Network and Mobile Augmented Reality,” Sensors, vol. 14, no. 9, pp. 17212–17234, Sep. 2014.

[66] “Arduino – One Wire Digital Temperature Sensor – DS18B20.” [Online]. Available: http://www.hobbytronics.co.uk/ds18b20-arduino. [Accessed: 09-May-2017].

[67] “Waterproof DS18B20 Digital temperature sensor + extras ID: 381 – $9.95 : Adafruit Industries, Unique & fun DIY electronics and kits.” [Online]. Available: https://www.adafruit.com/product/381. [Accessed: 09-May-2017].

STATUTORY DECLARATION

I hereby declare that

the Master thesis has been written by myself without any external unauthorized help and that it has not been submitted to any institution to achieve an academic grading;

I have not used sources or means without citing them in the text; any thoughts from others or literal quotations are clearly marked;

the electronically submitted Master thesis is identical to the hard copy;

one copy of the Master Thesis is deposited and made available in the CUAS library (§ 8 Austrian Copyright Law [UrhG]).