IN DEGREE PROJECT MEDICAL ENGINEERING, SECOND CYCLE, 30 CREDITS

, STOCKHOLM SWEDEN 2016

Development of a Flexible Software Framework for Biosignal PI

AN OPEN-SOURCE BIOSIGNAL ACQUISITION AND PROCESSING SYSTEM

MARTIN RÖSTIN

KTH ROYAL INSTITUTE OF TECHNOLOGYSCHOOL OF TECHNOLOGY AND HEALTH

Development of a Flexible Software Frameworkfor Biosignal PI,

An Open-Source Biosignal Acquisition and Processing System

Utveckling av ett Flexibelt Mjukvaruramverkför Biosignal PI,

ett system för insamling och bearbetning av biomedicinskasignaler med öppen källkod

Martin Röstin

Master of Science Thesis in Medical EngineeringAdvanced level (second cycle), 30 credits

Supervisor at KTH: Farhad AbtahiExaminer: Mats Nilsson

School of Technology and HealthTRITA-STH, EX 2016:10

Royal Institute of TechnologyKTH STH

SE-141 86 Flemingsberg, Swedenhttp://www.kth.se/sth

AbstractAs the world population ages, the healthcare system is facing new challenges in treating morepatients at a lower cost than today. One trend in addressing this problem is to increasethe opportunities of in-home care. To achieve this there is a need for safe and cost-effectivemonitoring systems. Biosignal PI is an ongoing open-source project created to develop aflexible and affordable platform for development of stand-alone devices able to measure andprocess physiological signals.

This master thesis project, performed at the department of Medical Sensors, Signals andSystem at the School of Technology and Health, aimed at further develop the Biosignal PIsoftware by constructing a new flexible software framework architecture that could be usedfor measurement and processing of different types of biosignals. The project also aimed atimplementing features for Heart Rate Variability(HRV) Analysis in the Biosignal PI softwareas well as developing a graphical user interface(GUI) for the Raspberry PI hardware modulePiFace Control and Display.

The project developed a new flexible abstract software framework for the Biosignal PI. Thenew framework was constructed to abstract all hardware specifics into smaller interchangeablemodules, with the idea of the modules being independent in handling their specific task makingit possible to make changes in the Biosignal PI software without having to rewrite all ofthe core. The new developed Biosignal PI software framework was implemented into theexisting hardware setup consisting of an Raspberry PI, a small and affordable single-boardcomputer, connected to ADAS1000, a low power analog front end capable of recording anElectrocardiography(ECG).

To control the Biosignal PI software two different GUIs were implemented. One GUI extendingthe original software GUI with the added feature of making it able to perform HRV-Analysis onthe Raspberry PI. This GUI requires a mouse and computer screen to function. To be able tocontrol the Biosignal PI without mouse the project also created a GUI for the PiFace Controland Display. The PiFace GUI enables the user to collect and store ECG signals without theneed of an big computer screen, increasing the mobility of the Biosignal PI device.

To help with the development process and also to make the project more compliant with theMedical Device Directive a couple of development tools were implemented such as a CMakebuild system, integrating the project with the Googletest testing framework for automatedtesting and the implementation of the document generator software Doxygen to be able tocreate an Software Documentation.

Keywords: Biosignal PI, Software Framework, Raspberry PI, PiFace Control and Display,Electrocardiography(ECG), Heart Rate Variability(HRV), Open-Source, Medical Device De-velopment, Medical Device Software

i

SammanfattningAllt eftersom världens befolkning åldras, ställs sjukvården inför nya utmaningar i att behandlafler patienter till en lägre kostnad än idag. En trend för att lösa detta problem är att utökamöjligheterna till vård i hemmet. För att kunna göra detta finns det ett ökande behov av säkraoch kostnadseffektiva patientövervakningssystem. Biosignal PI är ett pågående projekt medöppen källkod som skapats för att utveckla en flexibel och prisvärd plattform för utvecklingav fristående enheter som kan mäta och bearbeta olika fysiologiska signaler.

Detta examensarbete genomfördes vid institutionen för medicinska sensorer, signaler och sys-tem vid Skolan för Teknik och Hälsa. Projektet syftade till att vidareutveckla den befintligamjukvaran för Biosignal PI genom att skapa ett nytt flexibelt mjukvaruramverk som kan an-vändas för mätning och bearbetning av olika typer av biosignaler. Projektet syftade ocksåtill att utvidga mjukvaran och lägga till funktioner för att kunna genomföra hjärtfrekvensvari-abilitets(HRV) analys i Biosignal PIs mjukvara, samt att utveckla ett grafiskt användargränss-nitt(GUI) för hårdvarumodulen PiFace Control and Display.

Projektet har skapat ett nytt flexibelt mjukvaruramverk för Biosignal PI. Det nya ramverketkonstruerades för att abstrahera alla hårdvaruspecifika delar in i mindre utbytbara moduler,med tanken att modulerna ska vara oberoende i hur de hanterar sin specifika uppgift. Påså sätt ska det vara möjligt att göra ändringar i Biosignal PIs programvara utan att behövaskriva om hela mjukvaran. Det nyutvecklade Biosignal PI ramverket implementerades i detbefintliga hårdvaru systemet, som består av en Raspberry PI, liten och prisvärd enkortsdator,ansluten till ADAS1000, en analog hårdvarumodul med möjlighet att registrera ett elektrokar-diografi(EKG/ECG).

För att kontrollera Biosignal PI programmet har två olika grafiska användargränssnitt skapats.Det ena gränssnitt är en utvidgning av original programvaran med tillagd funktionalitet föratt kunna göra HRV-Analys på Raspberry PI, detta gränssnitt kräver dock mus och dataskärmför att kunna användas. För att kunna styra Biosignal PI utan mus och skärm skapades detäven ett gränssnitt för PiFace Control and Display. PiFace gränssnittet gör det möjligt föranvändaren att samla in och lagra EKG-signaler utan att behöva en stor datorskärm, på såsätt kan man öka Biosignal PI systemets mobilitet.

För att underlätta utvecklingsprocessen, samt göra projektet mer förenligt med det medicin-tekniska regelverket, har ett par utvecklingsverktyg integrerats till Biosignal PI projektet såsomCMake för kontroll av kompileringsprocessen, test ramverket Googletest för automatiseradtestning samt integrering med dokumentations generatorn Doxygen för att kunna skapa endokumentation av mjukvaran.

Nyckelord: Biosignal PI, Software Framework, Raspberry PI, PiFace Control and Display,Electrocardiography(ECG), Heart Rate Variability(HRV), open-source, Medical device devel-opment, Medical Device Software

iii

AcknowledgementsFirst and foremost I would like to thank my supervisor Farhad Abtahi for giving me theopportunity to work on this project. I am also thankful for your invaluable support andfeedback throughout the project.

I would also like to thank Anna Larsson, Cecilia Löwgren and Stefano Zappalà for your helpfulfeedback and discussions during our meetings.

Last, but not least, I would like to thank my family for your constant love and support.

Martin RöstinStockholm, January 2016

v

Contents

List of Figures ix

List of Tables ix

Nomenclature xi

1 Introduction 11.1 Background . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.2 Objective . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.3 Outline . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

2 Method 32.1 Biosignal PI Framework . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2.1.1 Software Requirements and Specifications . . . . . . . . . . . . . . . . . 32.1.2 Developing Methodology . . . . . . . . . . . . . . . . . . . . . . . . . . . 42.1.3 Design Patterns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42.1.4 Cross-compilation and Implementing a Build System . . . . . . . . . . . 52.1.5 Software Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2.2 Heart Rate Variability Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . 62.2.1 QRS-Detection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62.2.2 Converting MATLAB Code into C++ Code . . . . . . . . . . . . . . . . 7

2.3 Bluetooth . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92.4 Using PiFace Control and Display . . . . . . . . . . . . . . . . . . . . . . . . . . 92.5 Documenting the Created Software . . . . . . . . . . . . . . . . . . . . . . . . . 9

