FHIR Release 3 (STU) CI-Build

This page is part of the FHIR Specification (v3.0.2: STU 3). The current version which supercedes this version is 5.0.0 . For a full list Continuous Integration Build of available versions, see FHIR (will be incorrect/inconsistent at times).
See the Directory of published versions icon . Page versions: R5 R4B R4 R3

12.4 Logical Model event Pattern Event - Content

Responsible Owner: FHIR Infrastructure icon Informative

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" "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" "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" "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" "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" "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" "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" "procedure" or "observation" "observation" rather than "event"). "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 to this Pattern

12.4.4 12.4.5 Logical Model Pattern Content

Structure

Instantiates protocol Σ ?! Σ 0..1 Why What type Σ
Name Flags Card. Type Description & Constraints      Filter: Filters doco
. . Event I Logical Event Pattern
+ Rule: Not Done Reason can only be specified if NotDone status is "true" 'not-done'
+ Rule: reason elements can only be specified if status is NOT 'not-done'
. . . identifier Σ 0..* Identifier Business Identifier identifier for event {{title}}

. . . definition basedOn Σ 0..* Reference ( Definition Request ) Fulfills plan, proposal or definition order

. . basedOn . partOf Σ 0..* Reference ( Request Event ) Part of referenced event
Fulfills plan, proposal or order
. . . status ?! Σ 1..1 code preparation | in-progress | not-done | suspended | aborted | completed | entered-in-error | unknown
Binding: EventStatus ( Required )
. . notDone . statusReason 0..1 boolean CodeableConcept Reason for current status
{{title}} did not occur
. . notDoneReason . category Σ I 0..* CodeableConcept High level categorization of {{title}} did not occur

. . . code Σ 0..1 CodeableConcept What service was done
. . . product Σ 0..1 CodeableReference ( BiologicallyDerivedProduct | Device | DeviceDefinition | Medication | NutritionProduct | Substance ) Product used/provided
. . . subject Σ 1..1 Reference ( Patient | Group ) Individual service was done for/to
. . context . encounter Σ 0..1 Reference ( Encounter | EpisodeOfCare ) Encounter / Episode associated with event the {{title}} is part of
. . . occurrence[x] Σ 0..1 When event occurred {{title}} occurred/is occurring
. . . . occurrenceDateTime dateTime
. . . . occurrencePeriod Period
. . . . occurrenceTiming Timing
. . performer . recorded Σ 0..1 dateTime When {{title}} was first captured in the subject's record
... reported[x] Σ 0..1 Reported rather than primary record
.... reportedBoolean 0..* BackboneElement boolean
. . . . reportedReference Reference ( Patient | RelatedPerson | Practitioner | PractitionerRole | Organization )
... performer Σ 0..* BackboneElement Who performed event {{title}} and what they did

. . . role . function Σ 0..1 CodeableConcept Type of performance was done
Procedure Performer Role Codes ( Example )
. . . . actor Σ 1..1 Reference ( Practitioner | PractitionerRole | Organization | CareTeam | Patient | Device | RelatedPerson ) Who performed {{title}}
Individual who was performing
. . onBehalfOf . location Σ 0..1 Reference ( Organization Location ) Where {{title}} occurred
Organization organization was acting for
. . reasonCode . reason Σ 0..* CodeableConcept CodeableReference ( Condition | Observation | DiagnosticReport | DocumentReference ) Why was event {{title}} performed?

. . reasonReference . note 0..* Reference ( Condition | Observation Annotation ) Why was Comments made about the event performed?

. . note . relevantHistory 0..* Annotation Reference ( Provenance Relevant History ) Key events in history of {{title}}
Comments made about the event

doco Documentation for this format icon

UML Diagram ( Legend )

