This material contains content that is copyright of SNOMED International. Implementers of these specifications must have the appropriate SNOMED CT Affiliate license - for more information contact https://www.snomed.org/get-snomed
or info@snomed.org
.
Advance Care Planning (PZP), published by IKNL. This guide is not an authorized publication; it is the continuous build for version 1.0.0-rc1 built by the FHIR (HL7® FHIR® Standard) CI Build. This version is based on the current content of https://github.com/IKNL/PZP-FHIR-R4/ and changes regularly. See the Directory of published versions ( src
)
Code of Federal Regulation 21CFR§1271.290(c) ( src
)
Copyright/Legal: This artefact includes content from SNOMED Clinical Terms® (SNOMED CT®) which is copyright of the International Health Terminology Standards Development Organisation (IHTSDO). Implementers of these artefacts must have the appropriate SNOMED CT Affiliate license - for more information contact http://www.snomed.org/snomed-ct/getsnomed-ct or info@snomed.org. ( src
)
Advance Care Planning (PZP), published by IKNL. This guide is not an authorized publication; it is the continuous build for version 1.0.0-rc1 built by the FHIR (HL7® FHIR® Standard) CI Build. This version is based on the current content of https://github.com/IKNL/PZP-FHIR-R4/
and changes regularly. See the Directory of published versions
Either .policy
or .policyRule
should exist following core constraint ppc-1. If no explicit value is recorded, a fallback is to populate .policy.uri
with https://wetten.overheid.nl/
if the advance directive is recorded following Dutch law and regulations.
The codes SHALL be taken from The codes SHOULD be taken from RolCodelijst (2020-09-01T00:00:00)http://hl7.org/fhir/ValueSet/relatedperson-relationshiptype|4.0.1
( required
to http://decor.nictiz.nl/fhir/ValueSet/2.16.840.1.113883.2.4.3.11.60.40.2.3.1.2--20200901000000|2020-09-01T00:00:00
)
The codes SHALL be taken from The codes SHOULD be taken from RelatieCodelijst (2020-09-01T00:00:00)http://hl7.org/fhir/ValueSet/relatedperson-relationshiptype|4.0.1
( required
to http://decor.nictiz.nl/fhir/ValueSet/2.16.840.1.113883.2.4.3.11.60.40.2.3.1.1--20200901000000|2020-09-01T00:00:00
)
This .name
element accomodates the official parts of a Dutch name according to common international usage and optionally to the zib NameInformation v1.1 (2020)
. An official Dutch name is represented in FHIR as an ordinary international name, optionally augmented using extensions to specify how the last name is built up according to the Dutch rules if conformance to the zib is required. See the guidance on .family
and on .extension:nameUsage
for more information.
The codes SHALL be taken from For codes, see TelecomTypeCodelijst (2020-09-01T00:00:00)
( required
to http://decor.nictiz.nl/fhir/ValueSet/2.16.840.1.113883.2.4.3.11.60.40.2.20.6.1--20200901000000|2020-09-01T00:00:00
)
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.
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
.
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
.
The codes SHALL be taken from RolCodelijst (2020-09-01T00:00:00)
( required
to http://decor.nictiz.nl/fhir/ValueSet/2.16.840.1.113883.2.4.3.11.60.40.2.3.1.2--20200901000000|2020-09-01T00:00:00
)
The codes SHALL be taken from RelatieCodelijst (2020-09-01T00:00:00)
( required
to http://decor.nictiz.nl/fhir/ValueSet/2.16.840.1.113883.2.4.3.11.60.40.2.3.1.1--20200901000000|2020-09-01T00:00:00
)
The codes SHALL be taken from TelecomTypeCodelijst (2020-09-01T00:00:00)
( required
to http://decor.nictiz.nl/fhir/ValueSet/2.16.840.1.113883.2.4.3.11.60.40.2.20.6.1--20200901000000|2020-09-01T00:00:00
)
The codes SHALL be taken from LandCodelijsten (2020-09-01T00:00:00)
( required
to http://decor.nictiz.nl/fhir/ValueSet/2.16.840.1.113883.2.4.3.11.60.121.11.10--20200901000000|2020-09-01T00:00:00
)
Unless not suitable, these codes SHALL be taken from ZorgverlenerRolCodelijst (2020-09-01T00:00:00)http://hl7.org/fhir/ValueSet/encounter-participant-type|4.0.1
( extensible
to http://decor.nictiz.nl/fhir/ValueSet/2.16.840.1.113883.2.4.3.11.60.40.2.17.1.5--20200901000000|2020-09-01T00:00:00
)
Each occurrence of the zib HealthProfessional is normally represented by two
FHIR resources: a PractitionerRole resource (instance of nl-core-HealthProfessional-PractitionerRole
) and a Practitioner resource (instance of nl-core-HealthProfessional-Practitioner
). The Practitioner resource is referenced from the PractitionerRole instance. For this reason, sending systems should fill the reference to the PractitionerRole instance here, and not the Practitioner resource. Receiving systems can then retrieve the reference to the Practitioner resource from that PractitionerRole instance.
Each occurrence of the zib HealthProfessional is normally represented by two
FHIR resources: a PractitionerRole resource (instance of nl-core-HealthProfessional-PractitionerRole
) and a Practitioner resource (instance of nl-core-HealthProfessional-Practitioner
). The Practitioner resource is referenced from the PractitionerRole instance. For this reason, sending systems should fill the reference to the PractitionerRole instance here, and not the Practitioner resource. Receiving systems can then retrieve the reference to the Practitioner resource from that PractitionerRole instance.
Unless not suitable, these codes SHALL be taken from ZorgverlenerRolCodelijst (2020-09-01T00:00:00)
( extensible
to http://decor.nictiz.nl/fhir/ValueSet/2.16.840.1.113883.2.4.3.11.60.40.2.17.1.5--20200901000000|2020-09-01T00:00:00
)
Unless not suitable, these codes SHALL be taken from HerkomstCodelijst (2020-09-01T00:00:00)
( extensible
to http://decor.nictiz.nl/fhir/ValueSet/2.16.840.1.113883.2.4.3.11.60.40.2.15.1.2--20200901000000|2020-09-01T00:00:00
)
Unless not suitable, these codes SHALL be taken from BestemmingCodelijst (2020-09-01T00:00:00)
( extensible
to http://decor.nictiz.nl/fhir/ValueSet/2.16.840.1.113883.2.4.3.11.60.40.2.15.1.3--20200901000000|2020-09-01T00:00:00
)
The zib HealthProfessional is mapped for all but one concept (HealthProfessionalRole) to this Practitioner profile and a profile on PractitionerRole ( http://nictiz.nl/fhir/StructureDefinition/nl-core-HealthProfessional-PractitionerRole
). The PractitionerRole resource covers the recording of the location and types of services that HealthProfessionals are able to provide for a HealthcareProvider. The zib concepts Specialty and HealthcareProvider are therefore mapped onto PractitionerRole.
The codes SHALL be taken from GeslachtCodelijst (2020-09-01T00:00:00)
( required
to http://decor.nictiz.nl/fhir/ValueSet/2.16.840.1.113883.2.4.3.11.60.40.2.17.1.8--20200901000000|2020-09-01T00:00:00
)
The zib HealthProfessional is mapped for all but one concept (HealthProfessionalRole) to a profile on Practitioner ( http://nictiz.nl/fhir/StructureDefinition/nl-core-HealthProfessional-Practitioner
) and this PractitionerRole profile. The PractitionerRole resource covers the recording of the location and types of services that HealthProfessionals are able to provide for a HealthcareProvider. The zib concepts Specialty and HealthcareProvider are therefore mapped onto PractitionerRole.
The codes SHALL be taken from The codes SHOULD be taken from SpecialismeCodelijsten (2020-09-01T00:00:00)http://hl7.org/fhir/ValueSet/c80-practice-codes|4.0.1
( required
to http://decor.nictiz.nl/fhir/ValueSet/2.16.840.1.113883.2.4.3.11.60.121.11.22--20200901000000|2020-09-01T00:00:00
)
Please note that this zib concept (Location::HealthcareProvider) is also mapped on the Procedure.location
element in profile nl-core-Procedure-event
. The reason for this is that this zib concept aligns with the Location::HealthcareProvider concept in zib Procedure (NL-CM:14.1.5), but only for the situation that the Procedure is about placing the implant which is described using this instance of zib MedicalDevice. In this situation, the current extension is redundant and it is advised to only use Procedure.location
in profile nl-core-Procedure-event to represent the Location concept.
Both zib TreatmentObjective and the desired zib FunctionalOrMentalStatus are represented using the nl-core-TreatmentObjective
profile on the Goal resource.
The codes SHALL be taken from For example codes, see LocatieCodelijsten (2020-09-01T00:00:00)http://hl7.org/fhir/ValueSet/body-site|4.0.1
( required
to http://decor.nictiz.nl/fhir/ValueSet/2.16.840.1.113883.2.4.3.11.60.121.11.11--20200901000000|2020-09-01T00:00:00
)
The codes SHALL be taken from For codes, see LateraliteitCodelijst (2020-09-01T00:00:00)
( required
to http://decor.nictiz.nl/fhir/ValueSet/2.16.840.1.113883.2.4.3.11.60.40.2.20.7.2--20200901000000|2020-09-01T00:00:00
)
The codes SHALL be taken from LocatieCodelijsten (2020-09-01T00:00:00)
( required
to http://decor.nictiz.nl/fhir/ValueSet/2.16.840.1.113883.2.4.3.11.60.121.11.11--20200901000000|2020-09-01T00:00:00
)
The codes SHALL be taken from LateraliteitCodelijst (2020-09-01T00:00:00)
( required
to http://decor.nictiz.nl/fhir/ValueSet/2.16.840.1.113883.2.4.3.11.60.40.2.20.7.2--20200901000000|2020-09-01T00:00:00
)
In all cases the full identifier will be populated in .identifier
. If the identifier is a UDI in particular, it should also be populated in udiCarrier.carrierHRF
, and the element udiCarrier.issuer
is used to indicate which 'coding system' is used. Moreover the identifier may be broken down into several parts in that case, namely .udiCarrier.deviceIdentifier
, .manufactureDate
, .expirationDate
, .lotNumber
and .serialNumber
. For GTIN, guidance is given at the respective elements in this profile and is based on https://www.gs1.org/industries/healthcare/udi
. For HIBC please consult the the Supplier Labeling Standard that can be found at https://www.hibcc.org/udi-labeling-standards/barcode-standards/
, as conversion into the several parts is less straightforward.
In all cases the full identifier will be populated in .identifier
. If the identifier is a UDI in particular, it should also be populated in udiCarrier.carrierHRF
, and the element udiCarrier.issuer
is used to indicate which 'coding system' is used. Moreover the identifier may be broken down into several parts in that case, namely .udiCarrier.deviceIdentifier
, .manufactureDate
, .expirationDate
, .lotNumber
and .serialNumber
. For GTIN, guidance is given at the respective elements in this profile and is based on https://www.gs1.org/industries/healthcare/udi
. For HIBC please consult the the Supplier Labeling Standard that can be found at https://www.hibcc.org/udi-labeling-standards/barcode-standards/
, as conversion into the several parts is less straightforward.
Unless not suitable, these codes SHALL be taken from For codes, see NationaliteitCodelijst (2020-09-01T00:00:00)
( extensible
to http://decor.nictiz.nl/fhir/ValueSet/2.16.840.1.113883.2.4.3.11.60.40.2.7.6.3--20200901000000|2020-09-01T00:00:00
)
The codes SHALL be taken from For codes, see GeslachtCodelijst (2020-09-01T00:00:00)
( required
to http://decor.nictiz.nl/fhir/ValueSet/2.16.840.1.113883.2.4.3.11.60.40.2.0.1.1--20200901000000|2020-09-01T00:00:00
)
The codes SHALL be taken from Unless not suitable, these codes SHALL be taken from RolCodelijst (2020-09-01T00:00:00)http://hl7.org/fhir/ValueSet/patient-contactrelationship|4.0.1
( required
to http://decor.nictiz.nl/fhir/ValueSet/2.16.840.1.113883.2.4.3.11.60.40.2.3.1.2--20200901000000|2020-09-01T00:00:00
)
The codes SHALL be taken from Unless not suitable, these codes SHALL be taken from RelatieCodelijst (2020-09-01T00:00:00)http://hl7.org/fhir/ValueSet/patient-contactrelationship|4.0.1
( required
to http://decor.nictiz.nl/fhir/ValueSet/2.16.840.1.113883.2.4.3.11.60.40.2.3.1.1--20200901000000|2020-09-01T00:00:00
)
Unless not suitable, these codes SHALL be taken from NationaliteitCodelijst (2020-09-01T00:00:00)
( extensible
to http://decor.nictiz.nl/fhir/ValueSet/2.16.840.1.113883.2.4.3.11.60.40.2.7.6.3--20200901000000|2020-09-01T00:00:00
)
The codes SHALL be taken from GeslachtCodelijst (2020-09-01T00:00:00)
( required
to http://decor.nictiz.nl/fhir/ValueSet/2.16.840.1.113883.2.4.3.11.60.40.2.0.1.1--20200901000000|2020-09-01T00:00:00
)
This element can and should not completely capture the AddressInformation concept from zib ContactPerson; it should just be used for the information that is needed for contacting the person in relation to care of the patient. The full address information should instead be captured using an instance of nl-core-ContactPerson
, which can then be referenced from this resource. See the comment on Patient.contact
for more information.
The zib Procedure is mapped both to this Procedure profile and a profile on ServiceRequest ( http://nictiz.nl/fhir/StructureDefinition/nl-core-Procedure-request
) to align with the intention of FHIR. All past procedures are covered using this Procedure resource, while all future procedures, including the advised procedures, are covered in the ServiceRequest resource. Both resources contain the zib mappings, with the exception of the Requester concept; this is not relevant for past procedures and has only been mapped to the ServiceRequest profile.
The codes SHALL be taken from For example codes, see VerrichtingTypeCodelijsten (2020-09-01T00:00:00)http://hl7.org/fhir/ValueSet/procedure-code|4.0.1
( required
to http://decor.nictiz.nl/fhir/ValueSet/2.16.840.1.113883.2.4.3.11.60.121.11.19--20200901000000|2020-09-01T00:00:00
)
Please note that the zib concept Location::HealthcareProvider of zib MedicalDevice (NL-CM:10.1.8) is mapped onto this element, but it is also directly represented using a custom extension in the focal profile for that zib ( nl-core-MedicalDevice
). The reason for this is that the Location concept from zib MedicalDevice aligns with the Location concept from zib Procedure, but only for the situation that the Procedure is about placing an implant which is described using the instance of zib MedicalDevice. In this situation, the extension in the nl-core-MedicalDevice profile is redundant and it is advised to only use the current element to represent the Location concept.
Either .policy
or .policyRule
should exist following core constraint ppc-1. If no explicit value is recorded, a fallback is to populate .policy.uri
with https://wetten.overheid.nl/
if the treatment directive is recorded following Dutch law and regulations.
The codes SHALL be taken from BehandelingCodelijst (2020-09-01T00:00:00)
( required
to http://decor.nictiz.nl/fhir/ValueSet/2.16.840.1.113883.2.4.3.11.60.40.2.2.2.1--20200901000000|2020-09-01T00:00:00
)
This extension is based on the extension FreedomRestrictingIntervention.LegallyCapable
, but is adapted for the ACP context by allowing its use on the Patient resource and specifying its application to treatment decisions.
First, ICD codes cannot be added to Consent.provision.code
due to binding constraints, so the mapping is placed in Consent.provision.code.text
with OTH
as the code. A zib ticket ( ZIB-2796
) has been created to address this issue.