3 Results 113.1 Biosignal PI Framework . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

3.1.1 Device Facade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113.1.2 Data Model and Logging . . . . . . . . . . . . . . . . . . . . . . . . . . . 113.1.3 Application Wide Settings . . . . . . . . . . . . . . . . . . . . . . . . . . 123.1.4 CMake integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123.1.5 Automated Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

3.2 Heart Rate Variability Analysis Widget . . . . . . . . . . . . . . . . . . . . . . 133.3 Bluetooth Transfer Widget . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133.4 PiFace Graphical User Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . 133.5 Software Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

vii

4 Discussion 194.1 Biosignal PI Framework and software . . . . . . . . . . . . . . . . . . . . . . . . 194.2 Biosignal PI as a Medical Device . . . . . . . . . . . . . . . . . . . . . . . . . . 20

5 Conclusion 21

6 Future Work 23

Bibliography 25

Appendix A Literature Study 29

viii

List of Figures

2.1 Workflow for the development sprints . . . . . . . . . . . . . . . . . . . . . . . . 52.2 QRS-Detection, From ECG-File to IBI-file . . . . . . . . . . . . . . . . . . . . . 62.3 Flowchart transforming MATLAB code to C++ . . . . . . . . . . . . . . . . . . 82.4 RPI with connected PiFace, PiRack and ADAS . . . . . . . . . . . . . . . . . . 10

3.1 Biosignal PI Framework Architecture . . . . . . . . . . . . . . . . . . . . . . . . 123.2 Flowchart describing the HRV-Process . . . . . . . . . . . . . . . . . . . . . . . 143.3 Screenshot HrvWidget . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153.4 Screenshot Bluetooth Transfer Widget . . . . . . . . . . . . . . . . . . . . . . . 163.5 PiFace CAD with numbered switches . . . . . . . . . . . . . . . . . . . . . . . . 163.6 Screenshot Biosignal PI documentation Homepage . . . . . . . . . . . . . . . . 173.7 Screenshot BioSignal PI Documentation DeviceManager Class . . . . . . . . . . 18

A.1 Illustration of typical ECG trace . . . . . . . . . . . . . . . . . . . . . . . . . . 30A.2 Raspberry PI 2 model B . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33A.3 PiFace Control and Display . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

List of Tables

A.1 Metrics for Time-Domain Analysis of HRV[22] . . . . . . . . . . . . . . . . . . . 31A.2 Metrics for Frequency-Domain Analysis of HRV[22] . . . . . . . . . . . . . . . . 31

ix

Nomenclature

ADAS Analog to Digital converter used for capturing biosignalsANS Autonomous Nervous SystemECG ElectroCardioGraphyGPIO General- Purpose Input/OutputGUI Graphical User InterfaceHR Heart RateHRV Heart Rate VariabilityIBI Inter Beat IntervalMDD Medical Device DirectiveOSS Open Source SoftwareQT C++ software frameworkRPI Raspberry PISCM Source Control Management Software

xi

Chapter 1

Introduction

1.1 Background

Healthcare is facing new challenges as the world population ages. According to the UN theproportion of people over 60 years in the world are projected to double over the next halfcentury from 10% (2000) to 21% (2050)[1]. This aging will increase the spread of a wide rangeof non-communicable diseases such as heart-diseases, cancer, stroke and diabetes, while theproportion of working people per person older than 65 years is projected to be halved over thenext 50 years. This forces the future healthcare to treat more patients while the cost needs tobe lowered.[2]

To address these problems, there is a trend to increase the opportunities for in-home care.An important step in providing effective home care is the availability of safe and cost-effectivemonitoring systems. Through the use of devices that can detect different biomedical signals,for example Electrocardiography(ECG), patients can be monitored from home without havingto travel to the hospital as often. Studies conducted on patients with chronic conditions haveshown that homecare systems can help patients to better handle their diseases[3], [4].

Biosignal PI is an on-going open source project that was started to create a flexible and afford-able platform for development of standalone devices for measurement of different biomedicalsignals. This thesis will be a continuation of the existing software created in a previous project.The earlier developed software was designed to run on the Raspberry PI which is a small andaffordable computer. This framework is primarily intended for research and educational use.To allow for changes based on the needs of a specific project, the framework aims at beingmodular with interchangeable parts.[5]

1

2 Chapter 1. Introduction

1.2 Objective

The main objective of this project was to create a modular software framework architecture.To test this new Biosignal PI framework new features was added to the Biosignal PI software.In order to achieve this the objective was divided into four objectives.

• A modular software framework with equal functionality as original software for BiosignalPI

• Software with Heart Rate Variability analysis and Bluetooth functions implemented

• A Graphical User Interface for the hardware module PiFace Control and Display, makingit possible to run the Biosignal PI without mouse, keyboard and computer monitor.

• Written documentation regarding the software design

1.3 Outline

A theoretical background to most of the concepts used in this thesis can be found in theLiterature Study in Appendix A. Chapter 2 Methodology contains a description of the differentmethods used and how they have been used in the project. Chapter 3 Results describes theproduced software and Chapter 4 Discussion covers a discussion of the different parts of boththe produced framework and the Biosignal PI software as a whole. The Discussion also covers apart about how the Biosignal PI software complies with the Medical Device Directive regulatingwhat is required for medical software.

Chapter 2

Method

The method chapter will cover a summary of how the different parts of the Biosignal PIsoftware has been developed and the underlying process concerning the development of thedifferent parts. More information about software development in general and an introductionto the different software and methods used can be found in section A.3 of the Literature Studyin Appendix A.

2.1 Biosignal PI Framework

The main task of this project concerns modifications of the original software for the Biosig-nal PI in order of improving the modularity, interchangeability and ease of deployment forthe software. The modularity and interchangeability was improved through the creation ofa new Architectural Software Framework. The ease of deployment was simplified throughimplementation of a build system.

2.1.1 Software Requirements and Specifications

In the beginning of the project the original Biosignal PI software was analyzed to determinehow the original software worked and also to establish a specification on what sort of require-ments the new framework would have to satisfy. The old GUI was found sufficient and the newimplementations could build upon the existing core GUI. The specification were divided intogeneral and functional requirements. The general requirements were important for developingsoftware in general and Medical Device Software and the requirements set by the SoftwareDevelopment Life Cycle. For more information regarding Medical Device Software see sectionA.4 of the Literature Study in Appendix A. The general requirements were.

• Interchangeable

• Extendable

• Hardware independence

• Ease of Deployment

3

4 Chapter 2. Method

• Testable classes, dependency reduction

• Open-Source solutions

• Understandable code

The functional requirements were more target for the needs of this specific project with regardstaken to the requirements specifications from the old Biosignal PI software[6]. The functionalrequirements for the Biosignal PI framework were.

• Capture physiological data/signal from an attached device

• Store captured data to file

• Visualize sampled data in real time and from file

• Process physiological data

2.1.2 Developing Methodology

After creating the requirements list for the framework, a small skeleton was developed withminimal functionality to act as the backbone for further developments. After completing themain skeleton framework and implementation of the build system mentioned in section 2.1.4,the development of the whole framework was divided into shorter sprints with a concrete re-quirement list stating what the sprint should implement into the main skeleton. To help withmanaging the development process the project used Git and Github for source code manage-ment and task tracking. For every new sprint a list of requirements and a new developmentbranch was created in Git. When the sprint was finished and the developed software had beencompiled and tested the current development branch was merged into the main branch. Aftercompletion of a sprint a new sprint was planned from the remaining list of things needed toimplement. An illustration of the workflow for the software development can be seen in figure2.1.

During the software development process the author of this thesis has strived to follow theGoogle C++ Style Guide[7] concerning naming, structure, functionality and convention forthe developed software. The main reason for trying to follow a specific coding convention hasbeen to simplify the code and making it easier to understand for future developers. Following acoding convention can also help with upholding a higher consistency through out the software.

