"Concepts" are at the core of the OpenMRS platform, and being able to configure the system's clinical content via user-controlled metadata makes OpenMRS very powerful. That is the key to making large parts of the system configurable by non-programmers.
It is (deceptively) easy to create new concepts, and this allows implementations to get up an running fast, but the long-run management and maintenance of a concept dictionary is much harder, in ways that are not evident as you get started. It's easy to create a concept that will look correct on one form, but harder to think about how to model it for reuse on multiple forms. It's easy to skip the work of mapping a concept to other standard terminologies, but this is a required step if you're going to use those concepts for decision support, or be able to exchange data with external systems and HIEs. (An implementation should know that Systolic Blood Pressure is 271649006 in SNOMED CT, and 53665-6 in LOINC, but they shouldn't have to spend their own time figuring this out.)
In the long run, maintaining a high-quality dictionary requires a significant time investment, and most implementations find this hard to justify on their own. The CIEL concept dictionary takes a great first step towards being a shared, curated concept dictionary for the OpenMRS community. However it's currently difficult to use the CIEL dictionary if you also need to define your own local concepts (which many implementations do).
Open Concept Lab (https://openconceptlab.org) is the tool that we want to use in the OpenMRS community to mix-and-match shared, curated concepts (e.g. from the CIEL dictionary) with locally-defined concepts.
The goal of this project is to make UI enhancements to OCL to make it easier for OpenMRS implementations to use it to create and share content.
- Some familiarity with Python/Django (you can learn this!)
- Add a "Fork This Concept" feature (similarly to the way that forking works in github) for when an implementation wants to make local edits to someone else's concept. The forked concept should maintain a pointer to the version of the concept it was forked from, so that the implementation can later see any changes made to the original concept.
- Add a graphical "Diff Viewer". OCL stores full JSON representations of all historical concept versions, but there's no easy way for a user to see what the differences are. We need to add a view that displays (per-field) changes across concept versions.
- Add a "Relationship Browser" view in OCL, so that when you are looking at a concept, you can see immediately-related concepts in an intuitive way, and quickly browse to them.
For example something like this:
- Diff Viewer should allow you to compare _different_ concepts to each other
- Add a "Fork This Collection" feature, e.g. so an implementation could take a form of "OpenMRS Condition List starter set" and make some local modifications.
- Bigger picture on how we hope to use OCL in the broader OpenMRS ecosystem: