As you’ve all probably seen, we’re in the midst of transforming Bahmni from being a ThoughtWorks-owned project, to being a true FOSS project, with a coalition of organizations and individuals collaborating on its software development.
In early October, in just a few weeks, we will be spinning up a new iteration of the development team, and with this, we’ll be putting together a new Road Map.
In the medium-term, we’ll have a more formal Roadmap process (which is very underspecified in this Bahmni Governance document).
Right now, though, we are doing an abbreviated process to determine the first couple of product enhancements for this team to work on.
Action Item
Please share your thoughts about what should be the next one or two enhancements made to the Bahmni product.
If you share a rationale for why this is important, or more detailed designs about what a feature should look like, this will get more attention. But even just a one-line comment or a link to something in the Trello Big Feature Board is valuable!
Comments before the Product Architecture Team call on Wednesday September 20 will also get more weight.
My broader theme here is to consolidate what is already there in Bahmni and make it work well - as there is a whole lot already there. Second is start moving in the direction such that adding completely new modules on the EMR side becomes feasible.
Consolidate
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 - implementer trying to set this up for the first time, administrator, end user and support person. Ask the question, is it simple for them to do their work. I feel if we do this rigorously we will find that lots of small - application, automation, and documentation related things to do. These will help in making Bahmni more reliable and engaging for all types of users.
b) We could take a hard look at the data administration interface and ask whether it is easy to administer Bahmni. Specifically, I am referring to the fact that preparing Bahmni for end-users requires dealing with Bahmni app config, Global properties, Bahmni admin UIs and OpenMRS admin UI. This is a complex act.
Consolidating and improve our reporting story on Bahmni EMR side
Currently, we have a variety of options Bahmni Reports, OpenMRS reporting, some places use JasperReports because that is what they can get to work. I think and will admit that this requires some making some hard choices. But we should try to get to a point where we have a professional quality reporting solution.
Bahmni EMR as platform
I am not suggesting anything really gigantic to develop, but just make it possible for someone to read Bahmni/OpenMRS documentation, develop their own module, make it look not reasonably native and interoperate with rest of the application.
Bahmni Docker
We have done quite some work in that direction, and all the while we developed our know-how about Docker and envision to keep improving what we have done.
Bahmni is a multi-component product and we would like to have it completely Dockerised starting by Bahmni EMR only, but then adding all the bits that go with it: OpenELIS, Odoo and more.
Down the line lies the ability to generate Bahmni instances seamlessly based on versioned configurations.
Improve / consolidate / streamline the existing
This would converge to what @petmongrels suggested. While the new Bahmni development team organises itself over the next 6 to 12 months, perhaps is it reasonable to refrain going into major features but rather use that time to work on improving the existing and establish the workflow.
Bahmni extensions
I dream of a world where OpenMRS OWAs could also be used in Bahmni. I put this as my 3rd item because it raises many questions about the actual direction of Bahmni as a well defined “standard” product ready to be consumed by end users.
This was described under the “Integrate OpenMRS Reporting With Bahmni” card.
-I don’t know what a full integration would look like, but I feel like even the ability to access/run reports defined with the OpenMRS reporting module within the Bahmni UI would be enough as first phase.
2. Sync
This also was on the road map -Bahmni Hub & Spoke Model, but looks like it has been put on hold.
Looking at the recent discussions on the Sync 2.0 project, there might be some leverage on the work being done that can help resuming and pushing this feature to get it available in Bahmni.
From my point of view it would be nice if you could could open-source the configuration and steps of the Bahmni build-pipeline (*). This could help implementers taking ownership of their deployment and help to do customizations like Ubuntu deployments with only OpenMRS, the Atom feeds, and another ERP system. Just an idea…
Further, it would be nice if you present the Bahmni project in the FLOSS Weekly podcast (see examples of previous shows). If you also think so, one of the project leaders can write an email to Randal Schwartz at merlyn@stonehenge.com to schedule the interview.
Maybe it is already possible compile the YUM packages with the bahmni-package but this approach seems to be not a supported workflow right now. Further I am afraid that it would be difficult to tell the installer script to use self-compiled packages.
I’d love to see more continued work to converge with other initiatives in the OpenMRS ecosystem where Bahmni and non-Bahmni projects can all benefit. The more that Bahmni and the Reference Application run on in common the better, IMHO. So I’d personally vote for projects that move us in that direction.
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:
Fill L10n gaps.
That’s basically chasing hardcoded English words.
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.
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 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
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.
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.
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.
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).
ERP order syncing should go beyond radiology, lab and medications such as consultation orders. Raised here.
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
Patient Attributes do not sync in ERP as name-value pair as it was happening in the earlier version. Raised here
Refund receipt should also get printed
Backup Restore
All backup should get stored at one place say /data instead of different folders for openmrs and openerp
User Interface
Autocomplete used in ConceptSetUI should also have text search like patient search otherwise users have to type exact name which becomes difficult
Extending platforms
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.
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.
Stability of the bahmni-connect deployment. Every deployment takes days because of minor issues at places.
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)
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.
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. we reduce one big infra stratight away and just use one single database system.
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.
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.
Extensions
– e.g. Ability to plugin new UI module and embed additional extensions within existing ones. sharing contexts.
Search
– use Lucene search for patients in registration and every other place where applicable.
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.
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.
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.
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.
we reduce one big infra stratight away and just use one single database system.