How Open mHealth Designed a Popular Standard (Part 1 of 3)

Posted on December 1, 2015 I Written By

Andy Oram is an editor at O'Reilly Media, a highly respected book publisher and technology information provider. An employee of the company since 1992, Andy currently specializes in open source, software engineering, and health IT, but his editorial output has ranged from a legal guide covering intellectual property to a graphic novel about teenage hackers. His articles have appeared often on EMR & EHR and other blogs in the health IT space. Andy also writes often for O'Reilly's Radar site (http://oreilly.com/) and other publications on policy issues related to the Internet and on trends affecting technical innovation and its effects on society. Print publications where his work has appeared include The Economist, Communications of the ACM, Copyright World, the Journal of Information Technology & Politics, Vanguardia Dossier, and Internet Law and Business. Conferences where he has presented talks include O'Reilly's Open Source Convention, FISL (Brazil), FOSDEM, and DebConf.

If standards have not been universally adopted in the health care field, and are often implemented incorrectly when adopted, the reason may simply be that good standards are hard to design. A recent study found that mobile health app developers would like to share data, but “Less progress has been made in enabling apps to connect and communicate with provider healthcare systems–a fundamental requirement for mHealth to realize its full value in healthcare management.”

Open mHealth faced this challenge when they decided to provide a schema to represent the health data that app developers, research teams, and other individuals want to plug into useful applications. This article is about how they mined the health community for good design decisions and decided what necessary trade-offs to make.

Designing a good schema involves intensive conversations with several communities that depend on each other but often have trouble communicating their needs to each other:

Consumers/users

They can tell you what they’re really interested in, and give you surprising insights about what a product should produce. In the fitness device space, for instance, Open mHealth was told that consumers would like time zones including with timing data–something that currently is supported rarely and poorly. Manufacturers find time zones hard to do, and feel little competitive pressure to offer them.

Vendors/developers

They can fill you in on the details of their measurements, which might be hard to discern from the documentation or the devices themselves. A simple example: APIs often retrieve weight values without units. If you’re collecting data across many people and devices for clinical or scientific purposes (e.g., across one million people for the new Precision Medicine Initiative), you can’t be guessing whether someone weighs 70 pounds or 70 kilograms.

Clinicians/Researchers

They offer insights on long-range uses of data and subtleties that aren’t noticeable in routine use by consumers. For example, in the elderly and those on some types of medications, blood pressure can be quite different standing up or lying down. Open mHealth captures this distinction.

With everybody weighing in, listening well and applying good medical principles is a must, otherwise, you get (as co-founder Ida Sim repeatedly said in our phone call) “a mess.” Over the course of many interviews, one can determine the right Pareto distribution: finding the 20% of possible items that satisfy 90% of the most central uses for mobile health data.

Open mHealth apparently made good use of these connections, because the schema is increasingly being adhered to by manufacturers and adopted by researchers as well as developers throughout the medical industry. In the next section of this article I’ll take a look at some of the legwork that that went into turning the design principles into a useful schema.