Help us brainstorm OpenMRS project ideas

Community
1

As you may know, the OpenMRS Community has recently been the recipient of a gracious donation of resources. To maximize the benefit of the donation to the community, we would like your help in identifying high impact and high value projects that could benefit the OpenMRS Community. If you have an idea for a project that you are interested in doing or leading, and that would benefit the OpenMRS Community, please post your project idea here.

We are looking for projects with these attributes:

  • Are high impact / high value for the community (benefit all or most implementations)
  • Maximize use of resources (e.g., incorporate partnerships with organizations willing to help provide resources)
  • Someone actively wants to lead/own the project

In your proposal, please include:

  • Title and description
  • Benefit(s) to the OpenMRS Community
  • Potential risks
  • High level project plan (who would do the work, how long would it take, etc.)
  • Estimated budget
  • Availability of other resources, matching funds

We will follow up with a more formal proposal process in the coming months. If you want to help design this process, then join us on OpenMRS Leadership meetings or on OpenMRS Talk.

See a proposal you like? Click the heart on the post to show your support.

Want to ask questions or discuss a specific proposal? Please use the New Topic feature to take the discussion to a new topic (we would like to keep this topic focused on proposed ideas).

thanks in advance for your thoughts and ideas!

9 Likes
3

Hi @terry,

I am very excited to see some new project ideas inside the OpenMRS.

During my final year research project, I deeply went through the Machine Learning and Data Science techniques and those applications. Since OpenMRS is a wonderful EMR System around the world and I feel, Good to have some advanced AI projects inside the OpenMRS in the future :slight_smile: .

Some of those ideas could be,

  1. Predicting the next visit date based on the diagnosis and patient records.
  2. Predicting the patient diagnosis severity based on the notes and records.
  3. Diseases predictions based on the patient records.
  4. Anomaly detection among the patient information.
  5. Prescription predictions based on the patient diagnosis and diseases.

There are a lot of AI-based ideas for the medical system based on the Machine Learning and Data Science. I will detail describe those in another post.

Here, I would like to know, Are there any possibilities to think about the projects based on these following topics inside the OpenMRS (some of those projects may be research-based)

  • Data Science
  • Machine Learning
  • Deep Learning
  • Neural Networks

Hoping for your reply!

CC : @burke @darius @dkayiwa

Regards,

4 Likes
9
  • Title: Getting ready for the next 10 years (Openmrs 3.x)
  • Project Idea/Benefits to the OpenMRS Community: Openmrs has been around for quite some time and has successfully enabled various groups to build solutions that support healthcare delivery around the world. openmrs-core is the foundation for those efforts, institutions/countries/communities/developers depend on it to build their custom EMR or other solutions. However, not enough time is spent on removing technical debt, upgrading outdated dependencies which not only pose potential security risks but it also leads to slower development and a higher barrier to entry for new members. Developers sometimes need to take care of things new libraries, technologies have already solved (for ex. Spring Data for the data access layer to DBs or other backends). We are currently on Java 8 but Java 10 is already out. Upgrading to Java 9 is not easily possible since outdated dependencies are holding us back. Spring 5.x, Hibernate 5.x are out. We are testing using Junit 4, Junit 5 is already out. Our mocking frameworks are out of date. Our logging library has long seen its end-of-life but its hard to update since its so entangled. Still 40% of our code is not tested. We mostly rely on integration tests which makes our build times rather long. We should adapt our testing strategy and promote more unit tests. The list goes on… Its not a hot topic but it has to be done otherwise the future will not look so bright for openmrs-core and thus for everyone building on top of it. I strongly urge we create a dedicated task force that establishes an actionable plan to tackle those issues. Everyone will benefit.
  • Potential risks: I personally only see risks in ignoring this topic. The longer we wait the harder it will be.
  • High level project plan/Estimated budget: I am happy to work on a more formal project proposal with other interested contributors.

Looking forward to hearing about the next steps needed to create a formal proposal and also to the communities thoughts on this :slight_smile:

10 Likes
10

OpenMRS Metrics

image

Where is most of the OpenMRS-related development activity over the past week? Should we be reaching out to a highly active volunteer who recently went silent? What is our average response time for a pull request on a community priority ticket? Are we improving? Did someone manage to simultaneously resolve the most voted tickets and get the most like posts on Talk last month? How many…

These and many more questions could be answered with existing data if we had the tools to explore them. Tools like GrimoireLab can be used to create a community dashboard through which insights can be gained and better (more informed) decisions can be made. For example, here is dashboard created for OPNFV by Bitergia.

Benefits to the OpenMRS Community

By pulling together activity in GitHub, JIRA, Talk, Wiki, CI, IRC, etc., the OpenMRS community could increase transparency, be better informed about community activities, and do a better job recognizing community contributions.

As a side effect, we could also have realtime stats to drive our website and provide data for annual reports.

Potential risks

The biggest risks would be:

  • The dashboard setup is complicated/fragile (too difficult to maintain/upgrade/modify)
  • We aren’t able to come up with actionable questions to drive metrics
  • Available data don’t provide meaningful/actionable insights

High level project plan

We would hire a group like Bitergia with expertise to do the initial setup and initial iteration. The goal would be to have a community-hosted dashboard that could be sustained and adapted by the community.

  • As a community, decide on our top ten metrics of value [1-2 weeks]
  • Set up a GrimoireLab dashboard to answer those questions [2 months]
  • Review dashboard and decide on key changes & improvements
  • Second iteration [1 month]
  • Document & hand off to infrastructure team and community developers [1 month]

Estimated budget

USD $20-50k, depending on how fancy we get

Availability of other resources / matching funds

As on open source project, we may be able to get a reduced rate.

3 Likes
11

@teleivo Taking a cue to a discussion

Title: OpenMRS the EMR Kernel for Different Applications
Project Idea/Benefits to the OpenMRS community: OpenMRS has evolved as a web based application running on a MySQL database, and with needs from partners to deploy on low cost ARM hardware with a smaller footprint, as well as embed into the bludgeoning services of health data collection, as well as mobile data services support there is need to look into the architecture. This would be a kernel with core services exposed via REST, able to work with multiple RDBS systems, support pluggable authentication and role based access models, multi-location access control, sharing of data with disconnected instances, as well as de-normalizing the data model to simplify reporting

Potential Risks: Too much analysis and not enough value addition

High Level Project Plan/Estimated Budget: US$150,000 (3 dedicated devs for 1 year)

Plan:

Q1 - Extract non-core functions into dedicated core modules (legacy ui experience) while providing necessary foundational upgrades for tooling

Q2 - Refactor core module management functionality by making the core mode module aware and providing mechanisms for modules to advertise their functionality

Q3 - Database agnostic integrations: MariaDB, Postgres, CouchDB with focus on improving reporting mechanisms

Q4 - Distribution specific needs

2 Likes
12

Title: Foundational Disease Support

Project Idea/Benefits to the OpenMRS Community: OpenMRS in developing countries is used to support a number of high profile diseases HIV/AIDS, Tuberculosis, Non-communicable diseases, Ebola, Mother to Child Health - Antenatal, Maternity, Postnatal care for both mother and baby, Immunization and Nutrition for the first 1000 days among others at national level. The data collection tools and needs for these areas are fairly standardized and produced by WHO, UNAIDS, UNICEF which work in these areas. The purpose of this project is to provide modules on top of the OpenMRS Reference application leveraging CIEL dictionary and Open Concept Lab to provide starter modules with data collection, analysis, indicators, integration with DHIS2 and other reporting tools for each of these areas that can be leveraged by implementing partners in these areas to reduce the amount of re-inventing the wheel.

Potential Risks: Lack of usage within the national Health programs

High Level Project Plan/Estimated Budget Needs analysis by diseases area, but the disease specific work can be done in parallel with respective agencies and interested national programs

3 Likes
13

How much is OpenMRS core being informed and enriched by actual work done through the various implementations? Besides the OpenMRS focused dev and resource structure, OpenMRS core should also be actively benefiting from implementation specific dev…but is that clear and happening efficiently?

14

Hi everyone! Thanks for the concepts and comments to date!

Please keep them coming!

We will come back to you soon with a process to prioritize these proposals in the next week or two, so please use the opportunity now to share your ideas!

15

Title: Bahmni EMR / OpenMRS RefApp convergence

Benefits to the OpenMRS community: Development and investment in Bahmni EMR and the RefApp is currently fragmented, and general-purpose improvements are not made available between platforms. Implementations currently need to choose between Bahmni EMR or the OpenMRS reference application, where a preferable solution would be to choose Bahmni EMR and the OpenMRS reference application (and others), based on user requirements, using those apps that make the most sense, and converging on a common back-end of platform, modules, data representation (eg. use of encounter transactions), and REST API. Additionally, features currently only present in these distributions, including configuration (eg. use of bahmni_config) and integrations with other systesm (eg. OpenELIS and Odoo via Atom Feed) would be available more broadly.

Potential Risks: Each distribution team would cede some control over it’s architecture in order to stay compatible with the larger platform.

High Level Project Plan / Estimated Budget: Would need further analysis to determine the plan and budget. First step would be to agree that this is a goal worth pursuing, identify the various independent steps that can be taken toward convergence, and a high-level plan for making iterative progress towards this objective.

4 Likes
16

Title : Modular Frontend Framework

