A pattern to be followed by resources that represent the performance of some activity, possibly in accordance with a request or service definition.

Identifiers assigned to this event performer or other systems.

Allows identification of the event as it is known by various participating systems and in a way that remains consistent across servers.

A protocol, guideline, orderset or other definition that was adhered to in whole or in part by this event.

[The allowed reference resources may be adjusted as appropriate for the event resource].

A plan, proposal or order that is fulfilled in whole or in part by this event.

Allows tracing of authorization for the event and tracking whether proposals/recommendations were acted upon.

[The allowed reference resources may be adjusted as appropriate for the event resource].

A larger event of which this particular event is a component or step.

E.g. Drug administration as part of a procedure, procedure as part of observation, etc.

Not to be used to link an event to an Encounter - use Event.context for that.

[The allowed reference resources may be adjusted as appropriate for the event resource].

The current state of the event.

A nominal state-transition diagram can be found in the [[event.html#statemachine | Event pattern]] documentation

Unknown does not represent "other" - one of the defined statuses must apply. Unknown is used when the authoring system is not sure what the current status is.

If true, indicates that the described event (combination of code, timing, performer, etc.) did not actually occur.

Creating a {{title}} where notDone is true is intended for situations where there's a need for a specific statement in the record about something not being done. If the need is merely to indicate that a request wasn't fulfilled, that should be handled using Task.

The more attributes are populated, the more constrained the negated statement is. For example if timeframe and performer are specified, that means the event wasn't done by that performer in that time-period, but could well have been done by someone else or by that performer in a different time period.

Describes why the event did not occur in coded and/or textual form.

This is a separate element to allow it to have a distinct binding from reasonCode.

A code that identifies the specific service or action that was or is being performed.

The individual or set of individuals the action is being or was performed on.

Links the event to the Patient context.

[For resources that aren't patient-specific, the set of allowed resources may be extended to include other things. Group should generally be retained unless there's certainty this resource won't be used for veterinary, research or public health settings where Group may be necessary (e.g. this cage of rats/crate of chickens, group of people in a 5 mile radious of the incident, etc.)].

The encounter or episode of care that establishes the context for this event.

Links the request to the Encounter context.

This will typically be the encounter the event occurred within, but some events may be initiated prior to or after the official completion of an encounter or episode but still be tied to the context of the encounter or episode (e.g. pre-admission lab tests).

The date or time(s) the activity occurred.

[The list of types may be constrained as appropriate for the type of event].

Indicates who or what performed the event.

[Resources may choose to replace this with just a single performer or repeating where there's no need to distinguish role and/or responsible organization].

Describes the type of performance (e.g. primary surgeon, anaesthesiologiest, etc.).

[Adjust vocabulary to be appropriate to your domain - generally should reflect what the performer does, not who they are].

The device, practitioner, etc. who performed the action.

The organization the device or practitioner was acting on behalf of.

Practitioners and Devices can be associated with multiple organizations. This element indicates which organization they were acting on behalf of when performing the action.

Describes why the event occurred in coded or textual form.

Textual reasons can be captured using reasonCode.text.

Indicates another resource whose existence justifies this event.

[Additional resources may be added as appropriate].

Comments made about the event by the performer, subject or other participants.