Continua Health Alliance – the wrong approach

by bsrubin on December 28, 2010

I recently posted about that magical place on the web where we all store of health data – the Personal Health Record.  Except we don’t.  What about compatibility at the device level?  Shouldn’t my heart rate monitor, weight scale, and blood pressure cuff all speak the same language?  That’s the idea behind the Continua Health Alliance.  Continua has a wonderful vision – but my prediction?  It isn’t going to happen.

Top Reasons Continua is Going to Die

  1. Continua is a closed standard.  You need to be a member and pay real $ to get access.  It isn’t big bucks – but this is the WRONG way to build a standard these days.  World-changing organizations start in the garage these days and by the time they join standards organizations their products are already built.
  2. Continua is bloated.  Want your Bluetooth health device to be Continua compliant?  You’ll need to support the Health Device Profile.  This is a higher-level protocol that many Bluetooth stack vendors do not support – and if they do it will cost you $, memory, and complexity.
  3. Meager support from hub devices and smart phones.  OK – so you went through the pain of making a Continua supported device.  Now life will be good an your device will connect to a bunch of cool stuff – right?  Nope.  iPhone 4 doesn’t support HDP.  Droid doesn’t support HDP.  In fact – after four and a half years of operation there is only ONE hub device and ONE cell phone that support Continua standards for Bluetooth.  Fail.
  4. It’s easy to get your data to the cloud in other ways – and once it’s there you can use Open Web APIs to connect it all together.  How do health devices get their data up today?  Bluetooth SDP, Ant+, WiFi, 3G, PCs, smart phones, home routers, and dedicated devices – the list is endless – almost no one uses Continua standards – but data still moves.
  5. It’s not cheap to get tested for Continua compliance.  They appear to be taking the a heavier regulatory approach to certification – ala FDA, FCC, and Apple.

What do we really need?

  1. Truly open standards that are freely published and free to use.
  2. Adopt the an Android-like self-certification process for Continua devices – like this: “There is no cost to obtain Android compatibility for a device. The Compatibility Test Suite is open-source and available to anyone to use to test a device.”
  3. Both devices and services for health should be open.  That way if standards compatibilities arise (as they inevitably will) – individuals or groups can adapt the software and hardware to suit their needs.

I share the Continua vision - seamless connectivity and data transfer between consumers, patients, doctors, social circles, services, etc.  And for all the knocking – Continua has made admirable efforts to move us all in the right direction.  Let’s hope they pivot the standard more towards open – and we may see progress on adoption.

Share
  • http://armilegge.com Armi Legge

    I completely agree with what you said about Continua.  It needs to be a free and open source aggregation in order to really work.  It seems like they're really blowing this up far bigger than it can be at first, instead of letting it adapt to the consumer's demands.  Like most things of that nature, you're right, it's going to die.

    It seems like a better solution to have independent groups making their own devices, and then allow them to work together in order to solve their own needs.  Love to hear your thoughts.

    It's good that they're at least trying though:)

  • Alan Viars

    Do you know about OMHE Mircosyntax? http://code.google.com/p/omhe/  We are always looking for more volunteers to work on the project.OMHE Microsyntax for Medical Device Interoperability: An Open-Source Alternative to the Continua AllianceOMHE (Open Mobile Health Exchange), pronounced “ooommm” is an open-source microsyntax for medical devices, mobile text messaging, Twitter®, smart phones, and any system capable of sending a short text string. OMHE’s goal is to provide device interoperability between systems that transmit or receive fitness and wellness information. Its designed for use by both humans and machines. Unlike XML or JSON its simple enough that in most cases a person can type or read OMHE. OMHE still has enough syntactical structure to be parsed and used by machines or software. Another key design decision in OMHE is that OMHE does not define the mode of transport, but simply the data itself. This means OMHE can be blurted out by an electronic weight scale or sent from a human via mobile text message.OMHE was developed by group of health hackers interested in making it easier to create systems that communicate health information. As an open source specification, there is no license or club to join. Unlike the Continua Alliance which costs thousands to join and who’s utility is questionable, OMHE is a grassroots project defining a practical solution to interoperability. Those interested in contributing code, content, time or funding to the OMHE project should first request to join the Google Group at http://groups.google.com/group… OMHE project is hosted on Google Code at http://code.google.com/p/omhe/.

Previous post:

Next post: