10.3.1.2 | TA Workflow (v0.3)

Introduction

This Technical Agreement (TA) specifies a standards-based way to send a referral, order, or transfer from one care organization to another and to keep track of it until the work is done. It is built on COW IG and TA Notifications, and brings existing, separately developed Dutch agreements for this same problem together under a single, shared specification.

The conformance verbs SHALL, SHALL NOT, SHOULD, SHOULD NOT and MAY in this document are to be interpreted as defined in FHIR R4 (Conformance Rules, Conformance Language), when, and only when, they appear in capitals.

Context

Dutch healthcare organizations already exchange referrals, orders, and transfers between systems today, but they do so using at least two separately developed, incompatible mechanisms, and neither fully supports exchanging the status of that work once it is underway. The Technical Agreement Exchanging FHIR Data using a generic Notified Pull mechanism (TA NP) specifies one such mechanism, built for the exchange of the BgZ during a patient referral. The Nuts eOverdracht Bolt specifies another, built independently, on a similar timeline, for the nursing handover, a transfer of care.

Two national specifications, developed independently for closely related problems, cannot both remain the reference every new implementer is pointed to — harmonizing them is worthwhile. Doing so depends on two things being settled at the technical level:

• TA Notifications specifies the standardized Subscription and notification mechanism by which a party learns that a resource it does not own has changed.

• The forthcoming TA I&A specifies how the parties to an exchange identify, authenticate, and authorize one another.

Together, these give a harmonized specification the technical building blocks that neither TA NP nor eOverdracht had available when each defined its own mechanism.

These two agreements are not enough on their own. TA NP and eOverdracht each model the clinical workflow itself in their own way: a system built to one specification still cannot exchange a referral or transfer with a system built to the other, and a healthcare organization operating across both domains still needs two separate implementations to do what is, underneath, the same kind of work. The two domains are also not always separate processes: when an admitted patient moves from one hospital to another, the medical handover (TA NP) and the nursing handover (eOverdracht) belong to the same transfer and must be able to run as one integrated flow, yet each specification covers only its own half. Left alone, the divergence between the two specifications would only widen as each specification continues to evolve independently. Harmonizing the workflow model itself — not just the transport it travels over — is what allows an organization to build and maintain one implementation instead of two.

It also does something neither original specification could, precisely because each was written for one use case at a time: a harmonized model is general enough that referral, order, and transfer are simply particular instances of it, so that the next use case this ecosystem needs is described as a profile of something that already exists, rather than specified again from first principles.

This Technical Agreement is that model. It specifies, in one place, a standards-based way to exchange clinical workflow status for orders, referrals, and transfers, so that the agreements currently expressed via TA NP and via eOverdracht can each be specified and implemented as a profile of it.

Scope

In scope

• Exchanging clinical workflow status between a Placer and a Fulfiller.

• Hosting, creating, and updating a Coordination Task at the Placer, and the FHIR profile constraining it.

• The standing Subscription and notification mechanism informing a Fulfiller of relevant Task changes.

• The payload mode of the notification, and the requirements on the ids of Tasks and Subscriptions.

• Sharing content in Task.input, beyond the standard dataset where the Request has one.

• The Multiple Fulfillers Pattern, including bidding by candidates, and the simpler case of a single, already-known Fulfiller.

• Conformance to TA Routing.

• Conformance to GF Addressing, independently of TA Routing.

Out of scope

• Identification, authentication, and authorization of the parties — the subject of the forthcoming TA I&A.

• How the Placer learns that a healthcare service is split, merged, renamed or retired. This follows from GF Addressing (see Changes to healthcare services).

• How a Placer weighs the responses of the candidates and decides which one to select among multiple Fulfillers. Responses of the candidates such as accepting and bidding, and the recording of the decision, are in scope.

• The SubscriptionTopics of the individual use cases. Each use case that is specified as a profile of this TA defines its own topics (see SubscriptionTopic).

Vocabulary

Basis of this TA

Base Specifications

Relationship to COW IG

COW IG was chosen as the base resource and workflow model for four reasons: it is generic enough to cover order, referral, and transfer workflows alike, rather than one at a time; complete enough that this TA needs no invented extension to address the core problem; pitched at the right level of detail to be profiled rather than rebuilt; and an international standard, keeping this TA aligned with an ecosystem wider than the Netherlands alone.

COW IG cannot serve as a technical agreement on its own. Its generality is deliberate: it leaves open many of the choices two systems must agree on to actually interoperate, and implementers left free to make those choices differently produce systems that are each individually COW-conformant yet unable to exchange anything with one another.

This TA is a profile of COW IG, not an extension of it. It makes binding choices among the options COW IG already permits — which hosting pattern applies, which values Task.code takes, how cancellation is realized — so that independently built systems converge on one behavior. It does not add resource types, elements, or mechanisms beyond what COW IG itself defines, apart from a code system with eight codes: request-fulfillment for Task.code, selected, awaiting-information and visit-scheduled for Task.businessStatus, not-selected for Task.statusReason, and type-of-work, supplemental-resource and supplemental-query for Task.input (see Codes of this TA), and the use of the HL7 extension cqf-fhirQueryPattern to describe a standard dataset (see Retrieving the resources of a dataset). Where this TA is silent, COW IG's own guidance applies unmodified.

This TA refers to COW IG version 1.0.0-ballot. A later version of COW IG applies only once a later version of this TA refers to it.

Design Choices

This section states, for each major choice this TA makes within COW IG's model, why it was made this way rather than left to individual implementers.

Task at Placer, not Task at Fulfiller

COW IG names two patterns for where the Coordination Task is hosted. This TA fixes it at the Placer. TA NP's own persistent, status-bearing resource (the Workflow Task) is already hosted at the Sending System — the Placer, in COW IG's terms — and eOverdracht's Task is likewise hosted at the bronhouder (the source holder), for the same reason its own specification gives: keeping data at the source. Both existing agreements, developed independently of each other and of COW IG, already converge on this hosting choice.

The Multiple Fulfillers Pattern is adopted, not only the simpler single-performer case

Some use cases need to offer one patient to several candidate organizations in parallel, for example a transfer of care. A specification that covered only a single performer would leave those use cases out, so this TA adopts the Multiple Fulfillers Pattern as COW IG describes it.

The pattern has two further uses:

• Bidding. Candidates can do more than accept: they can describe what they would offer, so that the Placer can compare them before one is selected (see Bidding).

• Negotiation with one candidate. A genuine negotiation before a Request is finalized can be useful even with exactly one Fulfiller under consideration. Many Requests with a single Fulfiller need no negotiation at all (see Single Fulfiller Pattern).

Task.owner and Task.location resolve to HealthcareService and Location, not Organization

Notifications are addressed to the people who must act on them. An organization is too coarse for that. TA Routing allows several kinds of routing label, including (sub-)organizations, but specifies that Task.owner refers to the HealthcareService responsible for carrying out the Request. This TA follows TA Routing and allows only that type of owner, so that the Subscription filter, the notification endpoint and access control each work in one way. An organization or sub-organization that receives Tasks as a whole registers a HealthcareService for that purpose in GF Addressing:

• Task.owner identifies the HealthcareService that is asked to carry out the work.

• Task.location identifies the Location at which the work is to be carried out. A HealthcareService can be performed at several physical Locations, and a Placer can request care at a specific one. (TA Routing)

The Subscription follows the service, not the organization:

• A Subscription is established per HealthcareService, per topic and per base URL of the Placer. It has one notification endpoint, and in TA Routing that endpoint belongs to the service.

• This TA cannot assume that all services of a Fulfiller share one endpoint. A Subscription per service works in every case; a Subscription for the whole organization would not.

• TA Routing lets an ActivityDefinition carry an endpoint that takes precedence over the endpoint of the HealthcareService. This TA does not use it: a Subscription filters on Task.owner, and the definition is referred to from the Request, not from the Task, so a Subscription cannot select an endpoint per definition. A Fulfiller that needs a separate endpoint for some of its definitions registers a separate HealthcareService for them in GF Addressing.

• Task.location plays no part in the Subscription, and the notification endpoint is that of the HealthcareService, not of the Location.

Topics are defined per use case, not by this TA

TA Notifications places the definition of a topic in the use-case-specific technical agreement. This TA is the generic layer under several use cases, so it states the requirements that every topic meets, and each use case defines its own topic. There are three reasons for one topic per use case rather than one topic for all work:

• Authorization of a notification covers at least its SubscriptionTopic (TA Notifications). One topic per use case allows a different basis for each type of work.

• A candidate may not read the Request before it is selected, unless the use case states otherwise (see Patient context and readability). A topic per use case lets it know the type of work it is invited for.

• TA Notifications foresees specialising a generic Task topic for a use case with a coded trigger condition.

Topics trigger on create and update, not create alone

eOverdracht notifies on every Task change without exception, and TA NP's own mechanisms for both dataset updates and cancellation are update-triggered, not creation events. A topic that only covered create could not be specified as a profile of either.

Task.groupIdentifier is not used to link Tasks to the same Request

TA NP and eOverdracht each attach their own meaning to this element, and those meanings are incompatible with each other, so this TA does not add a further use to it. Linking Tasks to a Request is also unnecessary: Task.focus is mandatory in the profile of this TA, so Coordination Tasks that compete for the same Request can already be recognized by their shared reference to it.

The notification is id-only

The Task is addressed to a single receiver, and for such a resource TA Notifications says that id-only should be used in preference to empty. A full-resource notification would put a Task, which refers to a patient, into the notification itself, which is a disclosure of its own.

Actors

The obligations of each actor are listed in two groups. The first group follows from COW IG and is repeated here for completeness; this TA adds nothing to it. The second group is specified by this TA: a choice or an addition of this TA, which may build on another specification named in parentheses.

Placer

The Placer:

Follows from COW IG

• SHALL create the Request, hosted on its own FHIR server, and is the only party that modifies the Request directly.

• SHALL create a Coordination Task that refers to the Request, for the Fulfiller that is to carry it out.

• MAY cancel the Coordination Task before the work has started, and SHALL use a Cancellation Request Task to stop work that has started (see Cancellation (Before in-progress) and Cancellation Request (After in-progress)).

