Common UI modules across implementations (e.g. AMPATH)

Continuing the discussion from Instructions for a Bahmni dev environment, targeted at OpenMRS devs:

First, about this:

Every word of this is true, but…

I would challenge you to think about whether organizationally you truly want to be owning, building, and maintaining a completely custom user interface and application that is specific only to AMPATH. The trend in the US is that groups who have historically built their own custom in-house systems are abandoning these and moving toward Epic, etc. My casual impression is that you are taking the wrong approach here.

Anyway, to actually answer your question…

Yes, definitely there are lots of things that would nice to have in common across different JS-based front-end codebases.

As you know, Bahmni generally already has solutions for many of these things, and the team is not proactively prioritizing trying to pull these components out. I’m definitely interested in trying to make sure we do find reusable components where we can, but I’m not sure that there’s a “typical” way to do this. Perhaps as you are planning out the AMPATH work, you can bring up specific things that you’re intending to implement, and we can look to see (a) how these are done in Bahmni (or anywhere else!), and (b) whether it’s done in a way that we can extract a common pattern from.

1 Like

Darius, you bring up an interesting point. I’m not familiar enough about Epic’s business model but my understanding is that they sell a base model and that charge implementers a fee for customization. This is just to say that most (if not all) implementations will be organization specific.

In terms of the direction I’d like to go, the beauty to me behind using an angular front end is the relative ease in which you can introduce new “apps” to work on top of openmrs. Openmrs in this sense is our Epic (not a front end like bahmni). We are just starting this process and it may be the case that our workflows are similiar enough to bahmni’s that we can just user the existing ones. We will do our best not to write code we don’t have to.

There are aspects of front-end developement which are not user facing and are ripe to be shared across implementations. This is where I’m hoping collobaration can go. As we build, we will post questions to this forum to see how bahmni has decided to implement and where we think it makes sense to create a generalized version. Would also be very interested to hear others’ thoughts on this issue prospectively so we can do our best not to make ampath specific modules where it might serve another organization’s needs.

I think you will get more thoughts when you come to the actual details of specific things that you feel are missing in what AMPATH would love to have. :slight_smile: