Specifies contact information for a person or organization.

Need to track contact information in the same way across multiple resources.

The name of an individual to contact.

If there is no named individual, the telecom information is for the organization as a whole.

The contact details for the individual (if a name was provided) or the organization.

Describes a required data item for evaluation in terms of the type of data, and optional code or date-based filters of the data.

The type of the required data, specified as the type name of a resource. For profiles, this value is set to the type of the base resource of the profile.

The profile of the required data, specified as the uri of the profile definition.

The intended subjects of the data requirement. If this element is not provided, a Patient subject is assumed.

The subject of a data requirement is critical, as the data being specified is determined with respect to a particular subject. This corresponds roughly to the notion of a Compartment in that it limits what data is available based on its relationship to the subject. In CQL, this corresponds to the context declaration.

Indicates that specific elements of the type are referenced by the knowledge module and must be supported by the consumer in order to obtain an effective evaluation. This does not mean that a value is required for this element, only that the consuming system must understand the element and be able to provide values for it if they are available.

The value of mustSupport SHALL be a FHIRPath resolvable on the type of the DataRequirement. The path SHALL consist only of identifiers, constant indexers, and .resolve() (see the Simple FHIRPath Profile for full details).

Code filters specify additional constraints on the data, specifying the value set of interest for a particular element of the data. Each code filter defines an additional constraint on the data, i.e. code filters are AND'ed, not OR'ed.

The code-valued attribute of the filter. The specified path SHALL be a FHIRPath resolvable on the specified type of the DataRequirement, and SHALL consist only of identifiers, constant indexers, and .resolve(). The path is allowed to contain qualifiers (.) to traverse sub-elements, as well as indexers ([x]) to traverse multiple-cardinality sub-elements (see the Simple FHIRPath Profile for full details). Note that the index must be an integer constant. The path must resolve to an element of type code, Coding, or CodeableConcept.

The path attribute contains a Simple FHIRPath Subset that allows path traversal, but not calculation.

A token parameter that refers to a search parameter defined on the specified type of the DataRequirement, and which searches on elements of type code, Coding, or CodeableConcept.

The valueset for the code filter. The valueSet and code elements are additive. If valueSet is specified, the filter will return only those data items for which the value of the code-valued element specified in the path is a member of the specified valueset.

The codes for the code filter. If values are given, the filter will return only those data items for which the code-valued attribute specified by the path has a value that is one of the specified codes. If codes are specified in addition to a value set, the filter returns items matching a code in the value set or one of the specified codes.

Date filters specify additional constraints on the data in terms of the applicable date range for specific elements. Each date filter specifies an additional constraint on the data, i.e. date filters are AND'ed, not OR'ed.

The date-valued attribute of the filter. The specified path SHALL be a FHIRPath resolvable on the specified type of the DataRequirement, and SHALL consist only of identifiers, constant indexers, and .resolve(). The path is allowed to contain qualifiers (.) to traverse sub-elements, as well as indexers ([x]) to traverse multiple-cardinality sub-elements (see the Simple FHIRPath Profile for full details). Note that the index must be an integer constant. The path must resolve to an element of type date, dateTime, Period, Schedule, or Timing.

The path attribute contains a Simple FHIR Subset that allows path traversal, but not calculation.

A date parameter that refers to a search parameter defined on the specified type of the DataRequirement, and which searches on elements of type date, dateTime, Period, Schedule, or Timing.

The value of the filter. If period is specified, the filter will return only those data items that fall within the bounds determined by the Period, inclusive of the period boundaries. If dateTime is specified, the filter will return only those data items that are equal to the specified dateTime. If a Duration is specified, the filter will return only those data items that fall within Duration before now.

Value filters specify additional constraints on the data for elements other than code-valued or date-valued. Each value filter specifies an additional constraint on the data (i.e. valueFilters are AND'ed, not OR'ed).

The attribute of the filter. The specified path SHALL be a FHIRPath resolvable on the specified type of the DataRequirement, and SHALL consist only of identifiers, constant indexers, and .resolve(). The path is allowed to contain qualifiers (.) to traverse sub-elements, as well as indexers ([x]) to traverse multiple-cardinality sub-elements (see the Simple FHIRPath Profile for full details). Note that the index must be an integer constant. The path must resolve to an element of a type that is comparable to the valueFilter.value[x] element for the filter.

The path attribute contains a Simple FHIR Subset that allows path traversal, but not calculation.

A search parameter defined on the specified type of the DataRequirement, and which searches on elements of a type compatible with the type of the valueFilter.value[x] for the filter.

The comparator to be used to determine whether the value is matching.

The value of the filter.

Specifies a maximum number of results that are required (uses the _count search parameter).

Enables the requirement "most recent 5 results" to be expressed.

This element can be used in combination with the sort element to specify quota requirements such as "the most recent 5" or "the highest 5".

