Distributed Health Record Using IoT and IOTA

The problem

Patients wonder why they have to repeat medical information and why they can't access it once it has been documented.

Clinicians wonder why they have to spend time repeatedly entering the same information and why they can't access patient's health history from other healthcare providers or even sub-systems at the same hospital.

From https://www.iota.org/verticals/ehealth

Healthcare data has traditionally been siloed in different institutions or even within a single institution. These silos prevent meaningful sharing and reuse of data, and limit the quality of care that can be delivered. To receive medical treatment, an individual may need to consult with multiple providers for a single incident. When individuals transition from primary care clinics to hospitals to specialists and back again, records are not shared seamlessly, reducing their continuity of care.

Despite recent political ventures in many countries, our data is not satisfactory shared between healthcare professionals and basic medical information is duplicated many times over. With a dramatically growing number of consumer devices capable of monitoring clinical parameters, the number of silos are exploding.

This project explores the possibility of giving the patient full ownership over medical information and the ability to share it with relevant healthcare providers. It introduces the concept of a Distributed Health Record (DHR). This is applied to an example of secure medical home monitoring using IOTA, Azure Sphere and openEHR.

My background

With 15 years of experience developing a major Electronic Healthcare Record (EHR) system in the Nordic countries, I have first hand experience of the complexities of medical journals and interopability between systems. Further I am applying my knowledge of securing low-power IoT devices.

This is personal

Earlier this year I was prototyping health monitoring devices using LPWAN-technologies on low-power microcontrollers in my spare time. One day in March while at work, my heart stopped with no prior warning. My co-workers performed CPR and used a defibrillator to revive me before I was rushed to the hospital.

A genetic disorder, LQTS, was discovered and I ended up with an Implantable Cardioverter Defibrillator (ICD). This device is a safeguard for future incidents, and it also communicates with a base station that reports telemetry to my local hospital. While these technologies have proven great health benefits I got interested in security issues and data availability.

The first issue lead me to I am the cavalry and raised questions about the security of my own prototypes. This has so far lead me to the Azure Sphere MT3620 and it's security focus.

The healthcare industry has adopted computerized, connected technologies to more rapidly deploy improved medical devices. Over half of the medical devices marketed today operate on software: implantable; diagnostic machines; monitoring devices. These technologies have amazing capabilities to save lives, diagnose quickly and improve quality of life, and therefore a security failure is a failure to safeguard human life.

I also discovered that the data that my ICD is reporting ends up in a separate disconnected sub-system at the hospital and is not immediately available to other hospitals, clinics, emergency rooms outside hospitals or even other wards within the same hospital. This means that if I end up in a ER while on holiday it is unlikely they will know if my ICD reported a failure the previous night. In my country patients are able to log on to a national portal and read health records. The data from the ICD is exempt from this, I can only guess, due to technical incompatability.

The lack of interopability between systems and availability of health data is where IOTA comes in and is the main concern of this proof-of-concept.

Architecture

I don't believe one could leave the management of IOTA seeds and multiple passwords to all kinds of patients. 89 year old Maud is not going to recite her 81-character IOTA seed or high-security password when she visits her doctor for dizziness. My proposed solution is to integrate patient-owned medical data in IOTA with national patient portals already implemented in many countries. You would trust this party in creating and maintaining your medical wallet, and you would allow or deny healthcare practitioners in accessing it when needed. For the adventurous the seed would be accessable in the portal. Furthermore the actual medical data stored in the Tangle would be encrypted.

Technology

This project is a proof-of-concept (PoC) consisting of the following parts:

• An Azure Sphere Starter Kit with a Mikro Elektronika Mikroe Heart Rate 4 sensor, capable of sensing patients heart rate and blood oxidation.
• An Azure IoT Central application for routing and displaying telemetry. It also associates the device with a patient and defines rules for triggering actions.
• A serverless Azure Functions for composing openEHR observations and assigning the measurements to the correct patient's wallet/distributed health record.
• An integration with the IOTA Tangle.

