FHIR Implementation Guide eOverdracht v3.1

Uit informatiestandaarden
Ga naar: navigatie, zoeken


This page details the HL7 FHIR requirements for exchanging the Verpleegkundige eOverdracht data described in this functional design.

Use case: Send eOverdracht Aanmeldbericht


The send eOverdracht Aanmeldbericht transaction is used by the sending XIS to send the relevant data to the receiving XIS. In addition to the functional design, the structure of this transaction is described in Opbouw eOverdracht aanmelding.


Transaction group Transaction Actor Role
Send eOverdracht Aanmeldbericht(PUSH) Send aanmeldbericht request Healthcare professional (using a XIS) Sends aanmeldbericht to the receiving XIS
Send aanmeldbericht response Receiving XIS Sends acknowledgement message to sending XIS


Sending XIS: request message

The send eOverdracht Aanmeldbericht message uses the HTTP POST method on the target XIS's base.

Trigger Events

This message is invoked when the XIS needs to send an eOverdracht Aanmeldbericht to the receiving XIS.

Message Semantics

Because the data needed in the Aanmeldbericht will most likely consist of multiple FHIR resources, a document Bundle is used. This allows for bundling and sending a set of resources in a single interaction.

The interaction is performed by an HTTP POST command as shown:

POST [base] {?_format=[mime-type]}

The body of the post submission is a Bundle with Bundle.type = document. The first entry contains a Composition resource, and each subsequent entry contains a resource that is referenced from the Composition resource. By sending it to the target's base, the document Bundle will be processed as a transaction and each Bundle.entry will be treated as a create interaction for the entry.resource.

Read more:

The Composition resource in the Bundle SHALL conform to the eOverdracht Aanmeldbericht profile listed below. The table also lists profiles that represent ZIBs that can be used for the data exchange of the referenced resources.

The resources in the message SHALL be a valid instance of these profiles. All resources SHALL include their related profile canonical URL in the meta.profile element in order to show compliance.

The Bundle resource SHALL contain all resources that are referenced from the Composition resource, each in a separate Bundle.entry.




Expected Actions

On receipt of the submission, the receiving XIS shall validate the resources and respond with an appropriate HTTP code. If the XIS encounters any errors or if validation fails, the XIS shall return an error as documented in the Message Semantics of the response message.

XIS: response message

The target XIS returns an HTTP Status code appropriate to the processing outcome and returns a Bundle, of type transaction-response, that contains one entry for each entry in the request, in the same order, with the outcome of processing the entry.

Trigger Events

The target XIS completed processing of the send eOverdracht Aanmeldbericht message.

Message Semantics

The target XIS SHALL return a Bundle with type set to transaction-response that contains one entry for each entry in the request, in the same order, with the outcome of processing the entry.

A client may use the returned Bundle to track the outcomes of processing the entry, and the identities assigned to the resources by the server. Each entry element SHALL contain a response element which details the outcome of processing the entry - the HTTP status code, and the location and ETag header values, which are used for identifying and versioning the resources. In addition, a resource may be included in the entry, as specified by the Prefer header.

When the resource syntax or data is incorrect or invalid, and cannot be used to create a new resource, the server returns a 400 Bad Request HTTP status code. When the server rejects the content of the resource because of business rules, the server returns a 422 Unprocessable Entity error HTTP status code. In either case, the server SHOULD include a response body containing an OperationOutcome with detailed error messages describing the reason for the error, and perform a rollback of the creation of any previous entries.

Common HTTP Status codes returned on FHIR-related errors (in addition to normal HTTP errors related to security, header and content type negotiation issues):

  • 400 Bad Request - resource could not be parsed or failed basic FHIR validation rules
  • 404 Not Found - resource type not supported, or not a FHIR end-point
  • 422 Unprocessable Entity - the proposed resource violated applicable FHIR profiles or server business rules. This should be accompanied by an OperationOutcome resource providing additional detail

Read more: create transaction

Expected Actions

The sending XIS processes the results according to application-defined rules.

List of StructureDefinitions

The profiles listed in the table below represent their entire respective HCIM and are applicable in a broader context than the exchange of eOverdracht information.

A package is available that conveniently bundles all examples, profiles and other conformance resources you need into a single download. This version of the information standard depends on Nictiz package 1.1.x Please note that the direct links to the various conformance resources below will take you to the latest version, which might not match the package version. At time of writing, there is no way to render the conformance resource as found in the package. This is on the roadmap for Simplifier.

The FHIR Packaging mechanism to support consistent versioning of profiles and related conformance resources such as OperationDefinitions. FHIR Packaging is based on the NPM Packaging mechanism and offers developers a convenient way to include the conformance resources in their favorite IDE. The relevant package version is indicated and linked in the information standards technical design page.

For even more background information:


It is not required to implement FHIR based information standards using the packaging mechanism. It is still possible to download all or selected resources from Simplifier on as-needed basis. You are however encouraged to invest in dealing with packages.

Zib naam Zib versie FHIR Resource FHIR Profile
- - Composition http://nictiz.nl/fhir/StructureDefinition/eOverdrachtAanmeldbericht
Patient v3.1(2017NL) Patient http://fhir.nl/fhir/StructureDefinition/nl-core-patient
Betaler v3.1(2017NL) Coverage http://nictiz.nl/fhir/StructureDefinition/zib-Payer
Zorgaanbieder v3.1.1(2017NL) Organization http://fhir.nl/fhir/StructureDefinition/nl-core-organization
Zorgverlener v3.2(2017NL) Practitioner http://fhir.nl/fhir/StructureDefinition/nl-core-practitioner
PractitionerRole http://fhir.nl/fhir/StructureDefinition/nl-core-practitionerrole
Probleem v4.1(2017NL) Condition http://nictiz.nl/fhir/StructureDefinition/zib-Problem
Alert v3.2(2017NL) Flag http://nictiz.nl/fhir/StructureDefinition/zib-Alert
VrijheidsbeperkendeMaatregelen v3.1(2017NL) Procedure http://nictiz.nl/fhir/StructureDefinition/zib-FreedomRestrictingMeasures
GeplandeZorgActiviteit v3.1(2017NL) ProcedureRequest http://nictiz.nl/fhir/StructureDefinition/zib-ProcedureRequest
SondeSysteem v3.2(2017NL) DeviceUseStatement http://nictiz.nl/fhir/StructureDefinition/zib-FeedingTubeSystem
Infuus v3.2(2017NL) DeviceUseStatement http://nictiz.nl/fhir/StructureDefinition/zib-Infusion
Stoma v3.2(2017NL) Observation http://nictiz.nl/fhir/StructureDefinition/zib-Stoma

Interactions, operations, search parameters


The following logical interactions are needed for the send eOverdracht Aanmeldbericht transaction:


No operations are defined or needed for this transaction.

Search parameters

No search parameters are defined or needed for this transaction.