Apps Will Astonish

"Now this is meaningful use!"

In case you think the future for healthcare apps will be characterized by health information technology (HIT) "dead zones" of free downloads, fun gadgetry and vacuous consumerism with nothing to show for it, you should take a look at  this article appearing in the peer-reviewed journal Cell Systems. 

If authors Kenneth Mandl, Joshua Mandel and Isaac Kohane are even half right, "apps" could truly revolutionize HIT.  They argue that a superimposed "apps layer" ecosystem will demolish the "walled gardens" of EHRs and allow for true information sharing across clinics, systems and regions.

And that's just for starters.

As the Population Health Blog understands it, "Application Programming Interfaces" (or "APIs") will enable multiple third party apps to bridge to legacy EHRs.  That, in turn, will catalyze the creation of newer and better user experiences that reconcile doc and patient preferences with the current clunky one-size-fits-all EHRs. 

The result?

1. A "mash up" of "risks, trends and trajectories" with external data sources, telehealth and decision support systems. Why should a patient with cancer and his/her oncologist use the same computer operating environment as a patient and a dermatologist dealing with a rash?  Even better, apps can be easily substituted if a better one comes along.

2. Never mind ICD-9 or ICD-10, apps will be the "afferent limb" that links your unique genetic and phenotypic "diagnosis code" to the efferent limb of tailored treatment protocols.

3. Apps can collect and arrange the data from numerous devices at scale that not only allow for treatment compliance or disease management outside of the clinic, but the early identification of an emerging epidemic or medication side effects.

To achieve this, the authors recommend the EHR manufacturers not only retool, but adopt a uniform and open source approach to API development. Purchasers of EHRs consider should consider the future of APIs in their requests for proposals (RFPs).  They also recommend that research funding be directed toward apps that can operate across multiple information platforms. It would also help if there was a "seal of approval" process for app development that wasn't too closely tied to industry or too tied up in the regulatory miasma of government.

Telehealth Helps!

... and have you taken your pills today?

Are you in the "telehealth" business? 

Do you sell, buy, broker or provide remote monitoring, telephonic follow-up, internet-based patient management, handheld health apps, video-support or home-based medical devices? 

Then you'll probably want to download this 32 page paper.

Bashur and colleagues set out to review every good (defined as any controlled study with a valid concurrent comparison group with at least 150 study subjects) research paper on the impact of telehealth on three conditions: heart failure, stroke and chronic obstructive pulmonary disease.

177 references later, their conclusion is that telehealth - over a broad range of patient types (age, illness severity and co-morbidities), level and intensity of patient participation, provider types (nurses vs. physicians with or without an explicit protocol) - increases quality of care and reduces unnecessary utilization. 

In other words, telehealth is substitutive.  It doesn't add to inefficient services, it replaces them with something cheaper.

The Population Health Blog already knew that, of course, but it's handy to have an authoritative text that catalogs every published study.

What the PHB didn't quite know:

The official definition:

Telehealth (e-health, mobile health, m-health), connected health) is the delivery of healthcare via information and communication technology.

Telehealth jargon: when you launch it, make sure you have:

1. Fidelity (use in an appropriate setting with optimal strength and integrity),

2. Maturation (the technology may not have fully integrated personnel, other technology and patients to achieve maximum efficiency) and

3. Bundling (where the technology is vulnerable to how other concomitant supporting services are configured.