cio:V2.0.0 FHIR CiO

This FHIR IG is currently under development and can not be considered stable and ready for use. For questions and change requests regarding this IG, please create a ticket in BITS.

1 Introduction

This is the implementation guide (IG) for the information standard CiO (Dutch: Contra-indicaties en overgevoeligheden, English: Contraindications and intolerances), version 2.0.0-beta.1. The functional specification can be found here and is implemented using HL7 FHIR R4. This implementation guide assumes that the reader is familiar with both the functional specification and this version of FHIR.

Apart from this document, the guidelines as specified in the general FHIR Implementation Guide apply. In particular, the reader should take note of the Overarching principles and the use of FHIR packages. Where the general IG uses the term ‘use case’, this IG uses the term ‘transaction’ for the various processes that are described.

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

2 Boundaries and relationships

2.1 Boundaries

Note that this version of the CiO information standard is only focused on medication contraindications and hypersensitivities due to medication (see section 1.1 of the functional specification). Technically this scope is reflected in for instance the terminology used within the FHIR profiles or the naming of the cio-MedicationContraIndication profile. In this IG however, we will not further elaborate on this narrower scope and instead describe the technical implementation of this standard as general as possible, in order to make it easier to incorporate a broadening of the scope in subsequent versions of this IG.

2.2 Building blocks and profiles

The exchange of data within the CiO standard version 2.0.0-beta.1 is partly based on the 2020 publication of the Dutch Health and Care Information Models (Dutch: ‘zorginformatiebouwstenen’ or ‘zibs’), and subsequent changes made that are present in the 2022 prepublication. In particular, the prepublication of 2021 saw the introduction of the Hypersensitivity and Reaction zibs which are based on and still have quite some overlap with the zib AllergyIntolerance that already existed. The functional data set of CiO has further built upon the former two zibs (renaming the first as HypersensitivityDisposition), next to the zib MedicationContraIndication. These objects (which are actually exchanged) are referred to as ‘building blocks’ in the data set, and can thus be seen as ‘extended zibs’ suitable for implementation.

Due to new insights, the building blocks HypersensitivityDisposition and Reaction in the functional data set have deviated quite a lot from the zib AllergyIntolerance present in the 2020 publication, making them incompatible in varying degrees from a technical point of view. Therefore it was not possible to implement the FHIR profiles for these building blocks by building on and extending the nl-core profiles based on zib publication 2020. Hence the profiles for these building blocks have been created ‘independently’ from the nl-core profiles, meaning that they are not derived from nl-core-AllergyIntolerance. For the building block MedicationContraIndication on the other hand, the changes made within CiO are quite minimal with respect to its zib 2020 counterpart, making it possible to derive from nl-core-MedicationContraIndication.

Lastly it is important to note that there is still extensive discussion about the exact scope, name and structure of the HypersensitivityDisposition and Reaction building blocks, meaning that the current profiles definitely cannot be considered to be stable and ready for use. To aid in the discussion, two sets of FHIR profiles have been made for these building blocks:

• The cio-HypersensitivityDispositionReaction profile is created on the AllergyIntolerance resource and closely follows the nl-core-AllergyIntolerance profile corresponding to the zib AllergyIntolerance present in the 2020 publication. However due to incompatibilities (mainly on the level of terminology) it is not actually derived from that profile. The cio-HypersensitivityDispositionReaction profile contains both the HypersensitivityDisposition and Reaction building blocks, which makes sense as the Reaction building block is never exchanged on its own, but always in the context of a certain HypersensitivityDisposition. The main advantage in this profiling approach lies in the fact that it semantically makes the most sense, and the FHIR resource AllergyIntolerance already contains quite a lot of counterparts to the concepts in the functional data set (in particular on the level of the Reaction). This profiling approach will be referred to as approach A in the remainder of this IG.
• The cio-HypersensitivityDisposition and cio-Reaction profiles are created on the Condition and Observation resources, respectively. Using this approach less custom extensions are necessary to properly map the concepts from the functional data set, and it makes it easier to identify and handle Reactions. The main disadvantages are semantically of nature, for instance the mapping of the SubstanceToMonitor concept (which is a key concept in the HypersensitivityDisposition building block) is not as straightforward, and quite some concepts within the Reaction building block are mapped on Observation.components, while they have a direct counterpart in profiling approach A. This profiling approach will be referred to as approach B in the remainder of this IG.

