mp:V2.0.0 MedicationProcess9 FHIR

1 Introduction

This is the implementation guide (IG) for the information standard Medication Process 9 (MP9) version 2.0.0 using the HL7® FHIR® standard. The MP9 standard is described in this functional specification and implemented here using FHIR version R4. This implementation guide assumes that the reader is familiar with both the functional specification and this version of FHIR.

Apart from this document, the guidelines as specified in the general FHIR Implementation Guide apply. In particular, the reader should take note of the Use case overarching principles and the use of FHIR packages. Where the general IG uses the term 'use case', this IG follows the functional specification in using th term 'transaction' for the various processes that are described. The functional specification uses the term 'use case' for more practical examples.

This IG first describes the boundaries and relationships in place, after which the implementation is describer per transaction.

2 Boundaries and relationships

2.2 Mappings between profiles and data set

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

Because of open world modelling, the cardinality of elements in the FHIR profiles can be less strict than the cardinalities in the ART-DECOR transactions. However, the latter cardinality is leading when it comes to exchanging building blocks in the context of a specific transaction. For example: in the nl-core-MedicationAgreement profile, .requester has a cardinality of 0..1, while in the Serve Medication data ART-DECOR transaction, the Prescriber element has a cardinality of 1..1 R. Therefore, .requester is expected to be filled with either a Reference to an nl-core-HealthProfessional-PractitionerRole resource or a [DataAbsentReason extension, see the general FHIR IG on 'Missing information'. Profiles do not explicitly define if or how to apply FHIR DataAbsentReason.

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

Relations between different building blocks exist in transactions by means of concepts with a name starting with ‘Relation…’ (Dutch: ‘Relatie…’) of data type Identification, for example RelationAdministrationAgreement (mp-dataelement920-1328) in building block MedicationAgreement. These relations are mapped to the FHIR data type ‘Reference’. Implementers SHOULD use literal references (using .reference) instead of logical references (using .identifier) where possible, see the general FHIR IG on the Reference data type.

2.3 Pharmaceutical treatment

The MP9 transaction data sets reference a container ‘Pharmaceutical treatment’ (Dutch: ‘Medicamenteuze behandeling’), which contains all medication building blocks relevant to the transaction. For the specification of the Pharmaceutical treatment, see the functional specification. In FHIR, the Pharmaceutical treatment does not have an explicit resource representation. Instead, each medication building block contains the PharmaceuticalTreatmentIdentifier extension which contains the ‘Pharmaceutical Treatment Identifier’. This Identifier shall be the same across different related medication resources that constitute one pharmaceutical treatment. The custom search parameter pharmaceutical-treatment-identifier, see 'Search parameters' is used within the 'Medication data' transaction to query a server for all building blocks within a specific Pharmaceutical treatment.

2.4 Patient identification

This implementation guide assumes that the client system is able to make a connection to the right server that contains the patient's information. It does not provide information on finding the right server nor does it provide information about security. Moreover, each transaction is performed in the context of a specific (authenticated) patient, whose context might have been established using the authentication mechanisms described in external specifications such as the MedMij 'Afsprakenstelsel' or through the usage of search parameters for patient identification. Each server is required to perform filtering based on the patient associated with the context for the request or based on the patient identification search parameters, which is a chained search parameter for all resource types except Patient, so only the records associated with the authenticated patient are returned.

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

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

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

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

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

2.5 Resource identification

All profiles used within the MP9 information standard contain .identifier elements with a cardinality of 0..* because of open world modelling. However, all ART-DECOR transactions referenced within this IG assign a 1..1 Required cardinality, meaning a stable identifier SHOULD be provided, or the DataAbsentReason extension if a value is missing. Identifiers SHALL contain both a .system and a .value.

Because in HL7v3 (CDA) an identifier can only be composed using OIDs, the .system SHALL be an OID to accommodate compatibility in transformations to and from FHIR. The Netherlands HL7v3 datatype II also defines additional restrictions on the maximum length of both @root and @extension (equivalent to respectively .system and .value in FHIR). For the same compatibility reasons, .system SHALL have a maximum of 128 characters and .value SHALL have a maximum of 64 characters.

2.6 Differentiating between transactions

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

Resource.meta.profile, altough FHIR:Vdraft_FHIR_IG_R4#Profile_use_and_declaration required should not be used for this purpose.

2.6.1 Actionable tag

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

If applicable, the profiles used by a transaction require the use of .meta.tag with .system=http://hl7.org/fhir/ValueSet/common-tags and .value=actionable to indicate that the resource is part of a request intented to be acted upon. The absence of this tag indicated the resources is merely of informative nature.

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

2.6.2 Summarizing table

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

3 Transactions

This section describes the FHIR implementation of all transactions listed in [mp:V2.0.0_Ontwerp_medicatieproces_9_ENG#Information_systems_and_transactions|section 7 of the functional specification]. Transactions are paired per transaction group. Where the functional specification uses the terms ‘Consulting’ and ‘Making available’, this IG uses the terms ‘Retrieving’ and ‘Serving’.

3.1 Medication data (Retrieve/Serve)

The retrieve medication data transaction is used by the client to retrieve medication data from a server. The client can retrieve its desired information by searching for specific medication building blocks.

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

The names of the transaction groups and transactions link to the functional definition in an ART-DECOR publication which details per scenario which data elements are expected to be supported.

3.1.1 Retrieve (request messages)

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

• MedicationRequest
• MedicationDispense
• MedicationStatement
• MedicationAdministration

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

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

3.1.1.2 Search Parameters

The client MAY supply, and the server SHALL be capable of processing, all search parameters listed in the table below.

MP9 search parameters	Description	FHIR search parameter	FHIR resource	Example
Identification	Search on identifier.	identifier	MedicationRequest, MedicationDispense, MedicationStatement, MedicationAdministration	Retrieves a MedicationRequest resource with a specific identifier. GET [base]/MedicationRequest?identifier=http://example.nl/fhir/NamingSystem/MedicationRequest|999922448
Identification	Search on the pharmaceutical treatment identifier. Note: retrieval of all medication resoures belonging to one pharmaceutical treatment requires to search on all medication resource types.	pharmaceutical-treatment-identifier	MedicationRequest, MedicationDispense, MedicationStatement, MedicationAdministration	Retrieves all MedicationRequest resources that are part of a pharmaceutical treatment with a specific identifier. GET [base]/MedicationRequest?pharmaceutical-treatment-identifier=http://example.nl/fhir/NamingSystem/pharmaceuticaltreatment|1247848
Type	Search on type of medication building block.	category	MedicationRequest	Retrieves all MedicationRequest resources that represent the building block MedicationAgreement. GET [base]/MedicationRequest?category=http://snomed.info/sct|16076005 Retrieves all MedicationRequest resources that represent the building block DispenseRequest. GET [base]/MedicationRequest?category=http://snomed.info/sct|52711000146108 Retrieves all MedicationRequest resources that represent the building block VariableDosingRegimen. GET [base]/MedicationRequest?category=http://snomed.info/sct|395067002
			MedicationDispense	Retrieves all MedicationDispense resources that represent the building block MedicationDispense. GET [base]/MedicationDispense?category=http://snomed.info/sct|373784005 Retrieves all MedicationRequest resources that represent the building block AdministrationAgreement. GET [base]/MedicationRequest?category=http://snomed.info/sct|422037009
			MedicationStatement	Retrieves all MedicationStatement resources that represent the building block MedicationUse2. GET [base]/MedicationStatement?category=http://snomed.info/sct|422979000
			MedicationAdministration	Retrieves all MedicationAdministration resources that represent the building block MedicationAdministration2. GET [base]/MedicationAdministration?category=http://snomed.info/sct|18629005
MedicationCode	Search on medication code.	medication.code	MedicationRequest, MedicationDispense, MedicationStatement, MedicationAdministration	Retrieves all MedicationRequest resources that represent the building block MedicationAgreement and have Carbasalaatcalcium Sandoz 600 30 as medication. GET [base]/MedicationRequest?category=http://snomed.info/sct|16076005&medication.code=urn:oid:2.16.840.1.113883.2.4.4.8|13610554
PeriodOfUse	Search on medication use in the past, present or future within the specified time period.	period-of-use	MedicationDispense, MedicationRequest	Retrieves all MedicationRequest resources that represent the building block MedicationAgreement and were in effect from 01-01-2010. GET [base]/MedicationRequest?category=http://snomed.info/sct|16076005&period-of-use=ge2010-01-01
DispensePeriod	Returns all medication dispenses within the specified time period.	whenhandedover	MedicationDispense	Retrieves all MedicationDispense resources that represent the building block MedicationDispense and were handed over within a 2 year period. GET [base]/MedicationDispense?category=http://snomed.info/sct|373784005&whenhandedover=ge2010-01-01&whenhandedover=le2011-12-31
AdministrationPeriod	Returns all medication administrations within the specified time period.	effective-time	MedicationAdministration	Retrieves all MedicationAdministration resources that represent the building block MedicationAdministration2 and were administration happened within a 2 year period. GET [base]/MedicationAdministration?category=http://snomed.info/sct|18629005&effective-time=ge2010-01-01&effective-time=le2011-12-31
-	The client may request that the server returns resources related to the search results, in order to reduce the overall network delay of repeated retrievals of related resources. Supporting the include of the Patient and Medication resources referenced by building blocks is required. Others (Organization, Location, PractitionerRole, Practitioner, RelatedPerson, Observation) are optional. However: all resources referenced per literal reference SHALL be resolvable per the Nictiz IG.	_include=[type]:patient _include=[type]:medication	MedicationRequest, MedicationDispense, MedicationStatement, MedicationAdministration	Retrieves all MedicationRequest resources that have Carbasalaatcalcium Sandoz 600 30 as medication and includes the Medication resource in the search results. GET [base]/MedicationRequest?medication.code=urn:oid:2.16.840.1.113883.2.4.4.8|13610554&_include=MedicationRequest:medication

The following custom search parameters are defined for this transaction:

• http://nictiz.nl/fhir/SearchParameter/pharmaceutical-treatment-identifier
• http://nictiz.nl/fhir/SearchParameter/category
• http://nictiz.nl/fhir/SearchParameter/period-of-use

3.1.1.3 Retrieve all medication data

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

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

3.1.2 Serve (response messages

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

3.2 Medication data (Send/Receive)

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

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

The names of the transaction groups and transactions link to the functional definition in an ART-DECOR publication which details per scenario which data elements are expected to be supported.

3.2.1 Send (request message)

Because medication data consists of several building blocks along with supporting resources, a transaction interaction is used. This allows for sending a Bundle with a set of resources in a single interaction and makes it possible to include referenced secondary resources.

A transaction interaction is performed by an HTTP POST command as shown:

POST [base]

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

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

3.2.2 Receive (response message)

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

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

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

3.3 Medication overview (Retrieve/Serve)

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

3.3.1 Actors

Transaction group	Transaction	Actor	Role
Retrieve Medication overview (PULL)	Consulting medication overview	Client	Request Medication overview
	Making medication overview available	Server	Serve Medication overview

The names of the transaction groups and transactions link to the functional definition in an ART-DECOR publication which details per scenario which data elements are used.

3.3.2 Invocations

3.3.2.1 Request message

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

The client executes a medication-overview operation with HTTP POST against the server base endpoint as shown below.

POST [base]/$medication-overview

3.3.2.2 Response message

The server returns a HTTP Status code appropriate to the processing of the operation. The successful outcome of the $medication-overview operation is the body of the medication overview response message. Successful processing of this operation should result in a Bundle recourse of type 'searchset', containing one List and one Patient resource as entries along with all the resources that represent the current medication overview. These resources SHALL be referenced from the List resource. The clinical content of the medication overview is defined in the Medication Process specification.

The Bundle profile represents the structure of the retrieve medication overview response message. The List profile represents the medication overview. The List contains the medication overview metadata and references to all resources that constitute the medication overview. These resources are included in the Bundle as entries. The Bundle.total value contains the number of matching zib: MedicationUse, AdministrationAgreement and MedicationAgreement. Other included resources, such as Medication resources, are not included in the total. The returned Bundle has at least one List and one Patient resource. The returned data to the client SHALL be a valid instance of its applicable profile as shown in the List of Profiles.

Note that the medication resources blocks are grouped per 'pharmaceutical treatment' conform to the Medication Process specification. Grouping SHALL be done by use of a 'Pharmaceutical Treatment Identifier'. This identifier shall be the same across different related medication resources that constitute one medication treatment. The PharmaceuticalTreatmentIdentifier extension is to be used for this grouping purpose.

3.5 Medication prescription (Send/Receive)

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

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

The names of the transaction groups and transactions link to the functional definition in an ART-DECOR publication which details per scenario which data elements are expected to be supported.

3.5.1 Send (request message)

Because a medication prescription consists of several building blocks along with supporting resources, a transaction interaction is used. This allows for sending a Bundle with a set of resources in a single interaction and makes it possible to include referenced secondary resources.

A transaction interaction is performed by an HTTP POST command as shown:

POST [base]

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

The Bundle SHALL conform to the mp-MedicationPrescription-Bundle profile, which contains at least a MedicationAgreement building block (with MedicationRequest.intent=order) and optionally a DispenseRequest building block (with MedicationRequest.intent=order. Additionally, one instance of nl-core-Patient and at least one instance of nl-core-PharmaceuticalProduct are included, together with optional instances of nl-core-BodyWeight, nl-core-BodyHeight and nl-core-LaboratoryTestResult. All resources included in the Bundle SHALL conform to their respective profiles listed in section 2.1.

The mp-MedicationPrescription-Bundle profile prescribes the use of actionable-tags to indicate that the resources sent are part of a prescription and of actionable nature.

3.5.2 Receive (response message)

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

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

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

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

3.6 Medication prescription processing (Send/Receive)

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

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

The names of the transaction groups and transactions link to the functional definition in an ART-DECOR publication which details per scenario which data elements are expected to be supported.

3.6.1 Send (request message)

Because data on processing a medication prescription consists of several building blocks along with supporting resources, a transaction interaction is used. This allows for sending a Bundle with a set of resources in a single interaction and makes it possible to include referenced secondary resources.

A transaction interaction is performed by an HTTP POST command as shown:

POST [base]

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

The Bundle SHALL conform to the mp-MedicationPrescriptionProcessing-Bundle profile, which contains at least an AdministrationAgreement building block and optionally a MedicationDispense building block. Additionally, one instance of nl-core-Patient and at least one instance of nl-core-PharmaceuticalProduct are included. All resources included in the Bundle SHALL conform to their respective profiles listed in section 3.1.

The mp-MedicationPrescriptionProcessing-Bundle profile prescribes the use of actionable-tags to indicate that the resources sent are part of a prescription and of actionable nature.

3.6.2 Receive (response message)

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

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

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

3.7 Proposal dispense request (Send/Receive)

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

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

The names of the transaction groups and transactions link to the functional definition in an ART-DECOR publication which details per scenario which data elements are expected to be supported.

3.7.1 Send (request message)

Because a proposal dispense request consists of a DispenseRequest building block along with supporting resources, a transaction interaction is used. This allows for sending a Bundle with a set of resources in a single interaction and makes it possible to include referenced secondary resources.

A transaction interaction is performed by an HTTP POST command as shown:

POST [base]

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

The Bundle SHALL conform to the mp-ProposalDispenseRequest-Bundle profile, which contains one DispenseRequest building block (with MedicationRequest.intent=plan). Additionally, one instance of nl-core-Patient and at least one instance of nl-core-PharmaceuticalProduct are included. All resources included in the Bundle SHALL conform to their respective profiles listed in section 3.1.

The mp-ProposalDispenseRequest-Bundle profile prescribes the use of actionable-tags to indicate that the resources sent are part of a prescription and of actionable nature.

3.7.2 Receive (response message)

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

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

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

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

4 Release notes

Release notes can be found on the functional design page.