OpenMRS Tech Radar, Q4 2016

Inspired by the ThoughtWorks Technology Radar, and by Mike’s suggestion to do our own, a group of us put together the OpenMRS Technology Radar for Q4 2016.

Check it out at and share your thoughts!


What is the OpenMRS Technology Radar?

Our Tech Radar is an opinionated recommendation from some OpenMRSers who have been involved in many projects over the years, about what technologies you should be using, or avoiding, when building your OpenMRS implementations and distributions.

What is the structure?

The metaphor is a “radar” showing information about technologies, and how close they are to being recommended for adoption. (We took inspiration from the thinking behind ThoughtWorks’s radar.)

We organized the technologies we discussed into four quadrants:

  • Languages & Frameworks
  • Modules & Distributions
  • Standards & Conventions
  • Platforms & Integrations

Then we made a recommendation about each technology:

  1. Adopt … projects really should use these technologies (in the appropriate contexts, of course)
  2. Trial … projects should pilot/trial these technologies, and make an informed decision about whether they are the right fit
  3. Assess … projects should investigate these technologies, and track their progress, but they are typically not ready for production use
  4. Hold … you should avoid these technologies on new projects, and consider shifting away from them on existing projects, as appropriate.

Who was involved?

@burke, @darius, @dkayiwa, @mseaton, @pascal, @wyclif worked on this (slowly!) over the last 6 months, mostly in OpenMRS Design Forums.

How to get involved?

Did we get something wrong? Did we miss something? Write a comment on this thread!

We are also looking for /dev/3s and above to be part of the team when we do the next version. Send me a private message if you’re interested in joining for the next iteration.


+1 for this, thanks!!

We should bookmark/link/promote this somewhere, as it gives information that might not be obvious by just searching through the OpenMRS wiki (ie, hold on OpenMRS UI Framework).


1 Like

This is nice. Good to see Bahmni chosen to be in adopt.:clap:

1 Like

i agree with @mogoodrich about bookmarking this ( as we try to make finding information easier on the wiki). this is great work. thanks for doing this. I assume that the plan is to update every quarter? if it is, then we can add to the 1/4 update to the community report.

we should also make sure that the OpenMRS Advisory committee is aware of this somehow… nice…

I created a wiki page to replicate my first post in this thread. I wrote a couple of notes about things to remember to do with each release here.

As far as “bookmarking” goes, the radar has a permalink at

As far as promoting, we tweeted (and ThoughtWorks retweeted us). Any more suggestions?

Yes, we plan to update this quarterly. Yes, we can include it in the quarterly report, if you think that’s interesting.

To highlight that particular point, we are saying:

Adopt: HTML+JS+REST Hold: OpenMRS UI Framework Hold: Spring MVC and JSP

We are also saying:

Adopt: AngularJS 1.x Assess: Other new JS frameworks

Read about our reasoning on the radar at, and give your feedback here!

In particular, this should be highlighted on the standard path that a newbie developer (and implementer for that matter) is likely to take when first coming to OpenMRS:

Actually, doing a quick search, if I go to “” -> “Introduction to OpenMRS” -> “Technical Overview” I get a page that, nevermind the UI Framework, basically says we use Spring MVC for our web layer. (Though there is at least a note saying that DWR is being replaced by REST Web Services).

On that note, I don’t see a reference to the (extremely helpful) OpenMRS SDK on these pages either.

Maybe “Rewriting OpenMRS developers guide/technical reference” could be something tackled as part of the OMRS16 Hackathon?


Thanks Darius, this is very interesting and insightful!

I would be keen to correlate this with implementation experience or at least draw some parallels based on distros implemented over the years that have been constructed with combinations of elements from the technology stack - then relate with this tech radar.


i agree about the need to rewrite the developers guide/technical reference.I like the idea of having that at the Hackathon or making a commitment to do that in the new future.

I also am intrigued by the implementation experience guiding the tech radar. Since we are a health informatics initiative, i played with the idea of looking / knowing the clinical functionality ’ need’ that somehow sits within the tech radar evaluation .

Adopt … - what functionality is essential to deliver ( graphing) Trial …what functionality might assist in improving care quality/safety/ ( pop health at the POC and not generated in a DW) Assess … what project/ clinical care should be investigated technologically, and track their progress, but they are typically not ready for production use ( VR; in our case, maybe GIS) Hold … you should avoid these technologies on new projects, and consider shifting away from them on existing projects, as appropriate. ( non API based functionality)

it might be hard to do this, but it would help ensure that the tech decisions are ones that can support the clinical functionality that implementations need

@wanyee, I hope this is correlated with implementation experience, as some of the main contributors have been / are implementers. What do you think the output might look like of what you’re suggesting?

@terry, I like the idea you’re proposing, but I like it more for a separate output/effort, as opposed to trying to dual-purpose this tech radar. We tried to answer the question of how to build, assuming that you already know what to build. And it’s pretty dev-focused so that we can give specific answers to questions like “Angular 1.x vs Angular 2.x vs React?”

I would prefer to see what to build answered in the form of a maturity model showing what EHR functionality we would expect to provide the most impact. It could be very interesting to get a small group to start from an existing maturity model aimed at resource-rich settings, and think about what’s relevant to the resource-poor context.

i like what you are saying… we know that there are existing maturity models for the US and i imagine that there are many in other countries ( though many of the US vendors are represented t/o the globe).

There are adoption models and maturity models. HIMSS has recently published an ambulatory adoption model at

i am not endorsing that model, BUT it does start with a paper chart ( one could surmise that OpenMRS Forms straddle stage 0 and stage 1 with some of the higher stage functionality available) . If anyone is interested in looking at ‘what to build’ to meet the functional needs of LMIC, please let us know. I think that this work could be/should be used to help guide the development path.

@burke, I suggest that we add GitBook to our tech radar. Since you’ve actually used it, are you interested in writing the blurb?