Functional Design Medication Process 9 version 3.0.0-rc.2 English version

This page is currently under construction.

Klik hier voor de Nederlandse live-versie

1 Introduction

This document is part of the Medication Process Information Standard (MP9), developed within the Medication Transfer Programme. During the Kickstart the working method described in the information standard is tested and, if necessary, adjusted.

1.1 General information

This document describes the functional design (FD) of the Medication Process Information Standard . It describes the recording and exchange of medication data and illustrates this with specific practical examples. This is explained using the concepts of actors (people and information systems) and transactions (what information is exchanged, when, and how).
For more information about information standards and how they are developed, see the Nictiz webpage for Information standards . The Glossary overview on the Nictiz website and the Glossary on the Medication Transfer programme website explain the terms used in this FD.

Links to the Step 0 documentation can be found here.

1.2 Target audience

The target audience for this document consists of:

• Product managers, architects, designers, builders and testers of:

- suppliers of medication-related information systems.

- healthcare organisations and regional organisations.

- Nictiz.

• Representatives of health professionals and patients.

1.3 Frameworks and principles

1.3.1 Legislation

The transfer of medication data as described in this document complies with legislation and regulations. Sending a medication agreement combined with a dispense request corresponds to a prescription as defined in the Medicines Act. Further explanation can be found in NEN 7503:2022 Data exchange in healthcare. The Guideline on the Transfer of Medication Data in the Chain also contains an explanation of the legal requirements for the exchange of medication data.

1.3.2 Guideline and process

In 2020, the revised quality standard Guideline on the Transfer of Medication Data in the Chain was published by the Dutch Healthcare Institute. The objective is described as follows:
‘The transfer of medication data within the patient's network, so that prescribers, pharmacists, and administrators can provide continuity of care and make responsible risk assessments for safe medical and pharmaceutical care at the time of prescribing, dispensing, and administering within the chain.’

The accompanying Information section provides a general description of the recording and exchange of medication data. The information standard elaborates on this in detail. The medication process broadly consists of the following sub-processes:

• Prescribe
• Dispense
• Administer
• Use

The medication verification sub-process is also important in this regard. Chapter 5, Medication Process, describes the care process.

1.3.3 Scope of the information standard

The scope of the information standard covers the functional descriptions (this FD) and the dataset for all data exchanges within all sub-processes in the medication process (in ART-DECOR).

1.4 Qualification

A qualification script is drawn up based on this FD and the accompanying dataset. Drawing up qualification scripts falls outside the scope of this FD. For more information, see the Nictiz page on Qualification and the landing page of the Kickstart.

1.5 Reading guide

1.5.1 Use cases and scenarios in this FD

Within Nictiz, information standards are generally described on the basis of use cases. In these information standards, a use case is defined as a description of a practical situation in healthcare that is linked to a scenario. A scenario is a coherent group of transactions for the exchange of data.
The FD for MP9 deals with the healthcare-wide exchange of medication data between a large number of different parties involved and in a variety of healthcare situations. Within MP9, therefore, different use cases with associated scenarios may occur in a single sub-process. A scenario may also apply to more than one sub-process. Furthermore, MP9 pays a lot of attention to the recording of data, in addition to its exchange.
A different structure has therefore been chosen for MP9:

• Chapter 3 Information transfer provides an overview of the scenarios with their transactions, and the system roles required for this. It indicates in which sub-processes these occur.
• The description of the care process is provided in Chapter 5 Medication process. For each sub-process, it indicates which system roles are required.

1.5.2 Chapter overview

Chapter 1 Introduction provides general information about the FD of MP9.
Chapter 2 Conceptual model describes the underlying conceptual model on which MP9 is based: the reason for developing this model, principles, definitions and working method.
Chapter 3 Information exchange provides an overview of the relevant information systems, system roles, scenarios and transactions, and the building blocks involved.
Chapter 4 Consolidation: what, why and how describes what consolidation is and what the associated rules are for MP9.
Chapter 5 Medication Process describes the broad outline of the process, the sub-processes involved and how medication data is used, recorded and exchanged within it.
Chapter 6 Additional Information contains text that has not been included elsewhere, and references to relevant documentation outside this FD.

1.5.3 Examples on separate pages

Due to the length of this FD, the practical examples have been moved to pages outside this main page. There is a page with all examples and separate pages with examples per sub-process or sub-topic.
In addition, there are several other pages with further explanations in the form of examples.

1.5.4 Functionalities in beta version

In the previous publication of the FD and the dataset, some functionalities were incorrectly given the version designation 'release candidate 1'. This concerns the proposal data (see section 5.6) and the functionalities in the Administer sub-process (see section 5.4).
In this publication of the FD and the dataset, these functionalities are therefore published as beta versions, as they still need to be tested. This is in accordance with Nictiz's Sustainable Release Policy.

1.5.5 Writing conventions

The following writing conventions are followed in this FD:

• The medication building blocks are written as abbreviations. Only when they are first introduced and in section titles are the full names written out. The aim is to make the text shorter and more readable, especially in the case of long names such as ’variable dosing regimen’ or ’reply proposal dispense request’.
• Data elements of the building blocks and values from value lists are written as they appear in the dataset in ART-DECOR, including capital letters. This ensures that it is always clear what is meant.
• In this FD, the term ’patient’ is used to refer to both patients and clients.
• In this FD, the term ’supplier’ is used. A supplier is a pharmacist or dispensing general practitioner who carries out the dispensing process or under whose responsibility it takes place.

1.5.6 Repeated text blocks

Various pieces of text may appear in multiple places in the FD. This concerns information that is relevant in different paragraphs. This is particularly the case in Chapter 5. Examples include:

• Instructions for completing a data element that appears in both the MA and the TA.
• Texts about GDS that appear in various paragraphs of Chapter 5 are summarised in a separate section 5.8.

In such cases, the text is copied from the first paragraph in which it appears. This ensures that any changes are made in the same way in every instance.

2 Conceptual model

This chapter explains the model that forms the basis of MP9.
Section 2.1 discusses the reasons for developing this model.
Section 2.2 explains the basic principles.
Section 2.3 describes the medication building blocks and the proposal data.
Section 2.4 introduces the concept of ‘pharmaceutical treatment’ and its functional application.
Section 2.5 explains the interrelationships between building blocks and medication treatment.
Section 2.6 describes how these building blocks can be exchanged.

2.1 Reasons for developing the conceptual model

Registration and communication of medication data are largely done digitally. Over time, various problems have come to light. This was investigated in a project by the NHG and KNMP in 2012-2013. The conclusion was that therapeutic and logistical aspects are intertwined in the recording and communication of medication data. In addition, there is a lack of a clear and shared conceptual framework.

The above has been elaborated in a report, Building blocks for the medication process from 2014. This report describes a conceptual model in which therapeutic and logistical data are separated. This model forms the basis for the MP9 information standard. The texts in this chapter are partly based on this report.

2.2 Principles of the conceptual model

The conceptual model was developed using the sub-processes in the medication process as a starting point:

• prescribe
• dispense
• administer
• use

During these sub-processes, information is generated that is recorded in the form of medication building blocks. A building block in an information standard is a collection of related data elements surrounding a specific concept within a specific context, for example a medication agreement in the medication process. These data elements describe the data required for a clear and unambiguous representation of this concept.
The various medication building blocks represent steps in the patient’s medication process: prescribing a medicine (medication agreement, dispense request, variable dosing regimen), followed by dispensing (administration agreement, medication dispense), administering (medication administration) and using (medication use) that medicine.
During a sub-process, the data elements of the relevant building block are filled in as far as possible and relevant. This results in a concrete instance of that building block.
Instances of building blocks can be exchanged digitally: either by actively sending them to another health professional, or by making them available for consultation by another health professional and the patient, at any given moment (see section 2.6). This allows a health professional to access all of a patient's medication data at any time, as intended in the quality standard Guideline on the Transfer of Medication Data in the Chain.
A full explanation of the conceptual model can be found in the original report Building blocks for the medication process.

2.3 Medication building blocks and proposal data

This section describes the medication building blocks and proposal data. After the initial introduction, the Dutch abbreviations for the building blocks are used throughout, except in section titles.

2.3.1 Therapeutic and logistical building blocks

Within the medication building blocks, a distinction is made between therapy and logistics:

Therapy
This concerns the medical aspects. It includes, among other things, the medication (treatment) agreements and their implementation. The therapeutic intention, the (actual) use and self-medication also fall under this category.
The therapeutic building blocks are: medication agreement (MA), administration agreement (TA), variable dosing regimen (WDS), medication administration (MTD) and medication use (MGB).

Logistics
This concerns aspects relating to the physical flow of medicines, such as requests and deliveries.
The logistical building blocks are: dispense request (VV) and medication dispense (MVE).

Figure 2.1 shows the medication building blocks, divided into sub-processes and distinguishing between therapy and logistics.

Figure 2.1 Overview of therapeutic and logistical medication building blocks

The table below provides a description of these building blocks.

Building block	Abbr.	Description
medicatieafspraak medication agreement	MA	A medication agreement is an agreement between the prescriber and the patient regarding the use of medication by that patient. An agreement to discontinue or modify medication use is also a medication agreement.
wisselend doseerschema variable dosing regimen	WDS	The variable dosing regimen provides concrete details for the instructions for use section of a medication agreement. The dosing regimen can be modified in the interim without having to change the medication agreement.
verstrekkingsverzoek dispense request	VV	A dispense request is the prescriber's request to the supplier to dispense medication to the patient in line with the corresponding medication agreements.
toedieningsafspraak administration agreement	TA	An administration agreement contains the instructions for medication use from the supplier to the patient, their representative or administrator. With an administration agreement, the medication agreement is specified in concrete terms.
medicatieverstrekking medication dispense	MVE	A medication dispense is the provision of a supply of a medicine to the patient, their representative or administrator.
medicatietoediening medication administration	MTD	A medication administration is the separate administration of a medicine to the patient by the administrator.
medicatiegebruik medication use	MGB	medication use is a statement about the historical, current or intended use of a medicine by the patient. The statement can be recorded by the patient themselves, but also by a health professional or a representative of the patient.

2.3.2 Proposal data

A health professional or patient may wish to submit a proposal for a new MA or VV. Proposal data have been introduced to support this. In this FD and the dataset, the proposal data are published as a beta version (see section 1.5.4).

The table below provides a description of these proposal data.

Building block	Abbr.	Description
voorstel medicatieafspraak proposal medication agreement	VMA	The proposal medication agreement is a proposal made by a health professional or the patient to the prescriber regarding the prescription of medication. The proposal may involve stopping, starting, changing or continuing medication.
antwoord voorstel medicatieafspraak reply proposal medication agreement	AVMA	The reply proposal medication agreement is a response from the prescriber to the proposal medication agreement. In this response, the prescriber indicates whether they agree (after which an (adjusted) medication agreement will follow) or disagree (and the reason for this).
voorstel verstrekkingsverzoek proposal dispense request	VVV	The proposal dispense request is a proposal from a health professional or the patient to the prescriber to approve the dispensing of medication for the corresponding medication agreement.
antwoord voorstel verstrekkingsverzoek reply proposal dispense request	AVVV	The reply proposal dispense request is a response from the prescriber to the proposal dispense request. In this response, the prescriber indicates whether they agree (after which a dispensing request will follow) or disagree (and the reason for this).

A proposal may result in a new MA or VV. An AVMA or AVVV is always sent to the proposer.
A proposal is only intended for the prescriber to whom the proposal is addressed, not for the rest of the chain. They are therefore not building blocks (as in section 2.3.1) with which an overview of medication can be constructed, even though they are included in the dataset in ART-DECOR. They therefore do not fall under an MBH (see section 2.4).
Section 5.6 explains the use of the proposal data in more detail.

2.3.3 Medication building blocks and Health and Care Information Models

Health and Care Information Models (Dutch: zorginformatiebouwstenen or zibs) are conceptual models. Every information standard uses these as building blocks. However, zibs are context-independent and it may be necessary to add additional information to information standards in order to clarify that context. As a result, there are some differences between the medication building blocks in this FD and the medication zibs. For more information about zibs, see zibs.nl.

2.4 The concept of ‘pharmaceutical treatment’

This section introduces the concept of ‘pharmaceutical treatment’ (Dutch: medicamenteuze behandeling or MBH) and its functional application.

2.4.1 Pharmaceutical treatment as a technical concept

There may be several medication building blocks that relate to the same treatment. The concept of ‘pharmaceutical treatment’ has been introduced to indicate that these building blocks belong together. This concerns a technical concept. An MBH has no meaning in terms of care content. It takes the form of a unique identification number (id) that is linked by an information system to a building block or collection of related building blocks. The term ’pharmaceutical treatment’ is abbreviated as MBH.

The MBH makes the following possible:

1. The unambiguous identification of the collection of related medication building blocks.
2. The application of rules to a collection of building blocks, in order to unambiguously determine the current situation of a patient with regard to their treatment with a particular medicine (see Chapter 4).

2.4.2 Starting a new pharmaceutical treatment

Starting a pharmaceutical treatment involves recording an initial building block. This initiates a new MBH. The initial building block will usually be an MA, but it could also be a TA or MGB that is used to record self-care medication, or an MTD if medication needs to be administered immediately in an acute situation.
When recording a new building block, it must first be checked whether it concerns new medication, or whether a building block with the same product already exists. This may exist in one’s own information system, but also in information systems elsewhere.
A thorough check therefore requires consulting all available building blocks (for an explanation of consulting, see section 2.6 and Chapter 3). These building blocks are then checked:

• If there is no existing building block for this medicine, a new MBH is created.
• If a building block exists for the same medicine, the new building block will usually fall under the same MBH. However, the health professional must have the option of choosing to start a new MBH.
  

Figure 2.2 shows a flow chart for determining whether a new building block should be recorded in a new or existing MBH.

Figure 2.2 Flow chart recording new building block in new or existing MBH

When is medication considered to be ‘the same medicine’ or ‘the same treatment’?
When recording an MA, the PRK (Prescription Characteristics from the G-Standard) of a medicine determines whether this MA belongs to a new or existing MBH. A different PRK leads to a different MBH. An explanation of which characteristics are important at this level can be found on the webpage Z-Index Backbone.
NB: The fact that a change in PRK leads to a new MBH only applies to the MA. A supplier could choose a medicine with a different PRK, for example because of a preference policy. The associated TA and MVE will have the same MBH as the MA.
The other building blocks follow the MA or TA to which they refer.

The following applies to products without a PRK:

• Non-medicinal products. These are items such as crutches or bandages. In these cases, the HPK level (Trade Product Characteristics from the G-standard) determines whether it is a new product and therefore a new MBH.
• Medicines. These may include:

• Magistral preparations. These usually consist of several substances that do not fall under the same PRK. These substances are included separately as ingredients in the MA. Each individual magistral preparation or modification* thereof falls under a new MBH.
• Own items without PRK. These are items that may be stored in the internal information system under a 90 million number, for example half tablets or frequently used magistral preparations. Each individual item or modification* thereof falls under a new MBH.
• Medicines prescribed in free text and for which no product or ingredient code from the G-Standard is available. Each modification* to the product falls under a new MBH.
• Infusions. A provisional working method has been developed for Kickstart; see the page Infusion working method.
  

For these products too, the rules only apply when recording an MA, not for TAs and MVEs. If and insofar as the supplier is permitted to deviate from the medication described in the MA, this does not lead to a new MBH.

*In principle, 'modification' means: Modifications that would lead to a different PRK for products with PRK and thus would fall under a new MBH, also lead to an adjustment of the MBH for these products. This rule is primarily intended to ensure consistency. Where this leads to implementation problems, a workable solution must be sought in consultation between users and suppliers.

Examples

• Diazepam 5 mg 4x daily 1 tablet is changed to diazepam 5 mg 3x daily 1 tablet. The PRK remains the same, so both MAs fall under the same MBH.
• Paroxetine tablet 10 mg once daily 1 tablet is changed to paroxetine tablet 20 mg once daily 1 tablet. The corresponding MAs relate to different medicines at PRK level and therefore fall under different MBHs.
• As a precaution, a stomach protector has been agreed upon for treatment with prednisone. Although these are prescribed in parallel, they are different medicines. They are therefore not covered by the same MBH and can be changed and discontinued separately.
• Switching from a beta blocker to an ACE inhibitor means a change in PRK. The corresponding MAs fall under different MBHs.

2.4.2.1 Parallel pharmaceutical treatments for the same medication

As described above, when recording a new building block, it must be checked whether an MBH already exists for this medication. However, there may still be situations where parallel MBHs exist for the same medication.
Examples include:

• The patient has not given permission for their medication data to be made available.
• During migration and in hybrid situations, building blocks for the same treatment may be recorded in different information systems under different MBHs.
• Emergency situations in which the MA is recorded in the MBH opened by the MTD, after the administration of medication. If an MA already existed for that medication, there are now two MBHs with building blocks for that medication.
  

Merging of related building blocks that are recorded under different MBHs is described in the Implementation Guide Migration and Hybrid.

2.4.3 Stopping and modifying medication within a pharmaceutical treatment

Once a building block has been completed and exchanged, it cannot be modified. If modifications are necessary, they are made as follows:

Stopping

• To discontinue medication, the associated agreements (MA, TA) must be stopped by recording a stop-building block within the same MBH. This is a new MA or TA with stop type ’stopped’.
• Canceling is stopping an agreement (MA, TA) with a future startDateTime, so that the medication will not be used at all. This is done by recording a cancelation-building block within the same MBH. This is a new MA or TA with stop type ’canceled’. This makes it clear that the medication was never started, in contrast with discontinuing.
• Permanently stopping a WDS must be done by a stop-MA.
  

Modifying

• Modifying an agreement (MA, TA, WDS) is done within the same MBH by:

1. Recording a new agreement with the modified information AND
2. Stopping the existing agreement with a stop-building block with stop type ’stopped’.

The data element stop type is only filled in for stop-building blocks, i.e. only in case of stopping (including canceling) or modifying medication.
This method with stop-building blocks only applies to the agreement building blocks MA, TA and WDS. It does not apply to the other building blocks. MGB also has a stop type, but it has a different function. It indicates the period during which the patient did not use the medication, see section 5.5.2.
Chapter 5 provides a more detailed explanation of how to record (stop-) building blocks for each sub-process.

2.4.3.1 Regular and ‘technical’ building blocks

When permanently discontinuing a building block, the health professional will actively do so by entering the necessary information in a stop-building block.
In addition to regular stop-building blocks, there are also ‘technical’ stop-building blocks. These apply when medication is modified. In addition to recording a new building block with the modified information, the original building block must also be stopped. In this case, the health professional does not need to record a stop-building block themselves. It is created automatically by the system.
These stop-building blocks for modifying medication are referred to in this FD as technical stops, for example ‘technical stop-MA’.
The building block that is to be changed is stopped at the startDateTime of the new building block. In practice, the endDateTime of the technical stop building block may be slightly earlier (e.g. 1 second), so that information systems can process this more effectively.

2.4.4 Rules for parallel building blocks in an MBH

Within an MBH, several building blocks of the same type may be active at the same time, for example a current and a future MA. In principle, however, parallel building blocks are not permitted within a single MBH. Parallel building blocks are building blocks that:

• are of the same type and
• are both valid and
• have a (partially) overlapping PeriodOfUse.

In this FD, the word active refers to both current and future building blocks. Section 4.4 provides further explanation of the terms active, current and future, as well as the term valid.

In some cases, parallel building blocks are permitted within an MBH. This is elaborated in the rules below for each type of building block.

• Parallel MAs are not permitted within the same MBH. Complex build-up and phase-out schedules must also be recorded in a single MA.
• Parallel WDSs are not permitted within the same MBH.
• Parallel TAs are permitted within the same MBH. This may be necessary in order to fully implement the medication agreement.
• Parallel MGBs are permitted within the same MBH, but only with parallel TAs. This enables correct medication verification, so that, for example, the medication use associated with one TA can be assessed as ’in accordance with the agreement’, while the medication use associated with another TA in the same MBH is registered as deviating. In all other cases, parallel MGBs are not permitted.
  

In certain situations, parallel MAs may arise or threaten to arise. Example:

• When recording a new MA, it was not noticed that an MBH already exists for this medication.

If at any time it appears that there are parallel MAs, one of them must be discontinued.

2.5 Interrelationships pharmaceutical treatment and medication building blocks

An MBH may contain various building blocks. The interrelationships between the building blocks within an MBH is explained below, along with their numerical ratios, i.e. how often one building block may occur in relation to another building block within a single MBH. This concerns instances of the building blocks.

2.5.1 Interrelationships MBH - building blocks

The following applies to the interrelationships between an MBH and the building blocks (based on the MBH):

Pharmaceutical treatment → other building blocks
In principle, an MBH has at least one MA.	There may be exceptions; some examples are: • Self-care medication has only been recorded with building block MGB. • Medication has been administered immediately in an acute situation and an MTD has been recorded. • It has been agreed that the supplier may always provide stomach protection with an NSAID or prednisone. In such cases, there is an MBH without MA.
There may be 0 to more MAs active within an MBH: 0 or 1 current MA, and 0 or more future MAs. See section 4.4.1 for an explanation of the terms active, current, and future.
An MBH can have 0 or more of the building blocks VV, WDS, TA, MVE, MGB and MTD. An MBH always contains at least 1 building block.

2.5.2 Interrelationships between building blocks

The table below shows the numerical ratios between the building blocks, starting with the MA. For each building block, the number of instances of another building block that can occur within the same MBH is indicated. Where necessary, statements are accompanied by examples.
When the word ‘refer’ is used, it refers to a Relationship field as it appears in the dataset in ART-DECOR. If such a relationship does not exist, but a statement is made about the numerical ratios between the building blocks, this is marked with an asterisk (*).

Some general rules about referencing:

• A building block can reference a previously defined building block of the same type. This reference is not mandatory.
• Stop building blocks must contain a reference to the building block to be stopped, provided that it is present in the MBH.
• A normal building block never refers to a technical stop building block. Only a stop building block can refer to a technical stop.

Medication agreement → other building blocks
An MA may be succeeded by a new MA.	Examples: • Modifying existing medication. • Discontinuing existing medication. The new MA and any stop-MA then refer to the original MA.
An MA may be accompanied by 0, 1, or more WDSs.
An MA may be accompanied by 0, 1, or more VVs.	Examples: 0 • The patient still has sufficient supplies • It concerns self-care medication. 1 Prescribing a course of antibiotics. >1 Repeat medication associated with long-term MA.
An MA may be accompanied by 0, 1, or more TAs.	Examples: 0 • A new MA where no medication needs to be dispensed because the patient still has sufficient stock from a previous treatment. • This concerns an MA for medication that does not require a legal prescription and that is obtained by the patient themselves from a chemist. 1 The most common situation, where a TA follows an MA. >1 The supplier changes the commercial product or starts supplying the medication via GDS (Medicine Distribution System).
An MA may refer to a previously recorded TA.	Example: • A TA has been created for the dispensing of self-care medication. The prescriber decides to make this policy and creates an MA in the MBH of the TA.
An MA may refer to a previously recorded MGB.	Example: • The patient has created an MGB for self-care medication. The prescriber decides to make this policy and creates an MA in the MBH of the MGB.
Variable dosing regimen → other building blocks
A WDS refers to an MA.
A WDS may refer to a previously recorded WDS.	Example: • Modification of the variable dosing regimen.
Dispense request → other building blocks
A VV refers to 1 or more MAs.	Example: • In the event of an interim dosage increase, a VV can be recorded which, on the one hand, supplements the stock for the existing MA and, on the other hand, serves to start the stock for the future MA. Exception: In the transactions Making medication data available and Sending medication data, it is possible for a VV to exist without reference to an MA. This is only possible in the case of system migration, and sometimes in hybrid situations.
A VV may be accompanied by 0, 1, or more MVEs.	Examples: • 0 : The patient does not collect the medication. • 1: This concerns a course of antibiotics. • >1: GDS with VV for 3 months, dispensed weekly.
Administration agreement → other building blocks
A TA may be succeeded by a new TA.	Examples: • Modification of the existing MA. • Supplying a product with a different PRK or HPK due to preference policy or stock shortage. • Change in administration times or distribution form.
Multiple (possibly parallel) TAs may refer to the same MA.	Examples: • Supplying a medicine in the form of two or more products with different strengths that together produce the desired strength (parallel TAs). • Supplying a medicine with a different PRK or HPK, for example due to preference policy or stock shortage (serial TAs). • Supplying a medicine both in GDS and in a separate box as ’as needed’ medication. This involves different forms of distribution, so two TAs are required (parallel TAs).
A TA may exist without reference to an MA.	Example: • The supplier dispenses self-care medication and creates a TA in a new MBH. • The supplier dispenses a supplementary medicine for which there is no prescription yet. He creates a TA for this in a new MBH and sends a VMA for the supplementary medicine to the prescriber.
(*) A TA may be accompanied by 0, 1, or more MVEs.	Examples: • 0: The patient has sufficient stock. • 1: This concerns a course of antibiotics. • >1: A repeat supply every 2 weeks.
Medication dispense → other building blocks
In an outpatient setting, an MVE is based on a VV. In that case, the MVE refers to that VV.	Exceptions: • Self-care medication obtained from the supplier. • MVE based on a paper prescription. Paper prescriptions are in principle no longer permitted, but exceptions are possible; see the practical example Paper prescription.
(*)An MVE is based on an MA.	Exception: • Self-care medication obtained from the supplier. The supplier may also create a TA for this, but this is not mandatory.
(*) An MVE is based on a TA.	Exception: • Self-care medication obtained from the supplier. The supplier may also create a TA for this, but this is not mandatory.
(*) An MVE may be associated with multiple TAs.	Example: • A new TA has been created that did not require an MVE, because the patient had sufficient stock. The previous MVE then applies to both the old and the new TA.
Medication use → other building blocks
An MGB may refer to 0 or 1 MA.	Examples: • 0 : A patient records self-care medication with MGB. • 1: A patient records their use of a medicine over the past few weeks with MGB, with reference to the relevant MA.
Multiple MGBs may refer to the same MA.	Example: • A patient regularly keeps track of their medication use by recording MGBs relating to the same MA.
An MGB may refer to 0 or 1 TA.	Example: • 0: A patient records self-care medication provided by the pharmacy using MGB.
Multiple MGBs may refer to the same TA.	Example: • A patient regularly keeps track of their medication use by recording MGBs relating to the same MA.
An MGB can refer to only one other building block, MA or TA.	Reason: • If an MGB refers to both MA and TA, and there is a difference between TA and MA, it is impossible to deduce the meaning of ’as agreed’.
Medication administration → other building blocks
An MTD refers to 0 or 1 MA and/or TA and/or WDS, depending on the situation.	Examples: • In ad hoc situations where medication must be administered immediately, the MTD does not refer to any building block. • In outpatient situations, usually the TA will be referenced. In clinical situations, more likely reference will be made to an MA. • The MTD can refer to both the MA and TA, if both exist. The MA to which the MTD refers must be the same as the one to which the TA refers. • In the case of a WDS, the MTD will refer to both the WDS and the MA. The MA to which the MTD refers must be the same as the one to which the WDS refers.

The proposal data contain proposals for which it is not yet certain whether they will lead to new MAs or VVs. Proposal data always lead to responses containing the decision on those proposals. The numerical ratios for these proposal data are as follows:

• A VMA can lead to 0, 1 or more MAs.
• A VMA leads to 1 AVMA.
• A VVV can lead to 0, 1 or more VVs.
• A VVV leads to 1 AVVV.

2.5.3 Interrelationships between MBH and building blocks represented graphically

The statements in sections 2.5.1 and 2.5.2 result in the following figures:

Figure 2.3 Interrelationships between MBH and building blocks

Figure 2.3 shows how many instances of therapeutic and logistical building blocks can occur within a single MBH. A patient may have zero or more pharmaceutical treatments.

Figure 2.4 Interrelationships between building blocks within an MBH with mutual references

This figure shows the interrelationships between instances of the building blocks within a single MBH. The arrows indicate that one building block can refer to another building block. In the case of double-sided arrows, both building blocks can refer to each other. The following notation is used:

• 0..1 – 0 or 1 time
  
• 0..* – 0, 1 or more times
  
• 1..* – at least once
  
• 1..1 – exactly once
  

The numbers listed with a building block indicate how often this building block can occur within a single MBH (Figure 2.3), or, within the same MBH, with a single instance of the building block on the other side (Figure 2.4).
Example:

Figure 2.5 Explanation of notation numbers in images about the interrelationships between MBH and building blocks

• One instance of building block X can be associated with 0 or 1 instance of building block Y.
• One instance of building block Y can be associated with 0, 1 or more instances of building block X.

NB: The cardinalities within transactions are described in ART-DECOR scenarios, see also Chapter 3.

2.6 Sending and/or making available

A patient's medication data may be stored in various information systems. The aim of Medication Process MP9 is to make these data accessible to all health professionals involved, and to the patient themselves.
There are two methods for exchanging medication building blocks in the healthcare chain: sending and making available.

Sending
Medication data are sent to other parties involved, who receive these data automatically. Medication data are not sent to specific health professionals, but to healthcare providers. When the FD refers to sending to ‘the supplier/general practitioner/pulmonologist, etc.’, it refers to the relevant healthcare providers, not that individual health professional.
In MP9, sending is done using a Sending transaction, for example Sending medication data. The initiative lies with the sending party.

Making available
Once recorded, medication data can also be made available. This means that they can be queried. Querying allows other parties involved in the chain to collect all available medication building blocks.

Not all data are always made available to everyone:

• Proposal data are only sent by the person making the proposal to the recipient of the proposal, the prescriber.
• Dispense requests are only made available for querying by the patient.
• An information system only makes building blocks available that have been created by the health professional concerned. Any copies from another source are not made available.
• The Height and Weight HCIMs can be sent with the medication prescription. Laboratory results can also be sent. Querying/making these building blocks available is not within the scope of MP9.
  

The actual exchange of data takes place in MP9 with the Query and Making Available transactions, for example Query medication data and Making available medication data. The initiative for this lies with the querying party.
PLEASE NOTE: In these transactions, making available is a response to a query, so it concerns the actual delivery of the requested data to the querying party.

See Chapter 3 for further explanation of these transactions.

3 Information exchange

This chapter provides an overview of the information systems, system roles, transactions and the associated building blocks in MP9. It briefly describes how these concepts relate to each other and how they are used in the description of this information standard. The purpose of this chapter is to clarify the basic principles of information exchange within MP9. For detailed information, please refer to the source data in ART-DECOR index.

3.1 Overview of concepts

Recorded medication data are exchanged in the form of instances of medication building blocks. This takes place via transactions between the information systems of health professionals. Transactions are grouped into transaction groups, which in turn are part of scenarios. These can be found in the Scenarios tab in ART-DECOR scenarios.
An overview of the transactions per system role can also be found inART-DECOR (actor: system). A system role is a function that the system fulfils in the exchange of data. Each information system in MP9 must be able to fulfil certain system roles in order to be able to execute the corresponding transaction.

The Dataset tab in ART-DECOR contains the generic dataset with all data types relevant to MP9. A transaction dataset is a subset of this generic dataset. It contains the building blocks and data elements that can or must be exchanged in the transaction in question. The cardinality and conformity of the data elements are specified for each transaction. For an explanation of this, see the Guide to Cardinalities and Conformance .

A use case describes a practical situation in healthcare for which the exchange of information is specified on the basis of:

• Actors: Persons and information systems involved in the use case. This concerns the roles that these actors fulfil:
  • Business roles: prescriber, supplier, administrator, patient
  • System roles: sending, receiving, querying and making available
• Transactions: What information is exchanged, when, between which systems and system roles, and which business roles are involved.

The report Information Standards: foundation for data exchange in healthcare provides further explanation and background information on these concepts and their interrelationships.

3.2 Information systems, system roles and transactions

This section describes the information systems, system roles, transactions and associated building blocks within MP9.

3.2.1 Types of information systems

Within MP9, different types of information systems are distinguished based on their functional role:

• EVS – electronic prescription system
• AIS – pharmacy information system
• PGO – personal health environment
• eTDR – electronic administration registration system
• TrIS – thrombosis information system
  

XIS is the generic term used to refer to an information system.

3.2.2 System roles and associated transactions and building blocks

A system role is a function that the system performs in the exchange of data. It involves the following general functions:

• Sending system – sends data to a Receiving system
• Receiving system – receives data from a Sending system
• Querying system – requests data from an Available-making system
• Available-making system – sends the requested data to a Querying system

An information system can fulfil one or more of these system roles.

The table below provides an overview of the system roles within MP9 with their abbreviations, the corresponding transaction and the building blocks that may be involved. In ART-DECOR can be found how the building blocks involved are implemented for each transaction.

System role	Abbreviation	Transaction	Possible building blocks involved
Scenario Medication prescription
VoorschriftSturend	MP-VOS	Sending medication prescription	MA with or without VV; Length, Weight (if applicable) If necessary, kidney function values can be sent along with the prescription via the Lab2Zorg transaction. See Guide for including kidney function value with prescription.
VoorschriftOntvangend	MP-VOO	Receiving medication prescription
Scenario Medication prescription processing
VoorschriftAfhandelingSturend	MP-VAS	Sending data on processing of medication prescription	TA with or without MVE
VoorschriftAfhandelingOntvangend	MP-VAO	Receiving data on processing of medication prescription
Scenario Medication data
MedicatieGegevensSturend	MP-MGS	Sending medication data	1 or more: MA, VV, TA, MVE, MTD, MGB, WDS
MedicatieGegevensOntvangend	MP-MGO	Receiving medication data
MedicatieGegevensBeschikbaarstellend	MP-MGB	Making medication data available
MedicatieGegevensRaadplegend	MP-MGR	Query medication data
Scenario Proposal data
VoorstelMedicatieafspraakSturend	MP-VMS	Sending proposal medication agreement	VMA with or without Length, Weight
VoorstelMedicatieafspraakOntvangend	MP-VMO	Receiving proposal medication agreement
AntwoordVoorstelMedicatieafspraakSturend	MP-AVMS	Sending reply proposal medication agreement	AVMA
AntwoordVoorstelMedicatieafspraakOntvangend	MP-AVMO	Receiving reply proposal medication agreement
VoorstelVerstrekkingsverzoekSturend	MP-VVS	Sending proposal dispense request	VVV
VoorstelVerstrekkingsverzoekOntvangend	MP-VVO	Receiving proposal dispense request
AntwoordVoorstelVerstrekkingsverzoekSturend	MP-AVVS	Sending reply proposal dispense request	AVVV
AntwoordVoorstelVerstrekkingsverzoekOntvangend	MP-AVVO	Receiving reply proposal dispense request

Certain system roles are each other's logical counterparts and therefore always occur together in a system. For example, sending a prescription and receiving confirmation that the prescription has been processed. This concerns the following Send/Receive pairs:

• MP-VOS and MP-VAO
• MP-VOO and MP-VAS
• MP-VMS and MP-AVMO
• MP-VMO and MP-AVMS
• MP-VVS and MP-AVVO
• MP-VVO and MP-AVVS

3.2.3 Information systems and system roles

An information system can fulfil various system roles. The table below shows which roles these are for each information system.

system role	EVS	AIS	PGO	eTDR	TrIS
MP-VOS	√	-	-	-	√
MP-VOO	-	√	-	-	-
MP-VAS	-	√	-	-	-
MP-VAO	√	-	-	-	√
MP-MGS	√	√	√	√	√
MP-MGO	√	√	√	√	√
MP-MGB	√	√	√	√	√
MP-MGR	√	√	√	√	√
MP-VMS	√	√	√	√	√
MP-VMO	√	-	-	-	-
MP-AVMS	√	-	-	-	-
MP-AVMO	√	√	√	√	√
MP-VVS	√	√	√	√	√
MP-VVO	√	-	-	-	-
MP-AVVS	√	-	-	-	-
MP-AVVO	√	√	√	√	√

Figure 3.1 is a graphical representation of this:

Figure 3.1 Information systems and system roles

3.3 Scenarios

This section describes the following scenarios:

• Medication prescription
• Medication prescription processing
• Medication data
• Proposal data

In the description of each scenario the sub-processes in which it may occur are indicated. The corresponding process descriptions can be found in Chapter 5.
A subdivision per scenario rather than per use case has been chosen. This is because there is no one-to-one relationship between use cases and scenarios within the medication process. For example, the Prescription sub-process includes the use case of sending a medication prescription, but also the use cases of receiving data on the processing of a prescription, receiving and responding to a proposal from a supplier, or drawing up an overview of medication data. All scenarios apply in this sub-process. Conversely, the Medication data scenario can be used for all kinds of different use cases. A description per scenario is therefore the most efficient approach.

3.3.1 Scenario Medication prescription

3.3.1.1 Objective

The objective is for the prescriber to send a prescription to the supplier.

3.3.1.2 Process

This scenario applies to the use case of prescribing medication during the Prescribing sub-process.

3.3.1.3 Business roles and activity diagram

Business role (actor)	Description of business role
Prescriber	Sending medication prescription to supplier
Supplier	Receiving medication prescription from prescriber

3.3.1.4 Systems and system roles

The prescriber uses an EVS. The supplier uses an AIS.

System	Name system role	System role code	Description of system role
EVS	VoorschriftSturend	MP-VOS	Sending medication prescription
AIS	VoorschriftOntvangend	MP-VOO	Receiving medication prescription

3.3.1.5 Relationship between business roles, system roles and transactions

Scenario	Business role	System	System role code	Transaction group	Transaction
Medication prescription	Prescriber	EVS	MP-VOS	Medication prescription (Sending/Receiving)	Sending medication prescription
	Supplier	AIS	MP-VOO		Receiving medication prescription

3.3.2 Scenario Medication prescription processing

3.3.2.1 Objective

The objective is for the supplier to inform the prescriber about the processing of a medication prescription.

3.3.2.2 Process

This scenario applies to the use case of processing medication prescriptions during the sub-process Dispense.

3.3.2.3 Business roles and activity diagram

Business role (actor)	Description of business role
Supplier	Sending data on processing of medication prescription to prescriber
Prescriber	Receiving data on processing of medication prescription from supplier

3.3.2.4 Systems and system roles

The supplier uses an AIS. The prescriber uses an EVS.

System	Name system role	System role code	Description of system role
AIS	VoorschriftAfhandelingSturend	MP-VAS	Sending data on processing of medication prescription
EVS	VoorschriftAfhandelingOntvangend	MP-VAO	Receiving data on processing of medication prescription

3.3.2.5 Relationship between business roles, system roles and transactions

Scenario	Business role	System	System role code	Transaction group	Transaction
Medication prescription processing	Supplier	AIS	MP-VAS	Medication prescription processing (Sending/Receiving)	Sending data on processing of medication prescription
	Prescriber	EVS	MP-VAO		Receiving data on processing of medication prescription

3.3.3 Scenario Medication data

3.3.3.1 Objective

The objective is to enable health professionals and patients to exchange medication data by sending, receiving, querying and making the data available. Examples of use cases include:

• Making available an MGB that has been recorded during the medication verification process;
• Querying medication data for the purpose of drawing up an administration list;
• Sending a stop-MA by a prescriber to the prescriber of the original MA;
• Making a TA and MVE available by the supplier;
• Querying medication data by a patient.

3.3.3.2 Process

This scenario applies to various use cases during each of the sub-processes in Chapter 5.

3.3.3.3 Business roles and activity diagram

The Medication data scenario can apply to all business roles (health professionals and patients).

Business role (actor)	Description of business role
All actors	Sending medication data to fellow health professionals/patient
	Receiving medication data from fellow health professionals/patient
	Query medication data from fellow health professionals/patient
	Providing requested medication data to fellow health professionals/patient

3.3.3.4 Systems and system roles

The generic term XIS can refer to any information system, including EVS and AIS, as well as PGO, TrIS and eTDR.

System	Name system role	System role code	Description of system role
XIS	MedicatieGegevensSturend	MP-MGS	Sending medication data
	MedicatieGegevensOntvangend	MP-MGO	Receiving medication data
	MedicatieGegevensRaadplegend	MP-MGR	Query medication data
	MedicatieGegevensBeschikbaarstellend	MP-MGB	Providing requested medication data

3.3.3.5 Relationship between business roles, system roles and transactions

Scenario	Business role	System	System role code	Transaction group	Transaction
Medication data	All actors	XIS	MP-MGS	Medication data (Sending/Receiving)	Sending medication data
			MP-MGO		Receiving medication data
			MP-MGR	Medication data (Querying/Making available)	Query medication data
			MP-MGB		Making medication data available

3.3.4 Scenario Proposal data

NB: In this FD and the dataset, the proposal data are published as a beta version (see section 1.5.4).

3.3.4.1 Objective

The objective is to make a proposal regarding an MA or VV to the prescriber. All actors can make such a proposal.

3.3.4.2 Process

This scenario applies in use cases during all sub-processes. In section 5.6 the working method with proposal data is explained in more detail.

3.3.4.3 Business roles and activity diagram

The Proposal data scenario can apply to all business roles (health professionals and patients).

Business role (actor)	Description of business role
All actors	Sending proposal MA/VV to prescriber
	Receiving reply proposal MA/VV from prescriber
Prescriber	Receiving proposal MA/VV from all actors
	Sending reply proposal MA/VV to all actors

3.3.4.4 Systems and system roles

The prescriber uses an EVS. All actors use an XIS.

System	Name system role	System role code	Description of system role
XIS	VoorstelMedicatieafspraakSturend	MP-VMS	Sending proposal medication agreement
	AntwoordVoorstelMedicatieafspraakOntvangend	MP-AVMO	Receiving reply proposal medication agreement
	VoorstelVerstrekkingsverzoekSturend	MP-VVS	Sending proposal dispense request
	AntwoordVoorstelVerstrekkingsverzoekOntvangend	MP-AVVO	Receiving reply proposal dispense request
EVS	VoorstelMedicatieafspraakOntvangend	MP-VMO	Receiving proposal medication agreement
	AntwoordVoorstelMedicatieafspraakSturend	MP-AVMS	Sending reply proposal medication agreement
	VoorstelVerstrekkingsverzoekOntvangend	MP-VVO	Receiving proposal dispense request
	AntwoordVoorstelVerstrekkingsverzoekSturend	MP-AVVS	Sending reply proposal dispense request

3.3.4.5 Relationship between business roles, system roles and transactions

Scenario	Business role	System	System role code	Transaction group	Transaction
Proposal data	All actors	XIS	MP-VMS	Proposal medication agreement (VMS/VMO)	Sending proposal medication agreement
	Prescriber	EVS	MP-VMO		Receiving proposal medication agreement
Proposal data	All actors	XIS	MP-AVMO	Reply proposal medication agreement (AVMS/AVMO)	Receiving reply proposal medication agreement
	Prescriber	EVS	MP-AVMS		Sending reply proposal medication agreement
Proposal data	All actors	XIS	MP-VVS	Proposal dispense request (VVS/VVO)	Sending proposal dispense request
	Prescriber	EVS	MP-VVO		Receiving proposal dispense request
Proposal data	All actors	XIS	MP-AVVO	Reply proposal dispense request (AVVS/AVVO)	Receiving reply proposal dispense request
	Prescriber	EVS	MP-AVVS		Sending reply proposal dispense request

4 Consolidation: what, why and how

Consolidation involves merging data and then applying rules to create a coherent whole.
This chapter explains the what, why and how of consolidation.
Section 4.1 explains what consolidation is in the context of this information standard.
Section 4.2 explains the purpose of consolidation.
Section 4.3 describes the consolidation process.
Section 4.4 explains the concepts that are important in this context.
Section 4.5 describes the consolidation rules.
Section 4.6 explains what consolidation means for medication data overviews.

4.1 What is consolidation?

Consolidation is the merging of data and the application of rules to the merged set in order to arrive at a coherent whole.
In this information standard, this concerns the set of building blocks that is collected during querying. This collection can be very extensive. There may be different MBHs, each of which may also contain multiple building blocks. This can even amount to hundreds of building blocks.
After querying, consolidation rules are used to determine how each building block in the set should be interpreted.

4.2 What is the goal of consolidation?

The purpose of consolidation is to create a ‘coherent whole’ within the collection of building blocks. What this means exactly depends on the purpose of the query. An administration list requires different data than a general practitioner who wants to view the medication history of a new patient. It must be clear which building blocks provide the desired data. The consolidation rules can be used to determine the status of each building block within 1 MBH on the basis of two criteria:

• Is a building block ‘active’ or not?
• Is a building block ‘valid’ or not?

This status determines whether a building block contains the correct information for the intended application.

The concepts ‘active’ and ‘valid’ are explained in section 4.4.

4.3 Consolidation process

Consolidation involves the following steps:
Collecting building blocks
Building blocks for a specific period of time are collected from all available sources. This is done using the Query medication data transaction (see section 3.3.3).
In some situations, a building block may appear to be active and valid when in fact this is no longer the case. For this reason, the stop-building block with the most recent RegistrationDateTime must also be provided for each MBH, using the query parameter LastStop. The available-making system will then provide the last stop-MA, stop-TA and stop-WDS, even if such a building block falls outside the requested time period. In this way, it can still be determined that the building block has been stopped.
Deduplicating identical building blocks
In principle, duplicate building blocks should not occur, as the information systems involved in this transaction are only allowed to make their own medication data available. In some cases, however, this can still occur. The information system must therefore be able to identify and deduplicate any identical building blocks.
Applying consolidation rules
Consolidation rules are used to determine the activeness and validity of each building block in an MBH. This is explained in more detail in the following sections.

4.4 Terms relevant to the description of the consolidation rules

This section explains the terms used in the consolidation rules. The general rules are described using examples. These rules are explained in detail in section 4.5.

4.4.1 Is a building block active?

Active means that the effective end date/time of a building block, viewed from the present, lies in the future. The following section explains what is meant by the word ‘effective’ in the above sentence.

4.4.1.1 Effective period

The effective period of a building block is the period during which a building block is (or has been) current.

Once a building block has been established, it does not change (see section 2.4.3). This also applies to its PeriodOfUse. In practice, however, the actual start and end dates of an agreement may differ from those specified in the building block.

General rule: The effective end date/time of a building block changes due to a stop building block with reference to that building block.

Example
A patient is prescribed a medication for an indefinite period. The MA has startDateTime = day 1 and no endDateTime. After two weeks, the prescriber decides that the patient should stop taking the medication due to side effects. The stop-MA has the startDateTime of the original MA = day 1 and endDateTime = day 14.
On day 30, the MA appears to be current when viewed on its own, as it has no endDateTime. However, the effective end date/time of the MA has become that of the stop-MA.

General rule: The effective start date/time and end date/time of an MA can be influenced by a TA.

Example
A patient is prescribed a medication for 5 days. The MA has startDateTime = day 1 and endDateTime = day 5. The patient picks up the medication after 3 days. The TA therefore has a startDateTime = day 4 and an endDateTime = day 8.
On day 6, the endDateTime of the MA has passed. If only that MA is considered, it no longer appears to be current. However, the TA shows that the MA should still be considered current. The MA has an effective start date/time = day 4 and an effective end date/time = day 8.

These general rules are specified in more detail in section 4.5.1.

4.4.1.2 Active and non-active

Active building blocks have an effective end date/time that lies in the future relative to the present. Active building blocks are:

• Current building blocks, where the present lies between the effective start date/time and the effective end date/time.
• Future building blocks, where the effective start date/time lies in the future.

Non-active building blocks have an effective end date/time in the past. These building blocks form the history of a treatment. This also allows the course of a treatment in the past to be viewed.

Figure 4.1 illustrates these concepts graphically.

Figure 4.1. Active (present + future) and non-active building blocks within an MBH

4.4.2 Is a building block valid?

Valid refers to whether a building block accurately reflects the real situation. This depends on the context, in the form of possible other building blocks in the MBH concerned.
Once recorded, the information in a building block does not change. However, how that information should be understood may change when a subsequent building block is recorded within the same MBH.

General rule: A stop-building block stops the building block to which it refers, thereby making it invalid.

Example
There is an MA for an indefinite period with an accompanying VV. Can the supplier dispense medication based on this MA?
Situation A: No stop-building block with reference to this MA has been recorded. The MA is valid: the information in this building block is a correct representation of the actual situation.
The answer is Yes. Based on the information in this building block, the supplier may dispense the medicine.

Situation B: The MA has been followed by a stop-MA with reference to this MA. The MA has therefore been stopped and thus been made invalid: this MA does not provide an accurate representation of the real situation.
The answer is No. The supplier may no longer dispense the medicine, even though it is an MA for an indefinite period.

General rule: Some building blocks can also make building blocks of a different type invalid

Example
There is a current MA and TA for a medicine that needs to be administered. The TA is not followed by a stop-TA. Can the administrator administer the medicine?
Situation A: The corresponding MA has not been followed by a stop-building block. The MA and the TA are therefore both valid.
The answer is Yes. The administrator may administer the medicine in question.

Situation B: The corresponding MA has been stopped by a stop-MA with immediate effect. However, this stop-MA has not yet been processed in the pharmacy, which means that no stop-TA has been created yet. Although the TA is still current, it has become invalid due to the stop-MA.
The answer is No. The administrator may no longer administer the medicine.

These general rules are specified in more detail in section 4.5.2.

4.5 Consolidation rules

Section 4.4 shows that a building block can be valid without being active. Conversely, a building block can also be active without being valid. The corresponding rules for both are set out below.

4.5.1 Rules for determining the effective period of a building block

Section 4.4.1.1 lists two general rules regarding the effective period:

General rules:
The effective end date/time of a building block changes due to a stop building block with reference to that building block.
The effective start date/time and end date/time of an MA can be influenced by a TA.

The effective start date/time and end date/time, and therefore the effective period of a building block, are derived data. They are therefore not part of the dataset. The derivation rules are explained below. The number next to each derivation rule indicates the order in which the rules must be executed.

Starting medication
Making a medication agreement
Medication is started by recording an MA.

Rule 1a: The effective period of an MA is equal to its PeriodOfUse.

Making an administration agreement
A TA fills in an MA in concrete terms.

Rule 1b: The effective period of a TA is equal to its PeriodOfUse.

If an MA has an associated TA, the following applies:

Rule 2a: The effective period of the MA is equal to the effective period of the TA.

Stopping medication
Stopping a medication agreement
Medication is permanently stopped by creating a stop-MA with stop type ‘stopped’ and:

• startDateTime = startDateTime of the original MA
• endDateTime = date on which the medication is stopped.

The effective period of the original MA is replaced by that of the new stop-MA.

Rule 1c: When an MA is permanently stopped, the effective period of the MA is the effective period of the stop-MA.

Stopping an administration agreement
Situation a) The TA is stopped while the MA remains unchanged.
The effective period of the original TA is replaced by the effective period of the stop-TA. According to rule 1b, the latter is equal to its PeriodOfUse.

Situation b) The TA is stopped as a result of a stop-MA.
The stop-TA fills in the stop-MA in concrete terms. It is possible that the endDateTime of the stop-TA is later than that of the stop-MA, for example because the stop-MA specifies that the stop can take effect with the next GDS medication role. In such a case, the effective period of the MA changes, according to rules 1b and 2a.

Rules 1b and 2a: effective period stop-MA = effective period stop-TA = PeriodOfUse stop-TA.

Changing medication
Changing medication agreement
The prescriber changes medication within the MBH by discontinuing the original MA1 and creating a new MA2. This does not change the previous derivation rules:

Rule 1a: effective period of new MA2 = PeriodOfUse of MA2.
Rule 1c: effective period MA1 = effective period technical stop-MA.

Changing the administration agreement
Situation a) The TA is changed while the MA remains the same.
An MA is filled in in concrete terms by a TA. A change can be made to this TA (see section 5.3.2.4). This means that several consecutive TAs can be created under one MA. The effective period of the MA is now determined by all associated TAs.

Rule 2b: The effective period of an MA runs from the earliest startDateTime to the latest endDateTime of the associated TA's.

Parallel TAs may exist under a single MA whose RegistrationDateTime and startDateTime are the same. This does not change rule 2b.

Situation b) The TA is changed as a result of a change in the MA. This does not change the previous rules.

Temporarily interrupting and resuming medication
Medication is interrupted by creating a stop-MA with stop type ‘interrupted’ and with the same startDateTime as the original MA. The endDateTime of the stop-MA is the moment of the temporary interruption. Resumption is done by creating an MA with the date of resumption as startDateTime. However, the stop type ‘interrupted’ ensures that the effective period remains based on the effective startDateTime of the original MA.

Rule 1d: Temporary interruption of medication does not affect the effective period. The effective period remains the same as the effective period of the original MA.

4.5.1.1 Summary of rules for determining the effective period

The rules described must be applied in numerical order:

• Rule 1a: The effective period of an MA is equal to its PeriodOfUse.
• Rule 1b: The effective period of a (stop-)TA is equal to its PeriodOfUse.
• Rule 1c: When an MA is permanently stopped, the effective period of the MA is the effective period of the stop-MA.
• Rule 1d: Temporary interruption of medication does not affect the effective period. The effective period remains the same as the effective period of the original MA.
• Rule 2a: The effective period of the MA is equal to the effective period of the TA.
• Rule 2b: The effective period of an MA runs from the earliest startDateTime to the latest endDateTime of the associated TA’s.
  

4.5.2 Rules for determining the validity of a building block

Section 4.4 lists two general rules regarding the validity of building blocks within 1 MBH. These are specified in more detail below.
General rules:
A stop-building block stops the building block to which it refers, thereby making it invalid.
Some building blocks can also make building blocks of a different type invalid.

Stopping and making invalid other building blocks takes effect from the endDateTime of the stop-building block. The specific validity rules within a single MBH are as follows:

1. A stop-MA makes invalid at its endDateTime:

• the original MA to which this stop-MA refers, and
• the TA and WDS that also refer to that original MA, and
• all previously recorded MGBs

2. A stop-TA makes invalid at its endDateTime:

• the original TA to which this stop-TA refers, and
• all previously recorded MGBs

3. A stop-WDS makes invalid on its endDateTime:

• the WDS to which this stop-WDS refers, and
• all previously recorded MGBs

4. Each type of MA, TA and WDS makes invalid all previously recorded MGBs.

5. Each type of MGB makes invalid all previously recorded MGBs, provided they originate from the same type of author.

Exception: In the case of parallel TAs, a new MGB only makes invalid the older MGBs that belong to the same TA and originate from the same type of author.

The same rules apply to cancelation-building blocks.

The validity rules apply to agreement building blocks, i.e. MA, TA, and WDS. MGBs are not agreement building blocks, but may still be relevant. That is why they are also included in the consolidation rules. In the case of MGBs, ‘invalid’ can be interpreted as ‘the information in this building block may be out of date’.
MTDs are not included in these rules. An MTD is a record of an action that has already taken place. A stop-building block has no influence on an MTD that has already been recorded.

NB: Once a building block has been made invalid, it cannot be made valid again. A new building block must then be created.

The rules are applicable in the most common situations within an MBH. However, there may be situations that are not adequately covered by these rules. If a system cannot determine which building blocks are valid based on the above rules, this must be indicated to the end user. The end user can then assess this further themselves.

The rules are illustrated with examples on the page Examples of validity rules.
The Implementation manual Consolidation/derivation Rules provides a (non-normative) step-by-step plan for a possible practical application of the rules.

4.6 Medication data overviews

After consolidation, for each building block in an MBH is known whether it’s valid or invalid, and active or non-active. This allows all data to be placed in its correct context.
Based on this, various overviews of medication data can be generated. There are all kinds of situations and purposes in which an overview of medication data can be used. Therefore, there is no single definition or description for this. Such an overview can also take various forms (paper, PDF, presentation on a screen, etc.).

The consolidation rules are used to compile:

• a medication overview as described in the Guideline on the Transfer of Medication Data in the Chain
• an administration list

For each situation a proper presentation can be chosen, in consultation between the user or organisation and the supplier. The effective period can be used, for example, to show the course of a treatment, or to classify medication as current, future and recently discontinued.
Further information on administration lists can be found in section 5.4.2.

There are also situations in which the consolidation rules do not lead to a complete and/or accurate overview, for example because the patient has not given permission to share information. Medication verification is therefore always desirable.

5 Medication process

This chapter describes the medication process in relation to recording and exchanging the necessary data. The generic medication process essentially consists of the sub-processes of prescribing, dispensing, administering and using. The process begins when a patient starts using a medicine, whether prescribed or not. It ends when the use of the medicine in question stops.

The process can vary depending on the sector and situation. Not all parts are always applicable; for example, a VV is required for medication dispensing in an outpatient situation, but not in a clinical situation. Sub-processes can also be carried out iteratively or in a different order.

Supporting activities such as medication verification and medication monitoring are also necessary to ensure that the medication process is carried out responsibly. Medication verification is involved in various sub-processes and is therefore also included as a separate sub-process.
Because MP9 contributes to the completeness of medication data, better medication monitoring can be carried out. Medication monitoring itself falls outside the scope of this FO.

The sub-processes are described in sections 5.1 to 5.5.
Section 5.6 explains proposal data.
Section 5.7 contains some points of attention regarding the clinical situation.
Section 5.8 summarises the information relating to GDS medication from the previous sections.

The functional description is illustrated with practical examples. All practical examples can be found on a separate overview page. In addition, there are separate pages with practical examples for each sub-process and for GDS (Medicine Distribution System, Dutch: Geneesmiddel Distributie Systeem):

• Practical examples sub-process Medication verification
• Practical examples sub-process Prescribe
• Practical examples sub-process Dispense
• Practical examples sub-process Administer
• Practical examples sub-process Use
• Practical examples GDS

Some practical examples are relevant to multiple sub-processes and can therefore be found on different pages.

5.1 Sub-process Medication verification

This section describes the medication verification process. Medication verification involves determining the actual use of medication by the patient, together with the patient or their representative. Other information that may be relevant to that use (contraindications, allergies, serious side effects and laboratory values) may also be requested. The aim is to gain optimal insight into the actual use of medication by a patient, so that good care can be provided. Medication verification may be necessary or desirable at various points in the care process. For example, prior to prescribing, dispensing or administering medication, when evaluating a treatment, or when preparing for admission. To support the implementation of this sub-process, various examples are available on the page Practical examples sub-process Medication verification.

5.1.1 Overview of the sub-process Medication verification

Using the Query medication data transaction, the health professional collects the available medication building blocks, including any MGBs recorded by the patient. After consolidation, the health professional has an overview of the patient's medication.
In addition, sources such as the following can also be used:

• medication brought along
• telephone information from the patient's pharmacist or general practitioner

The health professional discusses this information with the patient and can record the verified medication (including self-care medication and medication from abroad) with the MGB building block.
The recorded data on medication use are made available to fellow health professionals and the patient so that they can be queried.

5.1.2 Results of Medication verification

5.1.2.1 How is a medicine used?

When verifying medication, the following outcomes are possible for each medicine:

• The medicine is being used as agreed.
• The medicine is not being used as agreed. Examples:

– The patient is using the medicine differently than agreed, or wants to do so.

– The patient is using a different medicine than the one known to the health professional.

• It is unknown whether the use is as agreed. Example:

– The patient has been prescribed medication abroad, but the prescription is no longer available.

The health professional can record these findings for each medicine using the MGB building block. This is explained in more detail in section 5.1.3.

In the event of deviating use, a prescriber may also decide to record a new MA or MA with modification (see section 5.2.2). If the prescriber sees no reason to do so, they may also record only an MGB, possibly with a comment that he or she has requested the patient to adhere to the agreements made earlier.
In the event of deviating use, a health professional can also send a VMA to the prescriber (see section 5.6) and/or advise the patient to inform the prescriber about the deviating use.

5.1.2.2 Inadvertently outstanding medication or ‘orphans’

During verification, it may become apparent that medication is incorrectly still outstanding. In certain situations, building blocks (MAs, TAs) may have remained inadvertently active, known as ‘orphans’. Examples:

• In the hybrid situation, something went wrong when merging building blocks for the same medication.
• Medication has been discontinued in a system other than that of the prescriber, and this system is no longer available for exchanging building blocks. As a result, the stop-MA is not provided and the original MA therefore still appears to be active and valid.
  

In the case of building blocks with endDateTime, the problem is limited because that medication is automatically no longer active after the endDateTime. Building blocks without an endDateTime, however, would continue to appear active and valid without intervention. Such ‘orphans’ can be identified during medication verification. The health professional must correct this with a stop-building block. If possible, the stop-building block is sent to the health professional who recorded the original building block.

5.1.3 Directions for recording data in the building block medication use

This section explains how to fill in certain data elements in specific situations. All formal source information about the building blocks and their data elements can be found in the Dataset and Scenarios tabs in the ART-DECOR index. The table below shows how certain data elements should be filled in in different situations.

The health professional performing the verification is the Author of the building block. In Informant, the source of the relevant information can be indicated, for example the patient, a health professional or another person involved. In RelationMedicationAgreement or RelationAdministrationAgreement, reference is made to the MA or TA that was the reference for specifying this use.

Situation	Use Indicator	AsAgreed Indicator	MedicationUse StopType	PeriodOfUse (fill in a maximum of 2 out of 3)			DosingInstructions
				startDateTime	Duration	endDateTime
Medication is/will be used in PeriodOfUse
This is as agreed	yes	yes	leave empty	fill in in accordance with MA or TA			fill in in accordance with MA or TA
				date/time when medication use started or will start	(intended) duration of medication use	date/time when medication use is or will be discontinued
This is not as agreed	yes	no	leave empty	date/time when deviating medication use started or will start	(intended) duration of non-compliant medication use	date/time when non-compliant medication use is or will be discontinued	the actual dosage used must be entered
There is no agreement (self-care medication) / unknown whether this is as agreed	yes	leave empty	leave empty	date/time when medication use started or will start	(intended) duration of medication use	date/time when medication is or will be discontinued	the dosage agreed upon by the patient must be entered
Medication is not/will not be used in PeriodOfUse
This is as agreed	no	yes	leave empty or fill in in accordance with stop-agreement	date/time from which medication use will be discontinued or suspended	n/a in case of discontinuing (intended) duration of suspension of medication use	n/a in case of discontinuing date/time when medication use is or will be resumed	leave empty, there is no dosage
This is not as agreed	no	no	discontinued / suspended	date/time from which use will be discontinued or suspended	n/a in case of discontinuing (intended) duration of suspension of medication use	n/a in case of discontinuing date/time when medication use is or will be resumed	leave empty, there is no dosage
There is no agreement (self-care medication) / unknown whether this is as agreed	no	leave empty	discontinued / suspended	date/time from which medication use will be discontinued or suspended	n/a in case of discontinuing (intended) duration of suspension of medication use	n/a in case of discontinuing date/time when medication use is or will be resumed	leave empty, there is no dosage

More information about filling in the MGB, MA and TA medication building blocks during medication verification can be found in the Implementation manual for filling in building blocks during medication verification.

5.1.4 Information exchange and system roles during sub-process Medication verification

During the Medication verification sub-process, various forms of information exchange may take place. The table below shows which system roles are required for this.

type of information exchange	system role	system role code
The health professional queries the available medication data.	MedicatieGegevensRaadplegend	MP-MGR
The health professional's information system responds to the query by providing the recorded medication data.	MedicatieGegevensBeschikbaarstellend	MP-MGB
The health professional can send the recorded medication data to other health professionals.	MedicatieGegevensSturend	MP-MGS

Health professionals who perform medication verification can use various information systems. See section 3.2.3 for an overview of the system roles per information system.

5.2 Sub-process Prescribe

This section describes the prescribing process. The prescriber role may be cariied out by anyone with prescribing authority under the Individual Healthcare Professions Act (Wet op de beroepen in de individuele gezondheidszorg, BIG). In addition, a prescriber may delegate this task to other health professionals without their own prescribing authority. This is only permitted within the conditions set out in the Act and within the agreements of the healthcare organisation concerned.
To support the implementation of this sub-process, various examples are available on the page Practical examples sub-process Prescribe.

5.2.1 Overview sub-process Prescribe

5.2.1.1 Process of prescribing in general

Starting the prescribing process
The prescribing process can start during a consultation or following a proposal from another health professional or the patient regarding their medication treatment. See section 5.6 for an explanation of proposal data.
The prescriber evaluates the patient's situation, including their medication treatment. An overview of medication data can be used for this purpose (see Chapter 4).

Possible actions when prescribing
The prescriber then decides to start, continue, stop or change medication. The following medication building blocks can be recorded:

• MA for recording the prescriber's therapeutic intention.
• WDS for specifying the dosing regimen for medicines with varying dosages (e.g. anticoagulant medication)
• VV for the logistical processing of the prescribed medication.

This is further elaborated for each building block in sections 5.2.2 to 5.2.4.
Section 5.2.5 contains instructions for completing the MA and VV building blocks in specific situations.

Exchanging data
The prescriber sends the (stop-) MA with or without VV to the supplier using the Sending medication prescription transaction. If necessary, a WDS, information about the patient's height or weight, or kidney function value can be sent along with it. The recorded data are also made available. The transfer of information is discussed further in section 5.2.6.
Medication monitoring is carried out during the prescribing process; the details of this are outside the scope of this FD.

5.2.1.2 Some specific situations

GP out-of-hours service (huisartsenpost, HAP)
A GP out-of-hours service works on behalf of the regular GP. In principle, the generic prescribing process is followed by the HAP. The HAP can also start, continue, change, and stop medication. If necessary, the HAP will also make the corresponding dispense requests. To supplement this process, the GP out-of-hours service prescriber can use the data element NextPractitioner (see section 5.2.5.1.7).

Medication process in the clinical situation
The medication process in the clinical situation is dealt with separately in section 5.7.

Medication on the administration list
For some patients, medication is listed on an administration list (administration patients). This medication can be administered by an administrator or by the patient themselves. The data required to generate an administration list can be recorded by the prescriber in MA or WDS and/or by the supplier in the TA (see section 5.2.5 and section 5.4.2).

5.2.2 Medication agreement

The MA is the therapeutic building block in a prescription. In it, the prescriber records what has been agreed with the patient about the medicine in question. The MA reflects the prescriber's therapeutic intention.

In general terms, a prescriber can create an initial MA within a new MBH, or continue, stop, change or temporarily interrupt an existing MA. This is explained in sections 5.2.2.1 to 5.2.2.5. See also section 2.4.3 for an explanation of the procedure for stopping and modifying a building block.

The intended duration of the medication is specified in the PeriodOfUse:

• Medication for an indefinite period: only startDateTime is entered, without duration or endDateTime
• Medication for a specific period: 2 of the 3 data elements must be entered. This also applies to medication for single use.
• If an endDateTime is specified, the time must always be provided. This is to avoid confusion between ‘until’ and ‘up to and including’. In the case of an ‘up to and including’ date (i.e. a whole day), the time 23:59:59 applies.

Section 5.2.5.1 explains how a number of data elements should be completed in certain situations.

5.2.2.1 Starting medication

An initial MA usually marks the start of an MBH. Sometimes, an MBH can also start with a different therapeutic building block. Examples:

• MTD in situations where acute administration of a medicine is required.
• TA if the supplier does not (yet) have access to the digital MA, for example in the hybrid situation.
• MGB recorded by the patient.

In such cases, the first MA in an MBH can follow after the other building block has been recorded. Even then, the MA always takes precedence in reflecting the prescriber's therapeutic intention.

An MA can be created to take effect immediately, but it can also be planned in advance, with a start date in the future (TMA). This TMA has a startDateTime that is later than the date on which the agreement was made.

5.2.2.2 Continuing medication

Examples of continuing medication are:

• Repeat medication; only a new VV is required for an existing MA.
• Upon admission to an institution where home medication is continued.

In both cases, the existing MA does not need to be adjusted unless the endDateTime of the MA has passed. In that case, a new MA must be recorded.
NB: Continuing treatment with a drug with a different PRK is not considered continuation, but a change (see section 5.2.2.4).

5.2.2.3 Stopping medication

An MA in which an endDateTime has already been specified, for example for a course of treatment, will automatically stop on that date. No stop-MA is required in this case.
If the medication needs to be discontinued earlier, or if an MA does not have an endDateTime, a stop-MA must be specified within the same MBH. The stop-MA contains the following new data:

data-element in dataset	explanation
endDateTime	The date on which the MA ends. This end date can also be in the future.
Prescriber	Name of the health professional creating the stop-MA.
RegistrationDateTime	Date and time on which the stop-MA is recorded.
MedicationAgreementStopType	'discontinued'
RelationMedicationAgreement	Reference to the MA being stopped. A stop-MA must include this reference, unless there is no MA available in the MBH to refer to. If the MBH only contains TA(s) and/or MGB(s), the prescriber must be able to stop these with a stop-MA without a RelationMedication Agreement. In that case, the stop-MA will not get a reference to a TA or MGB either.
ReasonModificationOr Discontinuation	Reason for stopping the MA. Filling in this data element is mandatory in outpatient settings. In clinical settings, this only needs to be completed if relevant for exchange within the care chain.

From the referenced MA, the remaining available information must be copied, including at least the following elements:

data-element in dataset	explanation
startDateTime	The original start date.
AgreedMedicine	The agreed-upon medicine. In the case of magistral preparations or ingredients, 90 million numbers do not need to be copied.
InstructionsForUse	The original instructions for use. The AdditionalInstructions data element does not need to be included, as the method of use is no longer relevant in a stop-MA.

The MA can be stopped immediately with an endDateTime today.
The MA can also be stopped with an endDateTime in the future. If the prescriber subsequently wishes to shorten the PeriodOfUse further, a second stop-MA is created. This second stop-MA refers to the most recent MA, in this case the first stop-MA.

Creating a stop-MA leads to the discontinuation of the associated WDSs and TAs. A stop-TA must also be created for the TAs. No stop-WDS is required for the WDS.

5.2.2.3.1 Stopping a medication agreement by another prescriber

A MA can be stopped by the prescriber themselves, or by another prescriber. When a prescriber stops a medication, they create a stop-MA. This is also the case when stopping someone else's MA. The stop-MA is sent to the health professional who created the MA that is being stopped (transaction Sending medication data).
The stop-MA must also be sent to the supplier. The prescriber can find this supplier by querying the TAs associated with the MA (transaction Query medication data). They then send the stop-MA to the supplier with an active TA (transaction Sending medication prescription).

5.2.2.3.2 Canceling a future medication agreement

Stopping an MA with a startDateTime in the future (TMA) is called canceling. The TMA is canceled by recording a cancelation-TMA. This is a stop-TMA with the stop type ‘canceled’. The cancelation-TMA shows that the patient has never used the medication in question according to that TMA.
The cancelation-TMA works the same as the stop-MA described above, but with two differences:

• The stop type is ‘canceled’ instead of ‘discontinued’.
• The startDateTime and endDateTime of the cancelation-TMA are the same.

The distinction between a cancelation-TMA and a regular stop-MA clarifies whether a medication has never been used (according to that TMA) or whether its use was first started and then stopped.

5.2.2.4 Modifying medication

Modifying medication can, for example, concern dosage, route of administration, period of use, or prescriber.

If a modification results in a different PRK, the prescriber discontinues the medication and records a new PRK in a new MBH (see section 2.4.2). Examples include a change in route of administration or strength, or switching to a different medication.
If the PRK of the prescribed medication remains the same, modifications are recorded under the same MBH.

Medication is modified by recording a technical stop-MA and a new MA with the modification within the same MBH. The technical stop-MA has an endDateTime equal to the startDateTime of the new MA with the modification (see section 2.4.3).
The new MA includes a reference to the original MA in RelationMedicationAgreement. If relevant for exchanges within the chain, the reason for the modification can be recorded in ReasonModificationOrDiscontinuation.

Extending the PeriodOfUse of an MA can be done in two ways:

• Creating a new MA2 with a startDateTime after the endDateTime of the original MA1. A stop-MA is not required for MA1; it expires automatically on its endDateTime. The new MA2 can be created either during or after the PeriodOfUse of MA1.
• Extending the PeriodOfUse of the original MA1 if it has not yet expired. This is a change with a technical stop-MA and a new MA2 with the extended PeriodOfUse.

A modification can take effect immediately or can be scheduled with a startDateTime in the future. If the modification is implemented in a future MA, a technical cancelation-TMA is created and a new TMA with the modification.

The technical stop-MA and technical cancelation-TMA work the same way as the regular stop-MA and cancelation-TMA. They also have the stop type ‘discontinued’ or ‘canceled’ (see section 5.2.2.3).

The technical stop-MA and new MA are created simultaneously and therefore have the same RegistrationDateTime (see section 2.4.3.1). They are sent and made available simultaneously. When queried, they are also provided simultaneously. The same applies to the technical cancelation-TMA and new TMA.

5.2.2.4.1 Correcting a medication agreement

A prescriber may have made a mistake in an MA, for example, a typo in the dosage. If the incorrect MA has not yet been shared with other health professionals, the prescriber can adjust or delete it in their own information system. If the incorrect agreement has already been shared with other health professionals, it must be corrected. If the PRK remains the same, correction follows the process of modifying an MA. Two new MAs are created within the same MBH:

• A new MA with the correct information and ‘incorrect registration of medication’ in ReasonModificationOrDiscontinuation.
• A technical stop-MA with the stop type ‘discontinued’ and a reference to the MA to be corrected in RelationMedicationAgreement.

Correcting a future MA is done in the same way, with a technical cancelation-TMA plus a new TMA.

If the correction involves prescribing medication with a different PRK, it is not considered a modification. In that case, the MA is stopped with a stop-MA with ‘incorrect registration of medication’ in ReasonModificationOrDiscontinuation. The new MA is recorded in a different MBH.

5.2.2.4.2 Modifying a medication agreement by another prescriber

A MA may be modified by the prescriber themselves or by another prescriber.
The technical stop-MA is sent to the health professional who created the original MA (transaction Send medication data).
The technical stop-MA and new MA are sent, with or without VV, to the supplier with an active TA (see section 5.2.2.3.1).

5.2.2.5 Temporarily interrupting and resuming medication

Temporarily interrupting means stopping the medication for a certain period of time. The interruption can take effect immediately or a future interruption can be planned. During the interruption period, the medication is considered active because of the intention to resume it in the future. Two new MAs are created within the same MBH:

• A stop-MA with stop type ‘suspended’, reference to the MA to be interrupted in RelationMedicationAgreement and, if relevant for exchange within the chain, the reason for interruption in ReasonModificationOrDiscontinuation.
• A new MA for resumption with a reference to that stop-MA and, if applicable, the reason for resumption in ReasonModificationOrDiscontinuation. This new MA can be created immediately or later, for example, only when the date of resumption is known.

If the prescriber wishes to permanently stop the interrupted MA, a stop-MA with stop type ‘discontinued’ is created with reference to the stop-MA with which the original MA was interrupted.

Temporary substitution with another medicine is not a modification or interruption but an actual discontinuation of the first medicine and the start of a new MBH with the substitute.

5.2.3 Variable dosing regimen

For some medicines, the dosage regimen is variable, for example because it depends on certain blood values. An example is anticoagulant medication. In this case, the prescriber determines the therapeutic INR range (International Normalised Ratio, a measure of blood clotting time) within which the treatment should take place.
The dosage instructions are then recorded in the WDS rather than the MA. With a WDS, the dosage of the medication can be adjusted without having to change the MA.
The thrombosis specialist draws up the specific dosage instructions within the agreed INR range and based on the measured INR value. This INR value is recorded in the WDS Comment data element, so that it is clear on which value a particular regimen is based. The prescribing physician who created the MA remains responsible for the VVs.

5.2.3.1 Starting a variable dosing regimen

The prescriber prescribes anticoagulant medication and records the following in the MA:

• AgreedMedicine: the prescribed medication. The WDS always records the same medication as in the MA.
• AdditionalInstructions ‘use according to thrombosis service schedule’; no dosage instruction is therefore included in the MA.
• Comment: the INR range within which treatment should take place.

The prescriber creates an initial WDS to bridge the period until thrombosis care is involved. Based on the INR value and, if necessary, their professional assessment, the thrombosis specialist draws up a WDS that modifies or follows the prescriber's schedule. From this point on, the thrombosis service takes over the drawing up of the WDSs from the prescriber.

5.2.3.2 Continuing a variable dosing regimen

A WDS will always be drawn up for a fixed period. It is updated based on relevant measurements. When the WDS expires at the end of the PeriodOfUse, it will be replaced by a new WDS (but see also section 5.2.3.4). The new WDS will contain a link to the MA and to the previous WDS. A stop-WDS is not required.

5.2.3.3 Stopping a variable dosing regimen

As long as there is an MA, there must also be a dosage instruction. If this is filled in by a WDS, a WDS must always exist for the duration of the MA.
Permanently stopping a WDS is done by stopping the MA. The thrombosis physician or other prescriber creates a stop-MA, or sends a VMA with a proposal to stop to the prescriber. Stopping the MA leads to the discontinuation of the associated WDS. No stop-WDS is then required.
If treatment needs to be restarted after some time, the normal procedure of creating an MA and starting a WDS is followed.

5.2.3.4 Modifying a variable dosing regimen

In case of anticoagulant medication, the MA must always be accompanied by a WDS. Therefore, the WDS wil usually continue until after the next measurement of the relevant blood value. This means that a WDS usually needs to be modified. This is done according to the normal modification process by recording a new WDS and a technical stop-WDS (see section 2.4.3).
The new WDS references the MA and the previous WDS. The reason for the modification can be recorded in ReasonModificationOrDiscontinuation in the WDS. A new INR value will usually be the starting point for the new schedule; this is recorded in the Comment data element of the WDS.

Modifications relating to the dosage instruction are included in the WDS. Modifications to other treatment policies must be recorded in the MA.

5.2.3.4.1 Modifying a variable dosing regimen by another prescriber

A WDS can be modified by the author of the WDS themselves, but also by another prescriber. The latter then sends the technical stop-WDS to the health professional who created the original WDS.

5.2.3.5 Interrupting the dosing schedule

It may be necessary to temporarily interrupt the dosing schedule, for example due to co-medication or a planned procedure. This can be done in two ways:

• If the intended start of the interruption is known, the dosage for the relevant period in the WDS is adjusted to 0. A new WDS with the zero dosage and a technical stop-WDS are created.

In this case, the MA and TA continue. This makes it clear that only the dosage schedule has been temporarily interrupted; the therapeutic treatment has not been stopped.

• If the exact period during which the interruption is to take place is not known, the interruption must be carried out via a stop-MA. See section 5.2.2.5.

5.2.4 Dispense request

The VV is the logistical building block in a prescription. In the VV, the prescriber describes how much of a medicine should be dispensed.
Section 5.2.5.2 explains how a number of data elements should be filled in in certain situations.

5.2.4.1 Making a dispense request

If a patient needs a (new) supply of medicine, a VV is created. For example, at the start of a treatment with a new medicine. A VV does not have to be created at the same time as an MA is recorded. In the case of an MA with a longer period of use, several VVs are created over time while the MA remains the same.
In a clinical setting, a VV is not necessary: the hospital pharmacist ensures that the medicine is available for the duration of the MA.

5.2.4.1.1 Making a dispense request by another prescriber

A prescriber other than the one who created the MA may issue a VV under this MA. This applies to repeat prescriptions. In that case, in the prescription the MA from the original prescriber is sent along with the VV to the pharmacy.

5.2.5 Directions for recording data in the building blocks medication agreement and dispense request

5.2.5.1 Directions for recording data in the building block medication agreement

This section explains how to fill in certain data elements of the MA in specific situations. All formal source information about the building blocks and their data elements can be found in the Dataset and Scenarios tabs in ART-DECOR.

5.2.5.1.1 MedicationAgreementAdditionalInformation

In the MedicationAgreementAdditionalInformation data element, a prescriber can indicate, among other things, whether or not an MA should take effect immediately. The following values are available for this purpose:

• Immediately on the administration list or in GDS
• After regular prescription processing on the administration list or in GDS
• Per next GDS medication role change on the administration list

If one of these values is entered in the new MA when modifying medication, the technical stop-MA must be assigned the same value. When discontinuing medication, this information can be recorded in the stop-MA.
Section 5.8 provides an overview of all information about GDS medication.

5.2.5.1.2 AgreedMedicine

G-standard and free text
In AgreedMedicine, the medicine to be prescribed is recorded using a code from the G-standard, usually at PRK level.
It is possible to prescribe without such a code, i.e. in free text. However, this is only permitted if no suitable code is available in the G-standard, for example in the case of investigational medicines. This may only be done in exceptional circumstances, partly because medication monitoring cannot be carried out without a G-standard code.

Non-medicines
Non-medicines can also be prescribed at HPK level from the G-standard. Example: inhaler (Aerochamber, HPK 1915185) as an aid for prescribed aerosols. Non-medicines are not applicable for a medication overview or medication monitoring.

Own articles
Own articles (90 million number) can also be recorded in this data element. The condition is that once a 90 million number has been created within an organisation, it may never be changed. During the exchange, the root-oid (unique technical identification of the organisation) in combination with the 90 million number ensures that it is unique in relation to all 90 million numbers from other organisations.
The substances that make up this article are recorded as ingredients in this data element of the MA. At least one ingredient must be recorded, as is the case with magistral preparations.

5.2.5.1.3 InstructionsForUse

Description
Instructions for use are provided electronically in two ways:

• Structured in accordance with the data structure under InstructionsForUse.
• As free text in the Description data element. This contains the complete instructions for use in readable form, for example: 1 piece once a day.
  

The option to display free text is intended for situations in which the receiving system cannot process the structured information properly, so that correct information can still be displayed to the end user.

It is expressly intended that suppliers make as much use as possible of the structured information to generate their own descriptions during implementation. The structured information and the free text must correspond completely. The structured information must not contain anything that is not mentioned in Description.

Additional Instructions
Anticoagulant medication (see section 5.2.3.1)
For medicines with a variable dosing regimen, no DosingInstructions are included in the MA and TA. In AdditionalInstructions, ‘use according to thrombosis service schedule’ is specified.

Medication that must be administered
Additional instructions for administration may be given to the (professional) administrator and/or patient. Examples include:

• Indicate that when stopping a fentanyl patch, the patch must be removed.
• When dosing half a tablet, indicate what should be done with the other half of the tablet.

Such information cannot be recorded in a structured manner. It is recorded in free text in the AdditionalInstruction data element of the MA, TA and/or WDS.

DosingInstructions
‘As needed’ medication
In the case of ‘as needed’ medication, the data element AsNeeded.Condition specifies the situation in which the medication must be taken.

Dosage instruction with an interval of once every 36 hours
A dosage instruction that prescribes the intake of 1 tablet every 36 hours can usually be recorded as 1 MA with a repeat dose of 1 tablet and an interval of 36 hours. However, not all information systems support intervals longer than 24 hours. In that case, an alternative method is required.
A practical solution is to use a three-day RepeatPeriodCyclicalSchedule with different Dosage Instructions for each day:

• day 1 one dose in the morning
• day 2 one dose in the evening
• day 3 no intake or administration.

Repeating this schedule still results in a correct dosing pattern with administration times that are 36 hours apart.

(Recommended) administration times for medication that must be administered
An administration list requires (recommended) administration times and dosage instructions. This information can be recorded in the TA, MA or WDS. Suppliers and prescribers in the outpatient setting do not routinely record the (recommended) administration times and must therefore be alert to the fact that the patient is receiving medication. Flexible (recommended) administration times are assumed as standard.

Sometimes a specific administration time is required, for example due to an interaction with other medication. In addition to stating the exact administration time, the administration list must also clearly indicate that no deviations from this time are permitted. This must be indicated by setting the data element AdministeringSchedule.IsFlexible to ‘no’ in MA, TA and/or WDS.

5.2.5.1.4 PeriodOfUse

If there is a situation-dependent startDateTime or endDateTime, this can be indicated in the data element PeriodOfUse.Condition. This condition makes explicit what the situation dependency entails. Examples of this are:

• ‘Start X days before admission’ – if the exact start time depends on a planned hospital admission.
• ‘Stop X days after holiday’ – if the medication is tapered off after a specific event with an uncertain end date.

See the page Examples uncertainty condition for details on how to use this condition.

5.2.5.1.5 RegistrationDateTime

The RegistrationDateTime indicates the date and time at which the medication building block was recorded and is used to correctly determine the sequence of the building blocks. Further explanation of the RegistrationDateTime can be found in ART-DECOR.

5.2.5.1.6 Comment

In the case of anticoagulant medication, the INR range within which the treatment should take place is recorded in Comment.

5.2.5.1.7 NextPractitioner

This data element can be used to record the health professional who can be contacted if there are any questions about this MA. If the health professional is not known, the relevant healthcare provider may be entered as an alternative. This data element can be used, for example, upon discharge from a clinical situation, see section 5.7.2.3.

It may also be relevant for a prescriber at a GP out-of-hours service (HAP). Examples:

• New MA: The HAP prescriber can enter the name of the regular GP here.
• Modifying existing MA: The HAP prescriber can enter the name of the prescriber of the original MA in the new MA here.
• Stopping existing MA: The GP out-of-hours service prescriber can enter the name of the original prescriber in the stop-MA here.

This makes it clear to the entire chain, even outside GP out-of-hours hours, which prescriber to contact for matters such as handling questions.

5.2.5.2 Directions for recording data in the building block dispense request

This section explains how to fill in certain data elements of the VV in specific situations. All formal source information about the building blocks and their data elements can be found in the Dataset and Scenarios tabs in ART-DECOR.

5.2.5.2.1 Quantity of medicine to be dispensed

In a VV, either the Amount to be dispensed or the ValidityPeriod can be specified. When specifying a ValidityPeriod, the quantity to be dispensed must be clearly derivable from the MA's DosingInstructions.
Please note: the endDateTime in a ValidityPeriod has a different meaning than the endDateTime in the PeriodOfUse of an MA. These may be different.

• ValidityPeriod.endDateTime: date until which the supplier has permission to dispense (and thus provide the patient with sufficient stock for use until that date).
• PeriodOfUse.endDateTime: date on which the patient must stop taking the medication (this may be the same as the ValidityPeriod.endDateTime or may be further in the future).

5.2.5.2.2 Medication not in GDS

In the AdditionalWishes data element of the VV, the prescriber can indicate that a medicine may not be dispensed in GDS.
Section 5.8 provides an overview of all information about GDS medication.

5.2.6 Information exchange during sub-process Prescribe

5.2.6.1 Sending kidney function value along with medication prescription

For some medicines, kidney function is important. The kidney function value then determines the choice and/or dosage of the medicine. For such medicines, the kidney function value is always sent along with the medication prescription. Also, if new results have become available since the previous dispensing, these must be sent again with the medication prescription for the new dispensing.
This kidney function value is recorded in the LaboratoryTestResult building block and sent via the Sending Laboratory Results transaction. See the Lab2Zorg Information Standard. Sending the kidney function value in LaboratoryTestResult separately, without a medication prescription, falls outside the scope of the MP9 information standard.

5.2.6.2 Include height and weight with medication prescription

When sending the medication prescription, the prescriber can also include the patient's height and weight. This can be done, for example, when prescribing for children, or when prescribing medication for which weight (e.g. anticoagulants) or body surface area (e.g. some oncology drugs) are important.

This refers to the height and weight that the prescriber has used to determine the prescription. This may differ from the height or weight that is generally recorded for the patient.

BodyHeight and BodyWeight are separate building blocks and can only be sent in the transactions Sending medication prescription and Sending proposal medication agreement. This information cannot be queried.

5.2.6.3 Information exchange and system roles during sub-process Prescribe

During the Prescribe sub-process, various forms of information exchange may take place. The table below shows which system roles are required for this.

type of information exchange	system role	system role code
The prescriber sends a new MA to the supplier chosen by the patient, accompanied by a VV in the outpatient situation. This instructs the supplier to dispense the medication.	VoorschriftSturend	MP-VOS
The prescriber sends a stop-MA and any new MA to the supplier, accompanied by a VV or not. In doing so, the prescriber instructs the supplier to implement a change in medication policy.
The prescriber sends a new VV with existing MA to the supplier. This instructs the supplier to dispense medication again.
The prescriber sends height and/or weight along with the prescription.
The prescriber sends a kidney function value along with the prescription.	VoorschriftSturend + LabResultaatSturend	MP-VOS + LAB-LRS
The prescriber receives a message when the supplier has processed the prescription.	VoorschriftAfhandelingOntvangend	MP-VAO
The prescriber can receive a VMA and/or VVV from other health professionals and return an AVMA and/or AVVV to the proposer.	VoorstelMedicatieafspraakOntvangend	MP-VMO
	AntwoordVoorstelMedicatieafspraakSturend	MP-AVMS
	VoorstelVerstrekkingsverzoekOntvangend	MP-VVO
	AntwoordVoorstelVerstrekkingsverzoekSturend	MP-AVVS
The prescriber can also send proposal data to another prescriber and receive responses.	VoorstelMedicatieafspraakSturend	MP-VMS
	AntwoordVoorstelMedicatieafspraakOntvangend	MP-AVMO
	VoorstelVerstrekkingsverzoekSturend	MP-VVS
	AntwoordVoorstelVerstrekkingsverzoekOntvangend	MP-AVVO
When queried, the EVS provides the recorded medication data. VV is only provided to the patient.	MedicatieGegevensBeschikbaarstellend	MP-MGB
The prescriber queries the available medication data to perform medication verification and/or evaluate the patient's medication treatment of the patient.	MedicatieGegevensRaadplegend	MP-MGR
The prescriber sends medication data to/receives medication data from another health professional, for example at the patient's request or upon discharge.	MedicatieGegevensSturend	MP-MGS
	MedicatieGegevensOntvangend	MP-MGO
The prescriber sends medication data (MA and WDS) to the thrombosis service if the prescriber has created an initial WDS as a bridging measure.	MedicatieGegevensSturend	MP-MGS
In the event of corrected data, the prescriber assesses who they must actively inform by sending the correct data.
In the event of stopping someone else's MA, the prescriber sends the stop-MA to the prescriber of the stopped MA.

The prescriber uses an electronic prescribing system (EVS). See section 3.2.3 for an overview of the system roles per information system.

5.3 Sub-process Dispense

This section describes the process of dispensing by a supplier. A supplier is a pharmacist or dispensing general practitioner who carries out the dispensing process or under whose responsibility it takes place. To support the implementation of this sub-process, various examples are available on the page Practical examples sub-process Dispense.

5.3.1 Overview sub-process Dispense

5.3.1.1 Process of dispensing in general

Starting the dispensing sub-process
The dispensing sub-process starts when the supplier receives a new medication prescription (MA with or without VV). A request from the patient for repeat medication dispensing, or a signal from the repeat module of the AIS may also be a reason for starting this sub-process. Sometimes a change in the patient's situation is a reason for starting the dispensing sub-process, for example because their medication must now be dispensed in a Medication Distribution System (Geneesmiddel Distributie Systeem, GDS).

The availability of the prescribed medicine and the preference policy are checked. Medication monitoring is also carried out; the details of this are outside the scope of this FO.

Possible actions during dispensing
If the data are sufficient, the supplier processes the medication prescription. This may involve dispensing medication, but this is not always the case. Examples include:

• The medication is stopped with a stop-MA.
• The medication has been changed and the patient still has sufficient stock.
• The patient does not collect the medication.

When processing the medication prescription, the following medication building blocks can be recorded:

• TA to record how the corresponding MA has been filled in specifically.
• MVE to record what has actually been dispensed to the patient.

This is further elaborated per building block in sections 5.3.2 and 5.3.3.
Section 5.3.4 contains instructions for implementing the MA and VV building blocks in specific situations.
Sometimes a supplier will want to contact the prescriber. For example:

• A new VV is required.
• There are questions about the MA received.
• After a medication monitoring signal.

In such cases, the supplier can send a VMA or VVV to the prescriber. In it, the supplier makes a specific proposal for an MA or VV, stating the reason for that proposal. See section 5.6 for further information about these proposal data.

Exchanging data
The supplier sends the TA and, if a dispensing has also taken place, the MVE to the prescriber. If the Author of the VV is a different health professional than the Prescriber in the MA, the TA and, if applicable, the MVE are sent to that Author. The recorded data is also made available.
The transfer of information is discussed further in section 5.3.5.

5.3.1.2 Some specific situations

Medication process in the clinical situation
The medication process in the clinical situation is dealt with separately in section 5.7.

Medication on the administration list
For some patients, medication is listed on an administration list (administration patients). This medication can be administered by an administrator or by the patient themselves. The data required to generate an administration list can be recorded by the prescriber in MA or WDS and/or by the supplier in the TA (see section 5.4.2).

5.3.2 Administration agreement

With the TA the MA is specified in concrete terms. A TA always has a reference to the corresponding MA (if available), in the data element RelationMedicationAgreement. A new TA is not always necessary, for example in the case of repeat dispensing under a current MA.
The TA is filled in based on factors such as availability, preference policy, or the wishes of the patient or prescriber. This can result, for example, in a product with a different strength and an adjusted dosing frequency. A different strength means a different PRK. Since the TA falls under the same MBH as the MA, building blocks with different PRKs can occur within 1 MBH.

In general terms, a supplier can create a new TA, or continue, stop, change or temporarily interrupt an existing TA. This is explained in sections 5.3.2.1 to 5.3.2.5.
Section 5.3.4.1 explains how a number of data elements should be completed in certain situations.

5.3.2.1 Initial administration agreement

A new TA is always created for a new MA. An initial TA in an MBH will usually be created in response to a new MA. However, an initial TA can also be created without an associated MA. For example, if a patient purchases a self-care product at the pharmacy, the supplier may choose to record a TA and thereby start a new MBH. This enables medication monitoring and the self-care product can then also be included on an administration list (see section 5.4).

Just like the corresponding MA, a TA may start in the future. This TTA has a startDateTime that is later than the date on which the agreement was made.

5.3.2.2 Continuing an administration agreement

If the existing MA and TA suffice to dispense new medication, the TA does not need to be adjusted.

5.3.2.3 Stopping an administration agreement

A TA in which an endDateTime has already been specified, for example for a course of treatment, will automatically stop on that date. No stop-TA is required in this case.
A stop-MA for permanently discontinuing medication leads to a stop-TA within the same MBH with stop type 'discontinued'. This prevents further dispensing of the medication.

The stop-TA contains the following new data:

data-element in dataset	uitleg
endDateTime	The date on which the TA ends. This end date can also be in the future.
Supplier	Name of the supplier creating the stop-MA
RegistrationDateTime	Date and time on which the stop-TA is recorded.
AdministrationAgreementStopType	‘discontinued’
RelationAdministrationAgreement	Reference to the TA being stopped. A stop-TA must include this reference, unless there is no TA available in the MBH to refer to. If the MBH only contains MGB(s), the prescriber must be able to stop these with a stop-TA without a RelationAdministrationAgreement. In that case, the stop-TA will not get a reference to an MGB either.
RelationMedicationAgreement	Reference to the stop-MA giving rise to this stop-TA.
AdministrationAgreementReasonModificationOrDiscontinuation	Reason for stopping the TA.

From the referenced TA the remaining available information must be copied, including at least the following elements:

data-element in dataset	uitleg
startDateTime	The original start date.
MedicineForAdministrationAgreement	The agreed-upon medicine. In the case of magistral preparations or ingredients, 90 million numbers do not need to be copied.
InstructionsForUse	The original instructions for use. The AdditionalInstructions data element does not need to be included, as the method of use is no longer relevant in a stop-TA.

The TA can be stopped immediately with an endDateTime today, or be stopped with an endDateTime in the future.

5.3.2.3.1 Stopping an administration agreement by another supplier

A TA can be stopped by the supplier themselves, but also by another supplier. When a supplier stops a medication, they create a stop-TA. This is also the case when stopping a TA from another supplier. The stop-TA is sent to the health professional who created the original TA. Their XIS system informs this health professional that there is a new change within the MBH.

5.3.2.3.2 Canceling a future administration agreement

Stopping a TA with a startDateTime in the future (TTA) is called canceling. The TTA is canceled by recording a cancelation-TTA. This is a stop-TTA with the stop type ‘canceled’. The cancelation-TTA shows that the patient has never used the medication in question according to that TTA.

The cancelation-TTA works the same way as the stop-TA described above, but with two differences:

• The stop type is ‘canceled’ instead of ‘discontinued’.
• The startDateTime and endDateTime of the cancelation-TTA are the same.

5.3.2.4 Modifying an administration agreement

It may be necessary to change the TA, for example due to a change in the product range or in the preference policy. Unlike the MA, in the case of a TA a modification of the product at PRK level does not lead to a different MBH.

Modifying a TA with an unmodified MA
Modifying a TA with an unmodified MA is done by creating a technical stop-TA with stop type ‘discontinued’ and a new TA with the modification within the same MBH. Both have a relationship to the original TA and the unmodified MA. The technical stop-TA has an endDateTime equal to the startDateTime of the new MA with the modification (see section 2.4.3). In the new TA, the reason for the change can be recorded in AdministrationAgreementReasonModificationOrDiscontinuation.

A modification can take effect immediately or can be scheduled with a startDateTime in the future. If the change is implemented in a future TA, a technical cancelation-TTA is created and a new TTA with the change.

The technical stop-TA and new TA are created simultaneously and therefore have the same RegistrationDateTime (see section 2.4.3.1). They are sent and made available simultaneously. When queried, they are also provided simultaneously. The same applies to the technical cancelation-TTA and new TTA.

Modifying a TA as a result of a modification of the MA
A TA may also need to be changed as a result of a modification of the associated MA. In that case, a technical stop MA and a new MA are created. This results in a technical stop-TA with a reference to the original TA and to the technical stop-MA. A new TA is created with a reference to the new MA, without a relationship to the original TA.
Modifying a TTA as a result of a modification of a future MA works in the same way.

action	leads to	with reference to
modification in TA
technical stop-TA	n.a.	original TA
new TA	n.a.	original TA (unmodified) MA
modification in TTA
technical cancelation-TTA	n.v.t.	original TTA
nieuwe TTA	n.v.t.	original TTA (unmodified) MA
modification in MA
technical stop-MA	technical stop-TA	original TA technical stop-MA
new MA	new TA	new MA
modification in TMA
technical cancelation-TMA	technical cancelation-TTA	original TTA technical cancelation-TMA
new TMA	new TTA	new TMA

5.3.2.4.1 Correcting an administration agreement

The same rules apply to correcting a TA as to correcting an MA (see section 5.2.2.4.1):
If the incorrect TA has not yet been shared with other health professionals, the supplier can adjust or delete it in their own information system. If the incorrect agreement has already been shared with other health professionals, it must be corrected. There are two new TAs are created within the same MBH:

• A new TA with the correct data, ‘incorrect registration of medication’ in AdministrationAgreementReasonModificationOrDiscontinuation and a reference to the TA to be corrected and the unmodified MA.
• A technical stop-TA with stop type ‘discontinued’ and a reference to the TA to be corrected in RelationAdministrationAgreement.

Correcting a future TA is done in the same way, with a technical cancelation-TTA plus a new TTA.

5.3.2.5 Temporarily interrupting and resuming an administration agreement

Interrupting a TA with an unmodified MA
Interrupting a TA with unmodified MA is done by recording two new TAs within the same MBH:

• A stop-TA with stop type ‘interrupted’, reference to the TA to be interrupted in RelationAdministrationAgreement and reason for interruption in AdministrationAgreementReasonModificationOrDiscontinuation.
• Upon resumption, a new TA with a relationship to the unmodified MA and to the original TA.

This may be relevant in the case of generic substitution during admission (see section 5.7.2.2.2).

Interrupting a TA as a result of an interrupt-MA
Interrupting a TA as a result of an interrupt-MA is done in the same way. However, the new TA has a relationship to the new resumption-MA, without a relationship to the original TA.

5.3.3 Medication dispense

The medication can be dispensed if a new or existing TA has been recorded for it. Medication may only be dispensed if there is a valid MA for it.
In an outpatient situation, a new or existing VV is also required. The MVE then contains a reference to that VV. In a clinical situation, an MA is sufficient.
Upon delivery, an MVE is recorded and made available.

5.3.3.1 Medication dispense in the case of GDS medication

It is desirable that a prescriber can determine whether changes in medication can wait until the next medication roll change. To do so, it must be clear when that roll change will take place.
To this end, it has been agreed that the DurationOfUse of an MVE will be equal to the duration of the medication roll. With a weekly medication roll, the MVE has a DurationOfUse of 7 days. For a fortnightly medication roll, the DurationOfUse is 14 days. In combination with the start of the MVE (in MedicationDispenseDateTime), it can easily be deduced what the last day of the roll will be.
This is particularly important for medication with a non-daily intake schedule. It prevents medication from being repeated too early and provides a clear starting point for roll changes. Examples:

• Medication with an intake schedule of 3 times a week, on Monday - Wednesday - Friday.
• Medication with a dosing schedule of once every two weeks. With a weekly medication roll, the roll will contain the medication one week and not the next.

5.3.4 Directions for recording data in the building blocks administration agreement and medication dispense

5.3.4.1 Directions for recording data in the building block administration agreement

This section explains how to fill in certain data elements of the TA in specific situations. All formal source information about the building blocks and their data elements can be found in the Dataset and Scenarios tabs in ART-DECOR.

5.3.4.1.1 DistributionForm

The DistributionForm data element of the TA and MVE can be used to indicate whether GDS medication is involved.
Section 5.8 provides an overview of all information about GDS medication.

5.3.4.1.2 InstructionsForUse

Description
Instructions for use are provided electronically in two ways:

• Structured in accordance with the data structure under InstructionsForUse.
• As free text in the Description data element. This contains the complete instructions for use in readable form, for example: 1 piece once a day.
  

The option to display free text is intended for situations in which the receiving system cannot process the structured information properly, so that correct information can still be displayed to the end user.

It is expressly intended that suppliers make as much use as possible of the structured information to generate their own descriptions during implementation. The structured information and the free text must correspond completely. The structured information must not contain anything that is not mentioned in Description.

Additional Instructions
Anticoagulant medication (see section 5.2.3.1)
For medicines with a variable dosing regimen, no DosingInstructions are included in the MA and TA. In AdditionalInstructions, ‘use according to thrombosis service schedule’ is specified.

Medication that must be administered
Additional instructions for administration may be given to the (professional) administrator and/or patient. Examples include:

• Indicate that when stopping a fentanyl patch, the patch must be removed.
• When dosing half a tablet, indicate what should be done with the other half of the tablet.

Such information cannot be recorded in a structured manner. It is recorded in free text in the AdditionalInstruction data element of the MA, TA and/or WDS.

DosingInstructions
‘As needed’ medication
In the case of ‘as needed’ medication, the data element AsNeeded.Condition specifies the situation in which the medication must be taken.

Dosage instruction with an interval of once every 36 hours
A dosage instruction that prescribes the intake of 1 tablet every 36 hours can usually be recorded as 1 MA with a Dose of 1 tablet and an Interval of 36 hours. However, not all information systems support intervals longer than 24 hours. In that case, an alternative method is required.
A practical solution is to use a three-day RepeatPeriodCyclicalSchedule with different DosingInstructions for each day:

• day 1 one dose in the morning
• day 2 one dose in the evening
• day 3 no intake or administration.

Repeating this schedule still results in a correct dosing pattern with administration times that are 36 hours apart.

(Recommended) administration times for medication that must be administered
An administration list requires (recommended) administration times and dosage instructions. This information can be recorded in the TA, MA or WDS. Suppliers and prescribers in the outpatient setting do not routinely record the (recommended) administration times and must therefore be alert to the fact that the patient is receiving medication. Flexible (recommended) administration times are assumed as standard.

Sometimes a specific administration time is required, for example due to an interaction with other medication. In addition to stating the exact administration time, the administration list must also clearly indicate that no deviations from this time are permitted. This must be indicated by setting the data element AdministeringSchedule.IsFlexible to ‘no’ in MA, TA and/or WDS.

Some dosing instructions cannot be easily translated into intake times. Examples include:

• Twice a week
• Once a month
• Twice a year

It is essential, particularly for patients having their medication administered, that the planned administration times are derived identically. For patients receiving medication, the use of the data element RepeatPeriodCyclicalSchedule is therefore mandatory in the case of dosing instructions that cannot be clearly derived. This makes it possible to always arrive at the same administration times, regardless of the information system used. For detailed examples with the data element RepeatPeriodCyclicalSchedule, see the page dosage examples.

5.3.4.1.3 PeriodOfUse

The intended duration of the medication is specified in the PeriodOfUse:

• Medication for an indefinite period: only startDateTime is entered, without duration or endDateTime
• Medication for a specific period: 2 of the 3 data elements must be entered. This also applies to medication for single use.
• If an endDateTime is specified, the time must always be provided. This is to avoid confusion between ‘until’ and ‘up to and including’. In the case of an ‘up to and including’ date (i.e. a whole day), the time 23:59:59 applies.
  

If there is a situation-dependent startDateTime or endDateTime, this can be indicated in the data element PeriodOfUse.Condition. This condition makes explicit what the situation dependency entails. Examples of this are:

• ‘Start X days before admission’ – if the exact start time depends on a planned hospital admission.
• ‘Stop X days after holiday’ – if the medication is tapered off after a specific event with an uncertain end date.

See the page Examples uncertainty condition for details on how to use this condition.

The startDateTime of a TA may differ from that in the MA. Examples:

• The patient does not collect the medication until several days after the startDateTime in the MA.
• Starting or modifying GDS medication.

The same applies to the endDateTime.

If medication is to be supplied in GDS or if changes are made to GDS medication, the startDateTime of the new GDS TA is the same as the starting date of the next medication roll.

If the change must take effect before a planned roll change, the time until the medication roll change must be bridged. This can be done by supplying the medication separately during that period or by changing the medication roll immediately.

5.3.4.1.4 MedicineForAdministrationAgreement

Whereas in the MA the medicine is usually prescribed at PRK level, in the TA it is listed at HPK level. This level contains additional medication monitoring data relating to excipients. The TA then lists the specific commercial product that has been or will be supplied.

5.3.4.1.5 RegistrationDateTime

The RegistrationDateTime indicates the date and time at which the medication building block was recorded and is used to correctly determine the sequence of the building blocks. Further explanation of the RegistrationDateTime can be found in ART-DECOR.

5.3.4.2 Directions for recording data in the building block medication dispense

This section explains how to fill in certain data elements of the MVE in specific situations. All formal source information about the building blocks and their data elements can be found in the Dataset and Scenarios tabs in ART-DECOR.

5.3.4.2.1 RequestDate and MedicationDispenseDateTime

In an MVE, both the RequestDate and the MedicationDispenseDateTime can be recorded.

• RequestDate: date/time at which the supplier records a planned dispensing.
• MedicationDispenseDateTime: date/time at which the actual handing out of the medication took place.

Both dates are the same if the VV is processed immediately and the patient collects the medication on the same day. If the patient collects the medication at a later time than the VV was processed, these dates will differ. If the medication is not collected, no dispensing takes place and no MVE is recorded.

When using a dispensing machine, the MedicationDispenseDateTime is the date/time at which the patient collects the medication from the machine. If this date/time is not available in the AIS, the date/time at which the medication is placed in the dispensing machine may be used instead.

If multiple dispensings are made under the same VV, each dispensing has its own RequestDate and, of course, its own MedicationDispenseDateTime.

5.3.4.2.2 DistributionForm

The DistributionForm data element of the TA and MVE can be used to indicate whether GDS medication is involved.
Section 5.8 provides an overview of all information about GDS medication.

5.3.5 Information transfer and system roles during sub-process Dispense

During the Dispense sub-process, various forms of information exchange may take place. The table below shows which system roles are required for this.

type of information exchange	system role	system role code
The supplier receives a new MA, a stop-MA, or a technical stop-MA with a modified new MA from the prescriber. This may be accompanied by kidney function values, height or weight.	VoorschriftOntvangend	MP-VOO
	LabresultaatOntvangendSysteem	LAB-LRO
The supplier informs the prescriber about the processing of the medication prescription by sending the TA and/or stop-TA, with or without MVE.	VoorschriftAfhandelingSturend	MP-VAS
The supplier can send a VMA and/or VVV to the prescriber and receive an AVMA and/or AVVV.	VoorstelMedicatieafspraakSturend	MP-VMS
	AntwoordVoorstelMedicatieafspraakOntvangend	MP-AVMO
	VoorstelVerstrekkingsverzoekSturend	MP-VVS
	AntwoordVoorstelVerstrekkingsverzoekOntvangend	MP-AVVO
When queried, the AIS provides the recorded medication data.	MedicatieGegevensBeschikbaarstellend	MP-MGB
The supplier queries the available medication data to perform medication verification.	MedicatieGegevensRaadplegend	MP-MGR
Where appropriate, the supplier can send medication data to or receive medication data from other health professionals.	MedicatieGegevensSturend	MP-MGS
	MedicatieGegevensOntvangend	MP-MGO

The supplier uses a pharmacy information system (AIS). See section 3.2.3 for an overview of the system roles per information system.

5.4 Sub-process Administer

NB: In this FD and the dataset, the functionalities in the Administer sub-process are published as a beta version (see section 1.5.4).

This section describes the process of administering medication. Medication can be administered without an administration list. Section 5.4.1.2 provides several examples of this. However, this section focuses on administering medication based on an administration list.
There are various situations in which medication must be administered, for example in a hospital, a nursing home or in home care. Medication can be administered by professional administrators such as doctors, nurses and carers. It is also possible that the patient or their informal carer administer the medication, but need an administration list to do so. In this FD the general term 'administrator' is used.

To support the implementation of this sub-process, various examples are available on the page Practical examples sub-process Administer.

5.4.1 Overview sub-process Administer

5.4.1.1 Administering medication using an administration list

In principle, medication is administered using an administration list. When starting with an administration list, the prescriber, supplier, administrator and/or patient agree on which medication will be included on the administration list and what the intended (target) administration times are. This process may vary depending on the situation and the healthcare organisation.

Prior to administration, the administrator must have an administration list with the relevant medication details for the patient. Section 5.4.2 explains the content and preparation of administration lists.

The administrator checks the medication available and the details on the administration list and, if necessary, prepares the medication for administration. The administrator administers the medication and records the administration in the MTD building block. Section 5.4.3 describes how the recording should take place in different situations.

The administrator can send a VMA or VVV to the prescriber to make a proposal regarding a patient's medication. See section 5.6 for the handling of these proposal data.

At the end of the process, the recorded data are exchanged. This allows a health professional to check which medication has been administered to a patient. This can be important, for example, when a patient is transferred to another department or institution. The exchange of information is discussed further in section 5.4.4.

5.4.1.2 Administering medication without administration list

Sometimes medication is administered without it being on an administration list. Examples include:

• A modification of the MA has been communicated verbally, but has not yet been recorded.
• Occasional administration by the general practitioner, for example of a tetanus injection or anaesthetic.
• Administration of medication in emergency situations. In this case, too, the administrator records an MTD after administration. This MTD can then be the first building block with which a new MBH is started. After this, an MA and TA should still be created within this MBH.

5.4.2 Administration lists

In order to account for which medication the administrator has administered to the patient, it must be stated on an administration list (apart from the exceptional situations in section 5.4.1). An administration list is a list of all medicines that have been prescribed to a patient and that must be administered to this patient. In principle, self-care medication is not included. Self-care medication can only be included on the administration list if a prescriber has established a prescribing policy for this and has created an MA for this purpose, and/or if a supplier has created a TA for this purpose.

5.4.2.1 Explanation of some data on administration lists

The sections below explain some data that may be important to include in an administration list. However, the exact information required for administration registration depends on the context of the administrator. The content of an administration list and the way in which an eTDR presents it can therefore differ depending on this context.

5.4.2.1.1 Medication in GDS

The administration list must clearly indicate whether a medication is dispensed in a GDS. The DistributionForm data element of the TA and the MVE can be used to indicate whether GDS medication is concerned.

5.4.2.1.2 Additional guidelines for administering medication

Additional instructions for administering medication can be provided to the (professional) administrator and/or patient. Examples include:

• Indicating that the patch should be removed when discontinuing use of a fentanyl patch.
• Indicating what should be done with the other half of a tablet when dosing half a tablet.

Such data cannot be recorded in a structured format. They are recorded in free text in the AdditionalInstructions data element of the MA, TA, and/or the WDS.

5.4.2.1.3 (Recommended) administration times

An administration list requires (recommended) administration times and dosage instructions. This information can be recorded in the TA, MA or WDS. Suppliers and prescribers in the outpatient setting do not routinely record the (recommended) administration times and must therefore be alert to the fact that the patient is receiving medication. (Recommended) administration times are assumed to be flexible unless specified otherwise.
If these data are missing, the administrator should check this with the prescriber or supplier.

Flexible (recommended) administration time
If the (recommended) administration time of a medication is flexible, it will usually be determined based on the administration times of other medications and the logistical rounds of the administrator.

Exact administration time
Sometimes a specific administration time is required, for example due to an interaction with other medication. In addition to stating the exact administration time, the administration list must also clearly indicate that no deviations from this time are permitted. This must be indicated by setting the data element AdministeringSchedule.IsFlexible to ‘no’ in MA, TA and/or WDS.

(Recommended) administration time in case of ‘as needed’ medication
For ‘as needed’ medication, the administration time is not normally known in advance. However, (recommended) administration times may be provided if there is a reason to do so, for example in the case of sleep medication.

RepeatPeriodCyclicalSchedule mandatory for certain dosing instructions
Some dosing instructions cannot be easily translated into intake times. Examples include:

• Twice a week
• Once a month
• Twice a year

It is essential, particularly for patients having their medication administered, that the planned administration times are derived identically. For those patients, the use of the data element RepeatPeriodCyclicalSchedule is therefore mandatory in the case of dosing instructions that cannot be clearly derived. This makes it possible to always arrive at the same administration times, regardless of the information system used.

For detailed examples with the data element RepeatPeriodCyclicalSchedule, see the dosage examples page.

5.4.2.1.4 InjectionPatchSite

For some medications, it is necessary to know where the last injection was given or where the last patch was applied. This is recorded after each administration in the InjectionPatchSite data element in the MTD.

5.4.2.2 Drawing up the administration list

To ensure that medication is administered safely and correctly, an administration list must show the relevant medication details for that administration moment. Prescribers, suppliers and administrators are responsible for providing the medication data necessary for compiling an administration list in a timely manner.

5.4.2.2.1 Medication building blocks used in the administration list

An administration list is compiled based on all MAs, TAs and WDSs available at the time the medication is to be administered. Data such as (recommended) administration times and instructions for use are recorded in these building blocks. Recently registered MTDs are also important, including MTDs for changed or recently discontinued medication. These MTDs provide insight into how previous administrations went, for example with regard to the InjectionPatchSite. The administrator's information system (eTDR) retrieves the data for an administration list using the Query medication data transaction.

5.4.2.2.2 Which data from which building block?

Information about the InjectionPatchSite can be found in the MTD. For the other data, the following table shows in which data element of which building block they occur.

Table I Medication data items in data elements of MA, TA and WDS

Nr	Data item	Medication building block
		Data element
		MA	TA	WDS
1	Medicine	AgreedMedicine	MedicineForAdministrationAgreement	AgreedMedicine
2	Prescriber	Prescriber	-	-
3	Supplier	-	Supplier	-
4	Author of the WDS	-	-	Author
5	Start date	PeriodOfUse.startDateTime
6	End date/duration	PeriodOfUse.endDateTime, PeriodOfUse.duration
7	InstructionsForUse:
	Description	InstructionsForUse.Description
	Route of administration	InstructionsForUse.RouteOfAdministration
	Additional instructions	InstructionsForUse.AdditionalInstructions
	Dose	InstructionsForUse.DosingInstructions.Dosage.Dose
	Administration time	InstructionsForUse.DosingInstructions.Dosage.AdministeringSchedule.AdministrationTime
	Administration speed	InstructionsForUse.DosingInstructions.Dosage.AdministeringSpeed
	Duration of administration	InstructionsForUse.DosingInstructions.Dosage.DurationOfAdministration
8	Comment	Comment, MedicationAgreementAdditionalInformation	Comment, AdministrationAgreementAdditionalInformation	Comment

Table I shows that various data items can appear in different building blocks. Most of the data required for the administration list are usually taken from the TA, as the TA fills in the MA in concrete terms. However, it may happen that only an MA is available. For example, if the supplier has not yet processed the MA. Whether data from this MA may be extracted for the administration list depends on the content of the AdditionalInformation data element (see section 5.2.5.1.1). This may concern new, modified or discontinued MAs. The following rules have been established for this purpose:

• Data element AdditionalInformation is empty or contains ‘Directly on administration list or in GDS’: the data from this MA are used to draw up the administration list.
• Data element AdditionalInformation contains ‘After regular prescription processing on administration list or in GDS’ or ‘Per next GDS role change on administration list’: the data in this MA may not be used to draw up the administration list. Until the MA has been processed by the supplier in a TA, the existing agreements remain applicable. After processing the MA, the TA is leading for the required data on the administration list.

Exception: If prescribing, dispensing and administering are recorded in a single XIS, the content of AdditionalInformation is irrelevant. The MA is then used in every situation for drawing up the administration list. This may be the case in hospitals, for example.

A WDS, too, influences which data should be extracted from which building block.

The following table indicates for various situations which building block is leading for retrieving data for the administration list for a specific medicine. The numbers refer to the data items in the previous table. This is further elaborated for various situations on the Examples of application of building blocks on the administration list page.

Table II Which building block is leading for retrieving data for use on the administration list

Situation			MA	TA	WDS
A) Only MA available: supplier has not yet processed the MA	MedicationAgreementAdditionalInformation in MA is empty or contains Directly on administration list or in GDS	New MA	Leading building block for data items #1, 5, 6, 7, 8 Prescriber data #2	–	–
		Modification or discontinuation of MA	Leading building block for data items #1, 5, 6, 7, 8 Prescriber data #2	–	–
	MedicationAgreementAdditionalInformation in MA contains After regular prescription processing on administration list or in GDS or Per next GDS medication roll change on administration list	New MA	–	–	–
		Modification or discontinuation of MA	Prescriber data #2	Existing TA: Leading building block for data items #1, 5, 6, 7, 8 Supplier data #3	–
B) MA and TA available	–	–	Prescriber data #2	Leading building block for data items #1, 5, 6, 7, 8 Supplier data #3	–
C) MA, TA and WDS available	–	–	Prescriber data #2	Leading building block for data item #1 Supplier data #3	Leading building block for data items #4, 5, 6, 7, 8

5.4.3 Directions for recording data in the building block medication administration

After administering medication, the administrator records the administration data in the MTD building block. Any deviations from the originally intended administration (e.g. changed dosage, patient refusal, swallowing problems, side effects, etc.) are also recorded here. This section describes some specific situations.

5.4.3.1 Administration deviates from administration list

The administrator may, in consultation and within set frameworks, deviate from what has been recorded by the prescriber and/or supplier in the MA and/or TA. For example, in the date or time of administration, or in the amount administered. The reason for this is recorded in the data element MedicationAdministrationReasonForDeviation in the MTD.

5.4.3.2 Administration did not take place

If it is not possible to administer a medication, this can be recorded in the MTD by entering 0 in the AdministeredAmount, possibly with an explanation in the Comment data element. If it is not the intention to administer the medication at a later time, this can also be indicated in that data element.

5.4.3.3 Postponing an administration

If administration is not successful, it can be decided in consultation with the prescriber or supplier to administer the medicine at a later time, provided this falls within the agreements made regarding flexible administration times. An initial MTD with an AdministeredAmount of 0 can also be recorded, and a new MTD if the medication is administered later.

5.4.3.4 Correcting an MTD that has already been recorded

It may happen that an MTD that has already been recorded needs to be corrected because the administration took place differently than was recorded. If the MTD has not yet been made available, the administrator can adjust or delete it in their own information system. If the MTD has already been shared with other health professionals, corrections are made by recording and making available additional MTDs. The data element AdministeredAmount can be used for this. The value of this data element can be negative in a corrective MTD. In case of corrections, the final quantity administered is then equal to the sum of the AdministeredAmount in all recorded MTDs. In MedicationAdministrationReasonForDeviation the reason for the correction can be indicated, for example 'incorrect registration of medication' or ‘drug spat out by patient'.

5.4.4 Information exchange and system roles during sub-process Administer

During the Administer sub-process, various forms of information exchange may take place. The table below shows which system roles are required for this.

type of information exchange	system role	system role code
The administrator queries a patient’s available medication data for drawing up the administration list	MedicatieGegevensRaadplegend	MP-MGR
When queried, the eTDR provides the recorded medication data.	MedicatieGegevensBeschikbaarstellend	MP-MGB
Where appropriate, the administrator can send medication data to or receive medication data from other health professionals.	MedicatieGegevensSturend	MP-MGS
	MedicatieGegevensOntvangend	MP-MGO
The administrator can send a VMA and/or VVV to the prescriber and receive an AVMA and/or AVVV.	VoorstelMedicatieafspraakSturend	MP-VMS
	AntwoordVoorstelMedicatieafspraakOntvangend	MP-AVMO
	VoorstelVerstrekkingsverzoekSturend	MP-VVS
	AntwoordVoorstelVerstrekkingsverzoekOntvangend	MP-AVVO

When administering medication, an electronic administration registration system (eTDR) is used . See section 3.2.3 for an overview of the system roles per information system.

5.5 Sub-process Use

This section describes the process of using medication and the recording of this use by a patient or their representative. Hereafter only the word ‘patient’ will be used.
Data about the patient's medication use can also be recorded by health professionals, for example during medication verification (see section 5.1).

To support the implementation of this sub-process, various examples are available on the Practical examples sub-process Use page.

5.5.1 Overview sub-process Use

The patient uses prescribed medication and/or self-care medication. This may also concern medication from abroad. This use may be in accordance with the agreements in MA and/or TA and/or WDS (for prescription medication), or in accordance with the instructions for use in the package (for self-care medication). The patient can also deviate from this.

If a new or modified MA or VV is required, a patient can contact the prescriber by sending a VMA or VVV. See section 5.2.5.1 for further information about proposal data.

Patients with a PGO or patient portal can view their medication data using the Query medication data transaction. They can also record their medication use in the medication building block MGB. The patient can record, among other things, for each medicine used:

• Is the medicine used or not?
• Is it used according to agreement (in MA/TA/WDS)?
• If not, in what way does the patient deviatee from the agreement?
• If applicable, the reason for deviation or discontinuation, for example side effects.

The recording of MGBs by the patient is optional. Information about their medication use in the form of MGBs recorded by the patient will therefore not always be available.

For patients who need to have their medication administered, the administration data are recorded by the administrator in an MTD, see section 5.4. However, some of these patients do take the medication themselves. If they record this in an MGB, it may differ from the data in the MTD.

The recorded data (MGB) are made available to the relevant health professionals.

5.5.2 Directions for recording data in the building block medication use

In the context of this section, this concerns patients who themselves record data about their use. The table below shows how the data elements in the MGB building block should be filled in in various situations.

Situation	Use Indicator	AsAgreed Indicator	MedicationUse StopType	PeriodOfUse (fill in a maximum of 2 out of 3)			DosingInstructions
				startDateTime	Duration	endDateTime
Medication is/will be used in PeriodOfUse
This is as agreed	yes	yes	leave empty	fill in in accordance with MA or TA			fill in in accordance with MA or TA
				date/time when medication use started or will start	(intended) duration of medication use	date/time when medication use is or will be discontinued
This is not as agreed	yes	no	leave empty	date/time when deviating medication use started or will start	(intended) duration of non-compliant medication use	date/time when non-compliant medication use is or will be discontinued	the actual dosage used must be entered
There is no agreement (self-care medication) / unknown whether this is as agreed	yes	leave empty	leave empty	date/time when medication use started or will start	(intended) duration of medication use	date/time when medication is or will be discontinued	the dosage agreed upon by the patient must be entered
Medication is not/will not be used in PeriodOfUse
This is as agreed	no	yes	leave empty or fill in in accordance with stop-agreement	date/time from which medication use will be discontinued or suspended	n/a in case of discontinuing (intended) duration of suspension of medication use	n/a in case of discontinuing date/time when medication use is or will be resumed	leave empty, there is no dosage
This is not as agreed	no	no	discontinued / suspended	date/time from which use will be discontinued or suspended	n/a in case of discontinuing (intended) duration of suspension of medication use	n/a in case of discontinuing date/time when medication use is or will be resumed	leave empty, there is no dosage
There is no agreement (self-care medication) / unknown whether this is as agreed	no	leave empty	discontinued / suspended	date/time from which medication use will be discontinued or suspended	n/a in case of discontinuing (intended) duration of suspension of medication use	n/a in case of discontinuing date/time when medication use is or will be resumed	leave empty, there is no dosage

See also the Implementation manual for filling in building blocks during medication verification for more explanation of how this building block is filled in during medication verification.

5.5.3 Information exchange and system roles during sub-process Use

During the Use sub-process, various forms of information exchange may take place. The table below shows which system roles are required for this.

type of information exchange	System role	system role code
When queried, the patient’s information system provides the recorded medication data.	MedicatieGegevensBeschikbaarstellend	MP-MGB
The patient can query their medication data.	MedicatieGegevensRaadplegend	MP-MGR
The patient can send a VMA and/or VVV to the prescriber and receive an AVMA and/or AVVV.	VoorstelMedicatieafspraakSturend	MP-VMS
	AntwoordVoorstelMedicatieafspraakOntvangend	MP-AVMO
	VoorstelVerstrekkingsverzoekSturend	MP-VVS
	AntwoordVoorstelVerstrekkingsverzoekOntvangend	MP-AVVO

The patient uses a PGO or a patient portal. See section 3.2.3 for an overview of the system roles per information system.

5.6 Proposal data

NB: In this FD and the dataset, the proposal data are published as a beta version (see section 1.5.4).

A prescriber may receive a proposal from a supplier, other health professional (including other prescribers), or from the patient regarding their pharmaceutical treatment. The following proposal data are available within MP9:

• Proposal medication agreement (VMA) for proposals regarding the MA, with an optional reason for this proposal.
• Reply proposal medication agreement (AVMA) for answering the VMA.
• Proposal dispense request (VVV) for proposals relating to the VV, with optionally a reason for this proposal.
• Reply proposal dispense request (AVVV), for answering the VVV.

In response to a proposal, the prescriber always sends an answer to the proposer. If the proposal leads to a new prescription, this will be sent to the supplier.

5.6.1 Proposal medication agreement

A proposer can send a VMA to the prescriber. This may concern a proposal to modify, stop or continue an existing MA, or to start a new MA. A prescriber who receives a VMA selects one of three possible responses:

• ‘Accepted’: the prescriber fully agrees with the proposal that has been made. In that case, the following data will be copied exactly from the VMA into the new MA:

data element
PeriodOfUse
AgreedMedicine
MedicationAgreementStopType
ReasonModificationOrDiscontinuation
PrescriptionReason
InstructionsForUse, with the exception of the description. An XIS can choose to copy the description upon querying, or generate it itself from the structured fields.
AdditionalInformation
Comment

• ‘Accepted with changes’: The prescriber agrees to the proposed pharmaceutical product but makes a therapeutic change in the MA compared to the VMA.
• ‘Rejected’: If the prescriber does not agree with the PRK of the proposed pharmaceutical product, the proposal is considered 'rejected' and an MA with another pharmaceutical product is made. In addition, the entire proposal can be rejected and no MA is made. In both cases an explanation must be given.

5.6.2 Proposal dispense request

A proposer can send a VVV to the prescriber. This concerns a request for a repeat prescription. A prescriber who receives a VVV selects one of three possible responses:

• ‘Accepted’: the prescriber fully agrees with the proposal that has been made. In that case, the following data will be copied exactly from the VVV into the new VV:

data element
MedicineToBeDispensed
Amount
NumberOfRefills
ValidityPeriod
DispenseLocation
AdditionalWishes
FinancialIndicationCode
Comment
RelationMedicationAgreement

• ‘Accepted with changes’: The prescriber agrees to the proposed pharmaceutical product but makes another change in the VV compared to the VVV.
• ‘Rejected’: If the prescriber does not agree with the PRK of the proposed pharmaceutical product, the proposal is considered 'rejected'. A VV with a different pharmaceutical product follows.

Another possibility is that the IntendedSupplier is changed. This, too, is seen as a rejection. The supplier making the proposal will receive the rejection if no dispensing is required. Finally, the prescriber can reject the VVV completely. An explanation must be given in all these cases.

