...
Internal settings and module configuration data are persisted within the database as "global properties." 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 – 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 properties, but also allow modules to add new custom datatypes.
...
Visit Attributes, Location Attributes, Provider Attributes
...
For OpenMRS 1.9, we decided to add the same extensibility for the visit table as we had for the person table, since the metadata needed about patient visits can vary greatly from one implementation to another. Given our positive experience with person attributes, we planned to introduce visit attributes from the very start along with the visit table. However, having learned a bit from the use of person attributes, Darius designed visit attributes to be a bit more flexible, introducing an abstracted "handler" interface instead of relying solely on regular expression formatting. Due to this generalized design, we were able to add attributes to the location and provider objects with little extra effort.
Requirements for Custom Datatypes
...