HdBe-AddressInformation

This datatype defines a common basis for expressing all addresses around the world, but adds extensions to express Belgium addresses specifically, according to the CBB AddressInformation. A Belgium 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 Belgium context, the implementer SHOULD in addition use the extension elements.

Separate address parts

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

Custom address types

The second addition is that the CBB 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 CBB concepts are mapped to the various FHIR elements (see the ConceptMaps https://fhir.healthdata.be/ConceptMap/AddressType-to-AddressType and https://fhir.healthdata.be/ConceptMap/AddressType-to-AddressUse as well). The code from the CBB should also be included using the extension on Address.extension:addressType.

     | CBB                               | .ext:addressType | .use | .type    |
     |-----------------------------------|------------------|------|----------|
     | Postal Address/Postadres          | PST              |      | postal   |
     | Primary Home/Officieel adres      | HP               | home | both     |
     | Visit Address/Woon-/verblijfadres | PHYS             | home | physical |
     | Temporary Address/Tijdelijk adres | TMP              | temp |          |
     | Work Place/Werkadres              | WP               | work |          |
     | Vacation Home/Vakantie adres      | HV               | temp |          |

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 CBB's ValueSet. Therefore, a custom extension has been made. This doesn't preclude the use of the AD-use extension.

Optional Extension Element - found in all resources.

The elements of Address stored in the address-part extensions will be ignored by applications that do not support them, so any information in them should also be duplicated in the Address.line to which they are attached. The value of Address.line should be populated with a complete string representation of all the separate extension values, like: "[Street] [HouseNumberIndication] [HouseNumber] [HouseNumberLetter] [HouseNumberAddition]".

streetName.

Street name of the address.

The number of a building, house or lot alongside the street. Also known as "primary street number". This does not number the street but rather the building.

House number of the address.

Any alphabetic character, fraction or other text that may appear after the numeric portion of a building number.

Export:

• If a HouseNumberLetter as well as a HouseNumberAddition is known: HouseNumberLetter first, followed by a space and finally the HouseNumberAddition.
• If only a HouseNumberLetter is known, send just that. No trailing space is required.
• If only a HouseNumberAddition is known, communicate that with a leading space.

Import

• If the value of buildingNumberSuffix contains no space, then the whole value is considered to be the HouseNumberLetter.
• If the value of buildingNumberSuffix contains a space, then everything before the first space is considered to be the HouseNumberLetter, and the everything trailing the first space is considered to be the HouseNumberAddition.

Note: While a leading space is allowed in string values in FHIR, the parsing of such space cannot be guaranteed in XML representations. Although aware of this issue, this mapping is not changed because of compatibility reasons. If an implementer cannot parse a leading space, the practical risk of mapping a HouseNumberIndication to a HouseNumberAddition is deemed insignificant.

This can be a unit designator, such as apartment number, suite number, or floor. There may be several unit designators in an address (e.g., "3rd floor, Appt. 342"). This can also be a designator pointing away from the location, rather than specifying a smaller location within some larger one (e.g., Dutch "t.o." means "opposite to" for house boats located across the street facing houses).

The indication used for addresses which do not consist of the usual street name and house number.

The coded HouseNumberIndication concept (CD datatype) is mapped to a FHIR string datatype with a constraint added (the value can only be 'by' or 'to').

The number or name of a specific unit contained within a building or complex, as assigned by that building or complex.

The FHIR datatype does not properly support coding the country using a CodeableConcept or Coding datatype. If the sender supports coded countries, it SHALL send the coded value using the CodeSpecification extension under Address.country.extension:countryCode.

Optional Extension Element - found in all resources.

Country in which the address is located.