Person Attribute vs. Observation

While observations and person attributes both collect data on a patient, there are key differences in how they are intended to be used.

Person Attributes

• Person attributes are intended to provide local implementation sites the bandwidth to collect custom attributes that are needed in order to meet local needs.
• As such, person attributes can be thought of as a local extension of the person table, meant to accommodate implementation-specific needs.
  • For example, in Tanzania, an implementation wanted to record a "ten cell" for each person, which refers to a group of 10 homes. A local person_attribute_type was created to store this information.
• Of note is the fact that person attributes are only designed to collect the most recent information for any person_attribute_type.
  • With the OpenMRS data model, when a person_attribute_type is updated with new information, the previously entered value will no longer be available in the database.
  • For example: An implementation has a person attribute for "patient's favorite color". The patient was seen in 2010, and answered that her favorite color is "green". In 2011, the patient returned to the clinic. She updated her information to indicate that her favorite color is "purple". In this case, the database would no longer have any indication of the initial response of "green". The only response that will appear for this person_attribute_type will be "purple".
  • While the data model is evolving to be able to store more than one value for a person_attribute_type, these multiple values will be intended to represent current information regarding the patient rather than historical information.

Observations

• An observation is anything actively measured or observed during an encounter.
• All observations are stored in the obs table. Unless deleted, any observation ever stored for a patient will remain available in the database. As such, observations are able to store historical data on patients.
  • For example: An implementation has a concept to collect "patient's favorite color". The patient was seen in 2010, and answered that her favorite color is "green". In 2011, the patient returned to the clinic. This time, she reported that her favorite color is "purple". When searching the database for the patient's response to the question of her favorite color, you would find one observation with a response of "green" and another observation with a response of "purple".

An Example

While it is not built into the OpenMRS person_address table, many implementations would like to collect phone contact information for patients. This seems to provide a good opportunity to leverage the person_attribute table, as phone numbers can be used as a way to identify patient. This can be tricky, though, given that person attributes do not store historical information.

Consider the following example: A patient comes to the clinic, and reports their contact phone number. The phone number that was reported is actually the phone number of the patient's mother, whose phone she is currently using. By the next time the patient visits the clinic, she has gotten a phone of her own and has reported that contact phone number. However, several weeks later, the patient forgets to pay her phone bill and no longer has her own phone number.

• If a person attribute was used to collect this information, the only number that would be retrievable is the now defunct contact number provided when the patient got her own phone. It might have been useful to also have access to the patient's mother's phone number, but this information is no longer available in the database.
• If an observation was used to collect this information, both of the phone numbers would be retrievable from the database, in separate observations.

It is important to consider situations such as this when deciding whether or not to collect a data point as a person attribute or as an observation.

While observations and person attributes both collect data on a patient, there are key differences in how they are intended to be used.