• SHALL, whenever a Coordination Task reaches an end status (completed, failed, rejected, cancelled or entered-in-error), decide what happens to the Request and update Request.status where required.

• With several candidates, SHALL select one and cancel the Coordination Tasks of the others (see Multiple Fulfillers Pattern).

Follows from TA Notifications

• SHALL have the FHIR base URL at which it hosts its Coordination Tasks registered in GF Addressing as an Endpoint of the Placer, with connectionType hl7-fhir-rest, payloadType Subscription and a payloadMimeType with fhirVersion=4.0. That base URL MAY be registered for several Placers; a Subscription at that base URL then concerns the Coordination Tasks of each of them.

Specified by this TA

• SHALL host the Coordination Task on its own FHIR server (COW IG allows either hosting pattern; see Design Choices).

• SHALL make sure that, when a HealthcareService of a Fulfiller is onboarded, a Subscription is established for that service and each topic under which it receives Tasks, at the base URL at which the Placer hosts its Coordination Tasks, by creating it out-of-band or, where the use case specifies in-band creation for the topic, by accepting it in-band (see Subscription). (TA Notifications)

• SHALL NOT create a Coordination Task for a HealthcareService under a topic unless a Subscription for that service and topic exists at the base URL at which it hosts that Task, with status active or error (see Subscription).

• SHALL grant the Fulfiller access to the Coordination Task for which the Fulfiller is accountable, limited to the elements that the Fulfiller may change (see Resource Definitions → Coordination Task → Write access), and SHALL record the identification of the accountable organization when it creates the Task (see Coordination Task).

• SHALL NOT create a Coordination Task, or create or accept a Subscription, for an owner identifier that does not resolve to exactly one HealthcareService (see Coordination Task and Subscription).

• SHALL act on the end of a Coordination Task as specified in Handling the End of a Coordination Task.

• MAY invite bids by creating a bidding task for each candidate (see Bidding).

• SHALL answer an Authorization Cancellation Request Task by setting its status to accepted or rejected (see Cancellation by the Fulfiller).

Fulfiller

The Fulfiller:

Follows from COW IG

• SHALL update the Coordination Task on the server of the Placer to report the progress of the work.

• MAY reject the Coordination Task, with a statusReason.

• MAY set the Coordination Task to failed when it can no longer carry out the work (see Cancellation by the Fulfiller).

• SHALL accept or reject a Cancellation Request Task.

• MAY ask the Placer to cancel the Request itself (see Cancellation by the Fulfiller).

Specified by this TA

• SHALL have every HealthcareService through which it receives Tasks under this TA registered in GF Addressing, with its notification endpoint, and the Locations at which these services are performed. A service that is not registered cannot receive Tasks (see Coordination Task). (GF Addressing)

• SHALL authenticate to the Placer on every read or write of the Coordination Task.

• SHALL make its changes as an update (PUT or PATCH) on the Placer’s server, changing only status, businessStatus, statusReason, executionPeriod, lastModified and output of the Coordination Task, and making them version-aware (see Write access).

• SHALL set the Coordination Task to failed, with a statusReason, after it has accepted a Cancellation Request Task (see After an accepted Cancellation Request).

• SHOULD support the ActivityDefinitions and PlanDefinitions that its HealthcareService lists (see Routing by the Fulfiller).

• MAY respond to a bidding task with a bid (see Bidding).

Resource Definitions

Profiles

Task profiles

This TA uses the FHIR Task resource, a general-purpose resource for tracking a piece of work. A FHIR profile narrows a general resource for a specific purpose: it states which elements must be filled in, which values are allowed, and how elements are to be used. This TA uses three profiles of Task and one profile of Subscription:

• The Coordination Task follows one Fulfiller's handling of one Request, from the moment the Request is sent until the work ends. It refers to the Request, names the Fulfiller asked to carry it out, and carries the status of the work. The Placer and the Fulfiller both use it to see where the work stands.

• The Cancellation Request Task is used by the Placer to ask the Fulfiller to stop work that has already started. It refers to the Coordination Task to be cancelled, and the Fulfiller answers by accepting or rejecting it.

• The Authorization Cancellation Request Task is used by a Fulfiller to ask the Placer to withdraw the Request itself, because it finds the Request inappropriate or even dangerous. It refers to the Request, and the Placer answers by accepting or rejecting it.

• The Subscription is used by the Fulfiller, through its HealthcareService, to be notified of changes to the Tasks it owns. It refers to the topic of a use case and filters on the HealthcareService. It builds on the Subscription profile of TA Notifications, which builds on that of the Subscriptions R5 Backport IG.

The Coordination Task and the Cancellation Request Task build on the profiles of the same names in COW IG, which define the minimum expectations for these Tasks. COW IG defines no profile for the Authorization Cancellation Request Task; it gives an example, and asks in its ballot whether it should become a separate profile. This TA adds further requirements, described in the sections below.

In addition, this TA uses a profile of ServiceRequest for the Request, which states the requirements of this TA on the ServiceRequest (see Request and Patient context and readability). COW IG defines no profile for the Request.

The formal definitions of these five profiles, of the CapabilityStatement of the Placer’s server, and of the code system and value sets of this TA are published in its implementation guide, package nl.twiin.fhir.r4.workflow, version 0.3.0-draft: https://fhir.twiin.nl/ig/workflow/0.3.0-draft/en/. The implementation guide expresses the requirements of this TA and adds none of its own; where it and this TA differ, this TA applies. The rules that a profile cannot express are text of this TA only.

Summary of the profiles

The tables below summarize the five profiles. Elements that are not listed are not constrained by this TA. The column R4 gives the base definition in FHIR R4, and the column COW IG gives the profile of the same name in COW IG. Some entries leave a value to the use case, such as the type of work, the topic and the heartbeat interval (see Use-case agreements under TA Notifications).

Coordination Task

The Fulfiller may change only status, businessStatus, statusReason, executionPeriod, lastModified and output (see Write access).

Cancellation Request Task

The Fulfiller may change only status and statusReason of a Cancellation Request Task.

Authorization Cancellation Request Task

The Fulfiller sets all elements at creation and does not change them afterwards. The Placer changes only status and statusReason.

ServiceRequest

Subscription

Rules that a profile cannot express

These rules remain text of this TA, or are declared in the CapabilityStatement of the Placer's server:

• that an owner identifier resolves to exactly one HealthcareService;

• that Task.owner and Task.location refer to a HealthcareService and a Location as profiled by GF Addressing (NL-GF-HealthcareService, NL-GF-Location), by the identifier from their AssignedId slice;

• that a Coordination Task is created only for a HealthcareService and topic with a Subscription, at the base URL at which the Task is hosted, with status active or error;

• the permitted status changes and who makes them;

• that updates by the Fulfiller are version-aware;

• that the Placer’s server rejects a move to in-progress while Task.code is request-fulfillment;

• that Task.for is empty while Task.code is request-fulfillment, unless the use case identifies the patient before selection;

• that exactly one candidate is selected, and only one whose Coordination Task has the status accepted;

• that no two Coordination Tasks for the same Request, whose status is not an end status, are owned by HealthcareServices of the same Fulfiller while either has Task.code request-fulfillment;

• that a Cancellation Request Task is created only when the Coordination Task is in-progress;

• that Task.owner of a Cancellation Request Task is the same HealthcareService as Task.owner of the Coordination Task it refers to;

• that the entry with type type-of-work of a Cancellation Request Task has the same value as that of the Coordination Task it refers to;

• that an Authorization Cancellation Request Task is created only by a Fulfiller that has a Coordination Task with Task.code fulfill for the same Request, whose status is not cancelled or entered-in-error;

• that ServiceRequest.code carries the code of the ActivityDefinition to which ServiceRequest.instantiatesCanonical refers, where that ActivityDefinition has a code;

• that ServiceRequest.performer remains unset in the Multiple Fulfillers Pattern until a candidate is selected;

• that the filter of a Subscription identifies exactly one HealthcareService;

• that channel.endpoint of a Subscription begins with the address of a notification endpoint of that HealthcareService;

• that there is one Subscription per HealthcareService, topic and base URL.

Coordination Task

The elements of the Coordination Task are restricted as in the table in Summary of the profiles. The following rules apply in addition.

Follows from COW IG

• A Coordination Task is created by the Placer for the Fulfiller that is to carry out the Request (see Task Creation).

Specified by this TA

• The Coordination Task is hosted on the Placer's own FHIR server. How the Placer creates it there is not specified by this TA (COW IG allows either hosting pattern; see Design Choices).

• The Placer SHALL NOT create a Coordination Task for an owner identifier that does not resolve to exactly one HealthcareService in GF Addressing, in the replica of the directory that the Placer uses to select the Fulfiller (see the assumption about GF Addressing under Search parameters).

• When the Placer creates a Coordination Task, it records the identification of the organization that is accountable for the Task: the organization that provides the HealthcareService it selected as Task.owner. The Placer takes this identification from the directory data at the moment of selection and keeps the record internally; it is not an element of the Task. The Placer applies the same record to the Cancellation Request Task of that Coordination Task. When it decides whether a Fulfiller may read or write a Task, the Placer uses this record and the authentication of the Fulfiller, and SHALL NOT use directory data. How the Fulfiller authenticates is the subject of TA I&A.

Write access

Follows from FHIR R4

• An update (PUT) replaces the whole resource.

Specified by this TA

• The Fulfiller SHALL authenticate on every read or write; access is verified per interaction.

• The Placer SHALL grant the Fulfiller access only to the Coordination Tasks for which the Fulfiller is accountable, and within those only to the elements that the Fulfiller may change (see below). The Fulfiller is accountable for a Coordination Task when the identity of the zorgaanbieder in its authentication is the identity that the Placer recorded for that Task when it created it. The identity of a GTK through which the Fulfiller connects does not suffice, since a GTK may act on behalf of several zorgaanbieders. The Placer SHALL allow the Fulfiller to read every element of its own Coordination Task.

• The Fulfiller MAY change only the elements marked Fulfiller in the column Written by of the table Coordination Task in Summary of the profiles: status, businessStatus, statusReason, executionPeriod, lastModified and output. All other elements are set by the Placer and SHALL NOT be changed by the Fulfiller. The Placer sets focus, requester, owner and authoredOn once, at creation.

• The Fulfiller SHOULD set Task.executionPeriod.start when it moves Task.status to in-progress, and Task.executionPeriod.end when it moves Task.status to completed or failed.

• A party that changes the Coordination Task MAY set Task.lastModified to the time of that change.

• Within the writable elements, two values are reserved for the Placer: the code not-selected in Task.statusReason and the code selected in Task.businessStatus (see Reason for cancelling a non-selected candidate and Business status).

• Either party MAY set Task.businessStatus to report progress within a status (see Business status). The Placer sets selected at selection; a later update by the Fulfiller replaces it, and the Placer recognizes the selected candidate by Task.code fulfill.

• The Placer's server SHALL check every update by the Fulfiller and reject it if it changes an element other than the ones named above, or changes an element to a reserved value. Sending a reserved value that the Placer has set, unchanged, is not a change.

• A Fulfiller that uses a full update (PUT) sends the Task with all other elements unchanged.

• The Fulfiller MAY create an Authorization Cancellation Request Task on the Placer's server. The Placer's server SHALL accept the create only when the identification in the authentication of the Fulfiller equals the identification recorded for a Coordination Task whose Task.focus refers to the same Request, whose Task.code is fulfill, and whose status is not cancelled or entered-in-error, and SHALL check the elements against the table Authorization Cancellation Request Task in Summary of the profiles. The Placer records this identification for the Authorization Cancellation Request Task as well. The Placer SHALL allow the Fulfiller to read the Authorization Cancellation Request Tasks it has created. The Fulfiller SHALL NOT change them after creation.

Concurrent writes

The first three rules below use mechanisms of the RESTful API of FHIR R4 for managing resource contention and for declaring capabilities. Those mechanisms are defined there, and this TA requires their use between the Placer and the Fulfiller. The last rule is an addition of this TA and is not defined by FHIR.

• An update by the Fulfiller SHALL be version-aware. The Fulfiller reads the Coordination Task, takes its version from the ETag, and sends that version in the If-Match header of its update. The Placer's server SHALL reject an update on a version that is no longer current with 412 Precondition Failed. The Fulfiller then reads the Task again and decides again. (FHIR R4, Managing Resource Contention and update)

• The Fulfiller MAY change the Coordination Task with PUT or with PATCH. A PATCH document is a JSON Patch (application/json-patch+json) and is version-aware in the same way. (FHIR R4, PATCH) The Placer's server SHALL support JSON Patch.

• The Placer's server SHALL declare the versioning level versioned-update in its CapabilityStatement (see Placer server capabilities). (FHIR R4, CapabilityStatement)

• The Placer bases its own updates of a Coordination Task on the current version in the same way, so that it does not overwrite an update by the Fulfiller.

Status of the Coordination Task

Follows from COW IG and FHIR R4

• The statuses are the codes of the TaskStatus code system of FHIR R4, and the transitions follow the typical state machine of FHIR R4 (see the figure below). The diagram has no move from in-progress to cancelled. (FHIR R4)

• The workflow meaning of Task.status comes from the Workflow State Overview of COW IG, and the rules for stopping work that has started from the cancellation rules of COW IG. To stop work that has started, the Placer creates a Cancellation Request Task. (COW IG)

Specified by this TA

• This TA adds no states.

• The statuses draft, ready and on-hold are not used by this TA.

• A Fulfiller moves Task.status to accepted before it moves it to in-progress, in every pattern. This TA adds no direct move from requested or received to in-progress.

• What accepted means depends on Task.code (FHIR R4, TaskStatus). With Task.code fulfill, the Fulfiller will carry out the work. With Task.code request-fulfillment, the candidate states that it can carry out work of this type and would do so if selected; this does not imply selection, and the candidate may not start the work (see Recognizing the pattern that applies and Bidding). When the Placer selects the candidate and sets Task.code to fulfill, the status stays accepted, and the acceptance becomes the agreement to carry out the work (COW IG, Workflow State Overview).

• Where this TA uses a transition that the diagram does not show, this is stated.

• A Fulfiller that has accepted, and finds that it can no longer carry out the work, MAY move Task.status from accepted to failed, with statusReason (COW IG, Fulfiller Unable to Perform). The typical state machine of FHIR R4 does not show this move, but FHIR R4 allows workflows to support additional transitions (FHIR R4, Task state machine). The Fulfiller does not set cancelled instead: under this TA only the Placer sets cancelled, so that cancelled always means that the Placer withdrew the Task (FHIR R4, Task, The Cancelled state).

• The move to in-progress has consequences: from then on the Placer cannot cancel the Coordination Task, and uses a Cancellation Request Task instead (see Cancellation Request (After in-progress)), and the Fulfiller sets Task.executionPeriod.start (see Write access). FHIR R4 defines in-progress as a task that has been started but is not yet complete, without stating when work counts as started (FHIR R4, TaskStatus). Each use case SHALL state when the work counts as started for its type of work (see Use-case agreements under TA Notifications). The Fulfiller SHALL NOT move the Coordination Task to in-progress before that point.

Business status

• A Fulfiller that awaits information sets awaiting-information and states what it needs in Task.statusReason.text. The Placer provides the information as the use case defines, for example in Task.input (see Sharing additional content), and the Fulfiller then sets another value or removes it. (COW IG)

• A use case MAY define further codes.

Cancellation Request Task

The elements of the Cancellation Request Task are restricted as in the table in Summary of the profiles. The following rules apply in addition.

Follows from COW IG

• A Cancellation Request Task SHALL be created by the Placer when Task.status has already reached in-progress on the Coordination Task it targets.

Specified by this TA

• The Cancellation Request Task is created on the Placer's own FHIR server.

• The Coordination Task is in-progress when a Cancellation Request Task is used, so it SHALL NOT be set to cancelled: COW IG treats the absence of a move from in-progress to cancelled in the state machine of FHIR R4 as a requirement, which the Cancellation Request Task exists to meet (COW IG, Placer Initiated Cancellations). When the Fulfiller accepts the Cancellation Request Task, it sets the Coordination Task to failed (see After an accepted Cancellation Request).

• The Placer MAY withdraw a Cancellation Request Task that the Fulfiller has not yet answered, by setting its status to cancelled; the work on the Coordination Task then continues. The Placer sets a Cancellation Request Task that it created by mistake to entered-in-error. A Cancellation Request Task takes no other statuses than requested, accepted, rejected, cancelled and entered-in-error.

Request and patient

Request

The Request is the ServiceRequest that states what is being asked for; every Coordination Task refers to one. The requested service is identified by ServiceRequest.code. Where a definition of the service exists, the Request can refer to it, and the definition can describe a standard dataset: the baseline set of information a Fulfiller needs to carry the Request out, which would otherwise have to be negotiated case by case. A Request needs neither a definition nor a standard dataset.

Follows from COW IG and TA Routing

• A Request resource SHALL exist for every Coordination Task. (COW IG)

• Request.status is changed only by the Placer, as the party that created the Request. (COW IG)

• ServiceRequest.instantiatesCanonical MAY additionally reference an ActivityDefinition or a PlanDefinition, where a bare code is not precise enough. A PlanDefinition is a composite of ActivityDefinitions; the same rules apply to both. (TA Routing)

• Where a directory defines an ActivityDefinition or PlanDefinition for a service, a receiving server MAY decline a Request that does not reference it via instantiatesCanonical, or that does not adhere to its requirements. (TA Routing)

• The Request is a ServiceRequest: the Coordination Task profile of COW IG restricts Task.focus to ServiceRequest. (COW IG)

Specified by this TA

• Where ServiceRequest.instantiatesCanonical refers to an ActivityDefinition that has a code, ServiceRequest.code SHALL carry that code, as applying an ActivityDefinition maps ActivityDefinition.code to ServiceRequest.code (FHIR R4, ActivityDefinition, Applying an ActivityDefinition). A PlanDefinition has no such code; ServiceRequest.code then states the requested service as for any Request.

• ServiceRequest.performer SHALL remain unset in the Multiple Fulfillers Pattern until a candidate is selected (see Multiple Fulfillers Pattern).

• ServiceRequest.instantiatesCanonical MAY refer to the ActivityDefinition or PlanDefinition of the requested service, which describes the standard dataset where it has one (see Retrieving the resources of a dataset). A Request that refers to no definition is valid under this TA.

• ServiceRequest.code SHALL be populated, so that the requested service can be routed also when ServiceRequest.instantiatesCanonical is absent (see Routing by the Fulfiller).

Request types other than ServiceRequest

The narrative of COW IG mentions request types other than ServiceRequest: DeviceRequest, MedicationRequest, NutritionOrder, SupplyRequest and VisionPrescription. Its Coordination Task profile (version 1.0.0-ballot), however, restricts Task.focus to ServiceRequest. This TA builds on that profile, so the Request is a ServiceRequest, and the rules of this TA on specific elements are written for ServiceRequest. Should a later version of COW IG allow other request types, a later version of this TA can reconsider this.

Retrieving the resources of a dataset

A Request has a standard dataset only where the definition in ServiceRequest.instantiatesCanonical describes one (see Request).

The ActivityDefinition or PlanDefinition of the Request refers in its element library to a Library. The dataRequirement of that Library describes the standard dataset, one DataRequirement per part of the dataset. A definition without a library, or a Library without dataRequirement, describes no standard dataset. Each DataRequirement carries one or more searches in the extension cqf-fhirQueryPattern (FHIR Extensions Pack). A search is relative to the FHIR base of the Placer, and the token {{context.patientId}} stands for the id of the Patient that Task.for refers to. A Fulfiller runs these searches after it is selected, when it may read the Request and the Patient (see Patient context and readability). Task.input carries only content beyond the standard dataset (see Sharing additional content).

The dataset is described once, by its owner, and not listed on each Task, as TA NP does for the BgZ: a list on the Task would show which data are recorded about the patient.

