One (micro) Syntax to Join Them All

Mike Kirkwood

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?
 

2 Comments

#1 | Thu, 02-04-10 01:09 | Peter

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 | Mon, 02-08-10 04:27 | Bill Schuller

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 Comment

Your Name:









Thanks for your comment. The words in the CAPTCHA box come from old book texts that are being scanned and stored by the Internet Archive. By entering the words in the box, you prove you are not a bot and also you help proofread the books. If the sample you see is too hard to read, simply click the recycle button to get another two. Don't forget to put a space between the words.


 

Archives - This site operates under a Creative Commons License.