Event ( Logical Base ) «Pattern» Identifiers Business identifiers assigned to this event {{title}} by the performer or and/or other systems systems. These identifiers remain constant as the resource is updated and propagates from server to server identifier : Identifier [0..*] A protocol, guideline, orderset or other definition that was adhered to in whole or in part by this event definition : Reference [0..*] Definition A plan, proposal or order that is fulfilled in whole or in part by this event {{title}} basedOn : Reference [0..*] « Request » A larger event of which this particular event {{title}} is a component or step partOf : Reference [0..*] « Event » Indicates that this {{title}} is relevant to the specified research study(ies) researchStudy : Reference [0..*] « ResearchStudy » The current state of the event {{title}} (this element modifies the meaning of other elements) status : code [1..1] « Codes identifying the stage lifecycle stage of a event an event. (Strength=Required) EventStatus ! » If true, indicates that Captures the described event (combination of code, timing, performer, etc.) did not actually occur (this element modifies reason for the meaning current state of other elements) the {{title}} notDone statusReason : boolean CodeableConcept [0..1] Describes why Partitions the event did not occur in coded {{title}} into one or more categories that can be used to filter searching, to govern access control and/or textual form to guide system behavior notDoneReason category : CodeableConcept [0..1] [0..*] A code that identifies the specific service or action that was or is being performed code : CodeableConcept [0..1] Indicates the product supplied or manipulated by this {{title}} product : CodeableReference [0..1] « BiologicallyDerivedProduct | Device | DeviceDefinition | Medication | NutritionProduct | Substance » The individual or set of individuals the action is being or was performed on subject : Reference [1..1] « Patient | Group » The encounter Encounter during which this {{title}} was created or episode of care that establishes to which the context for creation of this event record is tightly associated context encounter : Reference [0..1] « Encounter | EpisodeOfCare » The date date, period or time(s) timing when the activity occurred {{title}} did occur or is occurring occurrence[x] : Type DataType [0..1] « dateTime | Period | Timing » Describes why The date the event occurred occurrence of the {{title}} was first captured in coded or textual form the record - potentially significantly after the occurrence of the event reasonCode recorded : CodeableConcept dateTime [0..*] [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 report reported[x] : DataType [0..1] « boolean | Reference ( Patient | RelatedPerson | Practitioner | PractitionerRole | Organization ) » The principal physical location where the {{title}} was performed location : Reference [0..1] « Location » Describes why the {{title}} occurred in coded or textual form or Indicates another resource whose existence justifies this event {{title}} reasonReference reason : Reference CodeableReference [0..*] « Condition | Observation | DiagnosticReport | DocumentReference » Comments made about the event {{title}} by the performer, subject or other participants note : Annotation [0..*] 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 relevantHistory : Reference [0..*] « ( ProvenanceRelevantHistory ) » Performer Describes Distinguishes the type of performance (e.g. primary surgeon, anaesthesiologiest, etc.) involvement of the performer in the {{title}}. [Consider adding examples] role function : CodeableConcept [0..1] Codes describing the types of functional roles performers can take on when performing events (Strength=Example) Procedure Performer Role ?? The device, practitioner, etc. Indicates who or what performed the action {{title}} actor : Reference [1..1] « Practitioner | PractitionerRole | Organization | CareTeam | Patient | Device | RelatedPerson » The organization the device or practitioner was acting on behalf of onBehalfOf : Reference [0..1] Organization Indicates who or what performed the event {{title}} and how they were involved performer [0..*]

Structure

Instantiates protocol Σ ?! Σ 0..1 Why What type Σ
Name Flags Card. Type Description & Constraints      Filter: Filters doco
. . Event I Logical Event Pattern
+ Rule: Not Done Reason can only be specified if NotDone status is "true" 'not-done'
+ Rule: reason elements can only be specified if status is NOT 'not-done'
. . . identifier Σ 0..* Identifier Business Identifier identifier for event {{title}}

. . . definition basedOn Σ 0..* Reference ( Definition Request ) Fulfills plan, proposal or definition order

. . basedOn . partOf Σ 0..* Reference ( Request Event ) Part of referenced event
Fulfills plan, proposal or order
. . . status ?! Σ 1..1 code preparation | in-progress | not-done | suspended | aborted | completed | entered-in-error | unknown
Binding: EventStatus ( Required )
. . notDone . statusReason 0..1 boolean CodeableConcept Reason for current status
{{title}} did not occur
. . notDoneReason . category Σ I 0..* CodeableConcept High level categorization of {{title}} did not occur

. . . code Σ 0..1 CodeableConcept What service was done
. . . product Σ 0..1 CodeableReference ( BiologicallyDerivedProduct | Device | DeviceDefinition | Medication | NutritionProduct | Substance ) Product used/provided
. . . subject Σ 1..1 Reference ( Patient | Group ) Individual service was done for/to
. . context . encounter Σ 0..1 Reference ( Encounter | EpisodeOfCare ) Encounter / Episode associated with event the {{title}} is part of
. . . occurrence[x] Σ 0..1 When event occurred {{title}} occurred/is occurring
. . . . occurrenceDateTime dateTime
. . . . occurrencePeriod Period
. . . . occurrenceTiming Timing
. . performer . recorded Σ 0..1 dateTime When {{title}} was first captured in the subject's record
... reported[x] Σ 0..1 Reported rather than primary record
.... reportedBoolean 0..* BackboneElement boolean
. . . . reportedReference Reference ( Patient | RelatedPerson | Practitioner | PractitionerRole | Organization )
... performer Σ 0..* BackboneElement Who performed event {{title}} and what they did

. . . role . function Σ 0..1 CodeableConcept Type of performance was done
Procedure Performer Role Codes ( Example )
. . . . actor Σ 1..1 Reference ( Practitioner | PractitionerRole | Organization | CareTeam | Patient | Device | RelatedPerson ) Who performed {{title}}
Individual who was performing
. . onBehalfOf . location Σ 0..1 Reference ( Organization Location ) Where {{title}} occurred
Organization organization was acting for
. . reasonCode . reason Σ 0..* CodeableConcept CodeableReference ( Condition | Observation | DiagnosticReport | DocumentReference ) Why was event {{title}} performed?

. . reasonReference . note 0..* Reference ( Condition | Observation Annotation ) Why was Comments made about the event performed?

. . note . relevantHistory 0..* Annotation Reference ( Provenance Relevant History ) Key events in history of {{title}}
Comments made about the event

doco Documentation for this format icon

UML Diagram ( Legend )

Event ( Logical Base ) «Pattern» Identifiers Business identifiers assigned to this event {{title}} by the performer or and/or other systems systems. These identifiers remain constant as the resource is updated and propagates from server to server identifier : Identifier [0..*] A protocol, guideline, orderset or other definition that was adhered to in whole or in part by this event definition : Reference [0..*] Definition A plan, proposal or order that is fulfilled in whole or in part by this event {{title}} basedOn : Reference [0..*] « Request » A larger event of which this particular event {{title}} is a component or step partOf : Reference [0..*] « Event » Indicates that this {{title}} is relevant to the specified research study(ies) researchStudy : Reference [0..*] « ResearchStudy » The current state of the event {{title}} (this element modifies the meaning of other elements) status : code [1..1] « Codes identifying the stage lifecycle stage of a event an event. (Strength=Required) EventStatus ! » If true, indicates that Captures the described event (combination of code, timing, performer, etc.) did not actually occur (this element modifies reason for the meaning current state of other elements) the {{title}} notDone statusReason : boolean CodeableConcept [0..1] Describes why Partitions the event did not occur in coded {{title}} into one or more categories that can be used to filter searching, to govern access control and/or textual form to guide system behavior notDoneReason category : CodeableConcept [0..1] [0..*] A code that identifies the specific service or action that was or is being performed code : CodeableConcept [0..1] Indicates the product supplied or manipulated by this {{title}} product : CodeableReference [0..1] « BiologicallyDerivedProduct | Device | DeviceDefinition | Medication | NutritionProduct | Substance » The individual or set of individuals the action is being or was performed on subject : Reference [1..1] « Patient | Group » The encounter Encounter during which this {{title}} was created or episode of care that establishes to which the context for creation of this event record is tightly associated context encounter : Reference [0..1] « Encounter | EpisodeOfCare » The date date, period or time(s) timing when the activity occurred {{title}} did occur or is occurring occurrence[x] : Type DataType [0..1] « dateTime | Period | Timing » Describes why The date the event occurred occurrence of the {{title}} was first captured in coded or textual form the record - potentially significantly after the occurrence of the event reasonCode recorded : CodeableConcept dateTime [0..*] [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 report reported[x] : DataType [0..1] « boolean | Reference ( Patient | RelatedPerson | Practitioner | PractitionerRole | Organization ) » The principal physical location where the {{title}} was performed location : Reference [0..1] « Location » Describes why the {{title}} occurred in coded or textual form or Indicates another resource whose existence justifies this event {{title}} reasonReference reason : Reference CodeableReference [0..*] « Condition | Observation | DiagnosticReport | DocumentReference » Comments made about the event {{title}} by the performer, subject or other participants note : Annotation [0..*] 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 relevantHistory : Reference [0..*] « ( ProvenanceRelevantHistory ) » Performer Describes Distinguishes the type of performance (e.g. primary surgeon, anaesthesiologiest, etc.) involvement of the performer in the {{title}}. [Consider adding examples] role function : CodeableConcept [0..1] Codes describing the types of functional roles performers can take on when performing events (Strength=Example) Procedure Performer Role ?? The device, practitioner, etc. Indicates who or what performed the action {{title}} actor : Reference [1..1] « Practitioner | PractitionerRole | Organization | CareTeam | Patient | Device | RelatedPerson » The organization the device or practitioner was acting on behalf of onBehalfOf : Reference [0..1] Organization Indicates who or what performed the event {{title}} and how they were involved performer [0..*]

 

Alternate definitions: Master Definition XML + JSON .

12.4.4.1 12.4.5.1 Terminology Bindings

Event.performer.role Codes describing the types of functional roles performers can take on when performing events Unknown No details provided yet
Path Definition ValueSet Type Reference Documentation
Event.status EventStatus Required

Codes identifying the stage lifecycle stage of a event an event.

Event.statusReason Unknown No details provided yet Required Example EventStatus Codes identifying the reason for the current state of an event.
Event.code Unknown No details provided yet Example Codes indicating the details of what is/was done. These will vary significantly based on the type of request event resource and will often be example/preferred rather than extensible/required.
Event.performer.function Unknown No details provided yet Example Procedure Performer Role Codes that describe the specific involvement of a performer in an event. E.g. Primary vs. secondary vs. supervising, etc.
Event.reasonCode Event.reason Unknown No details provided yet Example 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.

12.4.4.2 12.4.5.2 Constraints

UniqueKey Level Location Description Expression
inv-1 : img  inv-1 Rule (base) Not Done Reason can only be specified if NotDone status is "true" ( expression 'not-done' : notDone status='not-done' or notDoneReason.exists().not() )
img  inv-2 Rule (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.5 12.4.7 State Machine

The following diagram shows the "typical" "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" "completed" back to "in-progress"). "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.8 Event history

This pattern contains an element called "eventHistory" that points to Provenance . This allows the resource to summarize key events that have happened over the lifespan of the resource. For example, when the event started, when it was suspended, when it was resumed, etc. The list of referenced Provenence entries don't necessarily include all events that have occurred over the lifespan of the resource. Instead, they list those the author considers 'significant' and relevant to downstream users. Modifications to drafts or small corrections that do not impact fulfillment might not be needed. In some cases, Provenance for changes to other resources (e.g. component events) might also be included if the source system tracks those as 'events' tied to the Event.

IMPORTANT: the eventHistory generally excludes the most recent change on 'pure' FHIR repositories. That is because in pure FHIR environments, the Provenance instance must be created after the update has been made - because it needs to point to the new 'version' of the resource that has been created. This means that if there is a desire to include the 'current' change in relevant history, it is necessary to first make the change, then update the resource to add the event to recentHistory. More typically, recentHistory simply won't include the most recent event. If the full history is needed, the system will need to retrieve both the history as well as the Provenance that points to the current release.

For systems that don't store history separately from the base resource, the eventHistory Provenance instances can be conveyed as contained resources . In this circumstance, there might also not be an issue with eventHistory also including the 'most recent' change as the history is updated at the same time the change is applied.

The full set of potential Provenance information may be overkill for those systems that are only interested in it from a eventHistory perspective. The Provenance Relevant History profile is included to give guidance on what data elements are most likely to be relevant for systems looking at Provenance from the perspective of eventHistory.

12.4.9 Use of 'identifier' and similar elements

The 'identifier' element is intended to be able to uniquely point to a single instance, however there are exceptions:

  • In order to be unique, both Identifier.system and Identifier.value must be present.
  • If the Identifier has an associated period, the identity only applies within that time-period.
  • There may be circumstances where the identifier might not always be unique. For example, social security numbers could appear on multiple patients due to fraud, entry error, or the presence of multiple patient records for the same individual for legacy purposes or the needs of differing departments.

Identifiers are not intended to act as 'classifiers' or 'categories', nor are they intended to convey identifiers for other business objects.

Some systems may contain legacy information that puts inappropriate content in identifier elements (e.g. placing an insurance subscriber id in Patient.identifier when that should instead go in Coverage.subscriber). In these situations, it is possible that values that are not actually 'proper' identifiers may still show up in identifier elements. While this is not 'correct', systems should still be tolerant of identifiers that prove to be non-unique.

Systems may choose to enforce that some identifiers systems must be unique within their system and only in the presence of such system enforcement can identifiers be safely used with a presumption that they will always resolve to only a single distinct record. If there is a need to convey 'categories' for resources, those can be conveyed in elements other than Resource.identifier. Examples include .code, .category, special elements like .groupIdentifier, extensions, or meta.tags.

12.4.10 Mappings

identifier basedOn partOf researchStudy status statusReason category code product subject encounter occurrence[x] recorded reported[x] performer .function.actor location reason note relevantHistory
AdverseEvent 1 1 1 1 T 1 2 NT 1 N 1 NT 1 1 T 1
AuditEvent 1 T 1 NC 1 NC 1 NTC 1 1 NT 1 NTC 1 N 1 NT 1 1 NT
ClaimResponse 1 1 NTC 1 1 NTC 1 NTC 1 NTC
Communication 1 1 T 1 T 1 1 1 C 1 2 NT 2 NTC 1 1
Composition 1 1|1 ET 0|1 E 1 1 NC 1 TC 1 1 NTC 1 NT
Consent 1 0|1 ET 0|1 E 1 1 NC 1 TC 1 NT
Contract 2 C 1 C 2 N 1 TC 2 NT 2 N 1 NTC 1 NT 1 NTC
Coverage 1 0|1 ET 1 1 NT 1 NT
CoverageEligibilityResponse 1 1 NTC 1 1 NT 1 NTC
DetectedIssue 1 1 1 1 1 TC 1 1 N 1 NTC 1 NT 1 NTC
DeviceAlert 1 1 NT 1 1 1 C 1 NT 1 T 1 1 T 1 1 NTC
DiagnosticReport 1 1 T 0|1 ET 0|1 E 1 0|1 E 1 1 C 1 TC 1 1 NT 2 NTC 0|1 E 1
DocumentReference 1 1 T 0|1 E 1 0|1 E 1 1 N 1 TC 1 NTC 1 NT 1 N 1 NT 1 NC 2 NTC 0|1 E
Encounter 1 2 NT 1 TC 0|1 E 1 2 NTC 1 C 2 NT 1 NT 1 NC 2 NTC 1 C 2 N
EnrollmentResponse 1 1 NTC 1 C 1 NT 1 NT 1 NTC
EpisodeOfCare 1 1|1 ENT 1 1 NC 1 1 NT 3 NTC 2 N
ExplanationOfBenefit 1 0|1 ET 1 1 NC 1 1 NTC
FamilyMemberHistory 1 0|1 ET 0|1 E 1 1 NT 1 1
GuidanceResponse 1 1 1 C 1 1 NT 1 NTC 1 1 1
ImagingSelection 1 1 T 1 1 1 C 1 TC 1 T 1 1 T
ImagingStudy 1 1 T 1 NT 1 1 T 1 1 NT 1 T 1 1 T 1 1 1
Immunization 1 1 T 0|1 E 1 1 2 NT 1 NT 1 1 TC 2 NT 1 T 1 1 T 1 1 1
Invoice 1 N 1 C 1
MedicationAdministration 1 1 NTC 1 T 0|1 E 1 1 C 1 NTC 1 1 1 C 1 T 1 1 T 0|1 E 1 1
MedicationDispense 1 1 NT 1 T 0|1 E 1 1 NTC 1 1 1 NT 1 T 1 T 0|1 E 1
MedicationStatement 1 0|1 ET 0|1 E 1 1 NTC 1 1 1 N 1 1
MessageHeader 1 NTC 1 TC
NutritionIntake 1 1 T 1 T 1 1 C 1 NT 1 1 1 T 1 1
Observation 1 1 T 1 T 0|1 E 1 0|1 E 1 1 C 1 TC 1 1 NT 1 NTC 0|1 E 1
PaymentNotice 1 1|1 ENT 1 1 NTC 1 NTC
PaymentReconciliation 1 0|1 ET 1 1 NTC 1 NTC 1 NTC
Procedure 1 1 T 1 T 0|1 E 1 1 1 1 T 1 1 T 1 1 1 T 1 1 T 1 1
Provenance 1 T 1 N 1 NTC 1 1 NT 1 NTC 1 N 1 NT 1 2 NTC
QuestionnaireResponse 1 1 T 1 T 0|1 E 1 1 TC 1 1 N 1 NTC
RiskAssessment 1 1 TC 1 NTC 0|1 E 1 1 1 1 1 T 1 NTC 1 1
Task 1 1 T 1 T 0|1 E 1 1 TC 1 1 NTC 1 NTC 1 1 NT 1 N 1 NTC 1|1 ENTC 1 1 1

Each non-grey cell contains a number, the number of elements and extensions (if > 0) mapped in the resource that are mapped to the pattern element in the column. If there are 0 elements and extensions, the number is not shown. In addition, the cell has a color and some character flags.

Colors:

  • Grey: the resource has no element or extension for the pattern element
  • White: the resource has an element that implements the pattern element with the same name
  • Yellow: the resource has a documented extension that implements the pattern element with the same name
  • Blue: the resource has an element that implements the pattern element with a different name
  • Red: the resource has an element that implements that pattern element, but the type or cardinality does not match

Flags:

  • E: pattern element implemented by an extension
  • N: pattern element implemented by an element with a different name
  • T: pattern element implemented by an element with a different type
  • C: pattern element implemented by an element with a different cardinality