mp:Vprepub-3.0.0 MedicationProcess9 FHIR - Bewerkingsoverzicht

Huib Vroege: Kopie van rc.1 versie op 21-11-2025

2025-11-21T14:38:09Z

Kopie van rc.1 versie op 21-11-2025

Wijzigingen bekijken

Luud Slagter op 31 okt 2023 om 18:07

2023-10-31T18:07:45Z

Luud Slagter: Publish 3.0.0-beta.2 IG

2023-10-31T18:05:05Z

Publish 3.0.0-beta.2 IG

Wijzigingen bekijken

Jorn Duwel: Update various links to 3.0.0

2023-02-23T12:48:48Z

Update various links to 3.0.0

Jorn Duwel: Update FHIR package versions, update ART-DECOR transaction links

2023-02-23T11:18:22Z

Update FHIR package versions, update ART-DECOR transaction links

Wijzigingen bekijken

Jorn Duwel: MP-874: Remove remark on zib2022

2023-02-23T10:55:13Z

MP-874: Remove remark on zib2022

Jorn Duwel: MP-877: Add remark on mappings

2023-02-22T15:20:26Z

MP-877: Add remark on mappings

Jorn Duwel: MP-733: Add period-of-use search parameter on MedicationUse2 (MedicationStatement)

2023-02-20T15:43:28Z

MP-733: Add period-of-use search parameter on MedicationUse2 (MedicationStatement)

Jorn Duwel: MP-639: Change nl-core to mp-PharmaceuticalProduct. Add note on this

2023-02-16T12:46:21Z

MP-639: Change nl-core to mp-PharmaceuticalProduct. Add note on this

Jorn Duwel: MP-773: Add subject:Patient.identifier as Patient identification mechanism

2023-02-15T10:18:04Z

MP-773: Add subject:Patient.identifier as Patient identification mechanism

@@ Regel 218: / Regel 218: @@
 == Pharmaceutical treatment ==
