...
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.
Currently Under Development
| Feature Description | Implementation |
|---|---|
| Android Client Configurable Views - System administrators will be able to update the views in the OpenSRP Android client through a server side configuration. The configuration is synced from the server to the client. Administrators can configure views for register views and Enketo forms. | TB REACH project |
| Splitting ZEIR App In to Multiple Libraries - Numerous features were developed for the ZEIR mobile application. Many of these features can add value across multiple mobile implementations. The team is undergoing an activity to split core features into independent libraries so they can be linked across applications. | OpenSRP Core |
| Testing Android Performance and Sync - The team is testing the Android client sync and performance with thousands of records on the Android device. This testing will identify bottlenecks and provide a list of features that can be developed to improve the user experience. | ZEIR |
| HPV Mobile App - The team is developing a mobile application to support HPV immunization services in Uganda. This app will utilize the Android client Configurable Views feature to implement multiple registers, workflows and dynamic forms on the mobile device. | HPV Uganda |
| 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 | (TBD) |
| 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 |
| Extended RapidPro Integration - 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. | ZEIR |
| 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 |
| Data Warehousing and Analytics - The teams are actively developing connections to cutting edge open source data warehousing and analytics solutions that promise scalable and responsive custom tailored views to better understand an implementation. These systems consume information from multiple data sources allowing implementers to combine, slice and dice information through a friendly interface. | ZEIR, 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, receivied and consumed. | OpenSRP Core |
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). |
| Explore Alternate Server Database Solutions - OpenSRP uses CouchDB for managing the synchronization of records. As we work through the Android client performance testing, we identify that CouchDB may require upgrade or significant changes. We are keeping a list of features required for the server side database technology and would like to compare them against current database systems. |
| 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. |
Improved App and Server Packaging - The teams would like 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. |
| 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 server to integrate with third party systems like OpenHIE, shared health records, etc. |
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 |
|---|---|
| CouchDB upgrade to v.2.x - We currently use CouchDB v 1.6.1 in production environments. Upgrading could improve performance but would likely have a breaking change in CouchDB and Lucene. | Medium |
| OpenMRS upgrade to v.2.x - OpenMRS platform 1.12.0 is currently supported in OpenSRP. The OpenMRS community is no longer supporting this version and we should consider upgrading the OpenMRS platform to the latest version for continued support. | 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 |
| 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 |
| Java 9 - OpenSRP currently deploys on Java 8. Java 9 presents a number of changes to how internal packages are structured causing build errors. Java 8 will not reach end of life support until 2020. | Low |