2.1.3 Design Patterns

In order to make the project more general and easier to comprehend for someone not involvedin the developing process, the author of this thesis has tried to implement widely establishedpatterns and solutions during the software design. For example the DeviceManager, which isthe module responsible for the connection and communication with the attached biomedicalsensors, has been implemented according to the Facade pattern. Where one base class acts to

Chapter 2. Method 5

Figure 2.1: Workflow describing the Software Development Sprints

simplify the interface for the rest of the application. More information about design patternsin general can be found in section A.3.4 of Appendix A.

2.1.4 Cross-compilation and Implementing a Build System

The software have been developed and built from workstations using Ubuntu and Linux Mint.In order for the software to run on the Raspberry PI the software has been cross-compiled withRaspbian as the intended host. To handle the cross-compilation and simplify the dependencytracking the build system CMake has been used. Through the creation of specific CMakeconfiguration and toolchain files the same CMakeLists.txt has be used to build the softwarefor different systems. The configuration and toolchain files specifies were to look for theneeded dependencies. To further simplify building the Biosignal PI on different computers,some BASH scripts were created to build and install all the different software and dependenciesneeded for building and developing the Biosignal PI from a Linux computer.

2.1.5 Software Testing

To encourage fast and objective testing throughout the development process the project uti-lized automated unit tests created with the Google testing framework Googletest[8]. Thedifferent tests were registered and called with the help of the testing framework. This was

6 Chapter 2. Method

handled through the creation of a CMake configuration file specific for the testing framework.The written tests were automatically built together with the rest of the software when CMakeand Make was called. The tests were there after called to verify that the new build did notbreak any of the rules set by the tests.

2.2 Heart Rate Variability Analysis

Besides the main objective of developing the Biosignal PI framework this projects also aimed atimplementing functionality for performing Heart Rate Variability Analysis with the BiosignalPI software. Since there already existed functioning open-source software for HRV-Analysisthe HRV functions used in this project were adopted from the MATLAB application HRVASwritten by John T. Ramshur[9]. The HRVAS software uses Interbeat Intervall(IBI) data asinput which made it necessary to process ECG-Data obtained from the Biosignal PI into anIBI-file, which was performed through QRS-detection. More information about general useand physiological origin of HRV can be found in section A.1.2 of Appendix A.

2.2.1 QRS-Detection

To be able to create an IBI-file from the information in the ECG-file the data has to be sentthrough a QRS-Detection algorithm. The QRS-detection algorithm used in this project wasimplemented from a modified version of the Hamilton-Tompkins Algorithm[10]. The modifiedalgorithm was extracted from the QRS-detector used in an ECG-Analysis software written inC by Patrick S. Hamilton[11]. A flowchart describing the detection process can be seen infigure 2.2, the different steps of the flowchart are explained below[10].

Figure 2.2: Flowchart describing the steps necessary for QRS-Detection of anECG-File into an IBI-File

• Preprocessing, in order to prepare the ECG-file for QRS-detection the file needs toundergo a number of steps transforming the original signal according to the needs of theQRS-detection part.

– Filtering, the ECG file is passed through both a low-pass filter and a high-passfilter. The filtering part is adopted from the Pan-Tompkins Algorithm[12].

Chapter 2. Method 7

– Differentiation and Time-averaging, the filtered signal is divided into two sig-nals y(n) and z(n). y(n) is saved as a referencing signal for use in the the Fidu-cial mark locator the other filtered signal z(n) is differentiated, squared and time-averaged.

– Peak Detection. the signal z(n) is used to detect the peaks located in the inves-tigated signal.

– Fiducial Mark Locator, for the peaks found in the time-averaged z(n) signal thecorresponding filtered peak is located in the reference signal y(n). The correspond-ing peak is chosen as the highest peak in the filtered signal y(n) in an interval 125msto 225 ms preceding the peak in the time-averaged signal z(n)[10].

• Event Vector, is a two column vector containing the results from the Preprocessingstage.

• QRS Detection Decision, all the peaks detected in the preprocessing stage is com-pared to a couple of rules in order to decide if the detected peak was a QRS complex.The different rules for deciding whether to accept or reject a peak is based on a combi-nation of information regarding the previous peaks as well as the height of the specificpeak.

After the QRS-detector had been implemented into the Biosignal PI software the functionalityof the beat detector was tested through the use of example ECG-data from the MIT-BIHdatabases[13] available through the online database collection PhysioBank Automated TellerMachine at physionet.org[14]. The MIT-BIH databases consists of different ECG-recordingsthat have accompanying IBI-files. In that way it was possible to compare the Biosignal PIgenerated IBI-files with the MIT-BIH reference IBI-files to see that the implemented algorithmperformed as wanted.

2.2.2 Converting MATLAB Code into C++ Code

The MATLAB code was converted into C++ code through the use of MATLAB Coder. Whichis a module that comes with Mathworks MATLAB, the coder was able to convert most partsof the original MATLAB code into C++ but in some functions part of the MATLAB codehad to be partially rewritten before converting it into C++ code. A flowchart describing howthe conversion was performed from MATLAB code into C++ code can be seen in figure 2.3.

To be able to use the generated C++ code with the Biosignal PI software it was necessary towrite so called initiation functions that could convert the data from the type used in Biosig-nal PI into the data-type used by the converted HRV-functions. Before the HRV-functionsconverted fromMATLAB could be called they needed to be initiated with the [Converted Func-tion]_initialize() function available with the converted MATLAB code. When the BiosignalPI software was done with the MATLAB HRV-functions they needed to be closed through thefunction [Converted Function]_terminate().

8 Chapter 2. Method

Figure 2.3: Flowchart describing the steps necessary to transform MATLABcode into C++ using MATLAB Coder

Chapter 2. Method 9

2.3 Bluetooth

To enable file transfer between Biosignal PI and a workstation the Biosignal PI has been im-plemented with support for transferring files using Bluetooth. The Raspberry PI was givenBluetooth functionallity through the use of a Bluetooth usb-dongle from Deltaco. The Blue-tooth functionality was implemented from code examples available with the Qt installation asa blueprint for how to create the connection[15].

2.4 Using PiFace Control and Display

One of the objectives of the project was to implement support for the hardware module PiFaceControl and Display(CAD). Implementation of PiFace CAD allows for usage of the systemwithout the need of a screen, mouse and keyboard for controlling the Biosignal PI. The PiFaceCAD GUI was implemented through the use of the static C library libpifacecad written byThomas Preston [16] which was used for communication between the created software andthe PiFace. In order to use the PiFace screen and buttons for controlling the Biosignal PIframework an abstract menu class was created that was implemented for all the menus neededfor using the PiFace CAD.

The PiFace CAD was connected to the RPI through the use of a PiFace PiRack as seen infigure 2.4, the usage of the PiRack was necessary since the RPI only have space for one GPIOdevice at the time without the PiRack.

2.5 Documenting the Created Software

To help with creating a software documentation the software Doxygen were used, more in-formation on Doxygen can be found in section A.3.2.4 of Appendix A. For a function or aparameter to turn up in the documentation it was given Doxygen formatted comments insidethe source code, the comments will there after be extracted by Doxygen. How and what toinclude in the document generation was specified in the Doxygen Configuration file DoxyFile.By calling Doxygen with Doxyfile the same configuration can be used for every documentationgeneration.

10 Chapter 2. Method

Figure 2.4: PiFace(top) connected to the Raspberry PI(bottom) usingPiRack(left), the ADAS board(middle connected with brown cable) is also con-

nected in the picture

Chapter 3

Results

The results section will cover description and figures explaining the created Biosignal PI frame-work as well as the expansions made for the Biosignals PI. Adding features for HRV analysis,Bluetooth file transfer and creation of a graphical user interface for the PiFace hardwaremodule.

3.1 Biosignal PI Framework

The created framework is meant to be modular with a high level of interchangeability regardingwhat sort of signal to capture, how to capture the signal and also how to store and visualizethe captured signals. To achieve this level of modularity the software has been developed intodifferent abstract parts. The main thought is to limit the dependency between the differentparts which has been achieved by adding abstract interfaces for all the different modules. Theinterface states how the communication should be performed for future new classes, this waychanging the capturing device or changing the type of data to store would not interfere withother parts of the software. The main layout of the Biosignal PI Framework can be seen infigure 3.1.

3.1.1 Device Facade

The class DeviceManager is created to work according to the Facade pattern handling all thecommunication between the used devices and the classes lying outside of the Device cluster.DeviceManager inherits from the QThread class making it possible having the DeviceManagerrunning in its own thread. To connect a certain device to the DeviceManager one need towrite a device specific class implementing the DeviceInterface class to be able to connect it toDeviceManager.

3.1.2 Data Model and Logging

The DataStream QObject is an abstract interface that specifies the functionality available whenusing a DataStream, which is the Data Model used for all connected devices to store and access

11

12 Chapter 3. Results

Figure 3.1: Specification of the different modules and parts of the BiosignalPI Framework

captured data. For saving the data into a file the DataLogger class is called. The DataLoggeris created to allow for more file types in the future, depending on the needs of the project itsbeing used in.

3.1.3 Application Wide Settings

The class SettingsSingleton is created according to the singleton pattern, meaning in broadterms that it cannot be copied, it can only be initialized by itsself and there can only exist onesingleton per application. The SettingsSingleton keeps all settings and options that are meantto be accessible for all classes in the application. The parameters stored in SettingsSingleton areset and accessed through the use of get and set functions in SettingsSingleton. By concealingthe actual parameters it is possible to implement validation functions for all parameters in alatter stage.

3.1.4 CMake integration

To simplify the process of compiling and building the Biosignal PI on different RPI this projecthas integrated support for building the Biosignal PI software with CMake. If any of BiosignalPI’s external dependencies are located on other locations then the default paths specified

Chapter 3. Results 13

by the operating system, the path to this dependency has to be set manually in a CMake-configuration file. Example configuration files are included with the Biosignal PI source code.

3.1.5 Automated Testing

To allow for automated testing the testing framework Googletest has been integrated into theCMake build system. By having the test framework integrated in the build system the testsare being compiled and built for every new build of the Biosignal PI software. In this way thetests can catch any new error in an early stage.

3.2 Heart Rate Variability Analysis Widget

To perform and display HRV Analysis a new QWidget HrvWidget was created and imple-mented as a QStackedWidget of MainWindow. HrvWidget lets the user choose the file toperform HRV-analysis on. After the chosen file have been double clicked it is processed ac-cording to the flowchart in figure 3.2 through the use of hrvanalysis.h, which contains all thefunctions needed for the different processing steps. The final result of the HRV-Analysis isdisplayed in HrvWidget as shown in figure 3.3.

3.3 Bluetooth Transfer Widget

To allow for file transfer with Bluetooth a new QWidget was added as a QStackedWidget toMainWindow. The Bluetooth widget utilizes the Qt module QtBluetooth which depends onbluez for the bluetooth functionality. For the file transfer the widget is using Obex ObjectPush, enabling it to send the chosen file to a connected computer or phone. A screenshot of theBluetooth widget can be seen in figure 3.4. The implemented bluetooth file transfer function iscurrently not working due to an unknown RPI problem with the Obex Object Push protocol.The Bluetooth functionality is however working as planned for the Ubuntu and Linux Mintbuilds of the Biosignal PI software.

3.4 PiFace Graphical User Interface

To run the Biosignal PI software with PiFace CAD a new GUI was created specialized for thePiFace CAD. The new PiFace GUI is implemented as a simple QCoreApplication consisting ofa loop checking the status of PiFace CAD switches(buttons), an illustration of the numberingof the different switches on the PiFace CAD can be seen in figure 3.5 for this implementationonly switch 4(exit application), 5(confirm) and 7(move to forward) are used. Depending onwhat switch the user pushes, the LCD screen of the PiFace shows different options implementedas different abstract menu objects.

14 Chapter 3. Results

ECG-Data

QRS Detection

IBI-Data

Ectopic Interval Detection and

Correction

Normalized IBI-Data

Time DomainHRV-Analysis

Detrending

Detrended andNormalized

IBI-Data

Frequency DomainHRV-Analysis

Display HRV-Analysis

Figure 3.2: Flowchart describing the different processing steps necessary toperform HRV-Analysis of the ECG-file chosen by the user

Chapter 3. Results 15

Figure 3.3: Screenshot showing the HrvWidget after a ECG-file has beenprocessed and the HRV-Analysis is displayed

16 Chapter 3. Results

Figure 3.4: Screenshot showing the Bluetooth Transfer Widget

Figure 3.5: PiFace Control and Display with the different switches numberedas they are in the used C-library libpifacecad

Chapter 3. Results 17

The different menu objects utilizes the Biosignal PI framework for capturing of ECG-signalsfrom the ADAS. The captured signal is saved through the DataLogger after the data acquisitionis stopped. To allow for the RPI to be started with the PiFace CAD without a monitor andkeyboard the RPI can be set up to boot directly to the Biosignal PI PiFace GUI if the PiFaceis connected. If the PiFace is not connected the RPI will boot to the terminal instead.

3.5 Software Documentation

Through the use of Doxygen, software documentation has been created in two versions. Oneweb version created in html and also a PDF version of the complete software documentation.The homepage(index.html) is shown in figure 3.6. To show an example of how the differentclass pages looks like for a specific class figure 3.7 shows the webpage generated for the De-viceManager class. The figure only shows the top view, more information is available for theDeviceManager further down the webpage. The PDF version is generated from a makefileusing LaTeX.

Figure 3.6: Screenshot of the homepage for the Biosignal PI Documentation

18 Chapter 3. Results

Figure 3.7: Screenshot showing the top of the Documentation for the Device-Manager

Chapter 4

Discussion

4.1 Biosignal PI Framework and software

The main objective of this project was the creation of the Biosignal PI software frameworkdescribed in section 3.1. The framework has been created to allow for future changes andadditions within the different modules without the need of changing other modules. Onepriority when constructing the framework was to try and prepare for future expansions, whichmay have made some parts more complex then necessary. The added complexity has beenregarded as acceptable given that is will simplify for further development.

When designing the Biosignal PI framework it was regarded important to create a softwarearchitecture that could be implemented into different sorts of projects concerning acquisitionof physiological signals from some sort of hardware device. For that reason the hardwarespecific parts were abstracted into a DeviceInterface object connected to the DeviceManagerclass. For the DataLogger the hardware dependent parts were abstracted through the use ofthe Qt framework.

To simplify and save time during the implementation of different features, the author of thisthesis has searched for existing open-source solutions and libraries to solve the needed tasksthat have appeared during the software development phase. Both the HRV-analysis and Blue-tooth connectivity is implemented from existing coding made available by other developers.

The developed framework was implemented into an extended version of the original Qt GUI.It was also implemented in a new GUI for the PiFace Control and Display hardware module.The PiFace GUI was implemented with a more simplified functionality then the Qt GUI. Ifneeded in future projects the PiFace GUI can be extended using the same abstract menu classas it is implemented with now.

The produced HrvWidget takes an ECG-file as input and performs an HRV-analysis of thefile. In order for this to work the ECG-file has to pass through a QRS-detector. Detecting theQRS-peaks has proven to be a somewhat resource demanding tasks taking about 10 minutesfor a 1-hour ECG-file on the RPI. This process is moved to another thread to avoid locking theQt-GUI but it still takes a lot of time to transform from ECG to IBI-file. The implementedQRS-detection algorithm has not been optimized for the application. Trying to optimize theused QRS-detection algorithm might significantly speed up the HRV-Analysis process. For

19

20 Chapter 4. Discussion

