Improved Person Attribute Types

Owned by Nyoman Ribeka
Last updated: Sept 26, 2011 by Roger FriedmanVersion comment
3 min read

Primary mentor

Nyoman Ribeka

Backup mentor

Wyclif Luyima

Assigned to

Former user (Deleted)


Background

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 (

Error rendering macro 'jira' : Unable to locate Jira server for this macro. It may be due to Application Link configuration.
).  This project will take on the task of Unable to locate Jira server for this macro. It may be due to Application Link configuration. , to bring person attribute in line with this more generic approach to attributes.

Purpose

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).

  • Refactor person attributes to align with the new design for attributes that Darius Jazayeri introduced for visit attributes
  • Create a handful of basic attribute datatypes.
  • Support extension of basic attribute types to further constrain them.
  • Support additional (e.g., through modules) of completely new attribute types – i.e., that may not extend a basic attribute type.
  • For each type, support settings like:
    • Input mask – e.g., constraining input with regular expression(s)
    • Provide a choice list of possible options
    • Validation
    • Single value vs. multiple value (via repeated entries of the same
    • Constraining to unique values vs. duplicates allowedFor example, for a telephone number, OpenMRS should be able to validate the phone number entries, making sure the phone number is in correct format. Another example is citizenship. Instead of giving a totally free text, it would be more convenience to give the user a list of predefined possible String values.

Required Skills

  •  Knowledge of the Java programming language

Desired Skills

  • J2EE knowledge
  • Spring and hibernate knowledge

Objectives

  • Create new datatypes for the Person Attribute Type
  • Update the API layer to have methods for working with the new datatypes
  • Add unit tests for the new methods added to the API.
  • Update the relevant documentation pages

Design Ideas

  • Replace 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).
  • Create implementations for AttributeTypeHandler for basic data types: String, Date, Number, etc.
  • Define 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.

Extra Credit

  • RCM-15: Include Patient Attributes when doing a data export
  • RCM-33: Cohort Builder - Search by Person Attributes
  • TRUNK-322: Person Attributes should show up on dashboard overview page
  • TRUNK-1793: Add startDate and stopDate to person attributes

Resources