Huidige versie van 5 jul 2023 om 15:04

This FHIR IG is currently under development and can not be considered stable and ready for use. For questions and change requests regarding this IG, please create a ticket in BITS.

Inhoud

1 Introduction
2 Workflow and message structure - referral use cases
3 Use cases
- 3.1 Use case: Referral from general practitioner to allied health professional
  - 3.1.1 Actors involved
  - 3.1.2 Relations between resources
4 FHIR profiles
5 Release notes

1 Introduction

This is the implementation guide for ELZ (Dutch: Eerstelijnszorg, English: Primary care). The functional specification can be found here and is implemented using HL7 FHIR R4. This implementation guide assumes that the reader is familiar with both the functional specification and the FHIR standard.

This IG is inspired by the BSeR IG, developed and published by the HL7 Public Health work group. The goal is to align with this IG where possible and Nictiz is participating in this work group for further development and international alignment of the BSeR IG.

Apart from this document, the guidelines as specified in the general FHIR Implementation Guide apply.

2 Workflow and message structure - referral use cases

2.1 Overview

The use cases described in this IG are limited in sense of workflow: events are handled on a per use case basis where the sender does not explicitly requests a response (e.g. a status update). Future insights might contain more (use case overarching) workflow. To prepare for this workflow mechanism, the Task resource is used as the entry point for all exchanges.

2.2 Task

2.2.1 Task requirements

The requirements for the Task resource in the ELZ context are specified using the http://nictiz.nl/fhir/StructureDefinition/hg-ReferralTask profile. This profile SHALL be used for the ELZ referral use cases.

The Task instance SHALL be hosted on the server of the sending XIS. Both the sending and the receiving XIS need to be able to update the Task. The sending XIS MAY use business rules to reject an update, for example if invalid status change is used.

Both the sending and the receiving XIS SHALL monitor the Task resource for changes. It is expected that the sending XIS will use a notification mechanism to inform the receiving XIS of creation or updates of the Task, but the receiving XIS could use a polling mechanism as well.

2.2.2 Task invocations

The receiving XIS can query the Task at the sending XIS by using the Task.id which is communicated in the notification:

 GET [base]/Task/[Task.id]

Note: It is up to the receiving XIS to determine if this is a new Task or an update to an existing Task, and if it is an update, what the change entails.

The receiving XIS can update a Task hosted by the sending XIS using a PUT operation:

 PUT [base]/Task/[Task.id]

The body should be the original Task with the needed modifications. The sending XIS SHOULD check the update for errors and inconsistencies. If the update is rejected, the sending XIS SHALL response with an HTTP 422 status code and an OperationOutcome detailing the problem.

A notification/transaction mechanism for this IG is currently under a broader (international) discussion and therefore not yet specified, it is however aimed to align with this initiative.

2.3 ServiceRequest

A ServiceRequest resource is used to represent a (request for) referral. The requirements for the ServiceRequest resource in the context of this IG are specified using the http://nictiz.nl/fhir/StructureDefinition/hg-ReferralServiceRequest profile. This profile SHALL be used in referral use cases.

Each referral SHALL be captured by a dedicated ServiceRequest. When a referral is sent to multiple parties, each party receives its own unique ServiceRequest. Revoking referrals after a certain period of time based on whether action is taken or not is out of scope of this IG.

The ServiceRequest is referenced from Task.focus.

2.3.1 ServiceRequest invocations

The receiving XIS MAY use the following mechanism to retrieve the ServiceRequest:

GET [base]/ServiceRequest/[ServiceRequest.id]

2.4 Composition

A Composition resource is used to capture relevant data that supports the referral, for instance the reason for referral or guidance noted down by the general practitioner. This data is either directly included in the Composition as unstructured text or included as referenced resources. The requirements for IG are specified using the http://nictiz.nl/fhir/StructureDefinition/hg-ReferralComposition profile. This profile SHALL be used in referral use cases.

The Composition is referenced from ServiceRequest.supportingInfo.

2.4.1 Composition invocations

The receiving XIS MAY use either of the following mechanisms to retrieve the Composition and individual FHIR resources referenced in the Composition:

As a Document

The receiving XIS uses the $document operation to retrieve both the Composition and all referenced resources as a single document Bundle.

GET [base]/Composition/[Composition.id]/$document

