CONTENTSINTRODUCTION 2

PROBLEM STATEMENT 2

OUR FINDINGS 3

COMMUNITY DISCUSSION 3

PROPOSED SOLUTIONS 4Option1 Develop new component in React and redesign sync strategy 4

Technical Analysis 4Summary 4Impact to Customer 5Pros 5Cons 5

Option2 Enhance existing application 7Technical Analysis 7Summary 7Impact to Customer 7Pros 8Cons 8

Option3 Build a new application in a New Tech Stack(React) 10Technical Analysis 10Summary 10Pros 10Cons 10

APPENDIX 14References for solution proposal 14React vs AngularJS Analysis 14

Bahmni Connect Tech Analysis

INTRODUCTIONBahmni Connect is an offline version of Bahmni EMR(with minimal functionality) that allows clinicians or care providers to conduct outreach programs and treat people in areas where there is limited or no internet connectivity. This application lets users/clinicians sync patient data from the Bahmni server(based on location defined) onto a tablet so they can have the required data for treating these patients. Additionally they can sync all patient observations gathered from their home/site visits back to the Bahmni server.

PROBLEM STATEMENTOne of our implementations have outreach programs as part of their mission which is critical for them. Their use case requires them to cater to 1000+ patients having more than 1L observations per clinic captured on Bahmni. The current Bahmni Connect sync strategy is not scaling well and has severe performance issues, making the Bahmni Connect product practically unusable and impacting the overall user experience.

A categorized view of the problems noted are,

Category1: Issues related to the way Bahmni Connect is configured on site➢ Blank page on connect➢ Patient data not syncing to connect device

Category2: Issues related to the way observation forms are filled up on the device running the Bahmni Connect application

➢ Errors thrown when syncing data from Bahmni Connect device back to the Bahmni serverCategory3: Bahmni Connect device not scaling to their volume of data or metadata

➢ Extremely slow sync of data➢ Performance issues

Bahmni Connect Deployment StepsThe first two categories of problems have been seen and can be resolved with mitigation steps and training of end users. The inputs from community thread https://talk.openmrs.org/t/bahmni-connect-registration-and-clinical-screen-are-blank/15214/7 were sought to resolve the issue

The third category is the one which would need careful consideration to design a solution.

OUR FINDINGS

To understand the third category better, we have put some numbers to the discussion to help understand the scale of the implementation. Out of 100 patients/encounters managed in a clinic(Bahmni installation) , 85 are assigned to the same location(id).The scale we are dealing with is rather big with ~90k patients and ~200k encounters.

Bahmni Connect by design today does an initial synchronization where it needs to pull down all the metadata + data related to patients, encounters for a location before loading its home page and allowing operations to start.This ‘eager’ fetching of data is causing extreme slowness issues on the connect devices. We are seeing multiple issues like initial sync erroring out midway multiple times, PWA devices becoming sluggish with prolonged usage etc.

A word on Sync Strategies in Bahmni Connect :

Bahmni by design maintains a log of events in a table called ‘event_records’ in the OpenMRS database.This includes categories of events like patients, encounters, drugs , offline-concepts. This log contains paths to each of these objects. This table would have records for all data on the clinic. So if a clinic has 10 locations there is no way to query event_records directly to figure out what data qualifies for which location. Bahmni connect needs a way to query the location mapped data to pull down ‘just enough’ data on a PWA device.For this reason Bahmni Connect PWA pulls down records from a different table called “event_log”.There is a service sitting in the middle which reads data from event records, adds a location specific ‘filter’ on it and saves to the event_log table with the added ‘filter column’.The bahmni connect OMOD namely bahmni-offline-sync defines an interface to define sync strategies.A sync strategy allows us to define a ‘filter’ criteria on how we want bahmni-connect to pull down records.Bahmni provides two sync strategies out of the box namely location based and id based strategies.For this reason historically in the cases where we have had to handle data scenarios typically what has been done is we have created new customized syncing strategies for the implementation and attempted to resolve scale issues.

COMMUNITY DISCUSSION

The challenges and enhancements on Bahmni Connect were discussed over PAT calls and below threads have details of the same.

Talk Thread ● https://talk.openmrs.org/t/bahmni-pat-call-15-july-2020/29438/5 ● https://talk.openmrs.org/t/synchronization-of-selective-records-to-bahmni-connect/28849

From our conversations with community and the talk threads associated to Bahmni Connect it was evident that several community members are facing issues and have suggested work arounds or chosen custom proprietary solutions to meet their use cases.

The investment on a solution would be accepted only if its for a social good. PSI does not encourage building of proprietary solutions as it deviates from their vision of investing for social good and also incurs a maintenance overhead.

The solution design would have to cater to a larger audience and make it usable by one and all

PROPOSED SOLUTION APPROACHES

Option1 Develop new component in React and redesign sync strategy

Technical Analysis

Complexity: HighRisk: Medium

A team of developers conversant with React and functionality context would be required.

Summary

In this approach we will meet the expectations at both technical and business levels . We believe that adding a new sync strategy alone will only work as long as the use case changes again. Having a customized search will help users create their own sync strategy that will be far less likely to have to change in the future. Also using React to develop the new component would make the added code ready for future.

The idea is to redesign the sync strategy and give users more flexibility in defining the subset of metadata or data that they wish to sync to the Bahmni Connect device.

● Come up with a new option to use connect to search for patients/encounters on the connect UI.● Develop this component in React and include in existing bahmni-connect code.● Make backend changes to accommodate these searches.● Add further customizations to support a new syncing strategy

○ This would require detailed discussion with users on the new criteria to partition the data● Design new customization rules to do selective download of data (only what is required)

Impact to Customer

There are 2 aspects that we are resolving as part of this approach

● New component built in React● Redesign the sync strategy

ProsRedesign the sync strategy

● Performance issues can be overcome● Optimum disk utilization on the offline device● Adding functionality with no technology debt

Cons● Initial learning curve. ● Mixed user experience(UX) as most of the app would remain on AngularJS● Any configurability being designed should have a wider acceptance or support from the

community.● We have to ensure backward compatibility for existing connect users● Moving to react would be an additional effort as against focusing only on the sync strategy

redesign.

A look into the areas that would be affected by the changes via this approach are on the next page.

Option2 Enhance existing application

Technical Analysis

Complexity: Medium Risk : Medium

SummaryThis approach is a subset of the previous option. Here, we intend to retain the current core functionality on the AngularJS code base and only change the logic around the sync strategy.

● Come up with a new syncing strategy after discussion with users on a new criteria to partition the data.

● Come up with new customization rules to do selective download of data the user really needs.● Optimize existing code to remove unnecessary files and refactor

Although this approach on a surface level will add more functionality to existing AngularJS code base , it will allow us to resolve the core problem with Bahmni Connect not being able to scale up to larger volumes of metadata and data. Just like Option1, here also we will need to rethink sync strategy as well as customization rules if any.This will be easier to get merged back into the product as neither the tech stack changes nor the configurability problem of the Option1 approach will impact existing users.

Impact to Customer

The development phase is shortened and as a result the effort and cost associated will also be low.

Pros● Ability to impact more on the scale problem head on● Ability to go faster into production and resolve issues for affected users quicker● Community support would be as before

Cons● Staying at AngularJS and adding new features is adding tech debt● AngularJS’s long-term-support (LTS) is ending in July 2021● The current code would become legacy code and maintenance on the long run could be

challenging. Lack of AngularJS technical expertise in market would entail long ramp up time to maintain code in future

● New security vulnerabilities or deprecated libraries in the long run could impact us.

A look into the areas that would be affected by the changes via this approach are on the next page.

Option3 Build a new application in a New Tech Stack(React)

Technical AnalysisComplexity: High Risk : High

Front End Tech Stack React/Redux

Back End Tech Stack Existing OpenMRS built on Java8 and Spring Boot

Reusable components

Impact on product existing functionality

Backward Compatibility

Summary

Considering the use-cases and survey responses from community and costs associated with the approaches, we can build the entire offline application from scratch and rethink the design. In this we could

1. Keep the backend tech stack untouched. Add code to suffice new requirements. 2. Add logic to support a new syncing strategy based on the new criteria to partition the data.3. Need to add support for behavior PWA has by virtue of being a packaged version of the same

main application.

Pros● We can build a robust product from scratch catering to maximum community use-cases

around using an offline application● Build a solution using the latest tech-stack on PWA

Cons● We have to ensure backward compatibility for existing connect users● Cost of building the solution from scratch and inability to use the current functionality

A look into the areas that would be affected by the changes via this approach are on the next page.

The above changes notwithstanding we would need to make several changes on the Bahmni connect backend which would be the same across all of the above approaches.Here is a diagram showing the affected areas on the backend.

Suggested estimates for effort can be found here : PWA Customised Sync EstimatesPlease note that these estimates are indicative numbers at a very high level. As a large part of the work would depend on what we uncover during the initial requirements understanding phase. We would need to have extensive discussion to understand how to break this work over time by priority so that we can show value quicker as well as uncover more complexities that we are not able to foresee at this point.

APPENDIX

References for solution proposal

● https://talk.openmrs.org/t/bahmni-connect-registration-and-clinical-screen-are-blank/15214/6 ● https://talk.openmrs.org/t/bahmni-connect-android-optimizations/25010 ● https://talk.openmrs.org/t/bahmni-connect-new-offline-sync-strategy/15129

React vs AngularJS Analysis

Features Angular ReactFramework or Library It is framework It is a library

Learning Curve It has a steep learning curve Quick learning curve

Bundle size & Download

https://bundlephobia.com/result?p=@angular/core@9.1.11

https://bundlephobia.com/result?p=react-dom@16.13.1

Ease to start Zero configuration needed Configurations are needed

Backward compatibility

Has a history of breaking changes with recent releases

Nothing reported so far

Community support Decent community support Huge community support

Performance Not well supported for table like format Well suited for everything

OOJS/Functional More towards object oriented programming More aligned towards functional programming.

Performance Reported low performance for huge data set High performance

Language Forces Typescript as a development language Can use JSX and Typescript both as a language

Binding type Two way binding makes it slower with large codebase

One way binding. React is just a library and works top down.

Development speed and productivity

It is more productive in initial phases as it is a framework

Provides a great flexibility and very close to native Javascript which makes it a great choice after 2-3 months.

Long Term Support Angular 8 - Nov, 2020 Not Applicable

Demographics https://2019.stateofjs.com/front-end-frameworks/overview/#overview

https://2019.stateofjs.com/front-end-frameworks/overview/#overview

Trends https://www.npmtrends.com/@angular/core-vs-react-vs-angular

https://www.npmtrends.com/@angular/core-vs-react-vs-angular

Below statistics show the increase in demand for React over time.Note: Please visit this WebSite for more detailed info on statistics

Below statistics indicate that React has an acceptance level of 89% as of 2019.Note: Please visit this WebSite for more detailed info on statistics