Analysis and postprocessing of ECG or heart rate data from wearable devices beyond the proprietary cloud and app infrastructure of the vendors.

Background: The impact of medical-grade wearable electrocardiographic (ECG) recording technology is increasing rapidly. A wide range of different portable smartphone-connected ECG and heart rate trackers is available on the market. Smart ECG devices are especially valuable to monitor either supraventricular arrhythmias or prolonged QT intervals to avoid drug-induced life-threatening arrhythmias. However, frequent false alarms or false-positive arrhythmia results from wearable devices are unwanted. Therefore, for clinical evaluation, it should be possible to measure and evaluate the biosignals of the wearables independent of the manufacturer. Objective: Unlike radiological devices that do support the universal digital imaging and communications in medicine standard, these medical-grade devices do not yet support a secure standardized exchange pathway between sensors, smartphones/smartwatches, and end services such as cloud storage or universal Web-based application programming interface (API) access. Consequently, postprocessing of recorded ECGs or heart rate interval data requires a whole toolbox of customized software technologies. Methods/
Results: Various methods for measuring and analyzing nonstandardized ECG and heart rate data are proposed, including online measurement of ECG waveforms within a PDF, access to data using manufacturer-specific software development kits, and access to biosignals using modern Web APIs.
Conclusion: With the appropriate workaround, modern software technologies such as JavaScript and PHP allow health care providers and researchers to easily and instantly access necessary and important signal measurements on demand.

The impact of medical-grade wearable electrocardiographic (ECG) recording technology is increasing rapidly. A wide range of different portable smartphone-connected ECG and heart rate trackers is available on the market.

Wearable ECG and heart rate recording processes are mainly vendor proprietary and often undocumented black box algorithms.

Unlike radiological devices that do support the universal DICOM standard, these medical-grade devices do not yet support a secure standardized exchange pathway between sensors and the medical caregivers.

Access to raw data is limited but necessary for objective evaluation of the medical data derived from the devices, such as rhythm diagnoses or heart rate variability parameters.

To overcome the shortcomings of limited access to raw biosignals from proprietary m-health device-vendor data infrastructures, self-made software that uses software development kits, software libraries, or application programming interfaces can be used.

Standardized access to the raw data from wearables is a real need for the future.

Introduction

Currently, electrocardiograms (ECGs) can be recorded independently of health care professionals through wearable ECG sensors present in smartwatches or sensors that connect to smartphones or other devices (Figure 1).1, 2, 3, 4 The recorded ECG can be stored locally, forwarded by e-mail, or transferred to a cloud service. Heart rate measurements also can be measured from a wearable sensor attached to the wrist, the chest, or even the ear lobe.5, 6, 7 Unfortunately, these medical-grade, consumer-oriented devices are missing an interoperability data exchange standard. Digital Imaging and Communications in Medicine (DICOM) is one established interoperability standard for postprocessing of medical images and 12-lead ECG recordings,8, 9, 10 but the new wearable ECG and heart rate measurement devices do not yet support any universal data exchange format. Although there are other, standardized open or vendor-specific ECG formats such as SCP-ECG, DICOM, HL7 aECG, ISHNE, and MUSE-XML, none of these have been designed for continuous mobile health (m-health) biosignal data storage. Nonetheless, health care providers need standardized exchange formats to measure such ECGs on demand, including use in identifying the presence of arrhythmias. Moreover, repeated home measurement of QT-interval duration can be important for improving safety monitoring in drug-induced QT prolongation. Even the ECG definition of the new HL7 Fast Healthcare Interoperability Resources (FHIR) standard, is still in the “informative” development process, with continuous R-R interval measurements from heart rate wearables having no standardized export format. However, some current software libraries are very promising, depending on the device. For example, standardized generic attribute profile (GATT) Bluetooth low-energy (BLE) heart rate trackers allow easy access to continuous RR interval measurement for arrhythmia detection, heart rate variability measurements, and derived performance data. This paper therefore summarizes several state-of-the-art software methods to postprocess ECG and R-R interval data acquired from wearable consumer devices. To help eliminate common false-positive screening results from heart rate or ECG wearables, signal postprocessing is important. Recently, Dr J.P. Onnela form the Harvard Department of Biostatistics reported on his blog that exporting the same heart rate data from a wearable device twice does not give the same results when using different versions of the vendor’s software development kit (SDK). He suspects that this is due to changes in the heart rate variability algorithm of the SDK, effectively a black box using an undisclosed methodology. Therefore, for clinical evaluation it would be more optimal to measure and evaluate the biosignals of the wearables independent of the manufacturer.