Note: The sending XIS SHALL produce a complete Bundle containing not only the Composition and the resources listed directly in the Composition, but all the indirectly referenced resources as well.

Individual requests

The receiving XIS first retrieves the Composition resource:

GET [base]/Compositon/[Composition.id]

Then the necessary other resources referenced can be fetched using GET interactions.

The sending XIS SHALL support both mechanisms.

2.4.2 Handling unstructured text concepts

Some concepts in the data set are of data type string, as some of the relevant data is entered manually by the referrer in the context of a specific referral. This data is often not represented as a persistent object in EHRs but more likely stored as a form or a questionnaire entry. In order to send this data within the Composition, the extension http://nictiz.nl/fhir/StructureDefinition/ext-TextValue is used on Composition.section, accompanied by a distinctive code on Composition.section.code. The Composition.section.text, which provides a human-readable narrative, is mandatory when the Composition.section does not contain an entry or sub-section. Also see invariant cmp-1.

Example:

<Composition>
...
<section>
    <extension url="http://nictiz.nl/fhir/StructureDefinition/ext-TextValue">
        <valueString value="paracetamol indien nodig"/>
    </extension>
    <title value="Ingestelde behandeling"/>
    <code>
        <coding>
            <system value="http://snomed.info/sct"/>
            <code value="108631000146107"/>
            <display value="behandeling lopende (situatie)"/>
        </coding>
    </code>
    <text>
        <status value="extensions"/>
        <div xmlns="http://www.w3.org/1999/xhtml">Ingestelde behandeling: paracetamol indien nodig</div>
    </text>
</section>
...
</Composition>

3 Use cases

Currently this IG only covers the #Use_case:_Referral_from_general_practitioner_to_allied_health_professional but omits the transfer of relevant medical record entries. As development moves on, this use case will be extended and more use cases will be added.

3.1 Use case: Referral from general practitioner to allied health professional

This is the technical counterpart of hg:Vprepub-1_Ontwerp_ELZ#Usecase:_Huisarts_verwijst_naar_paramedicus as described in the functional design.

3.1.1 Actors involved

Actors		Systems				FHIR CapabilityStatements
Name	Description	Name	Actor	System role	Description	Name	Description
General practitioner	The user of a HIS	HIS	Sending XIS (server)	HZP-VPS	General practitioner information system	http://nictiz.nl/fhir/CapabilityStatement/hg-Referral-GeneralPractitionerToAlliedHealthProfessional	FHIR client/server requirements
Allied health professional	The user of a PARIS	PARIS	Receiving XIS (client)	HZP-VPO	Allied health professional information system		FHIR client/server requirements

3.1.2 Relations between resources

4 FHIR profiles

ELZ uses the FHIR Packaging mechanism. This conveniently bundles all profiles, terminology, example material and other conformance resources you need into a single archive, which can be downloaded or installed using the appropriate FHIR tooling. This IG uses the following packages:

nictiz.fhir.nl.r4.elz version 0.2.0-beta.1 or compatible
nictiz.fhir.nl.r4.nl-core version 0.9.0-beta.1 or compatible

Note: packages use Semantic Versioning. Other versions can be used at will as long as they have the same major.minor number or a minor number higher than the stated version.

The FHIR profiles defined for zib publication 2020 are currently in beta status. Although major changes are not to be expected, users should be aware that these profiles might be subject to incompatible changes before a stable version is reached. Therefore, these profiles should not be regarded fit for use for real-world data exchange.

Profile name	FHIR Resource	Canonical URL
hg-ReferralTask	Task	http://nictiz.nl/fhir/StructureDefinition/hg-ReferralTask
hg-ReferralServiceRequest	ServiceRequest	http://nictiz.nl/fhir/StructureDefinition/hg-ReferralServiceRequest
hg-ReferralComposition	Composition	http://nictiz.nl/fhir/StructureDefinition/hg-ReferralComposition
nl-core-Patient	Patient	http://nictiz.nl/fhir/StructureDefinition/nl-core-Patient
nl-core-HealthProfessional-PractitionerRole	PractitionerRole	http://nictiz.nl/fhir/StructureDefinition/nl-core-HealthProfessional-PractitionerRole
nl-core-HealthProfessional-Practitioner	Practitioner	http://nictiz.nl/fhir/StructureDefinition/nl-core-HealthProfessional-Practitioner
nl-core-HealthcareProvider	Location	http://nictiz.nl/fhir/StructureDefinition/nl-core-HealthcareProvider
nl-core-HealthcareProvider-Organization	Organization	http://nictiz.nl/fhir/StructureDefinition/nl-core-HealthcareProvider-Organization
nl-core-Problem	Condition	http://nictiz.nl/fhir/StructureDefinition/nl-core-Problem

5 Release notes

Release notes can be found on the functional design page.

@@ Regel 1: / Regel 1: @@
+__NOINDEX__
 {{Vdraft/InformationBox|This FHIR IG is currently under development and can not be considered stable and ready for use. For questions and change requests regarding this IG, please create a ticket in [{{VersieInfo|BITS|release=V1|namespace=hg}} BITS].}}
-__NOINDEX__
 __NUMBEREDHEADINGS__
 {{DISPLAYTITLE:FHIR Implementation Guide ELZ {{VersieInfo|ELZ|release=V1|namespace=hg}}}}
+[[Bestand:Icoon_Nictiz_Cirkel_Eerstelijnszorg_Oranje.svg|link=|100px|ELZ|rechts]]
 <div class="toclimit-3">__TOC__</div>
@@ Regel 8: / Regel 11: @@
 =Introduction=
-This is the implementation guide for ELZ (Dutch: EersteLijnsZorg, English: Primary Care). This functional specification can be found [[Ontwerp_Huisartsenzorg|here]] and is implemented using [https://www.hl7.org/fhir/R4/ HL7 FHIR R4]. This implementation guide assumes that the reader is familiar with both the functional specification and the FHIR standard.
+This is the implementation guide for ELZ (Dutch: Eerstelijnszorg, English: Primary care). The functional specification can be found [[hg:Vprepub-1_Ontwerp_ELZ|here]] and is implemented using [https://www.hl7.org/fhir/R4/ HL7 FHIR R4]. This implementation guide assumes that the reader is familiar with both the functional specification and the FHIR standard.
+This IG is inspired by the [https://build.fhir.org/ig/HL7/bser/ BSeR IG], developed and published by the HL7 Public Health work group. The goal is to align with this IG where possible and Nictiz is participating in this work group for further development and international alignment of the BSeR IG.
 Apart from this document, the guidelines as specified in the [[FHIR:V1.0_FHIR_IG_R4|general FHIR Implementation Guide]] apply.
-=Workflow and message structure=
+=Workflow and message structure - referral use cases=
 ==Overview==
-The use cases described in this IG are limited in sense of workflow: events are handled on a per use case basis where the sender does not explicitly requests a response (e.g. a status update). Future insights might require more workflow and it is conceivable that the FHIR Task resource will be used to fulfill that. At this point in time, the ServiceRequest and Composition resources are sufficient for the use cases described in this IG. In a later stage, more (mostly zib based) resource profiles will be added for the transfer of the medical record.
+The use cases described in this IG are limited in sense of workflow: events are handled on a per use case basis where the sender does not explicitly requests a response (e.g. a status update). Future insights might contain more (use case overarching) workflow. To prepare for this workflow mechanism, the Task resource is used as the entry point for all exchanges.
+==Task==
+===Task requirements===
+The requirements for the Task resource in the ELZ context are specified using the {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/hg-ReferralTask|nictiz.fhir.nl.r4.elz|pkgVersion=0.2.0-beta.1}} profile. This profile SHALL be used for the ELZ referral use cases.
+The Task instance SHALL be hosted on the server of the sending XIS. Both the sending and the receiving XIS need to be able to update the Task. The sending XIS MAY use business rules to reject an update, for example if invalid status change is used.
+Both the sending and the receiving XIS SHALL monitor the Task resource for changes. It is expected that the sending XIS will use a notification mechanism to inform the receiving XIS of creation or updates of the Task, but the receiving XIS could use a polling mechanism as well.
+===Task invocations===
+The receiving XIS can query the Task at the sending XIS by using the {{fhir|Task.id}} which is communicated in the notification:
+  GET [base]/Task/[Task.id]
+'''Note''': It is up to the receiving XIS to determine if this is a new Task or an update to an existing Task, and if it is an update, what the change entails.
+The receiving XIS can update a Task hosted by the sending XIS using a PUT operation:
+  PUT [base]/Task/[Task.id]
+The body should be the original Task with the needed modifications. The sending XIS SHOULD check the update for errors and inconsistencies. If the update is rejected, the sending XIS SHALL response with an HTTP 422 status code and an OperationOutcome detailing the problem.
+{{Vdraft/InformationBoxSmall|A notification/transaction mechanism for this IG is currently under a broader (international) discussion and therefore not yet specified, it is however aimed to align with this initiative.}}
 ==ServiceRequest==
-A ServiceRequest resource is used to represent a (request for) referral. The requirements for the ServiceRequest resource in the context of this information standard are specified using the {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/hg-ReferralServiceRequest}} profile. This profile SHALL be used in referral use cases.
+A ServiceRequest resource is used to represent a (request for) referral. The requirements for the ServiceRequest resource in the context of this IG are specified using the {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/hg-ReferralServiceRequest|nictiz.fhir.nl.r4.elz|pkgVersion=0.2.0-beta.1}} profile. This profile SHALL be used in referral use cases.
+Each referral SHALL be captured by a dedicated ServiceRequest. When a referral is sent to multiple parties, each party receives its own unique ServiceRequest. Revoking referrals after a certain period of time based on whether action is taken or not is out of scope of this IG.
+The ServiceRequest is referenced from {{fhir|Task.focus}}.
-Each referral SHALL be captured by a dedicated ServiceRequest. When a referral is sent to multiple parties, each party receives its own unique ServiceRequest. Revoking referrals after a certain period of time based on whether action is taken or not is out of scope of this information standard.
+===ServiceRequest invocations===
+The receiving XIS MAY use the following mechanism to retrieve the ServiceRequest:
+<pre>GET [base]/ServiceRequest/[ServiceRequest.id]</pre>
 ==Composition==
-A Composition resource is used to capture relevant data that supports the referral, for instance the reason for referral or guidance noted down by the general practitioner. The requirements for the Composition resource in the context of this information standard are specified using the {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/hg-ReferralComposition}} profile. This profile SHALL be used in referral use cases.
+A Composition resource is used to capture relevant data that supports the referral, for instance the reason for referral or guidance noted down by the general practitioner. This data is either directly included in the Composition as unstructured text or included as referenced resources. The requirements for IG are specified using the {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/hg-ReferralComposition|nictiz.fhir.nl.r4.elz|pkgVersion=0.2.0-beta.1}} profile. This profile SHALL be used in referral use cases.
+The Composition is referenced from {{fhir|ServiceRequest.supportingInfo}}.
-===Handling free text concepts===
+===Composition invocations===
-Some concepts in the data set are of data type string, as some of the relevant data is entered manually by the referrer in the context of a specific referral. This data is often not represented as a persistent object in EHRs but more likely stored as a form or a questionnaire entry. In order to send this data within the Composition, the extension {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/ext-TextValue}} is used on {{fhir|Composition.section}}, accompanied by a distinctive code on {{fhir|Composition.section.code}}.
+The receiving XIS MAY use either of the following mechanisms to retrieve the Composition and individual FHIR resources referenced in the Composition:
+; As a Document: The receiving XIS uses the {{fhir|$document}} operation to retrieve both the Composition ''and'' all referenced resources as a single document Bundle.<br/><pre>GET [base]/Composition/[Composition.id]/$document</pre>'''Note''': The sending XIS SHALL produce a complete Bundle containing not only the Composition and the resources listed directly in the Composition, but all the indirectly referenced resources as well.
+; Individual requests: The receiving XIS first retrieves the Composition resource:<br/><pre>GET [base]/Compositon/[Composition.id]</pre>Then the necessary other resources referenced can be fetched using <code>GET</code> interactions.
+The sending XIS SHALL support both mechanisms.
+===Handling unstructured text concepts===
+Some concepts in the data set are of data type string, as some of the relevant data is entered manually by the referrer in the context of a specific referral. This data is often not represented as a persistent object in EHRs but more likely stored as a form or a questionnaire entry. In order to send this data within the Composition, the extension {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/ext-TextValue}} is used on {{fhir|Composition.section}}, accompanied by a distinctive code on {{fhir|Composition.section.code}}. The {{fhir|Composition.section.text}}, which provides a human-readable narrative, is mandatory when the {{fhir|Composition.section}} does not contain an entry or sub-section. Also see [http://hl7.org/fhir/R4/composition-definitions.html#Composition.section.text invariant cmp-1].
 Example:
@@ Regel 54: / Regel 97: @@
 =Use cases=
-{{Vdraft/InformationBoxSmall|Currently this IG only covers the [[#Use_case:_Referral_from_general_practitioner_to_paramedic]] and specifically just the referral and not the transfer of relevant medical record entries. As development moves on, more use cases will be added.}}
+{{Vdraft/InformationBoxSmall|Currently this IG only covers the [[#Use_case:_Referral_from_general_practitioner_to_allied_health_professional]] but omits the transfer of relevant medical record entries. As development moves on, this use case will be extended and more use cases will be added.}}
-==Use case: Referral from general practitioner to paramedic==
-This is the technical counterpart of [[Ontwerp_Huisartsenzorg#Usecase:_Huisarts_verwijst_naar_paramedicus]] as described in the functional design.
-===Introduction===
-{{Vdraft/InformationBoxSmall|The RESTful interactions for this use case have not been determined yet. The following is an initial proposal that can be used for testing purposes.}}
-Because sending a referral consists of a ServiceRequest and Composition resource along with supporting resources, a [https://www.hl7.org/fhir/http.html#transaction {{fhir|transaction}} interaction] interaction can be used. This allows for creating a set of resources in a single interaction and makes it possible to [[FHIR:V1.0_FHIR_IG_R4#Including_.22secondary.22_resources_when_sending_information|include referenced secondary resources]] if needed.
-A {{fhir|transaction}} interaction is performed by an HTTP POST command as shown:
-<pre>POST [base]</pre>
+==Use case: Referral from general practitioner to allied health professional==
+This is the technical counterpart of [[hg:Vprepub-1_Ontwerp_ELZ#Usecase:_Huisarts_verwijst_naar_paramedicus]] as described in the functional design.
-The body of the POST submission is a Bundle with {{fhir|Bundle.type}}={{term|transaction}}. Each entry carries request details ({{fhir|Bundle.entry.request}}) that provides the HTTP details of the action in order to inform the system processing the transaction of what to do for the entry. (Note: {{fhir|Bundle.request}} is optional in FHIR, but SHALL be present, even for the resources which aren't ServiceRequests or Compositions. See [[FHIR:V1.0_FHIR_IG_R4#Including_.22secondary.22_resources_when_sending_information]] for more information.)
-The resources included in the bundle SHALL conform to the profiles listed in the [[#FHIR_profiles|table below]].
 ===Actors involved===
 {| class="wikitable"
 ! colspan="2" | Actors
-! colspan="2" | Systems
+! colspan="4" | Systems
 ! colspan="2" | FHIR CapabilityStatements
 |-
@@ Regel 81: / Regel 111: @@
 ! Description
 ! Name
+! Actor
+! System role
 ! Description
 ! Name
@@ Regel 88: / Regel 120: @@
 | The user of a HIS
 | HIS
+| Sending XIS (server)
+| HZP-VPS
 | General practitioner information system
-| n/a
+| rowspan="2" | {{Simplifier|http://nictiz.nl/fhir/CapabilityStatement/hg-Referral-GeneralPractitionerToAlliedHealthProfessional|nictiz.fhir.nl.r4.elz|pkgVersion=0.2.0-beta.1}}
-| n/a
+| rowspan="2" | FHIR client/server requirements
 |-
-| Paramedic
+| Allied health professional
 | The user of a PARIS
 | PARIS
-| Paramedic information system
+| Receiving XIS (client)
-| n/a
+| HZP-VPO
-| n/a
+| Allied health professional information system
 |}
 ===Relations between resources===
-[[Bestand:Resources_verwijzing.png|1000px|link=]]
+[[Bestand:230523_Resources_verwijzing.png|1000px|link=]]
 =FHIR profiles=
-{{hg:Vprepub-1_NoteBoxPackage|p1=nictiz.fhir.nl.r4.elz|v1=0.1.0-alfa.1|p2=nictiz.fhir.nl.r4.nl-core|v2=0.7.0-beta.1}}
+{{hg:Vprepub-1_NoteBoxPackage|p1=nictiz.fhir.nl.r4.elz|v1=0.2.0-beta.1|p2=nictiz.fhir.nl.r4.nl-core|v2=0.9.0-beta.1}}
+{{Vdraft/InformationBoxSmall|The FHIR profiles defined for zib publication 2020 are currently in beta status. Although major changes are not to be expected, users should be aware that these profiles might be subject to incompatible changes before a stable version is reached. Therefore, these profiles should not be regarded fit for use for real-world data exchange.}}
 {| class="wikitable"
@@ Regel 111: / Regel 147: @@
 ! FHIR Resource
 ! Canonical URL
+|-
+| hg-ReferralTask
+| Task
+| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/hg-ReferralTask|nictiz.fhir.nl.r4.elz|pkgVersion=0.2.0-beta.1}}
 |-
 | hg-ReferralServiceRequest
 | ServiceRequest
-| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/hg-ReferralServiceRequest|nictiz.fhir.nl.r4.elz|pkgVersion=0.1.0-alfa.1}}
+| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/hg-ReferralServiceRequest|nictiz.fhir.nl.r4.elz|pkgVersion=0.2.0-beta.1}}
 |-
 | hg-ReferralComposition
 | Composition
-| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/hg-ReferralComposition|nictiz.fhir.nl.r4.elz|pkgVersion=0.1.0-alfa.1}}
+| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/hg-ReferralComposition|nictiz.fhir.nl.r4.elz|pkgVersion=0.2.0-beta.1}}
 |-
 | nl-core-Patient
 | Patient
-| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/nl-core-Patient|nictiz.fhir.nl.r4.nl-core|pkgVersion=0.7.0-beta1}}
+| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/nl-core-Patient|nictiz.fhir.nl.r4.nl-core|pkgVersion=0.9.0-beta.1}}
 |-
 | nl-core-HealthProfessional-PractitionerRole
 | PractitionerRole
-| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/nl-core-HealthProfessional-PractitionerRole|nictiz.fhir.nl.r4.nl-core|pkgVersion=0.7.0-beta1}}
+| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/nl-core-HealthProfessional-PractitionerRole|nictiz.fhir.nl.r4.nl-core|pkgVersion=0.9.0-beta.1}}
 |-
 | nl-core-HealthProfessional-Practitioner
 | Practitioner
-| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/nl-core-HealthProfessional-Practitioner|nictiz.fhir.nl.r4.nl-core|pkgVersion=0.7.0-beta1}}
+| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/nl-core-HealthProfessional-Practitioner|nictiz.fhir.nl.r4.nl-core|pkgVersion=0.9.0-beta.1}}
 |-
 | nl-core-HealthcareProvider
 | Location
-| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/nl-core-HealthcareProvider|nictiz.fhir.nl.r4.nl-core|pkgVersion=0.7.0-beta1}}
+| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/nl-core-HealthcareProvider|nictiz.fhir.nl.r4.nl-core|pkgVersion=0.9.0-beta.1}}
 |-
 | nl-core-HealthcareProvider-Organization
 | Organization
-| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/nl-core-HealthcareProvider-Organization|nictiz.fhir.nl.r4.nl-core|pkgVersion=0.7.0-beta1}}
+| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/nl-core-HealthcareProvider-Organization|nictiz.fhir.nl.r4.nl-core|pkgVersion=0.9.0-beta.1}}
 |-
 | nl-core-Problem
 | Condition
-| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/nl-core-Problem|nictiz.fhir.nl.r4.nl-core|pkgVersion=0.7.0-beta1}}
+| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/nl-core-Problem|nictiz.fhir.nl.r4.nl-core|pkgVersion=0.9.0-beta.1}}
 |}
 =Release notes=
 Release notes can be found on the [[hg:Vprepub-1_Ontwerp_ELZ#Release_notes| functional design page]].

hg:Vprepub-1 FHIR ELZ: verschil tussen versies

Huidige versie van 5 jul 2023 om 15:04

Inhoud

1 Introduction

2 Workflow and message structure - referral use cases

2.1 Overview

2.2 Task

2.2.1 Task requirements

2.2.2 Task invocations

2.3 ServiceRequest

2.3.1 ServiceRequest invocations

2.4 Composition

2.4.1 Composition invocations

2.4.2 Handling unstructured text concepts

3 Use cases

3.1 Use case: Referral from general practitioner to allied health professional

3.1.1 Actors involved

3.1.2 Relations between resources

4 FHIR profiles

5 Release notes

Navigatiemenu

Persoonlijke instellingen

Naamruimten

Varianten

Weergaven

Meer

Zoeken

Navigatie

Support

Hulpmiddelen