Best-practices

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.

A reference to a location at which the other resource is found. The reference may be a relative reference, in which case it is relative to the service base URL, or an absolute URL that resolves to the location where the resource is found. The reference may be version specific or not. If the reference is not to a FHIR RESTful server, then it should be assumed to be version specific. Internal fragment references (start with '#') refer to contained resources.

Using absolute URLs provides a stable scalable approach suitable for a cloud/web context, while using relative/logical references provides a flexible approach suitable for use when trading across closed eco-system boundaries. Absolute URLs do not need to point to a FHIR RESTful server, though this is the preferred approach. If the URL conforms to the structure "/[type]/[id]" then it should be assumed that the reference is to a FHIR RESTful server.

The purpose of this identifier.

Allows the appropriate identifier for a particular context of use to be selected from among a set of identifiers.

This is labeled as "Is Modifier" because applications should not mistake a temporary id for a permanent one. Applications can assume that an identifier is permanent unless it explicitly says that it is temporary.

A coded type for the identifier that can be used to determine which identifier to use for a specific purpose.

Allows users to make use of identifiers when the identifier system is not known.

This element deals only with general categories of identifiers. It SHOULD not be used for codes that correspond 1..1 with the Identifier.system. Some identifiers may fall into multiple categories due to common usage.

Where the system is known, a type is unnecessary because the type is always part of the system definition. However systems often need to handle identifiers where the system is not known. There is not a 1:1 relationship between type and system, since many different systems have the same type.

Establishes the namespace for the value - that is, a URL that describes a set values that are unique.

There are many sets of identifiers. To perform matching of two identifiers, we need to know what set we're dealing with. The system identifies a particular set of unique identifiers.

see http://en.wikipedia.org/wiki/Uniform_resource_identifier

The portion of the identifier typically relevant to the user and which is unique within the context of the system.

If the value is a full URI, then the system SHALL be urn:ietf:rfc:3986. The value's primary purpose is computational mapping. As a result, it may be normalized for comparison purposes (e.g. removing non-significant whitespace, dashes, etc.) A value formatted for human display can be conveyed using the Rendered Value extension.

Time period during which identifier is/was valid for use.

This is not a duration - that's a measure of time (a separate type), but a duration that occurs at a fixed value of time. A Period specifies a range of time; the context of use will specify whether the entire range applies (e.g. "the patient was an inpatient of the hospital for this time range") or one value from the range applies (e.g. "give to the patient between these two times"). If duration is required, specify the type as Interval|Duration.

Organization that issued/manages the identifier.

The Identifier.assigner may omit the .reference element and only contain a .display element reflecting the name or other textual information about the assigning organization.

Plain text narrative that identifies the resource in addition to the resource reference.

This is generally not the same as the Resource.text of the referenced resource. The purpose is to identify what's being referenced, not to fully describe it.

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.

Value of extension - may be a resource or one of a constrained set of the data types (see Extensibility in the spec for list).

A stream of bytes, base64 encoded

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.

Value of extension - may be a resource or one of a constrained set of the data types (see Extensibility in the spec for list).

A stream of bytes, base64 encoded

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.

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.

The identification of the code system that defines the meaning of the symbol in the code.

Need to be unambiguous about the source of the definition of the symbol.

The URI may be an OID (urn:oid:...) or a UUID (urn:uuid:...). OIDs and UUIDs SHALL be references to the HL7 OID registry. Otherwise, the URI should come from HL7's list of FHIR defined special URIs or it should de-reference to some definition that establish the system clearly and unambiguously.

The version of the code system which was used when choosing this code. Note that a well-maintained code system does not need the version reported, because the meaning of codes is consistent across versions. However this cannot consistently be assured. and when the meaning is not guaranteed to be consistent, the version SHOULD be exchanged.

Where the terminology does not clearly define what string should be used to identify code system versions, the recommendation is to use the date (expressed in FHIR date format) on which that version was officially published as the version date.

A symbol in syntax defined by the system. The symbol may be a predefined code or an expression in a syntax defined by the coding system (e.g. post-coordination).

Need to refer to a particular code in the system.

Note that FHIR strings may not exceed 1MB in size

A representation of the meaning of the code in the system, following the rules of the system.

Need to be able to carry a human-readable meaning of the code for readers that do not know the system.

Note that FHIR strings may not exceed 1MB in size

Indicates that this coding was chosen by a user directly - i.e. off a pick list of available items (codes or displays).

This has been identified as a clinical safety criterium - that this exact system/code pair was chosen explicitly, rather than inferred by the system based on some rules or language processing.

Amongst a set of alternatives, a directly chosen code is the most appropriate starting point for new translations. There is some ambiguity about what exactly 'directly chosen' implies, and trading partner agreement may be needed to clarify the use of this element and its consequences more completely.

A human language representation of the concept as seen/selected/uttered by the user who entered the data and/or which represents the intended meaning of the user.

The codes from the terminologies do not always capture the correct meaning with all the nuances of the human using them, or sometimes there is no appropriate code at all. In these cases, the text is used to capture the full meaning of the source.

Very often the text is the same as a displayName of one of the codings.

The purpose of this identifier.

Allows the appropriate identifier for a particular context of use to be selected from among a set of identifiers.

This is labeled as "Is Modifier" because applications should not mistake a temporary id for a permanent one. Applications can assume that an identifier is permanent unless it explicitly says that it is temporary.

A coded type for the identifier that can be used to determine which identifier to use for a specific purpose.

Allows users to make use of identifiers when the identifier system is not known.

This element deals only with general categories of identifiers. It SHOULD not be used for codes that correspond 1..1 with the Identifier.system. Some identifiers may fall into multiple categories due to common usage.

Where the system is known, a type is unnecessary because the type is always part of the system definition. However systems often need to handle identifiers where the system is not known. There is not a 1:1 relationship between type and system, since many different systems have the same type.

Establishes the namespace for the value - that is, a URL that describes a set values that are unique.

There are many sets of identifiers. To perform matching of two identifiers, we need to know what set we're dealing with. The system identifies a particular set of unique identifiers.

see http://en.wikipedia.org/wiki/Uniform_resource_identifier

The portion of the identifier typically relevant to the user and which is unique within the context of the system.

If the value is a full URI, then the system SHALL be urn:ietf:rfc:3986. The value's primary purpose is computational mapping. As a result, it may be normalized for comparison purposes (e.g. removing non-significant whitespace, dashes, etc.) A value formatted for human display can be conveyed using the Rendered Value extension.

Time period during which identifier is/was valid for use.

This is not a duration - that's a measure of time (a separate type), but a duration that occurs at a fixed value of time. A Period specifies a range of time; the context of use will specify whether the entire range applies (e.g. "the patient was an inpatient of the hospital for this time range") or one value from the range applies (e.g. "give to the patient between these two times"). If duration is required, specify the type as Interval|Duration.

This field determines the status of the 'patient' record in the context of the organization that owns the record. Note that the record is not the medical record, but rather the actual patient 'resource'. Obviously when the patient 'resource' is not active, then by extension his medical record might also be inactive. Patient.active='false' may be used discourage use of the record, but that it is kept beause there is (medical) data attached to it. Another use case is a patient moving to a different GP practice. Patient.active would be 'false' in the system of the previous GP.

Need to be able to mark a patient record as not to be used because it was created in error.

Default is true. If a record is inactive, and linked to an active record, then future patient/record updates should occur on the other patient

This element is labeled as a modifier because when the patient record is marked as not active it is not expected to be used/referenced without being changed back to active.

A human's name with the ability to identify parts and usage.

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

Dutch names require that certain name parts are separately communicable. For this reason, extensions are added onto the base HumanName element to mark the meaning of each part. A Dutch HumanName is still a proper FHIR HumanName; however, there might be an incompatibilty with the default FHIR mechanism for communicating given names. See the compatibility note below for more information.

The extension elements cover birth name (NL: eigennaam / geslachtsnaam) and partner/spouse name. Both may have a prefix (NL: voorvoegsel). When a person marries, he or she may keep their own name, assume the partner name, append the partner name to their own name, or the other way around.

Incompatibility note: It has come to light that this specification deviates from the way that the HumanName datatype is normally used. This will be fixed in a future release. However, current implementations should be aware of the special considerations regarding the use of this specification.

The issue at hand is the way alternative representations of a name, like initials or a nickname, are communicated. Normally this is done using multiple HumanName instances, which are differentiated using the .use element. However, this specification allows for including all alternative representations in the same HumanName instance, with the expectation that the extensions provide enough information for recieving systems to differentiate them. However, this means that contrary to the normal usage of this datatype, repetitions of .given names cannot be concatenated to get the full list of given names; the list might be a mix of full names, nicknames and initials.

Since multiple implementations are based on this specification, sending systems are advised (but not required) to keep the approach with one HumanName instance, while recieving systems should be able to handle this one-instance approach. More specifically:

• Sending and recieving systems SHOULD always use the specified extensions when using this datatype.
• Sending systems are encouraged to populate the .text element to unambigiously communicate the patient name.
• Sending systems are encouraged to send either the full given names or the initials, but not both. This alleviates the duplication of names in .given.
• When a sending system uses the current one-instance approach for communicating multiple representations, .use MAY NOT be populated. After all, it is not possible to select a single .use when the instance contains different representations.
• When a recieving system interprets the instance as the single-instance-multiple-representations approach, the .given names marked as initials SHOULD be interpreted as alternatives to the full given names. Note the underlying HCIM expects both the list of full names and list of initials to be a single string; there's no match for an initial to a full name. The instance SHOULD be regarded as using this approach when:
  • They encounter a single instance
  • And the .use element is absent
  • And all the name parts are differentiated using the specified extensions
• In any other circumstance, recieving systems SHOULD interpret the usage as the normal use.

Example: miss Irma Jongeneel marries mister de Haas and assumes the name Irma Jongeneel-de Haas:

• .family = "Jongeneel-de Haas"
• .given = "Irma" (with .given:iso21090EnQualifier = BR)
• .family:humannameOwnName = "Jongeneel"
• .family:humannamePartnerPrefix = "de "
• .family:humannamePartnerName = "Haas"

A contact detail for the individual. Note that there is no support for multiple use values like 'mobile business'.

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

