HealthSphere

HealthSphere

Holter monitor with heart rate analysis, Azure cloud based and dashboard.

Always use technology to improve the world, if you are a black hat or gray hat hacker please abstain at this point......... or at least leave your star to make me feel less guilty XP.

DISCLAIMER: This application is used for demonstrative and illustrative purposes only and does not constitute an offering that has gone through regulatory review. It is not intended to serve as a medical application. There is no representation as to the accuracy of the output of this application and it is presented without warranty.

Introduction:

Our heart beats 115200 times a day, it is such a fine machine that does not stop during our lives. However, not many people have the advantage to have this machine in good conditions. Many factors of daily life can permanently affect cardiac function.

Factors such as:

• Sedentarism.
• Diet full of Salt, saturated fats and refined sugar.
• Alcoholic intake.
• smoking
• high blood pressure
• obesity
• family history of heart disease
• history of a previous heart attack
• age over 45 for men, or over 55 for women
• male gender (there's a direct correlation for cardiovascular disease)
• substance abuse
• low potassium or magnesium

This brings us to our pain point:

Quite a lot of people have to undergo cardiac tests frequently in expensive hospitals with gigantic measuring devices. We are in a time where open health is stronger than ever and it is time to make the patient the point of care.

The market for electrocardiography is quite enormous, as it has become the standard for patients with heart risks.

What we can see in this graphic is that most of the electrocardiographs are those big machines (as a Biomedical Engineer I can attest that most, are quite old). In addition to this most in the "holter" category are not really wearables but smaller ones that can be carried despite that a wearable one that can be used at home could provide invaluable information about the patient's heart.

One thing that we have to notice first. The first of wearables has already come out in the market and the results are not that great. The main issue that Doctors put forth is that it is too much information, think of the internet before data aggregators, it has no value if it cannot be interpreted correctly and that is something that has to be taken into consideration. A solution should aggregate all that data and provide carers with useful information.

Because of these reasons through AzureSphere's technology we will create a real-time heart rate, EKG monitoring system and a dashboard deployment, that will be out of the box secure, from the MCU, to the OS, to the cloud. Healthcare data is our most valuable one, and it is evident that this kind of security must become the norm in every device.

Connection Diagram:

To develop this idea first we need a EKG-capable chip (EKG stands for electrocardiogram, K instead of C because of its dutch origin). We will be using this one:

http://www.theorycircuit.com/heart-rate-monitor-ad8232-interface-arduino/

It is a 3.3V compatible shield that works better with 3.3V boards such as the new line of Arduino boards such as the MKR line. As most of the ADCs from the Azure sphere have no developed library in order to activate them, we will make a wearable holter module with an Arduino MRK GSM 1400 (can be any Arduino from the MKR line or any other small 3.3V compatible microcontroller, the GSM was what I had in hand) and attach a Bluetooth module to it (If you have the Arduino MKR 1010 you can avoid having to use a BT module!), and of course the EKG board. This module will send its information via Bluetooth to the Azure Sphere which in turn will have a Bluetooth module connected to a serial port and it will then communicate to the Azure cloud.

Here is the connection diagram of the system. Both for the Azure module and the Holter module.

Services Connection Diagram:

Azure Sphere and Azure Cloud Setup:

The initial configuration of Azure Sphere is a bit long, however I recommend that you follow the official Microsoft documentation, which provide very clear instructions.

• https://docs.microsoft.com/en-us/azure-sphere/

You need to save the following data for later:

• Hubname.

• Device id.

• ID Scope

• Auth Number (Azure Sphere CLI)

azsphere tenant show-selected

Download the Azure Sphere code called "Health Sphere". Once you have downloaded it, open it with VS and in the file "app_manifiest.json" (it is provided at the end of this article, in the "code" section). Then alter it like so:

• Write the ID Scope in "CmdArgs": [ "xxxxxxxxxxxxx" ]
• Write the Hubname in "AllowedConnections": [ "global.azure-devices-provisioning.net", "xxxxxxxxxxxxxx.azure-devices.net" ]
• Replace the Auth Number in "DeviceAuthentication": "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"

{
    "SchemaVersion": 1,
    "Name": "AvnetStarterKit-Hackster.io-V1.0",
    "ComponentId": "685f13af-25a5-40b2-8dd8-8cbc253ecbd8",
    "EntryPoint": "/bin/app",
    "CmdArgs": [ "xxxxxxxxxxxxx" ],
    "Capabilities": {
      "AllowedConnections": [ "global.azure-devices-provisioning.net", "xxxxxxxx.azure-devices.net" ],
      "AllowedTcpServerPorts": [],
      "AllowedUdpServerPorts": [],
      "Gpio": [ 0, 4, 5, 8, 9, 10, 12, 13, 34 ],
      "Uart": [ "ISU0" ],
      "I2cMaster": [ "ISU2" ],
      "SpiMaster": [],
      "WifiConfig": true,
      "NetworkConfig": false,
      "SystemTime": false,
      "DeviceAuthentication": "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"
    }
  }

Then compile i.

UPDATE 21/11/2019:This project is already updated to the "3+Beta1909" version of the Target API Set. Many projects will not work in Visual Studio, if you have an old version of VS, it suddenly may be unable to compile in that version. If you have this same problem, update your version with this release:

https://docs.microsoft.com/en-us/azure-sphere/resources/release-notes-1909

That is ONLY for old installations, if you have the newest one, don't bother with this last detail.

Useful links to have in mind:

Github Azure Samples (These samples are for the Azure Sphere from an earlier version, however the chip is the same, so most of the samples work on this Azure Sphere verison):

• https://github.com/Azure/azure-sphere-samples

Azure Devices Heat Map:

• Azure Heat Map: http://avnet.me/azsphere-kit-map

Arduino Holter Monitor:

Before proceeding, let's explain just the basics of Electrocardiography. The physiological phenomena that produces it and how we can read it is quite interesting, but is beyond the scope of this entry. For that read:

https://www.ncbi.nlm.nih.gov/pmc/articles/PMC3714093/

The EKG is composed of the following graph and we will call this segment PT.

The heart rate is obtained by taking the distance between the peaks of two graphs, this is called the RR segment.

In this case the frequency will be obtained through an algorithm implemented in the board.

• First we get the ranges in which our AD8232 module is working.

We can observe that the wave approximately goes from 420 to 680 in the ADC reading, we will use the following hypothesis to detect the frequency.

• Since what we are looking for, is the reference of the R segment, we can notice that 650 is a value that the R segment will always reach, therefore detecting a value greater than 650 will be the R segment.

This can, of course, be changed if the contractile strength of a person's heart should be stronger of weaker, thus in turn providing different ranges. And provide a calibration range to allocate the R wave. Than would be used in a more commercial application.

Note: the code is in the Arduino Code Folder (github & down here)

This is the formula to obtain the heart rate.

The arduino generates a count in milliseconds, so the formula will be modified to work with the Arduino range.

Here is a sample of the previous algorithm. As you can see it can detect the frequency correctly. On the right you can see the values obtained by the Arduino and on the left a test with a Xiaomi Mi Band 3.

Bluetooth Modules Configuration

HC06:

Connect your BT module through USB - Serial TTL. (Serial configuration at 9600 baudrate, No line ending)

Send: AT
Response: OK
Send: AT+NAME<device name>
Response: OKsetname
Send: AT+PIN<4 digit code>
Response: OK<Any 4 digit code>

Baud Rates(1:1200, 2:2400, 3:4800, 4:9600, 5:19200, 6:38400, 7:57600, 8:115200, 9:230400, A:460800, B:921600, C:1382400)

Send: AT+BAUD8                  (115200 Baud Rate) 
Response: OK<baud rate>

HC05:

Connect your BT module through USB - Serial TTL. (Serial configuration 38400 baudrate, Both NL & CR)

The module has a button, which must be pressed when connecting to enable the function to configure it with the AT commands, so I recommend that you put a clip on it to make it easier.

Leave the HC06 connected when configuring the HC 05 since we need to pair the two devices

Send: AT
Response: OK
Send: AT+RMAAD
Response: OK
Send: AT+ROLE=1
Response: OK
Send: AT+RESET
Response: OK
Send: AT+CMODE=0
Response: OK
Send: AT+INQM=0,5,9
Response: OK
Send: AT+INIT
Response: OK
Send: AT+INQ
Response: 
+INQ:AA1:BBB:CCC,XXXXX,XXXX
+INQ:AA2:BBB:CCC,XXXXX,XXXX
+INQ:AA3:BBB:CCC,XXXXX,XXXX

Use the following command with all the BT addresses you get until you find HC 06, Example if AA1: BBB: CCC is the correct address.

Send: AT+RNAME?AA1,BBB,CCC
Response: +RNAME:<device name>
Send: AT+PAIR=AA1,BBB,CCC,9
Response: OK
Send: AT+BIND=AA1,BBB,CCC
Response: OK
Send: AT+CMODE=1
Response: OK
Send: AT+LINK=AA1,BBB,CCC
Response: OK

Now that the connection has been formed, the HC-05 will automatically connect to the HC-06 every time they are turned on.

Azure CLI Setup:

To install the Azure CLI you need to follow the proper tutorial provided by microsoft according to your OS (Windows 10 for me):

• https://docs.microsoft.com/en-us/cli/azure/install-azure-cli?view=azure-cli-latest

Enter the following command to get the Azure IoT extension

az extension add --name azure-cli-iot-ext

After that log in to your azure account.

az login

Once this is finished we can check if the data is being sent properly to Azure IoT Hub. Run the following command replacing HUBNAME and DEVICEID with your own.

az iot hub monitor-events --hub-name HUBNAME --device-id DEVICEID

We are receiving the heart rate every 10 seconds in the payload, as we previously set it in the Arduino code.

Receive Data and Save.

To send the data, what I did was a process of saving, processing and sending the data "Manually". However, at the end I will show how everything can be automated through a MACRO.

• The first step is to execute the following command, it will save all the information received by Azure CLI in a file.

az iot hub monitor-events --hub-name HUBNAME --device-id DEVICEID> datain.txt

• Since we are receiving the data every 10 seconds, we will only have to wait 10 seconds to execute the command before stopping it with CTRL + C. Inside the datain.txt file we can find the received data.

Setup Python Code.

For the subsequent processing of the data, we must configure the CloudMQTT credentials that we will use to send the data received from the CLI.

• Create an account in Cloud MQTT.

https://www.cloudmqtt.com/

• Copy the credentials of "Server", "User", "Password" and "Port".

Within the python code we will change the following parameters for our credentials.

client.username_pw_set ("USER", "PASSWORD")
client.connect ("SERVER", PORT)

Once we have the data there, we must execute the Exe.py program in the "Python Code" folder, this will process the data and send it to the CloudMQTT with the topic "/Azure"

Node-Red Setup:

Node Red is a tool for NodeJS where we can integrate services easily, without code. And of course, create excellent dashboards. Use the following documentation to start and install the Dashboard nodes:

NodeJS installation guide: https://www.guru99.com/download-install-node-js.html

NodeRED installation guide: https://nodered.org/docs/getting-started/windows

NodeRED dashboard installation guide: https://flows.nodered.org/node/node-red-dashboard

The file "flows.json" in the folder "Node-RED Flow" (at the end or on Github), has all the information to import the flow into your NodeRED.

Once that is done, we will edit the MQTT node to enter our credentials.

Set Server and Port.

Set User and Password.

If everything works fine, press the "Deploy" button and enter the following URL to check the Dashboard.

http://localhost:1880/ui

If we execute the Exe.py file, we will see how the data appears on the Dashboard.

Automate everything:

To Automate everything, create a macro with a program called "Mouse Recorder Premium", the macro of that program is in the "Macro File" folder.

For it to work properly, we must change for our values in this part of the macro.

The Final Product:

The following images showcase the building process of both the Holter Monitor and the Azure Sphere module. For both a custom, manually soldered PCB was fabricated and we repurposed a Pycom case for this project as it fitted the Holter Monitor correctly.

The desktop interface:

The mobile interface:

Holter Monitor:

Azure Sphere:

Our Epic DEMO:

Commentary and Future Rollout:

Because of the nature of healthcare information and how it can (and in some instances will) be used, or misused, security is of utmost importance. The Azure sphere provided us that characteristic along the development of this project and then some.

• Nevertheless, as every early project here are some proposed improvements
• One is size, we can go even smaller.
• The second most notorious one is that the ideal hardware configuration would be to include everything just using the Azure Sphere and a microE board.
• On an intermediate step the Arduino 1400 can be switched for a MKR 1010 to save on a Bluetooth module.
• When integrated we can also avoid using an additional service and implement the dashboard directly through a webpage and Azure cloud.

The market for healthcare wearables is trending and hot right now and as Apple has proven the interest to create healthcare wearables is on the rise. This create additional (if only superficial) validation to the project, but this also generates concerns. On one hand we have the open health movement that tries to convert the patient to the point of care and on the other hand we have these gargantuan corporations also trying to get a piece (or all) the cake for themselves. Whether one or the other wins will depend in how privacy and ownership of information will be handled and this might be one of the most important decisions shaping our future. For now projects like this one offer an alternative that is both secure and safe to implement. Hopefully you liked it and thanks for reading.