Specifies the order of the results to be returned.

Enables the requirement "most recent 5 results" to be expressed.

This element can be used in combination with the sort element to specify quota requirements such as "the most recent 5" or "the highest 5". When multiple sorts are specified, they are applied in the order they appear in the resource.

The attribute of the sort. The specified path must be resolvable from the type of the required data. The path is allowed to contain qualifiers (.) to traverse sub-elements, as well as indexers ([x]) to traverse multiple-cardinality sub-elements. Note that the index must be an integer constant.

The direction of the sort, ascending or descending.

The parameters to the module. This collection specifies both the input and output parameters. Input parameters are provided by the caller as part of the $evaluate operation. Output parameters are included in the GuidanceResponse.

The name of the parameter used to allow access to the value of the parameter in evaluation contexts.

Whether the parameter is input or output for the module.

The minimum number of times this parameter SHALL appear in the request or response.

The maximum number of times this element is permitted to appear in the request or response.

A brief discussion of what the parameter is for and how it is used by the module.

The type of the parameter.

If specified, this indicates a profile that the input data must conform to, or that the output data will conform to.

Related artifacts such as additional documentation, justification, or bibliographic references.

Knowledge resources must be able to provide enough information for consumers of the content (and/or interventions or results produced by the content) to be able to determine and understand the justification for and evidence in support of the content.

Each related artifact is either an attachment, or a reference to another knowledge resource, but not both.

The type of relationship to the related artifact.

The presence of both sides of a relationship type (e.g. successor and predecessor) is required to support use cases where one side of a relationship is not represented in FHIR. However, this feature SHALL NOT be used to create bi-directional resource links in FHIR instances. Specifically, following the methodology of "new points to old" and "many points to one", when using related artifact elements to describe and reference FHIR resources, the type element SHALL be drawn from the fhir-related-artifact-type ValueSet.

Provides additional classifiers of the related artifact.

A short label that can be used to reference the citation from elsewhere in the containing artifact, such as a footnote index.

A brief description of the document or knowledge resource being referenced, suitable for display to a consumer.

A bibliographic citation for the related artifact. This text SHOULD be formatted according to an accepted citation format.

Additional structured information about citations should be captured as extensions.

The document being referenced, represented as an attachment. This is exclusive with the resource element.

The related artifact, such as a library, value set, profile, or other knowledge resource.

If the type is predecessor, this is a reference to the succeeding knowledge resource. If the type is successor, this is a reference to the prior knowledge resource.

The related artifact, if the artifact is not a canonical resource, or a resource reference to a canonical resource.

If both resource and resourceReference are present, they SHOULD be consistent and reference the same resource. Although relatedArtifact is intended to support references to definitional resources, there are cases where non-definitional resources can be definitional (such as Location where the kind is mode). Related artifacts SHOULD be used to reference definitional resources, and profiles SHOULD be used to make that explicit for particular use cases.

The publication status of the artifact being referred to.

The date of publication of the artifact being referred to.

A description of a triggering event. Triggering events can be named events, data events, or periodic, as determined by the type element.

If an event is a named-event, it means the event is completely pre-coordinated, and no other information can be specified for the event. If the event is one of the data- events, the data and condition elements specify the triggering criteria. The data element specifies the structured component, and the condition element provides additional optional refinement of that structured component. If the event is periodic, the timing element defines when the event is triggered. For both data- and periodic events, a name can be provided as a shorthand for the formal semantics provided by the other elements.

The type of triggering event.

A formal name for the event. This may be an absolute URI that identifies the event formally (e.g. from a trigger registry), or a simple relative URI that identifies the event in a local context.

An event name can be provided for all event types, but is required for named events. If a name is provided for a type other than named events, it is considered to be a shorthand for the semantics described by the formal description of the event.

A code that identifies the event.

A reference to a SubscriptionTopic resource that defines the event. If this element is provided, no other information about the trigger definition may be supplied.

The timing of the event (if this is a periodic trigger).

The triggering data of the event (if this is a data trigger). If more than one data is requirement is specified, then all the data requirements must be true.

This element shall be present for any data type trigger.

A boolean-valued expression that is evaluated in the context of the container of the trigger definition and returns whether or not the trigger fires.

Need to be able to formally describe the triggering criteria.

This element can be only be specified for data type triggers and provides additional semantics for the trigger. The context available within the condition is based on the type of data event. For all events, the current resource will be available as context. In addition, for modification events, the previous resource will also be available. The expression may be inlined, or may be a simple absolute URI, which is a reference to a named expression within a logic library referenced by a library element or extension within the containing resource. If the expression is a FHIR Path expression, it evaluates in the context of a resource of one of the type identified in the data requirement, and may also refer to the variable %previous for delta comparisons on events of type data-changed, data-modified, and data-deleted which will always have the same type.

