App-t Development for Next Generation Healthcare
I am a recent addition to the “smartphone revolution.” While I never doubted the usefulness of these devices, I was simply steadfast in holding out for a reduction in data rates. I figured that with more users adopting smartphones, eventually, providers would reduce rates to get the rest of us who were waiting for a more affordable plan to hop aboard the bandwagon.
Finally realizing that this was unlikely to happen anytime soon, I folded (like a cheap suit…) and signed a new contract for a brand new, shiny Samsung Galaxy. The many advantages simply outweigh the cost concerns I had, and every couple of days, it seems I find a new benefit to having the device that I hadn’t even realized might be useful.
One of the offerings that many smartphone users have explored are the medical/healthcare apps. Whether using them for monitoring of vital signs during an exercise routine or tracking calories for a weight-loss program, these apps are becoming a daily touch point for users and their health. If nothing else, it keeps them conscious of their well-being, and that alone has to be considered a benefit.
What I’ve also come to realize is that any company developing such an app (whether it be healthcare related or not) has many more concerns to address beyond the general usefulness of their offering.
One of the first things I was shocked to find with my smartphone was how quickly the battery drained. Granted, much of that is due to the large screen, but since I was able to specifically delve into the battery “report” and see what was using up my power the most, I suddenly became very selective in which apps I allowed to run on the device (as much as I could anyway). Anything that I wasn’t using at all was immediately shut down completely or uninstalled. Any app I download that shows up on this power “report” page better be truly worthwhile or it’s likely to get the boot.
Just as power is a concern for mobile medical device developers, power consumption has to be on the minds of any designers of healthcare apps. If using the app results in having to charge the phone more often, users are going to get frustrated and stop using it. If they feel the need to plug the phone in while the app is in use, they’ve completely eliminated the purpose of having an app on a mobile phone to accomplish the task.
Additionally, since my plan provides me with a fixed amount of data, that report also went on my “watch list.” I set up alerts to let me know when I get too close to my limit and have a hard stop set up to prevent charges should that limit be reached.
Again, developers need to address how often data is sent and the size of the data packet so as to not seem like a burden for the user. And I found that apps that used significant data while not being put into active use by me were more “offensive” than those that only broadcast data when I had the program open. If data needs to be transmitted at fixed times – regardless of whether the user has the app open or not – perhaps allowing the user control over that would alleviate any concerns of data being sent when the person is not using the app actively.
These issues are nothing new to medical device manufacturers who are developing standalone, mobile healthcare technologies. Addressing data transmission and power consumption is something they have been dealing with long before smartphones and apps were offered. However, given that those devices are typically serving one purpose (i.e., the medical application), designers need not be concerned with the user’s impression of these factors (power consumption and data transmission) since the user is likely not monitoring them as closely as they are with apps on a smartphone. Sure, developers certainly need to optimize these elements, but it’s unlikely the user is going to form an opinion based around them.
When it comes to app development in the healthcare space, there are an array of other considerations designers need to keep in mind. FDA oversight, the use of accessories and connectivity with them, aesthetics, and usability are all additional and very relevant factors that need to be addressed. This likely would ensure continued usage of an app. Any one of these design elements can derail user adoption and kill an app. But these are true of most other medical devices being used in home healthcare today. The user’s perception of a medical app based on data transmission and/or power consumption is fairly unique to medical device apps and something developers certainly need to keep at the forefront of their minds.