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
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!
+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
All backup should get stored at one place say /data instead of different folders for openmrs and openerp
Autocomplete used in ConceptSetUI should also have text search like patient search otherwise users have to type exact name which becomes difficult
iPAD support - In spite of correct settings, camera is not accessible during patient registration and also receipt printing does not work on iPad.
– 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.
– 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.
– 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.
– e.g. Ability to plugin new UI module and embed additional extensions within existing ones. sharing contexts.
– use Lucene search for patients in registration and every other place where applicable.
– 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.
– manage and have better documentation for Bahmni specific APIs.
– between systems consider moving/sticking to FHIR resources instead of OpenMRS or custom.
– 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)
@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.