Patient

Demographics and other administrative information about an individual or animal receiving care or other health-related services.

This slice represents the person's official name information, including given names, last name and possibly the partner's last name.

Need to be able to track the patient by multiple names. Examples are your official name and a partner name.

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

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.

This slice represents the name information normally used to address the person.

Need to be able to track the patient by multiple names. Examples are your official name and a partner name.

This .name element represents the Dutch given name ("roepnaam") according to the zib NameInformation (v1.1, 2020).

Note 1: This element should only contain a person's unofficial name. The official names are represented in one or more other .name elements with .name.use = official.

Note 2: The examples illustrate how the zib is mapped to FHIR.

Container of the TelephoneNumbers concept. This container contains all data elements of the TelephoneNumbers concept.

People have (primary) ways to contact them in some way such as phone, email.

Implementation of the "TelephoneNumbers" concept of zib ContactInformation.

Please note that, although the zib concepts TelecomType and NumberType are functionally equivalent to the FHIR concepts ContactPoint.system and ContactPoint.use respectively, a mismatch occurs on the concept of mobile phone numbers; the zib uses the first concept and FHIR the second. For this reason, the ValueSet on ContactPoint.system is too narrow and the zib code will need to be communicated using the codeSpecification extension.

Details for all kinds of technology mediated contact points for a person or organization, including telephone, email, etc.

People have (primary) ways to contact them in some way such as phone, email.

The "EmailAddresses" concept of zib ContactInformation.

Patient’s administrative gender.

Needed for identification of the individual, in combination with (at least) name and birth date.

The gender might not match the biological sex as determined by genetics or the individual's preferred identification. Note that for both humans and particularly animals, there are other legitimate possibilities than male and female, though the vast majority of systems and contexts only support male and female. Systems providing decision support or enforcing business rules should ideally do this on the basis of Observations dealing with the specific sex or gender aspect of interest (anatomical, chromosomal, social, etc.) However, because these observations are infrequently recorded, defaulting to the administrative gender is common practice. Where such defaulting occurs, rule enforcement should allow for the variation between administrative and biological, chromosomal and other gender aspects. For example, an alert about a hysterectomy on a male should be handled as a warning or overridable error, not a "hard" error. See the Patient Gender and Sex section for additional information about communicating patient gender and sex.

Use ConceptMap 'GeslachtCodelijst-to-AdministrativeGender' to translate zib terminology to profile terminology in ValueSet 'AdministrativeGender'

An address expressed using postal conventions (as opposed to GPS or other location definition formats). This data type may be used to convey addresses for use in delivering mail as well as for visiting locations which might not be valid for mail delivery. There are a variety of postal address formats defined around the world.

May need to keep track of patient addresses for contacting, billing or reporting requirements and also to help with identification.

This datatype defines a common basis for expressing all addresses around the world, but adds extensions to express Dutch addresses specifically, according to the zib AddressInformation (v1.1, 2020). A Dutch Address still is a proper FHIR Address, which means that systems that cannot interpret the extensions will still be able to render and work with this datatype.

To have true compatibility an implementer SHOULD use the core Address parts as intended. To have addresses work for Dutch context, the implementer SHOULD in addition use the extension elements.

Separate address parts

The first addition is that Dutch addresses make certain address parts separately communicable. These parts are required for use in true Dutch systems when dealing with Dutch addresses, but may not have value for international systems when information gets sent abroad.

Custom address types

The second addition is that the zib defines its own ValueSet for address types, which can only be partially expressed using the FHIR Address datatype and requires a mapping to multiple elements. The table below explains how the zib concepts are mapped to the various FHIR elements (see the ConceptMaps http://nictiz.nl/fhir/ConceptMap/AdresSoortCodelijst-to-AddressUse and http://nictiz.nl/fhir/ConceptMap/AdresSoortCodelijst-to-AddressType as well). The code from the zib should also be included using the extension on Address.extension:addressType.

If Address.type is both then this is to be understood as a dual purpose address (postal and physical), unless a specific "postal" type address is added. Systems that support importing it like this are encouraged to do so, otherwise they may need to import this as two separate addresses.

Note: FHIR core defines the AD-use extension to further specify the postal address type. However, the ValueSet used in that extension doesn't completely match the zib ValueSet. Therefore, a custom extension has been made. This doesn't preclude the use of the AD-use extension.