to do
Logical Model: A pattern to be followed by resources that represent the performance of some activity, possibly in accordance with a request or service definition.
A pattern to be followed by resources that represent the performance of some activity, possibly in accordance with a request or service definition.
All FHIR elements must have a @value or children
hasValue() or (children().count() > id.count())
Not Done Reason can only be specified if status is 'not-done'
status='not-done' or notDoneReason.exists().not()
reason elements can only be specified if status is NOT 'not-done'
status!='not-done' or (reasonCode.exists().not() and reasonReference.exists().not())
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 server.
Note: This is a business identifier, not a resource identifier (see [discussion](resource.html#identifiers)). It is best practice for the identifier to only appear on a single resource instance, however business practices may occasionally dictate that multiple resource instances with the same identifier can exist - possibly even with different resource types. For example, multiple Patient and a Person resource instance might share the same social insurance number.
Allows identification of the {{title}} as it is known by various participating systems and in a way that remains consistent across servers.
A plan, proposal or order that is fulfilled in whole or in part by this {{title}}.
[The allowed reference resources may be adjusted as appropriate for the event resource].
Allows tracing of authorization for the {{title}} and tracking whether proposals/recommendations were acted upon.
A larger event of which this particular {{title}} is a component or step.
Not to be used to link an {{title}} to an Encounter - use 'context' for that.[The allowed reference resources may be adjusted as appropriate for the event resource].
[E.g. Drug administration as part of a procedure, procedure as part of observation, etc.].
Indicates that this {{title}} is relevant to the specified research study(ies).
This relevance might mean that the {{title}} occurred as part of the study protocol, but can also include events that occurred outside the study but still have relevance.
.outboundRelationship[typeCode=PERT].target[classCode=CLNTRL, moodCode=EVN]
preparation | in-progress | not-done | suspended | aborted | completed | entered-in-error | unknown
A nominal state-transition diagram can be found in the (Event pattern)[event.html#statemachine] 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.
This element is labelled as a modifier because it is a status element that contains status entered-in-error which means that the resource should not be treated as valid
Codes identifying the lifecycle stage of an event.
Captures the reason for the current state of the {{title}}.
This is generally only used for "exception" statuses such as "not-done", "suspended" or "cancelled". The reason for performing the event at all is captured in reasonCode, not here. [distinct reason codes for different statuses can be enforced using invariants if they are universal bindings].
Codes identifying the reason for the current state of an event.
.inboundRelationship[typeCode=SUBJ].source[classCode=CACT, moodCode=EVN].reasonCOde
Partitions the {{title}} into one or more categories that can be used to filter searching, to govern access control and/or to guide system behavior.
Categorization might be done automatically (inferred by code) or manually by user assertion. The absence of a category may limit the ability to determine when the element should be handled, so strong consideration should be given to how systems will be able to determine category values for legacy data and how data that cannot be categorized will be handled. As well, some categories might not be mutually exclusive, so systems should prepare for multiple declared categories - even within a single category 'axis'. In general, there should not be a 'strong' binding ('required' or 'extensible') on the category element overall. Instead, the element can be sliced and bindings can be asserted that apply to particular repetitions.
A code that identifies the specific service or action that was or is being performed.
[In some cases, the service type is implicit based on the scope of the resource and only a product element will be present].
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.
Indicates the product supplied or manipulated by this {{title}}.
The individual or set of individuals the action is being or was performed on.
[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.)].
Links the {{title}} to the Patient context. May also affect access control.
The Encounter during which this {{title}} was created or to which the creation of this record is tightly associated.
This will typically be the encounter the {{title}} was created during, but some {{title}}s may be initiated prior to or after the official completion of an encounter but still be tied to the context of the encounter (e.g. pre-admission lab tests).
Links the {{title}} to the Encounter context. May also affect access control.
.inboundRelationship(typeCode=COMP].source[classCode<=PCPR, moodCode=EVN]
The date, period or timing when the {{title}} did occur or is occurring.
This indicates when the activity actually occurred or is occurring, not when it was asked/requested/ordered to occur. For the latter, look at the occurence element of the Request this {{event}} is "basedOn". The status code allows differentiation of whether the timing reflects a historic event or an ongoing event. Ongoing events should not include an upper bound in the Period or Timing.bounds. [The list of types may be constrained as appropriate for the type of event. The use of 'Timing' in type is generally only appropriate for Events that are typically used to represent summary information.].
When {{title}} was first captured in the subject's record
The date the occurrence of the {{title}} was first captured in the record - potentially significantly after the occurrence of the event.
The recorded date indicates the date when the data was placed in the record maintained by the performing practitioner, or the date of disclosure by Patient or RelatedPerson, not a date of record transfer. If the record is transferred from one system to another (in paper or electronic form), it does not create a distinct recorded date. In most cases, performing practitioners will record on the same date the event occurred, but sometimes there are delays. If information is being relayed second-hand, the recorded date indicates when the system is first made aware of the data. The recorded date is NOT intended to be the same as a database.createdTimestamp - that would be captured as part of resource.meta or possibly Provenance. It is possible for the same event to be disclosed to different systems at different times. E.g. a patient might tell two different clinicians about a historical event at different visits. If the disclosure is from the patient rather than record transfer from clinician A to B, the recorded date would be the date each respective clinician put the data in their record. If the data flowed from clinician A to B, the recorded date would remain the recorded date as initially set in clinician A's system.
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 report.
Reported data may have different rules on editing and may be visually distinguished from primary data.
Who performed {{title}} and what they did
Indicates who or what performed the {{title}} and how they were involved.
[Resources may choose to replace this with just a single performer or repeating where there's no need to distinguish the function performed].
Distinguishes the type of involvement of the performer in the {{title}}. [Consider adding examples].
Allows disambiguation of the types of involvement of different performers.
Codes that describe the specific involvement of a performer in an event. E.g. Primary vs. secondary vs. supervising, etc.
Indicates who or what performed the {{title}}.
The principal physical location where the {{title}} was performed.
Ties the event to where the records are likely kept and provides context around the event occurrence (e.g. if it occurred inside or outside a dedicated healthcare setting).
Describes why the {{title}} occurred in coded or textual form or Indicates another resource whose existence justifies this {{title}}.
Textual reasons can be captured using reasonCode.text.
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.
Comments made about the {{title}} by the performer, subject or other participants.
.inboundRelationship(typeCode=SUBJ].source[classCode=ANNGEN, moodCode=EVN].value[xsi:type=ST]
Links to Provenance records for past versions of this resource or component resources that identify key state transitions or updates that are likely to be relevant to a user looking at the current version of the resource.
This element does not point to the Provenance associated with the *current* version of the resource - as it would be created after this version existed. The Provenance for the current version can be retrieved with a _revinclude. Referenced provenances should adhere to the provenance-relevant-history profile. See additional guidance [here](event.html#history).
.inboundRelationship(typeCode=SUBJ].source[classCode=CACT, moodCode=EVN]