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 demographic information necessary to support the medical, financial and logistic procedures but should 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 'scoping' resource. This group of attributes might include a resource reference to the scoper in the original Role. As such, the analysis "stereotype" of a role is still relevant, although its representation in the Fhir model might differ from case to case.

When "converting" such a role to nested elements within a Resource, a few general principles apply:

• Many roles have multiple id's, a specific role code, multiple adresses, a status and effectiveTime. I believe these attributes are present in the DMIMs (and RMIMs) to not block the possibility of being used in specific usecases while modeling 'by constraint'. Because of Fhir's support for usecase-specific extensions, it is not necessary to introduce them in the core resources and many of these do not get converted.
• Generally, the role's attributes will be nested within the resource representing the original 'scoping' Entity of the role. If the role also has a 'player', this can be done using a resource reference, but there will be many cases where the playing entity is not present as an actual resource instance. In this case, the group of attributes representing the role should both include a resource reference and additional elements from the playing entity.

Person properties

Based on the referenced source materials, these attributes emerge as 'core'

• identifiers (Person.id)
• names (Person.name)
• addresses (Person.addr)
• contacts (Person.telecom)
• dob (Person.birthTime)
• deceasedDate (Person.deceasedTime)
• gender (Person.administrativeGender)
• maritalStatus (Person.maritalStatusCode)
• birthOrder (Person.multipleBirthOrderNumber)

Note that birthTime and deceasedTime have been renamed to use 'date', since that it what most people seem to use in common speach. 'gender' is still the administrative gender, but this is reflected in its description rather than its name. 'telecom' has been renamed to 'contacts' to reflect the fact that the modalities of (electronic) contact have been expanded to include email, Skype, etcetera. 'telecom', although still appropriate, is too much associated with 'telephone' and 'fax'. The suffixes 'Code' and 'Number' are dropped from the names of the elements.

proposed extensions

• disability, CodeableConcept (Person.disabilityCode)
• livingArrangement, CodeableConcept (Person.livingArrangementCode)
• religion, CodeableConcept (Person.religiousAffiliationCode)
• race (Person.raceCode)
• disability, CodeableConcept (Person.disabilityCode)
• nationality (0..1) CodeableConcept (Person.asCitizen)
• organDonor, 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?