FHIR Person

Return to PA Resource Development

Person belongs to the group of attribution resources in Fhir which focus on the "who", "when" and "where" aspects of the information represented by Fhir. As such, its attributes are focused on the information necessary to support the medical and administrative procedures and but will not contain medical or care-related information itself. Person is a basic building block within the attribution layer, so it references other components from this layer (organizations, locations, encounters) but does not refer to higher-level constructs such as procedures or observations.

Analysis of the Person model in v3

The current v3 "Person" holds a whole range of properties that go well beyond just personal identification, like indications of religion, marital status or ethnicity. These attributes (and others) are very much necessary in some context (where registration might even be mandatory) but are of little use in actual international or even national communication due to the fact that these attributes are hard to interpret outside of their original context. It seems fair to move these attributes into extensions so they can be included in profiles where their context and thus their interpretation is clear.

Since most of healthcare is focused around observing aspects of patients (and thus persons), the Person model is especially sensitive to the unwanted inclusion of attributes that are captured for reasons other than patient administration. For example, the current model includes an "Employee" role to express the fact that a person receives wages for working for an organization. This is firmly an "administrative" function. However, this "Employee" role is also used on patients to note facts about their working conditions to support medical assessments. In this latter case the actual employer might be irrelevant, as might be the salary, but both notions are collapsed into one. This might feel natural to people familiar with RIM modelling, but feels foreign to outsiders. I consider the first use to be correct for this attribution layer, whereas the second should be moved and modeled as an Observation done while taking a social or functional patient history.

Not all attributes are relevant in all scenario's: Person can be used in multiple roles: as a patient, as a (care) professional or natural persons related to patients. Depending on these roles, some attributes might or might not be relevant, like disability 'professional' persons. This might suggest moving these attributes to resources representing these roles, but since some of them actually are aspects of the person, this is not normally a natural fit. E.g. 'disability' does not depend on being a patient in one hospital or another, so it makes no sense to move it there.

Handling roles

The PA domain is rich in roles. Fhir does not have a "role" Resource, so the existing roles cannot trivially be mapped to a corresponding Fhir construct. In fact, each role needs to be evaluated and can be expressed by either a resource (representing that role), or as a composite member of a resource. When does it make sense to actually create a resource for a role, in this case the roles around Person?

• The Role should be relevant outside the scope of the Person and there are other resources who might want to refer to the same instance of that role.
• For this to be possible, the role should have a clear notion of identity within the administrative process, so other resources and systems can actually unambiguously refer to it using a natural identifier.
• When the previous statements hold, the Role is probably non-transient and describes a long-lasting situation, and,
• The role is actually connected to the participation of a Person in an act.

If a role is not converted to a proper resource, it will survive as one or more grouped attributes within, generally speaking, the 'playing' resource. This group of attributes might even include an actual resource reference to the original scoper. As such, the analysis "stereotype" of a role is still relevant, although its representation in the model might differ from case to case.

Person properties

• identifiers (Person.id)
• names (Person.name)
• addresses (Person.addr)
• contacts (Person.telecom)
• dob (Person.birthTime)
• gender (Person.administrativeGender)
• nationality (0..1) CodeableConcept (Person.asCitizen)

proposed extensions

• disability, CodeableConcept (Person.disabilityCode)
• livingArrangement, CodeableConcept (Person.livingArrangementCode)
• religion, CodeableConcept (Person.religiousAffiliationCode)
• race (Person.raceCode)
• disability, CodeableConcept (Person.disabilityCode)
• birthOrder, integer (Person.multipleBirthOrderNumber)
• deceasedDate, dateTime (Person.deceasedTime)
• maritalStatus, CodeableConcept (Person.maritalStatusCode)
• isOrganDonor, boolean (Person.organDonorInd)

possible extensions

• ethnicGroup (Person.ethnicGroupCode) - current definition is much geared to specific (us?) usecases.

remarks

• Person.multipleBirthInd - propose to replace by DAR on Patient.birthOrder
• Person.deceasedInd - propose to replace by DAR on Person.deceasedDate
• Person.educationLevelCode - propose to replace by Person.qualifications

Person.Citizenship[1..*], proposed extension

Person.nationality does not cover multi-national or refugee/asylum situations. For these usecases, use Citizenship

• period [1..1], Period
• code, Coding [0..1], qualification of legal status within a nation
• nationality, CodeableConcept [1..1]

Person.Employment[1..*]

• identifier, HumanIdentifier[0..1] (Person.asEmployee.id)
• period (Person.asEmployee.effectiveTime)
• occupationCode

Proposed extensions

• addresses (Person.asEmployee.addresses)
• contacts (Person.asEmployee.telecom)

Possible extensions

• jobClass (Person.asEmployee.jobClassCode)

Remarks

• status - necessary?