The OpenMRS community held a massive (100+ person) brainstorming session during the annual global conference in Nairobi December 2018.

This post summarizes the results from 1551 ideas that were generated. Part 1 is a broad summary of the entire session. Part 2 goes through a summary of each of the six prompts that were used.

‍

Part 1: Major themes from the OpenMRS18 Conference brainstorm

1. Deliberately grow and strengthen the OpenMRS community

1a. Better explain what OpenMRS is and the positive impact electronic health records have on healthcare systems

1b. Provide tools that make the decision to implement OpenMRS in your facility easy

1c. Improve documentation, training, and implementer support

1d. Involve stakeholders, patients, and non-developers into the OpenMRS

1e. Build a common vision together

2. Built a strong electronic medical record tool that

2a. Is fast to implement

2b. Has a really intuitive user interface

2c. Works on mobile and at scale

2d. Functions online, offline, and at the point of care

2e. Has libraries of shareable concept dictionaries, indicators, workflows, forms, clinical decision support tools, and reports

2f. Has a straightforward data pipeline from data acquisition to report sharing

2g. Is interoperable with other systems

2h. Easy to customize and configure without programing knowledge

2i. Is modular in its development to encourage multiple developer communities

This conversation will continue on the OpenMRS Talk posts [link to appear here]

Part 2: Detailed summary of each question

The Process

Six How Might We questions were developed. The wording of the questions was tested against a small test group of 6 participants before the sessions. A prompt was projected at the front of the room, and groups of 4-6 members brainstormed together for 6-7 minutes. As someone had an idea, they wrote it down on a small sheet of paper and announced what it said as they placed it on the table in front of their group. Team members build on each other’s responses until the time is up. After each round, the responses were collected. The next prompt was then introduced.

The original responses from each round were then typed word-for-word into a Google Sheet document. A link to this is included after each prompt summary.

The prompts

Q1. How might we make reporting less of a headache?

Q2. How might we attract & engage (new and existing) people to the OpenMRS community?

Q3. How might we make implementing OpenMRS easier?

Q4. How might we make scaling up OpenMRS easier for you & your users?

Q5. How might we make OpenMRS the world’s best  electronic health record by 2030?

Q6. How might we build & sustain the OpenMRS community - dedicated to - tangibly improving world health?

examples of prompt responses:

Q1. REPORTING
How might we make reporting less of a headache?

Summary: Reporting can be improved by streamlining report data pipelines within OpenMRS to enable end-users to analyze the data themselves without the need to have developers generate the reports; and encourage funders, governments, and evaluative organizations to coordinate the creation of common indicators definitions and shared report specifications in order to reduce the burden upon implementers in producing unique data reports ad hoc for multiple groups.

Original copy of this table at:
https://docs.google.com/spreadsheets/d/1lIaw7kpDHdfWx9FynSvtfY_P137sRmOSIEHx1JEel6k/edit#gid=1656539639

Support a reporting community

• Bring together those who are working on reporting problems
• Create documentation around reporting & train more users in this field
• Understand user reporting needs better
• Overall, reduce time and administrative burden required for reporting

Standardize reporting

• Among donors, governments, and reporting bodies: create shared reporting frameworks, shared indicator definitions, and common practices to standardize reporting requirements
• Create standardized reports that can be imported easily into the EHR

Easy to use reporting module

• Create an easy to use reporting module with simple configuration, that updates itself
• Provide multilingual support
• Create a tool that anyone can use to generate the reports required
• Encourage more users to use the data, and use it in novel ways

Analytics tools

• Dashboard capability, with visual presentation such as graphs, maps, charts, etc
• More analytics tools for healthcare metrics
• Ability to quickly and easily generate ad hoc reports and custom queries
• Auto-reporting, report scheduling, and real-time reporting

Flexible database structure

• Standardize data and use FHIR database structure
• Encourage high quality cleaner data collected at point of care
• Tools to validate data quality

Intuitive data pipeline

• Make it easy to see the data transformations from database to aggregate report
• Make it easy to merge and join data sets
• Data warehouse, health information exchange, and aggregate reporting capabilities

Export data to other applications

• Easily export data to many formats and third party tools
• Create a reporting API
• Tools to share reports

Q2. DIVERSITY & INCLUSION
How might we attract & engage (new and existing) people to the OpenMRS community?

Summary: OpenMRS needs to explain more clearly through multiple mediums its story, its technology, and how new members can join the community and help improve global health. We need more members with diverse skillsets and backgrounds. Once new members join, they require a streamlined onboarding process, mentorship, and recognition for their contributions to the community.