Figure 1

Wearable electrocardiographic (ECG) recorders. From left to right: ECG watches: Samsung Galaxy Watch 3, FitBit Sense, and Withings ScanWatch with a medical graded oximeter for SpO2 measures. Right of the ScanWatch is the NextSENSE Pulse sensor 1-lead ECG recorder, which attaches to the chest by a belt or through electrodes. Displayed on the center smartphone is a wirelessly transmitted ECG signal, recorded with the Pulse sensor. Next are 2 different AliveCor Kardia devices: a 6-lead recorder—the KardiaMobile 6L (top), and a 1-lead recorder—the KardiaMobile (bottom). Right: Apple Watch with ECG recording capabilities displayed on a paired iPhone.

Methods and software solutions

Wearable ECG and heart rate recording processes are mainly vendor proprietary. Three different scenarios were covered in this research, as summarized in Figure 2. The 3 scenarios shown in Figure 2 might be used to overcome the shortcomings of limited access to raw biosignals from proprietary m-health device-vendor data infrastructures. In the first scenario, the vendor-proprietary application (APP) is used to handle ECG PDF recordings. In the second, the vendors’ APP and application programming interface (API) are used for consecutive postprocessing of the recorded ECGs and heart rate data with self-made software. In the third scenario, raw-data access is accomplished via a self-made acquisition and postprocessing software APP supported by SDKs, software libraries, or APIs provided by the vendors.

Figure 2

The 3 scenarios used in this research cover electrocardiographic (ECG) recordings to postprocessing of the ECG signals or R-R intervals. The first scenario uses the vendor-proprietary application (APP) with a self-made application programming interface (API) software to handle the ECG PDF recordings. The second scenario uses the vendor’s APP and API for consecutive postprocessing of raw ECG and R-R interval data with self-made software. The third scenario is based on raw-data access by a self-made acquisition and postprocessing software APP supported by software development kit (SDK), software library, or API provided by the vendors. HR = heart rate.

Scenario 1: Processing of PDF ECGs exported from proprietary vendor APPs with self-made software

If the PDF is the only available ECG data, special software tools are needed to find and measure the ECG complexes. Because direct access to the ECG waveform data is missing, using a PDF is considered a workaround. To be able to measure the ECG from smart devices, the patient must send the PDF of the ECG to the health care provider via e-mail or a permitted cloud gateway. It would be a clear advantage if the ECG PDF document could be encrypted before it is sent.

ECG QTc Calculator: Example of self-made software for PDF ECG postprocessing

Many devices such as KardiaMobile 6L (AliveCor, Mountain View, CA) and the Apple Watch (Apple, Cupertino, CA) are used for ECG monitoring. However, those devices currently only export PDF files. Sample recordings from such devices are shown in Figure 3. A general overview of the ECG QTc Calculator workflow process and the usage of different software tools is shown in Figure 4. The ECG QTc Calculator demonstrator tool is designed to accept any PDF containing ECG waveforms. Figure 5 shows the self-made demonstrator APP running in a Web browser for processing of uploaded ECG PDF files. The APP is designed such that physicians or their technicians can measure the QT intervals of the ECG lead on the PDF and calculate the corrected QT interval. The main software components of the QT-interval measurement program are based on JavaScript, HTML5, and PHP. The program written in JavaScript processes its data client-side. Therefore, data processing and measuring with JavaScript code running in a Web browser reduces the overhead of performing calculations on the server. All modern Web browsers support JavaScript and HTML5. The supporting software library to make calibrations and measurements on the PDF with the ECG lead is the PDF.js library. The PDF.js library is a general purpose, Web standards-based platform for parsing and rendering PDFs. After the physician receives the ECG recording as a PDF file, the following steps must be performed to ensure precise QT, QTc, and RR measurements. First, upload the ECG PDF recordings; second, choose a suitable scale to display the PDF; third, set calibration points between 2-second intervals; fourth, set the R1 point; fifth, set the R2 point; sixth, set Q-wave starting point; seventh, set T-wave end; and eighth, press calculate QT and QTc to determine R-R, QT, and QTc. In this demonstrator, we have adopted the Bazett formula (QTcB) and the Hodges formula (QTcH) to calculate the QTc interval.

