mp:V2.0.0 MedicationProcess9 FHIR: verschil tussen versies

Uit informatiestandaarden
Naar navigatie springen Naar zoeken springen
(Add section tag)
 
(199 tussenliggende versies door 3 gebruikers niet weergegeven)
Regel 1: Regel 1:
 
__NUMBEREDHEADINGS__
 
__NUMBEREDHEADINGS__
−
{{DISPLAYTITLE:FHIR Implementation Guide Medication Process 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|release=V2.0.0}} }}
−
{{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 March 2022. For an overview of current documentation for Medication Process see here [[Landingspagina_Medicatieproces]]}}
 
  
 
__TOC__
 
__TOC__
  
 
= 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:V9_2.0.0_Ontwerp_medicatieproces_ENG this functional specification] and implemented here using [https://www.hl7.org/fhir/R4/ FHIR] [https://www.hl7.org/fhir/R4/ 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|release=V2.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#Use_case_overarching_principles#Use_case_overarching_principles|Use case overarching principles]] and the use of [[FHIR:Vdraft_FHIR_IG_R4#Use_case_overarching_principles#FHIR_Packages|FHIR packages]]. Where the general IG uses the term 'use case', this IG follows the functional specification in using th 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 describer per transaction.
+
This IG first describes the boundaries and relationships in place, after which the implementation is described per transaction.
  
 
= Boundaries and relationships =
 
= Boundaries and relationships =
 
== Building blocks and profiles ==
 
== Building blocks and profiles ==
 +
 +
The exchange of data within the MP9 standard version {{VersieInfo|mp9|release=V2.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: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.
 +
 +
{{mp:V2.0.0/NoteBoxPackage|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}}
 +
 +
=== Medication building blocks ===
 +
 +
As described above, the main medication building blocks have no dependency on any zib2020 counterparts, resulting in so-called ‘mp’ profiles. Moreover, note that the building block VariableDosingRegimen does not have a zib counterpart, hence it makes sense to include it as an mp profile as well.
 +
 +
{| class="wikitable"
 +
|-
 +
! style="font-weight: bold;text-align:left;" | Building block (EN)
 +
! style="font-weight: bold;text-align:left;" | Building block (NL)
 +
! style="font-weight: bold;text-align:left;" | FHIR resource
 +
! style="font-weight: bold;text-align:left;" | FHIR profile
 +
|-
 +
| MedicationAgreement
 +
| Medicatieafspraak
 +
| MedicationRequest
 +
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/mp-MedicationAgreement|nictiz.fhir.nl.r4.medicationprocess9|pkgVersion=1.0.0}}
 +
|-
 +
| VariableDosingRegimen
 +
| WisselendDoseerschema
 +
| MedicationRequest
 +
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/mp-VariableDosingRegimen|nictiz.fhir.nl.r4.medicationprocess9|pkgVersion=1.0.0}}
 +
|-
 +
| DispenseRequest
 +
| Verstrekkingsverzoek
 +
| MedicationRequest
 +
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/mp-DispenseRequest|nictiz.fhir.nl.r4.medicationprocess9|pkgVersion=1.0.0}}
 +
|-
 +
| AdministrationAgreement
 +
| Toedieningsafspraak
 +
| MedicationDispense
 +
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/mp-AdministrationAgreement|nictiz.fhir.nl.r4.medicationprocess9|pkgVersion=1.0.0}}
 +
|-
 +
| MedicationDispense
 +
| Medicatieverstrekking
 +
| MedicationDispense
 +
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/mp-MedicationDispense|nictiz.fhir.nl.r4.medicationprocess9|pkgVersion=1.0.0}}
 +
|-
 +
| MedicationUse2
 +
| Medicatiegebruik2
 +
| MedicationStatement
 +
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/mp-MedicationUse2|nictiz.fhir.nl.r4.medicationprocess9|pkgVersion=1.0.0}}
 +
|-
 +
| MedicationAdministration2
 +
| Medicatietoediening2
 +
| MedicationAdministration
 +
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/mp-MedicationAdministration2|nictiz.fhir.nl.r4.medicationprocess9|pkgVersion=1.0.0}}
 +
|}
 +
 +
=== 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 [[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"
 +
|-
 +
! style="font-weight: bold;text-align:left;" | Building block (EN)
 +
! style="font-weight: bold;text-align:left;" | Building block (NL)
 +
! style="font-weight: bold;text-align:left;" | FHIR resource
 +
! style="font-weight: bold;text-align:left;" | FHIR profile
 +
|-
 +
| Patient
 +
| Patient
 +
| Patient
 +
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/nl-core-Patient|nictiz.fhir.nl.r4.nl-core|pkgVersion=0.5.0-beta1}}
 +
|-
 +
| PharmaceuticalProduct
 +
| FarmaceutischProduct
 +
| Medication
 +
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/nl-core-PharmaceuticalProduct|nictiz.fhir.nl.r4.nl-core|pkgVersion=0.5.0-beta1}}
 +
|-
 +
| Contact
 +
| Contactpersoon
 +
| RelatedPerson
 +
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/nl-core-ContactPerson|nictiz.fhir.nl.r4.nl-core|pkgVersion=0.5.0-beta1}}
 +
|-
 +
| rowspan="2" | HealthProfessional
 +
| rowspan="2" | Zorgverlener
 +
| PractitionerRole
 +
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/nl-core-HealthProfessional-PractitionerRole|nictiz.fhir.nl.r4.nl-core|pkgVersion=0.5.0-beta1}}
 +
|-
 +
| Practitioner
 +
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/nl-core-HealthProfessional-Practitioner|nictiz.fhir.nl.r4.nl-core|pkgVersion=0.5.0-beta1}}
 +
|-
 +
| rowspan="2" | HealthcareProvider
 +
| rowspan="2" | Zorgaanbieder
 +
| Location
 +
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/nl-core-HealthcareProvider|nictiz.fhir.nl.r4.nl-core|pkgVersion=0.5.0-beta1}}
 +
|-
 +
| Organization
 +
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/nl-core-HealthcareProvider-Organization|nictiz.fhir.nl.r4.nl-core|pkgVersion=0.5.0-beta1}}
 +
|-
 +
| BodyHeight
 +
| Lichaamslengte
 +
| Observation
 +
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/nl-core-BodyHeight|nictiz.fhir.nl.r4.nl-core|pkgVersion=0.5.0-beta1}}
 +
|-
 +
| BodyWeight
 +
| Lichaamsgewicht
 +
| Observation
 +
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/nl-core-BodyWeight|nictiz.fhir.nl.r4.nl-core|pkgVersion=0.5.0-beta1}}
 +
|}
 +
 +
Note the following:
 +
* Each occurrence of the zib HealthProfessional is normally represented by '''two''' FHIR resources: an instance of nl-core-HealthProfessional-PractitionerRole and an instance of nl-core-HealthProfessional-Practitioner. Sending systems should only fill the reference to the PractitionerRole instance where relevant. Receiving systems can resolve the reference to the Practitioner resource from that PractitionerRole instance.
 +
* The zib HealthcareProvider is mapped to both a Location and Organization profile. Most often, the Location profile acts as the focal resource, because most references to this zib are concerned about the recording of the physical location where the care to patient/client takes place rather than the organizational information. For the latter, the profile on Organization is used which is referenced using the {{fhir|Location.managingOrganization}} element. Sending systems should only fill the reference to the Location instance where relevant. Incidentally, concepts that are only concerned with organizational information can refer to the Organization instance.
 +
 +
=== Transaction specific profiles ===
 +
 +
For several transactions, additional profiles are provided. For each transaction the profile relevant is explicitly mentioned in the corresponding subsection.
 +
 +
{| class="wikitable"
 +
|-
 +
! style="font-weight: bold;text-align:left;" | Transaction profile (EN)
 +
! style="font-weight: bold;text-align:left;" | Transaction profile (NL)
 +
! style="font-weight: bold;text-align:left;" | FHIR resource
 +
! style="font-weight: bold;text-align:left;" | FHIR profile
 +
|-
 +
| rowspan="2" | MedicationOverview
 +
| rowspan="2" | MedicatieOverzicht
 +
| Bundle
 +
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/mp-MedicationOverview-Bundle|nictiz.fhir.nl.r4.medicationprocess9|pkgVersion=1.0.0}}
 +
|-
 +
| List
 +
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/mp-MedicationOverview|nictiz.fhir.nl.r4.medicationprocess9|pkgVersion=1.0.0}}
 +
|-
 +
| MedicationPrescription
 +
| Voorschrift
 +
| Bundle
 +
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/mp-MedicationPrescription-Bundle|nictiz.fhir.nl.r4.medicationprocess9|pkgVersion=1.0.0}}
 +
|-
 +
| MedicationPrescriptionProcessing
 +
| VoorschriftAfhandeling
 +
| Bundle
 +
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/mp-MedicationPrescriptionProcessing-Bundle|nictiz.fhir.nl.r4.medicationprocess9|pkgVersion=1.0.0}}
 +
|-
 +
| ProposalDispenseRequest
 +
| VoorstelVerstrekkingsverzoek
 +
| Bundle
 +
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/mp-ProposalDispenseRequest-Bundle|nictiz.fhir.nl.r4.medicationprocess9|pkgVersion=1.0.0}}
 +
|-
 +
| rowspan="2" | ReplyProposalDispenseRequest
 +
| rowspan="2" | AntwoordVoorstelVerstrekkingsverzoek
 +
| Bundle
 +
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/mp-ReplyProposalDispenseRequest-Bundle|nictiz.fhir.nl.r4.medicationprocess9|pkgVersion=1.0.0}}
 +
|-
 +
| Communication
 +
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/mp-ReplyProposalDispenseRequest|nictiz.fhir.nl.r4.medicationprocess9|pkgVersion=1.0.0}}
 +
|-
 +
| ProposalMedicationAgreement
 +
| VoorstelMedicatieafspraak
 +
| Bundle
 +
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/mp-ProposalMedicationAgreement-Bundle|nictiz.fhir.nl.r4.medicationprocess9|pkgVersion=1.0.0}}
 +
|-
 +
| rowspan="2" | ReplyProposalMedicationAgreement
 +
| rowspan="2" | AntwoordVoorstelMedicatieafspraak
 +
| Bundle
 +
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/mp-ReplyProposalMedicationAgreement-Bundle|nictiz.fhir.nl.r4.medicationprocess9|pkgVersion=1.0.0}}
 +
|-
 +
| Communication
 +
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/mp-ReplyProposalMedicationAgreement|nictiz.fhir.nl.r4.medicationprocess9|pkgVersion=1.0.0}}
 +
|}
  
 
== Mappings between profiles and data set ==
 
== 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-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 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 nl-core-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']]. Profiles do not explicitly define if or how to apply FHIR DataAbsentReason.
+
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 dataset. 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…’) 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 ==
−
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:V2.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 [[mp:Vprepub-9_2.0.0-beta3_FHIR_MedicationProcess#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:V2.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.
  
 
== Patient identification ==
 
== 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 (authenticated) 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. 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.
  
 
When patient identification requires the use of search parameters, the following search parameters SHALL be supported:
 
When patient identification requires the use of search parameters, the following search parameters SHALL be supported:
Regel 44: Regel 211:
  
 
== 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 Required 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|pkgVersion=0.5.0-beta1}} 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#Including_.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 combination 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.
  
−
{{fhir|Resource.meta.profile}}, altough [[FHIR:Vdraft_FHIR_IG_R4#Profile_use_and_declaration required]] should not be used for this purpose.  
+
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 ===
−
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.
  
−
If applicable, the profiles used by a transaction require the use of {{fhir|.meta.tag}} with {{fhir|.system}}={{term|<nowiki>http://hl7.org/fhir/ValueSet/common-tags</nowiki>}} and {{fhir|.value}}={{term|actionable}} to indicate that the resource is part of a request intented to be acted upon. The absence of this tag indicated the resources is merely of informative nature.
+
{{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.
  
−
It is up to systems to determine how and when the transactions using the {{term|actionable}}-tag are handled from a functional perspective. Systems may store the resource including the {{term|actionable}}-tag or remove it either upon storing or when the request is acted upon. However, systems SHALL make sure the tag is removed when serving or sending the resource as part of an informative transaction.
+
It is up to systems to determine how and when the transactions using the {{term|actionable}} tag are handled from a functional perspective. Systems may store the resource including the {{term|actionable}} tag or remove it either upon storing or when the request is acted upon. However, systems SHALL make sure the tag is removed when serving or sending the resource as part of an informative transaction.
  
 
=== Summarizing table ===
 
=== Summarizing table ===
Regel 66: Regel 236:
 
! style="font-weight: bold;text-align:left;" | PUSH/PULL
 
! style="font-weight: bold;text-align:left;" | PUSH/PULL
 
! style="font-weight: bold;text-align:left;" | Building blocks
 
! style="font-weight: bold;text-align:left;" | Building blocks
−
! style="font-weight: bold;text-align:left;" | {{term|actionable}}-tag
+
! style="font-weight: bold;text-align:left;" | {{term|actionable}} tag
−
! style="font-weight: bold;text-align:left;" | FHIR-element value
+
! style="font-weight: bold;text-align:left;" | FHIR element value
 
! style="font-weight: bold;text-align:left;" | Other
 
! style="font-weight: bold;text-align:left;" | Other
 
|-
 
|-
Regel 74: Regel 244:
 
| One or more of all building blocks
 
| One or more of all building blocks
 
| No
 
| No
−
| -
+
|
 
|  
 
|  
 
|-
 
|-
Regel 81: Regel 251:
 
| One or more of all building blocks
 
| One or more of all building blocks
 
| No
 
| No
−
| -
+
|
−
|  
+
|
 
|-
 
|-
 
| Medication overview (Retrieve/Serve)
 
| Medication overview (Retrieve/Serve)
Regel 88: Regel 258:
 
| MedicationAgreement, AdministrationAgreement, MedicationUse
 
| MedicationAgreement, AdministrationAgreement, MedicationUse
 
| No
 
| No
−
| -
+
|
 
| Includes MedicationOverview List resource in Bundle
 
| Includes MedicationOverview List resource in Bundle
 
|-
 
|-
Regel 95: Regel 265:
 
| MedicationAgreement, AdministrationAgreement, MedicationUse
 
| MedicationAgreement, AdministrationAgreement, MedicationUse
 
| No
 
| No
−
| -
+
|
 
| Includes MedicationOverview List resource in Bundle
 
| Includes MedicationOverview List resource in Bundle
 
|-
 
|-
Regel 102: Regel 272:
 
| MedicationAgreement, DispenseRequest (optional)
 
| MedicationAgreement, DispenseRequest (optional)
 
| Yes
 
| Yes
−
| {{fhir|MedicationRequest.intent}}={{term|order}} (for both MedicationAgreement and DispenseRequest building blocks)
+
| {{fhir|MedicationRequest.intent}} = {{term|order}} (for both MedicationAgreement and DispenseRequest building blocks)
 
|  
 
|  
 
|-
 
|-
Regel 116: Regel 286:
 
| DispenseRequest
 
| DispenseRequest
 
| Yes
 
| Yes
−
| {{fhir|MedicationRequest.intent}}={{term|plan}}
+
| {{fhir|MedicationRequest.intent}} = {{term|plan}}
 
|  
 
|  
 
|-
 
|-
Regel 130: Regel 300:
 
| MedicationAgreement
 
| MedicationAgreement
 
| Yes
 
| Yes
−
| {{fhir|MedicationRequest.intent}}={{term|plan}}
+
| {{fhir|MedicationRequest.intent}} = {{term|plan}}
 
|  
 
|  
 
|-
 
|-
Regel 142: Regel 312:
  
 
= 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. 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 154: Regel 324:
 
! style="text-align:left;"| '''FHIR CapabilityStatement'''
 
! style="text-align:left;"| '''FHIR CapabilityStatement'''
 
|-
 
|-
−
|style="background-color: white;vertical-align:top;" rowspan="2"|[http://decor.nictiz.nl/medicatieproces/mp-html-20220402T205710/sc-2.16.840.1.113883.2.4.3.11.60.20.77.3.131-2022-02-07T000000.html#_2.16.840.1.113883.2.4.3.11.60.20.77.4.299_20220207000000 Medication Data (PULL)]  
+
|style="background-color: white;vertical-align:top;" rowspan="2"|[http://decor.nictiz.nl/medicatieproces/mp-html-20220402T205710/sc-2.16.840.1.113883.2.4.3.11.60.20.77.3.131-2022-02-07T000000.html#_2.16.840.1.113883.2.4.3.11.60.20.77.4.299_20220207000000 Medication data (PULL)]  
 
|style="background-color: white;vertical-align:top;"|[http://decor.nictiz.nl/medicatieproces/mp-html-20220402T205710/tr-2.16.840.1.113883.2.4.3.11.60.20.77.4.300-2022-02-07T000000.html Retrieving medication data]
 
|style="background-color: white;vertical-align:top;"|[http://decor.nictiz.nl/medicatieproces/mp-html-20220402T205710/tr-2.16.840.1.113883.2.4.3.11.60.20.77.4.300-2022-02-07T000000.html Retrieving medication data]
 
|style="background-color: white;vertical-align:top;"|Client  
 
|style="background-color: white;vertical-align:top;"|Client  
 
|style="background-color: white;vertical-align:top;"|MP-MGR
 
|style="background-color: white;vertical-align:top;"|MP-MGR
−
|style="background-color: white;vertical-align:top;"|{{Simplifier|http://nictiz.nl/fhir/CapabilityStatement/MedicationProcess-ClientCapabilities|nictiz.fhir.nl.r4.medicationprocess9|pkgVersion=2.0.0-beta2|title=CapabilityStatement: Client}}
+
|style="background-color: white;vertical-align:top;" rowspan="2"|{{Simplifier|http://nictiz.nl/fhir/CapabilityStatement/mp-MedicationData.RetrieveServe|nictiz.fhir.nl.r4.medicationprocess9|pkgVersion=1.0.0|title=CapabilityStatement Retrieve/serve medication data}}
 
|-
 
|-
−
|style="background-color: white;vertical-align:top;"|[http://decor.nictiz.nl/medicatieproces/mp-html-20220402T205710/tr-2.16.840.1.113883.2.4.3.11.60.20.77.4.300-2022-02-07T000000.html Serving medication data]
+
|style="background-color: white;vertical-align:top;"|[http://decor.nictiz.nl/medicatieproces/mp-html-20220402T205710/tr-2.16.840.1.113883.2.4.3.11.60.20.77.4.301-2022-02-07T000000.html Serving medication data]
 
|style="background-color: white;vertical-align:top;"|Server
 
|style="background-color: white;vertical-align:top;"|Server
 
|style="background-color: white;vertical-align:top;"|MP-MGB
 
|style="background-color: white;vertical-align:top;"|MP-MGB
−
|style="background-color: white;vertical-align:top;"|{{Simplifier|http://nictiz.nl/fhir/CapabilityStatement/MedicationProcess-ServerCapabilities|nictiz.fhir.nl.r4.medicationprocess9|pkgVersion=2.0.0-beta2|title=CapabilityStatement: Server}}
 
 
|}
 
|}
  
−
The names of the transaction groups and transactions link to the functional definition in an ART-DECOR publication which details per scenario which data elements are expected to be supported.
+
=== Retrieve (request message) ===
−
 
+
When a patient or healthcare professional wants to obtain all medication data or specific parts matching various parameters, they issue a retrieve medication data request message. This message uses the HTTP GET method parameterized query against the server's medication FHIR endpoints. These endpoints can be one of the following:
−
=== Retrieve (request messages) ===
 
−
When a patient or healthcare professional wants to obtain all medication data or specific parts matching various parameters, it issues a retrieve medication data request message. This message uses the HTTP GET method parameterized query against the server's medication FHIR endpoints. These endpoints can be one of the following:
 
 
* MedicationRequest
 
* MedicationRequest
 
* MedicationDispense
 
* MedicationDispense
Regel 175: Regel 342:
 
* MedicationAdministration
 
* MedicationAdministration
  
−
The search interaction is performed by an HTTP GET conform the [http://hl7.org/fhir/R4/search.html FHIR search specification], as shown below. This URL is configurable by the client by configuring the query search. Multiple request messages may be needed to retrieve all desired information.
+
The search interaction is performed by an HTTP GET conform the [http://hl7.org/fhir/R4/search.html FHIR search specification], as shown below. This URL is configurable by the client by configuring the search query. Multiple request messages may be needed to retrieve all desired information.
  
 
<pre>GET [base]/[type]{?[parameters]}</pre>
 
<pre>GET [base]/[type]{?[parameters]}</pre>
  
 
==== Search parameters ====
 
==== Search parameters ====
−
====Search Parameters====
+
All search parameters listed in the table below SHALL be supported for processing by servers and MAY be supported by clients.
−
The client MAY supply, and the server SHALL be capable of processing, all search parameters listed in the table below.
 
  
 
{| class="wikitable"
 
{| class="wikitable"
−
! style="font-weight: bold;text-align:left;" | MP9 search parameters
+
! style="font-weight: bold;text-align:left;" | MP9 search parameter
 
! style="font-weight: bold;text-align:left;" | Description
 
! style="font-weight: bold;text-align:left;" | Description
 
! style="font-weight: bold;text-align:left;" | FHIR search parameter
 
! style="font-weight: bold;text-align:left;" | FHIR search parameter
 
! style="font-weight: bold;text-align:left;" | FHIR resource
 
! style="font-weight: bold;text-align:left;" | FHIR resource
 
! style="font-weight: bold;text-align:left;" | Example
 
! style="font-weight: bold;text-align:left;" | Example
 +
|-
 +
| PatientIdentificationNumber
 +
| Search on patient.
 +
| {{fhir|patient.identifier}} <ref name="patient-searchparameter">This search parameter only needs to be supported when patient identification requires the use of search parameters, see [[#Patient_identification|section 2.4]].</ref>
 +
| MedicationRequest, MedicationDispense, MedicationStatement, MedicationAdministration
 +
| Retrieves all MedicationRequest resources of a patient with a fake BSN of 11122233.
 +
<pre>GET [base]/MedicationRequest?patient.identifier=http://fhir.nl/fhir/NamingSystem/bsn|111222333</pre>
 
|-
 
|-
 
| Identification
 
| Identification
Regel 199: Regel 372:
 
| Identification
 
| Identification
 
| Search on the pharmaceutical treatment identifier.  
 
| Search on the pharmaceutical treatment identifier.  
−
Note: retrieval of all medication resoures belonging to one pharmaceutical treatment requires to search on all medication resource types.
+
Note: retrieval of all medication resources belonging to one pharmaceutical treatment requires to search on all medication resource types.
−
| {{fhir|pharmaceutical-treatment-identifier}} <ref name="custom-searchparameter">The search parameter consists of a custom FHIR search parameter not represented in the FHIR specification.</ref>
+
| {{fhir|pharmaceutical-treatment-identifier}} <ref name="custom-searchparameter">The search parameter consists of a custom FHIR search parameter not represented in the FHIR specification. Note that for {{fhir|MedicationRequest.category}} and {{fhir|MedicationStatement.category}} a core search parameter is available, hence no custom one is needed in those cases.</ref>
 
| MedicationRequest, MedicationDispense, MedicationStatement, MedicationAdministration
 
| MedicationRequest, MedicationDispense, MedicationStatement, MedicationAdministration
 
| Retrieves all MedicationRequest resources that are part of a pharmaceutical treatment with a specific identifier.
 
| Retrieves all MedicationRequest resources that are part of a pharmaceutical treatment with a specific identifier.
Regel 210: Regel 383:
 
| MedicationRequest
 
| MedicationRequest
 
| Retrieves all MedicationRequest resources that represent the building block MedicationAgreement.
 
| Retrieves all MedicationRequest resources that represent the building block MedicationAgreement.
−
<pre>GET [base]/MedicationRequest?category=http://snomed.info/sct|16076005</pre>
+
<pre>GET [base]/MedicationRequest?category=http://snomed.info/sct|33633005</pre>
 
Retrieves all MedicationRequest resources that represent the building block DispenseRequest.
 
Retrieves all MedicationRequest resources that represent the building block DispenseRequest.
 
<pre>GET [base]/MedicationRequest?category=http://snomed.info/sct|52711000146108</pre>
 
<pre>GET [base]/MedicationRequest?category=http://snomed.info/sct|52711000146108</pre>
Regel 235: Regel 408:
 
| MedicationRequest, MedicationDispense, MedicationStatement, MedicationAdministration
 
| MedicationRequest, MedicationDispense, MedicationStatement, MedicationAdministration
 
| Retrieves all MedicationRequest resources that represent the building block MedicationAgreement and have Carbasalaatcalcium Sandoz 600 30 as medication.
 
| Retrieves all MedicationRequest resources that represent the building block MedicationAgreement and have Carbasalaatcalcium Sandoz 600 30 as medication.
−
<pre>GET [base]/MedicationRequest?category=http://snomed.info/sct|16076005&medication.code=urn:oid:2.16.840.1.113883.2.4.4.8|13610554</pre>
+
<pre>GET [base]/MedicationRequest?category=http://snomed.info/sct|33633005&medication.code=urn:oid:2.16.840.1.113883.2.4.4.8|13610554</pre>
 
|-
 
|-
 
| PeriodOfUse
 
| PeriodOfUse
 
| Search on medication use in the past, present or future within the specified time period.
 
| Search on medication use in the past, present or future within the specified time period.
 
| {{fhir|period-of-use}}<ref name="custom-searchparameter"/>
 
| {{fhir|period-of-use}}<ref name="custom-searchparameter"/>
−
| MedicationDispense, MedicationRequest
+
| MedicationRequest, MedicationDispense
 
| Retrieves all MedicationRequest resources that represent the building block MedicationAgreement and were in effect from 01-01-2010.
 
| 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|16076005&period-of-use=ge2010-01-01</pre>
+
<pre>GET [base]/MedicationRequest?category=http://snomed.info/sct|33633005&period-of-use=ge2010-01-01</pre>
 
|-
 
|-
 
| DispensePeriod  
 
| DispensePeriod  
Regel 255: Regel 428:
 
| {{fhir|effective-time}}
 
| {{fhir|effective-time}}
 
| MedicationAdministration
 
| MedicationAdministration
−
| Retrieves all MedicationAdministration resources that represent the building block MedicationAdministration2 and were administration happened within a 2 year period.
+
| Retrieves all MedicationAdministration resources that represent the building block MedicationAdministration2 and where administration happened on a specific day.
−
<pre>GET [base]/MedicationAdministration?category=http://snomed.info/sct|18629005&effective-time=ge2010-01-01&effective-time=le2011-12-31</pre>
+
<pre>GET [base]/MedicationAdministration?category=http://snomed.info/sct|18629005&effective-time=eq2022-01-01</pre>
 
|-
 
|-
 
| -
 
| -
 
| 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>}}
Regel 270: Regel 443:
 
The following custom search parameters are defined for this transaction:
 
The following custom search parameters are defined for this transaction:
  
−
* {{Simplifier|http://nictiz.nl/fhir/SearchParameter/pharmaceutical-treatment-identifier|nictiz.fhir.nl.r4.zib2020|pkgVersion=0.1.0-beta1}}
+
* {{Simplifier|http://nictiz.nl/fhir/SearchParameter/pharmaceutical-treatment-identifier|nictiz.fhir.nl.r4.medicationprocess9|pkgVersion=1.0.0}}
−
* {{Simplifier|http://nictiz.nl/fhir/SearchParameter/category|nictiz.fhir.nl.r4.zib2020|pkgVersion=0.1.0-beta1}}
+
* {{Simplifier|http://nictiz.nl/fhir/SearchParameter/category|nictiz.fhir.nl.r4.medicationprocess9|pkgVersion=1.0.0}}
−
* {{Simplifier|http://nictiz.nl/fhir/SearchParameter/period-of-use|nictiz.fhir.nl.r4.zib2020|pkgVersion=0.1.0-beta1}}  
+
* {{Simplifier|http://nictiz.nl/fhir/SearchParameter/period-of-use|nictiz.fhir.nl.r4.medicationprocess9|pkgVersion=1.0.0}}
  
 
==== Retrieve all medication data ====
 
==== Retrieve all medication data ====
Regel 278: Regel 451:
  
 
<pre>
 
<pre>
−
GET [base]/MedicationRequest?category=http://snomed.info/sct|16076005&_include=MedicationRequest:medication
+
GET [base]/MedicationRequest?category=http://snomed.info/sct|33633005&_include=MedicationRequest:medication
 
GET [base]/MedicationRequest?category=http://snomed.info/sct|52711000146108&_include=MedicationRequest:medication
 
GET [base]/MedicationRequest?category=http://snomed.info/sct|52711000146108&_include=MedicationRequest:medication
 
GET [base]/MedicationRequest?category=http://snomed.info/sct|395067002&_include=MedicationRequest:medication
 
GET [base]/MedicationRequest?category=http://snomed.info/sct|395067002&_include=MedicationRequest:medication
Regel 287: Regel 460:
 
</pre>
 
</pre>
  
−
=== Serve (response messages ===
+
=== Serve (response message) ===
−
The server returns an HTTP Status code appropriate to the processing outcome and returns a Bundle, with {{fhir|Bundle.type}}={{term|searchset}}, including the resources matching the search query medication data. The resources included in the Bundle SHALL conform to the profiles listed in section 2.1.
+
The server returns an HTTP Status code appropriate to the processing outcome and returns a Bundle, with {{fhir|Bundle.type}} = {{term|searchset}}, including the resources matching the search query medication data. The resources included in the Bundle SHALL conform to the profiles listed in the 'List of profiles' below.
 +
 
 +
=== List of profiles ===
 +
 
 +
The table below includes all profiles that are explicitly mentioned in the data set of this transaction, and thus need to be supported.
  
 +
{| class="wikitable"
 +
|-
 +
! style="font-weight: bold;text-align:left;" | Building block (EN)
 +
! style="font-weight: bold;text-align:left;" | Building block (NL)
 +
! style="font-weight: bold;text-align:left;" | FHIR resource
 +
! style="font-weight: bold;text-align:left;" | FHIR profile
 +
|-
 +
| MedicationAgreement
 +
| Medicatieafspraak
 +
| MedicationRequest
 +
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/mp-MedicationAgreement|nictiz.fhir.nl.r4.medicationprocess9|pkgVersion=1.0.0}}
 +
|-
 +
| VariableDosingRegimen
 +
| WisselendDoseerschema
 +
| MedicationRequest
 +
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/mp-VariableDosingRegimen|nictiz.fhir.nl.r4.medicationprocess9|pkgVersion=1.0.0}}
 +
|-
 +
| DispenseRequest
 +
| Verstrekkingsverzoek
 +
| MedicationRequest
 +
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/mp-DispenseRequest|nictiz.fhir.nl.r4.medicationprocess9|pkgVersion=1.0.0}}
 +
|-
 +
| AdministrationAgreement
 +
| Toedieningsafspraak
 +
| MedicationDispense
 +
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/mp-AdministrationAgreement|nictiz.fhir.nl.r4.medicationprocess9|pkgVersion=1.0.0}}
 +
|-
 +
| MedicationDispense
 +
| Medicatieverstrekking
 +
| MedicationDispense
 +
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/mp-MedicationDispense|nictiz.fhir.nl.r4.medicationprocess9|pkgVersion=1.0.0}}
 +
|-
 +
| MedicationUse2
 +
| Medicatiegebruik2
 +
| MedicationStatement
 +
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/mp-MedicationUse2|nictiz.fhir.nl.r4.medicationprocess9|pkgVersion=1.0.0}}
 +
|-
 +
| MedicationAdministration2
 +
| Medicatietoediening2
 +
| MedicationAdministration
 +
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/mp-MedicationAdministration2|nictiz.fhir.nl.r4.medicationprocess9|pkgVersion=1.0.0}}
 +
|-
 +
| Patient
 +
| Patient
 +
| Patient
 +
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/nl-core-Patient|nictiz.fhir.nl.r4.nl-core|pkgVersion=0.5.0-beta1}}
 +
|-
 +
| Contact
 +
| Contactpersoon
 +
| RelatedPerson
 +
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/nl-core-ContactPerson|nictiz.fhir.nl.r4.nl-core|pkgVersion=0.5.0-beta1}}
 +
|-
 +
| PharmaceuticalProduct
 +
| FarmaceutischProduct
 +
| Medication
 +
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/nl-core-PharmaceuticalProduct|nictiz.fhir.nl.r4.nl-core|pkgVersion=0.5.0-beta1}}
 +
|-
 +
| rowspan="2" | HealthProfessional
 +
| rowspan="2" | Zorgverlener
 +
| PractitionerRole
 +
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/nl-core-HealthProfessional-PractitionerRole|nictiz.fhir.nl.r4.nl-core|pkgVersion=0.5.0-beta1}}
 +
|-
 +
| Practitioner
 +
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/nl-core-HealthProfessional-Practitioner|nictiz.fhir.nl.r4.nl-core|pkgVersion=0.5.0-beta1}}
 +
|-
 +
| rowspan="2" | HealthcareProvider
 +
| rowspan="2" | Zorgaanbieder
 +
| Location
 +
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/nl-core-HealthcareProvider|nictiz.fhir.nl.r4.nl-core|pkgVersion=0.5.0-beta1}}
 +
|-
 +
| Organization
 +
| {{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.
Regel 300: Regel 551:
 
! style="text-align:left;"| '''FHIR CapabilityStatement'''
 
! style="text-align:left;"| '''FHIR CapabilityStatement'''
 
|-
 
|-
−
|style="background-color: white;vertical-align:top;" rowspan="2"|[http://decor.nictiz.nl/medicatieproces/mp-html-20220402T205710/sc-2.16.840.1.113883.2.4.3.11.60.20.77.3.131-2022-02-07T000000.html#_2.16.840.1.113883.2.4.3.11.60.20.77.4.302_20220207000000 Medication Data (PUSH)]  
+
|style="background-color: white;vertical-align:top;" rowspan="2"|[http://decor.nictiz.nl/medicatieproces/mp-html-20220402T205710/sc-2.16.840.1.113883.2.4.3.11.60.20.77.3.131-2022-02-07T000000.html#_2.16.840.1.113883.2.4.3.11.60.20.77.4.302_20220207000000 Medication data (PUSH)]  
 
|style="background-color: white;vertical-align:top;"|[http://decor.nictiz.nl/medicatieproces/mp-html-20220402T205710/tr-2.16.840.1.113883.2.4.3.11.60.20.77.4.303-2022-02-07T000000.html Sending medication data]
 
|style="background-color: white;vertical-align:top;"|[http://decor.nictiz.nl/medicatieproces/mp-html-20220402T205710/tr-2.16.840.1.113883.2.4.3.11.60.20.77.4.303-2022-02-07T000000.html Sending medication data]
 
|style="background-color: white;vertical-align:top;"|Client  
 
|style="background-color: white;vertical-align:top;"|Client  
 
|style="background-color: white;vertical-align:top;"|MP-MGS
 
|style="background-color: white;vertical-align:top;"|MP-MGS
−
|style="background-color: white;vertical-align:top;"|{{Simplifier|http://nictiz.nl/fhir/CapabilityStatement/MedicationProcess-ClientCapabilities|nictiz.fhir.nl.r4.medicationprocess9|pkgVersion=2.0.0-beta2|title=CapabilityStatement: Client}}
+
|style="background-color: white;vertical-align:top;" rowspan="2"|{{Simplifier|http://nictiz.nl/fhir/CapabilityStatement/mp-MedicationData.SendReceive|nictiz.fhir.nl.r4.medicationprocess9|pkgVersion=1.0.0|title=CapabilityStatement Send/receive medication data}}
 
|-
 
|-
 
|style="background-color: white;vertical-align:top;"|Receiving medication data
 
|style="background-color: white;vertical-align:top;"|Receiving medication data
 
|style="background-color: white;vertical-align:top;"|Server
 
|style="background-color: white;vertical-align:top;"|Server
 
|style="background-color: white;vertical-align:top;"|MP-MGO
 
|style="background-color: white;vertical-align:top;"|MP-MGO
−
|style="background-color: white;vertical-align:top;"|{{Simplifier|http://nictiz.nl/fhir/CapabilityStatement/MedicationProcess-ServerCapabilities|nictiz.fhir.nl.r4.medicationprocess9|pkgVersion=2.0.0-beta2|title=CapabilityStatement: Server}}
 
 
|}
 
|}
−
 
−
The names of the transaction groups and transactions link to the functional definition in an ART-DECOR publication which details per scenario which data elements are expected to be supported.
 
  
 
=== Send (request message) ===
 
=== Send (request message) ===
Regel 319: Regel 567:
 
{{MpFhirSendTransaction}}
 
{{MpFhirSendTransaction}}
  
−
The resources included in the Bundle SHALL conform to the profiles listed in section 3.1. Because of the informative nature of the transaction, '''no''' [[mp:Vprepub-9_2.0.0-beta3_FHIR_MedicationProcess#Actionable_tag|{{term|actionable}}-tags]] shall be present.
+
The resources included in the Bundle SHALL conform to the profiles listed in the 'List of profiles' below. Because of the informative nature of the transaction, '''no''' [[#Actionable_tag|{{term|actionable}} tags]] shall be present.
  
 
=== Receive (response message) ===
 
=== Receive (response message) ===
−
The server checks each resource present within the Bundle it receives for the absence of [[mp:Vprepub-9_2.0.0-beta3_FHIR_MedicationProcess#Actionable_tag|{{term|actionable}}-tags]].
+
The server checks each resource present within the Bundle it receives for the absence of [[#Actionable_tag|{{term|actionable}} tags]].
 +
 
 +
{{MpFhirReceiveTransaction}}
  
−
The server returns an HTTP Status code appropriate to the processing outcome. If the transaction is successful, the server returns a Bundle with {{fhir|Bundle.type}}={{term|transaction-response}}, that contains one entry for each entry in the request, in the same order, with the outcome of processing the entry. Included ‘secondary resources’ are handled [[FHIR:Vdraft_FHIR_IG_R4#Referring_other_resources_when_sending_information|following the Nictiz IG]].
+
=== List of profiles ===
  
−
If the transaction fails, the server returns an OperationOutcome with one or multiple {{fhir|.issue}} elements filled with information, as detailed as possible, that describes why the transaction failed and which resource and/or request caused this.
+
The table below includes all profiles that are explicitly mentioned in the data set of this transaction, and thus need to be supported.
 +
 
 +
{| class="wikitable"
 +
|-
 +
! style="font-weight: bold;text-align:left;" | Building block (EN)
 +
! style="font-weight: bold;text-align:left;" | Building block (NL)
 +
! style="font-weight: bold;text-align:left;" | FHIR resource
 +
! style="font-weight: bold;text-align:left;" | FHIR profile
 +
|-
 +
| MedicationAgreement
 +
| Medicatieafspraak
 +
| MedicationRequest
 +
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/mp-MedicationAgreement|nictiz.fhir.nl.r4.medicationprocess9|pkgVersion=1.0.0}}
 +
|-
 +
| VariableDosingRegimen
 +
| WisselendDoseerschema
 +
| MedicationRequest
 +
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/mp-VariableDosingRegimen|nictiz.fhir.nl.r4.medicationprocess9|pkgVersion=1.0.0}}
 +
|-
 +
| DispenseRequest
 +
| Verstrekkingsverzoek
 +
| MedicationRequest
 +
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/mp-DispenseRequest|nictiz.fhir.nl.r4.medicationprocess9|pkgVersion=1.0.0}}
 +
|-
 +
| AdministrationAgreement
 +
| Toedieningsafspraak
 +
| MedicationDispense
 +
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/mp-AdministrationAgreement|nictiz.fhir.nl.r4.medicationprocess9|pkgVersion=1.0.0}}
 +
|-
 +
| MedicationDispense
 +
| Medicatieverstrekking
 +
| MedicationDispense
 +
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/mp-MedicationDispense|nictiz.fhir.nl.r4.medicationprocess9|pkgVersion=1.0.0}}
 +
|-
 +
| MedicationUse2
 +
| Medicatiegebruik2
 +
| MedicationStatement
 +
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/mp-MedicationUse2|nictiz.fhir.nl.r4.medicationprocess9|pkgVersion=1.0.0}}
 +
|-
 +
| MedicationAdministration2
 +
| Medicatietoediening2
 +
| MedicationAdministration
 +
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/mp-MedicationAdministration2|nictiz.fhir.nl.r4.medicationprocess9|pkgVersion=1.0.0}}
 +
|-
 +
| Patient
 +
| Patient
 +
| Patient
 +
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/nl-core-Patient|nictiz.fhir.nl.r4.nl-core|pkgVersion=0.5.0-beta1}}
 +
|-
 +
| Contact
 +
| Contactpersoon
 +
| RelatedPerson
 +
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/nl-core-ContactPerson|nictiz.fhir.nl.r4.nl-core|pkgVersion=0.5.0-beta1}}
 +
|-
 +
| PharmaceuticalProduct
 +
| FarmaceutischProduct
 +
| Medication
 +
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/nl-core-PharmaceuticalProduct|nictiz.fhir.nl.r4.nl-core|pkgVersion=0.5.0-beta1}}
 +
|-
 +
| rowspan="2" | HealthProfessional
 +
| rowspan="2" | Zorgverlener
 +
| PractitionerRole
 +
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/nl-core-HealthProfessional-PractitionerRole|nictiz.fhir.nl.r4.nl-core|pkgVersion=0.5.0-beta1}}
 +
|-
 +
| Practitioner
 +
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/nl-core-HealthProfessional-Practitioner|nictiz.fhir.nl.r4.nl-core|pkgVersion=0.5.0-beta1}}
 +
|-
 +
| rowspan="2" | HealthcareProvider
 +
| rowspan="2" | Zorgaanbieder
 +
| Location
 +
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/nl-core-HealthcareProvider|nictiz.fhir.nl.r4.nl-core|pkgVersion=0.5.0-beta1}}
 +
|-
 +
| Organization
 +
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/nl-core-HealthcareProvider-Organization|nictiz.fhir.nl.r4.nl-core|pkgVersion=0.5.0-beta1}}
 +
|}
  
 
== Medication overview (Retrieve/Serve) ==
 
== Medication overview (Retrieve/Serve) ==
−
{{IssueBox|The Medication overview transaction groups will be updated at a later point in time.}}
 
 
The retrieve medication overview transaction is used by the client to retrieve a medication overview from the server.
 
The retrieve medication overview transaction is used by the client to retrieve a medication overview from the server.
  
−
=== Actors ===
 
 
{| class="wikitable" "cellpadding="10"
 
{| class="wikitable" "cellpadding="10"
 
! style="text-align:left;"| '''Transaction group'''
 
! style="text-align:left;"| '''Transaction group'''
 
! style="text-align:left;"| '''Transaction'''
 
! style="text-align:left;"| '''Transaction'''
 
! style="text-align:left;"| '''Actor'''
 
! style="text-align:left;"| '''Actor'''
−
! style="text-align:left;"| '''Role'''
+
! style="text-align:left;"| '''System role'''
 +
! style="text-align:left;"| '''FHIR CapabilityStatement'''
 
|-
 
|-
−
|style="background-color: white;vertical-align:top;" rowspan="2"|[https://decor.nictiz.nl/pub/medicatieproces/mp-html-20210921T194523/sc-2.16.840.1.113883.2.4.3.11.60.20.77.3.28-2021-04-14T153926.html#_2.16.840.1.113883.2.4.3.11.60.20.77.4.189_20210414153926 Retrieve Medication overview (PULL)]
+
|style="background-color: white;vertical-align:top;" rowspan="2"|[http://decor.nictiz.nl/medicatieproces/mp-html-20220402T205710/sc-2.16.840.1.113883.2.4.3.11.60.20.77.3.132-2022-02-07T000000.html#_2.16.840.1.113883.2.4.3.11.60.20.77.4.315_20220207000000 Medication overview (PULL)]
−
|style="background-color: white;vertical-align:top;"|[https://decor.nictiz.nl/pub/medicatieproces/mp-html-20210921T194523/tr-2.16.840.1.113883.2.4.3.11.60.20.77.4.190-2021-04-14T153926.html Consulting medication overview]
+
|style="background-color: white;vertical-align:top;"|[http://decor.nictiz.nl/medicatieproces/mp-html-20220402T205710/tr-2.16.840.1.113883.2.4.3.11.60.20.77.4.316-2022-02-07T000000.html Retrieving medication overview]
 
|style="background-color: white;vertical-align:top;"|Client
 
|style="background-color: white;vertical-align:top;"|Client
−
|style="background-color: white;vertical-align:top;"|Request Medication overview
+
|style="background-color: white;vertical-align:top;"|MP-MOR
 +
|style="background-color: white;vertical-align:top;" rowspan="2"|{{Simplifier|http://nictiz.nl/fhir/CapabilityStatement/mp-MedicationOverview.RetrieveServe|nictiz.fhir.nl.r4.medicationprocess9|pkgVersion=1.0.0|title=CapabilityStatement Retrieve/serve medication overview}}
 
|-
 
|-
−
|style="background-color: white;vertical-align:top;"|[https://decor.nictiz.nl/pub/medicatieproces/mp-html-20210921T194523/tr-2.16.840.1.113883.2.4.3.11.60.20.77.4.191-2021-04-14T153926.html Making medication overview available]
+
|style="background-color: white;vertical-align:top;"|[http://decor.nictiz.nl/medicatieproces/mp-html-20220402T205710/tr-2.16.840.1.113883.2.4.3.11.60.20.77.4.317-2022-02-07T000000.html Serving medication overview]
 
|style="background-color: white;vertical-align:top;"|Server
 
|style="background-color: white;vertical-align:top;"|Server
−
|style="background-color: white;vertical-align:top;"|Serve Medication overview
+
|style="background-color: white;vertical-align:top;"|MP-MOB
 
|}
 
|}
−
The names of the transaction groups and transactions link to the functional definition in an ART-DECOR publication which details per scenario which data elements are used.
 
  
−
=== Invocations ===
+
=== Retrieve (request message) ===
−
==== Request message ====
+
When a patient or healthcare professional wants to obtain a patient's medication overview, they issue a retrieve medication overview request message. This message uses an extended operation on the RESTful API to obtain a medication overview from a server. An operation is needed because the server will formulate the content of the response based on its internal business logic. The medication overview can not easily be described by standardized RESTful requests.  
−
When the patient or healthcare professional wants to obtain a patient's medication overview, it issues a Consulting medication overview request message.
 
−
This message uses an extended operation on the RESTful API to obtain a medication overview from a server. An operation is needed because the server will formulate the content of the response based on its internal business logic. The medication overview can not easily be described by standardized restful requests.  
 
  
−
The client executes a {{Simplifier|http://nictiz.nl/fhir/OperationDefinition/Medication-Overview|nictiz.fhir.nl.r4.medicationprocess9|pkgVersion=2.0.0-beta2|title=medication-overview operation}} with HTTP POST against the server base endpoint as shown below.
+
The client executes a {{Simplifier|http://nictiz.nl/fhir/OperationDefinition/Medication-Overview|nictiz.fhir.nl.r4.medicationprocess9|title=medication-overview operation}} with an HTTP GET command conform the [http://hl7.org/fhir/R4/search.html FHIR search specification], as shown below. This URL is configurable by the client by configuring the search query.
  
 
<pre>
 
<pre>
−
POST [base]/$medication-overview
+
GET [base]/$medication-overview
 
</pre>
 
</pre>
  
−
==== Response message ====
+
=== Serve (response message) ===
−
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|pkgVersion=2.0.0-beta2|title={{fhir|$medication-overview}} operation}} is the body of the medication overview response message. Successful processing of this operation should result in a Bundle recourse of type 'searchset', containing one List and one Patient resource as entries along with all the resources that represent the current medication overview. These resources SHALL be referenced from the List resource. 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 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 Bundle profile represents the structure of the retrieve medication overview response message. The List profile represents the medication overview. The List contains the medication overview metadata and references to all resources that constitute the medication overview. These resources are included in the Bundle as entries. The {{fhir|Bundle.total}} value contains the number of matching zib: MedicationUse, AdministrationAgreement and MedicationAgreement. Other included resources, such as Medication resources, are not included in the total. The returned Bundle has at least one List and one Patient resource. The returned data to the client SHALL be a valid instance of its applicable profile as shown in the [[#List_of_Profiles|List of Profiles]].
+
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].
  
−
'''Note''' that the medication resources blocks are grouped per 'pharmaceutical treatment' conform to the [https://informatiestandaarden.nictiz.nl/wiki/mp:V9_2.0.0_Ontwerp_medicatieproces_ENG#.27Medicamenteuze_behandeling.27 Medication Process specification]. Grouping SHALL be done by use of a 'Pharmaceutical Treatment Identifier'. This identifier shall be the same across different related medication resources that constitute one medication treatment. The {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/ext-PharmaceuticalTreatment.Identifier|nictiz.fhir.nl.r4.zib2020|pkgVersion=0.1.0-beta1|title=PharmaceuticalTreatmentIdentifier extension}} is to be used for this grouping purpose.
+
=== List of profiles ===
 +
 
 +
The table below includes all profiles that are explicitly mentioned in the data set of this transaction, and thus need to be supported.
 +
 
 +
{| class="wikitable"
 +
|-
 +
! style="font-weight: bold;text-align:left;" | Building block/transaction profile (EN)
 +
! style="font-weight: bold;text-align:left;" | Building block/transaction profile (NL)
 +
! style="font-weight: bold;text-align:left;" | FHIR resource
 +
! style="font-weight: bold;text-align:left;" | FHIR profile
 +
|-
 +
| rowspan="2" | MedicationOverview
 +
| rowspan="2" | MedicatieOverzicht
 +
| Bundle
 +
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/mp-MedicationOverview-Bundle|nictiz.fhir.nl.r4.medicationprocess9|pkgVersion=1.0.0}}
 +
|-
 +
| List
 +
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/mp-MedicationOverview|nictiz.fhir.nl.r4.medicationprocess9|pkgVersion=1.0.0}}
 +
|-
 +
| MedicationAgreement
 +
| Medicatieafspraak
 +
| MedicationRequest
 +
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/mp-MedicationAgreement|nictiz.fhir.nl.r4.medicationprocess9|pkgVersion=1.0.0}}
 +
|-
 +
| AdministrationAgreement
 +
| Toedieningsafspraak
 +
| MedicationDispense
 +
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/mp-AdministrationAgreement|nictiz.fhir.nl.r4.medicationprocess9|pkgVersion=1.0.0}}
 +
|-
 +
| MedicationUse2
 +
| Medicatiegebruik2
 +
| MedicationStatement
 +
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/mp-MedicationUse2|nictiz.fhir.nl.r4.medicationprocess9|pkgVersion=1.0.0}}
 +
|-
 +
| Patient
 +
| Patient
 +
| Patient
 +
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/nl-core-Patient|nictiz.fhir.nl.r4.nl-core|pkgVersion=0.5.0-beta1}}
 +
|-
 +
| Contact
 +
| Contactpersoon
 +
| RelatedPerson
 +
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/nl-core-ContactPerson|nictiz.fhir.nl.r4.nl-core|pkgVersion=0.5.0-beta1}}
 +
|-
 +
| PharmaceuticalProduct
 +
| FarmaceutischProduct
 +
| Medication
 +
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/nl-core-PharmaceuticalProduct|nictiz.fhir.nl.r4.nl-core|pkgVersion=0.5.0-beta1}}
 +
|-
 +
| rowspan="2" | HealthProfessional
 +
| rowspan="2" | Zorgverlener
 +
| PractitionerRole
 +
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/nl-core-HealthProfessional-PractitionerRole|nictiz.fhir.nl.r4.nl-core|pkgVersion=0.5.0-beta1}}
 +
|-
 +
| Practitioner
 +
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/nl-core-HealthProfessional-Practitioner|nictiz.fhir.nl.r4.nl-core|pkgVersion=0.5.0-beta1}}
 +
|-
 +
| rowspan="2" | HealthcareProvider
 +
| rowspan="2" | Zorgaanbieder
 +
| Location
 +
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/nl-core-HealthcareProvider|nictiz.fhir.nl.r4.nl-core|pkgVersion=0.5.0-beta1}}
 +
|-
 +
| Organization
 +
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/nl-core-HealthcareProvider-Organization|nictiz.fhir.nl.r4.nl-core|pkgVersion=0.5.0-beta1}}
 +
|-
 +
| BodyHeight
 +
| Lichaamslengte
 +
| Observation
 +
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/nl-core-BodyHeight|nictiz.fhir.nl.r4.nl-core|pkgVersion=0.5.0-beta1}}
 +
|-
 +
| BodyWeight
 +
| Lichaamsgewicht
 +
| Observation
 +
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/nl-core-BodyWeight|nictiz.fhir.nl.r4.nl-core|pkgVersion=0.5.0-beta1}}
 +
|}
  
 
== Medication overview (Send/Receive) ==
 
== Medication overview (Send/Receive) ==
−
{{IssueBox|The Medication overview transaction groups will be updated at a later point in time.}}
+
The send medication overview transaction is used by the client to send a medication overview to a server.
 +
 
 +
{| class="wikitable" "cellpadding="10"
 +
! style="text-align:left;"| '''Transaction group'''
 +
! style="text-align:left;"| '''Transaction'''
 +
! style="text-align:left;"| '''Actor'''
 +
! style="text-align:left;"| '''System role'''
 +
! style="text-align:left;"| '''FHIR CapabilityStatement'''
 +
|-
 +
|style="background-color: white;vertical-align:top;" rowspan="2"|[http://decor.nictiz.nl/medicatieproces/mp-html-20220402T205710/sc-2.16.840.1.113883.2.4.3.11.60.20.77.3.132-2022-02-07T000000.html#_2.16.840.1.113883.2.4.3.11.60.20.77.4.318_20220207000000 Medication overview (PUSH)]
 +
|style="background-color: white;vertical-align:top;"|[https://decor.nictiz.nl/pub/medicatieproces/mp-html-20220402T205710/tr-2.16.840.1.113883.2.4.3.11.60.20.77.4.319-2022-02-07T000000.html Sending medication overview]
 +
|style="background-color: white;vertical-align:top;"|Client
 +
|style="background-color: white;vertical-align:top;"|MP-MOS
 +
|style="background-color: white;vertical-align:top;" rowspan="2"|{{Simplifier|http://nictiz.nl/fhir/CapabilityStatement/mp-MedicationOverview.SendReceive|nictiz.fhir.nl.r4.medicationprocess9|pkgVersion=1.0.0|title=CapabilityStatement Send/receive medication overview}}
 +
|-
 +
|style="background-color: white;vertical-align:top;"|Receiving medication overview
 +
|style="background-color: white;vertical-align:top;"|Server
 +
|style="background-color: white;vertical-align:top;"|MP-MOO
 +
|}
 +
 
 +
=== Send (request message) ===
 +
Because a medication overview consists of several building blocks along with supporting resources, a {{term|transaction}} interaction is used.
 +
 
 +
{{MpFhirSendTransaction}}
 +
 
 +
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].
 +
 
 +
=== Receive (response message) ===
 +
 
 +
{{MpFhirReceiveTransaction}}
 +
 
 +
=== List of profiles ===
 +
 
 +
The table below includes all profiles that are explicitly mentioned in the data set of this transaction, and thus need to be supported.
 +
 
 +
{| class="wikitable"
 +
|-
 +
! style="font-weight: bold;text-align:left;" | Building block/transaction profile (EN)
 +
! style="font-weight: bold;text-align:left;" | Building block/transaction profile (NL)
 +
! style="font-weight: bold;text-align:left;" | FHIR resource
 +
! style="font-weight: bold;text-align:left;" | FHIR profile
 +
|-
 +
| rowspan="2" | MedicationOverview
 +
| rowspan="2" | MedicatieOverzicht
 +
| Bundle
 +
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/mp-MedicationOverview-Bundle|nictiz.fhir.nl.r4.medicationprocess9|pkgVersion=1.0.0}}
 +
|-
 +
| List
 +
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/mp-MedicationOverview|nictiz.fhir.nl.r4.medicationprocess9|pkgVersion=1.0.0}}
 +
|-
 +
| MedicationAgreement
 +
| Medicatieafspraak
 +
| MedicationRequest
 +
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/mp-MedicationAgreement|nictiz.fhir.nl.r4.medicationprocess9|pkgVersion=1.0.0}}
 +
|-
 +
| AdministrationAgreement
 +
| Toedieningsafspraak
 +
| MedicationDispense
 +
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/mp-AdministrationAgreement|nictiz.fhir.nl.r4.medicationprocess9|pkgVersion=1.0.0}}
 +
|-
 +
| MedicationUse2
 +
| Medicatiegebruik2
 +
| MedicationStatement
 +
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/mp-MedicationUse2|nictiz.fhir.nl.r4.medicationprocess9|pkgVersion=1.0.0}}
 +
|-
 +
| Patient
 +
| Patient
 +
| Patient
 +
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/nl-core-Patient|nictiz.fhir.nl.r4.nl-core|pkgVersion=0.5.0-beta1}}
 +
|-
 +
| Contact
 +
| Contactpersoon
 +
| RelatedPerson
 +
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/nl-core-ContactPerson|nictiz.fhir.nl.r4.nl-core|pkgVersion=0.5.0-beta1}}
 +
|-
 +
| PharmaceuticalProduct
 +
| FarmaceutischProduct
 +
| Medication
 +
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/nl-core-PharmaceuticalProduct|nictiz.fhir.nl.r4.nl-core|pkgVersion=0.5.0-beta1}}
 +
|-
 +
| rowspan="2" | HealthProfessional
 +
| rowspan="2" | Zorgverlener
 +
| PractitionerRole
 +
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/nl-core-HealthProfessional-PractitionerRole|nictiz.fhir.nl.r4.nl-core|pkgVersion=0.5.0-beta1}}
 +
|-
 +
| Practitioner
 +
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/nl-core-HealthProfessional-Practitioner|nictiz.fhir.nl.r4.nl-core|pkgVersion=0.5.0-beta1}}
 +
|-
 +
| rowspan="2" | HealthcareProvider
 +
| rowspan="2" | Zorgaanbieder
 +
| Location
 +
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/nl-core-HealthcareProvider|nictiz.fhir.nl.r4.nl-core|pkgVersion=0.5.0-beta1}}
 +
|-
 +
| Organization
 +
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/nl-core-HealthcareProvider-Organization|nictiz.fhir.nl.r4.nl-core|pkgVersion=0.5.0-beta1}}
 +
|-
 +
| BodyHeight
 +
| Lichaamslengte
 +
| Observation
 +
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/nl-core-BodyHeight|nictiz.fhir.nl.r4.nl-core|pkgVersion=0.5.0-beta1}}
 +
|-
 +
| BodyWeight
 +
| Lichaamsgewicht
 +
| Observation
 +
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/nl-core-BodyWeight|nictiz.fhir.nl.r4.nl-core|pkgVersion=0.5.0-beta1}}
 +
|}
  
 
== Medication prescription (Send/Receive) ==
 
== Medication prescription (Send/Receive) ==
−
The send medication prescription transaction is used by the client to send a request to dispense medication (verstrekkingsverzoek) or process modifications to a medication agreement (medicatieafspraak) to a server.
+
The send medication prescription transaction is used by the client to send a request to dispense medication (Dutch: verstrekkingsverzoek) or process modifications to a medication agreement (Dutch: medicatieafspraak) to a server.
  
 
{| class="wikitable" "cellpadding="10"
 
{| class="wikitable" "cellpadding="10"
Regel 385: Regel 887:
 
|style="background-color: white;vertical-align:top;"|Client  
 
|style="background-color: white;vertical-align:top;"|Client  
 
|style="background-color: white;vertical-align:top;"|MP-VOS
 
|style="background-color: white;vertical-align:top;"|MP-VOS
−
|style="background-color: white;vertical-align:top;"|{{Simplifier|http://nictiz.nl/fhir/CapabilityStatement/MedicationProcess-ClientCapabilities|nictiz.fhir.nl.r4.medicationprocess9|pkgVersion=2.0.0-beta2|title=CapabilityStatement: Client}}
+
|style="background-color: white;vertical-align:top;" rowspan="2"|{{Simplifier|http://nictiz.nl/fhir/CapabilityStatement/mp-MedicationPrescription|nictiz.fhir.nl.r4.medicationprocess9|pkgVersion=1.0.0|title=CapabilityStatement Send/receive medication prescription}}
 
|-
 
|-
 
|style="background-color: white;vertical-align:top;"|Receiving medication prescription
 
|style="background-color: white;vertical-align:top;"|Receiving medication prescription
 
|style="background-color: white;vertical-align:top;"|Server
 
|style="background-color: white;vertical-align:top;"|Server
 
|style="background-color: white;vertical-align:top;"|MP-VOO
 
|style="background-color: white;vertical-align:top;"|MP-VOO
−
|style="background-color: white;vertical-align:top;"|{{Simplifier|http://nictiz.nl/fhir/CapabilityStatement/MedicationProcess-ServerCapabilities|nictiz.fhir.nl.r4.medicationprocess9|pkgVersion=2.0.0-beta2|title=CapabilityStatement: Server}}
 
 
|}
 
|}
−
 
−
The names of the transaction groups and transactions link to the functional definition in an ART-DECOR publication which details per scenario which data elements are expected to be supported.
 
  
 
=== Send (request message) ===
 
=== Send (request message) ===
Regel 400: Regel 899:
 
{{MpFhirSendTransaction}}
 
{{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 and at least one instance of nl-core-PharmaceuticalProduct are included, together with optional instances of nl-core-BodyWeight, nl-core-BodyHeight and nl-core-LaboratoryTestResult. All resources included in the Bundle SHALL conform to their respective profiles listed in section 2.1.
+
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 mp-MedicationPrescription-Bundle profile prescribes the use of [[mp:Vprepub-9_2.0.0-beta3_FHIR_MedicationProcess#Actionable_tag|{{term|actionable}}-tags]] to indicate that the resources sent are part of a prescription and of actionable nature.
+
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.
  
 
=== Receive (response message) ===
 
=== Receive (response message) ===
−
The server checks the MedicationAgreement and DispenseRequest building blocks present within the Bundle it receives for the presence of [[mp:Vprepub-9_2.0.0-beta3_FHIR_MedicationProcess#Actionable_tag|{{term|actionable}}-tags]] and the value of {{fhir|MedicationRequest.intent}}={{term|order}} to determine the transaction type.
+
The server checks the MedicationAgreement and DispenseRequest building blocks present within the Bundle it receives for the presence of [[#Actionable_tag|{{term|actionable}} tags]] and the value of {{fhir|MedicationRequest.intent}} = {{term|order}} to determine the transaction type.
  
−
The server returns an HTTP Status code appropriate to the processing outcome. If the transaction is successful, the server returns a Bundle with {{fhir|Bundle.type}}={{term|transaction-response}}, that contains one entry for each entry in the request, in the same order, with the outcome of processing the entry. Included ‘secondary resources’ are handled [[FHIR:Vdraft_FHIR_IG_R4#Referring_other_resources_when_sending_information|following the Nictiz IG]].
+
{{MpFhirReceiveTransaction}}
  
−
If the transaction fails, the server returns an OperationOutcome with one or multiple {{fhir|.issue}} elements filled with information, as detailed as possible, that describes why the transaction failed and which resource and/or request caused this.
+
Aside from the technical processing outcome described above, after functional processing an invocation of the [[#Medication_prescription_processing_.28Send.2FReceive.29|‘Send medication prescription processing’ transaction]] is expected.
  
−
Aside from the technical processing outcome described above, after functional processing an invocation of the [[mp:Vprepub-9_2.0.0-beta3_FHIR_MedicationProcess#Medication_prescription_processing_.28Send.2FReceive.29|‘Send medication prescription processing’ transaction]] is expected.
+
=== List of profiles ===
 +
 
 +
The table below includes all profiles that are explicitly mentioned in the data set of this transaction, and thus need to be supported.
 +
 
 +
{| class="wikitable"
 +
|-
 +
! style="font-weight: bold;text-align:left;" | Building block/transaction profile (EN)
 +
! style="font-weight: bold;text-align:left;" | Building block/transaction profile (NL)
 +
! style="font-weight: bold;text-align:left;" | FHIR resource
 +
! style="font-weight: bold;text-align:left;" | FHIR profile
 +
|-
 +
| MedicationPrescription
 +
| Voorschrift
 +
| Bundle
 +
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/mp-MedicationPrescription-Bundle|nictiz.fhir.nl.r4.medicationprocess9|pkgVersion=1.0.0}}
 +
|-
 +
| MedicationAgreement
 +
| Medicatieafspraak
 +
| MedicationRequest
 +
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/mp-MedicationAgreement|nictiz.fhir.nl.r4.medicationprocess9|pkgVersion=1.0.0}}
 +
|-
 +
| DispenseRequest
 +
| Verstrekkingsverzoek
 +
| MedicationRequest
 +
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/mp-DispenseRequest|nictiz.fhir.nl.r4.medicationprocess9|pkgVersion=1.0.0}}
 +
|-
 +
| Patient
 +
| Patient
 +
| Patient
 +
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/nl-core-Patient|nictiz.fhir.nl.r4.nl-core|pkgVersion=0.5.0-beta1}}
 +
|-
 +
| PharmaceuticalProduct
 +
| FarmaceutischProduct
 +
| Medication
 +
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/nl-core-PharmaceuticalProduct|nictiz.fhir.nl.r4.nl-core|pkgVersion=0.5.0-beta1}}
 +
|-
 +
| rowspan="2" | HealthProfessional
 +
| rowspan="2" | Zorgverlener
 +
| PractitionerRole
 +
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/nl-core-HealthProfessional-PractitionerRole|nictiz.fhir.nl.r4.nl-core|pkgVersion=0.5.0-beta1}}
 +
|-
 +
| Practitioner
 +
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/nl-core-HealthProfessional-Practitioner|nictiz.fhir.nl.r4.nl-core|pkgVersion=0.5.0-beta1}}
 +
|-
 +
| rowspan="2" | HealthcareProvider
 +
| rowspan="2" | Zorgaanbieder
 +
| Location
 +
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/nl-core-HealthcareProvider|nictiz.fhir.nl.r4.nl-core|pkgVersion=0.5.0-beta1}}
 +
|-
 +
| Organization
 +
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/nl-core-HealthcareProvider-Organization|nictiz.fhir.nl.r4.nl-core|pkgVersion=0.5.0-beta1}}
 +
|-
 +
| BodyHeight
 +
| Lichaamslengte
 +
| Observation
 +
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/nl-core-BodyHeight|nictiz.fhir.nl.r4.nl-core|pkgVersion=0.5.0-beta1}}
 +
|-
 +
| BodyWeight
 +
| Lichaamsgewicht
 +
| Observation
 +
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/nl-core-BodyWeight|nictiz.fhir.nl.r4.nl-core|pkgVersion=0.5.0-beta1}}
 +
|}
  
 
== Medication prescription processing (Send/Receive) ==
 
== Medication prescription processing (Send/Receive) ==
−
The send medication prescription processing transaction is used by the client to send data on the processing of a medication agreement (medicatieafspraak) and possibly a dispense request (verstrekkingsverzoek), in the form of an administration agreement (toedieningsafspraak) and optionally a medication dispense (medicatieverstrekking).
+
The send medication prescription processing transaction is used by the client to send data on the processing of a medication agreement (Dutch: medicatieafspraak) and possibly a dispense request (Dutch: verstrekkingsverzoek), in the form of an administration agreement (Dutch: toedieningsafspraak) and optionally a medication dispense (Dutch: medicatieverstrekking).
  
 
{| class="wikitable" "cellpadding="10"
 
{| class="wikitable" "cellpadding="10"
Regel 427: Regel 987:
 
|style="background-color: white;vertical-align:top;"|Client  
 
|style="background-color: white;vertical-align:top;"|Client  
 
|style="background-color: white;vertical-align:top;"|MP-VAS
 
|style="background-color: white;vertical-align:top;"|MP-VAS
−
|style="background-color: white;vertical-align:top;"|{{Simplifier|http://nictiz.nl/fhir/CapabilityStatement/MedicationProcess-ClientCapabilities|nictiz.fhir.nl.r4.medicationprocess9|pkgVersion=2.0.0-beta2|title=CapabilityStatement: Client}}
+
|style="background-color: white;vertical-align:top;" rowspan="2"|{{Simplifier|http://nictiz.nl/fhir/CapabilityStatement/mp-MedicationPrescriptionProcessing|nictiz.fhir.nl.r4.medicationprocess9|pkgVersion=1.0.0|title=CapabilityStatement Send/receive medication prescription processing}}
 
|-
 
|-
 
|style="background-color: white;vertical-align:top;"|Receiving data on processing of medication prescription
 
|style="background-color: white;vertical-align:top;"|Receiving data on processing of medication prescription
 
|style="background-color: white;vertical-align:top;"|Server
 
|style="background-color: white;vertical-align:top;"|Server
 
|style="background-color: white;vertical-align:top;"|MP-VAO
 
|style="background-color: white;vertical-align:top;"|MP-VAO
−
|style="background-color: white;vertical-align:top;"|{{Simplifier|http://nictiz.nl/fhir/CapabilityStatement/MedicationProcess-ServerCapabilities|nictiz.fhir.nl.r4.medicationprocess9|pkgVersion=2.0.0-beta2|title=CapabilityStatement: Server}}
 
 
|}
 
|}
−
 
−
The names of the transaction groups and transactions link to the functional definition in an ART-DECOR publication which details per scenario which data elements are expected to be supported.
 
  
 
=== Send (request message) ===
 
=== Send (request message) ===
Regel 442: Regel 999:
 
{{MpFhirSendTransaction}}
 
{{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 at least one instance of nl-core-PharmaceuticalProduct are included. All resources included in the Bundle SHALL conform to their respective profiles listed in section 3.1.
+
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 mp-MedicationPrescriptionProcessing-Bundle profile prescribes the use of [[mp:Vprepub-9_2.0.0-beta3_FHIR_MedicationProcess#Actionable_tag|{{term|actionable}}-tags]] to indicate that the resources sent are part of a prescription and of actionable nature.
+
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.
  
 
=== Receive (response message) ===
 
=== Receive (response message) ===
−
The server checks the AdministrationAgreement and MedicationDispense building blocks present within the Bundle it receives for the presence of [[mp:Vprepub-9_2.0.0-beta3_FHIR_MedicationProcess#Actionable_tag|{{term|actionable}}-tags]].
+
The server checks the AdministrationAgreement and MedicationDispense building blocks present within the Bundle it receives for the presence of [[#Actionable_tag|{{term|actionable}} tags]].
  
−
The server returns an HTTP Status code appropriate to the processing outcome. If the transaction is successful, the server returns a Bundle with {{fhir|Bundle.type}}={{term|transaction-response}}, that contains one entry for each entry in the request, in the same order, with the outcome of processing the entry. Included ‘secondary resources’ are handled [[FHIR:Vdraft_FHIR_IG_R4#Referring_other_resources_when_sending_information|following the Nictiz IG]].
+
{{MpFhirReceiveTransaction}}
  
−
If the transaction fails, the server returns an OperationOutcome with one or multiple {{fhir|.issue}} elements filled with information, as detailed as possible, that describes why the transaction failed and which resource and/or request caused this.
+
=== List of profiles ===
 +
 
 +
The table below includes all profiles that are explicitly mentioned in the data set of this transaction, and thus need to be supported.
 +
 
 +
{| class="wikitable"
 +
|-
 +
! style="font-weight: bold;text-align:left;" | Building block/transaction profile (EN)
 +
! style="font-weight: bold;text-align:left;" | Building block/transaction profile (NL)
 +
! style="font-weight: bold;text-align:left;" | FHIR resource
 +
! style="font-weight: bold;text-align:left;" | FHIR profile
 +
|-
 +
| MedicationPrescriptionProcessing
 +
| VoorschriftAfhandeling
 +
| Bundle
 +
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/mp-MedicationPrescriptionProcessing-Bundle|nictiz.fhir.nl.r4.medicationprocess9|pkgVersion=1.0.0}}
 +
|-
 +
| AdministrationAgreement
 +
| Toedieningsafspraak
 +
| MedicationDispense
 +
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/mp-AdministrationAgreement|nictiz.fhir.nl.r4.medicationprocess9|pkgVersion=1.0.0}}
 +
|-
 +
| MedicationDispense
 +
| Medicatieverstrekking
 +
| MedicationDispense
 +
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/mp-MedicationDispense|nictiz.fhir.nl.r4.medicationprocess9|pkgVersion=1.0.0}}
 +
|-
 +
| Patient
 +
| Patient
 +
| Patient
 +
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/nl-core-Patient|nictiz.fhir.nl.r4.nl-core|pkgVersion=0.5.0-beta1}}
 +
|-
 +
| PharmaceuticalProduct
 +
| FarmaceutischProduct
 +
| Medication
 +
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/nl-core-PharmaceuticalProduct|nictiz.fhir.nl.r4.nl-core|pkgVersion=0.5.0-beta1}}
 +
|-
 +
| rowspan="2" | HealthcareProvider
 +
| rowspan="2" | Zorgaanbieder
 +
| Location
 +
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/nl-core-HealthcareProvider|nictiz.fhir.nl.r4.nl-core|pkgVersion=0.5.0-beta1}}
 +
|-
 +
| Organization
 +
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/nl-core-HealthcareProvider-Organization|nictiz.fhir.nl.r4.nl-core|pkgVersion=0.5.0-beta1}}
 +
|}
  
 
== Proposal dispense request (Send/Receive) ==
 
== Proposal dispense request (Send/Receive) ==
−
The send proposal dispense request transaction is used by the client to inform the server about a new or modified proposal dispense request (verstrekkingsverzoek).
+
The send proposal dispense request transaction is used by the client to inform the server about a new or modified proposal dispense request (Dutch: verstrekkingsverzoek).
  
 
{| class="wikitable" "cellpadding="10"
 
{| class="wikitable" "cellpadding="10"
Regel 467: Regel 1.067:
 
|style="background-color: white;vertical-align:top;"|Client  
 
|style="background-color: white;vertical-align:top;"|Client  
 
|style="background-color: white;vertical-align:top;"|MP-VVS
 
|style="background-color: white;vertical-align:top;"|MP-VVS
−
|style="background-color: white;vertical-align:top;"|{{Simplifier|http://nictiz.nl/fhir/CapabilityStatement/MedicationProcess-ClientCapabilities|nictiz.fhir.nl.r4.medicationprocess9|pkgVersion=2.0.0-beta2|title=CapabilityStatement: Client}}
+
|style="background-color: white;vertical-align:top;" rowspan="2"|{{Simplifier|http://nictiz.nl/fhir/CapabilityStatement/mp-ProposalDispenseRequest|nictiz.fhir.nl.r4.medicationprocess9|pkgVersion=1.0.0|title=CapabilityStatement Send/receive proposal dispense request}}
 
|-
 
|-
 
|style="background-color: white;vertical-align:top;"|Receiving proposal dispense request
 
|style="background-color: white;vertical-align:top;"|Receiving proposal dispense request
 
|style="background-color: white;vertical-align:top;"|Server
 
|style="background-color: white;vertical-align:top;"|Server
 
|style="background-color: white;vertical-align:top;"|MP-VVO
 
|style="background-color: white;vertical-align:top;"|MP-VVO
−
|style="background-color: white;vertical-align:top;"|{{Simplifier|http://nictiz.nl/fhir/CapabilityStatement/MedicationProcess-ServerCapabilities|nictiz.fhir.nl.r4.medicationprocess9|pkgVersion=2.0.0-beta2|title=CapabilityStatement: Server}}
 
 
|}
 
|}
−
 
−
The names of the transaction groups and transactions link to the functional definition in an ART-DECOR publication which details per scenario which data elements are expected to be supported.
 
  
 
=== Send (request message) ===
 
=== Send (request message) ===
Regel 482: Regel 1.079:
 
{{MpFhirSendTransaction}}
 
{{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 at least one instance of nl-core-PharmaceuticalProduct are included. All resources included in the Bundle SHALL conform to their respective profiles listed in section 3.1.
+
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 mp-ProposalDispenseRequest-Bundle profile prescribes the use of [[mp:Vprepub-9_2.0.0-beta3_FHIR_MedicationProcess#Actionable_tag|{{term|actionable}}-tags]] to indicate that the resources sent are part of a proposal and of actionable nature.
+
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.
  
 
=== Receive (response message) ===
 
=== Receive (response message) ===
−
The client checks the DispenseRequest building block present within the Bundle it receives for the presence of [[mp:Vprepub-9_2.0.0-beta3_FHIR_MedicationProcess#Actionable_tag|{{term|actionable}}-tags]] and the value of {{fhir|MedicationRequest.intent}}={{term|plan}} to determine the transaction type.
+
The client checks the DispenseRequest building block present within the Bundle it receives for the presence of [[#Actionable_tag|{{term|actionable}} tags]] and the value of {{fhir|MedicationRequest.intent}} = {{term|plan}} to determine the transaction type.
 +
 
 +
{{MpFhirReceiveTransaction}}
 +
 
 +
Aside from the technical processing outcome described above, after functional processing an invocation of the [[#Reply_proposal_dispense_request_.28Send.2FReceive.29|‘Send reply proposal dispense request’ transaction]] is expected.
  
−
The server returns an HTTP Status code appropriate to the processing outcome. If the transaction is successful, the server returns a Bundle with {{fhir|Bundle.type}}={{term|transaction-response}}, that contains one entry for each entry in the request, in the same order, with the outcome of processing the entry. Included ‘secondary resources’ are handled [[FHIR:Vdraft_FHIR_IG_R4#Referring_other_resources_when_sending_information|following the Nictiz IG]].
+
=== List of profiles ===
  
−
If the transaction fails, the server returns an OperationOutcome with one or multiple {{fhir|.issue}} elements filled with information, as detailed as possible, that describes why the transaction failed and which resource and/or request caused this.
+
The table below includes all profiles that are explicitly mentioned in the data set of this transaction, and thus need to be supported.
  
−
Aside from the technical processing outcome described above, after functional processing an invocation of the [[mp:Vprepub-9_2.0.0-beta3_FHIR_MedicationProcess#Reply_proposal_dispense_request_.28Send.2FReceive.29|‘Send reply proposal dispense request’ transaction]] is expected.
+
{| class="wikitable"
 +
|-
 +
! style="font-weight: bold;text-align:left;" | Building block/transaction profile (EN)
 +
! style="font-weight: bold;text-align:left;" | Building block/transaction profile (NL)
 +
! style="font-weight: bold;text-align:left;" | FHIR resource
 +
! style="font-weight: bold;text-align:left;" | FHIR profile
 +
|-
 +
| ProposalDispenseRequest
 +
| VoorstelVerstrekkingsverzoek
 +
| Bundle
 +
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/mp-ProposalDispenseRequest-Bundle|nictiz.fhir.nl.r4.medicationprocess9|pkgVersion=1.0.0}}
 +
|-
 +
| DispenseRequest
 +
| Verstrekkingsverzoek
 +
| MedicationRequest
 +
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/mp-DispenseRequest|nictiz.fhir.nl.r4.medicationprocess9|pkgVersion=1.0.0}}
 +
|-
 +
| Patient
 +
| Patient
 +
| Patient
 +
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/nl-core-Patient|nictiz.fhir.nl.r4.nl-core|pkgVersion=0.5.0-beta1}}
 +
|-
 +
| PharmaceuticalProduct
 +
| FarmaceutischProduct
 +
| Medication
 +
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/nl-core-PharmaceuticalProduct|nictiz.fhir.nl.r4.nl-core|pkgVersion=0.5.0-beta1}}
 +
|-
 +
| rowspan="2" | HealthProfessional
 +
| rowspan="2" | Zorgverlener
 +
| PractitionerRole
 +
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/nl-core-HealthProfessional-PractitionerRole|nictiz.fhir.nl.r4.nl-core|pkgVersion=0.5.0-beta1}}
 +
|-
 +
| Practitioner
 +
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/nl-core-HealthProfessional-Practitioner|nictiz.fhir.nl.r4.nl-core|pkgVersion=0.5.0-beta1}}
 +
|-
 +
| rowspan="2" | HealthcareProvider
 +
| rowspan="2" | Zorgaanbieder
 +
| Location
 +
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/nl-core-HealthcareProvider|nictiz.fhir.nl.r4.nl-core|pkgVersion=0.5.0-beta1}}
 +
|-
 +
| Organization
 +
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/nl-core-HealthcareProvider-Organization|nictiz.fhir.nl.r4.nl-core|pkgVersion=0.5.0-beta1}}
 +
|}
  
 
== Reply proposal dispense request (Send/Receive) ==
 
== Reply proposal dispense request (Send/Receive) ==
−
The send reply proposal dispense request transaction is used by the client to inform the server about a reply on a proposed dispense request.
+
The send reply proposal dispense request transaction is used by the client to inform the server about a reply on a proposed dispense request (Dutch: verstrekkingsverzoek).
  
 
{| class="wikitable" "cellpadding="10"
 
{| class="wikitable" "cellpadding="10"
Regel 509: Regel 1.152:
 
|style="background-color: white;vertical-align:top;"|Client  
 
|style="background-color: white;vertical-align:top;"|Client  
 
|style="background-color: white;vertical-align:top;"|MP-VVO
 
|style="background-color: white;vertical-align:top;"|MP-VVO
−
|style="background-color: white;vertical-align:top;"|{{Simplifier|http://nictiz.nl/fhir/CapabilityStatement/MedicationProcess-ClientCapabilities|nictiz.fhir.nl.r4.medicationprocess9|pkgVersion=2.0.0-beta2|title=CapabilityStatement: Client}}
+
|style="background-color: white;vertical-align:top;" rowspan="2"|{{Simplifier|http://nictiz.nl/fhir/CapabilityStatement/mp-ReplyProposalDispenseRequest|nictiz.fhir.nl.r4.medicationprocess9|pkgVersion=1.0.0|title=CapabilityStatement Send/receive reply proposal dispense request}}
 
|-
 
|-
 
|style="background-color: white;vertical-align:top;"|Receiving reply proposal dispense request
 
|style="background-color: white;vertical-align:top;"|Receiving reply proposal dispense request
 
|style="background-color: white;vertical-align:top;"|Server
 
|style="background-color: white;vertical-align:top;"|Server
 
|style="background-color: white;vertical-align:top;"|MP-VVS
 
|style="background-color: white;vertical-align:top;"|MP-VVS
−
|style="background-color: white;vertical-align:top;"|{{Simplifier|http://nictiz.nl/fhir/CapabilityStatement/MedicationProcess-ServerCapabilities|nictiz.fhir.nl.r4.medicationprocess9|pkgVersion=2.0.0-beta2|title=CapabilityStatement: Server}}
 
 
|}
 
|}
−
 
−
The names of the transaction groups and transactions link to the functional definition in an ART-DECOR publication which details per scenario which data elements are expected to be supported.
 
  
 
=== Send (request message) ===
 
=== Send (request message) ===
Regel 524: Regel 1.164:
 
{{MpFhirSendTransaction}}
 
{{MpFhirSendTransaction}}
  
−
The Bundle SHALL contain one Communication resource that conforms to the mp-ReplyProposalDispenseRequest profile. Additionally, instances of nl-core-Patient, nl-core-DispenseRequest (i.e. the proposed dispense request that is replied to) and other supporting resources might be included. All resources included in the Bundle SHALL conform to their respective profiles listed in section 3.1.
+
The Bundle SHALL conform to the mp-ReplyProposalDispenseRequest-Bundle profile, which contains at least one Communication resource that conforms to the mp-ReplyProposalDispenseRequest profile. Additionally, one instance of nl-core-Patient and other supporting resources might be included. All resources included in the Bundle SHALL conform to their respective profiles listed in the 'List of profiles' below.
 +
 
 +
Note that the proposed dispense request that is replied to is internally resolvable by the server, hence it does not need to be included in the Bundle (and is thus not explicitly modelled in the mp-ReplyProposalDispenseRequest-Bundle profile).
  
−
The mp-ReplyProposalDispenseRequest profile prescribes the use of [[mp:Vprepub-9_2.0.0-beta3_FHIR_MedicationProcess#Actionable_tag|{{term|actionable}}-tags]] to indicate that the resource sent is of actionable nature.
+
The mp-ReplyProposalDispenseRequest profile prescribes the use of [[#Actionable_tag|{{term|actionable}} tags]] to indicate that the resource sent is of actionable nature.
  
 
=== Receive (response message) ===
 
=== Receive (response message) ===
−
The client checks the Communication resource present within the Bundle it receives for the presence of [[mp:Vprepub-9_2.0.0-beta3_FHIR_MedicationProcess#Actionable_tag|{{term|actionable}}-tags]] and the type of building block referenced to determine the transaction type.
+
The client checks the Communication resource present within the Bundle it receives for the presence of [[#Actionable_tag|{{term|actionable}} tags]] and the type of building block referenced to determine the transaction type.
  
−
The server returns an HTTP Status code appropriate to the processing outcome. If the transaction is successful, the server returns a Bundle with {{fhir|Bundle.type}}={{term|transaction-response}}, that contains one entry for each entry in the request, in the same order, with the outcome of processing the entry. Included ‘secondary resources’ are handled [[FHIR:Vdraft_FHIR_IG_R4#Referring_other_resources_when_sending_information|following the Nictiz IG]].
+
{{MpFhirReceiveTransaction}}
  
−
If the transaction fails, the server returns an OperationOutcome with one or multiple {{fhir|.issue}} elements filled with information, as detailed as possible, that describes why the transaction failed and which resource and/or request caused this.
+
Aside from the technical processing outcome described above, after functional processing this transaction might lead to an invocation of the [[#Medication_prescription_.28Send.2FReceive.29|‘Send medication prescription’ transaction]].
  
−
Aside from the technical processing outcome described above, after functional processing this transaction might lead to an invocation of the [[mp:Vprepub-9_2.0.0-beta3_FHIR_MedicationProcess#Medication_prescription_.28Send.2FReceive.29|‘Send medication prescription’]] transaction. 
+
=== List of profiles ===
 +
 
 +
The table below includes all profiles that are explicitly mentioned in the data set of this transaction, and thus need to be supported.
 +
 
 +
{| class="wikitable"
 +
|-
 +
! style="font-weight: bold;text-align:left;" | Building block/transaction profile (EN)
 +
! style="font-weight: bold;text-align:left;" | Building block/transaction profile (NL)
 +
! style="font-weight: bold;text-align:left;" | FHIR resource
 +
! style="font-weight: bold;text-align:left;" | FHIR profile
 +
|-
 +
| rowspan="2" | ReplyProposalDispenseRequest
 +
| rowspan="2" | AntwoordVoorstelVerstrekkingsverzoek
 +
| Bundle
 +
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/mp-ReplyProposalDispenseRequest-Bundle|nictiz.fhir.nl.r4.medicationprocess9|pkgVersion=1.0.0}}
 +
|-
 +
| Communication
 +
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/mp-ReplyProposalDispenseRequest|nictiz.fhir.nl.r4.medicationprocess9|pkgVersion=1.0.0}}
 +
|-
 +
| DispenseRequest
 +
| Verstrekkingsverzoek
 +
| MedicationRequest
 +
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/mp-DispenseRequest|nictiz.fhir.nl.r4.medicationprocess9|pkgVersion=1.0.0}}
 +
|-
 +
| Patient
 +
| Patient
 +
| Patient
 +
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/nl-core-Patient|nictiz.fhir.nl.r4.nl-core|pkgVersion=0.5.0-beta1}}
 +
|-
 +
| rowspan="2" | HealthProfessional
 +
| rowspan="2" | Zorgverlener
 +
| PractitionerRole
 +
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/nl-core-HealthProfessional-PractitionerRole|nictiz.fhir.nl.r4.nl-core|pkgVersion=0.5.0-beta1}}
 +
|-
 +
| Practitioner
 +
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/nl-core-HealthProfessional-Practitioner|nictiz.fhir.nl.r4.nl-core|pkgVersion=0.5.0-beta1}}
 +
|-
 +
| rowspan="2" | HealthcareProvider
 +
| rowspan="2" | Zorgaanbieder
 +
| Location
 +
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/nl-core-HealthcareProvider|nictiz.fhir.nl.r4.nl-core|pkgVersion=0.5.0-beta1}}
 +
|-
 +
| Organization
 +
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/nl-core-HealthcareProvider-Organization|nictiz.fhir.nl.r4.nl-core|pkgVersion=0.5.0-beta1}}
 +
|}
  
 
== Proposal medication agreement (Send/Receive) ==
 
== Proposal medication agreement (Send/Receive) ==
−
The send proposal medication agreement transaction is used by the client to inform the server about a new or modified proposal medication agreement (medicatieafspraak).
+
The send proposal medication agreement transaction is used by the client to inform the server about a new or modified proposal medication agreement (Dutch: medicatieafspraak).
  
 
{| class="wikitable" "cellpadding="10"
 
{| class="wikitable" "cellpadding="10"
Regel 551: Regel 1.237:
 
|style="background-color: white;vertical-align:top;"|Client  
 
|style="background-color: white;vertical-align:top;"|Client  
 
|style="background-color: white;vertical-align:top;"|MP-VMS
 
|style="background-color: white;vertical-align:top;"|MP-VMS
−
|style="background-color: white;vertical-align:top;"|{{Simplifier|http://nictiz.nl/fhir/CapabilityStatement/MedicationProcess-ClientCapabilities|nictiz.fhir.nl.r4.medicationprocess9|pkgVersion=2.0.0-beta2|title=CapabilityStatement: Client}}
+
|style="background-color: white;vertical-align:top;" rowspan="2"|{{Simplifier|http://nictiz.nl/fhir/CapabilityStatement/mp-ProposalMedicationAgreement|nictiz.fhir.nl.r4.medicationprocess9|pkgVersion=1.0.0|title=CapabilityStatement Send/receive proposal medication agreement}}
 
|-
 
|-
 
|style="background-color: white;vertical-align:top;"|Receiving proposal medication agreement
 
|style="background-color: white;vertical-align:top;"|Receiving proposal medication agreement
 
|style="background-color: white;vertical-align:top;"|Server
 
|style="background-color: white;vertical-align:top;"|Server
 
|style="background-color: white;vertical-align:top;"|MP-VMO
 
|style="background-color: white;vertical-align:top;"|MP-VMO
−
|style="background-color: white;vertical-align:top;"|{{Simplifier|http://nictiz.nl/fhir/CapabilityStatement/MedicationProcess-ServerCapabilities|nictiz.fhir.nl.r4.medicationprocess9|pkgVersion=2.0.0-beta2|title=CapabilityStatement: Server}}
 
 
|}
 
|}
−
 
−
The names of the transaction groups and transactions link to the functional definition in an ART-DECOR publication which details per scenario which data elements are expected to be supported.
 
  
 
=== Send (request message) ===
 
=== Send (request message) ===
Regel 566: Regel 1.249:
 
{{MpFhirSendTransaction}}
 
{{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 and at least one instance of nl-core-PharmaceuticalProduct are included, together with optional instances of nl-core-BodyWeight and nl-core-BodyHeight. All resources included in the Bundle SHALL conform to their respective profiles listed in section 3.1.
+
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 mp-ProposalMedicationAgreement-Bundle profile prescribes the use of [[mp:Vprepub-9_2.0.0-beta3_FHIR_MedicationProcess#Actionable_tag|{{term|actionable}}-tags]] to indicate that the resources sent are part of a proposal and of actionable nature.
+
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.
  
 
=== Receive (response message) ===
 
=== Receive (response message) ===
−
The client checks the MedicationAgreement building block present within the Bundle it receives for the presence of [[mp:Vprepub-9_2.0.0-beta3_FHIR_MedicationProcess#Actionable_tag|{{term|actionable}}-tags]] and the value of {{fhir|MedicationRequest.intent}}={{term|plan}} to determine the transaction type.
+
The client checks the MedicationAgreement building block present within the Bundle it receives for the presence of [[#Actionable_tag|{{term|actionable}} tags]] and the value of {{fhir|MedicationRequest.intent}} = {{term|plan}} to determine the transaction type.
  
−
The server returns an HTTP Status code appropriate to the processing outcome. If the transaction is successful, the server returns a Bundle with {{fhir|Bundle.type}}={{term|transaction-response}}, that contains one entry for each entry in the request, in the same order, with the outcome of processing the entry. Included ‘secondary resources’ are handled [[FHIR:Vdraft_FHIR_IG_R4#Referring_other_resources_when_sending_information|following the Nictiz IG]].
+
{{MpFhirReceiveTransaction}}
  
−
If the transaction fails, the server returns an OperationOutcome with one or multiple {{fhir|.issue}} elements filled with information, as detailed as possible, that describes why the transaction failed and which resource and/or request caused this.
+
Aside from the technical processing outcome described above, after functional processing an invocation of the [[#Reply_proposal_medication_agreement_.28Send.2FReceive.29|‘Send reply proposal medication agreement’ transaction]] is expected.
  
−
Aside from the technical processing outcome described above, after functional processing an invocation of the [[mp:Vprepub-9_2.0.0-beta3_FHIR_MedicationProcess#Reply_proposal_medication_agreement_.28Send.2FReceive.29|‘Send reply proposal medication agreement’ transaction]] is expected.
+
=== List of profiles ===
 +
 
 +
The table below includes all profiles that are explicitly mentioned in the data set of this transaction, and thus need to be supported.
 +
 
 +
{| class="wikitable"
 +
|-
 +
! style="font-weight: bold;text-align:left;" | Building block/transaction profile (EN)
 +
! style="font-weight: bold;text-align:left;" | Building block/transaction profile (NL)
 +
! style="font-weight: bold;text-align:left;" | FHIR resource
 +
! style="font-weight: bold;text-align:left;" | FHIR profile
 +
|-
 +
| ProposalMedicationAgreement
 +
| VoorstelMedicatieafspraak
 +
| Bundle
 +
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/mp-ProposalMedicationAgreement-Bundle|nictiz.fhir.nl.r4.medicationprocess9|pkgVersion=1.0.0}}
 +
|-
 +
| MedicationAgreement
 +
| Medicatieafspraak
 +
| MedicationRequest
 +
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/mp-MedicationAgreement|nictiz.fhir.nl.r4.medicationprocess9|pkgVersion=1.0.0}}
 +
|-
 +
| Patient
 +
| Patient
 +
| Patient
 +
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/nl-core-Patient|nictiz.fhir.nl.r4.nl-core|pkgVersion=0.5.0-beta1}}
 +
|-
 +
| PharmaceuticalProduct
 +
| FarmaceutischProduct
 +
| Medication
 +
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/nl-core-PharmaceuticalProduct|nictiz.fhir.nl.r4.nl-core|pkgVersion=0.5.0-beta1}}
 +
|-
 +
| rowspan="2" | HealthProfessional
 +
| rowspan="2" | Zorgverlener
 +
| PractitionerRole
 +
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/nl-core-HealthProfessional-PractitionerRole|nictiz.fhir.nl.r4.nl-core|pkgVersion=0.5.0-beta1}}
 +
|-
 +
| Practitioner
 +
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/nl-core-HealthProfessional-Practitioner|nictiz.fhir.nl.r4.nl-core|pkgVersion=0.5.0-beta1}}
 +
|-
 +
| rowspan="2" | HealthcareProvider
 +
| rowspan="2" | Zorgaanbieder
 +
| Location
 +
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/nl-core-HealthcareProvider|nictiz.fhir.nl.r4.nl-core|pkgVersion=0.5.0-beta1}}
 +
|-
 +
| Organization
 +
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/nl-core-HealthcareProvider-Organization|nictiz.fhir.nl.r4.nl-core|pkgVersion=0.5.0-beta1}}
 +
|-
 +
| BodyHeight
 +
| Lichaamslengte
 +
| Observation
 +
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/nl-core-BodyHeight|nictiz.fhir.nl.r4.nl-core|pkgVersion=0.5.0-beta1}}
 +
|-
 +
| BodyWeight
 +
| Lichaamsgewicht
 +
| Observation
 +
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/nl-core-BodyWeight|nictiz.fhir.nl.r4.nl-core|pkgVersion=0.5.0-beta1}}
 +
|}
  
 
== Reply proposal medication agreement (Send/Receive) ==
 
== Reply proposal medication agreement (Send/Receive) ==
−
The send reply proposal medication agreement transaction is used by the client to inform the server about a reply on a proposed medication agreement.
+
The send reply proposal medication agreement transaction is used by the client to inform the server about a reply on a proposed medication agreement (Dutch: medicatieafspraak).
  
 
{| class="wikitable" "cellpadding="10"
 
{| class="wikitable" "cellpadding="10"
Regel 593: Regel 1.332:
 
|style="background-color: white;vertical-align:top;"|Client  
 
|style="background-color: white;vertical-align:top;"|Client  
 
|style="background-color: white;vertical-align:top;"|MP-VMO
 
|style="background-color: white;vertical-align:top;"|MP-VMO
−
|style="background-color: white;vertical-align:top;"|{{Simplifier|http://nictiz.nl/fhir/CapabilityStatement/MedicationProcess-ClientCapabilities|nictiz.fhir.nl.r4.medicationprocess9|pkgVersion=2.0.0-beta2|title=CapabilityStatement: Client}}
+
|style="background-color: white;vertical-align:top;" rowspan="2"|{{Simplifier|http://nictiz.nl/fhir/CapabilityStatement/mp-ReplyProposalMedicationAgreement|nictiz.fhir.nl.r4.medicationprocess9|pkgVersion=1.0.0|title=CapabilityStatement Send/receive reply proposal medication agreement}}
 
|-
 
|-
 
|style="background-color: white;vertical-align:top;"|Receiving reply proposal medication agreement
 
|style="background-color: white;vertical-align:top;"|Receiving reply proposal medication agreement
 
|style="background-color: white;vertical-align:top;"|Server
 
|style="background-color: white;vertical-align:top;"|Server
 
|style="background-color: white;vertical-align:top;"|MP-VMS
 
|style="background-color: white;vertical-align:top;"|MP-VMS
−
|style="background-color: white;vertical-align:top;"|{{Simplifier|http://nictiz.nl/fhir/CapabilityStatement/MedicationProcess-ServerCapabilities|nictiz.fhir.nl.r4.medicationprocess9|pkgVersion=2.0.0-beta2|title=CapabilityStatement: Server}}
 
 
|}
 
|}
−
 
−
The names of the transaction groups and transactions link to the functional definition in an ART-DECOR publication which details per scenario which data elements are expected to be supported.
 
  
 
=== Send (request message) ===
 
=== Send (request message) ===
Regel 608: Regel 1.344:
 
{{MpFhirSendTransaction}}
 
{{MpFhirSendTransaction}}
  
−
The Bundle SHALL contain one resource that conforms to the mp-ReplyProposalMedicationAgreement profile. Additionally, instances of nl-core-Patient, nl-core-MedicationAgreement (i.e. the proposed medication agreement) and other supporting resources might be included. All resources included in the Bundle SHALL conform to their respective profiles listed in section 3.1.
+
The Bundle SHALL conform to the mp-ReplyProposalMedicationAgreement-Bundle profile, which contains at least one Communication resource that conforms to the mp-ReplyProposalMedicationAgreement profile. Additionally, one instance of nl-core-Patient and other supporting resources might be included. All resources included in the Bundle SHALL conform to their respective profiles listed in the 'List of profiles' below.
  
−
The mp-ReplyProposalMedicationAgreement profile prescribes the use of [[mp:Vprepub-9_2.0.0-beta3_FHIR_MedicationProcess#Actionable_tag|{{term|actionable}}-tags]] to indicate that the resource sent is of actionable nature.
+
Note that the proposed medication agreement that is replied to is internally resolvable by the server, hence it does not need to be included in the Bundle (and is thus not explicitly modelled in the mp-ReplyProposalMedicationAgreement-Bundle profile).
 +
 
 +
The mp-ReplyProposalMedicationAgreement profile prescribes the use of [[#Actionable_tag|{{term|actionable}} tags]] to indicate that the resource sent is of actionable nature.
  
 
=== Receive (response message) ===
 
=== Receive (response message) ===
−
The client checks the Communication resource present within the Bundle it receives for the presence of [[mp:Vprepub-9_2.0.0-beta3_FHIR_MedicationProcess#Actionable_tag|{{term|actionable}}-tags]] and the type of building block referenced to determine the transaction type.
+
The client checks the Communication resource present within the Bundle it receives for the presence of [[#Actionable_tag|{{term|actionable}} tags]] and the type of building block referenced to determine the transaction type.
 +
 
 +
{{MpFhirReceiveTransaction}}
 +
 
 +
Aside from the technical processing outcome described above, after functional processing this transaction might lead to an invocation of the [[#Medication_prescription_.28Send.2FReceive.29|‘Send medication prescription’ transaction]].
  
−
The server returns an HTTP Status code appropriate to the processing outcome. If the transaction is successful, the server returns a Bundle with {{fhir|Bundle.type}}={{term|transaction-response}}, that contains one entry for each entry in the request, in the same order, with the outcome of processing the entry. Included ‘secondary resources’ are handled [[FHIR:Vdraft_FHIR_IG_R4#Referring_other_resources_when_sending_information|following the Nictiz IG]].
+
=== List of profiles ===
  
−
If the transaction fails, the server returns an OperationOutcome with one or multiple {{fhir|.issue}} elements filled with information, as detailed as possible, that describes why the transaction failed and which resource and/or request caused this.
+
The table below includes all profiles that are explicitly mentioned in the data set of this transaction, and thus need to be supported.
  
−
Aside from the technical processing outcome described above, after functional processing this transaction might lead to an invocation of the [[mp:Vprepub-9_2.0.0-beta3_FHIR_MedicationProcess#Medication_prescription_.28Send.2FReceive.29|‘Send medication prescription’]] transaction.
+
{| class="wikitable"
 +
|-
 +
! style="font-weight: bold;text-align:left;" | Building block/transaction profile (EN)
 +
! style="font-weight: bold;text-align:left;" | Building block/transaction profile (NL)
 +
! style="font-weight: bold;text-align:left;" | FHIR resource
 +
! style="font-weight: bold;text-align:left;" | FHIR profile
 +
|-
 +
| rowspan="2" | ReplyProposalMedicationAgreement
 +
| rowspan="2" | AntwoordVoorstelMedicatieafspraak
 +
| Bundle
 +
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/mp-ReplyProposalMedicationAgreement-Bundle|nictiz.fhir.nl.r4.medicationprocess9|pkgVersion=1.0.0}}
 +
|-
 +
| Communication
 +
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/mp-ReplyProposalMedicationAgreement|nictiz.fhir.nl.r4.medicationprocess9|pkgVersion=1.0.0}}
 +
|-
 +
| MedicationAgreement
 +
| Medicatieafspraak
 +
| MedicationRequest
 +
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/mp-MedicationAgreement|nictiz.fhir.nl.r4.medicationprocess9|pkgVersion=1.0.0}}
 +
|-
 +
| Patient
 +
| Patient
 +
| Patient
 +
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/nl-core-Patient|nictiz.fhir.nl.r4.nl-core|pkgVersion=0.5.0-beta1}}
 +
|-
 +
| rowspan="2" | HealthProfessional
 +
| rowspan="2" | Zorgverlener
 +
| PractitionerRole
 +
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/nl-core-HealthProfessional-PractitionerRole|nictiz.fhir.nl.r4.nl-core|pkgVersion=0.5.0-beta1}}
 +
|-
 +
| Practitioner
 +
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/nl-core-HealthProfessional-Practitioner|nictiz.fhir.nl.r4.nl-core|pkgVersion=0.5.0-beta1}}
 +
|-
 +
| rowspan="2" | HealthcareProvider
 +
| rowspan="2" | Zorgaanbieder
 +
| Location
 +
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/nl-core-HealthcareProvider|nictiz.fhir.nl.r4.nl-core|pkgVersion=0.5.0-beta1}}
 +
|-
 +
| Organization
 +
| {{Simplifier|http://nictiz.nl/fhir/StructureDefinition/nl-core-HealthcareProvider-Organization|nictiz.fhir.nl.r4.nl-core|pkgVersion=0.5.0-beta1}}
 +
|}
  
 
=Release notes=
 
=Release notes=
−
Release notes can be found on the [[mp:V9_2.0_Ontwerp_medicatieproces_patient#Release_notes|functional design page]].
+
Release notes can be found [[mp:V2.0.0_releasenotes|here]].
  
 
=Footnotes=
 
=Footnotes=
 
<references/>
 
<references/>

Huidige versie van 4 nov 2022 om 11:17


1 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 this functional specification and further specified here using 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 general FHIR Implementation Guide apply. In particular, the reader should take note of the Overarching principles and the use of 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.

2 Boundaries and relationships

2.1 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.

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 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.

Em.png

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

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

2.1.1 Medication building blocks

As described above, the main medication building blocks have no dependency on any zib2020 counterparts, resulting in so-called ‘mp’ profiles. Moreover, note that the building block VariableDosingRegimen does not have a zib counterpart, hence it makes sense to include it as an mp profile as well.

Building block (EN) Building block (NL) FHIR resource FHIR profile
MedicationAgreement Medicatieafspraak MedicationRequest http://nictiz.nl/fhir/StructureDefinition/mp-MedicationAgreement
VariableDosingRegimen WisselendDoseerschema MedicationRequest http://nictiz.nl/fhir/StructureDefinition/mp-VariableDosingRegimen
DispenseRequest Verstrekkingsverzoek MedicationRequest http://nictiz.nl/fhir/StructureDefinition/mp-DispenseRequest
AdministrationAgreement Toedieningsafspraak MedicationDispense http://nictiz.nl/fhir/StructureDefinition/mp-AdministrationAgreement
MedicationDispense Medicatieverstrekking MedicationDispense http://nictiz.nl/fhir/StructureDefinition/mp-MedicationDispense
MedicationUse2 Medicatiegebruik2 MedicationStatement http://nictiz.nl/fhir/StructureDefinition/mp-MedicationUse2
MedicationAdministration2 Medicatietoediening2 MedicationAdministration http://nictiz.nl/fhir/StructureDefinition/mp-MedicationAdministration2

2.1.2 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 ‘nl-core’ package[1].

Building block (EN) Building block (NL) FHIR resource FHIR profile
Patient Patient Patient http://nictiz.nl/fhir/StructureDefinition/nl-core-Patient
PharmaceuticalProduct FarmaceutischProduct Medication http://nictiz.nl/fhir/StructureDefinition/nl-core-PharmaceuticalProduct
Contact Contactpersoon RelatedPerson http://nictiz.nl/fhir/StructureDefinition/nl-core-ContactPerson
HealthProfessional Zorgverlener PractitionerRole http://nictiz.nl/fhir/StructureDefinition/nl-core-HealthProfessional-PractitionerRole
Practitioner http://nictiz.nl/fhir/StructureDefinition/nl-core-HealthProfessional-Practitioner
HealthcareProvider Zorgaanbieder Location http://nictiz.nl/fhir/StructureDefinition/nl-core-HealthcareProvider
Organization http://nictiz.nl/fhir/StructureDefinition/nl-core-HealthcareProvider-Organization
BodyHeight Lichaamslengte Observation http://nictiz.nl/fhir/StructureDefinition/nl-core-BodyHeight
BodyWeight Lichaamsgewicht Observation http://nictiz.nl/fhir/StructureDefinition/nl-core-BodyWeight

Note the following:

  • Each occurrence of the zib HealthProfessional is normally represented by two FHIR resources: an instance of nl-core-HealthProfessional-PractitionerRole and an instance of nl-core-HealthProfessional-Practitioner. Sending systems should only fill the reference to the PractitionerRole instance where relevant. Receiving systems can resolve the reference to the Practitioner resource from that PractitionerRole instance.
  • The zib HealthcareProvider is mapped to both a Location and Organization profile. Most often, the Location profile acts as the focal resource, because most references to this zib are concerned about the recording of the physical location where the care to patient/client takes place rather than the organizational information. For the latter, the profile on Organization is used which is referenced using the Location.managingOrganization element. Sending systems should only fill the reference to the Location instance where relevant. Incidentally, concepts that are only concerned with organizational information can refer to the Organization instance.

2.1.3 Transaction specific profiles

For several transactions, additional profiles are provided. For each transaction the profile relevant is explicitly mentioned in the corresponding subsection.

Transaction profile (EN) Transaction profile (NL) FHIR resource FHIR profile
MedicationOverview MedicatieOverzicht Bundle http://nictiz.nl/fhir/StructureDefinition/mp-MedicationOverview-Bundle
List http://nictiz.nl/fhir/StructureDefinition/mp-MedicationOverview
MedicationPrescription Voorschrift Bundle http://nictiz.nl/fhir/StructureDefinition/mp-MedicationPrescription-Bundle
MedicationPrescriptionProcessing VoorschriftAfhandeling Bundle http://nictiz.nl/fhir/StructureDefinition/mp-MedicationPrescriptionProcessing-Bundle
ProposalDispenseRequest VoorstelVerstrekkingsverzoek Bundle http://nictiz.nl/fhir/StructureDefinition/mp-ProposalDispenseRequest-Bundle
ReplyProposalDispenseRequest AntwoordVoorstelVerstrekkingsverzoek Bundle http://nictiz.nl/fhir/StructureDefinition/mp-ReplyProposalDispenseRequest-Bundle
Communication http://nictiz.nl/fhir/StructureDefinition/mp-ReplyProposalDispenseRequest
ProposalMedicationAgreement VoorstelMedicatieafspraak Bundle http://nictiz.nl/fhir/StructureDefinition/mp-ProposalMedicationAgreement-Bundle
ReplyProposalMedicationAgreement AntwoordVoorstelMedicatieafspraak Bundle http://nictiz.nl/fhir/StructureDefinition/mp-ReplyProposalMedicationAgreement-Bundle
Communication http://nictiz.nl/fhir/StructureDefinition/mp-ReplyProposalMedicationAgreement

2.2 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.

Because of 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, .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, .requester is expected to be filled with either a Reference to an nl-core-HealthProfessional-PractitionerRole resource or a DataAbsentReason extension, see the 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 .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 .reference) instead of logical references (using .identifier) where possible, see the general FHIR IG on the Reference data type.

2.3 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 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 pharmaceutical-treatment-identifier, see ‘Search parameters’, is used within the ‘Medication data’ transaction to query a server for all building blocks within a specific Pharmaceutical treatment.

2.4 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 chained search parameter for all resource types except Patient, so only the records associated with the authenticated patient are returned.

When patient identification requires the use of search parameters, the following search parameters SHALL be supported:

  • Patient: identifier
  • MedicationRequest: patient
  • MedicationDispense: patient
  • MedicationStatement: patient
  • MedicationAdministration: patient

An example of a request that retrieves all MedicationRequest resources of a patient with a fake BSN of 11122233: 

GET [base]/MedicationRequest?patient.identifier=http://fhir.nl/fhir/NamingSystem/bsn|111222333

All request examples in this document do not include patient identification mechanisms. Requesters are assumed to include these if necessary.

2.5 Resource identification

All profiles used within the MP9 information standard contain .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 the DataAbsentReason extension if a value is missing. Identifiers SHALL contain both a .system and a .value.

Because in HL7v3 (CDA) an identifier can only be composed using OIDs, the .system SHALL be an OID to accommodate compatibility in transformations to and from FHIR. The Netherlands HL7v3 datatype II also defines additional restrictions on the maximum length of both @root and @extension (equivalent to respectively .system and .value in FHIR). For the same compatibility reasons, .system SHALL have a maximum of 128 characters and .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 http://nictiz.nl/fhir/StructureDefinition/ext-CopyIndicator present) they may store. This means that relative literal references may need to be rewritten to absolute ones. This also goes for included secondary resources in transactions.

2.6 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 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 Resource.meta.profile, although present in each building block (see the general FHIR IG on ‘Profile use and declaration’), SHOULD not be used for identification of the building block type and therefore for differentiating between transactions.

2.6.1 Actionable tag

To differentiate between sending or serving building blocks that are either of informative nature or of actionable nature, the actionable tag is used. Tags are Coding elements present in Resource.meta.tag used for workflow management.

Issue icon.png

The following paragraph speaks of .value, where .code is meant. This will be fixed in a next version of this IG, see MP-714.

If applicable, the profiles used by a transaction require the use of .meta.tag with .system = http://terminology.hl7.org/CodeSystem/common-tags and .value = 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.

It is up to systems to determine how and when the transactions using the actionable tag are handled from a functional perspective. Systems may store the resource including the actionable tag or remove it either upon storing or when the request is acted upon. However, systems SHALL make sure the tag is removed when serving or sending the resource as part of an informative transaction.

2.6.2 Summarizing table

Transaction PUSH/PULL Building blocks actionable tag FHIR element value Other
Medication data (Retrieve/Serve) PULL One or more of all building blocks No
Medication data (Send/Receive) PUSH One or more of all building blocks No
Medication overview (Retrieve/Serve) PULL MedicationAgreement, AdministrationAgreement, MedicationUse No Includes MedicationOverview List resource in Bundle
Medication overview (Send/Receive) PUSH MedicationAgreement, AdministrationAgreement, MedicationUse No Includes MedicationOverview List resource in Bundle
Medication prescription (Send/Receive) PUSH MedicationAgreement, DispenseRequest (optional) Yes MedicationRequest.intent = order (for both MedicationAgreement and DispenseRequest building blocks)
Medication prescription processing (Send/Receive) PUSH AdministrationAgreement, MedicationDispense (optional) Yes
Proposal dispense request (Send/Receive) PUSH DispenseRequest Yes MedicationRequest.intent = plan
Reply proposal dispense request (Send/Receive) PUSH Yes Communication resource with reference to DispenseRequest
Proposal medication agreement (Send/Receive) PUSH MedicationAgreement Yes MedicationRequest.intent = plan
Reply proposal medication agreement (Send/Receive) PUSH Yes Communication resource with reference to MedicationAgreement

3 Transactions

This section describes the FHIR implementation of all transactions listed in 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 (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’.

3.1 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.

Transaction group Transaction Actor System role FHIR CapabilityStatement
Medication data (PULL) Retrieving medication data Client MP-MGR CapabilityStatement Retrieve/serve medication data
Serving medication data Server MP-MGB

3.1.1 Retrieve (request message)

When a patient or healthcare professional wants to obtain all medication data or specific parts matching various parameters, they issue a retrieve medication data request message. This message uses the HTTP GET method parameterized query against the server's medication FHIR endpoints. These endpoints can be one of the following:

  • MedicationRequest
  • MedicationDispense
  • MedicationStatement
  • MedicationAdministration

The search interaction is performed by an HTTP GET conform the FHIR search specification, as shown below. This URL is configurable by the client by configuring the search query. Multiple request messages may be needed to retrieve all desired information. 

GET [base]/[type]{?[parameters]}

3.1.1.1 Search parameters

All search parameters listed in the table below SHALL be supported for processing by servers and MAY be supported by clients.

MP9 search parameter Description FHIR search parameter FHIR resource Example
PatientIdentificationNumber Search on patient. patient.identifier [2] MedicationRequest, MedicationDispense, MedicationStatement, MedicationAdministration Retrieves all MedicationRequest resources of a patient with a fake BSN of 11122233. 
GET [base]/MedicationRequest?patient.identifier=http://fhir.nl/fhir/NamingSystem/bsn|111222333
Identification Search on identifier. identifier MedicationRequest, MedicationDispense, MedicationStatement, MedicationAdministration Retrieves a MedicationRequest resource with a specific identifier. 
GET [base]/MedicationRequest?identifier=http://example.nl/fhir/NamingSystem/MedicationRequest|999922448
Identification Search on the pharmaceutical treatment identifier.

Note: retrieval of all medication resources belonging to one pharmaceutical treatment requires to search on all medication resource types.

pharmaceutical-treatment-identifier [3] MedicationRequest, MedicationDispense, MedicationStatement, MedicationAdministration Retrieves all MedicationRequest resources that are part of a pharmaceutical treatment with a specific identifier. 
GET [base]/MedicationRequest?pharmaceutical-treatment-identifier=http://example.nl/fhir/NamingSystem/pharmaceuticaltreatment|1247848
Type Search on type of medication building block. category [3] MedicationRequest Retrieves all MedicationRequest resources that represent the building block MedicationAgreement. 
GET [base]/MedicationRequest?category=http://snomed.info/sct|33633005

Retrieves all MedicationRequest resources that represent the building block DispenseRequest. 

GET [base]/MedicationRequest?category=http://snomed.info/sct|52711000146108

Retrieves all MedicationRequest resources that represent the building block VariableDosingRegimen. 

GET [base]/MedicationRequest?category=http://snomed.info/sct|395067002
MedicationDispense Retrieves all MedicationDispense resources that represent the building block MedicationDispense. 
GET [base]/MedicationDispense?category=http://snomed.info/sct|373784005

Retrieves all MedicationRequest resources that represent the building block AdministrationAgreement. 

GET [base]/MedicationRequest?category=http://snomed.info/sct|422037009
MedicationStatement Retrieves all MedicationStatement resources that represent the building block MedicationUse2. 
GET [base]/MedicationStatement?category=http://snomed.info/sct|422979000
MedicationAdministration Retrieves all MedicationAdministration resources that represent the building block MedicationAdministration2. 
GET [base]/MedicationAdministration?category=http://snomed.info/sct|18629005
MedicationCode Search on medication code. medication.code[4] MedicationRequest, MedicationDispense, MedicationStatement, MedicationAdministration Retrieves all MedicationRequest resources that represent the building block MedicationAgreement and have Carbasalaatcalcium Sandoz 600 30 as medication. 
GET [base]/MedicationRequest?category=http://snomed.info/sct|33633005&medication.code=urn:oid:2.16.840.1.113883.2.4.4.8|13610554
PeriodOfUse Search on medication use in the past, present or future within the specified time period. period-of-use[3] MedicationRequest, MedicationDispense Retrieves all MedicationRequest resources that represent the building block MedicationAgreement and were in effect from 01-01-2010. 
GET [base]/MedicationRequest?category=http://snomed.info/sct|33633005&period-of-use=ge2010-01-01
DispensePeriod Returns all medication dispenses within the specified time period. whenhandedover MedicationDispense Retrieves all MedicationDispense resources that represent the building block MedicationDispense and were handed over within a 2 year period. 
GET [base]/MedicationDispense?category=http://snomed.info/sct|373784005&whenhandedover=ge2010-01-01&whenhandedover=le2011-12-31
AdministrationPeriod Returns all medication administrations within the specified time period. effective-time MedicationAdministration Retrieves all MedicationAdministration resources that represent the building block MedicationAdministration2 and where administration happened on a specific day. 
GET [base]/MedicationAdministration?category=http://snomed.info/sct|18629005&effective-time=eq2022-01-01
- 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 per the Nictiz IG.

_include=[type]:patient

_include=[type]:medication

MedicationRequest, MedicationDispense, MedicationStatement, MedicationAdministration Retrieves all MedicationRequest resources that have Carbasalaatcalcium Sandoz 600 30 as medication and includes the Medication resource in the search results. 
GET [base]/MedicationRequest?medication.code=urn:oid:2.16.840.1.113883.2.4.4.8|13610554&_include=MedicationRequest:medication

The following custom search parameters are defined for this transaction:

3.1.1.2 Retrieve all medication data

To retrieve all known medication data, a client has to execute the following requests to retrieve all known medication data per building block, including referenced Medication resources: 

GET [base]/MedicationRequest?category=http://snomed.info/sct|33633005&_include=MedicationRequest:medication
GET [base]/MedicationRequest?category=http://snomed.info/sct|52711000146108&_include=MedicationRequest:medication
GET [base]/MedicationRequest?category=http://snomed.info/sct|395067002&_include=MedicationRequest:medication
GET [base]/MedicationDispense?category=http://snomed.info/sct|373784005&_include=MedicationDispense:medication
GET [base]/MedicationDispense?category=http://snomed.info/sct|422037009&_include=MedicationDispense:medication
GET [base]/MedicationStatement?category=http://snomed.info/sct|422979000&_include=MedicationStatement:medication
GET [base]/MedicationAdministration?category=http://snomed.info/sct|18629005&_include=MedicationStatement:medication

3.1.2 Serve (response message)

The server returns an HTTP Status code appropriate to the processing outcome and returns a Bundle, with Bundle.type = searchset, including the resources matching the search query medication data. The resources included in the Bundle SHALL conform to the profiles listed in the 'List of profiles' below.

3.1.3 List of profiles

The table below includes all profiles that are explicitly mentioned in the data set of this transaction, and thus need to be supported.

Building block (EN) Building block (NL) FHIR resource FHIR profile
MedicationAgreement Medicatieafspraak MedicationRequest http://nictiz.nl/fhir/StructureDefinition/mp-MedicationAgreement
VariableDosingRegimen WisselendDoseerschema MedicationRequest http://nictiz.nl/fhir/StructureDefinition/mp-VariableDosingRegimen
DispenseRequest Verstrekkingsverzoek MedicationRequest http://nictiz.nl/fhir/StructureDefinition/mp-DispenseRequest
AdministrationAgreement Toedieningsafspraak MedicationDispense http://nictiz.nl/fhir/StructureDefinition/mp-AdministrationAgreement
MedicationDispense Medicatieverstrekking MedicationDispense http://nictiz.nl/fhir/StructureDefinition/mp-MedicationDispense
MedicationUse2 Medicatiegebruik2 MedicationStatement http://nictiz.nl/fhir/StructureDefinition/mp-MedicationUse2
MedicationAdministration2 Medicatietoediening2 MedicationAdministration http://nictiz.nl/fhir/StructureDefinition/mp-MedicationAdministration2
Patient Patient Patient http://nictiz.nl/fhir/StructureDefinition/nl-core-Patient
Contact Contactpersoon RelatedPerson http://nictiz.nl/fhir/StructureDefinition/nl-core-ContactPerson
PharmaceuticalProduct FarmaceutischProduct Medication http://nictiz.nl/fhir/StructureDefinition/nl-core-PharmaceuticalProduct
HealthProfessional Zorgverlener PractitionerRole http://nictiz.nl/fhir/StructureDefinition/nl-core-HealthProfessional-PractitionerRole
Practitioner http://nictiz.nl/fhir/StructureDefinition/nl-core-HealthProfessional-Practitioner
HealthcareProvider Zorgaanbieder Location http://nictiz.nl/fhir/StructureDefinition/nl-core-HealthcareProvider
Organization http://nictiz.nl/fhir/StructureDefinition/nl-core-HealthcareProvider-Organization

3.2 Medication data (Send/Receive)

The send medication data transaction is used by the client to send medication data to a server.

Transaction group Transaction Actor System role FHIR CapabilityStatement
Medication data (PUSH) Sending medication data Client MP-MGS CapabilityStatement Send/receive medication data
Receiving medication data Server MP-MGO

3.2.1 Send (request message)

Because medication data consists of several building blocks along with supporting resources, a transaction interaction is used.

A transaction interaction allows for sending a Bundle with a set of resources in a single interaction and makes it possible to include referenced secondary resources. The interaction is performed by an HTTP POST command as shown: 

POST [base]

The body of the POST submission is a Bundle with Bundle.type = transaction. Each entry carries request details (Bundle.entry.request) that provides the HTTP method of the action to be executed. Usually, this will be POST, even for informative 'secondary' resources.

The resources included in the Bundle SHALL conform to the profiles listed in the 'List of profiles' below. Because of the informative nature of the transaction, no actionable tags shall be present.

3.2.2 Receive (response message)

The server checks each resource present within the Bundle it receives for the absence of actionable tags.

The server returns an HTTP Status code appropriate to the processing outcome. If the transaction is successful, the server returns a Bundle with Bundle.type = transaction-response, that contains one entry for each entry in the request, in the same order, with the outcome of processing the entry. Included ‘secondary resources’ are handled following the Nictiz IG.

If the transaction fails, the server returns an OperationOutcome with one or multiple .issue elements filled with information, as detailed as possible, that describes why the transaction failed and which resource and/or request caused this.

3.2.3 List of profiles

The table below includes all profiles that are explicitly mentioned in the data set of this transaction, and thus need to be supported.

Building block (EN) Building block (NL) FHIR resource FHIR profile
MedicationAgreement Medicatieafspraak MedicationRequest http://nictiz.nl/fhir/StructureDefinition/mp-MedicationAgreement
VariableDosingRegimen WisselendDoseerschema MedicationRequest http://nictiz.nl/fhir/StructureDefinition/mp-VariableDosingRegimen
DispenseRequest Verstrekkingsverzoek MedicationRequest http://nictiz.nl/fhir/StructureDefinition/mp-DispenseRequest
AdministrationAgreement Toedieningsafspraak MedicationDispense http://nictiz.nl/fhir/StructureDefinition/mp-AdministrationAgreement
MedicationDispense Medicatieverstrekking MedicationDispense http://nictiz.nl/fhir/StructureDefinition/mp-MedicationDispense
MedicationUse2 Medicatiegebruik2 MedicationStatement http://nictiz.nl/fhir/StructureDefinition/mp-MedicationUse2
MedicationAdministration2 Medicatietoediening2 MedicationAdministration http://nictiz.nl/fhir/StructureDefinition/mp-MedicationAdministration2
Patient Patient Patient http://nictiz.nl/fhir/StructureDefinition/nl-core-Patient
Contact Contactpersoon RelatedPerson http://nictiz.nl/fhir/StructureDefinition/nl-core-ContactPerson
PharmaceuticalProduct FarmaceutischProduct Medication http://nictiz.nl/fhir/StructureDefinition/nl-core-PharmaceuticalProduct
HealthProfessional Zorgverlener PractitionerRole http://nictiz.nl/fhir/StructureDefinition/nl-core-HealthProfessional-PractitionerRole
Practitioner http://nictiz.nl/fhir/StructureDefinition/nl-core-HealthProfessional-Practitioner
HealthcareProvider Zorgaanbieder Location http://nictiz.nl/fhir/StructureDefinition/nl-core-HealthcareProvider
Organization http://nictiz.nl/fhir/StructureDefinition/nl-core-HealthcareProvider-Organization

3.3 Medication overview (Retrieve/Serve)

The retrieve medication overview transaction is used by the client to retrieve a medication overview from the server.

Transaction group Transaction Actor System role FHIR CapabilityStatement
Medication overview (PULL) Retrieving medication overview Client MP-MOR CapabilityStatement Retrieve/serve medication overview
Serving medication overview Server MP-MOB

3.3.1 Retrieve (request message)

When a patient or healthcare professional wants to obtain a patient's medication overview, they issue a retrieve medication overview request message. This message uses an extended operation on the RESTful API to obtain a medication overview from a server. An operation is needed because the server will formulate the content of the response based on its internal business logic. The medication overview can not easily be described by standardized RESTful requests.

The client executes a medication-overview operation with an HTTP GET command conform the FHIR search specification, as shown below. This URL is configurable by the client by configuring the search query. 

GET [base]/$medication-overview

3.3.2 Serve (response message)

The server returns a HTTP Status code appropriate to the processing of the operation. The successful outcome of the $medication-overview operation is the body of the medication overview response message. Successful processing of this operation should result in a Bundle resource with Bundle.type = 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 section 2.1. The 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 Medication Process specification.

3.3.3 List of profiles

The table below includes all profiles that are explicitly mentioned in the data set of this transaction, and thus need to be supported.

Building block/transaction profile (EN) Building block/transaction profile (NL) FHIR resource FHIR profile
MedicationOverview MedicatieOverzicht Bundle http://nictiz.nl/fhir/StructureDefinition/mp-MedicationOverview-Bundle
List http://nictiz.nl/fhir/StructureDefinition/mp-MedicationOverview
MedicationAgreement Medicatieafspraak MedicationRequest http://nictiz.nl/fhir/StructureDefinition/mp-MedicationAgreement
AdministrationAgreement Toedieningsafspraak MedicationDispense http://nictiz.nl/fhir/StructureDefinition/mp-AdministrationAgreement
MedicationUse2 Medicatiegebruik2 MedicationStatement http://nictiz.nl/fhir/StructureDefinition/mp-MedicationUse2
Patient Patient Patient http://nictiz.nl/fhir/StructureDefinition/nl-core-Patient
Contact Contactpersoon RelatedPerson http://nictiz.nl/fhir/StructureDefinition/nl-core-ContactPerson
PharmaceuticalProduct FarmaceutischProduct Medication http://nictiz.nl/fhir/StructureDefinition/nl-core-PharmaceuticalProduct
HealthProfessional Zorgverlener PractitionerRole http://nictiz.nl/fhir/StructureDefinition/nl-core-HealthProfessional-PractitionerRole
Practitioner http://nictiz.nl/fhir/StructureDefinition/nl-core-HealthProfessional-Practitioner
HealthcareProvider Zorgaanbieder Location http://nictiz.nl/fhir/StructureDefinition/nl-core-HealthcareProvider
Organization http://nictiz.nl/fhir/StructureDefinition/nl-core-HealthcareProvider-Organization
BodyHeight Lichaamslengte Observation http://nictiz.nl/fhir/StructureDefinition/nl-core-BodyHeight
BodyWeight Lichaamsgewicht Observation http://nictiz.nl/fhir/StructureDefinition/nl-core-BodyWeight

3.4 Medication overview (Send/Receive)

The send medication overview transaction is used by the client to send a medication overview to a server.

Transaction group Transaction Actor System role FHIR CapabilityStatement
Medication overview (PUSH) Sending medication overview Client MP-MOS CapabilityStatement Send/receive medication overview
Receiving medication overview Server MP-MOO

3.4.1 Send (request message)

Because a medication overview consists of several building blocks along with supporting resources, a transaction interaction is used.

A transaction interaction allows for sending a Bundle with a set of resources in a single interaction and makes it possible to include referenced secondary resources. The interaction is performed by an HTTP POST command as shown: 

POST [base]

The body of the POST submission is a Bundle with Bundle.type = transaction. Each entry carries request details (Bundle.entry.request) that provides the HTTP method of the action to be executed. Usually, this will be POST, even for informative 'secondary' resources.

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 Medication Process specification.

3.4.2 Receive (response message)

The server returns an HTTP Status code appropriate to the processing outcome. If the transaction is successful, the server returns a Bundle with Bundle.type = transaction-response, that contains one entry for each entry in the request, in the same order, with the outcome of processing the entry. Included ‘secondary resources’ are handled following the Nictiz IG.

If the transaction fails, the server returns an OperationOutcome with one or multiple .issue elements filled with information, as detailed as possible, that describes why the transaction failed and which resource and/or request caused this.

3.4.3 List of profiles

The table below includes all profiles that are explicitly mentioned in the data set of this transaction, and thus need to be supported.

Building block/transaction profile (EN) Building block/transaction profile (NL) FHIR resource FHIR profile
MedicationOverview MedicatieOverzicht Bundle http://nictiz.nl/fhir/StructureDefinition/mp-MedicationOverview-Bundle
List http://nictiz.nl/fhir/StructureDefinition/mp-MedicationOverview
MedicationAgreement Medicatieafspraak MedicationRequest http://nictiz.nl/fhir/StructureDefinition/mp-MedicationAgreement
AdministrationAgreement Toedieningsafspraak MedicationDispense http://nictiz.nl/fhir/StructureDefinition/mp-AdministrationAgreement
MedicationUse2 Medicatiegebruik2 MedicationStatement http://nictiz.nl/fhir/StructureDefinition/mp-MedicationUse2
Patient Patient Patient http://nictiz.nl/fhir/StructureDefinition/nl-core-Patient
Contact Contactpersoon RelatedPerson http://nictiz.nl/fhir/StructureDefinition/nl-core-ContactPerson
PharmaceuticalProduct FarmaceutischProduct Medication http://nictiz.nl/fhir/StructureDefinition/nl-core-PharmaceuticalProduct
HealthProfessional Zorgverlener PractitionerRole http://nictiz.nl/fhir/StructureDefinition/nl-core-HealthProfessional-PractitionerRole
Practitioner http://nictiz.nl/fhir/StructureDefinition/nl-core-HealthProfessional-Practitioner
HealthcareProvider Zorgaanbieder Location http://nictiz.nl/fhir/StructureDefinition/nl-core-HealthcareProvider
Organization http://nictiz.nl/fhir/StructureDefinition/nl-core-HealthcareProvider-Organization
BodyHeight Lichaamslengte Observation http://nictiz.nl/fhir/StructureDefinition/nl-core-BodyHeight
BodyWeight Lichaamsgewicht Observation http://nictiz.nl/fhir/StructureDefinition/nl-core-BodyWeight

3.5 Medication prescription (Send/Receive)

The send medication prescription transaction is used by the client to send a request to dispense medication (Dutch: verstrekkingsverzoek) or process modifications to a medication agreement (Dutch: medicatieafspraak) to a server.

Transaction group Transaction Actor System role FHIR CapabilityStatement
Medication prescription (PUSH) Sending medication prescription Client MP-VOS CapabilityStatement Send/receive medication prescription
Receiving medication prescription Server MP-VOO

3.5.1 Send (request message)

Because a medication prescription consists of several building blocks along with supporting resources, a transaction interaction is used.

A transaction interaction allows for sending a Bundle with a set of resources in a single interaction and makes it possible to include referenced secondary resources. The interaction is performed by an HTTP POST command as shown: 

POST [base]

The body of the POST submission is a Bundle with Bundle.type = transaction. Each entry carries request details (Bundle.entry.request) that provides the HTTP method of the action to be executed. Usually, this will be POST, even for informative 'secondary' resources.

The Bundle SHALL conform to the mp-MedicationPrescription-Bundle profile, which contains at least a MedicationAgreement building block (with MedicationRequest.intent = order) and optionally a DispenseRequest building block (with MedicationRequest.intent = 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 mp-MedicationPrescription-Bundle profile prescribes the use of actionable tags to indicate that the resources sent are part of a prescription and of actionable nature.

3.5.2 Receive (response message)

The server checks the MedicationAgreement and DispenseRequest building blocks present within the Bundle it receives for the presence of actionable tags and the value of MedicationRequest.intent = order to determine the transaction type.

The server returns an HTTP Status code appropriate to the processing outcome. If the transaction is successful, the server returns a Bundle with Bundle.type = transaction-response, that contains one entry for each entry in the request, in the same order, with the outcome of processing the entry. Included ‘secondary resources’ are handled following the Nictiz IG.

If the transaction fails, the server returns an OperationOutcome with one or multiple .issue elements filled with information, as detailed as possible, that describes why the transaction failed and which resource and/or request caused this.

Aside from the technical processing outcome described above, after functional processing an invocation of the ‘Send medication prescription processing’ transaction is expected.

3.5.3 List of profiles

The table below includes all profiles that are explicitly mentioned in the data set of this transaction, and thus need to be supported.

Building block/transaction profile (EN) Building block/transaction profile (NL) FHIR resource FHIR profile
MedicationPrescription Voorschrift Bundle http://nictiz.nl/fhir/StructureDefinition/mp-MedicationPrescription-Bundle
MedicationAgreement Medicatieafspraak MedicationRequest http://nictiz.nl/fhir/StructureDefinition/mp-MedicationAgreement
DispenseRequest Verstrekkingsverzoek MedicationRequest http://nictiz.nl/fhir/StructureDefinition/mp-DispenseRequest
Patient Patient Patient http://nictiz.nl/fhir/StructureDefinition/nl-core-Patient
PharmaceuticalProduct FarmaceutischProduct Medication http://nictiz.nl/fhir/StructureDefinition/nl-core-PharmaceuticalProduct
HealthProfessional Zorgverlener PractitionerRole http://nictiz.nl/fhir/StructureDefinition/nl-core-HealthProfessional-PractitionerRole
Practitioner http://nictiz.nl/fhir/StructureDefinition/nl-core-HealthProfessional-Practitioner
HealthcareProvider Zorgaanbieder Location http://nictiz.nl/fhir/StructureDefinition/nl-core-HealthcareProvider
Organization http://nictiz.nl/fhir/StructureDefinition/nl-core-HealthcareProvider-Organization
BodyHeight Lichaamslengte Observation http://nictiz.nl/fhir/StructureDefinition/nl-core-BodyHeight
BodyWeight Lichaamsgewicht Observation http://nictiz.nl/fhir/StructureDefinition/nl-core-BodyWeight

3.6 Medication prescription processing (Send/Receive)

The send medication prescription processing transaction is used by the client to send data on the processing of a medication agreement (Dutch: medicatieafspraak) and possibly a dispense request (Dutch: verstrekkingsverzoek), in the form of an administration agreement (Dutch: toedieningsafspraak) and optionally a medication dispense (Dutch: medicatieverstrekking).

Transaction group Transaction Actor System role FHIR CapabilityStatement
Medication prescription processing (PUSH) Sending data on processing of medication prescription Client MP-VAS CapabilityStatement Send/receive medication prescription processing
Receiving data on processing of medication prescription Server MP-VAO

3.6.1 Send (request message)

Because data on processing a medication prescription consists of several building blocks along with supporting resources, a transaction interaction is used.

A transaction interaction allows for sending a Bundle with a set of resources in a single interaction and makes it possible to include referenced secondary resources. The interaction is performed by an HTTP POST command as shown: 

POST [base]

The body of the POST submission is a Bundle with Bundle.type = transaction. Each entry carries request details (Bundle.entry.request) that provides the HTTP method of the action to be executed. Usually, this will be POST, even for informative 'secondary' resources.

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 mp-MedicationPrescriptionProcessing-Bundle profile prescribes the use of actionable tags to indicate that the resources sent are part of a prescription and of actionable nature.

3.6.2 Receive (response message)

The server checks the AdministrationAgreement and MedicationDispense building blocks present within the Bundle it receives for the presence of actionable tags.

The server returns an HTTP Status code appropriate to the processing outcome. If the transaction is successful, the server returns a Bundle with Bundle.type = transaction-response, that contains one entry for each entry in the request, in the same order, with the outcome of processing the entry. Included ‘secondary resources’ are handled following the Nictiz IG.

If the transaction fails, the server returns an OperationOutcome with one or multiple .issue elements filled with information, as detailed as possible, that describes why the transaction failed and which resource and/or request caused this.

3.6.3 List of profiles

The table below includes all profiles that are explicitly mentioned in the data set of this transaction, and thus need to be supported.

Building block/transaction profile (EN) Building block/transaction profile (NL) FHIR resource FHIR profile
MedicationPrescriptionProcessing VoorschriftAfhandeling Bundle http://nictiz.nl/fhir/StructureDefinition/mp-MedicationPrescriptionProcessing-Bundle
AdministrationAgreement Toedieningsafspraak MedicationDispense http://nictiz.nl/fhir/StructureDefinition/mp-AdministrationAgreement
MedicationDispense Medicatieverstrekking MedicationDispense http://nictiz.nl/fhir/StructureDefinition/mp-MedicationDispense
Patient Patient Patient http://nictiz.nl/fhir/StructureDefinition/nl-core-Patient
PharmaceuticalProduct FarmaceutischProduct Medication http://nictiz.nl/fhir/StructureDefinition/nl-core-PharmaceuticalProduct
HealthcareProvider Zorgaanbieder Location http://nictiz.nl/fhir/StructureDefinition/nl-core-HealthcareProvider
Organization http://nictiz.nl/fhir/StructureDefinition/nl-core-HealthcareProvider-Organization

3.7 Proposal dispense request (Send/Receive)

The send proposal dispense request transaction is used by the client to inform the server about a new or modified proposal dispense request (Dutch: verstrekkingsverzoek).

Transaction group Transaction Actor System role FHIR CapabilityStatement
Proposal dispense request (PUSH) Sending proposal dispense request Client MP-VVS CapabilityStatement Send/receive proposal dispense request
Receiving proposal dispense request Server MP-VVO

3.7.1 Send (request message)

Because a proposal dispense request consists of a DispenseRequest building block along with supporting resources, a transaction interaction is used.

A transaction interaction allows for sending a Bundle with a set of resources in a single interaction and makes it possible to include referenced secondary resources. The interaction is performed by an HTTP POST command as shown: 

POST [base]

The body of the POST submission is a Bundle with Bundle.type = transaction. Each entry carries request details (Bundle.entry.request) that provides the HTTP method of the action to be executed. Usually, this will be POST, even for informative 'secondary' resources.

The Bundle SHALL conform to the mp-ProposalDispenseRequest-Bundle profile, which contains one DispenseRequest building block (with MedicationRequest.intent = 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 mp-ProposalDispenseRequest-Bundle profile prescribes the use of actionable tags to indicate that the resources sent are part of a proposal and of actionable nature.

3.7.2 Receive (response message)

The client checks the DispenseRequest building block present within the Bundle it receives for the presence of actionable tags and the value of MedicationRequest.intent = plan to determine the transaction type.

The server returns an HTTP Status code appropriate to the processing outcome. If the transaction is successful, the server returns a Bundle with Bundle.type = transaction-response, that contains one entry for each entry in the request, in the same order, with the outcome of processing the entry. Included ‘secondary resources’ are handled following the Nictiz IG.

If the transaction fails, the server returns an OperationOutcome with one or multiple .issue elements filled with information, as detailed as possible, that describes why the transaction failed and which resource and/or request caused this.

Aside from the technical processing outcome described above, after functional processing an invocation of the ‘Send reply proposal dispense request’ transaction is expected.

3.7.3 List of profiles

The table below includes all profiles that are explicitly mentioned in the data set of this transaction, and thus need to be supported.

Building block/transaction profile (EN) Building block/transaction profile (NL) FHIR resource FHIR profile
ProposalDispenseRequest VoorstelVerstrekkingsverzoek Bundle http://nictiz.nl/fhir/StructureDefinition/mp-ProposalDispenseRequest-Bundle
DispenseRequest Verstrekkingsverzoek MedicationRequest http://nictiz.nl/fhir/StructureDefinition/mp-DispenseRequest
Patient Patient Patient http://nictiz.nl/fhir/StructureDefinition/nl-core-Patient
PharmaceuticalProduct FarmaceutischProduct Medication http://nictiz.nl/fhir/StructureDefinition/nl-core-PharmaceuticalProduct
HealthProfessional Zorgverlener PractitionerRole http://nictiz.nl/fhir/StructureDefinition/nl-core-HealthProfessional-PractitionerRole
Practitioner http://nictiz.nl/fhir/StructureDefinition/nl-core-HealthProfessional-Practitioner
HealthcareProvider Zorgaanbieder Location http://nictiz.nl/fhir/StructureDefinition/nl-core-HealthcareProvider
Organization http://nictiz.nl/fhir/StructureDefinition/nl-core-HealthcareProvider-Organization

3.8 Reply proposal dispense request (Send/Receive)

The send reply proposal dispense request transaction is used by the client to inform the server about a reply on a proposed dispense request (Dutch: verstrekkingsverzoek).

Transaction group Transaction Actor System role FHIR CapabilityStatement
Reply proposal dispense request (PUSH) Sending reply proposal dispense request Client MP-VVO CapabilityStatement Send/receive reply proposal dispense request
Receiving reply proposal dispense request Server MP-VVS

3.8.1 Send (request message)

Because a reply proposal dispense request consists of a Communication resource (which contains the reply itself) along with supporting resources, a transaction interaction is used.

A transaction interaction allows for sending a Bundle with a set of resources in a single interaction and makes it possible to include referenced secondary resources. The interaction is performed by an HTTP POST command as shown: 

POST [base]

The body of the POST submission is a Bundle with Bundle.type = transaction. Each entry carries request details (Bundle.entry.request) that provides the HTTP method of the action to be executed. Usually, this will be POST, even for informative 'secondary' resources.

The Bundle SHALL conform to the mp-ReplyProposalDispenseRequest-Bundle profile, which contains at least one Communication resource that conforms to the mp-ReplyProposalDispenseRequest profile. Additionally, one instance of nl-core-Patient and other supporting resources might be included. All resources included in the Bundle SHALL conform to their respective profiles listed in the 'List of profiles' below.

Note that the proposed dispense request that is replied to is internally resolvable by the server, hence it does not need to be included in the Bundle (and is thus not explicitly modelled in the mp-ReplyProposalDispenseRequest-Bundle profile).

The mp-ReplyProposalDispenseRequest profile prescribes the use of actionable tags to indicate that the resource sent is of actionable nature.

3.8.2 Receive (response message)

The client checks the Communication resource present within the Bundle it receives for the presence of actionable tags and the type of building block referenced to determine the transaction type.

The server returns an HTTP Status code appropriate to the processing outcome. If the transaction is successful, the server returns a Bundle with Bundle.type = transaction-response, that contains one entry for each entry in the request, in the same order, with the outcome of processing the entry. Included ‘secondary resources’ are handled following the Nictiz IG.

If the transaction fails, the server returns an OperationOutcome with one or multiple .issue elements filled with information, as detailed as possible, that describes why the transaction failed and which resource and/or request caused this.

Aside from the technical processing outcome described above, after functional processing this transaction might lead to an invocation of the ‘Send medication prescription’ transaction.

3.8.3 List of profiles

The table below includes all profiles that are explicitly mentioned in the data set of this transaction, and thus need to be supported.

Building block/transaction profile (EN) Building block/transaction profile (NL) FHIR resource FHIR profile
ReplyProposalDispenseRequest AntwoordVoorstelVerstrekkingsverzoek Bundle http://nictiz.nl/fhir/StructureDefinition/mp-ReplyProposalDispenseRequest-Bundle
Communication http://nictiz.nl/fhir/StructureDefinition/mp-ReplyProposalDispenseRequest
DispenseRequest Verstrekkingsverzoek MedicationRequest http://nictiz.nl/fhir/StructureDefinition/mp-DispenseRequest
Patient Patient Patient http://nictiz.nl/fhir/StructureDefinition/nl-core-Patient
HealthProfessional Zorgverlener PractitionerRole http://nictiz.nl/fhir/StructureDefinition/nl-core-HealthProfessional-PractitionerRole
Practitioner http://nictiz.nl/fhir/StructureDefinition/nl-core-HealthProfessional-Practitioner
HealthcareProvider Zorgaanbieder Location http://nictiz.nl/fhir/StructureDefinition/nl-core-HealthcareProvider
Organization http://nictiz.nl/fhir/StructureDefinition/nl-core-HealthcareProvider-Organization

3.9 Proposal medication agreement (Send/Receive)

The send proposal medication agreement transaction is used by the client to inform the server about a new or modified proposal medication agreement (Dutch: medicatieafspraak).

Transaction group Transaction Actor System role FHIR CapabilityStatement
Proposal medication agreement (PUSH) Sending proposal medication agreement Client MP-VMS CapabilityStatement Send/receive proposal medication agreement
Receiving proposal medication agreement Server MP-VMO

3.9.1 Send (request message)

Because a proposal medication agreement consists of a MedicationAgreement building block along with supporting resources, a transaction interaction is used.

A transaction interaction allows for sending a Bundle with a set of resources in a single interaction and makes it possible to include referenced secondary resources. The interaction is performed by an HTTP POST command as shown: 

POST [base]

The body of the POST submission is a Bundle with Bundle.type = transaction. Each entry carries request details (Bundle.entry.request) that provides the HTTP method of the action to be executed. Usually, this will be POST, even for informative 'secondary' resources.

The Bundle SHALL conform to the mp-ProposalMedicationAgreement-Bundle profile, which contains at least a MedicationAgreement building block (with MedicationRequest.intent = 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 mp-ProposalMedicationAgreement-Bundle profile prescribes the use of actionable tags to indicate that the resources sent are part of a proposal and of actionable nature.

3.9.2 Receive (response message)

The client checks the MedicationAgreement building block present within the Bundle it receives for the presence of actionable tags and the value of MedicationRequest.intent = plan to determine the transaction type.

The server returns an HTTP Status code appropriate to the processing outcome. If the transaction is successful, the server returns a Bundle with Bundle.type = transaction-response, that contains one entry for each entry in the request, in the same order, with the outcome of processing the entry. Included ‘secondary resources’ are handled following the Nictiz IG.

If the transaction fails, the server returns an OperationOutcome with one or multiple .issue elements filled with information, as detailed as possible, that describes why the transaction failed and which resource and/or request caused this.

Aside from the technical processing outcome described above, after functional processing an invocation of the ‘Send reply proposal medication agreement’ transaction is expected.

3.9.3 List of profiles

The table below includes all profiles that are explicitly mentioned in the data set of this transaction, and thus need to be supported.

Building block/transaction profile (EN) Building block/transaction profile (NL) FHIR resource FHIR profile
ProposalMedicationAgreement VoorstelMedicatieafspraak Bundle http://nictiz.nl/fhir/StructureDefinition/mp-ProposalMedicationAgreement-Bundle
MedicationAgreement Medicatieafspraak MedicationRequest http://nictiz.nl/fhir/StructureDefinition/mp-MedicationAgreement
Patient Patient Patient http://nictiz.nl/fhir/StructureDefinition/nl-core-Patient
PharmaceuticalProduct FarmaceutischProduct Medication http://nictiz.nl/fhir/StructureDefinition/nl-core-PharmaceuticalProduct
HealthProfessional Zorgverlener PractitionerRole http://nictiz.nl/fhir/StructureDefinition/nl-core-HealthProfessional-PractitionerRole
Practitioner http://nictiz.nl/fhir/StructureDefinition/nl-core-HealthProfessional-Practitioner
HealthcareProvider Zorgaanbieder Location http://nictiz.nl/fhir/StructureDefinition/nl-core-HealthcareProvider
Organization http://nictiz.nl/fhir/StructureDefinition/nl-core-HealthcareProvider-Organization
BodyHeight Lichaamslengte Observation http://nictiz.nl/fhir/StructureDefinition/nl-core-BodyHeight
BodyWeight Lichaamsgewicht Observation http://nictiz.nl/fhir/StructureDefinition/nl-core-BodyWeight

3.10 Reply proposal medication agreement (Send/Receive)

The send reply proposal medication agreement transaction is used by the client to inform the server about a reply on a proposed medication agreement (Dutch: medicatieafspraak).

Transaction group Transaction Actor System role FHIR CapabilityStatement
Reply proposal medication agreement (PUSH) Sending reply proposal medication agreement Client MP-VMO CapabilityStatement Send/receive reply proposal medication agreement
Receiving reply proposal medication agreement Server MP-VMS

3.10.1 Send (request message)

Because a reply proposal medication agreement consists of a Communication resource (which contains the reply itself) along with supporting resources, a transaction interaction is used.

A transaction interaction allows for sending a Bundle with a set of resources in a single interaction and makes it possible to include referenced secondary resources. The interaction is performed by an HTTP POST command as shown: 

POST [base]

The body of the POST submission is a Bundle with Bundle.type = transaction. Each entry carries request details (Bundle.entry.request) that provides the HTTP method of the action to be executed. Usually, this will be POST, even for informative 'secondary' resources.

The Bundle SHALL conform to the mp-ReplyProposalMedicationAgreement-Bundle profile, which contains at least one Communication resource that conforms to the mp-ReplyProposalMedicationAgreement profile. Additionally, one instance of nl-core-Patient and other supporting resources might be included. All resources included in the Bundle SHALL conform to their respective profiles listed in the 'List of profiles' below.

Note that the proposed medication agreement that is replied to is internally resolvable by the server, hence it does not need to be included in the Bundle (and is thus not explicitly modelled in the mp-ReplyProposalMedicationAgreement-Bundle profile).

The mp-ReplyProposalMedicationAgreement profile prescribes the use of actionable tags to indicate that the resource sent is of actionable nature.

3.10.2 Receive (response message)

The client checks the Communication resource present within the Bundle it receives for the presence of actionable tags and the type of building block referenced to determine the transaction type.

The server returns an HTTP Status code appropriate to the processing outcome. If the transaction is successful, the server returns a Bundle with Bundle.type = transaction-response, that contains one entry for each entry in the request, in the same order, with the outcome of processing the entry. Included ‘secondary resources’ are handled following the Nictiz IG.

If the transaction fails, the server returns an OperationOutcome with one or multiple .issue elements filled with information, as detailed as possible, that describes why the transaction failed and which resource and/or request caused this.

Aside from the technical processing outcome described above, after functional processing this transaction might lead to an invocation of the ‘Send medication prescription’ transaction.

3.10.3 List of profiles

The table below includes all profiles that are explicitly mentioned in the data set of this transaction, and thus need to be supported.

Building block/transaction profile (EN) Building block/transaction profile (NL) FHIR resource FHIR profile
ReplyProposalMedicationAgreement AntwoordVoorstelMedicatieafspraak Bundle http://nictiz.nl/fhir/StructureDefinition/mp-ReplyProposalMedicationAgreement-Bundle
Communication http://nictiz.nl/fhir/StructureDefinition/mp-ReplyProposalMedicationAgreement
MedicationAgreement Medicatieafspraak MedicationRequest http://nictiz.nl/fhir/StructureDefinition/mp-MedicationAgreement
Patient Patient Patient http://nictiz.nl/fhir/StructureDefinition/nl-core-Patient
HealthProfessional Zorgverlener PractitionerRole http://nictiz.nl/fhir/StructureDefinition/nl-core-HealthProfessional-PractitionerRole
Practitioner http://nictiz.nl/fhir/StructureDefinition/nl-core-HealthProfessional-Practitioner
HealthcareProvider Zorgaanbieder Location http://nictiz.nl/fhir/StructureDefinition/nl-core-HealthcareProvider
Organization http://nictiz.nl/fhir/StructureDefinition/nl-core-HealthcareProvider-Organization

4 Release notes

Release notes can be found here.

5 Footnotes

  1. ↑ 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
  2. ↑ This search parameter only needs to be supported when patient identification requires the use of search parameters, see section 2.4.
  3. ↑ 3,0 3,1 3,2 The search parameter consists of a custom FHIR search parameter not represented in the FHIR specification. Note that for MedicationRequest.category and MedicationStatement.category a core search parameter is available, hence no custom one is needed in those cases.
  4. ↑ Chained search parameter: searches the medicationReference required in each building block for its .code.
Overgenomen van "https://informatiestandaarden.test-nictiz.nl/index.php?title=mp:V2.0.0_MedicationProcess9_FHIR&oldid=142482"