eReferral Implementation Guide, published by Riziv-Inami Platform. This guide is not an authorized publication; it is the continuous build for version 3.0.0 built by the FHIR (HL7® FHIR® Standard) CI Build. This version is based on the current content of https://github.com/hl7-be/referral-uhmep/ and changes regularly. See the Directory of published versions

Migration 2.1.0 to 3.0.0

This page collects the integration checks for moving from release 2.1.0 to 3.0.0. It complements the release notes, the generated profiles and the operation pages; it does not replace INAMI/RIZIV business requirements.

Release Boundaries

The checks below describe the current 3.0.0 artefacts and the changes recorded in this IG. They are not an exhaustive compatibility certification of every 2.1.0 deployment. Confirm the deployed API version, configuration and package versions in the target environment before cutover. A client upgrading from 2.1.0 should not assume that a missing field was previously valid merely because an earlier server accepted its payload.

Payload Compatibility Checklist

Cardinalities and terminology bindings are defined by the generated profiles, not by this summary. Start with the nursing profile, Annex 81 profile and diagnostic-imaging profile.

Radiology Operation Matrix

This matrix focuses on migration-sensitive paths. It is not a complete authorization matrix: the Access Matrix, privacy checks, assignment ownership and operation-specific preconditions still apply. Business prescription states are not literal values for ServiceRequest.status; see the status mapping.

For other actors, terminal states, missing assignments and POST-based creation/completion shortcuts, use the relevant operation page rather than extrapolating from these rows. In particular, an existing-task completion and creating a task already marked completed are separate routes with their own preconditions.

Before and After Operation Examples

These are illustrative state projections, not complete FHIR payloads or executable clinical scenarios. IDs are placeholders. Execute the documented request against a valid resource and read back the related resources to obtain the authoritative state, dates and task dependencies.

Ambulatory Assignment Removal

Example: an authorized caller removes an existing, in-progress ambulatory caregiver assignment.

DELETE /Task/{executionID}

The unchanged ServiceRequest.status does not mean that no workflow transition occurred. Refresh the referral task and assignment list. Do not use the removed assignment as an active execution identifier; Unassign a Care Provider describes the operation.

Urgency Completion from Ready

Example: an organization completes an existing urgency-track caregiver execution while the prescription is still READY. Use the PATCH payload under Finish Existing Execution.

This exception is specific to the urgency track. It does not establish a general right to complete an ambulatory or inpatient prescription directly from READY, nor does it mean the client must issue a separate start request for this existing-task path.

Patient Cancellation

Example: the patient cancels their own radiology prescription in business state READY using Cancel a Medical Document.

{
  "resourceType": "Parameters",
  "parameter": [
    {
      "name": "operation",
      "part": [
        { "name": "type", "valueCode": "replace" },
        { "name": "path", "valueString": "ServiceRequest.status" },
        { "name": "value", "valueString": "revoked" }
      ]
    }
  ]
}

Requery the server after the operation. Do not infer the final state of every related performer or organization task from the prescription status alone. The same documented patient-cancellation permission also covers PENDING; other prescription types retain their own rules.

Terminology and Validation Baseline

Do not silently remove or replace clinical codes to eliminate QA errors. Confirm the intended edition, release and source mapping first. The ten PSS radiology scenarios are illustrative inputs, not evidence that every code combination is accepted by the deployed backend.

Regression Test Checklist