| Note |
|---|
This page is outdated and no longer receives updates! |
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
| Info |
|---|
Comments from Roger FriedmanWe 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. |