FHIR:V1.0 FHIR IG R4 - Bewerkingsoverzicht

Pieter Edelman: Beveiligde "FHIR:V1.0 FHIR IG R4": Protect production page from accidental edits ([Bewerken=Alleen beheerders toestaan] (vervalt niet) [Hernoemen=Alleen beheerders toestaan] (vervalt niet))

2025-07-31T14:11:05Z

Beveiligde "FHIR:V1.0 FHIR IG R4": Protect production page from accidental edits ([Bewerken=Alleen beheerders toestaan] (vervalt niet) [Hernoemen=Alleen beheerders toestaan] (vervalt niet))

Pieter Edelman: Publish prepub to live environment

2025-07-31T14:11:05Z

Publish prepub to live environment

Pieter Edelman: Gekopieerd van FHIR:Vprepub-1.0 FHIR IG R4, versie 126738

2025-07-31T14:10:50Z

Gekopieerd van FHIR:Vprepub-1.0 FHIR IG R4, versie 126738

Pieter Edelman: ZIBFHIR-357: Fix broken link

2025-07-31T10:08:40Z

ZIBFHIR-357: Fix broken link

Pieter Edelman: ZIBFHIR-325: Make clear that a reference may contain both a literal and a logical reference

2025-06-02T19:32:51Z

ZIBFHIR-325: Make clear that a reference may contain both a literal and a logical reference

Pieter Edelman: MM-4755: Add section tags to mark of sections of the IG

2024-03-25T20:27:41Z

MM-4755: Add section tags to mark of sections of the IG

Luud Slagter: MM-4994: Textual improvements

2023-09-25T13:09:29Z

MM-4994: Textual improvements

Pieter Edelman: MM-4920: Clarify the introduction of the "Missing information" section

2023-09-19T11:07:03Z

MM-4920: Clarify the introduction of the "Missing information" section

Pieter Edelman: MM-4821: Provide guidance on reference display values

2023-06-19T15:38:14Z

MM-4821: Provide guidance on reference display values

Niek van Galen: MM-3987: toevoegen Sjabloon Ondersteuning

2023-01-25T09:43:34Z

MM-3987: toevoegen Sjabloon Ondersteuning

@@ Regel 1: / Regel 1: @@
 __NUMBEREDHEADINGS__
 {{DISPLAYTITLE:Nictiz FHIR R4 Implementation Guide {{VersieInfo|FHIR_IG_R4|release=V1.0}}}}
@@ Regel 48: / Regel 47: @@
 <section end="FunctionalDefinitions" /><section begin="ProfilingGuidelines" />
 ==Profiling guidelines==
-All conformance resources created within Nictiz follow the conventions as outlined in the [[FHIR:Vprepub-1.0_FHIR_Profiling_Guidelines_R4|FHIR Profiling Guidelines for FHIR R4]].
+All conformance resources created within Nictiz follow the conventions as outlined in the [[FHIR:V1.0_FHIR_Profiling_Guidelines_R4|FHIR Profiling Guidelines for FHIR R4]].
 <section end="ProfilingGuidelines" /><section begin="HTTPHeaders" />
 ==HTTP headers==
@@ Regel 116: / Regel 115: @@
 ; [https://hl7.org/fhir/R4/references.html#logical Logical references], using the {{fhir|.identifier}} element: Meaning a match on the business identifier ({{fhir|.identifier}}) for the referenced resource, without specifying where to find the referenced resource. Note: confusingly, although this reference type is called "logical reference", it does ''not'' act on the "logical identifier" ({{fhir|.id}}) of resources.
-Profiles usually do not constrain which resources may be targeted from a given element. For example, {{fhir|Condition.subject}} may point to a Patient or Group resource. The {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/nl-core-Problem|title=nl-core-Problem}} profile adds nl-core-Patient as a third option, to adhere both to [[FHIR:Vprepub-1.0_FHIR_Profiling_Guidelines_R4#Open_vs._closed_world_modeling|open world modelling]] and a need to provide useful guidance on how this reference should be handled. However, use case specific profiles may constrain the target profiles.
+Profiles usually do not constrain which resources may be targeted from a given element. For example, {{fhir|Condition.subject}} may point to a Patient or Group resource. The {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/nl-core-Problem|title=nl-core-Problem}} profile adds nl-core-Patient as a third option, to adhere both to [[FHIR:V1.0_FHIR_Profiling_Guidelines_R4#Open_vs._closed_world_modeling|open world modelling]] and a need to provide useful guidance on how this reference should be handled. However, use case specific profiles may constrain the target profiles.
 The basic requirements for using references in this context are:
@@ Regel 332: / Regel 331: @@
 * HTTP 401 Unauthorized
 * OperationOutcome with {{fhir|.code}} set to {{term|security}}.
-| [[FHIR:Vprepub-1.0 FHIR_Error_handling_examples#Not_authorized|Example]]
+| [[FHIR:V1.0 FHIR_Error_handling_examples#Not_authorized|Example]]
 |-
 | Invalid authorization, scope of the access token is not sufficient for the request
@@ Regel 338: / Regel 337: @@
 * HTTP 403 Forbidden
 * OperationOutcome with {{fhir|.code}} set to {{term|security}}.
-| [[FHIR:Vprepub-1.0 FHIR_Error_handling_examples#Invalid_authorization|Example]]
+| [[FHIR:V1.0 FHIR_Error_handling_examples#Invalid_authorization|Example]]
 |-
 | Resource is not supported
@@ Regel 344: / Regel 343: @@
 * HTTP 404 Not Found
 * OperationOutcome with {{fhir|.code}} set to {{term|not-supported}}.
-| [[FHIR:Vprepub-1.0 FHIR_Error_handling_examples#Resource_is_not_supported|Example]]
+| [[FHIR:V1.0 FHIR_Error_handling_examples#Resource_is_not_supported|Example]]
 |-
 | rowspan=4 |search
@@ Regel 357: / Regel 356: @@
 * HTTP 400 Bad Request
 * OperationOutcome. There are various issue type codes that could be used, depending on the nature of the error
-| [[FHIR:Vprepub-1.0 FHIR_Error_handling_examples#Syntactically_incorrect_parameter|Example]]
+| [[FHIR:V1.0 FHIR_Error_handling_examples#Syntactically_incorrect_parameter|Example]]
 |-
 | Known but unsupported value. This situation applies to non-supported profiles when the Resource endpoint itself is supported.
@@ Regel 365: / Regel 364: @@
 * OperationOutcome in Bundle as an entry with {{fhir|Bundle.entry.search.mode}} set to {{term|outcome}}.
 * OperationOutcome with {{fhir|.code}} set to {{term|not-found}} and {{fhir|.severity}} not set to {{term|fatal}} or {{term|error}}.
-| [[FHIR:Vprepub-1.0 FHIR_Error_handling_examples#Unkown_or_unsupported_search_parameter_value|Example]]
+| [[FHIR:V1.0 FHIR_Error_handling_examples#Unkown_or_unsupported_search_parameter_value|Example]]
 |-
 | read
@@ Regel 372: / Regel 371: @@
 * HTTP 404 Not Found
 * OperationOutcome with {{fhir|.code}} set to {{term|not-found}}.
-| [[FHIR:Vprepub-1.0 FHIR_Error_handling_examples#Request_on_an_unknown_id|Example]]
+| [[FHIR:V1.0 FHIR_Error_handling_examples#Request_on_an_unknown_id|Example]]
 |-
 | update
@@ Regel 379: / Regel 378: @@
 * HTTP 400 Bad Request
 * OperationOutcome with {{fhir|.code}} set to {{term|invalid}}.
-| [[FHIR:Vprepub-1.0 FHIR_Error_handling_examples#No_or_incorrect_Resource_id|Example]]
+| [[FHIR:V1.0 FHIR_Error_handling_examples#No_or_incorrect_Resource_id|Example]]
 |-
 | create/update
@@ Regel 386: / Regel 385: @@
 * HTTP 400 Bad Request or HTTP 422 Unprocessable Entity
 * OperationOutcome with {{fhir|.code}} set to {{term|invalid}} or preferably a more specific child code.
-| [[FHIR:Vprepub-1.0 FHIR_Error_handling_examples#Resource_syntax_or_data_is_incorrect_or_invalid|Example]]
+| [[FHIR:V1.0 FHIR_Error_handling_examples#Resource_syntax_or_data_is_incorrect_or_invalid|Example]]
 |}
 <section end="HandlingErrors" /><section begin="CapabilityStatements" />

@@ Regel 88: / Regel 88: @@
 ===Code system URIs===
-A coded value in FHIR is communicated as a combination of a code (in {{fhir|.code}}) and the canonical URI for the code system from which it was drawn (in {{fhir|.system}}). Implementers SHALL use the canonical URI that can be found by inspecting the ValueSet that is bound to a coded element in the appropriate FHIR profile<ref>Although the canonical URI is not formally defined in the ValueSet, in practical terms it can be found here.</ref>. Please note that a code system URI ''can'' align with its OID (as a <code><nowiki>urn:oid:[oid]</nowiki></code> URI), but that this is not always the case. For example, SNOMED CT is referenced by URL rather than by <code><nowiki>urn:oid:[oid]</nowiki></code><ref>For an overview of URLs defined, see [https://www.hl7.org/fhir/R4/terminologies-systems.html the FHIR core specification] or [http://hl7.nl/wiki/index.php?title=OIDs_en_FHIR_System_URIs HL7 NL for the Dutch realm].</ref>.
+A coded value in FHIR is communicated as a combination of a code (in {{fhir|.code}}) and the canonical URI for the code system from which it was drawn (in {{fhir|.system}}). Implementers SHALL use the canonical URI that can be found by inspecting the ValueSet that is bound to a coded element in the appropriate FHIR profile<ref>Although the canonical URI is not formally defined in the ValueSet, in practical terms it can be found here.</ref>. Please note that a code system URI ''can'' align with its OID (as a <code><nowiki>urn:oid:[oid]</nowiki></code> URI), but that this is not always the case. For example, SNOMED CT is referenced by URL rather than by <code><nowiki>urn:oid:[oid]</nowiki></code><ref>For an overview of URLs defined, see [https://www.hl7.org/fhir/R4/terminologies-systems.html the FHIR core specification] or [https://confluence.hl7.org/spaces/HNETH/pages/161077747/OIDs_en_FHIR_System_URIs HL7 NL for the Dutch realm].</ref>.
 ===Mapping of coded concepts===

@@ Regel 119: / Regel 119: @@
 The basic requirements for using references in this context are:
-* Either a literal or logical reference SHALL be specified.
+* Either a literal or logical reference or both SHALL be specified.
 ** Literal references are preferred over logical references where possible.
 * Literal references SHALL be resolvable.
@@ Regel 129: / Regel 129: @@
 In some circumstances, the constraints on the target resource type are too strict for the use case and the appropriate resource can't be referenced. In such cases, the proper reference type is added using an extension within the element that is used to refer the other resource. To aid receiving systems that cannot handle the extension, the sending system SHOULD give as much information as possible in the main element, for example by repeating the {{fhir|.display}} used in the extension in the main element.
 <section end="UseOfTheReferenceDataType" /><section begin="ProfileUseAndDeclaration" />
 ==Profile use and declaration==
 The implementation guides for the various information standards list the package version and profiles to use for the FHIR resources. A profile is a statement about the rules that this resource was created against. In the interest of interoperability it is important that, when using said information standard:

@@ Regel 13: / Regel 13: @@
 <section begin=OverarchingPrinciples />
 =Overarching principles=
 ==Functional definitions==
 Most, if not all, conformance resources are based on an underlying functional model. The functional model is the specification to which the conformance resources should adhere.
@@ Regel 45: / Regel 46: @@
 An information standard may provide additional use case or transaction specific profiles,  which constrain cardinality and apply {{fhir|mustSupport}} as applicable, for extra implementation guidance.
+<section end="FunctionalDefinitions" /><section begin="ProfilingGuidelines" />
 ==Profiling guidelines==
 All conformance resources created within Nictiz follow the conventions as outlined in the [[FHIR:Vprepub-1.0_FHIR_Profiling_Guidelines_R4|FHIR Profiling Guidelines for FHIR R4]].
+<section end="ProfilingGuidelines" /><section begin="HTTPHeaders" />
 ==HTTP headers==
 ===Content Types and encodings===
@@ Regel 75: / Regel 76: @@
 ** <p>Servers SHALL support a default version in absence of the <code>fhirVersion</code> parameter in the <code>Accept</code> and <code>Content-Type</code> headers.</p><p>Note: When a server previously supported FHIR STU3 on an endpoint, it makes sense to set STU3 as the default version to remain compatible with existing clients. Newer R4 implementations of clients are expected to use the <code>fhirVersion</code> parameter, whereas this was not the case for STU3 implementations.
 ** In case of a mismatch between the requested <code>fhirVersion</code> and the supported <code>fhirVersion</code>(s), servers SHALL respond with HTTP status 400 Bad Request and SHOULD include an OperationOutcome with {{fhir|.severity}} set to {{term|fatal}} and {{fhir|.code}} set to {{term|exception}}, and SHOULD include a {{fhir|.details}} element that outlines the mismatch.
+<section end="HTTPHeaders" /><section begin="UseOfCodedConcepts" />
 ==Use of coded concepts==
 ===Textual description of coded concepts===
@@ Regel 109: / Regel 110: @@
 </criticality>
 </syntaxhighlight>
+<section end="UseOfCodedConcepts" /><section begin="UseOfTheReferenceDataType" />
 ==Use of the reference data type==
 A key feature of FHIR is the ability of resources to reference each other. This is done using the [https://hl7.org/fhir/R4/references.html#Reference {{datatype|Reference}} data type]. This data type supports two modes of referencing:
@@ Regel 127: / Regel 128: @@
 In some circumstances, the constraints on the target resource type are too strict for the use case and the appropriate resource can't be referenced. In such cases, the proper reference type is added using an extension within the element that is used to refer the other resource. To aid receiving systems that cannot handle the extension, the sending system SHOULD give as much information as possible in the main element, for example by repeating the {{fhir|.display}} used in the extension in the main element.
+<section end="UseOfTheReferenceDataType" /><section begin="ProfileUseAndDeclaration" />
 ==Profile use and declaration==
 The implementation guides for the various information standards list the package version and profiles to use for the FHIR resources. A profile is a statement about the rules that this resource was created against. In the interest of interoperability it is important that, when using said information standard:
@@ Regel 147: / Regel 148: @@
 '''Note''': It is '''not''' required to implement FHIR-based information standards using the packaging mechanism. It is still possible to download all or selected resources from Simplifier on as-needed basis. You are however encouraged to invest in dealing with packages.
+<section end="ProfileUseAndDeclaration" /><section begin="Search" />
 ==Search==
@@ Regel 305: / Regel 306: @@
 </Bundle>
 </syntaxhighlight>
+<section end="Search" /><section begin="HandlingErrors" />
 == Handling errors==
 Errors in FHIR interactions are usually communicated using the combination of an appropriate HTTP status code in the 4xx-5xx range, and an [https://hl7.org/fhir/R4/operationoutcome.html OperationOutcome] resource providing more details regarding the error. The OperationOutcome resource contains mandatory elements to indicate the overall type and severity of the error (respectively {{fhir|.code}} and {{fhir|.severity}}) and MAY express the location (using {{fhir|.location}} or {{fhir|.expression}}) and a free-form or coded description of the error (using the {{fhir|.diagnostics}} or {{fhir|.details}} element). Although these latter elements are not required, their usage is strongly encouraged.
@@ Regel 386: / Regel 387: @@
 | [[FHIR:Vprepub-1.0 FHIR_Error_handling_examples#Resource_syntax_or_data_is_incorrect_or_invalid|Example]]
 |}
+<section end="HandlingErrors" /><section begin="CapabilityStatements" />
 ==CapabilityStatements==
 Information standards may have a [https://www.hl7.org/fhir/stu3/capabilitystatement.html CapabilityStatement] that is informative in nature and does not represent the minimum or maximum set of capabilities the client or server should support. Nictiz will strive to provide CapabilityStatements that are as complete as possible, however for the exact set of capabilities the implementation guide of the corresponding information standard should be consulted.
@@ Regel 401: / Regel 402: @@
 * If the server can unequivocally deduplicate this secondary resource (for example, because the patient is already known from the security context or the healthcare provider is recognized by the UZI number), it MAY choose to ignore the differences of this resource or it MAY incorporate them (see the [https://hl7.org/fhir/r4/http.html#transactional-integrity the section on transactional integrity] in the FHIR specification). Please note that absence of information should not result in deletion of information on the server, as the client could send a bare-bones instance. If the server chooses to ignore the differences, it SHOULD do so silently by responding with a 200 OK status code for the corresponding {{fhir|Bundle.entry.response.status}} in the response Bundle.
 * The server SHALL rewrite the references in the primary resource to the instance of the secondary resource it already has.
+<section end="CapabilityStatements" /><section begin="ValidationAndTerminology" />
 ==Validation and terminology==
 The outcome of profile based validation can depend on the tooling (validator, terminology server) and its settings used. Implementers should be aware of the following topics regarding terminology when validating instances of nl-core or derived profiles.
@@ Regel 410: / Regel 411: @@
 ===CodeSystems without concepts defined===
 The zibs or UCSDs often prescribe the use of 'external' code systems, the contents of which may not be available without proper license. In FHIR, this is manifested by the use of ValueSets that contain {{fhir|ValueSet.compose.include.system}}, without specific {{fhir|.concept}}s, to indicate that all codes from the referenced CodeSystem are allowed. These CodeSystem resources have {{fhir|CodeSystem.content}} set to {{term|not-present}}. Some validators give a {{term|warning}} when a code from such ValueSet and CodeSystem is used, but some validators may give an {{term|error}}.
+<section end="ValidationAndTerminology" /><section begin="MissingInformation" />
 ==Missing information==
 The FHIR profile or the the ART-DECOR specification of a use case (or transaction) may require the presence of an element (cardinality 1..1 or 1..*) while a sending system doesn't have the required data. When this element is marked [https://wiki.art-decor.org/index.php?title=DECOR-rules#Mandatory_.2F_Conformance 'Required' or 'R'] (as opposed to [https://wiki.art-decor.org/index.php?title=DECOR-rules#Mandatory_.2F_Conformance 'Mandatory' or 'M']) in the ART-DECOR specification, the following guidance can be applied. Please note that in the case of elements designated 'Mandatory', the data MUST be present.
@@ Regel 427: / Regel 428: @@
 Profiles do not explicitly define when or how to apply FHIR DataAbsentReason.
+<section end="MissingInformation" /><section begin="TheNarrative" />
 =={{fhir|Resource.text}} or "the narrative"==
 The FHIR R4 specification says instances SHOULD contain a human readable summary of the contained data, which can be used as fallback by the receiver. This human readable text is contained in the [https://hl7.org/fhir/R4/domainresource-definitions.html#DomainResource.text {{fhir|.text}} element] with data type [https://hl7.org/fhir/R4/narrative.html {{datatype|Narrative}}]. This human readable text is often referred to as "the narrative".
@@ Regel 466: / Regel 467: @@
 Senders SHOULD NOT use the other possible statuses unless it is explicitly documented why, e.g. in an information standard. Receivers MAY choose to support narratives with status {{term|additional}}, which means that it holds information not contained in the structured data. Receivers - upon rendering narrative with status {{term|additional}} - SHOULD make it clear to the user that the information is a fragment, and not the entire thing, in some suitable way.
-<section end=OverarchingPrinciples />
+<section end="TheNarrative" /><section end=OverarchingPrinciples />
 =Release notes=
 {{#lsth:Tabellen met release notes|Nictiz FHIR R4 Implementation Guide 1}}
 {{#lsth:MedMij:Sjabloon_Support}}

@@ Regel 112: / Regel 112: @@
 ==Use of the reference data type==
 A key feature of FHIR is the ability of resources to reference each other. This is done using the [https://hl7.org/fhir/R4/references.html#Reference {{datatype|Reference}} data type]. This data type supports two modes of referencing:
-; [https://hl7.org/fhir/R4/references.html#literal Literal references], using the {{fhir|.reference}} element: A relative or absolute REST endpoint containing the {{fhir|.id}} of the referenced resource. In a Bundle context, this may also be a reference to a {{fhir|Bundle.resource.fullUrl}}.
+; [https://hl7.org/fhir/R4/references.html#literal Literal references], using the {{fhir|.reference}} element: A relative or absolute REST endpoint containing the {{fhir|.id}} of the referenced resource. In a Bundle context, this may also be a reference to a {{fhir|Bundle.entry.fullUrl}}.
 ; [https://hl7.org/fhir/R4/references.html#logical Logical references], using the {{fhir|.identifier}} element: Meaning a match on the business identifier ({{fhir|.identifier}}) for the referenced resource, without specifying where to find the referenced resource. Note: confusingly, although this reference type is called "logical reference", it does ''not'' act on the "logical identifier" ({{fhir|.id}}) of resources.
@@ Regel 361: / Regel 361: @@
 * HTTP 200 OK
 * Empty Bundle of {{fhir|.type}} {{term|searchset}}.
-* OperationOutcome in Bundle as an entry marked with {{fhir|Bundle.entry.search.mode}} set to {{term|outcome}}.
+* OperationOutcome in Bundle as an entry with {{fhir|Bundle.entry.search.mode}} set to {{term|outcome}}.
 * OperationOutcome with {{fhir|.code}} set to {{term|not-found}} and {{fhir|.severity}} not set to {{term|fatal}} or {{term|error}}.
 | [[FHIR:Vprepub-1.0 FHIR_Error_handling_examples#Unkown_or_unsupported_search_parameter_value|Example]]

← Oudere versie	Versie van 31 jul 2025 om 14:11
(geen verschil)

← Oudere versie	Versie van 31 jul 2025 om 14:10
(geen verschil)

@@ Regel 412: / Regel 412: @@
 ==Missing information==
-When the ART-DECOR specification of a use case (or transaction) requires the presence of an element (cardinality 1..1 or 1..*) and is not defined to be mandatory (shown as Required or ‘R’), but data is missing, please use the following guidance. This guidance also applies if the FHIR cardinality of an element is 1..1.
+The FHIR profile or the the ART-DECOR specification of a use case (or transaction) may require the presence of an element (cardinality 1..1 or 1..*) while a sending system doesn't have the required data. When this element is marked [https://wiki.art-decor.org/index.php?title=DECOR-rules#Mandatory_.2F_Conformance 'Required' or 'R'] (as opposed to [https://wiki.art-decor.org/index.php?title=DECOR-rules#Mandatory_.2F_Conformance 'Mandatory' or 'M']) in the ART-DECOR specification, the following guidance can be applied. Please note that in the case of elements designated 'Mandatory', the data MUST be present.
 # For ''non-coded'' data elements, use the [http://hl7.org/fhir/R4/extension-data-absent-reason.html Data Absent Reason Extension] with an appropriate code.

@@ Regel 123: / Regel 123: @@
 ** External references SHALL be regarded in the same context as the resource itself. If the current security context is insufficient for retrieving the reference, then additional negotiation for appropriate privileges may be required.
 ** Relative references are preferred over absolute references.
-* A short description of the target resource SHOULD be included using the {{fhir|.display}} element.
+* For a receiver it is not always possible or feasible to actually resolve a reference. Therefore, a short description of the target resource SHOULD be included using the {{fhir|.display}} element.<br />Please note: in rare circumstances, it is undesirable to provide a receiver with detailed information until it is actually able to resolve the reference, e.g. due to privacy considerations. In this case, it is expected that the {{fhir|.display}} contains an explicit remark that this information is masked.
 * The resource type of the target resource SHOULD be included using the {{fhir|.type}} element.

← Oudere versie		Versie van 25 jan 2023 om 09:43
Regel 470:		Regel 470:
	{{#lsth:Tabellen met release notes\|Nictiz FHIR R4 Implementation Guide 1}}		{{#lsth:Tabellen met release notes\|Nictiz FHIR R4 Implementation Guide 1}}

−	~~=Support=~~	+	{{#lsth:MedMij:Sjabloon_Support}}
−	~~For questions and change requests regarding this IG, please create a ticket in [https~~:~~//bits.nictiz.nl/projects/MM BITS].~~