FHIM::Person::Person Diagram Person The properties that humans and animals (may) have in common are modeled in an abstract class called "Biological Entity." This class would never be instantiated on its own, but rather Person or Animal would be instantiated, and each would have the common properties of birthdate, age, etc. Therefore, when mapping person information to the FHIM, one would create an entry for Person.dateOfBirth, not BiologicalEntity.dateOfBirth. In object-oriented software, subtypes (also known as subclasses), automatically access the properties of their supertypes (aka superclasses) directly. So in Java, a person's date of birth would be represented as Person.dateOfBirth. Conversely, a superclass can be "downcasted" to a subclass if the writer of software doesn't know in advance which subtype will be acted upon at runtime. This is evident in the Patient hierarchy, where a lab test refers to a Patient, and the patient might be either a person or an animal. Notice that both the Person and the Amimal are accessed from HumanPatient and AnimalPatient by an association with the end-name of "subject". Thus, the person or animal can be accessed by Patient.subject. However, information specific to one or the other can only be retrieved if the proper one is instantiated. For example, patient.subject.maritalStatus will fail if the subject is an animal; similarly patient.subject.organismTaxon will fail if the subject is a person.Some properties, such as BiologicalEntity.age may be calculated based on other fields. These properties technically do not need to be in the model, as they can be calculated on the fly, however, the logical concept of age is often needed. Therefore, these properties are modeled, but marked as "derived", which is indicated in UML by a slash character in front of the property name. This is particularly evident in the birth certificate package, where much of the information about the newborn's parents could be calculated from their Person records. This technique is not used often in other parts of the FHIM.The ContactParty class is used for both persons to contact under given situations. The circumstances under which a person is acting as a point of contact for the patient is identified in the contactCategory property.A separate class, PersonalRelationship, is used to indicate how two persons are related to each other. Because a contact parties are often relatives, the same two Person records may have relationships via ContactParty and PersonalRelationship.Information about a Person’s role as a Student is often needed, especially for children, as schools often maintain immunization records for their students, and may provide vaccinations. The purpose of the Student class is to identify Student information about a Person at particular points in time; it is not intended that a Person’s entire academic experience be constructed by aggregation of individual Student records. Other constructs to do this are modeled in the Provider package, where academic history is needed for credentialing purposes.Similarly, information concerning a Person’s employment is modeled in this package for occupational health purposes, and should not be relied upon to provide a complete picture of a person’s employment history.It is important to note that the Patient Role class defines concepts related to an entity (a Person or an Animal) as they are acting in the role of a Patient. One subtlety easily overlooked is that a Person will have multiple Patient role instances, as determined by the Healthcare Provider. One way to think of it is that the Patient role represents a medical record as assigned by the healthcare provider. One Person may be patient A at Dr. Smith’s office, and patient Z at Dr. Jones’ office. Hospitals often assign separate patient IDs for each admission, so the same person at the same hospital may have multiple Patient “records”. This is why the Patient class has an association with the HealthcareProvider class, which, in HL7-speak, “scopes” the Patient instance. There is a subtle difference between a Patient Role and the associated HealthRecord for the Patient, as the HealthRecord is a controlled set of records about the Patient. The HealthRecord represents that information which may be the subject of Privacy-related or Consent-related Directives initiated or authorized by the Patient.
