This is the Continuous Integration Build of FHIR (will be incorrect/inconsistent at times).
See the Directory of published versions

• Content
• Examples
• Detailed Descriptions
• Mappings
• Operations
• Search Params
• Profiles
• Extensions
• R4 Conversions

8.21 Resource Person - Content

Patient Administration Work Group

Maturity Level: 4

Trial Use

Security Category: Patient

Compartments: Patient, Practitioner, RelatedPerson

Demographics and administrative information about a person independent of a specific health-related context.

8.21.3 References to this Resource

• Resource References: itself and PersonalRelationship
• Extension References: Device Maintenance Responsibility and initiating person

8.21.4 Resource Content

 

Additional definitions: Master Definition XML + JSON, XML Schema/Schematron + JSON Schema, ShEx (for Turtle) + see the extensions, the spreadsheet version & the dependency analysis

8.21.4.1 Terminology Bindings

Path	ValueSet	Type	Documentation
Person.gender	AdministrativeGender	Required	The gender of a person used for administrative purposes.
Person.maritalStatus	MaritalStatusCodes	Extensible	This value set defines the set of codes that can be used to indicate the marital status of a person.
Person.communication.language	AllLanguages (a valid code from Tags for the Identification of Languages )	Required	This value set includes all possible codes from BCP-47 (see http://tools.ietf.org/html/bcp47)
	Common Languages	starter
Person.link.assurance	IdentityAssuranceLevel	Required	The level of confidence that this link represents the same actual person, based on NIST Authentication Levels.

8.21.5 De-normalized Data

Most of the properties of the Person resource are replicated within the other resources that they are shared with. This is intentional and highlights the loose coupling of the resources.

Not many systems implement a shared Person record, and as such the values DO become out of sync with each other. The inclusion of this resource does permit a capability for systems to identify other instances of this actual person's data via a centralized registry that can assist in keeping things up to date.

8.21.6 Person and Linking

The person.link element is used to relate resources under a common person record. This element supports two primary scenarios where other resources refer to the same person resource.

Note to Implementers: In previous versions of the FHIR specification the patient.link element was not able link to RelatedPerson entries, leaving the Person resource to link them. Since STU3 the patient.link property was updated to also support RelatedPerson, reducing the need to link using the Person resource, however this can still be done.

8.21.7 Cross-Domain Patient Directory

In a data sharing network, finding the location of patient records across different systems is a necessary pre-requisite for accessing external patient data. Using the link element, systems associate patient resources from different organizations. The assuranceLevel associated with the link provides a way for a system to qualify its confidence in the asserted link. For example, a relationship from the person to a patient using a probabilistic matching algorithm may be represented using a link with an assurance level of level1, while a relationship established using a government-issued photo ID may be created with an assurance level of level3.

8.21.8 Cross-Domain Provider Directory

Similarly, providers working in multiple healthcare service settings may be linked across different organizations using the link element. The various practitioner resources can be related using a common person resource with a link for each of the practitioner resources located in other organizations.

8.21.9 Person Master Index

Many national and state programs maintain a central register of people, and their key Identifiers. These systems do not store any health related information, they are purely a validated set data, often provided by government departments. These may contain identifiers for patients, practitioners from various departments for various purposes. Access to these systems typically requires some form of professional role or permission, such as those in healthcare, law enforcement, or other internal government uses.

These may also operate outside of government in the private sector, such as associations or healthcare networks that a person may be involved with and may work in the same was as they do inside government. The usage of the data into the healthcare environment is not the only use of the register.

Note to Implementers: This style of system may use the Person resource without any FHIR references to Patient or Practitioner resources. In these environments the Master Index is likely to have a master identifier that performs this logical linking.
This style of usage has fewer security implications, as it doesn’t disclose where the information is being used.

8.21.10 Client Portal

Client Portals provide consumer access to a window of their data locked up in healthcare systems. In many cases these systems are externally integrated and do not have access to the legacy CIS/PAS systems.

In contrast to most systems where a user has access to multiple patients depending on their roles and permissions, a client portal provides a consumer with direct access to their data (with permissions applied). This can also include not just their data (via the Person.link Patient entries), but also to information that they have entered, or were involved with (via the Person.link RelatedPerson entries), such as observations that they entered.
With appropriate permissions/consent applied, the user could have access to other Patient records linked via a RelatedPerson.

8.21.11 Security and Privacy Considerations

The Person resource may contain identifying and demographic information about an individual, therefore it must be protected as Identifying Information.

The Person resource may contain references to the individual's other various Patient, Practitioner, and RelatedPerson resources, where the referenced record might be to very sensitive information. The access to the linked sensitive Resource may be protected, but the link itself may expose information.
For example where a Practitioner and Patient resource are linked through a Person resource, inspecting the Patient URL could reveal that the Practitioner has a record at a sensitive medical health clinic (e.g. Drug Rehabilitation Clinic).

When implementing the Person resource consideration should be given to the security and privacy of this information. Some mitigations to these risks include higher access control protections, filling out the Person resource as sparsely as practical for the given use-cases, and masking some data elements for certain users of the information. Additional security guidance can be found on the security page.

8.21.12 Search Parameters

Search parameters for this resource. See also the full list of search parameters for this resource, and check the Extensions registry for search parameters on extensions related to this resource. The common parameters also apply. See Searching for more information about searching in REST, messaging, and services.

Name	Type	Description	Expression	In Common
address	string	A server defined search that may match any of the string fields in the Address, including line, city, district, state, country, postalCode, and/or text	Person.address	4 Resources
address-city	string	A city specified in an address	Person.address.city	4 Resources
address-country	string	A country specified in an address	Person.address.country	4 Resources
address-postalcode	string	A postal code specified in an address	Person.address.postalCode	4 Resources
address-state	string	A state specified in an address	Person.address.state	4 Resources
address-use	token	A use code specified in an address	Person.address.use	4 Resources
birthdate	date	The person's date of birth	Person.birthDate	3 Resources
death-date	date	The date of death has been provided and satisfies this search value	(Person.deceased.ofType(dateTime))
deceased	token	This person has been marked as deceased, or has a death date entered	Person.deceased.exists() and Person.deceased != false
email	token	A value in an email contact	Person.telecom.where(system='email')	5 Resources
family	string	A portion of the family name of the person	Person.name.family
gender	token	The gender of the person	Person.gender	4 Resources
given	string	A portion of the given name of the person	Person.name.given
identifier	token	A person Identifier	Person.identifier	65 Resources
link	reference	Any link has this Patient, Person, RelatedPerson or Practitioner reference	Person.link.target (Practitioner, Patient, Person, RelatedPerson)
name	string	A server defined search that may match any of the string fields in the HumanName, including family, give, prefix, suffix, suffix, and/or text	Person.name
organization	reference	The organization at which this person record is being managed	Person.managingOrganization (Organization)
patient	reference	The Person links to this Patient	Person.link.target.where(resolve() is Patient) (Patient)	65 Resources
phone	token	A value in a phone contact	Person.telecom.where(system='phone')	5 Resources
phonetic	string	A portion of name using some kind of phonetic matching algorithm	Person.name	4 Resources
practitioner	reference	The Person links to this Practitioner	Person.link.target.where(resolve() is Practitioner) (Practitioner)
relatedperson	reference	The Person links to this RelatedPerson	Person.link.target.where(resolve() is RelatedPerson) (RelatedPerson)
telecom	token	The value in any kind of contact	Person.telecom	5 Resources