http://fhir.nl/fhir/NamingSystem/uzi-rolcode
http://nuts-foundation.github.io/nl-generic-functions-ig/CodeSystem/nl-gf-data-exchange-capabilities
http://www.whocc.no/atc
urn:oid:2.16.840.1.113883.2.4.6.7
This fragment is not visible to the reader
This publication includes IP covered under the following statements.
Type | Reference | Content |
---|---|---|
web | tel:+3131599991 | contact : +3131599991 , info@nedap.example.org |
web | tel:+3131599991 | contact : +3131599991 , info@example.org |
web | tel:+3131599991 | contact : +3131599991 , info@cp1.example.org |
web | tel:+31301234567 | telecom : +31301234567 , info@organization3.nl |
web | tel:+3131599991 | telecom : +3131599991 , info@cp1.example.org |
web | tel:+31301234567 | telecom : +31301234567 , info@cp2.example.org |
web | tel:+31612345678 | +31612345678 |
web | tel:+31301234568 | telecom : +31301234568 , |
web | tel:+31301234568 | telecom : +31301234568 , john.doe@cp3.example.org , https://matrix.to/#doctorno:cp3.example.org |
web | matrix.to | telecom : +31301234568 , john.doe@cp3.example.org , https://matrix.to/#doctorno:cp3.example.org |
web | decor.nictiz.nl |
Type of service that may be delivered or performed
Binding: VerrichtingTypeCodelijsten ( required ) |
web | decor.nictiz.nl |
Specialties handled by the HealthcareService
Binding: SpecialismeCodelijsten ( required ) |
web | www.nuts.nl |
IG © 2025+ Stichting Nuts
. Package fhir.nl.gf#0.2.0 based on FHIR 4.0.1
. Generated 2025-10-17
Links: Table of Contents | QA Report |
web | decor.nictiz.nl |
The codes SHALL be taken from For example codes, see
VerrichtingTypeCodelijsten
http://hl7.org/fhir/ValueSet/service-type|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
)
|
web | decor.nictiz.nl |
The codes SHALL be taken from The codes SHOULD be taken from
SpecialismeCodelijsten
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
)
|
web | decor.nictiz.nl |
The codes SHALL be taken from VerrichtingTypeCodelijsten
( required to http://decor.nictiz.nl/fhir/ValueSet/2.16.840.1.113883.2.4.3.11.60.121.11.19--20200901000000
)
|
web | decor.nictiz.nl |
The codes SHALL be taken from SpecialismeCodelijsten
( required to http://decor.nictiz.nl/fhir/ValueSet/2.16.840.1.113883.2.4.3.11.60.121.11.22--20200901000000
)
|
web | decor.nictiz.nl |
Type of service that may be delivered or performed Binding: VerrichtingTypeCodelijsten ( required ) |
web | decor.nictiz.nl |
Specialties handled by the HealthcareService Binding: SpecialismeCodelijsten ( required ) |
web | decor.nictiz.nl | VerrichtingTypeCodelijsten |
web | decor.nictiz.nl | SpecialismeCodelijsten |
web | nictiz.nl |
The zib HealthcareProvider is mapped to this Location profile and a profile on Organization ( http://nictiz.nl/fhir/StructureDefinition/nl-core-HealthcareProvider-Organization
). This Location profile acts as the focal resource of the HealthcareProvider because most references to this zib are concerned about the recording of the physical location where the care to patient/client takes place rather than the organizational information. For the latter, the profile on Organization is used which is referenced using the managingOrganization
element.
|
web | zibs.nl | 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. |
web | nictiz.nl |
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
.
|
web | nictiz.nl |
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
.
|
web | nictiz.nl | The zib HealthcareProvider is mapped to this Organization profile and a profile on Location ( http://nictiz.nl/fhir/StructureDefinition/nl-core-HealthcareProvider ). The Location profile acts as the focal resource of the HealthcareProvider because most references to this zib are concerned about the recording of the physical location where the care to patient/client takes place rather than the organizational information. Often there's no clear distinction between an organizational structure and a physical location. As a rule of thumb, locations are always used for recording where a service occurs, and hence where encounters and observations take place. |
web | decor.nictiz.nl |
The codes SHALL be taken from For example codes, see
AfdelingSpecialismeCodelijst
http://hl7.org/fhir/ValueSet/organization-type|4.0.1
( required to http://decor.nictiz.nl/fhir/ValueSet/2.16.840.1.113883.2.4.3.11.60.40.2.17.2.4--20200901000000
)
|
web | decor.nictiz.nl |
The codes SHALL be taken from For example codes, see
OrganisatieTypeCodelijst
http://hl7.org/fhir/ValueSet/organization-type|4.0.1
( required to http://decor.nictiz.nl/fhir/ValueSet/2.16.840.1.113883.2.4.3.11.60.40.2.17.2.3--20200901000000
)
|
web | decor.nictiz.nl |
The codes SHALL be taken from AfdelingSpecialismeCodelijst
( required to http://decor.nictiz.nl/fhir/ValueSet/2.16.840.1.113883.2.4.3.11.60.40.2.17.2.4--20200901000000
)
|
web | decor.nictiz.nl |
The codes SHALL be taken from OrganisatieTypeCodelijst
( required to http://decor.nictiz.nl/fhir/ValueSet/2.16.840.1.113883.2.4.3.11.60.40.2.17.2.3--20200901000000
)
|
web | zibs.nl |
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.
|
web | decor.nictiz.nl |
DepartmentSpecialty Binding: AfdelingSpecialismeCodelijst ( required ) : Used to categorize the organization. |
web | decor.nictiz.nl |
OrganizationType Binding: OrganisatieTypeCodelijst ( required ) : Used to categorize the organization. |
web | decor.nictiz.nl | AfdelingSpecialismeCodelijst |
web | decor.nictiz.nl | OrganisatieTypeCodelijst |
web | nictiz.nl | 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. |
web | zibs.nl |
This .name
element represents the Dutch given name ("roepnaam") according to the zib NameInformation v1.1 (2020)
.
|
web | decor.nictiz.nl |
The codes SHALL be taken from GeslachtCodelijst
( required to http://decor.nictiz.nl/fhir/ValueSet/2.16.840.1.113883.2.4.3.11.60.40.2.17.1.8--20200901000000
)
|
web | decor.nictiz.nl |
Value of extension Binding: GeslachtCodelijst ( required ) |
web | decor.nictiz.nl | GeslachtCodelijst |
web | nictiz.nl | 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. |
web | decor.nictiz.nl |
Specialty Binding: SpecialismeCodelijsten ( required ) : Specific specialty associated with the agency. |
web | profiles.ihe.net | GFA follows the IHE mCSD profile ( GF-Adressering, ADR-0 ). The mCSD profile provides multiple options for deployment. This guide specifies the choices made for The Netherlands. Most impactful/striking choice are: |
web | github.com | GFA follows the IHE mCSD profile ( GF-Adressering, ADR-0 ). The mCSD profile provides multiple options for deployment. This guide specifies the choices made for The Netherlands. Most impactful/striking choice are: |
web | github.com | An 'Update Client' uses the LRZa ( GF-Adressering, ADR-7 ) and the care provider Administration Directories to consolidate all data into a 'Query Directory.' |
web | github.com |
This overview implies a decentralized architecture for many components. An important central component is the LRZa Administration Directory. For more detail on the topology of GF Adressing, see GF-Adressering, ADR-5
. Each component, data model, and transaction will be discussed in more detail. |
web | github.com | The Administration Client of the LRZa provides a user interface for healthcare providers to administer their Administration Directory endpoint (URL).( GF-Adressering, ADR-10 and GF-Adressering, ADR#167 ) |
web | github.com | The Administration Client of the LRZa provides a user interface for healthcare providers to administer their Administration Directory endpoint (URL).( GF-Adressering, ADR-10 and GF-Adressering, ADR#167 ) |
web | github.com | The performance/availability requirements for an Administration Directory ( GF-Adressering, ADR#177 ): |
web | github.com | Besides using the 'history-type' operation, the Update Client should be able to query all instances in the Administration Directory using a search operation. Either for the initial load or periodically for a full reload to fix edge-case scenario's (e.g. Administration Directory backup restores). ( GF-Adressering, ADR-14 ) |
web | github.com | During consolidation, multiple Administration Directories may have overlapping or conflicting entities. An Update Client MUST only use data from authoritative data sources ( GF-Adressering, ADR#186 ) and MUST obey these guidelines: |
web | github.com |
After consolidation, the Update Client writes the updates to a Query Directory. For each instance, the meta.source
element is populated with the fully qualified URL of that instance at the originating Administration Directory ( GF-Adressering, ADR-6
). The Update Client MAY use the same interactions a Administration Client uses to register entities in an Administration Directory.
|
web | github.com | Within GF Addressing, profiles are used to validate data. They are based on both mCSD-profiles and nl-core-profiles (TODO: use Nictiz nl-core package as soon as dependency-bug is fixed)( GF-Adressering, ADR#188 ). Ideally, these profiles are merged in the nl-core-profiles in the future. An overview of the most common elements and relations between data models: |
web | github.com |
The NL-GF-Endpoints profile
has an extra value set constraint on .payloadType
( GF-Adressering, ADR-8
).
|
web | github.com | This resource type is out-of-scope for this IG-version (waiting for GF-Adressering, ADR#169 ) |
web | github.com | The service provider of an Administration Directory must require mTLS. Qualified certificates from Qualified Trusted Service Providers (like PKIoverheid) should be trusted. The service may also have a certificate policy that allows for other types of certificates (e.g. self-signed certificates) provided that -through policy- a sufficient level of trust in these certificates can be established. ( GF-Adressering, ADR#178 ) |
web | www.vektis.nl | Vektis-AGB is the authoritative source for the care provider type . GF Consent uses the Organization.type element, so it is important to use the authoritative source. |
web | www.bigregister.nl | BIG-register is the authoritative source for (a part of the) Physicians/Practitioners and their qualifications. |
web | github.com | The OrganizationAffiliation resource may be added in the future to publish relationships between organizations. ( GF-Adressering, ADR#169 ) |
web | github.com | GF-Localization follows the choices made by the MinvWS Localization working group, see GF-Lokalisatie, ADR's . This guide specifies the choices made. Most impactful/striking choice are: |
web | github.com | For more detail on the topology of GF-Localization, see GF-Lokalisatie, ADR-2 . Each component, data model, and transaction will be discussed in more detail. |
web | www.logius.nl | the receiver (of the request or response) exchanges the opaque value for a pseudonym at the Pseudonymization Service. This version of the IG will not go into the details of this Pseudonymization Service and the effect on FHIR transactions. For information on this topic, see the Logius BSNk-pp service . |
web | github.com | Within GF-Localization the NL-gf-localization-DocumentReference profile is used to register, search, and validate localization records ( NL-GF-IG, ADR#10 ). This data model basically states "Care provider X has data of type Y for Patient Z" . It contains the following elements: |
web | github.com | No ValueSet has been decided upon yet GF-Lokalisatie, ADR#62 , so in this IG-version, a fixed LOINC code '55188-7' is used: "Patient data Document" |
web | github.com | The initial implementation uses plain BSN (Burgerservicenummer) for simplicity. In a later stage, this will be replaced with pseudo-BSNs to enhance patient privacy. The pseudonymization service will ensure that patient identities are protected while still allowing organizations to use a joint index.( GF-Lokalisatie, ADR-1 ) |
careservices-datamodel.png ![]() |
careservices-overview-transactions.png ![]() |
localization-overview-transactions.png ![]() |
tree-filter.png ![]() |