Greetings once again, tech aficionados, today we have a slightly different tale to tell, so let’s begin by also welcoming our special guest digital health enthusiasts! It’s your resident creator of digital chaos back again with an epic adventure of a health tech proportions, an area for me where passion and purpose collide, some would call it “ikigai”.
Those that know me well will be acutely aware of my health tech background; it’s where I spent my formative years scrabbling around (in the physical and metaphorical sense) to connect all sorts of weird and wonderful patient monitoring devices up to electronic systems of record.
These typically serial cabled connections bridged the analogue world of patient monitoring with the digital world of electronic patient records, the sole purpose of which was to provide clinical staff with an automated way to capture and report on patient measurements and diagnostic data, improving the picture of a patient’s health.
When it comes to personal health tech, size matters…
Fast forward a fair few years to the modern day where I have less hair and the general public readily have access to consumer-grade health monitoring devices.
What was once a device the size of a small fridge sat on a trolley in a hospital ward; is now readily available as a pebble sized watch on your wrist. Isn’t it amazing how rapidly technology advances (as opposed to my hair line which is unfortunately receding…)
So this topic is a passion area for me; it is something I have been excited about for a while as most of now likely bored colleagues current and past will attest to!
I have also previously touched on this topic during my first community speaking event, Scottish Summit 2023 (in Manchester). Given I am not exactly a fan of public speaking you can see that when you are passionate about something you can gain super powers given the opportunity, maybe this Ikigai stuff is true!
To care in the community or not, that is the health tech question ?
Now for the readers of a more clinical persuasion; I am not suggesting that personal monitoring devices are of the same diagnostic quality as a purpose built clinically validated device such as an ECG’s, however they do provide ease of access to a health monitoring capability which in my humble opinion, as yet remains largely untapped in modern healthcare.
Coupled with the economics of public health service provision in the UK; of which we are all familiar (as it is frequently mentioned in the news). There is an ever increasing pressure on care providers to do more with less, improve wait times, see more patients all whilst ensuring to deliver quality care.
One of the often heralded ways to help tackle these challenges is by keeping patients in the community for longer, with the theory being it will help alleviate the load on the secondary health care providers.
Can we not use some digital health tech wizardry?
So it seems rather perplexing to a digital wizard of healthcare such as myself… that modern health tech wearables are not featuring more prominently in community care services.
If one of the main goals is provide more personal based care, why not utilise all this pre existing tech? This particular quandary has spent far too much time spinning around in my head, there are multiple reasons I can see at play..
- Lack of capacity to find and deploy these sorts of solutions?
- Fear of potential risk of new technology & safety concerns for patients?
- Lack of capital investment to invest in cloud platforms?
- Awareness that solutions are possible using consumer devices
My rumination’s have landed that it’s probably not one specific cause and likely a culmination of all of these factors (and probably more) given the massively overstretched workforce. However that being said it neatly allows us to circle back to the reason for this now rather rambling article!
Given I have absolutely no influence over national politics (probably a good thing); no influence on NHS policymakers or say in central government funding allocation, the only thing I can attempt to influence is awareness of what is possible in the hope that someone who does have the power reads this and can potentially build upon it further.
So then what’s the answer, well it sounds like a Health-tech quest to me!
So; fear not dear digital adventurer this shall no longer persist in my grey matter’s chaotic rumination!
Through this series on Health-Tech I shall endeavour to highlight how with a few key building blocks care providers can take stock of the physical beats in your chest and transform them into bytes of healthcare power. If you like paint by numbers, and who doesn’t like a good diagram here’s how it all looks in practice <—
So buckle up, health tech evangelists strap on your preferred heart rate monitor because we’re about to delve deeper into a digital tapestry that weaves wearable tech and cloud-based healthcare solutions together to create a beautiful platform of remote monitoring health-e-ness.
Excited yet …. ?? If yes you are my sort of people, if not well it’s still pretty damn cool so read on anyway.
The Genesis of a Heartbeat Symphony
Our epic tale starts with the humble Apple Watch, a digital sentinel on your wrist, vigilantly watching over every beat of your heart. It’s not just counting steps or calories; it’s the gatekeeper to a treasure trove of health data, diligently collected through the Apple HealthKit libraries.
Now; you may be thinking “oh here we go, another Apple fanboy drinking the koolaid and trying to add some more value to the Apple share price” Fear not, when it comes to digital tech i’m not fussy I can appreciate an Android as much as the next person.
The good news is you could connect up other wearables such as fitbit etc, provided they have api’s which can surface the data to a mobile application.
This data can be shared to the cloud platform and healthcare database it just so happens when I was figuring out how to connect the demo together I owned an Apple Watch!
So how do we transform the beats to bytes; well this is where the true magic begins when this data embarks on a journey beyond the Mickey Mouse watch face to the cloud. The first piece of the puzzle to achieving a cloud connected patient monitoring platform is to enable data connectivity and collection from the Apple HealthKit ecosystem.
The protagonist of this connected health tale is a nifty app nestled on the user’s iPhone, a digital conduit listens and channels the health data streams from the sensors on and in the watch. There are three main steps to this connected device success here; well two for the Apple Watch; one for other IoT devices (an added brucey bonus if you will). So lets dig in:
Step 1: HealthKitOnFHIR – iOS
Unfortunately; I am many things but not an app developer, so thankfully the act of obtaining the data from the watch via HealthKit to an app ready for streaming was originally worked out by some very talented and clever people.
Firstly Apple who created the HealthKit ecosystem to begin with and then Secondly a team from Microsoft who created a iOS swift library that automates the export of Apple HealthKit Data to a FHIR Server, which they have aptly named HealthKitOnFHIR.
But wait…. Gary I hear you ask what’s this FHIR based magic you speak of, alas it’s not a spell it’s a common healthcare messaging standard. This standard enables healthcare systems to exchange data in a structured way ensuring the right beats get to the right patients. Good news is there is lots of information about it out in yonder inter webs…
So yeah that’s great and all but how does it work; well here’s the clever bit HealthKitOnFhir enables configuration within the mobile application of a FHIR Server as an “external store” and provides a simple way to export high frequency HealthKit data. The solution enables transfer of a set of predefined health tech measurements from the Apple HealthKit environment on the device via it’s API’s, as you can see below there are a lot or measurements available, which pretty much covers enough datapoints to provide a fairly holistic view of a persons overall health!
| HeartRate | StepCount | BodyTemperature | HeartRateVariabilitySDNN |
| BloodPressure | BloodGlucose | RespiratoryRate | WalkingHeartRateAverage |
| BloodPressureDiastolic | OxygenSaturation | Height | AppleExerciseTime |
| BloodPressureSystolic | BodyMass | HeartRate | AppleStandTime |
| ActiveEnergyBurned | EnvironmentalAudioExposure | DietaryEnergyConsumed |
Now as with any true real life drama story, things are rarely that simple! Whilst the HealthKit app is available as source code and can be easily be deployed to an iOS device; there are of a few undocumented dependencies to enable a successful iOS app build and deployment. Fear not dear readers; I won’t leave you hanging they are as follows:
Certify your Provisioning
As with anything in the Apple ecosystem you will need a provisioning and deployment profile along with a signing certificate and have this enabled within your Xcode instance; you can run this on a simulator without but obviously you want to go full on foot to the floor and deploy to a device.
Background your Delivery
Secondly you need to enable utilisation of the HealthKit swift libraries for background delivery (otherwise the data won’t deliver). This again is a simple switch in the Signing and Capabilities section of the iOS deployment target,
And how do you make all the above work…. well guess what you need a paid developer profile and account from Apple… Of course, for the cool stuff you need to pay the proverbial fruit based piper!
Now it’s your turn!
So that’s it on the App side of things; it’s fairly simple and straight forward. Once you have the app deployed and configured you can then send the health data to the cloud. Thankfully there is a lot of information available on how to achieve this if you would like to try it for yourself and the code is also open source and available for download, guess what there is a helpful link below!
But wait…. where are we going?
Hey; hang on the cloud is a big place, where is all this data going to be sent to I hear you ask, ah-ha I see you are on point what digital gurus you are! Well yes you are correct, we need a destination for all this lovely measurement data to be sent to, so keep on reading I shall give you the destination
Step 2: Azure Health Data Services
As with any client server relationship, we need a protocol to be the other half of the handshake, a destination to our route, a net to our subs… Ok no more networking puns. To enable the iOS mobile application to have a destination to connect to, we need to provide it with a service to connect to. Remember our FHIR friend from earlier, well this is where it becomes the lead health tech actor in this extravaganza.
Microsoft Azure has a lovely set of tools for Healthcare Data Management, the Azure Health Data Services, the most notable of which is the Azure FHIR instance, which effectively operates as a cloud based FHIR server.
This FHIR database will be the ultimate end point for our health tech data, more on this in a later article, however to get the data into FHIR we need to get through the security gateways of Azure and Identity management, we can’t just have any old person sending us their health tech data now can we!
So to manage this data transfer in a secure manner we use Azure Event Hubs and an Azure App Registration, these solutions essentially enable public access from the user’s mobile device for specific set of predefined users.
However as with the iOS application build this isn’t just a switch it on and away you go job; there are some customisations that need to be added to support the measurement transfer; and helpfully these are as follows.
Register your App
The app registration config needs a “Mobile and Desktop” redirect URI adding which is configured to point to the Azure FHIR “SMARTonFhirProxy” service; thankfully this path can be found on the FHIR service config screen, however you will need to deploy this service before configuring the App registration, admittedly we are abit cart before the horse here….
Perms, Perms my Kingdom for some Perms
Once registered the app then also needs “user impersonation” permissions for the Azure Healthcare API’s to enable the user connection to the FHIR service on behalf of the authenticated user, this will be used later on in the FHIR service when granting permissions at that level.
Sound’s awesome, but I’m only seeing part of the health tech picture here…
So in summary by using the application sample from the HealthKitOnFHIR repo I was able to connect an Apple Watch to send HealthKit data and make it streamable to Azure Health Data Services.
Thankfully this health tech app based solution was made publicly available open-source on git-hub a few years ago for digital wanderers like us!
However as with a persons health tech journey that’s only part of the puzzle, there are whole piece(s) around how to take that data and transform it into the correct mappings for the FHIR service to understand store…
Guess what’s coming in the next post 🙂
So, as we close this chapter of our health tech adventure, I invite you to ponder the possibilities that lie at the intersection of technology and healthcare. And remember, each step you take, each heartbeat you monitor, is a pixel in the larger picture of health. Signing off with a heartful beep until next time.
Gary
P.S. Have you had your own eureka moments with health-tech? Share your stories below, and let’s continue to unravel the mysteries of digital health together!
