Release 5 Preview #1

This page is part of the FHIR Specification (v4.2.0: R5 Preview #1). 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.4 Pattern event - Content

FHIR Infrastructure Maturity Level: 1Informative

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

12.4.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.)

An "event" is any description of an activity that has already taken place or that is currently ongoing. It includes resources that primarily describe the "result" of an activity or what was found (e.g. a condition or observation). Examples include encounters, procedures, completed questionnaires, representations of state transitions, etc. It does not include resources that describe objects or roles (e.g. patient, device, location).

12.4.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

Events are distinct from requests in that an event is primarily focused on what has occurred or is occurring while requests deal with what is "desired" to occur. While creating a request or definition can be seen as a type of event, the focus of those other resources is not the "creation" but the desire/intention.

Events are related to Task in that events can be performed in fulfillment of a task and performing an event may involve the execution of one or more tasks. Events do not track the fulfillment of any requests they may be associated with. Tracking of fulfillment is managed through the Task resource.

12.4.3 Background and Context

This model 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.4.4 References

This pattern is implemented by AuditEvent, ChargeItem, ClaimResponse, ClinicalImpression, Communication, Composition, Condition, Consent, Coverage, CoverageEligibilityResponse, DetectedIssue, DeviceUseStatement, DiagnosticReport, DocumentManifest, DocumentReference, Encounter, EnrollmentResponse, EpisodeOfCare, ExplanationOfBenefit, FamilyMemberHistory, GuidanceResponse, ImagingStudy, Immunization, ImmunizationEvaluation, MedicationAdministration, MedicationDispense, MedicationUsage, NutritionIntake, Observation, PaymentNotice, PaymentReconciliation, Procedure, Provenance, QuestionnaireResponse, RiskAssessment and SupplyDelivery.

12.4.5 Pattern Content

Structure

NameFlagsCard.TypeDescription & Constraintsdoco
.. Event ILogicalEvent Pattern
+ Rule: Not Done Reason can only be specified if status is 'not-done'
+ Rule: reason elements can only be specified if status is NOT 'not-done'
... identifier Σ0..*IdentifierBusiness Identifier for {{title}}
... instantiatesCanonical Σ0..*canonical(Definition)Instantiates FHIR protocol or definition
... instantiatesUri Σ0..*uriInstantiates external protocol or definition
... partOf Σ0..*Reference(Event)Part of referenced event
... researchStudy 0..*Reference(ResearchStudy)Associated research study
... status ?!Σ1..1codepreparation | in-progress | not-done | suspended | aborted | completed | entered-in-error | unknown
EventStatus (Required)
... statusReason 0..1CodeableConceptReason for current status
... code Σ0..1CodeableConceptWhat was done
... subject Σ1..1Reference(Patient | Group)Individual service was done for/to
... encounter Σ0..1Reference(Encounter)Encounter created as part of
... occurrence[x] Σ0..1When {{title}} occurred/is occurring
.... occurrenceDateTimedateTime
.... occurrencePeriodPeriod
.... occurrenceTimingTiming
... recorded Σ0..1dateTimeWhen {{title}} was first captured in the subject's record
... reported[x] Σ0..1Reported rather than primary record
.... reportedBooleanboolean
.... reportedReferenceReference(Patient | RelatedPerson | Practitioner | PractitionerRole | Organization)
... performer Σ0..*BackboneElementWho performed {{title}} and what they did
.... function Σ0..1CodeableConceptType of performance
.... actor Σ1..1Reference(Practitioner | PractitionerRole | Organization | CareTeam | Patient | Device | RelatedPerson)Who performed {{title}}
... location Σ0..1Reference(Location)Where {{title}} occurred
... reason Σ0..*CodeableReference(Condition | Observation | DiagnosticReport | DocumentReference)Why was {{title}} performed?
... note 0..*AnnotationComments made about the event

doco Documentation for this format

UML Diagram (Legend)

