Zandbak/MVPTO - Bewerkingsoverzicht

Maarten Ligtvoet: Tekst vervangen - "{{#customtitle:" door "{{DISPLAYTITLE:"

2020-07-20T00:59:28Z

Tekst vervangen - "{{#customtitle:" door "{{DISPLAYTITLE:"

← Oudere versie		Versie van 20 jul 2020 00:59
Regel 1:		Regel 1:
	__NUMBEREDHEADINGS__		__NUMBEREDHEADINGS__
	{{~~#customtitle~~:MedMij FHIR Implementation Guide: Questionnaires {{Sjabloon:VersieInfo\|V2019.01\|Vragenlijsten}}}}		{{DISPLAYTITLE:MedMij FHIR Implementation Guide: Questionnaires {{Sjabloon:VersieInfo\|V2019.01\|Vragenlijsten}}}}
	{{MedMij:Vdraft_Issuebox_FHIR_IG}}		{{MedMij:Vdraft_Issuebox_FHIR_IG}}

Pieter Edelman op 17 mrt 2020 om 14:55

2020-03-17T14:55:28Z

← Oudere versie		Versie van 17 mrt 2020 14:55
Regel 48:		Regel 48:
	* updates the Task		* updates the Task
	* sends the QuestionnaireResponse		* sends the QuestionnaireResponse
	\| ~~[https~~://~~simplifier~~.~~net~~/~~nictizstu3-~~questionnaires~~/questionnairereference~~-clientcapabilities CapabilityStatement: Client]		\| {{Simplifier\|http://nictiz.nl/fhir/CapabilityStatement/questionnaires-clientcapabilities\|CapabilityStatement: Client}}
	\| FHIR Client requirements		\| FHIR Client requirements
	\|-		\|-
Regel 58:		Regel 58:
	* receives updates to the Task		* receives updates to the Task
	* receives the QuestionnaireResponse		* receives the QuestionnaireResponse
	\| ~~[https~~://~~simplifier~~.~~net~~/~~nictizstu3-~~questionnaires~~/questionnairereference~~-servercapabilities CapabilityStatement: Server]		\| {{Simplifier\|http://nictiz.nl/fhir/CapabilityStatement/questionnaires-servercapabilities\|CapabilityStatement: Server}}
	\| FHIR Server requirements		\| FHIR Server requirements
	\|-		\|-
Regel 66:		Regel 66:
	\| Healthcare information system or third party FHIR server		\| Healthcare information system or third party FHIR server
	* provides Questionnaire resource in XML and JSON formats		* provides Questionnaire resource in XML and JSON formats
	\| ~~[https~~://~~simplifier~~.~~net~~/~~nictizstu3-~~questionnaires~~/questionnairereference~~-repositorycapabilities CapabilityStatement: Questionnaire repository]		\| {{Simplifier\|http://nictiz.nl/fhir/CapabilityStatement/questionnaires-repositorycapabilities\|CapabilityStatement: Questionnaire repository}}
	\| Questionnaire repository requirements		\| Questionnaire repository requirements
	\|}		\|}

Niek van Galen: /* Actors involved */ Task naamgeving aangepast

2020-03-17T14:30:46Z

Actors involved: Task naamgeving aangepast

← Oudere versie		Versie van 17 mrt 2020 14:30
Regel 55:		Regel 55:
	\| XIS		\| XIS
	\| Healthcare information system		\| Healthcare information system
	* provides a ~~QuestionnaireReferenceTask~~		* provides a Questionnaires-Task
	* receives updates to the Task		* receives updates to the Task
	* receives the QuestionnaireResponse		* receives the QuestionnaireResponse

Niek van Galen: /* List of invocations */ Canonical van Task aangepast

2020-03-17T14:30:18Z

List of invocations: Canonical van Task aangepast

← Oudere versie		Versie van 17 mrt 2020 14:30
Regel 81:		Regel 81:
	[[Bestand:Afsprakenstelsel-01.png\|link=https://www.medmij.nl/afsprakenstelsel/\|rechts \|100px\|Go to Afsprakenstelsel]]		[[Bestand:Afsprakenstelsel-01.png\|link=https://www.medmij.nl/afsprakenstelsel/\|rechts \|100px\|Go to Afsprakenstelsel]]

	The order of invocations follows the [https://informatiestandaarden.nictiz.nl/wiki/MedMij:Vdraft_OntwerpVragenlijsten functional design]. At first the questionnaire is assigned to the patient by a ~~QuestionnaireReferenceTask~~ resource. The PHR extracts the reference to the Questionnaire resource and retrieves it from the XIS or from a questionnaire repository (VRE).		The order of invocations follows the [https://informatiestandaarden.nictiz.nl/wiki/MedMij:Vdraft_OntwerpVragenlijsten functional design]. At first the questionnaire is assigned to the patient by a Questionnaires-Task resource. The PHR extracts the reference to the Questionnaire resource and retrieves it from the XIS or from a questionnaire repository (VRE).

	This FHIR implementation guide assumes that the PHR system is able to make a connection to search Task resources at the XIS. It does not provide information on finding the right XIS nor does it provide information about security. These infrastructure and interface specifications are described in the [https://www.medmij.nl/afsprakenstelsel/ 'MedMij Afsprakenstelsel'].		This FHIR implementation guide assumes that the PHR system is able to make a connection to search Task resources at the XIS. It does not provide information on finding the right XIS nor does it provide information about security. These infrastructure and interface specifications are described in the [https://www.medmij.nl/afsprakenstelsel/ 'MedMij Afsprakenstelsel'].

	===Client searches ~~QuestionnaireReferenceTask~~ - PHR===		===Client searches Questionnaires-Task - PHR===
	Using a [http://hl7.org/fhir/STU3/search.html search operation], the PHR retrieves a Task resource containing a reference to the questionnaire from the XIS. The Task SHALL conform to the [[#List_of_StructureDefinitions\|~~QuestionnaireReferenceTask~~ profile]] and SHALL initially have <code>Task.status</code> set to "requested" (see [[#Task state machine]]). The Questionnaire resource SHALL be referenced using <code>Task.input.valueReference.reference</code>.		Using a [http://hl7.org/fhir/STU3/search.html search operation], the PHR retrieves a Task resource containing a reference to the questionnaire from the XIS. The Task SHALL conform to the [[#List_of_StructureDefinitions\|Questionnaires-Task profile]] and SHALL initially have <code>Task.status</code> set to "requested" (see [[#Task state machine]]). The Questionnaire resource SHALL be referenced using <code>Task.input.valueReference.reference</code>.

	GET [base]/Task/?code=<nowiki>http://loinc.org\|74468-0</nowiki>&status=requested&_include=Task:requester		GET [base]/Task/?code=<nowiki>http://loinc.org\|74468-0</nowiki>&status=requested&_include=Task:requester

Niek van Galen: /* FHIR profiles */ Canonical van Task aangepast

2020-03-17T14:28:49Z

FHIR profiles: Canonical van Task aangepast

← Oudere versie		Versie van 17 mrt 2020 14:28
Regel 322:		Regel 322:
	\|		\|
	\|-		\|-
	\| {{Simplifier\|http://nictiz.nl/fhir/StructureDefinition/~~QuestionnaireReferenceTask~~}}		\| {{Simplifier\|http://nictiz.nl/fhir/StructureDefinition/Questionnaires-Task}}
	\| Task		\| Task
	\|		\|

Pieter Edelman: Note about versioning references

2020-03-17T14:14:47Z

Note about versioning references

← Oudere versie		Versie van 17 mrt 2020 14:14
Regel 129:		Regel 129:
	A PHR MAY support other Questionnaire item types as well. However, if a PHR is unable to process any one part in the Questionnaire, it MUST reject the Questionnaire altogether, see below.		A PHR MAY support other Questionnaire item types as well. However, if a PHR is unable to process any one part in the Questionnaire, it MUST reject the Questionnaire altogether, see below.

	'''Note''': for known questionnaires, a PHR may choose to use hardcoded instead of generated forms. However, a PHR implementing this information standard should always be able to generate a form for the minimal Questionnaire requirements. Also note that a known questionnaire can only be recognized by its reference in the Task; currently, no coding system exists to identify known questionnaires. It is up to the PHR to check whether the referenced Questionnaire is the same as the ~~excpected~~ Questionnaire.		'''Note''': for known questionnaires, a PHR may choose to use hardcoded instead of generated forms. However, a PHR implementing this information standard should always be able to generate a form for the minimal Questionnaire requirements. Also note that a known questionnaire can only be recognized by its reference in the Task; currently, no coding system exists to identify known questionnaires. Although the XIS MUST use version specific references, it is up to the PHR to check whether the referenced Questionnaire is the same as the expected Questionnaire.

	===Multiple-choice questions in FHIR===		===Multiple-choice questions in FHIR===

Niek van Galen: /* Tracking the status using the Task resource */ tekstuele wijzigingen

2020-03-17T11:23:06Z

Tracking the status using the Task resource: tekstuele wijzigingen

← Oudere versie		Versie van 17 mrt 2020 11:23
Regel 257:		Regel 257:

	==Introduction==		==Introduction==
	Retreiving the questionnaire and sending the answers are two separate use cases, but they are meant to be used back-to-back; the XIS that prescribes the questionnaire ultimately expects a response to it (and a questionnaire response is only sent in response to a prescription, at least in the current version). To track the status of the prescription fullfillment, a Task resource at the XIS server is used, which transitions through various stages until completion.		Retreiving the questionnaire and sending the answers are two separate use cases, but they are meant to be used back-to-back; the XIS that prescribes the questionnaire ultimately expects a response to it (and a questionnaire response is only sent in response to a prescription, at least in the current version of this information standard). To track the status of the prescription fullfillment, a Task resource at the XIS server is used, which transitions through various stages until completion.

	It is the responsibility of the PHR to update the task at the different stages in the life cycle of the questionnaire, using an ~~<code>~~update~~</code>~~ operation (see [[#Updating the Task]]). This implies that the the Task resource should be made accessible by the XIS server for these updates, at least for the expected ~~life time~~ of the fullfillment cycle. Additionally, the PHR may perform a ~~<code>~~read~~</code>~~ of the Task resource at any time.		It is the responsibility of the PHR to update the task at the different stages in the life cycle of the questionnaire, using an update operation (see [[#Updating the Task]]). This implies that the the Task resource should be made accessible by the XIS server for these updates, at least for the expected lifetime of the fullfillment cycle. Additionally, the PHR may perform a [https://www.hl7.org/fhir/stu3/http.html#read read operation] of the Task resource at any time.

	It is primarilly the responsibility of the PHR to bring the task to a closed state. However, it is not guaranteed that the required update operation succeeds. If the PHR is unable to bring the task to a closed state, the server may eventually close the task because of business rules.		It is primarilly the responsibility of the PHR to bring the task to a closed state. However, it is not guaranteed that the required update operation succeeds. If the PHR is unable to bring the task to a closed state, the server may eventually close the task because of business rules.
Regel 274:		Regel 274:
	\--> rejected -----------------------/		\--> rejected -----------------------/
	</pre>		</pre>
	~~TODO: uittekenen.~~

	Only the ~~transactions~~ shown here are allowed. The server ~~should~~ reject any update that attempts to perform an illegal ~~transaction~~. See [[#Task update failures]].		Only the transitions shown here are allowed. The server SHOULD reject any update that attempts to perform an illegal transition. See [[#Task update failures]].

	==Updating the Task==		==Updating the Task==
Regel 285:		Regel 284:
	Where ORIGINAL_ID is the Task.id from the Task originally received from the XIS.		Where ORIGINAL_ID is the Task.id from the Task originally received from the XIS.

	'''Note''': ~~apart from the relevant modifications,~~ the Task resource ~~should~~ be sent completely and without changes.		'''Note''': the Task resource SHOULD be sent completely and without changes, apart from the relevant modifications.

	The server may be unable to accept an update the Task resource due to errors or because of business rules (e.g. because of an illegal status ~~transaction~~). In this case, the server ~~should~~ respond with a 400 type status code, accompanied by an OperationOutcome resource providing additional details (see [https://www.hl7.org/fhir/stu3/http.html#2.21.0.10.1. the FHIR documentation on rejecting updates]).		The server may be unable to accept an update the Task resource due to errors or because of business rules (e.g. because of an illegal status transition). In this case, the server SHOULD respond with a 400 type status code, accompanied by an OperationOutcome resource providing additional details (see [https://www.hl7.org/fhir/stu3/http.html#2.21.0.10.1. the FHIR documentation on rejecting updates]).

	The PHR should try to recover from this response. If this is not possible, the PHR ~~should~~ attempt to update the status of the Task resource on the server to "failed" and stop further processing. If it is not possible to perform this task update, the task effectively remains in a stalled position. The server may eventually close it because of business rules.		The PHR should try to recover from this response. If this is not possible, the PHR SHOULD attempt to update the status of the Task resource on the server to "failed" and stop further processing. If it is not possible to perform this task update, the task effectively remains in a stalled position. The server may eventually close it because of business rules.

	=FHIR profiles, interactions, search parameters=		=FHIR profiles, interactions, search parameters=

Niek van Galen: /* Use case: send questionnaire response */ tekstuele wijzigingen, example Q+QR toegevoegd voor gebruik item.option

2020-03-17T11:10:18Z

Use case: send questionnaire response: tekstuele wijzigingen, example Q+QR toegevoegd voor gebruik item.option

Wijzigingen bekijken

Niek van Galen: /* Use case: retrieve questionnaire */ Note weggehaald

2020-03-17T10:25:07Z

Use case: retrieve questionnaire: Note weggehaald

← Oudere versie		Versie van 17 mrt 2020 10:25
Regel 98:		Regel 98:

	The Questionnaire resource SHALL conform to the [[#List_of_StructureDefinitions\|Questionnaire profile]].		The Questionnaire resource SHALL conform to the [[#List_of_StructureDefinitions\|Questionnaire profile]].

	'''Note''': for known questionnaires, a PHR may choose to use hardcoded instead of generated forms. However, a PHR implementing this information standard should always be able to generate a form for the [[#Client_renders_questionnaire_form_-_PHR\|minimal Questionnaire requirements]]. Also note that a known questionnaire can only be recognized by its reference in the Task; currently, no coding system exists to identify known questionnaires. It is up to the PHR to check whether the referenced Questionnaire is the same as the excpected Questionnaire.

	If this operation fails (after repeated attempts), the PHR should close the task with status "failed" (see [[#Updating the Task]]). This closes the Task and ends the workflow (see [[#Task state machine]]).		If this operation fails (after repeated attempts), the PHR should close the task with status "failed" (see [[#Updating the Task]]). This closes the Task and ends the workflow (see [[#Task state machine]]).

Niek van Galen: /* Use case: retrieve questionnaire */ Tekstuele aanpassingen

2020-03-17T10:23:17Z

Use case: retrieve questionnaire: Tekstuele aanpassingen

← Oudere versie		Versie van 17 mrt 2020 10:23
Regel 81:		Regel 81:
	[[Bestand:Afsprakenstelsel-01.png\|link=https://www.medmij.nl/afsprakenstelsel/\|rechts \|100px\|Go to Afsprakenstelsel]]		[[Bestand:Afsprakenstelsel-01.png\|link=https://www.medmij.nl/afsprakenstelsel/\|rechts \|100px\|Go to Afsprakenstelsel]]

	The order of invocations follows the [https://informatiestandaarden.nictiz.nl/wiki/MedMij:Vdraft_OntwerpVragenlijsten ~~Functional Design~~]. At first the questionnaire is assigned to the patient by a QuestionnaireReferenceTask resource. The PHR extracts the reference to the Questionnaire resource and retrieves it from the XIS or from ~~an external~~ questionnaire repository.		The order of invocations follows the [https://informatiestandaarden.nictiz.nl/wiki/MedMij:Vdraft_OntwerpVragenlijsten functional design]. At first the questionnaire is assigned to the patient by a QuestionnaireReferenceTask resource. The PHR extracts the reference to the Questionnaire resource and retrieves it from the XIS or from a questionnaire repository (VRE).

	This FHIR implementation guide assumes that the PHR system is able to make a connection to search Task resources at the XIS. It does not provide information on finding the right XIS nor does it provide information about security. These infrastructure and interface specifications are described in the [https://www.medmij.nl/afsprakenstelsel/ 'MedMij Afsprakenstelsel'].		This FHIR implementation guide assumes that the PHR system is able to make a connection to search Task resources at the XIS. It does not provide information on finding the right XIS nor does it provide information about security. These infrastructure and interface specifications are described in the [https://www.medmij.nl/afsprakenstelsel/ 'MedMij Afsprakenstelsel'].

	===Client ~~gets Questionnaire reference~~ - PHR===		===Client searches QuestionnaireReferenceTask - PHR===
	Using a [http://hl7.org/fhir/STU3/search.html search operation], the PHR ~~provides~~ a Task resource containing a reference to the ~~patient~~ questionnaire from the XIS. The Task SHALL conform to the ~~MedMij~~ [[#List_of_StructureDefinitions\|QuestionnaireReferenceTask profile]] SHALL initially have Task.status set to "requested" (see [[#Task state machine]]). The Questionnaire resource SHALL be referenced using Task.input.valueReference.reference.		Using a [http://hl7.org/fhir/STU3/search.html search operation], the PHR retrieves a Task resource containing a reference to the questionnaire from the XIS. The Task SHALL conform to the [[#List_of_StructureDefinitions\|QuestionnaireReferenceTask profile]] and SHALL initially have <code>Task.status</code> set to "requested" (see [[#Task state machine]]). The Questionnaire resource SHALL be referenced using <code>Task.input.valueReference.reference</code>.

	GET [base]/Task/?code=<nowiki>http://loinc.org\|74468-0</nowiki>&status=requested~~&_include=Task:patient~~&_include=Task:requester		GET [base]/Task/?code=<nowiki>http://loinc.org\|74468-0</nowiki>&status=requested&_include=Task:requester

	If the search operation fails ~~'''~~(cannot be executed, not that there are no matches)~~'''~~, the return value is a status code 4xx or 5xx with an OperationOutcome (see [http://hl7.org/fhir/STU3/search.html#errors the FHIR documentation on search]).		If the search operation fails (cannot be executed, not that there are no matches), the return value is a status code 4xx or 5xx with an OperationOutcome (see [http://hl7.org/fhir/STU3/search.html#errors the FHIR documentation on search]).

	===Client ~~gets~~ Questionnaire - PHR===		===Client retrieves Questionnaire - PHR===
	Upon retreiving the Task, the PHR ~~system retreives~~ the Questionnaire resource referenced in the Task using a [https://www.hl7.org/fhir/stu3/http.html#read read operation]. This reference may live on the same base as the XIS or may be ~~an external reference~~.		Upon retreiving the Task, the PHR retrieves the Questionnaire resource referenced in the Task using a [https://www.hl7.org/fhir/stu3/http.html#read read operation]. This reference may live on the same base as the XIS or may be a questionnaire repository (VRE).

	GET ''Task.input.valueReference.reference.value''		GET ''Task.input.valueReference.reference.value''

	The Questionnaire resource SHALL conform to the ~~MedMij~~ [[#List_of_StructureDefinitions\|Questionnaire profile]].		The Questionnaire resource SHALL conform to the [[#List_of_StructureDefinitions\|Questionnaire profile]].

	'''Note''': for known questionnaires, a PHR may choose to use hardcoded instead of generated forms. However, ~~PHRs~~ implementing this information standard should always be able to generate a form for the minimal Questionnaire ~~subset defined below~~. Also note that a known questionnaire can only be recognized by its reference in the Task; currently, no coding system exists to identify known questionnaires.		'''Note''': for known questionnaires, a PHR may choose to use hardcoded instead of generated forms. However, a PHR implementing this information standard should always be able to generate a form for the [[#Client_renders_questionnaire_form_-_PHR\|minimal Questionnaire requirements]]. Also note that a known questionnaire can only be recognized by its reference in the Task; currently, no coding system exists to identify known questionnaires. It is up to the PHR to check whether the referenced Questionnaire is the same as the excpected Questionnaire.

	If this operation fails (after repeated attempts), the PHR should close the task with status "failed" (see [[#Updating the Task]]). This closes the Task and ends the workflow (see [[#Task state machine]]).		If this operation fails (after repeated attempts), the PHR should close the task with status "failed" (see [[#Updating the Task]]). This closes the Task and ends the workflow (see [[#Task state machine]]).