Shimmer Addresses Interoperability Headaches in Fitness and Medical Devices

Posted on October 19, 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.

The promise of device data pervades the health care field. It’s intrinsic to patient-centered medical homes, it beckons clinicians who are enamored with hopes for patient engagement, and it causes data analysts in health care to salivate. This promise also drives the data aggregation services offered by Validic and just recently, the Shimmer integration tool from Open mHealth. But according to David Haddad, Executive Director and Co-Founder of Open mHealth, devices resist attempts to yield up their data to programmers and automated tools.

Every device manufacturer has its own idiosyncratic way of handling data, focused on the particular uses for its own device. According to Haddad, for instance, different manufacturers provide completely different representations for the same data, leave out information like time zones and units, and can provide information as granular as once per second or as vague as once per day.. Even something as basic as secure connectivity is unstandardized. Although most vendors use the OAuth protocol that is widespread on the Web, many alter it in arbitrary ways. This puts barriers in the way of connecting to their APIs.

Validic and Shimmer have to overcome these hurdles one by one, vendor by vendor. The situation is just like the burdens facing applications that work with electronic health records. Haddad reports that the cacophony of standards among device vendors seems to come from lack of attention to the API side of their product, not deliberate obstructionism. With all the things device manufacturers have to worry about–the weight, feel, and attractiveness of the object itself, deals with payers and retailers offering the product, user interface issues, etc.–the API always seems to be an afterthought. (Apple may be an exception.)

So when Shimmer contacts the tool makers at these vendors, most respond and take suggestions in a positive manner. But they may have just one or two programmers working on the API, so progress is slow. It comes down to the old problem in health care: even with government emphasis on data sharing, there is still no strong advocate for interoperability in the field.

Why did Open mHealth take on this snake’s nest and develop Shimmer? Haddad says they figured that the advantages of open source–low cost of adoption and the ease of adding extensions–will open up new possibilities for app developers, clinical settings, and researchers. Most sites are unsure what to do with device data and are just starting to experiment with it. Being able to develop a prototype they can throw away later will foster innovation. Open mHealth has produced a detailed cost analysis in an appeal to researchers and clinicians to give Shimmer a try.

Shimmer, like the rest of the Open mHealth tools, rests on their own schemas for health data. The schemas in themselves can’t revolutionize health care. Every programmer maintains a healthy cynicism about schemas, harking back to xkcd’s cartoon about “one universal standard that covers everyone’s use cases.” But this schema took a broader view than most programs in health care, based on design principles that try to balance simplicity against usefulness and specificity. Of course, every attempt to maintain a balance comes up against complaints the the choices were too complex for some users, too simple for others. The true effects of Open mHealth appear as it is put to use–and that’s where open source tools and community efforts really can make a difference in health care. The schemas are showing value through their community adoption: they are already used by many sites, including some major commercial users, prestigious research sites, and start-ups.

A Pulse app translates between HL7 and the Open mHealth schema. This brings Open mHealth tools within easy reach of EHR vendors trying to support extensions, or users of the EHRs who consume their HL7-formatted data.

The Granola library translates between Apple’s HealthKit and JSON. Built on this library, the hipbone app takes data from an iPhone and puts it in JSON format into a Dropbox file. This makes it easier for researchers to play with HealthKit data.

In short, the walls separating medicine must be beaten down app by app, project by project. As researchers and clinicians release open source tools that tie different systems together, a bridge between products will emerge. Haddad hopes that more widespread adoption of the Open mHealth schema and Shimmer will increase pressure on device vendors to produce standardized data accessible to all.