...
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.
...
Most of these are more properly handled in some other way. Some do change, but have a legitimate claim to be person attributes (ie. civil status and current school). In those cases it depends on the rationale for collecting these things. If you're collecting them for epidemiological/research purposes, they should probably be observations recorded at an intake encounter. If you really want to store the marital history of a patient, or the school someone went to, for an administrative purpose, you might actually need start/end validity dates on person attributes. If it is to be used for administrative purposes, it may be more appropriate as a program enrollment.
Recommended Best Practices
...