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

Do we need Person?

Lloyd: I would have expected a bit of documentation on why Person makes sense as a distinct resource. In my experience, very few systems treat Person as a distinct entity from either Provider or Patient and almost never share a construct between them. Splitting Person from Patient and Person from Provider adds a fair bit of administrative complexity for systems, so we should only do so with good reason. Keep in mind that Patient need not be specific to a particular hospital. It's entirely possible for a Patient role to exist at a national or other level - any level where it makes sense to have a registry of them. Thus Person is not needed as a shared linkage point for Patient. And even if you did want to indicate that multiple Patients were in fact the same Person, you wouldn't necessarily have a shared Person record. The names, contact and other information might well be separately maintained. The only real reason I can think of for having Person as distinct from Patient and Provider is to support the rare use-case of a true "Person" registry where demographics are maintained separately from Patient and Provider information and it's possible for one "Person" to be both a "Provider" and a "Patient". I think this is a fairly remote edge-case and thus not necessarily worth the complexity of splitting the person information here.

Remember - resource design is not driven by semantic modelling, it's driven by how systems behave. So even if logically there's a Person and Roles, that should only manifest in the resource design if that's how we expect systems to behave.

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) - Core (20120913) [TELCON20130211 - We have changed this to become a specific identifier for Patient and a specific identifier for Provider. We decided to have both and re-introduce it in Demographics]
• name (Person.name) - Core (20120913) [WGM201301 - Stayed as part of Demographics]
• address (Person.addr) - Core (20120913) [WGM201301 - Stayed as part of Demographics]
• telecom (Person.telecom) - Core, 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) [WGM201301 - Stayed as part of Demographics]
• birthDate (Person.birthTime) - Core, renamed from dob (20120913) [WGM201301 - Stayed as part of Demographics]
• deceased (Person.deceasedInd) - Core (20120913) [WGM201301 - Stayed as part of Demographics]
• deceasedDate (Person.deceasedTime) - Extension (20120913), but see discussion below
• gender (Person.administrativeGender) - Core, valueset as in v2 and v3 - [WGM201301 - Stayed as part of Demographics]
• maritalStatus (Person.maritalStatusCode) - Core. 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) [WGM201301 - Stayed as part of Demographics]
• multipleBirth (Person.multipleBirthInd) - Move to SubjectOfCare, since it is only used in that context (20120913)

(20121022) TCON motion passed to keep maritalStatus in core, reaffirming what was already decided on 20120913, after a lot of discussion on the list on this particular attribute. There seems to be no valid objection in keeping it in core, all participants on call including Scandiavian and Canadian use sases include this attribute. It seems that registries that need it, actually really require it and registries that do not also do not object having it in there.

• LM: The use-cases are all for Patient though, and Person is also used for Provider. I can accept it being deemed part of the 80% for Patient, but find it hard to believe that 80% of systems that maintain Provider will capture maritalStatus. (The fact it applies to Person doesn't mean that it should live on Person. The element should live where it's typically used. Things such as height and weight are also associated with Person, but they will always be associated with SubjectOfCare, never Person.)

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.

Discussion: there are two choices (a) deceased and date are two separate notions, one who could go in core and one who does not, and not all usecases need both, (b) its one piece of information, and to avoid inconsistencies its better to have one field with a nullflavor saying that there is a date, but it is not available/known.

Q: Can we only define search operations based on the exact format of the data? For dates, can we make a search like "isDeceased", which would then actually search for dates with dar "unknown" ?

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

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

(20120917) TCON decision is to have this information as an extension and most likely to SubjectOfCare rather than Person. It is not likely that you record this info for Providers and the like

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'

(20120917) TCON decision is to have this information as an extension and most likely to SubjectOfCare rather than Person. It is not likely that you record this info for Providers and the like

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.

(20120917) TCON decision is to have this information as an extension and most likely to SubjectOfCare rather than Person. It is not likely that you record this info for Providers and the like

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.

(20120917) TCON decision is to have this information as core. The group feels that any Person could have other associated ids

• id (core)
• statusCode (extension)
• effectiveTime (extension)
• scopingOrganization (core) Action item: (AH) talk to Ewout pros/cons of inline version resource reference for this attribute