Original copy of this table at: https://docs.google.com/spreadsheets/d/1lIaw7kpDHdfWx9FynSvtfY_P137sRmOSIEHx1JEel6k/edit#gid=330579085

Explain, demonstrate, and promote OpenMRS

• Explain what OpenMRS is better the the public community
• Online demos of the software and sandbox versions
• More explicit publicity campaign to share stories of OpenMRS using all social media avenues (website, YouTube, podcast, etc)

Recognize our community

• Share success stories and explain the benefits of using OpenMRS
• Provide formal mentorship and implementer pairing to develop the community
• Promote community champions, country ambassadors, scholarships, and fellowships
• Find endorsements from external groups and individuals in support of OpenMRS

Invite new users

• Directly invite more users, in particular youth, women, those in new geographic regions, those with new skills and expertise, stakeholders, industry, friends from Google Summer of Code, and other open-source and tech communities
• Engage universities and their studies with OpenMRS, and encourage discussion of the platform in their curriculum
• Participate in other informatics and EHR workshops as means to advocate OpenMRS

Make it easier to be a new OpenMRS member

• Explain more clearly why people should join OpenMRS, and make it straightforward to join, understand how one can contribute, and have a smooth process to introduce to the community
• Provide boot camps, user trainings, and webinars, for more advanced training
• Create an OpenMRS University where people can develop the skills to implement the software and help contribute to it
• Recognize experts and competency with OpenMRS certification
• Have well written documentation on OpenMRS in multiple languages

Provide ongoing support

• Curate the OpenMRS forum (‘Talk website’) to sub interests, and develop communities of support around these
• Create more opportunities for non-developers to contribute
• Promote interoperability between implementations and regional support
• A formal help desk

Build a better product

• Have a public issues and ideas list that people know how to contribute to, and recognize and encourage submissions via competitions and hackathons
• Make it easy install, and web based
• Incorporate new technologies, and make interoperability easier

Q3. IMPLEMENTATION

How might we make implementing OpenMRS easier?

Summary: OpenMRS implementers require straightforward documentation on how to get it up and running and access to support during the set=up process. The product installation needs to be easy, fast, and require minimal configuration - ideally no technical developers required. Users would like an out-of-the-box product that just works (as opposed to assembling the pieces they need for this themselves).

Original copy of this table at: https://docs.google.com/spreadsheets/d/1lIaw7kpDHdfWx9FynSvtfY_P137sRmOSIEHx1JEel6k/edit#gid=1045597154

Implementation resources

• Tools for prospective users to estimate the costs and resources required to implement OpenMRS as their EHR
• Online demos and virtual sandbox so that new users know how OpenMRS works
• Implementor stories and best practice guidelines that help educate prospective implementers, combined with solid documentation.

Implementation training

• A solid multi-lingual implementation manual and training for new implementers with courses and certification.
• Implementation tools that help track the process of implementation and monitor the system performance
• Training tools for new users of the medical record to make it easy for them to start using it

Ongoing implementation support

• Mentorship, partnerships, and exchange programs to help new implementers
• A formal Helpdesk to contact for support, with additional Q&A hours
• A ‘Launch Team’ that can assist in new installations
• Further government support and collaboration during implementation

Fast installation

• One click easy installation that can be accomplished without requiring technical knowledge
• Straightforward configuration tools to get new implementers up and running quickly
• Shared libraries of forms, configuration settings, and workflows that can easily be imported into new installations
• Data migration tools to bring data from other sources in
• Auto-update with full backwards capability so users are all on the same version

Strong common application

• Focus on build a strong common core of tools that achieve 80% of required use cases out of the box, with easy customization of the other 20% as required
• Create a friendly user interface that is intuitive for clinicians and runs on both desktop and mobile
• Design the system with high modularity so that features can easily be added and removed

New features

• Deploy the system in the cloud
• Make it easy to run multiple installations and national or regional distributions
• Design a lightweight version that uses low resources, works offline, and can share data in a peer to peer network
• Focus on improving quality control, error logs, and system security

Q4. PAIN POINTS
How might we make scaling up OpenMRS easier for you & your users?

Summary: To scale OpenMRS, implementers needs tools to calculate the costs of implementation and ongoing operations. Comprehensive user training tools are required. The system must be easy to use, operate at scalable and offline. Software updates must be seamless, and data must easily flow into reporting frameworks.

Original copy of this table at: https://docs.google.com/spreadsheets/d/1lIaw7kpDHdfWx9FynSvtfY_P137sRmOSIEHx1JEel6k/edit#gid=875993527

Demonstrate value of OpenMRS

• Demonstrate to prospective implementers the value of OpenMRS both financially and in patient safety and improved health system performance
• Make it easy for prospective user to calculate the costs and resources required to install and provide ongoing operation of an OpenMRS system
• Publish electronic medical record best practices
• Grow the system with new users, new funding streams, and with involvement of patients

