Struct RequirementsStatement

pub struct RequirementsStatement {

    pub id: Option<String>,
    pub extension: Vec<Extension>,
    pub modifier_extension: Vec<Extension>,
    pub key: String,
    pub key_ext: Option<FieldExtension>,
    pub label: Option<String>,
    pub label_ext: Option<FieldExtension>,
    pub conformance: Vec<Option<ConformanceExpectation>>,
    pub conformance_ext: Vec<Option<FieldExtension>>,
    pub conditionality: Option<bool>,
    pub conditionality_ext: Option<FieldExtension>,
    pub requirement: String,
    pub requirement_ext: Option<FieldExtension>,
    pub derived_from: Option<String>,
    pub derived_from_ext: Option<FieldExtension>,
    pub parent: Option<String>,
    pub parent_ext: Option<FieldExtension>,
    pub satisfied_by: Vec<Option<String>>,
    pub satisfied_by_ext: Vec<Option<FieldExtension>>,
    pub reference: Vec<Option<String>>,
    pub reference_ext: Vec<Option<FieldExtension>>,
    pub source: Vec<Option<Reference>>,
    pub source_ext: Vec<Option<FieldExtension>>,
}

Sub-fields of the statement field in Requirements

Fields

id: Option<String>

Unique id for inter-element referencing

Unique id for the element within a resource (for internal references). This may be any string value that does not contain spaces.

extension: Vec<Extension>

Additional content defined by implementations

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 managable, 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.

There can be no stigma associated with the use of extensions by any application, project, or standard - regardless of the institution or jurisdiction that uses or defines the extensions. The use of extensions is what allows the FHIR specification to retain a core level of simplicity for everyone.

modifier_extension: Vec<Extension>

Extensions that cannot be ignored even if unrecognized

May be used to represent additional information that is not part of the basic definition of the element and that modifies the understanding of the element in which it is contained and/or the understanding of the containing element’s descendants. Usually modifier elements provide negation or qualification. To make the use of extensions safe and managable, 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. Applications processing a resource are required to check for modifier extensions.

Modifier extensions SHALL NOT change the meaning of any elements on Resource or DomainResource (including cannot change the meaning of modifierExtension itself).

There can be no stigma associated with the use of extensions by any application, project, or standard - regardless of the institution or jurisdiction that uses or defines the extensions. The use of extensions is what allows the FHIR specification to retain a core level of simplicity for everyone.

key: String

Key that identifies this statement

Key that identifies this statement (unique within this resource).

Refer directly to the statement by {url}#{key}

key_ext: Option<FieldExtension>

Extension field.

label: Option<String>

Short Human label for this statement

A short human usable label for this statement.

The key is intended for computers, while this is intended for humans. In its absence, the key should be convenient for a human to say (e.g. not a UUID)

label_ext: Option<FieldExtension>

Extension field.

conformance: Vec<Option<ConformanceExpectation>>

??; SHALL | SHOULD | MAY | SHOULD-NOT

A short human usable label for this statement.

The conformance code is extracted from the requirement to make indexing and display easier. The requirement needs to express the conformance verbs directly in the markdown content. It’s not unusual to mix verbs in a single sentence (e.g. System SHALL do X and SHOULD do Y)

conformance_ext: Vec<Option<FieldExtension>>

Extension field.

conditionality: Option<bool>

Set to true if requirements statement is conditional

This boolean flag is set to true of the text of the requirement is conditional on something e.g. it includes lanauage like ‘if x then y’. This conditionality flag is introduced for purposes of filtering and colour highlighting etc.

There is no intent that the conditional statement by evaluatable

conditionality_ext: Option<FieldExtension>

Extension field.

requirement: String

The actual requirement

The actual requirement for human consumption.

requirement_ext: Option<FieldExtension>

Extension field.

derived_from: Option<String>

Another statement this clarifies/restricts ([url#]key)

Another statement on one of the requirements that this requirement clarifies or restricts.

This can be just a key, if there is only one matching statement in the requirements statements referenced in Requirements.derivedFrom. If there is more than one, it should be in the format texturl#key

derived_from_ext: Option<FieldExtension>

Extension field.

parent: Option<String>

A larger requirement that this requirement helps to refine and enable

A larger requirement that this requirement helps to refine and enable.

Follows the same convention as statement.derivedFrom, where a reference is the canonical of the Requirements followed by ‘#’ and the ‘key’ of the specific requirement.

parent_ext: Option<FieldExtension>

Extension field.

satisfied_by: Vec<Option<String>>

Design artifact that satisfies this requirement

A reference to another artifact that satisfies this requirement. This could be a Profile, extension, or an element in one of those, or a CapabilityStatement, OperationDefinition, SearchParameter, CodeSystem(/code), ValueSet, Libary etc.

This is for use when the requirement is met be a pre-existing artifact e.g. a rule that’s met by the base FHIR spec, or a national implementation guide.

satisfied_by_ext: Vec<Option<FieldExtension>>

Extension field.

reference: Vec<Option<String>>

External artifact (rule/document etc. that) created this requirement

A reference to another artifact that created this requirement. This could be a Profile, etc., or external regulation, or business requirements expressed elsewhere.

reference_ext: Vec<Option<FieldExtension>>

Extension field.

source: Vec<Option<Reference>>

Who asked for this statement

Who asked for this statement to be a requirement. By default, it’s assumed that the publisher knows who it is if it matters.

source_ext: Vec<Option<FieldExtension>>

Extension field.

Implementations

impl RequirementsStatement

pub fn builder() -> RequirementsStatementBuilder

Start building a new instance

Trait Implementations

impl Clone for RequirementsStatement

fn clone(&self) -> RequirementsStatement

Returns a duplicate of the value.

fn clone_from(&mut self, source: &Self)

Performs copy-assignment from source.

impl Debug for RequirementsStatement

fn fmt(&self, f: &mut Formatter<'_>) -> Result<(), Error>

Formats the value using the given formatter.

impl<'de> Deserialize<'de> for RequirementsStatement

fn deserialize<__D>( __deserializer: __D, ) -> Result<RequirementsStatement, <__D as Deserializer<'de>>::Error>

where __D: Deserializer<'de>,

Deserialize this value from the given Serde deserializer.

impl PartialEq for RequirementsStatement

fn eq(&self, other: &RequirementsStatement) -> bool

Tests for self and other values to be equal, and is used by ==.

fn ne(&self, other: &Rhs) -> bool

Tests for !=. The default implementation is almost always sufficient, and should not be overridden without very good reason.

impl Serialize for RequirementsStatement

fn serialize<__S>( &self, __serializer: __S, ) -> Result<<__S as Serializer>::Ok, <__S as Serializer>::Error>

where __S: Serializer,

Serialize this value into the given Serde serializer.

impl StructuralPartialEq for RequirementsStatement