Help define the short-term Bahmni Roadmap

And also +1 on @rubailly’s suggestion to connect Bahmni with the Reporting module. Internally at MKS we had created this task:

Reports app to handle configured ‘date range’ reports NOT coming from Bahmni Reports

But a broader integration would be more than welcome.

There are quite a few suggestions here which are very good and worth exploring on their own. Just want put some context in which we should explore this roadmap. This is a very short term roadmap (8-10 weeks) and a really small team (3.5 FTEs? with only 2 prior Bahmni devs).

The Key objectives to me are:

  • Getting Bahmni community contribution to code development started - which includes - agree on necessary processes, designated code reviews, working on pull requests, answering dev / implementer’s questions on this forum, carrying out code walk through etc.
  • Get new Bahmni developers familiar with the code base

Towards these goals I suggest:

  • Identify simple low hanging tasks which can be completed in the time frame and helps validate the point above - Typically bug fixes, small enhancements to existing features, documentation updates, writing any missing tests etc. What @petmongrels has suggested under consolidation nicely fit here. [quote=“petmongrels, post:3, topic:13326”] Consider every feature in Bahmni and analyse the gaps. I can think of following ways to do this: a) Consider all users around that feature [/quote]

I also agree that the key objectives are to onboard new developers, and refactor our processes to be fully FOSS, and that preferring on smaller “consolidation”-style things over big new features is wise in the short term.

The best way to do onboarding and transformation is in the context of focusing on a few specific areas, especially areas in which we’ll be able to engage BA and user feedback…

I know that you (yes, you, the person reading this message) have some idea of one feature or enhancement that would be valuable to you, or to your clients. Please share that idea!

So if we are to shortlist smaller items to “get things going”, I would narrow down our choices to:

  1. Fill L10n gaps. That’s basically chasing hardcoded English words.
  2. Enable i18n. That’s an extension of the previous point to allow for a complete language switch at runtime. We have at least a big PR coming for Bahmni Core to support this.
  3. Enable simple “date range” reports from the Reporting module to be run via the existing Reports app.

Clearly 1 and 2 go together to a large extent. All the 3 points above are required by our current implementations in Southeast Asia.

1 Like

+1 to the key objectives of onboarding/ramping up new developers and improving processes to be fully FOSS. I would think one stream could be dedicated to bug fixes, ease of installation, community support (pull requests, talk, irc), incorporating feedbacks on appointment scheduling and form builder.

I also like the idea of engaging devs in areas so they are able to engage with users, understand the product and domain better. Some ideas that i have heard from client/community and are small enhancements and which could give exposure to different areas of Bahmni. This could form the second stream

  1. Cost of Care / Ability to fetch some information from ERP and show it up on EMR. It’s discussed in parts in this openmrs talk thread. It will give devs exposure to breadth ERP, EMR, creation of omod.
  2. Ability to upload external DICOM images to Bahmni (PACS). In my mind, It’s a small enhancement to current digital radiology integration feature and will give exposure to pacs integration to devs. More on the requirement in the trello card here.
  3. Making app more sensitive to provider - which will form the foundation to provide features like provider marking patients as favourites, showing data, forms, display controls based on who’s logged in and their privileges, subscribing to patients and getting alerts when there visit is opened. One of the requirements described in this trello card here. This will provide exposure to Bahmni EMR UI and API, plus openmrs model.
  4. Ability to add/modify/delete wards and beds using UI as people struggle doing it via SQL scripts as in the thread here. Development should involve building a simple UI layer on top of existing model.

I am curious about the asks for integrating openmrs reporting. I have used both in a single installation for different usecases. But not clear what’s the exact usecase for integrating them (keeping in mind the effort involved).

1 Like

Here is our list (In this feature list I could resist myself from including one or two bugs / issues which may need attention in the next version.)


  1. Operation Theater scheduling. Raised here

ERP Syncing

  1. Registration Fee to sync with ERP. Raised here

  2. ERP order syncing should go beyond radiology, lab and medications such as consultation orders. Raised here.

  3. Manually generated sales order triggers the corresponding purchase order for the supplier but the bahmni generated quotation / sales order confirmation does not trigger such the purchase order in spite of correct settings. This will also help to set up automatic POs for doctor’s payout. Raised here

  4. Patient Attributes do not sync in ERP as name-value pair as it was happening in the earlier version. Raised here

  5. Refund receipt should also get printed

Backup Restore

  1. All backup should get stored at one place say /data instead of different folders for openmrs and openerp

User Interface

  1. Autocomplete used in ConceptSetUI should also have text search like patient search otherwise users have to type exact name which becomes difficult

Extending platforms

  1. iPAD support - In spite of correct settings, camera is not accessible during patient registration and also receipt printing does not work on iPad.