Project Idea/Benefits to the OpenMRS Community: We have over the years successfully shared the server side code across all distributions because of having a platform with a module framework. This has not happened on the frontend, resulting into various distributions whose components cannot be shared in a plugin in fashion with other distributions. This has resulted into duplication of efforts which wastes our already scarce resources. We have had some good discussions on this talk thread. Our community does not seem to have the skills necessary to pull this off, and hence the need to look some where else.

Potential Risks: A framework having a learning curve that discourages developers of various distributions from taking advantage of it.

High Level Project Plan/Estimated Budget: I totally have no idea about this. All i can say is that this is going to be a highly experienced expert in front end development and technologies.

Availability of other resources, matching funds: A very nicely designed architecture with modern technologies will naturally attract volunteers to maintain, extend and build on top of it. In the early years, i volunteered to work on OpenMRS in my spare time for a full five years, because of the attraction to the server side module framework that blew me away with the ability to stretch my capacity to innovate, to the limits.

2 Likes
17

I actually don’t believe we don’t have the expertise to dig into front end development, every thing can be learnt, we got tons of smart people in the community, some of us can get better at it if we can love it more and put in the time, with that said, am not a UI guy because it is very subjective but I can do it. Just my 2 cents.

18

@wyclif what do you think we should do differently, to pull this off? Am asking this because we have been talking for a while, but i have not seen any one step up to address this problem. Could it be that those, who can do it, are busy and hence do not just have the time? Or, are you available to take this on?

1 Like
19

Title: Completion of data collection, cleaning and analysis for randomized controlled trial of the impact of OpenMRS and decision support tools to improve HIV care in Rwanda.

Hamish Fraser (Brown University, RI, USA), Michael Mugisha and Aline Umubeybeye (School of Public Health, Rwanda)

July, 2019

Benefits to OpenMRS community

With the growth of OpenMRS including several large scale rollouts comes a strong need to better understand how it functions in different environments and with different use cases, the user experience of different user classes, and the impact on clinical care. Such evaluation data would help to define the most valuable use cases, what improvements are required for OpenMRS (which can help drive the road map), and strengthen the case for funding OpenMRS development and implementation.

