A few weeks ago, we talked about one of the most energizing sessions at OMRS18: a massive brainstorming activity focused around six “How might we…?” questions that helped us consider some of our current challenges and dream of what the future could hold for OpenMRS.
As we said in that original post, we ended up with more than 1,550 ideas! This averages out to roughly 260 ideas per question, and if you haven’t already come across it, you can go to Greg Schmidt’s blog and read the summaries for each of the six questions.
We also thought we’d look at your ideas and see what emerged if we looked at them from three different lenses: community, technology, and organization. Here is what came out:
Community
Improve marketing and messaging. A large number of you called for improved publicity and marketing to create greater awareness of OpenMRS. Specific suggestions included: have a better website, have volunteer photojournalists who can visit sites, publish videos on YouTube, create a podcast serial about OpenMRS, publish a newsletter, have a social media campaign, and advertise our products to different audiences. Several suggestions focused on promoting OpenMRS by explaining who and what OpenMRS is (origin, strategy, roles and responsibilities, individual profiles, etc) as well as telling our story by sharing solutions and implementation stories, launching a campaign around the importance of OpenMRS, and showcase the impact of OpenMRS on patients.
Expand the community by reaching out and engaging potential members. This could be via an “open source road show,” on campus recruitment and reaching out to clinics. Once identified, creating an easier pathway to contribute, using alternatives to Talk, create simple tasks for new members to do, and frequently following up with those that introduce themselves.
Engage the community by reaching out to current members, involving more stakeholders, and organizing a variety of meetings. Many of you told us about the importance of engaging new and existing members who are non-developers by expanding the development tracks that supports contributions in design, dev, and documentation. Many advocated for greater recognition of volunteer contributions.
Strengthen community through capacity building. Your suggested approaches include on-the-job training/mentorship/paired programming by core developers, strengthening OpenMRS University, developing certification standards and a certification program for implementers and developers, offering more scholarships and fellowships, and hackathons/bootcamps. You also cited several target audiences for capacity building, including clinicians, core users, implementers, developers, and UI designers. Many of you also suggested working with universities on a range of activities, including presenting OpenMRS to universities to get more people on board, holding the conference at a university, and integrating OpenMRS into university curricula.
Technology
Update and improve documentation. A large number of you called for updating technical documentation (SOPs, user manuals), documentation on the data model, for each module, for each version, for implementations, and for onboarding. Some thought the structure of the documentation could be more user friendly and effective. Others thought the Wiki should have more comprehensive implementation documentation, publish a standard guide, align SOPs with clinical or technical guidelines, and use more videos or tutorials.
Greater support for implementation. In addition to better implementation documentation and training for both implementers and users, you asked for tools for prospective users that will help estimate the costs and resources required to implement OpenMRS, track the process of implementation, and monitor the system performance. Others suggested having a ‘Launch Team’ that can assist in new installations as well as a formal Helpdesk to contact for support, with additional Q&A hours.
Easier installation and updates. Many advocated for simplifying OpenMRS installation and providing frequent, auto-updates with full backwards capability – all of which can be accomplished without requiring technical knowledge. You also suggested having configuration settings and workflows that can easily be imported into new installations as well as data migration tools to bring data from other sources in. Some wanted to be able to deploy a cloud version of OpenMRS. Others are interested in designing a lightweight version that uses low resources, works offline, and can share data in a peer to peer network.
Common application that is built for scale. Most of you support building a strong core product that achieve 80% of required use cases out of the box, with easy customization of the other 20% as required. The product’s common core functionality must be valuable out-of-the-box with minimal customization and function at point of care. As a part of this common application, community members seek shared resources, concept libraries, workflows, and full interoperability of systems. You also encourage designing the system with high modularity so that features can easily be added and removed. There is strong support for creating a friendly user interface that is intuitive for clinicians and runs on both desktop and mobile devices. Additional suggestions included an increased focus on improving quality control, error logs, and system security.
Some suggestions to achieve this include: a) combine features from current distributions into a core distribution, b) reduce the number of and standardize current distributions to alleviate confusion, c) enable cross distribution module design and development for reusability, d) build common, reusable UI components, and e) scalable system architecture. The common application should be built firmly on existing standards, such as FHIR. Many encouraged the application of machine learning and artificial intelligence to help deploy care.
Broadened functionality and new technologies. Many expressed an interest in expanded functionality that will connect the system more closely with the delivery of healthcare services for multiple diseases, allow advanced real time data aggregation pipelines for disease surveillance, and support enhanced reporting and evaluation tools to measure the success of care delivered. To facilitate reporting, there is interest in an easy to use reporting module with simple configuration and flexible database structure. To encourage more users to use data, this could include a broader range of analytics tools, such as flexible dashboards with visual presentations, the ability to generate both ad hoc, custom queries while allowing auto-reporting, report scheduling, and real-time reporting. Many also want a system with an easier user interface that supports advanced clinical decision support, patient identification, and is designed to be both clinician facing and patient centered.
Organization
Establish regional or local communities. There were multiple calls for strengthening connections with OpenMRS countries through the introduction of OpenMRS country ambassadors/representatives and the formation of OpenMRS regional or national communities.
Encourage government engagement and other partnerships. A number of you suggested engaging or partnering with ministries of health in order to support local ownership and advocate for policies that support OpenMRS investment and adoption. You would like to see a community that is linked with other communities and potential partners within the global health community. Some of you encouraged clearly defined certification programs for service providers.
Increase diversity in multiple areas. You want greater diversity within OpenMRS leadership and the community by making meaningful commitments and actions. Suggestions included engaging women and youth as well as inviting contributions by non-programmers.
Increase contributions to the community. There were a number of calls to hire a sizable team of core developers as well as increase the number of core volunteer community developers. Several suggested having a “developer pipeline,” a concept that could be applied to those contributing to the community in other ways as well. You also suggested a variety of ways to encourage contributions back to the community, including setting aside a standard amount of time (i.e. 2.5%) to contribute to the community, launching campaigns to encourage giving back to the community, and proactively offering financial or in-kind support to implementing partners to build features in a shareable way.
Increase sustainable funding. Many simply suggested increased funding and applying better, sustainable business models – with few suggestions as to how to raise and use funding or what kind of business model to employ. A few of you identified the need for smarter funding, convincing countries and funders of the importance of funding infrastructure and the commons, and engaging more donors or encouraging donors to open their coffers. In addition to suggestions to improve the business model, a couple of you suggested selling packaged OpenMRS solutions and encouraging private sector use of OpenMRS.
If you any of this sparks new ideas that you want to share or if you want to explore how we can make (at least some of) these happen as a community, join us on Talk!