Implementations of OpenSRP are diverse in requirements and outcomes. We continually share libraries and features to ensure single investments have a larger impact. This page provides a common area for community members to share the product roadmap for their implementation of OpenSRP.
Completed
| Feature Description | Implementation |
|---|---|
ANC Reference Application - This application is funded by the WHO and includes a multi-step process for coordinating care of pregnant women including tracking their health over 8 contact visits, diagnoses, conditions, complex business logic, in-app dashboards, and reporting | WHO Reference Application |
Business Logic Improvements - We are improving the process for defining business logic using the MVEL template language that's supported both in the OpenSRP server and Android client | OpenSRP Core |
Mobile Map Views - The team is working on a mobile map view for OpenSRP that operates offline, using the information that's already stored on the tablet. These views act as a base layer so implementers can load whatever information on the map through JSON configuration. This innovative technology will allow us to identify where clients are located, check-in when health workers are present and, eventually, support workforce planning | Reveal |
Enhanced DHIS2 Reporting - Numerous projects are working on enhanced DHIS2 reports that allow Android device users to review, adjust and submit reports to DHIS2. This feature already works in numerous implementations and new reports are actively under development on the client and server sides. | Bangladesh, ZEIR |
Improved App and Server Packaging - The teams are working to make it easier to package and deploy the end-to-end OpenSRP solution for a given implementation. This includes creating deployment bundles that streamline the setup process and operationalization of the Android client, OpenSRP server, OpenMRS server and data warehouse. | OpenSRP Core |
Integration with Open Logistics Management Information System (OpenLMIS) - The team is building a server side integration with OpenLMIS to support the management of physical stock, reordering and receiving shipments at the facility level. This feature will make it easier for implementers to track medical commodities as they are requested, received and consumed. | OpenSRP Core |
Task Management - The Reveal project is developing a task management system that allows users to create tasks, assign them, perform them and close them. | Reveal |
Mobile to Mobile Sync - The team has worked on mobile to mobile sync in offline contexts where a mobile worker travels to a number of clinics, syncs the clinic with their information and takes the master device to a wifi hotspot to sync data from all clinics. | UNICEF West Africa |
Improving the Android Client Run and Sync Process - Bangladesh is improving the client processing functionality from the event client data model into the local relational model that's used for searching and display. This will improve the performance of the Android client and the sync process | Bangladesh |
Server Side Form Configuration - The teams would like to improve the form configuration process so forms can be stored on the server, synced to the Android client and you can load forms based on the team, location and user group | Living Goods |
Optimize / Improve Native Forms - Refactored the native forms core library to improve performance | OpenSRP Core |
Add support for Kubernetes - Migrated devops process to the Kubernetes | OpenSRP Core |
Advanced Mobile Workforce Management and Planning - The workforce is the center of an OpenSRP implementation. We would like to introduce systematic improvements that help frontline health workers and managers to better understand, track and improve the day-to-day activities of their team. This includes adding metadata information to understand who is logged in to a particular device, how long they spent on a particular activity and opening up feedback loops across the platform. This includes adding reporting and messaging components, push notifications and centralized interaction between users. | Goldsmith Project |
Currently Under Development
| Feature Description | Implementation |
|---|---|
OpenSRP Web Dashboard - The Bangladesh team has built a web dashboard and made it available to the community. We are working together to jointly define scope and identify areas where it can be extended for general OpenSRP use. The web application dashboard runs off of the OpenSRP server's database. Adapting the current OSP Web to use FIHR | Bangladesh, OpenSRP Core |
Improved OpenMRS Sync - The team has upgraded OpenSRP server to work with the latest versions of OpenMRS and is working on an improved sync pattern using Apache Nifi. | OpenSRP Core |
Bluetooth Integration with Blood Pressure Monitoring System - The Indonesia team is piloting a feature to integrate the Android client with a blood pressure monitoring system. This opens the door for remote sensors to submit information to OpenSRP. | Indonesia |
RapidPro Integration to Create Clients and Events - A RapidPro proof of concept using the Aleena bot was demonstrated in 2015. This proof of concept is currently being transitioned to production quality so OpenSRP server can send messages to mothers for appointment reminders and broadcast messaging. | (Pending Contract Award) |
Improve Sync to External Systems - We would like to make the sync process to external systems like DHIS more robust by transitioning them to Nifi. | OpenSRP Core |
FHIR Integration and Sync - FHIR is an emerging technology in the interoperability space. We recognize that identifying and implementing FHIR interfaces could improve the ability of OpenSRP servers to integrate with third party systems like OpenHIE, shared health records, etc. | OpenSRP Core |
Data model configurability - This enables us to have multiple apps from the same codebase with different database structures. Two apps generated from the same codebase/apk can record and store different data because the data structure/model is configurable eg. a single APK can result into two apps with one having the ability to record and store the house number while the other does not, such variations do not need to be developed into the codebase but can be implemented as configurations. | OpenSRP Core |
Redundancy across AWS Regions - support load balancing or failover across AWS Regions | OpenSRP Core |
Implement role management for OpenSRP - A security feature that is being added to OpenSRP to ensure users access data that they are authorized to access. This is done using roles in Keycloak. Users are assigned specific roles to add/view/edit specific data in OpenSRP. | OpenSRP Core |
Migration to Workmanager for Client Job Scheduling | OpenSRP Core |
Continuous Integration set up for Instrumented tests | OpenSRP Core |
Add support for performance monitoring SDK on the Android client - Add Firebase Performance Monitoring SDK to record metrics on method execution times to provide more visibility on slow methods. | OpenSRP Core |
Deploy redis cache for High Availability (Cluster) - Improve the redis cache service availability by minimizing downtime | OpenSRP Core |
Support for Kubernetes for OpenSRP web frontend | OpenSRP Web |
Feature Wishlist
This area focuses on crosscutting features that development teams would like address to systematically improve how the system operates. These features aren't currently scheduled and can be developed by anyone in the community.
| Feature Description (in no particular order) |
|---|
Android Client Fuzzy Search - We would like to implement a fuzzy search feature on the Android client that allows users to type a name and have common spellings returned. Currently, they must have the exact spelling to return a result. |
Systematic Patient Deduplication Across Android Client, Server and Reporting - Currently duplicate patients are identified at the server level and merged. We would like to add the ability to merge clients on the Android Client and ensure that those records are merged across the entire system (server, all Android clients and reporting). |
Remote data wipe on the Android client - ability to remove data on devices belonging to providers who are no longer authorized |
Implement encryption for sensitive files on device - generic support for encryption of files collected e.g. patient images |
Migration to spring boot as the backend framework for OpenSRP |
Encrypted OpenSRP Databases & File Storage |
Implement/Enable password management - 2FA for privileged users (e.g. Front End Web) |
Implementation - OpenSRP data access for external systems - Push Notifications MQTT |
Technical Debt
This area focuses on keeping a running list of technical debt that can be systematically addressed across implementations. Technical debt is a software development concept that focuses on identifying the compromise between choosing an easy solution now vs. using a better approach that would take longer. In practice, many of these items focus on keeping software dependencies up to date.
| Technical Debt Description | Impact |
|---|---|
Tomcat 7 - OpenSRP Server works with Apache Tomcat7 in many production environments, which has reached end of life support. The current focus of development is tomcat 8.5.x and 9. | Medium |
| Implemented Tech Debt | Impact |
|---|---|
OpenSRP Server Split and Refactor - We split the OpenSRP server and refactored it so it's more lightweight and implementation specific. | High |
Client Refactoring Clean-up - OpenSRP Android client has project modules that each contain components that should be shared. We have cleaned this up. | Medium |
Removed MOTECH and OpenMRS dependency in OpenSRP server - OpenSRP initially depended on OpenMRS to provide authentication, team management, location management and user management services however that is currently supported natively in OpenSRP with the authentication service being handled by integration with Keycloak a robust and multi-featured authentication system. | Medium |
Completely Remove CouchDB and Lucene dependencies from OpenSRP server. | Medium |
Spring Framework upgrade to v.5.x - We currently depend on Spring v 3.1.0 which has reached end of life support. The latest version is 5.0.x. | Medium |
Unit tests were added to improve the testing coverage - This vastly improved the stability of our code base greatly reducing the number of regression bugs when new features were added | Medium |
Upgraded to Java 9 - Support for the latest Java version is recommended in order to take advantage of the latest improvements in the Language | Low |
Moved all the client libraries to android x - This is a recommended upgrade for the Android Framework since the libraries previously used were deprecated and no longer supported by the foundation. In order to take advantage of the latest Open Source updates, patches and fixes we needed this. | High |
Added support for performance monitoring & analytics using firebase on the Android client - We implemented performance monitoring which helps gain insight into the performance characteristics of the android client. Integration with the performance monitoring SDK allows collection of performance data from the app for review and analysis and this can be used to understand the areas to be improved as well as use the info to fix performance issues | Medium |