this reason the IBI is saved as a txt file that the software will use if one wants to analyse thesame file again latter, making the second HRV-Analysis of a HRV-file much faster.

4.2 Biosignal PI as a Medical Device

As described in section A.4 in Appendix A concerning the Medical Device Directive(MDD),there is a lot of demands for software used with and as a Medical Device. During the develop-ment of the software in this project a couple of steps has been taking moving the Biosignal PIcloser to the different demands. Creating a description of the general software architecture,as done in this project, is one of the requirements for the MDD classification.

To simplify with dependency tracking and deployment of the developed software, the projectwas implemented with CMake for managing the build process. Implementing a build systemwas also important because it is a way of maintaining a correct and secure correct deploymentfor the chosen target environment, which is necessary according to the MDD.

Adding the Googletest framework is also a important preparation for the future. This projecthas only implemented a couple unit tests but more unit tests can be added in the future. Thesame testing framework can also be used for implementing integration and system testing. Allthree types of tests are necessary according to the MDD.

Another important aspect in software in general and medical software specifically is the need forproper documentation. The chosen document generation tool Doxygen can be used not only toprovide comments regarding functions and classes. But it is also possible to utilize Doxygen asa way of organizing different sort of functional lists as for example bug and todo lists, and alsocreating UML-diagrams describing the dependencies and relations between different classesand functions.

Chapter 5

Conclusion

A software framework capable of capturing and storing bio-signals in a hardware independentmanner has been created. The newly created framework has thereafter been implementedinto the Biosignal PI software. The original Biosignal PI software was developed in an earlierproject[6]. The Biosignal PI software has also been extended with an GUI created for thehardware module PiFace Control and Display. The PiFace GUI allows the Biosignal PI to berun without keyboard, mouse and screen connection. Features for performing HRV-Analysishas been added to the Biosignal PI application. To simplify for further development andunderstanding of the Biosignal PI an html-documentation has been created. This thesis projecthas also integrated the Googletest testing framework and CMake build system to furthersimplify for future development of the Biosignal PI project.

Even if some of the steps necessary for medical device software has been taken there stillremains some requirements that need to be attended. The Biosignal PI software is not tobe regarded as a Medical Device, but rather as Software of Unknown Provenance(SOUP) formainly educational and research purposes.

The Biosignal PI software developed in this thesis is available through Github at https://github.com/biosignalpi/Version-A1-Rapsberry-PI.

21

Chapter 6

Future Work

To further develop the Biosignal PI system it would be interesting to try to optimize thedeveloped software. Especially the QRS-detection and the HRV-Analysis functions might beable to work faster after optimization, lowering the waiting time for the HRV-Analysis. Itwould also be interesting to implement communication with some sort of database connectedto a web interface making it easier to access the collected information. An easier access couldopen up new opportunities and making it possible to use the Biosignal PI system from adistance e.g. user having it at home collecting data that someone else e.g. doctor/researchercould access. To continue on possible applications the Biosignal PI could also be extendedto feature some sort of heart beat detection. The ECG-Analysis software used for the QRS-detection also features functions for beat classification which could be implemented into theBiosignal PI software as a way of detecting arrhythmias.

In the future it would be interesting to see the Biosignal PI framework implemented togetherwith another acquisition hardware module then the ADAS1000 to further test the flexibilityof the produced framework. Regarding hardware changes it would also be interesting to testthe possibility of using the Biosignal PI with an battery pack. Combining the battery packwith WiFi or Bluetooth connection would be a way of possibly using the Biosignal PI systemas a telemonitoring system.

If the Biosignal PI someday are supposed to be classified as a medical device it would benecessary performing a thorough investigation of the steps needed for that. This project hasonly started on the documentation and testing required for certification. Among other thingsa Risk Management Process is a clear requirement according to the Medical Device Directive.However a thorough evaluation would be needed to clarify exactly what has to be done if onewants to use the Biosignal PI as a medical device, instead of using it primarily for researchand education as it is intended now.

23

Bibliography

[1] United Nations, “World Population Ageing 1950-2050: 2013”, United Nations, Depart-ment of Economic and Social Affairs Population Division, Report, 2013.

[2] WHO, “Good health adds life to years, Global brief for World Health Day 2012”, WorldHealth Organization, Report, 2012.

[3] S. Koch, “Home telehealth—Current state and future trends”, International Journal ofMedical Informatics, vol. 75, no. 8, pp. 565–576, 2006, issn: 1386-5056. doi: 10.1016/j.ijmedinf.2005.09.002.

[4] T. Botsis and G. Hartvigsen, “Current status and future perspectives in telecare forelderly people suffering from chronic diseases”, Journal of Telemedicine and Telecare,vol. 14, no. 4, pp. 195–203, 2008. doi: 10.1258/jtt.2008.070905.

[5] F. Abtahi, J. Snall, B. Aslamy, S. Abtahi, F. Seoane, and K. Lindecrantz, “Biosignal PI,an Affordable Open-Source ECG and Respiration Measurement System”, Sensors, vol.15, no. 1, pp. 93–109, 2015, issn: 1424-8220. doi: 10.3390/s150100093.

[6] J. Snäll, “Software Development of Biosignal PI: An affordable open source platform formonitoring ECG and respiration”, Master Thesis, Royal Institute of Technology, 2014.

[7] Google. (2015). Google C++ Style Guide, [Online]. Available: http://google.github.io/styleguide/cppguide.html (visited on 10/05/2015).

[8] GoogleTest. (2013). Getting started with Google C++ Testing Framework, [Online].Available: https://code.google.com/p/googletest/wiki/V1_7_Primer (visited on10/07/2015).

[9] J. T. Ramshur, “Design, evaluation, and application of heart rate variability software(HRVAS)”, The University of Memphis, Memphis, TN, 2010.

[10] P. S. Hamilton and W. J. Tompkins, “Quantitative investigation of QRS detection rulesusing the MIT/BIH arrhythmia database”, Biomedical Engineering, IEEE Transactionson, no. 12, pp. 1157–1165, 1986.

[11] EP Limited. (2003). EP Limited: Open Source ECG Analysis Software, [Online]. Avail-able: http://www.eplimited.com/confirmation.htm (visited on 01/06/2016).

[12] J. Pan and W. J. Tompkins, “A real-time QRS detection algorithm”, Biomedical Engi-neering, IEEE Transactions on, no. 3, pp. 230–236, 1985.

[13] G. B. Moody and R. G. Mark, “The impact of the MIT-BIH arrhythmia database”,Engineering in Medicine and Biology Magazine, IEEE, vol. 20, no. 3, pp. 45–50, 2001.

25

26 BIBLIOGRAPHY

[14] A. L. Goldberger, L. A. Amaral, L. Glass, J. M. Hausdorff, P. C. Ivanov, R. G. Mark,J. E. Mietus, G. B. Moody, C.-K. Peng, and H. E. Stanley, “Physiobank, Physiotoolkit,and Physionet components of a new research resource for complex physiologic signals”,Circulation, vol. 101, no. 23, e215–e220, 2000.

[15] Qt Company. (2015). Qt Bluetooth Overview | Qt Bluetooth 5.5, [Online]. Available:http://doc.qt.io/qt-5/qtbluetooth-overview.html (visited on 01/01/2016).

[16] P. Thomas Preston. (2014). Piface/libpifacecad, [Online]. Available: https://github.com/piface/libpifacecad (visited on 01/01/2016).

[17] G. Pocock and C. D. Richards, Human Physiology, The basis of medicine, 3rd. 2006,ch. 15, pp. 262–279, isbn: 0-19-856878-9.

[18] A. Atkielski. (2007). QRS-complex, [Online]. Available: https://commons.wikimedia.org/wiki/File:SinusRhythmLabels.svg (visited on 10/15/2015).

[19] U. R. Acharya, K. P. Joseph, N. Kannathal, C. M. Lim, and J. S. Suri, “Heart ratevariability: a review”, MEDICAL & BIOLOGICAL ENGINEERING & COMPUTING,vol. 44, no. 12, 1031–1051, 2006, issn: 0140-0118. doi: 10.1007/s11517-006-0119-0.

