How can clinically validated data schemas help doctors and patients provide better healthcare outcomes? What are some steps we can take at Open mHealth to get more data scientists and developers more involved in creating these schemas? These were just a few of the questions I asked myself prior to our first ever Summit, held in San Francisco on June 17th.
For those unfamiliar, schemas are a common language that specify the format and content of data, such as blood glucose readings, which affects how software programs process that data.
These schemas are important in that a majority of individual device makers that gather data define this data on their own, making it difficult for different devices to communicate the same measure.
By having a common data language, multiple devices can be aggregated together to reduce ambiguity of the data, which helps to improve the clinical context for doctors. With great clinical validity, these measures can aid in the management of patient care, reducing unnecessary testing and other problems that continue to plague healthcare systems around this country.
I won’t go into the specifics for designing schemas, as you can read about them in the documentation section of our website, but know that we’ve taken a lot of time to weigh open source interoperability with objectivity that doctors require when making diagnoses. If any measures are of particular interest to you, our schema library will be able to provide more examples of this process.
What I did want to talk about was the latter question: how can we leverage the digital healthcare community around us in the creation of these schemas?
And I wanted to extend this discussion to a more philosophical question: how does this kind of deep community engagement contribute to the principles of open source interoperability that guide Open mHealth?
The Nitty Gritty: Our Breakout Session Design
The breakout session at the Summit was one of our biggest successes, with over 35 people from across disciplines participating.
Where did we come up with the idea and why was it successful?
One of our guiding philosophies is that in healthcare, we need to work across disciplines and organizations in order to make any sort of noticeable impact. That was the motivation for facilitating an interactive session where people could work in small groups to generate new ideas and collaborations because we all benefit from coming together and sharing our ideas, challenges, and experiences.
In preparing for this session, we iteratively developed questions with the goal of creating prompts that would generate meaningful dialogue among community members. We listed out 8 – 10 different prompts for each of the main topics we wanted to cover and then talked through what would be most effective, because we knew that the phrasing of the questions would inherently affect the responses we would get. We had to get the wording right.
These were the 3 main questions we decided on:
- Identify schemas: What health and wellness domains would benefit from open, community-developed schemas?
- Drive adoption: What would help you to adopt OmH schemas in your work?
- Community collaboration: What are some specific strategies to help you / the community participate in developing new schemas?
We also wanted the session to feel action-oriented and valuable for the participants, not just us.
So we generated a series of “expected outcomes” for participants and kept them at the forefront of our planning. We also asked people to reflect on how they could envision themselves contributing in the schema development process, recognizing that people have very different skills and levels of time to contribute. This allowed participants to find multiple ways of being involved, even they weren’t working as a data scientist or clinical expert.
We used dot voting method to ensure this process of engagement was kept as open as possible. Dot voting was selected because it gives participants the greatest power to move freely around the space, thus allowing them to vote for ideas that resonated with them in an organic way after the small groups had brainstormed various answers to each question. This was a process where they were in full control rather than having our long-term thoughts about Open mHealth looming over the discussion.
Here’s one example of what a completed dot voting sheet looks like:
What the Community Wants for Schemas
In our reflections the week after the summit, we realized just how successful things were. The ideas presented were varied, deeply realized, and provocative when considering how we value collaborative open source projects. Major takeaways:
For identifying schemas, an overwhelming number of participants wanted to focus on capturing self-reported, patient-centered measures. Though there is a desire for patients to be more involved in the healthcare process, these self-reported measures must also occur with certain clinically objective standards, which is where a schema comes into play. Symptom and problem reporting is one of the areas where the tension between objective and subjective measures was highlighted.
Other measures in this category focused on specifically capturing mental health and wellbeing (i.e. the question: how can we be happy?). Eating habits were another area of focus that received a number of votes, with a specific desire to track the types of foods people were eating vs. what they actually should be eating. Finally, the “aggregation and integration of heterogenous data” was another interest, meaning that different schemas could be applied together to yield a greater picture of individual, or even community, health.
For driving adoption of Open mHealth schemas, numerous high level ideas were discussed, including organizational visibility, discoverability, and integrating with other standards and data sources. Partnerships with larger scale stakeholders (i.e. hospital systems, insurance companies or policy organizations) were seen as particularly important in expanding visibility and integrating with other standards. Furthermore, emphasizing the financial benefits of an Open mHealth collaboration could incentivize these large scale stakeholders to invest financially in schemas.
source: Flickr
With the growing use of Electronic Health Record (EHR) systems, the breakout session also emphasized the need for schemas to be compatible with existing systems, including Epic, one of the largest players in this space. Specifically, there was a desire to know if EHR fields could use the OmH schema language. Integration to HealthKit was seen as another valuable avenue to expand the reach of Open mHealth schemas.
For community engagement around the schemas, smaller, less intensive ways to begin engagement with schemas was a high priority. For instance, the idea of “rate my schema” received a lot of votes, where people could easily rate and assess a schema’s merits without directly participating our clinical measure working group (CLIME) process. There were also suggestions to create a platform for proposing and voting on new schemas. However, in the absence of any formal tools, it might be wise to set up less formal and more immediate ways that people can contribute right now.
A number of other community engagement practices also overlapped with the driving adoption section. This is to say: how can we engage a community without them knowing that specific schemas exist? This is where the role and development of schemas becomes increasingly complex.
Putting Votes Into Action
There are no easy solutions for many of the issues and measures that the participants in the breakout session wanted. However, that isn’t stopping us from developing a number of strategies for moving forward to expand our schema library and our community-driven efforts.
Over the next few weeks, we’re going to start making changes in the way the community can access schema information on the website. This will make that information even easier to access, and will help us reach a wider audience, many of whom aren’t involved in our CLIME process. We are also looking at the best ways to implement some of the platforms that people suggested, though implementation of a dedicated platform could take months to develop.
We don’t currently have another CLIME group scheduled, but we heard you loud and clear when you wanted to focus more on self-reported measures. For much of 2015, we’ve been interested in these measures, but have struggled to balance the need for clinical objectivity with the unpredictability of self-reported data. After we completed a CLIME group on medication adherence, we’re ready to tackle other complex measures with greater insight and clarity. Stay tuned another blog post on this topic!
The biggest takeaway from all of this, beyond specific action items, is that the summit was not about us, Open mHealth as an organization, but about the communities we work with to harness the power of open source software. Using an interactive, participant-driven activity was one way that we wanted to put the community at the center of action and ensure that everyone had a voice in the future of digital health data.
What are some other strategies you’d suggest to drive community involvement in schemas? What are some schema ideas you think are important? Feel free to answer this in the comments section below or mention us on Twitter @openmhealth.
==
This is the first post is a series dedicated to the Open mHealth Summit held on June 17th. We will be posting in the upcoming weeks about our CLIME groups, our data visualization process, shims, and many other open source technologies we’re interested in at Open mHealth.