mp:V2.0.0 MedicationProcess9 FHIR - Bewerkingsoverzicht

Jorn Duwel: Add section tag

2022-11-04T11:17:27Z

Add section tag

← Oudere versie		Versie van 4 nov 2022 11:17
Regel 313:		Regel 313:
	= Transactions =		= Transactions =
	This section describes the FHIR implementation of all transactions listed in [[mp:V2.0.0_Ontwerp_medicatieproces_9_ENG#Information_systems_and_transactions\|section 7 of the functional specification]]. Transactions are paired per transaction group. Each subsection below hyperlinks the names of the transaction groups and transactions to the functional definition in an ART-DECOR publication. The ART-DECOR publication details which data elements are expected to be supported ([[Handleiding_Kardinaliteiten_en_conformance\|cardinality and conformance]]) for each transaction. Where the functional specification uses the terms ‘Consulting’ and ‘Making available’, this IG uses the terms ‘Retrieving’ and ‘Serving’.		This section describes the FHIR implementation of all transactions listed in [[mp:V2.0.0_Ontwerp_medicatieproces_9_ENG#Information_systems_and_transactions\|section 7 of the functional specification]]. Transactions are paired per transaction group. Each subsection below hyperlinks the names of the transaction groups and transactions to the functional definition in an ART-DECOR publication. The ART-DECOR publication details which data elements are expected to be supported ([[Handleiding_Kardinaliteiten_en_conformance\|cardinality and conformance]]) for each transaction. Where the functional specification uses the terms ‘Consulting’ and ‘Making available’, this IG uses the terms ‘Retrieving’ and ‘Serving’.
			<section begin=medmij />
	== Medication data (Retrieve/Serve) ==		== Medication data (Retrieve/Serve) ==
	The retrieve medication data transaction is used by the client to retrieve medication data from a server. The client can retrieve its desired information by searching for specific medication building blocks.		The retrieve medication data transaction is used by the client to retrieve medication data from a server. The client can retrieve its desired information by searching for specific medication building blocks.
Regel 540:		Regel 540:
	\| {{Simplifier\|http://nictiz.nl/fhir/StructureDefinition/nl-core-HealthcareProvider-Organization\|nictiz.fhir.nl.r4.nl-core\|pkgVersion=0.5.0-beta1}}		\| {{Simplifier\|http://nictiz.nl/fhir/StructureDefinition/nl-core-HealthcareProvider-Organization\|nictiz.fhir.nl.r4.nl-core\|pkgVersion=0.5.0-beta1}}
	\|}		\|}
			<section end=medmij />
	== Medication data (Send/Receive) ==		== Medication data (Send/Receive) ==
	The send medication data transaction is used by the client to send medication data to a server.		The send medication data transaction is used by the client to send medication data to a server.

Jorn Duwel: /* Actionable tag */ - Placed IssueBox

2022-08-01T14:53:33Z

Actionable tag: - Placed IssueBox

← Oudere versie		Versie van 1 aug 2022 14:53
Regel 225:		Regel 225:
	To differentiate between sending or serving building blocks that are either of informative nature or of actionable nature, the {{term\|actionable}} tag is used. [https://hl7.org/fhir/r4/resource.html#tag Tags] are {{datatype\|Coding}} elements present in {{fhir\|Resource.meta.tag}} used for workflow management.		To differentiate between sending or serving building blocks that are either of informative nature or of actionable nature, the {{term\|actionable}} tag is used. [https://hl7.org/fhir/r4/resource.html#tag Tags] are {{datatype\|Coding}} elements present in {{fhir\|Resource.meta.tag}} used for workflow management.

			{{IssueBox\|1= The following paragraph speaks of {{fhir\|.value}}, where {{fhir\|.code}} is meant. This will be fixed in a next version of this IG, see [https://bits.nictiz.nl/browse/MP-714 MP-714]. }}
	If applicable, the profiles used by a transaction require the use of {{fhir\|.meta.tag}} with {{fhir\|.system}} = {{term\|<nowiki>http://terminology.hl7.org/CodeSystem/common-tags</nowiki>}} and {{fhir\|.value}} = {{term\|actionable}} to indicate that the resource is part of a request intended to be acted upon. The absence of this tag indicates that the resource is merely of informative nature.		If applicable, the profiles used by a transaction require the use of {{fhir\|.meta.tag}} with {{fhir\|.system}} = {{term\|<nowiki>http://terminology.hl7.org/CodeSystem/common-tags</nowiki>}} and {{fhir\|.value}} = {{term\|actionable}} to indicate that the resource is part of a request intended to be acted upon. The absence of this tag indicates that the resource is merely of informative nature.

Jorn Duwel: HOTFIX: Fix broken links

2022-06-15T19:07:51Z

HOTFIX: Fix broken links

Wijzigingen bekijken

Jorn Duwel: Jorn Duwel heeft pagina mp:Vprepub-9 2.0.0-beta3 FHIR MedicationProcess hernoemd naar mp:V2.0.0 MedicationProcess9 FHIR

2022-06-15T18:41:21Z

Jorn Duwel heeft pagina mp:Vprepub-9 2.0.0-beta3 FHIR MedicationProcess hernoemd naar mp:V2.0.0 MedicationProcess9 FHIR

← Oudere versie	Versie van 15 jun 2022 18:41
(geen verschil)

Jorn Duwel: Internal links

2022-06-15T18:39:46Z

Internal links

Wijzigingen bekijken

Jorn Duwel: Edit VersieInfo

2022-06-15T18:26:18Z

Edit VersieInfo

← Oudere versie		Versie van 15 jun 2022 18:26
Regel 15:		Regel 15:
	== Building blocks and profiles ==		== Building blocks and profiles ==

	The exchange of data within the MP9 standard version ~~2.0.0~~ is largely based on the 2020 publication of the Dutch Health and Care Information Models (Dutch: ‘zorginformatiebouwstenen’ or ‘zibs’). The objects that are present in the functional data set of the MP9 standard (and which are actually exchanged) are referred to as ‘building blocks’, and can thus be seen as ‘extended zibs’ suitable for implementation.		The exchange of data within the MP9 standard version {{VersieInfo\|mp9}} is largely based on the 2020 publication of the Dutch Health and Care Information Models (Dutch: ‘zorginformatiebouwstenen’ or ‘zibs’). The objects that are present in the functional data set of the MP9 standard (and which are actually exchanged) are referred to as ‘building blocks’, and can thus be seen as ‘extended zibs’ suitable for implementation.

	However, due to new insights, the medication related building blocks in the functional data set have deviated from the corresponding zibs they were originally based on, making them incompatible in varying degrees from a technical point of view. Therefore it was not possible to implement the FHIR profiles for these main building blocks by building on and extending [[FHIR:V0.9_FHIR_IG_R4#Functional_definitions\|the nl-core profiles]] based on zib-publication 2020. Hence the profiles for these building blocks have been created ‘independently’ from these profiles, meaning that the MP9 profiles have no dependency on the zib2020-package.		However, due to new insights, the medication related building blocks in the functional data set have deviated from the corresponding zibs they were originally based on, making them incompatible in varying degrees from a technical point of view. Therefore it was not possible to implement the FHIR profiles for these main building blocks by building on and extending [[FHIR:V0.9_FHIR_IG_R4#Functional_definitions\|the nl-core profiles]] based on zib-publication 2020. Hence the profiles for these building blocks have been created ‘independently’ from these profiles, meaning that the MP9 profiles have no dependency on the zib2020-package.

Jorn Duwel: /* Building blocks and profiles */ Add PackageNoteBox

2022-06-15T18:25:47Z

Building blocks and profiles: Add PackageNoteBox

← Oudere versie		Versie van 15 jun 2022 18:25
Regel 20:		Regel 20:

	All (incompatible) changes made in the medication related building blocks have resulted in change requests for the zibs, which will be part of the 2022 pre-publication. Thus, strictly speaking the MP9 standard is based on the 2022 pre-publication of the zibs.		All (incompatible) changes made in the medication related building blocks have resulted in change requests for the zibs, which will be part of the 2022 pre-publication. Thus, strictly speaking the MP9 standard is based on the 2022 pre-publication of the zibs.

			{{mp:V2.0.0/NoteBoxPackage\|p1=nictiz.fhir.nl.r4.medicationprocess9\|p2=nictiz.fhir.nl.r4.nl-core\|p3=nictiz.fhir.nl.r4.zib2020}}

	=== Medication building blocks ===		=== Medication building blocks ===

Jorn Duwel: Edit VersieInfo

2022-06-15T18:24:15Z

Edit VersieInfo

← Oudere versie		Versie van 15 jun 2022 18:24
Regel 1:		Regel 1:
	__NUMBEREDHEADINGS__		__NUMBEREDHEADINGS__
	{{DISPLAYTITLE:FHIR Implementation Guide Medication Process 9 version ~~2.0.0 bèta~~{{VersieInfo\|mp9~~\|release=MP9 2.0.0 bèta~~}} }}		{{DISPLAYTITLE:FHIR Implementation Guide Medication Process 9 version {{VersieInfo\|mp9}} }}
	{{IssueBox\|This publication has [[Media:20210826 - Roadmap releases informatiestandaard Medicatie Proces 9.pdf\|beta status]] and is being further developed for the Kickstart Medicatieoverdracht. Final publication expected in June 2022. For an overview of current documentation for Medication Process see here [[Landingspagina_Medicatieproces]]}}		{{IssueBox\|This publication has [[Media:20210826 - Roadmap releases informatiestandaard Medicatie Proces 9.pdf\|beta status]] and is being further developed for the Kickstart Medicatieoverdracht. Final publication expected in June 2022. For an overview of current documentation for Medication Process see here [[Landingspagina_Medicatieproces]]}}

Regel 6:		Regel 6:

	= Introduction =		= Introduction =
	This is the implementation guide (IG) for the information standard Medication Process 9 (MP9) version ~~2.0.0~~ using the HL7® FHIR® standard. The MP9 standard is described in [https://informatiestandaarden.nictiz.nl/wiki/mp:V2.0.0_Ontwerp_medicatieproces_9_ENG this functional specification] and further specified here using [https://www.hl7.org/fhir/R4/ FHIR version R4]. This implementation guide assumes that the reader is familiar with both the functional specification and this version of FHIR.		This is the implementation guide (IG) for the information standard Medication Process 9 (MP9) version {{VersieInfo\|mp9}} using the HL7® FHIR® standard. The MP9 standard is described in [https://informatiestandaarden.nictiz.nl/wiki/mp:V2.0.0_Ontwerp_medicatieproces_9_ENG this functional specification] and further specified here using [https://www.hl7.org/fhir/R4/ FHIR version R4]. This implementation guide assumes that the reader is familiar with both the functional specification and this version of FHIR.

	Apart from this document, the guidelines as specified in the [[FHIR:V0.9_FHIR_IG_R4\|general FHIR Implementation Guide]] apply. In particular, the reader should take note of the [[FHIR:V0.9_FHIR_IG_R4#Overarching_principles\|Overarching principles]] and the use of [[FHIR:V0.9_FHIR_IG_R4#FHIR_Packages\|FHIR packages]]. Where the general IG uses the term ‘use case’, this IG follows the functional specification in using the term ‘transaction’ for the various processes that are described. The functional specification uses the term ‘use case’ for more practical examples.		Apart from this document, the guidelines as specified in the [[FHIR:V0.9_FHIR_IG_R4\|general FHIR Implementation Guide]] apply. In particular, the reader should take note of the [[FHIR:V0.9_FHIR_IG_R4#Overarching_principles\|Overarching principles]] and the use of [[FHIR:V0.9_FHIR_IG_R4#FHIR_Packages\|FHIR packages]]. Where the general IG uses the term ‘use case’, this IG follows the functional specification in using the term ‘transaction’ for the various processes that are described. The functional specification uses the term ‘use case’ for more practical examples.

Jorn Duwel: /* Supporting building blocks */

2022-06-15T16:50:54Z

Supporting building blocks

← Oudere versie		Versie van 15 jun 2022 16:50
Regel 70:		Regel 70:
	=== Supporting building blocks ===		=== Supporting building blocks ===

	Additionally, the standard uses several supporting building blocks referenced from the main medication building blocks. All supporting building blocks are part of the ~~zib2020 package as~~ [[FHIR:V0.9_FHIR_IG_R4#Functional_definitions\|‘nl-core’ profiles]].		Additionally, the standard uses several supporting building blocks referenced from the main medication building blocks. All supporting building blocks are part of the [[FHIR:V0.9_FHIR_IG_R4#Functional_definitions\|‘nl-core’ package]]<ref>Although the nl-core package is still in beta-status, HL7 Netherlands has validated the profiles mentioned and assigned the status 'STU-NL' for use in the MP9 Kickstart, see [[Media:HL7_Nederland_disclaimer_STU-NL.pdf]]</ref>.

	{\| class="wikitable"		{\| class="wikitable"

Jorn Duwel: FHIR R4 IG Vdraft to V0.9

2022-06-15T16:39:03Z

FHIR R4 IG Vdraft to V0.9

← Oudere versie		Versie van 1 aug 2022 14:53
Regel 225:		Regel 225:
	To differentiate between sending or serving building blocks that are either of informative nature or of actionable nature, the {{term\|actionable}} tag is used. [https://hl7.org/fhir/r4/resource.html#tag Tags] are {{datatype\|Coding}} elements present in {{fhir\|Resource.meta.tag}} used for workflow management.		To differentiate between sending or serving building blocks that are either of informative nature or of actionable nature, the {{term\|actionable}} tag is used. [https://hl7.org/fhir/r4/resource.html#tag Tags] are {{datatype\|Coding}} elements present in {{fhir\|Resource.meta.tag}} used for workflow management.

			{{IssueBox\|1= The following paragraph speaks of {{fhir\|.value}}, where {{fhir\|.code}} is meant. This will be fixed in a next version of this IG, see [https://bits.nictiz.nl/browse/MP-714 MP-714]. }}
	If applicable, the profiles used by a transaction require the use of {{fhir\|.meta.tag}} with {{fhir\|.system}} = {{term\|<nowiki>http://terminology.hl7.org/CodeSystem/common-tags</nowiki>}} and {{fhir\|.value}} = {{term\|actionable}} to indicate that the resource is part of a request intended to be acted upon. The absence of this tag indicates that the resource is merely of informative nature.		If applicable, the profiles used by a transaction require the use of {{fhir\|.meta.tag}} with {{fhir\|.system}} = {{term\|<nowiki>http://terminology.hl7.org/CodeSystem/common-tags</nowiki>}} and {{fhir\|.value}} = {{term\|actionable}} to indicate that the resource is part of a request intended to be acted upon. The absence of this tag indicates that the resource is merely of informative nature.

← Oudere versie		Versie van 15 jun 2022 16:39
Regel 8:		Regel 8:
	This is the implementation guide (IG) for the information standard Medication Process 9 (MP9) version 2.0.0 using the HL7® FHIR® standard. The MP9 standard is described in [https://informatiestandaarden.nictiz.nl/wiki/mp:V2.0.0_Ontwerp_medicatieproces_9_ENG this functional specification] and further specified here using [https://www.hl7.org/fhir/R4/ FHIR version R4]. This implementation guide assumes that the reader is familiar with both the functional specification and this version of FHIR.		This is the implementation guide (IG) for the information standard Medication Process 9 (MP9) version 2.0.0 using the HL7® FHIR® standard. The MP9 standard is described in [https://informatiestandaarden.nictiz.nl/wiki/mp:V2.0.0_Ontwerp_medicatieproces_9_ENG this functional specification] and further specified here using [https://www.hl7.org/fhir/R4/ FHIR version R4]. This implementation guide assumes that the reader is familiar with both the functional specification and this version of FHIR.

	Apart from this document, the guidelines as specified in the [[FHIR:~~Vdraft_FHIR_IG_R4~~\|general FHIR Implementation Guide]] apply. In particular, the reader should take note of the [[FHIR:~~Vdraft_FHIR_IG_R4~~#Overarching_principles\|Overarching principles]] and the use of [[FHIR:~~Vdraft_FHIR_IG_R4~~#FHIR_Packages\|FHIR packages]]. Where the general IG uses the term ‘use case’, this IG follows the functional specification in using the term ‘transaction’ for the various processes that are described. The functional specification uses the term ‘use case’ for more practical examples.		Apart from this document, the guidelines as specified in the [[FHIR:V0.9_FHIR_IG_R4\|general FHIR Implementation Guide]] apply. In particular, the reader should take note of the [[FHIR:V0.9_FHIR_IG_R4#Overarching_principles\|Overarching principles]] and the use of [[FHIR:V0.9_FHIR_IG_R4#FHIR_Packages\|FHIR packages]]. Where the general IG uses the term ‘use case’, this IG follows the functional specification in using the term ‘transaction’ for the various processes that are described. The functional specification uses the term ‘use case’ for more practical examples.

	This IG first describes the boundaries and relationships in place, after which the implementation is described per transaction.		This IG first describes the boundaries and relationships in place, after which the implementation is described per transaction.
Regel 17:		Regel 17:
	The exchange of data within the MP9 standard version 2.0.0 is largely based on the 2020 publication of the Dutch Health and Care Information Models (Dutch: ‘zorginformatiebouwstenen’ or ‘zibs’). The objects that are present in the functional data set of the MP9 standard (and which are actually exchanged) are referred to as ‘building blocks’, and can thus be seen as ‘extended zibs’ suitable for implementation.		The exchange of data within the MP9 standard version 2.0.0 is largely based on the 2020 publication of the Dutch Health and Care Information Models (Dutch: ‘zorginformatiebouwstenen’ or ‘zibs’). The objects that are present in the functional data set of the MP9 standard (and which are actually exchanged) are referred to as ‘building blocks’, and can thus be seen as ‘extended zibs’ suitable for implementation.

	However, due to new insights, the medication related building blocks in the functional data set have deviated from the corresponding zibs they were originally based on, making them incompatible in varying degrees from a technical point of view. Therefore it was not possible to implement the FHIR profiles for these main building blocks by building on and extending [[FHIR:~~Vdraft_FHIR_IG_R4~~#Functional_definitions\|the nl-core profiles]] based on zib-publication 2020. Hence the profiles for these building blocks have been created ‘independently’ from these profiles, meaning that the MP9 profiles have no dependency on the zib2020-package.		However, due to new insights, the medication related building blocks in the functional data set have deviated from the corresponding zibs they were originally based on, making them incompatible in varying degrees from a technical point of view. Therefore it was not possible to implement the FHIR profiles for these main building blocks by building on and extending [[FHIR:V0.9_FHIR_IG_R4#Functional_definitions\|the nl-core profiles]] based on zib-publication 2020. Hence the profiles for these building blocks have been created ‘independently’ from these profiles, meaning that the MP9 profiles have no dependency on the zib2020-package.

	All (incompatible) changes made in the medication related building blocks have resulted in change requests for the zibs, which will be part of the 2022 pre-publication. Thus, strictly speaking the MP9 standard is based on the 2022 pre-publication of the zibs.		All (incompatible) changes made in the medication related building blocks have resulted in change requests for the zibs, which will be part of the 2022 pre-publication. Thus, strictly speaking the MP9 standard is based on the 2022 pre-publication of the zibs.
Regel 70:		Regel 70:
	=== Supporting building blocks ===		=== Supporting building blocks ===

	Additionally, the standard uses several supporting building blocks referenced from the main medication building blocks. All supporting building blocks are part of the zib2020 package as [[FHIR:~~Vdraft_FHIR_IG_R4~~#Functional_definitions\|‘nl-core’ profiles]].		Additionally, the standard uses several supporting building blocks referenced from the main medication building blocks. All supporting building blocks are part of the zib2020 package as [[FHIR:V0.9_FHIR_IG_R4#Functional_definitions\|‘nl-core’ profiles]].

	{\| class="wikitable"		{\| class="wikitable"
Regel 184:		Regel 184:
	Each transaction starts with links to the functional definition in an ART-DECOR publication and references one or several FHIR profiles. Where the functional definition contains all specific data elements for the transaction (prefixed with ‘dataelement-mp920’), the FHIR profiles only contain a mapping to these data elements that do not have a dependency on a zib counterpart. For example: ‘mp-dataelement920-83’ (MedicationAgreementDateTime) has a relation with the zib element with id ‘NL-CM-9.6.19757’, therefore no mapping with ‘mp-dataelement920-83’ can be found in the profiles. On the other hand, ‘mp-dataelement920-42’ (Identification) has no relation with a zib element, therefore a mapping can be found in the relevant FHIR profile.		Each transaction starts with links to the functional definition in an ART-DECOR publication and references one or several FHIR profiles. Where the functional definition contains all specific data elements for the transaction (prefixed with ‘dataelement-mp920’), the FHIR profiles only contain a mapping to these data elements that do not have a dependency on a zib counterpart. For example: ‘mp-dataelement920-83’ (MedicationAgreementDateTime) has a relation with the zib element with id ‘NL-CM-9.6.19757’, therefore no mapping with ‘mp-dataelement920-83’ can be found in the profiles. On the other hand, ‘mp-dataelement920-42’ (Identification) has no relation with a zib element, therefore a mapping can be found in the relevant FHIR profile.

	Because of [[FHIR:V1.0_FHIR_Profiling_Guidelines_R4#Open_vs._closed_world_modeling\|open world modelling]], the cardinality of elements in the FHIR profiles can be less strict than the cardinalities in the ART-DECOR transactions. However, the latter cardinality is leading when it comes to exchanging building blocks in the context of a specific transaction. For example: in the mp-MedicationAgreement profile, {{fhir\|.requester}} has a cardinality of 0..1, while in the ‘Serve Medication data’ ART-DECOR transaction, the Prescriber element has a cardinality of 1..1 R. Therefore, {{fhir\|.requester}} is expected to be filled with either a Reference to an nl-core-HealthProfessional-PractitionerRole resource or a [http://hl7.org/fhir/R4/extension-data-absent-reason.html DataAbsentReason extension], see the [[FHIR:~~Vdraft_FHIR_IG_R4~~#Missing_information\|general FHIR IG on ‘Missing information’]].		Because of [[FHIR:V1.0_FHIR_Profiling_Guidelines_R4#Open_vs._closed_world_modeling\|open world modelling]], the cardinality of elements in the FHIR profiles can be less strict than the cardinalities in the ART-DECOR transactions. However, the latter cardinality is leading when it comes to exchanging building blocks in the context of a specific transaction. For example: in the mp-MedicationAgreement profile, {{fhir\|.requester}} has a cardinality of 0..1, while in the ‘Serve Medication data’ ART-DECOR transaction, the Prescriber element has a cardinality of 1..1 R. Therefore, {{fhir\|.requester}} is expected to be filled with either a Reference to an nl-core-HealthProfessional-PractitionerRole resource or a [http://hl7.org/fhir/R4/extension-data-absent-reason.html DataAbsentReason extension], see the [[FHIR:V0.9_FHIR_IG_R4#Missing_information\|general FHIR IG on ‘Missing information’]].

	Each transaction contains a Patient building block with cardinality 1..1 M. This patient is the subject of all other building blocks in the transaction, although no explicit relation exists in the data set. Therefore, a reference to a Patient resource conforming to the nl-core-Patient profile is expected in {{fhir\|.subject}} of each FHIR instance of each building block.		Each transaction contains a Patient building block with cardinality 1..1 M. This patient is the subject of all other building blocks in the transaction, although no explicit relation exists in the data set. Therefore, a reference to a Patient resource conforming to the nl-core-Patient profile is expected in {{fhir\|.subject}} of each FHIR instance of each building block.

	Relations between different building blocks exist in transactions by means of concepts with a name starting with ‘Relation…’ (Dutch: ‘Relatie…’) and an underlying concept 'Identification' of data type Identification, for example RelationAdministrationAgreement (mp-dataelement920-1328) in building block MedicationAgreement. These relations are mapped to the FHIR data type ‘Reference’. Implementers SHOULD use literal references (using {{fhir\|.reference}}) instead of logical references (using {{fhir\|.identifier}}) where possible, see the [[FHIR:~~Vdraft_FHIR_IG_R4~~#Use_of_the_reference_datatype\|general FHIR IG on the Reference data type]].		Relations between different building blocks exist in transactions by means of concepts with a name starting with ‘Relation…’ (Dutch: ‘Relatie…’) and an underlying concept 'Identification' of data type Identification, for example RelationAdministrationAgreement (mp-dataelement920-1328) in building block MedicationAgreement. These relations are mapped to the FHIR data type ‘Reference’. Implementers SHOULD use literal references (using {{fhir\|.reference}}) instead of logical references (using {{fhir\|.identifier}}) where possible, see the [[FHIR:V0.9_FHIR_IG_R4#Use_of_the_reference_datatype\|general FHIR IG on the Reference data type]].

	== Pharmaceutical treatment ==		== Pharmaceutical treatment ==
Regel 210:		Regel 210:

	== Resource identification ==		== Resource identification ==
	All profiles used within the MP9 information standard contain {{fhir\|.identifier}} elements with a cardinality of 0..* because of open world modelling. However, all ART-DECOR transactions referenced within this IG assign a 1..1 R cardinality, meaning a stable identifier SHOULD be provided, or [[FHIR:~~Vdraft_FHIR_IG_R4~~#Missing_information\|the DataAbsentReason extension if a value is missing]]. Identifiers SHALL contain both a {{fhir\|.system}} and a {{fhir\|.value}}.		All profiles used within the MP9 information standard contain {{fhir\|.identifier}} elements with a cardinality of 0..* because of open world modelling. However, all ART-DECOR transactions referenced within this IG assign a 1..1 R cardinality, meaning a stable identifier SHOULD be provided, or [[FHIR:V0.9_FHIR_IG_R4#Missing_information\|the DataAbsentReason extension if a value is missing]]. Identifiers SHALL contain both a {{fhir\|.system}} and a {{fhir\|.value}}.

	Because in HL7v3 (CDA) an identifier can only be composed using OIDs, the {{fhir\|.system}} SHALL be an OID to accommodate compatibility in transformations to and from FHIR. The [https://www.hl7.nl/wiki/index.php?title=DatatypesR1:II Netherlands HL7v3 datatype II] also defines additional restrictions on the maximum length of both <code>@root</code> and <code>@extension</code> (equivalent to respectively {{fhir\|.system}} and {{fhir\|.value}} in FHIR). For the same compatibility reasons, {{fhir\|.system}} SHALL have a maximum of 128 characters and {{fhir\|.value}} SHALL have a maximum of 64 characters.		Because in HL7v3 (CDA) an identifier can only be composed using OIDs, the {{fhir\|.system}} SHALL be an OID to accommodate compatibility in transformations to and from FHIR. The [https://www.hl7.nl/wiki/index.php?title=DatatypesR1:II Netherlands HL7v3 datatype II] also defines additional restrictions on the maximum length of both <code>@root</code> and <code>@extension</code> (equivalent to respectively {{fhir\|.system}} and {{fhir\|.value}} in FHIR). For the same compatibility reasons, {{fhir\|.system}} SHALL have a maximum of 128 characters and {{fhir\|.value}} SHALL have a maximum of 64 characters.

	Systems that encounter or resolve references, either logical or literal, in resources they receive, SHALL NOT rewrite these references to a copy of these resources (with {{Simplifier\|http://nictiz.nl/fhir/StructureDefinition/ext-CopyIndicator\|nictiz.fhir.nl.r4.nl-core}} present) they may store. This means that [https://hl7.org/fhir/r4/references.html relative literal references] may need to be rewritten to absolute ones. This also goes for [[FHIR:~~Vdraft_FHIR_IG_R4~~#Referring_to_.22secondary.22_resources_when_sending_information\|included secondary resources in transactions]].		Systems that encounter or resolve references, either logical or literal, in resources they receive, SHALL NOT rewrite these references to a copy of these resources (with {{Simplifier\|http://nictiz.nl/fhir/StructureDefinition/ext-CopyIndicator\|nictiz.fhir.nl.r4.nl-core}} present) they may store. This means that [https://hl7.org/fhir/r4/references.html relative literal references] may need to be rewritten to absolute ones. This also goes for [[FHIR:V0.9_FHIR_IG_R4#Referring_to_.22secondary.22_resources_when_sending_information\|included secondary resources in transactions]].

	== Differentiating between transactions ==		== Differentiating between transactions ==
	All transactions described in this IG use the same medication building blocks in different combinations and settings, making it necessary to differentiate between them. Several mechanisms are used to achieve this. Aside from PUSH/PULL, the type of medication building blocks, supporting resources like List and Communication for specific transactions and fixing the value of specific FHIR elements in applicable profiles, the {{term\|actionable}} tag is used. The latter is described more in depth in the following section. Next to that, a summarizing table is provided.		All transactions described in this IG use the same medication building blocks in different combinations and settings, making it necessary to differentiate between them. Several mechanisms are used to achieve this. Aside from PUSH/PULL, the type of medication building blocks, supporting resources like List and Communication for specific transactions and fixing the value of specific FHIR elements in applicable profiles, the {{term\|actionable}} tag is used. The latter is described more in depth in the following section. Next to that, a summarizing table is provided.

	Note that {{fhir\|Resource.meta.profile}}, although present in each building block (see [[FHIR:~~Vdraft_FHIR_IG_R4~~#Profile_use_and_declaration\|the general FHIR IG on ‘Profile use and declaration’]]), SHOULD [https://hl7.org/fhir/r4/resource.html#profile-tags not be used for identification of the building block type] and therefore for differentiating between transactions.		Note that {{fhir\|Resource.meta.profile}}, although present in each building block (see [[FHIR:V0.9_FHIR_IG_R4#Profile_use_and_declaration\|the general FHIR IG on ‘Profile use and declaration’]]), SHOULD [https://hl7.org/fhir/r4/resource.html#profile-tags not be used for identification of the building block type] and therefore for differentiating between transactions.

	=== Actionable tag ===		=== Actionable tag ===
Regel 431:		Regel 431:
	\| -		\| -
	\| The client may request that the server returns resources related to the search results, in order to reduce the overall network delay of repeated retrievals of related resources.		\| The client may request that the server returns resources related to the search results, in order to reduce the overall network delay of repeated retrievals of related resources.
	Supporting the include of the Patient and Medication resources referenced by building blocks is required. Others (Organization, Location, PractitionerRole, Practitioner, RelatedPerson, Observation) are optional. However: all resources referenced per literal reference SHALL be resolvable [[FHIR:~~Vdraft_FHIR_IG_R4~~#Including_referenced_resources\|per the Nictiz IG]].		Supporting the include of the Patient and Medication resources referenced by building blocks is required. Others (Organization, Location, PractitionerRole, Practitioner, RelatedPerson, Observation) are optional. However: all resources referenced per literal reference SHALL be resolvable [[FHIR:V0.9_FHIR_IG_R4#Including_referenced_resources\|per the Nictiz IG]].
	\| {{fhir\|<nowiki>_include=[type]:patient</nowiki>}}		\| {{fhir\|<nowiki>_include=[type]:patient</nowiki>}}
	{{fhir\|<nowiki>_include=[type]:medication</nowiki>}}		{{fhir\|<nowiki>_include=[type]:medication</nowiki>}}