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 an actual "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.

The number of Role-Resources should be kept to a minimum, because any and all roles have to be considered when defining attribution of a care event to one or more roles. Can a "participant" be a Patient, a Patient | Organization, a Patient | Organization | Agent etc. Having many roles causes overlap between roles and make such design discussions difficult and error-prone. And wore, the difference between the role chosen might be irrelevant to most usecases.

Note that in the current design none of the related parties (employee, student, caregivers, etc) are identifiable resources, so they cannot directly be referenced to participate in care events in such a role. To stay within the v3 domain: many DMIMs use a choicebox of "Patient, RelatedParty, AssignedEntity" to indicate attribution (authorship, performer, participants). Because of the way we define related parties now, this has to be limitied to the proposed roles (most probably Patient and Provider).

Person properties

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

• identifier (Person.id) -
• name (Person.name) OK (20120913)
• address (Person.addr) OK (20120913)
• telecom (Person.telecom) - renamed from contact, because that suggested "contact party" at first sight. "telecom" is a well-worn path, so without a really good working alternative we want to stick to it (20120913)
• birthDate (Person.birthTime) - renamed from dob (20120913)
• deceased (Person.deceasedInd) - As long as we do not have a dar for "known to exist, but value not known" in deceasedDate, we need this attribute. It seems the v3 "UNK" did cover the case, but the "unknown" dar does not. Is that intentional? We would like to have this as one field in core.
• deceasedDate (Person.deceasedTime) - Would be core if this is one field, if we need to split up deceased & deceasedDate, deceased would be core, and deceasedDate would be an extension (20120913)
• gender (Person.administrativeGender)
• maritalStatus (Person.maritalStatusCode) - We discussed moving this onto the SoC role, since its most relevant there, but most attendees felt it was so much a characteristic of a person, that it should remain in Person and is just not strictly patient-only (20120913)
• multipleBirth (Person.multipleBirthInd) - Move to SubjectOfCare, since it is only used in that context (20120913)

EK: birthTime and deceasedTime have been renamed to use 'date', since that it what most people seem to use in common speech & Time seems a prefix connected to the datatype TS. AH: (and this goes for other name changes as well:) every time you change a name you make a disconnect between what v3 people know and are used to and the new FHIR spec. Don't do that unless really necessary.

EK: '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. AH: See comment about changing names from their v3 counterparts.

EK: For Person.deceasedInd because we have been discussing replacing these by a 'dataAbsentReason' 'unknown but known to exist' on 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.
• 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.
• multipleBirthOrder --> Move to SubjectOfCare (20120913)
• confidentialityCode (IdentifierPerson.confidentialityCode) - We feel it is not core, but should be an extension on SoC (20120913). Its also not used in CCD, CDAR2.

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).

In the Person RMIM, the role IdentifiedPerson is logically "combined" with the actual Person. These are the properties from IdentifierPerson that we considered, but are not worth transferring to person:

• status - always "active", so does not really carry any information worth transferring
• effectiveTime - is part of a role, but since IdentifierPerson was just a "technical" role introduced into the RMIM because Person could not be used as an entrypoint, this information was not really pertinent to Person.

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..*]

• identifier [0..1], HumanIdentifier (Citizen.id)
• 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

AH: This is core, very common in NL and other countries.

Remarks: identifier has been limited to 0..1.

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] (BirthPlace.addr)

Remarks: other Place attributes cannot be included, use Address.text to describe places like 'in taxi', 'on A2 motorway'

Person.PatientOfOtherProvider

A patient may have one or more primary care and/or preferred providers (PCP) that are relevant from an administrative point of view. Each of these is sent in an A_PrinicpalCareProvision CMET linked to the living subject who plays the role of PatientOfOtherProvider that is the subjectOf the care provision act.

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, for example to CareProvision from the PC domain.

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 his/her employer". This fact should probably be expressed using a code on an extension element. Discuss with PA.

Person.Student

Information for students, including student identifier and a boarding student's address and telephone, can be sent in a Student class. The statusCode and effectiveTime attributes can differentiate between current and former student relationships.

From this definition, it seems clear that the Student role is meant for students participating in care-related activities within an institution (check). This role is not separately identified in CDA or CCD, nor in openEHR, so it seems it will not make it into a Resource. This also means it won't be possible to identify someone explicitly in his role as student to participate in business processes.

Todo - check with PA for the actual usecase. Depending on usecase, the following might apply:

• To identify the fact that the person is a student, what and when: as an extension on Person. AH: This is indeed the usecase. The DMIM description suggests otherwise.
• To generally indicate a person's level of education: as a social history
• if it's the student-id that is of interest, this could be added to the list of HumanId's for the person.
• It's not clear to me if there's actual use to distinguish the 'boarding address' of a student from his/her Person.address.
• Actual qualifications that result from schooling are covered in the new Person.qualifications element.

Person.PersonalRelationship

Associations between the patient and another living subject, such as spouse or parent, can be sent in a PersonalRelationship class. The exact nature of an association is described by the code attribute with a value drawn from the PersonalRelationshipRoleType domain. The statusCode and effectiveTime attributes can differentiate between current and former personal relationships, for example, a former spouse. Most associations can be represented in either of two ways depending on who is the player and who is the scoper. For example, the association between a father and his daughter can be represented by a code of "father" where the parent is the player and the child is the scoper, or by a code of "daughter" where the child is the player and the parent is the scoper. Send a PersonalRelationship with negationInd "true" and a relationshipHolder of "not applicable" null flavor to convey that the patient does not have a personal relationship of the type characterized by the code attribute.

Is this role a Resource? To actually attribute care information to this role, like the informant being "the father" or the subject being "the son" this might be necessary. The number of specific attributes for this Resource would be very low though, and there's no natural identifier for it, so when systems are communicating, how can they refer to "the father role"?

More probably, the personal relationships can be recorded as nested information within Person. This nested information should contain both just basic elements of the related person (name, type of personal relationship) and might include a true reference to another Person Resource, in case this person is communicated or stored as a full Person resource.

Address and telecom information are part of the PersonalRelationship clone in the DMIM. Unlike with a "professional relationships" it seems unlikely role-specific contact information is within the 80%, e.g. "Address of this person as a friend of the patient", versus just the friend's address information as a person. So: if contact info is necessary, add the related person as a Person resource with address information, and refer to this Person resource using the nested "RelatedPerson" element as described above.

Remark: the definition in the DMIM mentions using 'negationInd' to indicate that some relationship does not exist. While typicial for v3, is not something I'd like to duplicate in Fhir. If you want to indicate someone is an orphan, put it in the social history using an observation.

Proposal for Person.RelatedPerson[0..*]

• role, CodeableConcept [0..1] (PersonalRelationship.code) - can be any next-of-kin, friend, and other inter-personal relationships, but not functional relations like guardianship and caregivers.
• name, HumanName [0..1]
• contact, Contact [0..1]
• Resource(Person) - in case the basic elements for RelatedPerson are insufficient, or the person is already known as a Resource, use the Resource reference.

Person.ContactParty

A person or organization that provides or receives information regarding the patient is sent in the ContactParty class. The type of contact is determined by a code from the ContactRoleType domain. The current values are "next of kin" and "emergency contact". The telecom attribute is required and mandatory. The statusCode and effectiveTime attributes can differentiate between current and former contacts. If the relationship (e.g., parent, spouse, unrelated friend) of the contact to the patient is of interest then a PersonalRelationship with the same living subjects as player and scoper should also be sent. Send a ContactParty with negationInd "true" and a contactEntityChoice of "not applicable" null flavor to convey that the patient does not have a contact party of the type characterized by the code attribute.

Both ContactParty and PersonalRelantionship provide elements to register address information. For ContactParty the address information seems more relevant and since it's a "party" it can also be an organization instead of a natural person. It is questionable if this is really an organization or an assigned person for that organization that has to be contacted. Also, since the possible contact codes are limited to "next of kin" or "emergency contact" it seems more improbable that an organization will actually play the role of contactparty here. Also, I expect a lot of overlap between the group of related persons and the contact person(s). There are three possibilities here:

• Recording the fact that some related person is a contact person by adding a flag to the Person.RelatedPerson element. One cannot indicate effectiveTime and thus "history" of contact parties this way, nor can one refer to a specific contact person if there are multiple.
• Keep ContactPerson and RelatedPerson as distinct nested elements within Person. Now, one can be contact person only during some timeframe, but still remain family member of the patient. One can still not distinguish contact persons if that is required for attribution.
• Making contact person into a Resource. Now, it is possible to refer to a specific contact person from an act. The notion of a "contact person" does not seems to have a natural identifier, nor will it have a considerable amount of relevant data. Alternatively, we might one chose of the two alternatives above, and refer to the actual identification of the contact person from the act (so, not using a Resource reference, but a natural identifier of the person who acts as the contact person).

I propose choice (2), introducing AssociatedParty[0..*], which records any people having a functional relationship with the Person:

• role, CodeableConcept [0..1] - (caregiver, contact person, guardian)
• name, HumanName [0..1]
• contact, Contact [0..1]
• Resource(Person|Organization|Agent) - in case the basic elements for RelatedProvider are insufficient, or the provider is already known as a Resource, use this Resource reference.
• period, Period [0..1]

AH: Another solution would be to have a RelatedPerson which can have multiple RelatedPerson.roles, so someone can be both a "brother" and "caregiver".

Person.CareGiver

A person (playing entity) responsible for the primary care of the patient (scoping entity) at home. The statusCode and effectiveTime attributes can differentiate between current and former caregiver relationships.

Note that a CareGiver can only be a person. The CareGiver may well have a PersonalRelationship with the Person as well.

See ContactParty.

Person.Guardian

The Guardian class can send the person or organization (player) that is legally responsible for the care and management of the patient (scoper). The statusCode and effectiveTime attributes can differentiate between current and former guardian relationships. A facsimile of the legal document establishing guardianship could be sent in the certificateText attribute. If the relationship (e.g., parent, spouse, unrelated friend) of the guardian to the patient is of interest then a PersonalRelationship with the same living subjects as player and scoper should also be sent. Send a Guardian with negationInd "true" and a guardianEntityChoice of "not applicable" null flavor to convey that the patient does not have a guardian.

Question: Except for (foster)parent/child guardianship, guardianship by organizations seem to be outside the 80%. Maybe all guardianship is? I guess guardianship is more or less assumed to be with the parents unless there's an explicit guardianship (foster parents?) indicated. In NL, "guardianship" is only defined for persons not being the parents.

See ContactParty.

Person.LanguageCommunication

In the current proposal this becomes a nested element Person.language [0..*]

• code, code [1..1] - ISO 639-3? Or something like ENG-CA?
• use, code [0..1] - No differentiation is made between spoken and written functionality here. Codes are from LanguageUse (fluent, useable, poor, none)

Patient

This, in principle, covers the attributes specific for a Person handled as a subject of care by a certain organization.

TODO: Describe what "Patient" is. Current definition in FHIR is incorrect (receiving care?), definition in DMIM ('primary record for the focal living subject in a patient registry') is too abstract. But it seems to be a 'record'. RIM says 'A LivingSubject' as a recipient of health care services from a healthcare provider'.

GG: Patient record includes an institution. This is not intended to be where the care occurs, but, which institution manages the resource.

In this definition of Patient 'converage' (A_Coverage) is incorrectly connected to a Patient record, since the Person is covered for all instances of patient-ness across organizations, not specifically for one organization.

Patient.addr. What kind of address would be pertaining to a Patient but not to the Person itself. Current implementations seem to prefer putting all addresses of the Person in Patient.addr. It seems more appropriate to use this for addresses like 'Ronald McDonald Houses'. It certainly does not seem like core.

For Patient.telecom we expect this to be used for telecom which is connected to the bed location as opposed to a patient's own phone number.

EK: I think when defined like this, addr/telecom information is about an admission to the hospital, an should not have a place in Patient: every time the patient is admitted, this information changes, and you need to update Patient. It feels not right to update a role to reflect information connected to a business process.