It is intended to be used for monitoring patients:

• Self-administrated at home
• Under supervision by home care
• Self-administrated or under supervision in nursing homes
• Self-administrated or under supervision at hospitals and clinics

Prerequisites

• Two or more IOTA-seeds representing patients. I recommend installing the Trinity wallet on computer and phone to verify the results. We will be using the devnet, although with the absense of value transactions this doesn't really matter for the PoC.
• A free Azure IoT Central account.
• A free Azure account for creating Azure Functions. This could be replaced by any web-server technology/hosting, but the sample code is based on dotnet core 2.1.
• Visual Studio 2017/2019.
• Azure Sphere SDK for developing device apps.
• GIT for downloading source code.
• azsphere command-line utility for configuring the MT3620.

Optional, but highly recommended

• IoT Central Explorer tool for monitoring messages.
• RequestBin for temporary capture and diagnosis of http-requests.
• Postman for manual generation of http-requests.
• Ocean Health Systems Archetype Editor for exploring openEHR data structures.

Sensor

For this PoC I have used a sensor for estimating heart rate (HR) through the pulse of the vascular system. It can also read how much the blood is saturated by oxygene (SpO2).

Monitoring SpO2 (out of hospital) can be useful for a number of health issues with insufficient oxygenation in the blood of the lungs. It can warn of deteriorating health for patients suffering of pheumonia and COPD (Asthma, emphysema). It is critical for patients of cystic fibrosis. It is also useful for monitoring acute airway inflammation, such as bronchitis, rhinitis, sinusitis, especially with children and patients who might not be able to altert a deteriorating state.

Other sensors that are readily available for this kind of out of hospital monitoring and their use cases are:

• ECG/EKG - Detect A-fib (tachycardio), v-fib, bradycardia (low HR), extrasystole (palpitations, LQTS).
• Temperature - Fever, fertility/ovulation, low metabolic rate, sepsis (patients with impaired immune system).
• Pressure mat - decubitus, movement of patients with dementia.
• Blood glucose - diabetes
• Blood pressure - complications of medication, stress, heart disease.

Code

The code for the Azure Sphere device is based on a few samples as starting points. When button B is pushed it reads the sensor, expecting you have your finger on the diodes. This data is transmitted and a few settings are synced.

Installation and first time registration of the Azure Sphere Starter Kit is well documented and required before running this application. This will tell you what you need to configure in app_manifest.json to allow the device on IoT Central.

Have the MT3620 User Guide handy.

I made a new repository and made a copy of the AzureIoT-sample from the https://github.com/Azure/azure-sphere-samples repository. This is a great starting point for creating a IoT Central or IoT Hub-connected application.

MikroE Click Heart Rate 4

The MikroE Click-boards have an extensive repository of libraries. They are however not compatible with the C-language-only environment of the Azure Sphere MT3620. Bummer. Having already ported one of these libraries for a I2C soil moisture sensor I was prepared to fire up my oscilloscope and put on a large pot of coffee.

I had ordered the MikroE Heart Rate 4 module because I had seen the work of James Flynn. The sample code worked with no modification and a lot of time was saved. Thanks James! Read up on his blog to learn more.

However, I discovered that as of September 2019 using analog-to-digital conversion (ADC) functionality, as most sensors do, merging these two starting points is not straight forward. One issue is that to use ADC for I2C communication you need to target Azure Sphere API version 2 Beta. This is denoted "2+Beta1905" under "Target API Set" under project properties as of this writing, but is subject to change.

Changing the API version with the Azure IoT Hub/Central as a starting point lead to all kinds of compile errors. I fixed most of them but not all. Using the clickboard_demos samples as a starting point and merging dependencies for the Azure IoT libraries did work.

One other issue was hardware definitions for the MT3620. The two samples target different definitions, with different names, and the sample_hardware.json and app_manifest.json need to agree. Decide on one and dig into the pinouts, you'll need to master this anyway.

Sample hardware abstraction for MT3620 RDB

Find the file sample_hardware.json under azure-sphere-samples\Hardware\mt3620_rdb\ and add GPIO's you need. I added

{"Name": "SAMPLE_HR4_INT", "Type": "Gpio", "Mapping": "MT3620_RDB_HEADER1_PIN8_GPIO", "Comment": "MT3620 RDB: GPIO2 is exposed on header 1 pin 8"}

to access the interrupt pin for the Heart Rate 4. How did I know what GPIO to use? I could visually see what pin was labeled INT on the Click-board, as well as find it on the product page.

The MT3620 User Guide states what GPIO pin this corresponds to on Click socket 1 on the Azure Sphere MT3620 Starter Kit.

The name SAMPLE_HR4_INT will be referenced in app_manifest.json and resolved to the correct pin address. Coming from a simple Arduino world this feels overly convoluted and messy. I have had 10-year olds pulse LED's in an hour on Arduinos, this is too abstract. I hope Microsoft simplifies this (just denote pin numbers) or adds visual tooling.

Using Click socket 1 or 2 for your modules does not matter if you need access to the INT pin for knowing when a finger is covering the sensor.

Communicating with I2C shares the same bus and the wires are interconnected. The I2C bus was already defined and left alone:

{"Name": "SAMPLE_LSM6DS3_I2C", "Type": "I2cMaster", "Mapping": "MT3620_RDB_HEADER4_ISU2_I2C", "Comment": "MT3620 RDB: Connect external LSM6DS3 to I2C using header 4, pin 6 (SDA) and pin 12 (SCL)"}

I invite you to further examine the client application or the HR4 sample to understand how the sensor is used. Don't worry about the algorithm for calculating the measurements.

Azure IoT Central telemetry

The rest of the code is pretty much about syncing and pushing telemetry data to IoT Central. Have a look at the azure-sphere-samples/Samples/AzureIoT for an isolated example.

Azure IoT Central application

I was familiar with Azure IoT Hub so I chose to use IoT Central for this project. The underlying mechanics are much of the same but you can achieve a lot with little or no code. Setting up an application is well documented, please follow this guide to learn more.

My application defines a device template with the following features:

• Telemetry for Heart rate and SpO2.
• Event for Device heartbeat.
• Settings for Status LED (for debugging, checking connection) and NPR Id. NPR Id is the national patient identifier I am using to assign readings to the correct patient's IOTA wallet. This setting would be used by an operator when a device is assigned to a patient for home monitoring. For use among multiple patients activating the correct patient might be accomplished using NFC, Chirp, barcode or similar.
• Properties for sensor version and NPR Id.
• Rule with webhook for triggering Azure Functions for creation of IOTA transactions.

You might notice NPR Id both under Settings and Properties, more on that later.

An indepth guide to Azure IoT Central. More on webhooks.

I recommend using RequestBin for debugging and exploring the http payload. Be aware that you will have to make a new address every 48 hours.

To monitor telemetry from the device to Azure IoT Central I used the tool iotc-explorer.

Azure Functions

The purpose of the Azure Function is to serve a national patient portal and do the following:

• Extract from the payload telemetry data, NPR Id (national patient identifier) and device identifier.
• Find the IOTA seed mapped to the patient. This would be a separate registry under the national patient portal, but has been simplified for brevity in this PoC.
• Create a openEHR compatible data structure, observation, from the sensor readings. This would be accomplished accessing a openEHR template repository, but has been simplified for brevity in this PoC.
• Create IOTA transactions for each measurement on behalf of the patient.

I spent quite some time trying to have the function access the device digital twin to get the patient identifier defined as an operator setting. This was unreliable and seemed to mess up device authentication. I believe the root cause to be the nature of the Azure Function and instance state.

I already had the needed id, NPR Id, as a Setting, but this was not a part of the payload IoT Central sends when the webhook is triggered.

To resolve this problem I added an identical Property in the template in Azure IoT Central. The device simply syncs the NPR Id Property with the value from the Setting. All the Telemetry and Properties defined as Conditions in a Rule are passed in the payload.

To develop and locally debug Azure Functions I recommend using Fiddler, Postman and JSON Editor Online. Please be aware that enabling decoding of encrypted http-requests in Fiddler may cause other applications on your computer to malfunction.

// Connect to a node on one of the main networks.

var repository = new RestIotaRepository(new RestClient("https://nodes.devnet.thetangle.org:443"));

// Get addresses from the Tangle on behalf of the patient's wallet for generating new address for posting reading.

// Would be an external trusted service.

var tangleAddresses = NationalIdentityService.GetTangleAddressesFromNprId(repository, nprId, ((JObject)telemetry).Count);

// Create transactions for the Tangle for each type of reading in payload and bundle together.

// Finalize and sign.

var bundle = CreateTransaction(tangleAddresses, telemetry);

// Send the complete transactions to the Tangle.

repository.SendTrytes(bundle.Transactions, depth: 2, minWeightMagnitude: 9);

Please explore the server code for more details.

Results

The results of the webhook are transactions on the Tangle, on behalf of the patient.

This data is now available for use in many different situations, regardless of hospital, clinic or country.

openEHR

'openEHR' is the name of a technology for e-health, consisting of open specifications, clinical models and software that can be used to create standards, and build information and interoperability solutions for healthcare. The various artefacts of openEHR are produced by the openEHR community and managed by the openEHR Foundation, an international non-profit organisation established in the year 2003.

openEHR is a massive subject, out of scope for this project description. In short I have based my implementation on the work of the "Vital signs" project, an attempt at standardizing how common clinical observations are described and globally readable. I have had to drastically condense the format to suit this application. I have also hard-coded creation of the structure, omiting a template repository. It is an attempt at proving a concept, rather than to be fully openEHR compliant.

You are invited to explore the openEHR Clinical Knowledge Manager or to download the Ocean Health Systems Archetype Editor to learn more about the data structure.

Security

The MT3620 has some very interesting security features on hardware level. Hopefully we will see less reports like this.

Lessons learned

• e-mail alert in Rules for Azure IoT Central has never worked while developing this project.
• Wi-fi connection for the Azure Sphere Starter Kit was increadibly unstable when first configured. I tried setting up a secondary 2G wi-fi network in addition to our main 5G and connection became much more stable.
• Azure IoT Central is a really nice solution. For what I ended up spending time developing Azure IoT Hub would probably have saved me some time and enabled more insight and tools.
• openEHR is complex and not a single-weekend readup.

Limitations

Experts in Domain Driven Design tend to agree: Electronic patient records and healthcare systems in general are among the most complex domains in software design. openEHR is designed for interopability between complex health systems and needs to be scaled down to fit lightweight devices.

I wanted to make a visualiser for a patient's distributed health record history and also attempt to import this into the EHR-system I work with. This will have to be left for a future project.

In future projects I would like to attempt more types of sensors, as mentioned earlier.

Encryption of the openEHR data in the Tangle was left during development, AES encryption the most obvious option.

Potential achievements with full scale deployment

If every patient world-wide were given single-source ownership of their medical data, the risk of maltreatment would significantly be reduced. This data only being shared when relevant and not being unnecessarily duplicated would increase privacy, security and trust. Secure home monitoring will increase the chances of uncovering health issues and reduce the load on hospitals and clinics with late stage disease. Using globally adaptable data formats will reduce sources of maltreatment between institutions and further open up safe exchange of patients across borders.

Modern healthcare has to take a turn in the direction it is growing.

Final thoughts on using IOTA as a patient-owned distributed health record

The core of the project worked out as hoped and I got to focus on the important stuff. While working on this I started thinking about using Masked Authenticated Messaging (MAM) as a way to keep interested parties synchronized with the patient's home monitoring. This will have to be left for a future project.