A expression that is evaluated in a specified context and returns a value. The context of use of the expression must specify the context in which the expression is evaluated, and how the result of the expression is used.

A brief, natural language description of the condition that effectively communicates the intended semantics.

A short name assigned to the expression to allow for multiple reuse of the expression in the context where it is defined.

The media type of the language for the expression.

The cardinality of this element is optional to allow text only as part of the authoring process. However, in order to be executable, the expression element must be specified.

An expression in the specified language that returns a value.

If Expression.expression and Expression.reference are both present, the Expression.expression might just be a name pointing something within the referenced content.

A URI that defines where the expression is found.

If both a reference and an expression is found, the reference SHALL point to the same expression.

Specifies clinical/business/etc. metadata that can be used to retrieve, index and/or categorize an artifact. This metadata can either be specific to the applicable population (e.g., age category, DRG) or the specific context of care (e.g., venue, care setting, provider of care).

Consumers of the resource must be able to determine the intended applicability for the resource. Ideally, this information would be used programmatically to determine when and how it should be incorporated or exposed.

A code that identifies the type of context being specified by this usage context.

A value that defines the context specified in this context of use. The interpretation of the value is defined by the code.

Specifies contact information for a specific purpose over a period of time, might be handled/monitored by a specific named person or organization.

Need to track contact and address information in the same way across multiple resources.

This datatype may be sparsely populated, i.e. only contain a purpose and phone number or address, but other cases could be completed filled out.

The purpose/type of contact.

If no purpose is defined, then these contact details may be used for any purpose.

The name of an individual to contact, some types of contact detail are usually blank.

If there is no named individual, the telecom/address information is not generally monitored by a specific individual.

The contact details application for the purpose defined.

Address for the contact.

More than 1 address would be for different purposes, and thus should be entered as a different entry,.

This contact detail is handled/monitored by a specific organization. If the name is provided in the contact, then it is referring to the named individual within this organization.

Some specific types of contact information can be an handled by an organization (eg legal council is via a specific firm).

Period that this contact was valid for usage.

If the details have multiple periods, then enter in a new ExtendedContact with the new period.

The set of values required to describe a virtual service's connection details, including some limitations of the service.

The type of virtual service to connect to (i.e. Teams, Zoom, Specific VMR technology, WhatsApp).

As this type defines what the virtual service is, it then defines what address and additional information might be relevant.

Some profiles could be used for specific types to define what the other values could/should be.

What address or number needs to be used for a user to connect to the virtual service to join. The channelType informs as to which datatype is appropriate to use (requires knowledge of the specific type).

A web address that provides additional details on the call, such as alternative/regional call in numbers, or other associated services.

Maximum number of participants supported by the virtual service where there are limitations imposed.

Some services have only a limitted number of participants permitted to connect at a time, this is typically used in "shared" virtual services that you might find on location resources.

Typically on-demand services might not have these restrictions.

Some systems require an additional factor/value be provided to access the service.

Some services require a session key to be able to access the service once connected.

This could be in cases where a shared number is used, and a session key is added to put into a private line, or to identify the participant in a call.

Availability data for an {item}, declaring what days/times are available, and any exceptions. The exceptions could be textual only, e.g. Public holidays, or could be time period specific and indicate a specific years dates.

A collection of times that the {item} is available.

Indicates which days of the week are available between the start and end Times.

Is this always available? (hence times are irrelevant) i.e. 24 hour service.

The opening time of day. Note: If the AllDay flag is set, then this time is ignored.

The timezone is expected to be specified or implied by the context this datatype is used.

The closing time of day. Note: If the AllDay flag is set, then this time is ignored.

The timezone is expected to be specified or implied by the context this datatype is used.

The {item} is not available during this period of time due to the provided reason.

The reason that can be presented to the user as to why this time is not available.

The reason will generally be provided to give the textual reason for displaying when the {item} is not available, e.g. 'Closed public holidays' or 'Independence Day'. In cases such as this, the during might not be included and local knowledge would be required in such cases (as don't desire to keep updating when the holiday occurs each year).

e.g.2: 'Closed for maintenance over the summer' for this example you would want to include the during period, unless this was a university hospital and the "summer" period was well known, but would recommend its inclusion anyway.

The {item} is not available (seasonally or for a public holiday) during this period.

Financial line items use this datatype to commonly categorize the value, and other factors that may effect how the value should be interpreted.

The type of monetary component, what the value is to be used for and how that should be applied in its context. e.g. A surchange would increase the cost, a deduction would reduce the cost.

A codable breakdown of the type of monetary component. e.g. State Tax, Federal Tax, VIP-Discount.

Some monetary component types can be further classified and need to be differentiated.

The factor that has been applied to the base price (in another monetary component value) when performing calculations.

The explicit value amount of the component (based on type/code).