Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Patient data is normally stored as an observation in OpenMRS, but there are also could be stored as a person attributes. Person attributes are used to describe something about the person (ie. Where was the person born?) where a as observations is are normally something recorded at a moment in time (ie. What is your weight now?).

If person attributes support having a historical record, they become more sophisticated than the original "virtual column in the person table". For example, you might want to record and keep a history of their marital civil status since this can change over time. Is it better to record "Civil Status" as a PersonAttribute with concept answers OR as an observation with dates? By using an observation, there is recording of snapshots in these are recorded as snapshots over time, and that's probably the real use case. You don't care what day the patient got married, rather you care that when they had encounter data captured, their the civil status was Married.

These are examples which have been recorded as patient attributeattributes:

  • Birthplace -> never changes
  • Citizenship -> changes rarely, but should allow multiple values on rare occasions.
  • Civil Status -> normal for this to changechanges
  • 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 entryentry (OpenMRS 1.9+)
  • Telephone Type -> changes; handled by PatientContact entryentry (OpenMRS 1.9+)
  • Treatment supporter -> relationship to another personchanges; handled by Relationship
  • Current School -> changes

...

If it is more appropriate to use other mechanisms for these (Observations, Patient Programs ( which supports Locations), and Relationships ( which supports start/end dates), we need some best practice practices documentation around this and to get some feedback into the community as to how these use cases would better be modeled. Do others have examples of Person Attributes that would need start date and end date bounds to meet their full needs?

Most of these are more properly handled in some other way. The ones that really may Some do change, but have a legit claim to be person attributes include (ie. civil status and current school). In those cases it really depends why you are depends on the rationale for collecting these things. If you're collecting them for epidemiological/research purposes, they should probably be obs recorded at an intake encounter. If you really want to store the marital history of a patient, or what school someone went to, for some sort of administrative purpose, you might actually need start/end validity dates on person attributes. If it's for administrative purposes, perhaps it's more appropriate as a program enrollment.

...