Canonical intermediate logical model for Patient translation. It is shaped to the full Patient core structure, aligned with eu-base as the structural baseline, and extended with Dutch zib and nl-core patient semantics using future-oriented normalized field names.

Unique id for the element within a resource (for internal references). This may be any string value that does not contain spaces.

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.

Source profile used to populate this logical model.

Target profile intended for this logical model instance.

Canonical URL of a source-side profile-specific extension or profile element preserved by this logical model.

Serialized source-side profile-specific extension or profile element payload when it cannot be represented by the generic R4 base shape.

Canonical URL of a target-side profile-specific extension or profile element preserved by this logical model.

Serialized target-side profile-specific extension or profile element payload when it cannot be represented by the generic R4 base shape.

Profile-specific extension data carried explicitly by the logical model alongside the normalized R4 payload.

Dutch BSN identifier when present as the dedicated patient identifier.

Patient identifiers.

Whether the patient record is active.

Contained resources needed by local references preserved from the source patient.

Patient names.

Patient photos.

Preferred pharmacy reference when carried on the BgZ patient source.

Patient contact points.

Patient telephone contact points.

Patient email contact points.

Administrative gender.

Additional Dutch coding for administrative gender when present.

Date of birth.

Whether the patient is deceased.

Date and time of death when recorded.

Patient addresses.

Formal marital or civil status.

Whether the patient is part of a multiple birth.

Birth order within a multiple birth when recorded as a number.

Country of citizenship or nationality with optional associated period.

Legal status when carried on the BgZ patient source.

Life stance when carried on the BgZ patient source.

PZP legal capability for medical treatment decisions, preserved as the profile-specific extension.

Communication and language proficiency information.

Contact person information.

General practitioner or responsible health professional reference.

PractitionerRole references carried through the Dutch STU3 practitioner-role reference extension.

Organization that manages the patient record.

Links to other patient or related person records.

Canonical intermediate logical model for Patient translation. It is shaped to the full Patient core structure, aligned with eu-base as the structural baseline, and extended with Dutch zib and nl-core patient semantics using future-oriented normalized field names.

Source profile used to populate this logical model.

Target profile intended for this logical model instance.

Canonical URL of a source-side profile-specific extension or profile element preserved by this logical model.

Serialized source-side profile-specific extension or profile element payload when it cannot be represented by the generic R4 base shape.

Canonical URL of a target-side profile-specific extension or profile element preserved by this logical model.

Serialized target-side profile-specific extension or profile element payload when it cannot be represented by the generic R4 base shape.

Profile-specific extension data carried explicitly by the logical model alongside the normalized R4 payload.

Dutch BSN identifier when present as the dedicated patient identifier.

Patient identifiers.

Whether the patient record is active.

Contained resources needed by local references preserved from the source patient.

Patient names.

Patient photos.

Preferred pharmacy reference when carried on the BgZ patient source.

Patient contact points.

Patient telephone contact points.

Patient email contact points.

Administrative gender.

Additional Dutch coding for administrative gender when present.

Date of birth.

Whether the patient is deceased.

Date and time of death when recorded.

Patient addresses.

Formal marital or civil status.

Whether the patient is part of a multiple birth.

Birth order within a multiple birth when recorded as a number.

Country of citizenship or nationality with optional associated period.

Legal status when carried on the BgZ patient source.

Life stance when carried on the BgZ patient source.

PZP legal capability for medical treatment decisions, preserved as the profile-specific extension.

Communication and language proficiency information.

Contact person information.

General practitioner or responsible health professional reference.

PractitionerRole references carried through the Dutch STU3 practitioner-role reference extension.

Organization that manages the patient record.

Links to other patient or related person records.

Canonical intermediate logical model for Patient translation. It is shaped to the full Patient core structure, aligned with eu-base as the structural baseline, and extended with Dutch zib and nl-core patient semantics using future-oriented normalized field names.

Unique id for the element within a resource (for internal references). This may be any string value that does not contain spaces.

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.

Source profile used to populate this logical model.

Target profile intended for this logical model instance.

Canonical URL of a source-side profile-specific extension or profile element preserved by this logical model.

Serialized source-side profile-specific extension or profile element payload when it cannot be represented by the generic R4 base shape.

Canonical URL of a target-side profile-specific extension or profile element preserved by this logical model.

Serialized target-side profile-specific extension or profile element payload when it cannot be represented by the generic R4 base shape.

Profile-specific extension data carried explicitly by the logical model alongside the normalized R4 payload.

Dutch BSN identifier when present as the dedicated patient identifier.

Patient identifiers.

Whether the patient record is active.

Contained resources needed by local references preserved from the source patient.

Patient names.

Patient photos.

Preferred pharmacy reference when carried on the BgZ patient source.

Patient contact points.

Patient telephone contact points.

Patient email contact points.

Administrative gender.

Additional Dutch coding for administrative gender when present.

Date of birth.

Whether the patient is deceased.

Date and time of death when recorded.

Patient addresses.

Formal marital or civil status.

Whether the patient is part of a multiple birth.

Birth order within a multiple birth when recorded as a number.

Country of citizenship or nationality with optional associated period.

Legal status when carried on the BgZ patient source.

Life stance when carried on the BgZ patient source.

PZP legal capability for medical treatment decisions, preserved as the profile-specific extension.

Communication and language proficiency information.

Contact person information.

General practitioner or responsible health professional reference.

PractitionerRole references carried through the Dutch STU3 practitioner-role reference extension.

Organization that manages the patient record.

Links to other patient or related person records.