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

[darius (Darius Jazayeri)]

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

@jdick

Bahmni team (and others), I’ll be helping to lead a team of developers at AMPATH (Eldoret, Kenya) in building a point-of-care system to serve our rural sites. Much of the user-interface and workflows will be specific to our specific health care delivery system. However, I’m certain that there are core modules (e.g. authentication, Openmrs REST WS result representations, form entry) which are likely to be useful across implementations.

If there is interest within the community, I think it would be useful to create a strategy which identifies features/functions (likely to be shareable across implementations) and creates generic conventions i.e. not naming modules ampath-formentry) which supports these core modules.

Please let me know if there’s interest and ideas for moving forward.

First, about this:

@jdick

More philosophically, I think it’s unlikely, especially in larger implementations (AMPATH has 100’s of sites and relatively organization specific work-flows), that a common user interface meet organizational needs without significant customization. It’d be a difficult battle to convince an organization to modify it’s workflows to match those recommended by an EMR. It may seem that things are generic but undoubtably, there will be customization required.

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.

[jdick (Jonathan Dick)]

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.

[dkayiwa (Daniel Kayiwa)]

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.