The Person class has what seems to be duplicative data fields. In addition to the standard creator, changer, and voider information it also collects person-specific versions of those, e.g., personCreator,personDateCreated, personVoidedBy.
There is a comment in the copy constructor for Person which seems to indicate some differentiation between a copy of the Person object (that might be shared by a Patient and User etc.) and an instance of the Person object. My best guess is that this functionality exists to allow the creation of a non-voided Patient from a voided Person using the appropriate constructor.
I was wondering if we need to maintain these fields to support any actual functionality or is it safe to deprecate them?
Personally, I have hated the fact that Patient extends Person, if you can void a patient but the associated Person record remains non voided then this goes against the inheritance principle. We should be using composition instead i.e. Person should be a field on Patient in order for a Patient record to have a different lifecycle from its associated Person record, this would be a non backwards compatible change that would potentially break some existing client code.
Anything that helps us evolve away from assuming a 1:1 relationship between patient & person sounds good to me. In other words, we should take advantage of any chance to refactor existing code that assumes a 1:1 extension of patient to person.
While it’s fine to have a single patient registration per person, it’s far more flexible to consider a “patient” as representing a person within a medical chart, where a person might have more than one chart by accident (duplicate records) or on purpose (multi-tenancy).