Free EMR Newsletter Want to receive the latest news on EMR, Meaningful Use, ARRA and Healthcare IT sent straight to your email? Join thousands of healthcare pros who subscribe to EMR and EHR for FREE!

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

Posted on December 3, 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 first section of this article introduced the common schemas for mobile health designed by Open mHealth, and the second section covered the first two design principles driving their schemas. We’ll finish off the design principles in this section.

Balancing permissiveness and constraints

Here, the ideal is to get accurate measurements to the precision needed by users and researchers. But many devices are known to give fuzzy results, or results that are internally consistent but out of line with absolute measurements.

The goal adopted by Open mHealth is to firm up the things that are simple to get right and also critical to accuracy, such as units of measurement discussed earlier. They also require care in reporting the time interval that a measurement covers: day, week, month. There’s no excuse if you add up the walks recorded for the day and the sum doesn’t match the total steps that the device reports for that day.

Some participants suggested putting in checks, such as whether the BMI is wildly out of range. The problem (in terms of public health as well as technology) is that there are often outlier cases in health care, and the range of what’s a “normal” BMI can change. The concept of a maximum BMI is therefore too strict and ultimately unhelpful.

Designing for data liquidity

Provenance is the big challenge here: where does data come from, how was it collected, and what algorithm was used to manipulate it? Open mHealth expects data to go far and wide among researchers and solution providers, so the schema must keep a trail of all the things done to it from its origin.

Dr. Sim said the ecosystem is not yet ready to ensure quality. For instance, a small error introduced at each step of data collection and processing can add up to a yawning gap between the reported measure and the truth. This can make a difference not only to researchers, but to the device’s consumers. Think, for instance, of a payer basing the consumer’s insurance premium on analytics performed on data from the device over time.

Alignment with clinical data standards

Electronic health records are starting to accept medical device data. Eventually, all EHRs will need to do this so that monitoring and connected health can become mainstream. Open mHealth adopted widespread medical ontologies such as SNOMED, which may seem like an obvious choice but is not at all what the devices do. Luckily, Open mHealth’s schemas come pre-labelled with appropriate terminology codes, so device developers don’t need to get into the painful weeds of medical coding.

Modeling of Time

A seemingly simple matter, time is quite challenging. The Open mHealth schema can represent both points in time and time intervals. There are still subtleties that must be handled properly, as when a measurement for one day is reported on the next day because the device was offline. These concerns feed into provenance, discussed under “Designing for data liquidity.”

Preliminary adoption is looking good. The schema will certainly evolve, hopefully allowing for diversity while not splintering into incompatible standards. This is the same balance that FHIR must strike under much more difficult circumstances. From a distance, it appears like Open mHealth, by keeping a clear eye on the goal and a firm hand on the development process, have avoided some of the pitfalls that the FHIR team has encountered.

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.