EventDefinition — Triggering event definition
The reusable "when X happens" pattern. PlanDefinition, Subscription and Measure reference EventDefinitions to fire their flows.
Purpose of the resource
EventDefinition encapsulates the definition of an event that can be consumed by other resources. Rather than each PlanDefinition or Subscription defining its own internal trigger, the logic is encoded once in a reusable, versioned, published EventDefinition.
Key fields
| Field | Type | Cardinality | Role |
|---|---|---|---|
url | uri | 0..1 | Canonical URL. |
identifier | Identifier[] | 0..* | Business identifiers. |
version | string | 0..1 | Version. |
name | string | 0..1 | Technical name. |
title | string | 0..1 | Title. |
subtitle | string | 0..1 | Subtitle. |
status | code | 1..1 | draft | active | retired | unknown. |
experimental | boolean | 0..1 | Test vs production. |
subject[x] | CodeableConcept | Reference | 0..1 | Subject. |
date | dateTime | 0..1 | Date. |
usage | markdown | 0..1 | Usage context. |
trigger | TriggerDefinition[] | 1..* | Trigger definitions (named-event, data-changed, data-added, data-modified, data-removed, periodic). |
JSON example
{
"resourceType": "EventDefinition",
"id": "critical-lab-result",
"url": "http://example.org/EventDefinition/critical-lab-result",
"version": "5.0.0",
"name": "CriticalLabResult",
"title": "Critical Lab Result Detected",
"status": "active",
"experimental": false,
"date": "2026-05-15",
"trigger": [{
"type": "data-changed",
"name": "Observation-critical",
"data": [{
"type": "Observation",
"profile": ["http://example.org/StructureDefinition/critical-observation"]
}]
}]
} Common pitfalls
- Trigger without
data— the system does not know what to watch. - Confusion with ActivityDefinition — EventDefinition describes a trigger; ActivityDefinition describes an action.
- No version — subscriptions lose their reference.
Related resources
- PlanDefinition — consumes triggers.
- Subscription.
- Measure.
- ActivityDefinition.
- FHIR R5 hub.