5.6.3 Dispensing before approval by prescriber

When the prescriber issues a prescription based on the VMA or VVV, it is sent to the supplier. The supplier then processes the prescription. In exceptional cases, a supplier may dispense before the prescriber has responded to the VMA. This is done on the basis of professional judgement, regional agreements or a verbal agreement. This may involve:

• An additional medicine that is routinely given with another product. For example, a laxative with an opioid.
• A substitute. The pharmaceutical product in the TA may differ from the MA (see section 5.3.2). For clarity in the chain, it may be desirable to adjust the MA accordingly, for example for the purposes of an administration list. For this, the supplier can send a VMA to the prescriber.

5.7 Medication process in the clinical situation

This section contains additional information about the medication process in clinical situations. This concerns patients who are admitted to, for example, a hospital, a mental health clinic, a nursing home or other institutions.

The medication process in the hospital-based outpatient clinic is not covered here. This corresponds to the outpatient situation as described in sections 5.1 to 5.5.

NB: At present (Q1 2026), the information is still limited to a summary of what was contained in FO v3.0.0 rc1.

5.7.1 Some points of attention in the clinical situation

The clinical medication process is largely the same as described in the previous sections, with a few differences and points to note:

Medication supply
During hospitalisation, medicines are generally supplied by the hospital pharmacy. In other institutions, this may be done by public, institutional or hospital pharmacies.

Provisional and definitive medication orders
In the clinical situation, the term ‘provisional medication order’ (VMO) is used. In MP9, a VMO is recorded in the form of a medication agreement (MA). The application of the MA in a clinical situation is slightly broader than in an outpatient situation. In addition to an agreement between the prescriber and the patient about the use of medication, it is also:

• an instructing order to the supplier to ensure that the medication is available for administration.
• an instructing order to the administrator to administer the medication.

The hospital pharmacist usually validates the administration request. This results in a ‘final medication order’, comparable to the TA.

Dispense request and medication dispense
In a hospital, no VV is required during admission. The hospital pharmacist ensures that the medicine is available for the duration of the MA. Usually, no MVE will be recorded either.
Sometimes medication is taken from the ward stock. Replenishing this stock is not considered medication dispense in the sense of this FD.
If the medication for an institution is supplied by a public pharmacy, VV and MVE may be recorded.

Administration list
During admission, an administration list is available for all patients receiving medication and (target) administration times are recorded as standard.

5.7.2 Medication process during admission and discharge

Many changes in MAs and TAs can occur during admission and discharge. The generic sub-processes (Medication verification, Prescribe, Dispense, Administer) remain applicable, as described in sections 5.1 to 5.4. The sections below summarise the process from a clinical perspective.

5.7.2.1 Prior to admission

Medication verification is usually carried out prior to admission. In the case of emergency admissions, this will often not be possible. However, it may be possible to do this later during the admission. The patient's medication may need to be adjusted prior to admission:

• Starting new medication
• Modifying, interrupting or discontinuing current medication

If the admission date is not yet known, the data element PeriodOfUse.Condition in the relevant MA or stop-MA can be used to specify how many days before admission the adjustment must take place. As soon as the admission date is known or is changed, this is recorded in a new MA.
See the page Examples uncertainty condition for details on how to use this condition.

5.7.2.2 During admission

At the start of an admission, the medication the patient is already taking is reviewed. Various decisions can be made regarding this medication:

• Unchanged continuation of medication use
• Generic substitution of medication
• Discontinuation of medication
• Modification of medication
• Temporary interruption of medication
• Pharmacotherapeutic substitution of medication

These processes generally proceed as described in sections 5.2.2.1 to 5.2.2.5. This is briefly explained in the following sections.
Medication verification may also take place during the admission period.

5.7.2.2.1 Unchanged continuation of medication use during admission

The patient continues to use their medication from the outpatient situation unchanged (see section 5.2.2.2).

• The MA and TA from the outpatient situation continue during admission and after discharge.

5.7.2.2.2 Generic substitution of medication during admission

During admission, the patient receives a different medicine than in the outpatient situation. This medicine has the same active ingredient, in the same quantity and pharmaceutical form. The PRK therefore remains the same.

• The MA continues during admission and after discharge.
• The TA from the outpatient situation is stopped upon admission (stop type ‘stopped’). After discharge, the provider from the outpatient situation creates a new TA for the MA.
• A new TA is created for the medication during admission. This is stopped upon discharge.

5.7.2.2.3 Discontinuation of medication during admission

The patient must permanently stop taking the medication prescribed in the outpatient setting (see section 5.2.2.3 and 5.3.2.3).

• The MA and TA are stopped upon admission (stop type ‘stopped’).

5.7.2.2.4 Modification of medication during admission

A modification is made to the medication from the outpatient situation, for example in terms of dosage (see section 5.2.2.4 and 5.3.2.4). This follows the regular modification process:

• The MA and TA from the outpatient situation are stopped with technical stop-MA and stop-TA (stop type ‘stopped’).
• A new MA and TA are recorded with the modification; these are stopped upon discharge.
• Upon discharge, a new MA and TA are created for the outpatient situation.

5.7.2.2.5 Temporary interruption of medication during admission

Interrupting medication from the outpatient situation upon admission and resuming it upon discharge follows the process described in section 5.2.2.5.

• The MA and TA from the outpatient situation are temporarily stopped, with stop type ‘suspended’.
• Upon discharge, a resumption MA and TA are created for the outpatient situation.

5.7.2.2.6 Pharmacotherapeutic substitution during admission

During admission, the patient receives a different medicine than in the outpatient situation. This medicine is registered for the same indication, but contains a different active substance and therefore has a different PRK (e.g. omeprazole/pantoprazole).

• The MA and TA from the outpatient situation are temporarily stopped, with the stop type ‘suspended’ (see section 5.2.2.5).
• A new MA and TA are recorded for the other medicine. This is done in a different MBH, because the medicine has a different PRK. The new MA and TA are stopped upon discharge.
• Upon discharge, a resumption MA and TA are created for the outpatient situation.

5.7.2.3 Upon discharge

Upon discharge, the clinical medication is discontinued. However, in the event of an interim discharge, the clinical medication continues.

If a new MA and TA are created upon discharge, the prescriber at the institution can use the data element NextPractitioner, to indicate who is expected to take over the treatment with the medicine in question (see section 5.2.5.1.7). This may be relevant, for example, when modifying or interrupting the medication from the outpatient situation.

5.7.3 Information exchange in the clinical situation

An institution makes available all medication data recorded within the institution itself (all its own building blocks). These may not all be relevant to receiving health professionals. Querying information systems could therefore filter the data. However, some medicines administered during hospitalisation may still be important after discharge. For example, because they have a long-term effect that requires medication monitoring even after discharge. These should therefore not be filtered out in advance. Sectors and suppliers can jointly draw up a list for this purpose. This page contains a list of examples of such drug groups.

5.8 Overview of GDS medication

5.8.1 Introduction

In the previous sections, information about GDS medication has been provided in various places. To provide more overview, that information is summarized in this section.

The Medication Distribution System (GDS) is a distribution method in which medicinal products are packaged in units per administration time. The use of GDS has consequences for prescribing, dispensing and administering medication. For all involved healthcare professionals it must be clear that the patient receives their medication in GDS. This must be recorded and communicated unambiguously.

The logistics of GDS medication are often carried out by an external party. This also requires information exchange with that party. However, the communication between the dispenser and the GDS supplier falls outside the scope of this information standard.

On the page Practical examples GDS examples of different situations are elaborated.

5.8.2 Prescribing and dispensing of GDS medication

Dispense request for GDS medication
In the AdditionalWishes data element of the VV, the prescriber can indicate that a medicine may not be dispensed in GDS.

Medication agreement for GDS medication
In the MedicationAgreementAdditionalInformation data element, a prescriber can indicate, among other things, whether or not an MA should take effect immediately. The following values are available for this purpose:

• Immediately on the administration list or in GDS
• After regular prescription processing on the administration list or in GDS
• Per next GDS medication role change on the administration list

If one of these values is entered in the new MA when modifying medication, the technical stop-MA must be assigned the same value. When discontinuing medication, this information can be recorded in the stop-MA.

Administration agreement and medication dispensing for GDS medication

The DistributionForm data element of the TA and MVE can be used to indicate whether GDS medication is involved.

If medication is to be supplied in GDS or if changes are made to GDS medication, the startDateTime of the new GDS TA is the same as the starting date of the next medication roll.

If the change must take effect before a planned roll change, the time until the medication roll change must be bridged. This can be done by supplying the medication separately during that period or by changing the medication roll immediately.

Duration of use MVE
It is desirable that a prescriber can determine whether changes in medication can wait until the next medication roll change. To do so, it must be clear when that roll change will take place.
To this end, it has been agreed that the DurationOfUse of an MVE will be equal to the duration of the medication roll. With a weekly medication roll, the MVE has a DurationOfUse of 7 days. For a fortnightly medication roll, the DurationOfUse is 14 days. In combination with the start of the MVE (in MedicationDispenseDateTime), it can easily be deduced what the last day of the roll will be.
This is particularly important for medication with a non-daily intake schedule. It prevents medication from being repeated too early and provides a clear starting point for roll changes. Examples:

• Medication with an intake schedule of 3 times a week, on Monday - Wednesday - Friday.
• Medication with a dosing schedule of once every two weeks. With a weekly medication roll, the roll will contain the medication one week and not the next.
  

6 Additional information

This chapter contains additional information for this FO.
In Section 6.1 reference is made to the page with links to additional documentation.
In Section 6.2 the list of external references used in this FO is included.
Section 6.3 contains the document history.

6.1 Additional documentation

On the page Additional documentation for information standard MP9 links to other relevant pages are available. These links are grouped according to the different types of information.

Supporting material Functional Design
This section contains Practical examples and Other examples.

This main page of the FO contains the functional information for the information standard MP9. Part of this information is illustrated by means of examples. These examples are included on separate pages.

This material previously formed an integral part of the FO, but has been placed separately in order to keep the FO itself compact and normative. The supporting material can be consulted for clarification and further elaboration.

Implementation and project documentation
In addition to the FO and the supporting material, additional implementation and project documentation is available. This includes, among other things, general information about the Medication Transfer program, chain agreements, process descriptions, implementation guides and technical elaborations.

6.2 References

Author(s)	Title	Version	Date (accessed)	Source
Nictiz	Medication Process Information Standard	Website	December 2025	Medication Process Information Standard
MO Programme	About the Medication Transfer Programme	Website	December 2025	Medication Transfer Programme
MO Programme	Kickstart Medication Transfer	Website	December 2025	Kickstart
Nictiz	Information Standards	Website	December 2025	Information standards
Nictiz	Glossary Overview	Website	December 2025	Glossary overview
MO Programme	Glossary	Website	December 2025	Glossary
Nictiz	Step 0 Documentation	9 July 2025	December 2025	Step 0 documentation
NEN	NEN 7503:2022 Data exchange in healthcare – Electronic processing and exchange of data for prescribing and dispensing medication	2022	December 2025	NEN 7503:2022 Data exchange in healthcare
Various	Guideline on the Transfer of Medication Data in the Chain	2018/2019	December 2025	Guideline on the Transfer of Medication Data in the Chain
Various	Information Section: Addendum to the Quality Standard on the Transfer of Medication Data in the Chain	July 2023	December 2025	Information section
Nictiz	ART-DECOR: Medication Process	February 2026	February 2026	ART-DECOR
Nictiz	Qualification	Website	December 2025	Qualification
NHG, KNMP, Z-index	Building Blocks for the Medication Process	2014	December 2025	Building blocks for the medication process
Nictiz	Health Information Building Blocks – Main Page	Website	December 2025	zibs.nl
Z-index	Z-Index Backbone	17 December 2025	December 2025	Z-Index Backbone
Nictiz	Deduplication of MBHs	12 August 2024	December 2025	Implementation Guide Migration and Hybrid
Nictiz	Infusion Working Method Kickstart	1 September 2025	December 2025	Infusion working method
Nictiz	Guide to Cardinalities and Conformance	25 September 2025	December 2025	Guide to Cardinalities and Conformance
Nictiz	Information Standards: Foundation for Data Exchange in Healthcare	8 September 2025	December 2025	Information Standards: foundation for data exchange in healthcare
Nictiz	Guide for Including Kidney Function Value with the Prescription	28 March 2025	December 2025	Guide for including kidney function value with prescription
Dutch Government	Individual Healthcare Professions Act (BIG Act)	2024	December 2025	Individual Healthcare Professions Act (BIG)
Nictiz	Lab2Zorg Design V3.0.0-beta.4	16 December 2025	December 2025	Lab2Zorg Information Standard

6.3 Document history

Version	Date	Description
9 3.0.0-rc.2	March 2026	all changes see: *Releasenotes
9 3.0.0-rc.1	May 2025	all changes see: *Releasenotes
9 3.0.0-beta.4	November 2024	all changes see: *Releasenotes
9 3.0.0-beta.3	March 2024	all changes see: *Release notes
9 3.0.0-beta.2	October 2023	all changes see: *Release notes
9 3.0.0-beta.1	February 2023	all changes see: *Release notes
9 2.0.0	14 April 2022	Changed images of usecase 4.1.38, 4.1.39 and 4.1.40, they showed GDS instead of WDS BITS MP-534
9 2.0.0	08 April 2022	broken internal links FO corrected BITS MP-607
9 2.0.0	05 April 2022	all changes see: *Release notes
9 2.0.0 bèta	01 October 2021	all changes see: *Release notes
9.1.0	September 2020	BITS MP-167 FO Translated in English
9.1.0	29 January 2020	Stop textual adjustments Par 7.11 added: Implementation of medication distribution system (GDS) fields BITS MP-85, BITS MP-93, BITS MP-122 Use cases added (Register usage based on medicatieverstrekkingen, Verstrekkingsverzoek with number of repetitions, Prescribe non-drug) Chapter 4: Added pictures of use cases Renal function value in the prescription BITS MP-48 Medication Overview: Par 5.7 added 'Fields not to be shown' Various textual specifications/ improvements, including o.a. BITS MP-131 Paragraph 'Unaddressed prescription' moved to chapter 'Considerations' BITS MP-151 Removed draft TA creation process BITS MP-128 Par 4.1.8: Explanation 'Medical necessity' BITS MP-129 Par 4.1.35: Use case added
9.0.7	July 2019	Removed examples of specific infrastructures
9.0.7	December 2018	Par 1.3.3. MBH at HPK level in case of 'non medicines' without a PRK level Par 1.3.3. MBH for medicines without PRK (magistrals, infusions, etc.) Par 2.2.5.5. Changing medication: Technical stop-ma: appointment date for stop-ma and new ma must be the same. Change on MA that has already been stopped explained (no extra Stop-ma needed) Par 2.2.6. Added: VV under MA of someone else Par 4.2.15. Explanation GDS supplier supplies different HPK Par 7.10: Medication use indicator, according to appointment indicator, stop type, period of use and dosing instruction: table adapted and examples added Par 4.1.34: Own articles explanation added Chapter 5: example medication overview inserted in this wiki page instead of a separate wiki page (to simplify searching within the FO). Various textual tightening / improvements
9.0.6	May 2018	Addition to proposed verstrekkingsverzoek and addition of reply proposed verstrekkingsverzoek Chapter 6 table 4 addition of links to ART-DECOR transactions Removed: chapter about LSP Par. 7.10 table was extended with period of use and dosing instructions Various paragraphs were made more precise Addition of the property ‘third parties’ building block’ for MA, TA and MGB in medication overview
9.0.5	January 2018	Terminology: Stop-MA was changed to stop-MA in accordance with earlier project agreements (in Dutch different terminology Stop changed to staken) Par. 1.3.4 Addition to indicate that MA may also refer to a building block under a different medicamenteuze behandeling. Par. 4.1.22 Discharge was adapted because outpatient medication that was discontinued earlier may be started again at discharge. Par. 4.1.26 Discontinuation of medication by third parties was adapted. Par. 4.1.27 Two PRKs under a single medicamenteuze behandeling. Par. 2.2.5.3 Medication discontinuation agreement was adapted to clarify the impact on previously entered future medicatieafspraken. Footnote 3 Provisional and final medication order clarified and use case Provisional and final medication order (par. 4.1.31) added. Par. 4.1.30 Use case Single use added. Paragraphs 2.2.4, 2.2.5.2, 2.2.5.4, 4.1.16, 4.1.22 were adapted for substitution. In case of substitution, a medicamenteuze behandeling is not temporarily halted but effectively discontinued. The substitution is started under a new medicamenteuze behandeling. Paragraph 4.1.33 Missing digital medicatieafspraak at admission was added. C5 Medication overview was adapted with a reference to a new content page with functional elaboration. Paragraph 7.10 Medicatiegebruik: use indicator, according to agreement indicator and stop type added as agreed. C6 Building blocks of medication overview were changed to MA, TA and MGB. Figure 2 Colours in data model in accordance with Figure 1. Various abbreviations explained.
9.0.4	September 2017	Processed Design decisions in functional design. This means the design decisions have become obsolete. The current Functional Design is now leading. Par. 1.3.1. Definitions of building blocks have been adapted and the abbreviation for medicatieverstrekking has changed to MVE. Par. 1.3.3. Medicamenteuze behandeling is now based on PRK, rewritten and introduced PT as well as added text on handling parallel MAs. Par. 1.3.4. New data model diagram, various relations added and adapted on the basis of design decisions. Par. 1.5 Glossary removed. C2 Medication process diagram changed: MO added to Send and/or make available by the user; lines in swimlane of administrator/user adapted. C4.1 New use cases added: Do not dispense before, Two PRKs in a single medicamenteuze behandeling, Discontinuation of medication by third parties, Creating a medicatieafspraak after the fact, Parallel medicatieafspraken. C4.2 New use case: Discontinuing medication in a GDS; modified use case: Request, dispense and not picked up. C5: Differences between medication profile and medication overview were described; inference rules adapted on the basis of the new design decisions. Where necessary, references from ART-DECOR to FD C7 were added. Various grammatical and minor textual changes.
9.0.2	18 June 2017	Conversion of the document to wiki.
0.97	22 December 2016	Paragraph 2.4, 4.3.1 review remarks incorporated. Paragraph 4.2.11 text made more precise.
0.96	1 December 2016	Paragraph 2.4 Process: Administer was adapted and C6: Sending/receiving administration data was added as a result.
0.95	15 July 2016	Pilot version