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.

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

Posted on December 2, 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 previous section of this article introduced the intensive research and consultation strategy used by Open mHealth to develop a common schema for exploiting health data by app developers, researchers, clinicians, individuals, and manufacturers of medical and fitness devices. Next we’ll go through the design principles with a look at specific choices and trade-offs.

Atomicity

Normally, one wants to break information down into chunks as small as possible. By doing this, you allow data holders to minimize the amount of data they need to send data users, and data users are free to scrutinize individual items or combine them any way they want. But some values in health need to be chunked together. When someone requests blood pressure, both the systolic and diastolic measures should be sent. The time zone should go with the time.

On the other hand, mHealth doesn’t need combinations of information that are common in medical settings. For instance, a dose may be interesting to know, but you don’t need the prescribing doctor, when the prescription was written, etc. On the other hand, some app developers have asked the prescription to include the number of refills remaining, so the app can issue reminders.

Balancing parsimony and complexity

Everybody wants all the data items they find useful, but don’t want to scroll through screenfuls of documentation for other people’s items. So how do you give a bewildering variety of consumers and researchers what they need most without overwhelming them?

An example of the process used by Open mHealth was the measurement for blood sugar. For people with Type 1 or Type 2 diabetes, the canonical measurement is fasting blood sugar first thing in the morning (the measurement can be very different at different times of the day). This helps the patients and their clinicians determine their overall blood sugar control. Measurements of blood sugar in relation to meals (e.g., two hours after lunch) or to sleep (e.g., at bedtime) is also clinically useful for both patients and clinicians.

Many of these users are curious what their blood sugar level is at other times, such as after a run. But to extend the schema this way would render it mind-boggling. And Dr. Sim says these values have far less direct clinical value for people with Type 2 diabetes, who are the majority of diabetic patients. So the schema sticks with reporting blood sugar related to meals and sleep. If users and vendors work together, they are free to extend the standard–after all, it is open source.

Another reason to avoid fine-grained options is that it leads to many values being reported inconsistently or incorrectly. This is a concern with the ICD-10 standard for diagnoses, which has been in use in europe for a long time and became a requirement for billing in the US since early October. ICD-9 is woefully outdated, but so much was dumped into ICD-10 that its implementation has left clinicians staying up nights and ignoring real opportunities for innovation. (Because ICD is aimed mostly at billing, it is not used for coding in Open mHealth schemas.)

Thanks to the Open mHealth schema, a dialog has started between users and device manufacturers about what new items to include. For instance, it could include average blood sugar over a fixed period of time, such as one month.

In the final section of this article, we’ll cover the rest of the design principles.

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.

Will 2013 Be The Year Of EMR/Device Convergence? Nope.

Posted on December 31, 2012 I Written By

Anne Zieger is veteran healthcare consultant and analyst with 20 years of industry experience. Zieger formerly served as editor-in-chief of FierceHealthcare.com and her commentaries have appeared in dozens of international business publications, including Forbes, Business Week and Information Week. She has also contributed content to hundreds of healthcare and health IT organizations, including several Fortune 500 companies. Contact her at @ziegerhealth on Twitter or visit her site at Zieger Healthcare.

Increasingly, healthcare organizations are introducing wireless medical devices which can hook up to EMRs.  And this makes a lot of sense, given that data from, say, infusion pumps offers a critical part of a patient’s overall picture and can boost safety as well.  On the other  hand, equipment and integration costs have held back hospitals from widespread convergence.

Given these opposing forces, it it looks like we’re poised at a point where adoption of wireless, EMR-connectible devices could gather momentum or stall out and drag into 2014 or beyond. But don’t get your hopes up for 2013. Here’s some trends that are likely to drag down the progress of medical device connectivity for the coming year:

* Device interoperability not required for Stage 2:  According to one blogger, William Hyman of Medical Connectivity, Stage 2 of Meaningful Use doesn’t directly doesn’t require providers to connect most traditional devices to the EMR. (Imaging and lab systems are exceptions, he notes.)  Well, if Stage 2 doesn’t require smart devices, must less connected ones, it’s hard to imgine CIOs making this a priority.

FCC initiatives to benefit wireless medical device use aren’t mature yet:  The FCC is taking several steps to encourage the use of connected medical devices. These include promoting the use of medical body area networks (MBANs), for which it has reserved spectrum, as well as making frequencies available for medical micropower networks. The agency is also working on making it easier to experimentally license spectrum for wireless health test beds for wireless medical devices.  These initiatives are just getting rolling, however.

Medical devicemakers face big EMR challenges:  As Medical Connectivity’s Tim Gee notes, creating device software that will smoothly pump data into an EMR is actually a pretty big challenge.  Devicemakers will need to export data in digital form, work with a central server aggregating data from your medical devices and translate you device data into HL7 for the EMR. Device vendors face big development expenses if they hope to get this right, he notes.

Will the wireless medical device become a standard part of hospital gear? I’d say it’s only a matter of time. But this year, progress is likely to be slow.