[20] K. Lindskog, “Development and evaluation of a HRV Biofeedback System”, 2014.

[21] M. P. Tarvainen, J.-P. Niskanen, J. A. Lipponen, P. O. Ranta-aho, and P. A. Kar-jalainen, “Kubios HRV - Heart rate variability analysis software”, English, COMPUTERMETHODS AND PROGRAMS IN BIOMEDICINE, vol. 113, no. 1, 210–220, 2014, issn:0169-2607. doi: 10.1016/j.cmpb.2013.07.024.

[22] A. Camm, M Malik, J. Bigger, G Breithardt, S Cerutti, R. Cohen, P Coumel, E. Fallen,H. Kennedy, R. Kleiger, F Lombardi, A Malliani, A. Moss, J. Rottman, G Schmidt, P.Schwartz, and D. Singer, “Heart rate variability. Standards of measurement, physiologicalinterpretation, and clinical use”, EUROPEAN HEART JOURNAL, vol. 17, no. 3, 354–381, 1996, issn: 0195-668X.

[23] F. Abtahi, A. Berndtsson, S. Abtahi, F. Seoane, and K. Lindecrantz, “Development andpreliminary evaluation of an Android based heart rate variability biofeedback system”, inEngineering in Medicine and Biology Society (EMBC), 2014 36th Annual InternationalConference of the IEEE, IEEE, 2014, pp. 3382–3385.

[24] G. Tan, T. Dao, L. Farmer, R. Sutherland, and R. Gevirtz, “Heart Rate Variability(HRV) and Posttraumatic Stress Disorder (PTSD): A Pilot Study”, English, AppliedPsychophysiology and Biofeedback, vol. 36, no. 1, pp. 27–35, 2011, issn: 1090-0586. doi:10.1007/s10484-010-9141-y. [Online]. Available: http://dx.doi.org/10.1007/s10484-010-9141-y.

[25] A. L. Hassett, D. C. Radvanski, E. G. Vaschillo, B. Vaschillo, L. H. Sigal, M. K. Karavi-das, S. Buyske, and P. M. Lehrer, “A pilot study of the efficacy of heart rate variability(HRV) biofeedback in patients with fibromyalgia”, Applied psychophysiology and biofeed-back, vol. 32, no. 1, pp. 1–10, 2007.

[26] R. P. Nolan, M. V. Kamath, J. S. Floras, J. Stanley, C. Pang, P. Picton, and Q. R.Young, “Heart Rate Variability Biofeedback as a behavioral neurocardiac intervention

BIBLIOGRAPHY 27

to enhance vagal heart rate control”, American heart journal, vol. 149, no. 6, 1137–e1,2005.

[27] L. Rodriguez-Linares, M. J. Lado, X. A. Vila, A. J. Mendez, and P. Cuesta, “gHRV:Heart rate variability analysis made easy”, English, COMPUTER METHODS ANDPROGRAMS IN BIOMEDICINE, vol. 116, no. 1, 26–38, 2014, issn: 0169-2607. doi:10.1016/j.cmpb.2014.04.007.

[28] The Raspberry Pi Fundation. (2015). The Raspberry Pi Fundation | About us, [Online].Available: https://www.raspberrypi.org/about/ (visited on 09/29/2015).

[29] The Register. (2015). Raspberry Pi 2, [Online]. Available: http://www.theregister.co.uk/2015/02/02/raspberry_pi_model_2/ (visited on 09/30/2015).

[30] The Raspberry Pi Fundation. (2015). Raspberry Pi 2 Model B, [Online]. Available:https://www.raspberrypi.org/products/raspberry-pi-2-model-b/ (visited on09/29/2015).

[31] Raspbian. (2015). Raspbian, [Online]. Available: https://www.raspbian.org/ (visitedon 09/29/2015).

[32] The Raspberry Pi Fundation. (2015). GPIO: Models A+, B+ and Raspberry PI 2,[Online]. Available: https://www.raspberrypi.org/documentation/usage/gpio-plus-and-raspi2/ (visited on 09/29/2015).

[33] P. M. Encyclopedia. (2015). SPI Bus Definition, [Online]. Available: http://www.pcmag.com/encyclopedia/term/59605/spi-bus (visited on 10/15/2015).

[34] PiFace. (2015). PiFace Control and Display, [Online]. Available: http://www.piface.org.uk/products/piface_control_and_display/ (visited on 10/15/2015).

[35] Analog Devices. (2015). ADAS 1000. datasheet and product info, [Online]. Available:http : / / www . analog . com / en / products / analog - to - digital - converters / ad -converters/adas1000.html (visited on 09/30/2015).

[36] B. Janamanchi, E. Katsamakas, W. Raghupathi, and W. Gao, “The State and Profileof Open Source Software Projects in health and medical informatics”, English, INTER-NATIONAL JOURNAL OF MEDICAL INFORMATICS, vol. 78, no. 7, 457–472, 2009,issn: 1386-5056. doi: 10.1016/j.ijmedinf.2009.02.006.

[37] A. Enquobahrie, P. Cheng, K. Gary, L. Ibanez, D. Gobbi, F. Lindseth, Z. Yaniv, S.Aylward, J. Jomier, and K. Cleary, “The image-guided surgery toolkit IGSTK: An opensource C++ software toolkit”, English, JOURNAL OF DIGITAL IMAGING, vol. 20,no. 1, 21–33, 2007, issn: 0897-1889. doi: 10.1007/s10278-007-9054-3.

[38] Kitware. (2015). Overview | CMake, [Online]. Available: https://cmake.org/overview/(visited on 10/05/2015).

[39] S. Chacon, Pro Git. Apress, 2009.

[40] J. Blanchette and M. Summerfield, C++ GUI Programming with Qt 4 (2nd Edition) -The official C++/Qt book. Pearson Education, 2008, isbn: 978-0132354165.

28 BIBLIOGRAPHY

[41] Doxygen. (2015). Doxygen: main page, [Online]. Available: http://doxygen.org (visitedon 12/07/2015).

[42] A. Pham and P.-V. Pham, Scrum in Action, Agile Software Project Management andDevelopment. Course Technology PTR, 2012, isbn: 978-1-4354-5919-7.

[43] Monroe, Robert T and Kompanek, Andrew and Melton, Ralph and Garlan, David B,“Architectural styles, design patterns, and objects”, IEEE software, p. 43, 1996.

[44] E. Gamma, R. Helm, R. Johnson, and J. Vlissides, Design Patterns: Elements of ReusableObject-Oriented Software. Pearson Education, 1994, isbn: 9780321700698.

[45] N. Hrgarek, “Certification and regulatory challenges in medical device software devel-opment”, in Proceedings of the 4th International Workshop on Software Engineering inHealth Care, IEEE Press, 2012, pp. 40–43.

[46] C. Becchetti and A. Neri,Medical instrument design and development: from requirementsto market placements. John Wiley & Sons, 2013, ch. 6, pp. 359–418.

[47] European Commisson, Directive 93/42/ECC, 2010.

Appendix A

Literature Study

A.1 Electrophysiology of the Human Heart

This chapter will give a brief description of the medical background behind electrocardiographyand heart rate variability. It will also include a short introduction of what metrics a heart ratevariability analysis can consist of.

A.1.1 Electrocardiography

The human heart works like a pump because the cardiac muscles dilate and constrict. Inthis way the heart is filled with blood during dilation which is then pushed out of the heartinto the blood vessels during contraction. For this process to work properly each part ofthe myocardium needs to be synchronized with the rest of the heart. This synchronizationis achieved with the help of conducting tissue and small electrical currents sent from thesinoatrial node in the left upper quadrant of the heart. When the current spreads through theheart small potential differences occur and these potential differences can be measured withElectrocardiography(ECG). ECG is a well established tool for diagnosing and monitoringcardiac activity. A typical ECG consists of three main parts; the P-wave resulting due tothe atrial depolarization, QRS-complex resulting from the ventricular depolarization and aT-wave resulting from repolarization of the ventricles as shown in figure A.1. The ECG canbe used in a wide variety of diagnostic and monitoring purposes for instance detecting cardiacarrhythmia and cardiac abnormalities.[17]