Where ServiceRequest.instantiatesCanonical is absent, or the definition describes no standard dataset, the Request has none. The Placer then shares the data the Fulfiller needs, if any, in Task.input (see Sharing additional content). A request may need no data at all.

Sharing additional content

The Placer MAY share content that the Fulfiller needs to carry out the work, beyond the standard dataset where the Request has one. This content is supplied with the Coordination Task, in Task.input. Each entry of Task.input has a type, which says what the content is, and a value, which is the content or a reference to it.

Specified by this TA

• Content that relates to why the Request was authorized, or what is authorized, belongs to the Request (Request.supportingInfo). Content that relates to how the Request is to be fulfilled belongs to the Task (Task.input). This is a choice of this TA, in line with guidance in the continuous build of COW IG, which the ballot version does not contain.

• The Placer sets and changes Task.input. It is not one of the elements that the Fulfiller may change (see Write access).

• Before selection, Task.input carries the type of work, entries that do not concern the patient, and entries that concern the patient without identifying the patient, where the use case states why they are not identifying. These entries carry their content in the entry itself, since a candidate may not read resources at the Placer before selection. Entries with type supplemental-resource or supplemental-query, and entries that identify the patient, are added when the Placer selects the candidate, or at creation in the Single Fulfiller Pattern or where the use case identifies the patient before selection (see Patient context and readability).

• A change of Task.input is a change of the Coordination Task, and reaches the Fulfiller through the notification of that change, in the same way as any other update by the Placer.

• The Placer SHALL share data that it holds beyond the standard dataset in entries with one of these types, from the code system of this TA (see Codes of this TA):

  • supplemental-resource, with in valueReference a reference to one resource at the Placer;

  • supplemental-query, with in valueString a search relative to the FHIR base of the Placer.

• These correspond to read-available-resource and query-available-resources of TA NP.

• Other content, such as instructions, MAY be shared in entries with a type that the care domain defines. What such an entry contains is not defined by this TA. An entry with content beyond the standard dataset SHALL NOT use the type type-of-work.

Patient context and readability

Requirements of COW IG and FHIR R4

• The Coordination Task refers to the Request in Task.focus, which is mandatory. (COW IG)

• Task.for is not constrained by COW IG. In FHIR R4 it is optional and can refer to the Patient; Task.for.identifier can carry an identifier of the patient. (COW IG, FHIR R4)

• Every ServiceRequest has a subject: ServiceRequest.subject is mandatory. (FHIR R4)

Functional requirement

During the preliminary phases of the workflow, a candidate Fulfiller is not given the identity of the patient, unless the use case requires it. The preliminary phases are the phases before the candidate is selected.

Solution, specified by this TA

• ServiceRequest.subject SHALL reference a Patient. A Group, a Location or a Device is not supported, and neither is leaving out or masking the subject, for example with the extension data-absent-reason.

• Until a candidate is selected, the Placer SHALL NOT give it read access to the Request or to the Patient resource, unless the use case identifies the patient to candidates before selection.

• Where the use case identifies the patient before selection, the Placer SHALL withdraw the read access of a candidate to the Request and the Patient resource when it cancels the Coordination Task of that candidate.

• Until a candidate is selected, Task.for of its Coordination Task SHALL be empty, and the Task SHALL NOT carry information that identifies the patient, also not in Task.location or in further entries of Task.input. Entries of Task.input MAY concern the patient without identifying the patient, where the use case states why they are not identifying. A use case MAY instead state that the patient is identified to candidates before selection, and on what basis (see Use-case agreements under TA Notifications); the Placer then sets Task.for at creation and gives each candidate read access to the Request and the Patient resource from creation.

• Before selection, the Coordination Task carries the identifier and id of the Task, its status and code, the reference to the Request in Task.focus, the Placer in Task.requester, the HealthcareService of the candidate in Task.owner, Task.authoredOn, the Location of the service in Task.location, the type of work in Task.input, and the further entries of Task.input that are allowed before selection. These identify the parties, the place and the kind of work, not the patient. The ids are opaque (see Identifiers of Tasks and Subscriptions), so the reference in Task.focus reveals nothing about the Request, which the candidate may not read. Task.location refers to a Location registered in GF Addressing, not to the address of the patient. What a candidate learns is that the Placer asks for this type of work, for an unnamed patient, at this place and time. Where few patients receive a type of work at a place, this can narrow the patient down; that is why the use case states why its type of work, and the further entries it adds before selection, are not identifying (see Use-case agreements under TA Notifications).

• When the Placer selects a candidate, it sets Task.code fulfill, and Task.for where it is not yet set, in the same update in which it sets Task.businessStatus to selected. From then on the candidate may read the Request and the Patient resource.

• In the Single Fulfiller Pattern the Fulfiller is selected from the creation of the Task, so the Placer SHALL set Task.for at creation, and the Fulfiller may read the Request from the start.

Task.for refers to the Patient by Reference.reference. Task.for.identifier SHOULD NOT be populated: identifiers of the patient, including those that the law requires to accompany personal data, are carried in Patient.identifier of the Patient resource to which Task.for refers.

The patient is referred to in these places:

What a candidate may read in each phase:

Routing by the Fulfiller

A notification tells the Fulfiller that a Coordination Task it owns has been created or changed. The topic of the Subscription and the entry with type type-of-work in Task.input indicate the type of work, also before the Fulfiller is selected, but not the details of the work, or where it is to be carried out (see Type of work on the Task). The Fulfiller finds this out after reading the Task, from the Request that Task.focus refers to and from Task.location:

Follows from TA Routing

• ServiceRequest.code states the type of service that is requested.

• ServiceRequest.instantiatesCanonical, where present, refers to an ActivityDefinition or a PlanDefinition that describes how the service is requested and what it requires.

• The HealthcareService that owns the Task publishes the services it supports as codes in HealthcareService.type, and optionally the ActivityDefinitions and PlanDefinitions that describe them, in the extension supportedActivityDefinitions on HealthcareService.type. It lists only the ActivityDefinitions and PlanDefinitions that it supports. (TA Routing; GF Addressing, NL-GF-HealthcareService).

• Task.location, where present, identifies the Location at which the work is to be carried out. A HealthcareService can be performed at several physical Locations, and a Placer can request care at a specific one.

• Task.code does not carry the kind of work: it states what the owner is expected to do with the Request (see Task.code under Coordination Task).

Specified by this TA

• The Fulfiller SHOULD support the ActivityDefinitions and PlanDefinitions that its HealthcareService lists: when a Request refers to such a definition, the Fulfiller SHOULD be able to resolve it and to process a Request according to it.

• Supporting a definition does not oblige the Fulfiller to accept a Request: the Fulfiller MAY decline any Request, including one that refers to a definition it supports, by rejecting the Coordination Task.

• The Fulfiller uses the information above to route the Request to the right internal process and, where Task.location is present, to the right Location, or to decline it (see Request).

• Where the Request refers to no definition, the Fulfiller routes the Request on ServiceRequest.code alone.

Identifiers and search

Search parameters

Tasks are found, and Subscriptions filtered, by the business identifier of Task.owner and Task.requester. This TA uses the search parameters owner and requester that FHIR R4 defines on Task, with the modifier :identifier. It defines no search parameters of its own.

Follows from FHIR R4

• Task has the search parameters owner, on Task.owner, and requester, on Task.requester, both of type reference. (FHIR R4, Task)

• The modifier :identifier searches a reference by Reference.identifier instead of by the literal reference. The value is a token of the form <system>|<value>. (FHIR R4, Search)

• A CapabilityStatement has no element to declare support for a modifier; it is stated in searchParam.documentation. (FHIR R4, CapabilityStatement)

Specified by this TA

• This TA defines no new identifier systems. Where this TA identifies an Organization by its URA, in Task.requester.identifier and in Task.owner.identifier of an Authorization Cancellation Request Task, it uses the system http://fhir.nl/fhir/NamingSystem/ura; a party that takes the URA from GF Addressing with another system records it there with this system, and the value is unchanged. A HealthcareService and a Location are identified by the identifier with which they are registered in GF Addressing, from the AssignedId slice of NL-GF-HealthcareService and NL-GF-Location, unchanged, including its assigner; the assigner carries the URA with the system that GF Addressing prescribes.

• A HealthcareService or Location whose AssignedId has an assigner identified otherwise than by a URA, such as by a KvK number, cannot be referred to as the owner or location of a Task under this TA.

• The Placer:

  • SHALL support the search parameters owner and requester on Task with the modifier :identifier, and declare them in its CapabilityStatement (see Placer server capabilities).

  • SHALL support owner:identifier in the filter of a Subscription (see Subscription).

  • SHALL record in Task.owner.identifier the identifier with which the HealthcareService is registered in GF Addressing, and in Task.requester.identifier the URA of the Placer, as stated above. A Task that carries only a literal Reference.reference is not found by these searches.

• The Fulfiller:

  • SHALL use owner:identifier, with the identifier of its HealthcareService, in the filter of its Subscription (see Subscription) and when it searches the Placer's server for its Tasks (see Resynchronization).

  • SHALL give the value of a search parameter in the form <system>|<value>.

  • MAY use requester:identifier to search for the Tasks of a given Placer.

Assumption about GF Addressing. This TA cannot place requirements on GF Addressing. It therefore does not require, but assumes, that GF Addressing ensures that an identifier system can only be used in a registration by the organization that the system refers to, so that a system and value identify one entity. The rules on ambiguous identifiers (see Coordination Task and Subscription) rely on this assumption.

Identifiers of Tasks and Subscriptions

The id of a Coordination Task, the id of a Cancellation Request Task and the id of a Subscription are carried in the notifications, so that every party that handles a notification sees them.

Follows from TA Notifications

• Each id SHALL be stable, opaque and unpredictable:

  • Stable: the same id on every request for the same resource. Where the source uses per-recipient ids, the id MAY differ between receivers, but SHALL remain the same for each individual receiver.

  • Opaque: the id SHALL NOT reveal creation order, volume, creation time or content.

  • Unpredictable: the id SHALL NOT be guessable, nor computable or confirmable from a real-world identifying number such as the BSN by anyone who does not hold a secret of the Placer. To be not guessable, an id SHALL carry at least 64 bits of entropy, generated by a cryptographically secure random number generator or produced by a keyed transformation with a secret key and an output of at least 64 bits. Only the random or keyed part of an id counts towards this minimum.