Event (Base) «Pattern»Business identifiers assigned to this {{title}} by the performer and/or other systems. These identifiers remain constant as the resource is updated and propagates from server to serveridentifier : Identifier [0..*]The URL pointing to a FHIR-defined protocol, guideline, orderset or other definition that is adhered to in whole or in part by this {{title}}instantiatesCanonical : canonical [0..*] « Definition »The URL pointing to an externally maintained protocol, guideline, orderset or other definition that is adhered to in whole or in part by this {{title}}instantiatesUri : uri [0..*]A plan, proposal or order that is fulfilled in whole or in part by this {{title}}basedOn : Reference [0..*] « Request »A larger event of which this particular {{title}} is a component or steppartOf : Reference [0..*] « Event »Indicates that this {{title}} is relevant to the specified research study(ies)researchStudy : Reference [0..*] « ResearchStudy »The current state of the {{title}} (this element modifies the meaning of other elements)status : code [1..1] « Codes identifying the lifecycle stage of an event. (Strength=Required)EventStatus! »Captures the reason for the current state of the {{title}}statusReason : 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 during which this {{title}} was created or to which the creation of this record is tightly associatedencounter : Reference [0..1] « Encounter »The date, period or timing when the {{title}} did occur or is occurringoccurrence[x] : DataType [0..1] « dateTime|Period|Timing »The date the occurrence of the {{title}} was first captured in the record - potentially significantly after the occurrence of the eventrecorded : dateTime [0..1]Indicates if this record was captured as a secondary 'reported' record rather than as an original primary source-of-truth record. It may also indicate the source of the reportreported[x] : DataType [0..1] « boolean|Reference(Patient| RelatedPerson|Practitioner|PractitionerRole|Organization) »The principal physical location where the {{title}} was performedlocation : Reference [0..1] « Location »Describes why the {{title}} occurred in coded or textual form or Indicates another resource whose existence justifies this {{title}}reason : DataType [0..*] « Condition|Observation|DiagnosticReport| DocumentReference »Comments made about the {{title}} by the performer, subject or other participantsnote : Annotation [0..*]PerformerDistinguishes the type of involvement of the performer in the {{title}}. [Consider adding examples]function : CodeableConcept [0..1]Indicates who or what performed the {{title}}actor : Reference [1..1] « Practitioner|PractitionerRole| Organization|CareTeam|Patient|Device|RelatedPerson »Indicates who or what performed the {{title}} and how they were involvedperformer[0..*]

Structure

NameFlagsCard.TypeDescription & Constraintsdoco
.. Event ILogicalEvent Pattern
+ Rule: Not Done Reason can only be specified if status is 'not-done'
+ Rule: reason elements can only be specified if status is NOT 'not-done'
... identifier Σ0..*IdentifierBusiness Identifier for {{title}}
... instantiatesCanonical Σ0..*canonical(Definition)Instantiates FHIR protocol or definition
... instantiatesUri Σ0..*uriInstantiates external protocol or definition
... partOf Σ0..*Reference(Event)Part of referenced event
... researchStudy 0..*Reference(ResearchStudy)Associated research study
... status ?!Σ1..1codepreparation | in-progress | not-done | suspended | aborted | completed | entered-in-error | unknown
EventStatus (Required)
... statusReason 0..1CodeableConceptReason for current status
... code Σ0..1CodeableConceptWhat was done
... subject Σ1..1Reference(Patient | Group)Individual service was done for/to
... encounter Σ0..1Reference(Encounter)Encounter created as part of
... occurrence[x] Σ0..1When {{title}} occurred/is occurring
.... occurrenceDateTimedateTime
.... occurrencePeriodPeriod
.... occurrenceTimingTiming
... recorded Σ0..1dateTimeWhen {{title}} was first captured in the subject's record
... reported[x] Σ0..1Reported rather than primary record
.... reportedBooleanboolean
.... reportedReferenceReference(Patient | RelatedPerson | Practitioner | PractitionerRole | Organization)
... performer Σ0..*BackboneElementWho performed {{title}} and what they did
.... function Σ0..1CodeableConceptType of performance
.... actor Σ1..1Reference(Practitioner | PractitionerRole | Organization | CareTeam | Patient | Device | RelatedPerson)Who performed {{title}}
... location Σ0..1Reference(Location)Where {{title}} occurred
... reason Σ0..*CodeableReference(Condition | Observation | DiagnosticReport | DocumentReference)Why was {{title}} performed?
... note 0..*AnnotationComments made about the event

doco Documentation for this format

UML Diagram (Legend)

Event (Base) «Pattern»Business identifiers assigned to this {{title}} by the performer and/or other systems. These identifiers remain constant as the resource is updated and propagates from server to serveridentifier : Identifier [0..*]The URL pointing to a FHIR-defined protocol, guideline, orderset or other definition that is adhered to in whole or in part by this {{title}}instantiatesCanonical : canonical [0..*] « Definition »The URL pointing to an externally maintained protocol, guideline, orderset or other definition that is adhered to in whole or in part by this {{title}}instantiatesUri : uri [0..*]A plan, proposal or order that is fulfilled in whole or in part by this {{title}}basedOn : Reference [0..*] « Request »A larger event of which this particular {{title}} is a component or steppartOf : Reference [0..*] « Event »Indicates that this {{title}} is relevant to the specified research study(ies)researchStudy : Reference [0..*] « ResearchStudy »The current state of the {{title}} (this element modifies the meaning of other elements)status : code [1..1] « Codes identifying the lifecycle stage of an event. (Strength=Required)EventStatus! »Captures the reason for the current state of the {{title}}statusReason : 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 during which this {{title}} was created or to which the creation of this record is tightly associatedencounter : Reference [0..1] « Encounter »The date, period or timing when the {{title}} did occur or is occurringoccurrence[x] : DataType [0..1] « dateTime|Period|Timing »The date the occurrence of the {{title}} was first captured in the record - potentially significantly after the occurrence of the eventrecorded : dateTime [0..1]Indicates if this record was captured as a secondary 'reported' record rather than as an original primary source-of-truth record. It may also indicate the source of the reportreported[x] : DataType [0..1] « boolean|Reference(Patient| RelatedPerson|Practitioner|PractitionerRole|Organization) »The principal physical location where the {{title}} was performedlocation : Reference [0..1] « Location »Describes why the {{title}} occurred in coded or textual form or Indicates another resource whose existence justifies this {{title}}reason : DataType [0..*] « Condition|Observation|DiagnosticReport| DocumentReference »Comments made about the {{title}} by the performer, subject or other participantsnote : Annotation [0..*]PerformerDistinguishes the type of involvement of the performer in the {{title}}. [Consider adding examples]function : CodeableConcept [0..1]Indicates who or what performed the {{title}}actor : Reference [1..1] « Practitioner|PractitionerRole| Organization|CareTeam|Patient|Device|RelatedPerson »Indicates who or what performed the {{title}} and how they were involvedperformer[0..*]

 

alternate definitions: Master Definition XML + JSON.

12.4.5.1 Terminology Bindings

PathDefinitionTypeReference
Event.status Codes identifying the lifecycle stage of an event.RequiredEventStatus
Event.statusReason Codes identifying the reason for the current state of an event.UnknownNo details provided yet
Event.code Codes indicating the details of what is/was done. These will vary significantly based on the type of event resource and will often be example/preferred rather than extensible/required.UnknownNo details provided yet
Event.performer.function Codes that describe the specific involvement of a performer in an event. E.g. Primary vs. secondary vs. supervising, etc.UnknownNo details provided yet
Event.reason 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.4.5.2 Constraints

idLevelLocationDescriptionExpression
inv-1Rule (base)Not Done Reason can only be specified if status is 'not-done'status='not-done' or notDoneReason.exists().not()
inv-2Rule (base)reason elements can only be specified if status is NOT 'not-done'status!='not-done' or (reasonCode.exists().not() and reasonReference.exists().not())

12.4.6 Extensions

Not all resources that follow the 'Event' pattern will necessarily include all of the above elements. A set of standard extensions have been defined for use with resources where an element might be "applicable" but is not commonly supported. A list of these can be found on the Event Extensions(event-specific) and Workflow Extensions(shared by events and requests).

12.4.7 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

12.4.7.1 Mappings

identifier instantiatesCanonical instantiatesUri basedOn partOf researchStudy status statusReason code subject encounter occurrence[x] recorded reported[x] performer .function .actor location reason note
AdverseEvent 1 1 1 1 1 1 N 1 N 1 1 1
AuditEvent 1 N 1 N 1 N 1 NC 1
ChargeItem 1 1 1 1 1 1 1 1 2 NC 1
ClaimResponse 1 1 N 1 1 N 1 N 1 N
ClinicalImpression 1 1 1 1 1 N 1 NC 1
Communication 1 1 1 1 1 1 1 1 C 2 N 2 NC 1
Composition 1 E 1 1 N 1 NC 1 N 1 N
Condition 1 E E 2 NC 1 1 1 N 1
Consent 1 E 1 1 NC 1 NC 1 N 1 N 1 NC
Contract
Coverage 1 1 1 N 1 N
CoverageEligibilityResponse 1 1 N 1 1 N 1 N
DetectedIssue 1 1 1 1 NC 1 N 1 NC 1 N
DeviceUseStatement 1 1 E 1 E 1 1 N 1 NC 2 N
DiagnosticReport 1 1 E E 1 E 1 1 C 1 1 N 2 NC E
DocumentManifest 2 N 1 1 N 1 C 1 N 1 N 1 NC
DocumentReference 2 N E 1 E 1 N 1 C 1 N 3 NC E
Encounter 1 2 N 1 E 1 2 NC 1 C 2 N 1 N 1 NC 2 NC 1 1
EnrollmentResponse 1 1 N 1 C 1 N 1 N 1 NC
EpisodeOfCare 1 1 N 1 1 NC 1 N 1 N 3 NC
ExplanationOfBenefit 1 1 1 N 1 N 1 N
FamilyMemberHistory 1 1 1 E 1 1 N 1 1
GuidanceResponse 1 1 N 1 1 C 1 1 N 1 NC 1 1
ImagingStudy 1 1 1 N 1 1 1 1 N 1 1 1 1
Immunization 1 E 1 1 1 N 1 N 1 1 1 1 1 1 1
ImmunizationEvaluation 1 1 1 N 1 N
Invoice 3 N 1 C 1
MedicationAdministration 1 1 N 1 E 1 1 C 1 N 1 1 N 1 1 1 1 1
MedicationDispense 1 1 N 1 E 1 1 N 1 N 1 C 1 N 1 1 1
MedicationUsage 1 1 1 E 1 1 C 1 N 1 1 N 1 1
NutritionIntake 1 1 1 1 1 C 1 N 1 1 N 1 N 1
Observation 1 1 1 E 1 E 1 1 C 1 N 1 NC E
PaymentNotice 1 1 N 1 1 N 1 N
PaymentReconciliation 1 1 1 N 1 NC 1 N
Procedure 1 1 1 1 1 E 1 1 1 1 1 1 1 1 1 1 1 1
Provenance 1 N 1 N 1 N 1 N 1
QuestionnaireResponse 1 1 1 E 1 1 C 1 1 N 1 N
RiskAssessment 1 1 1 N E 1 1 1 1 1 1 NC 1 1
SupplyDelivery 1 1 1 E 1 C E 1 N 1 NC 1 1 N E
Task 1 E 1 N 1 NC 1 N