1 Introduction
Globally,
cardiovascular diseases (
CVD) are the most prevailing diseases causing 17.9 million deaths (nearly 31% of all global deaths) in the year 2016 alone [
50]. Amongst
cardiovascular diseases (CVD), cardiac arrhythmias are widespread and affect over four million people in the United States, costing up to $67.7 billion annually [
58]. Cardiac arrhythmias such as
atrial fibrillation (
AF) and Atrial Flutter are the most common causes of heart failure, hospitalization, thromboembolic events, and death [
11,
14]. Nearly 30% of patients with
atrial fibrillation (AF) are unaware of their diagnosis [
19]. Therefore, early diagnosis and treatment of such arrhythmias is important to provide timely healthcare and prevent life threatening conditions [
26]. Moreover, CVD are chronic diseases, and the provision of chronic care in CVD patients does not reach quality standards in about 50% of cases, which has significant consequences for both patients and society [
45]. To meet the demand for high-quality care based on evidence-based principles, organizational care models such as the
Chronic Care Model (
CCM) [
62] have been proposed. Ambulatory technology for continuous CVD monitoring is seen as an essential means for improving chronic care outcome [
22].
1.1 Traditional Arrhythmia Screen Process
AF and other heart rhythm disorders are diagnosed based on ECG analysis. The current practice of arrhythmias diagnosis employs a 6 or 4-channel Holter monitor
1 and records ECG data from the patients, typically for 24–48 hrs. During this period, the patient is instructed to maintain a diary for keeping track of any symptoms suspected to be related to arrhythmia (e.g., palpitation, dizziness, and chest pain). Figure
1 shows the typical workflow of the traditional home-based ECG Holter monitoring. When the recording is complete, the patient-reported diary and ECG recordings from the Holter monitor are examined by a trained Holter nurse or a cardiologist. This method of Holter monitoring is subjected to many limitations. For instance, when arrhythmias are sporadic, it may not be easy to detect them in just 24–48 hours of Holter monitoring. Long-term ambulatory ECG under the free-living condition is limited by the Holter device’s battery life and the need for turn-over of the devices to examine other patients. Even with seven-day Holter monitoring, about 30 percent of episodes are missed [
33]. Implanted pacemakers provide an alternative way of collecting long term ECG for arrhythmia analysis, but they are invasive. Similarly, implantable loop recorders can also sense arrhythmias for very prolonged periods (years). However, compared to continuous Holter monitoring, their capacity to effectively detect arrhythmia is limited due to their dependence on their algorithm and limited memory capacity [
20,
27,
61]. Recent advances in wearable and
mobile health (
mHealth) technologies; however, have made it possible to collect long-term ECG in a non-invasive way [
63], and studies [
23,
46] have shown that they are cost-effective for arrhythmia diagnosis and management.
1.2 Challenges in Ambulatory ECG Monitoring
Although longitudinal ambulatory ECG monitoring under natural settings using wired Holter monitors are useful for improving arrhythmia screening, it has a set of challenges.
1.2.1 Arrhythmia Misinterpretation Due to the Lack of Contextual Information.
When recording long-term ECG under free-living conditions, many motion artifacts and anomalies are added to the ECG signal. These artifacts mimic arrhythmias [
44], which impacts both manual and computer-aided automated arrhythmia diagnostic accuracy, resulting in more false positive and false negative detections. A recent smartwatch-based arrhythmia detection study conducted by Dörr et al. [
16] reported that factors such as movement artifacts and poor signal quality adversely affected the diagnostic performance of arrhythmia detection algorithms when applied to ambulatory ECG.
Moreover, the lack of knowledge about the context in which the ECG was recorded can lead to misinterpretation and misclassification of heart arrhythmias [
2,
12]. Dinakarrao et al. [
15] recently reviewed the trends and techniques of computer-aided arrhythmia diagnosis and highlighted that ECG analysis independent of the patients’ physical condition and context (such as activities, place, and food intake) could induce misinterpretation and misclassification of arrhythmias, which is likely to multiply manifold when dealing with long term ECG recordings from the free-living condition, due to a number of confounding artifacts.
1.2.2 Lack of User Engagement in Longitudinal ECG Collection.
In longitudinal home-based ECG monitoring for arrhythmia screening, patients need to be active participants. However, previous research have shown that sustained patient engagement is a major barrier in collecting quality ambulatory ECG [
53]. In addition, the use of traditional wired Holter monitors for longitudinal ECG collection under free-living conditions is very inefficient as they are bulky in size [
32] and do not provide feedback for patient engagement during the process, and hence remains a “black box” to the patient.
1.2.3 Poor Signal Quality.
In long-term ambulatory ECG collection, it is quite common that electrodes become non-adhesive over time resulting in poor ECG signals. While some Holter monitors provide alarms to the patient on poor signal quality, patients are not always able to identify and take corrective measures to fix or change the electrodes, which results in noisy or unusable ECG data. Additionally, the motion artifacts during various activities under free-living conditions affect the signal quality [
51].
1.2.4 Recall Bias on Patient’s Self-reported Symptoms and Events.
The quality, usefulness, and reliability of patient-reported data without a full understanding of the patient’s context have been a major concern in clinical practice [
64]. As illustrated in Figure
1, patients are asked to keep a diary of any cardio-related symptoms (e.g., dizziness, palpation, and shortness of breathing) during ambulatory Holter monitoring. This diary is typically paper-based. The cardiologist use the information in this diary during ECG analysis to map symptoms noted in the diary with the ECG recording, in order to find any occurrence of arrhythmias. This paper-based diary suffers from recall bias as patients do not always carry it with them and have to rely on their memory when filling in the diary later. Moreover, the timing noted in the diary is often wrong or very imprecise. This lack of synchronization between the timestamp of the patient-reported symptoms with the ECG signal’s timestamp makes it difficult for the cardiologist to map the symptoms to the corresponding ECG during analysis. This recall bias on patient-reported symptoms gets multiplied manifold when collecting long term ECG in free-living conditions.
1.3 Context-aware ECG Monitoring Under Free-living Conditions
To address the above-mentioned challenges in longitudinal arrhythmia screening, this article presents the design, implementation, and usability and feasibility evaluation of
mCardia, which is a context-aware ECG collection system designed to be used under free-living conditions. In contrast to conventional ECG monitoring,
mCardia provides means to collect contextual information such as activities, sleep quantity and quality, body position (sleeping left/right/supine), patient-reported abnormal events (e.g., dizziness, palpitation) and their duration, food intake, and maps them with the raw ECG recordings (see Figure
2). This contextual information can help cardiologists reducing misinterpretation and misclassification of events due to many confounding artifacts when assessing long-term ECG data for arrhythmia screening. In addition, these contextual features associated with the raw ECG data can be utilized as input to machine-learning algorithms for reducing the number of false positives in automatic arrhythmia analysis of ambulatory ECG. In addition,
mCardia can improve doctor and patient communication in a chronic care model.
In summary, the contribution of this work is in (1) identifying relevant contextual data that can help in improving arrhythmia diagnosis, (2) the design and implementation of the mCardia system and its device-independent plugin-based software architecture, which makes it easy to integrate with other ECG devices, and (3) demonstrating the usability and feasibility of such a system in longitudinal arrhythmia screening via field deployment and two case studies.
The remainder of this article consists of eight sections. Section
2 describes related work. Section
3 outlines the design process and the final design of
mCardia. Thereafter Section
4 describes the
mCardia system architecture and implementation. Sections
5 and
6 describe the usability and clinical feasibility study and its results. Section
7 discusses the obtained results and Section
8 lists the limitations. Section
9 concludes the article.
3 Research Methods
The design of the
mCardia system followed a
user-centered design (
UCD) approach [
24] and applied the
patient-clinician-designer (
PCD) framework [
43]. This research method seeks to find a good design compromise by considering different, and sometimes conflicting, concerns from the perspective of three stakeholder groups; the patient, the clinician, and the designer. The
patient-clinician-designer (PCD) framework provides a structured process for mediating co-design activities to find appropriate design solutions. In total, the design activities spanned 16 months (April 2018 to July 2019) and involved 14 participants; 6 patients, 4 clinicians (3 cardiologists (MD) and 1 nurse), and 4 designers.
The entire design process involved clinicians affiliated with a department of cardiology at a high-volume Danish University Hospital, in Copenhagen. Patients were also recruited from this department. Figure
3 illustrates the timeline of the design process and its main activities, which involved identifying the context of use, specifying requirements, and two iterations of design and evaluation.
3.1 Identify the Context of Use
In this phase, the design involved a group of clinicians including a cardiologist, a nurse, and a medical intern in the department of cardiology, and a group of three patients.
To identify the clinicians’ needs and context of use of the system, we conducted several design meetings and workshops focusing on designing three main parts of the system: (a) What data to collect, including cardiovascular data (e.g., ECG and heart rate (HR)), contextual data (e.g., physical activity and step count), self-reported symptoms (e.g., feeling dizzy or experiencing racing heartbeats), and self-reported lifestyle data (e.g., information on sleep and eating). (b) The user experience, including creating the user experience (UX) design for how to use and mount the ECG device, how to pair it with the phone, how to input data on the phone, how data is visualized, and how to navigate between different parts of the app. (c) Using the data in clinical practice, including understanding how the contextual and self-reported data can improve arrhythmia screening and diagnosis and how data can be mapped and visualized. Meeting minutes were noted and circulated to the participants from each meetings.
In parallel to the design workshops, we conducted an observational field study of the current Holter monitoring process (Figure
1) in the hospital’s outpatient clinic. This study focused on observing and understanding the current process of preparing and setting up a patient for Holter monitoring, including how the device was introduced and mounted on patients, as well as getting the device and data back from the patient. The study also observed the process of analyzing the ECG data and the paper-based diaries collected from the patients, and how they were analyzed in the current software systems. Detailed notes were taken throughout this observational study. Pictures were taken and the audio was recorded, while the nurse analyzed the ECG data following a think-aloud protocol.
To understand the patients’ needs and context of use of the system, we involved and interviewed three patients (P1: M/78, P2: F/73, P3: F/25), who had been subject to traditional Holter monitoring. The patients were involved in the study outside the cardiology department, when they finished their Holter monitoring, and returned to the outpatient clinic. Open-ended interviews were conducted that focused on their experience using the traditional Holter monitoring setup. Notes were taken during the interviews.
3.2 Requirements Specification
Based on the first phase of the project, a comprehensive list of requirements was collected and documented in a
requirement analysis document (
RAD) [
38]. In summary, these requirements are:
–
User engagement in data collection: In terms of the user experience, the main concern of both patients and clinicians was the collection and mapping of self-reported symptoms and activities. Traditional Holter monitoring typically involves collection of self-reported symptoms and activities on paper-based diaries filled in by the patient. Later the clinicians need to map this to the ECG recordings. Clinicians stated that this process was cumbersome and the data was not valid, since the article diaries suffered from many flaws including missing data, incomplete data, and recall bias. All the patients agreed that it would be much easier for them to record the symptoms and activities in a smartphone app. For example, P1 only entered activities such as cycling, running, and so on, at the end of day and often forgot this, and P2 did not record anything in the article diary. P3 explained that she took notes on her smartphone and then had to manually add this to the article diary at the end of the day. Patients also reported that it was difficult to push the event marker button on the Holter device, since it was hard to locate underneath clothes.
Therefore, the requirement was to provide better methods for collecting self-reported symptoms and activities, and automatically map these with the timeline of the ECG recording.
–
Collect contextual information relevant for arrhythmia screening: Clinicians emphasized the value of contextual information such as heart rate (HR), heart rate variability (HRV), sleep, step counts, metabolic (MET) level, self-reported symptoms, symptom duration, and patients’ activity during the symptom in order to better interpret the ECG data. Patients were willing to provide these information as long as they are informed about what data is being collected and how it is used for the diagnosis and treatment purposes. Therefore, the requirement was to collect a wide set of contextual information about the patient’s conditions, activities, and where-abouts, by implementing ecologically momentary assessment (EMA) approach as well as by collecting data automatically from the sensors on the ECG device and the smartphone.
–
System feedback: The clinicians opposed the idea of providing visual feedback on physiological data to the patient. They argued that the feedback might cause unnecessary concerns and overwhelm the clinicians with calls from worried patients. Furthermore, clinicians asserted that providing visual feedback of the cardiovascular data to the patients might not be meaningful due to the complex nature of the data, which patients might not understand. On the other side, all the patients were quite enthusiastic about being able to see their own ECG data and welcomed any feedback that the system can provide about their heart condition. P1 said that he would be interested in seeing what the data looks like. He would also like to get feedback from the app, but he would see the cardiologist for a diagnosis (if any). P2 argued that she would like to get some feedbacks, but that she would call the clinician if she suspected something to be wrong. P3, who had an anxiety disorder, argued that the feedback from the system could be helpful, especially for the patients with anxiety. She argued that; “it is better to know if your heart is normal than not knowing anything”. Using the PCD approach, we found a compromise between these conflicting requirements and came up with a design requirement that the system should not provide any system-generated feedback that might worry the patient (such as automatic detection of AF), and at the same time, provide an overall visualization of selected data items.
–
Technical requirements: As ECG collection technology is evolving rapidly, a core technical requirement was to make the mCardia software architecture open and extensible so it could integrate with other ECG devices, which may be introduced in the future. Another requirement was to implement the collection of contextual data using a suitable mobile sensing framework, which could be configured to gather different types of context information. Such a generic mobile and wearable sensing framework can handle the optimization of sensing and use of resources on the phone, thereby alleviating
mCardia from handling such low-level sensing issues [
35]. The selection of the ECG device should take into consideration technical aspects such as battery life, comfort of long-term wearing, data buffering, and storing capacity, availability of an
application programmer interface (
API) for integration, the resolution of the ECG recording, and sampling frequency.
3.3 System Design
Based on the requirement specifications, a
minimum viable product (
MVP) focusing on three main features was outlined: (i) CVD data collection from a wearable ECG device, (ii) visualization of the data in the app, and (iii) collection of symptoms as reported by the patients. The main purpose of the system was to support longitudinal, ambulatory collection of ECG, contextual, and patient-reported data. Since no cardiologists would oversee the patient’s use of the system, the system was not designed for acute symptoms identification or real-time monitoring. For the
minimum viable product (MVP), the Movisens “EcgMove4” ECG device was chosen due to its availability, its high-quality data collection features, its connectivity, its open
application programmer interface (API), and its proven accuracy in collection of ECG data [
4]. The EcgMove4 records ECG, HR,
heart rate variability (HRV), body position, step counts, and
metabolic (MET) level, and allows patients to mark an event by double-tapping the device. The device can send data to a smartphone using
Bluetooth low energy (
BTLE). The system was designed and implemented during two major iterations.
3.3.1 Iteration 1.
Initially, the overall user flow in the app was designed (Figure
4) with a set of mock-up designs for each screen. The first design iteration focused on the “Home” and “Events” screens in the app. Figure
5 shows the “Home” screen. This is where all data is visualized and where the patient can get an overview. The overall design rationale of this screen is to provide an overview of relevant CVD physiological parameters, associated context information, and self-reported “events” on a daily basis. This 24 hours overview is designed to be simple, aesthetically pleasing, and informative. Therefore, it only shows selected data items that are most relevant for the patients to follow, namely; HR, HRV, sleep, active time, step counts, MET levels, and events. Other contextual and physiological data that is collected (e.g., raw ECG and accelerometer data, food-intake, body position) is not visualized.
An event can be reported in the system by pressing the plus (+) button or by double-tapping the ECG device. Event details are reported via the “Event Details” screen (Figure
6(a)), which allows the patient to self-report symptoms, symptom duration, activity while the symptoms occurred, and a free-text note. The self-reported symptoms in the “Event Details” include common symptoms such as palpitations, heartburn, shortness of breath, chest pain, sweating, and dizziness. Furthermore, the free-text note was explicitly meant for providing additional details and describing any unusual symptoms outside of the commonly occurring symptoms. The “Events” screen (Figure
6(b)) lists the events reported by the patient, including both those entered using the plus button and the ones originating from a double-tap on the device. Events reported by a double-tap on the device is listed as “
Missing symptoms”, and the user can select this, and fill in the details on the details screen.
The initial prototype of the app was evaluated by the clinicians. Semi-structured interviews were used to assess the key aspects regarding relevance of the data collection and visualization. Clinicians liked the fact that the app does not provide any system generated feedback and agreed that the data visualized in the app is informative and that patients might be able to understand them. The feedback from the clinicians helped improve the overall design of the system, including, for example, how event details should be specified by the patient and the data visualization could be improved. The evaluation also revealed that some data were missing. For example, the daily intake of meals and beverages can impact hearth rhythms.
During this iteration we also made a few technical tests of the Movisens EcgMove4 device, including comparing the quality of the ECG recording quality with a traditional ECG Holter monitor over a two hours recording.
All comments and feedback were analyzed and consolidated during the next design iteration.
3.3.2 Iteration 2.
Based on the feedback from the first iteration, an additional screen named “Daily Info” (Figure
6(c)) was added. This page collects self-reported data on stress level, sleep quality, and dietary details like the timing and size of breakfast, lunch, and dinner. Finally, a set of introductory screens were added, which provide information to the patient on the first time the app is installed and used (see Figure
4). These screens include; (i) A set of informed consent screens, where the patient is informed about the purpose of the app and the study and can sign the consent form; (ii) A screen for collection of demographic data; (iii) A screen where the user grants permission to collect data from the phone (e.g., location data); (iv) A screen providing instruction for use; and (v) A screen instructing the patient on how to mount the ECG device on their chest and pair it with the phone.
Then the system was evaluated by three patients (P4: M/55; P5: F/60; and P6: M/70) who used it for 24–72 hours on their own. Each patient was interviewed after using the system. The overall design and core features were well received. Specifically, patients stated that the visualization of the data on the app was helpful to see if the system was working. Patients argued that the system and continuous visualization increased their awareness of their health. For example, P5 said that the “spikes” (HR and HRV) on the app was more interesting and informative than the heart rate data displayed in the Fitbit tracker they used. When asked how the visualization was informative to them, they said that the
mCardia visualization provided them with an easy-to-understand, 24-hour visualization of when their HR/HRV was in or out of the range. The patients also provided input for improvements of the UI design of the app. For example, they wanted to be able to navigate back in time and see data from previous days, and they had suggestions for improving the legends. All these issues were incorporated into the final UI design as shown in Figures
5 and
6.
4 Mcardia System Implementation
Figure
7 shows the overall software architecture of the
mCardia mobile app, which runs on the patient’s smartphone and collects passive and active contextual data. The
mCardia app consists of a set of dedicated UI screens (marked red in Figure
7), which implement the flow in Figure
4 and the UI design in Figures
5 and
6. mCardia is build using two frameworks; the
CARP Mobile Sensing (
CAMS) framework [
7,
8] and the Research Package framework [
28], which in turn consist of a number of sub-components (all marked in green in Figure
7).
CARP Mobile Sensing (CAMS) is a cross platform and extensible framework for implementing mobile sensing apps and comes with a long list of options for data collection, data management, data anonymization, power (battery) optimization, and data upload. All data collection and data management in
mCardia are handled by CAMS. The Research Package handles the informed consent flow, displays information about the study to the user, and asks for a signature.
The data sampling is configured as a “Study” script in CAMS and handed over to the Study Controller, which is then responsible for collecting and transforming the data according to the study specification. In mCardia, the data is stored in the CACHET Research Platform (CARP), a cloud-based infrastructure for managing and analysing mobile health (mHealth) data. The CARPDataManager is responsible for uploading data to CACHET Research Platform (CARP).
A set of sampling packages are registered with CAMS’s study script, which are responsible for handling the data sampling. For example, all the contextual data collection (location, activity, and weather—see Table
1) is done via the
ContextPackage. Similarly, step counts from the pedometer sensor in the smartphone are collected via the
SensorPackage. Each sampling package encapsulated access to the
operating system (
OS) sensors and typically uses one or more Flutter plugins to access the
operating system (OS) level sensors.
Likewise, the integration to the ECG device (Movisens EcgMove4) in
mCardia was implemented by creating a
MovisensPackage [
36], which use a
Movisens Flutter plugin [
37] to access the native Movisens API (all marked purple in Figure
7) The Movisens API connects to the EcgMove4 device via
Bluetooth low energy (BTLE). But due to the extensible plugin architecture of CAMS, any new ECG device can be used in the system by creating a device-specific sampling package and registering it with CAMS, without changing anything in the app itself.
4.1 ECG Sensor Data Management and Synchronization
The Movisens EcgMove4 device is capable of recording continuous ambulatory ECG with adhesive electrodes or a dry electrode textile chest belt; hence, avoiding the need for cables. In addition, it has on-board 3D accelerometer, gyroscope, barometric air pressure, and temperature sensors. Table
1 lists all the data types provided by the sensors, along with their sampling frequencies.
The Movisens device supports the “live” and “live + buffed” modes to communicate with these on-board sensors. In “live” mode, the sensor signal can be activated via a BTLE GATT notification, and if a sensor is not connected to a receiving device, then data are discarded. Therefore, this mode is not suitable for longitudinal data collection, where device disconnection is a very common scenario. For this reason, mCardia utilizes the “live + buffer” mode in which the device’s signals are activated via GATT indication. As long as the mCardia app remains connected, the device transmits data, and when disconnected, the data are buffered. It has a maximum buffering capacity of one day. On re-connection, the device sends the buffered data sequentially until all data are transmitted (or the connection is terminated).
The Movisens device records a one-lead 12-bit resolution ECG at a sampling frequency of 1,024 Hz. The other sensors, like the 3D accelerometer and gyroscope sensors, are sampled at 64 Hz. In “live” mode, the delay between measurement and the transmission of heart rate, heart rate variability, step counts, body position, and metabolic levels over BTLE is 70, 94, 94, 94, and 94 seconds, respectively. Due to the high resolution and sampling frequency, the raw ECG recordings are not transmitted via BTLE for power saving reason. By default, all data are also stored in device’s 4GB internal memory. It has a capacity of storing 14 days of raw ECG data. This ECG data are extracted manually by connecting the device to a PC via USB and then uploaded to the CARP cloud server, where the ECG and the other contextual data (collected via smartphone) are synchronized.
4.2 Data Visualization and User Information
mCardia visualizes data in real time as per the sampling frequencies in Table
1. Data visualization UI elements listen to the CAMS
StudyController event stream, which broadcasts all data collected in real time. Data is not stored locally but uploaded directly to CARP. If the user wants to navigate back in time, data for a day is fetched from CARP and visualized. Sedentary behavior and active times are calculated based on the MET level data from the Movisens device. Sleep is calculated once per day based on body position, heart rate, and other sensor data from the phone.
When the app is installed and used for the first time, it provides legal and privacy information to the user and shows an informed consent form which the patient has to sign on the smartphone display, which is then stored in CARP. Upon installation, mCardia asks for the patients’ demographic information, including gender, age, height, weight, and sensor location. The Movisens device uses this information for personalizing the computation of MET level, energy expenditure, and so on. Since mCardia is designed to be used in an ambulatory setting (e.g., at home) for longitudinal data collection, the patient needs to understand how to set up and take care of the system. For this purpose, mCardia includes an elaborate tutorial that explains; (i) how to place the sensor and electrodes properly, (ii) how to clean the skin before placing the electrodes, and (iii) how to register an event by double-taping the sensor and annotate event in the app.
5 Feasibility Study of Mcardia
Klasnja et al. [
34] recommended that in the early phase of design or evaluation of novel health technologies
“a deep understanding of the how and why of the system use by its target users should be a central goal for evaluations of systems
”. Therefore, adhering to the best practices in health technology design research, a single-arm feasibility study of
mCardia was carried out to obtain a comprehensive understanding of its usability and feasibility under free-living conditions. We applied the
CACHET Unified Methodology for Assessment of Clinical Feasibility (
CUMACF) [
5,
9] method, which is an adoption from the
Post Study System Usability Questionnaire (
PSSUQ) [
39] scale, Behavior Change Wheel Methodology [
49], and
Unified Theory of Acceptance and Use of Technology (
UTAUT) [
60] for assessing the user’s intention for future acceptance of the technology. For a more comprehensive understanding, this was followed by the post-study semi-structured interviews. All the
CACHET Unified Methodology for Assessment of Clinical Feasibility (CUMACF) questions [
5] used in this study are available in Appendix A (Table
5). Specifically, the following three aspects of
mCardia system were investigated:
–
Usability evaluation, which includes perceived user engagement, usefulness, and usability of mCardia in longitudinal ECG data collection.
–
Technical robustness and feasibility of mCardia.
–
Clinical usefulness of contextual data in the arrhythmia screening process.
5.1 Recruitment
Participants were recruited from Denmark and India. In Denmark, the study was excepted for ethical approval by the Danish research ethics committee (Journal-nr.: H-19071015). In India, ethical approval for running the study was obtained from the institutional review board (IRB) of our collaborator institute Mahatma Gandhi University of Medical Sciences & Technology (MGUMST), Jaipur.
In India, participants were recruited during their outpatient clinic visits at MGUMST’s heart arrhythmia clinic. Likewise, in Denmark, participants were recruited by invitations and announcements outside the outpatient clinic. It was made clear in the recruitment material and in the talks with participants that data collected in the study would be used for assessing the technical feasibility of the technology, and not for clinical assessment or treatment. The study participant received a copy of the Q&A document describing the purpose of the study and how the mCardia system worked. Inclusion criteria were; (i) Previously undiagnosed individuals interested in heart arrhythmia screening; (ii) Individuals who had already been diagnosed with AF and interested in tracking AF symptoms; (iii) Comfortable in using smartphone apps and wearables, or have a caretaker or family member who can help them in using mCardia; (iv) Willing to use mCardia for a minimum of two weeks. We used a rolling recruitment strategy for four months. A total of 33 participants were interested and met the inclusion criteria. All the participants signed the informed consent in the mCardia app.
5.2 Procedures
The study was divided into three phases; an orientation meeting, the ambulatory use of mCardia, and an end meeting. At the orientation meeting, a kit was provided to the study participant, containing a single-channel Movisens ECG device, a phone (if they needed), charging cables, and a user manual explaining how mCardia and the Movisens ECG device should be used. Participants were asked to sign a consent form in the mCardia app and provide some details regarding demography, medical history related to heart diseases, medication, and previous ECG monitoring experience. Besides, they were instructed on how to use the app and take care of the ECG device (charging, putting on, and taking off electrodes). We explained what constituted an “Event” and demonstrated how to report such an event when they experience any unusual symptoms during the ECG recording period. In addition, they were also instructed to fill in the self-reports on food consumption, self-perceived stress, and sleep quality in the mCardia app on a daily basis. At the meeting, the patient was able to use mCardia and tried to enter events and other self-reported data under our guidance. Participants were asked to continuously wear the ECG device for two weeks (or longer if they wanted to). At the end of the study period, participants were asked to answer the CUMACF questionnaire to evaluate the usefulness and usability of mCardia. Based on the participant’s response to these questioners, we did a semi-structured qualitative interview for in-depth understanding of the experience in using mCardia.
6 Results
Out of 33 recruited participants, nine dropped out of the study and did not finish the minimum two-week study period. The dropout reasons included; sudden deterioration of their health causing hospitalization (
\(N=2\)), skin allergy/irritability (
\(N=4\)) caused by the wet ECG electrode, and travel constraint (
\(N=3\)). Thus, we present the usability and technical feasibility of
mCardia based on the data collected from 24 participants (8 females, 16 males, the average age of M = 58.79, SD = 10.11) over two weeks. Table
2 shows the participants’ demographics. Except for one participant (who used
mCardia for over a month), all participants contributed equally (2 weeks) to the quantitative and qualitative data. All participants or their caretakers in this study reported owning a smartphone. However, we provided an Android phone to four participants as the
mCardia was not compatible with their phone’s older Android version. Total ten (
\(N=10\)), participants had previous experience of short-term (1–2 days) ECG screening using a traditional wired Holter monitor at home or in a hospital. In addition, 9 out of 24 participants were assisted by a family member or caretaker at home during the two-week study period.
6.1 User Experience
6.1.1 Perceived Usefulness and Usability.
Figure
8 shows the results of the CUMACF questions for perceived usefulness and usability. Overall 96% of the study participants responded very positively about the design and usability of
mCardia (Q1). They found the app to be unobtrusive and non-interfering in their day-to-day tasks. Nearly 95% of the participants reported that keeping track of daily activity and unusual symptoms can help them understand their symptoms and health better (Q5). Besides 78% found that
mCardia could help increase the quality of communication with the doctor (Q3) and reduce recall bias (Q4) in home-based monitoring. Especially if they were to use the system for longitudinal arrhythmia screening. One participant who had previously used traditional wired Holder monitoring remarked that:
The big wired Holter monitor was just a black box for me, and it was not very comfortable to sleep or work while wearing it. Also, I was not strict about keeping the symptoms diary, as I would not keep the diary and a pen with me at all time. [P23]
In the “Effort Expectancy” assessment, nearly 75% of the participants found the help, error messages, guidelines, and so on, offered in mCardia adequate (Q11). In response to the question whether mCardia has all the functionality expected (Q14), around 50% of the participants responded neutrally, whereas, 9% showed disagreement. During the post-study interview, we found that participants wanted support for medication tracking and reminders in mCardia, since keeping track of their medication was core to their treatment. Finally, when asking about “Facilitating Conditions” most participants were positive. They reported that they had the resources needed (i.e smartphone) (Q17, N = 95.8%) and assessed themselves to be skillful in the use of mCardia (Q18, N = 95%). Besides, only 8.3% reported that they would require a dedicated person to assist (Q19).
Overall, the mCardia was reported as easy to use, with high user satisfaction, especially amongst the participants who have had previous experience with traditional wired Holter monitoring; 8 of 10 these users were very satisfied.
6.1.2 Engagement as Time Spent.
The amount of time spent on the mobile app is another indicator of user engagement. On average, participants spent 21 minutes interacting with mCardia daily. We found the use pattern for filling the details about recorded symptoms or events to be random. However, daily information such as stress level, sleep quality, and food intakes were mostly filled in once in the evening. Besides these two tasks, the majority of the participants routinely interacted with mCardia in the morning (to check night trends in heart rate) or after performing physical activities such as exercise, cycling, or a long walk. It should be noted that mCardia was not designed to maximize the time spent on the app. As one participant states in the post-study interview:
I might have spent more time in the app, if it had provided additional features such as medication tracking or recommendations. [P7]
However, based on the initial design phase, mCardia was designed mainly for brief sporadic use and not for medication management.
6.1.3 Events Recording and Phone-based Context Collection.
A total of
\(N=235\) events were created (either by taping on the Movisens device or on the phone), out of which nearly 60% were annotated, and the other 40% were either deleted or remained unfilled. Figure
9 shows the number of annotated and deleted/unfilled events per participant during the study. Among all the participants, the frequency of events created and deleted due to accidental taps on the ECG device was more on the initial few days and declined as the participants became more familiar with
mCardia.
6.2 Performance of Data Collection and its Impact on Usability
During the feasibility study over 8,064 hours of contextualized ECG data from 24 participants was collected. We performed an auto-correlation-based signal quality assessment of the collected ECG data to evaluate its usefulness for arrhythmia analysis. Nearly 89% of the collected ECG data was found to be suitable for arrhythmia analysis. The remaining 11% was not useful because the patient either forgot to put on the ECG device or the electrodes became nonadhesive and resulted in poor signal quality. We also found that the percentage of unusable data was slightly higher among the nine participants who were assisted by family members or caretakers. During the post-study interviews, we learned that when electrodes became nonadhesive, the patient would not realize this and replace them, unless told by a caretaker. The caretaker could spot missing HR and HRV data in the mCardia app. One caretaker recalled:
I would usually check and change the electrodes only when I found gaps in the HR or HRV data in the mCardia app’s circular wheel. [P3]
6.2.1 Yield.
Li et al. [
40] define “Yield” as “the fraction of the expected samples to the actual number of samples collected by the system” and argue that yield can serve as a proxy for determining engagement and user compliance. Following this definition, we define yield in
mCardia as the fraction of the expected samples of various data points such as HR, HRV, MET-level, and Daily Info that are successfully collected and stored in the cloud back-end. For instance, since HR, HRV, MET-level (corresponding to light, moderate, and vigorous activities), and steps are collected once per minute, 60 samples of them are expected in any given single hour. Similarly, Daily Info is collected once per day; therefore, the fraction of days in which we collected Daily Info data defines the Daily Info yield. Figure
10 shows the yield of HR, HRV, MET level, Step, and Daily Info for each participant. The median yield of Daily Info is 0.671, and only 57% of participants have Daily Info yield higher than 0.6. The MET-level median yield is 0.903, and nearly 88% of participants reaching yield more than 0.85. Similarly, the median yield for step is 0.902, and 81% of participants reaching yield more than .85. In contrast, the median yield of both HR and HRV is 0.79, which is lower than steps and MET-level, and only 41% and 37% of participants have HR and HRV yield higher than 0.85, respectively. The potential reasons for low HR and HRV yield include; (i) user not wearing the ECG device or wearing discharged device, (ii) non-adhesive of the ECG electrodes over time resulting in a noisy signal, and (iii) arrhythmia episodes in which the Movisens’ on-board algorithm is unable to correctly calculate HR and HRV.
6.3 Qualitative Data
To further understand the participants’ perspective, we conducted a post-study semi-structured interview of each participant and their caretaker. We employed an inductive approach [
59] for analyzing this interview data. As the focus of this study was on the feasibility and perceived usefulness of
mCardia, the following themes were in focus; (i) issues encountered, (ii) task suitability, and (iii) perceived usefulness.
6.3.1 Issues Encountered by Participants.
Table
4 lists the four main issues reported by the study participants during the post-study interview. One-fourth of the participants reported issues related to non-adhesiveness of wet ECG electrodes due to sweating or body movements during the night. This mainly happened when participants forgot to change the electrodes daily and continued using the same electrodes for more than 24 hours. A related issue is the skin discomfort or irritability which was reported by 20% of the participants—an issue that is well-known in long-term ECG monitoring [
47]. A third issue reported by 38% of the participants was the creation of “false events” due to accidental tapping on the ECG sensor. Such accidental taps typically happened when putting the device on or off for charging. Such taps resulted in creating false events in the
mCardia app and it annoyed the participants as they had to delete them manually in the app. One participant recalled:
For the first two days, when I pushed the ECG device hard in order to fit it into the charging tray, it added some events. When I saw these empty events later in the app, I was confused as I didn’t recall tapping on the device. [P10]
Finally, 20% of the participants reported that they kept wearing the ECG sensor even when its battery was completely discharged. Although the mCardia app displays the battery level of the sensor, the participants said that they did not notice it unless they explicitly opened the app and looked at the battery level. As explained by a participant:
If the app is closed and the device battery dies, I would not realize it. I [would] continue wearing it for hours until I opened the app and looked at the battery level. This happened several times in the last two weeks. [P17]
6.3.2 Task Suitability.
From the user’s point of view, the main task was to collect high-quality event information during ambulatory long-term use. Hence, we investigated the feasibility of phone-based event annotation as compared to the traditional paper-based diary. Compared to traditional paper-based event diaries, participants found the event creation and annotation in mCardia simple, clean, and very convenient. Interestingly, phone-based event annotation was most liked by participants (\(N=10\)) who previously have had the experience of traditional home-based Holter monitoring and paper-based event diaries. As explained by P20:
It is easier to note the symptoms on the mobile phone, since I carry it all the time. I do not have to remember and write it down in my [paper-based] event diary – especially, if I have to do it for many days or months. [P20]
6.3.3 Perceived Usefulness.
Although context-aware ECG monitoring via mCardia is primarily designed to help cardiologists in a more accurate and informed assessment of arrhythmias, we were also interested in the participants’ perceived usefulness of mCardia for managing their CVD health. In this regard, several participants or their caretakers described that they believed mCardia could be useful in two ways; (i) in better communicating their symptoms to the cardiologist, and (ii) to keep them aware about any unusual symptoms and the context in which they appear. For example, as explained by P2:
I think this clock overview is nice. I can see how my heartbeat changes when I am doing different activities. On two Fridays – when I had been playing basketball – I felt palpitations during the night and registered these events. It makes it easy to show them to the cardiologist and ask what happened at that time, and if it is related to playing sports. [P2]
6.4 Clinical Case Studies
The usefulness of context-aware ECG monitoring in arrhythmia screening can be demonstrated in two clinical cases based on data collected from the feasibility study—one focusing on tachycardia (high restring heart rate) and the other looking at palpitations.
6.4.1 Clinical Case #1: Tachycardia.
Tachycardia is the condition in which the heart rate exceeds the normal resting rate, which can be physiological or due to abnormal heart rhythm. The definition of tachycardia in adults is a resting HR above 100 BPM [
3]. Figure
11(a) and (b) shows a sudden increase in heart rate to over 100 BPM on two different occasions for the same patient (P12, female, 70 years). In Figure
11(b), contextual data reveals that the subject is not doing any physical activities during this time or even prior to the onset. During this period, the participant also added an event by tapping the device and provided some additional context that she was lying down after dinner and felt severe heartburn symptoms that lasted for around 20 minutes. This makes it a typical case of a
supraventricular tachycardia (
SVT) episode. On the other hand, Figure
11(a) although showing HR above 100 (at around 10–10:30 PM), contextual data shows that the patient is doing physical activity of jogging, walking, and running prior and during this period. Hence, in this scenario HR above 100 is not a case of
supraventricular tachycardia (SVT).
This case demonstrates that interpretation of ECG segments and HR is different depending on the context, and assessment in isolation could potentially lead to misdiagnosis. Thus, collection of contextual data in ambulatory ECG monitoring could enable faster and more accurate assessment of arrhythmias in both manual and computer-aided diagnosis of arrhythmia.
6.4.2 Clinical Case #2: Palpitations.
In this case, the patient was evaluated for annoying palpitations, and had known permanent atrial fibrillation. He referred palpitations during sleep that lasted 30 minutes. Figure
12(a) shows cases of mild rate changes whereas the accelerometer shows that patient is just turning in bed. At this point his doctor may hesitate to increase rate-lowering medications since the patient also referred dizziness when changing from laying down to standing position. In this context, Figure
12(b) helps to choose an adequate medicine adjustment since it is reassuring that there is an adequate chronotropic response when changing from laying in bed to walk, suggesting problem with ortostatic blood pressure changes. Furthermore, there are no cases of severe low rate. Hence, choice could be made for a rate-lowering medicine without blood-pressure lowering effect. This demonstrates that, in this case collection of contextual data not only helps in diagnosis but also in deciding on correct medication treatment.
7 Discussion
This study aimed at testing the feasibility and usability of mCardia for collecting context-aware ambulatory ECG for arrhythmia screening under free-living conditions. To this end, we need to ensure that mCardia meets the user experience and usability standards and keeps participants engaging as well as informed. The overall results of this feasibility study are encouraging. The findings indicated a good degree of usability, usefulness, and clinical applicability of mCardia. With the aim of replacing wired Holter monitors and paper-based diaries, it is particularly interesting to note that the quantitative results of usability and feasibility were more positive from the participants (\(N=10\)) who had previously used a traditional setup for home-based ECG monitoring. In this section, we discuss the patient’s perspective on the mCardia system, areas of improving it, and the use of contextual information in arrhythmia analysis.
7.1 Patient’s Perspective on mCardia
From the users’ perspective, three interesting findings emerged from the study, namely, that mCardia could improve event reporting practice, could improve patient-clinician communication, but that medication tracking was missing.
7.1.1 Improved Event Reporting Practice.
The ability to fill the details of the symptomatic events on the phone rather than a paper-based event diary was especially liked by the participants who previously had undergone 1–2 days ambulatory Holter monitoring at home. One participant noted that;
It was much easier to remember that I had tapped the device and had unusual symptoms by looking at the unfilled event log in the mCardia app. In my previous home Holter test, I rarely maintained the event diary, and even when I did the entries, it was with an approximate time. [P5]
Careful mapping of an event’s timestamp to the ECG timestamp is vital because—as shown in clinical case #2—only accurate mapping of these events helps in a better understanding of these unusual symptoms during ECG analysis. If relied on recall memory and proximate timestamp, these reported symptoms might not be reflected in corresponding ECG, which may cause ambiguity during analysis. By tapping the ECG device and using the phone to provide the details of the event significantly reduced recall bias in reporting events.
7.1.2 Improvement in Patient-clinician Communication.
As reported in the qualitative findings (Section
6.3), the patients argued that
mCardia has a strong potential to improve communication about their health condition to the doctor in a longitudinal home-based arrhythmia screening. In particular, the visualization of the daily overview of HR with the different activities and symptomatic events was considered motivating enough to keep using
mCardia for a longer period. Although participants asked if
mCardia could give them real-time feedback on arrhythmia, this feature was intentionally not part of the design. During the PCD design process, the doctors warned against such a feature. Current machine-learning algorithms for automatic arrhythmia detection are still in their infancy and mainly work on high-quality ECG recording done in the clinic under controlled conditions. Therefore, enabling real-time automatic arrhythmia detection on ambulatory ECG could result in false positives, causing anxiety, and unnecessary hospital visits. This problem has also been reported in several other studies involving short (30 sec) ECG, even in a low-risk healthy population [
31,
52].
Instead, mCardia can be seen as a tool for improving patient-clinician communication during the longitudinal arrhythmia screening period. On the one hand, it helps collect a much richer dataset for the clinician to improve clinical decision-making. On the other hand, it provides the patient with much better awareness and understanding of their disease symptoms and the relationship between behavior and their heart-related symptoms, without providing the diagnosis. Taken together, this can improve the dialogue between the patient and clinician.
7.1.3 Medication Tracking and Reminders.
In the CUMACF question no. 14 (“Q14: mCardia has all the functionalities that I expect it to have?”) received the a very negative response, with a majority of participants disagreeing or remaining neutral to this statement (see Figure
8). In the post-study interview, we learned that the majority of participants who disagreed to this statement wanted medication tracking and reminders to be part of
mCardia. This was especially highlighted by participants who suffered from several co-morbid chronic conditions. Even though medication tracking was discussed during the
mCardia design process, we decided not to include this since there are plenty of other apps available for this. However, the study showed that this might be important to
mCardia after all. Partly because the study showed that participants wanted this as an integrated feature in the same app. But more importantly, because medication tracking could help understand if there are any correlations between the medication dose and timing, and the occurrence of arrhythmia events or unusual symptoms experienced by participants. Furthermore, medication tracking could help in keeping participants more engaged in the data collection process.
7.2 Improvements to the mCardia System
While mCardia was widely accepted, we found inspiration for several areas of technical improvements concerning improving signal quality, keeping the ECG device charged, the prevention accidental event logging, and improvement of self-reported data.
7.2.1 Improving Signal Quality.
Proper attachment of the electrodes to the skin as well as changing them daily is key to quality transmission of the ECG signal. Support for continuous monitoring of signal quality could be added to mCardia, which could provide in-app notification if the signal quality remains weak for more than a certain period. Moreover, motion sensors, such as accelerometers, makes it possible to distinguish whether poor signal quality is due to motion artifacts or due to non-adhesiveness of the ECG electrode.
In this context, it is worth noticing that compared to others, the participants assisted by caretakers (N = 9) have a high percentage of unusable ECG data and low HR and HRV yield. The high percentage of unusable data is because caretakers would leave the phone with the patient and mainly check mCardia in the morning and evening. If electrodes become nonadhesive, caretakers would not realize this and replace them until they open the mCardia app on participant’s phones and see the missing data. To overcome this challenge, mCardia could also send a notification on signal quality to the caretaker’s phone.
Electrodes are also one of the common causes of skin discomfort and a major reason for participant dropout in ECG monitoring studies [
47]. Our study was not exempt from this. Although the participants were instructed to change the electrodes every day, some patients did not adhere to this instruction resulting in skin irritability and eventually dropping out of the study. One way to address this challenge could be to implement a daily notification in the app and alert the patient to change the electrodes. This feature could be combined with signal quality reporting.
7.2.2 Keeping the ECG Device Charged.
We found that although the battery level of the ECG device was displayed in the mCardia app, participants often forgot to charge the device. This could result in full discharge of the device and participants could end up wearing a discharged device for several hours. They would notice this only when they open the app. This was especially prevalent in the (\(N=9\)) participants who were assisted by a caretaker. This problem could be mitigated if mCardia notified the user or caretaker with an alert on low battery level, even if the app is closed. This can be done by server-sided push notification based on the last charging status of the ECG device and its discharge rate, which would work even if the mCardia app is closed or if the device becomes disconnected.
7.2.3 Preventing Accidental Event Logging.
Unintended logging of events due to accidental taps on the ECG device, especially while putting on or taking off the device to charge, was one of the main issues surfaced in qualitative analysis. Although detecting “accidental events” could be device-specific (Movisens in this case), they can be prevented by checking whether ECG electrodes are attached to the device or not. When the electrodes are not attached to the device, and tap on it should simply be discarded. In this way, new events will only be listed in the mCardia app when a participant is wearing the device and the recording is in progress.
7.2.4 Improving Reporting of Daily Info.
The information such as stress, sleep, and food intake provides important contextual and behavioral information that supplements the underline ECG data during arrhythmia analysis. However, the relatively low yield of Daily Info (c.f., Figure
10) suggests that participants were not motivated to enter these details on a daily basis. When asking about the reason for this low yield, we learned that participants could not see any direct value of this information for themselves. The design decision to collect this information was primarily focused on its importance for clinicians during ECG analysis. Hence, it seems important to feed this information back to the user as day-to-day educational information about the potential linkage between lifestyle and commonly known arrhythmia triggers.
7.3 Using Contextual Information in Arrhythmia Analysis
The two clinical cases presented in this study demonstrate the usefulness of contextual data in making more clinically informed decisions when analysing ambulatory ECG for arrhythmia diagnosis. For these case studies, the temporal alignment of ECG with the different contextual data was done manually. To take full advantage of these different contextual data, a fully automated system for temporal alignment, synchronization, and visualization of the context and ECG would be needed. Moreover, semi-automatic detection of potential arrhythmia onsets and offsets time would be needed to quickly analyze such a large amount of data.
In addition, contextual features can be used together with the ECG morphology to achieve personalization in algorithms for arrhythmia detection. Arrhythmia-provoking user-contexts and common symptoms at the onset of arrhythmias (as listed by Hansson et al. [
25]) can be utilized to build context-specific heuristics, which can help in reducing false alarms in computer-aided diagnosis of ambulatory ECG.
8 Limitations and Future Work
Our sample size is small, which might limit the ability to generalize the findings. Also, as there is no optimal length of the arrhythmia screening period and the study was focused more on technology demonstration or proof-of-concept rather than clinical outcomes, we kept the study period to a minimum of two weeks. However, it would be interesting to learn how the participant’s response, engagement, and usability behavior changes when they use mCardia for a much extended period (i.e., 2–4 months). More specifically, as the battery draining speed is known to affect the user experience and adhesion in any wearable-based longitudinal sensing. Therefore, its impact on mCardia’s usability needs to be investigated in a more long-term study.
In the next iteration, we would like to address the issue highlighted in this study namely: (1) provide alerts to users or caretakers on signal quality when electrodes become non-adhesive, (2) add medication tracking and reminders to increase user engagement, and (3) provide alerts to users when the ECG device battery needs charging, even while the mCardia app is closed or running in the background. The plan is to use and deploy
mCardia in a larger-scale clinical trial as part of the REAFEL project [
6] for diagnosis and management of AF in frail and elderly patients.
9 Conclusion
This article has described the design, technical implementation, and initial deployment of mCardia, a context-aware longitudinal ambulatory ECG collection system for cardiac arrhythmia screening. The primary contributions of the work are threefold. First, we have identified the relevant contextual information that can help improve arrhythmia screening when combined with ECG data. Second, we have presented the user experience (UX) design, software architecture, and technical implementation of a device-agnostic plugin-based mHealth application for collecting ECG with a broad spectrum of contextual and patient-reported data. Third, a single-arm feasibility study in a Danish and Indian setting demonstrated the usability and user acceptance of such technology for continuous ambulatory ECG monitoring for arrhythmia diagnosis. The mCardia system achieved high data yield, as well as high levels of patient compliance and acceptance. Via two clinical case studies, we also demonstrated how contextual information could help improve arrhythmia screening. As such, this article presents promising results in terms of the usability and feasibility of the mCardia system for longitudinal, ambulatory arrhythmia diagnosis, and monitoring under free-living conditions.
