Technical wiki page documentation about attributes

Hello everyone!

I am trying to create a documentation about attibutes in OpenMRS, in fulfillment of the issue at, but have limited information about what is really needed.

However, here is what i have done meanwhile. i request you guys to give comment as u throw more light into my technical eyes.

cc @darius @dkayiwa @herbert24 @mozzy @dev5 @dev4 @dev3 @dev2 @dev1

Thanks for working on this, My advice would be, you will need to add some examples of what an attribute is, Take forexample some-one technical and would love to get acquitted or implementing an attribute in a given class.Forexample

Class Attributes

“variable” for x in the example (as shown below). It is actually an attribute of the class. Or you could say that class attributes are variables within a class:

public class MyClass {
  int x = 5;
  int y = 3;
1 Like

This is just some hint, but you could use openmrs code context.Would also like to hear from different ideas otherwise well done @jnsereko

1 Like

Thanks so much @sharif


While term “attributes” is used to refer to variables exposed in a Java class and the columns in a database table, I believe TRUNK-2939 is referring to the “attributes” tables in the OpenMRS data model. Using the data model browser, you can see these tables as an example (that reminds me, now that Ref App 2.10 is released, I need to add it to the browser).

In brief, we have created some tables and corresponding Java classes in OpenMRS where we add “_attribute” to a domain object. The purpose is to allow local extensions to the data model without having to modify the shared (core) data model. It started when @dkayiwa noticed the extensibility of the EAV pattern in our obs table along with several requests from implementations for implementation specific adjustments to the data model (e.g., Tanzania wanted to record the “ten cell” for each person – a convention specific to that region for identifying clusters of homes). He thought, could we apply the extensibility of obs to our person object. So, we created a person_attribute table along with an person_attribute_type table to define custom “attributes” of person that would be an alternative to adding a new column to the person table (since not everyone wants or needs a “ten cell” attribute for person).

This approach of adding an x_attribute table has been repeated for several other domain objects for the same purpose.

So, core OpenMRS knows that attributes exist and can use them (based on their attribute type definition), but core code should never refer to a specific OpenMRS attribute, since any attribute of a table needed by core should instead be added to the core data model directly.

This allows implementations to extend the model where needed and, when we see broad use of the same OpenMRS attributes, we can introduce them directly into the core model. This approach and a desire to align with HL7 FHIR are major drivers behind core data model decisions.


@burke Thanks for highlighting and brodenning it very well. The explanation has solved the issue of attribute documentation to me.

Thanks for the explanation @burke! It is really satisfying. I am going to reedit the documentation i hard created.

Thanks for the help @sharif @burke.

May you please take a look at i am willing to alter if anything is missing.

1 Like

For inter-wiki links (links to other OpenMRS wiki pages), I would recommend using the built in linking (I think you can trigger it by typing an open square bracket [). You did this for one of your references, but not another. Making direct links to other wiki pages (instead of using external links to…) allows the wiki to properly track the relationships between wiki pages.

1 Like

I think i have put into practice the advice you gave to me @burke. If nothing is missing, i think this is all that was required. Check the page out at

Thank for the support @burke @sharif :clap: :clap: :clap: