I’m often asked about what Open mHealth does.
While we do offer tools to help you use patient-generated health data (like OMH-to-FHIR and Shimmer), the essence of Open mHealth is and always will be an open data standard.
It’s been our remit since day one.
In this post I’m going to break down what an Open mHealth data standard is through an mHealth schema and why need this to drive greater health data interoperability.
I’ll also show you can use the Open mHealth data schemas today to help you make your patient-generated data cleaner and simpler to use.
But before we do, let’s talk about philosophy.
Enter Ludwig Wittgenstein
Wittgenstein was a mathematical philosopher whose brand of philosophy centered on language. He believed that it’s “best to say nothing except what can be said”. And he used logic and symbolism to explain thoughts.
He makes the distinction between propositions (the meaning to which we think something is true) and sentences which are comprised of grammar spoken or written in a given language by someone at a given time and place.
Sometimes you can propose the same thing and have a different sentence/structure.
You can also have the same sentence but have very different meanings.
I know it’s a bit heady, but understanding this helps to explain Open mHealth, I promise.
Rain, rain go away
Imagine the scene: Three friends are about to run to their cars from the store, it’s January and water is falling from the sky.
One friend speaks Swahili, one speaks German, and one speaks Spanish.
The Swahili friend says, “kunanyesha”.
The German speaker says, “es regnet”.
The Spanish speaker says, “está lloviendo”.
To Wittgenstein’s point, each of the languages have different sentence structures with their own unique grammars, but they propose the same meaning.
Which is when water falls down from the sky that we agree that “it is raining”.
Open mHealth is like our language example.
Patient-generated health data is not created equal
Each app, device, platform that a patient uses emits data in a different way.
Think Fitbit, Apple’s HealthKit or Omron.
Each and every one of their APIs represents time, weight, blood pressure, blood glucose (and the list goes on) differently. Their grammars are different.
And in order for that data to make sense to the clinical and research worlds, there needs to be a way to represent this information so that despite their difference in “grammar” the meaning will always be the same (i.e. “it is raining”).
If you’ve gotten this far, you’re doing well. The Open mHealth interoperability standard is based on a common data schema that is used to make sense of disparate patient-generated health data for the clinical world. We are helping give one clinical meaning to disparate data sources.
What are data schemas?
Data schemas specify the format and content of data, such as blood glucose readings, which affects how software programs process that data. A common schema serves as a single source of documentation that can be referenced whenever and wherever the data points are used.
Why are data schemas important?
In healthcare, data schemas are particularly important because of the semantic importance and complexity of health data.
For example, the distinction between fasting and non-fasting blood glucose is critical to its clinical meaning.
Whether a heart rate is at rest or during exercise, or whether a weight is self-reported or sensed, are critical distinctions when making sense of data and taking clinical action using that data.
Our common schemas define the meaningful distinctions for each clinical measure, increasing the overall clinical utility of patient-generated health data and improving the ability of developers to build clinically usable products.
(If you haven’t already, you should check out the IEEE P1752 Working Group where we’re collaborating with industry and developer to make these schemas an international standard).
How can you use mHealth schemas today?
Step 1: Go to the Open mHealth schema library
Step 2: Search for a measure you want to represent
Step 3a: Learn the JSON schema specification
Each schemas provides a specification on how to model your data measurement of interest.
Step 3b: Learn to model data
Each measurement also has sample data associated with it to demonstrate how data should be produced.
People may tend to start with this step and then Step 3a to work backwards towards understanding how data should be structured.
Step 4: Validate
If your API is sharing data in Open mHealth you may want to validate to make sure, before making a new release, that the data still adheres to the schema.
You can use the test data validator to make sure it conforms to the Open mHealth schema (note that your individual code stack will differ from what is being presented in Github so you may need to find a validator that fits your unique platform).
Conclusion
mHealth data schemas are critical to not only make sure that everyone who’s producing data conforms to a standard but that the data produced is alos clean and simple to make sense.
While many apps, devices and wearables speak different “languages”, we will get to a standardized way of representing patient-generated health data so it can be useful to improving health.
Are you using Open mHealth to share or consume data? We’d love to hear about your use case. Or just leave a comment below.