(20120917) TCON discussion on how to convey the identifier type. Examples from Iryna are to convey "Drivers license from Alberta", "License for narcotics tracking". Action item (IR) Send URL with different relevant ID types in Canada.

(20120919) By IR: Here is the list of identification documents that can be used in Ontario, Canada to get narcotics prescriptions fulfilled.

[TELCON20130211 - Re-introduction of an identifier on Person (so its both on Person and Patient) for personal id's is sufficient. The Identifier type covers the core needs]

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.

(20120917) TCON decision. For Persons that are a provider this relationship could be useful to identify multiple roles he has. In Dutch Youth Care you will need this info for the SubjectOfCare. Groups feels that although these use cases exist this attribute is in the 20% rather than the 80% and so it belongs in an extension

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.

(20120917) TCON decision is to have this information as an extension and most likely to SubjectOfCare rather than Person. It might be relevant for Provider (trainees) in some cases, but all in all this should be an extension, not core.

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.

(20120917) TCON decision is to have this information as an extension and most likely to SubjectOfCare rather than Person. It is not likely that you record this info for Providers and the like

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 PersonalRelationship 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 seem to have a natural identifier, nor will it have a considerable amount of relevant data. Alternatively, we might one choose 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] core (20120924) (contact person|organization|agent) -- contact roles like guardian and care giver are not considered core to e.g. Persons that are Provider, see below
• name, HumanName [0..1] core (20120924)
• address, Address [0..*] core (20120924)
• telecom, Contact [0..*] core (20120924) Renamed from contact, similar to the Person class
• period, Period [0..1] extension (20120924)
• 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.

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

(20120917) TCON decision is that this class is core. Discussion on the attributes was not finalized. Group will come back to decide if having ContactParty as a separate resource is desirable.

(20120924) TCON decisions:

• This class is core to Person.
• This should not be a separate Resource.
• The rationale is that it's in the 80% of SubjectOfCare and Employee. It would be unfair/weird to force ContactParty in other roles, where it is most likely in the 20%, into the extensions while the attributes are the same when used.

(20120924) TCON discussions left unfinished. Will continue next call. What to do with ContactParties that are Guardian or Care Giver and the like. They are not core to any role. Two solutions:

• Add all ContactParty role type into Person and leave it up to profiles to constrain out roles that are not applicable to a particular role
  • Note: it is not possible methodologically to 'call' a Resource that you reference with a specific profile hence you cannot say something like only include this attribute/relationship when this is a Resource referenced from a SubjectOfCare, but not when this is a Resource referenced from a Provider
• Constrain ContactParty.role to the 80% on Person and add the ContactParty to roles where applicable, e.g. Guardian to SubjectOfCare, and Secretary/Head Office to Provider. This is similar to decisions made on e.g. BirthPlace
  • Note: the current ContactParty actually would be a "unspecified" ContactParty. You could question what Person ever has an "unspecified" ContactParty, e.g. "Call Sara at extension 234" without anything beyond that. Is she the mother for Emergency or the secretary for Business? We don't know. For this reason we could also reverse the decision to add ContactParty as core to Person and instead move ContactParty to roles altogether.

(20121004) Based on input from Netherlands, Norway, and Canada. Proposal accepted to not have any role relationships on Person to keep it lean and easy to implement. Any role relations should be added to role. This reverses the WG earlier decision to add ContactParty on Person, and instead leaves ContactParty to roles like SubjectOfCare, Provider and any other role that may have use for this association.

Discussion

(20120919-20120920) There was a PAFM list discussion was multiple people chipping in:

Chris: Based on the earlier recommendation that we should not create a resource for entities that don't have a natural identifier this entity should not become a resource. As far as attributes for this entity, please include the postal address. This is used most of the time (at least in the US).

Iryna: We didn't finish the conversation about the ContactParty. The reason why the group was thinking about the resource because it may be called not only fromt the Person resource but also applicable to a visit, care plan or care plan component, procedure etc. However I see your point about identifiers :) Is there an equivalent of "CMET" inFHIR?

