OpenMRS 2018 Conference Brainstorm Session
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.
If you want to listen/watch this - video is below. Also available on podcast app under: Gregory Schmidt
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.
