As discussed in the PAT call this week (24-Feb), I have summarised my findings on AngularJS codebase in Bahmni here: [Bahmni Blog] 1 Million Lines of Open Source Code. AngularJS codebase in Bahmni is about 164K. AngularJS will reach End-of-Life in Dec-2021, and we want to ensure that Bahmni code continues to move away from AngularJS and adopts React. This will ensure that future frontend code remains stable and we continue to find developers in the community who are comfortable with the tech stack.
Please read the blog for full analysis. Next steps as suggested in the PAT call (copied here from blog):
Remove deprecated AngularJS code: Like the appointments module and Forms1.x codebase from bahmniapps frontend repository.
Ensure all new feature development continues to happen in React and not in AngularJS.
Take community and volunteer help to quickly rewrite the smaller, less complex modules.
Refactor and rewrite Bahmni clinical controls (widgets) and reuse them in Bahmni EMR, just like how we written Form Designer in React and Form Controls are React controls running inside Angular Directives. This way a lot of complex functionality which depends on these controls can start becoming React-ified . And future extensions and controls can be written in this manner (lead by example).
Ensure we split functionality into their own bundles / repositories to make it easy to migrate frontend stack later. For instance the new appointment module is its own repository. This allows for easier debugging, refactoring, etc. because developers only need to understand one sub-domain to make changes (similar analogy as micro-services vs monoliths — but not too micro!).
What more can we do? Looking forward to your comments and suggestions.
@gsluthra Is there any plan to merge back the appointments module extensions back to the OpenMRS Reference app one so that there is only one community maintained module? Not sure about which other EMR features are different, but a list of these would be helpful to help think through such efforts
@ssmusoke the models are quite different. While existing ref app module is based on provider slots, Bahmni’s is based on service. The appt module (backend and frontend) are already used in some ref app contexts and also available as PWA
While am not well acquainted with the current work being done in openmrs 3.0 I get the impression that some of the bahmni-apps/features are being replicated…my question is whether bahmni has plans of extending the MF architecture to achieve what bahmni apps currently do. If that’s the case: then is it worth refactoring the bahmni apps as opposed to finding middle ground on MF to leverage it moving forward? cc @mksd@angshuonline@gsluthra@ssmusoke
I am not familiar with OpenMRS Frontend 3.0 MF initative. I spent some time over the last few days looking into it.
Here is what I understand about it:
Microfrontend style architecture, which allows for “independent” apps to be written and “plugged” in.
Has an assembly feature to pick/choose which apps to package in a distribution. See this video.
Seems to speak FHIR to OpenMRS backend (like SMART on FHIR vision). This means the backend needs to also speak FHIR (over APIs).
Just like Bahmni, it also has an Extension framework that allows Implementers to extend the reference/base app with custom features - like adding additional fields, validations or behavior (configured using JSON/JS or an Implementer UI). See this.
Eventually what all this means is that OpenMRS MF is a “sub-system” that will allow multiple-tech apps to be put together like Lego blocks and communicate over FHIR/API to OpenMRS backends (which can be openmrs core + modules).
Now coming back to Bahmni. Bahmni UI is already architected in a certain fashion (with Bahmni extensions support). Bahmni UI talks to (OpenMRS+Bahmni modules) over REST API. And this is deployed in 400-500 sites world wide.
If someone wanted to enhance Bahmni UI functionality – add a widget, page, screen; then it is unlikely that OpenMRS MFA can be used, since they want all EXISTING Bahmni functionality PLUS this new functionality, in the same frontend + Bahmni_OpenMRS backend.
I am not being able to envision how can Bahmni team adopt OpenMRS MFA without rewriting everything first. Here are some challenges I forsee:
Clients/Bahmni community would want the ability to migrate functionality-by-functionality without disturbing user expereince. If part of the new functionality is rewritten in OpenMRS MFA, it would not make sense to ask the same user to login into two different apps for two parts of “Clinical” functionality – like doing drug order in One, and Form filling in another.
It would be a lot of work for any team to ensure new app works in OpenMRS & Bahmni backend. What will likely happen is that certain MF apps will be seen as “Bahmni MF app”, managed by Bahmni community. If thats the case its anyways an independent piece of frontend code. It won’t get packaged in OpenMRS UI distro. So, then it might as well be developed in a manner that is fastest for Bahmni community to build/modify/maintain.
Microfront-end tech is quite complex to debug when things don’t work, and also quite complex for newbies to contribute. I feel it’s going to be risky for Bahmni UI to adopt OpenMRS MF – where a person needs to understand Bahmni complexity, implementation needs & then understand OpenMRS MFA architecture. The bar for contributions, testing and review just got even higher.
I can imagine certain independent pieces of functionality like maybe a seperate “admin” app, or a “lab” app, deployed as its own MicroApp and its own OpenMRS module – which will be NEW functionality, that can likely be adopted by OpenMRS and Bahmni equally and be developed in a common repo. In this case, people should be OK with saying - yeah I login into Bahmni EMR for Clinical work, but for doing say - certain ADMIN or LAB or REPORTING functionality - a seperate set of users use this other app which is an OpenMRS MFA app. This can only be true for sub-domains not currenlty supported by Bahmni.
I might be wrong in some of my assessment here – since I am not an expert frontend programmer, and haven’t worked on OpenMRS MFA. So, I welcome opinion of others in the community. I am also learning and making up my mind as we go along.
Please note: The above writeup is my summary and understanding of the situation and NOT a representation of the Community/Coalition/ThoughtWorks/etc.
Sorry I missed this.
I think thats a fair summary @gsluthra
There is one distinction that I would like to point out - MF is a generic framework, while the new initiatives that are happening in OpenMRS are towards a product. Obviously MF architecture/infra is going to get influenced by that, but someone can leverage MF f/w without alignment of OpenMRS product initiative. (please correct me if I am wrong)
I also don’t think (contrary to some opinions) that all setups/products from OpenMRS must follow the same UX. Bahmni is designed for small clinics/hospitals and as a point-of-care solution, rather than a retrospective system. Even in such cases, 2 different hospitals employ different process. So Bahmni will need to have its own UX (not just for backward compatibility).
I surely think Bahmni can leverage the tech backbone, but it does need to address it judiciously. Besides the design aspect, there is also the app/widget configuration bit which is completely different. We don’t want to make our existing userbases relearn/reconfigure or change our documentation. Technically, it might be possible to transform Bahmni config to the MF configuration runtime dynamically - but I wouldn’t underestimate the effort.
Also not in all cases Bahmni needs a Single-SPA approach. In a hospital, the registration clerk does only registration, an IPD nurse will handle only IPD … many cases do not warrant a Single-SPA approach.
APIs - to really leverage MF and interactivity between loaded apps and widgets - its essential to have a common model, and I understand and support wholehearted the FHIR standard adoption. But there are tons of gaps between FHIR spec and OpenMRS model (e.g. DiagnosticReport - I know many store them differently). At the same time, Bahmni uses a coarse grained service approach, while the MF does a fine grained approach over FHIR resources. To really leverage/bring synergy between 2 - we probably have to think of FHIR document approach (e.g. OP Consultation Profile, or Discharge Summary Profile, Prescription Profile) - thats a lot of work, and I am not sure if such broad level API work is happening on the FHIR module. AFAIK, its mostly driven by the MF and other project requirements.
For newer modules, I personally would be keen to try this out - e.g. Patient doc upload, order fulfilment - these are pretty simple and should be easy to adopt in MF.
The most difficult would be the clinical module - especially the dashboards - there might be ways but this warrants a bigger reply (which I hope I can write or discuss on PAT calls).
Bahmni team’s move to React (and Carbon components) has been going strong, and we have been ensuring that almost every new functionality is written in React. The CURE Team (working on IPD features) for instance is doing all the new frontend development in React, including migrating Patient Dashboard widgets, so that React Widgets run along side Angular widgets in the same Angular parent page.
Lab Lite Module, New Forms Display Control, Drug Chart, Patient Portal, New Doc Upload Module, etc are all being written in React. You can attend our weekly PAT calls, to see demos of the new functionality.
