First and foremost: this is a fantastic initiative! The potential value of mHealth to patients and physicians is tremendous yet remains largely untapped, and one of the main challenges is that many of us rush to market with boutique, stand alone, non-interoperable solutions (more than 13,000 health related Apps in the App Store, a recent count shows). Initiatives like Open mHealth will provide a tremendous step change in our ability to actually capture the value / health benefits of these technologies.
Having said that, I’ve also spent 15+ years in the IT industry where I have grown cautious of (and have been guilty party to!) approaches of the kind “there are too many incompatible standards / silos, lets build a bigger standard / silo”. So I am trying to understand how the various emerging standards relate and differ.
More concretely, if I’d want to start building mHealth apps for patients and physicians today, in which I’d want to heavily build upon, and contribute to, open standards (for all the right reasons that you mention!) can you help me understand how Open mHealth differs, e.g. from http://www.smartplatforms.org/ ? I realize these are relatively newly emerging standards, which may take convergent or divergent courses over time, yet if you were looking to build mHealth solutions, and would want to optimally deploy open source, would you adopt either emerging standard, both? And for what reason / purpose?
Many thanks for your kind insights. And again, I commend you for this great initiative, which will ultimately contribute to improving health outcomes for the many patients we all serve!
Joris,
Thank you for your enthusiastic comments. You touch on a very important question about the role of standards in Open mHealth. Our approach, broadly speaking, is to promote easy lightweight ways for people to use existing semantic standards of their choosing if and when they need them, and to allow community usage to reveal which terminologies/ontologies are most useful for which types of tasks and needs. Depending on the data element, the use case, the context (etc), different standards may be more ideal, so we cannot presume to know or prespecify only one standard. For example, we would allow a range of semantic standardization for collecting and exchanging a blood glucose value. One developer may be content with a very ad hoc string identifier (which would of course limit meaningful exchange with other systems), while another developer may annotate that data value with controlled terms from one or more standard terminologies (e.g., LOINC, SNOMED), in the form of BioPortal URIs.
Exchange standards at the level of information models are trickier. For interoperating with medical records, we plan on using the SMART approach. We will also be defining and publishing APIs for modular functions that are particular important or useful in mHealth, which will allow interoperation among Open mHealth-compliant components for those functions. The components themselves may be open source or proprietary — so long as their APIs are Open mHealth compliant, they can participate in the Open mHealth ecosystem. These APIs should then become increasingly robust over time with reuse and testing by the Open mHealth community.
We have to get past the debates about either defining new standards or wholesale adoption of any one existing standard, and innovate instead on finding flexible, layered approaches that allow de facto standards to emerge from meeting real-life patient- and clinician-centered use cases (rather than administrative use cases, for example). Our Open mHealth philosophy is to ground all our work in projects addressing real-life problems, which currently include projects on post-traumatic stress disorder, diabetes management, and chronic pain management. We will post developments on our website as they occur, and we are also working on ways for the developer community to get involved with this work so please stay tuned!
First and foremost: this is a fantastic initiative! The potential value of mHealth to patients and physicians is tremendous yet remains largely untapped, and one of the main challenges is that many of us rush to market with boutique, stand alone, non-interoperable solutions (more than 13,000 health related Apps in the App Store, a recent count shows). Initiatives like Open mHealth will provide a tremendous step change in our ability to actually capture the value / health benefits of these technologies.
Having said that, I’ve also spent 15+ years in the IT industry where I have grown cautious of (and have been guilty party to!) approaches of the kind “there are too many incompatible standards / silos, lets build a bigger standard / silo”. So I am trying to understand how the various emerging standards relate and differ.
More concretely, if I’d want to start building mHealth apps for patients and physicians today, in which I’d want to heavily build upon, and contribute to, open standards (for all the right reasons that you mention!) can you help me understand how Open mHealth differs, e.g. from http://www.smartplatforms.org/ ? I realize these are relatively newly emerging standards, which may take convergent or divergent courses over time, yet if you were looking to build mHealth solutions, and would want to optimally deploy open source, would you adopt either emerging standard, both? And for what reason / purpose?
Many thanks for your kind insights. And again, I commend you for this great initiative, which will ultimately contribute to improving health outcomes for the many patients we all serve!
Joris,
Thank you for your enthusiastic comments. You touch on a very important question about the role of standards in Open mHealth. Our approach, broadly speaking, is to promote easy lightweight ways for people to use existing semantic standards of their choosing if and when they need them, and to allow community usage to reveal which terminologies/ontologies are most useful for which types of tasks and needs. Depending on the data element, the use case, the context (etc), different standards may be more ideal, so we cannot presume to know or prespecify only one standard. For example, we would allow a range of semantic standardization for collecting and exchanging a blood glucose value. One developer may be content with a very ad hoc string identifier (which would of course limit meaningful exchange with other systems), while another developer may annotate that data value with controlled terms from one or more standard terminologies (e.g., LOINC, SNOMED), in the form of BioPortal URIs.
Exchange standards at the level of information models are trickier. For interoperating with medical records, we plan on using the SMART approach. We will also be defining and publishing APIs for modular functions that are particular important or useful in mHealth, which will allow interoperation among Open mHealth-compliant components for those functions. The components themselves may be open source or proprietary — so long as their APIs are Open mHealth compliant, they can participate in the Open mHealth ecosystem. These APIs should then become increasingly robust over time with reuse and testing by the Open mHealth community.
We have to get past the debates about either defining new standards or wholesale adoption of any one existing standard, and innovate instead on finding flexible, layered approaches that allow de facto standards to emerge from meeting real-life patient- and clinician-centered use cases (rather than administrative use cases, for example). Our Open mHealth philosophy is to ground all our work in projects addressing real-life problems, which currently include projects on post-traumatic stress disorder, diabetes management, and chronic pain management. We will post developments on our website as they occur, and we are also working on ways for the developer community to get involved with this work so please stay tuned!
Ida