Page Comparison

Background

OpenMRS uses a central concept dictionary to define much of the clinical data that are stored. Instead of having a "pulse" attribute hardcoded into a database table, the idea of "pulse" is entered into the concept dictionary and, when a patient's pulse is recorded, an entry is added to the observation table referencing the "pulse" concept within the dictionary. Concepts in the dictionary are categorized (or classified) using Concept Classes.  Some of the pre-defined concepts classes include "Test", "Procedure", "Drug", "Diagnosis", "Question", "Anatomy", etc. This list was a rather arbitrary classification scheme created to place concepts into high level "buckets" based on how there going to be used within the system. We've gotten very far using a relatively small number of concept classes and the constraint of each concept being assigned to a single concept class; however, as the number of implementations & distributions of OpenMRS grows, the constraints of concept classes are beginning to cause problems.

Purpose

The goal of this project is to provide more flexibility in classifying concepts by allowing concepts to be assigned to more than one class, while providing backwards compatibility so the large body of existing code does not break in the process.

Required Skills

• Strong Java skills
• Familiarity with the OpenMRS API
• An basic understanding of how Concepts are modeled within OpenMRS

Objectives

• Add the ability to assign concepts to more than one concept class within the API in a way that is backwards-compatible (available through new methods, maintain a "primary" class assignment for each concept to be used in cases where only one class is supported): 

  Jira Legacy
  TRUNK-4540 TRUNK-4540

• Adapt the REST API to support multiple classes per concept
• Adapt the most widely used concept tools to allow for more than one concept class per concept (e.g., concept management tools)

Resources

• Jira Legacy
  TRUNK-4540 TRUNK-4540