eOverdracht Notifications Implementation Guide - Notification Model Only (v0.2)

eOverdracht Notifications Implementation Guide

This document describes how the TTA Notifications can be used together with the current eOverdracht workflow model. It sits within a wider effort to harmonize the various Notified Pull transfer agreements (TA's) into a single, reusable workflow model for current and future workflows, based on the FHIR Clinical Order Workflow specification.

As FHIR COW-based specifications for other workflows emerge, further versions of this document will follow to reflect them.

Based on: 10.3.1.1 TTA Notifications, v0.4 Version: 0.2 (draft) Exchange agreement: eOverdracht (transfer of care between healthcare provider organisations) Status: Draft, based on a concrete SubscriptionTopic/Subscription proposal; not yet fully aligned across all stakeholders.

Conformance Language

Unless explicitly stated otherwise, properties and behaviours described in this document are required for conformance with the eOverdracht Notifications specification.

The key words SHALL, SHOULD and MAY are to be interpreted as follows:

• SHALL indicates a mandatory requirement.

• SHOULD indicates a recommended approach that ought to be followed unless there are valid reasons not to do so.

• MAY indicates an optional capability or behaviour.

Where a property is listed without an explicit conformance qualifier, SHALL is implied.

Roles

• Transferring organisation (the sender of the transfer of care) — the Subscription Server. Creates the Subscription and sends notifications when a Task relevant to the transfer changes.

• Receiving organisation — the Subscription Client. Receives notifications and, on receipt, pulls the referenced Task (and, from there, the transfer-of-care content) via a separate, authorised request.

Notification Pattern

Source Initiated Notifications (see TTA Notifications v0.4, Notification Patterns).

The Subscription is created by the transferring organisation, not the receiving organisation. This matches the Source Initiated pattern: the party that knows a transfer of care is taking place is also the party that establishes and manages the notification relationship.

Subscription creation: out-of-band. The SubscriptionTopic itself is published out-of-band — for eOverdracht, in the eOverdracht information standard/implementation guide rather than communicated live between systems — and the transferring organisation creates the Subscription directly, without a prior live request from the receiving organisation.

SubscriptionTopic

The eOverdracht SubscriptionTopic represents create and update events for transfer-of-care Tasks.

Required Properties

• SubscriptionTopic.url: https://landelijkafsprakenstelsel.nl/fhir/SubscriptionTopic/task

• SubscriptionTopic.resource: Task

• SubscriptionTopic.canFilterBy: owner (Task.owner), used to scope notifications to the intended receiving organisation.

Recommended Properties

• SubscriptionTopic.queryCriteria: code=http://snomed.info/sct|308292007

This limits the topic to Tasks representing a transfer of care and supports purpose limitation and data minimisation. The sender and receiver SHOULD include this criterion unless they have agreed to use a reusable Task SubscriptionTopic for multiple Task-based workflows.

{
  "resourceType": "SubscriptionTopic",
  "id": "TaskSubscriptionTopic",
  "url": "https://landelijkafsprakenstelsel.nl/fhir/SubscriptionTopic/task",
  "title": "Request - Task SubscriptionTopic",
  "description": "SubscriptionTopic for created or updated Task resources in the Request data category.",
  "status": "active",
  "resourceTrigger": [
    {
      "description": "Created or updated Task resources",
      "resource": "Task",
      "supportedInteraction": ["create", "update"]
    }
  ],
  "canFilterBy": [
    {
      "filterParameter": "patient",
      "filterDefinition": "http://hl7.org/fhir/SearchParameter/Task-patient"
    },
    {
      "filterParameter": "owner",
      "filterDefinition": "http://hl7.org/fhir/SearchParameter/Task-owner"
    }
  ]
}

Subscription

Created by the transferring organisation (the sender), based on:

{
  "resourceType": "Subscription",
  "id": "TaskTopicSubscriptionExample",
  "meta": {
    "profile": [
      "http://hl7.org/fhir/uv/subscriptions-backport/StructureDefinition/backport-subscription"
    ]
  },
  "status": "active",
  "reason": "Example topic-based Subscription for Task updates for a specific receiving organization",
  "criteria": "https://landelijkafsprakenstelsel.nl/fhir/SubscriptionTopic/task",
  "_criteria": {
    "extension": [
      {
        "url": "http://hl7.org/fhir/uv/subscriptions-backport/StructureDefinition/backport-filter-criteria",
        "valueString": "Task?owner=<URA van ontvanger>"
      }
    ]
  },
  "channel": {
    "type": "rest-hook",
    "endpoint": "https://example.org/fhir/Subscription/notification-endpoint",
    "payload": "application/fhir+json",
    "_payload": {
      "extension": [
        {
          "url": "http://hl7.org/fhir/uv/subscriptions-backport/StructureDefinition/backport-payload-content",
          "valueCode": "id-only"
        }
      ]
    }
  }
}

Example Task Resource

The Task instance is what this SubscriptionTopic monitors, and what the notification’s focus reference points to. It is illustrative, modeled on the actual eOverdracht Task profile (http://nictiz.nl/fhir/StructureDefinition/eOverdracht-Task ), which specifies:

• The Task instance SHALL be hosted on the server of the sending organisation (the Subscription Server here).

• Task.input (slice nursingHandoff) references the Composition that assembles the transfer-of-care content; the Task does not carry that content directly.

• When Task.input:nursingHandoff is populated, Task.owner MUST be populated with the receiving organisation.

Note: the published eOverdracht profile targets FHIR STU3, and the example below is kept in that native shape. This is possible because the notification mechanism (SubscriptionTopic, Subscription, notification Bundle) is a separate R4/R4B transport layer added on top — it doesn’t require the monitored resource itself to be re-expressed in R4/R4B; focus is just a reference, resolved by an ordinary GET against whatever version the sending server actually exposes.

{
  "resourceType": "Task",
  "id": "456",
  "meta": {
    "profile": ["http://nictiz.nl/fhir/StructureDefinition/eOverdracht-Task"]
  },
  "status": "in-progress",
  "intent": "order",
  "code": {
    "coding": [
      {
        "system": "http://snomed.info/sct",
        "code": "308292007",
        "display": "Transfer of care"
      }
    ]
  },
  "for": {
    "reference": "Patient/example"
  },
  "requester": {
    "agent": {
      "identifier": {
        "system": "http://fhir.nl/fhir/NamingSystem/ura",
        "value": "<URA van verzender>"
      }
    }
  },
  "owner": {
    "identifier": {
      "system": "http://fhir.nl/fhir/NamingSystem/ura",
      "value": "<URA van ontvanger>"
    }
  },
  "input": [
    {
      "type": {
        "coding": [
          {
            "system": "http://nictiz.nl/fhir/CodeSystem/TaskInputType",
            "code": "nursingHandoff",
            "display": "Nursing handoff"
          }
        ]
      },
      "valueReference": {
        "reference": "Composition/789"
      }
    }
  ]
}

Task.code uses the same SNOMED code (308292007, “Transfer of care”) proposed as the optional queryCriteria value for this SubscriptionTopic (see SubscriptionTopic), and Task/456/Composition/789 are the same identifiers referenced throughout the notification examples below.

Handshake

• Handshake: mandatory, per TTA Notifications v0.4 (channel.type is rest-hook).

• Heartbeat: not specified, because it is functionally not useful here: the transferring organisation already controls and verifies the channel via the mandatory handshake, so a missed delivery already surfaces through ordinary send failure and retry. Per TTA Notifications v0.4, a Subscription Client MAY still request a heartbeat interval when creating a Subscription in-band, but the Subscription Server is not obliged to support it.

Payload Mode

The TTA Notifications describes three type payload model: empty, id-only and full-resource. Of these ,only the first two are apply to the Notified Pull model, as used by eOverdracht. This draft version of the implementation guide refers to a separate document to give guidance on which model to use.

Complete Flow (id-only)

Example notification (R4, id-only)

{
  "resourceType": "Bundle",
  "type": "history",
  "entry": [
    {
      "resource": {
        "resourceType": "Parameters",
        "parameter": [
          { "name": "subscription", "valueReference": { "reference": "Subscription/TaskTopicSubscriptionExample" } },
          { "name": "topic", "valueCanonical": "https://landelijkafsprakenstelsel.nl/fhir/SubscriptionTopic/task" },
          { "name": "status", "valueCode": "active" },
          { "name": "type", "valueCode": "event-notification" },
          { "name": "events-since-subscription-start", "valueString": "42" },
          {
            "name": "notification-event",
            "part": [
              { "name": "event-number", "valueString": "42" },
              { "name": "timestamp", "valueInstant": "2026-07-16T09:15:00Z" },
              { "name": "focus", "valueReference": { "reference": "Task/456" } }
            ]
          }
        ]
      },
      "request" : {
        "method" : "GET",
        "url" : "https://sender.example/fhir/Subscription/TaskTopicSubscriptionExample/$status"
      },
      "response" : {
        "status" : "200"
      }
    }
  ]
}

Steps for the receiving organisation:

1. Receive the notification at its own notification endpoint, already carrying the Task reference: POST https://receiver.example/fhir/notifications

2. Read the focus reference directly — no search needed: GET https://sender.example/fhir/Task/456

3. Follow the Task’s reference to the transfer-of-care content and retrieve it via an authorised pull (out of scope of this document; see TA Pull): GET https://sender.example/fhir/Composition/789

Changes compared to v0.1

• Formatting of FHIR examples fixed.

• Missing elements of Notification resource example added.

• Option to filter by patient removed, as its not applicable to eOverdracht.

• Stricter SHALL/SHOULD specification of the ObservationTopic.

• id-only payload-mode no longer required. Referral to guidance document added.

• Paragraph describing the status of the document as a preliminary version added at the top.

• Title changed to reflect preliminary status

• Notification example specified as conforming to R4