Page Comparison

Person Attribute vs. Observation

...

These are examples which have been recorded as patient attributes:

• Birthplace -> never changes

• Citizenship -> rarely changes, but should allow multiple values on rare occasions

• Civil status -> changes

• Assigned health center -> program enrollment location

• District of assigned health center -> calculated off the program enrollment location

• Mother's name -> never changes

• Telephone number -> changes; handled by PatientContact entry (OpenMRS 1.9+)

• Telephone type -> changes; handled by PatientContact entry (OpenMRS 1.9+)

• Treatment supporter -> changes; handled by Relationship

• Current school -> changes

Some of these attributes are fixed and will never change - i.e. birthplace and mother's name. The rest of them could potentially change over time, in which case we would want to be able to represent that history. "Voiding" is not a proper solution for this, as we do not want to invalidate the historical data. We want to mark it as something that was true in the past, but is not true in the present.

...

Recommended Best Practices

• If a data point is fixed and will never change for all intents and purposes (eg. birthplace) use a PersonAttribute (or VisitAttribute, etc)

• If a data point is not fixed, and may change over time but you might not know the dates of starting and stopping, use an Observation

• If a data point is not fixed, and you want to capture the exact start and end dates:

  • Use a Relationship, if possible

  • Use a PersonContact, if possible

  • Use a PatientProgram, if possible

  • Use an ObsGroup otherwise

Comments

We have similar issues in the HR Module: We want to keep a job history as well as knowing the person's current job. We maintain begin and end dates, and at most one job per employee has a null end date. However, there remains the issue, as yet not resolved, of distinguishing between "edits" (to correct errors) and "changes" (to indicate a job change). The choice seems to be between not having edits, which means voiding and replacing erroneous records; and requiring the user to distinguish consistently between edits and changes.

While putting this capability into the Person Attribute table is no different than having a "preferred" name or address, probably a small percentage of patients have more than one name or address, while potentially many person attributes could have multiple records. Perhaps the best solution performance-wise would be to capture new/changed Person Attribute records as they are written and put them in a separate table. This would be easy and invisible if you can live with creation/modification dates. You could use the separate table to do longitudinal reports by, say, civil status. Also you could implement it by AOP and not have to monkey with the trunk. That's not the case for HR, which is interested in effective dates of personnel actions.