Cloud Native Arrhythmia Classification

Logo

Abstract

Nowdays, cardiological tools are only capable of offering a statistical report which does not offer valuable help to recognize common arrhythmias. Furthermore, existing AI-driven solutions require in-house implementation and constant maintenance. This paper presents a cloud native application running on Google Cloud Platform which provides an intuitive web interface. In this way, continuous management is decoupled from the public structure altogether, making the cloud approach more appealing. Having an always available deep learning solution for heart diseases analysis can be useful for a quick and preemptive patient examination before the actual medical input. Our contribution is the development of a cloud native solution, making the service highly scalable and resilient, as opposed to in-house configurations. We propose a three stateless microservices architecture that hierarchically manages the data flow and the inference, the latter being carried on by a two stage neural network which firstly handles the noise separation and secondly the classification. We run benchmarks on both our cloud solution and a local hosted equivalent to assess scalability and performance differences.

About The Project

In this project we aim to develope a cloud native solution for real-time arrhythmia classification. We took inspiration from the deep learning model presented in this paper with the addition of an extra classification stage; at first, our model looks for the presence of noise in an input ecg signal. If said signal is clean, it will be further evaluated in another stage, where our model classifies the signal in four possible classes of arrythmia. The cloud architecture consists of three stateless microservices capable of communicating with each other.

Proposed models

The ECG arrhythmia detection task is a sequence-to-sequence task which takes as input an ECG signal $x = [x_1 \ldots x_k]$ and outputs a sequence of labels $r = [r_1 \ldots r_k]$, such that each $r_i$ can take on one of $m$ different rhythm classes. Each output label corresponds to a segment of the input. Together the output labels cover the full sequence. However, this phase is executed after a preliminary classification step, which aims to look for noise presence in the signal. We use a convolutional neural network for both the binary and the sequence-to-sequence learning task. The networks take as input a time-series of raw ECG signal, and output a binary and a sequence of labels predictions, respectively. The models are structured as follows (model graphs generated with this tool):

          

Cloud Technologies

We opted to use a Platform-as-a-Service (PaaS) as it offers a ready-to-use cost efficient solution with the caveat of having less fine tuned control. The PaaS of our choice is Google Cloud Platform, as it offers a plethora of services for developers. The most crucial one being Google Cloud Run, a serverless model that can run and automatically manage containers thanks to the under the hood Kubernetes layer. This setup perfectly fits our needs of an autoscaling and on-demand server infrastructure. Furthermore, Cloud Run can be configured to support multiple concurrent requests on a single container instance which allows us to save time and cost. We built three containers for our app through the usage of Docker. Each container holds a microservice which is then deployed to a GCR service. Microservices are an architectural style for developing applications: they allow a large application to be decomposed into independent constituent parts, with each part having its own realm of responsibility. This leads to simpler scalability and optimization, which is exactly what we are looking for. The microservices communicate with each other in a feed-forward fashion thanks to the pub/sub protocol in conjunction with the usage of Eventarc triggers. The aforementioned approach decouples clients from the server (they won’t need to wait for the receiver to be available), and this separation is further enhanced by triggers’ way of message delivery: the push method. Clients will receive messages as soon as they are ready, without the necessity of a synchronous wait.

Diagram

Getting Started

Prerequisites

  • Install Docker
  • Follow this guide to authenticate the application as a service account
  • Go to the folder of each microservice and then run next commands. This will ensure that all the required libraries will be installed
      docker build -t /gcr.io/project_name/name_of_the_image .
    
      docker push /gcr.io/project_name/name_of_the_image
    
  • Go to Google Pub/Sub and create ecg and nonNoise-ecg topics
  • Go to Google Cloud Run and create the corrisponding services from the images you just pushed
  • Follow this guide to create Eventarc triggers for m2 and m3 services
    • Select the event provider Pub/Sub and choose Message.Published event

Configuration

├── M1
│   ──> contains web interface src code
├── M2
│   ──> contains Noise/non-Noise binary classifier src code
├── M3
│   ──> contains Arrhythmia classifier src code

The configuration we used for the m2 and m3 services is the following:

  • 4 CPUs and 4 GBs of RAM
  • Number of maximum requests per container: 3
  • Allow internal traffic and traffic from Cloud Load Balancing
  • Authentication: Require authentication

For m1 service we used :

  • 2 CPUs and 2 GBs of RAM
  • Number of maximum requests per container: 6
  • Allow all traffic
  • Authentication: Allow unauthenticated invocations

Once the services are created, click on the generated m1 url to access to the web interface

Demo

Logo

Contacts

Acknowledgements

We are grateful for the support of the University of Naples “Parthenope”, Department of Science and Technologies, Research Computing Facilities (link) for assistance with the calculations carried out in this work.

GitHub

View Github