The proposed project is the final stage of a large scale and long term evaluation of the use of OpenMRS to support HIV care in a low income setting – Rwanda. There are several important studies that have looked at the use of OpenMRS for HIV care in 1 – 3 sites such as a randomized controlled study showing a strong impact of alerts and reminders for pediatric HIV care at Moi University in Eldoret[Martin Were Pediatrics 2013]. In addition there is one multi-site study of the impact of alerts and reminders on HIV care in Kenya with a different EHR which showed a significant positive effect on detection and management of treatment failure[Tom Oluoch, Lancet HIV. However there is a lack of comprehensive real world evaluation of OpenMRS in larger projects with many sites.

The Rwanda eHealth Implementation Science project funded by the CDC, has been studying the usability, use, user experience, data quality, and stability of 112 OpenMRS implementations in HIV clinics in Rwanda (the process evaluation). It has also collected data for a costing studyof the development, implementation and use of an improved version of OpenMRS including improved patient summaries and decision support systems.

The third component of the study is a randomized, controlled trial (RCT) of the impact of an enhanced version of OpenMRS implemented in 56 intervention sites. This trial has 4 end points:

    1. The time for a patient who tests HIV positive to start ARV treatment
    1. The percentage of patients that have a viral load result at 8 months after starting treatment (6 months to test + 2 months for result to return and be entered into EHR)
    1. The time for clinicians to respond to treatment failure based on a high viral load result
    1. The percentage of patients with elevated viral load at the end of study

Short description of the project.

The current study status is that the process evaluation and costing study are complete regarding data collection and at the write up stage. The RCT is under way with the enhanced EHR software installed on the OpenMRS servers at the 56 intervention sites in July 2018. The study is due to end in July 2019.

Currently the CDC funds are no longer available for the final data collection process, data cleaning and analysis for the RCT. Many delays have plagued the project and this has ultimately led to final project funds being “timed out”. Requirements to complete the RCT are funds to cover collecting an image of the OpenMRS EHR databases for 112 sites, collecting some additional outcome data and missing data at those sites, analyzing the data, and renewing the Rwanda MOH IRB approval in September 2019.

This project has already yielded extensive data from the process evaluation and costing studies. These studies will provide valuable insights in to the performance, usability, data quality and costs of implementing OpenMRS at Scale. They also provide unique insights into the way a large scale OpenMRS roll out functions 4 years or more after the initial implementation and while managed locally by the MOH and other Rwandan agencies. Six publications are in process from the process evaluation and costing study. Inability to collect the final data from the RCT will result in loss of highly valuable data that could help improve OpenMRS.

High level project plan

  1. Collect database images from OpenMRS servers at all 112 sites. Collect additional data on key variables at the 112 sites. This will involve technical and data management staff visiting each site. Cost will include salaries, transport and local lodging.

  2. Enter data into study database and clean data.

  3. Carry out analysis of the data.

  4. Renew the IRB approval in Rwanda in September 2019

Potential Risks

These are low, the hard work has mostly been done and the critical deliverable is collecting the data for analysis.

Estimated Budget

$35,000 to $50,000. Some flexibility

1 Like
20

Title: IVR for OpenMRS

Interactive Voice Response (IVR) system is designed to automate a wide range of services. It is a sophisticated application of voice processing technology that creates a link between a person and a computer database, using a touch-tone telephone. The system, using pre-recorded voice files, prompts the caller to enter commands by speaking or pressing buttons, so that he or she can ask questions and make requests for information. The system has direct accesses to the “host” computer to retrieve the appropriate information, which can be instantly replied back to caller. The information can also be transmitted through fax, call back, or e-mail.

Topic of IVR and SMS communication was mentioned before in OpenMRS Talk, so there is obviously some interest in this feature:

I would like to hear your opinion about IVR. Do you think this feature would be beneficial for OpenMRS?

Benefit(s) to the OpenMRS Community

Here is a publication about IVR use in healthcare, with sources and references:

https://www.researchgate.net/publication/10930205_IVR_and_administrative_operations_in_healthcare_and_hospitals

And here are the benefits from this article:

  • it contributes to the professional image of the hospital and creates a positive “first impression” for callers.
  • It enables hospitals to offer consistent, 24-hour, high-quality patient service and increase efficiency, productivity, and profitability through automation.
  • It increases patient satisfaction and accessibility, providing accurate and reliable information on a wide variety of topics with easy access to data for analysis with customized, personalized scripts.
  • It relieves the administrative staff as well as physicians of routine customer interactions, such as information requests, as there is no live customer service contact, unless requested
  • it enables hospital staff to concentrate on more pressing administrative matters and to focus on issues that require human involvement and individual attention.
  • increases productivity as it extends hospital business hours around the clock without 24-hour staffing.
  • A speech-enabled interface makes navigation faster and easier and provides convenient caller services
  • It eliminates the risk that patients will experience busy signals or unanswered calls by reducing on-hold lines and the number of abandoned calls.
  • The average duration of the patient calls will fall overtime as they become more skilled in using the system, and this will reduce the telephone service charges.
  • As the usage of the system increases, it will serve more patients with less assistance from the hospital staff
  • IVR solutions reduce the costs associated with patient service and administration
  • An IVR system can communicate directly with a range of host computers and databases to access all the information a patient might need during a self-service transaction
  • In many cases,when needed, it can automatically keep track of the number of calls each sector receives and the total amount of time those calls lasted
  • It also automatically tracks detailed call statistics that enable users to create, save, and print a standard set of reports and provide real-time monitoring and system management.
  • The software also support English,Spanish, French, and other languages simultaneously, without having to hire multiple bilingual staff members in order to offer global call automation applications, as it allows the patient to decide the particular language to be used for transactions.

Here is the report from controlled trials with IVR:

http://webcache.googleusercontent.com/search?q=cache:x47yO7ZfOasJ:www.ihi.org/education/ihiopenschool/resources/Documents/Erich%2520Weiss_IVR.pdf+&cd=1&hl=en&ct=clnk&gl=pl&client=opera

“An opportunity for the use of IVR exists in nearly every healthcare setting. Its use it in acute care where newly discharged patients are enrolled in disease appropriate IVR systems may improve the transition in care from the hospital to the home and lead to reduced readmission rates. The overburdened primary care setting may benefit from reduced staff workloads and enhance patient understanding of their condition and the results of their lifestyle choices. Specialty care may implement an IVR system which monitors patient’s clinical data and provides guidance accordingly.”

Risks of IVR

I didn’t find the specifics risks of IVR for healthcare, but here are the common problems with these systems:

  • Incorrect interpretation – IVR systems rely on numbers and selections input via the customers’ telephone keypad. Mistakes can easily be made, with fingers mashing the wrong button or in the middle of typing out a long account number.
  • Takes too long – While it only takes a moment to ask a friendly receptionist what a business’ hours are, waiting through an entire menu of options just to find the right extension to reach a live person is a waste of customers’ time. While listing a menu of options may seem convenient for customers, it becomes an inconvenience when the choices aren’t clear or don’t fit the action a customer wants to take.
  • Impersonal – IVR systems also lose merit because they’re impersonal. There’s no friendly voice saying “Hello!” when a customer calls. Instead, it’s a computerized voice that speaks what it was programmed to say. There’s no chance of the caller being remembered from a previous interaction, or for special exceptions or solutions to be made.

High level project plan

Right now, we need to know what is the real demand/interest within the community for adding IVR functionality to OpenMRS. This would allow us to move on further with a project plan.

1 Like