See this document for a more detailed reasoning behind the mapping from functional data set to these FHIR profiles.

For both profiling approaches the technical implementation will be explained in this IG, for instance with respect to details within their profiles, or definitions of search requests/parameters in which the underlying FHIR resources are mentioned. After a definitive approach has been chosen, only the relevant sections will remain in subsequent versions of this IG.

Nictiz uses the FHIR Packaging mechanism. This conveniently bundles all profiles, terminology, example material and other conformance resources you need into a single archive, which can be downloaded or installed using the appropriate FHIR tooling. This version of the information standard uses the following packages: nictiz.fhir.nl.r4.cio version 1.0.0-beta.1 or compatible nictiz.fhir.nl.r4.medicationprocess9 version 2.0.0-beta.1 or compatible nictiz.fhir.nl.r4.nl-core version 0.9.0-beta.1 or compatible Note: packages use Semantic Versioning. Other versions can be used at will as long as they have the same major.minor number or a minor number higher than the stated version.

2.2.1 Main building blocks

As described above, only the MedicationContraIndication building block has a dependency on its zib counterpart (of the 2020 publication). Nevertheless all building blocks have resulted in so-called ‘cio’ profiles.

Building block (EN)	Building block (NL)	FHIR resource	FHIR profile
HypersensitivityDisposition	Overgevoeligheid	AllergyIntolerance	http://nictiz.nl/fhir/StructureDefinition/cio-HypersensitivityDispositionReaction
Reaction	Reactie
HypersensitivityDisposition	Overgevoeligheid	Condition	http://nictiz.nl/fhir/StructureDefinition/cio-HypersensitivityDisposition
Reaction	Reactie	Observation	http://nictiz.nl/fhir/StructureDefinition/cio-Reaction
MedicationContraIndication	MedicatieContraIndicatie	Flag	http://nictiz.nl/fhir/StructureDefinition/cio-MedicationContraIndication

2.2.2 Secondary building blocks

Additionally, the standard uses several secondary building blocks referenced from the main building blocks. All secondary building blocks are part of either the ‘nl-core’ or ‘medicationprocess9’ package.

Building block (EN)	Building block (NL)	FHIR resource	FHIR profile
Patient	Patient	Patient	http://nictiz.nl/fhir/StructureDefinition/nl-core-Patient
HealthProfessional	Zorgverlener	PractitionerRole	http://nictiz.nl/fhir/StructureDefinition/nl-core-HealthProfessional-PractitionerRole
		Practitioner	http://nictiz.nl/fhir/StructureDefinition/nl-core-HealthProfessional-Practitioner
HealthcareProvider	Zorgaanbieder	Location	http://nictiz.nl/fhir/StructureDefinition/nl-core-HealthcareProvider
		Organization	http://nictiz.nl/fhir/StructureDefinition/nl-core-HealthcareProvider-Organization
MedicationAgreement	Medicatieafspraak	MedicationRequest	http://nictiz.nl/fhir/StructureDefinition/mp-MedicationAgreement
AdministrationAgreement	Toedieningsafspraak	MedicationDispense	http://nictiz.nl/fhir/StructureDefinition/mp-AdministrationAgreement
MedicationDispense	Medicatieverstrekking	MedicationDispense	http://nictiz.nl/fhir/StructureDefinition/mp-MedicationDispense
MedicationUse2	Medicatiegebruik2	MedicationStatement	http://nictiz.nl/fhir/StructureDefinition/mp-MedicationUse2

Note the following:

• Each occurrence of the zib HealthProfessional is normally represented by two FHIR resources: an instance of nl-core-HealthProfessional-PractitionerRole and an instance of nl-core-HealthProfessional-Practitioner. Sending systems should only fill the reference to the PractitionerRole instance where relevant. Receiving systems can resolve the reference to the Practitioner resource from that PractitionerRole instance.
• The zib HealthcareProvider is mapped to both a Location and Organization profile. In general the Location profile acts as the focal resource, because most references to this zib are concerned about the recording of the physical location where the care to patient takes place rather than the organizational information. However, within the main building blocks in CiO the HealthcareProvider is always present as an author, hence a reference to the Organization profile is sufficient in those cases. The Location profile, although not directly referenced from the main building blocks, is mentioned in the table above for completeness purposes (as it is referred to in secondary resources).

2.2.3 Relations between building blocks

2.3 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. The FHIR profiles contain mappings to all data elements that are present in the functional data set (prefixed with ‘cio-dataelement-20-’).

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

Relations between different building blocks exist in transactions by means of concepts with a name starting with ‘Relation…’ (Dutch: ‘Relatie…’) and an underlying concept 'Identification' of data type Identification, for example RelationHypersensitivity (cio-dataelement-20-734) in building block Hypersensitivity. 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.4 Patient identification

This implementation guide assumes that the client system is able to make a connection to the right server that contains the patient's information. It does not provide information on finding the right server nor does it provide information about security. Moreover, each transaction is performed in the context of a specific patient, whose context might have been established using the authentication mechanisms described in external specifications such as the MedMij ‘Afsprakenstelsel’ or through the usage of search parameters for patient identification.

Each server is required to perform filtering based on the patient associated with the context for the request or based on the patient identification search parameters, which is a chained search parameter for all resource types except Patient, so only the records associated with the authenticated patient are returned.

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

• Patient: identifier
• AllergyIntolerance: patient.identifier
• Condition: patient.identifier and subject:Patient.identifier
• Observation: patient.identifier and subject:Patient.identifier
• Flag: patient.identifier and subject:Patient.identifier

An example of a request that retrieves all AllergyIntolerance resources of a patient with a fake BSN of 111222333:

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

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

3 Transactions

This section describes the FHIR implementation of all transactions listed in section 2 of the functional specification. Transactions are paired per transaction group. Each subsection below hyperlinks the names of the transaction groups and transactions to the functional definition in an ART-DECOR publication. The ART-DECOR publication details which data elements are expected to be supported (cardinality and conformance) for each transaction. Where the functional specification uses the terms ‘Query’ and ‘Making available’, this IG uses the terms ‘Retrieving’ and ‘Serving’.

3.1 Contraindication (Retrieve/Serve)

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

Transaction group	Transaction	Actor	System role	FHIR CapabilityStatement
Contraindication (PULL)	Retrieving contraindications	Client	CIO-CIR	CapabilityStatement Retrieve/serve contraindications
	Serving contraindications	Server	CIO-CIB

3.1.1 Retrieve (request message)

When a health professional or healthcare provider wants to obtain all contraindications or specific ones matching various parameters, they issue a retrieve contraindications request message. This message uses the HTTP GET method parameterized query against the server's FHIR Flag endpoint.

The search interaction is performed by an HTTP GET conform the FHIR search specification, as shown below. This URL is configurable by the client by configuring the search query.

GET [base]/Flag?category=http://snomed.info/sct|140401000146105{&[additional parameter(s)]}

3.1.1.1 Search parameters

All search parameters listed in the table below SHALL be supported for processing by servers and MAY be supported by clients, with the exception of the category parameter, which SHALL be supported by clients as well (as it is always part of the search query in this transaction).

CiO search parameter	Description	FHIR search parameter	FHIR resource	Example
-	Search on MedicationContraIndication building blocks.	category	Flag	Retrieves all Flag resources representing a MedicationContraIndication. GET [base]/Flag?category=http://snomed.info/sct|140401000146105
PatientIdentificationNumber	Search on patient.	patient.identifier	Flag	Retrieves all MedicationContraIndication building blocks of a patient with a fake BSN of 111222333. GET [base]/Flag?category=http://snomed.info/sct|140401000146105&patient.identifier=http://fhir.nl/fhir/NamingSystem/bsn|111222333
ReferenceDate	Search on the MedicationContraIndication building blocks that have been registered on or after a certain date.	registration-date-time	Flag	Retrieves all MedicationContraIndication building blocks that were registered from 01-05-2023. GET [base]/Flag?category=http://snomed.info/sct|140401000146105&registration-date-time=ge2023-05-01
-	The client may request that the server returns resources related to the search results, in order to reduce the overall network delay of repeated retrievals of related resources. Supporting the include of the Patient resource referenced by building blocks is required. Others (Organization, PractitionerRole, Practitioner) are optional. However: all resources referenced per literal reference SHALL be resolvable per the Nictiz IG.	_include=Flag:patient	Flag	Retrieves all MedicationContraIndication building blocks of a patient with a fake BSN of 111222333 and includes the Patient resource in the search results. GET [base]/Flag?category=http://snomed.info/sct|140401000146105&patient.identifier=http://fhir.nl/fhir/NamingSystem/bsn|111222333&_include=Flag:patient

The following custom search parameters are defined for this transaction:

• http://nictiz.nl/fhir/SearchParameter/Flag-category
• http://nictiz.nl/fhir/SearchParameter/Flag-registration-date-time

3.1.2 Serve (response message)

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

3.1.3 List of profiles

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

Building block (EN)	Building block (NL)	FHIR resource	FHIR profile
MedicationContraIndication	MedicatieContraIndicatie	Flag	http://nictiz.nl/fhir/StructureDefinition/cio-MedicationContraIndication
Patient	Patient	Patient	http://nictiz.nl/fhir/StructureDefinition/nl-core-Patient
HealthProfessional	Zorgverlener	PractitionerRole	http://nictiz.nl/fhir/StructureDefinition/nl-core-HealthProfessional-PractitionerRole
		Practitioner	http://nictiz.nl/fhir/StructureDefinition/nl-core-HealthProfessional-Practitioner
HealthcareProvider	Zorgaanbieder	Organization	http://nictiz.nl/fhir/StructureDefinition/nl-core-HealthcareProvider-Organization

3.2 Contraindication (Send/Receive)

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

Transaction group	Transaction	Actor	System role	FHIR CapabilityStatement
Contraindication (PUSH)	Sending contraindications	Client	CIO-CIS	CapabilityStatement Send/receive contraindications
	Receiving contraindications	Server	CIO-CIO

3.2.1 Send (request message)

Because the data sent in this transaction potentially consists of several building blocks along with secondary 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 if needed. The interaction is performed by an HTTP POST command as shown:

POST [base]

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

The resources included in the Bundle SHALL conform to the profiles listed in the 'List of profiles' below.

3.2.2 Receive (response message)

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

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

3.2.3 List of profiles

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

Building block (EN)	Building block (NL)	FHIR resource	FHIR profile
MedicationContraIndication	MedicatieContraIndicatie	Flag	http://nictiz.nl/fhir/StructureDefinition/cio-MedicationContraIndication
Patient	Patient	Patient	http://nictiz.nl/fhir/StructureDefinition/nl-core-Patient
HealthProfessional	Zorgverlener	PractitionerRole	http://nictiz.nl/fhir/StructureDefinition/nl-core-HealthProfessional-PractitionerRole
		Practitioner	http://nictiz.nl/fhir/StructureDefinition/nl-core-HealthProfessional-Practitioner
HealthcareProvider	Zorgaanbieder	Organization	http://nictiz.nl/fhir/StructureDefinition/nl-core-HealthcareProvider-Organization

3.3 Hypersensitivity Disposition (Retrieve/Serve)

Within this transaction both AllergyIntolerance and Condition/Observation resources are mentioned while specifying e.g. search requests and search parameters. Note that the former references are only relevant if profiling approach A is chosen, while the latter are only relevant in approach B.

The retrieve hypersensitivity dispositions transaction is used by the client to retrieve hypersensitivity dispositions including corresponding reactions from a server.

Transaction group	Transaction	Actor	System role	FHIR CapabilityStatement
Hypersensitivity Disposition (PULL)	Retrieving hypersensitivity dispositions	Client	CIO-OVR	CapabilityStatement Retrieve/serve hypersensitivity dispositions
	Serving hypersensitivity dispositions	Server	CIO-OVB

3.3.1 Retrieve (request message)

When a health professional or healthcare provider wants to obtain all hypersensitivity dispositions or specific ones matching various parameters, including the corresponding reactions, they issue a retrieve hypersensitivity dispositions request message. This message uses the HTTP GET method parameterized query against the server's FHIR AllergyIntolerance or Condition endpoint.

The search interaction is performed by an HTTP GET conform the FHIR search specification, as shown below. This URL is configurable by the client by configuring the search query.

GET [base]/AllergyIntolerance{?[parameter(s)]}

GET [base]/Condition?code=http://snomed.info/sct|157471000146100&_include=Condition:evidence-detail{&[additional parameter(s)]}

3.3.1.1 Search parameters

All search parameters listed in the table below SHALL be supported for processing by servers and MAY be supported by clients, with the exception of the code and evidence-detail parameters on Condition (and the corresponding include of the latter parameter), which SHALL be supported by clients as well (as these are always part of the search query in this transaction).

CiO search parameter	Description	FHIR search parameter	FHIR resource	Example
-	Search on HypersensitivityDisposition building blocks.	code	Condition	Retrieves all Condition resources representing a HypersensitivityDisposition. GET [base]/Condition?code=http://snomed.info/sct|157471000146100
-	Search on Reaction building blocks.	evidence-detail	Condition	Retrieves all Condition resources representing a HypersensitivityDisposition and includes the Observation resources representing corresponding Reactions. GET [base]/Condition?code=http://snomed.info/sct|157471000146100&_include=Condition:evidence-detail
PatientIdentificationNumber	Search on patient.	patient.identifier	AllergyIntolerance, Condition	Retrieves all HypersensitivityDisposition and corresponding Reaction building blocks of a patient with a fake BSN of 111222333. GET [base]/AllergyIntolerance?patient.identifier=http://fhir.nl/fhir/NamingSystem/bsn|111222333 GET [base]/Condition?code=http://snomed.info/sct|157471000146100&_include=Condition:evidence-detail&patient.identifier=http://fhir.nl/fhir/NamingSystem/bsn|111222333
ReferenceDate	Search on the HypersensitivityDisposition building blocks that have been registered on or after a certain date.	date	AllergyIntolerance	Retrieves all HypersensitivityDisposition and corresponding Reaction building blocks that were registered from 01-05-2023. GET [base]/AllergyIntolerance?recorded-date=ge2023-05-01 GET [base]/Condition?code=http://snomed.info/sct|157471000146100&_include=Condition:evidence-detail&recorded-date=ge2023-05-01
		recorded-date	Condition
-	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 Observation (the latter only in approach B) resource referenced by building blocks is required. Others (Organization, PractitionerRole, Practitioner, MedicationRequest, MedicationDispense, MedicationStatement) are optional. However: all resources referenced per literal reference SHALL be resolvable per the Nictiz IG.	_include=[type]:patient _include=Condition:evidence-detail	AllergyIntolerance, Condition	Retrieves all HypersensitivityDisposition and corresponding Reaction building blocks of a patient with a fake BSN of 111222333 and includes the Patient resource in the search results. GET [base]/AllergyIntolerance?patient.identifier=http://fhir.nl/fhir/NamingSystem/bsn|111222333&_include=AllergyIntolerance:patient GET [base]/Condition?code=http://snomed.info/sct|157471000146100&_include=Condition:evidence-detail&patient.identifier=http://fhir.nl/fhir/NamingSystem/bsn|111222333&_include=Condition:patient

3.3.2 Serve (response message)

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

3.3.3 List of profiles

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

Building block (EN)	Building block (NL)	FHIR resource	FHIR profile
HypersensitivityDisposition	Overgevoeligheid	AllergyIntolerance	http://nictiz.nl/fhir/StructureDefinition/cio-HypersensitivityDispositionReaction
Reaction	Reactie
HypersensitivityDisposition	Overgevoeligheid	Condition	http://nictiz.nl/fhir/StructureDefinition/cio-HypersensitivityDisposition
Reaction	Reactie	Observation	http://nictiz.nl/fhir/StructureDefinition/cio-Reaction
Patient	Patient	Patient	http://nictiz.nl/fhir/StructureDefinition/nl-core-Patient
HealthProfessional	Zorgverlener	PractitionerRole	http://nictiz.nl/fhir/StructureDefinition/nl-core-HealthProfessional-PractitionerRole
		Practitioner	http://nictiz.nl/fhir/StructureDefinition/nl-core-HealthProfessional-Practitioner
