vpk:Vprepub-4.0 FHIR eOverdracht - Bewerkingsoverzicht

Pieter Edelman: EOVDR-167: Add implementation advice about sending unstructured data as a PDF attachment

2022-10-21T13:20:25Z

EOVDR-167: Add implementation advice about sending unstructured data as a PDF attachment

← Oudere versie		Versie van 21 okt 2022 13:20
Regel 81:		Regel 81:

	The sending XIS SHALL support both mechanisms.		The sending XIS SHALL support both mechanisms.

			===Exchanging data as unstructured text===

			The information standard requires that all information described is exchanged in a structured way, according to the FHIR profiles described on this page. However, some systems are not able to support the full extent of the standard yet and may need to send part of the data as formatted text. The following implementation advice provides guidance on how systems with such a need may accomplish this exchange.

			* All unstructured (textual data) is collected in one single PDF/A document.
			* This document is added to the Composition resource representing the advance notice or the nursing handoff, in the following way:
			** An additional {{fhir\|Composition.section}} is created, with {{fhir\|.section.code}} set to SNOMED CT/{{term\|703852005}} (Narrative comment section).
			** In this section, there is a single {{fhir\|.section.entry}}, and it refers to a [http://hl7.org/fhir/stu3/documentreference.html DocumentReference] resource.
			** This DocumentReference resource references the PDF/A document containing the unstructured text.

			The use of the DocumentReference resource allows the sender to specify additional metadata about the document, if needed. It also prevents that the PDF/A is directly included when the Composition is requested using the {{fhir\|$document}} operation, which could lead to unexpected large data volumes.

	==Using Task to manage the workflow==		==Using Task to manage the workflow==

Mik de Jong: EOVDR-202: Implementatieadvies over notificatie authorization header toegevoegd.

2022-10-18T09:54:47Z

EOVDR-202: Implementatieadvies over notificatie authorization header toegevoegd.

← Oudere versie		Versie van 18 okt 2022 09:54
Regel 66:		Regel 66:
	It is expected that the sending XIS will notify the receiving XIS when a new Task is created or when an existing Task is updated. Although the notification mechanism is out of scope for the eOverdracht information standard, the notification SHALL communicate the {{fhir\|Task.id}} to the receiving XIS.		It is expected that the sending XIS will notify the receiving XIS when a new Task is created or when an existing Task is updated. Although the notification mechanism is out of scope for the eOverdracht information standard, the notification SHALL communicate the {{fhir\|Task.id}} to the receiving XIS.

	A straightforward implementation for this notification mechanism is for the notifying party to make an empty POST request on a pre-determined endpoint at the party that should be notified, with the {{fhir\|Task.id}} appended as path component:		A straightforward implementation for this notification mechanism is for the notifying party to make an empty POST request combined with an authorization header on a pre-determined endpoint at the party that should be notified, with the {{fhir\|Task.id}} appended as path component:
	POST [base]/[Task.id]		POST [base]/[Task.id]

Pieter Edelman: Add package scope to Simplifier links

2022-08-04T11:42:43Z

Add package scope to Simplifier links

Wijzigingen bekijken

Pieter Edelman: Adopt VersieInfo template

2022-08-02T10:48:20Z

Adopt VersieInfo template

← Oudere versie		Versie van 2 aug 2022 10:48
Regel 1:		Regel 1:
	__NOINDEX__		__NOINDEX__
	{{DISPLAYTITLE:eOverdracht 4.0~~-RC5~~ FHIR Implementation Guide}}		{{DISPLAYTITLE:eOverdracht {{VersieInfo\|eOverdracht\|release=V4.0}} FHIR Implementation Guide}}
	__NUMBEREDHEADINGS__		__NUMBEREDHEADINGS__
	=Introduction=		=Introduction=
Regel 175:		Regel 175:
	=FHIR profiles=		=FHIR profiles=
	{{NoteBox\|eOverdracht uses the [[FHIR:V1.0_FHIR_IG_STU3#FHIR_Packages\|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 version of the information standard uses the following packages:		{{NoteBox\|eOverdracht uses the [[FHIR:V1.0_FHIR_IG_STU3#FHIR_Packages\|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 version of the information standard uses the following packages:
	* [https://simplifier.net/packages/nictiz.fhir.nl.stu3.eoverdracht nictiz.fhir.nl.stu3.eoverdracht, version 1.0.0~~-rc5~~]		* [https://simplifier.net/packages/nictiz.fhir.nl.stu3.eoverdracht nictiz.fhir.nl.stu3.eoverdracht, version {{VersieInfo\|nictiz.fhir.nl.stu3.eoverdracht\|release=V4.0}}]
	* [https://simplifier.net/packages/nictiz.fhir.nl.stu3.zib2017 nictiz.fhir.nl.stu3.zib2017, version 2.1.0 or compatible]		* [https://simplifier.net/packages/nictiz.fhir.nl.stu3.zib2017 nictiz.fhir.nl.stu3.zib2017, version 2.1.0 or compatible]
	* [https://simplifier.net/packages/nictiz.fhir.nl.stu3.zib2020-preadopt nictiz.fhir.nl.stu3.zib2020-preadopt, version 0.0.1-~~beta1~~]		* [https://simplifier.net/packages/nictiz.fhir.nl.stu3.zib2020-preadopt nictiz.fhir.nl.stu3.zib2020-preadopt, version {{VersieInfo\|nictiz.fhir.nl.stu3.zib2020-preadopt\|release=V4.0}}]

	'''Note''': packages use [https://semver.org/ 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.}}		'''Note''': packages use [https://semver.org/ 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.}}

Pieter Edelman: EOVDR-177: Make clear that the initial Task.status for a transfer should be "in-progress"

2022-07-25T06:50:46Z

EOVDR-177: Make clear that the initial Task.status for a transfer should be "in-progress"

← Oudere versie		Versie van 25 jul 2022 06:50
Regel 166:		Regel 166:
	\|}		\|}
	===Partial workflow===		===Partial workflow===
	When the transfer has to be carried out without the negotiation phase, the sending XIS will create the Task instance with {{fhir\|Task.status}} already set to {{term\|~~accepted~~}} and {{fhir\|Task.input:nursingHandoff}} populated.		When the transfer has to be carried out without the negotiation phase, the sending XIS will create the Task instance with {{fhir\|Task.status}} already set to {{term\|in-progress}} and {{fhir\|Task.input:nursingHandoff}} populated.

	===Brokers===		===Brokers===

Pieter Edelman: Bump package level to version 1.0.0-rc5

2022-04-21T10:47:43Z

Bump package level to version 1.0.0-rc5

← Oudere versie		Versie van 21 apr 2022 10:47
Regel 187:		Regel 187:
	\|-		\|-
	\| eOverdracht Task		\| eOverdracht Task
	\| {{Simplifier\|http://nictiz.nl/fhir/StructureDefinition/eOverdracht-Task\|nictiz.fhir.nl.stu3.eoverdracht\|pkgVersion=1.0.0-~~rc1~~}}		\| {{Simplifier\|http://nictiz.nl/fhir/StructureDefinition/eOverdracht-Task\|nictiz.fhir.nl.stu3.eoverdracht\|pkgVersion=1.0.0-rc5}}
	\|-		\|-
	\| Composition for advance notice (Aanmeldbericht)		\| Composition for advance notice (Aanmeldbericht)
	\| {{Simplifier\|http://nictiz.nl/fhir/StructureDefinition/eOverdracht-AdvanceNotice\|nictiz.fhir.nl.stu3.eoverdracht\|pkgVersion=1.0.0-~~rc1~~}}		\| {{Simplifier\|http://nictiz.nl/fhir/StructureDefinition/eOverdracht-AdvanceNotice\|nictiz.fhir.nl.stu3.eoverdracht\|pkgVersion=1.0.0-rc5}}
	\|-		\|-
	\| Composition for nursing handoff adults (Overdrachtsbericht volwassenen)		\| Composition for nursing handoff adults (Overdrachtsbericht volwassenen)
	\| {{Simplifier\|http://nictiz.nl/fhir/StructureDefinition/eOverdracht-NursingHandoff-Adults\|nictiz.fhir.nl.stu3.eoverdracht\|pkgVersion=1.0.0-~~rc1~~}}		\| {{Simplifier\|http://nictiz.nl/fhir/StructureDefinition/eOverdracht-NursingHandoff-Adults\|nictiz.fhir.nl.stu3.eoverdracht\|pkgVersion=1.0.0-rc5}}
	\|-		\|-
	\| Composition for nursing handoff childcare 0-1 yo (Overdrachtsbericht kinderen 0-1 jaar)		\| Composition for nursing handoff childcare 0-1 yo (Overdrachtsbericht kinderen 0-1 jaar)
	\| {{Simplifier\|http://nictiz.nl/fhir/StructureDefinition/eOverdracht-NursingHandoff-Childcare-0-1yo\|nictiz.fhir.nl.stu3.eoverdracht\|pkgVersion=1.0.0-~~rc1~~}}		\| {{Simplifier\|http://nictiz.nl/fhir/StructureDefinition/eOverdracht-NursingHandoff-Childcare-0-1yo\|nictiz.fhir.nl.stu3.eoverdracht\|pkgVersion=1.0.0-rc5}}
	\|-		\|-
	\| Composition for nursing handoff childcare 1-18 yo (Overdrachtsbericht kinderen 1-18 jaar)		\| Composition for nursing handoff childcare 1-18 yo (Overdrachtsbericht kinderen 1-18 jaar)
	\| {{Simplifier\|http://nictiz.nl/fhir/StructureDefinition/eOverdracht-NursingHandoff-Childcare-1-18yo\|nictiz.fhir.nl.stu3.eoverdracht\|pkgVersion=1.0.0-~~rc1~~}}		\| {{Simplifier\|http://nictiz.nl/fhir/StructureDefinition/eOverdracht-NursingHandoff-Childcare-1-18yo\|nictiz.fhir.nl.stu3.eoverdracht\|pkgVersion=1.0.0-rc5}}
	\|}		\|}

Pieter Edelman: Bump package level to version 1.0.0-rc5

2022-04-21T10:46:05Z

Bump package level to version 1.0.0-rc5

← Oudere versie		Versie van 21 apr 2022 10:46
Regel 175:		Regel 175:
	=FHIR profiles=		=FHIR profiles=
	{{NoteBox\|eOverdracht uses the [[FHIR:V1.0_FHIR_IG_STU3#FHIR_Packages\|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 version of the information standard uses the following packages:		{{NoteBox\|eOverdracht uses the [[FHIR:V1.0_FHIR_IG_STU3#FHIR_Packages\|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 version of the information standard uses the following packages:
	* [https://simplifier.net/packages/nictiz.fhir.nl.stu3.eoverdracht nictiz.fhir.nl.stu3.eoverdracht, version 1.0.0-~~rc3~~]		* [https://simplifier.net/packages/nictiz.fhir.nl.stu3.eoverdracht nictiz.fhir.nl.stu3.eoverdracht, version 1.0.0-rc5]
	* [https://simplifier.net/packages/nictiz.fhir.nl.stu3.zib2017 nictiz.fhir.nl.stu3.zib2017, version 2.1.0 or compatible]		* [https://simplifier.net/packages/nictiz.fhir.nl.stu3.zib2017 nictiz.fhir.nl.stu3.zib2017, version 2.1.0 or compatible]
	* [https://simplifier.net/packages/nictiz.fhir.nl.stu3.zib2020-preadopt nictiz.fhir.nl.stu3.zib2020-preadopt, version 0.0.1-beta1]		* [https://simplifier.net/packages/nictiz.fhir.nl.stu3.zib2020-preadopt nictiz.fhir.nl.stu3.zib2020-preadopt, version 0.0.1-beta1]

Pieter Edelman: EOVDR-70: Change the notification mechanism by adding a resource.id to the POST

2022-04-20T18:15:59Z

EOVDR-70: Change the notification mechanism by adding a resource.id to the POST

← Oudere versie		Versie van 20 apr 2022 18:15
Regel 52:		Regel 52:

	===Task invocations===		===Task invocations===
	~~[[#Notifications\|Notifications]] to the~~ receiving XIS ~~are not expected to contain a logical id to~~ the Task~~. Hence,~~ the ~~receiving~~ XIS ~~should use a combination of a search interaction and~~ the ~~{{fhir~~\|~~_lastUpdated}} search parameter to retrieve the eOverdracht Tasks that have been added are changed since the last invocation~~:		The receiving XIS can query the Task at the sending XIS by using the Task.id which is communicated in the [[#Notifications\|notification]]:
	GET base/Task~~?code=<nowiki>http:~~/~~/snomed~~.~~info/sct</nowiki>\|308292007&_lastUpdated=ge[time of last request~~]		GET base/Task/[Task.id]

	'''Note 1''': More than one result can be returned, for example when an additional Task can have been modified before the notification has been sent, when the receiving XIS choose to batch search interactions, etc.		'''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.

	~~'''Note 2~~''': It is up to the receiving XIS to ~~detect~~ if ~~a result~~ is a new Task ~~instance~~ or ~~a change~~ to an existing ~~instance~~, and if so, what ~~has been changed since~~ the ~~last invocation~~.

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

	PUT base/Task/[id]		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 a HTTP 422 status code and an OperationOutcome detailing the problem.		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 a HTTP 422 status code and an OperationOutcome detailing the problem.

	===Notifications===		===Notifications===
	It is expected that the sending XIS will notify the receiving XIS when a new Task is created or when an existing Task is updated. Although the notification mechanism is out of scope for the eOverdracht information standard, ~~it is assumed that~~ the notification ~~does not contain a~~ Task ~~resource~~ id. ~~Rather, it signals that~~ the ~~receiving server should perform~~ a ~~search~~ at the ~~sending server to look for additions or changes in~~ the ~~eOverdracht~~ Task ~~resources~~.		It is expected that the sending XIS will notify the receiving XIS when a new Task is created or when an existing Task is updated. Although the notification mechanism is out of scope for the eOverdracht information standard, the notification SHALL communicate the {{fhir\|Task.id}} to the receiving XIS.

			A straightforward implementation for this notification mechanism is for the notifying party to make an empty POST request on a pre-determined endpoint at the party that should be notified, with the {{fhir\|Task.id}} appended as path component:
			POST [base]/[Task.id]

	~~A straightforward implementation for this notification mechanism~~ is ~~for~~ the notifying ~~party to make an empty POST request on a pre-determined endpoint at the~~ party that ~~should be notified. This could be arranged using~~ the ~~FHIR subscriptions mechanism, but the endpoints could also be arranged by other means~~.		The notified party is expected to respond with HTTP status code ''202 Accepted'' to inform the notifying party that the notification was successfully received.

	==Use of the Composition resource==		==Use of the Composition resource==
Regel 76:		Regel 77:
	===Composition invocations===		===Composition invocations===
	The receiving XIS MAY use either of the following mechanism for retrieving the individual FHIR resources referenced in the Compostion resource.		The receiving XIS MAY use either of the following mechanism for retrieving the individual FHIR resources referenced in the Compostion resource.
	; 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/[id]/$document</pre>''Note:'' the Compositions list just the resources that act as the entry point for the various concepts in the eOverdracht transactions, but each of these referenced resources may further refer other resources not listed there. The sending system SHALL produce a complete Bundle containing not only the resources listed directly in the Composition, but all the indirectly referenced resources as well.		; 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 Compositions list just the resources that act as the entry point for the various concepts in the eOverdracht transactions, but each of these referenced resources may further refer other resources not listed there. The sending system SHALL produce a complete Bundle containing not only 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/[id]</pre>Then the necessary other resources referenced can be fetched using a <code>GET</code> interaction.		; 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 a <code>GET</code> interaction.

	The sending XIS SHALL support both mechanisms.		The sending XIS SHALL support both mechanisms.
Regel 161:		Regel 162:
	!Negotiate alternative date		!Negotiate alternative date
	\|- style="vertical-align: top;"		\|- style="vertical-align: top;"
	\| [[Bestand:~~EOverdracht~~-HappyFlow.svg\|none\|top]]		\| [[Bestand:2022-03-18-eOverdracht-HappyFlow.svg\|none\|top]]
	\| [[Bestand:~~EOverdracht~~-AlternativeDate.svg\|none\|top]]		\| [[Bestand:2022-03-18-eOverdracht-AlternativeDate.svg\|none\|top]]
	\|}		\|}
	===Partial workflow===		===Partial workflow===

Mik de Jong: RC5 toegevoegd aan titel

2022-04-20T16:29:39Z

RC5 toegevoegd aan titel

← Oudere versie		Versie van 20 apr 2022 16:29
Regel 1:		Regel 1:
	__NOINDEX__		__NOINDEX__
	{{DISPLAYTITLE:eOverdracht 4.0 FHIR Implementation Guide}}		{{DISPLAYTITLE:eOverdracht 4.0-RC5 FHIR Implementation Guide}}
	__NUMBEREDHEADINGS__		__NUMBEREDHEADINGS__
	=Introduction=		=Introduction=

Pieter Edelman: Create prepub environment from vpk:V4.0

2022-03-03T15:19:04Z

Create prepub environment from vpk:V4.0

← Oudere versie		Versie van 3 mrt 2022 15:19
Regel 1:		Regel 1:
			__NOINDEX__
	{{DISPLAYTITLE:eOverdracht 4.0 FHIR Implementation Guide}}		{{DISPLAYTITLE:eOverdracht 4.0 FHIR Implementation Guide}}
	__NUMBEREDHEADINGS__		__NUMBEREDHEADINGS__
	=Introduction=		=Introduction=

	This is the implementation guide for the information standard eOverdracht, version 4.0. This standard is described in [[vpk:V4.0_Ontwerp eOverdracht\|this functional specification]] and implemented here using [https://www.hl7.org/fhir/stu3/ FHIR(STU3) HL7 FHIR, STU3]. This implementation guide assumes that the reader is familiar with this FHIR version.		This is the implementation guide for the information standard eOverdracht, version 4.0. This standard is described in [[vpk:Vprepub-4.0_Ontwerp eOverdracht\|this functional specification]] and implemented here using [https://www.hl7.org/fhir/stu3/ FHIR(STU3) HL7 FHIR, STU3]. This implementation guide assumes that the reader is familiar with this FHIR version.

	Apart from this document, the guidelines as specified in [[FHIR:V1.0 FHIR IG STU3\|general FHIR Implementation Guide]] apply. In particular, the reader should take note of the [[FHIR:V1.0_FHIR_IG_STU3#Use_case_overarching_principles\|Use case overarching principles]] and the use of [[FHIR:V1.0_FHIR_IG_STU3#FHIR_Packages\|FHIR packages]].		Apart from this document, the guidelines as specified in [[FHIR:V1.0 FHIR IG STU3\|general FHIR Implementation Guide]] apply. In particular, the reader should take note of the [[FHIR:V1.0_FHIR_IG_STU3#Use_case_overarching_principles\|Use case overarching principles]] and the use of [[FHIR:V1.0_FHIR_IG_STU3#FHIR_Packages\|FHIR packages]].