One (micro) Syntax to Join Them All

At the recent San Francisco Quantified Self Meetup, I had a chance to share the OMHE Open Mobile Health Exchange microsyntax standard.  This post goes into more detail about how it works and what is the end game for such an effort.

It is being developed in coordination with the Microsyntax.org effort and the project is hosted on Google Code.  This group was started by Alan Viars, Alan’s company Videntity has been contributing to the project and building a twitter bot to respond to OMHE Twitter messages.  Several other companies, including Polka (disclaimer, author is founder of Polka and contributor to OMHE) and Keas have signed on to support this standards effort, and more have expressed interest in jumping on board.


What is a microsyntax?

A
language description that is designed to be human readable,
interoperable between devices, and able to be parsed by a machine. 
OMHE is designed to be a flavor of Microsyntax focused on mobile health
exchange, data that is used between devices to capture activities of a
person’s health status.

omhe.jpg

What are benefits of such a thing?

Today,
it is very difficult to share health information between systems.  In
addition to the numerous challenges that exist between the borders of
the healthcare system, there are significant challenge in the personal
health tools.   This is due to lack of standards as well as a common
place to share information across systems.   It can be argued that
there wasn’t a real need as each tool maintained it’s own domain and
system lock on the user.  

That time is past us.  It is clear
that we (all) benefit when we can can connect our personal information
streams, both in correlating them together and in sharing them across
the borders of the health providers.

In a base-case example, if
you record your weight every day, it makes sense to be able to share
this with your doctor, nutritionist, and others that are on your health
team.   If you’re also tracking your diet, exercise, mood, and blood
pressure at the same time, it is clear that observing these
correlations can be a powerful tool to learn more about personal
patterns and impact behavior with this new combined knowledge.

Samples of it in action

One
of the big opportunities for the development community is the ability
to write specialized applications (like weight tracker) that also
connect to other systems by using OMHE as a middle layer for semantic
interoperability.  In other words, with OMHE creators and OMHE
acceptors in the marketplace, a person’s health logs can be exchanged
between systems and the person’s data will no longer be “locked” into a
device or website.  

A few samples that the group is working on a first-mover implementations shows promise for this concept:

belkinBPMonitor.jpgPulling the stream from existing devices in the market shows the power of the concept of OMHE.  

Although
ideally, OMHE will be embedded directly into devices as an
interoperability layer in the future, by getting started with existing
technology in the market and outputting it as OMHE, a large base of
compliant devices can be utilized into the market early in the
lifecycle of the project.

This provides a layer on top of the
communication layer that is already existing with this device, whether
it is USB, ANT, or BlueTooth, OMHE is agnostic.

To connect the
stream from this device to other sources (let’s say the Blood Pressure
device at the clinical provider) the OMHE project is offering it’s
parser as well as example code on how to build some basic web front
ends to showcase applications.

bpOMHE.jpg

In
Polka, one of the first implementers of OMHE, the Polka application
allows a user to generate compatible microsyntax from Polka into the
users Twitter stream.

sarahPolkaOMHE.jpg

When
Sarah’s pushes “include in my Twitter timeline”, her microsyntax is
appended to her Tweet and uploaded to her stream.  This generated a
piece of code (a hash in this case) that allows a machine parser to
read and interpret her observation.

sarahOMHE.jpg

What is the goal end-state for this project?

In
the meeting in San Francisco, Gary Wolf asked the inevitable question
“what if it works”.  The answer is simple.  More devices and tools will
contribute to the total picture of a person’s health, and the person
will be free to move between systems and devices freely.  This will
free up development resources to focus on applications being great
instead of data integration being a pain.  It’s a lofty goal, but one
that’s surely worth the investment in time.

Kevin Kelly asked
another important question, “if this is successful, will we ever see
it or will it be in the background?”.  The answer we aim for is “the user shouldn’t even know it is there”.  If OMHE is truly successful, a normal user
will not interact with OMHE, instead, they will simply know that their
information is plug and play and is leveraged in their personal
ecosystem.  The greatest compliment this project
could receive is that no one knows it exists.

What do you
think, could OMHE help solve a problem that is worth solving?  Would
you prefer tools that you use to quantify yourself to be portable?

This entry was posted in Personal Projects and tagged , , , . Bookmark the permalink.

2 Responses to One (micro) Syntax to Join Them All

  1. Peter says:

    This sounds good to me. I have used nike plus for the past 3 yrs, logging 1500+ miles. I just started using a garmin gps watch. It would be nice if they used the same standards. It would be even better if the results could be easily exported to polka, or some other app of my choice automatically.
    I don’t care too much about portability…or real time display. I usually only sync my watch (formerly my ipod) with my computer every week or so to upload my runs. The main reason use this now is to track my workout data by week/month/year.

  2. Bill Schuller says:

    > the person will be free to move between systems and devices freely.
    This is often harolded as the interoperability holy grail. Because we so often don’t have this basic ability now, thinking of open standards enabling you to use whichever single solution you choose, and move your historical data between them is where the line is usually drawn. We should instead be thinking of feeding the same data to several solutions simultaneously, each with its strengths and slight different perspective on the data.
    Of course, portability should be a basic tenet of any interoperability scenario. Perhaps even more important is the ability not to just take a copy of your data, but remove your data completely from a third-party solution. Privacy is not hiding your data after all, it’s controlling your data. Your data is worth nothing hidden away compared to the value it can present when correlated with other data or examined by a trained or even the public eye.
    There is a fine line between interoperability and integration, and OMHE is a syntax definition, not a transport. In fact, the current implementations of OMHE support Twitter, which is a Publish-Subscribe transport enabling this sort of streaming data to _multiple_ solutions. The “data sector” needs an more flexible, open and optimized transport for these small events. I’m not sure what to call it, but it’s coming soon.

    -Bill Schuller

Leave a Reply

Your email address will not be published. Required fields are marked *


*

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

Notify me of followup comments via e-mail. You can also subscribe without commenting.