A.1.2 Heart Rate Variability

Heart Rate Variability(HRV) is the time alterations between two consecutive heartbeats. Evenfor a steady heart rate there exist variation in time between two heartbeats, this phenomenais controlled by the autonomous nervous system(ANS). The ANS consists of sympathetic andparasympathetic activity. The sympathetic activity tends to increase the heart rate and lowerthe HRV while parasympathetic activity has the opposite effect.[19]–[21]

29

30 Appendix A. Literature Study

Figure A.1: Illustration of typical ECG trace [18]

A new heartbeat typically start with the P-wave of the ECG-trace as seen in figure A.1.HRV is however often calculated as the time between consecutive R-peaks since it is muchsimpler to recognize R-peaks in an ECG compared to P-waves, the time between two regularR-peaks is called the R-R interval. R-R intervals triggered by the sinoatrial node are calledN-N interval.[21]

A.1.2.1 Clinical Use of Heart Rate Variability

HRV has a lot of different possible clinical applications. One area where HRV has shown successis in risk prediction of sudden cardiac death following an acute myocardial infarction.[19], [22].HRV can also be used as a way of detecting diabetic neuropathy[19], [21], [22]. There is alsoa connection between HRV and a lot of different neurological, cardiac and renal diseases[19].Another way HRV can be used clinically is Biofeedback, which is a way of using HRV forbehavioral training for patients in order to increase their HRV. There are several methods forBiofeedback, one of the more common ones are resonant frequency training (RFT), where thetraining is performed by making the patient breath in a certain frequency[23]. Biofeedbackhas shown promises with a variety of diseases eg. Posttraumatic stress disorder(PTSD)[24],Fibromyalgia[25] and treatment of stress in patients with coronary heart disease(CHD)[26].

Appendix A. Literature Study 31

A.1.3 Methods for Heart Rate Variability Analysis

In order to study the HRV it is necessary to perform some sort of HRV Analysis Software. Theanalysis can consists of information obtained through different types of analysis of the HRV.The three main categories of computational methods commonly used are Time-domain meth-ods, Frequency-domain methods and nonlinear methods. The nonlinear methods include meth-ods such as for example Poincare plot, approximate entropy(ApEn), sample entropy(SampEn)and detrended fluctuation analysis(DFA).[21], [27]

A.1.3.1 Time-domain Methods

Some common time-domain metrics for measuring HRV are listed in table A.1.[21]

Variable Unit DescriptionSDNN ms standard deviation of all N-N intervalsNN50 # number of adjacent N-N intervals that differ more than 50mspNN50 % percentage of NN50 of all the N-N intervalsRR ms mean value of R-R intervals

Table A.1: Metrics for Time-Domain Analysis of HRV[22]

A.1.3.2 Frequency-domain Methods

The frequency domain methods are calculated from power spectral density(PSD) analysisof the signal. The PSD is generally divided into three groups very low frequency(VLF), lowfrequency(LF) and high frequency(HF). Some common metrics for Frequency-domain are listedin table A.2.[21]

Variable Unit DescriptionTotal Power ms2 The variance of NN intervalsVLF ms2 Power in VLF-range (<0.04Hz)LF ms2 Power in LF-range (0.04-0.15Hz)HF ms2 Power in HF-range (0.15-0.4Hz)LF/HF - Ratio between LF and HF

Table A.2: Metrics for Frequency-Domain Analysis of HRV[22]

32 Appendix A. Literature Study

Appendix A. Literature Study 33

A.2 Hardware

This chapter will go into the hardware necessary to be able to collect ECG-signal and alsodisplay and analyze the signals collected.

A.2.1 Raspberry PI

The Raspberry PI(RPI) is an affordable credit-card sized single-board personal-computer cre-ated by the Raspberry PI foundation which is an educational charity founded in order topromote the education of children and adults in the field of computers and computer science.The RPI can be used in education and research as an electronics prototyping platform forsmaller projects.[28]

The current RPI model is named Raspberry PI 2 Model B seen in figure A.2 and was releasedin February 2015 it is a upgrade of the older RPI 1 Model B+ (previously called RPI ModelB+).

Figure A.2: Raspberry PI 2 model B [29]

The main difference between RPI 1 B+ and RPI 2 B is a new multicore processor and alarger memory. The RPI can be installed with a variety of different operating systems butthe recommended one is Raspbian, a free operating system based on the Linux distributionDebian optimized for the RPI.[30], [31]

A.2.1.1 General-Purpose Input/Output

One of the things that makes RPI well suited for use in small projects is its ability to easily con-nect and control analog and digital hardware through its general-purpose input/output(GPIO)pins. The RPI is equipped with a 40-pin connector header. Out of the 40 pins, 26 of themare GPIO with the ability to either be programmed as an input or an output depending onthe needs of the specific project. Some of the GPIO pins can be used for Serial PeripheralInterface(SPI) communication between the RPI and attached hardware modules. SPI is a

34 Appendix A. Literature Study

communication protocol used to enable communication between different devices. The SPIsetup consists of a master device, for example a RPI, that control the communication to oneor more slave devices. A digital pathway is established between the devices with one line forinput and one line that handles output.[32], [33]

A.2.1.2 PiFace Control and Display

PiFace Control and Display(CAD) is a hardware module that can connect to the header of theRPI and communicate with the RPI through SPI. By connecting a PiFace CAD to the RPI itis possible to replace the need of keyboard and screen in order to control the RPI. The PiFaceCAD consists of a small backlight LCD display with the ability to show a total of 32 characterdivided into two lines. It also has 5 tactile buttons and a three-way navigational switch. Asseen in figure A.3

Figure A.3: PiFace Control and Display [34]

Through the help of library files written in Python it is possible to program the display andthe function of all the buttons and switch in order for the PiFace CAD to fit the need of anygiven software project.[34]

A.2.2 ADAS1000

The ADAS1000(ADAS) is an analog to digital converter(AD converter) designed for use ina wide-variety of applications were there exits a need for acquisition of high quality 5-leadECG with built in noise filtering and pace detection. The ADAS converts bio-potential signalsacquired from the chest of a patient into a digital signal that can be used for analyzingand monitoring in a software application. The ADAS also features functions for lead on/offdetection and test-signals for verification of new applications. The ADAS can be connectedto the GPIO of the RPI. SPI communication is used for the link between RPI and ADAS.[35]

Appendix A. Literature Study 35

A.3 Software Development

This chapter will give an introduction to open source development in general as well as someinformation about different concepts in software engineering useful for the development ofsoftware able to run on the Raspberry Pi.

A.3.1 Open Source Development

The development of open source software(OSS) is a rising trend within the healthcare industry.The reason for the increase of OSS might be that it is seen as a way of getting working soft-ware for a lower development cost when one can utilize collaboration between developers andresearchers from different part of the world. Open source software should not be confused withfree software. Free software usually only provide free executable program while open sourceprovides the source code, enabling users to be able to change how the program works.[36], [37]

The foundation of OSS is the Open Source Model which uses internet and communities as away of collaboration and leverage ideas, creativity and contributions from both the academicas well as the commercial world through its common software base. With an open sourcecode anyone interested can be a part of the project and contribute with what they have tooffer. Open source software can be used as a valuable educational tool since it is possible for astudent to study the source code that others have developed and even try to improve the code.Through the use of open source software it is possible to share algorithms between projectpreventing the need of reinventing the wheel.[36], [37]

A.3.2 Development Environment

In order for a software project to be successful and well structured one might utilize a lot ofdifferent tools that can help move the project forward as well as simplify for other participantsof the project to keep track of the current status. Below is a description of some types of toolsthat may be useful to implement in a software project.

A.3.2.1 Dependency Tracking

In projects where the developed software are supposed to be run and developed on differentsystems it maybe necessary to utilize some sort of software that can track all the dependenciesneeded to build the software successfully. One of the most common ways of keep track ofdependencies is the software CMake. CMake is an open source program that generates buildfiles that can be used by the native build environment. Through the use of CMakeLists.txt filesthe programmer can specify which libraries and dependencies are needed for the program to bebuilt correctly. The software can also be used to manage cross-compilation making it possibleto build for deployment on another operating system then the one used for compilation.[38]

36 Appendix A. Literature Study

A.3.2.2 Source Code Management

Source Code Management(SCM) is used to keep track of changes in software projects. SCMcan be a useful tool for both small one-man projects on a single computer as well as largerprojects with many contributors from different computers. Through the use of SCM it ispossible to keep the source in-sync between different computers.[39]

One of the most common SCM is Git, which is a open source product that let the user workon a project by keeping both a local copy of the current project tree and a remote copyonline available to other collaborators. To store a git repository online it is common to usesome sort of online repository hosting service, one of the must used hosting services for gitare Github.com which also has features for Wiki creation and project management. Throughthe use of branches it is possible to work on new features without the risk of overwriting theoriginal source code.[39]

A.3.2.3 Application Framework

Qt is a cross-platform application framework used for application development in C++. Anapplication framework is used to simplify certain task in the development process. Cross-platform means that applications developed with Qt are able to be run on different platformseg. ubuntu and Raspbian without the need of rewriting the code for the specific platform.Qt was launched in 1995 as a Graphical User Interface(GUI) framework but has over timeevolved to include features for a wide variety of functions beside GUI, which can be usedin the development of a new program such as for example database communication, threadhandling and event handling.[40]

A.3.2.4 Software Documentation Generator

An important part of making the software development process understandable for others thenthe programmer of the code fragment is documentation. Documentation can be constructedand organised with the help of Document Generator software. The free software Doxygen is adocumentation generator that are able to generate either html or latex documentation from theprogrammers comments inside the source code of a software project. Doxygen interprets howdifferent classes and functions are related and uses this information together with the user-specified code comments to generate a complete description of the software project. Whattype of information to generate and how deep Doxygen is supposed to document is controlledthrough the use of a user written configuration file containing all information needed forDoxygen.[41]

A.3.2.5 Testing Framework

For a software product to be successful it needs to work as specified. The only way of beingcertain of the functionality is through testing. Testing can either be made by hand through

Appendix A. Literature Study 37

the use of a debugger or by automated testing which consists of constructing test cases thatverifies the functionality of the software. To simplify automated testing there are TestingFrameworks designed to run user created tests. Automated Test should be performed after allforms of changes to the software to verify that the changes did not cause any problems withthe functionality.[8], [42]

A.3.2.6 Coding Convention

When writing code, it is important that the code is easy to understand. One way of making thecode more understandable and easier to interpret is through consistency. In order to achieveconsistency, it is good to set up clear rules for how the program should be written and howdecisions are to be made. These sort of rules or guidelines are usually called either codingstyle or coding convention. Larger software projects usually have their own style guide whilesmaller software projects, with only a couple of participants, either lack a specific conventionor implement a style guide created by someone else.[7]

A.3.3 Software Architecture

Software Architecture is sort of the blueprint for a software program. The architecture de-scribes the system structure and behaviour in a general way specifying what functionality asystem will have. Through abstraction the software is divided into different components. Thefunctionality of the components and how they interact with other components lies in the ar-chitecture while the specific implementation details of the components is not relevant for thearchitecture.[43]

A.3.4 Design Patterns

The use of design patterns in software engineering is a way of simplifying development throughthe use of already established solutions to general problems. Many of the design patterns usedtoday stem from the book "Design Patterns, Elements of Reusable Object-Oriented Software"by Gamma et al published in 1994, this book is considered as the start of a more common useof design patterns in software engineering. A pattern usually has four major elements that aredescribed:[44]

• Pattern Name

• Problem Description, short explanation on what the pattern can be used for

• Solution, abstract explanation on how the pattern should be implemented

• Consequences, short summary on the results and trade-offs made by implementing aspecific pattern

The use of design patterns to solve problems have two main advantages. It is more efficientto find a existing solution to a similar problem rather then trying to create a completely new

38 Appendix A. Literature Study

solution. The use of design patterns makes the code easier to follow for people who have seenthe pattern before and knows what the pattern does and which classes are used. For peoplenot familiar with the specific pattern they can search for more information on the patternthrough the pattern name.[44]

Appendix A. Literature Study 39

A.4 Medical Device Certification

In order for a medical device to be used in a clinical setting the device needs to be certifiedaccording to the regulations specified for the country where the device are to be used. Thischapter will give a brief overview of the regulatory demands. Within the European Unioneverything in the medical device area is regulated by three European Union directives. Thesethree directives constitute the Medical Device Directive(MDD) which is a harmonized directivethat all EU and EEA countries have to implement in their own national legislation. Thedirective sets out requirements on quality, testing and verification of a medical device. Thedirectives use a couple of harmonized standards such as ISO/EN 14971(risk management),ISO/EN13485(quality management system) and IEC/EN 60601-1(electrical safety) as a wayof specifying how to handle development of a medical device regarding these requirements.[45], [46]

"For devices which incorporate software or which are medical software in them-selves, the software must be validated according to the state of the art taking intoaccount the principles of development lifecycle, risk management, validation andverification" Section 9, European Commission Directive 93/42/EEC [47]

A.4.1 Software Requirements

As medical software becomes more and more advanced, the need for regulations of how theseshould be treated increases. To simplify the ability to ensure the quality and promote safedevelopment of medical device software, the new harmonized standard CEI/IEC 62304 hasbeen developed.[45]

The CEI/IEC 62304 provides a lot of requirements to be fulfilled in order for a developmentprocess to be regarded as safe. The standard specifies the need for a risk management sys-tem(ISO 14971) and a quality management system(ISO 13485).[45], [46]

A.4.1.1 Software Development Life Cycle

The specific requirements for a certain software varies depending on the safety classificationof the software. The safety classification depends on the possible side effect of a error in thesoftware.[45] A medical device can be classified as either I, II or III(I being least risk) in theEU classification system which is equivalent to the FDA classes A, B and C. It is recommendedthat medical software is classified as at least B(II)[46]. Chapter 5 of the CEI/IEC 62304 setsa couple of requirements for class B(II) and C(III) medical software.[45], [46]

• Development Planning a plan is required the extent depends on class B or C.

• Requirements Analysis has to be performed and documented.

• Architectural Design general needed for class B, needs to be specified on unit levelfor class C.

• Detailed Design only required for class C.

• Unit implementation and verification all units needs to be documented and alsounit tested.

• Integration and integration testing needs to be implemented fully.

• System testing required.

• Release documentation regarding software anomalies as well as operator usage andhuman factors.

A.4.1.2 Risk Management Process

For all class B and C devices chapter 7,8,9 of the CEI/IEC 62304 specifies the need of arisk management process. Which is a strategy on how to eliminate risks and how to resolvelater problems with the software. The risk management system is usually adopted from ISO14791. A correct risk management process includes a lot of control measures to ensure thatthe software can work safely. The need for proper documentation is high since documentationis regarded as a way for a third person to review whether all risks have been considered.[45],[46]

A.4.2 Software of Unknown Provenance

Software of Unknown Provenance(SOUP) is a term used for software lacking one or moreimportant parts needed for certification. The SOUP definition does not say anything aboutthe quality of the software and it can work correctly, however there is no way of being surethat the software is working correctly. SOUP can eventually turn into a medical device if theappropriate steps are taken regarding Software Development Life Cycle and Risk ManagementProcess.[46]

TRITA 2016:10

www.kth.se