• A consumer SHALL treat an id as an opaque string: it SHALL NOT parse it, derive meaning from it, or assume a format when querying.

Specified by this TA

• These requirements apply to the id of a Coordination Task, of a Cancellation Request Task, of a Subscription, and of the Request to which Task.focus refers. The value of Task.identifier SHALL meet the requirement of opacity as well.

• A UUIDv4 generated by a cryptographically secure random number generator meets these requirements. TA Notifications gives examples of constructions that satisfy the requirements and of constructions that do not (TA Notifications, Appendix A).

Notification

SubscriptionTopic

This TA does not define a SubscriptionTopic itself. Each use case that is specified as a profile of this TA defines one or more topics, each with its own canonical URL (see Design Choices). This section states the requirements that every such topic meets. The requirements of TA Notifications on a SubscriptionTopic apply in full, whether or not they are repeated here.

Follows from TA Notifications

• In FHIR R4 a SubscriptionTopic is not a resource exchanged or stored at runtime: a Subscription refers to the topic by its canonical URL only. The topic is a design-time definition, published in the use-case-specific technical agreement that defines it. (TA Notifications)

• A topic has a unique canonical URL and monitors a single resource type. (TA Notifications)

• The definition of a topic specifies which interactions trigger it, and any further trigger condition, such as a coded value. (TA Notifications)

• The definition of a topic states how the patient that an event concerns is resolved, and, where this differs between events, from which point the patient is resolvable. (TA Notifications)

• A topic defines the filter parameters that a Subscription may use, with the name and the element of the monitored resource to which each applies. (TA Notifications)

Specified by this TA

Every topic of a use case under this TA:

• SHALL monitor Task.

• SHALL be triggered by create and update. create alone is not sufficient: both TA NP and eOverdracht rely on update-triggered notifications (dataset updates, cancellation), so a topic must support create and update to be specifiable as a profile of either.

• SHALL allow the filter owner:identifier, the search parameter owner of FHIR R4 with the modifier identifier, which applies to Task.owner.identifier (see Search parameters).

• SHALL resolve the patient via Task.for. Until a candidate is selected, Task.for is empty and the event concerns no identified patient, unless the use case identifies the patient before selection. From the selection onwards, and from the creation of the Task in the Single Fulfiller Pattern or where the use case identifies the patient before selection, the patient is resolvable via Task.for (see Patient context and readability).

• SHALL deliver the Cancellation Request Tasks that refer to the Coordination Tasks it delivers. A Cancellation Request Task carries the same type of work as its Coordination Task (see Type of work on the Task), so a trigger condition that narrows the topic on the type of work admits it as well.

The use case defines the canonical URL of its topic, the trigger condition that narrows the topic to its type of work, and whether Subscriptions for the topic may be created in-band. The trigger condition narrows on the entry with type type-of-work in Task.input (see Type of work on the Task). FHIR R4 defines no search parameter on Task.input, so the trigger condition is expressed in FHIRPath, not as a query.

A use case that also publishes its topic as a SubscriptionTopic resource (TA Notifications) can do so in FHIR R5, not in R4B. In R5, SubscriptionTopic.canFilterBy.modifier is bound to search-modifier-code, which contains identifier; in R4B it is bound to subscription-search-modifier, which does not, so the filter parameter owner with the modifier identifier cannot be expressed there.

Because a Subscription fires on any matching interaction regardless of who performed it, including update in the topic means the Fulfiller is also notified of its own updates to the Coordination Task and to a Cancellation Request Task. A Fulfiller MAY disregard the content of a notification it recognizes as reporting its own prior update. It still accepts the notification with 200 OK and processes its event-number for the continuity check, as TA Notifications requires of a Subscription Client; a rejection would set the Subscription to error. The Placer holds the Subscriptions and receives no notifications under this TA.

Type of work on the Task

A topic of a use case narrows on the type of work (see SubscriptionTopic), and a candidate needs to know the type of work before it is selected, when it may not read the Request (see Patient context and readability). The Request does not state the type of work as such: ServiceRequest.code states the requested service, which is finer.

The Placer carries the type of work in exactly one entry of Task.input, with type type-of-work from the code system of this TA (see Codes of this TA) and a valueCodeableConcept with the code that the use case defines for its type of work. A Cancellation Request Task carries the same entry as the Coordination Task to which it refers, so that a topic and a search treat both alike. That code can be the one a use case already uses, such as SNOMED 308292007 for eOverdracht. The entry carries the type of work only, not ServiceRequest.code, so that a candidate learns no more than the use case before it is selected.

The type of work is not carried in Task.code: Task.code states what the owner is expected to do with the Request, as in COW IG and TA Routing (see Routing by the Fulfiller). An implementation of eOverdracht, whose Task profile fixes Task.code to SNOMED 308292007, carries that code in Task.input instead.

The topic of a notification also indicates the type of work, but the Task states it as well: a Fulfiller that finds a Task by a search, during Resynchronization, has no notification to take the topic from, and a HealthcareService can hold Subscriptions for several topics. FHIR R4 defines no search parameter on Task.input, so a search cannot be narrowed to one topic (see Resynchronization).

Subscription

The requirements of TA Notifications on a Subscription apply in full, whether or not they are repeated here. A Subscription is as defined below, whether it is established out-of-band or in-band. The requirements below are separated into those that follow from TA Notifications and COW IG and those that this TA specifies.

Follows from TA Notifications and COW IG

• A Subscription informs the Fulfiller of changes to the Coordination Tasks that it owns, and is held by the Placer, as Subscription Server, on its own server. (COW IG, Task at Placer with Subscriptions)

• A Subscription concerns the events of every zorgaanbieder for which the base URL at which it is held is registered in GF Addressing. (TA Notifications)

• A Subscription is established out-of-band by the Placer, or in-band by the Fulfiller where the use-case agreement specifies in-band creation for the topic. (TA Notifications)

• Subscription.criteria SHALL carry the canonical URL of the topic. (TA Notifications)

• The extension backport-filter-criteria carries the filter, in one of the formats of the Backport IG, which include [filterParameter]:[modifier]=[value], using a filter parameter defined by the topic. (TA Notifications; Subscriptions R5 Backport IG 1.1.0, Components)

• The extension backport-payload-content sets the payload mode. (TA Notifications)

• How the notification endpoint of the HealthcareService is discovered is the responsibility of GF Addressing. (GF Addressing; TA Routing)

Specified by this TA

• A Subscription is established once per HealthcareService of the Fulfiller, per topic under which that service receives Tasks, and per base URL at which Coordination Tasks for that service are hosted, as part of onboarding that service — not per Task — and serves every subsequently created Task at that base URL. Where that base URL is registered for several Placers, one Subscription serves the Coordination Tasks of all of them. A Fulfiller therefore has one Subscription per service, topic and base URL.

• The Placer SHALL NOT create a Coordination Task for a HealthcareService under a topic unless a Subscription for that service and topic exists at the base URL at which it hosts that Task, with status active or error.

• A Fulfiller that sets a Subscription to off, through Updating a Subscription (TA Notifications), ends the onboarding of that service for that topic at that base URL. The Placer then SHALL NOT create a new Subscription for that service, topic and base URL unless the Fulfiller has agreed to this outside this TA. (TA Notifications, Replacing a Subscription) Open Coordination Tasks that refer to the service keep their owner, but changes to them are no longer notified; the Fulfiller can retrieve them as described in Resynchronization.

• A Subscription is addressed to a notification endpoint of the HealthcareService: channel.endpoint begins with the address of an Endpoint in HealthcareService.endpoint with payloadType Notification (TA Notifications, Preconditions). An endpoint of an ActivityDefinition or PlanDefinition is not used under this TA (see Design Choices). When it is established out-of-band, the Placer creates it. When it is established in-band, the Fulfiller creates it with the notification endpoint of the HealthcareService.

• The filter SHALL be of the form owner:identifier=<system>|<value>, in which <system>|<value> is the business identifier of the HealthcareService (see Task.owner). The topic allows this filter (see SubscriptionTopic). The filter uses the search parameter owner of FHIR R4 with the modifier :identifier, as the search in Resynchronization does, so that the Subscription and the search select the same Tasks. The examples in TA Notifications, which use a filter parameter owner defined by the topic, without a modifier and with the URA of an organization, do not apply under this TA: Task.owner identifies a HealthcareService, not an organization.

• A filter in backport-filter-criteria SHALL NOT exclude a Cancellation Request Task that is owned by the Fulfiller, for example by filtering on Task.code without admitting abort.

• The payload mode SHALL be id-only. The payload modes empty and full-resource SHALL NOT be used under this TA.

• A Subscription SHALL carry the extension backport-heartbeat-period, with the interval that the use case states for the topic. For out-of-band creation the Placer sets it; for in-band creation the Fulfiller requests it, and the Placer SHALL accept it unchanged. The Fulfiller SHALL check at that interval whether a heartbeat was missed, and SHALL compare events-since-subscription-start with the highest event-number it has processed; TA Notifications makes this a SHOULD. Without heartbeats, the Fulfiller would not detect a missed last notification, such as of a Cancellation Request Task or of the cancellation of its Coordination Task. (TA Notifications, Heartbeat Notification)

• The Placer SHALL NOT create or accept a Subscription for an owner identifier that does not resolve to exactly one HealthcareService in GF Addressing, in the replica of the directory that the Placer uses to select the Fulfiller (see the assumption about GF Addressing under Search parameters).

On what basis the Placer accepts a Subscription that the Fulfiller creates in-band, or decides to create a Subscription itself out-of-band, is outside the scope of this TA, apart from the rule above on ambiguous identifiers. The notification endpoint is verified as TA Notifications requires. TA Notifications and the generic functions for authorization and consent apply.

Authorization value

TA Notifications allows an event-notification for an out-of-band Subscription to carry an authorization value for the subsequent pull, and does not allow it for an in-band Subscription. Under this TA, whether the Fulfiller may read a Task, the Request or the Patient is decided by its authentication and the identification that the Placer recorded (see Write access), not by a value in the notification.

A notification under this TA SHALL NOT carry an authorization value (authorization-type, authorization-value), for out-of-band and in-band Subscriptions alike, so that access does not depend on how a Subscription was established.

Use-case agreements under TA Notifications

A use case that is specified as a profile of this TA is the use-case-specific technical agreement in the sense of TA Notifications, and SHALL meet the requirements that TA Notifications places on such an agreement. This TA settles some of these requirements for every use case; a use case SHALL NOT deviate from what this TA settles. The table lists, for each requirement, what this TA settles and what the use case states.

In addition to the requirements of TA Notifications, a use case states when the work counts as started, and therefore when the Fulfiller moves the Coordination Task to in-progress (see Status of the Coordination Task).

Healthcare services

Changes to healthcare services

Healthcare services change: they are split, merged, renamed or retired. Each HealthcareService has its own Subscriptions, one per topic and base URL, and open Tasks refer to the service by its identifier. A change to a service therefore calls for maintenance of the Subscriptions of that service and of the Tasks that refer to it. The maintenance concerns at least how the Placer learns of a change to a service, what happens to the Subscriptions of the service, and what happens to the open Tasks that refer to it.

A change that keeps the identifier and the notification endpoint of the service, such as a new name, requires no maintenance. When the notification endpoint of a service changes, each Subscription of that service is replaced by one addressed to the new endpoint: by the Placer for an out-of-band Subscription, and by the Fulfiller for an in-band Subscription (TA Notifications, Replacing a Subscription). The endpoint cannot be changed on an existing Subscription (TA Notifications, Updating a Subscription).

Open Coordination Tasks and Cancellation Request Tasks keep their owner. The Placer sets Task.owner once, at creation (see Write access), and does not move an open Task to another service. A Fulfiller whose service can no longer carry out the work rejects the Task or sets it to failed (see Cancellation by the Fulfiller), and the Placer then decides on a new Task (see Handling the End of a Coordination Task).

The Placer SHOULD NOT set a Subscription of a service to off while open Coordination Tasks refer to that service, other than after replacing it, so that every open Task keeps a Subscription through which its notifications are delivered.

The Placer SHALL NOT create a new Coordination Task for a service that no longer resolves in the directory data (see Coordination Task). A successor service, from a split or a merge, gets its own Subscriptions through onboarding, like any other service (see Subscription).

Transactions

In each transaction and pattern, the rules are separated into those that follow from COW IG, TA Notifications or FHIR, and those that this TA specifies. The requirements of those specifications apply in full, whether or not they are repeated here.

Task lifecycle

Task Creation

• Trigger: the Placer has authorized a Request and identified one or more candidate Fulfillers.

• Exchange: none between the parties. The Placer creates the Coordination Task on its own FHIR server, in a way it chooses (see Coordination Task); what the parties exchange is the notification and the read by the Fulfiller.

Follows from COW IG and TA Notifications

• The Task is delivered as Notified Pull, via the standing Subscription (Resource Definitions → Subscription). The Fulfiller reads the Task from the Placer's server.

• The reads by the Fulfiller that follow a notification, of the Coordination Task, the Request, the Patient and the resources of the dataset, are the retrieval to which TA Notifications refers; its authorization is governed by TA I&A and TA Pull, not by TA Notifications.

Specified by this TA

• The notification is id-only: it carries a reference to the Coordination Task and no content. The reference is an absolute URL.

Task Update by Fulfiller

• Trigger: the Fulfiller updates Task.status, Task.businessStatus, Task.statusReason, Task.executionPeriod, Task.lastModified, or Task.output.

• Exchange: PUT/PATCH by the Fulfiller on the Placer-hosted Coordination Task.

Follows from COW IG

• The Fulfiller updates the Coordination Task at the Placer to report the progress of the work, over the Request's lifecycle.

Specified by this TA

• The update is limited to the elements named in the trigger. The update is version-aware (see Write access).

Task Update by Placer

• Trigger: the Placer updates the Coordination Task on its own initiative — for example, by cancelling it before in-progress (see Cancellation, below), or by changing any other element.

• Exchange: none between the parties. The Placer changes its own Coordination Task, in a way it chooses; what the parties exchange is the notification and the read by the Fulfiller.

Follows from COW IG and TA Notifications

• The update is delivered as Notified Pull: the Fulfiller did not make this change itself and can learn of it only through the notification or by reading the Task.

Handling the End of a Coordination Task

A Coordination Task ends when Task.status becomes completed, failed, rejected, cancelled or entered-in-error. The Placer decides about the Request by looking at all Coordination Tasks that refer to it, not at one Task alone. The column Source shows whether a row follows from COW IG or is specified by this TA.

This TA specifies in addition:

• While other candidates are still under consideration, the end of one candidate's Task does not change the Request. The Placer SHOULD NOT leave a Request active when no open Coordination Task refers to it, unless it is about to create one.

• Other Tasks that relate to a Coordination Task, such as a Cancellation Request Task, do not change the Request themselves. The Placer acts on the status of the Coordination Task.

Patterns for several candidates

Multiple Fulfillers Pattern

A Placer solicits one or more candidates at once, lets each respond, and commits to one, without having authorized any other candidate to act on the Request in the meantime. (COW IG, eOverdracht; see Design Choices)

Follows from COW IG

• One Request SHALL be shared by every candidate under consideration.

• One Coordination Task SHALL be created per candidate, each referencing the same Request via Task.focus.

• Each candidate MAY accept, by updating its own Task.status to accepted, as a Task Update by Fulfiller (see Transactions). Acceptance does not imply selection.

• When a candidate is chosen, the Placer SHALL set that candidate’s Task.code to fulfill and its Task.businessStatus to selected, and SHALL set every other candidate’s Task.status to cancelled with the reason “not selected”.

Specified by this TA

• The Placer records selected and not selected with the codes selected and not-selected of the code system of this TA (see Reason for cancelling a non-selected candidate).

• ServiceRequest.performer SHALL remain unset while solicitation is open.

• ServiceRequest.performer MAY be set to the selected candidate once chosen; Task.owner on the selected Task remains authoritative regardless.

• The Placer SHOULD record a selection as one atomic change: setting Task.businessStatus to selected, Task.code to fulfill and, where it is not yet set, Task.for on the Coordination Task of the selected candidate, and setting the Coordination Tasks of all other candidates to cancelled with statusReason not-selected, either all take effect or none does. Each of these changes is based on the current version of the Task (see Concurrent writes). If one of the Tasks has changed in the meantime, the Placer reads the Tasks again and decides again.

• The Placer invites at most one HealthcareService of the same Fulfiller at the same time for the same Request (see Candidates of the same Fulfiller).

• The Placer SHALL select only a candidate whose Coordination Task has the status accepted.

How the Placer weighs the responses of the candidates and decides which one to select is outside the scope of this TA. This TA specifies responses of the candidates such as accepting and bidding (see Bidding), and how the decision is recorded and communicated once made.

A candidate learns from Task.code request-fulfillment that no candidate has been selected yet and that it may not start the work (see Recognizing the pattern that applies). What a candidate that is not yet selected may read is stated in Patient context and readability.

Nothing in this pattern depends on the transfer-of-care use case that motivated it: the same structure applies to any workflow type this TA covers, wherever a Placer might solicit more than one Fulfiller for the same piece of work.

Candidates of the same Fulfiller

The Multiple Fulfillers Pattern creates one Coordination Task per candidate, and Task.owner identifies a HealthcareService. A Placer can therefore invite two HealthcareServices of the same Fulfiller as candidates for the same Request. Read access, however, is decided by the identification of the Fulfiller (see Write access), not by the HealthcareService. Once one of these services is selected, the other service has the same identification, and the Placer cannot keep it from reading the Request and the Patient resource, as Patient context and readability requires.

This TA therefore treats a candidate as a Fulfiller. The Placer SHALL NOT create a Coordination Task with Task.code request-fulfillment for a HealthcareService while a Coordination Task for the same Request, whose status is not an end status, exists for another HealthcareService of the same Fulfiller. Two HealthcareServices belong to the same Fulfiller when the Placer records the same identification for them (see Coordination Task). A Fulfiller that can carry out the work through several of its services routes the Request internally (see Routing by the Fulfiller).

Should TA I&A let a Fulfiller authenticate as a HealthcareService, a later version of this TA can allow several services of the same Fulfiller as candidates at the same time, with access per service.

Reason for cancelling a non-selected candidate

When the Placer selects a candidate in the Multiple Fulfillers Pattern, it cancels the Coordination Tasks of the other candidates. COW IG gives these Tasks the reason not selected in Task.statusReason, but defines no code for it, and Task.statusReason has only an example binding in FHIR R4. A candidate that is not selected may not read the Request (see Patient context and readability), so it learns why its Task was cancelled from Task.statusReason alone.

The Placer SHALL set Task.statusReason to the code not-selected from the code system of this TA (see Codes of this TA), and SHOULD add the text not selected in Task.statusReason.text. A candidate recognizes from the code that it was not selected, without reading the Request, and a system that does not know the code can still show the text. The code is defined together with selected, which records the opposite decision.

Bidding

Bidding is a way of using the Multiple Fulfillers Pattern in which candidates do not only accept but also describe what they would offer, so that the Placer, and where relevant the patient, can compare the candidates before one is selected. (COW IG)

Follows from COW IG

• A candidate describes what it would offer in a bid. What a bid contains depends on the care domain and is not defined by this TA. A bid may describe, for example, the candidate's availability, a more specific service it would perform, the expected cost, or the person who would carry out the work.

Specified by this TA

• A bidding task is a Coordination Task. The Placer invites bids by creating a Coordination Task for each candidate, all referring to the same Request (see Multiple Fulfillers Pattern). While several candidates are under consideration, these Coordination Tasks are the bidding tasks.

• A candidate responds with a bid by accepting its bidding task and recording the bid in Task.output, as a Task Update by Fulfiller.

