Nearly one in five adults in the US currently owns a wearable device. Whether that’s an activity tracker or a smartwatch, it doesn’t really matter. What follows is that there’s a lot of health data out there ripe for the picking. Estimates from Soreon Research suggest that 1.3 million lives will be saved using healthcare wearables by 2020. Almost half of all patients are prepared to to use them and hospitals are already prescribing them. Getting any meaningful data to the physician at the other end, though, is where the process can break down.
The problem is that, traditionally, there has been something of a disconnect between the Fitbits of this world, who make the devices, and hospitals looking after the patient EHRs. So, how are clinicians supposed to make use of all this? How do you get that wearable data into your workflow and in front the right person when they need it? Here are six ways. N.B. Some are better than others.
Why doesn’t Fitbit do it?
First, a little note on the problem. After all, why don’t the wearable manufactures do the leg work for the patients? Isn’t improving health what they’re selling to the customers? To a degree, it is but really they’re in the business of selling hardware and then often selling the anonymized data that those devices send to their servers for some healthy bonus revenue.
Making it possible for their apps to feed into patients’ EHR is less lucrative or, indeed, not lucrative at all for the wearable manufacturers. There’s licensing, medical certification of the hardware, responsibility for the measuring and the accuracy of the data and it’s all a bit beyond the remit of a company who just wanted everyone to wear its cool new bangle.
As it stands, it’s only really Apple who is making any inroads towards direct EHR compatibility with FHIR (Fast Healthcare Interoperability Resources) although that’s more about taking data from a patient’s record and pushing it to their mobile Health app and not the other way round. More on FHIR another time.
Without any quick and direct wearable data access, then, these are the options left open to hospitals and their clinicians.
1. Get patients to show their apps
It doesn’t give much information on how and when data was gathered but the non-technical and obvious solution is for a patient simply to show their physician the wearable app on their mobile phone when they go to their next appointment. For tracking in-between visits, then they could always exchange screengrabs via email or SMS. It’s cheap and simple but it’s also a big fistful of sand into the gears of a clinician’s workflow. How is all this supposed to integrate with a health record and what about being able to consistently monitor a patient whenever needed?
There’s also issues of data trust because screengrabs and a quick flick at an app don’t offer much in the way of provenance, so it’s understandable if a doctor takes what they’re shown with a rather large grain of salt and the patient themself then becomes rather demotivated at the dismissive attitude they’re received.
While it’s easy to ignore, though, it should be noted that even this rudimentary approach has value. Data about steps taken or even weight loss isn’t so complicated that a patient would make a mess of recording it and, even if the wearable in question is not endorsed by the hospital, it may still show a useful trend.
So, patients, don’t be put off if this is your only option and, doctors, do make more than a show of taking a look at the screen.
2. Head to the source – ask the wearable manufacturer
Once a wearable makes its measurements, that information is stored on the servers of the company that made it. You want information gathered on a Garmin Vivofit, you ask Garmin.
As it stands, the patients can access that data through their mobile apps but, as discussed, there’s no other pre-built conduits for that data to slide along. Instead the likes of Garmin, Fitbit, Facebook, Apple and all these big companies create an API – an application processing interface – which is a set of tools that a developer can use to build something to get the information they need from those servers. In the context of wearables, what we’re talking about is Samsung or Nokia effectively saying that they’re not going to waste their time and money making their wearables all nice and compatible with your EHR but they are going to leave out the bits and bobs for the hospital system and EHR developers to make those connections if they want to. So, yes, head to the source but it’s only part of the solution.
3. Get the hospital software technicians to work with Fitbit et al’s APIs
It’s a good idea but it’s very, very big ask of the developer teams within the healthcare system. Hospitals just aren’t really set up to do this themselves. They’ve bought and integrated EHR platforms from external providers at great expense and, even if the hospitals want to, they’re very short on the right kind of staff, with the right kinds of skillsets. There’s already enough work for the technical team in keeping their current EHR from falling over. It’s possible you’ll find a dev with a big heart, a can-do attitude and some time in their schedule but you might want to have a plan B up your sleeve.
4. Get the EHR companies to build in wearable compatibility
Pulling information from one database and integrating it into another is typically complicated and the kind of operation performed by workers developing complex systems more akin to banking and other kinds of enterprise technology. EHR systems currently aren’t as sophisticated as that. The teams that create and manage them don’t really have the resources to be the vanguard of this charge and the companies behind them might well see such attempts at integrating wearable data into the workflow as not really worth their time.
Again, it’s not in the EHR vendor’s business model to make money from wearable integration and, even if the hospitals are crying out for it, their EHR contracts have them over a barrel. Some have spent into the billions to get their systems up and running. They’re not about to switch which is why other companies with all the right software architecture skills have popped up to help bridge the gap. It’s a good idea and maybe something that will become part of the EHR buying decision in the future but it’s a dead end for now.
5. Wearable data aggregators
Spotting the obvious gap in the system, there are companies who specialize in aggregating the wearable information from all the various device manufacturer sources into a single data type. They then pipe that stream over to the hospitals who still have to figure out how to integrate it all into their systems. That still means getting the hospital’s developers at their to do the work but they only have a single API to deal with instead of the whole spectrum.
Using an aggregator is certainly one of the more realistic options on this list. There are aggregator companies out there offering this service and the hospitals have the resources to make use of them but you get what you pay for and there’s something of the cheap and dirty about this solution. It will get that wearable info in but the aggregators don’t do anything much to make tangible sense of that data. It doesn’t offer much at the patient end either but, sure, job done.
6. Dedicated remote monitoring software
The more sophisticated solution to all of this is a company that will not only pull that data into an EHR but one that will provide an end-to-end solution from a dedicated app on the patient’s phone all the way over to a meaningfully presented set of measurements at the clinician’s monitor screen and, yes, of course, this is what we do at Overlap and there are other good companies that offer similar software. By all means, go and investigate.
As far as we’re concerned, an overarching approach is going to be far better for getting patient-generated data into the clinician’s workflow. Rather than pulling from a single device – and plenty of patients will have multiple sensors on them at any one moment – dedicated remote monitoring software gives the opportunity to take multiple kinds of data from a patient and create a more detailed picture of their health. So, it’s not just ‘how much are you walking’ but ‘how much are you walking and how are you feeling’.
That’s all gathered together on the patient’s mobile app via Bluetooth, Wi-Fi and from the patient’s own manual inputs too and then is sent up into the remote monitoring software provider’s servers from where it’s pushed out to hospital EHRs. The data arrives at the EHR most usually within a separate remote monitoring tab of the record. Clinicians can then track their patients during their time away from hospital and, once it’s time for their appointment again, it’s all there together on-screen.
The other key benefit is that an end-to-end solution is more secure with one platform protecting the data all the way from the patient to the physician.
So, some choices; not many, we’ll grant you, but choices.
Which way will you go?
Leave a Reply