Documentation & training

• Clear documentation and ample training for the implementing team as well as real-time training for those users and clinicians starting up the system
• Helpdesk support

Easy implementation and customization

• Simple installation of OpenMRS and auto-updates with frequent releases
• Modular system design and app store

Globally interoperable

• Full interoperability of systems
• Tools to measure the OpenMRS system performance
• Common reporting tools and data pipelines into national aggregate reporting tools and disease surveillance tools

Lightweight and offline

• Make OpenMRS work offline with more advanced data synchronization and peer to peer connectivity
• Mobile friendly version that uses low power and inexpensive hardware that is reliable and fast

New technologies

• Cloud deployment of OpenMRS
• Redesign of database model
• Improved security, database replication, patient identification, and other features

Q5.  THE FUTURE
How might we make OpenMRS the world's best EHR by 2030?

Summary: To develop the world’s best electronic health record by 2030 a strong active community of implementers and developers needs to work together on building an amazing product that works for patients, clinicians, governments, researchers, and all those involved in healthcare.

Original copy of this table at: https://docs.google.com/spreadsheets/d/1lIaw7kpDHdfWx9FynSvtfY_P137sRmOSIEHx1JEel6k/edit#gid=1787743727

Strengthen community

• OpenMRS must recognize the contributions of their community and highlight publicly the good work being done
• New implementations and more users on the platform

Build it

• A clear shared vision of the future is needed
• The community will move ånd work together to make it happen
• Attract more developers and additional expertise not currently in the community
• A core development team would be helpful
• Additional funding and new business models to help make this happen

Easy start as a new user

• The cost to implement and maintain and OpenMRS installation must be reduced
• OpenMRS has to be easy to install, easy to upgrade, and easy to use by clinicians
• Training, documentation, support, and helpdesk available

Strong foundational product

• The product’s common core functionality must be valuable out-of-the-box with minimal customization and function at point of care
• A modular design to enable improvements to the platform
• Shared resources, concept libraries, workflows, and data interoperability

Built for scale

• OpenMRS must help lead the global community in creation of electronic health record standards, and health data reporting standards
• Built firmly on existing standards, such as FHIR
• Cloud deployment, mobile functionality, seamless sync, peer-to-peer sync, and offline functionality
• A scalable system architecture

Broadened functionality

• Design the system to be patient centered, making it easy for patients to enter data, sign into clinic, and access information via a portal
• Provide ability for health system and population health analytics and disease surveillance
• Tools for researchers to be able to coordinate and generate research (and FDA level) data
• Connect the system more closely into the delivery of healthcare services
• A full featured EHR system

New technologies

• Advanced clinical decision support
• Voice interface and natural language processing
• Machine learning and artificial intelligence to help deploy care
• Better patient identification tools

Q6.  COMING TOGETHER, COMMUNITY
How might we build & sustain the OpenMRS community - dedicated to tangibly improving world health?

Summary: To help improve global health, OpenMRS must (a) better articulate its mission, (b) grow its community, (c) tackle new health challenges, and (d) develop the necessary technologies for success.

Original copy of this table at:
https://docs.google.com/spreadsheets/d/1lIaw7kpDHdfWx9FynSvtfY_P137sRmOSIEHx1JEel6k/edit#gid=1811056488

Promote benefits of OpenMRS

• Conduct and publish research that shows the impact and benefits of OpenMRS
• Collect and share stores of implementations and uses of OpenMRS
• Promote best practices for electronic health records

Grow community connections

• Build partnerships with new organizations, stakeholders, and local representatives
• Expand the community by establishing local or regional communities
• Raise awareness among public health professionals and government leaders about OpenMRS and how they can contribute to the community
• Make it easy for OpenMRS members to communicate and meet with each other
• Reward top OpenMRS contributors

Create a diverse and capable community

• Establish a pipeline of core developers
• Expand OpenMRS University to include UI designers, developers, implementers
• Provide excellent user training
• Provide multilingual documentation

Build a powerful EHR

• Focus on building a strong core product that works with minimum configuration
• Have a core development team and make it easy for the community to contribute to development
• Fundraise and create novel ways to involve new creators

Expand the product

• Expand to provide care for multiple different diseases
• Provide advanced real time data aggregation pipelines for disease surveillance
• Enhanced reporting and evaluation tools to measure the success of care delivered
• New functions, features, and easier user interface

Join the discussion: and contribute in the OpenMRS Talk post [link pending].

Thanks you to Jennifer Antilla the new OpenMRS Community Manager for help with this session and blogpost.