Uncategorized

Three Rules For a Healthy mHealth App

Jaan SidorovAccording to this Wall Street Journal article, the prospect that “your doctor may soon prescribe you a smartphone app” is ushering in a new era of m-healthiness.

e-Researchers from marquee academic institutions are assessing the impact of handheld apps on medication use, symptom management, risk reduction and provider-patient communication. There’s not only an technology platform but an accompanying library of tailored e-prompts, e-reminders, e-pop-ups, e-recommendations, e-messaging, e-images and e-videos.

In other words, mix one part app with one part patient and bake until quality goes up and costs go down.

Unfortunately, however, what the article failed to mention is that much of that app content is based on information that is freely available in the public domain, and that these app developers have reconfigured and adapted it according to the variable interests, expertise and culture of their sponsoring institutions.

While policymakers and researchers would like to believe that on-line and public-domain health information is a commodity, the fact is that buyer, purchaser and provider organizations have been accessing, downloading and branding it for years.

They’ve taken a special pride of ownership in the other half of the wording, editing, formatting and presentation of that content.  That’s what makes it “theirs” for both their providers and their patients.

After all, all healthcare is local.

This has important implications for the smartphone app industry.  While the academic e-researchers and business e-developers dream of having their apps used by delivery systems everywhere, the problem is that their apps are often intertwined with their own organizations’ content.

In other words, you can have any breast cancer, heart failure or post-hospital discharge smartphone-based solution that you want, just so long as you also import their prompts, reminders, pop-ups, recommendations, messages, images and videos.

What then, are three rules to have your smartphone app be adopted by health systems everywhere?

1) Architecture Trumps Content: Smart app developers understand that the value proposition of the underlying technology architecture is separate from the value proposition of the content.  The app itself needs to be independently stable, secure and snappy with minimal branching logic, an easy-to-use interface and freedom from annoying bugs, whether it’s heart failure for a hundred patients in Halifax or a dozen persons with diabetes in Des Moines.

2) Architecture Must Support Any Content: Very smart app developers also understand that the architecture should be able to accommodate any content that is preferred by their customers. If ABC Regional Health System wants their in-house policies, procedures, pamphlets, web-pages, in-house guidelines and electronic record prompts to be reflected in a smartphone app, then the app’s framework should be able to import it in a seamless plug and play fashion.

3) Architecture Should Come With Content: That being said, not every buyer, purchaser or provider will have all the content needed to manage a target population. That means app developers will need to have generic content ready to go to fill in the gaps.

Bottom line:

The business case for apps may be similar to selling a house.  First off, make sure the foundation is solid and the roof is intact.  Be prepared to move knock out walls and move windows, if that’s what the buyer wants.  And, if the house needs to be furnished with some furniture, do it; if the buyer wants some or all of their furniture to furnish the house, do it.

<em>Jaan Sidorov, MD is chief medical officer at MedSolis.</em>

Categories: Uncategorized

1 reply »

  1. Although I’m unsure of how the American Healthcare system operates completely, in the UK I can vouch for it being just as convoluted. Having friends in care jobs and a girlfriend training to be a midwife, it’s apparent that the current system is failing, and failing because the resources aren’t there to support the people that need it most, or in fact, they are, but they’re in so many different formats, hosted by different companies, organisations and libraries that compiling the information and displaying it in a way which is consistent is always going to be a problem.

    One of the biggest factors in delivering great medical care is minimising the time spent filling out paperwork, filing it, returning it to the right people, having second opinions, getting signatures and ordering repeat prescriptions for people with long-term conditions. This time could be better spent with the patient, making them comfortable, assessing any future needs and being sociable with elderly and disabled patients who need more care.

    The issue you have is that there are many privacy issues and access rights regulations that prevent systems like this from being successful. If you look at these guys they’ve got a digital solution for care homes that streamlines a lot of the processes and focuses just on one area of healthcare rather than trying to spread themselves too wide.

    Where many app builders fail is not really understanding the market they’re working in. Developers inherently see the logical process of what needs to happen in order to get Patient A, resources X, Y and Z. However, in practise there are many ergonomics such as ease of use, the need for medical libraries, schedules, fallbacks and communications that need to happen in an order defined by the government, or local healthcare organisations that need bringing upto date first.