Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Reverted from v. 9
Warning
titleArchived Page

This page has been archived. The information on this page may not be up-to-date or maintained.

Person Attribute vs. Observation

...

Archived Page
Info
titleComments from Roger Friedman
Warning
title

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.