Subscription Profile

Canonical	../StructureDefinition/nexus-emr-core-subscription
Status	draft (experimental) · 1.26.0
Base	Subscription (constraint)
Source	FSH · JSON

Nexus EMR profile for Subscription (R4 criteria-based) -- server-side push notification registration managed by the subscription manager service. Infrastructure and a data-egress security surface: no effective date, and R4 gives it no identifier element. First pass; note the R5 redesign migration path.

Overview

Overview

The Nexus EMR Core Subscription profile is a server-side notification registration: a standing request to be notified when resources matching a search expression change, together with the channel those notifications are delivered on. It is infrastructure and tenant state, not clinical content -- a Subscription has no patient subject, carries no patient data, and describes no clinical fact.

Two consequences follow, both shared with the other infrastructure profiles in this IG. The profile declares no effective date: a subscription describes no clinical event, and end is an expiry timestamp rather than an effective date, so nothing here should date a chart surface. And there is no identifier constraint, because R4 Subscription has no identifier element at all (R5 adds one) -- the house identifier invariant deliberately does not apply, a detail that surprises implementers. Correlate subscriptions by resource id or by a tag.

The profile is draft and experimental, and carries one invariant, subscription-deliverable: criteria and channel.type must both be present. A half-configured subscription does not error, it simply never fires, and silent non-delivery is indistinguishable from no matching events.

R4 shape, and the R5 migration

Subscription was redesigned in R5 to be topic-based, with SubscriptionTopic replacing the R4 criteria search string. This profile is R4 and describes the R4 shape, so anything built on criteria is on a migration path; do not design a new long-lived integration against it without first reading the R5 backport guidance.

Two further points of scope are open in this first pass and should not be treated as settled: which resource types may be subscribed to (expected to become a closed list), and whether payload content is permitted at all versus id-only notification.

Criteria and channel are a security boundary

A Subscription is a standing instruction to send record content to an endpoint, so criteria and channel together define an ongoing data egress path. Four elements deserve specific attention:

• criteria (1..1) is an R4 search expression such as Observation?patient=123, and a security boundary rather than merely a filter: a broad criteria string, meaning a resource type with no patient or category scoping, subscribes to the whole population of that type. Note also that this IG ships no CapabilityStatement or SearchParameter artifacts, so nothing here states which search parameters a criteria string may rely on -- one using an unsupported parameter may match nothing and fire never.
• channel.endpoint is the egress destination, required in practice for every channel type except websocket. When auditing what leaves the system, review the endpoint, not just the criteria.
• channel.payload carries load-bearing security semantics that read as a formatting detail. When absent, the notification carries no resource content and the receiver must fetch the resource itself, and be authorized to do so. When present, record content is pushed directly to channel.endpoint. Absent is preferred: id-only notification keeps authorization at the read.
• channel.header is readable by anyone who can read the Subscription. A bearer token placed here is exposed accordingly; prefer a channel that does not require an inline credential.

Status and lifetime must be watched, not assumed

status (1..1) is set by the server, not only by the creator. Both error and off mean notifications are not being delivered, and the server may set them itself after repeated delivery failure. A service that created a subscription and assumes it is still live will miss events silently, so status must be polled or watched rather than set and forgotten.

end should be set: an open-ended subscription is a permanent egress path that outlives the reason it was created. reason (1..1) is free text worth writing properly rather than filling with a placeholder, since it is the only human-readable record of why an egress path was opened.