Small items based on the tickets from implementations that we support.

  1. Ability to search diagnoses by a corresponding ICD-10 code. We have a hospital that had to move all its ICD-10 codes as search terms just to be able to search for it in the diagnosis screen.
  2. Stability of the bahmni-connect deployment. Every deployment takes days because of minor issues at places.
  3. Speed up deployment time (
  4. CentOS 7 support (it is going to be harder to deploy 6.x on newer hardware. In one case we got lucky that going upto 6.8 helped us with the right drivers)

From my perspective

Short Term

  1. Consolidate – Enhance, strengthen existing features, make them user friendly (e.g. Medication UI or Search options in Orders)
    – Make existing features easy to configure. We started “Implementer Interface” - one component of Implementer interface was meant to ease the configuration, setup options easy - e.g. dashboard config, report configuration, OpenMRS properties configuration etc. – making bahmni installation, upgrade and backup as easy and fullproof as possible. – Update documentation - its a continuous process though. add more contexts and examples. also on troubleshooting.

  2. Upgrade – OS - Centos 7 – Components - Odoo 10+. Investigate whether we should think of Bika. – Potentially MySQL 5.7? Although, this might be more done on OpenMRS side. 5.7 supports JSON data types. I have felt many times that having that would have solved some of the extensibilities desired and enhanced the data model without compromise or hacks. – Push OpenMRS to support PostGres. :wink: we reduce one big infra stratight away and just use one single database system.

  3. Infrastructure & environments – I believe that in the short term - this would be one of the most important task that would be undertaken. This also should provide us opportunities of if and how we should think about re-engineering the build pipelines.

  4. Build, deployment/installation – we should really move to “infra as code” and “build as code”. I do believe having GoCD allows us a lot of benefits. But there are lots of build code that ideally should move to the core repositories. Btw, there are already utilities in Bahmni repos to create Docker images, and considering that we should debate whether we should really support Ubuntu or other OS like windows, in the short or medium term.
    – re-engineer Bahmni packaging. Right now, a new bahmni release involves marking every other component same as the release number. Instead, we should have Bahmni release composed of independent component’s release numbers. It would also save space and download. there is a document we had created, I can share that if you are interested. – Bahmni installer ISO image. We have Bahmni offline installation but it does require doing advance caching work by implementers.

  5. Extensions – e.g. Ability to plugin new UI module and embed additional extensions within existing ones. sharing contexts.

  6. Search – use Lucene search for patients in registration and every other place where applicable.

  7. Reporting – consolidate different works that has happened – Expose Bahmni reports data as JSON. This just opens up someone else writing additional reporting/dashboard apps. imagine using something like or similar tech.

  8. API – manage and have better documentation for Bahmni specific APIs. – between systems consider moving/sticking to FHIR resources instead of OpenMRS or custom. – also consider consolidation of existing APIs - e.g. dashbaord controls make too many calls, we discussed in the past about consolidating to getting data flattenned from server and aggregating/providing on client side and providing javascript APIs for controls.

  9. UI re-architecture – its an ongoing process, some are set in motion. e.g. new Form tech will hopefully replace all conseptSetUI based forms and be future basis for any form (not just observation form) in Bahmni that supports extensibility to even custom implementations. But having the vision and keeping focus will be the key aspect. – we should also debate how we should manage Bahmni UI codebase. (They aren’t published to npm repos or versionable as such in current state)

(huh! thats quite some list, I didn’t even mention the Functional features)

When I suggested to use Bahmni in our organization there was a lot of positive feedback.

However, our chairman requested that we don’t start with the implementation before the support terms and conditions are clarified, see Terms and Conditions of Bahmni Support .

Maybe you can consider this subject in the roadmap planning as well, as this might be important to get new implementations on board.

@janux since this is a different topic, I have replied here (and let’s follow up there if you don’t mind).

In my opinion, we should develop part of Inpatient Module, may be Procedure management, Daily Status monitoring. This is in high demand from hospitals and clinics here.

@darius and all, those would be the low hanging fruits. Or at least a starter to do list while awaiting a more structured roadmap.

(I wasn’t sure if the issue about the Reporting Module limited integration into Bahmni Apps should be part of it? Just let me know.)

Cc: @ningosi @mjsanish @ekirapa @ajeenckya

@arjun, @vinay, @ramashish, we have created tickets for issues that you all suggested (ICD codes for diagnoses, backup/restore locations, manage beds UI). You can find the links in Dimitri’s post that I’m replying to.

Can you please comment on our update these tickets with more details (e.g. full user stories), very soon, because work is starting now.

For further information and the detailed requirement document please refer here

@ramashish would it be possible to share this doc as a Google Doc? This would make it interactive with others able to comment/edit… etc.

Hello everyone, am really not so technical in the bahmni implementations, but one of the things that I would suggest the bahmni team to consider in the next release is probably the “OWA”

@ejustine this is happening to a certain extent. Two tickets that bring in UI components are doing so through using OWAs, see:

  • BAH-378: Design and integrate bed management admin UI
  • BAH-314: Enable Bahmni Apps Reports app to handle ‘date range’ reports from the Reporting module

They are both ‘in development’.

See PR #24

  • BAH-317: I18N support when searching by identifiers and address fields values.

@angshuonline @darius @binduak @shruthipitta