Lloyd: In FHIR, there are no CMETs. However, it is possible to declare a profile that must apply when referencing a resource. I'd use caution when doing so though. You have no clue what context your resource might be used in, so it's often hard to know a priori what constraints make sense for resources you reference. In most cases, profiles make more sense to defer to when defining a service, message or document (and thus have the context of use).
Thus far we've said that if you want to re-use a construct that isn't a separate resource, you just copy it into your resource definition. Only the committee maintaining the resource knows what constraints they require and odds of something being used exactly the same in multiple locations (including having identical descriptions, usage notes, etc.) is slim. Given that we're only going to have on the order of 100 resources total, and the number of places a re-used construct would appear is likely an order of magnitude less than that at maximum, copy & paste to ensure consistency is probably less complex than introducing a re-usable construct and trying to ensure fitness for purpose everywhere it's used.

Ewout: It seems to me CMET’s where implicitly used for (at least) three things in v3, which must be made explicit in FHIR:

• To contain a set of constrained classes, for (re)use in a certain context. This is what profiles are for now.
• To contain a set of classes, which could be reused in multiple models and actually formed a separate, reusable information entity (which is what Resources are now)
• To contain a set of classes, which could be reused in multiple models but where actually components of those models, and not separate units. This we do NOT have in FHIR, with one exception: within the same Resource definition, groups of attributes (the classes referred to by the closed diamond in UML) can be reused.

By the way, we badly need a name for the 3rd bullet, the “grouped attributes with a name UML, which are a component of the Resource, and which show up as nested data in the Resource XML”.
We’re using that “3rd bullet construct” to do ContactParty (is called RelatedParty in the Wiki-page about Person that Alexander and I put up, and is called RelatedPerson in the current FHIR spec). So, for now, this is not yet a separate resource, but a bunch of properties that is part of the Person itself. However, there’s an escape: the ContactParty properties also contain an identifier with which you could refer to a separate Person resource, for example if you would like to communicate and store the separate family members as individual resources.

Iryna: I do feel that we are talking about a third bullet without a name :) How would you recommend approaching the ContactParty, if it doesn't have a natural identifier (I guess it means a real life identifier) and highly desired to be re-used for non-Person resources? Ok, then we have a risk :) one group would copy from somewhere (if they know from where to copy) and another group would create an own part. Then if any updates, it will be changed in one place and not changed everywhere else...unless the FHIR Management Board keeps an eye on it ;-) right?

[WGM201301 Discussion seems to indicate contactpersons are not a separate resource, and we the need to have contactpersons is core. Added exactly that to the Patient and used Alexander's suggestion to have multiple types of contact-relationships. I also added a suggested list of codes to indicate the type. During TELCON20130211 we have discussed and confirmed this solution]

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.

(20120924) See ContactParty, specifically ContactParty.role

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.

(20120924) See ContactParty, specifically ContactParty.role

Person.LanguageCommunication

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

• languageCode, code [1..1] - core (20120924) A value representing a language for which the focal person has some level of proficiency for written or spoken communication. Examples: Spanish, Italian, German, English, American Sign. ISO 639-3? Or something like en-CA?
• modeCode [0..1] - core (20121004) A value representing the person's method of expression of this language Examples: expressed spoken, expressed written, expressed signed, received spoken, received written, received signed
• proficiencyLevelCode [0..1] - core (20121004) A value representing the person's level of proficiency in this language. Examples: excellent, good, fair, poor
• preferenceInd [0..1] - core (20121004) An indicator specifying whether or not this language is preferred by the focal person for the associated mode

(20121004) Rationale is based on input from Canada. Other persons on call are from single language countries.

Person.Member

Design Comments: A membership of the playing living subject in a group such as family, tribe, or religious organization UsageNotes: MEMBER Changed effectiveTime from IVL<TS> to GTS to allow conveying that a person is an active member of a household on a particular schedule (e.g., alternate weeks).

(20121004) This relation is not core. It's probably mostly relevant to SubjectOfCare and use cases for other role seem too far fetched to be in the 80%

Person.administrativeObservation

An observation that conveys peripheral administrative information that is not central to model. Examples of administrative observations might be Shared Secret, Preferred Contact Method, Preferred Contact Times, Preferred Written Communication Format.

(20121004) This relation is not core

SubjectOfCare

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.