eOverdracht Notifications Implementation Guide (v0.1)

eOverdracht Notifications Implementation Guide

Based on: 10.3.1.1 TTA Notifications, v0.4 Version: 0.1 (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.

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

{
  "resourceType": "SubscriptionTopic",
  "id": "TaskSubscriptionTopic",
  "url": "https://landelijkafsprakenstelsel.nl/fhir/SubscriptionTopic/task",
  "title": "Request - Task subscription topic",
  "description": "Subscription topic 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

Selected mode: id-only (see TTA Notifications v0.4, Notification Payload Model).

The notification references the changed Task; the transfer-of-care content itself is retrieved separately via an authorised pull, consistent with the Notified Pull pattern the eOverdracht information standard already uses. Empty and full-resource are not selected for eOverdracht (see Why not empty and Why not full-resource below).

Why id-only:

• Keeps clinical content off the notification channel entirely, consistent with minimum-necessary disclosure (see TTA Notifications v0.4, Notification Payload Model).

• Still identifies exactly which Task changed, via the focus reference, so the receiver can act on the notification directly.

• Matches what the eOverdracht standard’s own current notification mechanism already does: communicating the Task.id to the receiving organisation. Adopting id-only therefore changes only the delivery mechanism (a topic-based Subscription rather than an ad hoc POST), not the amount of information a notification discloses.

Why not empty: no focus reference, so the receiver can’t tell which Task changed without falling back to searching and reconciling — extra load, and ambiguous if several Tasks change at once.

Why not full-resource: pushes the Task itself over the channel, triggering the same consent/authorization obligations as any other disclosure (see TTA Notifications v0.4, Privacy, Consent, and Authorization). Unnecessary here: the Task is only a pointer, and the exchange agreement already relies on a separate, authorised pull for the actual content.

Complete Flow (id-only)

Example notification (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" } }
            ]
          }
        ]
      }
    }
  ]
}

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