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 seems to 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. One may also argue that since many of the attributes are only captured for patients and professionals (of relatives and others we mostly just have names and contactdetails), there may well be distinct Resources for 'Patient' and 'CareProvider', but no resource for 'Person'.

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.

I left out Person.multipleBirthInd and Person.deceasedInd because we have been discussing replacing these by a 'dataAbsentReason' on Patient.birthOrder and Person.deceasedDate.

The remaining attributes should be adopted either by HL7 International or affiliates as extensions:

• disability, CodeableConcept (Person.disabilityCode)
• livingArrangement, CodeableConcept (Person.livingArrangementCode)
• religion, CodeableConcept (Person.religiousAffiliationCode)
• race (Person.raceCode)
• ethnicGroup (Person.ethnicGroupCode) - current definition is much geared to specific (us?) usecases.
• nationality (0..1) CodeableConcept (Person.asCitizen) - see Citizen, below
• organDonor, boolean (Person.organDonorInd)
• educationLevel (Person.educationLevelCode) - if used for personnel, I propose this should be replaced by Person.qualifications, if used for patient's backgroud it might be social anamnesis.

Note: before adding elements as extensions to Person, one should verify that the information is still demographic of nature. Some might be considered part of the social or functional medical history of a patient and thus be moved to the medical content of the Fhir model. CCD uses this strategy (all are covered using Observations with and Observation.code from SocialHistoryTypeCode).

Person.Citizen

Citizenship information for a person, including citizen identifier and effective time can be sent in the Citizen class. The nation that scopes the Citizen role, as identified by Nation.code, is mandatory.

Proposal: represent Citizen, a Role in v3, as an extension on Person:

Person.Citizenship[0..*]

• period [0..1], Period (Citizen.effectiveTime)
• code, Coding [0..1] (Citizen.code) - qualification of legal status within a nation
• nation, Coding [1..1] (Citizen.politicalNation.code) - The code is required, there's no separate 'name' attribute other than the display value of the Coding

Person.BirthPlace

The patient's place of birth can be sent in a BirthPlace class. The BirthPlace.addr is a physical address (address use = "PHYS") and could be a full address or only known address components such as city or country. The BirthPlace.addr must be non-null if the E_Place.name is null. The geographic coordinates of the BirthPlace can be conveyed in an A_SpatialCoordinate observation.

The v3 definition allows both a textual address as an identifiable "place" to act as a birthplace. If we need to support this in Fhir, the birthplace needs to be represented by an Address and/or an identifiable Location Resource (or "Place" resource, needs to be discussed):

Proposal for Person.BirthPlace[0..1]

• address, Address [0..1] (BithPlace.addr)
• name, string [0..1] (from CDA R3 Place.name)
• place, Resource(Location) - todo: to be adapted depending of the definition of a Place and/or Location resource

Unlike in v3 messages, other Place attributes cannot be included, unless as part of an instantiated resource.

Person.PatientOfOtherProvider

Here, in my opinion, the registration of care provisions of care providers for this person goes beyond the scope of person demographics and attribution. Consequently this information needs to be moved to the next layer of the business model.

Person.OtherIDs

Identifiers used for the focal patient by other registries are sent in the OtherIDs class; this could even be an identifier used by the scoping organization of this Patient Registry but in a different context. The scoping organization for this identifier is sent in a required E_Organization [identified/confirmable] CMET.

The usecase for OtherIDs is the representation of id's assigned by other parties to this person. The current Fhir HumanId type allows for this, so the Person.identifiers element can be used to register these id's.

Person.Employee

A relationship of the focal person with an organization to receive wages or salary. The purpose of this class is to identify the type of relationship the employee has to the employer rather than the nature of the work actually performed. (according to the PA DMIM description. Role is called 'Employment' in R_Participant)

Since the nature of this role is the relationship between an employer and an employee, the use of this data could well extend beyond the Patient DMIM to cover employment of medical personnel as well. The CDA R3 header contains both 'Employee' and 'PersonEmployee' and 'Employment' in R_Participant (CDA), but is not present in CCD nor in R2.

Is Employee a Role? It is interesting to note that for medical personnel, there will be some kind of natural identifier, and the Employee role has a considerable number of specific attributes (jobClass, salary, hazardExposure). Most of these are irrelevant for Patients (where the purpose, according to the DMIM, is to identify the type of relationship the patient has with his employer) and it is unlikely multiple systems within or across hospitals will be able to identify the employment of a patient. It is also unlikely that persons will participate in medical procedures and acts in their role as employee (rather as an agent, patient, care provider), so the employee role is not likely to be used for attribution.

So, Employee might be a Resource for personnel management. In the context of patient administration, all that remains is its function to define the relationship between patient and employer (its role to define the nature of the work being part of the patient's social history). This fact should probably be expressed using some code on an extension element. Discuss with PA.