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.
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.