So here we are back once again like the renegade master… for the next act in our connected health tech journey, where we are all about the wizardry of data transformation!
Cast your minds back to our first episode where we discussed how to connect up your Apple Watch to the world of FHIR by using the beats from your heart, bytes from your iPhone and strings from the inter web.
We initially covered off the basic concept of connectivity, and how to create a level of security but as with anything in the mystical world of technology it’s never quite that simple!
I like big bytes and I cannot lie…. However mobile data streams and in particular IoT does not! So with the basic data connectivity and the user authentication cracked from the iOS app sorted, we need to provide a destination to receive and process all these byteiful measurements!
Where better to send a bunch of high frequency data than a service which has been specifically designed to be a recipient of all these high maintenance data points, welcome to the fray…… Azure Event Hub
Event hub acts as our data marshal whose main job is to make some sense and provide order to the IoT chaos. Azure Event Hub ensures that our basic HealthKit “event” data from the iOS app is formed into a structured set of messages and data streams which can then be handed off to an event processor and translated further down line.
For the bus conductors to be able to do their thing, we need to configure the event hub binding which provides the initial link between the source data from the iOS device and the normalisation process within the MedTech service
With this configuration the Event hub is effectively acting as the London bus conductor on the quest to the main player, the big dog and MVP in our data magic, Azure MedTech.
Cooking up something magical in the alchemist’s lab
Picture the MedTech service as if we’ve stepped into an alchemist’s lab, where the wizards are furiously working to handle the raw data from the HealthKit export and transmogrify the many messages into actionable healthcare related insights.
Here, in the crucible of Azure MedTech, our data undergoes a metamorphosis. It’s translated, mapped, and reshaped into a format that the Azure Health Data FHIR service can comprehend. This is where the data, once a mere collection of numbers, becomes a narrative a story of health and well-being.
There is however a-bit of translation and mapping magic required. At a basic level we have raw HealthKit messages arriving at pace via our Event Hub instance, the MedTech services job is to ingest, normalise, group and transform these messages into FHIR compliant datapoints and then finally Persist them through a Patient record mapping within in the FHIR service.
But, how is this done? do I need to add a couple of rabbit’s foots and eye’s of a newt? Thankfully not! There is no harming animals in this story…. To brew this MedTech magic potion we need two main elements:
Show me the way to go for a health tech device mapping…
The first piece of the puzzle is our device mapping which is quite aptly named. The device mapping enables the incoming raw data from the device (via the Event Hub) to be normalised through the use of a user defined mapping to group and consolidate measurements.
The mapping configuration transforms the device data into a normalised schema, simplifying the device data processing by providing a capability to map one device message into multiple normalised messages and visa versa.
For example a device could send multiple vital signs at once including body temperature, pulse rate, blood pressure and respiratory rate in a single message block.
Once the message has been through the device mapping and been through the normalisation process each multi measurement device message would be split out into four separate FHIR Observations with each representing a specific vital sign and the value sent by the device.
We’ve reached the health tech ‘data-stination’ of our dreams!”
The Destination mapping is the yin to the yang in this tale of wizarding magic as it provides the final destination transformation following the normalisation and grouping stage.
The normalised messages are processed and transformed into the FHIR specification and are then linked to a patient using a unique device ID, which is passed from the mobile device client.
At the heart of this transformation process sits the potion master, JSON. JSON is used as the translation language to map the normalised device messages into a FHIR compliant format, in this case the messages are transformed into FHIR Observations which can store the measurement data, provided a matching FHIR mapping has been configured in the JSON potion.
Once the transformation has been completed the MedTech service goes into match maker mode and searches the FHIR service for a suitable partner; retrieving any matching Device resources, along with its associated Patient resource, this digital dating service is all keyed using the device identifier which is present in the device message send from remote device.
Let the match making happen, forever health tech alone?
The final step in the potion brew is to choose what happens when no matching Device resource exists within the FHIR service, (queue forever alone meme). When this is the case we effectively have a new Patient or Device sending in data.
Thankfully the MedTech service has the answer to this challenge, we have a configuration option“Resolution Type”. We have two resolution modes to choose from in the MedTech configuration:
- Lookup – this option means the specific message is ignored if no device identifier is matched within the FHIR service, the next messages are then processed as normal.
- Create – means the MedTech service will create a minimal Device and Patient resource in the FHIR service if no match is found to support persistence of the messages.
Finally with our messages transmitted and transformed, the spells have been cast and the MedTech service has done its job. The next step in the mystical chain at the heart of the solution the hot smouldering cauldron of FHIR.
Did someone say FHIR starter, twisted FHIR starter?
So here we are at the centre of the universe in terms of our data persistence layer. Welcome to the world of the Azure Healthcare Data Services and Azure FHIR database.
This is the source of the wizards spells, the FHIR service acts as two things, a database and an interoperability engine, the crux of the power of FHIR and why it is such a source of innovation when it comes to Health Tech and why I obviously get quite excited about it.
- Azure FHIR is a managed FHIR service provisioned in the cloud
- It provides a FHIR standard based endpoint in Azure for data access and storage
- Enables Protected Health Dara management in a compliant cloud environment
- Using a SMART on FHIR proxy enables secure access for mobile and web clients
- All secured through Azure Role-based access control (RBAC) providing audit tracking for access, creation, modification and reads
What we have in FHIR is a service that enables a secure healthcare standards aligned data storage capability. We can use Azure FHIR to integrate with wider Patient records systems within a clinical environment using industry standard messaging and protocols a health tech dream.
So in essence Azure API for FHIR enables rapid exchange of data through Fast Healthcare Interoperability Resources. FHIR makes it easier for anyone working with health data to ingest, manage and share Protected Health Information (PHI).
This API based secure data environment enables storage and sharing of patient record data with other systems in the wider healthcare ecosystem, ultimately empowering an enhanced patient record experience and enabling clinical staff to make better informed decisions! Sounds awesome, that’s because it is.
To deploy enable this FHIRy service of awesomeness there are a couple of steps to success…
Show me your Health Data Services……
Azure API for FHIR isn’t a stand alone service it’s deployed from within the Azure Health Data Services which takes care of most of the main configurations; however there are a few key points for the deployment which needs consideration:
- The FHIR service needs to have a unique name as it is published on a hosted url which needs to be unique.
- The version needs to be set to R4 to ensure compatibility
- The versioning policy needs to be set to “Versioned”
- Post deployment be sure to enable “SMART on FHIR” is enabled to allow proxy of the authentication from the mobile device user
With service deployed the next step is to enable the connectivity from the mobile device and downstream endpoints, be that mobile device or any other IoT device.
This of course is a story of permissions aligned to the Azure RBAC as without a secured connection you will be unable to connect to the FHIR service. There are a few permissions that need to be enabled to support the transfer.
First of all there is permissions for the MedTech service itself where it will need “FHIR Data Writer” as shown.
Secondly the Enterprise Application which allows the Mobile device to connect requires Azure Event Hubs Data Receiver on the Event Hubs Instance
And that’s all folks, for now……
And that’s all folks, if you deploy and configure the above components, coupled with the iOS source code Application as detailed in the first Act, you should be able to log and send your HealthKit data to Azure FHIR from your Apple Watch!
Pretty damn awesome right? Feeling like a wizarding health tech master guru yet ?! Of course you are! But wait, I’m collecting all this awesome data, but whats the point in collecting it when you can’t see it how can I make any data driven decisions??
Well this is where we strap on our PowerPlatform capes and delve into the awesomeness that is PowerApps, did someone yell #PowerAddicts?
Yes you can connect to Azure FHIR and view all this lovely data using Power Apps, Power BI and start to do some more epic magic. Some would say that this is the even cooler piece to the puzzle… but unfortunately you will have to wait as I will reveal how it’s all possible in the final Act in this connected healthcare odyssey!
So, there we have it, another day another chapter closed in this Health tech story, as you drift off into the land of nod tonight (if you haven’t already) take a moment and have little thought around the possibilities unearthed here today to the future of community based care.
Gary
P.S. Have you concocted your own FHIRy tale with health-tech? Share your stories below, and let’s continue to start some FHIRs together!
