STU3 Candidate

This page is part of the FHIR Specification (v1.8.0: STU 3 Draft). The current version which supercedes this version is 5.0.0. For a full list of available versions, see the Directory of published versions . Page versions: R5 R4B R4 R3

12.7 Logical Model event - Content

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

12.7.1 Scope and Usage

This is NOT a resource. It is not part of the FHIR schema and cannot appear directly in FHIR instances. It is a logical model that defines a pattern adhered to by other resources. This pattern serves two purposes:

  • It offers guidance to work groups designing resources and helps ensure consistency of content created by different work groups
  • It provides a standard "view" that might be useful for implementers in processing and manipulating all resources that adhere to the same pattern. (Tooling that supports this may become available in a future release.)

12.7.2 Boundaries and Relationships

This logical model is one of three common workflow patterns. The other two patterns are Request and Definition. This pattern is followed by (or is intended to be followed by a number of other FHIR resources/

12.7.3 Background and Context

This resource represents a pattern. It provides a standard list of data elements with cardinalities, data types, definitions, rationale and usage notes that will ideally be adhered to by resources that fall into the "event" workflow category. However, adherence to this pattern is not mandatory. Not all healthcare domains are the same. Concepts that may be generally applicable (and thus are included in this standard pattern) might still not be relevant everywhere or may be sufficiently uncommon that they are more appropriate to include as extensions than as core properties of the resource. Work groups are encouraged to adjust descriptions, usage notes and rationale to be specific to their resource (e.g. use the term "procedure" or "observation" rather than "event"). As well, design notes in the comments column marked with [square brackets] identifies areas where domain variation is expected and encouraged. Other variation, including differences in names, cardinalities, data types and the decision to omit an element outright are also possible, but should be discussed with the FHIR Infrastructure work group's Workflow project to ensure the rationale for non-alignment is understood, to confirm that the deviation is necessary and to identify whether any adjustments to the pattern are appropriate.

This pattern provides a linkage to the W5 list of standard data elements. Resources that adhere to this pattern should ensure their w5 mappings are consistent, as is their data element ordering.

12.7.4 Logical Model Content

Structure

NameFlagsCard.TypeDescription & Constraintsdoco
.. Event ILogicalEvent Pattern
Not Done Reason can only be specified if NotDone is "true"
... identifier Σ0..1IdentifierBusiness Identifer for event
... definition Σ0..*Reference(Definition)Instantiates protocol or definition
... basedOn Σ0..*Reference(Request)Fulfills plan, proposal or order
... partOf Σ0..*Reference(Event)Part of referenced event
... status ?!Σ1..1codepreparation | in-progress | suspended | aborted | completed | entered-in-error
EventStatus (Required)
... notDone ?!Σ0..1boolean{{title}} did not occur
... notDoneReason ΣI0..1CodeableConceptWhy {{title}} did not occur
... code Σ0..1CodeableConceptWhat was done
... subject Σ1..1Reference(Patient | Group)Individual service was done for/to
... context Σ0..1Reference(Encounter | EpisodeOfCare)Encounter / Episode associated with event
... occurrence[x] Σ0..1When event occurred
.... occurrenceDateTimedateTime
.... occurrencePeriodPeriod
.... occurrenceTimingTiming
... performer Σ0..*BackboneElementWho performed event
.... role Σ0..1CodeableConceptWhat type of performance was done
Procedure Performer Role Codes (Required)
.... actor Σ1..1Reference(Practitioner | Organization | Patient | Device | RelatedPerson)Individual who was performing
.... onBehalfOf 0..1Reference(Organization)Organization organization was acting for
... reasonCodeableConcept Σ0..*CodeableConceptWhy was event performed?
... reasonReference Σ0..*Reference(Condition | Observation)Why was event performed?
... note 0..*AnnotationComments made about the event

doco Documentation for this format

UML Diagram (Legend)

Event (Logical)Identifiers assigned to this event performer or other systemsidentifier : Identifier [0..1]A protocol, guideline, orderset or other definition that was adhered to in whole or in part by this eventdefinition : Reference [0..*] « Definition »A plan, proposal or order that is fulfilled in whole or in part by this eventbasedOn : Reference [0..*] « Request »A larger event of which this particular event is a component or steppartOf : Reference [0..*] « Event »The current state of the event (this element modifies the meaning of other elements)status : code [1..1] « Codes identifying the stage lifecycle stage of a event (Strength=Required)EventStatus! »If true, indicates that the described event (combination of code, timing, performer, etc.) did not actually occur (this element modifies the meaning of other elements)notDone : boolean [0..1]Describes why the event did not occur in coded and/or textual formnotDoneReason : CodeableConcept [0..1]A code that identifies the specific service or action that was or is being performedcode : CodeableConcept [0..1]The individual or set of individuals the action is being or was performed onsubject : Reference [1..1] « Patient|Group »The encounter or episode of care that establishes the context for this eventcontext : Reference [0..1] « Encounter|EpisodeOfCare »The date or time(s) the activity occurredoccurrence[x] : Type [0..1] « dateTime|Period|Timing »Describes why the event occurred in coded or textual formreasonCodeableConcept : CodeableConcept [0..*]Indicates another resource whose existence justifies this eventreasonReference : Reference [0..*] « Condition|Observation »Comments made about the event by the performer, subject or other participantsnote : Annotation [0..*]PerformerDescribes the type of performance (e.g. primary surgeon, anaesthesiologiest, etc.)role : CodeableConcept [0..1] « Codes describing the types of functional roles performers can take on when performing events (Strength=Required)Procedure Performer Role ! »The device, practitioner, etc. who performed the actionactor : Reference [1..1] « Practitioner|Organization|Patient|Device| RelatedPerson »The organization the device or practitioner was acting on behalf ofonBehalfOf : Reference [0..1] « Organization »Indicates who or what performed the eventperformer[0..*]

Structure

NameFlagsCard.TypeDescription & Constraintsdoco
.. Event ILogicalEvent Pattern
Not Done Reason can only be specified if NotDone is "true"
... identifier Σ0..1IdentifierBusiness Identifer for event
... definition Σ0..*Reference(Definition)Instantiates protocol or definition
... basedOn Σ0..*Reference(Request)Fulfills plan, proposal or order
... partOf Σ0..*Reference(Event)Part of referenced event
... status ?!Σ1..1codepreparation | in-progress | suspended | aborted | completed | entered-in-error
EventStatus (Required)
... notDone ?!Σ0..1boolean{{title}} did not occur
... notDoneReason ΣI0..1CodeableConceptWhy {{title}} did not occur
... code Σ0..1CodeableConceptWhat was done
... subject Σ1..1Reference(Patient | Group)Individual service was done for/to
... context Σ0..1Reference(Encounter | EpisodeOfCare)Encounter / Episode associated with event
... occurrence[x] Σ0..1When event occurred
.... occurrenceDateTimedateTime
.... occurrencePeriodPeriod
.... occurrenceTimingTiming
... performer Σ0..*BackboneElementWho performed event
.... role Σ0..1CodeableConceptWhat type of performance was done
Procedure Performer Role Codes (Required)
.... actor Σ1..1Reference(Practitioner | Organization | Patient | Device | RelatedPerson)Individual who was performing
.... onBehalfOf 0..1Reference(Organization)Organization organization was acting for
... reasonCodeableConcept Σ0..*CodeableConceptWhy was event performed?
... reasonReference Σ0..*Reference(Condition | Observation)Why was event performed?
... note 0..*AnnotationComments made about the event

doco Documentation for this format

UML Diagram (Legend)

Event (Logical)Identifiers assigned to this event performer or other systemsidentifier : Identifier [0..1]A protocol, guideline, orderset or other definition that was adhered to in whole or in part by this eventdefinition : Reference [0..*] « Definition »A plan, proposal or order that is fulfilled in whole or in part by this eventbasedOn : Reference [0..*] « Request »A larger event of which this particular event is a component or steppartOf : Reference [0..*] « Event »The current state of the event (this element modifies the meaning of other elements)status : code [1..1] « Codes identifying the stage lifecycle stage of a event (Strength=Required)EventStatus! »If true, indicates that the described event (combination of code, timing, performer, etc.) did not actually occur (this element modifies the meaning of other elements)notDone : boolean [0..1]Describes why the event did not occur in coded and/or textual formnotDoneReason : CodeableConcept [0..1]A code that identifies the specific service or action that was or is being performedcode : CodeableConcept [0..1]The individual or set of individuals the action is being or was performed onsubject : Reference [1..1] « Patient|Group »The encounter or episode of care that establishes the context for this eventcontext : Reference [0..1] « Encounter|EpisodeOfCare »The date or time(s) the activity occurredoccurrence[x] : Type [0..1] « dateTime|Period|Timing »Describes why the event occurred in coded or textual formreasonCodeableConcept : CodeableConcept [0..*]Indicates another resource whose existence justifies this eventreasonReference : Reference [0..*] « Condition|Observation »Comments made about the event by the performer, subject or other participantsnote : Annotation [0..*]PerformerDescribes the type of performance (e.g. primary surgeon, anaesthesiologiest, etc.)role : CodeableConcept [0..1] « Codes describing the types of functional roles performers can take on when performing events (Strength=Required)Procedure Performer Role ! »The device, practitioner, etc. who performed the actionactor : Reference [1..1] « Practitioner|Organization|Patient|Device| RelatedPerson »The organization the device or practitioner was acting on behalf ofonBehalfOf : Reference [0..1] « Organization »Indicates who or what performed the eventperformer[0..*]

 

12.7.4.1 Terminology Bindings

PathDefinitionTypeReference
Event.status Codes identifying the stage lifecycle stage of a eventRequiredEventStatus
Event.code Codes indicating the details of what is/was done. These will vary significantly based on the type of request resource and will often be example/preferred rather than extensible/required.UnknownNo details provided yet
Event.performer.role Codes describing the types of functional roles performers can take on when performing eventsRequiredProcedure Performer Role Codes
Event.reasonCodeableConcept Codes identifying why this event was necessary. These may be clinical reasons (e.g. diagnoses, symptoms) and/or administrative reasons. While the detailed constraints of relevant reasons will vary by resource, some degree of consistency across resources around recommended codes would be desirable.UnknownNo details provided yet

12.7.4.2 Constraints

  • inv-1: Not Done Reason can only be specified if NotDone is "true" (expression : notDone or notDoneReason.exists().not())

12.7.5 State Machine

The following diagram shows the "typical" state machine diagram for resources following the Event pattern. Note that not all resources will support all states, some resources may choose different names for certain states and some resources may introduce sub-states to the listed states. As well, additional transitions may be supported, including from terminal nodes (e.g. from "completed" back to "in-progress"). That said, most resources should align with this state machine fairly well.

Typical state machine diagram for resources following the Event pattern