+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).