-The MP9 transaction data sets reference a container ‘Pharmaceutical treatment’ (Dutch: ‘Medicamenteuze behandeling’), which contains all medication building blocks relevant to the transaction. For the specification of the Pharmaceutical treatment, see [[mp:Vprepub-3.0.0_Ontwerp_medicatieproces_9_ENG#.27Medicamenteuze_behandeling.27|the functional specification]]. In FHIR, the Pharmaceutical treatment does not have an explicit resource representation. Instead, each medication building block contains the PharmaceuticalTreatmentIdentifier extension which contains the ‘Pharmaceutical Treatment Identifier’. This Identifier shall be the same across different related medication resources that constitute one Pharmaceutical treatment. The custom search parameter {{fhir|pharmaceutical-treatment-identifier}}, see [[#Search_parameters|‘Search parameters’]], is used within the ‘Medication data’ transaction to query a server for all building blocks within a specific Pharmaceutical treatment.
+The MP9 transaction data sets reference a container ‘Pharmaceutical treatment’ (Dutch: ‘Medicamenteuze behandeling’), which contains all medication building blocks relevant to the transaction. For the specification of the Pharmaceutical treatment, see [[mp:V3.0.0-beta_Ontwerp_medicatieproces_9_ENG#.27Medicamenteuze_behandeling_.2F_Pharmaceutical_treatment.27_.28MBH.29|the functional specification]]. In FHIR, the Pharmaceutical treatment does not have an explicit resource representation. Instead, each medication building block contains the PharmaceuticalTreatmentIdentifier extension which contains the ‘Pharmaceutical Treatment Identifier’. This Identifier shall be the same across different related medication resources that constitute one Pharmaceutical treatment. The custom search parameter {{fhir|pharmaceutical-treatment-identifier}}, see [[#Search_parameters|‘Search parameters’]], is used within the ‘Medication data’ transaction to query a server for all building blocks within a specific Pharmaceutical treatment.
 == Patient identification ==
@@ Regel 339: / Regel 339: @@
 = Transactions =
-This section describes the FHIR implementation of all transactions listed in [[mp:Vprepub-3.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:V3.0.0-beta_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 ‘Query’ and ‘Making available’, this IG uses the terms ‘Retrieving’ and ‘Serving’.
-<section begin=medmij />
+<section begin=medmij1 />
 == 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.

@@ Regel 184: / Regel 184: @@
 ====Bundle profiles====
-The profiles on Bundle serve as guidance both on what is needed to differentiate between transactions (for example setting {{fhir|.meta.tag}} or a specific value of {{fhir|.intent}}, see also [[mp:Vprepub-3.0.0_MedicationProcess9_FHIR#Differentiating_between_transactions|Differentiating between transactions]]) and on which building blocks can be expected to be included in a Bundle within a transaction.
+The profiles on Bundle serve as guidance both on what is needed to differentiate between transactions (for example setting {{fhir|.meta.tag}} or a specific value of {{fhir|.intent}}, see also [[mp:V3.0.0_MedicationProcess9_FHIR#Differentiating_between_transactions|Differentiating between transactions]]) and on which building blocks can be expected to be included in a Bundle within a transaction.
 All building blocks defined in the functional specification of a transaction have been added as slices on {{fhir|.entry}}. This is not a limited list, a sending system has the option to include more referenced resources if needed. Note that where the functional specification of a transaction specifies a minimum cardinality of 1 for a building block, the minimum cardinality in a Bundle profile has been set to 0. Because there are different ways in FHIR to reference to building blocks, senders are not required to include it in the Bundle.
-Where the functional specification of a transaction expects a HealthProfessional building block, both [[mp:Vprepub-3.0.0_MedicationProcess9_FHIR#Supporting_building_blocks|the profiles on resource types PractitionerRole and Practitioner]] have been included in the Bundle profile. The same goes for the HealthcareProvider building block with its profiles on Location and Organization.
+Where the functional specification of a transaction expects a HealthProfessional building block, both [[mp:V3.0.0_MedicationProcess9_FHIR#Supporting_building_blocks|the profiles on resource types PractitionerRole and Practitioner]] have been included in the Bundle profile. The same goes for the HealthcareProvider building block with its profiles on Location and Organization.
 == Mappings between profiles and data set ==
@@ Regel 702: / Regel 702: @@
 The server returns a HTTP Status code appropriate to the processing of the operation. The successful outcome of the {{Simplifier|http://nictiz.nl/fhir/OperationDefinition/Medication-Overview|nictiz.fhir.nl.r4.medicationprocess9|title={{fhir|$medication-overview}} operation}} is the body of the medication overview response message. Successful processing of this operation should result in a Bundle resource with {{fhir|Bundle.type}} = {{term|searchset}} that conforms to the mp-MedicationOverview-Bundle profile, which contains at least one List resource (that represents the medication overview and conforms to the mp-MedicationOverview profile) and optionally one Patient resource, along with all the resources that represent the current medication overview. These latter resources SHALL be referenced from the List resource. All resources included in the Bundle SHALL conform to their respective profiles listed in [[#Building_blocks_and_profiles|section 2.1]]. The {{fhir|Bundle.total}} value contains the number of matching building blocks (i.e. MedicationAgreement, AdministrationAgreement and MedicationUse2). Other included resources, such as Medication resources, are not included in the total.
-The clinical content of the medication overview is defined in the [https://informatiestandaarden.nictiz.nl/wiki/mp:V9_2.0.0_Ontwerp_medicatieproces_ENG#Medication_overview_and_inference_rules Medication Process specification].
+The clinical content of the medication overview is defined in the [https://informatiestandaarden.nictiz.nl/wiki/mp:V3.0.0_Ontwerp_medicatieproces_9_ENG#Medication_overview_and_inference_rules Medication Process specification].
 === List of profiles ===
@@ Regel 808: / Regel 808: @@
 The Bundle SHALL conform to the mp-MedicationOverview-Bundle profile, which contains at least one List profile (that represents the medication overview and conforms to the mp-MedicationOverview profile) and optionally one Patient resource, along with all the resources that represent the current medication overview. These latter resources SHALL be referenced from the List resource. All resources included in the Bundle SHALL conform to their respective profiles listed in the 'List of profiles' below.
-The clinical content of the medication overview is defined in the [https://informatiestandaarden.nictiz.nl/wiki/mp:V9_2.0.0_Ontwerp_medicatieproces_ENG#Medication_overview_and_inference_rules Medication Process specification].
+The clinical content of the medication overview is defined in the [https://informatiestandaarden.nictiz.nl/wiki/mp:V3.0.0_Ontwerp_medicatieproces_9_ENG#Medication_overview_and_inference_rules Medication Process specification].
 === Receive (response message) ===

← Oudere versie		Versie van 23 feb 2023 om 10:55
Regel 18:		Regel 18:

	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:V1.0_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:V1.0_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.

	Because the way 90 million numbers are exchanged is not compatible with the 2020 publication of zib PharmaceuticalProduct, a fork of the corresponding nl-core profile called 'mp-PharmaceuticalProduct' has been introduced.		Because the way 90 million numbers are exchanged is not compatible with the 2020 publication of zib PharmaceuticalProduct, a fork of the corresponding nl-core profile called 'mp-PharmaceuticalProduct' has been introduced.

@@ Regel 193: / Regel 193: @@
 == Mappings between profiles and data set ==
-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-mp9x’), the FHIR profiles only contain a mapping to these data elements that do not have a dependency on a zib counterpart. For example: ‘mp-dataelement9x-83’ (MedicationAgreementDateTime) has a relation with the zib element with id ‘NL-CM-9.6.19757’, therefore no mapping with ‘mp-dataelement9x-83’ can be found in the profiles. On the other hand, ‘mp-dataelement9x-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:V1.0_FHIR_IG_R4#Missing_information|general FHIR IG on ‘Missing information’]].

@@ Regel 422: / Regel 422: @@
 |-
 | PeriodOfUse
-| Search on medication use in the past, present or future within the specified time period.
+| Search on the MedicationAgreement, VariableDosingRegimen, AdministrationAgreement and MedicationUse2 building blocks that are related to medication that was used, is used or will be used during the indicated period.
 | {{fhir|period-of-use}}<ref name="custom-searchparameter"/>
-| MedicationRequest, MedicationDispense
+| MedicationRequest, MedicationDispense, MedicationStatement<ref>For the MedicationRequest and MedicationDispense resource types, the {{fhir|period-of-use}} parameter searches on the ext-TimeInterval.Period extension which may include the ext-TimeInterval.Duration extension. For the MedicationStatement resource type, the parameter modifies the core search parameter on {{fhir|.effective}} to include the ext-TimeInterval.Duration extension that may be present.</ref>
 | Retrieves all MedicationRequest resources that represent the building block MedicationAgreement and were in effect from 01-01-2010.
 <pre>GET [base]/MedicationRequest?category=http://snomed.info/sct|33633005&period-of-use=ge2010-01-01</pre>

@@ 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.
 {{NoteBoxNictizR4Package|p1=nictiz.fhir.nl.r4.medicationprocess9|v1=1.0.0|p2=nictiz.fhir.nl.r4.nl-core|v2=0.5.0-beta1|p3=nictiz.fhir.nl.r4.zib2020|v3=0.5.0-beta1}}
@@ Regel 89: / Regel 91: @@
 | FarmaceutischProduct
 | Medication
-| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/nl-core-PharmaceuticalProduct|nictiz.fhir.nl.r4.nl-core|pkgVersion=0.5.0-beta1}}
+| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/mp-PharmaceuticalProduct|nictiz.fhir.nl.r4.medicationprocess9|pkgVersion=2.0.0.beta.1}}
 |-
 | Contact
@@ Regel 531: / Regel 533: @@
 | FarmaceutischProduct
 | Medication
-| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/nl-core-PharmaceuticalProduct|nictiz.fhir.nl.r4.nl-core|pkgVersion=0.5.0-beta1}}
+| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/mp-PharmaceuticalProduct|nictiz.fhir.nl.r4.medicationprocess9|pkgVersion=2.0.0.beta.1}}
 |-
 | rowspan="2" | HealthProfessional
@@ Regel 642: / Regel 644: @@
 | FarmaceutischProduct
 | Medication
-| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/nl-core-PharmaceuticalProduct|nictiz.fhir.nl.r4.nl-core|pkgVersion=0.5.0-beta1}}
+| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/mp-PharmaceuticalProduct|nictiz.fhir.nl.r4.medicationprocess9|pkgVersion=2.0.0.beta.1}}
 |-
 | rowspan="2" | HealthProfessional
@@ Regel 743: / Regel 745: @@
 | FarmaceutischProduct
 | Medication
-| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/nl-core-PharmaceuticalProduct|nictiz.fhir.nl.r4.nl-core|pkgVersion=0.5.0-beta1}}
+| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/mp-PharmaceuticalProduct|nictiz.fhir.nl.r4.medicationprocess9|pkgVersion=2.0.0.beta.1}}
 |-
 | rowspan="2" | HealthProfessional
@@ Regel 853: / Regel 855: @@
 | FarmaceutischProduct
 | Medication
-| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/nl-core-PharmaceuticalProduct|nictiz.fhir.nl.r4.nl-core|pkgVersion=0.5.0-beta1}}
+| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/mp-PharmaceuticalProduct|nictiz.fhir.nl.r4.medicationprocess9|pkgVersion=2.0.0.beta.1}}
 |-
 | rowspan="2" | HealthProfessional
@@ Regel 908: / Regel 910: @@
 {{MpFhirSendTransaction}}
-The Bundle SHALL conform to the mp-MedicationPrescription-Bundle profile, which contains at least a MedicationAgreement building block (with {{fhir|MedicationRequest.intent}} = {{term|order}}) and optionally a DispenseRequest building block (with {{fhir|MedicationRequest.intent}} = {{term|order}}). Additionally, one instance of nl-core-Patient, nl-core-BodyHeight and nl-core-BodyWeight, and multiple instances of nl-core-PharmaceuticalProduct might be included, as well as other supporting resources. All resources included in the Bundle SHALL conform to their respective profiles listed in the 'List of profiles' below
+The Bundle SHALL conform to the mp-MedicationPrescription-Bundle profile, which contains at least a MedicationAgreement building block (with {{fhir|MedicationRequest.intent}} = {{term|order}}) and optionally a DispenseRequest building block (with {{fhir|MedicationRequest.intent}} = {{term|order}}). Additionally, one instance of nl-core-Patient, nl-core-BodyHeight and nl-core-BodyWeight, and multiple instances of mp-PharmaceuticalProduct might be included, as well as other supporting resources. All resources included in the Bundle SHALL conform to their respective profiles listed in the 'List of profiles' below
 The mp-MedicationPrescription-Bundle profile prescribes the use of [[#Actionable_tag|{{term|actionable}} tags]] to indicate that the resources sent are part of a prescription and of actionable nature.
@@ Regel 953: / Regel 955: @@
 | FarmaceutischProduct
 | Medication
-| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/nl-core-PharmaceuticalProduct|nictiz.fhir.nl.r4.nl-core|pkgVersion=0.5.0-beta1}}
+| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/mp-PharmaceuticalProduct|nictiz.fhir.nl.r4.medicationprocess9|pkgVersion=2.0.0.beta.1}}
 |-
 | rowspan="2" | HealthProfessional
@@ Regel 1.008: / Regel 1.010: @@
 {{MpFhirSendTransaction}}
-The Bundle SHALL conform to the mp-MedicationPrescriptionProcessing-Bundle profile, which contains at least an AdministrationAgreement building block and optionally a MedicationDispense building block. Additionally, one instance of nl-core-Patient and multiple instances of nl-core-PharmaceuticalProduct might be included, as well as other supporting resources. All resources included in the Bundle SHALL conform to their respective profiles listed in the 'List of profiles' below.
+The Bundle SHALL conform to the mp-MedicationPrescriptionProcessing-Bundle profile, which contains at least an AdministrationAgreement building block and optionally a MedicationDispense building block. Additionally, one instance of nl-core-Patient and multiple instances of mp-PharmaceuticalProduct might be included, as well as other supporting resources. All resources included in the Bundle SHALL conform to their respective profiles listed in the 'List of profiles' below.
 The mp-MedicationPrescriptionProcessing-Bundle profile prescribes the use of [[#Actionable_tag|{{term|actionable}} tags]] to indicate that the resources sent are part of a prescription and of actionable nature.
@@ Regel 1.051: / Regel 1.053: @@
 | FarmaceutischProduct
 | Medication
-| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/nl-core-PharmaceuticalProduct|nictiz.fhir.nl.r4.nl-core|pkgVersion=0.5.0-beta1}}
+| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/mp-PharmaceuticalProduct|nictiz.fhir.nl.r4.medicationprocess9|pkgVersion=2.0.0.beta.1}}
 |-
 | rowspan="2" | HealthcareProvider
