Concept Dictionary Contribution?


My name is Abby and my fellow student Tim Anderson and I were hoping to make a contribution to the concept dictionary. We were hoping to go through it and organize it better and get rid of some duplicates as well as perhaps put it all into a database with a UI for searching and adding new concept to it. This idea, however, was before we did research on how the platform itself accesses the concept dictionary data when filling out forms.

We were still hoping to make some sort of technical contribution to the concept dictionary. Is there anything you all have in mind for us to do?

Thanks, Abby (and Tim)

Always looking for more help on the concept front. I am the vocabulary and metadata lead for the OpenMRS community. Are you familiar with the CIEL references on the wiki? Also and Where are you based? Would you like to set up a skype conversation. Also note that @judy has been doing a lot of this clean up work with me too.

Tim and I are students at a college in Pennsylvania. Unfortunately we aren’t familiar with any of the things you mentioned, but we will look into them when we have a change (we are currently in exam week). Our winter break is immediately following this, so we may be able to set up a skype conversation if you think that will be productive and helpful!

@ash082342 and @andersont we would love to have your help on this!

The best way to proceed depends on whether you mean to do some development work or not.

If you want to write some code, and you have any experience with Python/Django, the most valuable thing for OpenMRS would be to make some improvements to Open Concept Lab tool.

Otherwise, @akanter can point you in the right direction.

PS- About Open Concept Lab, the forward-looking way that OpenMRS is hoping to improve concept management is by letting people use to mix and match their own custom concepts with well-curated ones from the CIEL dictionary. I wrote (a lot) about this in this post and this post (the idea is identical if you substitute “OpenMRS” for “Bahmni”, which is the specific distribution I work on in my day job). But we’re not ready to move people to this new workflow yet, because OCL still needs some specific improvements.

We would love to do some development work and would love to make some improvements to the Open Concept Lab tool, though we have limited experience with Python and don’t know much Django. With winter break fast approaching, though, we can definitely get to learning those to the best of our ability.

We will definitely have a look at the posts you mentioned and get more familiar with the things we need.

Please let us know if there are specific things you would like us to look into other than what you have already mentioned.

I think there are a lot of small UI improvements to be made to OCL that should be low-hanging fruit, and conducive to learning some python/django as you do them.

As a first one, we should improve the display for “question-and-answer” or “set membership” concepts (and other related concepts). Jon Payne and I can flesh that requirement out further, and we can come up with more things to do as well. Just let us know your timeline.

As of right now, Tim and I don’t have a strict timeline. We are on winter break from now until about the last week in january, and would like to take that time to familiarize ourselves with python, Django, and the other tools you mentioned so we can more effectively make improvements and such. Is that alright, or would you like to make any adjustments to that idea?

My recommendation would be that you don’t “go off and learn python/django, and then start to work on this” but instead you start to poke around the OCL codebase at the same time, and do a small ticket or two as a learning exercise.

A couple of us interested users of OCL just had a call today to prioritize some low-hanging fruit UI improvements, and we’ll be getting these written up as tickets soon.

(Also, I suggest you try to set up a dev environment for OCL sooner rather than later so that if the existing instructions turn out to be incorrect, we can get those updated for you before you start to work in earnest.)

PS- I’m very excited that someone is able to contribute some fixes to OCL, because there’s a backlog of little things that would improve its usability a lot for us, and there just hasn’t been anyone available to look at it!

Hi @ash082342 and @andersont, happy new year! I’m checking in to see how things are going, and if you’re ready to start working on Open Concept Lab.

Right before breaking for the holidays, @paynejd, @ball, and I worked on a list of improvements to make to OCL, which we prioritized and labeled as “good for students” vs not. (“Not for students” in this context means we expect it to involve a bunch of slow-moving design discussions.)

We wrote down our thoughts in this google doc:

If you are ready to start picking things up, then Ellen, Jon, and I will prioritize moving things from this doc into actual github issues that can be picked up and worked on.

Let us know!

Happy new year!

@ash082342 and I are back from break and are ready to work on stuff that you see fit.

Welcome back.

I suggest getting started by picking up the first issue that’s in the OCL UI Tweaks google doc I linked above.

Basically the idea is that when you do a search, you see some results, and also there are checkboxes on the left side to further filter. But after checking those boxes, you have to go press a button to trigger the search again. Instead, we’d like the search to be auto-triggered when you toggle any of the checkboxes.

(If you want, once you’ve had a chance to check out the code and poke around, we can touch base on a call and talk about this and other improvements.)

@paynejd, which github repo should we create this as an issue in?

Hi all, we have been creating all tickets in the oclapi repository. Thank you for your support on this!

Cheers, Jon


We have been keeping an eye on the oclapi issue tracker and could not find one for the auto-search (or most of the issues in the Google doc). Should we begin working on things straight from the doc or wait until a ticket is made?

Sorry for the delay in that. I will create the first couple of those tickets now.

But yes, you can begin working on things straight from the doc, and ask any questions here.

I created two github issues for now:

We can create more after Jon/Ellen/me touch base next.

Sounds good. Thank you. We should be working on them more frequently now since we have more time.

We have been having lots of trouble with docker (using the instructions on the readme on GitHub) and specifically docker-compose up command. We are getting the following error:

“ERROR: Version in”./docker-compose.yml" is unsupported. You might be seeing this error because you’re using the wrong Compose file version. Either specify a version of “2” (or “2.0”) and place your service definitions under the ‘services’ key or omit the ‘version’ key and place your service definitions a the root of the file to use version 1" For more on the Compose file format versions, see

Any help is greatly appreciated!

Where are you running this command from?

I just ran docker-compose up from /oclapi/django-nonrel/ocl in a just-updated checkout, and it worked for me.

I am running Docker version 1.13.1, build 092cba3.

Are you doing something different?

We fixed that error and are working on more. Docker is still giving us a lot of trouble. Hopefully we will have it set up tonight.

We are having issues with named volumes when running docker-compose up. We also have docker version 1.13.1, API version 1.26, Go version go1.7.5, Git commit 092cba3, OS/Arch linux/amd64…

The original error we got we may have fixed by changing the docker-compose.yml to be version 2.1 and by changing every instance of $ to $$. This led us to the named volumes error.