INTRODUCTION

 CONTENTS TOC \h \u \z INTRODUCTION PAGEREF _r0e4o5z3wk8y \h 2PROBLEM STATEMENT PAGEREF _e790y6z4mjnq \h 2OUR FINDINGS PAGEREF _cd5h2c2b0drh \h 3COMMUNITY DISCUSSION PAGEREF _nd2g86r9nviq \h 3PROPOSED SOLUTIONS PAGEREF _cli5cae6q7pc \h 4Option1 Develop new component in React and redesign sync strategy PAGEREF _dt3i66qt5jwo \h 4Technical Analysis PAGEREF _9qm5yryb65x5 \h 4Summary PAGEREF _nn99o8rr43am \h 4Impact to Customer PAGEREF _8w6a5c20y0n1 \h 5Pros PAGEREF _e6xob7ikaahm \h 5Cons PAGEREF _sj6ks6qoigb2 \h 5Option2 Enhance existing application PAGEREF _34cry3ew9pz1 \h 7Technical Analysis PAGEREF _8nemvdw15hf9 \h 7Summary PAGEREF _hv99rawm61qh \h 7Impact to Customer PAGEREF _rh2yzqqnonru \h 7Pros PAGEREF _gddpnonwv6n3 \h 8Cons PAGEREF _gddpnonwv6n3 \h 8Option3 Build a new application in a New Tech Stack(React) PAGEREF _a2c66pjiileu \h 10Technical Analysis PAGEREF _tat59tw8nzwn \h 10Summary PAGEREF _pdorjnigjhq8 \h 10Pros PAGEREF _b4apn6z2qpdr \h 10Cons PAGEREF _93972t5ry26y \h 10APPENDIX PAGEREF _qam5gvkabcbn \h 14References for solution proposal PAGEREF _793atf74annz \h 14React vs AngularJS Analysis PAGEREF _4q18v4ucjfpj \h 14Bahmni Connect Tech AnalysisINTRODUCTIONBahmni 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 siteBlank page on connectPatient data not syncing to connect device Category2: Issues related to the way observation forms are filled up on the device running the Bahmni Connect applicationErrors thrown when syncing data from Bahmni Connect device back to the Bahmni serverCategory3: Bahmni Connect device not scaling to their volume of data or metadataExtremely slow sync of dataPerformance issuesBahmni 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 were sought to resolve the issueThe third category is the one which would need careful consideration to design a solution.OUR FINDINGSTo 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 DISCUSSIONThe challenges and enhancements on Bahmni Connect were discussed over PAT calls and below threads have details of the same.Talk Thread 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 allPROPOSED SOLUTION APPROACHESOption1 Develop new component in React and redesign sync strategy Technical AnalysisComplexity: HighRisk: MediumA team of developers conversant with React and functionality context would be required.SummaryIn 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 e 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 dataDesign 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 approachNew component built in ReactRedesign the sync strategyProsRedesign the sync strategyPerformance issues can be overcomeOptimum disk utilization on the offline deviceAdding functionality with no technology debtConsInitial learning curve. Mixed user experience(UX) as most of the app would remain on AngularJSAny configurability being designed should have a wider acceptance or support from the community.We have to ensure backward compatibility for existing connect usersMoving 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 AnalysisComplexity: 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 e up with a new syncing strategy after discussion with users on a new criteria to partition the e up with new customization rules to do selective download of data the user really needs.Optimize existing code to remove unnecessary files and refactorAlthough 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. ProsAbility to impact more on the scale problem head onAbility to go faster into production and resolve issues for affected users quickerCommunity support would be as beforeConsStaying at AngularJS and adding new features is adding tech debtAngularJS’s long-term-support (LTS) is ending in July 2021The 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 futureNew 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/ReduxBack End Tech Stack Existing OpenMRS built on Java8 and Spring BootReusable components Impact on product existing functionalityBackward CompatibilitySummaryConsidering 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 Keep the backend tech stack untouched. Add code to suffice new requirements. Add logic to support a new syncing strategy based on the new criteria to partition the data.Need to add support for behavior PWA has by virtue of being a packaged version of the same main application. ProsWe can build a robust product from scratch catering to maximum community use-cases around using an offline applicationBuild a solution using the latest tech-stack on PWAConsWe have to ensure backward compatibility for existing connect usersCost of building the solution from scratch and inability to use the current functionalityA 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. APPENDIXReferences for solution proposal vs AngularJS AnalysisFeaturesAngularReactFramework or Library It is frameworkIt is a libraryLearning CurveIt has a steep learning curveQuick learning curveBundle size & Download to start Zero configuration neededConfigurations are neededBackward compatibility Has a history of breaking changes with recent releasesNothing reported so farCommunity support Decent community support Huge community supportPerformance Not well supported for table like formatWell suited for everythingOOJS/Functional More towards object oriented programmingMore aligned towards functional programming.Performance Reported low performance for huge data setHigh performanceLanguageForces Typescript as a development languageCan use JSX and Typescript both as a languageBinding type Two way binding makes it slower with large codebaseOne way binding. React is just a library and works top down.Development speed and productivityIt is more productive in initial phases as it is a frameworkProvides a great flexibility and very close to native Javascript which makes it a great choice after 2-3 months.Long Term SupportAngular 8 - Nov, 2020Not ApplicableDemographics statistics show the increase in demand for React over time.Note: Please visit this WebSite for more detailed info on statisticsBelow statistics indicate that React has an acceptance level of 89% as of 2019.Note: Please visit this WebSite for more detailed info on statistics ................
................

In order to avoid copyright disputes, this page is only a partial summary.

Google Online Preview   Download