Figure 3

Samples of electrocardiographic recordings (right) using the Apple Watch (top left) and KardiaMobile 6L (bottom left).

Figure 4

ECG QTc Calculator overview. From bottom left: The patient applies a mobile recording device to record the electrocardiographic (ECG) signal and the application (APP) sends the ECG as a PDF to the physician. The physician can then postprocess the ECG with ECG QTc Calculator to obtain the QT and QTc measurements.

Figure 5

Self-made demonstrator application (APP) running in a Web browser for processing of uploaded electrocardiographic (ECG) PDF files. The APP is designed for physicians to measure the QT intervals of the ECG lead on the PDF and calculate the corrected QT interval. QTcB = Bazett formula; QTcH = Hodges formula.

Scenario 2: Access to raw ECG signals or R-R interval data using the vendor-specific APP and API with self-made software for postprocessing

When the wearable device vendor offers access to the raw ECG waveforms or R-R interval data from the medical device data system (MDDS), the consumer (in this case the health care provider or the patient’s doctor) will have access to all recorded data. This means not only ECG raw data and its metadata but also complete demographic data. With security credentials and encryption keys, the data can be easily accessed through standard representational state transfer (REST) calls. The .Net C# REST Call code snippets in Supplemental Figure 1 show an example API call and the retrieved data after a successful REST GET request. An example of online documentation on how to access the related, full 300-Hz raw data ECG recording can be found within the Withings API documentation (available at http://developer.withings.com/oauth2/#operation/-heartv2-get). Figure 6 illustrates a comfortable workflow for the postprocessing of ECG data by API access and the measurement of the values in a JavaScript browser-hosted Web APP. Continuous one lead ECG is recorded with a BT ECG sensor from the chest. A smartphone APP displays the data and during recording uploads the data to the cloud-based medical device data system (Figure 6). When the physician needs to monitor QT-interval duration for QT safety, he or she can open a Web page and measure the recorded ECG with mouse-based calipers immediately after the ECG has been recorded anywhere in the world. The combination of modern HTML, JavaScript, CSS, and PHP allow one to write Web browser-based APPs to retrieve, measure, and store the data in a comfortable workflow process. After the measurement process, the data can be stored in a standardized medical format such as the HL7 Annotated ECG XML format required for Food and Drug Administration (FDA) drug studies or the HL7 FHIR format.

Figure 6

Continuous 1- lead ECG recorded with a Bluetooth electrocardiographic (ECG) sensor on the chest (top left). A smartphone application (APP) displays the data during recording (top middle) and uploads the data to the cloud-based medical device data system (topright). When the physician needs to monitor the QT-interval duration for QT safety, he or she can open a Web page and measure the recorded ECG with mouse-based calipers immediately after the ECG is recorded anywhere in the world (bottom).

Scenario 3: Direct access to raw data (ECG or R-R intervals) and processing with a self-made APP, supported by SDKs, software libraries, or APIs provided by device vendors

If there is an SDK or if the device supports the GATT BLE standard, the corresponding sensor data can be directly acquired with custom-made software. With Apple HealthKit libraries, the 1-lead ECG voltage measurements and the ECG classification of an Apple Watch recording can be retrieved. The Swift code snippet in Supplemental Figure 2 shows the code to access ECG voltage values stored on the local health store of an Apple iPhone. Supplemental Figure 2 also includes example ECG voltage measurements during an Apple Watch ECG recording. With Apple’s Bluetooth software library or similar tools for other operating systems, medical-grade BLE sensor raw data can be retrieved and displayed with its programs. A demonstrator program written in Swift for iOS is shown in Figure 7 (left). The program processes the data from a BLE heart rate tracker. The standardized BLE heart rate sensor from Polar is particularly interesting for heart rate variability analysis because the device has a resolution of 1024 Hz, which is better than the sample resolution of most Holter ECG devices used for heart rate variability analysis. Figure 7 (right) shows online access to a BLE heart rate sensor directly from a Chromium Web browser. Chromium developers recently implemented a new functionality in the browser that allows it to directly read, display, and analyze data from BLE devices such as heart rate sensors, health thermometers, glucose sensors, and SpO2 sensors. The Web Bluetooth work-in-progress API (WBT_API) specifically allows this. Whereas previously wireless sensor recording required the installation of a proprietary APP, with the Web Bluetooth API, vital signs for health, sports, and wellness can be wirelessly recorded, displayed, and processed independently of the type of device or the operating system on a Web browser. The developer can write one program and that same program will work on different operating systems. In addition, the user only needs to open the browser to collect data. Through the BLE GATT protocol, many health sensors can be connected, and the new Web API makes it easier to capture wireless sensor data for research and patient care scenarios. Figure 8 depicts a Microsoft Band2 (wearable wrist bracelet) Windows 10 APP written with the Microsoft Band 2 SDK adopted from Chantler. This demonstrator APP displays live multiple sensor data and sends the data to an FHIR server.

Figure 7

Raw data from a Bluetooth low-energy (BLE) heart rate sensor is received by 2 different software methods. Right: New Web-based application programming interface (API) displays the heart rate data online in a modern HTML5 Web browser. Left: Heart rate sensor is accessed via Apple’s Core Bluetooth API, and an Apple Swift program calculates heart rate and heart rate variability data online.

Figure 8

Custom-made demonstrator application (APP) written with the Microsoft Band 2 software development kit. The APP displays multiple sensor data retrieved from the Microsoft Band 2. Unfortunately, this powerful wearable is no longer available.

Discussion and conclusion

The fact that most current FDA- or medical CE (Conformitè Europëenne)-approved wearable ECG devices do not support a standardized medical exchange method that can enable caretakers to postprocess and measure the signals is a clear disadvantage. Although there are sufficient open-source software technologies that measure ECG markers from PDFs of ECGs, standardized access to the raw data is a real need for the future. Another concern about ECG PDFs is that they must include standard ECG calibration markers (eg, a simulated pulse that is 200 ms wide and 1 mV tall) or be overlaid on a standard grid at a standard size (eg, 25 mm/s and 10 mm/mV). Experience has shown that not all device/printer combinations ensure correct scaled printing. Thus, all measurements of printed ECG waveforms must be calibrated against the ECG’s voltage, time calipers, and the included grid. In general, spending time on postprocessing of PDF ECG is not an optimal use of a health care professional’s time. Moreover, it should be noted that user-activated, single-channel ECG watches for medical diagnostics have major limitations compared to multichannel ECG recorders. A single-channel ECG is not suitable for ischemia or infarction detection. Because the watch requires a second hand to activate the recording, short-duration arrhythmias often are not detected. Nevertheless, there are positive developments on the market, such as devices that come with SDKs or devices that support BLE GATT profiles for heart rate sensors. With the BLE GATT protocol, many health sensors can be connected, and SDKs or Web APIs make it easier to capture wireless sensor data for research and patient care scenarios. For personal privacy, encryption and general data security is an important factor. Thus, it would be desirable if as many devices as possible would enable access to their measurements without going through a manufacturer-specific cloud. It is clear that all the given access would be provided according to the regulations of the responsible authorities.

Acknowledgments

The authors thank Miranda and Barry Brown, Glenn Yacoub, and Todd Schlegel for their critical review of the manuscript.

Funding Sources

This work was supported by the Federal Ministry of Education and Research, Germany, within the Projects SELFPASS and MITASSIST.

Disclosures

Dr Stein is the owner of the company MED3D. One of the AliveCor devices was a testing sample; however, AliveCor was not involved in this study. Parts of the MedM server software were temporarily loaned; however, MedM was not involved in this study. All other authors have no conflicts to declare.

Authorship

All authors attest they meet the current ICMJE criteria for authorship.