FHIR R4 subscriptions need a silent-exit reconciliation path
FHIR R4 says Subscription criteria are evaluated against a resource's new value, so no notification is sent when a resource is deleted or updated so that it no longer matches. A subscriber that maintains a working population needs an explicit reconciliation path for those exits rather than treating received push messages as a complete current set.
Editorial figure by Health Interoperability Review. Source context: HL7 FHIR R4 Subscription resource.
Treat each push as a positive-match event
The direct answer is to treat an R4 Subscription notification as evidence that the server evaluated a created or updated resource against the configured criteria and produced a channel event. It is not, by itself, a complete current-membership list. Preserve the FHIR release, server and endpoint, Subscription identifier and version, status, reason, criteria string, channel type, endpoint, payload choice, header configuration where used, start or acceptance evidence, end time, and accountable owner. Keep the exact criteria with every population derived from it so a later reviewer can reproduce what counted as a match.
The R4 page says Subscription criteria use search-string interpretation and are applied to the resource's new value. That makes the positive event specific to the resource state evaluated at that time. A subscriber should retain the notification receipt, server and resource identifiers where supplied, event observation time, payload or no-payload state, retrieval performed after the signal, validation result, duplicate handling, and downstream processing. A received notification does not establish that the subscriber fetched the intended version, accepted it, reconciled it with local state, or completed a clinical or operational action.
Design the missing exit path deliberately
FHIR R4 explicitly states that no notification occurs when a resource is deleted or when an update makes it stop matching the criteria. A local list built only by adding positive notifications can therefore retain records that have silently exited the source-defined population. Define how the subscriber discovers and applies those exits. The specification describes REST history and bundle polling as an alternative with a tighter client-server relationship that does not involve missing updates or deletes; an implementation may also need a documented current-search reconciliation where supported and appropriate.
The reconciliation design should preserve its baseline query or history cursor, server time boundary, page or bundle identifiers, resource and version identifiers, delete or nonmatch evidence, overlap window, duplicate rule, late-arrival treatment, comparison result, correction event, exception owner, and completion receipt. It should state whether a resource leaving the criteria is removed, marked inactive, retained with a new state, or routed for qualified review. Never infer a deletion merely because a later positive notification is absent. Silence can also reflect an ended or errored subscription, channel failure, authorization failure, endpoint outage, or an unchanged resource.
Keep channel semantics and subscription state visible
R4 supports several channel types and permits notifications with no information about the matching resource or with the entire resource. Its examples include a REST hook, WebSocket ping, email or SMS, and message delivery. Preserve the configured channel and payload contract rather than normalizing every signal to resource delivered. A ping or payload-free hook needs a controlled retrieval step; a full-resource payload needs validation and privacy and security controls appropriate to the data and environment. The specification itself warns that sending the entire resource creates security concerns that the server must manage.
Subscription lifecycle belongs in the same evidence chain. R4 defines requested, active, error, and off status values, an optional end time, and a latest-error note. Monitor the authoritative server state, expiration, error condition, endpoint reachability, authentication where applicable, retry behavior, and renewal or replacement. Preserve state transitions and configuration versions. Recreating a subscription should not erase the cursor, reconciliation boundary, unresolved delivery gap, or local population that depended on the prior instance.
Test membership change, deletion, and recovery
A representative R4 test should create a synthetic resource that matches the approved criteria, confirm the configured notification, update it while it still matches, update it so it no longer matches, and delete another matching resource. Verify that the subscriber handles the two specified silent-exit cases through the designed reconciliation path. Repeat with a payload-free channel, a full-resource payload where permitted, a duplicate notification, a delayed notification, an endpoint outage, an error status, an expired subscription, and a replacement subscription with revised criteria.
Reviewers should be able to reconstruct the positive events, absent exit notifications, history or query boundary, fetched resource versions, deletions or nonmatches, local state changes, exceptions, privacy and security handling, and recovery decision without manufacturing events the source never sent. This analysis is limited to the FHIR 4.0.1 R4 Subscription page. It does not describe R5 behavior, prove a server's conformance, prescribe one reconciliation implementation, or establish that a notification, retrieved resource, local list, clinical review, care action, or outcome is complete or correct.
Enterprise buyer test
Translate this change into the exact population, record type, workflow stage, decision owner, effective date, and evidence that could be affected. Ask current or prospective providers to demonstrate the named workflow with representative data and an exception—not a polished feature tour. Record what official documentation establishes, what a provider states, what the team observes, and what remains unresolved.
A defensible review also identifies the dependency outside the product. Authority interpretation, policy configuration, data quality, integrations, human judgment, approval rights, release governance, training, and retained evidence may remain customer or service responsibilities. The evaluation should preserve those boundaries instead of treating a technology claim as the complete operating model.
What we will watch next
Health Interoperability Review will watch the named source and affected market records for later evidence that changes status, scope, availability, implementation timing, workflow consequence, or the limits of the initial report. A later announcement does not silently overwrite this dated account; the change ledger preserves the sequence.