• A candidate that is not yet selected may not read the Request, unless the use case states otherwise (see Patient context and readability). It accepts, and bids, on the basis of the type of work in Task.input (see Type of work on the Task) and the further entries of Task.input that the Placer shares before selection; what its acceptance means is stated in Status of the Coordination Task. After selection, a Fulfiller that finds from the Request that it cannot carry out the work sets the Coordination Task to failed, with a statusReason (see Status of the Coordination Task). The Coordination Tasks of the other candidates have then been cancelled, and the Placer decides on a new Coordination Task (see Handling the End of a Coordination Task).

• A candidate that does not want to bid MAY reject its bidding task with a statusReason. A candidate that accepts without a bid makes no offer beyond its acceptance.

• The Placer reviews the bids received and selects a candidate. How it compares the bids and decides is outside the scope of this TA. The selection is recorded as described in the Multiple Fulfillers Pattern. A bid is not a commitment by the Placer: bidding, like accepting, does not imply selection.

• The bidding ends when the Placer selects a candidate. The Coordination Task of the selected candidate continues for the work itself, and its Task.output keeps the bid. The Coordination Tasks of the other candidates are cancelled (see Multiple Fulfillers Pattern).

• Each candidate has its own bidding task, so a candidate's bid is recorded on its own task only. Whether a candidate may see the bids of other candidates is an access-control question, outside the scope of this TA.

Single Fulfiller Pattern

Where a Placer already knows, at the moment the Request is authorized, which single Fulfiller should carry out the work, the Multiple Fulfillers Pattern does not apply. This pattern is specified by this TA.

• Task.code SHALL be fulfill from creation.

• Task.owner SHALL identify the HealthcareService of the one Fulfiller directly.

• The Fulfiller moves Task.status from requested or received to accepted before it starts the work, as in the Multiple Fulfillers Pattern (see Status of the Coordination Task).

• The Fulfiller MAY decline by moving Task.status from requested or received to rejected, with statusReason.

This pattern applies only where the Placer and the sole Fulfiller have nothing to negotiate. Where negotiation is wanted — a proposed timing, a different scope, a request for more information — even with only one candidate, the Multiple Fulfillers Pattern applies instead, and the Request is treated as a solicitation of exactly one.

How a Fulfiller recognizes that this pattern applies is described in Recognizing the pattern that applies.

Cancellation

Cancellation (Before in-progress)

This is an instance of Task Update by Placer, above, in which Task.status is set to cancelled.

• Trigger: the Placer wishes to withdraw the Request; Task.status has not reached in-progress.

• Exchange: none between the parties. The Placer sets its own Coordination Task to cancelled, in a way it chooses.

Follows from COW IG

• The update is delivered as Notified Pull and requires no cross-organization write access.

• When the Placer withdraws the Request, it also sets Request.status to revoked. When only this Coordination Task is cancelled, for example because another candidate was selected, Request.status stays active.

Specified by this TA

• When the Placer withdraws the Request, it SHOULD state the reason in Task.statusReason.text. A Fulfiller whose Task is cancelled learns from Task.statusReason which of the two applies; a candidate that is not selected may not read Request.status (see Patient context and readability).

Cancellation Request (After in-progress)

• Trigger: the Placer wishes to withdraw the Request; Task.status has reached in-progress.

• Exchange: none between the parties. The Placer creates a Cancellation Request Task on its own FHIR server, in a way it chooses; the Fulfiller learns of it through the notification.

Follows from COW IG

• The Cancellation Request Task is delivered as Notified Pull.

Cancellation Request Response

• Trigger: the Fulfiller has read a Cancellation Request Task.

• Exchange: PUT/PATCH by the Fulfiller, updating the Cancellation Request Task's status. When it accepts, the Fulfiller then also updates the Coordination Task to failed.

Follows from COW IG

• The response is an update.

Specified by this TA

• When the Fulfiller accepts the Cancellation Request Task, the work is stopped, the Fulfiller sets the Coordination Task to failed, and the Placer sets Request.status to revoked. When the Fulfiller rejects it, the work continues and Request.status stays active.

After an accepted Cancellation Request

When the Fulfiller accepts a Cancellation Request Task, the Coordination Task is in-progress and SHALL NOT be set to cancelled, as described in Cancellation Request Task. The Placer sets Request.status to revoked when it withdraws the Request (see Cancellation Request Response).

After accepting the Cancellation Request Task, the Fulfiller sets the Coordination Task to failed, with a statusReason. Other than completed, failed is the only end status that the state machine of FHIR R4 allows from in-progress, and COW IG uses it when a Fulfiller can no longer carry out the work (COW IG, Fulfiller Unable to Perform). COW IG also allows the Fulfiller to set the Coordination Task to on-hold here; this TA does not use on-hold, which in the state machine of FHIR R4 leads only back to in-progress, so the Coordination Task would never reach an end status while the Request is revoked.

A Coordination Task that failed after a withdrawal is recognized by the accepted Cancellation Request Task whose Task.focus refers to it.

Cancellation by the Fulfiller

A Fulfiller that cannot or does not want to carry out the work has three possibilities. None of them changes the Request itself, which only the Placer modifies. All three follow from COW IG.

• Declining before starting. The Fulfiller sets the status of its Coordination Task to rejected, with a statusReason. The Request stays active.

• Unable to complete. A Fulfiller that has accepted or started the work, and finds that it can no longer carry it out, sets the status of its Coordination Task to failed, with a statusReason. The Placer then decides what happens to the Request (see Handling the End of a Coordination Task).

• Asking the Placer to withdraw the authorization. A Fulfiller that finds that the Request itself is inappropriate or even dangerous, so that no Fulfiller should carry it out, MAY ask the Placer to cancel it, with an Authorization Cancellation Request Task, and then also rejects its Coordination Task or sets it to failed (COW IG, Fulfiller Decline to Perform). Rejecting or failing the Coordination Task alone ends only the involvement of this Fulfiller; the Placer may then create a Coordination Task for another Fulfiller (see Handling the End of a Coordination Task). This Task has the status requested, the code abort, the intent proposal, and refers to the Request in Task.focus. The Placer decides. When the Placer accepts, it sets Request.status to revoked and ends the Coordination Tasks that refer to the Request and are still open: it sets those that have not reached in-progress to cancelled, and creates a Cancellation Request Task for those that are in-progress (see Cancellation (Before in-progress) and Cancellation Request (After in-progress)).

With the third possibility, the Fulfiller creates the Authorization Cancellation Request Task on the Placer’s server (see Write access), with the elements of the table Authorization Cancellation Request Task in Summary of the profiles. Its owner is the Placer, so the Subscription of the Fulfiller delivers neither this Task nor the answer to it. The Fulfiller learns the answer by reading the Authorization Cancellation Request Task, or by searching with requester:identifier=<system>|<value>&code=abort&intent=proposal.

Recovery and server behavior

Resynchronization

A Fulfiller that has missed notifications (a gap in the event numbers, a missed heartbeat, or a Subscription that was in error) retrieves the current state by searching the Placer's server. This TA does not require the $events operation. This section is the route for reconciliation that TA Notifications requires of a use-case agreement when $events is not required.

Follows from TA Notifications

• The period of the search starts before the last processed notification, with a margin, because the time of an event need not equal meta.lastUpdated of the Task (see _lastUpdated). A Task processed twice is processed idempotently.

• A search for missed changes is subject to data minimization, and SHALL be limited to the monitored resource type, the filter criteria of the Subscription and the period of the gap. (TA Notifications)

Specified by this TA

• The Fulfiller searches Tasks with the filter of its Subscription over the period of the gap: GET [base]/Task?owner:identifier=<system>|<value>&_lastUpdated=ge<time>. Every search includes this filter and the period. FHIR R4 defines no search parameter on Task.input, so the search cannot be narrowed to one topic: it can also return Tasks of its HealthcareService under other topics. These are Tasks that the Fulfiller may read in any case (see Write access). The Fulfiller recognizes the type of work of each Task it finds from the entry with type type-of-work (see Type of work on the Task).

• To find the Coordination Tasks for one Request, the Fulfiller adds focus=<Request>. To find the Cancellation Request Tasks for a Coordination Task, it adds focus=Task/<id>&code=abort.

Placer server capabilities

The server of the Placer SHALL publish a CapabilityStatement (the capabilities interaction) that declares at least the following.

Follows from FHIR R4 and TA Notifications

• A server publishes a CapabilityStatement through the capabilities interaction. (FHIR R4)

• For Subscription: read and search with the parameters of TA Notifications, the $status operation, and the $events operation where it is supported. (TA Notifications)

• Where the server supports in-band creation of Subscriptions, the supported SubscriptionTopics, in the extension capabilitystatement-subscriptiontopic-canonical; this is a SHOULD. (TA Notifications)

• For Subscription: the interaction update, for in-band and out-of-band Subscriptions alike, accepting only the changes that the transaction Updating a Subscription permits. (TA Notifications)

• Where in-band creation is specified for a topic: the interaction create on Subscription. (TA Notifications)

Specified by this TA

• For Task: the interactions read, search, update and patch, and create for the Authorization Cancellation Request Task; the versioning level versioned-update; the search parameters owner and requester, each with the support of the modifier :identifier stated in searchParam.documentation; and the search parameters focus, code, intent, status, business-status and _lastUpdated.

• For Subscription: the profile of this TA as supportedProfile.

• For the Request: the interaction read.

• For Patient: the interaction read.

The formal definition of this CapabilityStatement is published in the implementation guide of this TA (see Task profiles).

Codes of this TA

This TA defines a code system with eight codes.

Follows from FHIR R4 and COW IG

• The code fulfill is defined by HL7 in the FHIR code system for Task codes. (FHIR R4)

• The code request-fulfillment is not defined in any published code system. COW IG uses it in its Workflow State Overview for multiple potential performers, but does not define it in its formal artifacts, and the COW IG profile for the Coordination Task accepts any value in Task.code. (COW IG)

• The code selected is not defined in any published code system either. COW IG uses it in its Workflow State Overview for the selected Fulfiller, but its value set for Task.businessStatus, an example binding, does not contain it. (COW IG)

Specified by this TA

• This TA defines a code system, which contains request-fulfillment, selected, awaiting-information, visit-scheduled, not-selected, type-of-work, supplemental-resource and supplemental-query; a value set for Task.code, which contains fulfill from the HL7 code system and request-fulfillment from the code system of this TA; and two value sets bound with an extensible binding: one for Task.statusReason, which contains not-selected, and one for Task.businessStatus, which contains selected, awaiting-information and visit-scheduled.

• The Coordination Task profile binds Task.code to this value set with a required binding. A Task.code that is not in this value set is not valid under this TA. The HL7 code system is not changed or extended.

The formal definitions of this code system and of the value sets are published in the implementation guide of this TA (see Task profiles).

Recognizing the pattern that applies

A Fulfiller that receives a Coordination Task needs to know which pattern applies. In the Single Fulfiller Pattern the Placer has chosen the Fulfiller, nothing is negotiated, and the Fulfiller may start the work. In the Multiple Fulfillers Pattern the Fulfiller is one of several candidates, and it waits until the Placer selects a candidate; a Fulfiller that started the work too early would do work for nothing.

Task.code shows which pattern applies. While the Multiple Fulfillers Pattern applies and no candidate has been selected, also when only one candidate is invited, the Placer sets Task.code to request-fulfillment. In the Single Fulfiller Pattern Task.code is fulfill from creation, and at selection the Placer sets Task.code to fulfill on the Coordination Task of the selected candidate (see Multiple Fulfillers Pattern). COW IG uses the same codes in its Workflow State Overview.

A Fulfiller SHALL NOT start the work while Task.code is request-fulfillment. The Placer’s server SHALL reject an update by the Fulfiller that sets Task.status to in-progress while Task.code is request-fulfillment.

Task.code is used, rather than Task.businessStatus or ServiceRequest.performer, because it is the element that states what the owner is expected to do, and the Fulfiller does not need to read the Request to see it.

Changes since 0.2

• Introduction. Added how the conformance verbs are interpreted; MUST and MUST NOT are replaced by SHALL and SHALL NOT. Requirements of underlying specifications are repeated and marked as “Follows from …”. (editorial)

• Limitations of this document. Removed. Decisions outside this TA are listed under Out of scope; formal definitions are announced where they apply. (editorial)

• Context. eOverdracht is described as a transfer of care. (editorial)

• Scope. Out of scope: the topics of use cases, and how the Placer learns of a change to a healthcare service. (editorial)

• Vocabulary. Placer and Fulfiller are zorgaanbieders, acting as Subscription Server and Subscription Client of TA Notifications. Added zorgaanbieder, GTK, Authorization Cancellation Request Task, ActivityDefinition, PlanDefinition, CarePlan, Type of work and Directory. Standard dataset is described by the definition of the requested service. “referral” is replaced by “Request” where all types of work are meant. (technical)

• Basis of this TA. COW IG refers to the May 2025 ballot. TA Notifications, TA Routing and GF Addressing are identified by name and version. Added the FHIR Extensions Pack and TA Pull. (technical)

• Relationship to COW IG. This TA adds a code system with eight codes and uses the extension cqf-fhirQueryPattern. A later version of COW IG applies only once a later version of this TA refers to it. (technical)

• Design Choices. Added why topics are defined per use case. A Subscription is established per HealthcareService, topic and base URL, with the notification endpoint of the HealthcareService. (technical)

• Actors. The Placer registers its base URL in GF Addressing, establishes Subscriptions at onboarding, and answers an Authorization Cancellation Request Task. The Fulfiller registers its HealthcareServices in GF Addressing and may change businessStatus. The base URL of the Placer is registered with a payloadMimeType with fhirVersion=4.0. (technical)

• Task profiles. Added the Authorization Cancellation Request Task, a profile of ServiceRequest, and a profile of Subscription. (technical)

• Task profiles, Summary of the profiles, Placer server capabilities, Codes of this TA. The formal definitions are published in the implementation guide of this TA, which adds no requirements of its own; where it and this TA differ, this TA applies. (technical)

• Summary of the profiles. Element requirements are described for each profile, including owner and location from GF Addressing, a required binding on Task.code, and the type of work in Task.input. The Cancellation Request Task carries the Placer in Task.requester. (technical)

• Rules that a profile cannot express. Added rules on the Cancellation Request Task, the Authorization Cancellation Request Task and request-fulfillment. The rules are ordered by resource. (technical)

• Coordination Task. How the Placer creates the Task is not specified. The owner resolves in GF Addressing. (technical)

• Write access, Task Update by Fulfiller. Either party may set Task.businessStatus to report progress within a status; selected is reserved for the Placer. The Fulfiller may also change executionPeriod and lastModified, and may create an Authorization Cancellation Request Task. The accountable party is the zorgaanbieder, not the GTK. (technical)

• Status of the Coordination Task. ready is not used, and a Fulfiller accepts before in-progress. Added the move from accepted to failed. The meaning of accepted depends on Task.code. Only the Placer sets cancelled. (technical)

• Status of the Coordination Task, Use-case agreements under TA Notifications. Each use case states when the work counts as started; the Fulfiller does not move the Coordination Task to in-progress before that point, since from then on the Placer uses a Cancellation Request Task. (technical)

• Business status. New section, with the codes awaiting-information and visit-scheduled. (technical)

• Cancellation Request Task. The Placer may withdraw an unanswered Cancellation Request Task, or set it to entered-in-error. (technical)

• Request. The Request is a ServiceRequest. ServiceRequest.code is required and carries the code of the ActivityDefinition. ServiceRequest.instantiatesCanonical MAY refer to the definition of the requested service; a Request without a definition is valid. The introduction is rewritten accordingly. (technical)

• Retrieving the resources of a dataset. The standard dataset is described in a Library published by its owner, with searches in cqf-fhirQueryPattern. A Request has a standard dataset only where its definition describes one. (technical)

• Sharing additional content. Request.supportingInfo is for the authorization, Task.input for the fulfillment. Data at the Placer is shared with the types supplemental-resource and supplemental-query. Before selection, entries may concern the patient without identifying the patient. Entries that identify the patient, and references to data at the Placer, are added from selection, unless the use case identifies the patient before selection. (technical)

• Patient context and readability. Before selection the Task carries nothing that identifies the patient, unless the use case identifies the patient before selection. At selection the Placer sets Task.code fulfill, and Task.for where it is not yet set. Task.for.identifier SHOULD NOT be populated. (technical)

• Routing by the Fulfiller. The type of work is known from the topic and Task.input, also before selection. supportedActivityDefinitions is on HealthcareService.type, next to the codes of the services. Without a definition, the Fulfiller routes on ServiceRequest.code. (technical)

• Search parameters. owner and requester with :identifier replace the parameters of this TA. Identifiers of HealthcareService and Location are taken unchanged from GF Addressing; an assigner identified by KvK number is not supported. (technical)

• Identifiers of Tasks and Subscriptions. Aligned with TA Notifications 0.9, including at least 64 bits of entropy. The requirements also apply to the id of the Request, and Task.identifier is opaque. (technical)

• SubscriptionTopic. This TA states the requirements on the topics of use cases instead of defining a topic itself. The trigger condition on the type of work is expressed in FHIRPath. A topic resource can be published in R5, not R4B. (technical)

• Type of work on the Task. New section. The type of work is carried in Task.input, not in Task.code. (technical)

• Subscription. In-band creation only where the use case specifies it. The filter is owner:identifier. Heartbeats are required. A Subscription that the Fulfiller sets to off ends the onboarding. (technical)

• Authorization value. New section. A notification carries no authorization value. (technical)

• Use-case agreements under TA Notifications. New section. (technical)

• Changes to healthcare services. New section. Open Tasks keep their owner, and a changed notification endpoint requires replacing the Subscriptions of the service. (technical)

• Task Creation, Task Update by Placer, Cancellation (Before in-progress), Cancellation Request (After in-progress). The Placer’s own creates and changes are no longer specified as exchanges. (technical)

• Handling the End of a Coordination Task. failed also covers a Fulfiller that accepted but did not start, and work stopped after an accepted Cancellation Request Task. (technical)

• Multiple Fulfillers Pattern. A selection is recorded atomically and also sets Task.code to fulfill. ServiceRequest.performer remains unset until selection, also with one candidate. Only a candidate whose Coordination Task is accepted can be selected. (technical)

• Candidates of the same Fulfiller. New section. A Placer invites at most one HealthcareService of the same Fulfiller at the same time for the same Request. (technical)

• Reason for cancelling a non-selected candidate. The Placer sets the code not-selected. (technical)

• Bidding. Before selection, a candidate accepts and bids on the basis of the type of work. (technical)

• Single Fulfiller Pattern. Task.owner identifies the HealthcareService. The Fulfiller accepts before it starts the work. (technical)

• Single Fulfiller Pattern, Patient context and readability. The Placer sets Task.for at creation. (technical)

• Cancellation (Before in-progress). A cancelled Fulfiller learns the reason from Task.statusReason. (technical)

• Cancellation Request Response, After an accepted Cancellation Request. After accepting a Cancellation Request Task, the Fulfiller sets the Coordination Task to failed. (technical)

• Cancellation by the Fulfiller. The Fulfiller creates the Authorization Cancellation Request Task on the Placer’s server, ends its own Coordination Task, and reads the answer. (technical)

• Resynchronization. The search uses owner:identifier and cannot be narrowed to one topic. The type of work is taken from Task.input. (technical)

• Placer server capabilities. Added owner and requester with :identifier, intent, read on Patient, create on Task, and update and create on Subscription. (technical)

• Codes of this TA. Replaces Optional support for the code request-fulfillment: a code system with eight codes. (technical)

• Recognizing the pattern that applies. Task.code request-fulfillment shows that no candidate has been selected, and the Placer’s server enforces it. (technical)

• Write access, Actors, Transactions, Status of the Coordination Task, Cancellation Request Task, Resynchronization. “Direct Write” is replaced by “update”; spelling is made consistent. (editorial)

• Scope, Sharing additional content. The standard dataset is mentioned only where the Request has one. (editorial)

• Actors, Routing by the Fulfiller. The Fulfiller SHOULD, instead of SHALL, support the definitions that its HealthcareService lists. (technical)

Last updated: October 16, 2026