Name Flags Card. Type Description & Constraints HumanName C 0..* HumanName This is an abstract profile. Child profiles: NlcoreNameInformation NameInformation zib-NameInformation-1: If a prefix for a family name is specified, the family name is expected as well zib-NameInformation-2: If the prefix for a partner family name is specified, the partner family name is expected as well nameUsage 0..* code Preferred display order of name parts URL: http://hl7.org/fhir/StructureDefinition/humanname-assembly-order Binding: HumanNameAssemblyOrder (required): A code that represents the preferred display order of the components of a human name. value[x] 1..1 code NameUsage Binding: HumanNameAssemblyOrder (required): Use ConceptMap NaamgebruikCodelijst-to-HumanNameAssemblyOrder to translate terminology from the functional model to profile terminology in ValueSet HumanNameAssemblyOrder. use 1..1 code usual | official | temp | nickname | anonymous | old | maiden Required Pattern: official family prefix 0..1 string Voorvoegsel derived from person's own surname URL: http://hl7.org/fhir/StructureDefinition/humanname-own-prefix value[x] 1..1 string Prefix lastName 0..1 string Portion derived from person's own surname URL: http://hl7.org/fhir/StructureDefinition/humanname-own-name value[x] 1..1 string LastName partnerPrefix 0..1 string Voorvoegsel derived from person's partner's surname URL: http://hl7.org/fhir/StructureDefinition/humanname-partner-prefix value[x] 1..1 string PartnerPrefix partnerLastName 0..1 string Portion derived from person's partner's surname URL: http://hl7.org/fhir/StructureDefinition/humanname-partner-name value[x] 1..1 string PartnerLastName given 0..* string FirstName / Initial extension 1..* Extension Extension givenOrInitial 1..* code LS | AC | NB | PR | HON | BR | AD | SP | MID | CL | IN | VV URL: http://hl7.org/fhir/StructureDefinition/iso21090-EN-qualifier Binding: EntityNamePartQualifier (required): A set of codes each of which specifies a certain subcategory of the name part in addition to the main name part type. prefix 0..* string Titles suffix 0..* string Titles Documentation for this format
A person's official name information, including given names, last name and possibly the partner's last name.
This HumanName datatype represents the Dutch [zib ('Zorginformatiebouwsteen', i.e. Health and Care Information Model) NameInformation v1.1 (2020)](https://zibs.nl/wiki/NameInformation-v1.1(2020EN)), except for the GivenName concept. For the entire zib, the complementary profile [zib-NameInformation.GivenName](http://nictiz.nl/fhir/StructureDefinition/zib-NameInformation.GivenName) should be used. Both profiles can be added in a slice with the discriminator set to `value`/`use`.
Copyright and related rights waived via CC0, https://creativecommons.org/publicdomain/zero/1.0/. This does not apply to information from third parties, for example a medical terminology system. The implementer alone is responsible for identifying and obtaining any necessary licenses or authorizations to utilize third party IP in connection with the specification or otherwise.
This slice represents the person's official name information, including given names, last name and possibly the partner's last name.
This `.name` element represents a Dutch name according to the [zib NameInformation (v1.1, 2020)](https://zibs.nl/wiki/NameInformation-v1.1(2020EN)) (except for the GivenName concept). A Dutch name is represented in FHIR as an ordinary international name, but is augmented using extensions to specify how the last name is built up according to the Dutch rules. See the guidance on `.family` and on `.extension:nameUsage` for more information. Systems that need to work in a Dutch context SHOULD support these extensions as specified here. In addition, systems SHOULD use the core elements according to the FHIR specifications to provide compatibility outside Dutch contexts. It is encouraged to provide a representation of the full name in the `.text` element. **Note 1**: The zib cannot be represented straightforward in FHIR. Especially note the guidance on `.given` on how to map the FirstNames and Initials concepts, and on `.prefix`/`.suffix` on how to map the Titles concept. **Note 2**: This element should only contain a person's _official_ names. The GivenName concept is represented in another `.name` element with `.name.use` = _usual_. **Note 3**: The examples illustrate how the zib is mapped to FHIR.
All FHIR elements must have a @value or children
hasValue() or (children().count() > id.count())
If a prefix for a family name is specified, the family name is expected as well
family.extension('http://hl7.org/fhir/StructureDefinition/humanname-own-prefix').empty().not() implies family.extension('http://hl7.org/fhir/StructureDefinition/humanname-own-name').empty().not()
If the prefix for a partner family name is specified, the partner family name is expected as well
family.extension('http://hl7.org/fhir/StructureDefinition/humanname-partner-prefix').empty().not() implies family.extension('http://hl7.org/fhir/StructureDefinition/humanname-partner-name').empty().not()
Unique id for the element within a resource (for internal references). This may be any string value that does not contain spaces.
Extensions are always sliced by (at least) url
Additional content defined by implementations
May be used to represent additional information that is not part of the basic definition of the element. To make the use of extensions safe and manageable, there is a strict set of governance applied to the definition and use of extensions. Though any implementer can define an extension, there is a set of requirements that SHALL be met as part of the definition of the extension.
There can be no stigma associated with the use of extensions by any application, project, or standard - regardless of the institution or jurisdiction that uses or defines the extensions. The use of extensions is what allows the FHIR specification to retain a core level of simplicity for everyone.
Must have either extensions or value[x], not both
exists(f:extension)!=exists(f:*[starts-with(local-name(.), "value")])
A code that represents the preferred display order of the components of this human name.
Source of the definition for the extension code - a logical name or a URL.
The definition may point directly to a computable or human-readable definition of the extensibility codes, or it may be a logical URI as declared in some other specification. The definition SHALL be a URI for the Structure Definition defining the extension.
This concept indicates the last name or order of last names with which the person is to be addressed.
Use ConceptMap NaamgebruikCodelijst-to-HumanNameAssemblyOrder to translate terminology from the functional model to profile terminology in ValueSet HumanNameAssemblyOrder.
usual | official | temp | nickname | anonymous | old | maiden
Applications can assume that a name is current unless it explicitly says that it is temporary or old.
Allows the appropriate name for a particular context of use to be selected from among a set of names.
This is labeled as "Is Modifier" because applications should not mistake a temporary or old name etc.for a current/permanent one
XPN.7, but often indicated by which field contains the name
Specifies the entire name as it should be displayed e.g. on an application UI. This may be provided instead of or as well as the specific parts.
Can provide both a text representation and parts. Applications updating a name SHALL ensure that when both text and parts are present, no content is included in the text that isn't found in a part.
The part of a name that links to the genealogy. In some cultures (e.g. Eritrea) the family name of a son is the first name of his father.
Family Name may be decomposed into specific parts using extensions (de, nl, es related cultures).
unique id for the element within a resource (for internal references)
exists(f:extension)!=exists(f:*[starts-with(local-name(.), 'value')])
Voorvoegsel derived from person's own surname
The prefix portion (e.g. voorvoegsel) of the family name that is derived from the person's own surname, as distinguished from any portion that is derived from the surname of the person's partner or spouse.
An example of a voorvoegsel is the "van" in "Ludwig van Beethoven". Since the voorvoegsel doesn't sort completely alphabetically, it is reasonable to specify it as a separate sub-component.
Portion derived from person's own surname
The portion of the family name that is derived from the person's own surname, as distinguished from any portion that is derived from the surname of the person's partner or spouse.
If the person's surname has legally changed to become (or incorporate) the surname of the person's partner or spouse, this is the person's surname immediately prior to such change. Often this is the person's "maiden name".
Voorvoegsel derived from person's partner's surname
The prefix portion (e.g. voorvoegsel) of the family name that is derived from the person's partner's surname, as distinguished from any portion that is derived from the surname of the person's own.
An example of a voorvoegsel is the "van" in "Ludwig van Beethoven". Since the voorvoegsel doesn't sort completely alphabetically, it is reasonable to identify it as a separate sub-component.
Portion derived from person's partner's surname
The portion of the family name that is derived from the person's partner's surname, as distinguished from any portion that is derived from the surname of the person's own name.
One of a person’s official first names or the initial if the full name is not known.
This element represents the FirstNames and Initials concepts of zib NameInformation, but the FHIR implementation deviates from the zib model. The zib defines these concepts as a list of official first names (as a single string) and a list of initials (as a single string), both optional. They both represent the official name(s) of a person and thus represent the same concept. In FHIR however, each first name is either a complete name or an initial, but not both. In addition, each name may be defined separately. Therefore, the zib concepts are implemented here in the following way: * Systems SHOULD use a `.given` element for each official first name that they know of (either as a full name or an initial), in order of appearance (as specified by FHIR). * Each of these elements: * SHOULD be populated with the complete name if it is known, or with the initial if no more information is available. * SHALL be augmented with `extension:givenOrInitial` with code _BR_ when it represents a full name or code _IN_ when it represents an initial. Initials should thus not be communicated for each complete first name that is known, in contrast to what is specified by the zib. Receiving systems can recreate initials from the full names if needed. If a system _does_ however only have a list of official first names and a separate list of official initials, without knowing the relationship between these two, only the full names SHOULD be communicated, while an additional `.name` instance MAY be used to communicate the initials. It is expected that the second instance just contains the initials and no other information from the zib. Receiving systems MAY ignore the second instance. **Note 1:** The GivenName concept should not be included here but in a separate `.name` instance where `.use` = _usual_. **Note 2**: As specified by FHIR, multiple official first names MAY be combined in a single `.given` element (separated by spaces), as long as the `.given` elements can be concatenated to form the full first name representation, and the 'extension:givenOrInitial` is used to mark the element as containing either full names or the initials. This pattern is strongly discouraged as it is hard to determine if the value pertains multiple names or a single combined name containing spaces.
Given Names appear in the correct order for presenting the name
LS | AC | NB | PR | HON | BR | AD | SP | MID | CL | IN | VV
A set of codes each of which specifies a certain subcategory of the name part in addition to the main name part type.
Used to indicate additional information about the name part and how it should be used.
Noble and scientific titles. These can assist in formulating oral and formal addresing titles.
The zib concept 'titles' is mapped to elements `HumanName.prefix` and `HumanName.suffix`. Semantically this mapping is not complete: the zib uses a single concept that contains all the required information about noble and scientific titles, while FHIR captures the same information in a structured way. **Export:** Systems are expected to transform as much as possible to the FHIR datamodel and thereby to be as explicit as possible. Note that in order to mark the type of a prefix, you can use the FHIR standard extension for ISO 21090 EN Qualifiers. Examples include the use of the qualifier _HON_ to indicate honorific prefixes and _AC_ for academic prefixes. If it is not possible to breakup the zib concept titles to positioned prefixes and suffixes, the prefix element is used to store all information. **Import:** Systems need to expect and be resilient for a broader range of information stored in the prefix element than stated by it's definition.
Prefixes appear in the correct order for presenting the name
Suffixes appear in the correct order for presenting the name
Indicates the period of time when this name was valid for the named person.
Allows names to be placed in historical context.