A Patient may have multiple ways to be contacted with different uses or applicable periods. May need to have options for contacting the person urgently and also to help with identification. The address may not go directly to the individual, but may reach another party that is able to proxy for the patient (i.e. home phone, or pet owner's phone).

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.

Value of extension - may be a resource or one of a constrained set of the data types (see Extensibility in the spec for list).

A stream of bytes, base64 encoded

The date of birth for the individual.

Age of the individual drives many clinical processes.

At least an estimated year should be provided as a guess if the real DOB is unknown There is a standard extension "patient-birthTime" available that should be used where Time is required (such as in maternaty/infant care systems).

This datatype defines a common basis for expressing all addresses around the world, but adds extensions to express Dutch addresses specifically, according to the HCIM AddressInformation (v1.0, 2017). 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 HCIM 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 HCIM 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 HCIM code itself should also be included using the AddressType extension.

     | HCIM                              | .ext:AddressType | .ext:official | .use | .type    |

     |-----------------------------------|------------------|---------------|------|----------|

     | Postal Address/Postadres          | PST              |               |      | postal   |

     | Primary Home/Officieel adres      | HP               | true          | home |          |

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

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

Note: address is for postal addresses, not physical locations.

This field contains a patient's most recent marital (civil) status. A person’s marital status according to the terms and definition in the Dutch civil code.

Most, if not all systems capture it.

Not all terminology uses fit this general pattern. In some cases, models should not use CodeableConcept and use Coding directly and provide their own structure for managing text, codings, translations and the relationship between elements and pre- and post-coordination.

Image of the patient.

Many EHR systems have the capability to capture an image of the patient. Fits with newer social media usage too.

When providing a summary view (for example with Observation.value[x]) Attachment should be represented with a brief display text such as "Attachment".

The nature of the relationship between the patient and the contact person.

Used to determine which contact person is the most relevant to approach, depending on circumstances.

Not all terminology uses fit this general pattern. In some cases, models should not use CodeableConcept and use Coding directly and provide their own structure for managing text, codings, translations and the relationship between elements and pre- and post-coordination.

Expectation is to have at least one of primary contact ('Eerste relatie/contactpersoon') or secondary contact ('Tweede relatie/contactpersoon')

Used to determine which contact person is the most relevant to approach, depending on circumstances.

Not all terminology uses fit this general pattern. In some cases, models should not use CodeableConcept and use Coding directly and provide their own structure for managing text, codings, translations and the relationship between elements and pre- and post-coordination.

A human's name with the ability to identify parts and usage.

Contact persons need to be identified by name, but it is uncommon to need details about multiple other names for that contact person.

Dutch names require that certain name parts are separately communicable. For this reason, extensions are added onto the base HumanName element to mark the meaning of each part. A Dutch HumanName is still a proper FHIR HumanName; however, there might be an incompatibilty with the default FHIR mechanism for communicating given names. See the compatibility note below for more information.

The extension elements cover birth name (NL: eigennaam / geslachtsnaam) and partner/spouse name. Both may have a prefix (NL: voorvoegsel). When a person marries, he or she may keep their own name, assume the partner name, append the partner name to their own name, or the other way around.

Incompatibility note: It has come to light that this specification deviates from the way that the HumanName datatype is normally used. This will be fixed in a future release. However, current implementations should be aware of the special considerations regarding the use of this specification.

The issue at hand is the way alternative representations of a name, like initials or a nickname, are communicated. Normally this is done using multiple HumanName instances, which are differentiated using the .use element. However, this specification allows for including all alternative representations in the same HumanName instance, with the expectation that the extensions provide enough information for recieving systems to differentiate them. However, this means that contrary to the normal usage of this datatype, repetitions of .given names cannot be concatenated to get the full list of given names; the list might be a mix of full names, nicknames and initials.

Since multiple implementations are based on this specification, sending systems are advised (but not required) to keep the approach with one HumanName instance, while recieving systems should be able to handle this one-instance approach. More specifically:

• Sending and recieving systems SHOULD always use the specified extensions when using this datatype.
• Sending systems are encouraged to populate the .text element to unambigiously communicate the patient name.
• Sending systems are encouraged to send either the full given names or the initials, but not both. This alleviates the duplication of names in .given.
• When a sending system uses the current one-instance approach for communicating multiple representations, .use MAY NOT be populated. After all, it is not possible to select a single .use when the instance contains different representations.
• When a recieving system interprets the instance as the single-instance-multiple-representations approach, the .given names marked as initials SHOULD be interpreted as alternatives to the full given names. Note the underlying HCIM expects both the list of full names and list of initials to be a single string; there's no match for an initial to a full name. The instance SHOULD be regarded as using this approach when:
  • They encounter a single instance
  • And the .use element is absent
  • And all the name parts are differentiated using the specified extensions
• In any other circumstance, recieving systems SHOULD interpret the usage as the normal use.

Example: miss Irma Jongeneel marries mister de Haas and assumes the name Irma Jongeneel-de Haas:

• .family = "Jongeneel-de Haas"
• .given = "Irma" (with .given:iso21090EnQualifier = BR)
• .family:humannameOwnName = "Jongeneel"
• .family:humannamePartnerPrefix = "de "
• .family:humannamePartnerName = "Haas"

Contact information includes a person's telephone numbers and email addresses. This datatype defines a common basis for expressing all contact information around the world, but adds extensions to express Dutch contacts specifically, according to the HCIM ContactInformation (v1.0, 2017). A Dutch ContactPoint still is a proper FHIR ContactPoint, which means that systems that cannot interpret the extensions will still be able to render and work with this datatype. The table below explains how the HCIM concepts are mapped to the various FHIR elements. The HCIM code itself should also be included using the TelecomType extension.

     | HCIM                                               | .ext:TelecomType | .system | .use   |
     |----------------------------------------------------|------------------|---------|--------|
     | Primary Home Land Line                             | LL               | phone   | home   |
     | Temporary Land Line                                | LL               | phone   | temp   |
     | Primary Work Land Line                             | LL               | phone   | work   |
     |                                                    |                  |         |        |
     | Primary Home Fax                                   | FAX              | fax     | home   |
     | Temporary Fax                                      | FAX              | fax     | temp   |
     | Primary Work Fax                                   | FAX              | fax     | work   |
     |                                                    |                  |         |        |
     | Primary Home Mobile Phone                          | MC               | phone   | home   |
     | Temporary Mobile Phone                             | MC               | phone   | temp   |
     | Primary Work Mobile Phone                          | MC               | phone   | work   |
     |                                                    |                  |         |        |
     | Primary Home Pager                                 | PG               | pager   | home   |
     | Temporary Pager                                    | PG               | pager   | temp   |
     | Primary Work Pager                                 | PG               | pager   | work   |
     |                                                    |                  |         |        |
     | Private email address                              |                  | email   | home   |
     | Work email address                                 |                  | email   | work   |
     |                                                    |                  |         |        |
     | Mobile phone number undetermined private/business  |                  | phone   | mobile |

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

Telecommunication data details (phone/email) is physically modeled in the HCIM Patient, which is why the telecommunication mappings appear to be coming from the HCIM Patient instead of the HCIM ContactPerson

This datatype defines a common basis for expressing all addresses around the world, but adds extensions to express Dutch addresses specifically, according to the HCIM AddressInformation (v1.0, 2017). 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 HCIM 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 HCIM 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 HCIM code itself should also be included using the AddressType extension.

     | HCIM                              | .ext:AddressType | .ext:official | .use | .type    |

     |-----------------------------------|------------------|---------------|------|----------|

     | Postal Address/Postadres          | PST              |               |      | postal   |

     | Primary Home/Officieel adres      | HP               | true          | home |          |

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

Need to keep track where the contact person can be contacted per postal mail or visited.

Note: address is for postal addresses, not physical locations.

Administrative Gender - the gender that the contact person is considered to have for administration and record keeping purposes.

Needed to address the person correctly.

Note that FHIR strings may not exceed 1MB in size

A reference to a location at which the other resource is found. The reference may be a relative reference, in which case it is relative to the service base URL, or an absolute URL that resolves to the location where the resource is found. The reference may be version specific or not. If the reference is not to a FHIR RESTful server, then it should be assumed to be version specific. Internal fragment references (start with '#') refer to contained resources.

Using absolute URLs provides a stable scalable approach suitable for a cloud/web context, while using relative/logical references provides a flexible approach suitable for use when trading across closed eco-system boundaries. Absolute URLs do not need to point to a FHIR RESTful server, though this is the preferred approach. If the URL conforms to the structure "/[type]/[id]" then it should be assumed that the reference is to a FHIR RESTful server.

The purpose of this identifier.

Allows the appropriate identifier for a particular context of use to be selected from among a set of identifiers.

This is labeled as "Is Modifier" because applications should not mistake a temporary id for a permanent one. Applications can assume that an identifier is permanent unless it explicitly says that it is temporary.

A coded type for the identifier that can be used to determine which identifier to use for a specific purpose.

Allows users to make use of identifiers when the identifier system is not known.

This element deals only with general categories of identifiers. It SHOULD not be used for codes that correspond 1..1 with the Identifier.system. Some identifiers may fall into multiple categories due to common usage.

Where the system is known, a type is unnecessary because the type is always part of the system definition. However systems often need to handle identifiers where the system is not known. There is not a 1:1 relationship between type and system, since many different systems have the same type.

Establishes the namespace for the value - that is, a URL that describes a set values that are unique.

There are many sets of identifiers. To perform matching of two identifiers, we need to know what set we're dealing with. The system identifies a particular set of unique identifiers.

see http://en.wikipedia.org/wiki/Uniform_resource_identifier

The portion of the identifier typically relevant to the user and which is unique within the context of the system.

If the value is a full URI, then the system SHALL be urn:ietf:rfc:3986. The value's primary purpose is computational mapping. As a result, it may be normalized for comparison purposes (e.g. removing non-significant whitespace, dashes, etc.) A value formatted for human display can be conveyed using the Rendered Value extension.

Time period during which identifier is/was valid for use.

This is not a duration - that's a measure of time (a separate type), but a duration that occurs at a fixed value of time. A Period specifies a range of time; the context of use will specify whether the entire range applies (e.g. "the patient was an inpatient of the hospital for this time range") or one value from the range applies (e.g. "give to the patient between these two times"). If duration is required, specify the type as Interval|Duration.

Organization that issued/manages the identifier.

The Identifier.assigner may omit the .reference element and only contain a .display element reflecting the name or other textual information about the assigning organization.

Plain text narrative that identifies the resource in addition to the resource reference.

This is generally not the same as the Resource.text of the referenced resource. The purpose is to identify what's being referenced, not to fully describe it.

The period during which this contact person or organization is valid to be contacted relating to this patient.

This is not a duration - that's a measure of time (a separate type), but a duration that occurs at a fixed value of time. A Period specifies a range of time; the context of use will specify whether the entire range applies (e.g. "the patient was an inpatient of the hospital for this time range") or one value from the range applies (e.g. "give to the patient between these two times"). If duration is required, specify the type as Interval|Duration.

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.

Value of extension - may be a resource or one of a constrained set of the data types (see Extensibility in the spec for list).

A stream of bytes, base64 encoded

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.

Value of extension - may be a resource or one of a constrained set of the data types (see Extensibility in the spec for list).

A stream of bytes, base64 encoded

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.

Optional Extension Element - found in all resources.

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.

The language of communication.

The ISO-639-1 alpha 2 code in lower case for the language, optionally followed by a hyphen and the ISO-3166-1 alpha 2 code for the region in upper case; e.g. "en" for English, or "en-US" for American English versus "en-EN" for England English.

Most systems in multilingual countries will want to convey language. Not all systems actually need the regional dialect.

The FHIR valueset http://hl7.org/fhir/valueset-languages.html is used instead of the ZIB valueset CommunicationLanguageCodelist. The FHIR valueset uses the codesystem urn:ietf:bcp:47 which includes the ISO-639-2 alpha codesystem used by the ZIB valueset.

Indicates whether or not the patient prefers this language (over other languages he masters up a certain level).

People that master multiple languages up to certain level may prefer one or more, i.e. feel more confident in communicating in a particular language making other languages sort of a fall back method.

This language is specifically identified for communicating healthcare information.

Optional Extension Element - found in all resources.

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.

A reference to a location at which the other resource is found. The reference may be a relative reference, in which case it is relative to the service base URL, or an absolute URL that resolves to the location where the resource is found. The reference may be version specific or not. If the reference is not to a FHIR RESTful server, then it should be assumed to be version specific. Internal fragment references (start with '#') refer to contained resources.

Using absolute URLs provides a stable scalable approach suitable for a cloud/web context, while using relative/logical references provides a flexible approach suitable for use when trading across closed eco-system boundaries. Absolute URLs do not need to point to a FHIR RESTful server, though this is the preferred approach. If the URL conforms to the structure "/[type]/[id]" then it should be assumed that the reference is to a FHIR RESTful server.