HealthcareProvider	Zorgaanbieder	Organization	http://nictiz.nl/fhir/StructureDefinition/nl-core-HealthcareProvider-Organization
MedicationAgreement	Medicatieafspraak	MedicationRequest	http://nictiz.nl/fhir/StructureDefinition/mp-MedicationAgreement
AdministrationAgreement	Toedieningsafspraak	MedicationDispense	http://nictiz.nl/fhir/StructureDefinition/mp-AdministrationAgreement
MedicationDispense	Medicatieverstrekking	MedicationDispense	http://nictiz.nl/fhir/StructureDefinition/mp-MedicationDispense
MedicationUse2	Medicatiegebruik2	MedicationStatement	http://nictiz.nl/fhir/StructureDefinition/mp-MedicationUse2

3.4 Hypersensitivity Disposition (Send/Receive)

Within this transaction both AllergyIntolerance and Condition/Observation resources are mentioned while specifying e.g. the profiles that need to be supported. Note that the former references are only relevant if profiling approach A is chosen, while the latter are only relevant in approach B.

The send hypersensitivity dispositions transaction is used by the client to send hypersensitivity dispositions including corresponding reactions to a server.

Transaction group	Transaction	Actor	System role	FHIR CapabilityStatement
Hypersensitivity Disposition (PUSH)	Sending hypersensitivity dispositions	Client	CIO-OVS	CapabilityStatement Send/receive hypersensitivity dispositions
	Receiving hypersensitivity dispositions	Server	CIO-OVO

3.4.1 Send (request message)

Because the data sent in this transaction potentially consists of several building blocks along with secondary 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 if needed. The interaction is performed by an HTTP POST command as shown:

POST [base]

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

The resources included in the Bundle SHALL conform to the profiles listed in the 'List of profiles' below.

3.4.2 Receive (response message)

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

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

3.4.3 List of profiles

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

Building block (EN)	Building block (NL)	FHIR resource	FHIR profile
HypersensitivityDisposition	Overgevoeligheid	AllergyIntolerance	http://nictiz.nl/fhir/StructureDefinition/cio-HypersensitivityDispositionReaction
Reaction	Reactie
HypersensitivityDisposition	Overgevoeligheid	Condition	http://nictiz.nl/fhir/StructureDefinition/cio-HypersensitivityDisposition
Reaction	Reactie	Observation	http://nictiz.nl/fhir/StructureDefinition/cio-Reaction
Patient	Patient	Patient	http://nictiz.nl/fhir/StructureDefinition/nl-core-Patient
HealthProfessional	Zorgverlener	PractitionerRole	http://nictiz.nl/fhir/StructureDefinition/nl-core-HealthProfessional-PractitionerRole
		Practitioner	http://nictiz.nl/fhir/StructureDefinition/nl-core-HealthProfessional-Practitioner
HealthcareProvider	Zorgaanbieder	Organization	http://nictiz.nl/fhir/StructureDefinition/nl-core-HealthcareProvider-Organization
MedicationAgreement	Medicatieafspraak	MedicationRequest	http://nictiz.nl/fhir/StructureDefinition/mp-MedicationAgreement
AdministrationAgreement	Toedieningsafspraak	MedicationDispense	http://nictiz.nl/fhir/StructureDefinition/mp-AdministrationAgreement
MedicationDispense	Medicatieverstrekking	MedicationDispense	http://nictiz.nl/fhir/StructureDefinition/mp-MedicationDispense
MedicationUse2	Medicatiegebruik2	MedicationStatement	http://nictiz.nl/fhir/StructureDefinition/mp-MedicationUse2

4 Release notes

Release notes can be found on the functional design page.