Base StructureDefinition for TriggerDefinition Type: A description of a triggering event. Triggering events can be named events, data events, or periodic, as determined by the type element.
Subclass of core.model.Element (Base StructureDefinition for Element Type: Base definition for all elements in a resource.)
- Value parameters:
- `type`
- The type of triggering event.
- condition
- 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.
- data
- 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.
- extension
- May be used to represent additional information that is not part of the basic definition of the element. To make the use of extensions safe and manageable, there is a strict set of governance applied to the definition and use of extensions. Though any implementer can define an extension, there is a set of requirements that SHALL be met as part of the definition of the extension.
- id
- Unique id for the element within a resource (for internal references). This may be any string value that does not contain spaces.
- name
- 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.
- timing
- The timing of the event (if this is a periodic trigger).
- Constructor:
Introduces the fields
type
, name, data, timing, condition.- Companion:
- object
Type members
Inherited types
Value members
Concrete methods
Inherited methods
Slower than nodalMap, but should work with subtypes (e.g. PositiveInt). If you must use it, then:
Slower than nodalMap, but should work with subtypes (e.g. PositiveInt). If you must use it, then:
T
should not be a Choice[_], a LitSeq[_] or an Option[_]- It may require a type parameter sometimes (e.g.
sampleResource >>[BUNDLE_TYPE] { (_: BUNDLE_TYPE) => BUNDLE_TYPE.SEARCHSET }
)
- Inherited from:
- FHIRObject
- Inherited from:
- FHIRObject
Extract values of type From, and map to LitSeq[To] using fn: From => To. Unlike >>, this is safe even if From is a Choice[], a LitSeq[] or an Option[_] Quite slow, slower than nodalExtract
Extract values of type From, and map to LitSeq[To] using fn: From => To. Unlike >>, this is safe even if From is a Choice[], a LitSeq[] or an Option[_] Quite slow, slower than nodalExtract
- Inherited from:
- FHIRObject
- Inherited from:
- Utils
- Inherited from:
- Utils
- Inherited from:
- FHIRObject
- Inherited from:
- FHIRObject
Convenience alias for nodalGetByClass andThen map to LitSeq[To] using fn: From => To.
Convenience alias for nodalGetByClass andThen map to LitSeq[To] using fn: From => To.
- Inherited from:
- FHIRObject
Extract values of type From Unlike nodalMap, this is safe even if From is a Choice[_], a LitSeq[_] or an Option[_], however there remains a caveat with 'subtyped' types (eg PositiveInt), in that we can't differentiate them from the parent class Quite slow but faster than ^^
Extract values of type From Unlike nodalMap, this is safe even if From is a Choice[_], a LitSeq[_] or an Option[_], however there remains a caveat with 'subtyped' types (eg PositiveInt), in that we can't differentiate them from the parent class Quite slow but faster than ^^
- Inherited from:
- FHIRObject
Bit faster than >>
, but still much slower than using update$foo
when possible. If you must use it, then:
Bit faster than >>
, but still much slower than using update$foo
when possible. If you must use it, then:
T
should not be a Choice[_], a LitSeq[_], an Option[_], or any 'subtyped' type (eg PositiveInt). You should ensure, if T is a supertype of multiple valid choice values (e.g. T =:= Object), that the return value of fn retains the same type as the input value.
- Inherited from:
- FHIRObject
- Inherited from:
- FHIRObject
- Inherited from:
- FHIRObject
- Inherited from:
- FHIRObject
- Inherited from:
- FHIRObject
- Inherited from:
- FHIRObject