12.4 Pattern event - Content

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.

• Structure
• UML
• Both

Structure

Name	Flags	Card.	Type	Description & Constraints
Event	II		Logical	Event Pattern + reason elements can only be specified if status is NOT 'not-done' + Not Done Reason can only be specified if status is 'not-done'
identifier	Σ	0..*	Identifier	Business Identifier for {{title}}
instantiatesCanonical	Σ	0..*	canonical	Instantiates FHIR protocol or definition
instantiatesUri	Σ	0..*	uri	Instantiates external protocol or definition
basedOn	Σ	0..*	Reference(Request)	Fulfills plan, proposal or order
partOf	Σ	0..*	Reference(Event)	Part of referenced event
status	?!Σ	1..1	code	preparation | in-progress | not-done | suspended | aborted | completed | entered-in-error | unknown EventStatus (Required)
statusReason		0..1	CodeableConcept	Reason for current status
code	Σ	0..1	CodeableConcept	What was done
subject	Σ	1..1	Reference(Patient | Group)	Individual service was done for/to
context	Σ	0..1	Reference(Encounter | EpisodeOfCare)	Associated Encounter / Episode
occurrence[x]	Σ	0..1		When {{title}} occurred/is occurring
occurrenceDateTime			dateTime
occurrencePeriod			Period
occurrenceTiming			Timing
performer	Σ	0..*	BackboneElement	Who performed {{title}} and what they did
function	Σ	0..1	CodeableConcept	Type of performance
actor	Σ	1..1	Reference(Practitioner | PractitionerRole | Organization | CareTeam | Patient | Device | RelatedPerson)	Who performed {{title}}
location	Σ	0..1	Reference(Location)	Where {{title}} occurred
reasonCode	Σ	0..*	CodeableConcept	Why was {{title}} performed?
reasonReference	Σ	0..*	Reference(Condition | Observation | Media | DiagnosticReport | DocumentReference)	Why was {{title}} performed?
note		0..*	Annotation	Comments made about the event
Documentation for this format

Structure

Name	Flags	Card.	Type	Description & Constraints
Event	II		Logical	Event Pattern + reason elements can only be specified if status is NOT 'not-done' + Not Done Reason can only be specified if status is 'not-done'
identifier	Σ	0..*	Identifier	Business Identifier for {{title}}
instantiatesCanonical	Σ	0..*	canonical	Instantiates FHIR protocol or definition
instantiatesUri	Σ	0..*	uri	Instantiates external protocol or definition
basedOn	Σ	0..*	Reference(Request)	Fulfills plan, proposal or order
partOf	Σ	0..*	Reference(Event)	Part of referenced event
status	?!Σ	1..1	code	preparation | in-progress | not-done | suspended | aborted | completed | entered-in-error | unknown EventStatus (Required)
statusReason		0..1	CodeableConcept	Reason for current status
code	Σ	0..1	CodeableConcept	What was done
subject	Σ	1..1	Reference(Patient | Group)	Individual service was done for/to
context	Σ	0..1	Reference(Encounter | EpisodeOfCare)	Associated Encounter / Episode
occurrence[x]	Σ	0..1		When {{title}} occurred/is occurring
occurrenceDateTime			dateTime
occurrencePeriod			Period
occurrenceTiming			Timing
performer	Σ	0..*	BackboneElement	Who performed {{title}} and what they did
function	Σ	0..1	CodeableConcept	Type of performance
actor	Σ	1..1	Reference(Practitioner | PractitionerRole | Organization | CareTeam | Patient | Device | RelatedPerson)	Who performed {{title}}
location	Σ	0..1	Reference(Location)	Where {{title}} occurred
reasonCode	Σ	0..*	CodeableConcept	Why was {{title}} performed?
reasonReference	Σ	0..*	Reference(Condition | Observation | Media | DiagnosticReport | DocumentReference)	Why was {{title}} performed?
note		0..*	Annotation	Comments made about the event
Documentation for this format

UML Diagram (Legend)