Help define the short-term Bahmni Roadmap

Software Bahmni
17

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 freeboard.io 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)