...
When the person table was initially introduced into OpenMRS, all implementations were constrained to use the same attributes. Then, a bright young Ugandan (Daniel Kayiwa) suggested that we introduce the same flexibility of an entity-attribute-value (EAV) approach into the person table as we had done with our observations in the obs table. This approach allows implementations to virtually extend the person table to meet local needs. For example, in Tanzania, they wanted to track "ten cells", which are a type of addressing used in Tanzania. To accomplish this flexibility, we added a person_attribute table to contain implementation-specific data about persons and a person_attribute_type table to define the new "attributes" (virtual columns) for the person table. Using this mechanism, an implementation in Tanzania could define a new person attribute for "ten cell" and use it to store data for each person in their system without having to alter the core data model. Person attributes have been widely used & appreciated, since they allow OpenMRS to meet local needs through local extensions to the data model while allowing many implementations to continue sharing the core platform.
...
One of the benefits of migrating complex observations to a more generic "custom datatype" approach is that it allows OpenMRS to accommodate a larger set of datatypes for clinical data, which opens the door for OpenMRS to find common ground with OpenEHR archetypes.
...
Global properties
...
Settings (formerly Global Properties from 1.8 downwards)
Internal settings and module configuration data are persisted within the database as "global propertiessettings (formerly Global Properties from 1.8 downwards)." To date, these properties have been stored as strings, leaving it up to the modules and services that store & retrieve the values to convert non-string values into string representations. We have wanted a way to define various datatypes for global properties settings (formerly Global Properties from 1.8 downwards)– e.g., dates, numeric values, lists, etc. – and standardize the approach of defining the property's datatype, the UI widget used to manipulate the datatype, validation, etc. Eventually, we'd like not only to have standard datatypes for global propertiessettings (formerly Global Properties from 1.8 downwards), but also allow modules to add new custom datatypes.
...