@@ Regel 1.088: / Regel 1.090: @@
 {{MpFhirSendTransaction}}
-The Bundle SHALL conform to the mp-ProposalDispenseRequest-Bundle profile, which contains one DispenseRequest building block (with {{fhir|MedicationRequest.intent}} = {{term|plan}}). Additionally, one instance of nl-core-Patient and multiple instances of nl-core-PharmaceuticalProduct might be included, as well as other supporting resources. All resources included in the Bundle SHALL conform to their respective profiles listed in the 'List of profiles' below.
+The Bundle SHALL conform to the mp-ProposalDispenseRequest-Bundle profile, which contains one DispenseRequest building block (with {{fhir|MedicationRequest.intent}} = {{term|plan}}). Additionally, one instance of nl-core-Patient and multiple instances of mp-PharmaceuticalProduct might be included, as well as other supporting resources. All resources included in the Bundle SHALL conform to their respective profiles listed in the 'List of profiles' below.
 The mp-ProposalDispenseRequest-Bundle profile prescribes the use of [[#Actionable_tag|{{term|actionable}} tags]] to indicate that the resources sent are part of a proposal and of actionable nature.
@@ Regel 1.128: / Regel 1.130: @@
 | FarmaceutischProduct
 | Medication
-| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/nl-core-PharmaceuticalProduct|nictiz.fhir.nl.r4.nl-core|pkgVersion=0.5.0-beta1}}
+| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/mp-PharmaceuticalProduct|nictiz.fhir.nl.r4.medicationprocess9|pkgVersion=2.0.0.beta.1}}
 |-
 | rowspan="2" | HealthProfessional
@@ Regel 1.258: / Regel 1.260: @@
 {{MpFhirSendTransaction}}
-The Bundle SHALL conform to the mp-ProposalMedicationAgreement-Bundle profile, which contains at least a MedicationAgreement building block (with {{fhir|MedicationRequest.intent}} = {{term|plan}}). Additionally, one instance of nl-core-Patient, nl-core-BodyHeight and nl-core-BodyWeight, and multiple instances of nl-core-PharmaceuticalProduct might be included, as well as other supporting resources. All resources included in the Bundle SHALL conform to their respective profiles listed in the 'List of profiles' below.
+The Bundle SHALL conform to the mp-ProposalMedicationAgreement-Bundle profile, which contains at least a MedicationAgreement building block (with {{fhir|MedicationRequest.intent}} = {{term|plan}}). Additionally, one instance of nl-core-Patient, nl-core-BodyHeight and nl-core-BodyWeight, and multiple instances of mp-PharmaceuticalProduct might be included, as well as other supporting resources. All resources included in the Bundle SHALL conform to their respective profiles listed in the 'List of profiles' below.
 The mp-ProposalMedicationAgreement-Bundle profile prescribes the use of [[#Actionable_tag|{{term|actionable}} tags]] to indicate that the resources sent are part of a proposal and of actionable nature.
@@ Regel 1.298: / Regel 1.300: @@
 | FarmaceutischProduct
 | Medication
-| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/nl-core-PharmaceuticalProduct|nictiz.fhir.nl.r4.nl-core|pkgVersion=0.5.0-beta1}}
+| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/mp-PharmaceuticalProduct|nictiz.fhir.nl.r4.medicationprocess9|pkgVersion=2.0.0.beta.1}}
 |-
 | rowspan="2" | HealthProfessional

@@ Regel 203: / Regel 203: @@
 == Patient identification ==
-This implementation guide assumes that the client system is able to make a connection to the right server that contains the patient's information. It does not provide information on finding the right server nor does it provide information about security. Moreover, each transaction is performed in the context of a specific patient, whose context might have been established using the authentication mechanisms described in external specifications such as the MedMij ‘Afsprakenstelsel’ or through the usage of search parameters for patient identification. Each server is required to perform filtering based on the patient associated with the context for the request or based on the patient identification search parameters, which is a [https://www.hl7.org/fhir/r4/search.html#chaining chained search parameter] for all resource types except Patient, so only the records associated with the authenticated patient are returned.
+This implementation guide assumes that the client system is able to make a connection to the right server that contains the patient's information. It does not provide information on finding the right server nor does it provide information about security. Moreover, each transaction is performed in the context of a specific patient, whose context might have been established using the authentication mechanisms described in external specifications such as the MedMij ‘Afsprakenstelsel’ or through the usage of search parameters for patient identification.
 When patient identification requires the use of search parameters, the following search parameters SHALL be supported:
 * Patient: {{fhir|identifier}}
-* MedicationRequest: {{fhir|patient}}
+* MedicationRequest: {{fhir|patient.identifier}} and {{fhir|subject:Patient.identifier}}
-* MedicationDispense: {{fhir|patient}}
+* MedicationDispense: {{fhir|patient.identifier}} and {{fhir|subject:Patient.identifier}}
-* MedicationStatement: {{fhir|patient}}
+* MedicationStatement: {{fhir|patient.identifier}} and {{fhir|subject:Patient.identifier}}
-* MedicationAdministration: {{fhir|patient}}
+* MedicationAdministration: {{fhir|patient.identifier}} and {{fhir|subject:Patient.identifier}}
 An example of a request that retrieves all MedicationRequest resources of a patient with a fake BSN of 11122233: