Wiki Spaces
Documentation
Projects
Resources
Get Help from Others
Q&A: Ask OpenMRS
Discussion: OpenMRS Talk
Real-Time: IRC Chat | Slack
Primary mentor |
|
Backup mentor |
|
Assigned to |
In the OpenMRS Data Model, the person
table has attributes like gender & birthdate and – through links to other tables – names & addresses. These are attributes (or properties in Java) that are built directly into OpenMRS and, thereby, shared across all implementations. As OpenMRS has been implemented through countries across the world, we've discovered multiple attributes that are needed to meet local needs. For example, in Tanzania, they wanted to record a "ten cell" for each person, which refers to a group of 10 homes. To accommodate these implementation-specific (local) needs, Daniel Kayiwa suggested that we allow for local extensions of the person table. We did this by introducing the person_attribute
and person_attribute_type
tables, where the attribute definitions are stored in person_attribute_type
and the actual values for each person are stored in person_attribute
. To date, we have supported some fairly simple attribute types and have had limited capability for supporting more complex attribute types. We are also interested in expanding the "attribute" pattern for local extension of other tables in the data model.
Recent work has added visit attributes to the OpenMRS data model (
). This project will take on the task of , to bring person attribute in line with this more generic approach to attributes.OpenMRS currently supports a limited number of possible data types for Person Attribute Types – e.g. String and Integer. The purpose of this project is to extend the number of attribute types that are supported and, in the process, make the system more flexible.* Create an abstract design that can be expanded to cover additional "attribute" table extensions (e.g., visit_attribute).
person_attribute_type.format
with person_attribute_type.handler
, which specifies an AttributeTypeHandler
. The AttributeTypeHandler
interface would provide methods to define support for the features specified above (i.e., input mask, choices, validation, single vs. multiple, unique vs. duplicates allowed).AttributeTypeHandler
for basic data types: String, Date, Number, etc.PersonAttributeTypeHandler
as an extension of the AttributeTypeHandler
interface specifically for persons. We can do the same thing with VisitAttributeTypeHandler
for visit-specific attribute types for TRUNK-2131. In contrast, AttributeTypeHandler
implementations could be used for both person and visit table extensions.
4 Comments
Darius Jazayeri
Note that active development is happening around a generic framework for attributes and datatypes. Please follow the work happening around Visit Attributes, and work from this.
Nyoman Ribeka
I didn't follow the development on attribute and datatypes, Darius. Will watch them from now on I guess :) Thanks.
Nyoman Ribeka
See TRUNK-2134
Roger Friedman
Moved to Custom Datatypes Proposal 1